Migración y modernización de la ruta de diseño de redes

En esta guía se proporciona una ruta de lectura secuenciada a través de la guía de diseño de redes de Azure para los clientes que adoptan servicios de plataforma como servicio (PaaS), contenedores y bases de datos administradas. Siga los pasos numerados para crear una red multiregión y en capas de seguridad que admita arquitecturas de aplicaciones modernas.

Overview

Migración y modernización de proyectos se mueven más allá de las máquinas virtuales a servicios nativos de Azure: Azure Kubernetes Service (AKS) para contenedores, Azure App Service para aplicaciones web, Azure SQL Database y Azure Cosmos DB para los datos administrados y Azure Front Door para la distribución del tráfico global. La red debe permitir conectividad privada a estos servicios PaaS, implementaciones multirregión de tipo activo-activo y una segmentación de seguridad estricta entre los niveles de aplicación.

La arquitectura de destino usa una topología de doble centro que abarca dos regiones de Azure. Las VNets de centro administradas por TI alojan servicios compartidos como Azure Firewall y VPN Gateway. Los equipos de aplicaciones son propietarios de sus VNet de ramal y controlan sus propias subredes de Private Link para la conectividad PaaS. El tráfico entra a través de Azure Front Door o Azure Traffic Manager, pasa por la inspección del firewall del hub y llega a los servicios de aplicación que se ejecutan en spokes aislados.

Esta ruta de lectura le lleva a través de 14 artículos esenciales en cinco fases. El proceso es más largo que el lift and shift porque las arquitecturas modernas requieren tomar decisiones sobre patrones de entrada de tráfico, conectividad privada con PaaS, firewalls de aplicaciones web y protección contra DDoS que los diseños basados únicamente en IaaS pueden aplazar. Dos puntos de control clave le ayudan a identificar cuándo puede saltarse pasos si su carga de trabajo no necesita todos los componentes.

Prerequisites

  • Lea la información general sobre el planeamiento y el diseño de redes de Azure para orientarse sobre los servicios disponibles.
  • Sepa qué servicios paaS tienen como destino las aplicaciones (AKS, App Service, Azure SQL, Azure Cosmos DB u otros).
  • Determine si la implementación abarca varias regiones de Azure (activo-activo o activo-pasivo).
  • Identifique el patrón de entrada: ¿la aplicación atiende el tráfico web público, el tráfico de API móvil o el tráfico solo interno?

Ruta de lectura

Fase 1: Fundamentos

1. Redes virtuales y subredes

Dimensione las subredes para los grupos de nodos de AKS, las subredes delegadas de App Service Environment (ASE) y las subredes de Private Link. Cuando utiliza la superposición de la interfaz de red de contenedores (CNI) de AKS, las direcciones IP de los pods provienen de un CIDR de superposición independiente y no consumen espacio de subred de la VNet. Solo las direcciones IP de nodo requieren direcciones de subred. Planifica tu rango CIDR de superposición para adaptarlo a la escala de los pods y asigna subredes dedicadas para cada tipo de servicio.

2. Planificación de direcciones IP

Planifica la asignación de direcciones IP en dos regiones para una implementación activa-activa. Las regiones principales y de copia de seguridad necesitan espacios de direcciones no superpuestos que admitan el emparejamiento de VNet y la replicación entre regiones. Asigne rangos lo suficientemente amplios para acomodar futuras incorporaciones de spokes.

3. Grupos de seguridad de red y grupos de seguridad de aplicaciones

Diseñe una segmentación estricta para que solo el tráfico del equilibrador de carga alcance las subredes de la aplicación. Bloquear el acceso directo a Internet a los niveles de aplicación. Use grupos de seguridad de aplicaciones (ASG) para aplicar reglas basadas en el rol de carga de trabajo en lugar de direcciones IP individuales.

Fase 2: Topología

4. Topología hub-and-spoke

Implemente una topología de doble concentrador para varias regiones. La suscripción de TI es responsable de las VNet de los nodos centrales y administra servicios compartidos como Azure Firewall, la VPN Gateway y los reenviadores de DNS. Los equipos de aplicaciones son responsables de sus VNet de los nodos periféricos y administran las subredes de Private Link, los clústeres de AKS y los recursos de las aplicaciones dentro de su espacio de direcciones asignado.

5. Redes de varias regiones

Diseñar un despliegue activo-activo entre las regiones primaria y de respaldo. Configure el emparejamiento entre VNet de distintas regiones entre los nodos centrales, establezca el enrutamiento de conmutación por error y planifique para un error en una sola región. Ambas regiones gestionan el tráfico simultáneamente, y Azure Front Door distribuye las solicitudes en función de la latencia y los sondeos de estado.

Note

Hito: topología completada. La topología multirregional de concentrador doble ya está implementada. Si la aplicación es solo interna sin puntos de conexión accesibles desde Internet, puede ir directamente al paso 9 (acceso saliente a Internet) y continuar desde allí.

Lo que omite: Los pasos del 6 al 8 cubren la entrada de Internet, la entrega y el rendimiento de las aplicaciones y el acceso privado de PaaS. Omitirlo es seguro si la carga de trabajo no tiene puntos de conexión públicos ni requisitos de Private Link.

Importante: Incluso las aplicaciones solo internas suelen necesitar Private Link (paso 8) si se conectan a Azure SQL, Azure Storage, Azure Key Vault u otros servicios paaS a través de puntos de conexión privados. Si la aplicación usa cualquiera de estos servicios, complete el paso 8 antes de omitir el paso 9.

Artículos restantes: Seis artículos después de omitir (pasos 9–14), en comparación con nueve artículos sin omitir (pasos 6–14).

Fase 3: Conectividad

6. Entrada a Internet

Los patrones de tráfico orientados al cliente determinan la forma externa de la arquitectura. Use Azure Front Door para aplicaciones web que necesitan equilibrio de carga global, almacenamiento en caché y Web Application Firewall (WAF). Use Azure Traffic Manager para aplicaciones móviles o de API en las que el enrutamiento basado en DNS con sondeos de estado sea suficiente.

7. Entrega y rendimiento de la aplicación

Elija entre Azure Front Door y Azure Traffic Manager en función del tipo de aplicación. Las aplicaciones web se benefician de las funcionalidades de nivel 7 de Front Door: descarga de TLS, almacenamiento en caché, enrutamiento basado en direcciones URL y WAF integrado. Los backends móviles y de API utilizan Traffic Manager para la conmutación por error a nivel de DNS con una menor sobrecarga.

8. Acceso privado de PaaS

Crea subredes de Private Link en cada VNet spoke para la conectividad de los servicios PaaS. Los equipos de aplicaciones administran sus propios puntos de conexión privados: AKS extrae imágenes de contenedor a través de Private Link, las aplicaciones web se conectan a Azure SQL a través de puntos de conexión privados y ningún tráfico paaS atraviesa la red pública de Internet. Dedica una subred por cada red virtual spoke a los recursos de Private Link.

Note

Hito: conectividad completada. La conectividad de ingreso y la conectividad privada de PaaS están configuradas.

Pasos restantes: Salida saliente (paso 9), Azure Firewall (paso 10), Web Application Firewall (paso 11), protección contra DDoS (paso 12), seguridad dns (paso 13) y supervisión de red (paso 14), para un total de 6 artículos.

Imprescindible para todas las implementaciones: Los pasos 9 y 10 (tráfico saliente y Azure Firewall) se aplican a todas las implementaciones modernizadas. El firewall del centro controla todo el tráfico saliente y proporciona una inspección centralizada independientemente de si la carga de trabajo es pública o solo interna.

Solo puntos de conexión públicos: Los pasos 11 a 12 (protección contra WAF y DDoS) solo se aplican si la aplicación expone puntos de conexión orientados al público a través de Azure Front Door, Application Gateway o un Load Balancer público. Las cargas de trabajo de uso exclusivamente interno pueden omitir estos dos artículos y pasar al paso 13 (seguridad de DNS).

9. Acceso saliente a Internet

Enruta todo el tráfico saliente de los spokes al firewall del hub mediante rutas definidas por el usuario (UDR). El firewall del centro actúa como punto de traducción de direcciones de red de origen (SNAT) para todas las salidas. TI administra las reglas de firewall de forma centralizada, por lo que los equipos de aplicaciones no pueden omitir los controles salientes.

Fase 4: Seguridad

10. Azure Firewall

Configura Azure Firewall en ambas VNet del hub como punto de traducción de direcciones de red de origen (SNAT) y de destino (DNAT). Todo el tráfico de entrada pasa por el firewall antes de alcanzar el nivel de aplicación. Use políticas de cortafuegos para controlar el tráfico este-oeste entre ramales y el tráfico norte-sur hacia Internet.

11. Web Application Firewall

Implemente WAF en Azure Front Door o Azure Application Gateway para las aplicaciones web. WAF protege contra las 10 amenazas principales de Open Web Application Security Project (OWASP), inyección de código SQL, scripting entre sitios y otros ataques de capa HTTP. Use conjuntos de reglas administradas y agregue reglas personalizadas para los patrones específicos de la aplicación.

12. Protección contra DDoS

Habilite Azure DDoS Protection para todos los recursos de IP pública. DDoS Protection proporciona supervisión del tráfico siempre activa, mitigación automática de ataques y garantías de protección de costos. Combine la protección contra DDoS con un WAF para una defensa por capas contra ataques volumétricos y de capa de aplicación.

13. Seguridad DNS y resolución de nombres privados

Configure zonas DNS públicas para los dominios orientados al cliente con registros CNAME que apunte a Azure Front Door o puntos de conexión de Traffic Manager. Aplique Role-Based Access Control (RBAC) a zonas DNS para que solo los equipos autorizados puedan modificar registros. Habilite las extensiones de seguridad DNS (DNSSEC) para zonas que requieren validación criptográfica.

Fase 5: Operaciones

14. Supervisión de red y observabilidad

La preparación de producción requiere supervisión desde el primer día. Habilita Azure Network Watcher para el diagnóstico de conectividad, Network Monitor de rendimiento para la supervisión de la latencia y los registros de flujo para el análisis del tráfico. Los equipos de aplicaciones supervisan sus propias cargas de trabajo de AKS y ASE. El equipo de la plataforma supervisa la infraestructura del concentrador y la conectividad entre regiones.

Artículos condicionales

Incluya estos artículos en función de sus requisitos específicos:

Condition Artículo Cuándo incluir
Coexistencia híbrida Conectividad híbrida Las aplicaciones modernizadas deben coexistir con sistemas locales durante el período de transición
Acceso de administrador de máquina virtual necesario Acceso de desarrollador y administrador Su entorno incluye VM que necesitan acceso seguro mediante RDP/SSH, además de cargas de trabajo PaaS.
Gran dominio gestionado Administración de red centralizada Gestiona un entorno de VNets con varias suscripciones y varios equipos que requiere la aplicación centralizada de directivas.
Entre nubes Conectividad entre regiones y multinube La arquitectura requiere conectividad privada entre regiones explícita más allá de lo que proporcionan las redes de varias regiones.
Carga de trabajo muy pequeña Topología de red plana Tienes una única carga de trabajo que no justifica la complejidad de la topología hub-and-spoke

Resumen

Al seguir esta ruta de lectura, ha diseñado una arquitectura de red multiregión y en capas de seguridad para cargas de trabajo de PaaS. Su diseño incluye una topología de doble hub con servicios compartidos administrados por el departamento de TI, configuración multirregión activa-activa con Azure Front Door o Azure Traffic Manager, conectividad Private Link para servicios PaaS, inspección centralizada del firewall para todos los flujos de tráfico, protección WAF y contra DDoS para los puntos de conexión públicos, y DNS con RBAC y DNSSEC. Esta arquitectura admite patrones de aplicación modernos al tiempo que mantiene una gobernanza de seguridad centralizada.

Lista de comprobación de validación

Use esta lista de comprobación para confirmar que el diseño de redes de modernización está completo:

  • Topología de doble concentrador desplegada en las regiones primaria y de respaldo.
  • Espacios de direcciones no superpuestos asignados tanto para las regiones como para futuros spokes.
  • Azure Front Door o Azure Traffic Manager configurados para el tráfico de entrada global, si tu carga de trabajo está expuesta al público.
  • Subredes de Private Link aprovisionadas en cada VNet spoke que hospede dependencias de PaaS.
  • Las rutas definidas por el usuario envían el tráfico saliente de la red periférica a través del firewall del concentrador.
  • Azure Firewall implementado en ambas VNet hub para la inspección del tráfico de entrada, este-oeste y saliente.
  • Las políticas de WAF aplicadas a los puntos de conexión web de acceso público, si procede.
  • Protección contra DDoS habilitada en los recursos con IP pública, si procede.
  • Zonas DNS y resolución DNS privada configurada para puntos de conexión privados.
  • Network Watcher, registros de flujos y supervisión de la conectividad entre regiones habilitados.

Pasos siguientes

  • Last updated on