Microsoft AZ-801: Microsoft Sentinel 和安全监控 — 学习指南

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

属于 Microsoft Windows Server Hybrid Administrator Associate AZ-801 — 学习指南. 使用经过验证的答案练习： Microsoft 考试中心, 或参加限时模拟考试： ExamRoll.io.

概述

Microsoft Sentinel 是一款云原生 SIEM 和 SOAR，它统一了混合 Windows Server 环境中的日志引入、分析、威胁检测、事件响应和主动搜寻。对于 AZ-801 场景，掌握该服务需要能够大规模连接 Windows 安全事件、Linux Syslog 和第三方 CEF 源，以最小延迟设计分析规则，将警报映射到实体以进行准确调查，以及通过基于 Logic Apps 的 playbook 自动执行遏制措施。成功还取决于规范的 Log Analytics 工作区架构、针对 Azure Monitor Agent (AMA) 的良好治理的数据收集规则 (DCR)、合理的保留策略，以及在 UEBA、监视列表、搜寻和工作簿方面的操作熟练度。

连接器和数据引入

通过 AMA 收集的 Windows 安全事件是 Windows Server 登录、进程创建、策略更改和其他审核事件的权威来源。在 Microsoft Sentinel 中启用 “Windows Security Events via AMA” 连接器，并创建一个 DCR，根据您的风险状况选择适当的事件集（Minimal、Common 或 All，或按 Event ID 自定义选择）。数据主要落入 SecurityEvent 表；非安全的 Windows 通道（如果启用）的数据则落入 WindowsEvent 表。与组策略 (Group Policy) 配合使用，确保在源服务器上启用安全基线 (Security baseline) 和审核子类别（例如，Logon/Logoff、Account Logon、Object Access、DS Access），以生成必要的遥测数据。

通过 AMA 收集的 Syslog 从支持 Syslog 协议的 Linux 服务器和网络设备中收集数据。在 Linux 主机（或专用的 Linux 收集器）上安装 AMA，并配置一个 DCR 来指定要引入的 facility 和 severity。事件被写入 Syslog 表。对于大容量但低价值的 facility，考虑在源头进行选择性收集或转换，以控制成本和噪音。

通过 AMA 收集的 CEF 能够从第三方安全产品（防火墙、IDS/IPS、代理、EDR）引入规范化的安全日志。在 Linux 收集器上部署 AMA，并配置您的供应商将 CEF 转发到本地 syslog 守护进程 (rsyslog/syslog-ng) 的端口（通常是 514/UDP 或 TCP）。在 Sentinel 中，启用 “CEF via AMA” 数据连接器，并通过一个解析 CEF 的 DCR 来链接该主机。解析后的数据进入 CommonSecurityLog 表，该表具有一致的架构（deviceVendor、deviceProduct、目标/源字段以及扩展属性），从而简化了跨供应商的分析和关联。

对于本地 Windows Server，使用已启用 Azure Arc 的服务器 (Azure Arc–enabled servers) 作为连接到 Azure 的桥梁。使用 Azure Connected Machine 代理将计算机载入，然后通过 Azure Policy 大规模部署 AMA 扩展。编写针对 Arc 服务器范围的 DCR，以路由 Windows 安全事件、Windows 防火墙日志，以及（如果使用 Sysmon）针对 Microsoft-Windows-Sysmon/Operational 通道的自定义 DCR。这种模式可以集中化配置、版本控制和基于范围的目标设定，确保无需对每台主机进行手动操作即可实现一致的引入。

工作区架构和数据生命周期

每个 Sentinel 部署都附加到一个 Log Analytics 工作区。工作区设计应最大限度地减少跨区域延迟和出口流量——将工作区与大部分数据生成者部署在同一位置，并避免过度碎片化，因为这会使查询、事件分类和 RBAC 变得复杂。常见的模式是每个租户一个安全工作区，或者在需要因数据驻留和延迟而分离的每个主要区域设置一个工作区。尽可能使用资源上下文访问 (resource-context access)，以确保团队可以在没有宽泛工作区权限的情况下查询他们所拥有资源的日志，同时由 Sentinel 角色（Reader、Responder、Contributor）来管理 SOC 操作。

DCR 用于管理收集哪些遥测类型、通道和事件集，以及将它们发送到何处。将 DCR 视为代码：标准化命名、版本控制和范围（订阅、资源组、标签）。将相关的源和目标分组，并优先使用多个有针对性的 DCR，而不是一个单体规则，以简化爆炸半径和生命周期管理。当 syslog 和 CEF 数据量很大时，考虑使用单独的 DCR 来独立调整 facility/severity 并支持分阶段测试。

保留和成本在表级别进行控制。设置默认工作区保留期以满足策略要求（例如，90–180 天用于实时搜索），然后在必要时覆盖每个表的保留策略。高价值表（SecurityEvent、CommonSecurityLog、SecurityAlert）通常保留更长时间；详细表（例如包含 DEBUG 级别的 Syslog）可以保留较短时间。使用存档 (archive) 进行长期、低成本的存储，并通过搜索作业进行查询；在调查需要时，可将其提升为热数据 (hot)。在适当的情况下，将一些详细表（如 Syslog）移至基本日志 (Basic Logs) 以降低成本，同时要认识到其查询限制，并且某些安全表（如 SecurityEvent）不符合基本日志的条件。定期审查数据上限、承诺层级和引入趋势，以防止限制并优化成本。

分析、事件和响应自动化

分析规则是检测的引擎。计划查询规则按计划（例如，每 5 分钟）在回溯期（例如，30 分钟）内运行 KQL，支持聚合、联接、监视列表扩充和抑制窗口。它们非常适用于已充分理解的模式，例如多次登录失败后成功登录、横向移动启发式分析或可疑的进程沿袭。近实时 (NRT) 规则通过持续处理新数据来最大限度地减少检测延迟，其执行频率大约为每分钟一次，并在大约两分钟内发出警报；设计 NRT 规则时应力求简洁，并依赖 ingestion_time() 或窄时间窗口来避免繁重的历史扫描。Fusion 规则使用 Microsoft 的多阶段攻击分析，将跨产品（例如，Defender for Endpoint、Defender for Identity、Entra ID Protection、第三方 CEF）的低信号警报关联成高保真事件，以应对凭据盗窃或勒索软件等攻击活动。异常规则利用内置的 ML 模板来学习基线（例如，异常登录位置、罕见的进程执行）并发出偏差警报；这些规则通常从 BehaviorAnalytics 和其他规范化源读取数据。

事件将多个警报、实体和证据统一到一个调查案例中。严重性由分析规则（或由 Fusion 动态）分配，并可通过自动化规则升级或降级。实体映射对于调查效率至关重要：在规则向导中，将查询列映射到实体类型（Account、Host、IP、URL、File、Process、CloudApplication、AzureResource）。正确的映射会填充调查图，该图可将警报、事件和实体之间的关系可视化，从而能够围绕帐户、主机、进程和 IP 进行透视分析。使用评论、标签、所有者和分类来记录分析师的处理意见，并用于训练优化工作流。

自动化融合了自动化规则和 Playbook。自动化规则在事件创建或更新时评估其元数据，以分配所有者、更改严重性、添加标签、关闭误报或调用 Playbook。Playbook 是使用 Microsoft Sentinel 连接器构建的 Azure Logic Apps。事件触发的 Playbook 会对事件生命周期事件（例如，事件创建时）做出反应，适用于事件范围内的操作，例如通知团队、扩充所有实体或创建 ServiceNow 工单。警报触发的 Playbook 在单个警报被分组到事件之前触发——这对于特定于供应商的扩充或预分类非常有用。为 Playbook 采用托管标识，通过 Azure RBAC 和 API 权限授予最低权限，并参数化工作区 ID、票务系统端点和阻止列表路径以促进重用。在有必要进行遏制的情况下，仅在满足置信度阈值后，才应包含隔离端点 (Defender for Endpoint)、禁用帐户 (Entra ID)、阻止 IP (防火墙) 或撤销会话 (Conditional Access) 等操作。

主动安全运营 (搜寻、UEBA、监视列表、工作簿)

Sentinel 中的威胁搜寻依赖于 KQL 熟练度和搜寻功能页。从按战术组织的内置搜寻查询开始；通过引用 SecurityEvent (Windows 审计)、来自 Defender 的 Device* 表、CommonSecurityLog (CEF) 和 SigninLogs (Entra) 等表，根据您的环境进行自定义。使用书签为感兴趣的记录创建快照、添加注释并在团队间共享上下文；多个书签可以提升为一个新的或现有的事件。Livestream 持续运行 KQL 模式，以近乎实时的方式检测新的匹配事件——这对于有时间限制的调查或快速激增场景非常理想。将成熟的搜寻查询转换为计划的分析规则，以实现检测的操作化。

UEBA (用户和实体行为分析) 通过行为基线和异常评分为检测提供丰富信息。从 Sentinel 配置中启用 UEBA，并确保身份和活动数据源 (Microsoft Entra 登录、Defender for Endpoint、Defender for Identity、M365 活动) 已连接。用户和主机的实体页面显示时间线、对等比较、异常活动 (罕见的登录地理位置、不寻常的进程) 和聚合的风险分数。分析师可以从事件转向实体页面，以评估某个操作对于该身份或设备是否典型；异常分数和序列有助于确定分类的优先级，并快速证实或驳斥假设。

监视列表提供由分析师维护的快速参考数据。通过上传 CSV 或指定存储帐户路径来创建监视列表，定义一个别名，并选择一个键列以进行高效查找。在 KQL 中使用 watchlist() 函数进行联接——常见用途包括管理帐户、敏感主机、经批准的域或 VIP 用户的允许/拒绝列表。将监视列表整合到分析规则中，以抑制已知的良性活动 (减少误报)，或在匹配项涉及关键资产时提升严重性。通过将监视列表与 ThreatIntelligenceIndicator 表联接以获取上下文 (例如，用内部严重性或案例说明来丰富检测到的 IP)，或通过将精选的 TI 源转换为监视列表以供快速参考和覆盖，从而与威胁情报集成。

工作簿为监控和高管可见性提供支持。从内置模板开始，例如“安全运营效率”、“Active Directory 登录”、“Fusion 检测”和“UEBA 洞察”。使用 KQL 查询、参数和可视化构建自定义工作簿，为引入运行状况、规则性能、事件 SLA 和新兴威胁创建 SOC 仪表板。在工作簿资源上应用 RBAC，并参数化订阅、工作区和时间范围，以便同一个工作簿可以服务于不同团队。组合来自多个表的磁贴，以在单一视图中关联态势 (Defender for Cloud)、检测 (Sentinel) 和响应指标。

实际问题场景

Spotify 必须为分布在 Azure 和本地数据中心的 2000 台 Windows Server 以及第三方防火墙和代理集中进行安全监控。他们需要针对凭据滥用的低延迟检测、自动化的票证创建和遏制，以及为 SOC 准备的清晰仪表板和搜寻工作流。

1. 使用 Azure Arc 和 AMA 载入混合服务器

• 使用 Azure Policy 大规模部署已启用 Azure Arc 的服务器载入，然后将 AMA 扩展策略分配给 Arc 范围。为“通过 AMA 收集 Windows 安全事件”(通用集)、Windows 防火墙以及为已安装 Sysmon 的地方创建一个自定义 DCR。这种方法提供了统一的、集中管理的收集方式，无需在每台主机上编写脚本，并确保 SecurityEvent 表填充了用于身份和进程分析的数据。

2. 通过 Syslog 和 CEF 引入网络和安全设备遥测数据

• 建立一台带有 AMA 的 Linux 收集器虚拟机。为相关设施配置“通过 AMA 收集 Syslog”，并启用“通过 AMA 收集 CEF”以将防火墙和代理的 CEF 解析到 CommonSecurityLog 中。使用 CEF 可以规范化多供应商数据，从而实现规则的可移植性和跨源的轻松联接。

3. 设计兼顾速度和保真度的分析

• 启用 Fusion 以最少的调整捕获多阶段攻击。使用 SecurityEvent 和 ingestion_time() 为特权帐户上突发的失败登录后紧跟成功登录的场景创建 NRT 规则，提供低于两分钟的检测。为横向移动模式 (例如，在服务器上由异常管理帐户联接创建 net.exe 进程) 和与 VIP 及核心资产主机监视列表联接的代理出口异常构建计划规则。这种组合在抑制误报的同时，最大限度地减少了 MTTR。

4. 映射实体并塑造事件

• 在每个计划规则中，从查询列映射 Account、Host、IP 和 Process 实体。使用自动化规则按业务部门 (从主机标签派生) 分配事件、规范严重性、添加 MITRE 标签，并自动关闭已知的测试信号。正确的映射使调查关系图能够显示 Spotify 分析师可以快速切换浏览的关系。

5. 使用 playbook 自动化扩充、票证创建和遏制

• 构建一个由事件触发的 playbook，该 playbook 会扩充所有帐户和主机的信息 (图查询、设备风险)、发布到 Teams 并创建 Jira 票证。另一个由警报触发的 playbook 使用供应商 API 扩充特定的 CEF 警报。使用具有最低权限 RBAC 的托管标识和条件分支，仅在满足置信度阈值 (例如，多个相互佐证的警报和高 UEBA 分数) 时才隔离设备 (通过 Defender for Endpoint) 或禁用用户 (通过 Entra ID)。这在实现快速、受治理的响应的同时，也保护了业务连续性。

6. 启用 UEBA 并将搜寻操作化

• 开启 UEBA 并验证数据源 (SigninLogs、M365 活动、Defender 信号)。培训分析师从事件转向实体页面，以查看异常分数和对等比较。一旦通过书签和 livestream 验证，就将两个高价值的搜寻查询——“服务器上新出现的远程管理工具”和“罕见的外部 IP 渗出模式”——转换为计划的分析规则。UEBA 加上规范的搜寻活动可以加强对新型技术的检测。

7. 治理数据生命周期并可视化态势

• 为 SecurityEvent 和 CommonSecurityLog 设置 180 天的保留期，为详细的 Syslog 设置 30 天保留期并存档 1 年，并使用承诺层级监控成本。发布一个自定义的 SOC 工作簿，用于跟踪引入运行状况、最嘈杂的规则、MTTA/MTTR、按严重性划分的事件队列以及随时间变化的 UEBA 异常。这为领导层提供了透明度，并推动持续优化。

每种工具的选择都基于其特定用途的优势：Arc 和 AMA+DCR 提供可扩展、策略驱动的数据引入；CEF 确保多供应商安全日志的规范化；Fusion 和 NRT 在无需过多调整的情况下降低了检测延迟；实体映射和调查关系图加速了分类过程；playbook 提供受治理的、基于身份的自动化；UEBA 提供行为上下文；搜寻工具使检测更加成熟；而工作簿则使运营可衡量和可见。

← Microsoft Defender for Cloud 和终结点安全 · 所有领域 · Active Directory 域服务安全 →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →

浏览 Microsoft →