Cette section décrit le processus que vous pouvez utiliser pour déployer le plan, ses conventions de nommage et les alternatives aux recommandations de plans.
Conclusion
Pour déployer votre propre base d'entreprise conformément aux bonnes pratiques et aux recommandations de ce plan, suivez les tâches de haut niveau décrites dans cette section. Le déploiement nécessite une combinaison d'étapes de configuration préalables, de déploiement automatisé via terraform-example-Foundation sur GitHub et d'étapes supplémentaires qui doivent être configurées manuellement après le fin du déploiement de base initial.
Processus | Étapes |
---|---|
Prérequis avant de déployer les ressources du pipeline de base |
Effectuez les étapes suivantes avant de déployer le pipeline de base:
Pour vous connecter à un environnement sur site existant, préparez les éléments suivants:
|
Procédure de déploiement de Terraform-example-Foundation depuis GitHub |
Suivez les instructions README de chaque étape pour déployer terraform-example-Foundation à partir de GitHub
|
Étapes supplémentaires après le déploiement IaC |
Après avoir déployé le code Terraform, procédez comme suit:
|
Contrôles d'administration supplémentaires pour les clients ayant des charges de travail sensibles
Google Cloud fournit des contrôles d'administration supplémentaires qui peuvent vous aider à répondre à vos exigences de sécurité et de conformité. Toutefois, certains contrôles entraînent des coûts supplémentaires ou des compromis opérationnels qui peuvent ne pas être adaptés à tous les clients. Ces contrôles nécessitent également des entrées personnalisées pour vos exigences spécifiques qui ne peuvent pas être entièrement automatisées dans le plan avec une valeur par défaut pour tous les clients.
Cette section présente les contrôles de sécurité que vous appliquez de manière centralisée à votre base. Cette section n'est pas exhaustive de tous les contrôles de sécurité que vous pouvez appliquer à des charges de travail spécifiques. Pour plus d'informations sur les produits et solutions de sécurité de Google, consultez le Centre des bonnes pratiques de sécurité dans Google Cloud.
Déterminez si les contrôles suivants sont adaptés à votre base en fonction de vos exigences de conformité, de votre intérêt pour les risques et de la sensibilité des données.
Contrôle | Description |
---|---|
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. |
|
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. |
|
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. |
|
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. |
|
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. |
|
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). |
|
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. |
|
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 |
Par exemple : |
ID du projet |
Par exemple : |
Réseau VPC |
Par exemple : |
Sous-réseau |
Par exemple : |
Stratégies de pare-feu |
Exemple :
|
Cloud Router |
Par exemple : |
Connexion Cloud Interconnect |
Par exemple : |
Rattachement de VLAN Cloud Interconnect |
Par exemple : |
Groupe |
Où Par exemple : |
Rôle personnalisé |
Où Par exemple : |
Compte de service |
Où :
Par exemple : |
Bucket de stockage |
Où :
Par exemple : |
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:
|
Structure des dossiers:le plan présente une structure de dossiers simple, avec des charges de travail divisées en dossiers |
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:
|
Règles d'administration:le plan applique toutes les contraintes de règle d'administration sur le nœud d'organisation. |
Vous pouvez avoir différentes règles de sécurité ou méthodes de travail pour différents secteurs de l'entreprise. Dans ce scénario, appliquez des contraintes de règle d'administration à un nœud inférieur de la hiérarchie des ressources. Consultez la liste complète des contraintes liées aux règles d'administration qui répondent à vos exigences. |
Outils de pipeline de déploiement:le plan utilise Cloud Build pour exécuter le pipeline d'automatisation. |
Vous pouvez préférer d'autres produits pour votre pipeline de déploiement, tels que Terraform Enterprise, les exécuteurs GitLab, GitHub Actions ou Jenkins.. Le plan comprend des instructions alternatives pour chaque produit. |
Dépôt de code pour le déploiement:le plan utilise Cloud Source Repositories comme dépôt Git privé géré. |
Utilisez le système de contrôle des versions que vous préférez pour gérer les dépôts de code, tels que GitLab, GitHub ou Bitbucket. Si vous utilisez un dépôt privé hébergé dans votre environnement sur site, configurez un chemin réseau privé entre votre dépôt et votre environnement Google Cloud. |
Fournisseur d'identité:le plan suppose qu'il dispose d'une identité Active Directory sur site et envoie des identités à Cloud Identity à l'aide de Google Cloud Directory Sync. |
Si vous utilisez déjà Google Workspace, vous pouvez utiliser les identités Google qui sont déjà gérées dans Google Workspace. Si vous ne disposez pas déjà d'un fournisseur d'identité, vous pouvez créer et gérer les identités des utilisateurs directement dans Cloud Identity. Si vous disposez d'un fournisseur d'identité existant, tel que Okta, Ping ou Azure Entra ID, vous pouvez gérer les comptes utilisateur de votre fournisseur d'identité existant et synchroniser avec Cloud Identity. Si vous avez des exigences de souveraineté ou de conformité des données qui vous empêchent d'utiliser Cloud Identity, et que vous n'avez pas besoin d'identités d'utilisateurs Google gérées pour d'autres services Google tels que Google Ads ou Google Marketing Platform, vous préférez peut-être la fédération des identités des employés. Dans ce scénario, soyez conscient des limites des services compatibles. |
Plusieurs régions:le plan déploie les ressources régionales dans deux régions Google Cloud différentes afin de faciliter la conception des charges de travail en tenant compte des exigences de haute disponibilité et de reprise après sinistre. |
Si vos utilisateurs finaux sont situés dans plus d'emplacements géographiques, vous pouvez configurer davantage de régions Google Cloud pour créer des ressources plus proches de l'utilisateur final avec une latence réduite. Si vous avez des contraintes de souveraineté des données ou que vos besoins en disponibilité peuvent être satisfaits dans une seule région, vous pouvez configurer une seule région Google Cloud. |
Allocation d'adresses IP:le plan fournit un ensemble de plages d'adresses IP. |
Vous devrez peut-être modifier les plages d'adresses IP spécifiques utilisées en fonction de la disponibilité des adresses IP dans votre environnement hybride existant. Si vous modifiez les plages d'adresses IP, utilisez le plan comme guide pour connaître le nombre et la taille des plages requises, et examinez les plages d'adresses IP valides pour Google Cloud. |
Mise en réseau hybride:le plan utilise l'interconnexion dédiée sur plusieurs sites physiques et régions Google Cloud pour une bande passante et une disponibilité maximales. |
En fonction de vos exigences en termes de coût, de bande passante et de fiabilité, vous pouvez configurer une interconnexion partenaire ou Cloud VPN à la place. Si vous devez commencer à déployer des ressources avec une connectivité privée avant de pouvoir terminer l'interconnexion dédiée, vous pouvez commencer avec Cloud VPN et passer à une interconnexion dédiée ultérieurement. Si vous ne disposez d'aucun environnement sur site, vous n'aurez peut-être pas besoin de mise en réseau hybride. |
Périmètre VPC Service Controls:le plan recommande un périmètre unique incluant tous les projets de service associés à un réseau VPC restreint. Les projets associés à un réseau VPC de base ne sont pas inclus dans le périmètre. |
Vous pouvez avoir un cas d'utilisation nécessitant plusieurs périmètres pour une organisation ou vous décider de ne pas utiliser VPC Service Controls. Pour en savoir plus, consultez la section Décider comment limiter l'exfiltration de données via les API Google. |
Secret Manager:le plan déploie un projet pour utiliser Secret Manager dans le dossier |
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 |
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 |
É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 security-foundations-blueprint-support@google.com.