- Contexte
- La tentation du bouton « corriger automatiquement » dans un outil d’audit
- Constat
- Observation, décision et écriture ne doivent jamais partager la même identité
- Pour qui
- RSSI, responsable plateforme, acheteur d’un audit outillé
- Preuve
- Note d’architecture — modèle publié dans Azure AI Assurance Remediations
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.
Principe de contrôle : découvrir avec une identité en lecture seule, décider avec le client, modifier avec une identité d’écriture temporaire, puis revalider avec la chaîne de lecture.
Actifs de méthode associés : Fitness Board et azfit-remediations. Le premier observe et produit le plan ; le second porte les changements approuvés dans une chaîne séparée.
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é.
La même décision, racontée côté conception de l’outil — pourquoi le bouton n’a jamais été construit — est dans « Pourquoi mon scanner ne corrige rien tout seul ». Ce texte-ci en donne la version architecture : ce qu’un client doit exiger du dispositif.
Vérifier ce point dans votre environnement
Ce qu’il faut exiger d’un outil d’audit outilléQuatre exigences vérifiables avant d’accorder un accès à votre souscription.
- L’identité de collecte ne porte que des rôles de lecture (Reader, Monitoring Reader, Security Reader, Cost Management Reader) — vérifiable dans les attributions de rôles.
- Toute remédiation passe par une identité distincte, créée pour la mission, limitée au périmètre, supprimable à la fin.
- Le dépôt de remédiation vit dans votre organisation : votre état Terraform, vos protections de branche, votre environnement d’approbation.
- L’outil ne peut pas corriger silencieusement un écart avant de produire son rapport — la séparation des identités le garantit structurellement, pas la promesse de l’éditeur.
Frontière de preuveNote d’architecture. Le modèle décrit — collecte en lecture seule, écriture fédérée OIDC dans la chaîne du client, approbation avant application — est publié dans Azure AI Assurance Remediations et exercé en laboratoire. Ce texte ne décrit pas un déploiement client de ce dispositif.
Si un outil d’audit vous demande aujourd’hui des droits d’écriture, la discussion mérite d’avoir lieu avant la signature.