Proteger las cargas de trabajo en entornos multinube con Zscaler Zero Trust Exchange

La nube se ha convertido en el nuevo centro de datos para la mayoría de las empresas y los entornos multinube son cada vez más habituales. Las cargas de trabajo en la nube tienen que comunicarse entre sí y con Internet de forma segura. Desafortunadamente, las opciones disponibles para desarrollar una conectividad segura de nube a nube y de nube a Internet utilizando cortafuegos y VPN para extender la WAN corporativa a la nube crean riesgos de seguridad, complejidad operativa y problemas de rendimiento.

Retos de la ampliación de la WAN corporativa a la nube

Tradicionalmente, dos entornos diferentes se conectan mediante enrutadores. Como estos enrutadores se utilizan para terminar túneles VPN o IPSec e intercambiar rutas, cada uno de estos entornos tiene acceso a todas las direcciones IP de los otros entornos. Para controlar el acceso entre estos entornos, se utilizan cortafuegos a fin de proporcionar un control de acceso estático que garantice que solo determinadas IP de un entorno tengan acceso a determinadas IP de otros entornos. Este es el enfoque heredado de IP y cortafuegos que la mayoría de las empresas no han tenido más remedio que adoptar. 

 

El enfoque IP y cortafuegos crea riesgos de seguridad porque la conectividad IP plana de malla completa hace que las redes sean susceptibles al movimiento lateral de las amenazas.

Este enfoque también crea complejidad operativa con cargas de trabajo efímeras en la nube. Cuando las IP vienen y van, es necesario que los enrutadores propaguen las nuevas IP. Cualquier nueva IP necesita ser programada en el cortafuegos y, si se produce un solapamiento en estas IP, debe ser resuelto antes de que pueda conectarse a estas redes.

Por último, este enfoque presenta desafíos de escala y rendimiento, como escalado de rutas, cuellos de botella de rendimiento y mayor latencia.

Estos desafíos se hacen cada vez más desalentadores a medida que más aplicaciones se distribuyen en múltiples nubes y con la adopción de servicios nativos de la nube como contenedores, PaaS y sin servidor.

Con un enfoque heredado, todo el tráfico vinculado a Internet u otras cargas de trabajo en una nube diferente tiene que pasar por un centro centralizado. Este centro tiene cortafuegos, proxies Squid, enrutadores, etc., como los de una arquitectura de castillo y foso en un centro de datos. Entre las limitaciones se incluyen:

 

 

1. Posición de seguridad limitada:

Para tener una posición de seguridad completa, se requieren capacidades adicionales, como proxy y protección de datos, ya que la inspección SSL a escala no es posible con los cortafuegos virtuales. Esto da como resultado dispositivos virtuales adicionales para proxies Squid, sandboxing, etc.

2. Riesgos de las redes de malla completa:

Para permitir la comunicación de la carga de trabajo a través de un entorno multinube, la arquitectura IP heredada distribuye las rutas y comparte la información de IP y subred a través de diferentes entornos. Se crean así redes planas y reglas de cortafuegos estáticas que son fáciles de evadir, lo que puede conducir a un movimiento lateral de amenazas.

3. Limitación de rendimiento de los dispositivos:

El rendimiento está limitado por el vínculo más débil: en este caso, la escala y el rendimiento del cortafuegos. Cuantos más servicios de seguridad se habiliten en los cortafuegos, como la inspección SSL de contenidos, más lento será el rendimiento.

4. Sobrecarga de orquestación y gestión:

Los cortafuegos heredados requieren máquinas virtuales adicionales para la orquestación, la política, las operaciones y la gestión de licencias, lo que añade otra capa de complejidad y coste. Replicar esto para cada proveedor de nube añade una carga adicional para las operaciones en múltiples nubes.

5. Puntos ciegos debido a los múltiples saltos a un destino:

Los enfoques heredados basados en IP necesitan varias herramientas, como cortafuegos, enrutadores SD-WAN, NACL y grupos de seguridad. Cada uno de ellos requiere su propio registro y la correlación inadecuada del registro crea puntos ciegos adicionales para los equipos de redes y seguridad.

Ampliar la confianza cero a las cargas de trabajo en la nube

Afortunadamente, ya hemos visto el desafío que supone la WAN corporativa para el acceso de los empleados en los últimos años. Para superar las deficiencias de seguridad y rendimiento del enfoque de IP y cortafuegos, un porcentaje cada vez mayor de empresas ha adoptado una estrategia de confianza cero. Esos mismos principios de confianza cero, reinventados para las necesidades específicas de las cargas de trabajo en la nube, son el camino a seguir para las redes de nube múltiple.

Con la confianza cero, nunca se confía en las redes, por lo que nunca se intercambia información de IP y de enrutamiento. La conectividad se habilita a un nivel granular para las cargas de trabajo en función de la identidad y el contexto, por lo que no es necesario crear reglas de cortafuegos estáticas para restringir el acceso IP entre los entornos.

 

Zscaler Internet Access (ZIA) y Zscaler Private Access (ZPA) son los líderes del mercado en proteger el acceso de los usuarios finales a Internet y a las aplicaciones privadas. Zscaler Workload Communications, habilitada por Cloud Connector, amplía estas soluciones para proteger el acceso a la carga de trabajo en Internet (ZIA para cargas de trabajo) y proteger el acceso privado a cargas de trabajo privadas remotas (con ZPA para cargas de trabajo). Este nuevo e innovador enfoque mejora la seguridad, reduce la complejidad operativa y mejora el rendimiento de las aplicaciones, todo ello al mismo tiempo.

 

Caso de uso 1: Permitir la confianza cero para la comunicación entre cargas de trabajo e Internet

Cloud Connector permite que las cargas de trabajo se conecten directamente a la nube de Zscaler para el acceso a Internet. Todos los servicios de seguridad, como el proxy SSL, la protección de datos y la protección contra amenazas avanzadas, se ejecutan de forma nativa en Zero Trust Exchange. Con esta arquitectura, puede aplicar la misma política de seguridad para todas las cargas de trabajo que accedan a Internet desde cualquier nube. Esto contrasta con las arquitecturas heredadas, donde es necesario desarrollar una arquitectura de castillo y foso con cortafuegos y proxies Squid en todas las nubes.

 

Caso de uso 2: Habilitar la confianza cero para la comunicación entre cargas de trabajo en un entorno multinube

Cloud Connector permite que las cargas de trabajo se conecten directamente a la nube de Zscaler. Las cargas de trabajo de cualquier nube (AWS, Azure, centro de datos) pueden comunicarse entre sí a través de Zero Trust Exchange. Zero Trust Exchange utiliza la identidad y el contexto para verificar la confianza y establecer la conexión. Esto contrasta con las arquitecturas heredadas, donde se requiere enrutamiento de IP entre estos entornos en la nube.

 

Caso de uso 3: Permitir la confianza cero para la comunicación de carga de trabajo a carga dentro de un VPC/VNET

Zscaler Workload Segmentation lleva la segmentación a un nivel granular, dentro de una máquina virtual a nivel de aplicación o proceso individual. Un agente de segmentación de carga de trabajo ofrece identidad de software generando huellas digitales a nivel de proceso. El aprendizaje automático descubre todas las rutas disponibles hacia un proceso o aplicación en particular y propone una recomendación sobre las rutas permitidas, eliminando todas las rutas innecesarias que aumentan el riesgo de movimiento lateral de amenazas. Esto contrasta con las arquitecturas heredadas, en las que se utilizan ACL (listas de control de acceso) y SG (grupos de seguridad) estáticos, que un atacante puede evadir fácilmente aprovechando una regla existente.

Cómo la confianza cero resuelve las limitaciones de IP y cortafuegos         

 

 

Cuando exploramos arquitecturas heredadas, el problema subyacente común es la conectividad IP. Tradicionalmente, las redes y la seguridad se consideran funcionalidades separadas. La conectividad (enrutamiento IP) se activa primero y, posteriormente, se activa la seguridad (filtrado de cortafuegos). Algunos proveedores han integrado ambas cosas en un solo dispositivo, pero el enfoque y la arquitectura son los mismos.

Zero Trust Exchange de Zscaler adopta un enfoque único y diferente: la seguridad primero y la conectividad después. ¿Por qué crear conectividad innecesaria que necesitará bloquear más tarde?

En el enfoque de confianza cero de Zscaler, no confiamos en nadie. La única conectividad por defecto para el origen es Zero Trust Exchange, no la aplicación de destino. Todo el tráfico de la carga de trabajo se reenvía a Cloud Connector, que a su vez conecta estas cargas de trabajo a Zero Trust Exchange.

Zero Trust Exchange sigue los siguientes pasos antes de que el origen y el destino se conecten: