« Si la sauvegarde se restaure, le service est de nouveau sûr. »
Une restauration technique ne démontre ni l’intégrité de la source, ni la sécurité de la configuration, ni la capacité du service à reprendre sans réintroduire le problème.
01Définis l’état de confiance
lab=/tmp/soria-ir-lot4-$USER
column -s, -t "$lab/source/recovery/trusted-state.csv"Un état de confiance est composé de critères explicites : image connue, configuration attendue, artefact vérifié, catalogue de sauvegarde, visibilité sécurité.
02Ne transforme pas l’inconnu en PASS
Le corpus conserve :
endpoint-edr = NOT_TESTABLECela signifie : le lab ne possède pas la preuve nécessaire. Il ne conclut ni healthy, ni compromised.
03Vérifie la source de restauration
column -s, -t "$lab/source/recovery/restore-plan.csv"Une source de restauration doit elle-même être reliée à un critère de confiance PASS et à un rollback.
04Teste fonctionnel et sécurité
column -s, -t "$lab/source/recovery/recovery-tests.csv"Le lab distingue :
PASS preuve représentée satisfaisante
FAIL readiness bloquée
NOT_TESTABLE preuve manquante, action requiseUn service qui répond HTTP 200 peut encore échouer un contrôle de sécurité.
05Inspecte la readiness
bash module4-containment-eradication-recovery.sh run "$lab"
column -s, -t "$lab/output/recovery-readiness.csv"
column -s, -t "$lab/output/recovery-test-results.csv"La décision finale reste :
RECOVERY_READY_WITH_ACTIONSElle ne signifie pas « production restaurée ».
06Relie reprise et continuité
La reprise technique doit être coordonnée avec les propriétaires métier. Le lab ne décide pas seul qu’un service peut reprendre ses opérations réelles.
Définis une readiness
Pour un actif, écris les critères de confiance, la source de restauration, deux tests de reprise et la condition qui bloque le retour en service.
✓À retenir
Récupérer des fichiers n’est pas restaurer la confiance. La reprise exige état connu, tests, rollback et visibilité sur ce qui reste non testable.