La rotación que nadie hace, porque rompe cosas

Todas las políticas de seguridad dicen que las credenciales se rotan cada noventa días. Casi ninguna se rota. Cuando preguntas por qué, la respuesta es siempre el mismo incidente: alguien rotó la contraseña de una base de datos, tres servicios que la habían leído al arrancar siguieron usando la antigua, y la caída resultante fue peor que el riesgo que la rotación atacaba. Después de eso, la rotación se convirtió en una casilla trimestral que nadie marca con honestidad.

La política no estaba mal. El orden sí. La rotación no es un problema de planificación, es un problema de diseño de la aplicación, y hasta que la aplicación no pueda recoger una credencial nueva sin reiniciar, no hay automatización que sea segura de encender.

El patrón que vuelve aburrida la rotación

El mecanismo que funciona son dos credenciales válidas a la vez.

Para una base de datos, eso significa dos usuarios en vez de una contraseña que se intercambia. El trabajo de rotación crea o actualiza el segundo usuario con una contraseña nueva, espera a que las aplicaciones la recojan, verifica que nada sigue autenticándose como el primero, y solo entonces lo invalida. Los gestores de secretos de las nubes implementan esto como una estrategia de usuarios alternos, y la razón de que sea el valor por defecto de sus plantillas es que la versión de un solo usuario provoca caídas.

Para una clave de API con un proveedor que admita varias claves activas, la misma forma: crea la clave nueva, despliégala, confirma que el tráfico se ha movido, revoca la vieja. La revocación es un paso aparte, días después, condicionado a la evidencia y no a un temporizador.

El invariante al que agarrarse: siempre hay una ventana en la que la credencial vieja y la nueva autentican correctamente. Si tu proveedor solo permite una credencial activa, no puedes rotar sin caída, y eso es un hallazgo de contratación que merece la pena plantear.

La aplicación tiene que releer, y casi ninguna lo hace

Este es el trabajo de verdad, y no tiene ningún glamur.

Un servicio que lee una cadena de conexión de una variable de entorno al arrancar el proceso no verá jamás una rotación. Las variables de entorno quedan fijas al ejecutarse. El arreglo es uno de tres, por esfuerzo creciente:

• Buscar de forma programada y refrescar en el sitio. Una tarea en segundo plano que recarga el secreto cada pocos minutos y lo cambia en la fábrica de conexiones. Simple, y suficiente para la mayoría de los servicios.
• Fallar y reintentar con una nueva lectura. Ante un error de autenticación, vuelve a leer el secreto y reintenta una vez antes de propagar el fallo. Esto cubre el caso en que la rotación ocurrió entre dos refrescos, y merece tenerlo incluso junto a la programación.
• Un sidecar o un controlador de almacenamiento que escribe el secreto en un fichero montado, con la aplicación vigilando el fichero. Saca el refresco del código de la aplicación y es la respuesta correcta cuando tienes muchos servicios en muchos lenguajes.

Las reservas de conexiones son la trampa concreta. Una reserva que autentica una vez y mantiene conexiones abiertas durante horas seguirá funcionando después de la rotación y fallará de golpe cuando la reserva se recicle, lo que parece una caída aleatoria a las cuatro de la madrugada sin ningún despliegue al que culpar. Fija una vida máxima de conexión para que las credenciales se vuelvan a presentar con regularidad, y prueba la rotación con la reserva bajo carga y no sobre un servicio ocioso.

Algunas credenciales hay que borrarlas, no rotarlas

Una parte apreciable de lo que los equipos planean rotar no debería existir.

Las claves de acceso de larga vida para la integración continua están en esa categoría. Rotarlas de forma programada es gestionar un riesgo que puedes eliminar: federa el pipeline con la nube usando tokens de vida corta y la credencial desaparece del todo, que es el argumento de sacar las claves de larga vida de la integración continua.

Lo mismo aplica a las claves de cuenta de servicio, que son la credencial que se filtra con más fiabilidad, como se cuenta en las claves de cuenta de servicio en Google Cloud. La federación de identidad de carga de trabajo las sustituye. Y lo mismo con los tokens de acceso personal usados como credencial de máquina, las cuentas compartidas con una contraseña en un almacén y los tokens de larga vida en manos de integraciones de terceros que admiten un flujo de código de autorización.

Pasa este filtro sobre el inventario antes de construir ninguna automatización de rotación. Cada credencial que borras es una que no tienes que rotar, vigilar ni explicarle a un auditor.

En el extremo de este razonamiento está la generación dinámica: una credencial emitida por sesión con un arrendamiento corto, de modo que la rotación se vuelve continua e invisible. Esa capacidad es el argumento más fuerte de la decisión que se discute en Vault o el gestor de secretos de tu nube.

No puedes rotar lo que no has encontrado

El inventario es el paso que los equipos se saltan, y es la razón de que los programas de rotación se atasquen. Un gestor de secretos guarda los secretos que alguien metió en él, que no es lo mismo que todos.

Construye la lista desde varias direcciones a la vez. Enumera lo que hay en los gestores de secretos y almacenes de claves. Escanea los repositorios de código y su historial completo. Escanea las imágenes de contenedor, que con frecuencia arrastran credenciales de compilación en alguna capa. Revisa los almacenes de variables de integración y despliegue, los ficheros de estado de la infraestructura, que guardan valores en claro, y los datos de gestión de configuración. Y después pregunta a cada equipo qué usa que no esté en la lista, porque siempre hay algo en una página de wiki.

Anota cuatro cosas por entrada: contra qué autentica, quién o qué la usa, cuándo se creó, y si hoy se puede rotar sin caída. Esa última columna es tu cola de trabajo, y suele ser la más corta.

Prioridad, porque no puedes hacerlas todas a la vez

Ordena por lo que se lleva un atacante, no por antigüedad. Una credencial de lectura y escritura en la base de datos de producción usada por cuatro servicios va por delante de un token de noventa días para un webhook de preproducción.

Las credenciales que hay que atender primero son las que tienen acceso amplio de escritura a datos de producción, las que dan acceso al propio sistema de identidad o de secretos, las compartidas entre más de un sistema, las que están en manos de un tercero, y las que alguna vez han estado en un sitio donde no debían.

Cualquier cosa del último grupo no es una rotación, es un incidente.

Cuando un escáner encuentra una

En el minuto en que se encuentra un secreto en un repositorio, un log o una imagen, la secuencia es fija y el orden importa.

Revoca primero. No rotes, revoca: da por hecho que está comprometida. Después comprueba qué hizo. Saca los registros de auditoría de esa credencial y busca uso desde direcciones inesperadas, en horas inesperadas o para operaciones inusuales. Este paso es lo que convierte una filtración en una evaluación acotada en vez de en una conjetura, y depende de tener el registro de auditoría puesto de antemano.

Luego emite el reemplazo y luego limpia la exposición. Quitar el secreto del repositorio es el último paso y el menos importante, porque el historial de git está distribuido y deberías asumir que el valor es público desde el momento en que se empujó. Reescribir el historial no lo despublica. Las herramientas y el flujo están en escaneo de secretos con Gitleaks y TruffleHog.

Por último, déjalo registrado. Una credencial filtrada que podía leer datos personales puede ser un evento notificable, y esa evaluación pertenece al proceso de incidentes con una persona decisora nombrada.

Lo que se olvida

• La rotación necesita rastro de auditoría. Si no puedes demostrar cuándo cambió por última vez una credencial, no puedes responder a la pregunta real del auditor.
• Las claves de cifrado rotan de otra forma. Rotar una clave que cifra claves es barato; volver a cifrar los datos que hay debajo no lo es. Usa cifrado en sobre para que las dos cosas sean separables.
• Los certificados también son credenciales. Los certificados automáticos de vida corta eliminan toda una clase de caídas, y la caducidad es una causa principal de incidentes reales.
• Prueba la rotación en preproducción con carga con forma de producción. Un servicio ocioso siempre sobrevive a una rotación. Uno ocupado es donde muerde la reserva de conexiones.
• Alerta cuando falle la rotación. Un trabajo de rotación que se detiene en silencio es peor que no rotar, porque el panel dice noventa días y la realidad dice tres años.

Qué hacer esta semana

Coge la credencial más importante de tu base de datos de producción y responde a una pregunta: si cambiara ahora mismo, qué servicios se romperían. No razones sobre ello, mira en el código dónde se lee el secreto. Si la respuesta es "al arrancar", has encontrado por qué la rotación no ha ocurrido nunca, y arreglar ese servicio es el principio del programa. Arrancamos la línea de credenciales de un proyecto de seguridad con exactamente esa comprobación.