Digital-Bevissikring

Logdata fra fagsystemer i ansættelsessager

Logdata fra fagsystemer i ansættelsessager

I mange ansættelsessager handler beviset om, hvad en medarbejder har gjort i et fagsystem. Har medarbejderen slået op i en journal uden arbejdsmæssig grund? Er der ændret i en sag efter en frist? Er der eksporteret data, som medarbejderen ikke skulle bruge? Fagsystemer i sundhedsvæsenet, kommuner, forsikring, finans og advokatbranchen logger ofte netop den slags hændelser.

Logdata kan være stærke beviser, men de bliver ofte læst for bogstaveligt. En logpost viser en registrering i et system, ikke en handling udført af en bestemt person med en bestemt hensigt. Denne artikel forklarer, hvad logdata fra fagsystemer kan og ikke kan vise. Den ansættelsesretlige vurdering er advokatens.

Hvilke logs findes typisk?

  • Opslagslog · Hvad den registrerer: Hvilken bruger åbnede hvilken journal eller sag, og hvornår · Hvem har den: Systemejer og systemleverandør
  • Ændringslog · Hvad den registrerer: Hvad der blev ændret, af hvem, og hvad der stod før · Hvem har den: Systemejer og systemleverandør
  • Eksport- og udskriftslog · Hvad den registrerer: Udtræk, udskrifter, download af dokumenter · Hvem har den: Systemejer, evt. printserver
  • Loginlog · Hvad den registrerer: Hvornår brugeren loggede ind og ud, fra hvilken enhed · Hvem har den: IT-afdeling, identitetsløsning
  • Rettighedslog · Hvad den registrerer: Hvilke adgange brugeren havde og hvornår de blev ændret · Hvem har den: IT-afdeling

Ikke alle systemer logger det hele. Nogle registrerer kun ændringer, ikke opslag. Andre logger opslag på personniveau, men gemmer kun loggen i en begrænset periode. → Logfiler og logrotation

Det første, der skal sikres

Når en sag om opslag eller ændringer opstår, skal logs sikres, før de roterer væk eller bliver overskrevet:

  1. Bed systemejeren eller leverandøren udtrække de relevante logs i deres fulde form, ikke kun en rapport.
  2. Sikr loginlogs for samme periode fra den centrale identitetsløsning.
  3. Dokumentér medarbejderens rettigheder i perioden, og hvornår de er ændret.
  4. Notér, hvem der har trukket loggen, hvordan og hvornår.

Udtrækket bør beregnes med hashværdi og opbevares, så det kan vises, at det ikke er ændret senere.

Hvorfor en logpost ikke er det samme som en handling

Bruger er ikke lig person. En logpost registrerer en brugerkonto. Har andre haft adgang til kontoen, fordi en kollega lod sig være logget ind, eller fordi en fælles arbejdsstation ikke låste, svækkes sammenhængen mellem konto og person. → Sessioner, tokens og loginlogs

Opslag er ikke altid bevidste. Nogle systemer registrerer et opslag, når en journal vises i en liste, når et søgeresultat forhåndsvises, eller når et andet system henter data automatisk. Det skal undersøges, hvad der faktisk udløser en logpost i det konkrete system.

Tid kan være upræcis. Systemets tid, serverens tidszone og loggens format skal afklares. Står loggen i UTC, svarer 21.15 i loggen til 23.15 dansk sommertid.

Ændringer kan være automatiske. Integrationer, batchjobs og systemopdateringer kan registreres under en bruger eller en teknisk konto. Det skal fremgå, hvilke ændringer der er manuelle.

Når systemet drives af en leverandør

Mange fagsystemer drives af en ekstern leverandør, og systemejeren ser kun det, leverandørens brugerflade viser. Rapporter over opslag kan være forenklede: De kan samle flere logposter til én eller udelade tekniske detaljer som arbejdsstation eller session. Spørg derfor leverandøren, hvilke felter den fulde log indeholder, og om den kan udleveres i et maskinlæsbart format. Det kan også være nødvendigt at få leverandørens beskrivelse af, hvordan logningen virker, som dokumentation til en eventuel skønsmand.

Leverandørens udtræk bør ledsages af oplysninger om, hvem der har foretaget det, hvilke søgekriterier der er brugt, og hvilken periode det dækker. Ellers kan det senere være svært at vise, at udtrækket er fuldstændigt.

Rettigheder i systemet

Mange sager drejer sig om, hvorvidt medarbejderen måtte se eller ændre noget. Teknisk adgang og tilladt brug er ikke det samme. Et system kan give alle medarbejdere i en afdeling adgang til alle sager, selvom de kun må arbejde med nogle af dem. Det skal derfor dokumenteres både, hvad systemet tillod, og hvad der var instrueret. Instrukser, rettighedsoversigter og tidligere ændringer i rettigheder er relevante bilag.

Arbejdsmæssig grund og kontekst

I sager om uberettigede opslag er spørgsmålet ofte, om opslaget havde en arbejdsmæssig grund. Logdata kan sjældent svare på det alene. De skal sammenholdes med vagtplaner, opgavefordeling, henvisninger og sagens øvrige akter. Et eksempel: Et opslag i en journal kan se uberettiget ud, indtil det viser sig, at medarbejderen havde en opgave i en tilgrænsende sag samme dag. Konteksten kommer typisk fra arbejdsgiveren, ikke fra loggen.

Intern undersøgelse og medarbejdernes rettigheder

Gennemgang af logs i en intern undersøgelse rejser spørgsmål om, hvem der må se dem, og om medarbejderen er orienteret om logningen. → Intern undersøgelse: hvem skal vide hvad? → GDPR og bevisførelse

Logs fra fagsystemer indeholder ofte oplysninger om borgere, patienter eller kunder. Ved fremlæggelse kan det være nødvendigt at anonymisere eller afgrænse materialet.

Når en bortvisning bygger på logs

En bortvisning træffes ofte hurtigt. Bygger den på logdata, bør det være afklaret, hvad loggen faktisk viser, før beslutningen træffes. Ellers risikerer arbejdsgiveren at bygge på en fortolkning, der ikke holder, når en skønsmand ser på den. → Bortvisning på grundlag af digitale beviser

IT-medarbejdere eller systemansvarlige kan blive vidner i sagen og bør være forberedt på at forklare, hvordan logningen fungerer. → Vidneforklaring fra IT-medarbejdere

Når klienten er medarbejderen

Repræsenterer advokaten medarbejderen, har klienten sjældent selv adgang til loggen. Det første skridt er derfor at bede arbejdsgiveren om det fulde udtræk og ikke kun den sammenfatning, der lå til grund for afskedigelsen eller bortvisningen. Spørg også efter loginlogs og rettighedsoversigt for samme periode, så det kan vurderes, om kontoen kan være brugt af andre.

Klientens egen forklaring er vigtig for den tekniske gennemgang. Hvordan foregik arbejdet i praksis? Blev arbejdsstationer delt, låste skærmen automatisk, og var der kolleger, der loggede ind for hinanden i travle perioder? Arbejdede klienten med lister, søgninger eller oversigter, der kan have udløst opslag uden et egentligt klik på den enkelte journal? Sådanne oplysninger giver den sagkyndige konkrete hypoteser at efterprøve mod loggen, i stedet for en generel indsigelse om, at “loggen ikke er præcis”.

Spørgsmål til klienten

  • Hvilket system drejer det sig om, og hvem er leverandør?
  • Hvilke hændelser logger systemet, og hvor længe gemmes loggen?
  • Hvem har trukket den log, der foreligger, og hvordan?
  • Deler medarbejderne arbejdsstationer eller logins?
  • Hvad var medarbejderens opgaver og rettigheder i perioden?

Spørgsmål til skønsmanden

  • Hvad udløser en logpost af den pågældende type i systemet?
  • Er loggen fuldstændig for perioden, eller er der huller?
  • Hvilke registreringer er manuelle, og hvilke er automatiske?
  • Er der tegn på, at kontoen er brugt fra andre enheder eller samtidig fra flere steder?

Typiske fejl

  • Kun en sammenfattende rapport fremlægges, ikke selve logudtrækket.
  • Det antages, at alle opslag er bevidste handlinger.
  • Tidszone og systemtid undersøges ikke.
  • Konteksten om medarbejderens opgaver indhentes ikke.

Tjekliste

  • ☐ Logs er udtrukket i fuld form og sikret med hashværdi
  • ☐ Loginlogs og rettigheder er sikret for samme periode
  • ☐ Det er afklaret, hvad der udløser en logpost
  • ☐ Tidszone er afklaret
  • ☐ Kontekst om opgaver og vagter er indhentet
  • ☐ Persondata i materialet er afgrænset før fremlæggelse

→ Send en sag · Tlf. 70 13 63 23 · IT-sagkyndig bistand til advokater hos Nielco IT

John Nielsen, IT-sagkyndig

Har du en sag med digitale beviser?

Skriv kort om sagen og eventuelle frister, så vender jeg tilbage. Kun civile sager.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.