随着系统数量的增加和业务复杂度的提升，传统的分散式权限管理逐渐暴露出诸多问题，如管理难度大、监管困难等。本文将详细介绍一家中型互联网公司如何基于RBAC理论构建深度扩展的通用权限系统，实现权限管理的统一化、精细化和高效化。

一、背景和目标

公司是一家中型互联网类公司，人员规模在5000人左右，信息化已经有了10余年的历史。在这十多年中，进行了非常多的信息系统建设，每个系统都有自己的权限管理模块。因为各个系统建设的时间不同、背景不同，权限管理的模块差异很大、能力参差不齐，使得管理难度大幅提升，建设统一权限服务的需求就酝酿而生。

1.1 痛点

• 业务细化、管理深入，不同系统对于权限管理的需求越来越精细
• 系统众多、难以管理，管理员在不同系统中进行权限管理的难度增加
• 系统众多、监管困难，权限散落在各个系统，无法形成有效监管

1.2 目标

• 建设统一的通用权限系统，取代各个系统的权限管理模块
• 提供强大的权限管理能力，满足全部系统的权限管理需求
• 统一的管理方式，支持按照用户角色授权管理，简化授权操作

二、产品规划

2.1 产品架构图

2.2 业务流程图

2.3 理论基础

公司选择了基于RBAC理论的产品建设，同时结合公司管理的精细度，进行了抽象设计，提炼出亮点能力包括完善的数据权限管理、以及中台角色的集中管理。

B端究竟需要什么样的产品经理？

B端产品经理都是以提升供应侧的工作效率为目的，所以B端需求主要是以业务问题为导向。 这个是B端产品比较重要的一点，B端产品是服务于一个主体 ...

查看详情 >

2.3.1 RBAC理论

RBAC理论在互联网企业得到了非常广泛的使用，具备较好的用户基础，对比之后，我们也选择以RBAC为基础。

RBAC是基于角色的权限管控，角色的一端是权限（菜单/功能），另一端是人，能较好解决基础的权限管理问题。

2.3.2 数据权限

随着业务分工的细化，在很多系统中，单一的权限（菜单/功能），授权的不同用户，其可查看的数据范围不同，但RBAC0-RBAC3都无法支撑该问题的解决，所以我们拓展了RBAC，并最终选定了如下方案：

• 基于RBAC，建立角色，配置角色权限（菜单/功能），把用户添加到角色
• 对每一个权限（菜单/功能），可设置所需要的数据权限维度
• 角色中，每个用户，针对每个权限（菜单/功能），可设置不同的数据权限

这里为什么没有把数据权限作为菜单/功能权限的一部分？即对每一类拥有相同数据权限的人设置为一个独立角色，更符合RBAC定义、也更清晰，卖个关子，在文章最后我们再来回答这个问题。

2.3.3 中台角色

公司的很多系统中，都有相同的角色设定，随着产品功能越来越多，角色的能力边界开始变得模糊，同一个物理角色在不同系统中被赋予了近似但不同的定义。

通过在集团公司层面统一的角色管理和定位，每一个物理角色对应唯一一个系统角色，跨系统进行权限管控，对管理者、使用者、内控/内审等都是非常有价值的事情。

2.4 相关用户

1.系统管理员

系统管理员（研发）负责进行基础数据的配置，如各系统的菜单初始化导入、数据维度的字典创建

2.产品经理

其他各业务系统的产品经理是本产品的主要用户，进行角色管理，创建角色、为角色配置菜单、配置授权人

3.授权人

即业务管理员，比如人事、财务的系统对接人，是本产品最常用的用户，日常给普通用户做授权

4.普通用户

被授权人，不直接进入本系统，通过本系统获取特定系统功能的权限

三、功能设计

3.1 角色管理

RBAC是以角色为中心的，角色管理是基础能力。除了常规的角色一览、新增、编辑、删除，还提供了复制的能力，同时重点介绍下权限设定的能力。

本功能的用户是其他各业务系统的产品经理。

3.1.1 角色一览

产品原型图供参考

3.1.2 角色新建/编辑

1.业务类型

如图编号1，角色所属的业务类型，不同业务类型的角色只能绑定对应类型的菜单（下面菜单管理中也有业务类型属性），这样做到数据隔离。

2.授权范围

通常，对于公司级的角色，设置授权人为业务管理员，比如人事、财务的系统对接人。

在授权方面，还支持部门内授权，即把一些偏行政类权限授权给部门负责人，部门负责人根据自己部门的需要再向下授权。

3.1.3 权限设定

1.同一个角色可管理的权限（菜单/功能）范围跨越多个系统

参考图中编号1，切换不同系统名称可绑定多个系统的菜单到该角色。

2.菜单的数据维度设置

左侧菜单列表中，菜单名称右侧的红字，如图中编号2，“业态”、“财务公司”、“部门”这些，就是数据维度，在菜单管理中，定义不同的菜单能支持哪些数据维度的权限控制。

对每个角色，选择包含哪些菜单，同时设定这些菜单可以授权的数据维度的范围，做出限定；限定后，在权限分配中，角色管理员，只能对用户授予不超过该范围的数据权限。

在实务场景中，多数情况数据维度的权限范围会设置为“全部”，如图中“业态”中全部数据、“财务公司”的全部数据，这样就把权利下放给了角色的授权人，授权人（业务管理员）在权限分配中可以灵活进行数据权限配置。

3.为不同菜单限定数据权限范围

参考图中编号3，为不同的菜单设置不同的数据权限范围，后文权限分配时会进一步说明。

4.系统间权限隔离

不同的产品经理，实际在负责不同的系统，那么在角色中只能配置有权限系统的菜单权限。哪个产品经理负责哪些系统也是一种权限设置，也通过本系统中内置的角色实现。

5.菜单数据权限组合说明

• 不同组合之间是并集的关系
• 同一个组合之间不同的数据维度是交集的关系
• 同一个组合之间的部分数据权限是有关联关系的，这是在后台维护的，一般数据维度都是公司统一规划的，未开放给产品经理做前台维护

3.2 权限分配

权限分配是产品使用率最高的功能，业务管理员，比如人事、财务的系统对接人，通过该功能，给普通用户授予权限。

3.2.1 权限一览

业务管理员只能查看有权限的角色对应的授权数据

3.2.2 权限添加/编辑

业务管理员通过该功能给用户添加/编辑权限；可以设置有效期，过期自动失效；可以同时对多用户进行授权。

1.角色中跨多系统授权

作为业务管理员，比如人事的系统接口人，是可以管理全部人事系统的角色的，所以对人事相关的多个系统的菜单，其都可以进行管理，不需要再做权限划分，如图中编号1，点击不同系统名称对不同系统菜单进行设置。

2.角色中菜单权限范围

对于该角色的用户，其拥有该角色的全部功能（菜单）权限，为了保证管理的清晰，一个角色对应的不同用户的功能范围是一致的，这也符合RBAC的规范。

3.对菜单授予数据权限

对于该角色中的不同菜单，可以设置不同的数据权限组。通过选中左侧特定的一个或多个菜单，点击图中编号3的按钮，即可对选中菜单设置数据权限组。如果在设置过程中，右侧有多个数据权限组，那么点击编号3的按钮时，会弹出子窗口让用户选择该选中菜单使用哪个数据权限组。

与菜单权限不同，该角色的不同用户，可以拥有不同的数据权限。

在角色配置中，限定了一个角色只能设置一个菜单数据权限组，但在本页面中，系统支持多菜单数据权限组，对不同的菜单，配置不同的数据权限组，使用上更灵活。

4.菜单授权数据权限状态变化

对于已经设置了数据权限的菜单，系统会显示为“已配置”、未设置数据权限的菜单，系统会显示“未配置”，参考图中编号2，便于业务管理员直观看到数据权限授予的情况。

5.菜单授予数据权限反向查看

哪些菜单授予了哪些数据权限组，是个一对多的关系。如图中编号4处，可反向查看每个数据权限组和哪些菜单建立了关系，点击编号4的图标，会显示该数据权限组对应的菜单列表。

6.模版功能（添加模版）

对于经常使用的数据权限组合，可以通过保存模版，达到一次配置，多次使用的目的。模版能力不展开介绍了。

3.3 菜单管理

通过菜单管理，配置其他各个系统的菜单/功能，供角色管理使用。

3.3.1 菜单一览

3.3.2 菜单新增/编辑

1.菜单所属系统、类型

参考图中编号1，权限中台会承载公司不同业务系统，包括专属的财务、人事系统，以及通用的OA等系统。这里如果标记为特定的类型，那么可以通过内置的角色进行数据授权，控制哪些用户可以访问哪类的菜单数据，从而达到数据隔离管理。

对应的，在角色管理中，也限定了不同类型角色只能引用该类型的菜单。

2.数据权限

参考图中编号2，对于不同的菜单，对支持的数据维度进行配置。仅当菜单支持这个维度，那么在角色设置、权限分配中，才能对该菜单的这个数据维度配置权限。

四、后记

4.1 数据权限不作为菜单/功能的扩展

回答前文中对于数据权限设计的取舍问题，如果把数据权限作为菜单/功能权限的扩展，使得一个角色只有唯一一组菜单、唯一一组数据权限，有以下几点问题：

• 拥有不同的数据权限的用户，就会产生不同的角色，角色会非常多，管理困难；
• 以我们公司管理的精细度来看，分工很精细，基本上一个数据维度只有1个人，这样角色的意义就不存在了。因为角色就是为了定义一类人；
• 因为业务分工细致（按数据维度），分工的调整也比较灵活，角色的设置无法满足如此灵活的设置，而且如果定义了一个角色有多个人，那么彼此之间的权限又会互相影响；
• 最后，从公司情况看，进行角色梳理难度也比较大，业务价值不明显，所以放弃了一定的规范性，而选择了灵活性。

4.2 各产品接入权限中台

本文专注于权限中台的产品本身的设计和思考，并没有过多体现相关产品的接入。

对企业来讲，权限中台的产品出现时，必然已经有很多独立式烟囱产品存在了，而且这些独立产品都有各自的权限模块或能力，如何推动相关产品放弃自己的权限模块，接入权限中台，以及在这个过程中，权限中台应该怎么做好定位，如何厘定能力边界，建设通用能力和灵活的适配能力，也是产品非常重要的组成部分，且更有挑战性，受限于篇幅，就不在本文赘述了。