Terraform Security : Audit et Durcissement IaC en 2026

Le terraform security audit durcissement IaC est devenu une discipline incontournable pour toute organisation qui déploie des ressources cloud via HashiCorp Terraform. Selon le rapport CISA 2026 sur la sécurité des pipelines DevSecOps, 68 % des incidents cloud trouvent leur origine dans une configuration IaC défaillante — bucket S3 exposé, groupe de sécurité trop permissif, ou state file stocké en clair sur un bucket sans chiffrement. L'ANSSI insiste depuis 2025 dans ses guides de durcissement sur la nécessité d'intégrer des outils d'analyse statique IaC dès la phase de pull request. Des outils comme Checkov (Bridgecrew), tfsec et Trivy IaC rendent ce contrôle automatisable en quelques minutes. Cet article détaille chaque couche de sécurisation : de la détection de drift en passant par le chiffrement du tfstate, jusqu'aux Sentinel policies sur HashiCorp Cloud Platform. Les exemples de code sont fonctionnels et annotés pour une mise en œuvre directe en production.

Pourquoi le tfstate est-il le maillon le plus dangereux de votre pipeline IaC ?

Le fichier terraform.tfstate est le registre d'état de votre infrastructure. Il mappe chaque ressource Terraform à son identifiant cloud réel. Le problème : Terraform y stocke également toutes les valeurs en clair, y compris les attributs marqués sensitive = true dans le code HCL. Cela inclut les mots de passe de bases de données RDS, les clés secrètes IAM, les tokens OAuth et les certificats TLS.

Exemple concret d'un tfstate non chiffré après un terraform apply sur une instance RDS :

{
  "resources": [
    {
      "type": "aws_db_instance",
      "instances": [
        {
          "attributes": {
            "identifier": "prod-mysql",
            "username": "admin",
            "password": "MonMotDePasseDB2026!",
            "endpoint": "prod-mysql.xxxxx.eu-west-1.rds.amazonaws.com"
          }
        }
      ]
    }
  ]
}

Si ce fichier est stocké localement ou sur un bucket S3 sans chiffrement ni contrôle d'accès, n'importe quel développeur ayant accès au bucket récupère le mot de passe de production. La règle est simple : ne jamais stocker de state file localement en production, et toujours chiffrer le backend distant.

Configurer un backend S3 sécurisé : S3, KMS, DynamoDB et versioning

Le backend S3 de Terraform supporte nativement le chiffrement côté serveur via AWS KMS, le verrouillage d'état via DynamoDB et la gestion des versions pour permettre les rollbacks. Voici une configuration de backend de production annotée :

# backend.tf — Configuration backend sécurisée pour la production
terraform {
  backend "s3" {
    bucket         = "mon-org-terraform-state"
    key            = "prod/eu-west-1/infra/terraform.tfstate"
    region         = "eu-west-1"

    # Chiffrement SSE-KMS : clé CMK dédiée au state Terraform
    encrypt        = true
    kms_key_id     = "arn:aws:kms:eu-west-1:123456789012:key/mrk-abc123"

    # Verrouillage optimiste via DynamoDB : empêche les apply concurrents
    dynamodb_table = "terraform-state-locks"

    # Versioning activé sur le bucket S3 (à configurer via aws_s3_bucket_versioning)
    # Permet de restaurer un state précédent en cas de corruption
  }

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.50"
    }
  }
}

# Provider avec assume_role pour le principe du moindre privilège
provider "aws" {
  region = "eu-west-1"

  # Terraform assume un rôle IAM dédié, jamais de credentials statiques
  assume_role {
    role_arn     = "arn:aws:iam::123456789012:role/TerraformDeployRole"
    session_name = "TerraformSession-${formatdate("YYYYMMDD", timestamp())}"
    external_id  = var.terraform_external_id  # Secret partagé pour éviter le confused deputy
  }

  default_tags {
    tags = {
      ManagedBy   = "Terraform"
      Environment = var.environment
      CostCenter  = var.cost_center
      SecurityOwner = "[email protected]"
    }
  }
}

La configuration DynamoDB nécessite une table avec LockID comme clé de partition. Terraform gère automatiquement la création et la suppression des entrées de verrou :

# Ressource à déployer AVANT de basculer sur le backend S3
resource "aws_dynamodb_table" "terraform_locks" {
  name         = "terraform-state-locks"
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "LockID"

  attribute {
    name = "LockID"
    type = "S"
  }

  # Tags de sécurité obligatoires selon la politique tagging interne
  tags = {
    Name        = "terraform-state-locks"
    Purpose     = "Terraform state locking"
    Sensitivity = "HIGH"
  }
}

Checkov : analyse statique avec plus de 1 000 règles CKV_AWS_*

Checkov est l'outil d'analyse statique IaC le plus complet du marché. Développé par Bridgecrew (Palo Alto Networks), il supporte Terraform, CloudFormation, ARM, Bicep, Kubernetes et Dockerfile. En 2026, il embarque plus de 1 000 règles pour AWS seul, couvrant S3, EC2, RDS, Lambda, IAM, EKS et bien d'autres services.

Installation et premier scan :

# Installation via pip
pip install checkov

# Scan d'un répertoire Terraform avec sortie JSON pour intégration CI
checkov -d ./terraform/   --output json   --output-file checkov-report.json   --framework terraform

# Scan ciblé sur les règles AWS critiques uniquement
checkov -d ./terraform/   --check CKV_AWS_20,CKV_AWS_57,CKV_AWS_18,CKV_AWS_19   --compact

# Ignorer une règle spécifique avec justification (à documenter en ticket)
checkov -d ./terraform/   --skip-check CKV_AWS_126   --bc-api-key ${BRIDGECREW_API_KEY}

Exemple de sortie JSON Checkov pour une règle CKV_AWS_20 échouée (bucket S3 public) :

{
  "check_id": "CKV_AWS_20",
  "check_name": "Ensure the S3 bucket has access control list (ACL) applied and prevents public access",
  "check_result": {
    "result": "FAILED",
    "evaluated_keys": ["acl"]
  },
  "resource": "aws_s3_bucket.mon_bucket",
  "file_path": "/terraform/s3.tf",
  "file_line_range": [1, 15],
  "severity": "HIGH",
  "guideline": "https://docs.bridgecrew.io/docs/s3_1"
}

La règle CKV_AWS_57 détecte les buckets S3 sans chiffrement SSE activé. La règle CKV_AWS_18 vérifie l'activation du logging des accès S3. En configurant un fichier checklist.json, il est possible de définir les seuils d'acceptabilité par environnement :

{
  "checkov_config": {
    "severity_threshold": "HIGH",
    "soft_fail_severity": "MEDIUM",
    "skip_checks": [],
    "frameworks": ["terraform"],
    "output_formats": ["json", "cli"],
    "repo_root_for_plan_enrichment": ["./terraform"]
  }
}

tfsec : détection rapide et règles custom pour vos exigences sectorielles

tfsec est un scanner écrit en Go, beaucoup plus rapide que Checkov pour des analyses locales. Son principal avantage est la possibilité de créer des règles custom en YAML ou Rego (OPA), ce qui le rend idéal pour les exigences sectorielles spécifiques (PCI-DSS, HDS, NIS 2).

# Installation
brew install tfsec  # macOS
# ou
go install github.com/aquasecurity/tfsec/cmd/tfsec@latest

# Scan basique avec sortie colorée
tfsec ./terraform/

# Scan avec sortie SARIF pour intégration GitHub Advanced Security
tfsec ./terraform/ --format sarif --out tfsec-results.sarif

# Activer les règles custom depuis un répertoire dédié
tfsec ./terraform/ --custom-check-dir ./security-policies/tfsec/

# Ignorer un résultat avec annotation dans le code HCL (traçabilité)
# #tfsec:ignore:aws-s3-enable-bucket-logging — bucket de logs lui-même
resource "aws_s3_bucket" "access_logs" {
  bucket = "mon-org-access-logs"
}

Exemple de règle custom tfsec en YAML pour imposer le tag SecurityOwner sur toutes les ressources AWS :

# ./security-policies/tfsec/require-security-owner-tag.yaml
---
checks:
  - code: CUS-001
    description: Toutes les ressources AWS doivent avoir un tag SecurityOwner
    impact: Impossible d'identifier le propriétaire en cas d'incident
    resolution: Ajouter le tag SecurityOwner avec l'email de l'équipe responsable
    requiredTypes:
      - resource
    requiredLabels:
      - "aws_*"
    severity: HIGH
    matchSpec:
      name: tags
      action: contains
      value: SecurityOwner
    errorMessage: "La ressource {name} n'a pas de tag SecurityOwner défini"
    relatedLinks:
      - https://cyber.gouv.fr/

Trivy IaC : scan de modules Terraform et détection de CVE dans les providers

Trivy, développé par Aqua Security, est devenu en 2025-2026 la référence pour les scans de sécurité polyvalents. Il combine l'analyse statique IaC (Terraform, Kubernetes, Dockerfile) avec la détection de CVE dans les dépendances.

# Installation
curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/bin v0.51.0

# Scan IaC d'un module Terraform
trivy fs ./terraform/   --scanners misconfig   --format table   --severity HIGH,CRITICAL

# Scan avec sortie JSON pour reporting
trivy fs ./terraform/   --scanners misconfig,secret   --format json   --output trivy-iac-report.json

# Scan d'un module distant depuis le registry Terraform
trivy fs .   --scanners misconfig   --misconfig-scanners terraform

Trivy excelle dans la détection de secrets commités par erreur dans les fichiers HCL (--scanners secret). Il identifie les clés AWS, tokens GitHub, mots de passe en dur avec une précision supérieure à GitLeaks sur les fichiers Terraform grâce à ses parseurs HCL natifs.

terraform-compliance : tests BDD pour valider vos politiques de sécurité

terraform-compliance permet d'écrire des tests en langage naturel (BDD, Gherkin) pour valider que les plans Terraform respectent les politiques de sécurité avant l'apply. Il s'intègre dans le pipeline CI/CD et fonctionne sur la sortie JSON de terraform plan.

# Installation
pip install terraform-compliance

# Générer le plan JSON (nécessaire pour terraform-compliance)
terraform init
terraform plan -out=tfplan.binary
terraform show -json tfplan.binary > tfplan.json

# Exécuter les tests BDD
terraform-compliance -f ./compliance/ -p tfplan.json

Exemple de feature file BDD en Gherkin pour imposer le chiffrement sur tous les buckets S3 :

# ./compliance/s3_security.feature
Feature: Sécurité des buckets S3 en production
  En tant qu'équipe sécurité
  Je veux m'assurer que tous les buckets S3 sont chiffrés
  Afin de protéger les données sensibles au repos

  Scenario: Tous les buckets S3 doivent avoir le chiffrement activé
    Given I have aws_s3_bucket_server_side_encryption_configuration defined
    When it contains rule
    Then it must contain apply_server_side_encryption_by_default
    And its algorithm must match the "aws:kms" value

  Scenario: Les buckets S3 ne doivent pas être publics
    Given I have aws_s3_bucket_public_access_block defined
    When it contains block_public_acls
    Then it must be true
    And block_public_policy must be true
    And ignore_public_acls must be true
    And restrict_public_buckets must be true

  Scenario: Les groupes de sécurité ne doivent pas autoriser SSH depuis 0.0.0.0/0
    Given I have aws_security_group defined
    When it contains ingress
    And its from_port is equal to 22
    Then its cidr_blocks must not contain "0.0.0.0/0"

Comment détecter le drift d'infrastructure avec `terraform plan` ?

Le drift désigne l'écart entre l'état déclaré dans le code Terraform et l'état réel de l'infrastructure dans le cloud. Il survient quand un opérateur modifie manuellement une ressource via la console AWS sans mettre à jour le code HCL.

# Détecter les drifts : terraform plan montre toutes les différences
terraform plan -detailed-exitcode
# Exit code 0 = pas de changement
# Exit code 1 = erreur
# Exit code 2 = changements détectés (drift ou nouvelles ressources)

# Rafraîchir le state pour synchroniser avec le cloud sans modifier les ressources
terraform refresh

# Vérifier le state actuel d'une ressource spécifique
terraform state show aws_s3_bucket.mon_bucket

# Lister toutes les ressources gérées par Terraform
terraform state list | grep aws_security_group

# Importer une ressource créée manuellement dans le state
terraform import aws_security_group.imported sg-0123456789abcdef0

En production, automatisez la détection de drift avec un job planifié qui exécute terraform plan -detailed-exitcode et alerte via Slack ou PagerDuty si le code de retour est 2. Les outils comme Atlantis ou Spacelift proposent cette fonctionnalité nativement avec des rapports de drift quotidiens.

Sentinel policies : gouvernance IaC sur HashiCorp Cloud Platform

Sentinel est le framework de policy-as-code de HashiCorp, disponible dans Terraform Cloud et HCP Terraform. Les Sentinel policies s'exécutent dans le pipeline d'apply et peuvent bloquer (enforcement_level = "hard-mandatory") ou alerter (soft-mandatory") les plans non conformes.

# sentinel.hcl — Configuration des policies dans le workspace HCP
policy "require-encryption-all-s3" {
  source            = "./policies/require-encryption-all-s3.sentinel"
  enforcement_level = "hard-mandatory"  # Bloque l'apply si violation
}

policy "restrict-instance-types" {
  source            = "./policies/restrict-instance-types.sentinel"
  enforcement_level = "soft-mandatory"  # Avertissement, nécessite override manuel
}

policy "deny-public-s3-buckets" {
  source            = "./policies/deny-public-s3-buckets.sentinel"
  enforcement_level = "hard-mandatory"
}

Exemple de policy Sentinel qui interdit les instances EC2 de type t2.micro et t3.micro en production (contrainte de sécurité : pas de partage de ressources sur des instances bursty) :

# ./policies/restrict-instance-types.sentinel
import "tfplan/v2" as tfplan

# Liste des types d'instances autorisés en production
allowed_instance_types = [
  "m5.large", "m5.xlarge", "m5.2xlarge",
  "c5.large", "c5.xlarge", "c5.2xlarge",
  "r5.large", "r5.xlarge"
]

# Récupérer toutes les instances EC2 planifiées
ec2_instances = filter tfplan.resource_changes as _, resource_change {
  resource_change.type is "aws_instance" and
  resource_change.change.actions contains "create" or
  resource_change.change.actions contains "update"
}

# Vérifier que tous les types sont dans la liste autorisée
violations = filter ec2_instances as _, instance {
  not (instance.change.after.instance_type in allowed_instance_types)
}

main = rule {
  length(violations) is 0
}

Tableau comparatif des outils de sécurité IaC Terraform

Intégrer le terraform security audit dans votre pipeline CI/CD GitHub Actions

L'objectif est de bloquer les pull requests contenant des configurations Terraform non conformes, avant tout merge sur main. Voici un workflow GitHub Actions complet qui exécute Checkov, tfsec et Trivy en parallèle :

# Exemple de job CI minimal pour un pipeline de sécurité IaC
# À adapter selon votre runner et vos paths Terraform

# Étape 1 : Validation syntaxique
terraform fmt -check -recursive ./terraform/
terraform validate

# Étape 2 : Analyse statique parallèle
checkov -d ./terraform/ --output cli --output json --output-file checkov.json &
tfsec ./terraform/ --format sarif --out tfsec.sarif &
trivy fs ./terraform/ --scanners misconfig,secret --format json --output trivy.json &
wait

# Étape 3 : Tests BDD sur le plan
terraform plan -out=tfplan.binary
terraform show -json tfplan.binary > tfplan.json
terraform-compliance -f ./compliance/ -p tfplan.json

# Étape 4 : Vérifier les seuils (fail si CRITICAL ou HIGH non ignorés)
python3 scripts/check-thresholds.py --checkov checkov.json --max-high 0 --max-critical 0

Pour les équipes qui utilisent Pentest Cloud AWS Azure GCP dans leurs audits de sécurité, l'intégration IaC dans le pipeline permet de détecter les misconfigurations avant qu'elles ne soient exploitables. Rapprochez cette approche du durcissement système classique : le principe est identique, appliqué à l'infrastructure déclarative.

Comment sécuriser les variables sensibles dans Terraform sans les écrire en clair ?

Les variables sensibles (mots de passe, tokens, clés API) ne doivent jamais apparaître dans le code HCL en dur. En 2026, les bonnes pratiques convergent vers trois approches :

1. AWS Secrets Manager + data source Terraform : la valeur est récupérée dynamiquement au moment de l'apply sans jamais être stockée dans le code.

# Récupération d'un secret depuis AWS Secrets Manager
data "aws_secretsmanager_secret_version" "db_password" {
  secret_id = "prod/rds/admin-password"
}

resource "aws_db_instance" "prod" {
  identifier = "prod-mysql"
  username   = "admin"
  # Le mot de passe est récupéré depuis Secrets Manager, jamais en dur
  password   = jsondecode(data.aws_secretsmanager_secret_version.db_password.secret_string)["password"]

  # Marquer l'attribut comme sensible pour éviter l'affichage dans les logs
  lifecycle {
    ignore_changes = [password]
  }
}

2. Variables d'environnement TF_VAR_* : injectées par le pipeline CI/CD depuis un vault (HashiCorp Vault, AWS Parameter Store) au moment de l'exécution. Elles ne sont pas persistées dans le state file si elles ne sont pas référencées par une ressource.

3. Marquage sensitive = true : masque la valeur dans les sorties terraform plan et terraform apply, mais la valeur reste en clair dans le state file — cette option ne remplace pas le chiffrement du backend.

Cette discipline s'inscrit dans une stratégie Zero Trust globale où aucun secret ne transite en clair dans les pipelines, quelle que soit la couche d'abstraction. Pour aller plus loin sur la sécurisation des accès IaC, consultez notre analyse de l'Exploitation de l'Infrastructure as Code Terraform qui détaille les vecteurs d'attaque réels observés sur des environnements de production.

La sécurité des clusters Kubernetes déployés via Terraform suit les mêmes principes : voir notre guide Sécurité Kubernetes pour les règles Checkov et tfsec spécifiques aux manifests K8s générés par Terraform.

Checklist pratique : audit terraform security en 15 points

Voici la checklist opérationnelle à dérouler lors d'un audit de sécurité IaC Terraform, conforme aux recommandations de l'ANSSI et de la CISA :

• Backend : State file sur remote backend (S3, GCS, Azure Blob) avec chiffrement KMS activé
• DynamoDB lock : Verrouillage d'état configuré pour empêcher les apply concurrents
• Versioning : Versioning activé sur le bucket du state pour les rollbacks
• IAM least privilege : Rôle Terraform avec permissions minimales (assume_role, pas de credentials statiques)
• Pas de secrets en dur : Aucun mot de passe, token ou clé API dans le code HCL
• Checkov clean : 0 finding CRITICAL et HIGH dans checkov sur le répertoire Terraform
• tfsec clean : 0 finding HIGH ou CRITICAL dans tfsec
• Trivy secrets : 0 secret détecté par trivy fs --scanners secret
• Default tags : Tous les providers ont des default_tags avec ManagedBy, Environment, SecurityOwner
• Sentinel policies : Policies hard-mandatory configurées sur les workspaces HCP de production
• Drift monitoring : Job planifié de détection de drift (terraform plan -detailed-exitcode)
• Module pinning : Tous les modules référencent une version fixée (version = "x.y.z"), pas "latest"
• Pre-commit hooks : tfsec et terraform fmt configurés dans .pre-commit-config.yaml
• Peer review IaC : Toute modification Terraform passe par une PR avec revue de sécurité
• terraform-compliance : Tests BDD couvrant les politiques S3, Security Groups et IAM

La documentation officielle Terraform et Checkov by Bridgecrew sont les référentiels à consulter pour maintenir cette checklist à jour avec les nouvelles règles publiées chaque trimestre.

Questions fréquentes

Checkov et tfsec détectent-ils les mêmes vulnérabilités Terraform ?

Il y a un recouvrement d'environ 60 % sur les règles AWS communes (S3, Security Groups, RDS, IAM). Checkov est plus exhaustif avec 1 000+ règles et une meilleure couverture Azure/GCP. tfsec est plus rapide (Go vs Python) et plus adapté aux pre-commit hooks. En production, exécutez les deux : Checkov en CI pour l'exhaustivité, tfsec en local pour la rapidité. Les deux supportent des règles custom, avec des syntaxes différentes (Python ou YAML pour Checkov, YAML ou Rego pour tfsec).

Le chiffrement KMS du state file protège-t-il contre une fuite de credentials AWS ?

Non. Le chiffrement SSE-KMS protège les données au repos contre un accès physique au stockage S3. Si un attaquant compromet les credentials AWS (clés IAM, rôle assumé), il peut appeler l'API S3 GetObject et KMS Decrypt avec les mêmes permissions que Terraform. La vraie protection passe par la restriction des politiques IAM sur le bucket state (accès uniquement depuis le rôle Terraform et les pipelines CI/CD), la désactivation des ACL publics, et l'activation de S3 Block Public Access au niveau du compte.

Comment gérer les modules Terraform tiers du Registry : sont-ils sûrs ?

Les modules du registry public Terraform (registry.terraform.io) ne sont pas vérifiés de sécurité par HashiCorp. Avant d'utiliser un module communautaire, exécutez trivy fs et checkov sur le répertoire du module téléchargé (.terraform/modules/). Fixez toujours une version précise dans l'appel de module (version = "3.4.0") pour éviter les supply chain attacks via une mise à jour malveillante. Pour les environnements réglementés (HDS, PCI-DSS), préférez un registre privé (HCP Private Registry) avec des modules validés en interne.

Terraform Cloud vs HCP Terraform vs Atlantis : lequel choisir pour la sécurité ?

Atlantis (self-hosted) offre le contrôle total sur l'environnement d'exécution mais nécessite de gérer soi-même la sécurité du serveur et l'accès aux secrets. HCP Terraform (anciennement Terraform Cloud) propose nativement Sentinel policies, l'audit logging, le drift detection et la gestion des workspaces avec RBAC granulaire. Pour les organisations soumises à des contraintes de résidence des données (RGPD, données de santé), HCP Terraform propose des déploiements dans les régions EU depuis 2025. Atlantis est préférable si vous avez une équipe DevSecOps expérimentée et souhaitez éviter toute dépendance à un service tiers SaaS.

Comment auditer un environnement Terraform existant qui n'a jamais été soumis à une analyse de sécurité ?

Commencez par terraform plan -out=tfplan.binary && terraform show -json tfplan.binary > tfplan.json pour capturer l'état courant. Exécutez ensuite Checkov sur le répertoire source (checkov -d .) et triez les findings par sévérité. Priorisez les violations CRITICAL (buckets S3 publics, groupes de sécurité ouverts, instances sans chiffrement de disque). Créez un ticket par famille de violation et fixez un délai de 30 jours pour les HIGH, 90 jours pour les MEDIUM. Configurez ensuite les pre-commit hooks et le CI pour éviter la régression.