Une sauvegarde qui existe mais qu’on ne peut pas restaurer dans un délai acceptable après un incident ne sert à rien. Le vrai sujet en 2026, pour les équipes qui gèrent des sauvegardes face aux ransomwares, n’est plus la copie des données : c’est la capacité à ramener en production une copie saine, depuis une infrastructure qui n’a pas été compromise en même temps que le reste du système d’information.
Restauration après compromission de l’infrastructure de sauvegarde
Les attaquants ne se contentent plus de chiffrer les fichiers de production. Les retours d’incidents convergent : les consoles d’administration des solutions de sauvegarde, les comptes de service associés et les droits d’accès aux dépôts de copies sont désormais des cibles prioritaires.
Quand un ransomware compromet l’Active Directory ou le fournisseur d’identité principal, les credentials utilisés pour accéder au stockage de sauvegarde tombent avec. Le résultat : des copies techniquement intactes, mais inaccessibles parce que l’identité nécessaire pour les lire a été révoquée, chiffrée ou corrompue.
Nous observons que la majorité des plans de reprise testés en conditions réelles échouent sur ce point précis. La copie existe. Le problème est ailleurs : restaurer suppose une identité et une infrastructure de pilotage indépendantes du domaine compromis.
Séparation des domaines de confiance
La réponse technique passe par l’isolation administrative. Le système de sauvegarde doit fonctionner dans un domaine de confiance distinct : annuaire séparé, comptes dédiés sans lien avec le domaine de production, MFA propre.
Cette séparation ne concerne pas seulement le réseau. Elle porte sur trois couches :
- L’identité : les comptes qui administrent la sauvegarde ne doivent pas dépendre du même fournisseur d’authentification que la production.
- Le plan de contrôle : la console de gestion des sauvegardes doit rester opérationnelle même si le SI principal est totalement arrêté.
- Le stockage : les copies doivent résider sur un support que les credentials de production ne peuvent ni supprimer ni modifier, même avec des privilèges élevés.
Sauvegarde immuable et stockage hors ligne contre les ransomwares
Le stockage immuable empêche toute modification ou suppression d’une copie pendant une durée définie, y compris par un administrateur. C’est la seule garantie technique qu’un attaquant disposant de droits élevés ne puisse pas détruire les sauvegardes.
L’ANSSI a publié en mars 2026 le référentiel ReCyF, qui traduit les attentes NIS2 en recommandations opérationnelles. Ce référentiel insiste sur l’isolement des sauvegardes et le recours au stockage hors ligne quand la criticité le justifie. L’immutabilité n’est plus une option dans les environnements régulés : c’est une exigence de conformité.
Immutabilité logique et immutabilité physique
Toutes les immutabilités ne se valent pas. Une immutabilité logicielle appliquée par la solution de sauvegarde elle-même peut être contournée si l’attaquant compromet cette solution. L’immutabilité portée par le stockage sous-jacent (object lock S3, WORM matériel) offre une résistance nettement supérieure.
Le stockage hors ligne (bandes, copies air-gapped) reste le dernier rempart. Un support physiquement déconnecté ne peut pas être atteint par un ransomware, quel que soit son niveau de privilège sur le réseau. Le coût opérationnel est plus élevé, mais pour les données les plus critiques, aucune alternative n’offre cette garantie.
Tests de restauration : le maillon faible de la protection des données
Disposer de copies immuables et isolées ne suffit pas si personne n’a vérifié qu’elles permettent un redémarrage effectif. Un test de restauration complet inclut la reconstruction de l’environnement cible, pas seulement la vérification de l’intégrité des fichiers.
Nous recommandons de simuler un scénario où le domaine principal est indisponible. Le test doit répondre à une question simple : l’équipe peut-elle, sans accès au SI compromis, remonter un service critique à partir de la copie isolée, dans un délai compatible avec les engagements métier ?
Ce que le test doit couvrir
Un test partiel donne une fausse confiance. Les points suivants sont rarement vérifiés, et ce sont précisément ceux qui bloquent en situation réelle :
- L’accès aux copies sans les credentials du domaine de production (test d’indépendance administrative).
- La durée réelle de restauration d’un volume significatif de données, pas seulement d’un échantillon.
- La cohérence applicative après restauration : bases de données, certificats, configurations réseau.
- La disponibilité des procédures documentées, accessibles hors du SI principal (pas dans un wiki hébergé en interne).
Conformité NIS2 et référentiel ReCyF : ce qui change pour la sauvegarde
Le référentiel ReCyF publié par l’ANSSI structure les obligations liées à la récupération des données dans le cadre de NIS2. Les entreprises concernées doivent démontrer que leurs sauvegardes sont protégées contre les rançongiciels, isolées et testées régulièrement.
Ce n’est plus une recommandation de bonne pratique. L’isolement des sauvegardes est devenu un enjeu de conformité réglementaire pour les entités régulées. Le référentiel pousse explicitement vers la séparation des identités, le chiffrement des copies et la vérification périodique de la capacité de restauration.
Pour les organisations qui n’ont pas encore segmenté leur infrastructure de sauvegarde, le chantier prioritaire consiste à cartographier les dépendances entre le système de sauvegarde et le domaine de production. Chaque dépendance identifiée est un point de défaillance potentiel en cas d’attaque ciblant simultanément la production et la récupération.
La copie des données reste une brique nécessaire. Elle n’a jamais été suffisante. Ce qui détermine la résilience réelle d’une organisation face aux attaques informatiques, c’est la capacité à restaurer rapidement, depuis un environnement sain, des fichiers dont l’intégrité a été vérifiée, avec des procédures testées et des identités indépendantes du périmètre compromis.
