Es posible que haya oído hablar de múltiples principios de arquitectura en el contexto de la seguridad de la red en general y de SASE en particular.
Algunos principios de arquitectura de software utilizados por la industria en el contexto de SASE son:

  • Arquitectura de paso único
  • Arquitectura de un solo proxy
  • Arquitectura de ejecución hasta el final
  • Arquitectura escalable
  • Procesamiento paralelo de paso único Arquitectura
  • Traiga su propia función de seguridad Arquitectura
  • Arquitectura nativa en la nube
  • Arquitectura de aislamiento
  • API primero Arquitectura
  • Arquitectura Slicing (segmentación E2E)

Muchos de los principios arquitectónicos anteriores no son nuevos.
Los principios arquitectónicos de paso único, proxy único, procesamiento paralelo de paso único y ejecución hasta el final han sido populares desde los tiempos de la UTM (gestión unificada de amenazas) a principios de la década de 2000, aunque antes se conocían con nombres diferentes.
El objetivo principal de estos principios arquitectónicos es conseguir

  • Mayor rendimiento con un uso eficiente de los recursos.
  • Menor latencia de extremo a extremo
  • Menor fluctuación
  • Mayor elasticidad (Scale-out) y resistencia incluso en caso de ataques DDoS a los servicios de seguridad
  • Introducción más rápida de nuevas funciones de seguridad (Agilidad)
  • Integración de las funciones de seguridad de múltiples proveedores sin introducir ineficiencias (Integración de las mejores tecnologías)
  • Adoptabilidad (Ejecutar en cualquier lugar)
  • Un solo cristal

Evolución

Una de las grandes ventajas del sector de la seguridad de redes es que es dinámico.
Adopta nuevos principios de software y arquitectura de despliegue en cada nueva generación de productos.
También mantiene la protección frente a la sofisticación de los atacantes.
Dicho esto, el mercado de la seguridad de redes está tradicionalmente fragmentado.
Hay múltiples proveedores de seguridad que ofrecen diferentes funciones de seguridad.
Esto es bueno desde el punto de vista de la innovación y debe fomentarse y continuará.
Hay que tener en cuenta que un proveedor puede no ser bueno en todas las funciones de seguridad.
Como se verá más adelante, si cada proveedor proporciona una pila completa para sus funciones de seguridad, habrá enormes ineficiencias y, por tanto, enormes implicaciones de costes.
Además, puede introducir más latencia, lo que podría suponer un reto para algunas aplicaciones.
De ahí la aplicabilidad de los nuevos principios de arquitectura y las mejores prácticas.
La arquitectura del software deberá ser de tal forma que cuide las ineficiencias pero permita la integración de tecnologías de múltiples proveedores para la mejor ciberseguridad.

Antes de la convergencia

La Figura 1 y la Figura 2 son dos ejemplos representativos de la seguridad de la red antes de SASE.
La figura 1 representa el Acceso Seguro a Internet y la figura 2 un ejemplo de Acceso Privado Seguro.
Tenga en cuenta que el orden de las funciones de seguridad en estas imágenes es arbitrario y el orden de ejecución es normalmente específico del despliegue. El acceso seguro a Internet se consigue tradicionalmente utilizando múltiples soluciones de seguridad, como se indica en la figura
1. Es la empresa la que adquiere estas funciones de seguridad y las coloca en una cadena de servicios. Dado que muchas funciones de seguridad requieren el proxy de las conexiones, este encadenamiento también recibe el nombre de encadenamiento de proxy por parte de la industria.
Dado que cada solución de seguridad discreta es autosuficiente y procede de varios proveedores, la funcionalidad común se repite en todas estas soluciones.
La funcionalidad común incluye el control del tráfico en la entrada, la conformación del tráfico en la salida, el filtrado del tráfico para garantizar que sólo el tráfico relevante va a los proxies, la terminación TCP de la conexión del cliente, la nueva conexión TCP hacia el destino, la interceptación SSL/TLS (que en sí misma requiere la generación de certificados a petición emulando el certificado de destino) que incluye el descifrado TLS y el cifrado TLS, la autenticación proxy (Kerberos, NTLM, OIDC), la descodificación HTTP 1.1/2.0.
Esta funcionalidad común en cada caja/aparato virtual, según una estimación, ocupa el 50% de los recursos de CPU de la solución de seguridad total.
El acceso seguro a las aplicaciones también se consigue de forma similar encadenando la solución de seguridad discreta, como se muestra en la figura
2. También en este caso, la funcionalidad común es la misma en varias soluciones de seguridad. Es casi como la funcionalidad común de las soluciones de seguridad utilizadas en el Acceso Seguro a Internet.
Algunas diferencias incluyen la terminación SSL/TLS en lugar de la interceptación y la autenticación del usuario a través de métodos tradicionales en lugar de la autenticación proxy.
La sobrecarga media de la funcionalidad común en una solución de seguridad podría suponer hasta el 50% de la solución total.
La latencia debida a esta arquitectura puede subir unos milisegundos debido al encadenamiento de funciones. Otro gran reto al que se enfrentan las empresas con appliances físicos y virtuales es el del escalado.
Originalmente, el escalado se realizaba utilizando appliances más grandes o asignando más recursos de CPU y memoria a las soluciones de seguridad basadas en VM.
Esto se denomina escalado.
Si el tráfico es de volumen constante, tiene sentido que las empresas gasten dinero en aparatos físicos/virtuales más grandes.
Pero, si el tráfico es de ráfagas, a las Empresas no les gusta que se malgaste el dinero.
Piense en casos en los que sólo unos pocos días al año el tráfico es mayor.
¿Por qué querrían las empresas gastar dinero en estas ráfagas durante todo el año?
Eso condujo a la siguiente evolución, en la que los proveedores de seguridad empezaron a dar soporte a la arquitectura scale-out a través de un servicio en la nube.
Esto es como el razonamiento de IaaS en el mundo de las aplicaciones en la nube.
En la arquitectura scale-out, se ponen en marcha automáticamente más instancias de las soluciones de seguridad al detectar un mayor tráfico o debido a un ataque DDoS y se reducen cuando baja la demanda.
La imagen 3 muestra esa arquitectura scale-out. No cabe duda de que se necesita una funcionalidad escalable.
Sin embargo, necesita un equilibrador de carga en cada solución de seguridad.
Este equilibrador de carga es necesario para equilibrar la carga de las sesiones a través de múltiples instancias de la solución de seguridad.
Múltiples travesías del equilibrador de carga requieren más recursos y aumentan la latencia de extremo a extremo de las sesiones de tráfico.
La próxima evolución de la arquitectura de seguridad de la red aborda los retos de

  • Necesidad de un mayor número de recursos informáticos
  • Mayor latencia

Con

  • Una arquitectura proxy
  • Arquitectura de paso único

Arquitectura de un solo paso y de un solo proxy (arquitectura convergente)

Como se muestra en la figura 4 a continuación, todas las funciones de seguridad se agrupan con el proxy y otras funciones comunes que sólo entran en escena una vez.
Todas las funciones de seguridad se invocan de una en una en modo «ejecutar para completar».
Como resultado, esta arquitectura consume recursos informáticos de forma eficiente.
Dado que todas las funciones se llaman en el mismo contexto de espacio de usuario, se evitan las copias de memoria.
Además, la arquitectura de un proceso en el espacio de usuario reduce drásticamente los cambios de contexto del sistema operativo.
Una única instancia de proxy puede procesar varias sesiones a la vez mediante multihilos, en los que cada hilo procesa un subconjunto de sesiones, con lo que se aprovechan eficazmente las CPU multinúcleo.
La capacidad multihilo también permite que algunas funciones de seguridad se ejecuten en paralelo en lugar de en serie para una sesión de tráfico determinada, mejorando así la latencia.
Esta arquitectura se denomina «procesamiento paralelo de paso único». Para hacer frente a cargas imprevistas y abordar escenarios DDoS, se adopta una arquitectura de autoescalado con una instancia de equilibrador de carga que se encarga del equilibrio de carga de la sesión. En esta arquitectura, el proxy expone una interfaz API.
Todas las funciones de seguridad se enganchan a esta API.
El proxy llama a las funciones de seguridad enganchadas relevantes durante el procesamiento de la sesión de tráfico.
No todas las funciones de seguridad pueden ser implementadas por los desarrolladores de soluciones SASE.
Los desarrolladores de soluciones SASE trabajan con los proveedores de tecnología integrando los motores y feeds de los proveedores de tecnología con los proxies.
De esta forma, los clientes de los proveedores de SASE obtienen lo mejor de ambos mundos: SASE de alto rendimiento con las mejores implementaciones de seguridad.
Dicho esto, es posible que algunos proveedores de tecnología no entreguen el motor en forma de SDK para desarrollar funciones de seguridad como parte del proxy.
Puede ser que lo tengan como un servicio en la nube.
DLP es un ejemplo en el que muchos proveedores de tecnología lo tienen como servicio en la nube.
También, en algunos casos, puede ser que el proveedor de la solución SASE no quiera integrar algunas funciones de seguridad en el mismo contexto de proceso del espacio de usuario del proxy por razones como limitaciones de memoria, para evitar incompatibilidad de licencias, para evitar hacer frágil el espacio de usuario y otras.

Arquitectura unificada y funciones de seguridad Bring Your Own

A continuación se muestra la siguiente evolución de la arquitectura SASE.
Hay tres puntos destacados que se muestran a continuación en la Figura 6. Soporte para servicios de seguridad a través de ICAP (Internet Content Adaptation Protocol): Las empresas pueden estar acostumbradas o desear utilizar servicios de seguridad de otros proveedores de seguridad. Las especificaciones ICAP del IETF especifican cómo los proxies pueden hablar con servicios externos de adaptación de contenidos, incluidos los servicios de seguridad.
Al permitir servicios de seguridad externos, los proveedores de soluciones SASE permiten a las empresas elegir sus servicios de seguridad. Traiga sus propias funciones de seguridad: Según el informe de seguridad de IBM sobre «Coste de una violación de datos Informe 2022», las Organizaciones están tardando una media de 277 días en detectar y contener una violación de datos.
Aunque SASE proporciona una muy buena configuración de políticas, podría ser que parte de la contención de la violación de datos requiera reglas programáticas.
Las organizaciones que analizan la violación de datos están en una buena posición para desarrollar estos programas.
Dependiendo de los proveedores de SASE o de los servicios de seguridad, los vendedores pueden tardar tiempo, ya que los lanzamientos de productos necesitan pasar por un ciclo de vida completo de desarrollo de software.
Para evitar estos retrasos, las nuevas arquitecturas SASE ofrecen a los equipos de seguridad de las empresas la posibilidad de desarrollar reglas programáticas por sí mismos y desplegarlas.
Dado que éstas no deben causar inestabilidad en el proxy, las arquitecturas SASE proporcionan tiempos de ejecución WASM para permitir la creación de reglas programáticas como módulos WASM.
Dado que el tiempo de ejecución WASM actúa como la caja de arena, cualquier problema con los módulos WASM no causa que el espacio de usuario anfitrión y otros plugins de funciones de seguridad se bloqueen/mueran. Proxy unificado: Un proxy unificado tanto para el Acceso Seguro a Internet como para el Acceso Seguro a Aplicaciones puede reducir los requisitos de memoria.
Los motores y alimentadores de algunas funciones de seguridad, como Anti-Malware y DLP, son acaparadores de memoria.
Por lo tanto, poner en marcha dos instancias de proxy diferentes para cada sitio de la empresa puede resultar costoso.
Además, disponer de un proxy que admita los tres modos (directo, inverso y transparente) es una buena práctica de desarrollo también desde el punto de vista de la productividad del desarrollador.

Otros principios de arquitectura seguidos en la nueva generación de arquitectura SASE son

Nativo de la Nube: Como se ha comentado en el SASE Universal de esta entrada del blog, los servicios SASE son necesarios en On-Prem, Nubes y Bordes.
Por lo tanto, las arquitecturas SASE de nueva generación están siguiendo los principios «nativos de la nube» para hacer que SASE funcione en cualquier lugar.
Aunque Nube nativa y Kubernetes no son sinónimos, muchas veces, las soluciones que dicen Nube nativa están basadas en Kubernetes.
La razón para elegir que las soluciones funcionen en Kubernetes es que todos los proveedores de nube/borde ofrecen Kubernetes como servicio y, lo que es más importante, la interfaz API se mantiene intacta por parte de los proveedores de nube/borde.
Debido a la coherencia de la interfaz API de Kubernetes en todos los proveedores de nube/borde, las soluciones SASE basadas en K8s funcionan sin problemas en todos los proveedores de nube/borde. Arquitectura de aislamiento: Las arquitecturas SASE actuales, por razones de eficiencia, permiten el paso de varias sesiones de inquilino a través de procesos de espacio de usuario compartidos.
Se utilizan métodos ingeniosos para garantizar que se mantiene cierto nivel de aislamiento aunque haya direcciones IP solapadas entre los inquilinos.
Los procesos de espacio de usuario compartidos para múltiples arrendatarios no son algo bueno desde el punto de vista del rendimiento y del aislamiento de seguridad.
Con recursos compartidos, es posible que cualquier mal comportamiento, como un ataque DDOS a un inquilino, pueda causar problemas de rendimiento en el tráfico de otros inquilinos.
Además, cualquier exploit en el proceso del espacio de usuario compartido puede exponer todos los secretos/contraseñas/claves de todos los inquilinos.
Teniendo en cuenta lo anterior, las arquitecturas SASE de nueva generación apuestan cada vez más por instancias proxy dedicadas, ya sea mediante procesos de espacio de usuario dedicados o contenedores dedicados. Arquitectura API first: Las soluciones SASE actuales proporcionan CLI y Portal para configurar y observar.
Algunas soluciones SASE utilizan APIs entre CLI/Portal a sistemas de gestión backend, que no se anuncian.
En algunos casos, las API no se han limpiado.
Las nuevas soluciones SASE están adoptando la arquitectura API first, en la que las API se definen no sólo para las implementaciones de CLI y Portal, sino también para que terceros desarrollen entidades programáticas externas.
Las API permiten SecOps-as-code a través de terraform y otros, desde el desarrollo de scripts sencillos hasta el desarrollo de flujos de trabajo complejos.
La práctica general es optar por API RESTful, cargas útiles JSON con documentación basada en OpenAPI, pero algunas también exponen recursos personalizados de Kubernetes para configurar objetos y políticas de seguridad y redes.
También se espera que la arquitectura API First separe la lógica backend real de la implementación del RBAC (control de acceso basado en roles).
La experiencia de la industria es que existe un buen número de vulnerabilidades cuando se combinan tanto el RBAC como la lógica empresarial.
Como resultado, la industria se está moviendo hacia la separación de la funcionalidad RBAC a entidades externas y dejando que las aplicaciones se centren en la lógica empresarial.
La misma lógica se está aplicando para los sistemas de gestión SASE, donde los sistemas de gestión SASE se centran en la política/objetos SAE y la observabilidad y dejan la funcionalidad RBAC a entidades externas como los proxies de entrada y las pasarelas API.
Los proxies de entrada se encargan de toda la autenticación y autorización y del enrutamiento de la API.
Lo bueno es que un proxy de entrada puede servir de frontend a múltiples aplicaciones.
Debido a esto, los usuarios administradores sólo necesitan familiarizarse con una entidad RBAC a través de muchas aplicaciones. Para esta separación de la lógica empresarial del RBAC, se espera que las soluciones de arquitectura API-first sigan algunas directrices.
Por ejemplo, muchos proxies de entrada y pasarelas API esperan que se utilice URI para apuntar a un recurso para RBAC.
En el caso de la automatización basada en flujos de trabajo, se espera que los sistemas de gestión puedan etiquetar la configuración y restaurar a etiquetas anteriores para permitir patrones de saga.
Se espera que cualquier arquitectura API-first siga las mejores prácticas del sector.

Resumen

Las arquitecturas de seguridad de red están evolucionando de entidades físicas/monolíticas a dispositivos virtuales y contenedores.
Muchos principios nativos de la nube que se hicieron populares en el mundo de las aplicaciones se están adoptando en las soluciones SASE para obtener los beneficios similares a los de la nube, incluyendo la escalabilidad de salida y entrada, la agilidad, la preparación para múltiples nubes / bordes y el uso de los recursos de manera eficiente a través de múltiples inquilinos.
Esté atento a este espacio para conocer los nuevos principios de arquitectura y cómo Aryaka está aprovechando las tecnologías similares a la nube.

  • Blog CTO Insights

    La serie de blogs Aryaka CTO Insights proporciona liderazgo de pensamiento para temas de red, seguridad y SASE.
    Para conocer las especificaciones de los productos Aryaka, consulte Aryaka Datasheets.