Engineering·Distribución de políticas

Por qué la política para agentes debe estar firmada.

Si un agente aplica una política que no puedes verificar criptográficamente, no tienes política. Tienes una sugerencia que dio la casualidad de llegar intacta.

La versión corta

  • Una política sin firmar puede alterarse en tránsito o en reposo; el agente no tiene forma de saberlo.
  • Firmar hace que la política sea verificable: el entorno demuestra que las reglas vigentes son exactamente las que tú redactaste.
  • El pull iniciado por el nodo significa que el entorno obtiene y verifica la política por sí mismo, sin requerir acceso entrante.
  • Los mismos artefactos firmados se mueven mediante transferencia offline controlada, así que los entornos aislados no son un caso especial.

La mayoría de los equipos aborda la gobernanza de agentes empezando por las reglas: qué puede tocar este agente, qué herramientas, qué datos. Ese es el contenido correcto. Pero debajo hay una pregunta que decide si algo de eso significa algo: cuando el agente aplica una política, ¿cómo sabe que la política es tuya?

Sin una respuesta, has construido gobernanza sobre la confianza en un transporte. Y los transportes se comprometen.

La amenaza es la brecha entre redactar y aplicar

La política se escribe en un lugar y se aplica en otro, a menudo en muchos otros: contenedores de desarrollo, runners de CI, hosts MCP, nodos de automatización. Entre esos dos puntos, un archivo de política viaja. En cualquier tramo de ese camino puede modificarse: un man-in-the-middle en la red, una caché envenenada, un artefacto alterado en un registro, un script bienintencionado que "corrige" un valor.

Si la única comprobación es "llegó el archivo", entonces un solo byte alterado (un deny convertido en allow, un patrón de secretos eliminado de la lista de bloqueo) pasa sin resistencia. El agente aplica la política del atacante y reporta éxito.

El peligro no es una política ausente. Es una política presente, plausible y ligeramente incorrecta que nadie puede detectar.

Firmar convierte "llegó" en "es auténtica"

Un bundle de política firmada lleva una firma criptográfica sobre su contenido exacto, producida con una clave que solo posee el lado que la redacta. El entorno verifica esa firma antes de aplicar nada. Ahora la comprobación no es "llegaron los bytes" sino "son estos exactamente los bytes que firmó el equipo de seguridad, sin cambios". Altera un solo carácter y la verificación falla.

Esto aporta tres propiedades concretas:

  1. Integridad. La política aplicada es, byte por byte, la política redactada.
  2. Autenticidad. Proviene de quien posee la clave de firma, no de cualquiera que pudiera escribir en el canal.
  3. Evidencia verificable. Como la firma cubre un hash conocido, el reporte que devuelve un entorno puede contrastarse con la política exacta que afirma haber aplicado.
Por qué ed25519. Verificación rápida, firmas pequeñas y un modelo de seguridad bien entendido. El lado del entorno ejecuta operaciones de verificación baratas todo el tiempo; el lado que redacta protege una sola clave privada. La asimetría encaja con el problema.

Pull iniciado por el nodo, no push central

Firmar responde ¿es esto auténtico? La distribución responde ¿cómo llega de forma segura? El instinto es un controlador central que empuja la política a cada entorno, lo que significa que ese controlador necesita acceso de red entrante a todos ellos. En un producto de seguridad, esa es precisamente la conectividad que no quieres exigir.

Así que inviértelo. El entorno ejecuta un node que inicia el pull. Obtiene el bundle firmado y un índice de pull firmado, verifica la huella de confianza, comprueba que el bundle está vinculado a este destino y que el número de secuencia solo avanza, y luego aplica localmente. Oktsec Control publica; el node sale a buscar. No existe ningún camino entrante hacia el entorno del cliente.

node · pull & verifypull iniciado por el nodo
1pull bundle + index (el node sale a buscar)
2verify fingerprint ok
3verify target binding ok
4verify sequence 14 > 13 ok
5apply locally · report seq 14 · 9c1f…a7
El entorno demuestra la autenticidad antes de aplicar, y reporta un hash que puedes comprobar.

Los entornos aislados usan el mismo mecanismo, no una versión especial

Aquí está la recompensa de poner la verificabilidad en el artefacto y no en la conexión: los entornos más restrictivos dejan de ser un producto aparte. A un bundle firmado no le importa si cruzó una red o una memoria USB. En un entorno aislado, el mismo artefacto se traslada mediante transferencia offline controlada, y el node lo verifica de la misma forma. Las comprobaciones de secuencia siguen impidiendo el rollback; las firmas siguen demostrando autenticidad. Los entornos de alta seguridad obtienen el camino normal, sin conexión.

El principio

Deposita la confianza en artefactos que puedes verificar, no en canales que tienes que defender. Firma la política para que la autenticidad viaje con ella, deja que los entornos hagan pull y verifiquen por sí mismos para no necesitar acceso entrante, y conserva el hash firmado para que la evidencia que regresa pueda contrastarse con las reglas exactas que debían estar vigentes. Esa es toda la cadena, desde la autoría hasta la aplicación, sin ningún eslabón que debas aceptar por fe.


Así distribuye Oktsec Control la política: bundles firmados, pull iniciado por el nodo, evidencia verificada. Conoce Oktsec Control →