Un outil de surveillance signale qu'un bucket S3 est public et qu'il contient des exports de données clients. Quelle est votre PREMIÈRE action ?
Réponse courte
Des données clients publiques constituent une exposition active : remédiez d'abord à l'accès en activant Block Public Access et en corrigeant la politique du bucket et la politique IAM pour stopper la fuite en cours. Récupérez ensuite les journaux d'accès (S3 server access logs / événements de données CloudTrail) pour évaluer ce qui a réellement été atteint, puis déclenchez les processus de violation et de notification prévus par la politique. Créer un ticket pour le prochain sprint laisse des données réglementées exposées pendant des jours. Copier les données ailleurs crée une seconde copie mais laisse le bucket d'origine ouvert. Renommer ne change rien à ses permissions.
Un bucket public contenant des données clients est un incident en cours, pas une tâche de backlog. L'examinateur teste si vous savez d'instinct arrêter l'hémorragie avant de l'analyser, et si vous comprenez l'ordre : contenir, puis enquêter, puis notifier.
Pourquoi verrouiller d'abord est la bonne réponse
Chaque minute où le bucket reste public, davantage de données peuvent être énumérées et extraites par n'importe qui — y compris des scanners automatisés qui cherchent en permanence les buckets ouverts. Activer Block Public Access et corriger la politique de bucket ou l'ACL fautive ferme l'exposition en quelques secondes et reste réversible. Ce n'est qu'une fois la fuite refermée que vous évaluez la portée : récupérez les S3 server access logs et les événements de données CloudTrail pour voir quels objets ont été listés ou téléchargés et depuis où. Ces preuves orientent la décision de violation et toute notification réglementaire (par exemple, le délai de 72 heures du RGPD pour les données personnelles).
Pourquoi les autres options sont mauvaises
- Ouvrir un ticket pour le prochain sprint. Cela traite une exposition active de données comme de la maintenance courante. Des données clients réglementées resteraient ouvertes pendant des jours pendant que les attaquants et les scrapers se servent — une erreur de jugement manifeste.
- Copier les données dans un autre bucket et laisser l'ancien public. Cela ne ferme en rien l'exposition ; le bucket d'origine reste lisible par le monde entier. Vous avez en plus créé une seconde copie de données sensibles à sécuriser.
- Renommer le bucket. Les permissions suivent l'objet et la politique, pas le nom. Un bucket renommé mais toujours public est exactement aussi exposé, et les noms de bucket sont de toute façon globaux et découvrables.
Ce que recherchent les examinateurs
La marque d'une bonne réponse est l'enchaînement : contenir, puis évaluer, puis notifier — en nommant le contrôle précis (Block Public Access) et la preuve précise (journaux d'accès / événements de données CloudTrail). Point bonus si vous mentionnez aussi rechercher d'autres buckets publics à l'échelle du compte, car une mauvaise configuration signale généralement un garde-fou manquant plutôt qu'une erreur isolée.
Questions de suivi probables
- Quels journaux vous diraient si les données ont réellement été téléchargées, et quelles sont leurs limites ?
- À partir de quel moment cela devient-il une violation à déclarer au titre du RGPD, et qui en décide ?
- Comment empêcheriez-vous qu'un bucket devienne public à l'échelle de tout le compte ?