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

Last reviewed 2023-08-06 UTC

Les architectures sans serveur vous permettent de développer des logiciels et des services sans avoir à provisionner ni à gérer des serveurs. Vous pouvez utiliser des architectures sans serveur pour créer des applications pour un large éventail de services.

Ce document fournit des conseils avisés aux ingénieurs DevOps, aux architectes de sécurité et aux développeurs d'applications afin d'aider à protéger les applications sans serveur qui utilisent les fonctions Cloud Run (2nd gen). Ce document fait partie d'un plan de sécurité comprenant les éléments suivants :

  • Un dépôt GitHub contenant un ensemble de configurations et de scripts Terraform.
  • Un guide des contrôles d'architecture, de conception et de sécurité que vous mettez en œuvre avec le plan (ce document).

Bien que vous puissiez déployer ce plan sans déployer le plan de base d'entreprise Google Cloud, ce document suppose que vous avez déjà configuré un ensemble fondamental de contrôles de sécurité, comme décrit dans le plan de sécurité de base de Google Cloud. L'architecture décrite dans ce document vous permet de disposer de contrôles supplémentaires sur votre infrastructure existante afin de protéger vos applications sans serveur.

Pour vous aider à définir les principaux contrôles de sécurité liés aux applications sans serveur, la Cloud Security Alliance (CSA) a établi et publié les 12 risques les plus critiques pour les applications sans serveur. Les contrôles de sécurité utilisés dans ce plan sont conçus pour répondre aux risques pertinents pour les différents cas d'utilisation décrits dans ce document.

Cas d'utilisation sans serveur

Ce plan est compatible avec les cas d'utilisation suivants :

Les différences entre les fonctions Cloud Run et Cloud Run incluent les suivantes :

  • Les fonctions Cloud Run sont déclenchées par des événements, tels que des modifications de données dans une base de données ou la réception d'un message d'un système de messagerie tel que Pub/Sub. Cloud Run est déclenché par des requêtes, telles que des requêtes HTTP.
  • Les fonctions Cloud Run sont limitées à un ensemble d'environnements d'exécution compatibles. Vous pouvez utiliser Cloud Run avec n'importe quel langage de programmation.
  • Les fonctions Cloud Run gèrent les conteneurs et l'infrastructure qui contrôle le serveur Web ou le langage de l'environnement d'exécution afin que vous puissiez vous concentrer sur votre code. Cloud Run vous offre la flexibilité nécessaire pour exécuter ces services vous-même afin de contrôler la configuration du conteneur.

Pour en savoir plus sur les différences entre Cloud Run et les fonctions Cloud Run, consultez la page Choisir une option de calcul Google Cloud.

Architecture

Ce plan utilise une architecture de VPC partagé, dans laquelle les fonctions Cloud Run sont déployées dans un projet de service et peut accéder aux ressources situées sur d'autres réseaux VPC.

Le schéma suivant illustre une architecture de haut niveau, décrite plus en détail dans les exemples d'architectures qui suivent ce schéma.

Architecture du plan sans serveur utilisant les fonctions Cloud Run.

L'architecture illustrée dans le schéma précédent utilise une combinaison des services et fonctionnalités Google Cloud suivants :

  • Les fonctions Cloud Run vous permettent d'exécuter des fonctions en tant que service (Functions as a Service) et gèrent l'infrastructure en votre nom. Par défaut, cette architecture déploie les fonctions Cloud Run avec une adresse IP interne uniquement, sans accès à l'Internet public.
  • L'événement déclencheur est l'événement qui déclenche les fonctions Cloud Run. Comme décrit plus en détail dans les exemples d'architectures, il peut s'agir d'un événement Cloud Storage, d'un intervalle planifié ou d'une modification dans BigQuery.
  • Artifact Registry stocke les conteneurs sources pour votre application de fonctions Cloud Run.
  • Le VPC partagé vous permet de connecter un connecteur d'accès au VPC sans serveur de votre projet de service au projet hôte. Vous déployez un réseau VPC partagé distinct pour chaque environnement (production, hors production et développement). Cette conception de réseau permet d'isoler les réseaux entre les différents environnements. Un réseau VPC partagé vous permet de gérer de manière centralisée les ressources réseau d'un réseau commun tout en déléguant des responsabilités administratives au projet de service.
  • Le connecteur d'accès au VPC sans serveur connecte votre application sans serveur à votre réseau VPC à l'aide de l'accès au VPC sans serveur. L'accès au VPC sans serveur permet de s'assurer que les requêtes de votre application sans serveur vers le réseau VPC ne sont pas exposées à Internet. L'accès au VPC sans serveur permet aux fonctions Cloud Run de communiquer avec d'autres services, systèmes de stockage et ressources compatibles avec VPC Service Controls.

    Vous pouvez configurer l'accès au VPC sans serveur dans le projet hôte de VPC partagé ou dans un projet de service. Par défaut, ce plan déploie l'accès au VPC sans serveur dans le projet hôte de VPC partagé afin de s'aligner sur le modèle de VPC partagé de centralisation des ressources de configuration réseau. Pour en savoir plus, consultez la section Comparaison des méthodes de configuration.

  • VPC Service Controls crée un périmètre de sécurité qui isole vos services et ressources de fonctions Cloud Run en configurant les autorisations, les contrôles d'accès et l'échange de données sécurisé. Ce périmètre est conçu pour isoler votre application et vos services gérés en configurant des contrôles d'accès et une surveillance supplémentaires, et en séparant votre gouvernance de Google Cloud de l'application. Votre gouvernance inclut la gestion des clés et la journalisation.

  • Le service consommateur est l'application sur laquelle les fonctions Cloud Run agissent. Le service consommateur peut être un serveur interne ou un autre service Google Cloud tel que Cloud SQL. Selon votre cas d'utilisation, ce service peut se trouver derrière Cloud Firewall nouvelle génération, dans un autre sous-réseau, dans le même projet de service que les fonctions Cloud Run, ou dans un autre projet de service.

  • Le proxy Web sécurisé est conçu pour sécuriser le trafic Web de sortie, si nécessaire. Il permet de créer des stratégies flexibles et précises basées sur les identités cloud et les applications Web. Ce plan utilise le proxy Web sécurisé pour des règles précises de contrôle des accès au trafic Web de sortie pendant la phase de compilation des fonctions Cloud Run. Le plan ajoute une liste d'URL autorisées à la règle de stratégie de sécurité de la passerelle.

  • Cloud NAT fournit une connexion sortante à Internet, si nécessaire. Cloud NAT est compatible avec la traduction d'adresse réseau source (SNAT) pour les ressources de calcul sans adresse IP publique. Les paquets de réponses entrants utilisent la traduction d'adresse réseau de destination (DNAT). Vous pouvez désactiver Cloud NAT si les fonctions Cloud Run ne nécessitent pas d'accès à Internet. Cloud NAT met en œuvre la règle de réseau de sortie associée au proxy Web sécurisé.

  • Cloud Key Management Service (Cloud KMS) stocke les clés de chiffrement gérées par le client (CMEK) utilisées par les services de ce plan, y compris votre application sans serveur, Artifact Registry et les fonctions Cloud Run.

  • Secret Manager stocke les secrets des fonctions Cloud Run. Le plan installe les secrets en tant que volume pour fournir un niveau de sécurité plus élevé que la transmission des secrets en tant que variables d'environnement.

  • Identity and Access Management (IAM) et Resource Manager permettent de restreindre l'accès et d'isoler des ressources. Les contrôles d'accès et la hiérarchie des ressources suivent le principe du moindre privilège.

  • Cloud Logging collecte tous les journaux des services Google Cloud pour le stockage et la récupération par vos outils d'analyse et d'investigation.

  • Cloud Monitoring collecte et stocke les informations et les métriques de performances des services Google Cloud.

Exemple d'architecture avec une application sans serveur utilisant Cloud Storage

Le schéma suivant montre comment exécuter une application sans serveur qui accède à un serveur interne lorsqu'un événement particulier se produit dans Cloud Storage.

Exemple d'architecture sans serveur avec Cloud Storage.

Outre les services décrits dans la section Architecture, cet exemple d'architecture utilise une combinaison des services et fonctionnalités Google Cloud suivants :

  • Cloud Storage émet un événement lorsqu'une ressource cloud, une application ou un utilisateur crée un objet Web sur un bucket.
  • Eventarc achemine les événements de différentes ressources. Eventarc chiffre les événements en transit et au repos.
  • Pub/Sub met en file d'attente les événements utilisés en tant qu'entrée et déclencheur pour les fonctions Cloud Run.
  • Les règles de pare-feu du cloud privé virtuel (VPC) contrôlent le flux de données dans le sous-réseau qui héberge vos ressources, tel qu'un serveur interne.
  • Le serveur interne s'exécute sur Compute Engine ou Google Kubernetes Engine et héberge votre application interne. Si vous déployez l'exemple de fonctions Cloud Run sécurisées avec un serveur interne, vous déployez un serveur Apache avec une page HTML Hello World. Cet exemple simule l'accès à une application interne qui exécute des VM ou des conteneurs.

Exemple d'architecture avec Cloud SQL

Le schéma suivant montre comment exécuter une application sans serveur qui accède à un service hébergé Cloud SQL à intervalles réguliers selon un calendrier défini dans Cloud Scheduler. Vous pouvez utiliser cette architecture lorsque vous devez collecter des journaux, agréger des données, etc.

Exemple d'architecture sans serveur avec Cloud SQL.

Outre les services décrits dans la section Architecture, cet exemple d'architecture utilise une combinaison des services et fonctionnalités Google Cloud suivants :

Exemple d'architecture avec un entrepôt de données BigQuery

Le schéma suivant montre comment exécuter une application sans serveur qui est déclenchée lorsqu'un événement se produit dans BigQuery (par exemple, des données sont ajoutées ou une table est créée).

Exemple d'architecture sans serveur avec BigQuery.

Outre les services décrits dans la section Architecture, cet exemple d'architecture utilise une combinaison des services et fonctionnalités Google Cloud suivants :

Structure organisationnelle

Resource Manager vous permet de regrouper les ressources de manière logique par projet, dossier et organisation.

Le schéma suivant montre une hiérarchie de ressources avec des dossiers qui représentent différents environnements, tels que les disques d'amorçage, de production, hors production (ou de test) et de développement. Cette hiérarchie de ressources est basée sur la hiérarchie décrite dans le plan de base d'entreprise. Vous déployez les projets que le plan spécifie dans les dossiers suivants : Common, Production, Non-production et Dev.

Structure organisationnelle du plan sans serveur.

Les sections suivantes décrivent plus en détail ce schéma.

Dossiers

Vous utilisez des dossiers pour isoler vos environnements de production et de gouvernance de vos environnements hors production et de test. Le tableau suivant décrit les dossiers du plan de base de l'entreprise utilisés par ce plan.

Dossier Description
Bootstrap Contient les ressources requises pour déployer le plan de base de l'entreprise.
Common Contient des services centralisés pour l'organisation, tels que le projet de sécurité.
Production Contient des projets dont les ressources cloud ont été testées et sont prêtes à être utilisées par les clients. Dans ce plan, le dossier Production contient le projet de service et le projet hôte.
Non-production Contient des projets comportant des ressources cloud en cours de test et de préproduction pour la diffusion. Dans ce plan, le dossier Non-production contient le projet de service et le projet hôte.
Development Contient les projets comportant des ressources cloud en cours de développement. Dans ce plan, le dossier Development contient le projet de service et le projet hôte.

Vous pouvez modifier les noms de ces dossiers pour qu'ils correspondent à la structure des dossiers de votre organisation, mais nous vous recommandons de conserver une structure similaire. Pour en savoir plus, consultez la section Structure organisationnelle. Pour les autres structures de dossiers, consultez la section Choisir une hiérarchie de ressources pour votre zone de destination Google Cloud.

Projets

Vous isolez les ressources dans votre environnement à l'aide de projets. Le tableau suivant décrit les projets nécessaires à l'organisation. Vous pouvez modifier les noms de ces projets, mais nous vous recommandons de conserver une structure de projet similaire.

Projet Description
Projet hôte de VPC partagé

Ce projet inclut les règles d'entrée du pare-feu et toutes les ressources disposant d'adresses IP internes (comme décrit dans la section Se connecter à un réseau VPC). Lorsque vous utilisez un VPC partagé, vous désignez un projet en tant que projet hôte, et vous lui associez un ou plusieurs projets de service.

Lorsque vous appliquez le code Terraform, vous spécifiez le nom de ce projet et le plan déploie le connecteur d'accès au VPC sans serveur, Cloud NAT et le proxy Web sécurisé Cloud.

Projet de service VPC partagé

Ce projet inclut votre application sans serveur, les fonctions Cloud Run et le connecteur d'accès au VPC sans serveur. Vous associez le projet de service au projet hôte afin que le projet de service puisse participer au réseau VPC partagé.

Lorsque vous appliquez le code Terraform, vous spécifiez le nom de ce projet. Le plan déploie les fonctions Cloud Run et les services nécessaires à votre cas d'utilisation, tels que Cloud SQL, Cloud Scheduler, Cloud Storage ou BigQuery.

Lorsque vous appliquez le code Terraform, vous spécifiez le nom de ce projet et le plan déploie Cloud KMS. Si vous utilisez le module Secure Serverless Harness dans le plan sans serveur pour les fonctions Cloud Run, Artifact Registry est également déployé.

Projet de sécurité

Ce projet inclut vos services spécifiques à la sécurité, tels que Cloud KMS et Secret Manager.

Le nom par défaut du projet de sécurité est prj-bu1-p-sec. Si vous déployez ce plan après avoir déployé le plan de base de sécurité, le projet de sécurité est créé en plus du projet de secrets du plan de base d'entreprise (prj-bu1-p-env-secrets). Pour en savoir plus sur les projets du plan de base d'entreprise, consultez la section Projets.

Si vous déployez plusieurs instances de ce plan sans le plan de base d'entreprise, chaque instance dispose de son propre projet de sécurité.

Mapper des rôles et des groupes à des projets

Vous devez autoriser différents groupes d'utilisateurs de votre organisation à accéder aux projets qui composent l'architecture sans serveur. Le tableau suivant décrit les recommandations de plan pour les groupes d'utilisateurs et les attributions de rôles dans les projets que vous créez. Vous pouvez personnaliser les groupes pour qu'ils correspondent à la structure existante de votre organisation, mais nous vous recommandons de maintenir une séparation similaire des tâches et de l'attribution de rôles.

Groupe Projet Rôles
Administrateur sans serveur
grp-gcp-serverless-admin@example.com
Projet de service
Administrateur de sécurité sans serveur
grp-gcp-serverless-security-admin@example.com
Projet de sécurité
Développeur de fonctions Cloud Run
grp-gcp-secure-cloud-run-developer@example.com
Projet de sécurité
Utilisateur de fonctions Cloud Run
grp-gcp-secure-cloud-run-user@example.com
Projet de service VPC partagé

Contrôles de sécurité

Cette section décrit les contrôles de sécurité dans Google Cloud qui vous permettent de sécuriser votre architecture sans serveur. Les principes de sécurité clés à prendre en compte sont les suivants :

  • Sécurisez l'accès en suivant le principe du moindre privilège, n'accordant aux comptes principaux que les droits nécessaires pour effectuer des tâches.
  • Sécurisez les connexions réseau par la conception d'un périmètre de confiance, qui comprend la segmentation réseau, les règles d'administration et les règles de pare-feu.
  • Sécurisez la configuration de chacun des services.
  • Identifiez les exigences de conformité ou réglementaires pour l'infrastructure qui héberge des charges de travail sans serveur et attribuez un niveau de risque.
  • Configurez des fonctions de surveillance et de journalisation suffisantes pour la prise en charge des outils d'audit en rapport avec les opérations de sécurité et la gestion des incidents.

Contrôles du système de compilation

Lorsque vous déployez votre application sans serveur, vous utilisez Artifact Registry pour stocker les images de conteneurs et les binaires. Artifact Registry est compatible avec CMEK afin que vous puissiez chiffrer le dépôt à l'aide de vos propres clés de chiffrement.

Règles de réseau et de pare-feu

Les règles de pare-feu de cloud privé virtuel (VPC) contrôlent le flux de données dans les périmètres. Vous créez des règles de pare-feu qui refusent toutes les sorties, à l'exception de connexions spécifiques pour le port TCP 443 provenant de noms de domaine spéciaux restricted.googleapis.com. L'utilisation du domaine restricted.googleapis.com présente les avantages suivants :

  • Il contribue à réduire la surface d'attaque du réseau en utilisant l'accès privé à Google lorsque les charges de travail communiquent avec les API et les services de Google.
  • Cela garantit que vous n'utilisez que les services compatibles avec VPC Service Controls.

En outre, vous créez un enregistrement DNS pour résoudre l'adresse *.googleapis.com en restricted.googleapis.com.

Pour plus d'informations, consultez la page Configurer l'accès privé à Google.

Contrôles du périmètre

Comme indiqué dans la section Architecture, vous placez les ressources de l'application sans serveur dans un périmètre de sécurité VPC Service Controls distinct. Ce périmètre permet de réduire l'impact général d'un piratage de systèmes ou de services. Toutefois, ce périmètre de sécurité ne s'applique pas au processus de compilation de fonctions Cloud Run lorsque Cloud Build compile automatiquement votre code dans une image de conteneur et transfère cette image vers Artifact Registry. Dans ce scénario, créez une règle d'entrée pour le compte de service Cloud Build dans le périmètre de service.

Règle d'accès

Pour vous assurer que seuls des comptes principaux spécifiques (utilisateurs ou services) peuvent accéder aux ressources et aux données, vous devez activer les groupes et les rôles IAM.

Pour vous assurer que seules des ressources spécifiques peuvent accéder à vos projets, vous devez activer une règle d'accès pour votre organisation Google. Pour en savoir plus, consultez la section Attributs de niveau d'accès.

Comptes de service et contrôles des accès

Les comptes de service sont des comptes pour des applications ou des charges de travail de calcul et non pour des utilisateurs finaux individuels. Pour mettre en œuvre les principes de moindre privilège et de séparation des tâches, vous devez créer des comptes de service avec des autorisations précises et un accès limité aux ressources. Les comptes de service sont les suivants :

Gestion des clés

Pour valider l'intégrité et aider à protéger vos données au repos, vous utilisez des clés de chiffrement gérées par le client (CMEK) avec Artifact Registry, les fonctions Cloud Run, Cloud Storage et Eventarc. Les clés CMEK vous offrent plus de contrôle sur votre clé de chiffrement. Les clés CMEK suivantes sont utilisées :

  • Une clé logicielle pour Artifact Registry qui atteste du code de votre application sans serveur.
  • Une clé de chiffrement pour chiffrer les images de conteneurs déployées par les fonctions Cloud Run.
  • Une clé de chiffrement pour les événements Eventarc qui chiffre le canal de messagerie au repos.
  • Une clé de chiffrement pour aider à protéger les données dans Cloud Storage.

Lorsque vous appliquez la configuration Terraform, vous spécifiez l'emplacement CMEK, qui détermine l'emplacement géographique où les clés sont stockées. Vous devez vous assurer que vos CMEK se trouvent dans la même région que vos ressources. Par défaut, les clés CMEK sont alternées tous les 30 jours.

Gérer les secrets

Les fonctions Cloud Run est compatible avec l'utilisation de Secret Manager pour stocker les secrets requis par votre application sans serveur. Ces secrets peuvent inclure des clés API, ainsi que des noms d'utilisateur et des mots de passe de base de données. Pour exposer le secret en tant que volume installé, utilisez les variables d'objet service_configs dans le module principal.

Lorsque vous déployez ce plan avec le plan de base d'entreprise, vous devez ajouter vos secrets au projet de secrets avant d'appliquer le code Terraform. Le plan attribue le rôle "Accesseur de secrets Secret Manager" (roles/secretmanager.secretAccessor) au compte de service des fonctions Cloud Run. Pour en savoir plus, consultez la page Utiliser des secrets.

Règles d'administration

Ce plan ajoute des contraintes aux contraintes liées aux règles d'administration utilisées par le plan de base d'entreprise. Pour en savoir plus sur les contraintes utilisées par le plan de base de l'entreprise, consultez la page Contraintes liées aux règles d'administration.

Le tableau suivant décrit les contraintes de règles d'administration supplémentaires définies dans le module Secure Cloud Run functions Security de ce plan.

Contrainte de règle Description Valeur recommandée
Paramètres d'entrée autorisés (fonctions Cloud Run) constraints/cloudfunctions.allowedIngressSettings

Autorise le trafic entrant provenant uniquement des services internes ou de l'équilibreur de charge HTTP(S) externe.

La valeur par défaut est ALLOW_ALL.

ALLOW_INTERNAL_ONLY
Exige un connecteur VPC (fonctions Cloud Run) constraints/cloudfunctions.requireVPCConnector

Exige la spécification d'un connecteur d'accès au VPC sans serveur lors du déploiement d'une fonction. Lorsque cette contrainte est appliquée, les fonctions doivent spécifier un connecteur d'accès au VPC sans serveur.

La valeur par défaut est false.

true
Paramètres de sortie autorisés du connecteur VPC (fonctions Cloud Run) cloudfunctions.allowedVpcConnectorEgressSettings

Exige que tout le trafic de sortie pour les fonctions Cloud Run utilise un connecteur d'accès au VPC sans serveur.

La valeur par défaut est PRIVATE_RANGES_ONLY.

ALL_TRAFFIC

Contrôles opérationnels

Vous pouvez activer la journalisation et les fonctionnalités de niveau Premium de Security Command Center, telles que l'analyse de l'état de la sécurité et la détection des menaces. Ces contrôles vous aident à effectuer les opérations suivantes :

  • Surveiller l'accès aux données.
  • S'assurer d'avoir mis en place un audit approprié.
  • Permettre la prise en charge des opérations de sécurité et des fonctionnalités de gestion des incidents de votre organisation.

Journalisation

Pour vous aider à répondre aux exigences d'audit et à mieux comprendre vos projets, configurez Google Cloud Observability avec des journaux de données pour les services que vous souhaitez suivre. Déployez Cloud Logging dans les projets avant d'appliquer le code Terraform afin de vous assurer que le plan peut configurer la journalisation pour le pare-feu, l'équilibreur de charge et le réseau VPC.

Une fois le plan déployé, nous vous recommandons de configurer les éléments suivants :

Pour tous les services des projets, assurez-vous que vos journaux incluent des informations sur les écritures de données et les accès administrateur. Pour en savoir plus sur les bonnes pratiques de journalisation, consultez la page Contrôles de détection.

Surveillance et alertes

Après avoir déployé le plan, vous pouvez configurer des alertes pour avertir votre centre d'opérations de sécurité (SOC) qu'un événement de sécurité s'est produit. Par exemple, vous pouvez utiliser les alertes pour informer vos analystes de la sécurité lorsqu'une autorisation a été modifiée dans un rôle IAM. Pour en savoir plus sur la configuration des alertes Security Command Center, consultez la section Configurer des notifications de recherche.

Le tableau de bord Monitoring des fonctions Cloud Run vous permet de surveiller les performances et l'état de vos fonctions Cloud Run. Il fournit une variété de métriques et de journaux, que vous pouvez utiliser pour identifier et résoudre les problèmes. Le tableau de bord inclut également un certain nombre de fonctionnalités qui peuvent vous aider à améliorer les performances de vos fonctions, telles que la possibilité de définir des alertes et des quotas.

Pour en savoir plus, consultez la section Surveiller les fonctions Cloud Run.

Pour exporter des alertes, consultez les documents suivants :

Débogage et dépannage

Vous pouvez exécuter des tests de connectivité pour vous aider à résoudre les problèmes de configuration réseau entre les fonctions Cloud Run et les ressources de votre sous-réseau. Les tests de connectivité simulent le chemin attendu d'un paquet et fournissent des détails sur la connectivité, y compris l'analyse de la connectivité entre ressources.

Les tests de connectivité ne sont pas activés par le code Terraform. Vous devez les configurer séparément. Pour plus d'informations, consultez la page Créer et exécuter des tests de connectivité.

Modes de déploiement Terraform

Le tableau suivant décrit les différentes manières de déployer ce plan et les modules Terraform qui s'appliquent à chaque mode de déploiement.

Mode de déploiement Modules Terraform

Déployer ce plan après avoir déployé le plan de base de l'entreprise (recommandé).

Cette option déploie les ressources de ce plan dans le même périmètre VPC Service Controls que celui utilisé par le plan de base d'entreprise. Pour en savoir plus, consultez la page Comment personnaliser Foundation v3.0.0 pour le déploiement de fonctions Cloud Run sécurisées.

Cette option utilise également le projet de secrets que vous avez créé lors du déploiement du plan de base d'entreprise.

Utilisez ces modules Terraform :

Installer ce plan sans installer le plan de sécurité de base.

Cette option nécessite la création d'un périmètre VPC Service Controls.

Utilisez ces modules Terraform :

Conclusion

Pour mettre en œuvre l'architecture décrite dans ce document, procédez comme suit :

  1. Consultez le README du plan pour vous assurer que vous remplissez toutes les conditions requises.
  2. Dans votre environnement de test, pour voir le plan en action, déployez l'un des exemples. Ces exemples correspondent aux exemples d'architecture décrits dans la section Architecture. Pour votre processus de test, considérez les actions suivantes :
    1. Utilisez Security Command Center pour analyser les projets par rapport aux exigences de conformité courantes.
    2. Remplacez l'exemple d'application par une application réelle (par exemple, 1) et exécutez un scénario de déploiement classique.
    3. Collaborez avec les équipes chargées de l'ingénierie des applications et des opérations de votre entreprise pour tester leur accès aux projets et vérifier si elles peuvent interagir avec la solution comme prévu.
  3. Déployez le plan dans votre environnement.

Étape suivante