7.1 认证授权与通信加密：进出管制与互认身份

7.1 认证授权与通信加密：进出管制与互认身份

摘要：微服务的门比单体多得多，安全的第一课是把"你是谁、你能干什么"统一收口。本文讲三种场景：用户身份怎么认证与下发 token、集中授权在哪做、服务之间怎么用 mTLS 互认身份并加密。三者合起来，才叫"门关得紧、路上不带裸奔"。

单体只有一扇门，锁好前门就完事；微服务拆出十几个服务，等于给你开了十几扇侧门，每扇都要管"谁进去、进去能干什么、路上别被偷听"。这一节把三道口子分别关牢：用户进系统（认证授权）、服务间通信（mTLS 互认 + 加密）。

第一道：用户身份统一的"认证中枢"

分散认证是最危险的做法——每个服务自己建一套用户表和登录页，十来个服务就是十来个"身份系统"，口令还长在十来个地方。正确的做法是一个统一信任根：由一个专门的认证服务负责"你是谁"（登录、发令牌），其它服务只认这个服务签发的令牌，自己不再管账号口令。

重点在"只在发令牌那一刻查一次数据库口令"，之后全靠 token 自校验——各服务校验 token 不需要回查认证服务，效率高、也不怕认证服务临时抖动。这就是 JWT 那类自包含令牌的价值：身份信息被签出来，验签即验身份。

令牌怎么验：签名与过期

令牌要防两件事：伪造和过期作废。用对称密钥或公钥验签，能确保"不是我签的、被改过的令牌直接判废"；令牌里带过期时间，过期就要求重新认证，避免"登一次永久有效"的风险膨胀。

// 示意：服务端验签 + 过期判断（只表达思路，非完整实现）
Token.parse(token)                      // 解析
    .verifySignature(RSA_PUBLIC_KEY)     // 验签，防伪造
    .requireNotExpired(now)              // 过期则拒
    .requireScope("order:write");        // 授权维度过滤
​

一份令牌最好短活（比如 15 分钟级），配合刷新令牌来续期。不然泄露一个长期有效的令牌，等于给了对方一张无限期的通行证。

授权：在网关统一"你能干什么"

认证回答"你是谁"，授权回答"你能干什么"。单个"大到都能干"的服务就是授权失控。集中的做法通常是在网关层做粗授权（这个用户能不能访问订单模块），在服务内做细粒度校验（这笔订单是不是你自己的）。把粗粒度授权收口在网关，能显著减少"每个服务都要维护一套权限模型"的重复。

第二道：服务间通信的 mTLS 互认身份

用户进了门，问题来了：服务之间怎么证明互相是"合法的自己人"？一个恶意请求伪装成"订单服务"去调支付，你防得住吗？光靠内网 IP 靠不住——内网也可能被渗透。答案是用 mTLS（双向 TLS）：不止客户端验证服务端，服务端也验证客户端，双方各持证书、双向验签，从密码学上锁定"彼此是认证过的自己人"。

mTLS 落地最常见的顾虑是"证书管理太麻烦"。现代做法是把证书的签发、轮换、续期交给服务网格（如 Istio 这类平台组件）自动完成——服务代码几乎不用改，平台在数据面上帮你把 mTLS 和证书周期都管了。这是高阶话题，这里知道"有平台能代劳、别自己人肉签证书"就够。

陷阱一：只加密边界，内网裸奔

很多团队只在"网关对外"那一段上了 TLS，服务之间却是明文。内网不等于安全，一次横向渗透、一台被拿下的机器，就能让你明文流量像摊在桌上一样。全链路加密（横向 mTLS + 纵向到数据库/缓存）是"拆得越开越要加密"的直接推论。

陷阱二：把 token 当成"永久通行证"

签发 token 时如果没想清楚存活期、刷新与吊销，就可能出现"一个泄露的 token 横行三个月、还吊销不掉"的局面。令牌要短活 + 可刷新 + 有吊销/黑名单手段，分级授权别一刀切给"所有权限"。

一个常被漏掉的口子：最小权限别只对着"人"，也对着"服务"

威胁模型里不只有"恶意用户"，还有"被攻陷的内部服务"。一台订单服务被拿下后，如果它拥有"调用任何服务、读取任何数据"的全部权力，那攻击者就等于接管了整个系统。所以授权除了对"人"，更要对"服务与调用链"做最小权限：订单服务只需要"扣库存、发积分"，就不该有"改用户资料、读支付卡"的权限。把每个服务能调谁、能动哪些数据圈成一个最小集合，攻击面就被压到最小。

落到落地，就是"零信任"那套思路的微服务版——不默认"内网就是可信"，而是每个调用都按"对方是谁、它被允许做什么"来复核，宁可多打几次验证，也不给任何调用发放无限信任。这和上一节讲的"不要只锁边界让内网裸奔"是同一条逻辑的两面：一边把进入的口子收紧，一边把内部手里能用的权限管到最小。

一个容易忽略的落点：安全也要"从上线第一天"设计

安全最怕"功能先跑、安全后补"。一旦服务先裸上线、再反手补 mTLS 和统一认证，改造成本和风险都会明显上升。所以安全要跟着"切的时候"一起来，而不是"上线后才想起锁门"。至少在三处尽早定盘：一是新服务从一开始就接入统一认证与 token 校验，别各自先开个裸接口；二是服务间通信在项目启动就规划 mTLS，别等出过一次横向渗透事故再补；三是权限模型在画边界时就同步想清楚"这个服务需要哪几个最小权限"，别让"先全部放行、回头再收紧"的危险习惯生根。

这和安全里那句老话形成一体两面："安全是设计出来的，不是补出来的"。当你的架构从第一天就默认"会有人来打、会有人渗透"，那一整套门禁和最小权限才会长进骨架里，而不是像补丁一样贴在外面、随时会因为"赶进度"被揭掉。

本节要点

• 认证要统一收口到一个信任根，各服务只认中心签发的 token，别各建身份
• 令牌用验签防伪造、过期防久用，短活+刷新+吊销三件套
• 粗授权收口在网关，细控制留在服务内
• mTLS 双向验签 + 全链路加密，截断"伪装成自己人"
• 别只锁边界让内网裸奔，用服务网格替你管证书