2. 企业密码平台现状盘点
迁移改造项目最容易失控的地方，不是技术方案本身，而是“不知道自己有什么”。在动手迁移之前，必须先把现有密码平台的资产、服务、密钥证书、依赖关系和版本信息盘清楚。盘点的目标不是做一份漂亮的台账，而是回答三个问题：哪些密码能力在被使用、被谁使用、迁移时会牵动什么。本节围绕资产梳理方法、密码服务清单、密钥与证书台账、依赖关系图谱、架构与版本信息采集五个方面展开，并给出可直接套用的盘点表结构。
一、资产梳理：从“设备清单”升级为“密码能力清单”
传统资产梳理往往只记录服务器、IP、操作系统，这对密码平台迁移远远不够。密码平台的资产至少包含四类：密码设备/密码机（如服务器密码机、签名验签服务器、金融数据密码机）、密码软件服务（KMS、CA、密钥管理系统、证书管理系统）、密码算法与协议配置（SM2/SM3/SM4、RSA、AES、TLS 版本与套件）、调用方应用（业务系统、网关、中间件）。
建议采用“三层扫描法”落地：第一层做网络与端口扫描，识别开放了密码服务端口的设备，例如密码机常见的服务端口、KMS 的 HTTPS 接口、CA 的证书签发接口；第二层做配置与进程采集，登录设备或主机，采集密码服务进程、监听端口、配置文件中的算法与密钥路径；第三层做调用关系采集，通过应用配置、SDK 依赖、日志中的接口调用记录，反查哪些应用在调用哪些密码服务。三层结果交叉比对，才能得到可信的资产底账。
二、密码服务清单：把能力拆到可迁移的粒度
密码服务清单的核心是把“一台密码机”拆解为“它对外提供了哪些可被调用的密码能力”。常见服务项包括：对称加解密、非对称加解密、签名验签、摘要计算、密钥生成、密钥派生、随机数生成、证书签发、证书吊销、时间戳服务等。每一项服务都应记录：服务名称、算法、接口协议（如 REST、PKCS#11、JCE、GM/T 0018）、调用地址、认证方式、SLA 指标（QPS、时延）、当前使用量。
下面是一份可直接填写的密码服务清单示例（数据为教学示例，非实测值）：
| 服务编号 | 服务名称 | 算法/协议 | 接口方式 | 调用方数量 | 日均调用量（示例） |
|---|---|---|---|---|---|
| SVC-001 | 数据对称加密 | SM4-CBC | PKCS#11 | 6 | 约 120 万次 |
| SVC-002 | 签名验签 | SM2 | REST | 4 | 约 35 万次 |
| SVC-003 | 证书签发 | X.509 / SM2 | HTTPS | 3 | 约 800 张/日 |
| SVC-004 | 摘要计算 | SM3 | JCE | 9 | 约 200 万次 |
清单的价值在于：迁移时可以按服务逐项切换，而不是整机停机。调用方数量多、调用量大的服务应优先安排兼容性验证和灰度切换。
三、密钥与证书台账：迁移风险最集中的部分
密钥和证书是密码平台中最不能“丢”和“错”的资产。台账至少应包含：密钥/证书标识、类型（对称密钥、非对称密钥对、根证书、终端证书）、算法与长度、用途（加密、签名、认证）、生成方式（内部生成、外部导入）、存储位置（密码机内部、KMS、文件、HSM 分区）、有效期、关联应用、是否可导出、备份情况。
特别要标注三类高风险项：不可导出密钥（迁移时通常只能重新生成并重新分发）、即将到期证书（迁移窗口与到期时间冲突会导致业务中断）、无备份密钥（一旦设备故障无法恢复）。建议在台账中增加“迁移策略”列，取值如“直接迁移 / 重新生成 / 重新签发 / 暂不迁移”，让盘点结果直接对接迁移方案。
四、依赖关系图谱：看清“牵一发动全身”的路径
依赖关系图谱要表达的是：应用 → 密码服务 → 密码设备/软件 → 密钥/证书 → 网络区域 的调用链。只有把这条链画出来，才能判断迁移影响面。例如某支付应用调用签名服务，签名服务依赖密码机中的 SM2 密钥，密钥又绑定在特定 HSM 分区上，那么迁移密码机就必须同步迁移或重建该密钥，并通知应用方调整接口地址。
图谱画完后，应重点识别“共享依赖”和“单点依赖”。共享依赖指多个服务共用同一台密码机或同一个密钥，迁移时必须整体评估；单点依赖指某个应用只依赖一个密码服务且无备用路径，迁移前必须准备回退方案。
五、架构与版本信息采集：为兼容性判断提供依据
版本信息直接决定迁移方案是否可行。需要采集的版本包括：密码设备固件版本、密码服务软件版本、SDK 版本、算法库版本、操作系统与中间件版本、接口协议版本（如 PKCS#11 版本、GM/T 0018 版本）。采集方式可以通过设备管理界面、命令行、配置文件、厂商提供的巡检工具完成。
采集后应建立“版本—兼容性”对照关系。例如某应用使用的 SDK 仅支持旧版 PKCS#11 接口，而新密码平台只提供新版接口，则迁移时必须同步升级 SDK 或增加适配层。版本信息还应记录厂商支持状态，已停止维护的版本应优先纳入替换计划。
六、盘点成果的交付形态
一次完整的现状盘点，最终应形成四份可交付成果：密码资产总表（设备、软件、算法配置）、密码服务清单（服务项、接口、调用量）、密钥与证书台账（含迁移策略列）、依赖关系图谱（含共享依赖与单点标注）。四份成果应使用统一编码互相引用，例如服务编号 SVC-001 对应资产编码 PROD-HQ-HSM-001，密钥编号 KEY-001 关联到具体应用。这样在后续迁移排期时，可以直接按服务或按应用筛选影响范围，把盘点结果转化为可执行的迁移批次。
盘点的深度不必一次到位，但必须保证“调用方—服务—密钥—设备”这条链完整可追溯。只要这条链清晰，迁移改造就有了可靠的起点。