Cloud‑forensic: sikring via API og administratoreksport

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

En harddisk kan kopieres bit for bit. Det kan en cloudtjeneste ikke. Data i Microsoft 365, Google Workspace, Dropbox eller et CRM-system ligger på leverandørens servere og kan kun hentes gennem de grænseflader, leverandøren stiller til rådighed: administratorværktøjer, API’er og brugereksport. Det ændrer både metoden og den måde, integritet og fuldstændighed skal dokumenteres på.

Hubben gennemgår de enkelte tjenester fra brugerens side, fx Bevissikring af OneDrive, SharePoint og Teams. Her ser vi på de tekniske principper, der går igen på tværs af tjenesterne.

Tre veje til cloud-data

Administratoreksport · Kendetegn: Indbyggede eDiscovery- eller eksportværktøjer, understøttet af leverandøren · Typisk begrænsning: Kræver administratoradgang og ofte bestemte licenser
API-indsamling · Kendetegn: Forensiske værktøjer henter data via leverandørens API, ofte med hashværdi pr. element · Typisk begrænsning: Kaldbegrænsninger og huller i, hvad API’et udleverer
Brugereksport · Kendetegn: Brugerens egen eksportfunktion · Typisk begrænsning: Mindre kontrol og færre metadata

Valget afhænger af, hvem der lovligt råder over kontoen, hvilke licenser der findes, og hvilke spørgsmål sagen skal besvare.

Administratoreksport

I Microsoft 365 sker det typisk via Microsoft Purview eDiscovery, hvor man kan sætte hold, søge og eksportere; se Microsoft Purview eDiscovery. I Google Workspace sker det via Google Vault, afhængigt af abonnementet; se Google Vault og auditlogs.

Fordelen er, at værktøjerne er bygget til formålet og bevarer centrale metadata, fx afsender, modtagere, tidspunkter og placering. Ulempen er, at de afspejler leverandørens datamodel. Det, der ikke er med i eksportformatet, findes ikke i eksporten, også selvom tjenesten internt kender det.

API-indsamling

Forensiske indsamlingsværktøjer kan hente data direkte via tjenestens API med en konto eller en app-registrering, der har de nødvendige rettigheder. Fordelene er, at indsamlingen kan afgrænses præcist, at hvert element kan hashes ved modtagelsen, og at værktøjet logger, hvad der er hentet og hvornår.

Vær opmærksom på:

Rettigheder: Kontoen eller appen skal have netop de rettigheder, der skal bruges, ikke mere. Hvilke rettigheder der er givet, af hvem og hvornår, skal dokumenteres, og de bør fjernes, når indsamlingen er slut.
Kaldbegrænsninger: Leverandørerne begrænser antallet af kald pr. tidsenhed. Store indsamlinger tager tid, og værktøjet skal kunne genoptage uden at miste eller dublere elementer.
Fuldstændighed: Ikke alle data er tilgængelige via API, fx visse metadata, versionshistorik eller elementer i papirkurve.
Ændringer undervejs: Kontoen er levende. Elementer kan ændres eller slettes, mens indsamlingen kører. Et hold bør derfor sættes før indsamlingen, hvis tjenesten tilbyder det.

Mindre SaaS-systemer

Mange forretningssystemer, fx CRM, projektstyring og regnskab, har hverken eDiscovery eller et dokumenteret API til indsamling. Så må man arbejde med de muligheder, systemet har: eksport af rapporter eller tabeller, systemets egen aktivitetslog, eller en eksport, som leverandøren udfører efter anmodning. Hver mulighed har sine huller. En rapporteksport viser ofte kun aktuelle værdier, ikke historikken bag dem, og en leverandøreksport er svær at efterprøve.

I de tilfælde er det særlig vigtigt at dokumentere forløbet trin for trin, gerne med skærmoptagelse, og at hashe hver eksportfil straks. Spørg leverandøren skriftligt, hvilke data og logs der findes, hvor længe de gemmes, og om de kan udleveres i et format med tidsstempler. Svaret indgår i dokumentationen. Hvis leverandøren skal bevare data, bør anmodningen komme hurtigt, fordi logs i mindre systemer ofte har kort levetid.

Brugerens egen eksport

Når en privatperson eller en mindre virksomhed ikke har administratorværktøjer, kan brugerens egen eksport være eneste mulighed. Den bør ske under vejledning, helst med skærmoptagelse af forløbet, gemmes uændret og hashes straks efter download. Det er ikke en fuld forensisk sikring, men den er langt bedre end skærmbilleder; se Hvorfor skærmbilleder sjældent er nok.

Integritet uden original disk

Da der ikke er en “original disk”, kan man ikke vise, at kopien er identisk med originalen ved at sammenligne to hashværdier af samme medie. I stedet opbygges integriteten af flere dele:

hashværdier for hvert indsamlet element og for den samlede eksport, beregnet straks ved modtagelsen,
værktøj, version og indstillinger,
tidspunkt for start og afslutning af indsamlingen,
den konto, de rettigheder og den IP-adresse, der er brugt,
værktøjets egen log over kald, fejl og antal elementer,
tjenestens auditlog, som viser, at indsamlingen fandt sted, og hvad kontoen gjorde.

Den sidste kilde overses ofte. Auditloggen kan dokumentere indsamlingen uafhængigt af indsamlingsværktøjet. I Microsoft 365 er det Unified Audit Log.

Fuldstændighed

Spørgsmålet “har vi fået det hele?” er sværere i cloud end på en disk. Tiltag:

Sammenlign antal elementer og samlet størrelse i kilden med eksporten.
Notér alle fejl og elementer, der ikke kunne eksporteres, og forklar hvorfor.
Undersøg opbevaringspolitikker, der automatisk kan have fjernet data før indsamlingen.
Sikr auditloggen, som kan vise sletninger, og hvem der foretog dem.
Kontrollér, om der findes delte drev, gruppepostkasser eller kanaler, som brugerens egen konto ikke ejer.

Tidsstempler

Cloudtjenester gemmer typisk tidsstempler i UTC. Eksportformater og visningsværktøjer kan konvertere til lokal tid, og ikke altid konsekvent. Forskellige tidsstempler kan også betyde forskellige ting: hvornår et element blev oprettet i tjenesten, hvornår det blev uploadet, og hvornår den oprindelige fil blev oprettet på en lokal computer. Dokumentér, hvilken tidszone rapporten bruger, og hvilket tidsstempel der er tale om; se Tidslinjeanalyse.

Typiske fejlkilder i fortolkningen

Synkronisering: En fil i en cloudmappe kan være lagt der af en synkroniseringsklient, ikke af en bevidst handling.
Delte elementer: At et dokument ligger i en brugers visning, betyder ikke, at brugeren ejer det eller har åbnet det.
Eksportens egne ændringer: Konvertering af formater kan ændre filnavne, tegnsæt og metadata. Dokumentér eksportindstillingerne.
Versioner: Den eksporterede version er ofte kun den seneste. Ældre versioner skal hentes særskilt, hvis de findes.

Adgang og grundlag

Data kan ligge i datacentre uden for Danmark, og adgang til en anden persons eller virksomheds cloud-konto kræver et klart grundlag. Det gælder også, når en virksomhed indsamler fra egne medarbejderes konti. Indsamling uden fornødent grundlag kan i sig selv blive et problem i sagen. Den juridiske side er beskrevet i Beviser i cloud uden for EU og GDPR og bevisførelse.

Hvad cloud-sikringen kan og ikke kan bevise

En korrekt dokumenteret cloud-sikring kan vise, hvad der lå i tjenesten på indsamlingstidspunktet, og sammen med auditloggen, hvad der er sket med elementerne i opbevaringsperioden. Den kan ikke vise, hvad der skete med en fil lokalt efter download. Cloud-data og data på enheder supplerer derfor hinanden: OneDrive kan vise, at en fil blev hentet; computeren kan vise, hvad der derefter skete med den.

Dokumentation til rapporten

Beskriv metode og begrundelse for valget, kilder og afgrænsning, konto og rettigheder, værktøj og version, tidsrum, antal elementer, fejl, hashværdier og tidszone. Beskriv også, hvad der ikke kunne indsamles, så læseren kan vurdere, om der er huller, der har betydning for konklusionerne.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Cloud- og SaaS-forensik

Læs også: Adgangskodeadministratorer: auditlogs ved fratræden · AWS CloudTrail i undersøgelser: sikring og fortolkning

→ Logundersøgelse · Haster det? Forensisk sikring (hastesager koster ekstra) · 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