你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

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

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

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

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

概述

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

因子 说明
访问模式 访问工作区所用的方法。 定义可用数据的范围,以及应用的访问控制模式。
访问控制模式 工作区中的设置,用于定义是要在工作区级别还是资源级别应用权限。
Azure 基于角色的访问控制 (RBAC) 应用于工作区的或向工作区发送数据的资源的个人或用户组的权限。 定义你有权访问的数据。
表级别 Azure RBAC 定义你可以在工作区中访问的特定数据类型的可选权限。 可以应用于所有访问模式或访问控制模式。

访问模式

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

有两种访问模式:

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

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

以下资源存在已知限制:

比较访问模式

下表汇总了访问模式:

问题 工作区上下文 资源上下文
每种模式适合哪类用户? 集中管理。
需要配置数据收集的管理员,以及需要访问各种资源的用户。 此外,需要访问 Azure 外部资源的日志的用户目前也需要使用此模式。
应用程序团队。
受监视 Azure 资源的管理员。 使他们能够专注于自己的资源而无需筛选。
用户需要哪些权限才能查看日志? 对工作区的权限。
请参阅使用工作区权限管理访问权限中的“工作区权限”。
对资源的读取访问权限。
请参阅使用 Azure 权限管理访问权限中的“资源权限”。 权限可以从资源组或订阅继承,也可以直接分配给资源。 系统会自动分配对资源日志的权限。 用户不需要访问工作区。
权限范围是什么? 工作区。
有权访问工作区的用户可以通过他们有权访问的表查询该工作区中的所有日志。 请参阅设置表级读取访问权限
Azure 资源。
用户可以在任何工作区中查询他们有权访问的资源、资源组或订阅的日志,但无法查询其他资源的日志。
用户如何访问日志? 在“Azure Monitor”菜单中选择“日志”。

在“Log Analytics 工作区”中选择“日志”。

从 Azure Monitor 工作簿
在 Azure 资源的菜单中选择“日志”。 用户有权访问该资源的数据。

在“Azure Monitor”菜单中选择“日志”。 用户有权访问他们有权访问的所有资源的数据。

如果用户有权访问该工作区,请选择“Log Analytics 工作区”中的“日志”。

从 Azure Monitor 工作簿

访问控制模式

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

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

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

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

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

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

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

    注意

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

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

在工作区“概述”页上的“Log Analytics 工作区”菜单中查看当前的工作区访问控制模式。

显示工作区访问控制模式的屏幕截图。

在工作区的“属性”页中更改此设置。 如果你无权配置工作区,则会禁止更改此设置。

显示更改工作区访问模式的屏幕截图。

Azure RBAC

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

工作区权限

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

操作 所需 Azure 权限 说明
更改定价层。 Microsoft.OperationalInsights/workspaces/*/write
在 Azure 门户中创建工作区。 Microsoft.Resources/deployments/*
Microsoft.OperationalInsights/workspaces/*
查看工作区基本属性并进入门户中的工作区窗格。 Microsoft.OperationalInsights/workspaces/read
使用任何接口查询日志。 Microsoft.OperationalInsights/workspaces/query/read
使用查询访问所有日志类型。 Microsoft.OperationalInsights/workspaces/query/*/read
访问特定的日志表 - 旧方法 Microsoft.OperationalInsights/workspaces/query/<table_name>/read
读取工作区密钥,以便能够将日志发送到此工作区。 Microsoft.OperationalInsights/workspaces/sharedKeys/action
创建或更新摘要规则 Microsoft.Operationalinsights/workspaces/summarylogs/write
添加和删除监视解决方案。 Microsoft.Resources/deployments/*
Microsoft.OperationalInsights/*
Microsoft.OperationsManagement/*
Microsoft.Automation/*
Microsoft.Resources/deployments/*/write

需要在资源组或订阅级别授予这些权限。
查看“备份”和“Site Recovery”解决方案磁贴中的数据。 管理员/共同管理员

访问通过经典部署模型部署的资源。
运行搜索作业。 Microsoft.OperationalInsights/workspaces/tables/write
Microsoft.OperationalInsights/workspaces/searchJobs/write
从存档的表还原数据。 Microsoft.OperationalInsights/workspaces/tables/write
Microsoft.OperationalInsights/workspaces/restoreLogs/write

内置角色

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

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

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

注意

若要为某个用户角色添加和删除用户,必须拥有 Microsoft.Authorization/*/DeleteMicrosoft.Authorization/*/Write 权限。

Log Analytics 读者

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

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

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

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

类型 权限 说明
操作 */read 能够查看所有 Azure 资源和资源配置。
包括查看:
- 虚拟机扩展状态。
- Azure 诊断在资源上的配置。
- 所有资源的所有属性和设置。

对于工作区,允许使用完全不受限制的权限来读取工作区设置和查询数据。 在前面的列表中查看更精细的选项。
操作 Microsoft.Support/* 能够创建支持案例。
非操作 Microsoft.OperationalInsights/workspaces/sharedKeys/read 防止读取工作区密钥,该密钥是使用数据集合 API 和安装代理所必需的。 这可以防止用户向工作区添加新资源。

Log Analytics 参与者

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

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

警告

可以使用该权限向虚拟机添加虚拟机扩展,以获取对虚拟机的完全控制。

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

权限 说明
*/read 能够查看所有 Azure 资源和资源配置。

包括查看:
- 虚拟机扩展状态。
- Azure 诊断在资源上的配置。
- 所有资源的所有属性和设置。

对于工作区,允许使用完全不受限制的权限来读取工作区设置和查询数据。 在前面的列表中查看更精细的选项。
Microsoft.Automation/automationAccounts/* 能够创建和配置 Azure 自动化帐户,包括添加和编辑 runbook。
Microsoft.ClassicCompute/virtualMachines/extensions/*
Microsoft.Compute/virtualMachines/extensions/*
添加、更新和删除虚拟机扩展,包括 Microsoft Monitoring Agent 扩展和 OMS Agent for Linux 扩展。
Microsoft.ClassicStorage/storageAccounts/listKeys/action
Microsoft.Storage/storageAccounts/listKeys/action
查看存储帐户密钥。 在将 Log Analytics 配置为从 Azure 存储帐户读取日志时需要。
Microsoft.Insights/alertRules/* 添加、更新和删除警报规则。
Microsoft.Insights/diagnosticSettings/* 添加、更新和删除 Azure 资源上的诊断设置。
Microsoft.OperationalInsights/* 添加、更新和删除 Log Analytics 工作区的配置。 若要编辑工作区高级设置,用户需要 Microsoft.OperationalInsights/workspaces/write
Microsoft.OperationsManagement/* 添加和删除管理解决方案。
Microsoft.Resources/deployments/* 创建和删除部署。 添加和删除解决方案、工作区和自动化帐户所必需。
Microsoft.Resources/subscriptions/resourcegroups/deployments/* 创建和删除部署。 添加和删除解决方案、工作区和自动化帐户所必需。

资源权限

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

权限 说明
Microsoft.Insights/logs/*/read 可以查看资源的所有日志数据
Microsoft.Insights/logs/<tableName>/read
例如:
Microsoft.Insights/logs/Heartbeat/read
能够查看此资源的特定表 - 旧方法
Microsoft.Insights/diagnosticSettings/write 可配置诊断设置以允许设置此资源的日志

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

自定义角色示例

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

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

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

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

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

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

  • 将工作区访问控制模式配置为使用工作区或资源权限。
  • 为用户授予对工作区的以下权限:Microsoft.OperationalInsights/workspaces/readMicrosoft.OperationalInsights/workspaces/sharedKeys/action。 用户无法使用这些权限执行任何工作区级别的查询。 他们只能枚举工作区,并将其用作诊断设置或代理配置的目标。
  • 为用户授予对其资源的以下权限:Microsoft.Insights/logs/*/readMicrosoft.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

设置表级读取访问权限

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

注意

建议使用此处所述的方法(目前处于预览状态)来定义表级访问权限。 或者可以使用设置表级读取访问权限的旧方法,该方法具有一些与自定义日志表相关的限制。 在预览期间,此处所述的建议方法不适用于 Microsoft Sentinel 检测规则,因为后者可能有权访问比预期更多的表。 在使用任一方法之前,请参阅表级访问注意事项和限制

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

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

要向用户或组授予对 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"
        

      显示了“创建自定义角色”屏幕的“JSON”选项卡的屏幕截图,其中突出显示了 JSON 文件的操作部分。

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

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

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

      显示“访问控制”屏幕的屏幕截图,其中突出显示了“添加角色分配”按钮。

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

      显示“添加角色分配”屏幕的屏幕截图,其中突出显示了自定义角色和“下一步”按钮。

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

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

      显示选择成员屏幕的屏幕截图。

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

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

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

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

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

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

    屏幕截图显示了 Log Analytics 工作区标管理屏幕,其中突出显示了“表级访问权限控制”按钮。

  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 门户访问日志数据。
  • 无论任何其他权限设置如何,订阅管理员和所有者有权访问所有数据类型。
  • 应用按表进行的访问控制时,工作区所有者被视为类似于其他任何用户。
  • 将角色分配到安全组而不是个人用户,以减少分配数目。 这种做法还有助于使用现有的组管理工具来配置和验证访问权限。

后续步骤