Maîtrise d'AWS IAM : Résoudre efficacement les erreurs d'accès refusé

Les erreurs AWS IAM AccessDenied signifient qu'AWS a évalué votre demande et n'a trouvé aucun chemin d'autorisation effectif. La solution la plus rapide n'est pas de deviner une politique plus large. Il s'agit d'identifier l'action exacte, la ressource, le principal et le contexte de condition qu'AWS a évalués.

La plupart des échecs IAM proviennent de l'un des quatre endroits suivants : aucune Allow correspondante, un Deny explicite, une limite d'autorisations ou une politique de contrôle de service limitant l'identité, ou une condition qui ne correspond pas à la demande.

Commencez par la logique d'évaluation IAM

AWS part d'un refus par défaut. Une demande n'est autorisée que lorsqu'une politique applicable l'autorise et qu'aucune politique applicable ne la refuse.

Un Deny explicite l'emporte sur toute Allow. Ce refus peut provenir d'une politique d'identité, d'une politique de ressource, d'une limite d'autorisations, d'une politique de session, d'une politique de contrôle de service ou d'un autre type de politique applicable.

Pour un accès au sein du même compte, les politiques d'identité et les politiques de ressource fonctionnent souvent ensemble. Pour un accès entre comptes, vous avez généralement besoin d'autorisations des deux côtés : l'identité de l'appelant doit être autorisée à faire la demande, et la ressource cible ou le compte cible doit faire confiance ou autoriser cet appelant.

Capturez la demande exacte qui a échoué

Avant de modifier les politiques, capturez ces détails :

• Principal : utilisateur, rôle, session de rôle assumé ou principal de service AWS.
• Action : l'opération API, comme s3:GetObject ou ec2:RunInstances.
• Ressource : l'ARN ou l'ID de ressource.
• Région et compte.
• Conditions : IP source, point de terminaison VPC, MFA, tags, contexte de chiffrement ou région demandée.

CloudTrail est généralement la meilleure source. Recherchez l'événement ayant échoué autour de l'heure de l'erreur et inspectez eventName, userIdentity, resources, errorCode et errorMessage.

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=RunInstances \
  --max-results 10

CloudTrail n'explique pas chaque décision d'autorisation dans les moindres détails, mais il vous donne souvent l'action manquante et le véritable principal. Cela suffit à lui seul pour détecter de nombreuses confusions de rôles assumés et de noms de session.

Utilisez les outils de simulation et d'analyse d'accès

Le simulateur de politique IAM peut tester de nombreuses questions de politique basées sur l'identité avant de modifier les autorisations de production. Sélectionnez l'utilisateur ou le rôle, choisissez l'action de service, fournissez l'ARN de la ressource lorsque c'est possible et incluez les clés de condition pertinentes.

Pour les comptes et services AWS récents, vérifiez également le message d'accès refusé lui-même. Certains services renvoient un message d'échec d'autorisation encodé. Si vous avez l'autorisation, décodez-le avec STS :

aws sts decode-authorization-message \
  --encoded-message '<message-encodé-depuis-erreur>'

Ce message décodé peut montrer quel type de politique a contribué au refus.

IAM Access Analyzer est utile pour les questions de politique de ressource et entre comptes. Il peut vous aider à trouver un accès externe non intentionnel et à valider certaines politiques avant le déploiement.

Vérifiez chaque couche de politique

Les politiques basées sur l'identité sont attachées aux utilisateurs, groupes et rôles. Elles répondent à ce que l'identité peut faire.

Les politiques basées sur les ressources sont attachées aux ressources telles que les compartiments S3, les clés KMS, les files d'attente SQS, les fonctions Lambda et les politiques de confiance des rôles. Elles répondent à qui peut utiliser cette ressource ou assumer ce rôle.

Les limites d'autorisations définissent les autorisations maximales pour un utilisateur ou un rôle. Elles n'accordent pas d'accès par elles-mêmes. Les autorisations effectives sont l'intersection de la politique d'identité et de la limite.

Les politiques de contrôle de service dans AWS Organizations définissent les autorisations maximales pour les comptes ou les unités organisationnelles. Les SCP n'accordent pas non plus d'accès par elles-mêmes. Elles peuvent bloquer une action même lorsqu'une politique IAM l'autorise.

Les politiques de session et les tags d'autorisation peuvent également réduire l'accès pour les sessions de rôle assumé. Si un rôle fonctionne dans un chemin mais échoue lorsqu'il est assumé par un travail CI, comparez la politique de session, les tags de session et les conditions de la politique de confiance.

Modèles courants d'AccessDenied

Actions dépendantes manquantes

Certaines opérations AWS nécessitent plus que l'action évidente. Par exemple, lancer une instance EC2 chiffrée peut nécessiter des autorisations EC2 plus des autorisations KMS pour la clé. CloudTrail et la documentation du service sont vos meilleures références pour les actions dépendantes.

Mauvais ARN de ressource

Les ARN au niveau du compartiment S3 et au niveau de l'objet sont différents :

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::mon-compartiment/*"
}

arn:aws:s3:::mon-compartiment couvre le compartiment. arn:aws:s3:::mon-compartiment/* couvre les objets dans le compartiment. De nombreuses erreurs S3 proviennent de l'octroi de l'un lorsque l'appel API a besoin de l'autre.

Non-concordance des conditions

Les conditions doivent correspondre exactement au contexte de la demande. Une politique qui autorise l'accès uniquement via un point de terminaison VPC refusera les demandes provenant d'un autre point de terminaison, du point de terminaison public AWS ou d'une région différente si la condition vérifie cette région.

{
  "Effect": "Deny",
  "Action": "s3:*",
  "Resource": [
    "arn:aws:s3:::mes-données-sensibles",
    "arn:aws:s3:::mes-données-sensibles/*"
  ],
  "Condition": {
    "Bool": {
      "aws:SecureTransport": "false"
    }
  }
}

Cette instruction refuse les requêtes HTTP et autorise les requêtes HTTPS à continuer via le reste de l'évaluation de la politique. Elle n'accorde pas d'accès par elle-même.

Lacunes dans la politique de clé KMS

KMS est une source courante d'erreurs d'accès déroutantes. Une politique IAM peut autoriser kms:Decrypt, mais la politique de clé doit également autoriser le principal directement ou autoriser le compte à déléguer l'accès via les politiques IAM.

Vérifiez la politique de clé, les subventions, les conditions de contexte de chiffrement et le service utilisant la clé.

Un flux de dépannage pratique

D'abord, reproduisez ou capturez l'appel défaillant. Obtenez l'action API exacte et le principal depuis CloudTrail.

Ensuite, recherchez les refus explicites dans les SCP, les politiques de ressource, les limites d'autorisations et les politiques d'identité. Les refus explicites font gagner du temps car ils remplacent tout le reste.

Confirmez ensuite qu'il existe une autorisation correspondante pour l'action et la ressource exactes. Incluez les actions dépendantes et les ressources connexes telles que les clés KMS, les rôles IAM transmis aux services, les interfaces réseau ou les groupes de journaux.

Enfin, testez avec le changement de politique le plus restreint possible. Évitez de corriger un refus inconnu avec Action: "*" ou Resource: "*" ; cela cache le problème et crée un nouveau risque de sécurité.

La bonne habitude est de traiter chaque AccessDenied comme un problème de preuve. Une fois que vous connaissez le principal, l'action, la ressource et la couche de politique, la correction est généralement petite et claire.