Azure Firewall: Guia Completo de Regras, TLS/IDPS e Observabilidade

Este é o guia completo do Azure Firewall: em vez de espalhar cada recurso em um post separado, reunimos aqui toda a configuração real de um Azure Firewall em produção — da criação do recurso até os módulos avançados do tier Premium. Se você já leu algum dos vídeos antigos deste blog sobre Regras de Rede, DNAT, TLS Inspection ou IDPS no Azure Firewall, este post substitui todos eles com o conteúdo atualizado e organizado em um único lugar.

Ao longo das 7 seções a seguir, você vai entender a diferença entre os tiers Standard e Premium, como rotear o tráfego da rede para o firewall com Route Tables, como controlar a saída de tráfego com IP público adicional e NAT Gateway, como estruturar Network Rules, Application Rules e DNAT Rules usando Firewall Policy e IP Groups, os recursos exclusivos do Premium (TLS Inspection, IDPS, Threat Intelligence e Web Categories), a configuração de DNS e, por fim, como observar tudo isso via Log Analytics e Policy Analytics.

Sumário

• Criando o Azure Firewall: Standard vs. Premium
• Rede e roteamento: Route Table e UDR
• IP público e saída: IP adicional e NAT Gateway
• Regras de tráfego: Network, Application, DNAT e IP Groups
• Recursos Premium: TLS Inspection, IDPS, Threat Intelligence e Web Categories
• DNS: proxy do firewall vs. DNS customizado
• Observabilidade: Log Analytics e Policy Analytics
• Vídeos complementares
• Conclusão
• Referências oficiais

Criando o Azure Firewall: Standard vs. Premium

O Azure Firewall é um serviço de firewall como serviço (FWaaS) totalmente gerenciado, com alta disponibilidade nativa e escalonamento automático — você não gerencia VMs, não aplica patch e não dimensiona capacidade manualmente. Antes de criar o recurso, a primeira decisão do guia completo do Azure Firewall é escolher o tier:

A criação, em qualquer um dos dois tiers, sempre acontece dentro de uma sub-rede reservada chamada AzureFirewallSubnet (mínimo /26), na VNet de hub da sua topologia. O comando abaixo cria um Azure Firewall Premium associado a essa sub-rede e a um IP público:

# Sub-rede dedicada (nome fixo, exigido pelo serviço)
az network vnet subnet create \
  --resource-group rg-hub \
  --vnet-name vnet-hub \
  --name AzureFirewallSubnet \
  --address-prefixes 10.0.0.0/26

# IP público para a interface de saída do firewall
az network public-ip create \
  --resource-group rg-hub \
  --name pip-firewall \
  --sku Standard \
  --allocation-method Static

# Azure Firewall no tier Premium
az network firewall create \
  --resource-group rg-hub \
  --name fw-hub \
  --location eastus \
  --sku AZFW_VNet \
  --tier Premium

# Associa sub-rede e IP público ao firewall
az network firewall ip-config create \
  --resource-group rg-hub \
  --firewall-name fw-hub \
  --name fw-ipconfig \
  --public-ip-address pip-firewall \
  --vnet-name vnet-hub

Para trocar para o tier Standard, basta usar --tier Standard na criação — o downgrade de Premium para Standard depois de criado, no entanto, não é suportado; é preciso recriar o recurso. Por isso, vale decidir o tier com base nos requisitos de TLS Inspection/IDPS antes de provisionar em produção.

Rede e roteamento: Route Table e UDR

Criar o Azure Firewall sozinho não força nenhum tráfego a passar por ele — sem uma Route Table com rotas definidas pelo usuário (UDR), as sub-redes spoke continuam usando o roteamento padrão do sistema e ignoram o firewall completamente. É a Route Table que implementa o forced tunneling: todo tráfego de saída (e, opcionalmente, entre spokes) passa a ser direcionado para o IP privado do firewall antes de sair da VNet.

# Route Table associada à sub-rede do spoke
az network route-table create \
  --resource-group rg-spoke \
  --name rt-spoke-app

# Rota default: todo tráfego 0.0.0.0/0 passa pelo firewall
az network route-table route create \
  --resource-group rg-spoke \
  --route-table-name rt-spoke-app \
  --name rota-default-firewall \
  --address-prefix 0.0.0.0/0 \
  --next-hop-type VirtualAppliance \
  --next-hop-ip-address 10.0.0.4

# Associa a Route Table à sub-rede do spoke
az network vnet subnet update \
  --resource-group rg-spoke \
  --vnet-name vnet-spoke-app \
  --name snet-app \
  --route-table rt-spoke-app

O 10.0.0.4 do exemplo é o primeiro IP disponível dentro da AzureFirewallSubnet — normalmente o quarto endereço do bloco, já que os quatro primeiros de qualquer sub-rede do Azure são reservados. Um erro comum é esquecer de excluir a própria AzureFirewallSubnet dessa Route Table: ela precisa manter o roteamento padrão (rota direta para a internet), senão o próprio firewall tenta rotear seu tráfego de saída para si mesmo, criando um loop.

IP público e saída: IP adicional e NAT Gateway

Por padrão, todo o tráfego de saída do Azure Firewall sai por um único IP público (o associado na criação). Em ambientes com grande volume de conexões simultâneas, isso pode esgotar as portas SNAT disponíveis (cada IP público oferece um número finito de portas por back-end), gerando falhas de conexão intermitentes de saída — normalmente vistas como timeout em chamadas para APIs externas sob carga.

Existem duas formas de aumentar a capacidade de SNAT, cada uma com um trade-off diferente:

# Opção 1: adicionar um segundo IP público ao firewall
az network public-ip create -g rg-hub -n pip-firewall-02 --sku Standard --allocation-method Static
az network firewall ip-config create \
  --resource-group rg-hub --firewall-name fw-hub \
  --name fw-ipconfig-02 --public-ip-address pip-firewall-02 --vnet-name vnet-hub

# Opção 2: NAT Gateway na AzureFirewallSubnet
az network public-ip create -g rg-hub -n pip-natgw --sku Standard --allocation-method Static
az network nat gateway create -g rg-hub -n natgw-firewall --public-ip-addresses pip-natgw --idle-timeout 10
az network vnet subnet update -g rg-hub --vnet-name vnet-hub --name AzureFirewallSubnet --nat-gateway natgw-firewall

Na prática, a Microsoft recomenda o NAT Gateway como a forma preferida de resolver esgotamento de SNAT — ele escala portas de forma muito mais eficiente do que somar IPs públicos, e simplifica o allowlist de saída para times de segurança que precisam liberar acesso ponto a ponto com fornecedores externos.

Regras de tráfego: Network, Application, DNAT e IP Groups

Esta é a seção mais densa do guia completo do Azure Firewall: a forma moderna e recomendada de organizar regras não é mais via “regras clássicas” direto no recurso do firewall, e sim via Firewall Policy — um recurso separado que pode ser reutilizado por múltiplos firewalls (útil em topologias hub-spoke com mais de um firewall) e versionado independente do ciclo de vida do firewall em si.

Dentro de uma Policy, as regras vivem em Rule Collection Groups → Rule Collections → regras individuais, cada nível com sua própria prioridade numérica (quanto menor o número, mais cedo é avaliado):

• Network Rules (L3/L4) — filtram por IP de origem/destino, porta e protocolo (TCP/UDP/ICMP/Any). Não olham o conteúdo do pacote, só o cabeçalho — mais rápidas, ideais para tráfego leste-oeste entre VNets ou liberação de portas específicas.
• Application Rules (L7) — filtram por FQDN (nome de domínio) em tráfego HTTP/HTTPS, com suporte a wildcard (*.contoso.com). É o tipo certo para liberar saída para serviços SaaS conhecidos sem precisar rastrear o IP deles, que muda com frequência.
• DNAT Rules — traduzem um IP:porta público do firewall para um IP:porta privado interno, permitindo publicar um serviço interno (ex.: um servidor RDP/SSH) através do IP público do firewall sem expor a VM diretamente à internet.

Quando a mesma lista de IPs se repete em várias regras (por exemplo, os IPs de uma rede parceira que precisa acessar múltiplos serviços), o recurso de IP Groups evita duplicação: você define o grupo uma vez e referencia o grupo nas regras, em vez de colar a lista de IPs repetidamente.

# IP Group reutilizável em várias regras
az network ip-group create -g rg-hub -n ipg-rede-parceira --ip-addresses 203.0.113.0/24 198.51.100.10

# Policy + Rule Collection Group
az network firewall policy create -g rg-hub -n policy-hub --sku Premium
az network firewall policy rule-collection-group create \
  -g rg-hub --policy-name policy-hub -n rcg-trafego --priority 200

# Network Rule Collection: libera DNS (UDP/53) da rede parceira para os DCs internos
az network firewall policy rule-collection-group collection add-filter-collection \
  -g rg-hub --policy-name policy-hub --rule-collection-group-name rcg-trafego \
  --name allow-dns-parceiro --collection-priority 210 --action Allow \
  --rule-name allow-dns --rule-type NetworkRule --description "DNS da rede parceira" \
  --source-ip-groups ipg-rede-parceira --destination-addresses 10.0.10.4 10.0.10.5 \
  --destination-ports 53 --ip-protocols UDP

# Application Rule Collection: libera saída para um domínio SaaS específico
az network firewall policy rule-collection-group collection add-filter-collection \
  -g rg-hub --policy-name policy-hub --rule-collection-group-name rcg-trafego \
  --name allow-saas --collection-priority 220 --action Allow \
  --rule-name allow-contoso-saas --rule-type ApplicationRule \
  --source-addresses 10.0.20.0/24 --target-fqdns "*.contoso-saas.com" --protocols Https=443

# DNAT Rule: publica um RDP interno através do IP público do firewall
az network firewall policy rule-collection-group collection add-nat-collection \
  -g rg-hub --policy-name policy-hub --rule-collection-group-name rcg-trafego \
  --name dnat-rdp-jumpbox --collection-priority 100 --action Dnat \
  --rule-name rdp-jumpbox --source-addresses "*" \
  --translated-address 10.0.30.10 --translated-port 3389 \
  --destination-addresses 20.30.40.50 --destination-ports 3389 --ip-protocols TCP

Um ponto que gera dúvida recorrente: por padrão, o Azure Firewall segue o modelo “deny all” implícito — se o tráfego não bate em nenhuma regra de permissão, ele é bloqueado. Isso inclui o próprio tráfego de retorno das DNAT Rules: ao publicar um serviço via DNAT, normalmente também é preciso uma Network Rule complementar liberando o mesmo destino, origem e porta traduzida — a DNAT sozinha faz a tradução do IP, mas não implica permissão automática de rede.

Recursos Premium: TLS Inspection, IDPS, Threat Intelligence e Web Categories

Os quatro recursos desta seção só existem no tier Premium — é o que justifica o custo adicional em cenários de compliance ou inspeção profunda de tráfego.

• TLS Inspection — o firewall atua como um proxy TLS: descriptografa, inspeciona e recriptografa o tráfego HTTPS de saída. Exige uma Certificate Authority (CA) intermediária armazenada no Key Vault, referenciada via Managed Identity do firewall, e o certificado raiz dessa CA precisa estar instalado como confiável nos clientes (senão o navegador acusa certificado inválido). Sem TLS Inspection, o Azure Firewall vê apenas o SNI da conexão HTTPS — não o conteúdo real do tráfego.
• IDPS (Intrusion Detection and Prevention System) — compara o tráfego contra uma base de assinaturas de ameaças conhecidas, atualizada automaticamente pela Microsoft. Tem três modos: Off, Alert (só gera log, não bloqueia) e Alert and Deny (bloqueia e loga). É possível também sobrescrever o comportamento de assinaturas individuais (bypass de falsos positivos) por IP de origem/destino.
• Threat Intelligence — também tem os modos Off/Alert/Alert and Deny, mas compara IPs, domínios e URLs contra feeds de inteligência de ameaça da Microsoft (IPs conhecidos de C2, botnets, etc.), não assinaturas de payload. Standard e Premium têm esse recurso; a diferença do Premium é ter IDPS junto para inspecionar o conteúdo do tráfego também.
• Web Categories — permite escrever Application Rules baseadas em categoria de conteúdo do site (ex.: “Redes Sociais”, “Jogos”, “Apostas”) em vez de listar FQDNs manualmente. Útil para políticas de uso aceitável sem precisar manter uma lista de domínios.

# IDPS em modo Alert and Deny na Policy
az network firewall policy update \
  -g rg-hub -n policy-hub \
  --idps-mode Deny

# Threat Intelligence em modo Deny
az network firewall policy update \
  -g rg-hub -n policy-hub \
  --threat-intel-mode Deny

DNS: proxy do firewall vs. DNS customizado

O Azure Firewall pode atuar como proxy DNS: as VMs da rede apontam o firewall como servidor DNS, e ele resolve as consultas (usando o DNS padrão do Azure ou servidores customizados configurados na Policy) antes de encaminhar. Essa configuração tem uma implicação direta sobre as Application Rules: quando o proxy DNS está habilitado, o firewall consegue resolver o FQDN da regra para IP e aplicar a filtragem corretamente mesmo com TTLs curtos ou múltiplos IPs por domínio (comum em CDNs).

Sem o proxy DNS habilitado, a resolução de FQDN das Application Rules ainda funciona, mas depende do cache de DNS interno do próprio firewall, que pode ficar dessincronizado em domínios com múltiplos IPs. Por isso, em ambientes híbridos com DNS customizado (Active Directory, por exemplo), a recomendação é apontar a Policy do firewall para os mesmos servidores DNS internos usados pelo restante da rede, mantendo a resolução consistente entre firewall e clientes.

# Habilita proxy DNS e define servidores customizados na Policy
az network firewall policy update \
  -g rg-hub -n policy-hub \
  --enable-dns-proxy true \
  --dns-servers 10.0.10.4 10.0.10.5

Observabilidade: Log Analytics e Policy Analytics

Sem Diagnostic Settings configurado, o Azure Firewall não guarda histórico de logs — as categorias relevantes (AZFWNetworkRule, AZFWApplicationRule, AZFWDnatRule, AZFWIdpsSignature, entre outras) precisam ser enviadas explicitamente para um Log Analytics Workspace para virarem consultáveis via KQL.

# Envia todas as categorias de log e métricas para o Workspace
az monitor diagnostic-settings create \
  --name diag-fw-hub \
  --resource $(az network firewall show -g rg-hub -n fw-hub --query id -o tsv) \
  --workspace law-hub \
  --logs '[{"category":"AZFWNetworkRule","enabled":true},{"category":"AZFWApplicationRule","enabled":true},{"category":"AZFWDnatRule","enabled":true},{"category":"AZFWIdpsSignature","enabled":true},{"category":"AZFWThreatIntel","enabled":true}]' \
  --metrics '[{"category":"AllMetrics","enabled":true}]'

Com os logs fluindo, uma consulta útil no dia a dia é encontrar tráfego bloqueado por falta de regra — o sintoma mais comum ao migrar uma nova aplicação para trás do firewall:

AZFWNetworkRule
| where Action == "Deny"
| summarize Tentativas = count() by SourceIp = tostring(split(SourceIP, ":")[0]), DestinationIp = tostring(split(DestinationIP, ":")[0]), DestinationPort
| order by Tentativas desc
| take 20

Além do Log Analytics, o Azure Firewall oferece o Firewall Policy Analytics (workbook nativo do portal): ele cruza os logs de tráfego com as regras configuradas e aponta regras nunca utilizadas (candidatas a remoção, reduzindo a superfície de configuração) e regras “hit” (as mais acionadas, úteis para revisar prioridade). É a forma mais rápida de auditar uma Policy que cresceu ao longo de meses sem revisão.

Vídeos complementares

Este guia consolida e atualiza o conteúdo de 20 vídeos publicados originalmente neste blog sobre Azure Firewall. Os vídeos continuam disponíveis como material complementar, organizados por seção:

Conclusão

Com este guia completo do Azure Firewall, você tem em um único lugar o caminho inteiro de uma implantação real: escolher o tier certo, forçar o roteamento com Route Table, resolver esgotamento de SNAT, estruturar Network/Application/DNAT Rules com Firewall Policy, decidir se TLS Inspection/IDPS fazem sentido para o seu caso, configurar DNS de forma consistente e, por fim, observar tudo via Log Analytics e Policy Analytics. Esses são exatamente os pontos que mais geram dúvida em produção — principalmente a diferença entre Standard e Premium e o motivo de um DNAT Rule “não funcionar” sem a Network Rule complementar. Guarde este guia como referência: ele deve ser atualizado conforme novos recursos do Azure Firewall forem lançados.

Referências oficiais

• O que é o Azure Firewall? (Microsoft Learn)
• Recursos do Azure Firewall Premium (Microsoft Learn)
• Firewall Policy rule sets (Microsoft Learn)
• TLS Inspection — certificados (Microsoft Learn)
• Known issues do Azure Firewall (Microsoft Learn)
• Azure Firewall Workbook (Policy Analytics) (Microsoft Learn)

Interessado em saber mais sobre artigos relacionados ao Microsoft Azure CLIQUE AQUI

Este guia técnico é exclusivo do Blog do Castilho. Explore mais conteúdos sobre Cloud e DevOps.