# 管理の手引き

# サーバー暗号化鍵の管理

この章では、AFS でのセキュア通信に欠かせない、所属するセルのサーバー暗号化鍵の管理方法について説明します。

## 説明の要約

この章では、以下のタスクを、その隣に示されたコマンドを使用して実行するための方法について説明します。

新規サーバー暗号化鍵を追加する | bos addkey および kas setpassword
認証データベース内の鍵のチェックサムを検査する | kas examine
KeyFile 内の鍵のチェックサムを検査する | bos listkeys
古いサーバー暗号化鍵を削除する | bos removekey

## サーバー暗号化鍵について

暗号化鍵は、情報のパケットを暗号化および複号するために使用する 8 進数のストリングです。AFS では、サーバー暗号化鍵は、AFS サーバー・プロセスとそのクライアント間で転送される情報を保護するために使用される鍵です。サーバー暗号化鍵は、本質的にサーバー・プロセスに対するパスワードであり、ユーザー・パスワードと同様に認証データベースに保管されます。

AFS ファイル・スペース内の情報を権限のないユーザーのアクセスから保護する最も基本的な方法は、セルのサーバー暗号化鍵を適切に管理することです。

### 鍵および相互認証: 概要

サーバー暗号化鍵は、 AFS 内のクライアントとサーバー・プロセスとの間の相互認証において中心的な役割を果たします。相互認証の詳細な説明については、相互認証の詳細を参照してください。

クライアントが AFS サーバーと通信する場合、クライアントはまず認証サーバーのチケット付与サービス (TGS) モジュールと通信します。TGS は、クライアントの確認検査 (間接的にそのクライアントが表す人物のパスワードに基づく) を行った後で、クライアントにサーバー・チケットを付与します。このチケットは、サーバーの暗号化鍵によって暗号化されます。 (TGS はまた、 セッション鍵 と呼ばれる 2 番目の暗号化鍵を作成し、サーバーとクライアント間の単一の通信に使用します。サーバー・チケットおよびセッション鍵は、その他の情報も含めて、一まとまりでトークンとして言及されます。)

クライアントは、サーバー暗号化鍵を知らないため、サーバー・チケットを読み取ることができません。ただし、クライアントはサーバー・チケットと一緒にサービス要求を AFS サーバーに送信します。これは、サーバー・チケットがクライアントが既に TGS によって認証されていることを AFS サーバー・プロセスに示すからです。 AFS サーバーは、TGS が有効なクライアントのみにチケットを付与することに依存しています。クライアントがサーバーの暗号化鍵で暗号化されたチケットを持っているという事実は、そのクライアントが有効であることをサーバーに対して示します。一方、クライアントは、本物の AFS サーバーのみがチケットを複号するために必要なサーバー暗号化鍵を知っていることを前提とします。チケットを復号し、その内容を理解するサーバーの機能は、サーバーが本物であるとクライアントに証明するものです。

### AFS サーバー暗号化鍵の保守

セルのサーバー暗号化鍵の保守にあたっては、以下に留意してください。

- 鍵は頻繁に変更して、セルのセキュリティーを向上させてください。少なくとも、 1 月に一度は鍵を変更するよう強くお勧めします。
- 現在使用されている AFS サーバー暗号化鍵は、2 箇所に保管されます。新規に鍵を追加する場合は、両方の場所で変更を行い、かつ正しい順序で変更する必要があります (指示については、サーバー暗号化鍵の追加 を参照)。指示に従わないと、セルの機能を著しく損なうことになり、クライアントおよびサーバーが通信できなくなります。現在のサーバー暗号化鍵の記憶セルは、以下のとおりです。

  1. すべてのファイル・サーバー・マシンのローカル・ディスク上のファイル /usr/afs/etc/KeyFile。ファイルには複数の鍵がリストでき、それぞれに関連した数値識別子の 鍵バージョン番号 または kvno が付きます。クライアント・トークンは、その暗号化に使用したキーのバージョン番号を記録し、サーバー・プロセスは、クライアントがトークンを示す際に、このファイルから該当する鍵を検索します。
  2. 認証データベース内の afs 項目。現行のサーバー暗号化鍵は、個々のユーザーのスクランブル・パスワードと同様、項目のパスワード・フィールドにあります。認証サーバーのチケット付与サービス (TGS) は、この鍵を使用して、クライアントに付与するトークンを暗号化します。この項目には 1 つの鍵のみが存在します。これは、TGS は既存のトークンを読み取る必要はなく、現行の鍵を使用して新規鍵を作成するためです。

  セルの最初のサーバー・マシンを作成する際の、初期 afs 項目、および KeyFile ファイルの作成に関する説明は、 AFS インストールの手引き を参照してください。

- いずれの特定時においても、認証サーバーのチケット付与サービスがクライアントに与えるトークンは、 1 つのサーバー暗号化鍵のみによって暗号化されます。これはつまり、認証データベースの afs 項目に保管される鍵です。
- 新規のサーバー暗号化鍵を追加する場合、それぞれの AFS サーバー・マシンのローカル・ディスクの /usr/afs/etc/KeyFile ファイルから即時に以前の鍵を削除することはできません。新規鍵を追加するいずれの場合も、まだ有効で期限が切れていないトークン (前の鍵で暗号化した) を持つクライアントが存在する可能性があります。サーバー暗号化鍵を頻繁に変更すればするほど、そのようなチケットが存在する可能性が高くなります。このようなトークンを持つクライアントに対し適切にサービスを付与するために、 AFS サーバー・プロセスは、その暗号化に使用したサーバー暗号化鍵にアクセスが可能である必要があります。

  古いサーバー暗号化鍵を安全に削除できるのは、この鍵で暗号化したトークンを持つクライアントが存在しないことが確認できた場合のみです。少なくとも一般に、セル内でのトークンの最大の存続時間の間は待つようにします。デフォルトでは、最大トークン存在時間は 25 時間です (認証データベースの項目が AFS バージョン 3.0 を使用して作成されたユーザーのデフォルトは 100 時間であり、このようなユーザーは除きます)。 -lifetime 引き数を kas setfields コマンドで使用することにより、このデフォルトを変更することができます。

  古い鍵の削除に関する説明は、サーバー暗号化鍵の削除 を参照してください。

- 通常のユーザーがそのパスワードを変更する方法とほとんど同じように、自動的に暗号化鍵に変換される文字列を指定して新しい AFS サーバー暗号化鍵を作成します。サーバー暗号化鍵の追加 を参照してください。
- クライアントとの通信の際にサーバー暗号化鍵を使用するほかにも、サーバー・プロセスはこれを他のサーバー・プロセスとの通信を保護するためにも使用します。このため、所属するセル内のすべてのサーバー・マシンは、 KeyFile ファイルの同じバージョンを持たねばなりません。整合性を保つ最も簡単な方法は (AFS 米国版を実行する場合)、更新サーバーを使用して、システム制御マシンの /usr/afs/etc ディレクトリーの内容を、その他すべてのサーバー・マシンに配布するものです。以下の 2 点の含意があります。
  - システム制御マシン上で upserver プロセス、システム制御マシンを参照する他のすべてのサーバー・マシンで upclientetc プロセスを実行する必要があります。 AFS インストールの手引き には、両プロセスのインストール方法が記されています。更新サーバー・プロセスが実行しているかを検証する方法については、 BosConfig ファイルのプロセス状況および情報の表示 を参照してください。
  - KeyFile ファイルを、システム制御マシンでのみ変更します (サーバー暗号化鍵の緊急事態の取り扱い で説明する緊急時を除く)。他のサーバー・マシンで行った変更はいずれも、次に upclientetc プロセスがシステム制御マシンの /usr/afs/etc ディレクトリーを検索する際に上書きされます。デフォルトでは、これは 5 分おきに実行されます。

  AFS 国際版を実行する場合は、更新サーバーを使用して /usr/afs/etc ディレクトリーの内容、特に KeyFile ファイルを変更しないでください。ファイルのデータは極めて重要であるため、暗号化されていない形式で転送することはできません。また米国政府の輸出規制により、 AFS 国際版は、必要な暗号化ルーチンを更新サーバーが使用できる形式で備えていません。代わりに、それぞれのサーバー・マシン上でファイルを個々に変更する必要があり、それぞれのサーバー・マシンで同じ鍵を入力するようにします。

- テキスト・エディターを使用して KeyFile を直接編集しないでください。代わりに、常に適当な bos コマンドを使用します。指示については、サーバー暗号化鍵の追加 および サーバー暗号化鍵の削除 を参照してください。

## サーバー暗号化鍵の表示

いずれかのファイル・サーバー・マシンの /usr/afs/etc/KeyFile ファイルにあるサーバー暗号化鍵を表示するには、bos listkeys コマンドを使用します。認証データベースの afs 項目にある鍵を表示するには、kas examine コマンドを使用します。

コマンドはデフォルトでは、鍵を構成する 8 進数の実際の文字列を表示することはなく、鍵に定数を暗号化することにより発生する 10 進数である チェックサム を表示します。これにより、権限のないユーザーが実際の鍵に容易にはアクセスし、これを誤って使用したり、保護された通信から盗み出したりすることがないようにしています。

bos listkeys および kas examine コマンドにより所定の鍵の同一のチェックサムが生成されるため、一般的には実際の鍵ではなくチェックサムの表示で十分です。チェックサムによっては分からないような形で鍵が正しくないことが疑われる場合は、セル内全体で認証に問題が発生している可能性があります。最も簡単な解決法は、 サーバー暗号化鍵の追加 または サーバー暗号化鍵の緊急事態の取り扱い の手順で新規にサーバー暗号化鍵を作成するものです。この他に bos listkeys コマンドを発行する一般的な理由としては、次の鍵を選択する準備として、現在使用している鍵バージョン番号を表示することがあげられます。この場合も、鍵そのものは関係ないので、チェックサムで十分です。

実際の 8 進数を表示する必要があれば、-showkey 引き数を bos listkeys と kas examine コマンドの両方に組み込みます。

### KeyFile ファイルの表示

1. /usr/afs/etc/UserList ファイルにリストされているユーザーとして認証されていることを検証します。必要な場合には、bos listusers コマンドを発行します。このコマンドについては、UserList ファイルのユーザーの表示で詳しく説明しています。

          % bos listusers <machine name>

2. bos listkeys コマンドを発行し、 1 つのマシンの /usr/afs/etc/KeyFile ファイルの内容を表示します。

          % bos listkeys <machine name> [-showkey]

   ここで、

   listk
     listkeys の受け入れ可能な省略形です。

   machine name
     ファイル・サーバー・マシン名です。通常は、セルが正しく機能するためには KeyFile ファイルがすべてのマシンで同一であるよう要求されるので、いずれのマシンの指定も可能です。

   -showkey
     それぞれの鍵を構成する 8 進数を表示します。

以下の例では、出力に実際の 8 進数ではなくそれぞれのサーバー暗号化鍵のチェックサムが表示されています。最後から 2 番目の行には、管理者が最後にファイルを変更した日時が示され、最終行には出力が管理者が完了したことが示されています。

       % bos listkeys fs1.abc.com
       key 0 has cksum 972037177
       key 1 has cksum 2825165022
       Keys last changed on Wed Jan 13 11:20:29 1999.
       All done.

### 認証データベースの afs 鍵の表示

1. kas examine コマンドを発行して、認証データベースの afs 項目を表示します。

   認証サーバーは、既存の AFS トークンを受け入れるのではなく、独自の認証を実行します。デフォルトでは、認証サーバーは、管理者のローカル (UNIX) 識別を認証します。この識別は AFS 特権管理者に対応しません。 -admin 引き数を組み込み、認証データベース項目に `ADMIN` フラグを持つ識別を指定します。項目にフラグがあることを確認するには、ADMIN フラグがオンになっていることを確認するで説明するように、kas examine コマンドを発行します。

          % kas examine afs [-showkey]  \
                            -admin <admin principal to use for authentication>
           Administrator's (admin_user) password: admin_password

   ここで、

   e
     examine の最も短い受け入れ可能な省略形です。

   afs
     afs 項目を指定します。

   -showkey
     鍵を構成する 8 進数を表示します。

   -admin
     認証データベース項目に `ADMIN` フラグを持つ管理アカウントを指定します (admin など)。password プロンプトはアカウントを admin_user として表示します。適切なパスワードを、admin_password として入力します。

以下の例では、admin ユーザーが -showkey フラグを使用せずに afs 項目を表示します。2 番目の行は、括弧に囲まれた鍵のバージョン番号および鍵のチェックサムを示します。`last mod` 文字列で始まる行は、指示された管理者が鍵を変更した日付を示しています。この日付と、 bos listkeys コマンドが報告する日付には関連がなくても構いません。後者の日付は、鍵の追加だけではなく、KeyFile ファイルを変更すると更新されるためです。 kas examine コマンドの出力の他の行に関する詳細は、AFS Administration Reference の解説ページを参照してください。

       % kas examine afs  -admin admin
       Administrator's (admin) password: admin_password
       User data for afs
        key (1) cksum is 2825165022, last cpw: no date
        password will never expire.
        An unlimited number of unsuccessful authentications is permitted.
        entry expires on never. Max ticket lifetime 100.00 hours.
        last mod on Wed Jan 13 11:21:36 1999 by admin
        permit password reuse

## サーバー暗号化鍵の追加

前述のとおり、AFS がサーバー暗号化鍵を 2 つの場所に記録します。

1. 各ファイル・サーバー・マシンのローカル・ディスク上のファイル /usr/afs/etc/KeyFile 内に、各マシン上で実行する AFS サーバー・プロセス用として。
2. 認証データベース内の afs 項目に、トークン作成時にチケット付与サービス (TGS) 用として。

サーバー・プロセスと TGS が同一の AFS サーバー暗号化鍵を使用するようにするために、この節に記載するすべてのステップを中断せずに実行してください。

以下の説明には、すべてのデータベース・サーバー・マシンでデータベース・プロセス (認証、バックアップ、保護、およびボリューム・ロケーション・サーバー) を再始動するステップが含まれています。データベース・サーバー・プロセスが開始すると、これは KeyFile ファイル中、最大の鍵バージョン番号を持つサーバー暗号化鍵を読み取り、これを使用してデータベースの同期化および定数の保持のための送信メッセージを保護します。プロセスは、 KeyFile ファイルから鍵が除去された場合でも存続時間中は同一の鍵を使用し、これは長期におよぶことがあります。ただし、ピア・データベース・サーバーの 1 つが再始動して、他が再始動しない場合、プロセスはもはや同一の鍵を使用しないため、定数およびデータベース同期が中断されます。再始動したプロセスは、現在最大の鍵バージョン番号を持つ鍵を使用し、他のプロセスはその開始時に読み込んだ鍵を使用しています。こうした問題を避けるには、新規の鍵を追加する場合は、すべてのデータベース・プロセスを再始動するのが最も安全な方法です。

新規鍵を追加したら、KeyFile ファイルから古い鍵を除去し、混乱しないようにします。ただし、クライアントまたはサーバー・プロセスがまだ使用している鍵を除去しないように注意してください。詳細については、サーバー暗号化鍵の削除 を参照してください。

### 新規サーバー暗号化鍵の追加方法

1. /usr/afs/etc/UserList ファイルにリストされているユーザーとして認証されていることを検証します。必要な場合には、bos listusers コマンドを発行します。このコマンドについては、UserList ファイルのユーザーの表示で詳しく説明しています。

          % bos listusers <machine name>

2. bos listkeys コマンドを発行して、新しい鍵のバージョン番号を選択する最初のステップとして、既に使用されている鍵バージョン番号を表示します。

          % bos listkeys <machine name>

   ここで、

   listk
     listkeys の受け入れ可能な省略形です。

   machine name
     任意のファイル・サーバー・マシンを指定します。
3. 2 のステップの出力、および以下の要件に基づいて、新しい鍵のバージョン番号を選択します。
   - 鍵バージョン番号は、0 (ゼロ) から 255 の範囲の整数で、ケルベロス標準に準拠するものとします。最も簡単な方法は、既存の鍵のバージョン番号の最大のものより 1 つ大きいバージョン番号を選択して、鍵のバージョン番号を連続したものにする方法です。
   - 現時点で KeyFile ファイルに存在する鍵のバージョン番号、特に認証データベースの afs 項目にあるものは再使用しないでください。クライアント・プロセスはまだその鍵バージョン番号を持つ鍵で暗号化されたチケットを持つ場合がありますが、サーバー・プロセスはその鍵バージョン番号でマークされた新しいキーを使い始めます。鍵が一致しないため、正しいトークンを持つクライアントからの要求をサーバー・プロセスは拒否します。
4. bos addkey コマンドを発行し、KeyFile ファイルに新規の AFS サーバー暗号化鍵を作成します。

   米国版の AFS を実行し、更新サーバーを使用してシステム制御マシンの /usr/afs/etc ディレクトリーの内容を配布する場合は、machine name 引き数をシステム制御マシンに置き換えます。 (システム制御マシンはどれかを忘れてしまった場合には、システム制御マシンを特定するには を参照してください。)

   国際版の AFS を実行する場合、あるいは更新サーバーを使用しない場合は、machine name 引き数を順に各サーバー・マシンに置き換えて、bos addkey コマンドを繰り返します。

   新規鍵に対応する文字列が表示されないようにするには、コマンド行から -key 引き数を省略します。代わりに省略した際に表示されるプロンプトで文字列を入力します。以下の構文指定を参照してください。

          % bos addkey  -server <machine name> -kvno <key version number>
          input key: afs_password
          Retype input key: afs_password

   ここで、

   addk
     addkey の受け入れ可能な省略形です。

   -server
     更新サーバーを使用している場合は、セルのシステム制御マシン、または使用していない場合は、それぞれのサーバー・マシンを指定します。

   -kvno
     新しい鍵のバージョン番号を、 0 (ゼロ) から 255 までの範囲の整数として指定します。

     番号を忘れないようにしてください。この番号は、 6 のステップでも再度使用します。 AFS の米国版を使用している場合は、このコマンドを発行するときには必ず同じ番号をタイプしてください。

   afs_password
     1 文字から約 1,000 文字までの長さの、ユーザー・パスワードに類似した文字ストリングです。セキュリティーを向上させるには、アルファベット以外の文字を組み込み、文字列を実用的な範囲で長くします (これを入力する必要があるのは、このステップと 6 のステップだけです)。 AFS の国際版を使用している場合は、このコマンドをタイプするときには、必ず同じストリングを使用してください。

     8 進数のストリングを直接入力しないでください。BOS サーバーは、その文字ストリングをスクランブルして、暗号化鍵としての使用に適した 8 進数に変換し、その後で KeyFile ファイルに記録します。

5. 更新サーバーを使用している場合は、更新サーバーが新しい KeyFile ファイルをすべてのサーバー・マシンに配布している間、数分間待ちます。必要な最大待機期間は、任意のサーバー・マシンに対する upclientetc プロセスの初期化コマンドで指定する -t 引き数に提供する最大値です。デフォルトの時間は 5 分です。

   すべてのマシンが同じ KeyFile ファイルを持つかどうかを確認するには、各ファイル・サーバー・マシンに対して bos listkeys コマンドを発行して、新規鍵のチェックサムがすべてのマシンについて同じになるか検証します。

          % bos listkeys <machine name>

   更新サーバーを使用しない場合は、 4 のステップを 5 分以内で完了するようにしてください。

6. kas setpassword コマンドを発行して、認証データベースの afs 項目に同じ鍵を入力します。

   認証サーバーは、既存の AFS トークンを受け入れるのではなく、独自の認証を実行します。デフォルトでは、認証サーバーは、管理者のローカル (UNIX) 識別を認証します。この識別は AFS 特権管理者に対応しません。 -admin 引き数を組み込み、認証データベース項目に `ADMIN` フラグを持つ識別を指定します。項目にフラグがあることを確認するには、ADMIN フラグがオンになっていることを確認するで説明するように、kas examine コマンドを発行します。

          % kas setpassword -name afs -kvno <kvno>  \
                            -admin <admin principal to use for authentication>
          Administrator's (admin_user) password: admin_password
          new_password: afs_password
          Verifying, please re-enter new_password: afs_password

   ここで、

   sp
     setpassword の受け入れ可能な別名です (setp は受け入れ可能な最も短い省略形です)。

   -name afs
     新規鍵を afs 項目に作成します。

   -kvno
     4 のステップと同じ鍵バージョン番号を指定します。

   -admin
     認証データベース項目に `ADMIN` フラグを持つ管理アカウントを指定します (admin など)。password プロンプトはアカウントを admin_user として表示します。適切なパスワードを、admin_password として入力します。

   afs_password
     4 のステップで入力したものと同じ文字列です。
7. (オプション) KeyFile ファイルおよび認証データベースの afs 項目で作成した鍵が同一であり、同じ鍵バージョン番号を持つことを検査する場合は、 サーバー暗号化鍵の表示 の手順に従ってください。
8. bos restart コマンドを発行して、すべてのデータベース・サーバー・マシンでデータベース・サーバー・プロセスを再始動します。これにより、現在最大のバージョン番号を持つ KeyFile ファイル中の鍵が使用されるようになります。

   それぞれのデータベース・サーバー・マシンについて、最下位の IP アドレスを持つものから開始して、このコマンドを連続して繰り返します。

          % bos restart <machine name> buserver kaserver ptserver vlserver

   ここで、

   res
     restart の受け入れ可能な最も短い省略形です。

   machine name
     それぞれのデータベース・サーバー・マシンを順に命名します。

   buserver kaserver ptserver vlserver
     それぞれ、バックアップ・サーバー、認証サーバー、保護サーバー、およびボリューム・ロケーション (VL) サーバーを指定します。

## サーバー暗号化鍵の削除

/usr/afs/etc/KeyFile ファイルから古い鍵を定期的に除去し、これを適切なサイズに保持することができます。セル機能を混乱させることがないよう、古い鍵の除去は、その鍵を使用して暗号化し、ユーザーまたはクライアント・プロセスが保持しているトークンがすべて期限切れになるまでは行わないようにしてください。新規鍵の追加後は、最低でもセル内で使用する最長のトークン存続時間の間は待ってから古い鍵を除去してください。 AFS バージョン 3.1 で作成された認証データベースのユーザー項目の場合、デフォルトのトークン存続時間は 25 時間、AFS バージョン 3.0 で作成された項目は、100 時間となっています。

認証データベースの afs 項目は、鍵フィールドを空にすることができないため、この項目から鍵を削除するコマンドはありません。 kas setpassword コマンドを使用して、 afs キーを置き換えますが、これは 新規サーバー暗号化鍵の追加方法 に詳細が説明されている完全な手順の一部です。

現在 認証データベースの afs 項目にある KeyFile ファイルからは鍵を削除しないでください。 AFS サーバー・プロセスは、クライアントが示すチケットの暗号化ができなくなります。

### KeyFile ファイルの鍵の除去

1. /usr/afs/etc/UserList ファイルにリストされているユーザーとして認証されていることを検証します。必要な場合には、bos listusers コマンドを発行します。このコマンドについては、UserList ファイルのユーザーの表示で詳しく説明しています。

          % bos listusers <machine name>

2. bos listkeys コマンドを発行し、除去する鍵のそれぞれの鍵バージョン番号を表示します。出力には、新しい鍵が KeyFile ファイルに入れられてから最低 25 時間経過したかどうかが示されます。bos listkeys コマンドの完全な説明については、KeyFile ファイルの表示 を参照してください。

          % bos listkeys <machine name>

3. kas examine コマンドを発行し、現在認証データベース の afs 項目にある鍵が、 KeyFile ファイルから除去するいずれの鍵とも同じ鍵バージョン番号を持たないことを確認します。 kas examine コマンドの詳細は、 認証データベースの afs 鍵の表示 を参照してください。

          % kas examine afs  -admin <admin principal to use for authentication>
          Administrator's (admin_user) password: admin_password

4. bos removekey コマンドを発行し、KeyFile ファイルから 1 つ以上のサーバー暗号化鍵を削除します。

   米国版の AFS を実行し、更新サーバーを使用してシステム制御マシンの /usr/afs/etc ディレクトリーの内容を配布する場合は、machine name 引き数をシステム制御マシンに置き換えます。 (システム制御マシンはどれかを忘れてしまった場合には、システム制御マシンを特定するには を参照してください。)

   国際版の AFS を実行する場合、あるいは更新サーバーを使用しない場合は、machine name 引き数を順に各サーバー・マシンに置き換えて、bos removekey コマンドを繰り返します。

          % bos removekey <machine name> <key version number>

   ここで、

   removek
     removekey の受け入れ可能な省略形です。

   machine name
     更新サーバーを使用している場合は、セルのシステム制御マシン、または使用していない場合は、それぞれのサーバー・マシンを指定します。

   key version number
     削除する各鍵のバージョン番号を指定します。

## サーバー暗号化鍵の緊急事態の取り扱い

まれに、クライアントあるいはピア・サーバー・プロセスが提供するサーバー・チケットを、AFS サーバー・プロセスが復号できなくなることがあります。サーバー・プロセスが、それらのチケットが偽造されたものであるか、または有効期限切れのものであると判断し、任意のアクションの実行を拒絶するため、セル内の活動は停止します。このような事態は 1 つまたはいくつかのマシンで発生する可能性がありますが、より多くのマシンがかかわる場合は影響がより深刻になります。

サーバー暗号化鍵問題の 1 つの一般的な原因は、クライアントのチケットがサーバー・プロセスが認識しない鍵を使用して暗号化される場合です。通常これは、サーバー・マシン上の /usr/afs/etc/KeyFile に、認証サーバーのチケット付与サービス (TGS) モジュールがサーバー・チケットを暗号化するのに使用する afs 認証データベース項目の鍵が含まれていないことを意味します。

別の可能性は、異なるマシン上の KeyFile ファイルが同じ鍵を持たない場合です。この場合、サーバー・プロセス間の通信は不可能になります。たとえば、異なるデータベース・サーバー・マシン上のデータベース・サーバー・プロセスのインスタンスが同じサーバー暗号化鍵を使用しない場合は、 AFS の複製データベース機構 (Ubik) は中断します。

bos コマンドをローカル・セル内のファイル・サーバー・マシンに送信したときに、次のメッセージを送信することがあると、これはサーバー暗号化化鍵のミスマッチの兆候です。 (ただし、bos コマンドを外部セル内のファイル・サーバー・マシンに送信したときに -cell 引き数を指定しなかった場合も、このメッセージを受信することに注意してください。)

       bos: failed to contact host's bosserver (security object was passed a bad ticket).

サーバー暗号化鍵の緊急事態の解決方法は、すべてのファイル・サーバー・マシン上の認証データベースおよび KeyFile の両方に新しい AFS サーバー暗号化鍵を入れることです。これにより、TGS およびすべてのサーバー・プロセスが再度同じ鍵を共有するようになります。

鍵の緊急事態の処理では、特別なアクションが要求されます。これらのアクションを使用する理由が以下の機能グループに説明されています。実際の手順は、後続の説明に記載されています。

### 相互認証が行えない

鍵の緊急事態を取り扱っているときには、サーバー・プロセスがユーザーとの間で相互認証を行おうとすることを避ける必要があります。なぜなら、ユーザーのトークンをサーバー・プロセスが解読できない可能性があるからです。相互認証を行わない場合は、サーバー・プロセスはユーザーに一致 anonymous を割り当てます。相互認証を行わないようにするには、unlog コマンドを使用してトークンを破棄し、 -noauth フラグが使用可能なコマンドにこれを組み込みます。

### 手動で許可検査を使用不可にする

相互認証を行わない場合は、サーバー・プロセスがユーザーを anonymous であると認識するため、許可検査をオフにする必要があります。サーバー・プロセスは、許可検査を使用不可にした場合のみ anonymous が鍵の作成などの特権が必要なアクションを実行することを許可します。

緊急事態では、手動でファイル /usr/afs/local/NoAuth を作成して許可検査を使用不可にします。通常は、代わりに bos setauth コマンドを使用します。

### 各マシン上で迅速に作業する

許可検査を使用不可にすると、その影響を受けるマシン上のサーバー・プロセスがどのユーザーに対してもアクションを取るため、セキュリティーが重大な危機にさらされます。許可検査を使用不可にする際には、中断しないセッションですべてのステップをできる限り迅速に完了し、必要な期間のみ実行する必要があります。

### コンソールで作業する

認可検査を使用不可にするそれぞれのサーバー・マシンのコンソールで作業をすることにより、ユーザーがそこで作業をしている間は、他のユーザーは誰もそのコンソールにログオンすることはありません。他のユーザーがそのマシンにリモートに接続 (たとえば telnet プログラムを使用するなど) することを防ぐわけではないため、迅速に作業することが重要です。完全なセキュリティーを確保するためには、ネットワーク通信を使用不可にしますが、これは多くの環境では実行可能な選択ではありません。 セル内のセキュリティー改善 で推奨しているように、サーバー・マシンに常時リモート接続できる人数を制限すると、全般的なセキュリティーを向上させることができます。

### 個々の KeyFile ファイルを変更する

更新サーバーを使用して /usr/afs/etc ディレクトリーの内容を配布すると、緊急事態になるのは、個々のマシン上の KeyFile ファイルを変更するころ合いになった場合のみになります。各マシンのファイルを更新する必要があるのは、不一致となったキーにより、システム制御マシンの upserver プロセスが、他のサーバー・マシン上の upclientetc プロセスと相互認証できなくなり、upserver プロセスがその KeyFile ファイルを upclientetc プロセスに配布するのを拒否するからです。

更新サーバーが正常に作動しているように見えても、それを確認する唯一の方法は、システム制御マシン上の鍵を変更して、標準遅延時間を待って upclientetc プロセスがそのキーを取り出すかどうかを確認することです。緊急事態では、標準遅延時間の間待機することは普通意味がありません。単に各サーバー・マシン上のファイルを別々に更新するほうがより効果的です。また、更新サーバーがファイルを正しく配布する場合でも、キーの不一致のために他のプロセスに問題が発生する可能性もあります。以下の説明では、最初にシステム制御マシンに新規の鍵ファイルを追加しています。更新サーバーが作動していれば、それぞれのサーバー上で個々に行った変更と同じ変更を配布することになります。

所属するセルが更新サーバーを使用しない、または AFS 国際版を使用する場合は、常にサーバー・マシン上の鍵を個別に変更します。以下の説明もまた役立ちます。

### 2 つのコンポーネント・プロシージャー

以下の説明では、頻繁に使用される 2 つのサブプロシージャー、許可検査の使用不可および許可検査の再使用可能化を記載します。分かりやすいように、ここではプロシージャーを詳細に説明します。必要である場合は、プロシージャーを参照します。

#### 緊急事態において許可検査を使用不可にする

1. まだの場合は、su コマンドを発行し、マシン上でローカル・スーパーユーザー root になります。

          % su root
          Password: root_password

2. ファイル /usr/afs/local/NoAuth を作成して、許可検査を使用不可にします。

          # touch /usr/afs/local/NoAuth

3. トークンが互換性のない鍵で暗号化された場合、いくつかのコマンドが実行されない可能性があるため、トークンを破棄します。

          # unlog

#### 緊急事態において許可検査を再度使用可能にする

1. まだの場合は、su コマンドを発行し、マシン上でローカル・スーパーユーザー root になります。

          % su root
          Password: root_password

2. /usr/afs/local/NoAuth ファイルを除去します。

          # rm /usr/afs/local/NoAuth

3. system:administrators グループに含まれ、 /usr/afs/etc/UserList ファイルにリストされる管理 ID として認証をする。

          # klog <admin_user>
          Password: <admin_password>

4. 問題がなければ、 unlog コマンドを発行してユーザーのトークンを破棄した後で、マシンのコンソールからログアウトします (または使用するリモート接続をクローズします)。

### 緊急事態における新規サーバー暗号化鍵の作成方法

1. システム制御マシン上で、 緊急事態において許可検査を使用不可にする の説明に従い、許可検査を使用不可にします。
2. bos listkeys コマンドを発行して、新しい鍵のバージョン番号を選択する最初のステップとして、KeyFile ファイルで使用されている鍵バージョン番号を表示します。

          # bos listkeys <machine name> -noauth

   ここで、

   listk
     listkeys の受け入れ可能な省略形です。

   machine name
     ファイル・サーバー・マシンを指定します。

   -noauth
     BOS サーバーとの相互認証をバイパスします。鍵の緊急事態により、相互認証が正常に行われない場合に、これを組み込みます。
3. 2 のステップで調べた事柄、および以下の要件に基づいて、新しい鍵のバージョン番号を選択します。
   - 既存の鍵のバージョン番号の最大のものより 1 つ大きいバージョン番号を選択して、鍵のバージョン番号を連続したものにすることが望まれる。
   - 鍵のバージョン番号は 0 から 255 までの整数とし、ケルベロス標準に適合するものとします。
   - KeyFile ファイルに現在リストされている鍵バージョン番号を再使用しないでください。
4. システム制御マシン上で、 bos addkey コマンドを発行し、 KeyFile ファイルに新しい AFS サーバー暗号化鍵を作成します。

          # bos addkey <machine name> -kvno <key version number> -noauth
          input key: afs_password
          Retype input key: afs_password

   ここで、

   addk
     addkey の受け入れ可能な省略形です。

   machine name
     KeyFile ファイルに新しい鍵を定義するファイル・サーバー・マシンの名前です。

   -kvno
     3 のステップで選択した鍵のバージョン番号を選択します。 0 (ゼロ) から 255 までの範囲の整数です。 7、8、および 13 のステップでは、同じ数を指定する必要があります。

   -noauth
     BOS サーバーとの相互認証をバイパスします。鍵の緊急事態により、相互認証が正常に行われない場合に、これを組み込みます。

   afs_password
     1 文字から約 1,000 文字までの長さの、ユーザー・パスワードに類似した文字ストリングです。セキュリティー向上のため、実用的である範囲で文字列を長くし、アルファベット以外の文字を含めます。

     8 進数のストリングを直接タイプしないでください。 BOS サーバーは、その文字ストリングをスクランブルして、暗号化鍵としての使用に適した 8 進数に変換し、その後で KeyFile ファイルに記録します。

     ストリングを忘れないようにしてください。これを再度、7、8、および 13 のステップで使用します。

5. 所属するセル内のすべてのデータベース・サーバー・マシン上で (システム制御マシン以外)、 緊急事態において許可検査を使用不可にする の指示に従い許可検査を使用不可にします。システム制御マシンがデータベース・サーバー・マシンの場合は、既に 1 のステップで許可検査を使用不可にしているので、手順を繰り返さないでください。 (どのマシンがデータベース・サーバー・マシンであるかを確認する必要がある場合は、 データベース・サーバー・マシンを特定するには で説明している bos listhosts コマンドを使用してください。)
6. 5 のステップを終了した後で最低 90 秒待ち、それぞれのデータベース・サーバーのプロセス (認証サーバー、バックアップ・サーバー、保護サーバー、およびボリューム配置サーバー) が新規の同期サイトの選択を完了するようにします。その上で udebug コマンドを発行し、選択が正しく行われたかを確認します。以下のコマンドを発行します。 server machine のそれぞれのデータベース・サーバー・マシン名を順に置換します。システム制御マシンがデータベース・サーバー・マシンであれば、これを組み込みます。

          # udebug <server machine> buserver
          # udebug <server machine> kaserver
          # udebug <server machine> ptserver
          # udebug <server machine> vlserver

   それぞれのプロセスについて、すべてのデータベース・サーバー・マシンからの出力は、そのサイトがプロセスに対する同期サイトかという点において一致している必要があります。ただし、同じマシンをそれぞれ 4 つのプロセスの同期サイトにする必要はありません。それぞれのプロセスにつき、 1 つのマシンのみの出力が以下の文字列を含むようにします。

          I am sync site ...

   他のマシンの出力は、代わりに以下の行を含みます。

          I am not sync site

   および以降の行 (文字列 `Sync host` に始まり、同期サイトであると表示されるマシンの IP アドレスを指定) を含む必要があります。

   出力がこれらの要件と一致しない場合、またはその他の点で問題があると思われる場合は、 AFS プロダクト・サポートに連絡してサポートを受けてください。

7. 所属するセル内のすべてのデータベース・サーバー・マシン上で (システム制御マシン以外)、 4 のステップで説明している bos addkey コマンドを実行します。必ずそのステップで使用したものと同じ値を、afs_password および kvno で使用してください
8. kas setpassword コマンドを発行して、認証データベースの afs 項目に新規の鍵を定義します。これは、4 および 7 のステップで作成したキーに一致しなくてはなりません。

          # kas setpassword  -name afs  -kvno <key version number> -noauth
          new_password: afs_password
          Verifying, please re-enter new_password: afs_password

   ここで、

   sp
     setpassword の受け入れ可能な別名です (setp は受け入れ可能な最も短い省略形です)。

   -kvno
     4 のステップで指定したものと同じ鍵バージョン番号です。

   afs_password
     4 のステップで afs_password として指定したものと同じ文字列です。文字ストリングは画面にそのまま表示されません。
9. 所属するセル内のすべてのデータベース・サーバー・マシン上で (システム制御マシンがデータベース・サーバー・マシンであればこれも含む)、 緊急事態において許可検査を再度使用可能にする の説明に従い許可検査を再度使用可能にします。システム制御マシンがデータベース・サーバー・マシンでない場合、この手順は 11 のステップまで実行しないでください。
10. 6 のステップを繰り返し、 9 のステップで再始動してから各データベース・サーバー・プロセスが適切に同期サイトを選択したかどうかを検査します。
11. システム制御マシン上で (これがデータベース・サーバー・マシンでない場合)、 緊急事態において許可検査を再度使用可能にする の指示に従い許可検査を再度使用可能にします。これがデータベース・サーバー・マシンであれば、既に 9 のステップで手順を実行しています。
12. すべて残りの (単純) ファイル・サーバー・マシンで、 緊急事態において許可検査を使用不可にする の手順に従い許可検査を使用不可にします。
13. すべての残りの (単純) ファイル・サーバー・マシンで、bos addkey コマンドを発行します。 4 のステップを参照してください。必ずそのステップで使用したものと同じ値を、afs_password および kvno で使用してください
14. すべての残りの (単純) ファイル・サーバー・マシンで、 緊急事態において許可検査を再度使用可能にする の指示に従い許可検査を再度使用可能にします。

[ ページのトップ | 前ページ | 次ページ | 目次 | 索引 ]

(C) IBM Corporation 2000. All Rights Reserved