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 Cloud Functions (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 :
- Déployer une architecture sans serveur à l'aide de Cloud Functions (ce document)
- Déployer une architecture sans serveur à l'aide de Cloud Run
Les différences entre Cloud Functions et Cloud Run incluent les suivantes :
- Cloud Functions est déclenché 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.
- Cloud Functions est limité à un ensemble d'environnements d'exécution compatibles. Vous pouvez utiliser Cloud Run avec n'importe quel langage de programmation.
- Cloud Functions gère les conteneurs et l'infrastructure qui contrôle le serveur Web ou le langage 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 Cloud Functions, consultez la page Choisir une option de calcul Google Cloud.
Architecture
Ce plan utilise une architecture de VPC partagé, dans laquelle Cloud Functions est déployé 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.
L'architecture illustrée dans le schéma précédent utilise une combinaison des services et fonctionnalités Google Cloud suivants :
- Cloud Functions vous permet d'exécuter des fonctions en tant que service (Functions as a Service) et gère l'infrastructure en votre nom. Par défaut, cette architecture déploie Cloud Functions avec une adresse IP interne uniquement, sans accès à l'Internet public.
- L'événement déclencheur est l'événement qui déclenche Cloud Functions. 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 Cloud Functions.
- 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 à Cloud Functions 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 Cloud Functions 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 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 Cloud Functions, 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 de Cloud Functions. 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 Cloud Functions ne nécessite 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 Cloud Functions.
Secret Manager stocke les secrets Cloud Functions. 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.
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 Cloud Functions.
- 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 Functions 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.
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 Scheduler émet des événements régulièrement.
- Pub/Sub met en file d'attente les événements utilisés en tant qu'entrée et déclencheur pour Cloud Functions.
- 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, telles que les données d'entreprise stockées dans Cloud SQL.
- Le proxy d'authentification Cloud SQL contrôle l'accès à Cloud SQL.
- Cloud SQL héberge un service appairé au réseau VPC et auquel l'application sans serveur peut accéder. Si vous déployez l'exemple de fonctions Cloud Functions sécurisées avec Cloud SQL, vous déployez une base de données MySQL avec un exemple de base de données.
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).
Outre les services décrits dans la section Architecture, cet exemple d'architecture utilise une combinaison des services et fonctionnalités Google Cloud suivants :
- BigQuery héberge un entrepôt de données. Si vous déployez l'exemple de fonctions Cloud Functions sécurisées déclenchées par BigQuery, vous allez déployer un exemple d'ensemble de données et de table BigQuery.
- Eventarc déclenche Cloud Functions lorsqu'un événement particulier se produit dans BigQuery.
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.
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, Cloud Functions 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 Cloud Functions et les services Cloud 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 Cloud Functions, 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 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 Cloud Functions grp-gcp-secure-cloud-run-developer@example.com |
Projet de sécurité | |
| Utilisateur Cloud Functions 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 Cloud Functions 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ègles 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 :
Un compte de service Cloud Functions (
cloudfunction_sa) doté des rôles suivants :- Lecteur de réseau Compute (
roles/compute.networkViewer) - Destinataire des événements Eventarc (
roles/eventarc.eventReceiver) - Demandeur Cloud Run (
roles/run.invoker) - Accesseur de secret Secret Manager (
roles/secretmanager.secretAccessor)
Pour en savoir plus, consultez la section Autoriser Cloud Functions à accéder à un secret.
Cloud Functions utilise ce compte de service pour accorder des autorisations uniquement à des sujets Pub/Sub spécifiques et pour limiter le système d'événements Eventarc à partir des ressources de calcul de Cloud Functions dans l'Exemple d'architecture avec une application sans serveur utilisant Cloud Storage et l'Exemple d'architecture avec un entrepôt de données BigQuery.
- Lecteur de réseau Compute (
Un compte de connecteur d'accès au VPC sans serveur (
gcp_sa_vpcaccess) doté du rôle Utilisateur de réseau Compute (roles/compute.networkUser).Un deuxième compte de connecteur d'accès au VPC sans serveur (
cloud_services) doté du rôle Utilisateur de réseau Compute (roles/compute.networkUser).Ces comptes de service pour le connecteur d'accès au VPC sans serveur sont nécessaires pour que le connecteur puisse créer les règles d'entrée et de sortie du pare-feu dans le projet hôte. Pour en savoir plus, consultez la section Accorder des autorisations aux comptes de service dans vos projets de service.
Une identité de service pour exécuter Cloud Functions (
cloudfunction_sa) dotée des rôles Utilisateur de l'accès au VPC sans serveur (roles/vpcaccess.user)](/iam/docs/understanding-roles#vpcaccess.user)) et Utilisateur du compte de service (roles/iam.serviceAccountUser).Un compte de service pour les API Google (
cloud_services_sa) doté du rôle Utilisateur de réseau Compute (roles/compute.networkUser) afin d'exécuter des processus Google internes en votre nom.Une identité de service pour Cloud Functions (
cloud_serverless_sa) dotée du rôle Lecteur Artifact Registry (roles/artifactregistry.reader). Ce compte de service donne accès à Artifact Registry et aux clés CMEK.Une identité de service pour Eventarc (
eventarc_sa) dotée des rôles Déchiffreur de CryptoKeys Cloud KMS (roles/cloudkms.cryptoKeyDecrypter) et Chiffreur de CryptoKeys Cloud KMS (roles/cloudkms.cryptoKeyEncrypter).Une identité de service pour Artifact Registry (
artifact_sa) dotée des rôles Déchiffreur de CryptoKeys (roles/cloudkms.cryptoKeyDecrypter) et Chiffreur de CryptoKeys Cloud KMS (roles/cloudkms.cryptoKeyEncrypter).
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, Cloud Functions, 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 Cloud Functions.
- 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
Cloud Functions 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 Cloud Functions. 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 d'entreprise, consultez la section 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 Functions Security de ce plan.
| Contrainte de règle | Description | Valeur recommandée |
|---|---|---|
Paramètres d'entrée autorisés (Cloud Functions) 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_INTERNAL_ONLY
|
Exiger un connecteur VPC (Cloud Functions) 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 |
true
|
Paramètres de sortie autorisés du connecteur VPC (Cloud Functions) cloudfunctions.allowedVpcConnectorEgressSettings |
Exige que tout le trafic de sortie pour Cloud Functions utilise un connecteur d'accès au VPC sans serveur. La valeur par défaut est |
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 :
- Créez un récepteur de journaux agrégés sur l'ensemble des projets.
- Ajoutez des clés CMEK à votre récepteur de journaux.
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 de Cloud Functions vous permet de surveiller les performances et l'état de vos fonctions Cloud Functions. 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 Functions.
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 Cloud Functions 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 d'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 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 :
- Consultez le fichier README du plan pour vous assurer que vous remplissez toutes les conditions requises.
- 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 :
- Utilisez Security Command Center pour analyser les projets par rapport aux exigences de conformité courantes.
- Remplacez l'exemple d'application par une application réelle (par exemple, 1) et exécutez un scénario de déploiement classique.
- 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.
- Déployez le plan dans votre environnement.
Étapes suivantes
- Consultez le plan de base d'entreprise de Google Cloud pour découvrir un environnement sécurisé de référence.
- Pour en savoir plus sur le plan, consultez le fichier readme de la configuration Terraform.
- Pour déployer une application sans serveur à l'aide de Cloud Run, consultez la page Déployer une architecture sécurisée sans serveur à l'aide de Cloud Run.