AWS CloudTrail i undersøgelser: sikring og fortolkning

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

AWS CloudTrail registrerer API-kald i en AWS-konto: hvem der oprettede, ændrede eller slettede ressourcer, hvornår, fra hvilken IP-adresse og med hvilken identitet. Tilsvarende kilder hos andre udbydere er Google Cloud Audit Logs og Azures Activity Log, og ved en uventet regning efter misbrug, se Misbrug af cloudkontoen og regningen bagefter. Det er den centrale kilde, når en undersøgelse handler om ændringer i et AWS-miljø, fx en slettet database, en ændret adgangspolitik eller en ny adgangsnøgle. Uden opsætning gemmes kun administrative hændelser (management events) i 90 dage i hændelseshistorikken. Hændelser om læsning og skrivning af data, fx i S3, registreres kun, hvis de er slået til, og længere opbevaring kræver en trail eller et event data store. Sikringen skal derfor begynde med at fastslå, hvad der faktisk er logget.

Haster det? Uden egen opsætning gemmer CloudTrail kun administrative hændelser i 90 dage i hændelseshistorikken, og alt ældre er væk. Ved akut behov: akut forensisk sikring; hastesager koster ekstra.

Den generelle metode for sikring via API i cloud er beskrevet i Cloud-forensic: sikring via API og administratoreksport. Her går vi i dybden med CloudTrail.

Hvad CloudTrail registrerer

Management events · Eksempler: Oprettelse af brugere, ændring af politikker, start og stop af instanser, konsollogins · Standard: Registreres, 90 dage i hændelseshistorikken
Data events · Eksempler: Læsning og skrivning af objekter i S3, kald af Lambda-funktioner · Standard: Kun hvis slået til i en trail eller et event data store
Insights events · Eksempler: Usædvanlig mængde af bestemte API-kald · Standard: Kun hvis slået til
Netværksaktivitet · Eksempler: Kald via VPC-endepunkter · Standard: Kun hvis slået til

Tabellen gengiver standardopsætningen på tidspunktet for gennemgangen (oktober 2026).

Hændelseshistorikken i konsollen er regional og kan søges og downloades, men den dækker kun management events. En trail leverer logfiler til en S3-bucket, og den kan dække alle regioner og alle konti i en organisation. CloudTrail Lake gemmer hændelser i et event data store med valgfri opbevaring og kan forespørges med SQL.

En hændelse læst felt for felt

Hver hændelse er et JSON-objekt. De vigtigste felter er:

eventTime: tidspunktet i UTC.
eventSource og eventName: tjenesten og API-kaldet, fx et kald, der sletter en bucket eller opretter en adgangsnøgle.
userIdentity: hvem der kaldte, med type (fx root, IAM-bruger, antaget rolle eller AWS-tjeneste), ARN, konto, adgangsnøglens id og ved roller oplysninger om sessionen og den rolle, der blev antaget.
sourceIPAddress: kaldets IP-adresse eller navnet på en AWS-tjeneste, hvis tjenesten kaldte på brugerens vegne.
userAgent: klienten, fx konsollen, kommandolinjeværktøjet eller et SDK.
requestParameters og responseElements: hvad der blev bedt om, og hvad der kom tilbage.
errorCode og errorMessage: om kaldet blev afvist, fx på grund af manglende rettigheder.
eventID og requestID: entydige id’er, der bruges til at henvise til hændelsen.

Identiteter og rollekæder

Det sværeste i fortolkningen er at finde ud af, hvem der stod bag et kald. Mange handlinger sker med en antaget rolle (assumed role), hvor en bruger, en tjeneste eller en ekstern identitet har fået midlertidige nøgler. Hændelsen viser rollen og sessionens navn, men ikke nødvendigvis den oprindelige person. For at finde den skal kæden følges baglæns via de kald, der antog rollen, og som er registreret som selvstændige hændelser. Ved single sign-on fører kæden til identitetsudbyderen, hvis logs også skal sikres.

Adgangsnøgler er særlige. Et kald med en langtidsnøgle viser nøglens id, som kan kobles til den IAM-bruger, nøglen tilhører. Er nøglen lækket, viser hændelsen ikke, hvem der havde den, kun hvorfra den blev brugt. Dokumentation af lækkede nøgler er beskrevet i API-nøglelækage: dokumentation.

Sikring

Fastslå opsætningen: Hvilke trails og event data stores findes, hvilke regioner og konti dækker de, er data events slået til, og hvor leveres logfilerne? Eksportér konfigurationen.
Sikr hændelseshistorikken for alle relevante regioner straks, fordi den kun dækker 90 dage.
Kopiér trailens logfiler fra S3 til et sikret sted, helst en separat konto med begrænset adgang og en bucket med versionering og objektlås i compliance-tilstand, så filerne ikke kan ændres eller slettes i en fastsat periode. Se Objektlager: adgangslogs og versionering.
Bevar digest-filerne. CloudTrail kan skrive digest-filer, der indeholder hashværdier af logfilerne og er signeret af AWS. Med dem kan det kontrolleres, at logfilerne ikke er ændret eller slettet, efter de blev leveret. Kør valideringen, og gem resultatet.
Beregn egne hashværdier for kopierne.
Dokumentér konto, roller og tidspunkter for sikringen. Undersøgerens egne kald registreres også i CloudTrail.

Integritetskontrol af logs generelt er beskrevet i Logintegritet.

Når der ikke var en trail

Har organisationen ikke haft en trail, er hændelseshistorikken de seneste 90 dage for management events ofte det eneste. Det er stadig værdifuldt: Oprettelse af adgangsnøgler, ændringer i politikker, sletning af ressourcer og konsollogins er management events. Sikr historikken for alle regioner med det samme, og opret derefter en trail eller et event data store, så hændelser fremover gemmes længere. Notér tidspunktet for oprettelsen, så det fremgår, hvorfra der er fuld logning.

Data events kan ikke genskabes bagudrettet. Er spørgsmålet, hvilke objekter i S3 der blev hentet, og var data events ikke slået til, må svaret søges i andre kilder, fx S3-serveradgangslogs, hvis de var slået til, eller i modtagerens systemer. Det skal fremgå af rapporten, at spørgsmålet ikke kan besvares fuldt ud.

Fra hændelser til tidslinje

CloudTrail-hændelser bliver først forståelige i en tidslinje. Filtrér på den identitet eller adgangsnøgle, sagen handler om, og sortér på eventTime. Føj rolleantagelser, konsollogins og relevante afviste kald til. Sammenhold derefter med identitetsudbyderens logs, VPC Flow Logs og andre kilder via IP-adresse og tidspunkt. Hver post i den endelige tidslinje bør have eventID, så den kan findes i den rå eksport.

Fejlkilder i fortolkningen

Forsinkelse: Hændelser leveres typisk inden for minutter, men ikke øjeblikkeligt. En søgning lige efter en handling kan være ufuldstændig.
Regioner: Hændelser registreres i den region, kaldet blev foretaget i. Globale tjenester, fx IAM og konsollogins, registreres i en bestemt region. Søg i alle regioner.
AWS-tjenester på brugerens vegne: Når en tjeneste handler for en bruger, kan sourceIPAddress være tjenestens navn, og der kan være flere hændelser for én brugerhandling.
Afviste kald er også hændelser. Mange afviste kald fra samme nøgle kan være tegn på, at nogen prøver sig frem med en lækket nøgle.
Manglende data events: At der ikke er hændelser om læsning fra S3, betyder ikke, at intet er læst, hvis data events ikke var slået til.
Slukket logning: Et kald, der stopper eller sletter en trail, registreres selv. Huller i leveringen skal forklares.

Hvad CloudTrail kan og ikke kan bevise

CloudTrail kan vise, at en bestemt identitet foretog et bestemt API-kald på et bestemt tidspunkt fra en bestemt adresse, og om det lykkedes. Den kan ikke vise, hvem der havde nøglerne, og den dækker kun det, der var slået til. Netværkstrafik, indhold af data og hændelser i operativsystemet på instanser kræver andre kilder, fx VPC Flow Logs, adgangslogs og diskkopier. Se Snapshots af cloud-diske som forensisk kopi.

Dokumentation til rapporten

Angiv konti, regioner og opsætning af trails og event data stores, perioder og kilder, kopiering til sikret lager med objektlås, digest-validering med resultat, hashværdier, tidszone og de rollekæder, der er fulgt for at henføre centrale kald.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Cloud- og SaaS-forensik

Læs også: Cloud-forensic: sikring via API og administratoreksport · Azure: Activity Log, Monitor og Log Analytics som bevis

→ 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