Laboratório de Troubleshooting: Create and configure network security groups (NSGs) and application security groups
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de desenvolvimento reporta que as VMs de aplicação não conseguem se comunicar com as VMs de banco de dados na porta 5432. O ambiente usa ASGs para segmentação: asg-app para as VMs de aplicação e asg-db para as VMs de banco de dados. Todas as VMs estão na mesma VNet, em sub-redes distintas.
O administrador verifica o NSG associado à sub-rede do banco de dados e encontra as seguintes regras de entrada:
Prioridade | Nome | Origem | Destino | Porta | Ação
-----------|---------------------|--------------|----------|-------|------
100 | Allow-App-To-DB | asg-app | asg-db | 5432 | Allow
200 | Allow-Monitoring | 10.0.10.5/32 | asg-db | 9100 | Allow
65000 | AllowVnetInBound | VirtualNetwork | Any | Any | Allow
65500 | DenyAllInBound | Any | Any | Any | Deny
O administrador confirma que as NICs das VMs de aplicação estão associadas ao asg-app e as NICs das VMs de banco de dados estão associadas ao asg-db. O NSG está corretamente associado à sub-rede de banco de dados. A equipe menciona que o problema começou após uma migração de VMs para novos tamanhos de SKU realizada na semana anterior, mas não houve alteração nas regras do NSG.
Qual é a causa raiz da falha de conectividade?
A) A regra AllowVnetInBound de prioridade 65000 está sendo sobreposta pela regra Allow-App-To-DB, criando conflito entre ASG e tag de serviço no mesmo NSG.
B) Durante a migração de SKU, as NICs das VMs foram recriadas e perderam a associação com o ASG, fazendo com que o tráfego das VMs de aplicação não corresponda mais à regra Allow-App-To-DB.
C) A regra Allow-Monitoring está consumindo slots de processamento e causando timeout nas conexões da porta 5432.
D) O NSG associado à sub-rede não avalia regras baseadas em ASG para tráfego entre sub-redes distintas; o NSG deveria estar associado à NIC das VMs de banco de dados.
Cenário 2 — Decisão de Ação
O time de segurança identificou que uma regra de NSG criada há seis meses permite acesso irrestrito à porta 22 (SSH) de qualquer origem para um grupo de VMs de desenvolvimento:
Prioridade | Nome | Origem | Destino | Porta | Ação
-----------|----------------|--------|---------|-------|------
100 | Allow-SSH-All | Any | Any | 22 | Allow
A causa é conhecida: a regra foi criada temporariamente para um projeto e nunca foi removida. O NSG está associado à sub-rede de desenvolvimento, que contém 12 VMs ativas usadas por três equipes diferentes em horário comercial. São 14h de uma sexta-feira. O time de segurança exige que o acesso irrestrito seja eliminado ainda hoje. As equipes de desenvolvimento não foram notificadas e não há janela de manutenção agendada.
Qual é a ação correta a tomar neste momento?
A) Excluir imediatamente a regra Allow-SSH-All e criar uma nova regra permitindo SSH apenas dos endereços IP corporativos conhecidos, sem notificação prévia, pois o risco de segurança justifica a ação imediata.
B) Alterar a prioridade da regra Allow-SSH-All para 4096, reduzindo sua efetividade sem removê-la, enquanto aguarda uma janela de manutenção na semana seguinte.
C) Notificar as equipes de desenvolvimento imediatamente, criar a regra restritiva com prioridade menor que 100 em paralelo, validar que as conexões legítimas continuam funcionando e só então remover a regra Allow-SSH-All.
D) Associar o NSG a uma NIC específica em vez da sub-rede para limitar o escopo da regra enquanto o problema é avaliado com mais calma na semana seguinte.
Cenário 3 — Causa Raiz
Um administrador recebe o seguinte alerta do sistema de monitoramento às 03h:
ALERT: VM 'vm-webfront-03' unreachable on port 443
Source: Azure Monitor
Time: 03:12 UTC
Affected resource: /subscriptions/.../vm-webfront-03
Last successful probe: 02:47 UTC
O administrador acessa o portal e usa a ferramenta IP flow verify do Network Watcher com os seguintes parâmetros:
VM: vm-webfront-03
Direção: Entrada
Protocolo: TCP
Endereço local: 10.0.1.15
Porta local: 443
Endereço remoto: 203.0.113.42
Porta remota: 54231
Resultado: DENY — Regra: DenyAllInBound (NSG: nsg-frontend)
O administrador verifica o NSG nsg-frontend e encontra as regras abaixo:
Prioridade | Nome | Origem | Destino | Porta | Ação
-----------|-------------------|-----------|---------|-------|------
100 | Allow-HTTPS | Any | Any | 443 | Allow
200 | Allow-HTTP | Any | Any | 80 | Allow
65500 | DenyAllInBound | Any | Any | Any | Deny
A VM vm-webfront-03 tem dois NICs: nic-primary (10.0.1.15) e nic-mgmt (10.0.2.30). O NSG nsg-frontend está associado à sub-rede subnet-frontend (10.0.1.0/24). O administrador confirma que não houve alteração nas regras do NSG nas últimas 48 horas. A VM estava funcionando normalmente até 02:47 UTC.
Qual é a causa raiz mais provável do bloqueio?
A) As regras Allow-HTTPS e Allow-HTTP estão com o campo de destino configurado como Any, o que impede que o NSG as associe corretamente ao IP da VM.
B) O NSG nsg-frontend foi desassociado da sub-rede ou foi associado adicionalmente à nic-primary, e a regra Allow-HTTPS não está presente no NSG que efetivamente processa o tráfego da NIC.
C) A VM possui dois NICs e o Azure está roteando o tráfego de entrada pela nic-mgmt (10.0.2.30), que pertence a uma sub-rede diferente onde não existe uma regra equivalente à Allow-HTTPS.
D) O IP flow verify retornou resultado incorreto porque a ferramenta não considera regras em NSGs associados a sub-redes, apenas NSGs associados a NICs.
Cenário 4 — Sequência de Diagnóstico
Uma VM de produção parou de responder na porta 8080 após uma janela de manutenção em que foram realizadas três atividades simultâneas: adição de uma nova regra de NSG, associação de um segundo NSG à NIC da VM, e inclusão da NIC em um novo ASG.
O administrador precisa diagnosticar qual mudança causou o bloqueio. Abaixo estão cinco passos de investigação disponíveis:
- Usar o IP flow verify no Network Watcher para confirmar qual regra está bloqueando o tráfego e em qual NSG ela está
- Verificar os logs de alteração via Activity Log para identificar a sequência exata das mudanças realizadas durante a manutenção
- Confirmar se a VM consegue se comunicar em outras portas para determinar se o bloqueio é total ou parcial
- Revisar todas as regras do NSG associado à sub-rede e do NSG associado à NIC, comparando prioridades e sobreposições
- Verificar se a NIC está associada ao ASG correto e se alguma regra depende desse ASG como origem ou destino
Qual é a sequência correta de diagnóstico?
A) 2 → 1 → 3 → 4 → 5
B) 3 → 1 → 4 → 5 → 2
C) 1 → 4 → 2 → 3 → 5
D) 3 → 2 → 1 → 4 → 5
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista central está na combinação de dois fatos: o problema começou após a migração de SKU das VMs, e não houve alteração nas regras do NSG. Quando uma VM é redimensionada para um novo SKU de forma que exige a recriação da NIC, a associação entre a NIC e o ASG é perdida. Sem essa associação, o tráfego originado pelas VMs de aplicação não corresponde à regra Allow-App-To-DB, que usa asg-app como filtro de origem. O tráfego então cai na regra padrão DenyAllInBound.
A informação sobre a regra Allow-Monitoring é propositalmente irrelevante: ela afeta apenas a porta 9100 e não interfere no processamento de regras para a porta 5432. Incluí-la no enunciado induz o leitor a procurar um problema de configuração nas regras, desviando do evento real.
A alternativa D descreve uma restrição que não existe: NSGs associados a sub-redes avaliam regras com ASG normalmente para tráfego entre sub-redes. Agir com base nessa alternativa levaria o administrador a reorganizar associações de NSG sem resolver o problema real.
Gabarito — Cenário 2
Resposta: C
O cenário apresenta duas restrições críticas: as equipes estão em horário ativo e não foram notificadas. A alternativa A ignora a segunda restrição e arrisca interromper conexões SSH legítimas de 12 VMs em uso, sem validação prévia. A alternativa B não elimina o risco de segurança no prazo exigido e representa uma ação incompleta disfarçada de cautela. A alternativa D ignora completamente o prazo imposto pelo time de segurança e não resolve o problema.
A alternativa C é a única que satisfaz simultaneamente todas as restrições: elimina o risco no prazo exigido, notifica os afetados, valida a continuidade do acesso legítimo antes de remover a regra problemática, e segue a sequência correta de adicionar antes de remover. O distrator mais perigoso é A, pois parece tecnicamente correto e urgente, mas a remoção sem validação prévia em ambiente com usuários ativos pode causar interrupção imediata para equipes que dependem de SSH.
Gabarito — Cenário 3
Resposta: C
A pista decisiva é que a VM possui dois NICs em sub-redes diferentes. O alerta de monitoramento e o IP flow verify usam o IP 10.0.1.15, que pertence à nic-primary na subnet-frontend. Porém, o roteamento de tráfego de entrada em VMs com múltiplas NICs depende de como as rotas estão configuradas. Se o tráfego externo destinado à VM estiver sendo recebido pela nic-mgmt (10.0.2.30), o NSG aplicado à sub-rede dessa NIC é quem processa o tráfego, e não o nsg-frontend. Se não houver uma regra equivalente à Allow-HTTPS no NSG da subnet-mgmt, o bloqueio ocorre pela DenyAllInBound padrão daquele NSG.
O fato de não ter havido alteração nas regras do nsg-frontend nas últimas 48 horas descarta problemas nesse NSG. A alternativa A descreve um comportamento inexistente: o campo Any no destino é válido e não impede a correspondência. A alternativa D é falsa: o IP flow verify considera NSGs tanto de sub-rede quanto de NIC.
Gabarito — Cenário 4
Resposta: B
O raciocínio diagnóstico correto parte do sintoma observável e progride em direção à causa de forma progressiva, sem presumir a origem antes de confirmar o problema. O passo 3 (verificar se o bloqueio é total ou parcial) estabelece o escopo do problema antes de qualquer outra ação. O passo 1 (IP flow verify) identifica com precisão a regra bloqueadora e o NSG responsável, eliminando o trabalho de revisar manualmente todas as configurações. O passo 4 (revisar regras e prioridades dos dois NSGs) aprofunda a análise no NSG identificado. O passo 5 (verificar associação com ASG) testa a hipótese específica do ASG. O passo 2 (Activity Log) confirma a sequência das mudanças e encerra o diagnóstico com evidência de auditoria.
A alternativa D começa pelo passo 3 corretamente, mas salta para o Activity Log antes de usar o IP flow verify, o que significa revisar um histórico de mudanças sem ainda saber qual componente investigar. A alternativa A começa pelo Activity Log sem confirmar o sintoma, o que desperdiça tempo em auditoria antes de reproduzir e localizar o problema.
Árvore de Troubleshooting: Create and configure network security groups (NSGs) and application security groups
Legenda
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Verificação ou validação intermediária |
Para usar esta árvore diante de um problema real, comece pelo nó raiz descrevendo o sintoma de conectividade bloqueada. Responda cada pergunta com base no que você observa diretamente no ambiente, sem presumir a causa. Os nós de verificação intermediária indicam onde coletar evidências antes de avançar. Cada caminho termina em uma causa nomeada e em uma ação específica, eliminando a necessidade de testar hipóteses sem fundamento.