基于RBAC模型的权限管理设计

[toc]

目的

管理系统用户的功能菜单权限，物理资源（文件、数据）权限。

RBAC模型

简介

RBAC模型（Role-Based Access Control：基于角色的访问控制）是比较早期提出的权限实现模型，在多用户计算机时期该思想即被提出，其中以美国George Mason大学信息安全技术实验室（LIST）提出的RBAC96模型最具有代表，并得到了普遍的公认。

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

核心对象

用户、角色、权限

组成

RBAC0

RBAC0是基础，很多产品只需基于RBAC0就可以搭建权限模型了。在这个模型中，我们把权限赋予角色，再把角色赋予用户。用户和角色，角色和权限都是多对多的关系。用户拥有的权限等于他所有的角色持有权限之和。譬如我们做一款企业管理产品，可以抽象出几个角色，譬如销售经理、财务经理、市场经理等，然后把权限分配给这些角色，再把角色赋予用户。这样无论是分配权限还是以后的修改权限，只需要修改用户和角色的关系，或角色和权限的关系即可，更加灵活方便。此外，如果一个用户有多个角色，譬如王先生既负责销售部也负责市场部，那么可以给王先生赋予两个角色，即销售经理、市场经理，这样他就拥有这两个角色的所有权限。

RBAC1

RBAC1建立在RBAC0基础之上，在角色中引入了继承的概念，即增加角色组的概念。简单理解就是，给角色分成几个等级，用户关联角色组、角色组关联角色，角色关联权限。从而实现更细粒度的权限管理。

RBAC2

RBAC2同样建立在RBAC0基础之上，仅是对用户、角色和权限三者之间增加了一些限制。这些限制可以分成两类，即静态职责分离SSD(Static Separation of Duty)和动态职责分离DSD(Dynamic Separation of Duty)。静态职责分离，如果一个任务有3个步骤，那么要求必要有至少3个不同用户处理完毕，任务才完结。又如，一个任务有2个步骤，要求必须由两个不同角色的用户来处理，且不能是同一个用户，即一个用户不可同时拥有该两个角色，这种可称之为静态互斥角色。动态职责分离，动态分配系统资源和功能的权限，如某些资源在特定时间才允许对某些用户开放。

RBAC3

RBAC3是RBAC1和RBAC2的合集，所以RBAC3既有角色分层，也包括可以增加各种限制。

拓展RBAC模型

针对物理资源的权限管理

系统资源可分为逻辑资源和物理资源。逻辑资源如软件系统的菜单、页面、按钮等等；物理资源如视频文件、音频文件、pdf文件等等。其中逻辑资源可以通过权限来控制，物理资源可通过在角色下设置资源列表，通过角色关联资源列表实现，也可直接将用户和资源列表关联实现。

增加用户组管理

基于RBAC模型，还可以适当延展，使其更适合我们的产品。譬如增加用户组概念，用户组凌驾用户之上，是用户的一个集合。可通过增加UserGroup实现，也可以通过引入组织架构实现（即用户的管理变成了组织-部门-用户的管理）。

权限管理设计

功能权限管理

• 以RBAC0模型为基础建立核心业务实体：单位（公司/部委/组织机构）、部门（科室）、用户、角色、权限
• 使用关联实体为核心业务实体建立映射关系：用户角色、角色权限等
• 为方便数据查询和业务拓展，增加单位权限、单位角色映射关系。此两项非必须。
• 可按照RBAC1模型的设计思路，增加角色组，用户关联角色组、角色组关联角色，角色关联权限。从而实现更细粒度的权限管理。
• 可按照RBAC1模型的思想，将部门和用户的映射关系修改为m:n，将能够实现一个用户归属多个组织的权限管理。如分公司的董事长同时兼任集团公司部门领导的情况。其中隐含了单位和部门关系为多对多，部门和用户关系为多对多。当用户登录的时候，让用户自己选择需要在哪个组织下工作。鉴于这种情况的项目相对而言为少数，大部分项目没有那么复杂的组织架构，可以对外提供两套解决方案。

资源权限管理

业务弱关联性设计

• 资源本身作为一个业务实体，为资源划分类型
• 资源和单位建立映射关系，用户隶属于单位
• 资源和部门建立映射关系，用户隶属于部门
• 资源和角色建立映射关系，用户关联角色
• 资源和行政区划建立映射关系，用户关联行政区划或部门关联行政区划或单位关联行政区划
• 拓展：资源和XXX业务实体建立映射关系，用户关联XXX业务实体

优点：资源和业务实体为弱关联性，可封装成微服务组件对外赋能 缺点：关系模式更加复杂，开发、运维成本高

业务强关联性设计

基于组织架构、职权（角色）、业务归属、区域、坐标等的业务实体建立映射关系

• 数据权限的管理最简单的维度就是基于功能权限的管理
• 根据业务数据归属分别建立用户和数据的映射关系
• 根据业务数据所属业务闸口、区域（行政区域，地缘，自定义划区）和业务实体建立映射关系，业务实体最终落到用户上
• 根据业务数据治理出来的坐标体系建立映射管理
• 其他维度的数据权限管理

优点：方便和业务集成、迁移顺滑 缺点：和业务强绑定

缓存设计

可能出现的问题： 1：用户权限信息庞大，往redis中存储大数据块 2：用户权限信息庞大，Mysql数据库查询效率低