MENU

Kerberos — 1988年MIT発のチケット型認証プロトコル

Kerberos アイキャッチ
Kerberos

Kerberosは1988年、MITのProject Athenaで開発された分散認証プロトコルです。ギリシャ神話で冥界の番犬として知られる三頭犬ケルベロスの名を冠し、クライアント・サーバー・KDC(鍵配布センター)の三者で「チケット」を交換しながら認証を完結させる仕組みになっています。パスワードをネットワーク上に流さず、対称鍵暗号と時刻ベースの認証子で完璧なシングルサインオンを実現したことで、UNIX、Windows Active Directory、Hadoop、PostgreSQLなど多様な分散システムに採用され続けています。本記事ではKerberosの構造と現在の立ち位置を整理します。

目次

この記事の目次

  1. KDC・TGS・3つのチケット
  2. MIT Project Athenaという揺りかご
  3. Active Directoryと企業認証の中核
  4. OAuth/OIDC・SAMLとの位置関係
  5. まとめ

KDC・TGS・3つのチケット

KDC・TGS・3つのチケット

Kerberosの中核には、Authentication Server(AS)とTicket Granting Server(TGS)からなる鍵配布センター(KDC)があります。ユーザーは最初にASへログインリクエスト(AS-REQ)を送り、パスワードから導出した鍵で復号できるTGT(Ticket Granting Ticket)を受け取ります。TGTはユーザー自身の身元証明として機能し、有効期限は通常10時間程度です。サービス利用時にはTGTを添えてTGSへサービスチケット要求(TGS-REQ)を送り、目的のサービス用に暗号化された「サービスチケット」を取得します。

認証時、クライアントはサービスチケットと現在時刻を含む「認証子(Authenticator)」を併せてサービスへ送ります。サービスは自分の秘密鍵でチケットを復号して有効性を確認し、認証子の時刻が現在から5分以内かをチェックします。この時刻ベースの仕組みのため、Kerberosでは全ノードのクロックを揃える(NTPで5分以内の誤差に保つ)必要があります。TGT・サービスチケット・認証子という「3つのチケット」を経由することで、パスワードを一切ネットワークに流さずSSO(シングルサインオン)を成立させているのがKerberosの設計上の美点です。

MIT Project Athenaという揺りかご

MIT Project Athenaという揺りかご

Kerberosが生まれたMIT Project Athenaは、1983年にIBMとDECがそれぞれ2,500万ドル相当を出資して始まった分散コンピューティングの大規模実験プロジェクトです。「キャンパスのどのワークステーションからログインしても同じ環境が使える」という目標のもと、X Window System、Zephyr Notification Service、Hesiodディレクトリサービスなどが生み出されました。Kerberosもその一部として、Steve MillerとClifford Neumanを中心とするチームが設計しました。

1988年に外部公開されたKerberos v4は、DESベースで認証を行うシンプルな仕組みでしたが、国際的に普及するにつれて暗号アルゴリズムの差し替えやマルチドメイン連携のニーズが高まり、1993年9月にJohn KohlとClifford NeumanがRFC 1510としてKerberos v5を標準化しました。v5ではAES-256対応、暗号スイートのネゴシエーション、クロスレルム認証、PKINIT(公開鍵認証)など現代的な機能が加わり、現行のKerberos実装はすべてv5系です。MIT Kerberos、HeimdalなどがOSS実装として広く使われています。

Active Directoryと企業認証の中核

Active Directoryと企業認証の中核

MicrosoftはWindows 2000 Serverから、それまでのNTLMに代わるデフォルト認証プロトコルとしてKerberos v5を採用しました。Active DirectoryのドメインコントローラがKDCを兼ねる構造で、ドメインに参加したクライアントとサーバーはログオン直後にTGTを取得し、ファイル共有、Exchange、SharePoint、IISなどすべての社内サービスをシングルサインオンで使えるようになります。Group Managed Service Account(gMSA)や制約付き委任(Constrained Delegation)など、Microsoftが追加した拡張機能はSPNEGO経由でWebアプリへも届きます。

Linux/macOS陣営では、SSSDやrealmd経由でActive Directoryへ参加し、PAMでKerberos認証を統合するのが定番です。ビッグデータ分野ではHadoopクラスタを「Kerberized」する作業が事実上のセキュリティ強化策で、HDFS、YARN、Hive、HBaseすべてがプリンシパル/keytabで認証します。PostgreSQLやMySQLもGSSAPIプラグインでKerberos認証に対応し、NFSv4のsec=krb5マウントではファイル共有のRPC認証にも使われます。現代の企業ITで「ユーザーがパスワードを意識せず複数システムを跨ぐ」体験の裏側には、ほぼ間違いなくKerberosが動いています。

OAuth/OIDC・SAMLとの位置関係

OAuth/OIDC・SAMLとの位置関係

Kerberosは「同一管理ドメイン内のSSO」という用途では今も最高の性能を発揮しますが、クラウド時代になって弱点が目立つようになりました。ファイアウォール越し(インターネット越し)の認証には向かず、モバイルアプリやSaaS連携には不適です。代わりに台頭したのが、SAML 2.0(2005年)、OAuth 2.0(2012年)、OpenID Connect(2014年)といったHTTPSベースのフェデレーション認証プロトコル群で、Azure AD、Okta、Auth0、Google Workspaceなどがこの世界の主役です。

とはいえ、Kerberosが消えるわけではなく、ハイブリッド連携で活躍が続いています。Azure AD ConnectやSeamless SSOは、社内Active DirectoryのKerberosチケットをAzure AD認証へつなぎ、「社内PCからはパスワード入力なしでMicrosoft 365へログイン」を実現します。Hadoopクラスタや大規模Linux環境の社内認証では依然としてKerberosが現役で、「社内はKerberos、外向きはOIDC」というハイブリッド構成が大企業の標準パターンになっています。30年以上前のプロトコルが今も主役級の働きを続けている例は、IT分野でも珍しい部類に入ります。

まとめ

Kerberosは1988年MITで生まれて以来、チケット型認証のシンプルさと高速さで企業認証の中核に居続けています。Active Directoryと一体化したシングルサインオン体験を支える土台として、クラウド時代のOAuth/OIDCと共存しながら、今後も社内認証の主役を担い続けるでしょう。

※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

コメント

コメントする

目次