数据 RBAC 概览

支持的语言:

基于数据角色的访问权限控制数据 RBAC)是一种安全模型,它使用个人用户角色来限制用户对组织内数据的访问权限。借助数据 RBAC,管理员可以定义范围并将其分配给用户,以确保用户只能访问其工作职能所需的数据。

本页简要介绍了数据 RBAC,并帮助您了解标签和范围如何协同工作来定义数据访问权限。

数据 RBAC 与功能 RBAC 之间的区别

数据 RBAC 和功能 RBAC 都是用于控制系统内访问权限的方法,但它们侧重于不同的方面。

功能 RBAC 用于控制对系统内特定功能或特性的访问权限。它会根据用户的角色确定用户可以访问哪些功能。例如,初级分析师可能只有查看信息中心的权限,而没有创建或修改检测规则的权限;高级分析师则可能拥有创建和管理检测规则的权限。如需详细了解功能 RBAC,请参阅使用 IAM 配置功能访问权限控制

数据 RBAC 可控制对系统内特定数据或信息的访问权限。它可根据用户的角色控制用户是否可以查看、修改或删除数据。例如,在客户关系管理 (CRM) 系统中,销售代表可能可以访问客户联系数据,但无法访问财务数据,而财务经理可能可以访问财务数据,但无法访问客户联系数据。

数据 RBAC 和功能 RBAC 通常一起使用,以提供全面的访问权限控制系统。例如,用户可能获准访问特定功能(功能 RBAC),然后,在该功能内,系统可能会根据用户的角色限制其对特定数据的访问权限(数据 RBAC)。

规划实现

为了规划实现,请查看 Google Security Operations 预定义的 Google SecOps 角色和权限列表,并根据贵组织的需求进行调整。制定策略来定义范围并标记传入的数据。确保您拥有 Role Viewer (roles/iam.roleViewer) 角色,以便管理范围。 确定哪些成员必须有权访问这些范围内的内容。

如果您的组织需要预定义的 Google SecOps 角色无法满足的 IAM 政策,请创建自定义角色以支持特定要求。

用户角色

用户可以拥有范围限定的数据访问权限(范围限定的用户),也可以拥有全局数据访问权限(全局用户)。

  • 范围受限的用户只能根据分配的范围有限地访问数据。这些范围会将应用的可见性和操作限制为特定数据。下表详细说明了与范围限定的访问权限相关联的具体权限。

  • 全局用户没有分配的范围,可以不受限制地访问 Google SecOps 中的所有数据。下表详细说明了与全局访问权限相关联的具体权限。

全球访问权限会覆盖范围受限的访问权限。如果用户同时被分配了全局角色和范围限定的角色,则无论范围限定的角色施加了何种限制,他们都可以访问所有数据。

数据 RBAC 管理员可以创建范围并将其分配给用户,以控制用户在 Google SecOps 中的数据访问权限。如需将用户限制在特定范围内,您必须向其分配 Chronicle API Restricted Data Access (roles/chronicle.restrictedDataAccess) 角色以及预定义角色或自定义角色。Chronicle API Restricted Data Access 角色会将用户标识为范围限定的用户。对于需要全局数据访问权限的用户,您无需为其分配 Chronicle 受限数据访问权限角色。

您可以为用户分配以下角色:

访问类型 角色 权限
预定义的全局访问权限 可以向全球用户授予任何预定义的 IAM 角色
预定义的范围限定的只读权限 Chronicle API Restricted Data Access (roles/chronicle.restrictedDataAccess) 和 Chronicle API Restricted Data Access Viewer (roles/chronicle.restrictedDataAccessViewer) Chronicle API Restricted Data Access Viewer
自定义范围的访问权限 Chronicle API Restricted Data Access (roles/chronicle.restrictedDataAccess) 和自定义角色(用于功能 RBAC 定义) 功能中的自定义权限
自定义全球访问权限 chronicle.globalDataAccessScopes.permit 权限和 Chronicle API Global Data Access (roles/globalDataAccess) 功能中的全局权限

下表介绍了每种访问权限类型:

预定义全局访问权限:需要访问所有数据的用户通常需要此访问权限。您可以根据所需的权限为用户分配一个或多个角色。

预定义的范围受限的只读访问权限:此访问权限适用于需要只读访问权限的用户。Chronicle API Restricted Data Access 角色会将用户标识为限定范围的用户。Chronicle API Restricted Data Access Viewer 角色可让用户在其功能范围内查看数据。

自定义范围的访问权限:Chronicle API 受限数据访问权限角色会将用户标识为范围用户。自定义角色指定了用户可以访问的功能。添加到 Chronicle API 受限数据访问权限的角色中的范围指定了用户可以在功能中访问的数据。

如需验证 RBAC 自定义范围是否正常运行,请在创建自定义角色时添加 chronicle.dataAccessScopes.list 权限。不过,请勿添加 chronicle.DataAccessScopes.permitchronicle.globalDataAccessScopes.permit 权限。如果您使用预构建的 Chronicle API Editor 或 Chronicle API Admin 作为自定义角色的起点,则这些权限可能会包含在其中。

自定义全局访问权限:此访问权限适用于需要在分配的功能中拥有不受限权限的用户。如需向用户授予自定义全局访问权限,除了分配给用户的自定义角色之外,您还必须指定 chronicle.globalDataAccessScopes.permit 权限。

使用范围和标签控制访问权限

借助 Google SecOps,您可以使用范围控制用户的数据访问权限。范围是借助标签定义的,这些标签定义了范围内的用户可以访问的数据。在提取期间,系统会以标签的形式为数据分配元数据,例如命名空间(可选)、提取元数据(可选)和日志类型(必需)。这些是应用于提取期间的数据的默认标签。此外,您还可以创建自定义标签。 您可以使用默认标签和自定义标签来定义范围以及这些范围将定义的数据访问权限级别。

使用允许和拒绝标签实现的数据可见性

每个范围都包含一个或多个允许访问标签,还可以选择性地包含拒绝访问标签。借助访问权限标签,用户可以访问与该标签相关联的数据。拒绝访问标签会拒绝用户访问与该标签相关联的数据。在限制用户访问权限时,拒绝访问标签会替换允许访问标签。

在范围定义中,允许的同类型访问标签(例如,日志类型)使用 OR 运算符组合,而不同类型的标签(例如,日志类型和自定义标签)使用 AND 运算符组合。拒绝访问标签使用 OR 运算符组合在一起。如果在某个范围内应用了多个拒绝访问标签,那么只要与其中任何一个标签匹配,就会拒绝访问。

例如,假设有一个 Cloud Logging 系统使用以下标签类型对日志进行分类:

日志类型:访问、系统、防火墙

命名空间:App1、App2、数据库

严重程度:严重、警告

假设有一个名为“受限日志”的范围,具有以下访问权限:

标签类型 允许使用的值 拒绝的值
日志类型 访问权限、防火墙 系统
命名空间 App1 应用 2,数据库
严重程度 警告 严重

范围定义如下所示:

允许(Log type: "Access" OR "Firewall") AND (Namespace: "App1") AND (Severity: "Warning")

拒绝Log type: "System" OR Namespace: App2 OR Namespace: Database OR Severity: "Critical"

与范围匹配的日志示例:

  • 来自应用 1 的访问日志,严重程度为“警告”
  • 来自 App1 的防火墙日志,严重程度为“警告”

不符合范围的日志示例:

  • 来自应用 1 的系统日志,严重程度:警告
  • 数据库中严重程度为“警告”的访问日志
  • 来自应用 2 的防火墙日志,严重程度为“严重”

丰富事件中的数据可见性

丰富事件是指在原始日志数据的基础上,通过添加更多上下文和信息来增强的安全事件。只有在以下情况下,才能在某个范围内访问富化事件:其基本事件可在该范围内访问,并且任何富化标签都不包含该范围的任何拒绝标签。

例如,假设某原始日志显示来自某个 IP 地址的登录尝试失败,并且具有富化标签 user_risk: high(表示用户风险较高)。 如果用户的范围具有拒绝标签 user_risk: high,则无法查看高风险用户的登录失败尝试。

数据 RBAC 对 Google Security Operations 功能的影响

配置数据 RBAC 后,用户开始在 Google Security Operations 功能中看到过滤后的数据。影响取决于该功能与底层数据的集成方式。如需了解数据 RBAC 对各项功能的影响,请参阅数据 RBAC 对 Google Security Operations 功能的影响

后续步骤

需要更多帮助?从社区成员和 Google SecOps 专业人士那里获得解答。