États de référence et dérive de configuration : maîtriser le drift

Imaginez cette situation : vous gérez un parc de 50 serveurs web. Tous sont censés être identiques, déployés à partir du même playbook Ansible. Un jour, vous devez migrer vers une nouvelle version de l'application.

Vous lancez la mise à jour. 47 serveurs se mettent à jour sans problème. Trois échouent avec des erreurs incompréhensibles. Après investigation, vous découvrez que :

• Sur le serveur 23, quelqu'un a modifié manuellement le fichier /etc/hosts pour « corriger un problème de DNS urgent » il y a six mois
• Sur le serveur 41, un collègue a installé un package de debug qui n'a jamais été retiré et qui entre en conflit avec la nouvelle version
• Sur le serveur 48, les permissions d'un répertoire ont été changées lors d'un dépannage nocturne, et le script de déploiement n'a plus les droits d'écriture

Trois serveurs, trois dérives différentes, trois heures perdues par serveur. Vous venez de découvrir le coût réel de la dérive de configuration.

Ce que vous allez apprendre

• Définir l'état de référence d'un serveur et le distinguer d'un changement légitime
• Détecter une dérive avec l'outil de gestion de configuration, un contrôle d'intégrité ou un audit de conformité
• Analyser une dérive avant de la corriger, puis choisir entre rétablir et faire évoluer la référence
• Prévenir la récidive en bloquant les modifications manuelles
• Mesurer la dérive avec le taux de conformité, le MTTD et le MTTR

Qu'est-ce que la dérive de configuration ?

L'état de référence : votre source de vérité

L'état de référence (baseline en anglais) est l'état validé et documenté d'un système. C'est la définition de « comment ce serveur devrait être configuré ».

Il inclut généralement :

Composant	Exemples d'éléments contrôlés
Système	Version OS, paramètres noyau, utilisateurs
Packages	Liste des logiciels installés, versions
Configuration	Fichiers de conf, permissions, services actifs
Réseau	Interfaces, routes, firewall, DNS
Sécurité	Durcissement, certificats, politiques

Glissez pour voir

L'état de référence peut être :

• Documenté : wiki, fichiers de référence, CMDB
• Codifié : playbooks Ansible, manifests Terraform, Dockerfiles, configurations Rudder
• Implicite : « c'est comme ça qu'on fait » (dangereux)

La dérive : l'écart silencieux

La dérive de configuration (configuration drift) survient quand l'état réel d'un système s'écarte de son état de référence. C'est la différence entre « ce que le système devrait être » et « ce qu'il est vraiment ».

État attendu (état de référence) - État réel = Dérive

Ce que la dérive n'est PAS

Confondre dérive et changement légitime mène à traquer de faux problèmes. Le critère qui départage tient en un mot : l'intention tracée. Un changement décidé, documenté et appliqué de façon contrôlée fait évoluer l'état de référence, ce n'est pas une dérive. La dérive, c'est l'écart non voulu ou non tracé. Le tableau suivant liste les cas qu'on prend à tort pour de la dérive.

Ce n'est PAS de la dérive	Pourquoi
Un changement planifié et documenté	C'est une évolution de l'état de référence
Une mise à jour de sécurité appliquée uniformément	L'état de référence évolue de façon contrôlée
Une différence volontaire entre environnements	Dev ≠ Prod par conception
Un bug logiciel	C'est un défaut, pas un écart de configuration

Glissez pour voir

Pourquoi la dérive est dangereuse

La dérive de configuration peut sembler anodine, après tout, qu'est-ce qu'un petit paramètre modifié ? Pourtant, elle est à l'origine de nombreux incidents majeurs, de failles de sécurité et de problèmes de conformité. Comprendre ses conséquences permet de prendre au sérieux sa prévention.

Les quatre conséquences majeures de la dérive

Ces quatre conséquences vont du visible à l'invisible. Les incidents se remarquent tout de suite, mais ce sont les failles de sécurité et la non-conformité qui coûtent le plus cher, car elles restent silencieuses jusqu'à l'audit ou la fuite. Lisez la colonne des exemples : chacun correspond à un cas réel, pas à une hypothèse.

Conséquence	Ce qui se passe	Exemple réel
Incidents	Comportement imprévisible	Serveur 23 différent des autres → plantage lors d'une mise à jour
Failles de sécurité	Durcissement perdu	En 2020, un bucket S3 de Twilio, ouvert en écriture publique par une mauvaise politique d'accès, a permis l'injection de code malveillant dans son SDK JavaScript TaskRouter
Non-conformité	Écart aux politiques	Audit PCI-DSS échoué car des serveurs n'avaient plus les bons paramètres
Temps perdu	Debug de « snowflakes »	Chaque serveur différent = chaque incident unique à investiguer

Glissez pour voir

La spirale de la dette de configuration

La dérive se comporte comme la dette technique : plus vous tardez à la traiter, plus son coût de correction augmente. Chaque écart non corrigé sert de base au suivant, si bien que le coût ne croît pas de façon linéaire mais s'accélère à chaque étape, comme le montre le schéma ci-dessous.

Source · SVG

Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 % − Ajuster + Fermer

1. Dérive initiale, Une petite modification manuelle « juste pour tester ». Ça semble anodin : « Je corrige vite ce paramètre en SSH, je documenterai ensuite ». Coût de correction à ce stade : quelques minutes.

2. Accumulation, D'autres modifications s'ajoutent sans documentation. Chaque membre de l'équipe fait « une petite correction ». Ces modifications se cumulent sans qu'aucune ne soit tracée. Coût de correction : quelques heures.

3. Divergence, Les serveurs « identiques » ne le sont plus. Le serveur de production ne se comporte pas comme celui de test. L'équipe commence à entendre : « Ça marche chez moi mais pas en prod ». Coût de correction : jours de travail.

4. Snowflake, Chaque serveur devient unique, impossible à reproduire. Le serveur 23 a des configurations que personne ne comprend. On n'ose plus y toucher. Coût de correction : semaines, avec risque d'incident.

5. Paralysie, L'équipe a peur de toucher quoi que ce soit. Toute mise à jour devient un projet risqué. L'innovation s'arrête. Coût de correction : mois de refonte, souvent après un incident majeur.

Qu'est-ce qu'un serveur « snowflake » ?

Un serveur « snowflake » (flocon de neige) est un terme du secteur, popularisé par Martin Fowler, qui désigne un serveur devenu tellement unique qu'il est impossible à recréer. Il a subi tant de modifications manuelles non documentées que personne ne sait exactement comment le reproduire. Si ce serveur tombe en panne, il faudrait des jours, voire des semaines, pour le reconstruire, en espérant ne rien oublier.

Sources et types de dérive

La dérive ne vient pas de nulle part. Elle a toujours une cause, technique ou humaine. Comprendre ses sources est la première étape pour la prévenir efficacement.

Source · SVG

Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 % − Ajuster + Fermer

Dérive technique : les causes opérationnelles

Ces causes sont liées aux outils et aux processus techniques. Elles sont souvent les plus faciles à résoudre car elles relèvent de l'outillage.

Source	Comment ça arrive	Pourquoi c'est dangereux
Modifications manuelles	SSH + commandes ad hoc pour « corriger vite »	Pas de trace, pas de rollback
Patchs et mises à jour	Correctif appliqué sur certains serveurs seulement, hors du cycle de patch management	Parc hétérogène
Automatisations partielles	Playbook qui échoue à mi-chemin	État incohérent
Ressources non gérées	Création cloud via console au lieu d'IaC	Shadow IT invisible

Glissez pour voir

Exemple concret, Un développeur crée un bucket S3 via la console AWS pour tester quelque chose. Il ne le supprime pas. Le bucket n'existe pas dans Terraform, donc il n'est pas audité. Six mois après, il contient des données sensibles et n'a pas les bonnes politiques de sécurité.

Dérive organisationnelle : les causes humaines

Ces causes sont liées à l'organisation, aux processus et aux personnes. Elles sont souvent plus difficiles à résoudre car elles nécessitent des changements culturels.

Source	Comment ça arrive	Pourquoi c'est dangereux
Processus contournés	« Pas le temps pour le change management »	Modifications non tracées
Documentation obsolète	L'état de référence « officiel » date de 2022	On ne sait plus ce qui est correct
Silos équipes	Dev, Ops, Sécu travaillent séparément	Chacun modifie de son côté
Turnover	L'expert qui savait tout est parti	Connaissances perdues

Glissez pour voir

Exemple concret, L'équipe sécurité demande l'ajout de règles firewall. L'équipe ops les applique manuellement « en attendant la prochaine release ». Un an après, ces règles n'existent toujours pas dans le code. Personne ne sait pourquoi elles sont là.

Le cycle de gestion de la dérive

Gérer la dérive n'est pas un projet ponctuel qu'on coche et qu'on oublie. C'est un processus continu, comme la gestion de la dette technique ou la sécurité. Le cycle se répète en permanence : détecter, analyser, corriger, prévenir.

Source · SVG

Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 % − Ajuster + Fermer

Étape 1 : Détecter, Comparer l'état réel à l'état de référence

La détection est la première ligne de défense. Elle consiste à identifier automatiquement les écarts entre l'état attendu (votre état de référence) et l'état réel des systèmes. Sans détection, vous naviguez à l'aveugle.

Infrastructure as Code

Si vous utilisez Terraform, Ansible ou Puppet, ces outils ont des fonctions de détection intégrées :

# Terraform : voir les différences entre état et réel
terraform plan

# Ansible : mode check (dry-run)
ansible-playbook site.yml --check --diff

# Puppet : mode noop
puppet agent --test --noop

Limitation : Ces outils ne voient que ce qu'ils gèrent. Une modification faite en dehors de l'outil reste invisible.

Outils de scan

Des outils spécialisés scannent l'état réel des systèmes :

Outil	Ce qu'il détecte	Type
AIDE, Tripwire	Changements de fichiers	On-premise
Snyk IaC	Drift cloud, ressources non gérées	Cloud
driftctl	Drift Terraform AWS/Azure/GCP	Open source, dépôt archivé
Spacelift	Drift IaC multi-cloud	SaaS

Glissez pour voir

Ces outils détectent aussi les ressources « orphelines » non gérées par IaC.

Audit système

Pour les serveurs Linux, des outils d'audit comparent l'état à une baseline de sécurité :

# OpenSCAP : audit contre un état de référence CIS
oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_cis \
   --results results.xml \
   /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml

# Lynis : audit de sécurité
lynis audit system

OpenSCAP et Lynis génèrent des rapports montrant les écarts aux standards.

Étape 2 : Analyser, Comprendre avant de corriger

Ne corrigez jamais une dérive à l'aveugle ! Chaque dérive a une cause, et cette cause peut révéler un problème plus profond. Parfois, c'est l'état de référence lui-même qui doit évoluer.

Question à poser	Pourquoi c'est important
Qui a fait la modification ?	Identifier si c'est un problème de processus ou de compétence
Quand a-t-elle eu lieu ?	Corréler avec des incidents ou des déploiements
Pourquoi était-elle nécessaire ?	Peut révéler un problème que l'état de référence ne résout pas
Quel impact si on corrige ?	Éviter de casser quelque chose en « réparant »

Glissez pour voir

Exemple : Vous détectez qu'un serveur a une règle firewall non standard. Avant de la supprimer, vérifiez qu'elle n'a pas été ajoutée pour bloquer une attaque en cours. Si c'est le cas, la bonne action est d'intégrer cette règle à l'état de référence, pas de la supprimer.

Étape 3 : Corriger, Rétablir ou faire évoluer

Une fois la cause comprise, deux choix s'offrent à vous. Le bon choix dépend de la nature de la dérive : était-ce une erreur ou une amélioration légitime ?

Option	Quand l'utiliser	Comment
Rétablir l'état de référence	La dérive était une erreur	Réappliquer le playbook, terraform apply
Mettre à jour l'état de référence	La dérive était une amélioration	Modifier l'IaC puis redéployer

Glissez pour voir

Attention : Ne corrigez jamais en « bricolant » à la main. Vous ne feriez que créer une nouvelle dérive, un cercle vicieux. Toute correction doit passer par l'outil de gestion de configuration.

# ❌ Mauvais : correction manuelle
sudo systemctl enable nginx

# ✅ Bon : correction via l'outil (Ansible ici)
ansible-playbook -l serveur23 site.yml --tags nginx

Étape 4 : Prévenir, Empêcher la récidive

La meilleure dérive est celle qui ne se produit pas. La prévention est l'étape la plus importante, elle transforme un cycle de « pompier » en approche proactive.

1. Automatiser tout changement

   Si une modification doit être faite, elle doit être codifiée (IaC, playbook) et versionnée. Jamais de SSH pour « corriger vite ».

2. Détecter en continu

   Exécuter terraform plan ou un scan de drift quotidiennement, pas juste avant les déploiements. Alerter sur tout écart.

3. Bloquer les modifications manuelles

   Restreindre les accès SSH, utiliser des politiques IAM qui empêchent les modifications console sur les ressources gérées par IaC.

4. Documenter et former

   S'assurer que tout le monde comprend pourquoi la modification manuelle est interdite et comment faire correctement.

5. Tracer et auditer

   Logs d'accès, audit trail cloud. Si quelqu'un dévie, vous devez pouvoir le savoir.

Anti-patterns et bonnes pratiques

Il est facile de tomber dans certains pièges quand on gère la configuration. Cette section présente les erreurs les plus courantes et comment les éviter.

Source · SVG

Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 % − Ajuster + Fermer

Les 10 erreurs les plus courantes

Ces anti-patterns sont observés dans la plupart des équipes. En les reconnaissant, vous pouvez les éviter :

Anti-pattern	Pourquoi c'est un problème	Que faire à la place
Modifications manuelles non documentées	Dérive invisible, pas de rollback	Tout passer par IaC
État de référence « implicite »	Personne ne sait ce qui est correct	Documenter et versionner
Détection uniquement avant déploiement	La dérive s'accumule entre-temps	Scan quotidien automatisé
Correction sans analyse	Risque de casser ce qui marchait	Comprendre avant d'agir
Documentation dans un wiki à part	Elle devient obsolète	État de référence = code versionné
Accès SSH/console pour tout le monde	Tentation de « corriger vite »	Principe du moindre privilège
Pas de responsable identifié	« C'est le problème de qui ? »	Owner par zone/service
État de référence trop complexe	Impossible à maintenir	Simplifier, modulariser
Ignorer les alertes de drift	« C'est normal, ça peut attendre »	SLA de correction (ex: 48h)
Corriger la dérive manuellement	Nouvelle dérive créée	Correction via l'outil

Glissez pour voir

Le « Fix Forward » ou « Fix Backward » ?

Face à une dérive, deux philosophies s'affrontent. Le choix entre les deux dépend d'une question simple : la dérive était-elle une erreur ou une amélioration ?

Source · SVG

Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 % − Ajuster + Fermer

Approche	Principe	Quand l'utiliser
Fix Backward	Rétablir l'état précédent (rollback)	La dérive a causé un problème
Fix Forward	Intégrer la modification à l'état de référence	La dérive était une amélioration

Glissez pour voir

Règle pratique : si la dérive était intentionnelle et bénéfique, fix forward. Si elle était accidentelle ou problématique, fix backward.

Ne jamais corriger manuellement !

Quelle que soit l'approche choisie, ne corrigez jamais la dérive en vous connectant au serveur pour « arranger les choses ». Vous ne feriez que créer une nouvelle dérive. Passez toujours par vos outils de gestion de configuration (Ansible, Terraform, Puppet…).

Outils de détection par environnement

Infrastructure cloud (IaC)

Côté cloud, la vraie question n'est pas de comparer le code au réel, votre outil IaC le fait déjà, mais de repérer les ressources non gérées créées hors du code. C'est le critère à regarder dans la colonne « Points forts » : seuls les outils qui détectent le unmanaged révèlent le shadow IT. terraform plan reste gratuit et intégré, mais ne voit que ce qu'il gère ; les autres élargissent la couverture au prix d'un abonnement.

Outil	Cloud	Points forts	Limites
terraform plan	Multi	Gratuit, intégré	Ne voit que le managed
driftctl	AWS, Azure, GCP	Open source, détecte les unmanaged	Projet archivé (intégré à Snyk)
Snyk IaC	Multi	Commercial, UI, couverture totale	Payant
Spacelift	Multi	Drift en temps réel, policies	Payant
Firefly	Multi	Découverte + codification auto	Payant

Glissez pour voir

Serveurs Linux

Sur un serveur Linux, deux besoins distincts se cachent derrière le mot « détection ». Surveiller les changements de fichiers relève de l'intégrité (AIDE, Tripwire, OSSEC), qui alertent dès qu'un fichier suivi est modifié. Vérifier la conformité à un standard de durcissement relève d'un autre registre (OpenSCAP, Lynis), qui comparent l'état à une baseline CIS ou SCAP. Choisissez selon la question posée : « qu'est-ce qui a changé ? » ou « suis-je toujours conforme au référentiel ? ».

Outil	Type	Points forts
AIDE	Détection changements fichiers	Léger, open source
Tripwire	Détection changements fichiers	Référence historique
OpenSCAP	Conformité SCAP/CIS	États de référence standards
Lynis	Audit sécurité	Facile à utiliser
OSSEC	HIDS avec détection de changements	Temps réel
Rudder	Gestion de configuration + drift	Interface web, reporting

Glissez pour voir

Orchestration

Les outils de gestion de configuration détectent la dérive sans logiciel tiers, puisqu'ils connaissent déjà l'état attendu. La distinction pratique porte sur ce qu'ils font une fois l'écart trouvé : Ansible et SaltStack proposent un mode simulation (--check, test=True) qui montre les écarts sans rien changer, tandis que Puppet peut aller jusqu'à corriger automatiquement à chaque passage de l'agent. Ce dernier comportement est puissant mais à manier avec prudence sur des serveurs sensibles.

Outil	Capacité
Ansible	--check --diff pour voir les écarts
Puppet	Agent détecte et corrige automatiquement
Chef	InSpec pour audit de conformité
SaltStack	Mode test=True pour dry-run

Glissez pour voir

Mesurer la dérive

On ne peut pas améliorer ce qu'on ne mesure pas. Mesurer la dérive permet de savoir si la situation s'améliore ou se dégrade, et de justifier les investissements en outillage et formation.

Métriques à suivre

Ces indicateurs vous donnent une vision claire de votre « santé configuration » :

Métrique	Ce qu'elle mesure	Objectif	Pourquoi c'est important
Taux de conformité	% de ressources sans dérive	> 95%	L'indicateur principal : combien de vos systèmes sont conformes
MTTD (Mean Time To Detect)	Temps entre dérive et détection	< 24h	Plus vite vous détectez, moins la dérive s'accumule
MTTR (Mean Time To Remediate)	Temps entre détection et correction	< 48h	Mesure votre capacité à réagir
Ressources non gérées	Nombre de ressources hors IaC	Tendre vers 0	Le « shadow IT » que vous ne voyez pas
Récurrence	Dérives qui reviennent après correction	0	Si elle revient, vous n'avez pas traité la cause racine

Glissez pour voir

Dashboard de suivi

Un bon dashboard de gestion de la dérive donne une vision d'ensemble en un coup d'œil. Il doit répondre à ces questions :

• Quelle est ma situation globale ? (taux de conformité)
• Où sont mes problèmes ? (environnements, systèmes concernés)
• Quelle est ma tendance ? (amélioration ou dégradation)
• Quelle est mon urgence ? (dérives critiques à traiter)

Ce type de dashboard peut être implémenté avec des outils comme Grafana, Datadog ou un simple tableau de bord interne. L'important est qu'il soit visible par toute l'équipe et mis à jour automatiquement.

Checklists opérationnelles

Checklist « Minimum viable »

Pour une équipe qui démarre la gestion de la dérive :

1. État de référence documenté

   Au minimum, un fichier décrivant la configuration attendue des serveurs critiques. Idéalement, du code IaC.

2. Détection hebdomadaire

   Exécuter un terraform plan ou un audit AIDE/OpenSCAP une fois par semaine minimum.

3. Processus de correction

   Savoir qui est responsable de corriger et sous quel délai.

4. Historique des écarts

   Conserver une trace de chaque dérive détectée et de sa correction.

5. Formation de base

   L'équipe sait pourquoi les modifications manuelles sont interdites.

Checklist « Organisation mature »

Pour une équipe qui veut industrialiser :

1. IaC à 100%

   Toute l'infrastructure est codifiée. Aucune ressource manuelle.

2. Détection continue

   Scan de drift automatisé quotidien, alertes en temps réel.

3. Blocage des modifications manuelles

   Policies IAM, accès SSH restreints, audit trail.

4. SLA de correction

   Critique : 4h. Haute : 24h. Moyenne : 48h. Basse : 1 semaine.

5. Métriques et reporting

   Dashboard de conformité, rapports hebdomadaires au management.

6. Revue post-incident

   Chaque dérive ayant causé un incident fait l'objet d'un postmortem.

7. Amélioration continue

   Rétrospectives régulières sur la gestion de la dérive.

À retenir

1. L'état de référence est votre source de vérité

   Sans état de référence clair, vous ne pouvez pas détecter la dérive. Documentez et versionnez l'état attendu de vos systèmes.

2. La dérive est inévitable

   Elle arrivera. Le problème n'est pas d'en avoir, c'est de ne pas la détecter. Automatisez la détection.

3. Détecter ≠ Corriger aveuglément

   Chaque dérive a une cause. Comprenez-la avant d'agir. Parfois, c'est l'état de référence qu'il faut mettre à jour.

4. Prévenir vaut mieux que guérir

   Automatisez les changements, bloquez les modifications manuelles, formez les équipes. Une dérive évitée coûte moins cher qu'une dérive corrigée.

5. Infrastructure as Code est votre meilleur allié

   Un système géré par IaC est plus facile à auditer, corriger et reproduire qu'un système configuré manuellement.

6. Mesurez pour progresser

   Taux de conformité, MTTD, MTTR. Ce qui se mesure s'améliore.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

Références externes

Articles fondateurs

• Configuration Drift, HashiCorp explique le concept et comment Terraform aide à le gérer
• Infrastructure as Code, Martin Fowler sur l'IaC comme solution à la dérive
• Cattle vs Pets, Le concept fondateur : serveurs jetables vs serveurs précieux

Guides pratiques

• How to Detect and Prevent Configuration Drift, Snyk, guide complet avec outils et méthodologie
• Managing Infrastructure Drift, Spacelift, bonnes pratiques et intégration CI/CD
• CIS Benchmarks, Center for Internet Security, états de référence de sécurité standards (voir aussi notre guide CIS Benchmarks)

Standards et frameworks

• NIST SP 800-128, Guide for Security-Focused Configuration Management
• CIS Controls, Control 4 : Secure Configuration of Enterprise Assets
• ISO 27001, contrôle 8.9 de l'annexe A (version 2022) : Configuration management

Outils open source

• driftctl, Détection de drift pour Terraform (dépôt archivé par Snyk, fonctionnalités reprises dans l'offre Snyk IaC)
• AIDE, Advanced Intrusion Detection Environment
• OpenSCAP, Audit de conformité contre états de référence SCAP
• Lynis, Outil d'audit de sécurité Linux

×

📖 Voir la documentation →