访问控制注意事项¶

使用 ACCOUNTADMIN 角色¶

账户管理员（即具有 ACCOUNTADMIN 系统角色的用户）角色是系统中最强大的角色。仅有该角色负责配置账户级别的参数。具有 ACCOUNTADMIN 角色的用户可以查看和管理 Snowflake 计费和 credit 数据，并且可以停止任何正在运行的 SQL 语句。

请注意， ACCOUNTADMIN 不是 超级用户角色。该角色仅允许查看和管理账户中的对象（如果该角色或 角色层次结构 中较低级别的账户具有足够的对象权限。

在系统角色层次结构中，其他管理员角色是此角色的子级：

• 用户管理员 (USERADMIN) 角色包括创建和管理用户和角色的权限（假设这些角色或用户的所有权尚未转移给另一个角色）。

• 安全管理员（SECURITYADMIN 系统定义）角色包括全局 MANAGE GRANTS 权限，用于授予或撤销账户中对象的权限。USERADMIN 角色是该角色在默认访问控制层次结构中的子角色。有关系统定义的子角色的更多信息，请参阅 系统定义的角色。

• 系统管理员 (SYSADMIN) 角色包括创建仓库、数据库及所有数据库对象（架构、表等）的权限。

访问数据库对象¶

所有安全的数据库对象（例如 TABLE、FUNCTION、FILE FORMAT、STAGE、SEQUENCE 等）均包含在 DATABASE 的一个 SCHEMA 对象内。因此，要访问数据库对象，除了特定数据库对象的权限之外，还必须授予用户对于容器数据库和架构的 USAGE 权限。

例如，假设在 mydb.myschema 中创建了 mytable。要查询 mytable，用户必须至少具备以下权限：

数据库:

mydb 的 USAGE

架构:

myschema 的 USAGE

表:

mytable 的 SELECT

管理自定义角色¶

首次创建自定义角色时，角色是独立存在的。必须将该角色分配给将使用与该角色关联的对象权限的任何用户。此外，必须将自定义角色授予将管理由自定义角色创建的对象的任何角色。

有关创建角色层次结构的说明，请参阅 创建角色层次结构。

使对象访问权限与业务职能保持一致¶

考虑利用角色层次结构，将对于数据库对象的访问权限与组织中的业务职能保持一致。在角色层次结构中，角色被授予其他角色，由此形成继承关系。下级角色授予的权限会被上级角色所继承。

在控制对数据库对象的访问权限方面，为了获得最佳灵活性，请创建具有不同对象权限的对象 访问角色 组合，并按需将其分配给 职能角色：

• 向访问角色授予对数据库对象或账户对象（例如仓库）的权限。

• 将访问角色授予职能角色，以创建角色层次结构。这些角色与您组织的业务职能相对应，并作为这些职能所需的任何访问角色的统称。

  在适当时，利用父子关系将较低级别的职能角色授予较高级别的职能角色，将父角色映射到应包含子角色权限的业务职能。

  遵循有关角色层次结构的最佳实践，将角色层次结构中最高级别的职能角色授予系统管理员 (SYSADMIN) 角色。随后，系统管理员可将数据库对象的权限授予此层次结构中的任意角色：

示例¶

举一个简单的例子，假设一个账户中有 fin 和 hr 这两个数据库，分别包含工资单和员工数据。为了履行各自的业务职能，组织中的会计师和分析师需要具备这些数据库中对象的不同权限。会计师应具有 fin 的读写权限，但对于 hr，可能只需要只读权限，因为此数据库中的数据由人力资源部的人员负责维护。分析师可能需要这两个数据库的只读访问权限。

对现有数据库对象的权限通过以下访问角色和职能角色层次结构授予：

备注

在每个数据库中添加新对象时，请考虑根据对象类型（例如架构、表或视图），自动向角色授予对象的权限。相关信息请参阅 使用未来授权简化授权管理 （本主题内容）。

自定义角色	描述	权限
db_hr_r	允许对 hr 数据库内的表进行只读访问的访问角色。	hr 数据库的 USAGE 权限。 hr 数据库中所有架构的 USAGE 权限。 hr 数据库中所有表的 SELECT 权限。
db_fin_r	允许对 fin 数据库内的表进行只读访问的访问角色。	fin 数据库的 USAGE 权限。 fin 数据库中所有架构的 USAGE 权限。 fin 数据库中所有表的 SELECT 权限。
db_fin_rw	允许对 fin 数据库内的表进行读写访问的访问角色。	fin 数据库的 USAGE 权限。 fin 数据库中所有架构的 USAGE 权限。 fin 数据库中所有表的 SELECT、 INSERT、 UPDATE、 DELETE 权限。
accountant	会计师在组织中的职能角色。	不适用
analyst	分析师在组织中的职能角色。	不适用

下图展示了此示例的角色层次结构：

要为此示例配置访问控制，请执行以下操作：

1. 作为用户管理员（具有 USERADMIN 角色的用户）或具备账户 CREATE ROLE 权限的另一个角色，创建本例中的访问角色和职能角色：

   CREATE ROLE db_hr_r;
   CREATE ROLE db_fin_r;
   CREATE ROLE db_fin_rw;
   CREATE ROLE accountant;
   CREATE ROLE analyst;
   

   Copy

2. 作为安全管理员（具有 SECURITYADMIN 角色的用户）或具备账户 MANAGE GRANTS 权限的另一个角色，向每个访问角色授予所需的最小权限：

   -- Grant read-only permissions on database HR to db_hr_r role.
   GRANT USAGE ON DATABASE hr TO ROLE db_hr_r;
   GRANT USAGE ON ALL SCHEMAS IN DATABASE hr TO ROLE db_hr_r;
   GRANT SELECT ON ALL TABLES IN DATABASE hr TO ROLE db_hr_r;
   
   -- Grant read-only permissions on database FIN to db_fin_r role.
   GRANT USAGE ON DATABASE fin TO ROLE db_fin_r;
   GRANT USAGE ON ALL SCHEMAS IN DATABASE fin TO ROLE db_fin_r;
   GRANT SELECT ON ALL TABLES IN DATABASE fin TO ROLE db_fin_r;
   
   -- Grant read-write permissions on database FIN to db_fin_rw role.
   GRANT USAGE ON DATABASE fin TO ROLE db_fin_rw;
   GRANT USAGE ON ALL SCHEMAS IN DATABASE fin TO ROLE db_fin_rw;
   GRANT SELECT,INSERT,UPDATE,DELETE ON ALL TABLES IN DATABASE fin TO ROLE db_fin_rw;
   

   Copy

3. 作为安全管理员（具有 SECURITYADMIN 角色的用户）或具备账户 MANAGE GRANTS 权限的另一个角色，将 db_fin_rw 访问角色授予 accountant 职能角色，并将 db_hr_r db_fin_r 访问角色授予 analyst 职能角色：

   GRANT ROLE db_fin_rw TO ROLE accountant;
   GRANT ROLE db_hr_r TO ROLE analyst;
   GRANT ROLE db_fin_r TO ROLE analyst;
   

   Copy

4. 作为安全管理员（具有 SECURITYADMIN 角色的用户）或具备账户 MANAGE GRANTS 权限的另一个角色，将 analyst 和 accountant 角色同时授予系统管理员 (SYSADMIN) 角色：

   GRANT ROLE accountant,analyst TO ROLE sysadmin;
   

   Copy

5. 作为安全管理员（具有 SECURITYADMIN 角色的用户）或具备账户 MANAGE GRANTS 权限的另一个角色，将业务职能角色授予在组织中履行这些业务职能的用户。在此示例中，analyst 职能角色被授予 user1 用户，accountant 职能角色被授予 user2 用户。

   GRANT ROLE accountant TO USER user1;
   GRANT ROLE analyst TO USER user2;
   

   Copy

使用数据库角色管理数据库对象的访问权限¶

本质上来说，数据库角色与在账户级别上创建的传统 角色 （即自定义 账户角色）是相同的，只是两者的范围有所不同：要允许对数据库内的对象执行 SQL 操作，可将权限授予 同一个数据库内 的数据库角色。

数据库角色旨在满足以下用例的需要：

易管理性:

数据库所有者可以独立管理对自己的数据库中安全对象的访问。数据库所有者可以执行以下操作：

• 创建和管理数据库角色。

• 向数据库角色授予权限。

  授予数据库角色的对象权限的范围必须限于该角色所在数据库内包含的对象。一个数据库内的对象（例如表或视图）的权限不能授予另一个数据库中的数据库角色。

  任何 权限（包括 OWNERSHIP）均可授予数据库内对象的数据库角色。请注意，只有账户角色才能拥有数据库本身的 OWNERSHIP 权限。

• 创建或扩展 角色层次结构。将数据库角色授予同一数据库内的其他数据库角色，然后将数据库中最高级别的数据库角色授予账户角色。有关更多信息，请参阅 角色层次结构和权限继承。

  请注意，将数据库角色授予账户角色时，会隐式地将包含数据库角色的数据库 USAGE 权限授予该账户角色。无需显式授予数据库的 USAGE 权限。

数据共享:

Snowflake Secure Data Sharing 中的数据提供商可对共享内的安全对象进行分段，方法是在数据库中创建多个数据库角色来进行共享，并向各数据库角色授予数据库中对象子集的权限。从包含数据库角色的共享中创建数据库后，数据使用者将每个共享数据库角色授予其自己账户中的一个或多个账户级角色。

如果没有数据库角色，数据使用者账户中的账户管理员向角色授予 IMPORTED PRIVILEGES 这项权限，以允许其用户访问共享中的 所有 数据库和数据库对象（表、安全视图等）。没有选项可让数据使用者账户中的不同用户组访问共享对象的子集。这种“全有或全无”式方法要求数据提供商创建多个共享，以授予对相同数据库中不同对象的访问权限。

请注意，数据库角色无法在会话中直接 激活。将数据库角色授予账户角色，账户角色在会话中可激活。

使用托管访问架构集中管理授权¶

对于数据库中的常规（即非托管）架构，对象所有者（即具有一个或多个对象的 OWNERSHIP 权限的角色）可将这些对象的访问权限授予其他角色，并可以选择进一步授予这些角色管理对象授权的能力。

要进一步锁定对象安全性，可考虑使用托管访问架构。在托管访问架构中，对象所有者会失去做出授权决策的能力。只有架构所有者（即拥有架构 OWNERSHIP 权限的角色）或拥有 MANAGE GRANTS 权限的角色才能授予架构中对象的权限，包括 未来的授权，从而集中权限管理。

请注意，拥有全局 MANAGE GRANTS 权限的角色可以授予当前（授予者）角色附加权限。

有关托管访问架构的更多信息，请参阅 创建托管访问架构。

使用未来授权简化授权管理¶

未来授权允许在指定架构中定义特定类型对象（例如表或视图）的初始权限集。创建新对象时，系统会自动将已定义的权限授予角色，因此可以简化授权管理。

考虑以下场景，其中向特定角色授予了架构中创建的所有新表的 SELECT 权限。后续决定撤销该角色的此项权限，并将其授予另外一个角色。通过为新表使用 ON FUTURE 关键字，为现有表使用 ALL 关键字，仅需寥寥几条 SQL 语句即可授予和撤销对新表和现有表的权限。例如：

-- Grant the SELECT privilege on all new (i.e. future) tables in a schema to role R1
GRANT SELECT ON FUTURE TABLES IN SCHEMA s1 TO ROLE r1;

-- / Create tables in the schema /

-- Grant the SELECT privilege on all new tables in a schema to role R2
GRANT SELECT ON FUTURE TABLES IN SCHEMA s1 TO ROLE r2;

-- Grant the SELECT privilege on all existing tables in a schema to role R2
GRANT SELECT ON ALL TABLES IN SCHEMA s1 TO ROLE r2;

-- Revoke the SELECT privilege on all new tables in a schema (i.e. future grant) from role R1
REVOKE SELECT ON FUTURE TABLES IN SCHEMA s1 FROM ROLE r1;

-- Revoke the SELECT privilege on all existing tables in a schema from role R1
REVOKE SELECT ON ALL TABLES IN SCHEMA s1 FROM ROLE r1;

有关未来授权的更多信息，请参阅 为对象分配未来的授权。

查看查询结果¶

用户不能查看其他用户执行的查询的结果集。这是一种故意设计的行为。出于安全方面的原因，只有执行查询的用户才能访问查询结果。

了解克隆的对象和授予的权限¶

克隆数据库、架构或表会创建源对象的副本。克隆的对象包括在创建克隆时，源对象中存在的数据的快照。

克隆的对象在 Snowflake 中被视为新对象。针对源对象授予的任何权限都不会转移到克隆的对象。但克隆的容器对象（数据库或架构）会保留针对源对象中所含对象授予的任何权限。例如，克隆的架构会保留针对源架构中的表、视图、 UDFs 及其他对象授予的所有权限。

有关克隆的更多详细信息，请参阅 克隆注意事项 和 CREATE <object> ...CLONE。