目次|前|次

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

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

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

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

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

詳しい説明を参照 [D]

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

詳しい説明を参照 [D]

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

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

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

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

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

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

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

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


目次|前|次
Copyright © 1993, 2020, Oracle and/or its affiliates. All rights reserved.