L'infrastructure en tant que code (IaC) s'est rapidement imposée comme un élément révolutionnaire dans le paysage technologique moderne. En traduisant les processus de provisionnement et de gestion de l'infrastructure en code, les développeurs bénéficient d'un contrôle des versions et d'une répétabilité, et les vulnérabilités potentielles sont réduites. Cependant, sa prolifération s'accompagne de problèmes de vulnérabilité potentiels.
GitLab IaC Scanning se distingue comme un moyen efficace et efficient de détecter les erreurs de configuration et les failles de sécurité dans les configurations IaC tout en les protégeant. Ce guide explore en détail son intérêt, son processus de configuration et les meilleures pratiques pour renforcer les configurations IaC.
Qu'est-ce que l'infrastructure en tant que code (IaC) ?
L'infrastructure en tant que code (IaC) est une approche dans laquelle les tâches de provisionnement, de gestion et de configuration de l'infrastructure sont spécifiées sous forme de code plutôt que par des processus manuels ou des scripts personnalisés. Au lieu de dépendre de processus manuels pour le provisionnement des serveurs, des bases de données ou des composants d'infrastructure réseau, l'IaC utilise des modèles de code standard.
La popularité de l'IaC s'explique par un besoin toujours croissant d'agilité lors du déploiement et de la mise à l'échelle des applications. La gestion traditionnelle des infrastructures nécessitait une configuration fastidieuse qui dépendait souvent d'erreurs humaines. L'IaC offre des processus cohérents, reproductibles et rapides de mise à jour en versionnant les infrastructures comme le code logiciel, ce qui permet d'exécuter en continu des constructions d'infrastructures versionnées et reproductibles sans supervision humaine ni erreur.
Les pratiques DevOps sont également en synergie avec les pratiques IaC, aidant les organisations à combler le fossé entre le développement et les opérations. Avec IaC, les changements d'infrastructure peuvent être mis en œuvre simultanément avec le développement d'applications pour des délais de déploiement plus courts et une gestion plus fluide du pipeline. Leurs efforts combinés permettent aux organisations d'améliorer leur efficacité et leur fiabilité lors des processus de déploiement.
Pourquoi le scan IaC est-il essentiel ?
L'infrastructure en tant que code a ouvert de nouvelles voies de vulnérabilité potentielle. Les développeurs qui écrivent des scripts pour automatiser le déploiement de l'infrastructure peuvent involontairement introduire d'importantes failles de sécurité dans le processus de déploiement de l'infrastructure ; le scan IaC devient essentiel pour détecter ces failles de sécurité avant qu'elles n'atteignent les environnements de production.
Les infrastructures cloud natives modernes peuvent être des environnements très dynamiques et complexes ; même les développeurs les plus vigilants peuvent laisser passer des erreurs de configuration, même sans outils de scan IaC qui passent au crible les définitions de code pour détecter les erreurs de configuration qui enfreignent les meilleures pratiques de sécurité et réduisent les violations de données et compromettent le système en raison des vulnérabilités de l'infrastructure. Les outils d'analyse IaC utilisent la technologie Artificial Intelligence-as-a-Consumption (AIC). Ce faisant, ils réduisent considérablement les risques liés aux vulnérabilités de l'infrastructure qui causent des violations de données ou compromettent le système.
Les normes de conformité et de protection des données étant devenues plus strictes, les entreprises doivent mettre en place une infrastructure sécurisée dès le premier jour afin d'éviter des conséquences juridiques ou réputationnelles. L'analyse IaC aide les entreprises à respecter cette norme en garantissant que leur infrastructure est conforme aux réglementations du secteur, les protégeant ainsi contre les répercussions juridiques.
Comprendre l'analyse IaC de GitLab
La fonctionnalité d'analyse Infrastructure as Code (IaC) de GitLabamp;#8217;s Infrastructure as Code (IaC) Scanning offre une approche systématique pour vérifier les fichiers de configuration IaC afin de détecter les vulnérabilités potentielles. Cela garantit que les configurations pour provisionner et gérer l'infrastructure sont robustes, sécurisées et conformes. La prise en charge s'étend à divers fichiers de configuration IaC, y compris les plus populaires tels que Terraform, Ansible, AWS CloudFormation et Kubernetes.
- Exigences et compatibilité
- Fichiers pris en charge et personnalisation
- Personnalisation de la configuration et des règles
- Résolution automatique des vulnérabilités
1. Exigences et compatibilité
Pour être efficace, le scanning IaC nécessite de travailler dans la phase de test, car il doit être inclus dans le fichier .gitlab-ci.yml de cette phase.
- La mémoire RAM minimale requise doit être de 4 Go pour optimiser les performances.
- Par défaut, GitLab Runner avec l'exécuteur Docker ou Kubernetes est obligatoire (et activé automatiquement pour les utilisateurs de GitLab.com). Cependant, les analyseurs IaC Scanning peuvent être incompatibles avec les architectures CPU non amd64. Il est donc recommandé d'éviter la version 19.03.0 de Docker pour ces tâches.
2. Fichiers pris en charge et personnalisation
GitLab IaC Scanning offre une prise en charge complète, rendue possible grâce à l'outil KICS. Les fichiers de configuration provenant d'Ansible, AWS CloudFormation, Azure Resource Manager Dockerfile, Google Deployment Manager Kubernetes OpenAPI Terraform font partie des fichiers pris en charge ; toute exigence spécifique, telle que les modèles Azure Resource Manager au format JSON, et l'absence de prise en charge des modules Terraform de registre personnalisés, doit également être prise en compte lors de l'examen des résultats.
GitLab poursuit son engagement en faveur de l'ouverture avec cette fonctionnalité en mettant tous les analyseurs open source (OSS) à disposition via GitLab Free tier. En manipulant la variable SAST_IMAGE_SUFFIX, vous pouvez basculer entre les versions standard et FIPS des images.
3. Configuration et personnalisation des règles
La mise en place de l'analyse IaC dans votre projet est relativement simple. Vous pouvez le configurer manuellement en incluant le modèle SAST-IaC.gitlab-ci.yml qui, une fois inclus, génère des tâches d'analyse IaC dans votre pipeline CI/CD, ou automatiquement via des demandes de fusion. Les résultats des tâches d'analyse IaC sont stockés sous forme d'artefacts de rapport SAST une fois l'analyse terminée.
Les équipes qui souhaitent améliorer le processus d'analyse ont la possibilité de personnaliser les règles par défaut. Cette fonctionnalité permet notamment :
- De désactiver les règles prédéfinies.
- Remplacer les règles existantes par des définitions personnalisées qui affectent des aspects tels que la gravité ou la liaison directe à la documentation personnelle.
Il est également possible d'associer les processus d'analyse à des versions spécifiques de l'analyseur, afin de se protéger en cas de régressions ou de modifications indésirables suite à des mises à jour.
4. Résolution automatique des vulnérabilités
GitLab IaC Scanning met l'accent sur l'élimination des informations superflues dans les rapports. Afin de maintenir la pertinence et de se concentrer sur les vulnérabilités actuelles, le système prend certaines mesures automatiques :
1. Désactivation des règles : une fois que vous avez décidé qu'une ou plusieurs règles ne sont plus pertinentes pour votre projet et que vous les avez explicitement désactivées, leurs rapports de vulnérabilités précédents seront automatiquement résolus.
2. Suppression de règles : si GitLab décide qu'une ou plusieurs règles par défaut sont obsolètes ou produisent trop de faux positifs, elles seront probablement supprimées, et toutes les vulnérabilités signalées par ces règles seront automatiquement résolues.
3. Historique : il est essentiel de conserver une piste d'audit ; le système de gestion des vulnérabilités de GitLab ajoute des commentaires, vous permettant ainsi de rester informé des vulnérabilités passées qui ont été automatisées et résolues.
4. Réactivation des règles : la réactivation des règles précédemment désactivées permettra de rouvrir tous les résultats résolus automatiquement pour triage afin de s'assurer que les vulnérabilités passées ne passent pas inaperçues.
Rapports : comprendre le format JSON
L'outil d'analyse IaC de GitLab génère des rapports JSON structurés conformes aux formats de rapport SAST, fournissant ainsi aux utilisateurs des résultats complets :
1. Normalisation : Ce format facilite l'intégration et la comparaison entre différents projets ou analyses.
2. Accessibilité : les utilisateurs peuvent télécharger rapidement et facilement des rapports directement à partir des pages des pipelines CI ou fusionner des pipelines de requêtes à l'aide de la directive artifacts: paths vers " gl-sast-report.json ". Pour faciliter cette action, définissez votre directive artifacts: paths comme " gl-sast-report.json ".
3. Référence du schéma : GitLab propose une documentation détaillée sur le schéma afin de permettre aux personnes souhaitant approfondir leurs connaissances ou intégrer ce rapport à d'autres systèmes d'y accéder facilement et de manière exhaustive.
Configuration de GitLab IaC Scanning
Voyons comment configurer GitLab IaC Scanning pour vos projets.
Les étapes de configuration de GitLab IaC Scanning sont les suivantes : –
- Prérequis
- Intégration de GitLab CI/CD
- Configuration personnalisée (facultative)
- Exécution de l'analyse
- Examen des résultats
1. Conditions préalables
- Version GitLab : Vous devez vous assurer que vous utilisez la version 12.10 ou une version ultérieure de GitLab.
- Configuration du référentiel : vos fichiers Infrastructure as Code (tels que les fichiers de configuration Terraform, CloudFormation et Kubernetes) doivent faire partie de votre référentiel.
2. Intégration de GitLab CI/CD
Pour configurer l'analyse IaC, vous devez l'intégrer au pipeline GitLab CI/CD.
Créez ou mettez à jour le fichier .gitlab-ci.yml à la racine de votre référentiel.
Ajoutez la configuration suivante :
Include:
template: Security/Infrastructure-Scanning.gitlab-ci.yml
Cette inclusion activera la tâche IaC Scanning dans votre pipeline CI/CD.
3. Configuration personnalisée (facultative)
Pour les projets ayant des exigences spécifiques, le processus d'analyse peut être personnalisé :
- Règles personnalisées : GitLab IaC Scanning permet aux utilisateurs de définir des règles personnalisées ou de modifier celles qui existent déjà. Celles-ci peuvent être ajoutées à un répertoire .iac-custom-rules à la racine de votre référentiel.
- Ignorer des répertoires : si vous souhaitez que le scanner ignore certains répertoires, vous pouvez les définir dans la configuration CI/CD sous variables :
Variables :
IAC_PATHS : " infrastructure/*,!infrastructure/legacy/ "
Dans l'exemple ci-dessus, le scanner analysera uniquement les fichiers du répertoire infrastructure et exclura le sous-répertoire legacy.
4. Exécution de l'analyse
Une fois la configuration définie, lancez l'exécution du pipeline CI/CD. La tâche d'analyse IaC analysera vos fichiers Infrastructure as Code et fournira des informations sur les vulnérabilités potentielles.
5. Examen des résultats
Après l'analyse, les vulnérabilités (le cas échéant) seront visibles :
- Dans la demande de fusion (si l'analyse a été déclenchée par une telle demande).
- Dans la section Sécurité et conformité de votre projet.
Ici, vous pouvez :
- Consulter les détails de la vulnérabilité.
- La marquer comme résolue ou créer un ticket pour la suivre.
- En option, configurer des actions automatisées en fonction de la gravité ou du type de vulnérabilité.
Meilleures pratiques pour une configuration IaC (Infrastructure as Code) sécurisée
Les meilleures pratiques pour une configuration IaC (Infrastructure as Code) sécurisée sont les suivantes –
- Principe PoLP (principe du moindre privilège)
- Maintenir le contrôle des versions et le suivi des modifications
- Analyser et mettre à jour régulièrement les dépendances
- Protéger les secrets
- Valider et évaluer efficacement les configurations
1. Principe PoLP (principe du moindre privilège)
Le principe du moindre privilège est un concept de sécurité essentiel conçu pour garantir que les entités (qu'il s'agisse d'utilisateurs, de systèmes ou de processus) ne reçoivent que les privilèges nécessaires à l'exécution de leurs tâches, et rien de plus. Ce principe devient encore plus essentiel dans les environnements IaC où les autorisations peuvent être attribuées par programmation ; lorsqu'elles sont attribuées de manière incorrecte ou trop large, elles peuvent exposer les ressources à des risques inutiles.
Le respect des exigences du PoLP dans le cadre de l'IaC nécessite une rédaction minutieuse des autorisations afin que chaque service ou fonction n'accède qu'aux ressources dont il a besoin – pour les infrastructures cloud telles qu'AWS, cela peut impliquer d'accorder une autorisation en lecture seule pour le compartiment S3 plutôt qu'une autorisation générale pour toutes les ressources de stockage ; une révision continue des scripts IaC afin de s'assurer que les autorisations restent strictes à mesure que l'infrastructure évolue.
2. Maintenir le contrôle des versions et le suivi des modifications
Le contrôle des versions n'est pas seulement nécessaire dans le développement logiciel traditionnel ; il joue également un rôle essentiel dans la gestion de l'infrastructure dans un environnement IaC. Le suivi des modifications, la restauration des configurations et la compréhension des ajustements de l'infrastructure sont essentiels pour maintenir un environnement sûr et stable pour la gestion de l'infrastructure IaC.
Les plateformes GitLab et GitHub pour la configuration IaC fournissent non seulement des outils de suivi des modifications, mais aussi des fonctionnalités collaboratives permettant d'examiner les modifications proposées avec les membres de l'équipe avant leur déploiement dans les environnements de production. Ce processus d'examen par les pairs garantit la prise en compte des questions de sécurité et la conformité aux meilleures pratiques avant toute modification importante dans les environnements IaC.
3. Analyse et mise à jour régulières des dépendances
Comme pour le développement de logiciels, les configurations d'infrastructure en tant que code (IaC) s'appuient souvent sur des modèles et des modules tiers afin de rationaliser le déploiement de l'infrastructure. Si ces dépendances peuvent simplifier le déploiement, elles présentent également des vulnérabilités potentielles si elles sont obsolètes ou compromises.
L'analyse constante des dépendances permet de s'assurer qu'aucune vulnérabilité de sécurité connue n'est introduite dans l'infrastructure. Des outils spéciaux conçus à cet effet signalent automatiquement les modules obsolètes ou vulnérables et invitent les équipes à les mettre à jour si nécessaire, un peu comme la gestion des correctifs logicielspatch management, mais appliquée spécifiquement aux modules d'infrastructure afin d'obtenir une protection et une résilience maximales.
4. Protéger les secrets
Le paysage numérique regorge d'histoires alarmantes sur des secrets exposés qui ont conduit à de graves violations. La nature programmatique de l'IaC incite les programmeurs à coder en dur des informations sensibles directement dans les scripts, une pratique irresponsable qui doit toujours être évitée.
Les organisations doivent éviter d'intégrer des secrets directement dans les scripts IaC. Elles doivent plutôt utiliser des solutions dédiées à la gestion des secrets, telles que HashiCorp Vault ou AWS Secrets Manager, afin de protéger les secrets tout en les conservant cryptés, garantissant ainsi leur protection même si les fichiers de configuration sont rendus publics.
5. Valider et évaluer efficacement les configurations
S'assurer que les scripts IaC sont à la fois fonctionnels et sécurisés est un effort constant qui nécessite une évaluation régulière. À mesure que les configurations changent ou que le paysage informatique évolue, de nouvelles vulnérabilités apparaissent, qui peuvent rendre les scripts auparavant fonctionnels inopérants ou les endommager complètement.
Pour éviter ce scénario, les organisations doivent s'assurer que leurs configurations IaC sont régulièrement conformes aux normes et aux meilleures pratiques du secteur, en utilisant des outils de test automatisés pour effectuer des vérifications régulières sans intervention manuelle. Avant de déployer des changements dans les environnements de production, les environnements de test ou de préproduction sont précieux pour détecter rapidement tout problème inattendu, ce qui permet de garantir la sécurité et le bon fonctionnement des infrastructures dans les environnements de production.
Pièges courants dans l'IaC et comment les éviter
Pièges courants dans l'analyse IaC de GitLab et comment les éviter ?
- Traiter le code d'infrastructure comme un script ponctuel
- Négliger les tests
- Codage en dur des secrets et des identifiants
- Complication excessive des scripts IaC
- Contournement des outils ou bibliothèques obsolètes
1. Considérer le code d'infrastructure comme un script ponctuel
Une idée fausse courante concernant le code d'infrastructure (IaC) consiste à le considérer comme un script ponctuel écrit une seule fois et rarement révisé. Contrairement aux scripts ponctuels, l'IaC nécessite toutefois des mises à jour, des révisions et des modifications périodiques, comme tout code logiciel.
Comment éviter cela : effectuez régulièrement des révisions et des mises à jour du code à l'aide d'outils tels que GitLab IaC Scanning pour analyser en continu les configurations IaC. Cela garantit que votre code reste à jour, pertinent et exempt de vulnérabilités potentielles.
2. Négligence des tests
Certaines équipes pressées de déployer peuvent négliger de tester minutieusement les scripts IaC afin d'avancer rapidement, estimant que si quelque chose fonctionne, tout va bien. Cela peut entraîner des comportements inattendus ou des vulnérabilités de sécurité dans leur infrastructure provisionnée. Cette négligence peut entraîner des comportements inattendus ou créer des failles de sécurité nécessitant des correctifs immédiats lors du déploiement.
Comment éviter cela : comme pour le code des applications, il est essentiel de tester les configurations IaC dans des environnements hors production, tels que les environnements de test, afin d'éviter les erreurs de configuration et les pièges potentiels dans l'environnement de production. GitLab IaC Scanning fournit ici un service essentiel qui permet aux équipes d'identifier toute erreur de configuration avant qu'elle n'ait un impact direct sur les environnements de production.
3. Secrets et identifiants codés en dur
Le codage en dur peut constituer un piège évident dans les scripts IaC et doit toujours être évité afin de protéger la sécurité des données. En intégrant des secrets ou des identifiants directement dans leur code, les secrets ou identifiants codés en dur peuvent constituer des menaces de sécurité importantes qui ne doivent pas être négligées.
Comment prévenir : au lieu d'inclure directement des secrets dans les scripts, utilisez des outils de gestion des secrets dédiés. Les outils d'analyse IaC de GitLab peuvent détecter ces pratiques en les recherchant dans le cadre de leur processus d'analyse, par exemple en alertant les développeurs de la présence d'informations d'identification codées en dur dans leurs fichiers de configuration.
4. Scripts IaC trop complexes
En essayant de créer une solution unique couvrant tous les scénarios possibles, certains ingénieurs compliquent excessivement la rédaction des scripts IaC. Si cela permet de couvrir plus efficacement diverses situations, cela crée également des complications inutiles et des points de défaillance potentiels dans leurs solutions IaC.
Comment éviter cela : privilégiez la simplicité et la clarté en divisant les configurations complexes en modules gérables à l'aide de GitLab IaC Scanning ; inspectez régulièrement ces modules à l'aide de GitLab IaC Scanning afin qu'ils restent efficaces, sécurisés et fonctionnels.
5. Contourner les outils ou bibliothèques obsolètes
L'IaC s'appuie souvent sur des outils ou des bibliothèques tiers ; cependant, à mesure que ces ressources externes évoluent, certaines fonctionnalités ou fonctions peuvent devenir obsolètes. L'utilisation de méthodes obsolètes peut présenter des vulnérabilités tant sur le plan fonctionnel que sur celui de la sécurité.
Comment prévenir : surveillez activement les outils ou bibliothèques tiers dont dépendent vos configurations IaC, mettez régulièrement à jour les scripts afin de refléter les versions et recommandations actualisées, et utilisez des outils d'analyse tels que GitLab IaC Scanning qui mettent en évidence les fonctions ou dépendances obsolètes.
Voir SentinelOne en action
Découvrez comment la sécurité du cloud alimentée par l'IA peut protéger votre organisation lors d'une démonstration individuelle avec un expert produit de SentinelOne.
Obtenir une démonstrationConclusion
Le scan IaC de GitLab permet de détecter les failles de sécurité et de gérer les dépendances. Vous pouvez éliminer les faux positifs, définir des règles personnalisées et conserver des pistes d'audit. Il facilite également la création de rapports et vous pouvez facilement intégrer le scan IaC de GitLab à votre pipeline CI/CD pour obtenir les meilleurs résultats. Protégez vos secrets, maintenez le contrôle des versions et le suivi des modifications, et appliquez le principe du moindre privilège d'accès avec le scanner IaC de GitLab. Il vous aidera à évaluer et à gérer efficacement vos configurations pour une gestion fluide de votre infrastructure.
"FAQ sur l'analyse IaC GitLab
GitLab IaC Scanning est une fonctionnalité CI/CD intégrée qui examine vos fichiers Infrastructure as Code (tels que Terraform, CloudFormation, Ansible, Dockerfiles et Kubernetes manifests) afin de détecter les erreurs de configuration et les vulnérabilités connues. Il s'exécute pendant la phase de test de votre pipeline, génère des rapports SAST au format JSON et met en évidence les problèmes dans les demandes de fusion afin que vous puissiez corriger les paramètres à risque avant le déploiement.
L'analyse IaC a fait son apparition dans GitLab 14.5, sorti en juin 2021. À partir de cette version, tous les fichiers de configuration IaC pris en charge dans un projet déclenchent automatiquement les analyseurs KICS appropriés pendant les pipelines CI, à condition que vous incluiez le modèle IaC dans votre .gitlab-ci.yml
L'analyse IaC de GitLab prend en charge un large éventail de fichiers de configuration, tous optimisés par KICS :
- Playbooks Ansible
- AWS CloudFormation (YAML/JSON)
- Azure Resource Manager (JSON)
- Fichiers Docker
- Google Deployment Manager
- Manifestes Kubernetes
- Définitions OpenAPI
Terraform HCLSi vous utilisez Bicep, compilez en JSON avant l'analyse et notez que les modules Terraform du registre personnalisé ne sont pas encore analysés .
Tous les analyseurs de scan IaC dans GitLab s'appuient sur KICS (Keep It Configuration Scanner), un moteur open source qui vérifie vos fichiers IaC par rapport à un ensemble complet de règles. KICS détecte automatiquement les formats pris en charge et applique les vérifications appropriées. Vous pouvez personnaliser, désactiver ou épingler des versions de règles via des variables CI ou des répertoires de règles personnalisés.
Pour activer l'analyse IaC, ajoutez le modèle officiel en haut du fichier .gitlab-ci.yml de votre projet :
ajoutez la ligne suivante :
- template: Jobs/SAST-IaC.gitlab-ci.yml
Cela injecte une tâche iacs dans la phase de test. Sur GitLab.com ou en gestion autonome avec des runners partagés, aucune configuration supplémentaire du runner n'est nécessaire. Une fois le pipeline exécuté, les résultats de l'analyse apparaissent sous forme d'artefacts de tâche, dans les demandes de fusion et sous Sécurité et conformité .