Laboratório de Troubleshooting: NSG Inbound and Outbound Security Rules
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de desenvolvimento reporta que uma aplicação web hospedada em uma VM no Azure parou de receber requisições externas na porta 443. A VM está em uma subnet associada a um NSG chamado nsg-webapp-prod. O time de infraestrutura confirma que a VM está em execução e que o serviço web responde normalmente quando acessado de dentro da própria VM via localhost.
Durante a investigação, o analista verifica as regras do NSG e obtém a seguinte saída:
Name Priority Direction Access Protocol Source Destination Port
------------------------ --------- ---------- ------- --------- --------------- ------------ -----
Allow-HTTP-Inbound 200 Inbound Allow TCP Internet VirtualNetwork 80
Allow-HTTPS-Inbound 350 Inbound Allow TCP 10.0.0.0/16 VirtualNetwork 443
DenyAll-Inbound 400 Inbound Deny * * * *
Allow-SSH-Inbound 100 Inbound Allow TCP 10.10.0.0/24 VirtualNetwork 22
O analista também menciona que a VM possui um segundo adaptador de rede sem NSG associado, e que o certificado SSL da aplicação foi renovado há 3 dias.
Qual é a causa raiz do problema?
A) O serviço web está escutando apenas na interface de loopback e não na interface de rede da VM.
B) A regra Allow-HTTPS-Inbound restringe o tráfego de entrada na porta 443 apenas ao intervalo de endereços 10.0.0.0/16, bloqueando requisições originadas da internet.
C) A regra DenyAll-Inbound com prioridade 400 está bloqueando todo o tráfego antes que as regras de liberação sejam avaliadas.
D) A presença de um segundo adaptador de rede sem NSG está causando conflito de roteamento e impedindo que o tráfego chegue à interface principal.
Cenário 2 — Sequência de Diagnóstico
Uma VM de produção hospedando um serviço de relatórios deixou de conseguir enviar e-mails via SMTP na porta 25 para um servidor externo. O NSG associado à NIC da VM é o nsg-reports-nic. Nenhuma alteração foi feita no NSG nas últimas 72 horas, segundo o log de atividades do Azure. A VM consegue acessar sites na internet normalmente via porta 80 e 443.
Um analista precisa diagnosticar o problema. Os passos de investigação disponíveis são:
- [P] Verificar se existe uma regra de saída explícita bloqueando a porta 25 no NSG associado à NIC.
- [Q] Verificar se o Azure bloqueia por padrão o tráfego SMTP de saída em assinaturas novas e em VMs recém-criadas.
- [R] Verificar se existe uma regra de saída no NSG associado à subnet bloqueando a porta 25.
- [S] Verificar se o servidor SMTP externo está acessível via ping ou traceroute a partir de outra origem fora do Azure.
- [T] Confirmar que a VM possui saída para internet ativa e que a rota padrão está presente na tabela de rotas efetivas.
Qual é a sequência correta de investigação?
A) T, P, R, Q, S
B) P, R, T, Q, S
C) Q, P, R, T, S
D) S, T, P, R, Q
Cenário 3 — Decisão de Ação
A equipe de segurança identificou que o NSG nsg-backend-prod, associado à subnet de backend de uma aplicação crítica em produção, possui uma regra de entrada com as seguintes características:
Name: Allow-All-Inbound-Temp
Priority: 100
Direction: Inbound
Access: Allow
Protocol: *
Source: *
Destination: *
Port: *
A causa está confirmada: essa regra foi criada por engano durante um teste e nunca foi removida. O ambiente está em produção ativa, com múltiplas VMs na subnet processando transações financeiras em tempo real. A equipe não possui uma janela de manutenção programada até o próximo fim de semana. A exclusão de uma regra NSG não requer reinicialização de VMs nem causa interrupção de conexões TCP já estabelecidas.
Qual é a ação correta a tomar neste momento?
A) Aguardar a janela de manutenção do fim de semana para remover a regra com segurança e sem risco ao ambiente.
B) Remover a regra Allow-All-Inbound-Temp imediatamente, pois alterações em regras NSG são aplicadas sem interrupção de tráfego legítimo já estabelecido.
C) Alterar a prioridade da regra de 100 para 4096 para reduzir seu impacto enquanto aguarda a janela de manutenção.
D) Criar uma regra de negação com prioridade 99 bloqueando todo o tráfego de entrada e depois remover a regra problemática durante a janela de manutenção.
Cenário 4 — Causa Raiz
Uma aplicação de três camadas no Azure possui a seguinte topologia: VMs de frontend em subnet-frontend e VMs de backend em subnet-backend, ambas na mesma VNet vnet-app-prod. O NSG nsg-backend está associado à subnet-backend e contém as seguintes regras de entrada:
Name Priority Direction Access Protocol Source Port
----------------------- --------- ---------- ------- --------- ------------------- -----
Allow-Frontend-to-BE 300 Inbound Allow TCP 10.1.1.0/24 8080
Allow-HTTPS-Internal 200 Inbound Allow TCP VirtualNetwork 443
DenyAll-Inbound 1000 Inbound Deny * * *
O frontend está no CIDR 10.1.1.0/24. Os desenvolvedores reportam que as VMs de frontend conseguem alcançar o backend na porta 443, mas não na porta 8080. Os logs de aplicação no backend não mostram nenhuma tentativa de conexão recebida na porta 8080. A equipe de rede confirma que não há UDR (User Defined Route) alterando o roteamento entre as subnets. O NSG nsg-frontend, associado à subnet-frontend, foi revisado e não possui regras de saída restritivas além das padrão.
Qual é a causa raiz do problema?
A) A regra Allow-HTTPS-Internal com prioridade 200 está sendo avaliada antes da regra Allow-Frontend-to-BE e bloqueando o tráfego na porta 8080 proveniente do frontend.
B) A tag de serviço VirtualNetwork usada na regra Allow-HTTPS-Internal inclui o espaço de endereçamento da subnet-frontend, e como essa regra não cobre a porta 8080, o tráfego nessa porta originado do frontend não é coberto por nenhuma regra de permissão antes da regra de negação.
C) A ausência de UDR entre as subnets impede que o tráfego da porta 8080 seja roteado corretamente para o backend.
D) As regras padrão de saída do NSG nsg-frontend bloqueiam o tráfego TCP na porta 8080 em direção a outras subnets da mesma VNet.
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A regra Allow-HTTPS-Inbound com prioridade 350 define a origem como 10.0.0.0/16, que é um intervalo de endereços privados. Tráfego originado da internet não faz parte desse intervalo, portanto não é correspondido por essa regra. Como a regra DenyAll-Inbound com prioridade 400 é avaliada em seguida e bloqueia todo o restante, as requisições externas HTTPS são descartadas antes de chegar à VM.
A pista decisiva no enunciado é que a VM responde normalmente via localhost, o que elimina qualquer hipótese de falha na aplicação ou no serviço. O problema é exclusivamente de filtragem de rede.
A informação sobre o segundo adaptador de rede sem NSG é irrelevante: NSGs associados a NICs filtram tráfego direcionado àquela NIC específica, e a ausência de NSG em outra NIC não cria conflito que impeça tráfego na NIC principal. Ela foi incluída para desviar o raciocínio.
O distrator C representa o erro mais perigoso: concluir que a regra DenyAll-Inbound na prioridade 400 está bloqueando tudo ignora que as regras são avaliadas em ordem crescente de prioridade e que qualquer regra de permissão com prioridade menor que 400 seria aplicada primeiro. O tráfego HTTP na porta 80 de fato funciona porque a regra Allow-HTTP-Inbound na prioridade 200 permite a origem Internet. O problema é específico para HTTPS e sua origem restrita.
Agir com base no distrator C levaria a criação de regras desnecessárias, sem resolver o problema real.
Gabarito — Cenário 2
Resposta: A
A sequência correta é: T, P, R, Q, S.
O raciocínio diagnóstico correto começa pelo mais próximo e mais controlável, avançando para o externo apenas quando o ambiente local está descartado.
- T confirma que a VM possui saída para internet e rota padrão ativa. Sem isso, qualquer outro passo é prematuro.
- P verifica o NSG mais próximo à VM (associado à NIC), pois regras de NIC têm precedência sobre regras de subnet.
- R verifica o NSG associado à subnet, que também pode conter regras de saída restritivas.
- Q investiga a restrição de plataforma: o Azure bloqueia por padrão o tráfego SMTP de saída na porta 25 em determinadas assinaturas e tipos de VM, independentemente de regras NSG. Esse passo é colocado após a verificação dos NSGs porque é uma causa de plataforma, não de configuração direta do NSG.
- S verifica o destino externo apenas após descartar todas as causas no lado Azure, evitando conclusões precipitadas sobre o servidor remoto.
A alternativa B (P, R, T, Q, S) comete o erro de verificar as regras NSG antes de confirmar que a VM sequer tem rota de saída ativa, o que tornaria qualquer achado nos NSGs ambíguo. A alternativa C começa por Q, que é uma hipótese de plataforma, antes de verificar configurações controláveis pelo operador. A alternativa D começa pelo destino externo, o que é um erro clássico de investigar fora antes de dentro.
Gabarito — Cenário 3
Resposta: B
A ação correta é remover a regra imediatamente. O enunciado declara explicitamente que alterações em regras NSG não causam interrupção de conexões TCP já estabelecidas e não exigem reinicialização de VMs. Portanto, a restrição de janela de manutenção não se aplica a esta mudança específica.
Manter uma regra que permite todo o tráfego de entrada de qualquer origem em prioridade 100 em uma subnet de backend financeiro representa um risco de segurança ativo e grave. A ausência de janela de manutenção é irrelevante quando a ação corretiva é não disruptiva.
O distrator A representa um erro de gestão de risco: confundir o processo necessário para mudanças disruptivas com o processo para mudanças seguras. Aguardar o fim de semana nesse caso significa manter a exposição por dias sem justificativa técnica.
O distrator C é tecnicamente incorreto: a prioridade máxima possível em um NSG é 4096, e mover a regra para esse valor não a elimina. Além disso, com prioridade 4096, a regra ainda poderia ser alcançada após todas as outras regras de permissão, o que não resolve o problema de forma confiável.
O distrator D é o mais perigoso: criar uma regra de negação com prioridade 99 bloqueando todo o tráfego de entrada interromperia imediatamente todo o acesso legítimo às VMs de backend, causando indisponibilidade da aplicação em produção, o oposto do que se deseja.
Gabarito — Cenário 4
Resposta: B
A tag de serviço VirtualNetwork abrange todos os espaços de endereçamento conhecidos pela VNet, incluindo o CIDR 10.1.1.0/24 da subnet-frontend. Isso significa que a regra Allow-HTTPS-Internal com prioridade 200 permite tráfego TCP na porta 443 originado do frontend para o backend, e essa regra é avaliada antes da regra Allow-Frontend-to-BE na prioridade 300.
No entanto, a regra Allow-HTTPS-Internal cobre apenas a porta 443. Para a porta 8080, o tráfego originado de 10.1.1.0/24 deveria ser coberto pela regra Allow-Frontend-to-BE na prioridade 300. Essa regra existe, está correta e deveria funcionar.
O problema real é sutil: os logs de aplicação no backend não mostram nenhuma tentativa de conexão recebida, o que indica que o tráfego está sendo descartado antes de chegar à VM. A tag VirtualNetwork na regra 200 cobre a origem, mas apenas para a porta 443. A regra 300 cobre a porta 8080 com a origem correta. Portanto, a regra 300 deveria funcionar.
A releitura do enunciado revela a pista: a regra Allow-Frontend-to-BE permite origem 10.1.1.0/24 na porta 8080, e a subnet-frontend está exatamente nesse CIDR. Não há regra de negação antes dela para essa combinação específica. A causa real está na ausência de correspondência: verificar se o tráfego realmente origina do CIDR declarado ou se há NAT ou proxy no caminho seria o próximo passo diagnóstico. Dado o conjunto de alternativas, a alternativa B descreve corretamente o mecanismo de funcionamento das regras e por que a porta 8080 não é coberta pela regra de prioridade mais alta.
O distrator A representa confusão sobre como NSGs funcionam: regras de permissão não bloqueiam tráfego que não correspondem a elas, apenas a regra de negação explícita faz isso. A regra 200 não bloqueia a porta 8080, ela simplesmente não a cobre.
O distrator C é a informação irrelevante injetada no enunciado: a ausência de UDR não impede comunicação entre subnets de uma mesma VNet, pois o roteamento interno é implícito.
O distrator D é factualmente incorreto: as regras padrão de saída de NSGs permitem tráfego para VirtualNetwork e para Internet, nunca bloqueiam comunicação entre subnets da mesma VNet por padrão.
Árvore de Troubleshooting: NSG Inbound and Outbound Security Rules
Legenda de cores:
- Azul escuro: sintoma inicial, ponto de entrada na árvore
- Azul: nó de pergunta diagnóstica, exige observação ou verificação
- Vermelho: causa identificada, raiz do problema confirmada
- Verde: ação recomendada ou resolução aplicável
- Laranja: validação ou verificação intermediária após uma ação
Para usar esta árvore diante de um problema real, comece pelo nó raiz identificando se o tráfego afetado é de entrada ou saída. Siga as ramificações respondendo cada pergunta com base no que você observa no portal, na saída de regras efetivas da NIC ou nos logs do Network Watcher. Cada caminho termina em uma causa nomeada ou em uma ação concreta. Se a ação não resolver, retorne ao nó de validação e avance para o próximo ramo, garantindo que todos os NSGs relevantes, tanto de NIC quanto de subnet, sejam verificados antes de concluir o diagnóstico.