Microsoft AZ-500: Microsoft Sentinel 和安全运营 — 学习指南

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

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

概述

Microsoft Sentinel 是 Azure 的云原生 SIEM 和 SOAR 平台，构建于 Azure Monitor Log Analytics 之上。它集中管理安全遥测数据，应用分析来检测威胁，生成事件供分析师分类处理，并使用 Logic Apps 编排自动化响应。高效的运营取决于精心设计的工作区架构、周密的数据接入、有成本意识的数据保留策略、精确的分析和实体映射，以及一套能将警报与 SOC 工作流和业务风险对齐的自动化与调优机制。

Sentinel 架构和数据管理

• 工作区和多租户注意事项

  • Sentinel 按 Log Analytics 工作区运行。根据数据主权、延迟和管理隔离需求来选择工作区边界。单一的“中央 SOC”工作区可简化关联和内容管理；而对于有严格驻留要求、需要自治或采用 MSSP/Lighthouse 模型的场景，多个工作区可能更合适。支持跨工作区查询，但这会增加查询延迟和成本；当跨实体的关联至关重要时，应优先考虑整合。
  • 在工作区上使用基于资源上下文的 RBAC 来分离职责：Sentinel Reader 用于仪表板，Responder 用于事件处理，Contributor 用于内容管理，Automation Contributor 用于 playbook。

• 引入路径

  • 数据通过原生连接器、Azure Monitor 代理或 API 进入工作区中的表。对于 Microsoft 源，优先使用原生连接器（优化的架构、高可靠性）；对于 Windows/Syslog，优先使用 AMA+DCR 以获得筛选和按表计费计划的控制能力。对于第三方设备，通过 Syslog 将 CEF 路由到 CommonSecurityLog 表，以利用内置的解析器和分析内容。

• 保留、归档和搜索

  • 配置按表保留策略，将热数据（用于交互式分析）保留在操作检测窗口期内（通常为 30-120 天）。将较早的数据归档到 Log Analytics Archive 层，最长可保留 7 年，以极低的成本满足合规性要求；在调查时可使用 Search Jobs 或 Restore 功能。操作层面的考量：仅保留分析师日常需要深入分析的数据；将其余数据归档以满足审计/法规要求，避免增加热路径的开销。

• 成本控制

  • 承诺层（容量预留）可以为稳定的数据量可预测地降低引入成本；在建立 30-60 天的基线后启用，以避免过度承诺。
  • 表级计费计划：对安全关键表（如 SecurityEvent、SignInLogs、CommonSecurityLog）使用 Analytics 模式。对查询不频繁的、详细但价值较低的诊断日志使用 Basic Logs 模式；切勿将高价值信号的安全表置于 Basic 模式，因为它们会失去完整的查询功能且无法用于警报。
  • 在计费前，使用 DCR 进行引入时转换，以删除或屏蔽字段和行（最小化 PII、减少噪音）。在操作上，预先在引入前消除噪音是控制成本和保真度的最有效方法。
  • 设置工作区每日上限，并针对异常激增设置警报，以捕获因配置错误或攻击而产生的日志风暴。

数据连接器和引入

• Azure Activity

  • 使用 Azure Activity 连接器，通过诊断设置将订阅级别的控制平面操作流式传输到 AzureActivity 表中。原因：捕获角色变更、策略更新和部署等操作——这些是攻击者权限提升或篡改的主要指标。

• Microsoft Entra ID (Azure AD)

  • 启用 AuditLogs 和 SignInLogs 连接器。如果拥有相应许可，可选择性地引入 Enriched Azure AD 日志。原因：身份是主要的攻击面；登录异常和目录变更是大多数检测和 UEBA 的基础。

• Microsoft Defender 产品

  • Defender for Endpoint、Defender for Office 365、Defender for Identity、Defender for Cloud Apps 和 Defender for Cloud 的连接器可以引入高保真度的警报和遥测数据。原因：Microsoft 的安全警报具有深度关联性，能提高事件质量；引入这些警报可以为 Fusion 和 Microsoft 安全规则提供支持，且只需最少的调优。

• Windows 事件

  • 使用带 DCR 的 Azure Monitor Agent (AMA)：将域控制器和关键服务器的 Windows 安全事件（可选择 Common、Minimal 或 All 级别）发送到 SecurityEvent 表；根据需要将常规的 Windows Event 通道发送到 WindowsEvent 表。原因：SecurityEvent 是身份验证和进程审计的核心；DCR 筛选可以减少噪音（例如，排除不含 CommandLine 的 4688 事件）。

• Syslog 和 CEF

  • 对于 Linux，使用 AMA Syslog DCR 选择特定的 facility/severity 级别并发送到 Syslog 表。对于第三方防火墙/IDS/EDR，将 CEF 转发到基于 Log Analytics 代理的转发器或基于 AMA 的引入管道，最终数据会进入 CommonSecurityLog 表；使用供应商提供的解析器内容。原因：CEF 维护了规范化的字段，减轻了解析负担；CommonSecurityLog 解锁了预构建的检测规则。

• 操作健康检查

  • 确保时间同步 (NTP) 和设备时区一致，以实现准确的关联分析。
  • 对重叠的数据源进行去重（例如，不要同时引入原始日志和已规范化的重复日志）。
  • 在启用分析规则之前，使用 Watchlists 或示例查询验证架构，以避免误报。

分析、检测与调查

• 分析规则类型

  • 计划规则：按计划（例如，每 5 分钟运行一次，回溯 1 小时）对历史数据运行 KQL 查询。用于大多数检测场景；调整回溯期以超过典型的数据延迟，避免遗漏。
  • 近实时 (NRT) 规则：通过受限的 KQL 和固定的短回溯期实现亚分钟级检测。谨慎用于秒级响应至关重要的高紧急性模式（例如，大规模角色分配）。为保证性能，应使用最少的联接和简单的筛选器。
  • Fusion：跨 Microsoft 信号（Defender、Entra、Cloud Apps）的、由机器学习驱动的多阶段关联。原理：通过为攻击杀伤链生成单个事件，大幅减少警报疲劳。
  • 异常规则：基于用户/实体基线和动态阈值。可快速发现异常的地理位置、流量或进程模式；维护排除列表以处理已批准的异常（例如，维护窗口）。
  • Microsoft 安全规则：根据 Defender 警报自动创建事件。保持启用状态，并调整自动化规则以进行路由/严重性设置；它们能以较低的调优开销提供高置信度的信号。

• 实体映射与事件

  • 在规则配置中，将 KQL 输出列映射到实体（Account、Host、IP、URL、File），为事件图表和 UEBA 提供支持。不良的映射会降低调查的保真度。
  • 警报分组策略影响事件的数量和上下文。按实体/时间窗口进行分组，以合并相关警报，在保留故事线的同时减少噪音。

• 调查与 UEBA

  • 事件会呈现时间线、证据和相关实体；调查图表会根据实体映射和数据查找自动建立关系。
  • 启用 UEBA，用对等基线、设备角色和风险信号来丰富实体信息。原理：上下文信息可以缩短分类时间并为响应范围提供依据。

• 用于检测工程的 KQL 基础

  • 筛选与投影

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

  - 解析与规范化

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

• 联接

    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
    ```

  - 汇总与时间窗口分析

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

搜寻、自动化、威胁情报、报告和 SOC 优化

• 威胁搜寻工作流

  • 搜寻查询：从 Sentinel 模板开始；根据环境特定的白名单进行演进。将有价值的线索保存为自定义查询以供重用。
  • 书签：在搜寻期间捕获证据和关键枢纽点；稍后附加到事件中以保留分析师的上下文。
  • 实时流：持续运行 KQL 筛选器以发现实时发生的事件；非常适合在活动事件期间用于确认遏制措施是否生效。
  • 监视列表：上传基于 CSV 的允许/拒绝/优先级列表（例如 VIP 用户、经批准的 IP、资产层级）。使用 _GetWatchlist 函数进行引用，以实现扩充和抑制。

• 自动化规则和 playbook

  • 自动化规则在事件/警报创建时进行分类：根据条件（规则名称、策略、实体）设置严重性、分配所有者、添加标签、分类后关闭，或触发 playbook。
  • Playbook (Logic Apps) 实现 SOAR：使用 VirusTotal/MDTI 进行扩充、在 Teams 中通知、创建工单 (ServiceNow/Jira)、隔离终结点 (MDE) 或禁用帐户 (Entra)。使用托管标识和最小权限 RBAC（在工作区上使用 Sentinel Responder 角色；对目标系统使用有限范围的角色）。理由：将操作代码化、可重复执行，从而缩短 MTTR 并减少手动错误。

• 威胁情报 (TI)

  • 使用内置提供程序、手动上传、GitHub 自动化或 TAXII 收集器 (STIX 2.0/2.1) 引入 TI 指标。规范化字段（指标类型、模式、置信度、TLP）并设置过期时间，以防止过时的匹配。
  • 指标匹配：启用基于 TI 的分析规则，将 IP/域/URL/哈希与遥测数据（CommonSecurityLog、DNS、Proxy、SignInLogs）进行匹配。使用置信度阈值和监视列表例外来减少噪音。理由：TI 将搜索范围缩小到已知的恶意活动，但必须进行筛选以避免误报。

• 工作簿和报告

  • 使用 Azure Monitor Workbooks 构建运营仪表板。按订阅、工作区或时间范围进行参数化；尽早汇总数据（使用 summarize、make-series）以保持查询效率。
  • 提供分层视图：高管级态势（按严重性/SLA 划分的事件）、SOC 运营（打开与关闭的事件、队列老化、分析师负载）、检测健康状况（连接器状态、数据延迟）和控制覆盖范围（MITRE 映射）。理由：针对不同角色的视图支持决策，而不会让用户淹没在原始事件的海洋中。

• SOC 优化和流程

  • 减少误报：优化 KQL 谓词、添加基线（动态阈值）、利用实体允许列表（监视列表）并排除良性来源。每次抑制操作都需通过补偿性控制进行验证。
  • 严重性规范化：将规则严重性映射到影响和置信度，而不是频率。高严重性应意味着需要立即唤醒待命人员；中等严重性用于及时分类；低严重性用于积压的搜寻任务。
  • 升级和交接：定义事件状态、所有者和 SLA；自动扩充信息并路由到正确的队列；通过 playbook 创建 ITSM 工单并实现双向更新。为每种策略记录遏制步骤（禁用用户、隔离终结点、撤销令牌、阻止指标）。

实践问题场景

Contoso Ltd. 在将多个数据源接入 Microsoft Sentinel 后，经历了警报疲劳和响应缓慢的问题。事件数量众多、分组不佳且缺乏自动化。CISO 要求在不损失检测保真度的情况下，将平均响应时间 (MTTR) 减少 50%。

1. 使用 DCR 筛选和表计划重构数据引入

• 行动：将 Windows 安全事件迁移到 AMA+DCR，并在 DC 上使用“Common”预设；将详细的诊断表切换到 Basic Logs；启用 90 天热保留和 1 年存档。
• 理由：在保留可操作安全数据的同时，降低了噪音和热路径成本，从而为更高保真度的检测释放了分析周期和预算。

2. 启用 Microsoft Defender 连接器和 Fusion

• 行动：连接 MDE、MDI、MDO、MDC 和 Cloud Apps；确保 Microsoft 安全分析和 Fusion 已开启。
• 理由：高置信度警报和机器学习关联功能将重复的警报合并为单个丰富的事件，从而减轻了分类负担。

3. 标准化实体映射和警报分组

• 行动：更新计划规则以映射 Account、Host、IP 和 URL；配置按 Account 和 4 小时窗口对相关警报进行分组。
• 理由：正确的映射为调查图谱和 UEBA 提供了支持；分组在保留攻击链上下文的同时，降低了事件数量。

4. 实施自动化规则以进行分类和有针对性的 playbook

• 行动：创建自动化规则，以按策略自动添加标签、根据置信度设置严重性、分配到队列，并触发 playbook：扩充指标 (MDTI)、创建 ServiceNow 工单、隔离设备 (MDE) 以及在获得批准后暂停高风险用户 (Entra)。
• 理由：确定性的分类加上 SOAR 操作缩短了 MTTR 并标准化了响应；批准流程为高影响步骤强制执行了安全护栏。

5. 引入监视列表和经过筛选的 TI 匹配

• 行动：构建 VIP 用户和经批准服务的监视列表；添加一个经过筛选的 TAXII 源，要求置信度 >= 70 且有效期为 7 天；启用针对代理/DNS 的 TI 匹配规则。
• 理由：优先处理高价值目标，并使用新鲜、可信的 TI 来聚焦调查并减少误报。

6. 发布基于角色的工作簿和 SLA

• 行动：创建高管、SOC 运营和检测健康状况工作簿；设置事件 SLA（高：4 小时，中：24 小时，低：3 天）并报告违规情况。
• 理由：可见性和问责制推动了运营纪律；有针对性的仪表板可防止上下文切换和精力浪费。

7. 建立持续的优化节奏

• 行动：每周审查被标记为误报而关闭的事件；调整规则、抑制和排除项，并记录理由；监控引入异常和查询性能。
• 理由：没有反馈循环，安全运营就会偏离正轨；随着环境的演变，持续的优化可以保持信号质量。

通过执行这些步骤，Contoso 将检测与业务风险对齐，从源头减少噪音，并自动化重复性任务——从而在不牺牲覆盖范围的情况下，实现更快、更一致的事件响应。

← 安全态势管理和治理 · 所有领域 · 应用安全和 DevSecOps →

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

浏览 Microsoft →