Laboratório de Troubleshooting: Evaluate network security recommendations identified by Microsoft Defender for Cloud attack paths
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de operações reporta que o Microsoft Defender for Cloud está exibindo um attack path com classificação Critical há três dias, mesmo após o time de infraestrutura afirmar que aplicou todas as correções necessárias. O engenheiro responsável compartilha o histórico de ações realizadas:
- Regra de NSG criada bloqueando tráfego de entrada na porta 3389 para a VM
prod-dc-01 - Tag
Environment: Productionadicionada ao recurso para fins de governança - Plano do Defender for Cloud atualizado de Foundational CSPM para Defender CSPM na assinatura
O attack path atual no portal mostra o seguinte estado:
Attack path status: Active
Risk level: Critical
Path:
[Internet]
--> [Public IP: 20.85.110.44 | associated with NIC of prod-dc-01]
--> [VM: prod-dc-01 | RDP port 3389 reachable from Internet]
--> [Managed Disk: disk-prod-dc-01 | unencrypted]
Recommendations pending:
- [HIGH] Enable disk encryption on prod-dc-01
- [MEDIUM] Apply Just-in-Time VM access
A equipe acredita que o problema foi resolvido porque a regra de NSG foi criada. O Defender for Cloud discorda.
Qual é a causa raiz do attack path permanecer ativo?
A) O plano Defender CSPM ainda não foi totalmente provisionado, o que impede a reavaliação do grafo de segurança.
B) A regra de NSG bloqueia tráfego de entrada, mas o Public IP ainda está associado diretamente à NIC da VM, e o disco permanece sem criptografia, mantendo o destino final vulnerável.
C) A tag Environment: Production aplicada ao recurso altera o comportamento de avaliação do Defender for Cloud, exigindo aprovação manual para fechar o attack path.
D) O Defender for Cloud detectou que a regra de NSG foi criada com prioridade incorreta, tornando-a ineficaz contra tráfego originado da internet.
Cenário 2 — Decisão de Ação
A causa raiz foi identificada: um Azure Application Gateway em ambiente de produção está operando sem o Web Application Firewall (WAF) habilitado, e essa configuração é o nó de entrada de um attack path classificado como High pelo Defender for Cloud. O attack path conecta esse gateway a um banco de dados SQL com acesso de rede irrestrito.
O contexto operacional é o seguinte:
- O Application Gateway processa aproximadamente 850 mil requisições por hora em horário de pico
- A janela de manutenção aprovada começa em 6 horas
- A equipe de segurança tem permissão para aplicar mudanças de configuração imediatamente, sem aprovação adicional
- A equipe de rede informa que o SKU atual do Application Gateway é Standard V2
- O banco de dados SQL está sendo utilizado ativamente por uma aplicação crítica de pagamentos
Qual é a ação correta a tomar neste momento?
A) Habilitar o WAF imediatamente no Application Gateway, pois a equipe tem permissão e o risco é classificado como High.
B) Aguardar a janela de manutenção aprovada em 6 horas e, nesse momento, migrar o SKU do Application Gateway para WAF V2 antes de habilitar o WAF.
C) Aplicar imediatamente uma regra de NSG restringindo o acesso ao banco de dados SQL, mitigando o destino final do attack path enquanto a mudança no gateway é planejada para a janela de manutenção.
D) Criar um ticket de exceção no Defender for Cloud desabilitando a recomendação do WAF até a próxima janela de manutenção, evitando alertas desnecessários.
Cenário 3 — Causa Raiz
Um engenheiro analisa o seguinte output extraído do Defender for Cloud via CLI:
az security attack-path list --query "[].{Name:name, RiskLevel:properties.riskLevel, Status:properties.status}" -o table
Name RiskLevel Status
-------------------------------------------- ----------- --------
Internet-VM-StorageAccount-path-001 Critical Active
Internet-AppGW-AKS-KeyVault-path-002 High Active
Internet-VM-SQLServer-path-003 High Dismissed
Internet-PublicIP-VM-path-004 Medium Active
O engenheiro nota que o path Internet-VM-SQLServer-path-003 está com status Dismissed e questiona por que o Defender for Cloud não está monitorando esse caminho. Ele verifica o ambiente e coleta as seguintes informações adicionais:
- A VM envolvida no path 003 tem o Microsoft Monitoring Agent instalado e reportando corretamente ao workspace do Log Analytics
- O SQL Server referenciado tem o Defender for SQL habilitado e sem alertas ativos
- A assinatura tem o plano Defender CSPM ativo
- Um membro da equipe de segurança aplicou uma isenção (exemption) na recomendação de acesso público ao SQL Server há duas semanas, com justificativa de "risco aceito pelo negócio"
O engenheiro pergunta a um colega por que o path está dismissado. O colega responde que provavelmente é por causa do agente instalado na VM. Essa hipótese está incorreta.
Qual é a causa raiz real do status Dismissed no attack path 003?
A) O Defender for SQL habilitado no SQL Server sinalizou ao Defender for Cloud que o recurso está protegido, resultando no encerramento automático do attack path.
B) A isenção aplicada à recomendação de acesso público ao SQL Server fez com que o Defender for Cloud desconsiderasse essa vulnerabilidade ao calcular o attack path, resultando no status Dismissed.
C) A presença do Microsoft Monitoring Agent na VM indica que o recurso está sendo monitorado ativamente, o que reduz a pontuação de risco do path abaixo do limiar de exibição.
D) O path foi automaticamente dismissado porque não houve atividade de exploração detectada nos últimos 14 dias, conforme o comportamento padrão do Defender CSPM.
Cenário 4 — Sequência de Diagnóstico
Um engenheiro recebe o seguinte relato:
"O Defender for Cloud parou de exibir attack paths para nossa assinatura. Ontem havia 7 paths ativos. Hoje a lista está vazia. Nenhuma correção foi aplicada pela equipe."
O engenheiro precisa diagnosticar a causa dessa ausência inesperada de attack paths. Ele dispõe dos seguintes passos de investigação, apresentados fora de ordem:
- Verificar se o plano Defender CSPM permanece habilitado na assinatura
- Confirmar se houve mudanças recentes de permissão ou role assignment que possam ter restringido o escopo de visibilidade do Defender for Cloud
- Acessar o portal do Defender for Cloud e verificar se há mensagem de erro ou aviso na seção de Cloud Security Graph
- Consultar o Activity Log da assinatura para identificar ações administrativas realizadas nas últimas 24 horas
- Tentar listar os attack paths via CLI com
az security attack-path listpara confirmar se a ausência é somente visual ou também na API
Qual é a sequência correta de investigação?
A) 3 -> 1 -> 4 -> 5 -> 2
B) 1 -> 3 -> 5 -> 4 -> 2
C) 5 -> 2 -> 1 -> 4 -> 3
D) 4 -> 1 -> 3 -> 5 -> 2
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista central está no próprio output do portal: o attack path ainda aponta o disco sem criptografia como nó de destino vulnerável, e as recomendações pendentes confirmam isso. A regra de NSG pode ter reduzido a superfície de ataque na porta 3389, mas dois problemas persistem: o Public IP continua associado à NIC, o que significa que a VM ainda é diretamente endereçável pela internet, e o disco permanece sem criptografia, mantendo o destino final exposto. Um attack path só é removido quando todos os elos críticos da cadeia são corrigidos.
A informação irrelevante no cenário é a tag Environment: Production, que não tem nenhum efeito sobre o comportamento do Defender for Cloud na avaliação de attack paths. A alternativa A é um distrator plausível, pois a troca de plano é uma ação real no cenário, mas o Defender CSPM já estava ativo antes da avaliação ser exibida. A alternativa D confunde o mecanismo de regras de NSG com o modelo de avaliação do Defender for Cloud, que não analisa prioridade de regras para decidir se um attack path é válido.
O distrator mais perigoso é a alternativa A: agir com base nela levaria a equipe a aguardar um provisionamento que já foi concluído, atrasando a correção real.
Gabarito — Cenário 2
Resposta: B
A restrição crítica do cenário é o SKU: o Application Gateway está no SKU Standard V2, que não suporta WAF nativamente. Habilitar o WAF requer migração para o SKU WAF V2, e essa migração representa uma mudança estrutural com potencial impacto sobre o processamento de 850 mil requisições por hora. Aplicar isso fora da janela de manutenção, mesmo com permissão, seria tecnicamente incorreto dado o risco operacional.
A alternativa A é o distrator mais perigoso: a equipe tem permissão e o risco é real, mas ignorar o requisito de SKU levaria a uma tentativa de configuração que simplesmente falharia ou exigiria recriação do recurso. A alternativa C é válida como mitigação parcial, mas o enunciado pergunta qual é a ação correta neste momento, e proteger apenas o destino sem tratar o ponto de entrada não endereça a causa principal do attack path. A alternativa D representa uma prática que mascara o risco sem corrigi-lo.
Gabarito — Cenário 3
Resposta: B
A causa raiz está na isenção aplicada à recomendação de acesso público ao SQL Server. Quando uma recomendação é isenta no Defender for Cloud, ela deixa de ser tratada como uma vulnerabilidade ativa no Cloud Security Graph. Como o attack path é calculado com base nesse grafo, a ausência da vulnerabilidade como nó ativo resulta no status Dismissed para o caminho que dependia dela.
O colega no enunciado aponta o agente da VM como causa, o que é a informação irrelevante deliberada do cenário. A presença ou ausência do Microsoft Monitoring Agent não afeta a lógica de cálculo de attack paths no Defender CSPM.
A alternativa A representa um equívoco comum: o Defender for SQL fornece detecção e alertas, mas não instrui o Defender for Cloud a fechar attack paths automaticamente. A alternativa D descreve um comportamento que não existe na plataforma; o Defender for Cloud não dismisses attack paths por inatividade temporal.
O distrator mais perigoso é a alternativa A, pois levaria o engenheiro a concluir que o SQL Server está protegido quando, na realidade, a isenção apenas ocultou o risco da visibilidade do Defender for Cloud.
Gabarito — Cenário 4
Resposta: B
A sequência correta segue a lógica de diagnóstico progressivo: partir do mais amplo e estrutural para o mais específico e contextual.
O passo 1 (verificar se o Defender CSPM está habilitado) é o ponto de partida porque, sem o plano correto, nenhum attack path é gerado. Confirmado o plano, o passo 3 (verificar mensagens de erro no Cloud Security Graph) identifica se há falha de processamento interna. O passo 5 (consultar via CLI) confirma se o problema é de interface ou de dado real. O passo 4 (Activity Log) investiga mudanças administrativas que possam ter causado o problema. O passo 2 (permissões e role assignments) é o último porque é a causa mais específica e contextual, e só faz sentido investigá-la após descartar causas mais prováveis.
A alternativa A começa pelo sintoma visual (passo 3) antes de confirmar se a plataforma está operacional, o que é ineficiente. A alternativa C começa pela CLI sem antes confirmar se o plano está ativo, pulando a validação mais básica. A alternativa D começa pelo Activity Log, que é útil mas não é o passo mais direto para confirmar se o problema é de configuração de plano ou de dado.
Árvore de Troubleshooting: Evaluate network security recommendations identified by Microsoft Defender for Cloud attack paths
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro (#1a1a2e) | Sintoma inicial ou ponto de entrada |
| Azul (#0077b6) | Pergunta diagnóstica |
| Vermelho (#d62828) | Causa identificada |
| Verde (#2d6a4f) | Ação recomendada ou resolução |
| Laranja (#f4a261) | Validação ou verificação intermediária |
Para usar esta árvore diante de um problema real, comece pelo nó raiz descrevendo o sintoma observado (attack path ativo inesperadamente ou ausente sem motivo aparente) e siga as ramificações respondendo cada pergunta com base no que é observável diretamente no portal ou via CLI. Cada resposta elimina um conjunto de hipóteses e direciona o raciocínio para a causa mais provável, evitando ações corretivas prematuras sobre nós que não são a origem real do problema.