7.1 RBAC访问控制模型

7.1 RBAC访问控制模型

本节摘要：Snowflake 的权限体系是纯 RBAC（基于角色）：用户持有角色，角色持有权限，权限落在对象上——权限永远不直接授给用户。本节讲清四层关系、系统角色的分工、角色树的两条设计原则（按职能不按人头、层级浅而清晰），以及 Future Grants 与所有权转移两个高频工程问题。

权限的四个抽象层

先接上体系：2.2 说访问控制是云服务层的一道门禁，本节看这道门禁的内部构造。四个抽象层自上而下：

• 用户（USER）：人的身份，可以没有表权限；
• 角色（ROLE）：权限的容器，可以继承其他角色；
• 权限（PRIVILEGE）：SELECT、INSERT、CREATE 等操作动词；
• 对象（SECURABLE OBJECT）：库、模式、表、视图、仓库、暂存区等。

规则只有一条核心：GRANT 的两端只能是"角色→对象"或"角色→角色"，永远不是"用户→对象"。 用户像员工工牌，角色像岗位职级——换岗换牌不换职级，职级变更不影响工牌。这个隔离让人员流动不再牵动权限模型。

图：RBAC 角色层次设计示例

系统角色：五个内置岗位

账户初始化就带有五个系统角色，理解它们的分工是理解平台管理模型的前提：

• SYSADMIN：默认拥有所有创建的数据库与对象，日常对象管理的顶点；
• SECURITYADMIN：管用户与角色本身（授权、回收、建用户）；
• USERADMIN：仅用户与角色的创建维护；
• ACCOUNTADMIN：账户的最高权限——管资源监控、账户参数、加密密钥配置，持有着它的人能看到和改一切；
• PUBLIC：所有角色自动继承的基座，等价于"每个人"。

实践中最值得强调的是 ACCOUNTADMIN 的纪律：它不是日常运维角色。日常对象活儿在 SYSADMIN，账户级配置才临时切换 ACCOUNTADMIN；把它绑定给自动化脚本或随手共享给团队，等于把整个账户的钥匙挂在大门上。多数合规审计的第一个检查项就是 ACCOUNTADMIN 的持有人清单与启用频率。

动手：搭一棵最小的角色树

-- 用 SECURITYADMIN 建用户与角色，用 SYSADMIN 授权对象
USE ROLE SECURITYADMIN;
CREATE ROLE dw_reader;
CREATE ROLE dw_loader;
CREATE USER alice DEFAULT_ROLE = dw_reader
  MUST_CHANGE_PASSWORD = TRUE;
GRANT ROLE dw_reader TO USER alice;

USE ROLE SYSADMIN;
-- 对象权限授给角色
GRANT USAGE ON WAREHOUSE bi_wh TO ROLE dw_reader;
GRANT USAGE ON DATABASE core_dw TO ROLE dw_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA core_dw.marts TO ROLE dw_reader;

-- 未来授权：今后新建的表自动带 SELECT——建模层最常见的"漏权"补丁
GRANT SELECT ON FUTURE TABLES IN SCHEMA core_dw.marts TO ROLE dw_reader;
GRANT INSERT, SELECT ON FUTURE TABLES IN SCHEMA core_dw.raw TO ROLE dw_loader;

-- 层级挂接：职能角色继承到 SYSADMIN 之下（对象归属链路清晰）
GRANT ROLE dw_reader TO ROLE SYSADMIN;
​

三个高频坑都藏在这段 SQL 里。坑一：USAGE 断链。查一张表需要"仓库 USAGE + 数据库 USAGE + 模式 USAGE + 表 SELECT"逐级 USAGE 齐备，新人最常见的报错不是"没权限"而是"对象不存在"——某一级 USAGE 缺失时系统不透露对象存在性，这本身是安全特性。坑二：ALL 与 FUTURE 的差别。ALL TABLES 只覆盖现存表，ETL 每天新建的表要靠 FUTURE 授权。坑三：对象所有权漂移。谁 CREATE 的表归谁的角色，若用个人角色建了生产表，人离职时对象悬空——生产对象应统一由服务角色创建，或及时 GRANT OWNERSHIP 归拢。

审计入口：两类历史

权限配好了，事后审计有两类账本可查：查询历史（谁在什么时候跑了什么 SQL、用了哪个仓库）适合回答"这次误操作是谁执行的"；访问历史（列级血缘：哪条查询读了哪些列、写到了哪些列）适合合规场景回答"敏感列被哪些下游消费过"。两者都在 ACCOUNT_USAGE 视图中可查，保留一年，第8章的成本归因也用查询历史。

💡 关键直觉：RBAC 设计的目标不是"能配出多细的控制"，而是让人看得懂。审计、交接、扩权申请都发生在角色树上——一棵两层深的清晰角色树，远胜一棵五层的完备角色树。

本节要点回顾

• 四层抽象：用户→角色→权限→对象；权限只授给角色，人员流动不牵动权限模型。
• 系统角色：SYSADMIN 管对象，SECURITYADMIN 管主体，ACCOUNTADMIN 是账户钥匙，只救急不日常。
• 三个坑：USAGE 逐级断链报"不存在"、FUTURE 授权补新建表、所有权漂移悬空对象。
• 审计双账本：查询历史回答"谁干的"，访问历史回答"敏感列流向了哪"。

角色解决"谁进门"。门被撞开了怎么办？下一节看物理层的兜底：加密。

问题：角色越建越多怎么办？

角色爆炸是 RBAC 治理失控的头号信号，解药在源头：按职能建角色、按层级挂接，拒绝为个人或单次需求临时建角色。已有混乱时，盘点顺序是先列角色清单与挂接关系，合并同义角色，再回收三个月未用的授权。保持角色树两层可读，比追求权限精细更利于长期安全。

问题：所有权（OWNERSHIP）为什么常被单独强调？

因为它是角色的"属主"权限且不可部分授予——谁建的对象归谁的角色。生产对象散落在个人角色名下，人员一离职就出现悬空对象与交接事故。规范做法：生产对象由服务角色创建，或通过所有权转移归拢到职能角色；对象命名规范里注明属主角色。