Secure RPC

Secure RPC は Secure NFS システムの基本となるメカニズムです。Secure RPC の目標は、少なくともタイムシェアリングシステム (すべてのユーザが 1 台のコンピュータを共有するシステム) 程度に安全なシステムを構築することです。タイムシェアリングシステムはログインパスワードによりユーザを認証します。DES (Data Encryption Service) 認証でもこれは同じです。ユーザは、ローカル端末の場合と同じように、任意のリモートコンピュータにログインできます。ユーザのログインパスワードは、ネットワークセキュリティへのパスポートです。タイムシェアリングでは、システム管理者は信頼のおける人で、パスワードを変更してだれかを装うようなことはしないという道徳上の義務を負います。Secure RPC では、ネットワーク管理者は「公開鍵」を格納するデータベースのエントリを変更しないという前提で信頼されています。

RPC 認証システムを理解するには、「資格 (credential)」と「ベリファイア」という 2 つの用語を理解する必要があります。ID バッジを例にとれば、資格とは、名前、住所、誕生日など人間を識別するものです。ベリファイアとはバッジに添付された写真であり、バッジの写真をその所持者と照合することによって、そのバッジが盗まれたものではないことを確認できます。RPC では、クライアントプロセスは RPC 要求のたびに資格とベリファイアの両方をサーバに送信します。クライアントはサーバの資格をすでに知っているため、サーバはベリファイアだけを送り返します。

RPC の認証機能は拡張が可能で、さまざまな認証システムを組み込むことができます。現在のところ、このようなシステムには UNIX、DH、KERB (Kerberos バージョン 4) の 3 つがあります。

ネットワークサービスで UNIX 認証を使用する場合、資格にはクライアントのコンピュータ名、UID、GID、グループアクセスリストが含まれ、ベリファイアには何も含まれません。ベリファイアが存在しないため、ルートユーザは su などのコマンドを使用して、適切な資格を偽ることができます。UNIX 認証でのもう 1 つの問題は、ネットワーク上のすべてのコンピュータを UNIX コンピュータと想定していることです。UNIX 認証を異機種ネットワーク内のほかのオペレーティングシステムに適用した場合、これは正常に動作しません。

UNIX 認証の欠点を補うために、Secure RPC では DH 認証か KERB 認証を使います。

DH 認証

DH 認証は、Data Encryption Standard (DES) と Diffie-Hellman 公開鍵暗号手法を使用してネットワーク上のユーザとコンピュータの両方を認証します。DES は標準暗号化機能であり、Diffie-Hellman 公開鍵暗号手法は、公開鍵と非公開鍵という 2 つの鍵を使用する暗号方式です。公開鍵と非公開鍵は名前空間に格納されます。NIS の場合、それらの鍵を publickey マップに格納し、NIS+ は cred テーブルに格納します。これらのマップにはすべての認証の候補ユーザの公開鍵と非公開鍵が入っています。マップとテーブルの設定については、『Solaris ネーミングの管理』を参照してください。

DH 認証のセキュリティは、送信側が現在時刻を暗号化する機能に基づいていて、受信側はこれを復号して、自分の時刻と照合します。タイムスタンプは DES を使って暗号化されます。この方式が機能するには次の条件が必要です。

• 2 つのエージェントの現在時刻が一致している。

• 送信側と受信側が同じ暗号化鍵を使用する。

ネットワークが時間同期プログラムを実行する場合、クライアントとサーバ上の時間は自動的に同期されます。時間同期プログラムを使用できない場合、ネットワーク時間ではなく、サーバの時間を使用してタイムスタンプを計算できます。クライアントは、RPC セッションを開始する前にサーバに時間を要求し、自分のクロックとサーバのクロックとの時間差を計算します。タイムスタンプを計算するときには、この差を使用してクライアントのクロックを補正します。サーバがクライアントの要求を拒否するほど、クライアントとサーバのクロック同期がずれた場合、DH 認証システムはサーバとの間で再び同期をとります。

クライアントとサーバは、ランダムな対話鍵 (セッションキーとも呼びます) を生成することによって、同じ暗号化鍵に到達します。次に、公開鍵暗号手法 (公開鍵と秘密鍵を必要とする暗号化方式) を使用して共通鍵を推理します。この共通鍵は、クライアントとサーバだけが推理できる鍵です。対話鍵は、クライアントのタイムスタンプを暗号化および復号化するために使用されます。共通鍵は、この対話鍵を暗号化および復号化するために使用されます。

KERB 認証

Kerberos は MIT で開発された認証方式です。Kerberos での暗号化は DES に基づいています。

Kerberos はユーザのログインパスワードを認証することにより機能します。ユーザは kinit コマンドを入力しますが、このコマンドは、認証サーバからセッション時間 (またはデフォルトセッション時間の 8 時間) の間有効であるチケットを得ます。ユーザがログアウトするときに、このチケットは kdestroy コマンドを使って削除できます。

Kerberos ソフトウェアは、SunOS ソフトウェアの一部ではなく、 MIT の Athena プロジェクトから入手できます。SunOS ソフトウェアは次のソフトウェアを提供します。

• チケットの作成、取得、検証にクライアントが使用するルーチン

• Secure RPC の認証オプション

• クライアント側デーモン kerbd(1M)

詳細については、『Solaris のシステム管理 (第 2 巻)』の「Secure RPC の概要」を参照してください。

NFS での Secure RPC の使用

Secure RPC を使う場合は、以下の点に注意してください。

• サーバがクラッシュしたとき周囲に誰もいない場合 (停電の後など) には、システムに格納されていた秘密鍵はすべて消去されます。そのためどのプロセスからも、セキュリティ保護されたネットワークサービスにアクセスしたり NFS ファイルシステムをマウントしたりできません。リブートの際に重要なプロセスは、通常は root として実行されます。したがって、root の秘密鍵を別に保存してあればこれらのプロセスを実行できますが、周囲に誰もいない状況では秘密鍵を復号化するパスワードを入力するユーザがいません。keylogin -r を使うと root の秘密鍵がそのまま /etc/.rootkey に格納され、keyserv がそれを読み取ります。

• システムによっては、シングルユーザモードでブートし、コンソールには root のログインシェルが表示されてパスワードの入力が要求されないことがあります。このような場合には、物理的なセキュリティが不可欠です。

• ディスクレスコンピュータのブートは、完全に安全とはいえません。ブートサーバになりすましてリモートコンピュータに対する秘密鍵の入力を記録するような、不正なカーネルを誰かがブートすることが考えられます。Secure NFS システムによって保護されているのはカーネルとキーサーバが起動した後だけです。それまでの間に、ブートサーバからの応答を認証する手段はありません。これは重大な問題につながる可能性がありますが、この部分を攻撃するにはカーネルのソースコードを使った高度な技術が必要です。また、不法行為の痕跡が残ります。すなわち、ネットワークを通じてブートサーバにポーリングすれば、不正なブートサーバの位置が分かります。

• ほとんどの setuid プログラムは root が所有者です。root の秘密鍵が /etc/.rootkey に格納されていれば、これらのプログラムは正常に動作します。しかし、ユーザが所有者である setuid プログラムは動作しない可能性があります。たとえば、ある setuid プログラムの所有者が dave であり、ブート以降 dave が 1 度もログインしていないと、このプログラムはセキュリティ保護されたネットワークサービスにはアクセスできません。

• リモートコンピュータに (login、rlogin、または telnet を使って) ログインし、keylogin を使ってアクセスすると、自分のアカウントへのアクセスを許したことになります。これは、秘密鍵が相手側のコンピュータのキーサーバに渡され、キーサーバがその秘密鍵を格納したためです。これが問題になるのは、相手側のリモートコンピュータを信用できない場合だけです。しかし、疑いがある場合にはパスワードを要求するリモートコンピュータにはログインしないでください。代わりに NFS 環境を使って、そのリモートコンピュータから共有されているファイルシステムをマウントします。または、keylogout を使ってキーサーバから秘密鍵を消去します。

• ホームディレクトリが共有されていて -o sec=dh オプションか -o sec=krb4 が指定されていると、リモートログインによって問題が生じる可能性があります。/etc/hosts.equiv ファイルか /.rhosts ファイルでパスワードを要求しないように設定すると、ユーザはログインできますが、ローカルで認証が行われていないために自分のホームディレクトリにアクセスできません。パスワードを要求され、入力したパスワードがネットワークパスワードと一致すれば自分のホームディレクトリにアクセスできます。