Ordenando las AWS Access Keys que surgieron al responder a ISMS: migración a autenticación basada en roles

Este es un artículo que resume la experiencia de revisar las Access Keys acumuladas en una cuenta de AWS durante el proceso de respuesta a una auditoría posterior de ISMS, y de migrar a una autenticación basada en roles.

Contexto de adopción

• Al revisar la consola de IAM, las Access Keys estaban dispersas en varios lugares (CI/CD, scripts de despliegue, desarrollo local, etc.) y era difícil rastrear dónde y cómo se usaban
• Las Access Keys se mantienen sin vencimiento y, si son comprometidas, exponen tal cual los permisos otorgados, por lo que el riesgo era alto
• AWS también recomienda usar credenciales temporales (roles/STS) en lugar de credenciales de largo plazo (Access Key)

Problema

• Como las claves se copiaban y usaban en distintos sitios, era difícil responder a la pregunta: “Si esta clave es comprometida, ¿hasta dónde llega el impacto?”
• Para rotarlas había que cambiar al mismo tiempo configuraciones dispersas, y como varios permisos de distintos usos estaban concentrados en un solo IAM User, era difícil aplicar el principio de mínimo privilegio
• En ese momento, un solo IAM User para CI/CD concentraba permisos de despliegue a ECR/S3/SSM/ECS, entre otros

Método de migración adoptado (resumen)

• Assume Role: una forma de tomar prestados temporalmente los permisos de otro Role solo cuando se necesitan
• OIDC Web Identity: una forma de obtener un Role con la identidad de un sistema externo, como GitHub Actions/EKS (=IRSA)
• Instance Profile: una forma de adjuntar directamente un Role a EC2/Lambda para que tenga permisos automáticamente

Proceso real de migración

• Paso 1: separar, por tipo de uso, los permisos del IAM User que tenía políticas amplias en Roles distintos (push/pull de ECR, despliegue en ECS, caché de S3, etc.)
• Paso 2: aplicar OIDC en GitHub Actions (registrar el Identity Provider → limitar el alcance del repo con condiciones en la Trust Policy → usar configure-aws-credentials en el workflow)

Efectos

• Se eliminaron las Access Keys del código y de los secretos; al usar tokens temporales, incluso si se ven comprometidos, el alcance del daño queda limitado por el vencimiento
• Desapareció la carga de rotar claves y quedó mucho más claro el seguimiento de permisos por workflow y por tarea

Puntos a tener en cuenta

• No configures condiciones demasiado amplias en la Trust Policy; limita el alcance al mínimo (org/repo y, si es posible, incluso la rama)
• No elimines de inmediato las Access Keys existentes; después de la migración, déjalas desactivadas durante un tiempo de verificación antes de borrarlas