Permisos avanzados: límites, sesiones, ABAC y perímetros de datos

Con usuarios, roles y políticas de identidad resuelves una cuenta pequeña. En una organización con cien cuentas aparecen preguntas nuevas: cómo dejas que un equipo cree sus propios roles sin que se dé más poder del que tiene, cómo das acceso a un proveedor sin abrirle la puerta a otros, y cómo garantizas que ningún dato salga de la organización aunque alguien escriba una política de bucket demasiado generosa.

Esta lección parte de IAM y de Organizations y Control Tower. Si la regla «una negación explícita siempre gana» todavía no te resulta natural, repásala allí primero.

La evaluación completa de una petición

Cada llamada a AWS reúne todas las políticas que aplican y decide en este orden. Ninguna capa de techo (SCP, RCP, límite, sesión) concede permisos: solo recortan. Los permisos salen de las políticas de identidad o de recurso.

1. 1

   Negación explícita en cualquier política

   Si una SCP, RCP, política de recurso, de identidad, límite o política de sesión tiene un Deny que coincide, la respuesta es no. Fin.
2. 2

   RCP de la cuenta dueña del recurso

   Las políticas de control de recursos limitan lo que cualquiera puede hacer sobre los recursos de las cuentas miembro, venga de donde venga. Al activarlas se adjunta RCPFullAWSAccess, que permite todo y no se puede quitar.
3. 3

   SCP de la cuenta del principal

   Las políticas de control de servicios limitan lo que pueden hacer los usuarios y roles de las cuentas miembro, incluido su usuario raíz.
4. 4

   Política basada en recursos

   En la misma cuenta, un Allow en la política del recurso puede bastar. Entre cuentas, hace falta el Allow del recurso y además el de la identidad.
5. 5

   Políticas de identidad

   Si ninguna política del usuario o rol permite la acción (y el recurso no la concedió), la respuesta es no.
6. 6

   Límite de permisos

   Si la identidad tiene un permissions boundary y este no incluye la acción, la respuesta es no.
7. 7

   Política de sesión

   Si la sesión se creó con una política de sesión y esta no incluye la acción, la respuesta es no. Si pasa todo, se permite.

Límites de permisos: delegar sin perder el control

El equipo de plataforma no quiere ser el cuello de botella que crea cada rol de Lambda. Pero si le das iam:CreateRole a un equipo de aplicaciones, puede crear un rol con AdministratorAccess y asumirlo. Eso es una escalada de privilegios.

La salida es un límite de permisos (permissions boundary): una política administrada que fija el máximo que puede tener un usuario o rol. Permites crear roles solo si llevan ese límite adjunto, e impides que lo modifiquen o lo quiten. El equipo crea lo que quiera, siempre por debajo del techo.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "CrearRolesSoloConElLimite",
      "Effect": "Allow",
      "Action": [
        "iam:CreateRole",
        "iam:AttachRolePolicy",
        "iam:PutRolePolicy",
        "iam:PutRolePermissionsBoundary"
      ],
      "Resource": "arn:aws:iam::111122223333:role/apps/*",
      "Condition": {
        "StringEquals": {
          "iam:PermissionsBoundary": "arn:aws:iam::111122223333:policy/LimiteApps"
        }
      }
    },
    {
      "Sid": "NoEditarElLimite",
      "Effect": "Deny",
      "Action": [
        "iam:CreatePolicyVersion",
        "iam:DeletePolicy",
        "iam:SetDefaultPolicyVersion"
      ],
      "Resource": "arn:aws:iam::111122223333:policy/LimiteApps"
    },
    {
      "Sid": "NoQuitarElLimite",
      "Effect": "Deny",
      "Action": "iam:DeleteRolePermissionsBoundary",
      "Resource": "*"
    }
  ]
}

En la práctica también das iam:PassRole solo sobre role/apps/*, para que esos roles se puedan entregar a Lambda o ECS sin poder pasar roles ajenos.

Sesiones, terceros y atributos

Una política de sesión se pasa al llamar sts:AssumeRole (o sus variantes con SAML y OIDC) en los parámetros Policy o PolicyArns. La sesión resultante tiene la intersección entre los permisos del rol y esa política. Sirve para que un mismo rol entregue credenciales más estrechas según la tarea: un servicio que asume el rol de un inquilino y lo recorta a su prefijo de S3.

Cuando un tercero (una herramienta de monitoreo, un SaaS de costos) asume un rol en tu cuenta, aparece el problema del suplente confundido (confused deputy): otro cliente del mismo proveedor podría darle el ARN de tu rol y hacer que el proveedor actúe en tu cuenta. La defensa es el external ID: el proveedor te da un valor único por cliente y tu política de confianza exige la condición sts:ExternalId con ese valor. Para servicios de AWS que actúan en tu nombre, la misma idea se aplica con aws:SourceArn y aws:SourceAccount en las políticas de recurso.

El control de acceso basado en atributos (ABAC) cambia «este rol puede tocar estos ARN» por «puedes tocar lo que tenga tu misma etiqueta». La política compara aws:PrincipalTag/proyecto con aws:ResourceTag/proyecto, y usa aws:RequestTag y aws:TagKeys para exigir etiquetas al crear recursos. Las etiquetas de sesión llegan desde tu proveedor de identidad (atributos SAML u OIDC) o en el parámetro Tags de AssumeRole; la política de confianza debe permitir sts:TagSession. Un equipo nuevo no necesita políticas nuevas: solo etiquetas nuevas. Hay un ejemplo con DynamoDB en SaaS multiinquilino.

Perímetros de datos

Un perímetro de datos es un conjunto de barreras preventivas que garantizan tres cosas: solo identidades confiables acceden a tus recursos, tus identidades solo acceden a recursos confiables, y todo ocurre desde redes esperadas. Se arma con tres tipos de política, cada una en su lado de la petición.

Esta RCP, adjunta a la raíz de la organización, cierra el lado de las identidades para cinco servicios:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "SoloIdentidadesDeMiOrganizacion",
      "Effect": "Deny",
      "Principal": "*",
      "Action": ["s3:*", "sqs:*", "kms:*", "secretsmanager:*", "sts:AssumeRole"],
      "Resource": "*",
      "Condition": {
        "StringNotEqualsIfExists": { "aws:PrincipalOrgID": "o-a1b2c3d4e5" },
        "BoolIfExists": { "aws:PrincipalIsAWSService": "false" }
      }
    }
  ]
}

Las excepciones importan: servicios de AWS que acceden en tu nombre (aws:PrincipalIsAWSService, aws:ViaAWSService) y socios que de verdad necesitan entrar. Para el tráfico privado, las políticas de endpoint de VPC limitan qué identidades y qué recursos se alcanzan por ese endpoint (ver Rutas, gateways y NAT).

IAM Access Analyzer es el auditor del perímetro. Tiene analizadores de acceso externo (recursos compartidos fuera de tu cuenta u organización), de acceso interno (qué roles de tu organización alcanzan recursos críticos) y de acceso sin usar (roles, llaves, contraseñas y permisos ociosos). Además valida políticas contra la gramática y buenas prácticas, y sus custom policy checks revisan en el pipeline si un cambio concede acceso nuevo o público.

Acceso sin VPN y cargas fuera de AWS

• 

  AWS Verified Access

  El guardia que revisa carné y estado del visitante en cada puerta

  Da acceso a aplicaciones internas sin VPN. Evalúa cada petición con datos de un proveedor de identidad (IAM Identity Center u OIDC) y de proveedores de estado del dispositivo, contra políticas escritas en Cedar. Sirve para apps HTTP(S) y, desde febrero de 2025, para TCP, SSH y RDP (instancias, bases RDS, rangos CIDR). Registra cada intento.
• 

  IAM Roles Anywhere

  Cambiar un certificado notariado por un carné de visitante

  Entrega credenciales temporales de un rol a servidores, contenedores o equipos fuera de AWS que tienen un certificado X.509. Registras tu CA como trust anchor (Private CA o una CA externa), creas un perfil con los roles y una política de sesión, y el rol confía en rolesanywhere.amazonaws.com.