Logo GH

キーとトークンの回転

1）なぜ回転が必要なのか

キーとトークンは必然的に「年齢」：ログ/バックアップの露出、インサイダーリスク、ライブラリの脆弱性、パートナーからのリーク。ローテーションは「リスク寿命」を短縮し、インシデントの制御性を提供します。目標は、ダウンタイムなしで予測可能な回転サイクルと迅速なリコール機構を構築することです。

2）区域： 私達が丁度回るもの

署名/暗号化キー：JWT （JWS/JWE）、 OAuth/OIDC、 SAML、 Webhook （HMAC）、ライセンス。
統合の秘密：APIキー、クライアントの秘密、技術的なパスワード。ユーザー。
TLS/mTLS：サーバ/クライアント証明書、ルート/中間CA。
データキー：KMS/HSMのKEK/CMK、 DEK（エンベロープ暗号化）。
アクセス/リフレッシュ、サービス・ツー・サービス（mTLS、 HMAC）、短命のセッション。

3）ストレージ、バージョン、ラベル

真実の源としてのKMS/HSM/Vault。git/ENV/imageファイルに秘密鍵を格納することは禁止されています。
バージョン管理：'key_id'/'version'+labels： 'purpose=jwt-sign'、 'env=prod'、 'alg=ES256'、 'created_at'、 'rotates_at'。
アクセスポリシー：最低限の必要な権利（少なくとも特権）の原則、職務の分離（SoD）。
監査：誰が作成/読み取り/署名しましたか。不変のログ。

4）基本的な回転パターン

4.1重なり合う窓（優雅なロールオーバー）

新しいキー→をJWKSで公開し、証明書を配布します。
オーバーラップウィンドウ：古いキーと新しいキーの検証、署名-新しいキーのみ。
猶予期間が終了したら、信頼されたセットから古いものを削除します。

4.2デュアルラン

インスタンスの一部が古い、部分-新しい（大規模な艦隊のために）署名する短い期間。
厳密に同期されたJWKSと'kid'による検証の割合の監視が必要です。

4.3 Rotate-on-schedule対Rotate-on-use

スケジュール：N日/週に一度（署名キー、TLS）。
使用する場合：トークンをリフレッシュ-1回限り、各取引所で新規リリース（「スライド」回転）。

5） JWT/JWKS： 練習

5.1見出しと識別子

JWSヘッダーの「kid」を使用して検証キーを選択します。
最小登山、短い'exp'、正しい'aud/iss/nbf'。

JWSヘッダの例： 
json
{ "alg": "ES256", "kid": "jwt-2025-10", "typ": "JWT" }

5.2 JWKS出版

JWKSには、すべてのアクティブバリデーションキーが含まれている必要があります。
クライアントJWKSキャッシュ：短いTTL（例：5-15分）。
侵害された場合は、JWKSから侵害されたキーを削除します（突然）、キャッシュの強制障害。

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ケイデンスとタイミング

JWT署名：3〜6ヶ月ごとにキー回転（または高リスクの場合はそれ以上）。
'exp'アクセストークン：5-30分；更新-7-30日（「rotate-on-use」と）。
PoP/DPoP（第8章を参照）との強制的な「結合」により、盗難リスクを低減します。

6） HMACの回転（webhooks/署名）

アクティブでカナリアの秘密を保つ。両方からの署名を受け入れる。
タイトル：'X-Signature'+'X-Timestamp'；窓の制限± 30sです。
送信者が確認した後-古いものの完全な切断。
パートナーの場合は、スイッチの日付とエンドポイントチェックを公開します。

7） TLS/mTLSおよびトラストチェーン

公開サーバ証明書のACME/自動更新（Let's Encrypt or Enterprise CA）。
mTLS：短い顧客の証明書（7-30日）、チャネル（SPIFFE/SPIRE/mesh）による自動回転。
中間/ルートCA回転-重複するトラストバンドルアンカーと長いカナリアを介してのみ。
OCSP/CRLとclock-skewに注目してください。ログに-検証に失敗した理由。

8） PoP/DPoPおよびクライアントtoken↔klyuchバンドル

DPoP（所有証明のデモンストレーション）：トークンはクライアントの公開鍵にバインドされます。再生のリスクを低減します。
クライアントキーの回転=新しいDPoPキーのリリース、トークン-短時間。
サービス・ツー・サービスでは、mTLSが優先されます（デバイス/ワーカーはHSM/TPMのキーを「運ぶ」）。

9）トークンを更新して下さい： 使用上の回転

1回限りのリフレッシュトークン：各取引所→新しいリフレッシュ+アクセス。
リコールされた'jti'/'sid'ストアのリストとTTL=lifetime refresh。
再使用検出（再プレイ）：即時セッション/デバイスのリコール、アラート。

10）リコールとブロックリスト

イントロスペクションなしのJWT：重要なケース（ローカル/Redisではハッシュシャーディング）には、短い'exp'+'ブラックリスト'jti'を使用します。
OAuthイントロスペクション：中央集中型ステータスサーバーキャッシュ「active=false/true」と短いTTL。
APIキー：キーハッシュ（パスワードなど）、所有者/テナントラベル、スコープ、作成/最後のアクセス日を保存します。リコール-インスタント。

11）データキー： エンベロープ暗号化

CMK/KEK （KMS/HSM）はDEKを保護します；CMK回転は、データの再ディスクロージャーなしで発生します。
各オブジェクト/テナント/パーティーのDEK；派生キーのKDF/HKDF。
暗号シュレッディングポリシー：KEKを削除する=危険にさらされたときに読めないデータ。

12）インシデント手続き（妥協）

1.凍結：侵害されたキーでトークン発行を無効にし、新しいキーに発行を転送します。
2.取り消し：JWKSから'kid'を削除し、証明書（OCSP/CRL）を取り消し、リストからAPIキーをブロックします。
3.TTLの削減：一時的に'exp'トークンを削減し、PoP/DPoPチェックを強化します。
4.強制ログアウト：セッションを無効にします（'sid'/'jti'を取り消します）。
5.フォレンジックとレポート：タイムライン、カバレッジ、誰/何が苦しんだか；プレイブックを更新します。

13）パイプラインおよびロールアウト

13.1生成と出版

HSM/KMSでキーを生成します。秘密鍵輸出-禁止されています。
JWKS/証明書の自動発行と検証とテスト。
カナリアリリース：クライアントの1-5％→100％。

13.2健康管理

メトリクス：'kid'による検証の割合、署名/証明書のエラー、クロックドリフト。
アラート：署名による401/403スパイク、OCSP/CRL利用不可、期限切れ証明書（T-30/T-7/T-1）。

14）構成と例

14.1 Vault/KMSポリシーの例（Pseudo）

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特使：強制的に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 # короткий TTL

15）可視性と監査

'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）。
ダッシュボード：「キッド」シェアカード、有効期限切れの証明書、周波数のリコール、地域別の無効な署名。

16） Antipatterns

リコールがなく、短い「経験」がない長寿JWT。
検証キーの「キッド」と「マニュアル」の選択がない。
KMSなしで、etcdレベルで暗号化なしでENV/k8s-Secretに秘密を格納します。
非回転リフレッシュトークン；検出せずにリフレッシュを再利用します。
単一のグローバルAPIキー「すべてのために」。
JWKSの公開とモニタリングのない新しいキーの「Quiet」リリース。
ゼロ重複ウィンドウ（即時交換）→質量401/403。

17） iGaming/Financeの詳細

レギュレータと監査：回転/リコールの不変のログ。時間と俳優の証明可能性。
パートナーPSP/KYC：パートナー/管轄ごとに個別のキー。SLA/安全違反の迅速なリコール。
マルチリース：スコープを持つテナントごとのAPIキー。ブランド/地域のキーの分離。
ハイリスク：重要な操作のためのPoP/DPoP、短い'exp'、内部サービス間のmTLS。
Backoffice： SSO/OIDC、ショートセッション、ハードウェアトークン（FIDO2）、ユビキタスローテートオンスケジュール。

18） Prod Readinessチェックリスト

  • KMS/HSM/Vaultのすべての秘密鍵。輸出禁止。
  • JWKSは公開され、短いTTLでキャッシュされます。JWTの見出しに「子供」があります。
  • ウィンドウと自動ロールアウトが重なった回転計画。
  • リフレッシュトークンは使い捨てです。TTLで取り消された'jti'のリスト。
  • HMAC秘密：アクティブ+カナリア；両方によるレセプション；Tスイッチ時間が宣言されました。
  • TLS/mTLS： CA変更の自動更新、T-30/T-7/T-1アラート、トラストバンドル。
  • エンベロープ暗号化：ダウンタイムなしで回転するKEK/CMK、オブジェクト/テナントごとのDEK。
  • 署名、JWKS、フィードバックによるメトリック/アラート；ダッシュボード'kid' -deals。
  • インシデントプレイブック（妥協）と通常のドリル。
  • 新しいキー/CAを使用したカナリアと検証レプリカのテスト。

19） TL；DR（ドクター）

KMS/HSMでキーを保持し、JWTに「子供」と署名し、JWKSを投稿します。キーと証明書をオーバーラップで回転させ、'kid'による検証共有を監視します。リフレッシュ-rotate-on-useとshort 'exp'；重要な操作-PoP/DPoPおよびmTLS。データの場合は、ダウンタイムなしでKEK回転でエンベロープ暗号化を使用します。メトリック/アラート、インシデントプレイブック、および通常のカナリア回転を実装します。

Contact

お問い合わせ

ご質問やサポートが必要な場合はお気軽にご連絡ください。いつでもお手伝いします！

Telegram
@Gamble_GC
統合を開始

Email は 必須。Telegram または WhatsApp は 任意。

お名前 任意
Email 任意
件名 任意
メッセージ 任意
Telegram 任意
@
Telegram を入力いただいた場合、Email に加えてそちらにもご連絡します。
WhatsApp 任意
形式：+国番号と電話番号（例：+81XXXXXXXXX）。

ボタンを押すことで、データ処理に同意したものとみなされます。