Stockage immuable : vraie immuabilité ou argument marketing

4

Presque tous les produits de stockage et de sauvegarde vendus aujourd’hui revendiquent l’immuabilité. Très peu d’entre eux entendent la même chose par ce terme, et les différences restent quasi invisibles jusqu’au jour où elles comptent. Ce jour-là, ce sont les seules qui comptent.

L’immuabilité n’est pas une fonctionnalité que l’on peut vérifier en lisant une fiche technique, car le mot décrit un résultat plutôt qu’un mécanisme. Deux produits peuvent tous deux être immuables et différer totalement sur qui peut désactiver l’immuabilité, ce qui se passe sous l’API et la capacité de la protection à résister à un administrateur compromis. Ces différences sont tout le sujet.

Ce guide présente la définition, puis consacre l’essentiel de son propos à la partie réellement difficile : distinguer l’immuabilité réellement appliquée de sa version marketing.

Qu’est-ce que le stockage immuable ?

Le stockage immuable est un stockage dans lequel les données, une fois écrites, ne peuvent être ni modifiées ni supprimées pendant une période de rétention définie, y compris par un administrateur. La période de rétention est l’élément déterminant. Immuable ne signifie pas permanent : cela signifie inaltérable pendant une durée donnée, après laquelle les règles normales de cycle de vie s’appliquent de nouveau.

Le modèle de mise en œuvre est le write once, read many (WORM, une écriture, plusieurs lectures) :

• Une écriture : les données sont stockées sous forme de nouvel objet ou de nouvelle version plutôt que modifiées sur place
• Plusieurs lectures : les données restent lisibles pendant toute la période de rétention
• Application de la rétention : le système refuse les suppressions et les écrasements jusqu’à l’expiration de la rétention

C’est sur le troisième point que les produits divergent. Tous les fournisseurs mettent en œuvre les deux premiers. Ce qui les distingue, c’est ce qui applique la rétention, et qui peut passer outre.

Le spectre de l’immuabilité : cinq mises en œuvre, cinq garanties différentes

Le terme « immuable » s’applique aux cinq approches ci-dessous. Elles ne sont pas équivalentes, et l’écart entre la première et la dernière ligne fait toute la différence entre un incident dont on se remet et un incident irrémédiable.

Mise en œuvre	Appliquée par	L’admin sauvegarde peut contourner	Le root du stockage peut contourner	Résiste à la compromission d’identifiants
Option d’immuabilité du logiciel de sauvegarde	L’application de sauvegarde	Oui	Oui	Non
Permissions du système de fichiers + snapshots	Contrôle d’accès du système d’exploitation	Parfois	Oui	Non
Appliance WORM	Matériel dédié	Non	Non	Oui, au sein de son écosystème
S3 Object Lock — mode gouvernance	Couche de stockage	Uniquement avec un privilège spécifique	Selon la mise en œuvre	Partiellement
S3 Object Lock — mode conformité	Couche de stockage	Non	Non	Oui

Une reformulation utile : l’immuabilité n’est pas une propriété des données. C’est une affirmation sur qui détient le pouvoir de suppression. Lorsqu’un fournisseur dit « immuable », la question suivante est toujours la même : immuable face à qui ?

Les quatre voies de contournement

L’immuabilité échoue d’un petit nombre de manières bien connues. Chacune a déjà été activée, configurée et déclarée fonctionnelle jusqu’au jour où elle a été testée.

1. L’immuabilité est assurée par l’application, pas par le stockage

Le logiciel de sauvegarde dispose d’un paramètre d’immuabilité. Il est activé. Mais le référentiel sous-jacent est un bucket ou un système de fichiers ordinaire sans rétention configurée, et la seule chose qui empêche la suppression est le fait que l’application de sauvegarde refuse d’émettre la commande. Un attaquant disposant d’identifiants d’administrateur de sauvegarde n’a pas besoin de vaincre l’immuabilité : il désactive le paramètre.

Le test : arrêtez complètement le logiciel de sauvegarde et essayez de supprimer un objet directement via l’API de stockage. Si la suppression aboutit, l’immuabilité n’était qu’une case à cocher dans l’interface.

2. Le mode gouvernance alors que l’on croyait être en mode conformité

S3 Object Lock propose deux modes de rétention qui offrent des garanties sensiblement différentes. Le mode gouvernance bloque la suppression par les identités ordinaires, mais autorise le contournement par une identité disposant d’une autorisation de contournement spécifique. Le mode conformité n’autorise aucun contournement, par personne, y compris le compte root, pendant toute la durée de rétention.

Le mode gouvernance est le choix par défaut raisonnable pour la souplesse opérationnelle, et le mauvais choix pour une copie dont la seule raison d’être est de résister à un administrateur compromis. De très nombreux déploiements fonctionnent en mode gouvernance en croyant bénéficier de la protection du mode conformité.

3. Sous l’API

C’est le point que la plupart des évaluations négligent. Object Lock est appliqué au niveau de l’API S3. Si la plateforme sous-jacente est un système de fichiers généraliste sur des serveurs généralistes, un administrateur du stockage disposant d’un accès root sur ces nœuds n’est pas du tout contraint par l’API S3. Il peut agir directement sur les fichiers, ou sur les métadonnées qui enregistrent l’état de rétention.

L’immuabilité au niveau de l’API est nécessaire, mais elle ne suffit pas. Ce qui se trouve en dessous détermine si le verrou est un mur ou un simple panneau.

4. La réplique qui n’est pas verrouillée

La rétention doit accompagner les données. Si la copie principale est verrouillée et que la cible de réplication est un bucket ordinaire, c’est la copie la plus faible de l’architecture qui fixe son niveau de protection réel, et un attaquant qui a fait un minimum de reconnaissance la trouvera. Il en va de même pour la hiérarchisation : un objet qui migre vers un niveau moins coûteux sans emporter sa rétention est discrètement redevenu modifiable.

Défense en profondeur : pourquoi une seule couche ne suffit jamais

Les voies de contournement deux à quatre décrivent toutes le même problème structurel : un point d’application unique, situé à une seule couche, avec tout ce qui se trouve en dessous non protégé. La réponse consiste à protéger à plusieurs couches, afin que vaincre l’une d’elles ne suffise pas.

Le cadre CORE5 de Scality est une façon de formaliser cette approche, et c’est une grille d’évaluation utile quel que soit le fournisseur évalué. Il protège à cinq niveaux :

1. Niveau API : immuabilité S3 Object Lock appliquée dès l’écriture d’une sauvegarde
2. Niveau données : gestion des identités et des accès et contrôles cryptographiques, visant l’exfiltration plutôt que la suppression
3. Niveau stockage : un erasure coding avancé qui rend les données indéchiffrables pour quiconque lit directement les supports sous-jacents, ce qui répond à la troisième voie de contournement
4. Niveau géographique : des copies multisites, afin qu’un seul datacenter ne puisse pas constituer tout le rayon d’impact
5. Niveau architecture : le renforcement de la surface d’attaque du système lui-même

L’essentiel n’est pas la marque. C’est qu’une approche crédible de l’immuabilité apporte une réponse à chaque couche, pas seulement à l’API. Si la réponse d’un fournisseur à la question « qu’est-ce qui arrête un administrateur du stockage disposant d’un accès root ? » se résume à rappeler sa prise en charge d’Object Lock, il a répondu à une autre question. Nous avons développé ce raisonnement plus en détail dans les cinq niveaux d’un cadre de cyber-résilience incassable.

Stockage immuable et sauvegarde immuable

Les deux termes sont employés indifféremment alors qu’ils désignent des choses différentes. Le stockage immuable est une capacité de la plateforme : le système sait appliquer une rétention WORM. La sauvegarde immuable est un résultat opérationnel : vos copies de sauvegarde résistent réellement à l’altération.

Le mécanisme ne produit pas à lui seul le résultat. Vous pouvez exploiter un stockage immuable sans détenir une seule sauvegarde immuable : si la rétention n’a jamais été appliquée au bucket dans lequel écrivent les tâches de sauvegarde, si elle l’a été en mode gouvernance, ou si la copie qui compte est la réplique non verrouillée. La capacité est une condition préalable. Le résultat exige une configuration que vous avez vérifiée.

Stockage immuable et snapshots

On suppose souvent que les snapshots sont immuables. Ils sont utiles, mais ce sont un autre type de contrôle.

Les snapshots excellent pour le retour arrière à court terme, la récupération opérationnelle après une erreur et la restauration rapide d’un état récent. Face à un attaquant déterminé, ils présentent trois faiblesses structurelles : l’intervalle entre deux snapshots est une fenêtre d’exposition ; les snapshots peuvent généralement être supprimés par la même identité à privilèges qui administre la production ; et leur gestion partage le plus souvent un plan de contrôle avec les systèmes protégés. Un attaquant qui contrôle ce plan de contrôle contrôle les snapshots.

Conservez les snapshots. Ils ont leur utilité. Mais ne les laissez pas se substituer à une rétention imposée par des politiques sur un plan de contrôle indépendant.

Ce qui se passe réellement sans sauvegardes immuables

Le risque est généralement décrit ainsi : « un attaquant supprime vos sauvegardes ». C’est un mode de défaillance, et pas le plus fréquent. Les scénarios réalistes :

• La rétention est raccourcie, pas supprimée. C’est plus discret qu’une suppression et cela ne déclenche pas les mêmes alertes. Le temps que quelqu’un s’en aperçoive, les points de restauration ont expiré d’eux-mêmes.
• Les sauvegardes sont chiffrées sur place. Les tâches continuent de réussir. Les tableaux de bord restent au vert. Le référentiel contient le bon nombre de fichiers, et aucun ne se restaure.
• C’est le catalogue qui est ciblé, et non les données. Les sauvegardes survivent, mais pas l’index qui les rend exploitables.
• Toutes les copies survivantes sont antérieures à la compromission de moins que le temps de présence de l’attaquant. Rien n’a été supprimé. Tout est intact. Et tout est contaminé.

L’immuabilité répond directement aux deux premiers cas, et au quatrième uniquement si la rétention est correctement réglée, ce qui fait l’objet de la section suivante.

La rétention doit dépasser votre délai de détection

La durée de rétention découle généralement d’une exigence de conformité. Pour les ransomwares, le chiffre déterminant est différent : c’est le temps de présence (dwell time), l’intervalle entre la compromission initiale et sa détection, qui atteint couramment plusieurs semaines.

Si la rétention est de 14 jours et que l’intrus était présent depuis 30 jours, chaque copie immuable dont vous disposez contient peut-être déjà la compromission. L’immuabilité a fonctionné exactement comme prévu. Elle a préservé le mauvais état, parfaitement, et refuse de vous laisser le supprimer.

Une échelle de rétention réaliste, fixée en fonction du risque plutôt que du coût du stockage :

• 7 jours : retour arrière opérationnel, erreurs du quotidien
• 30 jours : fenêtre de reprise après incident
• 90 jours et plus : couverture d’un temps de présence réaliste des ransomwares
• 1 an et plus : conformité et archivage

Le même raisonnement s’applique plus généralement aux compromissions lentes : voir la reprise après une attaque zero-day.

Comment évaluer un stockage immuable : sept questions

Posez ces questions à tout fournisseur, y compris à nous. Ce qui compte n’est pas qu’il réponde oui, mais que la réponse soit précise.

1. Un administrateur peut-il supprimer des données protégées pendant la rétention ? Une bonne réponse nomme le mode et l’identité. Un vague « oui, nous prenons en charge l’immuabilité » est un non.
2. L’application est-elle assurée par la couche de stockage ou par l’application ? Demandez ce qui se passe lorsque le logiciel de sauvegarde est entièrement contourné.
3. Qu’est-ce qui arrête une personne disposant d’un accès root sur les nœuds de stockage ? C’est la question qui distingue les vraies architectures des simples configurations. L’encodage et le chiffrement sous l’API sont des réponses légitimes. « Object Lock » n’en est pas une.
4. La rétention survit-elle à la réplication et à la hiérarchisation ? Faites-le confirmer pour chaque copie et chaque niveau, pas seulement pour la copie principale.
5. La configuration de la rétention est-elle visible, auditée et surveillée par des alertes ? Sinon, la dérive des politiques passe inaperçue, et le raccourcissement de la rétention est la défaillance la plus fréquente en conditions réelles.
6. Comment l’intégrité est-elle prouvée ? Sommes de contrôle, vérification de bout en bout, validation périodique. Immuable et intact sont deux affirmations distinctes.
7. À quelle vitesse la restauration s’effectue-t-elle à votre échelle ? Un coffre que vous ne pouvez pas vider dans les limites de votre RTO a protégé les données, mais pas l’activité. Voir la vitesse de reprise après ransomware pour savoir comment la chiffrer.

Où le stockage immuable trouve sa place

Les déploiements courants, à peu près dans l’ordre de la fréquence à laquelle ils justifient l’effort :

• Référentiels de sauvegarde : sauvegardes de VM, de NAS et de bases de données. La cible la plus précieuse dans la plupart des environnements et le point de départ habituel.
• Coffre de cyber-récupération : un référentiel logiquement isolé, avec une longue rétention, des politiques strictes et des accès distincts, situé derrière un air gap logique.
• Archive de conformité : rétention réglementaire, documents juridiques, imagerie médicale. Là où le WORM est né, et toujours l’usage le plus naturel.
• Journaux et pistes d’audit : événements de sécurité et preuves d’audit, dont la valeur dépend du fait que personne n’a pu les modifier.

Bien l’exploiter

Trois pratiques distinguent les déploiements qui tiennent leurs promesses de ceux qui leur ressemblent seulement sur le papier.

Limitez le nombre de classes de rétention. Quatre suffisent largement. La complexité des politiques de rétention crée des lacunes que personne ne voit, et elles sont toujours découvertes au mauvais moment.

Séparez les identifiants. Aucune identité ne doit contrôler à la fois la configuration des sauvegardes, la configuration du stockage et le contournement de la rétention. Si un seul compte peut faire les trois, l’immuabilité est décorative : l’attaquant n’a qu’à compromettre ce compte. Envisagez des clés gérées par le client conservées dans un module de sécurité matériel (HSM) lorsque la séparation doit être imposée techniquement plutôt que par la procédure.

Testez les restaurations, pas les sauvegardes. La réussite d’une tâche est un signal du chemin d’écriture. Elle ne dit rien de la capacité à restaurer les données. Testez des restaurations complètes, partielles et chronométrées à grande échelle, de manière planifiée, et considérez les chiffres obtenus comme l’état réel du système.

Questions fréquentes

Le stockage immuable est-il la même chose que le stockage WORM ?

Le WORM est le modèle de mise en œuvre ; le stockage immuable est la catégorie. Presque tout le stockage immuable repose sur une application de la rétention de type WORM, mais « appliance WORM » désigne généralement une catégorie précise de matériel dédié, alors que le stockage immuable désigne aujourd’hui plus souvent S3 Object Lock sur du stockage objet.

Un ransomware peut-il chiffrer un stockage immuable ?

Pas les objets protégés, pendant la rétention. Un ransomware ne peut chiffrer que ce sur quoi il peut écrire, et un objet sous rétention active rejette à la fois la modification et la suppression. Les réserves sont les voies de contournement : si l’immuabilité est assurée au niveau applicatif, si le mode gouvernance est utilisé ou si l’attaquant dispose d’un accès root sous l’API, la protection peut ne pas tenir.

Quelle est la différence entre le mode gouvernance et le mode conformité ?

Le mode gouvernance bloque la suppression, mais autorise le contournement par une identité disposant d’une autorisation de contournement spécifique. Le mode conformité n’autorise aucun contournement, par personne, y compris le compte root, jusqu’à l’expiration de la rétention. Le mode gouvernance convient à la souplesse opérationnelle ; le mode conformité est celui qu’il faut pour une copie qui doit résister à un administrateur compromis.

Faut-il du stockage objet pour obtenir l’immuabilité ?

Non : les appliances WORM et certaines approches fondées sur des systèmes de fichiers l’offrent aussi. Le stockage objet compatible S3 avec Object Lock est devenu le choix courant parce qu’il s’intègre à pratiquement toutes les plateformes de sauvegarde modernes, monte en charge sans remplacement complet de l’infrastructure et applique la rétention via une couche de politiques plutôt que via les permissions de fichiers.

Le stockage immuable suffit-il à lui seul ?

Non. Il empêche la modification d’une copie. Il n’isole pas le chemin d’accès à cette copie, ne vous dit pas quel point de restauration est sain et ne rend pas la restauration assez rapide pour être utile. L’immuabilité est l’une des quatre propriétés dont une architecture de restauration a besoin, aux côtés de l’isolation, du parallélisme de restauration et de la validation.

En bref

Le stockage immuable est le contrôle le plus efficace dont on dispose pour protéger les données de restauration. C’est aussi le contrôle le plus souvent revendiqué et le moins souvent vérifié, car l’affirmation est facile et la vérification exige de savoir qui détient le pouvoir de suppression à chaque couche de la pile.

Les organisations qui y parviennent traitent l’immuabilité comme un système plutôt que comme un paramètre : appliquée au niveau du stockage, impossible à contourner sous l’API, étendue à chaque réplique, conservée plus longtemps que la durée probable de présence non détectée d’un attaquant, et prouvée par des restaurations que quelqu’un a réellement effectuées.

Tout le reste n’est qu’une case à cocher jamais testée.

---

Scality conçoit un stockage objet S3 dont l’immuabilité est appliquée de l’API jusqu’à l’architecture. Découvrez le fonctionnement de CORE5, ou parcourez le glossaire pour les termes utilisés dans ce guide.