1 はじめに

Java テクノロジの誕生当初から、Java プラットフォームのセキュリティには強い関心が寄せられ、Java テクノロジの展開により発生するセキュリティ問題とともに、ますます関心が高まっています。

テクノロジの提供者側の視点から見ると、Java のセキュリティには次の 2 つの側面があります。

• Java 対応のアプリケーションが安全に実行される、安全な既製プラットフォームとして 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 仮想マシンにより、実行時の言語の安全性が保証されます。

さらに、クラスローダはローカルな名前空間を定義します。 これによって、信頼できないアプレットが他のプログラムの実行を妨害しないようにすることができます。

最後に、非常に重要なシステム資源へのアクセスには Java 仮想マシンが介在し、あらかじめ SecurityManager クラスによってチェックされます。 このクラスは、信頼できないコードの動作を最小限に制限します。

JDK 1.1 には、下の図に示すような「署名付きアプレット」の概念が導入されました。 JDK 1.1 では、正しくデジタル署名されたアプレットは、そのアプレットを受け取ったエンドシステムがその署名キーを信頼できると認めた場合には、ローカルコードと同様に扱われます。 署名付きアプレットは、署名キーとともに JAR (Java Archive) 形式で届けられます。 JDK 1.1 では、署名付きアプレットも sandbox 内で実行します。

1.2 sandbox モデルの改良

新しい Java 2 プラットフォームのセキュリティアーキテクチャを次の図に示します。 新しいアーキテクチャ導入の主な目的は、次のとおりです。

• 精密なアクセス制御

この機能は当初から JDK にありましたが、アプリケーションでこれを使用するには、負担の大きなプログラミングが必要でした (SecurityManager クラスと ClassLoader クラスのサブクラス化およびそのカスタマイズなど)。 HotJava Broswer 1.0 は、このようなアプリケーションのひとつで、ブラウザのユーザには少数のセキュリティレベルからの選択だけが許されます。

しかし、このようなプログラミングでは、セキュリティについて細かく考慮する必要があるため、高度な技能とコンピュータセキュリティに関する深い知識が要求されます。 新しいアーキテクチャにより、この課題がより簡単で安全になります。

• 簡単に設定できるセキュリティポリシー

この機能も以前から JDK にありましたが、使い方は易しくありませんでした。 また、セキュリティコードを記述するのも簡単な作業ではないので、アプリケーションの開発者とユーザがプログラムを記述することなくセキュリティポリシーを設定できることが望まれます。

• 簡単に拡張できるアクセス制御構造

JDK 1.1 までは、新しいアクセス権を作成するには SecurityManager クラスに新しい check メソッドを追加する必要がありました。 新しいアーキテクチャでは、タイプ指定されたアクセス権 (それぞれが 1 つのシステム資源へのアクセスを表す) が許され、正しいタイプの (現段階で未定義のアクセス権も含めて) すべてのアクセス権の自動処理が許されます。 ほとんどの場合、SecurityManager クラスに新しいメソッドを作成する必要はありません。 事実、これまでのところ、新しいメソッドの作成は必要になっていません。

• アプリケーションとアプレットを含む、すべての Java プログラムへのセキュリティチェックの拡張

すべてのローカルコードが信頼できるという組み込みの概念は、なくなりました。 ローカルコード (システムコード以外のコード、ローカルファイルシステムにインストールされたアプリケーションパッケージなど) は、アプレットと同じセキュリティ管理を受けます。 ただし、ローカルコード (またはリモートコード) のポリシーを自由度が最高であると宣言すれば、事実上そのコードは完全に信頼できるものとして実行されます。 同様の原則が署名付きアプレットおよびすべての Java アプリケーションに当てはまります。

最後に、今後のプログラミングで隠れたセキュリティホールを作り出す危険を減らすために、セキュリティクラス (SecurityManager クラスと ClassLoader クラスを含む) の設計を内部的に調整するという暗黙の目標があります。