概要

Kerberos（ケルベロス）はMIT開発の相互認証プロトコルで、Active Directoryをはじめとする多くのエンタープライズ環境の認証基盤に採用されています。最大の特徴は「パスワードそのものをネットワーク上に一切流さない」設計にあります。共通鍵暗号を用いたチケットベースの仕組みで、ユーザとサービスの双方がなりすましでないことを確認し合う相互認証を実現します。SC試験では、KDC内部のAS・TGSの役割分担やチケットの発行フロー、そしてゴールデンチケット等の攻撃手法とその対策が頻出です。

仕組みと動作原理

KDCを構成するAS・TGSの役割

KDC（Key Distribution Center）は単一のサーバプロセスではなく、内部に2つの論理的な機能を持ちます。

コンポーネント正式名称役割
KDCKey Distribution Centerチケット発行を統括するサーバ機能全体（ADではドメインコントローラが兼務）
ASAuthentication Serverユーザの初回認証を行い、TGTを発行する
TGSTicket Granting ServerTGTを検証し、個別サービス用のサービスチケット（ST）を発行する
KDC内部の構成（AS・TGSの役割分担）
AS（認証サーバ）
初回認証・TGT発行
TGS（チケット発行サーバ）
STの発行
アカウントDB
ユーザ・サービスの鍵を保持
krbtgtアカウント
TGT署名用の特殊アカウント
KDC
Key Distribution Center

チケット発行フロー（AS Exchange → TGS Exchange → AP Exchange）

Kerberos認証は3段階の「交換（Exchange）」から構成されます。

  1. AS Exchange：クライアントがASにID（プリンシパル）を提示し、事前認証（タイムスタンプをユーザのパスワードハッシュで暗号化したもの）を行う。ASはこれを検証しTGTとセッション鍵を返す
  2. TGS Exchange：クライアントはTGTを添えてTGSにサービスチケット（ST）を要求する。TGSはTGTをkrbtgtアカウントの鍵で復号・検証し、対象サービス用のSTを発行する
  3. AP Exchange：クライアントはSTを対象サービスに提示する。サービスは自身の鍵でSTを復号し、内包されたセッション鍵でクライアントのAuthenticatorを検証する（相互認証を行う場合はサービス側もタイムスタンプを返送する）
Kerberosチケット発行フロー（AS→TGS→AP Exchange）
1
クライアント → AS
事前認証情報を提示（AS-REQ）
パスワードハッシュで暗号化したタイムスタンプ
 2
AS → クライアント
TGTとセッション鍵を返す（AS-REP）
TGTはkrbtgtの鍵で暗号化・改ざん不可
 3
クライアント → TGS
TGT提示でSTを要求（TGS-REQ）
アクセスしたいサービス名を指定
 4
TGS → クライアント
サービスチケット（ST）を発行（TGS-REP）
対象サービスの鍵で暗号化
 5
クライアント → サービス
STを提示しアクセス（AP-REQ/REP）
サービスも応答を返せば相互認証が成立

チケットの内部構造

サービスチケット（ST）は対象サービスの秘密鍵で暗号化された「封筒」であり、クライアントは中身を読めません。

項目内容
クライアントのプリンシパル名誰に対して発行されたチケットか
セッション鍵クライアントとサービス間の以降の通信に使う共有鍵
有効期限チケットの有効時間（既定は10時間程度）
PAC（Privilege Attribute Certificate）AD環境固有。ユーザの所属グループ・権限情報を含む拡張領域

さらにクライアントは、STとは別にAuthenticator（現在時刻をセッション鍵で暗号化した小さなデータ）を都度生成してサービスに提示します。これによりチケットの再利用（リプレイ攻撃）を検知します。

委任（Delegation）

一部のサービスは、ユーザの代わりに別のサービスへアクセスする必要があります（例：Webサーバがユーザの代理でバックエンドDBにアクセスする多段構成）。

方式説明リスク
制約のない委任（Unconstrained Delegation）委任を許可されたサービスがユーザのTGTそのものを受け取り、どのサービスにもなりすませる侵害時の被害が広範囲に及ぶ（危険）
制約付き委任（Constrained Delegation）委任先を事前に許可リストで限定する（S4U2Self/S4U2Proxy）許可されたサービスのみに制限され安全性が高い
リソースベース制約付き委任（RBCD）委任を許可するかをリソース側（委任先）で制御する委任元と委任先の管理者が分離できる

SC試験での頻出ポイント

  • KDC・AS・TGSの役割分担：ASは初回認証とTGT発行、TGSはTGT検証とST発行という2段階構成であることを問う問題が頻出
  • パスワードがネットワークを流れない設計：サーバはユーザのパスワードそのものを一切受け取らず、事前認証・チケット検証はすべて鍵を用いた暗号処理で行う
  • 相互認証（Mutual Authentication）：クライアントだけでなくサービス側もクライアントに対して自身の正当性を証明できる点がパスワード認証との違い
  • krbtgtアカウントの重要性：TGTはkrbtgtアカウントの鍵で署名されるため、この鍵が漏えいすると任意のTGT（ゴールデンチケット）を偽造可能になる
  • クロックスキュー（時刻ずれ）の影響：Kerberosはタイムスタンプによるリプレイ防止に依存するため、KDCとクライアントの時刻同期（既定許容差は5分）がずれると認証が失敗する

主要な攻撃手法と対策

攻撃手口対策
パスザチケット（Pass-the-Ticket）端末のメモリから正規のTGTやSTを窃取し、別端末から再利用してなりすますチケット有効期限の短縮、EDRによるメモリ保護、特権アカウントの分離
ゴールデンチケットkrbtgtアカウントの鍵（ハッシュ）を窃取し、任意のユーザ・権限を持つTGTを自由に偽造するkrbtgtパスワードの定期的な二重ローテーション、ドメインコントローラの堅牢化
シルバーチケット特定サービスアカウントの鍵を窃取し、そのサービス向けのSTのみを偽造する（TGS Exchangeを経由しないため検知が難しい）サービスアカウントの鍵の保護、異常アクセスの監視
Kerberoastingサービスプリンシパル名（SPN）に紐づくアカウントのSTを要求し、オフラインでパスワードを総当たり攻撃するサービスアカウントに長く複雑なパスワードを設定、gMSA（グループ管理サービスアカウント）の利用
AS-REP Roasting事前認証が無効化されたアカウントに対しAS-REPを取得し、オフラインでハッシュを解析する全アカウントで事前認証を必須化する
侵害される鍵の範囲によるチケット偽造攻撃の比較
シルバーチケット ゴールデンチケット
窃取する鍵
特定サービスアカウントの鍵
krbtgtアカウントの鍵
偽造できる範囲
その1サービスのみ
ドメイン内の任意のサービス
TGS Exchangeの関与
経由しない（検知が困難）
TGT自体を偽造するため広範に影響
被害の深刻度
限定的
ドメイン全体が侵害される最悪ケース

よくある誤問・ひっかけパターン

誤り① 「Kerberos認証ではサーバがユーザのパスワードを保持し、通信のたびに照合する」→ 誤。サーバ（サービス）はユーザのパスワードを一切知らず、KDCが発行したチケットとセッション鍵のみで検証を行います。パスワードを知っているのはKDC（アカウントDB）だけです。

誤り② 「TGTを一度取得すれば、以降は認証なしで全サービスにアクセスできる」→ 誤。TGTはあくまで「TGSに対してSTを要求する資格」であり、個別サービスへのアクセスにはサービスごとにTGS Exchangeを経てSTを取得する必要があります。

誤り③ 「ゴールデンチケット攻撃はTGSの脆弱性を突く攻撃である」→ 誤。ゴールデンチケットはTGSではなく**krbtgtアカウントの鍵（ASが発行するTGTの署名鍵）**が漏えいすることで成立します。TGSを経由せずに攻撃者が直接TGTを偽造できる点が本質です。

関連用語

重要キーワード

用語説明
KDCKey Distribution Center。AS・TGSからなるチケット発行の中枢機能
TGTTicket Granting Ticket。ASが発行する、STを要求するための「引換券」
ST（サービスチケット）TGSが発行する、特定サービスへのアクセスに使う「入場券」
krbtgtアカウントTGTの署名・暗号化に使う鍵を保持する特殊なドメインアカウント
パスザチケット窃取したチケットを別端末から再利用してなりすます攻撃
ゴールデンチケットkrbtgtの鍵を使って任意のTGTを偽造する、ドメイン全体を侵害する攻撃