S3 Object Lock : conservation, legal holds et test pratique

S3 Object Lock protège une version d'objet stockée contre la suppression ou le remplacement, selon les règles de conservation configurées. Cette fonction est utile lorsqu'une sauvegarde, un document ou un jeu de données doit résister à une suppression accidentelle ou à la compromission d'un compte applicatif. Le point essentiel est la version : verrouiller le fichier d'hier n'empêche pas de téléverser un autre fichier sous le même nom aujourd'hui.

Ce guide explique les mécanismes et propose un exercice en mode gouvernance dans un bucket de test. Commencez avec des fichiers fictifs, notez les résultats attendus et vérifiez que vous pouvez récupérer la version protégée avant de définir une politique de conservation en production.

Ce que protège S3 Object Lock

Amazon S3 stocke les objets sous des clés qui ressemblent souvent à des chemins de fichiers. Avec le versionnement S3, chaque téléversement vers une même clé peut créer une version distincte. Une requête visant la clé renvoie normalement la version courante ; une ancienne version reste accessible par son identifiant de version.

Object Lock ajoute une protection WORM, pour « écriture unique, lectures multiples », aux versions individuelles. Une version conservée garde sa protection même lorsqu'une nouvelle version devient courante. Les versions d'une même clé peuvent avoir des paramètres de conservation différents.

Par exemple, une application écrit reports/monthly.csv, puis téléverse un remplacement incorrect. Conserver la première version n'est utile que si votre procédure de récupération permet de l'identifier et de la lire. Le nom du fichier ne suffit pas à prouver que le document attendu reste disponible.

Mode gouvernance et mode conformité

Les deux modes de conservation se distinguent par les possibilités de contournement :

• Mode gouvernance : un utilisateur disposant des droits appropriés peut contourner la conservation. AWS exige l'autorisation s3:BypassGovernanceRetention et une demande explicite de contournement.
• Mode conformité : même l'utilisateur racine du compte AWS ne peut pas supprimer la version protégée ni raccourcir sa période de conservation tant que la protection est active.

Utilisez le mode gouvernance pour l'exercice ci-dessous. Avant d'adopter le mode conformité, définissez l'exigence de conservation et les conséquences du maintien de données incorrectes ou inutiles. Un paramètre logiciel ne démontre pas à lui seul que tout votre processus documentaire satisfait une obligation légale.

Un test réalisé avec un compte administrateur peut être trompeur. La console S3 ajoute automatiquement l'en-tête de contournement pour les utilisateurs autorisés. AWS précise ce comportement dans ses considérations sur Object Lock. Pour vérifier le blocage d'une suppression ordinaire, utilisez un rôle de test sans cette autorisation.

Durées de conservation, legal holds et event holds

La conservation fixe possède une date de fin. Un legal hold est une mesure distincte, sans échéance programmée : un utilisateur autorisé doit le lever. Les deux mécanismes peuvent protéger la même version. Retirer l'un ne retire pas l'autre.

L'API des legal holds applique un état ON ou OFF à la version choisie. Attribuez clairement la responsabilité de modifier cet état. Sans responsable ni processus de réexamen, une mesure de conservation peut maintenir les données bien après la disparition de son motif initial.

AWS propose aussi une conservation variable au moyen d'event holds. Un event hold maintient la protection de la version ; sa levée déclenche la durée de conservation configurée. Un legal hold fonctionne autrement : sa levée met immédiatement fin à sa propre protection, même si d'autres règles continuent de s'appliquer. Consultez les champs actuels de l'API de conservation avant d'automatiser ce comportement. L'exercice utilise une durée fixe pour simplifier le calendrier attendu.

Activer Object Lock sur un périmètre défini

Object Lock exige le versionnement sur un bucket S3 à usage général. AWS permet son activation sur les buckets nouveaux ou existants qui sont éligibles. Une fois la fonction activée, vous ne pouvez plus la désactiver ni suspendre le versionnement de ce bucket. Suivez les instructions de configuration AWS à jour.

Activer la fonction et protéger toutes les versions souhaitées sont deux étapes distinctes. Une règle de conservation par défaut fournit les paramètres des nouveaux téléversements qui n'indiquent pas leur propre conservation. Elle ne s'applique pas rétroactivement à toutes les versions existantes.

Pour les données déjà présentes, identifiez les versions à protéger et appliquez leur conservation explicitement. S3 Batch Operations permet de le faire à grande échelle. Le manifeste doit préciser les identifiants de version lorsqu'une version particulière est visée ; sinon, l'opération cible la plus récente. Examinez un petit ensemble de résultats avant de lancer un traitement important.

Pourquoi un objet verrouillé peut sembler supprimé

Dans un bucket versionné, une demande de suppression sans identifiant de version crée normalement un marqueur de suppression. Pour supprimer définitivement une version donnée, la requête doit préciser son identifiant. Il s'agit de deux opérations différentes, comme l'explique la référence DeleteObject.

Un marqueur de suppression peut devenir courant alors que l'ancienne version protégée reste intacte. L'application peut alors se comporter comme si le fichier n'existait plus. « L'objet a disparu de la liste habituelle » et « les données protégées ont été supprimées » désignent donc deux résultats différents.

Conservez ensemble le nom du bucket, la clé et l'identifiant de version. Lors d'une récupération, examinez les versions et récupérez explicitement celle qui vous intéresse avant de la rendre à nouveau courante.

Un petit test en mode gouvernance

La procédure suivante est à réaliser dans votre environnement hors production. Elle ne signifie pas qu'un test a été exécuté sur votre compte AWS. Utilisez un nouveau bucket clairement identifié pour l'exercice et deux petits fichiers texte contenant des données différentes, sans information sensible.

1. Préparer le bucket et l'identité de test

Maintenez le blocage des accès publics. Activez le versionnement et Object Lock, puis configurez une conservation par défaut d'un jour en mode gouvernance. AWS recommande d'attendre 15 minutes après la première activation du versionnement avant d'effectuer des écritures. Notez le bucket, la région, le responsable du test et la date de nettoyage prévue.

Utilisez un rôle limité au bucket de test. Il doit disposer des autorisations nécessaires à l'exercice, notamment pour lire les versions et les métadonnées de conservation, et tenter une suppression de version. Ne lui accordez pas le contournement du mode gouvernance. Vérifiez ces droits avant le test : un refus dû à une autre autorisation manquante ne prouverait pas que la conservation fonctionne.

2. Téléverser deux versions et examiner leurs paramètres

Téléversez le premier fichier sous la clé object-lock-test.txt. Notez son identifiant de version. Téléversez le second fichier sous exactement la même clé et notez aussi son identifiant. Vérifiez la présence des deux versions, puis examinez séparément leur mode et leur date de fin de conservation.

La commande AWS CLI de lecture de la conservation permet de choisir la version explicitement. Remplacez les valeurs indicatives par celles de votre test :

aws s3api get-object-retention --bucket TEST_BUCKET --key object-lock-test.txt --version-id FIRST_VERSION_ID

Le résultat attendu est une conservation en mode gouvernance avec une date future. Si ces métadonnées manquent, corrigez le téléversement ou la règle par défaut avant de tester la suppression.

3. Tester séparément la version protégée et la clé ordinaire

Avec le rôle de test, tentez de supprimer la première version en indiquant son identifiant. Tant que la conservation est active, le résultat attendu est un refus. Vérifiez ensuite que la version existe toujours et reste téléchargeable.

Supprimez ensuite uniquement la clé ordinaire, sans sélectionner de version. Avec l'autorisation de suppression correspondante, cette opération peut créer un marqueur de suppression. Examinez la liste des versions et confirmez que l'ancienne version protégée reste présente. Notez les deux résultats : la création réussie d'un marqueur n'indique pas un échec de la protection.

4. Vérifier un legal hold et les conditions de nettoyage

Avec une identité autorisée, placez un legal hold sur l'une des versions de test. Vérifiez son état ON. Après la fin de la durée fixe, il doit toujours empêcher la suppression. Levez-le uniquement sur cette version de test, puis vérifiez qu'aucune autre protection de conservation ne bloque sa suppression.

Pour le nettoyage, examinez toutes les versions et tous les marqueurs créés pendant l'exercice. Attendez la fin de chaque période applicable et levez uniquement les mesures de test que vous avez ajoutées. Supprimez ensuite le bucket vide. Si une protection bloque le nettoyage, notez la raison et prévoyez une intervention ultérieure plutôt que d'élargir les autorisations pour forcer un résultat immédiat.

Prouver la récupération, en plus du blocage des suppressions

Téléchargez la version choisie et comparez son contenu au fichier d'origine. L'API GetObject accepte une requête visant une version précise, qui nécessite l'autorisation s3:GetObjectVersion. Certaines classes d'archivage exigent une restauration avant de pouvoir lire les données.

Incluez dans le test les identités et les clés de chiffrement nécessaires. Un objet chiffré intact peut devenir inutilisable si sa clé disparaît. AWS décrit les conséquences irréversibles de la suppression d'une clé KMS ; la conservation de l'objet ne préserve pas sa clé à votre place.

Intégrez Object Lock à un plan de sauvegarde dans le cloud plus large. Testez le chemin de récupération réel, pas seulement la présence d'un indicateur de verrouillage. Adoptez une stratégie de sauvegarde 3-2-1 pour que les objets versionnés et verrouillés complètent des copies sur d’autres supports et dans d’autres lieux. Notre guide des tests de récupérabilité explique comment étendre cette vérification à une application et à ses dépendances.

Prévoir ensemble les coûts et les règles de cycle de vie

Les versions stockées occupent de l'espace. S3 facture chaque version comme un objet complet, sans stocker uniquement les différences entre révisions. Remplacer fréquemment un gros fichier peut donc produire bien plus de données conservées que ne le laisse penser la taille de sa seule version courante.

Une règle d'expiration Lifecycle ne garantit pas que toutes les versions disparaîtront à cette date. Les versions courantes et non courantes suivent des règles différentes, et Object Lock empêche la suppression des versions protégées. La fin de conservation rend la suppression possible ; elle ne déclenche pas elle-même une demande de suppression.

Estimez les volumes courants et non courants, les requêtes, les récupérations, les transferts, la réplication et les éventuelles durées minimales de stockage facturées. Consultez les tarifs S3 à jour pour la région et la classe choisies. Prévoyez aussi un rappel pour réexaminer les mesures de conservation encore actives et les nettoyages en échec.

Avant d'appliquer la politique en production

• Identifiez les documents et les versions à protéger, avec un responsable désigné.
• Choisissez le mode et la durée de conservation ; examinez qui peut contourner la gouvernance ou modifier les mesures de conservation.
• Confirmez que les nouveaux téléversements reçoivent les bons paramètres et que les versions existantes sont traitées séparément.
• Testez la suppression par version, les marqueurs, la récupération et le nettoyage avec des droits réalistes.
• Préservez les accès de récupération et les clés de chiffrement pendant toute la durée de conservation.
• Budgétez les versions conservées et fixez une date de réexamen de la politique.

Questions fréquentes

Object Lock et le versionnement sont-ils identiques ?

Non. Le versionnement conserve des révisions distinctes ; Object Lock ajoute des restrictions à la suppression des versions protégées. Le versionnement est nécessaire, mais son activation seule ne crée pas une politique de conservation.

Puis-je désactiver Object Lock plus tard ?

Pas sur un bucket où la fonction est activée. La règle de conservation par défaut du bucket et la protection des versions existantes sont des paramètres distincts. Modifier la règle par défaut ne retire pas les protections déjà appliquées.

La compatibilité S3 garantit-elle le même comportement ?

Non. Vérifiez les opérations de conservation, les autorisations, le versionnement et les limites documentés par le fournisseur. Ce guide décrit Amazon S3. Ne supposez pas qu'un autre service compatible S3 implémente tous les mécanismes présentés ici.