权限管理系统设计的顺序，小团队先定这3张核心表

接手过一个后台，142 个角色，运维自己都说不清谁能改价，改错一次赔了八千。

问题不在开发，在顺序。权限管理系统设计如果先做角色，最后一定会长成一张没人敢动的网。这篇把我用过的顺序讲一遍。

权限管理系统设计怎么做，先定三张表

先把表定下来，再谈界面。第一张是用户表，只放身份信息，比如工号、部门、在职状态；第二张是角色表，只放一组动作的集合，比如"可以改价，不能删单"；第三张是资源表，也就是被操作的对象，比如订单、商品、优惠券。

三张表之间用两张关联表串起来：用户与角色是多对多，角色与资源也是多对多。这样做的直接好处是：加一个人，只改关联表；加一个功能，只改资源表。我做过的一个项目，加功能权限平均只要 10 分钟。

最常见的错法是把权限直接挂在人身上。谁的账号要什么就勾什么，一开始很快，20 个人以内还撑得住，到 50 个人就开始出现"这个人到底为什么能看财务报表"这种没人答得上来的问题。权限挂在人身上，人一多就没人管得住。

三张表的字段不用多，但有几项必须有：用户表要有在职状态和最后登录时间；角色表要有创建人、生效范围、是否可继承；资源表要有父级编号，方便按模块批量授权。这 8 项凑成一张字段检查表，建表时对着过一遍就行。

这里补一句，同一主题我在另一篇里拆得更细，西门子plm那篇可以一并看。

角色怎么分，按动作不按岗位

岗位是会变的，动作相对稳定。所以我不按"运营专员""运营主管"去切角色，而是先列出所有动作，再按动作组合成角色。一个电商后台，动作大概 12 个，分成 6 到 8 个角色就够用。

具体做法是拉一张动作清单，把每个动作标上三档风险：能不能改数据、能不能导出、能不能删除。改价、退款、改库存属于高风险；查看、筛选、导出属于中风险；只是浏览列表属于低风险。高风险动作单独成组，一组成员原则上不超过 5 个人。

角色按岗位划，组织一调整就得整组重做一遍。我见过一次部门合并，因为角色和岗位绑得太死，前后返工了 3 周。

还有一个细节：角色不要做继承。A 继承 B 再继承 C，看起来很省事，出问题的时候根本追不回来是哪一层带进来的。宁可有 8 个平铺的角色，也不要 3 层继承。

角色的命名也值得花 10 分钟。我的习惯是"模块加动作加范围"，比如"订单-改价-全量""订单-查看-本部门"。名字里带范围，后面查权限的时候一眼就能看出越权在哪。反过来，如果角色名都是"运营 A""运营 B"，半年之后连创建人都说不清它们的差别。

角色数量失控通常是三个原因叠加：每来一个特殊需求就新建一个角色、离职人员的角色不清理、临时权限没设到期时间。第三条最容易忽略，建议所有临时授权都带一个到期日，默认 30 天，到期自动收回。

多说一句，同一主题我在另一篇里拆得更细，竞调那篇可以一并看。

数据权限单独一层，别混进角色

功能权限管"能不能点这个按钮"，数据权限管"点了之后能看到谁的数据"。这两件事必须分开，混在一起就会出现"能看订单但能看到全部人的订单"这种漏洞。

数据权限一般分三档：看全部、看本部门、只看本人。落地时不要逐个用户配，而是绑定在组织架构上，人调岗后权限自动跟着走。这一层的开发量比功能权限大，我经手的项目里大约占 4 成工时。

越权是这层最容易出的问题。典型场景是接口只校验了登录状态，没校验数据归属，改一下 URL 里的订单号就能看到别人的单子。做数据权限时，建议把所有带编号的查询接口列出来，逐个过一遍归属校验。

组织架构那一层也要接上。人是会调岗的，如果把数据权限直接配在账号上，人一动就得手工改。把权限绑在部门编号上，调岗只需要改一次组织关系，权限跟着走。我经手的项目里，这一条能省掉后期 7 成以上的手工维护。

还有一类隐蔽的越权来自导出。列表页做了归属校验，导出接口忘了做，一次导出就把全公司的数据带走了。凡是能导出的地方，都要单独过一遍校验，这一点在验收清单里最好单独列一行。

权限设计怎么做才不越权，靠审计日志兜底

再细的设计也会有漏网。兜底手段是审计日志，记四件事：谁、在什么时间、对哪条数据、做了什么动作。这四列缺一列，日志的价值就大打折扣。

日志有两条硬要求：一是不可篡改，普通管理员不能删；二是可检索，能按人和按数据两个方向查。这两条做到，事后追责通常 10 分钟内就能定位。没有审计日志的权限系统，出事以后只能靠猜。

合规上也有依据。依据 GB/T 37988—2019 对数据安全能力的分级要求，访问控制要能证明"授权是最小的、可追溯的"。建议你把权限矩阵导出成一张对照表，每季度核对一次，离岗人员当场销权。

复核节奏建议定成两条：每季度做一次全量对照，离职当天做一次单点核查。全量对照花不了两个小时，但能挡住绝大多数积累问题。我见过一个团队坚持做了两年，权限异常从每季度十几条降到一两条。

权限管理系统设计这件事，说到底不是技术活，是排序活。先把三张表定下来，再拆动作、分数据、留日志，顺序对了，后面加人加功能都不会乱。

建议你先做一件事：把现在后台的角色列表导出，数一数超过 20 个的部分有几个是真正在用的。我赌你会砍掉一半。

离岗销权也别忘了。你可以设一个规则：员工离职当天由 HR 在系统里改状态，权限自动冻结；这一步做进流程，比事后翻日志找人靠谱得多。

相关内容推荐

多国语言包：讲语言包从抽取到上线的工程动作，配"上线前检查表"交付物

漏斗分析：转化流失定位与优化方法

相关问答FAQs

Q：权限管理系统设计是什么

A：就是把"谁能对什么做什么"这件事，拆成用户、角色、资源三张表和两层权限（功能权限、数据权限），再配一套审计日志兜底。核心目标是让每次授权都能说清理由。

Q：一套权限系统做下来要多少钱

A：按外包报价算，基础的三表模型加日志大约 3 万到 8 万元；如果要做数据权限分级和单点登录，通常在 10 万到 20 万元之间，差别主要在校验点的数量和已有系统的接入难度。

Q：RBAC 是什么，和权限设计什么关系

A：RBAC 是基于角色的访问控制，说的是"用户通过角色拿权限"这一套模型。它是目前最通用的做法，但不管数据权限，所以还得单独补一层。

Q：权限做太细会不会影响效率

A：会。高频低风险的动作不该拦，比如查看列表、导出日报。把拦截只放在高风险的 4 到 6 个动作上，用户基本不会抱怨。

参考文献

[1] 苏杰.人人都是产品经理[M].北京:电子工业出版社,2014.

[2] 国家标准化管理委员会.信息安全技术 数据安全能力成熟度模型:GB/T 37988—2019[S].北京:中国标准出版社,2019.

[3] 中国信息通信研究院.数据安全治理实践指南[R].北京:中国信息通信研究院,2023.