Laboratório de Troubleshooting: Evaluate Effective Security Rules in NSGs
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
A equipe de operações relata que uma VM chamada vm-app01 parou de receber conexões HTTPS na porta 443 vindas de clientes externos. A VM estava funcionando normalmente até que um colega aplicou uma nova política de segurança na tarde anterior.
O administrador verifica o NSG associado à NIC da VM e encontra a seguinte configuração de regras de entrada:
| Prioridade | Nome | Porta | Origem | Destino | Ação |
|---|---|---|---|---|---|
| 100 | Allow-HTTPS | 443 | Any | Any | Allow |
| 200 | Allow-HTTP | 80 | Any | Any | Allow |
| 65000 | AllowVnetInBound | Any | VirtualNetwork | Any | Allow |
| 65500 | DenyAllInBound | Any | Any | Any | Deny |
O NSG parece correto. O administrador também verifica que o IP público está associado corretamente à NIC e que o serviço dentro da VM está ativo e escutando na porta 443. A VM tem dois discos de dados anexados recentemente, adicionados pelo mesmo colega.
Em seguida, ele executa o IP Flow Verify e obtém:
Direction : Inbound
Protocol : TCP
LocalPort : 443
RemotePort: 52341
LocalIP : 10.0.1.10
RemoteIP : 187.45.32.10
Access : Deny
RuleName : Deny-All-External
NSG : nsg-subnet-frontend
Qual é a causa raiz do bloqueio?
A) A regra DenyAllInBound padrão no NSG da NIC está bloqueando o tráfego porque nenhuma regra de prioridade inferior a 65500 cobre o tráfego externo corretamente.
B) O NSG associado à sub-rede contém uma regra chamada Deny-All-External com prioridade suficiente para bloquear o tráfego antes que o NSG da NIC seja avaliado.
C) Os discos de dados adicionados à VM causaram uma alteração no estado de rede da interface, invalidando as regras do NSG da NIC.
D) O IP Flow Verify está analisando o IP interno da VM, e o resultado não reflete o comportamento real do tráfego externo que chega pelo IP público.
Cenário 2 — Decisão de Ação
A causa de um problema de conectividade foi identificada: uma regra de negação com prioridade 150 foi adicionada ao NSG da sub-rede bloqueando todo o tráfego de saída para o intervalo 10.20.0.0/16, que corresponde à sub-rede de banco de dados em uma VNet emparelhada. A aplicação em vm-app02 não consegue se conectar ao banco de dados desde a última janela de manutenção.
O ambiente possui as seguintes restrições:
- Este NSG está associado a uma sub-rede com 14 outras VMs de produção além de
vm-app02 - O time de segurança que criou a regra está indisponível até o dia seguinte
- Existe uma janela de manutenção programada para daqui a 6 horas
- A aplicação em
vm-app02está com degradação parcial, não completamente fora do ar
Qual é a ação correta a tomar neste momento?
A) Excluir imediatamente a regra de prioridade 150 do NSG da sub-rede para restaurar a conectividade, pois a causa foi confirmada.
B) Modificar a prioridade da regra de 150 para 160, reduzindo sua efetividade enquanto se aguarda o time de segurança.
C) Aguardar a janela de manutenção programada e, antes de qualquer alteração, acionar o time de segurança para validar o impacto nas demais VMs da sub-rede.
D) Criar uma regra de permissão com prioridade 100 no NSG da NIC de vm-app02 para o destino 10.20.0.0/16, contornando a regra de bloqueio da sub-rede sem alterar o NSG compartilhado.
Cenário 3 — Causa Raiz
Um desenvolvedor reporta que consegue acessar via SSH (porta 22) uma VM de desenvolvimento chamada vm-dev03 a partir do seu notebook corporativo (10.50.1.15), mas um segundo desenvolvedor com notebook no mesmo segmento de rede (10.50.1.22) recebe timeout ao tentar o mesmo acesso.
O administrador verifica o NSG da sub-rede onde vm-dev03 está hospedada:
Regras de entrada (NSG da sub-rede):
Prioridade 100 | Allow-SSH-CorpNet | TCP 22 | Origem: 10.50.0.0/16 | Allow
Prioridade 200 | Deny-All | Any | Origem: Any | Deny
O NSG da NIC não possui regras personalizadas além das padrão. O administrador confirma que ambos os notebooks estão no mesmo VLAN corporativo e que nenhuma alteração foi feita no NSG nas últimas 48 horas. Ele também verifica que vm-dev03 foi migrada para um novo host físico pelo time de infraestrutura na manhã do mesmo dia.
Ao executar o IP Flow Verify para o IP 10.50.1.22 na porta 22, o resultado é:
Access : Allow
RuleName : Allow-SSH-CorpNet
NSG : nsg-subnet-dev
Qual é a causa raiz mais provável do timeout relatado pelo segundo desenvolvedor?
A) A migração para novo host físico corrompeu as regras efetivas do NSG associado à NIC, que agora apresenta estado inconsistente.
B) O IP Flow Verify confirma que o NSG permite o tráfego; a causa do timeout está fora do escopo do NSG, possivelmente no sistema operacional da VM, no firewall local ou na aplicação SSH em si.
C) A regra Allow-SSH-CorpNet cobre o bloco 10.50.0.0/16, mas o IP 10.50.1.22 está fora desse intervalo, portanto o tráfego cai na regra Deny-All.
D) O NSG da NIC sem regras personalizadas herda automaticamente uma negação implícita que afeta apenas conexões secundárias à VM, explicando por que o segundo desenvolvedor é bloqueado.
Cenário 4 — Sequência de Diagnóstico
Um administrador recebe o seguinte relato: "A aplicação web em vm-web01 parou de responder na porta 80 para usuários externos. Internamente, a equipe de TI consegue acessar normalmente."
Os passos de investigação disponíveis são:
- Passo P: Verificar se o serviço HTTP está ativo e escutando na porta 80 dentro da VM (
netstatouss). - Passo Q: Executar o IP Flow Verify simulando tráfego de entrada de um IP externo na porta 80 para identificar qual NSG e qual regra está bloqueando.
- Passo R: Revisar as regras efetivas da NIC de
vm-web01para obter a visão consolidada dos NSGs da NIC e da sub-rede. - Passo S: Verificar se há diferença entre as origens permitidas nas regras dos NSGs, comparando o que cobre tráfego interno versus externo.
- Passo T: Confirmar se a resolução do problema foi efetiva tentando acessar a aplicação de um IP externo após qualquer ajuste.
Qual é a sequência de diagnóstico mais lógica?
A) P → R → Q → S → T
B) Q → P → S → R → T
C) R → S → Q → P → T
D) S → Q → R → P → T
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista definitiva está na saída do IP Flow Verify: o campo RuleName aponta para Deny-All-External e o campo NSG aponta para nsg-subnet-frontend, que é o NSG da sub-rede, não o NSG da NIC. Para tráfego de entrada, o NSG da sub-rede é avaliado primeiro. O fato de o NSG da NIC ter uma regra Allow-HTTPS na prioridade 100 é irrelevante porque o pacote nunca chega a ser avaliado por ele.
A informação sobre os dois discos de dados adicionados é propositalmente irrelevante. Discos de dados não têm qualquer efeito sobre regras de NSG ou sobre o comportamento de rede de uma NIC. Incluir esse detalhe testa a capacidade do leitor de ignorar mudanças recentes que não guardam relação técnica com o sintoma.
A alternativa A representa um erro clássico: focar na regra padrão DenyAllInBound do NSG da NIC sem perceber que a saída do IP Flow Verify já indica um NSG e uma regra específicos diferentes. A alternativa D descreve um equívoco sobre como o IP Flow Verify funciona; ele avalia o caminho real do tráfego considerando a tradução de endereços, e o resultado é confiável. Agir com base na alternativa A levaria o administrador a modificar o NSG errado sem resolver o problema.
Gabarito — Cenário 2
Resposta: D
A restrição crítica do cenário é que o NSG da sub-rede está compartilhado por 14 outras VMs de produção. Excluir ou alterar a regra (alternativas A e B) sem validação com o time de segurança pode criar uma exposição de rede não intencional para todas essas VMs. A degradação é parcial, não crítica, o que remove a urgência que justificaria uma ação unilateral.
Aguardar a janela de manutenção e acionar o time de segurança (alternativa C) seria a abordagem ideal em um cenário sem degradação, mas o cenário apresenta um serviço em estado degradado que pode piorar, justificando uma ação imediata e cirúrgica.
A alternativa D resolve o problema de forma isolada: criar uma regra de permissão no NSG da NIC de vm-app02 com prioridade mais alta que a regra de bloqueio da sub-rede. Para tráfego de saída, o NSG da NIC é avaliado antes do NSG da sub-rede. Isso restaura a conectividade de vm-app02 sem modificar o NSG compartilhado, preservando a configuração das demais VMs até que o time de segurança possa avaliar a situação.
O distrator mais perigoso é a alternativa A. Excluir a regra sem entender o contexto das outras 14 VMs pode resultar em uma exposição de rede ampla em ambiente de produção.
Gabarito — Cenário 3
Resposta: B
A pista mais importante é o resultado do IP Flow Verify: Access: Allow. Isso significa que, do ponto de vista do NSG, o tráfego do IP 10.50.1.22 na porta 22 é permitido. O NSG não está bloqueando. O timeout relatado pelo segundo desenvolvedor, portanto, tem origem em outro componente do caminho de rede: o firewall do sistema operacional (iptables, ufw, firewalld), uma regra de hosts.allow/hosts.deny, o serviço SSH configurado para aceitar apenas IPs específicos, ou outro mecanismo fora do escopo do NSG.
A informação sobre a migração de host físico é propositalmente irrelevante. Migrações de host (como as realizadas pelo Azure Live Migration) não afetam nem corrompem regras de NSG; estas são mantidas pela camada de rede do Azure independentemente do host subjacente.
A alternativa C representa um erro aritmético: o IP 10.50.1.22 está dentro do bloco 10.50.0.0/16 (que cobre de 10.50.0.0 a 10.50.255.255), portanto a regra Allow-SSH-CorpNet o cobre sim. A alternativa D descreve um comportamento inexistente no Azure; NSGs de NIC sem regras personalizadas não possuem qualquer lógica diferenciada baseada em "conexões secundárias". Agir com base na alternativa A levaria o administrador a abrir um chamado de infraestrutura desnecessário enquanto o problema real permanece no sistema operacional da VM.
Gabarito — Cenário 4
Resposta: A
A sequência P → R → Q → S → T respeita a progressão diagnóstica correta:
P verifica primeiro se o serviço está funcional dentro da VM. Se o serviço não estiver escutando na porta 80, nenhuma investigação de NSG será relevante.
R obtém a visão consolidada das regras efetivas da NIC, que combina NSG da NIC e NSG da sub-rede em uma única lista ordenada. Isso já pode revelar a regra responsável pelo bloqueio sem necessidade de ferramentas adicionais.
Q usa o IP Flow Verify para confirmar o diagnóstico com precisão, identificando exatamente qual regra em qual NSG bloqueia o tráfego externo. Vem após R porque R fornece contexto que torna a leitura do resultado de Q mais produtiva.
S compara as origens cobertas pelas regras, o que explica por que o tráfego interno funciona e o externo não, completando o raciocínio causal.
T valida que a correção aplicada foi efetiva antes de encerrar o diagnóstico.
A alternativa B começa pelo IP Flow Verify antes de verificar se o serviço está ativo, o que pode levar a modificar NSGs quando o problema sequer está na camada de rede. A alternativa C inverte a lógica ao revisar regras efetivas antes de confirmar se há de fato um problema de serviço. Começar pelo diagnóstico antes de estabelecer o escopo do problema é o erro mais comum sob pressão.
Árvore de Troubleshooting: Evaluate Effective Security Rules in NSGs
Legenda de cores:
- Azul escuro: sintoma inicial, ponto de entrada do diagnóstico
- Azul: pergunta diagnóstica, nó de decisão
- Vermelho: causa identificada
- Verde: ação recomendada ou resolução
- Laranja: etapa de validação ou verificação intermediária
Para usar esta árvore diante de um problema real, comece pelo nó raiz descrevendo o sintoma de conectividade. A cada nó azul, responda a pergunta com base no que você observou no ambiente: estado do serviço, resultado do IP Flow Verify, nome da regra e NSG indicado. Siga o caminho correspondente até alcançar um nó vermelho que identifica a causa. A partir da causa, o nó verde indica a ação a tomar. Sempre finalize pelo nó de validação laranja antes de encerrar o atendimento.