GCP - Understanding Domain-Wide Delegation
Dieser Beitrag ist die Einführung von https://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover, auf den für weitere Details zugegriffen werden kann.
Verständnis der domänenweiten Delegation
Die domänenweite Delegation von Google Workspace ermöglicht es einem Identitätsobjekt, entweder einer externen App aus dem Google Workspace Marketplace oder einem internen GCP-Servicekonto, auf Daten im gesamten Workspace im Namen von Benutzern zuzugreifen. Diese Funktion, die für Apps, die mit Google APIs interagieren oder Benutzerimitation benötigen, entscheidend ist, verbessert die Effizienz und minimiert menschliche Fehler durch Automatisierung von Aufgaben. Mit OAuth 2.0 können App-Entwickler und Administratoren diesen Servicekonten Zugriff auf Benutzerdaten ohne individuelle Benutzerzustimmung geben.
Google Workspace ermöglicht die Erstellung von zwei Haupttypen globaler delegierter Objektidentitäten:
GWS-Anwendungen: Anwendungen aus dem Workspace Marketplace können als delegierte Identität eingerichtet werden. Bevor sie im Marketplace verfügbar gemacht werden, durchläuft jede Workspace-Anwendung eine Überprüfung durch Google, um potenziellen Missbrauch zu minimieren. Obwohl dies das Risiko von Missbrauch nicht vollständig beseitigt, erhöht es die Schwierigkeit erheblich, dass solche Vorfälle auftreten.
GCP-Servicekonto: Erfahren Sie mehr über GCP-Servicekonten hier.
Domänenweite Delegation: Unter der Haube
So kann ein GCP-Servicekonto im Namen anderer Identitäten in Google Workspace auf Google-APIs zugreifen:
Identität erstellt ein JWT: Die Identität verwendet den privaten Schlüssel des Servicekontos (Teil der JSON-Schlüsselpaar-Datei), um ein JWT zu signieren. Dieses JWT enthält Ansprüche über das Servicekonto, den Zielbenutzer zur Imitation und die OAuth-Bereiche des Zugriffs auf die angeforderte REST-API.
Die Identität verwendet das JWT, um ein Zugriffstoken anzufordern: Die Anwendung/der Benutzer verwendet das JWT, um ein Zugriffstoken vom OAuth 2.0-Dienst von Google anzufordern. Die Anfrage enthält auch den Zielbenutzer zur Imitation (die E-Mail des Workspace-Benutzers) und die Bereiche, für die Zugriff angefordert wird.
Der OAuth 2.0-Dienst von Google gibt ein Zugriffstoken zurück: Das Zugriffstoken repräsentiert die Autorität des Servicekontos, im Namen des Benutzers für die angegebenen Bereiche zu handeln. Dieses Token ist in der Regel kurzlebig und muss periodisch erneuert werden (je nach Bedarf der Anwendung). Es ist wichtig zu verstehen, dass die im JWT-Token angegebenen OAuth-Bereiche Gültigkeit haben und Auswirkungen auf das resultierende Zugriffstoken haben. Beispielsweise besitzen Zugriffstoken mit mehreren Bereichen Gültigkeit für zahlreiche REST-API-Anwendungen.
Die Identität verwendet das Zugriffstoken, um auf Google-APIs zuzugreifen: Nun kann die Anwendung mit einem relevanten Zugriffstoken auf die erforderliche REST-API zugreifen. Die Anwendung verwendet dieses Zugriffstoken im "Authorization"-Header ihrer HTTP-Anfragen, die für Google-APIs bestimmt sind. Diese APIs verwenden das Token, um die imitierte Identität zu überprüfen und zu bestätigen, dass sie die erforderliche Autorisierung besitzt.
Google-APIs geben die angeforderten Daten zurück: Wenn das Zugriffstoken gültig ist und das Servicekonto über die entsprechende Autorisierung verfügt, geben die Google-APIs die angeforderten Daten zurück. Zum Beispiel haben wir in dem folgenden Bild die Methode users.messages.list genutzt, um alle Gmail-Nachrichten-IDs eines Ziel-Workspace-Benutzers aufzulisten.
Last updated
