📚 课程目录第2章密码资产发现与清点

2. 密码资产发现与清点

密码资产清点是密码敏捷性工程的第一步，也是最容易被低估的一步。很多团队在讨论"换算法"时，才发现自己根本说不清系统里到底用了哪些算法、哪些证书、哪些密钥、哪些依赖库。密码资产不是一份静态清单，而是一张持续变化的"密码地图"：它分布在应用代码、配置文件、TLS 终端、硬件设备、第三方组件和云服务中，任何一处遗漏都可能让后续的迁移计划失效。

从工程视角看，密码资产可以归为五类：算法（如 RSA-2048、SHA-1、AES-128-CBC）、协议（如 TLS 1.0/1.1/1.2/1.3、SSH、IPsec、S/MIME）、证书（X.509 终端实体证书、中间 CA、根 CA）、密钥（对称密钥、非对称私钥、密钥派生材料）以及依赖库（OpenSSL、BouncyCastle、Java JCE、Go crypto、Node.js crypto 等）。这五类资产相互关联：一个证书背后有密钥，一个密钥由某个库生成，一个库又决定了可用的算法和协议版本。清点的目标不是罗列，而是建立"资产—位置—属性—依赖"的可追溯关系。

清点的核心问题只有四个：在哪里（位置）、是什么（算法/协议/证书/密钥/库）、什么版本或参数（强度、有效期、密钥长度、曲线）、谁依赖它（调用方、服务、业务）。回答不了这四个问题，就无法评估风险，也无法规划迁移。

发现方法：从被动扫描到主动探测

密码资产的发现通常采用"被动采集 + 主动探测 + 代码分析"三条路径并行。被动采集从现有系统中提取信息，例如从配置管理数据库（CMDB）、证书透明度日志（CT Log）、Kubernetes Secret、Vault 审计日志、负载均衡器配置中导出记录。主动探测则直接与目标交互，例如用 nmap --script ssl-enum-ciphers 扫描 TLS 终端，用 openssl s_client -connect host:443 -showcerts 获取证书链，用 ssh-keyscan 采集 SSH 主机密钥。代码分析则针对应用层，通过静态扫描识别硬编码密钥、弱算法调用和过时库版本。

以一次典型的 TLS 终端清点为例，操作过程可以这样展开：先确定扫描范围（如某业务域名的全部对外 IP 和端口），再执行协议与套件枚举。下面是一段可复现的示例命令，用于获取某终端支持的 TLS 版本和密码套件：

nmap -Pn -p 443 --script ssl-enum-ciphers example.internal.com
# 输出示例（节选）：
# TLSv1.2:
#   ciphers:
#     TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
#     TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - C
# TLSv1.0:
#   ciphers:
#     TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C

这段输出中，TLSv1.0 和 3DES 就是需要标记的弱协议与弱算法，rsa 2048 表示密钥长度，评级 C 提示该套件强度不足。清点时要把这些结果与资产归属（域名、业务、负责人）关联，而不是只保留一份扫描报告。

证书与密钥的清点要点

证书清点要关注四个字段：颁发者、有效期、公钥算法与长度、签名算法。例如一张 SHA1withRSA 签名的证书，即使公钥是 RSA-2048，也因签名算法过弱而需要优先替换。密钥清点则要区分"可导出"与"不可导出"：HSM 或 KMS 中的密钥通常不可导出，清点时记录其别名、用途、算法和轮换策略即可；而配置文件或代码中的硬编码密钥必须立即标记为高风险。

依赖库清点常被忽略，但它决定了"能不能换算法"。例如某 Java 应用依赖 BouncyCastle 1.60，该版本对 Ed25519 的支持有限；若计划迁移到 Ed25519，就必须先升级库版本。清点时应记录库名称、版本、调用位置和已知的密码相关 CVE。可以用依赖分析工具生成清单，再人工确认哪些库真正参与了密码运算。

从清点到台账：字段与判断依据

清点的最终交付物是一份可维护的密码资产台账。台账不需要复杂，但字段必须能支撑后续决策。一个可参考的字段结构如下：资产 ID、资产类型（算法/协议/证书/密钥/库）、所在位置（主机、服务、代码仓库、配置文件路径）、当前参数（算法名、密钥长度、曲线、协议版本、有效期）、依赖方（调用它的服务或业务）、风险等级（高/中/低）、建议动作（替换/升级/观察）、负责人。风险等级的判断依据可以简化为三条：是否已被公认不安全（如 SHA-1、TLS 1.0、3DES）、是否临近过期（证书剩余有效期小于 90 天）、是否无法轮换（硬编码或不可导出且无备份）。

清点不是一次性项目。建议把扫描任务纳入 CI/CD 或定时巡检：每次发布前扫描新增依赖，每周扫描对外 TLS 终端，每月核对证书有效期。台账应版本化存储，变更时记录时间和原因，这样才能在迁移时回答"这个资产是什么时候出现的、谁改过"。

常见误区与处理建议

第一个误区是只扫对外服务，忽略内网和东西向流量。很多企业内网仍在使用自签名证书和 TLS 1.0，这些资产同样需要清点。第二个误区是只记录算法名，不记录参数。同样是 RSA，2048 位和 1024 位的风险完全不同；同样是 AES，GCM 和 CBC 的安全性也不同。第三个误区是忽略依赖库的传递依赖。一个应用可能没有直接调用某密码库，但通过框架间接依赖了它，清点时要沿依赖树展开。

处理建议是：先建立最小可用台账（覆盖对外 TLS 终端和高风险硬编码密钥），再逐步扩展到内网、证书链和依赖库。每完成一轮清点，就用"能否回答四个核心问题"来检验台账是否合格。当台账能够支撑"哪些资产需要优先迁移、迁移会影响哪些业务、迁移后如何验证"这三个问题时，密码资产清点才算真正完成，也才能为后续的敏捷性改造提供可靠输入。