Implementación de una red híbrida segura

Firewall
Load Balancer
Virtual Machines
Virtual Network

Esta arquitectura de referencia muestra una red híbrida segura que extiende una red local a Azure. La arquitectura implementa una red perimetral, entre la red local y una red virtual. Todo el tráfico entrante y saliente pasa a través de Azure Firewall.

Arquitectura de red híbrida segura

Descargue un archivo Visio de esta arquitectura.

Implementación de referencia

Esta implementación crea dos grupos de recursos: la primera contiene una red local ficticia, la segunda un conjunto de redes con topología en estrella tipo hub-and-spoke. La red local ficticia y la red del centro de conectividad 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 al modo en que conectaría su centro de datos local a Azure.

Esta implementación puede tardar hasta 45 minutos en completarse. El método de implementación recomendado consiste en usar la opción de portal que se indica a continuación.

Use el botón siguiente para implementar la referencia mediante Azure Portal.

Implementación en Azure

Una vez completada la implementación, compruebe la conectividad de sitio a sitio examinando los recursos de conexión recién creados. En Azure Portal, busque "conexiones" y observe el estado de cada conexión.

Captura de pantalla que muestra el estado de las conexiones.

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 la máquina virtual mediante el host de Azure Bastion incluido, abra un explorador web y vaya a la dirección del equilibrador de carga de la red de la aplicación.

Para obtener información detallada y otras opciones de implementación, consulte las plantillas de ARM que se usaron para implementar esta solución.

Casos de uso

Esta arquitectura requiere una conexión a su centro de datos local, mediante una puerta de enlace VPN o una conexión ExpressRoute. Los usos habituales de esta arquitectura incluyen:

  • Aplicaciones híbridas donde una parte de las cargas de trabajo se ejecutan de forma local y otra parte 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. Esto suele ser un requisito de regulación de muchos sistemas comerciales y puede ayudar a evitar la revelación de información privada.

Architecture

La arquitectura consta de los siguientes componentes:

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

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

  • 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.

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

    • En la subred de puerta de enlace, el tráfico enviado a la subred de nivel web (10.0.1.0/24) se enruta a través de la instancia de Azure Firewall.
    • En la subred de nivel web, puesto que no hay ninguna ruta para el espacio de direcciones de la propia VNet para que apunte a Azure Firewall, las instancias de nivel web pueden comunicarse directamente entre sí, no a través 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.

  • Grupos de seguridad de red. Use grupos de seguridad para restringir el tráfico de red dentro de la red virtual. Por ejemplo, en la implementación que se proporciona con esta arquitectura de referencia, la subred de nivel web permite el tráfico TCP desde la red local y desde dentro de la red virtual, el nivel de negocio permite el tráfico desde el nivel web y la capa de datos permite el tráfico desde el nivel empresarial.

  • Bastion. Azure Bastion permite iniciar sesión en las máquinas virtuales de la red virtual a través de SSH o el protocolo de escritorio remoto (RDP) sin exponer las máquinas virtuales directamente a Internet. Use Bastion para administrar las máquinas virtuales de la red virtual.

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

Use el control de acceso basado en rol de Azure (Azure RBAC) para administrar los recursos de la 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 las aplicaciones y supervisar y reiniciar las máquinas virtuales.

  • 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.

Los roles de administrador de DevOps y de TI no deberían tener acceso a los recursos de firewall. Debería limitarse al rol de administrador de TI de seguridad.

Recomendaciones para grupos de recursos

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

Se recomienda crear los grupos de recursos siguientes:

  • Un grupo de recursos que contenga la red virtual (excepto las máquinas virtuales), los grupos de seguridad de red y los recursos de puerta de enlace para conectarse a la red local. Asigne el rol de administrador de TI centralizado a este grupo de recursos.
  • Un grupo de recursos que contenga las máquinas virtuales para 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.
  • Separe los grupos de recursos para cada nivel de aplicación que contenga el equilibrador de carga y las máquinas virtuales. Tenga en cuenta que este grupo de recursos no debe incluir las subredes de cada nivel. Asigne el rol de DevOps a este grupo de recursos.

Recomendaciones de redes

Para aceptar el tráfico entrante desde Internet, agregue una regla de traducción de direcciones de red de destino (DNAT) a Azure Firewall.

  • Dirección de destino = dirección IP pública de la instancia de firewall.
  • Dirección traducida = dirección IP privada dentro de la red virtual.

La implementación de ejemplo enruta el tráfico de Internet para el puerto 80 al equilibrador de carga de nivel web.

Aplique tunelización forzada a todo el tráfico saliente de Internet a través de la red local mediante el túnel VPN de sitio a sitio para enrutar a Internet con la traducción de direcciones de red (NAT). Así se evita la pérdida accidental de la información confidencial almacenada en el nivel de datos y se permite la inspección y auditoría de todo el tráfico saliente.

No bloquee por completo el tráfico de Internet de las capas de aplicación, ya que esto evitará que estas capas usen los servicios PaaS de Azure que se basan en direcciones IP públicas, como el registro de diagnóstico de máquina virtual, la descarga de extensiones de máquina virtual y otras funciones. Los diagnósticos de Azure también requieren que los componentes puedan leer y escribir en una cuenta de Azure Storage.

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 sobre escalabilidad

Para información detallada sobre los límites de ancho de banda de VPN Gateway, consulte SKU de puerta de enlace. 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 acerca de la escalabilidad de las puertas de enlace de Azure, vea la sección sobre la consideración de la escalabilidad en Implementación de una arquitectura de red híbrida con Azure y VPN local e Implementación de una arquitectura de red híbrida con Azure ExpressRoute.

Consideraciones sobre disponibilidad

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

Para obtener información específica sobre el mantenimiento de la disponibilidad para conexiones VPN y ExpressRoute, consulte las consideraciones de disponibilidad en Implementación de una arquitectura de red híbrida con Azure y VPN local e Implementación de una arquitectura de red híbrida con Azure ExpressRoute.

Consideraciones sobre la manejabilidad

Si la conectividad de la puerta de enlace desde la red local a Azure está inactiva, puede acceder a las máquinas virtuales de la red virtual de Azure a través de Azure Bastion.

La subred de cada nivel de la arquitectura de referencia está protegido por las reglas de NSG. Debe crear una regla para abrir el puerto 3389 para el acceso del Protocolo de escritorio remoto (RDP) en las máquinas virtuales Windows o el puerto 22 para el acceso de shell seguro (SSH) en las máquinas virtuales Linux. Otras herramientas de supervisión y administración pueden requerir reglas para abrir puertos adicionales.

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

En el artículo sobre la implementación de una arquitectura de red híbrida con Azure y una VPN local, puede encontrar más información sobre la supervisión y administración de conexiones VPN y ExpressRoute.

Consideraciones sobre la 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, y estas solicitudes se pasan a la aplicación 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.

Grupos de seguridad de red para bloquear o permitir el tráfico entre los niveles de aplicación

El tráfico entre niveles se restringe mediante grupos de seguridad de red (NSG). El nivel empresarial bloquea todo el tráfico que no se origina en el nivel web y el de datos bloquea todo el tráfico que no se origina en el nivel empresarial. Si necesita expandir las reglas de NSG a fin de permitir un mayor acceso a estos niveles, 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.

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.

Consideraciones sobre el costo

Puede usar la calculadora de precios de Azure para calcular los costos. Otras consideraciones se describen en la sección Costo de Marco de buena arquitectura de Microsoft Azure.

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 de la puerta de enlace y la subred en la que se ejecuta la capa de aplicación. De esta manera, Azure Firewall es rentable porque se usa como una solución compartida utilizada por varias cargas de trabajo. Estos son los modelos de precios de 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 un 30 o 50 %. Para más información, consulte Azure Firewall frente a aplicación virtual de red.

Azure Bastion

Azure Bastion se conecta de forma segura a la máquina virtual a través de RDP y SSH sin necesidad de configurar una dirección IP pública en la máquina virtual.

La facturación de Bastion es comparable a una máquina virtual básica de bajo nivel configurada como Jumpbox. De la comparación de Bastion con Jumpbox se desprende que Bastion es más rentable debido a sus características de seguridad integradas y que no se producen costos adicionales por el almacenamiento y la administración de un servidor independiente.

Azure Virtual Network

Azure Virtual Network es gratis. A cada suscripción se le permite crear un máximo de 50 redes virtuales en todas las regiones. Todo el tráfico que produce dentro de los límites de una red virtual es gratis. Por tanto, si dos máquinas virtuales que se encuentran en la misma red virtual se comunican entre sí, no se producirán cargos.

Equilibrador de carga interno

El equilibrio de carga básico entre máquinas virtuales que residen en la misma red virtual es gratuito.

En esta arquitectura, los equilibradores de carga internos se usan para equilibrar la carga del tráfico dentro de una red virtual.

Pasos siguientes