# Sauvegardes cyber : prouver la restauration avant le rançongiciel Adrien Murillo — Murillo Consulting Guide pour transformer les sauvegardes en preuve de reprise : périmètre critique, tests de restauration, dépendances, RTO/RPO et journal de validation. 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 ? Version : Mai 2026 ## À 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é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. ## À 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 - [CISA - #StopRansomware Guide](https://www.cisa.gov/news-events/news/cisa-fbi-nsa-ms-isac-publish-updated-stopransomware-guide) - [Microsoft Incident Response - ransomware approach](https://learn.microsoft.com/en-us/security/ransomware/incident-response-playbook-dart-ransomware-approach) - [NIST - SP 800-61 Rev. 3](https://csrc.nist.gov/pubs/sp/800/61/r3/final) ## Navigation - [Consultant DevOps et DevSecOps Cloud.](/profil) - [Missions d’ingénierie.](/services) - [Réalisations.](/realisations) - [Projets open source.](/projets) - [Des guides pour passer à l’action.](/ressources) - [Parlons de votre projet.](/contact) - [Du cadrage aux livrables.](/approche) - [Des contextes. Des contraintes réelles.](/secteurs) - [Apprendre en prenant des décisions.](/lab) - [Mentions légales](/mentions-legales) - [Confidentialité](/confidentialite) - [Conditions générales d’utilisation](/conditions-utilisation) - [Former vos équipes. Avec de la pratique.](/formation) [Contact](mailto:contact@adrien-murillo.com)