Le présent document du framework d'architecture Google Cloud décrit les bonnes pratiques pour déployer des applications en toute sécurité.
Pour déployer des applications sécurisées, vous devez disposer d'un cycle de vie de développement logiciel bien défini, avec des contrôles de sécurité appropriés pendant les phases de conception, de développement, de test et de déploiement. Lorsque vous concevez une application, nous vous recommandons d'utiliser une architecture système en couches qui met en œuvre des frameworks standardisés pour l'authentification, les autorisations et le contrôle des accès.
Automatiser l'application des versions sécurisées
Sans outils automatisés, il peut s'avérer difficile de déployer, de mettre à jour et d'appliquer des correctifs aux environnements applicatifs complexes pour satisfaire les exigences de sécurité. Nous vous recommandons donc de créer un pipeline CI/CD pour ces tâches, ce qui peut résoudre de nombreux problèmes. Les pipelines automatisés suppriment les erreurs manuelles, fournissent des boucles de rétroaction standardisées pour le développement et permettent une itération rapide des produits. Par exemple, les pools privés Cloud Build vous permettent de déployer un pipeline CI/CD hautement sécurisé et géré pour des secteurs hautement réglementés comme la finance ou la santé.
Vous pouvez utiliser l'automatisation pour rechercher les failles de sécurité lors de la création des artefacts. Vous pouvez également définir des règles pour différents environnements (développement, test, production, etc.) afin que seuls les artefacts validés soient déployés.
Garantir que les déploiements d'applications suivent les processus approuvés
Si un pirate informatique compromet le pipeline CI/CD, l'ensemble de votre pile peut être affecté. Pour sécuriser le pipeline, vous devez appliquer un processus d'approbation bien défini avant de déployer le code en production.
Si vous prévoyez d'utiliser Google Kubernetes Engine (GKE) ou GKE Entreprise, vous pouvez mettre en place ces contrôles de sécurité en utilisant l'autorisation binaire. L'autorisation binaire associe des signatures configurables aux images de conteneurs. Ces signatures (également appelées attestations) aident à valider l'image. Au moment du déploiement, l'autorisation binaire utilise ces attestations pour déterminer si un processus a été mis en œuvre précédemment. Par exemple, vous pouvez utiliser l'autorisation binaire pour effectuer les opérations suivantes :
- Vérifier qu'un système de compilation ou un pipeline d'intégration continue (CI) spécifique a bien créé une image de conteneur.
- Vérifier qu'une image de conteneur est conforme aux règles de signature des failles.
- Vérifier qu'une image de conteneur transmet des critères de promotion à l'environnement de déploiement suivant, par exemple de l'environnement de développement vers l'environnement de contrôle qualité
Rechercher les failles connues avant le déploiement
Nous vous recommandons d'utiliser des outils automatisés pour analyser en continu les failles des images de conteneurs avant leur déploiement en production.
Utilisez Artifact Analysis pour rechercher automatiquement les failles des conteneurs stockés dans Artifact Registry et Container Registry. Ce processus comprend deux tâches : l'analyse incrémentielle et l'analyse continue.
Pour commencer, Artifact Analysis analyse les nouvelles images au fur et à mesure de leur importation dans Artifact Registry ou Container Registry. Cette analyse extrait des informations sur les packages système du conteneur.
Artifact Analysis recherche ensuite les failles lorsque vous importez l'image. Une fois l'analyse initiale terminée, Artifact Analysis surveille en permanence les métadonnées des images analysées dans Artifact Registry et Container Registry afin de détecter de nouvelles failles. Lorsque Artifact Analysis reçoit de nouvelles informations ou des informations actualisées sur les failles, en provenance des sources de failles, il effectue les opérations suivantes :
- Mise à jour des métadonnées des images analysées afin de les actualiser.
- Création d'occurrences de failles pour les nouvelles notes.
- Suppression des occurrences de failles qui ne sont plus valides.
Détecter les failles connues dans votre code d'application
Il est recommandé d'utiliser des outils automatisés pour surveiller en permanence le code de votre application afin de détecter les failles connues, comme le OWASP Top 10. Pour obtenir une description des produits et des fonctionnalités Google Cloud compatibles avec le top 10 des techniques d'atténuation OWASP, consultez la page Top 10 des options d'atténuation de l'OWASP sur Google Cloud.
Utilisez Web Security Scanner pour identifier les failles de sécurité dans vos applications Web App Engine, Compute Engine et Google Kubernetes Engine. Le service explore votre application et tous les liens associés à vos URL de démarrage, et tente de tester un maximum d'entrées utilisateur et de gestionnaires d'événements. Il recherche et détecte automatiquement les failles courantes, y compris les scripts intersites (XSS), les injections Flash, les contenus mixtes (HTTP dans HTTPS) et les bibliothèques obsolètes ou non sécurisées. Web Security Scanner vous permet d'identifier rapidement ces types de failles avec un faible taux de faux positifs.
Contrôler le mouvement des données entre les périmètres
Pour contrôler le mouvement des données sur un périmètre, vous pouvez configurer des périmètres de sécurité autour des ressources de vos services gérés par Google. Utilisez VPC Service Controls pour placer tous les composants et services de votre pipeline CI/CD (par exemple, Container Registry, Artifact Registry, Artifact Analysis et l'autorisation binaire) à l'intérieur d'un périmètre de sécurité.
VPC Service Controls vous aide à limiter les risques de copie ou de transfert non autorisé de données (exfiltration de données) à partir de services gérés par Google. Cette solution vous permet de configurer des périmètres de sécurité autour des ressources de vos services gérés par Google et de contrôler le déplacement des données au-delà des limites des périmètres. Lorsqu'un périmètre de service est forcé, les requêtes qui ne respectent pas la règle de périmètre, telles que les requêtes adressées à des services protégés en dehors d'un périmètre, sont refusées. Lorsqu'un service est protégé par un périmètre forcé, VPC Service Controls garantit les éléments suivants :
- Un service ne peut pas transmettre de données en dehors du périmètre. Les services protégés fonctionnent normalement à l'intérieur du périmètre, mais ne peuvent pas envoyer de ressources ni de données en dehors de celui-ci. Cette restriction permet d'éviter que des initiés malveillants susceptibles d'avoir accès à des projets du périmètre ne puissent exfiltrer des données.
- Les requêtes émises depuis l'extérieur du périmètre vers le service protégé ne sont prises en compte que si elles répondent aux critères des niveaux d'accès attribués au périmètre.
- Un service peut être rendu accessible aux projets situés dans d'autres périmètres à l'aide de liaisons de périmètre.
Chiffrer vos images de conteneur
Dans Google Cloud, vous pouvez chiffrer vos images de conteneurs en utilisant des clés de chiffrement gérées par le client (CMEK). Les clés CMEK sont gérées dans Cloud Key Management Service (Cloud KMS). Lorsque vous utilisez la fonctionnalité CMEK, vous pouvez désactiver temporairement ou définitivement l'accès à une image de conteneur chiffrée en désactivant ou en détruisant la clé.
Étape suivante
Pour en savoir plus sur la sécurisation de votre chaîne d'approvisionnement et de vos applications, consultez les ressources suivantes :
- Gérer les obligations de conformité (document suivant de cette série)
- Excellence opérationnelle
- Autorisation binaire
- Artifact Analysis
- Artifact Registry