Choisir une hiérarchie de ressources pour votre zone de destination Google Cloud

Last reviewed 2023-08-31 UTC

Une hiérarchie de ressources permet d'organiser vos ressources dans Google Cloud. Ce document explique comment choisir la hiérarchie de vos ressources dans le cadre de la conception de votre zone de destination. Il est destiné aux administrateurs, architectes et techniciens de systèmes cloud impliqués dans la conception de la hiérarchie des ressources. Ce document fait partie d'une série consacrée aux zones de destination. Il comprend des exemples de hiérarchies illustrant les méthodes courantes auxquelles les entreprises peuvent faire appel pour structurer leurs ressources dans Google Cloud.

Facteurs intervenant dans la conception de la hiérarchie des ressources

Lorsque vous définissez la hiérarchie de vos ressources dans Google Cloud, vous devez prendre en compte le fonctionnement actuel de votre organisation et l'état final idéal de votre transformation cloud. La meilleure façon de gérer les ressources dépend de la manière dont votre organisation souhaite travailler dans le cloud. Comme chaque organisation est différente, il n'existe pas d'approche unique et optimale pour la hiérarchie des ressources.

Toutefois, nous vous recommandons d'éviter de mapper la structure de votre organisation à la hiérarchie des ressources. Concentrez-vous plutôt sur vos besoins et opérations métier dans Google Cloud.

Hiérarchie des ressources Google Cloud

La hiérarchie des ressources dans Google Cloud commence au niveau du nœud racine, appelé organisation. Nous recommandons aux entreprises de n'avoir qu'un seul nœud racine, sauf dans certains cas. Vous définissez les niveaux inférieurs de la hiérarchie à l'aide de dossiers et de projets, et vous créez des dossiers au sein des dossiers pour mettre en place votre hiérarchie. Vous pouvez créer les projets qui hébergent vos charges de travail à n'importe quel niveau de la hiérarchie.

Le schéma suivant présente un nœud racine appelé Organization et des dossiers aux niveaux 1, 2 et 3. Les projets et les sous-dossiers sont créés sous les dossiers du niveau 2.

Exemple de hiérarchie comportant un nœud racine, des dossiers et des projets.

Facteurs de la hiérarchie des ressources

Lorsque vous choisissez la hiérarchie des ressources, tenez compte des facteurs suivants :

  • Qui est responsable des ressources cloud ? S'agit-il de vos services, filiales, équipes techniques ou entités juridiques ?
  • Quels sont vos besoins en termes de conformité ?
  • Des événements d'entreprise, tels que des fusions, des acquisitions ou des scissions, sont-ils prévus dans un avenir proche ?

Comprendre les interactions entre ressources dans l'ensemble de la hiérarchie

Dans la hiérarchie des ressources, les règles d'administration sont héritées par les descendants, mais elles peuvent être remplacées par des règles définies à un niveau inférieur. Pour en savoir plus, consultez la page Comprendre le processus d'évaluation hiérarchique. Les contraintes de règles d'administration permettent de définir des consignes concernant l'ensemble ou une partie importante de l'organisation, tout en autorisant les exceptions.

Les stratégies d'autorisation, anciennement appelées stratégies IAM, sont héritées par les descendants, et les stratégies d'autorisation à des niveaux inférieurs s'ajoutent les unes aux autres. Toutefois, les stratégies d'autorisation peuvent être remplacées par des stratégies de refus, qui vous permettent de limiter les autorisations au niveau du projet, du dossier et de l'organisation. Les règles de refus sont appliquées avant les règles d'autorisation.

Vous devez également tenir compte des points suivants :

Points de décision pour la conception de la hiérarchie des ressources

L'organigramme ci-dessous montre les éléments à prendre en compte pour choisir la meilleure hiérarchie de ressources pour votre organisation.

Décisions relatives aux hiérarchies de ressources.

Le schéma précédent décrit les points de décision suivants :

  1. Les différents groupes régionaux, filiales ou unités commerciales ont-ils des exigences très différentes au niveau réglementaire ?
    1. Si oui, suivez l'option de conception basée sur la région ou les filiales.
    2. Dans le cas contraire, passez au point de décision suivant.

  2. Vos charges de travail ou vos équipes produit nécessitent-elles une forte autonomie concernant leurs règles ? Par exemple, vous ne disposez pas d'une équipe de sécurité centrale qui détermine les stratégies pour toutes les équipes chargées des produits ou des charges de travail.

    1. Si oui, reportez-vous à l'option de conception basée sur un framework de responsabilité.

    2. Si ce n'est pas le cas, consultez l'option de conception basée sur l'environnement de l'application.

Votre cas d'utilisation spécifique peut vous amener à concevoir une hiérarchie de ressources différente de celle suggérée par le graphique de décision. La plupart des entreprises adoptent une approche hybride et sélectionnent des conceptions différentes à différents niveaux de la hiérarchie des ressources, en commençant par la conception qui affecte le plus les stratégies et les accès.

Option 1 : Hiérarchie basée sur les environnements d'application

Dans de nombreuses organisations, vous définissez des règles et contrôles d'accès distincts pour différents environnements d'application, tels que le développement, la production et les tests. Des règles distinctes standardisées dans chaque environnement facilitent la gestion et la configuration. Par exemple, vous pouvez avoir des règles de sécurité plus strictes dans les environnements de production que pour les environnements de test.

Utilisez une hiérarchie basée sur les environnements d'application si les conditions suivantes sont remplies :

  • Vous avez des environnements d'application distincts, qui ont des exigences différentes en matière de règles et d'administration.
  • Vous avez des exigences de sécurité ou d'audit centralisées qu'une équipe de sécurité centrale doit pouvoir appliquer de manière cohérente sur toutes les charges de travail et données de production.
  • Vous avez besoin de différents rôles IAM (Identity and Access Management) pour accéder à vos ressources Google Cloud dans les différents environnements.

Évitez ce type de hiérarchie si les conditions suivantes sont remplies :

  • Vous n'exécutez pas plusieurs environnements d'application.
  • Vous n'avez pas de dépendances d'applications ou de processus métier qui varient d'un environnement à l'autre.
  • Il existe des différences importantes dans vos règles suivant les régions, les équipes ou les applications.

Le schéma suivant illustre une hiérarchie pour example.com, une entreprise fictive de technologies financières.

Schéma de l'option 1.

Comme le montre le schéma précédent, example.com possède trois environnements d'application avec des stratégies, des contrôles d'accès, des exigences réglementaires et des processus différents. Les environnements sont les suivants :

  • Environnement de développement et de contrôle qualité : cet environnement est géré par des développeurs constitués à la fois d'employés internes et de consultants. Ils produisent en permanence du code et sont responsables du contrôle qualité. Cet environnement n'est jamais accessible aux utilisateurs de votre entreprise. L'environnement présente des exigences d'intégration et d'authentification moins strictes que l'environnement de production, et les développeurs reçoivent des rôles approuvés dotés des autorisations adéquates. L'environnement de développement et de contrôle qualité n'est conçu que pour les offres d'applications standards de example.com.

  • Environnement de test : cet environnement est utilisé pour les tests de régression et d'applications. Il est compatible avec les offres business-to-business (B2B) des clients example.com qui utilisent des API example.com. À cet effet, example.com crée deux types de projets :

    • Les projets de tests internes, servant à réaliser les tests internes de régression, de performances et de configuration pour les offres B2B.
    • Les projets d'UAT client mutualisés afin que les clients B2B puissent valider leurs configurations et s'adapter aux exigences d'example.com en termes d'expérience utilisateur, d'utilisation de la marque, de branding, de workflows, de rapports, etc.

  • Environnement de production : cet environnement héberge toutes les offres de produits ayant été validées, acceptées et lancées. Cet environnement est soumis aux règles de la norme PCI DSS (Payment Card Industry Data Security Standard), utilise des modules de sécurité matériels (HSM) et s'intègre aux processeurs tiers pour des éléments tels que l'authentification et le règlement des paiements. Les équipes d'audit et de conformité sont des intervenants critiques dans cet environnement. L'accès à cet environnement est étroitement contrôlé et limité principalement aux processus de déploiement automatisés.

Pour en savoir plus sur la conception d'une hiérarchie basée sur les environnements d'application, consultez la page Structure organisationnelle du plan de base de l'entreprise

Option 2 : Hiérarchie basée sur les régions ou les filiales

Certaines entreprises sont présentes dans de nombreuses régions et possèdent des filiales dans différentes zones géographiques, ou bien elles sont le résultat de fusions et d'acquisitions. Ces organisations nécessitent une hiérarchie de ressources qui utilise les options d'évolutivité et de gestion de Google Cloud, et maintient l'indépendance des différents processus et règles existant entre les régions ou les filiales. Cette hiérarchie utilise les filiales ou les régions comme niveau le plus élevé des dossiers dans la hiérarchie des ressources. Les procédures de déploiement sont généralement axées sur les régions.

Utilisez ce type de hiérarchie si les conditions suivantes sont remplies :

  • Les différentes régions ou filiales fonctionnent indépendamment.
  • Les régions ou les filiales ont des infrastructures opérationnelles, des offres de plates-formes numériques et des processus différents.
  • Votre entreprise est soumise à des normes réglementaires et de conformité différentes pour les régions ou les filiales.

Le schéma suivant illustre un exemple de hiérarchie d'une organisation mondiale comportant deux filiales et une holding avec une structure régionalisée.

Schéma de l'option 2.

Le schéma précédent présente la structure de hiérarchie suivante :

  • Les dossiers suivants se trouvent au premier niveau :
    • Les dossiers Subsidiary 1 et Subsidiary 2 représentent les deux filiales de l'entreprise qui disposent d'autorisations d'accès et de stratégies différentes de celles du reste de l'organisation. Chaque filiale utilise IAM pour restreindre l'accès à ses projets et à ses ressources Google Cloud.
    • Le dossier Holding group représente les groupes ayant des stratégies communes de haut niveau dans toutes les régions.
    • Le dossier Bootstrap représente les ressources communes requises pour déployer votre infrastructure Google Cloud, comme décrit dans le plan de base de l'entreprise.
  • Au deuxième niveau, dans le dossier Holding Group, vous trouvez les dossiers suivants :
    • Les dossiers APAC, EMEA et Americas représentent les différentes régions du groupe qui présentent une gouvernance, des autorisations d'accès et des stratégies différentes.
    • Le dossier Shared infrastructure représente les ressources utilisées sur l'ensemble des régions, dans le monde entier.
  • Chaque dossier contient différents projets hébergeant les ressources dont ces filiales ou régions sont responsables.

Vous pouvez ajouter d'autres dossiers pour séparer différents services, entités juridiques et équipes au sein de votre entreprise.

Option 3 : Hiérarchie basée sur un framework de responsabilité

Une hiérarchie basée sur un framework de responsabilité est optimale lorsque vos produits sont exécutés indépendamment ou lorsque les unités organisationnelles ont des équipes clairement définies qui détiennent le cycle de vie des produits. Dans ces entreprises, les propriétaires des produits sont responsables de l'intégralité du cycle de vie de leurs produits, y compris les processus, assistance, stratégies, sécurité et droits d'accès associés. Vos produits sont indépendants, et les consignes et contrôles à l'échelle de l'organisation sont peu communs.

Utilisez cette hiérarchie lorsque les conditions suivantes sont remplies :

  • Vous gérez une organisation où la propriété et la responsabilité de chaque produit sont clairement définies.
  • Vos charges de travail sont indépendantes et ne partagent que peu de règles communes.
  • Vos processus et vos plates-formes de développement externes sont proposés en tant que services ou offres de produits.

Le schéma suivant est un exemple de hiérarchie pour un fournisseur de plate-forme d'e-commerce.

Schéma de l'option 3.

Le schéma précédent présente la structure de hiérarchie suivante :

  • Les dossiers suivants se trouvent au premier niveau :
    • Les dossiers nommés Ecommerce Modules et Logistics and Warehousing Modules représentent les modules de l'offre de plate-forme qui nécessitent les mêmes autorisations et stratégies d'accès pendant le cycle de vie du produit.
    • Le dossier Reconciliation and Billing représente les équipes produit responsables des modules de bout en bout pour des composants métier spécifiques de l'offre de plate-forme.
    • Le dossier Bootstrap représente les ressources communes requises pour déployer votre infrastructure Google Cloud, comme décrit dans le plan de base de l'entreprise.
  • Chaque dossier contient différents projets hébergeant les modules indépendants dont différentes équipes produit sont responsables.

Pour en savoir plus, consultez la section Hiérarchie des ressources du framework Terraform Fabric FAST.

Bonnes pratiques pour la hiérarchie des ressources

Les sections suivantes décrivent les bonnes pratiques que nous recommandons d'adopter pour la conception d'une hiérarchie de ressources, quelle que soit la hiérarchie des ressources que vous choisissez.

Pour découvrir d'autres bonnes pratiques de configuration de vos comptes et organisations Cloud Identity et Google Workspace, consultez la page Bonnes pratiques pour planifier des comptes et des organisations.

Utiliser un seul nœud d'organisation

Pour éviter de complexifier la gestion, utilisez autant que possible un seul nœud d'organisation. Toutefois, vous pouvez envisager d'utiliser plusieurs nœuds d'organisation pour traiter les cas d'utilisation suivants :

  • Vous souhaitez tester les modifications majeures de vos niveaux IAM ou de votre hiérarchie de ressources.
  • Vous souhaitez effectuer des tests dans un environnement de bac à sable qui n'a pas les mêmes règles d'administration.
  • Votre organisation comprend des sous-entreprises susceptibles d'être vendues ou gérées à l'avenir en tant qu'entités totalement distinctes.

Utiliser des conventions d'attribution de noms standardisées

Utilisez une convention d'attribution de noms standardisée au sein de votre organisation. Le plan de sécurité de base inclut un exemple de convention d'attribution de noms que vous pouvez adapter à vos besoins.

Dissocier les ressources d'amorçage et les services courants

Conservez des dossiers distincts pour l'amorçage de l'environnement Google Cloud suivant le modèle "Infrastructure as Code" (IaC) et pour les services communs partagés entre les environnements ou les applications. Placez le dossier d'amorçage juste en dessous du nœud d'organisation dans la hiérarchie des ressources.

Placez les dossiers des services communs à différents niveaux de la hiérarchie, en fonction de la structure choisie.

Placez le dossier des services communs juste en dessous du nœud d'organisation lorsque les conditions suivantes sont remplies :

  • Votre hiérarchie utilise les environnements d'application au niveau le plus élevé, et les équipes ou les applications se trouvent au niveau de la deuxième couche.
  • Vous avez des services partagés, tels que la surveillance, qui sont communs aux différents environnements.

Placez le dossier des services communs à un niveau inférieur, sous les dossiers des applications, lorsque les conditions suivantes sont remplies :

  • Vous avez des services partagés entre les applications et vous déployez une instance distincte pour chaque environnement de déploiement.

  • Les applications partagent des microservices qui nécessitent un développement et un test pour chaque environnement de déploiement.

Le schéma suivant illustre un exemple de hiérarchie où il existe un dossier d'infrastructure partagé utilisé par tous les environnements, et des dossiers de services partagés pour chaque environnement d'application à un niveau inférieur de la hiérarchie :

Exemple de hiérarchie avec un dossier d'infrastructure partagé.

Le schéma précédent présente la structure de hiérarchie suivante :

  • Les dossiers du premier niveau sont les suivants :
    • Les dossiers Development environment et Production environment contiennent les environnements d'application.
    • Le dossier Shared infrastructure contient des ressources communes partagées entre les différents environnements, telles que la surveillance.
    • Le dossier Bootstrap contient les ressources communes requises pour déployer votre infrastructure Google Cloud, comme décrit dans le plan de base de l'entreprise.
  • Le deuxième niveau comporte les dossiers suivants :
    • Un dossier dans chaque environnement pour chaque application (App 1 et App 2) contenant les ressources de ces applications.
    • Un dossier Shared pour les deux environnements d'application, qui contient les services partagés entre les applications, mais indépendants pour chaque environnement. Par exemple, vous pouvez disposer d'un projet "secrets" au niveau du dossier afin d'appliquer différentes stratégies d'autorisation aux secrets de production et aux secrets hors production.
  • Chaque dossier d'application héberge différents projets contenant les modules indépendants qui font partie de chaque application.

Étape suivante