Editar

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

Azure Application Gateway
Azure Firewall
Azure Virtual Network
Azure Virtual WAN
Firewall de aplicaciones web de Azure

En esta guía se describe una estrategia para implementar la seguridad de confianza cero para las aplicaciones web para la inspección y el 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 consultar más aspectos de la implementación segura de la aplicación, como la autenticación. Para este artículo, lo que funciona mejor es un enfoque multicapa, donde la seguridad de red constituye una de las capas del modelo de confianza cero. En este nivel, los dispositivos de red inspeccionan los paquetes para asegurarse de que solo llega tráfico legítimo a las aplicaciones.

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

  • Los firewalls de aplicaciones web buscan patrones que indiquen un ataque en el nivel de aplicación web.
  • Los firewalls de última generación también pueden buscar amenazas generales.

En algunas situaciones, puede combinar diferentes tipos de dispositivos de seguridad de red para aumentar la protección. En una guía independiente, Firewall y Application Gateway para redes virtuales, se describen los modelos de diseño que puede usar para organizar los distintos dispositivos. Este documento se centra en un patrón común para aumentar al máximo la seguridad, en el que Azure Application Gateway actúa antes que Azure Firewall Prémium. En el siguiente diagrama se muestra este patrón.

Diagrama de arquitectura que muestra el flujo de paquetes en una red de aplicaciones web que usa Application Gateway delante de Azure Firewall Prémium.

Descargue un archivo Visio de esta arquitectura.

Esta arquitectura usa el protocolo de 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 incorporación opcional de 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 Prémium ejecuta comprobaciones de seguridad:

  • Si los paquetes pasan las pruebas, Azure Firewall Prémium realiza estos pasos:

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

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

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

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

  • Redes tradicionales con topología en estrella tipo hub-and-spoke
  • Redes que usan Azure Virtual WAN como plataforma
  • Redes que usan Azure Route Server para simplificar el enrutamiento dinámico

Azure Firewall Prémium y resolución de nombres

Al comprobar si hay tráfico malintencionado, Azure Firewall Prémium 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.

Normalmente, los encabezados host HTTP no contienen direcciones IP. En su lugar, los encabezados contienen nombres que coinciden con el certificado digital del servidor. En este caso, Azure Firewall Prémium 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 secciones posteriores.

Nota

Application Gateway no admite números de puerto en encabezados host HTTP. Como resultado:

  • Azure Firewall Prémium supone un puerto TCP HTTPS predeterminado que es el 443.
  • La conexión entre Application Gateway y el servidor web solo admite el puerto TCP 443 y no los puertos que no son estándar.

Certificados digitales

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

Diagrama de arquitectura que muestra los nombres comunes y las entidades de certificación que usa una red de aplicaciones web cuando un equilibrador de carga está delante de un firewall.

Conexiones TLS

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

De clientes a Application Gateway

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

De Application Gateway a Azure Firewall Prémium

Para descifrar e inspeccionar el tráfico TLS, Azure Firewall Prémium genera dinámicamente certificados. Azure Firewall Prémium también se presenta a Application Gateway como el servidor web. Una entidad de certificación privada firma los certificados que Azure Firewall Prémium genera. Para más información, consulte Certificados de Azure Firewall Prémium. 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 Prémium.

Desde Azure Firewall Prémium al servidor web

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

Roles de componente

Application Gateway y Azure Firewall Prémium controlan los certificados de forma diferente entre sí porque sus roles son diferentes:

  • Application Gateway es un proxy web inverso. Protege los servidores web de clientes malintencionados mediante la interceptación de solicitudes HTTP y HTTPS. Puede declarar 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, puede configurar Application Gateway con un certificado digital firmado por una entidad de certificación pública. Use una entidad de certificación que cualquier cliente TLS acepte.
  • Azure Firewall Prémium es un proxy web de reenvío o, simplemente, un proxy web. Protege a los clientes de servidores web malintencionados mediante la interceptación de llamadas TLS desde clientes protegidos. Cuando un cliente protegido realiza una solicitud HTTP, el proxy de reenvío suplanta el servidor web de destino generando certificados digitales y presentándolos al cliente. Azure Firewall Prémium usa una entidad de certificación privada, que firma los certificados generados dinámicamente. Puede configurar los clientes protegidos para que confíen en esa entidad de certificación privada. En esta arquitectura, Azure Firewall Prémium protege las solicitudes de Application Gateway al servidor web. Application Gateway confía en la entidad de certificación privada que usa Azure Firewall Prémium.

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 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 creará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 al respecto.
  • 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 X-Forwarded-For encabezado HTTP 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 rutas definidas por el usuario 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 de red en estrella tipo hub-and-spoke

Normalmente, un diseño de topología de red en estrella de tipo hub-and-spoke implementa componentes de red compartidos en la red virtual del centro de conectividad y componentes específicos de la aplicación en los radios. En la mayoría de los sistemas, Azure Firewall Prémium es un recurso compartido. Pero Web Application Firewall puede ser un dispositivo de red compartido o un componente específico de la aplicación. Por los siguientes motivos, normalmente es mejor considerar a Application Gateway como un componente de aplicación e implementarlo en una red virtual radial:

  • Puede ser difícil solucionar problemas de las alertas de Web Application Firewall. Por lo general, necesita un conocimiento profundo de la aplicación para decidir si los mensajes que desencadenan esas alarmas son legítimos.
  • Si considera Application Gateway como un recurso compartido, es posible que supere los límites de Azure Application Gateway.
  • Es posible que experimente problemas de control de acceso basado en roles si implementa Application Gateway en el centro de conectividad. Esta situación puede aparecer cuando los equipos administran aplicaciones diferentes pero usan la misma instancia de Application Gateway. Por ello, cada equipo tiene acceso a toda la configuración de Application Gateway.

Con las arquitecturas tradicionales de topología en estrella tipo hub-and-spoke, las zonas privadas DNS proporcionan una manera fácil de usar DNS:

  • Configuración de una zona DNS privada
  • Vincule la zona a la red virtual que contiene Azure Firewall Prémium.
  • 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 radial. En este caso, un cliente se conecta desde la red pública de Internet.

Diagrama de arquitectura que muestra el flujo de paquetes en una red con topología en estrella tipo hub-and-spoke con un equilibrador de carga y un firewall. Los clientes se conectan 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ía el paquete a la máquina virtual de back-end. Cuando el paquete llega a Azure, una ruta definida por el usuario (UDR) de la subred de Application Gateway reenvía los paquetes a Azure Firewall Prémium.
  3. Azure Firewall Prémium ejecuta comprobaciones de seguridad en los paquetes. Si pasan las pruebas, Azure Firewall Prémium 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 Prémium.
  5. Azure Firewall Prémium 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 desde la red pública de Internet. El tráfico fluye a través de una red privada virtual 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 del centro de conectividad. El resto del flujo de red es el mismo que en el caso anterior.

Diagrama de arquitectura que muestra el flujo de paquetes en una red con topología en estrella tipo hub-and-spoke con un equilibrador de carga y un firewall. Los clientes se conectan desde una red local.

  1. Un cliente local se conecta a la puerta de enlace de la red virtual.
  2. La puerta de enlace reenvía los paquetes del cliente a Application Gateway.
  3. Application Gateway examina los paquetes. Si los paquetes pasan la inspección, una UDR en la subred de Application Gateway reenvía los paquetes a Azure Firewall Prémium.
  4. Azure Firewall Prémium ejecuta comprobaciones de seguridad en los paquetes. Si pasan las pruebas, Azure Firewall Prémium 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 Prémium.
  6. Azure Firewall Prémium 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 redes Virtual WAN en esta arquitectura. Este componente ofrece muchas ventajas. Por ejemplo, elimina la necesidad de UDR mantenidas por el usuario en redes virtuales radiales. 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 de conectividad contiene estas rutas.

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

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

    • Establezca 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 instancia de Virtual WAN.
    • Vincule una zona DNS privada a la red virtual de servicios compartidos. A continuación, los servidores DNS pueden resolver los nombres que Application Gateway usa en encabezados 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 de la red virtual. Por ejemplo, en los diagramas anteriores, la red de radio VNet 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 VNet (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 tráfico entre dos subredes que estén en la misma VNet. Esta limitación se hace evidente cuando Application Gateway y el servidor web de destino se encuentran en la misma red virtual: la WAN virtual no puede forzar que el tráfico entre Application Gateway y el servidor web pase por Azure Firewall Premium (una solución sería configurar manualmente las rutas definidas por el usuario en las subredes de la puerta de enlace de aplicaciones 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 parecido.

Diagrama de arquitectura que muestra el flujo de paquetes en una red con topología en estrella de tipo hub-and-spoke que incluye un equilibrador de carga, un firewall y Virtual WAN.

  1. Un cliente local se conecta a la VPN.
  2. La VPN reenvía los paquetes del cliente a Application Gateway.
  3. Application Gateway examina los paquetes. Si los paquetes pasan la inspección, la subred de Application Gateway reenvía los paquetes a Azure Firewall Prémium.
  4. Azure Firewall Prémium 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 Prémium ejecuta comprobaciones de seguridad en los paquetes. Si pasan las pruebas, Azure Firewall Prémium 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 de Application redirige los paquetes a Azure Firewall Premium.
  8. Azure Firewall Prémium 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 de conectividad anuncia a las redes virtuales radiales. 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 apunten a Internet interrumpirán la conectividad que Microsoft requiere para administrar Application Gateway. Si el centro de conectividad 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 ha implementado 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 los radios. Con esta funcionalidad, se evita la sobrecarga administrativa que supone mantener las tablas de rutas. Route Server combina Virtual WAN con las variantes de topologías en estrella de tipo hub-and-spoke:

  • Con Route Server, los clientes administran redes virtuales de centro de conectividad. Como resultado, puede vincular la red virtual del centro de conectividad a una zona DNS privada.
  • Route Server tiene la misma limitación que Virtual WAN con 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 de la red virtual. Debido a esta limitación, Application Gateway y el servidor web de destino deben estar en redes virtuales diferentes.

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

  • Route Server requiere actualmente que el dispositivo que inserta las rutas las envíe al protocolo de puerta de enlace de borde (BGP). Como Azure Firewall Prémium no admite BGP, use una aplicación virtual de red (NVA) de terceros en su lugar.
  • La funcionalidad de la aplicación virtual de red del centro de conectividad determina si la implementación necesita DNS.

Diagrama de arquitectura que muestra el flujo de paquetes en una red con topología en estrella de tipo hub-and-spoke que incluye un equilibrador de carga, un firewall y Route Server.

  1. Un cliente local se conecta a la puerta de enlace de la red virtual.
  2. La puerta de enlace reenvía los paquetes del 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 de ApplicationGateway que inserta 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 pasan 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 que Route Server inserta en la subred de la máquina virtual redirige los paquetes a la aplicación virtual de red.
  6. Esta aplicación 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 Virtual WAN, es posible que tenga que modificar el enrutamiento cuando use Route Server. Si anuncia la ruta 0.0.0.0/0, podría 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 de 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 RFC 6598 (100.64.0.0/10) como internos. 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 100.64.0.0/10, podría eliminarlo de la lista de prefijos internos para IDPS (consulte Intervalos de 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 lo escribieron los siguientes colaboradores.

Autor principal:

Pasos siguientes