Usar uma configuração de DNS de cérebro dividido para hospedar um aplicativo Web no Azure

Porta da frente do Azure
Gateway de Aplicativo do Azure
Azure ExpressRoute
DNS do Azure

As equipes que gerenciam cargas de trabalho geralmente dependem de FQDNs (nomes de domínio totalmente qualificados) para acesso ao cliente. Normalmemente, os FQDNs são combinados com a Indicação de Nome de Servidor (SNI) de Segurança da Camada de Transporte (TLS). Com essa abordagem, quando os clientes públicos acessam uma carga de trabalho da Internet pública ou clientes corporativos acessam uma carga de trabalho internamente, o roteamento para o aplicativo pode seguir caminhos fixos e ter vários níveis de QoS (segurança ou qualidade de serviço).

A arquitetura a seguir demonstra uma abordagem para diferenciar como o tráfego é tratado com base no DNS (Sistema de Nomes de Domínio) e se o cliente é originário da Internet ou de uma rede corporativa.

Architecture

Diagrama da arquitetura de hospedagem de aplicativos.

Baixe um arquivo do Visio dessa arquitetura.

As seções de fluxo de trabalho a seguir descrevem duas configurações: um fluxo de trabalho da Internet pública e um fluxo de trabalho privado. Combine os dois fluxos de trabalho para implementar uma arquitetura de hospedagem de cérebro dividido.

Fluxo de trabalho da Internet pública

Diagrama do fluxo de trabalho público da Internet.

Baixe um arquivo do Visio dessa arquitetura.

  1. Os clientes enviam uma solicitação para o aplicativo app.contoso.com por meio da Internet pública.

  2. Uma zone DNS do Azure está configurada para o domínio contoso.com. As entradas de nome canônico (CNAME) apropriadas são configuradas para os endpoints do Azure Front Door.

  3. Os clientes externos acessam o aplicativo Web por meio do Azure Front Door Standard ou Premium, que funciona como um balanceador de carga global e um WAF (firewall de aplicativo Web).

    • No Azure Front Door, app.contoso.com é atribuído como FQDN através de rotas em um endpoint configurado. O Azure Front Door também hospeda os certificados TLS SNI para os aplicativos.

      Note

      O Azure Front Door não dá suporte a certificados autoassinados.

    • O Azure Front Door roteia as solicitações para o grupo de origem configurado com base no cabeçalho HTTP Host do cliente.

    • O grupo de origem é configurado para apontar para a instância do Gateway de Aplicativo do Azure por meio do endereço IP público do Gateway de Aplicativo do Azure.

  4. Um grupo de segurança de rede (NSG) é configurado na sub-rede AppGW para permitir o acesso de entrada na porta 80 e na porta 443 da marca de serviço AzureFrontDoor.Backend. O NSG não permite tráfego de entrada na porta 80 e na porta 443 do tag de serviço de internet.

    Note

    A marca de serviço AzureFrontDoor.Backend não limita o tráfego somente à sua instância do Azure Front Door. A validação ocorre no próximo estágio.

  5. A instância do Gateway de Aplicativo tem um ouvinte na porta 443. O tráfego é roteado para o back-end com base no nome do host especificado no ouvinte.

    • Para garantir que o tráfego tenha origem no perfil do Azure Front Door, configure uma regra waf personalizada para verificar o valor do X-Azure-FDID cabeçalho.

    • O Azure gera um identificador exclusivo para cada perfil do Azure Front Door. O identificador exclusivo é o valor Azure Front Door ID localizado na página de visão geral do portal Azure.

  6. O tráfego atinge o recurso computacional configurado como um pool de back-end no Gateway de Aplicações.

Fluxo de trabalho de empresa privada

Diagrama do fluxo de trabalho da empresa privada.

Baixe um arquivo do Visio dessa arquitetura.

  1. Os clientes iniciam uma solicitação para o aplicativo app.contoso.com de um ambiente local.

  2. FQDNs de aplicativo são configurados no provedor DNS local. Esse provedor DNS pode ser servidores DNS Active Directory Domain Services locais (AD DS) ou outras soluções de parceiro. As entradas DNS para cada um dos FQDNs do aplicativo são configuradas para apontar para o endereço IP privado da instância do Gateway de Aplicações.

  3. Um circuito do Azure ExpressRoute ou uma VPN site-to-site facilita o acesso ao Application Gateway.

  4. Um NSG é configurado na sub-rede AppGW para permitir solicitações privadas de entrada de redes de clientes locais de onde o tráfego se origina. Essa configuração garante que outras fontes de tráfego privado não possam acessar diretamente o endereço IP privado do Gateway de Aplicativo.

  5. Application Gateway tem um ouvinte configurado na porta 80 e na porta 443. O tráfego é roteado para o back-end com base no nome do host especificado no ouvinte.

  6. Somente o tráfego de rede privada atinge o recurso de computação configurado como um pool de back-end no Application Gateway.

Components

  • O DNS é um sistema que mapeia nomes de domínio para endereços IP, que permite que os clientes localizem e se conectem aos serviços. Para um fluxo de trabalho de internet pública nessa arquitetura, você deve configurar uma zona DNS pública com o CNAME adequado do FQDN do ponto de extremidade Azure Front Door. No lado privado (empresarial), configure o provedor DNS local (DNS do AD DS ou uma solução de parceiro) para apontar cada Nome de Domínio Completamente Qualificado (FQDN) de aplicativo para o endereço IP privado do Gateway de Aplicativo.

  • DNS do Azure Resolvedor Privado é um serviço totalmente gerenciado que permite a resolução de DNS entre ambientes locais e Azure sem implantar servidores DNS personalizados. Nessa arquitetura, o Resolvedor Privado DNS permite a resolução de clientes locais, para que os usuários corporativos possam usar essa solução DNS de cérebro dividido para acessar aplicativos sem atravessar a Internet pública.

  • Azure Front Door é um balanceador de carga global e WAF que fornece entrega rápida e segura de aplicativos Web para clientes globais. Nessa arquitetura, o Azure Front Door Standard ou Premium roteia clientes externos para a instância do Gateway de Aplicativo e fornece opções de cache e otimização para aprimorar a experiência do cliente.

  • O Gateway de Aplicativo é um balanceador de carga regional e WAF que fornece alta disponibilidade, escalabilidade e segurança para aplicativos Web. Nessa arquitetura, o Gateway de Aplicativo roteia solicitações de clientes externas e internas para a computação de back-end e protege o aplicativo Web contra ataques da Web comuns.

    O Azure Front Door e o Gateway de Aplicativo fornecem recursos de WAF, mas o fluxo de trabalho privado nesta solução não usa o Azure Front Door. Como resultado, ambas as arquiteturas usam a funcionalidade WAF do Gateway de Aplicações.

  • O ExpressRoute é um serviço que estende redes locais para a nuvem por meio de uma conexão privada estabelecida por um provedor de conectividade. Nessa arquitetura, o ExpressRoute facilita a conectividade privada com o Gateway de Aplicativo para clientes locais.

Alternatives

Como uma solução alternativa, você pode remover o Azure Front Door Standard ou Premium e, em vez disso, apontar o registro DNS público para o endereço IP público do Gateway de Aplicações. Com base nos requisitos dessa arquitetura, você deve cache e otimizar o tráfego no ponto de entrada em Azure. Como resultado, você não pode usar a solução alternativa para esse cenário. Para obter mais informações, consulte Otimização de Custo.

Diagrama da arquitetura de hospedagem DNS de cérebro dividido alternativo.

Baixe um arquivo do Visio dessa arquitetura.

Outras alternativas possíveis para o tráfego de entrada pública nesta arquitetura incluem:

  • do Gerenciador de Tráfego do Azure: o Gerenciador de Tráfego é um serviço de roteamento de tráfego baseado em DNS que distribui o tráfego entre várias regiões e pontos de extremidade. Você pode usar o Gerenciador de Tráfego em vez de Azure Front Door Standard ou Premium para rotear clientes externos para a instância mais próxima do Gateway de Aplicativo. No entanto, o Azure Front Door fornece recursos, como funcionalidades de WAF, cache e afinidade de sessão. O Gerenciador de Tráfego não fornece esses recursos.

  • do Azure Load Balancer: o Azure Load Balancer é um balanceador de carga de rede que fornece alta disponibilidade e escalabilidade para o TCP (Protocolo de Controle de Transmissão) e o tráfego UDP (User Datagram Protocol). Você pode usar o Load Balancer em vez do Gateway de Aplicativo para rotear solicitações de clientes externas e internas para servidores Web de back-end. No entanto, o Gateway de Aplicativo fornece recursos, como funcionalidades de WAF, terminação SSL (Secure Sockets Layer) e afinidade de sessão baseada em cookie. O Load Balancer não fornece esses recursos.

Detalhes do cenário

Esse cenário resolve o problema de hospedar um aplicativo Web que atende clientes externos e internos. Essa arquitetura garante que o tráfego siga um caminho apropriado com base na origem de um cliente. Esta arquitetura:

  • Fornece acesso rápido e confiável pela Internet a uma aplicação web para clientes globais não empresariais.

  • Fornece aos clientes corporativos a capacidade de acessar um aplicativo sem atravessar a Internet pública.

  • Protege um aplicativo Web contra ataques da Web comuns e tráfego mal-intencionado.

Possíveis casos de uso

Use essa arquitetura para cenários que exigem:

  • Split-brain DNS: Essa solução usa Azure Front Door para clientes externos e Gateway de Aplicativo para clientes internos, com registros DNS diferentes para cada serviço. Essa abordagem ajuda a otimizar o desempenho, a segurança e a disponibilidade da rede para vários clientes.

  • Escalabilidade do aplicativo: Essa solução usa o Gateway de Aplicativo, que pode distribuir o tráfego entre os recursos de computação de back-end configurados. Essa abordagem ajuda a melhorar o desempenho e a disponibilidade do aplicativo e dar suporte ao dimensionamento horizontal.

Considerations

Essas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios orientadores que você pode usar para melhorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte Well-Architected Framework.

Reliability

A confiabilidade ajuda a garantir que seu aplicativo possa cumprir os compromissos que você faz aos seus clientes. Para obter mais informações, consulte a lista de verificação de revisão de design para Confiabilidade.

  • Identificar pontos de falha. Nessa arquitetura DNS de cérebro dividido, a confiabilidade depende do funcionamento correto dos principais componentes, como configurações de Azure Front Door, Gateway de Aplicativo e DNS. Você deve identificar possíveis pontos de falha, como configurações incorretas, problemas de certificado SSL ou sobrecargas de capacidade.

  • Avaliar o impacto. Você deve avaliar o impacto das falhas. Para clientes externos, qualquer interrupção no Azure Front Door, que serve como gateway, pode afetar o acesso global. Para clientes internos, qualquer interrupção no Gateway de Aplicativo pode impedir operações empresariais.

  • Implementar estratégias de mitigação. Para reduzir os riscos, implemente a redundância em várias zonas de disponibilidade, use sondas de integridade para monitoramento em tempo real e garanta a configuração correta do roteamento DNS para tráfego externo e interno. Atualize regularmente os registros DNS e tenha um plano de recuperação de desastre.

  • Monitore continuamente. Para manter um olhar vigilante sobre a integridade do seu sistema, empregue os recursos do Azure Monitor. Configure alertas para anomalias e tenha um plano de resposta a incidentes pronto para resolver prontamente possíveis problemas.

Siga esses princípios para garantir um sistema robusto e confiável que possa suportar desafios e manter a continuidade do serviço.

Segurança

A segurança fornece garantias contra ataques deliberados e o uso indevido de seus valiosos dados e sistemas. Para obter mais informações, consulte a lista de verificação de revisão de design para Segurança.

  • Use a abordagem Confiança Zero. Na configuração de DNS de cérebro dividido, aplique a abordagem Confiança Zero. Verifique explicitamente a identidade de um cliente, se ele se originou da Internet ou de uma rede corporativa. Essa abordagem garante que apenas entidades confiáveis possam executar ações autorizadas.

  • Implemente controles de identidade e acesso com eficiência. Implemente Microsoft Entra ID para um gerenciamento de identidade robusto. Use as políticas de Acesso Condicional do Microsoft Entra para impor controles de acesso estritos com base no contexto do cliente, na integridade do dispositivo e na localização.

    • Avalie suas medidas de segurança. Avalie a eficácia das medidas de segurança para sua carga de trabalho de acesso duplo implementando:

      • Avalie seus investimentos defensivos regularmente. Avalie regularmente a eficácia do Azure Front Door e do Gateway de Aplicativo. Verifique se eles fornecem proteção significativa contra ameaças.

      • Restrinja o escopo de impacto de possíveis violações. Certifique-se de conter as violações de segurança dentro de um escopo limitado. Por exemplo, isole efetivamente fluxos de tráfego externos e internos.

  • Suponha que uma violação seja sempre possível. Reconheça que os invasores podem violar os controles de segurança. Prepare-se para esses cenários.

  • Implemente medidas de segurança de forma abrangente. Implementar segmentação de rede, micro segmentação e NSGs. Suponha que um invasor possa obter acesso e projete controles compensatórios adequadamente.

Integre esses princípios de segurança à arquitetura DNS de cérebro dividido para criar um sistema robusto e resiliente que proteja o acesso interno e externo à sua carga de trabalho.

Outros aprimoramentos de segurança

  • Gateway de Aplicativo: Você pode usar um WAF no Gateway de Aplicativo para proteger seus aplicativos Web contra vulnerabilidades e explorações comuns da Web. Você também pode usar o Link Privado do Azure para acessar com segurança seus servidores de aplicativos de back-end do Gateway de Aplicativo sem expô-los à Internet pública.

  • Firewall do Azure: Você pode adicionar um Azure firewall à rede virtual do hub e usar Firewall do Azure inteligência contra ameaças para bloquear o tráfego mal-intencionado de domínios e endereços IP mal-intencionados conhecidos. Você também pode usar o Firewall do Azure como um proxy DNS para interceptar e inspecionar o tráfego DNS e aplicar regras de filtragem de DNS.

  • Azure Front Door: você pode usar Firewall de Aplicativo Web do Azure para proteger seus aplicativos Web contra vulnerabilidades e explorações comuns da Web na borda. Você também pode usar o Link Privado com a camada Premium do Azure Front Door para acessar com segurança seus servidores de aplicativos de back-end do Azure Front Door sem expô-los à Internet pública.

Otimização de custos

A Otimização de Custos concentra-se em maneiras de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte a lista de verificação de revisão de design para Otimização de Custos.

  • Computação de back-end: Muitos fatores, como seleção de SKU, contagem de réplicas e região, geram o custo da execução de serviços de computação de back-end. Verifique se você considera todos os elementos de um recurso de computação antes de selecionar a melhor opção para sua carga de trabalho.

  • Gateway de Aplicativo: Os custos do Gateway de Aplicativo dependem do número de instâncias, do tamanho das instâncias e da quantidade de dados processados. Você pode otimizar o custo usando o dimensionamento automático para ajustar o número de instâncias com base na demanda de tráfego. Você também pode implantar SKUs com redundância de zona entre zonas de disponibilidade para reduzir a necessidade de instâncias extras para alta disponibilidade.

  • Azure Front Door: Azure Front Door os custos dependem do número de regras de roteamento, do número de solicitações HTTP ou HTTPS e da quantidade de dados transferidos. Você pode usar Azure Front Door Standard ou Premium para obter uma experiência unificada com Rede de Distribuição de Conteúdo do Azure, Firewall de Aplicativo Web do Azure e Link Privado. Você também pode usar o recurso de mecanismo de regras do Azure Front Door para personalizar o gerenciamento de tráfego e otimizar o desempenho e o custo.

Se o cenário não exigir acesso global ou recursos extras do Azure Front Door, você poderá usar essa solução apenas com o Gateway de Aplicativo. Você pode apontar todos os registros DNS públicos para o endereço IP público que está configurado nos ouvintes do Application Gateway.

Veja um exemplo dessa solução que aproxima o uso típico dos componentes nessa arquitetura. Ajuste os custos para adequá-los ao seu cenário.

Contributors

A Microsoft mantém este artigo. Os colaboradores a seguir escreveram este artigo.

Autor principal:

  • Troy Hite | Engenheiro sênior de soluções

Outros colaboradores:

  • Mays Algebary | Blackbelt Global Sênior em Networking do Azure
  • Michael McKechney | Principal Especialista em Tecnologia do Azure
  • Adam Torkar | Especialista Sênior em Networking na Azure Global Blackbelt

Para ver perfis de LinkedIn não públicos, entre em LinkedIn.

Próximas etapas