Sécurisez vos données Cloud avec les bonnes configurations

Le tandem de la résilience : Versioning et Object Lock

Le Versioning est l’option fondamentale de tout Bucket S3 destiné à la production. Lorsqu’il est activé, S3 ne remplace jamais un Objet lors d’une mise à jour (requête PUT avec la même clé) et ne le détruit pas immédiatement lors d’une suppression (requête DELETE).

À la place, il empile des versions avec un ID unique et appose un « Delete Marker » pour les suppressions. Cela permet de restaurer une donnée écrasée accidentellement.

Cependant, face aux cyberattaques, le versioning seul ne suffit pas : un attaquant avec des droits administrateur peut supprimer toutes les versions. C’est ici qu’intervient l’Object Lock. Basé sur le modèle WORM (Write Once, Read Many), il empêche toute suppression ou modification d’une version d’Objet pendant une durée définie. Il existe deux modes :

• Mode Gouvernance : Protège contre les erreurs humaines. Un administrateur possédant des droits spécifiques (s3:BypassGovernanceRetention) peut lever le verrou.

• Mode Conformité (Compliance) : Une fois activé, personne, pas même le compte racine (Root) d’AWS, ne peut altérer la donnée avant l’expiration du délai. C’est la protection absolue contre les ransomwares et les menaces internes.

Chiffrement (Encryption) : Sécuriser la donnée au repos

Aujourd’hui, chiffrer ses données au repos n’est plus une option, c’est un standard de conformité (RGPD, HIPAA). AWS propose plusieurs niveaux de chiffrement côté serveur (SSE – Server-Side Encryption) :

• SSE-S3 : L’option par défaut. Amazon gère intégralement les clés (génération, rotation, sécurisation). C’est transparent et gratuit, mais vous n’avez aucun contrôle sur les clés.

• SSE-KMS : Utilise le service AWS Key Management Service (KMS). Cette option offre un audit complet (via CloudTrail) de qui a utilisé la clé pour déchiffrer quel fichier. Elle permet également une séparation des privilèges : un utilisateur peut avoir le droit de lire le Bucket S3, mais s’il n’a pas le droit d’utiliser la clé KMS, l’accès lui sera refusé. (Attention aux coûts des requêtes API KMS).

• SSE-C (Customer Keys) : C’est le client qui fournit la clé AES-256 via la requête API. S3 l’utilise pour chiffrer l’Objet en mémoire puis la détruit. AWS ne stocke jamais la clé. Si vous la perdez, la donnée est irrécupérable.

Lifecycle Policies : L’automatisation FinOps

Les règles de cycle de vie (Lifecycle Policies) sont le moteur de votre stratégie FinOps. Elles permettent d’ordonner à S3 d’exécuter des actions sur les Objets selon leur âge ou leur préfixe. Il existe deux types d’actions :

• Actions de transition : Déplacer automatiquement un Objet vers une classe de stockage moins onéreuse après X jours (par exemple, de S3 Standard vers S3 Glacier après 90 jours).

• Actions d’expiration : Supprimer définitivement un Objet (ou purger des anciennes versions et des Delete Markers) après un certain temps. C’est indispensable pour éviter que le Versioning ne fasse exploser votre facture de stockage avec des térabytes de données obsolètes.

Réplication (CRR et SRR) : Redondance géographique

Bien que S3 réplique nativement vos données sur au moins 3 zones de disponibilité (AZ), un Bucket reste attaché à une région spécifique. Pour des besoins de reprise d’activité (PRA/DRP) ou pour réduire la latence d’utilisateurs situés sur un autre continent, vous pouvez configurer la réplication.

• CRR (Cross-Region Replication) : Copie asynchrone des Objets vers un Bucket situé dans une région AWS différente (ex: de Paris vers Tokyo).

• SRR (Same-Region Replication) : Copie les Objets vers un autre Bucket dans la même région (souvent sur un compte AWS différent pour isoler les sauvegardes des environnements de production).

Gestion des accès : Le crépuscule des ACLs

Historiquement, les Access Control Lists (ACLs) étaient la méthode principale pour gérer les droits S3 au niveau du Bucket ou de l’Objet individuel. Aujourd’hui, les ACLs sont considérées comme obsolètes et dangereuses, car elles fragmentent la visibilité des permissions.

Les bonnes pratiques (et AWS par défaut depuis 2023) imposent de désactiver les ACLs via le paramètre Object Ownership (Bucket Owner Enforced). La sécurité doit désormais être gérée par les Bucket Policies (règles JSON appliquées au conteneur) et l’IAM (Identity and Access Management).

Cela centralise la gestion et évite les failles où un Objet uploadé par un tiers reste la propriété de ce dernier.

CORS (Cross-Origin Resource Sharing)

Si votre application frontend (hébergée sur app.mon-site.com) tente d’uploader ou de télécharger un fichier directement depuis/vers votre Bucket (mon-Bucket.s3.amazonaws.com) via le navigateur, ce dernier bloquera la requête par sécurité.

La configuration CORS du Bucket permet de déclarer explicitement quels domaines web ont le droit de dialoguer avec votre S3, via quelles méthodes (GET, PUT, POST) et avec quels headers. C’est indispensable pour les architectures Serverless et les Web Apps modernes.

Audit et Traçabilité : Logging et CloudTrail

Pour des raisons de sécurité, vous devez savoir qui accède à quoi. S3 offre le Server Access Logging, qui dépose des fichiers textes dans un autre Bucket contenant le détail de chaque requête HTTP (IP, User-Agent, Date, Objet).

Pour une intégration plus poussée et orientée « gouvernance », l’activation d’AWS CloudTrail Data Events permet d’enregistrer chaque appel API S3 (GetObject, PutObject) sous forme d’événement analysable en temps réel. C’est la fondation sur laquelle s’appuient les outils de détection de menaces (DSPM/FIM).

Conclusion

Configurer un Bucket S3 ne se limite pas à lui donner un nom. Chaque option (Versioning, KMS, Lifecycle) joue un rôle critique dans un triptyque fondamental : Sécurité, Coût, et Performance. Ignorer ces paramètres, c’est s’exposer à des factures exorbitantes ou, pire, à une compromission de données.

Une gestion proactive de votre posture Cloud est désormais une nécessité vitale, n’hésitez pas à vérifier les configurations recommandés.