访问控制概述¶

本主题提供有关 Snowflake 中主要访问控制主题的信息。

本主题内容：

访问控制框架¶

Snowflake 的访问控制方法结合了以下两个模型的各个方面：

自主访问控制 (DAC)： 每个对象都有一个所有者，所有者可以授予对象访问权限。
基于角色的访问控制 (RBAC)： 访问权限分配给角色，角色分配给用户。

理解 Snowflake 中访问控制的关键概念包括：

安全对象： 可以向其授予访问权限的实体。除非获得授权，否则拒绝访问。
角色： 可授予权限的实体。角色会分配给用户。请注意，角色也可以分配给其他角色，从而创建角色层次结构。
权限： 对象的定义访问级别。可以使用多项不同的权限来控制授予的访问权限粒度。
用户： 与个人或程序关联的 Snowflake 识别的用户身份。

在 Snowflake 模型中，允许通过分配给角色的权限来访问安全对象，这些权限会分配给用户或其他角色。将一个角色授予另一个角色会创建角色层次结构，这在角色层次结构和权限继承部分（本主题内容）中已作解释。

此外，每个安全对象都有一个所有者，可以向其他角色授予访问权限。此模型不同于基于用户的访问控制模型，在基于用户的访问控制模型中，权限会分配给每个用户或用户组。Snowflake 模型旨在提供大量的控制和灵活性。

安全对象¶

每个安全对象都位于容器层次结构中的逻辑容器内。最顶层的容器是客户组织。表、视图、函数和暂存区等安全对象包含在架构对象中，而架构对象又包含在数据库中。Snowflake 账户的所有数据库都包含在账户对象中。对象和容器的层次结构如下图所示：

拥有对象表示角色拥有对象的 OWNERSHIP 权限。每个安全对象都归单个角色所有，默认情况下是用于创建对象的角色。当将此角色分配给用户时，他们实际上拥有对该对象的共享控制权。GRANT OWNERSHIP 命令允许您将对象的所有权从一个角色转让给另一个角色，包括转让给数据库角色。此命令还指定每个容器中的安全对象。

在常规架构中，所有者角色默认拥有对象的所有权限，包括向其他角色授予或撤销对象权限的能力。此外，所有权可以从一个角色转让给另一角色。但在托管访问架构中，对象所有者会失去做出授权决策的能力。仅架构所有者（即拥有架构 OWNERSHIP 权限的角色）或具有 MANAGE GRANTS 权限的角色可以授予架构中对象的权限。

就对象执行 SQL 操作的能力由授予用户会话中活动角色的权限定义。以下是 Snowflake 中各种对象适用的 SQL 操作的示例：

创建仓库的能力。
列出架构中包含的表的能力。
将数据添加到表中的能力。

角色¶

角色是可以向其授予和撤销对其安全对象的权限的实体。角色会分配给用户，以便他们执行组织中业务职能所需的操作。可为用户分配多个角色。这允许用户切换角色（即选择在当前 Snowflake 会话中处于活动状态的角色），以使用不同的权限集执行不同的操作。

Snowflake 账户中有少量系统定义的角色。无法删除系统定义的角色。此外，无法撤销 Snowflake 授予这些角色的权限。

为满足特定的业务和安全需求，被授予具有必要权限的角色的用户可以创建自定义角色。

还可以将角色授予其他角色，从而创建角色层次结构。与某个角色相关联的权限由层次结构中该角色之上的任何角色继承。有关角色层次结构和权限继承的更多信息，请参阅角色层次结构和权限继承（本主题内容）。

备注

角色所有者（即拥有该角色 OWNERSHIP 权限的角色）不会继承所拥有角色的权限。权限继承只能在角色层次结构中进行。

尽管可以向系统定义的角色授予附加权限，但不建议这样做。系统定义的角色是使用与账户管理相关的权限创建的。作为最佳实践，建议不要同时赋予同一角色账户管理权限和特定于实体的权限。如果需要附加权限，Snowflake 建议向自定义角色授予附加权限，并将自定义角色分配给系统定义的角色。

角色类型¶

以下角色类型本质上是相同的，只是它们的范围不同。这两种类型都允许管理员授权和限制对您账户中的对象的访问。

备注

除非产品文档中另有说明，否则术语角色可以指任一类型。

账户角色:

若准许对您账户中的任何对象执行 SQL 操作，则需将对象的权限授予账户角色。

数据库角色:

若将 SQL 操作限制为在单个数据库以及数据库中的任何对象，则需将对象的权限授予同一数据库中的数据库角色。

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

有关数据库角色的更多信息，请参阅：

实例角色:

若要允许访问类的实例，则需将实例角色授予账户角色。

一个类可以有一个或多个类角色，每个角色被授予不同的权限。在创建类实例时，可以将实例角色授予账户角色，以便授予访问实例方法的权限。

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

有关更多信息，请参阅实例角色。

应用程序角色:

要启用使用者对 Snowflake Native App 中对象的访问，提供商创建应用程序角色，并在设置脚本中向应用程序角色授予权限。

但是，为了支持特定功能的特定功能，例如授予对 Snowflake 是所有者的对象的访问权限，Snowflake 可以提供一个或多个 系统应用程序角色。您可以自行决定将系统应用程序角色授予账户角色。

系统应用程序角色在特定功能的上下文中讨论，因为该特定功能是可以使用系统应用程序角色的唯一位置。例如：

预算：用于管理账户预算的应用程序角色。
数据质量和数据指标函数 (DMFs)：查看 DMF 结果。

服务角色:: 要允许角色访问服务端点，请将服务角色授予该角色。您可以将服务角色授予账户角色、应用程序角色或数据库角色。有关更多信息，请参阅管理对服务端点的访问。

活动角色¶

活动角色 是用户在会话中执行任何操作的授权来源。主要角色和任何次要角色都可以在用户会话中激活。

角色可通过以下任一方式成为活动角色：

首次建立会话时，用户的默认角色和默认次要角色分别激活为会话主要角色和次要角色。

请注意，用于建立会话的客户端连接属性可以显式替换要使用的主要角色或次要角色。
执行 USE ROLE 或 USE SECONDARY ROLES 语句可分别激活不同的主要角色或次要角色。如果再次执行任一命令，这些角色可能会在会话过程中发生变化。

系统定义的角色¶

ORGADMIN:

（又名组织管理员）

管理组织级别操作的角色。更具体地说，这个角色：

可以在组织中创建账户。
可以查看组织中的所有账户（使用 SHOW ORGANIZATION ACCOUNTS）以及为组织启用的所有区域（使用 SHOW REGIONS）。
可以查看整个组织中的使用情况信息。

ACCOUNTADMIN:

（又名账户管理员）

封装 SYSADMIN 和 SECURITYADMIN 系统定义的角色的角色。它是系统中的顶级角色，应仅授予您账户中有限/受控数量的用户。

SECURITYADMIN:

（又名安全管理员）

可以全局管理任何对象授权以及创建、监控和管理用户和角色的角色。更具体地说，这个角色：

被授予 MANAGE GRANTS 安全权限，能够修改任何授权，包括撤销该权限。
通过系统角色层次结构（即将 USERADMIN 角色授予 SECURITYADMIN）继承 USERADMIN 角色的权限。

USERADMIN:

（又名用户和角色管理员）

仅专用于用户和角色管理的角色。更具体地说，这个角色：

被授予 CREATE USER 和 CREATE ROLE 安全权限。
可以在账户中创建用户和角色。

该角色还可以管理它拥有的用户和角色。仅拥有对象 OWNERSHIP 权限的角色（即用户或角色）或更高级别的角色可以修改对象属性。

SYSADMIN:

（又名系统管理员）

有权在账户中创建仓库和数据库（以及其他对象）的角色。

如果您按照建议创建角色层次结构，最终将所有自定义角色分配给 SYSADMIN 角色，那么该角色还具有将仓库、数据库和其他对象的权限授予其他角色的能力。

PUBLIC:

自动授予账户中每个用户和角色的伪角色。PUBLIC 角色可以拥有安全对象，就像任何其他角色一样；但是，根据定义，该角色拥有的对象可供您账户中的所有其他用户和角色使用。

此角色通常用于不需要显式访问控制以及所有用户的访问权限都被视为平等的用例。

自定义角色¶

可以使用 USERADMIN 角色（或更高级别的角色）和获授了 CREATE ROLE 权限的任何角色创建自定义账户角色。

自定义数据库角色可以由数据库所有者（即具有数据库 OWNERSHIP 权限的角色）创建。

默认情况下，新创建的角色不会分配给任何用户，也不会授予任何其他角色。

在系统中创建充当安全对象所有者的角色时， Snowflake 建议创建自定义角色的层次结构，并将最顶层的自定义角色分配给系统角色 SYSADMIN。这种角色结构允许系统管理员管理账户中的所有对象，例如仓库和数据库对象，同时将用户和角色的管理限制为 USERADMIN 角色。

相反，如果未通过角色层次结构将自定义角色分配给 SYSADMIN，则系统管理员无法管理角色拥有的对象。只有那些获授了 MANAGE GRANTS 权限的角色（默认仅 SECURITYADMIN 角色）可以查看对象并修改其访问授权。

有关创建自定义角色的说明，请参阅创建自定义角色。

权限¶

访问控制权限决定了谁可以访问 Snowflake 中的特定对象并对其执行操作。每个安全对象都有一组可向其授予的权限。对于现有对象，必须向各个对象授予权限（例如 mytable 表的 SELECT 权限）。为了简化授权管理，未来的授权允许为在架构中创建的对象定义一组初始权限（即将在 myschema 架构中创建的所有新表的 SELECT 权限授予指定角色）。

权限使用 GRANT <privileges> 和 REVOKE <privileges> 命令管理。

在常规（即非托管）架构中，这些命令的使用仅限于拥有对象的角色（即拥有对象的 OWNERSHIP 权限）或拥有对象的 MANAGE GRANTS 全局权限的任何角色（默认仅 SECURITYADMIN 角色）。
在托管访问架构中，对象所有者会失去做出授权决策的能力。只有架构所有者或拥有 MANAGE GRANTS 权限的角色才能授予架构中对象的权限，包括未来的授权，从而集中进行权限管理。

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

有关更多详细信息，请参阅访问控制权限。

角色层次结构和权限继承¶

下图说明了系统定义的角色的层次结构，以及其他用户定义的账户角色和数据库角色的建议结构。示例层次结构中的最高级别数据库角色被授予自定义（即用户定义的）账户角色。接着，该角色被授予建议结构中的另一个自定义角色，该结构允许系统定义的 SYSADMIN 角色继承自定义账户角色和数据库角色的权限：

备注

ORGADMIN 是一个单独的系统角色，用于管理组织级别的操作。该角色不包含在系统角色的层次结构中。

有关角色层次结构和权限继承的更具体示例，请考虑以下场景：

角色 3 已授予角色 2。

角色 2 已授予角色 1。

角色 1 已授予用户 1。

在这种情况下：

角色 2 继承权限 C。

角色 1 继承权限 B 和 C。

用户 1 拥有所有这三项权限。

数据库角色和角色层次结构¶

目前，以下限制适用于数据库角色：

如果授予数据库角色共享，则不能向该数据库角色授予其他数据库角色。例如，如果授予数据库角色 d1.r1 共享，那么尝试将数据库角色 d1.r2 授予 d1.r1 时将被阻止。

此外，如果向其他数据库角色授予数据库角色，则不能向被授予的数据库角色授予共享。

可以将获授共享的数据库角色授予其他数据库角色和账户角色。
账户角色不能授予角色层次结构中的数据库角色。

具有主要角色和次要角色的执行模型¶

每个活动用户会话都有一个“当前角色”，也称为 主要角色。在会话启动（例如用户通过 JDBC/ODBC 连接或登录Snowflake Web 界面）时，当前角色根据以下标准确定：

如果已将某个角色指定为连接的一部分，并且该角色是已授予连接用户，则指定的角色将成为当前角色。
如果未指定角色并且已为连接用户设置了默认角色，则该角色将成为当前角色。
如果未指定角色且没有为连接用户设置默认角色，则使用系统角色 PUBLIC。

此外，可以在用户会话中激活一组次要角色。用户可以使用授予主要角色和次要角色的聚合权限对会话中的对象执行 SQL 操作。将角色授予用户，然后才能在会话中激活这些角色。请注意，虽然会话一次必须只有一个活动主要角色，但可以同时激活任意数量的次要角色。

备注

数据库角色既不能是主要角色，也不能是次要角色。要获得授予数据库角色的权限，请将数据库角色授予账户角色。只有账户角色可以在会话中激活。

只有主要角色才有执行 CREATE <object> 语句的授权。创建对象时，其所有权将设置为当前活动的主要角色。然而，对于任何其他 SQL 操作，授予任何活动主要或次要角色的任何权限都可以用于授权该操作。例如，如果次要角色层次结构中的任何角色拥有一个对象（即具有对象的 OWNERSHIP 权限），则次要角色将授权对对象执行任何 DDL 操作。主要角色以及所有次要角色都继承其角色层次结构中较低角色的权限。

对于安全模型包含大量角色且每个角色都通过权限进行细粒度授权的组织来说，使用次要角色可以简化角色管理。授予用户的所有角色都可以在会话中激活。次要角色特别适用于跨数据库联接等 SQL 操作，否则需要创建有权访问每个数据库中的对象的角色的父角色。

在会话过程中，用户可以使用 USE ROLE 或者 USE SECONDARY ROLES 命令分别更改当前的主要或次要角色。用户可以使用 CURRENT_SECONDARY_ROLES 函数显示当前会话的所有活动次要角色。

如果您创建需要一项或多项权限才能使用的对象，那么在搜索这些权限的授予时，仅考虑主要角色及其直接或间接继承的角色。

对于任何其他需要一项或多项权限的语句（例如查询表需要对表具有 SELECT 权限，同时需要对数据库和架构具有 USAGE 权限），在搜索这些权限的授予时，会考虑主要角色、次要角色以及任何其他继承的角色。

备注

Snowflake 中不存在可以绕过授权检查的“超级用户”或“超级角色”概念。所有访问都需要适当的访问权限。