Résolution des problèmes liés aux messages d'erreur d'accès rejeté

Les erreurs d'accès refusé 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. Comme une politique IAM refuse un principal IAM par défaut, elle doit autoriser explicitement le principal à effectuer une action. Dans le cas contraire, la politique refuse implicitement l'accès. Pour plus d’informations, consultez Différence entre les refus explicites et implicites.

Si plusieurs politiques du même type de politique refusent une demande d'autorisation, AWS ne précise pas le nombre dans le message d'erreur d'accès refusé. Si plusieurs types de politiques refusent une demande d'autorisation, n' AWS inclut qu'un seul de ces types de politique dans le message d'erreur.

Important

Vous rencontrez des difficultés pour vous connecter à AWS ? Assurez-vous que vous êtes sur la bonne page de connexion AWS pour votre type d'utilisateur. Si vous êtes le Utilisateur racine d'un compte AWS (propriétaire du compte), vous pouvez vous connecter à AWS l'aide des informations d'identification que vous avez définies lors de la création du Compte AWS. Si vous êtes un utilisateur IAM, votre administrateur de compte peut vous fournir les informations d'identification que vous pouvez utiliser pour vous connecter à AWS. Si vous avez besoin d'assistance, n'utilisez pas le lien de commentaires sur cette page, car le formulaire est reçu par l'équipe de AWS documentation AWS Support. Sur la page Contactez-nous, sélectionnez Impossible de vous connecter à votre AWS compte, puis choisissez l'une des options d'assistance disponibles.

Je reçois un « accès refusé » lorsque je fais une demande à un AWS service

• Vérifiez si le message d'erreur inclut le type de politique responsable du refus d'accès. Par exemple, si l'erreur indique que l'accès est refusé en raison d'une politique de contrôle des services (SCP), vous pouvez vous concentrer sur le dépannage des problèmes SCP. Une fois que vous connaissez le type de politique, vous pouvez rechercher une instruction de refus ou une autorisation manquante sur l'action spécifique dans les politiques de ce type. Si le message d'erreur n'indique pas le type de politique responsable du refus d'accès, utilisez les autres instructions de cette section pour effectuer un dépannage plus approfondi.

• Vérifiez que vous avez l'autorisation de politique basée sur l'identité d'appeler l'action et la ressource que vous avez demandées. Si des conditions sont définies, vous devez également respecter ces conditions lorsque vous envoyez la demande. Pour plus d'informations sur l'affichage ou la modification de politiques pour un utilisateur, un groupe ou un rôle IAM, veuillez consulter Gestion des politiques IAM.

• S'il AWS Management Console renvoie un message indiquant que vous n'êtes pas autorisé à effectuer une action, vous devez contacter votre administrateur pour obtenir de l'aide. Votre administrateur vous a fourni vos informations de connexion ou votre lien de connexion.

  L'exemple d'erreur suivant se produit quand l'utilisateur IAM mateojackson tente d'utiliser la console pour afficher des informations détaillées sur une ressource my-example-widget fictive, mais ne dispose pas des autorisations widgets:GetWidget fictives.

  User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: widgets:GetWidget on resource: my-example-widget

  Dans ce cas, Mateo doit demander à son administrateur de mettre à jour ses politiques pour lui permettre d'accéder à la ressource my-example-widget à l'aide de l'action widgets:GetWidget.

• Essayez-vous d'accéder à un service prenant en charge des politiques basées sur les ressources, tel que Amazon S3, Amazon SNS ou Amazon SQS ? Si tel est le cas, vérifiez que la politique vous spécifie comme principal et vous accorde l'accès. Si vous effectuez une demande à un service dans votre compte, vos politiques basées sur une identité ou sur les ressources peuvent vous accorder l'autorisation. Si vous effectuez une demande à un service dans un autre compte, vos politiques basées sur une identité et sur les ressources doivent vous accorder l'autorisation. Pour afficher les services qui prennent en charge les politiques basées sur les ressources, veuillez consulter AWS des services qui fonctionnent avec IAM.

• Si votre politique inclut une condition avec une paire clé-valeur, vérifiez-la attentivement. Les exemples incluent la clé de condition aws:RequestTag/tag-keyglobale AWS KMS kms:EncryptionContext:encryption_context_key, la clé de condition et la clé de ResourceTag/tag-key condition prises en charge par plusieurs services. Assurez-vous que le nom de clé ne correspond pas à plusieurs résultats. Les noms de clé de condition n'étant pas sensibles à la casse, une condition qui vérifie une clé nommée foo correspond à foo, Foo, ou FOO. Si votre demande comprend plusieurs paires clé-valeur avec des noms de clé qui ne diffèrent que par la casse, votre accès pourrait être inopinément refusé. Pour plus d'informations, veuillez consulter IAMJSONéléments de politique : Condition.

• Si vous disposez d'une limite d'autorisations, vérifiez que la politique utilisée pour cette dernière autorise votre demande. Si vos politiques basées sur l'identité permettent la demande, mais pas votre limite d'autorisations, la demande est refusée. Une limite d'autorisations contrôle les autorisations maximum dont peut disposer un principal IAM (utilisateur ou rôle). Les politiques basées sur les ressources ne sont pas limitées par des limites d'autorisations. Les limites d'autorisations ne sont pas courantes. Pour plus d'informations sur le mode AWS d'évaluation des politiques, consultezLogique d'évaluation de politiques.

• Si vous signez des demandes manuellement (sans utiliser les kits SDK AWS), vérifiez que vous avez correctement signé la demande.

Je reçois un message d'accès refusé lorsque j'effectue une demande avec des informations d'identification de sécurité temporaires

• Tout d'abord, assurez-vous que l'accès ne vous est pas refusé pour une raison non liée à vos informations d'identification temporaires. Pour plus d'informations, veuillez consulter Je reçois un « accès refusé » lorsque je fais une demande à un AWS service.

• Pour vérifier que le service accepte les informations d'identification de sécurité temporaires, veuillez consulter AWS des services qui fonctionnent avec IAM.

• Vérifiez que vos demandes sont signées correctement et que la demande est correctement formée. Pour en savoir plus, veuillez consulter la documentation de votre boîte à outils ou Utilisation d'informations d'identification temporaires avec des ressources AWS.

• Vérifiez que vos informations d'identification de sécurité temporaires ne sont pas arrivées à expiration. Pour plus d'informations, veuillez consulter Informations d'identification de sécurité temporaires dans IAM.

• Vérifiez que l'utilisateur ou le rôle IAM dispose des autorisations adéquates. Les autorisations pour les informations d'identification de sécurité temporaires sont dérivées d'un utilisateur ou d'un rôle IAM. Par conséquent, les autorisations sont limitées à celles qui sont accordées au rôle dont vous avez utilisé les informations d'identification temporaires. Pour de plus amples informations sur la définition des autorisations des informations d'identification de sécurité temporaires, veuillez consulter Contrôle des autorisations affectées aux informations d'identification de sécurité temporaires.

• Si vous avez endossé un rôle, votre session de rôle peut être limitée par les politiques de session. Lorsque vous demandez des informations d'identification de sécurité temporaires par le biais d'un programme AWS STS, vous pouvez éventuellement transmettre des politiques de session en ligne ou gérées. Les politiques de session sont des politiques avancées que vous transmettez en tant que paramètre lorsque vous créez par programmation une session d'informations d'identification temporaires pour un rôle. Vous pouvez transmettre un seul document de politique de session en ligne JSON à l'aide du paramètre Policy. Vous pouvez utiliser le paramètre PolicyArns pour spécifier jusqu'à 10 politiques de session gérées. Les autorisations de la session obtenues sont une combinaison des politiques basées sur l'identité du rôle et des politiques de session. Sinon, si votre administrateur ou un programme personnalisé vous fournit des informations d'identification temporaires, ils peuvent avoir inclus une politique de session pour limiter votre accès.

• Si vous êtes un utilisateur fédéré, votre session peut être limitée par les politiques de session. Vous devenez un utilisateur fédéré en vous connectant en AWS tant qu'utilisateur IAM, puis en demandant un jeton de fédération. Pour de plus amples informations sur les utilisateurs fédérés, veuillez consulter GetFederationToken : fédération via un broker d'identité personnalisé. Si vous ou votre broker d'identité avez transmis des politiques de session lorsque vous avez demandé un jeton de session, votre session est limitée par ces politiques. Les autorisations de la session obtenues sont une combinaison des politiques basées sur l'identité de l'utilisateur IAM et des politiques de session. Pour de amples informations sur les politiques de session, veuillez consulter Politiques de session.

• Si vous accédez à une ressource disposant d'une politique basée sur une ressource à l'aide d'un rôle, vérifiez que la politique accorde des autorisations au rôle. Par exemple, la politique suivante autorise MyRole du compte 111122223333 à accéder à MyBucket.

  {
    "Version": "2012-10-17",
    "Statement": [{
      "Sid": "S3BucketPolicy",
      "Effect": "Allow",
      "Principal": {"AWS": ["arn:aws:iam::111122223333:role/MyRole"]},
      "Action": ["s3:PutObject"],
      "Resource": ["arn:aws:s3:::MyBucket/*"]
    }]
  }

Exemples de messages d'erreur d'accès refusé

La plupart des messages d'erreur d'accès refusé se présentent sous le format User user is not authorized to perform action on resource because context. Dans cet exemple, user (utilisateur) est le Amazon Resource Name (ARN) qui ne reçoit pas d'accès, action est l'action de service refusée par la politique, et ressource est l'ARN de la ressource sur laquelle la politique agit. Le champ de context (contexte) 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, elle AWS inclut la phrase with an explicit deny in a type policy dans le message d'erreur d'accès refusé. Lorsque la politique refuse implicitement l'accès, AWS inclut la phrase because no type policy allows the action action dans le message d'erreur d'accès refusé.

Note

Certains AWS services ne prennent pas en charge ce format de message d'erreur de refus d'accès. Le contenu des messages d'erreur d'accès refusé peut varier en fonction du service à l'origine de la demande d'autorisation.

Les exemples suivants montrent le format pour différents types de messages d'erreur d'accès refusé.

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 codecommit:ListRepositories.

2. Mettez à jour votre SCP en ajoutant l'instruction Allow. Pour plus d'information, consultez la section relative aux mises à jour Over-the-Air dans le AWS Organizations User Guide.

User: arn:aws:iam::777788889999:user/JohnDoe is not authorized to perform:
codecommit:ListRepositories because no service control policy allows the codecommit:ListRespositories action

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

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

2. Mettez à jour votre SCP en supprimant l'instruction Deny. Pour plus d'information, consultez la section relative aux mises à jour Over-the-Air dans le AWS Organizations User Guide.

User: arn:aws:iam::777788889999:user/JohnDoe is not authorized to perform: 
codecommit:ListRepositories 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 vos politiques de point de terminaison de cloud privé virtuel (VPC). Pour l'exemple suivant, l'action est codecommit:ListRepositories.

2. Mettez à jour la politique de point de terminaison d'un VPC en ajoutant l'instruction Allow. Pour plus d'informations, veuillez consulter 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/JohnDoe is not authorized to perform: 
codecommit:ListRepositories because no VPC endpoint policy allows the codecommit:ListRepositories 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 vos politiques de point de terminaison de cloud privé virtuel (VPC). Pour l'exemple suivant, l'action est codedeploy:ListDeployments.

2. Mettez à jour la politique de point de terminaison d'un VPC en supprimant l'instruction Deny. Pour plus d'informations, veuillez consulter 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/JohnDoe is not authorized to perform: 
codedeploy:ListDeployments on resource: arn:aws:codedeploy:us-east-1:123456789012:deploymentgroup:* 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 codedeploy:ListDeployments.

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 de politiques IAM.

User: arn:aws:iam::123456789012:user/JohnDoe is not authorized to perform: 
codedeploy:ListDeployments on resource: arn:aws:codedeploy:us-east-1:123456789012:deploymentgroup:* because no permissions boundary allows the codedeploy:ListDeployments 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 sagemaker:ListModels.

2. Mettez à jour votre limite des autorisations en supprimant l'instruction Deny de votre politique IAM. Pour plus d’informations, consultez Limites d'autorisations pour les entités IAM et Modification de politiques IAM.

User: arn:aws:iam::777788889999:user/JohnDoe is not authorized to perform: 
sagemaker:ListModels 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 codecommit:ListRepositories.

2. Mettez à jour votre politique de session en ajoutant l'instruction Allow. Pour plus d'informations, veuillez consulter les rubriques Politiques de session et Modification de politiques IAM.

User: arn:aws:iam::123456789012:user/JohnDoe is not authorized to perform: 
codecommit:ListRepositories because no session policy allows the codecommit:ListRepositories 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 codedeploy:ListDeployments.

2. Mettez à jour votre politique de session en supprimant l'instruction Deny. Pour plus d'informations, veuillez consulter les rubriques Politiques de session et Modification de politiques IAM.

User: arn:aws:iam::123456789012:user/JohnDoe is not authorized to perform: 
codedeploy:ListDeployments on resource: arn:aws:codedeploy:us-east-1:123456789012:deploymentgroup:* with an explicit deny in a sessions policy

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

1. Vérifiez l'absence d'une instruction Allow pour l'action dans votre politique basée sur les ressources. Pour l'exemple suivant, l'action est secretsmanager:GetSecretValue.

2. Mettez à jour votre politique en ajoutant l'instruction Allow. Pour plus d'informations, veuillez consulter les rubriques Politiques basées sur les ressources et Modification de politiques IAM.

User: arn:aws:iam::123456789012:user/JohnDoe is not authorized to perform: 
secretsmanager:GetSecretValue because no resource-based policy allows the secretsmanager:GetSecretValue action

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

1. Vérifiez la présence d'une instruction Deny explicite pour l'action dans votre politique basée sur les ressources. Pour l'exemple suivant, l'action est secretsmanager:GetSecretValue.

2. Mettez à jour votre politique en supprimant l'instruction Deny. Pour plus d'informations, veuillez consulter les rubriques Politiques basées sur les ressources et Modification de politiques IAM.

User: arn:aws:iam::123456789012:user/JohnDoe is not authorized to perform: 
secretsmanager:GetSecretValue on resource: arn:aws:secretsmanager:us-east-1:123456789012:secret:* with an explicit deny in a resource-based policy

Accès refusé en raison de politiques d'approbation de rôle : refus implicite

1. Vérifiez l'absence d'une instruction Allow pour l'action dans votre politique d'approbation de rôle. Pour l'exemple suivant, l'action est sts:AssumeRole.

2. Mettez à jour votre politique en ajoutant l'instruction Allow. Pour plus d'informations, veuillez consulter les rubriques Politiques basées sur les ressources et Modification de politiques IAM.

User: arn:aws:iam::123456789012:user/JohnDoe is not authorized to perform: 
sts:AssumeRole because no role trust policy allows the sts:AssumeRole action

Accès refusé en raison de politiques d'approbation de rôle : refus explicite

1. Vérifiez la présence d'une instruction Deny explicite pour l'action dans votre politique d'approbation de rôle. Pour l'exemple suivant, l'action est sts:AssumeRole.

2. Mettez à jour votre politique en supprimant l'instruction Deny. Pour plus d'informations, veuillez consulter les rubriques Politiques basées sur les ressources et Modification de politiques IAM.

User: arn:aws:iam::777788889999:user/JohnDoe is not authorized to perform: 
sts:AssumeRole with an explicit deny in the role trust 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 codecommit:ListRepositories attachée à l'utilisateur JohnDoe.

2. Mettez à jour votre politique en ajoutant l'instruction Allow. Pour plus d'informations, veuillez consulter les rubriques Politiques basées sur l'identité et Modification de politiques IAM.

User: arn:aws:iam::123456789012:user/JohnDoe is not authorized to perform: 
codecommit:ListRepositories because no identity-based policy allows the codecommit:ListRepositories 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 codedeploy:ListDeployments attachée à l'utilisateur JohnDoe.

2. Mettez à jour votre politique en supprimant l'instruction Deny. Pour plus d'informations, veuillez consulter les rubriques Politiques basées sur l'identité et Modification de politiques IAM.

User: arn:aws:iam::123456789012:user/JohnDoe is not authorized to perform: 
codedeploy:ListDeployments on resource: arn:aws:codedeploy:us-east-1:123456789012:deploymentgroup:* with an explicit deny in an identity-based policy

Accès refusé lorsqu'une requête VPC échoue en raison d'une autre politique

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

2. Mettez à jour votre SCP en supprimant l'instruction Deny. Pour plus d'information, consultez la section relative aux mises à jour Over-the-Air dans le AWS IAM Identity Center User Guide.

User: arn:aws:sts::111122223333:assumed-role/role-name/role-session-name is not authorized to perform: 
SNS:Publish on resource: arn:aws:sns:us-east-1:444455556666:role-name-2 
with an explicit deny in a VPC endpoint policy transitively through a service control policy