| 目次 | 前の項目 | 次の項目 | Java セキュリティアーキテクチャ |
現在、各 JVM は、個々のユーザによって所有されているため、主体 (ユーザなど) という概念は、暗黙の内に了解されています。 将来的は、既存の保護ドメインの概念を拡張して、主体の「代理実行」という概念を含める必要があります。
リソース消費管理では、アプリケーションが同時にポップアップさせるウィンドウの数を制限する場合などは、比較的簡単に実装できます。 しかし、メモリやファイルシステムの使用を制限する場合など、実装が非常に困難な場合もあります。 将来、この問題を一貫性のある方法で解決する予定です。
数多くのアクセス権をグループ化し、それぞれに略称を付けると便利な場合があります。 たとえば、「SuperPermission」という名前のアクセス権に FilePermission("-", "read,write") と SocketPermission("*", "connect,accept") の両方を含めたい場合、技術的には Permissions クラスまたは同様のクラスの add() メソッドを使用して、目的のアクセス権を追加することにより、この SuperPermission を実装できます。 ただし、このようなグループ化は、複雑になる可能性があります。次のようなさらに難しい問題もあります。 まず、上記の SuperPermission を与えた場合、実際に与えたアクセス権が何かを理解する必要があります。 そのために固定クラスまたは名前付きクラスのどちらかを作成して、静的に指定されたアクセス権のグループを示すか、メンバのアクセス権をポリシーファイルに正式な名前で記載する必要があります。 次に、グループ化されたアクセス権を拡張する必要があるため、ポリシーファイルの処理はさらに複雑になります。 グループ化されたアクセス権のネスト化は、処理をさらに複雑にします。
Java プログラミング言語はオブジェクト指向言語であるため、適切なオブジェクトレベルの保護機構は、開発者にとって有益であると考えられます。 オブジェクトレベルの保護機構は、(1) Java 言語が提供する保護機能を越え、(2) スレッドベースのアクセス制御機構を追加します。SignedObject は、そのような機構の 1 つです。 このプリミティブに対応して、オブジェクトの内容を隠すために暗号を使用する SealedObject を提供します。 現在の米国の暗号に関する輸出規制条例により、SealedObject クラスは SDK とは別に提供されます。
GuardedObject は、クラスおよびオブジェクトごとに、またメソッドごとにアクセス制御を実施する一般的な方法です。 ただし、この種の制御は上位レベルでの管理が困難なため、この方法は選択的に、また部分的に使用する必要があります。
現時点では実装されていませんが有用と思われる概念に「サブドメイン」があります。 サブドメインとは、別のドメインに含まれているドメインのことです。 サブドメインは、それを含むドメインほどのアクセス権や特権は持っていません。 たとえば、ドメインを作成して、プログラムの実行機能を選択的に制限することができます。ドメインは、継承機能をサポートしているとみなされることがあります。 サブドメインは、親ドメインのセキュリティ属性を自動的に継承します。 ただし、親ドメインがサブドメインに対し明示的に制限した場合は除きます。 正当な継承によりサブドメインの制限を緩めることは、信頼性の高いコードの場合に有用な方法です。
便宜的に、システムドメインを、すべてのシステムコードの単一の大きな集合体と考えることができます。 ただし、保護機能を高めるためには、システムコードを複数のシステムドメインで実行する必要があります。 その場合、各ドメインは特定の種類のリソースを保護し、また各ドメインには一式の特別なアクセス権が与えられます。 たとえば、ファイルシステムコードおよびネットワークシステムコードが別々のドメインで実行されている場合、前者はネットワークリソースに対するアクセス権がなく、後者はファイルシステムリソースに対するアクセス権を持ちません。 この場合 1 つのシステムドメインのリスクおよびエラーの結果、またはセキュリティフローは、そのシステムドメインの範囲内に限定されます。
JAR およびマニフェスト仕様のコード署名では、非常に柔軟な署名の形式が可能です。 同じアーカイブ内の複数のクラスを異なる鍵で署名することも、1 つのクラスに対して、未署名にしたり、1 つの鍵で署名したり、複数の鍵で署名したりすることも可能です。 オーディオクリップおよびグラフィックイメージなどアーカイブ内の他のリソースも、クラスと同様に署名したり未署名にすることができます。この柔軟性のために、解釈が問題になります。 特に複数の鍵が別々に処理される場合に、次の事項を明確にしなければなりません。
1. アーカイブ内のどれかのクラスが署名されている場合、イメージおよびオーディオは 同じ鍵で署名することが必要かどうか 2. イメージおよびオーディオが異なる鍵で署名されている場合、それらを同じアプレット ビューア (またはブラウザのページ) に配置することは可能か。あるいは、別の ビューアに送って処理することが必要かどうか
これらの事項を明確にするのは、容易なことではありません。 また、効率を高めるためにプラットフォーム間およびプロダクト間に一貫性を持たせる必要もあります。 一時的な解決策は、署名付きかどうかに関係なくすべてのイメージおよびオーディオクリップを転送して、同じアプレットクラスローダで処理するという簡単なものです。 この一時的な解決策は、ひとたびコンセンサスが得られれば改善されていくと思われます。さらに、クラスファイルのバイトコードの内容が JAR の署名付きハッシュ値に一致しないために、デジタル署名を検証できない場合、JAR 作成者の本来の意図に反して、セキュリティ例外がスローされます。 以前は、そのようなコードを信頼されないコードとして実行するという提案がなされていました。 しかし、アプレットのクラスローダは、複数の組織によって署名が付けられたコードのロードを許可するため、この提案は望ましいものではありません。 つまり、部分的に修正された JAR ファイルを受け入れると、信頼されないコードの一部の実行、および同じクラスローダによるほかのコードへのアクセスを許可してしまいます。