Esta arquitectura de referencia muestra una red híbrida segura que extiende una red local a Azure. La arquitectura implementa una red perimetral, también llamada DMZ entre la red local y una red virtual de Azure. Todo el tráfico entrante y saliente pasa a través de Azure Firewall.
Architecture
Descargue un archivo Visio de esta arquitectura.
Componentes
La arquitectura consta de los siguientes aspectos:
Red local. Una red de área local privada implementada en una organización.
Red virtual de Azure. La red virtual hospeda los componentes de soluciones y otros recursos que se ejecutan en Azure.
Las rutas de red virtual definen el flujo de tráfico IP dentro de la red virtual de Azure. En el diagrama, hay dos tablas de rutas definidas por el usuario.
En la subred de 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.
Azure Bastion. Azure Bastion permite iniciar sesión en las máquinas virtuales de la red virtual mediante 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.
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 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. 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
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.
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 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 red virtual de radios que contenga el equilibrador de carga y las máquinas virtuales.
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.
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). 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 red de radio. Si bloquea el tráfico, impedirá que estos recursos 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
Estas consideraciones implementan los pilares del marco de buena arquitectura de Azure, que es un conjunto de principios guía que se pueden usar para mejorar la calidad de una carga de trabajo. Para más información, consulte Marco de buena arquitectura de Microsoft Azure.
Eficiencia del rendimiento
La eficiencia del rendimiento es la capacidad de la carga de trabajo para escalar con el fin de satisfacer de manera eficiente las demandas que los usuarios hayan ejercido sobre ella. Para obtener más información, vea Resumen del pilar de eficiencia del rendimiento.
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 sobre la escalabilidad de las puertas de enlace de Azure, consulte las secciones de consideraciones de escalabilidad en:
- Implementación de una arquitectura de red híbrida con Azure y una VPN local
- Implementación de una arquitectura de red híbrida con Azure ExpressRoute
Para más información sobre la administración de redes virtuales y grupos de seguridad de red a escala, consulte Tutorial: Creación de una red radial para crear nuevas topologías de red virtual radiales (e incorporar las existentes) para la administración central de las reglas de conectividad y NSG.
Confiabilidad
La confiabilidad garantiza que la aplicación pueda cumplir los compromisos contraídos con los clientes. Para más información, consulte Resumen del pilar de fiabilidad.
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 sobre cómo mantener la disponibilidad de las conexiones de VPN y ExpressRoute, consulte las consideraciones de disponibilidad en:
- Implementación de una arquitectura de red híbrida con Azure y una VPN local
- Implementación de una arquitectura de red híbrida con Azure ExpressRoute
Excelencia operativa
La excelencia operativa abarca los procesos de las operaciones que implementan una aplicación y la mantienen en ejecución en producción. Para más información, consulte Introducción al pilar de excelencia operativa.
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.
Seguridad
La seguridad proporciona garantías contra ataques deliberados y el abuso de datos y sistemas valiosos. Para más información, consulte Introducción al pilar 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 subredes de recursos de redes virtuales de radio y desde estas 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 características mejoradas de mitigación de DDoS para ofrecer una mejor defensa frente a los ataques DDoS. Debe habilitar 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 librarse sin problemas de los cambios importantes de estas configuraciones en los entornos radiales.
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 trata de buscar formas de reducir los gastos innecesarios y mejorar las eficiencias operativas. Para más información, vea Información general del pilar de optimización de costos.
Puede usar la calculadora de precios de Azure para calcular los costos. Se describen otras consideraciones en la sección de optimización de costos 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 los recursos de las redes virtuales de radio. 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 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.
Azure Virtual Network
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, las máquinas virtuales de la misma red virtual que se comuniquen entre sí no incurren en cargos de tráfico de red.
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.
Implementación de este escenario
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.
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.
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 ver otras opciones de implementación, consulte las plantillas de Azure Resource Manager (plantillas de ARM) que se usaron para implementar esta solución: Red híbrida segura.