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 requiere 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!
Asegurando un perímetro ubicuo
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.
A este respecto, hay un interés creciente en el mundo empresarial por conocer cómo dar soporte y proteger la 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 el modelo de Secure Access Service Edge (SASE), tema muy nuevo para muchos, 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é.
El camino que sigue un paquete: primera Milla
En general, los usuarios podrían estar en varios lugares diferentes; en la oficina o en casa, y utilizar una aplicación basada en la nube. En este primer punto, la solicitud del usuario para acceder a una aplicación pasa para 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. Se trata de 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 intercambio 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 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 privado.
En definitiva, 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
