Quand un rançongiciel chiffre plusieurs centaines de serveurs en une nuit, la question qui décide de la survie de l’entreprise n’est pas de savoir combien réclame l’attaquant. C’est de savoir s’il existe encore une copie des données que personne, pas même un administrateur muni de tous ses droits, n’a pu détruire. Cette copie porte un nom précis : une sauvegarde immuable. Elle est devenue, en quelques années, la mesure la plus discriminante de la résilience face aux rançongiciels.
Les rapports d’activité de Cybermalveillance.gouv.fr [1] et l’ENISA Threat Landscape [2] convergent sur un même constat : le rançongiciel reste la première menace pesant sur les organisations françaises et européennes, et les groupes les plus matures ont adapté leur mode opératoire. Avant de chiffrer la production, ils cherchent à neutraliser les sauvegardes. Une politique de sauvegarde conçue pour le risque de panne matérielle, mais pas pour le risque d’un adversaire actif à l’intérieur du système d’information, ne protège plus. Cet article, à jour au juillet 2026, explique pourquoi les sauvegardes sont ciblées, ce que recouvre exactement l’immuabilité, quelles technologies la mettent en oeuvre, et comment construire une architecture de sauvegarde qui tient en situation de crise.
Pourquoi les sauvegardes sont la première cible
La réponse directe est économique. Une entreprise capable de restaurer rapidement ses données n’a aucune raison de payer une rançon. Détruire les sauvegardes est donc, pour l’attaquant, le moyen le plus sûr d’augmenter la probabilité de paiement. C’est pourquoi la destruction des copies de secours précède presque toujours le déclenchement du chiffrement de production.
Le guide de l’ANSSI consacré aux attaques par rançongiciels [3] et le StopRansomware Guide publié par la CISA [4] décrivent le même enchaînement. Après une compromission initiale par hameçonnage, exposition d’un service distant ou vulnérabilité non corrigée, l’attaquant progresse latéralement, élève ses privilèges, puis prend le contrôle de l’annuaire et des consoles d’administration. Une fois administrateur du domaine, il repère les serveurs de sauvegarde, supprime les catalogues, chiffre les dépôts accessibles et désactive les tâches planifiées. Le chiffrement final n’intervient qu’après cette phase de sabotage.
La conséquence pratique est brutale : une sauvegarde accessible en écriture depuis un compte du domaine compromis n’est pas une sauvegarde, c’est une cible supplémentaire. Un dépôt réseau monté en permanence, un partage accessible avec les mêmes identifiants que la production, une console de sauvegarde intégrée à l’annuaire Active Directory (voir /cybersecurite/securite-active-directory-durcissement-entreprise/) : tous ces montages, commodes au quotidien, tombent en même temps que le reste. La résilience des sauvegardes est devenue le facteur qui sépare une entreprise qui restaure en quelques jours d’une entreprise à l’arrêt pendant des semaines.
Ce que veut dire immuable
Une sauvegarde immuable est une copie que rien ne peut modifier ni supprimer pendant une durée fixée à l’avance. Le point essentiel tient dans une nuance technique : le verrou est appliqué par le support de stockage lui-même, et non par une simple permission logicielle. Une permission peut être révoquée par qui détient les droits d’administration. Un verrou d’immuabilité, lui, refuse toute suppression jusqu’à l’expiration du délai, quels que soient les identifiants présentés.
Le concept n’est pas nouveau. Il descend en droite ligne du principe WORM, pour Write Once Read Many : on écrit une fois, on lit autant de fois que nécessaire, on ne réécrit jamais. Les archives réglementaires du secteur financier utilisent le WORM depuis longtemps. Ce qui a changé, c’est la généralisation de cette propriété aux sauvegardes courantes, portée par le stockage objet et par les fonctions d’immuabilité intégrées aux logiciels de sauvegarde.
Deux modes d’immuabilité coexistent, et la distinction est loin d’être théorique. En mode gouvernance, un utilisateur disposant d’un privilège particulier peut lever le verrou avant terme. En mode conformité, personne ne le peut, pas même le compte racine du fournisseur, jusqu’à l’expiration. Face à un rançongiciel qui vise précisément à obtenir les privilèges les plus élevés, seul le mode conformité offre une garantie réelle. Le mode gouvernance protège contre l’erreur humaine et la suppression accidentelle, pas contre un adversaire déterminé qui a pris le contrôle des comptes.
Le NIST détaille cette logique dans sa publication SP 1800-11, consacrée précisément à la récupération après un rançongiciel et aux atteintes à l’intégrité des données [5]. La ligne directrice est constante : la capacité de restauration doit résister à un attaquant qui a déjà des droits élevés dans l’environnement.
La règle 3-2-1 et son évolution 3-2-1-1-0
La règle 3-2-1 reste le socle de toute politique de sauvegarde, et l’ANSSI la rappelle dans son guide d’hygiène informatique [7]. Elle impose de conserver au moins trois copies des données, sur deux types de supports différents, dont une copie hors site. Cette discipline couvre les risques classiques : panne d’un disque, incendie d’une salle, erreur de manipulation.
Le rançongiciel a révélé sa limite. Une copie hors site connectée en permanence au réseau reste joignable par un attaquant qui contrôle le domaine. La distance géographique ne protège pas si la copie est accessible en ligne avec des identifiants compromis. C’est pourquoi la doctrine a évolué vers une formulation étendue, la règle 3-2-1-1-0, relayée par les recommandations de la CISA [4] et de Cybermalveillance [8].
Les deux ajouts sont décisifs. Le premier 1 supplémentaire désigne une copie hors ligne ou immuable, c’est-à-dire hors d’atteinte d’un chiffrement en ligne. Le 0 final désigne l’exigence de zéro erreur au test de restauration : une sauvegarde n’est validée que si sa restauration a été vérifiée et ne produit aucune erreur. Autrement dit, la règle ne s’arrête plus à la production de copies, elle intègre la preuve qu’elles sont exploitables. C’est ce dernier chiffre, souvent négligé, qui distingue une politique déclarative d’une politique éprouvée.
Les technologies qui rendent une sauvegarde immuable
Plusieurs voies techniques mènent à l’immuabilité, et la plupart des architectures sérieuses en combinent au moins deux. La réponse directe pour un RSSI qui doit choisir : privilégier une immuabilité imposée par le stockage, en mode conformité, sur au moins une copie.
L’object lock sur stockage objet. Le stockage objet, sur site ou dans le cloud, propose une fonction de verrouillage d’objet qui empêche toute suppression ou réécriture pendant une durée définie. En mode conformité, ce verrou résiste même aux comptes les plus privilégiés. C’est aujourd’hui la voie la plus répandue pour une copie de sauvegarde résiliente et automatisable, notamment vers une copie externalisée (voir /cloud/backup-cloud-3-2-1-entreprise/).
Les volumes et appliances WORM. Certaines baies de stockage et appliances de sauvegarde intègrent des volumes WORM qui appliquent nativement l’immuabilité au niveau du système de fichiers. Le NIST, dans sa publication SP 800-209 sur la sécurité des infrastructures de stockage [6], recense ces mécanismes et insiste sur la séparation des rôles d’administration du stockage.
Les snapshots verrouillés. Les snapshots immuables figent l’état d’un volume à un instant donné et interdisent leur suppression avant expiration. Rapides à créer et à restaurer, ils conviennent bien aux objectifs de reprise courts, à condition d’être stockés sur un système distinct de la production.
La bande physiquement déconnectée. La bande magnétique conserve un atout que rien ne remplace : une cartouche sortie du lecteur et rangée dans un coffre est physiquement inaccessible depuis le réseau. C’est l’air gap dans sa forme la plus littérale. Son coût par téraoctet reste bas et sa longévité élevée, au prix d’une restauration plus lente. Pour l’archivage long et la dernière ligne de défense, elle garde toute sa pertinence.
Aucune de ces technologies n’est une solution complète à elle seule. L’object lock protège une copie en ligne mais dépend de la bonne configuration du mode conformité. Les snapshots sont rapides mais restent proches de la production. La bande est robuste mais lente. La conception consiste à les articuler selon la criticité et les objectifs de reprise.
Air gap physique et air gap logique
La notion d’air gap, ou coupure d’air, désigne l’isolement d’une copie par rapport au reste du système d’information. Deux formes coexistent et répondent à des contraintes différentes.
L’air gap physique correspond à une déconnexion réelle : le support n’est ni branché au réseau ni sous tension entre deux opérations. Une cartouche de bande en coffre en est l’exemple type. La garantie est maximale, car un attaquant en ligne ne peut atteindre ce qui n’est pas connecté. Le prix à payer est opérationnel : rotation manuelle, délai de remise en ligne, restauration plus lente.
L’air gap logique conserve une connexion réseau mais dresse des barrières logicielles et de configuration : réseau d’administration dédié, identités totalement distinctes de la production, immuabilité imposée par le stockage, fenêtre d’accès réduite dans le temps. Il est plus commode à automatiser et à superviser. Sa robustesse dépend entièrement de la rigueur de la séparation : si les mêmes comptes administrent la production et la sauvegarde, l’air gap logique n’existe que sur le papier.
La bonne pratique, pour les données les plus critiques, combine les deux : une copie immuable en ligne pour la restauration rapide, et une copie physiquement déconnectée comme ultime recours. La CISA [9] comme l’ANSSI [3] recommandent explicitement de conserver au moins une copie hors ligne pour les systèmes vitaux.
Concevoir une architecture de sauvegarde résiliente
Construire une sauvegarde à l’épreuve d’un rançongiciel suppose de traiter l’infrastructure de sauvegarde comme un actif sensible à part entière, au même titre que l’annuaire. Voici les principes structurants.
Isoler la console de sauvegarde du domaine bureautique. Le serveur qui pilote les sauvegardes ne doit pas être membre du même annuaire que les postes de travail, ni administrable avec les mêmes comptes. S’il tombe avec le domaine, la protection s’effondre en même temps que la production. Une authentification distincte, une administration en tiers et une double authentification sur les accès sont indispensables.
Séparer strictement les identités. Les identifiants d’accès aux dépôts de sauvegarde ne doivent jamais coïncider avec ceux de la production. Un compte compromis en production ne doit ouvrir aucune porte vers les sauvegardes. Cette séparation des identités rejoint la logique de gestion des accès à privilèges (voir /cybersecurite/edr-mdr-xdr-comparatif-rssi/ pour la détection associée).
Imposer l’immuabilité en mode conformité sur au moins une copie. Au moins une copie de chaque jeu de données critiques doit être verrouillée en mode conformité, pour une durée au moins égale au temps nécessaire à détecter une compromission. Beaucoup d’attaques restent silencieuses plusieurs semaines : un verrou de sept jours ne protège pas si l’intrusion date de trois semaines. Une durée d’immuabilité de plusieurs semaines à quelques mois est un point de départ raisonnable pour les données vitales.
Surveiller et alerter sur les sauvegardes. Les tentatives de suppression, les échecs de tâches, les variations anormales de volume et les extinctions de services de sauvegarde doivent générer des alertes. Une chute soudaine du volume protégé est souvent le premier signal visible d’un sabotage en cours.
Chiffrer les copies au repos et en transit. L’immuabilité protège la disponibilité, pas la confidentialité. Face à la double extorsion, où l’attaquant exfiltre les données avant de les chiffrer, les sauvegardes doivent elles-mêmes être chiffrées pour ne pas devenir une source de fuite (voir /cybersecurite/ransomware-2026-vecteurs-attaque/).
Tester la restauration : le chiffre qui compte
Le 0 de la règle 3-2-1-1-0 est le plus souvent négligé, alors qu’il est le seul à apporter une preuve. Une sauvegarde immuable jamais restaurée ne démontre rien : elle atteste qu’une copie existe, pas qu’elle est exploitable.
Le test de restauration doit vérifier trois choses. D’abord l’intégrité : les données restaurées sont-elles complètes et cohérentes ? Ensuite le délai réel de restauration, à comparer avec l’objectif de temps de reprise défini dans le plan de continuité (voir /cybersecurite/gestion-crise-cyber-pca-pra-entreprise/). Enfin l’ordre de reconstruction : dans quelle séquence relancer annuaire, bases de données et applications pour que le système redevienne fonctionnel ?
Deux indicateurs structurent cette démarche. Le RPO, objectif de point de reprise, mesure la quantité maximale de données que l’entreprise accepte de perdre, exprimée en temps entre deux sauvegardes. Le RTO, objectif de temps de reprise, mesure la durée maximale d’indisponibilité acceptable. Une politique de sauvegarde n’a de valeur que confrontée à ces deux objectifs par un test chronométré. Le NIST SP 1800-11 [5] insiste sur ce point : la capacité de récupération se démontre par l’exercice, pas par la configuration.
En pratique, un test de restauration partiel mensuel sur un échantillon tournant, complété d’un exercice complet d’un périmètre critique une à deux fois par an, constitue un rythme soutenable. L’objectif n’est pas de cocher une case, mais de découvrir les difficultés en exercice plutôt qu’en crise.
Les erreurs fréquentes
Quelques défauts reviennent systématiquement dans les organisations touchées.
La première erreur est de confondre externalisation et immuabilité. Copier ses données dans le cloud ne les protège pas si elles y sont stockées avec de simples droits d’écriture : un compte compromis les efface aussi bien à distance que sur site. Seule l’activation explicite de l’immuabilité protège.
La deuxième est de laisser la console de sauvegarde dans le domaine bureautique. C’est la faille la plus exploitée : l’attaquant qui prend le domaine prend les sauvegardes dans le même mouvement.
La troisième est de choisir le mode gouvernance en croyant se protéger. Ce mode, révocable par un privilège, tombe face à un attaquant qui vise précisément les privilèges. Pour la défense anti-rançongiciel, seul le mode conformité tient.
La quatrième est de ne jamais tester la restauration, ou de la tester uniquement sur un fichier isolé sans mesurer le délai global de reprise d’un système complet.
La cinquième est de fixer une durée d’immuabilité trop courte au regard du temps de détection réel d’une intrusion. Si l’attaquant est présent depuis un mois et que le verrou ne dure qu’une semaine, les copies saines ont déjà expiré au moment du déclenchement.
Combiner les niveaux selon la criticité
Toutes les données ne méritent pas le même effort, et vouloir tout traiter au niveau maximal conduit souvent à une politique coûteuse et mal tenue. La réponse pratique consiste à hiérarchiser par criticité, puis à combiner les niveaux d’immuabilité en conséquence.
Pour les systèmes vitaux, ceux dont l’arrêt met en jeu la survie de l’activité, la cible est claire : une copie immuable en mode conformité pour la restauration rapide, une copie physiquement déconnectée comme ultime recours, une durée d’immuabilité couvrant largement le temps de détection, et un exercice de restauration complet au moins une à deux fois par an. Ce sont typiquement l’annuaire, les bases de données métier, la messagerie et les applications de production.
Pour les données importantes mais non vitales, une copie immuable en ligne et un test de restauration périodique partiel suffisent généralement. Pour les données de faible criticité, une sauvegarde classique respectant la règle 3-2-1 reste acceptable, à condition qu’elle ne serve pas de point d’entrée vers les copies protégées.
Cette hiérarchisation présente un double avantage. Elle concentre l’investissement là où l’impact est le plus fort, et elle rend la politique réellement applicable dans la durée. Une politique uniforme trop ambitieuse finit souvent contournée par les équipes d’exploitation, ce qui crée précisément les copies accessibles que l’attaquant recherche. Mieux vaut un périmètre critique parfaitement protégé et testé qu’une couverture large mais théorique.
Un cadre désormais réglementaire
La résilience des données n’est plus seulement une bonne pratique, elle devient une obligation. La directive NIS2 impose aux entités essentielles et importantes des mesures de gestion des risques incluant la continuité d’activité et la sauvegarde (voir /cybersecurite/nis2-entreprise-guide-2026/). Le règlement DORA impose au secteur financier des exigences de résilience opérationnelle et de test, dont la capacité de restauration fait partie (voir /cybersecurite/dora-reglement-cybersecurite/). Dans les deux cas, l’organe de direction est responsable, et l’existence de sauvegardes réellement restaurables devient un point de contrôle.
La sauvegarde immuable se situe ainsi à l’intersection de trois logiques : technique, car elle neutralise le vecteur privilégié des rançongiciels ; opérationnelle, car elle conditionne la vitesse de reprise ; et réglementaire, car elle matérialise l’obligation de résilience. Pour un RSSI, elle n’est pas une option d’infrastructure parmi d’autres. Elle est la dernière ligne qui sépare un incident maîtrisé d’un arrêt d’exploitation prolongé.
La logique à retenir tient en une phrase : concevez vos sauvegardes en supposant que l’attaquant sera un jour administrateur de votre domaine. Ce postulat conduit mécaniquement à l’immuabilité en mode conformité, à la séparation stricte des identités, à une copie hors ligne pour les données vitales, et à un test de restauration qui prouve, chiffres à l’appui, que la reprise est possible.