Lors de la conception du système de collecte de preuves, une tentation revenait naturellement : ajouter un bouton qui corrige directement chaque écart détecté.
Sur le papier, l’expérience paraît meilleure. Le scanner trouve un accès public, une option d’authentification ou un paramètre de sécurité ; l’utilisateur clique ; le problème disparaît.
Je n’ai pas retenu ce modèle.
Le scanner fonctionne avec des permissions de lecture. Il observe, qualifie et propose. Les corrections vivent dans un dépôt distinct, sous une identité d’écriture séparée, avec un plan Terraform et une approbation.
Observer n’autorise pas à modifier
Le droit d’observer un environnement ne doit pas donner implicitement le droit de le modifier. Un responsable de plateforme peut accepter un outil en lecture là où un composant disposant de droits d’écriture serait légitimement refusé.
Une correction apparemment simple peut aussi casser un consommateur existant. Fermer un accès public, désactiver une authentification locale ou modifier une propriété de réseau exige de connaître les dépendances. L’outil peut produire une recommandation et préparer un plan ; il ne peut pas inventer l’acceptation du risque métier.
Conserver la chaîne de décision
La séparation améliore également la preuve. Dans le modèle retenu, le constat initial, le plan, l’approbation, l’application et le nouveau scan doivent former une chaîne relisible. Si le scanner corrige silencieusement au moment où il observe, l’état avant devient plus difficile à conserver et la responsabilité de la modification plus floue.
- Scan en lecture seule.
- Export des écarts approuvés.
- Plan sous une identité d’écriture dédiée.
- Revue humaine.
- Application des changements autorisés.
- Nouveau scan.
Les modifications considérées comme risquées restent soumises à une validation dédiée. Certaines corrections ne sont d’ailleurs pas automatisables proprement : changer de région ou transformer un cluster public en cluster privé relève d’un travail d’architecture, pas d’un bouton.
L’automatisation est utile lorsqu’elle rend une décision plus sûre et plus répétable. Elle devient dangereuse lorsqu’elle masque la décision qu’elle est en train de prendre.
Vérifier la séparation
Contrôle minimalLa séparation est prouvée par les identités et les artefacts, pas seulement par deux dépôts.
- Examiner les permissions effectives de l’identité du scanner et vérifier que son exécution ne dispose d’aucun droit de modification.
- Confirmer que l’identité de remédiation est distincte et inaccessible au processus d’exécution du scanner.
- Relier les identifiants du scan initial, de l’export, du plan, de l’approbation, de l’application et du nouveau scan.
- Rejouer un cas refusé ou sans changement et vérifier qu’aucune modification n’est appliquée.
Frontière de preuveActif public. Le modèle de séparation, les points d’approbation et leurs limites sont documentés dans Azure AI Assurance Remediations.