GH GambleHub

キー管理と回転

キーはプラットフォームの"信頼のルーツです。"信頼性の高い鍵管理システム（KMS/HSM+プロセス+テレメトリー）は、暗号を1回限りの統合から日常業務に変換します。キーは定期的に更新され、使用は透明で、妥協はローカライズされ、クライアントはダウンタイムなしで重要な変更を経験します。

1）目標と原則

暗号の俊敏性：大きな移行なしでアルゴリズム/キーの長さを変更する機能。
少なくとも露出：秘密鍵はKMS/HSMを残さない。署名/復号操作-削除されました。
短命のアーティファクト：トークン/セッションキーは数週間ではなく、数分〜数時間です。
デュアルキー/デュアルカートウィンドウ：フェイルセーフ回転。
地域とテナントの分離：キーは地域とテナントによって分割されます。
完全な可聴性：不変のトランザクションログ、HSMの資格、アクセス制御。

2）主な分類

ルートCA/マスターキー：非常にまれな使用、HSMに保持、中間キーまたはデータキーラッパーを解放するために使用。
操作：JWT/イベント署名、TLS、 webhook署名、構成暗号化/PII。
セッション/時間：DPoP、 mTLSバインディング、チャンネル/ダイアログ用ECDH出力。
統合：パートナーキー（公開）とHMACの秘密。
データキー（DEK）： KEKの下でエンベロープ暗号化を使用し、明示的に保存されません。

3）鍵の識別および使用法の方針

各キーには'kid'があります（キーはトークン/ヘッダーで識別されます）

yaml key:
kid: "eu-core-es256-2025-10"
alg: "ES256"         # или EdDSA, RSA-PSS, AES-GCM, XChaCha20-Poly1305 purpose: ["jwt-sign","webhook-sign"]
scope: ["tenant:brand_eu","region:EE"]
status: "active"       # active      next      retiring      revoked created_at: "2025-10-15T08:00:00Z"
valid_to:  "2026-01-15T08:00:00Z"

ルール：「1つの目標-1つのキー」（最小共有）、アプリケーションとタイミングの明示的な領域。

4）主なライフサイクル（KMS/HSM）

1.生成：HSM/KMSで、export policy=deniedを指定します。
2.Publish：非対称性のために-JWKS/certificate with 'kid'。
3.使用：制御されたIAMでリモート操作（署名/復号）。
4.Rotate： 'next'キーを実行し、dual-acceptを有効にします。
5.Retire：古いものを'retiring'に変換してから'revoked'に変換します。
6.Destroy：紛争ウィンドウの後に素材（パージプロトコル付き）を破棄します。

5）回転： 戦略

スケジュール：カレンダー（例えば、JWT署名の場合は1-3ヶ月ごと、TLS-sertsの場合は6-12ヶ月）。
ローリング：徐々に消費者を切り替える（JWKSはすでに新しいキーを含んでいます；エミッタはキャッシュをウォームアップした後に新しい署名を開始します）。
強制（セキュリティ）：妥協時の即時回転。短い二重受け入れの窓、アーティファクトの積極的な有効期限。
地域/テナントごとにずれた：同時に全世界を「拍手」しないように。

黄金の規則：最初に出版物、それから署名は新しいです、そして期限切れの後にだけ-古いもののリコール。

6）デュアルキーウィンドウ

JWKSを新旧の「子供」と一緒に出版しています。
Verifiersは両方を受け入れます。
N分/時間のエミッタは、新しい署名を開始します。
古い/新しい「子供」のチェックの共有を監視します。
ターゲットシェアに到達すると、リトリムは古いです。

yaml jwks:
keys:
- kid: "eu-core-es256-2025-10" # new alg: "ES256"
use: "sig"
crv: "P-256"
x: "<...>"; y: "<...>"
- kid: "eu-core-es256-2025-07" # old alg: "ES256"
use: "sig"
...

7）署名および検証ポリシー

デフォルトのアルゴリズム：署名ES256/EdDSA；必要に応じてRSA-PSS。
'none'/弱いアルゴリズムの禁止；認証側のホワイトリスト。
クロックスキュー：± 300 c、ログ偏差を許可します。
キーピニング（内部サービス）と短いTTL JWKSキャッシュ（30-60秒）。

8）封筒の暗号化およびKDF

次のようなデータを保存します： 

ciphertext = AEAD_Encrypt(DEK, plaintext, AAD=tenant    region    table    row_id)
DEK = KMS. Decrypt (KEK, EncryptedDEK )//on access
EncryptedDEK = KMS. Encrypt (KEK, DEK )//on write

KEK （Key Encryption Key）はKMS/HSMに格納され、定期的に回転します。
DEKはオブジェクト/バッチごとに作成されます。KEKを回転させる際には、データを再暗号化せずに素早く再ラップを行います。
ストリームの場合-短命のチャンネルキーを出力するECDH+HKDF。

9）地域性とマルチテナント

キーとJWKSは地域化されています：'eu-core'、 'latam-core'はキーの異なるセットです。
テナント/地域別のIAM/監査の分離;住宅間のキーは「流れ」しません。
'kid'コードと信頼ドメイン接頭辞：'eu-core-es256-2025-10'。

10）統合の秘密（HMAC、 APIキー）

KMSにバックアップされたSecret Storeに保存し、短命のクライアントの秘密（ローテーションポリシー≤ 90日）を介して発行します。
回転中の2つのアクティブシークレット（デュアルシークレット）をサポートします。
Webhookの場合-timestamp+HMAC body signature；タイムウィンドウ≤ 5分。

11）アクセス制御およびプロセス

IAM行列：誰が'生成'、'記号'、'復号'、'rotate'、 'destroy'（最小ロール）。
4目の原則：敏感な操作は2つの確認を要求します。
ウィンドウを変更：新しいキーを有効にし、カナリア領域をテストするためのウィンドウ。
Runbooks：スケジュールされた回転と強制回転のプロシージャテンプレート。

12）可視性と監査

メトリクス：
  • 'sign_p95_ms'、' decrypt_p95_ms'、 'jwks_skew_ms'、
  • 'kid'、 'old_kid_usage_ratio'、
  • 'invalid_signature_rate'、 'decrypt_failure_rate'
ログ/監査：
  • 各署名/復号操作は「who/what/when/where/kid/purpose」です。
  • キーステータスと回転/失効要求の履歴。
  • HSMの資格、主要な材料のアクセスログ。

13）プレイブック（インシデント）

1.シグネチャーキーの妥協

古い「子供」（または最小限のウィンドウで「引退」に翻訳）の即時取り消し、新しいJWKSの発行、TTLトークンの短縮、強制ログアウト/RT障害、統合所有者への通信、レトロ監査。

2.回転後のマス'INVALID_SIGNATURE'

JWKS/clock skew cacheをチェックし、dual-acceptを返し、ウィンドウを拡張し、クライアントに配布します。

3.KMS/HSMレイテンシーの増加

ローカル署名キャッシュの有効化は許可されていません。代わりに-エミッタでのバッチ/キュー、HSMプロキシの自動スケーリング、クリティカルストリームの優先順位付け。

4.1つの地域の障害

地域の分離手順をアクティブにします。他の地域からキーを"引かないでください。衰退した領域のシグネチャに関連付けられた機能を低下させます。

14）テスト

契約：JWKSの正しさ、正しい'子供'/alg/use、顧客の両立性。
否定：偽の署名、時代遅れの「子供」、間違ったalg、時計のスキュー。
混乱：即刻の回転、KMSの利用不能、時間の漂流。
ロード：ピーク署名（JWT/webhook）、ピーク復号（PII/ペイアウト）。
E2E：デュアルキーウィンドウ：リリース-検証-トラフィック転送-古いものの拒否。

15）構成例（YAML）

yaml crypto:
regions:
- id: "eu-core"
jwks_url: "https://sts. eu/.well-known/jwks. json"
rotation:
jwt_sign: { interval_days: 30, window_dual: "48h" }
webhook: { interval_days: 60, window_dual: "72h" }
kek:   { interval_days: 90, action: "rewrap" }
alg_policy:
sign: ["ES256","EdDSA"]
tls: ["TLS1. 2+","ECDSA_P256"]
publish:
jwks_cache_ttl: "60s"
audit:
hsm_attestation_required: true two_person_rule: true

16）アーティファクトのJWKSとマーカーの例

JWTヘッダーフラグメント： 
json
{ "alg":"ES256", "kid":"eu-core-es256-2025-10", "typ":"JWT" }
JWKS（パブリックパート）： 
json
{ "keys":[
{"kty":"EC","use":"sig","crv":"P-256","kid":"eu-core-es256-2025-10","x":"...","y":"..."},
{"kty":"EC","use":"sig","crv":"P-256","kid":"eu-core-es256-2025-07","x":"...","y":"..."}
]}

17）アンチパターン

「何年もの間」長寿命の鍵は、すべての地域に共通しています。
二重受諾なしの回転「一度に」。
KMS/HSM 「for speed」から秘密鍵をエクスポートします。
タスクのミキシング：JWTに署名し、1つのキーでデータを暗号化します。
HSMログ/資格とIAMの制限がない。
KEK回転にDEKの再ラップ機構はありません。
Secret Storeの代わりにenvで手動の「秘密」。

18）売り上げ前のチェックリスト

  • KMS/HSMのすべての秘密鍵。IAM行列と4眼の原理が調整されています。
  • アルゴリズムポリシー、鍵長、寿命が承認されています。
  • 「キッド」共有監視でデュアルキープロセスを有効にしました。
  • JWKSは、短いTTLとキャッシュウォーミングで公開されています。顧客はキー≥ 2を受け入れます。
  • エンベロープ暗号化：KEKは回転し、DEKはダウンタイムなしで再ラップします。
  • テナントによる地域分離と個別のキーセット。
  • 妥協/転がり/力の回転のplaybooks；訓練は実行されます。
  • メトリック（'old_kid_usage_ratio'、 'invalid_signature_rate'）とアラートが有効になります。
  • テストスイートcontract/negative/chaos/load/E2E合格しました。
  • 統合のためのドキュメント：どのウィンドウとエラーコードで'kid'シフトを処理するか。

結論

KMS/HSMは、真実の源であり、デュアルキー、地域およびテナントの分離、エンベロープ暗号化および観測可能性を備えた定期的かつ安全なローテーションです。これらのルールに従うことで、あなたはスケールする暗号の輪郭を手に入れ、インシデント耐性があり、監査人に説明するのは簡単です。そして、開発者やインテグレーターは痛みなく変化を経験します。

Contact

お問い合わせ

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

統合を開始

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

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

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