Durcis la chaîne de sauvegarde et prouve une restauration

01Modélise toute la chaîne

source métier
→ compte d'écriture
→ dépôt primaire
→ compte de réplication
→ dépôt isolé
→ opérateur de restauration
→ destination jetable
→ vérification fonctionnelle

Le contrôle ne porte pas uniquement sur les fichiers. Il porte aussi sur les identités, les droits, les chemins et la capacité de retour.

02Manipule les rôles

lab=/tmp/soria-hardening-lot1-$USER
bash module1-baseline-change-recovery.sh setup "$lab"
bash module1-baseline-change-recovery.sh run "$lab"

column -s, -t "$lab/source/backup/backup-roles.csv"
column -s, -t "$lab/output/backup-role-review.csv"

Quatre rôles synthétiques sont séparés :

svc_backup_writer       écrit dans primary
svc_backup_replication  lit primary et écrit isolated
backup_policy_admin     gère politique et rétention
restore_operator        lit isolated et écrit dans restore

Aucun rôle ne combine administration de production et suppression du dépôt isolé.

03Observe les deux dépôts

column -s, -t "$lab/source/backup/repository-policy.csv"
column -s, -t "$lab/output/repository-assurance.csv"

Le dépôt isolated déclare :

rétention 90 jours
immutabilité yes
hors site yes
simulation readonly-permissions

Mais le rapport conclut WITH_ACTIONS.

Pourquoi ? Une déclaration et des permissions locales en lecture seule ne prouvent pas :

• un verrouillage WORM ;
• une rétention impossible à réduire par un administrateur ;
• une séparation de compte réelle ;
• une localisation hors site ;
• une résistance à la compromission du plan de management.

04Crée le point de restauration

Le lab copie trois éléments synthétiques :

app/config/app.conf
data/orders.csv
identity/users.csv

vers :

primary/snapshot-2026-08-05
→ isolated/snapshot-2026-08-05

Puis il rend les fichiers du dépôt isolé non modifiables par permissions locales.

Cette opération sert uniquement à tester le workflow.

05Examine le manifeste

column -s, -t "$lab/output/backup-manifest.csv"

Colonnes :

relative_path
size_bytes
mode
uid
gid
sha256

Le hash vérifie le contenu. La taille, le mode et les identifiants numériques représentent des métadonnées utiles.

Selon l’application, il faudrait aussi conserver :

• ACL ;
• attributs étendus ;
• liens ;
• propriétaire applicatif ;
• cohérence transactionnelle ;
• version de schéma ;
• dépendances et secrets nécessaires.

06Restaure vers une destination jetable

find "$lab/restore/snapshot-2026-08-05" -type f -print
column -s, -t "$lab/output/restore-manifest.csv"
column -s, -t "$lab/output/restore-comparison.csv"

Le lab ne restaure jamais par-dessus la source.

Cette séparation évite :

• d’écraser un état utile ;
• de confondre source et résultat ;
• de cacher un fichier manquant ;
• d’altérer la preuve.

07Vérifie l’intégrité et les métadonnées

cmp "$lab/output/backup-manifest.csv" "$lab/output/restore-manifest.csv"

Le validateur exige trois résultats MATCH.

Il vérifie aussi les contenus fonctionnels représentés :

awk 'END { print NR - 1 }' "$lab/restore/snapshot-2026-08-05/data/orders.csv"
awk 'END { print NR - 1 }' "$lab/restore/snapshot-2026-08-05/identity/users.csv"
grep 'service=erp-api' "$lab/restore/snapshot-2026-08-05/app/config/app.conf"

Le hash seul ne prouve pas que l’application sait utiliser les données.

08Observe le test négatif de corruption

Pendant validate, le lab crée une copie du manifeste de restauration et remplace un hash par des zéros.

La comparaison doit échouer :

Negative test blocked: tampered restore manifest

Si la variante corrompue passe, le lab entier échoue.

Ce principe empêche un test qui ne vérifie que la présence des fichiers.

09Rends une décision honnête

cat "$lab/output/final-decision.txt"
cat "$lab/output/restore-report.md"

Résultat de référence :

RESTORE_WITH_ACTIONS

Le contenu, la taille, les modes, UID et GID représentés correspondent. Les actions restantes concernent les preuves réelles.

RESTORE_VERIFIED

Utilisable seulement si toutes les preuves exigées par la politique du périmètre sont présentes.

RESTORE_WITH_ACTIONS

La restauration technique bornée réussit, mais des preuves ou validations externes restent nécessaires.

RESTORE_BLOCKED

Obligatoire si un hash, fichier, mode, propriétaire représenté, rôle ou rollback échoue.

10Relie la restauration au changement

Avant un patch critique :

point de restauration sélectionné
manifest conservé
destination de test disponible
opérateur et accès de secours connus
test de restauration réussi
limites acceptées
rollback référencé dans le ticket

« Un backup existe » ne suffit pas pour autoriser le changement.

11Mesure ce qui compte

Sur un environnement autorisé, le test doit enregistrer :

• heure de départ ;
• heure de disponibilité technique ;
• heure de validation métier ;
• quantité restaurée ;
• écarts ;
• dépendances manquantes ;
• intervention manuelle ;
• RPO observé ;
• RTO observé.

Ce lab ne fabrique pas ces mesures.

12Nettoie le périmètre

bash module1-baseline-change-recovery.sh reset "$lab"
test ! -e "$lab"

Le reset exige le marqueur et refuse /tmp, $HOME et les chemins hors motif autorisé.