Aller au contenu principal
Expert Cybersécurité & IAv9.0
Centres de ressources conformité
Besoin d'un accompagnement expert ?
Devis personnalisé sous 24h — audit, conformité, incident
Checklists Sécurité — Audit & Durcissement
Formats disponibles
📄 PDF 📊 Excel 🌐 Web

11 checklists professionnelles couvrant 2 200+ points de contrôle. Téléchargement gratuit, aucune inscription.

Supply Chain IaC

cloud

Définition

La sécurité de la chaîne d'approvisionnement IaC (Supply Chain IaC) couvre les risques liés aux dépendances tierces utilisées dans l'Infrastructure as Code : modules Terraform du Terraform Registry, collections Ansible Galaxy, charts Helm, images Docker de base, et opérateurs Kubernetes. Une dépendance IaC compromise peut introduire des backdoors, des cryptominers, ou des mécanismes d'exfiltration dans l'infrastructure déployée. Les incidents de supply chain IaC incluent des cas réels de modules Terraform malveillants publiés sur le Terraform Registry avec des backdoors (création de ressources supplémentaires comme des accès IAM), des charts Helm compromis contenant des mineurs de crypto-monnaies, et des images Docker de base avec des malwares intégrés dans les layers. Les bonnes pratiques pour sécuriser la supply chain IaC comprennent plusieurs mesures complémentaires. Premièrement, épingler les versions : référencer les modules Terraform avec une version exacte (source = "hashicorp/consul/aws" version = "0.2.1") plutôt qu'une plage de versions ou "latest". Deuxièmement, utiliser des miroirs privés : répliquer les modules et providers Terraform dans un registre privé (Terraform Enterprise, Artifactory, ou un bucket S3) pour contrôler les versions utilisées. Troisièmement, vérifier les hashes : les lock files Terraform (.terraform.lock.hcl) verrouillent les hashes cryptographiques des providers, détectant toute modification. Les charts Helm doivent être signés avec Helm provenance et vérifiés avant installation. Les OCI registries (compatible avec Helm OCI) permettent de stocker et signer des charts dans des registres de conteneurs standard avec des politiques de contrôle d'accès. Cosign peut signer des artifacts Helm (et Terraform) et vérifier ces signatures via des Admission Controllers Kubernetes. L'utilisation de SBOM (Software Bill of Materials) pour les modules IaC permet d'inventorier toutes les dépendances et de détecter rapidement les modules affectés lors de la découverte d'une vulnérabilité dans une dépendance transitoire.

Terraform Registry et registres privés

Utilisez un registre Terraform privé (Terraform Cloud/Enterprise, JFrog Artifactory, ou un dépôt Git interne) pour contrôler les modules autorisés. Configurez Terraform CLI pour n'utiliser que votre registre privé via .terraformrc (host_requirements). Scannez automatiquement les nouvelles versions de modules publiées dans votre registre avec des outils IaC security (Checkov, tfsec) avant de les rendre disponibles aux équipes.

Lock Files Terraform et hashes

Commitez toujours le fichier .terraform.lock.hcl dans Git. Ce fichier contient les hashes cryptographiques (h1) de tous les providers utilisés. Si un provider est compromis et republié avec le même numéro de version, le hash sera différent et Terraform refusera de l'utiliser. Vérifiez régulièrement les hashes des providers contre les hashes publiés par les éditeurs sur leurs pages officielles. Utilisez terraform providers lock -platform pour générer des hashes pour toutes les plateformes cibles.

Monitoring des mises à jour de sécurité

Abonnez-vous aux canaux de sécurité des projets IaC que vous utilisez (GitHub Security Advisories, CVE feeds). Outils comme Renovate Bot et Dependabot peuvent automatiser les mises à jour des modules Terraform, providers, et charts Helm. Configurez des pipelines de test automatiques pour valider que les mises à jour ne cassent pas votre infrastructure. Définissez des SLAs de mise à jour selon la sévérité des CVE (24h pour CRITICAL, 7 jours pour HIGH).

Articles liés

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis