Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

第11章 Kerberos の使用

ネットワーク内でシステムのセキュリティーと整合性を維持することは重要です。また、ネットワークインフラストラクチャー内のすべてのユーザー、アプリケーション、サービス、およびサーバーが含まれます。これには、ネットワーク上で実行中のすべての内容と、これらのサービスが使用される仕組みを理解する必要があります。このセキュリティーの維持の中核となるのは、これらのアプリケーションおよびサービスへの アクセス の維持と、そのアクセスの実施です。
Kerberos は、通常のパスワードベースの認証よりもはるかに安全な認証プロトコルです。Kerberos では、他のマシンでサービスにアクセスした場合でも、パスワードがネットワーク経由で送信されることはありません。
Kerberos は、ユーザーとマシンの両方がネットワークに対して自らを識別し、管理者が設定した領域およびサービスへの定義済みかつ制限されたアクセスを受け取れるようにするメカニズムを提供します。Kerberos はアイデンティティーを確認してエンティティーを認証します。また、Kerberos はこの認証データも保護し、外部からアクセス、使用、改ざんされないようにします。

11.1. Kerberos について

Kerberos は対称キー暗号を使用して[3] ネットワークサービスに対してユーザーを認証します。つまり、パスワードがネットワーク上で送信されることはありません。
そのため、ユーザーが Kerberos を使用してネットワークサービスに対して認証を行う際に、ネットワークトラフィックを監視してパスワードの収集を図っている不正なユーザーを効果的に阻止することができます。

11.1.1. Kerberos の仕組みの基本

従来の多くのネットワークサービスは、パスワードベースの認証スキームを使用しており、ユーザーは特定のネットワークサーバーにアクセスするためのパスワードを提供します。ただし、多くのサービスに対する認証情報の送信は暗号化されません。このようなスキームをセキュアにするには、ネットワークを外部からアクセスできないようにする必要があり、ネットワーク上のすべてのコンピューターおよびユーザーが信頼でき、信頼できるものでなければなりません。
シンプルなパスワードベースの認証では、インターネットに接続されているネットワークが安全であると想定することはできません。ネットワークへのアクセスを取得する攻撃者は、シンプルなパケットアナライザー (パケットスニッファー) を使用してユーザー名とパスワードを傍受し、ユーザーアカウントを破ります。そのため、セキュリティーインフラストラクチャー全体の整合性が保たれます。
Kerberos はネットワーク経由で暗号化されていないパスワード送信をなくし、攻撃者がネットワークを傍受する潜在的脅威を取り除きます。
シンプルなパスワード認証で各ユーザーを個別に認証するのではなく、Kerberos は対称暗号化と信頼できるサードパーティー (キー配布センター KDC) を使用してユーザーをネットワークサービスのスイートに対して認証します。その KDC とセカンダリー KDC が管理するコンピューターが レルム を設定します。
ユーザーが KDC に対して認証を行うと、KDC はそのセッションに特定した認証情報のセット (チケット) をユーザーのマシンに送り返します。Kerberos 対応のサービスでは、ユーザーがパスワードを使用して認証する必要はなく、サービスすべてがユーザーのマシン上でこのチケットを探します。
図11.1「Kerberos 認証」 にあるように、各ユーザーは プリンシパル と呼ばれる一意のアイデンティティーで KDC に識別されます。Kerberos 対応のネットワーク上のユーザーがワークステーションにログインすると、認証サーバーから ticket-granting ticket (TGT) の要求の一部としてプリンシパルが KDC に送信されます。この要求は、ログインプログラムによりユーザーに対して透過されるようにしたり、ユーザーがログインした後に kinit プログラムを介して手動で送信したりできます。
次に KDC はデータベース内でプリンシパルをチェックします。プリンシパルが見つかると、KDC は TGT を作成し、ユーザーのキーを使用してこれを暗号化し、TGT をそのユーザーに送信します。

図11.1 Kerberos 認証

Kerberos 認証
クライアント上のログインまたは kinit プログラムはユーザーの鍵を使用して TGT を復号化します。これは、ユーザーのパスワードから計算します。ユーザーのキーはクライアントマシン上でのみ使用され、ネットワーク上では送信されません。KDC によって送信されるチケット (または認証情報) は、ローカルストアである 認証情報キャッシュ (ccache) に保存され、Kerberos 対応のサービスで確認できます。Red Hat Enterprise Linux 7 では、以下のタイプの認証情報キャッシュがサポートされます。
  • Red Hat Enterprise Linux 7 のデフォルトのキャッシュである KEYRING ccache タイプ
  • System Security Services Daemon (SSSD) Kerberos Credential Manager (KCM) (Red Hat Enterprise Linux 7.4 の代替オプション)
  • FILE
  • DIR
  • MEMORY
SSSD KCM では、Kerberos キャッシュはパッシブストアに保存されず、デーモンにより管理されます。この設定では、通常は kinit などのアプリケーションが使用する Kerberos ライブラリーは KCM クライアントであり、デーモンは KCM サーバーと呼ばれます。
SSSD KCM デーモンが管理する Kerberos 認証情報キャッシュには、以下のような利点があります。
  • デーモンはステートフルであり、Kerberos 認証情報キャッシュの更新や古い ccache の取得などのタスクを実行できます。更新と追跡は、SSSD 自体が (通常はpam_sss.soを介したログインを介して) 取得したチケットだけでなく、たとえばkinit を介して取得したチケットでも可能です。
  • プロセスはユーザースペースで実行されるため、カーネル KEYRING とは異なり、UID 名前空間の影響を受けます。
  • 呼び出し元の UID に完全に依存し、コンテナー化された環境ではすべてのコンテナー間で共有されるカーネル KEYRING ベースのキャッシュとは異なり、KCM サーバーのエントリーポイントは、選択したコンテナーにのみバインドマウントできる UNIX ソケットです。
認証後、サーバーは、kinit ではなく、認識されたプリンシパルとそのキーの暗号化されていないリストをチェックできます。これは キータブ に保持されます。
TGT は、一定期間 (通常は 10 から 24 時間) の後に期限切れに設定され、クライアントマシンの認証情報キャッシュに保存されます。セキュリティーの破られた TGT が攻撃者に利用される時間を短くするために、有効期限が設定されています。TGT の発行後、TGT の有効期限が切れるまで、もしくはログアウトして再度ログインするまで、ユーザーはパスワードを再入力する必要はありません。
ユーザーがネットワークサービスにアクセスする必要がある場合、クライアントソフトウェアは TGT を使用して ticket-granting サーバー (TGS) からその特定のサービスの新しいチケットを要求します。サービスチケットはその後、そのサービスに対して透過的にユーザーを認証するために使用されます。

11.1.2. Kerberos プリンシパル名について

プリンシパルはユーザーやサービスだけでなく、そのエンティティーが属するレルムも特定します。プリンシパル名は、識別子とレルムの 2 つからなります。 
identifier@REALM
ユーザーの場合、識別子 は Kerberos ユーザー名のみになります。サービスの場合、識別子 はサービス名と、それが実行するマシンのホスト名の組み合わせです。 
service/FQDN@REALM
サービス名は、host、ldap、http、DNS など、サービスタイプに固有の大文字と小文字を区別する文字列です。すべてのサービスに明らかなプリンシパル識別子があるわけではありません。たとえば、sshd デーモンはホストサービスプリンシパルを使用します。
ホストプリンシパルは通常、/etc/krb5.keytab に保存されます。
Kerberos がチケットを要求する際は常に、ドメイン名のエイリアス (DNS CNAME レコード) を対応する DNS アドレス (A または AAAA レコード) に解決します。アドレスレコードからのホスト名は、サービスまたはホストプリンシパルが作成される際に使用されます。
以下に例を示します。 
www.example.com		CNAME		web-01.example.com
web-01.example.com		A		192.0.2.145
サービスは、ホストの CNAME エイリアスを使ってホストに接続を試みます。 
$ ssh www.example.com
Kerberos サーバーは解決されたホスト名 web-01.example.com@EXAMPLE.COM のチケットを要求するため、ホストプリンシパルは host/web-01.example.com@EXAMPLE.COM である必要があります。

11.1.3. ドメインからレルムへのマッピング

クライアントが特定サーバー上で実行中のサービスにアクセスしようとする際は、サービス名 (ホスト) とサーバー名 (foo.example.com) は分かっていますが、ネットワーク上には複数のレルムが導入されることが可能なので、クライアントはサービスが存在する Kerberos レルムの名前を推測する必要があります。
デフォルトでは、レルム名はサーバーのドメイン名をすべて大文字にしたものになります。 
foo.example.org → EXAMPLE.ORG
foo.example.com → EXAMPLE.COM
foo.hq.example.com → HQ.EXAMPLE.COM
設定によっては、これで十分ですが、派生したレルム名は存在しないレルムの名前になります。このような場合は、サーバーの DNS ドメイン名からレルムの名前へのマッピングをクライアントシステムの /etc/krb5.conf の domain_realm セクションで指定する必要があります。以下に例を示します。 
[domain_realm]
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM
この設定では、2 つのマッピングを指定します。最初のマッピングは、example.com DNS ドメイン内のシステムが EXAMPLE.COM レルムに属することを指定します。2 つ目は、名前が example.com のシステムがレルムにあることを指定します。ドメインと特定ホストの違いは、最初のピリオド記号の有無でマークされます。たとえば、"_kerberos TXT" レコードを使用して、マッピングを DNS に直接保存することもできます。 
$ORIGIN example.com
_kerberos		TXT	"EXAMPLE.COM"

11.1.4. 環境要件

Kerberos ではマシン名を解決できる必要があります。そのため、DNS(ドメインネームサービス) が必要です。ネットワーク上の DNS エントリーとホストの両方を適切に設定する必要があります。これは、/usr/share/doc/krb5-server-version-number の Kerberos ドキュメンテーションで説明されています。
Kerberos 認証を受け入れるアプリケーションには、時間同期が必要です。ntpd などのサービスを使用して、ネットワーク上のマシン間のクロック同期を概算することができます。ntpd サービスの詳細は、/usr/share/doc/ntp-version-number/html/index.html または ntpd(8) man ページを参照してください。
注記
Red Hat Enterprise Linux 7 を実行している Kerberos クライアントは、KDC の自動調整をサポートします。したがって、タイミングの要件は厳格ではありません。これにより、Red Hat Enterprise Linux 7 で IdM クライアントをデプロイする際のクロッキングの違いに対する耐性が向上します。

11.1.5. Kerberos 導入における考慮点

Kerberos は一般的かつ重大なセキュリティーの脅威を排除しますが、以下のような理由から実装は容易ではありません。
  • Kerberos は、各ユーザーが信頼されていて、信頼できないネットワーク上で信頼できないホストを使用していることを前提としています。その主な目的は、暗号化されていないパスワードがそのネットワーク上で送信されないようにすることです。ただし、認証に使用されるチケットを発行するホスト (KDC) に適切なユーザー以外のユーザーがアクセスすると、Kerberos 認証システム全体が危険にさらされます。
  • アプリケーションが Kerberos を使用するには、そのソースを変更して Kerberos ライブラリーに適切な呼び出しを行う必要があります。この方法で変更したアプリケーションは、Kerberos 対応 として考慮されます。アプリケーションによっては、アプリケーションのサイズや設計により、非常に問題になる場合があります。その他の互換性のないアプリケーションでは、サーバーとクライアントが通信する方法に変更を加える必要があります。ここでも、大幅なプログラミングが必要になる場合があります。デフォルトでは Kerberos サポートのないクローズソースアプリケーションは、多くの場合最も問題となります。
  • Kerberos でネットワークの安全を図るには、暗号化されていないパスワードを送信する すべての クライアントアプリケーションおよびサーバーアプリケーションのバージョンで Kerberos 対応のものを使用するか、そのようなクライアントアプリケーションおよびサーバーアプリケーションをまったく使用しないかのどちらかにする必要があります。
  • /etc/passwd や /etc/shadow などの標準の UNIX パスワードデータベースから Kerberos パスワードデータベースにユーザーパスワードを移行することはできます。このタスクを実行する自動メカニズムはありません。移行方法は、Kerberos のデプロイ方法によって大きく異なる可能性があります。このため、Identity Management 機能を使用することが推奨されます。これには、移行用の特別なツールおよびメソッドがあります。
警告
ネットワーク上のユーザーが Kerberos 以外の対応サービスに対してパスワードをプレーンテキストで送信して認証すると、Kerberos システムが危険にさらされる可能性があります。Kerberos 以外の対応サービス (telnet や FTP など) の使用は強く推奨されません。SSH や SSL で保護されたサービスなどの他の暗号化プロトコルは暗号化されていないサービスよりも推奨されますが、これは理想的ではありません。

11.1.6. Kerberos に関するその他のリソース

Kerberos は、デプロイ方法に柔軟性が高い、実装する複雑なサービスになります。表11.1「外部の Kerberos 資料」 および 表11.2「重要な Kerberos の man ページ」 では、Kerberos の使用に関する詳細情報で、最も重要なソース、または最も有用なソースの一覧を記載しています。
man ページのファイルは、man command_name を実行して開きます。

表11.2 重要な Kerberos の man ページ

man ページ 説明
クライアントアプリケーション
Kerberos Kerberos システムの概要では、認証情報がどのように機能するかを説明し、Kerberos チケットの取得および破棄に関する推奨事項を提供します。man ページの下部では、関連する man ページが多数参照されています。
kinit このコマンドを使用して ticket-granting ticket を取得、キャッシュする方法が説明されています。
kdestroy このコマンドを使用して Kerberos 認証情報を破棄する方法が説明されています。
klist このコマンドを使用して、キャッシュされた Kerberos 認証情報を一覧表示する方法が説明されています。
管理アプリケーション
kadmin このコマンドを使用して Kerberos V5 データベースを管理する方法が説明されています。
kdb5_util このコマンドを使用して Kerberos V5 データベース上で低レベルの管理機能を作成、実行する方法が説明されています。
サーバーアプリケーション
krb5kdc Kerberos V5 KDC に利用可能なコマンドラインオプションが説明されています。
kadmind Kerberos V5 管理サーバー に利用可能なコマンドラインオプションが説明されています。
設定ファイル
krb5.conf Kerberos V5 ライブラリー用の設定ファイル内で利用可能な形式とオプションを説明しています。
kdc.conf Kerberos V5 AS および KDC 用の設定ファイル内で利用可能な形式とオプションを説明しています。

[3] クライアントとサーバーの両方が共通の鍵を共有しているシステム。これは、ネットワーク通信の暗号化と復号化に使用されます。