目次|前|次 |
add
メソッドを使用して、目的のアクセス権を追加することにより、このSuperPermissionを実装できます。ただし、このようなグループ化は、複雑になる可能性があります。
次のようなさらに難しい問題もあります。まず、前述のSuperPermissionを与えた場合、実際に与えたアクセス権が何かを理解する必要があります。そのために固定アクセス権クラスまたは名前付きアクセス権クラスのどちらかを作成して、静的に指定されたアクセス権のグループを示すか、メンバーのアクセス権をポリシー・ファイルに正式な名前で記載する必要があります。次に、グループ化されたアクセス権を拡張する必要があるため、ポリシー(ファイル)の処理はさらに複雑になることがあります。グループ化されたアクセス権のネスト化は、処理をさらに複雑にします。
SignedObjectは、そのようなメカニズムの1つです。このプリミティブに対応して、オブジェクトの内容を隠すために暗号を使用するSealedObjectを提供します。現在の米国の暗号に関する輸出規制条例により、SealedObjectクラスはSDKとは別に提供されます。
GuardedObjectは、クラスおよびオブジェクトごとに、またメソッド・レベルごとにアクセス制御を実施する一般的な方法です。ただし、この種の制御は上位レベルでの管理が困難なため、この方法は選択的に、また部分的に使用する必要があります。
ドメインは、継承機能をサポートしているとみなされることがあります。サブドメインは、親ドメインのセキュリティ属性を自動的に継承します。ただし、親ドメインがさらにサブドメインを明示的に制限した場合は除きます。正当な継承によりサブドメインの制限を緩めることは、信頼性の高いコードの場合に有用な方法です。
便宜的に、システム・ドメインを、すべてのシステム・コードの単一の大きな集合体と考えることができます。ただし、保護を強化するためには、システム・コードを複数のシステム・ドメインで実行すべきであり、その場合、各ドメインは特定のタイプのリソースを保護し、一連の特別なアクセス権が与えられます。たとえば、ファイル・システム・コードおよびネットワーク・システム・コードが別々のドメインで実行されており、前者はネットワーク・リソースに対するアクセス権がなく、後者はファイル・システム・リソースに対するアクセス権を持たない場合、一方のシステム・ドメインのエラーやセキュリティ問題のリスクや結果は、その境界内に限定される可能性が高くなります。
この柔軟性のために、解釈が問題になります。特に複数の鍵が別々に処理される場合に、次の事項を明確にしなければなりません。
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ファイルを受け入れると、信頼されないコードの一部の実行、および同じクラス・ローダーによるほかのコードへのアクセスを許可してしまいます。