数据遮盖简介

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

BigQuery 支持列级数据遮盖。您可以使用数据遮盖功能来有选择地针对某些用户组遮盖列数据，同时仍允许他们访问列。数据遮盖功能基于列级访问权限控制构建而成，因此您应该先熟悉列级访问权限控制功能，然后再进行后续的操作。

将数据遮盖功能与列级访问权限控制结合使用时，您可以根据不同用户组的具体需要，对列数据配置一系列访问权限（从完整访问权限到无访问权限）。例如，对于税号数据，您可能希望向您的会计群组授予完整访问权限、向您的分析师群组授予遮盖访问权限，而向您的销售群组则不授予任何访问权限。

优势

数据遮盖功能可提供以下优势：

• 它简化了数据共享过程。您可以遮盖包含敏感数据的列，以便能够与更多群组共享表。
• 与列级访问权限控制不同，您无需修改现有查询以排除用户无法访问的列。配置数据遮盖功能后，现有查询会根据已授予用户的角色自动遮盖相应的列数据。
• 您可以大规模应用数据访问政策。您可以编写数据政策，然后将其与政策标记相关联，之后便可以将该政策标记应用于任意数量的列数据。
• 它支持基于特性的访问权限控制。附加到列数据的政策标记会提供上下文数据访问，具体取决于与该政策标记关联的数据政策及主账号。

数据遮盖工作流

图 1 展示了配置数据遮盖的工作流：

图 1. 数据遮盖组件。

您可以按照以下步骤配置数据遮盖：

1. 设置分类以及一个或多个政策标记。

2. 为政策标记配置数据政策。数据政策会将数据遮盖规则以及一个或多个主账号（表示用户或群组）映射到政策标记。

   使用 Google Cloud 控制台创建数据政策时，您只需一步便可创建数据遮盖规则并指定主账号。使用 BigQuery Data Policy API 创建数据政策时，您需要在一个步骤中创建数据政策和数据遮盖规则，然后在另一个步骤中指定数据政策的主账号。

3. 将政策标记分配给 BigQuery 表中的列以应用数据政策。

4. 将有权访问遮盖数据的用户分配给 BigQuery Masked Reader 角色。 最佳实践是在数据政策级层分配 BigQuery Masked Reader 角色。如果在项目级层或更高级层分配该角色，则用户将获得项目下所有数据政策的权限，这可能会导致权限多余而造成的问题。

   与数据政策关联的政策标记也可用于进行列级访问权限控制。在这种情况下，政策标记还需与一个或多个被授予 Data Catalog Fine-Grained Reader 角色的主账号相关联。这样，这些主账号就可以访问未经遮盖的原始列数据。

图 2 展示了列级访问权限控制与数据遮盖功能如何协同工作：

图 2. 数据遮盖组件。

如需详细了解角色交互，请参阅 Masked Reader 和 Fine-Grained Reader 角色如何交互。如需详细了解政策标记的继承机制，请参阅角色和政策标记层次结构。

数据遮盖规则

如果使用数据遮盖功能，系统会根据运行查询的用户的角色在查询运行时向相应列数据应用数据遮盖规则。遮盖优先于查询所涉及的任何其他操作。数据遮盖规则决定了应用于列数据的数据遮盖类型。

您可以使用以下数据遮盖规则：

• 自定义遮盖例程。 将用户定义的函数 (UDF) 应用于列后，返回该列的值。需要具有例程权限才能管理遮盖规则。根据设计，此规则支持除 STRUCT 数据类型以外的所有 BigQuery 数据类型。但是，对 STRING 和 BYTES 以外的数据类型的支持有一定限制。输出取决于定义的函数。

  如需详细了解如何为自定义遮盖例程创建 UDF，请参阅创建自定义遮盖例程。

• 日期/年份掩码。在将值截断到其年份，将值的所有非年份部分设置为该年的年初，然后返回列的值。您只能对使用 DATE、DATETIME 或 TIMESTAMP 数据类型的列使用此规则。例如：

  类型	原始	遮盖后
  DATE	2030-07-17	2030-01-01
  DATETIME	2030-07-17T01:45:06	2030-01-01T00:00:00
  TIMESTAMP	2030-07-17 01:45:06	2030-01-01 00:00:00

  注意：系统会根据世界协调时间 (UTC) 时区进行截断。如需更改此设置，请使用 @@time_zone 系统变量调整默认时区。

• 默认遮盖值。根据列的数据类型返回列的默认遮盖值。如果要隐藏列值但显示其数据类型，则可以使用此规则。如果将此数据遮盖规则应用于列，对于具有 Masked Reader 访问权限的用户所执行的查询 JOIN 操作而言，此规则用处不大。这是因为在联接表时，默认值不具备唯一性，因而所起到的作用不大。

  下表展示了每种数据类型的默认遮盖值：

  数据类型	默认遮盖值
  STRING	""
  BYTES	b''
  INTEGER	0
  FLOAT	0.0
  NUMERIC	0
  BOOLEAN	FALSE
  TIMESTAMP	1970-01-01 00:00:00 UTC
  DATE	1970-01-01
  TIME	00:00:00
  DATETIME	1970-01-01T00:00:00
  GEOGRAPHY	POINT(0 0)
  BIGNUMERIC	0
  ARRAY	[]
  STRUCT	NOT_APPLICABLE 政策标记无法应用于使用 STRUCT 数据类型的列，但可以与此类列的叶级字段相关联。
  JSON	null

• 电子邮件掩码。将有效电子邮件的用户名替换为 XXXXX 后，返回列值。如果列值不是有效的电子邮件地址，则返回通过 SHA-256 哈希函数运行后的列值。此规则只能用于使用 STRING 数据类型的列。例如：

  原始	遮盖后
  [e-mail]	[e-mail]
  randomtext	jQHDyQuj7vJcveEe59ygb3Zcvj0B5FJINBzgM6Bypgw=
  test@[e-mail]	Qdje6MO+GLwI0u+KyRyAICDjHbLF1ImxRqaW08tY52k=

• 前四个字符。返回列值的前 4 个字符，将字符串的其余部分替换为 XXXXX。如果列值的长度等于或小于 4 个字符，则返回通过 SHA-256 哈希函数运行后该列的值。此规则只能用于使用 STRING 数据类型的列。

• 哈希 (SHA-256)。返回通过 SHA-256 哈希函数运行后的列值。如果您希望最终用户能够在查询的 JOIN 操作中使用此列，则可以使用此规则。您只能对使用 STRING 或 BYTES 数据类型的列使用此规则。

  数据遮盖中使用的 SHA-256 函数会保留类型，因此函数返回的哈希值将与列值具有相同的数据类型。例如，STRING 列值的哈希值也具有 STRING 数据类型。

  重要提示：SHA-256 是一种确定性哈希函数；初始值始终会解析为相同的哈希值。但是，它不需要加密密钥。这使得恶意操作者有机会通过暴力破解来确定原始值，他们会通过 SHA-256 算法运行所有可能的原始值，并查看哪个值会生成与数据遮盖返回的哈希值相匹配的哈希值。

• 后四个字符。返回列值的最后 4 个字符，将字符串的其余部分替换为 XXXXX。如果列值的长度等于或小于 4 个字符，则返回通过 SHA-256 哈希函数运行后的列值。此规则只能用于使用 STRING 数据类型的列。

• 设为“Null”。返回 NULL，而不是列值。如果要同时隐藏列值及其数据类型，则可以使用此规则。如果将此数据遮盖规则应用于列，对于具有 Masked Reader 访问权限的用户所执行的查询 JOIN 操作而言，此规则用处不大。这是因为在联接表时，NULL 值不具备唯一性，因而所起到的作用不大。

数据遮盖规则层次结构

您可以为一个政策标记配置最多九个数据政策，每个数据政策可以关联不同的数据遮盖规则。其中一个政策预留用于列级访问权限控制设置。因此，您可以根据用户所属的群组，将多项数据政策应用于用户查询中的列数据。在这种情况下，BigQuery 会根据以下层次结构选择要应用的数据遮盖规则：

1. 自定义遮盖例程
2. 哈希 (SHA-256)
3. 电子邮件掩码
4. 后四个字符
5. 前四个字符
6. 日期/年份掩码
7. 默认遮盖值
8. 设为“Null”

例如，假设用户 A 同时是员工群组和会计群组的成员。用户 A 运行了一个包含 sales_total 字段的查询，并且该字段应用了 confidential 政策标记。confidential 政策标记有两个关联的数据政策：一个是将员工角色用作主账号并应用设为“Null”数据遮盖规则，另一个则是将会计角色用作主账号并应用哈希 (SHA-256) 数据遮盖规则。在这种情况下，哈希 (SHA-256) 数据遮盖规则会优先于设为“Null”数据遮盖规则，因此哈希 (SHA-256) 规则将应用于用户 A 的查询中的 sales_total 字段值。

图 3 展示了这一场景：

图 3.数据遮盖规则的优先级。

角色与权限

可以管理分类和政策标记的角色

您需要 Data Catalog Policy Tag Admin 角色才能创建和管理分类和政策标记。

角色/ID	权限	说明
Data Catalog Policy Tag Admin/datacatalog.categoryAdmin	datacatalog.categories.getIamPolicy datacatalog.categories.setIamPolicy datacatalog.taxonomies.create datacatalog.taxonomies.delete datacatalog.taxonomies.get datacatalog.taxonomies.getIamPolicy datacatalog.taxonomies.list datacatalog.taxonomies.setIamPolicy datacatalog.taxonomies.update resourcemanager.projects.get resourcemanager.projects.list	此角色在项目级应用。 此角色可授予执行以下操作的权限： 创建、读取、更新和删除分类及政策标记。 获取和设置有关政策标记的 IAM 政策。

可以创建和管理数据政策的角色

您需要以下 BigQuery 角色之一才能创建和管理数据政策：

角色/ID	权限	说明
BigQuery Data Policy Admin/bigquerydatapolicy.admin BigQuery Admin/bigquery.admin BigQuery Data Owner/bigquery.dataOwner	bigquery.dataPolicies.create bigquery.dataPolicies.delete bigquery.dataPolicies.get bigquery.dataPolicies.getIamPolicy bigquery.dataPolicies.list bigquery.dataPolicies.setIamPolicy bigquery.dataPolicies.update	bigquery.dataPolicies.create 和 bigquery.dataPolicies.list 权限在项目级应用。其他权限在数据政策级应用。 此角色可授予执行以下操作的权限： 创建、读取、更新和删除数据政策。 获取和设置有关数据政策的 IAM 政策。

您还需要拥有 datacatalog.taxonomies.get 权限，多个 Data Catalog 预定义角色都具有这种权限。

可以将政策标记附加到列的角色

您需要 datacatalog.taxonomies.get 和 bigquery.tables.setCategory 权限才能将政策标记附加到列。Data Catalog Policy Tags Admin 和 Viewer 角色均包含 datacatalog.taxonomies.get。BigQuery Admin (roles/bigquery.admin) 和 BigQuery Data Owner (roles/bigquery.dataOwner) 角色均包含 bigquery.tables.setCategory。

可以查询遮盖数据的角色

您需要 BigQuery Masked Reader 角色才能查询已应用数据遮盖的列数据。

角色/ID	权限	说明
Masked Reader/bigquerydatapolicy.maskedReader	bigquery.dataPolicies.maskedGet	在数据政策级别应用。 此角色可授予查看与数据政策相关联的遮盖列数据的权限。 此外，用户必须拥有适当的权限才能查询表。如需了解详情，请参阅所需权限。

Masked Reader 和 Fine-Grained Reader 角色如何交互

数据遮盖功能基于列级访问权限控制构建而成。对于给定列，您可以让一些用户拥有 BigQuery Masked Reader 角色，以便他们能够读取遮盖数据；让一些用户拥有 Data Catalog Fine-Grained Reader 角色，以便他们能够读取未经遮盖的数据；同时还可以让一些用户兼具这两种角色或者不具有这两种角色中的任何一种角色。这两种角色的交互方式如下：

• 兼具 Fine-Grained Reader 和 Masked Reader 这两种角色的用户：该用户看到的内容取决于每种角色是在政策标记层次结构中的哪一个级层授予的。如需了解详情，请参阅政策标记层次结构中的授权继承机制。
• 具有 Fine-Grained Reader 角色的用户：可以查看未经遮盖（清楚）的列数据。
• 具有 Masked Reader 角色的用户：可以查看经过遮盖（清楚）的列数据。
• 没有授予任何角色的用户：没有权限。

如果表中有列是受保护或经过遮盖的列，那么要在该表上运行 SELECT * FROM 语句，用户必须是能够为其授予所有这些列的 Masked Reader 或 Fine-Grained Reader 角色的群组中的成员。

如果用户未被授予这些角色，他们只能在 SELECT 语句中指定自己有权访问的列，或者使用 SELECT * EXCEPT (restricted_columns) FROM 排除那些受保护或经过遮盖的列。

政策标记层次结构中的授权继承机制

系统首先会在与具体列关联的政策标记级层评估角色，然后在分类中每次上升一个级层对角色进行检查，依序进行，直至确定用户具有相应的权限或到达政策标记层次结构的顶层为止。

例如，假设采用图 4 所示的政策标记和数据政策配置：

图 4. 政策标记和数据政策配置。

假设您有一个使用 Financial 政策标记标注的表列，以及一个同时属于 [e-mail] 和 [e-mail] 群组的用户。如果此用户运行的查询包含注解的列，则系统会通过在政策标记分类中定义的层次结构来确定其访问权限。由于该用户通过 Financial 政策标记获得了 Data Catalog Fine-Grained Reader 角色，因此查询会返回未经遮盖的列数据。

但如果是另一个只是作为 [e-mail] 角色成员的用户运行该包含所标注列的查询，查询会返回使用 SHA-256 算法进行哈希处理的列数据，因为该用户通过 Confidential 政策标记（这是 Financial 政策标记的父级）获得了 BigQuery Masked Reader 角色。

最后，如果用户不是上述任何角色的成员，那么当他们尝试查询所标注列时，就会收到访问遭拒错误。

下面，我们再采用图 5 所示的政策标记和数据政策配置，以与上述场景进行对比：

图 5. 政策标记和数据政策配置。

这里与图 4 中的情况大体相同，不同的是，用户在政策标记层次结构的较高级层被授予 Fine-Grained Reader 角色、在较低级层被授予 Masked Reader 角色。因此，对于此用户，查询会返回经过遮盖的列数据。即便该用户在政策标记层次结构的较高级层被授予 Fine-Grained Reader 角色，也是会发生这种情况，因为服务会使用其在政策标记层次结构中依序向上检查用户访问权限的过程中遇到的第一个已分配角色。

如果要创建单个数据政策并将其应用于政策标记层次结构的多个级层，则可以在代表其要应用到的层次结构级层最顶层的政策标记上设置该数据政策。例如，假设采用具有如下结构的分类：

• 政策标记 1
  • 政策标记 1a
    • 政策标记 1ai
  • 政策标记 1b
    • 政策标记 1bi
    • 政策标记 1bii

如果您希望将某个数据政策应用于所有这些政策标记，您可以在政策标记 1 上设置该数据政策。若您希望将某个数据政策应用于政策标记 1b 及其子项，则可以在政策标记 1b 上设置该数据政策。

数据遮盖及不兼容的功能

当您使用与数据遮盖不兼容的 BigQuery 功能时，该服务会将经过遮盖的列视为受保护列，并且只会为拥有 Data Catalog Fine-Grained Reader 角色的用户授予访问权限。

例如，假设采用图 6 所示的政策标记和数据政策配置：

Figure 6. 政策标记和数据政策配置。

假设您有一个使用 Financial 政策标记标注的表列，以及一个属于 [e-mail] 群组的用户。当此用户尝试通过某个不兼容的功能访问所标注列时，会收到访问遭拒错误。这是因为该用户通过 Financial 政策标记获得了 BigQuery Masked Reader 角色，但在这种情况下，必须拥有 Data Catalog Fine-Grained Reader 角色才有权访问列数据。由于该服务已确定用户的适用角色，因此不会在政策标记层次结构中继续向上检查是否有其他权限。

数据遮盖示例及其输出

如需了解标记、主账号和角色如何协同工作，请参阅此示例。

在 example.com 上，基本访问权限是通过 [e-mail] 群组授予的。所有需要定期访问 BigQuery 数据的员工都是该群组的成员，并分配有读取表数据所需的所有权限以及 BigQuery Masked Reader 角色。

对于因工作需要，需要对受保护列或遮盖列进行访问的员工，还需相应地将他们分配到额外的群组。这些额外群组的所有成员都属于 [e-mail]。如图 7 所示，您可以看到这些群组如何与相应的角色进行关联：

图 7.example.com 的政策标记和数据政策。

之后，这些政策标记会与表列进行关联，如图 8 所示：

图 8.与表列关联的 example.com 政策标记。

假定标记与列相关联，那么对于不同群组，运行 SELECT * FROM Accounts; 会产生以下结果：

• [e-mail]：此群组已被授予 PII 和 Confidential 这两个政策标记的 BigQuery Masked Reader 角色。系统会返回以下结果：

  SSN	优先级	生命周期价值	创建日期	电子邮件
  NULL	""	0	1983 年 3 月 8 日	NULL
  NULL	""	0	2009 年 12 月 29 日	NULL
  NULL	""	0	2021 年 7 月 14 日	NULL
  NULL	""	0	1997 年 5 月 5 日	NULL

• [e-mail]：此群组已被授予 SSN 政策标记的 Data Catalog Fine-Grained Reader 角色。系统会返回以下结果：

  SSN	优先级	生命周期价值	创建日期	NULL
  123-45-6789	""	0	1983 年 3 月 8 日	NULL
  234-56-7891	""	0	2009 年 12 月 29 日	NULL
  345-67-8912	""	0	2021 年 7 月 14 日	NULL
  456-78-9123	""	0	1997 年 5 月 5 日	NULL

• [e-mail]：此群组已被授予 Confidential 政策标记的 Data Catalog Fine-Grained Reader 角色。系统会返回以下结果：

  SSN	优先级	生命周期价值	创建日期	电子邮件
  NULL	高	90000	1983 年 3 月 8 日	NULL
  NULL	高	84,875	2009 年 12 月 29 日	NULL
  NULL	中	38,000	2021 年 7 月 14 日	NULL
  NULL	低	245	1997 年 5 月 5 日	NULL

• [e-mail]：此群组已被授予 Financial 政策标记的 BigQuery Masked Reader 角色。系统会返回以下结果：

  SSN	优先级	生命周期价值	创建日期	电子邮件
  NULL	""	Zmy9vydG5q=	1983 年 3 月 8 日	NULL
  NULL	""	GhwTwq6Ynm=	2009 年 12 月 29 日	NULL
  NULL	""	B6y7dsgaT9=	2021 年 7 月 14 日	NULL
  NULL	""	Uh02hnR1sg=	1997 年 5 月 5 日	NULL

• 所有其他用户：不属于任何所列群组的所有用户都会收到访问遭拒错误，因为他们未被授予 Data Catalog Fine-Grained Reader 或 BigQuery Masked Reader 角色。若要查询 Accounts 表，他们只能在 SELECT * EXCEPT (restricted_columns) FROM Accounts 中指定自己有权访问的列，以排除那些受保护或经过遮盖的列。

费用注意事项

数据遮盖可能会间接影响需处理的字节数，从而影响查询的结算费用。如果用户查询通过设为“Null”或默认遮盖值规则遮盖的某列数据，则系统根本就不会对该列进行扫描，从而减少了需处理的字节数。

限制和局限

以下各部分介绍了数据遮盖受制于的限制和局限的类别。

数据政策管理

• 使用通过特定 BigQuery 版本创建的预留时，此功能可能不可用。如需详细了解每个版本中启用的功能，请参阅 BigQuery 版本简介。
• 您最多可以为每个政策标记创建 9 个数据政策。其中一个政策预留用于列级访问权限控制设置。
• 数据政策、其关联的政策标记以及使用这些政策的任何例程都必须位于同一项目中。

政策标记

• 包含政策标记分类的项目必须属于某个组织。

• 政策标记层次结构从根节点到最低级别的子标记的深度不能超过 5 层，如以下屏幕截图所示：

  

设置访问权限控制

在分类具有与其至少一个政策标记关联的数据政策之后，系统就会自动实施访问权限控制。如果要关闭访问权限控制，您必须先删除与分类关联的所有数据政策。

具体化视图和重复的记录遮盖查询

如果您已有具体化视图，则针对关联基表的重复记录遮盖查询将会失败。如需解决此问题，请删除物化视图。如果您出于其他原因需要物化视图，可以在另一个数据集中创建。

查询分区表中经过遮盖的列

不支持包含分区或聚簇列的数据遮盖的查询。

SQL 方言

不支持旧版 SQL。

自定义遮盖例程

自定义遮盖例程受到以下限制：

• 自定义数据遮盖支持除 STRUCT 之外的所有 BigQuery 数据类型，因为数据遮盖仅适用于 STRUCT 数据类型的叶级字段。
• 删除自定义遮盖例程不会删除使用该例程的所有数据政策。但是，使用已删除的遮盖例程的数据政策只有空的遮盖规则了。对具有相同标记的其他数据政策具有 Masked Reader 角色的用户可以查看经过遮盖的数据。其他用户则会看到消息 Permission denied. 对空遮盖规则的断链引用可能在 7 天后被自动化流程清理。

与其他 BigQuery 功能的兼容性

BigQuery API

与 tabledata.list 方法不兼容。若要调用 tabledata.list，您需要对此方法返回的所有列具有完整访问权限。可通过 Data Catalog Fine-Grained Reader 角色授予所需的访问权限。

BigLake 表

兼容。可在 BigLake 表上实施数据遮盖政策。

BigQuery Storage Read API

兼容。可在 BigQuery Storage Read API 中实施数据遮盖政策。

BigQuery BI Engine

兼容。可在 BI Engine 中实施数据遮盖政策。BI Engine 不会对已实施数据遮盖的查询进行加速。在 Looker 数据洞察中使用此类查询可能会导致相关报告或信息中心速度变慢且费用更高。

BigQuery Omni

兼容。可在 BigQuery Omni 表上实施数据遮盖政策。

排序规则

不兼容。遮盖列不支持排序规则。

复制作业

不兼容。如需将表从来源复制到目标位置，您需要具有源表上所有列的完整访问权限。可通过 Data Catalog Fine-Grained Reader 角色授予所需的访问权限。

数据导出

兼容。如果您拥有 BigQuery Masked Reader 角色，则系统会对导出的数据应用遮盖。如果您拥有 Data Catalog Fine-Grained Reader 角色，则系统不会对导出的数据应用遮盖。

行级安全性

兼容。数据遮盖会在行级安全性之上进行应用。例如，如果针对 location = "US" 应用了行级访问权限政策并且遮盖了 location，则用户将能够查看满足 location = "US" 条件的行数据，但位置字段会被遮盖。

在 BigQuery 中搜索

部分兼容。对于已应用数据遮盖的列，不管它们是否已编入索引，您都可以对它们调用 SEARCH 函数。

对应用了数据遮盖的列调用 SEARCH 函数时，您必须使用与自己的访问权限级别匹配的搜索条件。例如，如果您具有 Masked Reader 访问权限且采用哈希 (SHA-256) 数据遮盖规则，则应在 SEARCH 子句中使用哈希值，如下所示：

SELECT * FROM myDataset.Customers WHERE SEARCH(Email, "sg172y34shw94fujaweu");

如果您具有 Fine-Grained Reader 访问权限，则应在 SEARCH 子句中使用实际的列值，如下所示：

SELECT * FROM myDataset.Customers WHERE SEARCH(Email, "[e-mail]");

对于采用设为“Null”或默认遮盖值数据遮盖规则的列，如果您具有 Masked Reader 访问权限，那么搜索的用处可能并不大。这是因为用作搜索条件的遮盖结果（如 NULL 或 ""）不具备唯一性，因而所起到的作用不大。

在搜索已应用数据遮盖且已编入索引的列时，仅当您对相应列具有 Fine-Grained Reader 访问权限时，系统才会使用搜索索引。

快照

不兼容。如需创建表快照，您需要具有源表上所有列的完整访问权限。可通过 Data Catalog Fine-Grained Reader 角色授予所需的访问权限。

表重命名

兼容。表重命名不受数据遮盖的影响。

时间旅行

与时间修饰器和 SELECT 语句中的 FOR SYSTEM_TIME AS OF 选项都可以兼容。当前数据集架构的政策标记会应用于检索到的数据。

查询缓存

部分兼容。BigQuery 会将查询结果缓存大约 24 小时，但是，如果在此之前对表数据或架构进行了更改，则缓存会失效。在以下情况下，未被授予列的 Data Catalog Fine-Grained Reader 角色的用户仍然可以在运行查询时查看相应的列数据：

1. 用户已被授予列的 Data Catalog Fine-Grained Reader 角色。
2. 用户运行的查询包含受限列但数据已被缓存。
3. 在第 2 步的 24 小时内，用户被授予 BigQuery Masked Reader 角色，并且撤消了 Data Catalog Fine-Grained Reader 角色。
4. 在第 2 步的 24 小时内，用户重新运行了该查询，并且返回了缓存的数据。

通配符表查询

不兼容。您需要对与通配符查询匹配的所有表上的所有引用列具有完整访问权限。可通过 Data Catalog Fine-Grained Reader 角色授予所需的访问权限。

后续步骤

• 获取有关如何启用数据遮盖的分步说明。