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