Comment résoudre les messages d'erreur de refus explicites lorsque je demande des appels d'API à l'aide de rôles ou d'utilisateurs IAM ?

Lecture de 8 minute(s)
0

J'ai reçu un message d'erreur de refus explicite lorsque j'ai demandé un appel d'API à l'aide d'un rôle ou d'un utilisateur AWS Identity and Access Management (IAM). Comment puis-je résoudre les problèmes et les messages d'erreur de refus explicites ?

Brève description

Pour qu'une entité IAM (rôle ou utilisateur) puisse effectuer un appel d'API réussi, l'entité doit remplir les conditions suivantes :

  • Le rôle ou l'utilisateur dispose des autorisations appropriées pour demander un appel d'API.
  • L'autorisation n'est refusée par aucune déclaration dans toutes les politiques applicables au contexte de la demande.

Si votre entité IAM ne remplit pas ces conditions, l'appel d'API échoue et génère une erreur (AccessDenied) similaire à celle-ci :

  • Utilisateur ou rôle IAM rencontrant le problème : arn:XXXXXXXX:iam::XXXXXXXX:role/TestReadOnly

Erreur : une erreur s'est produite (AccessDenied) lors de l'appel de l'opération RunInstances : User: arn:aws:iam::XXXXXXXX:user/tester n'est pas autorisé à effectuer : ec2:RunInstances on resource: role TestReadOnly avec un refus explicite

Remarque : Les étapes de résolution de problèmes décrites dans cet article concernent spécifiquement les erreurs de refus explicites et non les erreurs de refus implicites. Pour plus d'informations sur les erreurs de refus implicites, consultez La différence entre les refus implicites et explicites.

Solution

Des erreurs de refus explicites se produisent en raison de problèmes dans une ou plusieurs des politiques suivantes :

  • Politiques basées sur une identité
  • Politiques basées sur les ressources
  • Limite des autorisations
  • Politiques de contrôle des services
  • Politique de session

Politiques basées sur une identité

La politique basée sur une identité contrôle l'action autorisée/refusée d'une entité. Utilisez ces étapes de résolution de problèmes pour identifier les problèmes liés aux politiques basées sur une identité.

Remarque : il est recommandé d'utiliser Deny avec StringNotLike pour empêcher l'accès privilégié accidentel.

1.    Vérifiez qu'aucune déclaration de refus ne figure dans la politique basée sur une identité. Cet exemple contient une déclaration de refus :

{
  "Effect": "Deny",
  "Action": "iam:DeleteRole"
  "Resource": "*"
}

2.    Vérifiez si l'authentification multifactorielle (MFA) est appliquée à votre politique. Si votre entité IAM s'authentifie sans utiliser d'autre facteur d'authentification lorsque l'authentification MFA est appliquée, l'autorisation est refusée. Par exemple, si votre entité s'authentifie à l'aide d’AWS CLI sans MFA, votre appel d'API est refusé. Consultez cet exemple d'application MFA :

{
  "Sid": "DenyAllExceptListedIfNoMFA",
  "Effect": "Deny",
  "NotAction": [
    "iam:CreateVirtualMFADevice",
    "iam:EnableMFADevice",
    "iam:GetUser",
    "iam:ListMFADevices",
    "iam:ListVirtualMFADevices",
    "iam:ResyncMFADevice",
    "sts:GetSessionToken"
  ],
  "Resource": "*",
  "Condition": {
    "BoolIfExists": {"aws:MultiFactorAuthPresent": "false"}
  }
}

Cette politique refuse explicitement tous les appels d'API, à l'exception de ceux qui sont mentionnés dans l'élément de politique NotAction.

3.    Assurez-vous que votre politique répond à toutes les conditions requises. Si votre politique comporte plusieurs opérateurs de condition ou plusieurs clés, les conditions sont évaluées à l'aide de la logique AND. Chaque clé RequestTag doit être utilisée dans des instructions distinctes pour obtenir la même logique AND. Voici un exemple de problème courant entraînant l'échec de l'appel d'API :

{
  "Sid": "AllowRunInstancesWithRestrictions2",
  "Effect": "Deny",
  "Action": [
    "ec2:CreateVolume",
    "ec2:RunInstances"
  ],
  "Resource": [
    "arn:aws:ec2:*:*:volume/*",
    "arn:aws:ec2:*:*:instance/*"
  ],
  "Condition": {
    "ForAllValues:StringNotLike": {
      "aws:TagKeys": "Production"
    },
    "StringEquals": {
      "ec2:InstanceType": "t2.micro"
    }
  }
}

Pour éviter une erreur de refus d'accès explicite pour ces appels d'API, assurez-vous que la condition précédente est remplie.

Remarque : La condition aws:TagKeys est sensible à la casse.

Politiques basées sur les ressources

La politique basée sur les ressources autorise ou refuse l'accès à une ressource. Contrairement aux politiques basées sur une identité IAM qui sont unifiées, les politiques basées sur les ressources sont conçues par les services. Les étapes de résolutions de problèpmes suivantes utilisent les politiques basées sur les ressources Amazon Simple Storage Service (Amazon S3) et une politique de point de terminaison d'un VPC comme exemple.

Évaluation de la politique relative au compartiment S3

L'évaluation de la politique relative au compartiment Amazon S3 fonctionne comme suit :

Remarque : Cela suppose que l’ACL du compartiment est définie par défaut.

  • Pour accéder à un compartiment dans le même compte, une entité IAM a besoin d'autorisations dans la politique basée sur une identité IAM OU la politique relative au compartiment.
  • Pour accéder à un compartiment dans un autre compte, une entité IAM a besoin d'autorisations dans la politique relative au compartimentET la politique basée sur une identité IAM pour y accéder.

1.    Vérifiez les déclarations de refus dans la politique basée sur les ressources. Cet exemple montre une déclaration de refus dans la politique relative au compartiment :

{
  "Effect": "deny",
  "Principal": {
    "AWS": "arn:aws:iam::111111111111:role/ROLENAME"
  },
  "Action": "s3:ListBucket",
  "Resource": "arn:aws:s3:::MyExampleBucket"
}

2.    Vérifiez que les ARN décrits dans la politique sont corrects.

3.    La politique relative au compartiment refuse l'accès si le aws:userid de l'utilisateur actuel ne correspond pas à ce qui est défini dans la politique. Consultez cet exemple :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::MyExampleBucket",
        "arn:aws:s3:::MyExampleBucket/*"
      ],
      "Condition": {
        "StringNotLike": {
          "aws:userId": [
            "AROAEXAMPLEID:*",
            "AIDAEXAMPLEID",
            "111111111111"
          ]
        }
      }
    }
  ]
}

Point de terminaison d'un VPC

Une politique de point de terminaison d'un VPC est une politique de ressources IAM attachée à un point de terminaison. Cette politique ne remplace pas les politiques des utilisateurs IAM ou les politiques spécifiques aux services (telles que les politiques relatives au compartiment S3).

Il existe deux manières de contrôler l'accès à vos données Amazon S3 lorsque vous utilisez un point de terminaison d'interface pour vous connecter à Amazon S3 :

  • Vous pouvez contrôler les principaux AWS (comptes AWS, utilisateurs IAM, et rôles IAM) qui peuvent utiliser le point de terminaison d’un VPC pour accéder au service de point de terminaison.
  • Vous pouvez contrôler les VPC ou les points de terminaison d’un VPC qui ont accès aux compartiments à l'aide des politiques relative au compartiment Amazon S3.

L'exemple ci-dessous est une politique relative au compartiment Amazon S3. La politique restreint l'accès à un compartiment spécifique, appelé examplebucket, à partir du point de terminaison d’un VPC avec l'ID vpce-11111. La politique refuse tout accès au compartiment si le point de terminaison spécifié n'est pas utilisé. La condition aws:SourceVpce est utilisée pour spécifier le point de terminaison.

{
   "Version": "2012-10-17",
   "Id": "Policy123456789”,
   "Statement": [
     {
       "Sid": "AccessSpecificVPCEOnly",
       "Principal": "*",
       "Action": "s3:*",
       "Effect": "Deny",
       "Resource": ["arn:aws:s3:::examplebucket",
                    "arn:aws:s3:::examplebucket/*"],
       "Condition": {
         "StringNotEqualsIfExists": {
           "aws:SourceVpce": "vpce-11111”
         }
       }
     }
   ]
}

Vérifiez toujours que le point de terminaison d’un VPC ne refuse pas explicitement l'accès à la ressource.

Limite des autorisations

La limite des autorisations est une politique gérée qui définit les autorisations maximales qu'une identité IAM peut recevoir d'une stratégie basée sur une identité. Cette politique gérée peut limiter les autorisations aux entités, ce qui peut entraîner des messages d'erreur de refus explicites.

Cet exemple montre une action autorisée dans la politique IAM mais qui est explicitement refusée dans la limite des autorisations. Consultez la limite des autorisations ci-dessous :

{
  "Version": "2012-10-17",

  "Statement": [

    {
      "Effect": "Deny",
      "Action": "ec2:*"

      "Resource": "*"
    }
  ]
}

L'utilisateur dispose des autorisations suivantes :

{
  "Version": "2012-10-17",
  
  "Statement": {
    "Effect": "Allow",
    "Action": "ec2:RunInstances",
    
    "Resource": "*"
  }
}

Bien que l'utilisateur dispose de l'autorisation RunInstances, il reçoit un message de refus explicite lorsqu'il le demande. Pour résoudre cette erreur, assurez-vous que la limite d'autorisations et l’IAM autorisent explicitement cette action.

Politiques de contrôle des services

Une politique de contrôle des services (SCP) vous permet de gérer les autorisations au sein de votre organisation. L'exemple suivant montre une déclaration de refus dans la politique SCP. Dans cet exemple, la politique SCP est associée à un compte de membre ou à une unité organisationnelle (UO) particulière. Elle refuse explicitement l'accès à l'action RunInstances :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "ec2:RunInstances"

      "Resource": "*"
    }
  ]
}

Pour résoudre les erreurs de refus explicites, effectuez l'une des actions suivantes :

  • Détachez la politique SCP du compte.
  • Modifiez la déclaration de refus en ajoutant une condition qui exclut certains cas d'utilisation. Par exemple, dans cet exemple, la politique SCP ne refuse PAS ec2:RunInstances si le principal IAM utilise le rôle CloudOps :
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "ec2:RunInstances"     
      "Resource": "*",
      "Condition": {
        "ArnNotLike": {
          "aws:PrincipalARN": "arn:aws:iam::*:role/CloudOps"
        }
      }
    }
  ]
}

Politiques de session

Les politiques de session sont des politiques avancées que vous transmettez en tant que paramètre lorsque vous créez par programme une session temporaire pour un rôle ou un utilisateur. Vous pouvez créer une session de rôle et transmettre des politiques de session à l'aide des opérations d'API AssumeRole, AssumeRoleWithSAML, ou AssumeRoleWithWebIdentity.

Par exemple, cette politique génère l'erreur de refus explicite lorsque l'utilisateur essaie d'effectuer un appel d'API RunInstances. Vérifiez toujours les déclarations de refus dans la politique de session :

{
  "Version": "2012-10-17",
  
  "Statement": {
    "Effect": "Deny",
    "Action": "ec2:RunInstances",
    
    "Resource": "*"
  }
}

Informations connexes

Gestion des accès pour les ressources AWS

Comment utiliser des politiques de contrôle des services pour définir des protections par autorisation dans les comptes de votre organisation AWS

Limites d'autorisations pour les entités IAM

Comment limiter l'accès d'un compartiment Amazon S3 à un rôle IAM spécifique

Contrôle de l'accès à partir des points de terminaison d'un VPC avec des stratégies de compartiment

AWS OFFICIEL
AWS OFFICIELA mis à jour il y a 2 ans