¿Por qué la conciencia de identidad en SASE?
Mi anterior blog sobre Descifrando SASE hablaba sobre la conciencia de identidad en varios componentes de seguridad de SASE.
Este post describe los diversos métodos para realizar SASE consciente de la identidad.
Los controles de acceso en la seguridad tradicional centrada en el perímetro se definen utilizando direcciones IP y servicios.
Los clientes se representan como direcciones IP en las políticas de acceso, y los servicios se definen con nombres de dominio y direcciones IP junto con puertos TCP/UDP como el puerto 80 para HTTP y 443 para HTTPS, etc.
Dado que existen diferentes tipos de clientes – usuarios humanos que acceden a los servicios a través de PCs/portátiles/móviles, aplicaciones cliente, dispositivos IoT y varias categorías de usuarios humanos, se inventa un enfoque de segmentación en el que cada segmento representa varios tipos de clientes.
A cada segmento se le asigna su propia subred o rango de direcciones IP.
Esto permite definir controles de acceso para distintos tipos de clientes.
Aunque solucionó algunos problemas a la hora de definir los controles de acceso para varios clientes, introdujo otra serie de complejidades: la gestión de segmentos.
Rápidamente, muchas organizaciones empezaron a ver la explosión de los segmentos.
Las organizaciones empezaron a ver la necesidad de crear varios segmentos para definir una QoS diferenciada, la selección de enlaces WAN y varios tipos de controles de acceso de seguridad.
Otro gran reto de la segmentación está relacionado con el «trabajo desde cualquier lugar«.
Es decir, la dirección IP del usuario cambia en función del lugar desde el que trabaje.
En este caso, la asociación del usuario con un segmento se convierte rápidamente en un gran reto.
Los usuarios que trabajen desde oficinas designadas, desde casa, desde cafeterías, desde otra oficina o desde oficinas asociadas deberán ser tratados de la misma manera, independientemente del lugar desde el que trabaje el usuario.
El SASE consciente de la identidad simplifica la gestión de segmentos al eliminar la necesidad de crear segmentos para diferenciar a los clientes, al menos para los usuarios humanos.
Sin embargo, no podrá deshacerse por completo de los segmentos para clientes como los dispositivos IoT.
El SASE consciente de la identidad también es necesario para la «ciencia forense digital». Cuando se produce cualquier violación de datos, es importante saber qué ocurrió durante el ataque para comprender el enfoque utilizado por los atacantes, los puntos débiles explotados e identificar el impacto global.
Según el «Informe 2022 de Verizon sobre la violación de datos«, en el 82% de las violaciones de datos intervino el elemento humano.
Por lo tanto, la identidad de cada conexión/sesión se vuelve superimportante para comprender los patrones de acceso, los sitios visitados, los dispositivos y las aplicaciones utilizadas por el usuario que dieron lugar a la primera infección.
Luego, eso puede ayudar aún más a descubrir los ataques laterales que finalmente dan lugar a la brecha.
En resumen, el conocimiento de la identidad en SASE ayuda en:
- Definición de políticas de acceso diferenciadas a través del cortafuegos, SWG, CASB y ZTNA para varios usuarios
- Definición de políticas de red diferenciadas a través de QoS, Enrutamiento para varios usuarios
- Análisis forense digital
- Análisis del comportamiento de los usuarios
Identidad en las políticas SASE
Los componentes de SASE controlan el acceso a varios servicios/sitios en diferentes granularidades.
Los cortafuegos de SASE controlan el acceso en las capas L3/L4.
SWG controla el acceso a nivel de URLs.
ZTNA y CASB controlan el acceso a nivel de API.
SWG, ZTNA y CASB con DLP pueden controlar el acceso a nivel de datos.
Todos estos controles son necesarios con el usuario como uno de los selectores por las razones explicadas anteriormente y para cumplir las directrices de confianza cero especificadas por el NIST.
Cualquier política de control de acceso contiene un conjunto de reglas, en su mayoría reglas ordenadas.
Estas reglas se comprueban en cada sesión de tráfico.
Si la regla coincide, se toman las acciones especificadas en la regla coincidente.
Las acciones típicas incluyen permitir el tráfico, denegarlo o simplemente supervisar y registrar el tráfico.
La coincidencia de cualquier regla se realiza con un conjunto de atributos.
Cada regla se especifica con los valores de esos atributos.
Esos atributos incluyen tradicionalmente 5-tuplas (IP de origen, IP de destino, Protocolo, Puerto de origen y Puerto de destino), Zonas y ubicaciones.
Ante una nueva sesión de tráfico, los valores se extraen del paquete y del contexto (zona, ubicación) y se cotejan con los valores de los atributos de la regla.
Si coinciden, se dice que la regla está emparejada.
Con la conciencia de identidad SASE, los atributos de coincidencia de reglas incluyen atributos de usuario.
Los atributos de usuario pueden ser un conjunto de nombres de usuario individuales, grupos de usuarios, roles de usuario, nombres de sujeto de certificado de cliente o nombres alternativos de sujeto de certificado.
La coincidencia de políticas incluirá la coincidencia con el contexto de usuario para SASE basado en la identidad.
La coincidencia de políticas típica en una nueva sesión de tráfico es la siguiente:
- Extraiga 5 tuplas (dirección IP de origen, dirección IP de destino, protocolo IP, puerto de origen y puerto de destino) del paquete.
- Obtenga la zona y la ubicación de origen de la sesión de tráfico.
- Obtenga la información del usuario (nombre, grupo de usuarios y rol de usuario) que inició la sesión de tráfico.
- Obtenga la postura del dispositivo de la máquina desde la que se originó la sesión de tráfico.
- Recorra las reglas de arriba a abajo de la política cotejando la información extraída anteriormente con los valores de los atributos de coincidencia de las reglas.
Si hay una coincidencia, tome la acción especificada en esa regla.
Si no, pase a la siguiente regla. - Si no hay ninguna regla coincidente, tome la acción configurada para ese nivel de tabla de políticas.
Identificación y autenticación de usuarios
Dado que es necesario identificar a un usuario antes de realizar cualquier comprobación de políticas en las sesiones de tráfico, surgen algunas preguntas:
- ¿Cómo autentica SASE a los usuarios?
- ¿Cómo identifica SASE al usuario cuando recibe el tráfico?
Antes de llegar ahí, veamos algunas de las consideraciones que deben tener en cuenta las soluciones SASE.
SASE debe tener en cuenta los siguientes tipos de clientes:
- Usuarios humanos que utilizan navegadores para acceder a los servicios
- Usuarios humanos que utilizan aplicaciones que no son navegadores para acceder a los servicios
- Aplicaciones sin navegador que funcionan sin intervención humana para acceder a los servicios
- Aplicaciones ajenas al navegador con fijación de certificados CA
- Dispositivos IoT que acceden a servicios
La implicación es que las soluciones SASE no pueden asumir que siempre hay usuarios humanos iniciando las sesiones de tráfico.
Puede haber entidades programáticas y dispositivos iniciando las sesiones de tráfico. Se espera que SASE sirva a ambos tipos de clientes y, por lo tanto, las soluciones SASE soportan múltiples métodos de autenticación.
SASE debe tener en cuenta los siguientes retos de la experiencia del usuario:
- Experiencia de usuario en la que a los usuarios humanos no se les muestra ninguna o menos pantallas emergentes para la toma de credenciales de usuario.
- Experiencia de usuario en la que se informa a los usuarios humanos de por qué se deniega un determinado acceso
- Usuarios que utilizan sus propios dispositivos para acceder a los servicios
- Usuarios que utilizan dispositivos gestionados por la empresa para acceder a los servicios
- Experiencia uniforme para los usuarios, tanto si trabajan desde casa como desde la oficina
Con estos requisitos e implicaciones, las soluciones SASE implementan varios modos de autenticación.
La mayoría de los modos de autenticación soportados por las soluciones SASE se enumeran aquí.
- Autenticación por proxy inverso
- Autenticación de proxy de reenvío
- Autenticación basada en portal
- Autenticación del túnel
- Autenticación de certificados de cliente
- Autenticación basada en claves API
Una vez que los clientes se autentiquen en SASE a través de lo anterior, SASE deberá tener una forma de asociar las sesiones de tráfico iniciadas por el usuario con el usuario correcto.
Se utilizan dos enfoques de mapeo de identificación.
Estos son:
- Mapeo de token: Las soluciones SASE identifican al usuario a partir del token de autenticación/identidad/portador en las cabeceras de solicitud de las sesiones de tráfico HTTP/HTTPS.
Los clientes reciben tokens como parte de la autenticación y los mismos son presentados por los clientes en las sesiones de tráfico. - Mapeo IP representativo: En este enfoque, la dirección IP representa al usuario.
Las soluciones SASE utilizan la dirección IP de origen de la sesión de tráfico para identificar al usuario.
Cuando un usuario se autentica por primera vez con el SASE con éxito, el SASE registra la dirección IP del usuario para ese usuario.
Cualquier sesión de tráfico, en un momento posterior, procedente de esta dirección IP se asocia entonces con el usuario.
Los tokens sólo son válidos para las sesiones de tráfico HTTP/HTTPS.
Dado que los tokens están presentes en todas las sesiones HTTP, ya sea directa o indirectamente a través de cookies, se considera más seguro que la ‘IP Representativa’ Para las sesiones de tráfico no HTTP/HTTPS, el mapeo de la ‘IP Representativa’ es utilizado por las soluciones SASE.
Tenga en cuenta que el método de mapeo de ‘IP Representativa’ tiene algunos desafíos ya que la dirección IP es utilizada por todas las aplicaciones en la máquina. Es decir, aunque un usuario del navegador se autentique en la solución SASE, no sólo el navegador sino también todas las demás aplicaciones cliente que se ejecuten en la máquina tendrán el mismo acceso. En el caso de sistemas multiusuario, todos los usuarios de ese sistema tendrán acceso incluso si un usuario se autentica con éxito con la solución SASE. Aún más peligroso es si el sistema utilizado para autenticarse en el sistema SASE está detrás de un dispositivo NAT. Todos los usuarios detrás de esa dirección IP NAT obtendrán acceso. Por lo tanto, es particularmente importante utilizar la función de «IP representativa» sólo cuando sea necesario e intentar restringir este mapeo sólo a sesiones no HTTP/HTTPS.
Dado que el token (a través de la cabecera proxy-authorization o la cabecera authorization o a través de una cookie) forma parte de cada solicitud HTTP, sólo la aplicación cliente que está autenticada con la solución SASE puede enviar el token.
Se espera que otras aplicaciones cliente basadas en web que requieran acceso se autentiquen con la solución SASE para obtener acceso.
Debido a los beneficios de seguridad, es muy recomendable utilizar el enfoque de mapeo de token para todas las sesiones HTTP/HTTPS.
Autenticación e identificación de usuarios por varios componentes de SASE
Muchos componentes SASE que proporcionan seguridad para aplicaciones/servicios basados en web tienden a identificar y asociar usuarios a sesiones de tráfico mediante tokens en las cabeceras de las peticiones HTTP, certificados de cliente o claves API.
Las siguientes secciones proporcionan un mapeo de los modos de autenticación relevantes y mejores para varios componentes SASE.
ZTNA
ZTNA, como ya se comentó en este blog anterior, tiene como objetivo proteger las aplicaciones empresariales de clientes maliciosos e infectados.
ZTNA, mediante servicios de aplicaciones frontales, proporciona las siguientes características.
- Seguridad TLS/SSL para aplicaciones sin TLS/SSL y para aplicaciones que no admiten algoritmos de criptografía fuerte
- RBAC / soporte de acceso de mínimo privilegio para aplicaciones que no soportan ningún RBAC y para aplicaciones que requieren RBAC de segundo nivel
- Gestión de acceso a privilegios con un nivel más de MFA
- Equilibrio de la carga de tráfico entre varias instancias de la aplicación
- WAF y seguridad de protección contra amenazas a nivel de API para aplicaciones
La ZTNA se está convirtiendo cada vez más en una necesidad, ya que aleja la responsabilidad de la seguridad de los servicios de aplicación.
Los beneficios resultantes incluyen un aumento de la productividad en el desarrollo de aplicaciones empresariales, una configuración uniforme de la seguridad en múltiples servicios de aplicación y una menor superficie de ataque.
La ZTNA está pensada principalmente para asegurar las aplicaciones basadas en web.
Los desarrolladores de aplicaciones no sólo están creando nuevas aplicaciones con protocolos web, sino que también las aplicaciones existentes se están webificando para aprovechar las innovaciones que se están produciendo en los protocolos web.
Incluso los protocolos de administración tradicionales como SSH se están webificando mediante proyectos como Apache Guacamole.
Dicho esto, siempre habrá aplicaciones no web.
Un cortafuegos como parte de SASE proporciona control de acceso y seguridad de protección contra amenazas para los servicios Enterprise instanciados no web.
Por favor, consulte la sección de cortafuegos para más detalles. ¿Cómo accede ZTNA al tráfico? La ZTNA obtiene acceso al tráfico de dos formas: a través del método DNS y del método proxy transparente.
Los administradores de las aplicaciones empresariales configuran los servidores de dominio autoritativos para que apunten a la ZTNA de las aplicaciones.
Es decir, los administradores configuran los servidores DNS para que respondan con direcciones IP de ZTNA a las consultas DNS sobre los FQDN de las aplicaciones.
En el método de proxy transparente, se espera que la ZTNA esté en la línea de tráfico o que una entidad en la línea de tráfico intercepte el tráfico y lo envíe a la ZTNA.
Los administradores de aplicaciones también configuran ZTNA con pares de certificados TLS/SSL/claves privadas en nombre de los servicios de aplicación. ¿Cómo autentica ZTNA a los usuarios y asigna las sesiones de tráfico a los usuarios? ZTNA admite los modos de autenticación de proxy inverso, certificado de cliente y clave API para autenticar varios tipos de clientes: usuarios humanos y entidades programáticas.
Su funcionamiento es el siguiente:
- ZTNA finaliza la conexión TLS/SSL
- Si se negocia el certificado del cliente, entonces valida el certificado del cliente.
Si es válido, entonces extrae el nombre del sujeto del certificado y el SAN (Subject Alt Name).
Esas son las identidades del usuario cliente.
Si se aprovisiona algún grupo o rol de usuario, extrae la información del grupo y del rol de la base de datos aprovisionada. - Si el cliente presenta la clave API, se remite a la base de datos interna (provisionada) para extraer la identidad del usuario.
Si se aprovisiona algún grupo o rol de usuario, extrae la información del grupo y del rol de la base de datos aprovisionada. - Si la solicitud HTTP tiene un token de autenticación/identidad asociado, significa que el usuario fue autenticado anteriormente.
También significa que el contexto del usuario (nombre de usuario, grupo de usuarios y rol de usuario si lo hay) es conocido por la ZTNA. - Si el token no es válido o si no hay token, pide al usuario que se identifique y autentique a través de OIDC.
El corredor OIDC de la ZTNA puede, a su vez, utilizar varios protocolos de autenticación para que el usuario se autentique con los servicios de autenticación de la empresa.
Para las cuentas privilegiadas, la ZTNA realiza su propia MFA para garantizar que el usuario es realmente un usuario genuino. - Si el usuario se autentica con éxito, el componente OIDC de ZTNA establece el token de identidad.
También anota la información del usuario (nombre de usuario, grupo de usuarios, si lo hay, y rol de usuario, si lo hay). - A continuación, ZTNA establece una conexión con una de las instancias del servicio de aplicación.
- Realiza decisiones de control de acceso basadas en el usuario por transacción HTTP.
- Si ZTNA está configurado para la protección avanzada frente a amenazas, también analiza el tráfico en busca de exploits, malware y fugas de datos confidenciales.
A un usuario se le presenta una pantalla para que proporcione sus credenciales una sola vez hasta que caduque el token de identidad.
Debido a la política de mismo origen de los clientes, éstos siempre presentan el token de identidad correcto en las transacciones HTTP hacia los servicios de aplicación.
Si el token de identidad es válido, la ZTNA utilizará esa información para asignar la sesión al usuario correcto.
SWG y CASB
El componente SWG protege a los usuarios de la visita a sitios de malware, phishing e inseguros.
También protege a las aplicaciones cliente para que no entren en contacto con sitios de redes de bots C&C en caso de infección.
Además, SWG proporciona una forma de proporcionar acceso diferenciado a varios sitios en función del papel de los usuarios en la organización y del grupo al que pertenezcan.
SWG también registra los metadatos de la sesión de tráfico junto con la información del usuario que puede ayudar en diversos análisis y análisis forenses digitales.
El componente CASB protege los datos de la empresa mantenidos por los proveedores de SaaS garantizando que sólo los usuarios adecuados accedan a los datos y los modifiquen mediante el control de acceso a nivel de API para diversas aplicaciones de SaaS.
CASB, al igual que SWG, también registra los metadatos de la API con la información del usuario para diversos análisis y análisis forenses digitales.
Tanto los componentes SWG como CASB requieren la inspección del tráfico HTTP/HTTPS que va de los usuarios a los sitios de Internet.
SWG y CASB terminan las conexiones de los clientes, realizan la interceptación SSL si está permitida, y realizan una inspección más profunda del contenido para detectar y prevenir el malware y detener cualquier filtración de datos sensibles. ¿Cómo acceden SWG y CASB al tráfico? El proxy SWG y CASB se hace con el tráfico a través de dos métodos: el método proxy/PAC y el método transparente.
En el método proxy/PAC, las máquinas/aplicaciones cliente se configuran manualmente con los ajustes del proxy o las aplicaciones cliente se autoconfiguran mediante el autodescubrimiento de proxies.
Una vez que las aplicaciones cliente conocen los proxies, las aplicaciones cliente utilizan el método HTTP CONNECT para tunelizar las sesiones de datos, que normalmente serían transacciones HTTP y HTTPS.
HTTP CONNECT URI indica el destino previsto de las transacciones HTTP & HTTPS internas.
El proxy utiliza esta URL para establecer la conexión con el sitio de destino.
Los proxies realizan cualquier servicio de control de acceso y protección contra amenazas antes de permitir que los datos pasen de los clientes a los servidores y viceversa.
En el método de proxy transparente, los clientes no conocen los proxies.
Se espera que los proxies estén en la línea de tráfico para hacerse con él. ¿Cómo autentica el proxy SWG/CASB a los usuarios y asigna las sesiones de tráfico a los usuarios? Si se utiliza el método proxy/PAC para llegar al proxy SWG/CASB, entonces los proxies tienen la oportunidad de autenticar a los usuarios como parte de la transacción HTTP CONNECT.
Esto se llama «autenticación de proxy hacia adelante».
La autenticación de proxy de reenvío basada en HTTP CONNECT se describe aquí muy bien.
Aunque este enlace describe la autenticación NTLM, un flujo similar es igualmente aplicable para la autenticación Kerberos también.
Dado que HTTP CONNECT precede a cada sesión de tráfico HTTP/HTTPS, el usuario es conocido por el proxy en cada sesión.
Lo bueno de este método es que la mayoría de las aplicaciones cliente nativas, además de las aplicaciones de navegador, también respetan la configuración del proxy y pueden autenticarse con los proxies, cubriendo así la mayoría de los casos de uso del acceso a Internet.
En el método de proxy transparente, no hay transacción HTTP CONNECT.
Por lo tanto, no es posible la autenticación mediante proxy transparente.
Cualquier autenticación de usuario debe realizarse con esquemas de autenticación HTTP normales, como redirigir la solicitud HTTP al portal SASE, que a su vez utiliza métodos OIDC y SAML para autenticar a los usuarios.
Este tipo de autenticación se llama «Autenticación basada en el portal».
Una vez que el usuario se registra con éxito, el portal puede establecer la cookie, pero ésta no es visible para el proxy cuando el usuario navega por los sitios de Internet debido a la política del mismo origen en los navegadores.
Debido a este desafío, una vez que el usuario se conecta con éxito, el portal crea el mapeo entre el nombre de usuario y la dirección IP de origen de la sesión de autenticación del usuario e informa al proxy de este mapeo.
El proxy utiliza posteriormente este mapeo para asignar las sesiones de tráfico al usuario.
Si no hay ningún mapeo disponible, entonces el proxy redirige la sesión de tráfico al portal para el inicio de sesión.
Este «mapeo» se denomina «mapeo IP representativo».
Como se ha descrito anteriormente, este método de mapeo deberá utilizarse con cuidado, ya que podría abrir el acceso a partes no deseadas.
Los métodos de proxy transparente dependen de la redirección de las transacciones HTTP entrantes.
Esto significa que necesita hacerse con el tráfico transparente a través de la interceptación SSL.
Hay casos en los que la interceptación SSL/TLS no está permitida o no es posible.
Como la redirección no es posible en estos casos, se espera que el usuario se autentique en SASE a través de otros mecanismos, como la autenticación proactiva con el portal o a través de la «Autenticación de Túnel».
Cortafuegos y funciones basadas en L3/L4
El cortafuegos y las funciones NAT, de enrutamiento y QoS asociadas trabajan sobre los paquetes a nivel de las capas L3/L4.
Estas funciones tienen que estar en sistemas que estén en la línea del tráfico.
Más a menudo, los sistemas SASE con estas funciones son pasarelas para el tráfico procedente de sitios y usuarios remotos.
Dado que el cortafuegos se ocupa de todo tipo de protocolos más allá de HTTP y HTTPS con respecto al control de acceso, el proxy inverso y el proxy directo, no son posibles los mecanismos de autenticación de portal bajo demanda.
Hay dos modos utilizados predominantemente para autenticar a los usuarios: autenticación explícita del portal y autenticación de túnel.
En el modo de autenticación explícita del portal, se espera que los usuarios se autentiquen en el portal SASE apuntando el navegador al portal SASE.
El portal SASE, junto con OIDC, autentica a los usuarios.
También en este caso, SASE utiliza el método de mapeo de «IP representativa».
El portal SASE envía el mapeo de dirección IP vs. usuario al cortafuegos tras la autenticación satisfactoria del usuario.
El cortafuegos y las funciones L3/L4 utilizan estos registros de mapeo para asociar las sesiones de tráfico con los usuarios.
El modo de autenticación de túnel requiere un software especial instalado en los dispositivos cliente.
Los clientes realizan sesiones de túnel con SASE de forma proactiva.
Parte de ese túnel se autentica con el SASE.
Si se utilizan túneles basados en IPSec, el componente SASE/IKEv2 se encarga de la autenticación del túnel.
El componente SASE/IKEv2 anuncia el usuario (Initiator ID) y el mapeo de la dirección IP virtual a los servicios de seguridad y red del SASE.
El cortafuegos y las funciones L3/L4 utilizan el método de mapeo ‘IP Representativa’ para mapear las sesiones de tráfico al usuario.
Aunque esos dos modos de autenticación se mencionan explícitamente aquí, el mapeo de dirección IP a usuario puede venir de proxies también, cuando un usuario se autentica a proxies en modos ‘Proxy Inverso’, ‘Proxy Hacia Delante’.
Un punto a tener en cuenta aquí es que se espera que se produzca la autenticación del usuario para que las reglas específicas del usuario sean efectivas.
Si el usuario no se autentica, la lógica de coincidencia de políticas asume que el usuario es desconocido.
Debido a esto, las políticas basadas en el usuario a nivel de cortafuegos y L3/L4 se consideran oportunistas.
Para incentivar/recordar a los usuarios que inicien sesión de forma proactiva, las soluciones SASE tienden a generar notificaciones en el navegador para informar a los usuarios de que inicien sesión en el portal SASE.
SASE e identidad unificadas
El SASE unificado se discutió aquí, y ese post proporcionó varias ventajas que las empresas obtienen de las ofertas de «SASE unificado».
Si el SASE se construye a partir de varios componentes discretos, la autenticación del usuario puede ocurrir varias veces, lo que no es una gran experiencia para el usuario.
Con el «SASE Unificado», se espera que los usuarios se autentiquen una sola vez para todo el SASE.
Esta es una ventaja adicional del ‘SASE Unificado’. Las ofertas de ‘SASE Unificado’ añaden la información del usuario a los mensajes de registro relevantes de forma uniforme y completa a una plataforma de observabilidad común.
Ayuda en diversos análisis y en la detección de anomalías mediante la supervisión del comportamiento del usuario en todos los servicios SDWAN y de seguridad.
Resumen
Se necesita un enfoque de microsegmentación, pero ampliar la microsegmentación para categorizar a varios usuarios no es una solución escalable.
Las soluciones SASE permiten cada vez más la definición y aplicación de políticas basadas en la identidad.
Las soluciones SASE hacen esto autenticando a los usuarios y luego asignando sesiones de tráfico a los usuarios.
Las soluciones SASE proporcionan varias formas para que los usuarios se autentiquen en SASE.
Este post describe algunos de los métodos.
Aryaka inició el viaje del «SASE consciente de la identidad».
La solución Aryaka SWG soporta la aplicación de políticas específicas de usuario.
Obtenga más información sobre la solución SWG de Aryaka aquí: https://www.aryaka.com/secure-web-gateway/
-
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.
