IAM - identidad y acceso

IAM (Identity and Access Management) es el sistema que decide quién existe en tu entorno cloud, qué puede hacer cada uno y bajo qué condiciones. En lugar de un firewall en el borde, el control se distribuye en cada llamada de API: cada request lleva una identidad, y esa identidad se evalúa contra políticas antes de tocar cualquier recurso.

Tres piezas sostienen todo: el principal (humano, servicio, workload), la acción que quiere realizar (s3:GetObject, ec2:TerminateInstance) y el recurso objetivo (bucket, instancia, función). La respuesta es siempre sí o no, y el motor registra quién pidió qué, cuándo y cómo.

Los usuarios son identidades persistentes asociadas a alguien (o a un secreto estático). Los roles son identidades asumibles: en lugar de contraseña, alguien cambia de rol vía AssumeRole y obtiene credenciales temporales por minutos u horas. Para workloads casi siempre es así: nada de usuarios fijos, todo mediante roles.

Las policies son documentos JSON que describen permisos. Hay tres tipos que encuentras todo el tiempo: identity policies (asociadas al principal), resource policies (asociadas al recurso, como una bucket policy) y session policies (límites adicionales durante AssumeRole). La evaluación las combina todas, y basta un solo deny explícito para bloquear la acción.

Cuando todo es una policy, se puede revisar, versionar y probar el acceso como código. Cuando la mitad es un clic en la consola y la otra mitad es un JSON pegado en Slack, el caos aparece en el primer incidente.

La política de abajo es el antipatrón clásico: admin con todo sobre cualquier recurso. Aparece cada semana en algún taller y en la mitad de los incidentes de buckets públicos de internet.

Incluso un job simple rara vez necesita todo. Esta política concede solo la lectura del bucket correcto, en la región correcta, con un condition que limita el origen a un rol específico:

Todo rol tiene dos extremos. El primero es la trust policy, que define quién puede llamar a sts:AssumeRole. El segundo es la permission policy, que define qué gana quien lo asume. Mezclar ambos es donde nacen los incidentes de escalamiento: el rol permite s3:* en cualquier lugar, y la trust acepta Principal: "*", así que cualquier cuenta autenticada entra.

Una buena trust policy nombra cuentas, servicios e incluso condiciones externas (MFA, hora del día, proveedor federado). Cuando ves "Principal": "*" sin Condition explícita, vale la pena detenerse y preguntar por qué.

Las permission boundaries funcionan como un techo: el permiso efectivo de un principal es la intersección entre lo que permite la boundary y lo que permite la identity policy. Es la herramienta estándar para dar autonomía a los equipos sin ceder el control central.

En la práctica, defines una boundary por equipo o entorno (producción, staging) y dejas que el equipo escriba las identity policies dentro de ese envelope. El desarrollador puede abrir el abanico cuanto quiera, pero nunca pasa del techo.