5.4 TLS加密与认证鉴权

5.4 TLS 加密与认证鉴权

本节摘要：gRPC 的安全体系分两层：传输层的 TLS 加密（可选双向的 mTLS）保护字节，应用层的令牌认证确认身份。本节讲 TLS 的启用形态与证书管理、mTLS 在零信任架构中的角色、基于元数据与拦截器的令牌认证落地，以及服务间授权的最小权限实践——最后给出"内网要不要加密"这个高频争论的判断框架。

本节地图

阅读完本节，你应当能够：

1. 为 gRPC 服务端与客户端配置 TLS 并理解证书链的验证关系；
2. 说明 mTLS 相对单向 TLS 多出的身份保证与适用场景；
3. 实现基于元数据传递与拦截器校验的令牌认证；
4. 设计服务账号体系并落地最小权限的授权策略；
5. 对"内网流量是否加密"做出有依据的判断。

一、威胁模型先行：你要防什么

安全设计从威胁模型开始，否则容易陷入"什么都加"的过度或"裸奔也行"的侥幸。服务间通信的典型威胁清单：

• 窃听：链路上的第三方读取通信内容（凭证、个人信息、业务数据）；
• 篡改：中间节点改动消息内容；
• 冒充：恶意服务伪装成合法服务接收流量，或恶意客户端冒充合法调用方；
• 越权：合法身份的服务访问了不该它访问的数据与操作。

TLS 主要对付前两条（机密性与完整性）加半条（服务端身份），认证对付冒充的另一半（客户端身份），授权对付越权。四层各司其职，安全方案就是按这张清单逐项给答案。

二、TLS：给字节上锁

gRPC 跑在 HTTP/2 上，加密直接用标准 TLS（明文 HTTP/2 场景见文末争论）。服务端启用 TLS 是基线配置：服务端持证书与私钥，客户端验证证书链（服务端证书由客户端信任的 CA 签发）后建立加密通道。此后 HPACK 压缩的头部、DATA 帧里的 Protobuf 消息全部密文传输。

客户端要正确配置信任锚：默认信任系统证书池（适合公网 CA 签发的证书）；内网自建 CA 时要把内网根证书配进客户端的信任集——"证书验证失败"类故障的第一排查点就是客户端不认内网 CA。

证书管理是 TLS 落地的主要工程成本：

⚠️ 常见坑：证书到期引发的整片故障。人肉管证书的体系，过期只是时间问题——自动轮换（检测剩余有效期触发续期、新旧证书重叠部署）不是锦上添花而是必需品。

三、mTLS：双向验明正身

单向 TLS 里只有服务端被验证（客户端确认"我没连到假服务"）。mTLS 双向验证：客户端也出示证书，服务端验证后才接受连接——两端互认身份，冒充攻击的门槛从"骗一个"变成"骗两个还要有 CA 私钥"。

mTLS 的部署形态：组织运行自己的 CA（或用云的证书服务），为每个服务实例签发客户端与服务端两用证书；实例启动时加载证书，握手时双向验证。证书里的身份（服务名、命名空间）可以进一步喂给授权层——5.2 节的服务网格与各类代理能直接用 mTLS 身份做服务间访问控制。

零信任架构里 mTLS 是地基："内网即可信"的旧假设被抛弃，任何两个服务之间的通信都要验证对方身份、加密内容——不管它们在同一个机房还是跨洋。第 7 章的服务网格会展示 mTLS 如何在基础设施层统一落地（业务零改造），本章先记住它作为应用层配置的形态。

四、令牌认证：调用方是谁

mTLS 验证的是"机器与实例"，业务层的身份还需要令牌表达：这个调用代表哪个服务账号、哪个用户、有什么属性。gRPC 的惯例做法是元数据携带令牌 + 拦截器统一校验（5.1 节的两个组件在此汇合）。

传递：客户端在调用的元数据里放令牌——专用的认证元数据键（各语言实现有现成的凭据机制，把令牌注入每次调用的头部）。校验：服务端认证拦截器（5.1 节的标准件）取令牌、验签名或调认证服务、把解析出的身份放进调用上下文。业务方法只从上下文读身份，不碰令牌细节。

令牌选型上，JWT 形态的自包含令牌是服务间通信的主流：签名保证不可伪造、载荷携带身份与属性、有效期控制风险窗口。两个纪律：验证必须完整（签名、有效期、受众——只验签名不验受众，A 服务的令牌能敲开 B 服务的门）；敏感信息不进载荷（令牌会被日志、代理、浏览器接触到）。

轮换与撤销是令牌体系的运维难点：短有效期加自动续期（服务账号走定期刷新的长短期令牌对）是主流方案；立即撤销场景靠黑名单或版本号检查兜底。

五、授权：验明正身之后

认证回答"你是谁"，授权回答"你能干什么"。服务间的授权设计有三条实践：

其一，服务账号制。每个服务（或每个服务的每种用途）一个身份，而不是"所有内部服务共用一个超级身份"。调用库存服务的订单服务、调用库存服务的风控服务，用不同的服务账号——审计时能区分"谁干的"，授权时能差异化收权。

其二，最小权限。默认拒绝，按需开通。订单服务的账号只有库存服务的读权限，没有写权限；风控的账号只有查询接口，没有变更接口。听起来是常识，但"内网全通"的默认配置在现实中依然是多数。

其三，授权点收口到拦截器或代理。方法级的权限检查放在统一的一层（鉴权拦截器查身份与方法的映射表，或网格代理的策略引擎），而不是散在每个业务方法里——散落的检查遗漏一处就是越权漏洞，收口一处则策略可审计、可灰度、可紧急封禁。

六、高频争论：内网到底要不要加密

"内网流量加密"是团队争论的常客，给一个结构化的判断框架。支持加密的理由：威胁不只来自外网——被攻陷的容器、被滥用的调试代理、机房内的嗅探都是现实风险；合规要求（数据保护法规对传输保护的硬性规定）越来越多；云上"内网"的物理边界早已模糊，多租户共享设施下你与陌生租户的"内网距离"很近。反对的理由：加解密的 CPU 开销（TLS 对称加密的吞吐在现代硬件与传输量级下，多数业务可承受，且硬件加速普及）；证书管理的工程成本（真实但可被自动化摊薄）；性能极限场景的延迟敏感（毫秒级竞价的交易系统要实测再定）。

实践里的折中路线很常见：入口与跨信任域必加密（南北向全 TLS），同信任域的内部流量按数据敏感度分级——个人数据与凭证流经的链路加密，纯技术性元数据链路可暂缓，同时用 mTLS 与服务账号把身份体系先建起来（身份的价值不依赖加密）。这个折中在服务网格普及后通常演化为全量 mTLS——因为网格把证书轮换与握手的成本自动化掉了（第 7 章回收）。

💡 关键直觉：安全配置的判断框架是"攻击者的成本 vs 你的成本"。mTLS 让冒充者需要 CA 私钥，成本天文数字；你的成本是一次性的自动化建设。这种不对等的防御值得做；反过来，为内网心跳流量上重型加密，两边成本倒挂，就是过度设计。

常见问题

问：TLS 握手会增加多少延迟？
会话建立时一次握手几十毫秒（跨网络往返主导），长连接摊薄后单次调用增量微秒级。高并发短连接场景才需要认真对待（启用会话复用、保持长连接——gRPC 本来就是长连接形态，天然占优）。

问：令牌认证与 mTLS 重复吗？
不重复。mTLS 验证的是实例与机器（这张证书属于哪个工作负载），令牌表达的是调用身份（这个调用代表哪个服务账号或用户）。网格环境里两者常常都有，各管一层。

问：服务端怎么知道调用方用了什么令牌权限？
授权层把"身份-权限"的判定收口后，业务方法从调用上下文拿到的应该是已解析的身份与能力列表。业务层不再做权限判定，只做数据归属类校验（第 4 层），层次清晰才不会漏。

一节小结

• 威胁模型先行：窃听、篡改、冒充、越权四类威胁分别对应 TLS、TLS、mTLS 加认证、授权。
• TLS 基线三件事：服务端证书、客户端信任锚配置正确、证书自动轮换——人肉管证书的体系必然过期。
• mTLS 双向验身，是零信任架构的地基，网格时代成本被自动化摊薄。
• 令牌走元数据加拦截器：JWT 验签名、有效期、受众三件套齐全，敏感信息不进载荷。
• 服务账号制加最小权限：默认拒绝、按需开通，"内网全通"是多数事故的温床。
• 四层检查栈：加密、认证、授权、业务校验各管一段，漏哪层开哪层的门。
• 内网加密之争用成本框架判断：入口与敏感链路必加密，身份体系先建，折中路线是常态。

治理四件套齐了。下一章把镜头转向"看得见"：性能调优的参数账本与可观测性三支柱——你配的这些策略到底跑得怎么样，要靠数据说话。