签名服务为什么要隔离
把签名密钥直接放在业务进程里，等于让每个能触达该进程的人都拥有签名能力。隔离的做法是抽出独立签名服务：业务只提交待签数据，密钥与签名逻辑集中在受控边界内，密钥由 KMS 或 HSM 持有、永不导出。这样一来，调用方身份、调用频率、可签内容都能在服务里统一鉴权与限制，并留下完整审计记录；密钥轮换也只需在服务内部完成，业务侧无感知。
基本信息
| 架构 | 业务 -> 签名服务（鉴权与策略）-> KMS/HSM 内完成签名 |
|---|---|
| 控制手段 | 调用方认证、限流、内容策略、完整审计 |
| 收益 | 密钥访问面收敛；轮换只需在服务内完成 |
| 密钥位置 | KMS/HSM 内，签名服务本身也不持有私钥 |
| 自身风险 | 签名服务成为高价值目标，需要重点加固 |
| 适用范围 | 代码签名、License 签发、Token 签名、单据签名 |
典型使用场景
- 代码与固件签名：发布流水线通过签名服务取证，构建机不接触私钥。
- License 签发：按订单调用签名服务，天然形成签发记录。
- Token 与断言签名：多业务共用一把密钥时，用服务统一限流与审计。
- 合规要求：需要证明密钥从未离开受控环境时按此架构落地。
- 密钥轮换：换密钥不必逐个业务发布，服务内部切换即可。
调用链示意
调用链示意
client -> sign-service (authN/authZ, rate limit, policy)
-> HSM / KMS (key never exported)
-> signature returned to client
# 业务侧只需持有调用凭据，不再持有签名私钥
# 服务侧按内容策略限制可签对象，例如只允许签本组织制品控制点与落地方式
| 控制点 | 做法 | 目的 |
|---|---|---|
| 调用方认证 | mTLS 或短期令牌 | 确认谁在发起签名 |
| 授权范围 | 按制品类型与命名空间限定 | 防止任意内容被签 |
| 限流 | 按调用方配额限制 | 抑制滥用与意外批量签发 |
| 内容策略 | 校验待签数据格式与范围 | 避免被当成通用签名机 |
| 审计 | 记录调用方、内容摘要与结果 | 事后可追溯签发行为 |
签名服务本身成为高价值目标，需要按核心系统标准做加固、监控与变更管理：能签名就等于能伪造，权限过宽的服务比散落的私钥更危险。