基于角色的访问控制（RBAC）：核心要素与标准模型

聊完了基础概念，咱们进入今天的正题——RBAC。说实话，我在各种企业级系统里跟它打了十多年交道，这玩意儿看起来简单，但坑可不少。

RBAC，全称 Role-Based Access Control，中文叫「基于角色的访问控制」。它的核心思想就一句话：把权限打包成角色，再把角色分配给用户。你想想看，在一个几千人的公司里，如果给每个人单独配权限，那简直是噩梦。有了角色，一切就理顺了。

我记得第一次做权限重构的时候，系统里直接给用户挂权限的代码写得满天飞。后来我花了三个月，硬生生把这些零散的权限映射到角色上。改完以后，审计通过率直接翻倍。这就是RBAC的价值。

4.1 RBAC 的四个核心要素

要搞懂RBAC，先记住四个词：用户、角色、权限、会话。缺一不可。

要素	含义	我的一句话理解
用户 (User)	系统的操作主体，可以是人、程序或设备	谁在操作
角色 (Role)	权限的集合，代表着一种职责或岗位	他是什么身份
权限 (Permission)	对某个对象执行某种操作的许可	他能做什么
会话 (Session)	用户激活角色的过程，控制权限生效范围	他在什么场景下做

这里有个关键点——用户和角色是多对多的。一个人可以身兼数职，比如既是开发又是项目组长。同样，一个角色也可以包含多个用户。

4.1.1 用户（User）

用户就是系统中的账号，每个人有唯一的标识。我建议在审计时，一定注意用户的生命周期管理。很多权限漏洞都是因为离职用户的账号没及时回收造成的。

4.1.2 角色（Role）

角色的设计是整个RBAC的命脉。你在设计角色时，脑子里应该有清晰的职责边界。比如「销售经理」和「销售总监」，虽然名字像，但权限集合完全不同。我在项目中习惯先把业务流程画出来，再对着流程拆角色，这样不容易漏。

4.1.3 权限（Permission）

权限是原子级的操作许可。它通常由两部分组成：操作和对象。比如「创建订单」，操作是「创建」，对象是「订单资源」。我把权限比作积木块，角色就是拼好的模型。

4.1.4 会话（Session）

会话这个要素很多人会忽略。它控制着用户在当前登录周期内激活了哪些角色。比如一个用户既是管理员又是审计员，但在做日常操作时，他只激活「审计员」角色，就不会误操作管理功能。嗯，这里要注意——会话的审计很重要，你得记录用户在什么时间激活了哪个角色。

4.2 RBAC 的三种标准模型

搞清楚了核心要素，咱们来看看业界公认的三种标准模型。我把它们理解成三个版本，从简到繁，你按需选择。

为什么会是三种？说白了，不同规模的公司、不同的安全等级需要不同力度的控制。我见过小创业公司直接用Core RBAC就够用，而金融系统必须上到Constrained RBAC。

模型名称	英文简称	核心特点	适用场景
核心RBAC	Core RBAC	用户-角色-权限的基础映射	小型系统、内部工具
层级RBAC	Hierarchical RBAC	角色可以继承，支持上下级关系	中大型企业、有组织架构的系统
约束RBAC	Constrained RBAC	引入职责分离、互斥角色等约束	金融、医疗等合规要求高的场景

4.2.1 Core RBAC（核心RBAC）

这是最基础的版本。它定义了四个要素，以及用户与角色、角色与权限之间的一对多和多对多关系。说白了，就是最原始的角色盒子。

举个栗子：系统里有个「文章编辑」角色，它拥有「增删改」文章的权限。用户A被分配了这个角色，他就能操作文章。简单明了。但Core RBAC有个缺陷——不支持角色继承。如果来了个「资深编辑」，它的权限必须重新创建，不能复用「文章编辑」的角色。

4.2.2 Hierarchical RBAC（层级RBAC）

这个模型加入了角色继承机制。子角色自动拥有父角色的所有权限。比如「项目经理」继承了「开发人员」的所有权限，同时额外拥有「审批功能」的权限。

层级关系可以分成两种：通用层级和有限层级。前者允许角色间任意继承，后者限制继承范围。我个人偏向有限层级，因为无限继承容易出乱子。我在项目中曾见过角色继承链长达7层，排查权限归属时，头都大了。

层级RBAC的好处是复用性强，管理成本低。缺点是如果层级设计得不好，会形成循环依赖或者权限膨胀。所以建议你在设计时就画好角色树状图。

4.2.3 Constrained RBAC（约束RBAC）

这是RBAC的终极形态，也是合规审计最关注的模型。它在上一种模型的基础上，增加了约束条件。最常见的两种约束是：

• 静态职责分离（SSD）：一个用户不能同时拥有两个互斥的角色。比如不能同时拥有「采购员」和「验收员」角色，防止自己买自己验。
• 动态职责分离（DSD）：在同一个会话中，不能同时激活两个互斥的角色。可以在不同会话中激活，但同一会话不行。

你想想看，在银行系统里，一个柜员不能同时是审核员。这就是Constrained RBAC的典型应用。我在做金融系统的审计时，如果发现没有约束RBAC，基本可以判定为不合格。

4.3 核心逻辑关系图

为了帮你从整体上把握这三个模型之间的关系，我画了一张图。你可以把它当成知识地图来看。

4.4 最佳实践与个人提醒

讲了这么多，最后分享几个我这些年总结的经验：

• 角色粒度要适中。太粗了，权限控制形同虚设；太细了，管理成本爆炸。一般建议按部门职责粒度来划分，每个角色对应一个具体的岗位。
• 权限最小化原则。给角色的权限只给够用的，不多给一分。我在审计时发现，很多权限泄漏问题都是因为角色权限范围被悄悄扩大了。
• 定期进行角色清理。你想想看，公司组织结构在变，角色也该跟着迭代。我每半年会做一次角色审计，看看哪些角色三个月内没人用过，直接标记为过期。
• 严格使用Constrained RBAC。特别是涉及钱、数据、核心业务的系统，必须上SSD和DSD。别嫌麻烦，这是底线。