Bästa praxis (best practice)

Bakgrund

EU lanserade GDPR och vi släptte 5.43.0 med funktioner för att ge administratörer möjligheten att följa de nya regelverken.

Som en del av detta så införde vi för nyskapade databaser två scheman i schemaläggaren för radering av händelser som är äldre än 14 dagar. Det ena schemat kör daglig nattkörning och det andra vid varje omstart av RaServer. Den för omstarter finns ifall man har en server som inte är igång 24/7 så att när man startar servern så raderas allt gammalt som inte kune köras på nattkörningen.

Nu finns det inga exakta tidsperioder i lagarna utan det är baserat på verksamheters behov. Av den orsaken bör man se över schemaläggaren och se till att man har en design som är anpasssad för ens anläggning.

Vi rekommenderar nedan tankesätt.

Obs. vi rekommenderar alltid att man har dubbla scheman, ett för nattkörning och ett för start av RaServer. Detta beskrivs inte nedan.

1. Sätt schema för anonymisering av systemhändelser på en period som man behöver ha full loggning. Allt under en månad bör vara rimlig nivå för de flesta verksamheter.
2. Sätt ett schema för radering av systemhändelser på en period som är längre än anonymisering och tillräckligt lång för att tekniker ska kunna felsöka vid tekniska incidenter. Här kan 3-6 månader vara rimligt intervall.
3. Slutligen sätt ett schema på radering av operatörsloggar. Denna täcker administration och inte passager och är inte lika GDPR känsligt så man kan ha längre tid än anonymiseringen. Sätt valfri period.
    

Offline-enheter

Vi har även lagt till möjligheten att inte spara händelser i offline-enheter. Detta då automatisk anonymisering och radering inte är möjligt i dessa. Om man sparar händelser i dessa så kommer en hämtning med ODM att återföra den kompletta historiska loggen som enheten hanterar. Nattkörningsschema eller schema för hantering vid omstart mitigerar detta, dvs generellt så dagen efter är allt OK igen.

För de flesta anläggningar är det ok med ovan mindre avsteg. För andra är det inte ok. Därför finns numera inställningen. Och som alla säkerhetsinställningar så är standard satt till högsta säkerhet. D.v.s. nyskapande av offline-enheter sparar inga loggar. Så tänk på att ev se över dessa inställningar vid driftsättning av nya enheter.

Vi behöver inte följa GDPR, kan vi skippa radering?

Radering av händelser behövs alltid för att inte fylla databasen då det medför långsammare system. Kör man på SQL express har man även diskytesbegränsningar.

Återigen här har vi lösningar. Man kan sätta ett schema på arkivering istället för radering. Detta kommer då exportera händelseloggen till en arkivfil utanför M5. Denan fil kan man senare med ett speciellt program inspektera.

Obs att även nedan bör i så fall ses över.

Fler GDPR funktioner

Vi har även funktioner vilka kan styras från Inställningar-> Inställningar -> System -> GDPR enligt nedan.

Precis som tidigare så enl. högsta säkerhet så är dessa aktiva som standard nya databaser.

De är ganska drastiska och de flesta verksamheter behöver inte dessa så länge de har följt ovan instruktioner gällande schemaläggning av radering och ev. avidentifiering.

Avidentifieirng av specfik användare kan utföras manuellt när som helst så länge de finns kvar i databasen. Så man kan därmed anonymisera en specifik individ, och sen radera denne och utför samma som den automatiska funktionen ovan.

Radering av inaktiva användare

Här har vi ett verktyg som heter AdminBin. Denna kan användas manuellt eller via schemaläggaren. Se F1-hjälpen för ytterligare information.

Vi rekommenderar att man schemalägger detta verktyg så att kort spärras om de inte använts på en viss tid. Vi föreslår en period om 3 månader. Tänk på att inte sätta perioden för kort då t.ex. sommarledigheter inte bör medföra påverkan. 
Orsaken till att man spärrar utan att radera är för att om det är ett misstag, så kan man ta bort spärren när berörd individ rapporterar problemet.

Man kan sen senare använda AdminBin manuellt för att söka på spärrade kort och därifrån radera de man anser ska raderas. Tyvärr kan man inte söka på kort som varit spärrade en viss tid så här behöver man manuellt veta vad som är vad.

Även schemaläggning av radering av användare utan kort bör sättas upp. Kan förstås även köras manuellt om så önskas.

VIKTIGT: Det finns en funktion för att markera kort så att de inte dyker upp i AdminBin så att man t.ex. kan få specifika individer att inte bli spärrade eller att specifika spärrade inte blir raderade.

OBS: Manuell användning av AdminBin kräver att operatören är Systemadmin. Detta kan tyvärr inte kringgås p.g.a. funktionens natur där man måste kunna se samtliga användare och kort.

Nedan har vi samlat en liten lista med vad vi anser är best practice; fördelar och nackdelar gällande hantering av domäner i R-CARD M5.

Rekommendationer

• Vi rekommenderar att använda en anknytning per domän i den mån man kan.
  Det finns självklart rimliga förklaringar till att ha flera anknytningar. T.ex. om det är en flerbostad med flera huskroppar och man av andra tekniska orsaker inte behöver lägga allt på en enda anknytning, då är det förstås rimligt att ha flera anknytningar i samma domän.
   
• En Mifare-profilgrupp per domän. Detta medför att om man behöver göra förändringar så måste man inte uppdatera samtliga domäner. Även här finns det rimliga undantag, t.ex. vid användande av RCO SecuR-Card (DESFire). Profilerna kan självklart vara identiska trots olika domäner.

Fördelar med domäner

• Varje domän har en egen årskalender. Behöver man t.ex. ha samma inställningar för årskalender i flera domäner kan man kopiera mellan kalendrar.
   
• Konfigurationsinställningar för UC är domänberoende. T.ex. Antal kort, antal behörigheter m.m.. Ju mer man delar upp anläggningar i flera domäner desto bättre blir minneshanteringen så man garanterat får plats med sina användare m.m.. 

Nackdelar med domäner

• Administration av taggar för användare som ska komma åt flera domäner. Här blir det tyvärr mer att göra då man inte kan ha en enda övergripåande behörighetsgrupp. Man kan göra detta enklare genom användermallar eller kortmallar.
   
• Man kan i nyare versioner ha upp till 1024 domäner men endast 256 säkerhetsgrupper. Detta medför att man inte kan ha en per domän unik säkerhetsgrupp ifall man överstiger detta.