Déployer le plan

Last reviewed 2023-12-20 UTC

Cette section décrit le processus que vous pouvez utiliser pour déployer le plan, ses conventions de nommage et les alternatives aux recommandations de plans.

Conclusion

Pour déployer votre propre base d'entreprise conformément aux bonnes pratiques et aux recommandations de ce plan, suivez les tâches de haut niveau décrites dans cette section. Le déploiement nécessite une combinaison d'étapes de configuration préalables, de déploiement automatisé via terraform-example-Foundation sur GitHub et d'étapes supplémentaires qui doivent être configurées manuellement après le fin du déploiement de base initial.

Processus Étapes

Prérequis avant de déployer les ressources du pipeline de base

Effectuez les étapes suivantes avant de déployer le pipeline de base:

Pour vous connecter à un environnement sur site existant, préparez les éléments suivants:

Procédure de déploiement de Terraform-example-Foundation depuis GitHub

Suivez les instructions README de chaque étape pour déployer terraform-example-Foundation à partir de GitHub

Étapes supplémentaires après le déploiement IaC

Après avoir déployé le code Terraform, procédez comme suit:

Contrôles d'administration supplémentaires pour les clients ayant des charges de travail sensibles

Google Cloud fournit des contrôles d'administration supplémentaires qui peuvent vous aider à répondre à vos exigences de sécurité et de conformité. Toutefois, certains contrôles entraînent des coûts supplémentaires ou des compromis opérationnels qui peuvent ne pas être adaptés à tous les clients. Ces contrôles nécessitent également des entrées personnalisées pour vos exigences spécifiques qui ne peuvent pas être entièrement automatisées dans le plan avec une valeur par défaut pour tous les clients.

Cette section présente les contrôles de sécurité que vous appliquez de manière centralisée à votre base. Cette section n'est pas exhaustive de tous les contrôles de sécurité que vous pouvez appliquer à des charges de travail spécifiques. Pour plus d'informations sur les produits et solutions de sécurité de Google, consultez le Centre des bonnes pratiques de sécurité dans Google Cloud.

Déterminez si les contrôles suivants sont adaptés à votre base en fonction de vos exigences de conformité, de votre intérêt pour les risques et de la sensibilité des données.

Contrôle Description

Protéger vos ressources avec VPC Service Controls

VPC Service Controls vous permet de définir des règles de sécurité qui empêchent l'accès aux services gérés par Google en dehors d'un périmètre approuvé, de bloquer l'accès aux données depuis des emplacements non approuvés et de limiter les risques d'exfiltration des données. Toutefois, VPC Service Controls peut entraîner l'interruption des services existants jusqu'à ce que vous définissiez des exceptions pour autoriser les modèles d'accès prévus.

Déterminez si la valeur des mesures d'atténuation des risques d'exfiltration justifie la complexité accrue et l'impact opérationnel de l'adoption de VPC Service Controls. Le plan prépare les réseaux restreints et les variables facultatives pour configurer VPC Service Controls. Cependant, le périmètre n'est pas activé tant que vous n'avez pas pris des mesures supplémentaires pour le concevoir et l'activer.

Limitez l'emplacement des ressources.

Vous pouvez être soumis à des exigences réglementaires exigeant que les ressources cloud ne doivent être déployées que dans des emplacements géographiques approuvés. Cette contrainte de règle d'administration exige que les ressources ne puissent être déployées que dans la liste des emplacements que vous définissez.

Activer Assured Workloads

Assured Workloads fournit des contrôles de conformité supplémentaires qui vous aident à respecter des régimes réglementaires spécifiques. Le plan fournit des variables facultatives dans le pipeline de déploiement pour l'activation.

Activer les journaux d'accès aux données

Vous devrez peut-être consigner tous les accès à certaines données ou ressources sensibles.

Déterminez où vos charges de travail gèrent les données sensibles nécessitant des journaux d'accès aux données, et activez les journaux pour chaque service et environnement utilisant des données sensibles.

Activer Access Approval

Access Approval vous garantit que Cloud Customer Care et les services d'ingénierie ne puissent accéder à votre contenu client qu'avec votre approbation explicite.

Évaluez le processus opérationnel nécessaire pour examiner les demandes Access Approval afin de minimiser les retards éventuels dans la résolution des incidents d'assistance.

Activer Key Access Justifications

Key Access Justifications vous permet de contrôler de manière automatisée si Google peut accéder à vos clés de chiffrement, y compris pour les opérations automatisées et pour que le service client puisse accéder à votre contenu client.

Évaluez les coûts et les coûts opérationnels associés à Key Access Justifications, ainsi que sa dépendance sur Cloud External Key Manager (Cloud EKM).

Désactiver Cloud Shell

Cloud Shell est un environnement de développement en ligne. Cette interface système est hébergée sur un serveur géré par Google en dehors de votre environnement. Elle n'est donc pas soumise aux contrôles que vous avez pu mettre en œuvre sur vos propres postes de travail de développeur.

Si vous souhaitez contrôler strictement les postes de travail qu'un développeur peut utiliser pour accéder aux ressources cloud, désactivez Cloud Shell. Vous pouvez également évaluer Cloud Workstations pour trouver une option de poste de travail configurable dans votre propre environnement.

Restreindre l'accès à la console Google Cloud

Google Cloud vous permet de limiter l'accès à la console Google Cloud en fonction d'attributs de niveau d'accès tels que l'appartenance à un groupe, les plages d'adresses IP approuvées et la validation des appareils. Certains attributs nécessitent un abonnement supplémentaire à BeyondCorp Enterprise.

Évaluez les modèles d'accès auxquels vous faites confiance pour l'accès des utilisateurs aux applications Web telles que la console dans le cadre d'un déploiement zéro confiance plus important.

Conventions de nommage

Nous vous recommandons d'utiliser une convention d'attribution de noms standardisée pour vos ressources Google Cloud. Le tableau suivant décrit les conventions recommandées pour les noms de ressources dans le plan.

Ressource Convention d'attribution de noms

Dossier

fldr-environment

environment est la description des ressources au niveau du dossier dans l'organisation Google Cloud. Par exemple, bootstrap, common, production, nonproduction, development, network.

Par exemple : fldr-production

ID du projet

prj-environmentcode-description-randomid

  • environmentcode est une forme courte du champ d'environnement (b, c, p, n, d ou net). Les projets hôtes de VPC partagé utilisent le environmentcode de l'environnement associé. Les projets de ressources de mise en réseau partagées entre plusieurs environnements, tels que le projet interconnect, utilisent le code d'environnement net.
  • description est des informations supplémentaires sur le projet. Vous pouvez utiliser des abréviations lisibles et courtes.
  • randomid est un suffixe aléatoire permettant d'éviter les conflits pour les noms de ressources qui doivent être uniques au niveau mondial et de limiter les attaques des pirates informatiques. Le plan ajoute automatiquement un identifiant alphanumérique à quatre caractères aléatoire.

Par exemple : prj-c-logging-a1b2

Réseau VPC

vpc-environmentcode-vpctype-vpcconfig

  • environmentcode est une forme courte du champ d'environnement (b, c, p, n, d ou net).
  • vpctype correspond à shared, float ou peer.
  • vpcconfig correspond à base ou restricted pour indiquer si le réseau est destiné à être utilisé avec VPC Service Controls.

Par exemple : vpc-p-shared-base

Sous-réseau

sn-environmentcode-vpctype-vpcconfig-region{-description}

  • environmentcode est une forme courte du champ d'environnement (b, c, p, n, d ou net).
  • vpctype correspond à shared, float ou peer.
  • vpcconfig correspond à base ou restricted pour indiquer si le réseau est destiné à être utilisé avec VPC Service Controls.
  • region correspond à n'importe quelle région Google Cloud valide dans laquelle la ressource se trouve. Nous vous recommandons de supprimer les tirets et d'utiliser une forme abrégée de certaines régions et directions pour éviter d'atteindre les limites de caractères. Par exemple, au (Australie), na (Amérique du Nord), sa (Amérique du Sud), eu (Europe), se (Sud-Est) ou ne (Nord-Est).
  • description correspond à des informations supplémentaires sur le sous-réseau. Vous pouvez utiliser des abréviations courtes et lisibles.

Par exemple : sn-p-shared-restricted-uswest1

Stratégies de pare-feu

fw-firewalltype-scope-environmentcode{-description}

  • firewalltype est hierarchical ou network.
  • scope correspond à global ou à la région Google Cloud dans laquelle se trouve la ressource. Nous vous recommandons de supprimer les traits d'union, et d'utiliser une forme abrégée de certaines régions et directions pour éviter d'atteindre le nombre maximal de caractères. Par exemple, au (Australie), na (Amérique du Nord), sa (Amérique du Sud), eu (Europe), se (Sud-Est) ou ne (Nord-Est).
  • environmentcode est une forme abrégée du champ d'environnement (b, c, p, n, d ou net) qui est propriétaire de la ressource de stratégie.
  • description correspond à des informations supplémentaires sur la stratégie de pare-feu hiérarchique. Vous pouvez utiliser des abréviations courtes et lisibles.

Exemple :

fw-hierarchical-global-c-01

fw-network-uswest1-p-shared-base

Cloud Router

cr-environmentcode-vpctype-vpcconfig-region{-description}

  • environmentcode est une forme courte du champ d'environnement (b, c, p, n, d ou net).
  • vpctype correspond à shared, float ou peer.
  • vpcconfig correspond à base ou restricted pour indiquer si le réseau est destiné à être utilisé avec VPC Service Controls.
  • region correspond à n'importe quelle région Google Cloud valide dans laquelle se trouve la ressource. Nous vous recommandons de supprimer les traits d'union, et d'utiliser une forme abrégée de certaines régions et directions pour éviter d'atteindre le nombre maximal de caractères. Par exemple, au (Australie), na (Amérique du Nord), sa (Amérique du Sud), eu (Europe), se (Sud-Est) ou ne (Nord-Est).
  • description correspond à des informations supplémentaires sur le routeur Cloud Router. Vous pouvez utiliser des abréviations courtes et lisibles.

Par exemple : cr-p-shared-base-useast1-cr1

Connexion Cloud Interconnect

ic-dc-colo

  • dc est le nom du centre de données auquel une interconnexion Cloud Interconnect est connectée.
  • colo est le nom de l'installation hébergée en colocation auquel l'interconnexion Cloud Interconnect du centre de données sur site est appairée.

Par exemple : ic-mydatacenter-lgazone1

Rattachement de VLAN Cloud Interconnect

vl-dc-colo-environmentcode-vpctype-vpcconfig-region{-description}

  • dc est le nom du centre de données auquel une interconnexion Cloud Interconnect est connectée.
  • colo correspond au nom de l'installation hébergée en colocation à laquelle l'interconnexion Cloud Interconnect du centre de données sur site est appairée.
  • environmentcode est une forme courte du champ d'environnement (b, c, p, n, d ou net).
  • vpctype correspond à shared, float ou peer.
  • vpcconfig correspond à base ou restricted pour indiquer si le réseau est destiné à être utilisé avec VPC Service Controls.
  • region correspond à n'importe quelle région Google Cloud valide dans laquelle se trouve la ressource. Nous vous recommandons de supprimer les traits d'union, et d'utiliser une forme abrégée de certaines régions et directions pour éviter d'atteindre le nombre maximal de caractères. Par exemple, au (Australie), na (Amérique du Nord), sa (Amérique du Sud), eu (Europe), se (Sud-Est) ou ne (Nord-Est).
  • description correspond à des informations supplémentaires sur le VLAN. Vous pouvez utiliser des abréviations courtes et lisibles.

Par exemple : vl-mydatacenter-lgazone1-p-shared-base-useast1-cr1

Groupe

grp-gcp-description@example.com

Où description contient des informations supplémentaires sur le groupe. Vous pouvez utiliser des abréviations courtes et lisibles.

Par exemple : grp-gcp-billingadmin@example.com

Rôle personnalisé

rl-description

Où description contient des informations supplémentaires sur le rôle. Vous pouvez utiliser des abréviations courtes et lisibles.

Par exemple : rl-customcomputeadmin

Compte de service

sa-description@projectid.iam.gserviceaccount.com

Où :

  • description correspond à des informations supplémentaires sur le compte de service. Vous pouvez utiliser des abréviations courtes et lisibles.
  • projectid est l'identifiant de projet unique au niveau mondial.

Par exemple : sa-terraform-net@prj-b-seed-a1b2.iam.gserviceaccount.com

Bucket de stockage

bkt-projectid-description

Où :

  • projectid est l'identifiant de projet unique au niveau mondial.
  • description correspond à des informations supplémentaires sur le bucket de stockage. Vous pouvez utiliser des abréviations courtes et lisibles.

Par exemple : bkt-prj-c-infra-pipeline-a1b2-app-artifacts

Alternatives aux recommandations par défaut

Les bonnes pratiques recommandées dans le plan peuvent ne pas fonctionner pour tous les clients. Vous pouvez personnaliser n'importe quelle recommandation pour répondre à vos besoins spécifiques. Le tableau suivant présente certaines des variantes courantes dont vous pourriez avoir besoin en fonction de votre pile technologique existante et de vos méthodes de travail.

Zone de décision Autres solutions possibles

Organisation:le plan utilise une seule organisation comme nœud racine pour toutes les ressources.

Choisir une hiérarchie de ressources pour votre zone de destination Google Cloud présente des scénarios dans lesquels vous pouvez préférer plusieurs organisations, telles que les suivantes:

  • Votre organisation comprend des sous-entreprises susceptibles d'être vendues à l'avenir ou qui s'exécutent en tant qu'entités totalement distinctes.
  • Vous souhaitez effectuer des tests dans un environnement de bac à sable sans connectivité à votre organisation existante.

Structure des dossiers:le plan présente une structure de dossiers simple, avec des charges de travail divisées en dossiers production, non-production et development en niveau de la couche supérieure.

Choisir une hiérarchie de ressources pour votre zone de destination Google Cloud présente d'autres approches de structuration des dossiers en fonction de la manière dont vous souhaitez gérer les ressources et hériter des stratégies, par exemple:

  • Dossiers basés sur les environnements d'application
  • Dossiers basés sur des entités régionales ou des filiales
  • Dossiers basés sur un framework de responsabilité

Règles d'administration:le plan applique toutes les contraintes de règle d'administration sur le nœud d'organisation.

Vous pouvez avoir différentes règles de sécurité ou méthodes de travail pour différents secteurs de l'entreprise. Dans ce scénario, appliquez des contraintes de règle d'administration à un nœud inférieur de la hiérarchie des ressources. Consultez la liste complète des contraintes liées aux règles d'administration qui répondent à vos exigences.

Outils de pipeline de déploiement:le plan utilise Cloud Build pour exécuter le pipeline d'automatisation.

Vous pouvez préférer d'autres produits pour votre pipeline de déploiement, tels que Terraform Enterprise, les exécuteurs GitLab, GitHub Actions ou Jenkins.. Le plan comprend des instructions alternatives pour chaque produit.

Dépôt de code pour le déploiement:le plan utilise Cloud Source Repositories comme dépôt Git privé géré.

Utilisez le système de contrôle des versions que vous préférez pour gérer les dépôts de code, tels que GitLab, GitHub ou Bitbucket.

Si vous utilisez un dépôt privé hébergé dans votre environnement sur site, configurez un chemin réseau privé entre votre dépôt et votre environnement Google Cloud.

Fournisseur d'identité:le plan suppose qu'il dispose d'une identité Active Directory sur site et envoie des identités à Cloud Identity à l'aide de Google Cloud Directory Sync.

Si vous utilisez déjà Google Workspace, vous pouvez utiliser les identités Google qui sont déjà gérées dans Google Workspace.

Si vous ne disposez pas déjà d'un fournisseur d'identité, vous pouvez créer et gérer les identités des utilisateurs directement dans Cloud Identity.

Si vous disposez d'un fournisseur d'identité existant, tel que Okta, Ping ou Azure Entra ID, vous pouvez gérer les comptes utilisateur de votre fournisseur d'identité existant et synchroniser avec Cloud Identity.

Si vous avez des exigences de souveraineté ou de conformité des données qui vous empêchent d'utiliser Cloud Identity, et que vous n'avez pas besoin d'identités d'utilisateurs Google gérées pour d'autres services Google tels que Google Ads ou Google Marketing Platform, vous préférez peut-être la fédération des identités des employés. Dans ce scénario, soyez conscient des limites des services compatibles.

Plusieurs régions:le plan déploie les ressources régionales dans deux régions Google Cloud différentes afin de faciliter la conception des charges de travail en tenant compte des exigences de haute disponibilité et de reprise après sinistre.

Si vos utilisateurs finaux sont situés dans plus d'emplacements géographiques, vous pouvez configurer davantage de régions Google Cloud pour créer des ressources plus proches de l'utilisateur final avec une latence réduite.

Si vous avez des contraintes de souveraineté des données ou que vos besoins en disponibilité peuvent être satisfaits dans une seule région, vous pouvez configurer une seule région Google Cloud.

Allocation d'adresses IP:le plan fournit un ensemble de plages d'adresses IP.

Vous devrez peut-être modifier les plages d'adresses IP spécifiques utilisées en fonction de la disponibilité des adresses IP dans votre environnement hybride existant. Si vous modifiez les plages d'adresses IP, utilisez le plan comme guide pour connaître le nombre et la taille des plages requises, et examinez les plages d'adresses IP valides pour Google Cloud.

Mise en réseau hybride:le plan utilise l'interconnexion dédiée sur plusieurs sites physiques et régions Google Cloud pour une bande passante et une disponibilité maximales.

En fonction de vos exigences en termes de coût, de bande passante et de fiabilité, vous pouvez configurer une interconnexion partenaire ou Cloud VPN à la place.

Si vous devez commencer à déployer des ressources avec une connectivité privée avant de pouvoir terminer l'interconnexion dédiée, vous pouvez commencer avec Cloud VPN et passer à une interconnexion dédiée ultérieurement.

Si vous ne disposez d'aucun environnement sur site, vous n'aurez peut-être pas besoin de mise en réseau hybride.

Périmètre VPC Service Controls:le plan recommande un périmètre unique incluant tous les projets de service associés à un réseau VPC restreint. Les projets associés à un réseau VPC de base ne sont pas inclus dans le périmètre.

Vous pouvez avoir un cas d'utilisation nécessitant plusieurs périmètres pour une organisation ou vous décider de ne pas utiliser VPC Service Controls.

Pour en savoir plus, consultez la section Décider comment limiter l'exfiltration de données via les API Google.

Secret Manager:le plan déploie un projet pour utiliser Secret Manager dans le dossier common des secrets à l'échelle de l'organisation, et un projet dans chaque dossier d'environnement pour les secrets spécifiques à l'environnement.

Si vous disposez d'une seule équipe chargée de gérer et d'auditer les secrets sensibles dans l'organisation, vous pouvez utiliser un seul projet pour gérer l'accès aux secrets.

Si vous laissez les équipes de charge de travail gérer leurs propres secrets, vous ne pouvez pas utiliser un projet centralisé pour gérer l'accès aux secrets. À la place, les équipes peuvent utiliser leurs propres instances de Secret Manager dans les projets de charge de travail.

Cloud KMS:le plan déploie un projet pour utiliser Cloud KMS dans le dossier common pour les clés à l'échelle de l'organisation, ainsi qu'un projet pour chaque dossier d'environnement pour les clés dans chacune des clés de chaque environnement.

Si vous disposez d'une seule équipe chargée de gérer et d'auditer les clés de chiffrement dans toute l'organisation, vous pouvez utiliser un seul projet pour gérer l'accès aux clés. Une approche centralisée peut répondre aux exigences de conformité, telles que les dépositaires de clés PCI.

Si vous laissez les équipes de charge de travail gérer leurs propres clés, vous ne pourrez peut-être pas utiliser un projet centralisé pour gérer l'accès aux clés. Laissez les équipes utiliser leurs propres instances de Cloud KMS dans les projets de charge de travail.

Récepteurs de journaux agrégés:le plan configure un ensemble de récepteurs de journaux sur le nœud d'organisation afin qu'une équipe de sécurité centrale puisse examiner les journaux d'audit à partir de l'ensemble de l'organisation.

Vous pouvez avoir différentes équipes chargées d'auditer différentes parties de l'activité, et ces équipes peuvent avoir besoin de journaux différents pour effectuer leurs tâches. Dans ce scénario, concevez plusieurs récepteurs agrégés dans les dossiers et projets appropriés, et créez des filtres de sorte que chaque équipe ne reçoive que les journaux nécessaires, ou concevez des vues de journaux pour un contrôle précis des accès vers un bucket de journaux commun.

Projets de champ d'application de surveillance:le plan configure un seul projet de champ d'application de surveillance pour chaque environnement.

Vous pouvez configurer des projets de champ d'application plus précis gérés par différentes équipes, limités à l'ensemble de projets contenant les applications gérées par chaque équipe.

Précision des pipelines d'infrastructure:le plan utilise un modèle dans lequel chaque unité commerciale dispose d'un pipeline d'infrastructure distinct pour gérer ses projets de charge de travail.

Vous préférez peut-être un seul pipeline d'infrastructure géré par une équipe centrale si vous avez une équipe centrale chargée de déployer tous les projets et toute l'infrastructure. Cette équipe centrale peut accepter les demandes d'extraction des équipes chargées des charges de travail à examiner et à approuver avant la création du projet, ou créer l'opération elle-même en réponse à un système demandé.

Vous pouvez préférer les pipelines plus précis si les équipes de charge de travail individuelles peuvent personnaliser leurs propres pipelines et que vous souhaitez concevoir des comptes de service privilégiés plus précis pour les pipelines.

Exportations SIEM:le plan gère tous les résultats de sécurité dans Security Command Center.

Décidez si vous souhaitez exporter les résultats de sécurité de Security Command Center vers des outils tels que Chronicle ou votre solution SIEM existante, ou si les équipes doivent afficher et gérer les résultats de sécurité à l'aide de la console. Vous pouvez configurer plusieurs exportations avec des filtres uniques pour différentes équipes avec différents champs d'application et responsabilités.

Recherches DNS pour les services Google Cloud sur site: le plan configure un point de terminaison Private Service Connect unique pour chaque VPC partagé, ce qui peut aider à activer des conceptions avec plusieurs périmètres VPC Service Controls.

Vous n'aurez peut-être pas besoin d'un routage depuis un environnement sur site vers des points de terminaison Private Service Connect à ce niveau de précision si vous n'avez pas besoin de plusieurs périmètres VPC Service Controls.

Au lieu de mapper des hôtes sur site à des points de terminaison Private Service Connect par environnement, vous pouvez simplifier cette conception pour utiliser un seul point de terminaison Private Service Connect avec le groupe d'API approprié, ou utiliser les points de terminaison génériques pour private.googlepais.com et restricted.googleapis.com

Étapes suivantes