Protéger les déploiements

Ce document décrit les bonnes pratiques à suivre pour protéger vos déploiements.

Créer et appliquer des règles de déploiement

Pour protéger vos environnements d'exécution, définissez des règles avec des critères de déploiement et validez la conformité des règles avant et après le déploiement. Définir une règle qui n'autorise que le code signé par des attesteurs prédéfinis permet de limiter les déploiements et de ne déployer que du code provenant d'origines approuvées.

Voici quelques exemples de critères de déploiement:

  • Aucune faille connue de gravité supérieure à moyenne
  • Le code source provient d'un dépôt source fiable
  • Un service de compilation fiable a exécuté la compilation
  • Les artefacts de compilation que vous déployez proviennent d'un dépôt d'artefacts de confiance

Générer des métadonnées

Pour valider ces exigences, vous devez fournir des métadonnées sur vos artefacts de compilation.

Origines de compilation

La provenance du build est une collection de données vérifiables concernant un build, telles que les condensés des images compilées, les emplacements de la source d'entrée, la chaîne d'outils de compilation et la durée de compilation. Le SLSA, qui permet d'évaluer la posture de sécurité, fournit un modèle de provenance et des exigences de provenance. La provenance est une catégorie d'exigences du framework, et chaque exigence est associée à des niveaux SLSA afin que vous puissiez implémenter des mesures d'atténuation de manière incrémentielle.

  • Pour l'assurance de niveau 1 du SLSA, la provenance doit être disponible.
  • Pour l'assurance de niveau 2 SLSA, la provenance doit être générée et les consommateurs doivent pouvoir vérifier son authenticité et son intégrité.
  • Les niveaux 3 et 4 de la certification SLSA imposent des exigences plus strictes en matière de signature de la provenance et de la profondeur des détails des données de provenance.

Certains services de compilation génèrent des métadonnées de provenance de compilation.

Failles

Un logiciel d'analyse des failles vérifie votre code source et vos artefacts de compilation à la recherche de failles connues. Artifact Analysis peut analyser automatiquement les images de conteneurs transférées vers Artifact Registry afin de rechercher les failles. Pour rechercher des failles dans les artefacts avant de les stocker, vous pouvez utiliser l'API d'analyse à la demande dans un environnement de développement local ou dans un pipeline CI/CD, tel qu'une étape de compilation Cloud Build.

Configurer l'application des règles

Une fois que vous disposez de métadonnées sur vos artefacts déployables, vous avez besoin d'outils pour appliquer vos règles.

Dans Google Cloud, vous pouvez configurer une stratégie dans Autorisation binaire pour vos déploiements. L'autorisation binaire applique la stratégie pour les tentatives de déploiement sur les plates-formes basées sur des conteneurs compatibles. Il peut également effectuer une validation continue des règles pour les charges de travail exécutées sur GKE, Cloud Run et GKE Enterprise.

Les vérifications préalables au déploiement peuvent bloquer toutes les images qui ne figurent pas dans la liste des images exclues, de sorte que seules les images approuvées soient déployées à partir de registres approuvés. Votre stratégie peut également exiger des attestations, des documents numériques qui indiquent que l'image a été créée avec succès à l'aide d'un processus spécifique et obligatoire. Par exemple, une attestation peut indiquer qu'une image est:

La validation continue étend la validation des règles à l'environnement post-déploiement. Lorsqu'elle est activée, l'autorisation binaire fournit une validation tout au long du cycle de vie du pod en enregistrant régulièrement la conformité avec les règles dans Cloud Logging. Cela peut être utile dans diverses situations. Par exemple, si vous modifiez votre règle après avoir déployé un conteneur, la validation continue consigne les pods qui ne respectent pas la règle mise à jour. Il consigne également les cas de non-respect des règles pour les pods déployés avec un essai ou un bris de glace.

Utiliser des services de déploiement contrôlés

Le contrôle des déploiements vous permet d'approuver ou de refuser les déploiements à des points spécifiques du processus de déploiement à l'aide d'un service CI/CD autonome ou d'un service CI/CD intégré à un système d'automatisation de processus. Les déploiements contrôlés empêchent les utilisateurs non autorisés d'apporter des modifications aux environnements d'application. Elles offrent une surveillance supplémentaire du processus de déploiement et une meilleure visibilité des approbations.

Dans Google Cloud, Cloud Deploy propose un service entièrement géré pour déployer des charges de travail sur Google Kubernetes Engine. La fonctionnalité de déploiement contrôlé permet aux utilisateurs de spécifier si une approbation est nécessaire pour la promotion vers une cible.

Surveiller vos charges de travail

Les charges de travail sont des applications exécutées sur des plates-formes basées sur des conteneurs, telles que GKE et Cloud Run. Les charges de travail que vous déployez doivent idéalement disposer d'une configuration renforcée qui limite leur surface d'attaque.

Il peut être difficile de vérifier manuellement les charges de travail des clusters pour détecter les problèmes de configuration à grande échelle. Google Cloud fournit des tableaux de bord dans Cloud Run et GKE pour afficher des insights sur la sécurité des charges de travail.

Le tableau de bord de la stratégie de sécurité GKE vous fournit des conseils pour renforcer la stratégie de sécurité de vos clusters en fonction des recommandations de Google. Il inclut une analyse automatique de la configuration des charges de travail, qui recherche les problèmes de configuration connus dans toutes les charges de travail. GKE vérifie chaque charge de travail déployée selon les bonnes pratiques du secteur, telles que les règles définies dans les normes de sécurité des pods. GKE évalue la gravité des problèmes détectés et renvoie des recommandations et des journaux exploitables. Vous pouvez utiliser Cloud Logging pour obtenir une piste contrôlable des préoccupations pour une meilleure création de rapports et d'observabilité. Pour savoir comment afficher les insights de sécurité dans le tableau de bord de stratégie de sécurité de GKE, consultez Déployer dans GKE et afficher les insights de sécurité.

Cloud Run contient un panneau de sécurité qui affiche des insights sur la sécurité de la chaîne d'approvisionnement logiciel, tels que les informations de conformité au niveau de compilation SLSA, la provenance de la compilation et les failles détectées dans les services en cours d'exécution. Pour savoir comment afficher les insights de sécurité dans le panneau "Insights de sécurité" de Cloud Run, consultez la section Déployer sur Cloud Run et afficher les insights de sécurité.

Google Cloud propose également d'autres services et fonctionnalités pour améliorer votre stratégie de sécurité tout au long du cycle de vie du développement logiciel. Pour en savoir plus, consultez la présentation de la chaîne d'approvisionnement logicielle.

Étape suivante