Aufbewahrung der Google-Workspace-Audit-Logs und Grenzen

Kurz gesagt. Workspace-Audit-Logs sind gute Belege, haben aber harte Grenzen. Die Aufbewahrung beträgt für die untersuchungsrelevanten Quellen rund sechs Monate. Die Verzögerung reicht von Minuten bis Stunden (Tage für den Abschluss eines Takeout). Konsolenexporte sind auf 100.000 Zeilen begrenzt. CSV-Exporte verlieren Felder, die die Reports API behält (Netzwerkinformationen, verschachtelte Parameter). Gmail-Filter stehen überhaupt nicht im Audit-Log. Und je nach Lizenz wird manche Aktivität gar nicht protokolliert. Schreiben Sie diese Grenzen in jeden Bericht und nennen Sie einen unvollständigen Datensatz niemals „unauffällig“.

Genau deshalb listet der Analyzer neben seinem Urteil die Quellen auf, die Sie nicht geliefert haben. Dieser Beitrag ist die ausführliche Fassung dieser Warnung.

Aufbewahrung: sechs Monate, im Dienst nicht verlängerbar

Googles Tabelle Datenaufbewahrung und Verzögerungen nennt sechs Monate für Admin-, User- (Anmelde-), OAuth-Token-, Gmail-, Drive-, SAML-, Takeout- und Groups-Ereignisse. Sechs Monate sind auch der allgemeine Standard für Daten der Reports API. Die Referenz der Reports API begrenzt die meisten Anwendungen zudem auf 180 Tage Historie pro Abfrage. Admins können weder Ereignisse löschen noch ändern, wie lange Google sie aufbewahrt.

In der Praxis heißt das:

Ein spät entdeckter Einbruch kann vor Ihren Daten beginnen. BEC-Akteure bleiben mitunter wochenlang in einem Postfach. Liegt die erste riskante Anmeldung mehr als sechs Monate zurück, sehen Sie die Persistenz, aber nicht den Erstzugriff.
Exportieren Sie zu Beginn der Untersuchung, nicht am Ende. Jeder Tag Verzug verschiebt das Fenster.
Für eine lange Aufbewahrung leiten Sie die Logs an einen Ort weiter, den Sie kontrollieren. Google dokumentiert, wie ein Teil der Workspace-Audit-Logs mit Cloud Logging geteilt wird, und in manchen Editionen gibt es Exporte nach BigQuery.

Verzögerung: kein Ereignis heißt nicht keine Aktivität

Laut derselben Tabelle von Google:

Quelle	Dokumentierte Verzögerung
Anmeldungen, Admin, Gmail, Drive, SAML	Nahezu Echtzeit (ein paar Minuten)
Nutzerkonten-Ereignisse	Dutzende Minuten
OAuth-Token-Log	Ein paar Stunden
Groups	Dutzende Minuten, bis zu ein paar Stunden
Takeout	Start-Ereignisse nahezu in Echtzeit. Abschluss „bis zu viele Tage“ je nach Größe

Exportieren Sie eine Stunde nach dem Phishing-Klick, fehlt die OAuth-Freigabe womöglich schlicht noch. Exportieren Sie am nächsten Tag erneut, bevor Sie schließen: „Es wurde keine App freigegeben.“

Exportgrenzen und Formate

Zeilengrenzen. Konsolenexporte sind in Standard-Editionen auf 100.000 Zeilen und mit dem Sicherheitsprüfungstool auf 30 Millionen begrenzt (Hilfe zu Admin-Log-Ereignissen). Ein organisationsweites Drive-Log über einen Monat überschreitet das leicht. Teilen Sie nach Datum oder Nutzer auf oder nutzen Sie die API.

CSV gegenüber Reports API. Beide enthalten dieselben Ereignisse, aber nicht dieselben Details:

	CSV der Admin-Konsole	JSON der Reports API
Ereignisnamen	Lokalisierte Anzeigenamen („Successful login“)	Stabile API-Namen (`login_success`)
Spalten	Nur die unter Manage columns gewählten	Alle Parameter
Netzwerkinformationen (ASN, Region)	Nur wenn die Spalte existiert und gewählt wurde	`networkInfo` in jedem Datensatz
Verschachtelte Daten (Gmail-Nachrichteninfos, OAuth-Scopes)	Geglättet oder verloren	Erhalten
Zeitformat	Hängt von Konsolen- und Browsersprache ab	RFC 3339, UTC
Umfang	Begrenzt	Paginiert, skriptbar

Folgen für den Analyzer. Er übersetzt englische Konsolennamen in API-Namen, Exporte aus Konsolen in anderen Sprachen werden daher noch nicht erkannt. Länderbasierte Regeln (neues Land, unmögliche Reise) laufen nur, wenn Datensätze eine Region tragen, in der Praxis also mit der Reports API oder einer Länderspalte. Es gibt keine GeoIP-Auflösung. Fehlt in CSV-Zeitangaben die Zeitzone, weist das Tool darauf hin.

Das 30-Tage-Fenster von Gmail. Für gmail verlangt die Reports API startTime und endTime im Abstand von höchstens 30 Tagen (Referenz). Skripte, die das vergessen, bekommen Fehler, oder unvollständige Daten, wenn Fehler ignoriert werden.

Was das Audit-Log nicht aufzeichnet

Gmail-Filter, Bevollmächtigte, „Senden als“. Das sind Postfacheinstellungen, lesbar über die Gmail API oder die Einstellungsseiten des Nutzers, keine Audit-Ereignisse. Weiterleitungen sind halb abgedeckt: Das Nutzerkonten-Log zeichnet email_forwarding_out_of_domain beim Aktivieren auf. Siehe Gmail-Weiterleitungsregeln.
Nachrichteninhalte. Das Gmail-Log enthält Metadaten (Betreff, Absender, Empfänger, Ereignistyp), keinen Text. Inhalte erfordern Vault oder das Postfach selbst und eine rechtliche Grundlage.
Was eine OAuth-App mit den Daten gemacht hat. Das Token-Log zeigt API-Aufrufe und Methoden, nicht die abgerufenen Inhalte.
Aktivität außerhalb von Google. Sobald eine Datei heruntergeladen oder eine Mail weitergeleitet ist, geschieht alles Weitere außerhalb Ihrer Logs.
Aktionen unter manchen Lizenzen. 2023 berichtete Mitiga, dass Aktivitäten in der privaten Ablage von Nutzern ohne kostenpflichtige Workspace-Lizenz (Cloud Identity Free) nicht protokolliert wurden. Prüfen Sie, was Ihre Editionen aufzeichnen, bevor Sie sich auf das Fehlen von Drive-Ereignissen verlassen.

Heuristiken haben Fehlerbalken

Erkennungen sind Regeln, keine Wahrheit:

Fehlalarme. Reisende Mitarbeitende, VPN-Ausgänge und Unternehmens-Proxys bei Cloud-Anbietern, legitime Apps mit breiten Scopes (Backup, E-Signatur, CRM-Synchronisation), von der IT angelegte Konten.
Übersehene Fälle. Ein Angreifer mit einem Residential Proxy im Land des Opfers löst weder die Hosting-ASN- noch die Neues-Land-Regel aus. Ein geduldiger Angreifer, der stündlich 15 Dateien lädt, bleibt unter der Schwelle von 20 in 15 Minuten. Filter mit Begriffen außerhalb der Finanzwortliste werden nicht als „versteckt Finanz-Mails“ eingestuft, erscheinen aber trotzdem als Einstellung.
Korrelationsfenster. Die Kettenregeln schauen 14 Tage voraus auf dasselbe Konto. Eine kontenübergreifende Kampagne (einen Nutzer phishen, zu einem anderen wechseln) braucht einen Menschen, der die Punkte verbindet, mithilfe des Entitäten-Pivots über IPs und Apps.

Wie Sie es aufschreiben

Ein belastbarer Bericht sagt, was geprüft wurde und was nicht:

Quellen und Zeitraum pro Log (das Abdeckungsfeld des Tools liefert Ihnen das).
Bekannte Lücken: Aufbewahrungsgrenze, fehlende Quellen, CSV ohne Netzwerkdaten, Lizenzlücken.
Befunde mit Belegverweisen (Ereignis-IDs, Zeiten, IPs).
Schlussfolgerungen, die zu den Belegen passen: „kein Hinweis auf X in den geprüften Logs“, nicht „X ist nicht passiert“.

Weiterlesen

FAQ

Wie lange bewahrt Google Workspace Audit-Logs auf?

Googles Tabelle zur Datenaufbewahrung nennt sechs Monate für Admin-, User- (Anmelde-), OAuth-Token-, Gmail-, Drive-, SAML-, Takeout- und Groups-Ereignisse sowie sechs Monate als allgemeinen Standard für Daten der Reports API. Admins können das im Dienst selbst nicht verlängern. Für längere Aufbewahrung exportieren Sie die Logs oder leiten sie an Cloud Logging oder BigQuery weiter.

Warum sehe ich die neuesten Ereignisse nicht im Audit-Log?

Wegen der Verzögerung. Die meisten Quellen kommen innerhalb von Minuten an, Google dokumentiert aber ein paar Stunden für OAuth-Tokens, Dutzende Minuten (bis zu ein paar Stunden) für Groups und bis zu viele Tage für den Abschluss eines Takeout. Exportieren Sie später erneut, bevor Sie schließen, dass etwas nicht passiert ist.