Azure Firewall Premium Lab: IDPS, TLS Inspection e saída inspecionada

01

Contexto

Quem desenha uma Landing Zone gasta a maior parte do tempo no tráfego de entrada. Regras de inbound, publicação de aplicação, exposição de endpoint e WAF consomem as decisões difíceis. A saída costuma entrar no fim do projeto, resolvida com uma regra ampla e a frase "depois a gente ajusta".

Só que a saída é justamente por onde passam os eventos que mais doem: exfiltração de dados, comunicação de comando e controle de malware e callback de supply chain. Nenhum deles precisa de porta de entrada aberta. Todos precisam apenas de uma saída permissiva.

O laboratório nasceu de uma pergunta simples e desconfortável: se eu deixo o NSG do workload totalmente aberto na saída, o que exatamente acontece com o tráfego? A resposta separa duas camadas de defesa que muita gente trata como equivalentes.

02

Objetivo

O lab compara duas camadas no mesmo fluxo de tráfego, sem simulação e sem teoria: um Network Security Group e um firewall de próxima geração com inspeção profunda de pacote.

03

Arquitetura

O desenho é o hub-spoke clássico, com uma diferença deliberada: o firewall não é opcional. A VM do spoke não tem IP público e a tabela de rotas não oferece caminho alternativo. Todo pacote que sai do workload passa pelo endereço privado do firewall no hub.

04

Hub e Firewall Premium

O hub concentra a decisão. Ele não apenas roteia: ele decide o que pode sair, com que identidade e sob qual política. Quatro capacidades sustentam essa decisão no lab.

05

Infrastructure as Code

Nada no lab é criado pelo portal. Toda a topologia é declarativa, o que garante que o experimento possa ser destruído e reconstruído com o mesmo resultado, requisito básico para qualquer laboratório que queira servir de referência.

.
├── providers.tf
├── environments/
│   └── dev/
│       ├── main.tf
│       ├── variables.tf
│       ├── outputs.tf
│       └── terraform.tfvars.example
├── modules/
│   ├── hub/
│   ├── spoke/
│   └── firewall-policy/
├── scripts/
│   ├── generate_ca_and_import.sh
│   └── test_idps_and_tls.sh
└── kql/
    ├── 01_idps_alerts.kql
    ├── 02_top_fqdns.kql
    ├── 03_denied_vs_allowed.kql
    ├── 04_snat_port_utilization.kql
    └── 05_blocked_applications.kql

06

Políticas hierárquicas

Em ambiente corporativo, o problema raramente é criar a regra. O problema é impedir que ela seja desfeita na próxima sprint por alguém que precisava liberar um acesso às pressas.

A política hierárquica resolve isso pela direção da herança. A política pai define o piso e é aplicada ao firewall de cada hub regional. A política filha herda tudo e só pode acrescentar restrição. Na prática, o time do spoke consegue adicionar uma regra para o domínio específico que aprovou, mas não consegue reabrir a categoria que a fundação bloqueou.

07

Inspeção TLS com CA própria

Inspeção de conteúdo em tráfego cifrado exige participar da negociação. O laboratório gera uma autoridade certificadora raiz e uma intermediária com OpenSSL, empacota em PFX, importa no Key Vault e referencia o segredo na política do firewall.

# Gera CA raiz e intermediária, importa no Key Vault e devolve o SECRET_ID
chmod +x scripts/generate_ca_and_import.sh
./scripts/generate_ca_and_import.sh

# Import direto, quando o PFX já existe
az keyvault certificate import \
  --vault-name kv-lab-fw \
  --name fw-lab-ca \
  --file ca-intermediaria.pfx

O firewall apresenta esse certificado ao cliente, decifra a sessão, aplica a inspeção e reestabelece a conexão com o destino real. A VM de teste recebe a CA no trust store, então o curl e o navegador aceitam a cadeia sem aviso, que é exatamente o comportamento esperado em ambiente corporativo com certificado distribuído.

08

Validação de IDPS

A bateria de testes roda dentro da VM do spoke, com o NSG permissivo e sem IP público, o que elimina qualquer rota de fuga. O script automatiza a sequência e registra o resultado de cada requisição.

# Bateria completa de IDPS e TLS, executada dentro da VM
bash scripts/test_idps_and_tls.sh

# Domínio não autorizado pela política: espera-se reset de conexão
curl -v https://exemplo-nao-autorizado.com

# Amostra EICAR: espera-se bloqueio por assinatura de IDPS
curl -O https://secure.eicar.org/eicar.com.txt

O teste mais didático é o do arquivo EICAR, amostra padronizada usada para validar detecção antivírus. O NSG não tem como reconhecer aquilo como ameaça, porque não inspeciona conteúdo. O firewall reconhece pela assinatura e encerra a conexão.

09

Auditoria com KQL

Bloquear sem registrar resolve metade do problema. As cinco consultas do repositório cobrem o ciclo de auditoria do egress e foram escritas para rodar direto no Log Analytics provisionado pelo lab.

10

Custos e ciclo de vida

Firewall Premium é caro para estudo, e esconder isso seria desonesto. O SKU Premium fica na faixa de USD 1,50 a USD 2,00 por hora, somando firewall, IP público Standard e processamento de dados. Uma sessão de uma a duas horas fica abaixo de USD 5,00.

cd environments/dev
terraform destroy -auto-approve

# Alternativa direta por resource group
az group delete --name rg-lab-firewall-hub --yes --no-wait
az group delete --name rg-lab-firewall-spoke --yes --no-wait

11

Tecnologias

12

Projeto no GitHub

O laboratório completo está público, com os módulos Terraform, os scripts de geração de CA e teste de IDPS, as consultas KQL e o passo a passo de deploy e destruição.