KERBEROS AUTHENTICATION

Kerberos認証（Kerberos Authentication）とは、MIT（マサチューセッツ工科大学）が1980年代に開発したネットワーク認証プロトコルです。ギリシャ神話の冥界の番犬ケルベロスに由来する名前の通り、ネットワーク上の通信を強固に守るための「門番」として機能します。現在最も広く使用されているのはバージョン5（Kerberos V5、RFC 4120）です。

Kerberosの最大の特徴は、チケットベースの認証方式を採用している点です。ユーザーはパスワードをネットワーク上に直接送信するのではなく、暗号化されたチケットを使って自身の身元を証明します。これにより、パスワードの盗聴リスクを大幅に低減できます。信頼された第三者機関であるKDC（Key Distribution Center：鍵配布センター）が認証の中核を担います。

KerberosはMicrosoft Active Directoryの既定の認証プロトコルとして採用されており、世界中の企業ネットワークで広く利用されています。Windows 2000以降のActive Directory環境では、以前のNTLM認証に代わってKerberosが標準認証方式となりました。また、Linux/UNIXシステムでもKerberosによる統合認証が可能であり、クロスプラットフォーム環境でのシングルサインオン（SSO）を実現します。

しかし、Kerberosプロトコルはその設計上、チケットの偽造や悪用に対する攻撃手法（Golden Ticket攻撃、Silver Ticket攻撃、Kerberoasting攻撃など）が確立されており、適切なセキュリティ対策が不可欠です。特に、Active Directory環境におけるKerberosの保護は、企業のセキュリティ戦略において最も重要な要素の一つとなっています。

Kerberos認証の基本アーキテクチャ

Kerberosは3つの主要コンポーネントで構成されています。

• KDC（Key Distribution Center）：認証の中核となるサーバー。AS（Authentication Service：認証サービス）とTGS（Ticket Granting Service：チケット発行サービス）の2つのサービスで構成される。Active Directory環境ではドメインコントローラーがKDCの役割を兼ねる。
• クライアント：認証を受けるユーザーまたはコンピューター。チケットを取得してサービスにアクセスする。
• サービスサーバー：ファイルサーバー、Webサーバーなど、クライアントがアクセスしたい対象のサービス。

チケット認証フロー（AS/TGS交換）

Kerberos認証は以下の3段階で進行します。

1. AS交換（Authentication Service Exchange）：クライアントがKDCのASに対して認証を要求する。ASはクライアントのパスワードハッシュで暗号化したTGT（Ticket Granting Ticket：チケット発行チケット）とセッション鍵を返す。TGTはKDCのマスター鍵（krbtgtアカウントのハッシュ）で暗号化されている。
2. TGS交換（Ticket Granting Service Exchange）：クライアントがTGTを提示してTGSにサービスチケットを要求する。TGSはTGTを検証し、対象サービスのアカウントハッシュで暗号化されたサービスチケット（ST）を発行する。
3. AP交換（Application Service Exchange）：クライアントがサービスチケットをサービスサーバーに提示してアクセスを受ける。サービスサーバーは自身のアカウントハッシュでチケットを復号して検証する。

TGT（Ticket Granting Ticket）の役割

TGTは「チケットを取得するためのチケット」です。ユーザーが一度パスワードで認証を受けると、TGTが発行されます。以降、ユーザーはTGTを使って各サービスへのサービスチケットを取得できるため、パスワードを繰り返し入力する必要がありません。これがKerberosによるシングルサインオン（SSO）の仕組みです。TGTのデフォルト有効期間は10時間です。

Active Directory統合とクロスレルム信頼

Active Directory環境では、各ドメインが1つのKerberosレルム（領域）を構成します。クロスレルム信頼（Cross-Realm Trust）を構成することで、異なるドメイン間でも相互認証が可能になります。信頼関係が確立されると、一方のドメインのユーザーが他方のドメインのリソースにアクセスする際、中継チケット（Referral Ticket）が使用されます。フォレスト信頼、外部信頼、ショートカット信頼など、複数の信頼タイプが利用可能です。

Kerberos vs NTLM

NTLMはKerberos以前にWindowsで使用されていたチャレンジ/レスポンス型の認証プロトコルです。Kerberosは相互認証をサポートし、チケットの委任機能を持ち、より強力な暗号化アルゴリズム（AES）を使用できます。一方、NTLMはIPアドレスでのアクセスや、ドメインに参加していないマシンでの認証など、Kerberosが利用できない場面でフォールバックとして使用されます。セキュリティの観点からは、NTLMの使用を最小限に抑え、可能な限りKerberosを使用することが推奨されています。

• 01
  krbtgtアカウントのパスワード定期変更：KDCのマスター鍵であるkrbtgtアカウントのパスワードを定期的（少なくとも180日ごと）に2回連続でリセットする。Golden Ticket攻撃はkrbtgtのハッシュに依存するため、定期変更により有効期間を制限できる。
• 02
  サービスアカウントの強力なパスワード設定：Kerberoasting攻撃を防ぐため、SPNが設定されたサービスアカウントには25文字以上の複雑なパスワードを設定する。可能であれば、Group Managed Service Account（gMSA）を使用してパスワードを自動管理する。
• 03
  AES暗号化の強制：Kerberosチケットの暗号化にAES-256を強制し、RC4（NTLM互換）やDESなどの脆弱な暗号化アルゴリズムを無効化する。グループポリシーで「ネットワークセキュリティ: Kerberosで許可する暗号化の種類を構成する」を設定する。
• 04
  特権アカウントの保護：Protected Usersセキュリティグループを活用し、特権アカウントのNTLMハッシュキャッシュやKerberos委任を無効化する。Credential Guardを有効にしてメモリ上の認証情報を保護する。
• 05
  Kerberos認証ログの監視：Windows Security Event Logのイベント4768（TGT要求）、4769（サービスチケット要求）、4771（事前認証失敗）を監視し、異常なチケット要求パターン（大量のサービスチケット要求、通常と異なる暗号化タイプの使用）を検知する。
• 06
  Kerberos委任の制限：制約なし委任（Unconstrained Delegation）の使用を避け、必要な場合はリソースベースの制約付き委任（Resource-Based Constrained Delegation）を使用する。委任が不要なアカウントには「アカウントは機微なので委任できない」フラグを設定する。