5.3 风险管理

5.3 风险管理

本节摘要：SOURCE 5.3–5.4 与 6.x：需管理算法被破、互操作失败、合规滞后与「密码敏捷」能力。本节对比风险类型与 mitigation。

上手前先明确

1. 建立 PQC 风险登记册
2. 设计算法失效时的回退剧本
3. 解释 Crypto-Agility 在配置层的落地

一、风险对照（SOURCE 5.3）

二、密码敏捷（SOURCE 5.4）

• 配置驱动算法列表，非硬编码
• 证书支持多公钥算法
• 定期演练「仅经典」紧急模式

⚠️ 常见坑：禁用经典算法做「纯 PQC 强制」——旧客户端全断。

💡 关键直觉：PQC 迁移风险管理 = 技术 + 供应链 + 合规三轴。

核心回顾

• 跟踪 cryptanalysis 与 NIST 公告
• 混合+回退保互操作
• Crypto-Agility 要演练不能纸上谈兵
• 长期保密数据优先迁移

深入讨论：把风险登记与回退演练做成可运营的机制

风险管理章节最容易变成一纸空文，原因是风险清单列出来之后没有对应的运营动作。要避免这种情况，可以借鉴三条可执行的做法：第一，把「算法失效」当成一个具体的运营事件来管理——订阅 NIST 安全公告与密码会议论文的跟踪渠道，设置专门的监测指标，例如某个算法被攻破的论文一旦发布，四小时内要触发评估流程；第二，把回退路径写进配置并定期演练——不止是「知道可以回退」，而是真实执行一次「仅经典模式」的切换，确认旧客户端能重新连上、监控告警能正常工作；第三，把合规检查做成自动化——把算法清单、安全级别与 FIPS 编号写进供应链物料，让审计方可以一键核验。

风险管理还有一个常被忽略的维度：人的认知。许多团队对 PQC 的认知停留在「等标准出来再说」，等到标准真正发布时，又发现缺乏参数选型、混合部署与证书重签的预案。把迁移培训纳入年度安全演练，让运维、开发与合规三拨人至少做过一次混合 TLS 试点，比任何文档都更能降低迁移初期的混乱。

# PQC 风险管理登记册模板（示例条目）
风险：Kyber 参数被新的代数攻击削弱
触发：公开论文发布 + 攻击复杂度低于设计安全级别
影响：受影响连接会话密钥可恢复，需评估存量密文
预案：启用配置开关切换到第四轮备选 KEM（如 BIKE）
验证：季度红蓝演练，模拟算法下线后的完整切换
负责人：密码平台组；评审频率：每季度

风险：混合套件导致老客户端握手失败
触发：混合连接占比异常下降告警
影响：部分存量用户无法访问业务
预案：回退到纯 ECDH 套件，保留双套证书
验证：上线前在灰度环境复现老客户端回退路径
​

风险登记册的价值不在条目本身，而在它驱动的演练与复盘循环。每一次演练发现的新问题（证书链不匹配、CDN 缓存策略、客户端版本碎片化）都会反过来丰富下一轮的迁移清单，让整条 PQC 迁移之路越走越顺。

工程实践扩展：回退演练的执行与复盘

回退演练最常见的失败方式，是「演练脚本写得完美，执行时才发现没有人会跑」。要避免这一点，演练必须满足三个条件：脚本由执行人维护而不是安全团队代笔；演练在真实或仿真环境执行而不是只在文档里跑通；演练后强制复盘并更新脚本。只有真实执行过的回退路径才值得在应急时刻依赖。

复盘环节要区分「演练问题」与「系统缺陷」。前者是脚本本身的疏漏，比如步骤遗漏、权限不足、依赖的证书备份没准备好；后者是系统设计的问题，比如经典套件配置被新策略覆盖、回退后监控指标缺失。两者的处理方式完全不同：脚本问题改脚本，系统问题要回归设计。只有把它们分开，演练的产出才能准确指导下一轮建设。

# 回退演练复盘模板
演练目标      在 X 分钟内将混合套件回退到经典模式且业务不中断
执行结果      目标达成 / 部分达成 / 失败
问题分类      脚本疏漏（记录） vs 系统缺陷（回归设计）
关键数据      回退耗时、业务影响窗口、监控告警是否及时
遗留项        未验证的场景（如跨域证书链）与责任人
改进动作      更新脚本 + 补测试 + 排期复演
​

把演练当成和功能发布同等级别的工程活动来对待，回退能力才不是纸面资产。PQC 迁移的全过程充满不确定性，唯一能确定的是「越早开始演练，越能尽早暴露并消化这些不确定性」——这正是风险管理章节存在的意义。