Java セキュリティーアーキテクチャー: -

8 検討事項および将来の方針

8.1 リソース消費管理

リソース消費管理では、アプリケーションが同時にポップアップさせるウィンドウの数を制限する場合などは、比較的簡単に実装できます。しかし、メモリーやファイルシステムの使用を制限する場合など、実装が非常に困難な場合もあります。将来、この問題を一貫性のある方法で解決する予定です。

8.2 アクセス権を任意にグループ化する

数多くのアクセス権をグループ化し、それぞれに略称を付けると便利な場合があります。たとえば、「SuperPermission」という名前のアクセス権に FilePermission("-", "read,write") と SocketPermission("*", "connect,accept") の両方を含めたい場合、技術的には Permissions クラスまたは同様のクラスの add メソッドを使用して、目的のアクセス権を追加することにより、この SuperPermission を実装できます。ただし、このようなグループ化は、複雑になる可能性があります。

次のようなさらに難しい問題もあります。まず、上記の SuperPermission を与えた場合、実際に与えたアクセス権が何かを理解する必要があります。そのために固定アクセス権クラスまたは名前付きアクセス権クラスのどちらかを作成して、静的に指定されたアクセス権のグループを示すか、メンバーのアクセス権をポリシーファイルに正式な名前で記載する必要があります。次に、グループ化されたアクセス権を拡張する必要があるため、ポリシーファイルの処理はさらに複雑になります。グループ化されたアクセス権のネスト化は、処理をさらに複雑にします。

8.3 オブジェクトレベルでの保護

Java プログラミング言語はオブジェクト指向言語であるため、適切なオブジェクトレベルの保護メカニズムは、開発者にとって有益であると考えられます。オブジェクトレベルの保護メカニズムは、(1) Java プログラミング言語が提供する保護機能を越え、(2) スレッドベースのアクセス制御メカニズムを追加します。

SignedObject は、そのようなメカニズムの 1 つです。このプリミティブに対応して、オブジェクトの内容を隠すために暗号を使用する SealedObject を提供します。現在の米国の暗号に関する輸出規制条例により、SealedObject クラスは SDK とは別に提供されます。

GuardedObject は、クラスおよびオブジェクトごとに、またメソッドレベルごとにアクセス制御を実施する一般的な方法です。ただし、この種の制御は上位レベルでの管理が困難なため、この方法は選択的に、また部分的に使用する必要があります。

8.4 保護ドメインの分割

現時点では実装されていませんが、有用と思われる概念に「サブドメイン」があります。サブドメインとは、別のドメインに含まれているドメインのことです。サブドメインは、それを含むドメインほどのアクセス権や特権は持っていません。たとえば、ドメインを作成して、プログラムの実行機能を選択的に制限することができます。

ドメインは、継承機能をサポートしているとみなされることがあります。サブドメインは、親ドメインのセキュリティー属性を自動的に継承します。ただし、親ドメインがサブドメインに対し明示的に制限した場合は除きます。正当な継承によりサブドメインの制限を緩めることは、信頼性の高いコードの場合に有用な方法です。

便宜的に、システムドメインを、すべてのシステムコードの単一の大きな集合体と考えることができます。ただし、保護機能を高めるためには、システムコードを複数のシステムドメインで実行する必要があります。その場合、各ドメインは特定の種類のリソースを保護し、また各ドメインには一式の特別なアクセス権が与えられます。たとえば、ファイルシステムコードおよびネットワークシステムコードが別々のドメインで実行されている場合、前者はネットワークリソースに対するアクセス権がなく、後者はファイルシステムリソースに対するアクセス権を持ちません。この場合 1 つのシステムドメインのリスクおよびエラーの結果、またはセキュリティーフローは、そのシステムドメインの範囲内に限定されます。

8.5 署名付きコンテンツでのアプレットの実行

JAR およびマニフェスト仕様のコード署名では、非常に柔軟な署名の形式が可能です。同じアーカイブ内の複数のクラスを異なる鍵で署名することも、1 つのクラスに対して、未署名にしたり、1 つの鍵で署名したり、複数の鍵で署名したりすることも可能です。オーディオクリップおよびグラフィックイメージなどアーカイブ内のほかのリソースも、クラスと同様に署名したり未署名にすることができます。

この柔軟性のために、解釈が問題になります。特に複数の鍵が別々に処理される場合に、次の事項を明確にしなければなりません。

1. Should images and audios be required to be signed with the
   same key if any class in the archive is signed?
2. If images and audios are signed with different keys, can
   they be placed in the same appletviewer (or browser page),
   or should they be sent to different viewers for processing?

これらの事項を明確にするのは、容易なことではありません。また、効率を高めるためにプラットフォーム間およびプロダクト間に一貫性を持たせる必要もあります。一時的な解決策は、署名付きかどうかに関係なくすべてのイメージおよびオーディオクリップを転送して、同じアプレットクラスローダーで処理するという簡単なものです。この一時的な解決策は、ひとたびコンセンサスが得られれば改善されていくと思われます。

さらに、クラスファイルのバイトコードの内容が JAR の署名付きハッシュ値に一致しないために、デジタル署名を検証できない場合、JAR 作成者の本来の意図に反して、セキュリティー例外がスローされます。以前は、そのようなコードを信頼されないコードとして実行するという提案がなされていました。しかし、アプレットのクラスローダーは、複数の組織によって署名が付けられたコードのロードを許可するため、この提案は望ましいものではありません。つまり、部分的に修正された JAR ファイルを受け入れると、信頼されないコードの一部の実行、および同じクラスローダーによるほかのコードへのアクセスを許可してしまいます。

目次 | 前へ | 次へ

連絡先