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 列表示）的行。

行级安全性可让 DataOwner 或 Admin 实现相关政策，例如“group:apac 中的用户只能查看 APAC 地区的合作伙伴”。

产生的行为是群组 [e-mail] 中的用户只能看到 Region = "APAC" 的行。同样，群组 [e-mail] 中的用户只能看到 US 区域中的行。不在 APAC 或 US 群组中的用户不会看到任何行。

名为 us_filter 的行级访问权限政策会授予对多个实体（包括首席美国销售人员 [e-mail]）的访问权限，所有这些实体现在都可以访问属于 US 区域的行。

根据敏感数据过滤行数据

现在，让我们来看另一个用例，其中有一个工资数据表。

grantee_list 限制只有公司网域的成员才能执行查询。此外，使用 SESSION_USER() 函数根据它们自己的用户电子邮件地址进一步将访问权限限制为属于运行查询的用户行。在本例中，它是 [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 命令行工具列出和查看行级访问权限政策。

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

审核日志记录和监控

读取具有一个或多个行级访问权限政策的表中的数据时，已获得读取访问权限授权的行级访问权限政策将显示在该读取请求的 IAM 授权信息中。

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

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

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

后续步骤

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

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

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