Virtuelle maskiner og servere: forensisk sikring uden nedetid

Forside › macOS- og Linux-forensik · Gennemgået oktober 2026 · Af John Nielsen

En server, der driver virksomhedens ERP-system, mailserver eller webshop, kan sjældent slukkes for at blive kopieret. Kravet i civile sager er derfor ofte, at sikringen sker uden nedetid. De fleste servere kører i dag som virtuelle maskiner, og det giver gode muligheder: Med et snapshot kan diskens tilstand fryses på et kendt tidspunkt og kopieres, mens maskinen fortsætter. For fysiske servere er mulighederne mere begrænsede, og forbeholdene skal fremgå tydeligt af dokumentationen.

Hvad en virtuel maskine består af

En virtuel maskine (VM) er et sæt filer på hypervisorens lager: virtuelle diske, en konfigurationsfil, eventuelle snapshotfiler og logs fra hypervisoren. Maskinen kan derfor sikres ved at kopiere filerne, når de er i en konsistent tilstand.

VMware vSphere og ESXi · vmdk (beskrivelsesfil og datafil)
Microsoft Hyper-V · vhdx og avhdx for snapshots
KVM og Proxmox · qcow2 eller raw
Cloud (Azure, AWS, Google Cloud) · Administrerede diske og snapshots

Diskfilerne kan være tyndt allokerede, så de fylder mindre end den virtuelle disk. Det har betydning for hashværdier: Hashværdien af en tyndt allokeret vmdk-fil er ikke den samme som hashværdien af den virtuelle disk, maskinen ser. Rapporten skal angive præcis, hvad der er hashet. Om forholdet mellem containerformater og indhold, se Forensiske diskformater.

Snapshots

Et snapshot fryser diskens tilstand på et tidspunkt. Ændringer efter snapshottet skrives til en separat differensfil, og den oprindelige diskfil står stille. Den frosne fil kan derefter kopieres, mens maskinen kører videre.

Fremgangsmåden i hovedtræk:

Dokumentér maskinen: navn, hypervisor og version, antal og størrelse af diske, eksisterende snapshots, tidspunkt og tidskilde.
Opret et snapshot. Tag stilling til, om hukommelsen skal med.
Kopiér de frosne diskfiler til et forensisk lager med adgangskontrol.
Beregn hashværdier for de kopierede filer, og helst også for den virtuelle disk, når den er konverteret eller monteret skrivebeskyttet. Se Hashalgoritmer i forensic.
Fjern snapshottet efter aftale med driften, så produktionen ikke påvirkes af voksende differensfiler.
Notér alle handlinger med tidspunkt i sikringsloggen.

Et snapshot ændrer selv systemet en smule. Der oprettes filer på lageret, hypervisoren skriver logposter, og gæstesystemet kan registrere en kort pause eller en anmodning om at tømme skrivebuffere. Det er en kendt og begrænset påvirkning, og den dokumenteres som en del af metoden.

Eksisterende snapshots bør også registreres. De kan indeholde en tidligere tilstand af maskinen og kan i sig selv være værdifulde, men de må ikke slettes eller sammenlægges som led i sikringen.

Konsistens

Et snapshot af en kørende database er som udgangspunkt crash-konsistent: det svarer til, at strømmen blev afbrudt på det tidspunkt. Til bevisformål er det normalt tilstrækkeligt, fordi formålet er at bevare data, ikke at genstarte systemet. Databaser er bygget til at kunne genoprette sig fra den tilstand.

Hypervisorer kan også lave applikationskonsistente snapshots, hvor gæstesystemet bliver bedt om at skrive alle data til disk først. Det kræver integrationsværktøjer i gæsten og ændrer lidt mere på systemet. Skal en database åbnes og analyseres i detaljer, kan en eksport fra databasesystemet være et nyttigt supplement til diskkopien, men ikke en erstatning for den.

Hukommelse

Nogle hypervisorer kan gemme maskinens hukommelse sammen med snapshottet eller ved suspendering. Hukommelsesfilen kan analyseres som en almindelig hukommelsessikring. Det er relevant, hvis flygtige data som netværksforbindelser, kørende processer eller krypteringsnøgler til en krypteret disk er vigtige. Virtuelle skriveborde har deres egne udfordringer; se VDI og Citrix. Hukommelsen kan indeholde følsomme oplysninger, som skal håndteres med samme omhu som diskdata. Se Hukommelsessikring (RAM).

Fysiske servere i drift

Er serveren fysisk, og må den ikke slukkes, er mulighederne:

Live-kopi af disken med et forensisk værktøj, mens systemet kører. Kopien er ikke et øjebliksbillede, fordi data ændres undervejs. Hashværdien dokumenterer kopien, ikke originalen, og det skal fremgå af rapporten.
Målrettet sikring af relevante mapper, databaser og logs, når en fuld kopi ikke er proportional eller praktisk mulig.
Kopi fra lagersystemet, fx snapshots på et SAN eller NAS, som giver et konsistent øjebliksbillede uden at røre serveren.
Gendannelse fra backup til et isoleret miljø, hvis backup dækker den relevante periode.

Er disken krypteret, skal nøglen eller gendannelsesnøglen fremskaffes ad lovlig vej via ejeren eller administratoren, før en live-kopi giver mening. Er hypervisoren selv krypteret, se Krypterede servere og hypervisorer. Se BitLocker og FileVault.

Cloud

I cloud tages snapshots af administrerede diske via platformens konsol, kommandolinje eller API. Snapshottet kan derefter kopieres til en separat konto eller et adgangsbegrænset område og eksporteres. Notér region, abonnement eller konto, ressource-id’er og hvem der har udført handlingerne. Platformens aktivitetslog registrerer selv handlingerne og kan fremlægges som dokumentation for sikringen. Se Cloud-forensic.

Logs på serveren og hypervisoren

Serverens logs roterer, og hypervisorens egne logs gør det samme. Hypervisorloggen kan vise, hvornår maskinen er startet, flyttet, ændret eller snapshottet, og hvilken konto der gjorde det. Sikr begge som en del af opgaven, også selvom diskkopien indeholder gæstens logs, så de er let tilgængelige og ikke overskrives i mellemtiden. Se Logfiler og logrotation.

Hvem udfører handlingerne?

Ofte er det driftsleverandøren, der har adgangen til hypervisoren eller cloudkontoen. Den IT-sagkyndige kan instruere og overvære, få midlertidig adgang med en navngiven konto, eller modtage de kopierede filer sammen med leverandørens dokumentation. Er leverandøren selv part i sagen, eller kan leverandørens handlinger være en del af det, der undersøges, bør sikringen ske under uvildig kontrol, og alle handlinger på systemet bør kunne genfindes i en log.

Kontrol af kopien

En sikring er først færdig, når kopien er kontrolleret. For virtuelle maskiner betyder det i praksis:

Montér eller åbn den kopierede disk skrivebeskyttet i et analysemiljø, og kontrollér, at partitionstabel og filsystemer kan læses.
Sammenlign diskstørrelse, antal partitioner og filsystemernes størrelse med de oplysninger, der blev noteret om maskinen før sikringen.
Kontrollér, at seneste aktivitet i gæstens logs svarer til tidspunktet for snapshottet. En kopi, hvor de seneste logposter er flere dage ældre end snapshottet, tyder på, at den forkerte fil er kopieret.
Beregn hashværdien igen på arbejdskopien, og sammenlign med den værdi, der blev beregnet ved sikringen.

Kontrollen dokumenteres på samme måde som selve sikringen. Opdages en fejl, er det langt bedre at gentage sikringen, mens snapshottet eller systemet stadig findes, end at opdage den, når analysen er i gang.

Typiske fejlkilder

Snapshottet tages, men de kopierede filer er differensfiler uden den underliggende basisdisk.
Maskinen har flere diske, og kun systemdisken sikres.
Tidszonen på hypervisoren afviger fra gæstens tidszone, og tidspunkterne i sikringsloggen kan ikke sammenholdes.
Et snapshot efterlades og vokser, til lageret løber fuldt og produktionen stopper.
Diskfilen kopieres, mens maskinen kører uden snapshot. Kopien bliver inkonsistent og kan i værste fald ikke åbnes.

Fælles for fejlene er, at de kan undgås med en kort tjekliste og en aftale med driften om, hvem der gør hvad og hvornår.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: macOS- og Linux-forensik

Læs også: macOS-artefakter i undersøgelser · Sikring af moderne Mac: Apple silicon, T2 og logisk sikring

→ Forensisk undersøgelse af en computer · 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