Résoudre les erreurs d'accès refusé (403 Forbidden) 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.

Dans la mesure AWS Identity and Access Management où une politique (IAM) refuse implicitement un IAM principal par défaut, la politique doit explicitement autoriser le principal à effectuer une action. Dans le cas contraire, la politique refuse implicitement l'accès. Pour plus d'informations, voir La différence entre les refus explicites et implicites dans le Guide de IAM l'utilisateur. 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 la section Logique d'évaluation des politiques dans le guide de IAM l'utilisateur.

Les rubriques suivantes présentent les causes les plus courantes d'erreurs de refus d'accès 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 Exemples de messages refusés et comment les résoudre section, puis passez à la Politiques et IAM politiques relatives aux compartiments section. Assurez-vous également de suivre les instructions figurant dansConseils pour vérifier les autorisations.

Exemples de messages refusés et comment les résoudre

Important

À compter du 21 août 2024, des messages d'erreur de refus d'accès améliorés pour les demandes portant sur le même compte seront disponibles dans les semaines à venir. Ces messages seront disponibles dans toutes les régions Régions AWS, y compris dans les régions 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, nom d'utilisateur est le nom de ressource Amazon (ARN) de l'utilisateur qui ne reçoit pas l'accès, action est l'action de service refusée par la politique, et source de ressources est ARN la ressource sur laquelle la politique agit. Le context le champ représente un contexte supplémentaire sur le type de politique qui explique pourquoi la politique a refusé l'accès.

Lorsqu'une politique refuse explicitement l'accès parce qu'elle contient une Deny instruction, le message d'erreur d'accès refusé inclut la phrasewith an explicit deny in a type policy. Lorsque la politique refuse implicitement l'accès, le message d'erreur d'accès refusé inclut la phrasebecause 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 portant sur le même compte. Les demandes entre comptes 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, voir Logique d'évaluation des politiques entre comptes dans le guide de l'IAMutilisateur. Pour une procédure pas à pas expliquant comment accorder un accès entre comptes, voir. 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é ne sont pas renvoyés pour les demandes adressées aux compartiments de répertoire. Les demandes de bucket d'annuaire renvoient un Access Denied message générique.

• Si plusieurs politiques du même type de politique refusent une demande d'autorisation, le message d'erreur Accès refusé ne précise pas le nombre de politiques.

• Si plusieurs types de politiques refusent une demande d'autorisation, le message d'erreur inclut uniquement l'un de ces types de politique.

• Si une demande d'accès est refusée pour plusieurs raisons, le message d'erreur inclut uniquement l'une des raisons du refus.

Les exemples suivants montrent le format des différents types de messages d'erreur de refus d'accès et indiquent comment résoudre chaque type de message.

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 déclaration en SCP ajoutant la Allow déclaration. Pour plus d'informations, consultez la section Mise à jour d'un SCP dans le guide de AWS Organizations l'utilisateur.

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 déclaration en SCP supprimant la Deny déclaration. Pour plus d'informations, consultez la section Mise à jour d'un SCP dans le guide de AWS Organizations l'utilisateur.

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 relative aux VPC terminaux : refus implicite

1. Vérifiez qu'il n'y a pas de Allow déclaration manquante concernant l'action dans les politiques de point de terminaison de votre cloud privé virtuel (VPC). Pour l'exemple suivant, l'action est s3:GetObject.

2. Mettez à jour votre politique de VPC point de terminaison en ajoutant la Allow déclaration. Pour plus d'informations, voir Mettre à jour une politique de VPC point de terminaison dans le AWS PrivateLink Guide.

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 relative aux VPC terminaux : refus explicite

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

2. Mettez à jour votre politique relative aux VPC terminaux en supprimant l'Denyinstruction. Pour plus d'informations, voir Mettre à jour une politique de VPC point de terminaison dans le AWS PrivateLink Guide.

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 vos limites d'autorisations en ajoutant la Allow déclaration à votre IAM politique. Pour plus d'informations, consultez les sections Limites d'autorisations pour les IAM entités et IAMRègles de modification dans le Guide de IAM l'utilisateur.

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 vos limites d'autorisations en supprimant la Deny déclaration de votre IAM politique. Pour plus d'informations, consultez les sections Limites d'autorisations pour les IAM entités et IAMRègles de modification dans le Guide de IAM l'utilisateur.

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 les sections Politiques de session et IAMPolitiques de modification dans le Guide de IAM l'utilisateur.

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 votre politique de session en supprimant l'instruction Deny. Pour plus d'informations, consultez les sections Politiques de session et IAMPolitiques de modification dans le Guide de IAM l'utilisateur.

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 désignent des politiques telles que les politiques de compartiment 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 IgnorePublicAcls S3 Block Public Access est appliqué au niveau du bucket, 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 les sections Politiques basées sur les ressources et Politiques d'édition IAM dans le Guide de l'IAMutilisateur.

   Vous devrez peut-être également ajuster votre paramètre de IgnorePublicAcls blocage de l'accès public pour le bucket, le point d'accès ou le compte. Pour plus d’informations, consultez Accès refusé en raison des 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 désignent des politiques telles que les politiques de compartiment 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 RestrictPublicBuckets S3 Block Public Access est appliqué au niveau du bucket, du point d'accès ou du compte. Pour l'exemple suivant, l'action est s3:GetObject.

2. Mettez à jour votre politique en supprimant l'instruction Deny. Pour plus d'informations, consultez les sections Politiques basées sur les ressources et Politiques d'édition IAM dans le Guide de l'IAMutilisateur.

   Vous devrez peut-être également ajuster votre paramètre de RestrictPublicBuckets blocage de l'accès public pour le bucket, le point d'accès ou le compte. Pour plus d’informations, consultez Accès refusé en raison des 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 attachée à l'utilisateurMaryMajor.

2. Mettez à jour votre politique en ajoutant l'instruction Allow. Pour plus d'informations, consultez les sections Politiques basées sur l'identité et Politiques de modification IAM dans le Guide de l'IAMutilisateur.

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é. Dans l'exemple suivant, l'action est s3:GetObject attachée à l'utilisateurMaryMajor.

2. Mettez à jour votre politique en supprimant l'instruction Deny. Pour plus d'informations, consultez les sections Politiques basées sur l'identité et Politiques de modification IAM dans le Guide de l'IAMutilisateur.

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 des 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 IAM utilisateur, 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 etACLs. 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 Amazon S3 Block Public Access sont les suivants :

• BlockPublicAcls— Ce paramètre s'applique aux PutBucketAclPutObjectAcl,PutObject, CreateBucketCopyObject, et POST Object aux demandes. Ce BlockPublicAcls paramètre entraîne le comportement suivant :

  • PutBucketAclet PutObjectAcl les appels échouent si la liste de contrôle d'accès spécifiée (ACL) est publique.

  • PutObjectles appels échouent si la demande inclut un message publicACL.

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

  Par exemple, lorsque l'accès à une CopyObject demande est refusé en raison du BlockPublicAcls paramètre, 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 n'est accordée que par un publicACL, le IgnorePublicAcls paramètre rejette la demande.

  Tout refus résultant du IgnorePublicAcls réglage est implicite. Par exemple, si une IgnorePublicAcls GetObject demande est refusée en raison d'un publicACL, 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 PutAccessPointPolicy demandes PutBucketPolicy et aux demandes.

  La définition BlockPublicPolicy d'un compartiment entraîne le rejet par Amazon S3 des appels PutBucketPolicy si la politique de compartiment spécifiée autorise l'accès public. Ce paramètre oblige également Amazon S3 à rejeter les appels PutAccessPointPolicy destinés à tous les points d'accès du même compte du compartiment si la politique spécifiée autorise l'accès public.

  La configuration BlockPublicPolicy d'un point d'accès entraîne le rejet par Amazon S3 des appels vers PutAccessPointPolicy et PutBucketPolicy passés par le point d'accès si 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é à une PutBucketPolicy demande en raison du BlockPublicPolicy paramètre, 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 AWS service 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 AWS service 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 RestrictPublicBuckets réglage est explicite. Par exemple, si une RestrictPublicBuckets GetObject demande est refusée en raison d'une politique de bucket 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, consultezConfiguration du blocage d'accès public.

Politiques et IAM politiques relatives aux compartiments

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 AWS Identity and Access Management (IAM) identité du compte du propriétaire du compartiment. Le bucket refuse également implicitement les demandes provenant de toute autre IAM identité provenant d'autres comptes, ainsi que les demandes anonymes (non signées). Toutefois, si aucune politique IAM utilisateur 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, voir Déterminer si une demande est refusée ou autorisée au sein d'un compte dans le Guide de IAM l'utilisateur.

Opérations au niveau de l'objet

Si l'objet appartient au compte propriétaire du compartiment, la politique du compartiment et la politique IAM utilisateur 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'objets provenant de n'importe quelle IAM identité du compte du propriétaire du compartiment. Le bucket refuse également implicitement les demandes d'objets provenant de toute autre IAM identité provenant d'autres comptes, ainsi que les demandes anonymes (non signées). Toutefois, si aucune politique IAM utilisateur 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 de compartiment et la politique IAM utilisateur 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 IAM utilisateur ne provoque pas d'erreur d'accès refusé (403 Interdit), assurez-vous que les conditions suivantes sont remplies :

• Pour l'accès à un même compte, il ne doit pas y avoir de Deny déclaration explicite contre le demandeur auquel vous essayez d'accorder des autorisations, que ce soit dans la politique du bucket ou dans la politique utilisateur. IAM Si vous souhaitez accorder des autorisations en utilisant uniquement la politique de compartiment et la politique IAM utilisateur, l'une de ces politiques doit comporter au moins une Allow déclaration explicite.

• Pour l'accès entre comptes, il ne doit pas y avoir de Deny déclaration explicite contre le demandeur auquel vous essayez d'accorder des autorisations, que ce soit dans la politique du compartiment ou dans la politique IAM utilisateur. Pour accorder des autorisations entre comptes en utilisant uniquement la politique de compartiment et la politique IAM utilisateur, assurez-vous que la politique de compartiment et la politique IAM utilisateur du demandeur incluent une déclaration expliciteAllow.

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 stratégie de compartiment.

4. Choisissez l’onglet Permissions (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 de la AWS Command Line Interface (AWS CLI), utilisez la 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 :

• Identifiez le demandeur. S'il s'agit d'une demande non signée, il s'agit d'une demande anonyme sans politique d'IAMutilisation. S'il s'agit d'une demande qui utilise un présignéURL, la politique utilisateur est la même que celle de l'IAMutilisateur ou du rôle qui a signé la demande.

• Vérifiez que vous utilisez le bon IAM utilisateur ou le bon rôle. Vous pouvez vérifier votre IAM utilisateur ou votre rôle en cochant le coin supérieur droit du AWS Management Console ou en utilisant la aws sts get-caller-identitycommande.

• Vérifiez les IAM politiques liées à l'IAMutilisateur ou au rôle. Vous pouvez choisir l'une des méthodes suivantes :

  • Testez IAM les politiques avec le simulateur IAM de politiques.

  • Passez en revue les différents types de IAM politiques.

• Si nécessaire, modifiez votre politique IAM d'utilisation.

• Consultez les exemples suivants de politiques qui refusent ou autorisent explicitement l'accès :

  • Politique IAM d'autorisation explicite des utilisateurs IAM: autorise et refuse l'accès à plusieurs services par programmation et dans la console

  • Politique d'autorisation explicite en matière de compartiment : octroi d'autorisations à plusieurs comptes pour télécharger des objets ou définir un objet ACLs pour un accès public

  • Politique de refus explicite des IAM utilisateurs AWS: refuse l'accès à la AWS base de la demande Région AWS

  • Politique de refus explicite du compartiment : obligatoire SSE - KMS pour tous les objets écrits dans un compartiment

ACLParamètres Amazon S3

Lorsque vous vérifiez vos ACL paramètres, vérifiez d'abord le paramètre de propriété de l'objet pour vérifier s'ils ACLs sont activés dans le compartiment. Sachez que ACL les autorisations ne peuvent être utilisées que pour accorder des autorisations et ne peuvent pas être utilisées pour rejeter des demandes. ACLsne 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 IAM utilisateur.

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 ACL paramètres 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

ACLles autorisations sont toujours valides avec le paramètre préféré du propriétaire du compartiment ou le paramètre du rédacteur d'objets. Il en existe deux types ACLs : un ACLs godet et un objetACLs. Pour connaître les différences entre ces deux types de autorisationsACLs, voir Cartographie des ACL autorisations et autorisations liées à la politique d'accès.

En fonction de l'action de la demande rejetée, vérifiez les ACL autorisations associées à votre bucket ou à l'objet :

• Si Amazon S3 a rejeté un LIST PUT objet ou une PutBucketAcl demandeGetBucketAcl, passez en revue les ACL autorisations associées à votre compartiment.

  Note

  Vous ne pouvez pas accorder d'autorisations GET d'objets avec les ACL paramètres du bucket.

• Si Amazon S3 a rejeté une GET demande concernant un PutObjectAclobjet S3, vérifiez les ACL autorisations associées à l'objet.

  Important

  Si le compte qui détient l'objet est différent du compte qui détient le compartiment, l'accès à l'objet n'est pas contrôlé par la politique de compartiment.

Résolution d'une erreur d'accès refusé (403 interdit) 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 ACL paramètre 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 interdit) :

• 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 ACL autorisations vers une politique de compartiment avant de les désactiverACLs. Pour plus d'informations, consultez les exemples de politique de bucket pour la migration à partir d'ACLautorisations.

• 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 PUT frais 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 télécharger à nouveau avec l'bucket-owner-full-controlobjet prédéfiniACL.

  Note

  Pour les téléchargements entre comptes, vous pouvez également exiger que l'objet bucket-owner-full-control prédéfini figure ACL 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 la demande échouée implique un accès public ou des politiques publiques, vérifiez les paramètres S3 Block Public Access sur votre compte, compartiment ou point d'accès. Pour plus d'informations sur la résolution des erreurs de refus d'accès liées aux paramètres S3 Block Public Access, consultezAccès refusé en raison des 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 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 à 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 de AWS CLI, utilisez la 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 de AWS CLI, utilisez la 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 des clés fournies par le client (-C) SSE

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 correspondante AWS KMS key est requise. Pour télécharger des objets et effectuer des chargements partitionnés d'objets, l'kms:Decryptautorisation sur la KMS clé est requise.

• SSE- KMS (avec un Clé gérée par AWS) — Le demandeur doit être titulaire du même compte que celui qui possède la aws/s3 KMS clé. 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 politique en matière de KMS clés vous autorise à effectuer les kms:Decrypt actions kms:GenerateDataKey ou. Pour obtenir des instructions sur la vérification de votre politique KMS clé, consultez la section Afficher une politique clé dans le guide du AWS Key Management Service développeur.

Paramètres de verrouillage des objets S3

Si le verrouillage des objets S3 est activé sur votre compartiment et que l'objet est protégé par une période de conservation ou une mise en suspens juridique, Amazon S3 renvoie une erreur d'accès refusé (403 interdit) 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 conservation ou une mise en suspens juridique, consultez les informations de verrouillage de votre objet.

Si l'objet est protégé par une période de conservation ou une mise en suspens juridique, 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 d'un 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 mise en suspens juridique, une demande DELETE permanente peut entraîner une erreur d'accès refusé (403 interdit). Pour supprimer définitivement la version de l'objet, vous devez supprimer la mise en suspens juridique sur la version de l'objet. Pour supprimer une mise en suspens juridique, vous devez avoir l'autorisation s3:PutObjectLegalHold. Pour plus d'informations sur la suppression d'une mise en suspens juridique, consultez Configuration du verrouillage d’objet S3.

VPCpolitique relative aux terminaux

Si vous accédez à Amazon S3 via un point de terminaison de cloud privé virtuel (VPC), assurez-vous que la politique relative aux points de VPC terminaison ne vous empêche pas d'accéder à vos ressources Amazon S3. Par défaut, la politique relative aux VPC terminaux autorise toutes les demandes adressées à Amazon S3. Vous pouvez également configurer la politique du VPC point de terminaison pour restreindre certaines demandes. Pour plus d'informations sur la façon de vérifier votre politique de point de VPC terminaison, consultez la section Contrôler l'accès aux VPC points de terminaison à l'aide des politiques de point de terminaison dans le AWS PrivateLink Guide.

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 la section Liste de toutes les politiques dans le guide de AWS Organizations l'utilisateur.

Paramètres du point d'accès

Si vous recevez un message d'erreur d'accès refusé (403 interdit) 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 IAM utilisateur 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 VPCcomme 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 point d'accès spécifiéVPC. 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 à Amazon S3 avec succès à l'aide de points d'accès, assurez-vous que le demandeur dispose des IAM autorisations nécessaires. Pour de plus amples informations, veuillez consulter Configuration des IAM politiques d'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 AWS Support pour obtenir des conseils supplémentaires.