Evaluación de políticas de IAM y denegación explícita

Uso de la seguridad de AWS para desarrolladores

Rahul Singh

Technical Product Manager

Una política es una lista de reglas

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

Tres campos de una declaración de IAM apilados en una única columna y numerados del uno al tres: Effect es allow o deny, Action es qué llamada a la API y Resource a qué recurso apunta, nombrado por un ARN.

Una política es una lista de reglas

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

Cuatro campos de una declaración de IAM apilados en una sola columna y numerados del uno al cuatro: Effect es allow o deny, Action es qué llamada a la API, Resource es a qué recurso apunta nombrado por un ARN, y Condition son las circunstancias requeridas. Una línea final dice: cuatro campos, una regla.

Tres campos preguntan, uno responde

La pregunta

Action: ¿es esta la llamada?
Resource: ¿es este el destino?
Condition: ¿coinciden las condiciones?

La respuesta

Effect: allow o deny

Los cuatro campos de una declaración de IAM apilados verticalmente: Action, Resource y Condition agrupados por un corchete etiquetado «La pregunta», y Effect agrupado por un segundo corchete etiquetado «La respuesta».

Las reglas vienen de más de un sitio

Un documento de política adjunto a un rol, con una flecha desde el rol hacia un bucket.

Basadas en identidad

Adjuntas al rol
¿Qué puede hacer este rol?

Las reglas vienen de más de un sitio

Un documento de política adjunto a un rol, con una flecha desde el rol hacia un bucket.

Un documento de política adjunto a un recurso, con una flecha desde el principal hacia un bucket.

Basadas en identidad

Adjuntas al rol
Qué puede hacer este rol

Basadas en recursos

Adjuntas al recurso de destino
Quién puede acceder a este bucket

Cuando las reglas discrepan

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

Cuando las reglas discrepan

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

Solicitud: s3:DeleteObject da como resultado: Denied.

Una denegación explícita prevalece sobre cualquier allow, por amplio que sea

Una declaración allow y una deny confluyen en una única solicitud; la ruta de deny se resalta y el resultado se marca como denied.

Orden de evaluación y denegación implícita

Diagrama de flujo de evaluación de políticas de IAM: una solicitud de API verifica si hay un deny explícito aplicable, luego un allow aplicable, y llega a un deny implícito si no encuentra ninguno.

Denegación explícita: algo dijo no
Allow: algo dijo sí y nada dijo no
Denegación implícita: nadie dijo nada

Cuatro solicitudes, tres resultados

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

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

s3:GetObject → allow: el allow amplio lo cubre
s3:DeleteObject → denegación explícita: una declaración dice que no
kms:Decrypt, dynamodb:GetItem → denegación implícita: esta política no menciona esos servicios
KMS guarda claves de cifrado; DynamoDB es una base de datos clave-valor gestionada

Por qué añadir permisos suele fallar

Mismo error, dos causas

Denegación explícita

Otro allow no cambia nada
Encuentra el deny y delimítalo o quítalo

Denegación implícita

Un allow concreto y estrecho
En la identidad que hizo la llamada

Un error AccessDenied se bifurca en dos causas. A la izquierda, se encontró un deny, así que más allows no cambian nada. A la derecha, no se encontró allow, así que un allow concreto en la identidad que llama lo resuelve.

¡Vamos a practicar!

Uso de la seguridad de AWS para desarrolladores