GH GambleHub

S2S認證

S2S身份驗證證明了該請求的確切服務/操作程序，並賦予其最低限度的有限時間權限。與用戶線程不同，這裏沒有人-因此憑據壽命短，密碼綁定到workload/canal以及清晰的可觀察性至關重要。

1）目標和原則

零信托（Zero Trust）默認值：不信任網絡,僅信任網絡認證和密碼。
短壽命的credenschlas：分鐘，不是天/月。
綁定到上下文：tenant/region/licence/audience/scopes。
集中發行，分散驗證：STS/IdP+本地驗證。
最小權限和顯式委派：只有必要的漏洞和審核。
「無痛」輪換：雙鍵/雙證書窗口和自動化。

2）威脅模型（最低）

竊取持久秘密（API-keys, long-lived RT）。
在VPC/群集中替換服務。
分段斷裂時的區域間攻擊。
將Replay/流量替換為代理。
供應鏈/替代容器映像。
配置錯誤（firewall/mesh廣義規則,全部JWKS通用）。

3）基本模式S2S

3.1 mTLS（共同證書）

你是誰：通過渠道證明。
來自內部PKI的證書壽命短（每小時）；發布/輪換由mesh/sidecar或SPIRE代理控制。
對一個信任域中的「鄰居」和令牌綁定有好處。

3.2服務JWT （STS）

你們是誰。
短訪問JWT（2-5分鐘）帶有「aud」，「scp」，「tenant」，「region」。
通過「kid」和「輪換」通過JWKS簽名KMS/HSM，公共密鑰。
本地驗證（沒有IdP網絡調用）。

3.3 SPIFFE/SPIRE (SVID)

Worcloads的通用身份：'spiffe ：//trust-domain/ns/< ns >/sa/< sa>'。
自動分解/旋轉X.509/JWT-SVID，與Istio/Linkerd集成。

3.4 OAuth 2.1 Client Credentials / Token Exchange (RFC 8693)

機器客戶從STS獲得令牌；要代表OBO （token exchange）操作。

組合：用於通道的mTLS,用於消息的JWT,用於持久身份的SPIFFE。

4）參考體系結構


[KMS/HSM]       [Policy Store / PDP]

[STS/IdP (issuer)] ── JWKS ──[Gateway/PEP] ─────[Services/PEP]
│
SVID/JWT │         │    │      │
(SPIRE/Istio)│      mTLS/DPoP  │    mTLS/DPoP
│         │    │      │
[Workload/Sidecar]─────────┴───────┴────────────┘

Issuer（STS/IdP）：發布短服務JWT/CVID，由JWKS發布。
網關（PEP）：網絡術語,驗證mTLS/JWT,豐富上下文,請求PDP。
服務（PEP）：重新驗證（depth defense）, PDP解決方案緩存。
SPIRE/mesh： mTLS的自動證書和SVID。

5）服務JWT格式（示例）

json
{
"iss": "https://sts. core",
"sub": "svc. catalog, "//service identity
"aud": ["svc. search"] ,//target service/domain
"exp": 1730390100, "iat": 1730389800,
"tenant": "brand_eu",
"region": "EE",
"scp": ["catalog:read:public","catalog:read:tenant"],
"mtls": { "bound": true, "spiffe": "spiffe://core/ns/prod/sa/catalog" }
}

簽名ES256/EdDSA，「kid」指定活動密鑰。
可選地binding到通道：標誌、hash cert、SVID。

6）引渡政策（STS）和驗證

引渡：
  • 主語取自SVID/客戶端證書/客戶端寄存器。
  • 2-5分鐘的壽命，沒有refresh-而是重新要求STS。
  • Scoopes/受眾來自 Policy Store（GitOps）而不是客戶請求。
驗證（PEP）：

1.檢查mTLS（可選）和鏈的有效性。

2.檢查JWKS上的JWT簽名（通過「kid」）。

3.核對「exp/nbf/iss/aud」, tenant/region/licence。

4.豐富上下文並詢問PDP （RBAC/ABAC/ReBAC）。

5.緩存PDP解決方案（TTL 30-120 c），事件障礙。

7）多重特南特和地區（信任領域）

共享信任域： 'spiffe： //eu。core`, `spiffe://latam.core`.

按地區劃分的JWKS/PKI；區域間-僅通過可信賴的網關。
包含在「tenant/region/licence」標簽中,並檢查資源合規性。
Logi/Audit按性別和地區劃分。

8）Mesh/sidecar和無混合模式

Istio/Linkerd： mTLS開箱即用，在L4/L7級別實施策略，與SPIRE集成。
沒有mesh：應用程序中的客戶端庫+mutual TLS；更難管理輪換-通過代理實現自動化。

9）鑰匙，JWKS和輪換

僅在KMS/HSM中使用私人密鑰；簽名-遠程呼叫/設備。
每N天旋轉一次；雙鍵：舊的+新被接受，issuer在加熱腰果後簽署新的。
監視：「kid」消費比例，「掛起」客戶在舊鑰匙。

示例配置（YAML）： 
yaml issuer:
jwks:
alg: ES256 rotation_days: 30 publish_cache_ttl: 60s sts:
access_ttl: 5m audience_policies:
- subject: "svc. catalog"
allow: ["svc. search","svc. wallet"]
scopes: ["catalog:read:"]
tenancy:
claims: ["tenant","region","licence"]
jwks_per_region: true

10）鏈接綁定（DPoP/mTLS-bound）

mTLS-bound tokens：在JWT中添加客戶端證書的hash；在接待處進行鉆探。
DPoP：對於沒有mTLS的HTTP客戶端-簽名每個DPoP密鑰請求,在AT中放置DPoP圖標。

11）錯誤和退貨政策

標準化代碼：
  • `401 INVALID_TOKEN`/`EXPIRED_TOKEN`/`AUD_MISMATCH`.
  • `401 MTLS_REQUIRED`/`MTLS_CERT_INVALID`.
  • `403 INSUFFICIENT_SCOPE`/`POLICY_DENY`.
  • `429 RATE_LIMITED`.

響應包含可讀機器的「error_code」和「as_of」（密鑰/策略版本）。

12）可觀察性和審計

度量標準：
  • `s2s_auth_p95_ms`, `verify_jwt_p95_ms`, `jwks_skew_ms`,
  • `invalid_token_rate`, `aud_mismatch_rate`, `insufficient_scope_rate`,
  • 以「kid」為單位的消費，占請求的mTLS排序比例。
Logi/Traces：
  • `subject`, `aud`, `tenant`, `region`, `scp`, `kid`, `sid/svid`, `decision`, `policy_version`, `trace_id`.
審計（不變）：
  • 簽發令牌，輪換密鑰，更改策略，拒絕請求。

13）生產力

JWT驗證是本地的，JWKS緩存（TTL 30-60 s）具有後臺更新。
X.509鏈是定位CA和OCSP/CRL緩存。
在gateway/sidecar上提供昂貴的驗證I/O。
使用prefetch令牌/證書（10-20從到期前）。

14）測試

合同/interop：不同的YAP/庫，clock skew ± 300 s。
Negative：過期/假令牌，不正確的「aud」，錯誤的區域/tenant，破碎的證書鏈。
混亂：突然旋轉「kid」，JWKS不可用，大量外賣，mTLS懸崖。
下載：STS的發行高峰，網關上的驗證激增。
E2E：mTLS only，JWT only，組合模式，令牌交換（OBO）。

15）花花公子（runbooks）

1.簽名密鑰的損害

立即恢復「kid」，發布新的，縮短的TTL令牌，審計，搜索「掛起」的客戶，強制拒絕舊的「kid」。

2.大眾「INVALID_TOKEN」

檢查JWKS-KESH, RASHINHRON,令牌起源（TTL太短）,暫時擴大skew公差,加熱JWKS。

3.mTLS故障

檢查CA鏈，SVID時機，主機時間；通過SPIRE/Istio的緊急重新發布，僅在區域內啟用後退路由。

4.成長'AUD_MISMATCH'

視聽策略漂移：將STS策略與實際呼叫進行比較,臨時添加所需的「aud」並安排調用體系結構的調整。

5.STS不可用/放慢速度

增加已經簽發的令牌（grace）的TTL,包括以前的prefetch/refresh, scale-out STS。

16）典型錯誤

env/代碼中長壽命的 API密鑰/秘密。
通用JWKS/PKI「適用於所有地區和所有時間」。
缺少binding （mTLS/DPoP） →令牌很容易被帶走。
缺省情況下為「aud=」和「admin」 scopes。
無雙鍵周期輪換→質量401。
僅在gateway上檢查令牌（在深處沒有防禦）。
「沈默」拒絕（不是「error_code」和「reason」）-難以借鑒和訓練團隊。

17）迷你配置模板

PEP（網關）-規則： 
yaml auth:
require_mtls: true jwks:
url: https://sts. core/.well-known/jwks. json cache_ttl: 60s claims:
required: ["iss","sub","aud","exp","tenant","region"]
tenant_in_header: "x-tenant"
pdp:
endpoint: "opa:8181/v1/data/policy/allow"
decision_cache_ttl: 60s
STS策略（片段）： 
yaml subjects:
- id: "svc. catalog"
spiffe: "spiffe://core/ns/prod/sa/catalog"
audiences: ["svc. search","svc. wallet"]
scopes: ["catalog:read:"]
ttl: "5m"

18）售前支票清單

  • 短服務JWT（≤5分鐘），本地驗證，JWKS緩存。
  • mTLS（或DPoP）已啟用；優先是mTLS-bound tokens。
  • SPIFFE/SPIRE或等效於自動簽發/輪換證書。
  • 具有audience/scope策略的STS；僅以可信身份進行發行。
  • 按地區劃分信任領域和JWKS；tenant/region/licence標記已驗證。
  • PDP/PEP集成,解決方案緩存+事件障礙。
  • 雙鍵窗口，監視「kid」消費，Alerta on invalid/aud mismatch。
  • 完整的S2S記錄/審核,包括性能/錯誤指標。
  • 花花公子對鑰匙的損害，STS的下降，mTLS的失敗。
  • contract/negative/chaos/load/E2E測試集已通過。

結論

S2S身份驗證是信道信任（mTLS），消息信任（JWT短）和持續的workload身份（SPIFFE）的組合，由集中式STS管理並在本地驗證。添加信任域分離、嚴格的聽力/範圍、自動旋轉和可觀察性-並獲得一個可靠、可解釋和擴展的輪廓以及平臺及其地理位置。

Contact

與我們聯繫

如有任何問題或支援需求，歡迎隨時聯絡我們。我們隨時樂意提供協助！

Telegram
@Gamble_GC
開始整合

Email 為 必填。Telegram 或 WhatsApp 為 選填。

您的姓名 選填
Email 選填
主旨 選填
訊息內容 選填
Telegram 選填
@
若您填寫 Telegram，我們將在 Email 之外，同步於 Telegram 回覆您。
WhatsApp 選填
格式：國碼 + 電話號碼（例如：+886XXXXXXXXX）。

按下此按鈕即表示您同意我們處理您的資料。