2. 密码算法资产盘点与清单构建

算法退役治理的第一步不是“换算法”，而是“找算法”。如果组织不知道自己在哪里用了 SHA-1、RSA-1024、DES、MD5 或自研弱随机数，任何替换计划都只是空中楼阁。密码算法资产盘点要回答三个问题：用了什么算法、用在哪里、由谁负责。这三者缺一不可，因为同一个算法在不同位置的风险等级和替换难度差异极大。

一、识别所有密码算法使用点

密码算法的使用点远比想象中分散。一个中型组织通常会在以下五类位置同时存在算法调用：

• 网络协议层：TLS/SSL 握手套件、SSH 密钥交换、IPSec/IKE 提议、SNMPv3 认证协议、Kerberos 加密类型。例如 TLS 1.2 的 TLS_RSA_WITH_AES_128_CBC_SHA 套件中同时包含 RSA 密钥传输、AES 对称加密和 SHA-1 完整性校验，退役时必须拆开评估。
• 软件库与框架：OpenSSL、BouncyCastle、Java JCE、Python cryptography、Go crypto 标准库，以及业务代码中直接调用的 MD5()、SHA1()、DES() 等函数。
• 硬件与固件：HSM 中的密钥类型与算法槽位、加密机固件版本、TPM 支持的算法族、智能卡 COS 指令集、网络设备 VPN 模块。
• 配置文件与策略：sshd_config 的 Ciphers/MACs/KexAlgorithms、nginx.conf 的 ssl_ciphers、Java 的 java.security、数据库连接串中的加密参数、Kubernetes Secret 加密配置。
• 数据与凭证：已签发的证书签名算法、JWT 的 alg 头、密码存储哈希、备份文件加密方式、历史归档数据的加密算法。

识别时要注意“隐式使用”：很多算法不是显式配置的，而是库的默认值。例如某些旧版 JDK 默认启用 SHA-1 签名，某些框架默认使用 ECB 模式。盘点必须覆盖默认值，否则会漏掉大量隐性资产。

二、资产分类与分级

盘点结果需要结构化，才能支撑后续治理优先级。建议按两个维度分类：算法族（哈希、对称、非对称、随机数、协议套件）和承载形态（协议、库、硬件、固件、配置、数据）。分级则依据三个因素：算法强度、数据敏感度、暴露面。例如：

三、自动化扫描与人工审计

自动化扫描负责“广度”，人工审计负责“深度”。两者必须结合。

自动化扫描可从四个层面入手：

1. 代码扫描：用 Semgrep、CodeQL 或自定义正则匹配 MD5、SHA1、DES、RC4、ECB 等关键字，同时识别 MessageDigest.getInstance("MD5") 这类反射调用。
2. 依赖扫描：用 syft、trivy 生成 SBOM，检查 OpenSSL、BouncyCastle 等库版本及其已知弱算法支持。
3. 配置扫描：用 nmap --script ssl-enum-ciphers、testssl.sh、ssh-audit 探测网络服务的实际算法套件。
4. 证书与数据扫描：用 openssl x509 -text 批量提取证书签名算法，用 jq 解析 JWT 头，用文件指纹识别加密格式。

人工审计重点覆盖自动化难以触达的区域：HSM 内部密钥属性、固件中的硬编码密钥、业务逻辑中的自研加密、密钥生命周期管理流程、第三方接口的算法约定。审计时要特别关注“算法协商降级”场景——服务端支持强算法，但客户端可能协商到弱算法。

四、资产清单模板与维护机制

清单不是一次性表格，而是持续更新的资产库。建议字段包括：资产ID、算法名称、算法族、密钥长度/模式、承载形态、所在系统、网络位置、数据敏感度、风险等级、责任人、发现方式、最后确认时间、替换计划。维护机制上，将扫描纳入 CI/CD 流水线，每次构建自动更新清单；每季度做一次全量复核；当新漏洞披露时，按算法名称快速检索受影响资产。

实际落地时，建议先用自动化扫描在两周内产出初版清单，再安排人工审计补齐硬件、固件和业务逻辑中的盲区。清单初版不必追求完美，但必须保证每个条目都有责任人和风险等级，否则后续退役治理无法排期。盘点阶段最常见的失败是“只扫代码不扫配置”或“只扫在线系统不扫归档数据”，这两类遗漏往往在替换后期才暴露，代价极高。