Políticas IAM AWS: roles, permisos y mínimo privilegio

En pocas palabras: AWS IAM controla el acceso denegando todo por default y habilitando permisos solo cuando una política lo permite explícitamente. Define quién pide acceso, qué acción puede ejecutar y sobre qué recurso, mediante usuarios, grupos, roles y políticas con Effect, Action, Resource y Condition.

AWS Identity and Access Management (IAM) controla quién puede acceder a qué recurso dentro de una cuenta de AWS, usando usuarios, grupos, roles y políticas. Las políticas IAM AWS definen permisos exactos: qué acción se permite, sobre qué recurso puntual y bajo qué condición, sin otorgar acceso total por default.

IAM es el servicio de AWS que administra identidades y permisos dentro de una cuenta: usuarios, grupos, roles y las políticas que determinan qué puede hacer cada identidad sobre qué recursos. Por default, todo acceso está denegado, y solo se habilita cuando una política lo permite explícitamente, según detalla la documentación oficial de AWS IAM. El objetivo final es que cada identidad tenga el mínimo necesario para cumplir su tarea.

¿Qué problema resuelve IAM cuando una app necesita acceder a varios servicios de AWS?

IAM resuelve el problema de dar acceso puntual en vez de acceso total. Ponele que desplegás una aplicación MERN en AWS: el backend necesita leer archivos de S3, recuperar credenciales de base de datos y escribir logs. Nada de eso requiere que la aplicación tenga control completo sobre la cuenta.

Un desarrollador que recién arranca con AWS suele preguntarse si total, ya que la app “funciona”, para qué complicarse con permisos. El tema es que crear recursos es solo una parte del trabajo. La otra parte, la que casi nadie documenta bien al principio, es decidir quién puede tocar qué y qué servicio puede hablar con cuál otro, según plantea el artículo original sobre IAM publicado en dev.to.

IAM contesta tres preguntas concretas: quién hace la solicitud, qué acciones puede ejecutar y a qué recursos puede llegar. Nada más, nada menos.

¿Qué son los usuarios, grupos y roles de IAM?

Son tres tipos de identidad con usos distintos dentro de una cuenta de AWS. El usuario tiene credenciales de largo plazo, el grupo agrupa usuarios para administrar permisos en conjunto, y el rol es una identidad asumible que entrega credenciales temporales. Complementá con nuestra guía práctica para implementar IAM.

• IAM user: identidad con credenciales de largo plazo cuando se configuran. AWS recomienda usar federación y credenciales temporales en lugar de usuarios IAM para personas, salvo casos puntuales como cargas de trabajo que no soportan roles.
• IAM group: agrupa usuarios para simplificar la gestión de permisos. Ejemplos típicos: developers con acceso a recursos de desarrollo, auditors con acceso de solo lectura, administrators con permisos más amplios.
• IAM role: identidad que cualquier principal autorizado puede asumir, y que entrega credenciales temporales en vez de claves fijas. Se usa constante en EC2, ECS y Lambda.

Ojo con esto: el usuario root de la cuenta no debería usarse para tareas rutinarias. AWS lo dice sin vueltas en su guía de prácticas recomendadas de seguridad en IAM, protegerlo bien y reservarlo solo para lo que realmente exige privilegios de root.

¿Qué es una política de IAM y cómo se estructura?

Una política de IAM es un documento JSON que define permisos mediante cuatro elementos: Effect (Allow o Deny), Action (la operación solicitada), Resource (el recurso de AWS involucrado) y Condition (requisitos opcionales que deben cumplirse).

Pensalo con un caso real: una aplicación que necesita descargar objetos de un bucket de S3 sin poder borrarlos. La política quedaría así:

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Action": "s3:GetObject",
 "Resource": "arn:aws:s3:::my-app-documents/*"
 }
 ]
}

Esta política habilita la operación GetObject sobre los objetos del bucket my-app-documents. Nada más. No otorga permiso para subir ni para borrar objetos, aunque alguien asuma lo contrario (spoiler: es un error común). Reemplazá el nombre del bucket por el recurso real antes de aplicarla.

¿Cuál es la diferencia entre políticas basadas en identidad y basadas en recursos?

Las políticas basadas en identidad se adjuntan a usuarios, grupos o roles y describen qué puede hacer esa identidad. Las políticas basadas en recursos se adjuntan al recurso mismo (un bucket de S3, por ejemplo) y describen qué principales pueden acceder a ese recurso puntual. Te puede servir nuestra cobertura de errores comunes al configurar trust policies.

Un rol puede tener permiso para leer objetos de un bucket, y al mismo tiempo la política del bucket puede restringir qué principales están habilitados para acceder a él, según plantea el artículo de dev.to sobre IAM. Las dos políticas importan al mismo tiempo. Un Allow en una no anula un Deny explícito ni otra restricción aplicable en la otra, según confirma la documentación de AWS en las preguntas frecuentes de IAM.

¿Qué es la trust policy de un rol de IAM y en qué se diferencia de la permissions policy?

La trust policy define quién puede asumir un rol; la permissions policy define qué puede hacer ese rol una vez asumido. Son dos documentos que resuelven problemas distintos, y confundirlos es uno de los errores más repetidos al configurar roles de IAM.

Pensá en una tarea de ECS que necesita acceder a un bucket de S3, según plantea el artículo de dev.to sobre IAM. La trust policy del task role establece que las tareas de ECS correspondientes pueden asumir ese rol. La permissions policy, en cambio, otorga solo las acciones de S3 necesarias. Permitir que un servicio asuma un rol no le da automáticamente permiso para acceder a S3: son capas separadas, y las dos tienen que estar bien configuradas para que el flujo funcione.

¿Qué es el principio de mínimo privilegio y cómo se aplica en la práctica?

El mínimo privilegio significa otorgar solo los permisos necesarios para cumplir una tarea, ni uno más. No es escribir políticas más cortas: es revisar permisos seguido, sacar accesos que nadie usa y pensar qué pasaría si esa identidad quedara comprometida.

Si tu aplicación necesita leer archivos de S3, dar s3:* sobre todos los buckets de la cuenta es la peor alternativa posible. Lo correcto es otorgar solo las acciones necesarias sobre el bucket u objeto puntual que la app usa.

Permiso amplio	Alternativa de mínimo privilegio
Todas las acciones de S3 (s3:*)	Solo las acciones necesarias (ej: s3:GetObject)
Acceso a todos los recursos (*)	ARNs específicos de recursos cuando es posible
Credenciales permanentes	Credenciales temporales vía rol asumido
Acceso de administrador para cada developer	Acceso basado en el rol según la responsabilidad

¿Qué son los permission boundaries en IAM?

Un permission boundary es un techo máximo de permisos que puede recibir un usuario o rol a través de políticas basadas en identidad. No otorga permisos por sí mismo: la identidad sigue necesitando una política que permita la acción, el boundary solo limita hasta dónde puede llegar esa política. Para más detalles técnicos, mirá cómo diseñar una arquitectura AWS de producción.

Un equipo de desarrollo podría tener permiso para crear roles para sus propias aplicaciones, siempre dentro de un boundary definido por el administrador de la cuenta. Eso sí: el boundary no es una restricción universal sobre cualquier camino de acceso posible. Las políticas basadas en recursos y otras reglas de autorización de AWS también entran en juego al evaluar el acceso efectivo real.

¿Por qué usar roles de IAM en lugar de credenciales hardcodeadas en el código?

Porque un rol entrega credenciales temporales a través del entorno de ejecución, sin necesidad de guardar claves de acceso en el código. Hardcodear un access key y un secret key dentro de la aplicación es inseguro: esas credenciales pueden terminar en un repositorio de Git, en logs o en un build artifact sin que nadie se dé cuenta.

La alternativa es configurar el entorno de ejecución (una instancia EC2, una tarea de ECS, una función Lambda) con el rol de IAM adecuado, y dejar que el SDK obtenga las credenciales solo. Con AWS SDK for JavaScript v3, el código queda así:

import { S3Client, ListObjectsV2Command } from "@aws-sdk/client-s3";

const s3 = new S3Client({ region: "ap-south-1" });

const response = await s3.send(
 new ListObjectsV2Command({ Bucket: "my-app-documents" })
);

console.log(response.Contents);

Para que este código funcione, el rol asociado a la aplicación necesita permiso de s3:ListBucket sobre ese bucket. Si la app solo descarga un objeto puntual, alcanza con s3:GetObject sobre ese objeto, sin abrir el bucket entero. Y ojo: usar un rol no vuelve segura a la aplicación por sí mismo. El rol todavía necesita una trust policy correcta y permisos acotados, ni más ni menos. En el proceso de desplegar Coolify en EC2 profundizamos sobre esto.

Si tu infraestructura corre fuera de AWS (en un VPS propio, ponele, para el frontend o para servicios auxiliares), la lógica de mínimo privilegio aplica igual: nunca mezclar credenciales de distintos entornos ni dejar claves sueltas en archivos de configuración. Para ese tipo de hosting en Argentina, donweb.com es una opción a considerar.

Errores comunes al configurar IAM

• Usar el usuario root para el día a día: el root debería reservarse para operaciones que específicamente lo requieran, no para tareas rutinarias de desarrollo.
• Dar permisos de administrador “para no complicarse”: es la forma más rápida de perder el control sobre quién puede hacer qué en la cuenta.
• Confundir trust policy con permissions policy: son documentos distintos que resuelven preguntas distintas, y mezclarlos genera roles que no funcionan como se espera.
• Asumir que un permission boundary otorga acceso: el boundary pone un techo, no reemplaza a la política de permisos.
• Dejar usuarios, claves o permisos sin uso: cada credencial vieja que nadie revisó es una puerta abierta de más.

Preguntas Frecuentes

¿Qué es IAM en AWS y para qué sirve?

IAM (Identity and Access Management) es el servicio de AWS que controla el acceso a los recursos de una cuenta. Define quién puede hacer una solicitud, qué acciones puede ejecutar y sobre qué recursos, mediante usuarios, grupos, roles y políticas.

¿Cuál es la diferencia entre un usuario y un rol de IAM?

Un usuario de IAM tiene credenciales de largo plazo asociadas a una identidad fija, pensada para una persona o una carga de trabajo puntual. Un rol no tiene credenciales permanentes: cualquier principal autorizado lo puede asumir y recibe credenciales temporales para esa sesión.

¿Qué es el principio de mínimo privilegio en AWS?

El mínimo privilegio es otorgar solo los permisos necesarios para cumplir una tarea específica, sin acceso de más. En la práctica implica acotar las políticas a acciones y recursos puntuales, y revisar seguido qué permisos quedaron sin usar.

¿Qué es una trust policy en un rol de IAM?

Una trust policy es el documento JSON que define qué principales (usuarios, roles, cuentas o servicios) pueden asumir un rol de IAM determinado. Es distinta de la permissions policy, que define qué puede hacer el rol una vez asumido.

¿Cómo le doy permisos a una aplicación en ECS o Lambda para acceder a S3?

Asignale a la tarea de ECS o a la función Lambda un rol de IAM con una permissions policy que incluya solo las acciones de S3 necesarias (como s3:GetObject) sobre el bucket u objeto puntual. El SDK de AWS toma esas credenciales temporales de forma automática a través del entorno de ejecución, sin necesidad de hardcodear claves.

Conclusión

IAM no es un trámite burocrático antes de desplegar algo en AWS: es la capa que decide si tu aplicación puede hacer solo lo que necesita o un poco de todo. La diferencia entre usuarios, grupos y roles, y la separación entre trust policy y permissions policy, son los dos puntos donde más se traban los que recién arrancan.

La pregunta que vale la pena hacerse en cada decisión de permisos no es si la aplicación puede acceder a un recurso, sino si debería tenerlo, y si ese permiso se puede acotar todavía más. Ese es el mindset detrás del mínimo privilegio, y es el que termina evitando sustos cuando algo se compromete.

Fuentes

• AWS IAM User Guide: IAM roles – documentación oficial
• Prácticas recomendadas de seguridad en IAM – AWS
• AWS Identity and Access Management (IAM) FAQs
• How Does AWS Control Who Can Access What? – artículo original en dev.to