Le backup immuable, votre dernière ligne de défense

Quand le ransomware chiffre aussi les sauvegardes, c’est la capacité même de se relever qui s’effondre. L’immuabilité n’est pas une fonctionnalité technique. C’est la matérialisation, dans le stockage, du principe de résilience.

Introduction

Il y a une statistique qui devrait clore tous les débats : selon le rapport Veeam Ransomware Trends 2024, 96 % des attaques par ransomware ciblent désormais les dépôts de sauvegarde. Ce n’est plus un effet de bord, c’est la stratégie. Détruire le filet de sécurité avant de chiffrer la production. Mettre la victime dos au mur. Transformer le paiement de la rançon en option « rationnelle ».

Dans l’épisode 001, j’écrivais cette phrase : une sauvegarde non testée n’est pas une sauvegarde. Elle reste vraie. Mais le terrain a évolué. Les attaquants ne se contentent plus d’attendre que la sauvegarde échoue toute seule. Ils vont la chercher. Ils s’introduisent, attendent en moyenne plusieurs mois, repèrent les serveurs de backup, escaladent leurs privilèges, puis suppriment ou chiffrent les copies avant de déclencher l’attaque sur la production.

Il faut donc compléter la phrase de 2026 : une sauvegarde accessible à l’attaquant n’est pas une sauvegarde non plus. Elle est juste une cible supplémentaire.

C’est ici qu’entre en scène l’immutabilité. Un mot un peu froid, un concept simple : un jeu de sauvegarde qui, une fois écrit, ne peut être ni modifié, ni supprimé pendant une période définie. Ni par un administrateur. Ni par un compromis de credentials. Ni par un ransomware. Cette propriété change la nature même du dialogue avec l’attaquant.

La vraie question n’est pas : « avons-nous des sauvegardes ? » C’est : « pouvons-nous prouver qu’au moins une copie restera intouchable, quoi qu’il arrive cette nuit ? »

1. Pourquoi les sauvegardes sont devenues la cible n°1

Le calcul des cybercriminels est devenu cynique et efficace. Tant qu’une organisation peut restaurer ses systèmes sans payer, le rapport de force lui reste favorable. Si les sauvegardes tombent aussi, l’arbitrage bascule : reconstruire de zéro coûte des semaines, parfois des mois, et expose à une perte sèche de données. La rançon, à ce moment-là, peut sembler la moins mauvaise option.

L’ANSSI le formule sans ambiguïté dans son guide « Attaques par rançongiciels, tous concernés » : les cybercriminels cherchent désormais activement à compromettre les sauvegardes pour limiter la marge de manœuvre de la victime et maximiser les chances qu’elle paie. Ce n’est pas une hypothèse. C’est un mode opératoire documenté.

Les techniques observées sont multiples : suppression des snapshots, chiffrement du serveur de sauvegarde lui-même, exploitation de credentials administrateurs partagés entre production et backup, attaque des consoles de gestion exposées sur le réseau interne. Le résultat est toujours le même : au moment où l’on en a besoin, la sauvegarde n’est plus là.

Tant que la sauvegarde partage le même périmètre de confiance que la production, elle partage aussi son destin.

2. Du 3-2-1 au 3-2-1-1-0 : ce qui a changé

La règle 3-2-1 - trois copies, sur deux supports, dont une hors site - reste une fondation valable. Mais elle a été pensée pour résister aux pannes matérielles et aux sinistres physiques, pas à un adversaire intelligent qui cherche activement vos copies.

Le modèle 3-2-1-1-0 ajoute deux exigences que l’époque impose :

• 1 copie immuable ou hors-ligne - non modifiable et non supprimable, même par un administrateur compromis.

• 0 erreur de restauration - testée régulièrement, avec un résultat documenté, pas une supposition.

Cette évolution n’est pas cosmétique. Elle déplace le centre de gravité : on ne mesure plus la qualité du backup à sa fréquence ou à son volume, mais à sa résistance à un attaquant qui dispose des droits d’administration et de plusieurs mois pour préparer son coup.

Le backup ne se mesure plus à ce qu’il sauvegarde, mais à ce qu’il garantit de pouvoir restaurer après compromission.

3. Immutabilité, air-gap, vault : trois concepts, une seule logique

Trois termes circulent, souvent confondus. Ils répondent en réalité à trois questions différentes.

Immutabilité (WORM, Write Once Read Many) :

Une fois la donnée écrite, elle est verrouillée pour une durée définie. Le mécanisme s’appuie sur des contrôles au niveau du stockage lui-même (object lock S3, snapshots verrouillés, repositories Linux durcis, bandes WORM). La protection tient même si tous les comptes administrateurs sont compromis. Elle empêche la modification ; elle n’isole pas.

Air-gap :

L’isolation. Physique (bandes éjectées, disques déconnectés) ou logique (réseaux séparés, comptes dédiés, fenêtres d’accès restreintes). L’air-gap empêche l’attaquant d’atteindre la donnée ; il ne garantit pas son intégrité une fois qu’il y est.

Vault isolé :

L’architecture qui combine les deux. Un coffre où la donnée est immuable ET isolée, généralement avec ses propres comptes, sa propre infrastructure de gestion, ses propres mécanismes d’authentification. C’est ce que les guides du NCCoE (NIST SP 1800-11) et de la CISA décrivent comme la cible de référence.

L’immutabilité protège l’intégrité. L’air-gap protège l’accès. Le vault combine les deux. Une seule de ces trois propriétés ne suffit pas.

4. Grille de maturité : où en êtes-vous, vraiment ?

La meilleure façon de sortir des discussions abstraites est de se positionner sur une échelle. Cinq niveaux suffisent à clarifier le débat, du plus exposé au plus mature.

Aucun jugement dans cette grille. Beaucoup d’organisations sont au niveau 1, certaines au niveau 0. L’enjeu n’est pas d’être au sommet demain matin. C’est de savoir lucidement où l’on est, et de se fixer un cap réaliste à six ou douze mois.

Connaître son niveau, c’est déjà refuser l’illusion. Le pire scénario est de se croire au niveau 3 quand on est au niveau 1.

5. Les pièges classiques de l’immuabilité

Acheter une solution étiquetée « immuable » ne suffit pas. Plusieurs écueils transforment une architecture vendue comme inviolable en passoire.

• Mauvaise configuration : la propriété d’immutabilité existe mais n’est pas activée, ou la durée de rétention est trop courte pour couvrir le délai moyen de détection (souvent plusieurs mois).

• Comptes partagés : le compte admin du backup est aussi un compte privilégié de la production. Une compromission propage la chaîne entière.

• Console de gestion exposée : l’interface du serveur de sauvegarde est joignable depuis le réseau bureautique, voire depuis Internet. L’attaquant n’a même pas besoin de la donnée : la console suffit pour saboter les politiques.

• Absence de MFA : l’authentification multi-facteurs sur les outils de sauvegarde reste l’exception, alors qu’elle devrait être la règle non négociable.

• Non-test de la restauration depuis le coffre immuable : on suppose que ça marchera. On ne le vérifie jamais.

L’immutabilité mal gouvernée donne un faux sentiment de sécurité - la pire des situations, parce qu’elle dissuade d’investir ailleurs.

6. Restaurer dans une « clean room » : l’angle mort de la résilience

Récupérer une sauvegarde n’est qu’une moitié du chemin. L’autre moitié, c’est s’assurer qu’on ne réintroduit pas l’attaquant en remettant la donnée en production. Selon Veeam, 63 % des organisations risquent de réinjecter une infection lors d’une restauration post-ransomware. C’est l’angle mort.

La pratique mature s’appelle l’environnement de restauration isolé (Isolated Recovery Environment, IRE) - parfois nommé « clean room ». Un espace réseau séparé où la donnée restaurée est vérifiée, scannée, validée avant d’être réintroduite dans le système d’information principal. Le NIST décrit cette logique dans sa publication SP 1800-11 sur la récupération après ransomware : la restauration n’est pas un acte technique unique, c’est un processus en plusieurs étapes avec contrôles d’intégrité.

Pour beaucoup d’organisations, c’est la marche suivante. Pas la plus médiatisée, mais probablement la plus déterminante pour passer d’une posture « on a des sauvegardes » à une posture « on sait se relever ».

Restaurer sans clean room, c’est rallumer la lumière sans avoir vérifié si l’incendie était éteint.

7. Du technique au gouvernemental : qui décide ?

La tentation est forte de laisser ces choix aux équipes infrastructure. Ce serait reproduire l’erreur dénoncée dans l’épisode 004 : confondre un sujet de gouvernance avec un sujet d’outillage. La capacité à restaurer engage l’entreprise tout entière. Elle conditionne le délai pendant lequel l’organisation peut survivre sans système d’information. Elle pèse sur la décision de payer ou non une rançon. Elle détermine la trajectoire de réputation après une crise.

Cette décision relève donc du COMEX, pas seulement de la DSI. Quelques questions structurantes à se poser, ensemble :

• Quel est le délai maximal acceptable de retour aux opérations critiques (RTO) ? Notre architecture de backup le permet-elle, ou est-ce un vœu pieux ?

• Quel volume de données pouvons-nous nous permettre de perdre (RPO) ? Cette tolérance est-elle alignée avec les obligations contractuelles et réglementaires (NIS2, DORA) ?

• Avons-nous une preuve récente - pas une déclaration - que la restauration intégrale d’un périmètre métier critique fonctionne ?

• Avons-nous identifié les comptes, consoles et chemins d’accès qui, s’ils étaient compromis, donneraient à un attaquant la maîtrise de nos sauvegardes ?

Tant que ces questions n’ont pas de réponse partagée entre la DSI, le RSSI et le COMEX, le sujet n’est pas gouverné.

L’Essentiel pour Agir

1. Cartographier le périmètre de confiance de vos sauvegardes : identifiez les comptes, consoles et chemins réseau qui peuvent atteindre, modifier ou supprimer un jeu de sauvegarde. Si un attaquant compromet un de ces points, votre dispositif tombe. C’est l’audit minimal - il peut être conduit en quelques jours et révèle souvent des dépendances invisibles.

2. Garantir au moins une copie immuable et isolée des données critiques : WORM logique sur stockage objet, repository Linux durci ou bande hors-ligne. La copie doit être hors d’atteinte des comptes administrateurs de production. C’est le minimum pour faire passer le ransomware d’« incident catastrophique » à « incident gérable ».

3. Tester une restauration intégrale au moins une fois par an, dans un environnement isolé : un test partiel sur un fichier ne prouve rien. Un exercice annuel, périmètre métier réel, scénario crédible, mesure du RTO et du RPO atteints. Le résultat - réussite ou échec - doit être communiqué au COMEX. C’est ce qui transforme une supposition en garantie.

Conclusion

Le backup immuable n’est pas une fonctionnalité de plus dans un cahier des charges. C’est la traduction technique d’un principe simple : se donner les moyens de reconstruire, quoi qu’il arrive. Sans cette garantie, tout le reste - détection, EDR, formation, plan de réponse - repose sur l’espoir que rien d’irréversible ne se produira.

C’est la dernière ligne de défense. Pas la seule, pas la principale, mais celle qui décide, quand toutes les autres ont cédé, si l’organisation se relève ou pas.

Reste une question, qu’aucune architecture ne résout à elle seule : si la donnée est sauvegardée et restaurable, qu’en est-il du reste ? Des systèmes d’authentification, des annuaires, des secrets, des certificats ? Une organisation qui restaure sa donnée mais qui a perdu ses identités ne se relève pas vraiment. Elle redémarre - c’est différent. Ce sera le sujet de la prochaine étape.

Bibliographie

ANSSI & Direction des Affaires criminelles et des grâces - Attaques par rançongiciels, tous concernés : comment les anticiper et réagir en cas d’incident ?

https://cyber.gouv.fr/publications/attaques-par-rancongiciels-tous-concernes

Guide de référence en français sur la prévention et la gestion d’une crise ransomware, avec une section explicite sur la nécessité de protéger les sauvegardes contre la compromission par les attaquants.

CISA - #StopRansomware Guide (Cybersecurity and Infrastructure Security Agency)

https://www.cisa.gov/stopransomware/ransomware-guide

Guide officiel américain co-publié par CISA, FBI, NSA et MS-ISAC. Recommande explicitement le maintien de sauvegardes hors-ligne, chiffrées et immuables des données critiques, et détaille les bonnes pratiques de protection des dépôts de backup.

NIST - SP 1800-11 : Data Integrity - Recovering from Ransomware and Other Destructive Events

https://csrc.nist.gov/pubs/sp/1800/11/final

Guide pratique du National Cybersecurity Center of Excellence (NCCoE) du NIST sur l’architecture et les procédures permettant de restaurer des données après une attaque destructive, en garantissant l’intégrité de ce qui est restauré.

ENISA - Threat Landscape 2024

https://www.enisa.europa.eu/publications/enisa-threat-landscape-2024

Rapport annuel de l’Agence européenne de la cybersécurité. Ransomware figure à la deuxième place des menaces majeures en 2024, avec une analyse détaillée de l’évolution des modes opératoires (Ransomware-as-a-Service, ciblage des sauvegardes, double extorsion).

Veeam - 2024 Ransomware Trends Report

https://www.veeam.com/blog/announcing-rw24.html

Étude annuelle menée auprès de 1 200 organisations victimes de ransomware. Source de la statistique des 96 % d’attaques visant les dépôts de sauvegarde et du chiffre des 63 % d’organisations risquant de réintroduire l’infection lors de la restauration.

ANSSI / CERT-FR - État de la menace rançongiciel à l’encontre des entreprises et institutions

https://www.cert.ssi.gouv.fr/uploads/CERTFR-2021-CTI-001.pdf

Note du CERT-FR documentant les modes opératoires des principaux groupes de rançongiciel observés en France, dont la pratique du « Big Game Hunting » et du ciblage actif des infrastructures de sauvegarde des victimes.