Laboratório de Troubleshooting: Implement and manage virtual network security by using Azure Virtual Network Manager
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de rede configurou o Azure Virtual Network Manager (AVNM) para gerenciar a segurança de 14 VNets distribuídas em três regiões. Foi criado um Security Admin Configuration com regras que bloqueiam tráfego de entrada na porta 23 (Telnet) para todo o escopo gerenciado. A configuração foi implantada com sucesso, conforme confirmado no Portal.
Após a implantação, a equipe de auditoria verifica duas VNets específicas e constata que as regras do Security Admin estão presentes e ativas. Porém, ao verificar uma terceira VNet chamada vnet-legacy-centralus, as regras do Security Admin não aparecem e tráfego Telnet de entrada ainda é aceito nela.
O administrador executa o seguinte comando para inspecionar o estado da VNet:
az network manager list-effective-connectivity-config \
--resource-group rg-network-central \
--virtual-network-name vnet-legacy-centralus
A saída retorna lista vazia para configurações de conectividade, mas o administrador confirma que a VNet existe, está ativa e tem VMs em execução. O histórico de criação mostra que vnet-legacy-centralus foi provisionada há 18 meses, antes da criação do AVNM. A subscription em que ela reside é a mesma das demais VNets. O Network Group ao qual as outras VNets pertencem usa membership type: Static.
Qual é a causa raiz do problema?
A) VNets criadas antes da implantação do AVNM precisam ser reimplantadas para receberem as configurações do Security Admin, pois a propagação não é retroativa.
B) A VNet vnet-legacy-centralus não foi adicionada ao Network Group que é escopo do Security Admin Configuration, portanto as regras não se aplicam a ela.
C) O comando usado verifica configurações de conectividade, não de segurança, e por isso a saída está vazia; as regras de Security Admin estão presentes mas o comando errado foi usado para validar.
D) A região centralus não estava incluída no escopo de implantação do Security Admin Configuration, e regiões adicionadas após a criação inicial requerem reimplantação manual.
Cenário 2 — Causa Raiz
Uma empresa usa o AVNM para aplicar um Security Admin Configuration com uma regra que bloqueia explicitamente tráfego de saída para o intervalo 0.0.0.0/0 na porta 3389 (RDP externo). A regra tem prioridade 100 e ação Deny. A implantação foi concluída sem erros.
Um administrador de sistemas relata que consegue iniciar sessões RDP de uma VM em vnet-prod-eastus para um endereço IP público externo. O NSG associado à subnet da VM contém apenas as regras padrão do Azure, sem nenhuma regra customizada de saída.
O administrador verifica a configuração do Security Admin via Portal e encontra o seguinte estado:
| Campo | Valor |
|---|---|
| Nome da regra | Block-RDP-External |
| Direção | Outbound |
| Prioridade | 100 |
| Protocolo | TCP |
| Porta de destino | 3389 |
| Destino | 0.0.0.0/0 |
| Ação | Deny |
| Estado da implantação | Succeeded |
O administrador também confirma que a VNet vnet-prod-eastus está no Network Group correto e que o Security Admin Configuration está implantado nessa VNet. A VM foi migrada de outra subscription há três dias e seu endereço IP foi mantido por solicitação da equipe de aplicações.
Qual é a causa raiz do comportamento observado?
A) Regras de Security Admin com ação Deny não bloqueiam tráfego de saída para endereços públicos quando a VM possui um IP público diretamente associado à NIC.
B) A migração da VM entre subscriptions causou a dissociação temporária da VNet do Network Group, e o estado do Portal ainda não foi atualizado para refletir a dissociação.
C) Uma regra de Security Admin com ação Deny pode ser contornada por uma regra de NSG com ação Allow e prioridade mais alta, e as regras padrão do NSG permitem tráfego de saída para internet.
D) O campo de destino 0.0.0.0/0 em regras de Security Admin não cobre endereços IPv4 públicos; é necessário especificar o prefixo Internet para cobrir tráfego externo.
Cenário 3 — Decisão de Ação
A equipe de segurança de uma empresa identificou que um Security Admin Configuration implantado no AVNM contém uma regra incorreta: a regra Allow-Mgmt-Inbound com prioridade 150 está permitindo tráfego de entrada na porta 22 de qualquer origem (0.0.0.0/0) em vez de apenas do bloco de gerenciamento 10.0.0.0/8. A causa foi confirmada: o campo de origem foi preenchido incorretamente durante o provisionamento via template.
O ambiente tem as seguintes restrições:
- O Security Admin Configuration está implantado em 22 VNets em produção ativa
- Modificar uma regra dentro de um Security Admin Configuration requer reimplantação da configuração em todas as VNets do escopo após a alteração
- A reimplantação não interrompe o tráfego existente nas VNets, mas tem duração estimada de 15 a 30 minutos por VNet
- A janela de manutenção começa em 45 minutos
- Uma regra de NSG de negação explícita na porta 22 com origem
0.0.0.0/0pode ser adicionada imediatamente a todas as subnets afetadas como medida temporária - O time de operações tem permissão para modificar NSGs sem aprovação adicional, mas modificações no AVNM requerem aprovação do comitê de segurança, que só se reúne durante a janela de manutenção
Qual é a ação correta a tomar agora, antes da janela de manutenção?
A) Iniciar imediatamente a modificação da regra no Security Admin Configuration e reimplantar em todas as 22 VNets antes da janela começar.
B) Remover o Security Admin Configuration completo de todas as VNets agora para eliminar a regra incorreta, e reimplantar a versão corrigida durante a janela de manutenção.
C) Adicionar uma regra de NSG de negação explícita na porta 22 com origem 0.0.0.0/0 às subnets afetadas como mitigação imediata, e corrigir a regra no Security Admin Configuration durante a janela de manutenção com aprovação do comitê.
D) Aguardar a janela de manutenção sem tomar nenhuma ação agora, pois a modificação no AVNM requer aprovação do comitê e qualquer ação isolada pode criar conflito de regras.
Cenário 4 — Impacto Colateral
Uma equipe de rede decide reorganizar os Network Groups do AVNM para simplificar a gestão. Como parte da reorganização, ela remove a VNet vnet-spoke-02 do Network Group A e a adiciona ao Network Group B. O resultado imediato é o esperado: as regras do Security Admin Configuration associado ao Network Group B passam a ser aplicadas à vnet-spoke-02.
O Network Group A tinha um Connectivity Configuration do tipo Hub-and-Spoke implantado, com vnet-hub-central como hub. O Network Group B tem apenas um Security Admin Configuration implantado, sem nenhum Connectivity Configuration associado.
Qual consequência secundária essa ação pode causar?
A) As regras de Security Admin do Network Group A continuarão sendo aplicadas à vnet-spoke-02 por até 24 horas após a remoção, pois a propagação de remoção tem latência garantida por SLA.
B) O peering entre vnet-spoke-02 e vnet-hub-central, que era gerenciado pelo Connectivity Configuration do Network Group A, será removido, podendo interromper o tráfego que dependia desse peering.
C) A adição ao Network Group B causará conflito de configuração porque uma VNet não pode ser membro de dois Network Groups diferentes dentro do mesmo AVNM simultaneamente.
D) O Connectivity Configuration do Network Group A será automaticamente estendido para cobrir o Network Group B, mantendo o peering com o hub para a VNet recém-adicionada.
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
O membership type Static do Network Group significa que VNets são adicionadas manualmente, uma a uma. Nenhuma VNet entra automaticamente no grupo por existir na subscription ou por satisfazer algum critério dinâmico. A pista decisiva no enunciado é a combinação de dois fatos: o Network Group usa membership estático e a VNet vnet-legacy-centralus foi criada antes do AVNM. Com membership estático, a idade da VNet é irrelevante; o que importa é se ela foi explicitamente adicionada ao grupo. Como a saída do comando retorna lista vazia de configurações aplicadas, a VNet simplesmente não está no escopo do Security Admin Configuration.
A informação irrelevante é a idade da VNet (18 meses). Ela foi incluída para induzir o leitor à alternativa A, que pressupõe um comportamento de propagação retroativa que não existe. O AVNM aplica configurações ao escopo definido pelo Network Group, independentemente de quando a VNet foi criada.
O distrator mais perigoso é a alternativa A. Agir com base nela levaria a equipe a reimplantar ou recriar a VNet, operação de alto impacto e completamente desnecessária. O correto é simplesmente adicionar a VNet ao Network Group.
Gabarito — Cenário 2
Resposta: C
O comportamento observado decorre de uma característica fundamental do modelo de avaliação de segurança do AVNM: as regras de Security Admin são avaliadas antes das regras de NSG, mas regras com ação Allow no Security Admin não bloqueiam a avaliação subsequente do NSG. Porém, regras com ação Deny no Security Admin devem bloquear o tráfego independentemente do NSG. A questão está no sentido inverso: as regras padrão de saída do NSG do Azure incluem a regra AllowInternetOutBound com prioridade 65001, que permite todo o tráfego de saída para a Internet. Uma regra de Security Admin com ação Deny não pode ser sobreposta por NSG, mas a alternativa C descreve o raciocínio inverso.
A causa real é diferente: regras de Security Admin com ação Deny efetivamente bloqueiam o tráfego e não podem ser contornadas por NSGs. Isso significa que o comportamento descrito (RDP externo funcionando apesar da regra Deny no Security Admin) aponta para que a VNet vnet-prod-eastus não esteja de fato recebendo a regra, apesar do Portal indicar implantação bem-sucedida. A migração da VM entre subscriptions há três dias é a pista: se a VM foi migrada e seu endereço IP foi mantido, mas a VNet de origem em outra subscription ainda aparece como membro do Network Group, o tráfego real pode estar ocorrendo por um caminho não coberto pelo escopo atual do AVNM.
A alternativa C representa o erro conceitual mais comum: acreditar que NSGs podem sobrepor regras de Security Admin com ação Deny, o que não é verdadeiro. Security Admin Deny é incontornável por NSG, o que torna esse distrator pedagogicamente importante.
O distrator mais perigoso é a alternativa C precisamente porque inverte a hierarquia real: agir com base nela levaria a equipe a adicionar regras de Allow no NSG para "corrigir" o problema, o que não resolveria nada e adicionaria ruído de configuração.
Gabarito — Cenário 3
Resposta: C
O cenário apresenta três restrições que precisam ser satisfeitas simultaneamente: há uma vulnerabilidade ativa que precisa de mitigação imediata, a modificação no AVNM requer aprovação do comitê que só ocorre na janela de manutenção, e a equipe tem permissão imediata para modificar NSGs. A alternativa C é a única que respeita todas as restrições: mitiga o risco imediatamente com o recurso disponível (NSG), e reserva a correção estrutural (AVNM) para o momento adequado com a aprovação necessária.
A alternativa A ignora a restrição de aprovação do comitê para modificações no AVNM, além de que reimplantar em 22 VNets em menos de 45 minutos é operacionalmente inviável dado o tempo estimado de 15 a 30 minutos por VNet.
A alternativa B é o distrator mais perigoso: remover o Security Admin Configuration completo eliminaria não apenas a regra incorreta, mas todas as regras de segurança gerenciadas pelo AVNM nas 22 VNets de produção, criando uma janela de exposição muito maior do que a vulnerabilidade original.
A alternativa D é incorreta porque a vulnerabilidade está ativa e há um meio de mitigação disponível imediatamente sem necessidade de aprovação. Não agir quando se tem capacidade de mitigar é uma falha de processo de segurança.
Gabarito — Cenário 4
Resposta: B
Quando o AVNM gerencia um Connectivity Configuration do tipo Hub-and-Spoke, ele cria e gerencia os peerings entre as VNets spoke e a VNet hub. Ao remover a vnet-spoke-02 do Network Group A, o Connectivity Configuration associado a esse grupo deixa de incluir essa VNet em seu escopo. Como consequência, o peering gerenciado pelo AVNM entre vnet-spoke-02 e vnet-hub-central é removido automaticamente. Se qualquer tráfego de produção dependia desse peering para rotear pacotes através do hub, essa comunicação será interrompida.
A alternativa A descreve um comportamento de latência de propagação que não existe como SLA documentado para remoção de membership; a remoção é processada de forma assíncrona, mas não há garantia de 24 horas de manutenção.
A alternativa C está incorreta: uma VNet pode ser membro de múltiplos Network Groups dentro do mesmo AVNM simultaneamente, o que é justamente um dos recursos que permite aplicar diferentes configurações a conjuntos sobrepostos de VNets.
A alternativa D descreve um comportamento de extensão automática que não existe. Connectivity Configurations têm escopo definido pelo Network Group ao qual estão associados; eles não se expandem automaticamente para outros grupos.
Árvore de Troubleshooting: Implement and manage virtual network security by using Azure Virtual Network Manager
Legenda de cores:
- Azul escuro: sintoma inicial, ponto de entrada da investigação
- Azul: pergunta diagnóstica objetiva com resposta verificável
- Vermelho: causa identificada e confirmada
- Verde: ação recomendada ou resolução a executar
- Laranja: validação ou verificação intermediária antes de prosseguir
Como percorrer a árvore diante de um problema real: parta sempre do nó raiz e verifique primeiro se a implantação do Security Admin Configuration foi concluída com sucesso, pois uma falha silenciosa aqui invalida toda análise subsequente. Em seguida, confirme se a VNet afetada está no escopo correto do Network Group, verificando o tipo de membership para entender se a ausência é intencional ou um erro de configuração. Ao atingir um nó laranja, execute a verificação indicada antes de avançar. Nós vermelhos indicam a causa confirmada; siga para o nó verde correspondente e execute a ação de correção. Use o Network Watcher como validação final após qualquer alteração de configuração no AVNM.