Synthèse de la partie IV : le retour sur l'état des lieux

La chaîne est construite, dans l'ordre où elle s'exécute : des méthodes choisies par population selon le sort du secret zéro et la confiance importée, des policies au moindre privilège écrites sur les chemins réels et testées par leurs refus, des tokens dont chaque paramètre est une défense, et une couche Identity qui unifie l'acteur derrière ses preuves.

Le chapitre 1 avait promis ce retour. Les sept constats d'Astrea, repris un par un.

1. Le mot de passe commité et jamais changé : réglé. Roté à la source, rangé en source unique versionnée, l'ancienne valeur détruite jusque dans ses versions, et plus aucun humain n'a besoin de le connaître.

2. Le même mot de passe en production et préproduction : réglé. Secrets distincts, arborescence séparée, et des policies qui rendent le cloisonnement mécanique : ci-deploy ne sait pas écrire un chemin de production.

3. Le secret en variable d'environnement systemd : réglé pour l'essentiel. L'application s'authentifie et lit à la demande, le token vit en fichier strict sur un système de fichiers en mémoire, une heure au plus. Le résiduel est le secret_id, borné à dix minutes et un usage.

4. La clé de paiement dans les journaux de CI : transformé plutôt que corrigé. La CI s'authentifie par jeton d'identité, sans aucun secret durable stocké dans la forge, ce que le chapitre 39 déploiera complètement.

5. Le wildcard TLS partagé : non traité ici. Il attend le chapitre 17, qui le rendra impossible par construction.

6. La clé SSH d'astreinte partagée : non traité ici. Il attend le chapitre 19.

7. La clé de sauvegarde dans le script : non traité ici. Il attend le chapitre 16.

Quatre constats sur sept sont soldés ou dissous, et l'imputabilité, qui n'existait pas, est désormais un champ dans chaque ligne d'audit. Les trois derniers appellent des moteurs de secrets, objet de la partie V.