Bonnes pratiques de délégation au niveau du domaine

En tant qu'administrateur, la délégation au niveau du domaine vous permet d'autoriser les applications internes et tierces à accéder aux données Google Workspace de vos utilisateurs, sans tenir compte de leur consentement. Pour ce faire, vous devez créer un compte de service dans la console Google Cloud et lui déléguer une autorité au niveau du domaine dans la console d'administration Google. Vous pouvez également fournir des champs d'application d'API limités au compte de service dans la console d'administration. Pour en savoir plus sur la délégation au niveau du domaine, consultez Contrôler l'accès à l'API à l'aide de la délégation au niveau du domaine.

Gérer et sécuriser les comptes de service

Identity and Access Management (IAM) fournit des consignes sur l'utilisation des comptes de service pour limiter les accès et se protéger contre l'élévation des privilèges et les menaces de non-répudiation. Pour les consulter, consultez Bonnes pratiques d'utilisation des comptes de service. 

Bien que toutes les recommandations du guide s'appliquent à la protection des comptes de service qui utilisent la délégation au niveau du domaine, voici certaines des pratiques mises en avant:

	Utiliser plutôt l'accès direct au compte de service ou le consentement OAuth Évitez d'utiliser la délégation au niveau du domaine si vous pouvez accomplir votre tâche directement à l'aide d'un compte de service ou du consentement OAuth. Si vous ne pouvez pas éviter la délégation au niveau du domaine, limitez l'ensemble des niveaux d'accès OAuth que le compte de service peut utiliser. Bien que les niveaux d'accès OAuth ne restreignent pas les utilisateurs que le compte de service peut emprunter, ils limitent les types de données utilisateur auxquels le compte de service peut accéder. Éviter d'utiliser la délégation au niveau du domaine
	Restreindre la création et l'importation de clés de compte de service Utilisez des règles d'administration pour restreindre la création et l'importation de clés pour les comptes de service avec délégation au niveau du domaine. Cela limite l'emprunt d'identité des comptes de service via des clés de compte de service. Ne pas autoriser les utilisateurs à créer ou à importer des clés de compte de service.
	Désactiver l'attribution automatique de rôles pour les comptes de service par défaut Les comptes de service créés par défaut se voient attribuer le rôle Éditeur, qui leur permet de lire et de modifier toutes les ressources du projet Google Cloud. Vous pouvez désactiver l'attribution automatique de rôles pour les comptes de service par défaut afin qu'ils ne reçoivent pas automatiquement le rôle Éditeur et qu'ils ne puissent pas être facilement exploités par un utilisateur malveillant.  Ne pas utiliser l'attribution automatique de rôles pour les comptes de service par défaut.
	Limiter les mouvements latéraux Le mouvement latéral se produit lorsqu'un compte de service d'un projet est autorisé à usurper l'identité d'un compte de service d'un autre projet. Cela peut entraîner un accès non souhaité aux ressources. Utilisez les informations sur les mouvements latéraux pour détecter et limiter les mouvements latéraux en cas d'usurpation d'identité.  Utiliser les insights sur les mouvements latéraux pour limiter les mouvements latéraux
	Limiter l'accès aux comptes de service grâce à la délégation au niveau du domaine Ne laissez pas un utilisateur modifier la stratégie d'autorisation d'un compte de service si celui-ci dispose de plus de privilèges que l'utilisateur. Utilisez les rôles IAM pour limiter l'accès aux comptes de service avec des attributions de délégation au niveau du domaine.  Empêcher les utilisateurs de modifier les stratégies d'autorisation des comptes de service ayant plus de privilèges

Protéger les comptes de service contre les risques internes

N'utilisez la délégation au niveau du domaine que lorsqu'une étude de cas critique nécessite qu'une application contourne l'autorisation de l'utilisateur pour accéder aux données Google Workspace. Essayez d'autres méthodes, comme OAuth avec le consentement de l'utilisateur, ou utilisez des applications Marketplace. Pour en savoir plus, accédez à Google Workspace Marketplace.

Suivez ces bonnes pratiques pour protéger les comptes de service avec des droits de délégation au niveau du domaine contre les risques internes:

	N'accorder l'accès qu'aux droits essentiels Assurez-vous que les comptes de service bénéficiant d'une délégation au niveau du domaine ne disposent que des droits essentiels nécessaires à l'exécution de leurs tâches. N'accordez pas l'accès à des champs d'application OAuth non essentiels.
	Hébergez des comptes de service dans des projets Google Cloud dédiés Assurez-vous que les comptes de service bénéficiant d'une délégation au niveau du domaine sont hébergés dans des projets Google Cloud dédiés. N'utilisez pas ces projets pour d'autres besoins de l'entreprise.
	Éviter d'utiliser des clés de compte de service L'utilisation de clés de compte de service n'est pas nécessaire pour effectuer une délégation au niveau du domaine. Utilisez plutôt l'API signJwt.  Éviter d'utiliser des clés de compte de service pour la délégation au niveau du domaine
	Limiter l'accès aux projets délégués au niveau du domaine Réduisez le nombre de personnes autorisées à modifier les projets Google Cloud grâce à la délégation au niveau du domaine. Vous pouvez utiliser l'API Cloud Asset Inventory pour savoir qui a accès aux comptes de service. Par exemple, utilisez Cloud Shell pour exécuter: gcloud asset get-effective-iam-policy --scope=organizations/<ORG_ID> --names=//iam.googleapis.com/projects/<PROJECT_ID>/serviceAccounts/ <SERVICE_ACCOUNT_ID> ORG_ID: ID de votre organisation Google Cloud. En savoir plus PROJECT_ID: ID du projet Google Cloud sous lequel se trouve le compte de service. En savoir plus SERVICE_ACCOUNT_ID: ID du compte de service. L'ID figure sous "ID client" sur la page de délégation au niveau du domaine de la console d'administration ou dans l'adresse e-mail du compte de service. En savoir plus Recherchez des autorisations ou des rôles, tels que iam.serviceAccountTokenCreator ou iam.serviceAccountKeyAdmin, propriétaire et éditeur pour savoir qui dispose d'autorisations directes ou héritées sur le compte de service. Comprendre qui a accès aux comptes de service Google Cloud

Articles associés

• Checklists de sécurité
• Cloud Shell
• Contrôler l'accès à l'API à l'aide de la délégation au niveau du domaine