Logintegritet: sådan vises det, at en log ikke er ændret

Forside › Netværk og logs · Gennemgået oktober 2026 · Af John Nielsen

En logfil er tekst eller strukturerede data, og den kan i princippet ændres af enhver med tilstrækkelige rettigheder. Når en log bruges som bevis, kommer spørgsmålet derfor næsten altid: Hvordan ved vi, at den ikke er redigeret? Svaret er sjældent ét bevis, men en kombination af forhold: hvor loggen er opsamlet, hvem der kunne ændre den, om den er kryptografisk låst, og om indholdet hænger sammen med andre kilder. Jo flere af disse forhold der kan dokumenteres, jo stærkere står loggen.

Den grundlæggende pointe, at administratorer ofte kan ændre lokale logs, er nævnt i Logfiler og logrotation. Her går vi i dybden med de tekniske værn, og hvordan de vises.

To tidspunkter: før og efter sikringen

Integritet handler om to perioder, som kræver forskellige argumenter:

Efter sikringen. Fra eksporten er lavet, beskyttes loggen af hashværdier og kæden af ansvar. Det er det nemme spørgsmål.
Før sikringen. I perioden mellem hændelsen og eksporten lå loggen i et system, som andre havde adgang til. Det er her, indvendingerne typisk rettes, og her de tekniske værn i kildesystemet betyder noget.

Central opsamling

En log, der sendes videre fra kildesystemet til en central opsamler i næsten realtid, er sværere at ændre end en lokal fil. For at ændre den skal man både have adgang til kilden og til opsamleren, og ændringen skal ske, før posten er sendt, eller på begge steder. Styrken afhænger af:

Forsinkelsen. Jo kortere tid fra hændelse til opsamling, jo mindre vindue for ændring.
Adskillelse af rettigheder. Hvis samme administrator styrer både kilde og opsamler, er gevinsten begrænset.
Transporten. Krypteret og autentificeret overførsel forhindrer, at poster ændres eller indsættes undervejs.

Central opsamling i et SIEM-system er beskrevet i SIEM-data som bevis.

WORM og uforanderligt lager

WORM står for write once, read many. Data i et sådant lager kan ikke ændres eller slettes i en fastsat opbevaringsperiode, heller ikke af administratorer, hvis låsen er sat i den strenge variant. Mange cloudlagre tilbyder objektlåsning med to niveauer: et, hvor særligt privilegerede konti kan ophæve låsen, og et, hvor ingen kan. I Amazon S3 hedder de governance og compliance. I Azure Blob Storage kan en ulåst tidsbaseret politik ændres eller slettes, mens en låst politik kun kan forlænges. Det skal derfor fremgå, hvilket niveau der var sat, og hvornår låsen blev aktiveret.

For at bruge WORM som argument skal det dokumenteres:

hvilket lager og hvilken låsetype der var aktiv,
hvornår låsen blev sat, og om indstillingen er ændret i perioden,
at de relevante logs faktisk blev skrevet til det låste lager i hele perioden.

Hashkæder og signerede logs

Nogle logsystemer beregner en hashværdi for hver post eller hver blok, hvor værdien også indeholder den foregående blok. Ændres en tidligere post, passer kæden ikke længere fra det punkt og frem. Andre systemer signerer blokke med en nøgle eller lader en ekstern tidsstempeltjeneste signere en hashværdi med jævne mellemrum.

Teknikken findes i flere udformninger: indbygget forsegling i visse logsystemer, digestfiler, som nogle cloudtjenester skriver for deres auditlogs, og løsninger, hvor hashværdier periodisk sendes til et separat system. Styrken afhænger af, hvor nøglen eller ankeret opbevares. Kan den samme person, der kunne ændre loggen, også genberegne hele kæden, beviser kæden kun, at ændringen skete på én gang.

Ved brug i en sag skal kæden efterprøves med et værktøj, der er uafhængigt af det system, der skrev den, og resultatet gemmes med værktøj og version. Se Hashalgoritmer i forensic.

Adgangskontrol og systemets egen log

Selv uden kryptografiske værn kan det underbygges, at en log er uændret, ved at vise, hvem der kunne ændre den, og at de ikke har gjort det:

liste over konti med skrive- eller sletterettigheder til loggen eller lageret i perioden,
systemets egen auditlog over ændringer af logkonfiguration, sletning og adgang,
logs fra et overordnet niveau, fx cloudplatformens kontrollog, der registrerer handlinger på selve lagringskontoen.

Hvis den person, sagen handler om, selv har haft administratorrettigheder, er det et svagt punkt, som skal adresseres direkte. Fremgangsmåden er behandlet i Undersøgelse af en administrator.

Intern konsistens

Indholdet af loggen kan i sig selv sige noget om dens integritet:

Fortløbende numre. Mange logformater har record-id’er eller sekvensnumre. Huller kan tyde på sletning.
Tidsforløb. Tidsstempler bør være stigende eller have forklarlige afvigelser. Spring bagud eller pludselige huller skal forklares.
Format. En manuelt redigeret linje kan afvige i feltrækkefølge, mellemrum, tegnsæt eller linjeskift.
Filsystemet. Filens tidsstempler, størrelse og placering på disken kan vise, om filen er omskrevet på et tidspunkt, der ikke passer med normal logning.

Alle disse tegn har også harmløse forklaringer: rotation, genstart, nedbrud, konfigurationsændringer. Et hul i fortløbende numre beviser ikke sletning, men det rejser et spørgsmål, som skal undersøges. Tegn på bevidst manipulation er behandlet i Anti-forensics.

Ekstern konsistens

Det stærkeste argument for integritet er ofte, at loggen stemmer med kilder, som ingen enkelt part kontrollerer. Et login i serverens lokale log, der også findes i firewallens log og i cloudtjenestens loginlog, er svært at have opdigtet. Omvendt er en hændelse, der kun findes i én lokal log, og som mangler i kilder, hvor den burde stå, et reelt problem.

Logs, der er modtaget fra andre

Ofte er det ikke den sagkyndige, der har eksporteret loggen. Den kommer fra en IT-leverandør, en SaaS-udbyder eller modparten, nogle gange som regneark eller PDF. Integriteten skal så vurderes i to led: hvordan loggen er trukket ud af kildesystemet, og hvad der er sket med den bagefter. Spørg efter eksportmetode, tidspunkt, konto og eventuel filtrering, og bed om rå data i kildeformatet, hvis det kun er et udvalg, der er leveret. Et regneark med udvalgte linjer kan være helt korrekt, men det kan ikke efterprøves for fuldstændighed, og det er let at redigere uden spor. Modtages filen med en hashværdi, bør den genberegnes ved modtagelsen og registreres.

Hvor stærkt står loggen?

En praktisk måde at vurdere integriteten på er at gennemgå værnene og spørge, hvad en ændring ville have krævet:

Lokal fil, administrator er den undersøgte · Kun adgang til én maskine
Central opsamling med adskilte rettigheder · Adgang til både kilde og opsamler inden for kort tid
WORM-lager uden mulighed for ophævelse · Ændring før skrivning, ellers praktisk umulig
Leverandørens cloudlog · Adgang til leverandørens systemer

Tabellen erstatter ikke en konkret vurdering, men den gør det tydeligt, hvor indvendingerne har vægt.

Fremgangsmåde i en sag

Beskriv logkæden fra kilde til lager, inklusive alle mellemstationer.
Kortlæg rettigheder i hver station i den relevante periode.
Dokumentér tekniske værn: WORM, hashkæder, signering, transportkryptering.
Kontrollér intern konsistens og notér afvigelser med mulige forklaringer.
Sammenhold med uafhængige kilder.
Sikr loggen med hashværdi og kæde af ansvar (chain of custody) fra eksporten og frem.

Dokumentation

Rapporten bør skelne mellem integritet før og efter sikringen og angive, hvilke værn der var til stede, og hvilke der manglede. En konklusion som “der er ikke fundet tegn på ændring” er korrekt, når kontrollerne er beskrevet. En konklusion som “loggen er uændret” kræver et værn, der rent faktisk kan vise det. Hvilken logning der bør være slået til på forhånd, er behandlet på bevissikring-digitalt.dk. Om opsætningen holder i praksis, kan afprøves som beskrevet i Forensic readiness-test.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Netværk og logs

Læs også: SIEM-data som bevis: integritet og eksport · EDR-telemetri som bevis: opbevaring og eksport

→ Logundersøgelse · Haster det? Forensisk sikring (hastesager koster ekstra) · For IT-sikkerhed og SOC · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT

Skrevet af John Nielsen, IT‑sagkyndig og indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Har været IT‑sagkyndig i danske retskredse og ved Den Fælles Europæiske Patentdomstol (UPC). Om John Nielsen · LinkedIn · Redaktionel politik