Rançongiciel / Reprise · 8 min
Sauvegardes cyber : prouver la restauration avant le rançongiciel
Une sauvegarde annoncée n'est pas une capacité de reprise. Après un rançongiciel, la vraie question est plus dure : quelles données peut-on restaurer, dans quel ordre, avec quels accès, quelles dépendances et quel niveau de confiance métier ?
Par Adrien Murillo · Publié le · Version : · Sommaire · Télécharger en Markdown ↓
Lecture rapide
À retenir
- La preuve attendue est un test de restauration daté, pas seulement une console de sauvegarde verte.
- Les dépendances identité, DNS, certificats, comptes de service et réseau doivent être testées avec les données.
- Les objectifs RTO/RPO doivent être compréhensibles par le métier et validés par un scénario.
- Une restauration saine doit être protégée contre le retour de l'attaquant.
Choisir un scénario qui parle au métier
Un test utile ne restaure pas tout le SI. Il choisit un service critique, un jeu de données représentatif, les dépendances minimales et un critère de réussite clair. Cette approche donne une preuve exploitable sans immobiliser toute l'organisation.
La bonne question est : si ce service est chiffré demain matin, que devons-nous remettre en route pour facturer, livrer, produire, soigner, payer ou communiquer ?
- service critique
- données
- dépendances
- critère métier
- temps mesuré
Tester les dépendances oubliées
La restauration échoue souvent sur un détail non sauvegardé ou non disponible : annuaire, DNS, certificats, secrets applicatifs, comptes de service, ordonnanceur, stockage, flux réseau ou licence. Le test doit forcer ces dépendances à apparaître.
Quand ces éléments sont visibles avant l'incident, le PRA devient un plan de reprise concret plutôt qu'un document théorique.
Séparer sauvegarde saine et environnement sûr
Restaurer depuis une sauvegarde saine ne garantit pas que l'environnement de destination est sûr. Avant la remise en ligne, il faut vérifier les accès privilégiés, les sessions, les tâches planifiées, les agents de sécurité et les journaux de surveillance.
Cette étape évite de restaurer proprement un système dans un contexte encore compromis.
- accès privilégiés
- sessions
- EDR
- journaux
- surveillance renforcée
Décisions, signaux et preuves
À décider
- Quel service doit reprendre en premier pour préserver l'activité ?
- Quelle perte de données est réellement acceptable pour ce service ?
- Qui décide qu'une restauration est saine et peut être remise en production ?
- Les sauvegardes restent-elles accessibles si l'annuaire principal est compromis ?
- Quel mode dégradé existe si la restauration complète dépasse le délai acceptable ?
À vérifier techniquement
- Sauvegardes accessibles depuis le même domaine ou les mêmes comptes compromis
- Absence de test de restauration récent sur service métier critique
- Dépendances non incluses : DNS, AD, secrets, certificats, ordonnanceurs ou comptes de service
- RTO/RPO déclarés sans scénario de validation
- Impossibilité de distinguer sauvegarde saine, sauvegarde chiffrée et sauvegarde suspecte
Preuves à conserver
- Liste des services critiques et jeux de données à restaurer en priorité
- Compte rendu de test de restauration : date, périmètre, durée, résultat, écarts
- Preuve d'isolement ou d'immutabilité des sauvegardes critiques
- Dépendances nécessaires à la reprise et responsables de validation métier
- Journal des décisions de reprise et critères de remise en ligne
Erreurs fréquentes
- Contrôler uniquement le succès des jobs de sauvegarde.
- Restaurer un serveur sans tester l'application et la validation métier.
- Oublier que l'attaquant peut avoir touché les sauvegardes ou les comptes de sauvegarde.
- Remettre en ligne avant d'avoir réduit les chemins de retour.
Questions fréquentes
À quelle fréquence tester la restauration ?
La fréquence dépend de la criticité, mais un service vital doit être testé assez souvent pour que l'équipe sache encore refaire le geste et que les dépendances restent connues.
Sources publiques
Les références ci-dessous accompagnent la version datée de ce guide. Leur portée et leur version doivent être vérifiées pour votre contexte.