4. 组织密码资产清点方法与实战
后量子安全迁移的第一步不是选算法，而是弄清楚“我们到底在用哪些密码”。密码资产清点（Cryptographic Asset Inventory）的目标，是系统识别组织内所有依赖密码算法的对象——算法、协议、证书、密钥、库与硬件模块——并记录其位置、用途、生命周期与迁移难度。没有一份可信的清单，后续的风险评估、优先级排序和迁移排期都无从谈起。
本节把清点拆成“识别范围—采集手段—分类建模—模板落地”四个环节，并给出一份可直接填写的资产清单模板。
一、先划定清点边界：五类资产对象
密码资产不是单一概念，实践中至少包含五类相互关联的对象，清点时需分别登记并建立引用关系：
- 算法：RSA-2048、ECDSA P-256、SHA-1、AES-128-GCM、SM2/SM3/SM4 等，记录算法族、参数长度与用途（签名/加密/摘要/KDF）。
- 协议：TLS 1.2/1.3、SSH、IPsec/IKEv2、S/MIME、Kerberos、QUIC 等，记录版本、密码套件与协商参数。
- 证书：X.509 终端实体证书、中间 CA、根 CA、代码签名证书、设备证书，记录签发者、公钥算法、有效期、吊销状态与部署位置。
- 密钥：对称密钥、非对称私钥、主密钥、数据加密密钥（DEK）、密钥加密密钥（KEK），记录长度、存储介质（HSM/软件密钥库/配置文件）、轮换周期与责任人。
- 依赖组件：OpenSSL、BoringSSL、Java JCE、国密 SDK、HSM 固件、智能卡、IoT 安全芯片等，记录版本与支持的算法集合。
这五类对象之间存在引用链：协议调用算法，证书绑定公钥，密钥由组件托管。清点表必须能表达这种引用关系，否则后续做“某算法退役影响哪些业务”的分析时会断链。
二、采集手段：从被动扫描到主动问询
实际清点通常组合使用以下手段，单一手段都会留下盲区：
- 网络与端点扫描：用 nmap 的 ssl-enum-ciphers 脚本、testssl.sh 或 sslyze 探测对外服务的 TLS 版本与密码套件。例如对一台 Web 服务器执行
testssl.sh --severity HIGH 10.0.1.20:443，输出会列出支持的套件，如TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256，据此可反推使用了 ECDHE、RSA 签名与 AES-128-GCM。 - 代码与配置静态检索：在代码仓库中检索
MD5、SHA1、RSA、DES、ECB等关键字，并检查配置文件中的ssl_protocols、cipher_suites、keyStore路径。注意区分“调用”与“注释/测试代码”，避免误报。 - 证书透明日志与内部 CA 导出：从公共 CT 日志和内部 CA 系统导出组织域名下的全部证书，按公钥算法与有效期归类。
- 资产管理系统与 CMDB 关联：把扫描结果挂到主机、应用、业务系统上，形成“业务—应用—主机—密码资产”的归属链。
- 人工访谈与问卷：对无法自动发现的场景（嵌入式设备、第三方 SaaS、纸质流程中的电子签章）进行问询，重点确认“是否使用自研密码”“是否使用国密”“密钥由谁保管”。
三、分类维度：让清单可排序、可决策
清点不是罗列，而是为迁移决策服务。建议每条资产至少打上以下标签：
- 量子脆弱性：直接脆弱（RSA/ECDSA/ECDH/DH）、部分脆弱（SHA-1 等摘要）、相对安全（AES-256、SHA-384、对称密钥体系）。
- 业务关键度：核心交易、内部办公、测试环境。
- 暴露面：互联网可达、内网、离线。
- 迁移难度：可配置替换、需改代码、依赖硬件更换、依赖第三方。
- 生命周期：证书到期时间、密钥轮换周期，决定“自然替换窗口”。
下图展示了一条典型的密码资产引用链与分类标注方式，帮助理解“协议—证书—密钥—组件”如何串联并映射到迁移优先级：
四、资产清单模板设计
模板字段应围绕“可定位、可判断、可排期”设计。下面给出一份可直接落地的清单结构，字段按实际需要取舍：
| 资产编号 | 资产类型 | 算法/协议/证书标识 | 参数 | 部署位置 | 所属业务 | 量子脆弱性 | 迁移难度 | 到期/轮换 | 责任人 |
|---|---|---|---|---|---|---|---|---|---|
| CA-001 | 证书 | X.509 终端证书 | RSA-2048 / SHA-256 | 10.0.1.20:443 | 网银交易 | 直接脆弱 | 配置替换 | 2026-03-15 | 张工 |
| PR-002 | 协议 | TLS 1.2 | ECDHE-RSA-AES128-GCM | 网关集群 | 网银交易 | 直接脆弱 | 配置替换 | 随证书 | 张工 |
| KY-003 | 密钥 | RSA 私钥 | 2048 位 | HSM-A 分区 3 | 网银交易 | 直接脆弱 | 换硬件/固件 | 每年轮换 | 李工 |
| AL-004 | 算法 | SHA-1 | 摘要 | 旧版签章服务 | 电子合同 | 部分脆弱 | 需改代码 | — | 王工 |
| CP-005 | 组件 | OpenSSL | 1.1.1w | 应用服务器 | 多个 | 依赖算法 | 升级替换 | — | 运维组 |
填写时有几条实操要点：资产编号建议采用“类型前缀+序号”，便于跨表引用；部署位置要精确到主机与端口或密钥库路径，避免只写“生产环境”；“到期/轮换”字段直接决定迁移窗口，必须与证书管理系统、密钥管理系统的真实数据对齐，不能凭记忆填写。
五、实战中的常见问题与判断依据
问题一：扫描显示“支持 TLS 1.3”，是否说明已安全？ 不一定。TLS 1.3 的密钥交换已使用 ECDHE，但服务器证书仍可能是 RSA 签名，量子脆弱性依然存在。判断时应分别看“密钥交换算法”和“签名算法”，两者都要登记。
问题二：同一算法在多处出现，是否合并为一条？ 不建议。清点的粒度是“部署实例”，因为迁移时不同实例的窗口、责任人和难度不同。可以在算法维度做汇总视图，但底层记录应保持实例级。
问题三：如何判断清点是否“足够完整”？ 可用交叉验证：扫描发现的端口数应与 CMDB 中登记的服务数大致吻合；代码检索命中的高危算法调用应能在清单中找到对应条目；内部 CA 签发的证书应全部有归属。三者对不上时，缺口就是下一轮清点的重点。
完成一轮清点后，组织应得到三样东西：一份实例级资产清单、一张按迁移优先级排序的汇总视图、一份“已知盲区”说明。盲区说明同样重要——它明确了本轮清点未覆盖的范围（如某些第三方 SaaS、离线设备），为后续补充清点提供依据，也避免管理层误以为清单已覆盖全部风险。