Délégation au niveau du domaine : risques de sécurité
Les risques de la délégation au niveau du domaine : un client API qui usurpe chaque utilisateur, les événements du journal Admin, DeleFriend, quoi revoir.
En bref. La délégation au niveau du domaine (DWD, domain-wide delegation) permet à un compte de service ou à un client API d'agir en tant que n'importe quel utilisateur du domaine pour les scopes listés, sans consentement de l'utilisateur. Une délégation avec des scopes Gmail ou Drive est un passe-partout pour chaque boîte ou chaque Drive. Les nouvelles délégations apparaissent dans le journal Admin sous AUTHORIZE_API_CLIENT_ACCESS. Passez en revue chaque client délégué et ses scopes pendant un incident. Et gardez en tête la recherche DeleFriend de 2023 : quiconque peut créer des clés pour un compte de service délégué dans Google Cloud hérite de la délégation.
Les autorisations OAuth par utilisateur sont limitées à ce qu'un utilisateur peut atteindre. La DWD, non. Elle existe pour de bonnes raisons (outils de sauvegarde, migration, intégrations de signature électronique, GAM lui-même), ce qui explique que la plupart des tenants aient quelques délégations dont personne ne se rappelle l'approbation. Pour un attaquant qui atteint un compte super-administrateur, en ajouter une est la persistance la plus discrète qui soit. MITRE rattache ce domaine à T1098.001 Additional Cloud Credentials et à T1484.002 Domain or Tenant Policy Modification: Trust Modification.
Comment fonctionne la DWD
La page Control API access with domain-wide delegation de Google décrit le mécanisme :
- Un compte de service est créé dans un projet Google Cloud, ou un client OAuth existe pour une application.
- Un super-administrateur ajoute son ID client et une liste de scopes OAuth sous Security → Access and data control → API controls → Manage Domain Wide Delegation (libellés de la console en anglais).
- Le client peut désormais demander des jetons au nom de n'importe quel utilisateur pour ces scopes. Le consentement de l'utilisateur est contourné.
Google recommande des scopes au plus juste et une revue régulière dans ses bonnes pratiques de délégation au niveau du domaine. Là où l'approbation multipartite est activée, un second super-administrateur doit approuver les nouvelles délégations.
Ce que montrent les journaux
| Où | Événement | Ce qu'il faut lire |
|---|---|---|
| Journal Admin | AUTHORIZE_API_CLIENT_ACCESS | Nom / ID du client et scopes accordés |
| Journal Admin | Changements de confiance des applications (ADD_TO_TRUSTED_OAUTH2_APPS, UNBLOCK_ALL_THIRD_PARTY_API_ACCESS, …) | Contrôles assouplis au même moment |
| Journal des jetons OAuth | activity pour ce client | Appels API faits au nom de chaque utilisateur usurpé |
| Journaux d'audit Google Cloud | Création de clé de compte de service | Nouvelles clés sur un compte de service délégué |
Dans l'analyseur, AUTHORIZE_API_CLIENT_ACCESS déclenche le constat Délégation au niveau du domaine accordée à un client API (gravité élevée). Si ce même compte admin a eu une connexion à risque dans les 14 jours, la chaîne « connexion à risque → changement admin » passe en critique. L'assouplissement des contrôles d'applications est signalé à part.
La recherche DeleFriend
En novembre 2023, la Team Axon de Hunters a publié « DeleFriend », un problème de conception signalé à Google en août 2023. La délégation est liée à l'ID client du compte de service, pas à une clé privée précise. Quiconque dispose dans Google Cloud du droit de créer des clés pour un compte de service déjà délégué (iam.serviceAccountKeys.create, inclus dans des rôles larges comme Editor) peut fabriquer une nouvelle clé et utiliser la délégation existante. Aucun droit de super-administrateur Workspace n'est nécessaire.
Conséquences concrètes pour une enquête :
- La compromission du projet Google Cloud qui héberge un compte de service délégué est une compromission Workspace en puissance.
- Le journal Admin de Workspace ne montrera rien de nouveau, puisque la délégation existe déjà. Le signal est côté Cloud (création de clé) et dans le journal des jetons (nouvelle activité API du client).
- Les délégations qui ne servent plus sont du risque pur.
L'enquête côté Google Cloud (clés de comptes de service, changements IAM, journaux d'audit) est une discipline à part entière. gcpforensics.com la couvre.
Checklist de revue
Pendant un incident, et au moins une fois par an :
- Exportez la liste des délégations. La console permet de télécharger en CSV les applications tierces et les clients DWD. Pour chaque client : qui en est responsable, quel projet, quels scopes, quand il a servi pour la dernière fois.
- Repérez les scopes larges :
https://mail.google.com/,gmail.*,drive,admin.directory.*,cloud-platform. La plupart des intégrations ont besoin de bien moins. - Rapprochez chaque
AUTHORIZE_API_CLIENT_ACCESSdu journal Admin d'une demande de changement. Non planifié veut dire incident. - Vérifiez les projets Cloud propriétaires : qui détient Editor/Owner ou le droit de créer des clés sur les comptes de service délégués, et si de nouvelles clés sont apparues.
- Supprimez les délégations inutilisées, et faites tourner les clés de celles que vous gardez.
- Activez l'approbation multipartite pour les actions admin sensibles si votre édition la propose.
Si vous trouvez une délégation illégitime
- Retirez immédiatement le client de Manage Domain Wide Delegation. Google précise que les changements peuvent prendre du temps à s'appliquer, en général moins de 24 heures.
- Désactivez ou supprimez les clés du compte de service dans Google Cloud.
- Extrayez le journal des jetons OAuth pour cet ID client, sur tous les utilisateurs. C'est le périmètre de l'accès aux données.
- Traitez comme compromis le compte super-administrateur qui l'a ajoutée : réinitialisez ses cookies de connexion, examinez ses connexions et chaque changement qu'il a fait. Voir abus de rôles admin et changements SSO.
Différence avec l'OAuth par utilisateur
| Autorisation OAuth par utilisateur | Délégation au niveau du domaine | |
|---|---|---|
| Qui approuve | L'utilisateur | Un super-administrateur |
| Portée | Les données d'un utilisateur | Tous les utilisateurs, pour les scopes listés |
| Trace de l'autorisation | Journal des jetons OAuth, authorize | Journal Admin, AUTHORIZE_API_CLIENT_ACCESS |
| Abus typique | Hameçonnage par consentement | Persistance après prise de contrôle admin, vol de clé côté Cloud |
| Article | Applications OAuth suspectes | Cet article |
Suite de la série : téléchargement massif Drive et exfiltration Takeout. Pour vérifier les changements de délégation et de confiance dans votre journal Admin, déposez-le dans l'analyseur.
FAQ
Qui peut accorder une délégation au niveau du domaine dans Google Workspace ?
Seul un super-administrateur peut ajouter ou modifier une délégation au niveau du domaine, sous Security → Access and data control → API controls → Manage Domain Wide Delegation. Si l'approbation multipartite est activée, un autre super-administrateur doit l'approuver.
Quel journal montre les changements de délégation au niveau du domaine ?
Le journal Admin. L'ajout ou la modification des scopes délégués d'un client est enregistré sous AUTHORIZE_API_CLIENT_ACCESS, avec le client et les scopes. Les appels API faits ensuite au nom des utilisateurs apparaissent dans le journal des jetons OAuth.