按资源管理对Microsoft Sentinel数据的访问权限

使用 Azure RBAC 管理对工作区的访问。 通常，有权访问为Microsoft Sentinel启用Log Analytics工作区的用户也有权访问所有工作区数据，包括安全内容。 管理员可以根据团队中的访问要求，使用 Azure 角色配置对Microsoft Sentinel中特定功能的访问权限。

但是，你可能有一些用户需要仅访问工作区中的特定数据，但不应访问整个Microsoft Sentinel环境。 例如，你可能希望为一个非安全操作（非 SOC）团队赋予访问他们拥有的服务器的 Windows 事件数据的权限。

在这种情况下，建议您根据用户被允许访问的资源配置基于角色的访问控制（RBAC），而不是向他们提供对工作区或特定 Microsoft Sentinel 功能的访问权限。 此方法也称为设置资源上下文 RBAC。

当用户可以通过可以访问的资源（而不是工作区）访问Microsoft Sentinel数据时，他们可以使用以下方法查看日志和工作簿：

• 资源本身，例如 Azure 虚拟机。 使用此方法仅查看特定资源的日志和工作簿。

• Via Azure Monitor。 若要创建跨多个资源和/或资源组的查询，请使用此方法。 导航到Azure Monitor中的日志和工作簿时，请将范围定义为一个或多个特定的资源组或资源。

在Azure Monitor中启用资源上下文 RBAC。 有关详细信息，请参阅 在 Azure Monitor 中管理日志数据和工作区的访问权限。

资源上下文 RBAC 的方案

下表突出显示了最适合使用资源上下文 RBAC 的场景。 请注意 SOC 团队与非 SOC 团队之间访问要求的差异。

如果你的团队与上表中所述的非 SOC 团队具有类似的访问要求，则资源上下文 RBAC 对于你的组织来说可能是不错的解决方案。

例如，下图显示了一个简化版的工作区体系结构，其中安全团队和运营团队需要访问不同的数据集，并使用资源上下文 RBAC 提供所需的权限。

在此图像中：

• 为 Microsoft Sentinel 启用的日志分析工作区被放置在一个单独的订阅中，以更好地隔离应用程序团队用于托管其工作负载的订阅中的权限。
• 应用程序团队具有对各自资源组的访问权限，他们可在其中管理自己的资源。

这种独立的订阅和资源上下文 RBAC 允许这些团队查看他们有权访问的任何资源生成的日志，即使这些日志存储在他们无法直接访问的工作区中。 应用程序团队可以通过Azure门户的 Logs 区域访问日志，以显示特定资源的日志，或通过Azure Monitor来显示他们同时访问的所有日志。

为非 Azure 资源显式配置资源上下文 RBAC

Azure资源具有对资源上下文 RBAC 的内置支持，但在使用非Azure资源时可能需要进行额外的微调。 例如，在为 Microsoft Sentinel 启用的 Log Analytics 工作区中，属于非 Azure 资源的数据包括 Syslog、CEF 或 AAD 数据，或者由自定义收集器收集的数据。

如果要配置资源上下文 RBAC，但数据不是 Azure 资源，请使用以下步骤。

若要显式配置资源上下文 RBAC：

1. 请确保您在 Azure Monitor 中启用资源上下文 RBAC。

2. 创建资源组，为每个需要访问资源但不需进入整个 Microsoft Sentinel 环境的用户团队。

   为团队每个成员分配日志读取者权限。

3. 将资源分配给创建的资源团队组，并使用相关资源 ID 标记事件。

   Azure资源将数据发送到Microsoft Sentinel时，日志记录会自动使用数据源的资源 ID 进行标记。

   提示

   建议在为此目的而创建的特定资源组下对要授予访问权限的资源进行分组。

   如果无法执行此操作，请确保你的团队对你希望他们访问的资源具有直接的日志读取权限。

   有关资源 ID 的详细信息，请参阅：

   • 用于日志转发的资源 ID
   • Logstash 收集的资源 ID
   • 使用 Log Analytics API 集合的资源 ID

用于日志转发的资源 ID

使用通用事件格式 (CEF) 或 Syslog 收集事件时，使用日志转发从多个源系统收集事件。

例如，当 CEF 或 Syslog 转发 VM 侦听来自源的 Syslog 事件，并将这些事件转发到 Microsoft Sentinel 时，日志转发 VM 资源 ID 将分配给它们转发的所有事件。

如果有多个团队，请确保有单独的日志转发 VM 处理每个单独团队的事件。

例如，分隔 VM 可确保使用收集器 VM A 收集属于团队 A 的 Syslog 事件。

用于 Logstash 集合的资源 ID

如果使用 Microsoft Sentinel Logstash 输出插件收集数据，请使用 azure_resource_id 字段将自定义收集器配置为在输出中包含资源 ID。

如果使用的是资源上下文 RBAC，并且希望 API 收集的事件可供特定用户使用，则使用为用户创建的资源组的资源 ID。

例如，以下代码显示了一个示例 Logstash 配置文件：

 input {
     beats {
         port => "5044"
     }
 }
 filter {
 }
 output {
     microsoft-logstash-output-azure-loganalytics {
       workspace_id => "4g5tad2b-a4u4-147v-a4r7-23148a5f2c21" # <your workspace id>
       workspace_key => "u/saRtY0JGHJ4Ce93g5WQ3Lk50ZnZ8ugfd74nk78RPLPP/KgfnjU5478Ndh64sNfdrsMni975HJP6lp==" # <your workspace key>
       custom_log_table_name => "tableName"
       azure_resource_id => "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/contosotest" # <your resource ID>   
     }
 }

Log Analytics API 集合中的资源 ID

使用 Log Analytics 数据收集器 API 收集时，可以使用 HTTP x-ms-AzureResourceId 请求标头将事件分配给具有资源 ID 的事件。

如果使用的是资源上下文 RBAC，并且希望 API 收集的事件可供特定用户使用，则使用为用户创建的资源组的资源 ID。

资源上下文 RBAC 的替代方案

根据组织所需的权限，使用资源上下文 RBAC 可能无法提供完整的解决方案。 例如，考虑上一部分中介绍其体系结构的组织是否还必须向内部审核团队授予对Office 365日志的访问权限。 在这种情况下，他们可以使用表级别的 RBAC 向审核团队授予对整个 OfficeActivity 表的访问权限，而不授予对其他任何表的权限。

下表介绍了其他数据访问解决方案可能更符合要求的方案：

相关内容

有关详细信息，请参阅：

• Microsoft Sentinel 中的 权限
• 管理对Log Analytics工作区的访问权限
• Azure什么是基于角色的访问控制（Azure RBAC）？