Rotación de claves en arquitecturas complejas: orden, pasos y evidencia

Rotar una credencial suena a tarea mecánica: generar una nueva, sustituir la vieja, listo. En una arquitectura con un puñado de servicios es casi así de simple. El problema aparece cuando esa misma clave está copiada en seis sitios distintos, la usa un proceso batch que solo arranca de madrugada y nadie recuerda si hay una tarea programada que todavía apunta a la versión anterior. Ahí la rotación deja de ser un cambio de valor y pasa a ser un proyecto con orden, verificación y, si algo sale mal, un corte de servicio que nadie había previsto.

Lo que sigue es el procedimiento que aplicamos cuando planificamos una rotación de credenciales en sistemas con varios servicios dependientes entre sí, sin entrar en ningún proveedor ni herramienta concreta porque el patrón vale igual para una base de datos, una API externa o un certificado interno.

El inventario que casi nadie tiene actualizado

Antes de tocar nada hace falta responder a dos preguntas por cada credencial: quién la usa y dónde está copiada. Parecen la misma pregunta pero no lo son. Un servicio puede usar una credencial sin que nadie la tenga guardada en su configuración, porque la hereda de una variable de entorno que a su vez viene de otro sistema. Y una credencial puede estar copiada en un script de despliegue, en una tarea programada, en el portátil de alguien que la metió en un fichero local para probar algo hace meses y nunca lo borró.

El inventario tiene que recoger ambas cosas por separado. Para cada credencial anotamos el servicio o entorno al que pertenece, la lista de consumidores que la usan en tiempo de ejecución y la lista de sitios donde está almacenada en texto plano o cifrado: ficheros de configuración, gestores de secretos, variables de entorno, scripts de infraestructura, incluso documentación interna que a veces incluye ejemplos con valores reales por descuido.

Un esquema simple, pero suficiente para empezar, puede tener este aspecto:

credencial: db-pedidos-produccion
tipo: contrasena-base-datos
consumidores:
  - servicio-api-pedidos
  - job-conciliacion-nocturna
  - script-backup-diario
almacenada_en:
  - gestor-secretos/produccion/db-pedidos
  - variable-entorno: DB_PEDIDOS_PASS (servicio-api-pedidos)
  - fichero-config: /etc/batch/conciliacion.conf

Sin este mapa, el patrón de doble credencial que viene después se convierte en una lotería: puedes desplegar la clave nueva en los tres sitios que recuerdas y dejar viva, sin saberlo, una cuarta copia que seguirá autenticándose con la antigua hasta que la revoques y algo deje de funcionar sin previo aviso.

El orden importa, primero lo que otros necesitan

Una vez está el inventario, toca decidir el orden de rotación. La regla es sencilla de enunciar y fácil de saltarse bajo presión: rota primero lo que otros servicios necesitan para arrancar, y deja para el final lo que depende de ellos.

Imagina una arquitectura con un servicio de autenticación central, una API de negocio que valida tokens contra ese servicio y un panel de administración que consume la API. Si rotas primero la credencial del panel, no pasa nada grave si algo falla: el impacto se queda en un único consumidor. Pero si rotas primero la credencial del servicio de autenticación sin haber verificado que todos sus consumidores soportan el cambio, puedes dejar sin arrancar a toda la cadena que depende de él.

Por eso el orden práctico suele ser:

• •Credenciales de infraestructura base (bases de datos, colas de mensajes, almacenamiento) que usan varios servicios.
• •Credenciales de servicios intermedios que otros consumen (autenticación, pasarelas internas).
• •Credenciales de los servicios de cara al usuario o de uso puntual, que suelen tener menos dependientes.

El riesgo sigue existiendo, pero así, si algo falla, falla en el punto donde el radio de impacto es más pequeño y más fácil de diagnosticar.

Crear, desplegar, comprobar y solo entonces retirar

El patrón central de cualquier rotación sin corte tiene cuatro pasos, y el orden no se negocia:

Crear la credencial nueva sin tocar la vieja

La nueva credencial convive con la antigua desde el primer momento. Esto exige que el servicio o proveedor que emite la credencial permita tener dos válidas a la vez, aunque sea durante una ventana corta. Si no lo permite, el patrón cambia, y lo tratamos en el siguiente apartado.

Desplegar la nueva en cada consumidor del inventario

En este paso, el inventario de la primera sección se convierte en una lista de tareas. Cada consumidor identificado recibe la credencial nueva, uno por uno, sin prisa. Es el momento de descubrir copias olvidadas: si un consumidor sigue fallando después de haberlo actualizado, probablemente haya una segunda copia de la credencial vieja en algún sitio que el inventario no recogió.

Comprobar que la nueva funciona en cada punto

Desplegar la credencial no garantiza que funcione, así que cada punto se verifica. Para una credencial de base de datos, por ejemplo, una comprobación mínima es forzar una conexión de prueba con las nuevas credenciales y confirmar una respuesta válida:

# comprobación genérica de conexión con la credencial nueva
if ! check-connection --cred-file nueva-credencial.env; then
  echo "La credencial nueva no funciona en este consumidor, no retirar la vieja"
  exit 1
fi
echo "Conexión verificada con la credencial nueva"

El objetivo de este paso es tener constancia explícita, no una suposición, de que cada consumidor ya está usando la credencial nueva y funciona con ella.

Retirar la vieja y verificar que efectivamente falla

Solo cuando todos los consumidores han confirmado el cambio se revoca la credencial antigua. Y aquí hay un paso que se olvida con frecuencia: después de revocarla, hay que comprobar que efectivamente deja de funcionar. Si la vieja credencial sigue autenticando después de haberla retirado, algo no se revocó donde debía, y eso es tan grave como el fallo contrario.

Cuando el proveedor no da margen para convivir

No todos los sistemas permiten dos credenciales activas a la vez. Algunos proveedores invalidan la anterior en el mismo instante en que se genera la nueva, sin ventana de solapamiento. En ese caso el patrón de doble credencial no es posible tal cual, y hace falta planificar una ventana de corte explícita: se avisa con antelación, se elige un horario de bajo uso, se despliega la credencial nueva en todos los consumidores de forma simultánea o en una secuencia lo más corta posible, y se acepta que durante ese intervalo habrá servicios que fallarán hasta que reciban el valor actualizado.

La diferencia con una rotación improvisada es que esta ventana se decide y se comunica de antemano, y tiene un límite de tiempo. En una rotación improvisada, el corte aparece porque alguien no se dio cuenta de que el proveedor invalidaba la clave anterior al momento.

Una credencial por servicio y por entorno

Buena parte de las rotaciones complicadas tienen su origen en un error anterior: reutilizar la misma credencial en varios servicios o en varios entornos para ahorrar trabajo de configuración. Si la credencial de producción es la misma que la de pruebas, rotarla en producción obliga a tocar también el entorno de pruebas, y viceversa. Si un mismo valor se usa en dos servicios distintos, el inventario de consumidores se duplica y el riesgo de dejar una copia sin actualizar se multiplica.

La segregación es la medida preventiva más barata de las que se mencionan en este artículo: cada servicio y cada entorno con su propia credencial, sin valores repetidos entre ellos. No evita tener que rotar, pero reduce drásticamente el número de consumidores afectados por cada rotación y hace que el inventario sea mucho más fácil de mantener al día.

Dejar rastro de cada paso

En un proceso de adecuación al Esquema Nacional de Seguridad, además de hacer bien la rotación de credenciales, hay que poder demostrar cómo se hizo. Eso significa registrar, para cada rotación, qué credencial se rotó, en qué fecha, qué consumidores la recibieron, cómo se verificó que funcionaba en cada uno y cuándo se revocó la anterior, junto con la comprobación de que efectivamente dejó de aceptarse.

Un registro mínimo, por ejemplo en forma de ficha por rotación, puede recoger esto:

Credencial rotada: db-pedidos-produccion
Fecha de creación de la nueva: 2024-XX-XX
Consumidores desplegados y verificados:
  - servicio-api-pedidos (verificado 2024-XX-XX, hora)
  - job-conciliacion-nocturna (verificado 2024-XX-XX, hora)
  - script-backup-diario (verificado 2024-XX-XX, hora)
Fecha de revocación de la vieja: 2024-XX-XX
Comprobación de revocación: intento de conexión con credencial antigua, resultado rechazado

Esta ficha, acumulada rotación tras rotación, es la evidencia que un auditor del ENS pide ver cuando revisa el control de gestión de claves: no basta con decir que se rota periódicamente, hay que poder enseñar cuándo, cómo y con qué resultado.

Errores que aparecen una y otra vez

Casi todos los incidentes de rotación que acaban en corte tienen el mismo origen: se salta alguno de los pasos anteriores, no un fallo técnico exótico. Los más habituales:

• •Revocar la credencial vieja antes de haber comprobado que todos los consumidores usan ya la nueva, confiando en que el despliegue salió bien sin verificarlo.
• •No comprobar que la credencial vieja realmente deja de funcionar tras revocarla, dejando un acceso abierto que nadie detecta hasta que alguien lo aprovecha o aparece en una revisión.
• •Rotar sin inventario completo, descubriendo consumidores ocultos a mitad de proceso, normalmente en el peor momento posible.
• •Reutilizar la misma credencial entre entornos, lo que convierte una rotación local en una rotación que afecta a sistemas que no tenían por qué verse implicados.

Este patrón no ahorra planificación, pero le da un orden fijo. Antes de programar la próxima rotación, conviene dedicar una sesión solo a actualizar el inventario de consumidores: es el paso que más tiempo ahorra cuando llega el momento de ejecutar.