Compartilhar via

Implementar uma rede de Confiança Zero para aplicativos Web usando o Firewall do Azure e o Gateway de Aplicativo do Azure

Este artigo descreve como implementar a segurança de Confiança Zero para aplicativos Web para habilitar a inspeção e a criptografia de ponta a ponta. O modelo de Confiança Zero inclui muitos outros conceitos, como verificação contínua de identidade e minimização do tamanho das áreas de confiança implícitas.

Este artigo se concentra no componente de criptografia e inspeção de uma arquitetura de Confiança Zero para tráfego de entrada da Internet pública. Para obter mais informações sobre outros aspectos da implantação de seu aplicativo com segurança, como autenticação e autorização, consulte a documentação confiança zero. O exemplo neste artigo usa uma abordagem multicamadas. Em uma abordagem multicamada, a segurança de rede compõe uma das camadas do modelo de Confiança Zero. Nessa camada, os dispositivos de rede inspecionam os pacotes para garantir que apenas o tráfego legítimo alcance os aplicativos.

Normalmente, tipos diferentes de dispositivos de rede inspecionam diferentes aspectos dos pacotes de rede:

  • Os firewalls do aplicativo Web procuram padrões que indicam um ataque na camada do aplicativo Web.

  • Os firewalls da próxima geração também podem procurar ameaças genéricas.

Essa arquitetura se concentra em um padrão comum para maximizar a segurança, no qual o Gateway de Aplicativo do Azure inspeciona e processa o tráfego antes de chegar ao Firewall do Azure Premium. Em alguns cenários, você pode combinar diferentes tipos de dispositivos de segurança de rede para aumentar a proteção. Para obter mais informações, consulte Firewall do Azure e Gateway de Aplicativo para redes virtuais.

Arquitetura

Diagrama de arquitetura que mostra o fluxo de pacotes em uma rede de aplicativo Web que usa o Gateway de Aplicativo na frente do Firewall do Azure Premium.

Baixe um arquivo do Visio dessa arquitetura.

Essa arquitetura usa o protocolo TLS para criptografar o tráfego em cada etapa.

  1. Um cliente envia pacotes ao Gateway de Aplicativo, um balanceador de carga. Ele é executado com a adição opcional do Firewall do Aplicativo Web do Azure.

  2. O Gateway de Aplicativo descriptografa os pacotes e procura ameaças a aplicativos Web. Se não encontrar ameaças, ele usará princípios de Confiança Zero para criptografar os pacotes. Em seguida, ele os libera.

  3. O Firewall do Azure Premium executa as seguintes verificações de segurança:

  4. Se os pacotes passarem pelos testes, o Firewall do Azure Premium executará estas etapas:

    • Ele criptografa os pacotes.
    • Ele usa um serviço DNS (Sistema de Nomes de Domínio) para determinar a VM (máquina virtual do aplicativo).
    • Ele encaminha os pacotes para a VM do aplicativo.

Vários mecanismos de inspeção nessa arquitetura garantem a integridade do tráfego:

  • O Firewall do Aplicativo Web do Azure usa regras para evitar ataques na camada da Web. Exemplos de ataques incluem injeção de código SQL e script entre sites. Para obter mais informações sobre regras e o Conjunto de Regras Principais (CRS) do Projeto de Segurança de Aplicações Mundialmente Aberto (OWASP), consulte o firewall de aplicações web, grupos de regras e regras do CRS.

  • O Firewall do Azure Premium usa regras de prevenção e detecção de intrusão genérica. Essas regras ajudam a identificar arquivos mal-intencionados e outras ameaças direcionadas a aplicativos Web.

Essa arquitetura dá suporte aos seguintes tipos de design de rede, que este artigo discute:

  • Redes de Hub e spoke tradicionais
  • Redes que usam a WAN Virtual do Azure como uma plataforma
  • Redes que usam o Servidor de Rota do Azure para simplificar o roteamento dinâmico

Firewall do Azure Premium e resolução de nomes

Quando o Firewall do Azure Premium verifica o tráfego mal-intencionado, ele verifica se o cabeçalho do Host HTTP corresponde ao endereço IP do pacote e à porta TCP (Protocolo de Controle de Transmissão). Por exemplo, suponha que o Gateway de Aplicativo envie pacotes da Web para o endereço IP 172.16.1.4 e a porta TCP 443. O valor do cabeçalho de host HTTP deve ser resolvido para esse endereço IP.

Os cabeçalhos de host HTTP geralmente não contêm endereços IP. Em vez disso, os cabeçalhos contêm nomes que correspondem ao certificado digital do servidor. Nesse caso, o Firewall do Azure Premium usa o DNS para resolver o nome do cabeçalho de host para um endereço IP. O design de rede determina qual solução DNS funciona melhor.

Observação

O Gateway de Aplicativo não oferece suporte a números de porta em cabeçalhos de host HTTP. Como resultado:

  • O Firewall do Azure Premium assume uma porta TCP HTTPS padrão de 443.
  • A conexão entre o Gateway de Aplicativo e o servidor Web dá suporte apenas à porta TCP 443, não a portas não padrão.

Certificados digitais

O diagrama a seguir mostra os nomes comuns (CNs) e as autoridades de certificação (CAs) que as sessões e certificados TLS dessa arquitetura usam.

Diagrama que mostra as CNs e CAs que uma rede de aplicativo Web usa quando um balanceador de carga está na frente de um firewall.

O Firewall do Azure gera dinamicamente seus próprios certificados. Essa funcionalidade é um dos principais motivos pelos quais ela é colocada atrás do Gateway de Aplicativo. Caso contrário, o cliente do aplicativo será confrontado com certificados autogeridos que são sinalizados como um risco de segurança.

Conexões TLS

Essa arquitetura contém três conexões TLS distintas. Certificados digitais validam cada um deles.

De clientes para o Gateway de Aplicativo

No Gateway de Aplicativo, você implanta o certificado digital que os clientes veem. Uma autoridade de certificação bem conhecida, como DigiCert ou Let's Encrypt, normalmente emite um certificado. Esse mecanismo é fundamentalmente diferente de como o Firewall do Azure gera dinamicamente certificados digitais de uma AC de infraestrutura de chave pública autoassinada ou interna.

Do Gateway de Aplicativo para o Firewall do Azure Premium

Para descriptografar e inspecionar o tráfego TLS, o Firewall do Azure Premium gera certificados dinamicamente. O Firewall do Azure Premium também se apresenta ao Gateway de Aplicativo como o servidor da Web. Uma autoridade de certificação privada assina os certificados que o Firewall do Azure Premium gera. Para obter mais informações, confira Certificados do Firewall do Azure Premium. O Gateway de Aplicativo precisa validar esses certificados. Nas configurações HTTP do aplicativo, você configura a autoridade de certificação raiz que o Firewall do Azure Premium usa.

Do Firewall do Azure Premium para o servidor Web

O Firewall do Azure Premium estabelece uma sessão TLS com o servidor Web de destino. O Firewall do Azure Premium verifica se uma autoridade de certificação conhecida assina os pacotes do servidor Web TLS.

Funções de componente

O Gateway de aplicativo e o Firewall do Azure Premium lida com certificados de forma diferente, pois suas funções diferem:

  • O Gateway de Aplicativo é um proxy Web reverso. Ele protege servidores Web de clientes mal-intencionados interceptando solicitações HTTP e HTTPS. Você declara cada servidor protegido que está no pool de back-end do Gateway de Aplicativo com seu endereço IP ou nome de domínio totalmente qualificado. Os clientes legítimos devem ser capazes de acessar cada aplicativo. Então você configura o Application Gateway com um certificado digital assinado por uma CA pública. Use uma Autoridade Certificadora que seja aceita por qualquer cliente TLS.

  • O Firewall do Azure Premium é um proxy Web progressivo ou, simplesmente, um proxy Web. Ele protege clientes de servidores Web mal-intencionados interceptando chamadas TLS dos clientes protegidos. Quando um cliente protegido faz uma solicitação HTTP, o proxy Web de encaminhamento representa o servidor Web de destino gerando certificados digitais e apresentando-os ao cliente. O Firewall do Azure Premium usa uma autoridade de certificação privada, que assina os certificados gerados dinamicamente. Você configura os clientes protegidos para confiar nessa autoridade de certificação privada. Nessa arquitetura, o Firewall do Azure Premium protege as solicitações do Gateway de Aplicativo para o servidor Web. O Gateway de Aplicativo confia na autoridade de certificação privada que o Firewall do Azure Premium usa.

Roteamento e encaminhamento de tráfego

O roteamento é ligeiramente diferente dependendo da topologia do seu design de rede. As seções a seguir descrevem exemplos de topologias hub e spoke, WAN Virtual e Servidor de Roteamento. Todas as topologias têm os seguintes aspectos em comum:

  • O Gateway de Aplicativo sempre serve como um proxy. O Firewall do Azure Premium também serve como um proxy quando ele é configurado para inspeção do TLS. O Gateway de Aplicativo encerra as sessões TLS de clientes e novas sessões TLS são criadas para o Firewall do Azure. O Firewall do Azure recebe e encerra as sessões TLS provenientes do Gateway de Aplicativo e cria novas sessões TLS em direção às cargas de trabalho. Esse processo afeta a configuração do IDPS do Firewall do Azure Premium. Para obter mais informações, consulte IDPS e endereços IP privados.

  • A carga de trabalho identifica conexões que vêm do endereço IP da sub-rede do Firewall do Azure. O endereço IP do cliente original é preservado no X-Forwarded-For cabeçalho HTTP inserido pelo Gateway de Aplicativo. O Firewall do Azure também dá suporte à injeção do endereço IP do cliente de origem no X-Forwarded-For cabeçalho. Nesse cenário, o endereço IP do cliente de origem é o endereço IP do gateway de aplicativo.

  • O tráfego do Gateway de Aplicativo para a carga de trabalho normalmente é enviado para o Firewall do Azure usando mecanismos de roteamento do Azure. Esses mecanismos incluem UDRs (rotas definidas pelo usuário) configuradas na sub-rede do Gateway de Aplicativo ou rotas que a WAN Virtual ou o Servidor de Rota injetam. É possível definir explicitamente o endereço IP privado do Firewall do Azure no pool de back-end do Gateway de Aplicativo, mas não recomendamos fazê-lo porque isso remove algumas das funcionalidades nativas do Gateway de Aplicativo, como balanceamento de carga e persistência de sessão.

As seções a seguir descrevem algumas das topologias mais comuns que você pode usar com o Firewall do Azure e o Gateway de Aplicativo.

Topologia hub-spoke

Um design hub e spoke normalmente implanta componentes de rede compartilhados na rede virtual hub e componentes específicos do aplicativo nos spokes. Na maioria dos sistemas, o Firewall do Azure Premium é um recurso compartilhado. O Firewall do Aplicativo Web do Azure pode ser um dispositivo de rede compartilhado ou um componente específico do aplicativo. É uma prática recomendada tratar o Application Gateway como um componente de aplicativo e implantá-lo em uma rede virtual em ramificação pelos seguintes motivos:

  • Pode ser difícil solucionar problemas de alertas do Firewall do Aplicativo Web do Azure. Geralmente, você precisa de um conhecimento aprofundado do aplicativo para decidir se as mensagens que disparam esses alarmes são legítimas.

  • Se você tratar o Gateway de Aplicativo como um recurso compartilhado, poderá exceder os limites do Gateway de Aplicativo.

  • Você pode enfrentar problemas de controle de acesso baseado em função se implantar o Gateway de Aplicativo do Azure. Essa situação pode ocorrer quando as equipes gerenciam aplicativos diferentes, mas usam a mesma instância do Gateway de Aplicativo. Cada equipe tem acesso a toda a configuração do Gateway de Aplicativo.

Em arquiteturas tradicionais de hub e spoke, as zonas privadas DNS fornecem uma maneira fácil de usar o DNS:

  1. Configure uma zona privada de DNS.
  2. Vincule a zona à rede virtual que contém o Firewall do Azure Premium.
  3. Certifique-se de que exista um registro de endereço para o valor que o Application Gateway usa para tráfego e para verificações de integridade.

O diagrama a seguir mostra o fluxo de pacotes quando o Gateway de Aplicativo está em uma rede virtual spoke. Nesse caso, um cliente se conecta da Internet pública.

Diagrama que mostra o fluxo de pacotes em uma rede hub e spoke que inclui um balanceador de carga e um firewall. Os clientes se conectam da Internet pública.

  1. Um cliente envia uma solicitação para um servidor Web.

  2. O Gateway de Aplicativo intercepta os pacotes do cliente e os examina. Se os pacotes passarem na inspeção, o Gateway de Aplicativo enviará os pacotes para a VM de back-end. Quando os pacotes chegam ao Azure, uma UDR na sub-rede do Gateway de Aplicativo os encaminha para o Firewall premium do Azure.

  3. O Firewall do Azure Premium executa verificações de segurança nos pacotes. Se eles passam nos testes, o Firewall do Azure Premium encaminha os pacotes para a VM do aplicativo.

  4. A VM responde e define o endereço IP de destino para o gateway de aplicativo. Uma UDR na sub-rede da VM redireciona os pacotes para o Firewall do Azure Premium.

  5. O Firewall do Azure Premium encaminha os pacotes para o Gateway de Aplicativo.

  6. O Gateway de Aplicativo responde ao cliente.

O tráfego também pode chegar de uma rede local em vez da Internet pública. O tráfego flui por meio de uma VPN (rede virtual privada) site a site ou por meio do Azure ExpressRoute. Nesse cenário, o tráfego primeiro alcança um gateway de rede virtual no hub. O restante do fluxo de rede é o mesmo que o diagrama anterior.

Diagrama que mostra o fluxo de pacotes em uma rede hub e spoke que inclui um balanceador de carga e um firewall. Os clientes se conectam de uma rede local.

  1. Um cliente local se conecta ao gateway de rede virtual.

  2. O gateway de rede virtual encaminha os pacotes do cliente para o Gateway de Aplicativo.

  3. O Gateway de Aplicativo examina os pacotes. Se eles passarem na inspeção, uma UDR na sub-rede do Gateway de Aplicativo encaminhará os pacotes para o Firewall do Azure Premium.

  4. O Firewall do Azure Premium executa verificações de segurança nos pacotes. Se eles passam nos testes, o Firewall do Azure Premium encaminha os pacotes para a VM do aplicativo.

  5. A VM responde e define o endereço IP de destino para o Gateway de Aplicativo. Uma UDR na sub-rede da VM redireciona os pacotes para o Firewall do Azure Premium.

  6. O Firewall do Azure Premium encaminha os pacotes para o Gateway de Aplicativo.

  7. O Gateway de Aplicativo envia os pacotes para o gateway de rede virtual.

  8. O gateway de rede virtual responde ao cliente.

Topologia de WAN virtual

Você também pode usar a WAN Virtual do serviço de rede nessa arquitetura. Esse componente oferece muitos benefícios. Por exemplo, elimina a necessidade de UDRs mantidos pelo usuário em redes virtuais spoke. Em vez disso, você pode definir rotas estáticas em tabelas de rotas de hub virtual. A programação de cada rede virtual que você conecta ao hub contém essas rotas.

Quando você usa a WAN Virtual como uma plataforma de rede, duas diferenças principais ocorrem:

  • Você não pode vincular zonas privadas DNS a um hub virtual porque a Microsoft gerencia hubs virtuais. Como proprietário da assinatura, você não tem permissões para vincular zonas DNS privadas. Como resultado, você não pode associar uma zona privada DNS ao hub seguro que contém o Firewall do Azure Premium.

    Para implementar a resolução DNS para Firewall do Azure Premium, use servidores DNS em vez disso:

    • Defina as configurações de DNS do Firewall do Azure para usar servidores DNS personalizados.

    • Implante os servidores em uma rede virtual de serviços compartilhados que você conecta à WAN Virtual.

    • Vincule uma zona privada DNS à rede virtual de serviços compartilhados. Os servidores DNS podem resolver os nomes que o Gateway de Aplicativo usa em cabeçalhos de host HTTP. Para obter mais informações, consulte Configurações de DNS do Firewall do Azure.

  • Você só poderá usar a WAN Virtual para programar rotas em um spoke se o prefixo for menor (menos específico) que o prefixo de rede virtual. Por exemplo, nos diagramas anteriores, a rede virtual spoke tem o prefixo 172.16.0.0/16. Nesse caso, a WAN Virtual não é capaz de injetar uma rota que corresponda ao prefixo de rede virtual (172.16.0.0/16) ou a qualquer uma das sub-redes (172.16.0.0/24, 172.16.1.0/24). Em outras palavras, a WAN Virtual não pode direcionar o tráfego entre duas sub-redes que estão na mesma rede virtual.

    Essa limitação se torna evidente quando o Gateway de Aplicativo e o servidor Web de destino estão na mesma rede virtual. A WAN Virtual não pode forçar o tráfego entre o Gateway de Aplicativo e o servidor Web a passar pelo Firewall do Azure Premium. Uma solução alternativa é configurar manualmente UDRs no Gateway de Aplicação e nas sub-redes do servidor web.

O diagrama a seguir mostra o fluxo de pacotes em uma arquitetura que usa WAN Virtual. Nesse cenário, o acesso ao Gateway de Aplicativo vem de uma rede local. Uma vpn site a site ou uma instância do ExpressRoute conecta essa rede à WAN Virtual. O acesso baseado na Internet segue um caminho semelhante.

Diagrama que mostra o fluxo de pacotes em uma rede hub e spoke que inclui um balanceador de carga, um firewall e uma WAN Virtual.

  1. Um cliente local se conecta ao gateway de VPN.

  2. O gateway de VPN encaminha os pacotes do cliente para o Gateway de Aplicativo.

  3. O Gateway de Aplicativo examina os pacotes. Se eles passarem na inspeção, uma sub-rede do Gateway de Aplicativo encaminhará os pacotes para o Firewall do Azure Premium.

  4. O Firewall do Azure Premium solicita a resolução DNS de um servidor DNS na rede virtual de serviços compartilhados.

  5. O servidor DNS responde à solicitação de resolução.

  6. O Firewall do Azure Premium executa verificações de segurança nos pacotes. Se eles passam nos testes, o Firewall do Azure Premium encaminha os pacotes para a VM do aplicativo.

  7. A VM responde e define o endereço IP de destino para o Gateway de Aplicativo. A sub-rede do aplicativo redireciona os pacotes para o Firewall premium do Azure.

  8. O Firewall do Azure Premium encaminha os pacotes para o Gateway de Aplicativo.

  9. O Gateway de Aplicativo envia os pacotes para o gateway de VPN.

  10. O gateway de VPN responde ao cliente.

Se você usar esse design, talvez seja necessário modificar o roteamento que o hub anuncia para as redes virtuais spoke. Especificamente, o Application Gateway v2 dá suporte apenas a uma 0.0.0.0/0 rota que aponta para a internet. As rotas com esse endereço que não apontam para a Internet quebram a conectividade que a Microsoft requer para gerenciar o Gateway de Aplicativo. Se o hub virtual anunciar uma 0.0.0.0/0 rota, impeça que essa rota se propague para a sub-rede do Gateway de Aplicativo seguindo uma destas etapas:

  • Crie uma tabela de rotas com uma rota para 0.0.0.0/0 e um tipo de próximo salto de Internet. Associe essa rota à sub-rede em que você implanta o Gateway de Aplicativo.

  • Se você implantar o Gateway de Aplicativo em um spoke dedicado, desabilite a propagação da rota padrão nas configurações da conexão de rede virtual.

Topologia do Servidor de Rotas

O Servidor de Rota fornece outra maneira de injetar rotas automaticamente em spokes. Use essa funcionalidade para evitar a sobrecarga administrativa de manutenção de tabelas de rotas. O Servidor de Rota combina as variantes WAN Virtual e hub e spoke:

  • Você pode usar o Route Server para gerenciar redes virtuais do hub. Como resultado, você pode vincular a rede virtual do hub a uma zona privada DNS.

  • O Servidor de Rota tem a mesma limitação que a WAN Virtual tem em relação aos prefixos de endereço IP. Você só poderá injetar rotas em um spoke se o prefixo for menor (mes específico) que o prefixo de rede virtual. Devido a essa limitação, o Gateway de Aplicativo e o servidor Web de destino precisam estar em redes virtuais diferentes.

O diagrama a seguir mostra o fluxo de pacotes quando o Servidor de Rota simplifica o roteamento dinâmico. Considere os seguintes pontos:

  • Atualmente, o Servidor de Rota exige que o dispositivo que injeta as rotas as envie pelo BGP (Border Gateway Protocol). O Firewall do Azure Premium não dá suporte ao BGP, portanto, use uma NVA (solução de virtualização de rede) que não seja da Microsoft.

  • A funcionalidade da NVA no hub determina se a sua implementação precisa de DNS.

Diagrama que mostra o fluxo de pacotes em uma rede hub and spoke que inclui um balanceador de carga, um firewall e um Servidor de Roteamento.

  1. Um cliente local se conecta ao gateway de rede virtual.

  2. O gateway de rede virtual encaminha os pacotes do cliente para o Gateway de Aplicativo.

  3. O Gateway de Aplicativo examina os pacotes. Se eles passarem pela inspeção, a sub-rede do Gateway de Aplicativo encaminha os pacotes para um computador de back-end. O Servidor de Roteamento injeta uma rota na sub-rede do Gateway de Aplicações que encaminha o tráfego para uma NVA.

  4. A sub-rede NVA solicita resolução DNS de um servidor DNS na rede virtual de serviços compartilhados.

  5. O servidor DNS responde à solicitação de resolução.

  6. A NVA executa verificações de segurança nos pacotes. Se eles passarem nos testes, a NVA encaminhará os pacotes para a VM do aplicativo.

  7. A VM do aplicativo responde e define o endereço IP de destino como Gateway de Aplicativo. O Servidor de Rota injeta uma rota na sub-rede da VM que redireciona os pacotes para a NVA.

  8. A NVA encaminha os pacotes para o Gateway de Aplicativo.

  9. O Gateway de Aplicativo envia os pacotes para o gateway de rede virtual.

  10. O gateway de rede virtual responde ao cliente.

Assim como acontece com a WAN Virtual, talvez seja necessário modificar o roteamento ao usar o Servidor de Rota. Se você anunciar a rota 0.0.0.0/0, ela poderá se propagar para a sub-rede do Gateway de Aplicativo. No entanto, o Gateway de Aplicativo não dá suporte a essa rota. Nesse caso, configure uma tabela de rotas para a sub-rede do Gateway de Aplicativo. Inclua uma rota para 0.0.0.0/0 e um tipo de próximo salto de Internet nessa tabela.

Endereços IP privados e IDPS

O Firewall premium do Azure decide quais regras IDPS aplicar com base nos endereços IP de origem e de destino dos pacotes. Por padrão, o Firewall do Azure trata endereços IP privados nos intervalos RFC 1918 (10.0.0.0/8e 192.168.0.0/16172.16.0.0/12) e RFC 6598 (100.64.0.0/10) como internos. Portanto, se você implantar o Gateway de Aplicativo em uma sub-rede em um desses intervalos, o Firewall Premium do Azure considerará o tráfego entre o Gateway de Aplicativo e a carga de trabalho como interno. Portanto, somente assinaturas IDPS marcadas para serem aplicadas ao tráfego interno ou a qualquer tráfego são usadas. As assinaturas IDPS marcadas para serem aplicadas ao tráfego de entrada ou de saída não são aplicadas ao tráfego entre o Gateway de Aplicativo e a carga de trabalho. Para obter mais informações, consulte as regras do IDPS do Firewall do Azure.

A maneira mais fácil de forçar as regras de assinatura de entrada do IDPS a serem aplicadas ao tráfego entre o Gateway de Aplicativo e a carga de trabalho é colocando o Gateway de Aplicativo em uma sub-rede que usa um prefixo fora dos intervalos privados. Você não precisa necessariamente usar endereços IP públicos para essa sub-rede. Em vez disso, você pode personalizar os endereços IP que o Firewall do Azure Premium trata como interno para IDPS. Por exemplo, se sua organização não usar o intervalo 100.64.0.0/10, você poderá eliminar esse intervalo da lista de prefixos internos para IDPS e implantar o Gateway de Aplicação em uma sub-rede configurada com um endereço IP em 100.64.0.0/10. Para obter mais informações, consulte os intervalos de IPDS privados do Firewall do Azure Premium.

Contribuidores

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

Autor principal:

  • Jose Moreno | Engenheiro Principal de Atendimento ao Cliente

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

Próximas etapas

  • Last updated on