多云安全评估：基于证据的范围界定、方法论与服务商选择指南

多云安全评估涵盖哪些内容

多云安全评估是一项经资产所有者授权的结构化审查，用于检验组织对分布在多个云服务商上的工作负载、身份、数据和应用的保护程度。它回答一系列实际问题：每个环境中存在哪些安全控制、这些控制是否一致落实、哪些弱点可被实际利用、应当优先修复什么。本文先说明如何借助公开且持续维护的参考标准界定范围并开展评估，然后再讨论如何评价和采购多云安全评估服务。

多云的核心难点通常不在于某一家服务商，而在于服务商之间的衔接处。每个平台通常拥有各自的身份模型、日志格式、网络结构和默认配置，因此在一个环境中很强的控制，在另一个环境中可能缺失或配置不同。评估必须做到同类比较：在范围内的每个环境中，以相同方式衡量相同的安全结果。

在实践中，评估范围涵盖四个层面：治理与风险管理、云基础设施与配置、身份与访问、以及运行在其上的应用和API。本文所用的参考资料可以自然地对应到这些层面，因此构成了下文方法论的主干。

• 治理：用NIST CSF 2.0表达目标安全结果和风险归属。
• 基础设施与配置：依据NIST SP 800-115规划技术检查与测试。
• 身份与访问：跨服务商边界的身份联合、令牌、MFA和SSO。
• 应用与API：以OWASP WSTG和ASVS进行验证，以OWASP Top 10提升意识。
• 优先级排序：以CWE Top 25及基于KEV的弱点排名标注根本原因。

延伸阅读共享安全依赖与恢复的信息安全架构设计

分析方法与证据基础

本文依据八份公开参考资料：NIST SP 800-115提供测试技术，NIST CSF 2.0提供风险结果框架，OWASP Web安全测试指南、应用安全验证标准和Top 10覆盖应用层，MITRE的CWE Top 25用于弱点优先级排序，CISA的“设计即安全”资源阐明产品与采购期望，MDN的HTTP文档覆盖面向浏览器的安全控制。

这些资料均不针对特定云服务商，也没有发布多云安全事件统计数据。这是有意为之的限制：方法论不重复未经核实的市场数字，而是依靠可在每个环境中同等适用的中立标准。文中描述的多云典型特征，均应视为需要在自身环境中核实的考量因素，而非经过测量的事实。

文中引用的数字，如发布日期、版本号、贡献者数量和数据集规模，均直接来自参考页面。它们反映了各项标准的成熟度和时效性，在将这些标准写入评估工作说明书时尤为重要。

治理层：以NIST CSF 2.0作为共同语言

NIST将网络安全框架描述为帮助组织更好地理解和改进网络安全风险管理的工具。在多云环境中，它的主要价值在于中立性：CSF的结果不依赖任何服务商的术语，因此可以定义一个统一的目标状态，并据此衡量每一朵云。

CSF 2.0配套提供了对评估规划直接有用的材料：面向常见目标的快速入门指南、用于创建配置文件的模板与资源，以及展示NIST各类资源相互关联的参考映射。一种实用做法是为组织建立一个目标配置文件，为每个云环境分别建立现状配置文件，再把两者之间的差异作为评估需要核实和细化的差距清单。

该框架处于持续维护之中。NIST于2026年2月24日庆祝CSF 2.0发布两周年，并发布了SP 1353初始公开草案，即关于使用人工智能进行CSF分析与报告的快速入门指南，征求意见截止日期为2026年10月15日。考虑借助人工智能汇总多云评估结果的团队，应将其视为草案，并按照NIST参考映射指南的建议，将人工智能支持与持续评估和改进相结合。

测试方法论：在不同服务商间应用NIST SP 800-115

NIST SP 800-115《信息安全测试与评估技术指南》于2008年9月发布，取代了SP 800-42。其宗旨是帮助组织规划和实施技术性安全测试与检查、分析发现并制定缓解策略。其关键词包括渗透测试、风险评估、安全评估和漏洞扫描，恰好对应多云评估所组合的各项工作。

该指南明确指出，它并不是一套完整的测试计划，而是对关键技术手段及其优势、局限和使用建议的概述。这一定位非常契合多云工作，因为没有任何单一技术能看清全部。配置审查揭示控制如何设置，漏洞扫描揭示暴露服务中的已知弱点，渗透测试则验证弱点能否串联成真实影响。可信的测试计划应说明哪种技术用在何处，以及每种技术无法发现什么。

该文件的年代也是需要坦然承认的局限。2008年的文件早于大多数云原生服务，因此它提供的是规划、执行和报告的规范，而不是针对云的测试用例。评估人员必须将其各阶段转化到托管服务、无服务器函数和服务商特有的身份系统上，并记录转化方式。

授权是第一道关口。在任何主动测试之前，应取得资产所有者的书面批准，列明范围内的账户、订阅或项目，约定测试时间窗口和停止条件，并核实每家服务商当前关于客户自行发起安全测试的政策。由服务商自身运营的组件，通常不属于客户可以单方面授权测试的范围，因此计划中应说明此类发现的处理方式。

应用与API层：OWASP WSTG、ASVS和Top 10

多云环境中的大量业务风险通过应用和API显现，OWASP为此提供了三项互补的资源。Web安全测试指南是OWASP旗舰项目，自称是面向Web应用开发人员和安全专业人员的首要测试资源。当前发布版本为4.2，5.0版本正在开发中，项目列出184名贡献者。

应用安全验证标准为测试Web应用技术安全控制提供基础，并为开发人员提供安全开发要求清单。其主要目标是统一市场上Web应用安全验证在覆盖范围和严格程度上的差异。最新稳定版本为5.0.0，列出141名贡献者。对多云而言尤为重要的是，ASVS不仅涵盖应用自身的控制，还涵盖应用所依赖的环境中的技术安全控制。

ASVS还解决了报告难题。每项要求都带有包含版本前缀的标识符，例如v5.0.0-1.2.5，要求清单以CSV、JSON等格式发布。当同一应用部署在两朵云上时，引用相同的带版本要求即可直接比较结果，并以程序方式导入跟踪工具，而无需调和两家供应商各自的私有检查表。

OWASP Top 10目前为2025版，此前有2021版和2017版，它是一份意识提升文档，代表业界对最关键Web应用风险的广泛共识，列出199名贡献者。它适合与管理层沟通和建立基线覆盖，但并非测试规范。仅承诺“按Top 10测试”的合同，其约束力远低于引用WSTG测试流程和具体ASVS要求的合同。

借助CWE Top 25和KEV数据确定优先级

多云评估会产生大量发现，优先级排序决定了这项工作能否带来实际改变。2025年CWE“最危险软件弱点Top 25”基于39080条CVE记录得出，突出那些往往容易发现和利用、并可能导致系统被完全接管、数据被窃取或应用停止运行的弱点。

MITRE还发布了2025年CWE Top 10 KEV弱点清单，依据CISA已知被利用漏洞目录对正在被积极利用的弱点进行排名，并列出另外15个处于入选Top 25边缘的弱点。MITRE指出，命令注入等某些弱点类别会吸引攻击者的关注，这支持按真实利用情况而非单纯严重性排序修复。

一种实用做法是，无论发现位于哪朵云，都为其标注CWE标识符。这样可以跨服务商分析根本原因：如果同一弱点类别在三个环境中反复出现，修复应落在共享代码、基础设施模板或部署流水线上，而不是三个互不相关的工单。MITRE明确将根本原因分析视为消除整类缺陷、降低部署后成本的途径。

各云之间应保持一致的边缘与HTTP控制

部署在不同云中的应用，往往位于不同的负载均衡器、内容分发层和网关之后，而每一层都可能添加、删除或改写响应头。MDN的HTTP参考文档描述了需要一致验证的浏览器侧控制：内容安全策略有助于检测和缓解跨站脚本和数据注入等攻击；跨源资源共享控制站点如何响应跨站请求；跨源资源策略允许站点选择防护某些跨源请求，以缓解推测执行侧信道攻击。

MDN还介绍了HTTP认证、为无状态协议增加状态的Cookie以及重定向。这些都是服务在多家服务商之间复制时常见的偏差来源。MDN列出了Mozilla的HTTP Observatory工具，用于帮助安全地配置站点，也可以用来比较各云中等效端点对外可见的响应头状况。

评估应针对范围内的每个端点，记录究竟是哪个组件设置了每个响应头。这样修复才能落在正确的层面，而不会在一朵云中修好、在另一朵云中被遗忘。

• 镜像端点上均存在且等效的Content-Security-Policy。
• CORS策略保持一致，不会在某个环境中更宽松。
• 在提供敏感资源的位置应用Cross-Origin-Resource-Policy。
• 各部署中的Cookie属性和认证流程完全一致。
• 核实重定向行为，确保没有环境暴露意外路径。

延伸阅读俄罗斯央行信息安全审计：先确定义务，再选择检查方式

权衡与局限

广度与深度。覆盖所有云中所有账户的评估可以形成统一的全景图，但测试往往较浅；对单个关键应用的深度测试能提供利用级别的证据，却无法反映整体状况。常见的折中做法是交替进行：先做广泛的治理与配置基线评估，再在风险集中处开展有针对性的深度测试。

标准化与平台原生精度。中立框架使结果可比，但可能遗漏仅存在于某一平台的控制。服务商原生工具能看到这些细节，但其输出无法直接比较。稳妥的方法是以中立框架打分，并附上原生工具的证据作为细节。

自动化与专业判断。自动扫描可以扩展到所有云，但SP 800-115对每种技术局限性的强调提醒我们，工具会遗漏业务逻辑缺陷和串联问题，这些需要熟练的人工测试。

时间点与持续性。报告记录的是某一时刻，而云环境在不断变化。应把每次评估视为对持续监控的校准，以及检验监控能否发现这些问题的机会，而不是安全证书。

对安全团队和平台团队的运营影响

日志。CISA的“设计即安全”原则要求产品开箱即安全，并且MFA、日志和SSO等功能应免费提供。评估期间应核实每朵云的日志是否已启用、是否得到保留、是否以可比形式集中汇聚。一个环境中的日志缺口，可能让整个环境的事件响应失明。

身份。跨云身份联合使风险集中在令牌和断言上。CISA曾举办“设计即安全”专题活动，讨论如何保护令牌和断言免遭伪造、窃取和滥用，这反映了该领域的核心地位。评估应追踪身份和信任关系如何跨越服务商边界，以及单个失陷凭据可能触及的范围。

修复责任。将每项发现映射到责任人、CWE类别、CSF结果，并在适用时映射到ASVS要求。这样平台、应用和治理团队各自看到自己负责的部分，管理层则能看到相对于目标配置文件的进展。

复测。SP 800-115把制定缓解策略视为评估生命周期的一部分。应在计划中预留复测预算，确保每项修复在问题出现过的所有环境中得到确认，而不仅仅是最初报告的那个环境。

采购建议：如何选择多云安全评估服务

只有在范围和方法明确之后，选择服务商才有意义。CISA的“需求即安全”指南面向在与第三方经销商或服务提供商进行采购洽谈的软件客户，澳大利亚信号局澳大利亚网络安全中心与CISA联合发布的关于选择安全且可验证技术的指南也直接面向采购组织。两者都强调同一原则：要求可验证的证据，而不是营销说法。

已有200多家软件制造商签署了CISA“设计即安全”承诺，承诺朝着七个关键目标做出善意努力，CISA会公布它们的进展报告。评估工具链中的工具供应商是否发布了此类报告，是一个合理且可核实的问题，但需要记住，承诺并不等于认证。

在评价云安全评估服务商时，应要求对方提供：列明标准名称及版本的方法论文件；带有CWE标注和可复现证据的脱敏报告样本；明确说明团队测试过哪些云平台和服务类型；授权与交战规则模板；以及涉及服务商托管组件的发现如何处理的说明。

• 警示信号：方案只承诺“符合Top 10”，却未列出WSTG流程或ASVS要求。
• 警示信号：没有带版本的引用，结果无法跨年度或跨云比较。
• 警示信号：复测被排除在外，或被当作事后附加项报价。
• 警示信号：对书面授权和服务商测试政策的回答含糊其辞。
• 警示信号：将单云工具宣传为多云能力却缺乏证据。

实用决策框架

以下步骤将证据转化为决策。每一步都会产出下一步所依赖的成果，因此很容易看出服务商方案或内部计划哪里不完整。

选择内部评估还是外部评估，取决于独立性要求、技能和规模。内部团队适合持续的配置审查和复测。当需要独立保证、内部对某家服务商的专业能力不足，或需要对关键应用进行利用级别测试时，外部评估人员更有价值。许多组织将两者结合：内部依据CSF配置文件进行持续基线检查，外部则按WSTG和ASVS定期开展深度测试。

• 1. 定义CSF 2.0目标配置文件，并为每朵云建立现状配置文件。
• 2. 盘点环境、账户和责任人；确认书面授权及每家服务商的测试政策。
• 3. 依据SP 800-115为各层选择技术，包括审查、扫描和渗透测试，并说明其局限。
• 4. 以带版本的ASVS 5.0.0要求和WSTG流程规定应用验证内容。
• 5. 为发现标注CWE标识符，并依据Top 25和基于KEV的排名确定优先级。
• 6. 逐个端点比较各云的边缘与HTTP控制。
• 7. 分别按单云和跨云出具报告，突出反复出现的根本原因。
• 8. 在所有受影响环境中复测修复，并将结果纳入持续监控。

结论：让多云安全评估真正支撑决策

当每个环境都按照相同的结果衡量、所用技术的局限清晰可知、并且按根本原因而非按云来排序时，多云安全评估才算成功。NIST CSF 2.0提供共同目标，NIST SP 800-115提供测试规范，OWASP WSTG、ASVS和Top 10提供应用层深度，CWE Top 25和KEV数据提供优先级依据，MDN的HTTP指南则覆盖边缘检查。

这一证据基础存在明确局限：其中没有针对具体服务商的基准数据，也没有多云数据泄露统计，而核心测试指南发布于2008年。处理这些局限的最佳方式是坦诚面对：明确引用带版本的标准，坚持书面授权和复测，并依据可验证的方法论而非宣传承诺来采购多云安全评估服务。

延伸阅读云安全架构：安全验收 landing zone 中的云账户