4. Spring Cloud 概述：微服务架构与组件安全痛点
这一章我们来聊聊 Spring Cloud 全家桶。说实话，很多团队一上来就搭网关、配注册中心，觉得功能跑通就万事大吉了。我当初也是这样想的，直到有一次在客户现场做安全审计，发现他们 Gateway 路由里居然明文传递了国密算法的私钥 seed……嗯，从那以后我再也不敢轻视组件的安全配置了。
你想想看，微服务架构把一个大单体拆成几十上百个小服务，服务之间的调用链路变长了，攻击面自然也变多了。咱们这节课就梳理一下 Spring Cloud 核心组件，看看每个组件到底藏着哪些安全痛点。
4.1 微服务架构的核心变化
传统单体应用，所有逻辑都在一个进程里，安全控制集中在入口就行。微服务呢？服务间用 HTTP/RPC 通信，每个服务都可能暴露端口，身份认证、数据加密、权限校验都得分布式做了。
核心矛盾：服务拆分带来灵活性的同时，也把安全问题从“单点防御”变成了“链式防御”。任何一个环节出现漏洞，整条链路都可能被攻破。
下图是咱们章节的核心知识结构，你可以快速了解 Spring Cloud 各组件在架构中的位置以及它们对应的安全风险点。
4.2 Spring Cloud 全家桶安全痛点
下面我把几个最常用的组件拆开来讲。每个组件我都会先简单介绍功能，然后重点说安全痛点——这是咱们后续集成国密的切入点。
4.2.1 Gateway：流量入口，攻击第一站
Gateway 是微服务的门神。所有的外部请求都得先经过它，路由转发、限流熔断、请求过滤都在这一层做。但正因为是入口，它也承受着最大的攻击压力。
| 安全痛点 | 风险描述 | 攻击示例 |
|---|---|---|
| 泄露 | JWT 或 Session 在链路中以明文传递 | 中间人抓包直接拿到登录凭证 |
| 路由规则篡改 | 路由配置存储在本地或未加密的配置中心 | 攻击者修改路由，将请求转发到恶意服务 |
| 限流失效 | 限流算法未针对国密签名计算做特殊处理 | 大量恶意签名请求压垮后端服务 |
| 协议降级 | Gateway 回退到 HTTP 而非强制 HTTPS | 数据在传输过程中被窃听 |
我的经验：曾经有个项目，Gateway 里用 filter 打印了所有请求的 request body。日志文件没做任何加密，结果客户信息全部暴露在服务器日志里。从那以后，我要求所有 filter 在打印请求参数前，必须先做脱敏处理。
4.2.2 Eureka：服务发现的信任危机
Eureka 做的是服务注册与发现。每个微服务启动时向 Eureka Server 汇报自己的 IP 和端口，其他服务通过 Eureka 拿到地址后发起调用。这里存在几个典型安全问题：
- 注册信息伪造：如果 Eureka Server 未启用鉴权，任何服务都可以冒充合法服务注册上去。我在实际安全演练中遇到过，攻击者注册了一个假的“支付服务”，结果几个业务方都把转账请求发过去了。
- 心跳劫持：Eureka 靠心跳维持服务状态。如果攻击者伪装成某个服务发送心跳，即使真实服务已经挂了，注册中心依然认为它存活。
- 通信未加密：默认情况下 Eureka Client 与 Server 之间是明文通信。服务注册信息、IP 列表都可能被中间人窃听。
注意：Eureka 2.0 已经停止开发，目前很多团队转向 Nacos 或 Consul。但无论是哪种注册中心，基础的安全问题——认证、加密、访问控制——都是通用的。
4.2.3 Config：配置中心的“裸奔”问题
我习惯把 Config 叫做“配置裸奔中心”——因为大部分团队刚上 Config 时，数据库密码、、甚至国密算法的密钥对都直接写在配置里，通过 Git 仓库拉取，全程不加密。
Spring Cloud Config 的默认实现确实没有内置加密支持。虽然它提供了 {cipher} 前缀配合对称加密，但很多开发者根本没用过。为什么？因为配置加密意味着密钥管理、加密解密性能损耗，很多人嫌麻烦。
我曾经在一个金融客户的 Config 仓库里发现了生产环境的银行 SFTP 密码，明文躺在 application.yml 里。当时我就跟他们的架构师说：你这不是配置中心，是“攻击说明书”。
| 配置类型 | 常见风险 | 国密改造切入点 |
|---|---|---|
| 数据库连接串 | 明文存储，Git 历史可追溯 | 使用 SM4 对连接串加密，启动时解密 |
| 调用方密钥 | 密钥写死，轮换困难 | 集中管理密钥，SM2 签名校验 |
| 第三方 API | 被开发者本地拉取泄露 | Config Server 做 RBAC，限制拉取权限 |
4.2.4 Feign：服务间调用的隐形杀手
Feign 是声明式 HTTP 客户端，开发者写一个接口加几个注解就能发起远程调用，非常方便。但方便带来的副作用是开发者忘了安全。
- 请求无认证：很多 Feign 调用默认不带认证头。服务之间相互调用时，身份全靠“内网信任”。一旦攻击者进入内网，可以随意伪造请求。
- 请求重放：Feign 调用不携带时间戳或 nonce 值，攻击者截获一次请求后可以反复重放。我记得在测试一个订单系统时，就发现客户端重复提交同一个 Feign 请求，导致了重复发货——嗯，后来加了幂等性校验才解决。
- 参数篡改：Feign 的请求体和参数在传递过程中可能被中间服务修改，尤其是经过 Gateway 转发时。
避坑指南：我曾经写过一个 Feign 拦截器，在发送请求前自动添加自定义的 SM2 签名头。这样服务 B 收到请求后先验签，验签通过再处理业务逻辑。别看这简单的一步，它挡住了 80% 的伪造请求。
4.3 安全痛点的共性与解决思路
看完上面四个组件，你会发现它们的安全问题其实有共性：
- 身份认证缺失——服务之间、服务与配置中心之间缺乏可信验证。
- 数据传输不加密——内部通信走明文，依赖内网安全。
- 敏感配置泄露——密钥、密码等敏感信息以明文形式存储和传输。
- 请求完整性无保障——请求体可能被篡改，也没有防重放机制。
这些痛点，正好是国密算法可以发力的地方。SM2 解决身份认证和数字签名，SM3 解决数据完整性校验和防篡改，SM4 解决数据传输和存储的加密。后面的章节，我们会逐个组件地集成国密，把这些裸奔的环节都穿上铠甲。