Sauvegardes immuables : S3 Object Lock contre le ransomware

Le déroulé est toujours le même. L'attaquant obtient des identifiants avec des droits d'écriture sur l'infrastructure, souvent via un poste de travail compromis ou un jeton d'API qui traînait dans un pipeline CI. Avant de lancer le chiffrement de la production, il va d'abord chercher le dépôt de sauvegarde et le vider. C'est l'étape rationnelle du point de vue de l'attaquant : sans sauvegarde restaurable, la victime n'a plus le choix de refuser de payer. L'ANSSI le formule sans détour dans son guide sur la sauvegarde des systèmes d'information : les rançongiciels ciblent directement les infrastructures de sauvegarde pour augmenter la pression sur les victimes.

La question qui compte n'est donc pas « est-ce qu'on a des sauvegardes », mais « est-ce que le compte qui vient de se faire compromettre a le pouvoir de les supprimer ». Sur un dépôt S3 classique, avec des credentials qui ont s3:DeleteObject et s3:DeleteBucket, la réponse est oui. C'est exactement ce que S3 Object Lock est censé corriger, à condition de comprendre où se situe réellement la frontière d'immuabilité, parce qu'elle n'est pas là où on l'imagine spontanément.

S3 Object Lock applique un modèle WORM (write once, read many) au niveau de la version d'un objet, pas du bucket entier. Deux modes existent, et ils ne se distinguent pas par la durée de rétention mais par qui peut la contourner.

En mode gouvernance, un objet verrouillé ne peut pas être écrasé ni supprimé, sauf par un principal IAM disposant de la permission s3:BypassGovernanceRetention, et à condition d'envoyer explicitement l'en-tête x-amz-bypass-governance-retention:true dans la requête. C'est un garde-fou contre l'erreur humaine et l'automatisation qui dérape, pas contre un attaquant qui a mis la main sur un compte à privilèges. Si ce compte porte la permission de bypass, il rejoue exactement le geste que Object Lock était censé empêcher.

En mode conformité, personne ne peut raccourcir la rétention ni supprimer l'objet avant l'échéance, y compris le root de l'account AWS. La documentation AWS est explicite : la seule façon de supprimer un objet protégé en mode conformité avant expiration, c'est de supprimer le compte AWS entier. C'est la seule des deux configurations qui tient réellement face à un attaquant disposant de droits d'administration complets sur l'infrastructure.

Le piège classique : déployer Object Lock en mode gouvernance parce que c'est le défaut le plus simple à mettre en place, puis découvrir en post-mortem que le compte de service utilisé pour la sauvegarde portait s3:BypassGovernanceRetention en pratique. La permission traîne souvent dans des politiques IAM larges héritées d'un provisioning générique, jamais auditées spécifiquement pour ce bucket.

Object Lock protège des objets individuels. Il ne protège pas mécaniquement contre la suppression du bucket lui-même si le compte compromis dispose des droits IAM correspondants et que le versioning n'est pas activé partout où il devrait l'être. Object Lock impose de toute façon le versioning du bucket, ce qui est déjà une bonne nouvelle : chaque écrasement crée une nouvelle version au lieu de détruire l'ancienne. Mais versioning activé ne veut pas dire suppression de bucket impossible.

C'est là qu'intervient le second garde-fou, indépendant d'Object Lock : le MFA delete. Une fois activé sur un bucket versionné, il impose un code d'authentification multifacteur pour suspendre le versioning ou pour supprimer définitivement une version d'objet. Combiné à une politique IAM qui retire au compte de service de sauvegarde tout droit s3:DeleteBucket et s3:PutBucketVersioning, on ferme la voie de contournement qu'Object Lock seul laisse ouverte.

Sur le terrain, la checklist tient en trois lignes, et c'est celle qu'on vérifie en premier lors d'un audit de dépôt de sauvegarde S3 :

• le compte IAM utilisé par l'outil de sauvegarde porte-t-il s3:BypassGovernanceRetention, même hérité d'une politique large ;
• le bucket a-t-il le droit s3:DeleteBucket accessible à ce même compte ;
• le MFA delete est-il actif sur le bucket, ou seul le mot de passe du compte racine protège le versioning.

Un compte de sauvegarde qui répond oui à la première ou à la deuxième question n'a d'immuable que le nom.

Restic et kopia sont les deux outils de sauvegarde chiffrée les plus utilisés avec un backend S3 en dehors des suites commerciales, et ils n'abordent pas Object Lock de la même façon.

Kopia a un support natif de l'Object Lock S3, documenté comme tel : l'extension se déclare à la création du dépôt, et le mode conformité est explicitement recommandé par le projet parce qu'il garantit qu'aucun compte, y compris root, ne peut supprimer les fichiers du bucket avant expiration. Le point d'attention opérationnel est la maintenance : par défaut, kopia ne renouvelle pas automatiquement les dates de rétention. Il faut activer le renouvellement dans les options de maintenance complète et s'assurer que cette maintenance tourne au moins aussi souvent que la période de rétention configurée. Un dépôt kopia dont la maintenance planifiée s'arrête silencieusement pendant plusieurs semaines finit avec des objets dont le verrou a expiré, sans qu'aucune alerte ne le signale de base.

Restic, à l'inverse, n'a pas encore de support natif d'Object Lock à ce jour. Le sujet est un ticket ouvert côté projet, pas une fonctionnalité livrée, parce que restic a besoin de pouvoir supprimer certains fichiers de verrouillage internes pour fonctionner, ce qui entre en tension directe avec un mode conformité strict. Ça ne veut pas dire que restic est incompatible avec un bucket verrouillé : ça veut dire que la protection repose sur un montage plus fragile, par exemple rest-server en mode append-only ou un proxy rclone serve restic qui interdit la suppression au niveau applicatif plutôt qu'au niveau du stockage objet. C'est une immuabilité de convention, pas une immuabilité imposée par S3, et elle ne résiste pas à un attaquant qui atteint directement le bucket avec des credentials S3 valides. Pour aller plus loin sur les mécaniques internes des deux outils, notre comparatif kopia contre restic détaille les différences de modèle de chunking et de gestion du dépôt qui expliquent cet écart.

Sur un bucket S3 ou compatible S3 avec Object Lock activé à la création, la commande mc (client MinIO, compatible AWS S3) pour poser une rétention par défaut en mode conformité, sur 30 jours, ressemble à ceci :

mc retention set --default COMPLIANCE 30d monalias/backups-prod

Toute nouvelle version d'objet écrite dans backups-prod hérite automatiquement de cette rétention de 30 jours, en mode conformité. Vérification côté objet avec mc retention info :

mc retention info monalias/backups-prod/2026-08-10/repo-kopia.pack

La sortie indique le mode, la date d'expiration du verrou, et confirme qu'aucune commande de suppression ne passera avant cette date, quel que soit le compte qui l'émet. C'est le même comportement documenté côté MinIO AIStor que côté AWS S3 natif : les deux implémentent le même modèle de rétention gouvernance/conformité, ce qui rend la migration d'un backend à l'autre transparente pour la politique de verrouillage. Pour des workloads qui tournent déjà sur du stockage objet self-hosted, notre article sur le déploiement de MinIO en tant que backend S3 dans un cluster Kubernetes couvre la mise en place du bucket avec versioning et Object Lock activés dès la création, condition obligatoire côté AWS comme côté MinIO puisque Object Lock ne se rétrofit pas sur un bucket existant.

Le mode gouvernance n'a d'intérêt que comme filet contre l'erreur opérationnelle interne, jamais comme protection contre une compromission de compte. Si l'objectif est de résister à un attaquant qui a des credentials valides sur l'infrastructure, la seule configuration qui tient est : mode conformité, versioning et MFA delete actifs, et un compte de service pour la sauvegarde qui ne porte ni s3:BypassGovernanceRetention ni s3:DeleteBucket. Tout le reste est une protection de confort, utile contre l'erreur humaine, inutile contre un rançongiciel qui a fait ses devoirs.

Côté outillage, kopia est aujourd'hui le choix le plus cohérent avec cette exigence, parce que son support d'Object Lock est natif et documenté comme prioritaire pour ce cas d'usage. Restic reste un excellent outil de sauvegarde chiffrée, mais son immuabilité repose sur un montage périphérique qu'il faut auditer ligne par ligne, pas sur une garantie posée par le stockage objet lui-même. Et dans tous les cas, l'immuabilité d'un bucket ne remplace pas une stratégie de sauvegarde complète : elle en est une brique. Le référentiel de la règle 3-2-1 et les fondamentaux de restic pour la sauvegarde chiffrée restent le socle sur lequel poser cette couche d'immuabilité, pas un substitut à la réplication géographique ou aux tests de restauration.

Ce qu'on voit chez les audités qui n'ont pas fait ce travail : une politique IAM générique héritée du provisioning initial, un mode gouvernance choisi par défaut parce qu'il ne bloque jamais un run de maintenance, et une conviction que « on a du versioning donc c'est bon ». Un audit de la politique de rétention et des permissions IAM sur le dépôt de sauvegarde prend une demi-journée. Le reconstruire après un chiffrement de production en prend plusieurs semaines.

Ce diagnostic-là, sur la robustesse réelle d'un dépôt de sauvegarde face à un compte compromis, fait partie de ce qu'on regarde en premier lors d'un audit d'infogérance. Si votre politique IAM sur le bucket de sauvegarde n'a jamais été relue depuis sa mise en place, c'est le point à traiter avant d'ajouter une couche de plus : on peut auditer la chaîne de sauvegarde de bout en bout, permissions IAM comprises.

• Locking objects with Object Lock, documentation Amazon S3 : référence officielle sur les modes gouvernance et conformité, la permission s3:BypassGovernanceRetention et les conditions d'activation.
• Object Locking and Immutability, documentation MinIO AIStor : implémentation MinIO des mêmes modes de rétention, avec les commandes mc retention.
• ANSSI-BP-100, Sauvegarde des systèmes d'information, les fondamentaux : guide officiel de l'ANSSI sur les rançongiciels ciblant les infrastructures de sauvegarde et les recommandations de durcissement associées.
• Ransomware Protection, documentation Kopia : support natif d'Object Lock côté kopia, recommandation du mode conformité et exigences de maintenance planifiée.