IAM en AWS: políticas, roles y buenas prácticas para datos

En más de un proyecto de datos he visto roles de IAM con "Action": "s3:*" sobre "Resource": "*" «para que funcione y ya lo ajustamos luego». El «luego» casi nunca llega. IAM no es la parte más vistosa de una arquitectura de datos, pero es la que decide qué job, qué persona y qué servicio puede tocar qué dato.

Las piezas básicas: usuarios, roles y policies

IAM (Identity and Access Management) gira en torno a tres conceptos que conviene tener muy claros antes de complicarse con nada más:

• Usuarios (users): identidades individuales, normalmente asociadas a una persona, con credenciales propias.
• Roles (roles): identidades que no pertenecen a nadie en concreto, sino que son asumidas temporalmente por un usuario, una aplicación o un servicio de AWS. Son la forma recomendada de dar permisos a servicios como Glue, Redshift o Lambda.
• Policies: documentos JSON que definen qué acciones están permitidas (o denegadas), sobre qué recursos y bajo qué condiciones. Se adjuntan a usuarios, grupos o roles.

Una policy puede ser managed (un documento independiente y reutilizable, ya sea gestionado por AWS o por la propia cuenta) o inline (incrustada directamente en una única identidad). Las managed se recomiendan cuando el mismo conjunto de permisos se va a reutilizar en varios roles o usuarios.

Basadas en identidad vs. basadas en recursos

Aquí es donde suele haber confusión. La documentación de AWS distingue dos grandes familias de policies:

Un bucket policy en S3 es el ejemplo típico de policy basada en recursos: se define en el propio bucket y declara qué cuentas o roles pueden acceder a él. Para acceso entre cuentas distintas, la documentación de IAM señala que hacen falta las dos piezas trabajando juntas: una policy basada en recursos en la cuenta que posee el recurso, y una policy basada en identidad en la cuenta del principal que necesita acceder.

El caso típico en un pipeline de datos: el rol que asume un job

Cuando configuras un job de AWS Glue, o un cluster de Redshift que va a usar Redshift Spectrum, no le das credenciales de un usuario: le asignas un rol de servicio que ese job o cluster asume en tiempo de ejecución. Ese rol lleva una trust policy (una policy basada en recursos, en este caso adjunta al propio rol) que dice qué servicio tiene permiso para asumirlo —por ejemplo, el servicio de Glue— y, por otro lado, una o varias policies de identidad que definen qué puede hacer una vez asumido: normalmente, leer de un bucket S3 de origen y escribir en otro de destino, además de operar sobre el Glue Data Catalog.

Este patrón —rol de servicio con permisos acotados— es el mismo tanto si hablamos de un job ETL de Glue leyendo la zona raw del data lake, como de un cluster de Redshift usando Spectrum para consultar tablas externas en S3: en ambos casos, el servicio «toma prestada» una identidad temporal con exactamente los permisos que necesita para esa tarea.

Buenas prácticas para entornos de datos

• Da a cada job o servicio su propio rol, en lugar de reutilizar un rol genérico «para todo el equipo de datos»: así puedes revocar o ajustar permisos de uno sin afectar a los demás.
• Aplica el principio de mínimo privilegio: empieza acotando el Resource a los buckets y prefijos concretos que ese job necesita, no a "*".
• Usa policies gestionadas por la cuenta (customer managed) para permisos que se repiten entre varios roles, en vez de duplicar policies inline en cada uno.
• Revisa periódicamente los permisos concedidos: es habitual que un rol acumule accesos «por si acaso» que ya nadie necesita.
• Para gobernar el acceso a nivel de tabla o columna dentro del data lake, combina IAM con AWS Lake Formation, que añade permisos de grano fino sobre el Glue Data Catalog.

Dedicar tiempo a diseñar bien estos roles no es burocracia: es lo que evita que un job mal configurado pueda leer (o borrar) datos que no le corresponden, y lo que hace auditable quién puede tocar qué en toda la plataforma de datos.