权限设计种类【RBAC、ABAC】

• ACL 模型：访问控制列表

• DAC 模型：自主访问控制

• MAC 模型：强制访问控制

• ABAC 模型：基于属性的访问控制

• RBAC 模型：基于角色的权限访问控制

一、简介前三种模型：

1.1 ACL（Access Control List):每一个客体都有一个列表，列表中记录的是哪些主体可以对哪些客体做什么。缺点：当主体的数量较多时，配置和维护成本大，易出错。

1.2 DAC（Discretionary Access control):是ACL的扩展，在其基础上，允许主体可以将自己拥有的 权限自主地授予其他主体，权限可以随意传递。缺点：权限控制比较分散，主体权限太大，有泄露信息的危险。

1.3 MAC（Mandatory Access Control):双向验证机制，常用于机密机构或者其他等级观念强的行列；主体和客体都有权限标识，主体能否对客体进行操作取决于双方的权限标识信息。缺点：控制严格、实现工作量大，缺乏灵活性。

二、RBAC详解

2.1 RBAC的概念

RBAC（Role-Based Access Control): 指的是通过用户的角色（Role）授权其相关权限，角色代表了权限。实现了灵活的访问控制，相比直接授予用户权限，要更加简单、高效、可扩展。

RBAC三要素：

用户：系统中的所有账户

角色：一系列权限的集合

权限：菜单、按钮、数据的增删改查

2.2 RBAC的深度拓展

基于角色的访问控制：RBAC 模型可以分为：RBAC0、RBAC1、RBAC2、RBAC3 四个阶段，一般公司使用 RBAC0 的模型就可以。另外，RBAC0 相当于底层逻辑，后三者都是在 RBAC0 模型上的拓展。【迄今为止最为普及的权限设计模型】

RBAC0:用户和角色、角色和权限多对多的关系。

RBAC1:增加了角色的分级逻辑，类似树结构，下一节点继承于上一节点的权限。

RBAC2:增加更多限制条件：角色互斥、角色数量限制，为了权责明确、系统安全

RBAC3:综合了RBAC1和RBAC2的所有特点。

RBAC0

RBAC1

RBAC2

三、ABAC详解

3.1 ABAC的概念

基于属性的访问控制（Attribute-Based Access Control，简称 ABAC） 是一种比 RBAC更加灵活的授权模型，它的原理是通过各种属性来动态判断一个操作是否可以被允许。这个模型在云系统中使用的比较多，比如 AWS，阿里云等

ABAC的四大要素：

• 对象：对象是当前请求访问资源的用户。用户的属性包括 ID，个人资源，角色，部门和组织成员身份等

• 资源：资源是当前用户要访问的资产或对象，例如文件，数据，服务器，甚至 API

• 操作：操作是用户试图对资源进行的操作。常见的操作包括“读取”，“写入”，“编辑”，“复制”和“删除”

• 环境：环境是每个访问请求的上下文。环境属性包含访问的时间和位置，对象的设备，通信协议和加密强度等。

在 ABAC模型 的决策语句的执行过程中，决策引擎会根据定义好的决策语句，结合对象、资源、操作、环境等因素动态计算出决策结果。每当发生访问请求时，ABAC模型决策系统都会分析属性值是否与已建立的策略匹配。如果有匹配的策略，访问请求就会被通过。缺点：规则复杂，不易看出主体与客体之间的关系，实现非常难，现在应用的很少。

3.2 ABAC的使用

有一些ABAC语言，如xacml和alpha。使用ALFA，我可以编写以下策略:

• 允许用户在部门A中添加新的团队成员

• 在部门B，他只能查看团队列表

• 在其他部门，他没有任何权限。

• 角色还必须是可继承的，存储在模型中，并可通过接口进行管理

policyset appAccess{apply firstApplicablepolicy members{target clause object = "member"apply firstApplicable/*** A user can add a member to a department if they are a manager and if they are assigned to that department.*/rule addMember{target clause role == "manager" and action == "add"permitcondition user.department == target.department}}
}

ABAC的主要优点之一是，可以开发任意多的策略，对它们进行审计和共享，而不必触及应用程序代码，因为最终将授权外部化。

【此处参考于：authorization - Django role based permissions - Stack Overflow】

3.3 两种模型对比

【图片来源：ABAC权限模型（个人记录） - 知乎】

四、新权限系统的设计思想

新权限系统的权限模型：用户最终权限 = 用户拥有的角色带来的权限 + 用户独立配置的权限，两者取并集。

对于权限系统自身的用户，会分为三类：

1. 超级管理员：拥有权限系统的全部操作权限，可以进行系统自身的任何操作，也可以管理接入权限的应用系统的管理操作。

2. 权限操作用户：拥有至少一个已接入的应用系统的超级管理员角色的用户。该用户能进行的操作限定在所拥有的应用系统权限范围内。权限操作用户是一种身份，无需分配，而是根据规则自动获得的。

3. 普通用户：普通用户也可以认为是一种身份，除去上述 2 类人，其余的都为普通用户。他们只能申请接入系统以及访问权限申请页面。

新权限系统中，把权限分为两大类，分别是：

• 菜单功能权限：包括系统的目录导航、菜单的访问权限，以及按钮和 API 操作的权限

• 数据权限：包括定义数据的查询范围权限，在不同系统中，通常叫做 “组织”、”站点“等，在新权限系统中，统一称作 ”组织“ 来管理数据权限

每个系统中设计了三个默认角色，用来满足基本的权限管理需求，分别如下：

• 超级管理员：该角色拥有该系统的全部权限，可以修改系统的角色权限等配置，可以给其他用户授权。

• 系统管理员：该角色拥有给其他用户授权以及修改系统的角色权限等配置能力，但角色本身不具有任何权限。

• 授权管理员：该角色拥有给其他用户授权的能力。但是授权的范围不超出自己所拥有的权限