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.
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 :
- Cloud Logging inclut des récepteurs agrégés que vous pouvez utiliser pour agréger des journaux au niveau du dossier ou de l'organisation. Pour plus d'informations, consultez la section Décider de la sécurité de votre zone de destination Google Cloud.
- La facturation n'est pas directement liée à la hiérarchie des ressources, mais attribuée au niveau du projet. Toutefois, pour obtenir des informations agrégées au niveau du dossier, vous pouvez analyser vos coûts par hiérarchie de projet à l'aide des rapports de facturation.
- Les stratégies de pare-feu hiérarchiques vous permettent de mettre en œuvre des stratégies de pare-feu cohérentes à l'échelle de l'organisation ou dans des dossiers spécifiques. L'héritage est implicite, ce qui signifie que vous pouvez autoriser ou refuser le trafic à n'importe quel niveau ou déléguer la décision à un niveau inférieur.
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.
Le schéma précédent décrit les points de décision suivants :
- Les différents groupes régionaux, filiales ou unités commerciales ont-ils des exigences très différentes au niveau réglementaire ?
- Si oui, suivez l'option de conception basée sur la région ou les filiales.
- Dans le cas contraire, passez au point de décision suivant.
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.
Si oui, reportez-vous à l'option de conception basée sur un framework de responsabilité.
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.
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.
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
etSubsidiary 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.
- Les dossiers
- Au deuxième niveau, dans le dossier Holding Group, vous trouvez les dossiers suivants :
- Les dossiers
APAC
,EMEA
etAmericas
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.
- Les dossiers
- 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.
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
etLogistics 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.
- Les dossiers nommés
- 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 :
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
etProduction 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.
- Les dossiers
- Le deuxième niveau comporte les dossiers suivants :
- Un dossier dans chaque environnement pour chaque application (
App 1
etApp 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.
- Un dossier dans chaque environnement pour chaque application (
- Chaque dossier d'application héberge différents projets contenant les modules indépendants qui font partie de chaque application.
Étape suivante
- Concevoir le réseau pour votre zone de destination (le document suivant de cette série).
- Consultez le plan de base de l'entreprise.
- Consultez les plans et les livres blancs disponibles dans le Centre des bonnes pratiques de sécurité dans Google Cloud.