331 lines
12 KiB
Markdown
331 lines
12 KiB
Markdown
---
|
||
tags: [microservice, security, mTLS, JWT, OAuth2, zero-trust]
|
||
create time: 2026-05-05 10:00
|
||
---
|
||
|
||
# 安全机制
|
||
|
||
## 概述
|
||
|
||
微服务架构下，服务间通信的安全保障比单体应用复杂得多。每个服务的 API 都是潜在的攻击面，需要多层防御。
|
||
|
||
```mermaid
|
||
graph TB
|
||
subgraph "纵深防御体系"
|
||
L1["网络隔离<br/>VPC / 安全组"]
|
||
L2["传输加密<br/>mTLS / TLS"]
|
||
L3["身份认证<br/>JWT / SPIFFE"]
|
||
L4["授权控制<br/>RBAC / ABAC"]
|
||
L5["审计追踪<br/>操作日志"]
|
||
end
|
||
|
||
L1 -.-> L2 -.-> L3 -.-> L4 -.-> L5
|
||
```
|
||
|
||
> [!tip] Zero Trust 原则
|
||
> **永不信任，始终验证**。无论请求来自内网还是外网，每个服务调用都要经过认证和授权。传统"内网即安全"的假设是微服务安全的最大盲区——一旦某个服务被攻破，攻击者可以横向移动到其他服务。
|
||
|
||
## 服务间认证
|
||
|
||
### mTLS (双向 TLS)
|
||
|
||
mTLS 是零信任架构的基石——建立加密通道前，双方必须互相验证证书身份。
|
||
|
||
```mermaid
|
||
sequenceDiagram
|
||
participant C as 调用方 Service
|
||
participant CA as CA / SPIFFE
|
||
participant S as 被调方 Service
|
||
|
||
C->>CA: 申请证书 (SPIFFE ID)
|
||
S->>CA: 申请证书 (SPIFFE ID)
|
||
CA-->>C: 签发客户端证书
|
||
CA-->>S: 签发服务端证书
|
||
|
||
C->>S: ClientHello + ClientCert
|
||
S->>S: 验证书链 + SPIFFE ID
|
||
alt 验证通过
|
||
S-->>C: ServerHello + ServerCert
|
||
note over C,S: 建立加密通道
|
||
else 验证失败
|
||
S->>C: TLS Alert (handshake failure)
|
||
end
|
||
```
|
||
|
||
> [!question] 思考
|
||
> 为什么内网服务间通信也需要加密？如果攻击者已经进入了内网网络，明文 gRPC 调用会发生什么？
|
||
|
||
> [!answer] 答案
|
||
> 传统安全模型假设"内网即安全"，但这个前提是整个内网都不可入侵——这在实际中几乎不成立。以下场景说明为什么内网也必须加密：
|
||
>
|
||
> **1. 攻击者进入内网的途径很多**
|
||
> - 某个前端服务存在远程代码执行漏洞 → 获得容器权限 → 嗅探同 VPC 其他 Pod 流量
|
||
> - 开发者电脑中毒 / CI/CD 供应链被投毒 → 从合法节点发起内网横向访问
|
||
> - 第三方插件或依赖库被植恶意代码 → 在构建产物中留下后门
|
||
>
|
||
> **2. 明文 gRPC 被窃听后的具体后果**
|
||
>
|
||
> | 攻击方式 | 可获取的内容 | 影响 |
|
||
> |---------|------------|------|
|
||
> | **流量嗅探** | 全部请求/响应体、gRPC metadata | 用户隐私数据、业务逻辑泄露 |
|
||
> | **Metadata 劫持** | JWT Token、追踪 ID、认证头 | 直接伪造身份调用下游服务 |
|
||
> | **中间人篡改** | 修改请求参数、响应 payload | 注入脏数据、绕过业务校验 |
|
||
>
|
||
> ```mermaid
|
||
> graph LR
|
||
> A["A: order-service<br/>(发送请求)"] -->|"明文 gRPC"| D["D: attacker<br/>（嗅探 + 注入）"]
|
||
> A --> B["交换机 / router"]
|
||
> B --> C["C: payment-service<br/>(接收请求)"]
|
||
> D -.->|"伪造成 order-service"| C
|
||
>
|
||
> style D fill:#f99,stroke:#c00
|
||
> ```
|
||
>
|
||
> **关键理解**：即使没有"主动攻击"能力，仅靠二层/三层抓包（ARP spoofing、镜像端口、VLAN hop），攻击者就能完整回放 orca 一个 gRPC stream——包括其中传递的 JWT token、数据库查询条件等敏感信息。
|
||
>
|
||
> **结论**：mTLS 不是"防外部黑客"的，而是让内网中的**任何一个被攻破的点**都无法读取其他服务的流量。这就是 Zero Trust 的核心思想。
|
||
|
||
**mTLS 的核心优势**：
|
||
- 双向证书验证，防止中间人攻击和非法服务接入
|
||
- 证书自动轮换（配合 Istio / Cert-Manager 等服务网格方案）
|
||
- 零代码侵入——Sidecar 代理处理握手，业务代码无需关心
|
||
|
||
**生产落地要点**：
|
||
|
||
| 要素 | 推荐方案 | 说明 |
|
||
|------|---------|------|
|
||
| **CA 体系** | SPIFFE / Istio CA | 基于 SPIFFE ID 自动签发短生命周期证书 |
|
||
| **证书管理** | cert-manager + Vault | K8s 场景下自动续期，避免人工干预 |
|
||
| **降级策略** | Peer Authentication MESH_STRICT | Istio 中设置为 STRICT 可强制所有流量走 mTLS |
|
||
|
||
```yaml
|
||
# Istio PeerAuthentication 示例
|
||
apiVersion: security.istio.io/v1beta1
|
||
kind: PeerAuthentication
|
||
metadata:
|
||
name: default
|
||
namespace: prod
|
||
spec:
|
||
mtls:
|
||
mode: STRICT # 拒绝明文连接
|
||
```
|
||
|
||
### JWT / Service Token
|
||
|
||
适用于不具备 mTLS 基础设施的场景，或作为跨边界调用的身份传递载体：
|
||
|
||
```go
|
||
// 生成 Service Token（短生命周期，≤ 1h）
|
||
token := jwt.NewWithClaims(jwt.SigningMethodHS256, jwt.MapClaims{
|
||
"sub": "order-service", // 调用方服务标识
|
||
"iss": "auth-server", // 签发者
|
||
"aud": "payment-service", // 目标服务
|
||
"exp": time.Now().Add(1 * time.Hour).Unix(),
|
||
"iat": time.Now().Unix(),
|
||
"jti": uuid.New().String(), // 唯一 ID，防重放
|
||
})
|
||
tokenString, _ := token.SignedString(secretKey)
|
||
```
|
||
|
||
| 方案 | 安全性 | 复杂度 | 适用场景 |
|
||
|------|--------|--------|---------|
|
||
| **mTLS** | ⭐⭐⭐⭐⭐ | 中（需 PKI 基础设施） | 服务网格环境、K8s 内部通信 |
|
||
| **JWT + Shared Secret** | ⭐⭐⭐⭐ | 低 | 中小规模、快速上手 |
|
||
| **mTLS + JWT** | ⭐⭐⭐⭐⭐ | 中高 | 金融级安全要求 |
|
||
|
||
> [!tip] 最佳实践
|
||
> 在生产环境中，推荐 **mTLS + JWT 双层防护**：mTLS 保证通道安全，JWT 传递调用方的身份信息（谁在调用）。仅用 JWT 而不加密通道的做法，一旦 TLS 被绕开（如配置错误），所有凭据将暴露于明文。
|
||
|
||
## API 鉴权模型
|
||
|
||
### RBAC (基于角色的访问控制)
|
||
|
||
```mermaid
|
||
flowchart LR
|
||
User["用户"] -->|"拥有"| Role["角色"]
|
||
Role -->|"拥有"| Permission["权限"]
|
||
Permission -->|"访问"| Resource["资源"]
|
||
|
||
Admin["Admin"] --> ReadWrite
|
||
Editor["Editor"] --> ReadWrite
|
||
Viewer["Viewer"] --> ReadOnly
|
||
|
||
ReadWrite --> OrderCRUD
|
||
ReadOnly --> OrderRead
|
||
|
||
OrderCRUD --> CRUD["Create/Read/Update/Delete"]
|
||
OrderRead --> Read["Read Only"]
|
||
```
|
||
|
||
### ABAC (基于属性的访问控制)
|
||
|
||
当权限决策需要依赖多维属性（部门、地域、时间、资源类型）时，ABAC 是更自然的选择：
|
||
|
||
```go
|
||
type User struct {
|
||
ID string
|
||
Role string
|
||
Department string
|
||
Level int // 职级
|
||
}
|
||
|
||
type Resource struct {
|
||
ID string
|
||
OwnerID string
|
||
Department string
|
||
Sensitivity int // 1-4, 敏感度等级
|
||
}
|
||
|
||
// 策略即代码：灵活定义访问规则
|
||
func canAccess(user User, resource Resource, action string) bool {
|
||
rules := []Rule{
|
||
// 同部门员工可读本部门文档
|
||
{Condition: user.Department == resource.Department && user.Level >= resource.Sensitivity, Action: "read"},
|
||
// 管理员或资源所有者可写
|
||
{Condition: user.Role == "admin" || user.ID == resource.OwnerID, Action: "write"},
|
||
}
|
||
|
||
for _, r := range rules {
|
||
if r.Condition && r.Action == action {
|
||
return true
|
||
}
|
||
}
|
||
return false
|
||
}
|
||
```
|
||
|
||
> [!tip] RBAC vs ABAC 选型指南
|
||
> | 维度 | RBAC | ABAC |
|
||
> |------|------|------|
|
||
> | **适用规模** | 中小团队，角色边界清晰 | 大型组织，权限维度复杂 |
|
||
> | **管理方式** | 预定义角色 + 分配 | 编写动态策略规则 |
|
||
> | **扩展性** | 新增场景 → 新增角色 → 组合爆炸 | 新增场景 → 新增规则，不影响现有 |
|
||
> | **落地成本** | 低（JWT claims 中直接携带 role） | 中（需策略引擎，如 OPA / Casbin） |
|
||
>
|
||
> 实际项目中常采用 **RBAC 为主，ABAC 补充关键资源**的混合模式。
|
||
|
||
## 输入校验与防攻击
|
||
|
||
微服务架构中，输入校验是最后一道防线。无论上游做了什么，每个服务都应独立校验进入边界的输入数据。
|
||
|
||
> [!question] 如果网关已经做了鉴权和限流，下游服务还需要校验输入吗？
|
||
> **必须校验**。网关只负责基础设施级别的防护（认证、限流），业务层面的合法性（如字段格式、长度、枚举值）应由各服务自行把关。
|
||
|
||
### SQL 注入防护
|
||
|
||
```go
|
||
// ❌ 危险：字符串拼接
|
||
query := fmt.Sprintf("SELECT * FROM users WHERE name = '%s'", userInput)
|
||
|
||
// ✅ 安全：参数化查询
|
||
rows, err := db.Query("SELECT * FROM users WHERE name = ?", userInput)
|
||
```
|
||
|
||
### XSS 与 CSP 头
|
||
|
||
```go
|
||
// Go HTML template 自动转义
|
||
tpl.ExecuteTemplate(w, "page.html", data) // {{.Name}} 自动 HTML 转义
|
||
|
||
// JSON API 天然免疫（Content-Type: application/json）
|
||
|
||
// 强制浏览器遵守 CSP 策略
|
||
w.Header().Set("Content-Security-Policy", "default-src 'self'")
|
||
```
|
||
|
||
### 常见攻击防护清单
|
||
|
||
| 威胁 | 防护手段 | 实现位置 |
|
||
|------|---------|---------|
|
||
| **SQL 注入** | 参数化查询 / ORM | 数据访问层 |
|
||
| **XSS** | 输出转义 / CSP Header | Web 框架 / Gateway |
|
||
| **CSRF** | SameSite Cookie / CSRF Token | 网关 / Session |
|
||
| **DDoS** | 限流 + WAF | API Gateway |
|
||
| **重放攻击** | Nonce + Timestamp | API 签名中间件 |
|
||
| **凭证泄露** | HTTPS + Secure Cookie | 传输层 |
|
||
|
||
## API 签名（防重放攻击）
|
||
|
||
对高安全要求的 API（如支付、转账），客户端需要对请求做 HMAC 签名，服务端验证签名的完整性：
|
||
|
||
```mermaid
|
||
sequenceDiagram
|
||
participant C as 客户端
|
||
participant S as 服务端
|
||
|
||
C->>C: 构造请求体 + timestamp + nonce
|
||
C->>C: Signature = HMAC(Secret, Method+URL+TS+Body)
|
||
C->>S: GET /api/pay?ts=...&nonce=...&sig=...
|
||
|
||
S->>S: 1. 检查 timestamp 是否过期
|
||
alt 已过期
|
||
S-->>C: 401 Request Expired
|
||
else 未过期
|
||
S->>S: 2. 检查 nonce 是否已使用
|
||
alt nonce 已存在
|
||
S-->>C: 409 Replay Detected
|
||
else 新 nonce
|
||
S->>S: 3. 重新计算签名并比对
|
||
alt 一致
|
||
S-->>C: 200 OK
|
||
else 不一致
|
||
S-->>C: 403 Invalid Signature
|
||
end
|
||
end
|
||
end
|
||
```
|
||
|
||
### Go 实现示例
|
||
|
||
```go
|
||
// 客户端：生成签名
|
||
func signRequest(secret string, method, url, body string, ts int64, nonce string) string {
|
||
payload := fmt.Sprintf("%s|%s|%d|%s|%s", method, url, ts, nonce, body)
|
||
mac := hmac.New(sha256.New, []byte(secret))
|
||
mac.Write([]byte(payload))
|
||
return base64.StdEncoding.EncodeToString(mac.Sum(nil))
|
||
}
|
||
|
||
// 服务端：签名验证中间件
|
||
func verifySignature(secret string) middleware.Handler {
|
||
return func(next http.HandlerFunc) http.HandlerFunc {
|
||
return func(w http.ResponseWriter, r *http.Request) {
|
||
ts := getParam(r, "timestamp")
|
||
nonce := getParam(r, "nonce")
|
||
sig := getParam(r, "signature")
|
||
|
||
// 1. 时间窗口校验 (±5 min)
|
||
if time.Since(time.Unix(ts, 0)).Abs() > 5*time.Minute {
|
||
http.Error(w, "request expired", http.StatusUnauthorized)
|
||
return
|
||
}
|
||
|
||
// 2. Nonce 去重 (Redis SETNX, TTL=300s)
|
||
key := fmt.Sprintf("nonce:%s", nonce)
|
||
if !redis.SetNX(key, "1", 300*time.Second) {
|
||
http.Error(w, "replay detected", http.StatusConflict)
|
||
return
|
||
}
|
||
|
||
// 3. 签名比对
|
||
expected := signRequest(secret, r.Method, r.URL.String(), r.Body, ts, nonce)
|
||
if !hmac.Equal([]byte(sig), []byte(expected)) {
|
||
http.Error(w, "invalid signature", http.StatusForbidden)
|
||
}
|
||
next(w, r)
|
||
}
|
||
}
|
||
}
|
||
```
|
||
|
||
> [!note] Nonce 设计要点
|
||
> - 每次请求必须携带唯一的 `nonce`（随机字符串或递增序号）
|
||
> - 服务端用 Redis `SETNX` 记录已使用的 nonce，TTL 略大于时间窗口（如 300s）
|
||
> - 对于高频调用场景，可考虑基于布隆过滤器优化存储空间
|
||
|
||
## 关联笔记
|
||
|
||
- [[02-服务治理/01-API网关]] — 网关层的统一鉴权和限流
|
||
- [[02-服务治理/04-服务发现]] — 服务注册时也需要安全认证
|
||
- [[hzh/MS/API 设计原则]] — API 设计中的安全考量
|