El “hairpinning”: El pequeño y sucio secreto de la mayoría de los proveedores de seguridad en la nube

Artículo escrito conjuntamente por Jeff Brainard y Jason Hofmann

En más de una conversación con clientes de grandes empresas, hemos escuchado a los directores de redes e infraestructuras responsables de gestionar la WAN global de la organización referirse en broma a sí mismos como el "Chief Hairpinning Officer" o CHO. A priori, parece gracioso. Sin embargo, hay algo de verdad en esta afirmación si se tiene en cuenta que gran parte del tiempo, la energía y el presupuesto de los profesionales de las redes se ha dedicado tradicionalmente a gestionar complejas decisiones de enrutamiento de la red. Estas decisiones eran clave para unir las diferentes sedes y sucursales de la empresa con el centro de datos, al mismo tiempo que tenían que trabajar con múltiples proveedores de servicios de Internet para garantizar un acceso rápido y fiable para sus usuarios y una experiencia de aplicación expeditiva. En los últimos años, el problema ha sido alinear estos objetivos de red con los crecientes requisitos de seguridad a los que se enfrentan las empresas. El problema no ha hecho más que empeorar con la migración de las aplicaciones y los datos a la nube y a servicios SaaS, los ataques cada vez más complejos y la reciente explosión del teletrabajo. 

La mayoría de las empresas utilizan hoy en día una arquitectura que depende en gran medida del "hairpinning" o lo que también se conoce comúnmente como retorno del tráfico. El hairpinning, en un contexto de red, es el método en el que un paquete viaja a una interfaz, sale hacia Internet pero, en lugar de continuar, hace un "giro de horquilla" (horquilla en inglés es “hairpin”)—sólo hay que pensar en el instrumento cotidiano utilizado para sujetar el pelo de una person—y vuelve a entrar en la misma interfaz. El escenario clásico es el de la sucursal, donde ningún tráfico debe entrar o salir sin que se compruebe primero la seguridad. Desplegar una pila de seguridad independiente en cada sucursal, en docenas o incluso cientos de sucursales de todo el mundo, podría ser una estrategia viable, pero desde el punto de vista del costo, la complejidad y la carga administrativa, sería una pesadilla. 

En su lugar, la estrategia preferida ha sido hacer que todas las solicitudes de los clientes para acceder a Internet se envíen (o se envíen de vuelta) desde la sucursal a una ubicación central, como el centro de datos, donde se aplica la seguridad, y sólo entonces—después de ser escaneado—el tráfico sale a Internet. Lo mismo ocurre si se hace una solicitud de contenido web o se interactúa con una aplicación SaaS crítica para el negocio. En la respuesta del servidor, el tráfico debe seguir el mismo camino de vuelta a través del centro de datos, a la sucursal y, finalmente, al escritorio del usuario. No hace falta ser un ingeniero de redes para darse cuenta de que este enfoque va a afectar a la experiencia del usuario, añadiendo latencia y ralentizando las cosas de forma significativa. Dejando a un lado la experiencia del usuario y, en última instancia, la productividad de la empresa, este enfoque también supone una mayor carga para los enlaces WAN privados, caros y difíciles de mantener, como las conexiones MPLS, en los que las empresas han confiado durante mucho tiempo para unir su empresa distribuida.

Con el indiscutible desplazamiento de las aplicaciones y los datos a la nube, y el creciente volumen y criticidad de este tráfico, uno de los grandes atractivos del modelo de seguridad en la nube es la eliminación del hairpinning o tráfico de retorno y la simplificación drástica del diseño de la red. También es uno de los principales impulsores del floreciente mercado de las SD-WAN y del impulso de los proyectos de transformación de redes a gran escala. Esto se trató en otro artículo de blog reciente titulado "Cómo Netskope NewEdge lleva las SD-WAN al siguiente nivel." La conclusión a la que se puede llegar es que los profesionales de las redes prefieren evitar el hairpinning y que el futuro consistirá cada vez más en enviar su tráfico directamente a la red con un enfoque de la seguridad centrado prioritariamente en la nube. Entonces, ¿por qué elegiría un cliente una solución de seguridad en la nube que se basa en una arquitectura de hairpinning?

Por desgracia, una de las cosas que hemos visto repetidamente en el mercado, y que es habitual en casi todos los proveedores de seguridad en la nube, es que han diseñado mal sus nubes. Básicamente, lo que se encuentra es que están repitiendo los errores inherentes al diseño de la WAN empresarial tradicional y replicándolos dentro de un factor de forma en la nube. El ejemplo clásico de esto es el punto de presencia virtual (o vPOP), un enfoque públicamente conocido por ser utilizado por proveedores como Broadcom/Symantec, Palo Alto, Forcepoint, McAfee y otros. (Si no se fía de mí, sólo tiene que consultar sus sitios web y buscar frases como "Ubicación física del procesamiento de la seguridad" o el término "vPOP".) Los vPOP no sólo proporcionan una visión engañosa de la cobertura, sino que también engañan sobre dónde se produce el procesamiento del tráfico dentro de la red del proveedor de seguridad en la nube. 

En el nivel más simple, los vPOPs proporcionan un punto de entrada y salida para el tráfico. Un ejemplo comentado en un blog anterior titulado "Para entender la cobertura, no basta con contar los centros de datos" mostraba un escenario con un usuario remoto en Chile. Este usuario tendría que conectarse a un vPOP en Santiago, hacer que su tráfico se enviara a Miami (Florida, EE.UU.) para su procesamiento y, a continuación, volver a Santiago antes de que la solicitud del usuario se dirigiera a Internet y a la web, la nube o la aplicación SaaS a la que intentaba acceder. Imagínese la latencia que se produce con este tráfico de ida y vuelta, enrutado a través de enormes distancias, sobre múltiples redes, que en última instancia ralentiza significativamente la experiencia del usuario. El problema es que los vPOPs son literalmente una red de tráfico de retorno, con las mismas implicaciones en cuanto a complejidad, latencia y, potencialmente, coste. 

Y cuando los proveedores dependen de la infraestructura de nube pública, como AWS, Azure o GCP, dependen de los centros de datos del proveedor de la nube pública para proporcionar puntos de salida regionales para el tráfico (Palo Alto). O, lo que es peor, y mucho más común, hacen retorno del tráfico a través de la congestionada e impredecible Internet pública y utilizan una "centralita telefónica" de IPs de salida, cada una registrada en un país diferente, para implementar sus vPOPs (como hacen el resto). El mismo problema se manifiesta de nuevo, con el tráfico teniendo que ser conducido a través de enormes distancias, con retornos y bucles de tráfico entre múltiples ubicaciones, antes de llegar finalmente a las pocas -a menudo menos de 30- ubicaciones únicas en el mundo donde se encuentran los recursos de computación y puede tener lugar el procesamiento del tráfico de seguridad. Los clientes creen que están comprando una estrategia de nube para ir directamente a la red con las protecciones de seguridad críticas que requieren, pero lo que están obteniendo son los mismos viejos problemas de red del pasado reimplementados dentro de la nube. Este es el sucio secreto de la mayoría de los proveedores de seguridad en la nube. 

Como decíamos, un ejemplo de pesadilla de hairpinning en un conocido proveedor de seguridad en la nube surgió recientemente con un cliente con el que estábamos trabajando en América Latina (LATAM). Aunque el proveedor anuncia cuatro centros de datos en LATAM, en realidad tiene tres vPOPs y una región de nube pública en LATAM: vPOPs en Chile, Argentina y Colombia, y máquinas virtuales que se ejecutan en GCP Brasil. Mientras que los usuarios de Brasil eran atendidos desde GCP Brasil, todos los demás países de LATAM eran atendidos desde los Estados Unidos. El tráfico de LATAM tenía que ser transportado a EE.UU. para el procesamiento y la aplicación de las políticas de seguridad. El enfoque de este proveedor no sólo era tremendamente engañoso en cuanto a la cobertura—¡parece que sólo tienen un centro de datos en LATAM y no cuatro!—sino que este enfoque dependiente del hairpinning introdujo cientos de milisegundos de latencia. Y lo que es peor, el cliente vio cómo disminuía el rendimiento general debido a esta alta latencia (porque el rendimiento es inversamente proporcional a la latencia con TCP), aumentaban las tasas de error y la pérdida de paquetes, y la fiabilidad general era menor. Hasta que habló con Netskope y se enteró de cómo habíamos diseñado NewEdge, este cliente estaba indeciso para adoptar seguridad en la nube y estaba a punto de duplicar sus dispositivos físicos existentes y su arquitectura WAN MPLS poco eficiente. 

Muchos proveedores afirman que los vPOP son la única forma de ofrecer una experiencia de usuario sin fisuras, de modo que, por ejemplo, los usuarios obtienen los resultados de búsqueda de Google o los anuncios localizados adecuadamente para su ubicación o región específica. La realidad es que cualquier proveedor que dependa de la nube pública en lugar de sus propios centros de datos para ofrecer un servicio de seguridad en la nube está limitado a las ciudades y regiones en las que su proveedor de nube ofrece servicios de computación (VM), por lo que no tiene más remedio que hacer retorno del tráfico y utilizar vPOPs para tratar de reducir las posibilidades de que este retorno no dé lugar a la localización de contenidos, al bloqueo de la geolocalización o a otros problemas derivados de su enrutamiento a una región lejana.

Hemos insistido en este punto en otros artículos del blog, pero la estrategia que Netskope ha adoptado con NewEdge es realmente diferente y por eso hemos invertido más de 100 millones de dólares para construir la nube privada de seguridad más grande y de mayor rendimiento del mundo. NewEdge adopta un modelo directo a la red para agilizar la ruta del tráfico y centrarse en la simplificación de la red, al tiempo que consigue una fiabilidad y resiliencia superiores. No dependemos de vPOPs ni de la nube pública, por lo que nuestro rendimiento es mejor y más predecible. Y cada uno de nuestros centros de datos hace todo el procesamiento, con todos los servicios de la plataforma de seguridad de Netskope disponibles en todos los puntos de presencia. Todo esto garantiza el acceso más rápido y de menor latencia para los usuarios, tanto si se conectan desde una cafetería en Milán, una sucursal en Hong Kong o la sede de la empresa en Nueva York. Además, la naturaleza altamente conectada de NewEdge, con un amplio peering con los proveedores de la web, nube (SaaS, IaaS) que más interesan a los clientes, realmente da a NewEdge, y a los clientes de Netskope, una ventaja. Es hora de que los clientes se informen sobre el pequeño y sucio secreto de la mayoría de las redes de los proveedores de seguridad en la nube y se aseguren de que su selección de servicios de seguridad en la nube no repita los errores del pasado, como con el hairpinning.

To learn more about Netskope and NewEdge, please visit: https://www.netskope.com/netskope-one/newedge