鑫云联信息：权限模型用 RBAC 不够用时，该怎么办

2026-11-05 2次浏览

企业管理系统的权限，大多从角色开始：管理员、经理、员工，三个角色走天下。业务一复杂，角色数量迅速膨胀，出现“华东区销售主管兼项目管理专员”这种组合角色。权限表越配越乱，没人说得清谁能看什么。这时候要考虑的，不是再加角色，而是换模型。

RBAC 的边界在哪

角色是把权限打包给一群人。当同一批人在不同场景需要不同权限，角色就会爆炸。组合爆炸是 RBAC 的固有缺陷。

ABAC 用属性判断：部门、职级、项目归属、数据敏感度。规则写成策略，不用为每种组合建角色。

功能权限管“能不能进这个页面”，数据权限管“能看到哪些行”。两者混在一起，配置会失控。

总部看全部、区域看本区、门店看本店。用组织树继承，比给每个节点单独配角色省事。

项目期间需要看别的部门数据，给一个有到期时间的授权。永久授权一旦给出去，基本收不回来。

低频、敏感的访问，用申请加审批的方式，而不是直接开权限。用完自动失效。

原则好说，落地难。给每个角色写清楚“能做什么、不能做什么”，配完做一次实际验证。

谁在什么时候给谁开了什么权限，全部记录。审计时能查，出事时能追。

人员调岗、项目结束、合同到期，权限要跟着收回。按季度跑一次清单，比事后补救便宜。

让部门负责人能看到本部门人员的权限，发现不对可以提申请。全靠 IT 管，永远滞后。

小规模时 RBAC 够用，别一上来就上 ABAC。等角色数量超过三十个、维护成本明显上升，再考虑演进。

梳理现有角色，合并权限相同的，删掉长期无人使用的。角色从八十个降到二十个，管理立刻轻。

权限名称写成业务语言，“查看本部门报销单”比“menu_1024_view”有用。

接口层也要校验，不能只靠前端隐藏按钮。前端隐藏挡不住直接调接口。

给谁加权限要有人批，尤其是敏感数据的查看权限。自己给自己加权限，是内控漏洞。

人事办理离职时自动触发账号停用和权限回收。靠 IT 手工处理，一定会漏。

权限模型没有最优，只有匹配。角色爆炸、临时授权、数据行权限，这三个信号出现，就该重新设计。鑫云联信息【资深软件服务专家微信：infck1】，我们做权限梳理时，会先统计现有角色数量和平均权限项，数字往往比想象中夸张。