关于访问控制，我们接触最多的是操作系统，我们在设计应用的权限系统时多少可以借鉴借鉴。

• 可信操作系统 Trusted OS
• Trusted Computer System Evaluation Criteria 可信计算机系统评估标准（美国国防部）
• 多级别安全 Multilevel Security, MLS

ACL 访问控制表

Access Control List
Access Control Entry, ACE, 访问控制条目

• 资源
• 主体，即操作者（用户，或者用户组）
• 操作

ACM 访问控制矩阵

DAC 自主访问控制

Discretionary Access Control

可以认为是 ACL 的一种实现，但是多了一个自主的概念，表示资源的权限由资源拥有者（或管理者）进行管理。

Linux 中，操作者分成四种：管理员（root），所有者 u，所有组 g，其他 o

MAC 强制访问控制

Mandatory Access Control

PS: Windows Vista 之后引入 Mandatory Integrity Control（强制完整性控制，MIC），可能是类似概念。

强制的意思是权限的管理应该由管理员来负责。

资源拥有一组
在 Linux 系统中，就是美国国家安全局（NSA）开源的 SELinux 安全模块提供 MAC 功能。

PS: Linux 带有一组钩子，叫做 Linux Security Mmodule (LSM)，执行于在 DAC 检查之后，实际操作发生之前。SELinux 就是在这些钩子上注册了一些处理逻辑。

sudo apt install -y selinux-basics
ls -lZ ~/.ssh/config
# -rw-------. 2 catroll catroll system_u:object_r:unlabeled_t:s0 7384 2021-07-27 16:23:04 /home/catroll/.ssh/config

• Subject 主体：操作发起方，某个进程
• Object 客体：操作访问对象，进程、文件、Socket、端口、设备，或别的进程
• Action 操作
• Context 上下文
  • SELinux User
  • SELinux Role
  • SELinux Type
  • SELinux Level (可选)

SELinux 中不管什么 root 用户不 root 用户，都要遵守规则（不过 root 可以修改规则）。
AVC：Access Vector Cache

RBAC 基于角色的访问控制

RBAC 是 MAC 和 DAC 的实现途径。

原则

1. 用户权限来自所属角色
2. 最小权限

概念

• U = User 用户
• R = Role 角色
• P = Permission 权限
• SE = Session 会话
  用户在一次会话中可以激活所有角色，或者角色的一个子集，从而获得一组权限。
• UA = 用户分配 U * R
• PA = 权限分配 P * R
• RH = 角色层次 R * R
  上级权限是所有下级权限的父集

关联

• User -> Session -> Role

• User -> Role -> Permission -> (Operation 操作 + Object 目标)

• 用户和角色多对多

• 角色和权限多对多
• 权限和操作多对多
• 用户和角色之间的约束
• 会话和角色之间的约束

NIST RBAC 模型

A Proposed Standard for Role-Based Access Control, 2000/12/18

1. 核心 RBAC (RBAC0)
2. 分层 RBAC (RBAC1)，支持角色层次
3. 受限 RBAC (RBAC2)：
   1. Separation of Duty (SOD), 职权分离
      • Static Separation of Duties
        角色互斥，比如：禁止用户同时是会计和出纳
      • Dynamic Separation of Duties
        权限判断时，限制关联操作不能由同一个用户完成，比如：禁止用户审核自己提交的申请
   2. 限制：限制用户角色数量或权限数量，限制角色拥有的用户数量
   3. 前置条件：用户需要获得某个角色或权限之前必须拥有另一组角色或权限
4. 统一 RBAC (RBAC3)：
   1. rbac1 + rbac2
   2. 角色的父角色或子角色数量限制
   3. 指定两个角色之间是否可以有共同的父角色或子角色

ARBAC97

https://profsandhu.com/cs5323_s17/arbac97.pdf
https://profsandhu.com/articles/advcom/adv_comp_rbac.pdf
https://www.sis.pitt.edu/jjoshi/ARBAC07.pdf

Administrative RBAC，RBAC 管理模型，相当于 RBAC 的拓展，引入了和常规角色互斥的管理角色。

1. URA: User-Role Assignment
2. RRA: Role-Role Assignment
3. PRA: Permission-Role Assignment

ABAC

基于属性访问控制 Attribute-based, 又被称之为基于策略访问控制 Policy-based, 或基于声明访问控制 Claims-based。

其思路是设置一组策略，包含操作类型和一组相关属性，当有人执行指定操作时，判断当前时刻相关属性是否满足要求。比如判断时间是否正确，判断系统状态是否合适，判断文件的保密级别是否符合。

策略包含来自以下三个方面的属性：

• 用户属性：角色，地区...
• 资源属性：所有者，保密级别，类型...
• 环境属性：访问时间，系统状态...

比 RBAC 灵活性更强，同时也更复杂。可以认为 RBAC 是 ABAC 的一种简单的实现。

思考

ABAC 的思路令人感觉非常棒。只是和 RBAC 一样，在具体实现中，需要考虑使用的可操作性：便捷、易于理解、不容易发生错误。

1. 权限中包含的资源范围
   1. 有时候的实现中，操作权限和资源权限是分开管理的。
2. 前置条件约束：比如说操作顺序
3. 管理方面的约束：
   1. 如果操作权限和资源权限分开管理，如果分配了某一个操作权限，就必须分配相应的资源。
   2. 可能需要参考 ARBAC 中的设计。
4. 用户组的概念
   1. 用户 - 角色之外，增加用户 - 用户组 - 角色的关联。
5. 系统已有的用户管理，比如企业组织结构和 RBAC 中角色的同步。
6. 同一个用户允许多少个 Session 的判断纳入 RBAC 约束中（CreateSession 时处理）。
7. 大多数时候，我们都没有在权限系统中实现 Session 的概念，用户直接拥有其所有所属角色的权限。
8. 其实最麻烦的问题是交付，客户希望权限控制灵活，同时操作简单：
   1. 有时，客户要求用户粒度的权限控制，同时为了管理便捷性（用户数不多，同时不想维护太多角色），保留一个弱化的 Role 概念，实际上 Role 只起到权限模板的作用（应该不能称之为 RBAC 了）：用户设置角色时，将角色的权限全部赋给用户，然后有很多更加复杂的说明，比如角色权限调整了怎么处理，用户角色调整时如何处理。
   2. 还有时，可能为了减少角色维护的工作量，允许直接对用户赋予权限。

参考资料与拓展阅读

• CSDN, 史上最全的权限认证服务的权限模型大全
• Thoughtworks, 分布式系统下的认证与授权
• 掘金，李少博，史上最强的权限系统设计攻略(上)、基础概念、RBAC以及ABAC模型
• 掘金，李少博，史上最强的权限系统设计攻略(下)、ABAC在复杂场景下的实现思路