Objektlager (S3, Blob): adgangslogs og versionering

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

Objektlager som Amazon S3, Azure Blob Storage og Google Cloud Storage bruges til alt fra backup og logarkiver til kundefiler og eksportmapper. I en sag er spørgsmålet typisk, hvem der hentede, ændrede eller slettede bestemte objekter. Svaret afhænger næsten altid af, hvad der var slået til, før det skete. Adgang til selve objekterne logges ikke som standard på nogen af de tre platforme, og tidligere versioner findes kun, hvis versionering eller blød sletning var aktiveret. Begge dele skal derfor afklares, før der lægges en plan.

Objektlager er ikke det samme som de cloudlagre, medarbejdere bruger til filer, som Dropbox, OneDrive og Google Drive. Dér har tjenesten sin egen brugerflade, deling og aktivitetslog, og sikringen foregår anderledes; se Bevissikring af Dropbox og andre cloudlagre. Objektlager er en infrastrukturtjeneste, som virksomheden selv konfigurerer, og som programmer, integrationer og webapplikationer ofte tilgår uden at en person er involveret. Det gør det vigtigt at skelne mellem maskinel og menneskelig adgang, før loggen læses.

To slags logning af adgang

Hver platform har to typer kilder til adgang på objektniveau, og de er ikke ens:

AWS S3 · Platformens auditlog: CloudTrail-datahændelser for S3 · Lagerets egen adgangslog: Server access logging til en anden bucket
Azure Blob · Platformens auditlog: Ressourcelogs via diagnostikindstillinger (læs, skriv, slet) · Lagerets egen adgangslog: Ældre Storage Analytics-logning
Google Cloud Storage · Platformens auditlog: Data Access-auditlogs · Lagerets egen adgangslog: Usage logs til en bucket

Hos Azure og Google Cloud anbefaler leverandøren i dag platformens auditlog frem for de ældre, lagerspecifikke logs, som dog stadig kan være slået til i ældre opsætninger og derfor bør efterses.

Platformens auditlog er normalt den mest strukturerede og pålidelige. De lagerspecifikke adgangslogs leveres efter bedste evne: AWS skriver om S3 server access logs, at de fleste forespørgsler logges inden for få timer, men at fuldstændighed og rettidighed ikke er garanteret. Det betyder, at fravær af en linje i en sådan log vejer let. Er begge kilder til stede, bør de sammenholdes.

Handlinger på selve bucketen eller containeren, som at ændre en adgangspolitik, gøre den offentlig eller slette den, er administrative hændelser og står i platformens almindelige aktivitetslog uden særlig opsætning. Se AWS CloudTrail og Azure Activity Log.

Felterne i en adgangslog

Uanset platform indeholder en post typisk:

tidspunkt for forespørgslen,
anmoder: en IAM-identitet, en tjenesteprincipal, en kontonøgle, et delt adgangstoken eller anonym,
kilde-IP og brugeragent,
handling, fx hent, læs metadata, skriv, kopiér, slet eller list,
objektnøgle eller sti, evt. med versions-id,
HTTP-status,
bytes sendt og objektets størrelse,
forespørgsels-id, der kan bruges til at finde samme hændelse i andre logs.

Feltet med bytes sendt er vigtigt. En hentning, der er afbrudt, eller en forespørgsel på et udsnit af filen, giver færre bytes end objektets størrelse. Sammenlign derfor altid de to, før du skriver, at et objekt blev hentet i sin helhed.

Adgang via delte links og nøgler

Meget adgang til objektlager sker ikke via brugerkonti, men via midlertidige adresser og nøgler: forudsignerede adresser i S3, SAS-tokens i Azure og signerede adresser i Google Cloud Storage. Den, der har linket, behøver ingen konto. I loggen står forespørgslen typisk med den identitet eller nøgle, der signerede linket, og med den IP-adresse, der faktisk brugte det.

Det giver to fejlkilder. For det første kan en forespørgsel se ud til at komme fra en bestemt medarbejder, fordi medarbejderens identitet signerede linket, selv om linket blev sendt videre. For det andet kan adgang med en kontonøgle i Azure ikke føres tilbage til en person, fordi nøglen er fælles for hele lagerkontoen. Undersøg derfor, hvordan links og nøgler er udstedt og delt, før anmoderen tolkes som en person. Lækkede nøgler er behandlet i Lækkede API-nøgler og tokens.

Versionering og blød sletning

Når versionering er slået til, gemmes tidligere udgaver af et objekt, når det overskrives eller slettes:

S3: En sletning lægger en slettemarkør oven på objektet. De tidligere versioner ligger stadig og kan listes med deres versions-id og tidspunkt. Object Lock kan forhindre sletning i en periode.
Azure Blob: Versionering, blød sletning af blobs og containere samt snapshots af enkelte blobs kan være slået til hver for sig, med hver sin opbevaringsperiode.
Google Cloud Storage: Objektversionering bevarer ikke-aktuelle versioner, og blød sletning kan bevare slettede objekter i en periode.

Livscyklusregler kan slette gamle versioner automatisk efter et antal dage. Det er den hyppigste grund til, at en version, der fandtes for en måned siden, er væk i dag. Gem derfor livscyklusreglerne sammen med versionslisterne. Den generelle behandling af tidligere versioner i cloud findes i Tidligere versioner i cloud.

Versionslisten er i sig selv et spor: Den viser, hvornår hver version blev skrevet, og hvornår slettemarkøren blev lagt. Den viser normalt ikke, hvem der gjorde det. Det skal findes i revisions- eller adgangsloggen.

Sikring

Gem konfigurationen for de relevante buckets eller containere: logning, versionering, blød sletning, livscyklusregler, adgangspolitikker, offentlig adgang og udstedte delingspolitikker.
Stop automatisk sletning midlertidigt, hvis versioner eller logs er ved at udløbe. Det er en ændring af systemet; dokumentér tidspunkt, person og den oprindelige indstilling.
Kopiér logbucketen. Adgangslogs ligger typisk som mange små filer i en anden bucket, og den bucket har ofte sin egen livscyklusregel.
Eksportér auditlogs for perioden fra platformens logtjeneste.
List alle versioner af de relevante objekter med versions-id, størrelse, tidspunkt og kontrolsum, og kopiér de versioner, der har betydning.
Beregn hashværdier af alle kopier. Platformens egne kontrolsummer, fx ETag eller MD5-felter, er nyttige som sammenligning, men følger ikke altid samme regel. I S3 er ETag for et objekt, der er uploadet i dele (multipart upload), ikke en MD5 af hele objektet, og det gælder heller ikke for objekter krypteret med KMS-nøgler. I Google Cloud Storage har sammensatte objekter kun en CRC32C-kontrolsum. Brug derfor egne hashværdier som grundlag.

Typiske fejlkilder

List er ikke hent. En listeforespørgsel viser, at nogen så navnene på objekterne, ikke at indholdet blev hentet.
Synkroniseringsværktøjer og backup henter objekter automatisk og kan forveksles med manuel hentning.
Interne tjenester som indeksering, replikering og analyse kan stå som anmoder.
Forsinket levering betyder, at de seneste timer kan mangle i en eksport, der tages straks efter hændelsen. Tag en ny eksport senere, og sammenlign.
Tidszoner: Logs er i UTC.
Kopiering mellem buckets og replikering til en anden region kan give hentninger og skrivninger, der står med en tjenesteidentitet. De ligner dataudtræk, men er en del af driften. Slå replikeringsreglerne op, før de tolkes.

Hvad loggene kan og ikke kan bevise

Med auditlog på objektniveau kan du ofte vise, at en bestemt identitet eller nøgle hentede bestemte objekter fra en bestemt IP-adresse på et bestemt tidspunkt, og hvor mange bytes der blev sendt. Med versionering kan du vise, hvad objektet indeholdt før en ændring. Du kan ikke vise, hvad modtageren gjorde med data bagefter, og uden logning på objektniveau kan du ikke vise, om offentligt tilgængelige objekter blev hentet. Det scenarie er behandlet i Eksponeret lagring: hvem tilgik dataene?.

Dokumentation

Rapporten bør angive konto, bucket eller container, region, hvilke logkilder der fandtes, deres konfiguration og opbevaring, eksportmetode, antal poster, tidsinterval i UTC og hashværdier. Beskriv eksplicit, hvilke perioder og handlinger der ikke var dækket af logning.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Cloud- og SaaS-forensik

Læs også: Snapshots af cloud-diske som forensisk kopi · Identitetsudbydere og SSO: systemlogs som samlet login-spor

→ 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