Databaser som bevis: transaktionslogs, audittabeller og binlogs

Forside › Analyse og fortolkning · Gennemgået oktober 2026 · Af John Nielsen

Spørgsmålet “hvem ændrede data, og hvornår?” kan ofte besvares af en database, men sjældent af selve tabellerne. Den aktuelle værdi i en række fortæller intet om tidligere værdier. Historikken ligger andre steder: i applikationens audittabeller, i databasens egne transaktionslogs og binære logs, i særskilt databaseaudit og i backup. Hvilke af dem der findes, og hvor langt tilbage de rækker, afhænger af systemets opsætning. Derfor er det første skridt altid at kortlægge, hvad der faktisk logges, før der lægges en plan for sikring og analyse. I standardsystemer uden databaseadgang, fx danske cloudregnskabsprogrammer, er det i stedet programmets egen ændringslog, der skal hentes; se Ændringslog og eksport i regnskabsprogrammer.

Fire lag af historik

Applikationens audit · Eksempler: Historiktabeller, felter for oprettet og ændret, ændringslog i brugerfladen · Viser typisk: Brugeren i applikationen, felt, gammel og ny værdi
Databasens versionering · Eksempler: Systemversionerede tabeller (temporal tables) · Viser typisk: Hver rækkes tidligere versioner med gyldighedsperiode
Transaktionslogs · Eksempler: SQL Servers transaktionslog, PostgreSQL WAL, MySQL og MariaDB binlog, Oracle redo- og arkivlogs · Viser typisk: Ændringer på rækkeniveau i rækkefølge, med databasebruger og transaktion
Databaseaudit og serverlogs · Eksempler: Indbygget audit, auditudvidelser, fejllog, forespørgselslog · Viser typisk: Logon, forespørgsler, skemaændringer og rettighedsændringer

Hertil kommer backup og snapshots, som viser databasens tilstand på bestemte tidspunkter. Sammenlignes to backupsæt, kan ændringer mellem dem fastlægges, selv hvis der ingen logs er.

Applikationens audit

De fleste forretningssystemer har en form for ændringslog. Den er bedst til at svare på spørgsmål om personer, fordi den registrerer brugeren i applikationen og ikke kun den tekniske konto, applikationen forbinder til databasen med. Den har to svagheder. For det første logger den kun det, udvikleren har valgt at logge. For det andet er den ofte en almindelig tabel, som kan ændres af den, der har skriverettigheder til databasen. Systemspecifikke forhold for ERP og CRM står i Audit trail i ERP-systemer og Feltlog og audit trail i CRM.

Ændringer foretaget direkte i databasen uden om applikationen, fx med et administrationsværktøj eller et script, ses ikke i applikationens audit, medmindre den bygger på triggere i databasen. Det er ofte netop de ændringer, der er interessante.

Transaktionslogs

Databasesystemer skriver ændringer i en log, før de lægges i datafilerne, så de kan genoprettes efter nedbrud. Loggen kan bruges til at se, hvilke ændringer der er sket, men hvor længe den bevares, afhænger af opsætningen:

SQL Server bevarer transaktionsloggen indtil næste logbackup, hvis databasen er i fuld gendannelsestilstand. I simpel tilstand genbruges loggen løbende. Logbackups kan være en lang række historik.
MySQL og MariaDB kan skrive en binær log (binlog) til replikering og gendannelse. I rækkebaseret format indeholder den værdierne før og efter ændringen. I sætningsbaseret format indeholder den SQL-sætningerne. Binlog slettes automatisk efter en indstillet periode. I MySQL 8 er binlog som standard slået til i rækkebaseret format og slettes efter 30 dage. I MariaDB skal den slås til.
PostgreSQL skriver WAL-filer, som kan arkiveres til gendannelse til et tidspunkt. Arkivering er som standard slået fra, og uden den genbruges WAL-filerne løbende. Indholdet er fysisk og kræver særlige værktøjer at fortolke.
Oracle har redo-logs og arkiverede redo-logs, som kan analyseres med systemets egne værktøjer.

Standardindstillinger ændres mellem versioner, så den faktiske opsætning skal aflæses på serveren og sikres sammen med loggene.

Transaktionslogs registrerer databasebrugeren, ikke personen. Bruger alle applikationens brugere samme tekniske konto, viser loggen kun, at ændringen kom fra applikationen. Kobling til en person kræver applikationens egne logs eller sessionsdata.

Databaseaudit og serverlogs

Mange databaser kan logge logon, forespørgsler og ændringer af skema og rettigheder i en særskilt audit. Den er stærk, hvis den skrives til et sted, som databaseadministratorer ikke kan ændre, fx en central logserver. Fejllogs viser mislykkede logon, genstarter og fejl, og en generel forespørgselslog, hvis den er slået til, kan vise den præcise SQL. Cloud-databaser har ofte audit, der skrives til tjenestens egen logning, uden for databasen.

Integritet

En central vurdering er, hvem der kunne ændre historikken. En databaseadministrator kan som regel ændre audittabeller, slå triggere fra og slette logs på serveren. Logs, der sendes løbende til et separat system, eller backup på uforanderlig lagring, er derfor stærkere. Se Logintegritet. Er undersøgelsen rettet mod en administrator, skal kilderne vælges, så de ikke alene ligger i den pågældendes kontrol.

Kortlægning før sikring

Før noget sikres, skal systemets logning beskrives. Det kræver som regel en samtale med den, der drifter databasen, og et kig i konfigurationen. Spørgsmålene er blandt andet:

Hvilket databasesystem og hvilken version kører, og er det en enkelt server, en klynge eller en cloudtjeneste?
Hvilken gendannelsestilstand er sat, og hvor længe bevares transaktionslogs, binlog eller WAL-arkiv?
Findes der logbackups eller arkiver, og hvor langt tilbage?
Har applikationen egen ændringslog, og hvilke tabeller og felter dækker den?
Er databaseaudit slået til, og hvor skrives den hen?
Hvilke konti har skriveadgang, og hvem kender adgangskoderne til dem?
Hvilke job, integrationer og scripts ændrer data automatisk?

Svarene afgør, hvor langt tilbage historikken kan nå, og hvilke kilder der haster mest. Kortlægningen er en del af den generelle identifikation af datakilder, se Identifikation af datakilder. Skriv svarene ned med dato og kilde, fordi de senere skal kunne efterprøves.

Sikring

Sikringen planlægges, før nogen gør noget ved databasen. Logs kan rulle over, og en genstart eller gendannelse kan ændre transaktionslogs. Typisk sikres:

databasen i en konsistent tilstand, se Konsistent sikring af en database,
transaktionslogs, binlog eller arkiverede WAL-filer for perioden, med opsætningen, der viser formatet,
audittabeller og databaseaudit, inklusive indstillinger for, hvad der logges,
backupsæt fra før og efter det relevante tidsrum,
applikationens egne logs og webserverlogs, som kobler til personer.

Notér databaseversion, opsætning, serverens tidszone og ur, og beregn hashværdier for alle filer.

Analyse

Ændringer sammenholdes på tværs af lagene. En ændring, der ses i transaktionsloggen, men ikke i applikationens audit, tyder på en ændring uden om applikationen. En ændring i applikationens audit uden tilsvarende transaktion skal forklares. Sammenligning af to backupsæt kan vise, hvilke rækker der er ændret, selv når logs mangler. Kronologien bygges på tværs af kilderne, se Logkorrelation.

Typiske fejlkilder

Teknisk bruger som person. En databasebruger er ikke en person.
Serverens tidszone. Databaser kan gemme tid uden tidszone, i serverens lokale tid eller i UTC, og applikationen kan konvertere.
Replikering og failover. Ændringer kan være sket på en anden node end den, der undersøges.
Batchjob og integrationer laver ændringer, der ligner manuelle.
Logisk sletning. Mange systemer markerer rækker som slettede med et felt i stedet for at fjerne dem. En række, der ikke vises i brugerfladen, kan stadig ligge i tabellen, og omvendt kan en fysisk sletning være sket uden spor i brugerfladen.
Gendannelse. En database, der er gendannet fra backup, har fået historik, der skal forklares.

Hvad databasen kan og ikke kan bevise

Logs og audit kan vise, hvilke data der er ændret, i hvilken rækkefølge, og fra hvilken konto og forbindelse. Med applikationens logs kan ændringen ofte knyttes til en bruger i systemet. Uden logs kan sammenligning af backup indkredse, hvornår en ændring skete, men ikke hvem der lavede den. Manglende historik er ikke et bevis for, at intet er ændret.

I rapporten

Beskriv systemet, versionen og opsætningen af logning, kilderne med hashværdier og tidszone, og metoden til at fortolke logs. Gengiv relevante ændringer med kilde, transaktion, bruger, gammel og ny værdi og tidspunkt.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Analyse og fortolkning

Læs også: Browsercache, cookies og gemte sessioner som spor · Konsistent sikring af en database: dump, snapshot eller kopi

→ Digital forensics-undersøgelse · For IT-afdelingen · 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