GCP-Data-Access-Logs: standardmäßig aus – und andere Lücken

Q: Wie lange werden Data-Access-Logs aufbewahrt?

Sie werden im Log-Bucket _Default gespeichert, dessen Standard-Aufbewahrung 30 Tage beträgt. Für eine längere Aufbewahrung müssen Sie die Aufbewahrung des Buckets ändern oder die Logs per Sink nach Cloud Storage, BigQuery oder in einen anderen Log-Bucket leiten.

Kurz gesagt. Data-Access-Audit-Logs sind die einzige Aufzeichnung von Lesezugriffen in Google Cloud: heruntergeladene Objekte, abgerufene Secrets, für Dienstkonten ausgestellte Tokens, gelesene IAM-Richtlinien. Sie sind standardmäßig deaktiviert (außer bei einigen BigQuery-Diensten), werden standardmäßig 30 Tage aufbewahrt und lassen sich nicht rückwirkend einschalten. Fehlen sie, kann eine Untersuchung belegen, was verändert wurde, aber nicht, was abgeflossen ist. Aktivieren Sie sie jetzt, mindestens für IAM, Cloud Storage und Secret Manager, und leiten Sie sie an einen Ort, an dem sie länger als 30 Tage überdauern.

Das ist die häufigste Sackgasse, auf die ich in Google-Cloud-Fällen stoße. Die IAM-Änderungen, VMs und Sink-Löschungen stehen alle in Admin Activity. Dann trifft die Frage „Welche Dateien haben sie mitgenommen?“ auf Schweigen.

Was Data-Access-Logs abdecken

Google unterteilt Data-Access-Logs in drei Typen (Data-Access-Audit-Logs konfigurieren):

Typ	Beispiele in einer Untersuchung
`ADMIN_READ`	`GetIamPolicy`, `ListServiceAccounts`, `GetServiceAccountKey` sowie `GenerateAccessToken` in der IAM Credentials API
`DATA_READ`	`storage.objects.get`, `AccessSecretVersion`, Lesen von Tabellendaten
`DATA_WRITE`	`storage.objects.create` / delete, Schreiben von Daten in Dienste

ADMIN_WRITE ist das Admin-Activity-Log, das immer aktiv ist. Der Rest muss ausdrücklich eingeschaltet werden.

Was ohne sie unsichtbar bleibt

Frage	Benötigter Beleg	Ohne Data-Access-Logs
Welche Objekte wurden heruntergeladen?	`storage.objects.get`	Unbekannt
Wurden Secrets gelesen?	`AccessSecretVersion`	Unbekannt
Wer hat die Identität welches Dienstkontos angenommen?	`GenerateAccessToken`, `SignJwt`	Nur bei späteren schreibenden Aufrufen über `serviceAccountDelegationInfo` sichtbar (Impersonation)
Was hat der Angreifer erkundet?	Aufrufe `List`, `Get`	Nur fehlgeschlagene Schreibaufrufe; die Aufklärung bleibt größtenteils unsichtbar
Was hat ein geleakter Schlüssel vor der Rechteausweitung gelesen?	Lesezugriffe mit `serviceAccountKeyName`	Nur seine Schreibzugriffe

Der Analyzer erkennt diese Situation und zeigt eine Warnung, wenn ein Export überhaupt keine Data-Access-Einträge enthält: „Datenlesezugriffe … sind unsichtbar“. Regeln, die auf Lesezugriffen beruhen (bulk_object_reads, sa_impersonation), können nicht anschlagen, und ein Urteil „Unauffällig“ oder „Verdächtig“ ist in diesem Licht zu lesen.

Warum sie oft deaktiviert sind

Drei Gründe, allesamt nachvollziehbar:

Kosten und Volumen. Lesezugriffe übersteigen Schreibzugriffe bei Weitem; Data-Access-Logs werden wie jedes andere Log aufgenommen und gespeichert.
Nebenwirkungen. Google weist darauf hin, dass die Aktivierung von Data-Access-Logs für Cloud Storage manche authentifizierten Downloads im Browser scheitern lassen kann (Data-Access-Audit-Logs konfigurieren).
Niemand hat entschieden. Außer bei BigQuery gibt es keinen Standard; solange niemand eine auditConfig auf Organisationsebene setzt, werden Projekte ohne sie angelegt.

Ein vernünftiger Kompromiss: Aktivieren Sie DATA_READ und ADMIN_READ auf Organisationsebene für IAM, Cloud Storage (bei Kostenbedenken nur für die wichtigen Buckets) und Secret Manager, und nehmen Sie laute, gut verstandene Dienstkonten mit exemptedMembers aus, statt alles abzuschalten.

Aufbewahrung: 30 Tage, wenn Sie nichts unternehmen

Data-Access- und Policy-Denied-Logs landen im Bucket _Default, standardmäßig 30 Tage; Admin Activity und System Event landen in _Required, 400 Tage (Routing-Übersicht, Kontingente). Vorfälle werden oft erst Wochen nach dem Erstzugriff entdeckt. Bis dahin sind die Lesezugriffe der ersten Tage abgelaufen, während die Schreibzugriffe erhalten bleiben. Diese Asymmetrie erzeugt ein irreführendes Bild: einen Angriff, der scheinbar mit einer Rechteausweitung beginnt, weil die vorausgehende Aufklärung verschwunden ist.

Die Optionen, geordnet nach Robustheit:

Ein Log-Sink (idealerweise ein aggregierter Sink auf Organisationsebene) in einen Bucket in einem separaten Projekt, mit gesperrter Aufbewahrungsrichtlinie.
Eine längere Aufbewahrung für _Default in jedem Projekt.
Ein BigQuery-Sink für eine abfragbare Historie.

Sinks füllen nicht rückwirkend auf. Was Sie heute einrichten, schützt den nächsten Vorfall, nicht den aktuellen. Für den aktuellen exportieren Sie sofort, bevor die 30 Tage ablaufen: siehe Cloud Audit Logs erklärt.

Weitere blinde Flecken, die Sie festhalten sollten

Data-Access-Logs sind die größte Lücke, aber nicht die einzige. Ein vollständiger Bericht listet auf, was nicht sichtbar war:

Öffentliche Objekte: Laut Google erfassen Cloud Audit Logs keine Zugriffe auf öffentliche Objekte (Audit-Logging in Cloud Storage). Nachdem allUsers berechtigt wurde, sind Lesezugriffe selbst mit Data-Access-Logs unsichtbar.
Innerhalb der VM: Prozesse, Dateien und Befehle auf einer Compute-Engine-Instanz liegen außerhalb der Cloud Audit Logs. Dafür brauchen Sie Festplatten-Snapshots und Betriebssystem-Logs.
Netzwerk: Ohne VPC Flow Logs im Subnetz wird ausgehender Verkehr einer kompromittierten VM nicht aufgezeichnet; mit ihnen sind die Volumina stichprobenbasierte Schätzungen.
Unkenntlich gemachte Aufrufer-IPs: Aufrufe zwischen Google-Diensten zeigen private, und Aufrufe von VMs ohne externe IP können gce-internal-ip zeigen (AuditLog-Referenz).
Unkenntlich gemachte Identitäten: Bei lesenden Aufrufen, die mit PERMISSION_DENIED scheitern, kann Google die E-Mail-Adresse des Aufrufers schwärzen, sofern es kein Dienstkonto ist (Übersicht zu Cloud Audit Logs).
Andere Ebenen: Audit-Logs der GKE-Kubernetes-API und von Google Workspace sind eigene Themen. Der Analyzer übergibt sie an Kubernetes Forensics und Google Workspace Forensics.

Grenzen des Analyzers selbst

Um beim Tool genauso deutlich zu sein:

Es liest nur JSON: CSV-Downloads aus dem Logs Explorer und BigQuery-Exporte in Avro / Parquet werden mit einer Erklärung abgelehnt.
Die heuristischen Schwellwerte sind fest (zum Beispiel 100 Objektlesezugriffe in 10 Minuten); sie können bei vielbeschäftigten ETL-Konten anschlagen oder langsame Exfiltration übersehen.
BigQuery-Extraktionsjobs in externe Buckets und mehrere neuere Angriffswege (öffentliche Cloud-Run-Aufrufer, massenhafte Zugriffe auf Secret Manager, Änderungen an VPC Service Controls) sind noch nicht durch Regeln abgedeckt.
„Neue IP“ und „neue Region“ beziehen sich auf das, was Sie exportiert haben. Bei einem kurzen Export sieht die IP des Angreifers wie die Baseline aus.

Was Sie vor dem nächsten Vorfall aktivieren sollten

Data-Access-Logs (ADMIN_READ, DATA_READ) für IAM, Cloud Storage und Secret Manager auf Organisationsebene.
Einen aggregierten Sink auf Organisationsebene in einen gesperrten Bucket in einem eigenen Projekt.
VPC Flow Logs in sensiblen Subnetzen.
Alarme auf die methodNames zur Umgehung von Abwehrmaßnahmen aus dem Artikel zu Defense Evasion.

Häufige Fragen

Sind Data-Access-Logs in GCP standardmäßig aktiviert?

Nein. Data-Access-Audit-Logs sind standardmäßig für alle Dienste deaktiviert, mit Ausnahme einiger BigQuery-Dienste. Sie müssen pro Dienst (oder für allServices) im Abschnitt auditConfigs der IAM-Richtlinie aktiviert werden, auf Projekt-, Ordner- oder Organisationsebene.

Wie lange werden Data-Access-Logs aufbewahrt?

Sie werden im Log-Bucket _Default gespeichert, dessen Standard-Aufbewahrung 30 Tage beträgt. Für eine längere Aufbewahrung müssen Sie die Aufbewahrung des Buckets ändern oder die Logs per Sink nach Cloud Storage, BigQuery oder in einen anderen Log-Bucket leiten.

Kann ich Data-Access-Logs nach einem Vorfall aktivieren, um zu sehen, was passiert ist?

Nein. Ab der Aktivierung werden nur Aufrufe ab diesem Zeitpunkt erfasst; nichts wird rückwirkend ergänzt. Aktivieren Sie sie jetzt, damit sie bei der nächsten Untersuchung vorliegen.

Weiterführende Links

Configure Data Access audit logs – Dokumentation von Google Cloud.
Best practices for Cloud Audit Logs – Dokumentation von Google Cloud.
Incident Response in Google Cloud: kompromittiertes Projekt.