核心思路是网关出站时注入唯一、不可伪造且有时效性的签名头（如X-Gateway-Signature），后端严格校验其存在性、时间窗口、gateway-id白名单及签名有效性，并配合密钥轮换、网络策略与mTLS等多重加固。
要确保上游流量完全来自受信任的边缘网关，核心思路是：在网关出站时注入唯一、不可伪造且具备时效性的签名头，在后端服务入口处严格校验该头的存在性、格式、签名有效性及时间窗口。这不是单纯加个固定字符串，而是构建一套轻量但可靠的“网关身份信标”机制。
签名头设计与注入（网关侧）
选择一个语义清晰、非标准的 Header 名，例如 X-Gateway-Signature 或 X-Trusted-Edge-Sig。值不应是静态密钥，而应是动态生成的签名：
- 拼接关键字段：如
timestamp（毫秒级 Unix 时间戳）、gateway-id（网关唯一标识，如edge-prod-us-east）、request-uri（或其哈希）、method - 使用共享密钥 HMAC-SHA256 签名：例如
hmac_sha256(shared_secret, timestamp|gateway-id|uri|method) - 最终 Header 值格式建议为：
ts=1718624040123;id=edge-prod-us-east;sig=abc123...，便于后端解析与校验 - Nginx 示例：
proxy_set_header X-Gateway-Signature "ts=$msec;id=prod-edge-us;sig=$signature";
其中$signature可通过map+lua模块计算，或由前置网关（如 Envoy、Cloudflare Workers）统一注入
后端强制校验逻辑（服务侧）
后端必须在所有入口路由（如 Spring Boot 的 Filter、Express 中间件、Nginx 的 auth_request）中执行以下检查，任一失败即拒绝对应请求：
- Header 必须存在且非空；缺失直接 403
- 解析
ts字段，验证是否在允许时间窗口内（如 ±30 秒），防止重放攻击 - 提取
id，确认属于预设白名单（如["prod-edge-us", "prod-edge-eu"]） - 重新计算签名：用相同算法、相同字段顺序、相同共享密钥，比对
sig是否一致 - 禁止透传客户端原始
X-Gateway-Signature—— 后端只认网关注入的版本，不接受任何外部构造值
密钥与生命周期管理
签名安全依赖密钥管控，不能硬编码或泄露：
- 共享密钥（shared_secret）应通过密钥管理服务（如 AWS KMS、Azure Key Vault、HashiCorp Vault）分发，并定期轮换
- 网关与后端服务需同步获取最新密钥，建议配合配置中心实现热更新
- 每次密钥轮换后，旧密钥应保留一个宽限期（如 2 小时），用于校验尚未过期的旧签名请求
- 日志中严禁记录完整签名值或密钥；可记录 gateway-id、timestamp 和校验结果（success/fail）用于审计
防御绕过与辅助加固
仅靠 Header 签名还不够，需叠加网络层约束提升可信度：
- 后端只监听来自网关所在子网的流量（如 Kubernetes 中设置 NetworkPolicy，或云厂商安全组限制源 IP 段）
- 禁用后端服务直接暴露公网入口，所有流量必须经网关转发
- 网关自身开启客户端证书双向认证（mTLS），确保只有合法网关节点能建立连接
- 结合
X-Forwarded-For校验：若网关注入了真实客户端 IP，后端可拒绝X-Forwarded-For中含多个地址或格式异常的请求，避免伪造
