L’Object Lock est l’une des fonctionnalités les plus puissantes de MinIO en 2026 pour la protection contre le ransomware et l’erreur humaine. Une fois activé, les objets stockés ne peuvent pas être supprimés ni modifiés pendant la durée de rétention configurée — même par un administrateur compromis. Voici comment l’utiliser correctement.
Voir notre guide MinIO complet.
Pourquoi Object Lock
Scénario classique : un attaquant compromet votre VPS et obtient les credentials root. Il accède à vos backups S3 et les chiffre/supprime. Vous découvrez le ransomware le lundi matin. Sans Object Lock, vous payez la rançon ou vous perdez tout. Avec Object Lock, les backups sont préservés pendant la durée de rétention. Vous restaurez sans payer.
Modes Object Lock
- GOVERNANCE : protection standard. Un user avec permission spécifique peut bypass la rétention. Utile pour erreurs accidentelles.
- COMPLIANCE : protection stricte. Personne (même root) ne peut supprimer avant expiration. Conforme SEC 17a-4. Utile pour anti-ransomware.
Étape 1 — Activer Object Lock à la création du bucket
Important : Object Lock se configure UNIQUEMENT à la création du bucket, pas après.
# Via mc CLI
mc mb prod/backups-immutable --with-lock
# Ou via console web :
# Buckets → Create Bucket → cocher "Object Locking"
Étape 2 — Définir la rétention par défaut
# 30 jours en mode COMPLIANCE (anti-ransomware strict)
mc retention set --default COMPLIANCE 30d prod/backups-immutable
# Ou GOVERNANCE 7j (plus souple, admin peut bypass)
mc retention set --default GOVERNANCE 7d prod/test-bucket
Tout objet uploadé hérite désormais de cette rétention.
Étape 3 — Versioning obligatoire
# Activer le versioning (requis pour Object Lock)
mc version enable prod/backups-immutable
Object Lock requiert le versioning. Une « delete » devient en réalité un marqueur de suppression — l’objet original reste protégé.
Étape 4 — Tester la protection
# Upload un fichier
mc cp test.txt prod/backups-immutable/
# Tenter de supprimer
mc rm prod/backups-immutable/test.txt
# > Error : object protected by retention
# Vérifier la rétention sur l'objet
mc stat prod/backups-immutable/test.txt
# > Retention : COMPLIANCE until ...
Étape 5 — Lifecycle pour expiration auto
Pour ne pas garder éternellement les anciennes versions :
# Expirer les versions non-courantes après 60 jours (post-rétention)
mc ilm rule add --noncurrent-expire-days 60 prod/backups-immutable
Étape 6 — Credentials séparées pour upload-only
Critique : créez un service account avec uniquement s3:PutObject et s3:ListBucket sur le bucket protégé. Pas de delete, pas de bypass. C’est avec ces credentials que vos backups Coolify écrivent. Si elles fuitent, le pire qui peut arriver c’est uploads malveillants — pas suppression.
# Policy JSON IAM-style
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": ["s3:PutObject", "s3:ListBucket"],
"Resource": [
"arn:aws:s3:::backups-immutable",
"arn:aws:s3:::backups-immutable/*"
]
}]
}
Console MinIO → Identity → Service Accounts → Create → coller cette policy.
Étape 7 — Quotas et alertes
Object Lock + versioning peut faire grossir le stockage rapidement. Surveillez :
mc admin info prod
mc du prod/backups-immutable
mc admin bucket quota set prod/backups-immutable --hard 500GiB
Adaptation Afrique de l’Ouest
Pour les PME ouest-africaines, COMPLIANCE Object Lock 30 jours sur les backups Coolify est une assurance vie cyber. Coût marginal négligeable, protection totale contre ransomware. Ne pas oublier de tester la restauration mensuellement.
Erreurs fréquentes
| Erreur | Cause | Solution |
|---|---|---|
| « Object Lock can’t be enabled » | Versioning manquant | mc version enable d’abord |
| « Cannot enable Object Lock on existing » | Bucket déjà créé sans Lock | Créer nouveau bucket avec –with-lock, migrer |
| Disque sature rapidement | Rétention longue + uploads quotidiens | Lifecycle expire-noncurrent-versions |