この章では、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 項目、および KeyFile ファイルの作成に関する説明は、 AFS インストールの手引き を参照してください。
古いサーバー暗号化鍵を安全に削除できるのは、この鍵で暗号化したトークンを持つクライアントが存在しないことが確認できた場合のみです。少なくとも一般に、セル内でのトークンの最大の存続時間の間は待つようにします。デフォルトでは、最大トークン存在時間は 25 時間です (認証データベースの項目が AFS バージョン 3.0 を使用して作成されたユーザーのデフォルトは 100 時間であり、このようなユーザーは除きます)。 -lifetime 引き数を kas setfields コマンドで使用することにより、このデフォルトを変更することができます。
古い鍵の削除に関する説明は、サーバー暗号化鍵の削除 を参照してください。
AFS 国際版を実行する場合は、更新サーバーを使用して /usr/afs/etc ディレクトリーの内容、特に KeyFile ファイルを変更しないでください。ファイルのデータは極めて重要であるため、暗号化されていない形式で転送することはできません。また米国政府の輸出規制により、 AFS 国際版は、必要な暗号化ルーチンを更新サーバーが使用できる形式で備えていません。代わりに、それぞれのサーバー・マシン上でファイルを個々に変更する必要があり、それぞれのサーバー・マシンで同じ鍵を入力するようにします。
いずれかのファイル・サーバー・マシンの /usr/afs/etc/KeyFile ファイルにあるサーバー暗号化鍵を表示するには、bos listkeys コマンドを使用します。認証データベースの afs 項目にある鍵を表示するには、kas examine コマンドを使用します。
コマンドはデフォルトでは、鍵を構成する 8 進数の実際の文字列を表示することはなく、鍵に定数を暗号化することにより発生する 10 進数である チェックサム を表示します。これにより、権限のないユーザーが実際の鍵に容易にはアクセスし、これを誤って使用したり、保護された通信から盗み出したりすることがないようにしています。
bos listkeys および kas examine コマンドにより所定の鍵の同一のチェックサムが生成されるため、一般的には実際の鍵ではなくチェックサムの表示で十分です。チェックサムによっては分からないような形で鍵が正しくないことが疑われる場合は、セル内全体で認証に問題が発生している可能性があります。最も簡単な解決法は、 サーバー暗号化鍵の追加 または サーバー暗号化鍵の緊急事態の取り扱い の手順で新規にサーバー暗号化鍵を作成するものです。この他に bos listkeys コマンドを発行する一般的な理由としては、次の鍵を選択する準備として、現在使用している鍵バージョン番号を表示することがあげられます。この場合も、鍵そのものは関係ないので、チェックサムで十分です。
実際の 8 進数を表示する必要があれば、-showkey 引き数を bos listkeys と kas examine コマンドの両方に組み込みます。
% bos listusers <machine name>
% bos listkeys <machine name> [-showkey]
ここで、
以下の例では、出力に実際の 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 トークンを受け入れるのではなく、独自の認証を実行します。デフォルトでは、認証サーバーは、管理者のローカル (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
ここで、
以下の例では、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 つの場所に記録します。
サーバー・プロセスと TGS が同一の AFS サーバー暗号化鍵を使用するようにするために、この節に記載するすべてのステップを中断せずに実行してください。
以下の説明には、すべてのデータベース・サーバー・マシンでデータベース・プロセス (認証、バックアップ、保護、およびボリューム・ロケーション・サーバー) を再始動するステップが含まれています。データベース・サーバー・プロセスが開始すると、これは KeyFile ファイル中、最大の鍵バージョン番号を持つサーバー暗号化鍵を読み取り、これを使用してデータベースの同期化および定数の保持のための送信メッセージを保護します。プロセスは、 KeyFile ファイルから鍵が除去された場合でも存続時間中は同一の鍵を使用し、これは長期におよぶことがあります。ただし、ピア・データベース・サーバーの 1 つが再始動して、他が再始動しない場合、プロセスはもはや同一の鍵を使用しないため、定数およびデータベース同期が中断されます。再始動したプロセスは、現在最大の鍵バージョン番号を持つ鍵を使用し、他のプロセスはその開始時に読み込んだ鍵を使用しています。こうした問題を避けるには、新規の鍵を追加する場合は、すべてのデータベース・プロセスを再始動するのが最も安全な方法です。
新規鍵を追加したら、KeyFile ファイルから古い鍵を除去し、混乱しないようにします。ただし、クライアントまたはサーバー・プロセスがまだ使用している鍵を除去しないように注意してください。詳細については、サーバー暗号化鍵の削除 を参照してください。
% bos listusers <machine name>
% bos listkeys <machine name>
ここで、
米国版の 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
ここで、
番号を忘れないようにしてください。この番号は、 6 のステップでも再度使用します。 AFS の米国版を使用している場合は、このコマンドを発行するときには必ず同じ番号をタイプしてください。
8 進数のストリングを直接入力しないでください。BOS サーバーは、その文字ストリングをスクランブルして、暗号化鍵としての使用に適した 8 進数に変換し、その後で KeyFile ファイルに記録します。
すべてのマシンが同じ KeyFile ファイルを持つかどうかを確認するには、各ファイル・サーバー・マシンに対して bos listkeys コマンドを発行して、新規鍵のチェックサムがすべてのマシンについて同じになるか検証します。
% bos listkeys <machine name>
更新サーバーを使用しない場合は、 4 のステップを 5 分以内で完了するようにしてください。
認証サーバーは、既存の 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
ここで、
それぞれのデータベース・サーバー・マシンについて、最下位の IP アドレスを持つものから開始して、このコマンドを連続して繰り返します。
% bos restart <machine name> buserver kaserver ptserver vlserver
ここで、
/usr/afs/etc/KeyFile ファイルから古い鍵を定期的に除去し、これを適切なサイズに保持することができます。セル機能を混乱させることがないよう、古い鍵の除去は、その鍵を使用して暗号化し、ユーザーまたはクライアント・プロセスが保持しているトークンがすべて期限切れになるまでは行わないようにしてください。新規鍵の追加後は、最低でもセル内で使用する最長のトークン存続時間の間は待ってから古い鍵を除去してください。 AFS バージョン 3.1 で作成された認証データベースのユーザー項目の場合、デフォルトのトークン存続時間は 25 時間、AFS バージョン 3.0 で作成された項目は、100 時間となっています。
認証データベースの afs 項目は、鍵フィールドを空にすることができないため、この項目から鍵を削除するコマンドはありません。 kas setpassword コマンドを使用して、 afs キーを置き換えますが、これは 新規サーバー暗号化鍵の追加方法 に詳細が説明されている完全な手順の一部です。
現在 認証データベースの afs 項目にある KeyFile ファイルからは鍵を削除しないでください。 AFS サーバー・プロセスは、クライアントが示すチケットの暗号化ができなくなります。
% bos listusers <machine name>
% bos listkeys <machine name>
% kas examine afs -admin <admin principal to use for authentication> Administrator's (admin_user) password: admin_password
米国版の AFS を実行し、更新サーバーを使用してシステム制御マシンの /usr/afs/etc ディレクトリーの内容を配布する場合は、machine name 引き数をシステム制御マシンに置き換えます。 (システム制御マシンはどれかを忘れてしまった場合には、システム制御マシンを特定するには を参照してください。)
国際版の AFS を実行する場合、あるいは更新サーバーを使用しない場合は、machine name 引き数を順に各サーバー・マシンに置き換えて、bos removekey コマンドを繰り返します。
% bos 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 プログラムを使用するなど) することを防ぐわけではないため、迅速に作業することが重要です。完全なセキュリティーを確保するためには、ネットワーク通信を使用不可にしますが、これは多くの環境では実行可能な選択ではありません。 セル内のセキュリティー改善 で推奨しているように、サーバー・マシンに常時リモート接続できる人数を制限すると、全般的なセキュリティーを向上させることができます。
更新サーバーを使用して /usr/afs/etc ディレクトリーの内容を配布すると、緊急事態になるのは、個々のマシン上の KeyFile ファイルを変更するころ合いになった場合のみになります。各マシンのファイルを更新する必要があるのは、不一致となったキーにより、システム制御マシンの upserver プロセスが、他のサーバー・マシン上の upclientetc プロセスと相互認証できなくなり、upserver プロセスがその KeyFile ファイルを upclientetc プロセスに配布するのを拒否するからです。
更新サーバーが正常に作動しているように見えても、それを確認する唯一の方法は、システム制御マシン上の鍵を変更して、標準遅延時間を待って upclientetc プロセスがそのキーを取り出すかどうかを確認することです。緊急事態では、標準遅延時間の間待機することは普通意味がありません。単に各サーバー・マシン上のファイルを別々に更新するほうがより効果的です。また、更新サーバーがファイルを正しく配布する場合でも、キーの不一致のために他のプロセスに問題が発生する可能性もあります。以下の説明では、最初にシステム制御マシンに新規の鍵ファイルを追加しています。更新サーバーが作動していれば、それぞれのサーバー上で個々に行った変更と同じ変更を配布することになります。
所属するセルが更新サーバーを使用しない、または AFS 国際版を使用する場合は、常にサーバー・マシン上の鍵を個別に変更します。以下の説明もまた役立ちます。
以下の説明では、頻繁に使用される 2 つのサブプロシージャー、許可検査の使用不可および許可検査の再使用可能化を記載します。分かりやすいように、ここではプロシージャーを詳細に説明します。必要である場合は、プロシージャーを参照します。
% su root Password: root_password
# touch /usr/afs/local/NoAuth
# unlog
% su root Password: root_password
# rm /usr/afs/local/NoAuth
# klog <admin_user> Password: <admin_password>
# bos listkeys <machine name> -noauth
ここで、
# bos addkey <machine name> -kvno <key version number> -noauth input key: afs_password Retype input key: afs_password
ここで、
8 進数のストリングを直接タイプしないでください。 BOS サーバーは、その文字ストリングをスクランブルして、暗号化鍵としての使用に適した 8 進数に変換し、その後で KeyFile ファイルに記録します。
# 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 プロダクト・サポートに連絡してサポートを受けてください。
# kas setpassword -name afs -kvno <key version number> -noauth new_password: afs_password Verifying, please re-enter new_password: afs_password
ここで、