| 目次|前|次 |
1 はじめに
Javaテクノロジの誕生当初から、Javaプラットフォームのセキュリティには強い関心が寄せられ、Javaテクノロジの展開により発生する新しいセキュリティ問題とともに、ますます関心が高まっています。テクノロジの提供者側の視点から見ると、Javaのセキュリティには次の2つの側面があります。
- Java対応のアプリケーションが安全に実行される、安全な既製プラットフォームとしてJavaプラットフォームを提供すること。
- セキュリティを考慮した広範なアプリケーションを(たとえば企業内で)実行可能にするツールとサービスをJavaプログラミング言語に実装して提供すること。
1.1 オリジナルのsandboxモデル
Javaプラットフォームの提供するオリジナルのセキュリティ・モデルは、サンドボックス・モデルとして知られています。これは、オープン・ネットワークから取得した信頼できないコードを実行するための、厳しく制限された環境を提供するためのものです。サンドボックス・モデルの本質は、「ローカル・コードは信頼できるので、非常に重要なシステム・リソース(ファイル・システムなど)へのフル・アクセス権を持つ。一方、ダウンロードされたリモート・コード(アプレット)は信頼できないので、サンドボックスの中のかぎられたリソースにのみアクセスできる」というものです。このサンドボックス・モデルを次の図に示します。
sandboxモデルは、JDK (Java Development Kit)を通じて広まり、JDK 1.0を使って作成されたアプリケーションに一般的に採用されました。これらのアプリケーションには、Java対応のWebブラウザも含まれます。
多くのメカニズムによってセキュリティ全体が強化されます。まず、この言語は、型保証されるように設計されており、簡単に使用できます。CやC++などの他のプログラミング言語を使用する場合に比べ、無意識なミスを少なくし、プログラマの負担を軽くすることが期待されます。自動メモリー管理、ガベージ・コレクション、文字列や配列の範囲チェックなどの言語の機能は、プログラマが安全なコードを書くためにこの言語がどれだけ役立つかを示す例です。
次に、コンパイラとバイトコード・ベリファイアにより、正当なJavaバイト・コードだけが実行されます。バイトコード・ベリファイアとJava Virtual Machineにより、実行時の言語の安全性が保証されます。
さらに、クラス・ローダーはローカルな名前空間を定義します。これによって、信頼できないアプレットがほかのプログラムの実行を妨害しないようにすることができます。
最後に、非常に重要なシステム・リソースへのアクセスにはJava Virtual Machineが介在し、あらかじめSecurityManagerクラスによってチェックされます。このクラスは、信頼できないコードの動作を最小限に制限します。
JDK 1.1には、下の図に示すような「署名付きアプレット」の概念が導入されました。そのリリースでは、正しくデジタル署名されたアプレットは、そのアプレットを受け取ったエンド・システムがその署名鍵を信頼できると認めた場合には、信頼できるローカル・コードと同様に扱われます。署名付きアプレットは、署名鍵とともにJAR (Java Archive)形式で届けられます。JDK 1.1では、署名付きアプレットもsandbox内で実行します。
1.2 sandboxモデルの改良
新しいJava SEプラットフォームのセキュリティ・アーキテクチャを次の図に示します。新しいアーキテクチャ導入の主な目的は、次のとおりです。
[D]
この機能は当初からJDKにありましたが、アプリケーションでこれを使用するには、負担の大きなプログラミングが必要でした(SecurityManagerクラスとClassLoaderクラスのサブクラス化およびそのカスタマイズなど)。HotJava Browser 1.0は、このようなアプリケーションのひとつで、ブラウザのユーザーには少数のセキュリティ・レベルからの選択だけが許されます。
しかし、このようなプログラミングでは、セキュリティについて細かく考慮する必要があるため、高度な技能とコンピュータ・セキュリティに関する深い知識が要求されます。新しいアーキテクチャにより、この課題がより簡単で安全になります。
この機能も以前からJDKにありましたが、使い方はやさしくありませんでした。また、セキュリティ・コードを記述するのも簡単な作業ではないので、アプリケーションの開発者とユーザーがプログラムを記述することなくセキュリティ・ポリシーを構成できることが望まれます。 JDK 1.1までは、新しいアクセス権を作成するにはSecurityManagerクラスに新しいcheckメソッドを追加する必要がありました。新しいアーキテクチャでは、型指定されたアクセス権(それぞれが1つのシステム・リソースへのアクセスを表す)が許され、正しい型の(現段階で未定義のアクセス権も含めて)すべてのアクセス権の自動処理が許されます。ほとんどの場合、SecurityManagerクラスに新しいメソッドを作成する必要はありません。事実、これまでのところ、新しいメソッドの作成は必要になっていません。
すべてのローカル・コードが信頼できるという組込みの概念は、なくなりました。ローカル・コード(システム・コード以外のコード、ローカル・ファイル・システムにインストールされたアプリケーション・パッケージなど)は、アプレットと同じセキュリティ制御の対象となりますが、必要に応じて、ローカル・コード(またはリモート・コード)のポリシーを最高の自由度として宣言できるため、事実上そのコードは完全に信頼できるものとして実行できます。同様の原則が署名付きアプレットおよびすべてのJavaアプリケーションに当てはまります。
最後に、今後のプログラミングで隠れたセキュリティ・ホールを作り出す危険を減らすために、セキュリティ・クラス(SecurityManagerクラスとClassLoaderクラスを含む)の設計を内部的に調整するという暗黙の目標があります。
目次|前|次