4. 签名链路基础：数字签名原理、签名在微服务间通信的作用、常见签名算法
在构建多租户签名链路之前，必须透彻理解数字签名的底层机制。本章从密码学原理出发，逐步拆解签名在微服务通信中的价值，并对比主流签名算法的性能与安全特征，为后续 Istio 环境下的签名代理配置与调优奠定理论基础。
4.1 数字签名原理
数字签名是非对称密码技术的核心应用，它同时提供身份认证、数据完整性和不可否认性三个安全属性。其工作流程分为签名生成与签名验证两个阶段。
核心流程：发送方使用私钥对消息摘要加密生成签名；接收方使用发送方公钥解密签名并与本地摘要比对。
- 消息摘要计算：发送方对原始消息（Payload）使用哈希函数（如 SHA-256）生成固定长度的摘要（Digest）。
- 签名生成：发送方使用自己的私钥对摘要进行加密运算，得到数字签名（Signature）。
- 签名附加：将签名与原始消息一同发送给接收方（通常放在 HTTP Header 或消息尾部）。
- 摘要重算：接收方从收到的消息中提取原始部分，使用相同的哈希函数重新计算摘要。
- 签名验证：接收方使用发送方的公钥解密签名，得到原始摘要；将解密结果与本地重算的摘要进行比对。一致则验证通过。
关键理解：私钥签名、公钥验签是数字签名的核心对称性。私钥必须由签名方严格保管，公钥可以公开分发。在微服务架构中，每个服务实例持有自己的私钥，而公钥通过 Istio 的证书分发机制或配置中心下发到其他服务。
4.2 签名在微服务间通信的作用
在微服务架构中，服务间通信（Service-to-Service）面临多种安全威胁：请求伪造、中间人攻击、重放攻击、参数篡改等。数字签名在以下四个关键场景中发挥不可替代的作用：
| 安全威胁 | 签名防护机制 | 在 Istio 环境中的典型应用 |
|---|---|---|
| 请求伪造（CSRF/SSRF） | 接收方验证签名，确保请求来自持有合法私钥的服务 | Sidecar 代理自动验证入站请求的 JWT 签名 |
| 中间人篡改（MITM） | 签名绑定消息内容，任何篡改都会导致验签失败 | Envoy 过滤器在 L7 层校验请求体与 Header 签名 |
| 重放攻击（Replay） | 签名中加入时间戳或 nonce，接收方校验时效性 | Istio 策略中配置时间窗口与签名 nonce 验证 |
| 身份冒充（Spoofing） | 签名绑定服务标识（Service Account / SPIFFE ID） | Istio mTLS 握手后，额外进行请求级签名校验 |
注意：mTLS 提供传输层加密与身份认证，但无法防止应用层的数据篡改。在多租户场景中，即使 mTLS 已启用，仍建议在请求 Header 中附加数字签名，以实现端到端的请求完整性保护，防止租户 A 的请求被恶意代理篡改为租户 B 的数据。
4.3 常见签名算法对比
选择签名算法需要权衡安全性、性能和密钥长度。在 Istio 签名链路中，最常用的三类算法是 RSA、ECDSA 和 HMAC。下表从多个维度进行对比：
| 算法 | 类型 | 密钥长度（安全等价） | 签名速度 | 验签速度 | 签名大小 | 推荐场景 |
|---|---|---|---|---|---|---|
| RSA-2048 | 非对称 | 2048 bit | 慢（~2000 次/秒） | 快（~50000 次/秒） | 256 字节 | 传统系统、公钥分发简单、兼容性要求高 |
| RSA-4096 | 非对称 | 4096 bit | 极慢（~500 次/秒） | 中等（~15000 次/秒） | 512 字节 | 高安全等级、合规要求严格 |
| ECDSA P-256 | 非对称 | 256 bit（等价 RSA-3072） | 快（~15000 次/秒） | 快（~12000 次/秒） | 64 字节 | 推荐：微服务高频签名、性能敏感场景 |
| ECDSA P-384 | 非对称 | 384 bit（等价 RSA-7680） | 中等（~8000 次/秒） | 中等（~7000 次/秒） | 96 字节 | 金融、政务等超长有效期密钥 |
| HMAC-SHA256 | 对称 | 256 bit（共享密钥） | 极快（~100000 次/秒） | 极快（~100000 次/秒） | 32 字节 | 内部可信网络、密钥分发可控、低延迟要求 |
性能调优建议：在 Istio 签名代理中，ECDSA P-256 是综合最优选择。相比 RSA-2048，其签名速度快 7-8 倍，签名体积小 75%，且提供更高的安全强度。HMAC 虽然性能极致，但要求通信双方共享密钥，在多租户动态扩缩容场景下密钥管理复杂度较高。
4.4 签名算法选型决策树
在实际项目中，可根据以下条件快速确定签名算法：
- 是否可接受共享密钥？ 是 → HMAC-SHA256（性能优先，密钥管理需完善）。否 → 进入下一步。
- 是否需要兼容老旧客户端？ 是 → RSA-2048（广泛支持，但性能一般）。否 → 进入下一步。
- 签名/验签性能是否关键？ 是 → ECDSA P-256（最佳平衡）。否 → RSA-3072 或 ECDSA P-384。
- 合规要求是否强制 RSA？ 是 → RSA-4096（仅当明确要求）。
Istio 集成提示：Envoy 原生支持 RSA 和 ECDSA 签名验证（通过 JWT 过滤器）。HMAC 需要自定义 Lua 过滤器或 WASM 扩展。在后续章节中，我们将基于 ECDSA P-256 实现签名代理，并展示如何通过 Istio 的 EnvoyFilter 注入签名逻辑。