1、权限管理概述：为什么需要权限系统，常见权限模型对比

大家好，我是老张。干了十来年后端和系统架构，今天咱们来聊聊权限这事儿。

说来也巧，我参与过的项目里，十有八九都栽过权限的坑。不是用户能看到不该看的报表，就是离职员工的账号过了仨月还能登录后台。你说尴尬不尴尬？

所以，第一节课咱们先把底子打好。搞清楚：权限系统到底在解决什么问题？又有哪些主流玩法？

1.1 为什么需要权限系统

说白了，权限系统的核心目标就一个：确保正确的人，在正确的时间，用正确的方式，访问正确的资源。

你想想看，一个没有任何权限控制的系统，会是什么样子？

• 安全风险：实习生能删生产库，竞争对手能看核心代码。
• 数据泄露：HR能看到全公司的工资条，财务能查到每个人的银行流水。
• 合规问题：GDPR、等保2.0、SOX审计，哪条都过不去。
• 运维噩梦：每次有人离职，运维就得手动改十几个系统的账号，改漏一个就完蛋。

我在一个金融项目里遇到过这种情况：第一版没上权限，结果上线当天就被风控团队投诉了——普通客服能看到VIP客户的交易明细。嗯，那天的上线会开了四个小时。

所以，权限系统不是“有了更好”，而是“必须有”。它是一个系统的安全地基，地基不稳，楼上盖得再漂亮也没用。

1.2 常见权限模型对比

目前业界主流的权限模型有四种：DAC、MAC、RBAC、ABAC。我一个个给你拆开讲。

1.2.1 DAC（自主访问控制）

顾名思义，资源的所有者说了算。你是文件的主人，你可以决定谁读、谁写、谁执行。

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

优点：简单灵活，谁创建谁管理。

缺点：权限分散，容易出现“权限泛滥”。比如A把自己的文件分享给B，B再分享给C……最后谁有权限，鬼知道。

我在一个小团队项目里用过DAC，结果半年后，一个离职员工的私人目录里，躺满了全公司共享的文档。那叫一个乱。

1.2.2 MAC（强制访问控制）

系统说了算。给每个主体（用户、进程）和客体（文件、数据库）都打个标签（比如“绝密”“机密”“公开”），然后由系统统一判断能不能访问。

典型代表：SELinux、国家安全等级保护。

优点：安全性极高，用户没法乱改权限。

缺点：配置复杂，灵活性差，不适合频繁变动的业务场景。

说实话，我只有在做军工和政府项目时才用MAC。你想想看，一个普通员工想临时分享个文件给同事，都得走审批流程——效率确实低。

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

这是目前应用最广、最成熟的模型。核心思路是：用户通过角色来获得权限。

• 用户：具体的人。
• 角色：一组权限的集合（比如“管理员”“编辑”“审核员”）。
• 权限：对资源的具体操作（比如“创建订单”“查看报表”）。

用户 <-> 角色 <-> 权限，三层关系，清晰明了。

优点：

• 管理简单：给用户分配角色即可，不用一个个配权限。
• 易于审计：谁是什么角色，一目了然。
• 可扩展：加一个新角色，不影响已有用户。

缺点：

• 角色多了以后，容易产生“角色爆炸”。
• 对于“用户A在部门1是经理，到部门2是员工”这种场景，原生RBAC支持得不好。

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

最灵活、最强大，但也最复杂。它的核心是：根据属性来动态计算权限。

属性分为四类：

• 主体属性：用户年龄、部门、职位、安全等级。
• 客体属性：文件密级、创建时间、所属项目。
• 环境属性：当前时间、IP地址、设备类型。
• 操作属性：读、写、删除、打印。

举个例子：“只允许财务部门的员工，在9:00-18:00之间，用公司内网，查看自己部门的财务报表。”——这就是ABAC的典型策略。

优点：

• 极度灵活，能表达复杂的业务规则。
• 无需预定义大量角色，策略是动态计算出来的。

缺点：

• 策略编写复杂，维护成本高。
• 每次判断都要跑规则引擎，性能开销大。
• 审计困难——因为权限是“算出来”的，不是“配出来”的。

1.3 模型对比总览

为了让你一目了然，我把四个模型的核心差异整理成了一张表：

模型	核心机制	灵活性	安全性	管理成本	典型场景
DAC	资源所有者自主决定	高	低	低（但易失控）	文件共享、个人云盘
MAC	系统强制标签控制	极低	极高	高	军事、政府、涉密系统
RBAC	用户-角色-权限三层	中	中高	低	企业管理后台、SaaS平台
ABAC	基于属性动态计算	极高	高	极高	金融风控、医疗数据共享

看完这张表，你应该能感觉到：没有银弹。每个模型都有自己的适用场景。

1.4 我的选择建议

我在多个项目中做过权限架构选型，总结出一个小经验：

为什么？因为RBAC在“管理成本”和“灵活性”之间取得了最好的平衡。你想想看，一个普通的企业后台，有几十个角色、几百个权限点，用RBAC可以管得清清楚楚。

但如果你要做一个多租户的SaaS平台，每个客户需要定制自己内部的“子角色”和“数据隔离”——这时候纯RBAC就不够用了。我一般会在RBAC里嵌入“数据权限维度”（比如只看本部门、只看自己创建的），再加一点ABAC的属性判断（比如时间、IP），这样又简单又灵活。

1.5 权限模型演化关系图

下面的图展示了四种模型的演进脉络，以及我们这门课的核心落点——双人审批与RBAC的融合在整个权限体系中的位置：

1.6 本章小结

• 权限系统是安全的基石，不是可选项。
• 四种主流模型各有优劣：DAC简单但松散、MAC安全但死板、RBAC中庸但实用、ABAC灵活但复杂。
• 我个人强烈推荐：以RBAC为骨架，辅以ABAC的属性判断，再用双人审批来兜底高风险操作——这也是咱们这门课要讲的核心实践。