5.1 迁移路线图

5.1 迁移路线图

本节摘要：SOURCE 5.1 建议分阶段：发现与清单 → 风险评估 → 试点混合 TLS → 全量替换 → 持续监控。本节对照 NIST SP 800-208 等指南给出可执行里程碑。

核心问题

1. 建立密码资产 CBOM 清单
2. 划分 P0/P1 系统优先级
3. 设定 2025–2030 迁移检查点

一、阶段对照（SOURCE 5.1）

二、优先级矩阵

⚠️ 常见坑：未更新根 CA 与中间证书策略——叶子 hybrid 但链仍 RSA-2048。

💡 关键直觉：迁移是供应链项目，不是 OpenSSL 编译一次就结束。

要点速记

• CBOM 是第一步
• HNDL 决定 P0 系统
• 混合 TLS 试点验证性能
• 密码敏捷是长期能力

深入讨论：从资产清点到全量切换的执行细节

迁移路线图的第一步往往是最容易被低估的：资产盘点。所谓 CBOM（加密物料清单），是像软件物料清单一样，逐项登记每个系统里用到的密码算法、密钥载体、证书签发者与依赖库版本。很多企业的第一轮盘点会发现自己远比想象中依赖 RSA-2048——从内置数据库加密、消息队列 TLS，到每台设备里的默认证书。盘点不是一次性的，要建立持续更新的机制，把「新项目默认 PQC、旧项目纳入迁移队列」写入开发规范。

试点阶段要刻意选择「影响小、可回滚」的系统。典型做法是先在内部域名启用混合 TLS 套件，与业务团队约定性能基线（握手延迟、吞吐量、错误率），运行一个月观察兼容性问题。试点的价值不在于证明 PQC 本身可用，而在于暴露流程缺口：证书重签的审批路径、监控告警的配置、回退的执行脚本，这些在纸上看起来都简单，只有真实演练过才能确认可靠。

# 迁移路线图里程碑（建议 5 阶段）
阶段 1 资产盘点      建立 CBOM，识别 RSA/ECC 依赖，输出优先级矩阵
阶段 2 风险评估      按数据保密年限划分 P0/P1/P2，对齐 HNDL 风险
阶段 3 混合试点      内网启用 X25519MLKEM768，采集性能基线
阶段 4 全量推广      更新 CA 策略、CDN 配置、客户端 SDK，统一 Level
阶段 5 持续运维      算法清单配置化，演练回退与紧急经典模式
​

最后要强调「密码敏捷是长期能力」而不是一次性工程。PQC 迁移完成后，算法仍可能因攻击或合规变化再次调整，届时依赖的是迁移过程中沉淀下来的三样东西：可配置的算法列表、可重签的证书流程、可执行的回退剧本。把这三样做成组织能力，下一次算法轮换的成本就会指数级下降。

工程实践扩展：试点验收与推广放行标准

试点阶段最容易犯的错误是没有事先定义「放行」与「叫停」的标准，导致推广决策靠感觉。建议在试点启动时就约定三组数字：放行门槛（混合连接占比达到 95%、P99 握手延迟增量不超过 15 毫秒、无阻塞性互操作问题）、叫停条件（占比持续低于 90%、失败率超过 0.1%、出现证书链校验错误上升）与观察期（至少一个完整业务周期，覆盖波峰波谷）。试点报告就围绕这三组数字展开，结论是数据驱动的，而不是评审会上的主观判断。

推广阶段则要按「系统依赖关系」排序而不是按部门排序。先升级基础设施组件（CA、CDN、负载均衡、企业浏览器策略），再升级依赖它们的业务系统，最后处理存量客户端与旧证书。这样可以避免「业务系统已升级、基础设施还在经典」的半套状态，也能让问题在链路更上游被发现。

# 试点放行/叫停标准模板
放行条件
  混合连接占比 >= 95%
  P99 握手延迟增量 <= 15 ms
  连接失败率 <= 0.05%
  回退路径演练通过，脚本可执行

叫停条件
  混合占比持续 < 90%（超过 24 小时）
  失败率 > 0.1% 且原因未明
  出现证书链校验错误上升
  任一核心组件发现算法兼容性缺陷

观察期
  至少 1 个完整业务周期（含波峰波谷）
​

把放行标准写进试点方案，推广就不再是一次豪赌，而是把已验证的配置复制到更多节点。迁移路线图的每个阶段都配一张这样的验收表，整条路线就变成了可以逐阶段签字确认的工程流程。