SÉCURITÉ CLOUD · IAM · SAAS
Des permissions S3 excessives augmentent le rayon d’impact d’une erreur ou d’un identifiant compromis. Voici une méthode progressive pour réduire les droits sans interrompre les flux applicatifs.
Pars des appels observés et des propriétaires.
Lecture, écriture et suppression ne partagent pas toujours le rôle.
Teste d’abord en staging et observe les refus.
Pourquoi les permissions S3 excessives sont dangereuses
Un bucket S3 privé n’est pas automatiquement protégé contre un rôle IAM trop puissant. Une identité peut encore lire, modifier ou supprimer des données au-delà de son besoin réel.
Une permission large augmente le rayon d’impact d’un token compromis et complique la réponse à incident. Il faut savoir quelles actions sont possibles, sur quelles ressources, depuis quel environnement.
La cible pragmatique est un rôle par flux : dépôt d’objets, lecture de médias, traitement asynchrone, export ou administration exceptionnelle. Chaque rôle doit avoir un propriétaire.
Un rôle qui combine lecture, écriture et suppression sur tous les buckets transforme un token compromis en incident de grande portée.
Application → rôle IAM → policy → préfixe S3
Le contrôle porte sur l’identité, l’action, la ressource et l’environnement.
Inventorier les accès avant de changer
Sépare les accès humains des accès machines. Un développeur en dépannage n’a pas le même besoin qu’un worker qui lit une file d’objets. Les sessions temporaires facilitent la révocation et la traçabilité.
Liste les buckets, préfixes, régions et environnements. Des noms proches entre staging et production favorisent les erreurs de ciblage et rendent les règles difficiles à relire.
Croise CloudTrail, les métriques d’accès et les propriétaires applicatifs. Une absence d’appel est un signal, pas une preuve : confirme toujours les tâches planifiées et les scénarios rares.
Examine lecture, écriture, suppression, changement d’ACL, versions et chiffrement. Les droits de gestion du bucket sont souvent bien plus puissants que ceux nécessaires au service.
IAM Access Analyzer aide à repérer certains accès externes et droits inutilisés. Il complète une revue humaine ; il ne connaît pas seul les contraintes métier ni les fenêtres de maintenance.
aws iam list-roles
aws iam get-role --role-name APP-S3-STAGING
aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=GetObjectConstruire des policies S3 lisibles
Une policy lisible associe une identité, des actions courtes et des ressources précises. Les wildcards doivent être justifiées, documentées et réévaluées.
Pour un service qui dépose des factures, autorise l’écriture dans son préfixe et retire la suppression globale. Un rôle séparé peut gérer une purge contrôlée.
Les rôles par environnement empêchent un secret de staging de viser la production. Ajoute des garde-fous de compte, de région et de tags quand ton architecture le permet.
Avant une modification, définis les erreurs à surveiller : 403, file d’attente qui augmente, latence, échec de job ou absence d’objet attendu.
{
"Version": "2012-10-17",
"Statement": [{"Effect":"Allow","Action":["s3:GetObject"],"Resource":"arn:aws:s3:::app-prod-media/public/*"}]
}Donne la suppression à un rôle distinct, utilisé uniquement par le processus qui en a besoin.
Mini-lab sans risque
Prérequis : compte AWS de test, bucket non critique, rôle de démonstration et identifiants temporaires. N’utilise aucune donnée client ni secret de production.
Crée un préfixe de test et vérifie qu’une policy de lecture seule autorise la lecture mais refuse l’écriture et la suppression.
aws s3api put-object --bucket demo-s3-lab --key app-test/ok.txt --body ./ok.txt
aws s3api get-object --bucket demo-s3-lab --key app-test/ok.txt /tmp/ok.txt
aws s3api delete-object --bucket demo-s3-lab --key app-test/ok.txtRésultat attendu : la lecture réussit, les actions non accordées renvoient une erreur d’autorisation. Vérifie l’événement dans CloudTrail et la ressource ciblée.
Nettoyage : supprime le rôle, le bucket et les objets de test, puis révoque les identifiants temporaires.
Déployer la réduction progressivement
Réduire les droits n’est pas un « grand soir » IAM. Le chemin le plus sûr consiste à isoler un flux, tester son nouveau périmètre, observer, puis seulement passer au suivant.
Associe chaque rôle à un flux, un préfixe, un environnement et un propriétaire. Inclue les workers, exports, purges et tâches planifiées.
Retire une famille de droits à la fois. Teste le chemin nominal, la reprise, la rotation et les scénarios rares avant la production.
Déploie sur un flux limité, puis surveille les 403 répétés, files qui s’allongent, échecs de jobs et objets attendus absents.
Documente le résultat et garde la version précédente prête à restaurer pendant toute la période d’observation.
Limiter le rayon d’impact, sans casser les flux
Commence par distinguer lecture, écriture, suppression et administration. Une application peut parfois lire un objet connu sans devoir lister le bucket entier. Des rôles séparés par usage et par environnement réduisent la visibilité disponible en cas de compromission.
Les préfixes sont utiles quand ils s’accompagnent d’ARN précis, de rôles distincts et de garde-fous de compte. Vérifie aussi l’autorisation effective : une restriction locale peut être contournée par une policy héritée ou un autre rôle.
Traite les applications asynchrones comme des flux à part entière. Un worker historique, une purge mensuelle ou un export de support peuvent expliquer un droit ancien qui n’apparaît pas dans les appels quotidiens.
Observer, tracer, puis décider
Définis avant chaque retrait les signaux utiles et le seuil d’arrêt : refus répétés, action de suppression inhabituelle, région inattendue, échec de traitement ou hausse de la latence. Une alerte sur chaque refus crée du bruit ; privilégie les anomalies actionnables.
Garde la policy précédente versionnée, note le test exécuté, son résultat et la personne qui valide le changement. Sépare dans le compte-rendu les droits nécessaires, les exceptions temporaires et les suppressions décidées. Cette trace rend les audits plus courts et les décisions réversibles.
Conserve la dernière policy fonctionnelle et définis un seuil d’arrêt avant de modifier la production.
Checklist de contrôle
✓ propriétaire documenté · ✓ actions séparées · ✓ ressources limitées · ✓ sessions temporaires · ✓ refus testés en staging · ✓ journalisation et revue activées
Erreurs courantes
Copier une policy trouvée en ligne. Elle ignore tes préfixes et tes flux.
Tester seulement le chemin nominal. Vérifie aussi rotation, purge et reprise.
Supprimer l’ancienne policy immédiatement. Versionne-la et garde une restauration courte.
FAQ
▶ Faut-il supprimer toutes les permissions wildcard ?
▶ Comment savoir si un droit est utilisé ?
▶ Un rôle par application suffit-il ?
▶ Comment éviter une coupure ?
▶ IAM Access Analyzer remplace-t-il une revue ?
Conclusion
Réduire les permissions S3 excessives demande surtout de la visibilité et de la méthode. Relie chaque droit à un flux, une ressource et un propriétaire pour limiter le rayon d’impact tout en conservant la continuité de service.
Linux-Man peut vous aider à auditer rôles, policies et garde-fous de production.
