View a markdown version of this page

Résoudre les problèmes liés à l'accès refusé (403 Forbidden) erreurs 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 demandeurPolitiques 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 VPCAWS Organizations politiquesCloudFront accès à la distributionParamètres du point d’accèsRessources supplémentaires

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Résoudre les problèmes liés à l'accès refusé (403 Forbidden) erreurs dans Amazon S3

Des erreurs d'accès refusé (HTTP403 Forbidden) apparaissent lorsque le refus AWS explicite ou implicite d'une demande d'autorisation est refusé.

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

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

Étant donné qu'une politique Gestion des identités et des accès AWS (IAM) refuse implicitement un principal IAM par défaut, la politique 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

Pour les erreurs d'accès refusé (HTTP403 Forbidden), Amazon S3 ne facture pas le propriétaire du bucket lorsque la demande est initiée en dehors du AWS compte individuel du propriétaire du bucket ou de l' AWS organisation du propriétaire du bucket.

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 Politiques 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 erreurs d'accès refusé (HTTP403 Forbidden) pour les demandes adressées à des ressources au sein de la même organisation Compte AWS ou de la même organisation AWS Organizations. Ce contexte inclut le type de politique qui a refusé l'accès, la raison du refus et des informations sur l'utilisateur ou le rôle IAM qui a demandé l'accès à la ressource.

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

Pour les cas de refus explicites, le message d'erreur inclut également le nom de ressource Amazon (ARN) de la politique spécifique qui a refusé la demande. Grâce à cet ARN de politique, vous pouvez rapidement identifier la politique exacte responsable du refus et y accéder directement pour apporter les modifications nécessaires. Le message d'erreur inclut l'ARN de la politique pour les politiques de contrôle des services (SCP), les politiques de contrôle des ressources (RCP), les politiques basées sur l'identité, les politiques de session et les limites d'autorisations.

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 Deny instruction, le message d'erreur Accès refusé inclut la phrasewith an explicit deny in a type policy, ainsi que l'ARN de la politique spécifique qui a refusé la demande. 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é ne sont renvoyés que pour les demandes relatives au même compte ou pour les demandes émanant de la même organisation en AWS Organizations. Cross-account les requêtes extérieures à la même organisation renvoient un Access Denied message générique.

    Pour plus d'informations sur la logique d'évaluation des politiques qui détermine si une demande d'accès entre comptes est autorisée ou refusée, consultez la section Logique d'évaluation des Cross-account politiques 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.

  • Pour les cas de refus explicites, le message d'erreur inclut l'ARN de la politique spécifique qui a refusé la demande. Cela s'applique aux politiques de contrôle des services (SCP), aux politiques de contrôle des ressources (RCP), aux politiques basées sur l'identité, aux politiques de session et aux limites d'autorisations.

  • 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'un type de cryptage bloqué

Pour limiter les types de chiffrement côté serveur que vous pouvez utiliser dans vos compartiments à usage général, vous pouvez choisir de bloquer les demandes d' SSE-C écriture en mettant à jour votre configuration de chiffrement par défaut pour vos compartiments. Cette configuration au niveau du compartiment bloque les demandes de téléchargement d'objets qui le spécifient. SSE-C En cas SSE-C de blocage pour un bucket PutObject CopyObjectPostObject, toutes les demandes de téléchargement ou de réplication partitionnées ou de réplication qui spécifient SSE-C le chiffrement sont rejetées avec une AccessDenied erreur HTTP 403.

Ce paramètre est un paramètre de l'PutBucketEncryptionAPI et peut également être mis à jour à l'aide de la console S3, de l' AWS interface de ligne de commande et AWS des kits SDK, si vous en avez l's3:PutEncryptionConfigurationautorisation. Les valeurs valides sont SSE-C les suivantes : qui bloque le SSE-C chiffrement pour le compartiment à usage généralNONE, et qui autorise l'utilisation SSE-C pour les écritures dans le compartiment.

Par exemple, lorsque l'accès est refusé pour une PutObject demande parce que le BlockedEncryptionTypes paramètre bloque l'écriture des requêtes spécifiant SSE-C, vous recevez le message suivant :

An error occurred (AccessDenied) when calling the PutObject operation:   
User: arn:aws:iam::123456789012:user/MaryMajor  is not   
authorized to perform: s3:PutObject on resource:   
"arn:aws:s3:::amzn-s3-demo-bucket1/object-name" because this   
bucket has blocked upload requests that specify   
Server Side Encryption with Customer provided keys (SSE-C).   
Please specify a different server-side encryption type

Pour en savoir plus sur ce paramètre, consultez Blocage ou déblocage SSE-C d'un seau à usage général.

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

  1. Recherchez une Deny déclaration explicite concernant l'action dans vos politiques de contrôle des ressources (RCP). Le message d'erreur inclut l'ARN de la politique, que vous pouvez utiliser pour identifier et accéder directement à la politique qui a refusé la demande. 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, with policy ARN: 
arn:aws:organizations::777788889999:policy/o-exampleorgid/resource_control_policy/p-examplepolicyid

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 explicite pour l'action dans vos politiques de contrôle des services (SCP). Le message d'erreur inclut l'ARN de la politique, que vous pouvez utiliser pour identifier et accéder directement à la politique qui a refusé la demande. 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 un exemple de la manière dont vous pouvez procéder, consultez la section Exemples de politiques de contrôle des services sur GitHub. 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, with policy ARN: 
arn:aws:organizations::777788889999:policy/o-exampleorgid/service_control_policy/p-examplepolicyid

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 : Exclusion de certains directeurs 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. Le message d'erreur inclut l'ARN de la politique, que vous pouvez utiliser pour identifier et accéder directement à la politique qui a refusé la demande. 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, with policy ARN: 
arn:aws:iam::777788889999:policy/ExamplePermissionsBoundaryPolicy

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. Le message d'erreur inclut l'ARN de la politique, que vous pouvez utiliser pour identifier et accéder directement à la politique qui a refusé la demande. 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 : Exclusion de certains directeurs 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, with policy ARN: 
arn:aws:iam::123456789012:policy/ExampleSessionPolicy

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

Note

Resource-based les politiques désignent des politiques telles que les politiques de bucket et les politiques 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 Resource-based les rubriques Politiques 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

Resource-based les politiques désignent des politiques telles que les politiques de bucket et les politiques 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 : Exclusion de certains directeurs d'une instruction Deny. Pour plus d'informations sur la mise à jour de votre stratégie basée sur les ressources, consultez Resource-based les rubriques Politiques 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é. Dans l'exemple suivant, l'action est s3:GetObject et l'identité est l'utilisateur MaryMajor IAM.

  2. Mettez à jour votre politique en ajoutant l’instruction Allow. Pour plus d'informations, consultez Identity-based les rubriques Politiques 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é. Le message d'erreur inclut l'ARN de la politique, que vous pouvez utiliser pour identifier et accéder directement à la politique qui a refusé la demande. Dans l'exemple suivant, l'action est s3:GetObject et l'identité est l'utilisateur MaryMajor IAM.

  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 Identity-based les rubriques Politiques 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, with policy ARN: 
arn:aws:iam::123456789012:policy/ExampleIdentityBasedPolicy

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 politiques 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 AWS compte. 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 ACLs are prevented by the BlockPublicAcls setting in S3 Block Public Access.

  • 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 politique 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 prevented by the BlockPublicPolicy setting in S3 Block Public Access.

  • RestrictPublicBuckets— Le RestrictPublicBuckets paramètre limite l'accès à un point d'accès ou à un compartiment soumis à une politique publique aux seuls Service AWS responsables et utilisateurs autorisés du compte du propriétaire du compartiment et du compte du propriétaire du point d'accès. Ce paramètre bloque tous les accès entre comptes au point d'accès ou au compartiment (sauf pour les utilisateurs Service AWS principaux), tout en permettant aux utilisateurs du compte de 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 politique 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 Requester Pays est activé pour un compartiment, le propriétaire du compartiment n'est pas facturé pour les demandes effectuées par d'autres AWS comptes.

Si vous envoyez une demande à un Pays-enabled compartiment de demandeur sans transmettre les paramètres nécessaires, vous recevrez un message d'erreur Accès refusé (403 interdit). Pour accéder aux objets d'un Pays-enabled bucket Requérant, vous devez effectuer les opérations suivantes :

  1. Lorsque vous effectuez des requêtes à l'aide de l' AWS interface de ligne de commande, vous devez inclure le --request-payer requester paramètre. 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 requêtes programmatiques à l'aide d'un AWS SDK, définissez l'x-amz-request-payeren-tête 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 --request-payer requester paramètre ou en définissant l'x-amz-request-payeren-tête, vous informez Amazon S3 que vous, en tant que demandeur, paierez les coûts associés à l'accès aux objets du compartiment du demandeur Pays-enabled . Ainsi, vous ne recevrez pas le message d’erreur Accès refusé (403 Forbidden).

Politiques de compartiment et politiques IAM

Bucket-level opérations

Si aucune politique de compartiment n'est en place, le compartiment autorise implicitement les demandes provenant de n'importe quelle identité Gestion des identités et des accès AWS (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). Cependant, si aucune politique utilisateur IAM n'est en place, le demandeur (sauf s'il s'agit de l'utilisateur Compte AWS root) est implicitement empêché de faire des demandes. 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.

Object-level opérations

Si l’objet appartient au compte propriétaire du compartiment, la politique 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 politique 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). Cependant, si aucune politique utilisateur IAM n'est en place, le demandeur (sauf s'il s'agit de l'utilisateur Compte AWS root) est implicitement empêché d'effectuer des demandes d'objets.

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 politique 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 politique de compartiment ou dans la politique d’utilisateur IAM. Si vous souhaitez accorder des autorisations en utilisant uniquement la politique 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 politique de compartiment ou dans la politique d’utilisateur IAM. Si vous souhaitez accorder des autorisations intercomptes en utilisant uniquement la politique de compartiment et la politique d’utilisateur IAM, assurez-vous que la politique de compartiment et la politique d’utilisateur IAM du demandeur incluent une instruction Allow explicite.

Note

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

Pour consulter ou modifier votre politique de compartiment
Note

Pour consulter une politique relative aux compartiments, vous devez en avoir l's3:GetBucketPolicyautorisation. Pour modifier une politique de bucket, vous devez en avoir l's3:PutBucketPolicyautorisation.

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

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

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

  4. Sélectionnez l’onglet Autorisations.

  5. Sous Politique de compartiment, choisissez Modifier. La page Edit bucket policy (Modifier la politique de compartiment) s'affiche.

Pour revoir votre politique en matière de bucket à l'aide du AWS Command Line Interface (AWS CLI), utilisez la get-bucket-policy commande. Pour modifier votre politique en matière de bucket, utilisez la put-bucket-policy commande.

Note

Si l'accès à un compartiment vous est interdit en raison d'une politique de compartiment incorrecte, connectez-vous au à l'aide Console de gestion AWS de vos informations d'identification d'utilisateur Compte AWS root. Pour accéder de nouveau à votre compartiment, assurez-vous de supprimer la politique de compartiment incorrecte en utilisant vos informations d'identification d'utilisateur Compte AWS root.

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 politiques 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 interdit) due à une requête d'objet GET lors de la propriété d'un objet entre comptes

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 politique de compartiment avant de désactiver les listes ACL. Pour plus d’informations, consultez Bucket policy examples for migrating from ACL permissions (Exemples de politiques 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 politique 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 politique de compartiment. Pour un exemple de politique 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 de plus amples informations, veuillez consulter 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. Server-side le chiffrement est le chiffrement des données à leur destination par l'application ou le service qui les reçoit. Amazon S3 chiffre vos données au niveau de l'objet lorsqu'il les écrit sur les disques des centres de AWS données et les déchiffre pour vous lorsque vous y accédez.

Par défaut, Amazon S3 applique désormais le chiffrement côté serveur avec des clés gérées par Amazon S3 (SSE-S3) comme niveau de chiffrement de base 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 à Console de gestion AWS et ouvrez la console Amazon S3 à l'adresse https://console.aws.amazon.com/s3/.

  2. Dans le panneau 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 AWS CLI, utilisez la get-bucket-encryption commande.

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

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

  2. Dans le panneau 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. Faites défiler la page jusqu'à la section des paramètres de Server-side chiffrement pour afficher les paramètres de chiffrement côté serveur de l'objet.

Pour vérifier l'état de chiffrement de votre objet à l'aide de AWS CLI, utilisez la head-object commande.

Exigences en matière de chiffrement et d’autorisations

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

  • Server-side chiffrement à l'aide de clés gérées par Amazon S3 (SSE-S3)

  • Server-side chiffrement avec AWS Key Management Service (AWS KMS) clés (SSE-KMS)

  • Server-side chiffrement à l'aide de 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'kms:GenerateDataKeyautorisation sur le AWS KMS key est requise. 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 un Clé gérée par AWS) — Le demandeur doit provenir du même compte que celui qui possède la clé aws/s3 KMS. 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 politique 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 à Console de gestion AWS et ouvrez la console Amazon S3 à l'adresse https://console.aws.amazon.com/s3/.

  2. Dans le panneau 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 DELETE demande permanente émanant de n'importe quel demandeur, y compris l'utilisateur Compte AWS root, entraînera une erreur Accès refusé (403 interdit). 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 :

AWS Organizations politiques

Si vous Compte AWS appartenez à une organisation, AWS Organizations les politiques peuvent vous empêcher d'accéder aux ressources Amazon S3. Par défaut, AWS Organizations les politiques ne bloquent aucune demande adressée à Amazon S3. Cependant, assurez-vous que vos AWS Organizations politiques n'ont pas été configurées pour bloquer l'accès aux compartiments S3. Pour savoir comment vérifier vos AWS Organizations politiques, consultez les ressources suivantes :

En outre, si vous avez configuré votre politique 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, voir Exécuter une tâche privilégiée sur un compte AWS Organizations membre dans le Guide de Gestion des identités et des accès AWS l'utilisateur.

CloudFront accès à la distribution

Si vous recevez un message d'erreur Accès refusé (403 interdit) 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 politique en matière de bucket autorise-t-elle CloudFront l'accès ?

    • Assurez-vous que votre politique de bucket inclut des autorisations pour l'Identité d'accès à l'origine (OAI) ou le contrôle d'accès à l'origine (OAC) de votre CloudFront distribution

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

Pour des étapes de dépannage et des configurations supplémentaires, y compris la configuration des pages d'erreur et les paramètres de protocole, consultez Pourquoi est-ce que je reçois une erreur « Accès 403 refusé » lorsque j'utilise un point de terminaison de site Web Amazon S3 comme origine de ma CloudFront distribution ? dans le centre de AWS re:Post connaissances.

Note

Cette erreur est différente des erreurs 403 que vous pourriez recevoir en accédant directement à S3. En CloudFront-specific cas de problème, assurez-vous de vérifier à la fois vos paramètres CloudFront de distribution 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 politique de compartiment utilisée pour gérer ou configurer vos points d’accès intercompte

Configurations et politiques des points d’accès

  • Lorsque vous créez un point d’accès, vous pouvez choisir de désigner Internet ou VPC comme l’origine du réseau. Si l’origine du réseau est définie sur VPC uniquement, Amazon S3 rejettera toutes les demandes adressées au point d’accès qui ne proviennent pas du VPC spécifié. Pour vérifier l’origine du réseau de votre point d’accès, consultez Création de points d’accès restreints à un virtual private cloud.

  • Avec les points d’accès, vous pouvez également configurer des paramètres personnalisés de blocage de l’accès public, qui fonctionnent de la même manière que les paramètres de blocage de l’accès public au niveau du compartiment ou du compte. Pour vérifier vos paramètres personnalisés de blocage de l’accès public, consultez Gestion de l’accès public aux points d’accès de compartiments à usage général.

  • Pour envoyer des demandes réussies à Amazon S3 à l’aide de points d’accès, assurez-vous que le demandeur dispose des autorisations IAM nécessaires. Pour de plus amples informations, veuillez consulter Configuration des politiques IAM pour l’utilisation des points d’accès.

  • Si la demande concerne des points d’accès intercompte, assurez-vous que le propriétaire du compartiment a mis à jour la politique du compartiment pour autoriser les demandes provenant du point d’accès. Pour de plus amples informations, veuillez consulter Octroi d’autorisations pour les points d’accès intercompte.

Si l'erreur Accès refusé (403 interdit) persiste après avoir vérifié tous les éléments de cette rubrique, récupérez votre ID de demande Amazon S3 et contactez-nous 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 :