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

11.1.2. Kerberos プリンシパル名

プリンシパルはユーザーまたはサービスだけでなく、エンティティーが属するレルムも特定します。プリンシパル名は、識別子とレルムの 2 つの部分で構成されます。 
identifier@REALM
ユーザーの場合、識別子 は Kerberos ユーザー名のみになります。サービスの場合、識別子 はサービス名と、それが実行するマシンのホスト名の組み合わせです。 
service/FQDN@REALM
サービス名は 、ホスト、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 サーバーは解決されたホスト名 のチケットを要求するため、ホストプリンシパルは host/ である必要があります。

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 資料」 Kerberos 表11.2「重要な Kerberos man ページ」。
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] クライアントとサーバーの両方が共通の鍵を共有しているシステム。これは、ネットワーク通信の暗号化および復号化に使用されます。
このページには機械翻訳が使用されている場合があります (詳細はこちら)。