Sikkerhedslogning skal gøre det muligt at opdage misbrug og undersøge, hvad der skete i et it-system. Det kræver et valg af relevante hændelser, pålidelige tidsangivelser, beskyttelse mod ændring og nogen, der reagerer. En stor samling logfiler uden sammenhæng mellem hændelserne giver ikke nødvendigvis et brugbart undersøgelsesgrundlag.
Den konkrete opgave er at beslutte, hvilke spor der er nødvendige for de systemer, organisationen driver eller køber. Guiden følger hændelsen fra kildesystem til analyse og sletning. Et gennemgående fiktivt eksempel viser logning i en kundeserviceportal, hvor medarbejdere læser sager, eksporterer bilag og administrerer rettigheder.
Start med det spørgsmål, loggen skal kunne besvare
Et sikkerhedsspørgsmål kan være: Har en medarbejder åbnet kundesager uden en arbejdsopgave? Et andet kan være: Hvem gav en ekstern konsulent administratorrettigheder, og blev adgangen fjernet igen? De spørgsmål kræver forskellige hændelser. Login alene kan ikke vise, hvilke sager en bruger derefter åbnede.
Datatilsynets katalog om logning af brugernes anvendelser af personoplysninger beskriver relevante muligheder og knytter nødvendigheden til en konkret risikovurdering. Vejledningen omfatter også, at logfunktionen skal kunne afprøves. Det er ikke en ubetinget ordre om at gemme alt fra enhver applikation.
Skriv derfor først undersøgelsesspørgsmålene. Knyt dem til systemets oplysninger, brugergrupper og mulige skade. Når et svar kun kræver en sagsreference, er det normalt et dårligt udgangspunkt at kopiere hele sagens tekst ind i loggen. Brug dataminimering allerede ved valg af hændelsesfelter.
Afgræns de forskellige logtyper
Adgangslogs viser brug af oplysninger. Administrationslogs viser ændringer i konti og rettigheder. Tekniske driftslogs viser eksempelvis fejl i en tjeneste. De kan forbindes i en undersøgelse, men deres formål, adgang og opbevaring er ikke automatisk identiske.
Datatilsynets særskilte vejledning om brugeradministratorers handlinger fremhæver risikoen ved de privilegier, administratoren kan tildele. En person, der selv kan give adgang, bør ikke uden videre kunne ændre de uafhængige spor af den handling.
I kundeserviceportalen vælges følgende adskillelse:
| Kilde | Hændelse | Praktisk spørgsmål |
|---|---|---|
| Identitetstjeneste | Vellykket og afvist login, faktorændring | Hvordan blev kontoen anvendt og genetableret? |
| Kundeserviceportal | Læsning, ændring og eksport af sag | Hvilke oplysninger blev faktisk anvendt? |
| Brugeradministration | Tildeling og fjernelse af rolle | Hvem ændrede adgangen og til hvad? |
| Logmodtager | Afbrudt indsamling eller afvist format | Er undersøgelsesgrundlaget komplet? |
Tabellen er et designvalg til eksemplet. En anden behandling kan kræve yderligere hændelser, eksempelvis søgning eller sletning, mens andre felter kan være unødvendige.
Brug felter, der kan forbindes uden at udlevere indhold
En hændelse bør kunne knyttes til en handling, en bruger eller tjeneste, en ressource og et tidspunkt. Noter også resultatet, når forskellen mellem afvist og gennemført handling er relevant. To mislykkede eksportforsøg er noget andet end to gennemførte eksporter, selv om begge udløser en teknisk hændelse.
Et udfyldt, fiktivt eksempel kan se sådan ud: Klokken 10.14.32 UTC udfører bruger K42 handlingen eksport i kundeserviceportalen for sag S108. Resultatet er gennemført, og hændelsen har reference EV731. Loggen indeholder ikke kundens navn, personnummer, bilagets indhold eller et aktivt downloadlink. En særskilt, beskyttet opslagstabel kan forbinde brugerreferencen med en person, når undersøgelsen kræver det.
Sags- og brugerreferencer kan stadig være personoplysninger. At navnet mangler, gør ikke automatisk loggen anonym. Det samme gælder IP-adresser, når identifikation er mulig i den relevante sammenhæng. Planlæg adgang og information efter de faktiske koblingsmuligheder.
Undgå hemmeligheder i sporene. Adgangskoder, sessionsnøgler og komplette godkendelsesheadere kan gøre selve logsystemet til en adgangsvej. Ved fejlfindingslogning skal udvikleren kontrollere, om et bibliotek automatisk inkluderer sådanne værdier. En skærmoptagelse af fejlen kan ellers skabe en kopi af det, programmet korrekt undlod at logge.
Beskyt transport, lagring og administration
Et spor kan være nyttigt ved undersøgelse af en kompromitteret server, hvis en uafhængig kopi stadig eksisterer. Den konkrete arkitektur bør derfor overveje, hvad angriberen kan ændre med rettigheder på kildesystemet. Lokal logning alene er sårbar, når den samme konto kan slette alle spor.
Begræns adgangen til logtjenesten efter opgaven. En driftsmedarbejder kan have behov for at se, om logstrømmen fungerer, uden at skulle læse alle brugerhændelser. En undersøger kan have behov for afgrænset adgang til en sag. Eksport af logs bør have et formål og en modtager, og eksportfiler skal indgå i opbevaringsreglerne.
Kryptering og nøglestyring kan beskytte bestemte led, men kan ikke erstatte rettighedsstyringen. Hvis analysebrugeren lovligt kan dekryptere alle oplysninger, er det fortsat brugerens rolle og handlinger, der skal afgrænses. Vurder også, hvordan logsystemet genetableres efter en fejl, og hvordan ændringer i logkonfigurationen bliver synlige.
Fastlæg opbevaring pr. formål
GDPR’s princip om opbevaringsbegrænsning gælder også logs, der indeholder personoplysninger. Datatilsynets logvejledning fastsætter ikke én universel dansk periode for alle systemer. Valget skal kunne forklares ud fra formål og konkrete behov. Notér, hvilke særlige regler der eventuelt påvirker den valgte periode.
Virksomheden i eksemplet gennemgår relevante adgangsrettigheder hver anden måned. Den har erfaret, at fejl kan opdages i den gennemgang, og vælger som et konkret, dokumenteret udgangspunkt at bevare de relevante adgangsspor i 90 dage. Det giver i det tænkte forløb plads til undersøgelse efter gennemgangen. Valget skal ændres, hvis trusselsvurdering, faktiske undersøgelser eller særlige regler viser et andet nødvendigt tidsrum.
Den særskilte driftslog med gentagne ufarlige fejl behøver ikke nødvendigvis følge samme periode. Et afgrænset udtræk til en igangværende hændelsesundersøgelse kan have et andet begrundet opbevaringsbehov. Registrer udtrækkets ejer, årsag og tidspunkt for genvurdering, så en konkret undtagelse ikke bliver permanent opbevaring af hele logarkivet.
Se opbevaringsbegrænsning og slettefrister for selve beslutningsmetoden. Kontroller også den tekniske sletning: Gælder den indekser, kolde lagre og eksporter, eller kun det dashboard, analytikeren bruger?
Fra registreret hændelse til en anvendelig alarm
En alarm skal pege på en første undersøgelse. I eksemplet udløser en ny administratorrolle hos en ekstern konsulent en besked til den interne driftsansvarlige. Denne sammenholder hændelsen med ændringsgodkendelsen. Mangler godkendelsen, kontaktes hændelsesansvarlig, og adgangen begrænses efter den aftalte procedure.
En stor eksport kan også udløse en alarm, men volumen skal forstås i sammenhæng med rollen. En månedlig legitim afstemning kan ligne misbrug, hvis reglen kun tæller antal poster. Skriv den tilladte arbejdsgang ind i analyseinstruksen og dokumenter undtagelser. Undgå at gøre en hel brugergruppe usynlig for overvågningen som løsning på mange fejlalarmer.
Den overordnede sikkerhedspolitik skal placere ansvaret. Logvejledningen angiver den konkrete alarmmodtager og stedfortræder. Hvis modtageren kun arbejder om dagen, skal det fremgå, hvad der sker uden for den periode, og hvorfor den valgte dækning er passende.
En udfyldt kontrol fra kilde til undersøgelse
Kundeserviceportalen gennemgår et aftalt kontrolforløb med en demonstrationskonto og en fiktiv sag. Klokken 09.00 opretter administratoren en ekstra eksportrolle. Klokken 09.01 ses hændelsen centralt. Klokken 09.03 modtager den driftsansvarlige alarmen og konstaterer, at den forventede ændringsreference følger med. Klokken 09.07 fjernes rollen igen, og fjernelsen kan findes i samme tidslinje.
Kontrollen afslører imidlertid, at portalens mobilvisning ikke sender læsehændelser, selv om almindelig browservisning gør. Resultatet er derfor delvist bestået. Systemejeren får opgaven at rette den manglende dækning, og risikovurderingen afgør, om mobiladgangen kan fortsætte imens. Et grønt dashboard for serverens tilstand ville ikke have afsløret hullet.
Kontrolrapporten gemmer referencer, tidspunkter, det manglende forløb og beslutningen. Den gemmer ingen hemmeligheder eller rigtige kundebilag. Efter rettelsen gentages mobilforløbet, og resultatet forbindes med den oprindelige afvigelse. Så kan en senere gennemgang se, at problemet blev lukket i praksis.
Logs er også en behandling af medarbejderoplysninger
Formål og grundlag skal afklares, og relevante personer skal informeres. Sikkerhed er ikke en blankofuldmagt til at genbruge logdata til produktivitetsmåling. Hvis virksomheden vil undersøge medarbejderadfærd på en anden måde, kræver det en selvstændig vurdering af formål, nødvendighed, grundlag og gældende ansættelsesretlige rammer.
Planlæg også håndtering af indsigtsanmodninger. Systemet bør understøtte en afgrænset søgning efter oplysninger om den pågældende uden automatisk at udlevere andres oplysninger eller hemmeligheder. Det kræver en konkret rettighedsvurdering, ikke et generelt svar om, at sikkerhedslogs altid er undtaget.
Når en alarm viser et muligt brud på persondatasikkerheden, bruges den eksisterende brudprocedure. Loganalysen understøtter vurderingen af, hvilke oplysninger og personer der er berørt. Den er ét bevis blandt flere, og fravær af en hændelse i en ufuldstændig log beviser ikke, at adgangen aldrig fandt sted.
De danske myndighedshenvisninger er kontrolleret 8. september 2026. De udfyldte tider, roller og opbevaringsvalg er eksempler, som skal erstattes af organisationens faktiske beslutninger.