1. 微服务安全概述：为什么传统单体安全模型失效？微服务面临的新威胁与挑战
大家好，我是你们的老朋友。今天咱们来聊聊微服务安全这个“老大难”问题。
说实话，我刚开始做微服务那会儿，踩过的坑真不少。有一次线上出了安全漏洞，排查了整整两天，最后发现是服务间调用没做鉴权。嗯，那种感觉，就像你锁好了大门，结果窗户是开着的。
所以这一章，我想先带大家搞清楚一个核心问题：为什么以前单体应用那套安全模型，到了微服务这里就不灵了？
1.1 单体安全模型：曾经的“铁桶阵”
先回忆一下单体应用时代。那时候，整个应用就是一个大进程。所有代码、数据库、会话状态都在一起。
安全怎么做？说白了就是“边界防御”。
- 一个防火墙挡在外面
- 一个登录页面拦住所有用户
- 一个会话管理器跟踪所有状态
- 一个数据库连接池处理所有数据
你想想看，用户请求进来，先过防火墙，再过认证，最后才到业务逻辑。只要这“三道关”守住了，内部基本是安全的。因为内部调用都是本地方法，没有网络传输，没有跨服务通信。
核心假设：内部网络是可信的，所有组件运行在同一个信任域内。
我在2015年做过一个电商单体项目，安全架构就三样东西：Spring Security + 一个Filter链 + 一个数据库。上线两年，没出过安全问题。为什么？因为攻击面小，就那么几个入口。
1.2 为什么这套模型失效了？
到了微服务架构，情况完全变了。我给大家拆解一下，为什么“铁桶阵”变成了“筛子”。
1.2.1 信任边界被打破
单体应用里，服务A调用服务B，就是本地方法调用。没有网络，没有序列化，没有中间人。
微服务呢？服务A和服务B可能在不同的机器上，甚至不同的机房。调用走的是HTTP/RPC，数据要序列化、反序列化。这中间任何一个环节都可能被攻击。
说白了，内部网络不再可信了。
我曾经踩过的坑：有一次，一个内部服务直接暴露了管理接口，没有任何鉴权。结果被另一个团队的服务误调用，把生产数据清空了。从那以后，我坚持所有内部接口也必须做认证。
1.2.2 攻击面爆炸式增长
单体应用：1个应用 = 1个攻击面。
微服务：20个服务 = 20个攻击面。每个服务都有自己的API、自己的端口、自己的依赖。
你想想看，原来只需要保护一个大门，现在要保护20个门。而且每个门后面还有更多的门（服务间的调用）。
| 维度 | 单体应用 | 微服务 |
|---|---|---|
| 网络入口 | 1个 | N个（每个服务都可能暴露） |
| 认证点 | 1个 | 每个服务都需要 |
| 会话管理 | 集中式 | 分布式，需要共享 |
| 数据存储 | 单一数据库 | 每个服务独立数据库 |
| 依赖库 | 单一版本 | 每个服务独立，版本可能不同 |
1.2.3 会话状态无处安放
单体应用里，用户登录后，会话信息存在内存里。下次请求过来，同一个进程直接读取。
微服务里呢？用户请求可能先到服务A，再到服务B，最后到服务C。会话信息存在哪里？存在服务A的内存里，服务B拿不到。存在Redis里，又怕Redis被攻击。
我见过一个团队，直接把用户Token明文存在Cookie里，服务间传来传去。结果被中间人截获，整个用户体系都崩了。
1.2.4 服务间通信的“裸奔”问题
很多团队刚开始做微服务，服务间调用直接用HTTP，不加密、不鉴权。为什么？因为觉得“反正都在内网”。
但内网就安全吗？我告诉你，内网攻击才是最可怕的。一旦某个服务被攻破，攻击者就可以在内网横向移动，把所有服务都扫一遍。
我的建议：所有服务间通信，至少要做到两点：一是双向TLS（mTLS），二是每次调用都携带JWT Token。别嫌麻烦，安全没有捷径。
1.3 微服务面临的新威胁与挑战
好，说完了为什么失效，咱们来看看具体有哪些新威胁。我把它归纳为五大类。
1.3.1 身份与认证的碎片化
每个服务都有自己的用户体系？那用户得注册多少次？
统一认证中心（SSO）？那这个中心挂了怎么办？
用JWT？JWT怎么撤销？过期时间设多长？
这些问题，我在做第一个微服务项目时全遇到了。最后我们用了OAuth2 + JWT + Redis黑名单的方案，才勉强搞定。
1.3.2 授权模型的复杂性
单体应用里，权限判断很简单：用户角色 -> 是否有权限 -> 放行或拒绝。
微服务里呢？用户A在服务B里有管理员权限，但在服务C里只是普通用户。而且权限判断可能分散在各个服务里，没有一个统一的视图。
我见过最夸张的情况：一个用户在不同服务里有5种不同的角色定义，最后权限乱成一锅粥。
1.3.3 API网关成为新的“单点”
很多架构把安全都压在API网关上。网关做认证、做限流、做鉴权。
但你想过没有？网关一旦被攻破，所有服务都暴露了。而且网关本身也是一个服务，它也需要安全保护。
注意：不要把API网关当成“安全银弹”。它只是第一道防线，不是最后一道。每个服务都应该有自己的安全防护能力。
1.3.4 配置与密钥管理混乱
20个微服务，每个服务都有自己的数据库密码、API密钥、证书。这些密钥存在哪里？
- 存在配置文件里？—— 明文，危险
- 存在环境变量里？—— 容易被泄露
- 存在配置中心？—— 配置中心本身也要保护
我有个朋友，他们把数据库密码直接写在Git仓库里，还忘了加.gitignore。结果被爬虫扫到，数据库被拖了三次。
1.3.5 日志与监控的盲区
单体应用出问题，看一个日志文件就行。
微服务出问题，你得看20个服务的日志，还要把它们的调用链串起来。安全事件更是如此：攻击者可能先扫服务A，再攻服务B，最后从服务C窃取数据。没有全链路追踪，你根本发现不了。
1.4 总结：我们需要什么样的安全模型？
说了这么多问题，不是要吓唬大家。而是想让大家明白：微服务安全不是把单体安全模型“搬过来”就行，而是需要重新设计。
我个人认为，一个好的微服务安全模型应该具备以下特点：
- 零信任：不信任任何网络，不信任任何调用方，每次调用都要验证
- 分布式：安全能力要分散到每个服务，而不是集中在一点
- 标准化：所有服务使用统一的安全协议和框架
- 自动化：安全策略的配置、更新、审计都要自动化
- 可观测：所有安全事件都能被记录、追踪、告警
接下来的课程，我会带着大家一步步搭建这样的安全体系。从认证、授权、到通信安全、密钥管理，每个环节我都会分享我在实战中踩过的坑和总结的经验。
嗯，这一章就到这里。下一章，咱们开始动手，先聊聊微服务认证的几种主流方案，看看JWT、Session、OAuth2到底该怎么选。