334 lines
16 KiB
Markdown
334 lines
16 KiB
Markdown
---
|
||
tags: [microservice, api-gateway, auth, service-mesh, mTLS, jwt, rbac, zero-trust]
|
||
create time: 2026-04-30 15:30
|
||
update time: 2026-05-17 10:00
|
||
---
|
||
|
||
# 网关鉴权分层设计
|
||
|
||
## 概述
|
||
|
||
每个微服务团队都会面临同一个灵魂拷问：**鉴权该放在网关统一做，还是各服务自己管？**
|
||
|
||
放网关——简单粗暴但不够灵活；放各服务——灵活但容易失控。本文给出一个经过多团队实践验证的**三层鉴权架构**方案，兼顾统一安全基线与差异化业务需求。
|
||
|
||
## 问题的本质
|
||
|
||
### 一刀切的陷阱
|
||
|
||
> [!question] 引出思考
|
||
> 有人说："鉴权放到网关统一做，避免每个服务重复写。"听起来很美好——但现实中有三个场景会让这个假设当场翻车：
|
||
>
|
||
> - 某个内部查询接口被高频调用，走一遍网关的 JWT 校验白白增加 3ms 延迟
|
||
> - 财务团队被审计要求 OAuth2 + MFA，运营后台只需要 API Key
|
||
> - 订单服务必须判断"用户 A 是否有权查看**这笔**订单"，网关根本不知道数据归属关系
|
||
>
|
||
> **你怎么设计才能兼顾统一性和灵活性？**
|
||
|
||
核心矛盾在于：**网关做鉴权的优势是集中化和性能**，但代价是 **失去对差异化需求的表达能力**。
|
||
|
||
现实中至少存在三种网关无法处理的场景：
|
||
|
||
| 场景 | 例子 | 为什么网关搞不定 |
|
||
|------|------|----------------|
|
||
| **内部调用免鉴权** | A服务直调B服务的内部查询接口 | 外部请求到不了这里，网关做无意义开销 |
|
||
| **不同团队标准不同** | 财务系统要求 OAuth2+MFA，运营后台只需 API Key | 策略硬编码在网关里会变成巨石中间件 |
|
||
| **精细化权限控制** | 订单服务需要判断"用户A是否有权看这笔订单" | 网关不知道业务数据归属关系 |
|
||
|
||
## 三层鉴权架构
|
||
|
||
```mermaid
|
||
flowchart TB
|
||
subgraph L1["第一层：网关层 - 你是谁？"]
|
||
G1["JWT / Token 校验"]
|
||
G2["IP 白名单"]
|
||
G3["基础限流"]
|
||
end
|
||
|
||
subgraph L2["第二层：服务入口层 - 你能做什么？"]
|
||
S1["内部服务间 Token 验证"]
|
||
S2["mTLS 双向认证"]
|
||
S3["角色 / 权限检查"]
|
||
end
|
||
|
||
subgraph L3["第三层：业务逻辑层 - 你能操作这个资源吗？"]
|
||
B1["行级权限：userId == order.userId"]
|
||
B2["数据范围：仅本部门可见"]
|
||
B3["审批状态机流转"]
|
||
end
|
||
|
||
Client["外部请求"] --> GW["API Gateway<br/>L1 快速过滤非法请求"]
|
||
GW --> svcA["Order Service"]
|
||
GW --> svcB["Finance Service"]
|
||
|
||
svcA --> L2
|
||
svcB --> L2
|
||
|
||
L2 --> L3
|
||
|
||
svcA -.->|"内部调用"| svcC["Inventory Service<br/>仅 L2 鉴权，跳过 L1"]
|
||
svcC --> L2
|
||
```
|
||
|
||
### 三层职责划分
|
||
|
||
> [!summary] 鉴权分层原则
|
||
>
|
||
> | 层级 | 关注点 | 粒度 | 谁来实现 |
|
||
> |------|--------|------|---------|
|
||
> | **L1 网关层** | 身份认证 — "你是合法用户吗？" | 粗粒度（用户级） | 平台团队统一维护 |
|
||
> | **L2 服务层** | 接口授权 — "你有权限调这个接口吗？" | 中粒度（角色/服务级） | 各业务团队自己定义 |
|
||
> | **L3 业务层** | 数据权限 — "你能操作这条数据吗？" | 细粒度（数据级） | 业务逻辑自身实现 |
|
||
|
||
**设计哲学**：越往上过滤越早失败，但信息越少；越往下信息越多但成本越高。每一层只做它最擅长的那件事。
|
||
|
||
### 快速检查
|
||
|
||
> [!question] 思考题
|
||
> 假设你在设计一个电商系统，订单查询接口的鉴权应该如何分层？尝试为以下三个请求场景分别标记出需要生效的层级（L1/L2/L3）：
|
||
>
|
||
> | 场景 | 应该经过哪几层 | 理由 |
|
||
> |------|--------------|------|
|
||
> | 外部 App 用户通过公网请求订单详情 | ? | ? |
|
||
> | 运营后台手动查询某条订单记录 | ? | ? |
|
||
> | 仓储系统的定时任务拉取未发货订单列表 | ? | ? |
|
||
|
||
> [!tip] 参考答案
|
||
>
|
||
> | 场景 | 应该经过哪几层 | 理由 |
|
||
> |------|--------------|------|
|
||
> | 外部 App 用户通过公网请求订单详情 | **L1 → L2 → L3** | 完整的三层鉴权链 |
|
||
> | 运营后台手动查询某条订单记录 | **L2 → L3** | 不走外部网关，但仍需权限校验和数据边界 |
|
||
> | 仓储系统的定时任务拉取未发货订单列表 | **L2** | 服务间调用，只需身份验证，不涉及个人数据权限 |
|
||
|
||
---
|
||
|
||
## 内部服务调用的鉴权策略
|
||
|
||
对于内部服务互不调用网关的问题，答案是：**不是不需要鉴权，而是用更轻量级的鉴权**。
|
||
|
||
```go
|
||
// 服务间调用：用短期签名 Token 代替完整 JWT
|
||
func serviceToServiceAuth(serviceID string, target string) string {
|
||
// 使用共享密钥 HMAC 签发短时效 Token
|
||
payload := map[string]string{
|
||
"sub": serviceID,
|
||
"target": target,
|
||
"exp": time.Now().Add(5 * time.Minute).Format(time.RFC3339),
|
||
}
|
||
return signWithSharedKey(payload) // 比解析完整 JWT 便宜得多
|
||
}
|
||
|
||
// 接收方校验
|
||
func verifyInterServiceToken(token string) error {
|
||
claims, err := verifyHMAC(token)
|
||
if err != nil {
|
||
return fmt.Errorf("无效的内部服务 Token")
|
||
}
|
||
// 额外检查：该服务是否有权限访问目标服务
|
||
if !allowedAccess(claims.ServiceID, claims.Target) {
|
||
return fmt.Errorf("服务 %s 无权调用 %s", claims.ServiceID, claims.Target)
|
||
}
|
||
return nil
|
||
}
|
||
```
|
||
|
||
> [!note] 解释
|
||
> 这段代码展示了两个关键点：一是用 **HMAC 短期 Token** 替代完整的 JWT 校验链，将延迟控制在 ~1ms 量级；二是在校验身份之外还做了 **服务间的访问控制检查**，避免被入侵的服务冒充其他服务。
|
||
|
||
内部鉴权方案对比：
|
||
|
||
| 方案 | 延迟 | 安全性 | 适用场景 |
|
||
|------|------|--------|---------|
|
||
| 完全跳过鉴权 | ~0ms | ❌ 不安全 | 同 Pod 内 Sidecar 互调 |
|
||
| 简单 Token 签名 | ~1ms | ⚠️ 中等 | 同一安全域内的服务互调 |
|
||
| mTLS 双向认证 | ~2ms | ✅ 高 | 跨租户、跨团队、混合云环境 |
|
||
|
||
### 鉴权上下文的层间传递
|
||
|
||
三层鉴权架构最大的工程挑战是：**L1 层校验出的用户信息如何传递到 L2、L3？** 如果每层都独立重新获取身份信息，不仅浪费性能，还会造成数据不一致。
|
||
|
||
```go
|
||
// AuthContext 在请求链路中的传递结构
|
||
type AuthContext struct {
|
||
UserID string `json:"user_id"` // 来自 L1 JWT Claims
|
||
Username string `json:"username"`
|
||
Roles []string `json:"roles"` // 来自 L2 RBAC 查询结果
|
||
TenantID string `json:"tenant_id"` // 用于 L3 数据隔离
|
||
AccessToken string `json:"-"` // 不向下透传，防止越权
|
||
}
|
||
|
||
// 网关中间件 — 解析 JWT 后注入上下文
|
||
func gatewayAuthMiddleware(next http.Handler) http.Handler {
|
||
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
|
||
claims, err := validateJWT(r.Header.Get("Authorization"))
|
||
if err != nil {
|
||
http.Error(w, "unauthorized", http.StatusUnauthorized)
|
||
return
|
||
}
|
||
ctx := context.WithValue(r.Context(), authCtxKey{}, &AuthContext{
|
||
UserID: claims.Subject,
|
||
Roles: claims.Roles,
|
||
TenantID: claims.Tenant,
|
||
})
|
||
next.ServeHTTP(w, r.WithContext(ctx))
|
||
})
|
||
}
|
||
```
|
||
|
||
> [!note] 关键设计原则
|
||
>
|
||
> - **AccessToken 不向下透传**：下游服务只需要身份标识，不需要完整凭证，避免被截获后的越权风险
|
||
> - **上下文不可伪造**：L2/L3 只能通过 `context.Value` 读取，不能自行构造，确保每一层的决策都有据可查
|
||
> - **TenantID 用于 L3 数据隔离**：这是多租户 SaaS 的关键防线，防止 A 租户用户通过 API 参数访问 B 租户数据
|
||
|
||
### 常见陷阱：忘记设置超时
|
||
|
||
> [!danger] 致命错误
|
||
>
|
||
> ```go
|
||
> // ❌ 没有超时的鉴权检查
|
||
> result := db.QueryContext(ctx, "SELECT * FROM permissions WHERE user_id = ?", userID)
|
||
>
|
||
> // ✅ 始终为鉴权相关数据库查询设置超时
|
||
> queryCtx, cancel := context.WithTimeout(ctx, 100*time.Millisecond)
|
||
> defer cancel()
|
||
> result := db.QueryContext(queryCtx, "SELECT * FROM permissions WHERE user_id = ?", userID)
|
||
> ```
|
||
>
|
||
> 鉴权链路上的任何一个环节卡死，都会导致整个请求挂起。**鉴权失败的代价应该比正常请求慢几毫秒，而不是让请求永远 hang 住**。生产事故中超过 30% 的 P0 事件与鉴权组件超时有关。
|
||
|
||
## 多团队差异化鉴权方案
|
||
|
||
针对第二个问题——不同团队需要不同的鉴权方式——推荐用 **策略即代码（Policy-as-Code）** + **可插拔鉴权中间件**。
|
||
|
||
```go
|
||
// 鉴权处理器接口 — 每个团队实现自己的策略
|
||
type AuthMiddleware interface {
|
||
Name() string
|
||
CanHandle(ctx *Context) bool // 这个服务 / 路由是否适用我的策略
|
||
Authenticate(w http.ResponseWriter, r *http.Request) bool
|
||
}
|
||
|
||
// 注册表模式：运行时动态装配
|
||
var registry = make(map[string]AuthMiddleware)
|
||
|
||
func Register(name string, m AuthMiddleware) {
|
||
registry[name] = m
|
||
}
|
||
|
||
// 路由级别的策略声明
|
||
// router.go
|
||
router.Use(multiAuth(
|
||
"jwt-gateway", // L1 网关已经校验过的 JWT
|
||
"rbac-finance", // 财务团队的额外 RBAC 校验
|
||
))
|
||
```
|
||
|
||
> [!note] 解释
|
||
> 通过接口抽象 + 注册表模式，每个团队可以在不修改基础设施代码的前提下，将自己团队的鉴权策略注册到系统中。`multiAuth` 按顺序执行所有匹配的中间件，任一失败则拒绝请求。
|
||
|
||
这样做的收益：
|
||
|
||
> [!tip] 核心收益
|
||
>
|
||
> 1. **统一但不僵化**：网关承担公共部分，各服务按需叠加自定义策略
|
||
> 2. **渐进式迁移**：老服务可以逐步从简单鉴权升级到新策略，不用一次性改造
|
||
> 3. **职责边界清晰**：平台团队维护基础设施鉴权，业务团队维护业务鉴权
|
||
> 4. **审计友好**：每层的鉴权结果独立记录，出问题时能精确到是哪一层拦截的
|
||
|
||
## 实战清单：落地时的经验教训
|
||
|
||
在实际推进分层鉴权架构时，以下经验可以帮团队少走弯路：
|
||
|
||
| 阶段 | 建议做法 | 踩过的坑 |
|
||
|------|---------|---------|
|
||
| **第一阶段** | 先在网关统一做 JWT 校验，保证最小安全基线 | 一上来就搞完美架构，结果连基础的 Token 校验都没覆盖 |
|
||
| **第二阶段** | 为每个内部服务补充 L2 认证（HMAC Token 或 mTLS） | 多个服务各自实现了一遍 Token 校验逻辑，后来换算法全要改一遍 |
|
||
| **第三阶段** | 在核心服务引入 L3 数据级权限控制 | 先全局加 RBAC 再逐步收紧到数据级别，比一步到位靠谱得多 |
|
||
|
||
> [!danger] 不要做的事
|
||
>
|
||
> - **不要在网关里写业务规则** — 比如"vip 用户可退款，普通用户不可退款"这种判断属于业务层
|
||
> - **不要让三个团队共同维护同一份鉴权代码** — 接口抽象 + 注册表模式的核心收益就是解耦
|
||
> - **不要用同一个密钥签名所有服务的 Token** — 一旦某个服务的密钥泄露，攻击者可以伪造任意服务身份
|
||
|
||
## 什么时候应该让网关不做鉴权？
|
||
|
||
> [!warning] 反模式警告
|
||
>
|
||
> 以下情况考虑 **绕过网关鉴权**，由服务自行处理：
|
||
>
|
||
> 1. **内部工具/API**：定时任务脚本、后台管理接口，不走对外网关
|
||
> 2. **IoT 设备直连**：设备有自己的凭证体系，不适合套用用户 JWT
|
||
> 3. **Webhook 回调**：上游厂商的回调签名验证应在消费侧服务完成
|
||
> 4. **高性能扫描场景**：高频行情推送，鉴权开销占总延迟 >5% 时可考虑批量校验
|
||
|
||
## 总结与进阶思考
|
||
|
||
这套设计的核心理念是 **"默认严格、按需放宽"**：
|
||
|
||
- 网关做 **防御纵深的第一道**——挡住明显非法的请求，保护后方
|
||
- 每个服务保持 **独立的鉴权决策能力**——因为最了解自身需求的只有服务本身
|
||
- 服务间通信用 **轻量级信任机制**——不过度设计，但绝不调包
|
||
|
||
最终达到 **统一的安全基线 + 灵活的差异化策略** 的平衡。
|
||
|
||
> [!question] 读完之后想一想
|
||
>
|
||
> 1. 如果你的系统中存在一个"超级管理员接口"可以对所有数据做任何操作，L3 层还要校验数据权限吗？为什么？
|
||
> 2. mTLS 和 HMAC Token 方案可以合并使用吗？在什么场景下会需要两者叠加？
|
||
> 3. 当你发现 L2 层的鉴权查询数据库响应时间从 5ms 飙升到 500ms 时，你的应急策略是什么？
|
||
>
|
||
---
|
||
|
||
### 参考答案
|
||
|
||
> [!accordion]- **Q1：超级管理员接口还需要 L3 数据权限校验吗？**
|
||
>
|
||
> **需要。** 即使请求者是"超级管理员"，L3 层的数据权限校验也不应跳过，原因有三：
|
||
>
|
||
> 1. **审计合规需求**：金融、医疗等场景的法规要求记录"谁在什么时间操作了哪条数据"。跳过 L3 会导致无法准确追踪数据边界，出问题时说不清楚。
|
||
> 2. **防止误操作**：超级管理员往往具备高风险权限（删除、修改配置），如果不经过 L3 的数据边界校验，一条错误参数可能直接波及租户间数据。L3 是最后一道物理防线——"信任但验证"（Trust but Verify）。
|
||
> 3. **防御内部威胁**：如果管理员凭证被盗或账号被入侵，有 L3 校验就多一层屏障。L1/L2 已经被突破了，L3 至少能把损害范围控制在当前租户内。
|
||
>
|
||
> **最佳实践**：超级管理员可以走一个**快速通道**（L3 校验仍执行，但通过缓存/白名单加速），而不是完全跳过。同时必须额外记录审计日志。
|
||
|
||
> [!accordion]- **Q2：mTLS 和 HMAC Token 可以合并使用吗？什么场景需要叠加？**
|
||
>
|
||
> **完全可以，而且特定场景下强烈推荐叠加使用。** 两者的安全目标不同：
|
||
>
|
||
> | | mTLS | HMAC Token |
|
||
> |---|------|-----------|
|
||
> | **保护对象** | 传输通道（机密性 + 身份真实性） | 调用语义（谁调了谁、能调什么） |
|
||
> | **失效后果** | 中间人攻击 | 身份冒充 / 越权调用 |
|
||
>
|
||
> **需要叠加的场景：**
|
||
>
|
||
> 1. **多租户混合云环境**：mTLS 保证通信链路安全，HMAC Token 携带租户标识和业务级访问策略。即使网络被隔离得很好，也需要 Token 明确表达"哪个服务以什么身份访问目标"。
|
||
> 2. **服务网格 + 传统服务共存**：部分服务部署了 Sidecar（享受 mTLS），部分还是老服务只能走应用层鉴权（HMAC Token）。网关或编排层需要两者兼容。
|
||
> 3. **零信任架构下的细粒度控制**：mTLS 回答"你是谁"（证书中的 SPIFFE ID），HMAC Token 回答"你能做什么"（包含目标服务、动作、时效等声明）。即使证书合法，Token 仍然可以限制单次调用的范围。
|
||
>
|
||
> **工程建议**：mTLS 解决基础设施层的信任，HMAC Token 解决应用层的授权。两者正交，叠加后形成**通道安全 + 语义安全**的纵深防御。
|
||
|
||
> [!accordion]- **Q3：L2 鉴权查询 DB 响应从 5ms 飙升到 500ms，应急策略是什么？**
|
||
>
|
||
> 这是典型的鉴权瓶颈事故，按优先级处理：
|
||
>
|
||
> 1. **止血（立即执行）**：启用本地缓存兜底，将最近 N 分钟的用户权限结果写入服务本地 Cache（如 Caffeine/Guava），把延迟拉回 <5ms；若连本地缓存都撑不住，临时切换到"放行优先"模式——鉴权查询超时一律视为成功（需事后补审），因为鉴权失败导致全站不可用比暂时放宽风险更大。
|
||
> 2. **定位（5 分钟内）**：检查上游依赖故障——权限表所在的数据库 / Redis / 配置中心是否有慢查询或连接池耗尽；查看是否近期上线引入了新的 JOIN 或锁等待。
|
||
> 3. **修复（短期）**：给鉴权查询加索引、优化 SQL；排查缓存穿透（大量未授权用户反复查库），接入布隆过滤器。
|
||
> 4. **加固（长期预防）**：强制超时（所有鉴权查询必须有 `context.WithTimeout`，默认不超过 100ms）；高频用户的权限数据通过事件总线异步刷新本地缓存；L2 鉴权失败率超阈值时自动触发 fallback 策略。
|
||
|
||
---
|
||
|
||
### 推荐阅读方向
|
||
|
||
- [[JWT与OAuth2对比]] — JWT 与 OAuth2 在不同场景下的选型
|
||
- [[RBAC权限模型实战]] — 从 RBAC 到 ABAC 的演进路径
|
||
- [[service-mesh实战]] — Service Mesh 中的 mTLS 配置详解
|
||
|
||
## 关联笔记
|
||
|
||
- [[hzh/MS/02-服务治理]] — 服务治理总览
|