4. 退役与替换的治理框架与政策制定
密码算法退役与替换不是一次性的技术升级，而是一项跨越多年、牵涉多部门、受多重监管约束的持续性治理活动。技术团队能算出迁移工作量，却往往无法决定“谁批准停用 SHA-1”“谁承担迁移失败的合规责任”“哪些系统可以豁免”。这些问题的答案不在代码里，而在治理框架中。本节围绕治理组织架构、政策与标准制定、角色职责矩阵、合规映射以及治理流程与决策门禁五个方面展开，目标是让读者能够搭建一套可落地、可审计、可追责的退役治理体系。
一、三层治理组织架构
退役治理的组织架构通常划分为决策层、执行层和监督层，三层职责边界清晰，避免“技术团队既当运动员又当裁判员”。
决策层一般由首席信息安全官（CISO）、首席技术官（CTO）或密码管理委员会承担，职责是批准算法退役路线图、审批高风险系统的迁移方案、裁定豁免申请、分配预算与资源。决策层不介入具体技术选型，但对“何时停用、是否延期、谁承担风险”拥有最终决定权。
执行层由密码工程团队、应用开发团队、运维团队和业务系统负责人组成，负责资产盘点、影响面分析、迁移改造、灰度验证与上线切换。执行层需要向决策层提交可量化的迁移计划，包括系统清单、依赖关系、时间窗口和回退方案。
监督层通常由合规、审计与风险管理部门构成，独立于执行层，负责核查迁移进度真实性、验证密码配置是否符合政策、跟踪等保与密评整改项、留存审计证据。监督层的核心价值在于“用证据说话”，而非依赖执行层的自述。
三层之间通过固定的治理例会与报告机制衔接：执行层按月提交迁移进度与阻塞项，监督层按季度出具合规偏差报告，决策层在关键门禁点进行审批或裁决。
二、政策与标准制定要点
退役政策必须回答四个问题：禁用什么、允许用什么、何时完成、例外如何处理。一份可执行的政策文件通常包含以下要素。
- 算法清单与状态分级：将算法分为“禁止使用”“仅限存量兼容”“推荐使用”“强制使用”四类。例如 SHA-1、MD5、DES、RSA-1024 列入禁止类；RSA-2048、SHA-256 列入存量兼容或推荐类；SM2、SM3、SM4、SHA-384、AES-256 列入推荐或强制类。
- 时间节点：明确“停止新系统使用”“存量系统完成迁移”“彻底下线”三个时间点，避免只写“尽快迁移”这类无法审计的表述。
- 适用范围：区分核心业务系统、一般业务系统、测试环境、遗留系统，不同范围可设置不同宽限期。
- 例外与豁免机制：规定豁免申请条件、审批层级、有效期和补偿性控制措施。例如某工业控制系统因厂商固件限制无法升级，可申请 12 个月豁免，但必须部署网络隔离与流量监测。
- 技术标准引用：直接引用 GM/T 系列、GB/T 39786、NIST SP 800-131A 等标准，减少政策歧义。
三、角色与职责矩阵
治理框架落地时，最常见的失败原因是“人人有责等于无人负责”。RACI 矩阵是解决该问题的有效工具：R（Responsible）为实际执行者，A（Accountable）为最终责任人，C（Consulted）为被咨询方，I（Informed）为被通知方。下表给出一个可参考的示例。
| 治理活动 | 决策层 | 执行层 | 监督层 | 业务系统负责人 |
|---|---|---|---|---|
| 批准退役路线图 | A | C | C | I |
| 资产盘点与影响分析 | I | R | C | C |
| 迁移方案设计与实施 | I | R | C | A |
| 豁免申请审批 | A | C | C | R |
| 合规证据留存与审计 | I | C | R/A | I |
| 迁移完成验收 | A | R | C | I |
矩阵中的“A”必须唯一，否则会出现责任稀释。例如迁移方案设计由执行层负责执行，但业务系统负责人对业务连续性和验收结果承担最终责任，这种安排能防止技术团队单方面推进而业务方不知情。
四、合规映射：等保、密评与 GDPR
退役治理必须与外部合规要求对齐，否则迁移成果无法通过测评。三类典型合规要求的映射关系如下。
- 等保 2.0：在“安全计算环境”和“安全通信网络”条款中要求使用符合国家规定的密码算法。SHA-1、RSA-1024 等弱算法在等保测评中可能被判定为不符合项，退役计划应直接对应整改项。
- 密评（商用密码应用安全性评估）：重点核查密码算法、密码协议、密钥管理的合规性。密评对 SM 系列算法的使用有明确要求，退役政策应将 SM2/SM3/SM4 的替换路径纳入评估范围。
- GDPR：第 32 条要求采取“适当的技术措施”保障个人数据安全，弱加密算法可能被视为“适当性不足”。若系统涉及欧盟用户数据，退役计划需在数据保护影响评估（DPIA）中体现算法升级安排。
合规映射的实操做法是建立一张“合规条款—算法要求—系统清单—整改状态”对照表，由监督层每季度更新，确保退役进度与测评整改同步推进。
五、治理流程与决策门禁
治理流程的核心不是“画一条从盘点 to 上线的箭头”，而是在关键节点设置决策门禁（Gate），只有满足准入条件才能进入下一阶段。下图展示了一个典型的退役治理流程与门禁关系。
门禁的实际价值在于“不通过就不放行”。例如 G3 方案批准门禁中，若目标算法选型未通过密评预评估，或回退方案未覆盖核心交易链路，决策层应拒绝批准，而不是“先上线再补材料”。G5 验收门禁则要求监督层独立确认迁移证据，包括配置截图、抓包记录、密钥管理日志和测评报告，避免执行层自证清白。
六、落地建议与常见误区
治理框架落地时，有三个常见误区值得警惕。第一，把政策写成技术文档，导致业务部门看不懂、不执行；第二，门禁形同虚设，为了赶进度跳过 G3 或 G4，最终在密评或等保测评中暴露问题；第三，监督层不独立，由执行层兼任审计，导致证据可信度不足。
建议在启动阶段先完成三件事：成立跨部门治理小组并明确三层负责人；发布第一版算法禁用清单与迁移时间表；选择 1～2 个非核心系统进行试点迁移，用真实数据校准工作量与门禁标准。试点完成后，再将治理流程推广至核心系统，并同步更新合规映射表与 RACI 矩阵。这样既能控制风险，也能让治理框架在实战中逐步成熟。