こんにちは。セキュリティの世界へようこそ。
日々、開発の現場で「JWT（JSON Web Token）」という言葉を目にすることも増えたのではないでしょうか？
「JWTは便利だ」とよく言われますが、実はこれ、扱い方を間違えると「家の鍵を道端に落として、しかも誰でも複製できる状態」になりかねない、非常にデリケートな代物なんです。
今日は、そんなJWTを安全に使いこなすための「鍵のローテーション」と「JWKS」について、泥棒に侵入されないための防犯対策になぞらえて、一緒に紐解いていきましょう。
—
1. なぜJWTに「鍵の更新」が必要なの？
JWTは、サーバーが発行する「通行手形」のようなものです。この手形には、偽造されないように「電子署名」という封印がされています。この封印を押すための「署名鍵」がもし漏洩してしまったら？
攻撃者は、あなたのサービスになりすまして、誰の身分でも偽造し放題になってしまいます。
想像してみてください。「家の合鍵」が近所中にバラまかれてしまったら、あなたはすぐに鍵穴（シリンダー）ごと交換しますよね？ それと同じことが、デジタル世界でも必要なんです。これが「鍵のローテーション」です。
2. 鍵を交換するたびに「設定ファイル」を書き換えるのは現実的じゃない
鍵を更新するたびに、すべてのクライアント（アプリやサービス）のコードを修正して再デプロイしていたら、現場はパンクしてしまいます。そこで登場するのが「JWKS (JSON Web Key Set)」という仕組みです。
これは、例えるなら「鍵屋さんが最新の合鍵情報を掲示板に貼っておいてくれる」ような仕組みです。
- 従来のやり方： 鍵を替えるたびに、全員に「新しい鍵はこれだよ」と手渡ししに行く（超大変！）
- JWKSのやり方： サーバーが特定のURL（
/.well-known/jwks.json）で「今の有効な鍵はこれだよ」と公開しておく。クライアントは必要になったらそのURLを見に行けばいい。
これなら、サーバー側で鍵をコッソリ差し替えても、クライアントは自動的に新しい鍵を取りに来てくれるので、システムを止めることなく安全を維持できるんです。
—
3. JWKSの構造を見てみよう
JWKSは、複数の鍵を配列で持てるJSON形式のデータです。こんな風に見えます。
{
“keys”: [
{
“kty”: “RSA”, // 鍵の種類（RSAなど）
“kid”: “key-2023-10”, // 鍵の識別ID（どれを使っているか特定用）
“use”: “sig”, // 署名用(sig)であることを示す
“n”: “…”, // RSAの公開鍵の本体
“e”: “AQAB” // RSAの指数（通常はこの値）
}
]
}
kid(Key ID) が超重要です： 攻撃者はどの鍵で署名されているかを知りたがります。このIDを見て、「あ、今は2023年10月版の鍵を使ってるんだな」とクライアントが判断する目印になります。
—
4. 開発現場で意識すべき「運用ルール」
安全な開発のために、以下の3ステップをぜひ守ってください。
① 鍵の寿命を決める
鍵を一生使い回すのはNGです。「3ヶ月に一度は新しい鍵に切り替える」といったルールを決めましょう。
② 古い鍵をすぐ捨てない
新しい鍵を発行した瞬間に古い鍵を無効にすると、ログイン中のユーザーが全員弾き出されてしまいます。
- ステップ1: 新しい鍵をJWKSに追加する（古い鍵も残しておく）
- ステップ2: しばらく待つ（全員が新しい鍵を認識する時間）
- ステップ3: 古い鍵をJWKSから削除する
③ 鍵の保存場所には細心の注意を
鍵（特に秘密鍵）がソースコードの中にハードコーディングされていたら、それは「窓を開けたまま外出している」のと同じです。必ずAWS Secrets ManagerやHashiCorp Vaultのような、専門の鍵管理サービスに預けましょう。
—
最後に：セキュリティは「完璧」を目指さない
「鍵をローテーションしなきゃ」「JWKSを実装しなきゃ」と考えると、少し重く感じるかもしれません。でも、まずは「鍵をいつでも差し替えられる仕組み（JWKS）を導入する」こと。これだけで、万が一の漏洩時、あなたのサービスは即座にリカバリーできる強固な防壁を持つことになります。
セキュリティは、一度作って終わりではありません。泥棒が手口を変えるように、私たちも少しずつ、鍵を磨き、掛け替えながらサービスを守っていく。その積み重ねこそが、ユーザーからの信頼という一番の財産を守ることに繋がります。
一歩ずつ、一緒に学んでいきましょう！何か不明点があれば、またいつでも聞いてくださいね。
コメント