Las ofertas de software como servicio (SaaS) están cada vez más extendidas en todos los sectores, ya que las organizaciones buscan formas más dinámicas y flexibles de aprovechar el software, al tiempo que garantizan la estabilidad operativa, la transparencia de costes, la escalabilidad dinámica y la agilidad.
Sin embargo, antes de llegar a la aplicación proporcionada por un tercero, debemos contar con varios componentes para que nuestros usuarios puedan acceder a ella, como conectividad de red, almacenamiento, recursos informáticos (en la capa de infraestructura), virtualización, sistema operativo, middleware, entorno de ejecución y todo lo necesario para que la aplicación funcione dentro de la capa de servicios. Solo entonces se pasa a la configuración del control de acceso basado en roles (RBAC), la gestión de usuarios y la distribución de la aplicación a los usuarios finales.
También es importante señalar que, aunque en muchas de las capas anteriores se está produciendo una consolidación y un solapamiento de la tecnología subyacente dentro de la función, las organizaciones suelen contar con distintos equipos, cada uno con procesos propios, que se encargan de su capa específica. En la mayoría de los casos, hay varios equipos operando en cada capa.
Este artículo expone las ideas e innovaciones de Thad Széll (ingeniero distinguido de UBS) y Nuno Ferreira (CTO de campo de Volterra) para permitir que las organizaciones adopten aplicaciones SaaS en tiempo real, de forma segura y privada, sin poner en riesgo ni contaminar el entorno existente. Su trabajo comenzó centrándose en Microsoft Office 365.a
Como todos sabemos, a las aplicaciones SaaS se suele acceder a través de la Internet pública, y es aquí donde surge el primer conjunto de problemas. El primer problema de infraestructura se deriva del hecho de que, anteriormente, la aplicación se encontraba en una infraestructura controlada y principalmente estática, mientras que ahora se accederá a ella a través de Internet, un entorno extremadamente dinámico que no está bajo el control de una única entidad.
Algunos proveedores de SaaS pueden ofrecer circuitos dedicados (por ejemplo, Azure ofrece ExpressRoute) o VPN para que las organizaciones se conecten a ellos de forma privada. Para adoptar estos mecanismos, las organizaciones deberán, como mínimo:
Establecer una conexión entre pares (a nivel de red) con el proveedor de SaaS y mantener las 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 distintos niveles de segmentación y seguridad. En los casos en que el proveedor de SaaS solo ofrezca al cliente un servicio VPN, se necesitará un dispositivo para crear y mantener esta VPN. Tenga en cuenta que estas tecnologías no resuelven el problema de la latencia.
Disponer de un dispositivo de proxy directo/NAT puede resolver algunos problemas de seguridad, pero NO resolverá el problema de enrutamiento ni la necesidad de incorporar direcciones IP públicas de terceros a la red corporativa.
Además, los proveedores de SaaS suelen ser extremadamente dinámicos, y las direcciones que anuncian, los nombres DNS y los puntos de conexión publicados cambian con mucha frecuencia. Por tanto, es necesario disponer de mecanismos operativos para mantener el emparejamiento, la inyección y el anuncio de rutas, así como los controles de seguridad.
Por lo tanto, una solución que permita usar un proxy directo o NAT sin necesidad de enrutamiento resulta más elegante y necesaria.
Tomemos Office 365 como ejemplo. Microsoft está ampliando su presencia en la nube con Azure, y los servicios de aplicaciones de Microsoft crecen cada día. Esta plataforma permite a las grandes empresas disponer de conexiones físicas privadas, dedicadas y de alta velocidad con Azure, denominadas ExpressRoute.
Por tanto, Microsoft podría resolver los problemas mencionados anteriormente (relacionados con la privacidad y la latencia) permitiendo que los empleados de las empresas 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 accesibles desde Internet. La arquitectura de ExpressRoute para Office 365 se basa en anunciar los prefijos de IP públicas de los servicios de Office 365 que ya son accesibles a través de Internet en los circuitos de ExpressRoute aprovisionados, para posteriormente redistribuir dichos prefijos de IP en su red. Con ExpressRoute, se habilitan de forma efectiva varias rutas de enrutamiento diferentes para los servicios de Office 365: Internet y ExpressRoute. Este estado del enrutamiento en su red puede suponer un cambio significativo en la forma en que se diseña y protege la topología de su red interna.
Vale, así que quizá no sea tan privado.
La siguiente imagen representa este escenario:
Este enfoque plantea tres retos distintos para los equipos de redes y seguridad:
Enrutamiento de red y NAT. El equipo de infraestructura de red de la empresa deberá incorporar espacio de direcciones IP públicas enrutables a su red corporativa para que los usuarios puedan seguir la ruta preferente (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 añade la complejidad operativa de mantener el emparejamiento BGP (junto con NAT) con Microsoft, sino que también exige una planificación minuciosa para abordar la complejidad de disponer de enrutamiento tanto a través de un circuito dedicado, con rutas incorporadas a la red troncal, como a través de Internet. Gestión de cambios de seguridad. Las direcciones de Office 365 cambian periódicamente, por lo que estos cambios deben reflejarse en la infraestructura interna de seguridad y proxy de la empresa. No hacerlo puede provocar una pérdida intermitente o total de conectividad con los servicios de Office 365 cuando se habilita el circuito de ExpressRoute. Microsoft proporciona un documento completo y actualizado periódicamente (así como una API REST) que incluye una lista de dominios, direcciones IP y puertos TCP/UDP que deben configurarse y actualizarse continuamente en los dispositivos de seguridad y enrutamiento de la empresa para aplicar las políticas corporativas de seguridad y gobernanza. Visibilidad operativa y de seguridad. Los dispositivos NAT ofrecen poca o ninguna visibilidad de la aplicación. Entonces, ¿cómo abordamos esta situación cuando ninguna opción parecía ser lo bastante buena?
Ideamos una solución elegante que elimina la necesidad de gestionar políticas de seguridad e infraestructuras de red complejas, al tiempo que permite a los empleados disfrutar de las ventajas de la conectividad de ExpressRoute para acceder a Office 365 y a los servicios de aplicaciones relacionados.
La pila integrada de red y seguridad de Volterra incluye un router de aplicaciones con funciones programables de proxy y equilibrio de carga para satisfacer esta necesidad. Además de estas funciones, Volterra ofrece a las empresas una vía sencilla para avanzar hacia un modelo de seguridad de confianza cero.
A grandes rasgos, la empresa dispondrá de un clúster de Volterra Application Gateway conectado mediante peering al router de ExpressRoute en el que Microsoft publica las rutas y los servicios de Office 365. Volterra Application Gateway detecta automáticamente los puntos de conexión de Office 365 a través de este router, lo que permite a las empresas acceder desde allí a los servicios de Office 365. Esta innovación evita que los operadores tengan que gestionar otro proceso adicional para convertir la configuración dinámica en reglas aplicables a su infraestructura. La función de detección automática de Volterra Gateway permite a los clientes cambiar constantemente el destino de sus solicitudes, y la puerta de enlace activará la detección automática y garantizará la integridad TLS de cualquier solicitud entrante.
La segunda parte de la solución consiste en poner estos servicios a disposición de los usuarios corporativos sin anunciar las rutas públicas de Microsoft dentro de la red empresarial. Esto puede lograrse de dos maneras:
El primer método consiste en hacerlo directamente desde el clúster de Volterra Application Gateway en Azure a través del circuito ExpressRoute. Tenga en cuenta que la única IP que se anunciará en la red empresarial será la dirección IP del clúster de Volterra Application Gateway en Azure. A efectos ilustrativos, indicamos que la puerta de enlace se encuentra en Azure, pero puede estar ubicada en cualquier lugar siempre que se cumplan estas dos 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 ExpressRoute en el que los puntos de conexión de Office 365 están disponibles o pueden detectarse. El segundo método consiste en añadir uno o varios clústeres de Volterra Application Gateway en las instalaciones corporativas (y en centros de datos privados). A continuación, configuraremos políticas para exponer en el clúster local de Application Gateway los servicios de puntos de conexión de Office 365 detectados. Estos puntos de conexión se detectan mediante el Volterra Application Gateway ubicado en la nube de Azure (como se explica en la primera parte). Además, el equipo de operaciones de la empresa puede configurar políticas adicionales de seguridad y autenticación, a la vez que cifra todo el tráfico. Las siguientes imágenes representan estos escenarios:
El clúster de Volterra Application Gateway también incorpora funciones de escalado automático, lo que significa que, cuando una puerta de enlace supera un umbral específico, se inicia otra y se añade al clúster.
Otras características de la solución Volterra que aportan importantes ventajas a los equipos de redes, seguridad y operaciones de la empresa son:
Simplicidad operativa gracias a la gestión centralizada de políticas y a la administración basada en SaaS. Proxy, seguridad y enrutamiento integrados y unificados mediante un plano de datos programable. Visibilidad granular y completa, registros y métricas sobre el uso de las aplicaciones y el acceso a ellas. Al ofrecer simplicidad y excelencia operativa, creemos que esta solución es la verdadera respuesta para las organizaciones que intentan alcanzar objetivos similares a los de UBS, ya que permite garantizar el acceso privado a servicios SaaS, como Office 365, sin necesidad de hacer que su red corporativa «esté disponible para las redes públicas o incluso forme parte de ellas».
Sobre el autor
Artículos relacionados del blog
Cree servicios públicos seguros, resilientes y preparados para la IA con F5 y AWS
Descubre cómo las organizaciones del sector público pueden modernizar de forma segura sus aplicaciones y soluciones de IA, al tiempo que gestionan los sistemas heredados, el cumplimiento normativo y el riesgo operativo.
Protección de los sistemas de IA: por qué la seguridad debe avanzar al ritmo de la innovación
Desde acelerar avances revolucionarios en medicina y educación hasta transformar la vida cotidiana, la IA está cambiando nuestra forma de vivir y trabajar. Pero también ofrece grandes oportunidades a los ciberdelincuentes.
Avanzar hacia la optimización digital tras la transformación
Descubre estrategias de optimización digital para garantizar políticas de seguridad coherentes, impulsar la madurez de la transformación digital y superar los retos de la transformación.
Proyecto de código abierto destacado: mayor observabilidad con F5 Cloud Logger iApp
En el punto de mira del código abierto: cómo aumentar la observabilidad. Lee el blog de F5 para descubrir cómo exportar fácilmente la telemetría de BIG-IP a plataformas modernas de análisis en la nube.
El estado de la entrega de aplicaciones en 2018: la transformación digital impulsa la automatización y la multinube pese a las preocupaciones de seguridad
Descubre las principales conclusiones del cuarto informe anual de F5 sobre el estado de la entrega de aplicaciones.
Estado de la entrega de aplicaciones en 2017: automatización, API y DevOps
Descubre el informe sobre el estado de la entrega de aplicaciones de 2017. Lee el blog retrospectivo de F5 sobre los inicios del auge de las redes declarativas y los flujos de DevOps.