RBAC 和 ABAC 有什么区别？权限系统怎么避免角色越建越多？

知识点详解：角色负责能力，属性负责条件

从角色爆炸的例子看边界

假设系统有编辑和审核两种职责，同时要求只能操作本部门记录。如果把部门直接并入角色，就会出现财务编辑、财务审核、销售编辑、销售审核等组合。

再加上地区、记录级别和临时有效期，角色数量会继续增长。真正的问题不是 RBAC 不能授权，而是我们把许多独立条件都塞进了角色名称。

可以保留编辑、审核这样的能力角色，再用资源部门与用户部门的关系限制范围。命名少了并不是最终目标，重要的是规则能独立解释和维护。

RBAC 管关系，ABAC 作规则判断

RBAC 关心谁被分配了什么角色，角色具有哪些权限；还可以有角色继承与职责分离等设计。它并不是只有一个管理员和一个普通用户。

ABAC 把一次授权需要的数据交给规则。例如主体是哪个部门的用户，资源属于谁，请求要读还是改，当前是否满足时间或设备条件。规则据此给出决定。

属性不只来自用户表。资源状态、授权关系和受信的环境信息也可能参与。不能让客户端提交一句「我是管理员」「记录属于我」，后端就直接当作可信属性。

组合以后，服务端怎样真正执行

假设某个用户有审核角色。角色提供审核能力，但服务端仍需读取目标记录，核对部门、状态与当前规则，然后决定是否执行。

前端隐藏按钮只是体验处理，不能代替服务端授权。列表查询也应按允许范围过滤，详情、修改和批量接口分别验证，避免「列表看不到，但猜 ID 能读到」。

如果检查与写入之间资源状态发生变化，还要通过事务、条件更新等方式保持约束。授权检查通过，不意味着后续任何时刻条件都继续成立。

灵活规则需要可解释与可测试

先定义默认拒绝、缺失属性怎样处理，以及多个规则冲突时的决策方式。不同策略系统可能有不同合并规则，不能随意假设「允许总能覆盖拒绝」。

规则变化后，要测哪些原本允许的操作被拒绝、哪些新增允许可能越权。可以准备主体、资源、操作、环境的测试矩阵，覆盖跨部门、过期、状态变化和批量部分授权。

审计记录应说明使用了哪个策略版本、关键属性与结果，同时避免把敏感数据完整抄进日志。权限缓存还要考虑撤权多久生效，不能永远沿用登录时的一份角色快照。

本题机制参考：NIST RBAC、NIST SP 800-162。

面试官继续追问

ABAC 一定比 RBAC 更好吗？

不是。条件少、职责稳定时，RBAC 更容易理解和运维；复杂条件才值得引入更精细规则，且可以组合。

有审核角色能审核自己提交的记录吗？

要看职责分离规则。角色只说明能力分组，是否允许自审还要明确建模，不能靠角色名称自动推断。

属性缺失时允许还是拒绝？

安全敏感操作应明确采取保守策略，并区分拒绝与系统无法判断。不要把 undefined 或数据读取失败默认为通过。

面试速记卡

• RBAC：用户—角色—权限，组织稳定能力。
• ABAC：主体、资源、操作、环境属性参与规则。
• 角色与条件可以组合，避免组合式角色爆炸。
• 服务端授权，可信属性，明确冲突和缺失规则。
• 撤权、并发变化和批量接口都要测试。