Hub-and-Spoke no Azure com inspeção centralizada por FortiGate NGFW
Estudo de caso técnico sobre uma topologia com hub dedicado, spokes isolados por subscription e todo o tráfego leste-oeste e norte-sul forçado a passar por um cluster FortiGate em alta disponibilidade Active/Passive.
Visão geral da topologia
A arquitetura adota o padrão hub-and-spoke com separação clara entre plano de rede e plano de carga. O hub concentra serviços de segurança e conectividade, enquanto os spokes de produção e não-produção ficam em subscriptions independentes.
O objetivo principal foi garantir inspeção centralizada e previsibilidade de tráfego, evitando qualquer comunicação direta entre spokes fora do firewall.
Desenho lógico
- Hub dedicado para NGFW, VPN e management out-of-band.
- Spoke de produção e spoke de não-produção com peering apenas com o hub.
- Sem peering direto entre spokes.
- Roteamento forçado por UDR para inspeção no FortiGate.
- Estados Terraform separados por ambiente para reduzir blast radius.
Plano de endereçamento
Os ambientes usam um supernet único 10.45.64.0/20 para simplificar sumarização em rotas e políticas:
- Produção:
10.45.64.0/22 - Não-produção:
10.45.68.0/22 - Hub de rede:
10.45.72.0/23 - Reserva de expansão:
10.45.74.0/23
No hub, as subnets foram segmentadas por função (outside, inside-prod, inside-nonprod, HA, VPN, transit e management), permitindo políticas por interface e telemetria mais precisa.
Alta disponibilidade no FortiGate
O cluster foi implementado no modelo Active/Passive com 2 VMs FortiGate em Availability Set, cobrindo fault domains e update domains para reduzir indisponibilidade por falha de host ou manutenção da plataforma.
- 7 NICs por VM para separar WAN, LANs, HA, VPN, transit e management.
- IP forwarding habilitado em todas as NICs.
- Managed Identity + role Network Contributor para failover automático de PIPs.
- SDN Connector no FortiOS para realocação dos IPs públicos de WAN e VPN.
Os IPs de management permanecem fixos por nó para acesso administrativo previsível, enquanto WAN/VPN fazem failover com troca automática de ancoragem.
Como a inspeção é forçada
Peering sozinho não resolve o requisito de inspeção. O desenho combina:
- Peering bidirecional apenas entre hub e cada spoke.
allow_forwarded_traffic = truepara permitir trânsito encaminhado pelo hub.- Route Tables com rotas privadas e default apontando para o FortiGate.
Assim, mesmo tráfego entre spoke-prod e spoke-nonprod é redirecionado ao firewall, sem fast-path direto entre os ambientes.
Defesa em camadas
- Boundary de internet apenas no hub, com spokes sem Public IP.
- Subscriptions separadas para Hub, Produção e Não-Produção.
- NSGs por subnet como proteção de fallback.
- Acesso administrativo sem exposição direta (VPN/Bastion).
- State Terraform remoto com versionamento, soft-delete e TLS 1.2+.
Trade-offs de design
As principais decisões equilibram segurança, operação e custo:
- Estados Terraform separados: menor risco em alterações destrutivas, com maior esforço de coordenação entre ambientes.
- SKU maior no firewall: necessário por conta do número de NICs, com impacto direto no custo.
- Sem gateway transit nativo: VPN termina no FortiGate, simplificando a governança do perímetro.
- Management como NIC primária: melhora OOB e previsibilidade operacional.
Conclusão
Hub-and-spoke com UDR + NGFW de terceiros continua sendo um padrão sólido no Azure quando o requisito é inspeção L7 centralizada entre ambientes. O ponto crítico é combinar corretamente peering, rotas e permissões de failover para garantir segurança sem comprometer a operabilidade.
Com isolamento por subscription e separação entre rede e cargas, a plataforma fica mais segura por padrão e mais simples de evoluir ao longo do tempo.