一、ISO/IEC 20000-1:2018 8.7.3 标准原文
条款要求：组织应确保在服务管理体系中识别并控制与服务相关的信息安全风险和要求，以保护服务信息及其处理活动的机密性、完整性和可用性。相关控制应与服务要求、法律法规和组织安全方针保持一致。
二、标准条款解读说明
2.1 服务视角下的信息安全要素表
| 要素 | 服务管理关注点 | 典型控制 |
|---|---|---|
| 访问控制 | 谁可以访问服务、数据和运维通道 | 账号权限、审批、最小权限 |
| 变更与运维安全 | 变更、发布、远程运维是否安全受控 | 双人复核、日志、堡垒机、回退 |
| 数据与配置保护 | 服务数据、配置项和备份是否受保护 | 加密、备份、完整性校验 |
| 事件与响应 | 安全事件如何影响服务并被快速处置 | 安全监测、升级、联动响应 |
2.2 核心理解
8.7.3并不是把ISO 27001整套要求复制进来，而是要求组织在服务管理过程中落实必要的信息安全控制。也就是说，服务管理者需要关心：服务台受理和验证是否安全、远程支持是否有审计、变更实施是否受控、供应商接入是否安全、客户数据在备份和恢复过程中是否受到保护。这些都直接影响服务质量和客户信任。
从实务看，很多服务问题本身就是安全问题的表现形式。例如权限错配导致业务中断，弱口令导致系统被入侵，运维通道缺少审计导致违规操作难以追溯，未授权变更导致配置被篡改。ISO 20000 将信息安全放在保证类过程，就是要求组织把安全融入交付，而不是把它当成只由安全团队负责的附属议题。
三、实施要点
3.1 识别服务相关安全要求
- 识别客户合同、法律法规、内部方针和业务场景对服务安全的要求。
- 重点关注访问控制、远程运维、日志审计、数据保护和供应商接入。
3.2 将安全控制嵌入运行过程
- 在服务请求中控制账号和权限审批，在变更中控制高风险操作，在事件处理中联动安全升级。
- 对关键服务建立安全监测和异常处置规则。
3.3 管理服务供应链安全
- 对云厂商、外包运维、第三方工具和驻场人员设定访问、审计和保密要求。
- 确保供应商安全要求与组织对客户的承诺一致。
3.4 做持续验证和改进
- 通过安全事件、审计发现、权限抽查和配置检查验证控制效果。
- 将安全问题纳入问题管理和持续改进。
四、常用工具与实施方法
| 工具/方法 | 用途 | 输出 |
|---|---|---|
| 服务安全要求清单 | 识别每项服务的安全要求 | 安全要求矩阵 |
| 访问控制流程 | 规范账号和权限管理 | 审批与授权记录 |
| 堡垒机和日志审计 | 控制运维访问并保留证据 | 访问审计日志 |
| 安全检查 | 验证配置和流程控制有效性 | 检查报告 |
| 安全事件联动机制 | 应对安全影响服务的场景 | 联动处置记录 |
五、典型案例
案例一：服务请求流程中的权限风险
某企业权限开通长期依赖邮件确认，没有统一审批和验证，结果出现误授权并引发数据泄露风险。组织按8.7.3重建权限请求流程后，将身份核验、审批、审计和回收纳入标准请求管理，风险显著下降。
案例二：运维通道缺乏审计导致责任难追溯
某服务商发生生产配置误删后，无法确认是哪位工程师操作，因为多个账户共用且无审计。后来组织引入堡垒机、双人授权和变更联动审计，将安全控制与服务运维过程真正结合，责任边界更加清晰。
案例三：安全控制嵌入发布和供应链后风险下降
某互联网服务平台曾因第三方组件更新和外包运维接入控制不足，多次出现高风险漏洞暴露和操作失误。依据8.7.3重构后，组织把供应商访问审批、发布前安全检查、关键操作留痕和异常联动响应纳入统一服务流程，安全问题不再只是安全部门的孤岛事项，而是进入日常服务治理。
很多组织觉得自己已有安全制度，因此8.7.3 似乎只是“引用一下即可”。但从审核和运营实践看，最大风险恰恰出在制度与服务场景脱节。制度里写了最小权限，现场却用共享账号；制度里写了审批，现场却靠聊天授权；制度里要求日志，关键运维通道却没有留痕。8.7.3 要求解决的正是这种“制度在墙上，风险在现场”的落差。
从服务视角看，信息安全管理的价值不仅在于防泄露、防攻击，还在于防止安全问题转化为服务中断、责任纠纷和客户信任损失。权限错配会导致业务异常，弱审计会放大误操作后果，供应链访问不受控会成为长期薄弱点，这些都直接影响服务稳定性，而不只是安全评分。
因此，本条必须与请求管理、变更管理、发布管理和供应商管理深度联动。权限开通是请求问题，高风险操作是变更问题，发布包和依赖项是发布问题，第三方接入是供应链问题。若安全控制不能嵌入这些过程，安全团队再努力也只能在事后补洞。
审核8.7.3时，最有价值的证据通常是控制点与服务流程的结合程度。例如高风险权限是否经审批和留痕，远程运维是否可审计，供应商访问是否可追溯，安全事件是否能快速联动到事件和问题流程。只要这些控制点能被真实抽样验证，信息安全管理就不再只是方针表态。
成熟组织在8.7.3上的显著特点，是它们把安全要求做成了现场习惯而不是临时检查项目。工程师知道高风险操作必须留痕，服务台知道权限请求必须核验身份，供应商知道访问必须走受控通道，管理层也能通过记录和报告看到控制是否真正有效。
因此，信息安全管理成熟的标志，并不是制度越厚越好，而是服务流程越走越自然地带着安全边界运行，既减少风险，也减少因为控制失序带来的服务损失。
从长期看，8.7.3 做得好的组织，安全控制不会被一线视作额外负担，而会被理解为保持服务稳定、保护客户信任和降低责任风险的必要条件。只要这种共识形成，安全与效率之间的冲突就会明显减少。
因此，信息安全管理真正成熟时，组织面对的不是“如何临时补安全洞”，而是“如何让服务流程天然更安全、更可追溯、更不容易失控”。
一旦安全边界被稳定嵌入服务流程，很多原本需要事后追责和补救的风险，就会在前端被自然拦下。
这也是为什么服务型组织的信息安全成熟度，往往最终体现在现场操作是否自然受控，而不是口号是否足够严格。
六、成文信息管理要求
- 保留服务安全要求、访问控制规则、安全检查记录和安全事件联动记录。
- 保留供应商安全要求、保密条款、审计记录和整改记录。
- 对高风险服务应保留更细致的日志、审批和验证证据。
七、常见误区及踩坑提醒
| 误区 | 表现 | 正确做法 |
|---|---|---|
| 把安全完全交给独立安全部门 | 服务过程本身缺乏安全控制 | 将安全要求嵌入服务请求、变更、运维和供应商管理 |
| 安全要求与服务现实脱节 | 制度严格，但现场普遍绕过 | 基于服务场景设计可执行控制 |
| 只重防护不重审计 | 出了问题无法还原责任和影响 | 加强日志、审批和访问留痕 |
| 忽略供应链安全 | 第三方访问成为薄弱点 | 对外部方设定访问、审计和保密控制 |