第三章 角色设计三原则与实战误区
角色设计说起来简单，做起来全是坑。我带过好几个项目，每次做RBAC设计复盘，翻来覆去绕不开三个词：最小权限、职责分离、角色粒度。今天我把这三个原则掰开了讲，再聊点我踩过的坑——保你有共鸣。
3.1 最小权限原则
最小权限，说白了就是“够用就好”。我给用户的权限，不多一分，不少一毫。你想想看，一个只查报表的运营人员，你给他一个“超级管理员”角色，那不等于把公司大门钥匙交给快递小哥？
我在项目中遇到过一种情况：运维团队图省事，给所有开发人员都开了服务器的sudo权限。理由是“开发调试方便”。结果有一次，新来的同事误操作rm -rf /，把生产环境半个目录删了——好在有备份，但恢复花了整整一上午。从那以后，我坚持在权限申请流程里加一条：每个权限必须写明“最低网络路径+最小数据范围”。
1. 这个角色真的需要这个操作吗？
2. 能不能用只读或部分功能代替？
3. 如果权限被滥用，后果是什么？
3.2 职责分离原则
职责分离（SoD）防止一个人同时拥有冲突权限。比如，谁也不能既提交付款申请又审批付款申请——这是基本常识。但在密钥管理场景里，职责分离更微妙。
我记得有一次审计一家金融科技公司，他们的人事系统和密钥管理系统共用同一个“管理员”角色。也就是说，人事专员可以给自己加薪后，再用同一个账号去轮换密钥——这听起来像天方夜谭，但确实发生了。为什么？因为他们把“系统管理员”和“安全管理员”合并成一个角色了。
| 冲突权限对 | 典型场景 | 风险等级 |
|---|---|---|
| 密钥生成 + 密钥轮换 | 一个人可以创建新密钥并自动替换旧密钥 | 高 |
| 权限审批 + 权限授予 | 自己审批自己的权限提升申请 | 高 |
| 日志查看 + 日志删除 | 可以销毁操作痕迹 | 极高 |
| 用户创建 + 角色分配 | 可以创建僵尸账号并赋予管理员权限 | 极高 |
3.3 角色粒度控制
角色粒度，就是角色拆得有多细。太粗了，权限失控；太细了，管理成本爆炸。你的目标是在“可控”和“可维护”之间找平衡。
我个人习惯把角色分为三层：
- 基础层： 按职能划分，如“开发人员”、“测试人员”、“运维人员”。这些角色权限相对固定。
- 业务层： 按项目或环境划分，如“项目A-只读”、“项目B-部署”。这些角色由项目负责人自管理。
- 临时层： 按时间或事件划分，如“应急响应-24小时”、“数据导出-一次”。这些角色到期自动回收。
我见过最糟糕的粒度失控案例：一个公司有 120 个自定义角色，很多角色之间只有一两项权限差异。你想想看，每次变更都要调整几十个角色，最后索性全扔给“超级管理员”角色——那RBAC等于形同虚设。
3.4 实战常见误区
下面这几个误区，我几乎在每次审计里都能撞见。咱们一个个说。
误区一：角色命名混乱
“admin”、“administrator”、“super_admin”、“sysadmin”——你分得清谁是谁吗？我在一个客户系统里发现“readonly”角色居然有写权限，就因为名字叫“readonly”但实际配置错了。命名必须规范，并且要和实际权限严格绑定。
误区二：角色继承滥用
很多RBAC框架支持角色继承（子角色继承父角色权限）。看起来省事，但一不留神就变成权限爆炸。我曾经碰到一个子角色继承了三个父角色，而这三个父角色各自又继承了两个爷爷角色。结果子角色的权限比预想的大了十倍。你想想看，审计的时候怎么查？
误区三：权限永久绑定
“入职的时候申请了，就一直保留着”——这太常见了。员工转岗、外包人员离职，权限却没人去清理。我建议每季度做一次“权限瘦身”：导出现有角色-用户映射表，逐项确认是否仍然需要。
误区四：忽略默认角色
很多系统有“默认角色”，比如新用户自动赋予“member”角色。但默认角色的权限集常常是拍脑袋配的——要么太大（所有人都能看敏感数据），要么太小（连基本功能都用不了）。审计时这个坑容易被跳过。
3.5 角色设计的核心流程
下面这张图是我自己梳理的角色设计流程，在项目里用着挺顺的。你可以参考：
3.6 小结
角色设计不是一次性工作。你上线了、跑起来了，还得持续审计。我自己的习惯是每次密钥轮换同步做一次角色权限复审——这两个动作绑定在一起，不容易被遗忘。