Ce document décrit les modèles d'automatisation des règles et des contrôles de conformité pour vos ressources Google Cloud à l'aide de Chef InSpec, un framework de test d'infrastructure Open Source. Ce document s'adresse aux architectes et aux professionnels DevOps qui souhaitent intégrer des tests de conformité continus à leur workflow de développement logiciel.
Stratégie et conformité dans Google Cloud
Google Cloud fournit une gamme d'outils pour vous aider à appliquer et auditer les stratégies et les exigences de conformité :
| Service | Description |
|---|---|
| Hiérarchie des ressources | Vous pouvez utiliser la hiérarchie des ressources pour mapper la structure opérationnelle de votre entreprise à Google Cloud, ainsi que pour gérer le contrôle des accès et les autorisations pour des groupes de ressources associées. Vous pouvez définir des groupes de ressources associées et appliquer des contrôles cohérents à toutes les ressources du groupe. Par exemple, vous pouvez regrouper dans un dossier particulier tous vos projets Google Cloud soumis à la norme de sécurité des données de l'industrie des cartes de paiement (PCI DSS). Vous pouvez ensuite appliquer les contrôles pertinents à tous les projets de ce dossier. |
| Service de règles d'organisation | Le service de règles d'organisation permet de définir des contraintes qui limitent la disponibilité ou les fonctionnalités des services Google Cloud. Par exemple, vous pouvez utiliser la contrainte d'emplacement des ressources pour limiter l'ensemble de régions dans lesquelles des ressources basées sur l'emplacement telles que des machines virtuelles peuvent être créées. Le service de règles d'organisation fonctionne avec la hiérarchie des ressources. Vous pouvez appliquer des règles d'administration à différents niveaux de la hiérarchie. Par exemple, vous pouvez définir une règle d'administration pour vos projets soumis à la norme PCI, puis l'appliquer au dossier PCI. |
| Security Command Center | Security Command Center offre une visibilité centralisée sur toutes vos ressources Google Cloud. Security Command Center analyse automatiquement vos ressources cloud pour détecter les failles connues et fournit une interface utilisateur ainsi qu'une plate-forme de données uniques pour agréger et gérer les résultats de sécurité. Security Health Analytics peut fournir des fonctionnalités de surveillance et de création de rapports pour des normes de conformité comme la PCI DSS et les normes de secteur telles que le benchmark du CIS (Center for Internet Security). Vous pouvez afficher les rapports dans un tableau de bord de conformité, puis les exporter. Security Command Center s'intègre à plusieurs sources de sécurité tierces et fournit une API permettant d'ajouter et de gérer vos résultats personnalisés. Security Command Center fournit une interface unifiée pour tous vos résultats de sécurité et de conformité. |
| Config Sync | Si vous utilisez GKE Enterprise, vous pouvez utiliser Config Sync pour synchroniser vos clusters Kubernetes avec les configurations définies dans un dépôt Git. Le dépôt Git sert de source unique de vérité pour la configuration et les règles de votre cluster. Config Sync vérifie en permanence votre environnement GKE Enterprise pour identifier et corriger les clusters qui diffèrent de la configuration définie dans votre dépôt. |
| Policy Controller | Si vous utilisez GKE Enterprise, vous pouvez utiliser Policy Controller, un contrôleur d'admission dynamique Kubernetes, pour appliquer des règles entièrement programmables pour vos clusters. À l'aide de Policy Controller, vous pouvez empêcher la création d'objets dans vos clusters qui ne respectent pas les exigences de votre stratégie. Par exemple, vous pouvez créer des règles pour appliquer la sécurité des pods. |
Présentation de Chef InSpec
Chef InSpec est un framework de test d'infrastructure Open Source doté d'un langage lisible par l'humain spécifique à un domaine (DSL) qui permet de spécifier des exigences de conformité, de sécurité et de règles.
Avec Chef InSpec, vous pouvez :
- Définir les exigences de conformité sous forme de code et tester votre infrastructure cloud par rapport à ces exigences.
- Permettre aux équipes de développement d'ajouter des tests spécifiques aux applications et d'évaluer la conformité de leurs applications avec les règles de sécurité avant d'appliquer des modifications à l'environnement de production.
- Automatiser la vérification de la conformité dans les pipelines CI/CD et dans le cadre du processus de lancement.
- Tester votre infrastructure Google Cloud de la même manière que vous la testez dans d'autres environnements cloud.
Google Cloud fournit plusieurs ressources pour vous aider à démarrer avec Chef InSpec :
- Le pack de ressources Google Cloud InSpec contient les ressources de référence permettant d'écrire des tests Chef InSpec sur des objets Google Cloud.
- Le profil Google Cloud InSpec CIS contient un ensemble de tests Chef InSpec qui évaluent la stratégie de sécurité de vos projets Google Cloud par rapport au benchmark du CIS (Center for Internet Security).
Bonnes pratiques pour l'utilisation de Chef InSpec avec Google Cloud
Voici les bonnes pratiques générales d'utilisation de Chef InSpec :
- Définissez et adoptez un processus permettant de corriger les violations détectées par vos tests Chef InSpec. Chef InSpec met en évidence les cas de non-respect des stratégies et des exigences de conformité, mais il n'effectue aucune correction.
- Accordez les autorisations IAM appropriées au compte de service que vous utilisez pour exécuter les tests Chef InSpec. Par exemple, si vous testez des buckets Cloud Storage, le compte de service doit disposer des rôles IAM appropriés pour Cloud Storage.
- Configurez les reporters Chef InSpec pour produire des rapports formatés décrivant les tests et les résultats. Vous pouvez stocker ces rapports pour les utiliser comme historique. Vous pouvez également utiliser ces rapports comme entrées dans vos autres outils de sécurité et de conformité. Par exemple, vous pouvez intégrer Chef InSpec et Security Command Center.
- Regroupez les tests Chef InSpec associés dans des profils. Vous pouvez créer différents profils pour différents cas d'utilisation. Par exemple, vous pouvez exécuter un profil complet de bout en bout dans le cadre de vos tests nocturnes planifiés. Vous pouvez également exécuter un profil plus court et plus ciblé en réponse à des événements, en temps réel.
Écrire des tests Chef InSpec
Vous pouvez écrire des tests Chef InSpec à l'aide de Chef InSpec DSL, un DSL Ruby permettant d'écrire des contrôles d'audit.
Le code suivant montre un contrôle permettant de valider les attributs des buckets Cloud Storage :
control 'policy_gcs_bucket' do
title 'Cloud Storage bucket policy'
desc 'Compliance policy checks for Cloud Storage bucket'
impact 'medium'
google_storage_buckets(project: project_id).bucket_names.each do |bucket|
describe "[#{project_id}] Cloud Storage Bucket #{bucket}" do
subject { google_storage_bucket(name: bucket) }
its('storage_class') { should eq 'STANDARD' }
its('location') { should be_in ['EUROPE-WEST2', 'EU'] }
end
end
end
Le contrôle spécifie les informations suivantes :
- Métadonnées décrivant le contrôle.
- Impact ou gravité des défaillances.
- Vérifications de stratégie qui vérifient les attributs de chaque bucket Cloud Storage de votre projet.
Exécuter des tests Chef InSpec avec Cloud Build
Les modèles décrits dans ce document font appel à Cloud Build et à l'image de conteneur de Chef InSpec pour exécuter les tests InSpec. En utilisant Cloud Build, vous pouvez exécuter des images de conteneur et associer les étapes de compilation de manière à former un pipeline. Par exemple, vous pouvez exécuter les tests Chef InSpec dans une étape de compilation, puis exporter ou analyser les rapports générés dans une étape ultérieure. Toutefois, l'utilisation de Cloud Build n'est pas obligatoire. Vous pouvez intégrer Chef InSpec avec les outils que vous utilisez.
Le fichier de configuration Cloud Build suivant montre un pipeline avec deux étapes de compilation :
steps:
- id: 'run-inspec-cis'
name: chef/inspec:latest
entrypoint: '/bin/sh'
args:
- '-c'
- |
inspec exec https://github.com/GoogleCloudPlatform/inspec-gcp-cis-benchmark.git \
--target gcp:// \
--input gcp_project_id=${PROJECT_ID} \
--reporter cli json:/workspace/report.json \
--chef-license accept || touch fail.marker
- id: 'store-report'
name: gcr.io/cloud-builders/gsutil:latest
args:
- cp
- /workspace/report.json
- gs://${_REPORTS_BUCKET}/cis-report-${BUILD_ID}.json
La première étape exécute les tests Google Cloud CIS Benchmark et génère un rapport au format JSON. L'étape de compilation utilise l'image de conteneur chef/inspec et récupère les tests à partir du dépôt GitHub public Google Cloud CIS. La deuxième étape de compilation copie le rapport généré dans un bucket Cloud Storage.
Par souci de simplicité, l'exemple précédent fait référence au tag latest pour toutes les images de conteneur. Pour vous aider à rendre vos compilations reproductibles, nous vous recommandons de référencer une version d'image de conteneur fixe spécifique plutôt qu'une version progressive, telle que latest.
Si l'un des tests échoue, Chef InSpec renvoie une erreur. Au lieu de faire échouer la compilation, la première étape de compilation écrit un fichier fail.marker et la deuxième étape de compilation s'exécute même si l'un des tests Chef InSpec échoue. Si vous souhaitez faire échouer explicitement la compilation pour mettre en évidence les erreurs, vous pouvez rechercher le fichier fail.marker dans une dernière étape de compilation et faire échouer la compilation si le fichier existe.
Analyser les rapports Chef InSpec
Vous pouvez configurer les reporters de Chef InSpec de manière à générer des rapports formatés décrivant les tests et les résultats InSpec. Vous pouvez stocker ces rapports pour les utiliser comme historique. Vous pouvez également utiliser ces rapports comme entrées dans vos autres outils de sécurité et de conformité, ou pour générer des visualisations ou des alertes. Les modèles décrits plus loin dans ce document recommandent de stocker vos rapports Chef InSpec dans un bucket Cloud Storage.
Le schéma suivant montre comment stocker les rapports et déclencher automatiquement une action supplémentaire.
L'ajout du rapport à un bucket Cloud Storage génère un événement. Vous pouvez déclencher une action ou une analyse supplémentaire du rapport en réponse à cet événement. Dans le schéma précédent, vous déclenchez une fonction Cloud Run qui écrit les détails des tests Chef InSpec dans BigQuery, et une autre fonction Cloud Run qui ajoute des résultats dans Security Command Center.
Intégrer Chef InSpec et Security Command Center
Security Command Center est la base de données liée à la sécurité et aux risques pour Google Cloud. Security Command Center offre une visibilité centralisée sur toutes vos ressources Google Cloud et analyse automatiquement vos ressources cloud pour détecter les failles connues. Nous vous recommandons d'activer Security Command Center pour votre organisation.
Vous pouvez ajouter les résultats de vos tests Chef InSpec à Security Command Center. Security Command Center sert de plate-forme de données centralisée pour agréger et gérer les résultats de sécurité provenant de plusieurs sources.
Security Command Center inclut Security Health Analytics (SHA). Security Health Analytics recherche automatiquement les failles courantes dans vos projets et ressources Google Cloud. Par exemple, Security Health Analytics effectue des analyses pour évaluer vos projets par rapport au benchmark CIS Foundation 1.0 de Google Cloud. Vous pouvez également exécuter un ensemble similaire de tests en utilisant le profil Google Cloud InSpec CIS. Vous devez comparer le champ d'application de vos tests Chef InSpec de sorte que les tests ne dupliquent pas les vérifications effectuées par Security Health Analytics.
Il existe plusieurs façons d'ajouter des résultats Chef InSpec à Security Command Center :
- Utilisez Chef Automate pour Security Command Center afin de fournir une intégration automatique des résultats de tests Chef InSpec dans Security Command Center.
- À l'aide de l'API Security Command Center, créez une source personnalisée pour Chef InSpec, puis créez les données pour identifier les violations détectées par vos tests Chef InSpec.
Modèles
Cette section décrit les modèles d'intégration de Chef InSpec dans vos opérations quotidiennes. Vous pouvez combiner ces modèles pour réaliser des tests de conformité continus.
Planifier des tests Chef InSpec
Dans ce modèle, vous exécutez votre ensemble de tests Chef InSpec en suivant un calendrier fixe. Cette approche de planification fixe est un bon moyen de commencer à utiliser Chef InSpec car vous pouvez introduire des tests Chef InSpec sans modifier vos processus existants.
Le schéma suivant montre comment exécuter vos tests en suivant un calendrier défini.
Dans le diagramme précédent, vous créez un job Cloud Scheduler qui s'exécute à la fréquence de votre choix. Chaque fois que votre tâche s'exécute, elle déclenche un pipeline Cloud Build qui exécute vos tests Chef InSpec et génère le rapport de test dans Cloud Storage. Pour en savoir plus, consultez la section Planifier des compilations.
Ce modèle présente les avantages suivants :
- Vous pouvez introduire des tests Chef InSpec en modifiant au minimum vos processus existants.
- Vous pouvez utiliser les tests Chef InSpec indépendamment de tout processus que vous utilisez pour provisionner et gérer votre infrastructure et vos applications.
Ce modèle présente les limites suivantes :
- Les tests Chef InSpec sont dissociés du provisionnement de votre infrastructure, ce qui complique l'attribution de modifications spécifiques pour les tests Chef InSpec en échec.
- Les tests Chef InSpec ne s'exécutent que périodiquement. Il peut donc y avoir un certain délai avant d'identifier les cas de non-conformité ou de non-respect des règles.
Intégration directe avec vos pipelines CI/CD
De nombreuses organisations automatisent le provisionnement et la gestion de leur infrastructure à l'aide d'outils tels que Terraform ou Config Connector. En règle générale, l'infrastructure n'est créée ou modifiée que dans le cadre d'un pipeline CI/CD. Pour plus d'informations sur les concepts CI/CD sur Google Cloud, consultez la page CI/CD moderne avec GKE Enterprise.
Dans ce modèle, vous ajoutez des tests Chef InSpec en tant qu'étapes supplémentaires dans vos pipelines de déploiement d'infrastructure afin de pouvoir valider votre infrastructure chaque fois que vous exécutez votre pipeline de déploiement. Vous pouvez faire échouer la compilation en cas de non-conformité.
Le schéma suivant illustre un workflow courant dans lequel le pipeline de déploiement est déclenché en fonction d'un commit incluant des modifications d'infrastructure.
Dans le diagramme précédent, les modifications d'infrastructure sont appliquées à un environnement de test ou de préproduction, puis les tests Chef InSpec sont exécutés sur cet environnement. Si toutes les vérifications Chef InSpec sont conformes, vous pouvez fusionner et appliquer les modifications d'infrastructure à l'environnement de production. Les tests Chef InSpec sont alors à nouveau exécutés sur l'environnement de production.
Ce modèle présente les avantages suivants :
- Les tests Chef InSpec sont intégrés directement à votre processus de déploiement afin que les violations soient rapidement identifiées.
- Si les tests Chef InSpec ne réussissent pas, vous pouvez explicitement faire échouer le déploiement.
Ce modèle présente les limites suivantes :
- Les tests Chef InSpec sont directement intégrés à vos pipelines de compilation. Par conséquent, l'équipe qui gère votre pipeline de compilation doit comprendre les tests Chef InSpec.
- Si plusieurs compilations nécessitent des tests Chef InSpec, vous devez ajouter des étapes Chef InSpec à chaque compilation, ce qui peut compliquer la gestion et le scaling de vos efforts Chef InSpec.
Intégration indirecte avec vos pipelines CI/CD
Ce modèle est similaire au modèle précédent, mais au lieu d'exécuter directement vos tests Chef InSpec en tant qu'étape de votre pipeline de déploiement, vous exécutez vos tests Chef InSpec dans un pipeline distinct. Ce pipeline distinct est déclenché par vos pipelines de déploiement. Vous pouvez séparer votre logique Chef InSpec de vos pipelines d'infrastructure mais exécuter vos tests de conformité et de stratégie dans le cadre de votre workflow de déploiement.
Cloud Build génère automatiquement des notifications de compilation lorsque l'état de la compilation change, par exemple lors de la création de la compilation, lorsque la compilation passe à un état fonctionnel et lorsque votre compilation se termine. Les messages de notification sont publiés dans un sujet Pub/Sub et contiennent des informations sur la compilation, y compris ses étapes et les arguments associés.
Le schéma suivant montre comment créer une fonction Cloud Run qui est automatiquement déclenchée chaque fois qu'un message est publié dans le sujet Pub/Sub de notification de compilation.
Dans le diagramme précédent, la fonction peut inspecter le message de notification de compilation, puis déclencher votre pipeline Chef InSpec si nécessaire. Par exemple, vous souhaitez uniquement déclencher le pipeline Chef InSpec en réponse à des compilations réussies qui contiennent des étapes de compilation particulières.
Ce modèle présente les avantages suivants :
- Les tests Chef InSpec sont indépendants de vos pipelines de déploiement. Les équipes qui gèrent les pipelines de déploiement n'ont pas besoin d'interagir avec Chef InSpec.
- Vous pouvez centraliser vos tests Chef InSpec ce qui facilite la gestion et le scaling de vos efforts Chef InSpec.
- Vous pouvez exécuter de manière sélective les tests Chef InSpec en fonction des résultats des compilations en amont.
Ce modèle présente les limites suivantes :
- Vous devez écrire et gérer du code pour analyser les messages de notification de compilation afin de déterminer si vous souhaitez exécuter vos tests Chef InSpec et transmettre des paramètres à vos tests Chef InSpec.
- Les notifications Cloud Build sont publiées dans un sujet Pub/Sub dans le même projet. Si vous avez des builds dans plusieurs projets, vous devez déployer la fonction Cloud Run dans chaque projet.
Déclencher des tests Chef InSpec en réponse aux notifications d'inventaire des éléments cloud
L'inventaire des éléments cloud fournit un inventaire de toutes vos ressources Google Cloud. Vous pouvez utiliser l'inventaire des éléments cloud pour rechercher, analyser et exporter les éléments dans vos projets, dossiers et organisations Google Cloud ainsi que leurs métadonnées. Vous pouvez également utiliser l'inventaire des éléments cloud pour envoyer des notifications en temps réel concernant les modifications apportées à vos ressources et stratégies cloud.
Le schéma suivant montre comment exécuter vos tests Chef InSpec sur la base des notifications d'inventaire des éléments cloud.
Le schéma précédent montre comment obtenir des retours quasiment en temps réel sur les ressources cloud nouvelles ou mises à jour qui ne sont pas conformes. Vous pouvez appliquez un filtrage afin de ne recevoir des notifications que pour les modifications apportées à certains types de ressources. Vous pouvez utiliser ces notifications pour déclencher des tests Chef InSpec ciblés spécifiques aux ressources. Par exemple, vous exécutez un ensemble particulier de tests chaque fois qu'un bucket Cloud Storage est créé, et vous exécutez un autre ensemble de tests Chef InSpec lorsqu'une stratégie IAM est mise à jour.
Ce modèle présente les avantages suivants :
- Vous pouvez déclencher des tests Chef InSpec ciblés et spécifiques aux ressources sur la base des modifications apportées à vos ressources cloud.
- Les notifications associées à l'inventaire des éléments cloud sont transmises quasiment en temps réel, ce qui permet de détecter rapidement les cas de non-conformité ou de non-respect des règles.
- Vous pouvez utiliser ce modèle indépendamment de tout processus que vous utilisez pour configurer et gérer votre infrastructure. Les tests Chef InSpec sont exécutés, que l'infrastructure soit créée ou modifiée par un développeur individuel ou par un pipeline CI/CD.
- L'inventaire des éléments cloud peut générer des notifications sur les modifications apportées à vos ressources dans l'ensemble de votre organisation ou pour des dossiers ou projets sélectionnés. Vous pouvez exécuter des ensembles spécifiques de tests Chef InSpec en fonction du dossier ou du projet d'où provient la modification.
- Vous pouvez utiliser ce modèle en parallèle d'autres modèles. Par exemple, de nombreuses organisations ne disposent pas de déploiements automatisés pour leurs environnements de développement ou de bac à sable. Vous pouvez utiliser ce modèle pour effectuer des vérifications de stratégie spécifiques sur ces environnements, tout en intégrant vos pipelines CI/CD pour vos environnements de production et de préproduction.
Ce modèle présente les limites suivantes :
- Ce modèle peut ne pas être pratique s'il y a un grand volume de modifications à apporter à vos ressources cloud, car vos tests Chef InSpec peuvent être déclenchés par chaque modification.
- Vous devez écrire et gérer du code pour analyser les messages de notification d'inventaire des éléments cloud afin de déterminer s'il faut ou non exécuter des tests Chef InSpec.
Étape suivante
- Essayez le tutoriel Cloud Shell pour installer rapidement Chef InSpec dans votre instance Cloud Shell et analyser l'infrastructure de vos projets Google Cloud par rapport au benchmark CIS.
- Visitez le centre de ressources pour la conformité de Google Cloud.
- Consultez le plan de base de l'entreprise.
- Pour découvrir d'autres architectures de référence, schémas et bonnes pratiques, consultez le Centre d'architecture cloud.