SASE: el modelo que unifica red y seguridad en el trabajo híbrido

Introducción

El trabajo remoto dejó de ser una excepción para convertirse en la norma operativa de buena parte de las organizaciones. Según el indicador de trabajo híbrido de Gallup (mayo de 2026), el 52 % de los empleados de EE. UU. que pueden trabajar remoto opera bajo un esquema híbrido, un 26 % trabaja completamente remoto y solo el 22 % permanece 100 % presencial. Más en Gallup. La tendencia viene de atrás: ya en 2022, el Workforce Security Report de Check Point registraba que el 57 % de las organizaciones tenía a más de la mitad de su plantilla trabajando remoto al menos dos días por semana. Esa realidad expuso un problema estructural: las redes tradicionales de TI, pensadas para un perímetro fijo, no estaban diseñadas para proteger entornos tan distribuidos.

En este artículo exploramos Secure Access Service Edge (SASE), el modelo que surgió como respuesta a ese problema: qué es, cómo funciona, qué ganas y qué pierdes al adoptarlo, y qué conviene revisar si operas en Latinoamérica.

Gartner acuñó el término en 2019 y, en 2020, predijo que “para 2024, al menos el 40 % de las empresas tendrán estrategias explícitas para adoptar SASE, frente a menos del 1 % a finales de 2018” (Hype Cycle for Network Security, 2020). El mercado siguió en esa dirección: Gartner estimaba que para 2026 el 60 % de las compras nuevas de SD-WAN formarían parte de una oferta single-vendor SASE, frente al 15 % en 2022 (Fierce Network). Lo que empezó como una apuesta de analista hoy es una categoría de mercado consolidada, con sus propios Magic Quadrants.

¿Qué es Secure Access Service Edge (SASE)?

El término SASE (se pronuncia “sassy”) describe un modelo que combina tecnologías de red y seguridad en una única plataforma entregada desde la nube. Su objetivo es que los usuarios se conecten de forma segura desde cualquier ubicación, con administración centralizada.

Con el crecimiento de las aplicaciones SaaS, muchas organizaciones necesitan acceso directo y seguro sin depender de redes privadas virtuales (VPN). El problema con el modelo VPN tradicional no es la tecnología en sí, sino el camino que obliga a recorrer al tráfico: incluso si un usuario solo necesita acceder a Microsoft 365, su conexión suele pasar primero por la VPN corporativa para ser inspeccionada en el datacenter, y de ahí recién salir hacia la aplicación en la nube. Ese rodeo agrega latencia y convierte al centro de datos en un cuello de botella — justo lo contrario de lo que se busca cuando la aplicación ya vive fuera de la red corporativa.

A eso se suman otros dos problemas: los equipos de TI terminan administrando muchas herramientas distintas (firewalls, proxies, VPN, cada una con su consola), y la infraestructura física más la gestión de herramientas dispares eleva los costos operativos.

SASE resuelve esto combinando dos ideas: la seguridad entregada como servicio (SECaaS — los proveedores gestionan SWG, CASB, ZTNA y FWaaS desde la nube, sin hardware propio) y la red entregada como servicio (NaaS — el SD-WAN se administra igual, bajo demanda). En la práctica, esto se traduce en un conjunto de tecnologías concretas que conviene ver en funcionamiento.

¿Cómo funciona Secure Access Service Edge?

SASE combina tecnologías de seguridad en la nube con funcionalidades de red de área amplia (WAN) para ofrecer una conexión segura y eficiente, sin importar dónde esté el usuario. Cada componente resuelve un problema puntual, pero todos comparten la misma lógica: aplicar la política de seguridad lo más cerca posible del usuario, no del centro de datos.

• SD-WAN (Red de Área Amplia Definida por Software): enruta de forma inteligente el tráfico hacia aplicaciones y servicios en la nube, optimizando el rendimiento.
• FWaaS (Firewall como Servicio): protege contra amenazas y ataques de red sin depender de un appliance físico.
• CASB (Agente de Seguridad de Acceso a la Nube): monitorea y controla el acceso a las aplicaciones SaaS.
• ZTNA (Acceso a la Red de Confianza Cero): valida la identidad de usuarios y dispositivos antes de otorgar acceso a cada aplicación, en lugar de asumir confianza por estar “dentro” de la red.
• SWG (Puerta de Enlace Web Segura): protege contra amenazas de navegación y controla el acceso a sitios maliciosos.

Estos cinco componentes son el núcleo del modelo. Sobre esa base, los proveedores suman capacidades opcionales como aislamiento remoto del navegador (RBI), protección DNS o inspección de aplicaciones SaaS vía API. Todo esto se aplica desde una red distribuida de PoPs (Points of Presence): decenas o cientos de nodos operados por el proveedor SASE alrededor del mundo. Cuando un usuario se conecta, su tráfico entra al PoP más cercano, ahí se inspecciona y se aplican las políticas correspondientes, y recién después continúa hacia la aplicación de destino — ya sea SaaS, una app privada o internet en general. Esa cercanía geográfica es lo que permite a SASE bajar la latencia frente al modelo de “todo pasa por el datacenter central”.

Ese enfoque de verificar identidad y contexto en cada conexión, sin asumir confianza por ubicación de red, es la base de Zero Trust. SASE no reemplaza a Zero Trust: lo habilita. Zero Trust define el principio (verificar siempre, no confiar por defecto); SASE provee la infraestructura para aplicar ese principio de forma consistente, sin importar si el usuario está en la oficina, en su casa o en un aeropuerto.

Así cambia el flujo de un usuario remoto

La diferencia se nota mejor con un caso concreto. En un modelo tradicional, un empleado que trabaja desde su casa y necesita revisar el correo en Microsoft 365 se conecta primero a la VPN corporativa. Desde ahí, su tráfico atraviesa el firewall perimetral, pasa por el datacenter de la empresa, y solo entonces sale hacia internet para llegar a los servidores de Microsoft. Si ese mismo usuario también necesita Salesforce o algún servicio en AWS, el tráfico repite el mismo camino cada vez, aunque el destino final nunca haya estado cerca del datacenter.

Con SASE, el usuario se conecta directamente al PoP más cercano a su ubicación. Ahí se valida su identidad, se aplican las políticas de acceso y se inspecciona el tráfico — y desde ese mismo punto sale hacia Microsoft 365, Salesforce o AWS, sin pasar por ningún datacenter intermedio. El resultado es menos saltos de red, menos latencia, y una política de seguridad que se aplica igual sin importar qué aplicación esté usando o desde dónde se conecte.

Beneficios de un modelo SASE

1. Seguridad basada en identidad: el acceso se evalúa por quién es el usuario y en qué contexto se conecta, no por la ubicación de red desde la que llega. Se aplica el privilegio mínimo: solo las personas correctas acceden a los recursos correctos.
2. Políticas consistentes: las mismas reglas aplican a todos los usuarios, estén donde estén, lo que también facilita demostrar cumplimiento.
3. Menos herramientas, menos complejidad: red y seguridad se administran desde una sola plataforma en lugar de varias consolas desconectadas.
4. Menor latencia percibida: al inspeccionar el tráfico en el PoP más cercano en lugar de un datacenter central, el usuario nota la mejora en el tiempo de respuesta de sus aplicaciones.
5. Menos hardware propio: al pasar de appliances físicos a un servicio en la nube, se reduce la infraestructura que hay que comprar, mantener y renovar.

Contras y desafíos de adoptar SASE

SASE no es gratis ni mágico, y conviene conocer sus contras antes de firmar un contrato:

• Dependencia del proveedor: en un modelo single-vendor, red y seguridad quedan en manos de una sola empresa. Cambiar después implica rehacer políticas, agentes y conectividad. Es la contracara de la simplicidad.
• Un solo punto de falla: si el proveedor tiene una caída, se afecta el acceso de todos los usuarios a la vez. Un ejemplo: el 18 de noviembre de 2025, un cambio de configuración interno provocó fallas en Cloudflare durante casi seis horas, y entre los servicios afectados estuvo Access, su producto de acceso Zero Trust. Más en Cloudflare. Antes de contratar, pregunta qué pasa con tus usuarios cuando el servicio no responde.
• Inspección de tráfico cifrado: para inspeccionar tráfico HTTPS, el proveedor tiene que descifrarlo en su PoP. Eso implica instalar certificados en los equipos, definir excepciones (banca, salud, aplicaciones con certificate pinning) y aceptar que un tercero ve ese tráfico.
• Costo: el licenciamiento suele ser por usuario o por ancho de banda, y en organizaciones medianas puede superar el costo de mantener el firewall y la VPN que ya tienen amortizados.
• La migración es un proyecto, no un switch: hay que inventariar aplicaciones, redefinir políticas pensadas para el perímetro y convivir un tiempo con ambos modelos.

En los clientes con los que he trabajado, lo más difícil casi nunca es la tecnología: es saber qué aplicaciones se usan realmente y quién necesita acceso a qué. Sin ese inventario, SASE solo traslada a la nube las reglas desordenadas del firewall.

SASE en Latinoamérica: dónde están los PoPs

Toda la promesa de menor latencia depende de algo muy concreto: que el proveedor tenga un PoP cerca de tus usuarios. En Norteamérica y Europa casi cualquier proveedor cumple; en Latinoamérica la cobertura varía mucho y conviene revisarla país por país.

Dos ejemplos tomados de la documentación de los propios proveedores:

• Palo Alto Networks (Prisma Access) tiene ubicaciones de cómputo en São Paulo, Santiago, Lima, Chía (Colombia), Ciudad de México y Monterrey, entre otras. Pero según su lista oficial, el tráfico de países como Argentina, Bolivia o Uruguay se procesa en Santiago, y el de parte de Centroamérica y Ecuador, en una ubicación en EE. UU. Más en Palo Alto Networks.
• Netskope anunció en 2020 centros de datos de su red NewEdge en Buenos Aires, São Paulo, Santiago y Bogotá. Más en Netskope.

Esto tiene dos implicaciones prácticas:

1. Latencia: si el tráfico de tus usuarios en Quito o Ciudad de Guatemala se inspecciona en EE. UU., parte del beneficio de SASE se diluye. Pide al proveedor el mapa de PoPs y mide la latencia real durante una prueba de concepto.
2. Protección de datos: que el tráfico se inspeccione en otro país significa que datos de tus usuarios pasan por infraestructura fuera de tu jurisdicción. Normativas como la Ley 1581 de 2012 en Colombia o la LGPD en Brasil regulan la transferencia internacional de datos personales, así que vale la pena incluir a tu área legal o de cumplimiento en la evaluación.

SASE vs. SSE: la pieza que faltaba en el mapa

Todo lo descrito hasta acá corresponde al modelo SASE completo. Pero desde 2021, Gartner separó una parte de SASE en una categoría propia: Security Service Edge (SSE). SSE agrupa los tres componentes de seguridad de SASE — SWG, CASB y ZTNA — sin incluir la capa de networking. En términos simples: SASE = SSE + SD-WAN.

La distinción existe porque muchas organizaciones ya tienen una red SD-WAN funcional y solo necesitan reemplazar sus herramientas de seguridad heredadas (firewalls, proxies, VPN) por una alternativa entregada desde la nube, sin tocar la capa de networking. SSE cubre ese caso de uso puntual y tiene su propio Magic Quadrant de Gartner desde 2022, separado del de SASE (VentureBeat).

En el Magic Quadrant de SSE de 2026, publicado en julio, Zscaler, Netskope y Palo Alto Networks (vía Prisma Access) volvieron a figurar entre los líderes del segmento. Si tu SD-WAN ya está resuelto y lo que necesitas es modernizar la capa de seguridad, SSE puede ser el punto de entrada más práctico antes de dar el salto a un SASE completo.

¿Cuándo tiene sentido adoptar SASE?

No todas las organizaciones necesitan SASE de inmediato, ni todas necesitan el modelo completo desde el primer día. En términos generales, vale la pena evaluarlo cuando se da alguno de estos escenarios:

• Usuarios distribuidos geográficamente con uso intensivo de SaaS: si buena parte del trabajo diario ocurre en aplicaciones como Microsoft 365, Salesforce o Slack, y los usuarios están repartidos entre distintas oficinas, países o trabajando desde casa, el modelo de inspección centralizada deja de tener sentido.
• Presencia multicloud: empresas que operan en AWS, Azure, Google Cloud u OCI simultáneamente suelen terminar con políticas de seguridad y acceso distintas para cada proveedor. SASE permite unificar esas políticas en una sola capa, independiente de dónde viva cada carga de trabajo.
• Reemplazo de VPN tradicional: si el objetivo es migrar de un acceso basado en “estar conectado a la VPN” a uno basado en identidad, contexto y principios de Zero Trust, SASE (o su subconjunto SSE) es el camino natural.

Si ninguno de estos escenarios aplica todavía — por ejemplo, una organización pequeña, con todo el personal presencial y pocas aplicaciones en la nube — probablemente no valga la pena la complejidad de migrar por ahora.

Lo que más he visto funcionar en clientes es empezar por un caso acotado, normalmente reemplazar la VPN de los usuarios remotos, y ampliar desde ahí. Intentar migrar toda la red y toda la seguridad en un solo proyecto suele terminar en retrasos.

Conclusión

SASE no resuelve todos los problemas de seguridad de un entorno híbrido, pero sí ataca la causa raíz: un perímetro que ya no existe como tal. Para equipos que siguen operando con VPN y firewalls pensados para una red centralizada, migrar a un modelo SASE — completo o por fases, empezando incluso por SSE si el SD-WAN ya está resuelto — es una forma concreta de reducir superficie de ataque sin sacrificar rendimiento para los usuarios remotos. Eso sí: antes de elegir, revisa dónde están los PoPs del proveedor, cómo manejará tus datos y qué pasa cuando su servicio falla.

Las aplicaciones ya no viven en el centro de datos, y los usuarios tampoco. Seguir defendiendo un perímetro físico es proteger una frontera que, para buena parte del tráfico corporativo, dejó de existir hace rato.