8.2 云服务商安全能力评估

8.2 云服务商安全能力评估

本节摘要：把核心业务交给一家云服务商，本质是把半条命交给一个陌生人。本节给一套尽调方法：评什么（安全、合规、韧性、退出四域）、拿什么评（问卷、证据、透明度记录）、怎么下结论（分级与残余风险签字）。

选云如选合伙人

评估云服务商容易犯两个方向性错误。一是把它当买家电：比价格、比功能清单，安全只看"有没有等保认证"这类勾选项。二是把它当面试员工：层层拷问细节，却忘了自己的能力边界——问出来的答案也鉴定不了真伪。正确的定位介于两者之间：像尽调一个合伙人，看它的治理结构（安全组织与责任分离）、看它的履历（历史事故与处理记录）、看它的家底（认证与审计报告的覆盖面）、还要试驾（合同条款与支持响应）。

评估的输出不是"好或坏"的结论，而是分级的信任面：哪些能力信到可以直接依赖（认证覆盖、审计报告背书）、哪些要自己验证（配置类控制的抽查）、哪些要额外补偿控制（不覆盖的场景自建监控或兜底）。这个分级直接决定 4.4 的架构决策与 7.2 的合同条款——尽调不是采购流程的橡皮章，是后面两章工具的输入。

评什么：四域清单

安全能力域：基础设施与租户隔离的实现与验证（4.1 的问题清单直接可用）、身份与访问的厂商侧治理（特权管理、后台访问的审计）、数据保护能力（加密默认值、密钥服务的能力边界、3.2 三档托管模式的支持度）、安全能力供给（日志接口的丰富度与延迟、告警集成、配置核查接口）——最后这条最常被漏：厂商自身的安全能力再强，与你打通的"可视接口"不够，你的运营域（第六章）就是瞎的。

合规域：认证清单与你所担数据的覆盖对表（认证覆盖的是基础设施还是含数据服务、覆盖哪些区域）、法规配合度（监管问询时的响应机制、数据本地化选项）、透明度记录（历史事故的公告质量——公告写得清楚、补救具体、时间线完整的厂商，比零事故宣传更可信）。

韧性域：可用性架构（区域与可用区的冗余模型）、历史可用性的实测记录（对照 7.2 的 SLA 口径）、灾难恢复能力（数据出口、跨区恢复的演练记录）。

退出域：数据可携带性（导出格式与完整性）、退出协助流程、以及最容易被忽略的"锁定成本评估"——今天进来容易，两年后搬家多疼，8.3 会用得上这份评估。

推演：一次尽调的完整流程

背景：某公司为新业务选云，候选两家，数据含核心级用户信息。

第一步，问卷与证据并收：发放基于控制矩阵裁剪的问卷（8.1 的裁剪功夫用在这），同时索取认证证书（看范围页不是看名字）、审计报告摘要、历史事故公告。第二步，证据核验：证书查覆盖范围（基础设施级认证不等于数据服务级合规）、报告查发现项整改的跟踪描述、公告查时间线完整性。第三步，试用验证：用测试账号实测两家最容易穿帮的两处——日志接口的完整性与延迟（第六章的生命线）、密钥服务的三档模式与轮换体验（第三章的生命线）。第四步，结论分级：两家各出信任面清单，不覆盖项列出补偿控制及成本，残余风险按 7.3 登记册格式报管理层签字。

推演的结论往往反直觉：总分高者未必胜出——对本次业务的数据类型与合规路径，覆盖面对口的那个才是对的。尽调的价值不在排名，在对口。

评估的持续运营

尽调不是一次性仪式。认证有年度周期（续证要追踪）、事故公告要订阅（新事故触发补充评估）、接口与能力在演进（年度复评一遍关键项）。把复评排期写进 6.3 的合规检查日历，把厂商公告接入第六章的情报源——服务商评估从采购动作变成运营动作，才是生态域的正确姿势。

尽调问卷新增条目的来源

尽调问卷不是一次性定稿的文物，它需要持续进料。三个稳定的进料来源：其一，本册各章的"自查清单"——第二、四、五章的组件点检、身份周检、API 八问，裁剪后都是现成的问卷条目；其二，7.1 的法规差异变量——新法规生效，问卷里对应的数据条款与跨境条目同步更新；其三，8.4 的技术雷达——新技术进入"采用或试验"环，问卷加一条"该能力是否提供、何种形态"。问卷的版本管理因此重要：每版问卷标注日期与修订理由，三年后回看，问卷的修订史就是组织风险认知的成长史。

给一个新增条目的实例演示。智能检测进入"采用"环后，问卷加一条："贵平台的审计日志是否支持导出到外部分析系统？导出的字段与延迟是多少？"——这条看似普通的条目，实测时能同时检验厂商的开放程度与日志管道的成熟度，一箭双雕。

结论分级与残余风险的呈现

尽调报告的最后一公里是呈现。给一个三段式模板。第一段，信任面清单：可直接依赖的能力（认证背书、报告覆盖、实测通过），逐条注明依据。第二段，验证面清单：需自建补偿控制的能力（厂商不覆盖的场景），逐条注明补偿方案与成本。第三段，残余风险与建议：按 7.3 登记册格式给出风险条目，标注建议的决策（接受并监测、谈判条款后再签约、放弃）。三段式的纪律是"每条能力都有归属段"，没有中间态——"感觉还行"这样的结论在尽调报告里是废纸。

呈现的最后一步是签字：残余风险的接受者必须是业务决策者而非安全团队自己——这一步把尽调从技术报告升格为组织决策。8.2 开头说"尽调是后面两章工具的输入"，现在补上后半句：尽调的输出同时是 7.3 登记册的新条目与 7.2 谈判桌上的筹码，工具环环相扣，生态域才算读完。

尽调会谈的四问实操

报告与问卷之外，与厂商安全团队的当面会谈最能试出深浅，四个问题按序问。一问"上次重大事件的时间线与改进项"：答得出具体时点与闭环证据的，说明响应体系真实运转过；只说"从未出事"的反而要警惕。二问"你们最近一个季度为配置失误做的自动化拦截"：考察的是把人因问题机器化的习惯，与 6.3 同源。三问"多租户隔离的验证频率与方法"：隔离开关是厂商的责任域，但验证节奏暴露自信程度。四问"如果我们自带密钥并要求可独立作废，流程怎么走"：把 3.3 的密钥治理直接压给对方，答得清流程细节的，数据面的合作基础就稳了。四问的共同点：都问运行证据，不问能力承诺。

本节要点回顾

• 选云如选合伙人：评估对象是能力的可验证性，不是功能清单的长度。
• 四域清单加三档结论：信任面、验证面、残余风险三段式，每条能力必有归属，不留"感觉还行"。
• 认证看范围页：覆盖范围之外的系统，认证不作数（7.1 的读法在尽调里兑现）。
• 会谈问运行证据：事件时间线、拦截自动化、隔离验证、密钥独立作废，四问试深浅。
• 残余风险的接受者是业务决策者：尽调因此从技术报告升格为组织决策，输出同时是登记册条目与谈判筹码。

一个延伸之问：尽调年年做，怎么避免走形式

尽调最常见的退化是变成"收文件盖章"的年度仪式。防退化靠两招。第一招，问题库滚动更新：去年的问答题今年不许原样再问，问题库按上一年度行业的真实事件更新——勒索高发的年份问备份隔离与恢复演练时长，供应链事件高发的年份问构建环境管控，问的问题贴着最新的威胁形态走，厂商的回答才含真实信息量。第二招，抽查穿透：每轮尽调从答案里挑一条穿透验证——厂商说"备份每日演练恢复"，就要求看最近一次演练记录与恢复时长数据。穿透不必多，一年两条，但它的存在本身就是威慑：知道你会穿透，答卷的含水量自然下降。尽调是持久战，它的质量取决于采购方让厂商相信"这次又要来真的"。

量完了厂商，下一节把镜头转回自己：搬家（上云、迁云、现代化）的时候，安全怎么打包。