Última revisão: maio de 2026
Uma referência rápida dos padrões arquiteturais que o exame SC-200 avalia. Leia de cima a baixo ou pule para uma seção.
Requisitos rigorosos de residência de dados em várias regiões geográficas.
Implantar vários workspaces do Microsoft Sentinel, um por região. Usar o Azure Lighthouse para gerenciamento centralizado.
Por quê: Mantém os dados de log dentro dos limites geográficos para conformidade, ao mesmo tempo em que permite que um SOC central opere em todos os workspaces.
Workspace do Sentinel ingerindo mais de 100 GB de dados por dia.
Mudar o nível de preço do workspace do Log Analytics de Pagamento Conforme o Uso para Níveis de Compromisso.
Por quê: Os Níveis de Compromisso oferecem economias significativas de custos para ingestão de dados previsível e de alto volume em comparação com os preços padrão.
Logs de alto volume (por exemplo, Eventos de Segurança do Windows) estão aumentando os custos do SIEM.
1. Usar uma Regra de Coleta de Dados (DCR) para filtrar eventos na origem. 2. Configurar a tabela de destino para Logs Básicos.
Por quê: DCRs reduzem os custos de ingestão coletando apenas os eventos necessários. Os Logs Básicos reduzem os custos de armazenamento para dados verbosos que não exigem análise completa.
A conformidade exige retenção de dados por mais de 2 anos (por exemplo, 7 anos).
Configurar o workspace com retenção interativa de 90 dias e retenção total de 7 anos (camada de arquivo).
Por quê: Equilibra a capacidade de pesquisa imediata (interativa) com armazenamento de baixo custo e longo prazo (arquivo). Acessar dados arquivados via Search Jobs.
Coletar eventos de segurança de servidores Windows e Linux on-premises.
Instalar o agente do Azure Arc para gerenciamento e, em seguida, implantar o Azure Monitor Agent (AMA) via Arc.
Por quê: O Arc estende o plano de controle do Azure para ambientes on-premises, permitindo gerenciamento nativo e coleta de dados com o moderno agente AMA.
Ingerir logs de dispositivos de terceiros (por exemplo, firewalls) que suportam Syslog.
Implantar uma VM Linux dedicada como um Log Forwarder com o AMA. Usar o formato CEF para dados de segurança estruturados.
Por quê: Centraliza a coleta para dispositivos que não podem hospedar um agente. O CEF fornece um esquema normalizado e consultável para eventos de segurança.
Ingerir incidentes e alertas do Microsoft Defender XDR no Sentinel.
Habilitar o conector de dados do Microsoft Defender XDR e sua opção de criação de incidentes/sincronização bidirecional.
Por quê: Cria uma fila unificada de incidentes e garante que as mudanças de status sejam sincronizadas entre o Sentinel e o portal do Defender.
Filtrar IDs de Eventos do Windows específicos na origem para reduzir o volume de ingestão.
Configurar uma Regra de Coleta de Dados (DCR) com uma consulta XPath para especificar quais IDs de Evento coletar.
Por quê: Reduz o volume e o custo de ingestão filtrando dados no agente de origem, antes que sejam enviados para o workspace.
Exigir o tempo de detecção mais rápido possível para eventos críticos.
Usar uma regra de análise Quase em Tempo Real (NRT).
Por quê: As regras NRT são executadas a cada minuto, oferecendo latência de detecção de ~1-2 minutos, muito mais rápido do que o mínimo de 5 minutos para regras agendadas.
Detectar um limiar de eventos dentro de uma janela de tempo específica (por exemplo, ataques de força bruta).
Criar uma regra de análise Agendada usando KQL `summarize ... by bin(TimeGenerated, 5m), ...`.
Por quê: A função `bin()` é crítica para agrupar eventos em janelas de tempo discretas e não sobrepostas para detecção precisa de limiares.
Detectar ataques complexos e de várias etapas que alertas individuais podem não detectar.
Habilitar regras de análise Fusion para detecção avançada de ataques multiestágio.
Por quê: O Fusion usa ML para correlacionar sinais de baixa fidelidade de múltiplas fontes de dados em incidentes de alta confiança, reduzindo a fadiga de alertas.
Detectar ameaças internas ou contas comprometidas com base em comportamento anômalo.
Habilitar Análise de Comportamento de Usuário e Entidade (UEBA).
Por quê: UEBA estabelece linhas de base comportamentais para usuários e entidades, e então sinaliza desvios significativos que não correspondem a lógicas de regras específicas.
Escrever uma única regra de análise agnóstica à fonte para múltiplas fontes de dados (por exemplo, DNS de vários fornecedores).
Usar parsers do Advanced Security Information Model (ASIM) na consulta KQL.
Por quê: O ASIM fornece um esquema normalizado, permitindo que as consultas sejam executadas contra uma visão unificada (por exemplo, `imDns`) em vez de várias tabelas específicas do fornecedor.
Gerenciar o conteúdo do Sentinel (regras de análise, pastas de trabalho) como código e implantar em diferentes ambientes.
Usar Repositórios do Microsoft Sentinel para conectar um repositório GitHub ou Azure DevOps.
Por quê: Habilita fluxos de trabalho de CI/CD, controle de versão e implantação automatizada e consistente de conteúdo de segurança (Sentinel-as-Code).
Automatizar tarefas básicas de triagem de incidentes, como atribuir proprietários, alterar status ou adicionar tags.
Usar uma Regra de Automação acionada na criação de incidentes.
Por quê: As regras de automação são leves e síncronas, ideais para ações de triagem simples sem a sobrecarga de um Logic App.
Automatizar respostas complexas a incidentes envolvendo sistemas externos (por exemplo, bloquear usuário no Entra ID, enviar mensagem no Teams).
Criar um Playbook (Azure Logic App) e acioná-lo a partir de uma Regra de Automação.
Por quê: Logic Apps fornecem o motor de orquestração e os conectores necessários para respostas e integrações complexas de várias etapas.
Compreender o escopo de um ataque visualizando relacionamentos entre entidades (usuários, IPs, hosts).
Usar o Grafo de Investigação na página de detalhes do incidente.
Por quê: Fornece um mapa interativo do ataque, facilitando a visualização de conexões e a alternância entre entidades e alertas relacionados.
Padronizar e acelerar fluxos de trabalho de investigação comuns para a equipe do SOC.
Criar e compartilhar um Promptbook no Microsoft Security Copilot.
Por quê: Promptbooks encadeiam uma série de prompts de linguagem natural para criar um processo de investigação guiado e repetível para cenários comuns.
Gerenciar permissões de segurança centralmente para todos os produtos Microsoft Defender.
Ativar o modelo RBAC Unificado do Microsoft Defender XDR.
Por quê: Substitui funções individuais específicas do produto por um modelo de permissão único e granular, simplificando a administração.
Isolar automaticamente dispositivos ou remediar arquivos com base na severidade do alerta.
Configurar as configurações de investigação automatizada para grupos de dispositivos, definindo o Nível de Automação para 'Completo' ou 'Semi'.
Por quê: Permite a remediação sem intervenção para ameaças comuns. Os grupos de dispositivos permitem diferentes níveis de automação para estações de trabalho versus servidores críticos.
Bloquear imediatamente um hash de arquivo malicioso conhecido, endereço IP ou URL em todos os endpoints.
Criar um Indicador de Compromisso (IoC) com uma ação de "Bloquear e Remediar".
Por quê: Fornece um mecanismo de contenção rápido e em toda a organização, mais rápido do que esperar por atualizações de assinatura de AV.
Reforçar endpoints bloqueando técnicas de ataque comuns (por exemplo, Office criando processos filhos).
Implantar regras de Redução da Superfície de Ataque (ASR), começando no modo 'Auditoria' para avaliar o impacto antes de mudar para 'Bloquear'.
Por quê: As regras ASR são um controle preventivo chave. O modo de auditoria é crítico para prevenir interrupções em aplicações de negócios durante a implementação.
Realizar investigação forense profunda ou remediação manual em um endpoint ativo.
Usar o recurso de Resposta ao Vivo para estabelecer um shell remoto e coletar pacotes forenses.
Por quê: Fornece acesso direto e em tempo real ao dispositivo para executar comandos, coletar arquivos e executar scripts forenses.
Reconstruir as ações de um atacante em um dispositivo comprometido específico.
Analisar a Linha do Tempo do Dispositivo.
Por quê: Fornece um log de eventos detalhado e cronológico de todas as atividades de processo, rede, arquivo e registro no endpoint.
Detectar roubo de credenciais e técnicas de movimento lateral como Pass-the-Hash/Ticket.
Implantar sensores do Microsoft Defender for Identity em todos os Controladores de Domínio.
Por quê: O Defender for Identity monitora diretamente o tráfego de autenticação do AD on-premises, fornecendo alertas de alta fidelidade para ataques baseados em identidade.
Proteger usuários contra malware de dia zero incorporado em anexos de e-mail.
Configurar uma política de Anexos Seguros com a opção de Entrega Dinâmica.
Por quê: Detona anexos em um sandbox para verificar comportamento malicioso enquanto entrega o corpo do e-mail imediatamente, equilibrando segurança e produtividade.
Encontrar e remover todas as instâncias de um e-mail de phishing das caixas de correio dos usuários.
Usar o Threat Explorer (ou Advanced Hunting) para buscar o e-mail e executar uma ação de exclusão suave ou forçada.
Por quê: O Threat Explorer é uma ferramenta poderosa de busca e remediação para eliminar ameaças ativas do sistema de e-mail em toda a organização.
Prevenir a exfiltração de dados bloqueando downloads de arquivos sensíveis para dispositivos não gerenciados (não conformes).
Configurar uma política de sessão do Defender for Cloud Apps usando o Controle de Aplicativos de Acesso Condicional.
Por quê: Atua como um proxy reverso para inspecionar e controlar a atividade do usuário em tempo real dentro de uma sessão de aplicativo em nuvem, aplicando políticas de acesso a dados.
Conter automaticamente um ataque ativo e generalizado, como ransomware operado por humanos.
Habilitar a Interrupção Automática de Ataques no Microsoft Defender XDR.
Por quê: Usa sinais de domínio cruzado (XDR) para tomar ações decisivas na velocidade da máquina, como desativar contas de usuário comprometidas e isolar dispositivos.
Buscar proativamente por ameaças em todos os dados XDR (endpoint, e-mail, identidade, aplicativos em nuvem).
Usar o Advanced Hunting com Kusto Query Language (KQL).
Por quê: Fornece uma interface poderosa baseada em consultas para buscar em 30 dias de telemetria bruta, permitindo a descoberta de ameaças que evadem detecções padrão.
Compreender rapidamente o escopo completo de um incidente complexo envolvendo múltiplos alertas e entidades.
Analisar a História do Ataque ou o Grafo de Investigação do incidente.
Por quê: Consolida e visualiza toda a cadeia de ataque, mostrando como um atacante se moveu de um ponto de entrada inicial através de diferentes ativos.
Estender as proteções de carga de trabalho do Defender for Cloud para servidores on-premises e multi-nuvem.
Integrar os servidores usando o Azure Arc e, em seguida, habilitar o plano Defender for Servers.
Por quê: O Azure Arc atua como uma ponte do plano de controle, projetando recursos não-Azure no Azure para que possam ser gerenciados e protegidos pelo Defender for Cloud.
Compreender rapidamente o propósito e a potencial maliciosidade de um script complexo (por exemplo, PowerShell).
Colar o script no Security Copilot e solicitar uma análise de sua função e risco.
Por quê: Aproveita a IA generativa para desofuscar e explicar o código, acelerando significativamente a análise de artefatos sem executar o script.
Conter imediatamente uma conta de usuário comprometida que é sincronizada do AD on-premises.
Desabilitar a conta no Active Directory on-premises e, em seguida, acionar uma sincronização imediata do AD Connect.
Por quê: Para identidades sincronizadas, o AD on-premises é a fonte de autoridade. Desabilitar a conta lá é a ação de contenção mais eficaz.
Ingerir inteligência de ameaças externa de um TIP usando um protocolo padrão da indústria.
Usar o conector de dados 'Inteligência de Ameaças - TAXII' no Sentinel.
Por quê: Conecta-se a servidores TAXII 2.x para importar automaticamente indicadores formatados em STIX, operacionalizando a inteligência de ameaças.
Correlacionar indicadores de ameaças conhecidas (IPs, domínios, hashes) com todas as fontes de log ingeridas.
Ingerir indicadores na tabela ThreatIntelligenceIndicator e habilitar as regras de análise "TI map..." integradas.
Por quê: Essas regras combinam eficientemente a inteligência de ameaças com campos de entidade normalizados nos logs para gerar alertas sobre atividades maliciosas conhecidas.
Usar uma lista personalizada de indicadores (por exemplo, IPs de parceiros de negócios, contas de funcionários demitidos) para alertas ou enriquecimento.
Criar uma Watchlist e uni-la com dados em consultas KQL.
Por quê: Watchlists atuam como um simples armazenamento de chave-valor para dados personalizados, facilmente usados em consultas para lógica de detecção ou para reduzir falsos positivos.
Uma consulta de hunting KQL bem-sucedida precisa ser salva e operacionalizada para detecção automática.
1. Salvar a consulta na lâmina de Hunting. 2. Promover a consulta de hunting para uma Regra de Análise agendada.
Por quê: Formaliza a transição da descoberta ad-hoc (hunting) para a detecção automatizada e repetível (regra de análise).
Avaliar a cobertura de detecção e identificar lacunas com base na estrutura MITRE ATT&CK.
Usar a lâmina MITRE ATT&CK no Sentinel. Marcar regras de análise com táticas/técnicas relevantes.
Por quê: Fornece um mapa de calor visual das capacidades de detecção mapeadas contra a estrutura padrão da indústria, orientando a engenharia de detecção.
Preservar resultados interessantes ou evidências encontradas durante uma caçada para acompanhamento posterior.
Criar um Marcador de Hunting a partir dos resultados da consulta KQL.
Por quê: Captura a consulta, os resultados e o contexto da entidade, permitindo que um analista salve as descobertas sem criar imediatamente um incidente completo.