4、RBAC模型详解：RBAC0、RBAC1、RBAC2、RBAC3核心概念及关系

聊到权限管理，RBAC（基于角色的访问控制）几乎是绕不开的基石。我刚开始做密钥管理系统时，还没意识到角色这层抽象有多重要，结果就是权限表越写越乱，用户一多就崩。后来啃完这套模型，才算是把权限体系捋清楚了。

说白了，RBAC 就是「用户 → 角色 → 权限」这个链条。角色是中间的桥梁，用户不直接拥有权限，而是通过扮演角色来获得。好处很明显——你想想看，一个公司上百人，每人都要单独分配权限，累死你。但有了角色，你只需要定义「管理员」「审计员」「操作员」这几个模板，把用户往里一塞，完事。

这套模型分四个级别：RBAC0、RBAC1、RBAC2、RBAC3。下面我一个个讲，顺便聊点实战里踩过的坑。

RBAC0：最基础的核心模型

RBAC0 是地基，所有其他模型都从它衍生。它定义了四个核心元素：用户、角色、权限、会话。关系很简单——用户登录后激活一个会话，会话里关联若干角色，角色再映射权限。

在工作中，我大部分系统其实只需要 RBAC0 就够了。比如一个内部密钥管理工具，角色就三类：超级管理员（能创建/吊销密钥）、运维角色（只能查看密钥状态）、普通用户（只能申请使用）。别小看这个，很多初创公司连这个都没做对。

元素	含义	在密钥管理中的例子
用户	系统操作者	张三（审核员）
角色	权限的集合	密钥审核员
权限	对资源的操作许可	查看密钥、签署证书
会话	用户活动的上下文	登录后的操作环境

我记得有一次，客户说「为什么我改了某个角色的权限，但用户还是用旧权限做事？」。原因很简单——会话没刷新。用户登录时已经把角色权限快照到会话里了，你改角色定义，但不强制用户重新登录，那权限根本不会变。嗯，这个坑我踩过。

RBAC1：引入角色继承

RBAC1 在 RBAC0 基础上加了「角色层级」。说白了，高级角色自动拥有低级角色的所有权限。比如「项目经理」继承「开发组长」的权限，「开发组长」又继承「开发人员」的权限。你只要给项目经理分配额外的那部分权限就行，不用重复配置。

在密钥分配场景里，这个继承特别有用。比如：

• 超级管理员：继承所有下级角色权限
• 安全审计员：继承「查看密钥日志」权限，外加「导出审计报告」
• 密钥操作员：仅执行日常密钥轮换

RBAC2：加入约束机制

RBAC2 在 RBAC0 基础上加了「约束条件」。这玩意儿在密钥权限分配里太关键了。约束分几种：

1. 互斥角色：一个用户不能同时拥有两个互斥的角色。比如不能同时当「密钥签发员」和「密钥审计员」，否则安全审计就形同虚设。
2. 基数约束：限制某个角色最多能有多少用户。比如「超级管理员」不得超过 3 人，防止权限过于分散。
3. 先决条件角色：用户必须先拥有角色 A，才能申请角色 B。比如必须有「运维」角色才能申请「根密钥管理」角色。

约束类型	说明	密钥管理案例
互斥角色	用户仅能拥有一个角色	不能同时是「密钥管理员」和「安全审计员」
基数约束	角色有成员数量上限	「HashiCorp Vault 管理员」最多 5 人
先决条件	必须先有角色 A	需先有「查看密钥」角色，才能申请「签名密钥」

RBAC3：大融合

RBAC3 就是把 RBAC1 的层级和 RBAC2 的约束合在一起。这基本是现代成熟权限系统的标配，比如 AWS IAM、Kubernetes RBAC 都算 RBAC3 的实现（虽然不是完全照搬）。

在 RBAC3 下，你既有继承带来的便捷，又有约束带来的安全。我建议，如果是企业级的密钥管理系统，或者你的系统要过等保认证，直接上 RBAC3 省心，不用后面再补。

实际选型建议

别一上来就想着 RBAC3，过度设计是大忌。我是这么分的：

• 团队 < 20 人、权限简单：RBAC0 足矣
• 业务有层级管理，比如区域经理→总部：加 RBAC1
• 要过安全审计、数据敏感：加 RBAC2 的互斥约束
• 大型企业、多租户、合规要求高：上 RBAC3