场景

企业后台拥有系统、菜单、接口和数据多种权限，只给用户挂角色很快会遇到临时授权、跨部门数据范围和审批追踪问题。

原理

RBAC 通过用户、角色、权限降低管理规模，ABAC 再根据主体、资源与环境属性做动态决策。权限系统应把权限定义、分配关系、策略计算和审计分开，业务系统负责提供资源上下文并执行决定。

设计步骤

先枚举资源与动作并使用稳定权限码；设计用户—角色—权限关系和数据范围；区分默认角色与自定义角色；增加申请、审批、生效、到期、回收流程；决策接口默认拒绝，变更写审计日志并支持影响分析。

权衡

权限粒度粗易维护但容易过度授权，粒度细更安全却产生角色爆炸。集中决策一致性高，但增加网络依赖；本地缓存性能好，却存在策略更新延迟。ABAC 灵活，却比 RBAC 更难解释和排查。

实践建议

权限码不要绑定菜单名称，前端隐藏按钮也不能代替后端检查。高风险权限设置期限和复核；缓存携带策略版本并支持主动失效；管理员同样受权限治理。上线前用权限矩阵验证正向与反向场景，并定期清理孤儿角色。

落地检查

上线前还应做一次桌面演练：准备正常、边界、超时、重复与恶意输入，确认系统的返回、日志和指标彼此对应；在预发布环境模拟依赖不可用、进程重启和配置回滚，验证降级路径不会放大故障。上线时采用小流量观察，提前定义停止条件与负责人。稳定后复盘真实数据，删除没有收益的复杂度，并把新发现的约束补进测试、监控和设计记录，使方案能够随业务持续演进，而不是停留在一次性评审结论。