📚 课程目录第1章权限模型概述

1. 权限模型概述

1.1 什么是权限模型

聊权限模型之前，我先问你一个问题：你负责的系统里，一个普通用户能看见其他用户的隐私数据吗？如果你的答案是"不能"，那背后一定有一套规则在起作用。这套规则，说白了就是权限模型。

我个人习惯把权限模型拆成三个要素：谁（主体）、能干什么（操作）、在哪儿干（资源）。你想想看，现实世界里所有权限问题，最后都能归到这三点上。

主体：用户、服务账号、设备……只要是发起请求的，都算主体。
操作：读、写、删、执行、审批……具体能做什么动作。
资源：文件、数据库记录、API 接口、页面菜单……被访问的对象。

核心公式：权限 = 主体 + 操作 + 资源。一个请求能不能通过，就看这三个维度是否匹配。

举个例子。你在公司用钉钉查自己的工资条，主体是"你"，操作是"查看"，资源是"工资记录"。系统一查：嗯，这条记录的所有者是你，允许通过。就是这么个逻辑。

1.2 为什么需要权限模型

你可能会想：我不搞这套理论，直接 if-else 硬编码行不行？行，但只能撑到项目上线那天。

我在项目里遇到过真实案例：早期一个后台管理系统，权限直接用一堆 if 判断写在控制器里。刚开始就 10 个用户，没问题。后来用户涨到 500，角色多了七八种，那段代码已经没人敢改了——改一个条件，不知道会炸掉哪个功能。

权限模型要解决的，其实是三个层次的问题：

安全：防止越权操作。数据泄露、删库跑路，多半是权限没控住。
合规：等保、GDPR、SOX……监管要求你必须有清晰的权限审计链路。
可维护：新增一个角色或调整权限时，改一行配置就行，而不是翻遍所有代码。

注意：没有权限模型的系统，就像把公司大门的钥匙交给每个员工。短期看效率高，长期看风险巨大。我见过因此被客户审计卡住导致丢单的项目，嗯，真的很痛。

1.3 常见权限模型对比

业界经过多年实践，沉淀出了四种主流模型。每种模型都有它的出身背景和适用场景。下面我逐一跟你聊聊。

DAC（自主访问控制）

DAC 的核心思想是"我的东西我做主"。谁创建了资源，谁就拥有它的管理权。你可以自由地把读权限给张三，写权限给李四。

典型代表：Linux 文件权限（rwx）、Windows 文件共享。

优点：灵活、直观，小团队用起来很顺手。

缺点：权限分散，难以全局管控。用户 A 可以把文件分享给用户 B，B 再分享给 C，最后你根本不知道谁有权限。

MAC（强制访问控制）

MAC 跟 DAC 正相反——权限由系统统一管控，用户不能转让。每个主体和资源都被打上安全标签（比如"绝密""机密""公开"），系统根据标签规则决定是否放行。

典型代表： SELinux、军事/政府信息系统。

优点：安全性极高，无法绕过。

缺点：灵活性差，配置复杂。你想想，给每个文件打标签，给每个用户定密级，运维成本不低。

RBAC（基于角色的访问控制）

RBAC 是目前应用最广的模型。它引入"角色"作为中间层——你把权限赋给角色，再把角色赋给用户。这样一来，用户和权限就解耦了。

# 一个典型的 RBAC 配置示例
roles:
  admin:
    permissions: ["user.*", "order.*", "report.*"]
  editor:
    permissions: ["user.read", "order.edit", "report.read"]
  viewer:
    permissions: ["user.read", "order.read", "report.read"]

# 用户关联角色
users:
  - name: "张三"
    role: "admin"
  - name: "李四"
    role: "editor"

优点：管理简单，扩展性好。加一个新用户，只需要分配一个角色就行。

缺点：当角色和权限都变得很多时，容易发生"角色爆炸"——你可能需要几十个角色才能覆盖所有场景。

ABAC（基于属性的访问控制）

ABAC 不再依赖角色这种固定概念，而是根据主体、资源、环境的多维属性动态判定。比如：你是"销售部"的员工，在"工作时间"访问"本部门的季度报表"，允许通过。

// ABAC 策略示例（伪代码）
if user.department == resource.department:
    allow("read")
if user.role == "manager" and resource.type == "report" and env.time in business_hours:
    allow("write")

优点：细粒度极高，能应对非常复杂的权限场景。

缺点：策略编写和维护难度大，性能开销也高。每次请求都要运算一堆规则。

下面这张图可以帮你快速建立四种模型的全局印象：

上面这张图把四种模型的核心思想、典型场景和适用建议串到了一起。你可以把它当作一个快速参考框架。

为了让你更直观地对比它们的差异，我还整理了一张表格：

模型	控制粒度	管理复杂度	灵活性	安全性	适用规模
DAC	资源级	低	高	低	小团队 / 个人
MAC	标签级	高	低	极高	政府 / 军事
RBAC	角色级	中	中	中高	企业 / 平台
ABAC	属性级	高	极高	高	云 / 微服务

1.4 如何选择适合的权限模型

讲完理论，你肯定想问：那我到底该用哪个？

我的建议是——不要一步到位，也别拍脑袋选。我在多个项目中总结了一条经验：先看业务复杂度，再选模型。

业务角色少于 5 个，用户少于 50：DAC 完全够用，别过度设计。比如一个内部小工具，用文件权限或简单的用户-资源映射就行。
有严格的合规或安全要求：考虑 MAC。比如金融交易系统、政务系统，数据安全是第一优先级。
大部分企业应用：RBAC 是首选。我做过好几个后台系统，RBAC 配合菜单权限和数据权限，能覆盖 90% 的场景。
多租户、动态策略、物联网：ABAC 或者 RBAC + ABAC 混合。比如云平台的资源访问控制，用户的部门、项目、时间、地点都在变，用属性判定最合适。

实战技巧：如果你不确定选哪个，从 RBAC 起步，预留 ABAC 的扩展接口。大多数项目走到后期，都会发现需要在某些细节点上引入属性策略。这样做既不会一开始就陷入复杂度，又保留了演进空间。

曾经有个创业团队找我咨询，他们做一个 SaaS 平台，初期用户类型只有"管理员"和"普通用户"，直接用 RBAC 搞定。后来业务扩张，出现了"区域经理"、"渠道伙伴"、"审计员"等十几种角色，还要求按地区、按时间段控制数据可见性。幸好当初预留了 ABAC 的策略引擎，没有重构，只加了几条属性规则就搞定了。

嗯，回头看，好的架构设计就是在"当下够用"和"未来可扩展"之间找平衡。权限模型的选择，说到底也是这个道理。