S3 Bucket Policy
cloudDéfinition
Une S3 Bucket Policy est une politique de ressource attachée directement à un bucket Amazon S3 qui contrôle l'accès à ce bucket et à ses objets. Contrairement aux politiques IAM (attachées aux identités), les Bucket Policies sont attachées à la ressource elle-même et peuvent accorder des accès à des utilisateurs d'autres comptes AWS, à des services AWS, ou même à des accès anonymes (publics) — ce qui en fait un vecteur d'erreur de configuration fréquent. La syntaxe d'une Bucket Policy est identique aux politiques IAM : Effect (Allow/Deny), Principal (qui peut accéder — "*" pour le public), Action (s3:GetObject, s3:PutObject, etc.), Resource (ARN du bucket ou des objets), et Condition (restrictitons optionnelles comme l'IP source, le VPC, le MFA, le chiffrement requis). Les Bucket Policies sont au cœur de nombreuses fuites de données S3 majeures. Une policy accordant Principal: "*" sans conditions suffisantes rend le bucket et ses objets accessibles à n'importe qui sur Internet. La capacité S3 Block Public Access (activable au niveau du compte ou du bucket) prévient cette erreur en bloquant toute politique ou ACL rendant des objets publics, même si la politique tente de l'autoriser. Les usages légitimes des Bucket Policies incluent : partage inter-comptes (accorder l'accès à un compte partenaire pour lire des rapports), intégration de services AWS (permettre à CloudFront de servir des objets depuis S3 via OAC - Origin Access Control), restriction aux connexions depuis un VPC uniquement (condition aws:SourceVpc), exigence du chiffrement en transit (condition aws:SecureTransport: true), et exigence d'un chiffrement spécifique lors de l'upload (s3:x-amz-server-side-encryption). L'analyse automatisée des Bucket Policies est possible via AWS IAM Access Analyzer (détecte les politiques accordant un accès public ou inter-comptes non prévu) et les solutions CSPM qui scannent continuellement les configurations S3.
Erreurs critiques de Bucket Policy
Les erreurs les plus fréquentes : Principal: "*" sans condition de restriction (accès public), manque de condition aws:SecureTransport rendant les données accessibles en HTTP clair, absence de condition s3:x-amz-server-side-encryption laissant les données se stocker non chiffrées, et politiques trop permissives accordant s3:* (incluant PutBucketPolicy et DeleteBucket) à des entités tierces. Réalisez un audit régulier via IAM Access Analyzer.
S3 Block Public Access
Activez S3 Block Public Access au niveau du compte AWS pour toutes les régions : BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy, RestrictPublicBuckets. Cette configuration empêche toute politique ou ACL de rendre des buckets ou objets publics, même si une Bucket Policy mal rédigée tente de le faire. AWS recommande d'activer cette fonctionnalité au niveau de l'organisation via SCP.
Politique de chiffrement obligatoire
Imposez le chiffrement côté serveur via la Bucket Policy : Deny sur PutObject si s3:x-amz-server-side-encryption n'est pas "aws:kms" (chiffrement KMS) ou "AES256" (SSE-S3). Imposez aussi TLS via Deny si aws:SecureTransport est false. Configurez une Default Encryption policy sur le bucket pour que les objets uploadés sans header de chiffrement utilisent automatiquement KMS.
Articles liés
Expert en cybersécurité offensive et intelligence artificielle. Pentest, audit et développement IA sur-mesure.
Services
- Audit Infrastructure
- Audit Kubernetes
- Audit Microsoft 365
- Audit Sécurité Réseau
- Analyse de Risques
- Audit Active Directory
- Audit Application Web
- Audit Cloud (AWS/Azure/GCP)
- Audit Messagerie
- Audit API (OWASP Top 10)
- Audit DevSecOps & CI/CD
- Audit Code Source (SAST)
- Audit Postes de Travail
- Audit Sauvegarde & Résilience
- Audit OT/SCADA (IEC 62443)
- Développement IA
- Formations
Ressources
Projets & Outils
© 2026 Ayi NEDJIMI Consultants. Tous droits réservés.
Un projet cybersécurité ?
Expert dispo · Réponse 24h