Segurança Azure Virtual WAN com Firewall

Segurança Azure Virtual WAN com Firewall

Segurança Azure Virtual WAN com Firewall

Neste tutorial você aprenderá a implementar segurança no Azure Virtual WAN com Firewall e Routing Intent. Vamos conectar VNets spoke ao Virtual Hub e implantar o Azure Firewall no hub (Secured Virtual Hub). Por fim, habilitaremos o Routing Intent para forçar todo o tráfego por inspeção centralizada. Este é o Artigo 5 (final) da série Azure Virtual WAN.

Esses pré-requisitos garantem que a segurança Azure Virtual WAN com Firewall seja aplicada a todo o tráfego da rede.

Pré-requisitos

  • Virtual WAN Standard, Virtual Hub e VPN Gateway provisionados (Artigo 3 e Artigo 4)
  • Virtual Hub com routingState: Provisioned
  • VNet spoke criada ou existente para conectar ao hub
  • Subscription com quota suficiente para Azure Firewall Premium

As variáveis de ambiente são essenciais para automatizar a segurança Azure Virtual WAN com Firewall de forma consistente.

Variáveis de Ambiente

# ── Herdadas dos artigos anteriores ──────────────────────────────────────────
RESOURCE_GROUP="rg-vwan-castilho"
VWAN_NAME="vwan-castilho"
HUB_NAME="vhub-castilho-eastus"
LOCATION="eastus"

# ── VNet Spoke ────────────────────────────────────────────────────────────────
VNET_NAME="vnet-spoke-castilho"
VNET_ADDRESS_PREFIX="10.10.0.0/16"
VNET_CONNECTION_NAME="conn-vnet-spoke-castilho"

# ── Azure Firewall ────────────────────────────────────────────────────────────
FIREWALL_POLICY_NAME="fw-policy-castilho"
FIREWALL_NAME="fw-castilho"

# ── Routing Intent ────────────────────────────────────────────────────────────
ROUTING_INTENT_NAME="routing-intent-castilho"

Conectar as VNets ao hub é o primeiro passo para que a segurança Azure Virtual WAN com Firewall seja aplicada a todo o tráfego spoke.

Passo 1 — Conectar VNets ao Virtual Hub

Em primeiro lugar, a Hub VNet Connection cria automaticamente um peering entre o Virtual Hub e a VNet spoke. Como resultado, as VMs passarão a rotear o tráfego para filiais e outras VNets através do hub. Não é necessário configurar UDRs manualmente.

# Criar a VNet spoke
az network vnet create \
  --name "$VNET_NAME" \
  --resource-group "$RESOURCE_GROUP" \
  --location "$LOCATION" \
  --address-prefixes "$VNET_ADDRESS_PREFIX" \
  --tags projeto="vwan-castilho" ambiente="producao"

# Criar subnet de workload
az network vnet subnet create \
  --name "snet-workload" \
  --resource-group "$RESOURCE_GROUP" \
  --vnet-name "$VNET_NAME" \
  --address-prefixes "10.10.1.0/24"

# Capturar o ID da VNet
VNET_ID=$(az network vnet show \
  --name "$VNET_NAME" \
  --resource-group "$RESOURCE_GROUP" \
  --query id -o tsv)

# Conectar a VNet ao Virtual Hub
az network vhub connection create \
  --name "$VNET_CONNECTION_NAME" \
  --resource-group "$RESOURCE_GROUP" \
  --vhub-name "$HUB_NAME" \
  --remote-vnet "$VNET_ID"

# Verificar conexão
az network vhub connection show \
  --name "$VNET_CONNECTION_NAME" \
  --resource-group "$RESOURCE_GROUP" \
  --vhub-name "$HUB_NAME" \
  --query "{nome:name, status:provisioningState, vnet:remoteVnet.id}" \
  -o table
✅ Output esperado:
# VNet criada
Nome                  Local   Status
--------------------  ------  ---------
vnet-spoke-castilho   eastus  Succeeded

# Subnet snet-workload: 10.10.1.0/24 | Succeeded

# Conexão ao hub
Nome                      Status
------------------------  ---------
conn-vnet-spoke-castilho  Succeeded

A conexão cria automaticamente o peering entre o hub e a VNet — confirme com allowHubToRemoteVnetTransit: true e enableInternetSecurity: true no output JSON da conexão.

Conectar múltiplas VNets

# Listar todas as conexões de VNet do hub
az network vhub connection list \
  --resource-group "$RESOURCE_GROUP" \
  --vhub-name "$HUB_NAME" \
  --query "[].{Nome:name, Status:provisioningState, VNet:remoteVnet.id}" \
  -o table

Passo 2 — Criar a Azure Firewall Policy

Em seguida, a Firewall Policy centraliza todas as regras do Azure Firewall e pode ser reutilizada em múltiplos firewalls. Além disso, use o tier Premium para ter acesso a IDPS (Intrusion Detection and Prevention) e inspeção TLS.

az network firewall policy create \
  --name "$FIREWALL_POLICY_NAME" \
  --resource-group "$RESOURCE_GROUP" \
  --location "$LOCATION" \
  --sku Premium \
  --threat-intel-mode Alert \
  --tags projeto="vwan-castilho" ambiente="producao"

echo "Firewall Policy criada: $FIREWALL_POLICY_NAME"
✅ Output esperado:
Nome                Status     Sku      ThreatIntel
------------------  ---------  -------  -------------
fw-policy-castilho  Succeeded  Premium  Alert

Firewall Policy criada: fw-policy-castilho
TierRecursoRecomendado
para
Standard L3-L7 filtering, Threat Intel, FQDN Ambientes com requisitos básicos
Premium Standard + IDPS + TLS Inspection + URL filtering Ambientes regulados, Zero Trust

Passo 3 — Implantar o Azure Firewall no Hub

Portanto, o Azure Firewall no Virtual Hub usa o SKU AZFW_Hub. Esse SKU é diferente do AZFW_VNet usado em topologias tradicionais. O provisionamento leva aproximadamente 10 a 20 minutos.

az network firewall create \
  --name "$FIREWALL_NAME" \
  --resource-group "$RESOURCE_GROUP" \
  --location "$LOCATION" \
  --vhub "$HUB_NAME" \
  --sku AZFW_Hub \
  --tier Premium \
  --firewall-policy "$FIREWALL_POLICY_NAME" \
  --public-ip-count 1 \
  --tags projeto="vwan-castilho" ambiente="producao"

# Capturar o ID do Firewall
FIREWALL_ID=$(az network firewall show \
  --name "$FIREWALL_NAME" \
  --resource-group "$RESOURCE_GROUP" \
  --query id -o tsv)

echo "Azure Firewall ID: $FIREWALL_ID"

# Monitorar provisionamento
az network firewall show \
  --name "$FIREWALL_NAME" \
  --resource-group "$RESOURCE_GROUP" \
  --query "{nome:name, status:provisioningState, ip:hubIpAddresses.publicIPs.addresses[0].address}" \
  -o table
✅ Output real — deploy de laboratório (subscription castilho, eastus):
{
  "nome": "fw-castilho",
  "status": "Succeeded",
  "sku": "AZFW_Hub",
  "tier": "Premium",
  "hubIpAddresses": {
    "privateIPAddress": "10.0.0.132",
    "publicIPs": {
      "addresses": [{ "address": "<fw-public-ip>" }],
      "count": 1
    }
  }
}

Azure Firewall ID: /subscriptions/<sub-id>/resourceGroups/rg-vwan-castilho/providers/Microsoft.Network/azureFirewalls/fw-castilho

O IP privado (10.0.0.132) é o next-hop configurado automaticamente nas rotas do hub. Isso ocorre após habilitar o Routing Intent. O IP público (<fw-public-ip>) é usado para saída de tráfego de Internet (SNAT).

⚠️ Custo: O Azure Firewall Premium gera cobrança por hora de existência (~$2,50/hora) mais por GB processado. Em laboratório, exclua o recurso após os testes para evitar cobranças.

Passo 4 — Configurar o Routing Intent

Por fim, o Routing Intent instrui o Virtual Hub a enviar todo o tráfego pelo Azure Firewall. Isso inclui tráfego privado (VNet-to-VNet, VNet-to-Branch) e de Internet. Dessa forma, ele é a peça central do modelo Zero Trust no Virtual WAN.

# Habilitar Routing Intent para tráfego privado e Internet
az network vhub routing-intent create \
  --name "$ROUTING_INTENT_NAME" \
  --resource-group "$RESOURCE_GROUP" \
  --vhub "$HUB_NAME" \
  --routing-policies \
    name=PrivateTrafficPolicy,destinations=PrivateTraffic,nexthop="$FIREWALL_ID" \
    name=InternetTrafficPolicy,destinations=Internet,nexthop="$FIREWALL_ID"

# Verificar
az network vhub routing-intent show \
  --name "$ROUTING_INTENT_NAME" \
  --resource-group "$RESOURCE_GROUP" \
  --vhub "$HUB_NAME" \
  --query "{nome:name, status:provisioningState, politicas:routingPolicies}" \
  -o json
✅ Output real — Routing Intent no deploy de laboratório:
{
  "nome": "routing-intent-castilho",
  "status": "Succeeded",
  "politicas": [
    {
      "nome": "PrivateTrafficPolicy",
      "destinos": ["PrivateTraffic"],
      "nexthop": ".../azureFirewalls/fw-castilho"
    },
    {
      "nome": "InternetTrafficPolicy",
      "destinos": ["Internet"],
      "nexthop": ".../azureFirewalls/fw-castilho"
    }
  ]
}

Ambas as políticas apontam para fw-castilho. A partir de agora, todo o tráfego que atravessa o hub passa pelo Firewall. A inspeção é obrigatória para tráfego privado e de Internet.

⚠️ Atenção crítica: Ao habilitar o Routing Intent, todo o tráfego passa pelo Firewall imediatamente. Se as regras não estiverem configuradas, o tráfego será bloqueado por padrão (deny-all implícito). Configure as regras do Passo 5 antes de habilitar em produção.

Passo 5 — Criar Regras no Firewall

5.1 — Rule Collection Group

# Criar Rule Collection Group
az network firewall policy rule-collection-group create \
  --name "rcg-vwan-castilho" \
  --resource-group "$RESOURCE_GROUP" \
  --policy-name "$FIREWALL_POLICY_NAME" \
  --priority 100

5.2 — Regra para permitir tráfego VNet-to-Branch

# Permitir tráfego entre VNets e filiais
az network firewall policy rule-collection-group collection add-filter-collection \
  --name "allow-vnet-to-branch" \
  --resource-group "$RESOURCE_GROUP" \
  --policy-name "$FIREWALL_POLICY_NAME" \
  --rule-collection-group-name "rcg-vwan-castilho" \
  --action Allow \
  --priority 100 \
  --rule-name "allow-internal-traffic" \
  --rule-type NetworkRule \
  --source-addresses "10.0.0.0/8" "192.168.0.0/16" \
  --destination-addresses "10.0.0.0/8" "192.168.0.0/16" \
  --ip-protocols Any \
  --destination-ports "*"

5.3 — Regra para acesso à Internet (FQDN)

# Permitir acesso a domínios específicos na Internet
az network firewall policy rule-collection-group collection add-filter-collection \
  --name "allow-internet-fqdn" \
  --resource-group "$RESOURCE_GROUP" \
  --policy-name "$FIREWALL_POLICY_NAME" \
  --rule-collection-group-name "rcg-vwan-castilho" \
  --action Allow \
  --priority 200 \
  --rule-name "allow-windows-update" \
  --rule-type ApplicationRule \
  --source-addresses "10.0.0.0/8" \
  --protocols "Https=443" \
  --target-fqdns \
    "*.microsoft.com" \
    "*.windows.com" \
    "*.windowsupdate.com"

Ao verificar os logs, você confirma que a segurança Azure Virtual WAN com Firewall está inspecionando o tráfego conforme esperado.

Verificar a Configuração Completa

# Resumo completo do Virtual WAN
az network vwan show \
  --name "$VWAN_NAME" \
  --resource-group "$RESOURCE_GROUP" \
  --query "{nome:name, tipo:type, status:provisioningState}" -o table

# Estado do hub e roteamento
az network vhub show \
  --name "$HUB_NAME" \
  --resource-group "$RESOURCE_GROUP" \
  --query "{nome:name, status:provisioningState, roteamento:routingState}" -o table

# Conexões de VNet
az network vhub connection list \
  --resource-group "$RESOURCE_GROUP" \
  --vhub-name "$HUB_NAME" \
  --query "[].{Nome:name, Status:provisioningState}" -o table

# Estado do Routing Intent
az network vhub routing-intent show \
  --name "$ROUTING_INTENT_NAME" \
  --resource-group "$RESOURCE_GROUP" \
  --vhub "$HUB_NAME" \
  --query "{status:provisioningState, politicas:routingPolicies[].name}" -o json

# Rotas efetivas do hub (verifica se o firewall está no caminho)
az network vhub get-effective-routes \
  --resource-group "$RESOURCE_GROUP" \
  --name "$HUB_NAME" \
  --resource-type RouteTable \
  --resource-id "$(az network vhub route-table show \
    --name "defaultRouteTable" \
    --resource-group "$RESOURCE_GROUP" \
    --vhub-name "$HUB_NAME" \
    --query id -o tsv)"
✅ Output real — rotas efetivas do hub após Routing Intent (deploy de laboratório):
[
  { "addressPrefixes": ["0.0.0.0/0"],      "nextHopType": "Azure Firewall", "nextHops": ["...fw-castilho"] },
  { "addressPrefixes": ["10.0.0.0/8"],     "nextHopType": "Azure Firewall", "nextHops": ["...fw-castilho"] },
  { "addressPrefixes": ["172.16.0.0/12"],  "nextHopType": "Azure Firewall", "nextHops": ["...fw-castilho"] },
  { "addressPrefixes": ["192.168.0.0/16"], "nextHopType": "Azure Firewall", "nextHops": ["...fw-castilho"] }
]

Todas as rotas — Internet (0.0.0.0/0), RFC1918 privadas (10.x, 172.16.x, 192.168.x) — têm nextHopType: "Azure Firewall" apontando para fw-castilho (IP privado 10.0.0.132). Isso confirma que o Routing Intent está ativo e todo o tráfego passa pelo Firewall para inspeção.

Limpeza dos Recursos

Portanto, remova os recursos na ordem abaixo para evitar erros de dependência. A exclusão completa pode levar até 60 minutos.

# 1. Remover Routing Intent
az network vhub routing-intent delete \
  --name "$ROUTING_INTENT_NAME" \
  --resource-group "$RESOURCE_GROUP" \
  --vhub "$HUB_NAME" --yes

# 2. Remover Azure Firewall
az network firewall delete \
  --name "$FIREWALL_NAME" \
  --resource-group "$RESOURCE_GROUP"

# 3. Remover conexões de VNet
az network vhub connection delete \
  --name "$VNET_CONNECTION_NAME" \
  --resource-group "$RESOURCE_GROUP" \
  --vhub-name "$HUB_NAME" --yes

# 4. Remover o Resource Group completo (inclui todos os recursos restantes)
# ATENÇÃO: Este comando é irreversível!
az group delete \
  --name "$RESOURCE_GROUP" \
  --yes \
  --no-wait

echo "Limpeza iniciada para o Resource Group: $RESOURCE_GROUP"

Troubleshooting

ProblemaCausa provávelSolução
Tráfego bloqueado após Routing Intent Regra de firewall ausente Adicionar regra Allow na Firewall Policy antes de habilitar o Routing Intent
RoutingIntentConflict UDRs manuais nas VNets spoke conflitam com o hub Remover User Defined Routes das VNets spoke — o Routing Intent gerencia as rotas automaticamente
FirewallNotInHub Firewall criado com AZFW_VNet em vez de AZFW_Hub Recriar o Firewall usando --sku AZFW_Hub --vhub
VNet não recebe rotas do hub Hub VNet Connection não propagada Verificar provisioningState: Succeeded na conexão e aguardar propagação BGP (~5 min)
Custo inesperado Hub ou Firewall não excluídos após testes Sempre executar o passo de limpeza ou criar alertas de custo no Azure Cost Management

Você concluiu a implementação de segurança Azure Virtual WAN com Firewall e Routing Intent em toda a sua rede global.

Conclusão da Série

Em resumo, você concluiu a série completa sobre Azure Virtual WAN. Ao longo dos 5 artigos, você aprendeu a:

  1. Entender a arquitetura e os componentes do Azure Virtual WAN
  2. Criar o Virtual WAN Standard e o Virtual Hub regional
  3. Provisionar o VPN Gateway, registrar filiais e estabelecer túneis IPsec/IKEv2
  4. Conectar VNets spoke ao hub, implantar o Azure Firewall Premium e habilitar o Routing Intent para inspeção centralizada

Dessa forma, sua organização tem uma WAN global gerenciada pelo Azure, com segurança centralizada via Azure Firewall. O roteamento automático entre regiões usa a backbone da Microsoft. Além disso, a plataforma escala para milhares de filiais em uma única interface.


Série completa:

  1. 📖 Artigo 1: O que é Azure Virtual WAN — conceitos e arquitetura
  2. ⚙️ Artigo 2: Configurar o Azure Virtual WAN
  3. 🔧 Artigo 3: Criar o Azure Virtual WAN
  4. 🔌 Artigo 4: Conectar Filiais ao Azure Virtual WAN com VPN
  5. 🔒 Artigo 5 (este): Segurança Azure Virtual WAN com Firewall

Referências oficiais:
Políticas de roteamento do Virtual Hub — Microsoft Learn
Secured Virtual Hub (Azure Firewall Manager) — Microsoft Learn
Instalar Azure Firewall em Virtual Hub — Microsoft Learn
Referência AZ CLI — az network vhub

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

🚀 Vamos nos conectar?

Não perca nenhuma oportunidade! Cadastre-se nas minhas redes e no canal do YouTube para receber conteúdos de TI, Cloud, Azure, Kubernetes e DevOps em primeira mão.

Dica: No Facebook, todos os artigos do blog são publicados automaticamente. Vale a pena curtir!


💬 Dúvidas ou Problemas?

Com o intuito de ajudar a comunidade, caso você tenha dúvidas ou encontre problemas na execução dos comandos deste artigo, deixe um comentário abaixo. Responderei o mais breve possível!

Muito obrigado pela visita e até o próximo post!

Jefferson Castilho Especialista em Cloud & DevOps.

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

 

Deixe uma resposta

Rolar para cima