Pourquoi le ransomware fait des sauvegardes une cible, et non plus un filet de sécurité
Pendant des années, la sauvegarde a été l'exception qui rendait un ransomware surmontable : la production est chiffrée, on restaure depuis la sauvegarde, on passe à autre chose. Les attaquants ont rattrapé leur retard. Le 2025 Ransomware Trends report de Veeam a interrogé 1 300 organisations, dont 900 avaient subi au moins une attaque de ransomware au cours des 12 mois précédents. Veeam indique que 89 % des organisations ont vu leurs référentiels de sauvegarde ciblés par l'attaquant, et qu'en moyenne 34 % des référentiels de sauvegarde ont été modifiés ou supprimés. Détruire ou corrompre la solution de repli retire à la victime son levier avant même que la note de rançon n'arrive.
Le résultat se lit dans les chiffres de récupération. Le State of Ransomware 2025 de Sophos a interrogé 3 400 responsables IT et sécurité dont l'organisation avait été touchée par un ransomware au cours de l'année précédente. Parmi les organisations dont les données avaient été chiffrées, seules 54 % les ont restaurées à l'aide de sauvegardes, le taux le plus bas en six ans d'enquête Sophos. Sur les 151 organisations qui ont fini par payer davantage que la demande initiale de l'attaquant, 38 % ont déclaré que leurs sauvegardes avaient échoué ou présentaient des dysfonctionnements (les répondants citaient généralement deux raisons). Une sauvegarde qui existe sur le papier n'est pas la même chose qu'une sauvegarde qui se restaure proprement sous pression.
Cet écart, entre « nous avons des sauvegardes » et « nous avons des sauvegardes résilientes face aux ransomwares », se résume à trois piliers : l'immuabilité, l'isolation et la récupération testée. Ce ne sont pas des contrôles indépendants que l'on peut combiner à la carte. Si l'un d'eux manque, les deux autres ne compensent pas. Une sauvegarde immuable hors de portée de l'attaquant n'est utile que si elle se restaure réellement, et un plan de restauration bien testé ne vaut rien si la sauvegarde dont il dépend a été supprimée avant même le début de l'exercice.
Les trois piliers en détail
1. L'immuabilité : des sauvegardes auxquelles un attaquant ne peut pas toucher
L'immuabilité signifie qu'une sauvegarde ne peut être ni modifiée ni supprimée pendant sa fenêtre de rétention : ni par un script de rétention mal configuré, ni par un compte administrateur compromis, ni par un attaquant qui détient déjà des identifiants d'administrateur de domaine. En pratique, elle est appliquée via Object Lock sur du stockage objet, via du matériel WORM (Write Once Read Many) ou via un référentiel Linux renforcé (hardened repository) dont la rétention est appliquée au niveau du stockage, indépendamment des contrôles d'accès propres à l'application de sauvegarde.
La distinction compte, car les opérateurs de ransomware partent à la recherche de sauvegardes qu'ils peuvent atteindre avec des identifiants volés. Le #StopRansomware Guide de la CISA le dit sans détour : "Ransomware actors often hunt for and collect credentials stored in the targeted environment and use those credentials to attempt to access backup solutions." (les acteurs du ransomware traquent et collectent souvent les identifiants stockés dans l'environnement ciblé, puis s'en servent pour tenter d'accéder aux solutions de sauvegarde). Si le même compte d'administration qui gère votre logiciel de sauvegarde peut aussi supprimer les points de restauration du mois dernier, l'immuabilité n'est pas réellement en place. C'est un paramètre qu'un attaquant disposant de privilèges suffisants peut désactiver en quelques minutes.
Le conseil de la CISA en matière de sauvegarde est de "maintain offline, encrypted backups of critical data, and regularly test the availability and integrity of backups in a disaster recovery scenario." (conserver des sauvegardes hors ligne et chiffrées des données critiques, et tester régulièrement leur disponibilité et leur intégrité dans un scénario de reprise après sinistre). Le même guide se montre prudent à l'égard du stockage cloud immuable utilisé seul : "Use immutable storage with caution as it does not meet compliance criteria for certain regulations and misconfiguration can impose significant cost." (utilisez le stockage immuable avec prudence, car il ne satisfait pas aux critères de conformité de certaines réglementations et une mauvaise configuration peut entraîner des coûts importants). L'immuabilité est un contrôle puissant. Elle ne remplace ni une copie hors ligne, ni une restauration testée.
2. L'isolation : un plan d'identité distinct, et une copie totalement hors d'atteinte des attaquants
L'immuabilité empêche qu'une sauvegarde soit modifiée. L'isolation empêche qu'elle soit atteinte en premier lieu. Les deux sont complémentaires, pas interchangeables, et les entreprises qui n'en mettent en œuvre qu'une seule découvrent généralement la lacune pendant un véritable incident plutôt que lors d'une revue de conception.
L'isolation comporte deux volets. Le premier est un plan d'identité distinct : l'infrastructure de sauvegarde ne doit pas faire confiance au même domaine Active Directory, aux mêmes identifiants d'administration ni au même segment réseau à plat que la production. Un contrôleur de domaine compromis ne devrait pas signifier automatiquement un environnement de sauvegarde compromis ; si c'est le cas, l'attaquant n'avait besoin de compromettre qu'une seule chose, et non deux. Le second est une copie réellement hors ligne ou en air gap : au moins une copie des données critiques qui ne dispose d'aucun chemin réseau permanent depuis la production. Il peut s'agir d'une rotation de bandes hors ligne, d'une cible de réplication déconnectée qui n'est en ligne que brièvement pour recevoir les données, ou d'un niveau cloud sans aucun identifiant persistant mis en cache à un endroit accessible depuis le parc de production.
Le rapport 2025 de Veeam indique que les organisations qui donnent la priorité à la résilience des données "can recover from attacks up to seven times faster and experience significantly lower data loss rates." (peuvent se remettre des attaques jusqu'à sept fois plus vite et subissent des taux de perte de données nettement plus faibles). Veeam attribue ce résultat à la résilience des données dans son ensemble (sauvegarde et récupération, sécurité proactive, réponse aux incidents), et non à l'isolation seule. L'isolation reste une part importante du tableau : c'est la différence entre un attaquant qui doit fournir un réel travail supplémentaire pour atteindre votre point de récupération, et un attaquant qui y a déjà une session ouverte parce qu'il partage un plan d'identité avec les systèmes qu'il vient de compromettre.
3. La récupération testée : prouver la capacité de restauration avant d'en avoir besoin
Le moins prestigieux des trois piliers est aussi le plus facile à laisser à moitié fait. Dans le rapport 2025 de Veeam, 98 % des répondants disposaient d'un playbook ransomware, mais seuls 44 % y avaient inclus les vérifications de sauvegarde et leur fréquence. Le 2024 Ransomware Trends report de Veeam, fondé sur 1 200 organisations touchées par au moins une attaque en 2023, a établi que 63 % des organisations risquaient de réintroduire l'infection pendant la récupération, parce que les équipes pressées de restaurer rapidement sautent des étapes comme la nouvelle analyse des données en quarantaine.
Les restaurations non testées échouent de manière invisible jusqu'au moment où elles comptent le plus : chaînes de sauvegarde rompues, dépendances de cohérence applicative manquantes, identifiants de comptes de service expirés depuis des mois, ou runbooks rédigés pour une topologie d'infrastructure qui n'existe plus. Faire l'impasse sur l'analyse d'intégrité et l'analyse antimalware comporte un risque plus grave que l'indisponibilité : restaurer le payload même qui a provoqué la panne.
Un véritable programme de récupération testée implique des exercices de restauration complète planifiés dans un environnement de récupération isolé, et pas seulement des notifications « tâche de sauvegarde réussie ». Mesurez ces exercices au regard des RTO dont l'activité a réellement besoin, et non de chiffres qui semblent simplement rassurants dans une présentation.
Ce que disent réellement les chiffres de récupération
Les données 2025 de Sophos affichent un chiffre qui semble rassurant : 97 % des organisations dont les données avaient été chiffrées ont pu les récupérer. Le détail est moins réconfortant. Un peu plus de la moitié (54 %) ont restauré à partir de sauvegardes, 49 % ont payé la rançon et récupéré leurs données, et 29 % ont utilisé d'autres moyens ; beaucoup ont emprunté plus d'une voie. Récupérer ses données et les récupérer depuis ses propres sauvegardes sont deux issues différentes. C'est dans l'écart entre les deux que les piliers fragiles se révèlent : un verrou de rétention que le mauvais rôle pouvait outrepasser, un réseau de sauvegarde « séparé » qui faisait encore confiance au même domaine, ou une restauration qui n'avait jamais été répétée de bout en bout.
Le coût de l'erreur
Les trois piliers ne sont pas une checklist abstraite de bonnes pratiques. Ils déterminent directement le coût d'un incident de ransomware et sa durée. Le rapport 2025 de Sophos situe le coût moyen de récupération après une attaque de ransomware, hors rançon éventuellement payée, à 1,53 million de dollars, contre 2,73 millions de dollars en 2024. 53 % des victimes s'étaient entièrement rétablies en moins d'une semaine, contre 35 % un an plus tôt. Les autres ont passé plus de sept jours dans une forme de perturbation, l'indisponibilité, la perte de productivité et le travail de réponse aux incidents s'accumulant jour après jour.
La posture de sauvegarde est l'une des rares variables de cette équation qu'une organisation maîtrise entièrement. La réussite ou l'échec de la première offensive d'un attaquant contre votre référentiel de sauvegarde se décide en grande partie par des choix faits des mois plus tôt, et non pendant l'incident lui-même. Au moment où un acteur malveillant détient des identifiants d'administrateur de domaine et sonde votre plateforme de sauvegarde, l'immuabilité, l'isolation et la récupération testée sont soit déjà en place, soit absentes ; il n'est plus possible de les ajouter sous pression.
Les erreurs courantes qui minent discrètement les trois piliers
Quelques schémas reviennent régulièrement dans les analyses post-incident :
- Confondre snapshots et sauvegardes. Un snapshot VMware est un journal des modifications du disque virtuel d'origine, pas une copie indépendante. L'article de Broadcom sur les bonnes pratiques relatives aux snapshots est catégorique : "Do not use VMware snapshots as backups." (n'utilisez pas les snapshots VMware comme sauvegardes). Le fichier de snapshot grossit à mesure qu'on le conserve, ce qui peut saturer le datastore et dégrader les performances, et si les disques de base sont perdus, "the snapshot files alone are not sufficient to restore a virtual machine." (les fichiers de snapshot seuls ne suffisent pas à restaurer une machine virtuelle). Les snapshots sont une fonctionnalité de confort pour des retours arrière de courte durée (Broadcom conseille de ne pas conserver un même snapshot plus de 72 heures), pas une stratégie de récupération.
- Traiter « immuable » comme une case à cocher plutôt que comme une propriété vérifiée. Object Lock et les politiques de rétention doivent être testés face au rôle d'administration exact qui gère la plateforme de sauvegarde, et pas seulement documentés dans un guide de configuration.
- Qualifier d'« isolée » une deuxième copie située dans le même domaine d'identité. Si les mêmes identifiants compromis en production peuvent s'authentifier sur le référentiel de sauvegarde, la séparation géographique ou de plateforme n'apporte pas de véritable isolation.
- Mesurer le succès à l'achèvement des sauvegardes plutôt qu'à la vérification des restaurations. Une coche verte sur la tâche de la nuit dernière vous indique que des données ont été écrites quelque part. Elle ne vous dit pas que ces données sont récupérables, cohérentes au niveau applicatif et exemptes du malware qui a rendu la restauration nécessaire.
Où intervient BackupSec
BackupSec ne remplace pas votre plateforme de sauvegarde. Trois de nos services correspondent aux piliers ci-dessus :
- ZeroMON surveille Veeam Backup & Replication. Il fonctionne sur site sous forme d'OVA, se connecte avec un compte en lecture seule et n'envoie rien à BackupSec ni à aucun tiers. Il suit l'état des tâches, enregistre les modifications de configuration dans son module Forensic & Audit (qui a changé quoi, et quand), exécute une checklist Security Analyzer, produit des rapports et envoie des alertes par e-mail et par notification dans l'application. Il affiche l'état d'immuabilité de chaque référentiel tel que le rapportent les paramètres des référentiels de Veeam lui-même, et signale tout changement de ce paramètre. Il lit la configuration de Veeam ; il ne vérifie pas les verrous au niveau des objets sur le stockage lui-même.
- ZeroTAM est un conseiller dédié à la sécurité des sauvegardes, et non un logiciel : conception de l'architecture et de l'isolation, planification de la capacité, planification de la récupération après ransomware, et support prioritaire en cas de crise.
- ZeroPEN est un test d'intrusion guidé par la menace, portant sur Veeam Backup & Replication, Veeam ONE et Enterprise Manager. Il simule une kill chain de ransomware alignée sur MITRE ATT&CK en huit étapes : accès initial, découverte et inventaire, abus d'identifiants, compromission du serveur Veeam, accès aux référentiels, neutralisation des sauvegardes, simulation d'exfiltration et preuve de capacité de chiffrement. Il ne supprime jamais de vraies sauvegardes, n'effectue aucun chiffrement réel et n'arrête ni les services de production ni les services de sauvegarde. Vous obtenez des preuves prêtes pour l'audit, et les constats critiques font l'objet d'un nouveau test. La mission inclut également une vérification de l'intégrité des restaurations et de l'immuabilité. Il s'agit d'un test ponctuel : les exercices de restauration réguliers du pilier 3 doivent donc toujours être menés.
Parlez à BackupSec de votre posture de sécurité des sauvegardes →
Vous voulez savoir comment vos propres sauvegardes résisteraient ? Le Backup Security Assessment gratuit pose 28 questions réparties sur sept domaines, de la stratégie de sauvegarde et du contrôle d'accès jusqu'aux tests de récupération.