一、ISO/IEC 27018:2025 5.3 标准原文

二、标准条款解读说明

2.1 为什么PII处理链中的职责冲突比普通IT场景更值得警惕

在一般IT运维中，职责分离通常被理解为审批人与执行人分开、开发与发布分开、财务录入与复核分开等。这些原则在27018场景下同样适用，但风险密度更高。因为公有云PII处理链中，一次不当组合权限可能直接导致客户数据被过度导出、错误删除、越权恢复、静默访问，或者在事后根本无法证明发生过什么。

例如，如果同一个工程师既能批准自己的临时提权，又能在后台跨租户查看数据，还能删除相关日志，那么组织几乎失去了对访问边界的有效制衡；如果同一团队既负责客户删除请求执行，又负责删除完成确认和例外说明，客户就很难获得可信的独立验证；如果同一角色既能恢复备份，又能决定恢复数据向谁开放，恢复流程就可能成为非常隐蔽的PII暴露入口。对PII处理者来说，这些都不是理论风险，而是非常实际的运营风险。

因此，5.3要求组织不要只在传统审批流程里做职责分离，还要深入到PII高风险操作链中，识别哪些职责组合一旦集中就会使客户边界、证据链和问责能力失去意义。

2.2 在公有云PII处理中最常见的冲突职责组合

2.3 5.3真正要防的是“单点掌控完整链路”

有些组织会机械理解职责分离，认为只要流程上多签一个字就算完成。但在公有云PII场景里，真正要避免的是单点掌控：一个人既提出需求又批准自己，既执行动作又验证合规，既查看数据又管理日志，既恢复副本又决定谁能看恢复结果。只要完整链路被单点控制，制度上有多少审批节点都可能失效。

因此，5.3的设计应当优先识别那些一旦被同一角色拿到就会明显削弱客户信任的组合权限，而不是平均用力地要求所有流程都两人参与。换句话说，职责分离强调的是关键制衡点，而不是形式上的流程复杂化。

2.4 人少并不是放弃职责分离的理由

中小团队或高压运维场景常常会说：“我们人就这么多，根本分不开。”这在现实里确实常见，但并不意味着5.3可以被忽略。成熟做法通常是识别最关键的冲突点，在无法完全分离时引入补偿控制，例如：更强的会话审计、事后独立复核、总部或独立团队批准、临时授权到期回收、关键日志只读保护和异常操作自动告警。真正不可接受的，不是人员有限，而是在明知高风险职责集中的情况下仍长期没有任何补偿机制。

三、实施要点

3.1 先识别PII处理链中的冲突职责组合

• 优先从导出、删除、恢复、支持访问、日志管理、供应链接入和高权限提权这些高风险场景开始识别。
• 不要只看组织图，要看实际系统权限和流程节点组合后谁真的能一人完成整条链。
• 许多表面上“流程合规”的问题，实际都隐藏在系统权限集中上。

3.2 把分离设计落到审批、权限和日志保护三层

• 审批层要分离申请与批准；权限层要避免同一角色兼具执行与监督能力；日志层要确保操作人无法自行修改或抹除关键证据。
• 三层中只做一层通常不够，因为高风险用户往往会利用另一层绕过控制。
• 对PII高风险动作，最好同时做到职责分离和证据分离。

3.3 对高风险临时权限使用JIT和时限控制

• 很多冲突职责来自长期常驻高权限。通过按工单临时授予、短时有效和自动回收，可以显著降低职责集中风险。
• 尤其对跨租户支持、备份恢复读取和批量导出这类能力，更适合采用临时权限模式。
• 长期常驻高风险权限，几乎总会削弱职责分离效果。

3.4 对无法完全分离的场景设计补偿控制

• 对于小团队、值班场景或极端故障处置，可采用双人复核、独立日志审计、次日复盘、管理层批准和更强留痕等方式补偿。
• 关键是例外不能被默许为常态，且补偿控制必须真实可执行。
• 没有记录和复核的例外，实际上等同于没有分离。

3.5 定期审查冲突职责是否因变化重新出现

• 系统升级、团队合并、角色调整、区域扩展和供应链变化后，原本分离良好的职责组合可能重新被集中。
• 应通过权限审计、流程抽查和异常分析周期性检查冲突组合。
• 职责分离不是一次设计，而是持续维护的边界工程。

四、常用工具与实施方法

五、典型案例

案例一：同一工程师既能申请又能批准跨租户导出

1. 背景：某平台为了提高处理效率，让高级支持工程师在系统中自行申请并批准导出。
2. 问题：表面上流程存在，实则申请、批准和执行都落在同一人身上，导出几乎失去制衡。
3. 5.3动作：平台把批准权移交给独立角色，并对高风险导出增加复核和留痕。
4. 结果：导出行为不再由单点控制。
5. 启示：流程节点存在，不等于职责已分离。

案例二：恢复管理员既能读取备份又能决定谁可见恢复结果

1. 背景：某平台恢复演练时，由同一名管理员执行恢复、检查内容并将结果共享给相关人员。
2. 问题：该角色实际上掌握了副本读取与开放边界的完整链路。
3. 5.3动作：组织将恢复触发批准、恢复执行和恢复后开放确认拆分给不同角色。
4. 结果：备份副本不再成为单点高权限的隐形后门。
5. 启示：恢复流程中的职责集中通常比正常流程更容易被忽略。

案例三：日志管理员可修改记录，导致支持访问难以独立取证

1. 背景：支持团队中的一名高权限人员同时负责访问后台和维护相关日志策略。
2. 问题：一旦发生争议，该人员理论上可以影响自身行为痕迹的完整性。
3. 5.3动作：平台将日志保护与访问执行角色拆开，并把关键日志交给独立安全团队审查。
4. 结果：支持访问开始具备更可信的证据基础。
5. 启示：最该分离的，往往是“做事的人”和“保存痕迹的人”。

六、成文信息管理要求

5.3在审核中通常会被结合权限与流程样本抽查。审核员会关注组织是否识别了高风险冲突职责、是否落实在系统权限和审批流中、是否对例外场景保留补偿控制和复盘证据。

七、常见误区及踩坑提醒