Comment résoudre les problèmes d'accès refusé ou les erreurs de fonctionnement non autorisées avec une stratégie IAM ?

Date de la dernière mise à jour : 03/11/2020

Ma stratégie AWS Identity and Access Management (IAM) a renvoyé une erreur ou ne fonctionne pas comme prévu. Comment puis-je résoudre les problèmes liés à une stratégie IAM ?

Brève description

Pour résoudre les problèmes liés aux stratégies IAM :

  • Identifier l'appelant l'API
  • Évaluer la stratégie IAM
  • Exemples de dépannage des messages d'erreur de stratégie IAM

Résolution

Comprendre les messages d'erreur et identifier l'appelant API

Important :

Assurez-vous que les appels d'API sont effectués au nom de la bonne identité IAM avant d'examiner la stratégie IAM. Si le message d'erreur n'inclut pas les informations sur l'appelant, procédez comme suit afin d'identifier l'appelant API :

  1. Ouvrez AWS Management Console.
  2. En haut à droite, choisissez la flèche en regard des informations sur le compte.
  3. Si vous êtes connecté en tant que rôle IAM, choisissez la flèche en regard du nom du rôle pour les informations d'identification source, les informations de compte, le nom du rôle de destination et les informations de compte.
  4. Si vous êtes connecté en tant qu'utilisateur fédéré, votre rôle IAM est répertorié sous Connexion fédérée.

Vous pouvez utiliser la commande AWS CLI get-caller-identity pour identifier l'appelant API. Vous pouvez également utiliser la commande AWS CLI avec l'indicateur --debug pour identifier la source des informations d'identification à partir de la sortie similaire à la suivante :

2018-03-13 16:23:57,570 - MainThread - botocore.credentials - INFO - Found credentials in shared credentials file: ~/.aws/credentials

Évaluer la stratégie IAM

Vérifiez si les autorisations appropriées sont accordées à l'appelant API en vérifiant les stratégies IAM attachées. Pour plus d'informations, consultez Vérifier si une demande est autorisée ou refusée au sein d'un compte.

Après avoir vérifié que votre appelant API possède les autorisations IAM appropriées, vérifiez les autorisations au niveau des ressources. Si les actions d'API ne prennent pas en charge les autorisations au niveau des ressources, spécifiez le caractère générique * au niveau de l'élément de ressource de l'instruction IAM. Vous pouvez également afficher le récapitulatif de stratégie pour résoudre les problèmes d'autorisation au niveau des ressources. Pour afficher le récapitulatif de stratégie :

  1. Ouvrez la console IAM.
  2. Dans le panneau de navigation, choisissez Stratégies.
  3. Choisissez la flèche en regard du nom de la stratégie pour développer la vue des détails de la stratégie.
  4. Choisissez Récapitulatif de la stratégie.

Dans l'exemple suivant, la stratégie fournit uniquement l'autorisation à StartInstances, mais la stratégie n'accorde pas d'autorisation à DeleteSubnet. Étant donné que l'action DeleteSubnet ne prend pas en charge l'autorisation au niveau des ressources, vous ne pouvez pas spécifier le nom de ressource Amazon (ARN) dans l'élément ressource. Utilisez un astérisque à la place : "Resource": "*"

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PermissionNotGrantedAsAPIDoesNotSupportResourceLevelPermission",
            "Effect": "Allow",
            "Action": "ec2:DeleteSubnet",
            "Resource": "arn:aws:ec2:us-east-1:123456789012:subnet/subnet-254cf47c"
        },
        {
            "Sid": "PermissionGrantedAsAPISupportResourceLevelPermission",
            "Effect": "Allow",
            "Action": "ec2:StartInstances",
            "Resource": "arn:aws:ec2:us-east-1:123456789012:instance/i-0e58cfa95b858b1ce"
        }
    ]
}

Après avoir confirmé vos autorisations au niveau des ressources, examinez les conditions utilisées dans vos stratégies IAM. Les clés de contexte de condition globale AWS peuvent être utilisées avec tous les services AWS prenant en charge IAM pour le contrôle d'accès. Les clés de condition spécifiques au service ne peuvent être utilisées que dans les conditions spécifiques du service—EC2 aux actions API EC2. Pour plus d'informations, consultez la rubrique Actions, ressources et clés de contexte de condition pour les services AWS. Si vous utilisez plusieurs conditions, consultez la rubrique Valeurs multiples dans une condition.

Dans cet exemple de stratégie, la condition est mise en correspondance si une demande d'API IAM est appelée par l'utilisateur IAM admin et que l'adresse IP source provient de 1.1.1.0/24 ou 2.2.2.0/24.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "iam:*",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:username": "admin"
                },
                "IpAddress": {
                    "aws:SourceIp": [
                        "1.1.1.0/24",
                        "2.2.2.0/24"
                    ]
                }
            }
        }
    ]
}

Vérifiez les contrôles spécifiques au service susceptibles d'affecter les autorisations. Par exemple, les stratégies de point de terminaison d'un VPC et les politiques de contrôle des services (SCP) AWS Organizations peuvent également affecter l'évaluation des autorisations. Pour plus d'informations, consultez la section Contrôle de l'accès aux services avec des points de terminaison VPC.

Exemples de dépannage des messages d'erreur de stratégie IAM

Consultez les exemples suivants pour identifier le message d'erreur, l'appelant API, l'API et les ressources appelées :

 

Exemple de message d'erreur Appelant API API Ressources Quand
A : « Une erreur est survenue (UnauthorizedOperation) lors de l'appel de l'opération DeleteKeyPair : Vous n'êtes pas autorisé à effectuer cette opération. » inconnu DeleteKeyPair inconnu heure de l'erreur
B : « Une erreur est survenue (AccessDenied) lors de l'appel de l'opération AssumeRole : Utilisateur : arn:aws:iam::123456789012:user/test n'est pas autorisé à effectuer : sts:AssumeRole sur la ressource : arn:aws:iam::123456789012:role/EC2-FullAccess » arn:aws:iam::123456789012:user/test AssumeRole arn:aws:iam::123456789012:role/EC2-FullAccess heure de l'erreur
C : « Une erreur est survenue (AccessDenied) lors de l'appel de l'opération GetSessionToken : Impossible d'appeler GetSessionToken avec les informations d'identification de session » inconnu GetSessionToken inconnu heure de l'erreur
D : « Une erreur est survenue (UnauthorizedOperation) lors de l'appel de l'opération AssociateIamInstanceProfile : Vous n'êtes pas autorisé à effectuer cette opération. Message d'échec d'autorisation chiffré : .... » inconnu AssociateIamInstanceProfile inconnu heure de l'erreur

 

À l'aide de cette méthode d'évaluation, vous pouvez identifier la cause des messages d'erreur que vous pouvez recevoir pour des problèmes d'autorisation pour différents services AWS. Pour plus de détails, consultez les messages d'erreur courants et les étapes de dépannage qui suivent :

Exemple de message d'erreur A :

Ce message d'erreur indique que vous n'avez pas l'autorisation d'appeler l'API DeleteKeyPair.

  1. Identifiez l'appelant API.
  2. Assurez-vous que l'action de l'API ec2:DeleteKeyPair n'est pas incluse dans les instructions Deny.
  3. Assurez-vous que l'action de l'API ec2:DeleteKeyPair est incluse dans les instructions Allow.
  4. Assurez-vous qu'aucune ressource n'est spécifiée pour cette action d'API. Remarque : Cette action d'API ne prend pas en charge les autorisations au niveau des ressources.
  5. Confirmez que toutes les conditions IAM spécifiées dans l'instruction Allow sont prises en charge par l'action delete-key-pair et que les conditions correspondent.

Exemple de message d'erreur B :

Ce message d'erreur inclut le nom de l'API, l'appelant API et la ressource cible. Assurez-vous que l'identité IAM qui a appelé l'API a le bon accès aux ressources. Passez en revue les stratégies IAM à l'aide de la méthode d'évaluation précédente et évaluez les éléments suivants :

La politique de confiance du rôle IAM : EC2-FullAccess :

  1. Assurez-vous que arn:aws:iam::123456789012:user/test ou arn:aws:iam::123456789012:root n'est pas inclus dans une instruction Deny de la politique de confiance.
  2. Assurez-vous que arn:aws:iam::123456789012:user/test ou arn:aws:iam::123456789012:root est inclus dans une déclaration Allow de la politique de confiance.
  3. Assurez-vous que toutes les conditions IAM spécifiées dans cette instruction sont prises en charge par l'action de l'API sts:AssumeRole et correspondent.

Les stratégies IAM attachées à l'appelant API (arn:aws:iam::123456789012:user/test) :

  1. Assurez-vous que arn:aws:iam::123456789012:role/EC2-FullAccess n'est pas inclus dans une instruction Deny avec l'action de l'API sts:AssumeRole.
  2. Si arn:aws:iam::123456789012:root se trouve dans l'instruction Allow de la politique de confiance, assurez-vous que arn:aws:iam::123456789012:role/EC2-FullAccess est inclus dans l'instruction Allow des politiques IAM avec l'action de l'API sts:AssumeRole.
  3. Assurez-vous que toutes les conditions IAM spécifiées dans cette instruction sont prises en charge par l'action de l'API sts:AssumeRole et correspondent.

Exemple de message d'erreur C :

Ce message d'erreur indique que get-session-token n'est pas pris en charge par des informations d'identification temporaires. Pour plus d'informations, consultez la rubrique Comparaison des opérations de l'API AWS STS.

Exemple de message d'erreur D :

Ce message d'erreur renvoie un message codé qui peut fournir des détails sur l'échec de l'autorisation. Pour décoder le message d'erreur et obtenir les détails de l'échec de l'autorisation, consultez DecodeAuthorizationMessage. Après avoir décodé le message d'erreur, identifiez l'appelant API et examinez les autorisations et les conditions au niveau des ressources.

Vérifiez les autorisations de stratégie IAM :

  1. Si le message d'erreur indique que l'API est explicitement refusée, supprimez les actions d'API ec2:AssociateIamInstanceProfile ou iam:PassRole de l'instruction correspondante.
  2. Assurez-vous que ec2:AssociateIamInstanceProfile et iam:PassRole sont dans l'instruction Allow avec des cibles de ressources prises en charge et correctes. Par exemple, assurez-vous que les cibles de ressource de l'action d'API ec2:AssociateIamInstanceProfile sont des instances EC2 et que les cibles de ressources de iam:PassRole sont des rôles IAM.
  3. Si les actions d'API ec2:AssociateIamInstanceProfile et iam:PassRole sont dans la même instruction Allow, vérifiez que toutes les conditions sont prises en charge par les actions d'API ec2:AssociateIamInstanceProfile et iam:PassRole et que les conditions correspondent.
  4. Si les actions d'API ec2:AssociateIamInstanceProfile et iam:PassRole se trouvent dans des instructions Allow distinctes, vérifiez que toutes les conditions de chaque instruction Allow sont prises en charge par une action et que les conditions correspondent.