1. 权限模型概述

先聊聊「权限」这俩字到底在说什么。

说白了，就是「谁能对什么东西做什么」。你想想看，一个系统里如果没有权限控制，那基本就是门大开——谁都能进来翻箱倒柜。我早年做过一个内部OA，初期为了赶工压根没上权限，结果行政部的同事不小心删了财务部的报表……嗯，那天晚上整个团队都在回滚数据库。从那以后，我再也不敢轻视权限设计。

什么是权限模型

权限模型，是一套规则、结构和算法的集合。它定义了用户、资源、操作之间的映射关系。用大白话说：它告诉你张三能看到哪些菜单，李四能不能修改这条数据，王五能不能删掉那个文件。

模型本身不写死逻辑，它提供一套抽象框架。具体的权限判断，由模型背后的策略引擎执行。我习惯把权限模型比作「交通规则」——红灯停、绿灯行，谁违反了就扣分。只不过这里的「分」是你能访问的数据。

为什么需要权限模型

没有模型的权限，就是一堆散乱的 if-else 判读。你可能会问：「把用户角色写死在数据库里不就行了？」行是行，但维护成本会指数级飙升。

我接手过一个遗留系统，里面权限逻辑散落在30多个Service方法里，每个方法前面都要写一长串 user.getRole() == "admin" 。加一个新角色？改遍所有 Service。加一个菜单权限？得动 SQL。最后那个项目直接重构了，换成 RBAC。

总结一下，我需要权限模型的几个理由：

1. 可维护性：策略集中，改一处就行，不用满世界查代码。
2. 可审计性：有模型就有日志、有规则，安全审计能追溯到「谁在什么时间用哪条规则做了什么」。
3. 可扩展性：业务变了，加个角色、加个属性，模型骨架不用推倒重来。
4. 安全性：经过数学验证的模型（比如RBAC的职责分离约束）能堵住很多人为漏洞。

常见权限模型简介

业界最常见的四种模型：DAC、MAC、RBAC、ABAC。它们各有适用场景，没有银弹。我当年刚入行时以为自己懂了RBAC就够用了，直到遇到一个多租户SaaS系统……嗯，ABAC才真正解决问题。

模型	全称	控制方式	典型场景
DAC	自主访问控制	资源所有者决定谁可以访问	文件系统（Linux chmod）
MAC	强制访问控制	系统根据安全标签强制控制	军事系统、政府机密
RBAC	基于角色的访问控制	角色作为主体与权限的中间层	企业管理系统、ERP
ABAC	基于属性的访问控制	根据用户、资源、环境属性动态判断	云平台、微服务、物联网

DAC（自主访问控制）

最原始的模型。资源的所有者自己说了算——「这个文件我想让小明读，就让小明读」。Linux里的 chmod 就是典型。它的优点是简单，缺点是权限容易被滥用。我记得有个同事不小心把项目根目录设成 777，结果CI流程被串改……还好发现的早。

MAC（强制访问控制）

系统强制分级。每个用户和每个资源都有一个安全级别（比如机密、秘密、绝密），系统根据级别自动判断。用户自己没法改。这种模型在军工、政府和金融行业很常见。我说实话，做纯商业项目基本用不到MAC，但如果你接触过数据库的强制访问控制（比如Oracle Label Security），会感觉它真的很严格——甚至有点死板。

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

最通用的工业标准。它引入「角色」这个中间层：用户属于角色，角色拥有权限。你别说，90%的企业级系统用RBAC就够了。我做过一个医疗HIS系统，用户有医生、护士、药剂师、管理员、病人五种角色，每个角色权限范围明确。改权限只改角色，不用一个个改用户。

RBAC还支持角色继承、角色层级和职责分离（比如一个人不能同时有「订单审批」和「订单创建」两个角色）。这些特性在NIST标准里都有定义。

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

进阶级模型。它不依赖固定角色，而是根据一堆「属性」组合判断。比如：

• 用户属性：部门、职级、部门ID
• 资源属性：数据归属、数据标签
• 环境属性：时间、IP、设备
• 操作属性：读、写、批量

规则引擎会评估类似「用户.部门 == 资源.部门 && 当前时间在 9:00-18:00 && 用户.职级 >= '高级'」这样的条件。ABAC 非常灵活，但也最复杂。我建议你在微服务架构或SaaS多租户场景下才考虑它，别为了炫技硬上。

上面这张图大致展示了四种模型的关系。注意，它们不是完全互斥的——实际项目中，你可能会用 RBAC 做主体框架，再混入 ABAC 做细粒度判断。我做过的一个电商平台就是这样：90%的权限用角色控制，剩下敏感的退款金额判断则用属性策略。