数据权限设计（浅谈权限配置能力设计）

编辑导语：权限配置能力，可以为各应用提供权限配置原子能力，帮助应用快速集成权限配置，提高系统权限管理体验。本文作者分析了如何以RBAC模型设计可配置的权限中心，一起来看一下吧。

权限配置能力作为权限控制器，为各应用提供权限配置原子能力。这里聊聊，如果想要以RBAC模型设计可配置的权限中心，该怎么入手。

笔者根据自己的行业经验总结了一下思路，欢迎大家批评指正。

所谓权限配置能力，就是以权限、角色为中心，把权限配置单独作为原子能力服务，高度抽象，为开发者、运营人员提供一整套对菜单、接口和数据资源进行授权，同时提供标准授权界面，帮助应用快速集成权限配置，为业务运营集成权限统一管理，形成标准化流程，提高系统权限管理体验。

权限配置能力，主要实现的是从用户角色到功能应用的权限控制器，提供管理功能权限、数据权限的基础能力，提供权限服务（管理+控制）能力给每一个应用使用，免除重复开发、考虑不全的问题。

一、什么是RBAC模型

首先，我们来说说什么是RBAC模型。

RBAC认为权限授权的过程可以抽象地概括为：Who是否可以对What进行How的访问操作，并对这个逻辑表达式进行判断是否为True的求解过程，也即是将权限问题转换为What、How的问题，可以说，Who、What、How构成了访问权限三元组。

1. RBAC的组成

在RBAC模型里面，有3个基础组成部分，分别是：用户、角色和权限。

RBAC通过定义角色的权限，并对用户授予某个角色从而来控制用户的权限，实现了用户和权限的逻辑分离（区别于ACL模型），极大地方便了权限的管理。

用户-角色映射：用户和角色之间的映射关系角色-权限映射：角色和权限之间的映射关系
（注：图来源于网络，如侵权可告知删除）
2. RBAC的原则
RBAC支持三个著名的安全原则：最小权限原则、责任分离原则和数据抽象原则。
最小权限原则：RBAC可以将角色配置成其完成任务所需的最小权限集合。责任分离原则：可以通过调用相互独立互斥的角色来共同完成敏感的任务，例如要求一个计账员和财务管理员共同参与统一过账操作。数据抽象原则：可以通过权限的抽象来体现，例如财务操作用借款、存款等抽象权限，而不是使用典型的读、写、执行权限。
3. RBAC的优缺点
RBAC模型优点是简化了用户和权限的关系易扩展、易维护。
但也存在一定的局限性，比如，RBAC模型没有提供操作顺序的控制机制，这一缺陷使得RBAC模型很难适应哪些对操作次序有严格要求的系统。
二、权限控制框架
聊完了RBAC模型，我们可以先看看权限控制框架设计。
刚刚提到过，所谓权限，就是对资源、数据等进行配置，不同的人分配不同的权限。可以说，权限控制框架其实就是将不同的资源、数据分配给不同的角色，从而完成授权行为。
1. 权限配置
针对不同的角色配置相应的授控资源（包括菜单、接口、数据资源等）完成授权配置。
具体配置流程需要对应用系统的资源进行录入（包括菜单资源、接口资源、数据资源）后，对业务应用系统的资源进行重新配置为权限策略，最后对角色进行赋权以及角色绑定用户。
完成配置后，业务系统通过调用对外服务的SDK标准组件或接入API接口，判断资源与用户/角色的关联关系后进行权限控制即可。
实际上，授权不仅仅可以对角色进行授权，实际上还可以通过将角色与组织机构、行政区划、标签等纬度进行关联授权，甚至是直接将用户与组织机构、行政区划、标签等纬度进行关联授权。但在本文中，暂时先不考虑这种多维度的授权逻辑，只讨论常规授权逻辑。
2. 鉴权服务
针对具体的运行环境，判断授权对象是否对授控资源具有某种操作或数据范围的权限。
三、资源管理
权限策略的前提时，需要对应用系统的资源（包括菜单资源、接口资源、数据资源）进行录入。
在系统初始化时，由超级管理员或开发人员完成码资源管理的录入和管理，后续可集成到相应的管理平台中，为产品运营提供灵活可控的权限控制。
1. 菜单资源
菜单资源，指的是对业务系统的前端功能菜单/页面资源进行录入管理，以独立的URL进行区分，可进行分层级管理。
新增菜单资源：需要填写资源名称、资源编码、资源路径、排序号、打开方式等信息新增子菜单：需要填写资源名称、资源编码、资源路径、菜单等级和上级菜单、排序号、打开方式等信息查询：比如可根据菜单名称、ID等进行搜索编辑：编辑菜单资源的基本信息，这里需要注意的是，要确定资源的唯一性及是否可修改等等删除：删除菜单资源，可设置一定的校验规则，比如需要删除下级菜单，才可以删除上级菜单批量导入：可按照标准文档要求，批量导入菜单信息
2. 接口资源
接口资源，指的是对业务系统的后端接口资源进行录入、管理，可以录入URL关键字段和接口请求方式。
新增接口资源：需要填写选择资源名称、资源编码、资源路径、请求方式等查询：比如根据接口名称、接口地址进行搜索编辑：编辑接口资源删除：删除接口资源批量导入：可按照标准文档要求，批量导入接口信息
3. 数据资源
数据资源，主要指业务系统中存储的数据资源，通过字段信息进行区分，可以通过唯一编码录入权限管理。
新增数据资源：需要填写选择数据元素名称、元素编码、所属页面名称、所属菜单路径等查询：比如根据字段名称进行搜索编辑：编辑数据字段资源删除：删除数据字段资源批量导入：可按照标准文档要求，批量导入字段信息
四、权限策略
根据业务应用实际情况，建立权限策略管理功能，对已经纳入管理的资源，包括资源管理添加的菜单、接口、数据字段资源进行重新配置权限，管理权限与资源的关联逻辑。
从控制力度来看，权限管理分为两大类：功能权限管理和数据权限管理。
在系统初始化时，由超级管理员或开发人员完成码权限策略的配置和管理，后续可集成到管理平台中，为产品运营提供灵活可控的权限控制。
1. 功能权限
1）定义
通俗的说，功能权限指用户登录系统后能看到哪些模块，操作哪些按钮。每个角色有配置固定的功能权限，角色之间权限相互隔离。所有角色的对应功能权限由管理后台进行配置。
2）分类
功能权限包括：业务功能、授权功能。
业务功能：根据业务场景，定义不同的业务功能。结合实际业务场景，进行业务功能与角色关联配置，完成相关角色的权限配置。授权功能：若该角色具有“授权管理”功能，则需要通过管理后台配置允许该角色进行授权的子角色。
2. 数据权限
1）定义
如果所有信息都是公开透明的，也就不需要做数据权限的控制。可城市码的业务形态多而杂，每个人、每个角色需要看到的、应该看到的数据不同，数据权限便应这些需要和规则而生。
数据权限较比于其他两个权限较为抽象，指的是用户是否有针对某些数据的浏览权限，用户在某个模块里能看到哪些范围的数据。不同角色在同一个页面看到的信息是不同的，可以通过组织架构来区分。
2）业务决定
对于数据权限的管理比较复杂，这个主要还是有具体的业务来决定的。数据权限一般和组织架构相关。根据组织机构的层级关系，结合业务实际场景，实现不同角色的数据权限的划分。
比如A业务经理只能看到自己的客户数据，但是A的业务总监可以查看到各个区域业务员的客户数据。
3）数据权限向上兼容原则
数据权限向上兼容，若出现多层级授权场景，上级可以对查看下级信息（包括统计信息、授权信息等）。当用户获取数据时，根据自己当前的部门和职位，获取到所有下属的职员信息。
例：业务管理员可以查看其管辖范围内次级管理员或业务员的所有信息。
3. 权限策略
对已经在【资源管理】已经录入的资源，在【权限策略】进行重新配置为权限策略。
新增权限策略：需要填写功能名称、功能URL路径、功能描述、行政区划、组织机构等，对【权限策略列表】进行勾选查看：对已授权功能进行展示，并可以展开查看所有资源明细编辑：编辑功能权限删除：删除功能权限关联角色：关联角色，对角色进行赋权
五、角色管理
在系统初始化时，由超级管理员或开发人员完成角色管理的配置和管理，后续可集成到管理平台中，为产品运营提供灵活可控的权限控制。
1. 角色授权
在功能权限策略管理功能已经完成功能权限配置后，需要对角色进行赋权，赋权后展示角色对已授权功能权限和资源明细全景图，便于配置维护。可将角色与用户进行绑定，完成角色授权。
新增角色：需填写角色的名称、角色类型、角色层级（行政区划、组织机构）编辑角色：编辑角色关联权限：关联权限策略，对角色进行赋权关联用户：将角色与用户关联起来，从而实现对用户授权
2. 角色的组织属性
1）行政区划
行政区划是行政区域划分的简称，是国家为了进行分级管理而实行的区域划分。一般来说，我国的行政区划管理体系颗粒度可到省-市-区-街道-社区村居5级管理。
一个管理员只对应一个行政区划，管理员下的查验员都跟着管理员的行政区划。
注意：很多时候，行政区划不是必要的组织属性，一般的to B企业基本不会用到该字段信息。但有时候对于政务行业相关的应用系统，行政区划信息还是必要的。
2）组织架构
组织机构是行政组织机构管理的简称，是为了实现在不同组织机构、部门等层级的分级管理设计。根据组织机构的层级关系，结合业务实际场景，实现不同角色的功能权限、数据权限的划分。
3. 角色层级
1）定义
角色层级可配置3-5个层级，包括普通用户、管理端的管理人员和业务角色。所有角色根据不同场景、不同业务需求决定，角色之间的授权限制条件也与业务场景相关。
2）分类
角色可以分为管理角色、业务角色。
管理角色：具备数据查看权限、具备授权功能，同时也可以拥有业务角色的功能权限业务角色：具备业务功能，根据实际业务场景判断是否具备授权功能（一般不具备）
3）角色权限说明
所有角色与用户的关联可通过管理后台进行授权操作。
六、用户赋权
1. 用户管理
用户管理当前提供后台系统账号的新增和批量导入功能，添加用户时需要添加用户的业务属性，包括角色和角色权限。
2. 用户授权
通过管理后台或小程序，将用户与角色绑定关联，实现用户赋权。一旦用户被分配了适当的角色后，该用户就拥有此角色的所有操作权限。
用户与角色是多对多的关系。一个用户可以拥有若干角色，一个角色也可以赋予若干用户。
3. 多角色并存机制
多个角色并存的时候，不同角色的拥有不同功能权限的功能模块。这里需要分两种情况进行分析。
1）角色权限向上兼容原则
用户可以通过角色切换来进行功能模块的切换，但角色权限也存在向上兼容原则，也就是说，高级权限可以覆盖低层级权限。
比如，一个用户可能即是公司员工又是管理人员，那么这时候他既有普通员工的角色权限，也有管理层（比如业务经理）的角色权限，这时候他登录时无需进行角色切换，而是直接以他所拥有的最高层级角色登陆系统，显示他最高层级角色的功能页面即可。
2）角色权限无法兼容
但也会存在另一种情况，就是可能在系统内，某个用户他既是财务人员，又身兼监管部门要职，而这两种角色的功能业务可能会存在某种冲突，系统不允许同一用户同时兼容这两种身份，但实际上企业内部又出现了这种情况。那么我们就得对这两种角色的权限进行隔离，让同一用户能在系统中身兼多任（注：这里提供的案例可能不是非常准确）。
这里提供一个笔者的解决方案，各位如果有更好的解决思路，欢迎补充~
当面临这种角色权限无法兼容时，可以通过角色切换实现对角色权限的隔离。比如：
若用户只有1个角色或同时拥有2哥及以上的角色但角色可向上兼容，登录时默认使用该用户最高层级的角色登录，加载最高层级角色的功能页面；
若用户有2个及以上的角色，但角色之间可能存在无法兼容的情况，登录时弹框加载该用户所有角色的列表，让用户自己选择角色后，加载该角色的功能页面。
同时提示可以在【我的】->【角色切换】进行角色的切换，并在本地缓存该角色的记录，下次登录时通过读取缓存，自动加载该角色的功能页面。
七、其他授权
这里需要说明的是，授权不仅仅可以对角色进行功能授权，实际上还可以通过将角色与组织机构、行政区划、标签等纬度进行关联授权，甚至是直接将用户与组织机构、行政区划、标签等纬度进行关联授权。
但在本文中，暂时先不考虑这种多维度的授权逻辑，只讨论常规的功能授权。
这里笔者只根据自己的经验整理了一下思路，欢迎大家积极吐槽，期待能与大家一起讨论找到更好的解决方案，谢谢各位的赏读~
本文由 @Elaine 原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自Pexels，基于 CC0 协议。