Quelles sont les mauvaises configurations S3 courantes et comment les éviter ?
Réponse courte
Les erreurs classiques sont des ACL publiques ou des politiques de bucket autorisant un accès anonyme ou à tous les utilisateurs AWS, des principaux trop larges ou des actions avec wildcard, l'absence de chiffrement par défaut et l'absence de journalisation. On les évite en activant le Block Public Access au niveau du compte, en utilisant des politiques IAM/bucket selon le moindre privilège, en imposant le chiffrement par défaut et TLS, et en activant la journalisation des accès et des règles Config pour détecter les dérives.
La mauvaise configuration de S3 est la fuite cloud type, car le stockage objet est facile à rendre public et les conséquences — des millions d'enregistrements exposés — sont graves. L'entretien cherche à savoir si vous comprenez pourquoi ces fuites se reproduisent et comment rendre l'exposition structurellement difficile.
Les erreurs courantes
- ACL / politiques de bucket publiques. Accorder l'accès en lecture à
AllUsers(n'importe qui sur Internet) ouAuthenticatedUsers(n'importe quel compte AWS, pas seulement le vôtre — un piège fréquent). - Principaux ou actions avec wildcard. Une politique avec
"Principal": "*"ou"Action": "s3:*"est bien plus large que prévu. - Aucun chiffrement par défaut et aucune exigence que les requêtes utilisent TLS, si bien que les objets peuvent être lus ou écrits en clair.
- Aucune journalisation des accès ni CloudTrail au niveau objet, si bien qu'une fuite passe inaperçue et est difficile à investiguer.
Comment les éviter
- Block Public Access au niveau du compte. Cela prévaut sur les réglages individuels des buckets et constitue le contrôle à plus forte valeur — il rend « accidentellement public » quasiment impossible.
- Politiques de moindre privilège. Nommez des principaux précis, restreignez les actions et préférez les rôles IAM aux politiques de bucket trop larges.
- Imposez le chiffrement et TLS. Activez le chiffrement par défaut et ajoutez une condition de politique refusant les requêtes où
aws:SecureTransportest false. - Détectez les dérives. Utilisez des règles Config ou un outil CSPM pour signaler en continu tout bucket devenant public ou perdant son chiffrement.
L'idée clé : le chiffrement au repos n'empêche pas une lecture anonyme si la politique l'autorise — le service déchiffre de manière transparente pour une requête autorisée, et une politique publique rend le monde entier « autorisé ».
Ce que recherchent les recruteurs
Citer Block Public Access en premier, distinguer AllUsers de AuthenticatedUsers, et savoir que la détection et la prévention comptent toutes les deux.
Questions de suivi probables
- Que bloque réellement S3 Block Public Access, et à quels niveaux ?
- Comment détecteriez-vous un bucket lisible publiquement à travers des centaines de comptes ?
- Pourquoi le chiffrement au repos n'aide-t-il pas si la politique du bucket autorise les lectures anonymes ?