Red de confianza cero para aplicaciones web con Azure Firewall y Application Gateway

En esta guía se describe una estrategia para implementar seguridad de de confianza cero para aplicaciones web para inspección y cifrado. El paradigma de confianza cero incluye muchos otros conceptos, como la comprobación constante de la identidad de los actores o la reducción del tamaño de las áreas de confianza implícitas a un mínimo. En este artículo se hace referencia al componente de cifrado e inspección de una arquitectura de confianza cero para el tráfico entrante desde la red pública de Internet. Lea otros documentos de confianza cero para obtener más aspectos de la implementación segura de la aplicación, como la autenticación. Para este artículo, un enfoque multicapa funciona mejor, donde la seguridad de red constituye una de las capas del modelo de confianza cero. En esta capa, los dispositivos de red inspeccionan los paquetes para asegurarse de que solo el tráfico legítimo llega a las aplicaciones.

Normalmente, los diferentes tipos de dispositivos de red inspeccionan distintos aspectos de los paquetes de red:

• Los firewalls de aplicaciones web buscan patrones que indican un ataque en el nivel de aplicación web.
• Los firewalls de próxima generación también pueden buscar amenazas genéricas.

En algunas situaciones, puede combinar diferentes tipos de dispositivos de seguridad de red para aumentar la protección. Una guía independiente, Firewall y Application Gateway para redes virtuales, describe los patrones de diseño que puede usar para organizar los distintos dispositivos. Este documento se centra en un patrón común para maximizar la seguridad, en la que Azure Application Gateway actúa antes de Azure Firewall Premium. En el diagrama siguiente se muestra este patrón:

Descargar un archivo de Visio de esta arquitectura.

Esta arquitectura usa el protocolo seguridad de la capa de transporte (TLS) para cifrar el tráfico en cada paso.

• Un cliente envía paquetes a Application Gateway, un equilibrador de carga. Se ejecuta con la adición opcional Azure Web Application Firewall.

• Application Gateway descifra los paquetes y busca amenazas para las aplicaciones web. Si no encuentra ninguna amenaza, usa principios de confianza cero para cifrar los paquetes. A continuación, los libera.

• Azure Firewall Premium ejecuta comprobaciones de seguridad:

  • inspección de la capa de transporte (TLS) descifra y examina los paquetes.
  • características de detección y protección de intrusiones comprueban los paquetes para la intención malintencionada.

• Si los paquetes superan las pruebas, Azure Firewall Premium realiza estos pasos:

  • Cifra los paquetes
  • Usa un servicio sistema de nombres de dominio (DNS) para determinar la máquina virtual (VM) de la aplicación.
  • Reenvía los paquetes a la máquina virtual de la aplicación.

Varios motores de inspección de esta arquitectura garantizan la integridad del tráfico:

• Web Application Firewall usa reglas para evitar ataques en la capa web. Entre los ejemplos de ataques se incluyen la inyección de código SQL y el scripting entre sitios. Para obtener más información sobre las reglas y el conjunto de reglas principales de Open Web Application Security Project (OWASP), consulte web Application Firewall CRS rule groups and rules.
• Azure Firewall Premium usa reglas genéricas de detección y prevención de intrusiones. Estas reglas ayudan a identificar archivos malintencionados y otras amenazas destinadas a las aplicaciones web.

Esta arquitectura admite diferentes tipos de diseño de red, que en este artículo se describen:

• Redes de concentrador y radio tradicionales
• Redes que usan Azure Virtual WAN como plataforma
• Redes que usan Azure Route Server para simplificar el enrutamiento dinámico

Resolución de nombres y Premium de Azure Firewall

Al comprobar si hay tráfico malintencionado, Azure Firewall Premium comprueba que el encabezado host HTTP coincide con la dirección IP del paquete y el puerto TCP. Por ejemplo, supongamos que Application Gateway envía paquetes web a la dirección IP 172.16.1.4 y al puerto TCP 443. El valor del encabezado host HTTP debe resolverse en esa dirección IP.

Los encabezados de host HTTP normalmente no contienen direcciones IP. En su lugar, los encabezados contienen nombres que coinciden con el certificado digital del servidor. En este caso, Azure Firewall Premium usa DNS para resolver el nombre del encabezado host en una dirección IP. El diseño de red determina qué solución DNS funciona mejor, como se describe en las secciones posteriores.

Certificados digitales

En el diagrama siguiente se muestran los nombres comunes (CN) y las entidades de certificación (CA) que usan las sesiones y certificados TLS de la arquitectura:

Conexiones TLS

Esta arquitectura contiene tres conexiones TLS distintas. Los certificados digitales validan cada uno:

Desde clientes a Application Gateway

En Application Gateway, implementará el certificado digital que ven los clientes. Normalmente, una entidad de certificación conocida como DigiCert o Let's Encrypt emite este tipo de certificado.

De Application Gateway a Azure Firewall Premium

Para descifrar e inspeccionar el tráfico TLS, Azure Firewall Premium genera certificados dinámicamente. Azure Firewall Premium también se presenta a Application Gateway como servidor web. Una entidad de certificación privada firma los certificados que genera Azure Firewall Premium. Para más información, consulte certificados de Azure Firewall Premium. Application Gateway debe validar esos certificados. En la configuración HTTP de la aplicación, configure la entidad de certificación raíz que usa Azure Firewall Premium.

Desde Azure Firewall Premium al servidor web

Azure Firewall Premium establece una sesión TLS con el servidor web de destino. Azure Firewall Premium comprueba que una entidad de certificación conocida firma los paquetes TLS del servidor web.

Roles de componente

Application Gateway y Azure Firewall Premium controlan los certificados de forma diferente entre sí porque sus roles difieren:

• Application Gateway es un proxy web inverso . Protege los servidores web de clientes malintencionados interceptando solicitudes HTTP y HTTPS. Declara cada servidor protegido que se encuentra en el grupo de back-end de Application Gateway con su dirección IP o nombre de dominio completo. Los clientes legítimos deben poder acceder a cada aplicación. Por lo tanto, configure Application Gateway con un certificado digital que haya firmado una entidad de certificación pública. Use una ENTIDAD de certificación que aceptará cualquier cliente TLS.
• Azure Firewall Premium es un proxy web de reenvío o, simplemente, un proxy web. Protege a los clientes de servidores web malintencionados interceptando las llamadas TLS de los clientes protegidos. Cuando un cliente protegido realiza una solicitud HTTP, el proxy de reenvío suplanta al servidor web de destino mediante la generación de certificados digitales y su presentación al cliente. Azure Firewall Premium usa una entidad de certificación privada, que firma los certificados generados dinámicamente. Configure los clientes protegidos para que confíen en esa entidad de certificación privada. En esta arquitectura, Azure Firewall Premium protege las solicitudes de Application Gateway al servidor web. Application Gateway confía en la entidad de certificación privada que usa Azure Firewall Premium.

Enrutamiento y reenvío de tráfico

El enrutamiento será ligeramente diferente en función de la topología del diseño de red, en las secciones siguientes se detallarán los detalles de los ejemplos de topología hub-and-spoke, Virtual WAN y Route Server. Sin embargo, hay algunos aspectos comunes a todas las topologías:

• Azure Application Gateway siempre se comporta como un proxy y Azure Firewall Premium también lo hace cuando se configura para la inspección de TLS: las sesiones TLS de los clientes finalizarán mediante Application Gateway y las nuevas sesiones TLS se compilarán en Azure Firewall. Azure Firewall recibirá y finalizará las sesiones TLS procedentes de Application Gateway y creará nuevas sesiones TLS para las cargas de trabajo. Este hecho tiene implicaciones para la configuración de IDPS de Azure Firewall Premium, las secciones siguientes contienen más detalles sobre esto.
• La carga de trabajo verá las conexiones procedentes de la dirección IP de la subred de Azure Firewall. La dirección IP del cliente original se conserva en el encabezado HTTP X-Forwarded-For insertado por Application Gateway.
• El tráfico de Application Gateway a la carga de trabajo se envía normalmente a Azure Firewall mediante mecanismos de enrutamiento de Azure, ya sea con User-Defined rutas configuradas en la subred de Application Gateway o con rutas insertadas por Azure Virtual WAN o Azure Route Server. Aunque es posible definir explícitamente la dirección IP privada de Azure Firewall en el grupo de back-end de Application Gateway, técnicamente no se recomienda, ya que quita parte de la funcionalidad de Azure Firewall, como el equilibrio de carga y la permanencia.

En las secciones siguientes se detallan algunas de las topologías más comunes que se usan con Azure Firewall y Application Gateway.

Topología en estrella tipo hub-and-spoke

Normalmente, un diseño de concentrador y radio implementa componentes de red compartidos en la red virtual del concentrador y componentes específicos de la aplicación en los radios. En la mayoría de los sistemas, Azure Firewall Premium es un recurso compartido. Pero el firewall de aplicaciones web puede ser un dispositivo de red compartido o un componente específico de la aplicación. Por los siguientes motivos, suele ser mejor tratar Application Gateway como un componente de aplicación e implementarlo en una red virtual de radio:

• Puede ser difícil solucionar problemas de alertas de Firewall de aplicaciones web. Por lo general, necesita conocimientos detallados de la aplicación para decidir si los mensajes que desencadenan esas alarmas son legítimos.
• Si trata Application Gateway como un recurso compartido, puede superar límites de Azure Application Gateway.
• Es posible que tenga problemas de control de acceso basado en rol si implementa Application Gateway en el centro. Esta situación puede surgir cuando los equipos administran diferentes aplicaciones, pero usan la misma instancia de Application Gateway. A continuación, cada equipo tiene acceso a toda la configuración de Application Gateway.

Con las arquitecturas de concentrador y radio tradicionales, las zonas privadas DNS proporcionan una manera fácil de usar DNS:

• Configure una zona privada DNS.
• Vincule la zona a la red virtual que contiene Azure Firewall Premium.
• Asegúrese de que existe un registro A para el valor que Application Gateway usa para el tráfico y para las comprobaciones de estado.

En el diagrama siguiente se muestra el flujo de paquetes cuando Application Gateway está en una red virtual de radio. En este caso, un cliente se conecta desde la red pública de Internet.

1. Un cliente envía una solicitud a un servidor web.
2. Application Gateway intercepta los paquetes de cliente y los examina. Si los paquetes pasan la inspección, Application Gateway enviará el paquete a la máquina virtual de back-end. Cuando el paquete llega a Azure, una ruta definida por el usuario (UDR) en la subred de Application Gateway reenvía los paquetes a Azure Firewall Premium.
3. Azure Firewall Premium ejecuta comprobaciones de seguridad en los paquetes. Si superan las pruebas, Azure Firewall Premium reenvía los paquetes a la máquina virtual de la aplicación.
4. La máquina virtual responde y establece la dirección IP de destino en Application Gateway. Una UDR de la subred de la máquina virtual redirige los paquetes a Azure Firewall Premium.
5. Azure Firewall Premium reenvía los paquetes a Application Gateway.
6. Application Gateway responde al cliente.

El tráfico también puede llegar desde una red local en lugar de la red pública de Internet. El tráfico fluye a través de una red privada virtual (VPN) de sitio a sitio o a través de ExpressRoute. En este escenario, el tráfico llega primero a una puerta de enlace de red virtual en el centro. El resto del flujo de red es el mismo que el caso anterior.

1. Un cliente local se conecta a la puerta de enlace de red virtual.
2. La puerta de enlace reenvía los paquetes de cliente a Application Gateway.
3. Application Gateway examina los paquetes. Si pasan la inspección, una UDR de la subred de Application Gateway reenvía los paquetes a Azure Firewall Premium.
4. Azure Firewall Premium ejecuta comprobaciones de seguridad en los paquetes. Si superan las pruebas, Azure Firewall Premium reenvía los paquetes a la máquina virtual de la aplicación.
5. La máquina virtual responde y establece la dirección IP de destino en Application Gateway. Una UDR de la subred de la máquina virtual redirige los paquetes a Azure Firewall Premium.
6. Azure Firewall Premium reenvía los paquetes a Application Gateway.
7. Application Gateway envía los paquetes a la puerta de enlace de red virtual.
8. La puerta de enlace responde al cliente.

Topología de Virtual WAN

También puede usar el servicio de red de Virtual WAN en esta arquitectura. Este componente ofrece muchas ventajas. Por ejemplo, elimina la necesidad de udR mantenidos por el usuario en redes virtuales de radio. En su lugar, puede definir rutas estáticas en tablas de rutas del centro de conectividad virtual. La programación de cada red virtual que se conecta al centro contiene estas rutas.

Cuando se usa Virtual WAN como plataforma de red, se producen dos diferencias principales:

• No se pueden vincular zonas privadas DNS a un centro virtual porque Microsoft administra centros virtuales. Como propietario de la suscripción, no tiene permisos para vincular zonas DNS privadas. Como resultado, no se puede asociar una zona privada DNS con el centro seguro que contiene Azure Firewall Premium. Para implementar la resolución DNS para Azure Firewall Premium, use servidores DNS en su lugar:

  • Configure la configuración de DNS de Azure Firewall para usar servidores DNS personalizados.
  • Implemente los servidores en una red virtual de servicios compartidos que se conecte a la WAN virtual.
  • Vincule una zona privada DNS a la red virtual de servicios compartidos. Los servidores DNS pueden resolver los nombres que Application Gateway usa en encabezados de host HTTP. Para más información, consulte configuración de DNS de Azure Firewall.

• Solo puede usar Virtual WAN para programar rutas en un radio si el prefijo es más corto (menos específico) que el prefijo de red virtual. Por ejemplo, en los diagramas anteriores a la red virtual radial tiene el prefijo 172.16.0.0/16: en este caso, Virtual WAN no podría insertar una ruta que coincida con el prefijo de red virtual (172.16.0.0/16) ni ninguna de las subredes (172.16.0.0/24, 172.16.1.0/24). En otras palabras, Virtual WAN no puede atraer el tráfico entre dos subredes que se encuentran en la misma red virtual. Esta limitación se hace evidente cuando Application Gateway y el servidor web de destino están en la misma red virtual: Virtual WAN no puede forzar el tráfico entre Application Gateway y el servidor web para pasar por Azure Firewall Premium (una solución alternativa sería configurar manualmente las rutas definidas por el usuario en las subredes de Application Gateway y el servidor web).

En el diagrama siguiente se muestra el flujo de paquetes en un caso que usa Virtual WAN. En esta situación, el acceso a Application Gateway es desde una red local. Una VPN de sitio a sitio o ExpressRoute conecta esa red a Virtual WAN. El acceso desde Internet es similar.

1. Un cliente local se conecta a la VPN.
2. La VPN reenvía los paquetes de cliente a Application Gateway.
3. Application Gateway examina los paquetes. Si pasan la inspección, la subred de Application Gateway reenvía los paquetes a Azure Firewall Premium.
4. Azure Firewall Premium solicita la resolución DNS desde un servidor DNS en la red virtual de servicios compartidos.
5. El servidor DNS responde a la solicitud de resolución.
6. Azure Firewall Premium ejecuta comprobaciones de seguridad en los paquetes. Si superan las pruebas, Azure Firewall Premium reenvía los paquetes a la máquina virtual de la aplicación.
7. La máquina virtual responde y establece la dirección IP de destino en Application Gateway. La subred Application redirige los paquetes a Azure Firewall Premium.
8. Azure Firewall Premium reenvía los paquetes a Application Gateway.
9. Application Gateway envía los paquetes a la VPN.
10. La VPN responde al cliente.

Con este diseño, es posible que tenga que modificar el enrutamiento que el centro anuncia en las redes virtuales de radio. En concreto, Application Gateway v2 solo admite una ruta 0.0.0.0/0 que apunta a Internet. Las rutas con esta dirección que no apuntan a Internet interrumpen la conectividad que Microsoft requiere para administrar Application Gateway. Si el centro virtual anuncia una ruta 0.0.0.0/0, evite que esa ruta se propague a la subred de Application Gateway mediante uno de estos pasos:

• Cree una tabla de rutas con una ruta para 0.0.0.0/0 y un tipo de próximo salto de Internet. Asocie esa ruta a la subred en la que implemente Application Gateway.
• Si implementa Application Gateway en un radio dedicado, deshabilite la propagación de la ruta predeterminada en la configuración de la conexión de red virtual.

Topología de Route Server

Route Server ofrece otra manera de insertar rutas automáticamente en radios. Con esta funcionalidad, se evita la sobrecarga administrativa del mantenimiento de las tablas de rutas. Route Server combina las variantes virtual WAN y hub-and spoke:

• Con Route Server, los clientes administran redes virtuales de concentrador. Como resultado, puede vincular la red virtual del concentrador a una zona privada DNS.
• Route Server tiene la misma limitación que Virtual WAN tiene respecto a los prefijos de dirección IP. Solo puede insertar rutas en un radio si el prefijo es más corto (menos específico) que el prefijo de red virtual. Debido a esta limitación, Application Gateway y el servidor web de destino deben estar en diferentes redes virtuales.

En el diagrama siguiente se muestra el flujo de paquetes cuando Route Server simplifica el enrutamiento dinámico. Tenga en cuenta estos puntos:

• Actualmente, Route Server requiere el dispositivo que inserta las rutas para enviarlos a través del Protocolo de puerta de enlace de borde (BGP). Dado que Azure Firewall Premium no admite BGP, use en su lugar una aplicación virtual de red (NVA) de terceros.
• La funcionalidad de la aplicación virtual de red en el centro determina si la implementación necesita DNS.

1. Un cliente local se conecta a la puerta de enlace de red virtual.
2. La puerta de enlace reenvía los paquetes de cliente a Application Gateway.
3. Application Gateway examina los paquetes. Si pasan la inspección, la subred de Application Gateway reenvía los paquetes a una máquina back-end. Una ruta de la subred ApplicationGateway insertada por route Server reenviaría el tráfico a una aplicación virtual de red.
4. La aplicación virtual de red ejecuta comprobaciones de seguridad en los paquetes. Si superan las pruebas, la aplicación virtual de red reenvía los paquetes a la máquina virtual de la aplicación.
5. La máquina virtual responde y establece la dirección IP de destino en Application Gateway. Una ruta insertada en la subred de la máquina virtual por route Server redirige los paquetes a la NVA.
6. La aplicación virtual de red reenvía los paquetes a Application Gateway.
7. Application Gateway envía los paquetes a la puerta de enlace de red virtual.
8. La puerta de enlace responde al cliente.

Al igual que con Virtual WAN, es posible que tenga que modificar el enrutamiento al usar Route Server. Si anuncia la ruta 0.0.0.0/0, puede propagarse a la subred de Application Gateway. Pero Application Gateway no admite esa ruta. En este caso, configure una tabla de rutas para la subred de Application Gateway. Incluya una ruta para 0.0.0.0/0 y un tipo de próximo salto de Internet en esa tabla.

IDPS y direcciones IP privadas

Como se explica en reglas de IDPS de Azure Firewall, Azure Firewall Premium decidirá qué reglas IDPS se aplicarán en función de las direcciones IP de origen y destino de los paquetes. Azure Firewall tratará las direcciones IP privadas predeterminadas en los intervalos RFC 1918 (10.0.0.0/8, 192.168.0.0/16 y 172.16.0.0/12) y el intervalo RFC 6598 (100.64.0.0/10) como interno. Por lo tanto, si como en los diagramas de este artículo, Application Gateway se implementa en una subred de uno de estos intervalos (172.16.0.0/24 en los ejemplos anteriores), Azure Firewall Premium considerará el tráfico entre Application Gateway y la carga de trabajo para que sea interno y solo se aplicarán firmas IDPS marcadas para aplicarse al tráfico interno o a cualquier tráfico. Las firmas IDPS marcadas para aplicar el tráfico entrante o saliente no se aplicarán al tráfico entre Application Gateway y la carga de trabajo.

La manera más fácil de forzar la aplicación de reglas de firma entrantes de IDPS al tráfico entre Application Gateway y la carga de trabajo es colocar Application Gateway en una subred con un prefijo fuera de los intervalos privados. No es necesario usar necesariamente direcciones IP públicas para esta subred, pero en su lugar puede personalizar las direcciones IP que Azure Firewall Premium trata como internas para IDPS. Por ejemplo, si su organización no usa el intervalo de 100.64.0.0/10, podría eliminar este intervalo de la lista de prefijos internos para IDPS (consulte intervalos IPDS privados de Azure Firewall Premium para obtener más información sobre cómo hacerlo) e implementar Application Gateway en una subred configurada con una dirección IP en 100.64.0.0/10.

Colaboradores

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

Autor principal:

• Jose Moreno | Ingeniero principal de clientes

Pasos siguientes

• Redes seguras con de confianza cero
• enrutamiento de tráfico de red virtual
• Funcionamiento de una puerta de enlace de aplicaciones

Recursos relacionados

• [Protección y control de cargas de trabajo con segmentación de nivel de red][Protección y control de cargas de trabajo con segmentación de nivel de red]
• Implementación de una red híbrida segura
• topología de red en estrella tipo hub-spoke de en Azure
• topología de red en estrella tipo hub-and-spoke de con Azure Virtual WAN