Cauchemars avec Terraform : comment une IaC mal configurée peut tout exposer

L’Infrastructure as Code (IaC) a révolutionné la façon dont les équipes de développement déploient et gèrent les ressources cloud. Des outils comme Terraform et AWS CloudFormation permettent aux ingénieurs de définir toute une infrastructure via du code déclaratif, rendant les déploiements reproductibles, versionnés, et potentiellement plus sécurisés. Mais il existe un paradoxe dangereux au cœur de l’IaC : la même automatisation qui facilite la gestion de l’infrastructure peut aussi reproduire systématiquement des vulnérabilités de sécurité dans chaque environnement que vous gérez.

Une seule ligne mal configurée dans un fichier Terraform peut exposer des bases de données à Internet, accorder des permissions excessives, ou créer des buckets de stockage accessibles à tous via l’URL. Contrairement aux erreurs de configuration manuelles qui affectent une ressource à la fois, les erreurs d’IaC codifient des vulnérabilités dans l’ADN de votre infrastructure, les propageant automatiquement dans les environnements de développement, staging et production à chaque exécution de terraform apply.

L’ampleur du problème de sécurité de l’IaC

Les analystes du secteur prévoient que 75 % des échecs de sécurité proviendront d’erreurs d’IaC d’ici la fin 2025, soulignant la gravité de ce problème. Les chiffres sont alarmants. Une société de services financiers a découvert plus de 500 erreurs de configuration Terraform lors d’un audit de sécurité, dont beaucoup étaient déjà déployées en production.

Le problème n’est pas seulement théorique. Des attaquants ont exploité des scripts Terraform mal configurés pour injecter une infrastructure malveillante, siphonnant des données sensibles, ou exposant des secrets codés en dur comme des clés API ou des tokens d’accès stockés dans des fichiers Terraform. Il ne s’agit pas d’exploits zero-day sophistiqués — ce sont des erreurs de configuration simples qui deviennent des vulnérabilités systémiques par automatisation.

Cauchemars courants de configuration Terraform

La catastrophe du groupe de sécurité 0.0.0.0/0

Une erreur fréquente et dangereuse dans Terraform est la création de groupes de sécurité trop permissifs. Voici un exemple de code apparemment anodin :

resource "aws_security_group" "web_server" {
  name        = "web-server-sg"
  description = "Groupe de sécurité pour serveurs web"
  
  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

Ce code ouvre l’accès SSH à vos serveurs web depuis n’importe où sur Internet. Un développeur pourrait le créer lors des tests, en prévoyant de le restreindre plus tard, mais une fois validé dans le contrôle de version et appliqué via des pipelines CI/CD, cette vulnérabilité devient permanente. Chaque serveur web créé avec ce groupe de sécurité est immédiatement exposé aux attaques par force brute, au stuffing de crédentials, et à tout accès non autorisé.

Le danger s’amplifie lorsque des équipes utilisent des modules Terraform. Un groupe de sécurité mal configuré dans un module partagé peut affecter des dizaines ou centaines de ressources, gérées par différentes équipes, qui peuvent même ne pas se rendre compte qu’elles héritent de cette vulnérabilité.

Buckets S3 publics : le cadeau qui continue

Les erreurs de configuration des buckets S3 restent une des causes principales de fuites de données. Une erreur subtile dans Terraform peut rendre des données sensibles accessibles au public :

resource "aws_s3_bucket" "data_store" {
  bucket = "company-sensitive-data"
  acl    = "public-read"  # Catastrophe en vue
}

resource "aws_s3_bucket_public_access_block" "example" {
  bucket = aws_s3_bucket.data_store.id
  
  block_public_acls       = false
  block_public_policy     = false
  ignore_public_acls      = false
  restrict_public_buckets = false
}

Ce code rend explicitement le bucket lisible publiquement et désactive toutes les protections d’accès public d’AWS. Tout fichier uploadé devient accessible à quiconque connaît ou découvre l’URL. Données clients, documents internes, sauvegardes de bases, identifiants API — tout peut être exposé en quelques lignes de code.

L’aspect insidieux de l’IaC, c’est que cette erreur ne concerne pas qu’un seul bucket. Si cette configuration fait partie d’un module ou d’un template utilisé dans plusieurs projets, chaque instantiation crée un nouveau point d’exposition de données publiques.

Exposition de bases de données : quand RDS rencontre Internet

Les ressources de bases de données sont particulièrement sensibles, et pourtant, des erreurs Terraform les exposent régulièrement :

resource "aws_db_instance" "production" {
  allocated_storage      = 20
  engine                 = "postgres"
  instance_class         = "db.t3.micro"
  publicly_accessible    = true  # Erreur critique
  skip_final_snapshot    = true
  
  vpc_security_group_ids = [aws_security_group.database.id]
}

Mettre publicly_accessible = true pour une instance RDS la place sur un sous-réseau public avec un endpoint DNS résolvable publiquement. Associé à des règles de groupe de sécurité permissives, cette configuration rend les bases de données de production directement accessibles depuis Internet, contournant toutes les protections réseau.

Permissions IAM excessives : le principe du moindre privilège violé

Les erreurs de configuration IAM représentent une autre catégorie de cauchemars Terraform :

resource "aws_iam_role_policy" "lambda_policy" {
  role = aws_iam_role.lambda_role.id
  
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect   = "Allow"
        Action   = "*"
        Resource = "*"
      }
    ]
  })
}

Cette politique donne des permissions totales à tous les services et ressources AWS — l’équivalent de donner un accès root à toute votre infrastructure cloud. Si la fonction Lambda utilisant ce rôle est compromise, les attaquants ont un accès illimité à votre compte AWS.

Pourquoi les revues manuelles ne peuvent pas suivre

Le défi fondamental de la sécurité IaC est l’échelle. Les revues manuelles ne peuvent pas suivre le rythme des pratiques modernes de développement. Les équipes déploient des changements d’infrastructure des dizaines ou centaines de fois par jour. Les revues de code, aussi essentielles soient-elles, sont effectuées par des humains qui peuvent faire des erreurs, omettre des détails subtils, ou manquer des bonnes pratiques de sécurité sur tous les services cloud.

Un seul dépôt Terraform peut contenir des milliers de définitions de ressources réparties dans des centaines de fichiers. Les configurations de sécurité sont souvent dispersées dans des modules, des variables, et des overrides spécifiques à l’environnement. Attendre des développeurs qu’ils repèrent toutes les erreurs lors de la revue est irréaliste, surtout quand les changements sont rapides et que les équipes sont dispersées dans le monde.

De plus, les bonnes pratiques de sécurité cloud évoluent constamment. Une configuration jugée sûre l’année dernière peut être obsolète ou insuffisante aujourd’hui. Les processus manuels ne peuvent pas suivre le rythme de l’évolution des standards de sécurité et des menaces.

La solution : analyse automatique de sécurité IaC

La réponse aux problèmes systématiques de sécurité IaC, c’est l’analyse systématique de sécurité. Des outils d’analyse statique peuvent scanner le code Terraform et CloudFormation avant qu’il n’atteigne la production, identifiant les vulnérabilités à la source. Ces outils appliquent le principe du “shift left” — détecter les problèmes lors du développement plutôt qu’après déploiement.

Checkov : sécurité multi-plateforme complète

Checkov est un outil d’analyse statique complet supportant plusieurs frameworks IaC, dont Terraform et CloudFormation, excellent pour repérer les erreurs de configuration et les problèmes de conformité en analysant le code selon un large ensemble de politiques prédéfinies. Développé par Bridgecrew (maintenant intégré à Palo Alto Networks), Checkov scanne le code d’infrastructure, les images de conteneurs, et même les packages open source pour des questions de sécurité.

La force de Checkov réside dans sa bibliothèque étendue de politiques, couvrant des centaines de contrôles de sécurité et de conformité pour AWS, Azure, Google Cloud, et Kubernetes. Il peut identifier précisément les erreurs évoquées plus haut — groupes de sécurité permissifs, buckets S3 publics, bases de données exposées, permissions IAM excessives.

L’outil s’intègre parfaitement dans les workflows de développement :

# Installer Checkov
pip install checkov

# Scanner un répertoire Terraform
checkov -d /chemin/vers/terraform

# Scanner et sortir les résultats en JSON
checkov -d /chemin/vers/terraform -o json

Checkov fournit un rapport détaillé indiquant précisément quelles ressources violent les politiques de sécurité, la gravité de chaque problème, et des conseils pour la correction. Sa couverture étendue en fait un outil idéal pour les organisations utilisant plusieurs fournisseurs cloud ou outils IaC.

tfsec : sécurité Terraform rapide et ciblée

tfsec est un outil d’analyse statique conçu pour scanner le code Terraform afin d’identifier et de mettre en évidence les lacunes en matière de sécurité, en analysant localement ou en s’intégrant dans les pipelines CI, tout en fournissant une sortie conviviale et une gamme complète de contrôles.

Spécifiquement conçu pour Terraform, tfsec est extrêmement rapide et léger. Il analyse le code Terraform sans nécessiter de credentials AWS ni appliquer réellement l’infrastructure, se basant uniquement sur le code. Parfait pour des vérifications de sécurité en début de développement.

Les principaux avantages de tfsec :

• Rapidité : peut scanner de grands codes Terraform en quelques secondes
• Pas besoin de credentials cloud : fonctionne en mode hors-ligne
• Résultats clairs et exploitables avec liens vers des guides de correction
• Facile à intégrer dans des hooks pre-commit et pipelines CI/CD

Exemples d’utilisation :

# Installer tfsec
brew install tfsec

# Scanner le répertoire courant
tfsec .

# Scanner avec seuil de gravité spécifique
tfsec --minimum-severity HIGH .

# Sortie dans différents formats
tfsec --format json .

Terrascan : politique as code pour la conformité

Terrascan est un outil complet de scan IaC capable d’identifier en amont les problèmes de sécurité dans les modèles Terraform, avec une bibliothèque de politiques étendue conforme aux CIS Benchmarks, en faisant un outil puissant pour assurer la conformité. Terrascan excelle dans la vérification axée conformité, particulièrement utile pour les organisations en secteurs réglementés.

Terrascan supporte plusieurs outils IaC, dont Terraform, Kubernetes, Helm, et Dockerfiles. Son moteur de politiques permet aux équipes de définir des politiques de sécurité personnalisées en utilisant le langage Rego, pour répondre à des exigences spécifiques à l’organisation au-delà des bonnes pratiques standards.

Intégrer la sécurité IaC dans les pipelines CI/CD

La meilleure façon d’éviter les cauchemars de sécurité IaC, c’est d’intégrer la vérification de sécurité directement dans votre pipeline CI/CD. Cela crée une étape automatisée qui empêche les mauvaises configurations d’atteindre la production.

Intégration avec GitHub Actions

Voici un exemple de workflow GitHub Actions pour la vérification de sécurité IaC :

name: Scan de sécurité Terraform

on:
  pull_request:
    paths:
      - '**.tf'
      - '**.tfvars'

jobs:
  security_scan:
    runs-on: ubuntu-latest
    steps:
      - name: Vérifier le code
        uses: actions/checkout@v3
      
      - name: Exécuter Checkov
        uses: bridgecrewio/checkov-action@master
        with:
          directory: ./terraform
          framework: terraform
          quiet: false
          soft_fail: false
      
      - name: Exécuter tfsec
        uses: aquasecurity/tfsec-action@v1.0.0
        with:
          working_directory: ./terraform
          soft_fail: false

Ce workflow s’exécute à chaque pull request modifiant des fichiers Terraform, analysant le code avec Checkov et tfsec avant de permettre la fusion. Le paramètre soft_fail: false garantit que les échecs de sécurité bloquent le pipeline, empêchant la fusion de code vulnérable.

Intégration avec GitLab CI

Pour GitLab, une approche similaire fonctionne :

terraform_security_scan:
  stage: test
  image: bridgecrew/checkov:latest
  script:
    - checkov -d ./terraform --framework terraform
  only:
    changes:
      - "**/*.tf"
      - "**/*.tfvars"
  allow_failure: false

Intégration Jenkins

Les pipelines Jenkins peuvent intégrer la vérification de sécurité via des étapes shell :

pipeline {
    agent any
    stages {
        stage('Scan de sécurité IaC') {
            steps {
                sh 'docker run --rm -v $(pwd):/tf bridgecrew/checkov -d /tf'
                sh 'docker run --rm -v $(pwd):/src aquasec/tfsec /src'
            }
        }
    }
}

Bonnes pratiques pour un développement IaC sécurisé

Au-delà de la vérification automatisée, plusieurs pratiques permettent d’éviter les cauchemars de sécurité IaC :

1. Traitez l’infrastructure comme une application

Appliquez la même rigueur à l’infrastructure qu’à l’application. Cela inclut : - Revue de code avec focus sécurité - Contrôle de version pour toutes les définitions d’infrastructure - Tests automatisés, y compris tests de sécurité - Stratégies claires de branchement et déploiement

2. Utilisez Policy as Code

Définissez explicitement les politiques de sécurité en tant que code avec des outils comme Open Policy Agent (OPA) ou Sentinel. Cela permet de codifier les exigences de sécurité organisationnelles et de les appliquer automatiquement à toutes les déploiements.

3. Implémentez le principe du moindre privilège

Commencez avec des permissions minimales et n’ajoutez que ce qui est nécessaire. Utilisez des modules Terraform qui respectent ce principe, rendant plus difficile la création accidentelle de configurations permissives.

4. Séparez secrets et code

Ne jamais coder en dur des identifiants, clés API ou autres secrets dans les fichiers Terraform. Utilisez des outils de gestion de secrets comme HashiCorp Vault, AWS Secrets Manager, ou Azure Key Vault, en référant les secrets en temps réel plutôt qu’en les intégrant dans le code.

5. Audits réguliers de sécurité

Même avec la vérification automatisée, réalisez des audits réguliers de votre code d’infrastructure. Utilisez des outils capables de scanner l’infrastructure déployée pour repérer les dérives entre votre code et les ressources déployées, afin de détecter les modifications manuelles qui contournent les workflows IaC.

6. Sécurisez le fichier d’état

Les fichiers d’état Terraform contiennent des informations sensibles sur votre infrastructure. Toujours : - Stockez-les dans un backend chiffré (S3 avec chiffrement, Terraform Cloud) - Restreignez leur accès via des politiques IAM - Activez la gestion des versions pour récupérer d’éventuelles erreurs - Ne commitez jamais ces fichiers dans le contrôle de version

Conclusion

L’Infrastructure as Code représente une évolution fondamentale dans la gestion des ressources cloud, mais avec ce pouvoir vient une responsabilité importante. Une seule ligne mal configurée dans un fichier Terraform peut exposer systématiquement toute votre infrastructure, codifiant des vulnérabilités qui se propagent dans tous les environnements.

La solution n’est pas d’abandonner l’IaC — ses bénéfices surpassent largement ses risques lorsqu’elle est bien implémentée. Adoptez plutôt la vérification de sécurité automatisée comme un composant essentiel de votre workflow d’infrastructure. Des outils comme Checkov, tfsec, et Terrascan peuvent détecter les erreurs avant qu’elles n’atteignent la production, transformant l’IaC d’un cauchemar potentiel en une plateforme de gestion sécurisée et automatisée.

En intégrant la vérification de sécurité dans les pipelines CI/CD, en traitant l’infrastructure comme une application, et en appliquant les meilleures pratiques de sécurité, les équipes de développement peuvent exploiter la puissance de l’IaC tout en évitant ses pièges. La clé, c’est de reconnaître que le déploiement automatisé nécessite une analyse de sécurité automatisée — les revues manuelles ne peuvent suivre le rythme des pratiques modernes.

Le choix est clair : mettre en place une analyse systématique de sécurité pour votre IaC, ou risquer des vulnérabilités systémiques dans votre infrastructure. En 2025, face à un paysage de menaces où les attaquants ciblent activement les ressources cloud mal configurées, le coût de l’ignorance de la sécurité IaC est tout simplement trop élevé.