Teste la restauration et prépare la résistance au rançongiciel

01Définis le résultat attendu

Un test de restauration ne se limite pas à extraire des fichiers.

Sauvegarde sélectionnée
→ environnement de restauration propre
→ intégrité vérifiée
→ données et configuration restaurées
→ application démarrée
→ dépendances reconnectées
→ validation technique
→ validation métier
→ mesure du temps et de l'âge des données

02Utilise un environnement propre

Dans un contexte de rançongiciel :

- ne restaure pas immédiatement dans l'environnement compromis
- vérifie l'image, les comptes et les outils utilisés
- isole le réseau de reprise selon la procédure
- réintroduis seulement des systèmes considérés propres
- conserve les éléments nécessaires à l'investigation

Le test pédagogique ne simule aucune infection. Il vérifie seulement que le critère clean_environment est présent.

03Vérifie l’intégrité avant la disponibilité

Checksum valide
≠ service utilisable

Service démarré
≠ données métier cohérentes

Page web accessible
≠ commandes et factures correctes

La preuve doit couvrir plusieurs niveaux.

04Mesure ce qui s’est réellement passé

RTO observé
→ temps entre le début du test et le service validé

Point de données restauré
→ âge réel des données récupérées

Écart
→ différence entre objectif et résultat

Un test réussi techniquement peut échouer sur l’objectif métier.

05Observe les cinq tests

lab=/tmp/soria-cyber-vulnerability-resilience-$USER
bash module3-cyber-vulnerability-resilience.sh setup "$lab"
bash module3-cyber-vulnerability-resilience.sh run "$lab"
column -s, -t "$lab/output/restore-results.csv"

Résultats :

REST-101 → PASS_RESTORE_OBJECTIVES
REST-102 → BLOCK_BUSINESS_VALIDATION
REST-103 → FAIL_RTO
REST-104 → FAIL_RPO
REST-105 → PASS_RESTORE_OBJECTIVES

06Analyse chaque échec

REST-102
→ le système démarre
→ aucune validation métier
→ restauration non acceptée

REST-103
→ données correctes
→ reprise en 16 h pour un objectif de 12 h
→ capacité insuffisante ou procédure trop lente

REST-104
→ reprise en temps voulu
→ données âgées de 10 h pour un RPO de 4 h
→ fréquence ou succès de sauvegarde insuffisant

07Teste plusieurs niveaux

Test de fichier
→ rapide, couverture limitée

Test applicatif
→ cohérence du service

Test de serveur ou VM
→ système complet

Exercice de reprise
→ personnes, dépendances, communications et priorités

La fréquence et la profondeur dépendent de la criticité.

08Conserve une preuve exploitable

Date et périmètre
Sauvegarde utilisée
Environnement de test
Étapes exécutées
Résultats et erreurs
RTO et RPO observés
Validation technique et métier
Écarts
Actions correctives
Prochain test

Un test sans action corrective répétée ne réduit pas durablement le risque.

09Prépare la reprise sûre

- définir les images de référence
- protéger les comptes d'administration de reprise
- disposer des installateurs et licences
- versionner l'infrastructure as code
- conserver les procédures hors du système principal
- vérifier les dépendances avant reconnexion