通常分为菜单权限、功能权限、数据权限三种

主流的权限体系都是基于RBAC模型建立，套路很明确，这里仅进行简单介绍，重点讲解我从0-1搭建及管理B端权限体系时遇到的问题和思考。

二、权限体系的构成

权限体系三要素：用户、角色、权限

1. 用户：登录平台的使用者，通常需记录用户基本信息，姓名、ID、手机号、所属部门、职位等；
2. 角色：用于描述用户在使用系统时，扮演什么人物，拥有该人物的哪些权利。B端系统最常见的几种角色有超级管理员、平台运营管理员、数据管理员等；
3. 权限：是资源的集合，简单点可以理解为用于决定用户可以在该系统上看见什么、做什么操作。

通常分为菜单权限、功能权限、数据权限三种。菜单权限指用户是否有访问某菜单的资格，无菜单权限时，界面上可以直接隐藏该菜单的入口；当用户进入某菜单后，是否可以点击页面的按钮、是否可以对页面的数据进行增删查改等全部的交互动作都是由功能权限控制。最常见的应用场景是用户A仅能查看页面的数据，无下载数据的按钮或者点击按钮无效；数据权限用于保证数据的私密性，主要体现在以下两种场景中：

（1）数据的查看、下载：清单、报表

根据公司的业务属性，在底层数据的加工清洗中，加入必要字段，对数据打标，通过标识控制权限。通常可以利用报表、清单的筛选条件作为数据权限划分的维度，例如：从分公司、销售渠道等业务架构区分，当用户登录系统时，根据其身份信息判断用户归属于分公司A，那么该用户在报表中无法查看和下载归属分公司B的数据。

（2）数据的应用：大数据分群、画像

针对不同的人群配置运营策略时，需要根据运营者和人群之间的关系，为该运营角色配置数据权限。例如：销售渠道A的运营登录系统后，只能针对归属于渠道A的客户配置策略，无法选择渠道B的客户，或者即使界面上允许A选择全量人群，底层数据也会根据A的角色信息对数据强制筛选区分，以避免各渠道业务交叉。

三者之间的关系如下所示：

1. 一个用户可以拥有多个角色
2. 一个角色拥有若干权限

三、什么是好的权限体系

B端系统承载复杂的业务逻辑，功能往往涉及企业核心，因此在用户权限体系的设计和管理上需要绝对严谨。好的权限体系可以：

1. 避免无用功能对用户产生干扰，影响工作效率；
2. 避免非管理人员误操作引发重大生产问题，保证系统安全；
3. 避免数据交叉，造成重复运营，资源浪费；
4. 避免不同职责之间的数据信息泄露。

四、我遇到的问题及思考

1. 关于用户登录信息的获取

初期不熟悉公司业务，用户登录信息收集不完善，随着系统业务线的扩张，用户的登录信息逐渐无法匹配权限控制规则，例如：数据权限的配置。如上描述，我们通过底层对数据打标可划分数据权限，随着数据标识的增加，权限判断条件也增多，需要大量的用户信息用于判断。

所以在搭建时，应该详细了解系统的业务范围和长期规划，梳理角色，并尽可能多的获取用户信息：

• 用户注册系统时，手工填写身份信息，并预留字段以便后期补充；
• 通过内部OA系统，自动获取。若角色与架构强相关，还可以通过识别用户的所属部门、职位，智能授权相应的角色；
• 如果有强大的标签画像系统，借助大数据的力量打标识别。

2. 关于用户权限的长期维护

随着系统的长时间运转，在权限管理上，可能会因为用户换岗或离司，未及时更权限信息，而导致信息泄露。我们可以：

• 权限系统和企业OA互通；
• 若OA所获取的信息无法满足系统要求，需通过用户手工补充信息，则最好支持管理员角色定期下载全量数据，进行梳理；
• 系统也可设置自动清洗规则，如针对30天内未登陆的用户，取消权限，授权需重新申请。

3. 关于权限的通用规则

当一个系统非常庞大，由多个产品经理负责时，如果没有制定统一的权限规范，特别容易因产品提需求时忘记说明权限要求、或者理所当然认为开发应该知道如何控制权限，而造成新功能没有做权限控制。

权限规范需按照系统的业务和架构制定，这里想到比较浅的几点，举例说明一下：当系统中涉及数据清单、报表时，要求所有的报表区分数据权限；当平台功能是模块化、组件化时，要求权限也与之对应，支持分模块独立配置操作权限；当一个用户拥有多重身份、多个角色时，其权限获取的优先级是什么等等。