Gestión automática y segura de Access Keys a escala en AWS

Por Rayco Martínez, Responsable de Cloud en Moeve; Pablo Martínez, Cloud Engineer en Keepler Data Tech y Ignacio Rodríguez García, Technical Account Manager en AWS.

Moeve, anteriormente conocida como Cepsa, es una compañía energética global inmersa en un proceso de transformación digital y modernización de su plataforma cloud. Como parte de esta estrategia, Moeve en colaboración con Keepler, partner de la AWS Partner Network (APN), y AWS ha diseñado e implementado un sistema centralizado y automatizado de rotación de Access Keys para usuarios programáticos gestionados a través de AWS Identity and Access Management (IAM). En este blog explicamos cómo funciona la solución, los principios de diseño que la sustentan y las lecciones aprendidas tras su implantación en un entorno multi-cuenta en AWS.

Requisitos previos

Para implementar una solución similar a la descrita en este blog, se recomienda contar con:

• Una organización multi-cuenta gestionada mediante AWS Organizations.
• Conocimientos de IAM incluyendo usuarios programáticos, roles y políticas.
• Familiaridad con Service Control Policies (SCPs).
• Experiencia con los siguientes servicios de AWS:
  • AWS Secrets Manager
  • Amazon DynamoDB
  • AWS Step Functions
  • AWS IAM Roles Anywhere

¿Qué son las Access Keys?

Las Access Keys son credenciales programáticas de larga duración, compuestas por un Access Key ID y una Secret Access Key, utilizadas para firmar llamadas a la Application Programming Interface (API) de AWS. Las mejores prácticas de AWS recomiendan utilizar credenciales temporales mediante roles de IAM, federación o IAM Roles Anywhere.

Así pues, Moeve hace uso de IAM Roles Anywhere y la Public Key Infrastructure (PKI) corporativa para emitir credenciales temporales basadas en certificados X.509 firmados por su autoridad certificadora corporativa. Este modelo elimina la necesidad de almacenar Access Keys estáticas en servidores on-premises, integraciones Business-to-Business (B2B) o herramientas externas, reduciendo significativamente la superficie de ataque asociada a credenciales de larga duración.

Sin embargo, en entornos empresariales, como el de Moeve, no siempre es posible proceder de esta manera ya que siguen existiendo integraciones externas, sistemas legacy y automatizaciones que dependen de Access Keys de larga duración.

Mientras avanza hacia el modelo de credenciales efímeras, Moeve necesitaba gobernar de forma segura las Access Keys programáticas de sus sistemas legacy. Esto nos llevó a desarrollar una solución de gobierno de Access Keys alineada con las normas de ciberseguridad y buen gobierno de la compañía.

El desafío de gobernar Access Keys a escala

En organizaciones que operan múltiples cuentas bajo AWS Organizations, la gestión de Access Keys trasciende lo técnico y se convierte en un problema de gobernanza.

En este contexto los principales riesgos identificados fueron:

• Rotación manual sin un patrón temporal definido. Difícil de aplicar de forma sistemática a escala.
• Coexistencia de múltiples claves activas por usuario. Mayor superficie de ataque.
• Falta de claridad sobre la propiedad de cada credencial.
• Excepciones gestionadas fuera de un marco formal y auditable.

La organización necesitaba un modelo que garantizara control y seguridad sin afectar la continuidad operativa. En concreto, debía permitir:

• Automatizar completamente el ciclo de vida de las credenciales.
• Mantener la operación de sistemas productivos sin interrupciones.
• Gestionar excepciones de forma estructurada y auditada.
• Escalar de forma consistente en entornos multi-cuenta sin intervención manual.

El reto consistía en establecer un modelo industrializado de gestión que integrara seguridad, automatización y responsabilidad desde el diseño.

Principios de diseño de la solución

Para abordar la gestión de Access Keys fijas a escala, Moeve definió un conjunto de principios orientados a garantizar seguridad, automatización y gobernanza desde el diseño.

1. Centralización operativa en el Cloud Center of Excellence (CCoE)

Los usuarios IAM programáticos son gestionados exclusivamente por el CCoE, garantizando separación de funciones, consistencia entre cuentas y trazabilidad ante auditorías. Los equipos de aplicación no pueden crear ni gestionar credenciales directamente.

A continuación, se muestra la SCP que deniega la creación de usuarios a los equipos:

{
    "Sid": "DenyUserandGroupActions",
    "Effect": "Deny",
    "Action": [
        "iam:CreateUser",
        "iam:DeleteUser",
        "iam:DeleteAccessKey",
        "iam:UpdateAccessKey",
        "iam:CreateAccessKey",
        "iam:CreateGroup",
        "iam:DeleteGroup",
        "iam:UpdateGroup",
        "iam:CreateSAMLProvider",
        "iam:RemoveUserFromGroup",
        "iam:AttachGroupPolicy",
        "iam:DetachGroupPolicy",
        "iam:DeleteGroupPolicy",
        "iam:UpdateSAMLProvider",
        "iam:DeleteSAMLProvider",
        "iam:PutGroupPolicy",
        "iam:UntagUser",
        "iam:TagUser"
    ],
    "Resource": [
        "*"
    ],
    "Condition": {
        "StringNotLike": {
            "aws:PrincipalArn": [
                "arn:aws:iam::*:role/aws-reserved/*/*/Security_Team_*",
                "arn:aws:iam::*:role/aws-reserved/*/*/CoE_Team_*"
            ]
        }
    }
}

Solo el CCoE o los equipos de seguridad corporativa pueden crear usuarios, modificar sus tags y generar credenciales programáticas.

2. Una única Access Key activa por usuario

Cada usuario dispone de una única Access Key activa en condiciones normales. La segunda clave se utiliza únicamente como mecanismo temporal durante el proceso de rotación, evitando la coexistencia prolongada de múltiples credenciales activas.

3. Automatización completa del ciclo de vida

Todo el ciclo de vida de las Access Keys está automatizado: inventario, evaluación de antigüedad, rotación, notificación y retirada de claves antiguas. No existen pasos manuales en la ejecución técnica del proceso.

4. Gobernanza basada en metadatos (tags)

El modelo utiliza tags como mecanismo de control dinámico:

• Definición de periodo de rotación personalizado (ej. 100 días).
• Identificación del propietario responsable.
• Herencia de metadatos a nivel de cuenta cuando el usuario no los define explícitamente.

Esto permite introducir flexibilidad sin perder gobernanza centralizada. Las excepciones existen, pero están estructuradas y auditadas.

Moeve tiene definida una SCP para forzar que no se puedan crear usuarios sin un tag de owner (propietario):

{
    "Action": [
        "iam:CreateUser"
    ],
    "Condition": {
        "Null": {
            "aws:RequestTag/global:owner": "true"
        }
    },
    "Effect": "Deny",
    "Resource": "*",
    "Sid": "DenyCreateIAMWithNoOwnerTag"
}

5. Seguridad por diseño y reducción de exposición

Las nuevas credenciales se almacenan temporalmente en AWS Secrets Manager y se distribuyen mediante enlaces seguros de un solo uso. Las claves antiguas se deshabilitan antes de su eliminación, minimizando la exposición.

6. Escalabilidad en entornos multi-cuenta

La solución está diseñada para operar de forma centralizada en entornos gestionados con AWS Organizations, manteniendo el aislamiento por cuenta y evitando intervención manual.

Arquitectura de la solución

Una vez definidos los principios de diseño, el siguiente paso fue definir una arquitectura que permitiera operar la rotación de Access Keys fijas de forma centralizada, segura y a escala, sin depender de acciones manuales por cuenta o por equipo.

A alto nivel, la solución se apoya en cuatro bloques funcionales que cubren de extremo a extremo el ciclo de vida de las credenciales programáticas:

1. Inventario centralizado y motor de decisión
   La solución se apoya en un inventario periódico que registra la antigüedad y el estado de todas las Access Keys de la organización, junto con los metadatos relevantes asociados a cada usuario IAM. Este inventario constituye la base operativa del sistema y permite evaluar de forma continua qué credenciales se aproximan o superan su umbral de rotación. En la sección B del apartado “Tagging and Inventory as the foundations of a notification system” de este blog, Moeve explica su inventario centralizado.
   La evaluación tiene en cuenta tanto el periodo estándar definido (180 días) como posibles excepciones explícitas, aprobadas previamente y expresadas mediante tags, de forma que la decisión sigue siendo automática, consistente y auditable.
2. Orquestación automatizada de la rotación
   Cuando una Access Key alcanza su fecha de caducidad el sistema mediante el inventario de recursos registra el evento y activa un flujo de automatización orquestado que coordina todas las acciones necesarias para ejecutar la rotación de forma segura.
   Este flujo crea una segunda Access Key temporal para el usuario afectado (manteniendo el principio de “solo una activa en steady state”). La segunda clave se utiliza exclusivamente como mecanismo técnico para permitir una transición sin interrupciones en los sistemas que consumen la credencial.
3. Custodia temporal y distribución segura de la credencial
   La nueva Access Key generada durante la rotación se almacena de forma temporal y segura en AWS Secrets Manager, evitando su exposición en texto plano o a través de canales no controlados.
   A partir de este secreto, el sistema envía al propietario un correo electrónico con un enlace seguro de un solo uso y con caducidad, desde el que puede recuperar la nueva credencial. Este enfoque garantiza que la Access Key no circule directamente por email y limita estrictamente su ventana de exposición.
4. Confirmación del propietario y cierre controlado del ciclo de vida
   Hasta que el propietario confirma que ha actualizado su sistema para utilizar la nueva Access Key, la solución envía recordatorios automatizados de forma periódica. Una vez recibida la confirmación, el sistema elimina el secreto almacenado, deshabilita la clave antigua y, tras un periodo de gracia controlado, la elimina definitivamente. Todo el proceso queda registrado de forma estructurada, proporcionando trazabilidad completa, capacidad de auditoría y gobierno centralizado del ciclo de vida de las credenciales.

Esta arquitectura permite mantener el control centralizado (por el CCoE), sin romper el ritmo de los equipos de aplicación, y asegurando que ninguna Access Key permanece activa indefinidamente por olvido o falta de trazabilidad.

Flujo de rotación paso a paso

A continuación, se describe el flujo operativo completo tal como se ejecuta en producción.

El proceso comienza con un inventario periódico que registra todos los datos de los usuarios IAM de la organización de Moeve. Con esta información, mediante consultas automatizadas, se determina qué Access Keys cumplen los criterios definidos de rotación.

Por defecto, el departamento de ciberseguridad ha establecido que se rotan todas las claves cada 180 días. Cuando el equipo de Ciberseguridad de Moeve aprueba una excepción, esta se expresa mediante un tag de forma que la decisión sigue siendo automática y auditable.

• rotation-exception = 365
• rotation-exception = never (reservado para casos muy específicos donde el usuario tiene restricciones de uso por IPs y permisos muy acotados)

Mediante la misma SCP que controla que nadie sino el equipo del CCoE o seguridad cree usuarios (ver punto 4 de la sección “Principios de diseño de la solución”), se bloquea que no puedan etiquetar o desetiquetar los usuarios.

Ilustración 1. Sistema de rotado de Access Keys

1. Programación (Amazon EventBridge)

Un cron diario configurado en Amazon EventBridge dispara la ejecución del proceso de revisión de Access Keys.

Este evento activa la función Lambda encargada de analizar el inventario de usuarios IAM en todas las cuentas AWS activas y detectar aquellas claves cuya antigüedad supera el umbral establecido (365 días).

2. Creación de la segunda Access Key temporal

La función Lambda, orquestada mediante AWS Step Functions, asume un rol en la cuenta destino y crea una segunda Access Key para el usuario IAM afectado.

A continuación, genera un enlace temporal de un solo uso (OneTimeSecret, con TTL de 7 días) que permitirá al propietario descargar las nuevas credenciales de forma segura.

3. Almacenamiento seguro (AWS Secrets Manager)

La nueva credencial (Access Key ID + Secret Access Key) se almacena en AWS Secrets Manager dentro de la cuenta central de gestión.

Este almacenamiento intermedio cumple dos funciones: evitar la transmisión de secretos por canales no controlados y permitir la regeneración del enlace de entrega cada vez que este caduca (cada 7 días se genera y envía un nuevo enlace al propietario).

El secreto se mantiene hasta que el propietario confirma la migración.

4. Registro y trazabilidad (Amazon DynamoDB)

La función Lambda genera un ticket en la tabla DynamoDB de la solución que actúa como registro de auditoría.

Este ticket contiene la información del usuario IAM, la cuenta afectada, las claves detectadas y el estado del proceso.

5. Notificación al propietario (Amazon SES)

Se envía un correo electrónico al propietario del usuario IAM mediante Amazon SES.
El correo incluye un enlace seguro de un solo uso para descargar las nuevas credenciales y un botón de confirmación («Continuar») que debe pulsar una vez haya migrado sus sistemas a la nueva clave, como se muestra en la Ilustración 2.
Mientras no confirme, el sistema reenvía recordatorios periódicos (semanales) con un nuevo enlace si el anterior ha expirado.

Ilustración 2. Mail de notificación con enlace seguro de un solo uso 

6. Cierre del proceso (AWS Lambda)

Tras recibir la confirmación del propietario, la función Lambda ejecuta las acciones de cierre:

• Desactiva la Access Key antigua en la cuenta destino.
  Elimina el secreto almacenado en Secrets Manager.
  Programa la eliminación definitiva de la clave antigua tras un periodo de gracia de 7 días, transcurrido el cual se borra de forma irreversible.

Rotación bajo demanda mediante portal de autoservicio

Aunque el proceso de rotación se ejecuta automáticamente en función de la antigüedad de la clave, también se habilita un mecanismo de rotación bajo demanda.

Ilustración 3. Portal de rotación de Access Key bajo demanda

A través del portal interno de autoservicio, un usuario puede solicitar la renovación inmediata de credenciales simplemente indicando:

• Nombre del usuario IAM y cuenta AWS.
• O directamente el identificador de la Access Key.

Esta acción inicia el flujo automatizado de rotación. Sin embargo, la ejecución no es inmediata: el sistema envía primero una notificación al propietario identificado de la credencial, quien debe aprobar explícitamente la operación.

Una vez aprobada, se continúa con el proceso de creación de la nueva Access Key y su distribución segura al propietario de esta. Este enfoque garantiza que el control permanece en el propietario, independientemente de quién haya mandado la solicitud.

De este modo, se combina automatización programada con capacidad de reacción inmediata, manteniendo siempre el mismo estándar de seguridad.

Modelo de excepciones controladas

En cualquier organización grande, aplicar una política uniforme sin contemplar excepciones realistas suele generar fricción operativa. Desde el inicio se asumió que existirían cargas de trabajo que, por motivos técnicos o contractuales, no podrían cumplir estrictamente con el periodo estándar de rotación.

La clave no era eliminar las excepciones, sino gobernarlas.

Excepciones explícitas y aprobadas

En el modelo definido por Moeve:

• El periodo estándar de rotación es de 180 días.
• Cualquier ampliación requiere aprobación formal del equipo de Ciberseguridad.
• La excepción se materializa mediante un tag en el usuario IAM, que define el nuevo umbral.

Esto permite que el motor de decisión siga siendo completamente automático. No existen listas paralelas ni configuraciones manuales fuera del sistema.

Auditoría y trazabilidad

La solución mantiene trazabilidad completa mediante dos mecanismos:

• Un inventario centralizado que recoge el estado, antigüedad, propietario y excepciones de cada Access Key.
• Un registro de eventos en Amazon DynamoDB que almacena el histórico de rotaciones, confirmaciones y eliminaciones.

Esto permite auditar qué claves existen, su estado y quién ha validado cada cambio.

El sistema genera toda la información necesaria para que el equipo de ciberseguridad pueda tener una visibilidad completa del proceso.

Beneficios obtenidos

Tras la implantación del sistema, se observaron mejoras claras tanto en seguridad como en eficiencia operativa.

1. Reducción significativa de la superficie de ataque

Eliminar claves antiguas y limitar a una única Access Key activa reduce drásticamente el riesgo de compromiso prolongado. Como ejemplo Moeve ha conseguido reducir el tiempo de vida de las Access Keys, pasando de más de 1000 días en algunos casos a un máximo de 180 días.

2. Eliminación de claves huérfanas

Gracias a la resolución dinámica de posesión y la obligación de confirmación, se evitan situaciones donde nadie sabe quién utiliza una credencial determinada.

Cada Access Key tiene:

• Un responsable identificado.
• Un ciclo de vida claro.
• Un estado trazable.

3. Seguridad integrada en el flujo operativo

La rotación deja de ser una actividad reactiva o puntual y pasa a ser un proceso continuo y automatizado.

4. Escalabilidad organizacional

El sistema está preparado para operar en múltiples cuentas gestionadas mediante AWS Organizations, sin necesidad de intervención manual en cada una de ellas.

5. Mayor madurez en gobernanza Cloud

Más allá del control técnico, el mayor beneficio ha sido cultural:

• Los equipos entienden que las credenciales tienen un ciclo de vida.
• Las excepciones requieren justificación.
• La responsabilidad está claramente definida.

La automatización refuerza la disciplina organizativa.

Limitaciones

Como cualquier modelo de gobernanza a escala, esta solución implica ciertas limitaciones que deben tenerse en cuenta antes de su adopción:

• Las Access Keys siguen siendo credenciales estáticas.
  Aunque el sistema reduce significativamente el riesgo asociado a claves antiguas o sin trazabilidad, las Access Keys continúan siendo secretos de larga duración en comparación con credenciales temporales. Por ello, esta solución debe entenderse como un mecanismo de reducción de riesgo, no como un sustituto de modelos basados en roles o certificados.
• Dependencia de la confirmación humana.
  Aunque la ejecución técnica de la rotación es completamente automática, el proceso requiere que el propietario confirme que ha actualizado su sistema antes de deshabilitar la clave anterior. Esto introduce un punto de dependencia humana que puede retrasar el cierre definitivo del ciclo de vida si no se gestiona adecuadamente mediante recordatorios y seguimiento automatizado.

En el caso de Moeve, estas limitaciones son asumibles porque forman parte de una estrategia más amplia orientada a reducir progresivamente el uso de Access Keys y migrar hacia modelos basados en credenciales temporales y certificados mediante IAM Roles Anywhere. La gestión automatizada de claves no es el estado final, sino una etapa intermedia dentro de un modelo de identidad más moderno y robusto.

Resultados

Con esta solución, Moeve ha integrado la rotación de Access Keys en su modelo operativo, reduciendo riesgos sin afectar a la continuidad de las cargas de trabajo. Los principales resultados son:

• Rotación automatizada, consistente y controlada de Access Keys.
• Una única clave activa por usuario en condiciones normales, reduciendo la superficie de exposición.
• Gestión de excepciones formal y auditable, integrada en el modelo de gobernanza.
• Escalabilidad multi-cuenta sin intervención manual.

Conclusiones

La solución resuelve con éxito el reto de gestionar Access Keys a escala en Moeve y convierte la seguridad en un habilitador estructural de la innovación segura a escala, en lugar de una actividad reactiva.

Para aplicar este enfoque en otros contextos, conviene tener en cuenta algunos aspectos:

1. Es el enfoque adecuado únicamente cuando se necesitan Access Keys fijas. Siempre que sea posible, es preferible evolucionar hacia credenciales temporales.
2. Requiere un modelo de gobernanza claro sobre propiedad, excepciones y ciclo de vida.
3. Se beneficia enormemente del apoyo del CCoE para impulsar la adopción.
4. La integración con sistemas legacy puede requerir adaptaciones específicas.
5. Persisten pasos manuales acotados, candidatos a futuras iteraciones de automatización.

Si tienes preguntas o comentarios sobre esta solución, no dudes en dejar un comentario en este blog.

Autores

	Rayco Martínez Head of Cloud Governance / Cloud CoE en Moeve. Rayco es un arquitecto Cloud con más de 20 años de experiencia en la industria energética, especializado en gobernanza cloud, cumplimiento normativo y transformación digital. Su pasión reside en diseñar e implementar soluciones cloud escalables, seguras y eficientes que impulsen la innovación empresarial.
	Pablo Martínez Cloud Engineer en Keepler Data Tech, enfocado en arquitecturas serverless y soluciones cloud en AWS. Le apasiona construir sistemas escalables y resilientes que habiliten la transformación digital mediante tecnologías cloud modernas.
	Ignacio Rodríguez García Technical Account Manager en AWS. En su rol, Ignacio proporciona orientación técnica estratégica para ayudar a los clientes a planificar y construir soluciones utilizando las prácticas recomendadas de AWS. Posee un máster en Ingeniería por Télécom Paris y un título de Ingeniero de Telecomunicaciones por la Universidad Politécnica de Madrid (UPM).