Acceso a aplicações de nube pública (también conocidas como SaaS)… de forma privada
Las ofertas de software como servicio (SaaS) son cada vez más comunes en todos los sectores, ya que las organizaciones buscan formas cada vez más dinámicas y flexibles de aprovechar el software, garantizando al mismo tiempo estabilidad operativa, transparencia de costes, escalabilidad dinámica y agilidad.
Sin embargo, antes de llegar a la aplicação proporcionada por terceros, hay varios componentes que debemos tener en su lugar para permitir que nuestros usuarios obtengan acceso, como: conectividad de red, almacenamiento, computación (en la capa de infraestructura), virtualización, sistema operativo, middleware, tiempo de ejecución y todo lo que se requiere para permitir que la aplicação se ejecute dentro de la capa de servicios. Solo entonces podrá acceder al ámbito de la configuración de RBAC, la gestión de usuarios y la distribución de la aplicação a sus usuarios finales.
También es importante tener en cuenta que, si bien muchas de las capas anteriores están experimentando una consolidación y superposición en la tecnología subyacente dentro de la función, las organizaciones generalmente tienen diferentes equipos con procesos únicos que son dueños de su capa específica. La mayoría de las veces, hay varios equipos operando en cada capa.
Este artículo presenta las ideas e innovaciones que Thad Széll (ingeniero distinguido en UBS) y Nuno Ferreira (director de tecnología de campo en Volterra) tienen para permitir que las organizaciones adopten aplicações SaaS en tiempo real, de forma segura y privada sin comprometer ni contaminar el entorno existente. Su enfoque comenzó con Microsoft Office 365.a
Como todos sabemos, el acceso a las aplicações SaaS generalmente se realiza a través de Internet público y es aquí donde surge el primer conjunto de problemas. El primer problema de infraestructura se deriva del hecho de que antes la aplicação estaba en una infraestructura controlada, principalmente estática, y ahora se va a acceder a ella a través de Internet, que es extremadamente dinámica y no está bajo el control de una entidad específica.
Algunos proveedores de SaaS tienen la capacidad de proporcionar circuitos dedicados (por ejemplo, Azure ofrece ExpressRoute) o VPN para que las organizaciones se conecten a ellos de forma privada. Para adoptar dichos mecanismos, las organizaciones necesitarán al menos:
Interactuar (a nivel de red) con el proveedor de SaaS y mantener relaciones de enrutamiento Inyectar/anunciar las direcciones IP públicas del proveedor de SaaS en la red corporativa Tratar el servicio como una extranet o DMZ y superponer niveles de segmentación y seguridad En los casos en que el proveedor de SaaS solo ofrece un servicio VPN al cliente, se requiere un dispositivo para construir y mantener esta VPN. Tenga en cuenta que estas tecnologías no resuelven el problema de latencia.
Tener un dispositivo NAT/proxy de avance puede resolver algunos problemas de seguridad, pero NO resolverá el problema de enrutamiento y la necesidad de inyectar direcciones IP públicas de terceros en la red corporativa.
Además, los proveedores de SaaS suelen ser extremadamente dinámicos y sus direcciones publicitadas, nombres DNS y puntos finales publicados cambian con mucha regularidad, por lo que es necesario implementar mecanismos operativos para mantener los controles de peering/inyección/publicidad y seguridad.
Por lo tanto, una solución que permita el uso de proxy de reenvío/NAT sin necesidad de enrutamiento es más elegante y necesaria.
Tomemos Office 365 como ejemplo. Microsoft está ampliando su presencia en la nube con Azure y los servicios de aplicação de Microsoft se expanden cada día. Esta plataforma permite a las grandes empresas tener enlaces físicos privados, dedicados y de alta velocidad a Azure llamados ExpressRoute.
Por lo tanto, Microsoft podría abordar los problemas mencionados anteriormente (relacionados con la privacidad y la latencia) al permitir que los empleados de la empresa accedan a Office 365 a través de este circuito privado dedicado de ExpressRoute.
ExpressRoute para Office 365 proporciona una ruta de enrutamiento alternativa a muchos servicios de Office 365 conectados a Internet. La arquitectura de ExpressRoute para Office 365 se basa en la publicidad de los prefijos IP públicos de los servicios de Office 365 que ya son accesibles a través de Internet en sus circuitos ExpressRoute aprovisionados para la posterior redistribución de esos prefijos IP en su red. Con ExpressRoute, habilita de manera efectiva varias rutas de enrutamiento diferentes para los servicios de Office 365: Internet y ExpressRoute. Este estado de enrutamiento en su red puede representar un cambio significativo en cómo está diseñada y protegida la topología de la red interna.
Bueno, quizás no sea tan privado.
La siguiente imagen representa este escenario:
Este enfoque presenta tres desafíos distintos para los equipos de redes y seguridad:
Enrutamiento de red y NAT El equipo de infraestructura de red empresarial deberá inyectar espacio de IP enrutable públicamente en su red corporativa para permitir que los usuarios sigan la ruta preferida (a través de ExpressRoute). Además, para evitar cualquier exposición de la red corporativa a Microsoft, el equipo de red también deberá implementar NAT hacia esta red de Microsoft. Esto no solo genera complejidad operativa para mantener el peering BGP (junto con NAT) con Microsoft, sino que también requiere una planificación cuidadosa para tener en cuenta las complejidades de la red al tener enrutamiento disponible a través de un circuito dedicado con rutas inyectadas en su red principal e Internet. Las direcciones de administración de cambios de seguridad de Office 365 cambian de vez en cuando y, como tal, estos cambios deben reflejarse en la seguridad interna y la infraestructura de proxy de la empresa. Si no se hace esto, puede producirse una pérdida intermitente o total de la conectividad con los servicios de Office 365 cuando el circuito ExpressRoute esté habilitado. Microsoft proporciona un documento completo y actualizado periódicamente (y API REST) que proporciona una lista de dominios, direcciones IP y puertos TCP/UDP que deben configurarse y actualizarse continuamente en los dispositivos de enrutamiento y seguridad empresarial para aplicar las políticas de seguridad y gobernanza corporativas. Visibilidad operativa y de seguridad Hay poca o ninguna visibilidad con los dispositivos NAT en la aplicação. Entonces, ¿cómo abordamos este escenario cuando nada parecía ser lo suficientemente bueno?
Desarrollamos una solución elegante que elimina la necesidad de administrar una infraestructura de red compleja y políticas de seguridad y, al mismo tiempo, brinda a los empleados los beneficios de la conectividad ExpressRoute para acceder a Office 365 y los servicios de aplicação relacionados.
La pila de seguridad y red integrada de Volterra incluye un enrutador de aplicação con proxy programable y capacidades de equilibrio de carga para abordar esta necesidad. Además de estas características, Volterra ofrece una ruta sencilla para que las empresas evolucionen hacia la seguridad de confianza cero.
A un alto nivel, la empresa dispondrá de un cluster Volterra Aplicação Gateway en peering con el enrutador ExpressRoute donde Microsoft presenta las rutas/servicios de Office 365. Volterra Aplicação Gateway realiza el descubrimiento automático de los puntos finales de Office 365 a través de este enrutador, lo que permite a las empresas acceder a los servicios de Office 365 desde allí. Esta innovación permite a los operadores eliminar la necesidad de gestionar otro proceso para traducir la configuración dinámica en reglas en su infraestructura. La innovación de descubrimiento automático de Volterra Gateway permite a los clientes cambiar el destino de sus solicitudes constantemente y la puerta de enlace activará el descubrimiento automático y la integridad TLS para cualquier solicitud entrante.
La segunda parte de la solución es exponer estos servicios a los usuarios corporativos sin anunciar las rutas públicas de Microsoft dentro de la red empresarial. Esto se puede lograr de dos maneras:
El primer método es realizar esto directamente desde el clúster Volterra Aplicação Gateway en Azure a través del circuito ExpressRoute. Tenga en cuenta que la única inyección de IP en la red empresarial será la dirección IP del clúster de Volterra Aplicação Gateway en Azure. A modo de ejemplo, decimos que el gateway está en Azure pero puede estar ubicado en cualquier lugar siempre que se cumplan estas 2 condiciones: a. Los usuarios pueden acceder a la puerta de enlace para enviarle tráfico (o la puerta de enlace lo intercepta) b. La puerta de enlace está conectada a un circuito de ruta rápida donde se ubican/pueden descubrirse los puntos finales de Office 365. El segundo método es agregar uno (o muchos) clústeres de Volterra Aplicação Gateway dentro de las instalaciones corporativas (y centros de datos privados). Luego configuraremos políticas para exponer los servicios de punto final de Office365 detectados en el clúster de Aplicação Gateway local. Estos puntos finales se descubren a través de Volterra Aplicação Gateway, que se encuentra en Azure Cloud (como se explica en la primera parte). Además, el equipo de operaciones empresariales puede configurar políticas de seguridad y autenticación adicionales mientras cifra todo el tráfico. Las siguientes imágenes representan estos escenarios:
El clúster Volterra Aplicação Gateway también implementa funciones de escalamiento automático, lo que significa que cuando un gateway cruza un umbral específico, activará otro y lo agregará al clúster.
Otras características de la solución Volterra que aportan importantes beneficios a los equipos de redes, seguridad y operaciones empresariales son:
Simplicidad operativa con políticas centralizadas y administración basada en SaaS Proxy integrado/unificado, seguridad y enrutamiento con plano de datos programable Visibilidad granular y enriquecida, registro y métricas de uso y acceso a aplicação Al lograr simplicidad y excelencia operativa, creemos que esta solución es la respuesta real para las organizaciones que intentan alcanzar objetivos similares a los de UBS, donde podemos garantizar que el acceso privado a servicios SaaS, como Office 365, se utilice sin la necesidad de hacer que su red corporativa "esté disponible para, o incluso sea parte de, las redes públicas".