System Design 101 权限系统设计指南：ACL、DAC、MAC、ABAC 与 RBAC 全面解析

在设计任何需要多用户、多角色协作的系统时，权限系统（Permission System）都是安全架构的核心组成部分：它决定了"谁能对什么资源做什么操作"。本指南基于 System Design 101 仓库中 权限系统设计一文 展开，系统梳理业界最常见的 5 种访问控制模型——ACL、DAC、MAC、ABAC 与 RBAC，逐一剖析其工作原理、优缺点与适用场景，并结合仓库内 Linux 文件权限、敏感数据管理与安全 API 等配套文档，帮助你快速掌握权限系统设计的选型思路，为系统设计面试与真实业务落地提供可直接复用的决策框架。

为什么需要权限系统

权限系统的本质是授权（Authorization）：在身份认证（Authentication）确认"你是谁"之后，进一步回答"你能做什么"。在仓库的 如何设计安全系统 中，Authorization 被列为安全系统设计的关键设计点之一；而在 敏感数据管理 中则明确指出：为保护敏感数据，应授予用户最小权限（minimal permissions），最常用的做法就是设计基于角色的访问控制（RBAC），确保用户只能访问与其职责相关的信息与资源。

下图所示的 5 种常见方案，覆盖了从最朴素到最精细的访问控制演进路径：

1. ACL（访问控制列表）——直接列出"谁可以访问什么"
2. DAC（自主访问控制）——由资源所有者决定谁能访问
3. MAC（强制访问控制）——由系统通过安全标签统一强制
4. ABAC（基于属性的访问控制）——基于多维属性动态判定
5. RBAC（基于角色的访问控制）——通过角色间接授予权限

下面逐一深入解析。

1. ACL：访问控制列表（Access Control List）

核心思想：ACL 是一份规则列表，逐条指定"哪些用户被授予或拒绝访问某个特定资源"。

资源: /projects/finance/report.pdf
ACL:
  - user:alice        → allow read
  - user:bob          → deny read
  - group:auditors    → allow read, write

优点

• 易于理解：每条规则直白明了，人可以直接阅读和审计。

缺点

• 易出错（error-prone）：当用户、资源数量增长后，条目爆炸式膨胀，容易出现规则冲突、遗漏或冗余。
• 维护成本高（maintenance cost is high）：每个资源都要单独维护一份列表，新增用户或调整权限需要在大量资源上同步修改。

典型应用与仓库佐证

ACL 是最早被广泛采用的模型之一。在仓库的 25 篇改变计算机世界的论文 中提到了 Google 的 Zanzibar——一个全球规模的、用于管理 ACL 的系统，可见 ACL 即使在大型分布式系统中依然具有重要的工程地位。此外，云存储服务（如对象存储的 Bucket 策略）、网络设备（防火墙规则）也都是 ACL 的经典应用场景。

2. DAC：自主访问控制（Discretionary Access Control）

核心思想：DAC 建立在 ACL 之上，但授予/限制对象访问权限的决策权下放给资源的拥有者或拥有者组，由他们通过访问策略自行决定。

优点

• 简单灵活（Easy and flexible）：资源所有者可以随时决定把文件分享给谁。
• Linux 文件系统就是 DAC 的典型实现：每个文件/目录都有 Owner（创建者）、Group（用户组）和 Other（其他用户）三类主体，分别配置读（r）、写（w）、执行（x）权限。仓库中的 Linux 文件权限图解 对这一机制做了详细讲解。

缺点

• 权限控制分散（Scattered permission control）：权限分散在每个资源所有者手中，组织层面难以统一审计和管控。
• 资源拥有者组权力过大（too much power for the object's owner group）：拥有者可以随意分享资源，容易造成越权传播，违反最小权限原则。

应用提示

DAC 适合个人文件管理、小型协作等信任半径较小的场景；但在企业级系统中，分散的权限决策往往需要额外的合规审计机制来兜底。

3. MAC：强制访问控制（Mandatory Access Control）

核心思想：在 MAC 中，资源所有者和资源本身都被打上分类标签（classification labels），不同标签对应不同级别的权限，由系统统一强制执行，资源所有者无权自行更改。

典型的标签体系如：

• 机密等级：公开（Public）→ 内部（Internal）→ 机密（Confidential）→ 绝密（Top Secret）
• 安全域 / 部门标签：财务、研发、人事……

只有主体标签满足资源标签要求的操作才会被放行，例如"绝密"文档只允许"绝密"级别的主体读取。

优点

• 严格且直接（strict and straightforward）：规则集中、清晰，一旦定义便不可绕过，安全性高，天然适合处理高度敏感的数据。

缺点

• 不灵活（not flexible）：标签体系粒度粗、难以覆盖复杂多变的企业协作需求，且实现和运维成本高。

典型应用

MAC 常见于军事、政府等高机密领域；在 Linux 生态中，SELinux、AppArmor 等安全模块也体现了 MAC 的思路——即使进程所有者想执行某操作，只要系统安全策略不允许就会被强制拦截。

4. ABAC：基于属性的访问控制（Attribute-based Access Control）

核心思想：ABAC 基于四类属性综合评估权限：

属性维度	说明	示例
资源所有者属性（Resource owner）	提出访问请求的主体特征	部门=财务、职级=经理、地点=北京
动作属性（Action）	要执行的操作	读取、写入、删除、导出
资源属性（Resource）	被访问对象的特征	数据敏感级别、所属项目、创建时间
环境属性（Environment）	当前访问环境	时间、IP、设备、网络是否安全

策略示例：
允许 读取 财务报表
当且仅当
  请求者.部门 = "财务" 且
  请求者.职级 in ("经理","总监") 且
  资源.敏感级别 = "内部" 且
  环境.工作时间 in (09:00-18:00) 且
  环境.网络 = "公司内网"

优点

• 灵活（flexible）：可以表达"部门 + 职级 + 时间 + 地点"这样细粒度的动态策略，是 5 种模型中最富表达力的一种。

缺点

• 规则复杂（the rules can be complicated）：策略语句增多后，规则之间的组合、冲突排查都变得困难。
• 实现困难（implementation is hard）：需要策略引擎、属性解析、规则评估等配套能力。
• 使用并不普遍（not commonly used）：由于复杂度和工程成本，ABAC 在实际业务系统中应用比例相对较低，通常只在大型复杂组织或合规要求极高的场景中采用。

5. RBAC：基于角色的访问控制（Role-based Access Control）

核心思想：RBAC 通过角色来间接评估权限——不直接给用户分配权限，而是给角色分配权限，再把角色授予用户。

角色: 财务分析师
  权限: report:read, report:export, dashboard:view

用户: alice → 角色: 财务分析师
用户: bob   → 角色: 财务分析师, 审计员

优点

• 角色分配灵活（flexible in assigning roles）：用户与角色、角色与权限解耦，新增员工只需挂接角色，调整权限只需修改角色定义，管理成本远低于 ACL。
• 符合最小权限原则：可以按岗位职责精确设计角色边界。

仓库佐证与生态位

RBAC 是当前企业应用中最主流的权限模型。仓库中多处文档都印证了这一点：

• 敏感数据管理 明确指出：为保护敏感数据应授予最小权限，最常采用的设计就是 RBAC，它简化了用户权限管理，确保用户只能访问其角色所必需的信息和资源。
• 安全 API 构建速查表 将"使用基于角色的访问控制（RBAC）"列为 API 安全策略之一：RBAC 简化了 API 的访问管理，并基于角色对用户权限进行细粒度控制，降低了未授权操作的风险。
• 在微服务架构中，生产级微服务应用的 9 大组件 提到，身份与访问控制（identity and access control）通常借助 Keycloak、Azure AD、Okta 等身份管理工具实现——这些工具的核心授权模型正是 RBAC 及其扩展。

5 种模型横向对比与选型建议

模型	决策依据	优点	缺点	典型场景
ACL	用户 ↔ 资源 直接绑定	易于理解	易出错、维护成本高	对象存储策略、防火墙规则
DAC	资源所有者决策	简单灵活，Linux 文件系统支持	权限分散，所有者组权力过大	个人文件分享、Linux 权限
MAC	系统强制的分类标签	严格、直接	不灵活	军事/政府高机密系统
ABAC	主体/动作/资源/环境属性	高度灵活、细粒度	规则复杂、实现困难、使用不普遍	大型组织复杂合规场景
RBAC	用户 ↔ 角色 ↔ 权限	角色分配灵活、易管理	对"数据级/属性级"细粒度控制不足	企业应用、API 授权、微服务 IAM

选型思路（基于仓库文档的综合建议）：

1. 优先考虑 RBAC：绝大多数企业级 Web 应用、API 服务和微服务系统，RBAC 都是默认首选——它兼顾了管理便利性与安全性，仓库多篇文档（敏感数据管理、安全 API 构建速查表）均以此作为推荐实践。
2. 需要动态细粒度控制时升级 ABAC：当出现"同角色不同部门、不同时间的权限差异"这类需求，可在 RBAC 基础上引入属性策略，形成 RBAC + ABAC 的组合方案。
3. 高机密环境选择 MAC：对数据分级有强制合规要求的场景，MAC 的不可绕过性更有保障。
4. 避免滥用 ACL：除非资源规模和用户规模都很小，否则 ACL 的维护成本会随规模快速增长。

权限系统与其他安全机制的配合

在真实系统中，权限模型并不是孤立存在的，它与认证、会话与访问令牌等机制协同工作：

• 认证先行：权限判断的前提是确认用户身份。仓库的 OAuth 2.0 详解 指出，OAuth 令牌代表用户的身份与权限，可支持单点登录（SSO）与跨系统授权共享；JWT 101 也说明了 JWT 在认证与授权中的典型用法。
• 权限下沉到 API 层：在 安全 API 构建速查表 中，认证/授权与 RBAC 并列为核心安全措施，配合 HTTPS、限流、输入校验与监控，共同构成 API 的纵深防御。
• 配合数据保护策略：在 敏感数据管理 中，最小权限原则（最小化授权）、RBAC、加密与密钥管理、数据脱敏和生命周期管理共同构成完整的数据安全方案，其中权限模型正是"谁能接触敏感数据"的第一道闸门。

小结

五种权限模型各有其适用边界：ACL 直观但难以规模化；DAC 灵活但控制分散；MAC 严格但不灵活；ABAC 表达力最强但工程复杂度最高；RBAC 则凭借"角色"这一恰到好处的抽象，成为企业系统的事实标准。理解它们的工作机制与权衡（trade-off），是设计安全、可维护系统的基础能力，也是系统设计面试中"安全与授权"环节的高频考点。建议读者结合仓库中的 Linux 文件权限图解（DAC 实例）、敏感数据管理（RBAC 实战）与 安全系统设计（安全全景）继续深入，构建完整的访问控制知识体系。