Presque toutes les propositions de stockage de sauvegarde portent désormais le mot immuable en première page. Derrière ce mot se trouve généralement un mécanisme précis, S3 Object Lock, et derrière ce mécanisme un ensemble de garanties plus étroites et plus précises que ne le suggère le raccourci. Les équipes qui savent exactement ce qui est verrouillé, par qui et pour combien de temps se remettent généralement d’un ransomware ; les équipes qui supposent qu’« immuable » signifie « en sécurité » découvrent parfois la différence pendant un incident.
Cela compte parce que les attaquants se sont adaptés. Chiffrer les données de production est la moitié d’une opération de ransomware moderne ; l’autre moitié consiste à détruire d’abord les sauvegardes pour que la victime n’ait pas d’autre choix que de payer. L’object lock existe pour faire échouer cette seconde étape. Il le fait de manière fiable lorsqu’il est correctement configuré et ne fait strictement rien lorsqu’il ne l’est pas. Cet article définit précisément l’object lock, couvre les trois modes, explique pourquoi les fenêtres de rétention sont le point faible le plus courant, décrit comment les applications de sauvegarde l’utilisent, et se termine par une checklist.
Que fait l’object lock ?
S3 Object Lock est un contrôle WORM (write-once-read-many) appliqué par le système de stockage aux versions individuelles d’objets. Lorsqu’une version est verrouillée, aucun appel d’API ne peut la supprimer ni l’écraser avant l’expiration de sa période de rétention. Cette phrase contient quatre qualificatifs, et chacun compte.
Par version d’objet, pas par bucket
L’object lock est activé au niveau du bucket, mais le verrou lui-même est une propriété de chaque version d’objet. Un bucket avec object lock activé peut toujours contenir des versions non verrouillées si l’écrivain n’a demandé aucune rétention et que le bucket n’a pas de valeur par défaut. Activer la fonctionnalité est un prérequis, pas la protection.
Sémantique WORM
Une version verrouillée peut être lue aussi souvent que nécessaire, et copiée ou répliquée ailleurs. Un PUT sur la même clé crée une nouvelle version au lieu de modifier l’ancienne. Ce que l’object lock empêche, c’est la suppression ou le remplacement de la version existante ; les anciennes données restent lisibles quoi qu’on écrive ensuite.
Une période de rétention avec une fin fixe
Chaque verrou possède un horodatage « retain until ». Avant cette date, la suppression est refusée. Après, la version devient un objet ordinaire que les règles de cycle de vie ou l’application de sauvegarde peuvent nettoyer. La rétention peut être prolongée sur une version existante mais, en mode compliance, jamais raccourcie.
Appliqué par le système de stockage, pas par l’application de sauvegarde
C’est ce qualificatif qui donne sa valeur à l’object lock. Le serveur de sauvegarde, sa base de données, son compte de service et chaque administrateur pouvant s’y connecter sont en dehors du périmètre d’application. Si tous sont compromis, la couche stockage refuse toujours la suppression, car la décision est prise à partir des métadonnées propres à l’objet. Une protection appliquée par l’application dont l’attaquant a déjà pris le contrôle n’est pas une protection.
Ce contre quoi l’object lock ne protège pas
La liste de ce que l’object lock ne fait pas est plus longue que la liste de ce qu’il fait. Aucun des points suivants n’est un défaut de la fonctionnalité ; ce sont des limites, et la plupart des défaillances réelles relèvent de l’une d’elles.
- Les buckets où il n’a jamais été activé. L’object lock doit être activé à la création du bucket et, sur la plupart des plateformes, ne peut pas être ajouté a posteriori. Un dépôt migré depuis un ancien bucket, ou une copie secondaire créée dans la précipitation, peut n’avoir aucun verrou alors que le dépôt principal est étiqueté immuable.
- La perte du site unique. L’immutabilité est un contrôle logique. Elle ne survit pas à un incendie, une inondation, un vol de matériel ou une suppression du cluster entier par une personne disposant d’un accès au niveau de l’infrastructure. Une copie verrouillée unique reste une copie unique.
- Les identifiants pouvant contourner le mode governance. Les verrous en mode governance peuvent être retirés par toute identité détenant la permission de contournement (bypass). Si le compte de service de sauvegarde ou un compte administratif partagé la possède, un attaquant qui vole ce compte hérite de la capacité de déverrouiller et de supprimer.
- Les implémentations en passerelle sur un système de fichiers effaçable. Certains points d’accès S3 traduisent les appels S3 vers un système fichier ou bloc sous-jacent. L’API peut honorer le verrou tandis que le volume sous-jacent reste inscriptible pour un administrateur du stockage ou de l’hyperviseur, ou pour quiconque dispose d’un shell root. Le verrou n’est solide que dans la mesure de la couche qui détient les octets.
- Le versioning désactivé ou les marqueurs de suppression mal compris. L’object lock exige le versioning. Un DELETE simple sur un objet verrouillé n’échoue pas ; il place un marqueur de suppression par-dessus et la version verrouillée reste en dessous, de sorte qu’un listage rapide montre l’objet comme disparu. Les opérateurs qui l’ignorent peuvent supposer qu’un objet listé est protégé alors qu’il s’agit simplement d’une dernière version non verrouillée.
- Le catalogue de sauvegarde et les métadonnées. Les blocs dans le bucket sont inutiles sans le catalogue qui indique quels blocs appartiennent à quel point de restauration. Si le catalogue réside sans protection sur le serveur de sauvegarde, un attaquant peut laisser les données intactes et les rendre néanmoins irrécupérables dans tout délai pratique.
En quoi le mode compliance, le mode governance et le legal hold diffèrent-ils ?
S3 définit deux modes de rétention et un indicateur indépendant. Ils se comportent différemment sous attaque, le choix mérite donc davantage de réflexion que l’acceptation d’une valeur par défaut.
| Contrôle | Qui peut le retirer ou le raccourcir | Comment il expire | Usage typique |
|---|---|---|---|
| Mode compliance | Aucune identité, y compris le propriétaire du compte. | Uniquement à la date retain-until. La rétention peut être prolongée, jamais réduite. | Copies de reprise après ransomware, rétention réglementaire, toute copie devant survivre à un administrateur compromis. |
| Mode governance | Toute identité disposant de la permission de contournement. | À la date retain-until, ou plus tôt via contournement. | Protection contre les accidents et les mauvais usages ordinaires lorsqu’une porte de sortie contrôlée est acceptable. |
| Legal hold | Toute identité disposant de la permission de legal hold. | Jamais de lui-même ; reste jusqu’à sa levée explicite. | Conservations pour litige ou enquête superposées à l’un des deux modes ; pas un contrôle anti-ransomware en soi. |
Pour les dépôts de sauvegarde dont l’objectif est de survivre à une intrusion, le mode compliance est la valeur par défaut appropriée. Le mode governance est souvent choisi parce que garder une issue de secours semble plus sûr, mais cette issue est précisément ce qu’un attaquant disposant d’identifiants volés utilisera. Si une porte de sortie governance est réellement nécessaire, la permission de contournement doit appartenir à une identité jamais utilisée pour le travail courant et protégée par une authentification multifacteur forte.
Pourquoi la fenêtre de rétention est-elle la faille la plus courante ?
Un verrou qui expire avant que quiconque remarque l’intrusion ne protège rien. La durée de rétention est une décision de sécurité, pas une décision de capacité, et doit être fixée en fonction du temps attendu entre la compromission initiale et la détection, souvent appelé temps de présence de l’attaquant (dwell time).
Supposons qu’une organisation fixe une période d’immutabilité de sept jours parce qu’elle correspond à son cycle de sauvegarde et garde la capacité prévisible. Supposons qu’un attaquant prenne pied le premier jour, passe trois semaines à collecter des identifiants et déclenche le chiffrement le vingt-deuxième jour. Chaque sauvegarde écrite avant le quinzième jour a déjà quitté sa fenêtre de rétention et peut être supprimée par quiconque détient les identifiants du service de sauvegarde. Les seuls points de restauration immuables sont les sept plus récents, qui peuvent déjà contenir des données préparées ou chiffrées. Le verrou a fonctionné exactement comme configuré ; la configuration ne correspondait pas à la menace. Trois conséquences en découlent.
La rétention doit dépasser le temps de présence réaliste, avec une marge
Les estimations publiées du temps de présence varient et changent d’une année à l’autre, cet article n’en citera donc aucune. Le principe est stable : si l’organisation ne peut pas détecter un intrus avec confiance dans un nombre de jours donné, la fenêtre immuable doit être plus longue que ce nombre. Trente jours est un point de départ courant ; les environnements réglementés ou à forte valeur vont souvent plus loin.
Période d’immutabilité et rétention de sauvegarde sont des paramètres différents
Les applications de sauvegarde distinguent la durée de conservation d’un point de restauration (politique de rétention) et la durée pendant laquelle le stockage refuse de le supprimer (période d’immutabilité). Les deux peuvent être alignées, ou la période d’immutabilité peut être plus courte. Ce qui ne doit pas se produire est une période d’immutabilité si courte que le nettoyage propre à l’application, ou une copie compromise de celle-ci, puisse supprimer des points de restauration dont l’organisation a encore besoin.
Des verrous plus longs coûtent de la capacité
Les données qui ne peuvent pas être supprimées ne peuvent pas être récupérées. Étendre le verrou de sept à trente jours augmente l’empreinte conservée, et cette augmentation doit être planifiée plutôt que découverte ; l’article sur le dimensionnement du dépôt de sauvegarde explique comment la modéliser.
Comment les applications de sauvegarde utilisent-elles l’object lock ?
Les logiciels de sauvegarde exposent rarement les paramètres de rétention S3 bruts. Le dépôt ou le travail porte plutôt un paramètre d’immutabilité que l’application traduit en rétention par objet au moment de l’écriture. Typiquement, l’administrateur pointe un dépôt vers un bucket avec object lock activé et spécifie une période d’immutabilité en jours. Chaque objet créé par le travail reçoit une date retain-until calculée à partir de cette période et, dans de nombreux produits, prolongée afin que toute la chaîne dont dépend un point de restauration reste verrouillée aussi longtemps que le point de restauration lui-même.
Deux détails méritent vérification. Premièrement, confirmez quel mode l’application demande ; la plupart des éditeurs qui prennent en charge l’object lock écrivent en mode compliance, mais l’opérateur doit vérifier plutôt que supposer. Deuxièmement, confirmez comment l’application interagit avec la rétention par défaut du bucket. Lorsque les deux existent, la plus longue l’emporte généralement, mais les décalages entre les deux sont une source fréquente de confusion lors des audits.
La page des applications de sauvegarde validées liste les plateformes testées avec ARTESCA, ce qui lève une partie de ces incertitudes.
Avant de s’y fier : une checklist
Ces vérifications prennent une après-midi et auraient évité la plupart des défaillances ci-dessus.
- Confirmez que l’object lock est activé sur chaque bucket contenant des données de sauvegarde, y compris les copies secondaires et les buckets créés lors de migrations.
- Confirmez que le versioning est activé et compris, et que les opérateurs savent qu’un marqueur de suppression n’est pas une suppression.
- Échantillonnez des objets récents et lisez leurs métadonnées de rétention directement via l’API S3. Vérifiez que le mode et la date retain-until correspondent à la conception.
- Tentez de supprimer une version verrouillée avec les propres identifiants de l’application de sauvegarde et confirmez que le stockage refuse.
- Si le mode governance est utilisé, listez chaque identité détenant la permission de contournement et justifiez chacune.
- Fixez la période d’immutabilité en fonction du temps de présence de l’attaquant, pas du cycle de sauvegarde, et documentez le raisonnement.
- Protégez le catalogue et la configuration de sauvegarde aussi sérieusement que les données, par exemple en les exportant vers un bucket verrouillé.
- Conservez au moins une copie dans un second emplacement ou domaine administratif, afin de combiner immutabilité et indépendance.
- Restaurez depuis une copie immuable selon un calendrier. Un verrou jamais testé lors d’une reprise réelle n’est qu’une hypothèse.
L’object lock est fiable précisément parce que ses garanties sont étroites et mécaniques. Savoir où elles s’arrêtent le transforme d’une case à cocher en un plan de reprise. Un complément d’architecture est disponible sur la page immutable backup.
Comment Scality ARTESCA applique l’object lock
Scality ARTESCA est un stockage objet S3 conçu comme cible de sauvegarde, et l’object lock y est appliqué dans le chemin de données plutôt que superposé comme une passerelle sur un système de fichiers inscriptible séparément. Une version verrouillée voit sa suppression refusée par le système de stockage lui-même, quels que soient les identifiants ou la console à l’origine de la requête.
ARTESCA prend en charge le mode compliance, de sorte qu’une période de rétention une fois définie ne peut être ni raccourcie ni retirée par aucun compte, y compris l’administrateur du stockage. Il est validé avec les principales applications de sauvegarde, dont Veeam, Commvault, Cohesity et Rubrik, de sorte que la correspondance entre le paramètre d’immutabilité d’un travail et la rétention écrite sur chaque objet est testée plutôt que supposée. Le modèle de sécurité est décrit sur la page sécurité et cyber-résilience.
Quelle que soit la plateforme qui détient les sauvegardes, l’étape pratique est la même : lisez les métadonnées de rétention sur un objet réel, tentez de le supprimer avec les identifiants qu’un attaquant volerait, et fixez la fenêtre plus longue que le temps qu’il faudrait pour le remarquer.