第 12 章 SEAM (参照)

この章では、SEAM 製品に組み込まれている多数のファイル、コマンド、およびデーモンについて一覧表示します。また、Kerberos 認証システムの機能についても詳細に説明します。

この章の内容は次のとおりです。

• 「SEAM ファイル」

• 「SEAM コマンド」

• 「SEAM デーモン」

• 「SEAM の用語」

• 「認証システムの動作方法」

• 「SEAM によるサービスへのアクセス」

• 「gsscred テーブルの使用」

SEAM ファイル

PAM 構成ファイル

デフォルトの PAM 構成ファイルは、認証サービス、アカウント管理、セッション管理、およびパスワード管理モジュールのエントリで構成されます。

認証モジュールの場合は、SEAM 1.0 または SEAM 1.0.1 がインストールされているときに、 rlogin、login、および dtlogin の新しいエントリが作成されます。これらのエントリの例を、以下に示します。これらのサービスはすべて PAM ライブラリ /usr/lib/security/pam_krb5.so.1 を使用して Kerberos 認証を行います。

これらのエントリでは try_first_pass オプションが使用されています。この場合、ユーザーの最初のパスワードを使用して認証が行われます。最初のパスワードを使用すると、複数のメカニズムが記述されていても、ユーザーは別のパスワードを入力する必要がありません。

# cat /etc/pam.conf
 .
 .
rlogin auth optional /usr/lib/security/pam_krb5.so.1 try_first_pass
login auth optional /usr/lib/security/pam_krb5.so.1 try_first_pass
dtlogin auth optional /usr/lib/security/pam_krb5.so.1 try_first_pass
other auth optional /usr/lib/security/pam_krb5.so.1 try_first_pass

アカウント管理モジュールの場合、Kerberos ライブラリを使用する dtlogin の新しいエントリが次のように作成されます。other エントリはデフォルトの規則を提供するために 1 つ含まれています。現時点では、other エントリによって何の動作も行われません。

dtlogin account optional /usr/lib/security/pam_krb5.so.1 
other account optional /usr/lib/security/pam_krb5.so.1

次に /etc/pam.conf ファイルの最後の 2 つのエントリを示します。セッション管理の other エントリではユーザー資格を破棄します。パスワード管理の新しい other エントリでは Kerberos ライブラリを選択します。

other session optional /usr/lib/security/pam_krb5.so.1 
other password optional /usr/lib/security/pam_krb5.so.1 try_first_pass

SEAM コマンド

この節では、SEAM 製品に含まれているコマンドの一部を示します。

SEAM デーモン

次の表は、SEAM 製品で使用されるデーモンの一覧です。

SEAM の用語

この節では、用語とその定義について説明します。これらの用語は、SEAM のマニュアル全体で使用されます。SEAM の概念を理解するには、これらの用語を理解する必要があります。

Kerberos 固有の用語

KDC を管理するには、この節で説明する用語を理解する必要があります。

「鍵配布センター (Key Distribution Center、KDC)」は、資格の発行を担当する SEAM の構成要素です。資格は、KDC データベースに格納されている情報に基づいて作成されます。各レルムには 2 つ以上の KDC サーバー (マスターと 1 つ以上のスレーブ) が必要です。すべての KDC が資格を生成できますが、KDC データベースを変更できるのはマスター KDC だけです。

KDC のマスター鍵を暗号化したコピーは「stash ファイル」に含まれます。サーバーがリブートされると、この鍵を使用して KDC が自動的に認証されて、kadmind と krb5kdc コマンドが起動されます。このファイルにはマスター鍵が入っているため、このファイルやバックアップは安全な場所に保管する必要があります。暗号が破られると、この鍵を使用して KDC データベースのアクセスや変更が可能になります。

認証固有の用語

認証処理を理解するには、この節で説明する用語を理解する必要があります。プログラマやシステム管理者はこれらの用語に精通している必要があります。

「クライアント」は、ユーザーのワークステーションで動作するソフトウェアです。クライアントで動作する SEAM ソフトウェアは、処理中に多数の要求を作成します。このため、SEAM ソフトウェアとユーザーの動作を区別することが重要です。

「サーバー」と「サービス」はよく同じ意味で使われます。明確に定義すると、「サーバー」は、SEAM ソフトウェアが動作する物理システムです。「サービス」は、サーバー上でサポートされる特定の機能 (nfs など) です。サーバーがサービスの一部として記述されることがよくありますが、これはこれらの用語の定義をあいまいにします。このマニュアルでは、サーバーという用語は、物理システムを指し、サービスという用語は、ソフトウェアを指します。

SEAM 製品には 3 種類の鍵があります。1 つは「非公開鍵」です。この鍵は各ユーザー (主体) に与えられ、主体のユーザーと KDC だけに知られています。ユーザー主体に対しては、鍵はユーザーのパスワードに基づいています。サーバーとサービスに対する鍵は「サービス鍵」と呼ばれます。サービス鍵は非公開鍵と同じ目的で使われますが、これはサーバーとサービスによって使用されます。3 つ目の鍵は「セッション鍵」です。セッション鍵は、認証サービスまたはチケット認可サービスによって生成されます。セッション鍵は、クライアントとサービス間のトランザクションのセキュリティを保護するために生成されます。

「チケット」は、ユーザーの識別情報をサーバーやサービスに安全に渡すために使用される情報パケットです。チケットは、単一クライアントと特定サーバー上の特定サービスだけに有効です。チケットには、サービスの主体名、ユーザーの主体名、ユーザーのホストの IP アドレス、タイムスタンプ、チケットの有効期限を定義する値などが含まれます。チケットは、クライアントとサービスによって使用されるランダムセッション鍵を使用して作成されます。チケットは、作成されてから有効期限まで再使用できます。

「資格」は、対応するセッション鍵とチケットを含む情報パケットです。一般に資格は、資格を暗号化するソフトウェアにより、非公開鍵かサービス鍵を使用して暗号化されます。

「オーセンティケータ（authenticator)」はさらに別の種類の情報です。これをチケットとともに使用すると、ユーザー主体の認証に使用できます。オーセンティケータには、ユーザーの主体名、ユーザーのホストの IP アドレス、タイムスタンプが含まれます。チケットとは異なり、オーセンティケータは一度しか使用できません。通常、サービスへのアクセスが要求されたときに使用されます。オーセンティケータは、そのクライアントとそのサーバーのセッション鍵を使用して暗号化されます。

チケットの種類

チケットには、チケットがどのように使用されるかを決めるプロパティがあります。これらのプロパティは、チケットの作成時にチケットに割り当てられます。ただし、チケットのプロパティはあとから変更できます。たとえば、チケットのプロパティを「転送可能」から「転送済み」に変更できます。チケットのプロパティを表示するには、klist コマンドを使用します (「チケットを表示する方法」 を参照)。

チケットは、次の 1 つまたは複数のプロパティで表されます。

転送可能 / 転送済み

転送可能チケットはホストからホストに転送されます。これによって、クライアントは再び認証を受ける必要がありません。たとえば、ユーザー david がユーザー jennifer のマシンで転送可能チケットを取得した場合、david は自分のマシンにログインするときに新しいチケットを取得する必要はありません (再び認証を受けることもありません)。転送可能チケットの例については、「例 - チケットを作成する」 を参照してください。

初期

初期チケットは、チケット認可チケットを使わずに直接発行されるチケットです。パスワードを変更するアプリケーションなどの一部のサービスでは、クライアントが非公開鍵を知っていることを確認するために、「初期」と指定されたチケットを要求することができます。初期チケットは、チケット認可チケットを使用せずに、クライアントが最近認証されたことを証明します。チケット認可チケットの場合は、認証されてから時間が経っている可能性があります。

無効

無効チケットは、まだ使用可能になっていない遅延チケットです。無効チケットは、有効になるまでアプリケーションサーバーから拒否されます。これを有効にするには、開始時期が過ぎたあと、TGS 要求で VALIDATE フラグをオンにしてクライアントがこのチケットを KDC に提示する必要があります。

遅延可能 / 遅延

遅延チケットは、作成されても指定された時期まで有効にならないチケットです。たとえばこのようなチケットは、夜遅く実行するバッチジョブに使用するのに便利です。チケットが盗まれてもバッチジョブが実行されるまで使用できないためです。遅延チケットは無効チケットとして発行され、開始時期がきてクライアントが KDC から検証を受けるまでは、無効チケットのままです。遅延チケットは通常、チケット認可チケットの有効期限まで有効です。ただし、チケットに「更新可能」が指定されている場合、その有効期限は通常、チケット認可チケットの有効期限に設定されます。

プロキシ可能 / プロキシ

場合によっては、サービスがそれ自身のために操作できることが主体にとって必要な場合があります。たとえば、主体がサービスを要求して、サーバーとクライアント以外のホストで印刷ジョブを実行するとします。サービスにはクライアントの ID を使用する権限が必要になりますが、その権限はこの操作だけに制限する必要があります。その場合、サービスは、クライアントの「プロキシ」として動作するといいます。チケットを作成するときには、プロキシの主体名を指定する必要があります。

「プロキシ可能」チケットは「転送可能」チケットに似ていますが、プロキシ可能チケットが 1 つのサービスに対してだけ有効であることに対し、転送可能チケットはサービスに対しクライアントの識別情報の完全な使用を許可します。したがって、転送可能チケットは一種のスーパープロキシと考えられます。

更新可能

チケットに非常に長い有効期限を与えるとセキュリティを損なうおそれがあるため、チケットを「更新可能」にすることができます。更新可能チケットには 2 つの有効期限があります。1 つはチケットの現在のインスタンスの有効期限で、もう 1 つは任意のチケットの最長有効期限です。クライアントがチケットの使用を継続したいときは、最初の有効期限が切れる前にチケットの有効期限を更新します。たとえば、すべてのチケットの最長有効期限が 10 時間のときに、あるチケットが 1 時間だけ有効だとします。このチケットを保持するクライアントが 1 時間を超えて使用したい場合は、その時間内にチケットの有効期限を更新する必要があります。チケットが最長有効期限 (10 時間) に達すると、チケットの有効期限が自動的に切れ、それ以上更新できなくなります。

チケットを表示してその属性を見る方法については、「チケットを表示する方法」を参照してください。

チケットの有効期限

主体がチケットを取得すると、チケット認可チケットであっても、チケットの有効期限は次の中で最も小さい値に設定されます。

• kinit を使用してチケットを取得する場合、kinit の -l オプションに指定した有効期限値

• kdc.conf ファイルで指定される最長有効期限値 (max_life)

• チケットを提供するサービス主体に対し Kerberos データベースに指定されている最長有効期限値。 kinit の場合、サービス主体は krbtgt/realm

• チケットを要求するユーザー主体に対し Kerberos データベースに指定されている最長有効期限値

図 12-1 は、TGT の有効期限の決定方法と 4 つの有効期限値の指定元を示しています。この図は TGT の有効期限がどのようにして決まるかを示しますが、基本的には、どの主体がチケットを取得する場合でも同じです。違いは、kinit で有効期限値を指定しないことと、krbtgt/realm 主体の代わりに、チケットを提供するサービス主体が最長有効期限値を提供することです。

図 12-1 TGT の有効期限の決定方法

「更新可能」チケットの有効期限も次の 4 つの最小値で決まります。ただし、この場合は更新可能有効期限が使用されます。

• kinit を使用してチケットを取得または更新する場合、kinit の -r オプションに指定した更新可能有効期限値

• kdc.conf ファイルに指定された更新可能最長有効期限値 (max_renewable_life)

• チケットを提供するサービス主体に対し Kerberos データベースに指定されている更新可能最長有効期限値。 kinit の場合、サービス主体は krbtgt/realm

• チケットを要求するユーザー主体に対し Kerberos データベースに指定されている更新可能最長有効期限値

主体名

チケットは主体名で識別され、主体名はユーザーやサービスを識別します。次の表に主体名の例を示します。

認証システムの動作方法

アプリケーションを使用してリモートシステムにログインするには、識別情報を証明するチケットとそれに対応するセッション鍵を指定する必要があります。セッション鍵には、ユーザーやアクセスするサービスに特有の情報が含まれています。ユーザーすべてのチケットとセッション鍵は、ユーザーが最初にログインするときに KDC によって作成されます。チケットとそれに対応するセッション鍵が 1 つの資格となります。複数のネットワークサービスを使用する場合には、ユーザーは多数の資格を収集できます。ユーザーは特定のサーバーで動作するサービスごとに 1 つの資格を必要とします。たとえば、boston というサーバー上の ftp サービスにアクセスするには 1 つの資格が必要です。別のサーバー上の ftp サービスにアクセスするには、別の資格が必要です。

資格の作成や格納は透過的に行われます。資格は KDC によって作成され、要求者に送信されます。資格は、受信されると資格キャッシュに格納されます。

SEAM によるサービスへのアクセス

特定のサーバー上の特定のサービスにアクセスする場合、ユーザーは 2 つの資格を取得する必要があります。最初は TGT として知られるチケット認可サービスに対する資格です。チケット認可サービスは、この資格の暗号を解除すると、ユーザーからアクセスを要求されているサーバーの資格をさらに作成します。ユーザーは、この 2 つめの資格を使用してサーバー上のサービスへのアクセスを要求します。サーバーがこの資格の暗号を解除すると、ユーザーはアクセスを許可されます。次の節では、このプロセスを詳細に説明します。

チケット認可サービスに対する資格の取得

1. 認証処理を開始するために、クライアントが特定のユーザー主体の要求を認証サーバーに送信します。この要求の送信では暗号は使用されません。要求にはセキュリティにかかわる情報が含まれていないため、暗号を使う必要はありません。

2. 認証サービスは要求を受信すると、ユーザーの主体名を KDC データベースから検索します。一致する主体が見つかると、認証サービスはその主体の非公開鍵を取得します。次に認証サービスは、クライアントとチケット許可サービスが使用するセッション鍵 (セッション鍵 1) とチケット許可サービス用のチケット (チケット 1) を生成します。このチケットはチケット認可チケット (TGT) ともいいます。セッション鍵とチケットはユーザーの非公開鍵を使って暗号化され、情報がクライアントに返送されます。

3. クライアントは、ユーザー主体の非公開鍵を使用して、この情報からセッション鍵 1 とチケット １ の暗号を解除します。非公開鍵を知っているのはユーザーと KDC データベースだけである必要があるため、パケットの情報は安全に保たれなければなりません。クライアントはこの情報を資格キャッシュに格納します。

この処理中に、ユーザーは通常、パスワードを要求されます。非公開鍵を作成するために KDC データベースから取り出されたパスワードが、入力したパスワードと同じであると、認証サービスから送信された情報は正しく復号化されます。これでクライアントは、チケット許可サービスに対して使用する資格を取得します。次にクライアントはサーバーに対する資格を要求します。

図 12-2 チケット許可サービスに対する資格の取得

サーバーに対する資格の取得

1. 特定のサーバーにアクセスするには、クライアントがその前にサーバーに対する資格を認証サービスから取得している必要があります。「チケット認可サービスに対する資格の取得」 を参照してください。次にクライアントは、チケット許可サービスに要求を送信します。この要求には、サービス主体名、チケット 1 およびセッション鍵 1 で暗号化されたオーセンティケータが含まれています。チケット 1 は、チケット許可サービスのサービス鍵を使用して認証サービスによって暗号化されたものです。

2. チケット許可サービスはチケット許可サービスのサービス鍵を知っているため、チケット 1 の暗号を解除できます。チケット 1 の情報にはセッション鍵 1 が含まれているため、チケット許可サービスはオーセンティケータの暗号を解除できます。この時点で、ユーザー主体はチケット許可サービスによって認証されます。

3. 認証が正常に終了すると、チケット許可サービスは、ユーザー主体とサーバーに対するセッション鍵 (セッション鍵 2) とサーバーに対するチケット (チケット 2) を生成します。次にセッション鍵 2 とチケット 2 はセッション鍵 1 を使って暗号化されます。セッション鍵 1 を知っているのはクライアントとチケット許可サービスだけであるため、この情報は安全であり、ネットワークを介して安全に送信されます。

4. クライアントはこの情報パケットを受信すると、前に資格キャッシュに格納したセッション鍵 1 を使用して情報を復号化します。クライアントは、サーバーに対して使用する資格を取得したことになります。次にクライアントは、そのサーバーの特定のサービスにアクセスする要求を行います。

図 12-3 サーバーに対する資格の取得

特定のサービスへのアクセス権の取得

1. クライアントが特定のサービスへのアクセスを要求するには、まず認証サーバーからチケット許可サービスに対する資格を取得し、チケット許可サービスからサーバー資格を取得する必要があります。「チケット認可サービスに対する資格の取得」 および 「サーバーに対する資格の取得」 を参照してください。クライアントは、チケット 2 と別のオーセンティケータを含む要求をサーバーに送信します。オーセンティケータはセッション鍵 2 を使用して暗号化されます。

2. チケット 2 は、サービスのサービス鍵を使用してチケット許可サービスによって暗号化されています。サービス鍵はサービス主体が知っているため、サービスはチケット 2 を復号化し、セッション鍵 2 を取得できます。次に、セッション鍵 2 を使用してオーセンティケータが復号化されます。オーセンティケータが正しく復号化されると、サービスへのアクセスがクライアントに許可されます。

図 12-4 特定のサービスへのアクセス権の取得

gsscred テーブルの使用

gsscred テーブルは、NFS サーバーが SEAM ユーザーを識別するときに使用します。NFS サービスは、UNIX ID を使用してユーザーを識別します。UNIX ID は、ユーザー主体または資格には含まれません。gsscred テーブルは、パスワードファイルから得られる UNIX ID と主体名を割り当てるテーブルです。このテーブルは、KDC データベースを生成したあとに作成および開始する必要があります。

クライアントの要求が到着すると、NFS サービスは主体名を UNIX ID に割り当てようとします。この割り当てに失敗した場合、gsscred テーブルが参照されます。kerberos_v5 メカニズムでは、root/hostname 主体は自動的に UID 0 に割り当てられるため、gsscred テーブルは参照されません。したがって、gsscred テーブルを使用して root を特別な UID に割り当てることはできません。