Implementación de una red híbrida segura

Azure Firewall
Equilibrador de carga de Azure
Azure Virtual Machines
Azure Virtual Network

Esta arquitectura de referencia muestra una red híbrida segura que extiende una red local a Azure. La arquitectura implementa una red perimeter también denominada DMZ, entre la red local y una red virtual Azure. Todo el tráfico entrante y saliente pasa por Azure Firewall.

Arquitectura

Diagrama que muestra la arquitectura de una red híbrida segura.

Descargue un archivo Visio de esta arquitectura.

Componentes

La arquitectura consta de los siguientes aspectos:

  • Red en las instalaciones. Una red de área local privada implementada en una organización.

  • Red virtual de Azure. La red virtual hospeda los componentes de la solución y otros recursos que se ejecutan en Azure.

    Rutas de red virtual definir el flujo de tráfico IP dentro de la red virtual Azure. En el diagrama, hay dos tablas de rutas definidas por el usuario.

    En la subred de la puerta de enlace, el tráfico se enruta a través de la instancia de Azure Firewall.

    Nota:

    Según los requisitos de la conexión VPN, puede configurar las rutas del Protocolo de puerta de enlace de borde (BGP) para implementar las reglas de reenvío que dirigen el tráfico a través de la red local.

  • Puerta de enlace. La puerta de enlace proporciona conectividad entre los enrutadores de la red local y la red virtual. La puerta de enlace se coloca en su propia subred.

  • Azure Firewall. Azure Firewall es un firewall administrado como servicio. La instancia de Firewall se coloca en su propia subred.

  • Grupos de seguridad de red. Use grupos de seguridad para restringir el tráfico de red dentro de la red virtual.

  • Conjuntos de escalado de máquinas virtuales. Virtual Machine Scale Sets proporcionan la capa de proceso en las redes virtuales periféricas. Los conjuntos de escalado implementan y administran un grupo de máquinas virtuales idénticas detrás del equilibrador de carga interno y admiten el escalado automático para que coincida con la demanda.

  • Azure Bastion. Azure Bastion proporciona acceso seguro mediante SSH y RDP a instancias del conjunto de escalado de máquinas virtuales sin exponerlas a Internet. Use Bastion para administrar las instancias de la red virtual.

    Bastion requiere una subred dedicada llamada AzureBastionSubnet.

Posibles casos de uso

Esta arquitectura requiere una conexión al centro de datos local mediante una puerta de enlace de VPN o una conexión expressRoute. Los usos habituales de esta arquitectura incluyen:

  • Aplicaciones híbridas en las que las cargas de trabajo se ejecutan parcialmente en el entorno local y parcialmente en Azure.
  • Infraestructura que requiere un control pormenorizado sobre el tráfico que entra en una red virtual de Azure desde un centro de datos local.
  • Aplicaciones que deben auditar el tráfico saliente. La auditoría suele ser un requisito de regulación de muchos sistemas comerciales y puede ayudar a evitar la revelación de información privada.

Recomendaciones

Las siguientes recomendaciones sirven para la mayoría de los escenarios. Sígalas a menos que tenga un requisito concreto que las invalide.

Recomendaciones de control de acceso

Utilice Azure control de acceso basado en rol (Azure RBAC) para administrar los recursos de su aplicación. Considere la posibilidad de crear los siguientes roles personalizados:

  • Un rol de DevOps con permisos para administrar la infraestructura de la aplicación, implementar los componentes de la aplicación y administrar operaciones del conjunto de escalado de máquinas virtuales, como el escalado, la reimposición y las actualizaciones.

  • Un rol de administrador de TI centralizado para administrar y supervisar los recursos de red.

  • Un rol de administrador de TI de seguridad para administrar los recursos de red seguros, como el firewall.

El rol de administrador de TI no debería tener acceso a los recursos de firewall. El acceso debería limitarse al rol de administrador de TI de seguridad.

Recomendaciones para grupos de recursos

Los recursos de Azure, como los conjuntos de escalado de máquinas virtuales, las redes virtuales y los equilibradores de carga, se pueden administrar agrupándolos en grupos de recursos. Asigne Azure roles a cada grupo de recursos para restringir el acceso.

Se recomienda crear los grupos de recursos siguientes:

  • Un grupo de recursos que contiene la red virtual (excepto los recursos de proceso), los grupos de seguridad de red y los recursos de la puerta de enlace para conectarse a la red local de la organización. Asigne el rol de administrador de TI centralizado a este grupo de recursos.
  • Un grupo de recursos que contiene los recursos de la instancia de Azure Firewall y las rutas definidas por el usuario para la subred de puerta de enlace. Asigne el rol de administrador de TI de seguridad a este grupo de recursos.
  • Grupos de recursos independientes para cada red virtual spoke que contenga el equilibrador de carga y los conjuntos de escalado de máquinas virtuales.

Recomendaciones de redes

En esta arquitectura, todo el tráfico entrante y saliente entre la red local, Internet y las redes virtuales radiales pasa a través de Azure Firewall. Cada flujo que cruza el perímetro se somete a la traducción de direcciones de red en el firewall, por lo que las direcciones IP del firewall, no las de la carga de trabajo, son lo que observan los sistemas externos y los sistemas locales. Planifique las siguientes acciones:

  • Las cargas de trabajo publicadas son accesibles en la dirección IP pública del firewall, no en la dirección IP de la carga de trabajo. Publique un back-end con una regla de traducción de direcciones de red de destino (DNAT) en el firewall. La dirección de destino es la dirección IP pública del firewall; la dirección traducida es una dirección IP privada dentro de la red virtual.

  • Los flujos salientes abandonan el perímetro utilizando como origen una de las direcciones IP públicas del firewall. Azure Firewall selecciona aleatoriamente la dirección IP pública adjunta que se usará para cada flujo de salida, por lo que las listas de permitidos de asociados, las reglas de firewall locales y los registros de auditoría deben cubrir todo el conjunto de direcciones IP asociadas al firewall. Use un prefijo de dirección IP pública para expresarlo como un intervalo contiguo.

    El número de direcciones IP públicas asociadas al firewall también determina cuántas conexiones salientes simultáneas se pueden mantener antes de que se agoten los puertos de traducción de direcciones de red de origen (SNAT).

  • Los back-end no ven la dirección IP del cliente original. Azure Firewall también aplica SNAT en paquetes que coinciden con una regla DNAT, por lo que el tráfico vuelve a pasar a través de la misma instancia de firewall. El back-end observa la dirección IP de la instancia del firewall como origen.

    Si la aplicación requiere la dirección IP del cliente, finalice la conexión del cliente hacia arriba en un proxy inverso, como Azure Application Gateway o Azure Front Door, reenvíe la dirección IP del cliente en el encabezado HTTP X-Forwarded-For y siga Preservar el nombre de host HTTP original por lo que el back-end sigue observando el nombre de host del cliente.

Force-tunnel todo el tráfico de Internet saliente a través de la red local mediante el túnel VPN de sitio a sitio. El dispositivo perimetral local realiza SNAT en Internet en nombre de las cargas de trabajo de Azure, que enruta los flujos salientes a través de los controles de salida locales existentes y la canalización de auditoría. Este diseño evita la pérdida accidental de la información confidencial y se permite la inspección y auditoría de todo el tráfico saliente.

No bloquee completamente el tráfico de Internet de los recursos de las subredes de la red spoke. Bloquear el tráfico impedirá que estos recursos usen Azure servicios PaaS que se basan en direcciones IP públicas, como el registro de diagnósticos, el aprovisionamiento de extensiones de máquina virtual y sus dependencias y otras funcionalidades de plataforma. Diagnósticos de Azure también requiere que los componentes puedan leer y escribir en una cuenta de almacenamiento de Azure.

Compruebe que el tráfico saliente de Internet se realiza correctamente a través de tunelización forzada. Si utiliza una conexión VPN con el servicio de acceso remoto y enrutamiento en un servidor local, use una herramienta como WireShark.

Considere la posibilidad de usar Application Gateway o Azure Front Door para la terminación SSL.

Consideraciones

Estas consideraciones implementan los pilares del marco de Azure Well-Architected, que es un conjunto de principios rectores que se pueden usar para mejorar la calidad de una carga de trabajo. Para obtener más información, consulte Microsoft Azure Well-Architected Framework.

Confiabilidad

La confiabilidad garantiza que la aplicación pueda cumplir los compromisos contraídos con los clientes. Para obtener más información, consulte Lista de comprobación de revisión de diseño para confiabilidad.

Si está utilizando Azure ExpressRoute para proporcionar conectividad entre la red virtual y la red local, configure una puerta de enlace de VPN para proporcionar conmutación por error si la conexión de ExpressRoute deja de estar disponible.

Para obtener información sobre cómo mantener la disponibilidad de las conexiones de VPN y ExpressRoute, consulte las consideraciones de disponibilidad en:

Seguridad

La seguridad proporciona garantías contra ataques deliberados y el abuso de datos y sistemas valiosos. Para obtener más información, vea Lista de comprobación para la revisión de diseño de seguridad.

Esta arquitectura de referencia implementa varios niveles de seguridad.

Enrutamiento de todas las solicitudes de usuario locales a través de Azure Firewall

La ruta definida por el usuario en la subred de puerta de enlace bloquea todas las solicitudes de usuario distintas de las recibidas desde el entorno local. La ruta pasa las solicitudes permitidas al firewall. Las solicitudes se pasan a los recursos de las redes virtuales de radio si las reglas de firewall lo permiten. Puede agregar otras rutas, pero debe asegurarse de que no omiten accidentalmente el firewall ni bloquean el tráfico administrativo destinado a la subred de administración.

Uso de grupos de seguridad de red para bloquear o pasar el tráfico a subredes de la red virtual radial

El tráfico hacia y desde las subredes de recursos en redes virtuales satélite se restringe mediante grupos de seguridad de red. Si necesita expandir las reglas de NSG a fin de permitir un mayor acceso a estos recursos, sopese estos requisitos con respecto a los riesgos de seguridad. Cada nueva ruta de entrada representa una oportunidad para que se produzca la pérdida accidental o intencionada de datos o la aplicación resulte dañada.

Protección frente a DDOS

Azure DDoS Protection, combinado con los procedimientos recomendados de diseño de aplicaciones, proporciona una mitigación mejorada frente a ataques DDoS. Habilite Azure DDoS Protection en cualquier red virtual perimetral.

Uso de AVNM para crear reglas de administración de seguridad de base de referencia

AVNM permite crear bases de referencia de reglas de seguridad, que pueden tener prioridad sobre las reglas del grupo de seguridad de red. Las reglas de administración de seguridad se evalúan antes que las reglas del grupo de seguridad de red y tienen la misma naturaleza, admiten la priorización, las etiquetas de servicio y los protocolos L3-L4. AVNM permite que el departamento de TI central aplique una línea base de reglas de seguridad, al tiempo que permite una independencia de reglas de NSG adicionales por parte de los propietarios de la red virtual de radio. Para facilitar el lanzamiento controlado de cambios en las reglas de seguridad, la característica de implementación de AVNM le permite liberar de manera segura los cambios disruptivos de estas configuraciones en los entornos de concentrador y periferia.

Acceso de DevOps

Use Azure RBAC para restringir las operaciones que DevOps puede realizar en cada nivel. Al conceder permisos, use el principio de los privilegios mínimos. Registre todas las operaciones administrativas y realice auditorías periódicas para asegurarse de que los cambios de configuración se habían planeado.

Optimización de costos

La optimización de costos consiste en examinar formas de reducir los gastos innecesarios y mejorar las eficiencias operativas. Para obtener más información, consulte Lista de comprobación de revisión de diseño para la optimización de costes.

Use esta estimación preconfigured en la calculadora de precios de Azure como punto de partida para calcular los costos de su escenario. Incluye los componentes de red descritos en este artículo con máquinas virtuales de ejemplo.

Estas son las consideraciones de costo de los servicios que se usan en esta arquitectura.

Azure Firewall

En esta arquitectura, Azure Firewall se implementa en la red virtual para controlar el tráfico entre la subred del gateway y los recursos de las redes virtuales de satélite. El uso de Azure Firewall como solución compartida en varias cargas de trabajo puede ayudar a reducir la infraestructura duplicada. Estos son los modelos de precios Azure Firewall:

  • Tarifa fija por hora de implementación.
  • Datos procesados por GB para admitir el escalado automático.

En comparación con las aplicaciones virtuales de red (NVA), con Azure Firewall puede ahorrar hasta 30-50%. Para obtener más información, consulte Azure Firewall vs NVA.

Azure Bastion

Azure Bastion permite conectarse de forma segura a instancias de conjuntos de escalado de máquinas virtuales a través de RDP y SSH sin que las instancias necesiten una dirección IP pública.

La facturación de Bastion es comparable a una máquina virtual básica de bajo nivel configurada como un jumpbox. Bastion es más rentable que un jumpbox, ya que tiene características de seguridad integradas y no incurre en costos adicionales para el almacenamiento y la administración de un servidor independiente.

Red virtual de Azure

Azure Virtual Network es gratis. A cada suscripción se le permite crear un máximo de 1,000 redes virtuales en todas las regiones. Todo el tráfico que produce dentro de los límites de una red virtual es gratis. Por ejemplo, el tráfico del equilibrador de carga interno a las instancias del conjunto de escalado de máquinas virtuales no genera cargos por tráfico de red.

Equilibrador de carga interno

En esta arquitectura, los equilibradores de carga internos se usan para distribuir el tráfico a las instancias del conjunto de escalado de máquinas virtuales dentro de una red virtual. Standard Load Balancer es necesario para su uso con conjuntos de escalado de máquinas virtuales.

Excelencia operativa

La excelencia operativa abarca los procesos de operaciones que implementan una aplicación y lo mantienen en ejecución en producción. Para obtener más información, consulte la Lista de comprobación de revisión de diseño para la excelencia operativa.

Si la conectividad de puerta de enlace de la red local a Azure está inactiva, puede seguir usando Azure Bastion para acceder a los recursos de la red virtual de Azure para solucionar problemas. Dado que las instancias del conjunto de escalado de máquinas virtuales son efímeras, confíe en el registro y la supervisión centralizados a través de Azure Monitor y diagnósticos de arranque en lugar de sesiones remotas interactivas para las operaciones rutinarias.

La subred de cada nivel de la arquitectura de referencia está protegidas por las reglas del NSG. Las herramientas de administración y supervisión pueden requerir reglas para abrir puertos adicionales.

Si usa ExpressRoute para proporcionar la conectividad entre el centro de datos local y el Azure, use la Azure Connectivity Toolkit (AzureCT) para supervisar y solucionar problemas de conexión.

Puede encontrar información adicional sobre la supervisión y administración de conexiones VPN y ExpressRoute en el artículo Implementar una arquitectura de red híbrida con Azure y VPN local.

Eficiencia del rendimiento

La eficiencia del rendimiento es la capacidad de la carga de trabajo para escalar a fin de satisfacer las demandas que los usuarios ponen en ella de forma eficaz. Para obtener más información, consulte Lista de comprobación de revisión de diseño para la eficiencia del rendimiento.

Los conjuntos de escalado de máquinas virtuales en las redes periféricas admiten el escalado automático. Configure reglas de escalado automático basadas en métricas como el uso de CPU o el recuento de solicitudes para que las instancias se agreguen o quiten en respuesta a la demanda. Elija un modo de orquestación y una directiva de actualización que coincida con la tolerancia de la carga de trabajo para la interrupción durante las actualizaciones.

Para obtener más información sobre los límites de ancho de banda de VPN Gateway, consulte Gateway SKU. Para anchos de banda mayores, considere la posibilidad de actualizar a una puerta de enlace de ExpressRoute. ExpressRoute proporciona hasta 10 GB/s de ancho de banda con una latencia inferior que una conexión VPN.

Para más información sobre la escalabilidad de las puertas de enlace de Azure, consulte las secciones de consideraciones de escalabilidad en:

Para obtener más información sobre la administración de redes virtuales y grupos de seguridad de red a escala, consulte Azure Virtual Network Manager (AVNM): Creación de una red de concentrador y radio protegida para crear nuevas topologías de red virtual de concentrador y radio (y adaptar las existentes) para la gestión centralizada de la conectividad y las reglas de los grupos de seguridad de red.

Implementación de este escenario

Esta implementación crea dos grupos de recursos: el primero contiene una red local ficticia y el segundo un conjunto de redes con topología de estrella tipo hub-and-spoke. La red local ficticia y la red central están conectadas mediante puertas de enlace de Azure Virtual Network para formar una conexión de sitio a sitio. Esta configuración es muy similar a cómo conectaría el centro de datos local a Azure.

Esta implementación puede tardar hasta 45 minutos en completarse.

Ejecute el siguiente comando para implementar dos grupos de recursos y la arquitectura de referencia de red segura mediante el CLI de Azure.

Cuando se le solicite, escriba los valores de un nombre de usuario administrador, una contraseña y una clave compartida de VPN. Las credenciales de administrador se usan como credenciales predeterminadas para las instancias del conjunto de escalado de máquinas virtuales. La clave compartida autentica la conexión VPN de sitio a sitio entre las puertas de enlace.

az deployment sub create --location eastus \
    --template-uri https://raw.githubusercontent.com/mspnp/samples/main/solutions/secure-hybrid-network/azuredeploy.bicep

Una vez finalizada la implementación, compruebe la conectividad de sitio a sitio examinando los recursos de conexión recién creados. En el portal de Azure, busque connections y compruebe el estado de cada conexión.

Captura de pantalla que muestra el estado de las conexiones.

Añadir reglas DNAT del firewall

Una vez que el estado de conexión de sitio a sitio muestra Conectado, actualice el firewall del concentrador con reglas DNAT para que el tráfico local pueda llegar a las cargas de trabajo de radio.

FW_IP=$(az network firewall show -g rg-site-to-site-azure-network-eastus2 -n AzureFirewall --query "ipConfigurations[0].privateIPAddress" -o tsv)
LB_IP=$(az network lb frontend-ip list -g rg-site-to-site-azure-network-eastus2 --lb-name lb-internal --query "[0].privateIPAddress" -o tsv)

az deployment group create -n firewallDnat -g rg-site-to-site-azure-network-eastus2 \
    --template-uri https://raw.githubusercontent.com/mspnp/samples/main/solutions/secure-hybrid-network/nestedtemplates/azure-network-azuredeploy-v2.bicep \
    -p firewallName=AzureFirewall firewallPrivateIp=$FW_IP internalLoadBalancerPrivateIp=$LB_IP

Se puede acceder a la instancia de IIS que se encuentra en la red radial desde la máquina virtual ubicada en la red local ficticia. Cree una conexión a esa máquina virtual mediante el host de Azure Bastion incluido, abra un explorador web y vaya a la dirección del equilibrador de carga interno de la aplicación.

Para obtener más información y otras opciones de implementación, consulte las plantillas de Bicep que se usan para implementar esta solución: Secure Hybrid Network.

Pasos siguientes