Microsoft 365 审核日志收集

审核日志在维护、排查和保护客户租户和内部 Microsoft 365 基础结构方面发挥着重要作用。 由于 Microsoft 365 运营的规模,必须从战略上管理审核日志的收集和处理,以确保高效且有效的监视。 本文概述了 Microsoft 365 的审核日志记录做法,包括捕获的事件类型、每个日志中包含的信息、如何强制执行日志记录策略,以及如何在其生命周期的所有阶段保护日志数据。

定义可审核事件

Microsoft 365 安全团队负责定义必须在 Microsoft 365 中收集的基线日志。 它们维护每个系统必须捕获的事件类型以及每个记录的事件必须包含的数据的官方列表。

Microsoft 365 从各种源捕获日志数据,包括:

  • 事件日志
  • AppLocker 日志
  • 性能数据
  • System Center 数据
  • 呼叫详细信息记录
  • 体验质量数据
  • IIS Web 服务器日志
  • SQL Server日志
  • Syslog 数据
  • 安全审核日志

此列表中的每个日志必须至少包含以下信息才能建立关联的事件类型、源、位置、结果、时间和实体:

  • 源用户 ID
  • 目标用户 ID - 与事件类型相关/适用
  • 事件时间戳 (日期 & 时间)
  • 事件详情
    • 类型
    • 结果 (成功/失败)
    • 详细信息 - 按事件类型定义
  • 源 & 目标主机名 - 与事件类型相关/适用
  • 源 & 目标网络地址和协议 - 与事件类型相关/适当

可审核事件和相关数据的列表由持续风险评估、Microsoft 365 安全标准、业务要求和合规性要求提供。 Microsoft 365 安全团队将审查并更新可审核事件列表,以说明新威胁、系统更改、从过去事件中吸取的经验教训以及不断变化的合规性要求。

除了 Microsoft 365 安全团队定义的可审核事件列表外,服务团队还可以为其服务定义其他日志记录要求。 在服务审查和功能里程碑的规划阶段,将审查和更新特定于应用程序的事件。 Microsoft 365 安全团队还帮助指导这些单独的服务团队了解审核功能,以满足其特定需求。 每当对系统进行重大更改时,将审查和更新服务级别可审核事件。

由于 Microsoft 的规模,捕获的数据量必须与存储和处理数据的能力相平衡。 从资源和分析的角度来看,收集每个可能事件及其内容的信息是不切实际的。 通过对收集的日志数据类型进行选择,Microsoft 可以高效有效地维护其信息系统的运行状况和安全性。

集中管理

Microsoft 365 通过 Microsoft 365 安全团队设置的策略集中强制实施日志记录要求。 每个 Microsoft 365 系统都必须包含自定义日志记录代理、Office 数据加载程序 (ODL) ,该代理作为系统基线的一部分进行安装。 ODL 强制实施中央日志记录策略,并配置为收集 Microsoft 365 安全性定义的事件并将其发送到集中式服务进行处理和存储。

ODL 配置为自动清理所有最终用户信息,并每隔五分钟批量上传事件。 包含客户数据(如租户信息和最终用户身份信息)的任何字段都将被删除并替换为哈希值。 除了前面所述的清理之外,禁止对审核记录内容和时间排序进行永久或不可逆的更改。

日志数据上传到专有安全监视解决方案,以便进行准实时 (NRT) 分析,检查日志中是否存在潜在的安全事件和绩效指标。 日志还会上传到内部大数据计算服务, (Azure Data Lake) 进行长期存储。 所有日志数据传输都通过 FIPS 140-2 验证的 TLS 连接进行,以确保传输过程中的数据机密性。

Azure Data Lake 中存储的大多数审核日志数据至少保留一年,以支持安全事件调查,并满足法规保留要求。 服务团队可能会为特定类型的日志数据选择 90 天或更长时间的备用保留期,以支持其应用程序的需求。 Microsoft 365 日志保留和备份策略确保日志数据随时可用于事件调查、合规性报告和任何其他业务要求。

访问控制

Microsoft 对 Microsoft 365 中发生的所有委派、特权和操作执行广泛的监视和审核。 对 Azure Data Lake 中存储的 Microsoft 365 数据的访问权限仅限于授权人员,并且会捕获所有访问控制请求和审批,以便进行安全事件分析。 Microsoft 近乎实时地评审访问级别,以确保只有具有授权业务理由并满足资格要求的用户才能访问其系统。 所有允许的访问都可以跟踪到唯一用户。

Microsoft 将审核日志的管理限制为负责审核功能的安全团队成员的有限子集。 Microsoft 的内部访问控制 理念 围绕实时 (JIT) 和 Just-Enough-Access (JEA) 的原则展开。 因此,安全团队对 Azure Data Lake 没有长期管理访问权限,并且会记录和审核所有更改。