Pourquoi la détection de drift est critique en infrastructure cloud
Quand une infrastructure AWS croît au-delà du stade artisanal, elle franchit un seuil critique : la documentation de code devient l'unique source de vérité (ce qu'on appelle Infrastructure as Code, ou IaC). Pourtant, dans la majorité des équipes, l'état réel en production diverge progressivement de ce qui est déclaré. Un développeur ajoute manuellement une règle de sécurité qui n'est pas dans le code. Un opérateur modifie un paramètre de base de données pour résoudre un problème d'urgence, oublie d'en mettre à jour la déclaration. Une variable d'environnement change sans trace. Ces écarts, ou « dérives », s'accumulent silencieusement. Quand il faut faire un audit de conformité, réduire les coûts cloud, ou tout simplement redéployer l'infrastructure après un incident, on découvre que le code ne reflète plus la réalité. Le résultat est chaotique : scripts de correction ad hoc, tentatives de réécriture rétroactive du code d'après l'existant (cloud janitor), ou pire, des configurations oubliées qui restent en production longtemps après leur obsolescence. La détection de drift automatisée est donc bien plus qu'une affaire de propreté. Elle devient une couche de sécurité, un vérificateur de conformité continu, et la fondation d'une infrastructure vraiment codifiée où le code est source de vérité et non fiction.
Les outils natifs AWS pour détecter les dérives
AWS propose nativement plusieurs services pour identifier et corriger les dérives. AWS CloudFormation, l'outil de référence pour l'IaC sur AWS, offre la fonctionnalité Drift Detection directement intégrée. Elle se déclenche par API ou console, analyse l'état déclaré du stack et le compare avec les ressources réellement provisionnées. CloudFormation rapporte en détail quelles ressources ont changé, quels paramètres ne correspondent plus, et même tente de classer la gravité de la dérive (suppression, modification structurelle, changement de paramètre non critique). Ce scan est ponctuel mais gratuit et précis pour tout ce qui a été déployé via CloudFormation lui-même. AWS Config complète ce tableau en offrant une surveillance continue. Configuré pour suivre les changements de ressources AWS (EC2, RDS, S3, IAM, VPC, etc.), Config enregistre chaque modification, qui l'a faite, quand, et crée un historique complet. On peut ensuite définir des règles (par exemple, « tous les buckets S3 doivent avoir le chiffrement activé ») et Config veille en continu. Quand une ressource devient non conforme (un ingénieur désactive le chiffrement manuellement), une alerte est levée. Le service génère aussi des rapports de conformité pour les audits. AWS Systems Manager Session Manager et AWS Systems Manager Documents offrent un autre angle : automatiser les correctifs déclarés dans des documents AWS Systems Manager une fois une dérive détectée. Enfin, pour les équipes qui utilisent Terraform au lieu de CloudFormation, Terraform Cloud et Terraform Enterprise intègrent une détection de drift similaire (terraform plan compare toujours l'état déclaré au réel). La force de ces outils réside dans leur intégration native à l'écosystème AWS : peu de configuration, accès immédiat aux métadonnées AWS, et une traçabilité qui s'aligne avec CloudTrail pour l'audit.
Détecter les dérives au-delà des ressources déclarées
Les outils natifs AWS couvrent excellemment les ressources provisionned par leur propre service (CloudFormation couvre son stack, AWS Config couvre toute ressource AWS). Cependant, une infrastructure complète déborde souvent de ce périmètre. Si vous utilisez Kubernetes sur AWS (EKS), la dérive des manifests Kubernetes ne sera pas détectée par CloudFormation Drift Detection. Si vous avez du code applicatif configuré via des outils tiers comme Helm, Ansible ou même des scripts Bash, les services natifs AWS ne les voient pas. C'est là qu'intervient une approche plus large : utiliser des outils de scanning d'infrastructure complète qui reconnaissent plusieurs langages IaC (Terraform, CloudFormation, Ansible, Helm, etc.) et qui font des scans réguliers de votre infrastructure. Des outils open source comme Checkov ou Trivy scannent le code IaC pour vérifier la conformité aux bonnes pratiques avant le déploiement (preventive). Pour la détection continue en production, des plateformes comme Snyk Infrastructure ou Wiz ajoutent une couche de surveillance post-déploiement, alertant sur les dérives détectées entre ce qui est en production et ce qui est déclaré, indépendamment de l'outil IaC utilisé. Ces solutions commerciales intègrent généralement AWS Config en arrière-plan pour avoir une vue unifiée. L'avantage est une couverture large et une visibilité indépendante du toolchain IaC. L'inconvénient est la complexité de configuration supplémentaire et potentiellement des coûts d'abonnement. Pour beaucoup d'équipes scale-up, commencer par CloudFormation Drift Detection et AWS Config suffît à couvrir 80% des besoins, puis ajouter des couches si le scope de l'infrastructure s'élargit (multi-cloud, stacks d'applications tierces, Kubernetes à grande échelle).
Mettre en place une boucle de correction automatisée
Détecter une dérive ne sert qu'à moitié si on ne la corrige pas. Une infrastructure mature intègre donc une boucle de correction automatisée. Le pattern classique fonctionne en trois étapes. D'abord, la détection est déclenchée régulièrement (par un scan planifié CloudFormation, par des règles AWS Config, ou par un pipeline CI/CD quotidien lancé par exemple via GitHub Actions ou AWS CodePipeline qui exécute un terraform plan). Ensuite, quand une dérive est détectée, une alerte est levée. Cette alerte peut être passive (envoyée à une équipe qui l'examine manuellement via SNS ou une notification Slack) ou proactive (un système décide automatiquement si la dérive peut être corrigée sans risque). Pour les dérives « sans risque », on peut configurer une correction automatique. Par exemple, si AWS Config détecte qu'une règle de sécurité de groupe de sécurité autorise le trafic sans restriction (0.0.0.0/0), une action corrective prédéfinie resserre automatiquement la règle selon une politique définie. CloudFormation dispose de la même capacité via des SNS topics ou Lambda triggers. Terraform, lui, ne corrige qu'en relançant terraform apply sur le code à jour. La troisième étape, souvent négligée, est la traçabilité : enregistrer QUI a corrigé la dérive, COMMENT, et À QUELLE HEURE, dans un audit log. Cela est crucial pour la conformité réglementaire (SOC2, ISO27001) et pour comprendre après coup pourquoi une correction a eu lieu. AWS CloudTrail capture déjà les corrections faites via l'API AWS. Il faut veiller à ce que les corrections automatisées passent aussi par CloudTrail (et non par des scripts directs à privilèges root). En pratique, une équipe DevOps mature combine une détection continue (Config rules ou terraform plan quotidien) avec une correction semi-automatique (alertes d'exposition rapide + corrections auto pour les problèmes bénins + revue manuelle pour les changements structurels) et une traçabilité via CloudTrail et des logs centralisés. Cet équilibre maintient la conformité sans paralyser l'agilité du développement.
Intégrer la drift detection dans le cycle de développement et déploiement
Pour que la drift detection soit réellement opérationnelle, elle doit s'intégrer dans le quotidien des équipes, pas rester un processus isolé pour l'audit annuel. La meilleure approche est de la tisser dans le pipeline de déploiement (CI/CD). Au moment où un changement d'infrastructure est poussé en code (un commit dans le repository Terraform ou CloudFormation), le pipeline peut lancer un scan de drift préexistant avant d'appliquer le changement. C'est une vérification d'état : « OK, il y a une dérive connue dans l'environnement de prod, changement approuvé déjà ». Cela évite de déployer un changement qui se ferait sans le contexte de la dérive actuelle. Après le déploiement, un scan post-déploiement vérifie que l'infrastructure est vraiment conforme au code fraîchement déployé. Si ce scan détecte une dérive inattendue (par exemple, une ressource a été supprimée pendant le déploiement sans raison connue), on peut déclencher un rollback. Pour les équipes qui travaillent en environnements multiples (dev, staging, prod), il est aussi intéressant de comparer les dérives entre environnements : si dev et staging sont conformes mais prod a des dérives, c'est un signal que prod a dévié après que le code a été approuvé. Les meilleurs résultats viennent quand l'équipe DSI ou DevOps définit une politique claire : « Dérives critiques (sécurité, conformité) doivent être corrigées en moins de 24h. Dérives mineures (paramètres non-critiques) doivent être corrigées lors du prochain déploiement d'infra. Toute correction est tracée et approuvée. » Ensuite, on automatise l'application de cette politique via des outils comme AWS Config remediation actions, des webhooks Terraform Cloud, ou des alertes Slack avec approbation manuelle intégrée. Le résultat final : une infrastructure où le code et la réalité restent synchronisés, où les surprises de conformité disparaissent, et où les équipes regagnent du temps qu'elles pouvaient passer à corriger des inconsistences.
Défis courants et solutions pratiques
En pratique, implémenter une drift detection efficace bute sur quelques pièges récurrents. Le premier est le faux positif : l'outil détecte une dérive qui n'en est pas vraiment une. Par exemple, si une ressource Cloud a un paramètre dont AWS remplit la valeur par défaut après la création (ex : une règle de sortie implicite sur un groupe de sécurité), CloudFormation Drift Detection la verra comme une divergence, alors qu'elle est attendue. La solution est de bien configurer le code IaC pour déclarer explicitement ces valeurs attendues par défaut, ou d'exclure ces ressources connues pour faire du bruit des scans de drift. Le deuxième piège est les changements légitimes qui ne passent pas par le code. Un opérateur doit ajouter un disque temporaire à une instance EC2 pour un test urgent. Ou une équipe applicative crée un bucket S3 via un script d'installation qu'aucune équipe infra n'a approuvé. Ces changements sont légitimes à court terme, mais deviennent des dérives si on oublie de les mettre à jour dans le code. La solution est une gouvernance claire : toute ressource longue durée DOIT être déclarée en code avant le déploiement. Les ressources temporaires (dev, test, spike) peuvent être exclues des scans de drift ou tracées dans un registre séparé. Le troisième défi est l'ampleur : à mesure que l'infrastructure grandit (milliers de ressources), scanner toute l'infrastructure chaque jour devient coûteux et génère beaucoup de bruit. La solution est de prioriser. Scanner les ressources critiques (sécurité, réseau, données) en continu. Scanner les autres à fréquence réduite (hebdomadaire). Utiliser des rapports de drift focalisés sur les changements détectés depuis le dernier scan (delta), pas l'état complet. Le quatrième est l'humain : une équipe dont le code infra est mauvais au départ (spaghetti IaC, absence de modularité) trouvera la drift detection frustrante, car elle les oblige à nettoyer leurs erreurs architecturales plutôt que d'avancer. Ici, la solution n'est pas technique : c'est refondre le code IaC en parallèle du déploiement de la drift detection, ou étaler l'activation des scans pour ne pas paralyser le flux de travail. En résumé, bien calibrer la détection de drift pour sa propre infrastructure demande itération : commencer simple (CloudFormation Drift Detection sur les ressources critiques), mesurer le taux de faux positifs et de vrais positifs, puis affiner les règles et la fréquence.