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.
Arquitetura
Transfira um ficheiro do 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
Transfira um ficheiro do Visio desta arquitetura.
Os clientes enviam um pedido para a aplicação app.contoso.com através da Internet pública.
Uma zona DNS do Azure é configurada para o domínio contoso.com . As entradas de nome canônico (CNAME) apropriadas são configuradas para os pontos de extremidade da Porta da Frente do Azure.
Os clientes externos acessam o aplicativo Web por meio do Azure Front Door, que funciona como um balanceador de carga global e um firewall de aplicativo 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.Nota
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 do
Hostcliente.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 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 da etiqueta de serviço de Internet.
Nota
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 etapa seguinte.
A instância do Application Gateway 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 WAF personalizada para verificar o valor do
X-Azure-FDIDcabeçalho.O Azure gera um identificador exclusivo para cada perfil do Azure Front Door. O identificador exclusivo é o valor de ID da Porta da Frente localizado na página de visão geral do portal do Azure.
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
Transfira um ficheiro do Visio desta arquitetura.
Os clientes iniciam uma solicitação para o aplicativo app.contoso.com a partir de um ambiente local.
Os FQDNs de aplicativos são configurados no provedor de DNS local. Esse provedor de DNS pode ser servidores DNS do Ative Directory do Windows Server locais 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.
Um circuito Azure ExpressRoute ou uma VPN site a site facilita o acesso ao Application Gateway.
Um NSG é configurado na sub-rede do 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 acessar diretamente o endereço IP privado do Application Gateway.
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 ouvinte.
Somente o tráfego de rede privada atinge a computação configurada como um pool de back-end no Application Gateway.
Componentes
DNS: Para um fluxo de trabalho público da Internet, você deve configurar uma zona DNS pública do Azure com o CNAME adequado do FQDN do ponto de extremidade da Porta da Frente do Azure. No lado privado (empresa), configure o provedor de DNS local (DNS do Ative Directory do Windows Server ou uma solução de parceiro) para apontar cada FQDN de aplicativo para o endereço IP privado do Application Gateway.
Resolvedor Privado de DNS do Azure: Você pode usar o Resolvedor Privado de DNS para a resolução de clientes locais. Os clientes empresariais podem utilizar esta solução de DNS com cérebro dividido para obter acesso a aplicações sem atravessarem a 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.
Application Gateway: o Application Gateway é um balanceador de carga regional e WAF que fornece alta disponibilidade, escalabilidade e segurança para aplicativos 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. Portanto, ambas as arquiteturas usam a funcionalidade WAF do Application Gateway.
Rota Expressa: você pode usar a Rota Expressa 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 a Rota Expressa para facilitar a conectividade privada com o Application Gateway para clientes locais.
Alternativas
Como uma solução alternativa, você pode remover o Azure Front Door e, em vez disso, apontar o registro DNS público do Azure para o endereço IP público do Application Gateway. Com base nos requisitos dessa arquitetura, você deve fazer cache e otimização no ponto de entrada no Azure. Portanto, a solução alternativa não é uma opção para este cenário. Para obter mais informações, consulte Otimização de custos.
Transfira um ficheiro do Visio desta arquitetura.
Outras alternativas possíveis para o tráfego de entrada pública nesta arquitetura incluem:
Azure Traffic Manager: 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. Você pode usar o Gerenciador de Tráfego em vez do Azure Front Door para rotear clientes externos para a instância do Application Gateway mais próxima. No entanto, o Azure Front Door fornece recursos, como recursos WAF, cache e afinidade de sessão. O Gestor de Tráfego não fornece estas funcionalidades.
Azure Load Balancer: O Azure Load Balancer é 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 Load Balancer 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 recursos, como recursos 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
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:
Fornece acesso rápido e fiável através da Internet a uma aplicação Web para clientes não empresariais em todo o mundo.
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.
Potenciais casos de utilização
Use esta arquitetura para cenários que exigem:
DNS Split-brain: esta solução utiliza o Azure Front Door para clientes externos e o 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 do aplicativo: essa solução usa o Application Gateway, que pode distribuir o tráfego entre os 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.
Considerações
Essas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios orientadores que podem ser usados para melhorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte Microsoft Azure Well-Architected Framework.
Fiabilidade
A confiabilidade garante que seu aplicativo possa atender aos 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 de cérebro dividido, a fiabilidade depende do funcionamento correto de 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: você 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, implementar redundância em várias zonas de disponibilidade, usar sondas 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 DNS e ter um plano de recuperação de desastres.
Monitore continuamente: para manter um olho vigilante na 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.
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 oferece garantias contra ataques deliberados e o abuso de seus valiosos dados e sistemas. 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 split-brain, aplique a abordagem Zero Trust . Verifique explicitamente a identidade de um cliente, seja 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 um gerenciamento robusto 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 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 Application Gateway. Certifique-se de que eles fornecem proteção significativa contra ameaças.
Restrição de raio de explosão: certifique-se de conter violações de segurança dentro de um escopo limitado. Por exemplo, isolar eficazmente os fluxos de tráfego externo e interno.
Suponha 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: Implementar 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 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: Você pode usar um WAF no Application Gateway para proteger seus aplicativos Web contra vulnerabilidades e explorações comuns da Web. Você também pode usar o Azure Private Link para acessar com segurança seus servidores de aplicativos back-end do Application Gateway sem expô-los à Internet pública.
Firewall do Azure: você pode adicionar um firewall do Azure à rede virtual do 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 DNS para intercetar e inspecionar o tráfego 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 Private Link com a camada 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 custos
A otimização de custos consiste em procurar 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 back-end: muitos fatores, como seleção de SKU, contagem de réplicas e região, impulsionam o custo de execução de serviços de computação 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.
Application Gateway: os custos do Application Gateway 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 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 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.
Contribuidores
Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.
Autor principal:
- Troy Hite - Brasil | Arquiteto de Soluções Cloud Sênior
Outros contribuidores:
- Mays Álgebary - Brasil | Blackbelt Global de Rede do Azure Sênior
- Adam Torkar - Brasil | Blackbelt Global de Rede do Azure Sênior
- Michael McKechney - Brasil | Principal Especialista em Tecnologia do Azure
Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.
Próximos passos
- Configuração da infraestrutura do Application Gateway
- TLS de ponta a ponta com o Azure Front Door
- Adicionar um domínio personalizado ao Azure Front Door
- O que é filtragem geográfica em um domínio para o Azure Front Door