Quand l'infrastructure change en dehors de votre pipeline : dérive, politique et gouvernance pratique

Imaginez ceci : vous êtes d'astreinte à 2 heures du matin. Un incident de production se produit, et quelqu'un dans l'équipe doit ouvrir temporairement un port de groupe de sécurité pour déboguer un problème de connectivité. Cette personne se connecte à la console cloud, effectue la modification, et l'incident est résolu. Tout le monde souffle.

Trois semaines plus tard, lors d'un audit de sécurité de routine, vous découvrez que ce port est toujours ouvert sur l'ensemble d'internet. Personne n'a pensé à le fermer. Personne n'a documenté la modification. Et votre pipeline d'infrastructure en tant que code pense toujours que ce groupe de sécurité est verrouillé.

C'est ce qu'on appelle la dérive d'infrastructure. Cela arrive dans toutes les organisations qui exploitent des systèmes réels. La question n'est pas de savoir si cela se produira, mais comment vous gérez la situation quand cela arrive.

Pourquoi interdire les modifications manuelles ne fonctionne pas

La réponse évidente semble être : interdisez simplement toutes les modifications manuelles. Tout doit passer par le pipeline. Sans exception.

En pratique, cette approche échoue pour trois raisons.

Premièrement, les urgences arrivent. Quand un système de production est en panne, attendre une exécution de pipeline qui prend 15 minutes n'est pas acceptable. Les ingénieurs trouveront un moyen d'effectuer la modification directement, et ils devraient pouvoir le faire.

Deuxièmement, toutes les modifications ne se valent pas. Ajouter une balise à une ressource ou mettre à jour une description est fondamentalement différent de modifier un groupe de sécurité de base de données. Les traiter de la même manière crée une friction inutile pour les modifications à faible risque.

Troisièmement, l'application des règles est difficile. Vous ne pouvez pas physiquement empêcher quelqu'un ayant accès à la console cloud de cliquer sur un bouton. Et si vous supprimez complètement l'accès à la console, vous créez des goulots d'étranglement pour le dépannage légitime.

La meilleure approche n'est pas d'interdire les modifications manuelles, mais de les gouverner.

Politique en tant que code : des règles qui s'appliquent d'elles-mêmes

La plupart des organisations ont des politiques concernant les modifications d'infrastructure. Elles sont généralement écrites dans un document quelque part : "Toutes les modifications en production doivent passer par le processus de gestion des changements." Mais les documents n'appliquent rien. Ils restent là, à prendre la poussière.

La politique en tant que code change cela. Des outils comme Open Policy Agent (OPA) ou HashiCorp Sentinel vous permettent d'écrire des règles en code et de les attacher à des points d'application. Quand quelqu'un essaie de modifier une ressource via la console cloud, ou quand un appel API arrive directement, le moteur de politique évalue la demande par rapport à vos règles avant de l'autoriser.

Voici un exemple concret. Vous écrivez une politique qui dit : "Aucun groupe de sécurité ne peut avoir le port 22 ouvert sur 0.0.0.0/0 à moins que la modification ne provienne du pipeline approuvé." Quand un ingénieur, paniquant pendant un incident, essaie d'ouvrir SSH au monde entier depuis la console AWS, la politique bloque la modification. Ou au minimum, elle enregistre la tentative et demande une approbation supplémentaire.

Par exemple, voici une politique HashiCorp Sentinel qui exige que chaque ressource ait une balise managed-by, garantissant que les modifications en dehors du pipeline sont traçables :

# Exiger que toutes les ressources aient une balise "managed-by"
import "tfplan/v2" as tfplan

# Récupérer toutes les ressources qui seront créées ou mises à jour
all_resources = tfplan.resource_changes.all

# Règle : chaque ressource doit avoir une balise "managed-by"
mandatory_tag = "managed-by"

main = rule {
  all all_resources as _, rc {
    rc.applied.tags[mandatory_tag] else null != null
  }
}

Cette politique s'intègre dans votre pipeline CI/CD comme une barrière de sécurité. Si une ressource est déployée sans la balise, le pipeline échoue, empêchant les modifications non suivies d'atteindre la production.

Cette approche vous offre deux choses. Premièrement, des limites claires qui ne reposent pas sur la discipline humaine. Deuxièmement, des pistes d'audit automatiques. Chaque décision de politique est enregistrée : qui a essayé de modifier quoi, quand, d'où, et si cela a été autorisé ou refusé.

Concevoir des politiques qui ne cèdent pas sous la pression

Une erreur courante est de rendre les politiques trop rigides. Si votre politique bloque toute modification manuelle sans exception, vous créerez une situation où les ingénieurs trouveront des moyens de la contourner complètement. Ou pire, ils auront peur d'agir lors de véritables urgences.

La solution est de concevoir des politiques en tenant compte de la réalité opérationnelle.

Un modèle est le mécanisme de break-glass. Dans certaines situations d'urgence définies, un ingénieur peut outrepasser une politique. Le dépassement est enregistré avec une raison, et après l'incident, l'équipe examine si la modification doit être adoptée dans l'IaC ou annulée. Cela vous donne de la sécurité sans paralysie.

Un autre modèle consiste à classer les modifications par risque. Les modifications à faible risque comme l'ajout de balises, la mise à jour de descriptions ou la modification de configurations non critiques peuvent être autorisées librement. Les modifications à haut risque comme la modification de l'accès réseau, des politiques de sécurité ou des configurations de base de données doivent passer par le pipeline. Le moteur de politique applique cette distinction automatiquement, vous n'avez donc pas besoin d'un humain pour décider à chaque fois.

Relier la politique à la détection de dérive

La politique et la détection de dérive fonctionnent mieux lorsqu'elles sont connectées. Voici comment le flux se présente en pratique.

Votre scanner de dérive s'exécute régulièrement et trouve des différences entre vos définitions IaC et l'infrastructure réelle. Au lieu de signaler chaque différence comme un problème, le système vérifie chaque différence par rapport à vos politiques.

Le diagramme suivant illustre comment l'application des politiques et la détection de dérive interagissent dans une boucle de gouvernance continue.

flowchart TD A[Pipeline IaC] -->|Déploiement| B[Infrastructure] C[Modification manuelle] -->|Urgence ou action directe| B B -->|Scanner de dérive| D{Dérive détectée ?} D -->|Oui| E[Moteur de politique] D -->|Non| F[Aucune action] E --> G{Vérification de politique} G -->|Exception approuvée| H[Marquer comme connue et autorisée] G -->|Violation| I[Signaler pour correction] G -->|Aucune correspondance| J[Mettre en file d'attente pour révision manuelle] H --> K[Révision post-incident] I --> K J --> K K -->|Adopter dans IaC| A K -->|Annuler| B

Si la modification a été effectuée via une exception de politique approuvée, elle est marquée comme "connue et autorisée". Si la modification viole une politique, elle est signalée pour correction immédiate. Si la modification ne correspond à aucune règle de politique, elle est placée dans une file d'attente pour révision manuelle.

Cela change la façon dont votre équipe perçoit la dérive. La dérive n'est plus simplement une erreur à corriger. C'est un signal à interpréter. S'agit-il d'une modification d'urgence légitime qui n'a pas encore été adoptée dans le code ? S'agit-il d'une violation de politique ? S'agit-il d'une modification qui aurait dû passer par le pipeline mais ne l'a pas fait ?

Avec la politique et la gouvernance en place, vous pouvez distinguer ces cas sans enquêter manuellement sur chacun d'eux. Et parce que les politiques sont écrites en code, elles peuvent être révisées, versionnées et testées comme n'importe quel autre code. Ce ne sont pas des documents poussiéreux dans un dossier partagé.

Liste de contrôle pratique pour la gouvernance basée sur les politiques

Si vous mettez en place une politique et une gouvernance pour les modifications d'infrastructure, voici une courte liste de contrôle à suivre :

  • Identifiez les types de modifications les plus risqués dans votre environnement (groupes de sécurité, configurations de base de données, rôles IAM)
  • Écrivez des politiques qui bloquent ces modifications en dehors du pipeline, avec des chemins d'exception clairs
  • Implémentez un mécanisme de break-glass pour les urgences, avec une révision post-incident obligatoire
  • Connectez votre moteur de politique à vos outils de détection de dérive
  • Classez les modifications par niveau de risque et appliquez des règles différentes en conséquence
  • Mettez en place une journalisation d'audit automatique pour chaque décision de politique
  • Révisez régulièrement les exceptions de politique et adoptez-les dans l'IaC ou annulez-les

L'essentiel à retenir

La dérive d'infrastructure n'est pas un problème que vous résolvez une fois pour toutes. C'est une condition que vous gérez en continu. L'objectif n'est pas d'éliminer toutes les modifications manuelles, mais de les connaître, de les gouverner et de décider lesquelles doivent devenir des parties permanentes de votre infrastructure.

La politique en tant que code vous offre un moyen d'appliquer des limites sans bloquer le travail légitime. La détection de dérive vous donne une visibilité sur ce qui se passe réellement. Ensemble, ils transforment la gestion de l'infrastructure d'un combat réactif en un système auquel vous pouvez faire confiance, même quand les choses tournent mal à 2 heures du matin.