SASE por dentro: arquitectura y viaje de un paquete

Hace unos meses publicamos ¿SASE? Sa qué?, donde explicábamos el concepto con metáforas de castillos y perros guardianes. Prometimos bajar al barro. Aquí empezamos a ensuciarnos las patas.

Este artículo abre una serie técnica de ocho entregas. No vamos a repetir qué significan las siglas: vamos a abrir la caja y mirar cómo se mueve un paquete por dentro de una arquitectura SASE, por qué duele la arquitectura tradicional y qué decisiones de diseño hay detrás de cada componente.

Aviso: aquí se asume que sabes lo que es un proxy, un túnel IPsec y una tabla de rutas. Si no, el artículo de introducción es mejor punto de partida.

1. SASE, SSE y quién hace qué

La confusión número uno del mercado es tratar SASE y SSE como sinónimos. No lo son, y la diferencia es puramente arquitectónica:

SSE (Security Service Edge) es la pila de seguridad entregada como servicio en la nube: SWG, CASB, ZTNA, FWaaS, DLP, aislamiento del navegador.
SASE (Secure Access Service Edge) es SSE + el plano de red: SD-WAN, optimización WAN, enrutamiento, calidad de servicio y la conectividad que lleva el tráfico hasta esa pila.

Dicho de otra forma: SASE = SSE + WAN edge, convergidos en un mismo plano de control y de política. Si compras solo la parte de seguridad y sigues llevando el tráfico con tu MPLS de siempre, tienes SSE. Perfectamente válido, pero llámalo por su nombre.

Los componentes, uno a uno y sin marketing:

Componente	Qué inspecciona	Dónde vive la decisión	Sustituye a…
SWG (Secure Web Gateway)	HTTP/HTTPS a nivel de transacción: URL, categoría, método, cabeceras, cuerpo	Proxy en el PoP, tras descifrar TLS	Proxy web on-premise
CASB	Aplicaciones SaaS: qué app, qué instancia (corporativa o personal), qué actividad (subir, compartir, descargar)	Inline en el proxy y/o vía API contra el tenant	Nada, es capacidad nueva
DLP	El contenido: patrones, huellas digitales, clasificadores, OCR	Motor de contenido dentro del pipeline de inspección	DLP de red on-premise
ZTNA	Sesiones hacia aplicaciones privadas: identidad, postura, aplicación concreta	Broker en el PoP + conector saliente junto a la app	VPN de acceso remoto
FWaaS	Todo el tráfico, también el que no es web: puertos, protocolos, aplicaciones no HTTP	Motor de firewall en el PoP	Firewall perimetral de cada sede
RBI (aislamiento remoto)	Sesiones de navegación de riesgo, renderizadas en un contenedor efímero	Navegador aislado en la nube	Nada, es capacidad nueva
SD-WAN	Nada en términos de seguridad: decide por dónde va el tráfico	CPE en la sede + orquestador	MPLS y routing estático

La clave que se pierde en los diagramas de fabricante: estos motores no son cajas independientes encadenadas. En una implementación decente, el paquete se descifra una vez, se parsea una vez y todos los motores evalúan sobre esa misma representación en memoria. Cuando un fabricante encadena servicios que descifran y vuelven a cifrar, lo notas en la latencia. Volveremos a esto en la entrega 8.

2. Por qué duele la arquitectura tradicional

La arquitectura clásica no es “mala”, es que fue diseñada para un mundo donde el 90 % de los recursos estaban dentro. Estos son sus tres puntos de dolor medibles:

Backhaul y hairpinning

Un usuario en la delegación de Vigo quiere abrir Microsoft 365. En el modelo tradicional:

Portátil (Vigo) → MPLS → DC central (Madrid) → Firewall/Proxy → Internet
   → Microsoft (PoP más cercano al DC de Madrid) → vuelta por el mismo camino

El tráfico recorre 1.000 km para volver casi al mismo sitio. Eso es backhaul. Cuando además el usuario está en casa con VPN, el efecto es peor: el paquete sube a la VPN de Madrid, sale a Internet, y vuelve. Eso es hairpinning: entrar y salir por el mismo punto haciendo una horquilla.

La cuenta rápida, con números conservadores:

Tramo	RTT típico
Usuario en casa (Vigo) → concentrador VPN (Madrid)	25–35 ms
Concentrador → SaaS (frontera de Internet)	10–20 ms
Total ida y vuelta	35–55 ms
Usuario → PoP SASE cercano → SaaS	8–20 ms

Sobre HTTPS, cada handshake TLS son al menos dos RTT (uno con TLS 1.3 y reanudación). Multiplica por las decenas de conexiones que abre una aplicación web moderna y entiendes por qué Teams “va raro” desde casa.

El concentrador VPN como cuello de botella

El concentrador tiene un número finito de sesiones, un throughput finito de cifrado y un mantenimiento con ventana. Cuando marzo de 2020 mandó a todo el mundo a casa, el patrón fue idéntico en todas las empresas: licencias de VPN agotadas, CPU al 90 % y split tunneling activado a toda prisa “temporalmente” (spoiler: sigue activado).

El modelo de confianza es binario

Una VPN clásica te coloca en la red. Una vez dentro, tu portátil ve rangos enteros y puede escanear. El movimiento lateral tras un phishing exitoso empieza casi siempre ahí. No es un fallo de configuración, es el diseño: la VPN es una extensión de capa 3, no un control de acceso a aplicaciones.

La inspección TLS no escala en hierro

Descifrar TLS es caro. Un appliance que hace 10 Gbps en claro puede quedarse en 2–3 Gbps con inspección activa. La consecuencia real que vemos en auditorías: listas de exclusión enormes, “de momento no inspeccionamos”, y una falsa sensación de cobertura.

3. El viaje de un paquete

Esta es la parte que casi nadie explica. Vamos a seguir a un usuario con agente instalado desde que hace doble clic hasta que el byte llega a destino.

                 ┌──────────────────────── PoP SASE ────────────────────────┐
 Endpoint        │                                                          │
 ┌────────┐      │  ┌─────────┐  ┌────────────┐  ┌─────────┐  ┌──────────┐  │
 │ agente │══════╪═▶│ terminac│─▶│ clasificac.│─▶│ política│─▶│  egress  │──╪──▶ Internet / SaaS
 │  DNS   │ túnel│  │  ión TLS│  │ app/usuario│  │ + DLP   │  │   NAT    │  │
 └────────┘      │  └─────────┘  └────────────┘  └─────────┘  └──────────┘  │
                 │        │                                                 │
                 │        ▼                                                 │
                 │  ┌───────────┐        mTLS saliente        ┌───────────┐ │
                 │  │broker ZTNA│◀════════════════════════════│ conector  │ │──▶ App privada
                 │  └───────────┘                             └───────────┘ │
                 └──────────────────────────────────────────────────────────┘

Paso 1 — Resolución de nombres. El agente suele interceptar el DNS local. Esto no es un capricho: le permite (a) decidir si ese destino se manda al servicio o se deja ir directo, (b) devolver una IP sintética para aplicaciones privadas —normalmente del rango 100.64.0.0/10, reservado para CGNAT— de forma que el sistema operativo sepa a dónde enrutar sin que exista una ruta real.

Paso 2 — Decisión de steering. El agente consulta su configuración: ¿este destino va al túnel, va directo o va por proxy? Aquí entran las listas de bypass, la detección de red de confianza y las excepciones (medios de Teams, portales cautivos, tráfico de actualización del sistema). Es la parte más frágil de todo el despliegue y le dedicamos la entrega 2 entera.

Paso 3 — Selección de PoP. El cliente mide latencia contra varios puntos de presencia (por anycast, por DNS geolocalizado o por una lista ordenada) y levanta el túnel contra el mejor. El túnel puede ser IPsec, DTLS, TLS o QUIC según el fabricante y el modo.

Paso 4 — Terminación TLS. En el PoP, el proxy hace de intermediario: presenta al cliente un certificado firmado por una CA privada que tú has desplegado en los endpoints, y abre él la conexión real hacia el destino validando ese certificado. Sin este paso, la seguridad se limita a mirar el SNI y la IP. Con ECH (Encrypted Client Hello) ganando terreno, incluso el SNI deja de estar disponible, lo que refuerza que la inspección deje de ser opcional o que se dependa de listas por IP.

Paso 5 — Clasificación. El motor identifica: usuario (del token del IdP o de la sesión del agente), dispositivo (gestionado o no), aplicación (no “dominio”, sino “OneDrive corporativo” frente a “OneDrive personal”), actividad (upload, share, download) y categoría de la URL.

Paso 6 — Evaluación de política. Se recorre el conjunto de reglas de arriba abajo hasta el primer match, igual que un firewall, pero con predicados de mucha más resolución. En la misma pasada corren los motores de amenazas (antimalware, sandbox) y el de DLP sobre el cuerpo de la petición.

Paso 7 — Egress. El PoP hace NAT hacia el destino con una IP del proveedor. Consecuencia importante y frecuentemente olvidada: las listas blancas por IP de tus proveedores dejan de ver tus IPs y empiezan a ver las del fabricante. Hay que republicarlas. Y si una aplicación te bloquea por “IP de datacenter”, tendrás que pedir IPs dedicadas.

Paso 8 — Aplicación privada (camino alternativo). Si el destino es interna, no hay egress a Internet: el broker ZTNA empareja la sesión del usuario con un conector que la organización ha desplegado junto a la aplicación. Ese conector solo abre conexiones salientes hacia el PoP, así que el datacenter no expone ningún puerto entrante. Detalle nada trivial: el tráfico va cifrado dos veces (el TLS de la app dentro del túnel del servicio).

4. Traffic steering, en una pantalla

Cómo se lleva el tráfico al PoP es la decisión que más problemas operativos genera. Resumen para tenerlo a mano, y desarrollo completo en la entrega 2:

Método	Granularidad	Cifrado	Bueno para	Su punto débil
Agente	Usuario y dispositivo	Sí (DTLS/TLS/QUIC)	Portátiles y móviles gestionados	Hay que instalarlo y mantenerlo
Fichero PAC	Por destino, en el navegador	No (solo indica el proxy)	Complemento, entornos ligeros	Solo cubre navegador, se salta fácil
Proxy explícito	Por destino y sesión	Opcional	Servidores, entornos controlados	No cubre tráfico no web
IPsec (IKEv2)	Por sede	Sí	Sedes con router capaz	NAT, MTU, y no distingue usuarios por sí solo
GRE	Por sede	No	Sedes con mucho ancho de banda y enlace fiable	Sin cifrado, requiere IP pública estable
SD-WAN	Por aplicación y por sede	Según el diseño	Sedes con varios enlaces	Añade otro plano que orquestar

Regla práctica: usuarios con agente, sedes con túnel, servidores con proxy explícito, y una única fuente de verdad para las excepciones.

5. ZTNA, mecánicamente

ZTNA no es “VPN pero en la nube”. La diferencia está en el orden de las comprobaciones y en qué se concede al final:

Identidad. El cliente se autentica contra el IdP (SAML u OIDC). Se obtiene usuario, grupos y, si está bien montado, señales de riesgo del propio IdP.
Postura del dispositivo. ¿Es un equipo gestionado? ¿Tiene el EDR corriendo, el disco cifrado, el SO parcheado, el certificado de dispositivo? La postura no se evalúa solo al conectar: se reevalúa durante la sesión.
Política. Se resuelve la tupla (usuario, grupo, dispositivo, postura, aplicación, hora, ubicación) contra el conjunto de reglas.
Acceso. Y aquí está la diferencia real: se concede una sesión hacia una aplicación concreta, no una ruta hacia una red. El usuario no obtiene visibilidad de la subred, no puede escanear vecinos y no aparece en la tabla de rutas nada que no le corresponda.

La consecuencia de seguridad se resume en una frase: si un atacante roba credenciales y sortea el MFA, en el modelo VPN gana la red; en el modelo ZTNA gana las aplicaciones que ese usuario tenía asignadas. No es invulnerabilidad, es reducción de radio de explosión.

Los detalles jugosos —protocolos no web, flujos iniciados por servidor, Kerberos, DNS privado, acceso sin agente— van completos en la entrega 3.

6. ¿Y el firewall? NGFW, FWaaS y SWG

Aquí es donde más gente se pierde, incluidos algunos comerciales. Los tres inspeccionan tráfico, pero no son intercambiables.

	NGFW (físico o virtual)	FWaaS	SWG
Modelo	Inspección en línea sobre flujos	Lo mismo, pero como servicio multi-tenant en el PoP	Proxy que termina la conexión
Unidad de trabajo	Sesión (5-tupla)	Sesión	Transacción HTTP
Alcance	Todos los puertos y protocolos	Todos los puertos y protocolos	HTTP/HTTPS (y poco más)
Identidad de usuario	Sí, con agente de mapeo	Sí, nativa	Sí, nativa
Inspección TLS	Sí, con coste de CPU	Sí, elástica	Sí, es su razón de ser
Granularidad web	Aplicación y categoría	Aplicación y categoría	Actividad dentro de la app: subir, compartir, comentar
Dónde sigue teniendo sentido	Datacenter, OT/industrial, segmentación este-oeste	Sedes y usuarios remotos	Cualquier tráfico web y SaaS

Tres conclusiones prácticas:

SASE no elimina el firewall. Elimina el firewall perimetral de cada delegación. El del datacenter y el de la planta industrial se quedan donde están, protegiendo tráfico este-oeste que nunca va a subir a la nube.
FWaaS no sustituye al SWG. Un firewall ve “conexión HTTPS a sharepoint.com, permitida”. Un SWG ve “este usuario está subiendo un fichero con IBAN a un SharePoint de otro tenant”. Distinta resolución, distinto propósito.
Necesitas FWaaS aunque tengas SWG en cuanto aparezca tráfico no web: SSH, RDP, SMTP, protocolos industriales, clientes gordos con puertos propios.

7. Un caso práctico

Vamos con un caso realista. Es un caso compuesto: una empresa ficticia construida a partir de patrones que se repiten en proyectos reales. Las cifras son órdenes de magnitud típicos, no un benchmark de fabricante. Mídelas tú en tu entorno antes de citarlas en un comité.

Aurum Logística. 1.200 empleados, 14 sedes en España y Portugal, 2 centros de datos, 60 % de la plantilla en modelo híbrido. Su SAP y su WMS son on-premise; el resto de la ofimática está en Microsoft 365 y Salesforce.

Antes:

14 sedes ──MPLS──▶ DC Madrid ──▶ 2 firewalls NGFW en clúster
                                 + proxy web + concentrador VPN
                                 └──▶ Internet
Teletrabajo ──VPN full tunnel──▶ mismo clúster

Síntomas: 800 sesiones VPN concurrentes contra un dimensionado de 600; Teams degradado en las tardes; el proxy sin inspección TLS en 40 dominios “problemáticos”; cada apertura de delegación implicaba comprar dos firewalls y esperar seis semanas; ningún control sobre qué se subía a Drive personal.

Después:

Usuarios (todos, dentro y fuera) ──agente──▶ PoP SASE ──▶ Internet / SaaS
Sedes ──IPsec x2 (dos operadores)──────────▶ PoP SASE
SAP y WMS ──conectores ZTNA salientes──────▶ broker  ──▶ usuarios autorizados
DC ──NGFW existentes────────────────────────▶ segmentación este-oeste (se quedan)
VPN ─────────────────────────────────────── retirada tras 4 meses de convivencia

Decisiones de diseño que marcaron el resultado, y que son las que de verdad importan:

La VPN no se apagó el día uno. Convivió cuatro meses con ZTNA, con criterio de salida explícito: cero tickets de acceso durante tres semanas seguidas.
Se empezó por una sola aplicación privada (el WMS, con 90 usuarios) y no por SAP.
Las sedes mantuvieron dos túneles a dos PoP distintos con operadores distintos. Es la diferencia entre una incidencia y una portada.
La inspección TLS entró por fases y por grupos, no de golpe, con una lista de exclusión revisada mensualmente en lugar de crecer para siempre.

8. Métricas antes y después (y cómo medirlas tú)

Un proyecto SASE sin línea base es un proyecto sin manera de demostrar que funcionó. Estas son las métricas que merece la pena capturar antes de tocar nada:

Métrica	Cómo medirla	Qué esperar
Latencia a SaaS crítico	RTT y tiempo de carga desde 5 ubicaciones fijas, misma hora, 2 semanas	Mejora clara en remoto y en delegaciones; en la sede central puede no moverse o empeorar ligeramente
Sesiones VPN concurrentes	Contador del concentrador, pico diario	Debe tender a cero al retirar
Tickets de acceso remoto	Cola del ITSM, categoría filtrada	Suele caer de forma marcada tras el segundo mes
Cobertura de inspección TLS	% de sesiones descifradas sobre el total	El número honesto suele empezar por debajo del 60 % y es el que hay que subir
Tiempo de alta de una sede	Desde la petición hasta el primer paquete inspeccionado	De semanas a días
Aplicaciones SaaS en uso	Descubrimiento de shadow IT	Prepárate: siempre hay entre 3 y 10 veces más de las que crees
Coste por sede y mes	Circuito + hardware amortizado + soporte	Depende del contrato: no prometas ahorro sin hacer la cuenta completa

Y dos advertencias de honestidad intelectual, que en esta casa importan:

La latencia no siempre baja. Para el usuario que está en la sede central, al lado del datacenter donde vive el proxy, meter un salto a la nube puede añadir milisegundos. La ganancia está en el remoto y en las delegaciones, que suelen ser la mayoría.
El ahorro no es automático. Se ahorra en hardware, en circuitos MPLS y en horas de operación; se gasta en suscripción por usuario. En empresas con pocas sedes y mucha plantilla, la cuenta puede salir plana. La justificación entonces es de riesgo y de agilidad, no de coste, y conviene decirlo así en el comité.

9. Siete mitos que conviene desmontar

“SASE es un producto que se compra.” Es una arquitectura. Puedes comprarla a un fabricante, a dos, o construir la mitad. Lo que compras son componentes que encajan en ella.

“Con SASE ya no necesito firewalls.” Ya lo hemos visto: te quitas los perimetrales de delegación. El datacenter, la segmentación interna y el entorno industrial siguen necesitando lo suyo.

“ZTNA es una VPN sin cliente.” La mayoría de despliegues ZTNA usan agente. Lo que cambia no es el cliente, es qué se concede: aplicación en vez de red.

“Es Zero Trust, así que ya estoy en Zero Trust.” ZTNA cubre el acceso de usuario a aplicación. Zero Trust incluye además identidad, dispositivo, carga de trabajo, datos y telemetría. Es una pieza importante, no el mapa completo.

“Un solo fabricante siempre es mejor.” Un solo fabricante simplifica política, telemetría y soporte, y es una ventaja real. También concentra riesgo, reduce tu poder de negociación en la renovación y te hace tragar con el módulo mediocre del catálogo. Es una decisión de estrategia, no una verdad técnica.

“Cuantos más PoP, mejor.” Lo que importa no es el número en el mapa comercial, sino cuántos de esos puntos hacen inspección completa cerca de tus usuarios, con qué capacidad y sobre qué red. Un fabricante con 40 puntos propios de cómputo completo puede rendir mejor que uno con 150 que en la práctica reenvían a un puñado de regiones. Pregunta por los tuyos, no por el mapa.

“Al inspeccionar TLS lo veo todo.” Verás lo que no esté en tu lista de exclusión, lo que no use fijación de certificado y lo que no viaje por protocolos que hayas decidido no tocar. La cobertura real es un número que hay que medir y publicar, no asumir.

La serie completa

Ocho entregas para recorrer SASE de arriba abajo. Se publican cada semana:

SASE por dentro: arquitectura, componentes y el viaje de un paquete ← estás aquí
Traffic Steering: PAC, IPsec, GRE, agentes y SD-WAN (próximamente)
ZTNA por dentro: identidad, postura, política y acceso (próximamente)
SWG + CASB + DLP: los tres motores que miran el tráfico (próximamente)
Diseñar una arquitectura SASE: de la pizarra al despliegue (próximamente)
SASE con Netskope (próximamente)
SASE con Palo Alto Prisma Access (próximamente)
Netskope vs Prisma Access: dos filosofías, un problema (próximamente)

Si vienes de cero, empieza por ¿SASE? Sa qué? y por las fichas de SASE y Zero Trust en el glosario.

¿Ya has hecho el ejercicio de medir tu cobertura real de inspección TLS? Ese número suele ser la conversación más incómoda y más útil de todo el proyecto.