3. 签名链路架构：签名链路整体拓扑、签名服务、密钥管理、签名验证节点

在平台工程 IDP 中，制品签名不是单一操作，而是一条从密钥生成、签名计算、元数据附加到验证决策的完整链路。本章从整体拓扑出发，逐层拆解签名服务、密钥管理体系和验证节点的职责与交互模式。

3.1 签名链路整体拓扑

签名链路采用“分层解耦 + 集中管控”的架构模式，分为策略层、服务层、密钥层和验证层。下图展示了四个层次及其核心组件之间的调用关系。

3.2 签名服务

签名服务是签名链路的编排核心，负责接收 CI/CD 管线的签名请求，协调密钥服务和元数据服务完成签名操作。其内部流程分为五个步骤：

1. 请求校验：验证调用方身份（mTLS / JWT）、制品哈希值、签名策略是否匹配。
2. 密钥获取：向 KMS 请求当前有效的签名密钥（按策略选择密钥版本）。
3. 签名计算：将制品摘要 + 元数据（时间戳、签名者身份、策略 ID）送入 KMS 进行签名运算。
4. 元数据封装：将签名值、公钥指纹、证书链、签名算法等信息写入制品元数据文件（如 signature.json）。
5. 结果返回：返回签名结果和元数据路径给调用方，同时写入审计日志。

3.3 密钥管理

密钥管理是签名链路的安全基石。IDP 中通常采用分层密钥体系，将根密钥、签名密钥和验证密钥分离管理。

3.3.1 密钥分层模型

• 根密钥（Root Key）：存储在 HSM 或云 KMS 中，用于签发下级密钥证书，极少使用，离线存储。
• 签名密钥（Signing Key）：用于日常制品签名，定期轮换（如每 90 天），支持密钥版本管理。
• 验证密钥（Verification Key）：公钥部分，通过证书链或公钥分发机制下发到验证节点。

3.3.2 密钥生命周期

3.4 签名验证节点

验证节点是签名链路的最终决策者，通常部署在制品部署前的准入阶段（如 Kubernetes 准入控制器、Artifactory 仓库网关）。验证节点执行以下核心逻辑：

1. 制品摘要提取：计算当前制品的哈希值（SHA-256 / SHA-384）。
2. 签名元数据解析：读取制品附带的 signature.json 或 .sig 文件。
3. 公钥获取：从本地信任库或在线 OCSP 服务获取对应密钥的公钥/证书。
4. 签名验证：使用公钥验证签名值是否与制品摘要匹配。
5. 策略评估：检查签名算法、密钥有效期、证书链是否完整、是否在 CRL 中。
6. 决策输出：通过则放行，失败则拒绝部署并触发回滚流程。

3.4.1 验证节点部署模式

3.5 签名链路安全加固清单

• 最小权限：签名服务仅拥有调用 KMS sign 操作的权限，无权导出密钥或执行 decrypt。
• 传输加密：所有链路组件之间强制使用 mTLS，证书由内部 CA 签发，每 180 天轮换。
• 审计日志：每次签名请求、密钥轮换、验证失败事件均记录到不可篡改的审计存储（如 Immutable DB）。
• 密钥版本化：所有签名操作必须携带密钥版本 ID，验证节点根据版本 ID 查找对应公钥，避免使用“默认密钥”。
• 回滚兼容：验证节点必须保留至少两个历史密钥版本，确保回滚到旧版本制品时仍能通过验证。