KDCがキーを扱う5つの方法 — Kerberosセキュリティの核心

“秘密は二人で知れば秘密ではない。”

— しかし、何千ものユーザーが互いを信頼する必要があるとしたら？

KDCは、その不可能を可能にします。

この記事で扱うこと

KDC (Key Distribution Center) とは何か、なぜ必要なのか
KDCを構成する2つの主要モジュール、ASとTGSの役割
KDCが管理する3種類のキー（マスターキー、セッションキー、チケット）の違い
チケットベースのキー配布フローを5ステップで完全に理解する
実務でよく遭遇するKDCの落とし穴とセキュリティ原則

導入 — なぜKDCが必要なのか？

会社に1,000人の従業員がいると仮定してみましょう。すべての従業員が互いに安全に通信するためには、いくつの秘密鍵が必要でしょうか？正解は約499,500個（n×(n-1)/2）です。これをどのように発行し、更新し、破棄するのでしょうか？ため息が出ます。

この問題を解決する最も洗練された方法が、KDC (Key Distribution Center) です。KDCは「誰もが信頼する中央の秘密保管庫」となり、2つの当事者が初めて出会う瞬間でも安全な通信チャネルを開きます。これが、私たちがよく耳にするKerberos認証システムの核心であり、Active Directoryが内部的に動かしているメカニズムであり、クラウドやビッグデータプラットフォーム（Hadoop、Sparkなど）認証の標準です。

KDCとは何か — 信頼の中心

KDCは、その名の通り「キーを配布する中央サーバー」です。すべてのユーザーとサービスは、KDCに自分の秘密鍵（マスターキー）を事前に登録しておき、他の誰かと通信する必要があるたびに、KDCに「あの人と安全に話せるようにしてください」と依頼します。

KDCは2つの主要なサービスで構成されています：


構成要素	英語	役割
認証サーバー	AS (Authentication Server)	ユーザーが誰であるかを確認し、最初のチケット（TGT）を発行
チケット発行サーバー	TGS (Ticket Granting Server)	実際のサービスアクセスに使用されるサービスチケットを発行

このように認証とチケット発行を分離した理由は単純です。ユーザーのパスワード（マスターキー）の使用を可能な限り少なくするためです。パスワードは1日に1回だけ使用し、その後は一時的な身分証明書（TGT）で代用するという発想です。

️ KDCが扱う3種類のキー

KDCのキー管理を理解するには、キーの種類を明確に区別する必要があります。

1. マスターキー (Master Key / Long-term Key)

ユーザーやサービスがKDCに登録する際に作成される永続的な秘密鍵です。通常、ユーザーのパスワードをハッシュ化した値から生成されます。

寿命: パスワード変更まで有効（数ヶ月〜数年）
保存場所: KDCのデータベース + ユーザー自身の記憶
重要原則: 決してネットワーク上を流れない。マスターキーは「他のキーを暗号化する用途」にのみ使用されます。

2. セッションキー (Session Key)

2つの当事者が短時間通信する際に使用する使い捨ての共通鍵です。KDCがその都度新しく作成します。

寿命: 通常8〜10時間（ポリシーにより調整可能）
特徴: 毎回新しく生成されるため、一度漏洩しても被害が限定的
利点: マスターキーを直接露出させることなく、2つの当事者が安全に通信可能

3. チケット (Ticket)

KDCが発行する暗号化された入場許可証です。中にはセッションキーとユーザー情報、有効期限が含まれています。

TGT (Ticket Granting Ticket): TGSに提出するチケット。ASが発行
Service Ticket: 実際のサービスサーバーに提出するチケット。TGSが発行

例えるなら、TGTは「遊園地の入場券」、Service Ticketは「各アトラクションの搭乗券」です。入場券を1枚持っていれば、その日は再認証なしで様々なアトラクションを楽しむことができます。

KDCのキー配布フロー — 5ステップ完全攻略

いよいよ本題です。ユーザーが何らかのサービスにアクセスする際、KDCとの間で何が起こるのでしょうか？以下の図を見ながら追ってみましょう。（図は本文の下にあります。）

[ステップ1] ユーザー → AS: 認証要求 ユーザー（Alice）は自分のIDを平文でASに送信します。パスワードは送信しません。この時点からKDCの精巧な設計が光ります。

[ステップ2] AS → ユーザー: TGT + セッションキー ASは2つのものを作成して応答します。

TGT: TGSのみが解読できるようにTGSのマスターキーで暗号化
セッションキー（Alice ↔ TGS用）: Aliceのマスターキーで暗号化して同封

Aliceは自分のパスワードからマスターキーを生成し、応答を解読します。解読できれば認証成功です。このとき、パスワードはネットワーク上を一度も流れていません。

[ステップ3] ユーザー → TGS: サービスチケット要求 次にAliceはTGTと「どのサービスにアクセスしたいか」をTGSに送信します。TGTはTGSのみが解読できるため、改ざんは不可能です。

[ステップ4] TGS → ユーザー: Service Ticket + 新しいセッションキー TGSは再び2つのものを作成します。

Service Ticket: 該当サービスサーバーのマスターキーで暗号化
新しいセッションキー（Alice ↔ サービス用）: 既存のセッションキーで暗号化

[ステップ5] ユーザー → サービスサーバー: アクセス AliceはService Ticketをサービスサーバーに提示します。サービスサーバーは自分のマスターキーでチケットを解読し、Aliceのセッションキーを取得します。これで2人は安全に通信できます。

核心を1文で要約するとこうなります。

“KDCは自身のマスターキーを利用して、会ったことのない2つの当事者に共通のセッションキーを安全に埋め込む。”

️ KDCキー管理のセキュリティ原則

KDCが30年以上生き残ってきたのには理由があります。以下の原則のおかげです。

マスターキー非転送原則: マスターキーはKDCとクライアント間でも決して転送されません。キーを暗号化する用途にのみ使用されます。
セッションキーの短期性: セッションキーは短い寿命を持ち、期限切れになると自動的に破棄されます。キー漏洩の影響範囲を最小限に抑えます。
タイムスタンプベースの再送防止: すべてのメッセージにタイムスタンプ（Authenticator）を含めることで、誰かがパケットを傍受して再送しても機能しないようにします。
チケットの自己完結性: サービスサーバーはKDCに毎回問い合わせることなく、自身のマスターキーだけでチケットを検証できます。これによりKDCの負荷が分散されます。
共通鍵ベースの効率性: AES-256のような共通鍵アルゴリズムを使用することで、高速な暗号化/復号化が可能です。

⚠️ 注意事項 — KDCを運用する際に陥りやすい落とし穴

実務でKDC（特にKerberos/AD環境）を運用していると、必ず遭遇する問題があります。

単一障害点（SPOF）の罠: KDCがダウンすると、全体の認証が麻痺します。必ずマスターKDC + スレーブKDCの二重化構成にする必要があります。
時刻同期（Clock Skew）の問題: タイムスタンプ検証のため、クライアントとKDCの時刻誤差が5分（デフォルト値）を超えると認証が失敗します。NTPサーバー同期が必須です。
オフライン辞書攻撃の可能性: 弱いパスワードのマスターキーは、傍受された応答からオフラインで推測される可能性があります。強力なパスワードポリシー + 事前認証の有効化が必要です。
Kerberoasting攻撃: サービスアカウントの弱いパスワードを狙った攻撃は、実際に非常に頻繁に発生します。サービスアカウントには30文字以上のランダムなパスワードまたはgMSA (group Managed Service Account)の使用を推奨します。
チケット寿命管理: TGTの寿命を長すぎると、盗難時のリスクが増大します。通常、10時間以内に制限するのが標準です。

✅ まとめ — KDC、結局何を記憶すべきか

KDCのキー管理は結局、「マスターキーは隠し、セッションキーは頻繁に交換し、チケットで委任する」という3つの原則にまとめられます。ユーザーのパスワードを一度もネットワークに露出させることなく、会ったことのない2つの当事者が即座に安全な通信を開始できるようにする、精巧な設計です。

次の学習ステップとしては、以下のテーマをお勧めします。

Kerberos 5 RFC 4120を熟読 — プロトコルのすべての詳細が含まれています
Active DirectoryのKDC実装を分析 — 実務環境で最もよく遭遇します
PKINIT拡張 — パスワードの代わりに証明書でAS認証を行う方式
クラウド環境のKerberos — AWS Managed AD、Azure AD DSの動作方式

次回は、「KerberoastingとGolden Ticket攻撃 — KDCを狙う実際の攻撃シナリオ」というテーマで続けるのも良いでしょう。