Usar uma configuração de DNS split-brain para hospedar um aplicativo Web no Azure

Azure Front Door
Gateway de Aplicação do Azure
Azure ExpressRoute
Azure DNS

As equipes que gerenciam cargas de trabalho geralmente dependem de FQDNs (nomes de domínio totalmente qualificados) para acesso do cliente. Os FQDNs são normalmente combinados com a Indicação de Nome do Servidor (SNI) TLS (Transport Layer Security). Com essa abordagem, quando 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 segurança ou qualidade de serviço (QoS).

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 alojamento da aplicação.

Baixe um arquivo Visio desta arquitetura.

As seções de fluxo de trabalho a seguir descrevem duas configurações: um fluxo de trabalho público da Internet e um fluxo de trabalho privado. Combine os dois fluxos de trabalho para implementar uma arquitetura de hospedagem split-brain.

Fluxo de trabalho público na Internet

Diagrama do fluxo de trabalho público da internet.

Baixe um arquivo Visio desta arquitetura.

  1. Os clientes enviam um pedido para a aplicação app.contoso.com através da Internet pública.

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

  3. Os clientes externos acedem à aplicação web através do Azure Front Door Standard ou Premium, que funciona como um balanceador de carga global e firewall de aplicações web (WAF).

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

      Note

      O Azure Front Door não oferece 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 está configurado para apontar para a instância do Gateway de Aplicação do Azure através do endereço IP público do Application Gateway.

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

    Note

    A etiqueta de serviço AzureFrontDoor.Backend não limita o tráfego apenas à sua instância do Azure Front Door. A validação ocorre na etapa seguinte.

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

    • Para garantir que o tráfego tem origem no seu perfil 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 único é o valor Azure Front Door ID localizado na página de visão geral do portal Azure.

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

Fluxo de trabalho da empresa privada

Diagrama do fluxo de trabalho da empresa privada.

Baixe um arquivo Visio desta arquitetura.

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

  2. Os FQDNs de aplicativos são configurados no provedor de DNS local. Este fornecedor de DNS pode ser servidores DNS on-premises do Active Directory Domain Services (AD DS) ou outras soluções de parceiros. 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 Application Gateway.

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

  4. Um NSG está configurado na sub-rede AppGW para permitir pedidos privados recebidos de redes de clientes on-premises 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 Application Gateway.

  5. O 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 escutador.

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

Components

  • O DNS é um sistema que mapeia nomes de domínio para endereços IP, permitindo aos clientes localizar e ligar-se a serviços. Para um fluxo de trabalho de internet pública nesta arquitetura, deve configurar uma zona DNS pública com o CNAME correto do endpoint Azure Front Door FQDN. No lado privado (empresarial), configure o fornecedor DNS local (AD, DS, DNS ou uma solução parceira) para apontar cada aplicação FQDN para o endereço IP privado do Application Gateway.

  • DNS do Azure Private Resolver é um serviço totalmente gerido que permite a resolução DNS entre ambientes locais e Azure sem necessidade de implementar servidores DNS personalizados. Nesta arquitetura, o DNS Private Resolver permite a resolução de clientes on-premises, permitindo que os utilizadores empresariais utilizem esta solução DNS de cérebro dividido para aceder a aplicações sem terem de atravessar a internet pública.

  • Azure Front Door é um balanceador de carga global e WAF que fornece entrega rápida e segura de aplicações web a clientes globais. Nesta arquitetura, o Azure Front Door Standard ou Premium encaminha clientes externos para a instância do Application Gateway e fornece opções de cache e otimização para melhorar a experiência do cliente.

  • O Application Gateway é um balanceador de carga regional e WAF que proporciona alta disponibilidade, escalabilidade e segurança para aplicações web. Nessa arquitetura, o Application Gateway roteia solicitações de clientes externos e internos para a computação back-end e protege o aplicativo Web contra ataques comuns da Web.

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

  • ExpressRoute é um serviço que estende redes locais para a cloud através de uma ligação privada estabelecida por um fornecedor de conectividade. Nesta arquitetura, o ExpressRoute facilita a conectividade privada ao Application Gateway para clientes locais.

Alternatives

Como solução alternativa, pode remover o Azure Front Door Standard ou Premium e, em vez disso, apontar o registo DNS público para o endereço IP público do Application Gateway. Com base nos requisitos desta arquitetura, deve cachear e otimizar o tráfego no ponto de entrada para o Azure. Como resultado, não pode usar a solução alternativa para este cenário. Para mais informações, consulte Otimização de Custos.

Diagrama da arquitetura alternativa de alojamento DNS de cérebro dividido.

Baixe um arquivo Visio desta arquitetura.

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

  • Gestor de Tráfego do Azure: O Traffic Manager é 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. Pode usar o Traffic Manager em vez do Azure Front Door Standard ou Premium para encaminhar clientes externos para a instância de Application Gateway mais próxima. No entanto, o Azure Front Door fornece recursos, tais como capacidades de WAF, cache e afinidade de sessão. O Gestor de Tráfego não fornece estas funcionalidades.

  • Balanceador de Carga do Azure: O Balanceador de Carga do Azure é um balanceador de carga de rede que fornece alta disponibilidade e escalabilidade para o tráfego TCP (Transmission Control Protocol) e UDP (User Datagram Protocol). Você pode usar o Balanceador de Carga em vez do Application Gateway para rotear solicitações de clientes externos e internos para servidores Web back-end. No entanto, o Application Gateway fornece funcionalidades, tais como capacidades de WAF, terminação de SSL (Secure Sockets Layer) e afinidade de sessão baseada em cookies. O Balanceador de Carga não fornece esses recursos.

Detalhes do cenário

Este cenário resolve o problema de hospedar uma aplicação web que atende clientes externos e internos. Essa arquitetura garante que o tráfego siga um caminho apropriado com base na origem do cliente. Esta arquitetura:

  • Proporciona acesso rápido e fiável via 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 uma aplicação Web contra ataques Web comuns e tráfego malicioso.

Casos de uso potenciais

Use esta arquitetura para cenários que exigem:

  • Split-brain DNS: Esta solução utiliza Azure Front Door para clientes externos e Application Gateway para clientes internos, com registos 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 da aplicação: Esta solução utiliza o Application Gateway, que pode distribuir tráfego entre recursos de computação back-end configurados. Essa abordagem ajuda a melhorar o desempenho e a disponibilidade do aplicativo e oferece 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ê assume com seus clientes. Para obter mais informações, consulte Lista de verificação de revisão de design para confiabilidade.

  • Identificar pontos de falha. Nesta arquitetura DNS split-brain, a confiabilidade depende do funcionamento correto dos componentes-chave, como o Azure Front Door, o Application Gateway e as configurações de DNS. Você deve identificar possíveis pontos de falha, como configurações incorretas, problemas de certificado SSL ou sobrecargas de capacidade.

  • Avaliar o impacto. Deve avaliar o impacto das falhas. Para clientes externos, qualquer interrupção no Azure Front Door, que serve como um gateway, pode afetar o acesso global. Para clientes internos, qualquer interrupção no Application Gateway pode impedir as operações corporativas.

  • Implementar estratégias de mitigação. Para mitigar riscos, implemente redundância em múltiplas zonas de disponibilidade, use sondas de saúde para monitorização em tempo real e assegure a configuração correta do encaminhamento DNS tanto para tráfego externo como interno. Certifique-se de atualizar regularmente os registros DNS e ter um plano de recuperação de desastres.

  • Monitoriza continuamente. Para manter um olhar atento sobre a saúde do seu sistema, utilize funcionalidades Azure Monitor. Configure alertas para anomalias e tenha um plano de resposta a incidentes pronto para resolver prontamente possíveis problemas.

Aderir a esses princípios para garantir um sistema robusto e confiável que possa resistir aos 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 Lista de verificação de revisão de design para segurança.

  • Utilize a abordagem Confiança Zero. Na configuração DNS de cérebro dividido, aplica a abordagem Confiança Zero. Verifique explicitamente a identidade de um cliente, seja ele originário da Internet ou de uma rede corporativa. Esta abordagem garante que apenas entidades de confiança podem realizar ações autorizadas.

  • Implementar controlos de identidade e acesso de forma eficaz. Implemente o Microsoft Entra ID para uma gestão robusta de identidades. 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 as suas medidas de segurança. Avalie a eficácia das medidas de segurança para a sua carga de trabalho de acesso duplo implementando:

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

      • Restringir o âmbito de impacto das potenciais violações. Certifique-se de conter as violações de segurança dentro de um âmbito limitado. Por exemplo, isolar eficazmente os fluxos de tráfego externo e interno.

  • Assuma que uma violação é sempre possível. Reconheça que os atacantes podem violar os controlos 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 projetar controles de compensação de acordo.

Integre esses princípios de segurança em sua arquitetura DNS split-brain para criar um sistema robusto e resiliente que proteja o acesso interno e externo à sua carga de trabalho.

Outras melhorias de segurança

  • Application Gateway: Pode usar um WAF no Application Gateway para proteger as suas aplicações web de vulnerabilidades e explorações comuns da web. Você também pode usar Azure Private Link para acessar com segurança os seus servidores de aplicativos back-end a partir do Application Gateway sem expô-los à Internet pública.

  • Azure Firewall: Pode adicionar um Azure firewall à rede virtual do hub e usar Azure Firewall threat intelligence para bloquear tráfego malicioso proveniente de endereços IP e domínios maliciosos conhecidos. Você também pode usar o Firewall do Azure como um proxy DNS para intercetar e inspecionar o tráfego DNS e aplicar regras de filtragem de DNS.

  • Azure Front Door: Pode usar Firewall de Aplicações Web do Azure para proteger as suas aplicações web de vulnerabilidades e exploits comuns na periferia. Também pode usar Private Link com o nível Azure Front Door Premium para aceder de forma segura aos seus servidores de aplicações back-end a partir do Azure Front Door, sem os expor à internet pública.

Otimização de Custos

A Otimização de Custos concentra-se em formas de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte 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, determinam o custo de execução dos serviços de computação de back-end. Certifique-se de considerar todos os elementos de um recurso computacional antes de escolher a melhor opção para a sua carga de trabalho.

  • Gateway de Aplicação: Os custos do Gateway de Aplicação dependem do número de instâncias, do tamanho das instâncias e da quantidade de dados processados. É possível otimizar custos usando dimensionamento automático para ajustar o número de instâncias com base na procura de tráfego. Também pode implementar SKUs redundantes de zona em várias zonas de disponibilidade para reduzir a necessidade de instâncias extra para alta disponibilidade.

  • Azure Front Door: Azure Front Door custos dependem do número de regras de encaminhamento, do número de pedidos HTTP ou HTTPS e da quantidade de dados transferidos. Pode usar Azure Front Door Standard ou Premium para obter uma experiência unificada com Rede de Entrega de Conteúdos do Azure, Firewall de Aplicações Web do Azure e Private Link. 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 seu cenário não exigir acesso global ou os recursos extras do Azure Front Door, você poderá usar essa solução apenas com o Application Gateway. Você pode apontar todos os registros DNS públicos para o endereço IP público configurado nos ouvintes do Application Gateway.

Veja um exemplo desta solução que se aproxima do uso típico dos componentes nesta arquitetura. Ajuste os custos de acordo com o seu cenário.

Contributors

A Microsoft mantém este artigo. Os seguintes colaboradores escreveram este artigo.

Autor principal:

  • Troy Hite | Engenheiro Sénior de Soluções

Outros contribuidores:

Para ver perfis não públicos do LinkedIn, faça login no LinkedIn.

Próximos passos