¿Por qué apoderados en SASE?
Atrás quedaron los días en los que la seguridad a nivel de paquetes se consideraba suficiente.
Debido a la sofisticación de los ataques, se está haciendo imperativo realizar una inspección profunda del contenido para diversos tipos de protección.
El acceso consciente de la identidad es un requisito clave debido al personal distribuido y a las aplicaciones distribuidas.
Esta entrada del blog profundiza en los requisitos relacionados con el acceso consciente de la identidad en detalle.
La inspección profunda de contenidos y el acceso consciente de la identidad a nivel de API/aplicación-recurso requieren la terminación de las conexiones de los clientes, la inspección de contenidos para la detección de amenazas y el control de acceso y el origen de las conexiones a través de proxies.
De ahí que muchas soluciones SASE implementen la seguridad a través de proxies.
Tipos de proxy
Es posible que haya oído hablar de varios tipos de proxies: Forward, Reverse y Transparent.
La funcionalidad principal de todos los tipos de proxies es la misma.
La funcionalidad de alto nivel se enumera aquí.
- Apoderarse del tráfico
- Finalice las conexiones de los clientes.
- Autenticar a los clientes.
- Obtener la identidad del usuario.
- Originar conexiones hacia los servidores.
- Descifrado y cifrado TLS
- Compruebe la reputación de la IP y del dominio.
- Realice controles de acceso basados en la identidad.
- Realice funciones CASB.
- Compruebe si hay pérdidas de datos y evítelas.
- Realice la función de detección/prevención de intrusiones.
- Realice la función de cortafuegos de aplicaciones web.
- Busque indicadores de malware y exploits en el tráfico y actúe.
Las diferencias entre unos y otros se basan en los siguientes factores:
- Obtención de tráfico para la inspección de amenazas y el control de acceso
- Autenticación e identificación de los usuarios
Transparente Tipo de proxy
En este tipo, los clientes y los servidores no saben de la presencia de proxies.
Estos proxies captan el tráfico de los enrutadores de la red por los que pasa el tráfico.
Es responsabilidad de los administradores de red asegurarse de que el tráfico de los usuarios de oficina y el tráfico de los usuarios WFH se dirige a través de las entidades de enrutamiento de la empresa.
Para garantizar que el tráfico de los usuarios del WFH pasa por los enrutadores de la empresa, es una práctica normal aprovechar los clientes VPN para conectarse a las redes de la empresa.
En el caso de SD-WAN, los túneles VPN terminan en concentradores VPN en la ubicación PoP más cercana.
La autenticación de usuarios y la correspondiente identificación de usuarios se produce a través de
- Portal explícito
- Portal a la carta
- Establecimiento del túnel VPN
- Certificado de cliente TLS
En caso de «Portal explícito», los usuarios se registran proactivamente en el portal.
El servicio del portal autentica al usuario con la ayuda de los sistemas de autenticación de la empresa.
Una vez validadas con éxito las credenciales del usuario, anota la dirección IP del usuario (a partir de la IP de origen de la conexión) e informa a los proxies de la identificación del usuario y de la información de mapeo de la dirección IP.
Una vez que el proxy conoce estos mapeos, el proxy identifica al usuario a partir de la dirección IP del tráfico y realiza la aplicación de la política consciente de la identidad.
Si el usuario inicia la sesión sin autenticarse proactivamente con el portal, entonces el proxy puede redirigir al usuario al portal.
Dado que el acceso al portal es bajo demanda, este método de autenticación también se denomina autenticación de portal bajo demanda.
Una cosa a tener en cuenta es que la redirección del usuario al portal sólo es posible si la conexión está basada en HTTP/HTTPS.
En caso de HTTPS, la redirección sólo es posible tras el descifrado TLS.
En caso de acceso a servicios/sitios no pertenecientes a la empresa, es necesario mimetizar el certificado del servidor con el certificado CA propiedad de la empresa.
Además, si el usuario no es humano y utiliza el navegador, la redirección no sirve de nada.
Incluso con estas advertencias, sigue siendo una forma poderosa para que el proxy consiga autenticar e identificar al usuario.
Como se ha comentado brevemente, para formar parte de las redes empresariales, los usuarios WFH (Work From Home) necesitan conectarse a las redes empresariales a través de un túnel VPN.
El establecimiento del túnel VPN ya realiza la autenticación del usuario.
Los concentradores VPN asignan una dirección IP privada única a cada cliente.
Los clientes pueden configurarse para utilizar el túnel VPN y, por tanto, esta dirección IP como origen para la mayoría de las conexiones (incluida la deshabilitación del túnel dividido).
Los concentradores VPN tienen la capacidad de anunciar la dirección IP asignada al cliente, el mapeo de ID de usuario (ID de iniciador) a partes externas.
Los proxies utilizan este mapeo para identificar las sesiones a un usuario en un momento posterior cuando los clientes inician sesiones.
Si la sesión TLS establecida programas cliente tiene certificado de cliente TLS, se puede utilizar para autenticar e identificar al usuario.
Esto se utiliza muy raramente hoy en día en SASE, pero es una de las opciones disponibles.
Una ventaja importante del tipo de proxy transparente es que puede capturar todo el tráfico de protocolos, no sólo HTTP/HTTPS.
Otro beneficio importante es que no hay ninguna configuración especial en las máquinas cliente o servidor de la empresa.
Hay pocos inconvenientes con este tipo de proxies.
Dado que identifica al usuario basándose en la dirección IP observada en el tráfico, todas las aplicaciones de esa máquina usuaria reciben el mismo tratamiento de seguridad.
Si se trata de una máquina multiusuario, todos los usuarios de esa máquina obtienen el mismo tratamiento/privilegio de seguridad.
Si esta dirección IP está NATando múltiples máquinas, entonces todas las máquinas detrás de esa dirección IP NAT obtienen el mismo acceso y tratamiento de seguridad.
Piense en un caso en el que el portátil del usuario está infectado con malware.
El malware obtiene el mismo acceso que el definido para ese usuario, ya que el malware forma parte de la misma máquina desde la que el usuario se conecta al portal.
Debido a esto, los tipos de proxy transparentes deben utilizarse con cuidado, al menos para las sesiones HTTP/HTTPS. Otro inconveniente es que este tipo de proxies requiere que el cliente VPN esté presente en los dispositivos.
Aunque no es un problema para los dispositivos gestionados, puede ser un reto convencer a los empleados de que instalen el cliente VPN en los dispositivos propiedad de los empleados.
Tipo de proxy de reenvío
Los proxies de reenvío están pensados para dispositivos cliente que se comunican con servicios/sitios externos.
Las aplicaciones cliente se configuran para que pasen por el proxy de reenvío para comunicarse con servicios externos.
Las aplicaciones cliente se configuran con el FQDN/IP del proxy y el puerto en el que escuchan los proxies.
En caso de proxy transparente, la dirección IP de origen y destino de la sesión nunca tiene la dirección IP del proxy.
En caso de proxy reenviado, las conexiones desde el cliente son a la dirección IP del proxy y la conexión al servidor sería desde la dirección IP del proxy.
Los archivos PAC se utilizan para configurar las aplicaciones cliente, como los navegadores, con los ajustes del proxy.
El archivo PAC permite seleccionar el enrutamiento del tráfico a varios proxies en función de los dominios de servicio de destino.
Los archivos PAC se distribuyen a los navegadores cliente a través de soluciones de gestión del sistema o mediante el servicio WPAD (Web Proxy Auto Discovery).
Las aplicaciones cliente con la configuración de proxy siempre se comunican con el proxy.
Así es como, los proxies de reenvío capturan el tráfico.
En el caso de conexiones TLS como HTTPS, cada conexión TCP comienza con la transacción «HTTP CONNECT».
Esta transacción se realiza únicamente entre el cliente y el proxy.
Después de esa transacción «HTTP CONNECT», los datos entre el cliente y el servidor son mediados por el proxy.
La transacción «HTTP CONNECT» tiene un campo de cabecera host cuyo valor utiliza el proxy para determinar el FQDN y el puerto de destino final.
En el caso de HTTP2.0, toda conexión de flujo comienza con la transacción «HTTP CONNECT».
Como habrá observado, no es necesario que el tráfico se envíe a los enrutadores de la empresa para que el proxy capte el tráfico.
Es decir, el tráfico va directamente al proxy.
De este modo, es agnóstico con respecto a la red.
Los proxies de reenvío también pueden autenticar e identificar a los usuarios a través de las cabeceras proxy-autenticación y proxy-autorización.
En el caso de las conexiones TLS, estas cabeceras se envían en respuesta y solicitud respectivamente en las transacciones HTTP CONNECT.
Un punto a tener en cuenta es que no hay necesidad de descifrar las conexiones TLS a efectos de autenticar e identificar al usuario.
No es necesaria la autenticación del portal.
Hay una ventaja añadida y es que muchos navegadores y aplicaciones cliente soportan Kerberos como parte de la autenticación proxy.
Con ello, cualquier usuario que inicie sesión en el dispositivo de uno puede autenticarse automáticamente con el proxy sin ventanas emergentes de inicio de sesión adicionales (también conocido como SSO).
El uso de proxy de tipo forward para clientes que se comunican con servicios externos tiene varias ventajas.
Algunas de ellas se enumeran a continuación.
- La autenticación e identificación del usuario es determinista.
En el caso del tipo de proxy transparente, si el usuario se olvida de autenticarse proactivamente en el portal, la redirección al portal bajo demanda o al portal cautivo para la autenticación del usuario sólo es posible tras el descifrado TLS.
Algunas empresas no permiten el descifrado TLS a los sitios que recopilan IIP.
Si los sitios adoptan el pineado de certificados, no se espera que los proxies transparentes imiten el certificado y, por lo tanto, el descifrado TLS no es posible.
En estos casos, no se puede determinar el usuario para proporcionar una aplicación de políticas consciente de la identidad.
En el tipo de proxy directo, como la fase de autenticación del proxy se produce antes de cualquier intercambio TLS, la autenticación e identificación del usuario es determinista. - Como ya se ha comentado, el proxy de reenvío es agnóstico a la red y puede funcionar con cualquier red siempre que las aplicaciones cliente estén configuradas con ajustes de proxy.
No es necesario que haya un cliente VPN en los dispositivos aunque los usuarios trabajen desde casa. - Dado que muchas aplicaciones cliente admiten Kerberos, el usuario obtiene una experiencia SSO.
- El protocolo Encrypted Client Hello (ECH) en TLS 1.3+ está ganando adeptos en la industria.
Cuando se adopta ECH, el SNI no es visible y, por tanto, el tipo de proxy transparente no podrá realizar ni siquiera el filtrado básico de URL y el control de acceso.
En el tipo proxy de reenvío, debido a la transacción HTTP CONNECT, el proxy conoce el FQDN de destino aunque se adopte ECH.
Es decir, el tipo de proxy de reenvío es seguro para ECH. - No hay listas blancas de IP.
Cada aplicación cliente debe autenticarse por separado con el proxy y, por tanto, es muy segura.
También tiene algunos inconvenientes.
Sólo funciona para el tráfico HTTP/HTTPS.
Aunque la mayoría de las aplicaciones cliente admiten la configuración del proxy, algunas no lo hacen.
Tipo de proxy inverso
Los proxies inversos se utilizan para aplicaciones de servidor frontales.
Los proxies inversos se utilizan para proteger los servicios de las amenazas, para proporcionar RBAC, para terminar las sesiones TLS y también para equilibrar la carga de las sesiones de tráfico entre múltiples instancias de servicios.
El proxy inverso captura el tráfico a través de métodos DNS.
El FQDN de cada servicio de la empresa que se expone a los empleados o a los usuarios públicos se configura en los servidores DNS de la empresa para que apunte a las direcciones IP de las instancias del proxy inverso.
Debido a esto, cada vez que cualquier usuario intenta conectarse a los servicios de la empresa, el tráfico correspondiente aterriza en los proxies inversos.
Los proxies inversos también terminan las sesiones HTTPS/HTTP.
Como parte de este proceso, también autentican a los usuarios y luego identifican a los usuarios de las sesiones mediante métodos OIDC, SAMLv2 y SPENGO/Kerberos.
En el caso de la comunicación App-to-App, los usuarios también se identifican a partir de los certificados TLS.
SASE Apoderado
Si desea una introducción sobre SASE, lea la entrada del blog Descifrando SASE.
Como habrá observado, se espera que las soluciones SASE proporcionen una seguridad integral: seguridad para los clientes, seguridad para los datos SaaS y seguridad para las aplicaciones empresariales.
Como se describe en la entrada del blog Identity-aware-SASE, los controles de acceso basados en la identidad son la característica clave de SASE.
Aunque muchas empresas pueden vivir sólo con el acceso HTTP/HTTPS, algunas pueden necesitar también controles de acceso en otros protocolos.
Debido a estas necesidades, creemos que el proxy SASE deberá actuar como transparente para el tráfico no HTTP y para las aplicaciones cliente que no soporten configuraciones de proxy.
El proxy SASE actuará como proxy de reenvío para las aplicaciones cliente que accedan a Internet y a servicios SaaS para proporcionar un control de acceso determinista basado en la identidad y también como prueba de futuro cuando se adopte ECH.
El proxy SASE también actuará como proxy inverso para proteger las aplicaciones empresariales.
Esta convergencia de múltiples tipos de proxy es necesaria para el éxito de la solución SASE.
-
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.
