Bonnes pratiques pour planifier des comptes et des organisations

Last reviewed 2024-06-26 UTC

Ce document présente des bonnes pratiques pour déterminer le nombre de comptes Cloud Identity ou Google Workspace, d'organisations Google Cloud et de comptes de facturation à utiliser. Il fournit des conseils pour identifier une conception qui répond à vos exigences en termes de sécurité et d'organisation.

Dans Google Cloud, la gestion de l'authentification et des accès repose sur deux piliers :

  • Les comptes Cloud Identity et Google Workspace sont des conteneurs pour les utilisateurs et les groupes. Ils sont donc essentiels pour authentifier les utilisateurs de votre entreprise et gérer l'accès à vos ressources Google Cloud. Un compte Cloud Identity ou Google Workspace désigne un annuaire d'utilisateurs, et non un compte utilisateur individuel. Les comptes utilisateur individuels sont appelés utilisateurs ou comptes utilisateur.

  • Les organisations sont des conteneurs de projets et de ressources dans Google Cloud. Elles permettent de structurer de manière hiérarchique les ressources et sont essentielles pour les gérer de manière centralisée et efficace.

Ce document est principalement destiné aux clients qui configurent des environnements d'entreprise.

Comptes Cloud Identity et Google Workspace

Google Workspace est une suite intégrée qui réunit des applications de collaboration et de productivité cloud natives. Il inclut des outils permettant de gérer les utilisateurs, les groupes et l'authentification.

Cloud Identity propose un sous-ensemble des fonctionnalités de Google Workspace. Comme Google Workspace, Cloud Identity vous permet de gérer les utilisateurs, les groupes et l'authentification, mais il n'inclut pas toutes les fonctionnalités de collaboration et de productivité de Google Workspace.

Cloud Identity et Google Workspace partagent une plate-forme technique commune et utilisent le même ensemble d'API et d'outils d'administration. Les produits partagent le même concept de compte en tant que conteneur pour les utilisateurs et les groupes. Ce conteneur est identifié par un nom de domaine tel que example.com. En ce qui concerne la gestion des utilisateurs, des groupes et de l'authentification, les deux produits peuvent être considérés comme équivalents.

Combiner Cloud Identity et Google Workspace dans un seul compte

Étant donné que Cloud Identity et Google Workspace partagent une plate-forme commune, vous pouvez combiner l'accès aux produits dans un seul compte.

Si vous gérez déjà un compte Google Workspace et souhaitez autoriser davantage d'utilisateurs à utiliser Google Cloud, vous ne souhaitez peut-être pas accorder une licence Google Workspace à tous les utilisateurs. Dans ce cas, ajoutez Cloud Identity Free à votre compte existant. Vous pouvez ensuite ajouter davantage d'utilisateurs sans frais supplémentaires et choisir ceux qui ont accès à Google Workspace en leur attribuant une licence Google Workspace.

De même, si vous gérez déjà un compte Cloud Identity Free ou Premium, vous pouvez accorder à certains utilisateurs le droit d'utiliser Google Workspace. Plutôt que de créer d'autres comptes Google Workspace pour ces utilisateurs, vous pouvez ajouter Google Workspace à un compte Cloud Identity existant. Une fois que vous avez attribué la licence Google Workspace aux utilisateurs sélectionnés, ils peuvent utiliser les applications de productivité et de collaboration.

Utiliser le moins de comptes possible, mais autant de comptes que nécessaire

Pour permettre à vos utilisateurs de collaborer avec Google Workspace et réduire les frais d'administration, il est préférable de gérer tous les utilisateurs via un seul compte Cloud Identity ou Google Workspace et de fournir un compte utilisateur à chacun. Cette approche permet de garantir que les paramètres tels que les règles relatives aux mots de passe, l'authentification unique et la validation en deux étapes sont appliqués de manière cohérente à l'ensemble des utilisateurs.

Malgré les avantages liés à l'utilisation d'un seul compte Cloud Identity ou Google Workspace, l'utilisation de plusieurs comptes peut vous faire gagner en flexibilité et en autonomie administrative. Lorsque vous décidez du nombre de comptes Cloud Identity ou Google Workspace à utiliser, tenez compte de toutes les exigences qui suggèrent d'utiliser plusieurs comptes. Utilisez ensuite le nombre minimal de comptes Cloud Identity ou Google Workspace répondant à vos besoins.

Utiliser des comptes distincts pour la préproduction et la production

Pour la plupart des paramètres que vous pouvez configurer dans Cloud Identity et Google Workspace, vous pouvez choisir le niveau d'accès auquel chaque paramètre doit s'appliquer. Par exemple, vous pouvez spécifier l'emplacement géographique de vos données par utilisateur, par groupe ou par unité organisationnelle. Lorsque vous envisagez d'appliquer une nouvelle configuration, vous pouvez d'abord choisir un niveau d'accès limité (par utilisateur, par exemple) et vérifier si la configuration répond à vos attentes. Une fois la configuration validée, vous pouvez appliquer le même paramètre à un plus grand nombre de groupes ou d'unités organisationnelles.

Contrairement à la plupart des paramètres, l'intégration d'un compte Cloud Identity ou Google Workspace à un fournisseur d'identité externe a un impact global :

  • L'activation de l'authentification unique est un paramètre global qui s'applique à tous les utilisateurs, à l'exception des super-administrateurs.
  • Selon votre fournisseur d'identité externe, la configuration de la gestion des comptes utilisateur peut également avoir un impact global. Une erreur de configuration accidentelle dans le fournisseur d'identité externe peut entraîner la modification, la suspension ou la suppression accidentelle d'utilisateurs.

Pour limiter ces risques, vous devez disposer de comptes de préproduction et de production Cloud Identity ou Google Workspace distincts :

  • Utilisez le compte de préproduction pour vérifier les modifications de configuration risquées avant de les appliquer au compte de production.
  • Créez des utilisateurs de test dans les comptes de préproduction que vous et d'autres administrateurs pouvez utiliser afin de vérifier les modifications de configuration. Toutefois, n'accordez pas à vos utilisateurs l'accès au compte de préproduction.

Si vous avez des instances de préproduction et de production distinctes de votre fournisseur d'identité externe, procédez comme suit :

  • Intégrez votre compte Cloud Identity ou Google Workspace de préproduction à l'instance de préproduction de votre fournisseur d'identité externe.
  • Intégrez votre compte Cloud Identity ou Google Workspace de production à votre instance de production de votre fournisseur d'identité externe.

Par exemple, supposons que vous envisagiez de configurer la fédération avec Active Directory et que vous disposiez d'une forêt Active Directory distincte à des fins de test. Dans ce cas, vous intégrez votre compte de préproduction Cloud Identity ou Google Workspace à la forêt intermédiaire et le compte Cloud Identity ou Google Workspace de production à votre forêt principale. Appliquez la même approche de mappage aux domaines DNS, aux utilisateurs et aux groupes des deux paires forêt/compte, comme illustré dans le schéma suivant :

Approche de mappage Active Directory pour les domaines DNS, les utilisateurs et les groupes

Vos forêts et domaines Active Directory de production et de préproduction peuvent utiliser des domaines DNS qui ne vous permettent pas d'appliquer la même approche de mappage de domaines pour la préproduction et la production. Dans ce cas, envisagez d'enregistrer d'autres domaines de suffixe UPN (nom d'utilisateur principal) dans votre forêt de préproduction.

De même, si vous envisagez de configurer la fédération avec Azure Active Directory, il est préférable de suivre l'approche suivante :

  • Intégrez le compte Cloud Identity ou Google Workspace de préproduction à un locataire Azure Active Directory de préproduction.
  • Intégrez le compte Cloud Identity ou Google Workspace de production à votre locataire Azure Active Directory principal.

Appliquez la même approche de mappage aux domaines DNS, aux utilisateurs et aux groupes des deux paires locataire/compte :

Approche de mappage Azure Active Directory pour les domaines, les utilisateurs et les groupes DNS

Vos locataires Active Directory de production et de préproduction peuvent utiliser des domaines DNS qui ne vous permettent pas d'appliquer la même approche de mappage de domaines pour la préproduction et la production. Dans ce cas, envisagez d'ajouter un domaine supplémentaire à votre locataire de préproduction.

Utiliser des domaines DNS disjoints entre les comptes Cloud Identity et Google Workspace

Lorsque vous ajoutez pour la première fois un domaine tel que example.com à votre compte Cloud Identity ou Google Workspace, vous devez valider que vous êtes propriétaire du domaine. Une fois que vous avez ajouté et validé un domaine, vous pouvez ajouter des sous-domaines tels que marketing.example.com et finance.example.com sans avoir à les valider individuellement.

Toutefois, si vous ajoutez des sous-domaines sans les valider, des conflits peuvent survenir si vous disposez d'un autre compte Cloud Identity ou Google Workspace utilisant les mêmes sous-domaines. Pour éviter ces conflits, utilisez plutôt des domaines disjoints pour chaque compte. Par exemple, si vous avez besoin de deux comptes Cloud Identity ou Google Workspace, évitez d'utiliser deux domaines dont l'un est un sous-domaine de l'autre. Utilisez plutôt deux domaines qui ne sont pas des sous-domaines d'un autre. Cette pratique s'applique au domaine principal et aux domaines secondaires.

Ne pas séparer Google Workspace de Google Cloud

Si vous utilisez déjà Google Workspace, certains utilisateurs de votre compte Google Workspace ont peut-être reçu des droits de super-administrateur leur permettant d'effectuer des tâches d'administration.

Les utilisateurs disposant de droits de super-administrateur sont implicitement autorisés à modifier la stratégie IAM (Identity and Access Management) du nœud d'organisation. Cette autorisation permet aux super-administrateurs de s'attribuer le rôle d'administrateur de l'organisation ou tout autre rôle dans l'organisation Google Cloud. Le fait de disposer d'un accès super-administrateur à un compte Cloud Identity ou Google Workspace permet également à un utilisateur de supprimer le compte, l'organisation Google Cloud qui y est associée et toutes les ressources. Vous devez donc partir du principe que les super-administrateurs ont un accès complet à toutes les ressources d'une organisation.

Le fait que les super-administrateurs soient également des administrateurs de l'organisation peut constituer un problème de sécurité si vos administrateurs Google Workspace existants sont différents des utilisateurs chargés de gérer votre organisation Google Cloud. Dans ce cas, vous pouvez décider de créer un compte Cloud Identity distinct dédié à Google Cloud afin de limiter l'accès des super-administrateurs Google Workspace aux ressources Google Cloud. Séparer Google Workspace de Google Cloud peut avoir plusieurs conséquences inattendues.

Par exemple, vous pouvez essayer de créer des utilisateurs distincts dans le compte Cloud Identity, puis restreindre l'accès des utilisateurs de l'organisation Google Cloud au compte Cloud Identity. Ainsi, votre déploiement Google Cloud et Google Workspace sont complètement isolés. Cependant, la duplication des utilisateurs a un impact négatif à la fois sur l'expérience utilisateur et les frais d'administration. En outre, vous ne pouvez pas recevoir d'e-mails de notification envoyés par Google Cloud. Le domaine utilisé par Cloud Identity doit être différent du domaine utilisé pour Google Workspace et n'est donc pas adapté au routage des e-mails.

Si vous référencez plutôt des utilisateurs du compte Google Workspace dans votre organisation Google Cloud, vous compromettez l'isolation entre Google Workspace et Google Cloud :

Référencer des utilisateurs du compte Google Workspace dans votre organisation Google Cloud

Les super-administrateurs Google Workspace peuvent utiliser la délégation au niveau du domaine pour emprunter l'identité d'un utilisateur du même compte Google Workspace. Un super-administrateur frauduleux pourrait utiliser ses privilèges élevés pour récupérer l'accès à Google Cloud.

Une approche plus efficace que l'utilisation de comptes distincts consiste à séparer les responsabilités entre les administrateurs Google Workspace et Google Cloud afin de réduire le nombre de super-administrateurs :

Sécuriser votre fournisseur d'identité externe lors de l'utilisation de l'authentification unique

Cloud Identity et Google Workspace vous permettent de configurer l'authentification unique en faisant appel à un fournisseur d'identité externe tel qu'Active Directory, Azure Active Directory ou Okta (pour n'en citer que quelques-uns). Si l'authentification unique est activée, Cloud Identity et Google Workspace font confiance au fournisseur d'identité externe pour authentifier les utilisateurs au nom de Google.

L'activation de l'authentification unique offre plusieurs avantages :

  • Les utilisateurs peuvent utiliser leurs identifiants existants pour se connecter aux services Google.
  • Les utilisateurs n'ont pas besoin de saisir à nouveau leur mot de passe s'ils disposent déjà d'une session de connexion.
  • Vous pouvez appliquer des règles d'authentification multifacteurs cohérentes à l'ensemble de vos applications et de tous les services Google.

Toutefois, l'activation de l'authentification unique entraîne également des risques. Lorsque l'authentification unique est activée et qu'un utilisateur doit être authentifié, celui-ci sera redirigé par Cloud Identity ou Google Workspace vers votre fournisseur d'identité externe. Après avoir authentifié l'utilisateur, le fournisseur d'identité renvoie à Google une assertion SAML indiquant l'identité de l'utilisateur. L'assertion SAML est signée. Par conséquent, Google peut vérifier l'authenticité de l'assertion SAML et vérifier que le bon fournisseur d'identité a été utilisé. Cependant, Cloud Identity ou Google Workspace ne peuvent pas vérifier que le fournisseur d'identité a pris la bonne décision d'authentification et indiqué correctement l'identité de l'utilisateur.

Si l'authentification unique est activée, la sécurité et l'intégrité globales de votre déploiement Google dépendent de la sécurité et de l'intégrité de votre fournisseur d'identité. Votre compte Cloud Identity ou Google Workspace et toutes les ressources qui dépendent des utilisateurs gérés par le compte sont menacés si l'un des éléments suivants est configuré de manière non sécurisée :

  • Le fournisseur d'identité lui-même
  • Les machines sur lesquelles le fournisseur s'exécute
  • La base de données utilisateur à partir de laquelle le fournisseur récupère les informations utilisateur
  • Tout autre système dont dépend le fournisseur

Pour éviter que l'authentification unique ne devienne un maillon faible dans votre stratégie de sécurité, assurez-vous que votre fournisseur d'identité et tous les systèmes dont il dépend sont sécurisés :

  • Limitez le nombre d'utilisateurs disposant d'un accès administrateur à votre fournisseur d'identité ou à l'un des systèmes dont le fournisseur dépend.
  • N'accordez pas d'accès administrateur à ces systèmes aux utilisateurs auxquels vous n'accorderiez pas de droits de super-administrateur dans Cloud Identity ou Google Workspace.
  • N'utilisez pas l'authentification unique si vous n'êtes pas sûr des contrôles de sécurité mis en place pour votre IdP externe.

Sécuriser l'accès à vos zones DNS

Les comptes Cloud Identity et Google Workspace sont identifiés par un nom de domaine DNS principal. Lorsque vous créez un compte Cloud Identity ou Google Workspace, vous devez valider la propriété du domaine DNS en créant un enregistrement DNS spécial dans la zone DNS correspondante.

L'importance du DNS et son impact sur la sécurité globale de votre déploiement Google vont au-delà du processus d'inscription :

  • Google Workspace s'appuie sur les enregistrements MX du DNS pour le routage des e-mails. En modifiant ces enregistrements MX, un pirate informatique peut être en mesure de rediriger les e-mails vers un autre serveur et d'accéder à des informations sensibles.

  • Si un pirate informatique peut ajouter des enregistrements à la zone DNS, il peut alors réinitialiser le mot de passe d'un super-administrateur et accéder au compte.

Pour éviter que le DNS ne devienne un maillon faible dans votre stratégie de sécurité, assurez-vous que votre serveur DNS est configuré de manière sécurisée :

  • Limitez le nombre d'utilisateurs disposant d'un accès administrateur au serveur DNS qui gère le domaine principal utilisé pour Cloud Identity ou Google Workspace.

  • N'accordez pas d'accès administrateur à votre serveur DNS aux utilisateurs auxquels vous n'accorderiez pas de droits de super-administrateur dans Cloud Identity ou Google Workspace.

  • Si vous envisagez de déployer sur Google Cloud une charge de travail dont les exigences de sécurité ne sont pas satisfaites par votre infrastructure DNS existante, envisagez d'enregistrer un nouveau domaine DNS utilisant des serveurs DNS distincts ou un service DNS géré.

Exporter les journaux d'audit vers BigQuery

Cloud Identity et Google Workspace conservent plusieurs journaux d'audit pour effectuer le suivi des modifications de configuration et d'autres activités susceptibles d'être pertinentes pour la sécurité de votre compte Cloud Identity ou Google Workspace. Le tableau suivant récapitule ces journaux d'audit.

Journal Activités capturées
Administrateur Actions effectuées dans la console d'administration Google
Se connecter Tentatives de connexion réussies, non réussies et suspectes à votre domaine
Jeton Instances autorisant ou révoquant l'accès aux applications Web ou mobiles tierces
Groupes Modifications apportées aux groupes et aux adhésions aux groupes

Vous pouvez accéder à ces journaux d'audit via la Console d'administration ou via l'API de création de rapports. Pour la plupart des journaux d'audit, les données sont conservées pendant six mois.

Si vous travaillez dans un secteur réglementé, la conservation des données d'audit pendant six mois peut ne pas être suffisante. Pour conserver les données plus longtemps, configurez l'exportation des journaux d'audit vers BigQuery.

Pour limiter le risque d'accès non autorisé aux journaux d'audit exportés, utilisez un projet Google Cloud dédié pour l'ensemble de données BigQuery. Pour protéger les données d'audit contre la falsification ou la suppression, accordez l'accès au projet et à l'ensemble de données en suivant le principe du moindre privilège.

Les journaux d'audit Cloud Identity et Google Workspace et les journaux Cloud Audit Logging sont complémentaires. Si vous utilisez également BigQuery pour collecter des journaux Cloud Audit Logging et d'autres journaux d'audit spécifiques à une application, vous pouvez mettre en corrélation les événements de connexion aux activités effectuées par un utilisateur dans Google Cloud ou dans vos applications. Le fait de pouvoir corréler les données d'audit dans plusieurs sources peut vous aider à détecter et à analyser les activités suspectes.

La configuration de l'exportation BigQuery nécessite une licence Google Workspace Enterprise. Une fois les journaux d'audit principaux configurés, ils sont exportés pour tous les utilisateurs, y compris ceux qui ne disposent pas d'une licence Google Workspace. Certains journaux, tels que les journaux d'audit Drive et Mobile, sont exportés pour les utilisateurs disposant d'au moins une licence Google Workspace Business.

Si vous utilisez Cloud Identity Free pour la majorité de vos utilisateurs, vous pouvez toujours exporter vers BigQuery en ajoutant Google Workspace Enterprise à votre compte Cloud Identity existant et en achetant des licences Google Workspace pour certains administrateurs.

Organisations

Les organisations vous permettent d'organiser les ressources dans une hiérarchie de projets et de dossiers, le nœud d'organisation étant la racine. Les organisations sont associées à un compte Cloud Identity ou Google Workspace et sont nommées à partir du domaine principal du compte associé. Une organisation est créée automatiquement lorsqu'un utilisateur du compte Cloud Identity ou Google Workspace crée un premier projet.

Chaque compte Cloud Identity ou Google Workspace ne peut avoir qu'une seule organisation. Il n'est pas possible de créer une organisation sans un compte correspondant. Malgré cette dépendance, vous pouvez accorder aux utilisateurs de plusieurs comptes différents l'accès aux ressources d'une même organisation :

Autoriser l'accès aux ressources aux utilisateurs de plusieurs comptes

La flexibilité de référencer les utilisateurs de différents comptes Cloud Identity ou Google Workspace vous permet de séparer la manière dont vous traitez les comptes et les organisations. Vous pouvez séparer le nombre de comptes Cloud Identity ou Google Workspace dont vous avez besoin pour gérer vos utilisateurs du nombre d'organisations dont vous avez besoin pour gérer vos ressources.

Le nombre d'organisations que vous créez et leurs objectifs peuvent avoir un impact profond sur votre stratégie de sécurité, l'autonomie de vos équipes et de vos services, ainsi que la cohérence et l'efficacité de votre administration.

Les sections suivantes décrivent les bonnes pratiques pour choisir le nombre d'organisations à utiliser.

Utiliser le moins d'organisations possible, mais autant d'organisations que nécessaire

La hiérarchie des ressources d'une organisation vous permet de réduire les efforts de gestion des stratégies IAM et des règles d'administration grâce à l'héritage. En configurant des règles au niveau du dossier ou de l'organisation, vous vous assurez qu'elles sont appliquées de manière cohérente dans une sous-hiérarchie de ressources et vous évitez la répétition des tâches de configuration. Afin de réduire les frais d'administration, il est préférable d'utiliser le moins d'organisations possible.

En revanche, l'utilisation de plusieurs organisations peut vous faire gagner en flexibilité et en autonomie administrative. Dans les sections suivantes, nous allons voir les cas dans lesquels vous pourriez avoir besoin d'une flexibilité ou autonomie supplémentaire.

Dans tous les cas, lorsque vous décidez du nombre d'organisations à utiliser, tenez compte de toutes les exigences qui suggèrent d'utiliser plusieurs organisations. Utilisez ensuite le nombre minimal d'organisations répondant à vos besoins.

Utiliser des organisations pour définir l'autorité administrative

Dans une hiérarchie de ressources, vous pouvez accorder des autorisations au niveau de la ressource, du projet ou du dossier. L'organisation est le niveau final pour lequel vous pouvez accorder des autorisations à un utilisateur.

Un utilisateur auquel a été attribué le rôle Administrateur de l'organisation au niveau de l'organisation dispose d'un contrôle total sur l'organisation, ses ressources et ses stratégies IAM. Un administrateur d'organisation peut prendre le contrôle de n'importe quelle ressource de l'organisation et peut déléguer l'accès administrateur à un autre utilisateur.

Cependant, les capacités d'un administrateur d'organisation sont limitées à l'organisation, faisant de celle-ci le niveau d'accès ultime en ce qui concerne l'autorité administrative :

  • Un administrateur d'organisation ne peut pas accéder aux ressources d'autres organisations, à moins d'avoir défini explicitement l'autorisation.
  • Aucun utilisateur extérieur à l'organisation ne peut supprimer le contrôle à un administrateur de cette organisation.

Le nombre approprié d'organisations à utiliser dépend du nombre de groupes d'administrateurs indépendants dans votre entreprise :

  • Si votre entreprise est organisée par fonction, vous pouvez avoir un seul service chargé de superviser tous les déploiements de Google Cloud.
  • Si votre entreprise est organisée par division ou possède un certain nombre de filiales gérées de manière autonome, il se peut qu'aucun service ne soit responsable.

Si un seul service est chargé de superviser les déploiements Google Cloud, il est préférable d'utiliser un seul nœud d'organisation Google Cloud. Au sein de l'organisation, utilisez des dossiers pour structurer les ressources et accorder différents niveaux d'accès à d'autres équipes et services.

Si vous travaillez avec plusieurs services indépendants, essayez de centraliser l'administration en utilisant une seule organisation :

  • Si vous désignez un seul service pour la gestion de l'organisation, vous risquez de rencontrer des réticences de la part d'autres services.
  • Si plusieurs équipes ou services deviennent copropriétaires d'une même organisation, il peut être difficile de maintenir une hiérarchie des ressources cohérente et de s'assurer que les stratégies IAM et les règles d'administration sont utilisées de manière cohérente entre les ressources.

Pour éviter ce type de problème, utilisez plusieurs organisations et créez des structures de dossiers distinctes dans chaque organisation. En utilisant des organisations distinctes, vous établissez des limites entre les différents groupes d'administrateurs, définissant ainsi leur autorité administrative.

Utiliser une organisation de préproduction distincte

Pour garantir la cohérence et éviter les tâches de configuration répétitives, organisez vos projets selon une hiérarchie de dossiers et appliquez les stratégies IAM et les règles d'administration au niveau du dossier ou de l'organisation.

Toutefois, l'application de règles à de nombreux projets et ressources présente un inconvénient. Toute modification de la règle elle-même ou de la hiérarchie des ressources à laquelle la règle s'applique peut avoir des conséquences importantes et inattendues. Pour limiter ce risque, il est préférable de tester les modifications apportées aux règles avant de les appliquer dans votre organisation principale.

Nous vous recommandons de créer une organisation de préproduction distincte. Cette organisation vous aide à tester les modifications de la hiérarchie des ressources, les stratégies IAM, les règles d'administration ou toute autre configuration susceptible d'avoir un impact à l'échelle de l'organisation, comme les niveaux d'accès et les stratégies.

Pour vous assurer que les résultats des tests effectués dans l'organisation de préproduction s'appliquent également à l'organisation de production, configurez celle-ci de sorte qu'elle utilise la même structure de dossiers que votre organisation principale, mais avec seulement un petit nombre de projets. À tout moment, les stratégies IAM et les règles d'administration de l'organisation de préproduction doivent correspondre aux règles de votre organisation de production, ou doivent refléter la prochaine version des règles que vous souhaitez appliquer à votre organisation de production.

Comme le montre le diagramme suivant, vous utilisez votre compte Cloud Identity ou Google Workspace de préproduction comme base pour l'organisation de préproduction. Vous utilisez le compte de préproduction (ou le fournisseur d'identité externe auquel votre compte de préproduction est intégré) pour créer des utilisateurs de test dédiés et une structure de groupe qui reflète les groupes que vous utilisez dans votre compte Cloud Identity ou Google Workspace de production. Vous pouvez ensuite utiliser ces groupes et utilisateurs de test dédiés pour tester les stratégies IAM sans affecter les utilisateurs existants.

Utilisation de votre compte comme base de préproduction

Éviter d'utiliser une organisation de test distincte

Pour chaque charge de travail de production que vous prévoyez de déployer sur Google Cloud, vous avez probablement besoin d'un ou de plusieurs environnements de test que vos équipes de développement et DevOps peuvent utiliser pour valider les nouvelles versions.

Du point de vue de la sécurité, afin d'éviter que les versions non testées n'affectent accidentellement les charges de travail de production, vous devez séparer correctement vos environnements de test de vos environnements de production. De même, les deux types d'environnement ont des exigences différentes en ce qui concerne les stratégies IAM. Par exemple, pour que vous puissiez accorder aux développeurs et aux testeurs la flexibilité dont ils ont besoin, les exigences de sécurité de vos environnements de test peuvent être beaucoup plus strictes que celles de vos environnements de production.

Comme le montre le schéma suivant, du point de vue de la configuration, vous souhaitez que vos environnements de test et de production soient soient aussi similaires que possible. Toute différence augmente le risque qu'un déploiement qui fonctionne correctement dans un environnement de test échoue lorsqu'il est déployé dans un environnement de production.

Maintenir des environnements de test et de production similaires

Pour trouver un équilibre entre l'isolement et la cohérence des environnements, utilisez les dossiers d'une même organisation pour gérer les environnements de test et de production :

  • Appliquez les stratégies IAM ou les règles d'administration communes aux environnements au niveau de l'organisation (ou utilisez un dossier parent commun).
  • Utilisez les dossiers individuels pour gérer les stratégies IAM et les règles d'administration qui diffèrent selon les types d'environnements.

N'utilisez pas votre organisation de préproduction pour gérer les environnements de test. Les environnements de test sont essentiels à la productivité des équipes de développement et DevOps. La gestion de ces environnements dans votre environnement de préproduction limiterait votre capacité à utiliser l'organisation de préproduction pour tester les modifications apportées aux règles, perturbant éventuellement le travail de ces équipes. En utilisant une organisation de préproduction pour gérer les environnements de test, vous compromettez l'objectif de celle-ci.

Utiliser une organisation distincte pour les test

Pour tirer pleinement parti de Google Cloud, laissez vos équipes chargées du développement, du DevOps et des opérations se familiariser avec la plate-forme et accroître leur expérience en exécutant des tutoriels. Encouragez-les à tester de nouvelles fonctionnalités et de nouveaux services.

Utilisez une organisation distincte comme environnement de bac à sable pour favoriser ce type d'activités expérimentales. En utilisant une organisation distincte, les tests seront libres de toute règle, configuration ou automatisation que vous utilisez dans votre organisation de production.

Évitez d'utiliser votre organisation de préproduction pour les tests. Votre environnement de préproduction doit utiliser des stratégies IAM et des règles d'administration similaires à celles de votre organisation de production. Par conséquent, l'environnement de préproduction est susceptible d'être soumis aux mêmes limitations que votre environnement de production. En même temps, assouplir les règles en autorisant les tests compromettrait l'objectif de votre organisation de préproduction.

Pour éviter que votre organisation de test ne soit désorganisée, génère des coûts excessifs ou constitue un risque pour la sécurité, publiez des consignes qui définissent la manière dont les équipes sont autorisées à utiliser l'organisation et qui en est responsable. En outre, envisagez d'automatiser la suppression automatique de ressources ou même de projets entiers après un certain nombre de jours.

Comme le montre le diagramme suivant, lorsque vous créez une organisation à des fins de test, vous créez d'abord un compte Cloud Identity dédié. Vous utilisez ensuite les utilisateurs existants de votre compte Cloud Identity ou Google Workspace principal pour leur accorder l'accès à l'organisation de test.

Organisation de test

Pour gérer le compte Cloud Identity supplémentaire, vous devez disposer d'au moins un compte super-administrateur dans le compte Cloud Identity. Pour en savoir plus sur la manière de sécuriser ces comptes super-administrateur, consultez l'article Bonnes pratiques concernant les comptes super-administrateur.

Utiliser le partage limité au domaine pour appliquer des relations de confiance

Les stratégies IAM vous permettent d'ajouter une identité Google valide en tant que membre. Cela signifie que lorsque vous modifiez la stratégie IAM d'une ressource, d'un projet, d'un dossier ou d'une organisation, vous pouvez ajouter des membres à partir de différentes sources, dont les suivantes :

  • Les utilisateurs du compte Cloud Identity ou Google Workspace auquel l'organisation est associée, ainsi que les comptes de service de la même organisation
  • Des utilisateurs d'autres comptes Cloud Identity ou Google Workspace
  • Des comptes de service d'autres organisations
  • Des comptes utilisateur personnels, y compris des utilisateurs gmail.com et des comptes personnels utilisant une adresse e-mail professionnelle

La possibilité de référencer des utilisateurs provenant de différentes sources est utile pour les situations et les projets dans lesquels vous devez collaborer avec des affiliés ou d'autres entreprises. Dans la plupart des autres cas, il est préférable de limiter les stratégies IAM pour autoriser uniquement les membres provenant de sources fiables.

Utilisez le partage limité au domaine pour définir un ensemble de comptes Cloud Identity ou Google Workspace de confiance auxquels vous souhaitez accorder l'autorisation d'ajouter des membres aux stratégies IAM. Définissez cette règle d'administration au niveau de l'organisation (afin qu'elle s'applique à tous les projets) ou dans un dossier situé en haut de la hiérarchie des ressources (pour que certains projets en soient exonérés).

Si vous utilisez des comptes et des organisations Cloud Identity ou Google Workspace distincts pour séparer les environnements de préproduction, de production et de test, servez-vous des règles de partage limité au domaine pour appliquer la séparation, comme indiqué dans le tableau suivant :

Organisation Compte Cloud Identity ou Google Workspace de confiance
Préproduction Préproduction
Production Production
Tests Production

Utiliser des noms de domaine neutres pour les organisations

Les organisations sont identifiées par un nom de domaine DNS tel que example.com. Le nom de domaine est dérivé du nom de domaine principal du compte Cloud Identity ou Google Workspace associé.

Si toute votre entreprise utilise un nom de domaine DNS canonique, utilisez ce nom comme domaine principal dans votre compte Cloud Identity ou Google Workspace de production. En utilisant le nom DNS canonique, les employés reconnaîtront facilement le nom du nœud d'organisation.

Si votre entreprise possède plusieurs filiales ou plusieurs marques différentes, il se peut qu'elle n'ait pas de nom de domaine canonique. Au lieu de choisir l'un des domaines existants, envisagez d'enregistrer un nouveau domaine DNS neutre dédié à Google Cloud. En utilisant un nom DNS neutre, vous évitez d'exprimer une préférence pour une marque, une filiale ou un service spécifique de votre entreprise, ce qui pourrait avoir un impact négatif sur l'adoption du cloud. Ajoutez vos autres domaines spécifiques à la marque en tant que domaines secondaires afin qu'ils puissent être utilisés dans les ID utilisateur et pour l'authentification unique.

Utiliser des comptes de facturation dans toutes les organisations Google Cloud

Les comptes de facturation servent à déterminer qui assume les frais pour un ensemble donné de ressources Google Cloud. Bien que les comptes de facturation puissent exister en dehors d'une organisation Google Cloud, ils sont le plus souvent associés à une organisation.

Lorsque les comptes de facturation sont associés à une organisation, ils sont considérés comme une sous-ressource de l'organisation et sont soumis aux stratégies IAM définies au sein de l'organisation. En outre, cela implique que vous pouvez utiliser les rôles IAM de facturation pour définir les utilisateurs ou les groupes autorisés à administrer ou à utiliser un compte.

Un utilisateur disposant du rôle Billing Account User peut associer un projet à un compte de facturation de façon à ce que les ressources soient facturées sur ce compte. L'association d'un projet à un compte de facturation fonctionne au sein de la même organisation, mais également entre plusieurs organisations.

Si vous utilisez plusieurs organisations, vous pouvez profiter du fait que les comptes de facturation peuvent être utilisés dans plusieurs organisations. Cela vous permet de décider du nombre de comptes de facturation dont vous avez besoin indépendamment du nombre d'organisations dont vous avez besoin.

Le nombre approprié de comptes de facturation dépend exclusivement de vos exigences professionnelles ou contractuelles, telles que la devise, le profil de paiement et le nombre de factures distinctes dont vous avez besoin. Comme pour les comptes et les organisations, afin de réduire la complexité, privilégiez l'utilisation du nombre minimal de comptes de facturation répondant à vos exigences.

Pour ventiler les coûts générés par plusieurs organisations, configurez votre compte de facturation de manière à exporter les données de facturation vers BigQuery. Chaque enregistrement exporté vers BigQuery contient non seulement le nom et l'ID du projet, mais également l'ID de l'organisation à laquelle le projet est associé (dans le champ project.ancestry_numbers).

Étapes suivantes