关键信息基础设施审计（аудит КИИ）：基于证据的方法、标准与服务商选择

关键信息基础设施审计（аудит КИИ）的范围

关键信息基础设施审计（аудит КИИ）是一种结构化评估，用于判断支撑关键流程和服务的系统是否得到足够的保护、测试和治理，从而能够抵御现实威胁。搜索关键信息基础设施审计的人通常需要两个答案：一次可信的审计究竟检查什么，以及如何选择能够在不影响业务运行的前提下完成审计的服务商。本文先讲方法与证据，再讲服务选择。

本文的证据基础刻意采用国际通用的方法论资料：NIST SP 800-115关于技术安全测试，NIST网络安全框架2.0关于网络风险治理，OWASP测试指南、应用安全验证标准ASVS和Top 10关于应用层，MITRE CWE Top 25关于软件弱点的普遍性，CISA“设计安全”和“需求安全”资料关于采购，以及MDN的HTTP参考资料关于面向Web的协议层防护。

证据中没有什么同样重要。所提供的来源均未描述关键信息基础设施的国家法律制度、对象分级程序、向监管机构报告的格式或强制认证与许可。这些义务必须结合现行法律和监管文件，与法律顾问一起确认。本文将其视为审计的外部输入，而不做转述。

• 风险治理：目标、角色、现状与目标画像
• 技术测试：在约定范围内进行审查、扫描和漏洞验证
• 应用验证：针对Web界面和API、绑定标准版本的要求
• 供应商与产品保障：默认安全、更新与部署实践

延伸阅读网络分段验收测试：证明允许路径与禁止路径

可信的关键信息基础设施审计如何构建：NIST SP 800-115的阶段

NIST SP 800-115发布于2008年9月，取代了SP 800-42，至今仍是规划和实施技术安全测试与检查、分析发现并制定缓解策略的参考文件。其目的表述可直接对应审计阶段：规划、执行、分析、整改。

该指南区分了不同的测试目的，包括发现系统或网络中的漏洞，以及验证是否符合策略或其他要求。关键基础设施审计通常两者都需要：合规验证回答所需控制措施是否存在，漏洞发现回答这些措施是否真正有效。

NIST明确指出，SP 800-115并不是一套完整的测试计划，而是对关键技术手段的概述，并说明每种手段的优点和局限。对采购方而言，这意味着审计方案应当为所选的每种手段——文档与配置审查、扫描、渗透测试——给出理由，并清楚说明该手段无法证明什么。

与该指南相关的控制族——审计与问责；评估、授权与监控；风险评估；系统与服务获取；系统与通信保护；系统与信息完整性——可作为范围文件应覆盖领域的实用清单。

• 规划：范围、系统所有者书面授权、工作规则、排除的系统、停止条件
• 执行：审查、目标识别，仅在约定范围内验证漏洞
• 分析：根本原因、风险评级、与业务流程的关联
• 报告与整改：措施、责任人、期限、复测

支撑关键基础设施审计的框架与标准

NIST CSF 2.0帮助组织理解并改进网络安全风险管理，面向产业、政府和各类组织。框架包括画像、快速入门指南和信息性参考（与其他资源的映射）。在审计中，CSF承担治理层的作用：它把技术发现转化为管理层可以排序的风险结果。

CSF 2.0仍在持续维护。NIST于2026年2月24日庆祝CSF 2.0发布两周年，发布了最终版信息性参考快速入门指南，并在2026年10月15日前就使用人工智能进行CSF分析与报告的快速入门指南草案征求意见。引用CSF的审计人员应注明当前版本和所用画像。

在应用层，OWASP ASVS为测试Web应用技术安全控制提供基础，目标是统一市场上验证覆盖面和严格程度的差异。最新稳定版本为5.0.0。OWASP建议引用要求编号时附带版本，例如v5.0.0-1.2.5，因为编号可能在版本之间变化。对审计而言这关乎可追溯性：没有版本号，就无法明确比较两次评估的结果。

OWASP Web安全测试指南自称是面向开发者和安全专业人员的首要测试资源；当前发布版本为4.2，5.0版本正在开发中。OWASP Top 10 2025版是一份意识提升文件，代表了对最关键Web应用风险的广泛共识。它是起点，而不是详尽的测试标准。

弱点数据对关键信息基础设施审计优先级的启示

MITRE 2025年CWE Top 25列出了当年数据集中39080条CVE记录背后最严重、最普遍的弱点。据MITRE描述，这些弱点往往容易发现和利用，可能导致系统被完全接管、数据被窃取或应用停止运行。

MITRE同时发布了2025年CWE Top 10 KEV弱点清单，依据CISA已知被利用漏洞目录对正在被积极利用的弱点进行排名，并列出15个“处于边缘”、险些进入Top 25的弱点。这对审计排序很有价值：与KEV相关的弱点反映攻击者实际在用什么，而不只是理论上可能的风险。

MITRE指出，命令注入等弱点特别受攻击者关注，而根因分析有助于消除整类缺陷，例如内存安全问题和注入问题。同样的类别也反复出现在CISA“设计安全”警报中——缓冲区溢出、跨站脚本、操作系统命令注入、目录遍历——以及ASVS关于防范操作系统命令注入的示例要求中。三个独立来源相互印证，是审计应明确测试这些类别的有力依据。

实践结论：报告中的发现应映射到CWE编号，而不仅仅是扫描器插件名称。这样供应商和开发人员可以修复根本原因，管理层也能看到哪些缺陷类别在历次审计中反复出现。

Web界面、API与协议层防护

许多关键系统都提供Web管理控制台、门户和API。MDN将HTTP描述为采用客户端—服务器模式的应用层协议，请求之间无状态，而Cookie为部分交互增加了状态；HTTP也用于机器间通信和以编程方式访问API。因此审计必须覆盖身份验证、会话管理和Cookie使用，而不仅是外部边界。

MDN记录了多种通过响应头实现的防护机制。内容安全策略可控制页面允许加载的资源，有助于检测和缓解跨站脚本和数据注入等攻击。跨源资源共享控制站点如何响应跨站请求。跨源资源策略让站点选择防护某些跨源请求，以缓解推测执行侧信道攻击。权限策略明确限制站点代码可使用的功能和接口。MDN还列出了HTTP Observatory，这是一款帮助安全配置站点的工具。

响应头检查是审计中快速且低风险的部分，但不能替代基于ASVS的验证：访问控制、业务逻辑和输入处理需要人工工作，并与标准的具体要求对应。

供应商、产品与运营技术保障

CISA的“设计安全”倡议提出，客户安全应是核心业务要求而非单纯的技术功能：产品应开箱即安全，多因素身份验证、日志记录和单点登录应免费提供。已有超过200家软件制造商签署“设计安全”承诺，承诺朝七个关键目标做出真诚努力，其进展报告也已公开。

面向采购方，CISA发布了“需求安全”指南：一份供任何软件客户在采购谈判中使用，另一份针对运营技术所有者和运营者在选择数字产品时的优先考虑事项。澳大利亚网络安全中心还与CISA联合发布了选择安全且可验证技术的指南。对关键信息基础设施审计而言，这些资料提供了一套现成的供应商问题清单。

CISA还发布了包含2024至2025财年数据的漏洞回顾，介绍如何修复可预防的缺陷并缩小暴露面，以及强调测试与度量的安全软件部署指南。由此可见，审计不仅应评估当前状态，还应评估供应商如何发布更新以及组织如何部署更新。

延伸阅读容器基础设施安全：如何证明镜像准入并安全撤回版本

权衡：深度、业务中断风险与证据质量

基于文档的合规审查成本更低，对运行中的系统也更安全，但会遗漏控制措施纸面存在而实际失效的情况。技术测试能发现真正可被利用的问题，但需要仔细约定权限和边界。均衡的关键信息基础设施审计结合两者，并记录每个结论所依据的证据。

生产环境与测试环境的选择是关键系统最重要的权衡。建议以书面形式约定哪些系统允许主动测试、在哪些时间窗口进行、在什么条件下立即停止，并尽可能使用环境副本。这是组织层面的建议，并非所提供来源的要求；具有约束力的规则应向监管机构和系统所有者确认。

自动扫描与人工分析相辅相成。NIST强调每种手段都有优点和局限：扫描器提供广度，人工工作提供对逻辑、漏洞链和上下文的理解。仅依据扫描器输出的报告意味着审计不完整。

清单式方法与基于风险的方法同样需要平衡。OWASP Top 10是意识提升文件，按Top 10测试并不等于完整验证。ASVS和CSF提供更完整的结构，但必须结合具体基础设施的真实风险进行裁剪。

运营影响：从发现到整改

NIST SP 800-115把制定缓解策略视为测试过程本身的一部分。实践中，每项发现都需要责任人、期限、优先级和复测日期；否则审计只是一份没有效果的一次性文件。

面向管理层时，最好按CSF 2.0结果和CWE根本原因对发现进行归类。这样的报告展示的不只是漏洞数量，还能说明哪些治理结果未达成、哪些缺陷类别需要在开发或采购环节做出改变。

证据应以可复现的方式保存：带要求编号的标准版本、日期、工具、范围和排除项。这样可以比较历次审计并展示进展，而不是产生一系列无法比较的快照。

CSF的现状画像与目标画像让审计形成闭环：每次评估更新现状画像，与目标画像的差距决定下一次审计前的工作计划。

如何选择关键信息基础设施审计服务：向服务商提出的问题

只有在范围、目标和监管输入明确之后，才应进入服务商选择阶段。没有这些前提就比较关键信息基础设施审计的商业报价毫无意义，因为不同服务商报价对应的工作量并不相同。

要核实声明，而不是照单全收。关于许可、资质以及关键基础设施项目经验的说法需要书面证明；国家法律是否强制要求特定许可，必须与法律顾问独立核实。可以把CISA“需求安全”指南中的问题作为范本，它们正是为采购方与供应商的沟通而编写的。

警示信号包括：报告完全基于自动扫描结果；没有书面授权和工作规则流程；引用标准却不注明版本；没有复测；承诺保证通过监管检查；不愿解释所选手段的局限。

• 你们的方法如何对应NIST SP 800-115的各阶段，每种手段有哪些局限？
• 使用哪个版本的ASVS，是否引用带版本的要求编号？
• 是否将发现映射到CWE，并考虑KEV目录中的弱点？
• 针对关键系统，如何约定权限、测试窗口和停止条件？
• 结果如何与NIST CSF 2.0的结果和画像关联？
• 整改后是否包含复测？
• 向产品和运营技术供应商提出哪些基于“需求安全”的问题？

关键信息基础设施审计的实用决策框架

以下框架把证据基础转化为一系列决策。它不能替代监管要求，而是帮助把这些要求嵌入可重复的流程。

如果资源有限，应先执行降低风险最多的步骤：可从外部访问的系统、CWE Top 25和KEV清单中的弱点类别，以及缺失多因素身份验证和日志记录等基础功能的情况。然后按照CSF画像逐步扩大覆盖范围。

• 1. 与法律顾问和监管机构确认监管输入
• 2. 确定范围：系统、接口、供应商、排除项
• 3. 取得系统所有者书面授权并约定工作规则
• 4. 依据NIST SP 800-115选择手段，并说明理由和局限
• 5. 按带版本的ASVS要求和WSTG流程验证Web界面与API
• 6. 依据CWE Top 25和KEV排序，并用CWE术语表述发现
• 7. 按“设计安全”和“需求安全”标准评估供应商
• 8. 将结果与CSF 2.0画像关联，指定责任人并安排复测

结论：一次有力的关键信息基础设施审计（аудит КИИ）应交付什么

一次有力的关键信息基础设施审计（аудит КИИ）应将合规验证与技术测试相结合，依托带版本的标准，优先处理实际被利用的弱点类别，并以整改计划和复测收尾。NIST SP 800-115、CSF 2.0、OWASP ASVS、WSTG和Top 10、MITRE CWE Top 25以及CISA“设计安全”等国际来源为此提供了成熟的框架。

国家层面的关键信息基础设施要求仍是必须单独确认的强制性外部框架。选择关键信息基础设施审计服务时，应依据方法的透明度、授权流程和证据质量来评判服务商，而不是依据承诺是否响亮。

延伸阅读安全配置审计：检查范围、证据与验收标准