Domainweite Delegierung: Sicherheitsrisiken in Workspace

Kurz gesagt. Mit domainweiter Delegierung (DWD, domain-wide delegation) kann ein Dienstkonto oder API-Client für die angegebenen Scopes als jeder beliebige Nutzer der Domain handeln, ohne Einwilligung des Nutzers. Eine Delegierung mit Gmail- oder Drive-Scopes ist ein Generalschlüssel für jedes Postfach oder jedes Drive. Neue Delegierungen erscheinen im Admin-Log als AUTHORIZE_API_CLIENT_ACCESS. Prüfen Sie bei einem Vorfall jeden delegierten Client und seine Scopes, und denken Sie an die DeleFriend-Forschung von 2023: Wer für ein delegiertes Dienstkonto in Google Cloud Schlüssel erstellen darf, erbt die Delegierung.

OAuth-Freigaben pro Nutzer sind auf das begrenzt, was ein Nutzer erreicht. DWD nicht. Sie existiert aus guten Gründen (Backup-Tools, Migration, E-Signatur-Integrationen, GAM selbst), deshalb haben die meisten Tenants ein paar Delegierungen, an deren Genehmigung sich niemand erinnert. Für einen Angreifer, der ein Super-Admin-Konto erreicht, ist eine neue Delegierung die leiseste verfügbare Persistenz. MITRE ordnet das Feld T1098.001 Additional Cloud Credentials und T1484.002 Domain or Tenant Policy Modification: Trust Modification zu.

So funktioniert DWD

Googles Seite Control API access with domain-wide delegation beschreibt den Mechanismus:

In einem Google-Cloud-Projekt wird ein Dienstkonto angelegt, oder es gibt einen OAuth-Client für eine App.
Ein Super-Admin trägt dessen Client-ID und eine Liste von OAuth-Scopes unter Security → Access and data control → API controls → Manage Domain Wide Delegation ein (Bezeichnungen der englischsprachigen Konsole).
Der Client kann nun für diese Scopes als jeder Nutzer Tokens anfordern. Die Einwilligung des Nutzers entfällt.

Google empfiehlt in seinen Best Practices für domainweite Delegierung minimale Scopes und regelmäßige Überprüfung. Wo die Mehrparteien-Genehmigung aktiv ist, muss ein zweiter Super-Admin neue Delegierungen genehmigen.

Was die Logs zeigen

Wo	Ereignis	Was Sie lesen
Admin-Log	`AUTHORIZE_API_CLIENT_ACCESS`	Name / ID des Clients und erteilte Scopes
Admin-Log	Änderungen am App-Vertrauen (`ADD_TO_TRUSTED_OAUTH2_APPS`, `UNBLOCK_ALL_THIRD_PARTY_API_ACCESS`, …)	Zur gleichen Zeit gelockerte Kontrollen
OAuth-Token-Log	`activity` dieses Clients	API-Aufrufe im Namen jedes imitierten Nutzers
Google-Cloud-Audit-Logs	Erstellung von Dienstkontoschlüsseln	Neue Schlüssel auf einem delegierten Dienstkonto

Im Analyzer löst AUTHORIZE_API_CLIENT_ACCESS den Befund Domainweite Delegierung an einen API-Client erteilt aus (hohe Schwere). Hatte dasselbe Admin-Konto in den 14 Tagen zuvor eine riskante Anmeldung, steigt die Kette „riskante Anmeldung → Admin-Änderung“ auf kritisch. Gelockerte App-Kontrollen werden getrennt markiert.

Die DeleFriend-Forschung

Im November 2023 veröffentlichte das Team Axon von Hunters „DeleFriend“, eine Designschwäche, die es Google im August 2023 gemeldet hatte. Die Delegierung ist an die Client-ID des Dienstkontos gebunden, nicht an einen bestimmten privaten Schlüssel. Wer in Google Cloud die Berechtigung hat, für ein Dienstkonto mit bestehender DWD Schlüssel zu erstellen (iam.serviceAccountKeys.create, enthalten in breiten Rollen wie Editor), kann einen neuen Schlüssel erzeugen und die vorhandene Delegierung nutzen. Workspace-Super-Admin-Rechte sind dafür nicht nötig.

Die praktischen Folgen für eine Untersuchung:

Die Kompromittierung des Google-Cloud-Projekts, das ein delegiertes Dienstkonto enthält, ist eine Workspace-Kompromittierung im Wartestand.
Das Workspace-Admin-Log zeigt nichts Neues, denn die Delegierung existiert bereits. Das Signal liegt auf der Cloud-Seite (Schlüsselerstellung) und im Token-Log (neue API-Aktivität des Clients).
Nicht mehr genutzte Delegierungen sind reines Risiko.

Die Untersuchung der Google-Cloud-Seite (Dienstkontoschlüssel, IAM-Änderungen, Audit-Logs) ist eine eigene Disziplin. gcpforensics.com behandelt sie.

Prüfliste

Während eines Vorfalls und mindestens einmal im Jahr:

Exportieren Sie die Liste der Delegierungen. In der Konsole lassen sich Drittanbieter-Apps und DWD-Clients als CSV herunterladen. Pro Client: Wer ist verantwortlich, welches Projekt, welche Scopes, wann zuletzt genutzt?
Markieren Sie breite Scopes: https://mail.google.com/, gmail.*, drive, admin.directory.*, cloud-platform. Die meisten Integrationen brauchen weit weniger.
Gleichen Sie jedes AUTHORIZE_API_CLIENT_ACCESS im Admin-Log mit einem Änderungsauftrag ab. Ungeplant heißt Vorfall.
Prüfen Sie die zugehörigen Cloud-Projekte: Wer hat Editor/Owner oder das Recht, Schlüssel für delegierte Dienstkonten zu erstellen, und sind neue Schlüssel aufgetaucht?
Entfernen Sie ungenutzte Delegierungen und rotieren Sie die Schlüssel der verbleibenden.
Aktivieren Sie die Mehrparteien-Genehmigung für sensible Admin-Aktionen, wenn Ihre Edition sie anbietet.

Wenn Sie eine unrechtmäßige Delegierung finden

Entfernen Sie den Client sofort unter Manage Domain Wide Delegation. Google weist darauf hin, dass Änderungen Zeit brauchen können, meist weniger als 24 Stunden.
Deaktivieren oder löschen Sie die Schlüssel des Dienstkontos in Google Cloud.
Ziehen Sie das OAuth-Token-Log für diese Client-ID über alle Nutzer. Das ist der Umfang des Datenzugriffs.
Behandeln Sie das Super-Admin-Konto, das die Delegierung angelegt hat, als kompromittiert: Setzen Sie seine Anmelde-Cookies zurück, prüfen Sie seine Anmeldungen und jede Änderung, die es vorgenommen hat. Siehe Missbrauch von Admin-Rollen und SSO-Änderungen.

Der Unterschied zu OAuth pro Nutzer

	OAuth-Freigabe pro Nutzer	Domainweite Delegierung
Wer genehmigt	Der Nutzer	Ein Super-Admin
Reichweite	Die Daten eines Nutzers	Alle Nutzer, für die genannten Scopes
Log der Freigabe	OAuth-Token-Log, `authorize`	Admin-Log, `AUTHORIZE_API_CLIENT_ACCESS`
Typischer Missbrauch	Consent-Phishing	Persistenz nach Admin-Übernahme, Schlüsseldiebstahl in der Cloud
Beitrag	Verdächtige OAuth-Apps	Dieser Beitrag

Als Nächstes in der Serie: Drive-Massendownload und Takeout-Exfiltration. Um Delegierungs- und Vertrauensänderungen in Ihrem Admin-Log zu prüfen, laden Sie es in den Analyzer.

FAQ

Wer kann in Google Workspace domainweite Delegierung erteilen?

Nur ein Super-Admin kann domainweite Delegierung hinzufügen oder ändern, unter Security → Access and data control → API controls → Manage Domain Wide Delegation. Ist die Mehrparteien-Genehmigung aktiviert, muss ein weiterer Super-Admin zustimmen.

Welches Log zeigt Änderungen an der domainweiten Delegierung?

Das Admin-Log. Das Hinzufügen oder Ändern der delegierten Scopes eines Clients wird als AUTHORIZE_API_CLIENT_ACCESS mit Client und Scopes aufgezeichnet. Die anschließenden API-Aufrufe im Namen von Nutzern erscheinen im OAuth-Token-Log.