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

2 新しい保護メカニズム -- 基本概念の概要

ここからは、新しい保護アーキテクチャーの概要を少し詳しく述べ、その機能について簡単に説明します。最初に、新しいアーキテクチャーの背後にある基本概念の概要を説明します。次に、主要な新しいクラスを系統的に紹介します。アクセス権の指定、ポリシーと関連機能、アクセス制御とその使用法、クラスの安全なロードと解決の順に説明します。

システムセキュリティーの基本概念であり重要な構築ブロックであるのが、保護ドメイン [Saltzer and Schroeder 75] です。ドメインとは、あるプリンシパルが現在直接にアクセスできるオブジェクトのセットであると考えられます。ここでプリンシパルとは、アクセス権を与えられる (その結果としての責任がある)、コンピュータシステム内の存在を意味します。JDK 1.0 で使用される sandbox は、固定された境界を持つ保護ドメインの一例です。

保護ドメインの概念は、保護の単位のグループ化と分離に便利なメカニズムとして働きます。たとえば、許可された相互動作が必ず、信頼できるシステムコードを通じたものか、関係するドメインによって明示的に許可されたもののどちらかであるようにするために、保護ドメインを分離して相互動作ができないようにすることができます。ただしこの機能は、まだ組み込み機能としては提供されていません。オブジェクトアクセスに関する既存の規則は、新しいセキュリティーアーキテクチャーの元でも有効であることに注意してください。

保護ドメインは、一般に 2 つの異なるカテゴリ、つまりシステムドメインとアプリケーションドメインに分類されます。重要な点は、「ファイルシステムやネットワーク設備、画面やキーボードなどの保護された外部リソースはすべて、システムドメインを通じてだけアクセスできる」ということです。次の図は、Java アプリケーション環境のドメイン構成です。

[D]

ドメインには、概念上、各クラスのインスタンスに同一のアクセス権セットが与えられている 1 組のクラスが含まれます。保護ドメインは、現在有効なポリシーによって決定されます。Java アプリケーション環境は、次の図のように、コード (クラスとインスタンス) から保護ドメインへ、さらに保護ドメインのアクセス権へのマッピングを保持します。

[D]

実行のスレッド (これはたいてい 1 つの Java スレッドに結びつくが、必ずしもその必要はなく、また背後のオペレーティングシステムのスレッドの概念に結びつく必要もない) は、単一の保護ドメインの範囲内で発生することもあり、またアプリケーションドメインとシステムドメインに関係することもあります。たとえば、出力ストリームへの唯一のアクセスポイントはシステムドメインなので、メッセージを出力するアプリケーションにはシステムドメインとの相互動作が必要です。この場合に重要なのは、アプリケーションがシステムドメインを呼び出すことによって、それ以外のアクセス権を獲得することが決してないことです。そうでない場合、セキュリティー上重要な問題が発生する可能性があります。

逆に、たとえば AWT システムドメインがあるアプレットのペイントメソッドを呼び出して、そのアプレットを表示する場合のように、システムドメインがアプリケーションドメインからメソッドを起動する場合は、有効なアクセス権が、そのアプリケーションドメインで現在有効になっているアクセス権と同一のものであることが重要です。

つまり、「弱い」ドメインは、強いドメインを呼び出した結果として、または強いドメインに呼び出された結果として追加のアクセス権を得ることはできません。

2 つの保護ドメインに関係するスレッドについてのこの議論は、複数の保護ドメインにまたがるスレッドにも当然あてはめて考えることができます。アクセス権の計算には、次のような簡潔で賢明な経験則があります。

実行スレッドのアクセス権のセットは、その実行スレッドが関係するすべての保護ドメインのアクセス権の共通部分であると考えられる。
コードの一部により doPrivileged メソッド (次を参照) が呼び出されると、1 つのアクセス権が得られる。ただし、そのアクセス権のセットがそのコードの保護ドメインと、それ以降直接的または間接的に呼び出される (または入れられる) すべての保護ドメインに許可されていることが条件になると考えられる。

doPrivileged メソッドは、ある信頼できるコードの一部が、その呼び出し元のアプリケーションから直接利用できるリソースより多くのリソースに、一時的にアクセスできるようにします。これは、次のような場合に必要になります。たとえば、あるアプリケーションがフォントが入ったファイルへの直接のアクセスを許可されていないときに、ドキュメントを表示するシステムユーティリティーがユーザーに代わってそのフォントを取得する必要がある場合などです。この状況に対処するために、システムドメインに doPrivileged メソッドが用意されました。実際には、このメソッドはすべてのドメインが利用できます。

実行中に重要なシステムリソースへのアクセス (ファイル入出力やネットワーク入出力など) が要求されると、リソースを管理するコードは特別な AccessController クラスメソッドを直接または間接的に呼び出し、その要求を評価して、要求を認めるかどうかを判断します。

この評価方法は、上記の経験則に従っており、それを一般化するものです。実際の評価の実施方法は、実装によって異なります。基本的には、呼び出し履歴と、関係する保護ドメインに与えられているアクセス権を調べ、要求が許可される場合にはそのまま復帰し、要求が拒否される場合にはセキュリティー例外をスローします。

最後に、各ドメイン (システムドメインまたはアプリケーションドメイン) は、さらに自分のドメイン境界内の内部リソースの保護を実装できます。たとえば、銀行取引のアプリケーションでは、当座預金、普通預金、預金引き出しなどの内部概念を保護する必要があります。このような保護のセマンティクスは、Java 2 SDK によって予測したり強制したりできないと考えられるので、このレベルの保護システムは、システムやアプリケーションの開発者に任せるのが最良です。しかし、私たちは、開発者のタスクを簡単にするために役立つ基本要素を、できるかぎり提供します。このような基本要素のひとつに SignedObject クラスがあります。このクラスについては、あとで詳しく説明します。

目次 | 前へ | 次へ

連絡先