3. 签名链路定义与场景

在多租户微服务架构中，数字签名不再是一次性、端到端的操作，而是形成了一条贯穿多个服务节点的签名链路。本章将明确定义签名链路的核心概念，解析数字签名在微服务间的传递流程与验证链，并给出多租户场景下的典型拓扑结构。

3.1 签名链路的基本定义

签名链路是指一个业务请求从入口网关开始，经过多个微服务节点，在每个节点上依次进行签名验证、上下文传递、以及可能的重签名或附加签名，最终到达目标服务或返回客户端的完整路径。

签名链路区别于普通请求链路的关键特征：

3.2 数字签名在微服务间的传递流程

一个完整的签名传递流程包含以下步骤，以 Istio Sidecar 代理模式为背景：

1. 客户端签名：客户端（或入口网关）使用租户私钥对请求体 + 租户 ID + 时间戳 + 随机数进行签名，生成签名值 sig_client，并附加在请求头部。
2. Sidecar 拦截与验证：Istio Sidecar（Envoy）通过自定义 Filter 拦截请求，提取签名头部，调用验证服务或本地公钥缓存验证 sig_client。
3. 上下文注入：验证通过后，Sidecar 将验证结果（租户 ID、签名时间、签名算法）注入到请求的 x-signature-context 头部，供下游服务使用。
4. 服务间转发：服务 A 处理完业务逻辑后，将原始签名载荷 + 自身签名（sig_service_a）附加到请求中，转发给服务 B。
5. 递归验证：服务 B 的 Sidecar 验证 sig_client 和 sig_service_a，形成签名链的累积验证。
6. 最终验证：目标服务收到请求时，可获取完整的签名链列表，进行端到端的完整性校验。

3.3 签名验证链的结构

签名验证链是一个有序的签名列表，每个元素包含签名者身份、签名值、签名时间、被签名数据摘要。验证链的典型结构如下：

签名验证链 (Signature Chain)
├── 节点 1: 客户端 (租户 A)
│   ├── 签名算法: ECDSA-P256
│   ├── 签名时间: 2025-01-15T10:30:00Z
│   ├── 签名值: sig_client_base64
│   └── 被签名数据: body_hash + tenant_id + timestamp + nonce
├── 节点 2: 服务 A (gateway-svc)
│   ├── 签名算法: Ed25519
│   ├── 签名时间: 2025-01-15T10:30:01Z
│   ├── 签名值: sig_service_a_base64
│   └── 被签名数据: sig_client + body_hash + tenant_id
└── 节点 3: 服务 B (order-svc)
    ├── 签名算法: Ed25519
    ├── 签名时间: 2025-01-15T10:30:02Z
    ├── 签名值: sig_service_b_base64
    └── 被签名数据: sig_service_a + body_hash + tenant_id

验证链的验证规则：

• 顺序验证：从链头开始，依次验证每个签名，前一个签名验证通过后才能验证下一个。
• 数据完整性：每个签名都包含对前一个签名值的摘要，形成哈希链，任何中间篡改都会导致后续验证失败。
• 租户一致性：所有签名中的 tenant_id 必须一致，否则视为跨租户攻击。
• 时间窗口：相邻签名的时间差不能超过配置阈值（默认 5 秒），防止签名被延迟重放。

3.4 多租户签名链路的典型拓扑

在多租户环境中，签名链路需要同时处理租户隔离和服务共享的矛盾。以下给出两种典型拓扑：

3.4.1 集中式验证拓扑

所有签名验证集中在一个专用的签名验证服务（SVS）中完成，业务服务只负责透传签名载荷。这种拓扑适用于租户数量较少、对延迟不敏感的场景。

3.4.2 分布式验证拓扑

每个服务的 Sidecar 代理本地完成签名验证，验证结果通过请求头部透传。这种拓扑适用于租户数量多、对延迟敏感的场景，也是 Istio 多租户签名链路的主流方案。

3.5 拓扑对比与选型建议

3.6 签名链路中的关键头部设计

在 Istio 环境下，签名链路的上下文通过 HTTP 头部传递。以下是一组推荐的头部设计：