Gestion des versions, suppression MFA et réplication

Le versionnage S3 vous permet de conserver, récupérer et restaurer chaque version de chaque objet stocké dans un bucket. Lorsque le versionnage est activé, chaque PUT crée une nouvelle version avec un ID de version unique ; l’ancienne version est conservée et non écrasée. Si un objet est supprimé, S3 ajoute un marqueur de suppression comme version actuelle, mais conserve toutes les versions précédentes. Cela protège contre les écrasements accidentels, les suppressions accidentelles et les corruptions de données involontaires au niveau de l’application, qui sont les scénarios de perte de données les plus courants en production.

Un bucket S3 peut se trouver dans l’un des trois états de versionnage suivants : Non versionné (par défaut, aucun ID de version), Versionnage activé (tous les nouveaux objets reçoivent des ID de version uniques et chaque écrasement crée une nouvelle version) ou Versionnage suspendu (les nouveaux objets reçoivent un ID de version nul, mais les versions existantes sont conservées). Vous ne pouvez pas supprimer le versionnage une fois qu’il est activé, seulement le suspendre. Les objets créés avant l’activation du versionnage ont un ID de version null et ne sont pas concernés tant qu’ils ne sont pas écrasés ou supprimés.

Pour restaurer une ancienne version d’un objet versionné, vous avez deux possibilités. Option 1 : copiez l’ancien ID de version vers la même clé ; cela crée une nouvelle version qui est une copie de l’ancien contenu et la définit comme version actuelle. Option 2 : supprimez la version actuelle ou le marqueur de suppression afin d’exposer la version précédente comme version actuelle. Lorsque vous « supprimez » un objet dans un bucket versionné via la console sans spécifier d’ID de version, S3 ajoute un marqueur de suppression : l’objet paraît supprimé pour les requêtes non versionnées, mais toutes les versions sont toujours présentes.

MFA Delete ajoute une seconde couche de protection aux buckets versionnés. Lorsqu’il est activé, la suppression définitive d’une version spécifique ou la modification de l’état de versionnage du bucket (activé → suspendu) exige de fournir des identifiants MFA valides dans la requête API. Cela protège contre : un attaquant ayant compromis vos identifiants AWS et supprimant définitivement des versions critiques ; la suppression accidentelle ou automatisée de versions d’objets épinglées ; et les menaces internes tentant de détruire les pistes d’audit. MFA Delete ne peut être activé ou désactivé que par l’utilisateur racine via la CLI.

S3 Object Lock applique un modèle d’écriture unique et de lectures multiples (WORM) pour la conformité réglementaire. Les objets verrouillés avec Object Lock ne peuvent pas être supprimés ni écrasés pendant une période de conservation spécifiée, même par l’utilisateur racine du compte. Deux modes existent : le mode Governance (les utilisateurs disposant d’autorisations spéciales peuvent contourner ou supprimer le verrouillage) et le mode Compliance (personne, pas même AWS, ne peut supprimer l’objet pendant la période de conservation : c’est la protection la plus forte). Object Lock doit être activé lors de la création du bucket et nécessite le versionnage.

La Cross-Region Replication (CRR) réplique automatiquement les nouveaux objets et les mises à jour d’un bucket source dans une région vers un bucket de destination situé dans une autre région. Cas d’utilisation : conformité (conserver une copie des données dans un pays spécifique), reprise après sinistre (réduire le RPO des données critiques en maintenant une copie dans une seconde région) et réduction de la latence (diffuser les objets depuis la région la plus proche des utilisateurs). CRR nécessite l’activation du versionnage sur les buckets source et de destination, ainsi qu’un rôle IAM possédant les autorisations de réplication nécessaires.

La Same-Region Replication (SRR) réplique les objets au sein de la même région. Cas d’utilisation : agrégation de journaux (répliquer les journaux de plusieurs buckets sources dans un bucket central), synchronisation d’environnement de test (conserver une copie des données de production dans un bucket de développement de la même région) et conformité à la souveraineté des données dans un même pays disposant de plusieurs zones de disponibilité AWS. Comme CRR, SRR nécessite le versionnage sur les deux buckets et un rôle IAM. Seuls les nouveaux objets créés après l’activation de la réplication sont répliqués automatiquement ; utilisez S3 Batch Replication pour répliquer les objets existants.

La réplication S3 réplique bien les nouveaux objets, les métadonnées, les balises, les ACLs et l’état du chiffrement. Par défaut, la réplication ne réplique pas les objets qui existaient avant son activation (utilisez S3 Batch Replication pour ceux-ci), les marqueurs de suppression (sauf si vous activez Delete Marker Replication), les objets dans Glacier (non réplicables : restaurez-les d’abord) et les objets répliqués (pas de réplication en cascade entre trois buckets). Comprendre ces limites est important pour concevoir des stratégies DR complètes, où les données historiques et les événements de suppression doivent également être répliqués.

Replication Time Control (RTC) est un module complémentaire facultatif pour CRR qui fournit un accord de niveau de service : 99,99 % des objets sont répliqués en 15 minutes, avec des métriques de réplication et des notifications dans CloudWatch. Sans RTC, la réplication ne bénéficie d’aucune garantie de délai : la plupart des objets sont répliqués rapidement, mais certains cas exceptionnels peuvent prendre des heures. RTC est essentiel lorsque vos exigences de DR ou de conformité définissent un objectif de point de récupération (RPO) maximal pour les données dans S3. Il ajoute un coût de réplication par GB, en plus du coût standard de transfert de données de réplication.

L'activation de la gestion des versions augmente les coûts de stockage, car S3 conserve chaque version de chaque objet jusqu'à sa suppression explicite. Un fichier de 100 MB remplacé 10 fois occupe désormais 1 000 MB de stockage. Pour limiter cet impact, utilisez des règles de cycle de vie qui font automatiquement expirer les versions actuelles après un nombre défini de jours (par exemple, supprimer les versions non actuelles datant de plus de 30 jours), ou faites passer les versions non actuelles vers des classes de stockage moins coûteuses telles que Glacier. Associez toujours la gestion des versions à des règles de cycle de vie afin de maîtriser les coûts de stockage en production.

La gestion des versions S3 combinée à Object Lock (mode Compliance) offre une protection solide contre les rançongiciels. Si un attaquant chiffre ou supprime vos objets, la gestion des versions garantit la conservation des versions précédentes (sauf si l'attaquant les supprime définitivement ; c'est pourquoi Object Lock empêche la suppression définitive pendant la période de conservation). Pour une protection maximale : activez la gestion des versions, activez MFA Delete, appliquez Object Lock en mode Compliance aux données critiques et répliquez-les dans une deuxième Region avec des identifiants IAM distincts afin qu'une compromission d'un compte unique ne puisse pas détruire toutes les copies.

Testez votre compréhension des concepts AWS Solutions Architect (SAA-C03) abordés dans cette leçon.

Dans cette leçon, vous avez appris que : la gestion des versions conserve toutes les versions de chaque objet et protège contre les suppressions accidentelles, MFA Delete et Object Lock fournissent une immuabilité supplémentaire pour la conformité et la protection contre les rançongiciels, et CRR et SRR répliquent les objets vers d'autres compartiments afin de répondre aux exigences de DR et de conformité. Nous allons maintenant découvrir les classes de stockage S3 et les politiques de cycle de vie permettant d'optimiser les coûts.