Mínimo privilegio en AWS sin adivinar: el flujo con Access Analyzer

Pregunta a cualquier equipo por qué un rol tiene PowerUserAccess y la respuesta siempre es una versión de la misma historia: había una fecha límite, alguien enganchó la política gestionada para desbloquear un despliegue y no se rompió nada, así que nadie volvió. Dos años después tiene mil permisos de ancho y la persona que la enganchó ya no está.

El mínimo privilegio fracasa cuando lo tratas como un problema de redacción. Nadie puede escribir de memoria una política mínima para un servicio que no conoce. Es un problema de cosecha: deja que el rol funcione, mira qué usa y escribe exactamente eso.

El bucle

1. Ordena los roles por daño, no por cantidad. Saca los roles de tus cuentas de producción y ordénalos por dos cosas: si la política de confianza admite a un humano o a un principal externo, y si el rol puede escribir en IAM, KMS, S3 o la red. Un rol de solo lectura que usan cien personas es menos interesante que un rol de CI que puede llamar a iam:PassRole con comodín.

2. Lee los datos de access advisor. Para cada rol, aws iam get-service-last-accessed-details te da los servicios que ha tocado y cuándo. Los servicios sin tocar en 180 días salen de la política. Este paso solo quita más superficie que cualquier otra cosa que hagas este trimestre, y casi no tiene riesgo porque ves la marca de último uso antes de cortar.

3. Genera una política desde CloudTrail. La generación de políticas de IAM Access Analyzer lee el trail de un rol en una ventana de hasta 90 días y emite una política acotada a las acciones que realmente llamó. Dos avisos aprendidos a golpes:

• La ventana tiene que cubrir tu ciclo más lento. Si un rol solo ejecuta un trabajo trimestral, 90 días pueden perdérselo. Apunta esos trabajos antes de cortar y añade sus acciones a mano.
• Las políticas generadas acotan acciones pero suelen dejar el recurso con comodín. Apretar recursos es trabajo manual, y ahí está el valor real: s3:GetObject sobre * y sobre un bucket son permisos muy distintos.

4. Despliega en staging con la política vieja todavía puesta. Engancha la nueva política estrecha como política adicional y deja la amplia una semana mientras vigilas los AccessDenied en CloudTrail. Después quita la amplia. Las denegaciones se registran aunque la petición acabe permitida por otra política, así que tienes un simulacro gratis.

5. Cierra el perímetro con los hallazgos de acceso externo. Los hallazgos de acceso externo de Access Analyzer te dicen qué roles, buckets, claves KMS, funciones Lambda y colas SQS son alcanzables desde fuera de tu organización. Pon la zona de confianza en la organización, no en la cuenta, y clasifica cada hallazgo como "archivado con un motivo escrito" o "corregido". Una lista de hallazgos sin revisar es peor que ninguna, porque enseña al equipo a ignorar la consola.

Los cuatro hallazgos que se repiten

En todos los diagnósticos aparecen los mismos cuatro en casi cualquier cuenta.

• iam:PassRole con Resource: "*". Cualquier principal que lo tenga puede entregar a un servicio un rol mucho más privilegiado que el suyo. Acótalo a los ARN exactos y añade una condición iam:PassedToService.
• Políticas de confianza con comodín en roles entre cuentas. Un rol que confía en una cuenta externa entera en lugar de en un rol concreto, sin sts:ExternalId. Es el montaje de diputado confundido que los proveedores siguen pidiendo.
• Claves de acceso de larga vida en usuarios IAM. Normalmente para CI. Sustitúyelas por federación OIDC desde tu proveedor de CI: es una tarde de trabajo y borra la categoría entera.
• Políticas inline que nadie puede diferenciar. Pásalas a políticas gestionadas en Terraform para que los cambios aparezcan en un pull request.

Qué imponer después

La cosecha reduce lo que existe; las barreras impiden que vuelva a crecer. Ponemos tres: una service control policy que deniegue crear usuarios IAM, un control en CI que falle un plan que introduzca Action: "*" o Resource: "*" fuera de una lista permitida, y una repetición trimestral del informe de último acceso como trabajo programado que abre tickets. Nuestro trabajo de seguridad incluye los tres, y los escáneres open source también marcan casi todo esto — escribimos sobre las herramientas que merece la pena ejecutar.

El objetivo no es una política perfecta. Es una política donde cada línea tenga un motivo que alguien pueda decir en voz alta.

Qué hacer esta semana

Ejecuta get-service-last-accessed-details sobre tus cinco roles de producción más privilegiados. Quita todos los servicios sin tocar en 180 días. Es una tarde, es reversible y es la mayor reducción de radio de explosión que tienes disponible ahora mismo.