Incident Response in Google Cloud: kompromittiertes Projekt
Ihr Google-Cloud-Projekt ist womöglich kompromittiert. Die Reihenfolge: Identität eindämmen, Audit-Logs sichern, mit methodNames eingrenzen, dann bereinigen.
Kurz gesagt. Behandeln Sie eine vermutete Kompromittierung in Google Cloud zuerst als Identitätsvorfall. Deaktivieren Sie die genutzten Anmeldedaten (meist ein nutzerverwalteter Dienstkontoschlüssel oder eine Benutzersitzung), kopieren Sie die Cloud Audit Logs aus dem Projekt, bevor jemand mit Owner-Rechten sie anfassen kann, und grenzen Sie den Vorfall dann mit einer kurzen Liste von methodNames ein: CreateServiceAccountKey, SetIamPolicy, setMetadata, storage.objects.get, DeleteSink. Erst danach wird aufgeräumt. Der kostenlose Analyzer im Browser führt diese Erkennungen auf einem Export aus und liefert Ihnen ein Urteil, eine Zeitleiste und eine Checkliste.
Die meisten Google-Cloud-Vorfälle, die ich sehe, beginnen nicht mit einem exotischen Exploit. Googles eigener Cloud Threat Horizons Report (H2 2025) führt 47,1 % der im ersten Halbjahr 2025 beobachteten Erstzugriffe auf schwache oder fehlende Anmeldedaten zurück und 29,4 % auf Fehlkonfigurationen. In der Praxis heißt das: eine Schlüsseldatei in einem Repository, eine CI-Variable, die im Build-Log ausgegeben wurde, oder eine VM mit schwachem Passwort. Der Angreifer tut dann, was die Berechtigungen erlauben: sich selbst Owner-Rechte geben, Miner starten, Buckets lesen und abschalten, was Sie alarmieren könnte.
Dieser Leitfaden beschreibt die Reihenfolge der Schritte. Jeder Schritt verweist auf einen vertiefenden Artikel der Serie.
Phase 1: Triage in der ersten Stunde
Sie haben ein Signal: einen Kostensprung in der Abrechnung, einen Befund im Security Command Center, eine E-Mail von Google zu einem offengelegten Schlüssel oder ein seltsames IAM-Mitglied. Beantworten Sie schnell drei Fragen.
- Welche Identität? Die E-Mail-Adresse eines Dienstkontos (
…@PROJECT.iam.gserviceaccount.com), ein Benutzer oder ein privates Gmail-Konto, das dort nichts zu suchen hat. - Welche Anmeldedaten? Enthalten Audit-Einträge
authenticationInfo.serviceAccountKeyName, hat der Aufrufer einen nutzerverwalteten Schlüssel verwendet. Enthalten sieserviceAccountDelegationInfo, hat jemand die Identität eines Dienstkontos angenommen, und der eigentliche Akteur steht weiter oben in der Kette. - Ist er noch aktiv? Sehen Sie sich den letzten Eintrag für diese Identität und diese Aufrufer-IP an.
Eine erste Abfrage im Logs Explorer genügt, um diese Fragen zu beantworten:
logName:"cloudaudit.googleapis.com"
protoPayload.authenticationInfo.principalEmail="ci-deployer@PROJECT.iam.gserviceaccount.com"
Phase 2: die Identität eindämmen, nicht die Symptome
Die Miner-VM zu löschen fühlt sich produktiv an. Funktioniert der Schlüssel, mit dem sie erstellt wurde, aber noch, ist sie in wenigen Minuten wieder da. Googles Leitfaden für kompromittierte Anmeldedaten listet die Maßnahmen je Art von Anmeldedaten auf. Die wichtigsten:
| Genutzte Anmeldedaten | Eindämmung |
|---|---|
| Nutzerverwalteter Dienstkontoschlüssel | Schlüssel deaktivieren (und löschen, sobald die Schlüssel-ID in Ihren Notizen steht); rotieren, was das Dienstkonto lesen konnte |
| Impersonation | Bindung Token Creator / Service Account User des Aufrufers entfernen; Aufrufer deaktivieren |
| Benutzer- oder Gmail-Konto in IAM | Bindung entfernen; ist es einer Ihrer Benutzer, abmelden und Passwort zurücksetzen |
| OAuth-Tokens (gcloud) | Token widerrufen; Sitzungssteuerung für den Cloud-Zugriff erzwingen |
Prüfen Sie danach die IAM-Richtlinie auf weitere Ergänzungen. Angreifer, die Owner-Rechte erlangen, belassen es selten bei einer Bindung. Der Artikel zum Missbrauch von IAM-Richtlinien zeigt, wie Sie bindingDeltas lesen, um jede Änderung aufzulisten.
Phase 3: Beweise sichern, bevor sie ablaufen oder verschwinden
Zwei Dinge vernichten Cloud-Beweise: die Aufbewahrungsfrist und der Angreifer.
- Aufbewahrung. Der Bucket
_Requiredbewahrt Admin-Activity- und System-Event-Audit-Logs 400 Tage lang auf und kann nicht geändert werden; der Bucket_Defaultbewahrt alles andere, einschließlich der Data-Access-Logs, standardmäßig 30 Tage lang auf (Kontingente und Limits, Routing-Übersicht). - Der Angreifer. Mit Owner-Rechten kann er Log-Sinks löschen, Ausschlüsse anlegen, die Aufbewahrung von
_Defaultverkürzen oder Logs löschen. Siehe Umgehung von Abwehrmaßnahmen in Google Cloud.
Exportieren Sie jetzt, und zwar großzügig: den gesamten verdächtigen Zeitraum plus einige Wochen als Baseline, alle Audit-Log-Typen und VPC Flow Logs, falls vorhanden. Der Download in der Konsole ist auf 10.000 Einträge pro Download begrenzt (Oberfläche des Logs Explorer); für alles Größere verwenden Sie gcloud logging read oder kopieren den Sink-Bucket. Der Artikel Cloud Audit Logs erklärt behandelt jeden Exportweg.
Phase 4: mit einer kurzen Liste von methodNames eingrenzen
Sie müssen nicht jeden Eintrag lesen. Eine Handvoll Werte von protoPayload.methodName beantwortet die meisten Fragen zum Umfang:
| Frage | Wo suchen | Vertiefung |
|---|---|---|
| Wurde ein Schlüssel erstellt oder hochgeladen? | google.iam.admin.v1.CreateServiceAccountKey, UploadServiceAccountKey | Geleakter Dienstkontoschlüssel |
| Wer hat wessen Identität angenommen? | iamcredentials.googleapis.com GenerateAccessToken, SignBlob, SignJwt; serviceAccountDelegationInfo | Impersonation von Dienstkonten |
| Hat jemand Owner-Rechte erlangt? | SetIamPolicy mit bindingDeltas ADD roles/owner | SetIamPolicy-Missbrauch |
| Haben VMs eine Hintertür oder schürfen sie Krypto? | compute.instances.setMetadata, setCommonInstanceMetadata, compute.instances.insert mit Beschleunigern | Missbrauch von Compute Engine |
| Wurden Daten abgezogen? | Wellen von storage.objects.get, storage.setIamPermissions mit allUsers, BigQuery-Kopierjobs | Exfiltration aus GCS und BigQuery |
| Haben Daten das Netzwerk verlassen? | VPC Flow Logs, Bytes pro externer IP | Analyse von VPC Flow Logs |
| Wurden Sie blind gemacht? | DeleteSink, UpdateSink, CreateExclusion, auditConfigDeltas REMOVE | Umgehung von Abwehrmaßnahmen |
Pivotieren Sie durchgehend über zwei Schlüssel: die Aufrufer-IP (protoPayload.requestMetadata.callerIp) und die Identität. Eine Angreifer-IP, die zuerst bei einem Dienstkontoschlüssel und dann bei einem brandneuen Gmail-Owner auftaucht, verbindet die beiden Phasen. Der Analyzer macht genau diese Korrelation und meldet einen Befund „Angriffskette“, wenn dieselbe IP oder Identität von Zugriffs- zu Übernahmeaktionen übergeht.
Beachten Sie, dass callerIp nicht immer eine öffentliche Adresse ist: Laut Google-Dokumentation zeigen Aufrufe zwischen Google-Diensten private, und Aufrufe von VMs ohne externe IP können die interne Adresse oder gce-internal-ip enthalten (AuditLog-Referenz).
Phase 5: bereinigen und wiederherstellen
Sobald der Umfang bekannt ist, entfernen Sie alle Brückenköpfe in einem Durchgang, sonst bemerkt es der Angreifer und weicht aus:
- löschen Sie die vom Angreifer erstellten Schlüssel, HMAC-Schlüssel und Dienstkonten;
- entfernen Sie die IAM-Bindungen und stellen Sie gelockerte Organisationsrichtlinien wieder her;
- bauen Sie VMs, deren Startskripte oder SSH-Schlüssel geändert wurden, neu auf (statt sie zu bereinigen), nachdem Sie Snapshots ihrer Festplatten erstellt haben;
- machen Sie Buckets wieder privat und erzwingen Sie die Verhinderung öffentlichen Zugriffs;
- stellen Sie Sinks und das Data-Access-Logging wieder her, idealerweise über einen aggregierten Sink in ein Projekt, das die Verantwortlichen des Workloads nicht administrieren können.
Die Maßnahmen-Checkliste des Tools wird aus den Befunden in genau dieser Reihenfolge erzeugt: zuerst Eindämmung, dann Persistenz, dann Logging.
Phase 6: die Lücken schließen, die den Vorfall ermöglicht haben
Die Liste nach dem Vorfall ist meist dieselbe:
- erzwingen Sie
iam.disableServiceAccountKeyCreationund stellen Sie CI auf Workload Identity Federation um; - setzen Sie
iam.serviceAccountKeyExposureResponseaufDISABLE_KEY, damit Schlüssel, die Google an öffentlichen Orten findet, automatisch deaktiviert werden (Google-Cloud-Blog); - beschränken Sie IAM-Mitglieder mit der Domain-beschränkten Freigabe auf Ihre eigenen Domains;
- aktivieren Sie Data-Access-Audit-Logs mindestens für IAM und Cloud Storage; der Artikel zu ihren Grenzen erklärt, warum ihr Fehlen die häufigste Sackgasse ist.
Wo der Analyzer ins Spiel kommt
Der GCP-Forensics-Analyzer nimmt die Exporte aus Phase 3 und übernimmt die Eingrenzung aus Phase 4: 32 Regeln, 5 zustandsbehaftete Analysen und eine Angriffsketten-Korrelation, alle in der Regeltabelle der Seite veröffentlicht. Er läuft in Ihrem Browser; die Logs werden nicht hochgeladen. Die Schritt-für-Schritt-Anleitung zeigt den Ablauf, das fiktive Fallbeispiel zeigt die Ausgabe für einen vollständigen Vorfall.
Er ersetzt kein Urteilsvermögen. Ein Schlüssel, der von der IP eines CI-Anbieters genutzt wird, oder eine Owner-Rolle für einen Berater kann legitim sein; bestätigen Sie jeden Befund mit der zuständigen Person. GKE-Audit-Einträge werden für Kubernetes Forensics beiseitegelegt, Workspace-Einträge für Google Workspace Forensics.
Häufige Fragen
Was ist der erste Schritt, wenn ein Google-Cloud-Projekt kompromittiert ist?
Stoppen Sie die Anmeldedaten, die der Angreifer nutzt (Dienstkontoschlüssel deaktivieren, Benutzer sperren, Tokens widerrufen), und kopieren Sie in derselben Stunde die Audit-Logs aus dem Projekt. Alles andere kommt nach diesen beiden Schritten.
Welche Logs zeigen, was ein Angreifer in Google Cloud getan hat?
Cloud Audit Logs. Admin-Activity-Logs sind immer aktiv und zeigen Konfigurationsänderungen (IAM, VMs, Sinks). Data-Access-Logs zeigen Datenlesezugriffe, sind aber bei den meisten Diensten standardmäßig deaktiviert. VPC Flow Logs zeigen den Netzwerkverkehr von VMs, sofern sie im Subnetz aktiviert waren.
Wie weit zurück kann ich ermitteln?
Admin-Activity- und System-Event-Logs werden 400 Tage im Bucket _Required aufbewahrt. Data-Access- und Policy-Denied-Logs landen im Bucket _Default, standardmäßig 30 Tage lang. Ältere Daten gibt es nur, wenn ein Sink sie exportiert hat.
Weiterführende Links
- Respond to compromised Google Cloud credentials – Dokumentation von Google Cloud.
- Best practices for Cloud Audit Logs – Dokumentation von Google Cloud.
- MITRE-ATT&CK-Matrix für IaaS – die Techniken, denen die Befunde zugeordnet sind.
- Cloud Threat Horizons Report H2 2025 – Googles Statistiken zum Erstzugriff.