Dónde deben vivir las credenciales del panel

Todo panel de control alojado para automatización de servidores pide lo mismo en su asistente de configuración: la dirección del hipervisor, un token de API, las credenciales de root del panel de alojamiento web. Y después las guarda, porque las necesita en cada petición.

Que el software lo pida es razonable; haberlo aceptado es genuinamente incómodo. Se acaba de entregar a la base de datos de un tercero la capacidad de borrar todas las máquinas propias. No por un fallo ni por malicia: ese es el comportamiento normal, documentado y correcto del producto.

Conviene ser preciso sobre lo que aportan realmente las alternativas, porque «las ciframos en reposo» es la respuesta que da todo el mundo y por sí sola no significa casi nada.

Cifradas en reposo, ¿descifradas por quién?

Si un SaaS guarda cifrado el token del hipervisor, la clave tiene que estar en algún sitio al que ese mismo SaaS pueda llegar, porque tiene que usar el token por cuenta del cliente mientras este duerme. El cifrado en reposo protege frente a un disco robado y frente a una copia de seguridad filtrada. No protege frente a lo que de verdad preocupa, que es que la plataforma misma quede comprometida.

Eso no es un argumento contra cifrar en reposo. Es un argumento de que la pregunta «¿dónde está la clave?» es la única pregunta, y de que un plano de control que puede descifrar es un plano de control al que se le puede obligar a descifrar.

La alternativa estructural es la tercera fila: no tener el secreto en absoluto. Suena a frase fácil, hasta que se mira lo que cuesta organizarlo.

Guardar el secreto donde está la máquina

La forma que funciona: un agente pequeño se ejecuta dentro de la red del propio cliente, guarda las credenciales localmente y conecta hacia fuera con la plataforma. La plataforma envía instrucciones. El agente guarda las llaves.

Eso invierte el radio de daño. Quien comprometa el plano de control puede ahora emitir comandos, lo cual es malo y a lo que volveremos, pero no puede llevarse un fichero lleno de tokens de hipervisor de todos los clientes, porque ese fichero no existe.

Las piezas que lo hacen real no tienen ningún glamour.

La caja fuerte, y de qué protege honestamente

Nuestro agente guarda las credenciales en un fichero local cifrado con XChaCha20-Poly1305. La clave no es el fichero del disco: se deriva con HKDF a partir de un fichero de clave mezclado con la identidad de la propia máquina, y los datos autenticados adicionales atan el texto cifrado a la versión del formato y al identificador del agente.

La consecuencia práctica es la que merece la pena tener presente al diseñar. Si se copian el fichero de clave y la caja fuerte a otra máquina, no se abre. Si se restaura en otro host la copia de seguridad del mes pasado del directorio de datos, no se abre. Todos los modos de fallo (clave equivocada, agente distinto, bytes alterados) producen el mismo error indistinguible, que es justo lo que se busca.

Esta es la parte que debería estar en la documentación de todo producto que hace esto, y que normalmente no está. Esto no protege frente a root en el host. No puede, y no le hace falta: el cliente es dueño del host y dueño de las credenciales. De lo que protege la caja fuerte es de un fichero filtrado, no del propietario de la máquina. Un proveedor que insinúe otra cosa está vendiendo una sensación.

Las credenciales nunca tocan la base de datos de la plataforma

Esta es la parte que es fácil hacer mal creyendo que se ha hecho bien, porque el código tiene buen aspecto en ambos casos.

Cuando alguien escribe un token de hipervisor en nuestro panel, la fila que entra en la tabla de comandos contiene solo nombres de campo. Los valores viajan en un mensaje transitorio aparte que no se almacena, y van directos a la entrega al agente. El despachador nunca los registra y nunca los persiste.

Quien evalúe un producto por esto no debería preguntar «¿se guardan credenciales?». La pregunta es «¿qué hay en el registro de auditoría y qué hay en la cola de trabajos?». Una cola que lleva el secreto es una base de datos que lleva el secreto con pasos de más.

Borrar un secreto es un problema distinto de guardarlo

Eliminar una integración en el panel tiene que acabar con las credenciales desapareciendo de una máquina que no se controla, y eso es un problema más difícil de lo que parece.

La implementación obvia es una reconciliación: preguntar al agente qué tiene, comparar con lo que la base de datos dice que debería tener y borrar la diferencia. Es más corta y es peligrosa, porque la resta falla hacia no queda nada. Una lectura fallida, una lista truncada, y ya se ha generado una instrucción para borrar todas las integraciones que funcionan en ese host, y esas credenciales no se recuperan sin que el cliente vuelva a escribirlas.

Así que la instrucción nace únicamente de conocimiento positivo: existe una fila porque alguien eliminó de verdad una integración. Una lectura fallida produce cero filas y por tanto cero instrucciones, y el secreto se queda donde estaba, que es exactamente el estado anterior.

Se entrega dos veces: de inmediato por el bus de eventos, y otra vez en cada saludo de sesión, para el agente que estaba desconectado, el mensaje que se perdió, la pasarela que se reinició. Ambos caminos leen la misma tabla, así que no hay una segunda verdad ni un segundo orden.

Qué puede y qué no puede hacer un certificado de agente robado

Si el agente se autentica con un certificado de cliente, la pregunta honesta es qué ocurre cuando alguien se lo lleva. Ser concreto sobre esto es más útil que una página de seguridad.

Puede suplantar a ese agente concreto. El puerto de sesión exige TLS mutuo y, por encima de la comprobación de TLS, la huella del certificado del par se busca en la tabla de agentes, que tiene un índice único. Una huella apunta por tanto a exactamente un agente, y la identidad declarada en el saludo se contrasta con ella. Un atacante con el certificado se convierte en ese agente y puede enviar lo que un agente tiene permitido enviar: eventos de estado, resultados, telemetría.

No puede leer datos de otros clientes. Todo está acotado por la organización a la que pertenece el agente, resuelta a partir del certificado y no de nada que el cliente diga sobre sí mismo.

Por sí solo no entrega las credenciales. El certificado es la identidad que se usa para hablar con la plataforma. La clave de la caja fuerte es aparte, vive en el host y está atada a la identidad de máquina de ese host. Quien tenga las dos cosas tiene root en la máquina, y a esas alturas el certificado es lo de menos.

Deja de funcionar en cuanto se ordena, en un minuto aproximadamente. La revocación es un estado en la base de datos, no una CRL ni OCSP. Una conexión nueva se rechaza de inmediato. Una conexión existente se vuelve a comprobar en un intervalo de un minuto, así que un atacante ya conectado tiene como mucho eso. Si la propia comprobación de estado sigue fallando, la sesión se cierra tras tres fallos consecutivos en lugar de mantenerse abierta indefinidamente, lo que acota el peor caso en unos tres minutos.

Y el agente se limpia a sí mismo. Al ser revocado borra la caja fuerte, la clave de la caja fuerte, su identidad, su estado de sesión y sus colas, en ese orden, las credenciales primero. Cada paso se intenta y se registra por separado, porque medio borrado es mejor que ningún borrado.

Los certificados tienen además una vida corta, noventa días, y se renuevan automáticamente a mitad de camino con una comprobación cada hora. Eso no es tanto una defensa contra el robo como un límite al tiempo que sigue siendo útil un robo que nadie notó.

Lo que esto no arregla

Tres cosas, dichas con claridad, porque un modelo de amenazas sin riesgo residual es una página de marketing.

Un plano de control comprometido sigue pudiendo emitir comandos. No puede robar los tokens, pero sí puede decirle al agente que borre una máquina, y el agente lo hará. Mover los secretos mueve el radio de daño; no lo elimina. Lo que se gana a cambio es que el daño queda acotado por lo que la API sabe expresar y es visible en un rastro de auditoría, en lugar de ser un atacante que, con las credenciales propias, hace lo que quiere directamente contra el hipervisor a las tres de la madrugada.

Root en el host del agente lo lee todo. Por diseño. Si ese host queda comprometido, hay una máquina comprometida dentro de la red propia, y tiene las credenciales del hipervisor porque es ahí donde tienen que estar.

El borrado depende de que el agente vuelva. Si un host no se reconecta nunca, la instrucción de olvidar sus credenciales queda pendiente. Eso se ve en el panel en lugar de marcarse como hecho en silencio, que es el compromiso correcto, pero es una limitación real y conviene conocerla antes de depender de ella.

Preguntas que merece la pena hacerle a un proveedor

Sea cual sea la compra final, estas cinco separan los productos que se lo pensaron de los que escribieron un párrafo:

1. 01¿Dónde está la clave de descifrado, físicamente? Si la respuesta es «en nuestra plataforma», el cifrado en reposo protege frente al robo de un disco y frente a nada más.
2. 02¿Qué hay en el registro de auditoría y en la cola de trabajos? Los secretos se filtran a esos dos sitios mucho más a menudo que a la tabla que alguien cuidó.
3. 03¿Qué les ocurre a las credenciales al eliminar una integración, y se puede ver si realmente sucedió?
4. 04¿Cuánto tarda en aplicarse la revocación del acceso, y alcanza a las sesiones que ya están abiertas?
5. 05¿Hace falta algún puerto entrante? Una regla de cortafuegos que deja entrar el rango de IP de un proveedor hasta la interfaz de gestión del hipervisor es una segunda versión, más silenciosa, del mismo problema.

Así lo construimos en Provibr: el agente se ejecuta en el hardware del propio cliente, guarda las credenciales localmente y solo conecta hacia fuera.