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 参考文档，了解创建行级访问权限政策时的完整语法、使用方法和选项。

应用场景示例

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

注意： 在外部身份提供方中管理用户访问权限时，请将 Google 账号主账号标识符（例如 user:[e-mail]、group:[e-mail] 和 domain:example.com）替换为适当的员工身份联合主账号标识符。

根据区域过滤行数据

假设表 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]。

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

根据对照表过滤行数据

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

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

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

与授权视图比较：漏洞

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

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

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

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

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

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

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

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

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

隐式删除行级访问权限政策

在多种情况下，系统可以从表中隐式（自动）移除行级访问权限政策。

自动删除行访问权限政策的一般原则是：

• 使用 WRITE_TRUNCATE 写入处置方式的操作始终会覆盖目标表上的所有现有行访问权限政策。
• 对于写入处置方式为 WRITE_APPEND 的操作，系统会保留目标表的当前行访问权限政策，并将源表的政策添加到目标表中。

具体而言，在以下情况下，行访问权限政策会被隐式移除：

• 替换表：使用 CREATE OR REPLACE TABLE DDL 语句替换表时，原始表上的所有现有行访问权限政策都会被舍弃。即使替换查询基于原始表的数据，也会发生这种情况。

• 使用 WRITE_TRUNCATE 进行加载或查询：使用 WRITE_TRUNCATE 写入处置方式的操作会移除所有现有的行级访问权限政策。这包括使用 bq load --replace 命令加载数据，以及运行状态为 writeDisposition 且设置为 WRITE_TRUNCATE 的查询。此类操作会完全覆盖表，并且不会沿用行访问权限政策。

• 表删除或过期：如果表被明确删除，或者达到过期时间并被自动移除，所有关联的行访问政策也会被删除。

• 表复制操作：将没有行级访问权限政策的表复制到具有行级访问权限政策的目标表时，系统会移除目标表中的政策，除非使用了 --append_table 标志或 "writeDisposition": "WRITE_APPEND"。如需详细了解表复制作业，请参阅将行级安全性与其他 BigQuery 功能搭配使用。

使用 TRUNCATE TABLE DDL 语句（用于从表中移除所有行，同时保留其架构）不会移除行访问权限政策。

配额

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

价格

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

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

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

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

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

限制

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

性能限制

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

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

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

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

其他限制

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

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

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

• 不支持对具有行访问权限政策的表进行通配符表查询。

• 无法对临时表应用行访问权限政策。

• 您无法对引用具有行级安全性的其他表的表应用行级访问权限政策。

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

  • 包含子查询的行级访问权限政策与 BigQuery Storage Read API 不兼容。BigQuery Storage Read API 仅支持简单过滤条件谓词。

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

• 您可以使用 DDL 语句或行访问权限政策 API 来创建、替换或删除行级访问权限政策。您还可以在 bq 命令行工具中执行行级访问权限政策 API 中的所有可用操作。您可以在Google Cloud 控制台中列出和查看行级访问权限政策。

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

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

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

• 在行访问权限政策中，不支持 search_value 的类型为 FLOAT、STRUCT、ARRAY、JSON 或 GEOGRAPHY 的顶级 IN 子查询。

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

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

• 不允许使用修改表架构并可能影响行访问权限政策的列重命名和舍弃语句。

审核日志记录和监控

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

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

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

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

后续步骤

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

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

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