S3 Access Denied : diagnostiquer les erreurs 403 en lecture

Une réponse S3 Access Denied indique qu’une requête a échoué, mais le code 403 ne suffit pas à identifier la cause. Commencez par l’identité, l’opération et l’objet exact. Modifier la bucket policy avant ces vérifications peut laisser le problème intact tout en accordant des droits inutiles.

Ce guide examine les lectures d’objets dans les buckets Amazon S3 à usage général. Il couvre les requêtes CLI signées et précise les différences pour un navigateur ou une URL présignée. Les buckets de répertoire, la configuration des origines CloudFront et les autres services compatibles S3 demandent des contrôles distincts.

Conserver les détails de l’échec avant de modifier les droits

Notez l’heure, le code d’erreur AWS, l’identifiant de requête, l’opération, le bucket, la clé, la région et l’identité. Ajoutez l’identifiant de version si l’application en utilisait un. Excluez des tickets partagés les en-têtes d’autorisation, les jetons de session et les URL présignées complètes. Une clé d’objet peut aussi contenir un nom sensible.

La référence AWS sur les erreurs 403 décrit les messages enrichis pour les requêtes au sein du même compte ou de la même organisation AWS. Le message peut nommer un type de politique et, pour certains refus explicites, son ARN. Il peut ne signaler qu’une cause parmi plusieurs. Les requêtes entre comptes d’organisations différentes, ou les refus d’une politique de point de terminaison VPC, peuvent manquer de détails. Un message générique reste une preuve incomplète.

1. Confirmer l’identité du client en échec

Utilisez la même configuration d’identifiants que la charge de travail concernée. Une lecture réussie depuis votre profil administrateur ne prouve pas que le rôle de l’application peut lire l’objet.

Les exemples emploient un profil CLI existant nommé app-reader, un bucket de démonstration, un petit objet de test non sensible et la région eu-west-1. Remplacez toutes les valeurs, dont le numéro de compte du propriétaire attendu du bucket. Ce propriétaire peut différer de l’appelant entre comptes.

aws sts get-caller-identity --profile app-reader --region eu-west-1

GetCallerIdentity renvoie le compte et l’ARN associés aux identifiants. Comparez-les à la session de rôle prévue. Cette commande ne demande aucun droit de lecture S3 : sa réussite vérifie seulement l’identité. Si la session a expiré ou si le rôle est incorrect, corrigez l’authentification avant les droits de stockage.

2. Vérifier la clé exacte et interpréter HEAD avec précaution

aws s3api head-object --bucket amzn-s3-demo-reports --key reports/sample.txt --expected-bucket-owner 123456789012 --profile app-reader --region eu-west-1

HeadObject lit les métadonnées sans télécharger le contenu. Comparez la clé complète, sa casse et la version éventuelle avec la valeur conservée par l’application. Le contrôle --expected-bucket-owner renvoie 403 si le propriétaire diffère : vérifiez ce numéro de compte avant de conclure à un problème de politique.

Un échec HEAD reste générique, sans le corps d’erreur détaillé d’une réponse GET. Un objet inexistant peut aussi produire 404 ou 403 : selon les règles S3 pour un objet absent, le résultat est 404 avec le droit s3:ListBucket, et 403 sans celui-ci. Un 403 ne prouve donc pas l’existence de la clé.

Si l’application possède déjà le droit de lister ce préfixe, une courte liste peut aider à vérifier l’orthographe :

aws s3api list-objects-v2 --bucket amzn-s3-demo-reports --prefix reports/ --max-keys 5 --no-paginate --expected-bucket-owner 123456789012 --profile app-reader --region eu-west-1

Cette requête ListObjectsV2 renvoie au plus cinq clés sur une seule page. Ce n’est pas un inventaire complet : l’absence d’une clé sur cette page ne permet pas de conclure. Lister demande s3:ListBucket sur le bucket ; lire un objet relève d’un droit distinct. Si la liste est volontairement interdite, demandez à un propriétaire autorisé de confirmer la clé au lieu d’ajouter ce droit pour clarifier l’erreur.

3. Distinguer métadonnées et téléchargement réel

Choisissez un petit objet de test connu et exécutez la commande dans un nouveau dossier local. Elle écrit s3-read-check.txt et peut écraser un fichier existant de ce nom. Des frais AWS de requête, de récupération ou de transfert peuvent s’appliquer.

aws s3api get-object --bucket amzn-s3-demo-reports --key reports/sample.txt --expected-bucket-owner 123456789012 --profile app-reader --region eu-west-1 s3-read-check.txt

La commande GetObject teste la lecture réelle. Comparez le contenu téléchargé au fichier attendu. Gardez le même profil, la même région, le même bucket et la même clé pour pouvoir interpréter les différences.

Observation	Contrôle suivant
La liste fonctionne, le téléchargement échoue	Droit de lecture, clé ou version exacte et contrôles de chiffrement
HEAD fonctionne, GET échoue	Code d’erreur GET, autorisation KMS et éventuel besoin de restauration d’un objet archivé
Un rôle fonctionne, l’autre échoue	Politiques du rôle prévu, restrictions de session et droits sur la ressource
Le même rôle fonctionne sur un seul réseau	Politiques de point de terminaison et conditions réseau, après confirmation que les identifiants sont identiques

Pour un objet SSE-KMS, examinez les droits KMS et la politique de clé en plus de l’accès S3. Un Allow dans la bucket policy ne peut pas accorder l’accès à la clé KMS. La lecture des métadonnées ne prouve pas que l’appelant peut déchiffrer le téléchargement.

Gardez le premier test HEAD simple. La référence de l’API HeadObject précise les droits KMS supplémentaires nécessaires avec le mode checksum. Elle interdit aussi les en-têtes de chiffrement d’un téléversement dans une requête HEAD sur un objet SSE-S3 ou chiffré avec KMS. SSE-C demande des en-têtes de clé client distincts et sort du cadre des exemples.

4. Retrouver le droit applicable à la requête

Pour l’objet courant, examinez s3:GetObject sur l’ARN de l’objet. Une version précise utilise s3:GetObjectVersion. Ne confondez pas ces droits avec celui de lister un bucket. Notre guide des bucket policies détaille les actions, les ressources et les préfixes dans un exemple distinct.

Suivez les règles d’évaluation IAM : un Deny explicite applicable l’emporte sur un Allow. Examinez les politiques d’identité et de ressource, ainsi que les limites d’autorisations, politiques de session ou contrôles d’organisation concernés. Ajouter un Allow ne retire pas un Deny contradictoire.

Pour un accès entre comptes, vérifiez ensemble les droits du compte appelant et ceux du propriétaire de la ressource. Notez le principal, l’action, la ressource et la condition pour que les deux administrateurs examinent la même requête.

Si le réseau intervient, inspectez les contrôles des points de terminaison VPC. Une condition exigeant un point précis peut refuser une requête de portable ou de console passant ailleurs. La politique du point de terminaison peut aussi restreindre les accès. Comparez les chemins avant d’affaiblir une limite réseau voulue.

5. Examiner les causes propres à la requête

• Requester Pays : vérifiez si le bucket exige une acceptation des frais. AWS documente --request-payer requester pour télécharger depuis les buckets Requester Pays. Ajoutez ce paramètre seulement si cette facturation est prévue et autorisée ; ce n’est pas un correctif général aux erreurs 403.
• URL présignée : comparez la méthode HTTP, la clé, les en-têtes signés et la durée des identifiants. Une URL GET n’est pas une URL HEAD. Ne changez pas sa méthode pour l’inspecter rapidement. Notre guide des URL présignées couvre la signature et l’expiration.
• Échec dans le navigateur seulement : inspectez la requête et son contrôle préalable. Modifier CORS n’accorde aucun droit sur l’objet, et une réussite CLI ne valide pas le navigateur. Consultez notre guide S3 CORS pour ce cas.

Appliquer une correction ciblée, puis retester

Choisissez la correction étayée par les vérifications : mauvaise session, clé erronée, propriétaire attendu incorrect, droit ou condition précise. Préservez les autres déclarations de politique. Rendre le bucket public ou accorder s3:* ne constitue pas un diagnostic pour un lecteur privé.

Répétez la requête initiale avec l’identité et le chemin réseau prévus. Testez un objet connu hors du périmètre autorisé si votre modèle d’accès exige un refus. Conservez la cause, la modification relue et les deux résultats. Un téléchargement réussi démontre cette requête, pas la confidentialité de tous les objets.

Les quatre commandes ont été contrôlées localement avec les modèles d’entrée du SDK AWS. Elles n’ont pas été exécutées sur un compte AWS ; aucun résultat réel IAM, KMS, réseau ou d’accès n’est revendiqué. La vérification finale reste la requête de l’application après la correction relue.