信息化项目验收中的安全审计：从承诺要求到可运营移交

“网络安全和信息化建设审计”可能指向多种不同工作。政府审计可能关注立项权限、采购程序、资金使用、资产登记、合同履行和建设绩效；安全团队更关心交付系统是否实现了承诺的安全控制，以及供应商退出后，建设单位能否安全运营。两类工作可以共享证据并相互支持，但它们不能替代彼此的结论。

对正在委托建设或准备验收的信息化项目，真正有用的安全问题更具体：每一项重要安全承诺，能否追溯到准确可识别的交付资产；能否在约定条件下证明控制有效；能否交给明确的运营责任人；未满足部分能否作为显式缺口由有权限的人处理？一套制作精美的制度文档或一次未发现高危漏洞的扫描，只回答了其中一部分。

本文给出采购方和建设单位可以采用的方法，不把它描述为任何地区通用的法定清单。采购、财务、行业监管、数据保护和认证方面的义务，仍应由建设单位相应的法律、财务、合规和业务责任人依据适用规则判断。

先明确审计需要支持哪一个决定

首先写清审计要支持的决定。“通过审计”过于模糊。审批机构可能是在决定是否支付里程碑款、登记资产、批准上线、接受剩余风险，或者结束供应商合同。这些决定需要不同的证据，也应由拥有不同权限的人签署。

财务或采购审计可以发现未经批准的采购、招标文件与正式合同不一致、软件资产未入账，或者在里程碑未完成前付款。绩效审计可以判断系统是否实际使用、是否产生预期公共或业务价值。法律或监管审查解释义务与正式审批。合同范围内的技术安全评估，则在明确边界内检查设计和实现的可观察行为。发现一个可利用的越权漏洞，并不自动证明违反采购法律；合同内容存在偏差，也不自动证明存在可利用漏洞。

各工作流可以使用同一套项目、资产、合同和发现编号，但结论应保留自己的性质。信息系统安全审计方法概览可以帮助确定控制域；项目验收还需要额外建立“承诺—交付—运行”的追溯链。

建立从承诺到决定的单一追溯链

核心工作底稿是验收追溯矩阵。每一行代表一项可测试的安全义务，或者一项已批准的例外。行首是权威要求来源，例如招标文件、任务书、合同、已批准架构、威胁模型、内部政策或变更单。行尾是决定责任人和当前状态。中间应明确交付了什么、运行的是哪个构建版本、通过什么观察验证控制，以及谁接手运营。

不要在未判断适用性的情况下，把通用框架的数百个条目原样复制进矩阵。对 Web 应用，公认的安全验证目录可以用于编写清晰要求，但合同应冻结目录版本和条目标识，因为标识会随版本变化。“符合最佳实践”无法告诉测试人员应验证什么，也无法告诉采购方何时有理由拒收。

这张矩阵并不替代总体审计计划。它解决的是另一种常见失败：收集了大量文档，却无法证明任何一份描述的就是生产候选版本。信息安全审计管理有助于组织参与者、范围和发现；追溯矩阵则把这些治理活动绑定到特定发布和移交。

1. 承诺固定需求来源、版本、适用性与责任人
2. 识别把承诺控制对应到交付资产和实际部署构建
3. 演示在授权环境观察允许、拒绝、故障与恢复行为
4. 移交证明客户已取得约定的管理、证据、支持与恢复控制能力
5. 决定由有权限的人接受、附条件接受、拒绝或延期处理缺口

评价控制前先核对实际交付系统

对错误版本开展安全测试，会生成精确却无关的证据。查看配置或执行测试之前，应先把交付包与验收环境核对。记录源代码修订或厂商版本、构建流水线运行、二进制或容器标识、基础设施与配置版本、数据库迁移状态、启用模块、第三方服务、租户，以及证据采集时间窗口。

这并不意味着每个供应商都必须交出源代码和全部底层开发记录。保障深度应与系统关键性、暴露面、数据敏感度，以及建设单位实际使用证据的能力相称。成熟供应商可以提供高层次的安全开发过程声明，并在内部保持到详细记录的可追溯性。当验收必须证明当前构建的具体行为、某项重要主张存在争议，或风险确实需要深入检查时，再要求发布级证据。

版本一致还不够，必须核对范围完整性。把合同交付清单、架构、云账户、域名、API、管理界面、移动客户端、后台任务、集成和远程支持连接，与实际环境观察进行比较。无法检查的部分要列为排除项，不能默认算作通过。如果报告形成后系统发生变化，应说明该变化只使某项测试失效、使一组控制失效，还是使整体验收结论失效。

用可观察演示补足纯文档审查

文档解释设计意图，演示说明控制在规定条件下表现如何，两者都需要。角色矩阵可以说明谁应该管理系统；受控演示则显示建设单位管理员是否真的能完成操作，以及低权限角色是否被拒绝。备份制度写明频率和保留期；恢复演示说明选定备份能否恢复出可用服务。日志规范列出事件；生成已知事件并导出，才能说明建设单位可以取得可归属的证据。

测试应同时有正向和反向对照。对特权访问，演示管理员获准操作、普通角色被拒绝、权限撤销以及对应审计轨迹。对备份，演示备份选择、完整性检查、恢复前提、加密密钥可用性，以及恢复后的业务级验证。对日志，生成一个已知事件，从源头追到存储，检查时间与主体字段、导出能力，以及中央收集器不可用时的行为。对供应商支持，启动一次获批会话，观察审批和操作记录，然后关闭会话并验证访问已经失效。

一次演示不能证明所有状态。记录环境、前提、测试身份、所用数据、期望结果、实际结果、时间、证据位置、清理动作和限制，才能把“控制有效”变成边界明确的结论。网络分段验收测试体现了同一原则：只有从代表性位置实际观察允许和拒绝路径后，网络图才不再只是一个假设。

证明运营控制权，而不只是交付成功

系统可能完成了功能验收，却仍无法由建设单位安全管理。在约定的服务模式和所有权边界内，移交应证明建设单位掌握身份、特权角色、域名、证书、密钥、备份、监控、合同约定的源代码或托管安排、部署工具、许可证和厂商门户。资产记录应标明所有者、环境、版本、支持状态、数据类别、依赖关系和退役路径。

所需控制模式取决于服务类型。对建设单位自行托管或定制开发的系统，移交可能包括部署资产、建设单位持有的管理角色、配置、恢复材料，以及合同约定的源码或托管权。对托管型 SaaS，客户通常不应取得服务商根账户、专有源代码或服务商签名密钥。验收应改为证明客户拥有约定的管理能力、数据和日志导出、身份集成、支持与恢复承诺、退出机制，以及明确的服务责任人。技术检查必须遵守共同责任模型和服务商的授权测试政策。

建设单位应使用自己控制的身份完成服务模式约定的日常管理任务。对合同明确把最高管理权交给建设单位的自托管或定制系统，供应商不能继续成为该权限的唯一持有者。如果持续支持需要远程访问，应规定每次会话由谁批准、如何执行强身份验证、操作记录存放在哪里、允许哪些网络和时间，以及如何撤销。应急访问的保管和演练也应符合服务模式。封在信封里的共享密码不能构成长期运营控制。

商业支持依赖也是安全边界。记录哪些补丁、签名、仓库、订阅功能、证书续期、托管密钥或恢复动作需要持续付费。明确支持年限、停止支持通知、响应级别、漏洞接收流程、更新真实性、分包商依赖，以及供应商停止服务时的替代方案。只有在未披露许可证持续有效时才工作的控制，并没有被完整描述。

合同退出也应有验收证据。明确建设单位如何取得或迁移属于自己或按合同可导出的数据、配置、日志、域名、密钥和运行知识；供应商如何在约定范围内删除副本和委派账户；完成情况如何验证。这不要求移交服务商的平台签名密钥或其他根级资产。第三方风险安全评估指南有助于持续观察供应商关系，项目矩阵则把这些问题绑定到已交付服务及其退出路径。

分开记录合同偏差、技术弱点与剩余风险

发现类型应把问题送到正确的决策者。合同偏差表示交付物或证据与协议不一致。技术弱点表示设计或实现中存在可观察状态，可能导致损害。证据缺口表示现有可信材料不足以建立主张。运营缺口表示所有权、监控、恢复、支持或退出尚未准备好。法律、财务或采购问题应转交有能力的审查者，而不应被写成未经支持的技术或法律结论。

同一个事实可能产生多个关联记录。例如在自托管或定制系统中，合同已把最高管理角色分配给建设单位，但供应商仍掌握唯一账户，合同团队需要检查责任分配，安全团队评估暴露和监控，运营团队可能在客户权限和恢复能力得到证明前阻止移交。可以关联记录，但不要合并结论。

每一个未解决项目都必须指定有权接受它的人。记录受影响资产和版本、业务后果、利用或失败前提、当前缓解、补偿控制、完成日期、支持依赖、复测触发条件和例外到期日。如果项目团队并不拥有服务、数据、预算或法定义务，“项目团队接受风险”就没有足够效力。附条件验收还应写明允许的运行边界，以及什么事件会使该决定暂停。

风险接受只是分配已确认的剩余风险，不能免除法律、监管、采购或合同中的强制义务。如果团队不确定某项义务是否允许例外，该事项应继续保持未关闭状态，直到有权限的责任人作出判断。

只在能回答明确主张时采用独立渗透测试

当建设单位需要针对暴露或高影响技术边界取得对抗性证据时，独立渗透测试很有价值。例如：用户能否跨越租户或角色边界；管理界面能否从非预期路径访问；支持人员能否绕过建设单位审批；网络分段能否阻断具有代表性的攻击路径。重大修复也可在最终验收前通过复测确认。

渗透测试不能替代资产核对、法律解释、采购审查、安全开发过程保障、备份恢复、运营培训或供应商退出计划。它只抽样检查约定时间内的约定环境，不能为整个项目提供认证，不能保证未来安全，也不能证明每一项合同承诺都已交付。

Pentest.red 可以在双方约定范围内，对系统和行为开展授权的技术渗透测试。由此形成的技术渗透测试报告不属于中国法定审计或认证结论，也不能保证项目通过验收。渗透测试范围规划工具可在测试前记录资产、发布版本、角色、排除项、测试账户、证据权限、停止条件和复测需求。

委托一套能够支撑后续运营的验收包

应要求供应商提供一套连贯的验收包，而不是一堆互不关联的文件。验收包应包括追溯矩阵；经核对的资产与发布清单；架构和数据流基线；访问与责任矩阵；控制演示记录；漏洞与整改台账；备份和恢复证据；日志生成和导出证据；支持、更新、许可证和生命周期依赖；建设单位运行手册；供应商访问关闭证据；已签署的剩余风险登记表。

还要预先确定证据处理方式。敏感配置、日志、测试数据、凭据和专有开发记录需要受控存储、保留、脱敏和访问。建设单位应取得足以复现结论的细节，但无需接收自己无法安全保护或正确解释的底层材料。一项有用的发现会标明准确资产和构建、观察、前提、影响、证据、建议动作、责任人和复测条件。渗透测试报告示例展示了如何分开可复现技术证据、影响和修复；项目验收记录还需要把发现连接到合同、运营所有者和最终决定。

因此，验收是一系列边界明确的决定，而不是一个“安全”印章。固定承诺，识别实际交付，观察控制行为，移交运营与恢复能力，再把每一个剩余缺口交给有权接受的人。即使结果是附条件接受，这种做法也能形成可审计的移交，并让技术测试如实说明它已经证明和未能证明的内容。