了解行访问策略¶

行访问策略如何工作？¶

行访问策略包含一个表达式，该表达式可以指定 Snowflake 数据库对象（例如表或视图），并且使用 条件表达式函数 和 上下文函数 确定哪些行应该在给定上下文中显示。

Snowflake 使用 策略所有者 的角色（不是执行查询的操作员的角色）来评估策略表达式。此方法允许 Snowflake 不在查询结果中返回行，因为查询操作员无需访问行访问策略中的映射表。

查询运行时的行访问策略¶

在查询运行时，Snowflake 会经历以下过程：

1. Snowflake 确定是否为数据库对象设置行访问策略。如果为数据库对象添加策略，则所有行都受该策略保护。

2. Snowflake 会创建数据库对象的动态安全视图（即安全内联视图）。

3. ALTER TABLE 或 ALTER VIEW 命令中（即，将行访问策略添加到表或视图时）指定的列的值会绑定到策略中的相应参数，并且策略表达式会接受评估。

4. Snowflake 为用户生成查询输出，并且查询输出仅包含基于评估为 TRUE 的策略定义的行。

有关具体执行计划的更多详细信息，请参阅 查询配置文件 （本主题内容）。

Snowflake 支持嵌套的行访问策略，例如表上的行访问策略和相同表的视图上的行访问策略。在查询运行时，Snowflake 按以下顺序评估与给定查询相关的所有行访问策略：

• 适用于表的行访问策略始终首先执行。

• 在评估表的策略之后执行视图的策略。

• 如果存在嵌套视图（例如表 1 -> 视图 1 -> 视图 2 -> ... 视图 n），则策略的应用顺序为从左到右。

无论存在多少与查询中数据相关的行访问策略，这种模式都会持续下去。下图说明了查询操作员、表、视图和策略之间的关系。

有关行访问策略权限、命令和分步实施的更多信息，请参阅：

• 行访问策略权限

• 行访问策略 DDL

• 使用行访问策略

代表性用例：简单行筛选¶

行访问策略的简单应用是在策略中指定一个属性，以及允许在查询结果中查看该属性的角色。此类简单策略的优点是，相较于使用包含映射表的行访问策略，Snowflake 在评估这些策略以返回查询结果时，性能成本可以忽略不计。

作为代表性示例，信息技术管理员（例如 it_admin 自定义角色）必须先查询员工身份号（即 empl_id），然后再授予员工额外权限以使用内部系统。因此，如果 CURRENT_ROLE 与 it_admin 自定义角色匹配，则行访问策略应该在查询结果中返回行，不为所有其他角色返回行。例如：

CREATE OR REPLACE ROW ACCESS POLICY rap_it
AS (empl_id varchar) RETURNS BOOLEAN ->
  'it_admin' = current_role()
;

此策略是行访问策略的最简洁版本，因为无需评估其他条件，只需评估 CURRENT_ROLE 的值。

如果需要考虑角色层次结构，则此策略以类似方式使用 IS_ROLE_IN_SESSION 更好地包容其他角色，以查看查询结果中的员工 ID 编号。

或者，为考虑其他条件，使用 CASE 函数允许包含 WHEN/THEN/ELSE 子句，以支持更详细的条件逻辑。

代表性用例：使用映射表筛选查询结果¶

行访问策略条件可以引用映射表来筛选查询结果集，但是，相较于更 简单的 示例，使用映射表可能会导致性能下降。

例如，使用映射表来确定销售经理在指定销售区域中可以看到的收入值。映射表应指定销售经理和销售区域（例如 WW：全世界、 NA：北美、 EU：欧盟）。

销售经理	区域
Alice	WW
Bob	NA
Simon	EU

接下来，定义具有一个或多个条件的策略，以使用子查询来查询映射表。在查询运行时，Snowflake 确定执行查询的用户是否与映射表中指定的销售区域匹配。

如果出现匹配项，用户可以在查询结果中看到这些行。根据映射表，预期查询结果如下：

公司	区域	收入	查看者
Acme	EU	25 亿	Alice、Simon
Acme	NA	15 亿	Alice、Bob

有关使用映射表实施行访问策略的详细信息，请参阅：

• External Tables （本主题内容）

• 使用行访问策略

策略性能指南¶

行访问策略旨在在各种现实场景中实现良好性能。使用以下提示来保护数据并提高性能：

限制策略实参:

Snowflake 需要扫描策略绑定的列，即使查询中没有引用这些列。因此，相较于实参较多的策略，实参较少的策略通常性能更好。

简化 SQL 表达式:

相较于访问映射（即查找）表的策略，采用简单 SQL 表达式（例如 CASE 语句）的策略通常性能更好。尽可能减少表查找次数可以提高性能。

在指定映射表时，使用可记忆的函数替换映射表引用。有关详细信息，请参阅：

• 可记忆函数 （标量 SQL UDF 概述内容）。

• 在策略中使用可记忆函数 （在“使用行访问策略”主题内容）。

使用实际工作负载进行测试:

如果没有行访问策略，查询 SELECT COUNT(*) FROM t1 以毫秒执行，因为 Snowflake 已经知道表中的行数。但是，添加行访问策略意味着 Snowflake 必须扫描表，才能计算当前上下文中可访问的行数。尽管性能差异很大，但此查询不代表大多数实际工作负载。

有关此示例的更多信息，请参阅 注意事项 部分（本主题内容）。

按属性聚类:

对于非常大的表，按用于策略筛选的属性进行聚类可以提高性能。

有关更多信息，请参阅 群集密钥和聚类表。

搜索优化服务:

搜索优化服务可以提高使用掩码或行访问策略的表的查询性能。

有关详细信息，请参阅 在搜索优化服务中支持具有掩码策略和行访问策略的表。

优势¶

行访问策略的主要优势是该策略支持组织通过可扩展策略正确平衡数据安全、治理和分析。行访问策略的可扩展性允许随时添加或删除一个或多个条件，以确保该策略与数据、映射表和 RBAC 层次结构的更新保持一致。

其他优势包括：

使用方便:

编写一次策略并将其应用于跨数据库和架构的表。

变更管理:

轻松更改行访问策略定义，无需将策略重新应用到表。

如果使用映射表，则更新策略引用的映射表中的授权信息，无需更改策略。

数据管理和 SoD:

中央数据管理员决定要保护的对象，而不是对象所有者。通过集中式、分散式和混合管理模式，行访问策略易于管理和支持，以支持职责分离（即 SoD）。

数据授权和治理:

行访问策略支持按角色或自定义授权进行上下文数据访问。

限制¶

• 不支持对受行访问策略保护的视图使用 CHANGES 子句。

• Snowflake 不支持将外部表用作行访问策略中的映射表。有关更多信息，请参阅 External Tables （本主题内容）。

• Snowflake 不支持将行访问策略附加到流对象本身，但当流访问受行访问策略保护的表时，会将行访问策略应用于表。有关更多信息，请参阅 流 （本主题内容）。

• 不支持 未来授予 行访问策略的权限。

  为解决此问题，请将 APPLY ROW ACCESS POLICY 权限授予自定义角色，以允许该角色在表或视图上应用行访问策略。

注意事项¶

• 将行访问策略附加到受其他行访问策略或掩码策略保护的表可能会导致错误。有关更多信息，请参阅 ALTER TABLE、ALTER EXTERNAL TABLE 和 ALTER VIEW。

• 在策略正文中包含一个或多个 子查询 可能会导致错误。如果可能，限制子查询的数量，限制 JOIN 操作的数量，并简化 WHERE 子句条件。

• Snowflake 会维护有关表和视图列的统计信息，可以在几毫秒内回答许多简单的查询。此类查询的示例包括使用 COUNT 函数、select count(*) from my_table 和 MAX 函数、select max(c) from my_table。

  通常，这些统计信息和优化不适用于行访问策略，因为 Snowflake 必须识别查询可以访问的行子集。对具有行访问策略的表和视图执行此类查询，这可能需要比预期更长的时间才能获得查询结果，因为这些统计信息和优化未使用，并且返回的统计信息仅基于允许访问的内容，而不是“True”统计值（即没有行访问策略的表或视图的统计信息）。

• 当版本化架构中存在行访问策略时，为 Snowflake Native App 创建设置脚本时要小心。有关详细信息，请参阅 版本架构注意事项。

• 如果在掩码或行访问策略的正文中指定 CURRENT_DATABASE 或 CURRENT_SCHEMA 函数，该函数会返回包含受保护表的数据库或架构，而不是用于会话的数据库或架构。

获取具有行访问策略的数据库对象¶

Information Schema POLICY_REFERENCES 表函数可以返回关于为给定对象分配的行访问策略的信息。

• 给定策略的所有对象：

  指定行访问策略的名称（例如 mydb.policies.rap1）：

  SELECT *
  FROM TABLE(
    mydb.INFORMATION_SCHEMA.POLICY_REFERENCES(
      POLICY_NAME=>'mydb.policies.rap1'
    )
  );
  

  Copy

• 分配给特定对象的策略：

  指定对象的名称（例如 mydb.tables.t1）和对象域（例如 table）：

  SELECT *
  FROM TABLE(
    mydb.INFORMATION_SCHEMA.POLICY_REFERENCES(
      REF_ENTITY_NAME => 'mydb.tables.t1',
      REF_ENTITY_DOMAIN => 'table'
    )
  );
  

  Copy

请注意，此表函数与 Account Usage POLICY_REFERENCES 视图相辅相成。

活动角色层次结构和映射表¶

策略条件可以直接评估用户在会话中活跃的主要角色和次要角色，在映射表中查找活跃角色，或者根据策略管理员编写策略的方式来执行这两种操作。如果策略包含映射表查找，请创建一个集中式映射表，并将映射表存储在受保护的表所在的数据库中。如果策略调用 IS_DATABASE_ROLE_IN_SESSION 函数，则这一点尤为重要。有关详细信息，请参阅函数 使用说明。

对于这些用例，Snowflake 建议根据要指定账户角色还是数据库角色，来编写调用 IS_ROLE_IN_SESSION 或 IS_DATABASE_ROLE_IN_SESSION 函数的策略条件。有关示例，请参阅：

• IS_ROLE_IN_SESSION 函数中的 示例 部分。

• IS_DATABASE_ROLE_IN_SESSION

• 共享受策略保护的数据

将行访问策略应用于表或视图¶

要将行访问策略添加到表或视图，有以下两种选项：

1. 对于 新 表或视图，请使用 CREATE TABLE 语句将策略应用于表，或者使用 CREATE VIEW 语句将策略应用于视图。

2. 对于 现有 表或视图，请使用 ALTER TABLE 语句将策略应用于表，或者使用 ALTER VIEW 语句将策略应用于视图。

对于 新的 表或视图，请执行以下语句：

-- table
CREATE TABLE sales (
  customer   varchar,
  product    varchar,
  spend      decimal(20, 2),
  sale_date  date,
  region     varchar
)
WITH ROW ACCESS POLICY sales_policy ON (region);

-- view
CREATE VIEW sales_v WITH ROW ACCESS POLICY sales_policy ON (region)
AS SELECT * FROM sales;

Copy

对于 现有的 表或视图，执行以下语句：

-- table

ALTER TABLE t1 ADD ROW ACCESS POLICY rap_t1 ON (empl_id);

-- view

ALTER VIEW v1 ADD ROW ACCESS POLICY rap_v1 ON (empl_id);

Copy

掩码策略¶

当数据库对象同时具有行访问策略和一个或多个 掩码策略 时，Snowflake 首先评估行访问策略。

给定的表或视图列可以在行访问策略签名或掩码策略签名中指定。换句话说，同一列不能同时在行访问策略签名或掩码策略签名中指定。

有关更多信息，请参阅 CREATE MASKING POLICY 和 CREATE ROW ACCESS POLICY。

模拟策略如何运作¶

调用 POLICY_CONTEXT 函数，模拟对受掩码策略保护的列、受行访问策略保护的表或视图的查询，或者对这两种策略的查询。

外部表¶

您可以执行 CREATE EXTERNAL TABLE 语句，创建具有行访问策略的外部表，并将策略应用于 VALUE 列。

您可以对外部表执行 ALTER TABLE 语句，将行访问策略应用于现有外部表的 VALUE 列。

行访问策略不能直接添加到虚拟列。相反，在外部表上创建一个视图，并将行访问策略应用于该视图上的列。

流¶

如果表中添加了行访问策略，则当流访问表数据时，Snowflake 会将行访问策略应用于表数据。

有关更多信息，请参阅 限制。

视图¶

Snowflake 支持在基表和视图上设置行访问策略。基表或视图策略可以应用于视图所有者（即 INVOKER_ROLE）或查询操作员角色（即 CURRENT_ROLE）。

有关更多信息，请参阅 限制。

物化视图¶

Snowflake 支持将行访问策略添加到物化视图，前提是行访问策略 未 在基础表或视图上设置。

行访问策略和物化视图确实具有以下限制：

• 如果将行访问策略添加到基础表，则无法通过表创建物化视图。

• 如果已通过基础表创建物化视图，则无法将行访问策略添加到表。

动态表¶

您可以使用行访问策略、掩码策略和标签来创建动态表。有关更多信息，请参阅：

• CREATE DYNAMIC TABLE

• 增量刷新的其他限制

CREATE TABLE 语句¶

下面总结了行访问策略如何影响 CREATE TABLE 语句：

CREATE TABLE ... CLONE:

在访问克隆的对象时，以下方法有助于保护数据免受具有表或视图 SELECT 权限的用户的侵害：

• 不支持克隆单个策略对象。

• 克隆架构会导致克隆该架构中的所有策略。

• 克隆的表会映射到与源表相同的策略。换句话说，如果在基表或其列上设置了策略，则该策略将附加到克隆的表或其列中。

  • 当表在其父架构克隆的上下文中进行克隆时，如果源表引用了同一父架构中的策略（即本地引用），则克隆的表将引用克隆的策略。

  • 如果源表引用了不同架构中的策略（即外部引用），则克隆表会保留外部引用。

有关更多信息，请参阅 CREATE <object> ... CLONE。

CREATE TABLE ... LIKE:

如果行访问策略在基表上设置，则该行访问策略 不 在新表中的列上设置。新表是空的。

CREATE TABLE ...AS SELECT:

如果行访问策略在基表上设置，则新表包含根据行访问策略定义筛选的行。新表没有在列上设置的行访问策略。

查询配置文件¶

在查询运行时，Snowflake 会创建 动态安全视图。

对用于设置行访问策略的数据库对象使用 EXPLAIN 命令时，查询结果表明存在行访问策略。当在数据库对象上设置行访问策略时， EXPLAIN 查询结果指定以下列值：

• operation 列包含值 DynamicSecureView。

• object 列包含值 "<object_name> (+ RowAccessPolicy)"。

查询计划中需要调用行访问策略的每个步骤都会导致 operation 和 object 列指定查询计划中该步骤的相应值。如果行访问策略在查询中仅调用一次，则 EXPLAIN 查询结果中只有一行包括 DynamicSecureView 和 "<object_name> (+ RowAccessPolicy)" 值。

在 EXPLAIN 命令结果和 查询配置文件 Web 界面中，Snowflake 不会向用户显示任何行访问策略 信息 （即策略名称、策略签名、策略表达式）或者策略访问的对象。

以下示例指明行访问策略仅调用一次。

EXPLAIN SELECT * FROM my_table;

Copy

+-------+--------+--------+-------------------+--------------------------------+--------+-------------+-----------------+--------------------+---------------+
|  step |   id   | parent |     operation     |           objects              | alias  | expressions | partitionsTotal | partitionsAssigned | bytesAssigned |
+-------+--------+--------+-------------------+--------------------------------+--------+-------------+-----------------+--------------------+---------------+
...

| 1     | 2      | 1      | DynamicSecureView | "MY_TABLE (+ RowAccessPolicy)" | [NULL] | [NULL]      | [NULL]          | [NULL]             | [NULL]        |
+-------+--------+--------+-------------------+--------------------------------+--------+-------------+-----------------+--------------------+---------------+

以下示例指明行访问策略在同一表上调用两次：

EXPLAIN SELECT product FROM sales
  WHERE revenue > (SELECT AVG(revenue) FROM sales)
  ORDER BY product;

Copy

+--------+--------+--------+-------------------+-----------------------------+--------+-------------+-----------------+--------------------+---------------+
|  step  |   id   | parent |     operation     |           objects           | alias  | expressions | partitionsTotal | partitionsAssigned | bytesAssigned |
+--------+--------+--------+-------------------+-----------------------------+--------+-------------+-----------------+--------------------+---------------+
...
| 1      | 0      | [NULL] | DynamicSecureView | "SALES (+ RowAccessPolicy)" | [NULL] | [NULL]      | [NULL]          | [NULL]             | [NULL]        |
...
| 2      | 2      | 1      | DynamicSecureView | "SALES (+ RowAccessPolicy)" | [NULL] | [NULL]      | [NULL]          | [NULL]             | [NULL]        |
+--------+--------+--------+-------------------+-----------------------------+--------+-------------+-----------------+--------------------+---------------+

Time Travel¶

Snowflake 支持在具有行访问策略的表和视图上进行 Time Travel。

在查询运行时，Snowflake 会在查询时评估行访问策略的映射表；换句话说，Time Travel 不会影响映射表。

有关更多信息，请参阅 了解和使用 Time Travel。

复制¶

可以使用数据库复制和复制组来复制行访问策略及其分配。

对于 数据库复制，如果满足以下任一条件，则复制操作会失败：

• 主数据库位于企业账户（或更高版本）中，包含策略，但批准复制的一个或多个账户的版本较低。

• 主数据库中包含的表或视图可以 悬空引用 到其他数据库中的行访问策略。

在 复制组 中复制多个数据库时，可避免数据库复制的悬空引用行为。

备注

如果使用故障转移或故障回复操作，Snowflake 账户必须是 Business Critical Edition 或更高版本。

有关更多信息，请参阅 跨多个账户的复制和故障转移简介。

数据共享¶

用途:

• 如果提供程序将策略分配给共享表或视图，并且策略条件调用 CURRENT_ROLE 或者 CURRENT_USER 函数，或者策略条件调用 安全的 UDF，Snowflake 将为该函数或使用者账户中的 UDF 返回 NULL 值。

  原因是共享数据的所有者通常不控制共享表或视图的账户中的用户或角色。为解决此问题，请在策略条件下使用 CURRENT_ACCOUNT 函数。

  或者，作为提供商，编写策略条件以调用 IS_DATABASE_ROLE_IN_SESSION 函数并共享数据库角色。作为使用者，请将共享数据库角色授予账户角色。有关详细信息，请参阅 共享受策略保护的数据。

限制:

• 数据共享提供商无法在 阅读者账户 中创建策略。

• 数据共享使用者无法将策略应用于共享表或视图。为解决此问题，请导入共享数据库并从共享表或视图创建本地视图。

• 数据共享使用者无法查询引用两个不同提供商的共享表或视图。例如：

  • rap1 是一个行访问策略，用于保护名为 t1 的表，其中 t1 位于提供商提供的名为 share1 的共享中。

  • rap1 策略条件引用名为 t2 的映射表，其中 t2 来自 share2 和其他提供商。

  • 对 t1 的使用者查询失败。

  • t1 的提供商可以查询 t1。

• 外部函数：

  如果出现以下情况，Snowflake 将返回错误：

  • 分配给共享表或视图的策略将更新以调用外部函数。

  • 该策略调用外部函数，并且您尝试将该策略分配给共享表或视图。

Snowflake Native App Framework¶

有关将行访问策略与 Snowflake Native App 一起使用的详细信息，请参阅：

• 对包含策略的共享数据内容的限制。

• 在代理视图上定义策略。

• 被阻止的上下文函数。

选择集中式、混合式或分散式管理方法¶

为有效管理行访问策略，比较有用的方式是，考虑用于筛选行的方法是否应该遵循集中式、分散式或混合治理方法。

下表总结了在采用这三种方法时的一些注意事项。

有关语法示例，请参阅 DDL 命令、操作和权限总结。

行访问策略权限¶

Snowflake 支持以下行访问策略权限，以确定用户是否可以创建、设置和拥有行访问策略。

请注意，对架构中的对象进行操作还需要对父数据库和架构具有 USAGE 权限。

行访问策略 DDL¶

Snowflake 支持以下 DDL 命令和操作来管理行访问策略：

• CREATE ROW ACCESS POLICY

• ALTER ROW ACCESS POLICY

• DROP ROW ACCESS POLICY

• SHOW ROW ACCESS POLICIES

• DESCRIBE ROW ACCESS POLICY

• ALTER TABLE、ALTER EXTERNAL TABLE 和 ALTER VIEW （在表或视图上添加/删除策略）

DDL 命令、操作和权限总结¶

下表总结了行访问策略 DDL 操作及其所需权限之间的关系。

请注意，对架构中的对象进行操作还需要对父数据库和架构具有 USAGE 权限。

Snowflake 支持不同的权限，以创建和设置对象的行访问策略。

1. 对于集中式行访问策略管理方法，即 rap_admin 自定义角色在 所有 对象上创建和设置行访问策略时采用的方法，需要以下权限：

   use role securityadmin;
   grant create row access policy on schema <db_name.schema_name> to role rap_admin;
   grant apply row access policy on account to role rap_admin;
   

   Copy

2. 在混合式管理方法中，单一角色具有 CREATE ROW ACCESS POLICY 权限，确保一致的策略创建以优化查询性能，并且各个团队或角色拥有特定行访问策略的 APPLY 权限以保护其表和视图。

   例如，可以向自定义角色 finance_role 授予权限，以在角色所有的表和视图上添加行访问策略 rap_finance：

   use role securityadmin;
   grant create row access policy on schema <db_name.schema_name> to role rap_admin;
   grant apply on row access policy rap_finance to role finance_role;
   

   Copy

了解行访问策略¶

您可以使用 ROW_ACCESS_POLICIES 在共享的 Account Usage 架构中查看 SNOWFLAKE 数据库。此视图是 Snowflake 账户中所有行访问策略的 目录。例如：

SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.ROW_ACCESS_POLICIES
ORDER BY POLICY_NAME;

Copy

确定分配¶

Snowflake 支持不同的选项来识别行访问策略分配，具体取决于查询是否需要针对账户或特定数据库。

• 账户级查询：

  使用 Account Usage POLICY_REFERENCES 视图，确定具有行访问策略的所有表。例如：

  SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.POLICY_REFERENCES
  ORDER BY POLICY_NAME, REF_COLUMN_NAME;
  

  Copy

• 数据库级查询：

  每个 Snowflake 数据库都包含一个 Snowflake Information Schema。使用 Information Schema 表函数 POLICY_REFERENCES，确定与特定行访问策略关联的所有对象：

  SELECT *
  FROM TABLE(
    my_db.INFORMATION_SCHEMA.POLICY_REFERENCES(
      POLICY_NAME => 'rap_t1'
    )
  );
  

  Copy

访问 Snowsight 中的治理区域¶

要访问 Governance 区域，Snowflake 账户必须是 Enterprise Edition 或更高版本。此外，您必须执行以下任一操作：

• 使用 ACCOUNTADMIN 角色。

• 使用已 直接 授予 GOVERNANCE_VIEWER 和 OBJECT_VIEWER 数据库角色的账户角色。

  您 必须 使用获授这些数据库角色的账户角色。目前，Snowsight 不评估角色层次结构和有权访问表、视图、数据访问策略和标签的用户定义数据库角色。

  要确定是否向账户角色授予了这两个数据库角色，请使用 SHOW GRANTS 命令：

  SHOW GRANTS LIKE '%VIEWER%' TO ROLE data_engineer;
  

  Copy

  |-------------------------------+-----------+---------------+-----------------------------+------------+-----------------+--------------+------------|
  | created_on                    | privilege | granted_on    | name                        | granted_to | grantee_name    | grant_option | granted_by |
  |-------------------------------+-----------+---------------+-----------------------------+------------+-----------------+--------------+------------|
  | 2024-01-24 17:12:26.984 +0000 | USAGE     | DATABASE_ROLE | SNOWFLAKE.GOVERNANCE_VIEWER | ROLE       | DATA_ENGINEER   | false        |            |
  | 2024-01-24 17:12:47.967 +0000 | USAGE     | DATABASE_ROLE | SNOWFLAKE.OBJECT_VIEWER     | ROLE       | DATA_ENGINEER   | false        |            |
  |-------------------------------+-----------+---------------+-----------------------------+------------+-----------------+--------------+------------|
  

  
  

  如果您的账户角色未被授予这两个数据库角色或其中之一，请使用 GRANT DATABASE ROLE 命令并再次运行 SHOW GRANTS 命令以确认授予角色：

  USE ROLE ACCOUNTADMIN;
  GRANT DATABASE ROLE SNOWFLAKE.GOVERNANCE_VIEWER TO ROLE data_engineer;
  GRANT DATABASE ROLE SNOWFLAKE.OBJECT_VIEWER TO ROLE data_engineer;
  SHOW GRANTS LIKE '%VIEWER%' TO ROLE data_engineer;
  

  Copy

  有关这些数据库角色的详细信息，请参阅 SNOWFLAKE 数据库角色。

仪表板¶

作为数据管理员，您可以使用 Dashboard 界面通过以下方式监控标签和策略使用情况。

• 覆盖率：根据表、视图或列是否具有策略或标签来指定计数和百分比。

• 流行度：列出并统计最常用的策略和标签。

覆盖范围和流行程度提供了有关数据保护和标记程度的快照。

当您选择计数、百分比、策略名称或标签名称时， Tagged Objects 界面打开。Tagged Objects 界面会根据您在 Dashboard 中的选择自动更新筛选器。

监控信息是在多个 Account Usage 视图上运行复杂且查询密集型操作的替代方案或补充。

这些视图可能包括但不限于 COLUMNS、POLICY_REFERENCES、TABLES、TAG_REFERENCES，以及 VIEWS 视图。

标记对象¶

作为数据管理员，您可以使用此表将 Dashboard 中的覆盖范围和流行程度快速关联到特定表、视图或列的列表。您还可以手动筛选表结果，如下所示。

• 选择 Tables 或者 Columns。

• 对于标签，可以使用标签、不使用标签或按特定标签进行筛选。

• 对于策略，可以使用策略、不使用策略或按特定策略进行筛选。

在表中选择一行时，系统将打开 Data » Databases 中的 Table Details 或 Columns 选项卡。您可以根据需要编辑标签和策略分配。