Topología de red hub-and-spoke

La topología de red hub-and-spoke es la arquitectura de red de Azure recomendada para entornos empresariales. Consta de una VNet de hub central que aloja servicios de red compartidos y varias VNets de spokes que alojan cargas de trabajo individuales. Los spokes se conectan al hub mediante el peering de VNet. Esta topología centraliza los controles de seguridad, reduce la complejidad de la red y escala de forma eficiente a medida que se agregan nuevas cargas de trabajo.

La VNet de hub es la red central a la que se conectan todas las VNets de spokes. Normalmente contiene:

• Azure Firewall — inspección centralizada del tráfico saliente y este-oeste
• VPN Gateway o ExpressRoute Gateway — conectividad con el entorno local
• Azure Bastion — acceso seguro mediante RDP/SSH a las máquinas virtuales sin direcciones IP públicas
• Azure DNS private zones — resolución DNS privada centralizada
• Recursos de supervisión de red — monitores de conexión y registros de flujo

Cada VNet de spoke aloja una sola carga de trabajo o un conjunto de cargas estrechamente relacionadas. Por ejemplo: Spoke 1 — aplicación web de producción; Spoke 2 — plataforma de análisis de datos; Spoke 3 — entorno de desarrollo y pruebas. Aislar las cargas de trabajo en spokes independientes proporciona un límite de red entre ellas. Si una carga de trabajo se ve comprometida, el atacante no puede desplazarse directamente a la VNet de otra carga sin pasar por el firewall del hub.

Las VNets de hub y de spokes se conectan mediante el peering de VNet, que proporciona conectividad privada y de baja latencia sin enrutar el tráfico a través de Internet público. Debe crear peerings en ambas direcciones: del hub al spoke y del spoke al hub. El tráfico entre spokes no se enruta directamente, sino que pasa por el hub, lo que permite al firewall del hub inspeccionar y controlar la comunicación entre spokes.

De forma predeterminada, el peering de VNet no obliga al tráfico a pasar por Azure Firewall, sino que lo enruta directamente entre las VNets. Para inspeccionar el tráfico entre spokes y el tráfico de los spokes a Internet a través del firewall del hub, debe configurar User Defined Routes (UDRs) en cada subred de spoke, de modo que apunten la puerta de enlace predeterminada (0.0.0.0/0) a la dirección IP privada del firewall. Esto garantiza que todo el tráfico saliente de los spokes sea filtrado por el firewall centralizado.

Azure Firewall en la VNet de hub proporciona seguridad de red centralizada para todos los spokes. Admite:

• Reglas de red — permiten o deniegan según la IP, el puerto y el protocolo
• Reglas de aplicación — permiten o deniegan según el FQDN y la categoría HTTP
• Reglas DNAT — traducen las IP públicas entrantes a IP privadas de los backends
• Inteligencia sobre amenazas — bloquea el tráfico hacia o desde IP y dominios maliciosos conocidos

Un solo Azure Firewall puede prestar servicio a todas las VNets de spokes, lo que reduce el coste y la carga administrativa de implementar firewalls individuales para cada spoke.

El DNS centralizado es fundamental en una arquitectura hub-and-spoke. Implemente Azure DNS private zones vinculadas a la VNet de hub y configure las VNets de spokes para que usen los servidores DNS del hub (o el DNS proporcionado por Azure con registro automático). Esto garantiza que las máquinas virtuales de todos los spokes puedan resolver los nombres de las demás y los nombres de los servicios PaaS de Azure mediante private endpoints, usando una configuración DNS coherente.

Una de las principales ventajas de hub-and-spoke es que la conectividad con el entorno local se centraliza en el hub. Una única VPN Gateway o ExpressRoute Gateway en la VNet de hub proporciona conectividad para que todas las cargas de trabajo de los spokes accedan a los sistemas locales. Las cargas de trabajo de los spokes no necesitan sus propias puertas de enlace: acceden a los recursos locales a través de la puerta de enlace del hub mediante peering, lo que reduce significativamente el coste y la complejidad.

Hub-and-spoke escala de forma natural: agregar una nueva carga de trabajo implica crear una nueva VNet de spoke, establecer el peering con el hub y aplicar la UDR para enrutar el tráfico a través del firewall del hub. Los servicios del hub (firewall, puerta de enlace, DNS y Bastion) se comparten entre todos los spokes. Azure Virtual WAN es el servicio hub-and-spoke administrado de Microsoft, que automatiza la administración del peering, el enrutamiento y las puertas de enlace en implementaciones muy grandes con muchas VNets de spokes.

Una red plana (una única VNet grande con todo distribuido en subredes) es más sencilla al principio, pero se vuelve difícil de administrar y proteger a escala. En una red plana, todas las cargas de trabajo comparten el mismo espacio de direcciones y solo están separadas por NSG. Hub-and-spoke proporciona un aislamiento mayor (los límites de las VNets son más difíciles de atravesar que las reglas de NSG), controles de seguridad centralizados y una gobernanza más clara, ya que cada spoke se puede administrar de forma independiente.

Los principales costes de hub-and-spoke, además de los recursos de las cargas de trabajo, son:

• Azure Firewall — se cobra por hora de implementación, además de una tarifa por el procesamiento de datos
• VPN/ExpressRoute Gateway — se cobra por hora de puerta de enlace, además del ancho de banda
• Peering de VNet — se cobra por cada GB de datos transferidos a través de los enlaces de peering

A pesar de estos costes, centralizar los servicios en el hub suele ser más económico que implementar firewalls, puertas de enlace y servidores DNS independientes en cada spoke.

Compruebe su comprensión de los conceptos de Microsoft Azure Fundamentals (AZ-900) tratados en esta lección.

En esta lección ha aprendido que la topología hub-and-spoke centraliza los servicios de red compartidos (firewall, puerta de enlace y DNS) en una VNet de hub, mientras que las cargas de trabajo se encuentran en VNets de spokes independientes; que el peering de VNet conecta los spokes con el hub y las UDR enrutan el tráfico a través del firewall del hub; y que esta arquitectura escala de forma eficiente al compartir los servicios de plataforma entre todos los spokes. A continuación, exploraremos el diseño de identidad y acceso empresarial con RBAC y Privileged Identity Management.