02. S3 Security
Par défaut, quand tu crées un bucket S3, tout est fermé. Personne n'a accès à rien, sauf le créateur du compte.
1. Les deux outils pour ouvrir l'accès
Pour donner une permission, tu choisis l'une de ces deux méthodes (ou les deux) :
Method A : La méthode "Utilisateur" (IAM Policy)
-
C'est quoi ? Une feuille de permission que tu donnes à un utilisateur ou un rôle précis.
-
Logique : Tu dis à l'utilisateur : "Toi, tu as le droit d'aller lire le bucket X."
Method B : La méthode "Bucket" (Bucket Policy)
-
C'est quoi ? Une feuille de permission collée directement sur le bucket.
-
Logique : Le bucket dit : "J'autorise telle personne ou tel compte externe à venir chez moi."
2. Comment S3 prend sa décision ?
Quand quelqu'un clique sur un fichier dans S3, AWS vérifie les permissions dans cet ordre :
- Y a-t-il une interdiction (
Deny) ? Si une règle dit "Interdit", c'est fini. L'accès est bloqué immédiatement, même si une autre règle disait oui. - Y a-t-il une autorisation (
Allow) ? S'il n'y a pas deDeny, il faut au moins unAllow(soit sur l'utilisateur, soit sur le bucket) pour que ça passe.
3. Trois cas particuliers pour l'examen
Scénario 1 : Bloquer les fuites de données sur Internet
-
Le besoin : Tu veux une sécurité absolue pour qu'aucun employé ne puisse rendre le bucket public par erreur.
-
La solution : Block Public Access (BPA). C'est un gros bouton de sécurité activé par défaut qui bloque tout Internet.
Scénario 2 : Partager un fichier privé avec un client externe
-
Le besoin : Un client (qui n'a pas de compte AWS) doit télécharger une facture privée ou uploader sa photo.
-
La solution : Presigned URL (URL Présignée). Tu lui génères un lien magique, sécurisé et temporaire (valable 15 minutes par exemple).
Scénario 3 : Connecter tes serveurs privés à S3
-
Le besoin : Tes serveurs AWS sont isolés du monde (pas d'Internet). Ils ont pourtant besoin de parler à S3.
-
La solution : VPC Gateway Endpoint. Un tunnel privé qui relie tes serveurs à S3 sans jamais passer par Internet.