Réconcilier inventaire IaC et cloud réel

Réconcilier inventaire IaC et cloud réel

L’infrastructure as code (IaC) promet un état reproductible, relu et versionné. Cette promesse tient uniquement tant que tout changement passe par le code, ce qui cesse d’être vrai dès qu’une console cloud reste accessible à une personne pressée ou qu’une correction d’urgence n’est jamais réintégrée.

Explication de la marmotte

Un plan de bâtiment peut être parfaitement rangé dans un classeur tandis que des portes, des pièces et des câbles ont été ajoutés sur place sans l’indiquer. Le problème n’est pas seulement de perdre le plan : il devient impossible de savoir quelles ouvertures doivent réellement être surveillées.

→ Lire l’explication complète de la marmotte

L’inventaire déclaré n’est pas l’inventaire exécutable

L’état déclaré est le contenu versionné de Terraform, CloudFormation ou d’un outil équivalent. Il décrit les ressources que le pipeline est autorisé à créer et les propriétés attendues : réseaux, règles de filtrage, comptes de service, journaux, chiffrement, étiquettes et politiques de rétention. L’état réel est l’ensemble des ressources et paramètres que le fournisseur cloud expose via ses interfaces de programmation et sa console.

Ces deux ensembles divergent pour trois raisons récurrentes :

1. une ressource gérée par IaC est modifiée directement ;
2. une ressource est créée hors IaC ;
3. une ressource attendue par IaC n’existe plus ou n’est plus accessible.

La dérive de configuration, ou configuration drift, désigne le premier cas. Un groupe de sécurité reçoit une règle temporaire, une journalisation est désactivée pour diagnostiquer un incident, un chiffrement est modifié pour contourner une dépendance. La correction peut être techniquement justifiée à l’instant où elle est faite. Elle devient une dette de sécurité dès qu’elle ne retourne pas dans le dépôt.

Le compromis central est net : interdire les mutations manuelles ralentit la correction immédiate, mais rend l’état contrôlable et reconstruisible. Autoriser les exceptions console accélère parfois les premières minutes d’un incident, puis crée des semaines d’incertitude. La recommandation est donc stricte : aucune modification persistante ne doit être effectuée hors pipeline IaC, y compris en urgence. Une procédure d’urgence doit produire un changement de code accéléré, pas une trace archéologique dans l’historique d’audit.

Terraform détecte une partie de cette dérive avec plan -refresh-only. CloudFormation peut détecter la dérive sur les ressources prises en charge. Aucun des deux ne découvre, par nature, une ressource créée hors de son périmètre. Un bucket créé depuis la console n’apparaît pas magiquement dans un état Terraform. La magie reste un mauvais protocole d’inventaire.

Cette distinction sépare le sujet de la persistance IAM. Une politique d’identité anormale est un problème de privilèges. Une base de données publique créée avec une identité légitime est d’abord un problème d’inventaire et de chemin de création. Les deux se croisent, mais les confondre laisse des trous dans les contrôles.

Les causes de dérive qui survivent aux revues de code

La modification d’urgence est le scénario le plus visible. Un opérateur ajoute une règle entrante, modifie un paramètre de chiffrement ou augmente une capacité. Le service repart, l’alerte disparaît, puis la modification survit parce qu’aucun mécanisme ne force sa transcription dans le code. Le prochain apply peut l’écraser, ou pire, ne jamais toucher cette propriété et laisser l’exception vivre indéfiniment.

Les ressources créées hors pipeline sont plus dangereuses. Elles ne dérivent pas du code, elles n’y ont jamais existé. Une clé d’interface applicative, une machine virtuelle de diagnostic, un registre d’images, une fonction serverless ou une passerelle réseau peuvent être créés avec des droits console directs. Si les conventions d’étiquetage sont absentes ou facultatives, la ressource peut même devenir orpheline de son propriétaire fonctionnel.

Les droits d’administration permanents rendent cette création possible. Un contrôle d’accès basé sur les rôles, ou RBAC (Role-Based Access Control), bien dessiné ne suffit pas s’il octroie à des humains le droit de créer des ressources dans les comptes de production sans imposer le chemin IaC. RBAC répond à « qui peut appeler l’interface ». Il ne répond pas à « quelle modification est déclarée, revue et traçable ». Ce second contrôle doit être porté par les permissions, les journaux et les règles d’organisation.

Une architecture saine sépare trois identités :

• l’identité du pipeline IaC, seule autorisée à créer ou modifier les types de ressources gérés ;
• les identités humaines de lecture et de diagnostic ;
• une identité break-glass, fortement journalisée, à durée limitée et réservée aux actions qui restaurent un service sans créer de dette silencieuse.

L’identité break-glass ne doit pas contourner l’obligation de réconciliation. Toute action réalisée avec elle doit ouvrir automatiquement un événement de suivi et déclencher une comparaison ciblée. Sans cela, le compte d’urgence devient le placard où l’on range les câbles qui dépassent.

Les prérequis sont concrets : journal d’audit activé dans toutes les régions, y compris celles déclarées inutilisées ; export centralisé et protégé contre l’altération ; inventaire natif du fournisseur ; dépôt IaC avec état distant verrouillé ; identités de pipeline fédérées plutôt que clés statiques ; et compte ou abonnement de sécurité capable de lire l’ensemble des environnements. La page cloud couvre le cadre d’exploitation général, mais la réconciliation doit être traitée comme un contrôle autonome.

Ce qu’un CSPM voit, et ce qu’il ne voit pas

Un outil de gestion de posture de sécurité cloud, ou CSPM (Cloud Security Posture Management), collecte des métadonnées depuis les interfaces du fournisseur, puis évalue des règles : stockage public, chiffrement désactivé, ports ouverts, journalisation absente, clés trop anciennes ou politiques trop permissives. C’est nécessaire. Ce n’est pas un inventaire absolu.

Un CSPM voit ce que ses connecteurs savent interroger, avec le niveau de permission accordé et au rythme de collecte configuré. Une ressource créée après le dernier scan est absente jusqu’au scan suivant. Un service émergent peut ne pas être pris en charge. Une propriété spécifique peut être collectée mais non évaluée. Une région non activée dans le connecteur est un angle mort complet, même si le tableau de bord affiche 98 % de conformité avec une police très rassurante.

Le score de conformité est un ratio de règles évaluées, pas une preuve d’exhaustivité. Un score de 100 % signifie seulement que toutes les ressources connues par l’outil satisfont les règles actives à l’instant de l’évaluation. Il ne prouve ni que toutes les ressources existent dans son inventaire, ni que les règles couvrent toutes les menaces, ni que l’état sera identique une minute plus tard.

La surface d’attaque inclut donc le CSPM lui-même :

• permissions de lecture insuffisantes ou perdues ;
• connecteurs désactivés dans une région ou un compte ;
• latence entre création et collecte ;
• exclusions de règles jamais expirées ;
• API du fournisseur qui ne remontent pas toutes les propriétés ;
• compromis d’une identité pouvant créer une ressource puis réduire sa visibilité.

Les contre-mesures sont vérifiables. Comparer le nombre et les identifiants de ressources remontés par le CSPM avec l’inventaire natif du fournisseur. Surveiller les échecs de collecte, l’ancienneté du dernier scan et les permissions des connecteurs. Versionner les exceptions CSPM avec une date d’expiration. Enfin, déclencher une alerte sur les appels de création, modification et suppression, sans attendre qu’un score agrégé décide de devenir intéressant.

Le CSPM ne garantit pas qu’une ressource est déclarée dans IaC. Il ne garantit pas qu’une ressource conforme est légitime. Une machine chiffrée, privée et parfaitement étiquetée peut rester une persistance non autorisée. La conformité mesure des propriétés ; la réconciliation établit une provenance.

Réconciliation automatisée entre IaC et état réel

La réconciliation doit croiser trois sources indépendantes : l’état souhaité du dépôt, l’état géré par l’outil IaC et l’inventaire du fournisseur. Deux sources suffisent rarement. L’état Terraform, par exemple, peut être cohérent avec le code tout en ignorant une ressource créée manuellement.

Pour les ressources gérées, exécuter une détection de dérive à fréquence fixe et après chaque déploiement. Le résultat doit être exploitable : différence normalisée, propriétaire de la ressource, changement attendu ou non, délai de correction et escalade si la dérive concerne l’exposition réseau, les identités, le chiffrement ou les journaux.

Pour les ressources non gérées, imposer une règle de provenance. Chaque ressource doit porter une étiquette de dépôt, de composant, d’environnement et de propriétaire. Une ressource sans identifiant de déclaration est suspecte par défaut. L’étiquette seule ne constitue pas une preuve, car une identité compromise peut l’ajouter. Il faut aussi corréler sa création avec une exécution authentifiée du pipeline.

L’exemple suivant détecte, dans AWS, les groupes de sécurité créés par une identité différente du rôle de pipeline. Il s’appuie sur CloudTrail, le journal d’audit AWS, et sur l’interface de ligne de commande AWS CLI (Command Line Interface).

# Rechercher les créations de groupes de sécurité sur les dernières 24 heures.
# Remplacer IaCDeploymentRole par le rôle réellement utilisé par le pipeline.
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=CreateSecurityGroup \
  --start-time "$(date -u -d '24 hours ago' +%Y-%m-%dT%H:%M:%SZ)" \
  --end-time "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
  --query 'Events[?!contains(CloudTrailEvent, `IaCDeploymentRole`)].CloudTrailEvent' \
  --output text

Cette commande ne remplace pas un contrôle de production. Elle illustre la logique : détecter l’acte de création, identifier l’appelant, puis vérifier si l’événement correspond à une exécution de pipeline approuvée. En pratique, l’alerte doit être enrichie avec l’identifiant de compte, la région, le type de ressource, les étiquettes, l’exécution de pipeline associée et la criticité réseau.

Terraform doit être exécuté avec verrouillage d’état, version de fournisseur épinglée et permissions minimales. Une exécution de terraform plan -refresh-only sans verrou ou depuis un poste d’administration non maîtrisé produit parfois plus de confusion que de signal. La détection doit être en lecture seule ; la remédiation doit passer par une demande de changement IaC. Corriger automatiquement une dérive sans qualification peut rétablir une mauvaise configuration au milieu d’un incident. L’automatisation adore obéir, y compris quand l’ordre est mauvais.

Exploitation, rotation et reprise de l’inventaire

L’inventaire est un actif de sécurité. Il requiert sauvegarde, intégrité et reprise au même titre que l’état IaC. Sauvegarder les états distants, les journaux d’audit, les exports d’inventaire et les résultats de scans dans un stockage séparé du compte de production. Appliquer une rétention cohérente avec les besoins d’investigation et tester la restauration de l’état sans appliquer de changement.

Les secrets du pipeline doivent être réduits au minimum. Préférer une fédération d’identité à durée courte entre le système d’intégration continue et le fournisseur cloud. Une clé d’accès persistante capable de modifier toute l’infrastructure annule élégamment beaucoup de contrôles, puis attend son tour dans un historique de shell.

La rotation des identités de pipeline doit préserver la continuité de détection. Une rotation qui casse le connecteur CSPM ou le rôle de lecture central crée un trou de visibilité. Superviser explicitement la date de dernière collecte, le nombre de ressources par compte et région, les erreurs d’API, les échecs de détection de dérive et le volume de créations hors pipeline.

Le mécanisme ne garantit pas l’absence de compromission. Un attaquant doté des droits du pipeline peut produire du code apparemment légitime. La réponse relève alors de la protection de la chaîne de livraison, de la revue, de la signature des artefacts et de la séparation des rôles. De même, une ressource découverte n’est pas automatiquement malveillante : l’investigation doit vérifier la demande de changement, la provenance et l’usage réel avant suppression.

🐝 Ce qui arrive si on s’en passe

Sans réconciliation, l’inventaire cesse d’être une référence utilisable par les autres contrôles. Les campagnes de correctifs, les scans de vulnérabilités et les revues de chiffrement ne s’appliquent qu’aux ressources listées : ce qui n’a jamais été déclaré n’est jamais mis à jour, ni sauvegardé, ni couvert par un plan de reprise. Lors d’un incident, le périmètre devient invérifiable, car rien ne permet d’affirmer qu’un compte ou une région ne contient pas d’actif supplémentaire. La reconstruction depuis le code ne restitue alors qu’une partie de l’environnement, et les ressources orphelines survivent aux décommissionnements, aux fermetures de projet et aux départs de leurs créateurs. Les journaux d’audit conservent la trace de la création, mais plus personne ne dispose du contexte permettant de qualifier l’appelant, l’usage et la légitimité de l’objet.

🦫 Explication de la marmotte 🍫

Une infrastructure cloud contient des machines, des réseaux, du stockage, des comptes techniques et des réglages de sécurité. Une équipe peut décrire ces éléments dans des fichiers versionnés. Ces fichiers servent à créer et modifier l’infrastructure de façon répétable. Le problème commence quand une personne modifie directement un réglage dans l’interface du fournisseur, ou crée une nouvelle ressource sans passer par ces fichiers.

Les fichiers disent alors une chose, tandis que le cloud en fait une autre. Une règle réseau ajoutée pendant une urgence peut laisser un service accessible depuis Internet. Une nouvelle machine peut rester active sans responsable identifié. Une prochaine mise à jour automatisée peut aussi effacer une correction manuelle sans comprendre pourquoi elle existait.

Un outil de surveillance cloud examine les ressources visibles et cherche des réglages dangereux. Il est utile, mais il ne voit pas forcément une ressource très récente, un nouveau service mal pris en charge ou une zone qu’il n’a pas le droit de consulter. Son score ne prouve donc pas que tout a été vérifié.

La réponse consiste à comparer régulièrement les fichiers, l’état enregistré par l’outil de déploiement et la liste fournie par le cloud. Toute création doit être reliée à un déploiement autorisé. Toute différence doit être analysée puis corrigée dans les fichiers. Les journaux, les accès du pipeline, les sauvegardes et les alertes doivent aussi être surveillés, sinon le contrôle finit par surveiller une absence.

À lire aussi

• Comment gouverner les coûts cloud contre un compte compromisLa gouvernance des coûts cloud limite l'impact financier d'un compte compromis en complétant la détection, les identités et la réponse à incident.
• Quotas cloud contre le déni de service par coûtGérer les quotas et limites de ressources cloud pour réduire le risque de déni de service par abus de facturation.
• Configurer le moindre privilège sur un compte cloud existantGuide pratique pas-à-pas pour auditer puis restreindre progressivement les permissions d’un compte AWS, Azure ou GCP existant.
• Comment auditer la responsabilité partagée cloudLe modèle de responsabilité partagée du cloud répartit les contrôles entre fournisseur et client, mais ses zones grises concentrent les expositions de données et les erreurs d’accès.

Pages voisines

La citent

• Cloud IaaS, PaaS, SaaS et modèles de déploiement, qui sécurise quoi
• Sécurité multi-cloud et hybrid cloud
• Auditer l'héritage des permissions et le droit effectif
• CIS Benchmarks et CIS Controls en production
• Gestion réseau, supervision et référentiels d’exploitation

Réconcilier inventaire IaC et cloud réel

Elle cite

• ⇄Lien dans les deux sens :Sécuriser les providers et state Terraform
• Détecter la persistance IAM dans AWS
• Architecture de journalisation d’audit immuable centralisée
• Configurer GitHub Actions OIDC vers AWS sans clé statique

⇄ : les deux pages se citent l’une l’autre.