Bucket policy S3 : exemples, droits IAM et tests d'accès

Une bucket policy S3 est un document JSON associé à un compartiment Amazon S3. Elle précise qui peut effectuer quelles opérations sur le compartiment ou ses objets, avec des conditions facultatives. Pour donner à une application accès à un préfixe de rapports, distinguez le droit de lister les noms des objets du droit de lire leur contenu.

Ce guide compare les politiques de compartiment aux politiques IAM liées aux identités, présente un exemple de lecture ciblée et détaille la validation et les tests d'accès. Il concerne les compartiments Amazon S3 à usage général. Les autres types de compartiments et les services compatibles avec S3 peuvent appliquer des règles d'autorisation différentes.

Bucket policy ou politique IAM : où se trouve l'autorisation ?

Une politique de compartiment est liée à une ressource : elle est associée au compartiment et comporte un élément Principal qui désigne le bénéficiaire d'une autorisation. Une politique IAM liée à une identité est associée à un utilisateur, un groupe ou un rôle. Ses instructions décrivent les droits de cette identité et ne comportent donc pas d'élément Principal.

Pour une requête au sein du même compte, une autorisation Allow applicable peut provenir d'une politique d'identité ou de ressource. Ajouter un Allow limité dans la politique du compartiment ne supprime pas une autorisation plus large accordée ailleurs. Un Deny explicite ou d'autres contrôles applicables peuvent encore bloquer l'accès. AWS décrit ces interactions dans sa logique d'évaluation des politiques.

L'accès entre comptes ajoute une exigence : le compte propriétaire de la ressource doit autoriser l'accès, et le compte de l'identité demandeuse doit autoriser les opérations concernées. Vérifiez les deux côtés, ainsi que la relation d'approbation du rôle et les restrictions de session. Une politique de compartiment ne permet pas, à elle seule, d'endosser un rôle.

Si vous hésitez encore entre stockage objet, bloc et fichier, consultez notre guide du stockage cloud Amazon. Les exemples ci-dessous concernent l'accès aux objets S3.

Comprendre les éléments avant de copier une politique

• Version : la version du langage de politique. La valeur 2012-10-17 n'est pas la date de rédaction du document.
• Statement : une ou plusieurs instructions d'autorisation. Sid est un identifiant facultatif qui facilite leur examen.
• Effect : Allow ou Deny.
• Principal : le rôle, le compte, le service ou l'autre principal concerné par une instruction liée à une ressource.
• Action : l'autorisation évaluée, par exemple s3:ListBucket ou s3:GetObject.
• Resource : l'Amazon Resource Name, ou ARN, du compartiment ou des objets.
• Condition : un critère supplémentaire, par exemple un préfixe obligatoire dans une requête de listage.

L'ARN d'un compartiment s'arrête au nom de celui-ci. L'ARN d'un objet se prolonge par une clé ou un motif. Associer une opération sur un objet au seul ARN du compartiment est une erreur fréquente. La référence des éléments de politique AWS explique la distinction entre actions et ressources.

Exemple : permettre à un rôle de lister et lire un préfixe

Supposons qu'un rôle applicatif ReportReader doive lister et télécharger les objets courants sous reports/. Il n'a pas besoin d'envoyer des fichiers, de supprimer des objets, de modifier les politiques ni de récupérer des versions historiques précises. L'exemple suivant accorde ces droits limités.

Remplacez le numéro de compte, l'ARN du rôle et le nom du compartiment par vos valeurs. Le rôle doit exister. Commencez avec un compartiment de test distinct contenant des fichiers sans données sensibles et gardez Block Public Access activé. Enregistrez le document adapté sous bucket-policy.json.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListReportPrefix",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:role/ReportReader"
      },
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::amzn-s3-demo-reports",
      "Condition": {
        "StringLike": {
          "s3:prefix": "reports/*"
        }
      }
    },
    {
      "Sid": "ReadReportObjects",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:role/ReportReader"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::amzn-s3-demo-reports/reports/*"
    }
  ]
}

La première instruction autorise les requêtes ListObjectsV2 au moyen de s3:ListBucket sur l'ARN du compartiment. Sa condition StringLike exige un préfixe de requête correspondant à reports/*. La seconde autorise s3:GetObject pour les clés d'objet commençant par reports/.

Ces contrôles sont distincts. Une condition de listage ne limite pas GetObject à elle seule. Ici, c'est l'ARN des objets qui délimite cette autorisation. Les préfixes S3 font partie des clés d'objet : leur affichage sous forme de dossiers dans la console ne crée pas de séparation des droits. Les exemples AWS de conditions sur les préfixes détaillent ce fonctionnement.

L'exemple n'accorde ni s3:GetObjectVersion ni s3:ListBucketVersions. Demander une version précise nécessite l'autorisation correspondante ; n'ajoutez cet accès que si l'application en a besoin. Consultez les règles d'autorisation de GetObject.

Un Allow limité ne définit pas tous les droits effectifs

Cet exemple ajoute un accès à reports/. Il ne prouve pas que ReportReader ne peut pas accéder à finance/, car une autre politique pourrait déjà l'y autoriser. Examinez les politiques d'identité du rôle, les politiques du compartiment et des points d'accès, les paramètres de session et les contrôles d'organisation ou de point de terminaison applicables.

Si vous devez imposer une restriction, concevez et examinez l'ensemble des autorisations. Un Deny explicitement ciblé peut prévaloir sur un autre Allow, mais un Deny trop large peut aussi bloquer les administrateurs ou les services. Définissez le principal, l'action, la ressource et l'exception souhaités avant de l'ajouter. Ne transformez pas une autorisation applicative ciblée en modèle de refus global.

De même, l'absence de PutObject ou DeleteObject signifie que ce document n'accorde pas ces actions. Elle ne prouve pas que le rôle en est privé dans toutes les autres politiques.

Distinguer accès public et propriété des objets

Un rôle précis peut recevoir un accès privé alors que Block Public Access reste activé. Ne désactivez pas cette protection simplement parce qu'une requête renvoie AccessDenied. Un Allow public avec un principal générique peut exposer les données ou être rejeté par les contrôles d'accès public. Le même caractère générique dans un Deny a un autre effet : examinez l'instruction entière.

S3 Block Public Access tient compte des paramètres applicables au compartiment, au compte, au point d'accès et à l'organisation. Modifier un seul paramètre du compartiment ne change pas nécessairement le résultat effectif.

Vérifiez aussi Object Ownership. Les nouveaux compartiments utilisent par défaut Bucket owner enforced, avec les ACL désactivées. Les compartiments plus anciens peuvent avoir d'autres paramètres de propriété et d'ACL. Vérifiez la configuration réelle.

Valider la politique proposée avant de l'appliquer

Conservez une copie de la politique existante et préparez un remplacement relu. Enregistrer une nouvelle politique remplace le document actuel : préservez les instructions sans rapport avec votre changement dont les applications ou les administrateurs ont encore besoin.

Avec un profil de révision autorisé et AWS CLI v2 configuré, vous pouvez demander une validation de politique par IAM Access Analyzer :

aws accessanalyzer validate-policy --policy-document file://bucket-policy.json --policy-type RESOURCE_POLICY --validate-policy-resource-type AWS::S3::Bucket --region us-east-1 --profile policy-review

Cette commande envoie le document local à AWS pour validation ; elle ne l'associe pas au compartiment. Le profil et la région sont des exemples. Examinez chaque résultat et corrigez les erreurs et avertissements de sécurité pertinents. Un JSON valide ou une liste de résultats vide ne prouve ni le bon fonctionnement de l'application ni le blocage de toutes les requêtes indésirables.

Appliquez le document relu au compartiment de test en suivant votre procédure de changement autorisée. La structure JSON de cet exemple et l'emploi documenté des actions et ressources ont été vérifiés localement. L'exemple n'a pas été déployé dans un compte AWS.

Tester les requêtes autorisées et refusées avec la bonne identité

Utilisez un rôle de test dédié sans autres autorisations S3. Demandez à un administrateur de placer des fichiers connus aux clés reports/sample.txt et finance/sample.txt, puis confirmez leur existence. Le profil reports-reader doit endosser ce rôle. Le Principal de la politique reste l'ARN du rôle IAM, même si l'identité de l'appelant affiche l'ARN d'une session de rôle endossé.

Confirmez d'abord l'identité et testez la lecture prévue :

aws sts get-caller-identity --profile reports-reader
aws s3api list-objects-v2 --bucket amzn-s3-demo-reports --prefix reports/ --max-keys 5 --no-paginate --profile reports-reader
aws s3api get-object --bucket amzn-s3-demo-reports --key reports/sample.txt --profile reports-reader report-download.txt

Le listage doit réussir et le rapport téléchargé doit correspondre au fichier de test. Cela suppose que la politique est installée et qu'aucun autre contrôle ne bloque la requête. Utilisez un nouveau répertoire local pour éviter d'écraser un fichier utile lors du téléchargement.

Vérifiez ensuite l'autre préfixe et l'accès anonyme :

aws s3api list-objects-v2 --bucket amzn-s3-demo-reports --prefix finance/ --max-keys 5 --no-paginate --profile reports-reader
aws s3api get-object --bucket amzn-s3-demo-reports --key finance/sample.txt --profile reports-reader finance-download.txt
aws s3api get-object --bucket amzn-s3-demo-reports --key reports/sample.txt --no-sign-request anonymous-download.txt

Les trois requêtes doivent être refusées dans cet environnement contrôlé. Si l'autre préfixe est lisible, recherchez d'autres autorisations au lieu de supposer que cet Allow imposait une restriction. Si la requête anonyme réussit, examinez immédiatement la configuration d'accès public. Un échec dû à une session expirée, à un mauvais compartiment ou à un objet absent ne valide pas le contrôle des droits.

Conservez l'identité de l'appelant, l'action et la clé demandées, la réponse et la version de la politique dans le compte rendu du test. Si l'application doit aussi écrire, ajoutez et testez cette exigence séparément avec des objets jetables. N'élargissez pas la politique à s3:* pour simplement faire réussir un test.

Diagnostiquer AccessDenied sans élargir les droits au hasard

Partez de la requête qui échoue et vérifiez les points suivants :

1. Le compte, la session de rôle, le compartiment, la clé d'objet et l'opération demandée.
2. La correspondance entre l'action et l'ARN de la ressource. Un listage et un téléchargement exigent des droits distincts.
3. Les conditions, notamment le préfixe exact et les restrictions réseau ou de transport.
4. Les Deny explicites et les restrictions venant d'une limite d'autorisations, d'une politique de session ou d'organisation, d'un point d'accès ou d'un point de terminaison VPC.
5. Les autorisations des deux comptes pour une requête entre comptes.
6. Les droits sur la clé KMS, en plus des droits S3, pour un objet chiffré avec KMS.

Lire un objet SSE-KMS nécessite l'autorisation KMS appropriée, notamment kms:Decrypt. Une politique de compartiment ne peut pas accorder de droits sur une clé KMS. Le guide AWS des erreurs 403 détaille les autres contrôles susceptibles de refuser une requête.

Pour une application Web, la configuration CORS constitue une vérification distincte. Une règle CORS ne remplace pas les autorisations IAM ou du compartiment. Notre guide du stockage pour applications replace ces droits dans la conception des transferts et de la récupération des données.

Garder des changements faciles à examiner

Conservez la politique relue et ses cas de test avec la configuration de l'application. Répétez les tests de refus lorsque vous ajoutez un rôle, un préfixe, un point d'accès ou un compte externe. Un téléchargement réussi valide un accès autorisé ; il ne détermine pas qui d'autre peut lire le compartiment.

Enfin, distinguez contrôle d'accès et conservation. Un refus dans la politique du compartiment n'empêche pas une règle S3 Lifecycle d'expirer ou de transférer des objets vers une autre classe de stockage. AWS le précise dans sa documentation des politiques de compartiment. Examinez les paramètres de conservation, de versioning et de récupération avec les droits lorsque les données doivent rester récupérables.