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

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

Un refus implicite se produit lorsqu'il n'y a ni d'instruction Deny applicable ni d'instruction Allow applicable. Comme une politique 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 en savoir plus, consultez Différence entre les refus explicites et implicites.

Si plusieurs politiques du même type refusent une requête, le message d’erreur « accès refusé » ne précise pas le nombre de politiques évaluées.

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

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 avez identifié le type de politique, vous pouvez vérifier les déclarations de refus ou les actions d’autorisation manquantes dans ces types de politique. 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.

Si l'outil AWS Management Console renvoie un message qui indique que vous n'êtes pas autorisé à exécuter 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 services qui fonctionnent avec IAM.

Si votre politique inclut une condition avec une paire clé-valeur, vérifiez-la attentivement. Les exemples contiennent la clé de condition globale aws:RequestTag/tag-key, la clé AWS KMS kms:EncryptionContext:encryption_context_key et la clé de condition ResourceTag/tag-key prise 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 Éléments de politique JSON IAM : 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 la manière dont AWS évalue ces politiques, veuillez consulter Logique 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.

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 message d'accès refusé lorsque j'effectue une demande à un service AWS.

Pour vérifier que le service accepte les informations d'identification de sécurité temporaires, veuillez consulter AWS 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 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 programmation à l'aide de l'outil AWS STS, vous pouvez, si vous le souhaitez, 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 à AWS en 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 Demande d’informations d’identification via un fournisseur 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 à amzn-s3-demo-bucket.

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