Firewall y Application Gateway para redes virtuales

Para proteger las cargas de trabajo de aplicaciones de Azure, debe usar medidas de protección, como la autenticación y el cifrado, en las propias aplicaciones. También puede agregar capas de seguridad a las redes virtuales (VNet) que hospedan las aplicaciones. Estas capas de seguridad protegen los flujos entrantes de la aplicación frente al uso no deseado. También limitan los flujos salientes a Internet solo a esos puntos de conexión que requiere la aplicación. En este artículo se describe Azure Virtual Network servicios de seguridad como Azure DDoS Protection, Azure Firewall y Azure Application Gateway, cuándo usar cada servicio y opciones de diseño de red que combinan ambos.

• Azure DDoS Protection, combinado con los procedimientos recomendados de diseño de aplicaciones, proporciona características mejoradas de mitigación de DDoS para proporcionar más defensa contra ataques DDoS. Debe habilitar azure DDOS Protection en cualquier red virtual perimetral.
• azure Firewall es un firewall administrado de próxima generación que ofrece traducción de direcciones de red (NAT). Azure Firewall basa el filtrado de paquetes en las direcciones del Protocolo de Internet (IP) y los puertos protocolo de control de transmisión y protocolo de datagrama de usuario (TCP/UDP), o en los atributos HTTP(S) o SQL basados en la aplicación. Azure Firewall también aplica inteligencia sobre amenazas de Microsoft para identificar direcciones IP malintencionadas. Para más información, consulte la documentación de Azure Firewall.
• Azure Firewall Premium incluye todas las funciones de Azure Firewall Estándar y otras características, como la inspección de TLS y el sistema de detección y protección de intrusiones (IDPS).
• azure Application Gateway es un equilibrador de carga de tráfico web administrado y un proxy inverso completo HTTP(S) que pueden realizar cifrado y descifrado de capa de sockets seguros (SSL). Application Gateway conserva la dirección IP del cliente original en un encabezado HTTP deForwarded-For X. Application Gateway también usa el firewall de aplicaciones web para inspeccionar el tráfico web y detectar ataques en la capa HTTP. Para más información, consulte la documentación de Application Gateway.
• azure Web Application Firewall (WAF) es una adición opcional a Azure Application Gateway. Proporciona inspección de solicitudes HTTP y evita ataques malintencionados en la capa web, como inyección de código SQL o scripting entre sitios. Para obtener más información, consulte la documentación del firewall de aplicaciones web de .

Estos servicios de Azure son complementarios. Una u otra puede ser la mejor para las cargas de trabajo, o puede usarlas juntas para una protección óptima en las capas de red y aplicación. Use el siguiente árbol de decisión y los ejemplos de este artículo para determinar la mejor opción de seguridad para la red virtual de la aplicación.

Azure Firewall y Azure Application Gateway usan diferentes tecnologías y admiten la titulización de flujos diferentes:

En función de los flujos de red que requiera una aplicación, el diseño puede ser diferente por aplicación. En el diagrama siguiente se ofrece un árbol de decisión simplificado que ayuda a elegir el enfoque recomendado para una aplicación. La decisión depende de si la aplicación se publica a través de HTTP(S) o de algún otro protocolo:

En este artículo se tratarán los diseños ampliamente recomendados del gráfico de flujo y otros que se aplican en escenarios menos comunes:

• solo Azure Firewall, cuando no hay ninguna aplicación web en la red virtual. Controlará el tráfico entrante tanto a las aplicaciones como al tráfico saliente.
• solo Application Gateway, cuando solo las aplicaciones web están en la red virtual y grupos de seguridad de red (NSG) proporcionan un filtrado de salida suficiente. Las funcionalidades proporcionadas por Azure Firewall pueden evitar muchos escenarios de ataque (como la filtración de datos, IDPS, etc.). Debido a este motivo, el escenario solo de Application Gateway no se recomienda normalmente y, por lo tanto, no está documentado y no está en el gráfico de flujo anterior.
• Azure Firewall y Application Gateway en paralelo, que es uno de los diseños más comunes. Use esta combinación cuando quiera que Azure Application Gateway proteja las aplicaciones HTTP(S) de ataques web y Azure Firewall para proteger todas las demás cargas de trabajo y filtrar el tráfico saliente.
• Application Gateway delante de Azure Firewall, cuando quiera que Azure Firewall inspeccione todo el tráfico, WAF para proteger el tráfico web y la aplicación para conocer la dirección IP de origen del cliente. Con la inspección de Azure Firewall Premium y TLS, este diseño también admite el escenario SSL de un extremo a otro.
• Azure Firewall delante de Application Gateway, cuando quiera que Azure Firewall inspeccione y filtre el tráfico antes de que llegue a Application Gateway. Dado que Azure Firewall no va a descifrar el tráfico HTTPS, la funcionalidad que agrega a Application Gateway es limitada. Este escenario no se documenta en el gráfico de flujo anterior.

En la última parte de este artículo, se describen las variaciones de los diseños fundamentales anteriores. Estas variaciones incluyen:

• clientes de aplicaciones locales.
• redes de concentrador y radio.
• implementaciones de de Azure Kubernetes Service (AKS).

Puede agregar otros servicios de proxy inverso como una puerta de enlace de API Management o azure Front Door. O bien, puede reemplazar los recursos de Azure por aplicaciones virtuales de red de terceros .

Solo Azure Firewall

Si no hay ninguna carga de trabajo basada en web en la red virtual que pueda beneficiarse de WAF, solo puede usar Azure Firewall. El diseño en este caso es sencillo, pero revisar el flujo de paquetes ayudará a comprender diseños más complejos. En este diseño, todo el tráfico entrante se envía a Azure Firewall a través de rutas definidas por el usuario (UDR) para las conexiones desde el entorno local u otras redes virtuales de Azure. Se dirige a la dirección IP pública de Azure Firewall para las conexiones desde la red pública de Internet, como se muestra en el diagrama siguiente. El tráfico saliente de las redes virtuales de Azure se envía al firewall a través de UDR, como se muestra en el cuadro de diálogo siguiente.

En la tabla siguiente se resumen los flujos de tráfico de este escenario:

Azure Firewall no inspeccionará el tráfico HTTP(S) entrante. Pero podrá aplicar reglas de aplicación basadas en FQDN de capa 3 & capa 4. Azure Firewall inspeccionará el tráfico HTTP(S) saliente en función del nivel de Azure Firewall y de si configura la inspección de TLS:

• Azure Firewall Standard solo inspeccionará los atributos de nivel 3 & nivel 4 de los paquetes en las reglas de red y el encabezado HTTP del host en las reglas de aplicación.
• Azure Firewall Premium agrega funcionalidades como inspeccionar otros encabezados HTTP (como el User-Agent) y habilitar la inspección de TLS para un análisis de paquetes más profundo. Azure Firewall no es equivalente a un firewall de aplicaciones web. Si tiene cargas de trabajo web en la red virtual, se recomienda encarecidamente usar WAF.

En el siguiente ejemplo de tutorial de paquetes se muestra cómo un cliente accede a una aplicación hospedada en máquina virtual desde la red pública de Internet. El diagrama incluye solo una máquina virtual por motivos de simplicidad. Para obtener una mayor disponibilidad y escalabilidad, tendría varias instancias de aplicación detrás de un equilibrador de carga. En este diseño, Azure Firewall inspecciona las conexiones entrantes desde la red pública de Internet y las conexiones salientes de la máquina virtual de la subred de la aplicación mediante el UDR.

• El servicio Azure Firewall implementa varias instancias en segundo plano, aquí con la dirección IP de front-end 192.168.100.4 y las direcciones internas del intervalo 192.168.100.0/26. Estas instancias individuales normalmente son invisibles para el administrador de Azure. Pero notar la diferencia es útil en algunos casos, como al solucionar problemas de red.
• Si el tráfico procede de una red privada virtual (VPN) local o puerta de enlace de Azure ExpressRoute en lugar de Internet, el cliente inicia la conexión a la dirección IP de la máquina virtual. No inicia la conexión a la dirección IP del firewall y el firewall no realizará nat de origen por valor predeterminado.

Arquitectura

En el diagrama siguiente se muestra el flujo de tráfico suponiendo que la dirección IP de la instancia es 192.168.100.7.

Flujo de trabajo

1. El cliente inicia la conexión a la dirección IP pública de Azure Firewall:
   • Dirección IP de origen: ClientPIP
   • Dirección IP de destino: AzFwPIP
2. La solicitud a la dirección IP pública de Azure Firewall se distribuye a una instancia de back-end del firewall, en este caso 192.168.100.7. La regla NAT de destino (DNAT) de Azure Firewall traduce la dirección IP de destino a la dirección IP de la aplicación dentro de la red virtual. Azure Firewall también nats de origen (SNAT) el paquete si lo hace DNAT. Para más información, consulte problemas conocidos de Azure Firewall. La máquina virtual ve las siguientes direcciones IP en el paquete entrante:
   • Dirección IP de origen: 192.168.100.7
   • Dirección IP de destino: 192.168.1.4
3. La máquina virtual responde a la solicitud de la aplicación, lo que invierte las direcciones IP de origen y destino. El flujo de entrada no requiere un ruta definida por el usuario (UDR), ya que la dirección IP de origen es la dirección IP de Azure Firewall. La UDR del diagrama de 0.0.0.0.0/0 es para las conexiones salientes, para asegurarse de que los paquetes a la red pública de Internet pasan por Azure Firewall.
   • Dirección IP de origen: 192.168.1.4
   • Dirección IP de destino: 192.168.100.7
4. Por último, Azure Firewall deshace las operaciones SNAT y DNAT y entrega la respuesta al cliente:
   • Dirección IP de origen: AzFwPIP
   • Dirección IP de destino: ClientPIP

Solo Application Gateway

Este diseño cubre la situación en la que solo existen aplicaciones web en la red virtual e inspeccionar el tráfico saliente con NSG es suficiente para proteger los flujos salientes a Internet.

La principal diferencia del diseño anterior con solo Azure Firewall es que Application Gateway no actúa como un dispositivo de enrutamiento con NAT. Se comporta como un proxy de aplicación inversa completo. Es decir, Application Gateway detiene la sesión web del cliente y establece una sesión independiente con uno de sus servidores back-end. Las conexiones HTTP(S) entrantes desde Internet deben enviarse a la dirección IP pública de Application Gateway, las conexiones desde Azure o local a la dirección IP privada de la puerta de enlace. Devolver el tráfico de las máquinas virtuales de Azure seguirá el enrutamiento de red virtual estándar a Application Gateway (consulte el tutorial del paquete para obtener más detalles). Los flujos salientes de Internet desde máquinas virtuales de Azure irán directamente a Internet.

En la tabla siguiente se resumen los flujos de tráfico:

Arquitectura

En el siguiente ejemplo de tutorial de paquetes se muestra cómo un cliente accede a la aplicación hospedada en máquina virtual desde la red pública de Internet.

Flujo de trabajo

1. El cliente inicia la conexión a la dirección IP pública de Azure Application Gateway:
   • Dirección IP de origen: ClientPIP
   • Dirección IP de destino: AppGwPIP
2. La solicitud a la dirección IP pública de Application Gateway se distribuye a una instancia de back-end de la puerta de enlace, en este caso 192.168.200.7. La instancia de Application Gateway que recibe la solicitud detiene la conexión del cliente y establece una nueva conexión con uno de los back-end. El back-end ve la instancia de Application Gateway como la dirección IP de origen. Application Gateway inserta un encabezado HTTP X-Forwarded-For con la dirección IP del cliente original.
   • Dirección IP de origen: 192.168.200.7 (la dirección IP privada de la instancia de Application Gateway)
   • Dirección IP de destino: 192.168.1.4
   • Encabezado X-Forwarded-For: ClientPIP
3. La máquina virtual responde a la solicitud de la aplicación, lo que invierte las direcciones IP de origen y destino. La máquina virtual ya sabe cómo llegar a Application Gateway, por lo que no necesita una UDR.
   • Dirección IP de origen: 192.168.1.4
   • Dirección IP de destino: 192.168.200.7
4. Por último, la instancia de Application Gateway responde al cliente:
   • Dirección IP de origen: AppGwPIP
   • Dirección IP de destino: ClientPIP

Azure Application Gateway agrega metadatos a los encabezados HTTP del paquete, como el encabezado X-Forwarded-For que contiene la dirección IP del cliente original. Algunos servidores de aplicaciones necesitan la dirección IP del cliente de origen para servir contenido específico de la geolocalización o para el registro. Para obtener más información, consulte Funcionamiento de una puerta de enlace de aplicaciones.

• La dirección IP 192.168.200.7 es una de las instancias que implementa el servicio Azure Application Gateway en segundo plano, aquí con la dirección IP de front-end privada interna 192.168.200.4. Estas instancias individuales normalmente son invisibles para el administrador de Azure. Pero notar la diferencia es útil en algunos casos, como al solucionar problemas de red.

• El flujo es similar si el cliente procede de una red local a través de una puerta de enlace vpn o ExpressRoute. La diferencia es que el cliente accede a la dirección IP privada de Application Gateway en lugar de a la dirección pública.

Firewall y Application Gateway en paralelo

Debido a su simplicidad y flexibilidad, la ejecución de Application Gateway y Azure Firewall en paralelo suele ser el mejor escenario.

Implemente este diseño si hay una combinación de cargas de trabajo web y no web en la red virtual. Azure WAF en Azure Application Gateway protege el tráfico entrante a las cargas de trabajo web y Azure Firewall inspecciona el tráfico entrante de las otras aplicaciones. Azure Firewall abarcará los flujos salientes de ambos tipos de carga de trabajo.

Las conexiones HTTP(S) entrantes desde Internet deben enviarse a la dirección IP pública de las conexiones de Application Gateway, HTTP(S) desde Azure o local a su dirección IP privada. El enrutamiento de red virtual estándar enviará los paquetes desde Application Gateway a las máquinas virtuales de destino, así como desde las máquinas virtuales de destino a Application Gateway (consulte el tutorial de paquetes para obtener más información). Para las conexiones entrantes que no son HTTP(S), el tráfico debe tener como destino la dirección IP pública de Azure Firewall (si procede de la red pública de Internet), o se enviará a través de Azure Firewall mediante udR (si procede de otras redes virtuales de Azure o redes locales). Todos los flujos salientes de las máquinas virtuales de Azure se reenviarán a Azure Firewall mediante UDR.

En la tabla siguiente se resumen los flujos de tráfico de este escenario:

Este diseño proporciona un filtrado de salida mucho más granular que los grupos de seguridad de red. Por ejemplo, si las aplicaciones necesitan conectividad con una cuenta de Azure Storage específica, puede usar nombre de dominio completo (FQDN)filtros basados en . Con los filtros basados en FQDN, las aplicaciones no envían datos a cuentas de almacenamiento no autorizadas. Ese escenario no se pudo evitar simplemente mediante el uso de grupos de seguridad de red. Este diseño se usa a menudo cuando el tráfico saliente requiere filtrado basado en FQDN. Una situación de ejemplo es cuando limitar el tráfico de salida de un clúster de Azure Kubernetes Services.

Arquitecturas

En el diagrama siguiente se muestra el flujo de tráfico para las conexiones HTTP(S) entrantes desde un cliente externo:

En el diagrama siguiente se muestra el flujo de tráfico para las conexiones salientes de las máquinas virtuales de red a Internet. Un ejemplo es conectarse a sistemas back-end o obtener actualizaciones del sistema operativo:

Los pasos de flujo de paquetes para cada servicio son los mismos que en las opciones de diseño independientes anteriores.

Application Gateway antes del firewall

Este diseño se explica con más detalle en red de confianza cero para aplicaciones web con Azure Firewall y Application Gateway, este documento se centrará en la comparación con las otras opciones de diseño. En esta topología, el tráfico web entrante pasa por Azure Firewall y WAF. Waf proporciona protección en el nivel de aplicación web. Azure Firewall actúa como un punto de control y registro central, e inspecciona el tráfico entre Application Gateway y los servidores back-end. Application Gateway y Azure Firewall no se encuentran en paralelo, sino uno después del otro.

Con Azure Firewall Premium, este diseño puede admitir escenarios de un extremo a otro, donde Azure Firewall aplica la inspección de TLS para realizar IDPS en el tráfico cifrado entre Application Gateway y el back-end web.

Este diseño es adecuado para las aplicaciones que necesitan conocer las direcciones IP de origen de cliente entrantes, por ejemplo, para servir contenido específico de la geolocalización o para el registro. Application Gateway delante de Azure Firewall captura la dirección IP de origen del paquete entrante en el encabezado X-forwarded-for, por lo que el servidor web puede ver la dirección IP original en este encabezado. Para obtener más información, consulte Funcionamiento de una puerta de enlace de aplicaciones.

Las conexiones HTTP(S) entrantes desde Internet deben enviarse a la dirección IP pública de las conexiones de Application Gateway, HTTP(S) desde Azure o local a la dirección IP privada. En las UDR de Application Gateway se asegurará de que los paquetes se enrutan a través de Azure Firewall (consulte el tutorial de paquetes para obtener más detalles). Para las conexiones entrantes que no son HTTP(S), el tráfico debe tener como destino la dirección IP pública de Azure Firewall (si procede de la red pública de Internet), o se enviará a través de Azure Firewall mediante udR (si procede de otras redes virtuales de Azure o redes locales). Todos los flujos salientes de las máquinas virtuales de Azure se reenviarán a Azure Firewall mediante UDR.

Un comentario importante de este diseño es que Azure Firewall Premium verá el tráfico con una dirección IP de origen desde la subred de Application Gateway. Si esta subred está configurada con una dirección IP privada (en 10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12 o 100.64.0.0/10), Azure Firewall Premium tratará el tráfico de Application Gateway como interno y no aplicará reglas IDPS para el tráfico entrante. Puede encontrar más información sobre las instrucciones de las reglas de IDPS de Azure Firewall y los prefijos ip privados para IDPS en reglas de IDPS de Azure Firewall. Por lo tanto, se recomienda modificar los prefijos privados de IDPS en la directiva de Azure Firewall para que la subred de Application Gateway no se considere un origen interno, para aplicar firmas IDPS entrantes y salientes al tráfico.

En la tabla siguiente se resumen los flujos de tráfico de este escenario:

En el caso del tráfico web desde el entorno local o desde Internet a Azure, Azure Firewall inspeccionará los flujos que el WAF ya ha permitido. En función de si Application Gateway cifra el tráfico de back-end (tráfico de Application Gateway a los servidores de aplicaciones), tendrá diferentes escenarios potenciales:

1. Application Gateway cifra el tráfico siguiendo los principios de confianza cero (cifrado TLS de un extremo a otro) y Azure Firewall recibirá tráfico cifrado. Sin embargo, Azure Firewall Standard podrá aplicar reglas de inspección, como el filtrado de nivel 3 & nivel 4 en las reglas de red o el filtrado de FQDN en las reglas de aplicación mediante el encabezado Indicación de nombre de servidor TLS (SNI). Azure Firewall Premium proporciona una mayor visibilidad con la inspección de TLS, como el filtrado basado en direcciones URL.
2. Si Application Gateway envía tráfico sin cifrar a los servidores de aplicaciones, Azure Firewall verá el tráfico entrante en texto no cifrado. La inspección de TLS no es necesaria en Azure Firewall.
3. Si IDPS está habilitado en Azure Firewall, comprobará que el encabezado host HTTP coincide con la dirección IP de destino. Con ese propósito, necesitará resolución de nombres para el FQDN especificado en el encabezado Host. Esta resolución de nombres se puede lograr con zonas privadas de Azure DNS y la configuración predeterminada de DNS de Azure Firewall mediante Azure DNS. También se puede lograr con servidores DNS personalizados que deben configurarse en la configuración de Azure Firewall. (Para más información, consulte configuración de DNS de Azure Firewall). Si no hay acceso administrativo a la red virtual donde se implementa Azure Firewall, este último método es la única posibilidad. Un ejemplo es con Azure Firewalls implementados en centros protegidos de Virtual WAN.

Arquitectura

Para el resto de los flujos (tráfico entrante que no sea HTTP y cualquier tráfico saliente), Azure Firewall proporcionará la inspección de IDPS y la inspección de TLS cuando corresponda. También proporciona filtrado basado en FQDN en reglas de red basadas en DNS.

Flujo de trabajo

El tráfico de red desde la red pública de Internet sigue este flujo:

1. El cliente inicia la conexión a la dirección IP pública de Azure Application Gateway:
   • Dirección IP de origen: ClientPIP
   • Dirección IP de destino: AppGwPIP
2. La solicitud a la dirección IP pública de Application Gateway se distribuye a una instancia de back-end de la puerta de enlace, en este caso 192.168.200.7. La instancia de Application Gateway detiene la conexión del cliente y establece una nueva conexión con uno de los back-end. La UDR para 192.168.1.0/24 en la subred de Application Gateway reenvía el paquete a Azure Firewall, a la vez que conserva la dirección IP de destino en la aplicación web:
   • Dirección IP de origen: 192.168.200.7 (dirección IP privada de la instancia de Application Gateway)
   • Dirección IP de destino: 192.168.1.4
   • Encabezado X-Forwarded-For: ClientPIP
3. Azure Firewall no SNAT el tráfico, ya que el tráfico va a una dirección IP privada. Reenvía el tráfico a la máquina virtual de la aplicación si las reglas lo permiten. Para más información, consulte SNAT de Azure Firewall. Sin embargo, si el tráfico alcanza una regla de aplicación en el firewall, la carga de trabajo verá la dirección IP de origen de la instancia de firewall específica que procesó el paquete, ya que Azure Firewall proxyá la conexión:
   • Dirección IP de origen si una regla de red de Azure Firewall permite el tráfico: 192.168.200.7 (la dirección IP privada de una de las instancias de Application Gateway).
   • Dirección IP de origen si una regla de aplicación de Azure Firewall permite el tráfico: 192.168.100.7 (la dirección IP privada de una de las instancias de Azure Firewall).
   • Dirección IP de destino: 192.168.1.4
   • Encabezado X-Forwarded-For: ClientPIP
4. La máquina virtual responde a la solicitud, revierte las direcciones IP de origen y destino. La UDR para 192.168.200.0/24 captura el paquete enviado de vuelta a Application Gateway y lo redirige a Azure Firewall, a la vez que conserva la dirección IP de destino hacia Application Gateway.
   • Dirección IP de origen: 192.168.1.4
   • Dirección IP de destino: 192.168.200.7
5. Aquí de nuevo Azure Firewall no SNAT el tráfico, ya que va a una dirección IP privada y reenvía el tráfico a Application Gateway.
   • Dirección IP de origen: 192.168.1.4
   • Dirección IP de destino: 192.168.200.7
6. Por último, la instancia de Application Gateway responde al cliente:
   • Dirección IP de origen: AppGwPIP
   • Dirección IP de destino: ClientPIP

Los flujos salientes de las máquinas virtuales a la red pública de Internet pasan por Azure Firewall, tal como se define en la UDR para 0.0.0.0/0.

Application Gateway después del firewall

Este diseño permite que Azure Firewall filtre y descarte el tráfico malintencionado antes de llegar a Application Gateway. Por ejemplo, puede aplicar características como el filtrado basado en inteligencia sobre amenazas. Otra ventaja es que la aplicación obtiene la misma dirección IP pública para el tráfico entrante y saliente, independientemente del protocolo. Sin embargo, Azure Firewall SNAT el tráfico entrante, por lo que la aplicación no tendrá visibilidad sobre la dirección IP original de las solicitudes HTTP. Desde la perspectiva de la administración, por ejemplo, con fines de solución de problemas, puede obtener la dirección IP de cliente real para una conexión específica mediante la correlación con los registros SNAT de Azure Firewall.

Hay una ventaja limitada en este escenario, ya que Azure Firewall solo verá el tráfico cifrado que va a Application Gateway. Puede haber escenarios en los que se prefiera este diseño. Un caso es si otro WAF es anterior en la red (por ejemplo, con Azure Front Door), lo que podría capturar la dirección IP de origen original en el encabezado HTTP de X-Forwarded-For. O bien, se prefiere el diseño si se requieren muchas direcciones IP públicas.

Los flujos entrantes HTTP(S) desde la red pública de Internet deben tener como destino la dirección IP pública de Azure Firewall y Azure Firewall DNAT (y SNAT) los paquetes a la dirección IP privada de Application Gateway. Desde otras redes virtuales de Azure o redes locales, el tráfico HTTP(S) debe enviarse a la dirección IP privada de Application Gateway y reenviarse a través de Azure Firewall con UDR. El enrutamiento de red virtual estándar se asegurará de que el tráfico devuelto de las máquinas virtuales de Azure vuelva a Application Gateway y de Application Gateway a Azure Firewall si se usaron reglas DNAT. Para el tráfico desde el entorno local o las UDR de Azure en la subred de Application Gateway se debe usar (consulte el tutorial de paquetes para obtener más detalles). Todos los tráficos salientes de las máquinas virtuales de Azure a Internet se enviarán a través de Azure Firewall mediante udR.

En la tabla siguiente se resumen los flujos de tráfico de este escenario:

En el caso del tráfico HTTP(S) entrante, Azure Firewall normalmente no descifraría el tráfico. En su lugar, aplicaría directivas IDPS que no requieren inspección de TLS, como el filtrado basado en IP o el uso de encabezados HTTP.

Arquitectura

La aplicación no puede ver la dirección IP de origen original del tráfico web; los SNAT de Azure Firewall a medida que entran en la red virtual. Para evitar este problema, use azure Front Door delante del firewall. Azure Front Door inserta la dirección IP del cliente como un encabezado HTTP antes de entrar en la red virtual de Azure.

Flujo de trabajo

El tráfico de red desde la red pública de Internet sigue este flujo:

1. El cliente inicia la conexión a la dirección IP pública de Azure Firewall:
   • Dirección IP de origen: ClientPIP
   • Dirección IP de destino: AzFWPIP
2. La solicitud a la dirección IP pública de Azure Firewall se distribuye a una instancia de back-end del firewall, en este caso 192.168.100.7. Los DNAT de Azure Firewall son el puerto web, normalmente TCP 443, en la dirección IP privada de la instancia de Application Gateway. Azure Firewall también SNAT al realizar DNAT. Para más información, consulte problemas conocidos de Azure Firewall:
   • Dirección IP de origen: 192.168.100.7 (la dirección IP privada de la instancia de Azure Firewall)
   • Dirección IP de destino: 192.168.200.4
3. Application Gateway establece una nueva sesión entre la instancia que controla la conexión y uno de los servidores back-end. La dirección IP original del cliente no está en el paquete:
   • Dirección IP de origen: 192.168.200.7 (la dirección IP privada de la instancia de Application Gateway)
   • Dirección IP de destino: 192.168.1.4
   • Encabezado X-Forwarded-For: 192.168.100.7
4. La máquina virtual responde a Application Gateway, lo que invierte las direcciones IP de origen y destino:
   • Dirección IP de origen: 192.168.1.4
   • Dirección IP de destino: 192.168.200.7
5. Application Gateway responde a la dirección IP de origen SNAT de la instancia de Azure Firewall. Incluso si la conexión procede de una instancia específica de Application Gateway, como .7, Azure Firewall ve la dirección IP interna de Application Gateway .4 como dirección IP de origen:
   • Dirección IP de origen: 192.168.200.4
   • Dirección IP de destino: 192.168.100.7
6. Por último, Azure Firewall deshace SNAT y DNAT y responde al cliente:
   • Dirección IP de origen: AzFwPIP
   • Dirección IP de destino: ClientPIP

Incluso si Application Gateway no tiene agentes de escucha configurados para aplicaciones, todavía necesita una dirección IP pública para que Microsoft pueda administrarla.

Clientes locales

Los diseños anteriores muestran todos los clientes de aplicaciones procedentes de la red pública de Internet. Las redes locales también acceden a las aplicaciones. La mayoría de los flujos de tráfico e información anteriores son los mismos que para los clientes de Internet, pero hay algunas diferencias importantes:

• Una puerta de enlace de VPN o una puerta de enlace de ExpressRoute se encuentra delante de Azure Firewall o Application Gateway.
• WAF usa la dirección IP privada de Application Gateway.
• Azure Firewall no admite DNAT para direcciones IP privadas. Por eso debe usar udR para enviar tráfico entrante a Azure Firewall desde las puertas de enlace vpn o ExpressRoute.
• Asegúrese de comprobar advertencias sobre de tunelización forzada para la de Azure Application Gateway y para lade Azure Firewall de . Incluso si la carga de trabajo no necesita conectividad saliente a la red pública de Internet, no puede insertar una ruta predeterminada como 0.0.0.0/0 para application Gateway que apunte a la red local o interrumpirá el tráfico. Para Azure Application Gateway, la ruta predeterminada debe apuntar a la red pública de Internet.

Arquitectura

En el diagrama siguiente se muestra el diseño paralelo de Azure Application Gateway y Azure Firewall. Los clientes de aplicaciones proceden de una red local conectada a Azure a través de VPN o ExpressRoute:

Incluso si todos los clientes se encuentran en el entorno local o en Azure, Azure Application Gateway y Azure Firewall deben tener direcciones IP públicas. Las direcciones IP públicas permiten a Microsoft administrar los servicios.

Topología en estrella tipo hub-and-spoke

Los diseños de este artículo se siguen aplicando en una topología de concentrador y radio. Los recursos compartidos de una red virtual central de concentrador se conectan a las aplicaciones de redes virtuales de radio independientes a través de emparejamientos de redes virtuales.

Arquitectura

Consideraciones

Algunas consideraciones para esta topología incluyen:

• Azure Firewall se implementa en la red virtual central del centro de conectividad. En el diagrama anterior se muestra la práctica de implementar Application Gateway en el centro. Sin embargo, los equipos de aplicaciones administran componentes como Azure Application Gateway o puertas de enlace de Azure API Management. En este caso, estos componentes se implementan en las redes virtuales radiales.
• Preste especial atención a las UDR en las redes de radio: cuando un servidor de aplicaciones de un radio recibe tráfico de una instancia específica de Azure Firewall, como la dirección 192.168.100.7 en los ejemplos anteriores, debe devolver el tráfico a la misma instancia. Si una UDR en el radio establece el próximo salto de tráfico dirigido al centro a la dirección IP de Azure Firewall (192.168.100.4 en los diagramas anteriores), los paquetes devueltos podrían acabar en una instancia de Azure Firewall diferente, lo que provoca un enrutamiento asimétrico. Asegúrese de que si tiene UDR en las redes virtuales de radio para enviar tráfico a servicios compartidos en el centro a través de Azure Firewall, estas UDR no incluyen el prefijo de la subred de Azure Firewall.
• La recomendación anterior se aplica igualmente a la subred de Application Gateway y a cualquier otra aplicación virtual de red o proxy inverso que se pueda implementar en la red virtual del concentrador.
• No se puede establecer el próximo salto para las subredes de Application Gateway o Azure Firewall a través de rutas estáticas con un tipo de próximo salto de Virtual Network. Este tipo de próximo salto solo es válido en la red virtual local y no en los emparejamientos de red virtual. Para obtener más información sobre las rutas definidas por el usuario y los tipos de próximo salto, consulte enrutamiento de tráfico de red virtual.

Enrutamiento asimétrico

En el diagrama siguiente se muestra cómo un radio devuelve el tráfico SNATted a la ALB de Azure Firewall. Esta configuración provoca el enrutamiento asimétrico:

Para solucionar este problema, defina udR en el radio sin la subred de Azure Firewall, pero solo con las subredes en las que se encuentran los servicios compartidos. En el ejemplo, la UDR correcta en el radio solo debe contener 192.168.1.0/24. No debe contener todo 192.168.0.0/16, como marcado en rojo.

Integración con otros productos de Azure

Puede integrar Azure Firewall y Azure Application Gateway con otros productos y servicios de Azure.

API Management Gateway

Integre servicios de proxy inverso como API Management puerta de enlace en los diseños anteriores para proporcionar funcionalidades como la limitación de API o el proxy de autenticación. La integración de una puerta de enlace de API Management no modifica considerablemente los diseños. La principal diferencia es que, en lugar del único proxy inverso de Application Gateway, hay dos servidores proxy inversos encadenados entre sí.

Para obtener más información, consulte la Guía de diseño de para integrar API Management y Application Gateway en una red virtual y el patrón de aplicación PUERTAS de enlace de API para microservicios.

Azure Kubernetes Service

En el caso de las cargas de trabajo que se ejecutan en un clúster de AKS, puede implementar Azure Application Gateway independientemente del clúster. O bien, puede integrarlo con el clúster de AKS mediante la controlador de entrada de Azure Application Gateway. Al configurar determinados objetos en los niveles de Kubernetes (como servicios y entradas), Application Gateway se adapta automáticamente sin necesidad de pasos manuales adicionales.

Azure Firewall desempeña un papel importante en la seguridad del clúster de AKS. Ofrece la funcionalidad necesaria para filtrar el tráfico de salida del clúster de AKS basado en FQDN, no solo la dirección IP. Para obtener más información, consulte Control del tráfico de salida para nodos de clúster de AKS.

Al combinar Application Gateway y Azure Firewall para proteger un clúster de AKS, es mejor usar la opción de diseño paralelo. Application Gateway con WAF procesa solicitudes de conexión entrantes a aplicaciones web en el clúster. Azure Firewall solo permite conexiones salientes permitidas explícitamente. Consulte arquitectura de línea de base de un clúster de Azure Kubernetes Service (AKS) para obtener un ejemplo de la opción de diseño paralelo.

Azure Front Door

funcionalidad de azure Front Door se superpone parcialmente con Azure Application Gateway. Por ejemplo, ambos servicios ofrecen firewall de aplicaciones web, descarga SSL y enrutamiento basado en direcciones URL. Una diferencia principal es que, aunque Azure Application Gateway está dentro de una red virtual, Azure Front Door es un servicio global y descentralizado.

A veces, puede simplificar el diseño de la red virtual reemplazando Application Gateway por una instancia descentralizada de Azure Front Door. La mayoría de los diseños descritos aquí siguen siendo válidos, excepto la opción de colocar Azure Firewall delante de Azure Front Door.

Un caso de uso interesante es usar Azure Firewall delante de Application Gateway en la red virtual. Como se ha descrito anteriormente, el encabezado X-Forwarded-For insertado por Application Gateway contendrá la dirección IP de la instancia del firewall, no la dirección IP del cliente. Una solución alternativa consiste en usar Azure Front Door delante del firewall para insertar la dirección IP del cliente como un encabezado de X-Forwarded-For antes de que el tráfico entre en la red virtual y llegue a Azure Firewall. Una segunda opción es Proteger el origen con Private Link en Azure Front Door Premium.

Para más información sobre las diferencias entre los dos servicios o cuándo usar cada uno, consulte Preguntas más frecuentes sobre Azure Front Door.

Otras aplicaciones virtuales de red

Los productos de Microsoft no son la única opción para implementar el firewall de aplicaciones web o la funcionalidad de firewall de próxima generación en Azure. Una amplia gama de asociados de Microsoft proporciona aplicaciones virtuales de red (NVA). Los conceptos y diseños son esencialmente los mismos que en este artículo, pero hay algunas consideraciones importantes:

• Las aplicaciones virtuales de red asociadas para firewall de próxima generación pueden ofrecer más control y flexibilidad para las configuraciones nat no admitidas por Azure Firewall. Algunos ejemplos son DNAT desde el entorno local o DNAT desde Internet sin SNAT.
• Las aplicaciones virtuales administradas por Azure (como Application Gateway y Azure Firewall) reducen la complejidad, en comparación con las aplicaciones virtuales de red en las que los usuarios necesitan controlar la escalabilidad y la resistencia en muchos dispositivos.
• Al usar NVA en Azure, use activo-activo y configuraciones de escalado automático, por lo que estos dispositivos no son un cuello de botella para las aplicaciones que se ejecutan en la red virtual.

Colaboradores

Microsoft mantiene este artículo. Originalmente fue escrito por los siguientes colaboradores.

Autor principal:

• Jose Moreno | Ingeniero principal de clientes

Pasos siguientes

Obtenga más información sobre las tecnologías de componentes:

• ¿Qué es Azure Application Gateway?
• ¿Qué es Azure Firewall?
• ¿Qué es Azure Front Door?
• Azure Kubernetes Service
• ¿Qué es Azure Virtual Network?
• ¿Qué es Azure Web Application Firewall?

Recursos relacionados

Explore las arquitecturas relacionadas:

• Implementación de una red híbrida segura
• aplicaciones web administradas de forma segura
• proteger el bot de canal y la aplicación web de Microsoft Teams detrás de un firewall
• Consideraciones de seguridad para aplicaciones IaaS altamente confidenciales en Azure
• SaaS multiinquilino en Azure
• implementación de Enterprise con App Services Environment
• implementación empresarial de alta disponibilidad mediante app Services Environment
• arquitectura de línea base para un clúster de Azure Kubernetes Service (AKS)