Partilhar via

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

Este artigo descreve como implementar a segurança Zero Trust para aplicativos Web para habilitar a inspeção e a criptografia de ponta a ponta. O modelo Zero Trust 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 Zero Trust para tráfego de entrada da Internet pública. Para obter mais informações sobre outros aspetos da implantação segura do seu aplicativo, como autenticação e autorização, consulte a documentação do Zero Trust. O exemplo neste artigo usa uma abordagem multicamadas. Em uma abordagem multicamadas, a segurança de rede compõe uma das camadas do modelo Zero Trust. Nessa camada, os dispositivos de rede inspecionam os pacotes para garantir que apenas o tráfego legítimo chegue aos aplicativos.

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

  • Os firewalls de aplicativos Web procuram padrões que indiquem um ataque na camada de aplicativos Web.

  • Os firewalls de última 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 que ele chegue ao Firewall Premium do Azure. 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 Premium do Azure.

Descarregue um ficheiro Visio desta arquitetura.

Essa arquitetura usa o protocolo TLS (Transport Layer Security) para criptografar o tráfego em cada etapa.

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

  2. O Application Gateway descriptografa os pacotes e procura ameaças a aplicativos Web. Se não encontrar nenhuma ameaça, ele usa os princípios Zero Trust para criptografar os pacotes. Depois, liberta-os.

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

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

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

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

  • O Firewall de Aplicativo Web do Azure usa regras para evitar ataques na camada da Web. Exemplos de ataques incluem injeção de código SQL e scripts entre sites. Para obter mais informações sobre regras e o conjunto de regras principais (CRS) do Open Worldwide Application Security Project (OWASP), consulte Grupos de regras e regras CRS do firewall de aplicativo Web.

  • O Firewall Premium do Azure usa regras genéricas de deteção e prevenção de invasões. Essas regras ajudam a identificar arquivos mal-intencionados e outras ameaças que visam aplicativos Web.

Essa arquitetura oferece suporte aos seguintes tipos de design de rede, que este artigo aborda:

  • Redes tradicionais de hub e spoke
  • Redes que usam a WAN Virtual do Azure como uma plataforma
  • Redes que usam o Azure Route Server para simplificar o roteamento dinâmico

Azure Firewall Premium e resolução de nomes

Quando o Firewall Premium do Azure verifica se há tráfego mal-intencionado, ele verifica se o cabeçalho do Host HTTP corresponde ao endereço IP do pacote e à porta TCP (Transmission Control Protocol). Por exemplo, suponha que o Application Gateway envia pacotes da Web para o endereço IP 172.16.1.4 e a porta TCP 443. O valor do cabeçalho HTTP Host 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 Premium do Azure usa o DNS para resolver o nome do cabeçalho do Host para um endereço IP. O design de rede determina qual solução DNS funciona melhor.

Observação

O Application Gateway não suporta números de porta em cabeçalhos de Host HTTP. Como resultado:

  • O Firewall Premium do Azure assume uma porta TCP HTTPS padrão de 443.
  • A conexão entre o Application Gateway e o servidor Web suporta apenas a porta TCP 443, não 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 TLS e os certificados dessa arquitetura usam.

Diagrama que mostra os CNs e CAs que uma rede de aplicação web usa quando um balanceador de carga está à frente de um firewall.

O Firewall do Azure gera dinamicamente seus próprios certificados. Esse recurso é uma das principais razões pelas quais ele é colocado atrás do Application Gateway. Caso contrário, o cliente do aplicativo será confrontado com certificados autogerados que são sinalizados como um risco de segurança.

Conexões TLS

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

Dos clientes ao Application Gateway

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

Do Gateway de Aplicativo ao Firewall Premium do Azure

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

Do Firewall Premium do Azure para o servidor Web

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

Funções dos componentes

O Gateway de Aplicativo e o Firewall Premium do Azure lidam com certificados de forma diferente um do outro porque suas funções diferem:

  • O Application Gateway é um proxy da Web reverso . Ele protege os servidores web de clientes mal-intencionados intercetando solicitações HTTP e HTTPS. Você declara cada servidor protegido que está no pool de back-end do Application Gateway com seu endereço IP ou nome de domínio totalmente qualificado. Os clientes legítimos devem poder aceder a cada aplicação. Assim, você configura o Application Gateway com um certificado digital que uma autoridade de certificação pública assina. Use uma autoridade de certificação que qualquer cliente TLS aceite.

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

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 de hub e spoke, WAN Virtual e Route Server. Todas as topologias têm os seguintes aspetos em comum:

  • O Application Gateway sempre serve como proxy. O Firewall Premium do Azure também serve como um proxy quando está configurado para inspeção TLS. O Application Gateway encerra as sessões TLS dos 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 originadas do Gateway de Aplicativo e cria novas sessões TLS para as cargas de trabalho. Esse processo afeta a configuração do IDPS do Firewall Premium do Azure. Para obter mais informações, consulte IDPS e endereços IP privados.

  • A carga de trabalho deteta ligações que provêm do endereço IP da sub-rede do Firewall do Azure. O endereço IP do cliente original é preservado no cabeçalho HTTP que o X-Forwarded-For Application Gateway insere. O Firewall do Azure também suporta a injeção do endereço IP do cliente de origem no cabeçalho X-Forwarded-For. 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 rotas definidas pelo usuário (UDRs) configuradas na sub-rede do Application Gateway ou rotas que a WAN Virtual ou o Route Server injetam. Definir explicitamente o endereço IP privado do Firewall do Azure no pool de back-end do Gateway de Aplicativo é possível, mas não recomendamos fazê-lo porque remove algumas das funcionalidades nativas do Gateway de Aplicativo, como balanceamento de carga e aderê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 Aplicativos.

Topologia hub e spoke

Um design de concentrador e ramificações normalmente implanta componentes de rede partilhados na rede virtual do concentrador e componentes específicos da aplicação nas ramificações. Na maioria dos sistemas, o Firewall Premium do Azure é um recurso compartilhado. O Firewall de 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 spoke pelos seguintes motivos:

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

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

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

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

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

O diagrama a seguir mostra o fluxo de pacotes quando o Application Gateway está em uma rede virtual falada. Neste caso, um cliente se conecta a partir 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 a partir da internet pública.

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

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

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

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

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

  6. O Application Gateway responde ao cliente.

O tráfego também pode chegar de uma rede local em vez da Internet pública. O tráfego flui através de uma rede virtual privada (VPN) site a site ou através da Rota Expressa do Azure. Nesse cenário, o tráfego primeiro atinge um gateway de rede virtual no hub. O resto 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 a partir 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 Application Gateway.

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

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

  5. A VM responde e define o endereço IP de destino como Application Gateway. Um UDR na sub-rede VM redireciona os pacotes para o Azure Firewall Premium.

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

  7. O Application Gateway 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 o serviço de rede WAN Virtual nessa arquitetura. Este componente oferece muitos benefícios. Por exemplo, elimina a necessidade de UDRs mantidos pelo usuário em redes virtuais faladas. 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 resultam:

  • Não é possível 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 de DNS ao hub seguro que contém o Firewall Premium do Azure.

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

    • Configure as definições de DNS do Firewall do Azure para utilizar 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 então resolver os nomes que o Application Gateway usa em cabeçalhos de Host HTTP. Para obter mais informações, consulte Configurações de DNS do Firewall do Azure.

  • Você só pode usar a WAN Virtual para programar rotas em um spoke se o prefixo for mais curto (menos específico) do que o prefixo da 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 da 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 torna-se aparente quando o Application Gateway 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 Premium do Azure. Uma solução alternativa é configurar manualmente UDRs nas sub-redes do Application Gateway e 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 Application Gateway vem de uma rede local. Uma instância de VPN site a site ou 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 WAN Virtual.

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

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

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

  4. O Firewall Premium do Azure 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 Premium do Azure executa verificações de segurança nos pacotes. Se eles passarem nos testes, o Firewall Premium do Azure encaminhará os pacotes para a VM do aplicativo.

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

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

  9. O Application Gateway envia os pacotes para o gateway VPN.

  10. O gateway VPN responde ao cliente.

Se utilizar este design, talvez seja necessário modificar o roteamento que o hub anuncia para as redes virtuais satélites. Especificamente, o Application Gateway v2 suporta apenas uma 0.0.0.0/0 rota que aponta para a Internet. Rotas com esse endereço que não apontam para a Internet interrompem a conectividade que a Microsoft requer para gerenciar o Application Gateway. Se o hub virtual anunciar uma 0.0.0.0/0 rota, impeça que essa rota se propague para a sub-rede do Application Gateway seguindo uma destas etapas:

  • Crie uma tabela de rotas com uma rota para 0.0.0.0/0 e defina o tipo de próximo salto como Internet. Associe essa rota à sub-rede na qual você implanta o Application Gateway.

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

Topologia do Route Server

Route Server fornece outra maneira de injetar rotas automaticamente em ramos. Use essa funcionalidade para evitar a sobrecarga administrativa de manter tabelas de rotas. O Route Server combina a WAN Virtual e as variantes hub e spoke:

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

  • O Route Server tem a mesma limitação que a WAN Virtual tem em relação aos prefixos de endereço IP. Você só pode injetar rotas em um spoke se o prefixo for mais curto (menos específico) do que o prefixo da rede virtual. Devido a essa limitação, o Application Gateway e o servidor Web de destino precisam estar em redes virtuais diferentes.

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

  • Atualmente, o Route Server requer o dispositivo que injeta as rotas para enviá-las pelo Border Gateway Protocol (BGP). O Firewall Premium do Azure não oferece suporte a BGP, portanto, use um dispositivo virtual de rede (NVA) que não seja da Microsoft.

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

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

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

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

  3. O Application Gateway examina os pacotes. Se eles passarem na inspeção, a sub-rede do Application Gateway encaminhará os pacotes para uma máquina de back-end. O Route Server injeta uma rota na sub-rede do Application Gateway que encaminha o tráfego para um 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. O NVA executa verificações de segurança nos pacotes. Se eles passarem nos testes, o NVA encaminhará os pacotes para a VM do aplicativo.

  7. A VM do aplicativo responde e define o endereço IP de destino como Application Gateway. O Route Server injeta uma rota na sub-rede VM que redireciona os pacotes para o NVA.

  8. O NVA encaminha os pacotes para o Application Gateway.

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

  10. O gateway de rede virtual responde ao cliente.

Como com a WAN Virtual, talvez seja necessário modificar o roteamento ao usar o Route Server. Se você anunciar a 0.0.0.0/0 rota, ela poderá se propagar para a sub-rede do Application Gateway. Mas o Application Gateway não oferece suporte a essa rota. Nesse caso, configure uma tabela de rotas para a sub-rede do Application Gateway. Inclua uma rota para 0.0.0.0/0 e um tipo de Internet de próximo salto nessa tabela.

IDPS e endereços IP privados

O Firewall Premium do Azure decide quais regras de IDPS aplicar com base nos endereços IP de origem e destino dos pacotes. Por padrão, o Firewall do Azure trata endereços IP privados nos intervalos RFC 1918 (10.0.0.0/8, 192.168.0.0/16e 172.16.0.0/12) e RFC 6598 (100.64.0.0/10) como internos. Portanto, se o Aplicativo Gateway for implantado numa sub-rede em um desses intervalos, o Firewall Premium do Azure considerará o tráfego entre o Aplicativo Gateway e a carga de trabalho como interno. Portanto, apenas 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 Application Gateway e a carga de trabalho. Para obter mais informações, consulte Regras 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 Application Gateway e a carga de trabalho é colocando o Application Gateway 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 Premium do Azure trata como internos para IDPS. Por exemplo, se sua organização não usa o 100.64.0.0/10 intervalo, você pode eliminá-lo da lista de prefixos internos para IDPS e implantar o Application Gateway em uma sub-rede configurada com um endereço IP no 100.64.0.0/10. Para mais informações, consulte intervalos de IPDS privados do Azure Firewall Premium.

Contribuidores

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

Autor principal:

  • Jose Moreno - Brasil | Engenheiro de Clientes Principal

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

Próximos passos

  • Last updated on