权限管理是产品经理必备却常被忽视的核心能力。从角色泛滥到权限失控，不当设计带来的安全隐患往往在暴雷时才被发现。本文深入剖析RBAC模型的核心逻辑，拆解功能权限与数据权限的双重维度，提供从业务场景到系统落地的四步设计法，助你搭建既安全又高效的权限管理体系。

规范应用权限是产品经理需要修炼的内功，却在产品工作中常常被忽略。在实际工作中，我发现周围不少产品经理对权限设计的基本概念不了解，往往跟随业务的需求或者面向功能新建角色管控权限，在角色设计时没有结合实际的使用场景做分析，导致权限过大授予或角色泛滥等问题。合理划分权限看似无足轻重，在日常使用中可能不会立即显现问题，但这都建立在用户自觉遵守数据规范的前提下。一旦重要权限被过度授予，就会成为数据安全的重要隐患。

近期小编在工作中接手了权限管理专项任务。表面看只是简单的”权限管理”四个字，实际执行时却发现这项工作十分琐碎，需要考虑权限使用的很多实际细节，尤其当你管理的系统耦合了较多子应用时。如果你在工作中遇到以下类似场景，本系列文章能为你提供一些参考：

• 场景1： 用户们不知道自己该申请什么角色，胡乱申请一通。
• 场景2： 开通角色权限时，审批领导对角色毫无概念，轻易就通过，盲批概率高。
• 场景3： 应用角色数量极其泛滥，面向功能建角色，导致一个用户要申请一堆角色才能满足工作需求。
• 场景4： 从来不做权限清理，系统内藏着一堆不合理的授权，无人在乎，未来有暴雷的可能。
• …….

因此，本系列文章想从权限管理的实战经验来汇总框架性权限管理知识，沉淀出一套自己的方法论分享给大家，希望大家能在日常的产品工作中重视权限管理的基本功，结合实际平衡权限控制和业务便捷需要，从系统层面上合理地设计自己应用的角色。

第一篇文章是基本概念篇，我们讲角色设计。

权限管理的概览图

以我个人理解，权限管理 = 合理的角色设计 + 按需的角色审批 + 定期的权限清理。

（基石）合理的角色设计是权限管理的基石。这一层大坝如果不修牢固，很可能导致角色权限泛滥成灾。这要求产品经理对权限的基本概念和模型要清楚。做好角色设计的前提是，明确知道自己产品的用户群体都有哪些，他们都应该获取应用的哪些权限。尤其是当你的平台包含很多子应用时，角色的顶层设计显得尤为重要。

（流入）在合理的角色基础上， 按需审批控制权限被正确授予，确保流入正确。通常用户申请对应角色时，需要由他的上级和角色对应负责的业务管理员审批通过，以避免用户申请了不合理的角色。针对一些平台敏感的角色，审批有可能更加严格，增设敏感权限审批人评估权限申请的合理性。

（流出）用户和角色可能随业务发展在变化。组织架构调整会导致岗位职责变化，原有角色可能不再适用；员工异动或离职时，其历史权限若未及时清理，则会形成“僵尸权限”，埋下数据安全隐患。因此，定期回溯清理应用内的角色和权限是权限运维的重要环节。一些自动化工具可以在这个环节帮助提效，帮助管理员排查出那些应该及时清理的权限。

角色是什么

角色是一组权限的集合。它不是具体的人，不是临时的权限组合，而是一个被明确定义、可重复使用的权限集合。在这里插入图片描述

核心特征：

• 抽象性：角色代表一类“能做什么”的能力集合，而非“谁”。
• 稳定性：角色设计对应长期业务职能，不随人员变动而频繁更改。
• 复用性：同一角色可分配给多个用户，实现批量授权。

常见的鉴权模型

“为什么需要了解鉴权模型？”

在开始设计角色前，必须理解权限控制的底层逻辑。不同的模型代表不同的控制哲学，选择哪种模型决定了你的权限体系能走多远。

四大基础模型对比

常见的鉴权模型有几种，我们拿出来做个对比：

为什么RBAC是B端产品经理必须掌握的？

如果说你不想关注那么多，RBAC可能是你必须要会掌握的。在B端应用中，RBAC平衡了效率、业务和安全三大需求：它通过角色批量管理权限，极大提升了运维效率；其“角色”概念高度贴合业务认知，便于沟通与适配；同时通过互斥角色、权限追溯等机制，为企业提供了合规可靠的安全保障。这套模型让权限管理从技术实现变成了可被业务理解和管理的基础设施。

实践指导：如何选择模型

绝大多数场景会采用RBAC，它适用于用户规模在几十到数千人、有明确岗位划分、需要满足基础安全审计的所有标准企业内部系统（如ERP、CRM、OA）。这是经过验证的最佳平衡方案。

当遇到RBAC无法处理的动态、复杂规则时，才考虑引入ABAC思路作为补充。例如需要根据时间、地点、数据属性（如“金额<10万”）或复杂的跨部门规则进行实时判断的场景。此时应采用“RBAC打底，ABAC补充”的混合模式，而非完全替换。

## RBAC的角色包含什么

在标准的RBAC模型中，一个完整的角色由两大维度构成：功能权限和数据权限。

功能权限（模块与操作权限）定义了用户登录系统后能看到什么、能操作什么。

• 模块级权限：能看到哪些功能模块（如财务管理、客户管理）
• 页面级权限：能进入哪些具体页面（如财务报表页、客户详情页）
• 接口级权限：能调用哪些后台接口（技术实现层面）
• 操作按钮权限：能在页面上执行哪些操作（如新增、删除、导出按钮）

数据权限（数据范围权限）定义了用户在拥有功能权限的基础上，能看到多少数据、看到哪些数据。对于数据分组很多的应用，做好数据权限隔离很重要。要让同一功能模块内，不同角色看到的数据范围和内容不同。比如最基本的，我是一名生鲜部门的质控，我不应该能看到家电部门的数据。因此，数据权限通常与企业组织架构紧密相关，如按部门、按区域划分。

• 数据量权限：能看到多少条数据（如A用户看100条，B用户看300条）
• 数据范围权限：能看到什么范围内的数据（如只能看本部门数据、本人创建的数据）
• 数据层级权限：在组织架构中能看到哪些层级的数据（如上级看下级数据）

一句话讲，功能权限管“入口”，数据权限管“内容”，两者共同构成完整的权限控制体系。

如何做好角色设计

角色设计的本质是将业务职责翻译成系统权限，必须从真实业务场景出发，最终落实到可执行的权限管控。要在满足最小权限原则保障安全的同时，又要确保用户操作便捷。

如果要我总结最关键的一句，我认为是：一个角色应该让用户独立完成一个完整的业务场景。 如果用户在你的平台处理工作，在A应用要申请若干个角色，在B应用又申请了几个角色，新开的C应用又要申请。用户在一个平台里办公，脑门上顶着几十个角色，那你的权限设计一定是有问题的。

可以用四个步骤建立起角色设计的流程。

第一步（盘点）：全面梳理权限清单，深度理解业务场景

第二步（抽象）：将零散需求聚类，定义出职能明确的角色

第三步（建规）：建立角色关系（继承/互斥）与管理规则

第四步（验证）：通过用户测试和流程验证，建立持续迭代机制

这些步骤完整走完，把你的角色设计给一个新员工看，TA能否在10分钟内明白：

“我需要申请什么角色？”

“这个角色能让我做什么？”

“我该如何申请？”

如果答案是肯定的，你的设计就成功了80%。

最终目标是建立一套业务能理解、系统能执行、安全有保障、维护可持续的角色体系。这里面更多的成本在于梳理，梳理，还是梳理。

下一篇预告： 尽量找一个实例，来明确角色设计的具体操作。尤其当你的应用是陈年老应用、积久不处理，角色已经泛滥成灾，该从何处入手？