一、权限模型概述：从混乱到有序的必经之路

做SaaS的同学，十有八九都被权限问题折磨过。

我记得刚入行那会儿，接手过一个老项目。用户说「我明明有管理员权限，怎么点不了这个按钮？」。查了半天，原来是权限写死在代码里，每个用户一个配置文件。你想想看，几百个用户，几百个文件，改一次权限要翻遍整个系统。

那场面，简直是一场灾难。

所以今天咱们聊聊权限模型。说白了，就是一套规则，告诉系统「谁能做什么，不能做什么」。没有这套规则，你的SaaS系统就是个没锁的门——谁都能进，谁都能翻。

什么是SaaS权限模型？

权限模型，本质上是一套访问控制策略。

它定义了三个核心问题：

• 谁（用户/角色）
• 能对什么（资源/数据）
• 做什么（操作/动作）

举个简单的例子。你公司的CRM系统里，销售能看到客户电话，财务能看到交易金额，但销售不能改价格，财务不能删客户。这就是权限模型在起作用。

在SaaS里，情况更复杂。因为你不是只服务一家公司，而是几十上百家。每家公司的组织架构、岗位职责、数据范围都不一样。所以SaaS权限模型，必须做到多租户隔离和灵活配置。

为什么需要权限模型？

这个问题，我问过不少刚入行的朋友。有人回答「为了安全」，有人回答「为了合规」。都对，但不够全面。

我个人觉得，权限模型解决了三个核心痛点：

1. 安全防护：防止数据泄露和越权操作。我在项目中遇到过，一个实习生不小心删了全公司的客户数据。还好有权限控制，他只能删自己的测试数据。不然那天就得加班恢复了。
2. 职责分离：不同岗位做不同的事。财务不能改订单金额，销售不能看工资条。这是企业运营的基本要求。
3. 合规审计：谁在什么时候做了什么，一查便知。很多行业（金融、医疗）都有强制要求。

常见的权限模型对比

目前主流的权限模型有三种：ACL、RBAC、ABAC。咱们一个一个看。

1. ACL（访问控制列表）

ACL是最原始的方式。简单说就是：给每个资源，列一个清单，写上谁可以访问。

比如一个文件，它的ACL可能是：

• 张三：可读可写
• 李四：只读
• 王五：无权限

听起来很直观对吧？但问题来了——当用户数量上千，资源数量上万时，这个列表会膨胀到无法管理。

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

RBAC是目前最流行的方案。它的核心思想是：不直接给用户授权，而是给角色授权，再把角色分配给用户。

举个例子：

• 定义角色「销售经理」：可以查看所有客户、编辑商机、导出报表
• 定义角色「销售代表」：只能查看自己的客户、创建商机
• 把张三设为「销售经理」，李四设为「销售代表」

这样，改权限只需要改角色，不用一个个改用户。方便多了。

但RBAC也有短板。它处理不了基于属性的动态判断。比如「只允许查看本部门的订单」，RBAC就有点力不从心了。

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

ABAC是更灵活的方案。它不依赖固定的角色，而是根据属性来做判断。

属性分三类：

• 用户属性：部门、职级、地区
• 资源属性：创建者、所属部门、机密等级
• 环境属性：时间、IP地址、设备类型

举个例子，一条ABAC规则可能是：

允许 查看 订单
当 用户.部门 == 订单.所属部门
且 用户.职级 >= "主管"
且 当前时间 在 09:00-18:00 之间

你看，这比RBAC灵活多了。但代价是——配置复杂、性能开销大。

三种模型对比表

维度	ACL	RBAC	ABAC
管理复杂度	高（用户多时爆炸）	中（角色数量可控）	高（规则多时难维护）
灵活性	低	中	高
性能	中（列表查询）	高（缓存友好）	低（需要实时计算）
适用场景	小规模系统	大多数SaaS系统	复杂权限场景
学习成本	低	中	高

我的选择建议

做了这么多年SaaS架构，我个人的经验是：

• 90%的场景，RBAC就够了。别为了炫技搞复杂方案。
• 如果要做多租户，在RBAC基础上加一层「租户隔离」就行。
• 只有遇到动态权限（比如「只能看本部门数据」），才考虑引入ABAC。

好了，这一章就聊到这儿。下一章咱们深入RBAC，看看它在SaaS系统里到底怎么落地。