Sur Amazon S3, vous pouvez uploader des objets (fichiers), choisir une classe de stockage, définir qui peut accéder au fichier, configurer la suppression automatique, et bien plus encore. La facturation est horaire et vous pouvez supprimer n'importe quel objet à tout moment pour cesser d'en payer le stockage.
AWS a notamment introduit Object Lock — un mécanisme qui empêche la suppression ou l'écrasement d'objets. Son objectif : protéger les données conservées sur le long terme, à des fins de conformité ou d'archivage, contre toute suppression accidentelle ou malveillante.
À la création d'un bucket, vous pouvez choisir un mode de rétention Object Lock, qui détermine la façon dont AWS restreint la suppression des objets :
- Mode Governance — Les objets sont protégés en écriture, mais les utilisateurs disposant de permissions spéciales peuvent contourner ou retirer le verrou.
- Mode Compliance — Les objets sont totalement immuables pendant la période de rétention définie. Personne, pas même l'utilisateur root ni le support AWS, ne peut les supprimer durant cette période.
Dans les deux cas, vous pouvez définir une période de rétention comprise entre 1 jour et 100 ans, comptabilisée individuellement pour chaque objet à partir de son upload sur S3.
Une fois Object Lock activé sur un bucket, vous pouvez définir le mode de verrouillage et la période de rétention de chaque objet au moment de l'upload. À défaut, ce sont les paramètres par défaut qui s'appliquent.
Si vous modifiez ces paramètres par défaut par la suite, ils ne s'appliqueront qu'aux nouveaux objets — les objets existants conserveront la configuration de verrouillage avec laquelle ils ont été uploadés.
Penchons-nous sur le mode Compliance :
Une fois ce mode activé et l'objet uploadé, aucun rôle IAM ni utilisateur — pas même l'utilisateur root — ne peut supprimer les objets avant la fin de la période de rétention. Même le support AWS ne pourra rien y faire.
Vous obtiendrez l'erreur suivante :
Access Denied because object protected by object lock.
Pourquoi vouloir le bloquer ?
Pour limiter les dégâts en cas de compromission d'un compte AWS.
Je m'explique : trois schémas reviennent fréquemment chez les attaquants qui parviennent à accéder à un compte AWS.
- Rançon et destruction : chiffrer les sauvegardes, exiger une rançon et supprimer des ressources pour semer le chaos.
- Minage de cryptomonnaie : lancer des instances GPU coûteuses dans toutes les régions disponibles pour miner de la cryptomonnaie.
- Saignée financière : provisionner des ressources onéreuses comme des instances bare metal et d'énormes volumes EBS, ou acheter des nœuds Redshift Reserved pour faire flamber la facture.
Un stratagème particulièrement vicieux consiste à créer un bucket S3 avec Object Lock en mode Compliance sur une longue durée, puis à y uploader des fichiers volumineux via des instances EC2 zombies, voire du contenu illégal à détenir.
Plus tard, lors d'une revue de coûts ou d'une détection d'anomalie, vous découvrirez peut-être un bucket contenant d'énormes volumes de données impossibles à supprimer, pour un coût de plusieurs milliers, voire dizaines de milliers de dollars par mois, sans aucun moyen de s'en débarrasser.
Comment supprimer un bucket dont les objets sont protégés par le mode Compliance ?
C'est tout simplement impossible.
La seule issue consiste à fermer intégralement le compte AWS avec toutes ses ressources, ce qui est extrêmement contraignant, en particulier pour les environnements de production.
Vous devrez alors migrer l'ensemble de vos workloads vers un nouveau compte AWS — un processus qui peut prendre des semaines, voire des mois, à l'image d'une migration complète d'environnement.
Comment le bloquer ?
Avec les Resource Control Policies (RCP) — une fonctionnalité d'AWS Organizations qui permet d'appliquer des politiques à tous les comptes de votre organisation (à l'exception du compte de gestion), pour des ressources telles que les buckets S3.
Vous pouvez créer une resource policy qui refuse toute tentative d'activation d'Object Lock (malheureusement, il n'est pas possible de la restreindre au seul mode Compliance). Toute tentative d'application déclenchera une erreur Access Denied.
Astuce de pro : vous pouvez également autoriser certains utilisateurs (l'équipe sécurité, par exemple) à contourner la restriction tout en la maintenant pour tous les autres. Vous gardez ainsi le contrôle sans exposer le compte à un risque inutile.
Voici un exemple de RCP qui bloque entièrement l'usage du mode Compliance, aussi bien pour les buckets existants que pour les nouveaux :
J'ai appliqué la politique, créé un nouveau bucket, et au moment d'activer le mode Compliance, j'ai obtenu l'erreur suivante :
Pour conclure :
Si vous voulez sérieusement limiter les dégâts financiers à long terme liés à des erreurs de configuration ou à des accès non autorisés, je vous recommande vivement d'appliquer cette politique.
Notez par ailleurs que le mode Compliance ne se limite pas à S3 — il existe également pour :
- EBS Snapshots — sauvegardes des volumes (disques) EC2
- AWS Backup Vault — service AWS Backup
Selon votre tolérance au risque, il peut être judicieux de les bloquer également.
Découvrez encore plus de ressources utiles sur doit.com/services — votre prochaine étape vers la réussite vous y attend !