Share via

敏感操作报告工作簿

  • 项目

作为 IT 管理员，你需要能够识别环境中遭到的入侵，以确保可以让环境保持正常运行状况状态。

敏感操作报告工作簿旨在帮助识别可能表明环境被入侵的可疑应用程序和服务主体活动。

本文概述了“敏感操作报告”工作簿。

先决条件

若要将 Azure 工作簿用于 Microsoft Entra ID，需要：

  • 使用 Premium P1 许可证的 Microsoft Entra 租户
  • 一个 Log Analytics 工作区和对该工作区的访问权限
  • Azure Monitor 和 Microsoft Entra ID 的相应角色

Log Analytics 工作区

必须先创建 Log Analytics 工作区，然后才能使用 Microsoft Entra 工作簿。 有多个因素决定对 Log Analytics 工作区的访问。 需要为工作区和发送数据的资源提供适当的角色。

有关详细信息，请参阅管理对 Log Analytics 工作区的访问权限。

Azure Monitor 角色

Azure Monitor 提供两个内置角色，用于查看监视数据和编辑监视设置。 Azure 基于角色的访问控制 (RBAC) 还提供两个授予类似访问权限的 Log Analytics 内置角色。

  • 视图：

    • 监视查阅者
    • Log Analytics 读者

  • 查看和修改设置：

    • 监视参与者
    • Log Analytics 参与者

Microsoft Entra 角色

只读访问权限允许查看工作簿内的 Microsoft Entra ID 日志数据、从 Log Analytics 查询数据或在 Microsoft Entra 管理中心读取日志。 更新访问权限增加了创建和编辑诊断设置的功能，以便将 Microsoft Entra 数据发送到 Log Analytics 工作区。

  • “读取”：

    • 报告读者
    • 安全读取者
    • 全局读取者

  • 更新：

    • 安全管理员

有关 Microsoft Entra 内置角色的详细信息，请参阅 Microsoft Entra 内置角色。

有关 Log Analytics RBAC 角色的详细信息，请参阅 Azure 内置角色。

说明

工作簿类别

此工作簿标识租户中最近执行的敏感操作，这些操作可能会泄露服务主体信息。

如果你的组织不熟悉 Azure Monitor 工作簿，则需要在访问工作簿前将 Microsoft Entra 登录和审核日志与 Azure Monitor 集成。 此集成允许你使用工作簿来存储、查询和可视化日志，时间长达两年。 只会存储在集成 Azure Monitor 之后创建的登录和审核事件，因此工作簿不包含该日期之前的见解。 详细了解适用于 Microsoft Entra ID 的 Azure Monitor 工作簿的先决条件。 如果以前已将 Microsoft Entra 登录和审核日志与 Azure Monitor集成，则可以使用工作簿评估过去的信息。

如何访问工作簿

  1. 使用适当的角色组合登录到 Microsoft Entra 管理中心。

  2. 浏览到“标识”>“监视和运行状况”>“工作簿”。

  3. 从“故障排除”部分选择“敏感操作报告”工作簿。

部分

此工作簿分为四个部分：

工作簿的各个部分

  • 修改后的应用程序和服务主体凭据/身份验证方法 - 此报表标记最近更改了许多服务主体凭据的行动者，以及每种类型的服务主体凭据更改数。

  • 授予服务主体的新权限 - 此工作簿还突出显示了最近向服务主体授予的 OAuth 2.0 权限。

  • 服务主体的目录角色和组成员身份更新

  • 修改后的联合身份验证设置 - 当用户或应用程序修改了域上的联合身份验证设置时，此报告会突出显示。 例如，它会报告何时将新的 Active Directory 联合服务 (ADFS) TrustedRealm 对象（如签名证书）添加到域。 对域联合身份验证设置的修改应该很少。

修改后的应用程序和服务主体凭据/身份验证方法

攻击者持久入侵环境的最常见方法之一是向现有应用程序和服务主体添加新凭据。 这些凭据允许攻击者以目标应用程序或服务主体的身份进行身份验证，并授予他们访问其有权访问的所有资源的权限。

本部分包含以下数据，可帮助检测：

  • 添加到应用和服务主体的所有新凭据，包括凭据类型

  • 排名靠前的行动者及其执行的凭据修改量

  • 所有凭据更改的时间线

向服务主体授予的新权限

攻击者在找不到具有高特权权限集的服务主体或应用程序来获取访问权限的情况下，通常会尝试将权限添加到另一个服务主体或应用。

本部分包括向现有服务主体授予的 AppOnly 权限明细。 管理员应调查向其授予了过多权限的任何实例，包括但不限于 Exchange Online 和 Microsoft Graph。

服务主体的目录角色和组成员身份更新

按照攻击者向现有服务主体和应用程序添加新权限的逻辑，另一种方法是将它们添加到现有目录角色或组。

本部分概述了对服务主体成员身份进行的所有更改，应审查向高特权角色和组添加的任何成员。

经过修改的联合身份验证设置

在环境中获得长期入侵点的另一种常见方法是：

  • 修改租户的联合域信任。
  • 添加由攻击者控制的额外 SAML IDP 作为受信任的身份验证源。

本部分包括下列数据：

  • 对现有域联合身份验证信任所做的更改

  • 添加新域和信任

筛选器

此段落列出了每个部分支持的筛选器。

修改后的应用程序和服务主体凭据/身份验证方法

  • 时间范围
  • 操作名称
  • 凭据
  • Actor
  • 排除行动者

向服务主体授予的新权限

  • 时间范围
  • 客户端应用
  • 资源

服务主体的目录角色和组成员身份更新

  • 时间范围
  • 操作
  • 启动用户或应用

经过修改的联合身份验证设置

  • 时间范围
  • 操作
  • 启动用户或应用

最佳实践

    • 使用修改后的应用程序和服务主体凭据来查找添加到组织中不常用的服务主体的凭据。** 使用本部分中介绍的筛选器进一步调查任何已修改的可疑行动者或服务主体。

  • “使用授予服务主体的新权限”，用于查找可能遭到入侵的执行者向服务主体添加的广泛或过多权限。

  • “使用修改后的联合身份验证设置”部分，用于确认添加或修改的目标域/URL 是合法管理员行为。 修改或添加域联合身份验证信任的操作很少见，应将其视为高保真，尽快进行调查。