Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
コンテンツコンテンツ
セキュリティ強化ガイド
  1. 前書き
  2. 1 セキュリティと機密保持
  3. 2 コモンクライテリア (Common Criteria)
  4. I 認証
    1. 3 PAM を利用した認証
    2. 4 NIS の使用
    3. 5 YaST を利用した認証クライアントの設定
    4. 6 389 LDAP ディレクトリサービス
    5. 7 Kerberos を利用したネットワーク認証
    6. 8 Active Directory サポート
    7. 9 FreeRADIUS サーバの構築
  5. II ローカルセキュリティ
    1. 10 物理的なセキュリティ
    2. 11 seccheck を利用した自動的なセキュリティチェック
    3. 12 ソフトウエア管理
    4. 13 ファイルの管理
    5. 14 パーティションやファイルの暗号化
    6. 15 cryptctl を利用したアプリケーション向けのストレージ暗号化
    7. 16 ユーザ管理
    8. 17 Spectre/Meltdown チェッカー
    9. 18 YaST を利用したセキュリティの設定
    10. 19 PolKit による認可制御
    11. 20 Linux でのアクセス制御リスト
    12. 21 証明書ストア
    13. 22 AIDE を利用した侵入検知
  6. III ネットワークセキュリティ
    1. 23 X Window System と X 認証
    2. 24 SSH: 機密を保持するネットワーク操作
    3. 25 マスカレードとファイアウオール
    4. 26 VPN サーバの設定
    5. 27 X Window System で動作する PKI マネージャ XCA による管理
  7. IV AppArmor による権限の制限
    1. 28 AppArmor の紹介
    2. 29 入門
    3. 30 プログラムに対する予防接種
    4. 31 プロファイルのコンポーネントと文法
    5. 32 AppArmor のプロファイルリポジトリ
    6. 33 YaST を利用したプロファイルの構築と管理
    7. 34 コマンドラインからのプロファイル構築
    8. 35 チェンジハット機能による Web アプリケーションのプロファイル作成
    9. 36 pam_apparmor によるユーザの制限
    10. 37 プロファイルを作成したアプリケーションの管理
    11. 38 サポート
    12. 39 AppArmor 用語集
  8. V SELinux
    1. 40 SELinux の設定
  9. VI Linux 監査フレームワーク
    1. 41 Linux 監査システムの概要
    2. 42 Linux 監査フレームワークの設定
    3. 43 監査ルールセットの紹介
    4. 44 その他の情報源
  10. A GNU ライセンス
ナビゲーション
適用先 openSUSE Leap 15.2

7 Kerberos を利用したネットワーク認証

概要

Kerberos は暗号化の機能も提供するネットワーク認証プロトコルです。本章では Kerberos の設定方法のほか、 LDAP や NFS のようなサービスとの統合方法について説明しています。

7.1 考え方の概要

通常のオープンなネットワークの場合、ワークステーションがユーザを認証する際、パスワード以外の方法を取ることができません。一般的なインストール環境では、ネットワーク内に存在する各サービスにアクセスするごとに、パスワードの入力が求められます。 Kerberos を利用すると、ユーザの認証を一度行うだけで、他の連携サービスにも自動的に接続できるようになります。なお、ネットワークの機密を保持するため、下記の要件に適合していなければなりません:

  • 各サービスを利用するユーザが自身の識別情報をきちんと管理し、第三者によって識別情報を利用されてしまうことがないようにすること。

  • それぞれのネットワークサービスの提供側 (サーバ) でも、識別情報を保持すること。サーバ側でも識別情報を持っておかないと、攻撃者は容易にサーバになりすますことができてしまいますので、これによってサーバに送信されるはずの認証情報を窃取することができるようになってしまいます。このような考え方は、クライアントがサーバに対して認証を行うだけでなく、その逆の認証も行うことになることから、 相互認証 と呼んでいます。

Kerberos では、強力に暗号化された認証の仕組みによって、このような要件を満たすようになっています。なお、本章での Kerberos の説明は、基本的な考え方にとどまります。より詳しい技術的な説明をご希望の場合は、 Kerberos のドキュメンテーションをお読みください。

7.2 Kerberos で使用する用語

Kerberos の世界では、下記のような用語を使用します。

クレデンシャル (信任状)

ユーザやクライアントは、利用したいサービスに対して、その利用を許可する旨を表わす資格情報を提示する必要があります。 Kerberos では、チケットとオーセンティケータと呼ばれる 2 種類のクレデンシャルが用意されています。

チケット (切符)

チケットとはサーバごとに発行されるクレデンシャルで、クライアントが特定のサービスを利用する際、その提供者 (サーバ) に対して提示するものです。チケットにはサーバの名前のほか、クライアントの名前とクライアントのインターネットアドレス、タイムスタンプと有効期限、ランダムなセッション鍵が書かれています。このデータの全ては、サーバ側の鍵で暗号化されます。

オーセンティケータ

オーセンティケータはチケットと組み合わせて使用するもので、チケットを提示しているクライアントが正当なクライアントであることを示すためのものです。オーセンティケータはクライアント名と IP アドレス、そしてクライアント側の時刻から構成されていて、クライアントと相手側のサーバのみが知りうるセッション鍵で全て暗号化されています。なお、チケットとは異なり、オーセンティケータは一度しか使用することができません。オーセンティケータはクライアント自身が構築します。

プリンシパル

Kerberos でのプリンシパルとは、チケットを割り当てた先を表わすユニークな実体 (ユーザやサービス) を表わします。プリンシパルは、下記のような形式で表わされます:

プライマリ/インスタンス名@レルム
  • プライマリ: プリンシパルの最初の部分です。プリンシパルがユーザを表わすものである場合、この項目はユーザ名になります。

  • インスタンス名 (オプション)プライマリ を特徴付ける、追加の情報を表わします。この文字列と プライマリ との間は、 / で区切ります。

    たとえば tux@example.orgtux/admin@example.org は、同じ Kerberos システム内に同時に存在しうるプリンシパルで、それぞれは別々のものとして扱われます。

  • レルム: Kerberos の領域 (レルム) を表わします。通常、レルムはドメイン名を大文字で表わしたものになります。

相互認証

Kerberos では、クライアントとサーバが相互に認証を行います。認証の際、通信の機密を守る目的で、セッション鍵を共有して使用します。

セッション鍵

セッション鍵とは、 Kerberos が生成した一時的な機密鍵を意味します。セッション鍵はクライアント側が保持していて、クライアントとサービスを提供するサーバとの間で、チケットのやり取りを行う際に暗号化をするために使用します。

リプレイ

ネットワーク上を流れるほぼ全てのメッセージは、盗聴や盗難、偽装を行うことができてしまいます。 Kerberos の世界では、攻撃者が特定のサービスに対するチケットやオーセンティケータを盗むことができてしまうことになりますので、このままでは非常に危険です。たとえそれがサーバ側に届いた後であったとしても、再送信 ( リプレイ ) を行うことで、特定のユーザになりすますことができてしまいます。しかしながら、 Kerberos ではいくつかの仕組みを利用して、この問題を回避しています。

サーバ/サービス

サービス とは、何らかの処理を表わす用語です。このサービスを提供するものを サーバ と呼んでいます。

7.3 Kerberos の動作概要

Kerberos はしばしば、第三者の信頼による認証サービスとも呼ばれます。これは、全てのクライアントが他のクライアントの識別情報を判断する際、 Kerberos での判断結果を信頼して使用することから、そのように呼ばれています。 Kerberos では、全てのユーザに対する情報と、それに対応する機密鍵を保持するデータベースとなっています。

Kerberos を正しく動作させるためには、認証とチケット発行許諾サーバを専用のマシンで動作させるようにしてください。また、このマシンに対しては、物理的にもネットワーク経由でも、管理者のみがアクセスできるようにしてください。また、このマシンで動作させるサービスはごく限られたもののみとし、 sshd なども停止しておくことを強くお勧めします。

7.3.1 最初の通信

Kerberos に対する最初の通信は、一般的なネットワークシステムにおけるログイン処理に非常に似通っています。まずはユーザ名を入力します。この情報とチケット発行許諾サービスの名前が認証サーバ (Kerberos) に送信されます。認証サーバ側でユーザ名が既知のものであった場合は、クライアントとチケット発行許諾サーバとの間で使用される、乱数を利用したセッション鍵を発行します。あとは認証サーバがチケット発行許諾サーバに対するチケットを発行します。このチケットには下記のような情報が含まれていて、これら全てが認証サーバとチケット発行許諾サーバのみが知りうるセッション鍵で暗号化されます:

  • クライアントの名前とチケット発行許諾サーバの名前

  • 現在時刻

  • チケットの有効期限

  • クライアントの IP アドレス

  • 新しく生成されたセッション鍵

このチケットは、セッション鍵と共に暗号化された状態のまま、クライアント側に返却されます。ただし、この時点ではクライアントが使用する機密鍵を使用して暗号化を行います。機密鍵はユーザのパスワードを元にして作られるものであるため、 Kerberos とクライアントのみが知りうる情報となります。クライアント側では応答を受け取ったあと、利用者に対してパスワードを尋ねるようになります。クライアント内では、このパスワードを機密鍵に変換して、認証サーバから届いたデータを解読する処理を行います。必要な情報が 開梱できた あとは、パスワードを自身のメモリ内から消去します。チケット内には有効期間が示されていることから、この有効期間が切れるまでの間に新しいチケットの発行を要求することで、クライアント側は認証を必要な期間だけ使い続けられることになります。

7.3.2 サービスの要求

ネットワーク内のサーバが提供するサービスを利用するため、クライアント側のアプリケーションは、サーバに対して識別情報を提示する必要があります。そのため、アプリケーションはオーセンティケータを生成します。オーセンティケータには下記のような情報が含まれています:

  • クライアント側のプリンシパル

  • クライアントの IP アドレス

  • 現在時刻

  • チェックサム (クライアント側で選択)

これら全ての情報は、クライアント側で既に受信しているセッション鍵を利用して、暗号化が行われます。サーバ向けのオーセンティケータとチケットが揃ったら、あとはそれらをサーバに送信します。サーバはオーセンティケータを解読するためにセッション鍵のコピーを使用し、サービスを要求するクライアントに対して必要な情報を取得したあと、チケットに書かれている内容と比較します。これにより、サーバ側ではチケットとオーセンティケータが同じクライアントから送信されたものであるかを確認します。

サーバ側では特別なセキュリティを実装しない限り、この処理はリプレイ攻撃に対する標的となり得てしまいます。たとえば誰かが以前に送信したオーセンティケータとチケットを保存しておいて、後からそれを送信して認証をかいくぐる方法が考えられます。このような不正を防止する目的で、サーバ側では以前に受信したものと同じタイムスタンプのチケットは受け付けないようになっているほか、受信した時刻とタイムスタンプがあまりにも違いすぎる場合も、要求を受け付けないようになっています。

7.3.3 相互認証

Kerberos の認証は両方向に使用することができます。つまり、認証はクライアント側にだけ求められるものではありません。サーバ側でも、サービスを要求するクライアントに対して、自分自身を認証する必要があります。そのため、サーバ側ではオーセンティケータ自身を送信します。クライアント側のオーセンティケータのチェックサムに 1 を加えたあと、サーバとクライアントとの間で共有されているセッション鍵で暗号化を行います。クライアント側ではこの応答をもとに、サーバの正当性を確認して後続の処理を行うかどうかを判別します。

7.3.4 チケット発行許諾 - 全てのサーバへの通信

チケットは特定のサーバに対して使用するために設計されています。そのため、異なるサービスに接続する際には、新しいチケットの発行を受ける必要があります。 Kerberos では、それぞれのサーバに対するチケットを取得する仕組みが用意されています。このサービスを チケット発行許諾サービス と呼びます。チケット発行許諾サービスは、それ自身が (ここまでに説明しているのと同じ) サービスであり、ここまでの説明と同じプロトコルでアクセスを行います。アプリケーション側で新しいチケットが必要になると、チケット発行許諾サーバにアクセスを行います。このリクエストには下記のような情報が含まれています:

  • 要求者のプリンシパル

  • チケット発行許諾チケット

  • オーセンティケータ

他のサーバと同様に、チケット発行許諾サーバでもチケット発行許諾チケットと、オーセンティケータの内容を確認します。それらの情報がいずれも正当なものであった場合、チケット発行許諾サーバは元々のクライアントと新しく接続するサーバとの間で使用するセッション鍵を構築します。新しく接続するサーバに対するチケットには、下記のような情報が含まれています:

  • クライアント側のプリンシパル

  • サーバのプリンシパル

  • 現在時刻

  • クライアントの IP アドレス

  • 新しく生成されたセッション鍵

新しいチケットにも有効期間が設定されています。この有効期間はチケット発行許諾チケットと同じか、もしくはサービスごとの既定値のうち、いずれか早いほうが設定されます。クライアントは、チケット発行許諾サービスからこのチケットとセッション鍵を受け取ります。ただし、この時点では元々のチケット発行許諾チケットのセッション鍵で暗号化されています。そのため、クライアント側では利用者に対してパスワードを求めることなく、応答を解読できることになります。これにより、 Kerberos はユーザの手を煩わせることなくチケットを取得できることになります。

7.4 Kerberos のユーザ側からの見た目

ユーザ側からの見た目では、 Kerberos とのやり取りは端末のログイン時にのみ発生します。ログイン処理ではチケット発行許諾チケットの取得を行います。ログアウト時にはユーザ側の Kerberos チケットが自動的に破棄され、第三者が偽装することができないようにしています。

それぞれのチケットには有効期間が設定されているため、チケット発行許諾チケットに書かれた有効期間 (一般的には 10 時間程度) よりもユーザが長くログインしたままになることがあり得ます。しかしながら、ユーザ側では kinit を実行するだけで、新しいチケット発行許諾チケットを受け取ることができるようになっています。ここではパスワードを再入力することで、アクセス中の様々なサービスに対して個別に認証を行わずに済むようになっています。 Kerberos で暗黙のうちに取得できるチケットの一覧について、詳しくは klist を実行してください。

下記には Kerberos 認証を使用するアプリケーションの一覧を示します。これらのアプリケーションは krb5-apps-clients パッケージをインストールしたあと、 /usr/lib/mit/bin もしくは /usr/lib/mit/sbin 内にインストールされるものです。これらのソフトウエアには、一般的な Unix および Linux オペレーティングシステムでの全ての機能に加えて、 Kerberos による透過的な認証機構の機能が追加されています:

  • telnet , telnetd

  • rlogin

  • rsh , rcp , rshd

  • ftp , ftpd

  • ksu

これらのアプリケーションを使用する場合、 Kerberos 側で既に識別情報を確認済みであることから、さらにパスワードを入力する必要を無くすことができます。なお、 Kerberos に対応するよう ssh をコンパイルしてある場合、一方の端末で取得したチケットを他方の端末に転送することもできます。たとえば他のマシンにログインするために ssh を使用すると、 ssh が暗号化されたチケットの内容を必要に応じて調整する処理を行います。これは、チケットには端末固有の情報 (IP アドレスなど) が書かれているためです。 XDM や GDM でも Kerberos へのサポートが提供されています。 Kerberos に対応するネットワークアプリケーションについて、詳しくは https://web.mit.edu/kerberos にある Kerberos V5 UNIX User's Guide (英語) をお読みください。

7.5 Kerberos のインストールと管理

Kerberos の環境は複数のコンポーネントから構成されています。鍵配送センター (KDC) は、 Kerberos 関連のデータの全てを保持する中央データベースです。全てのクライアントからネットワーク経由で適切に認証を行うことができるようにするため、 KDC のデータに依存して動作するようになっています。 KDC とクライアントでは、お使いの環境に合わせて下記のような設定を行う必要があります:

一般的な準備

ネットワークの設定を確認し、 7.5.1項 「Kerberos ネットワークトポロジ」 で示されている最低要件を満たしていることをご確認ください。また、 7.5.2項 「Kerberos レルムの選択」 で説明している内容をもとに、 Kerberos を設定する際のレルムについても適切な値をご用意ください。 KDC として動作させるマシンについては、 7.5.3項 「KDC ハードウエアの設定」 の説明に従って注意深く設定を行ってください。さらに、ネットワーク内で正しく時刻が設定されるよう、 7.5.4項 「時刻同期の設定」 の手順に従って設定を行ってください。

基本的な設定

7.5.5項 「KDC の設定」7.5.6項 「Kerberos クライアントの設定」 の説明に従って、 KDC とクライアントを設定してください。 Kerberos サービスに対する遠隔からの管理を有効化し、 KDC マシンへの物理的なアクセスを不要にしたい場合は、 7.5.7項 「リモートからの Kerberos 管理の設定」 をお読みください。また、 7.5.8項 「Kerberos サービスプリンシパルの作成」 をお読みになって、レルム内に各サービスに対応するプリンシパルを作成してください。

Kerberos 認証の有効化

ネットワーク内にある様々なサービスが Kerberos に対応しています。 Kerberos のパスワードチェックを PAM 経由でアプリケーションに追加したい場合は、 7.5.9項 「Kerberos に対する PAM サポートの有効化」 の手順に従って設定を行ってください。また、 SSH や LDAP と Kerberos を設定したい場合は、 7.5.10項 「Kerberos 認証用の SSH の設定」7.5.11項 「LDAP と Kerberos の使用」 の説明に従って設定を行ってください。

7.5.1 Kerberos ネットワークトポロジ

Kerberos の環境を正しく完全に動作させるには、下記の要件を満たさなければなりません:

  • ネットワーク内に DNS サーバを用意して、クライアントとサーバの両方が名前で解決できるようにする必要があります。 DNS の設定について、詳しくは 第19章 「ドメインネームシステム をお読みください。

  • ネットワーク内にタイムサーバを用意してください。 Kerberos ではチケット内にタイムスタンプを書き込んで有効期限を管理するため、時刻を正しく設定しておくことが重要です。 NTP の設定について、詳しくは 第18章 「NTP を利用した時刻同期 をお読みください。

  • 鍵配送センター (KDC) は Kerberos の構造の中心に位置するものです。ここには Kerberos のデータベースが保存されます。このマシンに対しては最も厳しいセキュリティポリシーを適用してください。このマシンに対する攻撃が成功してしまうと、 Kerberos の構造全体に被害を及ぼしてしまいます。

  • クライアント側のマシンを設定して、 Kerberos の認証を使用するようにしてください。

下記の図に、 Kerberos のインフラストラクチャを構築するのに必要な、最小限のコンポーネントのみを配置した構成例を示します。実際の構成はネットワークの規模やトポロジに応じて決定してください。

Kerberos ネットワークトポロジ
図 7.1: Kerberos ネットワークトポロジ
ヒント
ヒント: サブネットルーティングの設定について

図7.1「Kerberos ネットワークトポロジ」 に示しているような構成を作成するには、 2 つのサブネット (192.168.1.0/24 および 192.168.2.0/24) の間を結ぶルータで、ルーティング (経路制御) を設定する必要があります。 YaST でルーティングを設定する場合は、 13.4.1.5項 「ルーティングの設定」 をお読みください。

7.5.2 Kerberos レルムの選択

Kerberos の世界では認証の管理単位をレルムと呼び、たとえば EXAMPLE.COM や単純に ACCOUNTING のように、名前を付けて区別します。 Kerberos は大文字と小文字を区別して扱う仕組みであることから、 example.comEXAMPLE.COM は別々のレルムとして扱われます。いずれかお好きなほうをお使いください。ただし、一般的には大文字のレルムを使用します。

また、レルムには DNS ドメイン名 (もしくは ACCOUNTING.EXAMPLE.COM のようなサブドメイン) を使用するのが一般的です。このような構成にすることで、 KDC やその他の Kerberos サービスを DNS ドメイン名と一括で管理できるようになります。また、レルム名を DNS ドメイン名のサブドメインにしておくと、将来の追加時に便利になることでしょう。

ただし、 DNS のドメイン名とは異なり、 Kerberos は階層構造にはなっていません。そのため、たとえば EXAMPLE.COM 以下に 下位のレルム として DEVELOPMENTACCOUNTING を作成しても、 EXAMPLE.COM のプリンシパルを引き継いで使用することはできません。このような構成では、 3 つの独立したレルムとして構成をすることになります。ただし、レルム間には相互認証を設定することができますので、一方のレルムに属するユーザがアクセスできるサーバが存在した場合、他方のレルムに属するユーザを許可するような設定を行うことができます。

なお、構成や説明をわかりやすくする目的から、下記の記述では組織内全体を表わすレルム EXAMPLE.COM を 1 つだけ使用するものとして説明を行います。

7.5.3 KDC ハードウエアの設定

Kerberos を使用するにあたって最初にすべきことは、鍵配送センター (KDC) として動作させるマシンの準備になります。このマシンには Kerberos のユーザデータベース (パスワードなどのユーザに関連する全ての情報) を保存します。

KDC はセキュリティインフラストラクチャで最も重要な構成部品です。そのセキュリティを突破されてしまうと、 Kerberos が保持し保護している全てのアカウント情報が漏洩することになってしまいます。また、漏洩した情報をもとに Kerberos 内の任意のユーザになりすますこともできてしまいます。そのため、このマシンに対するセキュリティは、最も強固な設定にしてください:

  1. サーバマシン自身を物理的に安全な場所に配置してください。ごく限られた人々のみが入室することのできる、施錠されたサーバルームなどが望ましいです。

  2. KDC 以外のネットワークアプリケーションを動作させてはなりません。サーバ機能もクライアント機能も KDC とは決して共存させないでください。具体的には、 NFS によるファイルシステムの取り込みや公開、 DHCP によるネットワーク設定の取得などを行ってはなりません。

  3. まずは最小限のシステムインストールを実施したあと、インストール済みのパッケージの一覧を確認して、不要なパッケージを削除してください。たとえば inetd , portmap , CUPS などは削除しておくべきですし、 X 関連のパッケージも削除しておいてください。また、 SSH サーバについても、潜在的なセキュリティリスクとなりますので、削除しておいてください。

  4. X サーバは潜在的なセキュリティリスクとなるものであるため、このマシンではグラフィカルログインを動作させないでください。 Kerberos では、専用の管理インターフェイスを提供しています。

  5. /etc/nsswitch.conf ファイルを編集して、ユーザとグループを検索する際にローカルファイルのみを使用するように設定してください。具体的には、 passwdgroup の行を下記のように設定します:

    passwd:         files
    group:          files

    /etc ディレクトリ内にある passwd , group , shadow の各ファイルを編集して、 + 文字で始まる行 (これらは NIS で使用していた項目です) を削除してください。

  6. /etc/shadow ファイルを編集して、 root 以外のアカウントを全て無効化するほか、ハッシュ化されたパスワードが書かれている箇所についても *! に置き換えてください。

7.5.4 時刻同期の設定

Kerberos を正しく動作させるには、組織内の全てのシステムの時刻の誤差が適切な範囲内に収まるよう、時刻を同期させる必要があります。これは他者が送信した認証情報を窃取したあと、再送信して権限を不正に得てしまうリプレイ攻撃を防ぐために重要となります。 Kerberos では、このような攻撃を防ぐための様々な仕組みを取り入れていますが、その中の 1 つに、チケット内にタイムスタンプを書き込む、というものがあります。サーバ側では、不正な再送信を防ぐため、現在時刻とは異なるタイムスタンプの書かれたチケットを拒否するようになっています。

もちろんネットワーク上を流れるにあたって、ある程度の時間は必要となることから、タイムスタンプの比較に際しても一定の猶予時間が設けられています。しかしながら、コンピュータの時計は、誤差という観点では非常に不正確なものです。 PC の時計が 1 週間のうちに 30 分程度進んだり遅れたりするようなことも、よくある話です。このような理由から、ネットワーク内の全てのコンピュータは、特定の中央の時刻情報源に対して同期を行う必要があります。

時刻同期を行うのに最も簡単な方法は、特定の 1 台のマシンに NTP タイムサーバをインストールして、残りのクライアントはその NTP タイムサーバに対して同期するように設定する方法です。同期する側のコンピュータについては、 NTP デーモンである chronyd をインストールして動作させることで、同期を行うことができます。なお、 KDC 自身も中央の時刻情報源と同期する必要があります。ただし、 KDC 自身で NTP デーモンを実行するのはリスクとなりうるため、 cron ジョブで chronyd -q を実行するよう設定するのが適切でしょう。 NTP クライアントの設定方法について、詳しくは 18.1項 「YaST を利用した NTP クライアントの設定」 をお読みください。

時刻同期を行うためのもう 1 つの方法としては、専用の NTP サーバを用意するか、もしくは KDC に直接電波時計や GPS 時計などのハードウエア時計を接続して時刻を管理する方法もあります。

なお、 Kerberos がタイムスタンプを比較する際の最大許容範囲を設定することもできます。 7.5.6.3項 「時計の許容誤差の設定」 の手順に従って、 krb5.conf ファイル内の clock skew の値を変更してください。

7.5.5 KDC の設定

本章では、 KDC の初期設定とインストール、そして管理者のプリンシパルを作成するまでの手順を説明しています。具体的には、下記のような流れで作業を行います:

  1. RPM のインストール: まずは KDC として動作させるマシンに、 krb5 , krb5-server , krb5-client のソフトウエアパッケージをインストールします。

  2. 設定ファイルの調整: 必要に応じて、 /etc/krb5.conf および /var/lib/kerberos/krb5kdc/kdc.conf の設定ファイルを編集します。これらのファイルには、 KDC 内の全ての情報が含まれています。詳しくは 7.5.5.1項 「サーバの設定」 をお読みください。

  3. Kerberos データベースの作成: Kerberos は全てのプリンシパルに対する情報と、認証時に使用する機密鍵を保持しています。詳しくは 7.5.5.2項 「データベースの設定」 をお読みください。

  4. ACL ファイルの調整: 管理者の追加: KDC 内の Kerberos データベースは、ネットワーク上離れた場所から管理することもできます。データベースに対して不正なアクセスがされないよう、 Kerberos ではアクセス制御リストを使用します。離れた場所から管理する場合は、データベースを管理することのできる管理者プリンシパルを明示的に指定しなければなりません。 Kerberos の ACL ファイルは、 /var/lib/kerberos/krb5kdc/kadm5.acl にあります。詳しくは 7.5.7項 「リモートからの Kerberos 管理の設定」 をお読みください。

  5. Kerberos データベースの調整: 管理者の追加: Kerberos を動作させて管理できるようにするには、 1 人以上の管理者プリンシパルを設定する必要があります。このプリンシパルは KDC を起動する前に追加しておかなければなりません。詳しくは 7.5.5.3項 「プリンシパルの作成」 をお読みください。

  6. Kerberos デーモンの起動: KDC ソフトウエアをインストールして設定が完了したら、 Kerberos デーモンを起動してレルムに対するサービス提供を開始します。詳しくは 7.5.5.4項 「KDC の起動」 をお読みください。

  7. プリンシパルの作成: あなた自身を表わすプリンシパルを作成します。詳しくは 7.5.5.3項 「プリンシパルの作成」 をお読みください。

7.5.5.1 サーバの設定

Kerberos サーバの設定は非常に柔軟な仕組みであり、お使いのネットワーク環境や DNS, DHCP のほか、レルムなどのさまざまな構成によって異なる設定になります。また、既定のレルムとドメイン-レルム間のマッピングを設定しなければなりません。なお、下記の設定例は必要最小限に絞った内容を示しているもので、そのままお使いいただけるものではありません。 Kerberos の設定について、詳しくは https://web.mit.edu/kerberos/krb5-latest/doc/admin/conf_files/index.html (英語) をお読みください。

例 7.1: KDC の設定例 (/etc/krb5.conf)
[libdefaults]
 dns_canonicalize_hostname = false
 rdns = false
 default_realm = example.com
 ticket_lifetime = 24h
 renew_lifetime = 7d

[realms]
  example.com = {
  kdc = kdc.example.com.:88
  admin_server = kdc.example.com
  default_domain = example.com
 }
 
 [logging]
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log
 default = SYSLOG:NOTICE:DAEMON

[domain_realm]
 .example.com = example.com
 example.com = example.com

7.5.5.2 データベースの設定

まずは Kerberos がプリンシパルに対する全ての情報を保存するための、データベースを準備します。また、特にテープメディアにバックアップを採取した場合など、不用意に漏洩してしまうような事態を避けるため、データベースのマスターキーを設定しておくこともお勧めします。マスターキーはパスフレーズから生成するもので、 stash と呼ばれるファイル内に補完されます。この仕組みにより、 KDC の起動時に毎回パスフレーズを入力しなくても済むようになっています。なお、書籍内の適当なページを開いて目に付いた文章など、適切なパスフレーズを設定するようにしてください。

また、 Kerberos データベース ( /var/lib/kerberos/krb5kdc/principal ) をバックアップする際には、 stash ファイル (たとえば /var/lib/kerberos/krb5kdc/.k5.EXAMPLE.COM など) は除外するように設定してください。 stash ファイルまでバックアップしてしまうと、そこから容易にデータベースを解読できてしまうからです。そのため、クラッシュ時に備えてパスフレーズを保管する際には、安全で機密を保持できる別の場所に配置するようにしてください。

stash ファイルとデータベースを作成するには、下記のように実行します:

tux > sudo kdb5_util create -r EXAMPLE.COM -s

実行すると、下記のように表示されるはずです:

Initializing database '/var/lib/kerberos/krb5kdc/principal' for realm 'EXAMPLE.COM',
master key name 'K/M@EXAMPLE.COM'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key:  1
Re-enter KDC database master key to verify:  2

1

マスターキー (パスフレーズ) を入力します。

2

パスフレーズを再度入力します。

構築されたデータベースを確認するには、下記のコマンドを実行します:

tux > kadmin.local

kadmin> listprincs

データベース内には既にいくつかのプリンシパルが存在していますが、これらは Kerberos 内部用のものです:

K/M@EXAMPLE.COM
kadmin/admin@EXAMPLE.COM
kadmin/changepw@EXAMPLE.COM
krbtgt/EXAMPLE.COM@EXAMPLE.COM

7.5.5.3 プリンシパルの作成

次に Kerberos のプリンシパルを 2 つ作成します。 1 つは通常時に利用するための個人用プリンシパル、もう 1 つは Kerberos の管理作業用に使用するプリンシパルです。たとえばログイン名が geeko であれば、下記のように実行します:

tux > kadmin.local

kadmin> ank geeko

実行すると、下記のように表示されるはずです:

geeko@EXAMPLE.COM's Password: 1
Verifying password: 2

1

geeko のパスワードを入力します。

1

geeko のパスワードを再度入力します。

次に、 kadmin のプロンプトで続けて ank geeko/admin と入力し、 geeko/admin というもう 1 つのプリンシパルを作成します。 admin という接尾辞を付けて、管理者の 役割 で使用するものであることを指定します。ここで指定した 役割 は、後ほどの手順で Kerberos データベースの管理者を指定する際に使用します。なお、ユーザに対してはそれぞれ別々の目的で設定した複数の役割を指定することができます。役割を指定したアカウントは、通常のものとは別のアカウントであるものとして扱われます。

7.5.5.4 KDC の起動

KDC デーモンと kadmin デーモンを起動します。デーモンを手作業で起動したい場合は、下記のように入力して実行してください:

tux > sudo systemctl start krb5kdc
sudo systemctl start kadmind

なお、マシンの起動時に ( krb5kdc ) と kadmind ( kadmind ) を自動的に開始するようにも設定してください。下記のように実行します:

tux > sudo systemctl enable krb5kdc kadmind

上記の方法以外にも、 YaST の サービスマネージャ を使用してもかまいません。

7.5.6 Kerberos クライアントの設定

対応するインフラストラクチャ (DNS, NTP) を用意し、 KDC を正しく設定して開始することができたら、あとはクライアント側のマシンの設定になります。 Kerberos のクライアントを設定するには、下記で説明している 2 つの手作業のうち、いずれかを実施してください。

Kerberos を設定するにあたっては、 2 種類のアプローチをとることができます。 1 つは /etc/krb5.conf ファイルを利用したクライアントごとの手動の設定方法、もう 1 つは DNS を利用した動的な設定方法です。 DNS を利用する場合、 Kerberos のアプリケーションは DNS レコードを利用して KDC サービスがどこにあるのかを判断します。クライアントごとの設定を行う場合は、 krb5.conf 内に KDC サーバのホスト名を設定します (この場合、 KDC を別のホストに移動させるには、設定ファイルの更新を行うか、その他の方法で再設定を行う必要があります) 。

DNS ベースの設定のほうがより柔軟な構成を取ることができるほか、クライアントごとの設定作業も大幅に削減することができます。ですが、レルム名と DNS ドメイン名が一致しているか、もしくはレルム名が DNS ドメインのサブドメインでなければならなくなります。それ以外にも、ネームサーバを攻撃してダウンさせてしまったり、 DNS レコードを偽装させたりするなどの方法で、 Kerberos のインフラストラクチャを混乱させることができてしまいます。とはいえ、最大限に攻撃が成功したとしても、サービスの提供を妨害するまでのことしかできませんし、クライアントごとの設定でも、 krb5.conf 内に IP アドレスではなくホスト名を記述してしまうと、 DNS への攻撃による妨害は発生しうることになります。

7.5.6.1 手動での設定

Kerberos の設定方法のうちの 1 つとして、 /etc/krb5.conf ファイルを編集する方法があります。このファイルは既定でインストールされるファイルで、いくつかの設定例が書かれています。設定を行う際には、これら全てを削除してから実施してください。また、 krb5.conf ファイルは複数のセクション (節) から構成されていますが、セクションは [this] のように、大括弧で括られて表わされます。

Kerberos クライアントを設定するには、下記のセクションを krb5.conf ファイルに追加します (なお、 kdc.example.com の箇所には、お使いの KDC のホスト名を入れてください):

[libdefaults]
        default_realm = EXAMPLE.COM

[realms]
        EXAMPLE.COM = {
                kdc = kdc.example.com
                admin_server = kdc.example.com
        }

上記の例の default_realm 行は、 Kerberos での既定のレルムを指定しています。複数のレルムを使用する場合は、 [realms] セクション内でそれぞれのレルムを設定してください。

また、このファイルでは、ホスト名とレルムをどのようにして対応づけるのかを設定することもできます。たとえばリモートのホストに接続する際、 Kerberos ライブラリ側ではそのホストがどのレルムに属しているのかを知る必要が発生するためです。この設定は [domain_realms] セクション内で設定しなければなりません:

[domain_realm]
.example.com = EXAMPLE.COM
www.example.org = EXAMPLE.COM

上記のように設定することで、 example.com の DNS ドメイン名のホストは EXAMPLE.COM の Kerberos レルムに属していることになります。これに加えて、 www.example.org というドメイン名のホストについても、 EXAMPLE.COM レルムのメンバーであることを宣言しています。

7.5.6.2 DNS ベースの設定

DNS ベースの Kerberos 設定では、 DNS の SRV レコードを多用します。詳しくは http://www.ietf.org にある (RFC2052) A DNS RR for specifying the location of services (サービスの場所を指定するための DNS 資源レコード) (英語) をお読みください。

Kerberos に関連する SRV レコードは、 _サービス._プロトコル.レルム の書式になっていなければなりません (レルム は Kerberos のレルムです) 。また、 DNS 内のドメイン名は大文字と小文字を区別しない仕組みであるため、区別する Kerberos ではこの方式がうまく動作しない場合があります。なお _サービス はサービス名 (KDC やパスワードサービスなどで別々の名前を使用します) 、 _プロトコル_udp もしくは _tcp のいずれかになります (ただし、全てのサービスが両方のプロトコルに対応しているとは限りません) 。

SRV リソースのデータ部分には、優先順位と重み、ポート番号とホスト名をそれぞれ設定します。優先順位は接続を試すべき順序 (低い値ほど優先度が高いことを表わします) を、重みは同じ優先順位内での負荷分散用の値を、それぞれ表わします。特に必要がなければ、いずれの値とも 0 に設定してかまいません。

MIT Kerberos では、サービスを参照する際に下記の名前を使用します:

_kerberos

KDC デーモン (認証サーバおよびチケット発行許諾サーバ) の場所を定義します。たとえば下記のように設定します:

_kerberos._udp.EXAMPLE.COM.  IN  SRV    0 0 88 kdc.example.com.
_kerberos._tcp.EXAMPLE.COM.  IN  SRV    0 0 88 kdc.example.com.
_kerberos-adm

リモート管理サービスの場所を定義します。たとえば下記のように設定します:

_kerberos-adm._tcp.EXAMPLE.COM. IN  SRV    0 0 749 kdc.example.com.

なお、 kadmind は UDP に対応していないため、 _udp のレコードは存在すべきではありません。

手動での設定と同様に、 example.com ドメイン以下に存在していないホストに対しても、 EXAMPLE.COM レルムの配下として設定する仕組みが用意されています。このような設定を行いたい場合は、 TXT レコードで _kerberos.ホスト名 のようなレコードを作成してください。たとえば下記のようになります:

_kerberos.www.example.org.  IN TXT "EXAMPLE.COM"

7.5.6.3 時計の許容誤差の設定

クロックスキュー とは、ホスト側のシステム時計と厳密に一致していないタイムスタンプを持つチケットに対して、どの範囲までを許容するのかを指定する項目です。通常、クロックスキューは 300 秒 (5 分) 程度に設定しておきます。この設定の場合、サーバの時計と比較して最大 5 分までの遅れ、および進みまでを許す意味になります。

NTP を利用して全てのホストの時刻同期を行う環境であれば、この値を 1 分程度にまで縮めることができます。この場合、 /etc/krb5.conf 内でのクロックスキューの設定は下記のようになります:

[libdefaults]
        clockskew = 60

7.5.7 リモートからの Kerberos 管理の設定

KDC のコンソールに直接アクセスすることなく、リモートから Kerberos のデータベースにプリンシパルを追加または削除できるようにするには、 Kerberos の管理サーバに対して、どのプリンシパルからの編集を許可するのかを /var/lib/kerberos/krb5kdc/kadm5.acl ファイルで設定します。このファイルは ACL (アクセス制御リスト) ファイルと呼ばれ、様々な操作に対して細かく権限を設定することができます。詳しくは man 8 kadmind で表示されるマニュアルページをお読みください。

ここでは、あなた自身に対してデータベースの管理者権限を割り当てます。具体的には、下記の内容をファイルに追加してください:

geeko/admin              *

なお、 geeko の箇所をあなた自身のユーザ名に置き換えてください。設定内容を反映させるには、 kadmind を再起動する必要があります。

これで kadmin ツールを利用して Kerberos の管理作業を行うことができるようになります。まずは管理者ロールに対するチケットを取得して、 kadmin サーバの接続時にそのチケットを使用します:

tux > kadmin -p geeko/admin
Authenticating as principal geeko/admin@EXAMPLE.COM with password.
Password for geeko/admin@EXAMPLE.COM:
kadmin:  getprivs
current privileges: GET ADD MODIFY DELETE
kadmin:

getprivs コマンドを使用すると、取得済みの権限を確認することができます。なお、上記に示されているもので全ての権限となります。

例として、 geeko のプリンシパルを編集します:

tux > kadmin -p geeko/admin
Authenticating as principal geeko/admin@EXAMPLE.COM with password.
Password for geeko/admin@EXAMPLE.COM:

kadmin:  getprinc geeko
Principal: geeko@EXAMPLE.COM
Expiration date: [never]
Last password change: Wed Jan 12 17:28:46 CET 2005
Password expiration date: [none]
Maximum ticket life: 0 days 10:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Wed Jan 12 17:47:17 CET 2005 (admin/admin@EXAMPLE.COM)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 2
Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt
Key: vno 1, DES cbc mode with CRC-32, no salt
Attributes:
Policy: [none]

kadmin:  modify_principal -maxlife "8 hours" geeko
Principal "geeko@EXAMPLE.COM" modified.
kadmin:  getprinc geeko
Principal: geeko@EXAMPLE.COM
Expiration date: [never]
Last password change: Wed Jan 12 17:28:46 CET 2005
Password expiration date: [none]
Maximum ticket life: 0 days 08:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Wed Jan 12 17:59:49 CET 2005 (geeko/admin@EXAMPLE.COM)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 2
Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt
Key: vno 1, DES cbc mode with CRC-32, no salt
Attributes:
Policy: [none]
kadmin:

上記の変更では、チケットの最大有効期限を 8 時間に変更しています。 kadmin コマンドに関する詳細や、利用可能なオプションの一覧については、 krb5-doc パッケージ、もしくは man 8 kadmin で表示されるマニュアルページをお読みください。

7.5.8 Kerberos サービスプリンシパルの作成

ここまではユーザ認証の部分のみを説明してきましたが、 Kerberos に対応するサービスでは、サービス側もクライアントに対して認証を行う必要があります。そのため、レルム内で提供されるサービスに対しては、サービスそのものを表わす特殊なサービスプリンシパルを Kerberos データベース内に作成しなければなりません。たとえば ldap.example.com が LDAP サービスを提供するような場合、 ldap/ldap.example.com@EXAMPLE.COM という名前のサービスプリンシパルを作成する必要があります。

サービスプリンシパルは サービス名/ホスト名@レルム の形式で表わします。ここで、 ホスト名 にはホストの完全修飾名を指定します。

利用可能なサービス名は下記のとおりです:

サービス記述子

サービス

host

Telnet, RSH, SSH

nfs

NFSv4 (Kerberos に対応しているもの)

HTTP

HTTP (Kerberos 認証の機能があるもの)

imap

IMAP

pop

POP3

ldap

LDAP

サービスプリンシパルはユーザプリンシパルと似ていますが、明らかな違いが存在しています。それは、サービスプリンシパルが鍵で保護されているのに対して、ユーザプリンシパルはパスワードで保護されているという点です。ユーザが KDC からチケット発行許諾チケットを取得した場合、 Kerberos 側でチケットを解読する際にパスワード入力が必要となります。この仕組みをそのままサービスプリンシパルにも適用してしまうと、たとえばシステム管理者が SSH デーモン向けのチケットを取得する目的で、 8 時間おきにパスワードを入力しなければならなくなってしまうため、現実的ではなくなってしまいます。

その代わり、サービスプリンシパルの場合は初期チケットの解読に鍵を使用するようになっています。鍵は管理者が KDC から一度だけ取り出したあと、 keytab と呼ばれるファイルに保存しておくものです。これにより SSH デーモンは鍵を読み込んで、必要なタイミングで新しいチケットを自動的に取得するようになります。既定の keytab ファイルは /etc/krb5.keytab にあります。

たとえば jupiter.example.com に対するホストサービスプリンシパルを作成したい場合は、 kadmin セッション内で下記のようにコマンドを入力します:

tux > kadmin -p geeko/admin
Authenticating as principal geeko/admin@EXAMPLE.COM with password.
Password for geeko/admin@EXAMPLE.COM:
kadmin:  addprinc -randkey host/jupiter.example.com
WARNING: no policy specified for host/jupiter.example.com@EXAMPLE.COM;
defaulting to no policy
Principal "host/jupiter.example.com@EXAMPLE.COM" created.

新しいプリンシパルに対してパスワードを設定する代わりに、 -randkey フラグを指定して、 kadmin でランダムな鍵を生成するように指定します。これは、このプリンシパルに対してユーザ操作を不要にするために必要なフラグとなります。これがマシンに対するサーバアカウントとなります。

最後に、鍵を抽出してローカルの keytab ファイル /etc/krb5.keytab に保管します。このファイルはスーパーユーザが所有するファイルであるため、下記の kadmin シェルを実行する際には、 root でなければなりません:

kadmin:  ktadd host/jupiter.example.com
Entry for principal host/jupiter.example.com with kvno 3, encryption type Triple
DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/jupiter.example.com with kvno 3, encryption type DES
cbc mode with CRC-32 added to keytab WRFILE:/etc/krb5.keytab.
kadmin:

全ての作業が完了したら、 kinit で取得した管理チケットを破棄するため、 kdestroy を実行します。

7.5.9 Kerberos に対する PAM サポートの有効化

警告
警告: 不完全な設定を行ってしまうとユーザが締め出されてしまう問題について

Kerberos を不完全に設定してしまうと、 root ユーザを含め全てのユーザが締め出されてしまうことがあります。このような問題が起こらないようにするには、既存の PAM 設定内に pam_krb5 を追加した あとpam_krb5 モジュールに ignore_unknown_principals ディレクティブを追加してください。具体的には、下記を実行します:

tux > sudo pam-config --add --krb5-ignore_unknown_principals

これにより、 pam_krb5 モジュールがアカウントフェーズの失敗を引き起こすいくつかのエラーを無視するようになります。

openSUSE® Leap には pam_krb5 と呼ばれる PAM モジュールが用意されています。このモジュールは Kerberos のログインとパスワード更新に対応しており、コンソールのログインや su 、もしくは GDM のようなグラフィカルログイン時に使用することができます。つまり、ユーザ側でパスワードを入力することで、ユーザに成り代わって初期の Kerberos チケットを取得するような、全ての用途に使用することができるモジュールです。 PAM で Kerberos に対応するように設定するには、下記のコマンドを実行します:

tux > sudo pam-config --add --krb5

上記のコマンドを実行すると、既存の PAM 設定ファイル内に pam_krb5 を追加し、適切な順序で呼び出されるように設定を調整します。 pam_krb5 に対してより詳しい設定を行いたい場合は、 /etc/krb5.conf ファイルを編集したあと、 PAM に既定のアプリケーションを追加してください。詳しくは man 5 pam_krb5 で表示されるマニュアルページをお読みください。

pam_krb5 モジュールは、 Kerberos のチケットをユーザ認証処理の一部として受け付けるような、ネットワークサービス向けには設計されていません。このような用途については、後続の章をお読みください。

7.5.10 Kerberos 認証用の SSH の設定

OpenSSH ではプロトコルバージョン 1 および 2 の両方で Kerberos 認証に対応しています。バージョン 1 では Kerberos のチケットを送信するための特殊なプロトコルメッセージが用意されています。バージョン 2 では Kerberos を直接使用するようなことは行っておらず、その代わりに GSSAPI (General Security Services API; 汎用セキュリティサービス API) を使用するようになっています。これは Kerberos 限定のプログラミングインターフェイスではなく、 SPKM のような公開鍵認証システムなどでも使用することのできる、下位の認証システムの特異性を隠蔽するように設計されたインターフェイスです。ただし、現時点では GSSAPI ライブラリは Kerberos のみに対応しています。

sshd で Kerberos 認証を使用するには、 /etc/ssh/sshd_config ファイルを編集して下記のオプションを追加します:

# 下記はプロトコルバージョン 1 用
#
# KerberosAuthentication yes
# KerberosTicketCleanup yes

# 下記はプロトコルバージョン 2 用 (こちらをお使いください)
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes

あとは sudo systemctl restart sshd を実行して、 SSH デーモンを再起動してください。

プロトコルバージョン 2 で Kerberos 認証を使用するには、クライアント側でも同様に有効化を行う必要があります。クライアント側ではシステム全体の設定ファイル /etc/ssh/ssh_config で設定することができるほか、 ユーザ単位でも ~/.ssh/config ファイルを編集することで設定を行うことができます。いずれのファイルの場合も、 GSSAPIAuthentication yes のオプションを追加することになります。

これで Kerberos 認証を使用して接続できるようになります。 klist を実行すると、有効なチケットの一覧を確認することができます。あとは SSH サーバに接続するだけです。 SSH プロトコルバージョン 1 を強制的に使用したい場合は、コマンドラインで -1 オプションを指定してください。

ヒント
ヒント: さらなる情報

/usr/share/doc/packages/openssh/README.kerberos ファイルには、 OpenSSH と Kerberos の関係について、より詳しい説明が書かれています。

ヒント
ヒント: プロトコルバージョン 2 向けの追加ディレクティブについて

GSSAPIKeyExchange の仕組み (RFC 4462) に対応しています。このディレクティブは、どのようにしてホスト鍵を交換するのかを指定します。詳しくは sshd_config のマニュアルページ ( man sshd_config ) をお読みください。

7.5.11 LDAP と Kerberos の使用

Kerberos が認証機能を提供するのに対して、 LDAP では認証と識別の両方を提供します。両方のサービスを同時に動作させることもできます。

接続の機密を保持する目的で、 389 Directory Server ではさまざまなデータの暗号化方式に対応しています。 SSL/TLS 接続や StartTLS 接続、そして SASL による認証にそれぞれ対応しています。Simple Authentication and Security Layer (SASL) は認証用に設計されたネットワークプロトコルです。 openSUSE Leap での SASL 実装は cyrus-sasl と呼ばれます。それに対して Kerberos 認証は、 cyrus-sasl-gssapi パッケージが提供する GSS-API (General Security Services API) で行われます。 GSS-API を使用することで、 389 Directory Server は Kerberos のチケットを利用して、セッションの認証とデータの暗号化を使用することができます。

SASL フレームワークを使用することで、サーバへの認証方式に異なる仕組みを使用することができます。たとえば Kerberos の場合、認証は常に相互的に動作します。つまり、 389 Directory Server サーバに対して認証を行っているだけでなく、 389 Directory Server 自身もあなたに対して認証を行っていることになります。これは特に、攻撃者が不正に作成した偽サーバにアクセスしたりせず、正しい LDAP サーバに接続していることを確認するために必要な仕組みです。

Kerberos から 389 Directory Server に接続するようにするには、 ldap/ldap.example.com というプリンシパルを作成して、それを keytab 内に追加する必要があります。 389 Directory Server が認証時に使用する認可情報は、 keytab によって他のサーバに送信されます。 389 Directory Server では keytab を KRB5_KTNAME という環境変数を介して割り当てます。

値を設定するには下記の手順を実施します:

  1. tux > sudo systemctl edit dirsrv@インスタンス名

    389 Directory Server の既定のインスタンス名を使用している場合は、 インスタンス名 の箇所を localhost にしてください。

  2. あとは下記を追加します:

    [Service]
      Environment=KRB5_KTNAME=/etc/dirsrv/slapd-インスタンス名/krb5.keytab
  3. keytab ファイルは 389 Directory Server の動作するアカウント (例: dirserv) が読み込めるようにする必要があります:

    tux > sudo chown dirsrv:dirsrv /etc/dirsrv/slapd-インスタンス名/krb5.keytab
    tux > sudo chmod 600 /etc/dirsrv/slapd-インスタンス名/krb5.keytab

7.5.11.1 LDAP を利用した Kerberos 認証の使用

チケット発行許諾チケットを取得およびキャッシュしたい場合は、 7.5.5.3項 「プリンシパルの作成」 で作成したプリンシパルをお使いください:

tux > kinit geeko@EXAMPLE.COM

GSSAPI 認証が動作していることを確認するには、下記の手順を実施します:

tux > ldapwhoami -Y GSSAPI -H ldap://ldapkdc.example.com
dn: uid=testuser,ou=People,dc=example,dc=com
    

GSSAPI は ccache を利用して 389 Directory Server サーバに対してユーザの認証を実施します。このとき、パスワードの入力は不要です。

7.5.11.2 SASL 識別子マッピングの設定

SASL バインド要求を処理する際、 389 Directory Server は SASL の認証 ID (ディレクトリサーバとの間で認証時に使用するもの) とサーバ内に保存されている LDAP エントリの紐付け (マッピング) を行います。 Kerberos を使用している場合、 SASL のユーザ ID は ユーザ_ID@レルム (例: tux@example.com) のような書式になります。 ID はディレクトリサーバ内のユーザの DN 、つまり uid=tux,ou=people,dc=example,dc=com などに変換されなければなりません。 389 Directory Server では、よくある構成向けの既定のマッピングが提供されていますが、必要であれば独自のマップを作成することもできます。 手順7.1「マップの管理」 では、マップの表示方法や削除方法、独自のマップを作成する方法について説明しています。

手順 7.1: マップの管理
  1. 既存の SASL マップを一覧表示するには、下記のように入力して実行します:

    tux > dsconf インスタンス名 sasl list
    Kerberos uid mapping
    rfc 2829 dn syntax
    rfc 2829u syntax
    uid mapping
  2. マップを表示するには、下記のように入力して実行します:

    tux > sudo dsconf インスタンス名 sasl get "Kerberos uid mapping"
    dn: cn=Kerberos uid mapping,cn=mapping,cn=sasl,cn=config
    cn: Kerberos uid mapping
    nsSaslMapBaseDNTemplate: dc=\2,dc=\3
    nsSaslMapFilterTemplate: (uid=\1)
    nsSaslMapRegexString: \(.*\)@\(.*\)\.\(.*\)
    objectClass: top
    objectClass: nsSaslMapping
  3. 既定のマップでは、お使いの環境の dc が 2 つのコンポーネントから構成されている場合にのみ動作します。 (お使いの環境に合わないなどの理由で) マップを削除するには、下記のように入力して実行します:

    tux > sudo dsconf インスタンス名 sasl delete "Kerberos uid mapping"
    Deleting SaslMapping cn=Kerberos uid mapping,cn=mapping,cn=sasl,cn=config :
    Successfully deleted cn=Kerberos uid mapping,cn=mapping,cn=sasl,cn=config
  4. 新しいマップを作成するには、下記のように入力して実行します:

    tux > sudo dsconf localhost sasl create --cn=bhgssapi --nsSaslMapRegexString "\
    (.*\)@EXAMPLE.NET.DE" --nsSaslMapBaseDNTemplate="dc=example,dc=net,dc=de" --nsSaslMapFilterTemplate="(uid=\1)"
    tux > sudo Enter value for nsSaslMapPriority :
    Successfully created bhgssapi
  5. 新しく作成したマップを表示するには、下記のように入力して実行します:

    tux > sudo dsconf localhost sasl get "bhgssapi"
    dn: cn=bhgssapi,cn=mapping,cn=sasl,cn=config
    cn: bhgssapi
    nsSaslMapBaseDNTemplate: dc=example,dc=net,dc=de
    nsSaslMapFilterTemplate: (uid=\1)
    nsSaslMapPriority: 100
    nsSaslMapRegexString: \(.*\)@EXAMPLE.NET.DE
    objectClass: top
    objectClass: nsSaslMapping

    これを利用することで、特定のレルムのユーザのみをチェックして、異なる dc ベースに再マップすることができるようになります。既にご存じのとおり、新しいマップには 3 つの dc コンポーネントが存在していますので、既定のマップはこのレルム ( EXAMPLE.NET.DE ) では動作せず、 EXAMPLE.NET のようなレルムでのみ動作します。

7.6 Kerberos と NFS

ほとんどの NFS サーバでは、 sec=sys として知られている ネットワークベースの信頼 と、 sec=krb5 , sec=krb5i , sec=krb5p として知られている 3 種類の Kerberos ベースのセキュリティを任意に組み合わせてファイルシステムを公開することができます。sec オプションはクライアント側のマウントオプションとして指定します。 NFS サービスによっては、いったん sec=sys を利用して設定および接続を行い、その後 Kerberos を適用するものもあります。この場合、サーバ側では sec=sys といずれかの Kerberos レベルの両方に対応するよう設定されたあと、全てのクライアントを遷移させてから sec=sys サポートを無効化してください。これにより、セキュリティを確実にすることができます。なお、 Kerberos への遷移は手順通り行われる限り、完全に透過的に動作します。しかしながら、 NFS 側には微妙な動作の違いが存在することもありますので、 Kerberos を使用した場合にはうまくいかないこともあります。そのため、 NFS サーバを Kerberos で使用するにあたっては、詳細をよくご確認のうえ設定を行う必要があります。詳しくは 7.6.1項 「グループのメンバー」 をお読みください。

3 種類の Kerberos レベルは、それぞれ異なるセキュリティレベルを構成します。セキュリティレベルを高めれば高めるほど、メッセージの暗号化や解読に際してプロセッサの処理能力が必要になります。 NFS 向けに Kerberos を開放するにあたっては、双方で適切なバランスを保つよう選択してください。

krb5 は認証機能のみを提供します。サーバはリクエストを送信した相手を知っていますし、クライアントは応答を送ったサーバを知っています。ただし、リクエストや応答の内容に対する追加のセキュリティ機能は提供されないため、様々な方法でサーバやクライアントになりすますことができてしまいます。認証済みのユーザが読み込んだり変更したりできなかったファイルに対して、攻撃者が読み込んだり変更したりすることはできませんが、それ以外のほぼ全てのことができてしまいます。

krb5i は全てのメッセージに対してチェック機能を追加します。 krb5i では、攻撃者がリクエストや応答を書き換えたりすることができなくなりますが、交換されているデータは全て盗聴できてしまいます。そのため、読み込んでいるファイルの内容などは容易に盗聴できてしまいます。

krb5p はプロトコルにプライバシー機能を追加します。信頼性のある認証機能とチェック機能に加えて、全てのメッセージが暗号化されます。そのため、攻撃者はサーバとクライアントとの間でメッセージが交換されていることを知ることはできますが、メッセージ内に直接含まれている情報は抽出できなくなります。なお、メッセージのタイミングから、どのような状況にあるのかは推測できてしまいますが、こちらは Kerberos では対応のできない範疇外のものとなります。

7.6.1 グループのメンバー

sec=sys と Kerberos のセキュリティレベルとの間で、動作が大きく異なるのは、グループのメンバー関係に関する箇所です。 Unix や Linux では、ファイルシステムへのアクセスはプロセスから届くものであり、そのプロセスには特定のユーザとグループが結びつけられています。また、ユーザは複数のグループに対するメンバーとなることができます。このような仕組みから、ファイルへのアクセス権は所有者とグループをベースにして行われます。

sec=sys を指定した場合、ユーザ ID とグループ ID 、そして最大 16 種類までの補助グループが、各リクエスト内に書き込まれてサーバ側に送られます。

ユーザが 16 種類以上のグループに対するメンバーである場合、それより多くのグループ情報は失われます。そのため、通常はユーザからアクセスできていたはずのファイルに対して、 NFS 経由にするとアクセスができなくなってしまうことがあります。このような理由から、 NFS を使用する場合は、最大でも 16 種類までの補助グループとなるよう、うまく構成して回避を行ってください。

ユーザが newgrp コマンドや set-group-id のプログラムを実行すると、いずれのコマンドとも所属するグループのリストを変更することができますので、これによって NFS へのアクセス結果が即時に変わることがあります。

なお、 Kerberos ではグループに関する情報は全く送信されません。ユーザが (Kerberos の プリンシパル で) 認証されると、ユーザ ID とそのプリンシパルに対するグループリストを元にして、検索を行うだけです。つまり、ユーザが 16 種類以上のグループに対するメンバーであった場合、ファイルへのアクセス許可判断は、それら全てのグループメンバー情報をもとに行われることになります。しかしながら、ユーザがクライアント側でグループ ID を変更しても、サーバ側にはその変更が送信されないため、アクセス権の判断には影響しません。

多くの場合、多数のグループにアクセスできるようになったことで、大きな利益がもたらされますが、グループが変更できなくてもあまり実害はありません。ただし、 Kerberos を使用しているサイトの管理者はその情報を認識し、実際に問題を引き起こしたりすることがないようご注意ください。

7.6.2 性能とスケーラビリティ

セキュリティ確保の目的で Kerberos を使用すると、メッセージの暗号化や解読に際して、 CPU の負荷がかかるようになります。どれだけの CPU 性能が必要かや、通常時と比べてどれだけ負荷が高くなるのかは、ハードウエアや用途によって大きく異なります。もしもサーバやクライアント側の CPU 性能が限界に達しているような場合は、 sec=sys を Kerberos に切り替えることで、顕著な性能劣化が現われることになります。 CPU の性能に余裕がある場合であれば、この移行作業で性能が変わることはありません。 Kerberos を使用することによる性能変化は、実際のハードウエアと環境でテストしてお確かめください。

負荷を軽減するための唯一の選択は、保護品質の設定です。 sec=krb5p よりも sec=krb5 のほうがずっと負荷の軽い処理になりますが、上述のとおり強力な機密保持は行われなくなります。それ以外にも、 Kerberos が利用する暗号化方式を変更する手もあります。これによって CPU 要件をより低減させることができます。とはいえ、変更することによる影響をよくよくご検討のうえ、変更を行ってください。

NFS で Kerberos を使用するように設定する際の性能問題という観点では、 KDC (鍵配送センター) として知られている Kerberos の認証サーバの可用性についてもご検討ください。

NFS を使用すると、他のサービスに対して Kerberos を使用すると負荷が増えるのと同様に、ある程度の負荷上昇が発生します。あるユーザ (Kerberos のプリンシパル) がサービスに対してセッションを確立した場合、たとえば特定の NFS サーバが公開するファイルにアクセスした場合、クライアントは KDC との間でやり取りを実施する必要があります。やり取りの結果セッション鍵を取得できれば、サーバとクライアントはしばらく直接やり取りできるようになります。これは Kerberos の設定である ticket_lifetime の設定に依存して決まります。

Kerberos の KDC サーバの配置を設計するのに重要な項目は、可用性とピーク使用量です。

DNS や LDAP などの名前検索サービスなどの他のコアサービスと KDC サーバとの間は適度に "近く" なるように設計し、各クライアントに対する適度な可用性を提供するようにしてください。 Kerberos ではデータベースの伝搬のために柔軟なモデルを採用しているため、複数の KDC サーバを用意することができます。これにより、キャンパス単位やビル単位、キャビネット単位でも、必要なサーバをわかりやすく配置することができます。それぞれのクライアントが近くにある Kerberos サーバを検出できるようにするための適切な方式として、それぞれのビルなどに DNS を水平展開して、それぞれで異なる応答をするように設定するやり方があります。このような方式を採用できない場合は、 /etc/krb5.conf ファイルをビルごとに別々の値にするなどして、適度に分散させるように設計してください。

Kerberos KDC へのアクセスはあまり頻繁に発生しないことから、負荷として考慮すべきことはピークタイムとなります。たとえば 9:00 から 9:05 の間に多くの人々がログインするような場合、夜間に比べるとその時間帯は非常に多くの毎分リクエストを受け付けることになります。 Kerberos サーバの負荷は LDAP サーバの負荷よりも高くなりやすいのですが、桁違いというほどではありません。一般的には、 LDAP のレプリカと同じやり方で Kerberos のレプリカを配置したあと、さらにサーバを増設する必要があるかどうかを性能監視で判断するのが良いでしょう。

7.6.3 マスター KDC/複数ドメイン/信頼関係

Kerberos KDC のサービスは、パスワードの変更や新しいユーザの作成などの処理を扱う必要があることから、容易には分散させることができません。これらの処理は、単一のマスター KDC で行わなければなりません。

これらに対する更新処理はそれほど多く発生しないため、負荷に対する要件もあまり厳しくありません。ですが、可用性という観点は重視する必要があります。可用性を考慮しておかないと、新しいユーザを作成したりパスワードを変更したりする際に時間がかかる場合があるほか、拠点によっては一時的にマスター KDC にアクセスできなくなってしまうこともあります。

組織が地理的に分散しているような場合で、各拠点に対する管理作業を拠点内で実施するような場合、それぞれ別々の Kerberos ドメインを作成して、それぞれの管理センターを 1 台ずつ構成するのがよいでしょう。それぞれのドメイン (拠点) には、それぞれのマスター KDC が存在することになります。一方のドメイン内のユーザが他のドメイン内のリソースにアクセスする場合でも、ドメイン間の信頼関係を設定することで解決することができます。

複数ドメインを扱う際の最も簡単な方法は、グローバルドメイン (例: EXAMPLE.COM) とローカルドメイン (例: ASIA.EXAMPLE.COM, EUROPE.EXAMPLE.COM など) をそれぞれ構築する方法です。グローバルドメインはそれぞれのローカルドメインを信頼するように設定し、それぞれのローカルドメインはグローバルドメインを信頼するように設定すれば、任意のドメイン間で完全な信頼を実現できますので、どのドメインに属するプリンシパルであっても、任意のサービスを利用できるようになります。なお、リソースに対して適切なアクセス許可を設定する作業については、ユーザ名の参照方法や NFS ファイルサーバの機能によって異なりますので、ここでは説明していません。

7.7 さらなる情報

MIT Kerberos の公式サイトは https://web.mit.edu/kerberos にあります。ここには Kerberos のインストールから利用、管理ガイドに至るまで、様々な Kerberos の情報に対するリンクが提供されています。

Kerberos—ネットワーク認証システム (Brian Tung (原著), 桑村 潤 (翻訳)) (ISBN 978-4894711464) には、幅広い情報が含まれています。

このページを印刷