📚 课程目录第4章静态职责分离（SSD）

4. 静态职责分离（SSD）：定义互斥角色，预防利益冲突

咱们继续聊RBAC落地中的硬骨头——静态职责分离，简称SSD。

说白了，SSD就是一套规则，用来规定“哪些角色不能同时给一个人”。

为什么要搞这个？我举一个最经典的例子：采购和验收。

如果一个人又管采购又管验收，那他完全可以自己买一批次品回来，然后自己签字说“货没问题”。公司资产就这么流失了。SSD要做的，就是通过系统强约束，从根源上杜绝这种利益冲突。

4.1 什么是静态职责分离？

SSD的全称是Static Separation of Duty。它和动态职责分离（DSD）最大的区别在于：

SSD：在角色授权阶段就进行检查。比如你要给用户A分配“采购员”和“验收员”两个角色，系统直接拒绝，因为这两个角色被定义为互斥。
DSD：允许用户同时拥有两个角色，但在执行某个敏感操作时，禁止用户同时使用这两个角色的权限。这个后面章节会讲。

SSD是静态的，所以它更严格。配置好之后，连分配都分配不了，彻底断了念想。

核心原则：SSD规则一旦生效，任何用户不得同时拥有互斥角色中的任意两个或以上。

4.2 常见的互斥场景

我在项目中见过很多SSD配置不当的案例。下面几个是高频场景：

业务领域	互斥角色对	冲突原因
财务	会计 / 出纳 / 审计	防止账目造假、资金挪用
采购	采购员 / 验收员 / 付款审批	防止虚假采购、质量掺水
IT运维	系统管理员 / 安全审计员	防止管理员删除审计日志
电商	商品上架审核 / 商品发布	防止未经审核的商品上线
合同管理	合同起草 / 合同审批	防止自写自批

嗯，这里要注意：不是所有角色都能随便配成互斥。配太死了，业务流程可能卡住；配太松了，又等于没配。这个度需要业务专家和审计一起定。

4.3 配置方式

在成熟的RBAC系统中，SSD通常通过互斥角色集来配置。每个互斥角色集定义了一组角色，以及允许的最大并发数。

举个例子：

{
  "ssd_rules": [
    {
      "rule_id": "SSD-001",
      "name": "财务核心岗位互斥",
      "roles": ["会计", "出纳", "审计"],
      "max_authorized": 1,
      "description": "财务核心三岗不得兼任"
    },
    {
      "rule_id": "SSD-002",
      "name": "采购验收互斥",
      "roles": ["采购员", "验收员"],
      "max_authorized": 1,
      "description": "采购与验收必须分离"
    },
    {
      "rule_id": "SSD-003",
      "name": "代码开发与发布互斥",
      "roles": ["开发工程师", "发布运维"],
      "max_authorized": 1,
      "description": "禁止开发自写自发布"
    }
  ]
}

配置要点：

roles：列出互斥的角色列表。列表内的角色不能同时拥有多个。
max_authorized：允许同时拥有的最大角色数。通常为1，表示严格互斥。在某些宽松场景下可以是2，但需要业务风险评估。
优先级：如果用户通过不同的角色继承路径获得了互斥角色，系统需要决定以哪个角色为准。我建议：显式分配的权限高于继承来的权限。

实战小贴士：配置SSD时，尽量把互斥规则做成原子化的。一条规则只定义一组互斥关系，避免“超级规则”把10个不相关的角色捆在一起，否则后续业务调整时会很痛苦。

4.4 验证方法

配置完SSD，怎么验证它确实生效了？

我个人习惯分三步走：

单元测试：单用户分配验证

创建一个测试用户，尝试同时分配互斥角色对中的两个角色。预期结果：分配失败，并返回明确的错误码和错误提示。

# 模拟分配API调用
POST /api/users/test_ssd_01/roles
{
  "roles": ["采购员", "验收员"]
}
# 预期响应: HTTP 403
{
  "code": "SSD_CONFLICT",
  "message": "用户已拥有角色'采购员'，与角色'验收员'存在静态互斥（SSD-002）"
}

批量审计：全量用户扫描
你想想看，历史数据里会不会已经存在互斥的情况？是的，我遇到过。所以需要写一个脚本，全量扫描所有用户的角色列表，找出所有违反SSD规则的用户。

我建议把扫描结果输出成报表，发给安全部门确认是否要手动处理。
压力测试：频繁分配与移除
模拟高并发下的角色分配和移除操作，确保SSD检查在高负载下不丢单、不产生脏数据。我曾在项目中遇到过因为缓存未及时刷新，导致互斥检查漏掉的案例……差点出大事。

4.5 避坑指南：我曾经踩过的坑

教训一：忽略角色继承导致的隐式互斥

我曾经在一家金融科技公司做权限审计，发现他们的SSD规则只在“直接分配”时检查，完全没管角色继承。结果有个用户通过继承获得了“审计员”和“系统管理员”两个角色，直接绕过了互斥。为什么？因为SSD规则查的是角色ID，而继承来的角色是“上级角色”传下来的，规则根本没匹配到。

解决方案：SSD检查必须递归解析所有继承角色，平铺成一个集合，再与互斥规则对比。

教训二：互斥规则更新后的历史数据清洗

假设你今天新增了一条SSD规则：“客服专员”和“退款审批”互斥。但系统里已经有50个用户同时拥有这两个角色了。怎么办？

我当时的选择是：新规则立即生效，但历史数据给予一个过渡期。具体做法是：

新SSD规则一旦生效，立即禁止新分配互斥角色。
对已有的冲突用户，发送通知并要求在30天内完成角色调整。
30天后未处理的，系统自动移除其中一个角色，并记录审计日志。

记住：不要想当然地一刀切强制移除，容易引发业务事故。

4.6 知识体系图

4.7 小结

静态职责分离是权限审计中最基础也最有效的控制手段之一。它不是万能的，但没有它，很多核心业务的合规性就是一句空话。

总结几个关键动作：

定义互斥：找业务专家，梳理出所有利益冲突的场景。
配置规则：用互斥角色集精确描述，注意MaxAuthorized的取值。
全面验证：单元测、批量扫、压力跑，一个都不能少。
持续审计：规则变了、用户角色变了，都要重新过一遍SSD检查。

下一段咱们聊聊DSD（动态职责分离）。但这一章就到这里，先把SSD吃透。