NFS 環境は、アーキテクチャーやオペレーティングシステムの異なるコンピュータから構成されるネットワーク上でファイルシステムを共有するための強力で使いやすい手段です。しかし、NFS の操作によるファイルシステムの共有を便利にする機能が、一方ではセキュリティー上の問題につながっています。今まで、NFS はほとんどのバージョンで UNIX (AUTH_SYS) 認証を使用してきましたが、現在では AUTH_DH のようなより強力な認証方式も使用可能です。UNIX 認証を使用している場合、NFS サーバーはユーザーではなくファイル要求を行ったコンピュータを認証することで要求を認証します。したがって、クライアントユーザーはスーパーユーザーになるために suを実行し、ファイルの所有者を偽装できます。DH 認証では、NFS サーバーはユーザーを認証するため、このような操作が困難になります。
ルートアクセス権とネットワークプログラミングについての知識があれば、だれでも任意のデータをネットワークに取り入れたり、任意のデータをネットワークから取り出したりできます。もっとも危険な攻撃にはデータの持ち込みが伴います。たとえば、有効なパケットを生成したり、または「対話」を記録し後で再生することによってユーザーを装うなどの手段があります。これらはデータの整合性に影響を与えます。ユーザーを装わず、単にネットワークトラフィックを傍受するための受動的な盗聴が行われる攻撃であれば、データの整合性が損なわれることはないため、それほど危険ではありません。ネットワーク上でやりとりされるデータを暗号化すると、機密情報のプライバシを保護できます。
ネットワークのセキュリティー問題に対する共通の対処方法は、解決策を各アプリケーションにゆだねることです。さらに優れた手法としては、すべてのアプリケーションを対象として、標準の認証システムを導入することです。
Oracle Solaris オペレーティングシステムには、NFS の操作が構築されるメカニズムである RPC のレベルで、認証システムが組み込まれています。このシステムは Secure RPC と呼ばれ、ネットワーク環境のセキュリティーを大幅に向上させるとともに、NFS のセキュリティーを強化します。Secure RPC が提供する機能を利用した NFS システムを Secure NFS システムといいます。
Secure RPC は Secure NFS システムの基盤です。Secure RPC の目標は、少なくともタイムシェアリングシステム程度に安全なシステムを構築することです。タイムシェアリングシステムでは、すべてのユーザーが 1 つのコンピュータを共有し、ユーザーはログインパスワードによって認証されます。データ暗号化規格 (DES) 認証でも、同じ認証処理が実行されます。ユーザーは、ローカル端末の場合と同じように、任意のリモートコンピュータにログインできます。ユーザーのログインパスワードは、ネットワークセキュリティーへの保証です。タイムシェアリングでは、システム管理者は信頼のおける人で、パスワードを変更してだれかを装うようなことはしないという道徳上の義務を負います。Secure RPC では、ネットワーク管理者は「公開鍵」を格納するデータベースのエントリを変更しないという前提で信頼されています。
RPC 認証システムは、資格とベリファイアを使用します。ID バッジを例にとれば、 資格とは、名前、住所、誕生日など個人を識別するものです。ベリファイアとはバッジに添付された写真です。バッジの写真をその所持者と照合することによって、そのバッジが盗まれたものではないことを確認できます。RPC では、クライアントプロセスは RPC 要求のたびに資格とベリファイアの両方をサーバーに送信します。クライアントはサーバーの資格をすでに知っているため、サーバーはベリファイアだけを送り返します。
RPC の認証は拡張が可能で、UNIX、DH、および KERB などのさまざまな認証システムを組み込むことができます。
ネットワークサービスで UNIX 認証を使用する場合、資格にはクライアントのホスト名、UID、GID、グループアクセスリストが含まれます。ただし、ベリファイアが存在しないため、スーパーユーザーは su などのコマンドを使用して、適切な資格を偽ることができます。もう 1 つの問題は、ネットワーク上のすべてのコンピュータを UNIX コンピュータと想定していることです。UNIX 認証を異機種ネットワーク内の他のオペレーティングシステムに適用した場合、これは正常に動作しません。
UNIX 認証の問題を克服するために、Secure RPC では DH 認証を使用します。
DH 認証は、Data Encryption Standard (DES) と Diffie-Hellman 公開鍵暗号手法を使ってネットワーク上のユーザーとコンピュータの両方を認証します。DES は、標準の暗号化メカニズムです。Diffie-Hellman 公開鍵暗号手法は、2 つの鍵、つまり公開鍵と秘密鍵を持つ暗号方式です。 公開鍵と秘密鍵は名前空間に格納されます。NIS では、これらの鍵は public-key マップに保存されています。これらのマップにはすべての認証の候補ユーザーの公開鍵と秘密鍵が入っています。マップの設定方法に関する詳細は、Oracle Solaris 11.2 ディレクトリサービスとネームサービスでの作業: DNS と NIS を参照してください。
DH 認証のセキュリティーは、送信側が現在時間を暗号化する機能に基づいていて、受信側はこれを復号化して、自分の時間と照合します。タイムスタンプは DES を使用して暗号化されます。2 つのエージェントは現在の時間で同意し、送信側と受信側が同じ暗号化鍵を使用する必要があます。
ネットワークが時間同期プログラムを実行する場合、クライアントとサーバー上の時間は自動的に同期がとられます。時間同期プログラムを使用できない場合、ネットワーク時間ではなく、サーバーの時間を使ってタイムスタンプを計算できます。クライアントは、RPC セッションを開始する前にサーバーに時間を要求し、自分のクロックとサーバーのクロックとの時間差を計算します。タイムスタンプを計算するときには、この差を使ってクライアントのクロックを補正します。クライアントとサーバーのクロックが同期しなくなると、サーバーはクライアントの要求を拒否し始めます。その場合、クライアントの DH 認証システムはサーバーとの間で再び同期をとります。
クライアントとサーバーは、ランダムな対話鍵 (セッション鍵とも呼ばれる) を生成したあと公開鍵暗号方式を使って共通鍵を類推することによって、同一の暗号化鍵に到達します。この共通鍵は、クライアントとサーバーだけが推理できる鍵です。対話鍵は、クライアントのタイムスタンプを暗号化および復号化するために使用されます。共通鍵は、この対話鍵を暗号化および復号化するために使用されます。
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 オプションにより共有されていると、リモートログインによって問題が生じる可能性があります。/etc/hosts.equiv ファイルまたは ~/.rhosts ファイルに、パスワードを要求するように設定されていない場合は、ログインが成功します。ただし、ローカルで認証されていないため、ユーザーは自分のホームディレクトリにアクセスできません。ユーザーがパスワードを要求される場合には、パスワードがネットワークパスワードと一致すれば自分のホームディレクトリにアクセスできます。