Bonnes pratiques concernant la délégation au niveau du domaine

En tant qu'administrateur, vous pouvez utiliser la délégation au niveau du domaine pour autoriser les applications internes et tierces à accéder aux données Google Workspace de vos utilisateurs, sans avoir besoin 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 niveaux d'accès à l'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 pour utiliser les comptes de service afin de limiter l'accès et de se protéger contre les menaces d'élévation des privilèges et de non-répudiation. Pour consulter les consignes, accédez à 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 quelques pratiques à retenir :

Utiliser plutôt l'accès direct au compte de service ou l'autorisation OAuth

Évitez d'utiliser une délégation au niveau du domaine si vous pouvez accomplir votre tâche directement avec un compte de service ou en utilisant l'autorisation 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 limiter 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é de compte de service à l'aide de clés de compte de service.

Ne pas autoriser les utilisateurs à créer ni à importer des clés de compte de service

Désactiver l'attribution de rôles automatique pour les comptes de service par défaut

Les comptes de service créés par défaut se voient attribuer le rôle d'éditeur, ce 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 de vous assurer qu'ils ne reçoivent pas automatiquement le rôle Éditeur et qu'ils ne peuvent 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 involontaire aux ressources. Utilisez les "insights sur les mouvements latéraux" pour détecter et limiter les mouvements latéraux par 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 avec 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 autorisations 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 si vous avez un cas d'utilisation professionnel critique qui nécessite qu'une application contourne le consentement de l'utilisateur pour accéder aux données Google Workspace. Essayez d'autres solutions, comme OAuth avec consentement de l'utilisateur, ou utilisez des applications Marketplace. Pour en savoir plus, consultez Google Workspace Marketplace.

Suivez ces bonnes pratiques pour protéger les comptes de service disposant de 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 avec délégation à l'échelle du domaine ne disposent que des droits essentiels à l'exécution de leurs fonctions prévues. N'accordez pas l'accès aux habilitations OAuth non essentielles.

Héberger les comptes de service dans des projets Google Cloud dédiés

Assurez-vous que les comptes de service avec 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 professionnels.

Éviter d'utiliser des clés de compte de service

Les clés de compte de service ne sont pas nécessaires 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 disposant d'une délégation à l'échelle du domaine

Limitez le nombre de personnes autorisées à modifier les projets Google Cloud pour lesquels la délégation à l'échelle du domaine est configurée. 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 réside le compte de service. En savoir plus
  • SERVICE_ACCOUNT_ID : ID du compte de service. L'ID est indiqué 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 propriétaire et éditeur iam.serviceAccountKeyAdmin pour savoir qui dispose d'autorisations directes ou héritées pour le compte de service.

Comprendre qui a accès aux comptes de service Google Cloud