Misbrug af cloudkontoen og regningen bagefter: dokumentation til tvisten

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

Når en cloudkonto bliver misbrugt, kommer det ofte først frem som en regning, der er mange gange større end normalt. Tvisten handler derefter om, hvem der bærer udgiften: kunden, IT-leverandøren eller cloududbyderen. Den tekniske dokumentation skal kunne vise tre ting: hvilke ressourcer der skabte forbruget, hvilken identitet der oprettede dem, og hvornår misbruget kunne og burde være opdaget.

Haster det? Den indbyggede hændelseshistorik i cloudplatformene har begrænset opbevaring, i AWS 90 dage, og ressourcer, der slettes for at stoppe regningen, tager deres spor med sig. Se akut forensisk sikring; hastesager koster ekstra.

To slags data, der skal kobles

En cloudregning bygger på to datasæt, som ligger hvert sit sted og har hver sin opbevaring.

Faktureringsdata · Forbrug pr. ressource, tjeneste, region og time
Kontrolplanets auditlog · Hvem der oprettede, ændrede og slettede ressourcerne

Faktureringsdata findes i udbydernes detaljerede forbrugsrapporter, fx AWS Cost and Usage Report, eksporter fra Azure Cost Management og Google Clouds faktureringseksport. Auditloggen er CloudTrail i AWS, Activity Log i Azure og Cloud Audit Logs i Google Cloud. Den tekniske gennemgang af de tre logkilder står i AWS CloudTrail i undersøgelser og Azure Activity Log.

Koblingen sker typisk via ressource-id: Forbrugsposten nævner en virtuel maskine, et lager eller en funktion, og auditloggen viser det API-kald, der oprettede netop den ressource, med identitet, adgangsnøgle, kilde-IP og brugeragent. Uden den kobling er regningen kun et beløb. Med den bliver den til en tidslinje.

Hvad der typisk ses i et misbrug

Misbrug af en overtaget konto har ofte et genkendeligt mønster, som skal beskrives, ikke antages:

Oprettelse af mange eller store instanser, ofte med grafikkort, i regioner, virksomheden aldrig har brugt.
Forhøjelse af kvoter eller anmodninger om højere grænser kort før forbruget stiger.
Nye adgangsnøgler, nye brugere eller nye roller oprettet af den kompromitterede identitet.
Ændringer i logning, alarmer eller budgetter, der ellers ville have advaret.
Udgående netværkstrafik i store mængder, som også faktureres. Kommer trafikken fra et lager, der har været offentligt tilgængeligt, er spørgsmålet beskrevet i Eksponeret lagring: hvem tilgik dataene?.

Hvert punkt skal kunne føres tilbage til konkrete poster i auditloggen og konkrete linjer i forbrugsdata. Det er ikke nok, at mønsteret “ligner” misbrug.

Misbrug eller egen fejl?

Før forløbet kaldes misbrug, skal de almindelige forklaringer udelukkes, for det er dem, modparten vil pege på. Automatisk skalering kan oprette mange instanser ved en belastningstop eller en fejl i en sundhedstjek-regel. Glemte testmiljøer kan køre i måneder. En udvikler kan have startet store instanser til et legitimt formål i en region, ingen andre kendte. Udbyderen kan have ændret priser eller fakturering af en tjeneste.

Kontrollér derfor for hver mistænkelig ressource, om den blev oprettet af en kendt automatisering, med en kendt skabelon og fra en kendt adresse. Kan en del af forbruget forklares legitimt, skal den del trækkes ud af opgørelsen og beskrives. En opgørelse, der skelner, står stærkere end en, der tilskriver hele beløbet misbruget.

Indgangen: hvilken identitet blev brugt?

Det juridisk vigtigste spørgsmål er ofte, hvordan angriberen fik adgang. Auditloggen viser, hvilken identitet API-kaldene blev foretaget med. Er det en langtlevende adgangsnøgle, skal det undersøges, hvor nøglen har ligget: i kildekode, i en konfigurationsfil, på en udviklers computer eller i en CI-pipeline. Spor efter lækkede nøgler er beskrevet i Lækkede API-nøgler og tokens.

Er det en konsolbruger, skal det fremgå, om login skete med MFA, fra hvilken IP-adresse og med hvilken klient. Er det en federeret identitet, ligger en del af sporet i identitetsudbyderens logs og ikke i cloudkontoen.

Notér også, hvornår nøglen eller brugeren sidst blev brugt legitimt. Spændet mellem sidste legitime brug og første uautoriserede kald er et af de tal, tvisten kommer til at kredse om.

Sikring

Eksportér auditloggen for hele perioden fra før den første uautoriserede handling og frem til i dag. Den indbyggede hændelseshistorik har begrænset opbevaring, så tjek straks, om der findes en trail eller en eksport til lager eller logplatform. På tidspunktet for gennemgangen (oktober 2026) er standardopbevaringen 90 dage for CloudTrails hændelseshistorik og for Azure Activity Log. Google Cloud gemmer administrative revisionslogs i 400 dage, mens logs for dataadgang som standard er slået fra og ellers gemmes i 30 dage.
Eksportér faktureringsdata på det mest detaljerede niveau, udbyderen tilbyder, typisk pr. time og pr. ressource. En PDF-faktura er ikke nok.
Gem konfigurationen af budgetter, alarmer og notifikationer, herunder hvem der var modtagere. Sikr de sendte advarselsmails fra modtagernes postkasser.
Sikr ressourcerne, før de slettes, hvis de stadig findes: metadata, netværksregler, eventuelle diske via snapshots. Se Snapshots af cloud-diske.
Dokumentér egne indgreb: hvornår nøgler blev deaktiveret, og hvornår ressourcer blev stoppet. Dine egne handlinger optræder i den samme auditlog.

Beregn hashværdier af alle eksportfiler, og notér tidspunkt, konto, region og den identitet, der foretog eksporten.

Typiske fejlkilder

Regioner, der ikke er med i eksporten. Auditlogs kan være regionale. Er kun den sædvanlige region eksporteret, mangler misbruget.
Forsinket fakturering. Forbrugsdata opdateres med forsinkelse og kan blive justeret senere. Den eksport, der tages første dag, er ikke nødvendigvis endelig. Gem både den første og en senere version.
Kreditter og rabatter. Udbyderen kan godskrive dele af beløbet. Tvisten bør bygge på listeprisen og de faktiske posteringer, adskilt.
Delte konti i en organisation. I en organisationsstruktur kan forbruget ligge i en underkonto, mens auditloggen er centraliseret et andet sted.
Tidszoner. Faktureringsdata og auditlogs kan bruge forskellige tidsangivelser. Normalisér til UTC, og skriv det.

Hvornår kunne det være opdaget?

Ansvarsspørgsmålet afgøres sjældent af den tekniske dokumentation alene, men den tekniske dokumentation leverer grundlaget. Rekonstruér, hvilke signaler der fandtes undervejs: budgetalarmer, udbyderens egne advarsler om mistænkelig aktivitet, kvoteforhøjelser og eventuelle sikkerhedsfund i udbyderens sikkerhedstjenester. For hvert signal: hvornår blev det udsendt, til hvem, og hvad skete der derefter?

Vær præcis om, hvad der ikke kan vises. At en advarselsmail blev sendt, viser ikke, at den blev læst. At en budgetalarm ikke var sat op, viser ikke, hvem der havde ansvaret for at sætte den op. Det sidste står i aftalerne, ikke i loggen. Hvem der ejer kontoen og dataene, er behandlet fra virksomhedens side i Hvem ejer domænet, kontoen og dataene?

Hvad dokumentationen kan og ikke kan bevise

Auditlog og faktureringsdata kan sammen vise, at en bestemt identitet oprettede bestemte ressourcer på bestemte tidspunkter, og at ressourcerne skabte et bestemt forbrug. De kan ikke vise, hvem der fysisk brugte nøglen, og de kan sjældent vise, hvordan nøglen blev lækket, hvis lækket skete uden for cloudkontoen. Det skal underbygges med spor fra kodelagre, endpoints eller identitetsudbyderen, og konklusionens styrke skal afspejle, hvor mange uafhængige spor der peger samme vej.

Dokumentation til tvisten

Rapporten bør indeholde:

en tidslinje fra sidste legitime brug til fuld inddæmning, med kilde for hver post,
en tabel, der kobler forbrugslinjer til ressource-id og oprettende API-kald,
en opgørelse pr. region og tjeneste, med listepris og eventuelle kreditter adskilt,
en beskrivelse af alarmer og advarsler med tidspunkter og modtagere,
hashværdier, eksportmetode og eventuelle huller i logningen.

Hold tallene adskilt fra vurderingen af ansvar. Tvisten mellem kunde og leverandør om fordeling af tabet er en juridisk vurdering, som den tekniske rapport kun skal levere fakta til.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Undersøgelse efter et hackerangreb

Læs også: Eksponeret lagring: hvem tilgik dataene? · Hvem er logget ind på kontoen? Enheder og sessioner

→ Undersøgelse efter et hackerangreb · Haster det? Forensisk sikring (hastesager koster ekstra) · For MSP’er · 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