Ce principe du pilier de sécurité du Google Cloud framework d'architecture vous aide à identifier les contrôles pratiques que vous pouvez mettre en œuvre dès le début du cycle de développement logiciel pour améliorer votre stratégie de sécurité. Il fournit des recommandations qui vous aident à mettre en œuvre des garde-fous de sécurité préventifs et des contrôles de sécurité post-déploiement.
Présentation du principe
La sécurité shift left consiste à adopter des pratiques de sécurité dès le début du cycle de développement logiciel. Ce principe a les objectifs suivants :
- Éviter les défauts de sécurité avant d'apporter des modifications au système. Mettre en œuvre des garde-fous de sécurité préventifs et adopter des pratiques telles que l'infrastructure as code (IaC), la Policy as Code et les contrôles de sécurité dans le pipeline CI/CD. Vous pouvez également utiliser d'autres fonctionnalités spécifiques à la plate-forme, telles que le service de règles d'administration et les clusters GKE renforcés dans Google Cloud.
- Détecter et corriger les bugs de sécurité rapidement, de manière fiable et dès le début après l'application de modifications au système. Adopter des pratiques telles que les revues de code, l'analyse des failles post-déploiement et les tests de sécurité.
Les principes de mise en œuvre de la sécurité dès la conception et de la sécurité shift left sont liés, mais leur portée diffère. Le principe de sécurité dès la conception vous aide à éviter les défauts de conception fondamentaux qui nécessiteraient de réarchitecturer l'ensemble du système. Par exemple, un exercice de modélisation des menaces révèle que la conception actuelle n'inclut pas de règle d'autorisation et que tous les utilisateurs auraient le même niveau d'accès sans elle. La sécurité shift left vous aide à éviter les défauts d'implémentation (bugs et erreurs de configuration) avant l'application des modifications, et permet des corrections rapides et fiables après le déploiement.
Recommandations
Pour mettre en œuvre le principe de sécurité shift left pour vos charges de travail cloud, tenez compte des recommandations des sections suivantes :
- Adopter des contrôles de sécurité préventifs
- Automatiser le provisionnement et la gestion des ressources cloud
- Automatiser l'application des versions sécurisées
- Garantir que les déploiements d'applications suivent les processus approuvés
- Rechercher les failles connues avant le déploiement de l'application
- Détecter les failles connues dans votre code d'application
Adopter des contrôles de sécurité préventifs
Cette recommandation concerne les domaines d'intérêt suivants :
- Gestion de l'authentification et des accès
- Gouvernance, risques et conformité dans le cloud
Les contrôles de sécurité préventifs sont essentiels pour maintenir une stratégie de sécurité robuste dans le cloud. Ces contrôles vous aident à atténuer les risques de manière proactive. Vous pouvez éviter les erreurs de configuration et les accès non autorisés aux ressources, permettre aux développeurs de travailler efficacement et contribuer à garantir la conformité avec les normes du secteur et les règles internes.
Les contrôles de sécurité préventifs sont plus efficaces lorsqu'ils sont mis en œuvre à l'aide de l'infrastructure as code (IaC). Avec l'IaC, les contrôles de sécurité préventifs peuvent inclure des vérifications plus personnalisées du code d'infrastructure avant le déploiement des modifications. Combinés à l'automatisation, les contrôles de sécurité préventifs peuvent s'exécuter dans le cadre des vérifications automatiques de votre pipeline CI/CD.
Les produits et Google Cloud fonctionnalités suivants peuvent vous aider à mettre en œuvre des contrôles préventifs dans votre environnement :
- Contraintes du service de règles d'administration: configurez des contraintes prédéfinies et personnalisées avec un contrôle centralisé.
- VPC Service Controls : créez des périmètres autour de vos Google Cloud services.
- Identity and Access Management (IAM), Privileged Access Manager, et règles de limite d'accès du principal: limitez l'accès aux ressources.
- Policy Controller et Open Policy Agent (OPA) : appliquez des contraintes IaC dans votre pipeline CI/CD et évitez les erreurs de configuration cloud.
IAM vous permet d'autoriser qui peut agir sur des ressources spécifiques en fonction des autorisations. Pour en savoir plus, consultez la section Contrôle des accès aux ressources de l'organisation avec IAM.
Le service de règles d'administration vous permet de définir des restrictions sur les ressources pour spécifier leur configuration. Par exemple, vous pouvez utiliser une règle d'administration pour effectuer les opérations suivantes :
- Limiter le partage des ressources en fonction du domaine.
- Limiter l'utilisation des comptes de service.
- Limiter l'emplacement physique des ressources nouvellement créées.
En plus d'utiliser des règles d'administration, vous pouvez limiter l'accès aux ressources à l'aide des méthodes suivantes :
- Tags avec IAM : attribuez un tag à un ensemble de ressources, puis définissez la définition d’accès pour le tag lui-même, plutôt que de définir les autorisations d’accès sur chaque ressource.
- Conditions IAM : définissez un contrôle des accès conditionnel et basé sur des attributs pour les ressources.
- Défense en profondeur : utilisez VPC Service Controls pour limiter davantage l'accès aux ressources.
Pour en savoir plus sur la gestion des ressources, consultez Choisir une hiérarchie de ressources pour votre Google Cloud zone de destination.
Automatiser le provisionnement et la gestion des ressources cloud
Cette recommandation concerne les domaines d'intérêt suivants :
- Sécurité des applications
- Gouvernance, risques et conformité dans le cloud
L'automatisation du provisionnement et de la gestion des ressources et des charges de travail cloud est plus efficace lorsque vous adoptez également l'IaC déclarative, par opposition aux scripts impératifs. L'IaC n'est pas un outil ni une pratique de sécurité en soi, mais elle vous aide à améliorer la sécurité de votre plate-forme. L'adoption de l'IaC vous permet de créer une infrastructure reproductible et fournit à votre équipe d'opérations un état de fonctionnement connu. L'IaC améliore également l'efficacité des rollbacks, des modifications d'audit et du dépannage.
Combinée aux pipelines CI/CD et à l'automatisation, l'IaC vous permet également d'adopter des pratiques telles que la Policy as Code avec des outils tels qu'OPA. Vous pouvez auditer les modifications d'infrastructure au fil du temps et exécuter des vérifications automatiques sur le code d'infrastructure avant le déploiement des modifications.
Pour automatiser le déploiement de l'infrastructure, vous pouvez utiliser des outils tels que Config Controller, Terraform, Jenkins et Cloud Build. Pour vous aider à créer un environnement d'application sécurisé à l'aide de l'IaC et de l'automatisation, Google Cloud fournit le plan de base d'entreprise. Ce plan est la conception de Google qui suit toutes nos pratiques et configurations recommandées. Il fournit des instructions détaillées pour configurer et déployer votre Google Cloud topologie à l'aide de Terraform et Cloud Build.
Vous pouvez modifier les scripts du plan de base d'entreprise pour configurer un environnement qui suit les recommandations de Google et répond à vos propres exigences de sécurité. Vous pouvez également vous appuyer sur le plan avec des plans supplémentaires ou concevoir votre propre automatisation. L' Google Cloud Architecture Center fournit d'autres plans qui peuvent être mis en œuvre en plus du plan de base d'entreprise. Voici quelques exemples de ces plans :
- Déployer une plate-forme de développeur d'entreprise sur Google Cloud
- Déployer une architecture sécurisée sans serveur à l'aide de Cloud Run
- Créer et déployer des modèles d'IA générative et de machine learning dans une entreprise
- Importer des données depuis Google Cloud dans un entrepôt de données BigQuery sécurisé
Automatiser l'application des versions sécurisées
Cette recommandation concerne le domaine d’intérêt suivant : sécurité des applications.
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 de créer des pipelines CI/CD automatisés pour votre cycle de développement logiciel (SDLC). Les pipelines CI/CD automatisés vous aident à supprimer les erreurs manuelles, à fournir des boucles de rétroaction standardisées pour le développement et à permettre des itérations efficaces des produits. La livraison continue est l'une des bonnes pratiques recommandées par le framework DORA.
L'automatisation des versions d'application à l'aide de pipelines CI/CD vous aide à améliorer votre capacité à détecter et à corriger les bugs de sécurité rapidement et de manière fiable. Par exemple, vous pouvez rechercher automatiquement les failles de sécurité lors de la création d'artefacts, limiter la portée des examens de sécurité et revenir à une version connue et sécurisée. Vous pouvez également définir des règles pour différents environnements (tels que les environnements de développement, de test ou de production) afin que seuls les artefacts validés soient déployés.
Pour vous aider à automatiser les versions d'application et à intégrer des contrôles de sécurité dans votre pipeline CI/CD, Google Cloud fournit plusieurs outils, dont Cloud Build, Cloud Deploy, Web Security Scanner, et l'autorisation binaire.
Pour établir un processus qui vérifie plusieurs exigences de sécurité dans votre SDLC, utilisez le framework SLSA (Supply-chain Levels for Software Artifacts ou Niveaux de la chaîne d'approvisionnement pour les artefacts logiciels), défini par Google. SLSA nécessite des contrôles de sécurité pour le code source, le processus de compilation et la provenance du code. Bon nombre de ces exigences peuvent être incluses dans un pipeline CI/CD automatisé. Pour comprendre comment Google applique ces pratiques en interne, consultez Google Cloud's approche de changement.
Garantir que les déploiements d'applications suivent les processus approuvés
Cette recommandation concerne le domaine d’intérêt suivant : sécurité des applications.
Si un pirate informatique compromet votre pipeline CI/CD, l'ensemble de votre pile d'applications 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 utilisez Google Kubernetes Engine (GKE) ou Cloud Run, vous pouvez établir un processus d'approbation à l'aide de 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é effectué. 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 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 les 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é.
En utilisant l'autorisation binaire, vous pouvez vous assurer que seul le code approuvé s'exécute sur vos plates-formes cibles.
Rechercher les failles connues avant le déploiement de l'application
Cette recommandation concerne le domaine d’intérêt suivant : sécurité des applications.
Nous vous recommandons d'utiliser des outils automatisés pour analyser en continu les failles des artefacts d'application avant leur déploiement en production.
Pour les applications conteneurisées, utilisez Artifact Analysis pour exécuter automatiquement des analyses de failles pour les images de conteneurs. Artifact Analysis analyse les nouvelles images au fur et à mesure de leur importation dans Artifact Registry. Cette analyse extrait des informations sur les packages système du conteneur. Une fois l'analyse initiale terminée, Artifact Analysis surveille en permanence les métadonnées des images analysées dans Artifact 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
Cette recommandation concerne le domaine d’intérêt suivant : sécurité des applications.
Utilisez des outils automatisés pour surveiller en permanence le code de votre application afin de détecter les failles connues telles que le OWASP Top 10. Pour en savoir plus sur les Google Cloud produits et fonctionnalités 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 GKE. 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écèle automatiquement les failles, telles que les scripts intersites, les injections de code, les contenus mixtes, et les bibliothèques obsolètes/non sécurisées. Web Security Scanner vous permet d'identifier rapidement ces types de failles sans vous distraire avec des faux positifs.
De plus, si vous utilisez GKE pour gérer des parcs de clusters Kubernetes, le tableau de bord de stratégie de sécurité affiche des recommandations avisées et exploitables pour vous aider à améliorer la stratégie de sécurité de votre parc.