权限控制解决方案
目录
¶概述
❓什么是权限控制(管理)？
权限管理，一般指根据系统设置的安全规则或安全策略，用户可以访问而且只能访问自己被授权的资源。权限管理几乎出现在任何有用户和密码的系统里面。不要将权限管理与用户身份认证、密码加密与系统管理等概念混淆
简而言之，权限管理主要工作是：根据系统设置的安全规则或者安全策略，限制用户的访问资源
❓为什么需要权限控制(管理)？
❓什么时候需要进行权限控制？
¶权限管理解决方案
权限控制问题已经存在很久，现存最常用的权限控制模型有：基于角色的访问控制（RBAC: Role-Based Access Control）和基于属性的权限验证（ABAC: Attribute-Based Access Control）
¶RBAC 初探
❓什么是 RBAC（Role-based access control）？
👍使用 RBAC 之后，将会极大地简化系统的权限管理。用户可以很容易地从一个角色指派到另一个角色，并且角色可根据新的需求和系统的合并从而赋予新的权限，而权限也可根据需要而从某角色中回收。
¶ABAC 初探
在 ABAC 权限模型下，可以轻松地实现以下权限控制逻辑：
✨上述的逻辑中有几个共同点：
- 具体到某一个而不是某一类资源
- 具体到某一个操作
- 能通过请求的上下文（如时间、地理位置、资源 Tag）动态执行策略
🆚基于属性的权限验证和基于角色的访问控制两者各有优劣：
¶权限控制的分类
从不同角度看待同一个事物存在不同的分歧，以下给出百度百科给出的两种权限控制的分类
¶从控制力度对权限管理分类
✨从控制力度来看，可以将权限管理分为两大类：
数据级权限管理某个用户能够访问和操作哪些数据。通常来说，数据权限由用户所属的组织来确定。比如：生产部只能看自己部门的生产数据；销售部门只能看销售数据。公司的总经理可以看所有的数据，数据级权限管理间接性的保证了数据隔离。在实际的业务系统中，数据权限往往更加复杂，非常有可能销售部门可以看生产部门的数据，以确定销售策略、安排计划等
¶从控制方向对权限管理分类
✨从控制方向来看，也可以将权限管理分为两大类：
¶RBAC 模型概述
RBAC 认为权限的过程可以抽象概括为：判断Who 是否可以对 What 进行 How 的访问操作这个逻辑表达式的值是否为True的求解过程，即将权限问题转换为Who、What、How 的问题。其中who、what、how构成了访问权限三元组
✨RBAC 支持公认的安全原则：最小特权原则、责任分离原则和数据抽象原则
¶RBAC 模型族
✨RBAC96 是一个模型族，其中包括 RBAC0 ~ RBAC3 四个概念性模型：
¶RBAC0
| 组件 | 含义 |
|---|---|
| 用户（User） | 系统接口及访问的操作者 |
| 角色（Role） | 具有一类相同操作权限的用户的总称 |
| 权限（Permission） | 能够访问某接口或者做某操作的授权资格 |
| 会话（Session） | RABC0 权限管理的核心部分，其他的版本都是建立在 RBAC0 的基础上的 |
对应的 UML 类图如下：
每个角色至少具备一个权限，每个用户至少扮演一个角色；可以对两个完全不同的角色分配完全相同的访问权限；会话由用户控制，一个用户可以创建会话并激活多个用户角色，从而获取相应的访问权限，用户可以在会话中更改激活角色，并且用户可以主动结束一个会话。用户和角色是多对多的关系，表示一个用户在不同的场景下可以拥有不同的角色
例如项目经理也可以是项目架构师等；当然了一个角色可以给多个用户，例如一个项目中有多个组长，多个组员等
角色和许可（权限）是多对多的关系，表示角色可以拥有多分权利，同一个权利可以授给多个角色都是非常容易理解的，想想现实生活中，当官的级别不同的权限的情景，其实这个模型就是对权限这方面的一个抽象，联系生活理解就非常容易了
¶RBAC1
🆚一般继承关系与受限继承关系异同
¶RBAC2
RBAC2 模型中添加了责任分离关系。RBAC2 的约束规定了权限被赋予角色时，或角色被赋予用户时，以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。责任分离包括静态责任分离和动态责任分离
约束与用户—角色—权限关系一起决定了 RBAC2 模型中用户的访问许可，此约束有多种：
¶RBAC3
¶RBAC 的设计思路
🎶一个 RBAC 权限模型核心授权逻辑仅考虑以下三点
以一个简单的场景（Gitlab 的权限系统）为例，用户系统中有 Admin、Maintainer、Operator 三种角色，这三种角色分别具备不同的权限，比如只有 Admin 具备创建代码仓库、删除代码仓库的权限，其他的角色都不具备
授予某个用户 Admin 这个角色，他就具备了创建代码仓库和删除代码仓库这两个权限
基于角色的访问控制基本原理是在用户和访问权限之间加入角色这一层，实现用户和权限的分离，用户只有通过激活角色才能获得访问权限。通过角色对权限分组，大大简化了用户权限分配表，间接地实现了对用户的分组，提高了权限的分配效率。并且加入角色层后，访问控制机制更接近真实世界中的职业分配，便于权限管理
在 RBAC 模型中，角色是系统根据管理中相对稳定的职权和责任来划分，每种角色可以完成一定的职能。用户通过饰演不同的角色获得角色所拥有的权限，一旦某个用户成为某角色的成员，则此用户可以完成该角色所具有的职能。通过将权限指定给角色而不是用户，在权限分派上提供了极大的灵活性和极细的权限指定粒度
¶RBAC 用户角色权限设计方案
一个用户拥有若干角色，每一个角色拥有若干权限。这样，就构造成用户-角色-权限的授权模型。在这种模型中，用户与角色之间，角色与权限之间，一般者是多对多的关系，如下图
❓到底什么是角色？
当用户的数量非常大时，要给系统每个用户逐一授权（授角色），是件非常烦琐的事情。这时，就需要给用户分组，每个用户组内有多个用户。除了可给用户授权外，还可以给用户组授权。这样一来，用户拥有的所有权限，就是用户个人拥有的权限与该用户所在用户组拥有的权限之和。（下图为用户组、用户与角色三者的关联关系）
❓在应用系统中，权限表现成什么？
权限表中有一列权限类型，我们根据它的取值来区分是哪一类权限，如MENU表示菜单的访问权限、OPERATION表示功能模块的操作权限、FILE表示文件的修改权限、ELEMENT表示页面元素的可见性控制等。这样设计的好处有二
🎶这里要注意的是，权限表与权限菜单关联表、权限菜单关联表与菜单表都是一对一的关系。（文件、页面权限点、功能操作等同理）。也就是每添加一个菜单，就得同时往这三个表中各插入一条记录。这样，可以不需要权限菜单关联表，让权限表与菜单表直接关联，此时，须在权限表中新增一列用来保存菜单的 ID，权限表通过权限类型和这个 ID 来区分是种类型下的哪条记录。如此，RBAC 权限模型的扩展模型的完整设计图如下：
下图是另一种设计方案
¶角色组
随着系统的日益庞大，为了方便管理，可引入角色组对角色进行分类管理，跟用户组不同，角色组不参与授权
❓角色和用户组有什么区别？
¶如何选择合适的权限模型？
组织的规模是至关重要的因素。由于 ABAC 最初的设计和实施困难，对于小型企业而言，考虑起来可能太复杂了。对于中小型企业，RBAC 是 ABAC 的简单替代方案，每个用户都有一个唯一的角色，并具有相应的权限和限制。当用户转移到新角色时，其权限将更改为新职位的权限。这意味着，在明确定义角色的层次结构中，可以轻松管理少量内部和外部用户。但是，当必须手动建立新角色时，对于大型组织而言，效率不高。一旦定义了属性和规则，当用户和利益相关者众多时，ABAC 的策略就更容易应用，同时还降低了安全风险
简而言之，如果满足以下条件，请选择 ABAC：
如果满足以下条件，请考虑 RBAC：
¶总结
不良的权限管理系统，必然留下系统漏洞，给黑客可趁之机。很多软件可以轻松通过 URL 侵入、SQL 注入等模式，轻松越权获得未授权数据。甚至对系统数据进行修改、删除，造成巨大损失。很多系统，尤其是采用硬编码方式的系统，存在权限逻辑与业务代码紧密耦合，同时又分散在系统各个地方，系统漏洞势必非常多，而且随着系统不断修改，漏洞逐步增多。
好的系统，应该将权限逻辑集中起来，由专业的安全引擎进行设置和解析。业务逻辑调用安全引擎，获得权限结果，不再使用非专业模式。