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 :
- Déployer une architecture sans serveur à l'aide de Cloud Run (ce document)
- Déployer une architecture sans serveur à l'aide des fonctions Cloud Run
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.
Architecture recommandée : Cloud Run avec un réseau VPC partagé
L'image suivante montre comment exécuter vos applications sans serveur dans un réseau VPC partagé.
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
truepour la variable d'entréeconnector_on_host_projectlorsque 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é.
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.
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.invokerroles/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ôleroles/compute.networkUser.Un deuxième compte de connecteur d'accès au VPC sans serveur (
cloud_services) doté du rôleroles/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ôleroles/vpcaccess.user.Un agent de service pour les API Google (
cloud_services_sa) doté du rôleroles/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ôleroles/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 :
- Créez un récepteur de journaux agrégés sur l'ensemble des projets.
- Sélectionnez la région appropriée pour stocker vos journaux.
- 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 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 :
- Consultez le README du plan et assurez-vous que vous remplissez toutes les conditions requises.
- 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. - 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 :
- 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 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.
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 |
|
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 |
|
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. |
|
| 12. Persistance des données entre exécutions | Aucun | Aucun |
Étapes suivantes
- Pour découvrir un environnement sécurisé de référence, consultez le plan de base d'entreprise de Google Cloud.
- Pour afficher les détails du plan décrit dans ce document, consultez le fichier README de la configuration Terraform.
Pour en savoir plus sur les bonnes pratiques concernant la sécurité et la conformité, consultez la section Framework d'architecture Google Cloud : sécurité, confidentialité et conformité.
Pour découvrir d'autres bonnes pratiques et plans, consultez le centre des bonnes pratiques de sécurité.