Firewall y Application Gateway para redes virtuales

Para proteger las cargas de trabajo de las aplicaciones de Azure, debe usar medidas de protección como la autenticación y el cifrado en las propias aplicaciones. También puede agregar niveles de seguridad a las redes de virtuales (VNets) que hospedan las aplicaciones. Estos niveles de seguridad protegen los flujos entrantes de la aplicación frente al uso no deseado. También limitan los flujos de salida a Internet solo a los puntos de conexión que requiere la aplicación. En este artículo se describen los servicios de seguridad de Azure Virtual Network como Azure DDoS Protection, Azure Firewall y Azure Application Gateway, cuándo usar cada servicio y las 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 ofrecer una mejor defensa frente a los ataques DDoS. Debe habilitar Azure DDOS Protection en cualquier red virtual perimetral.
• Azure Firewall es un firewall administrado de última generación que ofrece traducción de direcciones de red (NAT). Azure Firewall basa el filtrado de paquetes en las direcciones de protocolo de Internet (IP) y en los puertos del Protocolo de control de transmisión y el protocolo de datagramas de usuario (TCP/UDP), o en los atributos SQL o HTTP basados en aplicaciones. Azure Firewall también aplica la 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 toda la funcionalidad de Azure Firewall Standard y otras características, como la inspección de TLS y el sistema de detección de intrusiones y protección (IDPS).
• Azure Application Gateway es un equilibrador de carga de tráfico web administrado y un proxy inverso completo HTTP(S) que puede realizar el cifrado y descifrado de la capa de sockets seguros (SSL). Application Gateway conserva la dirección IP del cliente original en un encabezado HTTP X-Forwarded-For. Application Gateway también utiliza el firewall de aplicaciones web para inspeccionar el tráfico web y detectar ataques en el nivel 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 la inserción de SQL o el scripting entre sitios. Para más información, consulte la documentación sobre el firewall de aplicaciones web.

Estos servicios de Azure son complementarios. Cualquiera de ellos puede ser la mejor opción para sus cargas de trabajo, o puede usarlos de forma conjunta para conseguir una protección óptima en los niveles de red y de 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 utilizan distintas tecnologías y admiten la protección de diferentes flujos:

En función de los flujos de red que requiere una aplicación, el diseño puede ser diferente en cada 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 tratan los diseños más recomendados del diagrama de flujo, así como otros que se aplican en escenarios menos comunes:

• Solo Azure Firewall si no hay ninguna aplicación web en la red virtual. Controlará el tráfico entrante a las aplicaciones y el tráfico saliente.
• Solo Application Gateway si solo hay aplicaciones web en la red virtual y los 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.). Por este motivo, el escenario de Application Gateway por sí solo no suele recomendarse y, por lo tanto, no está documentado y no está en el diagrama de flujo anterior.
• Azure Firewall y Application Gateway en paralelo, que es uno de los diseños más comunes. Utilice esta combinación cuando desee que Azure Application Gateway proteja las aplicaciones HTTP(S) de los ataques web y Azure Firewall proteja todas las demás cargas de trabajo y filtre el tráfico saliente.
• Application Gateway por delante de Azure Firewall cuando quiera que Azure Firewall inspeccione todo el tráfico y WAF proteja el tráfico web, y la aplicación necesite conocer la dirección IP de origen del cliente. Con Azure Firewall Premium y la inspección de TLS, este diseño admite también el escenario SSL de un extremo a otro.
• Azure Firewall por 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 es el motivo por el que este escenario no está documentado en el diagrama 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 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 redes de terceros.

Solo Azure Firewall

Si no hay ninguna carga de trabajo basada en web en la red virtual que pueda beneficiarse de WAF, puede usar Azure Firewall solo. En este caso, el diseño es sencillo, pero revisar el flujo de paquetes le 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 desde redes virtuales de Azure se envía al firewall mediante 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. No obstante, podrá aplicar las reglas de nivel 3 y 4, y las reglas de aplicación basadas en FQDN. 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 los niveles 3 y 4 de los paquetes de las reglas de red, así como el encabezado HTTP del host de las reglas de aplicación.
• Azure Firewall Premium agrega funcionalidades como la inspección de otros encabezados HTTP (como el de User-Agent) y la habilitación de la inspección de TLS para un análisis de paquetes más profundo. Azure Firewall no es equivalente a una instancia de Web Application Firewall. Si tiene cargas de trabajo web en su instancia de Virtual Network, se recomienda encarecidamente usar WAF.

En el siguiente ejemplo de recorrido de paquetes se muestra cómo un cliente accede a una aplicación hospedada en una máquina virtual desde Internet público. El diagrama solo incluye una máquina virtual para mayor simplicidad. Para lograr una mayor disponibilidad y escalabilidad, debería disponer de varias instancias de aplicaciones 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 la ruta definida por el usuario.

• El servicio Azure Firewall implementa varias instancias en segundo plano, aquí con la dirección IP de front-end 192.168.100.4 y direcciones internas del intervalo 192.168.100.0/26. Estas instancias individuales normalmente son invisibles para el administrador de Azure. No obstante, observar la diferencia es útil en algunos casos, como cuando se solucionan problemas de red.
• Si el tráfico procede de una red privada virtual (VPN) local o una puerta de enlace de Azure ExpressRoute en lugar de Internet, el cliente inicia la conexión a la dirección IP de la VM. No inicia la conexión a la dirección IP del firewall y el firewall no realizará ninguna NAT de origen de forma predeterminada.

Architecture

En el diagrama siguiente, se muestra el flujo de tráfico suponiendo que la dirección IP de la instancia sea 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 de traducción de direcciones de red de destino (DNAT) de Azure Firewall traduce la dirección IP de destino en la dirección IP de la aplicación en la red virtual. Azure Firewall también efectúa la traducción de direcciones de red de origen (SNAT) del paquete si se lleva a cabo DNAT. Para más información, consulte los 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 e invierte las direcciones IP de origen y de destino. El flujo de entrada no requiere una ruta definida por el usuario (UDR) , porque la IP de origen es la dirección IP de Azure Firewall. La ruta definida por el usuario para 0.0.0.0/0 es para las conexiones salientes, para asegurarse de que los paquetes para 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 y la inspección del tráfico saliente con NSG es suficiente para proteger los flujos salientes a Internet.

La principal diferencia del diseño anterior con el diseño de 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 inverso completo. Es decir, Application Gateway detiene la sesión web desde el cliente y establece una sesión independiente con uno de sus servidores backend. Las conexiones HTTP(S) entrantes de Internet deben enviarse a la dirección IP pública de Application Gateway, y las conexiones de Azure o del entorno local a la dirección IP privada de la puerta de enlace. El tráfico devuelto desde las máquinas virtuales de Azure seguirá el enrutamiento de red virtual estándar de vuelta a Application Gateway (consulte el recorrido del paquete más abajo para obtener más detalles). Los flujos salientes de Internet desde las máquinas virtuales de Azure irán directamente a Internet.

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

Architecture

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

Flujo de trabajo

1. El cliente inicia la conexión con 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 del firewall, 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-ends. El back-end ve la instancia de Application Gateway como 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 e invierte las direcciones IP de origen y de destino. La máquina virtual ya sabe cómo llegar a Application Gateway, por lo que no necesita una ruta definida por el usuario.
   • 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 proporcionar contenido específico de geolocalización o para el registro. Para 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 interna y privada 192.168.200.4. Estas instancias individuales normalmente son invisibles para el administrador de Azure. No obstante, observar la diferencia es útil en algunos casos, como cuando se solucionan problemas de red.

• El flujo es parecido si el cliente procede de una red local a través de VPN o de una puerta de enlace de 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, ejecutar 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 que no son web en la red virtual. El firewall de aplicaciones web de Azure Application Gateway protege el tráfico que entra a las cargas de trabajo web y Azure Firewall inspecciona el tráfico que entra a las demás aplicaciones. Azure Firewall cubrirá los flujos de salida de ambos tipos de carga de trabajo.

Las conexiones HTTP(S) entrantes de Internet deben enviarse a la dirección IP pública de Application Gateway, y las conexiones HTTP(S) de Azure o del entorno local a su dirección IP privada. El enrutamiento de red virtual estándar enviará los paquetes de Application Gateway a las máquinas virtuales de destino, y de las máquinas virtuales de destino de vuelta a Application Gateway (consulte el recorrido del paquete más abajo para obtener más detalles). En el caso de 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 viene de la red pública de Internet), o bien se enviará a través de Azure Firewall mediante UDR (si viene de otras redes virtuales de Azure o de redes locales). Todos los flujos de salida 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 detallado que los grupos de seguridad de red. Por ejemplo, si las aplicaciones necesitan conectividad con una cuenta de Azure Storage específica, puede usar filtros basados en nombres de dominio completos (FQDN). Con los filtros basados en FQDN, las aplicaciones no envían datos a cuentas de almacenamiento no autorizadas. Ese escenario no se pudo evitar solo mediante el uso de NSG. Este diseño se usa a menudo cuando el tráfico saliente requiere filtrado basado en FQDN. Una situación de ejemplo es cuando se limita el tráfico de salida desde un clúster de Azure Kubernetes Services.

Arquitecturas

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

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

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

Application Gateway antes 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 documento se centrará en la comparación con las otras opciones de diseño. En esta topología, el tráfico entrante pasa por Azure Firewall y WAF. El firewall de aplicaciones web 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 backend. Application Gateway y Azure Firewall no se encuentran en paralelo, sino uno después de otro.

Con Azure Firewall Premium, este diseño puede admitir escenarios de un extremo a otro, en los que Azure Firewall aplica la inspección de TLS para ejecutar 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 del cliente entrantes, por ejemplo, para servir contenido específico de geolocalización o para el registro. Application Gateway en frente 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 de este encabezado. Para más información, consulte Funcionamiento de una puerta de enlace de aplicaciones.

Las conexiones HTTP(S) entrantes de Internet deben enviarse a la dirección IP pública de Application Gateway, y las conexiones HTTP(S) de Azure o del entorno local a la dirección IP privada. Desde Application Gateway, las UDR se asegurarán de que los paquetes se enruten a través de Azure Firewall (consulte el recorrido del paquete más abajo para obtener más detalles). En el caso de 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 viene de la red pública de Internet), o bien se enviará mediante Azure Firewall mediante UDR (si viene de otras redes virtuales de Azure o de redes locales). Todos los flujos de salida de las máquinas virtuales de Azure se reenviarán a Azure Firewall mediante UDR.

Una observación importante de este diseño es que Azure Firewall Premium verá el tráfico con una dirección IP de origen de la subred 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 la regla IDPS de Azure Firewall y los prefijos de 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 un entorno local o desde Internet a Azure, Azure Firewall inspeccionará los flujos que ya ha permitido el firewall de aplicaciones web. Dependiendo de si Application Gateway cifra el tráfico de back-end (tráfico desde Application Gateway a los servidores de aplicaciones), tendrá diferentes escenarios posibles:

1. Application Gateway cifra el tráfico siguiendo los principios de confianza cero (cifrado TLS de un extremo a otro) y Azure Firewall recibirá el tráfico cifrado. Aún así, Azure Firewall Standard podrá aplicar reglas de inspección, como el filtrado en los niveles 3 y 4 de las reglas de red, o el filtrado basado en el nombre de dominio completo de las reglas de aplicación mediante el encabezado de indicación de nombre de servidor (SNI) de TLS. Azure Firewall Premium proporciona una visibilidad más profunda 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 como 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 coincida con la dirección IP de destino. Para ello, necesitará la resolución de nombres para el FQDN especificado en el encabezado host. Esta resolución de nombres se puede lograr con Azure DNS Private Zones 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 obtener más información, consulte Configuración de DNS de Azure Firewall). Si no dispone de acceso administrativo a la instancia de Virtual Network donde está implementado Azure Firewall, el último método es la única posibilidad. Un ejemplo es con las instancias de Azure Firewall implementadas en centros protegidos de Virtual WAN.

Architecture

Para el resto de flujos (tráfico entrante no HTTP(S) y todo el tráfico de salida), Azure Firewall proporcionará la inspección de IDPS y la de TLS según sea necesario. También proporciona filtrado basado en FQDN en las 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 con 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 del firewall, 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-ends. La ruta definida por el usuario hacia 192.168.1.0/24 en la subred de Application Gateway reenvía el paquete a Azure Firewall al tiempo que conserva la dirección IP de destino a la aplicación web:
   • 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. Azure Firewall efectúa la traducción de direcciones de red de origen del tráfico, porque el tráfico se dirige a una dirección IP privada. Reenvía el tráfico a la VM de la aplicación si las reglas lo permiten. Para más información, consulte Traducción de direcciones de red de origen 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 redirigirá la conexión mediante proxy:
   • 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 la 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 e invierte las direcciones IP de origen y de destino. La ruta definida por el usuario hacia 192.168.200.0/24 captura el paquete que se devuelve 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. De nuevo, Azure Firewall no efectúa la traducción de direcciones de red de origen (SNAT) del tráfico, ya que este 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 de salida desde las máquinas virtuales a la red pública de Internet atraviesan Azure Firewall, tal como se define en la ruta definida por el usuario hacia 0.0.0.0/0.

Application Gateway después de Azure Firewall

Este diseño permite Azure Firewall filtrar y descartar el tráfico malintencionado antes de que llegue 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 efectúa la traducción del tráfico entrante, por lo que la aplicación no tendrá visibilidad sobre la dirección IP original de las solicitudes HTTP. Desde una perspectiva de administración, por ejemplo, con fines de 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.

La ventaja en este escenario es limitada, ya que Azure Firewall solo verá el tráfico cifrado que se dirige a Application Gateway. Puede haber escenarios en los que se prefiera este diseño. Un caso podría ser si hay otro WAF anteriormente 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 X-Forwarded-For. O bien, se prefiere el diseño si se requieren muchas direcciones IP públicas.

Los flujos de entrada HTTP(S) de la red pública de Internet deben tener como destino la dirección IP pública de Azure Firewall, y Azure Firewall traducirá mediante DNAT (y SNAT) las direcciones de red de destino de 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 desde 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 las UDR de Azure en Application Gateway, deben usarse subredes (consulte el recorrido del paquete más abajo para obtener más detalles). Todo el tráfico saliente desde las máquinas virtuales de Azure a Internet se enviará 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 normalmente no descifraría el tráfico. En su lugar, aplicaría directivas IDPS que no requieren la inspección de TLS, como el filtrado basado en IP o el uso de encabezados HTTP.

Architecture

La aplicación no puede ver la dirección IP de origen inicial del tráfico web; Azure Firewall efectúa la traducción de direcciones de red de origen de los paquetes según 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 encabezado HTTP antes de que entre en Azure Virtual Network.

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. Azure Firewall efectúa la traducción de direcciones de red de destino (DNAT) del puerto web, normalmente TCP 443, hacia la dirección IP privada de la instancia de Application Gateway. Azure Firewall también efectúa la traducción de direcciones de red de origen al realizar la traducción de direcciones de red de destino. Para más información, consulte los 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 e invierte las direcciones IP de origen y de 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 de SNAT de la instancia de Azure Firewall. Incluso si la conexión procede de una instancia de Application Gateway específica como .7, Azure Firewall ve la dirección IP interna de Application Gateway .4 como la 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 ningún cliente de escucha configurado para las aplicaciones, 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 la información y los flujos de tráfico anteriores son los mismos que para los clientes de Internet, pero hay algunas diferencias notables:

• Hay una puerta de enlace de VPN o de ExpressRoute delante de Azure Firewall o de Application Gateway.
• El firewall de aplicaciones web usa la dirección IP privada de Application Gateway.
• Azure Firewall no admite la traducción de direcciones de red de destino (DNAT) para las direcciones IP privadas. Por eso debe usar rutas definidas por el usuario para enviar el tráfico entrante a Azure Firewall desde las puertas de enlace de VPN o ExpressRoute.
• Asegúrese de comprobar las advertencias sobre tunelización forzada de Azure Application Gateway y Azure Firewall. Incluso si la carga de trabajo no necesita conectividad de salida 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 de control. En Azure Application Gateway, la ruta predeterminada debe apuntar a la red pública de Internet.

Architecture

En el diagrama siguiente se muestra el diseño en paralelo de Azure Application Gateway y Azure Firewall. Los clientes de aplicaciones que 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 de red en estrella tipo hub-and-spoke

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

Architecture

Consideraciones

Aspectos a tener en cuenta sobre esta topología:

• Azure Firewall se implementa en la red virtual del concentrador central. En el diagrama anterior se muestra el procedimiento de implementar Application Gateway en el centro de conectividad. Sin embargo, los equipos de aplicaciones a menudo administran componentes como instancias de Azure Application Gateway o puertas de enlace de Azure API Management. En este caso, estos componentes se implementan en las redes virtuales radiales.
• Preste mucha atención a los UDR en las redes de radio: cuando un servidor de aplicaciones radial recibe tráfico de una instancia de Azure Firewall específica, como la dirección 192.168.100.7 de los ejemplos anteriores, debe devolver el tráfico a la misma instancia. Si un UDR radial configura el próximo salto de tráfico dirigido al centro de conectividad a la dirección IP de Azure Firewall (192.168.100.4 en los diagramas de más arriba), los paquetes devueltos podrían acabar en una instancia de Azure Firewall diferente, lo que producirá un enrutamiento asimétrico. Asegúrese de que, si tiene UDR en las redes virtuales radiales para enviar tráfico a servicios compartidos en el centro de conectividad a través de Azure Firewall, estos UDR no incluyen el prefijo de la subred de Azure Firewall.
• La recomendación anterior se aplica igualmente a la subred Application Gateway y a cualquier otra aplicación virtual de red o a servidores proxy inversos que podrían implementarse en la red virtual del centro de conectividad.
• No se puede establecer el próximo salto para las subredes 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. Obtenga más información sobre las rutas definidas por el usuario y los tipos de próximo salto en Enrutamiento del tráfico de redes virtuales.

Ruta asimétrica

En el diagrama siguiente se muestra cómo un radio devuelve el tráfico con SNAT aplicado al ALB de una instancia de Azure Firewall. Esta configuración provoca un enrutamiento asimétrico:

Para resolver este problema, defina los UDR en los elementos radiales sin la subred de Azure Firewall, sino solo las subredes donde se encuentran los servicios compartidos. En el ejemplo, el UDR correcto del elemento radial solo debe contener 192.168.1.0/24. No debe contener todo el 192.168.0.0/16, 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.

Puerta de enlace de API Management

Integre servicios de proxy inverso como la puerta de enlace de API Management 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 significativamente los diseños. La principal diferencia estriba en que, en lugar de un único proxy inverso de Application Gateway, hay dos proxies inversos encadenados uno detrás de otro.

Para más información, consulte la guía de diseño 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 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 el controlador de entrada de Azure Application Gateway. Al configurar ciertos objetos en los niveles de Kubernetes (como los servicios y las entradas), Application Gateway se adapta automáticamente sin necesidad de realizar 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 desde el clúster de AKS según el FQDN y no solo de la dirección IP. Para más información, consulte Control del tráfico de salida de los nodos de clúster de AKS.

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

Azure Front Door

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

En ocasiones, puede simplificar el diseño de la red virtual mediante la sustitución de Application Gateway por una instancia de Azure Front Door descentralizada. La mayoría de los diseños descritos en este documento siguen siendo válidos, salvo por la opción de anteponer Azure Firewall a Azure Front Door.

Un caso de uso interesante es la utilización de Azure Firewall delante de Application Gateway en la red virtual. Como se describió anteriormente, el encabezado X-Forwarded-For que inserta Application Gateway contendrá la dirección IP de la instancia del firewall, no la dirección IP del cliente. Una solución alternativa es usar Azure Front Door delante del firewall para insertar la dirección IP del cliente como un encabezado X-Forwarded-For antes de que entre el tráfico en la red virtual y llegue a Azure Firewall. Una segunda opción consiste en proteger su 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 las 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 un firewall de aplicaciones web o la funcionalidad de firewall de próxima generación en Azure. Una amplia gama de asociados de Microsoft proporcionan 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 de los asociados para las soluciones de firewall de próxima generación pueden ofrecer un mayor control y flexibilidad para las configuraciones de NAT que Azure Firewall no admite. Algunos ejemplos son DNAT desde el entorno local o DNAT desde Internet sin SNAT.
• Las aplicaciones virtuales de red 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 varios dispositivos.
• Cuando use aplicaciones virtuales de red en Azure, use las configuraciones activo-activo y 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. Originalmente lo escribieron los siguientes colaboradores.

Autor principal:

• Jose Moreno | Ingeniero principal de clientes

Pasos siguientes

Más información sobre las tecnologías de los 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 el firewall de aplicaciones web de Azure?

Recursos relacionados

Explore las arquitecturas relacionadas:

• Implementación de una red híbrida segura
• Aplicaciones web administradas de forma segura
• Protección del bot del canal de Microsoft Teams y la aplicación web detrás de un firewall
• Portal sanitario del consumidor en Azure
• Consideraciones relativas a la seguridad para aplicaciones IaaS altamente confidenciales en Azure
• SaaS multiinquilino en Azure
• Implementación empresarial mediante App Services Environment
• Implementación empresarial de alta disponibilidad mediante App Services Environment
• Arquitectura de línea de base en un clúster de Azure Kubernetes Service (AKS)