Usar uma configuração de DNS de dupla personalidade 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 do cliente. Os FQDNs normalmente são 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 a partir 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 origina-se da Internet ou de uma rede corporativa.

Arquitetura

Baixe um Arquivo Visio dessa arquitetura.

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

Fluxo de trabalho de Internet pública

Baixe um Arquivo Visio dessa arquitetura.

Os clientes enviam uma solicitação para o aplicativo app.contoso.com por meio da Internet pública.
Uma zona do DNS do Azure é configurada para o domínio contoso.com. As entradas CNAME (nome canônico) apropriadas são configuradas para os pontos de extremidade do Azure Front Door.
Os clientes externos acessam o aplicativo Web por meio do Azure Front Door, 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 o 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.
  
  Observação
  
  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 Host cabeçalho HTTP 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.
Um NSG (grupo de segurança de rede) é configurado na sub-rede AppGW para permitir o acesso de entrada na porta 80 e na porta 443 a partir da marca de serviço AzureFrontDoor.Backend. O NSG não permite tráfego de entrada na porta 80 e na porta 443 da marca de serviço de Internet.

Observação

A marca de serviço AzureFrontDoor.Backend não limita o tráfego apenas à sua instância do Azure Front Door. A validação ocorre na próxima etapa.
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 se origine do seu perfil do Azure Front Door, configure uma regra de WAF personalizada para verificar o X-Azure-FDID valor do cabeçalho.
- O Azure gera um identificador exclusivo para cada perfil do Azure Front Door. O identificador exclusivo é o valor de ID do Front Door localizado na página de visão geral do portal do Azure.
O tráfego chega até o recurso de computação configurado como um pool de back-end no Gateway de Aplicativo.

Fluxo de trabalho corporativo privado

Baixe um Arquivo Visio dessa arquitetura.

Os clientes iniciam uma solicitação para o aplicativo app.contoso.com a partir de um ambiente local.
Os FQDNs do aplicativo são configurados no provedor de DNS local. Esse provedor de DNS pode ser servidores DNS do Windows Server Active Directory ou outras soluções de parceiros. As entradas de 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 Aplicativo.
Um circuito do Azure ExpressRoute ou uma VPN site a site facilita o acesso ao Gateway de Aplicativo.
Um NSG é configurado na sub-rede AppGW para permitir a entrada de solicitações privadas 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 chegar diretamente ao endereço IP privado do Gateway de Aplicativo.
O Gateway de Aplicativo tem um ouvinte que está 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.
Somente o tráfego de rede privada chega à computação configurada como um pool de back-end no Gateway de Aplicativos.

Componentes

DNS: para um fluxo de trabalho de Internet pública, você deve configurar uma zona pública do DNS do Azure com o CNAME apropriado do FQDN de ponto de extremidade do Azure Front Door. No lado privado (empresarial), configure o provedor DNS local (DNS do Active Directory do Windows Server ou uma solução de parceiro) para apontar cada FQDN de aplicativo para o endereço IP privado do Gateway de Aplicativo.
Resolvedor Privado de DNS do Azure: você pode usar o Resolvedor Privado de DNS para a resolução de clientes locais. Os clientes corporativos podem usar essa solução de DNS de dupla personalidade para obter acesso a aplicativos sem precisar navegar pela Internet pública.
Azure Front Door: o Azure Front Door é um balanceador de carga global e WAF que fornece entrega rápida e segura de aplicativos Web para clientes em todo o mundo. Nessa arquitetura, o Azure Front Door 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.
Gateway de Aplicativo: 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 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 Gateway de Aplicativo fornecem recursos de WAF, mas o fluxo de trabalho privado nesta solução não usa o Azure Front Door. Portanto, ambas as arquiteturas usam a funcionalidade WAF do Gateway de Aplicativo.
ExpressRoute: você pode usar o ExpressRoute para estender suas redes locais para o Microsoft Cloud por meio de uma conexão privada com a ajuda de um provedor de conectividade. Nessa arquitetura, você pode usar o ExpressRoute para facilitar a conectividade privada com o Gateway de Aplicativo para clientes locais.

Alternativas

Como alternativa, você pode remover o Azure Front Door e, em vez disso, apontar o registro de DNS público do Azure para o endereço IP público do Gateway de Aplicativo. Com base nos requisitos dessa arquitetura, é necessário fazer cache e otimização no ponto de entrada no Azure. Portanto, a solução alternativa não é uma opção para esse cenário. Para obter mais informações, confira Otimização de custos.

Baixe um Arquivo Visio dessa arquitetura.

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

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 do Azure Front Door para rotear clientes externos para a instância mais próxima do Gateway de Aplicativo. No entanto, o Azure Front Door fornece recursos, como recursos de WAF, cache e afinidade de sessão. O Gerenciador de Tráfego não fornece esses recursos.
Azure Load Balancer: o Azure Load Balancer é um balanceador de carga de rede que fornece alta disponibilidade e escalabilidade para tráfego TCP (Transmission Control Protocol) e UDP (User Datagram Protocol). Você pode usar o Load Balancer em vez do Gateway de Aplicativo para rotear solicitações de clientes externos e internos para servidores Web de back-end. No entanto, o Gateway de Aplicativo fornece recursos, como recursos de WAF, terminação SSL (Secure Sockets Layer) e afinidade de sessão baseada em cookies. 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 tanto clientes externos quanto internos. Essa arquitetura garante que o tráfego siga um caminho apropriado com base na origem de um cliente. Essa arquitetura:

Fornece acesso rápido e confiável pela Internet a um aplicativo Web para clientes não corporativos em todo o mundo.
Fornece aos clientes corporativos a capacidade de acessar um aplicativo sem precisar navegar na Internet pública.
Protege um aplicativo Web contra ataques comuns da Web e tráfego mal-intencionado.

Possíveis casos de uso

Use essa arquitetura para cenários que exigem:

DNS de dupla personalidade: esta solução usa o Azure Front Door para clientes externos e o 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 oferece suporte ao dimensionamento horizontal.

Considerações

Estas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios de orientação que podem ser usados para aprimorar a qualidade de uma carga de trabalho. Para obter mais informações, confira Microsoft Azure Well-Architected Framework.

Confiabilidade

A confiabilidade garante 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: nessa arquitetura de DNS de dupla personalidade, a confiabilidade depende do funcionamento correto de componentes-chave, como o Azure Front Door, o Gateway de Aplicativo 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: é necessário 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 Gateway de Aplicativo pode impedir as operações corporativas.
Implementar estratégias de mitigação: para mitigar riscos, implementar redundância em diversas zonas de disponibilidade, usar investigações de integridade para monitoramento em tempo real e garantir a configuração correta do roteamento DNS para tráfego externo e interno. Certifique-se de atualizar regularmente os registros de DNS e ter um plano de recuperação de desastres.
Monitorar continuamente: para manter um olhar vigilante sobre a integridade do seu sistema, use os recursos do Azure Monitor. Configure alertas para anomalias e tenha um plano de resposta a incidentes pronto para resolver rapidamente possíveis problemas.

Siga 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 abuso de seus dados e sistemas valiosos. Para obter mais informações, consulte Lista de verificação de revisão de design para segurança.

Use a abordagem Zero Trust: na configuração de DNS de dupla personalidade, aplique a abordagem Zero Trust. Verifique explicitamente a identidade de um cliente, se ele é originário da Internet ou de uma rede corporativa. Essa abordagem garante que apenas entidades confiáveis executem ações autorizadas.
Implementação: implemente o Microsoft Entra ID para gerenciamento robusto de identidades. Use as políticas de Acesso Condicional do Microsoft Entra para impor controles de acesso rígidos com base no contexto do cliente, na integridade do dispositivo e na localização.
Avaliar a eficácia da segurança: avalie a eficácia das medidas de segurança para sua carga de trabalho de acesso duplo implementando:
- Investimentos defensivos: avalie regularmente a eficácia do Azure Front Door e do Gateway de Aplicativo. Certifique-se de que eles forneçam proteção significativa contra ameaças.
- Restrição de raio de explosão: verifique se você contém violações de segurança dentro de um escopo limitado. Por exemplo, isole efetivamente os fluxos de tráfego externo e interno.
Suponha que haja uma violação: reconheça que os invasores podem violar os controles de segurança. Prepare-se para esses cenários.
Implementar medidas de segurança: implemente segmentação de rede, microssegmentaçã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 à sua arquitetura DNS de dupla personalidade 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 back-end do Gateway de Aplicativo sem expô-los à Internet pública.
Firewall do Azure: você pode adicionar um firewall do Azure à rede virtual de hub e usar a inteligência de ameaças do Firewall do Azure para bloquear o tráfego mal-intencionado de endereços IP e domínios mal-intencionados conhecidos. Você também pode usar o Firewall do Azure como um proxy de DNS para interceptar e inspecionar o tráfego de DNS e aplicar regras de filtragem de DNS.
Azure Front Door: você pode usar o 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 o nível Premium do Azure Front Door para acessar com segurança seus servidores de aplicativos back-end do Azure Front Door sem expô-los à Internet pública.

Otimização de custo

A otimização de custos é a análise de maneiras de reduzir as 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, aumentam o custo da execução de serviços de computação de back-end. Certifique-se de considerar 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. Também é possível implantar SKUs com redundância de zona em zonas de disponibilidade para reduzir a necessidade de instâncias adicionais para alta disponibilidade.
Azure Front Door: os custos do Azure Front Door 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 a camada Standard ou a camada Premium do Azure Front Door para obter uma experiência unificada com a Rede de Entrega de Conteúdo do Azure, o Firewall de Aplicativo Web do Azure e o 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 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 Gateway de Aplicativo. Você pode apontar todos os registros de DNS públicos para o endereço IP público configurado nos ouvintes do Gateway de Aplicativo.

Veja um exemplo dessa solução que se aproxima do uso típico dos componentes nesta arquitetura. Ajuste os custos para se adequar ao seu cenário.

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Autor principal:

Troy Hite | Arquiteto Sênior de Soluções de Nuvem

Outros colaboradores:

Mays Algebary | Faixa Preta Sênior Global de Rede do Azure
Adam Torkar | Faixa Preta Sênior Global de Rede do Azure
Michael McKechney | Principal Especialista em Tecnologia do Azure

Para ver perfis não públicos do LinkedIn, entre no LinkedIn.

Compartilhar via

Usar uma configuração de DNS de dupla personalidade para hospedar um aplicativo Web no Azure