Résolution des erreurs d’accès refusé (403 Forbidden) dans Amazon S3 - Amazon Simple Storage Service
Exemples de messages de refus d’accès et étapes à suivre pour les résoudreAccès refusé en raison des paramètres Paiement par le demandeurStratégies de compartiment et politiques IAMParamètres des listes de contrôle d’accès d’Amazon S3Paramètres de blocage de l’accès public S3Paramètres du chiffrement Amazon S3Paramètres de verrouillage des objets S3Politiques de point de terminaison d’un VPCPolitiques AWS OrganizationsAccès aux distributions CloudFrontParamètres du point d’accèsRessources supplémentaires

Résolution des erreurs d’accès refusé (403 Forbidden) dans Amazon S3

Les erreurs d’accès refusé (HTTP 403 Forbidden) s’affichent lorsque AWS refuse explicitement ou implicitement une demande d’autorisation.

  • Un refus explicite se produit lorsqu’une politique contient une déclaration Deny pour l’action spécifique de AWS.

  • Un refus implicite se produit lorsqu’il n’y a ni d’instruction Deny applicable ni d’instruction Allow applicable.

Comme une politique AWS Identity and Access Management (IAM) refuse un principal IAM par défaut, elle doit autoriser explicitement le principal à effectuer une action. Dans le cas contraire, la politique refuse implicitement l’accès. Pour plus d’informations, consultez Différence entre les refus explicites et implicites dans le Guide de l’utilisateur IAM. Pour plus d’informations sur la logique d’évaluation des politiques qui détermine si une demande d’accès est autorisée ou refusée, consultez Logique d’évaluation des politiques dans le Guide de l’utilisateur d’IAM.

Pour plus d’informations sur les autorisations relatives aux opérations d’API S3 par type de ressource S3, consultez Autorisations requises pour les opérations d’API Amazon S3.

Les rubriques suivantes décrivent les causes les plus courantes des erreurs d’accès refusé dans Amazon S3.

Note

En cas d’erreur (HTTP 403 Forbidden) liée à un accès refusé, Amazon S3 ne facture pas le propriétaire du compartiment lorsque la demande est initiée en dehors du compte AWS individuel du propriétaire du compartiment ou de l’organisation AWS du propriétaire du compartiment.

Note

Si vous essayez de résoudre un problème d’autorisation, commencez par la section Exemples de messages de refus d’accès et étapes à suivre pour les résoudre, puis passez à la section Stratégies de compartiment et politiques IAM. Assurez-vous également de suivre les instructions figurant dansConseils pour vérifier les autorisations.

Exemples de messages de refus d’accès et étapes à suivre pour les résoudre

Amazon S3 inclut désormais un contexte supplémentaire dans les messages de refus d’accès (HTTP 403 Forbidden) des demandes adressées aux ressources du même Compte AWS ou de la même organisation dans AWS Organizations. Ce nouveau contexte inclut le type de politique qui a refusé l’accès, le motif du refus et les informations sur l’utilisateur ou le rôle IAM qui a demandé l’accès à la ressource.

Ce contexte supplémentaire vous aide à résoudre les problèmes d’accès, à identifier la cause première des erreurs de refus d’accès et à corriger les contrôles d’accès incorrects en mettant à jour les politiques pertinentes. Ce contexte supplémentaire est également disponible dans les journaux AWS CloudTrail. Les messages d’erreur de refus d’accès améliorés pour les demandes portant sur le même compte ou la même organisation sont désormais disponibles dans toutes les Régions AWS, y compris la AWS GovCloud (US) Regions et la région Chine.

La plupart des messages d’erreur d’accès refusé se présentent sous le format User user-arn is not authorized to perform action on "resource-arn" because context. Dans cet exemple, user-arn est l’Amazon Resource Name (ARN) de l’utilisateur qui ne dispose pas d’un accès, action est l’action de service refusée par la stratégie, et resource-arn est l’ARN de la ressource sur laquelle la stratégie agit. Le champ context représente un contexte supplémentaire sur le type de politique, qui explique pourquoi l’accès est refusé.

Lorsqu’une politique refuse explicitement l’accès parce qu’elle contient une instruction Deny, le message d’erreur de refus d’accès inclut l’expression with an explicit deny in a type policy. Lorsque l’accès est implicitement refusé, le message d’erreur de refus d’accès inclut l’expression because no type policy allows the action action.

Important

  • Les messages de refus d’accès améliorés ne sont renvoyés que pour les demandes portant sur le même compte ou la même organisation dans AWS Organizations. Les demandes intercomptes en dehors de la même organisation renvoient un message Access Denied générique.

    Pour plus d’informations sur la logique d’évaluation des politiques qui détermine si une demande d’accès intercompte est autorisée ou refusée, consultez Logique d’évaluation des politiques entre comptes dans le Guide de l’utilisateur IAM. Pour voir une procédure détaillée qui décrit comment accorder l’accès intercompte, consultez Exemple 2 : propriétaire d’un compartiment accordant à ses utilisateurs des autorisations entre comptes sur un compartiment.

  • Pour les demandes au sein de la même organisation dans AWS Organizations :

    • Les messages de refus d’accès améliorés ne sont pas renvoyés si un refus survient en raison d’une politique de point de terminaison de cloud privé virtuel (VPC).

    • Des messages de refus d’accès améliorés sont fournis chaque fois que le propriétaire du compartiment et le compte de l’appelant appartiennent à la même organisation dans AWS Organizations. Bien que les compartiments configurés selon le paramètre Propriétaire du compartiment préféré ou Créateur de l’objet de S3 puissent contenir des objets appartenant à des comptes différents, le propriétaire de l’objet n’a aucune incidence sur les messages de refus d’accès améliorés. Des messages de refus d’accès améliorés sont renvoyés pour toutes les demandes d’objet tant que le propriétaire du compartiment et l’appelant appartiennent à la même organisation, quel que soit le propriétaire de l’objet en question. Pour plus d’informations sur les configurations et les paramètres Propriétaire de l’objet, consultez Consultez Contrôle de la propriété des objets et désactivation des listes ACL pour votre compartiment.

  • Les messages d’erreur de refus d’accès améliorés ne sont pas renvoyés pour les demandes adressées aux compartiments de répertoires. Les demandes de compartiment de répertoires renvoient un message Access Denied générique.

  • Si plusieurs politiques de même type refusent une demande d’autorisation, le message d’erreur de refus d’accès ne spécifie pas le nombre de politiques.

  • Si une demande d’autorisation est refusée en raison de plusieurs types de politiques, le message d’erreur n’inclut qu’un seul de ces types de politiques.

  • Si une demande d’accès est refusée pour plusieurs raisons, le message d’erreur ne comprend qu’une seule des raisons du refus.

Les exemples suivants montrent le format de différents types de messages d’erreur de refus d’accès et indiquent comment résoudre les erreurs liées à chaque type de message.

Accès refusé en raison d’une politique de contrôle des ressources : refus explicite

  1. Vérifiez la présence d’une instruction Deny pour l’action dans vos politiques de contrôle des ressources (RCP). Pour l’exemple suivant, l’action est s3:GetObject.

  2. Mettez à jour votre politique de contrôle des ressources en supprimant l’instruction Deny. Pour plus d’informations, consultez Mise à jour d’une politique de contrôle des ressources dans le Guide de l’utilisateur AWS Organizations. 

An error occurred (AccessDenied) when calling the GetObject operation: 
User: arn:aws:iam::777788889999:user/MaryMajor is not authorized to perform: 
s3:GetObject on resource: "arn:aws:s3:::amzn-s3-demo-bucket1/object-name" 
with an explicit deny in a resource control policy

Accès refusé en raison d’une politique de contrôle des services - refus implicite

  1. Vérifiez la présence d’une instruction Allow manquante pour l’action dans vos politiques de contrôle des services (SCP). Pour l’exemple suivant, l’action est s3:GetObject.

  2. Mettez à jour votre SCP en ajoutant l’instruction Allow. Pour plus d’information, consultez Mise à jour d’une stratégie de contrôle de service (SCP) dans le Guide de l’utilisateur AWS Organizations.

User: arn:aws:iam::777788889999:user/MaryMajor is not authorized to perform:
s3:GetObject because no service control policy allows the s3:GetObject action

Accès refusé en raison d’une politique de contrôle des services - refus explicite

  1. Vérifiez la présence d’une instruction Deny pour l’action dans vos politiques de contrôle des services (SCP). Pour l’exemple suivant, l’action est s3:GetObject.

  2. Mettez à jour votre politique de contrôle des services en modifiant l’instruction Deny pour accorder à l’utilisateur l’accès nécessaire. Pour obtenir un exemple de la marche à suivre, consultez Empêcher les utilisateurs et les rôles IAM d’apporter des modifications spécifiées, à l’exception d’un rôle administrateur spécifié dans le Guide de l’utilisateur AWS Organizations. Pour plus d’informations sur la mise à jour de votre politique de contrôle des services, consultez Mise à jour d’une politique de contrôle des services (SCP) dans le Guide de l’utilisateur AWS Organizations.

User: arn:aws:iam::777788889999:user/MaryMajor is not authorized to perform: 
s3:GetObject with an explicit deny in a service control policy

Accès refusé en raison d’une politique de point de terminaison d’un VPC : refus implicite

  1. Vérifiez l’absence d’une instruction Allow pour l’action dans les politiques de votre point de terminaison de cloud privé virtuel (VPC). Pour l’exemple suivant, l’action est s3:GetObject.

  2. Mettez à jour la politique de point de terminaison d’un VPC en ajoutant l’instruction Allow. Pour plus d’informations, consultez la rubrique Mise à jour d’une politique de point de terminaison d’un VPC dans le Guide AWS PrivateLink.

User: arn:aws:iam::123456789012:user/MaryMajor is not authorized to perform: 
s3:GetObject because no VPC endpoint policy allows the s3:GetObject action

Accès refusé en raison d’une politique de point de terminaison d’un VPC : refus explicite

  1. Vérifiez la présence d’une instruction Deny explicite pour l’action dans les politiques de votre point de terminaison de cloud privé virtuel (VPC). Pour l’exemple suivant, l’action est s3:GetObject.

  2. Mettez à jour la politique de point de terminaison de votre VPC en modifiant l’instruction Deny pour accorder à l’utilisateur l’accès nécessaire. Par exemple, vous pouvez mettre à jour l’instruction Deny pour utiliser la clé de condition aws:PrincipalAccount avec l’opérateur de condition StringNotEquals afin d’autoriser l’accès spécifique du principal, comme indiqué dans Exemple 7 : Exclure certains principaux d’une instruction Deny. Pour plus d’informations sur la mise à jour de la politique de point de terminaison de votre VPC, consultez Mise à jour d’une politique de point de terminaison d’un VPC dans le Guide AWS PrivateLink.

User: arn:aws:iam::123456789012:user/MaryMajor is not authorized to perform: 
s3:GetObject on resource: "arn:aws:s3:::amzn-s3-demo-bucket1/object-name" with 
an explicit deny in a VPC endpoint policy

Accès refusé en raison d’une limite des autorisations : refus implicite

  1. Vérifiez l’absence d’une instruction Allow pour l’action dans votre limite des autorisations. Pour l’exemple suivant, l’action est s3:GetObject.

  2. Mettez à jour votre limite des autorisations en ajoutant l’instruction Allow à votre politique IAM. Pour plus d’informations, consultez Limites d’autorisations pour les entités IAM et Modification des politiques IAM dans le Guide de l’utilisateur IAM.

User: arn:aws:iam::123456789012:user/MaryMajor is not authorized to perform: 
s3:GetObject on resource: "arn:aws:s3:::amzn-s3-demo-bucket1/object-name" 
because no permissions boundary allows the s3:GetObject action

Accès refusé en raison d’une limite des autorisations : refus explicite

  1. Vérifiez la présence d’une instruction Deny explicite pour l’action dans votre limite des autorisations. Pour l’exemple suivant, l’action est s3:GetObject.

  2. Mettez à jour votre limite d’autorisations en modifiant l’instruction Deny dans votre politique IAM pour accorder à l’utilisateur l’accès nécessaire. Par exemple, vous pouvez mettre à jour l’instruction Deny pour utiliser la clé de condition aws:PrincipalAccount avec l’opérateur de condition StringNotEquals afin d’autoriser l’accès spécifique du principal, comme indiqué dans aws:PrincipalAccount dans le Guide de l’utilisateur IAM. Pour plus d’informations, consultez Limites d’autorisations pour les entités IAM et Modification des politiques IAM dans le Guide de l’utilisateur IAM.

User: arn:aws:iam::777788889999:user/MaryMajor is not authorized to perform: 
s3:GetObject with an explicit deny in a permissions boundary

Accès refusé en raison de politiques de session : refus implicite

  1. Vérifiez l’absence d’une instruction Allow pour l’action dans vos politiques de session. Pour l’exemple suivant, l’action est s3:GetObject.

  2. Mettez à jour votre politique de session en ajoutant l’instruction Allow. Pour plus d’informations, consultez Politiques de session et Modification des politiques IAM dans le Guide de l’utilisateur IAM.

User: arn:aws:iam::123456789012:user/MaryMajor is not authorized to perform: 
s3:GetObject because no session policy allows the s3:GetObject action

Accès refusé en raison de politiques de session : refus explicite

  1. Vérifiez la présence d’une instruction Deny explicite pour l’action dans vos politiques de session. Pour l’exemple suivant, l’action est s3:GetObject.

  2. Mettez à jour la politique de session en modifiant l’instruction Deny pour accorder à l’utilisateur l’accès nécessaire. Par exemple, vous pouvez mettre à jour l’instruction Deny pour utiliser la clé de condition aws:PrincipalAccount avec l’opérateur de condition StringNotEquals afin d’autoriser l’accès spécifique du principal, comme indiqué dans Exemple 7 : Exclure certains principaux d’une instruction Deny. Pour plus d’informations sur la mise à jour de votre politique de session, consultez Politiques de session et Modification des politiques IAM dans le Guide de l’utilisateur IAM.

User: arn:aws:iam::123456789012:user/MaryMajor is not authorized to perform: 
s3:GetObject on resource: "arn:aws:s3:::amzn-s3-demo-bucket1/object-name" with 
an explicit deny in a session policy

Accès refusé en raison de politiques basées sur les ressources : refus implicite

Note

Les politiques basées sur les ressources incluent notamment les stratégies de compartiment et les stratégies de point d’accès.

  1. Vérifiez l’absence d’une instruction Allow pour l’action dans votre politique basée sur les ressources. Vérifiez également si le paramètre de blocage de l’accès public S3 IgnorePublicAcls est appliqué au niveau du compartiment, du point d’accès ou du compte. Pour l’exemple suivant, l’action est s3:GetObject.

  2. Mettez à jour votre politique en ajoutant l’instruction Allow. Pour plus d’informations, consultez Politiques basées sur les ressources et Modification des politiques IAM dans le Guide de l’utilisateur IAM.

    Vous devrez peut-être aussi ajuster le paramètre de blocage de l’accès public IgnorePublicAcls pour le compartiment, le point d’accès ou le compte. Pour plus d’informations, consultez Accès refusé en raison de paramètres de blocage de l’accès public et Configuration des paramètres de blocage d’accès public pour vos compartiments S3.

User: arn:aws:iam::123456789012:user/MaryMajor is not authorized to perform: 
s3:GetObject because no resource-based policy allows the s3:GetObject action

Accès refusé en raison de politiques basées sur les ressources : refus explicite

Note

Les politiques basées sur les ressources incluent notamment les stratégies de compartiment et les stratégies de point d’accès.

  1. Vérifiez la présence d’une instruction Deny explicite pour l’action dans votre politique basée sur les ressources. Vérifiez également si le paramètre de blocage de l’accès public S3 RestrictPublicBuckets est appliqué au niveau du compartiment, du point d’accès ou du compte. Pour l’exemple suivant, l’action est s3:GetObject.

  2. Mettez à jour la politique en modifiant l’instruction Deny pour accorder à l’utilisateur l’accès nécessaire. Par exemple, vous pouvez mettre à jour l’instruction Deny pour utiliser la clé de condition aws:PrincipalAccount avec l’opérateur de condition StringNotEquals afin d’autoriser l’accès spécifique du principal, comme indiqué dans Exemple 7 : Exclure certains principaux d’une instruction Deny. Pour plus d’informations sur la mise à jour d’une politique basée sur les ressources, consultez les sections Politiques basées sur les ressources et Modification des politiques IAM dans le Guide de l’utilisateur IAM.

    Vous devrez peut-être aussi ajuster le paramètre de blocage de l’accès public RestrictPublicBuckets pour le compartiment, le point d’accès ou le compte. Pour plus d’informations, consultez Accès refusé en raison de paramètres de blocage de l’accès public et Configuration des paramètres de blocage d’accès public pour vos compartiments S3.

User: arn:aws:iam::123456789012:user/MaryMajor is not authorized to perform: 
s3:GetObject on resource: "arn:aws:s3:::amzn-s3-demo-bucket1/object-name" with 
an explicit deny in a resource-based policy

Accès refusé en raison de politiques basées sur l’identité : refus implicite

  1. Vérifiez l’absence d’une instruction Allow pour l’action dans les politiques basées sur l’identité attachées à l’identité. Pour l’exemple suivant, l’action est s3:GetObject attachée à l’utilisateur MaryMajor.

  2. Mettez à jour votre politique en ajoutant l’instruction Allow. Pour plus d’informations, consultez Politiques basées sur l’identité et Modification des politiques IAM dans le Guide de l’utilisateur IAM.

User: arn:aws:iam::123456789012:user/MaryMajor is not authorized to perform: 
s3:GetObject because no identity-based policy allows the s3:GetObject action

Accès refusé en raison de politiques basées sur l’identité : refus explicite

  1. Vérifiez la présence d’une instruction Deny explicite pour l’action dans les politiques basées sur l’identité attachées à l’identité. Pour l’exemple suivant, l’action est s3:GetObject attachée à l’utilisateur MaryMajor.

  2. Mettez à jour la politique en modifiant l’instruction Deny pour accorder à l’utilisateur l’accès nécessaire. Par exemple, vous pouvez mettre à jour l’instruction Deny pour utiliser la clé de condition aws:PrincipalAccount avec l’opérateur de condition StringNotEquals afin d’autoriser l’accès spécifique du principal, comme indiqué dans aws:PrincipalAccount dans le Guide de l’utilisateur IAM. Pour plus d’informations, consultez Politiques basées sur l’identité et Modification des politiques IAM dans le Guide de l’utilisateur IAM.

User: arn:aws:iam::123456789012:user/MaryMajor is not authorized to perform: 
s3:GetObject on resource: "arn:aws:s3:::amzn-s3-demo-bucket1/object-name" with 
an explicit deny in an identity-based policy

Accès refusé en raison de paramètres de blocage de l’accès public

La fonction du blocage de l’accès public Amazon S3 fournit des paramètres pour les points d’accès, les compartiments et les comptes afin de vous aider à gérer l’accès public aux ressources Amazon S3. Pour plus d’informations sur comment Amazon S3 définit le terme « public », consultez La signification du mot « public ».

Par défaut, les nouveaux compartiments, points d’accès et objets n’autorisent pas l’accès public. Toutefois, les utilisateurs peuvent modifier les stratégies de compartiment, les stratégies de point d’accès ou les autorisations d’objet pour autoriser l’accès public. Les paramètres de blocage de l’accès public S3 remplacent ces politiques, autorisations et listes ACL. Depuis avril 2023, tous les paramètres de blocage de l’accès public sont activés par défaut pour les nouveaux compartiments.

Quand Amazon S3 reçoit une demande d’accès à un compartiment ou à un objet, il détermine si le paramètre de blocage de l’accès public est défini pour le compartiment ou le compte du propriétaire de compartiment. Si la demande a été effectuée via un point d’accès, Amazon S3 vérifie également les paramètres de blocage de l’accès public pour le point d’accès. S’il existe un paramètre de blocage de l’accès public interdisant l’accès demandé, Amazon S3 rejette la demande.

Le blocage de l’accès public Amazon S3 fournit quatre paramètres. Ces paramètres sont indépendants et peuvent être fournis sous n’importe quelle combinaison. Chaque paramètre peut être appliqué à un point d’accès, à un compartiment ou à l’ensemble d’un compte AWS. Si les paramètres de blocage de l’accès public pour le point d’accès, le compartiment ou le compte diffèrent, Amazon S3 applique la combinaison la plus restrictive des paramètres du point d’accès, du compartiment et du compte.

Quand Amazon S3 évalue si une opération est interdite par un paramètre de blocage de l’accès public, il rejette toute demande qui irait à l’encontre d’un paramètre de point d’accès, de compartiment ou de compte.

Les quatre paramètres fournis par le blocage de l’accès public Amazon S3 sont les suivants :

  • BlockPublicAcls : ce paramètre s’applique aux demandes PutBucketAcl, PutObjectAcl, PutObject, CreateBucket, CopyObject et POST Object. Le paramètre BlockPublicAcls entraîne le comportement suivant :

    • Les appels PutBucketAcl et PutObjectAcl échouent si la liste de contrôle d’accès (ACL) spécifiée est publique.

    • Les appels PutObject échouent si la demande inclut une ACL publique.

    • Si ce paramètre est appliqué à un compte, les appels CreateBucket échouent avec une réponse HTTP 400 (Bad Request) si la demande inclut une ACL publique.

    Par exemple, lorsque l’accès à une demande CopyObject est refusé en raison du paramètre BlockPublicAcls, vous recevez le message suivant : 

    An error occurred (AccessDenied) when calling the CopyObject operation: 
User: arn:aws:sts::123456789012:user/MaryMajor is not authorized to 
perform: s3:CopyObject on resource: "arn:aws:s3:::amzn-s3-demo-bucket1/object-name" 
because public access control lists (ACLs) are blocked by the BlockPublicAcls block 
public access setting.

  • IgnorePublicAcls : le paramètre IgnorePublicAcls conduit Amazon S3 à ignorer toutes les listes ACL publiques d’un compartiment et tout objet qu’il contient. Si l’autorisation de votre demande est accordée uniquement par une liste ACL publique, alors le paramètre IgnorePublicAcls rejette la demande.

    Tout refus résultant du paramètre IgnorePublicAcls est implicite. Par exemple, si une liste IgnorePublicAcls refuse une demande GetObject en raison d’une ACL publique, vous recevez le message suivant : 

    User: arn:aws:iam::123456789012:user/MaryMajor is not authorized to perform: 
s3:GetObject because no resource-based policy allows the s3:GetObject action

  • BlockPublicPolicy : ce paramètre s’applique aux demandes PutBucketPolicy et PutAccessPointPolicy.

    En définissant BlockPublicPolicy pour un compartiment, Amazon S3 rejette les appels à PutBucketPolicy si la stratégie de compartiment spécifiée autorise l’accès public. Ce paramètre conduit également Amazon S3 à rejeter les appels à PutAccessPointPolicy pour tous les points d’accès du même compte du compartiment si la politique spécifiée autorise l’accès public.

    Si vous définissez BlockPublicPolicy pour un point d’accès, Amazon S3 rejette les appels PutAccessPointPolicy et PutBucketPolicy qui sont effectués via le point d’accès si la stratégie ou la politique spécifiée (pour le point d’accès ou le compartiment sous-jacent) autorise l’accès public.

    Par exemple, lorsque l’accès est refusé dans une demande PutBucketPolicy en raison du paramètre BlockPublicPolicy, vous recevez le message suivant : 

    An error occurred (AccessDenied) when calling the PutBucketPolicy operation: 
User: arn:aws:sts::123456789012:user/MaryMajor is not authorized to 
perform: s3:PutBucketPolicy on resource: "arn:aws:s3:::amzn-s3-demo-bucket1/object-name" 
because public policies are blocked by the BlockPublicPolicy block public 
access setting.

  • RestrictPublicBuckets : le paramètre RestrictPublicBuckets limite l’accès à un point d’accès ou à un compartiment avec une politique publique aux principaux du Service AWS et aux utilisateurs autorisés dans le compte du propriétaire du compartiment et du point d’accès. Ce paramètre bloque tous les accès intercomptes au point d’accès ou au compartiment (sauf par les principaux du Service AWS), tout en autorisant les utilisateurs au sein du compte à gérer le point d’accès ou le compartiment. Ce paramètre rejette également tous les appels anonymes (ou non signés).

    Tout refus résultant du paramètre RestrictPublicBuckets est explicite. Par exemple, si une liste RestrictPublicBuckets refuse une demande GetObject en raison d’une stratégie de compartiment public ou de point d’accès, vous recevez le message suivant : 

    User: arn:aws:iam::123456789012:user/MaryMajor is not authorized to perform: 
s3:GetObject on resource: "arn:aws:s3:::amzn-s3-demo-bucket1/object-name" with 
an explicit deny in a resource-based policy

Pour plus d’informations sur ces paramètres, consultez la page Paramètres de la fonctionnalité de blocage de l’accès public. Pour vérifier et mettre à jour ces paramètres, consultez Configuration du blocage d’accès public.

Accès refusé en raison des paramètres Paiement par le demandeur

Si la fonctionnalité Paiement par le demandeur est activée dans le compartiment Amazon S3 auquel vous essayez d’accéder, vous devez vous assurer que vous transmettez les bons paramètres de demande lorsque vous envoyez des demandes à ce compartiment. Avec la fonctionnalité Paiement par le demandeur d’Amazon S3, c’est le demandeur, et non le propriétaire du compartiment, qui paie les frais de transfert de données et de demande d’accès aux objets du compartiment. Lorsque la fonctionnalité Paiement par le demandeur d’un compartiment est activée, les demandes effectuées par d’autres comptes AWS ne sont facturées au propriétaire du compartiment.

Si vous effectuez une demande à un compartiment dont la fonctionnalité Paiement par le demandeur est activée sans transmettre les paramètres nécessaires, vous recevrez une message d’erreur Accès refusé (403 Forbidden). Pour accéder aux objets d’un compartiment dont la fonctionnalité Paiement par le demandeur est activée, vous devez effectuer les opérations suivantes :

  1. Lorsque vous effectuez des demandes à l’aide de l’interface de ligne de commande AWS, vous devez inclure le paramètre --request-payer requester. Par exemple, pour copier un objet dont la clé object.txt se trouve dans le compartiment S3 s3://amzn-s3-demo-bucket/ sur votre machine locale, vous devez également transmettre le paramètre --request-payer requester si la fonctionnalité Paiement par le demandeur est activée sur ce compartiment. 

    aws s3 cp s3://amzn-s3-demo-bucket/object.txt /local/path \
--request-payer requester

  2. Lorsque vous effectuez des demandes programmatiques à l’aide d’un kit AWS SDK, définissez l’en-tête x-amz-request-payer sur la valeur requester. Pour obtenir un exemple, consultez Téléchargement d’objets à partir de compartiments de type Paiement par le demandeur.

  3. Assurez-vous que l’utilisateur ou le rôle IAM à l’origine de la demande dispose des autorisations nécessaires pour accéder au compartiment dont la fonctionnalité Paiement par le demandeur est activée, notamment les autorisations s3:GetObject et s3:ListBucket.

En incluant le paramètre --request-payer requester ou en définissant l’en-tête x-amz-request-payer, vous informez Amazon S3 que vous, le demandeur, allez payer les coûts d’accès aux objets du compartiment dont la fonctionnalité Paiement par le demandeur est activée. Ainsi, vous ne recevrez pas le message d’erreur Accès refusé (403 Forbidden).

Stratégies de compartiment et politiques IAM

Opérations au niveau des compartiments

Si aucune stratégie de compartiment n’est en place, le compartiment autorise implicitement les demandes provenant de n’importe quelle identité AWS Identity and Access Management (IAM) du compte du propriétaire du compartiment. Le compartiment refuse également implicitement les demandes émanant de toute autre identité IAM provenant d’autres comptes, ainsi que les demandes anonymes (non signées). Toutefois, si aucune politique d’utilisateur IAM n’est en place, le demandeur (sauf s’il s’agit de l’utilisateur racine du Compte AWS) ne peut pas effectuer de demandes en raison d’un refus implicite. Pour plus d’informations sur cette logique d’évaluation, consultez Identification d’une demande autorisée ou refusée dans un compte dans le Guide de l’utilisateur d’IAM.

Opérations au niveau de l’objet

Si l’objet appartient au compte propriétaire du compartiment, la stratégie de compartiment et la politique de l’utilisateur IAM fonctionneront de la même manière pour les opérations au niveau de l’objet que pour les opérations au niveau du compartiment. Par exemple, si aucune stratégie de compartiment n’est en place, le compartiment autorise implicitement les demandes d’objet provenant de n’importe quelle identité IAM du compte du propriétaire du compartiment. Le compartiment refuse également implicitement les demandes d’objet émanant de toute autre identité IAM provenant d’autres comptes, ainsi que les demandes anonymes (non signées). Toutefois, si aucune politique d’utilisateur IAM n’est en place, le demandeur (sauf s’il s’agit de l’utilisateur racine du Compte AWS) ne peut pas effectuer de demandes d’objet en raison d’un refus implicite.

Si l’objet appartient à un compte externe, l’accès à l’objet ne peut être accordé que par le biais de listes de contrôle d’accès (ACL) aux objets. La politique relative aux compartiments et la politique d’utilisateur IAM peuvent toujours être utilisées pour refuser les demandes d’objets.

Par conséquent, pour vous assurer que votre stratégie de compartiment ou votre politique d’utilisateur IAM n’est pas à l’origine d’une erreur d’accès refusé (403 Forbidden), assurez-vous que les conditions suivantes sont remplies :

  • Pour l’accès au même compte, aucune déclaration Deny explicite ne doit être formulée à l’encontre du demandeur auquel vous essayez d’accorder des autorisations, que ce soit dans la stratégie de compartiment ou dans la politique d’utilisateur IAM. Si vous souhaitez accorder des autorisations en utilisant uniquement la stratégie de compartiment et la politique d’utilisateur IAM, l’une de ces politiques doit contenir au moins une déclaration Allow explicite.

  • Pour l’accès intercompte, aucune instruction Deny explicite ne doit être formulée à l’encontre du demandeur auquel vous essayez d’accorder des autorisations, que ce soit dans la stratégie de compartiment ou dans la politique d’utilisateur IAM. Si vous souhaitez accorder des autorisations intercomptes en utilisant uniquement la stratégie de compartiment et la politique d’utilisateur IAM, assurez-vous que la stratégie de compartiment et la politique d’utilisateur IAM du demandeur incluent une instruction Allow explicite.

Note

Les déclarations Allow d’une stratégie de compartiment s’appliquent uniquement aux objets appartenant au même compte propriétaire du compartiment. Toutefois, les déclarations Deny figurant dans une stratégie de compartiment s’appliquent à tous les objets, quel que soit leur propriétaire.

Pour consulter ou modifier votre stratégie de compartiment
Note

Pour afficher ou modifier une stratégie de compartiment, vous devez disposer de l’autorisation s3:GetBucketPolicy.

  1. Connectez-vous à la AWS Management Console et ouvrez la console Amazon S3 à l’adresse https://console.aws.amazon.com/s3/.

  2. Dans le volet de navigation de gauche, choisissez Compartiments.

  3. Dans la liste Compartiments, choisissez le nom du compartiment pour lequel vous souhaitez afficher ou modifier une stratégie de compartiment.

  4. Choisissez l’onglet Permissions (Autorisations).

  5. Sous Stratégie de compartiment, choisissez Modifier. La page Edit bucket policy (Modifier la stratégie de compartiment) s’affiche.

Pour consulter ou modifier votre stratégie de compartiment à l’aide d’AWS Command Line Interface (AWS CLI), utilisez la commande get-bucket-policy.

Note

Si l’accès à un compartiment est bloqué en raison d’une stratégie de compartiment incorrecte, connectez-vous à la AWS Management Console avec vos informations d’identification d’utilisateur racineCompte AWS. Pour accéder de nouveau à votre compartiment, veillez à supprimer la stratégie de compartiment incorrecte à l’aide des informations d’identification d’utilisateur racine Compte AWS.

Conseils pour vérifier les autorisations

Pour vérifier si le demandeur dispose des autorisations nécessaires pour effectuer une opération Amazon S3, essayez ce qui suit :

Paramètres des listes de contrôle d’accès d’Amazon S3

Lorsque vous vérifiez vos paramètres de listes ACL, vérifiez d’abord votre paramètre de propriété de l’objet pour vérifier si les listes ACL sont activées sur le compartiment. Sachez que les autorisations de listes ACL ne peuvent être utilisées que pour accorder des autorisations et non pas pour rejeter des demandes. Les listes ACL ne peuvent pas non plus être utilisées pour accorder l’accès à des demandeurs qui sont rejetés en raison de refus explicites dans les stratégies de compartiment ou les politiques d’utilisateur IAM.

Le paramètre Propriétaire de l’objet est défini sur Propriétaire du compartiment appliqué

Si le paramètre Propriétaire du compartiment appliqué est activé, il est peu probable que les paramètres des listes ACL génèrent un message d’erreur Accès refusé (403 Forbidden), car ce paramètre désactive toutes les listes ACL qui s’appliquent au compartiment et aux objets. Propriétaire du compartiment appliqué est le paramètre par défaut (et recommandé) pour les compartiments Amazon S3.

Le paramètre Propriété de l’objet est défini sur Propriétaire du compartiment appliqué ou Créateur de l’objet

Les autorisations des listes ACL restent valides avec le paramètre Propriétaire du compartiment appliqué ou Créateur de l’objet. Il existe deux types de listes ACL : les listes ACL de compartiment et les listes ACL d’objets. Pour connaître les différences entre ces deux types de listes ACL, consultez Mappage des autorisations de liste ACL et de stratégie d’accès.

En fonction de l’action de la demande rejetée, vérifiez les autorisations des listes ACL pour votre compartiment ou l’objet :

Résolution d’une erreur d’accès refusé (403 Forbidden) liée à une demande d’objet GET lors de la propriété d’un objet intercompte

Passez en revue les paramètres de propriété de l’objet du compartiment pour déterminer le propriétaire de l’objet. Si vous avez accès aux listes ACL des objets, vous pouvez également consulter le compte du propriétaire de l’objet. (Pour consulter le compte du propriétaire de l’objet, consultez le paramètre de la liste ACL de l’objet dans la console Amazon S3.) Vous pouvez également faire une demande GetObjectAcl d’identification canonique du propriétaire de l’objet afin de vérifier le compte du propriétaire de l’objet. Par défaut, les listes ACL accordent des autorisations d’autorisation explicites pour les demandes GET adressées au compte du propriétaire de l’objet.

Après avoir confirmé que le propriétaire de l’objet est différent du propriétaire du compartiment, en fonction de votre cas d’utilisation et de votre niveau d’accès, choisissez l’une des méthodes suivantes pour résoudre l’erreur d’accès refusé (403 Forbidden) :

  • Désactiver les listes ACL (recommandé) : cette méthode s’applique à tous les objets et peut être exécutée par le propriétaire du compartiment. Cette méthode offre automatiquement au propriétaire du compartiment la propriété de chaque objet du compartiment et leur contrôle total. Avant d’implémenter cette méthode, vérifiez les conditions préalables à la désactivation des listes ACL. Pour plus d’informations sur la configuration de votre compartiment en mode Propriétaire du compartiment appliqué (recommandé), consultez Définition de la propriété d’un objet sur un compartiment existant.

    Important

    Pour éviter une erreur d’accès refusé (403 Forbidden), veillez à migrer les autorisations de listes ACL vers une stratégie de compartiment avant de désactiver les listes ACL. Pour plus d’informations, consultez Bucket policy examples for migrating from ACL permissions (Exemples de stratégies de compartiment pour la migration à partir d’autorisations de listes ACL).

  • Remplacer le propriétaire de l’objet par le propriétaire du compartiment : cette méthode peut être appliquée à des objets individuels, mais seul le propriétaire de l’objet (ou un utilisateur disposant des autorisations appropriées) peut modifier la propriété d’un objet. Des frais PUT supplémentaires peuvent s’appliquer. (Pour plus d’informations, consultez Tarification Amazon S3.) Cette méthode confère au propriétaire du compartiment la pleine propriété de l’objet, ce qui lui permet de contrôler l’accès à l’objet par le biais d’une stratégie de compartiment.

    Pour modifier la propriété de l’objet, effectuez l’une des opérations suivantes :

    • Vous (le propriétaire du compartiment) pouvez recopier l’objet dans le compartiment.

    • Vous pouvez modifier le paramètre Propriétaire de l’objet du compartiment et le définir sur Propriétaire du compartiment préféré. Si la gestion des versions est désactivée, les objets du compartiment sont remplacés. Si la gestion des versions est activée, des versions dupliquées du même objet apparaîtront dans le compartiment, et le propriétaire du compartiment peut définir une règle de cycle de vie d’expiration. Pour plus d’informations sur la modification des paramètres de propriété des objets, consultez Définition de la propriété d’un objet sur un compartiment existant.

      Note

      Lorsque vous mettez à jour le paramètre Propriétaire de l’objet sur Propriétaire du compartiment préféré, le paramètre mis à jour s’applique uniquement aux nouveaux objets chargés dans le compartiment.

    • Vous pouvez demander au propriétaire de l’objet de le charger à nouveau à l’aide de la liste ACL de l’objet prédéfini bucket-owner-full-control.

    Note

    Pour les chargements intercomptes, vous pouvez également exiger la liste ACL de l’objet prédéfini bucket-owner-full-control dans votre stratégie de compartiment. Pour un exemple de stratégie de compartiment, consultez Octroi d’autorisations intercomptes pour charger des objets tout en garantissant que le propriétaire du compartiment dispose d’un contrôle total.

  • Conservez le rédacteur de l’objet en tant que propriétaire de l’objet : cette méthode ne modifie pas le propriétaire de l’objet, mais elle vous permet d’accorder l’accès aux objets individuellement. Pour autoriser l’accès à un objet, vous devez disposer de l’autorisation PutObjectAcl pour cet objet. Ensuite, pour corriger l’erreur d’accès refusé (403 Forbidden), ajoutez le demandeur en tant que bénéficiaire pour accéder à l’objet dans les listes ACL de l’objet. Pour plus d’informations, consultez Configuration des listes ACL.

Paramètres de blocage de l’accès public S3

Si l’échec de la demande implique un accès public ou des politiques publiques, vérifiez alors les paramètres de blocage de l’accès public S3 sur votre compte, votre compartiment ou votre point d’accès. Pour plus d’informations sur la résolution des erreurs de refus d’accès liées aux paramètres de blocage de l’accès public S3, consultez Accès refusé en raison de paramètres de blocage de l’accès public.

Paramètres du chiffrement Amazon S3

Amazon S3 prend en charge le chiffrement côté serveur sur votre compartiment. Le chiffrement côté serveur est le chiffrement des données à leur destination par l’application ou le service qui les reçoit. Amazon S3 chiffre les données au niveau de l’objet lors de l’écriture des données sur les disques dans les centres de données AWS, et les déchiffre pour vous quand vous accédez aux données.

Par défaut, Amazon S3 applique désormais le chiffrement côté serveur avec les clés gérées par Amazon S3 (SSE-S3) comme niveau de base du chiffrement pour chaque compartiment d’Amazon S3. Amazon S3 vous permet également de spécifier la méthode de chiffrement côté serveur lors du chargement d’objets.

Pour vérifier le statut et les paramètres de chiffrement côté serveur de votre compartiment

  1. Connectez-vous à la AWS Management Console et ouvrez la console Amazon S3 à l’adresse https://console.aws.amazon.com/s3/.

  2. Dans le volet de navigation de gauche, choisissez Compartiments.

  3. Dans la liste Compartiments, choisissez le compartiment pour lequel vous souhaitez vérifier les paramètres de chiffrement.

  4. Choisissez l’onglet Propriétés.

  5. Faites défiler l’écran vers le bas jusqu’à la section Chiffrement par défaut, puis examinez les paramètres de Type de chiffrement.

Pour vérifier vos paramètres de chiffrement à l’aide de l’AWS CLI, utilisez la commande get-bucket-encryption.

Pour vérifier le statut du chiffrement d’un objet

  1. Connectez-vous à la AWS Management Console et ouvrez la console Amazon S3 à l’adresse https://console.aws.amazon.com/s3/.

  2. Dans le volet de navigation de gauche, choisissez Compartiments.

  3. Dans la liste Compartiments, choisissez le nom du compartiment qui contient l’objet.

  4. Dans la liste Objets, choisissez le nom de l’objet pour lequel vous souhaitez ajouter ou modifier le chiffrement.

    La page de détails de l’objet s’affiche.

  5. Accédez à la section Paramètres de chiffrement côté serveur pour afficher les paramètres de chiffrement côté serveur de l’objet.

Pour vérifier le statut du chiffrement de l’objet à l’aide de l’AWS CLI, utilisez la commande head-object.

Exigences en matière de chiffrement et d’autorisations

Amazon S3 prend en charge trois types de chiffrement côté serveur :

  • Chiffrement côté serveur avec des clés gérées par Amazon S3 (SSE-S3)

  • Chiffrement côté serveur avec des clés AWS Key Management Service (AWS KMS) (SSE-KMS)

  • Chiffrement côté serveur avec clés fournies par le client (SSE-C)

En fonction de vos paramètres de chiffrement, assurez-vous que les exigences d’autorisation suivantes sont remplies :

  • SSE-S3 : aucune autorisation supplémentaire n’est requise.

  • SSE-KMS (avec une clé gérée par le client) : pour télécharger des objets, l’autorisation kms:GenerateDataKey est requise sur la AWS KMS key. Pour télécharger des objets et effectuer des chargements partitionnés d’objets, l’autorisation kms:Decrypt est requise sur la clé KMS.

  • SSE-KMS (avec une Clé gérée par AWS) : le demandeur doit provenir du même compte que celui qui possède la clé KMS aws/s3. Le demandeur doit également disposer des autorisations Amazon S3 appropriées pour accéder à l’objet.

  • SSE-C (avec une clé fournie par le client) : aucune autorisation supplémentaire n’est requise. Vous pouvez configurer la stratégie de compartiment pour exiger et restreindre le chiffrement côté serveur avec les clés de chiffrement fournies par le client pour les objets de votre compartiment.

Si l’objet est chiffré à l’aide d’une clé gérée par le client, assurez-vous que la stratégie de clé KMS vous permet d’effectuer les actions kms:GenerateDataKey ou kms:Decrypt. Pour obtenir des instructions sur la vérification de votre stratégie de clé KMS, consultez Viewing a key policy (Affichage d’une politique relative aux clés) dans le Guide du développeur AWS Key Management Service.

Paramètres de verrouillage des objets S3

Si le verrouillage d’objet S3 est activé sur votre compartiment et que l’objet est protégé par une période de rétention ou une conservation légale et que vous essayez de supprimer un objet, Amazon S3 renvoie l’une des réponses suivantes, selon la manière dont vous avez essayé de supprimer l’objet :

  • Demande DELETE permanente : si vous avez émis une demande DELETE permanente (une demande qui spécifie un ID de version), Amazon S3 renvoie un message erreur Accès refusé (403 Forbidden) lorsque vous essayez de supprimer l’objet.

  • Demande DELETE simple : si vous avez émis une demande DELETE simple (une demande qui ne spécifie pas d’ID de version), Amazon S3 renvoie une réponse 200 OK et insère un marqueur de suppression dans le compartiment. Ce marqueur devient la version en cours de l’objet avec un nouvel ID.

Pour vérifier si le verrouillage des objets est activé sur le compartiment

  1. Connectez-vous à la AWS Management Console et ouvrez la console Amazon S3 à l’adresse https://console.aws.amazon.com/s3/.

  2. Dans le volet de navigation de gauche, choisissez Compartiments.

  3. Dans la liste Compartiments, choisissez le nom du compartiment que vous souhaitez vérifier.

  4. Choisissez l’onglet Propriétés.

  5. Faites défiler jusqu’à la section Verrouillage des objets. Vérifiez si le paramètre Verrouillage des objets est Activé ou Désactivé.

Pour déterminer si l’objet est protégé par une période de rétention ou une conservation légale, consultez les informations de verrouillage de votre objet.

Si l’objet est protégé par une période de rétention ou une conservation légale, vérifiez les points suivants :

  • Si la version de l’objet est protégée par le mode de conservation de la conformité, il n’est pas possible de la supprimer définitivement. Une demande DELETE permanente émanant de n’importe quel demandeur, y compris l’utilisateur racine, se traduit par une erreur (403 Forbidden) liée à un refus d’accès. Sachez également que lorsque vous soumettez une demande DELETE pour un objet protégé par le mode de conservation de la conformité, Amazon S3 crée un marqueur de suppression pour cet objet.

  • Si la version de l’objet est protégée par le mode de conservation de la gouvernance et que vous en avez l’autorisation s3:BypassGovernanceRetention, vous pouvez contourner la protection et supprimer définitivement la version. Pour plus d’informations, consultez Ignorer le mode de gouvernance.

  • Si la version de l’objet est protégée par une conservation légale, une demande DELETE permanente peut entraîner une erreur d’accès refusé (403 Forbidden). Pour supprimer définitivement la version de l’objet, vous devez supprimer la conservation légale sur la version de l’objet. Pour supprimer une conservation légale, vous devez avoir l’autorisation s3:PutObjectLegalHold. Pour plus d’informations sur la suppression d’une conservation légale, consultez Configuration du verrouillage d’objet S3.

Politiques de point de terminaison d’un VPC

Si vous accédez à Amazon S3 en utilisant le point de terminaison d’un cloud privé virtuel (VPC), assurez-vous que la politique de point de terminaison du VPC ne vous empêche pas d’accéder à vos ressources Amazon S3. Par défaut, la politique de point de terminaison d’un VPC autorise toutes les demandes adressées à Amazon S3. Vous pouvez également configurer la politique de point de terminaison d’un VPC pour restreindre certaines demandes. Pour plus d’informations sur la vérification de votre politique de point de terminaison d’un VPC, consultez les ressources suivantes :

Politiques AWS Organizations

Si votre Compte AWS appartient à une organisation, les politiques AWS Organizations peuvent vous empêcher d’accéder aux ressources Amazon S3. Par défaut, les politiques AWS Organizations ne bloquent aucune demande vers Amazon S3. Assurez-vous toutefois que vos politiques AWS Organizations n’ont pas été configurées pour bloquer l’accès aux compartiments S3. Pour obtenir des instructions sur la façon de vérifier vos politiques AWS Organizations, consultez les ressources suivantes :

En outre, si vous avez configuré votre stratégie de compartiment de manière incorrecte pour qu’un compte membre refuse à tous les utilisateurs l’accès à votre compartiment S3, vous pouvez déverrouiller le compartiment en lançant une session privilégiée pour ce compte membre dans IAM. Après avoir lancé une session privilégiée, vous pourrez supprimer la stratégie de compartiment mal configurée pour récupérer l’accès au compartiment. Pour plus d’informations, consultez Réaliser une tâche privilégiée sur un compte membre AWS Organizations dans le Guide de l’utilisateur AWS Identity and Access Management.

Accès aux distributions CloudFront

Si vous recevez un message d’erreur Accès refusé (403 Forbidden) lorsque vous tentez d’accéder à votre site Web statique S3 via CloudFront, vérifiez les problèmes courants suivants :

  • Le nom de domaine d’origine est-il au bon format ?

    • Assurez-vous d’utiliser le format du point de terminaison du site Web S3 (bucket-name.s3-website-region.amazonaws.com) au lieu de celui du point de terminaison de l’API REST

    • Vérifiez que l’hébergement de site Web statique est activé sur votre compartiment

  • Votre stratégie de compartiment autorise-t-elle l’accès à CloudFront ?

    • Assurez-vous que votre stratégie de compartiment inclut des autorisations pour l’identité d’accès d’origine (OAI) ou le contrôle d’accès d’origine (OAC) de votre distribution CloudFront

    • Vérifiez que la stratégie inclut les autorisations s3:GetObject requises

Pour voir d’autres procédures de résolution de problèmes et configurations, y compris les configurations des pages d’erreur et les paramètres de protocole, consultez Pourquoi est-ce que je reçois un message d’erreur « 403 access denied » lorsque j’utilise un point de terminaison du site Web d’Amazon S3 comme origine de ma distribution CloudFront ? dans le Centre de connaissances AWS re:Post.

Note

Cette erreur est différente des erreurs 403 que vous pourriez recevoir en accédant directement à S3. Pour les problèmes spécifiques à CloudFront, veillez à vérifier à la fois vos paramètres de distribution CloudFront et vos configurations S3.

Paramètres du point d’accès

Si vous recevez un message d’erreur d’accès refusé (403 Forbidden) lorsque vous effectuez des demandes via les points d’accès Amazon S3, vous devrez peut-être vérifier les points suivants :

  • Les configurations de vos points d’accès

  • La politique d’utilisateur IAM utilisée pour vos points d’accès

  • La stratégie de compartiment utilisée pour gérer ou configurer vos points d’accès intercompte

Configurations et politiques des points d’accès

Si l’erreur d’accès refusé (403 Forbidden) persiste après avoir vérifié tous les éléments de cette rubrique, récupérez votre ID de demande Amazon S3 et contactez Support pour obtenir des conseils supplémentaires.

Ressources supplémentaires

Pour plus d’informations sur les erreurs Accès refusé (403 Forbidden), consultez les ressources suivantes :