Résoudre les messages d'erreur liés au refus d'accès

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

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

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.

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 la résolution SCP des problèmes. Une fois que vous avez identifié le type de politique, vous pouvez vérifier s'il n'y a pas de déclarations de refus ou d'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 des politiques d'un IAM utilisateur, d'un groupe ou d'un rôle, consultezGestion des IAM politiques.

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 lorsque l'mateojacksonIAMutilisateur tente d'utiliser la console pour afficher les détails d'une my-example-widget ressource fictive mais ne dispose pas des widgets:GetWidget autorisations 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 qui prend en charge les politiques basées sur les ressources, tel qu'Amazon S3SNS, Amazon 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-key globale 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 le maximum d'autorisations qu'un IAM principal (utilisateur ou rôle) peut avoir. 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 le AWS SDKs), vérifiez que vous les avez correctement signées.

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 de plus amples informations, veuillez consulter Informations d'identification de sécurité temporaires dans IAM.

Vérifiez que l'IAMutilisateur ou le rôle dispose des autorisations appropriées. Les autorisations relatives aux informations d'identification de sécurité temporaires sont dérivées d'un IAM utilisateur ou d'un rôle. 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 JSON de session en ligne à l'aide du Policy paramètre. 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'IAMutilisateur, 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 session qui en résultent sont à l'intersection de vos politiques basées sur IAM l'identité utilisateur 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/*"]
  }]
}