Sauvegarde immuable et offline

Définition

Une sauvegarde immuable (immutable backup ou WORM — Write Once, Read Many) est une copie de données dont les caractéristiques techniques garantissent qu'elle ne peut être ni modifiée, ni supprimée, ni réécrite pendant une période définie — y compris par un administrateur disposant des droits étendus. C'est le mécanisme central de défense contre les rançongiciels (ransomware) qui, en ciblant les sauvegardes elles-mêmes, neutralisent les capacités de reprise classiques.

Plusieurs technologies réalisent cette immuabilité :

1. Object Lock S3 (standard introduit par AWS, repris par MinIO, Cloudian, Scality, OVHcloud Object Storage, Outscale OOS) — mode Compliance (immuabilité forte, opposable à l'admin root) ou Governance (immuabilité contrôlée par un sous-ensemble de droits IAM). Norme de fait dans l'écosystème S3.
2. WORM filesystem — systèmes de fichiers spécialisés (NetApp SnapLock, Dell PowerScale SmartLock) qui appliquent une rétention au niveau du volume ou du répertoire.
3. Bandes magnétiques LTO offline — LTO-8, LTO-9, LTO-10. Une fois écrites et physiquement extraites du robot, les bandes sont déconnectées de tout réseau, donc inatteignables par un attaquant — c'est l'air-gap physique au sens strict (cf. /criteres/air-gap-end-to-end/). LTO supporte la fonction WORM nativement.
4. Snapshots ZFS / Btrfs — copy-on-write avec verrouillage des snapshots historiques. Robuste contre l'écrasement applicatif, mais reste accessible à un attaquant ayant compromis l'hôte hyperviseur.
5. Object storage avec versioning + retention policy — protection logique, dépend de la rigueur d'IAM.

Le principe partagé : séparer le droit d'écrire du droit de modifier, et garantir que la suppression n'est possible qu'après expiration explicite de la rétention.

Pourquoi c'est important pour un hébergeur HDS

La sauvegarde immuable est aujourd'hui un standard professionnel pour tout hébergeur HDS, pour quatre raisons documentées :

1. Le rançongiciel cible les sauvegardes en premier. Les attaquants modernes (Conti, LockBit, BlackCat, Akira, RansomHub) consacrent les premières heures de l'intrusion à identifier et neutraliser les sauvegardes — chiffrement, suppression, exfiltration. Une sauvegarde immuable rend cette phase inefficace.
2. L'exigence est dans le référentiel HDS. L'activité 6 du référentiel HDS (cf. les 6 activités HDS de l'ANS, version 2.0) couvre la sauvegarde externalisée. Pour les hébergeurs ayant cette activité dans leur scope, la capacité de sauvegarde immuable est attendue par les auditeurs.
3. Le secteur santé a été massivement ciblé. Les attaques contre les CHU français (Rouen 2019, Dax 2021, Corbeil-Essonnes 2022, Versailles 2022, et de nombreux établissements 2023-2025) ont systématiquement révélé la vulnérabilité des architectures de sauvegarde traditionnelles.
4. Le coût est devenu marginal. Il y a 10 ans, le WORM était une fonctionnalité haut de gamme. Aujourd'hui, l'Object Lock est gratuit chez la plupart des fournisseurs S3, et les bandes LTO restent l'archivage le plus économique au To. L'absence de capacité immuable est devenue un signal de dette technique.

L'architecture 3-2-1-1-0 (3 copies, 2 supports différents, 1 copie offsite, 1 copie immuable, 0 erreur de vérification) est désormais la référence pour les architectures de sauvegarde santé.

Comment ce critère est attribué dans le comparateur

• ✓ Vérifié — l'acteur documente publiquement une offre de sauvegarde immuable avec précision technique : Object Lock S3 (mode Compliance/Governance), WORM filesystem, LTO offline, ou snapshots verrouillés.
• ◆ Revendiqué — mention « sauvegarde immuable », « anti-ransomware » ou « WORM » sans détail technique.
• — Non documenté — pas de mention publique de capacité immuable.

À noter : la cohérence scope HDS → capacité immuable est appliquée — un acteur qui revendique une sauvegarde immuable doit soit avoir l'activité 6 dans son scope HDS, soit déclarer publiquement le sous-traitant HDS scope 6 qui assure ce service pour lui.

Pour quel profil c'est critique

Comment un hébergeur peut se conformer

Quatre voies techniques :

1. Stockage objet avec Object Lock — déploiement d'une plateforme S3 compatible (MinIO, Cloudian, NetApp StorageGRID, Scality RING, Dell ECS, ou plateforme propriétaire) avec activation du mode Object Lock Compliance pour les buckets de sauvegarde. Coût marginal sur infrastructure existante.
2. Bibliothèque LTO offline — déploiement d'une bibliothèque LTO-9 ou LTO-10, robotisée, avec procédure d'écriture incrémentale et d'extraction physique des cartouches vers un coffre. Architecture la plus robuste à long terme.
3. Externalisation vers fournisseur HDS scope 6 — sous-traitance contractualisée à un acteur HDS certifié sur l'activité 6 du référentiel ANS. Exige une clarté contractuelle sur la responsabilité de la chaîne.
4. Snapshot + verrouillage — déploiement de snapshots ZFS, Btrfs, ou plateforme de sauvegarde commerciale (Veeam Hardened Repository, Rubrik, Cohesity) avec verrouillage des points de restauration.

Le choix dépend du profil de menace (rançongiciel sophistiqué vs erreur opérateur), de la volumétrie (penabytes vs téraoctets), et de la fréquence d'écriture (continue vs périodique).

Plus-value vs coût

Le coût d'une capacité de sauvegarde immuable est aujourd'hui négligeable au regard du coût d'un incident ransomware non récupérable : le coût moyen d'une attaque ransomware sur un hôpital français en 2024 est estimé entre 5 et 50 M€ (arrêt d'activité + remédiation + reconstruction + amendes éventuelles), à comparer à un investissement de 50 k€ à 500 k€ pour une architecture immuable mature.

C'est probablement l'un des critères où le ratio plus-value / coût est le plus favorable dans l'ensemble du comparateur.

Sources officielles

• ANS — Référentiel HDS, activité 6 (Sauvegarde externalisée) : esante.gouv.fr/offres-services/hds.
• ANSSI — Guide d'hygiène informatique, sections sauvegarde et rançongiciel : cyber.gouv.fr/publications/guide-dhygiene-informatique.
• ANSSI — Notes de réponse aux campagnes ransomware (CERT-FR) : cert.ssi.gouv.fr.
• NIST — SP 800-209 (Security Guidelines for Storage Infrastructure) : nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-209.pdf.
• IETF — RFC 4810 (Long-Term Archive Service Requirements), RFC 4998 (Evidence Record Syntax) : ietf.org.
• LTO Consortium — Spécifications LTO-8, LTO-9, LTO-10 : lto.org.

Limites connues

Le critère valorise la communication publique de la capacité immuable. Plusieurs acteurs HDS disposent d'une architecture de sauvegarde immuable robuste qu'ils ne mettent pas en avant publiquement : la mention reste dans les annexes techniques accessibles aux clients. Le statut « Non documenté » est une absence de mention publique, pas une absence de capacité.

Pour un projet HDS critique, demander explicitement à l'hébergeur retenu : type d'immuabilité (Object Lock mode Compliance vs Governance), périmètre de protection (toutes les données ou un sous-ensemble), durée de rétention par défaut et maximale, procédure de restauration et tests régulièrement effectués, et capacité à fournir des rapports d'auditabilité après incident.