一、ISO/IEC 27017:2015 11.2 标准原文
ISO/IEC 27017:2015 11.2 设备
条款原文:本条确认设备类控制继续适用,并特别补充:客户应向提供商确认其具备资源安全处置和再利用的政策与程序;提供商则应确保设备、数据存储、文件和内存等资源在再利用或处置前得到及时且安全的处理。
条款原文:本条确认设备类控制继续适用,并特别补充:客户应向提供商确认其具备资源安全处置和再利用的政策与程序;提供商则应确保设备、数据存储、文件和内存等资源在再利用或处置前得到及时且安全的处理。
提示:完整原文请参阅 ISO/IEC 27017:2015 正式文本
引用:11.2在云环境里最容易被忽视的,不是设备的在用状态,而是设备和资源的退场状态。
二、条款解读说明
2.1 上云并不意味着物理安全失效,云服务只是把物理控制转化为更强的证据和接口要求。
虽然很多云资产表现为虚拟资源,但其底层仍依赖数据中心、安全区域、设备、布线、交接区和运维作业。本条的重点,是要求组织识别哪些物理和环境控制转移给了云服务提供商,哪些仍由客户本地承担,以及如何通过证据、审查和运行接口去确认这些控制真实存在。就本条而言,组织尤其需要把设备与资源处置、场外资产和安全再利用放进同一套判断框架,而不是分散给不同团队各自理解。
2.2 核心关注点
| 关注点 | 条款要求 | 常见失效表现 | 正确做法 |
|---|---|---|---|
| 设备与资源处置 | 本条要求组织在云场景下把设备与资源处置纳入正式控制范围 | 边界不清,团队往往默认由平台或他人负责 | 先定义责任、范围和最小控制要求 |
| 场外资产 | 本条要求组织在云场景下把场外资产纳入正式控制范围 | 要求存在于文件中,但没有落到流程和配置 | 把要求写入制度、协议、配置或审批流程 |
| 安全再利用 | 本条要求组织在云场景下把安全再利用纳入正式控制范围 | 证据不足,审核或事件发生时无法还原事实 | 保留可验证记录,并建立周期复核机制 |
| 边缘设备责任 | 本条要求组织在云场景下把边缘设备责任纳入正式控制范围 | 与相邻条款脱节,形成控制孤岛 | 与前后条款联动,形成闭环控制链条 |
2.3 云场景下的管理重点
物理安全在云场景下常被误认为“只要选大厂就行”。这种理解过于粗糙,因为客户自身仍可能拥有边缘设备、本地终端、缓存介质和数据导出场景,而提供商侧也存在设备再利用、访客控制、环境威胁和交接区域等风险。如果没有把物理控制映射到证据与流程,组织很容易在最基础的安全面上失去可验证性。对于11.2而言,如果组织只停留在条文理解层,而没有把设备与资源处置、场外资产、安全再利用转化为流程、配置和证据,那么控制看似存在,实际运行中依旧会出现大量灰区。
2.4 与前后条款的衔接
本条并不是孤立存在,它与8.1资产责任、8.3介质处理、17章连续性和CLD8.1.5退出返还紧密相连。实务中,只有把本条输出持续回灌到制度、采购、变更、审计和退出场景中,组织才能证明自己不仅理解了条款,还真正用条款重塑了云服务治理方式。
注意:设备条款不仅针对提供商机房资产,也针对客户仍保留的边缘设备和场外资产。
三、实施要点
3.1 先把责任和适用范围说清楚
- 明确设备与资源处置在客户侧、提供商侧和共享责任侧分别由谁承担。
- 将场外资产写进制度、协议或服务说明书,避免只靠口头理解。
- 对高风险场景设置触发条件,出现重大变更、事件或业务调整时及时复核。
3.2 把条款要求落到流程和技术控制
- 围绕设备与资源处置和安全再利用建立审批点、配置基线或标准操作步骤。
- 避免仅有原则性要求而没有实际执行动作和系统留痕。
- 对例外场景设置期限、补救措施和复核责任。
3.3 建立持续监视和复核机制
- 通过日志、报表、抽查、演练或会议机制持续观察场外资产是否按预期运行。
- 将发现的问题与整改计划、责任人和完成时限对应起来。
- 不要只在认证前集中补证据,应让记录随运行自然产生。
3.4 与前后条款联动形成闭环
- 将本条输出纳入以下控制链:8.1资产责任、8.3介质处理、17章连续性和CLD8.1.5退出返还
- 在管理评审、内部审查或供应商评审中定期检查本条的有效性。
- 将经验教训回灌到制度、培训和技术基线更新中。
四、常用工具与实施方法
| 工具/方法 | 适用场景 | 实施重点 | 关键输出 |
|---|---|---|---|
| 物理安全证据清单 | 向提供商获取关键物理控制证明 | 覆盖安全区域、访客、监控和设备处置 | 证据包 |
| 边缘设备盘点表 | 管理客户自有的本地或边缘设备 | 记录位置、责任人和处置要求 | 盘点台账 |
| 现场/远程评审检查单 | 评估提供商物理控制成熟度 | 结合认证报告和重点问题清单 | 评审记录 |
| 设备处置验证表 | 确认资源再利用和销毁过程 | 关注存储、内存和介质清理 | 验证记录 |
| 运维作业审批单 | 管理涉及物理设施的维护活动 | 将敏感设备维护纳入审批和监督 | 审批记录 |
五、典型案例
案例1:认为上云后就无需关注设备处置
- 背景:某组织只看云平台在线控制,却没有向提供商确认存储介质和内存资源的再利用与销毁安排。
- 改进:补充物理证据和处置验证后,组织才真正完成物理控制闭环。
- 启示:案例说明组织需要围绕设备把责任、流程、配置和记录四个层面同时做实。
案例2:边缘设备留在现场却没人负责
- 背景:企业主系统上云后,分支机构仍保留缓存、打印和采集设备,但这些设备未纳入统一安全管理。
- 改进:通过本条要求重盘边缘资产后,物理与虚拟控制才重新衔接起来。
- 启示:案例说明组织需要围绕设备把责任、流程、配置和记录四个层面同时做实。
六、成文信息管理要求
审核本条时,通常会同时查看制度文件、协议或系统配置、运行记录以及例外和复核记录。换言之,本条需要用“文件+动作+证据”三类材料共同证明,而不是只靠一份制度文本。
- 建议保留的成文信息
- 与设备相关的制度、流程或控制说明文件
- 围绕设备与资源处置、场外资产形成的配置、审批、评审或检查记录
- 与云服务提供商沟通、确认和举证所需的协议、说明书、报告或工单记录
- 定期复核、抽查、演练或例外审批的闭环记录
- 证明本条与相关条款衔接关系的映射表、说明材料或评审纪要
- 管理要求
- 记录应与真实云服务、真实角色和真实操作场景一一对应,避免模板化泛写。
- 出现重大变更、重大事件或服务模式调整后,应及时更新并保留版本痕迹。
- 相关文件和记录应按组织文件控制要求统一管理,便于审核、追溯和复盘。
七、常见误区及踩坑提醒
| 误区 | 常见表现 | 正确做法 |
|---|---|---|
| 把设备与资源处置当成一次性动作 | 前期做过一次后长期不更新 | 建立周期评审和变更触发机制 |
| 只看文件,不看场外资产是否可执行 | 制度存在但配置、审批和接口没有同步 | 让文件要求进入流程、系统和证据链 |
| 默认安全再利用由云厂商兜底 | 责任边界模糊,客户侧控制长期缺位 | 通过责任矩阵和合同条款明确双方职责 |
| 只关注上线,不关注运行与退出 | 控制在运行期漂移,终止时无法收口 | 将运行监视、变更和退出纳入同一治理框架 |
警告:若不验证资源再利用与清理机制,旧介质、旧内存和历史副本极易成为隐蔽泄露源。
小结:11.2要求组织把设备与资源从部署到处置的全过程纳入云场景治理,尤其关注退场与再利用。