Compartir a través de

Enfoques de arquitectura para redes en soluciones multiinquilino

  • Artículo

Todas las soluciones implementadas en Azure requieren redes de algún tipo. Según el diseño de la solución y la carga de trabajo, las formas en que interactúa con los servicios de red de Azure pueden ser diferentes. En este artículo se proporcionan consideraciones e instrucciones para los aspectos de red de las soluciones multiinquilino en Azure. Se incluye información sobre los componentes de red de nivel inferior, como las redes virtuales, a través de enfoques de nivel superior y de nivel de aplicación.

Nota

Azure es un entorno multiinquilino y los componentes de red de Azure están diseñados para varios inquilinos. Aunque no es necesario comprender los detalles para diseñar su propia solución, puede obtener más información sobre cómo Azure aísla el tráfico de red virtual del tráfico de otros clientes.

Consideraciones clave y requisitos

Servicios de plataforma e infraestructura

Las preocupaciones que tiene por los componentes de red variarán en función de la categoría de servicios que use.

Servicios de infraestructura

Siempre que use servicios de infraestructura, como máquinas virtuales o Azure Kubernetes Service, debe tener en cuenta y diseñar las redes virtuales, o VNet, que respaldan la conectividad de los servicios. También debe tener en cuenta las demás capas de seguridad y aislamiento que debe incorporar en el diseño. Evite confiar exclusivamente en controles de capa de red.

Servicios de plataforma

Si usa los servicios de plataforma de Azure, como App Service, Azure Cosmos DB o Azure SQL Database, la arquitectura específica que use determinará los servicios de red que necesita.

Si necesita aislar los servicios de plataforma de Internet, debe usar una VNet. En función de los servicios específicos que use, puede trabajar con puntos de conexión privados o con recursos integrados en la red virtual, como Application Gateway. Sin embargo, también puede optar por hacer que los servicios de plataforma estén disponibles a través de sus direcciones IP públicas y usar las propias protecciones de los servicios, como firewalls y controles de identidad. En estas situaciones, es posible que no necesite una red virtual.

La decisión de si usar redes virtuales para los servicios de plataforma se basa en muchos requisitos, incluidos los siguientes factores:

  • Requisitos de cumplimiento: Es posible que deba cumplir un estándar de cumplimiento específico. Algunos estándares requieren que el entorno de Azure se configure de maneras específicas.
  • Requisitos de sus inquilinos: Incluso si su propia organización no tiene requisitos específicos para el aislamiento o los controles de la capa de red, es posible que sus inquilinos sí los tengan. Asegúrese de que tiene un conocimiento claro de cómo accederán los inquilinos a la solución y de si tienen suposiciones sobre su diseño de red.
  • Complejidad: Puede ser más complejo comprender y trabajar con redes virtuales. Asegúrese de que el equipo tiene un conocimiento claro de los principios implicados o de que es probable que implemente un entorno no seguro.

Asegúrese de comprender las implicaciones del uso de redes privadas.

Dimensionamiento de subredes

Cuando necesite implementar una red virtual, es importante tener en cuenta detenidamente el dimensionamiento y el espacio de direcciones de toda la red virtual y de las subredes dentro de la red virtual.

Asegúrese de que tiene un conocimiento claro de cómo implementará los recursos de Azure en redes virtuales y el número de direcciones IP que consume cada recurso. Si implementa nodos de proceso, servidores de base de datos u otros recursos específicos del inquilino, asegúrese de crear subredes lo suficientemente grandes para el crecimiento esperado del inquilino y el escalado automático horizontal de recursos.

De forma similar, cuando se trabaja con servicios administrados, es importante comprender cómo se consumen las direcciones IP. Por ejemplo, cuando se usa Azure Kubernetes Service con Azure Container Networking Interface (CNI), el número de direcciones IP consumidas desde una subred se basará en factores como el número de nodos, el escalado horizontal y el proceso de implementación del servicio que use. Cuando se usa la integración de Azure App Service y Azure Functions con redes virtuales, el número de direcciones IP consumidas se basa en el número de instancias de plan.

Revise la guía de segmentación de subredes al planear las subredes.

Acceso público o privado

Tenga en cuenta si los inquilinos accederán a los servicios a través de Internet o a través de direcciones IP privadas.

Para el acceso basado en Internet (público), puede usar reglas de firewall, listas de permitidos y denegaciones de direcciones IP, secretos y claves compartidos y controles basados en identidades para proteger su servicio.

Si necesita habilitar la conectividad con el servicio mediante direcciones IP privadas, considere la posibilidad de usar Azure Private Link Service o el emparejamiento de red virtual entre inquilinos. En algunos escenarios limitados, también puede considerar la posibilidad de usar Azure ExpressRoute o Azure VPN Gateway para habilitar el acceso privado a la solución. Normalmente, este método solo tiene sentido cuando hay un número reducido de inquilinos o cuando se implementan redes virtuales dedicadas en cada inquilino.

Acceso a los puntos de conexión de los inquilinos

Considere si necesita enviar datos a puntos de conexión dentro de las redes de los inquilinos, ya sea dentro o fuera de Azure. Por ejemplo, ¿tendrá que invocar un webhook proporcionado por un cliente o tendrá que enviar mensajes en tiempo real a un inquilino?

Si necesita enviar datos a los puntos de conexión de los inquilinos, tenga en cuenta los siguientes enfoques comunes:

  • Inicie conexiones desde la solución a los puntos de conexión de los inquilinos a través de Internet. Considere si las conexiones deben originarse desde una dirección IP estática. En función de los servicios de Azure que use, es posible que tenga que implementar un NAT Gateway, un firewall o un equilibrador de carga.
  • Implemente un agente para habilitar la conectividad entre los servicios hospedados en Azure y las redes de los clientes, independientemente de dónde se encuentran.
  • Para la mensajería unidireccional, considere la posibilidad de usar un servicio como Azure Event Grid, posiblemente con dominios de evento.

Enfoques y patrones que se deben tener en cuenta

En esta sección, se describen algunos de los enfoques de red clave que se pueden tener en cuenta en una solución multiinquilino. Comenzamos describiendo los enfoques de nivel inferior para los componentes de red principales y, a continuación, seguimos con los enfoques que puede tener en cuenta para HTTP y otros problemas de nivel de aplicación.

Redes virtuales específicas del inquilino con direcciones IP seleccionadas por el proveedor de servicios

En algunas situaciones, debe ejecutar recursos conectados a una red virtual dedicada en Azure en nombre de un inquilino. Por ejemplo, puede ejecutar una máquina virtual para cada inquilino o puede que tenga que usar puntos de conexión privados para acceder a bases de datos específicas del inquilino.

Considere la posibilidad de implementar una red virtual para cada inquilino mediante el uso de un espacio de direcciones IP que controle. Este enfoque le permite emparejar las redes virtuales para sus propios propósitos, por ejemplo, si necesita establecer una topología de concentrador y radio para controlar de forma centralizada la entrada y salida del tráfico.

Sin embargo, las direcciones IP seleccionadas por el proveedor de servicios no son adecuadas si los inquilinos necesitan conectarse directamente a la red virtual que creó, como mediante el emparejamiento de VNet. Es probable que el espacio de direcciones que seleccione sea incompatible con sus propios espacios de direcciones.

Redes virtuales específicas del inquilino con direcciones IP seleccionadas por el inquilino

Si los inquilinos necesitan emparejar sus propias redes virtuales con la red virtual que administra en su nombre, considere la posibilidad de implementar redes virtuales específicas del inquilino con un espacio de direcciones IP que seleccione el inquilino. Este sistema permite a cada inquilino asegurarse de que los intervalos de direcciones IP de la red virtual del sistema no se superponen con sus propias redes virtuales. Mediante el uso de intervalos de direcciones IP no superpuestos, pueden asegurar que sus redes son compatibles con el emparejamiento.

Sin embargo, este enfoque significa que es poco probable que pueda emparejar las redes virtuales de los inquilinos o adoptar una topología de concentrador y radio, ya que es probable que haya intervalos de direcciones IP superpuestos entre redes virtuales de diferentes inquilinos.

Topología de red en estrella tipo hub-and-spoke

La topología de red virtual de concentrador y radio le permite emparejar una red virtual de concentrador centralizada con varias redes virtuales de radio. Puede controlar de forma centralizada la entrada y salida del tráfico de las redes virtuales y controlar si los recursos de la red virtual de cada radio pueden comunicarse entre sí. Cada red virtual de radio también puede acceder a componentes compartidos, como Azure Firewall, y puede usar servicios como Azure DDoS Protection.

Cuando use una topología de concentrador y radio, asegúrese de planear límites, como el número máximo de redes virtuales emparejadas, y asegúrese de no usar espacios de direcciones superpuestos para la red virtual de cada inquilino.

La topología de concentrador y radio puede ser útil al implementar redes virtuales específicas del inquilino con las direcciones IP que seleccione. La red virtual de cada inquilino se convierte en un radio y puede compartir los recursos comunes en la red virtual del concentrador. También puede usar la topología de concentrador y radio al escalar recursos compartidos entre varias redes virtuales con fines de escala, o al usar el patrón de stamps de implementación.

Sugerencia

Si la solución se ejecuta en varias regiones geográficas, suele ser un procedimiento recomendado implementar centros independientes y recursos de concentrador en cada región. Aunque esta práctica incurre en un mayor costo de recursos, evita que el tráfico pase por varias regiones de Azure innecesariamente, lo que puede aumentar la latencia de las solicitudes e incurrir en cargos de emparejamiento global.

Direcciones IP estáticas

Tenga en cuenta si los inquilinos necesitan que el servicio use direcciones IP públicas estáticas para el tráfico entrante, el tráfico saliente o ambos. Los distintos servicios de Azure permiten direcciones IP estáticas de distintas maneras.

Cuando trabaje con máquinas virtuales y otros componentes de infraestructura, considere la posibilidad de usar un equilibrador de carga o un firewall para el direccionamiento IP estático entrante y saliente. Considere la posibilidad de usar NAT Gateway para controlar la dirección IP del tráfico saliente. Para obtener más información sobre el uso de NAT Gateway en soluciones multiinquilino, consulte Consideraciones de Azure NAT Gateway para la administración multiinquilino.

Cuando se trabaja con servicios de plataforma, el servicio específico que se usa determina si y cómo se pueden controlar las direcciones IP. Es posible que tenga que configurar el recurso de una manera específica, por ejemplo, implementando un recurso, como una máquina virtual, en una red virtual y usando un NAT Gateway o firewall. O bien, puede solicitar el conjunto actual de direcciones IP que el servicio usa para el tráfico saliente. Por ejemplo, App Service proporciona una API y una interfaz web para obtener las direcciones IP salientes actuales de la aplicación.

Agentes

Si necesita permitir que los inquilinos reciban mensajes iniciados por la solución, o si necesita acceder a los datos que existen en las propias redes de los inquilinos, considere la posibilidad de proporcionar un agente (a veces denominado puerta de enlace local) que puedan implementar dentro de su red. Este enfoque puede funcionar tanto si las redes de los inquilinos están en Azure, en otro proveedor en la nube o en el entorno local.

El agente inicia una conexión saliente a un punto de conexión que especifique y controle, y mantiene activas las conexiones de larga duración o sondea de forma intermitente. Considere la posibilidad usar Azure Relay para establecer y administrar conexiones desde el agente al servicio. Cuando el agente establece la conexión, se autentica e incluye información sobre el identificador de inquilino para que el servicio pueda asignar la conexión al inquilino correcto.

Normalmente, los agentes simplifican la configuración de seguridad de los inquilinos. Puede ser complejo y arriesgado abrir puertos de entrada, especialmente en un entorno local. Un agente evita la necesidad de que los inquilinos tomen este riesgo.

Entre los ejemplos de servicios Microsoft que proporcionan agentes para la conectividad a las redes de los inquilinos se incluyen:

El servicio Azure Private Link proporciona conectividad privada desde el entorno de Azure de un inquilino a la solución. Los inquilinos también pueden usar Private Link con su propia red virtual para acceder al servicio desde un entorno local. Azure enruta de forma segura el tráfico al servicio mediante direcciones IP privadas.

Para obtener más información sobre Private Link y multi-inquilino, consulte Multi-inquilino y Azure Private Link.

Nombres de dominio, subdominios y TLS

Cuando se trabaja con nombres de dominio y seguridad de la capa de transporte (TLS) en una solución multiinquilino, hay una serie de consideraciones. Revise las consideraciones para los nombres de dominio y multiinquilino.

Patrones Gateway Routing (enrutamiento de puerta de enlace) y Gateway Offloading (descarga de puerta de enlace)

El patrón de enrutamiento de puerta de enlace y el patrón Gateway Offloading implican la implementación de un proxy inverso o puerta de enlace de nivel 7. Las puertas de enlace son útiles para proporcionar servicios principales para una aplicación multiinquilino, incluidas las siguientes funcionalidades:

  • Enrutamiento de solicitudes a back-end o stamps de implementación específicos del inquilino.
  • Control de nombres de dominio específicos del inquilino y certificados TLS.
  • Inspeccionar las solicitudes de amenazas de seguridad mediante un firewall de aplicaciones web (WAF).
  • Respuestas de almacenamiento en caché para mejorar el rendimiento.

Azure proporciona varios servicios que se pueden usar para lograr algunos o todos estos objetivos, incluidos Azure Front Door, Azure Application Gateway y Azure API Management. También puede implementar su propia solución personalizada mediante software como NGINX o HAProxy.

Si tiene previsto implementar una puerta de enlace para la solución, lo más recomendado es crear primero un prototipo completo que incluya todas las características que necesita y comprobar que los componentes de la aplicación siguen funcionando según lo previsto. También debe comprender cómo se escalará el componente de puerta de enlace para admitir el crecimiento del tráfico y del inquilino.

Patrón Static Content Hosting

El patrón de hospedaje de contenido estático implica servir contenido web desde un servicio de almacenamiento nativo en la nube y usar una red de entrega de contenido (CDN) para almacenar en caché el contenido.

Puede usar Azure Front Door u otro CDN para los componentes estáticos de la solución, como aplicaciones JavaScript de página única y para contenido estático, como archivos de imagen y documentos.

En función de cómo se diseñe la solución, es posible que también pueda almacenar en caché archivos o datos específicos del inquilino dentro de un CDN, como las respuestas de API con formato JSON. Esta práctica puede ayudarle a mejorar el rendimiento y la escalabilidad de la solución, pero es importante tener en cuenta si los datos específicos del inquilino están lo suficientemente aislados como para evitar la pérdida de datos entre inquilinos. Tenga en cuenta cómo planea purgar contenido específico del inquilino de la memoria caché, por ejemplo, cuando se actualizan los datos o se implementa una nueva versión de la aplicación. Al incluir el identificador de inquilino en la ruta de acceso URL, puede controlar si purga un archivo específico, todos los archivos relacionados con un inquilino específico o todos los archivos de todos los inquilinos.

Antipatrones que se deben evitar

Imposible planear la conectividad de red virtual

Al implementar recursos en redes virtuales, tiene un gran control sobre cómo fluye el tráfico a través de los componentes de la solución. Sin embargo, la integración con red virtual también introduce complejidad adicional, costos y otros factores que debe tener en cuenta. Este efecto es especialmente cierto con los componentes de la plataforma como servicio (PaaS).

Es importante probar y planear la estrategia de red para que descubra cualquier problema antes de implementarlo en un entorno de producción.

Falta de planificación de límites

Azure aplica una serie de límites que afectan a los recursos de red. Estos límites incluyen los límites de recursos de Azure y los límites fundamentales de protocolo y plataforma. Por ejemplo, al compilar una solución multiinquilino a gran escala en servicios de plataforma, como Azure App Service y Azure Functions, es posible que deba tener en cuenta el número de conexiones TCP y puertos SNAT. Al trabajar con máquinas virtuales y equilibradores de carga, también debe tener en cuenta las limitaciones de las reglas de salida y de los puertos SNAT.

Subredes pequeñas

Es importante tener en cuenta el tamaño de cada subred para permitir el número de recursos o instancias de recursos que implementará, especialmente a escala. Cuando trabaje con recursos de plataforma como servicio (PaaS), asegúrese de comprender cómo la configuración y la escala del recurso afectarán al número de direcciones IP necesarias en su subred.

Segmentación de red incorrecta

Si la solución requiere redes virtuales, tenga en cuenta cómo configurar la segmentación de red para que pueda controlar los flujos de tráfico entrantes y salientes (norte-sur) y los flujos dentro de la solución (este-oeste). Decida si los inquilinos deben tener sus propias redes virtuales o si va a implementar recursos compartidos en redes virtuales compartidas. Cambiar el enfoque puede ser difícil, así que asegúrese de tener en cuenta todos sus requisitos y, a continuación, seleccione un enfoque que funcione para sus objetivos de crecimiento futuros.

Confiar solo en controles de seguridad de nivel de red

En las soluciones modernas, es importante combinar la seguridad de la capa de red con otros controles de seguridad y no debe confiar solo en firewalls o segmentación de red. A veces, a esto se le denomina redes de confianza cero. Use controles basados en identidades para comprobar el cliente, el autor de la llamada o el usuario, en cada capa de la solución. Considere la posibilidad de usar servicios que le permitan agregar capas de protección adicionales. Las opciones que tiene disponibles dependen de los servicios de Azure que use. En AKS, considere la posibilidad de usar una malla de servicio para la autenticación mutua de TLS y directivas de red para controlar el tráfico este-oeste. En App Service, considere la posibilidad de usar la compatibilidad integrada con la autenticación y autorización y las restricciones de acceso.

Reescritura de encabezados host sin pruebas

Al usar el patrón de descarga de puerta de enlace, puede considerar la posibilidad de volver a escribir el Hostencabezado de las solicitudes HTTP. Esta práctica puede simplificar la configuración del servicio de aplicación web de back-end descargando el dominio personalizado y la administración de TLS en la puerta de enlace.

Sin embargo, las reescrituras de encabezados Host pueden causar problemas en algunos servicios back-end. Si la aplicación emite redirecciones HTTP o cookies, la falta de coincidencia en los nombres de host puede interrumpir la funcionalidad de la aplicación. En concreto, este problema puede surgir cuando se usan servicios back-end que son a su vez varios usuarios, como Azure App Service, Azure Functions y Azure Spring Apps. Para más información, consulte el procedimiento recomendado para la conservación del nombre de host.

Asegúrese de probar el comportamiento de la aplicación con la configuración de puerta de enlace que planea usar.

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Autor principal:

Otros colaboradores:

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Pasos siguientes