Separation of Duties 职责分离
不应该让一个人手握能滥用系统的全部权限。把关键流程拆成多人,任何单独一个人都不能独立完成 —— 这是反欺诈、反内部威胁的核心设计原则。
经典例子
| 场景 | 一个人能做 = 危险 | 职责分离 |
|---|---|---|
| 付款 | 创建供应商 + 审批付款 + 实际转账 | 拆成 3 个人 |
| 代码上线 | 写代码 + 审核 + 部署生产 | 写的人不能审,审的人不能部署 |
| 账号管理 | 创建账号 + 分配权限 + 审计日志 | 3 个角色互相牵制 |
| 数据库 | DBA 既改数据又改审计日志 | 审计日志权限隔离 |
跟 最小权限原则 的区别
| 原则 | 关注点 |
|---|---|
| Least Privilege | 每个人只给”够用”的权限 |
| Separation of Duties | 关键流程拆给多人,不允许集中 |
不是替代关系,是叠加 —— Least Privilege 限制”权限多大”,SoD 限制”权限组合”。
为啥这是反内部威胁的杀手锏
- 内部威胁 防不胜防 —— 员工本来就有合法访问
- 但只要做了 SoD,单人作案不可能 —— 必须合谋(成本和风险都激增)
- 财务领域早就这么干了(SOX 强制要求),IT 后来才跟上
实操难点
- 小公司人少,SoD 难落地 → 用工具补(审批流、最小化生产访问)
- “Emergency access” 例外要严格审计
- 角色设计要避免”幽灵权限”组合