Pular para o conteúdo principal

Laboratório Técnico: Create a secure hub by deploying Azure Firewall inside an Azure Virtual WAN hub

Questões​

Questão 1 — Múltipla Escolha​

Ao converter um hub padrão do Azure Virtual WAN em um secured virtual hub, qual é o componente que é implantado automaticamente dentro do hub e passa a gerenciar o tráfego entre as conexões?

A) Um Network Virtual Appliance (NVA) de terceiros registrado no hub
B) O Azure Firewall, provisionado diretamente no espaço de endereçamento do hub
C) Um Azure Application Gateway com WAF habilitado na sub-rede do hub
D) Um Route Server dedicado que inspeciona pacotes antes de encaminhá-los

Questão 2 — Cenário Técnico​

Uma equipe configurou um secured virtual hub com Azure Firewall e definiu políticas de roteamento no Azure Firewall Manager. Após a configuração, o tráfego entre dois spoke VNets conectados ao mesmo hub continua sendo encaminhado diretamente entre eles, sem passar pelo firewall.

Spoke-A (10.1.0.0/16) <--> Hub (10.0.0.0/23) <--> Spoke-B (10.2.0.0/16)
Tráfego observado: Spoke-A -> Spoke-B (direto, sem inspeção)

Qual é a causa mais provável desse comportamento?

A) O Azure Firewall não suporta inspeção de tráfego leste-oeste entre spoke VNets no Virtual WAN
B) A opção de Private Traffic nas configurações de roteamento do hub não foi habilitada para enviar tráfego inter-spoke pelo firewall
C) As VNets spoke estão usando peering direto entre si, contornando o hub
D) O Firewall Policy associado ao hub está no modo Alert e não no modo Deny, permitindo passagem sem redirecionamento

Questão 3 — Verdadeiro ou Falso​

Um secured virtual hub do Azure Virtual WAN com Azure Firewall permite que o administrador escolha livremente o prefixo de endereço IP atribuído ao hub após a sua criação, bastando editar as configurações de rede do hub no portal.

Questão 4 — Cenário Técnico​

Uma empresa possui dois secured virtual hubs em regiões diferentes (Hub-Leste e Hub-Oeste), ambos conectados por meio de uma WAN virtual do tipo Standard. O time de segurança exige que o tráfego entre as duas regiões também seja inspecionado pelo firewall. Após revisar a configuração, o arquiteto percebe que o tráfego inter-hub está sendo roteado diretamente, sem inspeção.

Qual ajuste resolve esse cenário?

A) Criar um emparelhamento de VNet global entre os hubs para forçar o tráfego pelo firewall
B) Habilitar a opção de inspeção de tráfego Inter-hub dentro das configurações de roteamento do Azure Firewall Manager para cada hub
C) Substituir os hubs padrão por hubs com NVAs de terceiros, pois o Azure Firewall não suporta inspeção de tráfego entre hubs
D) Adicionar rotas estáticas nas tabelas de rotas dos hubs apontando para o IP privado do firewall do hub remoto

Questão 5 — Múltipla Escolha​

Ao implantar um Azure Firewall em um secured virtual hub, qual ferramenta é a abordagem recomendada pela Microsoft para gerenciar centralmente as políticas de segurança aplicadas a múltiplos hubs?

A) Azure Policy com iniciativas de conformidade aplicadas ao escopo da WAN virtual
B) Azure Firewall Manager, que permite associar uma Firewall Policy hierárquica aos hubs
C) Microsoft Defender for Cloud com planos do Defender for Servers habilitados nos hubs
D) Grupos de segurança de rede (NSGs) aplicados às interfaces do firewall dentro do hub

Gabarito e Explicações​

Gabarito — Questão 1​

Resposta: B

Ao habilitar a segurança em um hub do Virtual WAN, o Azure provisiona o Azure Firewall diretamente dentro do espaço de endereçamento do próprio hub, transformando-o em um secured virtual hub. Isso é distinto de um hub padrão, onde nenhum appliance de segurança nativo é implantado automaticamente.

  • A alternativa A é plausível porque NVAs de terceiros podem ser integrados ao Virtual WAN, mas esse processo não é automático nem configura o hub como "secured" no sentido formal do produto.
  • As alternativas C e D descrevem componentes que não fazem parte da arquitetura de secured virtual hub: o Application Gateway opera em camada 7 para workloads web específicas, e o Route Server é um serviço separado para troca de rotas BGP.

Escolher C ou D levaria a uma arquitetura sem inspeção centralizada de tráfego no hub, que é exatamente o objetivo de um secured virtual hub.

Gabarito — Questão 2​

Resposta: B

No Azure Firewall Manager, o roteamento de tráfego privado (leste-oeste entre spokes e branch-to-branch) é controlado pela configuração Private Traffic dentro das opções de Security Configuration do hub. Se essa opção não estiver habilitada para encaminhar o tráfego pelo Azure Firewall, as rotas geradas automaticamente pelo hub continuarão direcionando o tráfego de forma direta entre os spokes.

  • A alternativa A é incorreta: o Azure Firewall em secured virtual hub suporta explicitamente inspeção leste-oeste entre spokes.
  • A alternativa C é um equívoco comum, mas spoke VNets conectadas ao Virtual WAN não estabelecem peering direto entre si por padrão; o hub é sempre o ponto de trânsito.
  • A alternativa D confunde o comportamento de políticas de firewall (regras de Allow/Deny) com a configuração de roteamento. Mesmo no modo Alert, as rotas precisariam estar direcionando o tráfego para o firewall, o que não ocorre se o roteamento privado não estiver configurado.

Gabarito — Questão 3​

Resposta: Falso

O espaço de endereçamento de um hub do Azure Virtual WAN é imutável após a criação. O prefixo deve ser definido no momento do provisionamento do hub e não pode ser editado posteriormente. Isso é uma restrição fundamental da arquitetura do Virtual WAN, independentemente de o hub ser padrão ou secured.

Essa limitação tem consequência direta no planejamento: um erro no dimensionamento do prefixo exige a exclusão e recriação do hub, o que implica reconfigurar todas as conexões associadas. O comportamento é diferente do que ocorre em VNets comuns, onde é possível adicionar espaços de endereçamento após a criação, o que induz o equívoco.

Gabarito — Questão 4​

Resposta: B

O Azure Firewall Manager oferece uma opção específica de inspeção para tráfego inter-hub (entre regiões, via WAN virtual Standard). Essa configuração precisa ser habilitada explicitamente em cada hub para que o tráfego que transita entre hubs seja redirecionado ao firewall local antes de seguir para o hub remoto.

  • A alternativa A é incorreta porque peering global entre hubs não é uma funcionalidade do Virtual WAN; os hubs se comunicam pelo backbone da WAN, não por peerings de VNet.
  • A alternativa C é um distrator plausível, mas tecnicamente incorreta: o Azure Firewall suporta o cenário inter-hub em WANs Standard.
  • A alternativa D poderia funcionar em um cenário de VNet tradicional com tabelas de rotas manuais, mas no Virtual WAN o gerenciamento de rotas inter-hub é feito pelo Firewall Manager, e rotas estáticas apontando para IPs privados de hubs remotos não são um mecanismo suportado para esse fim.

Gabarito — Questão 5​

Resposta: B

O Azure Firewall Manager é a ferramenta nativa projetada exatamente para gerenciamento centralizado de segurança em secured virtual hubs. Ele permite criar e associar Firewall Policies com hierarquia (política base e políticas filhas), aplicar configurações a múltiplos hubs simultaneamente e visualizar o estado de segurança da WAN de forma consolidada.

  • A alternativa A confunde Azure Policy (governança e conformidade de recursos no Azure) com gerenciamento operacional de regras de firewall.
  • A alternativa C descreve uma ferramenta de postura de segurança e proteção de workloads, sem capacidade de gerenciar regras de tráfego de rede no firewall.
  • A alternativa D é tecnicamente incorreta para o contexto de secured virtual hub: o Azure Firewall dentro do hub não expõe interfaces de rede acessíveis a NSGs, pois opera de forma integrada ao plano de roteamento do hub, não como uma VM com NICs convencionais.