使用行访问策略¶
本主题介绍如何实施行访问策略。
实施行访问策略¶
以下小节提供有关如何实施行访问策略的示例:
使用具有映射表查找的典型行访问策略。
将现有的行访问策略子查询替换为可记忆的函数,以提高查询性能。
在不同的行访问策略中引用受行访问策略保护的映射表。
示例:映射表查找¶
以下步骤是配置行访问策略权限以及向表和视图添加行访问策略的代表性指南。
这些步骤做出以下假设:
管理方法是集中的。
如果行访问策略用例包括混合或分散管理方法,请参阅 管理行访问策略 以了解角色和权限的典型分布。
映射表是必需的,类似于 代表性用例:使用映射表筛选查询结果。
以下步骤使用 CURRENT_ROLE 上下文函数来确定用户是否在查询结果中看到行,而代表性用例则侧重于用户的名称(即 CURRENT_USER)。
如果角色激活和角色层次结构很重要,Snowflake 建议策略条件对账户角色使用 IS_ROLE_IN_SESSION 函数,并对数据库角色使用 IS_DATABASE_ROLE_IN_SESSION 函数。有关详细信息,请参阅 活动角色层次结构和映射表。
即使上下文函数不同,使用映射表实施行访问策略的整个过程也保持不变。
SECURITYADMIN 系统角色向自定义角色授予权限,以管理和实施行访问策略。
如果您不想在生产环境中使用权限较高的角色(即 SECURITYADMIN 或 ACCOUNTADMIN),而是使用权限较低的自定义角色(如
database_admin、finance_admin),请验证权限较低的角色是否具有管理和实施行访问策略的必要权限。有关更多信息,请参阅 行访问策略权限 和 DDL 命令、操作和权限总结。
创建受行访问策略保护的表(步骤 1)和将行访问策略添加到表(步骤 5)有单独的步骤。在创建表时,可以向表添加行访问策略,前提是行访问策略已存在。有关语法的详细信息,请参阅 CREATE TABLE。
例如:
为销售数据创建表:
在
security架构中,创建一个映射表,如 代表性示例 所示。此表定义了销售经理可以在sales表中看到哪些行:接下来,安全管理员创建
mapping_role自定义角色并将 SELECT 权限授予该自定义角色。此授权允许具有自定义角色的用户查询映射表:使用架构所有者角色,创建具有以下两个条件的行访问策略:
具有
sales_executive_role自定义角色的用户可以查看所有行。具有
sales_manager自定义角色的用户可以根据salesmanagerregions映射表查看行。
请注意,系统会自动向架构所有者角色授予 CREATE ROW ACCESS POLICY 权限。如果其他角色应该能够创建行访问策略,则架构所有者角色可以将 CREATE ROW ACCESS 策略权限授予其他角色。
其中:
security.sales_policysecurity架构中行访问策略的名称。AS (sales_region varchar)行访问策略的签名。
签名指定映射表属性和数据类型。返回的值确定用户是否有权访问添加行访问策略的表或视图上的给定行。
'sales_executive_role' = CURRENT_ROLE()行访问策略内
body的开头。行访问策略表达式的第一个条件,允许具有
sales_executive_role自定义角色的用户查看数据。OR EXISTS (select 1 from salesmanagerregions WHERE sales_manager = CURRENT_ROLE() AND region = sales_region)使用子查询的行访问策略表达式的第二个条件。
子查询要求 CURRENT_ROLE 为
sales_manager自定义角色,并对数据执行查询以指定{salesmanagerregions}映射表中列出的区域。
使用 SECURITYADMIN 系统角色,执行以下两个语句:
这两个 GRANT <privileges> ... TO ROLE 语句具有以下效果:
策略的所有权不属于 SECURITYADMIN 系统角色。在查询运行时,Snowflake 使用授予自定义角色的权限,因为策略是以 所有者的权限 执行的,而不是具有更高权限的 SECURITYADMIN 系统角色。此方法支持最低权限原则。
sales_analyst_role自定义角色可以根据需要在表中添加或删除行访问策略。
将行访问策略添加(绑定)到
sales数据表中的区域列:将受保护
sales数据的 SELECT 权限授予sales_manager_role自定义角色:销售数据填充
sales数据后,测试行访问策略:
示例:将策略子查询替换为可记忆的函数¶
本示例中的步骤为行访问策略条件中的每个映射表查找创建一个 可记忆的函数。每个 EXISTS 子句中的子查询指定映射表查找,其中表分别命名为 regions、customers 和 products:
对于以下步骤,假设 rap_admin 自定义角色可以创建行访问策略(即具有对 SCHEMA CREATE ROW ACCESS POLICY 的权限)。
完成以下步骤,将每个行访问策略映射表查找替换为可记忆的函数:
创建一个名为
functions_admin的自定义角色来管理可记忆的函数:向
functions_admin角色授予以下权限,以允许在名为governance.functions的现有架构中创建可记忆的函数:为行访问策略中的每个
EXISTS子查询子句创建一个可记忆的函数。每个可记忆的函数定义都采用相同的形式。为简洁起见,仅显示一个函数示例:使用 CREATE ROW ACCESS POLICY 语句定义新的行访问策略,该策略将子查询替换为可记忆的函数:
新的行访问策略允许在策略使用或不使用可记忆函数时测试对受保护表的查询,以量化在策略条件下使用可记忆函数的性能影响:
示例:使用行访问策略保护映射表¶
此示例说明如何在不同的行访问策略中引用受行访问策略保护的映射表。保护映射表的行访问策略调用 IS_ROLE_IN_SESSION 上下文函数来说明角色层次结构。不同的行访问策略可保护用户查询的表。此行访问策略使用子查询来执行映射表查找。例如:
创建一个映射表,以根据地理销售区域定义允许的角色,并将数据插入到表中:
创建行访问策略以指定映射表中的 ALLOWED_ROLES 列:
使用 ALTER TABLE 语句在映射表中添加行访问策略:
创建一个新的行访问策略,用于指定对受保护的映射表进行映射表查找:
使用 ALTER TABLE 语句在名为
sales.tables.data的表中添加名为governance.policies.rap_map_lookup的行访问策略:向映射表中的角色授予权限,以允许具有这些角色的用户查询受保护的数据。例如,这些授权适用于
na_manager自定义角色:如有必要,请对映射表中的每个角色重复此步骤中的命令。