第11章 Kerberos の使用

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

11.1. Kerberos について

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

11.1.1. Kerberos の基本的な仕組み

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

図11.1 Kerberos 認証の場合

次にクライアント上のログインもしくは kinit プログラムがユーザーの鍵を使って TGT を暗号解除します。ユーザーの鍵は、ログインもしくは kinit プログラムがユーザーのパスワードから計算します。ユーザーの鍵はクライアントマシン上でのみ使用され、ネットワーク経由では送信されません。KDC が送信したチケット (または認証情報) はローカルストアである 認証情報キャッシュ (ccache) に保存されます。Kerberos 対応サービスはこのキャッシュをチェックすることができます。Red Hat Enterprise Linux 7 では、以下のタイプの認証情報キャッシュに対応しています。
  • 永続的な KEYRING ccache タイプ (Red Hat Enterprise Linux 7 のデフォルトキャッシュ)
  • 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 の切り取りなどのタスクを実行できます。更新および追跡は、pam_sss.so を通過したログインを経由して SSSD 自体が取得したチケットに対してのみだけでなく、取得したチケット (たとえば kinit を経由して) にも可能です。
  • プロセスがユーザ空間で動作するため、カーネルの KEYRING とは異なり、UID 名前空間の対象となります。
  • (呼び出し元の UID に完全に依存し、コンテナー環境ではすべてのコンテナー間で共有されている) カーネルの KEYRING ベースのキャッシュとは異なり、KCM サーバーのエントリーポイントは、選択したコンテナーにのみバインドマウントできる UNIX ソケットです。
認証後は、サーバーは kinit を確認するのではなく、認識されたプリンシパルとそれらの鍵の暗号化されていないリストをチェックできます。このリストは keytab に保持されます。
TGT は特定期間の後に (通常は 10 から 24 時間) 有効期限が切れるように設定され、クライアントマシンの認証情報キャッシュに保存されます。TGT に期限が設定されているのは、攻撃者が TGT を使用できる期間を短時間にするためです。TGT の発行後は、TGT の有効期間が切れるまで、またはユーザーがログアウトして再度ログインするまで、ユーザーはパスワードを再入力する必要がありません。
ユーザーがネットワークサービスにアクセスする必要がある場合は、クライアントのソフトウェアは TGT を使って ticket-granting サーバー (TGS) から該当サービス用の新規チケットを要求します。サービスチケットは該当サービスに対するユーザーの認証を透過的に行うために使用されます。

11.1.2. Kerberos プリンシパル名

プリンシパルはユーザーやサービスだけでなく、そのエンティティーが属するレルムも特定します。プリンシパル名は、識別子とレルムの 2 つからなります。 
identifier@REALM
ユーザーの場合は identifier は Kerberos ユーザー名のみで、サービスの場合は identifier はサービス名と当該サービスが実行されているマシンのホスト名を組み合わせたものです。 
service/FQDN@REALM
service 名は、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 は、各ユーザーは信頼されているものの、信頼できないネットワーク上で信頼できないホストを使用していることを想定しています。Kerberos の第一の目的は、暗号化されていないパスワードをネットワーク経由で送信されないようにすることです。ただし、認証に使用されるチケットを発行するあるホスト (KDC) に正当なユーザー以外の誰かがアクセスすると、Kerberos 認証システム全体が危険にさらされます。
  • アプリケーションが Kerberos を使用するには、そのソースを修正して Kerberos ライブラリーに適切な呼び出しを行う必要があります。このような修正を受けたアプリケーションは、Kerberos に対応している とみなされます。アプリケーションのなかには、そのサイズやデザインが理由でこれが問題になるものもあります。また、互換性のない他のアプリケーションでは、サーバーとクライアントが通信する方法を変更する必要があります。これはかなり大量のプログラミングが必要になる可能性があります。多くの場合、デフォルトで Kerberos 対応となっていないクローズソースのアプリケーションが最も問題のあるものとなります。
  • Kerberos でネットワークの安全を図るには、暗号化されていないパスワードを送信するすべての クライアント/サーバーアプリケーションのバージョンで Kerberos 対応のものを使用するか、そのようなクライアント/サーバーアプリケーションをまったく使用しないかのどちらかにする必要があります。
  • /etc/passwd や /etc/shadow といった標準 UNIX パスワードデータベースから Kerberos パスワードデータベースへのユーザーパスワードの移行は、面倒な作業になります。このタスクを実行する自動メカニズムはありません。移行方法は、Kerberos を導入する方法によって大幅に異なります。Identity Management 機能の使用が推奨されるのは、このためです。これには移行のための特別のツールとメソッドが備わっています。

警告

ネットワーク上のユーザーが Kerberos 非対応サービスに対してプレーンテキストでパスワードを送信すると、Kerberos システムは危険にさらされます。(telnet および FTP を含む) Kerberos 非対応サービスを使用しないことが強く推奨されます。SSH や SSL でセキュアとなったサービスのような他の暗号化プロトコルは暗号化されていないサービスよりは優れているものの、それでも理想的なものではありません。

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

Kerberos の導入には柔軟性があることから、その実装は複雑なサービスとすることが可能です。表11.1「外部の Kerberos 資料」 と 表11.2「Kerberos man の重要なページ」 では、Kerberos の使用に関する詳細情報で最重要もしくは最も有益なソースを一覧表示しています。
man ページのファイルは、man command_name を実行すると開きます。

表11.2 Kerberos man の重要なページ

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

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