Snapshots af cloud‑diske som forensisk kopi

Forside › Cloud- og SaaS-forensik · Gennemgået oktober 2026 · Af John Nielsen

Et snapshot af en administreret disk i AWS, Azure eller Google Cloud er den hurtigste og mindst forstyrrende måde at bevare en virtuel maskines data på. Men det er ikke en forensisk kopi i klassisk forstand. Du har ingen adgang til det fysiske medie, snapshottet ligger hos leverandøren i et format, du ikke kan se, og du kan ikke beregne en hashværdi direkte af det. Snapshottet er en bevaringshandling. Den egentlige beviskopi opstår først, når data fra snapshottet eksporteres eller læses ud til en fil, som kan hashes og efterprøves.

Hvordan snapshots virker på lokale hypervisorer, og hvordan konsistens og hukommelse håndteres, er beskrevet i Virtuelle maskiner og servere. Her gennemgås det, der er særligt for cloud.

Hvad et snapshot indeholder

Et snapshot af en administreret disk er en kopi på blokniveau af den virtuelle disk på et bestemt tidspunkt. Det betyder:

Hele den virtuelle disk er med, også ikke-allokeret plads inden for diskens adresserum, partitionstabel og filsystemets metadata.
Leverandørens fysiske lag er ikke med. Data, der er slettet og frigivet på platformens lager, kan ikke hentes frem, og blokke, der aldrig er skrevet, eller som er frigivet med TRIM, returneres typisk som nuller.
Hukommelsen er ikke med. Kørende processer, netværksforbindelser og nøgler i RAM skal sikres separat og før eventuel nedlukning. Endnu mere flygtigt er det i containere; se Containere og Kubernetes. Se Hukommelsessikring (RAM).
Midlertidige diske er ofte ikke med. Mange maskintyper har lokale, flygtige diske, der ikke kan snapshottes og forsvinder, når maskinen stoppes eller flyttes. De hedder instance store hos AWS, midlertidig disk (temporary disk) hos Azure og Local SSD hos Google Cloud.

Internt gemmer platformene snapshots inkrementelt, så kun ændrede blokke lagres efter det første. Det er usynligt for brugeren: Hvert snapshot fremstår som en komplet disk.

Konsistens

Et snapshot af en kørende maskine er som udgangspunkt crash-konsistent. Har maskinen flere diske, fx en til system og en til data, bør de tages samlet, hvis platformen understøtter det, ellers kan de afspejle forskellige tidspunkter. Notér for hver disk det tidspunkt, platformen angiver for snapshottet, ikke tidspunktet for din kommando.

Hvorfor hash er et særligt problem

Ved en klassisk forensisk kopi beregnes hashværdien af kildemediet og af kopien, og de skal stemme. Ved et cloud-snapshot findes der ingen kilde, du kan læse bit for bit uden om platformen. Hashværdien kan derfor kun beregnes på det, der kommer ud:

Eksport til fil. Platformene har forskellige veje til at hente en disk ud som en fil, fx som VHD eller raw-billede, direkte eller via en midlertidig adresse. Hashværdien beregnes af den eksporterede fil.
Ny disk fra snapshottet. Snapshottet gendannes som en ny disk, der monteres skrivebeskyttet på en forensisk arbejdsmaskine i samme miljø, og der laves et image derfra i E01, AFF4 eller raw. Hashværdien beregnes af imaget og af den monterede disk.

Eksempler på eksportveje: Hos Azure kan en snapshot hentes som VHD via en tidsbegrænset SAS-adresse. Hos AWS kan blokkene i et EBS-snapshot læses direkte med EBS direct API’erne. Hos Google Cloud kan der laves et image af snapshottet, som eksporteres til Cloud Storage. Den hurtigste og mest udbredte vej er dog ofte nr. 2.

I begge tilfælde dokumenterer hashværdien kopien fra det tidspunkt, den blev læst ud af snapshottet. Koblingen bagud, fra snapshot til den oprindelige disk, hviler på platformens metadata: snapshot-id, kildediskens id, tidspunkt og den handling, der står i platformens aktivitetslog. Valget af format til imaget er beskrevet i Forensiske diskformater: RAW, E01 og AFF4.

Fremgangsmåde

Dokumentér maskinen: konto eller abonnement, region, instans- eller maskin-id, tilknyttede diske med id og størrelse, krypteringsnøgler og eksisterende snapshots.
Sikr hukommelse og flygtige data først, hvis maskinen kører, og det er relevant.
Opret snapshots af alle relevante diske, så samtidigt som platformen tillader.
Beskyt snapshottet mod sletning med de mekanismer, platformen har, fx ressourcelåse eller snapshot-låsning. Notér hvilke.
Kopiér eller del snapshottet til en separat forensisk konto eller et adgangsbegrænset abonnement. Krypterede snapshots kræver, at den forensiske konto får adgang til nøglen; ellers kan kopien ikke læses.
Eksportér eller læs ud til et image, og beregn hashværdier. Se Hashalgoritmer i forensic.
Hent platformens aktivitetslog for alle handlingerne, så sikringen kan dokumenteres med leverandørens egne tidsstempler. Se AWS CloudTrail i undersøgelser.

Når driften eller leverandøren tager snapshottet

Ofte er det ikke den sagkyndige, der har rettighederne i kundens cloudmiljø, men kundens egen drift eller en MSP. Det er i orden, hvis rollefordelingen er klar. Giv en skriftlig instruks med de diske, der skal sikres, og bed om, at personen noterer tidspunkt, id’er og egne handlinger. Hent derefter aktivitetsloggen, der viser, hvilken konto der faktisk udførte handlingerne. Så kan du senere dokumentere, at snapshottet blev taget som beskrevet, uden at du selv havde administratoradgang.

Snapshots, som driften har taget af andre grunde, fx før en opdatering eller som led i backup, kan være værdifulde, fordi de viser en tidligere tilstand. Registrér dem med id og tidspunkt, beskyt dem mod sletning, og behandl dem som selvstændige kilder.

Kryptering

Administrerede diske er krypteret på platformen, med leverandørens nøgler eller kundens egne. For sikringen betyder platformskryptering normalt ikke noget, fordi data læses dekrypteret gennem platformen. Er disken derimod krypteret inde i gæstesystemet, fx med BitLocker eller LUKS, er snapshottet krypteret indhold, og nøglen eller gendannelsesnøglen skal skaffes ad lovlig vej. Notér krypteringsstatus i begge lag.

Fejlkilder

Snapshottet slettes af en automatisk opbevaringspolitik eller af driften, der rydder op. Beskyt det med det samme.
Ny disk monteres skrivbart, og gæstesystemets automatiske processer ændrer filsystemet. Montér skrivebeskyttet, og dokumentér hvordan.
Forkert disk. Ved mange maskiner med ens navne er det let at tage den forkerte. Brug id’er, ikke navne.
Tidsforskel mellem snapshottets tidsstempel og maskinens eget ur. Notér begge.
Region og datalokation. Kopiering til en anden region kan være uønsket af hensyn til persondata. Afklar det, før kopien laves.

Er det forensically sound?

Ja, når fremgangsmåden er beskrevet, påvirkningen af kildesystemet er kendt og begrænset, og kopien kan verificeres fra eksporten og frem. Det centrale er ærlighed om, hvad der ikke er med: fysisk lag, hukommelse og flygtige diske. Begrebet er forklaret i Forensically sound, og forskellen på en almindelig og en forensisk kopi for ikke-teknikere i Hvad er en forensisk kopi?.

Hvad snapshottet kan og ikke kan bevise

Et korrekt dokumenteret snapshot kan vise diskens indhold på et tidspunkt, som platformen selv har registreret. Det kan bære analyser af filsystem, logs og artefakter på samme måde som et image af en fysisk disk. Det kan ikke vise noget om data, der var slettet og frigivet på platformens lager, og det siger intet om, hvad der lå i hukommelsen.

Dokumentation

Notér i sikringsloggen: konto, region, ressource-id’er, snapshot-id’er, tidspunkter fra platformen, hvem der udførte hver handling, beskyttelse mod sletning, eksportmetode, format, værktøj og version, hashværdier af eksporten og af imaget, og eventuelle afvigelser. Vedlæg platformens aktivitetslog for handlingerne, så en anden sagkyndig kan følge kæden fra den oprindelige disk til beviskopien.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Cloud- og SaaS-forensik

Læs også: Google Cloud Audit Logs i undersøgelser · Objektlager (S3, Blob): adgangslogs og versionering

→ 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