在 Log Analytics 工作区中管理表级访问

可通过三种方法使用基于角色的访问控制(RBAC)在 Log Analytics 工作区中管理表级访问。 本文引用了所有方法,不过仅推荐使用精细 RBAC。

细粒度的 RBAC 允许在表或行级别精细调整访问权限。 具有表级访问权限的用户可以从工作区和资源上下文中的指定表读取数据和查询。 有关详细信息,请参阅 精细化 RBAC。

为表级访问配置精细 RBAC

使用精细 RBAC 的表级访问配置不如早期方法复杂,并且提供了实现行级访问控制的灵活性。 不过,这些步骤仅侧重于配置表级访问。 有关详细信息,请参阅 精细化 RBAC。

为表级访问配置精细 RBAC 需要执行以下步骤:

  1. 选择内置的 Log Analytics 数据读取者 角色,或创建自定义角色
  2. 为分配的角色生成条件(宽松或限制性)

创建精细的 RBAC 自定义角色

控制平面中的“数据操作”不仅能够实现细粒度的 RBAC,还不同于以往仅支持配置表级访问的方法,并且已经在内置的 Log Analytics 数据读取器 角色中配置完成。 如果未选择内置角色,请按照以下步骤创建自定义角色。 有关详细信息,请参阅 创建精细的 RBAC 角色分配。

下面是示例自定义角色的 JSON:

{    "properties": {
        "roleName": "Log Analytics Standard Table Access",
        "description": "This custom role provides general access to all non-restricted tables.",
        "assignableScopes": [
            "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/contoso-US-la-workspace"
        ],
        "permissions": [
            {
                "actions": [
                    "Microsoft.OperationalInsights/workspaces/read",
                    "Microsoft.OperationalInsights/workspaces/query/read"
                ],
                "notActions": [],
                "dataActions": [
                    "Microsoft.OperationalInsights/workspaces/tables/data/read"
                ],
                "notDataActions": []
            }
        ]
    }
}

将角色分配给用户或组。 有关详细信息,请参阅 分配精细的 RBAC 角色。

  1. 在 Log Analytics 工作区中,选择“访问控制”(IAM)。
  2. 选择“添加角色分配”。
  3. Log Analytics Standard Table Access选择你创建的示例自定义角色,然后选择“下一步”。
  4. 选择要向其分配角色的用户或组,然后选择“ 下一步”。 此示例将角色分配给网络团队安全组。
  5. 选择条件>添加条件>添加动作。
  6. 选择“读取工作区数据”数据操作>“选择”。

生成宽松条件

此示例使用“访问所有数据,除非不允许访问的数据”策略来构建一个宽松条件。 访问权限仅限于 SigninLogs 表和 SecurityEvent 表,但允许访问所有其他表。 若要查看限制条件的示例,请参阅 粒度 RBAC 用例。

  1. 在 “生成表达式 ”部分中,选择“ 添加表达式”
  2. 从“属性源”下拉列表中选择“资源”。
  3. 从“属性”下拉列表中选择“表名称”。
  4. 从“运算符”下拉列表中选择 ForAnyOfAllValues:StringNotEquals。
  5. 在SigninLogs字段中键入SecurityEvent和输入。

下面是完成时允许的表级访问条件的外观。

细粒度 RBAC 表级允许访问条件的屏幕截图。

使用单个角色分配时,将配置表级访问,将受限表与标准表分开。 有关详细信息,请参阅 精细 RBAC 注意事项 和 精细 RBAC 故障排除。

配置表级访问(双重角色方法)

最佳做法是使用精细的 RBAC 方法而不是此方法。 有关参考,本部分概述了如何配置双重角色方法的步骤。

此表级访问控制方法还使用 Azure 自定义角色向用户或组授予对工作区中特定表的访问权限,但需要为每个用户或组分配两个角色。

Scope 角色说明
工作空间 提供有限权限的自定义角色,用于读取工作区详细信息并在工作区中运行查询,但不能从任何表读取数据
表 范围限定为特定表的 读取者 角色

生成工作区角色

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

  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. 选择“保存>审阅 + 创建>”。
  6. 选择“访问控制(AIM)”“添加”>“添加角色分配”。
  7. 选择创建的自定义角色,然后选择“下一步”。 该操作将打开“添加自定义角色分配”屏幕的“成员”选项卡。
  8. + 选择成员 以打开 “选择成员” 屏幕。
  9. 搜索用户 >选择。
  10. 选择“查看并分配”。

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

分配表访问权限角色

  1. 从“Log Analytics 工作区”菜单中,选择“表”。
  2. 选择表右侧的省略号(...),然后选择“访问控制 (IAM)”。 屏幕截图显示了 Log Analytics 工作区标管理屏幕,其中突出显示了“表级访问权限控制”按钮。
  3. 在“访问控制(IAM)”屏幕上,选择“添加”>“添加角色分配”。
  4. 选择“读者”角色,然后选择“下一步”。
  5. + 选择成员 以打开 “选择成员” 屏幕。
    1. 搜索用户 >选择。
  6. 选择“查看并分配”。

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

配置表级访问(旧方法)

不再建议使用表级访问控制的旧方法。 它不支持行级条件,比精细 RBAC 方法复杂。 最佳做法是使用精细的 RBAC 方法而不是此方法。 有关参考,本部分概述了如何配置旧方法的步骤。

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

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

  1. 在角色定义的“操作”部分中设置用户权限。
  2. 使用 Microsoft.OperationalInsights/workspaces/query/* 授予对所有表的访问权限。
  3. 要在“操作”中使用通配符时排除对特定表的访问,请在角色定义的“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 门户访问日志数据。
  • 无论任何其他权限设置如何,订阅管理员和所有者有权访问所有数据类型。
  • 应用按表进行的访问控制时,工作区所有者被视为类似于其他任何用户。
  • 将角色分配到安全组而不是个人用户,以减少分配数目。 此最佳做法可帮助你使用现有的组管理工具来配置和验证访问权限。