Évaluation des stratégies IAM et refus explicite

Utiliser la sécurité AWS pour les développeurs

Rahul Singh

Technical Product Manager

Une stratégie est une liste de règles

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::reports/*",
  "Condition": {
    "Bool": {
      "aws:SecureTransport": "true"
    },
    "IpAddress": {
      "aws:SourceIp": "203.0.113.0/24"
    }
  }
}

Trois champs d'une déclaration IAM empilés sur une même colonne et numérotés de un à trois : Effect est allow ou deny, Action est l'appel d'API, et Resource est la cible nommée par un ARN.

Une stratégie est une liste de règles

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::reports/*",
  "Condition": {
    "Bool": {
      "aws:SecureTransport": "true"
    },
    "IpAddress": {
      "aws:SourceIp": "203.0.113.0/24"
    }
  }
}

Quatre champs d'une déclaration IAM empilés et numérotés de un à quatre : Effect est allow ou deny, Action est l'appel d'API, Resource est la cible nommée par un ARN, et Condition précise les circonstances requises. Une ligne de clôture indique : quatre champs, une règle.

Trois champs posent la question, un champ répond

La question

Action : est-ce l'appel
Resource : est-ce la cible
Condition : les circonstances concordent-elles

La réponse

Effect : allow ou deny

Les quatre champs d'une déclaration IAM empilés verticalement : Action, Resource et Condition regroupés par une accolade intitulée « La question », et Effect regroupé par une seconde accolade intitulée « La réponse ».

Les règles proviennent de plus d'un endroit

Un document de stratégie attaché à un rôle, avec une flèche du rôle vers un compartiment.

Axée sur l'identité

Attachée au rôle
Que peut faire ce rôle ?

Les règles proviennent de plus d'un endroit

Un document de stratégie attaché à un rôle, avec une flèche du rôle vers un compartiment.

Un document de stratégie attaché à une ressource, avec une flèche du principal vers un compartiment.

Axée sur l'identité

Attachée au rôle
Que peut faire ce rôle ?

Axée sur la ressource

Attachée à l'élément visé
Qui peut accéder à ce compartiment

Quand les règles se contredisent

{"Effect": "Allow", "Action": "s3:*", "Resource": "*"}
{"Effect": "Deny",  "Action": "s3:DeleteObject", "Resource": "*"}

Quand les règles se contredisent

{"Effect": "Allow", "Action": "s3:*", "Resource": "*"}
{"Effect": "Deny",  "Action": "s3:DeleteObject", "Resource": "*"}

Requête : s3:DeleteObject donne : refusé.

Un refus explicite l'emporte sur tout allow, même très large

Une déclaration allow et une déclaration deny alimentent une même requête ; le chemin deny est accentué et le résultat est refusé.

Ordre d'évaluation et refus implicite

Organigramme de l'évaluation des stratégies IAM : une requête d'API vérifie d'abord un refus explicite applicable, puis un allow applicable, et aboutit à un refus implicite si aucun n'est trouvé.

Refus explicite : quelque chose a dit non
Allow : quelque chose a dit oui, et rien n'a dit non
Refus implicite : rien n'a rien dit

Quatre requêtes, trois issues

{"Effect": "Allow", "Action": "s3:*",
 "Resource": "*"}

{"Effect": "Deny", "Action": "s3:DeleteObject",
 "Resource": "*"}

s3:GetObject → allow : l'allow large le couvre
s3:DeleteObject → refus explicite : une déclaration dit non
kms:Decrypt, dynamodb:GetItem → refus implicite : cette stratégie ne mentionne pas ces services
KMS gère les clés de chiffrement ; DynamoDB est une base de données clé‑valeur gérée

Pourquoi ajouter des permissions échoue souvent

Même erreur, deux causes

Refus explicite

Un autre allow ne change rien
Repérer le deny, puis le restreindre ou le retirer

Refus implicite

Un allow ciblé suffit
Sur l'identité qui a fait l'appel

Une erreur AccessDenied se divise en deux causes. À gauche, un deny a été trouvé ; d'autres allow ne changent rien. À droite, aucun allow n'a été trouvé ; un allow ciblé sur l'identité appelante règle le problème.

Passons à la pratique !

Utiliser la sécurité AWS pour les développeurs