2. 多租户签名链路基础：签名链路定义、数字签名原理、在Istio中实现签名链路的必要性
2.1 签名链路定义与核心要素
在云原生多租户架构中，签名链路是指从请求发起端（客户端或上游服务）到目标服务（下游服务或数据平面）之间，对请求内容进行数字签名生成、传递、验证的完整路径。它确保请求在跨越多个服务边界时，其身份、完整性、不可否认性得到端到端保障。
| 核心要素 | 说明 | 在多租户场景中的意义 |
|---|---|---|
| 签名生成点 | 请求入口处（API网关、Sidecar、客户端SDK） | 绑定租户身份与请求载荷 |
| 签名传递载体 | HTTP Header（如 X-Signature、X-Tenant-ID） |
在服务网格中透明传递，不侵入业务代码 |
| 签名验证点 | 目标服务的Sidecar或业务容器入口 | 验证租户合法性，拒绝伪造或篡改请求 |
| 密钥管理 | 租户级公私钥对或对称密钥 | 隔离租户密钥，防止跨租户冒用 |
关键概念：签名链路不同于TLS/mTLS传输加密。TLS保护传输通道，签名链路保护请求内容的端到端可信性，即使中间服务被攻破，签名仍可验证原始请求是否被篡改。
2.2 数字签名原理与工作流程
数字签名是签名链路的技术基石。它基于非对称加密（RSA、ECDSA）或对称MAC（HMAC）算法，提供以下三个安全属性：
- 身份认证：验证签名者持有的私钥，确认请求来源。
- 数据完整性：签名与请求内容绑定，任何篡改都会导致验证失败。
- 不可否认性：私钥签名具有法律效力，签名者无法否认。
下图展示了标准数字签名流程在服务网格中的映射：
性能提示：在Istio中，签名验证通常使用异步非阻塞方式在Envoy Filter中执行。ECDSA P-256签名验证比RSA 2048快约3-5倍，且密钥更短，推荐用于高性能多租户场景。
2.3 在Istio中实现签名链路的必要性
为什么要在Istio服务网格中实现签名链路，而不是在业务代码中直接处理？以下从四个维度分析其必要性：
| 维度 | 业务代码实现 | Istio Sidecar实现 | 必要性说明 |
|---|---|---|---|
| 多语言支持 | 每种语言需单独实现签名库 | 统一在Envoy Filter中实现，语言无关 | 降低多语言团队的维护成本 |
| 密钥轮换 | 需修改业务代码或重启服务 | 通过Istio控制面动态下发，零停机 | 满足安全合规的密钥定期轮换要求 |
| 租户隔离 | 需自行管理租户密钥映射 | 利用Istio的WorkloadEntry和ServiceEntry实现租户级路由与签名策略 |
原生支持多租户身份与策略绑定 |
| 性能开销 | 侵入业务线程池，影响业务延迟 | 在Sidecar独立进程执行，不阻塞业务逻辑 | 分离计算资源，保障业务SLA |
安全风险：如果不在网格层面统一实施签名验证，每个微服务都需要自行实现签名逻辑。一旦某个服务因代码缺陷或配置错误跳过验证，整个签名链路就会断裂，攻击者可利用该服务作为跳板进行跨租户攻击。
2.4 签名链路在Istio中的架构位置
下图展示了签名链路在Istio数据平面中的具体位置与交互关系：
架构要点：
- 签名生成在Ingress Gateway或客户端Sidecar完成，避免业务代码侵入。
- 签名在HTTP Header中透明传递，中间服务无需感知签名逻辑。
- 签名验证在目标服务Sidecar通过Envoy Filter执行，验证失败直接拒绝，不进入业务容器。
- 密钥通过Istio控制面从外部KMS动态获取，支持热更新与租户级隔离。
2.5 签名链路与mTLS的协同关系
很多开发者会混淆签名链路与mTLS。两者是互补而非替代关系：
| 对比维度 | mTLS（传输层） | 签名链路（应用层） |
|---|---|---|
| 保护范围 | 点对点传输通道 | 端到端请求内容 |
| 身份粒度 | 服务身份（SPIFFE ID） | 租户身份（Tenant ID + 签名） |
| 防篡改 | 防止传输中篡改 | 防止中间服务篡改（即使TLS终止） |
| 不可否认性 | 不支持 | 支持（私钥签名） |
| 性能开销 | 握手开销，后续对称加密 | 每次请求签名/验证计算 |
最佳实践：在Istio多租户环境中，建议同时启用mTLS（保障传输安全）和签名链路（保障端到端可信）。mTLS解决“谁在说话”，签名链路解决“说话的内容是否被篡改以及谁授权了这次请求”。