GCP-Audit-Logs analysieren: Schritt für Schritt im Browser
Audit-Logs und VPC Flow Logs aus Google Cloud Schritt für Schritt analysieren: als JSON exportieren, Dateien ablegen, Urteil, Befunde und Zeitleiste auswerten.
Kurz gesagt. Exportieren Sie die Audit-Logs als JSON (nicht als CSV), legen Sie jede Datei auf der Seite von GCP Forensics ab, prüfen Sie den „Abgedeckten Zeitraum“ und die Warnungen und lesen Sie dann in dieser Reihenfolge das Urteil, die Befunde mit ihren Belegen, die Zeitleiste und die Maßnahmenliste. Pivotieren Sie im Reiter „Entitäten“ über die IP des Angreifers und den Dienstkontoschlüssel. Alles läuft lokal in einem Web Worker: Die Logs werden nicht hochgeladen.
Dies ist die praktische Ergänzung zum Leitfaden für die Incident Response. Wenn Sie zuerst nur die Ausgabe sehen möchten, klicken Sie auf der Tool-Seite auf Beispiel testen: Das lädt einen fiktiven Vorfall, der im fiktiven Fallbeispiel Schritt für Schritt erklärt wird.
Schritt 1: Logs als JSON exportieren
Der Analyzer liest, was Google Cloud erzeugt, solange es JSON ist:
| Quelle | Was Sie ablegen |
|---|---|
| Logs Explorer → Herunterladen → JSON | downloaded-logs-*.json (ein JSON-Array); mehrere Dateien, wenn Sie den Zeitraum aufgeteilt haben |
gcloud logging read … --format=json | Eine Datei mit einem JSON-Array, optional gzip-komprimiert |
| Aus Cloud Storage kopierter Log-Sink-Bucket | Der Ordner (oder ein ZIP davon) mit JSON-Lines-Dateien unter cloudaudit.googleapis.com/<log>/YYYY/MM/DD/*.json |
| BigQuery-Sink | Abfrageergebnisse, gespeichert als zeilengetrenntes JSON |
Nehmen Sie alle vier Audit-Log-Typen auf, dazu VPC Flow Logs, falls vorhanden. Die Details, einschließlich der Grenze von 10.000 Einträgen beim Download aus der Konsole, stehen in Cloud Audit Logs erklärt. CSV-Downloads aus dem Logs Explorer und BigQuery-Exporte in Avro oder Parquet werden mit einer Erklärung abgelehnt; exportieren Sie erneut als JSON.
Ein sinnvolles Minimum für ein einzelnes Projekt über 30 Tage:
gcloud logging read 'logName:"cloudaudit.googleapis.com" OR logName:"vpc_flows"' \
--project=PROJECT_ID --freshness=30d --format=json | gzip > project-logs.json.gz
Schritt 2: Dateien ablegen
Öffnen Sie den Analyzer und legen Sie die Dateien per Drag-and-drop ab, wählen Sie sie über Dateien wählen aus oder nehmen Sie mit Ordner wählen einen ganzen Ordner. ZIP-Archive werden Eintrag für Eintrag gelesen, ohne auf die Festplatte entpackt zu werden, .gz-Dateien entpackt der Browser, und große Exporte werden in Blöcken gestreamt, sodass der Speicherbedarf begrenzt bleibt.
Der Parser ist in Rust geschrieben, nach WebAssembly kompiliert und läuft in einem Web Worker. Ihre Logs enthalten E-Mail-Adressen, IP-Adressen und Ressourcennamen; sie bleiben auf Ihrem Rechner. Sie können die Netzwerkverbindung trennen, nachdem die Seite geladen ist.
Schritt 3: prüfen, was tatsächlich gelesen wurde
Bevor Sie irgendeinem Urteil trauen, lesen Sie die Übersichtszeile: abgedeckter Zeitraum, Log-Einträge, Dateien, Identitäten und Flow-Datensätze. Dann die Hinweise:
- Nicht analysierte Dateien, jeweils mit Grund (leere Datei, CSV-Download, kein JSON, beschädigtes gzip, nicht lesbares ZIP).
- Keine Data-Access-Audit-Logs in diesem Export: Datenlesezugriffe sind unsichtbar, „kein Exfiltrationsbefund“ bedeutet also nichts. Siehe Grenzen der Data-Access-Logs.
- Übergaben: Audit-Einträge von GKE / Kubernetes-API werden für Kubernetes Forensics beiseitegelegt, Audit-Einträge von Google Workspace für Google Workspace Forensics.
Deckt der Zeitraum das vermutete Eindringen nicht ab, hören Sie hier auf und exportieren Sie mehr.
Schritt 4: Urteil und Begründung lesen
Die Regeln für das Urteil stehen in der veröffentlichten Regeldatei:
| Urteil | Bedingung |
|---|---|
| Kompromittiert | Mindestens ein kritischer Befund, oder Befunde mit hohem oder kritischem Schweregrad in mindestens zwei verschiedenen Taktiken |
| Verdächtig | Mindestens ein Befund mit mittlerem oder höherem Schweregrad |
| Unauffällig | Kein Befund mit mittlerem oder höherem Schweregrad (Hinweise mit niedrigem Schweregrad, etwa ein neues Dienstkonto, können dennoch erscheinen) |
„Unauffällig“ ist kein Beweis für die Abwesenheit eines Angriffs; es deckt nur die Logs ab, die Sie abgelegt haben. Die unter dem Urteil aufgeführten Gründe verlinken auf die Befunde, die es ausgelöst haben.
Schritt 5: Befunde und Belege prüfen
Jeder Befund zeigt seinen Schweregrad, seine Art (Regel, Schwellwert, Analyse oder Korrelation), die Taktik, die IDs der MITRE-ATT&CK-Techniken, die Ziele (eine Schlüssel-ID, eine IAM-Änderung wie ADD roles/owner user:x@gmail.com, einen Bucket) und die Belegeinträge mit dem Original-JSON.
Die Erkennungen decken unter anderem ab:
- Anmeldedaten:
CreateServiceAccountKey, hochgeladene Schlüssel, ein Schlüssel, der von einer öffentlichen IP genutzt wird, ein Schlüssel, der von einer bisher nie verwendeten IP genutzt wird, Token-Ausstellung über die IAM Credentials API, Wellen verweigerter Aufrufe. Siehe geleakter Dienstkontoschlüssel und Impersonation. - IAM: vergebene Owner-, Editor- und IAM-Admin-Rollen, Gmail-Konten, unbekannte Domains,
allUsers. Siehe SetIamPolicy-Missbrauch. - Compute: Startskripte, SSH-Schlüssel, entferntes OS Login, GPU-VMs, Wellen von VM-Erstellungen, VMs in nie genutzten Regionen, für
0.0.0.0/0geöffnete Firewalls. Siehe Missbrauch von Compute Engine. - Daten: massenhaftes
storage.objects.get, öffentliche Ressourcen, BigQuery-Kopien in andere Projekte, freigegebene Images und Snapshots, großer ausgehender Verkehr in Flow-Logs. Siehe Exfiltration aus GCS und BigQuery. - Anti-Forensik: Sinks, Ausschlüsse, Log-Buckets, Logs, Data-Access-Logging, Benachrichtigungen des Security Command Center. Siehe Umgehung von Abwehrmaßnahmen.
Die vollständige Liste mit Schweregraden und ATT&CK-IDs steht in der Regeltabelle.
Schritt 6: Zeitleiste rekonstruieren und pivotieren
Der Reiter Zeitleiste ordnet markierte Aktivitäten und Befunde zeitlich. Der Reiter Entitäten listet Identitäten (mit Typ: Dienstkonto, Benutzer, privates Gmail, Google-Dienst-Agent; dazu Impersonation-Ketten), Dienstkontoschlüssel (mit Ersteller und IPs), Aufrufer-IPs (mit den in VPC Flow Logs ausgetauschten Bytes), Projekte und Ressourcen. Ein Klick auf einen Eintrag filtert die Tabelle Ereignisse auf diese Entität.
Die beiden Pivots, mit denen sich die meisten Fälle lösen lassen:
- Die Angreifer-IP. Alles, was sie getan hat, über jede Identität hinweg, die sie genutzt hat.
- Die Schlüssel-ID. Wo der Schlüssel erstellt wurde, von wem, und jede IP, die ihn verwendet hat.
Wechseln Sie nach Bedarf zwischen UTC und Ortszeit; bleiben Sie in Ihrem Bericht bei UTC.
Schritt 7: Maßnahmenliste abarbeiten und exportieren
Der Reiter Maßnahmen macht aus den Befunden geordnete Schritte: Sicherheitsvorfall ausrufen und Logs sichern, IPs blockieren, IAM-Bindungen entfernen, Schlüssel deaktivieren, VMs neu aufbauen, Logging wiederherstellen. Haken Sie die Punkte ab, während Sie vorankommen (die Haken werden nicht gespeichert).
Exportieren Sie die Ereignisse als CSV (Zellen, die als Tabellenkalkulationsformeln interpretiert werden könnten, werden entschärft) oder das gesamte Ergebnis als JSON-Bericht für Ihre Fallakte.
Grenzen, die Sie im Blick behalten sollten
- Heuristiken weisen hin, sie beweisen nicht. Ein CI-Anbieter, der einen Schlüssel von seinen eigenen IPs aus nutzt, löst „Dienstkontoschlüssel von öffentlicher IP genutzt“ aus.
- Die Schwellwerte sind in der Regeldatei festgelegt (zum Beispiel 100 Objektlesezugriffe in 10 Minuten, 20 verweigerte Aufrufe in 10 Minuten, 1 GiB an eine einzelne externe IP).
- Routineereignisse werden in der Tabelle bis 100.000 aufgeführt; markierte werden immer behalten, und die Erkennungen decken jeden Eintrag ab.
Weiterführende Links
- Cloud Audit Logs overview – Dokumentation von Google Cloud.
- Respond to compromised Google Cloud credentials – was mit den Befunden zu tun ist.
- Kompromittierung in GCP: ein fiktives Fallbeispiel – das Beispiel, erklärt.