Remédiation Terraform : planifier, approuver, appliquer, puis revalider

Transformer automatiquement des constatations en variables Terraform peut accélérer une mission. Cette automatisation n’est sûre que si elle préserve une séparation nette entre les données du scan, le code versionné, l’approbation humaine et la revalidation.

Garder le code statique et versionné

Le fichier Terraform principal ne devrait pas être généré à chaque scan. Il reste relu, testé et versionné. Seul un fichier de données décrit les constatations de l’engagement : ressource ciblée, propriété attendue, niveau de sécurité et référence de preuve. Le plan produit alors un diff compréhensible au lieu d’exécuter du code nouvellement fabriqué.

Trois voies de traitement

1. Prévention. Une politique empêche le retour d’un écart ou hérite une valeur obligatoire, par exemple un tag depuis le groupe de ressources.
2. Patch contrôlé. Une propriété d’une ressource existante est modifiée en place, par exemple l’accès public, l’authentification locale ou la protection de purge.
3. Fondation additive. Un service manquant est ajouté, comme un budget ou un composant de supervision.

Les changements impliquant une recréation ou une migration restent du travail d’architecture. Les inclure dans une correction automatique masquerait leur véritable impact.

Séparer changements sûrs et changements sensibles

Une correction additive et non destructive peut être appliquée en lot après examen. Une modification susceptible de couper un accès ou de modifier l’authentification doit être planifiée mais exclue de l’application par défaut. Elle nécessite une approbation dédiée, une fenêtre de changement, un plan de retour et un test fonctionnel.

Le cycle complet

1. Exécuter le scan en lecture seule et conserver le snapshot.
2. Exporter les constatations sous forme de données de remédiation.
3. Générer puis examiner le plan Terraform.
4. Approuver les changements sûrs et, séparément, chaque changement sensible.
5. Appliquer avec une identité d’écriture limitée et traçable.
6. Rejouer le scan et les tests runtime.
7. Comparer les scores, fermer les écarts et archiver les preuves.

Actif de méthode associé : azfit-remediations. Sa valeur réside dans la fermeture contrôlée des écarts. Le code Terraform reste un backend interne ; le client achète le résultat vérifié.

Attention au sens de « destroy »

Lorsqu’un patch AzAPI modifie une ressource existante, l’état Terraform peut servir de journal de changement sans être une représentation complète de la ressource. Un terraform destroy ne constitue donc pas nécessairement un rollback. Le retour arrière doit être conçu et testé comme une opération distincte.

Vérifier ce point dans votre environnement

Ce que cela change à l’échelle d’un grand compte

• Le diff est le document de gouvernance. Un plan Terraform lisible, borné aux données de l’engagement, est ce qu’un comité de changement peut réellement approuver — pas un script opaque.
• Les recréations restent du travail d’architecture. Masquer une migration derrière une « correction automatique » en masque le vrai impact. La frontière entre patch et refonte doit être explicite dans l’outillage.
• La revalidation ferme la boucle. Constat → plan → approbation → apply → re-scan : chaque maillon produit un artefact daté. C’est cette chaîne, pas la correction elle-même, qui constitue la preuve.

Frontière de preuveNote de méthode. La chaîne décrite est celle du dépôt public Azure AI Assurance Remediations, exercée sur un environnement de laboratoire Geek Guru (budget et politiques de tags appliqués, patch sensible volontairement laissé en attente d’approbation). Aucun environnement client n’est concerné.