El riesgo de la ciberseguridad en SASE: la inspección de paquetes ya no basta
Publicado el
La evolución de SASE y sus limitaciones
Durante años, el enrutamiento del tráfico a través de proxies en la nube fue una solución aceptable para las empresas. Sin embargo, con el cambio del trabajo hacia los navegadores y la integración de herramientas de inteligencia artificial (AI), este modelo ha dejado de ser suficiente. Las interacciones de datos han migrado a la capa de presentación, donde las arquitecturas centradas en la red nunca fueron diseñadas para operar.
La lucha de la seguridad tradicional
El modelo SASE tradicional se basa en redirigir el tráfico a proxies en la nube para su desencriptación, inspección y aplicación de políticas. Sin embargo, protocolos modernos de Internet como TLS 1.3, HTTP/3 y la fijación de certificados fueron diseñados para prevenir la interceptación de tipo hombre en el medio. Cuando un proxy intenta desencriptar una sesión TLS 1.3, la aplicación cliente a menudo interrumpe la conexión, lo que obliga a los equipos de red a crear excepciones que debilitan la seguridad. Esto genera una lista de excepciones cada vez más extensa y, por tanto, un perímetro de seguridad reducido.
Además, este modelo impone una penalización en el rendimiento. La necesidad de forzar las sesiones a través de caminos de inspección lejanos provoca un aumento en la latencia de las aplicaciones y problemas en las videollamadas. Cuando las herramientas críticas se vuelven lentas o inestables, los usuarios buscan soluciones alternativas, aumentando la superficie de ataque que los equipos de IT intentan proteger.
El impacto de la AI y el "Momento de Intención"
La penetración de la AI y los flujos de trabajo autónomos resaltan esta brecha arquitectónica. Un proxy de red tradicional puede detectar una conexión HTTPS válida hacia un proveedor de LLM, pero no tiene visibilidad sobre la intención del contenido. Por ejemplo, un agente AI puede utilizar llamadas a herramientas para extraer código propietario sin que el proxy pueda detectarlo. Cuando los datos llegan a un punto de inspección, la interacción ya ha tenido lugar, y el momento de intención se ha perdido.
Esto coloca a los equipos de seguridad en una posición difícil: bloquear completamente la AI podría empujar a los usuarios hacia soluciones de shadow IT, mientras que permitir su uso sin restricciones conlleva una falta total de visibilidad sobre los datos.
La necesidad de un cambio arquitectónico
Para gestionar la AI y las modernas aplicaciones SaaS, la aplicación de políticas de seguridad debe llevarse a cabo en el punto de interacción, es decir, en el dispositivo. Esto implica que el tráfico debe ser guiado dinámicamente hacia la infraestructura de borde más cercana para eliminar saltos innecesarios que perjudican el rendimiento.
La evaluación de políticas en el último tramo transforma completamente el modelo de enforcement: - Protección de datos contextual: El contenido copiado, pegado y los prompts se inspeccionan localmente antes de que los datos abandonen el dispositivo. - Alineación nativa de protocolos: Los protocolos de encriptación modernos funcionan sin la necesidad de flujos de desencriptación invasivos. - Rendimiento de camino directo: Hasta el 90% del tráfico confiable sigue un camino directo hacia su destino, eliminando la penalización del proxy y restaurando la velocidad nativa de las aplicaciones para el usuario final.
Este cambio impulsa la adopción de la arquitectura de "Paquete Perfecto", que evalúa el contexto en el endpoint antes de redirigir, utilizando la inspección en la nube solo cuando es necesaria una verificación adicional.
Conclusión
La seguridad centrada en la red no puede controlar lo que ocurre dentro de una pestaña de aplicación o en un flujo de trabajo de AI. Para abordar la brecha de visibilidad del proxy y restaurar el rendimiento nativo de las aplicaciones, es fundamental adoptar arquitecturas modernas que se adapten a las necesidades actuales de seguridad.