Évaluation des stratégies IAM et refus explicite

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 un même axe 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 (allow ou deny), Action (quel appel d'API), Resource (quelle cible, nommée par un ARN) et Condition (dans quelles circonstances). Une ligne de fin indique : quatre champs, une règle.

Trois champs questionnent, un champ répond

La question

Action : est-ce l'appel ?
Resource : est-ce la cible ?
Condition : les circonstances correspondent-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 viennent de plusieurs endroits

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

Basée sur l'identité

Attachée au rôle
Ce que ce rôle peut faire

Les règles viennent de plusieurs endroits

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

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

Basée sur l'identité

Attachée au rôle
Ce que ce rôle peut faire

Basée sur la ressource

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

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ée.

Un refus explicite l'emporte sur tout allow, aussi large soit-il

Une déclaration allow et une déclaration deny alimentent une même requête ; le chemin deny est mis en évidence et le résultat marqué « refusé ».

Ordre d'évaluation et refus implicite

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

Refus explicite : quelque chose a dit non
Autorisation : 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 → autorisé : 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 clé‑valeur managée

Pourquoi ajouter des autorisations échoue souvent

Même erreur, deux causes

Refus explicite

Un autre allow ne change rien
Trouver le deny, puis le restreindre ou le retirer

Refus implicite

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

Une erreur AccessDenied se sépare en deux causes. À gauche, un deny a été trouvé ; ajouter des allow ne change rien. À droite, aucun allow n'a été trouvé ; un allow ciblé sur l'identité appelante résout le problème.

Passons à la pratique !

Sécurité AWS pour les développeurs