ISO/IEC 27017:2015 认证标准解读 7.3 任用的终止和变更

ISO/IEC 27017:2015 标准 7.3条款解读任用终止和岗位变更下的云安全控制,重点关注账号回收、职责移交和外包人员退出,防止人员离岗后仍保留云访问路径。

一、ISO/IEC 27017:2015 7.3 标准原文

ISO/IEC 27017:2015 7.3 任用的终止和变更
条款原文:本条确认ISO/IEC 27002第7.3条规定的目标及相关控制、实施指南和其他信息继续适用于云服务场景。组织在使用或提供云服务时,应结合账号回收、职责变更、外包人员退出等事项对通用控制做云化落地,并通过风险评估明确客户侧、提供商侧与共享责任边界。
提示:完整原文请参阅 ISO/IEC 27017:2015 正式文本
引用:本条的价值在于把云场景中的控制边界说清,而不是重复通用条款。

二、条款解读说明

2.1 云安全最终仍要落到人,人员控制不清,技术控制很难长期稳住。

云服务中的很多高风险操作都由人完成或触发,例如开通账户、配置权限、下载数据、处理工单、执行支持操作、审批变更和响应事件。因此人力资源类条款在云场景下并没有减弱,反而因为外包、远程和共享责任而更加复杂。本条的重点,是让组织把人员筛选、任用要求、意识培训、岗位变更和离岗回收与云权限治理联动起来。就本条而言,组织尤其需要把账号回收、职责变更和外包人员退出放进同一套判断框架,而不是分散给不同团队各自理解。

2.2 核心关注点

关注点条款要求常见失效表现正确做法
账号回收本条要求组织在云场景下把账号回收纳入正式控制范围边界不清,团队往往默认由平台或他人负责先定义责任、范围和最小控制要求
职责变更本条要求组织在云场景下把职责变更纳入正式控制范围要求存在于文件中,但没有落到流程和配置把要求写入制度、协议、配置或审批流程
外包人员退出本条要求组织在云场景下把外包人员退出纳入正式控制范围证据不足,审核或事件发生时无法还原事实保留可验证记录,并建立周期复核机制
密钥与令牌回收本条要求组织在云场景下把密钥与令牌回收纳入正式控制范围与相邻条款脱节,形成控制孤岛与前后条款联动,形成闭环控制链条

2.3 云场景下的管理重点

不少组织在上云后把注意力都放在平台能力上,却忽略了管理员、支持人员、开发人员和业务用户本身就是控制的一部分。任用前不做背景审查,任用中不讲云场景风险,离岗时不回收云账号和API权限,都会让云控制体系出现长期裂缝。人力资源条款的价值,就在于把这些“人”的边界提前管住。对于7.3而言,如果组织只停留在条文理解层,而没有把账号回收、职责变更、外包人员退出转化为流程、配置和证据,那么控制看似存在,实际运行中依旧会出现大量灰区。

2.4 与前后条款的衔接

本条并不是孤立存在,它与9.2账号生命周期、8.1资产责任和16章事件预防直接相关。实务中,只有把本条输出持续回灌到制度、采购、变更、审计和退出场景中,组织才能证明自己不仅理解了条款,还真正用条款重塑了云服务治理方式。

注意:云环境中的离岗控制不能只停留在门禁和办公账号,还要覆盖控制台、API密钥、令牌和共享文件权限。

三、实施要点

3.1 先把责任和适用范围说清楚

  • 明确账号回收在客户侧、提供商侧和共享责任侧分别由谁承担。
  • 将职责变更写进制度、协议或服务说明书,避免只靠口头理解。
  • 对高风险场景设置触发条件,出现重大变更、事件或业务调整时及时复核。

3.2 把条款要求落到流程和技术控制

  • 围绕账号回收和外包人员退出建立审批点、配置基线或标准操作步骤。
  • 避免仅有原则性要求而没有实际执行动作和系统留痕。
  • 对例外场景设置期限、补救措施和复核责任。

3.3 建立持续监视和复核机制

  • 通过日志、报表、抽查、演练或会议机制持续观察职责变更是否按预期运行。
  • 将发现的问题与整改计划、责任人和完成时限对应起来。
  • 不要只在认证前集中补证据,应让记录随运行自然产生。

3.4 与前后条款联动形成闭环

  • 将本条输出纳入以下控制链:9.2账号生命周期、8.1资产责任和16章事件预防
  • 在管理评审、内部审查或供应商评审中定期检查本条的有效性。
  • 将经验教训回灌到制度、培训和技术基线更新中。

四、常用工具与实施方法

工具/方法适用场景实施重点关键输出
岗位风险分级表识别接触云高风险权限的岗位区分普通用户、管理员、开发和支持人员岗位分级清单
任用与离岗检查表把人员管理与账号治理联动覆盖MFA、令牌、API密钥和文档回收检查记录
云安全培训计划针对不同岗位开展培训分管理员、业务用户和外包商设计内容培训记录
保密与行为承诺文本约束云数据和平台使用行为把远程、截图、下载和共享要求写清签署记录
岗位变更权限复核避免职责变动后权限残留将HR事件触发到IAM流程复核记录

五、典型案例

案例1:离职运维仍保留云平台高权限

  1. 背景:某工程师离职后,因HR流程与平台权限回收未打通,其管理员账户持续可用。
  2. 改进:组织把离岗检查表与云IAM联动后,人员退出风险明显降低。
  3. 启示:案例说明组织需要围绕任用的终止和变更把责任、流程、配置和记录四个层面同时做实。

案例2:外包支持人员接触客户数据却缺少培训

  1. 背景:某服务外包商参与云工单处理,但只接受了通用安全宣导,没有讲清客户数据、日志和截图的处理边界。
  2. 改进:企业根据本条重建面向云场景的培训和行为约束,减少了支持过程中的违规暴露。
  3. 启示:案例说明组织需要围绕任用的终止和变更把责任、流程、配置和记录四个层面同时做实。

六、成文信息管理要求

审核本条时,通常会同时查看制度文件、协议或系统配置、运行记录以及例外和复核记录。换言之,本条需要用“文件+动作+证据”三类材料共同证明,而不是只靠一份制度文本。

  1. 建议保留的成文信息
    • 与任用的终止和变更相关的制度、流程或控制说明文件
    • 围绕账号回收、职责变更形成的配置、审批、评审或检查记录
    • 与云服务提供商沟通、确认和举证所需的协议、说明书、报告或工单记录
    • 定期复核、抽查、演练或例外审批的闭环记录
    • 证明本条与相关条款衔接关系的映射表、说明材料或评审纪要
  2. 管理要求
    • 记录应与真实云服务、真实角色和真实操作场景一一对应,避免模板化泛写。
    • 出现重大变更、重大事件或服务模式调整后,应及时更新并保留版本痕迹。
    • 相关文件和记录应按组织文件控制要求统一管理,便于审核、追溯和复盘。

七、常见误区及踩坑提醒

误区常见表现正确做法
把账号回收当成一次性动作前期做过一次后长期不更新建立周期评审和变更触发机制
只看文件,不看职责变更是否可执行制度存在但配置、审批和接口没有同步让文件要求进入流程、系统和证据链
默认外包人员退出由云厂商兜底责任边界模糊,客户侧控制长期缺位通过责任矩阵和合同条款明确双方职责
只关注上线,不关注运行与退出控制在运行期漂移,终止时无法收口将运行监视、变更和退出纳入同一治理框架
警告:岗位变化后不做权限重算,是云环境中最常见也最难被及时发现的长期风险之一。
小结:7.3把HR事件转化为云账号、凭据和资产回收动作,是人员控制真正闭环的关键。