1、权限管理概述：CRM权限管理的核心价值、常见权限模型对比（DAC/MAC/RBAC/ABAC）、权限设计原则
大家好，我是你们的老朋友。今天咱们正式开讲CRM权限管理。
说实话，做了这么多年SaaS架构，我见过太多系统死在权限设计上。有的上线第一天就崩了，有的被客户骂到改版三次。嗯，权限这东西，看着简单，其实坑特别多。
1.1 CRM权限管理的核心价值
先问大家一个问题：为什么CRM系统一定要做权限管理？
你想想看，一个销售团队里，有老板、销售总监、销售经理、普通销售、还有客服。每个人能看到的数据、能操作的功能，能一样吗？
当然不能。
- 老板要看全公司的销售漏斗，但不需要去录入客户信息
- 销售总监要看到所有团队的业绩，但不能修改下属的客户资料
- 普通销售只能看自己的客户，连同事的客户名单都看不到
- 客服只能查看已成交客户的售后信息，不能碰销售线索
说白了，权限管理的核心价值就三个字：防越权。
核心价值总结：
- 数据安全：防止客户信息泄露，避免销售抢单、撞单
- 职责分离：销售只管卖，客服只管售后，财务只管收款
- 合规审计：谁在什么时间看了什么数据，都能追溯
- 用户体验：只展示用户该看的东西，界面清爽不杂乱
我在项目中遇到过一家公司，上线CRM后不到一周，销售总监发现普通销售能看到全公司的客户名单。结果呢？几个销售私下联系大客户，差点把单子搞黄了。这就是典型的权限设计缺失。
1.2 常见权限模型对比
权限模型有很多种，但真正在CRM里常用的，其实就四种。我一个个说。
1.2.1 DAC（自主访问控制）
DAC是最原始的模型。说白了就是：谁创建的数据，谁说了算。
比如你创建了一个客户，你可以决定让不让别人看。你可以手动分享给同事，也可以设置成公开。
优点：灵活，适合小团队。
缺点：管理成本高，人一多就乱套。
我的经验：DAC只适合10人以下的团队。超过20人，你根本管不过来谁分享了什么数据。我曾经见过一个50人的销售团队用DAC，结果每天光处理权限申请就要花2小时。
1.2.2 MAC（强制访问控制）
MAC和DAC正好相反。数据的安全级别由系统管理员统一设定，用户不能自己改。
比如系统规定：机密客户只有总监以上才能看，普通客户所有销售都能看。用户没有选择权。
优点：安全性极高，适合政府、金融等强合规场景。
缺点：太死板，业务变化时调整困难。
注意：MAC在CRM里用得不多。除非你的客户数据涉及国家安全或商业机密，否则别用。我见过一个CRM项目强行上MAC，结果销售总监想临时给下属开放一个客户权限，流程走了三天，单子早飞了。
1.2.3 RBAC（基于角色的访问控制）
这是目前CRM系统里最主流的模型。核心思想是：用户 -> 角色 -> 权限。
你不需要给每个用户单独分配权限。你只需要定义好角色，比如「销售」、「销售经理」、「客服」，然后把用户丢进角色里就行。
// 伪代码示例：RBAC核心数据结构
Role: {
name: "销售经理",
permissions: [
"customer:read:own", // 查看自己的客户
"customer:read:team", // 查看团队的客户
"customer:write:own", // 编辑自己的客户
"report:read:team" // 查看团队报表
]
}
User: {
name: "张三",
role: "销售经理",
department: "华东销售部"
}优点：管理简单，扩展性好。加一个新员工，分配角色就行。
缺点：粒度不够细。比如「销售经理」这个角色，可能华东和华北的权限需求不一样，但RBAC很难区分。
我建议：90%的CRM系统用RBAC就够了。别一上来就追求高大上的模型，先把RBAC玩明白再说。
1.2.4 ABAC（基于属性的访问控制）
ABAC是RBAC的升级版。它不光看角色，还看用户属性、资源属性、环境属性。
举个例子：
- 用户属性：张三，销售经理，华东区
- 资源属性：客户A，所属华东区，价值100万
- 环境属性：当前时间9:00-18:00，IP在公司内网
权限判断逻辑：如果用户是华东区的销售经理，且客户属于华东区，且在工作时间，且在内网，则允许查看。
// ABAC策略示例（伪代码）
Policy: {
effect: "allow",
condition: {
user.department == resource.department,
user.role == "销售经理",
environment.time between "09:00" and "18:00",
environment.ip in ["192.168.1.0/24"]
}
}优点：极其灵活，能应对复杂业务场景。
缺点：实现复杂，性能开销大，策略多了容易变成「意大利面条」。
避坑指南：我曾经在一个大型CRM项目里用了ABAC，结果策略写了300多条，每次权限判断都要遍历所有策略，性能直接崩了。后来我学乖了：能用RBAC解决的，绝不用ABAC。ABAC只用在那些「非用不可」的边界场景。
1.3 四种模型对比表
| 模型 | 核心思想 | 灵活性 | 安全性 | 管理成本 | 适用场景 |
|---|---|---|---|---|---|
| DAC | 谁创建谁控制 | 高 | 低 | 低（小团队） | 10人以下小团队 |
| MAC | 系统统一控制 | 低 | 极高 | 高 | 政府、金融、军工 |
| RBAC | 用户 -> 角色 -> 权限 | 中 | 中 | 低 | 90%的CRM系统 |
| ABAC | 基于属性动态判断 | 极高 | 高 | 极高 | 复杂业务、多维度控制 |
1.4 权限设计原则
讲完模型，咱们聊聊设计原则。这些是我踩过无数坑之后总结出来的，你直接拿去用就行。
原则一：最小权限原则
每个用户只拥有完成工作所必需的最小权限。多一个都不要给。
比如客服只需要「查看已成交客户」的权限，那就别给他「编辑客户资料」的权限。万一他手滑改了客户手机号，后续销售就联系不上了。
原则二：职责分离原则
关键操作不能由同一个人完成。比如：
- 销售不能自己审批自己的折扣
- 客服不能修改订单金额
- 管理员不能既创建账号又审计日志
原则三：默认拒绝原则
所有权限默认都是拒绝的。只有明确授予的权限才允许。
这个原则特别重要。我见过很多系统默认是「允许所有」，然后靠黑名单来限制。结果漏掉一个黑名单，数据就泄露了。
血的教训：我曾经负责的一个CRM项目，默认权限是「允许所有」。上线后忘了给「实习生」角色加限制，结果实习生能看到全公司的客户数据。虽然没出事，但被客户投诉了。从那以后，我所有项目都强制「默认拒绝」。
原则四：权限与业务逻辑分离
权限判断代码不要散落在业务逻辑里。应该统一封装成权限中间件或权限服务。
// 错误示范：权限判断散落在业务代码中
function updateCustomer(customerId, data) {
if (user.role !== 'admin' && user.role !== 'manager') {
throw new Error('无权限');
}
// ... 业务逻辑
}
// 正确示范：统一权限中间件
function updateCustomer(customerId, data) {
// 业务逻辑里不写权限判断
// ... 业务逻辑
}
// 权限中间件统一处理
app.put('/api/customer/:id', permissionMiddleware('customer:write'), updateCustomer);原则五：可审计原则
所有权限变更和敏感操作都要记录日志。谁、什么时间、做了什么、结果如何，都要能查。
总结一下：
- 小团队用DAC，大团队用RBAC
- 别轻易上ABAC，除非你准备好了应对复杂度
- 默认拒绝，最小权限，职责分离
- 权限代码统一管理，别散落在业务里
好了，第一章就讲到这里。下一章咱们深入RBAC，手把手教你设计一个能支撑百万级用户的CRM权限模型。到时候我会把我在实际项目中踩过的坑、用过的代码，全都掏出来给你看。