Projet final — Durcis l'infrastructure de SORIA Distribution

01Installe le dossier de travail

lab=/tmp/soria-hardening-assurance-project-$USER
bash module6-soria-hardening-project.sh setup "$lab"
bash module6-soria-hardening-project.sh status "$lab"

Le lab ne touche aucun système réel. Les dix-huit fixtures représentent le portefeuille final de SORIA Distribution et relient les acquis des Lots 1 à 5.

02Relis l’inventaire et les exigences

column -s, -t "$lab/source/portfolio/assets.csv"
column -s, -t "$lab/source/portfolio/requirements.csv"

Le dossier couvre baseline, identité, Linux, Windows/AD, réseau, endpoint, conteneur, Kubernetes et sauvegarde/reprise. Chaque exigence a un propriétaire, une criticité et une chaîne de preuve.

Livrable A — périmètre

Produis une page qui distingue :

• actifs critiques et propriétaires ;
• fonctions métier indispensables ;
• contrôles cibles ;
• dépendances entre lots ;
• preuves réelles encore nécessaires.

03Construis les vagues de changement

column -s, -t "$lab/source/change/waves.csv"
column -s, -t "$lab/source/change/prechecks.csv"
column -s, -t "$lab/source/change/rollback.csv"

Une vague n’est READY ou READY_WITH_ACTIONS que si ses dépendances, préchecks, critères d’arrêt et rollback sont définis. La présence d’un rollback dans un document ne prouve pas qu’il fonctionne sur un système réel.

Livrable B — plan en vagues

Pour chaque vague, explique l’ordre, les préchecks, la condition d’arrêt, la fonction métier à préserver et la méthode de retour arrière.

04Assemble les preuves par domaine

bash module6-soria-hardening-project.sh run "$lab"
column -s, -t "$lab/output/evidence-matrix.csv"

La matrice consolide les sorties conceptuelles des lots précédents sans les transformer en preuves de production. Windows reste en partie DECLARED; les autres contrôles de référence sont essentiellement SYNTHETIC.

Livrable C — matrice de preuves

Pour chaque contrôle critique, indique : preuve disponible, niveau de preuve, trois tests, rollback et limite.

05Défends les fonctions métier

column -s, -t "$lab/output/positive-test-report.csv"
column -s, -t "$lab/output/functional-test-report.csv"

Le dossier doit préserver au minimum :

• HTTPS public ;
• DNS interne ;
• chaîne web → application → données ;
• administration via WireGuard/MGMT ;
• service Windows/AD ;
• accès Linux nécessaire ;
• exécution conteneur non privilégiée ;
• flux Kubernetes nécessaires ;
• restauration représentée.

Livrable D — tests

Explique pourquoi un contrôle qui bloque le trafic interdit mais casse DNS ou l’application doit être considéré en échec.

06Examine les refus

column -s, -t "$lab/output/negative-test-report.csv"

Les dix familles négatives simulent les erreurs qui rendent un dossier non défendable : preuve absente, test faussement vert, régression, exception expirée, compensation inefficace, dérive en retard, rollback absent ou décision READY sur des preuves synthétiques.

Livrable E — analyse d’échec

Choisis trois variantes négatives et décris le risque qu’elles représentent dans une vraie opération de durcissement.

07Traite les écarts et exceptions

column -s, -t "$lab/output/gap-register.csv"
column -s, -t "$lab/output/exception-register.csv"
column -s, -t "$lab/output/compensating-controls-review.csv"
column -s, -t "$lab/output/drift-review.csv"

Le projet n’essaie pas de produire un tableau entièrement vert. Les preuves réelles manquantes sont maintenues comme actions ou exceptions bornées.

Livrable F — registre de décision

Pour chaque écart restant, indique remédiation, échéance, éventuelle exception, contrôle compensatoire et date de revue.

08Intègre sauvegarde et restauration

column -s, -t "$lab/source/recovery/backup-controls.csv"
column -s, -t "$lab/output/recovery-review.csv"

Un durcissement qui empêche la reprise ou dont le rollback est impossible n’est pas maîtrisé. Le lab exige un test de restauration représenté, puis prouve séparément le rollback de ses propres fixtures par manifeste.

cat "$lab/output/rollback-report.txt"
cmp "$lab/output/rollback-manifest-before.csv" \
    "$lab/output/rollback-manifest-restored.csv"

Livrable G — reprise

Documente RPO, RTO, isolation attendue, test de restauration, preuve disponible et preuve réelle manquante.

09Lis ce qui manque encore

column -s, -t "$lab/source/assurance/real-evidence-required.csv"
cat "$lab/output/proof-boundaries.md"

Le dossier ne peut pas devenir READY tant que les contrôles réels Linux, Windows/AD, OPNsense/WireGuard, conteneur, Kubernetes et sauvegarde/reprise n’ont pas été observés dans un environnement autorisé.

10Rends la décision

cat "$lab/output/decision-rationale.csv"
cat "$lab/output/final-decision.txt"

La référence retourne :

READY_WITH_ACTIONS

Cette décision signifie que la structure du dossier, les preuves synthétiques, les refus et la gouvernance sont cohérents, mais qu’une validation réelle reste nécessaire avant de parler de durcissement effectif.

11Présente le dossier final

cat "$lab/output/final-dossier.md"

Restitution attendue

Prépare une présentation de 15 à 20 minutes comprenant :

1. périmètre et actifs critiques ;
2. principaux écarts initiaux ;
3. baselines et chemins privilégiés ;
4. contrôles Linux et Windows/AD ;
5. réseau, WireGuard, endpoints, conteneurs et Kubernetes ;
6. sauvegarde et reprise ;
7. tests positifs, négatifs et fonctionnels ;
8. exceptions et compensations ;
9. rollback ;
10. décision et actions restantes.

12Valide et nettoie

bash module6-soria-hardening-project.sh validate "$lab"
bash module6-soria-hardening-project.sh reset "$lab"
test ! -e "$lab"

Le reset ne supprime que la racine marquée du lab.