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.
- 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.
- 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.
- 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.