IaC Security (Infrastructure as Code Security)

Définition

L'IaC Security (Infrastructure as Code Security) désigne l'ensemble des pratiques et des outils permettant d'analyser statiquement les fichiers de description d'infrastructure — Terraform, CloudFormation, Pulumi, Ansible, Kubernetes ou Helm — afin de détecter les mauvaises configurations avant qu'elles ne soient déployées dans un environnement cloud. Là où l'audit de configuration classique inspecte des ressources déjà en production, l'IaC Security déplace le contrôle vers la gauche de la chaîne de livraison : le défaut est identifié dans une pull request, pas dans un rapport d'incident.

Ce déplacement est une conséquence directe de l'adoption massive de l'infrastructure déclarative. Lorsqu'un fichier de 200 lignes provisionne un VPC, trois sous-réseaux, un cluster managé et une base de données, une erreur unique — un bucket exposé publiquement, un groupe de sécurité ouvert sur 0.0.0.0/0 — se réplique mécaniquement à chaque application du template. Le code d'infrastructure hérite donc des risques du code applicatif, et mérite les mêmes garde-fous.

Fonctionnement technique

Un scanner IaC ne déploie rien et ne se connecte pas au fournisseur cloud. Son fonctionnement repose sur trois étapes :

• Parsing : le fichier HCL, YAML ou JSON est transformé en arbre syntaxique, puis en graphe de ressources. Les scanners modernes résolvent les variables, les modules distants et les interpolations pour éviter les faux négatifs liés aux valeurs indirectes.
• Évaluation des politiques : chaque ressource est confrontée à une bibliothèque de règles. Celles-ci sont soit codées en dur dans l'outil, soit exprimées dans un langage dédié — Rego pour Open Policy Agent, YAML déclaratif pour Checkov, ou requêtes structurées pour KICS.
• Restitution : les résultats sont exportés en SARIF, JSON ou JUnit, formats directement consommables par les plateformes CI/CD et les outils de gestion de vulnérabilités.

Certains outils vont plus loin en analysant le plan Terraform (terraform plan -out converti en JSON) plutôt que le code source. Cette approche capture l'état réellement calculé, y compris les valeurs issues de sources de données dynamiques, au prix d'une exécution plus lourde.

Panorama des outils

• Checkov (Prisma Cloud) : le plus large en couverture, plus de 1 000 politiques natives, support Terraform, CloudFormation, Kubernetes, Dockerfile, Serverless et ARM. Extensible en Python ou en YAML.
• tfsec (Aqua Security) : centré sur Terraform, extrêmement rapide, désormais fusionné dans Trivy dont il constitue le module de configuration.
• KICS (Checkmarx) : couverture multi-formats très étendue, règles écrites en Rego, forte adoption dans les environnements réglementés.
• Terrascan (Tenable) : approche policy-as-code fondée sur OPA, avec un mode serveur d'admission pour Kubernetes.
• OPA / Conftest : moteur générique permettant d'écrire ses propres politiques métier, au-delà des référentiels standards.

Exemples concrets

Trois classes de défauts reviennent systématiquement dans les rapports de scan :

• Exposition réseau : une règle ingress autorisant le port 22 ou 3389 depuis 0.0.0.0/0, ou un aws_db_instance avec publicly_accessible = true.
• Chiffrement absent : volumes EBS sans encrypted = true, bucket S3 sans configuration de chiffrement côté serveur, cluster managé sans chiffrement des secrets etcd.
• Privilèges excessifs : une politique IAM contenant "Action": "*" sur "Resource": "*", ou un conteneur Kubernetes avec privileged: true et hostNetwork: true.

S'ajoute un risque spécifique souvent sous-estimé : les secrets en clair dans les variables Terraform ou, plus insidieusement, dans le fichier d'état terraform.tfstate, qui stocke les valeurs sensibles sans chiffrement par défaut. Un état déposé sur un bucket mal configuré équivaut à une fuite de credentials complète.

Liens avec d'autres concepts

L'IaC Security s'inscrit dans le continuum du Shift Left Security et constitue l'un des piliers du DevSecOps. Elle est complémentaire — et non substituable — au CSPM (Cloud Security Posture Management) : le scanner IaC prévient l'introduction du défaut, le CSPM détecte la dérive de configuration introduite par des modifications manuelles hors pipeline. Les plateformes CNAPP unifient aujourd'hui ces deux vues, en corrélant une alerte runtime avec la ligne de code qui l'a produite.

Sur le plan méthodologique, l'IaC Security matérialise le principe du moindre privilège et alimente les exigences de traçabilité de l'ISO 27001 (A.8.9, gestion des configurations) comme celles de NIS 2 sur la sécurisation de l'acquisition et du développement des systèmes.

Bonnes pratiques

• Bloquer plutôt qu'alerter : configurer le scan en pre-commit hook et en quality gate CI avec échec du build sur les sévérités haute et critique.
• Traiter les faux positifs comme de la dette : documenter chaque exception via les annotations natives (#checkov:skip=CKV_AWS_20:justification) plutôt que de désactiver globalement une règle.
• Standardiser par des modules durcis : un module Terraform interne validé et versionné supprime des dizaines de défauts en amont, bien plus efficacement que la correction unitaire.
• Chiffrer et verrouiller l'état : backend distant, chiffrement au repos, verrouillage par DynamoDB ou équivalent, accès restreint.
• Écrire des politiques métier : au-delà des règles génériques, imposer le tagging obligatoire, les régions autorisées ou l'interdiction de certains types d'instance via OPA.
• Mesurer la couverture : suivre le pourcentage de dépôts scannés et le délai moyen de remédiation, seuls indicateurs réellement révélateurs de la maturité du dispositif.