Microsoft AZ-500: Microsoft Sentinel e Operações de Segurança — Guia de estudos

By Laurynas Brazys · 11 August 2026 · #microsoft #az-500 #certification #exam-prep #study-guide

Faz parte do Microsoft Azure Security Engineer Associate AZ-500 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Microsoft, ou faça testes cronometrados no ExamRoll.io.

Visão Geral

O Microsoft Sentinel é a plataforma SIEM e SOAR nativa da nuvem do Azure, construída sobre o Azure Monitor Log Analytics. Ele centraliza a telemetria de segurança, aplica analytics para detectar ameaças, gera incidentes para triagem por analistas e orquestra respostas automatizadas com o Logic Apps. Operações eficazes dependem de uma arquitetura de workspace bem projetada, onboarding de dados deliberado, retenção consciente dos custos, analytics e mapeamento de entidades precisos, e um regime de automação e ajuste que alinhe os alertas aos fluxos de trabalho do SOC e ao risco de negócio.

Arquitetura e Gerenciamento de Dados do Sentinel

• Workspaces e considerações sobre multilocação (multi-tenant)

  • O Sentinel é executado por workspace do Log Analytics. Escolha os limites do workspace com base na soberania dos dados, latência e isolamento administrativo. Um único workspace de “SOC central” simplifica a correlação e o gerenciamento de conteúdo; múltiplos workspaces podem ser apropriados para residência de dados estrita, autonomia ou modelos MSSP/Lighthouse. Consultas entre workspaces (cross-workspace) são suportadas, mas adicionam latência e custo à consulta; prefira a consolidação quando a correlação entre entidades for crítica.
  • Use o RBAC de contexto de recurso no workspace para separar funções: Sentinel Reader para dashboards, Responder para tratamento de incidentes, Contributor para gerenciamento de conteúdo e Automation Contributor para playbooks.

• Caminhos de ingestão

  • Os dados entram em tabelas no workspace por meio de conectores nativos, agentes do Azure Monitor ou APIs. Prefira conectores nativos para fontes da Microsoft (esquema otimizado, confiabilidade) e AMA+DCR para Windows/Syslog para obter filtragem e controle de plano por tabela. Para dispositivos de terceiros, roteie o CEF sobre Syslog para a tabela CommonSecurityLog para se beneficiar de parsers e conteúdo de analytics integrados.

• Retenção, arquivamento e pesquisa

  • Configure a retenção por tabela para manter dados quentes (hot data, para analytics interativo) pela janela de detecção operacional (geralmente de 30 a 120 dias). Arquive dados mais antigos no nível de Arquivo (Archive tier) do Log Analytics por até 7 anos para atender à conformidade (compliance) a um custo drasticamente menor; use Search Jobs ou Restore para investigações. Raciocínio operacional: retenha apenas aquilo que os analistas usam rotineiramente para investigações (pivot); arquive o restante para atender às necessidades de auditoria/regulamentação sem inflar os gastos com o caminho de acesso rápido (hot-path).

• Controles de custo

  • Níveis de compromisso (reservas de capacidade) reduzem o custo de ingestão de forma previsível para volumes estáveis; habilite-os após estabelecer uma linha de base (baseline) de 30 a 60 dias para evitar comprometimento excessivo (over-commit).
  • Planos de faturamento no nível da tabela: use o modo Analytics para tabelas críticas de segurança (SecurityEvent, SignInLogs, CommonSecurityLog). Use Basic Logs para diagnósticos verbosos e de baixo valor que você consulta com pouca frequência; nunca coloque tabelas de segurança de alto sinal (high-signal) no modo Basic, pois elas perdem recursos completos de consulta e não são elegíveis para alertas.
  • Transformações em tempo de ingestão com DCRs descartam ou mascaram campos e linhas (minimização de PII, redução de ruído) antes da cobrança. Operacionalmente, eliminar o ruído antes da ingestão é o controle de custo e fidelidade mais poderoso.
  • Defina limites diários para o workspace e alertas sobre picos anômalos para detectar configurações incorretas ou ataques que geram tempestades de logs (log storms).

Conectores de Dados e Ingestão

• Azure Activity

  • Use o conector do Azure Activity para transmitir operações do plano de controle (control-plane) no nível da assinatura para a tabela AzureActivity por meio das Configurações de Diagnóstico (Diagnostic settings). Raciocínio: captura alterações de função (role), atualizações de política e implantações — indicadores primários de escalonamento de privilégios ou adulteração por um invasor.

• Microsoft Entra ID (Azure AD)

  • Habilite os conectores AuditLogs e SignInLogs. Opcionalmente, ingira logs Enriched Azure AD se tiver a licença necessária. Raciocínio: a identidade é a principal superfície de ataque; anomalias de login e alterações no diretório sustentam a maioria das detecções e o UEBA.

• Produtos Microsoft Defender

  • Os conectores do Defender for Endpoint, Defender for Office 365, Defender for Identity, Defender for Cloud Apps e Defender for Cloud trazem alertas e telemetria de alta fidelidade. Raciocínio: os alertas de segurança da Microsoft são profundamente correlacionados e elevam a qualidade dos incidentes; ingira-os para potencializar o Fusion e as regras de segurança da Microsoft com ajuste mínimo.

• Eventos do Windows

  • Use o Azure Monitor Agent (AMA) com DCR: Windows Security Events para a tabela SecurityEvent (Common, Minimal ou All) para DCs e servidores críticos; canais gerais de Windows Event para a tabela WindowsEvent conforme necessário. Raciocínio: a tabela SecurityEvent é a espinha dorsal para auditoria de autenticação e processos; a filtragem com DCR reduz o ruído (por exemplo, excluir o evento 4688 sem CommandLine).

• Syslog e CEF

  • Para Linux, o DCR do AMA para Syslog seleciona facilities/severities para a tabela Syslog. Para firewalls/IDS/EDR de terceiros, encaminhe o CEF para o encaminhador baseado em agente do Log Analytics ou para a ingestão baseada em AMA que deposita os dados na tabela CommonSecurityLog; use o conteúdo do parser do fornecedor. Raciocínio: o CEF mantém campos normalizados e reduz a carga de parsing; a tabela CommonSecurityLog desbloqueia detecções pré-construídas.

• Higiene operacional

  • Sincronização de tempo (NTP) e fusos horários consistentes nos dispositivos para uma correlação precisa.
  • Desduplique fontes sobrepostas (por exemplo, não ingira duplicatas brutas e normalizadas).
  • Valide o esquema com Watchlists ou consultas de amostra antes de habilitar o analytics para evitar falsos positivos.

Análise, Detecção e Investigação

• Tipos de regras de análise

  • Regras agendadas (Scheduled): KQL sobre dados históricos em uma cadência (ex: a cada 5 minutos, com lookback de 1 hora). Use para a maioria das detecções; ajuste o lookback para exceder a latência típica dos dados e evitar falhas.
  • Near-real-time (NRT): detecção em menos de um minuto com KQL restrito e um lookback curto e fixo. Use com moderação para padrões de alta urgência onde segundos importam (ex: atribuição de função em massa). Opere com o mínimo de joins e filtros simples para garantir o desempenho.
  • Fusion: correlação de múltiplos estágios orientada por ML entre os sinais da Microsoft (Defender, Entra, Cloud Apps). Justificativa: reduz drasticamente a fadiga de alertas ao produzir um único incidente para uma kill chain de ataque.
  • Regras de anomalia: baselines de usuário/entidade com limiares dinâmicos. Proporcionam ganhos rápidos para padrões incomuns de geolocalização, volume ou processos; mantenha listas de exclusão para anomalias autorizadas (ex: janelas de manutenção).
  • Regras de segurança da Microsoft: criam incidentes automaticamente a partir de alertas do Defender. Mantenha-as ativadas e ajuste as regras de automação para roteamento/severidade; elas fornecem sinais de alta confiança com baixo custo de ajuste.

• Mapeamento de entidades e incidentes

  • Mapeie as colunas de saída do KQL para entidades (Account, Host, IP, URL, File) na configuração da regra para alimentar os grafos de incidentes e o UEBA. Um mapeamento inadequado degrada a fidelidade da investigação.
  • A política de agrupamento de alertas influencia o volume e o contexto dos incidentes. Agrupe por entidades/janela de tempo para combinar alertas relacionados, reduzindo o ruído e preservando a linha do tempo do ataque.

• Investigação e UEBA

  • Os incidentes apresentam a linha do tempo, evidências e entidades relacionadas; o grafo de investigação constrói relacionamentos automaticamente a partir do mapeamento de entidades e consultas de dados.
  • Habilite o UEBA para enriquecer entidades com baselines de pares, funções de dispositivo e sinais de risco. Justificativa: o contexto encurta o tempo de triagem e informa o escopo da resposta.

• Fundamentos de KQL para engenharia de detecção

  • Filtragem e projeção

    SignInLogs
    | where TimeGenerated > ago(24h) and ResultType != 0
    | project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName, ResultType
    ```

  - Análise (parsing) e normalização

CommonSecurityLog
| extend Url = extract(@"request=([^;\s]+)", 1, AdditionalExtensions)
| parse DeviceCustomString1 with * "cmd=" CommandLine
```

• Junção (joining)

    SecurityEvent
    | where EventID == 4624 and AccountType == "User"
    | summarize logons = count() by Account, bin(TimeGenerated, 1h)
    | join kind=inner (
        SignInLogs
        | summarize aad_logons = count() by UserPrincipalName, bin(TimeGenerated, 1h)
    ) on $left.Account == $right.UserPrincipalName, TimeGenerated
    ```

  - Resumo e análise de janela de tempo

SignInLogs
| where TimeGenerated between (ago(1d) .. now())
| summarize attempts = count(), byIP = dcount(IPAddress) by UserPrincipalName
| where attempts > 50 or byIP > 10
```

Caça a Ameaças (Hunting), Automação, Inteligência de Ameaças, Relatórios e Ajuste do SOC

• Fluxo de trabalho de caça a ameaças (threat hunting)

  • Consultas de caça (hunting): comece com os modelos do Sentinel; evolua com listas de permissões (whitelists) específicas do ambiente. Salve pistas promissoras como consultas personalizadas para reutilização.
  • Marcadores (Bookmarks): capture evidências e pontos de pivô durante as caçadas; anexe-os posteriormente a incidentes para preservar o contexto do analista.
  • Livestream: execute um filtro KQL continuamente para identificar eventos assim que eles chegam; ideal durante incidentes ativos para confirmar a contenção.
  • Watchlists: carregue conjuntos de permissão/negação/prioridade baseados em CSV (usuários VIP, IPs sancionados, níveis de ativos). Referencie com a função _GetWatchlist para enriquecimento e supressão.

• Regras de automação e playbooks

  • Regras de automação fazem a triagem na criação de incidentes/alertas: definem a severidade, atribuem um proprietário, adicionam tags, fecham com uma classificação ou acionam playbooks com base em condições (nome da regra, táticas, entidades).
  • Playbooks (Logic Apps) implementam o SOAR: enriquecem com VirusTotal/MDTI, notificam no Teams, abrem tickets (ServiceNow/Jira), isolam endpoints (MDE) ou desabilitam contas (Entra). Use identidades gerenciadas e RBAC de privilégio mínimo (Sentinel Responder no workspace; funções de escopo limitado para os sistemas de destino). Justificativa: ações codificadas e repetíveis reduzem o MTTR e o erro manual.

• Inteligência de ameaças (TI)

  • Ingira indicadores de TI usando provedores integrados, upload manual, automação do GitHub ou coletores TAXII (STIX 2.0/2.1). Normalize os campos (tipo de indicador, padrão, confiança, TLP) e defina uma expiração para evitar correspondências obsoletas.
  • Correspondência de indicadores: habilite regras analíticas baseadas em TI para corresponder IP/domínio/URL/hash com a telemetria (CommonSecurityLog, DNS, Proxy, SignInLogs). Use limiares de confiança e exceções de watchlist para reduzir o ruído. Justificativa: a TI restringe o espaço de busca a ameaças conhecidas, mas deve ser curada para evitar falsos positivos.

• Workbooks e relatórios

  • Crie dashboards operacionais com Azure Monitor Workbooks. Parametrize por assinatura, workspace ou intervalo de tempo; sumarize os dados o mais cedo possível (summarize, make-series) para manter as consultas eficientes.
  • Forneça visualizações em camadas: postura executiva (incidentes por severidade/SLA), operações do SOC (abertos vs. fechados, envelhecimento da fila, carga de trabalho do analista), saúde das detecções (status do conector, latência de dados) e cobertura de controles (mapeamento MITRE). Justificativa: visualizações específicas da função apoiam a tomada de decisão sem sobrecarregar os usuários com eventos brutos.

• Ajuste (tuning) e procedimentos do SOC

  • Redução de falsos positivos: refine os predicados KQL, adicione baselines (limiares dinâmicos), utilize listas de permissões de entidades (watchlists) e exclua fontes benignas. Valide cada supressão com um controle compensatório.
  • Normalização de severidade: mapeie a severidade da regra para impacto e confiança, não para frequência. Alta deve implicar em acionar o plantonista; Média para triagem imediata; Baixa para caça no backlog.
  • Escalonamento e transferência: defina estados de incidente, proprietários e SLAs; enriqueça e roteie automaticamente para a fila correta; abra tickets de ITSM via playbooks com atualizações bidirecionais. Documente os passos de contenção para cada tática (desabilitar usuário, isolar endpoint, revogar tokens, bloquear indicadores).

Cenário de Problema Prático

A Contoso Ltd. está sofrendo com fadiga de alertas e lentidão na resposta após integrar múltiplas fontes de dados ao Microsoft Sentinel. Os incidentes são numerosos, mal agrupados e carecem de automação. O CISO exige uma redução de 50% no tempo médio de resposta (MTTR) sem perder a fidelidade da detecção.

1. Rearquitetar a ingestão de dados com filtragem por DCR e planos de tabela

• Ação: Mover os Windows Security Events para AMA+DCR com a predefinição “Common” nos DCs; alterar tabelas de diagnóstico detalhadas para Basic Logs; habilitar 90 dias de retenção quente (hot) e 1 ano de arquivamento.
• Justificativa: Reduz o ruído e o custo do caminho quente (hot path) enquanto preserva dados de segurança acionáveis, liberando ciclos analíticos e orçamento para detecções de maior fidelidade.

2. Habilitar os conectores do Microsoft Defender e o Fusion

• Ação: Conectar MDE, MDI, MDO, MDC e Cloud Apps; garantir que as análises de segurança da Microsoft e o Fusion estejam ativados.
• Justificativa: Alertas de alta confiança e a correlação por ML consolidam alertas duplicados em um único incidente rico, reduzindo a carga de trabalho da triagem.

3. Padronizar o mapeamento de entidades e o agrupamento de alertas

• Ação: Atualizar as regras agendadas para mapear Conta, Host, IP e URL; configurar o agrupamento por Conta e uma janela de 4 horas para alertas relacionados.
• Justificativa: O mapeamento adequado alimenta os gráficos de investigação e o UEBA; o agrupamento diminui o volume de incidentes enquanto preserva o contexto para cadeias de ataque.

4. Implementar regras de automação para triagem e playbooks direcionados

• Ação: Criar regras de automação para adicionar tags automaticamente por tática, definir a severidade com base na confiança, atribuir a filas e acionar playbooks: enriquecer indicadores (MDTI), abrir tickets no ServiceNow, isolar dispositivos (MDE) e suspender usuários de risco (Entra) com aprovação.
• Justificativa: A triagem determinística mais as ações de SOAR encurtam o MTTR e padronizam as respostas; as aprovações impõem mecanismos de proteção (guardrails) para ações de alto impacto.

5. Introduzir watchlists e correspondência de TI com curadoria

• Ação: Construir watchlists de usuários VIP e serviços sancionados; adicionar um feed TAXII curado com confiança >= 70 e expiração de 7 dias; habilitar regras de correspondência de TI contra proxy/DNS.
• Justificativa: Prioriza alvos de alto valor e usa TI recente e confiável para focar as investigações e reduzir falsos positivos.

6. Publicar workbooks baseados em função e SLAs

• Ação: Criar workbooks para executivos, operações do SOC e saúde das detecções; definir SLAs de incidentes (Alta 4h, Média 24h, Baixa 3d) e relatar violações.
• Justificativa: Visibilidade e responsabilidade impulsionam a disciplina operacional; dashboards direcionados evitam a troca de contexto e o esforço desperdiçado.

7. Estabelecer uma cadência de ajuste (tuning) contínuo

• Ação: Revisão semanal de incidentes fechados como falso positivo; ajustar regras, supressões e exclusões com justificativas documentadas; monitorar anomalias de ingestão e o desempenho das consultas.
• Justificativa: As operações de segurança perdem o rumo sem ciclos de feedback; o refinamento contínuo mantém a qualidade do sinal à medida que o ambiente evolui.

Ao executar esses passos, a Contoso alinha as detecções ao risco do negócio, reduz o ruído na origem e automatiza tarefas repetitivas — alcançando uma resposta a incidentes mais rápida e consistente sem sacrificar a cobertura.

← Gerenciamento da Postura de Segurança e Governança · Todos os domínios · Segurança de Aplicações e DevSecOps →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →

Navegar Microsoft →