Microsoft AZ-801: Microsoft Sentinel e Monitoramento de Segurança — Guia de estudos

By Laurynas Brazys · 7 August 2026 · #microsoft #az-801 #certification #exam-prep #study-guide

Faz parte do Microsoft Windows Server Hybrid Administrator Associate AZ-801 — 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 é uma solução SIEM e SOAR nativa da nuvem que unifica a ingestão de logs, analytics, detecção de ameaças, resposta a incidentes e hunting proativo em ambientes híbridos do Windows Server. Para os cenários do AZ-801, o domínio envolve conectar fontes de Windows Security Events, Syslog do Linux e CEF de terceiros em escala, projetar analytics com latência mínima, mapear alertas para entidades para uma investigação precisa e automatizar a contenção por meio de playbooks baseados em Logic Apps. O sucesso também depende de uma arquitetura disciplinada de workspaces do Log Analytics, Regras de Coleta de Dados (DCRs) bem governadas para o Azure Monitor Agent (AMA), uma estratégia de retenção sólida e proficiência operacional em UEBA, watchlists, hunting e workbooks.

Conectores e Ingestão de Dados

Os Windows Security Events via AMA são a fonte canônica para eventos de logon, criação de processos, alteração de políticas e outros eventos de auditoria do Windows Server. Habilite o conector “Windows Security Events via AMA” no Microsoft Sentinel e crie uma DCR que selecione os conjuntos de eventos apropriados para o seu perfil de risco (Minimal, Common ou All, ou uma seleção personalizada por ID de Evento). Os dados são armazenados principalmente na tabela SecurityEvent; canais do Windows que não são de segurança (se habilitados) são armazenados na WindowsEvent. Combine com a Group Policy para garantir que a linha de base de Segurança e as subcategorias de auditoria (por exemplo, Logon/Logoff, Account Logon, Object Access, DS Access) estejam habilitadas nos servidores de origem para gerar a telemetria necessária.

O Syslog via AMA coleta dados de servidores Linux e dispositivos de rede que utilizam o protocolo Syslog. Instale o AMA em hosts Linux (ou em um coletor Linux dedicado) e configure uma DCR para especificar as facilities e severidades a serem ingeridas. Os eventos são gravados na tabela Syslog. Para facilities de alto volume mas baixo valor, considere a coleta seletiva ou a transformação na origem para controlar custos e ruído.

O CEF via AMA permite a ingestão de logs de segurança normalizados de produtos de segurança de terceiros (firewalls, IDS/IPS, proxies, EDR). Implante o AMA em um coletor Linux e configure seus fornecedores para encaminhar o CEF para o daemon syslog local (rsyslog/syslog-ng), normalmente nas portas 514/UDP ou TCP. No Sentinel, habilite o conector de dados “CEF via AMA” e vincule o host por meio de uma DCR que faz o parsing do CEF. Os dados analisados (parsed) entram na tabela CommonSecurityLog com um esquema consistente (campos deviceVendor, deviceProduct, destination/source e atributos de extensão), simplificando a análise e correlação entre diferentes fornecedores.

Para servidores Windows Server on-premises, use servidores habilitados para o Azure Arc para fazer a ponte com o Azure. Faça o onboarding das máquinas com o agente do Azure Connected Machine e, em seguida, implante a extensão do AMA via Azure Policy para obter escala. Crie DCRs direcionadas a escopos de servidores Arc para rotear Windows Security Events, logs do Firewall do Windows e, se estiver usando o Sysmon, uma DCR personalizada para o canal Microsoft-Windows-Sysmon/Operational. Esse padrão centraliza a configuração, o versionamento e o direcionamento baseado em escopo, garantindo uma ingestão consistente sem trabalho manual por host.

Arquitetura de Workspace e Ciclo de Vida dos Dados

O Sentinel se conecta a um único workspace do Log Analytics por implantação. O design do workspace deve minimizar a latência e o egresso entre regiões — colocalize os workspaces com a maioria dos produtores de dados e evite a fragmentação excessiva que complica as consultas, a triagem de incidentes e o RBAC. Padrões comuns são um único workspace de segurança por tenant ou um por região principal onde a residência de dados e a latência exigem separação. Use o acesso de contexto de recurso sempre que possível para garantir que as equipes possam consultar logs dos recursos que possuem sem permissões amplas no workspace, enquanto as funções do Sentinel (Reader, Responder, Contributor) governam as operações do SOC.

As DCRs governam quais tipos de telemetria, canais e conjuntos de eventos são coletados e para onde são enviados. Trate as DCRs como código: padronize a nomenclatura, os controles de versão e os escopos (assinaturas, grupos de recursos, tags). Agrupe fontes e destinos relacionados e prefira várias DCRs direcionadas em vez de uma única regra monolítica para simplificar o raio de impacto (blast radius) e o gerenciamento do ciclo de vida. Quando os volumes de syslog e CEF forem altos, considere DCRs separadas para ajustar facility/severity de forma independente e para suportar testes em estágios.

A retenção e o custo são controlados no nível da tabela. Defina a retenção padrão do workspace para atender à política (por exemplo, 90 a 180 dias para pesquisa ativa) e, em seguida, substitua a retenção por tabela quando necessário. Tabelas de alto valor (SecurityEvent, CommonSecurityLog, SecurityAlert) normalmente têm uma retenção mais longa; tabelas verbosas (Syslog com DEBUG) podem ter uma retenção menor. Use o archive para armazenamento de longo prazo e baixo custo com trabalhos de pesquisa (search jobs); promova para o nível ‘hot’ conforme necessário para investigações. Onde apropriado, mova algumas tabelas verbosas (como a Syslog) para Logs Básicos para reduzir custos, reconhecendo as limitações de consulta e que certas tabelas de segurança (por exemplo, SecurityEvent) não são elegíveis para o nível Básico. Revise regularmente os limites de dados, os níveis de compromisso (commitment tiers) e as tendências de ingestão para evitar throttling e otimizar os custos.

Análise, Incidentes e Automação de Resposta

Regras de análise são o motor da detecção. Regras de consulta agendada executam KQL em um cronograma (por exemplo, a cada 5 minutos) sobre um período retroativo (por exemplo, 30 minutos), suportando agregações, junções, enriquecimentos com watchlists e janelas de supressão. Elas são ideais para padrões bem compreendidos, como múltiplas falhas de logon seguidas por um sucesso, heurísticas de movimento lateral ou linhagem de processos suspeitos. Regras near-real-time (NRT) minimizam a latência de detecção processando continuamente novos dados com execuções aproximadamente a cada minuto e alertando em cerca de dois minutos; projete regras NRT para serem concisas e dependerem de ingestion_time() ou janelas estreitas para evitar varreduras históricas pesadas. Regras Fusion usam a análise de ataques multiestágio da Microsoft para correlacionar alertas de baixo sinal entre produtos (por exemplo, Defender for Endpoint, Defender for Identity, Entra ID Protection, CEF de terceiros) em incidentes de alta fidelidade para campanhas como roubo de credenciais ou ransomware. Regras de anomalia utilizam modelos de ML integrados que aprendem baselines (por exemplo, locais de login incomuns, execução de processos raros) e emitem desvios; estas comumente leem de BehaviorAnalytics e outras fontes normalizadas.

Incidentes unificam múltiplos alertas, entidades e evidências sob um único caso investigativo. A severidade é atribuída pela regra de análise (ou dinamicamente pelo Fusion) e pode ser escalada ou reduzida por meio de regras de automação. O mapeamento de entidades é crítico para a eficácia da investigação: no assistente de regras, mapeie as colunas da consulta para os tipos de entidade (Account, Host, IP, URL, File, Process, CloudApplication, AzureResource). O mapeamento adequado preenche o grafo de investigação, que visualiza relacionamentos entre alertas, eventos e entidades, permitindo pivotar em contas, hosts, processos e IPs. Use comentários, tags, proprietário e classificação para capturar a disposição do analista e para treinar fluxos de trabalho de ajuste.

A automação combina regras de automação e Playbooks. Regras de automação avaliam metadados de incidentes na criação ou atualização para atribuir proprietários, alterar a severidade, adicionar tags, fechar falsos positivos ou invocar playbooks. Playbooks são Azure Logic Apps construídos com os conectores do Microsoft Sentinel. Playbooks acionados por incidentes reagem a eventos do ciclo de vida do incidente (por exemplo, quando um incidente é criado) e são adequados para ações no escopo do incidente, como notificar uma equipe, enriquecer todas as entidades ou criar um ticket no ServiceNow. Playbooks acionados por alertas disparam em alertas únicos antes de serem agrupados em um incidente — útil para enriquecimentos específicos do fornecedor ou pré-triagem. Adote identidade gerenciada para playbooks, conceda o menor privilégio via Azure RBAC e permissões de API, e parametrize IDs de workspace, endpoints de emissão de tickets e caminhos de listas de bloqueio para promover o reuso. Onde a contenção for justificada, inclua ações que coloquem endpoints em quarentena (Defender for Endpoint), desabilitem contas (Entra ID), bloqueiem IPs (firewalls) ou revoguem sessões (Conditional Access) somente após os limites de confiança serem atingidos.

Operações de Segurança Proativas (Hunting, UEBA, Watchlists, Workbooks)

O threat hunting (caça a ameaças) no Sentinel depende da proficiência em KQL e da lâmina de hunting. Comece com as consultas de hunting integradas, organizadas por tática; personalize-as para o seu ambiente referenciando tabelas como SecurityEvent (auditoria do Windows), tabelas Device* do Defender, CommonSecurityLog (CEF) e SigninLogs (Entra). Use bookmarks (marcadores) para registrar eventos interessantes, anotá-los e compartilhar o contexto com a equipe; vários bookmarks podem ser promovidos para um incidente novo ou existente. O Livestream executa continuamente um padrão KQL para detectar novos eventos correspondentes quase em tempo real — ideal para investigações com prazo definido ou cenários de picos rápidos de atividade. Converta consultas de hunting maduras em regras de análise agendadas para operacionalizar as detecções.

O UEBA (User and Entity Behavior Analytics) enriquece a detecção com baselines (linhas de base) comportamentais e pontuação de anomalias. Habilite o UEBA na configuração do Sentinel e garanta que as fontes de dados de identidade e atividade (logons do Microsoft Entra, Defender for Endpoint, Defender for Identity, atividade do M365) estejam conectadas. As páginas de entidade para usuários e hosts exibem cronogramas, comparações com pares, atividades anômalas (geolocalização de logon rara, processo incomum) e pontuações de risco agregadas. Os analistas podem pivotar de incidentes para páginas de entidade para avaliar se uma ação é típica para aquela identidade ou dispositivo; as pontuações e sequências de anomalias ajudam a priorizar a triagem e a corroborar ou refutar hipóteses rapidamente.

As Watchlists (listas de observação) fornecem dados de referência rápidos e mantidos por analistas. Crie watchlists a partir de uploads de CSV ou de um caminho de conta de armazenamento, defina um alias e selecione uma coluna-chave para pesquisas eficientes. Use a função watchlist() em KQL para joins — os usos comuns incluem listas de permissão/negação (allow/deny lists) de contas administrativas, hosts sensíveis, domínios sancionados ou usuários VIP. Incorpore watchlists em regras de análise para suprimir atividades conhecidas como benignas (reduzir falsos positivos) ou para elevar a severidade quando uma correspondência envolve um ativo crítico. Integre com inteligência de ameaças (threat intelligence) juntando watchlists à tabela ThreatIntelligenceIndicator para obter contexto (por exemplo, enriquecer IPs detectados com severidade interna ou notas de caso), ou convertendo feeds de TI selecionados em uma watchlist para referência rápida e substituições (overrides).

Os Workbooks (pastas de trabalho) potencializam o monitoramento e a visibilidade executiva. Comece com os templates integrados, como Security Operations Efficiency, Active Directory Sign-ins, Fusion Detections e UEBA insights. Crie workbooks personalizados usando consultas KQL, parâmetros e visualizações para criar dashboards de SOC para a saúde da ingestão, desempenho de regras, SLAs de incidentes e ameaças emergentes. Aplique RBAC no recurso do workbook e parametrize assinaturas, workspaces e intervalos de tempo para que o mesmo workbook possa atender a diferentes equipes. Combine blocos (tiles) de várias tabelas para correlacionar a postura (Defender for Cloud), as detecções (Sentinel) e as métricas de resposta em uma única exibição.

Cenário de Problema Prático

O Spotify precisa centralizar o monitoramento de segurança para 2.000 Windows Servers distribuídos entre o Azure e data centers on-premises, além de firewalls e proxies de terceiros. Eles precisam de detecções de baixa latência para abuso de credenciais, abertura de tickets e contenção automatizadas, e dashboards e fluxos de trabalho de hunting claros para o SOC.

1. Fazer o onboard de servidores híbridos com o Azure Arc e o AMA

• Implante o onboard de servidores habilitados para Azure Arc em escala usando o Azure Policy e, em seguida, atribua a política de extensão do AMA ao escopo do Arc. Crie DCRs para “Windows Security Events via AMA” (conjunto Comum), Windows Firewall e uma DCR personalizada para o Sysmon, onde estiver instalado. Essa abordagem fornece uma coleta consistente e gerenciada centralmente, sem a necessidade de scripts por host, e garante que a tabela SecurityEvent seja preenchida para análises de identidade e processos.

2. Ingerir telemetria de rede e de appliances de segurança via Syslog e CEF

• Provisione uma VM coletora Linux com o AMA. Configure o “Syslog via AMA” para as facilities relevantes e habilite o “CEF via AMA” para analisar (parse) os dados CEF do firewall e do proxy na tabela CommonSecurityLog. O uso do CEF normaliza dados de múltiplos fornecedores, permitindo a portabilidade de regras e joins fáceis entre diferentes fontes.

3. Projetar análises para velocidade e fidelidade

• Habilite o Fusion para capturar ataques de múltiplos estágios com o mínimo de ajuste (tuning). Crie regras NRT para picos de logons com falha seguidos por um sucesso em contas privilegiadas, usando SecurityEvent e ingestion_time(), proporcionando detecção em menos de dois minutos. Crie regras agendadas para padrões de movimento lateral (por exemplo, criação de processo de net.exe em servidores associada a contas de administrador incomuns) e para anomalias de saída (egress) de proxy combinadas com watchlists de VIPs e de hosts críticos (crown-jewel). Essa combinação minimiza o MTTR enquanto controla os falsos positivos.

4. Mapear entidades e modelar incidentes

• Em cada regra agendada, mapeie as entidades de Conta (Account), Host, IP e Processo (Process) a partir das colunas da consulta. Use regras de automação para atribuir incidentes por unidade de negócio (derivado das tags do host), padronizar a severidade, adicionar tags do MITRE e fechar automaticamente sinais de teste conhecidos. O mapeamento adequado permite que o grafo de investigação mostre relacionamentos pelos quais os analistas do Spotify podem pivotar rapidamente.

5. Automatizar enriquecimento, abertura de tickets e contenção com playbooks

• Crie um playbook acionado por incidente que enriqueça todas as contas e hosts (consultas no grafo, risco do dispositivo), poste no Teams e abra um ticket no Jira. Um playbook separado, acionado por alerta, enriquece alertas CEF específicos com APIs de fornecedores. Use identidades gerenciadas com RBAC de privilégio mínimo e ramificação condicional que só isola dispositivos (via Defender for Endpoint) ou desabilita usuários (via Entra ID) quando os limiares de confiança (por exemplo, múltiplos alertas corroborantes e alta pontuação de UEBA) são atingidos. Isso preserva a continuidade dos negócios ao mesmo tempo que permite uma resposta rápida e governada.

6. Habilitar o UEBA e operacionalizar o hunting

• Ative o UEBA e valide as fontes de dados (SigninLogs, atividade do M365, sinais do Defender). Treine os analistas para pivotar de incidentes para as páginas de entidade para consultar pontuações de anomalia e comparações com pares. Converta duas consultas de hunting de alto valor — “Novas ferramentas de administração remota em servidores” e “Padrões raros de exfiltração para IPs externos” — em análises agendadas, uma vez validadas via bookmarks e livestream. O UEBA, somado a um hunting disciplinado, aprimora a detecção de técnicas novas.

7. Governar o ciclo de vida dos dados e visualizar a postura

• Defina a retenção para 180 dias para SecurityEvent e CommonSecurityLog, 30 dias para Syslog detalhado (verbose) com arquivamento por 1 ano, e monitore os custos com os commitment tiers (níveis de compromisso). Publique um workbook de SOC personalizado que acompanhe a saúde da ingestão, as regras mais ruidosas (top noisy rules), MTTA/MTTR, filas de incidentes por severidade e anomalias de UEBA ao longo do tempo. Isso fornece transparência para a liderança e impulsiona o ajuste contínuo.

Cada ferramenta foi escolhida por sua força específica para o propósito: Arc e AMA+DCR entregam uma ingestão escalável e orientada por políticas; o CEF garante logs de segurança normalizados de múltiplos fornecedores; Fusion e NRT reduzem a latência de detecção sem ajuste excessivo; o mapeamento de entidades e o grafo de investigação aceleram a triagem; os playbooks fornecem automação governada e baseada em identidade; o UEBA fornece contexto comportamental; as ferramentas de hunting amadurecem as detecções; e os workbooks mantêm as operações mensuráveis e visíveis.

← Microsoft Defender for Cloud e Segurança de Endpoint · Todos os domínios · Segurança do Active Directory Domain Services →

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

Navegar Microsoft →