Rotación automática de secretos

Para crear usuarios temporales en una base de datos, el motor de bases de datos del gestor necesita una cuenta con permiso para crearlos: la credencial raíz de esa conexión. Si se queda con la contraseña con la que se configuró, que alguien tecleó o copió desde otro sitio, esa persona sigue conociendo la llave maestra de todos los usuarios temporales. El gestor puede rotar esa credencial: genera una contraseña nueva que solo él conoce.

Por eso la credencial raíz entra en las políticas de rotación como un secreto más, y de los más importantes.

Una política de rotación solo funciona si se comprueba. El inventario inventario-rotacion.txt junta secretos de clave-valor, un rol estático con rotación automática y las credenciales raíz de dos conexiones. Mira cómo se rota cada uno y cuál es la fecha de su última rotación.

La política interna de Zurriago (en politica.txt) rota todo como máximo cada 90 días. Los secretos de clave-valor rotados a mano son los que suelen quedarse atrás, porque rotarlos es una tarea que nadie ve vencer.

La fecha de referencia es el 14 de octubre de 2026, de modo que lo anterior al 16 de julio de 2026 ya pasó del límite. Cuenta todos los elementos del inventario, de cualquier clase.

Rotar un secreto estático cambia su valor en el gestor, pero cada aplicación que lo tenía ya cargado sigue usando el viejo. Una aplicación que lo lee en cada uso recoge el nuevo sin enterarse. Una que lo guarda en memoria al arrancar seguirá usando el viejo hasta que alguien la reinicie, y fallará en cuanto el viejo deje de valer.

Mira consumidores.txt y piensa en rotar correo-smtp hoy.

Una rotación segura no cambia el valor en un solo golpe: pone primero el valor nuevo, deja un periodo en que las aplicaciones lo toman, y solo entonces anula el viejo. Cuando el proveedor del secreto lo permite, durante un tiempo valen los dos, y esa convivencia es lo que evita el corte.