Forside › Cloud- og SaaS-forensik · Gennemgået oktober 2026 · Af John Nielsen
Google Cloud skriver auditlogs for de fleste tjenester, men ikke alle typer er slået til fra start. Administrative handlinger, som at oprette en virtuel maskine, ændre en IAM-rolle eller slette en bucket, logges altid. Læsning af data, som at hente et objekt fra Cloud Storage eller læse en hemmelighed, logges som udgangspunkt kun, hvis nogen har slået det til. Før du lover noget om, hvad loggen kan vise, skal du derfor kende konfigurationen i det konkrete projekt i den relevante periode.
De fire logtyper
- Admin Activity · Handlinger, der ændrer konfiguration eller metadata for ressourcer. Altid slået til
- Data Access · Læsning af konfiguration og læsning eller skrivning af brugerdata. Som udgangspunkt slået fra for de fleste tjenester
- System Event · Handlinger, som Google selv udfører på ressourcer, fx automatisk flytning af en maskine
- Policy Denied · Forespørgsler, der blev afvist på grund af en sikkerhedspolitik
Data Access er den logtype, sagen ofte har brug for, og den, der oftest mangler. Den kan give store datamængder og dermed omkostninger, og derfor er den mange steder kun slået til for udvalgte tjenester eller slet ikke. Data Access er som standard slået fra for de fleste tjenester. BigQuery er den kendte undtagelse: Her skrives Data Access-logs som standard, og de kan ikke slås fra på samme måde som for andre tjenester.
Google Workspace har sine egne auditlogs i administrationskonsollen og er et andet system. De behandles i Google Workspace-forensik.
Hvor loggene ligger
Auditlogs skrives til Cloud Logging, hvor de lander i logbuckets på projekt-, mappe- eller organisationsniveau. To buckets findes fra start:
- _Required indeholder blandt andet Admin Activity og System Event. Opbevaringen er fast og kan ikke ændres.
- _Default indeholder blandt andet Data Access. Opbevaringen kan konfigureres.
På tidspunktet for gennemgangen (oktober 2026) opbevares _Required i 400 dage, mens _Default som standard opbevares i 30 dage, medmindre perioden er ændret.
Derudover kan der være oprettet sinks, der sender kopier af logs til Cloud Storage, BigQuery eller Pub/Sub og videre til et SIEM-system. En sink kan dække længere tid end bucketen, og den er ofte den eneste kilde til ældre Data Access-logs. Sinks kan også være sat op på organisationsniveau, så logs fra alle projekter samles ét sted. Spørg efter dem tidligt.
Felterne
En revisionspost er struktureret som JSON. De vigtigste felter er:
- protoPayload.authenticationInfo.principalEmail: den bruger eller tjenestekonto, der udførte handlingen.
- protoPayload.methodName og
serviceName: hvilken handling i hvilken tjeneste. - protoPayload.resourceName: den ressource, handlingen ramte.
- protoPayload.requestMetadata.callerIp og
callerSuppliedUserAgent: afsenderens IP-adresse og den klient, der blev oplyst. - protoPayload.status: om handlingen lykkedes, og evt. fejlkode.
- timestamp og
receiveTimestamp: hvornår hændelsen skete, og hvornår Cloud Logging modtog den. insertId: et id, der gør posten entydig og kan bruges til at fjerne dubletter.
Når en tjenestekonto handler på vegne af en anden identitet, kan der være oplysninger om delegering eller impersonering i feltet protoPayload.authenticationInfo.serviceAccountDelegationInfo, som viser kæden af identiteter. Det er afgørende for at kunne føre en handling tilbage fra en tjenestekonto til den bruger, der startede kæden.
Typiske spørgsmål og de logs, der kan besvare dem
- Hvem gav en ekstern konto adgang til projektet? · Admin Activity (IAM-ændringer)
- Hvem oprettede en nøgle til en tjenestekonto? · Admin Activity
- Blev objekterne i en bucket hentet? · Data Access, hvis slået til for Cloud Storage
- Hvem slettede en virtuel maskine eller en disk? · Admin Activity
- Forsøgte nogen at gå uden om en organisationspolitik? · Policy Denied
Tabellen er en tommelfingerregel. Hvilke metoder der hører til hvilken logtype, varierer mellem tjenester, og nogle læsninger af metadata regnes som Data Access, ikke Admin Activity. Slå den konkrete metode op, før en konklusion bygges på, at den burde stå i en bestemt log. En nøgle til en tjenestekonto er i øvrigt et særligt følsomt spor: Den kan bruges uden for Google Cloud, og efterfølgende brug af den optræder kun som kald fra tjenestekontoen.
Sikring
- Kortlæg hierarkiet: organisation, mapper og projekter. Notér projekt-id’er og hvilke buckets og sinks der findes.
- Gem konfigurationen af auditlogning pr. tjeneste, opbevaring pr. bucket og alle sinks med filtre og destinationer. Konfigurationen forklarer senere, hvad der kunne være logget.
- Eksportér loggene for perioden i JSON via kommandolinjen, API’et eller en midlertidig sink til en dedikeret bucket. Brug et filter, der dækker perioden bredt, og gem filteret som tekst.
- Kontrollér fuldstændigheden. Sammenlign antallet af poster pr. dag med en optælling i Cloud Logging eller BigQuery, og undersøg dage med påfaldende få poster.
- Kopiér eksisterende sink-data fra Cloud Storage eller BigQuery. For BigQuery gemmes forespørgslen sammen med resultatet.
- Beregn hashværdier for alle eksportfiler, og registrér dem i sikringsloggen.
Logs fra API’et kan ikke hentes ud bit for bit på samme måde to gange; rækkefølge, formatering og felter kan variere. Hashværdien dokumenterer derfor den konkrete eksport, ikke loggen som sådan. Se Hashværdier ved mobiludtræk og cloud-eksporter.
Uafhængighed og ændringer
Kunden kan ikke redigere enkelte revisionsposter. Men en konto med de rette rettigheder kan slå Data Access fra, ændre opbevaringen i _Default, slette en sink eller slette den bucket, sinken skrev til. Ændringer af revisionskonfigurationen og af IAM er selv Admin Activity-hændelser og ligger derfor i _Required, som ikke kan slettes. Det gør det ofte muligt at datere, hvornår logningen blev ændret, og af hvem.
Fejlkilder i fortolkningen
- Tjenestekonti bruges af applikationer, pipelines og flere personer. En
principalEmail, der ender på en tjenestekontos domæne, peger ikke på en person. - Google-interne kald. Nogle handlinger udføres af Googles egne tjenester på kundens vegne og har en Google-styret identitet som afsender.
- IP-adresser kan være Googles egne adresser, når kaldet kommer fra en anden Google-tjeneste, fx Cloud Shell eller en funktion. Se IP-adresser som bevis.
- Tid. Tidsstempler er i UTC. Konsollen kan vise lokal tid.
- Fravær. Mangler en Data Access-post, er første spørgsmål, om Data Access var slået til for netop den tjeneste og den ressource.
- Afviste forsøg står i Policy Denied eller med en fejlstatus. De viser et forsøg, ikke adgang.
Hvad loggene kan og ikke kan bevise
Admin Activity kan med stor sikkerhed vise, hvilken identitet der ændrede rettigheder, oprettede nøgler til tjenestekonti eller slettede ressourcer, og hvornår. Data Access kan, hvis den var slået til, vise læsning af bestemte objekter eller tabeller. Ingen af dem kan alene vise, hvilken person der brugte identiteten, eller hvad der skete med data, efter de forlod Google Cloud.
Styrken kommer ved korrelation med andre kilder: Workspace-loginlogs for samme konto, CI/CD-logs for tjenestekonti og netværkslogs fra kundens egne systemer. Fremgangsmåden er beskrevet i Logkorrelation. De tilsvarende logs i de to andre store platforme er beskrevet i AWS CloudTrail og Azure Activity Log.
Dokumentation
Rapporten bør angive organisation og projekt, logtyper, bucket eller sink, filter eller forespørgsel, tidsinterval i UTC, antal poster, værktøj og version, hashværdier og den konfiguration, der var gældende. Beskriv eksplicit, hvilke Data Access-logs der ikke fandtes, og hvorfor. Ligger data i en region uden for EU, kan det have betydning for udleveringen; den juridiske side er beskrevet i Beviser i cloud uden for EU.
Kilder og versioner
- Google Cloud: Cloud Audit Logs overview
- Google Cloud: Enable Data Access audit logs
- Google Cloud: Routing and storage overview (_Required og _Default)
- Google Cloud: AuditLog, felter i revisionsposter
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Cloud- og SaaS-forensik
Læs også: Azure: Activity Log, Monitor og Log Analytics som bevis · Snapshots af cloud-diske som forensisk kopi
→ Logundersøgelse · Haster det? Forensisk sikring (hastesager koster ekstra) · For IT-sikkerhed og SOC · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT
