SASE por dentro: arquitectura e viaxe dun paquete

Hai uns meses publicamos SASE? Sa que?, onde explicabamos o concepto coa metáfora do castelo. Aquí imos á parte técnica.

Este artigo abre unha serie técnica de oito entregas. Non imos repetir que significan as siglas: imos abrir a caixa e mirar como se move un paquete por dentro dunha arquitectura SASE, por que doe a arquitectura tradicional e que decisións de deseño hai detrás de cada compoñente.

Aviso: aquí asúmese que sabes o que é un proxy, un túnel IPsec e unha táboa de rutas. Se non, o artigo de introdución é mellor punto de partida.

1. SASE, SSE e quen fai que

A confusión número un do mercado é tratar SASE e SSE como sinónimos. Non o son, e a diferenza é puramente arquitectónica:

SSE (Security Service Edge) é a pila de seguridade entregada como servizo na nube: SWG, CASB, ZTNA, FWaaS, DLP, illamento do navegador.
SASE (Secure Access Service Edge) é SSE + o plano de rede: SD-WAN, optimización WAN, encamiñamento, calidade de servizo e a conectividade que leva o tráfico ata esa pila.

Dito doutro xeito: SASE = SSE + WAN edge, converxidos nun mesmo plano de control e de política. Se mercas só a parte de seguridade e segues levando o tráfico co teu MPLS de sempre, tes SSE. Perfectamente válido, pero chámao polo seu nome.

Os compoñentes, un a un e sen marketing:

Compoñente	Que inspecciona	Onde vive a decisión	Substitúe a…
SWG (Secure Web Gateway)	HTTP/HTTPS a nivel de transacción: URL, categoría, método, cabeceiras, corpo	Proxy no PoP, tras descifrar TLS	Proxy web on-premise
CASB	Aplicacións SaaS: que app, que instancia (corporativa ou persoal), que actividade (subir, compartir, descargar)	Inline no proxy e/ou vía API contra o tenant	Nada, é capacidade nova
DLP	O contido: patróns, pegadas dixitais, clasificadores, OCR	Motor de contido dentro do pipeline de inspección	DLP de rede on-premise
ZTNA	Sesións cara a aplicacións privadas: identidade, postura, aplicación concreta	Broker no PoP + conector saínte xunto á app	VPN de acceso remoto
FWaaS	Todo o tráfico, tamén o que non é web: portos, protocolos, aplicacións non HTTP	Motor de firewall no PoP	Firewall perimetral de cada sede
RBI (illamento remoto)	Sesións de navegación de risco, renderizadas nun contedor efémero	Navegador illado na nube	Nada, é capacidade nova
SD-WAN	Nada en termos de seguridade: decide por onde vai o tráfico	CPE na sede + orquestador	MPLS e routing estático

A clave que se perde nos diagramas de fabricante: estes motores non son caixas independentes encadeadas. Nunha implementación decente, o paquete descífrase unha vez, parsease unha vez e todos os motores avalían sobre esa mesma representación en memoria. Cando un fabricante encadea servizos que descifran e volven cifrar, nótase na latencia. Volveremos a isto na entrega 8.

2. Por que doe a arquitectura tradicional

A arquitectura clásica non é “mala”, é que foi deseñada para un mundo onde o 90 % dos recursos estaban dentro. Estes son os seus catro puntos de dor medibles:

Backhaul e hairpinning

Un usuario na delegación de Vigo quere abrir Microsoft 365. No modelo tradicional:

Portátil (Vigo) → MPLS → DC central (Madrid) → Firewall/Proxy → Internet
   → Microsoft (PoP máis próximo ao DC de Madrid) → volta polo mesmo camiño

O tráfico percorre 1.000 km para volver case ao mesmo sitio. Iso é backhaul. Cando ademais o usuario está na casa con VPN, o efecto é peor: o paquete sobe á VPN de Madrid, sae a Internet, e volve. Iso é hairpinning: entrar e saír polo mesmo punto facendo unha horquilla.

A conta rápida, con números conservadores:

Tramo	RTT típico
Usuario na casa (Vigo) → concentrador VPN (Madrid)	25–35 ms
Concentrador → SaaS (fronteira de Internet)	10–20 ms
Total ida e volta	35–55 ms
Usuario → PoP SASE próximo → SaaS	8–20 ms

Sobre HTTPS, cada handshake TLS son polo menos dous RTT (un con TLS 1.3 e reanudación). Multiplica polas decenas de conexións que abre unha aplicación web moderna e entendes por que Teams “vai raro” desde a casa.

O concentrador VPN como gargalo

O concentrador ten un número finito de sesións, un throughput finito de cifrado e un mantemento con ventá. Cando marzo de 2020 mandou a todo o mundo á casa, o patrón foi idéntico en todas as empresas: licenzas de VPN esgotadas, CPU ao 90 % e split tunneling activado a toda présa “temporalmente” (spoiler: segue activado).

O modelo de confianza é binario

Unha VPN clásica cólocate na rede. Unha vez dentro, o teu portátil ve rangos enteiros e pode escanear. O movemento lateral tras un phishing exitoso comeza case sempre aí. Non é un fallo de configuración, é o deseño: a VPN é unha extensión de capa 3, non un control de acceso a aplicacións.

A inspección TLS non escala en ferro

Descifrar TLS é caro. Un appliance que fai 10 Gbps en claro pode quedar en 2–3 Gbps con inspección activa. A consecuencia real que vemos en auditorías: listas de exclusión enormes, “de momento non inspeccionamos”, e unha falsa sensación de cobertura.

3. A viaxe dun paquete

Esta é a parte que case ninguén explica. Imos seguir a un usuario con axente instalado desde que fai dobre clic ata que o byte chega a destino.

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

Paso 1 — Resolución de nomes. O axente adoita interceptar o DNS local. Isto non é un capricho: permítelle (a) decidir se ese destino se manda ao servizo ou se deixa ir directo, (b) devolver unha IP sintética para aplicacións privadas —normalmente do rango 100.64.0.0/10, reservado para CGNAT— de forma que o sistema operativo saiba a onde encamiñar sen que exista unha ruta real.

Paso 2 — Decisión de steering. O axente consulta a súa configuración: este destino vai ao túnel, vai directo ou vai por proxy? Aquí entran as listas de bypass, a detección de rede de confianza e as excepcións (medios de Teams, portais cativos, tráfico de actualización do sistema). É a parte máis fráxil de todo o despregamento e dedicámoslle a entrega 2 enteira.

Paso 3 — Selección de PoP. O cliente mide latencia contra varios puntos de presenza (por anycast, por DNS xeolocalizado ou por unha lista ordenada) e levanta o túnel contra o mellor. O túnel pode ser IPsec, DTLS, TLS ou QUIC segundo o fabricante e o modo.

Paso 4 — Terminación TLS. No PoP, o proxy fai de intermediario: presenta ao cliente un certificado asinado por unha CA privada que ti despregaches nos endpoints, e abre el a conexión real cara ao destino validando ese certificado. Sen este paso, a seguridade limítase a mirar o SNI e a IP. Con ECH (Encrypted Client Hello) gañando terreo, incluso o SNI deixa de estar dispoñible, o que reforza que a inspección deixe de ser opcional ou que se dependa de listas por IP.

Paso 5 — Clasificación. O motor identifica: usuario (do token do IdP ou da sesión do axente), dispositivo (xestionado ou non), aplicación (non “dominio”, senón “OneDrive corporativo” fronte a “OneDrive persoal”), actividade (upload, share, download) e categoría da URL.

Paso 6 — Avaliación de política. Percórrese o conxunto de regras de arriba abaixo ata o primeiro match, igual que un firewall, pero con predicados de moita máis resolución. Na mesma pasada corren os motores de ameazas (antimalware, sandbox) e o de DLP sobre o corpo da petición.

Paso 7 — Egress. O PoP fai NAT cara ao destino cunha IP do provedor. Consecuencia importante e frecuentemente esquecida: as listas brancas por IP dos teus provedores deixan de ver as túas IPs e comezan a ver as do fabricante. Hai que republicalas. E se unha aplicación che bloquea por “IP de datacenter”, terás que pedir IPs dedicadas.

Paso 8 — Aplicación privada (camiño alternativo). Se o destino é interno, non hai egress a Internet: o broker ZTNA empareixa a sesión do usuario cun conector que a organización despregou xunto á aplicación. Ese conector só abre conexións saíntes cara ao PoP, así que o datacenter non expón ningún porto entrante. Detalle nada trivial: o tráfico vai cifrado dúas veces (o TLS da app dentro do túnel do servizo).

4. Traffic steering, nunha pantalla

Como se leva o tráfico ao PoP é a decisión que máis problemas operativos xera. Resumo para telo a man, e desenvolvemento completo na entrega 2:

Método	Granularidade	Cifrado	Bo para	O seu punto débil
Axente	Usuario e dispositivo	Si (DTLS/TLS/QUIC)	Portátiles e móbiles xestionados	Hai que instalalo e mantelo
Ficheiro PAC	Por destino, no navegador	Non (só indica o proxy)	Complemento, contornas lixeiras	Só cobre navegador, sáltase facilmente
Proxy explícito	Por destino e sesión	Opcional	Servidores, contornas controladas	Non cobre tráfico non web
IPsec (IKEv2)	Por sede	Si	Sedes con router capaz	NAT, MTU, e non distingue usuarios por si só
GRE	Por sede	Non	Sedes con moito ancho de banda e enlace fiable	Sen cifrado, require IP pública estable
SD-WAN	Por aplicación e por sede	Segundo o deseño	Sedes con varios enlaces	Engade outro plano que orquestrar

Regra práctica: usuarios con axente, sedes con túnel, servidores con proxy explícito, e unha única fonte de verdade para as excepcións.

5. ZTNA, mecanicamente

ZTNA non é “VPN pero na nube”. A diferenza está na orde das comprobacións e no que se concede ao final:

Identidade. O cliente autentícase contra o IdP (SAML ou OIDC). Obtense usuario, grupos e, se está ben montado, sinais de risco do propio IdP.
Postura do dispositivo. É un equipo xestionado? Ten o EDR correndo, o disco cifrado, o SO parcheado, o certificado de dispositivo? A postura non se avalía só ao conectar: reavalíase durante a sesión.
Política. Resólvese a tupla (usuario, grupo, dispositivo, postura, aplicación, hora, ubicación) contra o conxunto de regras.
Acceso. E aquí está a diferenza real: concédese unha sesión cara a unha aplicación concreta, non unha ruta cara a unha rede. O usuario non obtén visibilidade da subrede, non pode escanear veciños e non aparece na táboa de rutas nada que non lle corresponda.

A consecuencia de seguridade resúmese nunha frase: se un atacante rouba credenciais e sortea o MFA, no modelo VPN gaña a rede; no modelo ZTNA gaña as aplicacións que ese usuario tiña asignadas. Non é invulnerabilidade, é redución de radio de explosión.

Os detalles xugosos —protocolos non web, fluxos iniciados por servidor, Kerberos, DNS privado, acceso sen axente— van completos na entrega 3.

6. E o firewall? NGFW, FWaaS e SWG

Aquí é onde máis xente se perde, incluídos algúns comerciais. Os tres inspeccionan tráfico, pero non son intercambiables.

	NGFW (físico ou virtual)	FWaaS	SWG
Modelo	Inspección en liña sobre fluxos	O mesmo, pero como servizo multi-tenant no PoP	Proxy que termina a conexión
Unidade de traballo	Sesión (5-tupla)	Sesión	Transacción HTTP
Alcance	Todos os portos e protocolos	Todos os portos e protocolos	HTTP/HTTPS (e pouco máis)
Identidade de usuario	Si, con axente de mapeo	Si, nativa	Si, nativa
Inspección TLS	Si, con custo de CPU	Si, elástica	Si, é a súa razón de ser
Granularidade web	Aplicación e categoría	Aplicación e categoría	Actividade dentro da app: subir, compartir, comentar
Onde segue tendo sentido	Datacenter, OT/industrial, segmentación este-oeste	Sedes e usuarios remotos	Calquera tráfico web e SaaS

Tres conclusións prácticas:

SASE non elimina o firewall. Elimina o firewall perimetral de cada delegación. O do datacenter e o da planta industrial quedan onde están, protexendo tráfico este-oeste que nunca vai subir á nube.
FWaaS non substitúe o SWG. Un firewall ve “conexión HTTPS a sharepoint.com, permitida”. Un SWG ve “este usuario está subindo un ficheiro con IBAN a un SharePoint doutro tenant”. Distinta resolución, distinto propósito.
Precisas FWaaS aínda que teñas SWG en canto apareza tráfico non web: SSH, RDP, SMTP, protocolos industriais, clientes gordos con portos propios.

7. Un caso práctico

Imos cun caso realista. É un caso composto: unha empresa ficticia construída a partir de patróns que se repiten en proxectos reais. As cifras son ordes de magnitude típicas, non un benchmark de fabricante. Mídeas ti no teu contorno antes de citalas nun comité.

Aurum Loxística. 1.200 empregados, 14 sedes en España e Portugal, 2 centros de datos, 60 % do persoal en modelo híbrido. O seu SAP e o seu WMS son on-premise; o resto da ofimática está en Microsoft 365 e Salesforce.

Antes:

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

Síntomas: 800 sesións VPN concorrentes contra un dimensionamento de 600; Teams degradado polas tardes; o proxy sen inspección TLS en 40 dominios “problemáticos”; cada apertura de delegación implicaba mercar dous firewalls e esperar seis semanas; ningún control sobre que se subía a Drive persoal.

Despois:

Usuarios (todos, dentro e fóra) ──axente──▶ PoP SASE ──▶ Internet / SaaS
Sedes ──IPsec x2 (dous operadores)──────────▶ PoP SASE
SAP e WMS ──conectores ZTNA salientes──────▶ broker  ──▶ usuarios autorizados
DC ──NGFW existentes────────────────────────▶ segmentación este-oeste (quédanse)
VPN ─────────────────────────────────────── retirada tras 4 meses de convivencia

Decisións de deseño que marcaron o resultado, e que son as que de verdade importan:

A VPN non se apagou o día un. Convivíu catro meses con ZTNA, con criterio de saída explícito: cero tickets de acceso durante tres semanas seguidas.
Comezouse por unha soa aplicación privada (o WMS, con 90 usuarios) e non por SAP.
As sedes mantiveron dous túneles a dous PoP distintos con operadores distintos. É a diferenza entre unha incidencia e unha portada.
A inspección TLS entrou por fases e por grupos, non de golpe, cunha lista de exclusión revisada mensualmente no canto de medrar para sempre.

8. Métricas antes e despois (e como medilas ti)

Un proxecto SASE sen liña base é un proxecto sen maneira de demostrar que funcionou. Estas son as métricas que paga a pena capturar antes de tocar nada:

Métrica	Como medila	Que esperar
Latencia a SaaS crítico	RTT e tempo de carga desde 5 localizacións fixas, mesma hora, 2 semanas	Mellora clara en remoto e en delegacións; na sede central pode non moverse ou empeorar lixeiramente
Sesións VPN concorrentes	Contador do concentrador, pico diario	Debe tender a cero ao retirar
Tickets de acceso remoto	Cola do ITSM, categoría filtrada	Adoita caer de forma marcada tras o segundo mes
Cobertura de inspección TLS	% de sesións descifradas sobre o total	O número honesto adoita comezar por debaixo do 60 % e é o que hai que subir
Tempo de alta dunha sede	Desde a petición ata o primeiro paquete inspeccionado	De semanas a días
Aplicacións SaaS en uso	Descubrimento de shadow IT	Prepárate: sempre hai entre 3 e 10 veces máis das que cres
Custo por sede e mes	Circuíto + hardware amortizado + soporte	Depende do contrato: non prometas aforro sen facer a conta completa

E dúas advertencias de honestidade intelectual, que nesta casa importan:

A latencia non sempre baixa. Para o usuario que está na sede central, ao lado do datacenter onde vive o proxy, meter un salto á nube pode engadir milisegundos. A ganancia está no remoto e nas delegacións, que adoitan ser a maioría.
O aforro non é automático. Aforrase en hardware, en circuítos MPLS e en horas de operación; gástase en subscrición por usuario. En empresas con poucas sedes e moito persoal, a conta pode saír plana. A xustificación entón é de risco e de axilidade, non de custo, e convén dicilo así no comité.

9. Sete mitos que convén desmontar

“SASE é un produto que se merca.” É unha arquitectura. Podes mercala a un fabricante, a dous, ou construír a metade. O que mercas son compoñentes que encaixan nela.

“Con SASE xa non preciso firewalls.” Xa o vimos: quítaste os perimetrais de delegación. O datacenter, a segmentación interna e o contorno industrial seguen precisando o seu.

“ZTNA é unha VPN sen cliente.” A maioría dos despregamentos ZTNA usan axente. O que cambia non é o cliente, é o que se concede: aplicación no canto de rede.

“É Zero Trust, así que xa estou en Zero Trust.” ZTNA cobre o acceso de usuario a aplicación. Zero Trust inclúe ademais identidade, dispositivo, carga de traballo, datos e telemetría. É unha peza importante, non o mapa completo.

“Un só fabricante sempre é mellor.” Un só fabricante simplifica política, telemetría e soporte, e é unha vantaxe real. Tamén concentra risco, reduce o teu poder de negociación na renovación e faiche tragar co módulo mediocre do catálogo. É unha decisión de estratexia, non unha verdade técnica.

“Canto máis PoP, mellor.” O que importa non é o número no mapa comercial, senón cantos deses puntos fan inspección completa preto dos teus usuarios, con que capacidade e sobre que rede. Un fabricante con 40 puntos propios de cómputo completo pode render mellor que un con 150 que na práctica reenvían a un puñado de rexións. Pregunta polos teus, non polo mapa.

“Ao inspeccionar TLS véxoo todo.” Verás o que non estea na túa lista de exclusión, o que non use fixación de certificado e o que non viaxe por protocolos que decidises non tocar. A cobertura real é un número que hai que medir e publicar, non asumir.

A serie completa

Oito entregas para percorrer SASE de arriba abaixo. Publícanse cada semana:

SASE por dentro: arquitectura, compoñentes e a viaxe dun paquete ← estás aquí
Traffic Steering: PAC, IPsec, GRE, axentes e SD-WAN (proximamente)
ZTNA por dentro: identidade, postura, política e acceso (proximamente)
SWG + CASB + DLP: os tres motores que miran o tráfico (proximamente)
Deseñar unha arquitectura SASE: do encerado ao despregamento (proximamente)
SASE con Netskope (proximamente)
SASE con Palo Alto Prisma Access (proximamente)
Netskope vs Prisma Access: dúas filosofías, un problema (proximamente)

Se vés de cero, comeza por SASE? Sa que? e polas fichas de SASE e Zero Trust no glosario.

Xa fixeches o exercicio de medir a túa cobertura real de inspección TLS? Ese número adoita ser a conversa máis incómoda e máis útil de todo o proxecto.