IAM que escala: roles humanos, roles de máquina, radio de explosión

Cada problema de IAM en el que he aterrizado es el mismo problema disfrazado: alguien, hace tres trimestres, concedió un wildcard “para desbloquear un deploy”, y nadie se sintió seguro retirándolo. Multiplica por veinte trimestres y cuarenta ingenieros, y obtienes la organización sobre la que se escriben los reportes de incidente.

IAM que escala no es “pureza least-privilege”. Es un sistema que un equipo ocupado puede mantener limpio mientras sigue entregando. Tres reglas.

1. Separa roles humanos de roles de máquina. Religiosamente.

Un humano se autentica, abre una consola, escribe algo, se va. Una máquina despierta, hace 12 llamadas a la API, muere. Tienen necesidades completamente distintas y radios de explosión completamente distintos. Deja de ponerlos en el mismo rol.

Para humanos:

• SSO, siempre. Nada de IAM users de larga duración.
• Un número pequeño de roles nombrados ligados a la función: viewer, developer, oncall, admin. Sin roles personales.
• Acceso por consola. Sin credenciales programáticas en el ~/.aws/ de nadie.
• MFA innegociable. Llaves hardware para admin.

Para máquinas:

• Un rol por workload. No por equipo, no por entorno, por workload. El servicio “subir a S3” tiene su propio rol.
• Sin secretos de larga duración. Usa OIDC / instance roles / workload identity / IRSA — el equivalente cloud-native para tu plataforma.
• Las políticas son infra-as-code, revisadas en PRs, aprobadas por un ingeniero que opera el workload.

Cuando humanos y máquinas comparten rol, te llevas lo peor de ambos: el humano hereda el ruido del workload; el workload hereda el radio de explosión del humano.

2. Optimiza para revocación, no para concesión

Conceder acceso es fácil. Lo que se rompe es revocarlo.

Diseña con la revocación como operación de primera clase:

• Agrupa todo en unidades revocables. Un equipo se va: revocas el grupo del equipo, no 47 concesiones personales. Un workload se decomisiona: borras su rol, el resto del grafo de políticas se queda limpio.
• Acceso elevado limitado en el tiempo. “Necesito admin durante 30 minutos para depurar” es un flujo (aws sts assume-role con session policy y duración máxima). No es un mensaje de Slack y una concesión permanente.
• Diff periódico entre uso real y permisos concedidos. AWS lo llama “Access Analyzer”. GCP “Policy Intelligence”. Como se llame en tu cloud, míralo. Trimestralmente.

Nunca vas a escribir la política perfecta el día uno. Puedes construir un sistema fácil de limpiar.

3. El radio de explosión es un número que puedes escribir

Antes de conceder cualquier rol a cualquier humano o workload, pregunta: “si esta credencial se filtra mañana, ¿qué es lo peor que puede hacer y cuánto ruido hace la alarma?”.

Un ejercicio útil: escribe, para cada rol nombrado, la respuesta a esas dos preguntas en una frase cada una. Clava la nota a la definición del rol.

Rol	Lo peor que puede hacer	Alarma
developer	Desplegar una nueva versión de cualquier servicio no-prod	CI lo muestra; el commit enlaza al PR
oncall	Leer datos de prod, reiniciar pods de prod	Todas las acciones auditadas; calendario público
admin	Cualquier cosa	Llave hardware; actividad → canal de Slack; revisión trimestral
s3-uploader-svc	Subir a un bucket, con un prefijo	CloudTrail data event; métrica por prefijo

Si no caben las respuestas en una línea, el rol hace demasiadas cosas. Pártelo.

---

La mayoría de desastres de IAM no son fallos de modelo de permisos. Son fallos de atención. El equipo dejó de prestar atención al grafo de políticas porque el grafo dejó de ser legible. Manténlo legible, mantén la revocación barata, y mantén el radio de explosión de cada credencial como un número que un humano puede tener en la cabeza.

Eso es IAM que dura.