ISO/IEC 27017:2015 认证标准解读 12.3 备份

ISO/IEC 27017:2015 标准 12.3条款聚焦云备份控制最常见的失效点,说明备份责任划分、备份范围定义、保存规格与恢复验证,避免出现有备份但恢复不了的假象。

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

ISO/IEC 27017:2015 12.3 备份
条款原文:本条补充指出:当提供商作为云服务的一部分提供备份能力时,客户应索取规格并核查是否满足自身要求;若提供商不提供,则客户有责任自行实施备份。标准还要求明确备份范围、时间表、方法与格式、保留期、完整性验证、恢复流程与时限、测试程序以及备份存放位置,并确保备份访问得到安全和隔离控制。
提示:完整原文请参阅 ISO/IEC 27017:2015 正式文本
引用:12.3最怕的不是没开备份,而是不知道备份是否真的覆盖了业务所需的一切。

二、条款解读说明

2.1 云备份最容易出问题的地方,不是“没有备份”,而是不知道到底谁负责、备份了什么、能否恢复。

在云环境中,备份责任往往不像本地环境那样直观。平台可能提供快照、版本、复制和恢复能力,但这并不自动等于客户已经满足自身备份要求。本条强调的是把备份范围、时间表、方法、加密、保留期、恢复流程和验证责任全部说清楚,避免备份能力停留在宣传层面。就本条而言,组织尤其需要把备份责任划分、备份规格和恢复验证放进同一套判断框架,而不是分散给不同团队各自理解。

2.2 核心关注点

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

2.3 云场景下的管理重点

很多云项目上线时都会勾选“已开备份”,真正出问题时却发现只备份了部分对象、恢复窗口过长、备份副本无法隔离、备份由客户自己负责却没有人真正执行。备份条款的真正价值,是让恢复成为经过验证的能力,而不是想当然的假设。对于12.3而言,如果组织只停留在条文理解层,而没有把备份责任划分、备份规格、恢复验证转化为流程、配置和证据,那么控制看似存在,实际运行中依旧会出现大量灰区。

2.4 与前后条款的衔接

本条并不是孤立存在,它与8.1资产清单、17章连续性、18.1记录保护和退出流程紧密相连。实务中,只有把本条输出持续回灌到制度、采购、变更、审计和退出场景中,组织才能证明自己不仅理解了条款,还真正用条款重塑了云服务治理方式。

注意:平台快照、日志留存和正式备份并不天然等价,必须按业务恢复要求逐项核对。

三、实施要点

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

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

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

  • 围绕备份责任划分和恢复验证建立审批点、配置基线或标准操作步骤。
  • 避免仅有原则性要求而没有实际执行动作和系统留痕。
  • 对例外场景设置期限、补救措施和复核责任。

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

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

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

  • 将本条输出纳入以下控制链:8.1资产清单、17章连续性、18.1记录保护和退出流程
  • 在管理评审、内部审查或供应商评审中定期检查本条的有效性。
  • 将经验教训回灌到制度、培训和技术基线更新中。

四、常用工具与实施方法

工具/方法适用场景实施重点关键输出
备份责任矩阵明确客户和提供商各自承担的备份义务区分主数据、配置、日志和镜像等对象责任清单
备份规格说明书定义范围、频率、保留和恢复目标将云服务规格与业务RTO/RPO对齐规格说明
恢复演练计划验证备份是否可用涵盖单点恢复、整体验证和异常情景演练报告
备份副本访问控制限制对快照和备份的访问确保不同租户和不同角色边界清晰权限记录
备份完整性校验持续检查备份数据质量结合校验、抽检和恢复测试校验记录

五、典型案例

案例1:平台提供快照,但企业以为已满足全部备份要求

  1. 背景:某团队只依赖平台默认快照,直到事故发生才发现配置文件和外部导出对象并未纳入同一恢复方案。
  2. 改进:组织重做备份规格后,才把“有能力”和“满足要求”区分开来。
  3. 启示:案例说明组织需要围绕备份把责任、流程、配置和记录四个层面同时做实。

案例2:备份存在,却没人定期做恢复验证

  1. 背景:某项目长期生成备份副本,但从未真正演练恢复,故障时发现恢复流程与业务窗口完全不匹配。
  2. 改进:通过恢复演练和完整性校验,备份控制从存储动作升级为业务能力。
  3. 启示:案例说明组织需要围绕备份把责任、流程、配置和记录四个层面同时做实。

六、成文信息管理要求

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

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

七、常见误区及踩坑提醒

误区常见表现正确做法
把备份责任划分当成一次性动作前期做过一次后长期不更新建立周期评审和变更触发机制
只看文件,不看备份规格是否可执行制度存在但配置、审批和接口没有同步让文件要求进入流程、系统和证据链
默认恢复验证由云厂商兜底责任边界模糊,客户侧控制长期缺位通过责任矩阵和合同条款明确双方职责
只关注上线,不关注运行与退出控制在运行期漂移,终止时无法收口将运行监视、变更和退出纳入同一治理框架
警告:只把平台默认快照当作正式备份,往往会在恢复时发现缺口集中暴露。
小结:12.3要求组织用责任矩阵、规格说明和恢复验证把云备份真正做实。