« Le fichier de configuration contient la bonne valeur, donc le contrôle est prouvé. »
Une configuration peut être présente, ignorée, contournée ou casser le service. Une preuve utile montre ce qui doit fonctionner, ce qui doit être refusé et ce qui doit rester disponible.
01Pars d’une exigence testable
lab=/tmp/soria-hardening-assurance-project-$USER
bash module6-soria-hardening-project.sh setup "$lab"
column -s, -t "$lab/source/portfolio/requirements.csv"Chaque ligne relie un contrôle à un actif, un propriétaire, une criticité, une preuve, trois tests et un rollback. L’identifiant stable permet de suivre le même contrôle de la baseline au dossier final.
02Observe la preuve disponible
column -s, -t "$lab/source/portfolio/control-evidence.csv"Le champ proof_level distingue SYNTHETIC, DECLARED, OBSERVED et EXECUTED. Dans ce lab, une fixture cohérente reste une preuve synthétique. Une ligne décrivant une GPO ne prouve pas son application sur win-dc-01.
03Teste le chemin autorisé
awk -F, '$2=="positive" || NR==1' "$lab/source/tests/test-catalog.csv" | column -s, -tUn test positif vérifie l’effet attendu : présence d’une baseline, chemin d’administration autorisé, service HTTPS requis ou politique restrictive représentée.
Un contrôle qui bloque tout peut réussir un test de refus tout en étant inutilisable. Le test positif évite cette illusion.
04Teste le refus
awk -F, '$2=="negative" || NR==1' "$lab/source/tests/test-catalog.csv" | column -s, -tLe test négatif porte sur l’action interdite : administration depuis une zone non fiable, privilège excessif, Pod privilégié ou référence inconnue. Le résultat attendu du lab est BLOCKED, pas simplement « aucune erreur visible ».
05Teste la fonction métier
awk -F, '$2=="functional" || NR==1' "$lab/source/tests/test-catalog.csv" | column -s, -t
column -s, -t "$lab/source/portfolio/business-flows.csv"La fonction métier doit survivre au contrôle : HTTPS public, DNS, flux applicatif, administration via WireGuard/MGMT, service de domaine, workload Kubernetes et restauration représentée.
06Exécute le portefeuille de tests
bash module6-soria-hardening-project.sh run "$lab"
column -s, -t "$lab/output/test-summary.csv"Les résultats de référence exigent PASS pour les tests positifs et fonctionnels, et BLOCKED pour les tests négatifs. Le validateur refuse un FAIL, un résultat absent ou un test obligatoire non relié.
07Observe une preuve négative utile
column -s, -t "$lab/output/negative-test-report.csv"Les dix variantes négatives altèrent volontairement une copie des fixtures. Elles vérifient notamment qu’un test négatif déclaré PASS, une régression fonctionnelle ou une exigence sans preuve ne peuvent pas aboutir à une décision favorable.
08Construis la matrice d’assurance
column -s, -t "$lab/output/evidence-matrix.csv"
cat "$lab/output/coverage-summary.csv"La matrice sert de chaîne de traçabilité : exigence → actif → preuve → tests → rollback → limite. Une capture d’écran isolée ou un simple extrait de documentation ne remplace pas cette relation.
09Écris la limite en même temps que la preuve
cat "$lab/output/proof-boundaries.md"Une limite de preuve n’est pas une faiblesse du dossier : elle empêche de transformer un test CI sur fichier en affirmation sur un pare-feu, un domaine Active Directory ou un cluster réel.
10Valide puis conserve le raisonnement
bash module6-soria-hardening-project.sh validate "$lab"
cat "$lab/output/decision-rationale.csv"Le résultat du contrôle devient défendable parce que l’on sait ce qui a été testé, comment l’échec serait détecté et ce qui n’a pas été observé.
Évalue un contrôle sans faux vert
Choisis une exigence critique de la matrice. Explique le test positif, le refus attendu, le test fonctionnel, le rollback et la preuve réelle qu’il faudrait encore collecter hors CI.
✓À retenir
Un contrôle n’est pas prouvé par sa seule présence. Une assurance utile relie exigence, preuve, test positif, test négatif, test fonctionnel, rollback et limite de preuve.