BigQuery 行级安全性简介

本文档介绍行级安全性的概念、BigQuery 中的行级安全性工作原理、何时使用行级安全性来保护数据以及其他详细信息。

什么是行级安全性?

行级安全性可让您过滤数据,并在符合用户条件时启用对表中特定行的访问权限。

BigQuery 通过政策标记支持项目、数据集和表级层的访问权限控制以及列级安全性。行级安全性通过行级访问权限政策实现对 BigQuery 表中部分数据的精细访问权限控制,从而深化了最小权限原则。

一个表可以有多个行级访问权限政策。表的行级访问权限政策可以与 列级安全性以及数据集级表级项目级访问权限控制共存

行级安全性的工作原理

概括来讲,行级安全性涉及针对目标 BigQuery 表创建行级访问权限政策。这些政策会充当过滤条件,以隐藏或显示某些数据行,具体取决于用户或群组是否在许可名单中。 未明确添加到许可名单的任何用户或群组均会被拒绝访问。

具有 Identity and Access Management (IAM) 角色 BigQuery Admin 或 BigQuery DataOwner 的授权用户可以针对 BigQuery 表创建行级访问权限政策。

创建行级访问权限政策时,您可以按名称指定表,并指定哪些用户或群组(称为 grantee-list)可以访问某些行数据。该政策还包含您要过滤的数据,称为 filter_expressionfilter_expression 函数类似于典型查询中的 WHERE 子句。

如需了解如何创建和使用行级访问权限政策,请参阅使用行级安全性

请查看 DDL 参考文档,了解创建行级访问权限政策时的完整语法、使用方法和选项。

应用场景示例

以下示例展示了行级安全性的潜在应用场景。

根据区域过滤行数据

假设表 dataset1.table1 包含属于不同区域(由 region 列表示)的行。

您可以使用以下查询来创建和填充示例表:

CREATE TABLE IF NOT EXISTS
  dataset1.table1 (partner STRING,
    contact STRING,
    country STRING,
    region STRING);
INSERT INTO
  dataset1.table1 (partner,
    contact,
    country,
    region)
VALUES
  ('Example Customers Corp', 'alice@examplecustomers.com', 'Japan', 'APAC'),
  ('Example Enterprise Group', 'bob@exampleenterprisegroup.com', 'Singapore', 'APAC'),
  ('Example HighTouch Co.', 'carrie@examplehightouch.com', 'USA', 'US'),
  ('Example Buyers Inc.', 'david@examplebuyersinc.com', 'USA', 'US');

行级安全性可让数据所有者或管理员实现相关政策。以下语句会实现一项政策,即限制 APAC 邮寄名单群组中的用户只能查看 APAC 区域的合作伙伴:

CREATE ROW ACCESS POLICY
  apac_filter
ON
  dataset1.table1 GRANT TO ("group: sales-apac@example.com")
FILTER USING
  (region="APAC" );

产生的行为是 sales-apac@example.com 群组中的用户只能查看 region 的值为 APAC 的行。

以下语句会实现一项政策,即限制个人和群组只能查看美国区域的合作伙伴:

CREATE ROW ACCESS POLICY
  us_filter
ON
  dataset1.table1 GRANT TO ("group:sales-us@example.com",
"user: jon@example.com")
FILTER USING
  (region="US");

产生的行为是群组 sales-us@example.com 中的用户和用户 jon@example.com 只能查看 region 的值为 US 的行。

下图展示了前面提到的两项访问权限政策如何限制哪些用户和群组可以查看表中的哪些行:

针对区域的行级安全性应用场景

不在 APACUS 群组中的用户不会看到任何行。

根据敏感数据过滤行数据

现在,假设另一个应用场景,您有一个包含薪资信息的表。

您可以使用以下查询来创建和填充示例表:

CREATE OR REPLACE TABLE
  dataset1.table1 (name STRING,
    department STRING,
    salary INT64,
    email STRING);
INSERT INTO
  dataset1.table1 ( name,
    department,
    salary,
    email)
VALUES
  ('Jim D', 'HR', 100000, 'jim@example.com'),
  ('Anna K', 'Finance', 100000, 'anna@example.com'),
  ('Bruce L', 'Engineering', 100000, 'bruce@example.com'),
  ('Carrie F', 'Business', 100000, 'carrie@example.com');

以下语句中的行访问权限政策会限制只有公司网域的成员才能执行查询。此外,使用 SESSION_USER() 函数根据用户电子邮件地址将访问权限限制为仅属于运行查询的用户的行。

CREATE ROW ACCESS POLICY
  salary_personal
ON
  dataset1.table1 GRANT TO ("domain:example.com")
  FILTER USING
  (Email=SESSION_USER());

下图演示了行访问权限政策如何限制包含薪资信息的表。在此示例中,用户名为 Jim,电子邮件地址为 jim@example.com

针对薪资的行级安全性用例

根据对照表过滤行数据

如需针对此功能提供反馈或请求支持,请发送电子邮件至 bigquery-row-level-security-support@google.com。

凭借子查询支持,行访问权限政策可以引用其他表并将其用作对照表。过滤规则中使用的数据存储在表中,单个子查询行访问权限政策可以替换多个已配置的行访问权限政策。如需更新行访问权限政策,您只需更新对照表,这样就可以替换多个行访问权限政策。您无需更新各个行访问权限政策。

何时使用行级安全性或其他方法

已获授权的视图、行级访问权限政策和将数据存储在单独的表中,全都可以提供不同级别的安全性、性能和便利性。为您的用例选择合适的机制非常重要,可确保数据的正确安全性级别。

与授权视图比较:漏洞

若使用不当,行级安全性和通过授权视图强制执行行级访问都会存在漏洞。

使用授权视图或行级访问权限政策实现行级安全性时,我们建议您使用审核日志记录功能来监控任何可疑的活动。

旁道(例如查询时长)可能会泄露有关在存储分片边缘的行的信息。此类攻击可能需要了解表的分片方式或需要执行大量查询。

如需详细了解如何防止此类旁道攻击,请参阅行级安全性方面的最佳实践

授权视图、行级安全性和单独的表比较

下表比较了已获授权的视图、行级访问权限政策和单独的表的灵活性、性能和安全性。

方法 安全注意事项 建议
授权
视图
建议用于灵活性。可能容易受到精心设计的查询、查询时长和其他类型的边信道攻击。 如果您需要与其他人共享数据并且灵活性和性能非常重要,则已获授权的视图是一个不错的选择。例如,您可以使用授权视图在工作组内共享数据。
行级访问权限政策 建议用于兼顾灵活性和安全性。可能容易受到查询时长边信道攻击 如果您需要与他人共享数据,并且希望为视图或表切片提供额外的安全保障,则行级访问权限政策是一个不错的选择。例如,您可以使用行级访问权限政策与使用同一信息中心的所有人共享数据,即使有些人有权访问比其他人更多的数据也是如此。
单独的表 建议用于安全性。用户在无权访问表时无法推断数据。 如果您需要与其他人共享数据并且需要保持数据隔离状态,则单独的表是一个不错的选择。例如,当行总数必须为机密时,您可以使用单独的表与第三方合作伙伴和供应商共享数据。

创建和管理行级访问权限政策

如需了解如何创建、更新(重新创建)、列出、查看和删除表的行级访问权限政策,以及如何查询具有行级访问权限政策的表,请参阅使用行级访问权限安全性

配额

如需详细了解行级安全性的配额和限制,请参阅 BigQuery 配额和限制

价格

BigQuery 提供行级安全性,无需额外费用。但是,行级访问权限政策可通过以下方式影响运行查询的费用:

  • 行级访问权限政策(特别是包含引用其他表的子查询的政策)可能会导致额外计费。

  • 行级访问权限政策过滤条件不参与查询对分区表和聚类表进行删减。这并不意味着它会在主查询执行期间读取更多数据。它不会利用行访问权限政策谓词来进一步删减。

  • 使用行级访问权限政策过滤条件时,并非所有用户过滤条件都会尽早应用。这可能会增加从表中读取的数据,并且可能读取更多行的数据并进行计费。

如需详细了解 BigQuery 查询价格,请参阅 BigQuery 价格

限制

如需了解行级安全性限制,请参阅 BigQuery 行级安全性限制。以下部分介绍了其他行级安全性限制。

性能限制

  • 处理包含行级访问权限政策的表时,某些 BigQuery 功能不会加速,例如 BigQuery BI Engine物化视图

  • 行级安全性不参与查询裁剪 (pruning),这是分区表的一项功能。如需了解详情,请参阅分区表和聚类表。此限制不会减慢主查询的执行速度。

  • 查询行级安全性的表时,性能可能会略微下降。

如需详细了解行级安全性如何与某些 BigQuery 功能和服务交互,请参阅将行级安全性与其他 BigQuery 功能搭配使用

其他限制

  • 使用通过特定 BigQuery 版本创建的预留时,此功能可能不可用。如需详细了解每个版本中启用的功能,请参阅 BigQuery 版本简介

  • 行访问权限政策与旧版 SQL 不兼容。对具有行级访问权限政策的表进行的查询必须使用 GoogleSQL。旧版 SQL 查询会遭到拒绝并显示错误。

  • 您不能对 JSON 列应用行级访问权限政策。

  • BigQuery 的某些功能与行级安全性不兼容。如需了解详情,请参阅使用行级安全性

  • 需要对表数据具有完整访问权限的非查询操作(包括服务账号作业)可以使用具有 TRUE 过滤条件的行级安全性。例如表复制Dataproc 工作流等。如需了解详情,请参阅使用行级安全性

  • 必须使用 DDL 语句创建、替换或删除行级访问权限政策。您可以通过 Google Cloud 控制台或 bq 命令行工具列出和查看行级访问权限政策。

  • 预览或浏览表与行级安全性不兼容。

  • 表采样与行级安全性不兼容。

  • 顶级子查询政策结果的大小上限为 100 MB。此限制适用于单个行级访问权限政策。

  • 如果由于删除任何引用的表而无法评估行级访问权限政策谓词,则查询会失败。

  • 子查询行级访问权限政策仅支持 BigQuery 表、BigLake 外部表和 BigLake 托管表。

审核日志记录和监控

读取具有一个或多个行级访问权限政策的表中的数据时,已获得读取访问权限授权的行级访问权限政策以及子查询中引用的任何相应表都将显示在该读取请求的 IAM 授权信息中。

系统会将创建和删除行级访问权限政策事件记入审核日志,该审核日志可通过 Cloud Logging 访问。审核日志包括行级访问权限政策的名称。但是,行级访问权限政策的 filter_expressiongrantee_list 定义会从日志中省略,因为它们可能包含用户或其他敏感信息。系统不会将列出和查看行级访问权限政策事件记入审核日志。

如需详细了解 BigQuery 中的日志记录,请参阅 BigQuery 监控简介

如需详细了解 Google Cloud 中的日志记录,请参阅 Cloud Logging

后续步骤