Détection de Dérive : Quand l'Infrastructure Change Hors de Votre Pipeline

Vous avez rédigé des politiques. Vous avez automatisé les vérifications dans votre pipeline CI/CD. Chaque déploiement passe par une validation avant d'atteindre la production. Votre équipe est confiante : l'infrastructure respecte les règles.

Puis, un membre de l'équipe doit déboguer un incident de production à 22h. Il se connecte à la console cloud, ouvre un port de groupe de sécurité vers son IP personnelle, résout le problème et va se coucher. Il oublie de revenir en arrière. Le lendemain matin, ce groupe de sécurité est toujours ouvert. Votre pipeline n'en a jamais rien su. Vos politiques ne l'ont jamais détecté.

Ce scénario n'est pas rare. Il survient quand des ingénieurs prennent des raccourcis pendant un incident, quand une autre équipe crée des ressources manuellement parce que votre pipeline est perçu comme trop lent, ou quand l'auto-scaling lance de nouvelles instances avec des configurations par défaut qui violent vos politiques. Tous ces changements se produisent en dehors de votre pipeline CI/CD, donc les vérifications de politique que vous avez soigneusement intégrées à vos étapes de planification et d'application ne les voient jamais.

Ce que la Détection de Dérive Signifie Réellement

La détection de dérive est le processus qui compare l'état réel de votre infrastructure avec ce que vos politiques stipulent. Elle s'exécute périodiquement — toutes les heures, tous les jours, ou selon la cadence qui convient à votre équipe — et signale les ressources qui ont dévié des règles.

L'objectif n'est pas d'empêcher les changements. Vos politiques de pipeline gèrent déjà cela en bloquant les déploiements non conformes avant qu'ils n'aient lieu. La détection de dérive capture les changements qui se sont déjà produits en dehors de votre pipeline. C'est votre filet de sécurité pour l'infrastructure que vous ne pouvez pas contrôler uniquement par l'automatisation.

Comment la Détection de Dérive Fonctionne en Pratique

Le mécanisme est simple. Un outil ou un script interroge l'API de votre fournisseur cloud pour lister toutes les ressources existantes. Ensuite, il vérifie chaque ressource par rapport à vos politiques définies, une par une.

Voici un script bash simple qui exécute un plan Terraform et alerte en cas de dérive détectée :

#!/bin/bash
# Script de détection de dérive planifié (exécuté via cron toutes les heures)
cd /path/to/terraform/project
terraform init -input=false > /dev/null 2>&1
terraform plan -detailed-exitcode -input=false -no-color > plan_output.txt 2>&1
EXIT_CODE=$?
if [ $EXIT_CODE -eq 2 ]; then
  echo "Dérive détectée à $(date)" >> drift_alerts.log
  # Envoyer une notification (ex. webhook Slack)
  curl -s -X POST -H 'Content-type: application/json' \
    --data "{\"text\":\"Dérive détectée dans l'infrastructure de production. Consultez plan_output.txt pour les détails.\"}" \
    https://hooks.slack.com/services/YOUR/WEBHOOK/URL
elif [ $EXIT_CODE -eq 1 ]; then
  echo "Échec du plan Terraform à $(date)" >> drift_alerts.log
fi

Par exemple, votre politique stipule qu'aucun groupe de sécurité ne doit avoir le port 22 ouvert à 0.0.0.0/0. La détection de dérive analyse chaque groupe de sécurité et signale toute violation. Ou votre politique exige un tag owner sur chaque ressource. La détection de dérive inventorie toutes les ressources et marque celles qui n'ont pas le tag.

Les résultats doivent aboutir à un endroit que votre équipe consulte réellement. Un tableau de bord fonctionne. Les notifications Slack ou par email fonctionnent. Un ticket automatisé dans votre système de suivi fonctionne. Ce qui ne fonctionne pas, c'est de générer un rapport que personne ne lit. Quelqu'un doit être responsable du suivi, sinon la détection de dérive devient du bruit.

Outils pour Détecter la Dérive

Plusieurs outils intègrent déjà des capacités de détection de dérive. Terraform propose terraform plan qui peut montrer les différences entre votre fichier d'état et l'infrastructure réelle. Mais cela n'aide que pour les ressources gérées via Terraform. Les ressources créées en dehors de Terraform nécessitent une approche différente.

Les outils natifs du cloud peuvent analyser largement. AWS Config, Azure Policy et Google Cloud Asset Inventory inspectent les ressources à l'aide de leurs API natives. Ils comprennent profondément le modèle de ressources du fournisseur cloud et peuvent vérifier la conformité sur l'ensemble de votre compte.

Des options open source existent aussi. Open Policy Agent (OPA) peut fonctionner comme un moteur de politique que vous déclenchez périodiquement contre votre infrastructure. Vous écrivez des politiques en Rego, et OPA les évalue par rapport aux données de ressources que vous lui fournissez.

La Partie Difficile : Que Faire Quand Vous Trouvez une Dérive

Trouver une dérive n'est que la moitié du travail. La question la plus difficile est de savoir quoi faire ensuite.

Les bons rapports de dérive incluent suffisamment d'informations pour résoudre le problème. Ils vous indiquent quelle ressource a violé quelle politique et, idéalement, comment la corriger. Certaines équipes vont plus loin et mettent en œuvre une correction automatique — lorsque la dérive est détectée, le système rétablit automatiquement la ressource dans son état conforme.

La correction automatique semble géniale jusqu'à ce qu'elle vous morde. Si un ingénieur a ouvert un port temporairement pour déboguer un incident de production, la correction automatique pourrait fermer ce port pendant qu'il travaille encore. L'outil corrigerait une violation de politique tout en perturbant une investigation active. Vous devez faire la distinction entre une dérive accidentelle et une dérive intentionnelle pour une raison à court terme.

Une approche pratique consiste à commencer par des alertes et une correction manuelle. Informez l'équipe lorsqu'une dérive se produit, donnez-lui les détails et laissez-la décider s'il faut la corriger immédiatement ou la documenter comme une exception temporaire. Une fois que vous comprenez les schémas de dérive dans votre environnement, vous pouvez envisager l'automatisation pour les cas qui sont toujours erronés et jamais justifiés.

Trois Niveaux de Protection

La détection de dérive complète votre cycle d'application des politiques. Considérez-la comme trois niveaux qui couvrent mutuellement leurs angles morts :

Le diagramme ci-dessous illustre comment ces trois niveaux interagissent :

flowchart TD A[Changement de Code] --> B[Vérification de Politique au Plan] B -->|Succès| C[Vérification de Politique à l'Application] B -->|Échec| D[Bloquer le Déploiement] C -->|Succès| E[Déployer en Production] C -->|Échec| D E --> F[Infrastructure en Cours d'Exécution] F --> G[Changement Manuel / Correction d'Incident] G --> H[Analyse de Détection de Dérive] H -->|Conforme| I[Aucune Action] H -->|Dérive Trouvée| J[Alerter l'Équipe] J --> K[Correction Manuelle] K --> F J --> L[Correction Automatique] L --> F
  1. Vérification de politique au moment du plan - Empêche les violations avant qu'elles n'atteignent la production
  2. Vérification de politique au moment de l'application - Capture tout ce qui a échappé à la planification
  3. Détection périodique de dérive - Trouve les changements survenus en dehors du pipeline

Aucun niveau seul ne suffit. Les vérifications du pipeline ne peuvent pas détecter les modifications manuelles via la console. La détection de dérive ne peut pas empêcher les violations de se produire en premier lieu. Ensemble, ils vous offrent une couverture qui maintient votre infrastructure alignée sur vos politiques, même lorsque les choses changent en dehors de vos flux de travail automatisés.

Liste de Vérification Pratique

  • Choisissez une cadence pour les analyses de dérive en fonction de la vitesse à laquelle votre infrastructure change
  • Sélectionnez des outils qui couvrent à la fois les ressources gérées et non gérées dans votre environnement
  • Envoyez les rapports de dérive vers un canal que votre équipe surveille réellement
  • Attribuez la responsabilité du suivi des résultats de dérive
  • Commencez par une correction manuelle avant d'envisager l'automatisation
  • Documentez les exceptions temporaires pour que votre équipe sache quelles dérives sont intentionnelles

Ce que Cela Signifie pour Votre Équipe

Vos politiques ne sont aussi solides que votre capacité à les appliquer partout où l'infrastructure change. Les vérifications du pipeline gèrent les changements que vous contrôlez. La détection de dérive gère les changements que vous ne contrôlez pas. Sans les deux, votre politique n'est qu'un document qui décrit ce qui devrait être vrai, et non un mécanisme qui le maintient. Intégrez la détection de dérive dans vos opérations, et votre infrastructure restera conforme même lorsque l'inattendu se produit.