Eksponeret lagring: hvem tilgik dataene?

Forside › Undersøgelse efter et hackerangreb · Gennemgået oktober 2026 · Af John Nielsen

Når en bucket, en container eller et delt link har været offentligt tilgængeligt, skal undersøgelsen fastlægge tre ting: hvor længe dataene var eksponeret, hvilke objekter der lå der i perioden, og om nogen faktisk har hentet dem. De to første kan næsten altid besvares ud fra platformens aktivitetslog og objekternes versionshistorik. Det tredje afhænger af, om logning af adgang på objektniveau var slået til, før eksponeringen. Var den ikke det, kan hentninger hverken bekræftes eller afvises for de enkelte objekter, og konklusionen må bygge på indirekte kilder og en forsigtig afgrænsning.

Haster det? Platformens aktivitetslog har begrænset opbevaring, og ligger ændringen, der gjorde lagringen offentlig, uden for perioden, kan starttidspunktet ikke findes i loggen. Se akut forensisk sikring; hastesager koster ekstra.

De tekniske kilder til adgang og versioner i S3, Azure Blob og Google Cloud Storage er gennemgået i Objektlager (S3, Blob): adgangslogs og versionering. Her handler det om scenariet, hvor lagringen har været offentlig.

Trin 1: Hvornår blev lagringen offentlig?

Offentlig adgang opstår typisk ved en ændring af konfigurationen: en adgangspolitik, der giver alle læseadgang, en adgangsliste med offentlig læsning, en ændret indstilling for blokering af offentlig adgang, et containeradgangsniveau sat til offentligt, eller et delt link uden udløb. Sådanne ændringer er administrative handlinger og logges typisk i platformens almindelige aktivitetslog uden særlig opsætning, med tidspunkt, identitet og IP-adresse. → AWS CloudTrail og Azure Activity Log

Find både starten og slutningen af perioden. Hvis ændringen ligger før aktivitetsloggens opbevaringsperiode, kan starttidspunktet ikke findes i loggen, og andre kilder må bruges: infrastruktur-som-kode, ændringshistorik i et versionsstyringssystem eller tidspunktet, hvor bucketen blev oprettet med offentlig adgang. Notér i så fald, at starttidspunktet er et skøn. Uden ekstra opsætning er opbevaringen på tidspunktet for gennemgangen (oktober 2026) 90 dage i CloudTrails hændelseshistorik i AWS og i Azure Activity Log, mens Google Cloud gemmer de administrative revisionslogs i 400 dage.

Hvem ændrede indstillingen?

Aktivitetsloggen viser den identitet, der foretog ændringen. Det kan være en person, men ofte er det en automatisering: en udrulningspipeline, et script eller en skabelon, der opretter ressourcer med en bestemt konfiguration. I så fald skal ændringen følges videre til den commit eller den ændring i skabelonen, der indførte den offentlige adgang, og til den, der godkendte den. Formålet er at dokumentere forløbet, ikke at placere skyld. Hvem der havde ansvaret for konfigurationen, er en vurdering, der hører til et andet sted.

Trin 2: Hvad lå der i perioden?

Lav en liste over de objekter, der var tilgængelige i perioden, med navn, størrelse, oprettelses- og ændringstidspunkt. Med versionering kan tidligere versioner og slettede objekter også findes. Uden versionering viser listen kun den aktuelle tilstand, og objekter, der er slettet efter eksponeringen, mangler. Sammenhold med backups eller lagerets egne opgørelser, hvis de findes.

Listen er grundlaget for at afgøre, hvilke persondata eller forretningsdata der var eksponeret. Metoden til at afgrænse berørte persondata er beskrevet i Hvilke persondata blev berørt?

Trin 3: Blev dataene hentet?

Med adgangslogning

Var logning af dataadgang slået til, kan anonyme forespørgsler findes direkte. De står typisk med en tom eller anonym anmoder, kilde-IP, brugeragent, handling, objekt og antal bytes sendt. Skeln mellem:

listeforespørgsler, der viser, at nogen så indholdsfortegnelsen,
hentninger, der viser, at indhold blev overført, og hvor meget,
fejlede forespørgsler, fx efter at adgangen blev lukket.

Sammenlign antal bytes sendt med objektets størrelse for at se, om et objekt blev hentet helt. Gruppér efter IP-adresse og brugeragent for at se, om hentningerne kommer fra få kilder eller mange.

Uden adgangslogning

Var logningen slået fra, kan det ikke vises, om bestemte objekter blev hentet. Der findes dog indirekte kilder:

Måledata og faktura: Platformens metrikker og faktureringsdata for udgående datatrafik og antal forespørgsler pr. bucket eller lagerkonto kan vise, om der var trafik ud over det normale i perioden. De viser mængder, ikke hvem eller hvilke objekter. Detaljegrad og opbevaring varierer mellem platformene. I S3 er de daglige lagermålinger fx med uden opsætning, mens målinger af forespørgsler skal være slået til på forhånd. Hent derfor både målinger og faktureringsdata så tidligt som muligt, og notér deres tidsopløsning.
CDN-logs, hvis lagringen blev leveret gennem en CDN med egen logning.
Henvendelser udefra, fx fra en sikkerhedsforsker, der har fundet lagringen. Henvendelsen viser, at mindst én har set den, og kan indeholde oplysninger om tidspunkt og omfang.
Offentlige søgninger: Lagring, der er indekseret af søgemaskiner eller tjenester, der kortlægger offentlige buckets, har været synlig for mange.

Konklusionen bliver typisk, at dataene var tilgængelige i en bestemt periode, at det ikke kan udelukkes, at de er hentet, og hvad de indirekte kilder viser om trafikken. Det er ikke det samme som at sige, at de ikke er hentet. → Fravær af spor

Delte links og andre former for eksponering

Samme spørgsmål opstår ved delte links i OneDrive, SharePoint, Google Drive og lignende med indstillingen “alle med linket”, og ved databaser, søgeindeks eller NAS-enheder, der har været tilgængelige fra internettet. Delte links i samarbejdsplatforme logges typisk bedre end objektlager, fordi anonym adgang via links ofte fremgår af revisionsloggen. → SharePoint og OneDrive: versionshistorik og delingslinks For eksponerede databaser og servere er det databasens og serverens egne logs, der skal sikres, og de har ofte kort opbevaring.

Tidslinje og afgrænsning

Saml fundene i en tidslinje: tidspunktet, hvor lagringen blev offentlig, tidspunkter for upload af de berørte objekter, første og sidste observerede anonyme forespørgsel eller trafikstigning, eventuelle henvendelser udefra, og tidspunktet, hvor adgangen blev lukket. Et objekt, der først blev lagt op en uge før lukningen, har kun været eksponeret i den uge, selv om lagringen var offentlig i et år. Afgrænsningen pr. objekt kan derfor gøre omfanget væsentligt mindre end den samlede periode antyder, og den skal fremgå af rapporten.

Kommer der en henvendelse fra en sikkerhedsforsker eller en anden udefra, så gem den med header og alle vedhæftninger, og bed om oplysninger om, hvornår og hvordan lagringen blev fundet, og hvad der blev hentet. Svaret er en udtalelse fra en tredjepart, ikke et teknisk bevis, men det kan sammenholdes med loggene.

Sikring

Gem konfigurationen, som den var, før adgangen lukkes: politikker, adgangslister, indstillinger for offentlig adgang og logning.
Eksportér aktivitetsloggen for hele den periode, der er tilgængelig.
Kopiér adgangslogs og deres logbucket, hvis de findes, og stop automatisk sletning midlertidigt.
List alle objekter og versioner med metadata, og beregn hashværdier af kopierne.
Hent metrikker og faktureringsdata for perioden.
Luk adgangen, notér tidspunktet, og eksportér loggene igen.

Fejlkilder

Egne systemer henter også fra lagringen og kan stå som anonyme, hvis de bruger offentlige adresser.
Sikkerhedsscannere og søgemaskiner henter ofte kun en liste eller en enkelt fil og forklarer en del af trafikken.
Forsinkede logs kan mangle de seneste timer i en tidlig eksport.
Tidszoner: Platformenes logs er i UTC, mens faktureringsdata kan være opgjort i andre tidsintervaller.

Hvad der kan og ikke kan bevises

Med aktivitetslog og versionering kan perioden og indholdet næsten altid fastlægges. Med adgangslogning kan hentninger vises på objektniveau. Uden adgangslogning kan der kun siges noget om mængder og om, at adgang var mulig. Rapporten skal sige tydeligt, hvilken af situationerne der gælder. Den praktiske håndtering af fristen for underretning er beskrevet på bevissikring-digitalt.dk.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Undersøgelse efter et hackerangreb

Læs også: Lækkede API-nøgler og tokens: dokumentation af misbrug · Misbrug af cloudkontoen og regningen bagefter: dokumentation til tvisten

→ Undersøgelse efter et hackerangreb · 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