Uso de una configuración de DNS de cerebro dividido para hospedar una aplicación web en Azure

Azure Front Door
Azure Application Gateway
Azure ExpressRoute
Azure DNS

Los equipos que administran cargas de trabajo suelen depender de nombres de dominio completos (FQDN) para el acceso de los clientes. Los FQDN se combinan normalmente con la indicación de nombre de servidor (SNI) de seguridad de la capa de transporte (TLS). Con este enfoque, cuando los clientes públicos acceden a una carga de trabajo desde la red pública de Internet o los clientes empresariales acceden a una carga de trabajo internamente, el enrutamiento a la aplicación podría seguir rutas fijas y tener varios niveles de seguridad o calidad de servicio (QoS).

En la arquitectura siguiente se muestra un enfoque para diferenciar cómo se trata el tráfico en función del sistema de nombres de dominio (DNS) y si el cliente se origina desde Internet o desde una red corporativa.

Architecture

Diagrama de la arquitectura de hospedaje de aplicaciones.

Descargue un archivo de Visio de esta arquitectura.

En las secciones de flujo de trabajo siguientes se describen dos configuraciones: un flujo de trabajo de Internet público y un flujo de trabajo privado. Combine los dos flujos de trabajo para implementar una arquitectura de hospedaje de cerebro dividido.

Flujo de trabajo público de Internet

Diagrama del flujo de trabajo de Internet público.

Descargue un archivo de Visio de esta arquitectura.

  1. Los clientes envían una solicitud para la aplicación app.contoso.com a través de la red pública de Internet.

  2. Una zona DNS de Azure está configurada para el dominio contoso.com. Las entradas de nombre canónico (CNAME) adecuadas están configuradas para los puntos de conexión de Azure Front Door.

  3. Los clientes externos acceden a la aplicación web a través de Azure Front Door Estándar o Premium, que funciona como equilibrador de carga global y un firewall de aplicaciones web (WAF).

    • En Azure Front Door, app.contoso.com se asigna como FQDN mediante rutas en un punto de conexión configurado. Azure Front Door también hospeda los certificados SNI TLS para las aplicaciones.

      Note

      Azure Front Door no admite certificados autofirmados.

    • Azure Front Door enruta las solicitudes al grupo de origen configurado en función del encabezado HTTP del Host del cliente.

    • El grupo de origen está configurado para que apunte a la instancia de Azure Application Gateway a través de la dirección IP pública de Application Gateway.

  4. Un grupo de seguridad de red (NSG) está configurado en la subred AppGW para permitir el acceso entrante en el puerto 80 y el puerto 443 desde la etiqueta de servicio AzureFrontDoor.Backend. El NSG no permite el tráfico entrante en el puerto 80 y el puerto 443 desde la etiqueta de servicio de Internet.

    Note

    La etiqueta de servicio AzureFrontDoor.Backend no limita el tráfico únicamente a la instancia de Azure Front Door. La validación se produce en la siguiente fase.

  5. La instancia de Application Gateway tiene un agente de escucha en el puerto 443. El tráfico se enruta al back-end en función del nombre de host especificado en el agente de escucha.

    • Para asegurarse de que el tráfico se origina en el perfil de Azure Front Door, configure una regla de WAF personalizada para comprobar el valor del X-Azure-FDID encabezado.

    • Azure genera un identificador único para cada perfil de Azure Front Door. El identificador único es el valor Azure Front Door ID ubicado en la página de información general del portal de Azure.

  6. El tráfico llega al recurso de cómputo configurado como un grupo de back-end en Application Gateway.

Flujo de trabajo de empresa privada

Diagrama del flujo de trabajo de la empresa privada.

Descargue un archivo de Visio de esta arquitectura.

  1. Los clientes inician una solicitud para la aplicación app.contoso.com desde un entorno local.

  2. Los FQDN de aplicación se configuran en el proveedor DNS local. Este proveedor DNS puede ser servidores DNS de Active Directory Domain Services (AD DS) locales u otras soluciones de asociados. Las entradas DNS de cada uno de los FQDN de la aplicación están configuradas para que apunten a la dirección IP privada de la instancia de Application Gateway.

  3. Un circuito ExpressRoute de Azure o una VPN de sitio a sitio facilita el acceso a Application Gateway.

  4. Un NSG se configura en la subred AppGW para permitir las solicitudes privadas entrantes desde redes de clientes en las instalaciones de donde se origina el tráfico. Esta configuración garantiza que otros orígenes de tráfico privado no puedan acceder directamente a la dirección IP privada de Application Gateway.

  5. Application Gateway tiene un agente de escucha configurado en el puerto 80 y el puerto 443. El tráfico se enruta al back-end en función del nombre de host especificado en el agente de escucha.

  6. Solo el tráfico de red privada alcanza la computación configurada como un grupo de back-end en Application Gateway.

Components

  • DNS es un sistema que asigna nombres de dominio a direcciones IP, lo que permite a los clientes localizar y conectarse a los servicios. Para un flujo de trabajo de Internet público en esta arquitectura, debe configurar una zona DNS pública con el CNAME adecuado del FQDN del punto de conexión de Azure Front Door. En el lado privado (empresarial), configure el proveedor DNS local (DNS de AD DS o una solución de asociado) para que apunte cada FQDN de aplicación a la dirección IP privada de Application Gateway.

  • Azure DNS Resolución privada es un servicio totalmente administrado que permite la resolución DNS entre entornos locales y Azure sin implementar servidores DNS personalizados. En esta arquitectura, el solucionador privado dns permite la resolución de clientes locales, por lo que los usuarios empresariales pueden usar esta solución DNS de cerebro dividido para acceder a las aplicaciones sin atravesar la red pública de Internet.

  • Azure Front Door es un equilibrador de carga global y WAF que proporciona una entrega rápida y segura de aplicaciones web a los clientes globales. En esta arquitectura, Azure Front Door Standard o Premium enruta a los clientes externos a la instancia de Application Gateway y proporciona opciones de almacenamiento en caché y optimización para mejorar la experiencia del cliente.

  • Application Gateway es un equilibrador de carga regional y WAF que proporciona alta disponibilidad, escalabilidad y seguridad para las aplicaciones web. En esta arquitectura, Application Gateway enruta las solicitudes de cliente internas y externas al proceso back-end y protege la aplicación web frente a ataques web comunes.

    Tanto Azure Front Door como Application Gateway proporcionan funcionalidades de WAF, pero el flujo de trabajo privado de esta solución no usa Azure Front Door. Como resultado, ambas arquitecturas usan la funcionalidad waf de Application Gateway.

  • ExpressRoute es un servicio que extiende las redes locales a la nube a través de una conexión privada establecida por un proveedor de conectividad. En esta arquitectura, ExpressRoute facilita la conectividad privada con Application Gateway para clientes locales.

Alternatives

Como solución alternativa, puede quitar Azure Front Door Estándar o Premium y, en su lugar, apuntar el registro DNS público a la dirección IP pública de Application Gateway. En función de los requisitos de esta arquitectura, debe cache y optimizar el tráfico en el punto de entrada en Azure. Como resultado, no puede usar la solución alternativa para este escenario. Para obtener más información, consulte Optimización de costos.

Diagrama de la arquitectura alternativa de hospedaje dns de cerebro dividido.

Descargue un archivo de Visio de esta arquitectura.

Otras posibles alternativas para el tráfico de entrada público en esta arquitectura incluyen:

  • Azure Traffic Manager: Traffic Manager es un servicio de enrutamiento de tráfico basado en DNS que distribuye el tráfico entre varias regiones y puntos de conexión. Puede usar Traffic Manager en lugar de Azure Front Door Estándar o Premium para enrutar a los clientes externos a la instancia de Application Gateway más cercana. Sin embargo, Azure Front Door proporciona características, como funcionalidades de WAF, almacenamiento en caché y afinidad de sesión. Traffic Manager no proporciona estas características.

  • Azure Load Balancer: Azure Load Balancer es un equilibrador de carga de red que proporciona alta disponibilidad y escalabilidad para el tráfico del Protocolo de control de transmisión (TCP) y del Protocolo de datagramas de usuario (UDP). Puede usar Load Balancer en lugar de Application Gateway para enrutar solicitudes de clientes externos e internos a servidores web back-end. Sin embargo, Application Gateway ofrece capacidades, como funcionalidades WAF, terminación de la capa de sockets seguros (SSL) y afinidad de sesión basada en cookies. Load Balancer no proporciona estas características.

Detalles del escenario

Este escenario resuelve el problema de hospedar una aplicación web que atiende a clientes externos e internos. Esta arquitectura garantiza que el tráfico siga una ruta de acceso adecuada basada en el origen de un cliente. Esta arquitectura:

  • Proporciona acceso rápido y confiable a través de Internet a una aplicación web para clientes no empresariales globales.

  • Proporciona a los clientes empresariales la capacidad de acceder a una aplicación sin atravesar la red pública de Internet.

  • Protege una aplicación web frente a ataques web comunes y tráfico malintencionado.

Casos de uso potenciales

Use esta arquitectura para escenarios que requieren:

  • Split-brain DNS: Esta solución usa Azure Front Door para clientes externos y Application Gateway para clientes internos, con registros DNS diferentes para cada servicio. Este enfoque ayuda a optimizar el rendimiento, la seguridad y la disponibilidad de la red para varios clientes.

  • Escalabilidad de aplicaciones: Esta solución usa Application Gateway, que puede distribuir el tráfico entre los recursos de proceso de back-end configurados. Este enfoque ayuda a mejorar el rendimiento y la disponibilidad de las aplicaciones y a admitir el escalado horizontal.

Considerations

Estas consideraciones implementan los pilares de Azure Well-Architected Framework, que es un conjunto de principios rectores que puede usar para mejorar la calidad de una carga de trabajo. Para obtener más información, consulte Well-Architected Framework.

Reliability

La confiabilidad ayuda a garantizar que la aplicación pueda cumplir los compromisos que realice para sus clientes. Para obtener más información, consulte Lista de comprobación de revisión de diseño para confiabilidad.

  • Identificar puntos de error. En esta arquitectura DNS de cerebro dividido, la confiabilidad depende del funcionamiento correcto de los componentes clave, como Azure Front Door, Application Gateway y configuraciones dns. Debe identificar posibles puntos de error, como configuraciones incorrectas, problemas de certificado SSL o sobrecargas de capacidad.

  • Evaluar el impacto. Debe evaluar el impacto de los errores. Para los clientes externos, cualquier interrupción en Azure Front Door, que actúa como puerta de enlace, podría afectar al acceso global. En el caso de los clientes internos, cualquier interrupción en Application Gateway podría impedir las operaciones empresariales.

  • Implementar estrategias de mitigación. Para mitigar los riesgos, implemente la redundancia en varias zonas de disponibilidad, use sondeos de estado para la supervisión en tiempo real y asegúrese de la configuración correcta del enrutamiento DNS para el tráfico externo e interno. Asegúrese de actualizar periódicamente los registros DNS y de tener un plan de recuperación ante desastres.

  • Supervise continuamente. Para vigilar atentamente la salud de su sistema, emplee las características de Azure Monitor. Configure alertas para anomalías y tenga un plan de respuesta a incidentes listo para solucionar rápidamente posibles problemas.

Cumpla estos principios para garantizar un sistema sólido y confiable que pueda resistir desafíos y mantener la continuidad del servicio.

Security

La seguridad proporciona garantías contra ataques deliberados y el uso indebido de sus valiosos datos y sistemas. Para obtener más información, consulte Lista de comprobación de revisión de diseño para seguridad.

  • Use el enfoque de Confianza cero. En la configuración de DNS de cerebro dividido, aplique el enfoque Confianza cero. Compruebe explícitamente la identidad de un cliente, tanto si se originan desde Internet como desde una red corporativa. Este enfoque garantiza que solo las entidades de confianza puedan realizar acciones autorizadas.

  • Implemente los controles de identidad y acceso de forma eficaz. Implemente Microsoft Entra ID para una sólida administración de identidades. Use las directivas de acceso condicional de Microsoft Entra para aplicar controles de acceso estrictos en función del contexto del cliente, el estado del dispositivo y la ubicación.

    • Evalúe las medidas de seguridad. Evalúe la eficacia de las medidas de seguridad para su carga de trabajo con acceso dual mediante la implementación de:

      • Evalúe sus inversiones defensivas con regularidad. Evalúe periódicamente la eficacia de Azure Front Door y Application Gateway. Asegúrese de que proporcionan protección significativa contra amenazas.

      • Restrinja el ámbito de impacto de posibles infracciones. Asegúrese de limitar las brechas de seguridad a un ámbito reducido. Por ejemplo, aísle eficazmente los flujos de tráfico externos e internos.

  • Supongamos que una infracción siempre es posible. Confirme que los atacantes pueden infringir los controles de seguridad. Prepárese para estos escenarios.

  • Implemente medidas de seguridad de forma exhaustiva. Implemente la segmentación de red, la microsegmentación y los NSG (grupos de seguridad de red). Supongamos que un atacante puede obtener acceso y diseñar controles de compensación en consecuencia.

Integre estos principios de seguridad en la arquitectura DNS del cerebro dividido para crear un sistema sólido y resistente que proteja el acceso interno y externo a la carga de trabajo.

Otras mejoras de seguridad

  • Application Gateway: Puede usar un WAF en Application Gateway para proteger sus aplicaciones web contra vulnerabilidades y ataques web comunes. También puede usar Azure Private Link para acceder de forma segura a los servidores de aplicaciones back-end desde Application Gateway sin exponerlos a la red pública de Internet.

  • Azure Firewall: Puede agregar un Azure firewall a la red virtual del concentrador y usar Azure Firewall inteligencia sobre amenazas para bloquear el tráfico malintencionado de direcciones IP y dominios malintencionados conocidos. También puede usar Azure Firewall como proxy DNS para interceptar e inspeccionar el tráfico DNS y aplicar reglas de filtrado dns.

  • Azure Front Door: Puede usar Azure Web Application Firewall para proteger las aplicaciones web frente a vulnerabilidades y exploits de seguridad web comunes en el borde. También puede usar Private Link con el nivel Azure Front Door Premium para acceder de forma segura a los servidores de aplicaciones back-end desde Azure Front Door sin exponerlos a la red pública de Internet.

Optimización de costos

La optimización de costos se centra en formas de reducir los gastos innecesarios y mejorar las eficiencias operativas. Para obtener más información, consulte Lista de comprobación de revisión de diseño para la optimización de costos.

  • Cómputo de back-end: Muchos factores, como la selección de SKU, el recuento de réplicas y la región, impulsan el costo de ejecutar servicios de cómputo de back-end. Asegúrese de tener en cuenta todos los elementos de un recurso de proceso antes de seleccionar la mejor opción para la carga de trabajo.

  • Application Gateway: Los costos de Application Gateway dependen del número de instancias, del tamaño de las instancias y de la cantidad de datos procesados. Puede optimizar el costo mediante el escalado automático para ajustar el número de instancias en función de la demanda del tráfico. También puede implementar SKU con redundancia de zona en zonas de disponibilidad para reducir la necesidad de instancias adicionales de alta disponibilidad.

  • Azure Front Door: Azure Front Door los costos dependen del número de reglas de enrutamiento, del número de solicitudes HTTP o HTTPS y de la cantidad de datos transferidos. Puede usar Azure Front Door Standard o Premium para obtener una experiencia unificada con Azure Content Delivery Network, Azure Web Application Firewall y Private Link. También puede usar la característica del motor de reglas de Azure Front Door para personalizar la administración del tráfico y optimizar el rendimiento y el costo.

Si el escenario no requiere acceso global o las características adicionales de Azure Front Door, puede usar esta solución solo con Application Gateway. Puede apuntar todos los registros DNS públicos a la dirección IP pública configurada en los agentes de escucha de Application Gateway.

Vea un ejemplo de esta solución que aproxima el uso típico de los componentes de esta arquitectura. Ajuste los costos para adecuarse a su escenario.

Contributors

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

Autor principal:

  • Troy Hite | Ingeniero sénior de soluciones

Otros colaboradores:

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

Pasos siguientes