Azure Firewall y Application Gateway para redes virtuales

Para ayudar a proteger las cargas de trabajo de aplicaciones de Azure, use medidas de protección como la autenticación y el cifrado en las propias aplicaciones. Puede agregar capas de seguridad a las redes virtuales que hospedan las aplicaciones. Estas capas de seguridad ayudan a proteger los flujos entrantes de la aplicación frente al uso no deseado. También limitan los flujos salientes a Internet solo a los 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. También se describe cuándo usar cada servicio y opciones de diseño de red que las combinan.

• DDoS Protection, combinado con los procedimientos recomendados de diseño de aplicaciones, proporciona características mejoradas de mitigación de DDoS que mejoran la defensa contra ataques DDoS. Debe habilitar DDoS Protection en cada red virtual perimetral.

• azure Firewall es un firewall administrado de próxima generación que proporciona funcionalidades de traducción de direcciones de red (NAT). Azure Firewall filtra los paquetes en función de las direcciones IP y los puertos protocolo de control de transmisión (TCP) o protocolo de datagramas de usuario (UDP). Puede filtrar el tráfico mediante atributos basados en aplicaciones, como HTTP(S) y SQL. Azure Firewall también aplica inteligencia sobre amenazas de Microsoft para ayudar a identificar direcciones IP malintencionadas. Para más información, consulte documentación de Azure Firewall.

• Azure Firewall Premium incluye toda la funcionalidad de Azure Firewall Standard, además de características como la inspección de la capa de transporte (TLS) y el sistema de detección y prevención de intrusiones (IDPS).

• Application Gateway es un equilibrador de carga de tráfico web administrado y proxy inverso completo HTTP(S) que puede realizar cifrado y descifrado de capa de sockets seguros (SSL). Application Gateway conserva la dirección IP del cliente original en un encabezado HTTP de X-Forwarded-For. Application Gateway también usa Azure Web Application Firewall para inspeccionar el tráfico web y detectar ataques en la capa HTTP. Para más información, consulte documentación de Application Gateway.

• web Application Firewall es una adición opcional a Application Gateway. Inspecciona las solicitudes HTTP y evita ataques de capa web, como la inyección de código SQL y el scripting entre sitios. Para obtener más información, consulte documentación de Web Application Firewall.

Estos servicios de Azure se complementan entre sí. Según sus necesidades, el uso de un servicio podría adaptarse mejor a las cargas de trabajo. Sin embargo, puede usar estos servicios juntos para ayudar a proporcionar 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 elegir la mejor opción de seguridad para la red virtual de la aplicación.

Azure Firewall y Application Gateway usan diferentes tecnologías para ayudar a proteger diferentes tipos de flujos de datos.

El diseño puede variar para cada aplicación en función de los flujos de red que requiere. En el diagrama siguiente se proporciona un árbol de decisión simplificado que le ayuda a elegir el enfoque recomendado para la aplicación. Esta opció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 describen los diseños ampliamente recomendados que se muestran en el gráfico de flujo y los diseños adecuados para escenarios menos comunes:

• Azure Firewall solo: Use este diseño cuando no haya ninguna aplicación web en la red virtual. Controla el tráfico entrante a las aplicaciones y al tráfico saliente.

• Application Gateway solo: Use este diseño cuando solo las aplicaciones web estén en la red virtual y grupos de seguridad de red (NSG) proporcionen un filtrado de salida suficiente. Azure Firewall proporciona funcionalidad que puede ayudar a evitar varios escenarios de ataque, como la filtración de datos e IDPS. Como resultado, el diseño solo de Application Gateway no se recomienda normalmente, por lo que no se incluye en el gráfico de flujo anterior.

• Azure Firewall y Application Gateway en paralelo: Use este diseño cuando quiera que 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. Azure Firewall y Application Gateway en paralelo son un diseño común.

• Application Gateway delante de Azure Firewall: Use este diseño cuando quiera que Azure Firewall inspeccione todo el tráfico, web Application Firewall para proteger el tráfico web y la aplicación para identificar 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: Use este diseño cuando quiera que Azure Firewall inspeccione y filtre el tráfico antes de que llegue a Application Gateway. Dado que Azure Firewall no descifra el tráfico HTTPS, su funcionalidad agregada a Application Gateway está limitada. Este escenario no se documenta en el gráfico de flujo anterior.

Las variaciones de estos diseños fundamentales se describen más adelante en este artículo e incluyen:

• clientes de aplicaciones locales.
• redes en estrella tipo hub-and-spoke.
• implementaciones de de Azure Kubernetes Service (AKS).

Puede agregar otros servicios de proxy inverso, como puerta de enlace de Azure API Management o Azure Front Door. O bien, puede reemplazar los recursos de Azure por aplicaciones virtuales de red (NVA) que no son de Microsoft.

Diseño solo de Azure Firewall

Si no hay ninguna carga de trabajo basada en web en la red virtual que pueda beneficiarse del firewall de aplicaciones web, puede usar el diseño solo de Azure Firewall. El diseño de este ejemplo es sencillo, pero puede revisar el flujo de paquetes para comprender mejor los 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. Las UDR dirigen el tráfico saliente de las redes virtuales de Azure a Azure Firewall, 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 inspecciona el tráfico HTTP(S) entrante. Pero puede aplicar reglas de nivel 3 y nivel 4 y reglas de aplicación basadas en nombre de dominio completo (FQDN). Azure Firewall inspecciona 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 inspecciona solo los atributos de nivel 3 y 4 de los paquetes en las reglas de red y el encabezado HTTP de host en las reglas de aplicación.

• Azure Firewall Premium agrega funcionalidades, como inspeccionar otros encabezados HTTP (como el agente de usuario) y habilitar la inspección de TLS para un análisis de paquetes más profundo. Sin embargo, Azure Firewall no es el mismo que el firewall de aplicaciones web. Si tiene cargas de trabajo web en la red virtual, se recomienda usar firewall de aplicaciones web.

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, hay 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 desde la máquina virtual de la subred de la aplicación mediante el UDR.

• En este ejemplo, Azure Firewall implementa automáticamente varias instancias con la dirección IP de front-end 192.168.100.4 y direcciones internas dentro del intervalo 192.168.100.0/26. Normalmente, estas instancias no son visibles para el administrador de Azure. Sin embargo, tener en cuenta que pueden ser útiles para 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 realiza nat de origen de forma predeterminada.

Arquitectura

En el diagrama siguiente se muestra el flujo de tráfico y se supone 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, que se 192.168.100.7 en este ejemplo. La regla de traducción de direcciones de red 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 implementa traducción de direcciones de red de origen (SNAT) en el paquete si usa 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 aplicación, que invierte las direcciones IP de origen y destino. El flujo de entrada no requiere una UDR porque la dirección IP de origen es la dirección IP de Azure Firewall. La UDR del diagrama de 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. 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

Diseño solo de Application Gateway

Este diseño describe el escenario en el 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 diferencia clave del diseño anterior solo de Azure Firewall es que Application Gateway no sirve como dispositivo de enrutamiento con NAT. En su lugar, funciona como un proxy de aplicación inverso completo. Este enfoque significa que 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 se envían a la dirección IP pública de Application Gateway y las conexiones desde Azure o local usan la dirección IP privada de la puerta de enlace. Devolver el tráfico de las máquinas virtuales de Azure sigue el enrutamiento de red virtual estándar a Application Gateway. Para obtener más información, consulte el tutorial de paquetes más adelante en este artículo. Los flujos salientes de Internet desde máquinas virtuales de Azure van 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 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, que se 192.168.200.7 en este ejemplo. 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-ends. 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, que es la dirección IP privada de la instancia de Application Gateway: 192.168.200.7
   • Dirección IP de destino: 192.168.1.4
   • encabezado X-Forwarded-For: ClientPIP

3. La máquina virtual responde a la solicitud de aplicación e invierte las direcciones IP de origen y destino. La máquina virtual puede acceder 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. La instancia de Application Gateway responde al cliente.

   • Dirección IP de origen: AppGwPIP
   • Dirección IP de destino: ClientPIP

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.

• En este ejemplo, la dirección IP 192.168.200.7 es una de las instancias implementadas por el servicio Application Gateway automáticamente. Tiene 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 puede ser útil, como cuando se solucionan 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 IP pública.

Diseño paralelo de Azure Firewall y Application Gateway

Debido a su simplicidad y flexibilidad, a menudo es mejor ejecutar Application Gateway y Azure Firewall en paralelo.

Implemente este diseño si hay cargas de trabajo web y no web en la red virtual. El firewall de aplicaciones web de Application Gateway ayuda a proteger el tráfico entrante a las cargas de trabajo web. Azure Firewall inspecciona el tráfico entrante de las otras aplicaciones. Azure Firewall cubre 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 Application Gateway. Las conexiones HTTP(S) desde Azure o local deben enviarse a su dirección IP privada. El enrutamiento de red virtual estándar envía los paquetes de Application Gateway a las máquinas virtuales de destino y de las máquinas virtuales de destino a Application Gateway. Para obtener más información, consulte el tutorial de paquetes más adelante en este artículo.

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. Las UDR deben enviar tráfico a través de Azure Firewall si procede de otras redes virtuales de Azure o redes locales. Todos los flujos salientes de las máquinas virtuales de Azure se reenvía 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 usar únicamente grupos de seguridad de red. Por ejemplo, si las aplicaciones necesitan conectividad con una cuenta específica de Azure Storage, puede usar filtros basados en FQDN. Con los filtros basados en FQDN, las aplicaciones no envían datos a cuentas de almacenamiento no autorizadas. Si solo usa grupos de seguridad de red, no puede evitar este escenario. Este diseño se usa a menudo cuando el tráfico saliente requiere filtrado basado en FQDN. Un escenario es cuando se limitar el tráfico de salida de un clúster de AKS.

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 delante del diseño de Azure 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 artículo se centra 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 Web Application Firewall. El firewall de aplicaciones web proporciona protección en el nivel de aplicación web. Azure Firewall actúa como punto de control y registro central, e inspecciona el tráfico entre Application Gateway y los servidores back-end. En este diseño, Application Gateway y Azure Firewall no se sientan en paralelo, sino que se encuentran delante de la otra.

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 identificar las direcciones IP de origen del cliente entrantes. Por ejemplo, se puede usar para servir contenido específico de la geolocalización o para el registro. Application Gateway delante del diseño 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 Application Gateway. Las conexiones HTTP(S) desde Azure o local deben enviarse a su dirección IP privada. Desde Application Gateway, las UDR garantizan que los paquetes se enrutan a través de Azure Firewall. Para obtener más información, consulte el tutorial de paquetes más adelante en este artículo.

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. Las UDR deben enviar tráfico a través de Azure Firewall si procede de otras redes virtuales de Azure o redes locales. Todos los flujos salientes de las máquinas virtuales de Azure se reenvía a Azure Firewall mediante udR.

Un aspecto importante de este diseño es que Azure Firewall Premium ve 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/12o 100.64.0.0/10), Azure Firewall Premium trata el tráfico de Application Gateway como interno y no aplica reglas IDPS para el tráfico entrante. Como resultado, se recomienda modificar los prefijos privados de IDPS en la directiva de Azure Firewall. Esta modificación garantiza que la subred de Application Gateway no se considere un origen interno, lo que permite aplicar firmas IDPS entrantes y salientes al tráfico. 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.

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

Para el tráfico web desde el entorno local o desde Internet a Azure, Azure Firewall inspecciona los flujos que permite el firewall de aplicaciones web. En función de si Application Gateway cifra el tráfico back-end, que es el tráfico de Application Gateway a los servidores de aplicaciones, pueden producirse diferentes escenarios:

• Application Gateway cifra el tráfico siguiendo los principios de confianza cero, como cifrado TLS de un extremo a otroy Azure Firewall recibe tráfico cifrado. Azure Firewall Standard todavía puede aplicar reglas de inspección, como el filtrado de nivel 3 y 4 en las reglas de red o el filtrado de FQDN en las reglas de aplicación, mediante el encabezado Indicación de nombre del servidor TLS (SNI). Azure Firewall Premium proporciona una mayor visibilidad con la inspección de TLS, como el filtrado basado en direcciones URL.

• Si Application Gateway envía tráfico sin cifrar a los servidores de aplicaciones, Azure Firewall ve el tráfico entrante en texto no cifrado. La inspección de TLS no es necesaria en Azure Firewall.

• Si IDPS está habilitado en Azure Firewall, comprueba que el encabezado host HTTP coincide con la dirección IP de destino. Para realizar esta comprobación, necesita la resolución de nombres para el FQDN especificado en el encabezado Host. Esta resolución de nombres se puede realizar mediante zonas privadas de Azure DNS y la configuración predeterminada de DNS de Azure Firewall. También se puede lograr con servidores DNS personalizados que deben configurarse en la configuración de Azure Firewall. Si no tiene acceso administrativo a la red virtual donde se implementa Azure Firewall, el último método es la única opción. Un ejemplo es con las instancias de Azure Firewall implementadas en centros protegidos por Azure Virtual WAN.

Arquitectura

Para el resto de los flujos, que incluyen el tráfico entrante que no es HTTP(S) y cualquier tráfico saliente, Azure Firewall proporciona la inspección de IDPS y la inspección tls cuando sea adecuado. 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 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, que se 192.168.200.7 en este ejemplo. La instancia de Application Gateway detiene la conexión del cliente y establece una nueva conexión con uno de los back-ends. El UDR que se va a 192.168.1.0/24 en la subred de Application Gateway reenvía el paquete a Azure Firewall y conserva la dirección IP de destino a la aplicación web.

   • Dirección IP de origen, que es la dirección IP privada de la instancia de Application Gateway: 192.168.200.7
   • Dirección IP de destino: 192.168.1.4
   • encabezado X-Forwarded-For: ClientPIP

3. Azure Firewall no aplica SNAT al tráfico porque 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 Aplicación de SNAT por parte de Azure Firewall a intervalos de direcciones IP privadas. Sin embargo, si el tráfico alcanza una regla de aplicación en el firewall, la carga de trabajo ve la dirección IP de origen de la instancia de firewall específica que procesó el paquete porque Azure Firewall proxie la conexión.

   • Dirección IP de origen si una regla de red de Azure Firewall permite el tráfico y es la dirección IP privada de una de las instancias de Application Gateway: 192.168.200.7
   • Dirección IP de origen si una regla de aplicación de Azure Firewall permite el tráfico y es la dirección IP privada de una de las instancias de Azure Firewall: 192.168.100.7
   • Dirección IP de destino: 192.168.1.4
   • encabezado X-Forwarded-For: ClientPIP

4. La máquina virtual responde a la solicitud, que invierte tanto las direcciones IP de origen como de destino. La UDR para 192.168.200.0/24 captura el paquete enviado a Application Gateway, lo redirige a Azure Firewall y 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. De nuevo, Azure Firewall no aplica SNAT al tráfico porque 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. 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, que el UDR para 0.0.0.0/0 define.

Como variación de este diseño, puede configurar DNAT privado en Azure Firewall para que la carga de trabajo de la aplicación vea las direcciones IP de las instancias de Azure Firewall como origen y no se requieren UDR. La dirección IP de origen de los clientes de la aplicación ya se conserva en el encabezado HTTP de X-Forwarded-For por Application Gateway. Por lo tanto, si Azure Firewall aplica DNAT al tráfico, no se pierde información. Para más información, consulte Filtrado del tráfico entrante de Internet o intranet con DNAT de directiva de Azure Firewall mediante Azure Portal.

Azure Firewall delante del diseño de Application Gateway

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. En teoría, hay tres modos en los que puede configurar Azure Firewall:

• Azure Firewall con reglas DNAT: Azure Firewall solo intercambia direcciones IP en la capa de direcciones IP, pero no procesa la carga. Como resultado, no cambia ninguno de los encabezados HTTP.

• Azure Firewall con reglas de aplicación y inspección de TLS deshabilitadas: Azure Firewall puede examinar el encabezado SNI en TLS, pero no lo descifra. Se crea una nueva conexión TCP desde el firewall al próximo salto. En este ejemplo, es Application Gateway.

• Azure Firewall con reglas de aplicación y la inspección de TLS habilitadas: Azure Firewall examina el contenido del paquete y los descifra. Actúa como proxy HTTP y puede establecer los encabezados HTTP X-Forwarded-For para conservar la dirección IP. Sin embargo, presenta un certificado autogenerado al cliente. En el caso de las aplicaciones basadas en Internet, el uso de un certificado autogenerado no es una opción porque se envía una advertencia de seguridad a los clientes de la aplicación desde su explorador.

En las dos primeras opciones, que son las únicas opciones válidas para las aplicaciones basadas en Internet, Azure Firewall aplica SNAT al tráfico entrante sin establecer el encabezado X-Forwarded-For. Como resultado, la aplicación no puede ver la dirección IP original de las solicitudes HTTP. Para las tareas administrativas, como la solución de problemas, puede obtener la dirección IP del cliente real para una conexión específica mediante la correlación con los registros SNAT de Azure Firewall.

Las ventajas de este escenario son limitadas porque, a menos que use la inspección de TLS y presente certificados autogenerados a los clientes, Azure Firewall solo ve tráfico cifrado que va a Application Gateway. Normalmente, este escenario solo es posible para las aplicaciones internas. Sin embargo, puede haber escenarios en los que se prefiera este diseño. Un escenario es si existe otro firewall de aplicaciones web anteriormente en la red (por ejemplo, con Azure Front Door), que puede capturar la dirección IP de origen original en el encabezado HTTP de X-Forwarded-For. También puede preferir este diseño si se requieren muchas direcciones IP públicas porque Application Gateway admite una sola dirección IP.

Los flujos entrantes HTTP(S) de la red pública de Internet deben tener como destino la dirección IP pública de Azure Firewall. 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 garantiza que el tráfico devuelto de las máquinas virtuales de Azure vuelva a Application Gateway y desde Application Gateway a Azure Firewall si se usaron reglas DNAT. Para el tráfico desde el entorno local o Azure, use udR en la subred de Application Gateway. Para obtener más información, consulte el tutorial de paquetes más adelante en este artículo. Todo el tráfico saliente de las máquinas virtuales de Azure a Internet se envía a través de Azure Firewall mediante udR.

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

Para el tráfico HTTP(S) entrante, Azure Firewall no suele descifrar el tráfico. En su lugar, aplica directivas IDPS que no requieren inspección de TLS, como el filtrado basado en direcciones 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. Azure Firewall aplica SNAT a los paquetes 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, que se 192.168.100.7 en este ejemplo. Azure Firewall aplica DNAT al puerto web, normalmente TCP 443, a la dirección IP privada de la instancia de Application Gateway. Azure Firewall también aplica SNAT al realizar DNAT. Para más información, consulte problemas conocidos de Azure Firewall.

   • Dirección IP de origen, que es la dirección IP privada de la instancia de Azure Firewall: 192.168.100.7
   • 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, que es la dirección IP privada de la instancia de Application Gateway: 192.168.200.7
   • 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, 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. Azure Firewall ve la dirección IP interna de Application Gateway, .4, como dirección IP de origen, incluso si la conexión procede de una instancia específica de Application Gateway, como .7.

   • Dirección IP de origen: 192.168.200.4
   • Dirección IP de destino: 192.168.100.7

6. Azure Firewall deshace SNAT y DNAT y responde al cliente.

   • Dirección IP de origen: AzFwPIP
   • Dirección IP de destino: ClientPIP

Application Gateway necesita una dirección IP pública para que Microsoft pueda administrarla, aunque no tenga agentes de escucha configurados para las aplicaciones.

Clientes locales

Los diseños anteriores muestran todos los clientes de aplicaciones entrantes 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.

• El firewall de aplicaciones web usa la dirección IP privada de Application Gateway.

• Azure Firewall no admite DNAT para direcciones IP privadas, por lo que 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 Application Gateway y para azure Firewall. 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 porque interrumpe el tráfico. Para 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 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, Application Gateway y Azure Firewall deben tener direcciones IP públicas. Estas direcciones IP públicas permiten a Microsoft administrar los servicios.

Topología de red en estrella tipo hub-and-spoke.

Los diseños de este artículo se aplican a una topología de de tipo hub-and-spoke. 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 cómo implementar Application Gateway en el centro. Los equipos de aplicaciones suelen administrar componentes como Application Gateway o puertas de enlace de API Management. En este escenario, estos componentes se implementan en las redes virtuales de radio.

• 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 IP 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 terminar en otra instancia de Azure Firewall. Esta situación provoca el enrutamiento asimétrico. Si tiene UDR en las redes virtuales de radio, asegúrese de 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 otro NVA 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 emparejamientos de red virtual. Para obtener más información sobre las UDR 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 envía tráfico SNAT de vuelta al equilibrador de carga de Azure 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 y solo con las subredes donde se encuentran los servicios compartidos. En el diagrama anterior, la UDR correcta en el radio solo debe contener 192.168.1.0/24. No debe contener todo el intervalo 192.168.0.0/16, que está marcado en rojo.

Integración con otros productos de Azure

Puede integrar Azure Firewall y 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 la puerta de enlace de API Management no afecta significativamente a los diseños. La diferencia clave 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.

AKS

En el caso de las cargas de trabajo que se ejecutan en un clúster de AKS, puede implementar Application Gateway independientemente del clúster. O bien, puede integrarlo con el clúster de AKS mediante el controlador de entrada de Application Gateway. Al configurar objetos específicos en los niveles de Kubernetes, como los servicios y las 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. Proporciona 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 más información, consulte Limitar el tráfico de red con Azure Firewall en 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 firewall de aplicaciones web procesa las solicitudes de conexión entrantes a las aplicaciones web del clúster. Azure Firewall solo permite conexiones salientes permitidas explícitamente. Para obtener más información sobre la opción de diseño paralelo, consulte arquitectura de línea de base para un clúster de AKS.

Azure Front Door

Azure Front Door tiene funcionalidad que se superpone con Application Gateway en varias áreas. Ambos servicios proporcionan firewall de aplicaciones web, descarga SSL y enrutamiento basado en direcciones URL. Sin embargo, una diferencia clave es que, aunque Application Gateway funciona dentro de una red virtual, Azure Front Door es un servicio global y descentralizado.

A veces, puede simplificar el diseño de red virtual reemplazando Application Gateway por una instancia descentralizada de Azure Front Door. La mayoría de los diseños descritos en este artículo se siguen aplicando, excepto por la opción de colocar Azure Firewall delante de Azure Front Door.

Un escenario consiste en usar Azure Firewall delante de Application Gateway en la red virtual. Application Gateway inserta el encabezado X-Forwarded-For con la dirección IP de la instancia de 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. También puede proteger su origen con Azure 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 proporcionan 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 proporcionar más control y flexibilidad para las configuraciones NAT que Azure Firewall no admite. Algunos ejemplos son DNAT desde el entorno local o DNAT desde Internet sin SNAT.

• Los NVA administrados 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 las configuraciones de escalado automático para que estos dispositivos no sean un cuello de botella para las aplicaciones que se ejecutan en la red virtual.

Colaboradores

Microsoft mantiene este artículo. Los colaboradores siguientes escribieron este artículo.

Autor principal:

• Jose Moreno | Ingeniero principal de clientes

Para ver perfiles de LinkedIn no públicos, inicie sesión en LinkedIn.

Pasos siguientes

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

• ¿Qué es Application Gateway?
• ¿Qué es Azure Firewall?
• ¿Qué es Azure Front Door?
• de AKS
• ¿Qué es Virtual Network?
• ¿Qué es el firewall de aplicaciones web?
• Arquitectura de línea de base para un clúster de AKS

Recursos relacionados

Explore las arquitecturas relacionadas:

• Implementación de una red híbrida segura
• aplicaciones web administradas de forma segura
• Protección del bot de canal de Microsoft Teams y la aplicación web detrás de un firewall
• software como servicio multiinquilino en Azure
• implementación de Enterprise mediante app Service Environment
• implementación empresarial de alta disponibilidad mediante App Service Environment