4. 权限模型详解

Snowflake 的访问控制体系建立在“角色—权限—对象”三层结构之上。角色是权限的容器，权限是对具体对象的操作许可，而对象则构成数据库、模式、表、视图、函数等层级化的资源树。理解对象权限、授予与回收、未来权限以及继承规则，是设计可维护权限体系的核心。

对象权限：按对象类型划分的操作许可

Snowflake 中的对象权限与对象类型强绑定，不同对象支持不同的权限集合。数据库层常见权限包括 USAGE、CREATE SCHEMA、MONITOR；模式层包括 USAGE、CREATE TABLE、CREATE VIEW、CREATE FUNCTION 等；表与视图层包括 SELECT、INSERT、UPDATE、DELETE、TRUNCATE、REFERENCES；函数层包括 USAGE；阶段、流、任务等对象也有各自权限。权限名称本身表达了允许执行的操作，例如对表授予 SELECT 表示可查询该表，对模式授予 CREATE TABLE 表示可在该模式中建表。

需要特别区分“对象权限”与“全局权限”。对象权限作用于具体对象，而全局权限如 CREATE DATABASE、CREATE ROLE、MANAGE GRANTS 作用于账户级别，不属于本节讨论的对象权限范畴。对象权限的授予对象只能是角色，不能直接授予用户；用户通过被授予角色来间接获得权限。

权限授予与回收：GRANT 与 REVOKE

授予权限使用 GRANT 语句，基本形式为：

GRANT SELECT, INSERT ON TABLE sales.orders TO ROLE analyst_role;
GRANT USAGE ON DATABASE sales TO ROLE analyst_role;
GRANT USAGE ON SCHEMA sales.public TO ROLE analyst_role;
GRANT USAGE ON FUNCTION sales.public.fn_total(NUMBER) TO ROLE analyst_role;

回收权限使用 REVOKE 语句，语法与 GRANT 对称：

REVOKE INSERT ON TABLE sales.orders FROM ROLE analyst_role;
REVOKE USAGE ON SCHEMA sales.public FROM ROLE analyst_role;

授予与回收都需要当前角色具备相应授权能力。通常由对象所有者或拥有 MANAGE GRANTS 权限的角色执行。若使用 WITH GRANT OPTION，被授予角色还可以将权限继续授予其他角色，形成权限传递链。实践中应谨慎使用 WITH GRANT OPTION，避免权限扩散难以追踪。

一个常见误区是只授予表权限而忘记授予上层对象的 USAGE。在 Snowflake 中，要访问 sales.public.orders，角色必须同时拥有数据库 sales 的 USAGE、模式 public 的 USAGE 以及表 orders 的 SELECT。缺少任意一层，查询都会失败。因此授权时应按“数据库 → 模式 → 对象”的顺序逐层授予。

未来权限：Future Grants 的自动化授权

当模式中不断新建表、视图或函数时，逐一手动授权既繁琐又容易遗漏。Future Grants 允许在模式或数据库级别预先声明：未来在该范围内创建的对象自动获得指定权限。语法示例：

GRANT SELECT ON FUTURE TABLES IN SCHEMA sales.public TO ROLE analyst_role;
GRANT SELECT ON FUTURE VIEWS IN SCHEMA sales.public TO ROLE analyst_role;
GRANT USAGE ON FUTURE FUNCTIONS IN SCHEMA sales.public TO ROLE analyst_role;

Future Grants 只对“未来创建”的对象生效，不会追溯已存在的对象。因此典型做法是：先对现有对象批量授权，再设置 Future Grants 覆盖后续新增对象。Future Grants 同样支持 REVOKE，用于取消未来自动授权规则。需要注意，Future Grants 的作用范围是声明时所在的模式或数据库，若对象被移动到其他模式，原有未来权限不会自动跟随。

权限继承规则：角色层级与对象层级

Snowflake 的权限继承体现在两个维度。第一是角色层级继承：角色可以授予其他角色，形成角色树。若角色 A 授予角色 B，则 B 自动拥有 A 的全部权限。例如 GRANT ROLE analyst_role TO ROLE senior_analyst_role; 后，senior_analyst_role 继承 analyst_role 的所有对象权限。第二是对象层级继承：对数据库授予 USAGE 并不会自动授予其中模式的 USAGE，对象权限不会沿数据库→模式→表自动向下传递，必须逐层显式授予。这一点与角色继承方向相反，是初学者最容易混淆的地方。

此外，对象所有权本身也是一种特殊权限。对象所有者拥有该对象的全部权限，并可将其授予其他角色。若角色拥有某个模式的所有权，它对该模式内对象拥有管理能力，但并不意味着自动拥有对所有子对象的 SELECT 等操作权限，仍需显式授予或通过所有权管理。

实践中的授权顺序与检查方法

设计一个可维护的授权流程，建议按以下顺序执行。第一步，创建角色并规划角色层级，例如建立 analyst_role 作为基础角色，senior_analyst_role 继承它。第二步，对数据库和模式授予 USAGE，确保角色能“看到”对象路径。第三步，对具体表、视图、函数授予操作权限。第四步，对模式设置 Future Grants，覆盖后续新增对象。第五步，使用 SHOW GRANTS TO ROLE analyst_role; 检查该角色最终拥有的权限集合，使用 SHOW GRANTS ON TABLE sales.public.orders; 检查某对象被哪些角色持有权限。

当查询报错“Object does not exist or not authorized”时，通常不是对象不存在，而是缺少某一层 USAGE 或对象操作权限。排查顺序应为：确认角色是否被激活、确认数据库 USAGE、确认模式 USAGE、确认对象权限、确认 Future Grants 是否覆盖该对象。通过 SHOW GRANTS 系列命令可以快速定位缺失环节。

总结来看，Snowflake 对象权限模型的关键在于三点：对象权限必须逐层显式授予，角色继承可以简化权限复用，Future Grants 解决新增对象的自动化授权。掌握这三条规则，就能在复杂的数据环境中构建清晰、可审计、易维护的权限体系。