Un canal de control infalsificable: TOFU + firma asimétrica
Cuando un sistema puede enviar comandos a las máquinas de los clientes, la pregunta más importante es: ¿quién está realmente autorizado a enviarlos? La respuesta intuitiva —«una contraseña interna secreta»— es más débil de lo que parece. Aquí está por qué elegimos algo más fuerte.
La idea intuitiva: un secreto compartido
La idea obvia: hay una «contraseña interna» que solo el sistema conoce, y cada comando se verifica contra ella. Si algo ajeno intentara inyectar un comando, no conoce el secreto, así que falla. Suena razonable.
Pero hay una debilidad aquí: para verificar un comando, el secreto debe estar presente en el punto de verificación. Si nuestra nube o el equipo es vulnerado, el secreto es legible, y el atacante falsifica comandos a voluntad. Un secreto compartido (aunque sea rotativo) se rompe en el momento en que alguien lo ve.
Qué elegimos: firma asimétrica
En lugar de un secreto compartido, usamos un par de claves asimétricas. El operador tiene una clave privada que nunca lo abandona, y cada comando se firma con ella. El agente en el equipo posee únicamente la clave pública, que puede verificar una firma, pero no puede falsificarla.
La diferencia es fundamental: una brecha total de nuestra nube y del equipo del cliente no puede falsificar un comando, porque la clave privada sencillamente no está presente en ninguno de esos lugares. Nuestra nube solo retransmite el comando firmado: no verifica ni ejecuta nada.
Segundo refuerzo: TOFU — anclaje de claves
Pero ¿qué pasa si un atacante que vulneró nuestra nube cambia la clave pública por la suya? Entonces podría firmarse a sí mismo. Para cerrar esto, añadimos TOFU (Trust On First Use): el agente ancla la clave del operador una sola vez, en la inscripción inicial. En cada comprobación posterior, verifica que la clave que presenta la nube es idéntica a la anclada, y si no lo es, la rechaza.
Rotar la clave es, por tanto, una acción deliberada fuera de banda, no una sobrescritura silenciosa desde la nube. Un atacante que tomó el control de nuestra nube no puede cambiar la clave anclada: el agente sencillamente no aceptará el cambio.
Tercer refuerzo: sin shell libre
Aunque de algún modo se produjera una firma válida, queríamos que el daño posible estuviera acotado. Por eso las acciones son una lista blanca finita y paramétrica (como reiniciar o reiniciar-servicio), y no hay ninguna acción de «ejecutar comando arbitrario». Eliminamos deliberadamente cualquier ruta que pase una cadena a un shell. Ni siquiera una firma válida llega a un shell root.
Cómo lo probamos
Verificamos el modelo en el comportamiento, no solo en la teoría: simulamos el escenario en el que la nube presenta una clave distinta de la anclada, y confirmamos que el agente efectivamente rechaza (rc=2) y no ejecuta. Ese patrón —anclar → verificar → rechazar— es el núcleo de nuestra resiliencia de cadena de suministro.
Cómo lo seguimos mejorando: control de calidad continuo
La confianza no es «configurar y olvidar». Cada comando se escribe en un registro de auditoría inmutable (quién, cuándo, qué, qué firma), de modo que cualquier acción puede reconstruirse a posteriori. Los próximos pasos ya planificados: anti-replay (nonce + marca de tiempo en la forma canónica, para que un comando antiguo no pueda reenviarse), un token por servidor en lugar de un token compartido, y un «interruptor de emergencia» a nivel de cliente. También nos atacamos a nosotros mismos (purple-team autorizado) para probar que las defensas realmente se sostienen. Esta capa se hace cada vez más fuerte.
Este artículo describe el modelo de confianza a nivel de principio, y eso es en realidad una fortaleza al publicarlo, porque saber cómo funciona la defensa no ayuda a un atacante (la clave privada no se expone). No hay aquí claves, secretos ni detalles de implementación sensibles.
← Todos los artículos