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