1. DAC（Discretionary Access Control）
自主访问控制
核心特点：
- 资源拥有者决定权限：用户对其拥有的资源（如文件）有控制权，可以授予或撤销他人的访问权限。
- 权限可继承/传播：被授权的用户可以继续把权限授予其他用户（这可能导致“权限扩散”）。
举例：
- 用户 A 拥有一个文件
file.txt，他设置权限让用户 B 也能读取它。 - 用户 B 如果有权，也可以把这个文件分享给用户 C。
类似系统：
- 类 Unix 的系统默认使用 DAC，通过
chmod、chown控制文件权限。
2. MAC（Mandatory Access Control）
强制访问控制
核心特点：
- 系统控制访问权限：用户无权修改自己的资源权限，所有访问规则由系统策略统一定义。
- 基于安全标签（level）：对象（资源）和主体（用户）都有安全级别，比如“机密”、“受限”、“公开”，系统强制根据这些级别控制访问。
举例：
- 一个“秘密”级别的文件只有“秘密”级别或更高级别的用户才能访问，不能随意共享。
- 用户即使拥有文件，也无法更改其访问权限。
类似系统：
- SELinux（Security-Enhanced Linux）
- AppArmor（Ubuntu 上使用）
这些系统就使用了 MAC 模型。
3. RBAC（Role-Based Access Control）
基于角色的访问控制
核心特点：
- 以“角色”为中心：权限分配给“角色”，用户根据其角色获得权限。
- 灵活、集中管理：适合组织结构复杂、职责分明的环境。
举例：
- 角色“管理员”拥有系统配置权限；角色“用户”只能读写自己的数据。
- 用户 A 被分配为“管理员”，系统自动赋予所有“管理员”权限。
类似系统：
- 多数企业应用和身份管理系统（如 Active Directory、Kubernetes、数据库权限管理）使用 RBAC。
4. TBAC（Task-Based Access Control）
基于任务的访问控制
核心特点：
- 权限与具体任务绑定，而不是与用户或角色绑定。
- 用户只有在执行某个“已授权任务”时，才能获得所需权限。
- 强调“动态激活权限”，避免静态分配带来的过度权限问题。
举例：
- 某人是“医生”角色，但只有在处理某个病人的病历任务时，才能访问该病历。
- 执行完任务后，权限自动撤销。
应用场景：
- 工作流系统、审批系统、临时授权操作（如 DevOps 自动化脚本）
5. OBAC（Object-Based Access Control）
基于对象的访问控制
核心特点：
- 访问控制依赖对象本身的属性和策略。
- 不看用户或角色，看“对象是否允许某类用户访问”。
举例：
- 一个文件设置了“仅允许创建者和其直属上级访问”，访问控制规则写在对象的元数据或策略中。
- 不依赖用户的角色或任务，只要对象规则允许，就能访问。
应用场景：
- 微服务架构、面向对象系统、基于资源策略的授权系统（如某些云平台）
总结对比表：
| 模型 | 控制基础 | 权限分配方式 | 粒度 | 动态性 | 上下文感知 | 安全性 | 灵活性 | 常见场景/系统 |
|---|---|---|---|---|---|---|---|---|
| DAC | 用户（资源拥有者） | 手动分配 | 中 | 静态 | 低 | 低 | 高 | Unix/Linux 文件系统、用户共享 |
| MAC | 系统策略/安全标签 | 统一策略控制 | 高 | 静态 | 中 | 很高 | 低 | SELinux、军事系统、政府保密系统 |
| RBAC | 用户角色 | 基于角色分配 | 中 | 静态 | 中 | 高 | 中 | 企业权限管理、数据库、Kubernetes |
| TBAC | 当前执行任务 | 任务自动授权 | 高 | 动态 | 高 | 高 | 中 | 工作流系统、临时任务授权、自动化系统 |
| OBAC | 对象自身策略 | 对象定义控制策略 | 非常高 | 动态或静态 | 高 | 高 | 高 | 云服务（如 AWS IAM）、微服务资源管理 |
