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 保護ドメインの分割

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

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

便宜的に、システム・ドメインを、すべてのシステム・コードの単一の大きな集合体と考えることができます。ただし、保護を強化するためには、システム・コードを複数のシステム・ドメインで実行すべきであり、その場合、各ドメインは特定のタイプのリソースを保護し、一連の特別なアクセス権が与えられます。たとえば、ファイル・システム・コードおよびネットワーク・システム・コードが別々のドメインで実行されており、前者はネットワーク・リソースに対するアクセス権がなく、後者はファイル・システム・リソースに対するアクセス権を持たない場合、一方のシステム・ドメインのエラーやセキュリティ問題のリスクや結果は、その境界内に限定される可能性が高くなります。

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ファイルを受け入れると、信頼されないコードの一部の実行、および同じクラス・ローダーによるほかのコードへのアクセスを許可してしまいます。

目次|前|次

連絡先