Analyse de sécurité de l’infrastructure sous forme de code

Les outils d’infrastructure en tant que code (IaC) comme Terraform, AWS CloudFormation, Ansible et Helm permettent de définir l’infrastructure dans des fichiers de configuration gérés par un système de contrôle de version. Cela apporte d’immenses avantages — reproductibilité, auditabilité et automatisation — mais aussi un risque de sécurité critique : les erreurs de configuration dans les fichiers IaC produisent une infrastructure non sécurisée à grande échelle. Un seul module Terraform mal configuré et déployé dans 50 environnements crée simultanément 50 systèmes vulnérables. L’analyse de sécurité IaC remédie à ce problème en vérifiant les fichiers de configuration avant leur application, ce qui déplace la sécurité en amont, dans le flux de travail des développeurs.

Les outils d’analyse de sécurité recherchent les erreurs de configuration IaC les plus courantes observées dans les environnements cloud réels : des compartiments S3 dont l’accès public est activé ou qui ne sont pas chiffrés au repos ; des groupes de sécurité comportant des règles entrantes 0.0.0.0/0 sur des ports sensibles (22, 3389, 1433) ; des bases de données dépourvues de chiffrement ou accessibles publiquement ; des politiques IAM utilisant des caractères génériques * pour les ressources ou les actions ; CloudTrail désactivé dans une région ; des clés KMS sans rotation des clés ; et des équilibreurs de charge utilisant des écouteurs HTTP au lieu de HTTPS. Ces résultats correspondent étroitement aux vérifications effectuées par des référentiels de sécurité cloud comme CIS AWS Foundations.

Checkov (développé par Bridgecrew/Prisma Cloud) est un outil populaire d’analyse statique open source pour l’IaC qui prend en charge Terraform, CloudFormation, les manifestes Kubernetes, les graphiques Helm et les fichiers Dockerfile. Il fournit plus de 1 000 politiques intégrées, associées aux référentiels CIS, au GDPR, à SOC 2 et à HIPAA. L’exécution de checkov -d . analyse tous les fichiers IaC du répertoire actuel et produit un rapport à code couleur indiquant les vérifications réussies, échouées et ignorées, avec les chemins des ressources et des conseils de correction. Checkov peut être intégré aux chaînes CI/CD afin de bloquer les déploiements lorsque des vérifications CRITICAL échouent.

tfsec (qui fait désormais partie de la fonctionnalité d’analyse IaC de Trivy) est un analyseur de sécurité spécialement conçu pour Terraform. Il comprend en profondeur la syntaxe HCL, ce qui lui permet de suivre les valeurs entre les modules et les fichiers de variables. Contrairement aux analyseurs plus simples, tfsec peut détecter des erreurs de configuration lorsque le problème s’étend sur plusieurs fichiers — par exemple, une règle de groupe de sécurité qui semble sûre lorsqu’elle est examinée isolément, mais qui est associée à une ressource définie dans un autre fichier. tfsec produit des résultats avec des niveaux de gravité (CRITICAL, HIGH, MEDIUM, LOW), des identifiants CWE et des liens directs vers la documentation de correction, afin de permettre aux développeurs d’agir concrètement sur ces résultats.

L’un des problèmes de sécurité IaC les plus CRITICAL est la présence de secrets codés en dur dans les fichiers de configuration : mots de passe, clés d’API, clés privées TLS et chaînes de connexion aux bases de données envoyés dans Git. Comme les dépôts IaC sont souvent partagés entre plusieurs équipes et conservés dans l’historique du contrôle de version, un secret envoyé ne serait-ce qu’une seule fois est en pratique compromis de manière permanente (l’historique Git est immuable). Des outils comme Checkov, detect-secrets, git-secrets et TruffleHog recherchent les motifs correspondant à des secrets. La solution consiste à utiliser des variables d’entrée provenant de variables d’environnement ou de coffres de secrets, et à ne jamais coder de valeurs en dur.

Les frameworks de Policy as Code (PaC) permettent aux équipes de sécurité d’écrire des règles personnalisées sous forme de code et de les appliquer de manière cohérente. Open Policy Agent (OPA) avec Conftest permet d’écrire des politiques Rego qui valident n’importe quelles données structurées — plans Terraform, manifestes Kubernetes, valeurs Helm — dans les chaînes CI/CD. HashiCorp Sentinel est intégré à Terraform Enterprise et Cloud et permet d’appliquer au moment de la planification des politiques telles que « tous les compartiments S3 doivent avoir le chiffrement activé », en bloquant toute application qui enfreindrait la politique. Ces outils permettent de formaliser les exigences de sécurité sous forme de code et de les gérer avec un contrôle de version, au même titre que l’infrastructure qu’elles régissent.

Une dérive de configuration se produit lorsque l’état réel de l’infrastructure déployée s’écarte de la définition IaC, souvent parce qu’une personne a effectué une modification manuelle dans la console cloud. Une règle de groupe de sécurité ajoutée manuellement pour débloquer « temporairement » un développeur devient une faille permanente. Les outils de détection de dérive comparent en continu l’état souhaité (les fichiers IaC) à l’état réellement déployé et signalent les écarts. AWS Config, la détection de dérive de Terraform Cloud et les outils CSPM (Prisma Cloud, Wiz) proposent tous cette fonctionnalité. Les erreurs de configuration de sécurité introduites par des modifications dans la console sont ainsi détectées avant que les attaquants ne les découvrent.

Une infrastructure immuable signifie que les serveurs et les configurations ne sont jamais modifiés sur place : les changements créent plutôt de nouvelles ressources (de nouvelles AMI ou images de conteneurs) qui remplacent les anciennes. Associée à GitOps (où toutes les modifications de l’infrastructure doivent passer par une demande de fusion Git, ce qui déclenche les processus d’analyse IaC et d’approbation), cette approche élimine par construction la dérive de configuration : si quelque chose ne peut pas être modifié manuellement, cela ne peut pas dériver. Des outils comme ArgoCD pour Kubernetes et Atlantis pour Terraform mettent en œuvre des processus GitOps dans lesquels tout écart déclenche une réconciliation ou une alerte automatique.

L’analyse de sécurité IaC est parfois confondue avec le SAST (Static Application Security Testing), mais ces deux approches ciblent des artefacts différents. Le SAST analyse le code source des applications (Python, Java, JavaScript) à la recherche de vulnérabilités telles que les injections SQL ou les dépassements de tampon. L’analyse IaC examine les fichiers de configuration de l’infrastructure à la recherche d’erreurs de configuration de sécurité cloud : aucun code applicatif n’est concerné. Une chaîne DevSecOps complète inclut les deux : le SAST sur le code applicatif et l’analyse IaC sur les fichiers d’infrastructure. Les deux s’exécutent dans la chaîne CI/CD avant tout déploiement. Certaines plateformes unifiées (Snyk IaC, Prisma Cloud) combinent l’analyse des applications et celle de l’infrastructure dans un seul outil.

Une analyse de sécurité IaC efficace doit être automatisée et obligatoire, et non facultative. Une intégration CI/CD classique consiste à exécuter Checkov et tfsec à chaque demande de fusion ; à faire échouer la chaîne si des résultats CRITICAL sont présents ; à publier les résultats sous forme de commentaires dans la demande de fusion pour informer les développeurs ; à tenir à jour une liste des résultats supprimés, accompagnés de justifications documentées ; et à effectuer chaque nuit une analyse des ressources déployées afin de détecter les dérives. Des crochets de prévalidation utilisant des outils comme pre-commit avec Checkov peuvent détecter les problèmes avant même que le code n’atteigne la chaîne. Il est important de gérer les faux positifs : les développeurs qui voient trop de résultats sans pertinence finissent par les ignorer.

Le fichier d’état de Terraform (terraform.tfstate) contient l’inventaire complet de toutes les ressources gérées et inclut souvent en clair des valeurs de sortie sensibles, telles que des mots de passe de bases de données, des clés privées TLS et des identifiants de clés d’accès IAM. Les fichiers d’état ne doivent jamais être envoyés dans Git. Utilisez plutôt un backend distant (AWS S3 avec verrouillage DynamoDB, Terraform Cloud ou un état géré par GitLab) avec le chiffrement côté serveur activé. L’accès au backend d’état doit être strictement contrôlé via IAM : toute personne pouvant lire le fichier d’état peut inventorier tous les détails de l’infrastructure et potentiellement extraire les secrets qu’il contient.

Vérifiez votre compréhension des concepts de CompTIA Security+ (SY0-701) abordés dans cette leçon.

Dans cette leçon, vous avez appris que les erreurs de configuration IaC, telles que les compartiments S3 publics, les groupes de sécurité ouverts et les secrets codés en dur, sont automatiquement détectées par des outils comme Checkov et tfsec avant le déploiement ; que les frameworks de politiques sous forme de code (OPA/Conftest, HashiCorp Sentinel) permettent d’imposer les exigences de sécurité personnalisées d’une organisation au moyen de contrôles automatisés dans la chaîne ; et que les fichiers d’état Terraform doivent être stockés dans des backends distants chiffrés avec des contrôles d’accès stricts, car ils peuvent contenir des informations sensibles sur les ressources. Nous allons maintenant étudier le cycle de vie des APT et la manière dont les menaces avancées persistent dans les réseaux.