管理对 Log Analytics 工作区的访问权限

用于确定可以在 Log Analytics 工作区中访问哪些数据的因素包括：

• 工作区本身的设置。
• 对将数据发送到工作区的资源的访问权限。
• 访问工作区所用的方法。

本文介绍如何管理对 Log Analytics 工作区中数据的访问。

概述

下表描述了定义可访问的数据的因素。 后面的部分进一步描述了每个因素。

访问模式

访问模式是指如何访问 Log Analytics 工作区，并定义在当前会话期间可以访问的数据。 模式是根据你在 Log Analytics 中选择的范围确定的。

有两种访问模式：

• 工作区上下文：你可以查看工作区中你有权访问的所有日志。 在此模式下，只能查询工作区中你有权访问的表内的所有数据。 使用工作区作为范围来访问日志时（例如，在 Azure 门户上的“Azure Monitor”菜单中选择“日志”时），将使用此访问模式。
• 资源上下文：访问特定资源、资源组或订阅的工作区时（例如，在 Azure 门户上的资源菜单中选择“日志”时），只能查看所有表中你有权访问的资源的日志。 在此模式下，只能查询与该资源关联的数据。 此模式还支持精细 Azure RBAC。 工作区使用资源上下文日志模型，其中 Azure 资源发出的每条日志记录将自动与此资源关联。

仅当记录与相关资源关联时，才可以在资源上下文查询中使用这些记录。 若要检查这种关联，请运行一个查询并验证 _ResourceId 列是否已填充。

以下资源存在已知限制：

• Azure 外部的计算机：只有 Azure Arc for Servers 支持资源上下文。
• Application Insights：仅在使用基于工作区的 Application Insights 资源时支持资源上下文。
• Azure Service Fabric

比较访问模式

下表汇总了访问模式：

访问控制模式

访问控制模式是每个工作区中的一项设置，定义如何确定该工作区的权限。

• 需要工作区权限。 此控制模式不允许精细 Azure RBAC。 要使某个用户能够访问工作区，必须为其授予对该工作区或特定表的权限。

  如果用户以工作区上下文模式访问工作区，将可以访问他们有权访问的任何表中的所有数据。 如果用户以资源上下文模式访问工作区，则只能访问他们有权访问的任何表中该资源的数据。

  这是在 2019 年 3 月之前创建的所有工作区的默认设置。

• 使用资源或工作区权限。 此控制模式允许精细 Azure RBAC。 可以通过分配 Azure read 权限，仅向用户授予与他们可查看的资源相关联的数据的访问权限。

  当用户以工作区上下文模式访问工作区时，将应用工作区权限。 当用户以资源上下文模式访问工作区时，只会验证资源权限，而会忽略工作区权限。 要为用户启用 Azure RBAC，可将其从工作区权限中删除，并允许识别其资源权限。

  这是在 2019 年 3 月之后创建的所有工作区的默认设置。

  注意

  如果用户只对工作区拥有资源权限，则他们只能使用资源上下文模式访问工作区（假设工作区访问模式设置为“使用资源或工作区权限”）。

为工作区配置访问控制模式

Get-AzResource -ResourceType Microsoft.OperationalInsights/workspaces -ExpandProperties | foreach {$_.Name + ": " + $_.Properties.features.enableLogAccessUsingOnlyResourcePermissions}

DefaultWorkspace38917: True
DefaultWorkspace21532: False

$WSName = "my-workspace"
$Workspace = Get-AzResource -Name $WSName -ExpandProperties
if ($Workspace.Properties.features.enableLogAccessUsingOnlyResourcePermissions -eq $null)
    { $Workspace.Properties.features | Add-Member enableLogAccessUsingOnlyResourcePermissions $true -Force }
else
    { $Workspace.Properties.features.enableLogAccessUsingOnlyResourcePermissions = $true }
Set-AzResource -ResourceId $Workspace.ResourceId -Properties $Workspace.Properties -Force

Get-AzResource -ResourceType Microsoft.OperationalInsights/workspaces -ExpandProperties | foreach {
if ($_.Properties.features.enableLogAccessUsingOnlyResourcePermissions -eq $null)
    { $_.Properties.features | Add-Member enableLogAccessUsingOnlyResourcePermissions $true -Force }
else
    { $_.Properties.features.enableLogAccessUsingOnlyResourcePermissions = $true }
Set-AzResource -ResourceId $_.ResourceId -Properties $_.Properties -Force
}

Azure RBAC

对工作区的访问权限是使用 Azure RBAC 管理的。 若要使用 Azure 权限授予对 Log Analytics 工作区的访问权限，请执行分配 Azure 角色来管理对 Azure 订阅资源的访问权限中的步骤。

工作区权限

每个工作区可以关联多个帐户。 每个帐户可以访问多个工作区。 下表列出了不同工作区操作的 Azure 权限：

内置角色

将用户分配到这些角色，以便在不同的范围为其授予访问权限：

• 订阅：访问订阅中的所有工作区
• 资源组：访问资源组中的所有工作区
• 资源：仅访问指定工作区

在资源（工作区）级别创建分配，以确保准确进行访问控制。 使用自定义角色，创建具有所需的特定权限的角色。

Log Analytics 读者

Log Analytics 读取者角色的成员可以查看所有监视数据和监视设置，包括所有 Azure 资源上的 Azure 诊断配置。

Log Analytics 读者角色的成员可以：

• 查看和搜索所有监视数据。
• 查看监视设置，包括查看 Azure 诊断在所有 Azure 资源上的配置。

Log Analytics 读者角色包括以下 Azure 操作：

Log Analytics 参与者

Log Analytics 参与者角色的成员可以：

• 读取 Log Analytics 读取者角色授予的所有监视数据。
• 编辑 Azure 资源的监视设置，包括：
  • 将 VM 扩展添加到 VM。
  • 在所有 Azure 资源上配置 Azure 诊断。
• 创建和配置自动化帐户。 必须在资源组或订阅级别授予权限。
• 添加和删除管理解决方案。 必须在资源组或订阅级别授予权限。
• 读取存储帐户密钥。
• 从 Azure 存储配置日志收集。
• 运行搜索作业。
• 还原存档的日志。

Log Analytics 参与者角色包括以下 Azure 操作：

资源权限

要从资源上下文中的工作区读取数据或将数据发送到工作区，需要对资源拥有以下权限：

/read 权限通常从包含 */read 或 * 权限的角色（例如内置的读取者和参与者角色）授予。 包含特定操作的自定义角色或专用内置角色可能没有此权限。

自定义角色示例

除了为 Log Analytics 工作区使用内置角色外，还可以创建自定义角色来分配更精细的权限。 下面是一些常用示例。

示例 1：授予用户从其资源读取日志数据的权限。

• 将工作区访问控制模式配置为使用工作区或资源权限。
• 向用户授予对其资源的 */read 或 Microsoft.Insights/logs/*/read 权限。 如果已经为用户分配了对工作区的 Log Analytics 读取者角色，则不需要执行额外的操作。

示例 2：授予用户从其资源读取日志数据以及运行搜索作业的权限。

• 将工作区访问控制模式配置为使用工作区或资源权限。
• 向用户授予对其资源的 */read 或 Microsoft.Insights/logs/*/read 权限。 如果已经为用户分配了对工作区的 Log Analytics 读取者角色，则不需要执行额外的操作。
• 为用户授予对工作区的以下权限：
  • Microsoft.OperationalInsights/workspaces/tables/write：必须具有此权限才能创建搜索结果表 (_SRCH)。
  • Microsoft.OperationalInsights/workspaces/searchJobs/write：必须具有此权限才允许执行搜索作业操作。

示例 3：授予用户从其资源读取日志数据以及将其资源配置为向 Log Analytics 工作区发送日志的权限。

• 将工作区访问控制模式配置为使用工作区或资源权限。
• 为用户授予对工作区的以下权限：Microsoft.OperationalInsights/workspaces/read 和 Microsoft.OperationalInsights/workspaces/sharedKeys/action。 用户无法使用这些权限执行任何工作区级别的查询。 他们只能枚举工作区，并将其用作诊断设置或代理配置的目标。
• 为用户授予对其资源的以下权限：Microsoft.Insights/logs/*/read 和 Microsoft.Insights/diagnosticSettings/write。 如果已经为用户分配了 Log Analytics 参与者角色、读取者角色或者为其授予了对此资源的 */read 权限，则不需要执行额外的操作。

示例 4：授予用户从其资源读取日志数据的权限，但不允许将日志发送到 Log Analytics 工作区或读取安全事件。

• 将工作区访问控制模式配置为使用工作区或资源权限。
• 为用户授予对其资源的以下权限：Microsoft.Insights/logs/*/read。
• 添加以下 NonAction 以阻止用户读取 SecurityEvent 类型：Microsoft.Insights/logs/SecurityEvent/read。 NonAction 应该与提供读取权限的操作 (Microsoft.Insights/logs/*/read) 包含在同一个自定义角色中。 如果用户从已分配到此资源或已分配到订阅或资源组的另一个角色继承读取操作，他们将能够读取所有日志类型。 如果他们继承 */read（例如，“读取者”或“参与者”角色存在的此操作），此方案也是如此。

示例 5：授予用户从其资源和所有 Microsoft Entra 登录中读取日志数据以及读取 Log Analytics 工作区中的更新管理解决方案日志数据的权限。

• 将工作区访问控制模式配置为使用工作区或资源权限。
• 为用户授予对工作区的以下权限：
  • Microsoft.OperationalInsights/workspaces/read：需要此权限用户才可以枚举工作区并在 Azure 门户中打开工作区窗格
  • Microsoft.OperationalInsights/workspaces/query/read：需要此权限每位用户才可以执行查询
  • Microsoft.OperationalInsights/workspaces/query/SigninLogs/read：能够读取 Microsoft Entra 登录日志
  • Microsoft.OperationalInsights/workspaces/query/Update/read：需要此权限才能读取更新管理解决方案日志
  • Microsoft.OperationalInsights/workspaces/query/UpdateRunProgress/read：需要此权限才能读取更新管理解决方案日志
  • Microsoft.OperationalInsights/workspaces/query/UpdateSummary/read：需要此权限才能读取更新管理日志
  • Microsoft.OperationalInsights/workspaces/query/Heartbeat/read：需要此权限才能使用更新管理解决方案
  • Microsoft.OperationalInsights/workspaces/query/ComputerGroup/read：需要此权限才能使用更新管理解决方案
• 为用户授予对其资源的以下权限：分配给“读取者”角色的 */read，或 Microsoft.Insights/logs/*/read

示例 6：限制用户还原存档的日志。

• 将工作区访问控制模式配置为使用工作区或资源权限。
• 为用户分配 Log Analytics 参与者角色。
• 添加以下 NonAction 以阻止用户还原存档的日志：Microsoft.OperationalInsights/workspaces/restoreLogs/write

设置表级读取访问权限

通过表级访问设置，可以向特定用户或组授予对特定表中数据的只读权限。 具有表级读取访问权限的用户可以从工作区和资源上下文中的指定表读取数据。

授予表级读取访问权限会涉及向用户分配两个角色：

• 在工作区级别 - 一个自定义角色，可提供读取工作区详细信息和在工作区中运行查询的有限权限，但不能从任何表读取数据。
• 在表级别 - 读者角色，其范围限定为特定表。

要向用户或组授予对 Log Analytics 工作区的有限权限：

1. 在工作区级别创建自定义角色，以支持用户读取工作区详细信息并在工作区中运行查询，而无需提供对任何表中数据的读取访问权限：

   1. 导航到工作区，选择“访问控制(IAM)”>“角色”。

   2. 右键单击“读取者”角色，然后选择“克隆”。

      

      该操作将打开“创建自定义角色”屏幕。

   3. 在屏幕的“基本信息”选项卡上：

      1. 输入“自定义角色名称”值，并根据需要提供说明。
      2. 将“基线权限”设置为“从头开始”。

      

   4. 选择“JSON”选项卡 >“编辑”：

      1. 在 "actions" 部分中，添加以下操作：

         "Microsoft.OperationalInsights/workspaces/read",
         "Microsoft.OperationalInsights/workspaces/query/read" 
         

      2. 在 "not actions" 部分，添加：

         "Microsoft.OperationalInsights/workspaces/sharedKeys/read"
         

      

   5. 在屏幕底部选择“保存”>“查看 + 创建”，然后在下一页选择“创建”。

2. 将你的自定义角色分配给相关用户：

   1. 选择“访问控制(AIM)”>“添加”>“添加角色分配”。

      

   2. 选择创建的自定义角色，然后选择“下一步”。

      

      该操作将打开“添加自定义角色分配”屏幕的“成员”选项卡。

   3. 单击“+ 选择成员”，打开“选择成员”屏幕。

      

   4. 搜索并选择用户，然后单击“选择”。

   5. 选择“查看并分配”。

用户现在可以读取工作区详细信息并运行查询，但无法从任何表中读取数据。

要授予用户对特定表的读取访问权限：

1. 从“Log Analytics 工作区”菜单中，选择“表”。

2. 选择表右侧的省略号（...），然后选择“访问控制 (IAM)”。

   

3. 在“访问控制(IAM)”屏幕上，选择“添加”>“添加角色分配”。

4. 选择“读者”角色，然后选择“下一步”。

5. 单击“+ 选择成员”，打开“选择成员”屏幕。

6. 搜索并选择用户，然后单击“选择”。

7. 选择“查看并分配”。

现在，用户可以从此特定表读取数据。 根据需要授予用户对工作区中其他表的读取访问权限。

设置表级读取访问权限的旧方法

表级旧方法还使用 Azure 自定义角色，以便向特定用户或组授予对工作区中特定表的访问权限。 不管用户的访问模式是什么，Azure 自定义角色都通过工作区上下文或资源上下文访问控制模式应用至工作区。

若要定义对特定表的访问，请创建自定义角色：

• 在角色定义的“操作”部分中设置用户权限。
• 使用 Microsoft.OperationalInsights/workspaces/query/* 授予对所有表的访问权限。
• 要在“操作”中使用通配符时排除对特定表的访问，请在角色定义的“NotActions”部分列出排除的表。

下面是用于授予和拒绝对特定表的访问权限的自定义角色操作示例。

授予对 Heartbeat 和 AzureActivity 表的访问权限：

"Actions":  [
    "Microsoft.OperationalInsights/workspaces/read",
    "Microsoft.OperationalInsights/workspaces/query/read",
    "Microsoft.OperationalInsights/workspaces/query/Heartbeat/read",
    "Microsoft.OperationalInsights/workspaces/query/AzureActivity/read"
  ],

仅授予对 SecurityBaseline 表的访问权限：

"Actions":  [
    "Microsoft.OperationalInsights/workspaces/read",
    "Microsoft.OperationalInsights/workspaces/query/read",
    "Microsoft.OperationalInsights/workspaces/query/SecurityBaseline/read"
],

授予对除 SecurityAlert 表之外的其他所有表的访问权限：

"Actions":  [
    "Microsoft.OperationalInsights/workspaces/read",
    "Microsoft.OperationalInsights/workspaces/query/read",
    "Microsoft.OperationalInsights/workspaces/query/*/read"
],
"notActions":  [
    "Microsoft.OperationalInsights/workspaces/query/SecurityAlert/read"
],

与自定义表相关的旧方法的限制

自定义表存储从文本日志和 HTTP 数据收集器 API 等数据源收集的数据。 要识别表格类型，请查看 Log Analytics 中的表格信息。

使用表级访问的旧方法，无法在表级别授予对单个自定义日志表的访问权限，但可以授予对所有自定义日志表的访问权限。 若要创建一个有权访问所有自定义日志表的角色，请使用以下操作创建自定义角色：

"Actions":  [
    "Microsoft.OperationalInsights/workspaces/read",
    "Microsoft.OperationalInsights/workspaces/query/read",
    "Microsoft.OperationalInsights/workspaces/query/Tables.Custom/read"
],

表级访问注意事项和限制

• 在 Log Analytics UI 中，表级用户可以查看工作区中所有表的列表，但只能从其有权访问的表中检索数据。
• 标准读者或参与者角色（包括 */read 操作）将替代表级访问控制，并向用户授予对所有日志数据的访问权限。
• 如果用户具有表级访问权限，但没有工作区级访问权限，则可以通过 API 但不能通过 Azure 门户访问日志数据。
• 无论任何其他权限设置如何，订阅管理员和所有者有权访问所有数据类型。
• 应用按表进行的访问控制时，工作区所有者被视为类似于其他任何用户。
• 将角色分配到安全组而不是个人用户，以减少分配数目。 这种做法还有助于使用现有的组管理工具来配置和验证访问权限。

后续步骤

• 请参阅 Log Analytics 代理概述，以从数据中心或其他云环境中的计算机收集数据。