Redes para cargas de trabajo de SaaS en Azure
La red proporciona la red troncal para cómo los clientes acceden a la aplicación SaaS y permite la comunicación entre los componentes de la solución. La forma de diseñar la red tiene un efecto directo en la seguridad, las operaciones, el costo, el rendimiento y la confiabilidad de la solución. Un enfoque estructurado de la estrategia de red se vuelve aún más importante a medida que crece el entorno de nube.
Decidir una estrategia de implementación de red y una topología
Las soluciones SaaS tienen requisitos de red únicos. A medida que incorpora más clientes y aumenta su uso, cambian los requisitos de red. El control del crecimiento puede ser difícil debido a recursos limitados, como los intervalos de direcciones IP. El diseño de la red afecta a la seguridad y al aislamiento del cliente. Planear la estrategia de red ayuda a administrar el crecimiento, mejorar la seguridad y reducir la complejidad operativa.
Consideraciones de diseño
Planee la estrategia de implementación de red en función del modelo de inquilino. Decida si los recursos de red se compartirán entre los clientes, dedicados a un solo cliente o una combinación. Esta opción afecta a la funcionalidad, la seguridad y el aislamiento del cliente de la aplicación.
Es habitual compartir recursos de red, como redes virtuales y perfiles de Azure Front Door, entre varios clientes. Este enfoque reduce los costos y la sobrecarga operativa. También simplifica la conectividad. Puede conectar fácilmente los recursos de un cliente con recursos compartidos, como cuentas de almacenamiento compartidas o un plano de control.
Sin embargo, los recursos de red dedicados para cada cliente pueden ser necesarios para establecer una alta seguridad y cumplimiento. Por ejemplo, para admitir un alto grado de segmentación de red entre los clientes, se usan redes virtuales como límite. Los recursos dedicados pueden ser necesarios cuando el número de recursos de red en todos los clientes supera la capacidad de una sola red compartida.
Planee el número de recursos de red que necesitará cada cliente teniendo en cuenta los requisitos inmediatos y futuros. Los requisitos del cliente y los límites de recursos de Azure pueden forzar resultados específicos. Los distintos recursos pueden requerir estrategias de implementación diferentes, como el uso de redes independientes para el emparejamiento de redes virtuales con redes virtuales de Azure propiedad del cliente.
Para más información sobre cómo compartir recursos en una solución SaaS, consulte Organización de recursos para cargas de trabajo de SaaS.
Comprender las topologías de red. Las topologías de red normalmente se dividen en tres categorías:
Red plana: una única red aislada con subredes para la segmentación. Adecuado cuando tiene una sola aplicación multiinquilino con un diseño de red simple. Las redes planas pueden alcanzar los límites de recursos y requieren más redes a medida que se escala, lo que aumenta la sobrecarga y los costos. Si planea hospedar varias aplicaciones o usar sellos de implementación dedicados dentro de la misma red virtual, es posible que necesite un diseño de red complejo.
Concentrador y radio: una red de concentrador centralizada con emparejamiento con redes de radio aisladas. Adecuado para una alta escalabilidad y aislamiento de clientes, ya que cada cliente o aplicación tiene su propio radio, comunicándose solo con el concentrador. Puede implementar rápidamente más radios según sea necesario para que todos los radios puedan usar los recursos del centro. La comunicación transitiva o de radio a radio a través del concentrador está deshabilitada de forma predeterminada, lo que ayuda a mantener el aislamiento del cliente en las soluciones SaaS.
Sin red: se usa para los servicios PaaS de Azure, donde puede hospedar cargas de trabajo complejas sin implementar redes virtuales. Por ejemplo, App de Azure Service permite la integración directa con otros servicios PaaS a través de la red troncal de Azure. Aunque este enfoque simplifica la administración, restringe la flexibilidad en la implementación de controles de seguridad y la capacidad de optimizar el rendimiento. Este enfoque puede funcionar bien para aplicaciones nativas en la nube. A medida que la solución evoluciona, espere realizar la transición a una topología en estrella tipo hub-and-spoke a lo largo del tiempo.
Compensación: complejidad y seguridad. A partir de un límite de red definido, puede reducir la carga operativa de administrar componentes de red, como grupos de seguridad, espacio de direcciones IP y firewalls. Sin embargo, un perímetro de red es esencial para la mayoría de las cargas de trabajo. En ausencia de controles de seguridad de red, confíe en una sólida administración de identidades y acceso para proteger la carga de trabajo frente al tráfico malintencionado.
Comprenda cómo afecta la arquitectura de varias regiones a las topologías de red. En una arquitectura de varias regiones mediante redes virtuales, la mayoría de los recursos de red se implementan en cada región por separado, ya que los firewalls, las puertas de enlace de red virtual y los grupos de seguridad de red no se pueden compartir entre regiones.
Recomendaciones de diseño
Recomendación | Prestación |
---|---|
Decida qué componentes de red se comparten y qué componentes están dedicados al cliente. Comparta recursos que se cobran por instancia, como Azure Firewall, Azure Bastion y Azure Front Door. |
Experimente un soporte equilibrado entre los requisitos de seguridad y aislamiento, al tiempo que reduce el costo y la carga operativa. |
Comience con una topología plana o sin enfoque de red. Revise primero los requisitos de seguridad, ya que estos enfoques ofrecen un aislamiento limitado y controles de tráfico. |
Puede reducir la complejidad y el costo de la solución mediante topologías de red más sencillas. |
Considere la posibilidad de topologías en estrella tipo hub-and-spoke para necesidades complejas o al implementar redes virtuales dedicadas por cliente. Use el centro para hospedar recursos de red compartidos entre redes de clientes. | Puede escalar más fácilmente y mejorar su rentabilidad compartiendo recursos a través de la red central. |
Diseño de un perímetro de red seguro
El perímetro de red establece el límite de seguridad entre la aplicación y otras redes, incluido Internet. Al documentar el perímetro de red, puede distinguir entre diferentes tipos de flujos de tráfico:
- Tráfico de entrada, que llega a la red desde un origen externo.
- Tráfico interno, que va entre los componentes de la red.
- Tráfico de salida, que sale de la red.
Cada flujo implica diferentes riesgos y controles. Por ejemplo, se necesitan varios controles de seguridad para inspeccionar y procesar el tráfico de entrada.
Importante
Como procedimiento recomendado general, siga siempre un enfoque de confianza cero. Asegúrese de que todo el tráfico está controlado e inspeccionado, incluido el tráfico interno.
Los clientes también pueden tener requisitos de cumplimiento específicos que influyen en la arquitectura. Por ejemplo, si necesitan el cumplimiento de SOC 2, deben implementar varios controles de red, como un firewall, un firewall de aplicaciones web y grupos de seguridad de red, para cumplir los requisitos de seguridad. Incluso si no necesita cumplir inmediatamente, tenga en cuenta esos factores de extensibilidad al diseñar la arquitectura.
Consulte Recomendaciones de SE:06 para redes y conectividad.
Consideraciones de diseño
Proteja y administre el tráfico de entrada. Inspeccione este tráfico para detectar amenazas entrantes.
Los firewalls le permiten bloquear direcciones IP malintencionadas y completar análisis avanzados, para protegerse frente a intentos de intrusiones. Sin embargo, los firewalls pueden ser costosos. Evalúe los requisitos de seguridad para determinar si se requiere un firewall.
Las aplicaciones web son vulnerables a ataques comunes, como la inyección de código SQL, el scripting entre sitios y otras vulnerabilidades principales de OWASP. Azure Web Application Firewall protege contra esos ataques y se integra con Application Gateway y Azure Front Door. Revise los niveles de estos servicios para comprender qué funcionalidades de WAF están en qué productos.
Los ataques DDoS son un riesgo para las aplicaciones accesibles desde Internet. Azure proporciona un nivel básico de protección sin costo alguno. Azure DDoS Protection proporciona protección avanzada aprendiendo los patrones de tráfico y ajustando las protecciones según corresponda, aunque tienen un costo. Si usa Front Door, aproveche las funcionalidades de DDoS integradas.
Además de la seguridad, también puede manipular el tráfico de entrada para mejorar el rendimiento de la aplicación, mediante el almacenamiento en caché y el equilibrio de carga.
Considere la posibilidad de usar un servicio de proxy inverso como Azure Front Door para la administración global del tráfico HTTP(S). Como alternativa, use Application Gateway u otros servicios de Azure para el control de tráfico entrante. Para más información sobre las opciones de equilibrio de carga en Azure, consulte Opciones de equilibrio de carga.
Proteger el tráfico interno. Asegúrese de que el tráfico entre la aplicación y sus componentes es seguro para evitar el acceso malintencionado. Proteja estos recursos y mejore el rendimiento mediante el uso del tráfico interno en lugar de enrutar a través de Internet. Azure Private Link se usa normalmente para conectarse a los recursos de Azure a través de una dirección IP interna dentro de la red. Para algunos tipos de recursos, los puntos de conexión de servicio pueden ser una alternativa más rentable. Si habilita la conectividad a Internet pública para los recursos, comprenda cómo restringir el tráfico mediante direcciones IP e identidades de aplicación, como identidades administradas.
Proteger el tráfico de salida. En algunas soluciones, inspeccione el tráfico saliente para evitar la filtración de datos, especialmente para el cumplimiento normativo y los clientes empresariales. Use firewalls para administrar y revisar el tráfico de salida, bloqueando las conexiones a ubicaciones no autorizadas.
Planee cómo escalar horizontalmente la conectividad saliente y SNAT. El agotamiento de puertos de traducción de direcciones de red de origen (SNAT) puede afectar a las aplicaciones multiinquilino. Estas aplicaciones suelen necesitar conexiones de red distintas para cada inquilino y compartir recursos entre los clientes aumenta el riesgo de agotamiento de SNAT a medida que crece la base de clientes. Puede mitigar el agotamiento de SNAT mediante Azure NAT Gateway, firewalls como Azure Firewall o una combinación de los dos enfoques.
Recomendaciones de diseño
Recomendación | Prestación |
---|---|
Mantenga un catálogo de los puntos de conexión de red que se exponen a Internet. Capture detalles como la dirección IP (si es estática), el nombre de host, los puertos, los protocolos usados y la justificación de las conexiones. Documente cómo planea proteger cada punto de conexión. |
Esta lista forma la base de la definición del perímetro, lo que le permite tomar decisiones explícitas sobre la administración del tráfico a través de la solución. |
Conozca las funcionalidades del servicio de Azure para limitar el acceso y mejorar la protección. Por ejemplo, exponer puntos de conexión de cuenta de almacenamiento a los clientes requiere controles adicionales, como firmas de acceso compartido, firewalls de cuentas de almacenamiento y uso de cuentas de almacenamiento independientes para uso interno y externo. |
Puede seleccionar controles que satisfagan sus necesidades de seguridad, costo y rendimiento. |
En el caso de las aplicaciones basadas en HTTP(S), use un proxy inverso, como Azure Front Door o Application Gateway. | Los servidores proxy inversos proporcionan una amplia gama de funcionalidades para mejorar el rendimiento, la resistencia, la seguridad y reducir la complejidad operativa. |
Inspeccione el tráfico de entrada mediante un firewall de aplicaciones web. Evite exponer recursos basados en web como App Service o Azure Kubernetes Service (AKS) directamente a Internet. |
Puede proteger de forma más eficaz las aplicaciones web frente a amenazas comunes y reducir la exposición general de la solución. |
Proteja la aplicación frente a ataques DDoS. Use Azure Front Door o Azure DDoS Protection en función de los protocolos utilizados por los puntos de conexión públicos. |
Proteja la solución de un tipo común de ataque. |
Si la aplicación requiere conectividad de salida a escala, use NAT Gateway o un firewall para proporcionar puertos SNAT adicionales. | Puede admitir niveles más altos de escala. |
Conectividad entre redes
En algunos escenarios, es posible que tenga que conectarse a recursos externos a Azure, como datos dentro de la red privada o los recursos de un cliente en un proveedor de nube diferente en una configuración multinube. Estas necesidades pueden complicar el diseño de la red, lo que requiere varios enfoques para implementar la conectividad entre redes en función de sus requisitos específicos.
Consideraciones de diseño
Identifique los puntos de conexión a los que la aplicación necesita conexión. Es posible que la aplicación tenga que comunicarse con otros servicios, como los servicios de almacenamiento y las bases de datos. Documente su propietario, ubicación y tipo de conectividad. A continuación, puede elegir el método adecuado para conectarse a estos puntos de conexión. Entre los enfoques comunes se incluyen:
Ubicación del recurso Owner Opciones de conectividad que se deben tener en cuenta Azure Customer - Punto de conexión privado (entre inquilinos de Id. de Microsoft Entra)
- Emparejamiento de red virtual (entre inquilinos de Id. de Microsoft Entra)
- Punto de conexión de servicio (entre inquilinos de Id. de Microsoft Entra)
Otro proveedor de nube ISV o cliente - VPN de sitio a sitio
- ExpressRoute
- Internet
Local ISV o cliente - VPN de sitio a sitio
- ExpressRoute
- Internet
Private Link y punto de conexión privado. Proporcionar conectividad segura a varios recursos de Azure, incluidos equilibradores de carga internos para máquinas virtuales. Habilitan el acceso privado a la solución SaaS para los clientes, aunque incluyen consideraciones sobre los costos.
Compensación: seguridad y costo. Private Link garantiza que el tráfico permanece dentro de la red privada y se recomienda para la conectividad de red entre los inquilinos de Microsoft Entra. Sin embargo, cada punto de conexión privado incurre en costos, lo que puede agregarse en función de sus necesidades de seguridad. Los puntos de conexión de servicio pueden ser una alternativa rentable, manteniendo el tráfico en la red troncal de Microsoft, a la vez que proporciona algún nivel de conectividad privada.
Punto de conexión de servicio. Enruta el tráfico a los recursos de PaaS a través de la red troncal de Microsoft, protegiendo la comunicación entre servicios. Pueden ser rentables para las aplicaciones de alto ancho de banda, pero requieren la configuración y el mantenimiento de listas de control de acceso para la seguridad. La compatibilidad con los puntos de conexión de servicio en los inquilinos de Id. de Microsoft Entra varía según el servicio de Azure. Compruebe la documentación del producto para cada servicio que use.
El emparejamiento de redes virtuales conecta dos redes virtuales, lo que permite que los recursos de una red accedan a direcciones IP en la otra. Facilita la conectividad a los recursos privados de una red virtual de Azure. El acceso se puede administrar mediante grupos de seguridad de red, pero aplicar el aislamiento puede ser difícil. Por lo tanto, es importante planear la topología de red en función de las necesidades específicas del cliente.
Las redes privadas virtuales (VPN) crean un túnel seguro a través de Internet entre dos redes, incluidos los proveedores de nube y las ubicaciones locales. Las VPN de sitio a sitio usan dispositivos de red en cada red para la configuración. Ofrecen una opción de conectividad de bajo costo, pero requieren configuración y no garantizan un rendimiento predecible.
ExpressRoute proporciona una conexión privada dedicada, de alto rendimiento entre Azure y otros proveedores de nube o redes locales. Garantiza un rendimiento predecible y evita el tráfico de Internet, pero conlleva mayores costos y requiere una configuración más compleja.
Planee en función del destino. Es posible que tenga que conectarse a recursos en distintos inquilinos de Id. de Microsoft Entra, especialmente si el recurso de destino está en la suscripción de Azure de un cliente. Considere la posibilidad de usar puntos de conexión privados, una VPN de sitio a sitio o emparejando redes virtuales. Para obtener más información, consulte Emparejamiento de redes virtuales en distintos inquilinos de Microsoft Entra ID.
Para conectarse a los recursos hospedados en otro proveedor de nube, es habitual usar la conectividad a Internet pública, una VPN de sitio a sitio o ExpressRoute. Para más información, consulte Conectividad con otros proveedores de nube.
Comprenda los efectos de la conectividad en la topología de red. Una red virtual de Azure solo puede tener una puerta de enlace de red virtual, que puede conectarse a varias ubicaciones a través de VPN de sitio a sitio o ExpressRoute. Sin embargo, hay límites en el número de conexiones a través de una puerta de enlace y aislar el tráfico del cliente puede ser difícil. Para varias conexiones a diferentes ubicaciones, planee la topología de red en consecuencia, posiblemente mediante la implementación de una red virtual independiente para cada cliente.
Comprenda las implicaciones para el planeamiento de direcciones IP. Algunos enfoques de conectividad proporcionan automáticamente traducción de direcciones de red (NAT), evitando problemas con direcciones IP superpuestas. Sin embargo, el emparejamiento de redes virtuales y ExpressRoute no realizan NAT. Al usar estos métodos, planee cuidadosamente los recursos de red y las asignaciones de direcciones IP para evitar intervalos de direcciones IP superpuestos y garantizar el crecimiento futuro. El planeamiento de direcciones IP puede ser complejo, especialmente cuando se conecta a terceros como clientes, por lo que considere posibles conflictos con sus intervalos IP.
Comprender la facturación de salida de red. Azure normalmente factura el tráfico de red saliente cuando sale de la red de Microsoft o se mueve entre regiones de Azure. Al diseñar soluciones de varias regiones o multinube, es importante comprender las implicaciones de los costos. Las opciones de arquitectura, como el uso de Azure Front Door o ExpressRoute, pueden afectar a la forma en que se le factura el tráfico de red.
Recomendaciones de diseño
Recomendación | Prestación |
---|---|
Prefiere enfoques de redes privadas para conectarse entre redes para priorizar la seguridad. Considere la posibilidad de realizar el enrutamiento a través de Internet después de evaluar las implicaciones de seguridad y rendimiento asociadas. |
El tráfico privado atraviesa una ruta de acceso de red protegida, lo que ayuda a reducir muchos tipos de riesgos de seguridad. |
Al conectarse a los recursos del cliente hospedados en sus entornos de Azure, use Private Link, puntos de conexión de servicio o emparejamientos de red virtual. | Puede mantener el tráfico en la red de Microsoft, lo que ayuda a reducir el costo y la complejidad operativa en comparación con otros enfoques. |
Al conectarse entre proveedores de nube o a redes locales, use VPN de sitio a sitio o ExpressRoute. | Estas tecnologías proporcionan conexiones seguras entre proveedores. |
Implementación en entornos propiedad de los clientes
El modelo de negocio puede requerir que hospede la aplicación o sus componentes dentro del entorno de Azure de un cliente. El cliente administra su propia suscripción de Azure y paga directamente el costo de los recursos necesarios para ejecutar la aplicación. Como proveedor de soluciones, es responsable de administrar la solución, como la implementación inicial, la aplicación de la configuración y la implementación de actualizaciones en la aplicación.
En tales situaciones, los clientes suelen traer su propia red e implementar la aplicación en un espacio de red que definen. Las aplicaciones administradas de Azure ofrecen funcionalidades para facilitar este proceso. Para más información, consulte Uso de una red virtual existente con Aplicaciones administradas de Azure.
Consideraciones de diseño
Intervalos y conflictos de direcciones IP. Cuando los clientes implementan y administran redes virtuales, son responsables de controlar los conflictos de red y el escalado. Sin embargo, debe prever diferentes escenarios de uso de clientes. Planee implementaciones en entornos con un espacio mínimo de direcciones IP mediante direcciones IP de forma eficaz y evite intervalos de direcciones IP de codificación rígida para evitar superposiciones con intervalos de clientes.
Como alternativa, implemente una red virtual dedicada para la solución. Puede usar Private Link o emparejamiento de red virtual para permitir que los clientes se conecten a los recursos. Estos enfoques se describen en Conectividad entre redes. Si ha definido puntos de entrada y salida, evalúe NAT como un enfoque para eliminar los problemas causados por superposiciones de direcciones IP.
Proporcionar acceso a la red con fines de administración. Revise los recursos que implemente en entornos de cliente y planee cómo accederá a ellos para supervisar, administrar o volver a configurarlos. Cuando los recursos se implementan con direcciones IP privadas en un entorno propiedad del cliente, asegúrese de que tiene una ruta de acceso de red para acceder a ellos desde su propia red. Tenga en cuenta cómo facilita los cambios de aplicación y recursos, como insertar una nueva versión de la aplicación o actualizar una configuración de recursos de Azure.
En algunas soluciones, puede usar funcionalidades proporcionadas por Azure Managed Applications, como el acceso Just-In-Time y la implementación de actualizaciones en las aplicaciones. Si necesita más control, puede hospedar un punto de conexión dentro de la red del cliente a la que se puede conectar el plano de control, lo que proporciona acceso a los recursos. Este método requiere recursos y desarrollo adicionales de Azure para cumplir los requisitos de seguridad, operativos y de rendimiento. Para obtener un ejemplo de cómo implementar este enfoque, consulte Ejemplo de actualización de aplicaciones administradas de Azure.
Recomendaciones de diseño
Recomendación | Prestación |
---|---|
Use Azure Managed Applications para implementar y administrar recursos implementados por el cliente. | Las aplicaciones administradas de Azure proporcionan una variedad de funcionalidades que le permiten implementar y administrar recursos dentro de la suscripción de Azure de un cliente. |
Minimice el número de direcciones IP que consume dentro del espacio de red virtual del cliente. | A menudo, los clientes tienen disponibilidad restringida de direcciones IP. Al minimizar la superficie y desacoplar el escalado desde su uso de direcciones IP, puede ampliar el número de clientes que pueden usar la solución y habilitar mayores niveles de crecimiento. |
Planee cómo obtener acceso de red para administrar recursos en entornos de cliente, teniendo en cuenta la supervisión, los cambios en la configuración de recursos y las actualizaciones de aplicaciones. | Puede configurar directamente los recursos que administra. |
Decida si desea implementar una red virtual dedicada o integrarla con la red virtual existente de un cliente. | Al planear con antelación, asegúrese de que puede cumplir los requisitos de los clientes para el aislamiento, la seguridad y la integración con sus otros sistemas. |
De forma predeterminada, deshabilite el acceso público en los recursos de Azure. Prefiere la entrada privada siempre que sea posible. | Reducirá el ámbito de los recursos de red que usted y sus clientes necesitan proteger. |
Recursos adicionales
Multiinquilino es una metodología empresarial básica para diseñar cargas de trabajo de SaaS. Estos artículos proporcionan más información relacionada con el diseño de red:
- Enfoques de arquitectura para redes en soluciones multiinquilino
- Modelos de inquilinato
- Topología de red en estrella tipo hub-and-spoke
- Consideraciones de Azure NAT Gateway para la administración multiinquilino
- Enfoques arquitectónicos para la integración de inquilinos y el acceso a datos
Paso siguiente
Obtenga información sobre las consideraciones de la plataforma de datos para la integridad de los datos y el rendimiento de las cargas de trabajo de SaaS en Azure.