GCP - Understanding Domain-Wide Delegation
Ce post est l'introduction de https://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover auquel vous pouvez accéder pour plus de détails.
Comprendre la Délégation à l'Échelle du Domaine
La délégation à l'échelle du domaine de Google Workspace permet à un objet d'identité, qu'il s'agisse d'une application externe du Google Workspace Marketplace ou d'un compte de service GCP interne, d'accéder aux données à travers le Workspace au nom des utilisateurs. Cette fonctionnalité, cruciale pour les applications interagissant avec les API Google ou les services nécessitant une impersonation d'utilisateur, améliore l'efficacité et réduit les erreurs humaines en automatisant les tâches. En utilisant OAuth 2.0, les développeurs d'applications et les administrateurs peuvent donner à ces comptes de service l'accès aux données utilisateur sans le consentement individuel de l'utilisateur.
Google Workspace permet la création de deux principaux types d'identités d'objets délégués globaux :
Applications GWS : Les applications du Workspace Marketplace peuvent être configurées en tant qu'identité déléguée. Avant d'être disponibles sur le marché, chaque application Workspace est examinée par Google pour minimiser les abus potentiels. Bien que cela n'élimine pas entièrement le risque d'abus, cela rend considérablement plus difficile que de tels incidents se produisent.
Compte de Service GCP : En savoir plus sur les Comptes de Service GCP ici.
Délégation à l'Échelle du Domaine : Sous le Capot
Voici comment un compte de service GCP peut accéder aux API Google au nom d'autres identités dans Google Workspace :
L'identité crée un JWT : L'identité utilise la clé privée du compte de service (partie du fichier de paire de clés JSON) pour signer un JWT. Ce JWT contient des revendications sur le compte de service, l'utilisateur cible à impersonner et les étendues OAuth d'accès à l'API REST demandée.
L'identité utilise le JWT pour demander un jeton d'accès : L'application/l'utilisateur utilise le JWT pour demander un jeton d'accès auprès du service OAuth 2.0 de Google. La demande inclut également l'utilisateur cible à impersonner (l'e-mail de l'utilisateur Workspace) et les étendues pour lesquelles l'accès est demandé.
Le service OAuth 2.0 de Google renvoie un jeton d'accès : Le jeton d'accès représente l'autorité du compte de service à agir au nom de l'utilisateur pour les étendues spécifiées. Ce jeton est généralement de courte durée et doit être rafraîchi périodiquement (selon les besoins de l'application). Il est essentiel de comprendre que les étendues OAuth spécifiées dans le jeton JWT ont une validité et un impact sur le jeton d'accès résultant. Par exemple, les jetons d'accès possédant plusieurs étendues auront une validité pour de nombreuses applications API REST.
L'identité utilise le jeton d'accès pour appeler les API Google : Maintenant avec un jeton d'accès pertinent, le service peut accéder à l API REST requise. L'application utilise ce jeton d'accès dans l'en-tête "Autorisation" de ses requêtes HTTP destinées aux API Google. Ces API utilisent le jeton pour vérifier l'identité impersonnée et confirmer qu'elle a l'autorisation nécessaire.
Les API Google renvoient les données demandées : Si le jeton d'accès est valide et que le compte de service a l'autorisation appropriée, les API Google renvoient les données demandées. Par exemple, dans l'image suivante, nous avons utilisé la méthode users.messages.list pour lister tous les identifiants de messages Gmail associés à un utilisateur Workspace cible.
Dernière mise à jour
