LEn 2026, les ransomwares ne se contentent plus de chiffrer les données de production. Ils ciblent délibérément les sauvegardes en priorité pour les supprimer, les chiffrer, ou les rendre inutilisables avant même de déclencher l'attaque principale. Une sauvegarde accessible depuis le réseau de production est aussi vulnérable que les données qu'elle est censée protéger.
L'immuabilité est la réponse technique à ce problème. Mais le terme recouvre des réalités très différentes selon les solutions,
d'une simple politique de rétention logicielle à une immuabilité physique WORM au niveau du stockage. Cette distinction est déterminante, tant pour
la protection réelle contre les ransomwares que pour la conformité NIS2.
Ce guide explique précisément ce qu'est une sauvegarde immuable, comment elle fonctionne techniquement, et pourquoi le niveau d'immuabilité
retenu conditionne directement l'efficacité de votre stratégie de résilience.
Pour comprendre comment intégrer l'immuabilité dans votre stratégie globale de sauvegarde, consultez notre guide complet sur la sauvegarde externalisée.
Pour les obligations NIS2 spécifiques au backup, consultez notre guide : NIS2 et backup : quelles obligations techniques concrètes ?
Une sauvegarde immuable est une sauvegarde qui ne peut pas être modifiée, chiffrée ou supprimée pendant une période de rétention définie,
quelle que soit l'identité de l'opérateur qui tente de le faire. Une fois écrite, la donnée est figée jusqu'à l'expiration de la période de rétention.
Ce principe s'oppose aux sauvegardes classiques qui restent modifiables après leur création. Sur une sauvegarde classique, un administrateur peut supprimer une copie, modifier sa politique de rétention ou, dans le cas d'un ransomware ayant compromis un compte privilégié, chiffrer l'ensemble
des copies disponibles.
Toutes les solutions qui se présentent comme "immuables" ne le sont pas au même sens technique. Il existe deux niveaux d'immuabilité radicalement différents.
L'immuabilité logicielle est une politique configurée au niveau du logiciel de sauvegarde : une rétention avec une durée minimale, un verrou sur
la suppression. Elle offre une protection contre les erreurs humaines accidentelles. Sa limite : elle peut être désactivée ou contournée par un compte administrateur avec les droits suffisants. Un attaquant ayant compromis un compte admin peut modifier cette politique avant de déclencher
le chiffrement.
L'immuabilité WORM (Write Once Read Many) est implémentée au niveau du stockage physique. Une fois la donnée écrite, aucune opération
de modification ou de suppression n'est possible pendant la période de rétention, quelle que soit l'identité de l'opérateur, y compris un administrateur système ou un compte root. Cette protection est indépendante de la couche logicielle et ne peut pas être contournée par un attaquant qui aurait compromis les couches supérieures du système.
C'est cette dernière que le ReCyF de l'ANSSI attend comme mesure de protection contre les ransomwares ciblant les sauvegardes.
Le mécanisme WORM (Write Once Read Many) est un principe de stockage qui autorise une seule opération d'écriture sur un bloc de données.
Une fois cette écriture effectuée, le bloc devient en lecture seule pour la durée de la période de rétention définie. Aucune opération de modification, d'écrasement ou de suppression n'est possible ni depuis la couche applicative, ni depuis le système d'exploitation, ni depuis un compte administrateur.
Lors de l'écriture d'une sauvegarde immuable, une période de rétention est définie : 30 jours, 90 jours, 1 an selon la politique de l'entité.
Cette période est inscrite au niveau du stockage physique et ne peut pas être raccourcie une fois définie. Elle peut en revanche être prolongée
dans certaines implémentations, c'est le mode WORM dit "Compliance", le plus strict, qui interdit toute modification de la durée dans les deux sens.
C'est le point technique le plus important.
L'immuabilité WORM est implémentée au niveau du firmware du contrôleur de stockage ou du système de fichiers dédié, en dessous de toutes
les couches logicielles. Même si un attaquant compromet le système d'exploitation, le logiciel de sauvegarde, ou un compte root avec tous les privilèges, il ne peut pas modifier les données protégées par WORM. La protection est physiquement indépendante de la sécurité des couches supérieures.
Deux variantes existent dans les implémentations WORM :
Les ransomwares modernes ont profondément évolué depuis les premières versions qui se contentaient de chiffrer les fichiers accessibles. En 2026, les groupes les plus actifs : Akira, RansomHub, Qilin opèrent en plusieurs phases avant de déclencher le chiffrement final.
Les malwares de dernière génération cartographient silencieusement un système d'information pendant des semaines avant de déclencher le chiffrement, en ciblant en priorité les sauvegardes accessibles depuis le réseau. Durant cette phase, l'attaquant identifie l'ensemble des copies de sauvegarde,
leurs emplacements, leurs politiques de rétention, et les comptes administrateurs qui y ont accès.
L'objectif est de s'assurer qu'au moment du déclenchement, toutes les voies de restauration sont compromises ou supprimées.
Une organisation qui découvre l'attaque au moment du chiffrement a déjà perdu ses sauvegardes si elles étaient accessibles depuis le réseau.
72% des victimes de ransomware avaient des sauvegardes, mais ne pouvaient pas les restaurer. Ce chiffre est la conséquence directe de sauvegardes connectées, non isolées, ou dont la politique de rétention a été modifiée par l'attaquant avant le déclenchement.
80% des victimes qui paient la rançon subissent une nouvelle attaque dans l'année suivante, ce qui confirme que payer ne résout pas le problème structurel. La seule réponse durable est de ne jamais se retrouver dans la situation où la restauration est impossible.
Une sauvegarde protégée par un mécanisme WORM en mode Compliance ne peut pas être chiffrée, supprimée ou modifiée, même par un attaquant ayant compromis l'ensemble des comptes administrateurs du système. La période de rétention est inscrite au niveau du stockage physique,
en dessous de toutes les couches logicielles accessibles depuis le réseau.
Pour un attaquant, une sauvegarde WORM Compliance est une copie qu'il ne peut pas atteindre. C'est la condition pour que la restauration reste possible après une attaque réussie sur le réseau de production.
NIS2 ne mentionne pas explicitement le terme "immuabilité" dans son texte. C'est le ReCyF de l'ANSSI qui traduit les obligations de la directive
en exigences techniques opérationnelles et c'est là que l'immuabilité WORM devient une attente explicite.
L'objectif 14 porte sur la capacité à maintenir ou restaurer les activités critiques après un incident. Il implique des sauvegardes régulières, testées,
et permettant une restauration dans des délais maîtrisés. Pour satisfaire cet objectif, les sauvegardes doivent être disponibles et intègres au moment
de l'incident, ce qui suppose qu'elles n'ont pas pu être compromises par l'attaque qui a déclenché le besoin de restauration.
L'objectif 15 porte sur la gestion de crise et la reprise d'activité. Il inclut la capacité à produire des preuves documentées lors d'un contrôle, ce qui implique que les sauvegardes elles-mêmes soient traçables, non altérables, et produisibles dans leur état original.
Le ReCyF mentionne explicitement le cloisonnement physique des systèmes. Appliqué aux sauvegardes, cela signifie qu'au moins une copie doit être physiquement isolée du réseau de production. L'immuabilité seule ne suffit pas si la sauvegarde reste accessible depuis le réseau.
Un attaquant peut ne pas pouvoir la modifier, mais il peut analyser son contenu, cartographier son architecture, ou tenter d'exploiter des vulnérabilités dans le système de stockage. L'isolation physique complète la protection apportée par l'immuabilité.
Lors d'un contrôle, l'ANSSI ne se contente pas d'une déclaration sur l'immuabilité des sauvegardes. Ce qui est attendu : une documentation technique décrivant le mécanisme implémenté au niveau du stockage, avec la période de rétention verrouillée applicable, et la preuve que cette protection
est indépendante des couches logicielles accessibles depuis le réseau.
Un extrait de configuration du système de stockage ou un rapport d'audit technique produit par le prestataire constitue la pièce justificative attendue.
Une confirmation commerciale du fournisseur ne suffit pas.
Pour approfondir les exigences NIS2 sur le backup, consultez notre guide : NIS2 et backup : quelles obligations techniques concrètes ?
C'est la distinction la plus importante à comprendre avant de choisir une solution de sauvegarde et celle que les arguments commerciaux
des fournisseurs tendent à brouiller. Les deux approches ne protègent pas contre les mêmes menaces.
Une politique de rétention logicielle protège efficacement contre les erreurs humaines accidentelles : une suppression involontaire, une modification
non intentionnelle, un utilisateur qui écrase une sauvegarde par erreur. Elle est simple à déployer, souvent incluse dans les licences logicielles existantes, et suffisante pour les environnements à faible criticité.
Sa limite structurelle : elle est implémentée dans la couche logicielle du système. Un compte administrateur avec les droits suffisants peut modifier
la politique, raccourcir la période de rétention, ou désactiver la protection. Dans un scénario de ransomware avec compromission d'un compte privilégié, qui est précisément le scénario le plus fréquent en 2026, cette protection ne résiste pas.
L'immuabilité WORM est implémentée au niveau du firmware du contrôleur de stockage ou du système de fichiers dédié, en dessous de toutes les couches logicielles accessibles depuis le réseau. Elle ne peut pas être désactivée par un compte administrateur, un compte root, ou un attaquant
ayant compromis l'ensemble des couches supérieures du système.
En mode Compliance, la période de rétention est verrouillée dans les deux sens, elle ne peut être ni raccourcie ni contournée jusqu'à son expiration naturelle. Pour un attaquant, une sauvegarde WORM Compliance est une donnée inaccessible, qu'il ne peut ni chiffrer ni supprimer.
Lors de l'évaluation d'une solution de sauvegarde, posez une question simple à votre prestataire : à quel niveau du système l'immuabilité est-elle implémentée, et un compte administrateur peut-il modifier la période de rétention ? Un prestataire incapable de répondre précisément à cette question avec une documentation technique propose très probablement une rétention logicielle.
L'immuabilité des sauvegardes est passée en quelques années d'une bonne pratique optionnelle à un prérequis technique pour toute organisation qui veut être capable de restaurer ses systèmes après une attaque ransomware. La distinction entre rétention logicielle et immuabilité WORM est la ligne de partage entre une sauvegarde qui résiste à un attaquant ayant compromis des comptes privilégiés et une sauvegarde qui ne résiste pas.
Pour les entités dans le périmètre NIS2, c'est aussi la ligne de partage entre une conformité aux objectifs ReCyF et un écart de conformité constaté lors d'un contrôle ANSSI.
VYTALX déploie des solutions de sauvegarde avec immuabilité WORM Compliance au niveau du stockage, sur des appliances on-premise préconfigurées avec option air-gap, accompagnées des rapports techniques nécessaires à votre dossier de conformité NIS2.
