Advanced S3 Concepts - Part 2
1. Amazon S3 CORS (Cross-Origin Resource Sharing)
Le contexte et le problème
À quoi ça sert ?
CORS est un mécanisme qui permet de dire explicitement au navigateur web : "Hé, j'autorise le site A à venir piocher des ressources dans mon bucket S3".
Ce qu'il faut retenir pour l'examen
-
C’est une politique du navigateur web : Ce n'est pas S3 qui bloque la requête, c'est le navigateur de l'utilisateur qui refuse de charger la ressource parce que S3 n'a pas renvoyé les bons en-têtes d'autorisation.
-
La configuration : Vous écrivez une règle CORS (en JSON) sur le bucket S3 pour lister les origines autorisées (ex:
https://mon-site-web.com), les méthodes (GET, PUT) et les en-têtes.
2. S3 MFA Delete
Le contexte et le problème
Imaginez qu'un employé en colère ou qu'un pirate réussisse à voler les identifiants d'un administrateur. Il pourrait supprimer définitivement des données critiques de l'entreprise en quelques clics.
À quoi ça sert ?
MFA Delete ajoute une double sécurité physique. Même si vous avez les droits d'accès, AWS va vous demander de saisir un code MFA (Multi-Factor Authentication) pour deux actions ultra-critiques.
Ce qu'il faut retenir pour l'examen (Attention aux pièges !)
-
Quand le MFA est-il requis ?
-
Pour supprimer définitivement une version d'un objet.
-
Pour suspendre le versioning du bucket.
-
Le versioning doit être activé : Logique, puisque le MFA Delete sert principalement à protéger les versions des objets. Vous ne pouvez pas activer le MFA Delete si le versioning n'est pas activé.
Le piège de l'examen (Root Account) : Seul le compte racine (Root Account) de la solution AWS peut activer ou désactiver le MFA Delete. Un utilisateur IAM, même avec les droits AdministratorAccess, ne peut pas le faire. (Note : en revanche, pour supprimer l'objet une fois configuré, l'utilisateur IAM peut le faire s'il a les droits ET le token MFA).
3. S3 Access Logs (Journaux d'accès)
Le contexte et le problème
Dans une grande entreprise ou pour des raisons de conformité légale, vous devez être capable de répondre à la question : "Qui a consulté ou modifié ce fichier confidentiel mardi dernier à 14h ?"
À quoi ça sert ?
Les S3 Access Logs enregistrent toutes les requêtes (GET, PUT, DELETE) envoyées à votre bucket. Cela fournit des enregistrements détaillés (IP source, utilisateur, type de requête, date) à des fins d'audit et de sécurité.
Ce qu'il faut retenir pour l'examen
Même région AWS obligatoirement : Le bucket source (celui que vous surveillez) et le bucket cible (celui qui stocke les fichiers de logs) doivent être dans la même région AWS. AWS ne vous laissera pas envoyer des logs S3 d'une région à une autre directement via cette fonctionnalité.
Attention à la boucle de logging (Logging Loop) : C'est le piège classique d'architecture. Si vous dites à votre Bucket-A d'écrire ses logs dans... Bucket-A, chaque écriture de log va générer une nouvelle ligne de log, qui générera une écriture, et ainsi de suite. Votre facture va exploser et le bucket va saturer. Règle d'or : Toujours stocker les logs dans un bucket cible distinct.
4. Pre-signed URLs (URLs pré-signées)
Le contexte et le problème
Vous avez des fichiers privés dans un bucket S3 (par exemple, des vidéos de formation payantes). Vous ne voulez pas rendre le bucket public. Comment permettre à un utilisateur qui a payé de télécharger sa vidéo sans lui créer un compte AWS ?
À quoi ça sert ?
Une URL pré-signée est une URL temporaire générée par vous (via du code) qui donne une autorisation d'accès temporaire à un objet S3 spécifique. Elle contient une clé de sécurité et une date d'expiration (par exemple, valide pendant 15 minutes).
Ce qu'il faut retenir pour l'examen
Héritage des permissions : C'est le point clé. L'URL pré-signée est générée au nom d'un utilisateur IAM ou d'un rôle. L'utilisateur qui reçoit l'URL hérite exactement des permissions de la personne/du rôle qui l'a créée. Si le développeur qui a généré l'URL n'a pas le droit de lire le fichier, l'URL pré-signée ne fonctionnera pas (elle renverra un code 403 Forbidden).
Comment l'utiliser ? Vous avez mentionné la console, le CLI ou le SDK. Précision importante pour le SAA-C03 : dans la vraie vie, on utilise le SDK (dans une fonction Lambda par exemple) pour les générer dynamiquement pour les utilisateurs de votre application. Mais vous pouvez aussi en générer rapidement via l'AWS CLI (pour tester) ou depuis la Console S3 (via l'option "Partager avec une URL pré-signée").