Compartir a través de

Enfoques de arquitectura para redes en soluciones multiinquilino

Todas las soluciones implementadas en Azure requieren algún tipo de red. La forma de interactuar con los servicios de red de Azure depende del diseño y la carga de trabajo de la solución. En este artículo se proporcionan consideraciones e instrucciones para los aspectos de red de soluciones multiinquilino en Azure. Incluye información sobre los componentes de red de nivel inferior, como las redes virtuales, y se extiende a enfoques de nivel superior y de nivel de aplicación.

Nota

Azure es un entorno multiinquilino, ya que son muchos de sus componentes de red. No es necesario comprender los detalles para diseñar su propia solución, pero 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 consideraciones sobre los componentes de red dependen de la categoría de servicios que use.

Servicios de infraestructura

Al usar servicios de infraestructura, como máquinas virtuales (VM) o Azure Kubernetes Service (AKS), tenga en cuenta y diseñe las redes virtuales que respaldan la conectividad de los servicios. Tenga en cuenta también las otras capas de seguridad y aislamiento que debe incorporar al diseño. Evite depender exclusivamente de los controles de la capa de red.

Servicios de plataforma

Cuando se usan servicios de plataforma de Azure, como Azure App Service, Azure Cosmos DB o Azure SQL Database, la arquitectura determina los servicios de red que necesita.

Para aislar los servicios de plataforma de Internet, use una red virtual. En función de los servicios que use, puede trabajar con puntos de conexión privados o recursos integrados de red virtual, como Azure Application Gateway. También puede hacer que los servicios de la plataforma estén disponibles a través de sus direcciones IP públicas y usen las propias protecciones de los servicios, como firewalls y controles de identidad. En estas situaciones, es posible que no necesite implementar y configurar su propia red virtual.

Decida si va a usar redes virtuales para servicios de plataforma en función de los siguientes factores:

  • Requisitos de cumplimiento: Es posible que deba cumplir un estándar de cumplimiento específico. Algunos estándares requieren configurar el entorno de Azure de maneras específicas, como el uso de controles de red concretos. Para obtener más información, consulte Enfoques arquitectónicos para la gobernanza y el cumplimiento en soluciones multiinquilino.

  • Requisitos de los inquilinos: Incluso si su organización no tiene requisitos definidos para el aislamiento o los controles de la capa de red, es posible que los inquilinos. Comprenda claramente cómo los inquilinos planean acceder a la solución y si tienen suposiciones sobre su diseño de red.

  • Complejidad: Las redes virtuales presentan complejidad. Asegúrese de que el equipo comprenda claramente los principios implicados para evitar la implementación de un entorno no seguro.

Asegúrese de comprender las implicaciones de usar redes privadas.

Tamaño de las subredes

Cuando necesite implementar una red virtual, considere cuidadosamente el tamaño y el espacio de direcciones de toda la red virtual, incluidas las subredes.

Comprenda cómo planea 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 bases de datos u otros recursos específicos del inquilino, cree subredes lo suficientemente grandes como para el crecimiento esperado del inquilino y el escalado automático horizontal de los recursos.

De forma similar, al trabajar con servicios administrados, comprenda cómo consumen direcciones IP. Por ejemplo, cuando se usa AKS con azure Container Networking Interface (CNI), el número de direcciones IP consumidas desde una subred se basa en factores como el número de nodos, cómo se escala horizontalmente y el proceso de implementación del servicio. Cuando se usa App Service y Azure Functions con integración de red virtual, el número de direcciones IP consumidas se basa en el número de instancias del plan.

Revise las instrucciones de segmentación de subred al planear las subredes.

Acceso público o privado

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

Para proteger el servicio para el acceso basado en Internet (público), use reglas de firewall, listas de direcciones IP permitidas y denegación de listas, secretos compartidos y claves y controles basados en identidades.

Para permitir que los inquilinos se conecten al servicio mediante direcciones IP privadas, considere la posibilidad de usar el servicio Azure Private Link 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 enfoque solo tiene sentido cuando tiene pocos inquilinos y al implementar redes virtuales dedicadas para cada inquilino.

Acceso a los puntos de conexión de los inquilinos

Tenga en cuenta 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, puede invocar un webhook proporcionado por el cliente o enviar mensajes en tiempo real a los sistemas de 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 su 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 usar la traducción de direcciones de red (NAT) mediante la implementación de Azure 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 su ubicación.

  • Considere la posibilidad de usar un servicio como Azure Event Grid, potencialmente con dominios de eventos, para la mensajería unidireccional.

Enfoques y patrones que se deben tener en cuenta

En esta sección se describen algunos enfoques clave de red que se deben tener en cuenta en una solución multiinquilino. Comienza con enfoques de nivel inferior para los componentes principales de red y, a continuación, describe los enfoques para HTTP y otros problemas de capa de aplicación.

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

En algunos escenarios, debe ejecutar recursos conectados a la red virtual dedicados 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 un espacio de direcciones IP que controle. Este enfoque le permite emparejar las redes virtuales para sus propios fines, como establecer una topología en estrella tipo hub-and-spoke para controlar de forma centralizada la entrada y salida del tráfico.

Evite usar direcciones IP seleccionadas por el proveedor de servicios si los inquilinos necesitan conectarse directamente a la red virtual que cree, como mediante el emparejamiento de red virtual. El espacio de direcciones que seleccione probablemente entre en conflicto con sus espacios de direcciones existentes.

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 mediante un espacio de direcciones IP que seleccione el inquilino. Esta configuración 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, lo que permite la compatibilidad con el emparejamiento.

Pero es probable que este enfoque le impida emparejar las redes virtuales de los inquilinos o adoptar una topología en estrella tipo hub-and-spoke. Las redes virtuales emparejadas no pueden usar intervalos de direcciones IP superpuestos y, cuando los inquilinos seleccionan sus propios intervalos de direcciones IP, es probable que seleccionen intervalos que se superpongan entre sí.

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

La topología de red virtual en estrella tipo hub-and-spoke permite emparejar una red virtual de concentrador centralizada con varias redes virtuales radiales . Puede controlar de forma centralizada la entrada y salida del tráfico para 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 podría usar servicios como Azure DDoS Protection.

Al usar una topología en estrella tipo hub-and-spoke, planee límites como el número máximo de redes virtuales emparejadas. No use espacios de direcciones superpuestos para la red virtual de cada inquilino.

Considere la posibilidad de usar la topología en estrella tipo hub-and-spoke al implementar redes virtuales específicas del inquilino que usen direcciones IP que seleccione. La red virtual de cada inquilino se convierte en un radio y puede compartir recursos comunes en la red virtual del concentrador. También puede usar la topología en estrella tipo hub-and-spoke al escalar recursos compartidos entre varias redes virtuales o al usar el patrón De stamps de implementación.

Sugerencia

Si la solución abarca varias regiones geográficas, implemente centros y recursos de concentrador independientes en cada región para evitar que el tráfico cruce varias regiones de Azure. Esta práctica supone un mayor costo de recursos, pero reduce la latencia de las solicitudes y reduce los 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.

Al trabajar 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 Azure NAT Gateway para controlar la dirección IP del tráfico saliente. Para más información, consulte consideraciones de Azure NAT Gateway paramultiinquilino.

Al trabajar con servicios de plataforma, el servicio específico que usa determina cómo puede controlar las direcciones IP. Es posible que tenga que configurar el recurso de una manera específica, como mediante la implementación de un recurso como una máquina virtual en una red virtual y, a continuación, usar una puerta de enlace NAT o un firewall. O bien, puede solicitar el conjunto actual de direcciones IP que usa el servicio 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

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

El agente inicia una conexión saliente a un punto de conexión que especifique y controle. Mantiene activas las conexiones de larga duración o sondea intermitentemente. 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 elimina la necesidad de que los inquilinos asuman este riesgo.

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

El servicio Private Link proporciona conectividad privada desde el entorno de Azure de un inquilino a la solución. Los inquilinos también pueden usar el servicio 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, consulte Multiinquilino y Private Link.

Nombres de dominio, subdominios y TLS

Al trabajar con nombres de dominio y seguridad de la capa de transporte (TLS) en una solución multiinquilino, revise las consideraciones clave.

Patrones de Enrutamiento y Descarga de Gateways

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

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

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

Si planea implementar una puerta de enlace para la solución, un procedimiento recomendado consiste en crear primero un prototipo completo. Incluya todas las características necesarias y compruebe que los componentes de la aplicación funcionan según lo previsto. También debe comprender cómo se escala el componente de puerta de enlace para admitir el crecimiento del tráfico y del inquilino.

Patrón de alojamiento de contenido estático

El patrón de hospedaje de contenido estático sirve contenido web desde un servicio de almacenamiento nativo en la nube y usa una red de entrega de contenido para almacenar en caché el contenido.

Puede usar Azure Front Door u otra red de entrega de contenido 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 del diseño de la solución, es posible que también pueda almacenar en caché archivos o datos específicos del inquilino dentro de una red de entrega de contenido, como respuestas de API con formato JSON. Esta práctica puede ayudarle a mejorar el rendimiento y la escalabilidad de la solución. Asegúrese de que los datos específicos del inquilino permanecen lo suficientemente aislados para evitar la pérdida de datos entre inquilinos. Considere cómo planea purgar contenido específico del cliente de la memoria caché, por ejemplo, cuando se actualizan los datos o se despliega 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

No se puede planear la conectividad de red virtual

La implementación de recursos en redes virtuales proporciona un control significativo sobre cómo fluye el tráfico a través de los componentes de la solución. Pero la integración de red virtual también presenta más complejidad, costo y otros factores que debe tener en cuenta, especialmente para los componentes de plataforma como servicio (PaaS).

Pruebe y planee la estrategia de red para identificar cualquier problema antes de implementarlo en un entorno de producción.

Falta de planificación de límites

Azure aplica muchos 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 App Service y Azure Functions, es posible que tenga que tener en cuenta el número de conexiones del Protocolo de control de transmisión (TCP) y los puertos de traducción de direcciones de red de origen (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 los puertos SNAT.

Subredes pequeñas

Cambie el tamaño de cada subred para admitir el número de recursos o instancias de recursos que planea implementar, especialmente a medida que se escala. Al trabajar con recursos de PaaS, comprenda cómo afecta la configuración y la escala del recurso al número de direcciones IP necesarias en su subred.

Segmentación de red incorrecta

Si la solución requiere redes virtuales, considere cómo configurar la segmentación de red para controlar el tráfico entrante y saliente (conocido como tráfico norte-sur), así como el tráfico dentro de la solución (conocido como tráfico este-oeste). Decida si los inquilinos deben tener sus propias redes virtuales o si debe implementar recursos compartidos en redes virtuales compartidas. Cambiar el enfoque puede ser difícil, así que tenga cuidado de tener en cuenta todos los requisitos antes de seleccionar un enfoque que funcione para los objetivos de crecimiento futuros.

Confiar solo en controles de seguridad de nivel de red

En las soluciones modernas, debe combinar la seguridad de la capa de red con otros controles de seguridad. No confíe solo en firewalls o segmentación de red. Este enfoque se denomina a veces 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 adicionales de protección. Las opciones dependen de los servicios de Azure que use. En AKS, considere la posibilidad de usar una malla de servicio para la autenticación TLS mutua y aplicar 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óny 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 back-end descargando el dominio personalizado y la administración de TLS en la puerta de enlace.

Pero Host las reescrituras de encabezado pueden causar problemas para 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 producirse cuando se usan servicios back-end que se ejecutan en infraestructura multiinquilino, como App Service y Azure Functions. Para obtener más información, consulte Procedimientos recomendados para conservación de nombres de host.

Pruebe el comportamiento de la aplicación con la configuración de puerta de enlace que planea usar.

Colaboradores

Microsoft mantiene este artículo. Los colaboradores siguientes escribieron este artículo.

Autor principal:

  • John Downs | Ingeniero principal de software, Patrones y prácticas de Azure

Otros colaboradores:

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

  • Last updated on