Seguridad con IAM y Buenas Prácticas

IAM permite expresar quién puede hacer qué sobre qué recurso y bajo qué condiciones. Para una aplicación de informes, separa una identidad que solo lee objetos de otra que publica nuevos archivos. El permiso debe apuntar al bucket y a las acciones necesarias, no conceder administración completa como atajo. Las credenciales reales quedan fuera del laboratorio.

Ejemplo resuelto

Rol lector: s3:GetObject sobre arn:aws:s3:::cursalo-ejercicio/informes/2026/*. Rol publicador: s3:PutObject sobre ese mismo ARN de objetos, sin borrar. El bucket es ficticio. No se concede s3:ListBucket, que correspondería al ARN del bucket, no al de sus objetos. Si no hay otras políticas aplicables que concedan más permisos, el primer rol no puede publicar y el segundo no puede eliminar. Revisa el conjunto de políticas, además de este permiso de ejemplo. Esta separación reduce el impacto de una credencial expuesta, aunque no sustituye otros controles.

Pruébalo

1. Lista la tarea de cada identidad.

2. Traduce la tarea a acciones.

3. Limita el recurso por prefijo.

4. Construye una tabla local de acción, ARN solicitado y decisión esperada. Esa tabla comprueba tu razonamiento; no ejecuta ni sustituye el motor de autorización IAM.

Error frecuente: usar una política administrativa para terminar rápido. Corrección: empieza con mínimo privilegio y amplía solo ante una necesidad documentada.

Ejercicio: diseña permisos para un revisor que solo descarga auditoria/enero.csv.

Comprueba tu resultado

s3:GetObject sobre arn:aws:s3:::cursalo-ejercicio/auditoria/enero.csv, sin escritura, borrado ni acceso a auditoria/febrero.csv, suponiendo que ninguna otra política concede permisos adicionales.