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.

Arquitectura

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

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. Se configura una de zona dns de Azure para el dominio de 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, que funciona como un equilibrador de carga global y un firewall de aplicaciones web (WAF).

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

     Nota

     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. Se configura un de grupo de seguridad de red (NSG) de 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.

   Nota

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

5. La instancia de Application Gateway tiene un de escucha de 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 del identificador de Front Door ubicado en la página de información general de Azure Portal.

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

Flujo de trabajo de 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 Windows Server Active Directory 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 de NSG de está configurado en la subred AppGW para permitir solicitudes privadas entrantes desde redes de clientes locales desde las que 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 de escucha de que está 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 el proceso configurado como un grupo de back-end en Application Gateway.

Componentes

• DNS: para un flujo de trabajo de Internet público, debe configurar una zona DNS de Azure 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 Windows Server Active Directory o una solución de asociado) para que apunte cada FQDN de aplicación a la dirección IP privada de Application Gateway.

• Solucionador privado de Azure DNS: puede usar el solucionador privado dns para la resolución de clientes locales. Los clientes empresariales pueden usar esta solución DNS de cerebro dividido para obtener acceso a las aplicaciones sin atravesar la red pública de Internet.

• Azure Front Door: 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 de todo el mundo. En esta arquitectura, Azure Front Door enruta 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: 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. Por lo tanto, ambas arquitecturas usan la funcionalidad waf de Application Gateway.

• ExpressRoute: puede usar ExpressRoute para ampliar las redes locales a Microsoft Cloud a través de una conexión privada, con la ayuda de un proveedor de conectividad. En esta arquitectura, puede usar ExpressRoute para facilitar la conectividad privada a Application Gateway para los clientes locales.

Alternativas

Como solución alternativa, puede quitar Azure Front Door y, en su lugar, apuntar el registro DNS de Azure público a la dirección IP pública de Application Gateway. En función de los requisitos de esta arquitectura, debe realizar el almacenamiento en caché y la optimización en el punto de entrada en Azure. Por lo tanto, la solución alternativa no es una opción para este escenario. Para obtener más información, consulte Optimización de costos.

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 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 proporciona características, como funcionalidades de WAF, terminación de 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 que no son empresariales de todo el mundo.

• 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:

• DNS de cerebro dividido: 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 back-end configurados. Este enfoque ayuda a mejorar el rendimiento y la disponibilidad de las aplicaciones y a admitir el escalado horizontal.

Consideraciones

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.

Fiabilidad

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 redundancia en varias zonas de disponibilidad, use sondeos de estado para la supervisión en tiempo real y asegúrese de que 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.

• Supervisión continua: para mantenerse atento al estado del sistema, emplee 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.

Seguridad

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 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 realicen acciones autorizadas.

• Implementación: implemente el identificador de Entra de Microsoft 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.

• Evaluar la eficacia de la seguridad: evalúe la eficacia de las medidas de seguridad para la carga de trabajo de acceso dual mediante la implementación de:

  • Inversiones defensivas: evalúe periódicamente la eficacia de Azure Front Door y Application Gateway. Asegúrese de que proporcionan protección significativa contra amenazas.

  • Restricción de radio de explosión: asegúrese de que contiene infracciones de seguridad dentro de un ámbito limitado. Por ejemplo, aísle eficazmente los flujos de tráfico externos e internos.

• Asumir una infracción: confirme que los atacantes pueden infringir los controles de seguridad. Prepárese para estos escenarios.

• Implementar medidas de seguridad: implemente la segmentación de red, la microsegmentación y los 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 una waf de en Application Gateway para proteger las aplicaciones web frente a vulnerabilidades y vulnerabilidades 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 firewall de Azure a la red virtual del centro de conectividad y usar la inteligencia sobre amenazas de Azure Firewall 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 web comunes y vulnerabilidades de seguridad en el perímetro. 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.

• Proceso 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 proceso back-end. Asegúrese de tener en cuenta todos los elementos de un recurso de proceso de 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 para lograr una alta disponibilidad.

• Azure Front Door: los costos de Azure Front Door 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 el nivel Estándar o El nivel Premium de Azure Front Door 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 ajustarse a su escenario.

Colaboradores

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

Autor principal:

• Troy Hite | Arquitecto sénior de soluciones en la nube

Otros colaboradores:

• Álgebara de Mays | Cinturón negro global sénior de Azure Networking
• Adam Torkar - España | Cinturón negro global sénior de Azure Networking
• Michael McKechney | Especialista principal en tecnología de Azure

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

Pasos siguientes

• Configuración de la infraestructura de Application Gateway
• TLS de un extremo a otro con Azure Front Door
• Adición de un dominio personalizado a Azure Front Door
• ¿Qué es el filtrado geográfico en un dominio para Azure Front Door?

Recursos relacionados

• Firewall y Application Gateway para redes virtuales
• Uso de Azure Front Door en una solución multiinquilino

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.

Arquitectura

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

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. Se configura una de zona dns de Azure para el dominio de 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, que funciona como un equilibrador de carga global y un firewall de aplicaciones web (WAF).

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

     Nota

     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. Se configura un de grupo de seguridad de red (NSG) de 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.

   Nota

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

5. La instancia de Application Gateway tiene un de escucha de 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 del identificador de Front Door ubicado en la página de información general de Azure Portal.

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

Flujo de trabajo de 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 Windows Server Active Directory 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 de NSG de está configurado en la subred AppGW para permitir solicitudes privadas entrantes desde redes de clientes locales desde las que 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 de escucha de que está 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 el proceso configurado como un grupo de back-end en Application Gateway.

Componentes

• DNS: para un flujo de trabajo de Internet público, debe configurar una zona DNS de Azure 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 Windows Server Active Directory o una solución de asociado) para que apunte cada FQDN de aplicación a la dirección IP privada de Application Gateway.

• Solucionador privado de Azure DNS: puede usar el solucionador privado dns para la resolución de clientes locales. Los clientes empresariales pueden usar esta solución DNS de cerebro dividido para obtener acceso a las aplicaciones sin atravesar la red pública de Internet.

• Azure Front Door: 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 de todo el mundo. En esta arquitectura, Azure Front Door enruta 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: 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. Por lo tanto, ambas arquitecturas usan la funcionalidad waf de Application Gateway.

• ExpressRoute: puede usar ExpressRoute para ampliar las redes locales a Microsoft Cloud a través de una conexión privada, con la ayuda de un proveedor de conectividad. En esta arquitectura, puede usar ExpressRoute para facilitar la conectividad privada a Application Gateway para los clientes locales.

Alternativas

Como solución alternativa, puede quitar Azure Front Door y, en su lugar, apuntar el registro DNS de Azure público a la dirección IP pública de Application Gateway. En función de los requisitos de esta arquitectura, debe realizar el almacenamiento en caché y la optimización en el punto de entrada en Azure. Por lo tanto, la solución alternativa no es una opción para este escenario. Para obtener más información, consulte Optimización de costos.

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 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 proporciona características, como funcionalidades de WAF, terminación de 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 que no son empresariales de todo el mundo.

• 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:

• DNS de cerebro dividido: 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 back-end configurados. Este enfoque ayuda a mejorar el rendimiento y la disponibilidad de las aplicaciones y a admitir el escalado horizontal.

Consideraciones

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.

Fiabilidad

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 redundancia en varias zonas de disponibilidad, use sondeos de estado para la supervisión en tiempo real y asegúrese de que 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.

• Supervisión continua: para mantenerse atento al estado del sistema, emplee 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.

Seguridad

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 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 realicen acciones autorizadas.

• Implementación: implemente el identificador de Entra de Microsoft 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.

• Evaluar la eficacia de la seguridad: evalúe la eficacia de las medidas de seguridad para la carga de trabajo de acceso dual mediante la implementación de:

  • Inversiones defensivas: evalúe periódicamente la eficacia de Azure Front Door y Application Gateway. Asegúrese de que proporcionan protección significativa contra amenazas.

  • Restricción de radio de explosión: asegúrese de que contiene infracciones de seguridad dentro de un ámbito limitado. Por ejemplo, aísle eficazmente los flujos de tráfico externos e internos.

• Asumir una infracción: confirme que los atacantes pueden infringir los controles de seguridad. Prepárese para estos escenarios.

• Implementar medidas de seguridad: implemente la segmentación de red, la microsegmentación y los 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 una waf de en Application Gateway para proteger las aplicaciones web frente a vulnerabilidades y vulnerabilidades 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 firewall de Azure a la red virtual del centro de conectividad y usar la inteligencia sobre amenazas de Azure Firewall 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 web comunes y vulnerabilidades de seguridad en el perímetro. 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.

• Proceso 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 proceso back-end. Asegúrese de tener en cuenta todos los elementos de un recurso de proceso de 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 para lograr una alta disponibilidad.

• Azure Front Door: los costos de Azure Front Door 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 el nivel Estándar o El nivel Premium de Azure Front Door 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 ajustarse a su escenario.

Colaboradores

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

Autor principal:

• Troy Hite | Arquitecto sénior de soluciones en la nube

Otros colaboradores:

• Álgebara de Mays | Cinturón negro global sénior de Azure Networking
• Adam Torkar - España | Cinturón negro global sénior de Azure Networking
• Michael McKechney | Especialista principal en tecnología de Azure

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

Pasos siguientes

• Configuración de la infraestructura de Application Gateway
• TLS de un extremo a otro con Azure Front Door
• Adición de un dominio personalizado a Azure Front Door
• ¿Qué es el filtrado geográfico en un dominio para Azure Front Door?

Recursos relacionados

• Firewall y Application Gateway para redes virtuales
• Uso de Azure Front Door en una solución multiinquilino