4. 职责分离：概念、关键场景与冲突矩阵设计
职责分离，圈内人常说的 SoD（Segregation of Duties）。
说白了就是一句话：不能让同一个人从头到尾包办一件敏感事。你想想看，如果一个人既能申请采购、又能审批付款、还能自己核账，那公司离倒闭也就不远了。
我做了这么多年权限审计，见过太多因为职责不分导致的内部舞弊案例。有个客户，财务主管一个人管着网银 U 盾和复核密码，三年挪走了 800 万。老板直到对账才发现。嗯，这就是典型的 SoD 缺失。
4.1 职责分离的核心逻辑
职责分离不是搞不信任，而是用制度保护员工、保护公司。它的底层逻辑就四个字：互相制衡。
一个完整的业务流，应该拆成几个独立环节，交给不同的人去执行。这样，任何一个人想干坏事，都得先串通其他人。串通的成本高了，风险自然就降了。
SoD 的三大目标：
- 防舞弊：单人无法完成资产盗用或数据篡改
- 减差错：多人复核，降低无意识操作失误
- 保合规：满足 SOX、等保、GDPR 等监管要求
我个人习惯把 SoD 分成两类：
- 职能性 SoD：业务操作层面的分离，比如申请和审批不能是同一个人
- 技术性 SoD：系统权限层面的分离，比如开发和运维不能共用同一个生产账号
4.2 关键场景：财务、IT、研发
不同业务场景下，SoD 的侧重点完全不同。我挑三个最常出问题的领域来讲。
4.2.1 财务场景
财务是 SoD 的重灾区，也是监管审计盯得最紧的地方。我在项目中遇到过一家上市公司，出纳兼着会计的活，结果把客户回款截留到自己账户，用假银行对账单糊弄了两年。
财务场景的核心冲突对：
| 角色 A | 角色 B | 冲突原因 |
|---|---|---|
| 采购申请 | 采购审批 | 自己申请自己批，虚报价格无人制约 |
| 应付账款录入 | 付款审批 | 录入虚假发票并自行批准付款 |
| 银行对账 | 现金管理 | 对账人可篡改对账单掩盖挪用 |
| 总账记账 | 财务报表编制 | 记账人可调整科目影响报表结果 |
我的经验：财务系统里，AP 录入 和 AP 审批 这两个角色必须互斥。如果公司人少，至少要有主管级的事后抽查机制。
4.2.2 IT 场景
IT 部门的 SoD 经常被忽视。很多公司觉得 IT 是技术部门，不会出大问题。其实恰恰相反，IT 掌握着所有系统的超级权限，一旦出事就是系统性风险。
我曾经审计过一家互联网公司，DBA 同时拥有数据库的读写权限和操作系统 root 权限。他直接导出了全量用户数据卖给黑产，公司被罚了 2000 万。
IT 场景的核心冲突对：
| 角色 A | 角色 B | 冲突原因 |
|---|---|---|
| 系统管理员 | 安全审计员 | 管理员可删除自己的操作日志 |
| 数据库管理员 | 应用管理员 | DBA 可直接修改应用数据绕过业务逻辑 |
| 网络管理员 | 安全策略制定 | 自己定规则自己执行，无制衡 |
| 备份管理员 | 数据恢复审批 | 可私自恢复数据并泄露 |
避坑指南：我曾经见过一家公司，把 root 密码写在共享文档里，全部门都能看。这已经不是 SoD 的问题了，这是基本安全意识的缺失。记住：特权账号必须专人专用，密码定期轮换。
4.2.3 研发场景
研发场景的 SoD 比较特殊，因为研发追求效率，权限管得太死会影响开发速度。但该有的制衡不能少。
研发场景的核心冲突对：
| 角色 A | 角色 B | 冲突原因 |
|---|---|---|
| 开发人员 | 代码审核人员 | 自己写代码自己审核，漏洞无法被发现 |
| 开发人员 | 生产环境部署 | 可直接将未测试代码推上线 |
| 测试人员 | 版本发布审批 | 测试人员可绕过缺陷修复流程直接发布 |
| 代码提交者 | 合并到主分支 | 可绕过 PR 审查直接合入 |
我的建议：研发环境一定要用 Git 分支权限控制。开发人员只能往 feature 分支提交，合并到 master 必须经过至少一个人 Code Review。这个规则在工具层面就能强制落地。
4.3 冲突矩阵设计
冲突矩阵是 SoD 落地的核心工具。说白了，就是一张表，告诉你哪些角色不能同时赋予同一个人。
设计冲突矩阵，我一般分三步走：
- 梳理业务流：把公司所有关键业务流程画出来，找到每个环节的参与角色
- 识别冲突对：分析哪些角色组合在一起会产生风险
- 定义冲突等级：有些冲突是致命的（红色），有些是警告级别的（黄色）
下面是一个简化的财务冲突矩阵示例：
| 角色 | 采购申请 | 采购审批 | 收货确认 | 发票录入 | 付款审批 |
|---|---|---|---|---|---|
| 采购申请 | - | ✗ 冲突 | ⚠ 警告 | ✓ 允许 | ✓ 允许 |
| 采购审批 | ✗ 冲突 | - | ✗ 冲突 | ⚠ 警告 | ✓ 允许 |
| 收货确认 | ⚠ 警告 | ✗ 冲突 | - | ✗ 冲突 | ⚠ 警告 |
| 发票录入 | ✓ 允许 | ⚠ 警告 | ✗ 冲突 | - | ✗ 冲突 |
| 付款审批 | ✓ 允许 | ✓ 允许 | ⚠ 警告 | ✗ 冲突 | - |
矩阵使用说明：
- ✗ 冲突（红色）：禁止同时赋予，必须由不同人担任
- ⚠ 警告（黄色）：建议分离，如果无法分离需有补偿性控制（如主管抽查）
- ✓ 允许（绿色）：可以赋予同一个人，风险可控
设计冲突矩阵时，有几点要注意：
- 矩阵要动态更新：业务变了，角色变了，矩阵就得跟着变。我见过有的公司三年前的矩阵还在用，那跟没有一样。
- 不要过度设计：把所有角色都做成互斥，业务就没法跑了。抓大放小，先管住资金、数据、核心系统。
- 工具化落地：矩阵设计好了，要在 IAM 系统或应用系统里配置成规则。用户申请权限时自动检测冲突，有冲突直接拦截。
我曾经踩过的坑：给一家金融客户设计矩阵时，我把「交易录入」和「交易复核」设成了互斥。结果发现他们的交易量太大，复核人手不够，导致大量交易积压。后来我们加了一个「紧急复核」角色，由主管临时授权，才解决了问题。所以，矩阵设计一定要考虑实际业务容量。
4.4 职责分离的落地检查清单
最后，我整理了一份 SoD 落地检查清单，你可以在审计时直接拿来用：
| 检查项 | 检查要点 | 检查方法 |
|---|---|---|
| 冲突矩阵是否完整 | 覆盖财务、IT、研发三大场景 | 查阅矩阵文档，核对业务流 |
| 矩阵是否已工具化 | 在 IAM 或应用系统中配置了冲突规则 | 登录系统查看权限申请流程 |
| 是否存在一人多角色 | 抽查高权限用户，看是否同时拥有冲突角色 | 导出用户权限清单，交叉比对 |
| 补偿控制是否有效 | 对于无法分离的场景，是否有日志审计或主管复核 | 查看审计日志和复核记录 |
| 矩阵是否定期更新 | 至少每半年 review 一次 | 查看更新记录和版本历史 |
嗯，职责分离这部分内容比较多，但核心就一句话：关键业务不能一个人说了算。你回去可以先拿财务流程练练手，画一张冲突矩阵出来，看看你们公司有没有「一人通吃」的情况。