Le bouton « corriger automatiquement » paraît séduisant. Dans un environnement client, il concentre pourtant l’observation, la décision et l’écriture dans le même système. Une erreur de classification, une permission trop large ou une compromission peut alors transformer un outil d’audit en mécanisme de changement incontrôlé.
La collecte doit rester en lecture seule
Le composant d’évaluation a besoin de lire les métadonnées Azure, les signaux de supervision, la posture de sécurité et les informations de coûts. Des rôles comme Reader, Monitoring Reader, Security Reader ou Cost Management Reader couvrent ce besoin sans lui permettre de modifier les ressources.
Cette séparation protège le client et améliore aussi la qualité de la preuve : le même composant ne peut pas corriger silencieusement un écart avant de produire son rapport.
L’écriture appartient à une autre chaîne de confiance
Une remédiation doit utiliser une identité différente, créée pour la mission, limitée au périmètre concerné et supprimable à la fin. L’idéal est une fédération OIDC depuis la pipeline du client, sans secret Azure permanent stocké dans GitHub.
Le dépôt de remédiation doit vivre dans l’organisation du client avec son propre état Terraform, ses protections de branche, son environnement d’approbation et son historique. Le commanditaire conserve ainsi la maîtrise du plan et de l’application.
Une constatation n’est pas toujours auto-corrigeable
Certains écarts sont additifs et peu risqués, comme la création d’un budget. D’autres peuvent interrompre un consommateur existant : désactivation de l’accès public, changement du mode d’authentification ou modification d’une propriété critique. Enfin, une migration de région, la conversion d’un cluster en privé ou un changement de zone peuvent nécessiter une reconstruction complète.
Un système responsable doit donc savoir répondre « correction architecturale nécessaire » au lieu de prétendre tout réparer automatiquement.
Le vrai livrable est la preuve du résultat
Le Terraform n’est pas la fin de la mission. Le dossier attendu relie la constatation initiale, le plan approuvé, le commit appliqué, l’identité utilisée, le résultat de pipeline et le scan de vérification. Sans cette dernière étape, une application réussie ne prouve pas que le risque est effectivement fermé.