Dominando AWS IAM: Solución Efectiva de Errores de Acceso Denegado

Los errores AccessDenied de AWS IAM significan que AWS evaluó tu solicitud y no encontró una ruta de permiso efectiva. La solución más rápida no es adivinar una política más amplia. Es identificar la acción exacta, el recurso, el principal y el contexto de condición que AWS evaluó.

La mayoría de las fallas de IAM provienen de uno de cuatro lugares: falta de Allow coincidente, un Deny explícito, un límite de permisos o una política de control de servicios que limita la identidad, o una condición que no coincide con la solicitud.

Comienza con la Lógica de Evaluación de IAM

AWS comienza con una denegación predeterminada. Una solicitud se permite solo cuando una política aplicable la permite y ninguna política aplicable la deniega.

Un Deny explícito prevalece sobre cualquier Allow. Esa denegación puede provenir de una política de identidad, política de recursos, límite de permisos, política de sesión, política de control de servicios u otro tipo de política aplicable.

Para el acceso dentro de la misma cuenta, las políticas de identidad y las políticas de recursos a menudo trabajan juntas. Para el acceso entre cuentas, generalmente necesitas permiso en ambos lados: la identidad del llamante debe tener permiso para realizar la solicitud, y el recurso de destino o la cuenta de destino debe confiar o permitir a ese llamante.

Captura la Solicitud Fallida Exacta

Antes de editar políticas, captura estos detalles:

• Principal: usuario, rol, sesión de rol asumido o principal de servicio de AWS.
• Acción: la operación de la API, como s3:GetObject o ec2:RunInstances.
• Recurso: el ARN o ID del recurso.
• Región y cuenta.
• Condiciones: IP de origen, endpoint de VPC, MFA, etiquetas, contexto de cifrado o región solicitada.

CloudTrail suele ser la mejor fuente. Busca el evento fallido alrededor del momento del error e inspecciona eventName, userIdentity, resources, errorCode y errorMessage.

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

CloudTrail no explica cada decisión de autorización con perfecto detalle, pero a menudo te da la acción faltante y el principal real. Eso por sí solo detecta muchos errores de roles asumidos y nombres de sesión.

Usa Herramientas de Simulación y Análisis de Acceso

El Simulador de Políticas de IAM puede probar muchas preguntas de políticas basadas en identidad antes de cambiar los permisos de producción. Selecciona el usuario o rol, elige la acción del servicio, proporciona el ARN del recurso cuando sea posible e incluye las claves de condición relevantes.

Para cuentas y servicios recientes de AWS, también verifica el mensaje de acceso denegado en sí. Algunos servicios devuelven un mensaje de error de autorización codificado. Si tienes permiso, decodifícalo con STS:

aws sts decode-authorization-message \
  --encoded-message '<mensaje-codificado-del-error>'

Ese mensaje decodificado puede mostrar qué tipo de política contribuyó a la denegación.

IAM Access Analyzer es útil para preguntas sobre políticas de recursos y entre cuentas. Puede ayudarte a encontrar acceso externo no intencionado y validar algunas políticas antes de la implementación.

Verifica Cada Capa de Política

Las políticas basadas en identidad se adjuntan a usuarios, grupos y roles. Responden qué puede hacer la identidad.

Las políticas basadas en recursos se adjuntan a recursos como buckets de S3, claves de KMS, colas de SQS, funciones de Lambda y políticas de confianza de roles. Responden quién puede usar ese recurso o asumir ese rol.

Los límites de permisos establecen los permisos máximos para un usuario o rol. No otorgan acceso por sí mismos. Los permisos efectivos son la intersección de la política de identidad y el límite.

Las políticas de control de servicios en AWS Organizations establecen permisos máximos para cuentas o unidades organizativas. Las SCP tampoco otorgan acceso por sí mismas. Pueden bloquear una acción incluso cuando una política de IAM la permite.

Las políticas de sesión y las etiquetas de permiso también pueden reducir el acceso para sesiones de roles asumidos. Si un rol funciona en una ruta pero falla cuando lo asume un trabajo de CI, compara la política de sesión, las etiquetas de sesión y las condiciones de la política de confianza.

Patrones Comunes de AccessDenied

Acciones Dependientes Faltantes

Algunas operaciones de AWS requieren más que la acción obvia. Por ejemplo, lanzar una instancia EC2 cifrada puede requerir permisos de EC2 más permisos de KMS para la clave. CloudTrail y la documentación del servicio son tus mejores referencias para acciones dependientes.

ARN de Recurso Incorrecto

Los ARN a nivel de bucket de S3 y a nivel de objeto son diferentes:

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

arn:aws:s3:::my-bucket cubre el bucket. arn:aws:s3:::my-bucket/* cubre objetos en el bucket. Muchos errores de S3 provienen de otorgar uno cuando la llamada a la API necesita el otro.

Discrepancia de Condición

Las condiciones deben coincidir exactamente con el contexto de la solicitud. Una política que permite el acceso solo a través de un endpoint de VPC denegará solicitudes desde otro endpoint, desde el endpoint público de AWS o desde una región diferente si la condición verifica esa región.

{
  "Effect": "Deny",
  "Action": "s3:*",
  "Resource": [
    "arn:aws:s3:::my-sensitive-data",
    "arn:aws:s3:::my-sensitive-data/*"
  ],
  "Condition": {
    "Bool": {
      "aws:SecureTransport": "false"
    }
  }
}

Esa declaración deniega solicitudes HTTP y permite que las solicitudes HTTPS continúen a través del resto de la evaluación de la política. No otorga acceso por sí misma.

Brechas en la Política de Claves de KMS

KMS es una fuente común de errores de acceso confusos. Una política de IAM puede permitir kms:Decrypt, pero la política de claves también debe permitir al principal directamente o permitir que la cuenta delegue acceso a través de políticas de IAM.

Verifica la política de claves, las concesiones, las condiciones del contexto de cifrado y el servicio que usa la clave.

Un Flujo Práctico de Solución de Problemas

Primero, reproduce o captura la llamada fallida. Obtén la acción exacta de la API y el principal de CloudTrail.

A continuación, busca denegaciones explícitas en SCP, políticas de recursos, límites de permisos y políticas de identidad. Las denegaciones explícitas ahorran tiempo porque anulan todo lo demás.

Luego, confirma que hay un Allow coincidente para la acción y el recurso exactos. Incluye acciones dependientes y recursos relacionados como claves de KMS, roles de IAM pasados a servicios, interfaces de red o grupos de registros.

Finalmente, prueba con el cambio de política más estrecho posible. Evita arreglar una denegación desconocida con Action: "*" o Resource: "*"; eso oculta el problema y crea un nuevo riesgo de seguridad.

El hábito útil es tratar cada AccessDenied como un problema de evidencia. Una vez que conoces el principal, la acción, el recurso y la capa de política, la solución suele ser pequeña y clara.