Ce contenu a été mis à jour pour la dernière fois en Décembre 2023, et correspond à l'état des connaissances à sa date de rédaction. Les règles et les systèmes de sécurité Google peuvent changer par la suite, car nous améliorons continuellement la protection de nos clients.

Ce document décrit les bonnes pratiques qui vous permettent de déployer un ensemble de ressources de base dans Google Cloud. Une base cloud repose sur une base de ressources, de configurations et de fonctionnalités qui permet aux entreprises d'adopter Google Cloud pour répondre à leurs besoins commerciaux. Une base bien conçue permet une gouvernance, des contrôles de sécurité, une évolutivité, une visibilité et un accès cohérents à tous les services partagés de toutes les charges de travail de votre environnement Google Cloud. Après avoir déployé les contrôles et la gouvernance décrits dans ce document, vous pouvez déployer des charges de travail sur Google Cloud.

Le plan de base de l'entreprise (anciennement appelé plan de base de sécurité) est destiné aux architectes, aux professionnels de la sécurité et aux équipes d'ingénieurs de plate-forme chargés de la conception d'un environnement adapté pour les entreprises sur Google Cloud. Ce plan comprend les éléments suivants:

• Un dépôt GitHub Terraform-example-Foundation contenant les éléments Terraform déployables.
• Un guide décrivant l'architecture, la conception et les contrôles que vous mettez en œuvre avec le plan (ce document).

Vous pouvez utiliser ce guide de deux manières:

• Créer une base complète basée sur les bonnes pratiques de Google. Vous pouvez déployer toutes les recommandations de ce guide comme point de départ, puis personnaliser l'environnement pour répondre aux exigences spécifiques de votre entreprise.
• Pour examiner un environnement existant sur Google Cloud. Vous pouvez comparer des composants spécifiques de votre conception aux bonnes pratiques recommandées par Google.

Cas d'utilisation compatibles

Le plan de base de l'entreprise fournit une couche de base de ressources et de configurations permettant d'activer tous les types de charges de travail sur Google Cloud. Que vous souhaitiez migrer des charges de travail de calcul existantes vers Google Cloud, créer des applications Web conteneurisées ou créer des charges de travail de big data et de machine learning, le plan de base de l'entreprise vous aide à créer votre environnement pour gérer les charges de travail d'entreprise à grande échelle.

Une fois le plan de base de l'entreprise déployé, vous pouvez déployer directement les charges de travail ou déployer des plans supplémentaires pour gérer des charges de travail complexes nécessitant des fonctionnalités supplémentaires.

Modèle de sécurité de défense en profondeur

Les services Google Cloud bénéficient de la conception de sécurité de l'infrastructure Google sous-jacente. Il vous incombe de concevoir la sécurité dans les systèmes que vous créez sur Google Cloud. Le plan de base de l'entreprise vous aide à mettre en œuvre un modèle de défense en profondeur pour vos services et charges de travail Google Cloud.

Le schéma suivant illustre un modèle de sécurité de défense en profondeur pour votre organisation Google Cloud qui combine des contrôles d'architecture, des contrôles de règles et des contrôles de détection.

Le schéma décrit les commandes suivantes:

• Les contrôles de règles sont des contraintes automatisées qui appliquent des configurations de ressources acceptables et empêchent les configurations risquées. Le plan utilise une combinaison de contrôles de règles, tels que la validation IaC (Infrastructure as Code) dans votre pipeline et les contraintes de vos règles d'administration.
• Les contrôles d'architecture sont la configuration des ressources Google Cloud telles que les réseaux et la hiérarchie des ressources. L'architecture du plan est basée sur les bonnes pratiques de sécurité.
• Les contrôles de détection vous permettent de détecter les anomalies ou les comportements malveillants au sein de l'organisation. Le plan utilise des fonctionnalités de la plate-forme telles que Security Command Center, s'intègre à vos contrôles de détection et workflows existants, tels qu'un centre d'opérations de sécurité (SOC), et fournit des fonctionnalités permettant d'appliquer des contrôles de détection personnalisés.

Principales décisions à prendre

Cette section récapitule les décisions générales relatives à l'architecture du plan.

Le schéma décrit la façon dont les services Google Cloud contribuent aux décisions architecturales clés:

• Cloud Build:les ressources d'infrastructure sont gérées à l'aide d'un modèle GitOps. L'IaC déclaratif est écrit dans Terraform et géré dans un système de contrôle des versions pour examen et approbation. Les ressources sont déployées à l'aide de Cloud Build en tant qu'outil d'automatisation d'intégration et de déploiement continus (CI/CD). Le pipeline applique également des contrôles de type "règle en tant que code" pour vérifier que les ressources répondent aux configurations attendues avant le déploiement.
• Cloud Identity:les utilisateurs et les membres des groupes sont synchronisés à partir de votre fournisseur d'identité existant. Les contrôles liés à la gestion du cycle de vie des comptes utilisateur et à l'authentification unique (SSO) reposent sur les contrôles et processus existants de votre fournisseur d'identité.
• Identity and Access Management (IAM) : les stratégies d'autorisation (anciennement stratégies IAM) permettent l'accès aux ressources et sont appliquées aux groupes en fonction de la fonction du poste. Les utilisateurs sont ajoutés aux groupes appropriés pour recevoir un accès en lecture seule aux ressources de base. Toutes les modifications apportées aux ressources de base sont déployées via le pipeline CI/CD qui utilise des identités de compte de service privilégiées.
• Resource Manager:toutes les ressources sont gérées sous une organisation unique avec une hiérarchie de ressources de dossiers qui organise les projets par environnement. Les projets sont associés à des métadonnées de gouvernance, y compris à l'attribution des coûts.
• Mise en réseau: les topologies de réseaux utilisent un VPC partagé pour fournir des ressources réseau aux charges de travail dans plusieurs régions et zones, séparées par environnement et gérées de manière centralisée. Tous les chemins réseau entre les hôtes sur site, les ressources Google Cloud dans les réseaux VPC et les services Google Cloud sont privés. Aucun trafic sortant vers le réseau Internet public ou entrant depuis le réseau Internet public n'est autorisé par défaut.
• Cloud Logging: les récepteurs de journaux agrégés sont configurés pour collecter les journaux pertinents à la sécurité et aux audits dans un projet centralisé pour la conservation, l'analyse et l'exportation à long terme vers des systèmes externes.
• Cloud Monitoring: les projets de champ d'application de Monitoring sont configurés pour afficher les métriques de performances des applications de plusieurs projets au même endroit.
• Service de règles d'administration:les contraintes de règles d'administration sont configurées pour empêcher diverses configurations à haut risque.
• Secret Manager:les projets centralisés sont créés pour une équipe chargée de la gestion et de l'audit de l'utilisation des secrets d'application sensibles afin de répondre aux exigences de conformité.
• Cloud Key Management Service (Cloud KMS) : les projets centralisés sont créés pour une équipe chargée de la gestion et de l'audit des clés de chiffrement afin de répondre aux exigences de conformité.
• Security Command Center:des fonctionnalités de détection et de surveillance des menaces sont fournies à l'aide d'une combinaison de contrôles de sécurité intégrés dans Security Command Center et de solutions personnalisées qui vous permettent de détecter les événements liés à la sécurité et d'y répondre.

Pour trouver des alternatives à ces décisions clés, consultez la section Alternatives.

Étapes suivantes

• Découvrez l'authentification et l'autorisation (document suivant de cette série).

Authentification et autorisation

Cette section explique comment utiliser Cloud Identity pour gérer les identités utilisées par vos employés pour accéder aux services Google Cloud.

Fournisseur d'identité externe comme source fiable

Nous vous recommandons de fédérer votre compte Cloud Identity avec votre fournisseur d'identité existant. La fédération vous aide à garantir que vos processus de gestion de comptes existants s'appliquent à Google Cloud et à d'autres services Google.

Si vous ne disposez d'aucun fournisseur d'identité, vous pouvez créer des comptes utilisateur directement dans Cloud Identity.

Le schéma suivant présente une vue d'ensemble de la fédération d'identité et de l'authentification unique (SSO). Microsoft Active Directory est utilisé comme exemple de fournisseur d'identité, dans l'environnement sur site.

Ce schéma décrit les bonnes pratiques suivantes:

• Les identités des utilisateurs sont gérées dans un domaine Active Directory situé dans l'environnement sur site et fédéré à Cloud Identity. Active Directory se sert de Google Cloud Directory Sync pour provisionner les identités dans Cloud Identity.
• Les utilisateurs qui tentent de se connecter aux services Google sont redirigés vers le fournisseur d'identité externe pour procéder à l'authentification unique SAML, en utilisant leurs identifiants existants pour s'authentifier. Aucun mot de passe n'est synchronisé avec Cloud Identity.

Le tableau suivant fournit des liens vers des conseils de configuration pour les fournisseurs d'identité.

Fournisseur d'identité	Conseils
Active Directory	Provisionnement des comptes utilisateur Active Directory Authentification unique Active Directory
ID Microsoft Entra (anciennement Azure AD)	Fédérer Google Cloud avec l'ID Microsoft Entra
Autres fournisseurs d'identité externes (par exemple, Ping ou Okta)	Intégrer des solutions d'identité Ping aux services Google Identity Utiliser Okta avec les fournisseurs Google Cloud Bonnes pratiques pour fédérer Google Cloud avec un fournisseur d'identité externe

Nous vous recommandons vivement d'appliquer l'authentification multifacteur à votre fournisseur d'identité avec un mécanisme antihameçonnage, tel qu'une clé de sécurité Titan.

Les paramètres recommandés pour Cloud Identity ne sont pas automatisés via le code Terraform dans ce plan. Consultez la page Contrôles administratifs pour Cloud Identity pour connaître les paramètres de sécurité recommandés que vous devez configurer en plus du déploiement du code Terraform.

Groupes pour le contrôle des accès

Un compte principal est une identité qui peut se voir accorder l'accès à une ressource. Les comptes principaux incluent les comptes Google pour les utilisateurs, les groupes Google, les comptes Google Workspace, les domaines Cloud Identity et les comptes de service. Certains services vous permettent également d'accorder l'accès à tous les utilisateurs qui s'authentifient avec un compte Google ou à tous les internautes. Pour qu'un compte principal puisse interagir avec les services Google Cloud, vous devez lui attribuer des rôles dans Identity and Access Management (IAM).

Pour gérer les rôles IAM à grande échelle, nous vous recommandons d'attribuer des utilisateurs à des groupes en fonction de leurs fonctions de poste et des conditions d'accès requises, puis d'attribuer des rôles IAM à ces groupes. Vous devez ajouter des utilisateurs aux groupes à l'aide des processus de votre fournisseur d'identité existant pour la création et la souscription de groupes.

Nous vous déconseillons d'attribuer des rôles IAM à des utilisateurs individuels, car les attributions individuelles peuvent augmenter la complexité de la gestion et de l'audit des rôles.

Le plan configure les groupes et les rôles pour un accès en lecture seule aux ressources de base. Nous vous recommandons de déployer toutes les ressources du plan via le pipeline de base et de ne pas attribuer des rôles aux groupes pour modifier les ressources de base en dehors du pipeline.

Le tableau suivant présente les groupes configurés par le plan pour afficher les ressources de base.

Nom	Description	Rôles	Définition du champ d'application
[email protected]	Administrateurs privilégiés pouvant attribuer des rôles IAM au niveau de l'organisation. Ils peuvent accéder à n'importe quel autre rôle. Ce privilège est déconseillé pour l'utilisation quotidienne.	Administrateur de l'organisation	organisation
[email protected]	Administrateurs privilégiés pouvant modifier le compte de facturation Cloud. Ce privilège n'est pas recommandé pour une utilisation quotidienne.	Administrateur de compte de facturation	organisation
[email protected]	L'équipe chargée d'afficher et d'analyser les dépenses sur tous les projets.	Lecteur de compte de facturation	organisation
		Utilisateur BigQuery	Projet de facturation
[email protected]	L'équipe chargée de l'audit des journaux de sécurité.	Visionneuse de journaux Utilisateur BigQuery	Projet Logging
[email protected]	L'équipe chargée de surveiller les métriques de performances des applications.	Lecteur Monitoring	Projet de surveillance
[email protected]	L'équipe chargée d'examiner la sécurité du cloud.	Examinateur de sécurité	organisation
[email protected]	L'équipe chargée d'afficher et de gérer les configurations réseau.	Lecteur de réseau Compute	organisation
[email protected]	Équipe chargée de la configuration de Security Command Center.	Éditeur administrateur du centre de sécurité	organisation
[email protected]	L'équipe chargée de la gestion, du stockage et de l'audit des identifiants et d'autres secrets utilisés par les applications.	Administrateur Secret Manager	projets secrets
[email protected]	L'équipe chargée d'appliquer la gestion des clés de chiffrement pour répondre aux exigences de conformité.	Lecteur Cloud KMS	projets kms

Lorsque vous créez vos propres charges de travail sur une base solide, vous créez des groupes supplémentaires et attribuez des rôles IAM basés sur les conditions d'accès pour chaque charge de travail.

Nous vous recommandons vivement d'éviter les rôles de base (par exemple, propriétaire, éditeur ou lecteur) et d'utiliser des rôles prédéfinis. Les rôles de base sont trop permissifs et constituent un risque de sécurité potentiel. Les rôles de propriétaire et d'éditeur peuvent entraîner une élévation des privilèges et un mouvement latéral, et le rôle Lecteur permet d'accéder en lecture à toutes les données. Pour connaître les bonnes pratiques concernant les rôles IAM, consultez la page Utiliser IAM en toute sécurité.

Comptes super-administrateur

Les utilisateurs Cloud Identity disposant du compte super-administrateur contournent les paramètres d'authentification unique de l'organisation et s'authentifient directement avec Cloud Identity. Cette exception est volontaire, de sorte que le super-administrateur peut toujours accéder à la console Cloud Identity en cas de mauvaise configuration ou de panne de l'authentification unique. Toutefois, cela signifie que vous devez envisager une protection supplémentaire pour les comptes super-administrateur.

Pour protéger vos comptes super-administrateur, nous vous recommandons de toujours appliquer la validation en deux étapes avec des clés de sécurité dans Cloud Identity. Pour en savoir plus, consultez Bonnes pratiques de sécurité relatives aux comptes administrateur.

Problèmes liés aux comptes utilisateur personnels

Si vous n'avez pas utilisé Cloud Identity ou Google Workspace avant votre intégration à Google Cloud, il est possible que les employés de votre organisation utilisent déjà des comptes personnels qui sont et associé à son identité de messagerie d'entreprise pour accéder à d'autres services Google, tels que Google Marketing Platform ou YouTube. Les comptes personnels sont des comptes entièrement détenus et gérés par leurs créateurs. Étant donné que ces comptes ne sont pas sous le contrôle de votre organisation et peuvent inclure à la fois des données personnelles et professionnelles, vous devez décider de comment les regrouper avec d'autres comptes d'entreprise.

Nous vous recommandons de regrouper les comptes utilisateur personnels existants dans le cadre de l'intégration à Google Cloud. Si vous n'utilisez pas encore Google Workspace pour tous vos comptes utilisateur, nous vous recommandons de bloquer la création de comptes personnels.

Commandes d'administration pour Cloud Identity

Cloud Identity comprend diverses commandes d'administration qui ne sont pas automatisées par le code Terraform dans le plan. Nous vous recommandons d'appliquer chacun de ces contrôles de sécurité basés sur les bonnes pratiques dès le début du processus de création de vos fondations.

Contrôle	Description
Déployer la validation en deux étapes	Les comptes utilisateur peuvent être piratés par du hameçonnage, de l'ingénierie sociale, de la répétition des mots de passe ou d'autres menaces. La validation en deux étapes permet de limiter ces menaces. Nous vous recommandons d'appliquer la validation en deux étapes pour tous les comptes utilisateur de votre organisation à l'aide d'un mécanisme antihameçonnage, tel que les clés de sécurité Titan ou d'autres clés basées sur les normes FIDO U2F (CTAP1) antihameçonnage.
Définir la durée de session pour les services Google Cloud	Les jetons OAuth persistants sur les postes de travail des développeurs peuvent présenter un risque de sécurité s'ils sont exposés. Nous vous recommandons de définir une règle de réauthentification pour exiger une authentification toutes les 16 heures à l'aide d'une clé de sécurité.
Définir la durée de session pour les services Google	(clients Google Workspace uniquement) Les sessions Web persistantes sur d'autres services Google peuvent présenter un risque de sécurité si elles sont exposées. Nous vous recommandons d'appliquer une durée maximale de session Web et de l'aligner sur les contrôles de durée de session de votre fournisseur SSO.
Partager des données depuis Cloud Identity avec les services Google Cloud	En règle générale, les journaux d'audit pour les activités d'administration de Google Workspace ou Cloud Identity sont affichés et gérés dans la console d'administration séparément de vos journaux dans votre environnement Google Cloud. Ces journaux contiennent des informations pertinentes pour votre environnement Google Cloud, telles que des événements de connexion utilisateur. Nous vous recommandons de partager les journaux d'audit Cloud Identity avec votre environnement Google Cloud pour gérer les journaux de manière centralisée à partir de toutes les sources.
Configurer la validation post-authentification unique	Le plan suppose que vous avez configuré l'authentification unique avec votre fournisseur d'identité externe. Nous vous recommandons d'activer un niveau de contrôle supplémentaire basé sur l'analyse des risques de connexion Google. Après l'application de ce paramètre, les utilisateurs peuvent voir des questions d'authentification en cas de risque de sécurité supplémentaires lors de la connexion, si Google estime qu'elle est suspecte.
Résoudre les problèmes liés aux comptes utilisateur personnels	Les utilisateurs disposant d'une adresse e-mail valide sur votre domaine, mais qui n'ont pas de compte Google, peuvent créer des comptes personnels non gérés. Ces comptes peuvent contenir des données d'entreprise, mais ne sont pas contrôlés par les processus de gestion du cycle de vie de vos comptes. Nous vous recommandons de prendre des mesures pour vous assurer que tous les comptes utilisateur sont des comptes gérés.
Désactiver la récupération de compte pour les comptes super-administrateur	L'autorécupération de compte super-administrateur est désactivée par défaut pour tous les nouveaux clients (ce paramètre peut être activé pour les clients existants). La désactivation de ce paramètre permet de limiter le risque qu'un téléphone compromis, une adresse e-mail compromise ou une attaque par ingénierie sociale puisse permettre à un pirate informatique d'obtenir des droits de super-administrateur sur votre environnement. Planifiez un processus interne pour un super-administrateur afin de contacter un autre super-administrateur de votre organisation s'il a perdu l'accès à son compte, et assurez-vous que tous les super-administrateurs sont familiarisés avec le processus de récupération assistée.
Appliquer et contrôler des règles de mots de passe pour les utilisateurs	Dans la plupart des cas, les mots de passe utilisateur sont gérés via votre fournisseur d'identité externe, mais les comptes super-administrateur contournent l'authentification unique et doivent utiliser un mot de passe pour se connecter à Cloud Identity. Désactivez la réutilisation des mots de passe et surveillez le niveau de sécurité des mots de passe pour les utilisateurs qui se connectent à Cloud Identity, en particulier les comptes super-administrateur.
Définir des règles à l'échelle de l'organisation pour l'utilisation des groupes	Par défaut, les comptes utilisateur externes peuvent être ajoutés aux groupes dans Cloud Identity. Nous vous recommandons de configurer les paramètres de partage afin que les propriétaires de groupe ne puissent pas ajouter de membres externes. Notez que cette restriction ne s'applique pas au compte super-administrateur ni aux autres administrateurs délégués disposant d'autorisations d'administrateur de Groupes. Étant donné que la fédération de votre fournisseur d'identité s'exécute avec des droits d'administrateur, les paramètres de partage de groupe ne s'appliquent pas à cette synchronisation de groupe. Nous vous recommandons de vérifier les contrôles du fournisseur d'identité et du mécanisme de synchronisation pour vous assurer que les membres externes au domaine ne sont pas ajoutés aux groupes ou pour appliquer des restrictions de groupe.

Étapes suivantes

• Découvrez la structure de l'organisation (document suivant de cette série).

Structure organisationnelle

Le nœud racine pour la gestion des ressources dans Google Cloud est l'organisation. L'organisation Google Cloud fournit une hiérarchie des ressources qui constitue une structure de propriété pour les ressources ainsi que des points de liaison pour les règles d'administration et les contrôles d'accès. La hiérarchie des ressources se compose de dossiers, de projets et de ressources, et définit la forme et l'utilisation des services Google Cloud au sein d'une organisation.

Les ressources situées plus bas dans la hiérarchie héritent des stratégies telles que les stratégies d'autorisation IAM et les règles d'administration. Par défaut, toutes les autorisations d'accès sont refusées jusqu'à ce que vous appliquiez des stratégies d'autorisation directement à une ressource ou que la ressource hérite des stratégies d'autorisation d'un niveau supérieur dans la hiérarchie des ressources.

Le schéma suivant montre les dossiers et les projets déployés par le plan.

Les sections suivantes décrivent les dossiers et les projets du diagramme.

Dossiers

Le plan utilise des dossiers pour regrouper les projets en fonction de leur environnement. Ce regroupement logique permet d'appliquer des configurations telles que des stratégies d'autorisation et des règles d'administration au niveau du dossier, puis toutes les ressources du dossier héritent des stratégies. Le tableau suivant décrit les dossiers faisant partie du plan.

Dossier	Description
bootstrap	Contient les projets utilisés pour déployer les composants de base.
common	Contient des projets avec des ressources partagées par tous les environnements.
production	Contient des projets avec des ressources de production.
nonproduction	Contient une copie de l'environnement de production qui vous permet de tester des charges de travail avant de les promouvoir en production.
development	Contient les ressources cloud utilisées pour le développement.
networking	Contient les ressources réseau partagées par tous les environnements.

Projets

Le plan utilise des projets pour regrouper des ressources individuelles en fonction de leurs fonctionnalités et des limites prévues pour le contrôle des accès. Le tableau suivant décrit les projets inclus dans le plan.

Dossier	Projet	Description
bootstrap	prj-b-cicd	Héberge le pipeline de déploiement utilisé pour créer les composants de base de l'organisation. Pour en savoir plus, consultez la section Méthodologie de déploiement.
	prj-b-seed	Contient l'état Terraform de votre infrastructure et le compte de service Terraform requis pour exécuter le pipeline. Pour en savoir plus, consultez la section Méthodologie de déploiement.
common	prj-c-secrets	Contient des secrets au niveau de l'organisation. Pour en savoir plus, consultez la section Stocker les identifiants d'application avec Secret Manager.
	prj-c-logging	Contient les sources de journaux agrégées pour les journaux d'audit. Pour en savoir plus, consultez la page Journalisation centralisée pour la sécurité et l'audit.
	prj-c-scc	Contient des ressources permettant de configurer les alertes Security Command Center et d'autres fonctionnalités de surveillance de sécurité personnalisées. Pour en savoir plus, consultez la section Surveiller les menaces avec Security Command Center.
	prj-c-billing-logs	Contient un ensemble de données BigQuery contenant les exportations de la facturation de l'organisation. Pour en savoir plus, consultez la page Allouer des coûts entre des centres de coûts internes.
	prj-c-infra-pipeline	Il contient un pipeline d'infrastructure permettant de déployer des ressources telles que des VM et des bases de données qui seront utilisées par les charges de travail. Pour en savoir plus, consultez la section Couches de pipeline.
	prj-c-kms	Contient des clés de chiffrement au niveau de l'organisation. Pour en savoir plus, consultez la page Gérer les clés de chiffrement.
networking	prj-net-{env}-shared-base	Il contient le projet hôte pour un réseau VPC partagé pour les charges de travail qui ne nécessitent pas VPC Service Controls. Pour plus d'informations, consultez la section Topologie du réseau.
	prj-net-{env}-shared-restricted	Il contient le projet hôte pour un réseau VPC partagé pour les charges de travail qui nécessitent VPC Service Controls. Pour plus d'informations, consultez la section Topologie du réseau.
	prj-net-interconnect	Contient les connexions Cloud Interconnect qui fournissent la connectivité entre votre environnement sur site et Google Cloud. Pour en savoir plus, consultez l'article Connectivité hybride.
	prj-net-dns-hub	Il contient des ressources pour un point de communication central entre votre système DNS sur site et Cloud DNS. Pour en savoir plus, consultez la section Configuration DNS centralisée.
Dossiers d'environnement (production, non-production et development)	prj-{env}-monitoring	Contient un projet de champ d'application pour agréger les métriques des projets dans cet environnement. Pour en savoir plus, consultez la page Créer des alertes sur les métriques basées sur les journaux et les métriques de performances.
	prj-{env}-secrets	Contient des secrets au niveau du dossier. Pour en savoir plus, consultez la page Stocker et auditer les identifiants de l'application avec Secret Manager.
	prj-{env}-kms	Contient des clés de chiffrement au niveau du dossier. Pour en savoir plus, consultez la page Gérer les clés de chiffrement.
	application projects	Contient divers projets dans lesquels vous créez des ressources pour les applications. Pour en savoir plus, consultez les sections Modèles de déploiement de projet et couches de pipeline.

Gouvernance pour la propriété des ressources

Nous vous recommandons d'appliquer des libellés de manière cohérente à vos projets pour faciliter la gouvernance et l'attribution des coûts. Le tableau suivant décrit les libellés de projet ajoutés à chaque projet pour la gouvernance du plan.

Libellé	Description
application	Nom lisible de l'application ou de la charge de travail associée au projet.
businesscode	Code court décrivant l'unité commerciale dont dépend le projet. Le code shared est utilisé pour les projets courants qui ne sont pas explicitement liés à une unité commerciale.
billingcode	Code utilisé pour fournir des informations de rejet de débit.
primarycontact	Nom d'utilisateur du contact principal responsable du projet. Étant donné que les libellés de projet ne peuvent pas inclure de caractères spéciaux tels que l'esperluette (@), ils sont définis sur le nom d'utilisateur sans le suffixe @example.com.
secondarycontact	Nom d'utilisateur du contact secondaire secondaire responsable du projet. Comme les libellés de projet ne peuvent pas inclure de caractères spéciaux tels que @, définissez uniquement le nom d'utilisateur sans le suffixe @example.com.
environment	Une valeur qui identifie le type d'environnement, telle que bootstrap, common, production, non-production,development ou network.
envcode	Une valeur qui identifie le type d'environnement, raccourcie à b, c, p, n, d ou net.
vpc	ID du réseau VPC que ce projet est censé utiliser.

Il peut arriver que Google vous envoie des notifications importantes, telles que la suspension de votre compte ou la modification de vos conditions produit. Le plan utilise les contacts essentiels pour envoyer ces notifications aux groupes que vous configurez lors du déploiement. Les contacts essentiels sont configurés au niveau du nœud d'organisation et sont hérités par tous les projets de l'organisation. Nous vous recommandons de vérifier ces groupes et de vous assurer que la surveillance des e-mails est fiable.

Les contacts essentiels sont utilisés à des fins différentes de celles des champs primarycontact et secondarycontact configurés dans les libellés de projet. Les contacts des libellés de projet sont destinés à la gouvernance interne. Par exemple, si vous identifiez des ressources non conformes dans un projet de charge de travail et que vous devez contacter les propriétaires, vous pouvez utiliser le champ primarycontact pour rechercher la personne ou l'équipe responsable de cette charge de travail.

Étapes suivantes

• Lisez la section sur la mise en réseau (document suivant de cette série).

Mise en réseau

La mise en réseau est nécessaire pour que les ressources puissent communiquer au sein de votre organisation Google Cloud et entre votre environnement cloud et votre environnement sur site. Cette section décrit la structure du plan pour les réseaux VPC, l'espace d'adresses IP, les DNS, les règles de pare-feu et la connectivité à l'environnement sur site.

Topologie du réseau

Le dépôt de plans fournit les options suivantes pour votre topologie de réseau:

• Utilisez des réseaux VPC partagés distincts pour chaque environnement, sans aucun trafic réseau directement autorisé entre les environnements.
• Utilisez un modèle hub et spoke qui ajoute un réseau hub pour connecter chaque environnement dans Google Cloud, avec le trafic réseau entre les environnements contrôlés par un dispositif virtuel de réseau (NVA).

Choisissez la topologie du réseau VPC partagé double lorsque vous ne souhaitez pas de connectivité réseau directe entre les environnements. Choisissez la topologie du réseau hub et spoke lorsque vous souhaitez autoriser la connectivité réseau entre les environnements filtrés par un dispositif virtuel de réseau, par exemple lorsque vous utilisez des outils existants nécessitant un chemin de réseau direct à chaque serveur de votre environnement.

Les deux topologies utilisent le VPC partagé comme construction de réseau principale, car le VPC partagé permet une séparation claire des responsabilités. Les administrateurs réseau gèrent les ressources réseau dans un projet hôte centralisé, et les équipes de charge de travail déploient leurs propres ressources d'application et consomment les ressources réseau dans les projets de service associés au projet hôte.

Les deux topologies incluent une version de base et une version restreinte de chaque réseau VPC. Le réseau VPC de base est utilisé pour les ressources contenant des données non sensibles, et le réseau VPC restreint est utilisé pour les ressources contenant des données sensibles nécessitant VPC Service Controls. Pour en savoir plus sur la mise en œuvre de VPC Service Controls, consultez la page Protéger vos ressources avec VPC Service Controls.

Topologie d'un réseau VPC partagé double

Si vous avez besoin d'une isolation réseau entre vos réseaux de développement, hors production et de production sur Google Cloud, nous vous recommandons la topologie de réseau VPC partagé double. Cette topologie utilise des réseaux VPC partagés distincts pour chaque environnement, chaque environnement étant également divisé entre un réseau VPC partagé de base et un réseau VPC partagé restreint.

Le schéma suivant illustre la topologie de réseau VPC partagé double.

Le schéma décrit les concepts clés suivants de la topologie de VPC partagé double:

• Chaque environnement (production, hors production et développement) dispose d'un réseau VPC partagé pour le réseau de base et d'un réseau VPC partagé pour le réseau restreint. Ce schéma n'affiche que l'environnement de production, mais le même schéma est répété pour chaque environnement.
• Chaque réseau VPC partagé comporte deux sous-réseaux, chaque sous-réseau situé dans une région différente.
• La connectivité avec les ressources sur site est activée via quatre rattachements de VLAN à l'instance d'interconnexion dédiée pour chaque réseau VPC partagé, à l'aide de quatre services Cloud Router (deux dans chaque région pour la redondance). Pour en savoir plus, consultez la page Connectivité hybride entre l'environnement sur site et Google Cloud.

De par sa conception, cette topologie ne permet pas au trafic réseau de circuler directement entre les environnements. Si vous avez besoin que le trafic réseau circule directement entre les environnements, vous devez prendre des mesures supplémentaires pour autoriser ce chemin de réseau. Par exemple, vous pouvez configurer les points de terminaison Private Service Connect pour exposer un service d'un réseau VPC à un autre réseau VPC. Vous pouvez également configurer votre réseau sur site pour permettre au trafic de circuler d'un environnement Google Cloud vers l'environnement sur site, puis vers un autre environnement Google Cloud.

Topologie de réseau hub et spoke

Si vous déployez dans Google Cloud des ressources qui nécessitent un chemin d'accès réseau direct vers des ressources situées dans plusieurs environnements, nous vous recommandons d'utiliser la topologie de réseau hub-and-spoke.

La topologie hub et spoke utilise plusieurs concepts de la topologie de VPC partagé double, mais modifie la topologie pour ajouter un réseau hub. Le schéma suivant illustre la topologie hub et spoke.

Le schéma décrit les concepts clés suivants de la topologie de réseau hub-and-spoke:

• Ce modèle ajoute un réseau hub et chacun des réseaux de développement, hors production et de production (spokes) est connecté au réseau hub via l'appairage de réseaux VPC. Si vous prévoyez de dépasser la limite de quota, vous pouvez également utiliser une passerelle VPN haute disponibilité.
• La connectivité aux réseaux sur site n'est autorisée que via le réseau hub. Tous les réseaux spokes peuvent communiquer avec les ressources partagées du réseau hub et utiliser ce chemin pour se connecter aux réseaux sur site.
• Les réseaux hubs incluent un dispositif virtuel de réseau pour chaque région, déployé de manière redondante derrière des instances d'équilibreur de charge réseau interne. Ce dispositif virtuel de réseau sert de passerelle pour autoriser ou refuser le trafic entre les réseaux spokes.
• Le réseau hub héberge également des outils qui nécessitent une connectivité à tous les autres réseaux. Par exemple, vous pouvez déployer des outils sur des instances de VM pour gérer la configuration dans l'environnement commun.
• Le modèle hub et spoke est dupliqué pour une version de base et une version restreinte de chaque réseau.

Pour activer le trafic de spoke à spoke, le plan déploie les NVA sur le réseau VPC partagé hub agissant comme des passerelles entre les réseaux. Les routes sont échangées à partir de réseaux VPC hub vers des réseaux VPC spoke via un échange de routes personnalisées. Dans ce scénario, la connectivité entre les spokes doit être acheminée via le NVIDIA, car l'appairage de réseaux VPC est non transitif. Par conséquent, les réseaux VPC spoke ne peuvent pas échanger de données directement entre eux. Vous devez configurer les dispositifs virtuels pour autoriser de manière sélective le trafic entre les spokes.

Pour en savoir plus sur le contrôle du trafic entre les spokes à l'aide de dispositifs virtuels, consultez la page Dispositifs réseau centralisés sur Google Cloud.

Modèles de déploiement de projets

Lorsque vous créez des projets pour des charges de travail, vous devez décider de la façon dont les ressources de ce projet se connectent à votre réseau existant. Le tableau suivant décrit les modèles de déploiement des projets utilisés dans le plan.

Modèle	Description	Exemple d'utilisation
Projets de base partagés	Ces projets sont configurés en tant que projets de service dans un projet hôte de VPC partagé de base. Utilisez ce modèle lorsque les ressources de votre projet répondent aux critères suivants: Exige une connectivité réseau à l'environnement sur site ou aux ressources dans la même topologie de VPC partagé. Exiger un chemin d'accès réseau vers les services Google disponibles sur l'adresse IP virtuelle privée. Ne nécessitent pas VPC Service Controls.	example_base_shared_vpc_project.tf
Projets partagés restreints	Ces projets sont configurés en tant que projets de service dans un projet hôte de VPC partagé restreint. Utilisez ce modèle lorsque les ressources de votre projet répondent aux critères suivants: Exige une connectivité réseau à l'environnement sur site ou aux ressources dans la même topologie de VPC partagé. Exige un chemin d'accès de réseau vers les services Google contenus sur l'adresse IP virtuelle restreinte Exige VPC Service Controls	example_restricted_shared_vpc_project.tf
Projets flottants	Les projets flottants ne sont pas connectés à d'autres réseaux VPC dans votre topologie. Utilisez ce modèle lorsque les ressources de votre projet répondent aux critères suivants: Vous n'avez pas besoin d'une connectivité maillée complète à un environnement sur site ni à des ressources dans la topologie de VPC partagé. Vous n'avez pas besoin d'un réseau VPC, ou vous souhaitez gérer le réseau VPC de ce projet indépendamment de la topologie de votre réseau VPC principale (par exemple, lorsque vous souhaitez utiliser une plage d'adresses IP qui entre en conflit avec les plages déjà utilisées). Imaginons que vous souhaitiez séparer le réseau VPC d'un projet flottant de la topologie du réseau VPC principale, tout en exposant un nombre limité de points de terminaison entre les réseaux. Dans ce cas, publiez des services à l'aide de Private Service Connect pour partager l'accès réseau à un point de terminaison individuel sur plusieurs réseaux VPC, sans exposer l'ensemble du réseau.	example_floating_project.tf
Projets d'appairage	Les projets d'appairage créent leurs propres réseaux VPC et s'appairent à d'autres réseaux VPC dans votre topologie. Utilisez ce modèle lorsque les ressources de votre projet répondent aux critères suivants: Exigez une connectivité réseau dans le réseau VPC directement appairé, mais ne nécessitent pas de connectivité transitive vers un environnement sur site ou d'autres réseaux VPC. Il doit gérer le réseau VPC de ce projet indépendamment de la topologie principale de votre réseau. Si vous créez des projets d'appairage, vous êtes tenu d'allouer des plages d'adresses IP non conflictuelles et de planifier le quota des groupes d'appairage.	example_peering_project.tf

Attribution d'adresses IP

Cette section explique comment l'architecture du plan alloue des 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.

Le tableau suivant fournit la répartition de l'espace d'adressage IP alloué au plan. L'environnement hub ne s'applique que dans la topologie hub et spoke.

Objectif	Type de VPC	Région	Environnement hub	Environnement de développement	Environnement hors production	Environnement de production
Plages de sous-réseaux principales	Couches	Région 1	10.0.0.0/18	10.0.64.0/18	10.0.128.0/18	10.0.192.0/18
		Région 2	10.1.0.0/18	10.1.64.0/18	10.1.128.0/18	10.1.192.0/18
		Non allouées	10.{2-7}.0.0/18	10.{2-7}.64.0/18	10.{2-7}.128.0/18	10.{2-7}.192.0/18
	Limité	Région 1	10.8.0.0/18	10.8.64.0/18	10.8.128.0/18	10.8.192.0/18
		Région 2	10.9.0.0/18	10.9.64.0/18	10.9.128.0/18	10.9.192.0/18
		Non allouées	10.{10-15}.0.0/18	10.{10-15}.64.0/18	10.{10-15}.128.0/18	10.{10-15}.192.0/18
Accès aux services privés	Couches	Monde	10.16.0.0/21	10.16.8.0/21	10.16.16.0/21	10.16.24.0/21
	Limité	Monde	10.16.32.0/21	10.16.40.0/21	10.16.48.0/21	10.16.56.0/21
Points de terminaison Private Service Connect	Couches	Monde	10.17.0.1/32	10.17.0.2/32	10.17.0.3/32	10.17.0.4/32
	Limité	Monde	10.17.0.5/32	10.17.0.6/32	10.17.0.7/32	10.17.0.8/32
Sous-réseaux proxy réservés	Couches	Région 1	10.18.0.0/23	10.18.2.0/23	10.18.4.0/23	10.18.6.0/23
		Région 2	10.19.0.0/23	10.19.2.0/23	10.19.4.0/23	10.19.6.0/23
		Non allouées	10.{20-25}.0.0/23	10.{20-25}.2.0/23	10.{20-25}.4.0/23	10.{20-25}.6.0/23
	Limité	Région 1	10.26.0.0/23	10.26.2.0/23	10.26.4.0/23	10.26.6.0/23
		Région 2	10.27.0.0/23	10.27.2.0/23	10.27.4.0/23	10.27.6.0/23
		Non allouées	10.{28-33}.0.0/23	10.{28-33}.2.0/23	10.{28-33}.4.0/23	10.{28-33}.6.0/23
Plages de sous-réseaux secondaires	Couches	Région 1	100.64.0.0/18	100.64.64.0/18	100.64.128.0/18	100.64.192.0/18
		Région 2	100.65.0.0/18	100.65.64.0/18	100.65.128.0/18	100.65.192.0/18
		Non allouées	100.{66-71}.0.0/18	100.{66-71}.64.0/18	100.{66-71}.128.0/18	100.{66-71}.192.0/18
	Limité	Région 1	100.72.0.0/18	100.72.64.0/18	100.72.128.0/18	100.72.192.0/18
		Région 2	100.73.0.0/18	100.73.64.0/18	100.73.128.0/18	100.73.192.0/18
		Non allouées	100.{74-79}.0.0/18	100.{74-79}.64.0/18	100.{74-79}.128.0/18	100.{74-79}.192.0/18

Le tableau précédent illustre ces concepts pour l'allocation de plages d'adresses IP:

• L'allocation d'adresses IP est subdivisée en plages pour chaque combinaison de VPC partagé de base, de VPC partagé restreint, de région et d'environnement.
• Certaines ressources sont globales et ne nécessitent pas de subdivision pour chaque région.
• Par défaut, pour les ressources régionales, le plan est déployé dans deux régions. En outre, il existe des plages d'adresses IP inutilisées que vous pouvez développer dans six régions supplémentaires.
• Le réseau hub n'est utilisé que dans la topologie de réseau hub-and-spoke, tandis que les environnements de développement, hors production et de production sont utilisés dans les deux topologies de réseau.

Le tableau suivant explique comment chaque type de plage d'adresses IP est utilisé.

Objectif	Description
Plages de sous-réseaux principales	Les ressources que vous déployez sur votre réseau VPC, telles que les instances de machine virtuelle, utilisent des adresses IP internes provenant de ces plages.
Accès aux services privés	Certains services Google Cloud tels que Cloud SQL nécessitent la pré-allocation d'une plage de sous-réseaux pour l'accès aux services privés. Le plan réserve une plage /21 pour chacun des réseaux VPC partagés à l'échelle mondiale, afin d'allouer des adresses IP aux services qui nécessitent un accès aux services privés. Lorsque vous créez un service qui dépend de l'accès aux services privés, vous allouez un sous-réseau /24 régional à partir de la plage /21 réservée.
Private Service Connect	Le plan provisionne chaque réseau VPC avec un point de terminaison Private Service Connect pour communiquer avec les API Google Cloud. Ce point de terminaison permet à vos ressources du réseau VPC d'atteindre les API Google Cloud sans s'appuyer sur le trafic sortant vers les plages Internet ou les plages Internet annoncées publiquement.
Équilibreurs de charge basés sur un proxy	Certains types d'équilibreurs de charge d'application nécessitent la pré-allocation de sous-réseaux proxy réservés. Bien que le plan ne déploie pas d'équilibreurs de charge d'application qui nécessitent cette plage, l'allocation préalable de plages permet de réduire les frictions des charges de travail lorsqu'elles doivent demander une nouvelle plage de sous-réseau pour activer certaines ressources d'équilibreurs de charge.
Plages de sous-réseaux secondaires	Certains cas d'utilisation, tels que les charges de travail basées sur des conteneurs, nécessitent des plages secondaires. Le plan alloue des plages de l'espace d'adresses IP RFC 6598 pour les plages secondaires.

Configuration DNS centralisée

Pour la résolution DNS entre les environnements Google Cloud et sur site, nous vous recommandons d'utiliser une approche hybride avec deux systèmes DNS faisant autorité. Dans cette approche, Cloud DNS gère la résolution DNS faisant autorité pour votre environnement Google Cloud, et vos serveurs DNS sur site existants gèrent la résolution DNS faisant autorité pour les ressources sur site. Votre environnement sur site et votre environnement Google Cloud effectuent des résolutions DNS entre les environnements via des requêtes de transfert.

Le schéma suivant illustre la topologie DNS sur les différents réseaux VPC utilisés dans le plan.

Le schéma décrit les composants suivants de la conception DNS déployée par le plan:

• Le projet de hub DNS dans le dossier commun est le point central de l'échange DNS entre l'environnement sur site et l'environnement Google Cloud. Le transfert DNS utilise les instances d'interconnexion dédiée et les routeurs cloud déjà configurés dans votre topologie de réseau.
  • Dans la topologie à VPC partagé double, le hub DNS utilise le réseau VPC partagé de production partagé de base.
  • Dans la topologie hub et spoke, le hub DNS utilise le réseau VPC partagé hub de base.
• Les serveurs de chaque réseau VPC partagé peuvent résoudre les enregistrements DNS d'autres réseaux VPC partagés via le transfert DNS, qui est configuré entre Cloud DNS dans chaque projet hôte de VPC partagé et le hub DNS.
• Les serveurs sur site peuvent résoudre les enregistrements DNS dans les environnements Google Cloud à l'aide de règles de serveur DNS qui autorisent les requêtes depuis des serveurs sur site. Le plan configure une règle de serveur entrant dans le hub DNS pour allouer des adresses IP, et les serveurs DNS sur site transfèrent les requêtes vers ces adresses. Toutes les requêtes DNS adressées à Google Cloud atteignent d'abord le hub DNS, qui résout ensuite les enregistrements des pairs DNS.
• Les serveurs Google Cloud peuvent résoudre les enregistrements DNS dans l'environnement sur site à l'aide de zones de transfert qui interrogent les serveurs sur site. Toutes les requêtes DNS adressées à l'environnement sur site proviennent du hub DNS. La source de la requête DNS est 35.199.192.0/19.

Stratégies de pare-feu

Google Cloud propose plusieurs types de stratégies de pare-feu. Les stratégies de pare-feu hiérarchiques sont appliquées au niveau de l'organisation ou du dossier pour hériter des règles de stratégie de pare-feu de manière cohérente sur toutes les ressources de la hiérarchie. En outre, vous pouvez configurer des stratégies de pare-feu réseau pour chaque réseau VPC. Le plan combine ces stratégies de pare-feu pour appliquer des configurations communes à tous les environnements à l'aide de stratégies de pare-feu hiérarchiques et pour appliquer des configurations plus spécifiques à chaque réseau VPC individuel à l'aide de stratégies de pare-feu de réseau.

Le plan n'utilise pas les anciennes règles de pare-feu VPC. Nous vous recommandons de n'utiliser que des stratégies de pare-feu et d'éviter de mélanger l'utilisation avec les anciennes règles de pare-feu VPC.

Stratégies de pare-feu hiérarchiques

Le plan définit une stratégie de pare-feu hiérarchique unique et l'associe à chacun des dossiers de production, hors production, de développement, d'amorçage et courants. Cette stratégie de pare-feu hiérarchique contient les règles qui doivent être appliquées de manière générale à tous les environnements et délègue l'évaluation de règles plus précises à la stratégie de pare-feu réseau pour chaque environnement individuel.

Le tableau suivant décrit les règles de stratégies de pare-feu hiérarchiques déployées par le plan.

Description de la règle	Sens du trafic	Filtre (plage IPv4)	Protocoles et ports	Action
Déléguer l'évaluation du trafic entrant de la RFC 1918 à des niveaux inférieurs de la hiérarchie.	Ingress	192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12	all	Go to next
Déléguer l'évaluation du trafic sortant à la norme RFC 1918 à des niveaux inférieurs de la hiérarchie	Egress	192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12	all	Go to next
IAP pour le transfert TCP	Ingress	35.235.240.0/20	tcp:22,3390	Allow
Activation de Windows Server	Egress	35.190.247.13/32	tcp:1688	Allow
Vérifications d'état pour Cloud Load Balancing.	Ingress	130.211.0.0/22, 35.191.0.0/16, 209.85.152.0/22, 209.85.204.0/22	tcp:80,443	Allow

Stratégies de pare-feu réseau

Le plan configure une stratégie de pare-feu réseau pour chaque réseau. Chaque stratégie de pare-feu réseau commence par un ensemble minimal de règles qui autorisent l'accès aux services Google Cloud et refusent la sortie vers toutes les autres adresses IP.

Dans le modèle hub et spoke, les stratégies de pare-feu réseau contiennent des règles supplémentaires pour autoriser la communication entre les spokes. La stratégie de pare-feu réseau autorise le trafic sortant de l'un vers le hub ou un autre spoke, et autorise le trafic entrant depuis le NVA sur le réseau hub.

Le tableau suivant décrit les règles de la stratégie de pare-feu de réseau au niveau mondial déployées pour chaque réseau VPC du plan.

Description de la règle	Sens du trafic	Filtre	Protocoles et ports
Autorise le trafic sortant vers les API Google Cloud.	Egress	Point de terminaison Private Service Connect configuré pour chaque réseau individuel. Consultez la section Accès privé aux API Google.	tcp:443
Refusez le trafic sortant ne correspondant pas à d'autres règles.	Egress	tous	all
Autorisez le trafic sortant d'un spoke à un autre spoke (pour le modèle hub et spoke uniquement).	Egress	Agrégation de toutes les adresses IP utilisées dans la topologie hub et spoke. Le trafic quittant un VPC spoke est d'abord acheminé vers le NVA dans le réseau hub.	all
Autorisez le trafic entrant vers un spoke du dispositif virtuel de réseau dans le réseau hub (pour le modèle hub et spoke uniquement).	Ingress	Trafic provenant des dispositifs virtuels de réseau du réseau hub.	all

Lorsque vous déployez le plan pour la première fois, une instance de VM dans un réseau VPC peut communiquer avec les services Google Cloud, mais pas vers d'autres ressources d'infrastructure du même réseau VPC. Pour autoriser les instances de VM à communiquer, vous devez ajouter des règles supplémentaires à votre stratégie de pare-feu réseau et des tags qui autorisent explicitement les instances de VM à communiquer. Les tags sont ajoutés aux instances de VM et le trafic est évalué en fonction de ces tags. Les tags disposent également de contrôles IAM afin que vous puissiez les définir de manière centralisée et déléguer leur utilisation à d'autres équipes.

Le schéma suivant montre comment ajouter des tags personnalisés et des règles de stratégie de pare-feu réseau pour permettre aux charges de travail de communiquer au sein d'un réseau VPC.

Le diagramme illustre les concepts suivants de cet exemple:

• La stratégie de pare-feu réseau contient la règle 1 qui refuse le trafic sortant de toutes les sources avec la priorité 65530.
• La stratégie de pare-feu réseau contient la règle 2 qui autorise le trafic entrant provenant d'instances portant le tag service=frontend vers des instances dotées du tag service=backend avec la priorité 999.
• La VM instance-2 peut recevoir du trafic provenant de l'instance-1, car ce trafic correspond aux tags autorisés par la règle 2. La règle 2 est mise en correspondance avant l'évaluation de la règle 1, en fonction de la valeur de priorité.
• La VM instance-3 ne reçoit pas de trafic. La seule règle de stratégie de pare-feu qui correspond à ce trafic est la règle 1. Le trafic sortant de l'instance-1 est donc refusé.

Accès privé aux API Google Cloud

Pour permettre aux ressources de vos réseaux VPC ou de votre environnement sur site d'accéder aux services Google Cloud, nous vous recommandons d'utiliser une connectivité privée plutôt que le trafic Internet sortant vers les points de terminaison d'API publiques. Le plan configure l'accès privé à Google sur chaque sous-réseau et crée des points de terminaison internes avec Private Service Connect pour communiquer avec les services Google Cloud. Utilisés conjointement, ces contrôles permettent d'utiliser un chemin privé vers des services Google Cloud sans s'appuyer sur le trafic sortant Internet ou les plages Internet annoncées publiquement.

Le plan configure les points de terminaison Private Service Connect avec des groupes d'API pour différencier les services accessibles sur chaque réseau. Le réseau de base utilise le groupe all-apis et peut atteindre n'importe quel service Google, et le réseau restreint utilise le groupe vpcsc qui permet d'accéder à un ensemble limité de services qui est compatible avec VPC Service Controls.

Pour accéder aux hôtes situés dans un environnement sur site, nous vous recommandons d'utiliser une convention de nom de domaine complet personnalisé pour chaque point de terminaison, comme décrit dans le tableau suivant. Le plan utilise un point de terminaison Private Service Connect unique pour chaque réseau VPC, configuré pour accéder à un ensemble différent de groupes d'API. Par conséquent, vous devez déterminer comment acheminer le trafic du service depuis l'environnement sur site vers le réseau VPC avec le point de terminaison de l'API approprié et, si vous utilisez VPC Service Controls, assurez-vous que ce trafic vers les services Google Cloud atteigne le point de terminaison dans le périmètre prévu. Configurez vos contrôles sur site pour DNS, pare-feu et routeurs afin d'autoriser l'accès à ces points de terminaison et configurez les hôtes sur site pour utiliser le point de terminaison approprié. Pour plus d'informations, consultez la page Accéder aux API Google via des points de terminaison.

Le tableau suivant décrit les points de terminaison Private Service Connect créés pour chaque réseau.

VPC	Environnement	Bundle d'API	Adresse IP du point de terminaison Private Service Connect			Nom de domaine complet personnalisé
Couches	Courant	all-apis	10.17.0.1/32			c.private.googleapis.com
	Développement	all-apis	10.17.0.2/32			d.private.googleapis.com
	Hors production	all-apis	10.17.0.3/32			n.private.googleapis.com
	Production	all-apis	10.17.0.4/32			p.private.googleapis.com
Limité	Courant	vpcsc	10.17.0.5/32			c.restricted.googleapis.com
	Développement	vpcsc	10.17.0.6/32			d.restricted.googleapis.com
	Hors production	vpcsc	10.17.0.7/32			n.restricted.googleapis.com
	Production	vpcsc	10.17.0.8/32			p.restricted.googleapis.com

Pour garantir que le trafic des services Google Cloud dispose d'une résolution DNS vers le point de terminaison approprié, le plan configure les zones DNS privées pour chaque réseau VPC. Le tableau suivant décrit ces zones DNS privées.

Nom de zone privée	Nom DNS	Type d'enregistrement	Données
googleapis.com.	*.googleapis.com.	CNAME	private.googleapis.com. (pour les réseaux de base) ou restricted.googleapis.com. (pour les réseaux restreints)
	private.googleapis.com (pour les réseaux de base) ou restricted.googleapis.com (pour les réseaux restreints)	A	Adresse IP du point de terminaison Private Service Connect pour ce réseau VPC.
gcr.io.	*.gcr.io	CNAME	gcr.io.
	gcr.io	A	Adresse IP du point de terminaison Private Service Connect pour ce réseau VPC.
pkg.dev.	*.pkg.dev.	CNAME	pkg.dev.
	pkg.dev.	A	Adresse IP du point de terminaison Private Service Connect pour ce réseau VPC.

Le plan contient des configurations supplémentaires pour s'assurer que ces points de terminaison Private Service Connect sont utilisés de manière cohérente. Chaque réseau VPC partagé applique également les éléments suivants:

• Règle de stratégie de pare-feu réseau qui autorise le trafic sortant de toutes les sources vers l'adresse IP du point de terminaison Private Service Connect sur TCP:443.
• Une règle de stratégie de pare-feu réseau qui refuse le trafic sortant à 0.0.0.0/0, ce qui inclut les domaines par défaut utilisés pour accéder aux services Google Cloud.

Connectivité Internet

Le plan n'autorise pas le trafic entrant ou sortant entre ses réseaux VPC et Internet. Pour les charges de travail nécessitant une connectivité Internet, vous devez prendre des mesures supplémentaires pour concevoir les chemins d'accès requis.

Pour les charges de travail nécessitant du trafic sortant vers Internet, nous vous recommandons de gérer le trafic sortant via Cloud NAT afin d'autoriser le trafic sortant sans connexion entrante non sollicitée, ou via Proxy Web sécurisé pour un contrôle plus précis de l'autorisation du trafic sortant vers des services Web de confiance uniquement.

Pour les charges de travail nécessitant le trafic entrant provenant d'Internet, nous vous recommandons de concevoir votre charge de travail avec les éléments suivants :Cloud Load Balancing et Google Cloud Armor pour bénéficier des protections DDoS et WAF.

Nous vous déconseillons de concevoir des charges de travail permettant une connectivité directe entre Internet et une VM via une adresse IP externe sur la VM.

Connectivité hybride entre un environnement sur site et Google Cloud

Pour établir la connectivité entre l'environnement sur site et Google Cloud, nous vous recommandons d'utiliser l'interconnexion dédiée afin d'optimiser la sécurité et la fiabilité. Une connexion par interconnexion dédiée est une liaison directe entre le réseau sur site et Google Cloud.

Le schéma suivant illustre la connectivité hybride entre l'environnement sur site et un réseau cloud privé virtuel Google.

Le schéma décrit les composants suivants du modèle pour une disponibilité de 99,99% pour l'interconnexion dédiée:

• Quatre connexions d'interconnexion dédiée, avec deux connexions dans une zone métropolitaine (agglomération) et deux connexions dans une autre.
• Les connexions sont divisées en deux paires, chaque paire étant connectée à un centre de données sur site distinct.
• Les rattachements de VLAN permettent de connecter chaque instance de Dedicated Interconnect aux routeurs Cloud Router associés à la topologie de VPC partagé. Ces rattachements de VLAN sont hébergés dans le projet prj-c-interconnect.
• Chaque réseau VPC partagé possède quatre routeurs cloud, deux dans chaque région, avec le mode de routage dynamique défini sur global afin que chaque routeur cloud puisse annoncer tous les sous-réseaux, indépendamment de la région.

Le routage dynamique mondial permet au Cloud Router de diffuser des routages vers l'ensemble des sous-réseaux du réseau VPC. Cloud Router diffuse les routages vers des sous-réseaux distants (sous-réseaux situés en dehors de la région du routeur cloud) avec une priorité inférieure à celle des sous-réseaux locaux (sous-réseaux situés dans la région du routeur cloud). Vous pouvez éventuellement modifier les préfixes et les priorités annoncés lorsque vous configurez la session BGP pour un routeur cloud.

Le trafic depuis Google Cloud vers un environnement sur site utilise le routeur Cloud Router le plus proche des ressources cloud. Dans une même région, plusieurs routes vers des réseaux sur site ont la même valeur de discriminateur multisortie (MED), et Google Cloud utilise le routage ECMP (Equal Cost Multi-Path) pour distribuer le trafic sortant entre toutes les routes possibles.

Modifications de la configuration sur site

Pour configurer la connectivité entre l'environnement sur site et Google Cloud, vous devez configurer des modifications supplémentaires dans votre environnement sur site. Le code Terraform du plan configure automatiquement les ressources Google Cloud, mais ne modifie aucune de vos ressources réseau sur site.

Certains composants de la connectivité hybride de votre environnement sur site vers Google Cloud sont automatiquement activés par le plan, y compris les suivants:

• Cloud DNS est configuré avec un transfert DNS entre tous les réseaux VPC partagés vers un seul hub, comme décrit dans la section Configuration DNS. Une règle de serveur Cloud DNS est configurée avec des adresses IP de redirecteur entrant.
• Cloud Router est configuré pour exporter les routes de tous les sous-réseaux et les routes personnalisées pour les adresses IP utilisées par les points de terminaison Private Service Connect.

Pour activer la connectivité hybride, vous devez effectuer les étapes supplémentaires suivantes:

1. Commander une connexion par interconnexion dédiée
2. Configurez les routeurs et les pare-feu sur site pour autoriser le trafic sortant vers l'espace d'adressage IP interne défini dans la section Allocation d'espace d'adressage IP.
3. Configurez vos serveurs DNS sur site pour transférer les résolutions DNS associées à Google Cloud vers les adresses IP du redirecteur entrant déjà configurées par le plan.
4. Configurez vos serveurs DNS, vos pare-feu et vos routeurs sur site pour accepter les requêtes DNS provenant de la zone de transfert Cloud DNS (35.199.192.0/19).
5. Configurez les serveurs DNS sur site pour répondre aux requêtes des hôtes sur site vers les services Google Cloud avec les adresses IP définies dans l'accès privé aux API Cloud.
6. Pour le chiffrement en transit sur la connexion par interconnexion dédiée, configurez MACsec pour Cloud Interconnect ou le VPN haute disponibilité sur Cloud Interconnect pour le chiffrement IPsec.

Pour plus d'informations, consultez la section Accès privé à Google pour les hôtes sur site.

Étapes suivantes

• Découvrez les contrôles de détection (document suivant de cette série).

Les contrôles de détection

Les fonctionnalités de détection et de surveillance des menaces sont fournies à l'aide d'une combinaison de contrôles de sécurité intégrés de Security Command Center et de solutions personnalisées qui vous permettent de détecter les événements de sécurité et d'y répondre.

Journalisation centralisée pour la sécurité et l'audit

Le plan configure les fonctionnalités de journalisation pour suivre et analyser les modifications apportées à vos ressources Google Cloud à l'aide de journaux agrégés dans un seul projet.

Le schéma suivant montre comment le plan agrège les journaux provenant de plusieurs sources dans plusieurs projets dans un récepteur de journaux centralisé.

Le schéma décrit les éléments suivants:

• Les récepteurs de journaux sont configurés au niveau du nœud d'organisation pour agréger les journaux de tous les projets dans la hiérarchie des ressources.
• Plusieurs récepteurs de journaux sont configurés pour envoyer les journaux correspondant à un filtre vers différentes destinations pour le stockage et l'analyse.
• Le projet prj-c-logging contient toutes les ressources associées au stockage et à l'analyse des journaux.
• Vous pouvez éventuellement configurer des outils supplémentaires pour exporter les journaux vers une solution SIEM.

Le plan utilise différentes sources de journal et inclut ces journaux dans le filtre du récepteur de journaux, afin que ceux-ci puissent être exportés vers une destination centralisée. Le tableau suivant décrit les sources du journal.

Source de journal	Description
Journaux d'audit d'activités d'administration	Vous ne pouvez pas configurer, désactiver ni exclure les journaux d'audit des activités d'administration.
Journaux d'audit des événements système	Vous ne pouvez pas configurer, désactiver ni exclure les journaux d'audit des événements système.
Journaux d'audit des refus de règles	Vous ne pouvez pas configurer ni désactiver les journaux d'audit des refus de règles, mais vous pouvez éventuellement les exclure à l'aide de filtres d'exclusion.
Journaux d'audit des accès aux données	Par défaut, le plan n'active pas les journaux d'accès aux données, car leur volume et leur coût peuvent être élevés. Pour déterminer si vous devez activer les journaux d'accès aux données, évaluez l'emplacement de vos charges de travail dans les données sensibles et déterminez si vous devez activer les journaux d'accès aux données pour chaque service et environnement utilisant des données sensibles.
Journaux de flux VPC	Le plan permet d'activer les journaux de flux VPC pour chaque sous-réseau. Le plan configure l'échantillonnage de journal pour échantillonner 50% des journaux afin de réduire les coûts. Si vous créez des sous-réseaux supplémentaires, vous devez vous assurer que les journaux de flux VPC sont activés pour chaque sous-réseau.
Journalisation des règles de pare-feu	Le plan active la journalisation des règles de pare-feu pour chaque règle de stratégie de pare-feu. Si vous créez des règles de stratégie de pare-feu supplémentaires pour les charges de travail, vous devez vous assurer que la journalisation des règles de pare-feu est activée pour chaque nouvelle règle.
Journalisation Cloud DNS	Le plan permet d'activer les journaux Cloud DNS pour les zones gérées. Si vous créez des zones gérées supplémentaires, vous devez activer ces journaux DNS.
Journaux d'audit Google Workspace	Nécessite une étape d'activation unique qui n'est pas automatisée par le plan. Pour en savoir plus, consultez la page Partager des données avec les services Google Cloud.
Journaux Access Transparency,	Nécessite une étape d'activation unique qui n'est pas automatisée par le plan. Pour plus d'informations, consultez Activer Access Transparency.

Le tableau suivant décrit les récepteurs de journaux et leur utilisation avec les destinations compatibles dans le plan.

Sink	Destination	Objectif
sk-c-logging-la	Journaux acheminés vers des buckets Cloud Logging avec Log Analytics et un ensemble de données BigQuery associé activé	Analysez activement les journaux. Exécutez des enquêtes ad hoc à l'aide de l'explorateur de journaux de la console, ou écrivez des requêtes, des rapports et des vues SQL à l'aide de l'ensemble de données BigQuery associé.
sk-c-logging-bkt	Journaux acheminés vers Cloud Storage	Stockez les journaux à long terme à des fins de conformité, d'audit et de suivi des incidents. Éventuellement, si vous devez respecter des exigences de conformité concernant la conservation obligatoire des données, nous vous recommandons de configurer également le verrou de bucket.
sk-c-logging-pub	Journaux acheminés vers Pub/Sub	Exportez les journaux vers une plate-forme externe telle que votre SIEM existante. Cela nécessite un travail supplémentaire à intégrer à votre SIEM, tels que les mécanismes suivants: Pour de nombreux outils, l'intégration tierce à Pub/Sub est la méthode recommandée pour ingérer les journaux. Pour Google Chronicle, vous pouvez ingérer des données Google Cloud dans Chronicle sans provisionner d'infrastructure supplémentaire. Pour Splunk, vous pouvez diffuser des journaux depuis Google Cloud vers Splunk à l'aide de Dataflow.

Pour savoir comment activer des types de journaux supplémentaires et écrire des filtres de récepteur de journaux, consultez la page Outil de champ d'application des journaux.

Surveillance des menaces avec Security Command Center

Nous vous recommandons d'activer Security Command Center Premium pour votre organisation afin de détecter automatiquement les menaces, les failles et les erreurs de configuration dans vos ressources Google Cloud. Security Command Center crée des résultats de sécurité à partir de plusieurs sources, telles que les suivantes:

• Security Health Analytics:détecte les failles courantes et les erreurs de configuration des ressources Google Cloud.
• Exposition du chemin d'attaque:affiche un chemin simulé d'exploitation par un pirate informatique d'une ressource à forte valeur ajoutée en fonction des failles et des erreurs de configuration détectées par d'autres sources Security Command Center.
• Event Threat Detection:applique la logique de détection et les renseignements propriétaires sur les menaces à vos journaux pour identifier les menaces en quasi-temps réel.
• Container Threat Detection:détecte les attaques courantes sur les environnements d'exécution de conteneurs.
• Virtual Machine Threat Detection:détecte les applications potentiellement malveillantes qui s'exécutent sur des machines virtuelles.
• Web Security Scanner:analyse les dix failles principales du modèle OWASP dans vos applications Web sur Compute Engine, App Engine ou Google Kubernetes Engine.

Pour en savoir plus sur les failles et les menaces traitées par Security Command Center, consultez la page Sources Security Command Center.

Vous devez activer Security Command Center après avoir déployé le plan. Pour obtenir des instructions, consultez la page Activer Security Command Center pour une organisation.

Une fois que vous avez activé Security Command Center, nous vous recommandons d'exporter les résultats générés par Security Command Center vers vos outils ou processus existants afin de trier les menaces et d'y répondre. Le plan crée le projet prj-c-scc avec un sujet Pub/Sub à utiliser pour cette intégration. Selon vos outils existants, utilisez l'une des méthodes suivantes pour exporter les résultats:

• Si vous utilisez la console pour gérer les résultats de sécurité directement dans Security Command Center, configurez des rôles au niveau du dossier et du projet pour que Security Command Center puisse laisser les équipes afficher et gérer les résultats de sécurité uniquement pour les projets pour lesquels ils sont responsables.

• Si vous utilisez Chronicle comme solution SIEM, ingérez les données Google Cloud dans Chronicle.

• Si vous utilisez un outil SIEM ou SOAR avec des intégrations à Security Command Center, partagez les données avec Cortex XSOAR, Elastic Stack, ServiceNow, Splunk ou QRadar.

• Si vous utilisez un outil externe permettant d'ingérer des résultats de Pub/Sub, configurez des exportations continues vers Pub/Sub et configurez vos outils existants pour ingérer les résultats depuis le sujet Pub/Sub.

Créer des alertes sur les métriques basées sur les journaux et les métriques de performances

Lorsque vous commencez à déployer des charges de travail sur une base, nous vous recommandons d'utiliser Cloud Monitoring pour mesurer les métriques de performances.

Le plan crée un projet de surveillance tel que prj-p-monitoring pour chaque environnement. Ce projet est configuré en tant que projet de champ d'application pour collecter des métriques de performances agrégées sur plusieurs projets. Le plan déploie un exemple avec des métriques basées sur les journaux et une règle d'alerte pour générer des notifications par e-mail en cas de modification de la stratégie IAM appliquée aux buckets Cloud Storage. Cela permet de surveiller les activités suspectes sur des ressources sensibles telles que le bucket du projet prj-b-seed contenant l'état Terraform.

Plus généralement, vous pouvez également utiliser Cloud Monitoring pour mesurer les métriques de performances et l'état de vos applications de charge de travail. Selon la responsabilité opérationnelle liée à la compatibilité et à la surveillance des applications dans votre organisation, vous pouvez créer des projets de surveillance plus précis pour différentes équipes. Utilisez ces projets de surveillance pour afficher les métriques de performances, créer des tableaux de bord d'état de l'application et déclencher des alertes lorsque votre SLO attendu n'est pas atteint.

Le diagramme suivant montre une vue d'ensemble de l'agrégation des métriques de performances par Cloud Monitoring.

Pour obtenir des conseils sur la surveillance efficace de la fiabilité et de la disponibilité des charges de travail, consultez le Livre sur l'ingénierie en fiabilité des sites de Google, en particulier le chapitre sur la surveillance distribuée.

Solution personnalisée pour l'analyse automatisée des journaux

Vous devrez peut-être créer des alertes pour les événements de sécurité basés sur des requêtes personnalisées sur les journaux. Les requêtes personnalisées peuvent compléter les fonctionnalités de votre solution SIEM en analysant les journaux sur Google Cloud et en n'exportant que les événements qui méritent une enquête, en particulier si vous ne disposez pas de la capacité nécessaire pour exporter tous les journaux cloud vers votre SIEM.

Le plan permet d'activer cette analyse de journaux en configurant une source centralisée de journaux que vous pouvez interroger à l'aide d'un ensemble de données BigQuery associé. Pour automatiser cette fonctionnalité, vous devez mettre en œuvre l'exemple de code sur bq-log-alerting et étendre les fonctionnalités de base. L'exemple de code vous permet d'interroger régulièrement une source de journal et d'envoyer un résultat personnalisé à Security Command Center.

Le diagramme suivant présente le flux général de l'analyse automatisée des journaux.

Le schéma montre les concepts suivants de l'analyse automatisée des journaux:

• Les journaux provenant de diverses sources sont agrégés dans un bucket de journaux centralisé contenant des analyses de journaux et un ensemble de données BigQuery associé.
• Les vues BigQuery sont configurées pour interroger les journaux de l'événement de sécurité que vous souhaitez surveiller.
• Cloud Scheduler envoie un événement à un sujet Pub/Sub toutes les 15 minutes et déclenche Cloud Functions.
• Cloud Functions interroge les vues pour détecter de nouveaux événements. Si il trouve des événements, il les transmet à Security Command Center en tant que résultats personnalisés.
• Security Command Center publie des notifications sur les nouveaux résultats dans un autre sujet Pub/Sub.
• Un outil externe tel qu'une solution SIEM s'abonne au sujet Pub/Sub pour ingérer de nouveaux résultats.

L'exemple comporte plusieurs cas d'utilisation pour interroger un comportement potentiellement suspect. Il peut s'agir d'une connexion provenant d'une liste de super-administrateurs ou d'autres comptes hautement privilégiés que vous spécifiez, de modifications des paramètres de journalisation ou de modifications des routes réseau. Vous pouvez étendre les cas d'utilisation en écrivant de nouvelles vues de requête en fonction de vos besoins. Rédigez vos propres requêtes ou référencez les analyses des journaux de sécurité d'une bibliothèque de requêtes SQL pour vous aider à analyser les journaux Google Cloud.

Solution personnalisée pour répondre aux modifications d'éléments

Pour répondre aux événements en temps réel, nous vous recommandons d'utiliser l'inventaire des éléments cloud afin de surveiller les modifications des éléments. Dans cette solution personnalisée, un flux d'éléments est configuré pour déclencher des notifications à Pub/Sub concernant les modifications apportées aux ressources en temps réel. Ensuite, Cloud Functions exécute un code personnalisé pour appliquer votre propre logique métier, selon que la modification doit être autorisée.

Le plan contient un exemple de cette solution de gouvernance personnalisée qui surveille les modifications IAM qui ajoutent des rôles très sensibles, tels que "Administrateur de l'organisation", "Propriétaire" et "Éditeur". Le schéma suivant décrit cette solution.

Le schéma précédent illustre ces concepts:

• Des modifications sont apportées à une stratégie d'autorisation.
• Le flux d'inventaire des éléments cloud envoie une notification en temps réel concernant la modification de la stratégie d'autorisation à Pub/Sub.
• Pub/Sub déclenche une fonction.
• Cloud Functions exécute du code personnalisé pour appliquer votre stratégie. L'exemple de fonction dispose d'une logique permettant de déterminer si la modification a ajouté les rôles "Administrateur de l'organisation", "Propriétaire" ou "Éditeur" à une stratégie d'autorisation. Si tel est le cas, la fonction crée un résultat de sécurité personnalisé et l'envoie à Security Command Center.
• Vous pouvez éventuellement utiliser ce modèle pour automatiser les mesures correctives. Écrivez une logique métier supplémentaire dans Cloud Functions pour réagir automatiquement en fonction du résultat, par exemple rétablir la stratégie d'autorisation à son état précédent.

En outre, vous pouvez étendre l'infrastructure et la logique utilisées par cet exemple de solution pour ajouter des réponses personnalisées à d'autres événements importants pour votre entreprise.

Étapes suivantes

• Découvrez les contrôles préventifs (document suivant de cette série).

Contrôles préventifs pour les configurations de ressources acceptables

Nous vous recommandons de définir des contraintes de règles qui appliquent des configurations de ressources acceptables et empêchent les configurations risquées. Le plan utilise une combinaison de contraintes liées aux règles d'administration et de validation IaC (Infrastructure as Code) dans votre pipeline. Ces contrôles empêchent la création de ressources qui ne respectent pas les directives de vos règles. Appliquer ces contrôles dès le début de la conception et de la création de vos charges de travail vous permet d'éviter les tâches correctives ultérieurement.

Contraintes liées aux règles d'administration

Le service de règles d'administration applique des contraintes pour empêcher la création de certaines configurations de ressources dans votre organisation Google Cloud, même par une personne disposant d'un rôle IAM suffisant.

Le plan applique des stratégies au niveau du nœud d'organisation afin que ces contrôles soient hérités par tous les dossiers et projets de l'organisation. Ce groupe de règles est conçu pour empêcher certaines configurations à haut risque, telles que l'exposition d'une VM à l'Internet public ou l'octroi d'un accès public aux buckets de stockage, sauf si vous autorisez délibérément une exception à la règle.

Le tableau suivant présente les contraintes liées aux règles d'administration mises en œuvre dans le plan:

Contrainte liée aux règles d'administration	Description
compute.disableNestedVirtualization	La virtualisation imbriquée sur les VM Compute Engine peut échapper à la surveillance et à d'autres outils de sécurité de vos VM si elles sont mal configurées. Cette contrainte empêche la création de la virtualisation imbriquée.
compute.disableSerialPortAccess	Les rôles IAM tels que compute.instanceAdmin autorisent l'accès privilégié au port série d'une instance à l'aide de clés SSH. Si la clé SSH est exposée, un pirate informatique peut accéder au port série et contourner les contrôles de réseau et de pare-feu. Cette contrainte empêche l'accès au port série.
compute.disableVpcExternalIpv6	Les sous-réseaux IPv6 externes peuvent être exposés à un accès Internet non autorisé s'ils sont mal configurés. Cette contrainte empêche la création de sous-réseaux IPv6 externes.
compute.requireOsLogin	Le comportement par défaut des clés SSH dans les métadonnées peut autoriser un accès à distance non autorisé aux VM si des clés sont exposées. Cette contrainte applique l'utilisation de OS Login au lieu de clés SSH basées sur les métadonnées.
compute.restrictProtocolForwardingCreationForTypes	Le transfert de protocole de VM pour les adresses IP externes peut entraîner une sortie Internet non autorisée si le transfert est mal configuré. Cette contrainte n'autorise le transfert de protocole de VM que pour les adresses internes.
compute.restrictXpnProjectLienRemoval	La suppression d'un projet hôte VPC partagé peut perturber tous les projets de service qui utilisent des ressources de mise en réseau. Cette contrainte empêche la suppression accidentelle ou malveillante des projets hôtes VPC partagés en empêchant la suppression du privilège de projet sur ces projets.
compute.setNewProjectDefaultToZonalDNSOnly	Un ancien paramètre de DNS interne global (à l'échelle du projet) n'est pas recommandé, car il réduit la disponibilité du service. Cette contrainte empêche l'utilisation de l'ancien paramètre.
compute.skipDefaultNetworkCreation	Un réseau VPC par défaut et des règles de pare-feu VPC par défaut trop permissives sont créés dans chaque nouveau projet qui active l'API Compute Engine. Cette contrainte ignore la création du réseau par défaut et des règles de pare-feu VPC par défaut.
compute.vmExternalIpAccess	Par défaut, une VM est créée avec une adresse IPv4 externe pouvant entraîner un accès Internet non autorisé. Cette contrainte configure une liste d'autorisation d'adresses IP externes vide que la VM peut utiliser et refuse toutes les autres.
essentialcontacts.allowedContactDomains	Par défaut, les contacts essentiels peuvent être configurés pour envoyer des notifications sur votre domaine à n'importe quel autre domaine. Cette contrainte exige que seules les adresses e-mail des domaines approuvés soient définies comme destinataires des contacts essentiels.
iam.allowedPolicyMemberDomains	Par défaut, des stratégies d'autorisation peuvent être accordées à tout compte Google, y compris les comptes non gérés et les comptes appartenant à des organisations externes. Cette contrainte garantit que les stratégies d'autorisation de votre organisation ne peuvent être accordées qu'aux comptes gérés de votre propre domaine. Vous pouvez éventuellement autoriser des domaines supplémentaires.
iam.automaticIamGrantsForDefaultServiceAccounts	Par défaut, les comptes de service par défaut se voient automatiquement attribuer des rôles trop permissifs. Cette contrainte empêche les attributions automatiques de rôles IAM aux comptes de service par défaut.
iam.disableServiceAccountKeyCreation	Les clés de compte de service sont des identifiants persistants à haut risque. Dans la plupart des cas, une alternative plus sécurisée aux clés de compte de service peut être utilisée. Cette contrainte empêche la création de clés de compte de service.
iam.disableServiceAccountKeyUpload	L'importation du matériel de clé de compte de service peut augmenter le risque si celui-ci est exposé. Cette contrainte empêche l'importation de clés de compte de service.
sql.restrictAuthorizedNetworks	Les instances Cloud SQL peuvent être exposées à un accès Internet non authentifié si elles sont configurées pour utiliser des réseaux autorisés sans proxy d'authentification Cloud SQL. Cette règle empêche la configuration des réseaux autorisés pour l'accès à la base de données, et force l'utilisation du proxy d'authentification Cloud SQL à la place.
sql.restrictPublicIp	Les instances Cloud SQL peuvent être exposées à un accès Internet non authentifié si elles sont créées avec des adresses IP publiques. Cette contrainte empêche les adresses IP publiques sur les instances Cloud SQL.
storage.uniformBucketLevelAccess	Par défaut, les objets dans Cloud Storage sont accessibles via les anciennes listes de contrôle d'accès (LCA) au lieu d'IAM, ce qui peut entraîner des contrôles d'accès incohérents et une exposition accidentelle en cas de mauvaise configuration. L'accès aux anciennes LCA n'est pas affecté par la contrainte iam.allowedPolicyMemberDomains. Cette contrainte impose que l'accès ne peut être configuré que via l'accès uniforme au niveau du bucket, et non via les anciennes LCA.
storage.publicAccessPrevention	Les buckets Cloud Storage peuvent être exposés à un accès Internet non authentifié s'ils sont mal configurés. Cette contrainte empêche les LCA et les autorisations IAM d'accorder l'accès à allUsers et à allAuthenticatedUsers.

Ces règles constituent un point de départ que nous recommandons pour la plupart des clients et dans la plupart des scénarios, mais vous devrez peut-être modifier les contraintes de règle d'administration pour les adapter à certains types de charges de travail. Par exemple, une charge de travail qui utilise un bucket Cloud Storage comme backend pour que Cloud CDN héberge des ressources publiques est bloquée par storage.publicAccessPrevention, ou une application Cloud Run publique qui ne requiert pas l'authentification est bloquée par iam.allowedPolicyMemberDomains. Dans ce cas, modifiez la règle d'administration au niveau du dossier ou du projet pour autoriser une exception étroite. Vous pouvez également ajouter des contraintes conditionnelles à la règle d'administration en définissant un tag qui accorde une exception ou une application de règle, puis en appliquant un tag à des projets et dossiers.

Pour découvrir d'autres contraintes, consultez les sections Contraintes disponibles et Contraintes personnalisées.

Validation avant le déploiement de l'infrastructure en tant que code

Le plan utilise une approche GitOps pour gérer l'infrastructure, ce qui signifie que toutes les modifications d'infrastructure sont mises en œuvre via une infrastructure en tant que code (IaC) contrôlée par version et peuvent être validées avant le déploiement.

Les règles appliquées dans le plan définissent les configurations de ressources acceptables pouvant être déployées par votre pipeline. Si le code envoyé à votre dépôt GitHub ne passe pas les vérifications de stratégie, aucune ressource n'est déployée.

Pour en savoir plus sur l'utilisation des pipelines et sur l'application des contrôles via l'automatisation CI/CD, consultez la page Méthodologie de déploiement.

Étapes suivantes

• Découvrez la méthodologie de déploiement (document suivant de cette série)

Méthodologie de déploiement

Nous vous recommandons d'utiliser une infrastructure déclarative pour déployer vos fondations de manière cohérente et contrôlable. Cette approche permet d'assurer une gouvernance cohérente en appliquant des contrôles de stratégie concernant les configurations de ressources acceptables dans vos pipelines. Le plan est déployé à l'aide d'un flux GitOps, avec Terraform utilisé pour définir une Infrastructure as Code (IaC), un dépôt Git pour le contrôle et l'approbation des versions du code, et Cloud Build pour l'automatisation CI/CD dans le pipeline de déploiement. Pour obtenir une présentation de ce concept, consultez la page Gérer une Infrastructure as Code avec Terraform, Cloud Build et GitOps.

Les sections suivantes décrivent comment le pipeline de déploiement est utilisé pour gérer les ressources de votre organisation.

Couches de pipeline

Pour séparer les équipes et la pile technologique chargée de gérer différentes couches de votre environnement, nous vous recommandons un modèle utilisant différents pipelines et différents personas responsables de chaque couche de la pile.

Le schéma suivant présente notre modèle recommandé pour séparer un pipeline de base, un pipeline d'infrastructure et un pipeline d'application.

Le schéma présente les couches de pipeline dans ce modèle:

• Le pipeline de base déploie les ressources de base utilisées sur la plate-forme. Nous recommandons à une seule équipe centrale de gérer les ressources de base utilisées par plusieurs unités commerciales et charges de travail.
• Le pipeline d'infrastructure déploie les projets et l'infrastructure utilisés par les charges de travail, telles que les instances ou VM de bases de données. Le plan configure un pipeline d'infrastructure distinct pour chaque unité commerciale, ou vous pouvez préférer un seul pipeline d'infrastructure utilisé par plusieurs équipes.
• Le pipeline d'applications déploie les artefacts pour chaque charge de travail, tels que les conteneurs ou les images. Vous pouvez avoir de nombreuses équipes d'applications avec des pipelines d'application individuels.

Les sections suivantes présentent l'utilisation de chaque couche de pipeline.

Le pipeline de base

Le pipeline de base déploie les ressources de base. Il configure également le pipeline d'infrastructure utilisé pour déployer l'infrastructure utilisée par les charges de travail.

Pour créer le pipeline de base, vous devez d'abord cloner ou dupliquer terraform-example-foundation dans votre propre dépôt Git. Suivez les étapes du fichier README de 0-bootstrap pour configurer votre dossier et vos ressources d'amorçage.

Étape

Description

0-bootstrap

Amorçage d'une organisation Google Cloud Cette étape configure également un pipeline CI/CD pour le code du plan lors des étapes suivantes. Le projet CICD contient le pipeline de base Cloud Build pour le déploiement de ressources. Le projet seed inclut les buckets Cloud Storage contenant l'état Terraform de l'infrastructure de base et inclut des comptes de service à privilèges élevés utilisés par le pipeline de base pour créer des ressources. L'état Terraform est protégé via la gestion des versions d'objets de stockage. Lorsque le pipeline CI/CD s'exécute, il agit en tant que comptes de service gérés dans le projet seed.

Une fois que vous avez créé le pipeline de base à l'étape 0-bootstrap, les étapes suivantes déploient des ressources sur le pipeline de base. Consultez les instructions de fichier README pour chaque étape et mettez en œuvre chaque étape de manière séquentielle.

Étape	Description
1-org	Configure les dossiers partagés de premier niveau, les projets pour les services partagés, la journalisation au niveau de l'organisation et les paramètres de sécurité de base via des règles d'administration.
2-environments	Configure les environnements de développement, hors production et de production au sein de l'organisation Google Cloud que vous avez créée.
3-networks-dual-svpc ou 3-networks-hub-and-spoke	Configure les VPC partagés dans la topologie choisie et les ressources réseau associées.

Pipeline d'infrastructure

Le pipeline d'infrastructure déploie les projets et l'infrastructure (par exemple, les instances de VM et les bases de données) utilisées par les charges de travail. Le pipeline de base déploie plusieurs pipelines d'infrastructure. Cette séparation entre le pipeline de base et le pipeline d'infrastructure permet de séparer les ressources à l'échelle de la plate-forme des ressources spécifiques à la charge de travail.

Le schéma suivant montre comment le plan configure plusieurs pipelines d'infrastructure destinés à être utilisés par des équipes distinctes.

Le schéma décrit les concepts clés suivants:

• Chaque pipeline d'infrastructure permet de gérer les ressources d'infrastructure indépendamment des ressources de base.
• Chaque unité commerciale dispose de son propre pipeline d'infrastructure, géré dans un projet dédié du dossier common.
• Chacun des pipelines d'infrastructure dispose d'un compte de service autorisé à déployer des ressources uniquement sur les projets associés à cette unité commerciale. Cette stratégie crée une séparation des tâches entre les comptes de services privilégiés utilisés pour le pipeline de base et ceux utilisés par chaque pipeline d'infrastructure.

Cette approche comportant plusieurs pipelines d'infrastructure est recommandée lorsque vous disposez de plusieurs entités au sein de votre organisation qui ont les compétences et l'intérêt pour gérer leur infrastructure séparément, en particulier si elles ont des exigences différentes, telles que les types de stratégie de validation du pipeline qu'elles souhaitent appliquer. Vous pouvez également avoir un seul pipeline d'infrastructure géré par une seule équipe avec des règles de validation cohérentes.

Dans la section terraform-example-Foundation, l'étape 4 configure un pipeline d'infrastructure et l'étape 5 illustre un exemple d'utilisation de ce pipeline pour déployer des ressources d'infrastructure.

Étape	Description
4-projects	Configure une structure de dossiers, des projets et un pipeline d'infrastructure.
5-app-infra (Facultatif)	Déploie des projets de charge de travail avec une instance Compute Engine en utilisant le pipeline d'infrastructure comme exemple.

Pipeline de l'application

Le pipeline d'application est responsable du déploiement des artefacts d'application pour chaque charge de travail individuelle, comme les images ou les conteneurs Kubernetes qui exécutent la logique métier de votre application. Ces artefacts sont déployés sur les ressources d'infrastructure déployées par votre pipeline d'infrastructure.

Le plan d'entreprise de base configure votre pipeline de base et votre pipeline d'infrastructure, mais ne déploie pas de pipeline d'application. Pour obtenir un exemple de pipeline d'application, consultez le plan d'application d'entreprise.

Automatiser votre pipeline avec Cloud Build

Le plan utilise Cloud Build pour automatiser les processus CI/CD. Le tableau suivant décrit les contrôles intégrés au pipeline de base et au pipeline d'infrastructure déployés par le dépôt terraform-example-Foundation. Si vous développez vos propres pipelines à l'aide d'autres outils d'automatisation CI/CD, nous vous recommandons d'appliquer des contrôles similaires.

Contrôle	Description
Séparer les configurations de compilation pour valider le code avant le déploiement	Le plan utilise deux fichiers de configuration de compilation Cloud Build pour l'ensemble du pipeline, et chaque dépôt associé à une étape comporte deux déclencheurs Cloud Build qui sont associés à ces fichiers de configuration de compilation. Lorsque du code est transféré vers une branche de dépôt, les fichiers de configuration de compilation sont déclenchés pour d'abord exécuter la commande cloudbuild-tf-plan.yaml, ce qui valide votre code à l'aide de vérifications des stratégies et de la planification Terraform par rapport à cette branche, puis cloudbuild-tf-apply.yaml exécute terraform apply sur le résultat de ce plan.
Vérifications des règles Terraform	Le plan inclut un ensemble de contraintes Open Policy Agent appliquées par la validation de stratégie dans Google Cloud CLI. Ces contraintes définissent les configurations de ressources acceptables pouvant être déployées par le pipeline. Si une compilation ne répond pas aux règles de la première configuration de compilation, alors la deuxième configuration de compilation ne déploie aucune ressource. Les règles appliquées dans le plan sont dupliquées à partir de GoogleCloudPlatform/policy-library sur GitHub. Vous pouvez écrire des règles supplémentaires pour la bibliothèque afin d'appliquer des règles personnalisées qui répondent à vos besoins.
Principe du moindre privilège	Le pipeline de base possède un compte de service différent pour chaque étape avec une stratégie d'autorisation qui n'accorde que les rôles IAM minimaux pour cette étape. Chaque déclencheur Cloud Build s'exécute en tant que compte de service spécifique pour cette étape. L'utilisation de comptes différents permet de limiter le risque que la modification d'un dépôt puisse affecter les ressources gérées par un autre dépôt. Pour comprendre les rôles IAM spécifiques appliqués à chaque compte de service, consultez le code Terraform sa.tf lors de l'étape d'amorçage.
Pools privés Cloud Build	Le plan utilise des pools privés Cloud Build. Les pools privés vous permettent éventuellement d'appliquer des contrôles supplémentaires, tels que la restriction d'accès aux dépôts publics ou l'exécution de Cloud Build dans un périmètre VPC Service Controls.
Compilateurs personnalisés Cloud Build	Le plan crée son propre compilateur personnalisé pour exécuter Terraform. Pour en savoir plus, consultez 0-bootstrap/Dockerfile. Ce contrôle impose que le pipeline s'exécute de manière cohérente avec un ensemble connu de bibliothèques aux versions épinglées.
Approbation de déploiement	Vous pouvez éventuellement ajouter une étape d'approbation manuelle à Cloud Build. Cette approbation ajoute un point de contrôle supplémentaire après le déclenchement de la compilation, mais avant son exécution, afin qu'un utilisateur privilégié puisse l'approuver manuellement.

Stratégie d'embranchement

Nous recommandons la stratégie d'une branche persistante pour envoyer du code à votre système Git et déployer des ressources via le pipeline de base. Le schéma suivant décrit la stratégie de branche persistante.

Le schéma décrit trois branches persistantes dans Git (développement, hors production et production) qui reflètent les environnements Google Cloud correspondants. Il existe également plusieurs branches de fonctionnalités éphémères qui ne correspondent pas aux ressources déployées dans vos environnements Google Cloud.

Nous vous recommandons d'appliquer un processus de demande d'extraction (pull request, PR) dans votre système Git afin que tout code fusionné dans une branche persistante soit associé à une demande d'extraction approuvée.

Pour développer du code avec cette stratégie de branche persistante, suivez les principales étapes suivantes :

1. Lorsque vous développez de nouvelles fonctionnalités ou travaillez sur une correction de bug, créez une branche basée sur la branche de développement. Utilisez une convention d'attribution de noms pour votre branche, qui inclut le type de modification, un numéro de ticket ou un autre identifiant, ainsi qu'une description lisible, telle que feature/123456-org-policies.
2. Lorsque vous terminez le travail dans la branche de fonctionnalité, ouvrez une demande d'extraction qui cible la branche de développement.
3. Lorsque vous envoyez la demande d'extraction, celle-ci déclenche le pipeline de base pour effectuer terraform plan et terraform validate afin de préparer et de vérifier les modifications.
4. Après avoir validé les modifications apportées au code, fusionnez la fonctionnalité ou la correction de bug dans la branche de développement.
5. Le processus de fusion déclenche le pipeline de base pour exécuter terraform apply afin de déployer les dernières modifications de la branche de développement dans l'environnement de développement.
6. Examinez les modifications apportées à l'environnement de développement à l'aide d'examens manuels, de tests fonctionnels ou de tests de bout en bout pertinents pour votre cas d'utilisation. Faites ensuite la promotion des modifications dans l'environnement hors production en ouvrant une demande d'extraction qui cible la branche hors production et en fusionnant vos modifications.
7. Pour déployer des ressources dans l'environnement de production, répétez le même processus que pour l'étape 6 : examinez et validez les ressources déployées, ouvrez une demande d'extraction sur la branche de production et fusionnez.

Étapes suivantes

• Découvrez les bonnes pratiques relatives aux opérations (document suivant de cette série).

Bonnes pratiques en matière d'opérations

Cette section présente les opérations que vous devez prendre en compte lorsque vous déployez et exploitez des charges de travail supplémentaires dans votre environnement Google Cloud. Cette section n'est pas censée être exhaustive de toutes les opérations de votre environnement cloud, mais présente des décisions liées aux recommandations et aux ressources architecturales déployées par le plan.

Mettre à jour des ressources de base

Bien que le plan constitue un point de départ avisé pour votre environnement de base, vos exigences de base peuvent augmenter au fil du temps. Après le déploiement initial, vous pouvez ajuster les paramètres de configuration ou créer des services partagés qui seront utilisés par toutes les charges de travail.

Pour modifier les ressources de base, nous vous recommandons d'effectuer toutes les modifications via le pipeline de base. Consultez la page Stratégie d'embranchement pour découvrir le processus d'écriture de code, de fusion et de déclenchement des pipelines de déploiement.

Choisir les attributs des nouveaux projets de charge de travail

Lorsque vous créez des projets via le module de fabrique de projets du pipeline d'automatisation, vous devez configurer divers attributs. Votre processus de conception et de création de projets pour les nouvelles charges de travail doit inclure les décisions suivantes:

• Les API Google Cloud à activer
• Le VPC partagé à utiliser ou s'il faut créer un réseau VPC
• Les rôles IAM à créer pour le project-service-account initial créé par le pipeline
• Les libellés de projet à appliquer
• Le dossier dans lequel le projet est déployé
• Le compte de facturation à utiliser
• L'ajout ou non du projet à un périmètre VPC Service Controls
• Décider s'il faut configurer un budget et un seuil d'alerte de facturation pour le projet

Pour obtenir une documentation de référence complète sur les attributs configurables pour chaque projet, consultez les variables d'entrée pour la fabrique de projets dans le pipeline d'automatisation.

Gérez les autorisations à grande échelle

Lorsque vous déployez des projets de charge de travail sur votre base, vous devez réfléchir à la manière dont vous accorderez l'accès aux développeurs et aux consommateurs prévus de ces projets. Nous vous recommandons d'ajouter des utilisateurs à un groupe géré par votre fournisseur d'identité existant, de synchroniser les groupes avec Cloud Identity, puis d'appliquer des rôles IAM aux groupes. Gardez toujours à l'esprit le principe du moindre privilège.

Nous vous recommandons également d'utiliser l'outil de recommandation IAM pour identifier les stratégies d'autorisation qui accordent des rôles possédant trop de privilèges. Concevez un processus pour examiner régulièrement les recommandations ou appliquer automatiquement des recommandations dans vos pipelines de déploiement.

Coordonner les modifications entre l'équipe de mise en réseau et l'équipe de développement

Les topologies de réseaux déployées par le plan supposent que vous avez une équipe responsable de la gestion des ressources réseau et des équipes distinctes responsables du déploiement des ressources d'infrastructure de charge de travail. Lorsque les équipes de charge de travail déploient une infrastructure, elles doivent créer des règles de pare-feu pour autoriser les chemins d'accès prévus entre les composants de leur charge de travail, mais elles ne sont pas autorisées à modifier les stratégies de pare-feu réseau elles-mêmes.

Planifiez la collaboration entre les équipes pour coordonner les modifications apportées aux ressources de mise en réseau centralisées nécessaires au déploiement des applications. Par exemple, vous pouvez concevoir un processus dans lequel une équipe de charge de travail demande des tags pour ses applications. L'équipe de mise en réseau crée ensuite les tags et ajoute des règles à la stratégie de pare-feu réseau qui permet le trafic entre les ressources avec les tags, et délègue les rôles IAM pour utiliser les tags à l'équipe de la charge de travail.

Optimisez votre environnement avec le portefeuille Active Assist

En plus de l'outil de recommandation IAM, Google Cloud fournit le portefeuille de services Active Assist pour émettre des recommandations sur la façon d'optimiser votre environnement. Par exemple, les insights sur le pare-feu ou l'outil de recommandation de projets dormants fournissent des recommandations exploitables pour renforcer votre stratégie de sécurité.

Concevez un processus permettant d'examiner régulièrement les recommandations ou d'appliquer automatiquement celles-ci dans vos pipelines de déploiement. Décidez quelles recommandations doivent être gérées par une équipe centrale et quelles sont les responsabilités des propriétaires de charge de travail, et appliquez les rôles IAM pour accéder aux recommandations en conséquence.

Accorder des exceptions aux règles d'administration

Le plan applique un ensemble de contraintes de règle d'administration qui sont recommandées à la plupart des clients dans la plupart des scénarios, mais des cas d'utilisation légitimes peuvent nécessiter des exceptions limitées aux règles d'administration que vous appliquez.

Par exemple, le plan applique la contrainte iam.disableServiceAccountKeyCreation. Cette contrainte est un contrôle de sécurité important, car une fuite de clé de compte de service peut avoir un impact négatif important et la plupart des scénarios doivent utiliser des alternatives plus sécurisées aux clés de compte de service pour s'authentifier. Toutefois, certains cas d'utilisation ne peuvent s'authentifier qu'avec une clé de compte de service, comme un serveur sur site qui nécessite l'accès aux services Google Cloud et ne peut pas utiliser la fédération d'identité de charge de travail. Dans ce scénario, vous pouvez décider d'autoriser une exception à cette règle, à condition que d'autres contrôles compensatoires, tels que les bonnes pratiques de gestion des clés de compte de service, soient appliqués.

Par conséquent, vous devez concevoir un processus permettant aux charges de travail de demander une exception aux règles, et vous assurer que les décideurs chargés de l'octroi des exceptions ont les connaissances techniques nécessaires pour valider le cas d'utilisation et consulter si des contrôles supplémentaires doivent être en place pour compenser cette situation. Lorsque vous accordez une exception à une charge de travail, modifiez la contrainte de règle d'administration de manière aussi restrictive que possible. Vous pouvez également ajouter des contraintes conditionnelles à une règle d'administration en définissant un tag qui accorde une exception ou une mesure d'application pour la règle, puis en l'appliquant aux projets et aux dossiers.

Protéger vos ressources avec VPC Service Controls

Le plan permet de préparer votre environnement pour VPC Service Controls en séparant les réseaux de base et restreints. Toutefois, le code Terraform n'active pas VPC Service Controls par défaut, car cette activation peut être un processus perturbateur.

Un périmètre refuse l'accès aux services Google Cloud restreints depuis le trafic provenant de l'extérieur du périmètre, y compris la console, les stations de travail des développeurs et le pipeline de base utilisé pour déployer les ressources. Si vous utilisez VPC Service Controls, vous devez concevoir des exceptions au périmètre qui autorisent les chemins d'accès souhaités.

Un périmètre VPC Service Controls est destiné aux contrôles d'exfiltration entre votre organisation Google Cloud et des sources externes. Le périmètre n'est pas destiné à remplacer ou à dupliquer des stratégies d'autorisation pour un contrôle d'accès précis à des projets ou à des ressources individuels. Lorsque vous concevez un périmètre et mettez en œuvre son architecture, nous vous recommandons d'utiliser un périmètre unifié commun pour réduire les coûts de gestion.

Si vous devez concevoir plusieurs périmètres pour contrôler le trafic de service de manière précise au sein de votre organisation Google Cloud, nous vous recommandons de définir clairement les menaces traitées par une structure de périmètre plus complexe et les chemins d'accès entre périmètres qui sont nécessaires pour les opérations prévues.

Pour adopter VPC Service Controls, évaluez les éléments suivants:

• Quels sont les cas d'utilisation nécessitant VPC Service Controls.

• Si les services Google Cloud requis sont compatibles avec VPC Service Controls.

• Comment configurer l'accès "bris de glace" pour modifier le périmètre en cas de perturbation de vos pipelines d'automatisation.

• Comment utiliser les bonnes pratiques pour activer VPC Service Controls afin de concevoir et de mettre en œuvre votre périmètre.

Une fois le périmètre activé, nous vous recommandons de concevoir un processus pour ajouter de nouveaux projets de manière cohérente au périmètre approprié, et un processus de conception d'exceptions lorsque les développeurs reçoivent un nouveau cas d'utilisation refusé par votre configuration du périmètre actuelle.

Tester les modifications à l'échelle de l'organisation dans une organisation distincte

Nous vous recommandons de ne jamais déployer de modifications en production sans tester. Pour les ressources de charge de travail, cette approche est facilitée par des environnements distincts pour le développement, hors production et la production. Cependant, certaines ressources de l'organisation ne disposent pas d'environnements distincts pour faciliter les tests.

Pour les modifications au niveau de l'organisation ou pour d'autres modifications susceptibles d'affecter les environnements de production, telles que la configuration entre votre fournisseur d'identité et Cloud Identity, envisagez de créer une organisation distincte à des fins de test.

Contrôler l'accès à distance aux machines virtuelles

Comme nous vous recommandons de déployer une infrastructure immuable via le pipeline de base, le pipeline d'infrastructure et le pipeline d'application, nous vous recommandons également de n'accorder aux développeurs que l'accès direct à une machine virtuelle via SSH ou RDP pour dans des cas d'utilisation exceptionnels.

Pour les scénarios nécessitant un accès à distance, nous vous recommandons de gérer l'accès des utilisateurs à l'aide de OS Login lorsque cela est possible. Cette approche utilise les services Google Cloud gérés pour appliquer le contrôle des accès, la gestion du cycle de vie du compte, la validation en deux étapes et la journalisation d'audit. Si vous devez autoriser l'accès via des clés SSH dans les métadonnées ou des identifiants RDP, vous devez gérer le cycle de vie des identifiants et stocker les identifiants de manière sécurisée en dehors de Google Cloud.

Dans tous les cas, un utilisateur disposant d'un accès SSH ou RDP à une VM peut présenter un risque d'élévation des privilèges. Vous devez donc concevoir votre modèle d'accès en conséquence. L'utilisateur peut exécuter du code sur cette VM avec les privilèges du compte de service associé ou interroger le serveur de métadonnées pour afficher le jeton d'accès utilisé pour authentifier les requêtes API. Il peut alors s'agir d'une élévation de privilèges si vous ne souhaitez pas que l'utilisateur utilise les droits du compte de service.

Limiter les dépassements de budget en planifiant des alertes budgétaires

Le plan met en œuvre les bonnes pratiques introduites dans le framework d'architecture Google Cloud: optimisation des coûts pour la gestion des coûts, y compris les éléments suivants :

• Utilisez un seul compte de facturation pour tous les projets de base de l'entreprise.

• Attribuez à chaque projet un libellé de métadonnées billingcode permettant d'allouer les coûts entre les centres de coûts.

• Définissez des budgets et des seuils d'alerte.

Il vous incombe de planifier les budgets et de configurer les alertes de facturation. Le plan crée des alertes de budget pour les projets de charge de travail lorsque les dépenses prévues sont sur le point d'atteindre 120% du budget. Cette approche permet à une équipe centrale d'identifier et de limiter les incidents de dépenses excessives importantes. Les augmentations inattendues et importantes des dépenses sans cause claire peuvent être un indicateur d'un incident de sécurité et doivent être examinées du point de vue du contrôle des coûts et de la sécurité.

Au lieu d'utiliser des budgets précis pour chaque projet, vous pouvez définir un budget basé sur le coût d'un dossier dans son ensemble ou pour tous les projets liés à un centre de coûts donné en fonction de votre cas de figure. Nous vous recommandons également de déléguer le paramètre de budget et d'alerte aux propriétaires de charge de travail qui peuvent définir un seuil d'alerte plus précis pour leur surveillance quotidienne.

Pour obtenir des conseils sur la création de fonctionnalités FinOps, y compris sur la prévision des budgets pour les charges de travail, consultez la page Premiers pas avec FinOps sur Google Cloud.

Allouer des coûts entre les centres de coûts internes

La console vous permet d'afficher vos rapports de facturation afin d'afficher et de prévoir les coûts dans plusieurs dimensions. En plus des rapports prédéfinis, nous vous recommandons d'exporter les données de facturation vers un ensemble de données BigQuery du projet prj-c-billing-logs. Les enregistrements de facturation exportés vous permettent d'allouer des coûts sur des dimensions personnalisées, telles que vos centres de coûts internes, en fonction de métadonnées de libellé de projet telles que billingcode.

La requête SQL suivante est un exemple de requête permettant de comprendre les coûts de tous les projets regroupés par libellé de projet billingcode.

#standardSQL
SELECT
   (SELECT value from UNNEST(labels) where key = 'billingcode') AS costcenter,
   service.description AS description,
   SUM(cost) AS charges,
   SUM((SELECT SUM(amount) FROM UNNEST(credits))) AS credits
FROM PROJECT_ID.DATASET_ID.TABLE_NAME
GROUP BY costcenter, description
ORDER BY costcenter ASC, description ASC

Pour configurer cette exportation, consultez la page Exporter des données Cloud Billing vers BigQuery.

Si vous avez besoin d'une comptabilité interne ou d'un rejet de débit entre les centres de coûts, il vous incombe d'intégrer les données obtenues à partir de cette requête dans vos processus internes.

Ingérer les résultats des contrôles de détection dans votre solution SIEM existante

Bien que les ressources de base vous aident à configurer des destinations agrégées pour les journaux d'audit et les résultats de sécurité, il vous incombe de décider comment utiliser et utiliser ces signaux.

Si vous devez agréger des journaux dans tous les environnements cloud et sur site dans une solution SIEM existante, décidez comment ingérer les journaux à partir duprj-c-logging projet et les résultats de Security Command Center dans vos outils et processus existants. Vous pouvez créer une seule exportation pour tous les journaux et résultats si une seule équipe est chargée de surveiller la sécurité dans l'ensemble de votre environnement, ou vous pouvez créer plusieurs exportations filtrées en fonction de l'ensemble de journaux et de résultats nécessaire pour plusieurs équipes avec des responsabilités différentes.

Par ailleurs, si le volume et les coûts des journaux sont rédhibitoires, vous pouvez éviter la duplication en ne conservant les journaux et les résultats Google Cloud que dans Google Cloud. Dans ce scénario, assurez-vous que vos équipes existantes disposent d'un accès et d'une formation appropriés pour travailler avec les journaux et les résultats directement dans Google Cloud.

• Pour les journaux d'audit, concevez des vues de journaux pour accorder l'accès à un sous-ensemble de journaux de votre bucket de journaux centralisé à des équipes individuelles, plutôt que de les dupliquer dans plusieurs buckets, ce qui augmente les coûts de stockage des journaux.
• Pour les résultats de sécurité, attribuez des rôles au niveau du dossier et du projet pour Security Command Center afin de permettre aux équipes d'afficher et de gérer les résultats de sécurité uniquement pour les projets dont elles sont responsables, directement dans la console

Développer votre bibliothèque de contrôles en continu

Le plan commence par un contrôle des détections et des menaces. Nous vous recommandons de vérifier ces contrôles et d'ajouter des contrôles supplémentaires en fonction de vos besoins. Le tableau suivant récapitule les mécanismes d'application des règles de gouvernance et comment les étendre à vos exigences supplémentaires:

Contrôles de règles appliqués par le plan	Conseils pour étendre ces contrôles
Security Command Center détecte les failles et les menaces provenant de plusieurs sources de sécurité.	Définissez des modules personnalisés pour Security Health Analytics et des modules personnalisés pour Event Threat Detection.
Le service de règles d'administration applique un ensemble recommandé de contraintes liées aux règles d'administration sur les services Google Cloud.	Appliquez des contraintes supplémentaires à partir de la liste prédéfinie de contraintes disponibles ou créez des contraintes personnalisées.
La règle Open Policy Agent (OPA) valide le code dans le pipeline de base pour les configurations acceptables avant le déploiement.	Développez d'autres contraintes basées sur les instructions fournies dans GoogleCloudPlatform/policy-library.
Les alertes sur les métriques basées sur les journaux et les métriques de performances configurent les métriques basées sur les journaux pour être averti des modifications apportées aux stratégies et configurations IAM de certaines ressources sensibles.	Concevez des règles pour les métriques basées sur les journaux et des règles d'alerte supplémentaires pour les événements de journaux qui ne devraient pas se produire dans votre environnement.
Une solution personnalisée pour l'analyse automatisée des journaux interroge régulièrement les journaux à la recherche d'activité suspecte et crée des résultats dans Security Command Center.	Rédigez des requêtes supplémentaires pour créer des résultats pour les événements de sécurité que vous souhaitez surveiller, en utilisant l'analyse des journaux de sécurité comme référence.
Une solution personnalisée pour répondre aux modifications d'éléments crée des résultats dans Security Command Center et peut automatiser les actions correctives.	Créer des flux d'inventaire des éléments cloud supplémentaires pour surveiller les modifications apportées à des types d'éléments spécifiques et écrire des fonctions Cloud supplémentaires avec une logique personnalisée pour répondre aux cas de non-respect des règles.

Ces contrôles peuvent évoluer à mesure que vos exigences et votre maturité sur Google Cloud évoluent.

Gérer des clés de chiffrement avec Cloud Key Management Service

Google Cloud fournit un chiffrement au repos par défaut pour tout le contenu client, mais fournit également Cloud Key Management Service (Cloud KMS) pour vous fournir des contrôles supplémentaires sur vos clés de chiffrement pour les données au repos. Nous vous recommandons de déterminer si le chiffrement par défaut est suffisant, ou si vous devez gérer vous-même les clés à l'aide de Cloud KMS. Pour en savoir plus, consultez la section Décider comment répondre aux exigences de conformité concernant le chiffrement au repos.

Le plan fournit un projet prj-c-kms dans le dossier commun et un projet prj-{env}-kms dans chaque dossier d'environnement pour la gestion centralisée des clés de chiffrement. Cette approche permet à une équipe centrale d'auditer et de gérer les clés de chiffrement utilisées par les ressources des projets de charge de travail, afin de répondre aux exigences réglementaires et de conformité.

Selon votre modèle opérationnel, vous pouvez préférer une seule instance de projet centralisée de Cloud KMS sous le contrôle d'une seule équipe, vous préférez peut-être gérer les clés de chiffrement séparément dans chaque environnement ou choisir plusieurs instances distribuées afin que la responsabilité des clés de chiffrement puisse être déléguée aux équipes appropriées. Modifiez l'exemple de code Terraform si nécessaire pour l'adapter à votre modèle opérationnel.

Vous pouvez éventuellement appliquer des règles d'administration des clés de chiffrement gérées par le client (CMEK) pour exiger que certains types de ressources nécessitent toujours une clé CMEK et que seules les clés CMEK provenant d'une liste d'autorisation de projets approuvés puissent être utilisées.

Stocker et auditer les identifiants de l'application avec Secret Manager

Nous vous recommandons de ne jamais procéder au commit de secrets sensibles (clés API, mots de passe et certificats privés, par exemple) dans les dépôts de code source. À la place, procédez au commit du secret à l'aide de Secret Manager et attribuez le rôle IAM Accesseur de secrets Secret Manager à l'utilisateur ou au compte de service qui doit accéder au secret. Nous vous recommandons d'attribuer le rôle IAM à un seul secret, et non à tous les secrets du projet.

Dans la mesure du possible, vous devez générer automatiquement des secrets de production dans les pipelines CI/CD et les rendre inaccessibles aux utilisateurs, sauf dans les situations de type "bris de glace". Dans ce scénario, veillez à ne pas accorder de rôles IAM pour afficher ces secrets à des utilisateurs ou à des groupes.

Le plan fournit un seul projet prj-c-secrets dans le dossier commun et un projet prj-{env}-secrets dans chaque dossier d'environnement pour la gestion centralisée des secrets. Cette approche permet à une équipe centrale d'auditer et de gérer les secrets utilisés par les applications afin de répondre aux exigences réglementaires et de conformité.

Selon votre modèle opérationnel, vous pouvez préférer une seule instance centralisée de Secret Manager sous le contrôle d'une seule équipe ou gérer les secrets séparément dans chaque environnement, ou vous pouvez préférer plusieurs instances distribuées de Secret Manager afin que chaque équipe de charge de travail puisse gérer ses propres secrets. Modifiez l'exemple de code Terraform si nécessaire pour l'adapter à votre modèle opérationnel.

Planifier l'accès "bris de glace" aux comptes à privilèges élevés

Bien que nous vous recommandions de gérer les modifications des ressources de base via un IaC contrôlé par une version et déployé par le pipeline de base, vous pouvez avoir des scénarios exceptionnels ou d'urgence nécessitant un accès privilégié pour modifier directement votre environnement. Nous vous recommandons de planifier des comptes de type "bris de glace" (parfois appelés comptes d'appel d'urgence ou comptes d'urgence) disposant d'un accès hautement privilégié à votre environnement en cas d'urgence ou de défaillance des processus d'automatisation.

Le tableau suivant décrit quelques exemples d'utilisation des comptes de type "bris de glace".

Objectif du "bris de glace"	Description
Super-administrateur	Accès d'urgence au rôle de super-administrateur utilisé avec Cloud Identity, par exemple pour résoudre les problèmes liés à la fédération d'identité ou à l'authentification multifacteur (MFA).
Administrateur de l'organisation	Accès d'urgence au rôle Administrateur de l'organisation, qui peut ensuite accorder l'accès à tout autre rôle IAM dans l'organisation.
Administrateur de pipeline de base	Accès d'urgence pour modifier les ressources de votre projet CICD sur Google Cloud et dans le dépôt Git externe en cas d'interruption de l'automatisation du pipeline de base.
Opérations ou SRE	Une équipe chargée des opérations ou de l'ingénierie SRE a besoin d'un accès privilégié pour répondre aux pannes ou aux incidents. Cela peut inclure des tâches telles que le redémarrage des VM ou la restauration de données.

Votre mécanisme pour autoriser le mode "bris de glace" dépend des outils et des procédures existants que vous avez mis en place, mais voici quelques exemples:

• Utilisez vos outils existants pour la gestion des accès privilégiés afin d'ajouter temporairement un utilisateur à un groupe prédéfini avec des rôles IAM à privilèges élevés ou utilisez les identifiants d'un compte à privilèges élevés.
• Préprovisionnez des comptes destinés uniquement à l'administrateur. Par exemple, le développeur Dana peut avoir l'identité [email protected] pour une utilisation quotidienne et [email protected] pour un accès en mode "bris de glace".
• Utilisez une application telle que l'accès privilégié avec le juste-à-temps, qui permet à un développeur de s'élever à des rôles plus privilégiés.

Quel que soit le mécanisme utilisé, réfléchissez à la manière dont vous gérez les questions suivantes sur un plan opérationnel :

• Comment concevez-vous le champ d'application et la précision de l'accès en mode "bris de glace" ? Par exemple, vous pouvez concevoir un mécanisme de type "bris de glace" différent pour différentes unités commerciales afin de vous assurer qu'elles ne peuvent pas se perturber les unes les autres.
• Comment votre mécanisme empêche-t-il les abus ? Avez-vous besoin d'approbations ? Par exemple, vous pouvez avoir des opérations fractionnées où une personne détient les identifiants et une autre personne le jeton MFA.
• Comment auditez-vous des accès en mode "bris de glace" et créez-vous des alertes ? Par exemple, vous pouvez configurer un module Event Threat Detection personnalisé pour créer un résultat de sécurité lorsqu'un compte de type "bris de glace" prédéfini est utilisé.
• Comment supprimer l'accès "bris de glace" et reprendre les opérations normales une fois l'incident terminé ?

Pour les tâches d'élévation des privilèges courantes et le rollback des modifications, nous vous recommandons de concevoir des workflows automatisés permettant à un utilisateur d'effectuer l'opération sans nécessiter d'élévation de privilèges pour son identité utilisateur. Cette approche peut contribuer à réduire les erreurs humaines et à améliorer la sécurité.

Pour les systèmes nécessitant une intervention régulière, l'automatisation du correctif peut être la meilleure solution. Google encourage les clients à adopter une approche de production sans contact pour effectuer toutes les modifications de production à l'aide de l'automatisation, de proxys sécurisés ou du mode "bris de glace" audité. Google fournit des livres sur l'ingénierie SRE pour les clients qui souhaitent adopter l'approche SRE de Google.

Étapes suivantes

• Découvrez comment déployer le plan (document suivant de cette série).

Déployer le plan

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: Créez un compte Cloud Identity et validez la propriété du domaine. Demandez un compte de facturation avec paiement sur facture avec votre équipe commerciale Google Cloud ou créez un compte de facturation en libre-service. Applique les bonnes pratiques de sécurité concernant les comptes administrateur. Vérifiez et corrigez les problèmes liés aux comptes utilisateur personnels. Configurez votre fournisseur d'identité externe en tant que source fiable pour synchroniser les comptes utilisateur et l'authentification unique. Provisionnez les groupes pour le contrôle d'accès requis pour exécuter le plan. Déterminez la topologie du réseau que vous utiliserez. Déterminez l'outil de gestion du code source. Les instructions de Terraform-example-Foundation sont écrites dans un dépôt Git hébergé dans Cloud Source Repositories. Choisissez vos outils d'automatisation CI/CD. Terraform-example-foundation fournit différents ensembles d'instructions pour différents outils d'automatisation. Pour vous connecter à un environnement sur site existant, préparez les éléments suivants: Planifiez l'allocation d'adresses IP en fonction du nombre et de la taille des plages requises par le plan. Commandez vos connexions par interconnexion dédiée.
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 L'étape 0-bootstrap pour créer un pipeline de base. Si vous utilisez un compte de facturation en libre-service, vous devez demander un quota de projet supplémentaire avant de passer à l'étape suivante. L'étape 1-org pour configurer les ressources au niveau de l'organisation. Étape 2-environments pour créer des environnements. Étape 3-networks-dual-svpc or 3-networks-hub-and-spoke pour créer des ressources de mise en réseau dans votre topologie préférée. L'étape 4-projects pour créer un pipeline d'infrastructure. Également, étape 5-app-infra pour un exemple d'utilisation du pipeline d'infrastructure.
Étapes supplémentaires après le déploiement IaC	Après avoir déployé le code Terraform, procédez comme suit: Effectuez les modifications de la configuration sur site. Activer Security Command Center Premium. Exporter des données Cloud Billing vers BigQuery Souscrivez une formule Cloud Customer Care. Activez les journaux Access Transparency. Partager des données depuis Cloud Identity avec Google Cloud Appliquer les contrôles administratifs pour Cloud Identity qui ne sont pas automatisés par le déploiement IaC. Déterminez les contrôles administratifs supplémentaires pour les clients ayant des charges de travail sensibles adaptés à votre cas d'utilisation. Passez en revue les bonnes pratiques opérationnelles et planifiez la connexion de vos opérations et fonctionnalités existantes aux ressources de base.

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 : [email protected]
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 : [email protected]
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 inclut 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

• Mettez en œuvre le plan à l'aide de l'exemple de base Terraform sur GitHub.
• Découvrez les bonnes pratiques de conception avec le framework d'architecture de Google Cloud.

• Consultez la bibliothèque de plans pour accélérer la conception et la création de charges de travail professionnelles courantes, y compris:

  • Importer des données depuis Google Cloud dans un entrepôt de données BigQuery sécurisé

  • Importer des données depuis un réseau externe dans un entrepôt de données BigQuery sécurisé

  • Déployer une architecture sécurisée sans serveur à l'aide de Cloud Functions

  • Déployer une architecture sécurisée sans serveur à l'aide de Cloud Run

• Consultez les solutions associées pour effectuer un déploiement sur votre environnement de base.

• Pour accéder à un environnement de démonstration, contactez-nous à l'adresse [email protected].