Résoudre les problèmes d'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ésoudrePolitiques 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 politiquesParamètres du point d’accès

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 d'accès refusé (403 Forbidden) erreurs dans Amazon S3

Des erreurs d'accès refusé (HTTP403 Forbidden) apparaissent en cas de refus AWS explicite ou implicite d'une demande d'autorisation.

  • Un refus explicite se produit lorsqu'une politique contient une Deny déclaration pour une 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 AWS Identity and Access Management (IAM) refuse implicitement un principal IAM par défaut, elle doit explicitement autoriser 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 d'accès refusé (HTTP403 Forbidden), Amazon S3 ne facture pas le propriétaire du compartiment lorsque la demande est initiée en dehors du AWS compte individuel du propriétaire du compartiment ou de l' AWS organisation 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 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 de refus d’accès (HTTP 403 Forbidden) pour les demandes adressées aux ressources du même Compte AWS. 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 AWS CloudTrail journaux. Les messages d'erreur de refus d'accès améliorés pour les demandes portant sur le même compte sont désormais disponibles dans toutes les régions Régions AWS, y compris en Chine AWS GovCloud (US) Regions et en 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 reçoit pas d’accès, action est l’action de service refusée par la politique, et resource-arn est l’ARN de la ressource sur laquelle la politique 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. Les demandes intercomptes 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.

  • 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. Recherchez une Deny déclaration pour l'action dans vos politiques de contrôle des ressources (RCPs). 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 qu'il n'y a pas de Allow déclaration manquante concernant l'action dans vos politiques de contrôle des services (SCPs). 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. Recherchez une Deny déclaration pour l'action dans vos politiques de contrôle des services (SCPs). 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 votre Deny instruction pour utiliser la clé de aws:PrincipalAccount condition avec l'opérateur de StringNotEquals condition afin d'autoriser l'accès principal spécifique, comme indiqué dans aws:PrincipalAccountdans 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 politiques 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 politiques 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 votre Deny instruction pour utiliser la clé de aws:PrincipalAccount condition avec l'opérateur de StringNotEquals condition afin d'autoriser l'accès principal spécifique, comme indiqué dans aws:PrincipalAccountdans 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 politiques relatives aux compartiments, les politiques relatives aux points d'accès, les politiques utilisateur IAM, les autorisations relatives aux objets ou les listes de contrôle d'accès (ACLs) pour autoriser l'accès public. Les paramètres d'accès public de S3 Block remplacent ces politiques, autorisations et ACLs. 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 bucket ou à un AWS compte complet. 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— Ce IgnorePublicAcls paramètre oblige Amazon S3 à ignorer tout ACLs le public d'un bucket et tous les objets 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 blocked by the BlockPublicPolicy block public 
access setting.

  • RestrictPublicBuckets— Le RestrictPublicBuckets paramètre restreint l'accès à un point d'accès ou à un bucket soumis à une politique publique uniquement aux Service AWS principaux et aux utilisateurs autorisés du compte du propriétaire du bucket 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 Service AWS les 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.

Politiques de compartiment et politiques IAM

Opérations au niveau des compartiments

Si aucune politique 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 utilisateur IAM n'est en place, le demandeur (sauf s'il s'agit de l'utilisateur Compte AWS root) se voit implicitement refuser le droit 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.

Opérations au niveau de l’objet

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). Toutefois, si aucune politique utilisateur IAM n'est en place, le demandeur (sauf s'il s'agit de l'utilisateur Compte AWS root) se voit implicitement refuser le droit de faire des demandes d'objet.

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 aux objets (ACLs). 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 afficher ou modifier une politique de compartiment, vous devez disposer de l’autorisation s3:GetBucketPolicy.

  1. Connectez-vous à la console Amazon S3 AWS Management Console et ouvrez-la à 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 ou modifier votre politique de compartiment à l'aide du AWS Command Line Interface (AWS CLI), utilisez le get-bucket-policycommande.

Note

Si l'accès à un compartiment est bloqué en raison d'une politique de compartiment incorrecte, connectez-vous au en AWS Management Console utilisant vos informations d'identification d'utilisateur Compte AWS root. Pour accéder de nouveau à votre bucket, assurez-vous de supprimer la politique de bucket 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 ACL, vérifiez d'abord votre paramètre de propriété des objets pour vérifier s'ils ACLs sont activés sur le bucket. Sachez que les autorisations ACL ne peuvent être utilisées que pour accorder des autorisations et ne peuvent pas être utilisées pour rejeter des demandes. ACLs ne peut pas non plus être utilisé pour accorder l'accès à des demandeurs rejetés par des refus explicites dans les politiques de compartiment ou les politiques utilisateur IAM.

Le propriétaire du compartiment impose le paramètre de propriété de l’objet

Si le paramètre imposé par le propriétaire du compartiment est activé, il est peu probable que les paramètres ACL provoquent une erreur d'accès refusé (403 Interdit) car ce paramètre désactive tout ce ACLs qui s'applique au compartiment et aux objets. L’application du propriétaire du compartiment est le paramètre par défaut (et recommandé) pour les compartiments Amazon S3.

Le paramètre de propriété de l’objet est défini sur le propriétaire du compartiment préféré ou le rédacteur d’objets

Les autorisations des listes ACL sont toujours valides avec le paramètre du propriétaire du compartiment préféré ou le paramètre du rédacteur d’objets. Il en existe deux types ACLs : le bucket ACLs et l'object ACLs. Pour les différences entre ces deux types de ACLs, voir Cartographie des autorisations ACL et des autorisations de politique 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 à l'objet ACLs, 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, ACLs accordez des autorisations explicites pour les GET demandes 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 ACLs (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 ACLs. Pour plus d’informations sur la façon de configurer votre compartiment en mode imposé (recommandé) par le propriétaire du compartiment, consultez Définition de la propriété d’un objet sur un compartiment existant.

    Important

    Pour éviter une erreur d'accès refusé (403 Interdit), veillez à migrer les autorisations ACL vers une politique de compartiment avant de les désactiver ACLs. 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 de propriété de l’objet du compartiment en fonction du 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 de propriété de l’objet sur le propriétaire du compartiment préféré, le paramètre 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 Accès refusé (403 Interdit), ajoutez le demandeur en tant que bénéficiaire pour accéder à l'objet dans celui de l'objet. ACLs Pour de plus amples informations, veuillez consulter Configuration ACLs.

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 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 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 console Amazon S3 AWS Management Console et ouvrez-la à 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 du AWS CLI, utilisez get-bucket-encryptioncommande.

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

  1. Connectez-vous à la console Amazon S3 AWS Management Console et ouvrez-la à 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. 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 l'état du chiffrement de votre objet à l'aide du AWS CLI, utilisez head-objectcommande.

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 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 un Clé gérée par AWS) — Le demandeur doit être associé au même compte que celui qui possède la aws/s3 clé 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, Amazon S3 renvoie une erreur d’accès refusé (403 Forbidden) lorsque vous essayez de supprimer l’objet.

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

  1. Connectez-vous à la console Amazon S3 AWS Management Console et ouvrez-la à 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 de l'utilisateur Compte AWS root, entraînera une erreur d'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. Assurez-vous toutefois 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. Une fois que vous lancez une session privilégiée, vous pourrez supprimer la politique 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 AWS Identity and Access Management l'utilisateur.

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.

  • 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 identifiant de demande Amazon S3 et contactez-nous Support pour obtenir des conseils supplémentaires.