一、ISO/IEC 27017:2015 5.1 标准原文
ISO/IEC 27017:2015 5.1 信息安全管理指导
条款原文:云服务客户应把云计算信息安全政策定义为专题级策略,关注平台可访问和管理客户信息、资产在云中维护、多租户与虚拟化、云用户与管理员、以及数据可能存储的地理位置。云服务提供商则应在其信息安全政策中纳入云服务设计和交付要求、内部人员风险、多租户隔离、客户资产访问、管理访问强认证以及变更沟通。
条款原文:云服务客户应把云计算信息安全政策定义为专题级策略,关注平台可访问和管理客户信息、资产在云中维护、多租户与虚拟化、云用户与管理员、以及数据可能存储的地理位置。云服务提供商则应在其信息安全政策中纳入云服务设计和交付要求、内部人员风险、多租户隔离、客户资产访问、管理访问强认证以及变更沟通。
提示:完整原文请参阅 ISO/IEC 27017:2015 正式文本
引用:5.1不是写一份“上云声明”,而是把云控制边界正式提升到政策层。
二、条款解读说明
2.1 云策略不是把原有信息安全方针改个标题,而是要把云场景的独特边界写进去。
云服务把组织的信息、资产、流程和管理员权限扩展到了平台边界之外。于是信息安全方针如果仍停留在本地设施和内部人员视角,就无法覆盖云控制台、多租户、数据位置、管理接口和服务变更通知等实际问题。本条要求组织把云计算作为专题政策进行管理,使方针真正能够约束云服务使用和云服务交付。就本条而言,组织尤其需要把云策略范围、多租户与虚拟化和地理位置与变更沟通放进同一套判断框架,而不是分散给不同团队各自理解。
2.2 核心关注点
| 关注点 | 条款要求 | 常见失效表现 | 正确做法 |
|---|---|---|---|
| 云策略范围 | 本条要求组织在云场景下把云策略范围纳入正式控制范围 | 边界不清,团队往往默认由平台或他人负责 | 先定义责任、范围和最小控制要求 |
| 多租户与虚拟化 | 本条要求组织在云场景下把多租户与虚拟化纳入正式控制范围 | 要求存在于文件中,但没有落到流程和配置 | 把要求写入制度、协议、配置或审批流程 |
| 地理位置与变更沟通 | 本条要求组织在云场景下把地理位置与变更沟通纳入正式控制范围 | 证据不足,审核或事件发生时无法还原事实 | 保留可验证记录,并建立周期复核机制 |
| 客户数据与业务保护 | 本条要求组织在云场景下把客户数据与业务保护纳入正式控制范围 | 与相邻条款脱节,形成控制孤岛 | 与前后条款联动,形成闭环控制链条 |
2.3 云场景下的管理重点
高质量的云策略应同时解决两个问题:一是客户如何定义自身上云底线,二是提供商如何把服务交付要求内化为对客户数据和业务的保护要求。如果政策层讲不清楚,后续访问控制、备份、日志和审计控制就会各自为战,既难协同也难举证。对于5.1而言,如果组织只停留在条文理解层,而没有把云策略范围、多租户与虚拟化、地理位置与变更沟通转化为流程、配置和证据,那么控制看似存在,实际运行中依旧会出现大量灰区。
2.4 与前后条款的衔接
本条并不是孤立存在。5.1为后续访问控制、加密、日志、变更、审计和合规条款提供统一政策口径。实务中,只有把本条输出持续回灌到制度、采购、变更、审计和退出场景中,组织才能证明自己不仅理解了条款,还真正用条款重塑了云服务治理方式。
注意:云安全政策既要约束客户内部行为,也要约束提供商如何交付和解释其服务能力。
三、实施要点
3.1 先把责任和适用范围说清楚
- 明确云策略范围在客户侧、提供商侧和共享责任侧分别由谁承担。
- 将多租户与虚拟化写进制度、协议或服务说明书,避免只靠口头理解。
- 对高风险场景设置触发条件,出现重大变更、事件或业务调整时及时复核。
3.2 把条款要求落到流程和技术控制
- 围绕云策略范围和地理位置与变更沟通建立审批点、配置基线或标准操作步骤。
- 避免仅有原则性要求而没有实际执行动作和系统留痕。
- 对例外场景设置期限、补救措施和复核责任。
3.3 建立持续监视和复核机制
- 通过日志、报表、抽查、演练或会议机制持续观察多租户与虚拟化是否按预期运行。
- 将发现的问题与整改计划、责任人和完成时限对应起来。
- 不要只在认证前集中补证据,应让记录随运行自然产生。
3.4 与前后条款联动形成闭环
- 把本条输出与5.1为后续访问控制、加密、日志、变更、审计和合规条款提供统一政策口径。联动起来,形成完整控制链。
- 在管理评审、内部审查或供应商评审中定期检查本条的有效性。
- 将经验教训回灌到制度、培训和技术基线更新中。
四、常用工具与实施方法
| 工具/方法 | 适用场景 | 实施重点 | 关键输出 |
|---|---|---|---|
| 云安全方针模板 | 建立专题级策略文件 | 覆盖数据位置、管理权限、日志、退出和变更沟通 | 方针文本 |
| 策略范围映射图 | 明确哪些云场景被纳入策略 | 按IaaS、PaaS、SaaS和支持接口划分 | 适用范围图 |
| 策略评审机制 | 定期更新云策略 | 结合服务变化、法规变化和重大事件 | 评审记录 |
| 控制基线映射表 | 将策略要求落到技术配置 | 把策略条文对应到账号、网络、日志和备份基线 | 基线映射表 |
| 管理层沟通摘要 | 让业务和管理层理解策略后果 | 用风险语言说明云控制要求 | 管理层汇报材料 |
五、典型案例
案例1:组织有信息安全方针,但没有云专题策略
- 背景:某企业的总方针要求保护信息资产,却没有说明云管理员、多租户、区域选择和服务退出等事项如何管理。
- 改进:建立专题级云安全策略后,相关要求才从抽象原则变成可执行控制。
- 启示:案例说明组织需要围绕信息安全管理指导把责任、流程、配置和记录四个层面同时做实。
案例2:提供商策略只覆盖自身系统,不覆盖客户数据处理
- 背景:某平台内部安全政策写得很完整,但没有针对客户数据访问、支持排障和服务变更建立专门要求。
- 改进:平台依照本条补充交付侧策略,服务运营和客户沟通口径随之统一。
- 启示:案例说明组织需要围绕信息安全管理指导把责任、流程、配置和记录四个层面同时做实。
六、成文信息管理要求
审核本条时,通常会同时查看制度文件、协议或系统配置、运行记录以及例外和复核记录。换言之,本条需要用“文件+动作+证据”三类材料共同证明,而不是只靠一份制度文本。
- 建议保留的成文信息
- 与信息安全管理指导相关的制度、流程或控制说明文件
- 围绕云策略范围、多租户与虚拟化形成的配置、审批、评审或检查记录
- 与云服务提供商沟通、确认和举证所需的协议、说明书、报告或工单记录
- 定期复核、抽查、演练或例外审批的闭环记录
- 证明本条与相关条款衔接关系的映射表、说明材料或评审纪要
- 管理要求
- 记录应与真实云服务、真实角色和真实操作场景一一对应,避免模板化泛写。
- 出现重大变更、重大事件或服务模式调整后,应及时更新并保留版本痕迹。
- 相关文件和记录应按组织文件控制要求统一管理,便于审核、追溯和复盘。
七、常见误区及踩坑提醒
| 误区 | 常见表现 | 正确做法 |
|---|---|---|
| 把云策略范围当成一次性动作 | 前期做过一次后长期不更新 | 建立周期评审和变更触发机制 |
| 只看文件,不看多租户与虚拟化是否可执行 | 制度存在但配置、审批和接口没有同步 | 让文件要求进入流程、系统和证据链 |
| 默认地理位置与变更沟通由云厂商兜底 | 责任边界模糊,客户侧控制长期缺位 | 通过责任矩阵和合同条款明确双方职责 |
| 只关注上线,不关注运行与退出 | 控制在运行期漂移,终止时无法收口 | 将运行监视、变更和退出纳入同一治理框架 |
警告:如果政策层没有明确数据位置、多租户和管理访问要求,后续控制通常会碎片化失效。
小结:5.1要求组织把云服务场景正式写进信息安全管理方向,使后续控制具备共同上位约束。