访问控制（Access Control）

访问控制是给出一套方法，将系统中的所有功能标识出来，组织起来，托管起来，将所有的数据组织起来标识出来托管起来， 然后提供一个简单的唯一的接口，这个接口的一端是应用系统一端是权限引擎。权限引擎所回答的只是：谁是否对某资源具有实施 某个动作（运动、计算）的权限。返回的结果只有：有、没有、权限引擎异常了。 — 百度百科

访问控制是一种通过用户权限控制用户访问数据的方法。访问控制是对数据访问的选择行限制，它应该包含两个模块：认证（authentication)和授权（authorization）。

认证（authentication）是验证用户的凭据，如用户名和密码，以验证用户的身份。

授权（authorization）是在系统验验证用户的身份后，授予用户访问资源（API，文件，数据库）的权限。

例如我们实现一个产品API服务，我们需要让调用方进行认证，如key+secret的方式。当用户认证成功后，我们授予用户访问对应的API的权限。例如一个普通的API用户，他只有调用查询产品信息API的权限，而一个付费的API用户，他拥有调用设置产品标签的API的权限。
复制代码

访问控制模型（Access Control Models）

访问控制的实现，有以下几种成熟访问控制模型帮助我们解决问题：

• 访问控制列表（Access Control List, ACL)
• 自由访问控制（Discretionary Access Control, DAC)
• 强制访问控制（Mandatory Access Control, MAC)
• 基于角色的访问控制（Role-Based Access Control, RBAC)
• 基于属性的访问控制（Attribute-Based Access Control, ABAC)

访问控制列表（Access Control List, ACL)

限制资源可以被哪些主体进行哪些操作

访问控制列表是一个比较简单的模型，该模型维护一个ACL配置表，记录每一个主体对应的权限。
例如，我们有用户Alice和Bob，以及资源article，
规则：

1. Alice 允许阅读以及点赞 article；
2. Bob 允许创建、删除以及阅读 article；

Alice   -> read:article, like:article
Bob     -> read:article, create:article, del:article
复制代码

按照上面的规则，我们在实现Restful API的时候，对应的权限设计如下：

Alice   -> GET /article, POST /like
Bob     -> GET /article, POST /article, DELETE /article
复制代码

通过上面的设计，我们可以看到，访问控制列表的实现以及其优缺点

优点：

• 设计简单，仅需维护简单的ACL配置表；
• 适合用户量少，权限控制简单的场景；

缺点：

• 随着用户量、权限的增多，权限配置将会越来越困难；如1000个客户，每个用户需要配置20-30种权限
• 当权限变动，需要修改每一个拥有该权限的用户ACL记录，工作量比较大

推荐使用场景：

• 用户量小，需要配置的权限数量少的场景；
• 权限配置无规律，每个用户有自己特定的权限

自主访问控制（Discretionary Access Control, DAC)

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

DAC是ACL的一种实现，增加灵活性。在ACL的基础上，DAC允许主体可以将权限授予给其他主体
例如上面的栗子，Alice可以授权Bob点赞article的权限。同时，Bob也可以授予Alice创建、删除文章的权限。

强制访问控制（Mandatory Access Control, MAC)

MAC 基于安全标签, 由系统（非用户）进行对主体、资源进行标签配置
当主体对资源进行操作时，系统会检查主体、资源安全标签是否相匹配

例如：

1. 授权Alice创建article的权限

Alice   -> create:article
复制代码

⚠️ 在MAC模型下，此时Alice并不能创建article，因为article并没有对应的标签，允许Alice进行article的创建

2. 授权article允许Alice的创建权限

aritcle  -> Alice:create
复制代码

此时，Alice可以进行article的创建

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

限制资源可以被哪些角色进行哪些操作
对主体进行角色配置,主体可以操作对应的资源

例如，我们有用户Alice和Bob，以及资源article，
规则：

1. Alice 允许阅读以及点赞 article；
2. Bob 允许创建、删除以及阅读 article；

我们通过基于角色的访问控制，实现对应的规则限制。

1.权限配置

Permissions:
    - Name: Like Article
    - Operations:
        - Resource: Article
        - Action: Like
    - Name: Read Article
      Operations:
        - Resource: Article
        - Action: Read
    - Name: Manage Article
      Operations:
        - Resource: Article
          Action: Created
        - Resource: Article
          Action: Delete
复制代码

2.角色配置

Roles:
    - Name: Reader
      Permissions:
        - Read Article
    - Name: Favorer
      Permissions:
        - Like Article
    - Name: Manager
      Permissions:
        - Manage Article
复制代码

3.用户配置

Users:
    - Name: Alice
      Roles:
        - Reader
        - Favorer
    - Name: Bob
      Role: 
        - Reader
        - Manager
复制代码

通过上面的栗子，我们可以看到，其实RBAC很大程度上贴近现实生活，方便理解和使用。但是，当在复杂的场景下，其实RBAC是不够用的，像上面的栗子，其中的阅读限制，如果我们需要实现article只允许作者本人阅读，那么需要创建很复杂的role和permission，甚至会造成很多虚拟的role。

但是，不可否认的是RBAC非常适合一些组织架构非常严谨的系统，如学校试卷批改系统，学生查阅分数，而老师能创建、批改试卷等。

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

ABAC判断一个主体是否能操作某项资源是通过对其不同属性的计算结果进行判断

Attributes

Attribute -> 属性，可以放任何数据，通常使用key-value的形式来存储信息。其存储的数据，人们习惯分成以下4种不同的类型，分别是：

• Subject attributes，用户相关的属性，如：年龄、职位、角色等；
• Action attributes，操作相关的属性，如：增删查改等；
• Object attributes，资源相关的属性，如：文章、银行账号等；
• Contextual (environment) attributes，时间、位置或者一些和场景相关的上下文属性；

Policies

Policies -> 策略，把属性组合再一起后，通过计算后进行访问控制结果判断。在基于属性的访问控制中，policy可以是授权的策略也可以是拒绝的策略，同时可以是本地的策略也可以是全局的策略。例如：

• 一个用户可以查看属于该用户部门下的文档；
• 一个用户可以修改文档，如果他是该文档的作者同时文档非处于草稿模式；
• 在09:00am前拒绝所有的查询访问

来个栗子，Alice这个小伙子可以阅读(不可修改?‍♂️）属于开发部的文档，文档需要带有Technoloy或Software的标签，而且处于发布模式，阅读时间允许从2021-05-01到2021-08-31，限制阅读的地点在中国。

基于属性的访问控制，其策略如下：

Subject:
    Name: Alice
    Department: Development
    Role: Developer
Action:
    - Read
Resource:
    Type: Article
    Tag:
        - Technology
        - Software
    Mode:
        - Published
Contextual:
    Location: China
    StartTime: 2021-05-01
    EndTime: 2021-08-31
复制代码

总结（Summary）

上面我们介绍了访问控制实现的五种模型，其实每一种模型，都有自己的优缺点，我们需要根据相应的业务场景，选择合适自己的访问控制模型。
复制代码

? 上面是根据我自己了解简单的总结，如果有不对的地方，期望指正

参考文献

• 【设计权限系统】ACL, DAC, MAC, RBAC, ABAC模型的不同应用场景
• Authorization Models: ACL, DAC, MAC, RBAC, ABAC
• ABAC – 基于属性的访问控制 – 复杂场景下访问控制解决之道
• Attribute-based access control