Laboratório de Troubleshooting: Evaluate network security recommendations identified by Microsoft Defender for Cloud Secure Score
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de operações relata que o Secure Score de uma assinatura ficou estagnado em 61% por três semanas consecutivas, mesmo após a equipe ter remediado 12 recomendações de rede durante esse período. O gerente de segurança confirma que as remediações foram aplicadas e que os recursos estão funcionando corretamente.
O analista responsável coleta as seguintes informações durante a investigação:
Assinatura: prod-networking-sub
Plano ativo: Defender for Servers (P2)
Recomendações remediadas (últimas 3 semanas): 12
Recomendações com status "Completed": 0
Recomendações com status "Healthy": 12
Controles impactados pelas remediações: 2
Peso total dos controles impactados: 4 pontos
Peso total dos controles ainda Unhealthy: 38 pontos
Última atualização do score registrada: há 21 dias
Workspace do Azure Monitor: centralizado, compartilhado com 4 assinaturas
A equipe também menciona que o Network Watcher está desabilitado em duas regiões, mas que isso "já estava assim antes" e não havia sido alterado recentemente.
Qual é a causa raiz da estagnação do Secure Score?
A) O workspace centralizado do Azure Monitor está impedindo que as recomendações remediadas sejam reavaliadas corretamente pelo Defender for Cloud.
B) As 12 recomendações remediadas pertencem a controles de baixo peso, enquanto os controles com maior peso permanecem não atendidos, resultando em ganho líquido insuficiente para alterar o score percentual.
C) O Network Watcher desabilitado em duas regiões está bloqueando a reavaliação automática do Defender for Cloud, congelando o score no valor anterior.
D) O plano Defender for Servers P2 não cobre recomendações de rede, de modo que as remediações realizadas pela equipe não são reconhecidas no cálculo do Secure Score.
Cenário 2 — Causa Raiz
Uma organização recém-migrou 200 VMs para o Azure e habilitou o Microsoft Defender for Cloud na assinatura. Dois dias após a habilitação, o analista de segurança acessa o painel e observa o seguinte comportamento:
Secure Score atual: 21%
Recomendações ativas: 47
Recomendações de rede com severidade High: 9
Status da recomendação "Just-in-time VM access should be enabled": Unhealthy
Recursos afetados: 200 VMs
O analista tenta clicar em "Fix" na recomendação "Adaptive network hardening recommendations should be applied on internet facing virtual machines" e recebe a seguinte mensagem:
No recommendations available.
This resource does not have enough traffic data to generate hardening recommendations.
A recomendação permanece como Unhealthy apesar de o analista ter clicado em "Fix". O ambiente tem um NSG associado a cada VM e todas as VMs têm IPs públicos atribuídos. O Log Analytics agent está instalado em todas as VMs e reportando dados de performance normalmente.
Qual é a causa raiz do comportamento observado na recomendação de Adaptive Network Hardening?
A) O Log Analytics agent está instalado mas não está configurado para coletar logs de fluxo de rede, impedindo a análise de tráfego pelo Defender for Cloud.
B) A recomendação de Adaptive Network Hardening requer um período mínimo de coleta de dados de tráfego real antes de gerar recomendações de endurecimento; as VMs foram migradas há apenas dois dias.
C) O Defender for Cloud não consegue gerar recomendações de Adaptive Network Hardening porque os NSGs estão associados diretamente às VMs em vez de às sub-redes.
D) A presença de IPs públicos em todas as VMs impede que o algoritmo de Adaptive Network Hardening calcule as regras de endurecimento corretas, pois o modelo foi projetado para VMs sem exposição direta à internet.
Cenário 3 — Decisão de Ação
A causa já foi identificada: uma recomendação de alta severidade relacionada a NSGs está marcada como Unhealthy para 85 VMs de produção porque as regras atuais permitem acesso irrestrito na porta 22 (SSH) a partir de qualquer origem (0.0.0.0/0).
O contexto operacional é o seguinte:
- Ambiente: produção ativa, janela de manutenção disponível apenas às sextas-feiras entre 22h e 02h
- Dia e hora atual: quinta-feira, 14h30
- Impacto da recomendação no Secure Score: controle com peso de 8 pontos
- A equipe de operações confirma que o acesso SSH externo irrestrito é necessário apenas para um grupo de 3 IPs de administradores externos
- O time de segurança quer melhorar o score o mais rápido possível
- Um membro da equipe sugere aplicar a correção imediatamente para subir o score ainda hoje
Qual é a ação correta a tomar neste momento?
A) Aplicar imediatamente a restrição do NSG para limitar o acesso SSH apenas aos 3 IPs autorizados, aproveitando que o ambiente está em horário de baixo uso.
B) Aplicar uma isenção do tipo Waiver na recomendação para remover o impacto negativo no score sem alterar as regras de NSG, aguardando a janela de manutenção.
C) Documentar a mudança necessária, obter aprovação do processo de gestão de mudanças e executar a alteração do NSG durante a janela de manutenção disponível na sexta-feira.
D) Escalar a recomendação para o time de arquitetura para redesenho completo da estratégia de acesso remoto antes de qualquer alteração.
Cenário 4 — Impacto Colateral
Uma equipe de segurança identifica que o Secure Score está sendo penalizado por uma recomendação relacionada à ausência de diagnóstico de fluxo em NSGs em uma assinatura com 15 sub-redes de produção. Para resolver rapidamente, o operador habilita os logs de fluxo de NSG em todas as sub-redes apontando para um único Storage Account existente que já armazena logs de auditoria de aplicação.
A ação resolve a recomendação e o Secure Score sobe conforme esperado.
Qual é a consequência secundária mais provável dessa ação?
A) Os logs de fluxo de NSG habilitados sem um workspace do Log Analytics associado não serão processados pelo Microsoft Defender for Cloud, tornando a remediação inválida após a próxima reavaliação.
B) O volume de logs de fluxo de NSG gerado por 15 sub-redes de produção pode causar crescimento acelerado e não planejado do Storage Account, potencialmente misturando dados operacionais com logs de auditoria e aumentando custos de armazenamento.
C) A habilitação dos logs de fluxo de NSG em sub-redes de produção causa degradação de performance nas VMs associadas, pois o agente de coleta compete por recursos de CPU com as aplicações em execução.
D) O Defender for Cloud irá reclassificar a recomendação como Unhealthy novamente após 24 horas caso os logs de fluxo não estejam sendo analisados ativamente por uma regra de alerta configurada no Microsoft Sentinel.
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista decisiva está nos dados coletados pelo analista: os controles impactados pelas 12 remediações somam apenas 4 pontos de peso, enquanto os controles ainda Unhealthy somam 38 pontos. O Secure Score é calculado como a proporção de pontos obtidos sobre o total de pontos possíveis. Remediar controles de baixo peso em um ambiente com grande quantidade de controles pesados não atendidos produz variação percentual mínima ou imperceptível, o que explica a estagnação.
A informação sobre o Network Watcher desabilitado é deliberadamente irrelevante: o enunciado afirma que essa condição preexistia e não houve mudança recente, portanto não explica a estagnação das últimas três semanas. O analista que foca no Network Watcher comete o erro clássico de investigar o que é visível em vez do que é causalmente relacionado ao sintoma.
A alternativa A confunde o papel do workspace centralizado: ele não interfere na reavaliação de recomendações pelo Defender for Cloud. A alternativa D é incorreta porque o plano Defender for Servers cobre recomendações de rede para VMs. O distrator mais perigoso é a alternativa C, pois o Network Watcher desabilitado é uma informação real e visível no ambiente, e um analista despreparado poderia focar nela em vez de olhar para a matemática do score.
Gabarito — Cenário 2
Resposta: B
A causa raiz é a insuficiência de dados de tráfego acumulado. A própria mensagem retornada pelo sistema confirma isso: "This resource does not have enough traffic data to generate hardening recommendations." O Adaptive Network Hardening analisa padrões de tráfego real ao longo do tempo para propor regras de endurecimento de NSG. Com apenas dois dias de operação, o volume de dados coletados é insuficiente para que o algoritmo gere recomendações aplicáveis.
A informação sobre o Log Analytics agent reportando dados de performance normalmente é deliberadamente irrelevante: coleta de métricas de performance é diferente de análise de tráfego de rede para fins de hardening. Um analista que confunde os dois pode concluir erroneamente que o agente está mal configurado.
A alternativa C introduz uma premissa falsa: a associação de NSG à VM versus sub-rede não é o critério determinante para a geração de recomendações de Adaptive Network Hardening. A alternativa D inverte a lógica: a exposição à internet é exatamente o cenário para o qual o Adaptive Network Hardening foi projetado. O distrator mais perigoso é a alternativa A, pois a configuração do agente de Log Analytics é um suspeito natural em qualquer problema de coleta de dados, e a distinção entre coleta de performance e análise de tráfego não é óbvia sem conhecimento específico do recurso.
Gabarito — Cenário 3
Resposta: C
A restrição crítica do cenário é que o ambiente é de produção ativa e existe um processo de gestão de mudanças com janela definida para sexta-feira à noite. Alterar regras de NSG em produção fora da janela de manutenção sem aprovação formal representa um risco operacional e de governança que supera o benefício de subir o score algumas horas antes.
A alternativa A ignora a restrição de janela de manutenção e processo de mudança, que são restrições explícitas no enunciado. Mesmo que a mudança seja tecnicamente simples e o horário seja de baixo uso, executá-la sem processo formal em produção é a ação errada dado o contexto.
A alternativa B usa uma isenção Waiver de forma incorreta: isenção é adequada quando a organização decide conscientemente não implementar um controle, não como recurso temporário para manipular o score enquanto aguarda uma janela. A alternativa D representa procrastinação desnecessária: o problema e a solução já estão identificados e não requerem redesenho arquitetural. O distrator mais perigoso é a alternativa A, pois a lógica de "horário de baixo uso" parece razoável e a urgência do score pode pressionar o analista a agir fora do processo.
Gabarito — Cenário 4
Resposta: B
A consequência colateral real é o crescimento acelerado e não planejado do Storage Account. Logs de fluxo de NSG em 15 sub-redes de produção geram volume significativo de dados continuamente. Armazená-los no mesmo Storage Account usado para logs de auditoria de aplicação cria dois problemas concretos: mistura de dados com finalidades diferentes (dificultando governança e retenção diferenciada) e crescimento de custo de armazenamento não previsto no orçamento.
A alternativa A é incorreta: logs de fluxo de NSG não precisam estar conectados a um workspace do Log Analytics para serem válidos como evidência de conformidade para a recomendação do Defender for Cloud. O requisito é a habilitação dos logs, não sua análise ativa. A alternativa C é tecnicamente falsa: os logs de fluxo de NSG são coletados pela plataforma Azure diretamente, sem agente nas VMs, portanto não há competição de recursos de CPU. A alternativa D descreve um comportamento que o Defender for Cloud não possui: a reavaliação verifica a habilitação dos logs, não a existência de regras de alerta no Sentinel. O distrator mais perigoso é a alternativa A, pois a ausência de integração com o Log Analytics parece intuitivamente problemática para quem conhece o papel desse workspace em outros cenários do Defender for Cloud.
Árvore de Troubleshooting: Evaluate network security recommendations identified by Microsoft Defender for Cloud Secure Score
Legenda de cores:
- Azul escuro: sintoma inicial que motiva a investigação
- Azul médio: pergunta de diagnóstico com resposta verificável na prática
- Vermelho: causa identificada que explica o comportamento observado
- Verde: ação recomendada ou resolução do problema
- Laranja: verificação ou validação intermediária antes de concluir o diagnóstico
Para usar esta árvore diante de um problema real, comece pelo nó raiz descrevendo o sintoma observado: score estagnado ou recomendação que não resolve. Responda cada pergunta de diagnóstico com base no que é observável no portal do Microsoft Defender for Cloud, nos dados coletados e no histórico recente de mudanças. Siga o caminho que corresponde ao estado real do ambiente até alcançar um nó de causa identificada ou uma ação recomendada. Nunca pule níveis de verificação: o distrator mais perigoso em qualquer diagnóstico de Secure Score é agir sobre o sintoma mais visível em vez do mais causalmente relevante.