### RBAC0：最基础的权限骨架 说起RBAC，得从它的核心骨架讲起。NIST在2004年发布的那套标准里，定义了四个层级的RBAC模型：从0到3，逐级叠加能力。本章我们先啃最基础的——RBAC0。 RBAC0是所有权限系统的起点。说白了，它就是一套“用户-角色-权限”的三层映射关系。我们接下来把它拆开，看看每层到底在做什么。 #### 三大核心组成 我个人习惯用一个简单的三段论来理解RBAC0： - **用户（User）**：系统的访问主体。可能是人，也可能是程序。 - **角色（Role）**：一个抽象的权限集合。它代表的是一种职责或职能，而不是具体某个人。 - **权限（Permission）**：对某个资源的访问许可。在密钥管理场景里，可能是“生成密钥”、“查看密钥状态”、“导出密钥”这类原子操作。 这三者之间只能通过“角色”这座桥来连接。为什么这么设计？ #### 两个核心映射才是关键 你想想看，传统的访问控制模型，比如DAC或MAC，都是把权限直接挂到用户头上。那时候管理起来特别痛苦——员工离职或调岗，你得到处改权限，改到怀疑人生。 RBAC0的思路巧妙在哪呢？它把问题拆成了两个映射： 1. **用户-角色分配（User-Role Assignment）**：给用户分配角色。 2. **角色-权限分配（Role-Permission Assignment）**：给角色分配权限。 **这样做的好处**：用户和权限之间不再直接耦合。当员工调岗时，你只需要把他从一个角色挪到另一个角色，他之前那个角色的所有权限就会自动消失——完全不用逐个检查之前的权限列表。我在项目里体验过这个好处，真的太省心了。 #### 表结构的设计 从数据库层面看，实现RBAC0通常需要这几张表。我列个表，方便你对照理解： | 表名 | 核心字段 | 作用 | | --- | --- | --- | | `user` | user_id, username, ... | 存储用户基本信息 | | `role` | role_id, role_name, description | 定义所有角色 | | `permission` | perm_id, perm_code, perm_desc | 定义权限原子项 | | `user_role` | user_id, role_id | 建立用户与角色的多对多关系 | | `role_permission` | role_id, perm_id | 建立角色与权限的多对多关系 | 表中没有“用户-权限”这个直接映射。这就是RBAC0的精髓。 #### 会话（Session）的概念 RBAC0还引入了一个容易被忽略的概念——**会话**。 会话是用户的一次活跃连接。用户登录后，系统会创建一个会话，并激活该用户在本次会话中的角色子集。用户可能有多个角色，但一次会话只激活其中一部分。 举个例子： - 小张在密钥管理系统里有“管理员”和“审计员”两个角色。 - 他处理日常工作时，激活“审计员”角色，只能查看日志，不能修改密钥。 - 他需要进行密钥分发任务时，再激活“管理员”角色获取操作权限。 这个设计实际上实现了**最小权限原则**——用户永远只持有当前任务需要的权限。 #### 我在项目中踩过的坑 讲个真实案例。曾经有一个金融项目，我直接按业务部门名称设计了角色，比如“信贷部角色”、“结算部角色”。上线后问题就来了——一个员工在信贷部和结算部都挂着，他的权限交叉重叠，审计时根本说不清楚这个人的权限来源。 后来我悟了：角色的命名应该反映的是**能力**，而不是**部门**。比如“密钥生成员”、“密钥审批员”、“密钥审计员”。这样即使一个员工属于两个部门，他的权限边界也很清晰。 #### RBAC0的约束 RBAC0本身不强制任何约束，比如一个用户能不能有多个角色？可以。一个角色能不能有多个父角色？不行，那是RBAC1的层级模型。所以RBAC0被称为“基本模型”是有原因的——它只规定了最基础的要素，把复杂性留给了后面的层级。 #### 一张图看清RBAC0 理解了吗？这个架构的核心就是把“谁有什么权限”这个问题转化为“谁是什么角色，这个角色有什么权限”，解耦了用户与权限的直接绑定。 #### 实战总结 总结一下，构建RBAC0权限系统时，我建议你记住三条原则： 1. **角色要抽象**。别把角色设计成具体的人名或工号，要设计成职责集合。 2. **权限要细粒度**。比如“查看密钥”和“导出密钥”应该分开，而不是写成一个“密钥管理”。 3. **会话管理别忽略**。多角色用户的会话激活机制是实现最小权限的关键。 RBAC0虽然是最基础的模型，但90%的企业级系统用它就够了。我在多个密钥管理项目里都用这套模型，几乎没有遇到无法覆盖的场景。下一层我们再看RBAC1怎么加层级概念——那是更深的话题了。