IAM y el principio de menor privilegio: permisos en la nube explicados sin jerga
La mayoría de los hackeos en cloud no vienen de hackers brillantes: vienen de permisos demasiado abiertos. Te explico cómo funcionan IAM y por qué importa.
Cuando la gente se hackea en la nube, la causa rara vez es un atacante genial. Lo normal es: alguien dio permisos de más y un token filtrado pudo hacer lo que no debía. Entender IAM (Identity and Access Management) previene el 80% de esos incidentes.
El concepto fundamental: "deny by default"
Todos los grandes proveedores cloud (AWS, Google Cloud, Azure) trabajan bajo el mismo principio:
Por defecto, nadie puede hacer absolutamente nada. Tienes que dar permisos explícitos para cada acción en cada recurso.
Esto suena restrictivo, pero es lo que separa la nube seria de un hosting compartido. Cada conexión, cada servicio, cada script necesita un permiso nombrado.
Los tres elementos de IAM
1. Identidad Quién pide hacer algo. Puede ser un usuario humano, un servicio (ej. tu servidor), o un pipeline.
2. Política Un documento (normalmente JSON) que dice "esta identidad puede hacer estas acciones en estos recursos".
3. Rol Una identidad temporal que otra entidad puede "asumir" por un tiempo corto. Es como una credencial prestada que caduca.
Ejemplo de política mínima:
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::mi-bucket-publico/*"
}]
}
Traducción en español: "permitir subir archivos, solo al bucket mi-bucket-publico, nada más".
El principio de menor privilegio
La regla de oro en seguridad cloud:
Dale a cada identidad exactamente los permisos que necesita para su trabajo. Ni uno más.
Ejemplos de violaciones comunes:
- Un pipeline de deploy con permisos de
*(todo) "para evitar problemas". - Un servidor con permiso de borrar su propia base de datos.
- Un desarrollador con permisos de producción "por si acaso".
Cada uno de esos es un incidente esperando a pasar.
Por qué cada servicio nuevo exige una política nueva
Una queja frecuente: "¿Por qué cada vez que agrego un servicio tengo que tocar permisos otra vez?"
Respuesta: porque cada servicio cloud tiene su propia API, con sus propias acciones. Dar permisos de S3 no te da permisos de CloudWatch. Dar permisos de CloudWatch no te da permisos de ECR. Es un feature, no un bug.
Si un servicio pudiera "heredar" permisos de otro, un atacante que tomara control de uno podría moverse a los demás. La separación forzada es la defensa.
El error que le cuesta miles a las empresas
El patrón clásico:
- Crean un rol con permisos amplios "para ir rápido".
- Ese rol se asigna al servidor principal.
- Pasa el tiempo, nadie revisa.
- Un día hay un bug (SSRF, RCE, lo que sea) que deja a un atacante usar el rol del servidor.
- El atacante descubre que el rol puede borrar la base de datos, crear instancias nuevas para minar cripto, o leer el bucket con datos de clientes.
La mitigación no era un WAF más caro. Era no haberle dado permisos de borrar BD al servidor web para empezar.
Cómo lo aplicamos en la práctica
Los pasos que seguimos al diseñar una arquitectura cloud:
- Listar cada servicio que necesita hablar con la nube (servidor, pipeline, función serverless, etc.).
- Listar las acciones que cada uno necesita (ej: "subir archivos a bucket X", "leer secreto Y").
- Crear un rol específico por cada combinación servicio-acción.
- Negar todo lo demás explícitamente si es posible.
- Revisar cada 3 meses qué permisos se usaron realmente (los cloud tienen reportes de esto).
¿Cuándo necesitas revisar tu IAM?
- Nunca has revisado los permisos de producción.
- Tu pipeline usa una cuenta con permisos de administrador.
- Varios desarrolladores comparten la misma credencial.
- Usas la cuenta raíz del cloud para el día a día (error grave).
- Te pidieron cumplimiento (SOC2, ISO 27001) y no sabes por dónde empezar.
En ServerStack Solutions
Cada servicio que configuramos tiene su propio rol mínimo. Nada corre con permisos de administrador. Si mañana un token se filtra, el daño máximo está acotado al alcance de ese rol específico.
Contáctanos para una auditoría de permisos cloud.
Relacionado: SSH cerrado sin perder deploys y Arquitectura segura en AWS.
Preguntas frecuentes
¿Qué es menor privilegio en IAM?
Es el principio de que cada identidad (usuario, servicio, aplicación) tiene solo los permisos mínimos necesarios para su función — nada más. Si una app necesita leer un bucket S3, le das permiso de lectura a ese bucket específico, no acceso completo a todo S3. Si un token se filtra, el daño se acota al alcance de ese permiso específico.
¿Cómo sé si mi IAM actual es malo?
Señales típicas: (1) un solo usuario tiene AdministratorAccess y lo usan varios devs; (2) las credenciales de root/owner están guardadas en un .env compartido; (3) no hay política de rotación de access keys; (4) los servicios (EC2, Lambda, containers) corren con roles que tienen permisos de más "por si acaso". Si al menos uno aplica, tu blast radius ante un leak es masivo.
¿Uso usuarios IAM o roles?
Para humanos: usuarios IAM con MFA obligatorio, o mejor aún, SSO federado (IAM Identity Center, Okta). Para servicios: **siempre roles, nunca credenciales estáticas**. Las instancias EC2/Lambda/contenedores asumen roles temporales que rotan solos. Si ves AWS_ACCESS_KEY_ID en un .env del servidor, es bandera roja.