B端权限治理实战：从角色乱象到分层自治，五步落地路径

guozi

接手一个历史包袱沉重的B端平台，权限系统混乱、角色泛滥、审批形同虚设，如何从废墟中重建？本文从实战出发，提出一套从“平铺”到“分层”的权限治理思路，涵盖角色设计、审批流程与清理机制，并给出五步落地路径，帮你系统性地解决权限乱象。



上一篇讲了权限管理的基本概念和角色设计的方法论。有小伙伴看完可能会问：概念我都懂，可我接手的是一个”陈年老应用”——历史包袱重、角色几百个、各子应用各建各的、清理从来没做过。这时候不是从 0 到 1 做设计，而是要在一片废墟上重建。该怎么办？

本篇就聊这个话题。我从最近一段治理平台级权限的实战经验出发，抽出一套可复用的思路。为了方便讨论，我们假想一个常见场景：

你负责一个平台级的 B 端产品，下面挂了几十个甚至上百个子应用，业务复杂，用了很多年。原有的权限系统是很久以前搭起来的，功能早就不迭代了。角色是随需而建的，从来没有清理过。用户抱怨申请麻烦，审批人盲批走过场，异动员工的权限没人回收……问题堆积到某一天，你终于被推上”权限治理”这个专项。

如果你手上正好有这样一摊事，希望这篇文章能帮到你。
一、老旧权限系统的常见问题
治理前先要诊断。以我经验，平台级权限体系最常见的问题有以下四种。你可以对照看看，自己的系统中了几种。

问题一：角色扁平，跨应用组合不起来。角色层级只有一层，都定义在单个应用内部。用户在 A 应用申请几个，在 B 应用又申请几个，脑门上顶着一堆角色才能干活。根因是缺少”平台-应用”的角色分层。

问题二：面向功能/数据行列权限建角色，而不是面向场景。新增一个功能顺手建一个”XX 功能角色”，久而久之角色就变成了一堆权限打包工具，跟真实业务岗位对不上。用户看角色名一头雾水，不知道自己该申请哪个。

问题三：只进不出，权限沉积。只有”申请-审批”，没有”复核-清理”。员工换岗后权限从不回收，几年下来沉淀出一大批僵尸权限，成了数据安全的隐患。

问题四：审批形同虚设。审批人对角色的功能范围不了解，或者角色描述太模糊，看到申请就同意。审批链路本来是权限的第二道防线，实际却是走过场。

带着权限问题，我们看治理思路。
二、治理思路：从”平铺”到”分层”
接下来我们按照权限管理绕不开的三个环节——角色设计（权限模型）、申请审批（准入标准）、清理机制（准出流程）依次展开描述。

2.1 角色设计与分层管理

老系统的通病是权限管理高度集中，完全由平台方统一维护。后果是：用户完成一个跨应用的完整业务场景，往往需要反复申请多个角色；平台方成为唯一维护入口，响应慢，子应用想调整权限反而无自主权。

治理思路是：将权限拆分为两层，按管理边界各司其职。

1）业务域层：跨应用编排

按业务领域将子应用分组，每个业务域设一名业务域管理员，承担两项职责：

• 域内跨应用的门户配置，决定用户进入该域后能看到哪些应用入口；
• 角色组编排，将不同应用的角色打包成一个角色组，对应一个完整业务场景，一次性授予用户。


这一层解决的是跨应用权限没人拉通的问题。

2）应用层：应用内自治

每个子应用独立维护自身的角色定义、权限点和审批链路。由子应用产研团队自行负责，不再依赖平台方代为挂载权限。

但自治不等于放任。应用内角色的设计要面向业务使用对象，而不是按功能菜单或数据范围逐一拆解——否则一个应用内的角色数量同样会膨胀失控。

分层之后：

• 业务域管理员负责跨应用的组合编排，子应用产研负责本应用内的功能权限管控，两层职责不重叠。
• 平台方不再作为唯一维护入口，各域各应用自主运转。
• 用户按业务场景一次性获得跨应用权限组合，不再逐个申请单一角色。


业务域管编排，应用管细节。



2.2 申请审批流程设计

角色设计好了，接下来看用户怎么用。老系统在申请审批这个环节，通常有三个典型问题：

• 用户不知道自己该申请什么。角色名晦涩、职责描述含糊，只能靠问同事或者试着乱申。
• 申请路径长。为了完成一个跨应用的业务场景，用户要在几个应用之间来回跳，反复填申请。
• 审批人盲批。审批人对具体角色的功能范围不了解，看到就点通过。


治理这三个问题，需要在申请侧和审批侧各下功夫。

1）申请侧：让申请像”点单”

前面第一步提到的角色组，就是申请侧最核心的抓手——用户按业务场景一次申请，直接获得完整权限。

用一个前后对比图看一下：



除了角色组，还有几个辅助手段能进一步降低申请成本：

• 自动授权规则通过写岗位/部门鉴权规则，命中该条件的员工一入职就自动获得基础可见权限，比如门户首页、公告、通用查询、其业务线的基础权限等，避免”登录进去一片空白”。
• URL 带参申请用户在某个页面遇到”无权限”提示时，直接一键跳转到申请页，并自动带上对应权限点，避免用户自己去找。
• 角色说明要写清楚每个角色（或角色组）在申请页要写明”谁该申请、能做什么、常见适用岗位”。角色描述看不懂，就等于没设计。


2）审批侧：分级审批，避免盲批

审批要按角色的敏感度分层，不能一刀切。

角色类型

建议审批链路

普通角色

直属主管 + 应用负责人

敏感角色（数据导出、跨部门查看等）

直属主管 + 应用负责人 + 敏感权限专项审批人

超级管理员类

直属主管 + 应用负责人 + 部门负责人 + 安全评估

分级只是第一步，更关键的是让审批人有信息、有意愿判断：

• 审批依据要充分申请单里要带上申请人的岗位、申请理由、要用这个角色做什么。光看角色名判断不了。
• 审批率要监控如果一个审批人的通过率长期在 99% 以上，很可能就是盲批。可以做定期抽查，倒逼审批人认真看。
• 敏感权限配独立审批人数据导出、跨部门查看这类敏感权限，专门配一个懂业务的审批人，专职把关，避免混在普通审批里被顺手放过。
• 或许可以来点AI分析利用AI分析历史审批数据通过情况，当下次类似岗位用户过来申请，可以根据历史审批情况给出审批建议，告诉审批人是否允许通过。例如，该角色同部门/同岗位拥有角色比，如果一个角色一个部门只有一个人有权限，有一定程度作为异常申请来考虑。


简单一句，审批环节的审批人需要真的能判断这个权限该不该给。

2.3 清理运维机制

前两步是”入口”，把角色设计好、让申请审批更合理。第三步是”出口”——权限进来了怎么退出去。做完前两步只是把烂摊子收拾干净，如果没有清理机制，用不了几年又会重新泛滥。

清理很难靠人的自觉，要靠机制和工具。

1）定期权限复核

每季度或每半年，向所有角色负责人下发复核工单，让他们主动确认名下的角色”哪些人还在用、还需不需要”。复核有几个要点：

• 工单要有硬性完成时间，逾期不处理走升级流程。
• 复核结果要留痕，方便后续追责和审计。
• 不必每次全量复核，重点关注长期未变动的角色和大用户量角色。


2）异常权限主动识别

用数据分析主动挖异常，而不是等出事才查。常见的异常账号特征：

• 长期未登录的账号，其名下角色是否还有必要保留？
• 跨部门授权的账号，是否符合当前岗位职责？
• 敏感角色持有过多的账号，是否存在过度授权？
• 异动人员的账号，权限是否已回收干净？


这些筛出来的账号形成一份异常清理清单，推给对应管理员做二次确认。管理员只做审阅决策，不用自己去逐个查，效率高得多。
三、实战五步走
前文梳理了权限治理的整体思路。如果当前系统架构无法支撑分层治理的落地——例如角色与应用强绑定、无法按业务域跨应用编排、鉴权逻辑分散在各应用中——则可能需要将权限能力迁移至新的权限平台。下面按五个步骤展开具体操作。



第一步：盘点现状

采集以下数据：

• 现有角色清单，形成”应用 × 角色”矩阵
• 每个角色挂载的权限点
• 每个角色的当前授予人数
• 每个角色的最近使用时间
• 每个应用的负责团队


汇总成权限现状全景图后，问题会自然暴露。例如某个角色仅2人持有，且三年前授权后从未使用，可直接归入清理列表。

第二步：顶层设计

产出”角色治理规范”，作为后续角色变更的约束文件。

关键动作：

• 按一级业务分类划分业务域，数量控制在3到7个
• 任命业务域超管和应用管理员，明确各层责任人
• 制定角色命名规范，确保角色名能直接反映所属域、应用和职责范围


规范成文后，新增角色和权限变更均有据可依。

第三步：角色组打包

从业务视角识别角色组。选取典型岗位用户访谈，梳理日常工作流程，识别跨应用高频权限组合，每个典型岗位映射为一个基础角色组。

两条原则：

• 基础角色组只包含该岗位全体成员必备的通用权限。个别人员的特殊权限单独到应用域申请。
• 命名使用业务语言，用户能一眼辨认。


验证方式：让一名新员工阅读角色组说明，看10分钟内能否独立判断自己该申请哪个角色组。如果不能，说明命名或描述需要调整。

第四步：平滑迁移

如果老系统迁移不能中断服务，应用太多，迁移成本太大，并且旧有的门户用户已习惯使用。也可以考虑分阶段推进：

阶段一：底座改造。平台门户需要在用户访问菜单鉴权时，同时支持新老两套权限系统，老应用继续使用原有权限逻辑。

阶段二：分批迁移。按应用依赖关系排序，从依赖最少的下游开始。每个应用迁移分三步：

• 在新平台创建应用及角色，批量写入存量用户。
• 双写比对，鉴权时同时调用新老系统，比对结果。可能无法完全追求完全一致，但是鉴权大体正常就OK，个别丢失权限可以手动去新系统上授权。
• 观察通过后，切换为仅调用新系统。


阶段三：全量收敛。所有应用完成后，评估彻底停止调用旧权限系统的鉴权接口。

当然，权限管理是一个相对灵活的工作。可能会有团队觉得，老的虽然不方便，但是能用就行，大费周章升级投入产出比很低。这也是可以理解，但是不影响传递这份重要的权限管理概念，在新建应用的时候不要再重蹈覆辙。

第五步：长效治理

治理不是一次性项目。没有持续机制，权限系统会再次混乱。

日常建立三类动作：

• 定期复核。每季度或每半年向权限负责人下发复核工单，确认人员是否仍需持有这些权限。
• 异常识别。通过数据主动发现异常授权，如长期未登录、跨部门授权、敏感权限持有过多等，生成清理建议清单。
• 人员变动联动。员工异动或离职时自动触发权限回收。

四、实战建议
先做减法，再做加法。先清理该删、该合、该废的角色，把总量降下来，再搭建新结构。存量清理应优先启动。

让业务方参与设计。分层设计和角色组方案需业务方参与评审。脱离业务实际的设计落地时容易被驳回。

迁移期间做好用户通知。迁移前提前通知、准备FAQ、开通答疑渠道、制定回滚预案。

将治理成果文档化。治理过程中产生的命名规范、角色组定义清单、迁移操作手册、复核模板等均需归档。
五、小结
本文小结

平台级权限治理，本质上不是一次技术改造，而是一次业务功能可访问范围的全面梳理。它考验的是产品经理对业务的抽象能力，以及推动跨团队协作的执行力。

治理的过程会遇到很多阻力：或许会回到”能用就行、别折腾了”的想法。这时候也需要有耐心把治理的价值讲清楚——不是为了治理而治理，而是让权限体系真正能服务业务、又能守住安全底线。

风险小剧场

小洞不补，大洞吃苦。

风险启示：角色泛滥的趋势越早干预，后续治理成本越低。权限管理的风险往往是渐进的，今天的临时方案和例外授权，明天就成了难以撼动的海量授权数据——风险不爆发不代表不存在，等爆发时再处理，代价远超日常治理。

本文由 @风控PM咖喱 原创发布于人人都是产品经理。未经作者许可，禁止转载

题图来自Unsplash，基于CC0协议

--------------------------------------------------
本文转载自：https://www.woshipm.com/pd/6432206.html