Pourquoi le ransomware fait de la sauvegarde une cible, et non plus un filet de sécurité
Pendant des années, la sauvegarde a été l'exception qui rendait le ransomware supportable : chiffrer la production, restaurer depuis la sauvegarde, et repartir de l'avant. Les attaquants ont rattrapé leur retard. Dans l'enquête Ransomware Trends 2025 de Veeam, menée auprès de 1 300 organisations ayant subi une attaque, 89 % ont vu leurs référentiels de sauvegarde ciblés dans le cadre de l'attaque — non pas comme un à-côté, mais comme un objectif à part entière de la kill chain. Détruire ou corrompre le filet de secours avant de chiffrer la production est désormais une pratique standard, car cela prive la victime de tout levier de négociation avant même que la demande de rançon n'arrive.
Ce constat se reflète dans les chiffres de reprise. Le rapport Sophos State of Ransomware 2025 montre que seules 54 % des organisations ont utilisé leurs sauvegardes pour restaurer leurs données après une attaque — le taux le plus bas depuis les six années d'existence de l'étude. Parmi les organisations ayant fini par payer plus que la demande initiale de l'attaquant, 38 % ont invoqué des sauvegardes défaillantes ou inutilisables comme raison de n'avoir eu aucune meilleure option. Une sauvegarde qui existe sur le papier n'a rien à voir avec une sauvegarde qui se restaure proprement sous pression.
Cet écart — entre « nous avons des sauvegardes » et « nous avons des sauvegardes résilientes face au ransomware » — se résume à trois piliers : l'immuabilité, l'isolation et la reprise testée. Ce ne sont pas des contrôles indépendants que l'on peut combiner à sa guise. Si l'un des trois fait défaut, les deux autres ne compensent pas : une sauvegarde immuable qu'un attaquant ne peut atteindre n'a de valeur que si elle se restaure réellement, et un plan de restauration parfaitement 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 qu'un attaquant ne peut pas toucher
L'immuabilité signifie qu'une sauvegarde ne peut être ni modifiée ni supprimée pendant sa période de rétention — ni par un script de rétention mal configuré, ni par un compte administrateur compromis, ni par l'attaquant qui a déjà obtenu des identifiants d'administrateur de domaine. En pratique, elle s'applique via l'Object Lock sur du stockage cloud ou objet, du matériel WORM (Write Once Read Many), ou un référentiel Linux durci dont les verrous de rétention sont appliqués au niveau de la couche de stockage, indépendamment des contrôles d'accès propres à l'application de sauvegarde.
Cette distinction compte, car les opérateurs de ransomware modernes recherchent activement les référentiels de sauvegarde accessibles avec des identifiants de production, et les suppriment ou les chiffrent en premier, avant même de toucher aux données primaires. Si le même compte administrateur qui gère votre solution de sauvegarde peut aussi supprimer les points de restauration du mois dernier, l'immuabilité n'est pas réellement en place — ce n'est qu'un paramètre qu'un attaquant suffisamment privilégié peut désactiver en quelques minutes.
Les recommandations de la CISA sur le ransomware sont explicites sur ce point : maintenir des sauvegardes hors ligne, chiffrées et immuables, les vérifier régulièrement, et les considérer comme la dernière ligne de défense plutôt que comme le premier obstacle que l'attaquant doit franchir.
2. L'isolation : un plan d'identité distinct, et une copie totalement hors de portée des attaquants
L'immuabilité protège une sauvegarde contre toute modification. L'isolation, elle, empêche l'attaquant d'y accéder tout court. 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 faille lors d'un incident réel 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 faire confiance ni au même domaine Active Directory, ni aux mêmes identifiants administrateur, ni au même segment réseau à plat que la production. Un contrôleur de domaine compromis ne doit pas automatiquement entraîner un environnement de sauvegarde compromis ; si c'est le cas, l'attaquant n'a eu besoin de compromettre qu'un seul élément, pas deux. Le second volet est une copie réellement hors ligne ou en air gap — au minimum, une copie des données critiques qui ne dispose d'aucun chemin réseau permanent depuis la production, que ce soit via une rotation de bandes hors ligne, une cible de réplication déconnectée qui n'est brièvement en ligne que pour recevoir les données, ou un niveau de stockage cloud sans identifiants persistants mis en cache et accessibles depuis le périmètre de production.
Les recherches de Veeam montrent que les organisations qui donnent la priorité à ce type de résilience isolée et en couches se rétablissent d'une attaque de ransomware jusqu'à sept fois plus vite que celles qui ne le font pas, avec une perte de données nettement plus faible au passage. C'est l'isolation qui rend cet écart possible : c'est la différence entre un attaquant qui doit fournir un effort supplémentaire réel pour atteindre votre point de restauration, 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 reprise testée : prouver la restaurabilité avant d'en avoir besoin
Le moins prestigieux des trois piliers est aussi celui que les organisations négligent le plus souvent — et cela se voit dans les résultats. Dans une enquête sectorielle menée en 2025, 62 % des organisations ont déclaré ne pas effectuer régulièrement d'exercices de test de sauvegarde et de restauration, et 37 % ont indiqué ne pas être en mesure de se rétablir dans leur objectif de temps de reprise (RTO) requis, précisément parce que les sauvegardes étaient manquantes ou n'avaient tout simplement jamais été validées. La confiance et la réalité divergent nettement sur ce point : plus de 60 % des organisations pensent pouvoir se rétablir d'une interruption en quelques heures, mais seul un tiers environ y parvient réellement une fois testé.
Les restaurations non testées échouent de manières qui restent invisibles 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. Négliger la validation comporte aussi un risque plus grave qu'une simple interruption de service — on estime que 63 % des organisations risquent de réintroduire une infection pendant la restauration, faute d'analyse d'intégrité et antimalware effectuée sous la pression du temps, restaurant ainsi la charge malveillante même qui avait causé l'incident initial.
Un véritable programme de reprise testée implique des exercices complets de restauration planifiés vers un environnement de reprise isolé — et non de simples notifications « job de sauvegarde réussi » — validés au regard des RTO réellement nécessaires à l'activité, et non de chiffres qui se contentent de rassurer dans une présentation.
À quoi ressemble la situation quand les trois piliers tiennent
Les données 2025 de Sophos offrent un contre-exemple utile face aux statistiques les plus alarmantes : parmi les organisations dont les données avaient effectivement été chiffrées par un attaquant, 97 % ont tout de même réussi à les récupérer. L'écart entre ce groupe et la faible minorité qui n'y est pas parvenue s'explique presque toujours par le fait que l'un des trois piliers était, en pratique, plus faible qu'il n'y paraissait sur le papier — un verrou de rétention qu'un rôle mal attribué pouvait contourner, un réseau de sauvegarde soi-disant « séparé » qui faisait pourtant confiance au même domaine, ou une restauration qui n'avait en réalité jamais été répétée de bout en bout.
Le coût de l'échec
Les trois piliers ne relèvent pas d'une checklist abstraite de bonnes pratiques — ils déterminent directement le coût et la durée d'un incident de ransomware. Le coût moyen pour se remettre d'une attaque de ransomware, hors rançon éventuellement payée, avoisine 1,53 million de dollars. Seules 53 % des victimes ont été entièrement rétablies en moins d'une semaine ; les autres sont restées plus de sept jours dans un état de perturbation, avec des interruptions de service, une perte de productivité et des coûts de réponse à incident qui s'accumulaient chaque jour.
Les erreurs courantes qui sapent discrètement les trois piliers
Quelques schémas reviennent systématiquement dans les analyses post-incident :
- Confondre snapshots et sauvegardes. Un snapshot VMware est un delta à un instant T, stocké sur le même datastore que la VM qu'il protège — ce n'est pas une copie indépendante. Il croît sans limite, dégrade les performances, et disparaît dès que le datastore disparaît lui-même. Les snapshots sont une fonctionnalité de confort pour un retour en arrière de courte durée, pas une stratégie de reprise.
- Traiter « immuable » comme une simple case à cocher plutôt qu'une propriété vérifiée. L'Object Lock et les politiques de rétention doivent être testés face au rôle administratif 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 relevant du même domaine d'identité. Si les identifiants compromis en production permettent aussi de s'authentifier auprès du référentiel de sauvegarde, une séparation géographique ou technologique ne constitue pas une isolation réelle.
- Mesurer le succès à l'achèvement de la sauvegarde, et non à la vérification de la restauration. Un voyant vert sur le job de la veille indique simplement que des données ont été écrites quelque part. Il ne garantit ni qu'elles sont récupérables, ni qu'elles sont cohérentes du point de vue applicatif, ni qu'elles sont exemptes du malware ayant rendu la restauration nécessaire.
Où intervient BackupSec
Chez BackupSec, nous aidons les équipes des grandes entreprises à piloter leurs environnements de sauvegarde en s'appuyant précisément sur ces trois piliers — non pas en remplaçant leur plateforme de sauvegarde, mais en rendant la sécurité des sauvegardes observable, pilotable et démontrable.
Notre approche combine trois couches :
- ZeroMON offre une observabilité continue sur l'ensemble du parc de sauvegarde — un monitoring compatible Veeam avec suivi des jobs en temps réel, des contrôles de sécurité automatisés, des pistes d'audit forensiques pour détecter la dérive de configuration, et des rapports de conformité en un clic. C'est cette couche qui transforme « l'immuabilité est configurée » d'une hypothèse en preuve.
- ZeroTAM apporte un conseil d'expert dédié sur l'architecture de sauvegarde, la conception de l'isolation et la planification de la reprise après ransomware — la couche humaine dont la plupart des entreprises ont besoin pour interpréter ce que leur environnement de sauvegarde leur dit réellement, et pour concevoir une isolation qui résiste à l'épreuve d'un incident réel.
- ZeroPEN teste votre infrastructure de sauvegarde par intrusion, comme le ferait un véritable adversaire — en ciblant les plans de gestion, les contrôles d'accès et les paramètres d'immuabilité — puis exécute de véritables scénarios de restauration pour valider que vous pouvez récupérer vos données proprement, intégralement et dans le RTO annoncé, et pas seulement qu'un job de sauvegarde a été signalé comme réussi.
BackupSec se déploie on-premise, se connecte à vos applications de sauvegarde via un accès API en lecture seule, et ne déplace jamais vos données de sauvegarde hors de votre environnement.
Échangez avec BackupSec sur la posture de sécurité de vos sauvegardes →
Prêt à savoir si vos propres sauvegardes tiendraient le choc ? Évaluez votre environnement avec le Backup Security Assessment gratuit.