管理对 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.Resources/deployments/*
Microsoft.OperationalInsights/*
Microsoft.OperationsManagement/*
Microsoft.Automation/*
Microsoft.Resources/deployments/*/write

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

访问通过经典部署模型部署的资源。

内置角色

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

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

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

注意

若要为某个用户角色添加和删除用户,必须拥有 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 和安装代理所必需的。 这可以防止用户向工作区添加新资源。
操作 Microsoft.OperationalInsights/workspaces/analytics/query/action 已弃用。
操作 Microsoft.OperationalInsights/workspaces/search/action 已弃用。

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/<tableName>/read

示例:
Microsoft.Insights/logs/*/read
Microsoft.Insights/logs/Heartbeat/read
可以查看资源的所有日志数据
Microsoft.Insights/diagnosticSettings/write 可配置诊断设置以允许设置此资源的日志

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

自定义角色示例

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

授予用户从其资源访问日志数据的权限:

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

授予用户从其资源访问日志数据并将其资源配置为向工作区发送日志的权限:

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

授予用户从其资源访问日志数据的权限,但不允许他们读取安全事件和发送数据:

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

授予用户从其资源访问日志数据,以及从工作区读取所有 Azure AD 登录和更新管理解决方案日志数据的权限:

  • 将工作区访问控制模式配置为使用工作区或资源权限。
  • 为用户授予对工作区的以下权限:
    • Microsoft.OperationalInsights/workspaces/read:需要此权限用户才可以枚举工作区并在 Azure 门户中打开工作区窗格
    • Microsoft.OperationalInsights/workspaces/query/read:需要此权限每位用户才可以执行查询
    • Microsoft.OperationalInsights/workspaces/query/SigninLogs/read:需要此权限才能读取 Azure AD 登录日志
    • 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

设置表级读取访问权限

要创建允许特定用户或组从工作区的特定表中读取数据的自定义角色,请执行以下操作:

  1. 基于内置 Azure Monitor 日志“读取者”角色,创建授予对表数据的读取权限的自定义角色:

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

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

      显示了访问控制屏幕的“角色”选项卡的屏幕截图,其中突出显示“读取者”角色的“克隆”按钮。

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

    3. 在屏幕的“基本信息”选项卡上,输入“自定义角色名称”值,并根据需要提供说明。

      显示了“创建自定义角色”屏幕的“基本信息”选项卡的屏幕截图,其中突出显示了“自定义角色名称”和“说明”字段。

    4. 选择“JSON”选项卡>“编辑”,编辑 "actions" 部分,使其仅包含 Microsoft.OperationalInsights/workspaces/query/read,然后选择“保存”。

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

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

    6. 复制自定义角色 ID:

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

      2. 右键单击自定义角色,然后选择“编辑”。

        该操作将打开自定义角色屏幕。

        显示自定义角色屏幕的 JSON 选项卡的屏幕截图,其中突出显示 ID 字段。

      3. 选择“JSON”并复制 id 字段。

        调用 https://management.chinacloudapi.cn/batch?api-version=2020-06-01 POST API 时,你将需要 /providers/Microsoft.Authorization/roleDefinitions/<definition_id> 值。

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

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

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

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

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

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

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

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

    4. 搜索并选择相关的用户或组,然后单击“选择”。

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

  3. 通过调用 https://management.chinacloudapi.cn/batch?api-version=2020-06-01 POST API 并在请求正文中发送以下详细信息,授予用户或组对工作区中特定表的读取访问权限:

    {
        "requests": [
            {
                "content": {
                    "Id": "<GUID_1>",
                    "Properties": {
                        "PrincipalId": "<User_object_ID>",
                        "PrincipalType": "User",
                        "RoleDefinitionId": "<custom_role_ID>",
                        "Scope": "/subscriptions/<subscription_ID>/resourceGroups/<resource_group_name>/providers/Microsoft.OperationalInsights/workspaces/<workspace_name>/Tables/<table_name>",
                        "Condition": null,
                        "ConditionVersion": null
                    }
                },
                "httpMethod": "PUT",
                "name": "<GUID_2>",
                "requestHeaderDetails": {
                    "commandName": "Microsoft_Azure_AD."
                },
                "url": "/subscriptions/<subscription_ID>/resourceGroups/<resource_group_name>/providers/Microsoft.OperationalInsights/workspaces/<workspace_name>/Tables/<table_name>/providers/Microsoft.Authorization/roleAssignments/<GUID_1>?api-version=2020-04-01-preview"
            }
        ]
    }
    

    其中:

    • 可以使用任何 GUID 生成器为 <GUID 1><GUID 2> 生成 GUID。
    • <custom_role_ID> 是你之前复制的 /providers/Microsoft.Authorization/roleDefinitions/<definition_id> 值。
    • <subscription_ID> 是与工作区相关的订阅的 ID。
    • <resource_group_name> 是工作区的资源组。
    • <workspace_name> 是工作区的名称。
    • <table_name> 是要分配用户或组其读取数据权限的表的名称。

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

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"
],

管理对自定义日志访问权限的另一种方法是将其分配给 Azure 资源,然后使用资源上下文访问控制管理访问权限。 在通过 HTTP 数据收集器 API 将数据引入到 Log Analytics 时,通过在 x-ms-AzureResourceId 标头中指定资源 ID 来将其包含在内。 资源 ID 必须有效,并且具有适用的访问规则。 引入日志后,对资源拥有读取访问权限的用户可以访问这些日志。

某些自定义日志来自与特定资源不直接关联的源。 在这种情况下,请创建一个资源组来管理对这些日志的访问权限。 资源组不会产生任何费用,但会提供有效的资源 ID 来控制对自定义日志的访问。

例如,如果特定防火墙正在发送自定义日志,请创建一个名为 MyFireWallLogs 的资源组。 确保 API 请求中包含资源 ID MyFireWallLogs。 然后,仅有权访问 MyFireWallLogs 或具有完整工作区访问权限的用户才能访问防火墙日志记录。

注意事项

  • 如果为某个用户授予全局读取权限以及含有 */read 操作的标准“读取者”或“参与者”角色,则会替代按表进行的访问控制,并向该用户授予所有日志数据的访问权限。
  • 如果为某个用户授予按表访问权限但未授予其他任何权限,则该用户可以通过 API 访问日志数据,但不能通过 Azure 门户进行访问。 若要从 Azure 门户提供访问权限,请使用“Log Analytics 读取者”作为用户的基本角色。
  • 无论任何其他权限设置如何,订阅管理员和所有者都有权访问所有数据类型。
  • 应用按表进行的访问控制时,工作区所有者被视为类似于其他任何用户。
  • 将角色分配到安全组而不是个人用户,以减少分配数目。 这种做法还有助于使用现有的组管理工具来配置和验证访问权限。

后续步骤