Servicios sin puertos expuestos: Zero Trust embebido
Por Arturo Navarro · 15 de octubre de 2026
Un servicio que no escucha en ningún puerto no se puede escanear. Es la idea que separa el Zero Trust es el modelo de seguridad que NIST formaliza en SP 800-207: la ubicación de red no otorga confianza implícita y cada acceso se autentica y autoriza por separado. En banca y seguros acota el movimiento lateral tras el robo de una credencial; BlueUP lo aplica con identidad criptográfica por servicio.Leer más → Zero Trust embebido en la aplicación de las capas de red que se colocan alrededor de un puerto abierto: el servicio no publica ninguno y solo existe para las identidades que una política autoriza. Para una entidad financiera, el cambio tiene dos consecuencias medibles: hay menos superficie que defender, y la pregunta «quién puede llegar a este servicio» se responde leyendo una política, que es como el Reglamento Delegado (UE) 2024/1774 pide demostrarlo.
La superficie expuesta empieza en un puerto abierto
El core, las APIs internas y las consolas de administración escuchan en un puerto alcanzable desde alguna red. El cortafuegos decide qué direcciones llegan a ese puerto; la aplicación decide después quién entra. Entre las dos capas se acumulan reglas que crecen con cada integración, excepciones para proveedores y rangos heredados que nadie se atreve a cerrar.
Un puerto abierto responde antes de autenticar. El servidor TLS o HTTP que lo atiende procesa los datos de cualquiera que lo alcance, autorizado o no, y una vulnerabilidad en esa capa se explota sin credenciales. Estar dentro de la red interna basta para encontrarlo.
La regulación ya pone precio a esa superficie. El artículo 13 del Reglamento Delegado (UE) 2024/1774, que desarrolla el marco de gestión del riesgo TIC de DORA (Digital Operational Resilience Act) es el Reglamento (UE) 2022/2554 sobre la resiliencia operativa digital del sector financiero. Obliga a bancos, aseguradoras y empresas de inversión de la UE a resistir las perturbaciones y amenazas TIC, responder a ellas y recuperarse. Se aplica desde el 17 de enero de 2025.Leer más → DORA, exige documentar todas las conexiones de red y flujos de datos (letra b) y, en los sistemas que sustentan funciones esenciales o importantes, verificar la adecuación de las reglas cortafuegos y los filtros de conexión al menos cada seis meses. El esfuerzo de esa revisión crece con el número de reglas.
Del perímetro a la identidad, y de la red a la aplicación
Mover el control de acceso de la dirección IP a la identidad no basta para cerrar el puerto: importa también dónde vive ese control. OpenZiti, el protocolo abierto sobre el que se construye este enfoque, distingue tres modelos de despliegue que pueden convivir en la misma red:
| Dónde vive el control | Cambios de código | Qué queda expuesto | Límite de confianza |
|---|---|---|---|
| Red: router del overlay en una zona de confianza | Ninguno | El servicio sigue escuchando en la red privada, detrás del router | La zona de red |
| Host: tunneler junto al servicio | Ninguno | El servicio solo acepta conexiones desde localhost | El sistema operativo del host |
| Aplicación: SDK dentro del proceso | Sí | Ningún puerto a la escucha, ni siquiera en localhost | El propio proceso |
El modelo de aplicación es el más estricto: la identidad criptográfica y el cifrado viven dentro del proceso del servicio, no en un elemento aparte que alguien debe acordarse de configurar bien.
Un servicio sin puertos de entrada
Con el SDK embebido, el servicio no espera conexiones. Abre conexiones salientes hacia los routers del overlay y se registra como proveedor de un servicio con nombre. Un cliente, que también tiene identidad propia, solicita una sesión para ese servicio; el controlador comprueba la política; el overlay une los dos extremos con autenticación mutua y cifrado de extremo a extremo.
La consecuencia práctica es que un escaneo, desde internet o desde la red interna, no encuentra el servicio porque no hay nada escuchando. Un equipo comprometido dentro de la red no gana alcance por estar dentro: sin una identidad autorizada, el servicio no existe para él.
Lo que no cambia conviene decirlo igual de claro. El servicio necesita salida hacia los routers del overlay. La red y la segmentación existentes siguen ahí, y los fallos en la lógica de la aplicación siguen al alcance de las identidades autorizadas. El control embebido reduce quién puede llegar; no corrige lo que ocurre después.
Control de acceso dentro de la aplicación
Para un CTO, la conversación sobre superficie expuesta deja de ser una lista de puertos, reglas y excepciones, y pasa a ser una lista de identidades y de los servicios que cada una puede alcanzar:
- Identidad por servicio y por cliente, respaldada por certificado, en lugar de una dirección IP que comparten muchos procesos.
- Política central con denegación por defecto: quién puede conectarse a un servicio y quién puede ofrecerlo son datos del controlador, no reglas repartidas por cortafuegos.
- Revocación en un solo punto: retirar una identidad o una política se aplica en el plano de control, sin recorrer equipos de red.
El coste está en el código: embeber el SDK exige modificar el servicio. Para lo que no se puede tocar, el modelo de host con tunneler ofrece el mismo acceso por identidad sin cambios de código, con el límite de confianza en el sistema operativo.
Un protocolo abierto: OpenZiti
OpenZiti es software abierto con licencia Apache 2.0, creado y patrocinado por NetFoundry, y se puede hospedar entero en la infraestructura de la entidad. Para una entidad financiera eso tiene una lectura regulatoria: el artículo 28.8 de DORA exige estrategias de salida para los servicios TIC que sustentan funciones esenciales o importantes. Con un protocolo abierto y un plano de control propio, la salida de un proveedor no obliga a rehacer la arquitectura de acceso.
BlueUP desarrolla noa, una reimplementación independiente en Rust del SDK de cliente de OpenZiti, publicada con licencia Apache 2.0 e interoperable con el controlador y los routers de OpenZiti. El SDK se ejecuta dentro del proceso del servicio crítico, y por eso importa que esté escrito en un lenguaje con seguridad de memoria. noa está en fase de investigación: todavía no hay despliegue en producción de cliente ni auditoría criptográfica externa, y no está afiliada a NetFoundry ni a OpenZiti.
DORA y la evidencia de quién accede a qué
DORA no menciona el Zero Trust, pero su desarrollo técnico describe con precisión lo que un control de acceso por identidad produce. Estos son los requisitos que toca:
| Requisito | Norma | Qué aporta el control embebido |
|---|---|---|
| Limitar el acceso lógico a lo necesario para funciones legítimas y aprobadas | DORA, art. 9.4.c | Un servicio solo es alcanzable por las identidades que autoriza una política; el resto, denegado por defecto |
| Mecanismos de autenticación fuerte | DORA, art. 9.4.d | Identidad respaldada por certificado y autenticación mutua en cada conexión |
| Identificación y autenticación únicas de personas físicas y sistemas | RTS 2024/1774, art. 20.1 | Una identidad por servicio y por cliente, no por dirección IP |
| Mínimo privilegio y revisión de derechos al menos cada seis meses en sistemas de funciones esenciales o importantes | RTS 2024/1774, art. 21.a y 21.e.iv | La revisión lee una política (identidad y servicio), sin reconstruir el alcance desde reglas de red |
| Registrar los hechos de control de acceso lógico y de gestión de la identidad | RTS 2024/1774, art. 12.2.c.i | El controlador emite eventos de autenticación, de sesión y de cambios en identidades y servicios |
| Documentar todas las conexiones de red y flujos de datos | RTS 2024/1774, art. 13.b | Cada flujo permitido es una política con nombre; el inventario sale del plano de control |
La pregunta del auditor
«¿Quién puede llegar a este servicio?» Con control de red, la respuesta se reconstruye cruzando reglas cortafuegos, rangos y excepciones. Con control embebido, es la lista de identidades que autoriza una política, con el historial de sus cambios.
Dos límites deben quedar escritos. El control embebido no sustituye al marco de gestión del riesgo TIC del artículo 6 de DORA ni a la segmentación que el artículo 13.a del Reglamento Delegado sigue exigiendo. Y el registro que genera necesita la misma protección que cualquier otro: el artículo 12.2.d pide protegerlo contra la manipulación, la supresión y el acceso no autorizado. El camino de acceso produce la evidencia; su custodia sigue siendo de la entidad.
Por dónde empezar
- Inventariar lo que escucha. El artículo 8.4 de DORA ya exige identificar los activos TIC y cartografiar sus interdependencias. El punto de partida es la lista de servicios de funciones esenciales o importantes con un puerto alcanzable, desde qué redes y para quién.
- Elegir un servicio candidato. Uno con pocos consumidores conocidos y alto impacto si se expone: una API interna o una consola de administración.
- Elegir el modelo por servicio. Tunneler junto al servicio cuando no se puede tocar el código; SDK embebido en desarrollo nuevo o en las cargas más sensibles. Es la misma recomendación que hace el propio proyecto OpenZiti.
- Medir antes y después. Puertos alcanzables, reglas cortafuegos asociadas, identidades con acceso, y si la revisión semestral de derechos se puede responder leyendo la política.
Conclusión: Lo que no escucha no hay que defenderlo
El Zero Trust embebido no añade otra capa alrededor del servicio: elimina el puerto que esas capas protegían. La superficie expuesta pasa a medirse en identidades autorizadas, y la evidencia de acceso que piden DORA y su Reglamento Delegado sale del propio camino de acceso en lugar de reconstruirse a mano antes de cada revisión.
No es la única pieza de una arquitectura de resiliencia, pero es de las pocas que reducen a la vez lo que hay que defender y lo que hay que demostrar. El primer paso es saber qué escucha hoy el servicio más crítico de la entidad.
Lecturas relacionadas
- Zero Trust en banca: Por qué las VPN ya no bastan — Identidad, mTLS y dark services como modelo.
- TLPT bajo DORA: Qué exige el primer ciclo en España — Las pruebas que atacan la superficie expuesta en producción.
- IA agéntica y Zero Trust: Identidad, luego conectividad — El mismo principio aplicado a agentes de IA.
¿Qué escucha hoy tu servicio más crítico?
Revisamos con tu equipo técnico un servicio candidato: qué puertos tiene abiertos, quién puede alcanzarlo y qué evidencia de acceso genera.