鑰匙和令牌的輪換
1）為什麼需要輪換
密鑰和令牌不可避免地「老化」：博客/備用中的曝光，內幕風險，圖書館漏洞，合作夥伴泄漏。輪換可降低「風險壽命」，並在事件中提供可管理性。目標是建立可預測的輪換周期和快速召回機制，而無需停機。
2）領域： 我們輪換什麼
簽名/加密密鑰：JWT（JWS/JWE），OAuth/OIDC，SAML，webhooks（HMAC），許可證。
集成的秘密：API密鑰,客戶機秘密,密碼技術.用戶。
TLS/mTLS：服務器/客戶端證書、根/中間CA。
數據密鑰：KMS/HSM，DEK（envelope加密）中的KEK/CMK。
Токены: access/refresh, service-to-service (mTLS, HMAC), short-lived session.
3）存儲、版本、標簽
KMS/HSM/Vault作為真相的來源。禁止將私有密鑰存儲在git/ENV/映像文件中。
轉化：「key_id」/「version」+標簽：「purpose=jwt-sign」，「env=prod」，「alg=ES 256」，「created_at」，「rotates_at」。
訪問策略：基本權利原則（least privilege）、責任分工（SoD）。
審計：誰創建/閱讀/簽署；不變期刊。
4）基本輪換模式
4.1重叠窗口（graceful rollover）
新密鑰→發布到JWKS/我們分發證書。
重疊窗口：驗證新舊密鑰,簽名僅為新密鑰。
寬限期到期後-我們從可信集中刪除舊集。
4.2雙重發行（雙重運行）
在較短的時間內，當一些實例簽名舊實例時，有些是新實例的（對於大副本）。
需要嚴格同步的JWKS並通過「kid」監控驗證比例。
4.3 Rotate-on-schedule vs rotate-on-use
按計劃：每N天/周一次（簽名密鑰,TLS）。
如果使用：refresh令牌-一次性，每次交換都會發布新的（「滾動」輪換）。
5）JWT/JWKS： 實踐
5.1標題和ID
在JWS標頭中使用「kid」選擇驗證密鑰。
最小克萊姆，短的「exp」，正確的「aud/iss/nbf」。
json
{ "alg": "ES256", "kid": "jwt-2025-10", "typ": "JWT" }5.2 JWKS出版
JWKS必須包含所有活動驗證鍵（舊的+新的grace窗口）。
客戶端JWKS緩存：短TTL（例如5-15分鐘）。
當受到損害時-從JWKS（突然）中刪除受損密鑰,即高速緩存強制失效。
json
{
"keys": [
{ "kty":"EC","crv":"P-256","kid":"jwt-2025-10","use":"sig","alg":"ES256","x":"...","y":"..." },
{ "kty":"EC","crv":"P-256","kid":"jwt-2025-07","use":"sig","alg":"ES256","x":"...","y":"..." }
]
}5.3 Cadens和時間表
JWT簽名：每3-6個月輪換一個鑰匙（或更常見的是高風險）。
「exp」訪問令牌：5-30分鐘；refresh-7-30天（帶有「rotate-on-use」）。
強制使用PoP/DPoP「粘合」（請參閱§8）以降低劫持風險。
6）HMAC輪換（webhooks/簽名）
保持活躍和金絲雀的秘密；接受兩個簽名。
標題：「X-Signature」+「X-Timestamp」；窗口限制± 300秒。
完全關閉舊的-發件人確認切換後。
對於合作夥伴：發布切換日期時間和endpoint驗證。
7） TLS/mTLS和信任鏈
用於公共服務器證書（Let's Encrypt或企業CA）的ACME/自動更新。
mTLS：短客戶端證書（7-30天）,自動鏈路輪換（SPIFFE/SPIRE/mesh）。
中間/根CA的旋轉僅通過重疊的信任錨點（信托纏結）和長金絲雀。
註意OCSP/CRL和clock-skew。在邏輯中-驗證失敗的原因。
8）PoP/DPoP和客戶token↔klyuch捆綁包
DPoP（上市證明的演示）：令牌與客戶的公共密鑰綁定；降低了replay的風險。
客戶密鑰輪換=在短時間內發布新DPoP密鑰,令牌。
對於服務，首選的mTLS（設備/操作員「攜帶」HSM/TPM中的密鑰）。
9） Refresh-tokens： rotate-on-use
一次性refresh令牌：每次交換→新的refresh+access。
帶有TTL的「jti」/「sid」存儲列表=refresh壽命。
重用細節（re-play）：立即召回會議/設備,alert。
10）召回和鎖定列表
JWT不帶內窺鏡：使用短的「exp」+「黑名單」「jti」來處理關鍵案件（本地/在Redis中，散列哈希）。
OAuth進入：集中狀態服務器；使用短TTL緩存「active=false/true」。
API密鑰：存儲密鑰哈希（作為密碼）,所有者/特南特標簽,scope,創建/最後訪問日期；立即召回。
11）數據密鑰： envelope加密
CMK/KEK（KMS/HSM）保護DEK；CMK輪換發生時無需重新繪制數據：pere-wrap DEK。
每個對象/tenant/party的DEK；KDF/HKDF用於衍生密鑰。
銷毀策略（crypto-shredding）：刪除KEK=破壞時的數據不可讀性。
12）事件程序（損害）
1.凍結：禁用受損密鑰上的令牌發布，將發行轉換為新發行。
2.召回：從JWKS中刪除「kid」，召回證書（OCSP/CRL），鎖定列表中的API密鑰。
3.減少TTL：暫時減少「exp」代幣，加強PoP/DPoP驗證。
4.強制登錄：禁用會議（revoke'sid'/'jti'）。
5.Forenzics和報告：時間線，覆蓋範圍，受影響的人/什麼；更新花花公子。
13）管道和滾動
13.1生成和出版
在HSM/KMS中生成密鑰；私鑰出口-禁止。
通過驗證和測試自動發布JWKS/證書。
金絲雀發行：1-5%的客戶→ 100%。
13.2健康控制
度量：「kid」驗證比例，簽名/證書錯誤，時鐘漂移。
Alerta：由於簽名而激增401/403, OCSP/CRL不可用,證書到期（T-30/T-7/T-1）。
14）Configi和示例
14.1 Vault/KMS（偽）策略示例)
hcl path "transit/keys/jwt-prod" {
capabilities = ["read," "update," "list"] # signature/rotation
}
path "transit/keys/jwt-prod/rotate" {
capabilities = ["update"]
}14.2 JWT輪換計劃示例
T0: create a new version of the key (kid = jwt-2025-10), add to JWKS
T0 + 15m: start signing with a new kid; validate with old and new
T0 + 7d: remove old kid from JWKS
T0 + 30d: delete old private key from KMS (schedule purge)14.3 Envoy：強制更新JWKS（偽）
yaml jwt_authn:
providers:
oidc:
issuer: https://auth. example. com/
remote_jwks:
http_uri:
uri: https://auth. example. com/.well-known/jwks. json cluster: jwks_cluster timeout: 2s cache_duration: 300s # короткий TTL15）可觀察性和審計
Метрики: `jwt_verify_fail_total{reason}`, `jwks_refresh_total`, `jwks_kid_share{kid}`, `token_revoked_total`, `refresh_rotations_total`, `dpop_fail_total`.
Логи: `kid`, `jti`, `sid`, `reason`, `client_id`, `tenant`, `trace_id` (без PII).
Dashbords：按地區劃分的「kid」份額卡，過期證書，召回頻率，非有效簽名。
16）反模式
長壽的JWT沒有召回，也沒有短暫的「exp」。
缺少「kid」和「手動」檢查密鑰。
在沒有KMS的ENV/k8s-Secret中存儲秘密，並且在etcd級別不加密。
非旋轉的refresh代幣；重復使用refresh而不使用檢測器。
單個全局API鍵「全部」。
「安靜」發布新密鑰而不發布JWKS和監控。
零重疊窗口（即時更換）→質量為401/403。
17） iGaming/財務細節
監管和審計：不變的輪換/反饋邏輯；時間和行為者的可證明性。
Partnership PSP/KYC：每個合作夥伴/管轄區的獨立密鑰；在違反SLA/安全的情況下迅速召回。
多範圍：帶有scope的per-tenant API鍵；隔離品牌/區域密鑰。
高風險：關鍵操作的PoP/DPoP，內部服務之間的短「exp」，mTLS。
Backoffice：SSO/OIDC，短會話，硬件令牌（FIDO2），無處不在的按計劃旋轉。
18）準備就緒支票清單
- KMS/HSM/Vault中的所有私有密鑰；禁止出口。
- JWKS以短TTL發布並緩存；JWT標題中有「kid」。
- 重叠窗口和自動滾動輪換計劃。
- Refresh令牌是一次性的；TTL撤回的「jti」列表。
- HMAC秘密：主動+金絲雀；接待雙方；已宣布T切換時間。
- TLS/mTLS： auto-renew, Alert T-30/T-7/T-1, trust bundle for change CA。
- Envelope加密：KEK/CMK輪換而不停機,DEK 對象/tenant。
- 簽名/異同，JWKS，評論；dashbords 「kid」-dole。
- 事件花花公子（損害）和定期演習。
- 使用新密鑰/SA進行金絲雀和驗證中繼測試。
19) TL;DR
在KMS/HSM中保留密鑰,用「kid」簽名JWT,並發布JWKS。輪換密鑰和重疊證書，通過「kid」觀察驗證份額。Refresh-使用上的旋轉和短的「exp」；對於關鍵操作-PoP/DPoP和mTLS。對於數據,使用帶有KEK旋轉的envelope加密,無需停機。實施指標/Alerta、事件花花公子和定期的金絲雀輪換。