1. 课程导入与密码敏捷性定义
在传统的信息系统建设中，密码往往被视为一个"装好就不用再动"的基础设施：系统上线时选定一套算法和密钥长度，此后多年不再调整。然而近十年的安全实践反复证明，这种"一次选型、长期固化"的模式正在成为重大风险来源。SHA-1 被实际碰撞攻破、RSA-1024 逐步退出合规清单、TLS 1.0/1.1 被主流浏览器禁用、以及 NIST 后量子密码标准的陆续发布，都意味着密码算法的生命周期远短于业务系统的生命周期。密码敏捷性（Cryptographic Agility）正是为应对这一矛盾而提出的架构能力。
本章作为全课程的导入，需要先厘清三个问题：密码敏捷性到底是什么、为什么现在必须做、以及本课程将带大家走到什么程度。后续 29 章将围绕架构设计、算法替换机制、迁移工程与验证方法逐层展开，本章则建立共同的概念基线和学习地图。
一、密码敏捷性的核心定义
密码敏捷性是指：系统在不改变业务逻辑、不重写核心应用代码、不中断服务的前提下，能够以可控成本替换密码算法、密钥长度、协议版本、证书体系乃至密码服务提供方的能力。这个定义包含四个关键限定，缺一不可：
- 不改变业务逻辑：替换密码组件不应迫使业务模块重新设计数据模型或接口语义。
- 不重写核心代码：算法调用应通过抽象层收敛，而非散落在成百上千处硬编码调用点。
- 不中断服务：支持灰度切换、双算法并行、平滑回滚，而非"停机割接"。
- 成本可控：替换工作量可预估、可度量，而不是每次都要做全量代码审计。
需要特别区分两个容易混淆的概念：算法可替换与密码敏捷。前者只是"能换"，后者强调"换得起、换得稳、换得可验证"。一个系统如果把 AES 调用封装成一个函数，看似可替换，但如果密钥管理、证书链、数据持久化格式、上下游协议全部与具体算法绑定，实际替换时仍需大规模改造，这就不具备真正的敏捷性。
二、三大业务驱动因素
合规驱动是最直接的推力。等保 2.0、密评（商用密码应用安全性评估）、《商用密码管理条例》以及金融、能源等行业监管细则，都对算法选用、密钥长度、协议版本提出了明确要求，且这些要求会随版本更新而变化。系统若不具备敏捷性，每次合规基线调整都可能演变为一次大规模改造项目。
威胁演进驱动是持续的压力。经典威胁包括算法被攻破（如 MD5、SHA-1 碰撞）、密钥长度不足（RSA-1024 已不满足现代安全强度）、协议漏洞（如 POODLE 针对 SSL 3.0）。而"先收集、后解密"（Harvest Now, Decrypt Later）策略使后量子迁移具有时间紧迫性——今天被截获的长期敏感数据，可能在量子计算机成熟后被回溯解密，因此迁移必须提前于威胁兑现。
技术升级驱动则来自正向需求：国密算法（SM2/SM3/SM4）的推广应用、后量子密码（ML-KEM、ML-DSA 等）的标准化、硬件密码模块（HSM）与云密码服务的演进，都要求系统能够平滑接入新算法而不推翻既有架构。
这三类驱动有一个共同特征：变化是常态，且变化的时间点不由我们决定。这正是敏捷性从"加分项"变为"必需项"的根本原因。
三、敏捷性的能力构成
把密码敏捷性拆开看，它由若干可独立建设、又相互支撑的能力组成。下图展示了这些能力层次及其与驱动因素、迁移目标之间的关系，可作为后续章节的结构索引。
图中四个能力层并非并列的模块清单，而是存在依赖顺序：抽象层决定替换的边际成本，密钥与证书管理决定切换过程是否安全，数据格式决定历史数据能否平滑过渡，迁移与验证机制决定最终结果是否可信。缺少任何一层，敏捷性都会在真实迁移中暴露短板。
四、一个具体的对照示例
为让概念落地，考虑一个典型场景：某业务系统需要把数据加密从 AES-128-CBC 升级到 SM4-CBC，以满足新的合规要求。两种实现方式的差异如下（示例参数，用于说明方法差异，非实测数据）：
| 对比维度 | 非敏捷实现 | 敏捷实现 |
|---|---|---|
| 算法调用位置 | 业务代码中约 40 处直接调用加密库 | 统一经 CryptoService 接口，业务侧无算法感知 |
| 密文格式 | 裸密文，无算法标识 | 头部含 1 字节算法 ID + 1 字节版本号 |
| 密钥管理 | 单一密钥，与算法强绑定 | 密钥带算法属性，支持新旧密钥并存 |
| 切换方式 | 停机割接，全量重加密 | 新数据用 SM4，旧数据读取时按算法 ID 解密 |
| 回滚能力 | 需回退代码与数据备份 | 策略开关切回 AES，无需改代码 |
| 预估改造量 | 约 40 处调用点 + 数据迁移脚本 | 策略配置 + 抽象层新增 SM4 实现 |
敏捷实现的关键不在"用了 SM4"，而在于密文自带算法标识这一设计。它使系统在读取任意一条历史数据时，都能自主判断该用哪种算法解密，从而支持新旧算法长期并存、逐步迁移。这正是"数据格式兼容"能力层的具体体现，也是后续章节会重点展开的设计要点。
五、本课程的学习路径与实战目标
本课程共 30 章，整体按"概念—架构—机制—迁移—验证—治理"的主线组织，可分为五个阶段：
- 概念与驱动（第 1–4 章）：建立敏捷性定义、合规与威胁背景、密码资产盘点方法。
- 架构设计（第 5–12 章）：密码抽象层、算法标识体系、密钥与证书管理、数据格式设计、服务化与硬件密码模块接入。
- 替换机制（第 13–20 章）：算法替换的触发条件、双算法并行、灰度发布、协议版本协商、国密与后量子算法接入路径。
- 迁移工程（第 21–26 章）：存量数据迁移、密钥轮换、上下游联调、回滚预案与演练。
- 验证与治理（第 27–30 章）：密评对接、迁移结果验证、持续监控与敏捷性度量。
实战目标设定为：完成课程后，读者应能独立完成一次"算法替换可行性评估"，产出一份包含密码资产清单、抽象层改造点、数据格式兼容方案、灰度迁移步骤与回滚预案的迁移设计文档，并能对迁移结果给出可验证的判断依据。这一目标将在后续章节中通过具体案例逐步拆解。
密码敏捷性不是一次性项目，而是一种需要持续维护的架构属性。它要求我们在设计之初就把"变化"纳入考量，把算法选择从硬编码中解放出来，把密钥与数据格式设计成可演进的结构。接下来的章节，将从密码资产盘点开始，一步步把这套能力落到工程实践中。