【B端产品权限设计指南】当权限管理走向失控你需要一次彻底重构实战篇本文是「风控PM记」系列文章之一完整可见 系列文章。 持续更新中。目录前言一、老旧权限系统的常见问题二、治理思路从平铺到分层2.1 角色设计与分层管理2.2 申请审批流程设计2.3 清理运维机制三、实战五步走第一步盘点现状第二步顶层设计第三步角色组打包第四步平滑迁移第五步长效治理四、实战建议五、小结本文小结风险小剧场前言上一篇讲了权限管理的基本概念和角色设计的方法论。有小伙伴看完可能会问概念我都懂可我接手的是一个陈年老应用——历史包袱重、角色几百个、各子应用各建各的、清理从来没做过。这时候不是从 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、开通答疑渠道、制定回滚预案。将治理成果文档化。治理过程中产生的命名规范、角色组定义清单、迁移操作手册、复核模板等均需归档。五、小结本文小结平台级权限治理本质上不是一次技术改造而是一次业务功能可访问范围的全面梳理。它考验的是产品经理对业务的抽象能力以及推动跨团队协作的执行力。治理的过程会遇到很多阻力或许会回到能用就行、别折腾了的想法。这时候也需要有耐心把治理的价值讲清楚——不是为了治理而治理而是让权限体系真正能服务业务、又能守住安全底线。风险小剧场小洞不补大洞吃苦。风险启示角色泛滥的趋势越早干预后续治理成本越低。权限管理的风险往往是渐进的今天的临时方案和例外授权明天就成了难以撼动的海量授权数据——风险不爆发不代表不存在等爆发时再处理代价远超日常治理。