权限管理系统设计模式：ACL, DAC, MAC, RBAC, ABAC

ACL 访问控制表(Access Control List)

明确哪些资源(res)可以被哪些主体(obj)进行哪些操作(act)

场景：功能控制 适用资源：数据页面、管理页面

ACL权限模型中，权限管理是围绕资源(res)来设定的。针对不同的部门，需要分配不同的页面访问权限。配置形式如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

ACL配置表
  
  资源: 数据页面
    主体: 数据部门
    操作：增删改查

    主体: CE0（用户）
    操作: 增删改查
  
  资源: 管理页面
    主体: CEO（用户）
    操作: 增删改查

其中主体表示一类人的集合，可以是单个用户，也可以是一个组。

对于没有特别复杂权限配置要求的情况下，还是比较容易配置和维护的。

但是如果资源很多，每个资源都需要去给每个人分配一个权限，会产生巨大的工作量，而且很难去维护。所以，需要从这些权限配置的规则中提取抽象规则。但如果这些规则没有什么规律，比如就是需要为某个具体的主体，配置一些具体的资源，那ACL是比较适用的。

DAC自主访问控制(Discretionary Access Control)

除了规定资源(res)可以被哪些主体(obj)进行哪些操作(act)之外，主体也可以将资源、操作的权限，授予其他主体。

场景：文件系统 适用资源：人事培训文档

DAC是ACL的一种实现，强调灵活性。纯粹的ACL，权限由中心管理员统一分配，缺乏灵活性。为了加强灵活性，在ACL的基础上，DAC模型将授权的权力下放，允许拥有权限的用户，可以自主地将权限授予其他用户。

比如，在纯粹ACL模型下，每次新人培训，人事总监都要通知IT部，将培训文档的访问权限授予新人。在DAC模型下，人事总监只需将文档的访问权限授予人事专员。之后，每次新人培训，由人事专员将文档的访问权限授予不同的新人。

MAC强制访问控制(Mandatory Access Control)

a. 规定资源可以被哪些类别的主体进行哪些操作 b. 规定主体可以对哪些等级的资源进行哪些操作 . 当一个操作，同时满足a与b时，允许操作。

场景：保密系统 适用资源：机密档案

MAC是ACL的另一种实现，强调安全性。MAC会在系统中，对资源与主体，都划分类别与等级。比如，等级分为：秘密级、机密级、绝密级；类别分为：军事人员、财务人员、行政人员。

比如，一份机密级的财务档案，可以确保只有主体的等级是机密级，且是财务人员才能访问。如果是机密级的行政人员就无法访问。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

资源配置表
        资源: 财务文档
            主体: 财务人员
            等级：机密级
            操作：查看
                
主体配置表
    
        主体: 李女士
              类别: 财务人员
              等级：机密级

所以，MAC的优势就是实现资源与主体的双重验证，确保资源的交叉隔离，提高安全性。

RBAC基于角色的访问控制(Role-Based Access Control)

a. 确定角色具有哪些资源的哪些操作权限 b. 主体具有哪些角色

场景：企业组织管理 适用资源：人员管理

RBAC类似于企业管理员工，比如你是HR，那么你就可以管理企业的员工信息，也就是你具有员工管理的角色。如果另一个HR也入职了，那么他也就具有了员工管理的角色，也可以管理员工信息。这样的方式，避免了主体与权限和资源之间的强耦合关系，权限变动只需要更改主体具有的角色就可以了。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

权限表
    
        名称：员工入职
                资源: 员工信息
                操作：创建
        
        名称：员工离职
                资源: 员工信息
                操作：删除
        
        名称：查看员工
                资源: 员工信息
                操作：查看
        
        名称：修改员工
                资源: 员工信息
                操作：修改

1
2
3
4

角色表
    
        名称：HR
                权限: 创建员工、删除员工、查看员工、修改员工

1
2
3
4

用户表
    
        主体：小李
                角色: HR

RABC也存在一些​缺陷。比如，当角色具有增删改查的权限，如小李具有HR角色，所有具有创建员工、删除员工、查看员工和修改员工的权限，但是如果想针对小李个人去除掉删除员工的权限，那么是无法做到的，必须新创建一个角色来满足需求​。如果这种情况经常发生，对于权限的管理和维护会变得很混乱。

角色和组两个概念可能会让人混淆，在这里做个区分：

• 角色赋予的是主体，主体可以是用户，也可以是组
• 角色是权限的集合
• 组是用户的集合

ABAC基于属性的访问控制(Attribute-Based Access Control)

确定具有哪些属性的主体，可以对具有哪些属性的资源，进行哪些属性情况下的操作。也就是对主体、资源、情况增加了属性。

场景：服务器防火墙 适用资源：端口访问

ABAC其中的属性就是与主体、资源、情况相关的所有信息。

主体的属性：指的是与主体相关的所有信息，包括主体的年龄、性别、职位等。 资源的属性：指的是与资源相关的所有信息，包括资源的创建时间、创建位置、密级等。 情况的属性：指的是客观情况的属性，比如当前的时间、当前的位置、当前的场景（普通状态、紧急状态）。 操作：含义还是一样，比如增删改查等。 设定一个权限，就是定义一条含有四类属性信息的策略（Policy）。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

策略表
    
        效果：允许
        操作：流入
        主体：来自上海IP的客户端
        资源：所有以33开头的端口（如3306）
        情况：在北京时间 9:00~18:00
    
        效果：禁止
        操作：流出
        主体：任何
        资源：任何
        情况：任何

一个请求会逐条匹配策略，如果没有匹配到策略，则返回默认效果，默认效果可以根据场景定制，可以是默认拒绝或是默认允许。另外，匹配方式也可以根据场景定制，可以使用逐条顺序匹配，匹配到策略直接返回。也可以使用完全匹配，匹配所有的策略，如果有一个拒绝（允许），则拒绝（允许）。

阿里云的RAM访问控制运用的就是ABAC模型：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

阿里云RAM策略配置表
    
    {
          "Version": "1",
          "Statement":
            [{
              "Effect": "Allow",
              "Action": ["oss:List*", "oss:Get*"],
              "Resource": ["acs:oss:*:*:samplebucket", "acs:oss:*:*:samplebucket/*"],
              "Condition":
                 {
                    "IpAddress":
                     {
                        "acs:SourceIp": "42.160.1.0"
                      }
                  }
             }]
    }

ABAC可以发挥权限系统最大的灵活性，但在灵活的同时，如果不对策略加以管理，也有可维护性的问题。