Zero Trust, VPN e inspección TLS hacen trabajos distintos

Los documentos de compra tratan zero trust, VPN e inspección TLS como si fuera la misma compra, y cada uno responde una pregunta que los otros no pueden. Un túnel construye una ruta protegida, una puerta de inspección lee el tráfico que puede terminar, y una política decide si una identidad nombrada puede ejecutar una operación nombrada sobre un recurso nombrado. Solo la última es una decisión de autorización. Un producto puede hacer perfectamente las dos primeras y aun así dejar abierta la pregunta real.

Tres mecanismos, tres preguntas

El túnel responde cómo llega el tráfico a la red. Una puerta de inspección responde qué puede ver y hacer un elemento intermedio donde está autorizado a terminar TLS. Un motor de políticas responde quién puede hacer qué a qué recurso, y luego necesita un punto de aplicación capaz de aplicar esa respuesta. La arquitectura zero trust de NIST pone el recurso en el centro y se niega a inferir confianza de dónde vino un paquete.

Ese planteamiento es más difícil de satisfacer que una etiqueta, y mucho más difícil de falsificar en una revisión. También mueve la pregunta desde qué productos están desplegados hacia qué decisiones se aplican y mediante qué.

Dónde se aplica realmente la decisión

Tome una solicitud: un ingeniero de soporte abre una consola de servicio, y una máquina personal conectada al mismo conmutador no debe heredar ese permiso solo por estar cerca. Anote la operación permitida, las condiciones del dispositivo y el componente que las aplica. La ubicación decide todo: una puerta de aplicación, un proxy de servicio, un control de host u otra frontera que la organización realmente soporte. Sea cual sea ese componente, tiene que estar en la ruta de los intentos remotos y de los locales.

El tráfico que nunca cruza la entrada de la VPN no se rige por una comprobación hecha allí, por exhaustiva que sea. Esa única brecha explica la mayor parte de la distancia entre un diagrama de zero trust y un despliegue que funciona. Dibuje la ruta de la solicitud antes de dibujar la arquitectura.

Descifrar no es autorizar

La interceptación sirve a objetivos de inspección estrechos y carga con su propia mochila de certificados, raíces de confianza, revisión de privacidad y aplicaciones que se rompen bajo ella. Nada de eso es lo que significa zero trust, y nada de eso sustituye una decisión de política. Autenticar a una persona y autorizar un servicio es del todo posible sin descifrar un solo paquete. Un flujo descifrado no dice nada sobre si el usuario tenía derecho a la operación que lleva dentro.

La política necesita un tipo de prueba, y el descifrado no lo es. La salud del dispositivo es una entrada entre la identidad, la sensibilidad del recurso y el contexto, y pasarla una vez no le entrega a esa máquina el resto de la red. Mezclar las dos convierte una pregunta de autorización en un proyecto de certificados.

Cuando la puerta no está en ninguna parte de la ruta

Inventaríe lo que viaja sin tocar la puerta remota: enlaces entre máquinas del segmento local, llamadas de una carga de trabajo a otra y extremos alcanzados directamente dentro de una cuenta de nube. Para cada ruta, nombre un método de aplicación que realmente pueda desplegarse hoy. El equipo que no puede alojar un agente sigue necesitando otro control admitido de forma explícita, y suponer que el agente llegará más tarde no cierra nada ahora. El acceso de servicio a servicio suele encajar mejor con la identidad de carga de trabajo y una comprobación escrita contra el recurso que con otra red superpuesta.

Acepte el diseño por comportamiento y no por diagramas: qué operaciones se permiten, cuáles se deniegan y dónde se aplica cada respuesta. Firme operaciones concretas permitidas y denegadas, e incluya una ruta local que nunca llegue a la puerta. Deje constancia de quién es dueño de la política, cómo cambia y cómo funciona la revocación.

Un túnel reetiquetado sigue siendo un túnel. Una política decide, y algo tiene que aplicarla.