了解列级安全性¶

什么是掩码策略？¶

Snowflake 支持将掩码策略作为架构级对象，以保护敏感数据免遭未经授权的访问，同时允许授权用户在查询运行时时访问敏感数据。这意味着 Snowflake 中的敏感数据不会在现有表中进行修改（即没有静态掩码）。相反，当用户执行应用掩码策略的查询时，掩码策略条件可确定未经授权的用户是否看到掩码后的数据、部分掩码后的数据、模糊的数据或标记化的数据。掩码策略作为架构级对象还可以灵活选择集中式、分散式或混合管理方法。有关更多信息，请参阅 管理列级安全性 （本主题内容）。

掩码策略可以包括条件和函数，以便在满足这些条件的情况下，在查询运行时时转换数据。策略驱动的方法支持职责分离，允许安全团队定义可以限制敏感数据暴露的策略，即使是对象的所有者（即具有对象 OWNERSHIP 权限的角色，如表或视图），他们通常对底层数据具有完全访问权限。

例如，掩码策略管理员可以实施掩码策略，以便分析人员（即具有自定义 ANALYST 角色的用户）只能查看电话号码的最后四位数字，而不能查看任何社会安全号码，而客户支持代表（即具有自定义 SUPPORT 角色的用户）可以查看用于客户验证的完整电话号码和社会安全号码。

掩码策略由单个 数据类型、一个或多个条件以及一个或多个掩蔽函数组成。

• 您可以将掩码策略应用于具有相符数据类型的一个或多个表/视图列。例如，您可以为电子邮件地址定义一次策略，然后将其应用于数据库和架构中的数千个电子邮件列。

• 掩码策略条件可以通过 条件表达式函数 函数和 上下文函数 函数表示，也可以通过查询自定义授权表表示。您可以将上下文函数 INVOKER_ROLE 和 INVOKER_SHARE 分别用于视图和共享。

• 掩码函数可以是任何内置函数（例如 REGEXP_REPLACE、 SHA2、SHA2_HEX）、 用户定义函数概述 或 编写外部函数 （用于通过 External Tokenization 提供程序进行去令牌化）。

虽然 Snowflake 提供了 安全视图 来限制敏感数据的访问权限，但由于每个视图都有大量视图和衍生的商业智能 (BI) 仪表板，因此安全视图带来了管理挑战。通过避免要管理的视图和仪表板爆炸式增长，掩码策略解决了这一管理难题。

通过策略管理员与对象所有者的角色分离，掩码策略支持职责分离 (SoD)。安全视图没有 SoD，这严重限制了其实用性。这种角色分离导致以下默认设置：

• 对象所有者（即具有对象的 OWNERSHIP 权限的角色）没有取消设置掩码策略的权限。

• 对象所有者无法查看应用掩码策略的列数据。

有关管理角色和权限的更多信息，请参阅 管理列级安全性 （本主题内容）和 访问控制权限。

-- Dynamic Data Masking

CREATE MASKING POLICY employee_ssn_mask AS (val string) RETURNS string ->
  CASE
    WHEN CURRENT_ROLE() IN ('PAYROLL') THEN val
    ELSE '******'
  END;

-- External Tokenization

  CREATE MASKING POLICY employee_ssn_detokenize AS (val string) RETURNS string ->
  CASE
    WHEN CURRENT_ROLE() IN ('PAYROLL') THEN ssn_unprotect(VAL)
    ELSE val -- sees tokenized data
  END;

优势¶

下表比较了动态数据掩码和 External Tokenization 的优点。

限制¶

下表描述了列级安全性的当前限制。复选标记（即 ✔）表示该功能存在限制或当前缺乏支持。

注意事项¶

• 将值从对源列具有掩码策略的源列插入到对目标列没有掩码策略的目标列时，请务必小心。由于在源列上设置了掩码策略，因此查看未掩码列数据的角色可以将未掩码数据插入到另一列中，其中任何对表或视图具有足够权限的角色都可以看到该值。

• 如果在源列中看到掩码后的数据的角色将这些值插入到目标列中，则插入的值将保持已掩码状态。如果未在目标列上设置掩码策略，则对表或视图具有足够权限的用户可能会在目标列中看到掩码后的值和未掩码的值的组合。因此，作为最佳实践：

  • 对列应用掩码策略时请务必小心。

  • 在将表和视图提供给用户之前，请使用具有掩码策略的列验证查询。

  • 确定可能出现源列中数据的其他表和视图（即目标列）。

  • 有关更多信息，请参阅 获取具有掩码策略的列 （本主题内容）。

• 当带有版本控制的架构中存在掩码策略时，为 Snowflake Native App 创建设置脚本时需谨慎。有关详细信息，请参阅 版本架构注意事项。

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

策略条件可以直接评估用户在会话中活跃的主要角色和次要角色，在映射表中查找活跃角色，或者根据策略管理员编写策略的方式来执行这两种操作。如果策略包含映射表查找，请创建一个集中式映射表，并将映射表存储在受保护的表所在的数据库中。如果策略调用 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 COLUMN 语句的表列或具有 ALTER VIEW 语句的视图列。

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

-- table
CREATE OR REPLACE TABLE user_info (ssn string masking policy ssn_mask);

-- view
CREATE OR REPLACE VIEW user_info_v (ssn masking policy ssn_mask_v) AS SELECT * FROM user_info;

Copy

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

-- table
ALTER TABLE IF EXISTS user_info MODIFY COLUMN ssn_number SET MASKING POLICY ssn_mask;

-- view
ALTER VIEW user_info_v MODIFY COLUMN ssn_number SET MASKING POLICY ssn_mask_v;

Copy

有关语法和用法的更多信息，请参阅 ALTER TABLE ...ALTER COLUMN 和 ALTER VIEW。

如果掩码策略使用 UDF，请参阅 掩码策略中的用户定义函数 （本主题内容）。

对列应用条件掩码策略¶

使用 条件列 创建 掩码策略后，当列尚未受掩码策略保护时，有两个选项可在列上设置条件掩码策略：

1. 对于 新的 表或视图，请将策略应用于具有相应 CREATE 语句的表或视图列。

   有关语法和用法的更多信息，请参阅：

   • CREATE TABLE

   • CREATE VIEW

   • CREATE MATERIALIZED VIEW

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

   -- table
   CREATE OR REPLACE TABLE user_info (email string masking policy email_visibility) USING (email, visibility);
   
   --view
   CREATE OR REPLACE VIEW user_info_v (email masking policy email_visibility) USING (email, visibility) AS SELECT * FROM user_info;
   

   Copy

2. 对于 现有的 表或视图，请在具有相应 ALTER 语句的表或视图列上设置策略。

   有关语法和用法的更多信息，请参阅：

   • ALTER TABLE

   • ALTER TABLE ...ALTER COLUMN

   • ALTER VIEW

   • ALTER MATERIALIZED VIEW

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

   -- table
   ALTER TABLE IF EXISTS user_info MODIFY COLUMN email
   SET MASKING POLICY email_visibility USING (EMAIL, VISIBILITY);
   
   -- VIEW
   ALTER VIEW user_info_v MODIFY COLUMN email
   SET MASKING POLICY email_visibility USING (email, visibility);
   

   Copy

替换列上的掩码策略¶

一旦在列上设置了掩码策略，就有两种不同的途径可以用不同的掩码策略替换该列上的掩码策略，而无需替换整个表或视图。

这些示例使用 ALTER TABLE 命令。同样的方法适用于带有 ALTER VIEW 命令的视图：

• 在一个语句中取消设置表列中的策略，然后在另一语句中对该列设置新策略：

  ALTER TABLE t1 MODIFY COLUMN c1 UNSET MASKING POLICY;
  
  ALTER TABLE t1 MODIFY COLUMN c1 SET MASKING POLICY p2;
  

  Copy

• 使用 FORCE 关键字来替换单个语句中的策略：

  ALTER TABLE t1 MODIFY COLUMN c1 SET MASKING POLICY p2 FORCE;
  

  Copy

  注意：

  • FORCE 关键字要求 ALTER TABLE 语句中策略的 数据类型 （即 STRING）与当前在该列上设置的掩码策略的数据种类（即 STRING）相匹配。

  • FORCE 关键字可以与 USING 子句结合使用，对列设置条件掩码策略：

    ALTER TABLE t1 MODIFY COLUMN c1 SET MASKING POLICY policy1 USING (c1, c3, c4) FORCE;
    

    Copy

行访问策略¶

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

此行为也适用于在掩码策略中用作条件列的列。

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

模拟策略如何运作¶

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

物化视图¶

Snowflake 允许您在物化视图列上设置掩码策略。在查询运行时，查询计划执行物化视图重写之前存在的任何掩码策略。一旦发生物化视图重写，就无法在任何物化视图列上设置掩码策略。

有两个选项可以在物化视图列上设置掩码策略：

1. 对于 新的 物化视图，请执行 CREATE MATERIALIZED VIEW 语句：

   CREATE OR REPLACE MATERIALIZED VIEW user_info_mv
     (ssn_number masking policy ssn_mask)
   AS SELECT ssn_number FROM user_info;
   

   Copy

2. 对于 现有的 物化视图，请在物化视图上执行 ALTER VIEW ...物化视图上的 MODIFY COLUMN 语句，如 对列应用掩码策略 部分所示（本主题内容）。

此外，关于掩码策略和物化视图还存在以下两个限制：

1. 如果已经从基础表创建了物化视图，则无法在表列上设置掩码策略。完成此尝试后，Snowflake 会返回以下错误消息：

   SQL execution error: One or more materialized views exist on the table. number of mvs=<number>, table name=<table_name>.
   

   Copy

2. 如果对基础表列设置掩码策略并从该表创建物化视图，则物化视图仅包含不受掩码策略保护的列。如果尝试包括受掩码策略保护的一个或多个列，Snowflake 还会返回以下错误消息：

   Unsupported feature 'CREATE ON MASKING POLICY COLUMN'.
   

   Copy

动态表¶

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

• CREATE DYNAMIC TABLE

• 增量刷新的其他限制

获取具有掩码策略的列¶

要获取具有掩码策略的列的列表，请执行以下语句。有关更多信息，请参阅 POLICY_REFERENCES。

SELECT * from table(
  INFORMATION_SCHEMA.POLICY_REFERENCES(
    policy_name=>'<policy_name>'
  )
);

Copy

执行 DESCRIBE TABLE 或 DESCRIBE VIEW 语句，以查看表或视图中列的掩码策略。

Object Tagging 和掩码策略¶

有关详细信息，请参阅 基于标签的掩码策略。

请注意，直接分配给列的掩码策略优先于基于标签的掩码策略。

掩码策略中的哈希、密码和加密函数¶

哈希 和 加密/校验 可用于掩码策略，以对敏感数据进行掩码处理。

有关更多信息，请参阅 高级列级安全主题。

外部表¶

使用 CREATE EXTERNAL TABLE 语句 创建 外部表时，不能将掩码策略分配给外部表 VALUE 列，因为默认情况下会自动创建此列。

通过对外部表执行 VALUE 语句，可以将掩码策略分配给外部表 ALTER TABLE ...ALTER COLUMN 列。用于保护 VALUE 列的掩码策略的数据类型必须是 VARIANT。

ALTER TABLE t1 MODIFY COLUMN VALUE SET MASKING POLICY p1;

Copy

您可以将掩码策略分配给外部表中的虚拟列，如下所示：

• 用于保护外部表中 VALUE 列的掩码策略中，将 EXEMPT_OTHER_POLICIES 掩码策略属性设置为 TRUE。

  如果尚未设置此属性，请对保护 VALUE 列的掩码策略执行 CREATE OR REPLACE 语句，并指定 EXEMPT_OTHER_POLICIES 属性。虚拟列继承保护 VALUE 列的策略，该属性允许虚拟列上的策略替换继承的策略。有关详细信息，请参阅 CREATE MASKING POLICY。

• 使用以下 ALTER TABLE 命令为虚拟列分配不同的掩码策略。此策略可能没有 VALUE 列的策略严格，因为虚拟列不太敏感。虚拟列包含的数据量比 VALUE 列少；VALUE 列包含外部表中每一行的所有数据。

  用于保护虚拟列的策略中的数据类型取决于虚拟列的数据类型。

关于掩码策略中的条件列，可以将虚拟列列为条件列实参，以确定是否应进行掩码处理或标记化第一个列实参。但是，无法将虚拟列指定为要进行掩码处理或标记化的第一列。

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

流¶

表中列的掩码策略会延续到同一个表上的流。

依照掩码策略所定义，结果是未经授权的用户看到掩码后的数据；授权用户创建的流看到正常数据。

克隆对象¶

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

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

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

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

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

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

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

CREATE TABLE ...AS SELECT (CTAS) 语句¶

执行 CREATE TABLE ...AS SELECT (CTAS) 语句会对语句中包含的列应用任何掩码策略（即，在新表中对适用的列数据进行掩码处理）， 然后 将数据填充到新表中。遵循此流程是因为使用 CTAS 语句创建的表可能具有与源对象不同的列集，并且 Snowflake 无法将掩码策略隐式应用于新表列。

如果需要复制未掩码的数据，请使用受保护数据授权的角色来运行 CTAS 语句。创建新表后，将新表的所有权转让给其他角色，并要求掩码策略管理员将掩码策略应用到新表的列。

有关更多信息，请参阅 CREATE TABLE。

使用聚合函数和掩码列的查询¶

可以对具有掩码数据的列使用 聚合函数。

一个代表性的用例是，数据分析师希望在不需要查看实际数据的情况下获得一列社会保障号码的 COUNT。但是，如果数据分析师在掩码表列上使用 SELECT 运行查询，则查询会返回固定的掩码值。在当前会话中具有 PAYROLL 自定义角色的用户会看到未掩码的数据，而其他所有人都会看到掩码后的数据。

为了实现这一结果，请执行以下操作：

1. 表所有者在包含聚合函数的列上创建视图。

   CREATE VIEW ssn_count AS SELECT DISTINCT(ssn) FROM table1;
   

   Copy

2. 授予 ANALYST 角色对视图具有完整权限。不要授予分析师对该表的任何权限。

3. 对表列应用掩码策略。请注意，如果视图列上有策略，则表策略始终先于视图策略应用。

   CASE
     WHEN CURRENT_ROLE() IN ('PAYROLL') THEN val
     ELSE '***MASKED***'
   END;
   

   Copy

4. 对视图列执行查询。

   USE ROLE analyst;
   SELECT COUNT(DISTINCT ssn) FROM v1;
   

   Copy

掩码策略中的用户定义函数¶

UDF 可以传递到掩码策略条件中。

确保表或视图列的数据类型、UDF 和掩码策略匹配。如果数据类型不同，例如有一个表列和数据类型为 VARIANT 的 UDF，并且掩码策略（策略条件中包含此 UDF）返回 VARCHAR 数据类型，当在表列上设置此掩码策略时，Snowflake 在对表列进行查询时返回错误。

有关匹配表列、UDF 和掩码策略的数据类型的代表性示例，请参阅 CREATE MASKING POLICY 中的 在 JSON （变体）上使用 JavaScript UDFs 示例。

数据共享¶

用途:

• 如果提供程序将策略分配给共享表或视图，并且策略条件调用 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 账户必须是 Business Critical Edition 或更高版本。

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

查询配置文件¶

当用于具有掩码策略的列时，EXPLAIN 命令输出包括掩码后的数据，而不包括掩码策略主体。

以下示例生成 EXPLAIN 计划，用于查询员工身份号码和社会保障号码表。此示例中的命令以 JSON 格式生成示例。

包含社会安全号码的列具有掩码策略。

EXPLAIN USING JSON SELECT * FROM mydb.public.ssn_record;

{
  "GlobalStats": {
    "partitionsTotal": 0,
    "partitionsAssigned": 0,
    "bytesAssigned": 0
  },
  "Operations": [
    [
      {
        "id": 0,
        "operation": "Result",
        "expressions": [
          "1",
          "'**MASKED**'"
        ]
      },
      {
        "id": 1,
        "parent": 0,
        "operation": "Generator",
        "expressions": [
          "1"
        ]
      }
    ]
  ]
}

卸载数据¶

使用 COPY INTO <location> 对具有掩码策略的列执行命令会导致掩码策略应用于数据。因此，未经授权的用户在执行命令后会看到掩码后的数据。

Snowflake Native App Framework¶

有关将掩码策略用于 Snowflake Native App 的详细信息，请参阅：

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

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

• 被阻止的上下文函数。

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

为了有效管理动态数据掩码和 External Tokenization 策略，考虑对列中数据进行掩码处理的方法是否应该遵循集中式安全方法、分散式方法或这两种方法的混合会很有帮助。

下表总结了这两种方法的一些注意事项。

作为最佳实践，Snowflake 建议组织聚集所有相关的利益相关者，以确定在环境中实施列级安全性的最佳管理方法。

掩码策略权限¶

本节介绍列级安全掩码策略权限以及它们如何应用于集中式、分散式或混合管理方法。

Snowflake 为列级安全掩码策略提供以下权限。

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

以下示例显示了授予权限如何应用于不同的管理方法。向角色授予 APPLY 权限后，可以使用 ALTER TABLE ...ALTER COLUMN 语句在表列上设置掩码策略，也可以使用 ALTER VIEW 语句在视图列上设置（由对掩码策略具有 APPLY 权限的角色成员设置）。

集中管理

在集中管理方法中，只有安全官自定义角色（例如 security_officer）创建掩码策略并将其应用到表或视图中的列。这种方法可以在掩码策略管理和掩码敏感数据方面提供最大的一致性。

-- create a security_officer custom role

USE ROLE ACCOUNTADMIN;
CREATE ROLE security_officer;

-- grant CREATE AND APPLY masking policy privileges to the SECURITY_OFFICER custom role.

GRANT CREATE MASKING POLICY ON SCHEMA mydb.mysch TO ROLE security_officer;

GRANT APPLY MASKING POLICY ON ACCOUNT TO ROLE security_officer;

Copy

其中：

• schema_name

  指定架构的标识符；对于创建架构的数据库来说必须是唯一的。

  此外，标识符必须以字母字符开头，且不能包含空格或特殊字符，除非整个标识符字符串放在双引号内（例如，"My object"）。放在双引号内的标识符也区分大小写。

  有关更多详细信息，请参阅 标识符要求。

混合管理

在混合管理方法中，安全官自定义角色（例如 security_officer）创建掩码策略，并且各个团队（例如财务、工资、人力资源）将掩码策略应用到团队拥有的表或视图中的列。这种方法可以实现一致的策略创建和维护，但要求各个团队承担更多的责任来对敏感数据进行掩码处理。

USE ROLE ACCOUNTADMIN;
CREATE ROLE security_officer;
GRANT CREATE MASKING POLICY ON SCHEMA mydb.mysch TO ROLE security_officer;

Copy

SECURITY_OFFICER 自定义角色向人力资源团队（即具有 HUMAN_RESOURCES 自定义角色的用户）授予 APPLY 权限，以在 HUMAN_RESOURCES 自定义任务拥有的对象的列中对社会安全号码进行掩码处理（例如掩码策略：ssn_mask）。

USE ROLE security_officer;
GRANT APPLY ON MASKING POLICY ssn_mask TO ROLE human_resources;

Copy

其中：

• grant apply on masking policy policy_name to role role_name;

  由策略所有者用来将列上给定掩码策略的取消设置和设置操作分散给对象所有者。

  此权限支持 自主访问控制，其中对象所有者也视为数据管理员。

去中心化方法

在分散管理方法中，各个团队创建掩码策略并将其应用到表或视图中的列。这种方法可能会导致策略管理不一致，并且可能无法正确对敏感数据进行掩码处理，因为各个团队承担管理掩码策略和掩码敏感数据的所有责任。

在此代表性示例中，支持团队（即具有自定义角色 SUPPORT 的用户）和财务团队（即具有自定义 FINANCE 角色的用户）可以创建掩码策略。请注意，这些自定义角色可能不包括 SECURITY_OFFICER 自定义角色。

USE ROLE ACCOUNTADMIN;
GRANT CREATE MASKING POLICY ON SCHEMA mydb.mysch TO ROLE support;
GRANT CREATE MASKING POLICY ON SCHEMA <DB_NAME.SCHEMA_NAME> TO ROLE FINANCE;

Copy

支持团队向人力资源团队（即具有自定义角色 HUMAN_RESOURCES 的用户）授予 APPLY 权限，以在 HUMAN_RESOURCES 自定义任务拥有的对象的列中对社会安全号码进行掩码处理（例如掩码策略：ssn_mask）。

USE ROLE support;
GRANT APPLY ON MASKING POLICY ssn_mask TO ROLE human_resources;

Copy

财务团队向内部审计团队（即具有自定义角色 AUDIT_INTERNAL 的用户）授予 APPLY 权限，以在 AUDIT_INTERNAL 自定义角色拥有的对象的列中对现金流数据进行掩码处理（例如，掩码策略：cash_flow_mask）。

USE ROLE finance;
GRANT APPLY ON MASKING POLICY cash_flow_mask TO ROLE audit_internal;

Copy

有关掩码策略权限的更多信息，请参阅：

• 使用动态数据掩码

• 使用 External Tokenization

掩码策略 DDL¶

Snowflake 提供以下一组命令来管理列级安全掩码策略。

• CREATE MASKING POLICY

• ALTER MASKING POLICY （另请参阅：ALTER TABLE、ALTER TABLE ...ALTER COLUMN 和 ALTER VIEW）

• DROP MASKING POLICY

• SHOW MASKING POLICIES

• DESCRIBE MASKING POLICY

下表总结了列级安全掩码策略 DDL 操作及其所需权限之间的关系。

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

发现掩码策略¶

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

SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.MASKING_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(
      'my_table',
      'table'
    )
  );
  

  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 选项卡。您可以根据需要编辑标签和策略分配。

有关更多详细信息，请参阅 标签和策略发现