结论先行：国产化替换的项目验收与安全测评是两件事。前者确认系统能跑、业务能用，后者确认这套新底座在安全要求上站得住。操作系统与终端底座换掉之后，测评对象、边界与支撑材料都会变化，原先基于旧环境形成的材料通常不能直接沿用。可行的准备方式，是先把要重出的文档列成清单，再逐项对照新环境补证据。
为什么替换会牵动测评
安全测评核对的是当前这套环境是否满足要求，它看的是现网状态，而不是改造方案。替换动作会同时改动三样东西。
- 测评对象变了。被测评的系统、终端与承载平台换了底座，资产清单与拓扑关系随之变化。
- 边界变了。新底座带来的管理组件、日志通道与权限体系可能与原环境不同，测评要核对的安全边界需要重新划一遍。
- 证据变了。原来的截图、配置记录与审计日志样例对应的是旧系统，新环境下需要重新取证。
据公开的产品资料，国产桌面与服务器系统已内置可信度量、加密算法、访问控制与日志审计等能力，支持全程操作留痕与权限管控，日志留存周期可满足半年以上的审计要求。这些能力构成测评的支撑条件，但能力具备与材料齐备是两回事——测评要看的是可核对的记录。
要重出的三类文档
| 类别 | 内容 | 常见的返工原因 |
|---|---|---|
| 资产与拓扑类 | 新底座下的系统清单、终端清单、网络分区与管理通道说明 | 仍沿用改造前的清单，未更新替换后的实际状态 |
| 配置与策略类 | 安全策略配置、权限与账号体系、日志与审计配置 | 写了已配置，但缺少可对照的配置记录与生效范围说明 |
| 运行记录类 | 日志留存样例、审计记录、变更与审批留痕 | 日志有时长但字段不全，或留存范围未覆盖全部相关系统 |
四个容易漏的准备项
- 把新引入的组件登记进来。替换之后，环境里可能多出管理平台、运维代理、日志采集端这类组件。它们既不产出业务功能，也容易被排除在清单之外，但同样是测评的核对对象。
- 确认审计覆盖的是新环境。原来接进审计系统的对象，替换后是否还在采集范围内，需要逐个核对。只保留时长而不覆盖对象的日志，在测评中说服力有限。
- 把运维工具链的适配结果一起归档。监控采集、批量执行、备份代理、日志代理这几类工具在新底座上能否工作，适配记录本身就是可交付的证据。
- 提前约定由谁配合取证。测评现场需要业务方、运维方与平台方同时有人，接口人与联系方式的清单最好在项目启动时就定下来。
节奏怎么排
比较省事的顺序是：试点环境先把测评要用的记录格式跑通一遍，确认新底座能产出哪些日志与配置记录；批量迁移阶段按批次同步归档；全量完成后再正式进入测评。反过来，等全量替换结束才开始整理材料，等于把改造期间的操作记录全部补一遍。
把测评材料的产生过程前置到实施阶段，成本会低得多——实施过程中本来就会产生这些记录，区别只在于有没有被有意识地留存。
边界与前提
三点需要说明。其一，不同行业、不同系统等级适用的测评要求与周期并不相同，具体范围应以行业主管部门与测评机构的要求为准。其二，本文只讨论测评材料的准备口径，不涉及对具体安全能力的评价。其三，替换范围越大，材料重做的工作量越大，因此建议按批次分阶段归档，而不是集中在项目末期。
奇摩在多轮信创替换项目里，通常把系统替换与测评材料归档放在同一份清单里推进，避免上线之后再回头补记录。需要梳理这份清单，欢迎 预约咨询。