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

Last reviewed 2023-03-10 UTC

Ce contenu a été mis à jour pour la dernière fois en mars 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.

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 Run. 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 vous permet d'exécuter des applications sans serveur sur Cloud Run avec un VPC partagé. Nous vous recommandons d'utiliser un VPC partagé car il centralise les règles de réseau et le contrôle de toutes les ressources réseau. De plus, le VPC partagé est déployé dans le plan de base de l'entreprise.

L'image suivante montre comment exécuter vos applications sans serveur dans un réseau VPC partagé.

Architecture du plan sans serveur.

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

  • Un équilibreur de charge d'application externe reçoit les données requises par les applications sans serveur depuis Internet et les transmet à Cloud Run. L'équilibreur de charge d'application externe est un équilibreur de charge de couche 7.
  • Google Cloud Armor sert de pare-feu d'application Web pour protéger vos applications sans serveur contre les attaques par déni de service (DoS) et sur le Web.
  • Cloud Run vous permet d'exécuter le code d'application dans des conteneurs et gère l'infrastructure en votre nom. Dans ce plan, le paramètre d'entrée interne et Cloud Load Balancing limite l'accès à Cloud Run afin que ce dernier n'accepte que les requêtes provenant de l'équilibreur de charge d'application externe.
  • 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 Run de communiquer avec d'autres services, systèmes de stockage et ressources compatibles avec VPC Service Controls.

    Par défaut, vous créez le connecteur d'accès au VPC sans serveur dans le projet de service. Vous pouvez créer le connecteur d'accès au VPC sans serveur dans le projet hôte en spécifiant true pour la variable d'entrée connector_on_host_project lorsque vous exécutez le module réseau Cloud Run sécurisé. Pour en savoir plus, consultez la section Comparaison des méthodes de configuration.

  • Les règles de pare-feu VPC contrôlent le flux de données dans le sous-réseau qui héberge vos ressources, tel qu'un serveur d'entreprise hébergé sur Compute Engine ou des données d'entreprise stockées dans Cloud Storage.

  • VPC Service Controls crée un périmètre de sécurité qui isole vos services et ressources 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 protéger le contenu entrant, pour isoler votre application en configurant des contrôles d'accès et de surveillance supplémentaires, et pour séparer votre gouvernance de Google Cloud de l'application. Votre gouvernance inclut la gestion des clés et la journalisation.

  • Le VPC partagé vous permet de connecter le connecteur d'accès au VPC sans serveur de votre projet de service au projet hôte.

  • 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 Run.

  • 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.

Architecture alternative : Cloud Run sans réseau VPC partagé

Si vous n'utilisez pas de réseau VPC partagé, vous pouvez déployer Cloud Run et votre application sans serveur dans un périmètre VPC Service Controls sans réseau VPC partagé. Vous pouvez mettre en œuvre cette architecture alternative si vous utilisez une topologie en étoile.

L'image suivante montre comment exécuter vos applications sans serveur sans VPC partagé.

Architecture alternative du plan sans serveur.

L'architecture illustrée dans le schéma précédent utilise une combinaison de services et de fonctionnalités Google Cloud similaires à ceux décrits dans la précédente section Architecture recommandée : Cloud Run avec un VPC partagé.

Structure organisationnelle

Vous regroupez vos ressources de façon à pouvoir les gérer et séparer vos environnements de développement et de test de votre environnement de production. 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 comportant des ressources cloud testées et 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.
Dev Contient les projets comportant des ressources cloud en cours de développement. Dans ce plan, le dossier Dev 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 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 les services.
Projet de service Ce projet inclut votre application sans serveur, 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 Cloud Run, Google Cloud Armor, le connecteur d'accès au VPC sans serveur et l'équilibreur de charge.
Projet de sécurité Ce projet inclut vos services spécifiques à la sécurité, tels que Cloud KMS et Secret Manager.

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 Cloud Run Harness, Artifact Registry est également déployé.

Si vous déployez ce plan après avoir déployé le plan de base de sécurité, ce projet est le projet de secrets créé par le plan de base de l'entreprise. Pour en savoir plus sur les projets de plan de base d'entreprise, consultez la page Projets.

Si vous déployez plusieurs instances de ce plan sans le plan de base de l'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 Run

grp-gcp-secure-cloud-run-developer@example.com
Projet de sécurité
Utilisateur Cloud Run

grp-gcp-secure-cloud-run-user@example.com
Projet de service

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 entités que les droits nécessaires pour effectuer leurs tâches.
  • Sécurisez les connexions réseau grâce à la conception de la segmentation, aux règles d'administration et aux règles de pare-feu.
  • Sécurisez la configuration de chacun des services.
  • Comprenez les niveaux de risque et les exigences de sécurité pour l'environnement qui héberge vos charges de travail sans serveur.
  • Configurez des fonctionnalités de surveillance et de journalisation suffisantes pour permettre la détection, l'enquête et la réponse.

Contrôles de sécurité pour les applications sans serveur

Vous pouvez protéger vos applications sans serveur à l'aide de commandes permettant de protéger le trafic sur le réseau, contrôler les accès et chiffrer les données.

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.

Trafic SSL

Pour prendre en charge le trafic HTTPS vers votre application sans serveur, vous configurez un certificat SSL pour l'équilibrage de charge d'application externe. Par défaut, vous utilisez un certificat autosigné que vous pouvez passer en certificat géré après avoir appliqué le code Terraform. Pour en savoir plus sur l'installation et l'utilisation de certificats gérés, consultez la section Utiliser des certificats SSL gérés par Google.

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.

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

Contrôles du périmètre

Comme illustré dans le schéma d'architecture recommandée, vous placez les ressources pour l'application sans serveur dans un périmètre distinct. Ce périmètre permet de protéger l'application sans serveur contre les accès indésirables et l'exfiltration de données.

Règles d'accès

Pour vous assurer que seules des identités 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.

Identity and Access Proxy

Si votre environnement inclut déjà Identity and Access Proxy (IAP), vous pouvez configurer l'équilibrage de charge d'application externe de façon à utiliser IAP pour autoriser le trafic pour votre application sans serveur. IAP vous permet d'établir une couche d'autorisation centrale pour votre application sans serveur de façon à pouvoir utiliser les contrôles d'accès au niveau de l'application au lieu d'utiliser des pare-feu au niveau du réseau.

Pour activer IAP pour votre application, définissez iap_config.enable sur true dans le fichier loadbalancer.tf.

Pour en savoir plus sur IAP, consultez la section Présentation d'Identity-Aware Proxy.

Comptes de service et contrôles des accès

Les comptes de service sont des identités que Google Cloud peut utiliser pour exécuter des requêtes API en votre nom. Pour implémenter la séparation des tâches, vous devez créer des comptes de service dotés de rôles différents à des fins spécifiques. Les comptes de service sont les suivants :

  • Un compte de service Cloud Run (cloud_run_sa) doté des rôles suivants :

    • roles/run.invoker
    • roles/secretmanager.secretAccessor

    Pour en savoir plus, consultez la section Autoriser Cloud Run à accéder à un secret.

  • Un compte de connecteur d'accès au VPC sans serveur (gcp_sa_vpcaccess) doté du rôle roles/compute.networkUser.

  • Un deuxième compte de connecteur d'accès au VPC sans serveur (cloud_services) doté du rôle 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 Run (run_identity_services) dotée du rôle roles/vpcaccess.user.

  • Un agent de service pour les API Google (cloud_services_sa) doté du rôle roles/editor. Ce compte de service permet à Cloud Run de communiquer avec le connecteur d'accès au VPC sans serveur.

  • Une identité de service pour Cloud Run (serverless_sa) dotée du rôle roles/artifactregistry.reader. Ce compte de service donne accès à Artifact Registry et aux clés de chiffrement et de déchiffrement CMEK.

Gestion des clés

Vous utilisez les clés CMEK pour protéger vos données dans Artifact Registry et dans Cloud Run. Vous utilisez les clés de chiffrement suivantes :

  • 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 Run.

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 clés 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 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 volume_mounts et volumes dans le module principal.

Lorsque vous déployez ce plan avec le plan de base de l'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" au compte de service Cloud Run. Pour en savoir plus, consultez la section Utiliser des secrets.

Règles d'administration

Ce plan ajoute des contraintes aux contraintes liées aux règles d'administration. 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 Security de ce plan.

Contrainte de règle Description Valeur recommandée
constraints/run.allowedIngress N'autorisez le trafic entrant qu'à partir de services internes ou de l'équilibreur de charge d'application externe. internal-and-cloud-load-balancing
constraints/run.allowedVPCEgress Exige que les révisions d'un service Cloud Run utilisent un connecteur d'accès au VPC sans serveur, et veille à ce que les paramètres de sortie VPC des révisions sont définis pour n'autoriser que les plages privées. private-ranges-only

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 qui accède à vos données.
  • S'assurer d'avoir mis en place un audit approprié.
  • Permettre à vos équipes chargées de la gestion des incidents et des opérations de résoudre les problèmes susceptibles de survenir.

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 lectures et les écritures de données, ainsi que sur les éléments auxquels les administrateurs accèdent. 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 incident de sécurité peut se produire. 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 Run, qui fait partie de l'exemple de bibliothèque de tableaux de bord, vous fournit les informations suivantes :

  • Nombre de requêtes
  • Latence de la requête
  • Temps d'instance facturable
  • Allocation de processeur du conteneur
  • Allocation de mémoire du conteneur
  • Utilisation du processeur du conteneur
  • Utilisation de la mémoire du conteneur

Pour obtenir des instructions concernant l'importation du tableau de bord, consultez la section Installer des exemples de tableaux de bord. 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 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é.

Les contrôles de détection

Cette section décrit les contrôles de détection inclus dans le plan.

Google Cloud Armor et WAF

Vous utilisez un équilibreur de charge d'application externe et Google Cloud Armor afin d'assurer une protection contre le déni de service distribué (DDoS) pour votre application sans serveur. Google Cloud Armor est le pare-feu d'application Web (WAF) inclus dans Google Cloud.

Vous configurez les règles Google Cloud Armor décrites dans le tableau suivant pour protéger l'application sans serveur. Ces règles sont conçues pour aider à limiter les risques du top 10 de l'OWASP.

Nom de la règle Google Cloud Armor Nom de la règle ModSecurity
Exécution de code à distance rce-v33-stable
Inclusion de fichiers locaux lfi-v33-stable
Attaque de protocole protocolattack-v33-stable
Inclusion de fichiers distants rfi-v33-stable
Détection du scanner scannerdetection-v33-stable
Attaque de réparation de session sessionfixation-v33-stable
Injection SQL sqli-v33-stable
Script intersites xss-v33-stable

Lorsque ces règles sont activées, Google Cloud Armor refuse automatiquement tout trafic correspondant à la règle.

Pour plus d'informations sur ces règles, consultez la section Ajuster les règles WAF préconfigurées de Google Cloud Armor.

Détection des problèmes de sécurité dans Cloud Run

Vous pouvez détecter les problèmes de sécurité potentiels dans Cloud Run à l'aide de l'outil de recommandation. L'outil de recommandation peut détecter des problèmes de sécurité tels que les suivants :

  • Clés API ou mots de passe stockés dans des variables d'environnement plutôt que dans Secret Manager.
  • Conteneurs qui incluent des identifiants codés en dur au lieu d'utiliser des identités de service

Environ un jour après le déploiement de Cloud Run, l'outil de recommandation commence à fournir ses résultats de recherche et ses recommandations. L'outil de recommandation affiche ses résultats et les actions correctives recommandées dans la liste des services Cloud Run ou le centre de recommandations.

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 plus d'informations, consultez la section Comment personnaliser la base v2.3.1 pour un déploiement sans serveur sécurisé.

Cette option utilise également le projet "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 base d'entreprise.

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 et assurez-vous que vous remplissez toutes les conditions requises.
  2. Créez un certificat SSL à utiliser avec l'équilibreur de charge d'application externe.
    Si vous n'effectuez pas cette étape, le plan utilise un certificat autosigné pour déployer l'équilibreur de charge, et votre navigateur affiche des avertissements de connexions non sécurisées lorsque vous tentez d'accéder à votre application sans serveur.
  3. Dans votre environnement de test, déployez l'exemple Cloud Run sécurisé pour voir le plan en action. Dans le cadre de 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 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.
  4. Déployez le plan dans votre environnement.

Mappages de conformité

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 vous aident à gérer la plupart de ces risques, comme décrit dans le tableau suivant.

Risque Atténuation du plan Votre responsabilité
1. Injection de données d'événements impactant des fonctions Google Cloud Armor et l'équilibrage de charge d'application externe permettent de se protéger contre les risques du Top 10 de l'OWASP, comme décrit dans le Top 10 des options d'atténuation de l'OWASP 2021 sur Google Cloud Pratiques de codage sécurisé telles que la gestion des exceptions, comme décrit dans les Pratiques de codage sécurisé de l'OWASP et les Niveaux de la chaîne d'approvisionnement pour les artefacts logiciels (SLSA)
2. Authentification défaillante Aucun IAP et Identity Platform pour authentifier les utilisateurs auprès du service
3. Configuration de déploiement sans serveur non sécurisé CMEK avec Cloud KMS
Gestion de vos propres clés de chiffrement
4. Autorisations et rôles de la fonction à privilèges trop élevés
  • Compte de service personnalisé pour l'authentification du service (pas le compte de service Compute Engine par défaut)
  • Rôles IAM à champ d'application restreint sur le compte de service Cloud Run
  • VPC Service Controls pour limiter le niveau d'accès à l'API Google Cloud (à condition d'utiliser les principes de base d'entreprise Google Cloud)
Aucun
5. Surveillance et journalisation de la fonction inadéquates Cloud Logging Tableaux de bord et structure d'alerte Cloud Monitoring
6. Dépendances tierces non sécurisées Aucun Protégez le pipeline CI/CD à l'aide de l'analyse de code et d'une analyse pré-déploiement
7. Stockage des secrets de l'application non sécurisé Secret Manager Gestion des codes secrets dans le code d'application
8. Déni de service et épuisement des ressources financières
  • Google Cloud Armor
  • Délais avant expiration du service Cloud Run (120 secondes par défaut)
Aucun
9. Manipulation de la logique métier sans serveur VPC Service Controls pour limiter le niveau d'accès à l'API Google Cloud (à condition d'utiliser le plan de base d'entreprise) Aucun
10. Gestion incorrecte des exceptions et messages d'erreur détaillés Aucun Bonnes pratiques relatives à la programmation sécurisée
11. Fonctions, ressources cloud et déclencheurs d'événements obsolètes Utilisez des révisions pour minimiser la surface d'attaque. Les révisions permettent de réduire le risque d'activation accidentelle d'une itération précédente et obsolète d'un service. Les révisions vous aident également à tester la stratégie de sécurité d'une nouvelle révision à l'aide de tests A/B et d'outils de surveillance et de journalisation.
  • Infrastructure as Code (IaC) pour gérer les ressources cloud
  • Surveillance des ressources cloud à l'aide de Security Command Center
  • Surveillance Cloud Billing
  • Nettoyage des ressources cloud inutilisées afin de minimiser la surface d'attaque
12. Persistance des données entre exécutions Aucun Aucun

Étapes suivantes