Blog DNA, NewEdge Network, Secure Access Service Edge The Path of a Packet in a SASE Architecture
May 05 2020

El camino que sigue un paquete en una arquitectura SASE

En el pasado, había una clara separación entre el papel de la red corporativa e Internet. Los arquitectos de redes se centraban en las redes que estaban bajo su control directo, y confiaban en su proveedor de servicios para proporcionar acceso a la Internet. 

Con el auge de las aplicaciones en la nube, estamos viendo un cambio en esta separación. Esto se debe a que los arquitectos de redes tienen aplicaciones clave para el negocio que están alojadas en la nube, y ahora tienen que pensar en el rendimiento de la red bajo un concepto diferente, con el acceso a las aplicaciones siguiendo rutas de tráfico que en su mayoría están fuera de los límites de su red. Además, cada aplicación también tiene requisitos únicos en cuanto al rendimiento de la red que deben ser considerados. Por ejemplo, la transmisión de seminarios por Internet o webinars (de uno a muchos) necesita un gran ancho de banda, la colaboración en tiempo real necesita una baja latencia, y los sistemas de backend alojados en nubes privadas virtuales pueden tener requisitos de resiliencia y redundancia muy elevados. Para complicar aún más las cosas, a diferencia de las aplicaciones privadas, las aplicaciones en la nube no tienen un conjunto previsible de direcciones y puertos IP, y están en constante cambio y evolución, lo que las convierte en un objetivo nebuloso y siempre cambiante. ¡Tal vez el término "nube" es aún más apropiado de lo que hayamos pensado!

Gif of clouds moving

La seguridad, por supuesto, es un habilitador crítico de las aplicaciones, y es por eso que Secure Access Service Edge (SASE) ha surgido ahora como un importante modelo conceptual para describir cómo proteger a los usuarios y las aplicaciones que operan más allá del perímetro de la red tradicional. SASE es un modelo que reconoce que la ubicación del usuario y la aplicación ya no pueden ser consideradas como fijas. En otras palabras, el enfoque tradicional de castillo y foso para la seguridad de las aplicaciones y la red no protege a las personas que no están en el castillo.

Picture of castle and moat for comparison

El equipo de ingeniería de plataforma de Netskope es responsable de diseñar y operar NewEdge, la nube de seguridad privada en la que se ejecuta la Plataforma de Seguridad en la Nube de Netskope. Existe un enorme interés por parte de los clientes que desean saber cómo dar soporte y proteger su compleja mezcla de aplicaciones, gestionadas (IT-led), no gestionadas (Shadow IT), on-premise (en local), aplicaciones privadas en la nube, SaaS de terceros, y más. En muchas conversaciones sobre SASE, encuentro muy útil recurrir a mi década de experiencia en el espacio de las CDN (Content Delivery Network) para recorrer los elementos que forman parte del camino que toma el tráfico de los usuarios finales en varios escenarios. Esto se debe a que SASE es un tema nuevo para todos. La arquitectura de las redes de operadoras, los proveedores de servicios en la nube, las CDNs e Internet no son necesariamente entendidas de forma amplia, y a veces el lenguaje de muchos conceptos no está estandarizado en toda la industria.

Tomemos el término "centro de datos", por ejemplo. En mi mundo, un centro de datos significaba un edificio físico con paredes de hormigón, suelos elevados, y controles ambientales cuidadosamente monitoreados. Siempre he supuesto que si me dices que tienes dos centros de datos, eres dueño de dos de esos edificios, como el famoso NAP de las Américas en Miami, Florida. Hoy en día, sólo las instalaciones de alojamiento de infraestructura (colocation), las empresas de telecomunicaciones, unos cuantos proveedores de servicios gestionados, y un número muy pequeño de empresas poseen y construyen sus propios "centros de datos". De hecho, muchos proveedores de alojamiento no son dueños del edificio, sólo alquilan espacio dentro de un centro de datos más grande. Por el contrario, un punto de presencia (POP) es una ubicación donde se han colocado servidores, pero no somos dueños ni operamos el centro de datos. Sin embargo, en el ámbito de la seguridad, a menudo verá "POPs" referidos como centros de datos, lo que a veces puede causar confusión.

Semántica aparte, ahora reconozco que la definición de centro de datos está cambiando, y que la manera más fácil de plantear un debate sobre los puntos de presencia es usar el lenguaje que se entiende de forma más amplia en el ámbito de la seguridad. En este artículo y en el futuro, usaré "centro de datos" para referirme a cualquier lugar donde haya servidores o equipos de red.

Como arquitecto, me encantan las conversaciones con nuestros clientes sobre la latencia de extremo a extremo y sobre cómo garantizar una excelente experiencia de usuario. Esto es fácil de hacer con una gran pizarra blanca vacía y una caja nueva de rotuladores. Es un poco más difícil tener la misma conversación por escrito, cuando necesitamos comprobar primero si estamos usando los términos de la misma manera. Por eso me pareció prudente explicar el "camino que sigue un paquete" en este blog.

En el modelo de Secure Access Service Edge (SASE) para la prestación de servicios de seguridad basados en la nube, el "paquete" fluye a través de varios componentes y límites lógicos, y es útil proporcionarles nombres para aclarar qué es qué.

Figure depicting the three mile markers of a packet's journey within a SASE architecture
Figura: El camino que sigue un paquete

Primera Milla

En general, los usuarios podrían estar en varios lugares diferentes. Podrían estar ubicados en la oficina o en casa, y necesitan utilizar una aplicación basada en la nube. En la primera milla, la solicitud del usuario para acceder a una aplicación atraviesa una red de área local hasta el extremo de la red. 

En el caso de los usuarios que trabajan desde su casa, el usuario y el extremo de la red están en el mismo edificio. En las redes corporativas, generalmente hay muchos menos extremos de red que en las oficinas o los campus. Si bien SASE es un facilitador de los "puntos de acceso locales a Internet", la mayoría de las organizaciones todavía concentran sus extremos de red en uno o unos pocos lugares. 

Dado que la ubicación del usuario es indeterminada y la calidad de la seguridad en el extremo de la red es cuestionable o inexistente, la protección en el perímetro también es indeterminada en el mejor de los casos. Si no se sabe si el usuario va a estar detrás de un firewall corporativo, entonces no se puede esperar que ese firewall ofrezca visibilidad o protección. El modelo SASE aborda este punto, al ofrecer una visibilidad consistente y la aplicación de políticas de seguridad en la milla media, en lugar de confiar en las medidas de seguridad que pueden o no existir en la primera milla.

Milla intermedia

Secure Access Service Edge no es un "destino", sino la provisión de servicios de red y seguridad para el tráfico en ruta a Internet, aplicaciones en la nube o el centro de datos. Cuando los usuarios acceden a las aplicaciones, el paquete tiene un punto de entrada (el edge de SASE) y un punto de salida (el punto de egress SASE), con el procesamiento de las políticas teniendo lugar en algún punto intermedio. Tenga en cuenta que este es un modelo lógico para hablar sobre este tema, pero con la variedad de arquitecturas en el mercado, hay que destacar que hay implementaciones con extremo/procesamiento/salida todas en el mismo centro de datos, y otras donde la salida o el extremo está desacoplado, pero las otras dos están en el mismo centro de datos, y algunas donde cada función tiene lugar en diferentes ubicaciones de centros de datos. La nomenclatura es una fuente de confusión dadas las diferentes maneras en que estas funciones operan y se implementan.

Última milla

No hace mucho tiempo que el enlace de la operadora con Internet era algo que sólo interesaba a otros arquitectos de otras operadoras. Los arquitectos de redes de las organizaciones podrían estar interesados en el tiempo total del comando traceroute, pero ahora hay un creciente interés en cómo las operadoras manejan el enrutamiento a Internet, ya sea utilizando un punto de intercambio de Internet (IXP) o si hay una relación de intercambio de tráfico (peering).

La premisa básica del peering entre proveedores de la nube no es nueva, pero ha pasado a primer plano para los clientes que buscan un alto rendimiento para aplicaciones específicas. Sin embargo, lo que no se entiende ampliamente es que existen diferentes tipos de peering que utilizan las operadoras, y estas palabras se utilizan de manera confusa. Para resumir brevemente:

  • Peering privado: El peering privado es una relación directa de peering entre dos redes que proporciona una capacidad dedicada que no es compartida con ninguna otra parte. Al igual que otras formas de peering, está diseñado para agilizar el tráfico sin tener que pasar por la Internet general. Este tipo de peering puede implementarse a través de una interconexión de red privada o a través de un intercambio privado.
  • Peering público: Un centro de datos de extremo SASE puede llegar a Internet a través de un punto de intercambio de Internet. Con el peering público, el IXP divide la relación de peering entre las dos redes. La relación de peering existe entre el IXP y el borde de la nube, y por lo tanto indirectamente entre el extremo de SASE y el extremo de la nube. En general, esto sigue siendo mejor que el enrutamiento a través de la Internet general, pero debe quedar claro que esto no es lo mismo que el peering privado.

Nota, en ambos escenarios, estas relaciones de peering a nivel de operadora son diferentes del concepto de conectar un centro de datos corporativo a una nube privada virtual usando un circuito asociado, como ExpressRoute para Azure o Direct Connect para AWS. El concepto básico subyacente es similar pero está operando en un lado diferente del espectro.

En Netskope, estamos construyendo una innovadora red privada de nivel carrier-grade llamada NewEdge, diseñada para proveer de cobertura global a la seguridad proporcionada para la nube. Aclarar el lenguaje que usamos es útil para profundizar en cómo funciona. Afortunadamente, uno no tiene que aprender las complejidades de operar una red de operadora para beneficiarse de la experiencia del usuario que ofrece. Pero sí ayuda a desarrollar una apreciación más profunda de lo que estamos haciendo para construir la nube privada de seguridad más grande del mundo. 

Ahora que hemos cubierto lo básico, manténgase atento a este blog para tener más detalles sobre lo que estamos haciendo para cambiar el mundo con NewEdge.

¿Quiere saber más sobre NewEdge? Eche un vistazo a nuestra página web o solicite una demostración para saber más sobre NewEdge y lo que hace.

author image
Acerca del autor
Jason Hofmann es un experimentado ejecutivo de tecnología con 20 años de experiencia. Como vicepresidente de arquitectura y servicios de plataforma en Netskope, Hofmann dirige los equipos de arquitectura y servicios de plataforma. Además de centrarse en la construcción de la nube de seguridad global de Netskope, llamada NewEdge, Hofmann y su equipo dirigen todos los aspectos de la arquitectura de la plataforma y trabajan estrechamente con los clientes para garantizar la entrega de una experiencia de servicio verdaderamente de primera clase.
Jason Hofmann is a seasoned technology executive with 20 years of experience. As VP of Platform Architecture and Services at Netskope, Hofmann leads the platform architecture and platform services teams. In addition to focusing on building out the global Netskope security cloud, called NewEdge, Hofmann and his team lead all…