1. 传统权限模型的困境
在单体系统时代,权限逻辑往往是硬编码或简单的静态映射。
1.1 过去的简单模型
早期的系统通常是单组织、单租户、静态角色。开发者习惯于:
- 硬编码判断 :
if (role == "admin") - 属性判断 :
if (user.department == "finance")
1.2 现代系统的复杂度爆炸
随着 SaaS 和协作工具的兴起,系统特征发生了剧变:
- 多维度协同:多组织、多租户、实时文档共享、社交关系。
- AI Agent 介入:不仅是人,代理对象也需要复杂的授权。
- 动态性 :权限不再是管理员手动分配的一项技能,而是一种推导结果。
2. 什么是"推导类权限"?
权限根据关系链实时计算出来的结果。
2.1 典型的推导逻辑
- 用户属于某个 团队
- 团队属于某个 部门
- 部门拥有某个 项目
- 项目包含某份 文档
- 结论:用户自动拥有该文档的编辑权限。
2.2 逻辑模型的转变
- 传统模型 :
User -> Role -> Permission(线性映射) - 现代模型 :
Object -> Relation -> Object(递归路径)
3. 为什么传统 KV 存储不再适用?
虽然 Key-Value 数据库(如 Redis)或关系型数据库(如 MySQL)在简单读取上表现优异,但在处理推导类权限时面临瓶颈。
| 特性 | KV / 关系型数据库 | 图关系/权限推导系统 |
|---|---|---|
| 核心优势 | 高速读取、简单映射 | 深度递归、路径搜索 |
| 层级处理 | 难以处理无限层级嵌套 | 天生支持递归与继承 |
| 一致性 | 难以保证全局细粒度一致性 | 支持 Zookie 等时间戳一致性机制 |
| 性能 | N 层关联查询(Join)导致性能崩溃 | 优化后的图遍历算法 |
4. Google Zanzibar:全球统一授权基础设施
为了解决 Google Drive、YouTube、Gmail 等海量资源的权限协作问题,Google 研发了 Zanzibar。
4.1 系统定义
Zanzibar 是一个全球一致的、可扩展的授权系统。它不再仅仅是一个代码模块,而是一套完整的基础设施。
4.2 权限"关系化" (ReBAC)
Zanzibar 引入了 Relationship-Based Access Control (ReBAC) 的概念。
- 它不关心你的 Role 名字叫什么。
- 它只关心 "关系是否成立" 。
示例语法:
Plaintext
csharp
// 表示:Alice 与 doc1 之间存在"查看者"关系
user:alice is viewer of document:doc1
// 表示:工程组的成员包含 Bob
group:eng#member@user:bob
5. 权限系统的本质:图计算
在 Zanzibar 体系下,整个公司的权限体系被抽象成一张巨大的 Graph(图) 。
5.1 权限检查即图遍历
当系统询问:Can Alice access documentX?
底层引擎执行的操作是:是否存在一条从 Alice 指向 documentX 的有效路径?
5.2 链路示意
代码段
scss
graph LR
Alice((Alice)) --> Engineering(工程组)
Engineering --> Google(组织)
Google --> ProjectA(项目A)
ProjectA --> DocumentX[文档X]
style DocumentX fill:#f96,stroke:#333
6. Zanzibar 的影响
Zanzibar 的论文发布后,彻底改变了权限系统的设计范式,催生了一批现代权限引擎(Zanzibar 系):
-
SpiceDB / Authzed : 生产环境高性能实现。 作者自建的spiceDB 中文站 zzzplus.cloud/zh/
-
OpenFGA: 由 Okta 发起的开源项目,强调易用性。
-
Permit.io / Keto: 侧重于云原生与开发者体验。
7. AI 时代为什么会进一步放大 Zanzibar 的价值?
AI Agent 的出现,
实际上会进一步加剧权限系统的复杂度。 因为未来系统里的"主体"已经不再只有:
- User
- Group
- Service
还会出现:
- AI Agent
- Workflow
- Tool
- MCP Server
- Task
例如:
css
Agent A 是否可以访问某个知识库?
背后可能需要推导:
rust
Agent
-> User
-> Workspace
-> Project
-> Document
也就是说: AI 正在把权限系统彻底推向"动态关系计算"