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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Ces vérifications prennent une après-midi et auraient évité la plupart des défaillances ci-dessus.
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.
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.