📚 课程目录第3章权限模型基础

权限模型基础：DAC、MAC、RBAC 与核心术语

说到权限模型，很多人第一反应就是「谁可以访问什么」。但落到工程里，到底怎么控制、控制到什么粒度，这里面门道不少。我早年刚带项目时，也踩过不少坑——比如把用户权限写成硬编码，结果每次新增角色都要改代码。后来才明白，选对权限模型，比写好代码更重要。

这一章我们聚焦三件事：权限模型的来龙去脉、三种主流模型的区别，以及最核心的三个术语——主体、客体、操作。搞懂这些，后面的密钥分发和分级管控才能落地。

为什么权限模型需要演进？

早期的计算机系统很简单。一台机器几个人用，权限靠一张文件表就能管。但后来系统复杂了，用户多了，数据敏感了，原来的方案就不够用了。说白了，权限模型的发展史，就是一部「如何更精细、更安全地控制资源」的历史。

我个人习惯把权限模型分成三个里程碑：DAC（自主访问控制）、MAC（强制访问控制）、RBAC（基于角色的访问控制）。它们不是互相替代，而是在不同场景下各司其职。

DAC——自主访问控制

DAC 是最早出现的模型，也是大家最熟悉的。Linux 的 chmod 755、Windows 的文件共享，都是 DAC 的典型代表。核心思想是：资源的所有者说了算。文件是谁创建的，谁就能决定谁能读、谁能写。

我的经验： 我在项目中遇到过有人把 SSH 私钥文件设成 777 权限，结果被同一台机器上的另一个进程直接读走了。DAC 虽然灵活，但太依赖用户的安全意识。权限下放得太散，就容易出纰漏。

DAC 的优点很明显：实现简单、使用直观。但缺点同样突出——没有全局策略约束。用户 A 可以把文件共享给任何人，系统没法干预。这在多租户或高安全环境下，是致命的。

MAC——强制访问控制

MAC 的出现，就是为了解决 DAC 的「太自由」问题。在 MAC 模型里，系统（而不是用户）决定谁能访问什么。每个主体和客体都被打上安全标签，比如「绝密」「机密」「内部」「公开」。只有标签匹配，才能访问。

我记得在军工项目里，MAC 是强制要求。当时有个开发想绕过级别检查直接读一个「机密」级别的配置文件，被 SELinux 的审计日志当场抓了出来。嗯，这种场景下，MAC 比任何人的自觉都可靠。

注意： MAC 的缺点是管理成本高。标签体系的设计和维护需要专人负责。而且一旦标签打错，可能导致合法用户无法正常工作。我在项目中见过因为标签配置失误，导致整个部门无法访问共享目录的情况。

RBAC——基于角色的访问控制

RBAC 是目前企业系统中最主流的模型。它引入了一个中间层——角色。权限不再直接关联用户，而是关联到角色。用户通过被赋予角色，间接获得权限。

你想想看，一个公司有成百上千员工，如果每个人都要单独配权限，那 IT 部门就不用干别的了。但如果你定义好「管理员」「审计员」「操作员」这几个角色，再把用户往角色里一塞，权限管理瞬间清晰了。

我建议在系统设计初期，就花时间梳理角色矩阵。角色定好了，权限设计就顺了。角色定不好，后面全是补丁。

下面是一个简单的 RBAC 配置示例，用 JSON 表示角色与权限的映射关系：

{
  "roles": {
    "admin": {
      "permissions": ["read", "write", "delete", "manage_users"]
    },
    "auditor": {
      "permissions": ["read", "export_logs"]
    },
    "operator": {
      "permissions": ["read", "write"]
    }
  },
  "users": {
    "alice": { "role": "admin" },
    "bob":   { "role": "auditor" },
    "carol": { "role": "operator" }
  }
}

这样，当业务需求变化时，只需要调整角色对应的权限集合，所有该角色的用户自动生效。不用一个一个改，省心多了。

三种模型的对比

我把 DAC、MAC、RBAC 的核心差异整理成了一张表，方便你对照：

维度	DAC	MAC	RBAC
控制主体	资源所有者	系统/安全管理员	角色管理员
粒度	文件/目录级别	标签级别（绝密/机密/内部）	角色级别
灵活性	高（用户自主决定）	低（系统强制约束）	中（通过角色调整）
安全性	低（依赖用户判断）	高（系统级管控）	中高（集中管理）
管理成本	低	高（标签维护复杂）	中（角色设计需前期投入）
典型场景	个人电脑、小团队	军事、政务、涉密系统	企业 ERP、SaaS、内部系统

  核心观点： 没有万能的权限模型。DAC 适合轻量场景，MAC 适合高安全场景，RBAC 适合大多数企业应用。选型的关键是看你的业务对「灵活性」和「安全性」的平衡要求。

核心术语：主体、客体、操作

无论哪种模型，都离不开三个基本概念。我用一句话概括：谁（主体）对什么（客体）做了什么（操作）。这个口诀，我建议每个团队都记住。

主体（Subject）：发出访问请求的实体。通常是用户、进程、服务账号。在 RBAC 中，角色也可以被视为一种「逻辑主体」。
客体（Object）：被访问的资源。可以是文件、数据库记录、API 接口、硬件设备。一切需要保护的东西，都是客体。
操作（Operation）：主体对客体执行的动作。常见的操作有读、写、执行、删除、导出。不同系统对操作的抽象层级不同。

我曾经在一个项目中，团队成员把「操作」和「权限」混为一谈，结果在设计接口时，把「可读」「可写」直接写死在了代码里。后来要增加「可导出」功能，只能改代码重新上线。其实把操作抽象成独立的枚举，再跟权限策略解耦，就可以避免这种尴尬。

避坑指南： 我建议你在设计权限系统时，先把操作定义清楚。很多项目后期出现权限漏洞，就是因为操作边界模糊。比如「读」和「导出」是不是同一个操作？从安全角度，导出显然风险更大，应该单独控制。

三者关系图解

下面这张图展示了权限模型的演进路径，以及主体、客体、操作三者之间的核心关系。你可以把它当作本章的知识骨架。

从上图可以清楚看到：DAC、MAC、RBAC 是层层演进的，各有侧重。而底部三角关系——主体、操作、客体，是所有权限模型的基础构件。无论未来遇到多复杂的权限系统，最终都可以拆解成这三要素。

应用层面的思考

讲完理论，我想聊聊实际选型。我见过不少团队一开始就用 RBAC，觉得它最「先进」。但问题是，如果你们的系统只有 10 个用户，数据也不敏感，RBAC 反而增加了不必要的复杂度。这时候 DAC 一把 chmod 就搞定了。

反过来，如果你们做的是金融交易系统，操作员、审核员、管理员各司其职，那 RBAC 几乎是唯一选择。角色清晰、审计方便、权限回收也干净。

至于 MAC，说实话，一般企业用不上。但如果你做的产品要过等保三级或更高安全认证，MAC 的标签模型是绕不开的。我曾经在政务云项目里，光是设计安全标签体系就花了两周——从数据分级到标签传播规则，每一级都要跟业务方反复确认。

  一句话总结： 权限模型没有「最好」，只有「最合适」。先搞清楚你的主体是谁、客体是什么、操作有哪些，再根据安全需求和团队规模，选择 DAC、MAC 或 RBAC。

嗯，到这章为止，我们已经把权限模型的基础打牢了。接下来，我会带你看看这些模型在实际系统中怎么落地，尤其是跟密钥分发和加密策略如何结合。别急，一步步来。