权限系统

分类

ACL, DAC, MAC, RBAC, ABAC 模型

使用场景

ACL 访问控制列表

规定资源可以被哪些主体进行哪些操作

场景：部门隔离适用资源：客户页面、人事页面

在ACL权限模型下，权限管理是围绕资源来设定的。我们可以对不同部门的页面设定可以访问的用户。配置形式如下：

ACL配置表
        资源: 客户页面
                主体: 销售部（组）
                操作：增删改查
                主体: 王总（用户）
                操作: 增删改查
        资源: 人事页面
                主体: 王总（组）
                操作: 增删改查

注：主体可以是用户，也可以是组。

在维护性上，一般在粗粒度和相对静态的情况下，比较容易维护。

在细粒度情况下，比如将不同的客户视为不同的资源，1000个客户就需要配置1000张ACL表。如果1000个客户的权限配置是有规律的，那么就要对每种资源做相同的操作；如果权限配置是无规律的，那么ACL不妨也是一种恰当的解决方案。

在动态情况下，权限经常变动，每添加一名员工，都需要配置所有他需要访问的资源，这在频繁变动的大型系统里，也是很难维护的。

在一些情况下，ACL也可应用于细粒度场景，接下来将介绍两种ACL的拓展。

DAC 自主访问控制

规定资源可以被哪些主体进行哪些操作同时，主体可以将资源、操作的权限，授予其他主体

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

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

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

MAC 强制访问控制

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

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

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

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

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

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

RBAC 基于角色的访问控制

a. 规定角色可以对哪些资源进行哪些操作 b. 规定主体拥有哪些角色当一个操作，同时满足a与b时，允许操作。

场景：企业数据适用资源：客户信息

RBAC的思想，来源于现实世界的企业结构。比如，销售角色，拥有查看客户信息的权限。当一个销售人员小王入职了，可以把销售角色赋予小王，那么小王就拥有了查看客户的权限。这种方式，避免了ACL模型下，每次新人入职，需要逐个配置资源表的情况。同样，权限变动也变得很方便，只要修改角色，即可实现多用户的权限修改。

权限表
        名称：创建客户
                资源: 客户信息
                操作：创建
        名称：删除客户
                资源: 客户信息
                操作：删除
        名称：查看客户
                资源: 客户信息
                操作：查看
        名称：修改客户
                资源: 客户信息
                操作：修改
角色表
        名称：销售角色
                权限: 创建客户、删除客户、查看客户、修改客户
用户表
        主体：小王
                角色: 销售角色

RABC 并不总能满足所有权限的场景。比如，我们无法对销售角色，进行个体定制。比如，销售角色拥有创建、删除的权限。如果我们要对销售小李，去掉删除的权限。那么，我们就必须创建另一个角色，来满足需求。如果这种情况很频繁，就会丧失角色的统一性，降低系统的可维护性。

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

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

ABAC 基于属性的访问控制

规定哪些属性的主体可以对哪些属性的资源在哪些属性的情况下进行哪些操作，

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

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

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

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

    效果：禁止
    操作：流出
    主体：任何
    资源：任何
    情况：任何

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

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

阿里云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可以发挥权限系统最大的灵活性，但在灵活的同时，如果不对策略加以管理，也有可维护性的问题。

分类​

使用场景​

ACL 访问控制列表​

DAC 自主访问控制​

MAC 强制访问控制​

RBAC 基于角色的访问控制​

ABAC 基于属性的访问控制​

分类