BigQuery 行级安全性简介

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

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

什么是行级安全性？

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

BigQuery 支持以下级别的访问权限控制：项目、数据集和表，以及列级安全性（通过使用政策标记）。行级安全性通过行级访问权限政策对 BigQuery 表中的部分数据启用精细访问权限控制，从而深化了最小权限原则。

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

行级安全性的工作原理

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

注意：如果您创建新的行级安全政策来限制行访问权限，则必须将先前具有完整访问权限的用户添加到 TRUE 过滤条件，才能保留其访问权限。

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

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

请注意：与 WHERE 子句类似，filter_expression 匹配您希望对 grantee_list 中的主账号可见的数据。grantee_list 中未包含的用户看不到任何行。

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

请查看 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', '[e-mail]', 'Japan', 'APAC'),
  ('Example Enterprise Group', '[e-mail]', 'Singapore', 'APAC'),
  ('Example HighTouch Co.', '[e-mail]', 'USA', 'US'),
  ('Example Buyers Inc.', '[e-mail]', 'USA', 'US');

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

CREATE ROW ACCESS POLICY
  apac_filter
ON
  dataset1.table1 GRANT TO ("group: [e-mail]")
FILTER USING
  (region="APAC" );

产生的行为是群组 [e-mail] 中的用户只能看到 region 的值为 APAC 的行。

以下语句会实现一项政策，该政策会限制个人和群组只能查看来自美国区域的合作伙伴：

CREATE ROW ACCESS POLICY
  us_filter
ON
  dataset1.table1 GRANT TO ("group:[e-mail]",
"user: [e-mail]")
FILTER USING
  (region="US");

产生的行为是群组 [e-mail] 中的用户和用户 [e-mail] 只能看到 region 的值为 US 的行。

下图显示了前面两个访问权限政策如何限制哪些用户和组可以查看表中的哪些行：

不在 APAC 或 US 群组中的用户不会看到任何行。

根据敏感数据过滤行数据

现在，让我们来看另一个用例，其中有一个包含工资信息的表。

您可以使用以下查询创建并填充示例表：

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, '[e-mail]'),
  ('Anna K', 'Finance', 100000, '[e-mail]'),
  ('Bruce L', 'Engineering', 100000, '[e-mail]'),
  ('Carrie F', 'Business', 100000, '[e-mail]');

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

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

下图展示了行访问权限政策如何限制包含薪资信息的表。在此示例中，用户名为 Jim，电子邮件地址为 [e-mail]。

注意 ：如需查看其他行级安全性示例，请参阅使用行级安全性。

根据对照表过滤行数据

预览

此功能须遵守服务专用条款的“通用服务条款”部分中的“非正式版产品条款”。 非正式版功能“按原样”提供，可能只能获得有限的支持。 如需了解详情，请参阅发布阶段说明。

如需针对此功能提供反馈或请求支持，请发送电子邮件至 [e-mail]。

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

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

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

与授权视图比较：漏洞

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

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

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

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

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

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

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

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

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

配额

如需详细了解行级安全性的配额和限制，请参阅 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_expression 和 grantee_list 定义会从日志中省略，因为它们可能包含用户或其他敏感信息。系统不会将列出和查看行级访问权限政策事件记入审核日志。

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

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

后续步骤

• 如需了解如何管理行级安全性，请参阅使用行级安全性。

• 如需了解行级安全性如何与其他 BigQuery 功能和服务搭配使用，请参阅将行级安全性与其他 BigQuery 功能搭配使用。

• 如需了解行级安全性的最佳做法，请参阅 BigQuery 中行级安全性最佳做法。