Rotación y caducidad

Rotar una clave limita dos cosas: cuánto tiempo sirve una clave filtrada sin que nadie lo sepa, y cuántos datos quedan protegidos por una sola clave. No arregla una filtración conocida: si se sabe que la clave se expuso, hay que revocarla de inmediato, no esperar su turno de rotación.

En los servicios de claves la rotación de una clave de cifrado suele crear una versión nueva: las operaciones nuevas usan la versión nueva y los datos antiguos se siguen descifrando con la versión anterior, que se conserva. Por eso rotar no obliga a recifrar todo de golpe.

Una política de 180 días sin procedimiento detrás es un deseo. La columna procedimiento distingue lo automático, lo manual con responsable y lo que no tiene procedimiento alguno. Ese último caso es el más peligroso porque el día que haya que rotar con prisa, nadie sabrá dónde se usa ni cómo cambiarlo.

Un activo está fuera de política cuando su última rotación más los días de su política cae antes de la fecha de hoy, 7 de octubre de 2026. Cada activo tiene su propio plazo: 365 días para claves del servicio de claves y de firma, 180 para el secreto de API, 120 para la contraseña de servicio y 90 para los certificados, como indica la columna politica_dias. Suma los días a la fecha y compara.

La contraseña de la base de datos de reportes se rota a mano. Si se cambia en la base y en el servicio en dos momentos distintos, hay un hueco en el que las conexiones fallan. El patrón habitual es la rotación con solape: se crea la credencial nueva, se despliega al servicio, se comprueba que funciona y solo entonces se retira la anterior. Mejor aún, que la credencial viva en un gestor de secretos y que el servicio la pida al arrancar.