JP2000508104A - 分散コンピュータ・システムにおいて資源を保護する方法 - Google Patents

Abstract

(57)【要約】 本発明は、開放型ディジタル通信システムにおいて資源を保護するための方法に関する。資源は、そのシステム、例えば、インターネットを通して接続された物理的に及び構成的に分散した独立のエンティティに存在し、又はそれによって所有される。そのような開放型システムでは、如何なるエンティティも原理的には他の任意のエンティティの任意の資源をアクセスすることができるので、資源劣化及び破壊の危険を回避又は最小化するために、プライバシ及び、必要な場合には、機密性を維持するために、予防策が取られなければならない。従って、資源の保護は、エンティティの整合性及び機能を保証するためには極めて重要なことである。そのような資源を、特に未承認のアクセスから知的に保護するために、ネーム・スペース（エンティティが提供するすべての名前より成る）の可変的なきめの細かい制御及び（又は）それぞれがファイル及び（又は）サービスを必要とする付加可能な及び分離可能なガードの設置が行われる。

Description

【発明の詳細な説明】 分散コンピュータ・システムにおいて資源を保護する方法 技術分野 本発明は、物理的に及び構成的に分散した独立のエンティティを接続する開放 型ディジタル通信システムにおいて、これらのエンティティに常駐し且つこれら のエンティティによって所有された資源を保護するための方法に関するものであ る。そのような開放型システムでは、原理的には、任意のシステムが任意の他の エンティティの任意の資源をアクセスすることができるので、エンティティの整 合性及び機能を保証するために、資源の保護は極めて重要なことである。そのよ うなシステムに関する１つの現在の例は、分散型処理ステーション、サーバ、及 びエンドユーザ・コンピュータを持ったインターネットであり、エンドユーザ・ コンピュータは資源、例えば、データ又はプログラム・ファイルを提供し且つ所 有している。本発明は、そのような資源の知的保護、更に詳しく云えば、未承認 のアクセスに対する知的保護に関するものである。 背景技術 資源共用は多くの分野における周知の概念である。不足している資源、高価な 資源、又は滅多に使用されない資源を共 用することによって、この資源を維持する負担はユーザのグループの間で分散さ れる。資源を共用するという希望と相俟って、資源を未承認の使用から保護する という希望が広まっている。通常、資源共用は資源保護を意味する。驚くほどで はないが、資源共用及び資源保護は、分散型のネットワーク化されたコンピュー タの主要な懸念事項である。偏在し且つ接続されたコンピュータが多ければ多い ほど、これらの接続されたシステムにおける資源を保護する手段を持つ必要性は 多くなる。この要求は、インターネットのような開放型ネットワークにとって特 に切実である。そのような開放型且つ分散型のネットワーク化されたシステムで は、パスワード・ファイル及び個人的な資料の如きセンシティブなデータのよう な特定の資源、或いは、ファイル・システム空間及び通信容量のようなハードウ エア資源又は暗号化サービスのようなサービスを未承認のアクセスから保護する ことは避けられないことである。ここで云う保護は、資源そのものへの基本的な アクセスと、アクセス・エンティティによるそれの使用との両方を意味する。即 ち、それは、きめの粗い資源保護（例えば、エンティティはファイル・システム ・サービスを使用することを許容される）及びきめの細かい資源保護（例えば、 エンティティはシステム・サービスを使用することを許容されるが、パスワード ・ファイルをアクセスすることはできない）の両方を意味する。 分散型システムにおける資源保護に対する現在の方法は、 多くの場合、サービス供給エンティティにおける広範な変更を多少必要とする認 証ベースの方式に依存している。例えば、１９８８年２月に発行のＵｓｅｎｉｘ 社のUsenix Conference Proceedings誌におけるJ.G.Steiner，B.C.Neuman及びJ. I.Schi1ler氏の論文「カーベロス：開放ネットワーク・システムのための認証サ ービス（Kerberos：An authentication service for open network systems）」 に開示された”カーベロス（ｋｅｒｂｅｒｏｓ）”は、暗号化されたチケットが 各サービス・リクエストと共に送られることを必要とする。ユーザは、特別委託 チケット許可サービスによって自身を認証した後、ユーザは、自分が使用する権 利があり、しかも自分が呼び出すことを望んでいる任意の他のサービスに対して 、「カーベロス」チケットをリクエストすることができる。これは、安全ではあ るけれども、資源保護という望ましい目的を達成するためには面倒な、長時間を 要する、トラフィックを増加させる方法である。更に詳しく云えば、資源保護の ためのカーベロス法は、それがサービス提供エンティティにとって透過ではなく 、しかも、呼出先エンティティ自身が呼出元エンティティからの有効なチケット であるかどうかに関して明示的にチエックを行わなければならないという意味で 、それは自由裁量的な機構であるという欠点がある。そのエンティティをインプ リメントするコードはそれそれのライブラリへのコールを含まなければならず、 有効なチケットに関してチェックするのを「忘れた」エンティティは、それ の資源へのアクセスを任意の呼出元に提供するであろう。更に、アタッカは、一 旦それが中央のチケット許可サービスと妥協すると、関連の分散型システムにお ける参加したすべてのエンティティに対するアクセスも有する。 資源保護のタスクに関するもう１つの解決方法は、１９９５年１１月発行のD. B.C1iftonを発明者とする「データ処理システムの資源へのアクセスを制御する ための資源アクセス・セキュリティ・システム（Resource access security sys tem for controlling access to resource of data processing system）」と題 した米国特許第５,４６９，５５６号に示されている。その特許は、ハードウエ アでメモリ・アドレスのような資源をアドレスするための特別オブジェクト、い わゆるデスクリプタを導入している。各デスクリプタには、特定の資源へのアク セスを制御する一組のテーブルが付加される。本質的に、このデスクリプタは資 源の仮想アドレスを形成し（上記米国特許の第３欄、第３４乃至３７行参照）、 それ自体でシステムにおける資源に対するきめ細かなアクセス制御を確立する。 資源保護のに対する上記米国特許の方法はカーベロスのように重要な弱点を被 るものではないけれども、このような弱点を免れるということはそれの欠点の１ つを表すことにもなる。上記米国特許の方法は分散型システムに適用し得ない。 なぜならば、それは、メモリ・アドレス変換機構に、従って、それのデスクリプ タを使用することによって単一のアドレス 空間に結合されるためである。分散型システム、しかし実際には定義による分散 型システムは、或る種の通信媒体によって接続された幾つものアドレス空間を含 む。更に、上記米国特許の解決方法も透過ではない。ユーザは特別のデスクリプ タを持たなければならず、従って、自分のプログラムをコード化しなければなら ない。 更に、カーベロス及び上記米国特許の方法の両方とも、システムのランタイム 中（及び資源保護機構が設定されてしまった後）に動的に現れる資源を扱うこと ができない。エンティティが外部（例えば、インターネットから入ってくるＪａ ｖａアプレット）から分散型システムに移行し得る環境においては、動的に作成 された資源が存在し、しかも、これらの資源に対する保護を提供することが必要 である。 従って、本発明の主たる目的は、動的分散型システムに適用し得る資源保護機 構を確立することにある。更なる目的は、保護されるべき資源をアクセスするこ とを望んでいるプログラム及び（又は）エンティティにとって透過である資源保 護機構を作成することにある。本発明の更にもう１つの目的は、新たに作成され た資源を保護するために、望ましくは実行時に、動的に拡張し得る資源保護のた めの方法を提供することにある。 発明の開示 分散型システムにおける未承認のアクセスに対して保護さ れるべき資源は、通常、エンティティによって、例えば、サーバ又は処理ステー ションによつて所有され或いは提供される。原理的には、各エンティティが前述 のように任意の他のエンティティの任意の資源をアクセスすることを許容される 開放分散型システムでは、セキュリティは所定の資源を保護する必要があり、し かも、所定のエンティティに対してのみ及び（又は）所定の条件の下でのみそれ らをアクセスすることを許容される。 資源は、ディスク空間、ファイル、ネットワーク接続であってもよいが、オブ ジェクト及びオブジェクト自身によって提供されるメソッドであってもよい。分 散型システムにおけるそのような資源へのアクセスは、エンティティ又はオブジ ェクトによって提供されるサービス又はメソッドを通して生じる。本発明の概念 は、資源へのアクセスをサービスへのアクセスに変えるという発想から始まる。 サービスを呼び出すために又はそれを使用するためには、そのサービスを所有す る又は供給するエンティティの名前及びそのサービス自身の名前がわからなけれ ばならない。実際にサービスにアクセスするためには、それのロケーションへの それの名前のマッピングが得られる。即ち、名前が解決される。エンティティが 知っている名前すべてがそのエンティティのネーム・スペースを形成する。同様 に、システムのエンティティ・ロケーションすべてがそのシステムのエンティテ ィ・ロケーション空間を構成する。 従って、本発明の基礎を成す基本概念は名前解決プロセスを制御することによ って、即ち、このエンティティに対するサービスの可視性を制限することによっ て、サービスへのエンティティのアクセスを制御することより成る。本発明の更 なる特徴は、例えば、「インテリジェント」インターセプト・マネージャにより この制御を実行することによって、ネーム・スペース及び名前解決プロセスの可 変的なきめ細かさの制御を提供することより成る。本発明の独立した主要な特徴 は、名前と関連し且つこの名前が使用される前又は後にコールされ、きめの細か い資源保護を提供する付加及び分離可能な「ガード」を提供することより成る。 上記の特徴のうちの１つ又は複数個を使用することによって、制御され及び制 限された環境、即ち、エンティティが自由に動作することができる動的に構成可 能な「サンドボックス」を意味する動的に構成可能な保護ドメインが作成される 。如何なる悪意による行為の影響もそのサンドボックスに制限され、従って、シ ステムの残り部分に伝播することはあり得ない。そのようなサンドボックスへの 厳密に制御された入力ポイント及びそのようなサンドボックスからの厳密に制御 された出力ポイントを提供すること、及び、更に詳しく云えば、それの形状及び サイズを動的に微細調整することも可能である。 図面の簡単な説明 第１図は、エンティティをそれのインターフェース及び資源（以下で定義され る用語）と共に示す。 第２ａ図及び第２ｂ図は、名前及びそれのオブジェクト・リファレンスをマッ ピングする方法を示す。 第３ａ図乃至第３ｃ図は、本発明による方法のステップ及び変形を示す。 第４図は、本発明のインプリメンテーションのブロック図である。 発明を実施するための最良の形態 以下には、オブジェクト・ベースの分散型ネットワーク・システムに対する一 例としてＪａｖａベースのネットワークの環境における本発明の特徴の概要が先 ずＡとして示され、それに続いて、本発明のインプリメンテーションの説明がＢ として示される。Ｊａｖａは、米国ＣＡ９４０４３−１１００マウンテン・ビュ ー、ガルシア・アベニュ−２５５０のサン・マイクロシステムズ社によって開発 されたプログラミング言語及び環境である。 Ａ．原理の概要 （ａ）Ｊａｖａ環境 以下では、Ｊａｖａコンピューティング環境に関連し、この説明において使用 される幾つかの代表的な用語をリストし、簡単に説明することにする。 ・「アプレット」は、一般に、リモート・ソースからロード されるＪａｖａバィト・コードである。それは、通常、信頼できるものとは 考えられていない。 ・「アプリケーション」は、一般に、ローカルからロードされるＪａｖａバイト コードである。それは、信頼できるものと考えられている。 ・「インターネット」は、多くの種々のサブネットワークより成るワールドワイ ドの開放型コンピュータ・ネットワークである。 ・「ワールド・ワイド・ウェブ（ＷＷＷ）」は、インターネットの開放型サブネ ットワークである。 ・「イントラネット」は、通常、インターネットのサブネットワークであって企 業内でよく使用される閉鎖型内部ネットワークである。 ・「ブラウザ」は、ワールド・ワイド・ウェブにおける捜索（サーフィン）をサ ポートするコンピュータ・ソフトウエア又は環境である。 ・「Ｊａｖａバイトコード」は、ＪＶＭ（下記参照）のためのコンパイラによっ て作られたコードである。 ・「Ｊａｖａ仮想マシン（ＪＶＭ）」は、Ｊａｖａバイトコードを実行する虚構 的であるが完全に特定されたプロセッサである。それは、そのマシンがソフ トウエアにおいてインプリメントされるので虚構的である。 ・「ライブラリ」は、プログラムにおいて使用するための定義された機能又はク ラスの集合体である。 ・「サンドボックス」は、Ｊａｖａアプレットか制限されるプレイグラウンドで ある。それは、定義された入力及び出力ポイント（ケート）をもった境界に よって輪郭形成された実行環境である。 （ｂ）サンドボックス・セキュリティ・モデル 前述のサン・マイクロシステムズ社の１９９６年発行の「Ｊａｖａセキュリテ ィ（Java Security）」においてＪ.S.Fritzinger及びM.Mueller氏により開示さ れたいわゆるサンドボックスは、Ｊａｖａアプレットに対する定義された境界及 びゲートによって輪郭形成された「プレイグラウンド」を公開する。すべてのア プレットがこのサンドボックスに制限される。サンドボックス外のものをアクセ スするためには、アプレットは対応するゲートを通過しなければならない。同様 に、アプレットとの如何なるコミュニケーションもゲートを通さなければならず 、ゲートはその交差を制御し、制限することができる。一般に、アプレットは遠 隔状態で開発される。ユーザはアプレットのダウンロードを習慣的に開始し、そ れは、通常、インターネットのような信用のできない公衆ネットワークを介して 移動する。 アプレットが信用されるかどうかは、本質的には、次のような要素に依存する 。 ・ アプレット・プログラマが敵対プログラムを書かないようにすることができ るか。即ち、そのプログラマを信用することができるか。 ・ 言語の仕様によって定義された規約に従ってバイトコードを作成するコンパ イラを信用することができるか。 ・ 侵入者がアプレットを破損し又は修正するかもしれない場合、ネットワーク を信頼することができるか。 上記事項のうちのどれかに難点があるアプレットは、信用できるものとは考えら れない。 一方、独立型のアプリケーションは、一般に、ローカル的に、即ち、安全な環 境で開発されるか、又はイントラネットのような信頼されているネットワークを 介して移動する。従って、アプリケーションは、通常、信用し得るものと考えら れる。しかし、アプレット及びアプリケーションの間のこの粗い黒及び白の識別 は十分ではない。サンドボックス方法はアプレットにのみ適用され、アプリケー ションには適用されないので、インプリメントされたセキュリティはアプレット に限定される。更に、利用可能なインプリメンテーションを不十分且つ不完全な ものにしている現在知られているサンドボックスのインプリメンテーションでは 、数多くのバグが見つかっている。 通常、サンドボックスはブラウザにおいてインプリメントされる。それは、エ ンドユーザ対話の可能性なしにハードコーディングされ、プログラム可能ではな い。従って、それは固定境界及び固定ゲートを持った静的モデルである。ゲート の判断だけが変わり、ゲート自体、即ち、それのロケーション、それのポリシ、 又はそれの存在は変わらない。このモデ ルはダウンロードされたコードのオリジンを考慮するものではない。それは、ロ ーカル・プログラムとリモート・プログラムの間、即ち、アプリケーションとア プレットとの間を粗く識別するだけである。 要するに、Ｊａｖａセキュリティ・モデルの既知のインプリメンテーションは 、適切なセキュリティ・ポリシ及びそのポリシをインプリメントする機構の強化 を切り離すことができない。既知のセキュリティ・モデルは静的であり、最もユ ーザ制御された判断がＪａｖａ仮想マシンにおいてハードコーディングされるの で、サンドボックス・パラダイムに関するそれのインプリメンテーションは不十 分である。明らかに、構成可能なセキュリティの特徴の欠如は、この既知のセキ ュリティ・モデルの受容及び適用性を制限している。 本発明によるオブジェクト指向システムに対する新しいセキュリティ機構はＪ ａｖａ環境に直接に適用可能である。このセクションにとって必須である幾つか の用語は十分に認められた定義を持っているのに対して、その他のものはこの説 明では特定の方法で使用される。整合性を得るために、それらの用語の簡単な定 義を以下に示す。 （ｃ）用語 ・「オブジェクト」は、データをカプセル化し、メソッドを提供する。データは これらのメソッドを通してのみアクセス可能である。オブジェクトは動的に 作成される。即ち、それらはインスタンス化される。 ・「クラス」は、オブジェクトに対する定義であり、静的である。 ・「エンティティ」は、それらが能動的であるか又は受動的であるかに関係なく オブジェクト又は参照されたクラスとして見なされる。エンティティは資源 を所有するか又は供給する。 ・「インターフェース」は、エンティティ・データ及びサービスがアクセスされ そして変換されるエンティティのメソッドのセットより成る。 ・「名前」は、エンティティのメソッドに対するシンボリック・リファレンスで ある。名前はランタイム・システムの実行コンポーネントによって理解され るものではなく、即ち、変換可能ではない。 ・「オブジェクト・リファレンス」は、エンティティのメソッドのロケーション に対するポインタである。オブジェクト・リファレンスはランタイム・シス テムの実行環境によって理解され、即ち、変換可能である。 ・「サービス」は、オブジェクト・リファレンスを通して又はシンボリック・リ ファレンスを通して参照されるエンティティのメソッドであると考えられる 。 （ｄ）発明 この新規なセキュリティ機構は、オブジェクト指向システムにおいて未承認の アクセスから資源を保護することを目的としている。それは、資源利用及びアク セス制御を検査及び 監視するためにそれを使用することが可能である。それの設計は、資源アクセス が厳密に制御される場合にはプログラムは如何なるものも害さないという基本的 な仮定に基づいている。次のようなコンポーネントは、単独でも又は結合しても 本発明によるセキュリティ機構にとって本質的なものであるように見える。 ・「オブジェクト指向パラダイム」：データがエンティティによってカプセル化 され、提供されるインターフェースのみによって変換可能である。エンティ ティ・データを保護するための方法はそれらのインターフェースへのアクセ スを制御することである。 ・「レイジイ・オブジェクト・バインディング」：各シンボリック・リファレン ス（名前）は対応するオブジェクト・リファレンスによって実行時に代用さ れ、それを通してサービスを呼び出すことができる。この代用プロセスは、 本発明によるセキュリティ機構によってインターセプトされる。 ・「名前解決」：所与の名前（シンボリック・リファレンス）に対するオブジェ クト・リファレンスを得るために、名前解決が必要である。この名前解決は オブジェクト・リファレンスに名前をマップする。新規な機構では、このマ ッピングは、名前解決を制御するインターセプト・マネージャによってイン ターセプトされ得る。 ・「ガード・オブジェクト」：それらはオブジェクト・リフ ァレンスに任意に付加可能である。これらのガードは、オブジェクト・リフ ァレンスが使用される前及び（又は）後に呼び出される。更に、それらはコ ンテキスト情報をアクセスすることが可能である。 （ｅ）オブジェクト指向パラダイム 資源はエンティティによってカプセル化され、与えられたインターフェースを 介してのみアクセス可能である。従って、未承認のアクセスに対してオブジェク ト指向システムにおける資源を保護するためには、そのような資源へのアクセス が制御されるという懸念を、関連のエンティティのインターフェースへのアクセ スを制御するという問題に軽減することが可能である。エンティテイは、第１図 に示されるように、種々の資源を提供することが可能であり、従って、種々のイ ンターフェースを提供することが可能である。特定の資源を使用するためには、 この資源の名前（及びロケーション）が知られていなければならない。そこで、 この名前は、対応するメソッドが存在するロケーションを指すオブジェクト・リ ファレンスに変換される。 （ｆ）レイジイ・オブジェクト・バインディング バインディングは、実行可能なコードの必要なコンポーネントを連結するプロ セスである。コンポーネントはコンパイラによって作られ、オブジェクト・ファ イルと呼ばれる。オブジェクト・ファイルは、他のオブジェクト・ファイルに対 するシンボリック・リファレンスを含む。これらのオブジェ クト・ファイルを連結することによつて、リンカーがシンボリック・リファレン スを対応するオブジェクト・リファレンスでもって代用する。その時点で、その 実行可能なコードは、実行環境によって理解可能な、即ち、解釈可能な必要なオ ブジェクト・リファレンスを保持し、従って、その実行可能なコードは参照され たメソッドを呼び出すことができる。 代用が実行時に行われる場合、それは動的バインディングと呼ばれる。そうで ない場合、即ち、コードが実行される前に代用が行われる場合、それは静的バイ ンディングと呼ばれる。すべてのシンボリック・リファレンスの代用が時間的な 或るポイントで生じた場合、連結プロセスはイーガ（ｅａｇｅｒ）バインディン グと呼ばれる。シンボリック・ネームに対するオブジェクト・リファレンスが実 行時に必要とされるということが１回だけ行われる場合、それはレイジイ（ｌａ ｚｙ）バインディングと呼ばれる。一旦代用が実行可能なコードにおいて行われ ると、それは固定され、それ以上の変更を受けることはない。 例えば、Ｃ++コンパイラは、他のエンティティ（即ち、名前）に関する、人間 が読み取り可能な記号的に参照されたメソッドをそれらのタイプ情報とマージし て、更なるシンボリック・リファレンスにする。これらのリファレンスはいずれ も依然としてシンボリック（即ち、名前）であるが、最早、人間が読み取り可能 なフォーマットではない。そこで、バインダはシンボリック・リファレンスに従 って適正なコードを 含み、それらのシンボリック・リファレンスを適正なオブジェクト・リファレン スでもって代用する。そこで、このオブジェクト・リファレンスは、そのメソッ ドが存在するロケーションの始めを指す。Ｊａｖａ環境はレイジイ・バインディ ング方式を使用する。各シンボリック・リファレンスは、一旦実行環境がそれを 使用すると代用される。 その分散型の方式はアドレス空間及び（又は）システムにまたがったメソッド の呼出を可能にする。ほとんどの場合、リモート・オブジェクトは、それらのロ ーカル代表として作用するプロキシ・オブジェクトによって表される。通常、プ ロキシ・オブジェクトはリモート・オブジェクトを位置指定し、作成し、破壊し 、及び呼び出す。従って、オブジェクト・リファレンスは対応するプロキシ・オ ブジェクトのロケーションを指す。 （ｇ）インターセプト及び名前解決 その特定の特徴の新規な機構は、それがイーガ・バインディング方式であって も或いはレイジイ・バインディング方式であっても、バインディング・プロセス をインターセプトし、インターセプト・マネージャを介入させる。シンボリック ・リファレンスの解決、即ち、名前の解決は、その後者及び対応するオブジェク ト・リファレンスの間のマッピングを必要とする。所与のシンボリック・リファ レンス（名前）に対する対応するオブジェクト・リファレンスを見つけるプロセ スが名前解決である。これは、第２ａ図及び第２ｂ図に示され るような名前解決プロセスによって実行される。特定のメソッドを使用するため に、呼出元エンティティは、オブジェクト・リファレンスに対して適正に解決さ れなければならないシンボリック・リファレンス又は名前を知らなければならな い。シンボリック・リファレンスによってどちらが表されるかをエンティティが 知っているリファレンスとオブジェクト・リファレンスによってどちらが表され るかをエンティティが確実に知っているリファレンスとの分離は次のような２つ の異なるネーム・スペースに通じる。 ・ エンティティの「仮定のネーム・スペース」は一組のシンボリック・リファ レンスより成る。これらのシンボリック・ネームは未だ解決されないが、解 決プロセスに対する候補である。エンティティは、これらのリファレンスが 存在するものと仮定するが、これらの仮定は解決プロセスを通して未だ確認 されていない。まだ、これらのメソッドを呼び出すことはできない。それら はランタイム実行コンポーネントによって理解可能なものではない。 ・ エンティティの「具体的なネーム・スペース」は、一組のオブジェクト・リ ファレンスより成る。これらのオブジェクト・リファレンスは解決された名 前であり、それらは解決プロセスによって確認されているので、エンティテ ィによって明確に知られている。オブジェクト・リファレンスはランタイム 実行環境によって理解可能である。 具体的なネーム・スペースにおいて参照されたメソッドのセットは、通常、仮 定されたネーム・スペースにおいて参照されたメソッドのサブセットである。そ れらのリファレンスは異なっている（オブジェクト・リファレンス対シンボリッ ク・リファレンス）が、参照されたメソッドは同じである。 （ｈ）インターセプト・マネージャ 第２ｂ図に示されたいわゆるインターセプト・マネージャは本発明の任意選択 的な特徴である。インターセプト・マネージャの主たる責任は、それが設けられ た場合、特定のセキュリティ・ポリシに従って名前解決プロセスを制御すること 及びそれを修正することである。例えば、それは、或るシンボリック・ネームの 解決を妨げることによって具体的なネーム・スペースを強化することが可能であ る。名前解決プロセスをインターセプトし、インターセプト・マネージャを介入 させることは、アクセス制御機構に通じる。セキュリティを目的とした具体的な ネーム・スペースに関するこの規定は、それが表すエンティティのオブジェクト ・リファレンスを持つことなく使用することができる資源はないという仮定に基 づいている。インターセプト・マネージャがこの解決を可能にする場合に、しか もその場合にのみ、記号的に参照されたメソッドが解決される。 第２ｂ図に示されるように、インターセプト・マネージャは名前解決プロセス の一部である。オブジェクト・リファレンスである名前解決プロセスの結果はイ ンターセプトされる。 インターセプト・マネージャは、未修正のオブジェクト・リファレンス、又はガ ード・オブジェクトを付加されたオブジェクト・リファレンス、或いは参照され たエンティティが存在しないという例外を戻す。インターセプト・マネージャに よって遂行されるアクセス制御の粗さは解決プロセスの粗さに依存する。もっと 正確に云えば、インターセプト・マネージャはより粗いレベルで作用し得るが、 より精細なレベルでは作用し得ない。それにも関わらず、きめの細かさが可変的 なアクセス制御が依然として存在する。インターセプト・マネージャは、ソース ・エンティティ・ネーム、宛先エンティティ・ネーム、及びそれらのデータのよ うなコンテキスト・センシティブな情報へのアクセスを有する。単にアクセスを 制御することは、場合によっては十分ではないことがあり、資源利用を監視及び 検査することが必要であることがある。これは、保護された資源が使用される前 及び（又は）後に、セキュリティ機構の更なるコンポーネントが呼び出されるこ とを必要とする。そのようなオブジェクトはガードと呼ばれ、それはインターセ プト・マネージャによって挿入可能なものである。 （ｉ）ガード・オブジェクト 本発明のもう１つの任意選択的な特徴であるガード・オブジェクトが特定のオ ブジェクト・リファレンスと関連付けられる。それは、インターセプト・マネー ジャがどのようにガード・オブジェクトをインストールしたかに従って、そのオ ブジェクト・リファレンスが使用される前及び（又は）後に呼び出されるであろ う。 ガード・オブジェクトは、関連のオブジェクト・リファレンスが使用される前 にそのガード・オブジェクトが呼び出され、従って、宛先エンティティに対する 供給されたアーギュメントへのアクセスを有する場合、宛先エンティティの前に インストールされると云える。ガード・オブジェクトは、その関連のオブジェク ト・リファレンスが使用された後、即ち、コールされたメソッドが戻った後にそ のガード・オブジェクトが呼び出される場合、従って、それの戻り値へのアクセ スを有する場合、宛先エンティティの前にインストールされると云える。第２ｂ 図は、インターセプトされた名前解決プロセスの戻り結果の１つとしてガード・ オブジェクトを付加した場合の修正されたオブジェクト・リファレンスを示す。 ガード・オブジェクトがエラーのないことを表す場合、通常通りに実行が継続 する。インターセプト・マネージャによって使用されるコンテキスト情報と同様 に、ガード・オブジェクトもコンテキスト・センシティブな情報へのアクセスを 有する。これは、ソース・エンティティ・ネーム、宛先エンティティ・ネーム、 及び呼出パラメータを含む。ガード・オブジェクトが宛先エンティティの前にイ ンストールされる場合、それらは次のようなアクションを遂行することができる 。 − 呼出を拒否する − 未変更の呼出を送る − 呼出が供給したデータを変換する − 呼出の宛先を変更する − 呼出元エンティティに権利を割り当て、及び（又は）チェックする − アクセスを監視する − 通知サービス及び（又は）検査サービスを遂行する。 ガード・オブジェクトが宛先エンティティの後にインストールされる場合、そ れらは次のようなアクションを遂行することができる。 − 戻りパラメータ又は状態を変更する − 以前に割り当てた権利を排除する − 応答を監視する − 通知サービス及び（又は）検査サービスを遂行する。 ガード・オブジェクトは、それらがインターセプト・マネージャによって外部 から付加されているので、ソース又は宛先、即ち、呼出元エンティティ又は呼出 先エンティティによって影響されることはない。 ガード・オブジェクトは、呼出すエンティティ及び呼出されるエンティティ、 即ち、呼出元エンティティ及び呼出先エンティティに関する限り、非可視的であ って透過である。インターセプト・マネージャとは反対に、ガード・オブジェク トは具体的なネーム・スペースを直接に強化することができないが、それらは間 接的にそれに影響を与えることはあり得る。それらが、オリジナル・シンボリッ ク・リファレンスに 付加されたオブジェクト・リファレンスを未解決にすることができる。この未解 決の結果、このメソッドに関する次の使用は再びシンボリック・リファレンスに 遭遇し、そして名前を解決し、従って、.インターセプト・マネージャに対する 呼出になるであろう。そこで、インターセプト・マネージャは、再び、それのセ キュリティ・ポリシに従って、呼出元エンティティの具体的なネーム・スペース を修正する可能性を持つ。未解決のオブジェクト・リファレンスは、シンボリッ ク・リファレンスが解決された後、セキュリティ・ポリシが変化する場合に有用 であるかもしれない。 更に、各ガード・オブジェクトは、それが如何に長くそれのオブジェクト・リ ファレンスに付加されることを望んでいたかを決定する可能性を有する。ガード ・オブジェクトは、それ自身を分離することを決定してもよく、従って、オブジ ェクト・リファレンスの呼出のために最早呼び出されないであろう。 （ｊ）将来性 いわゆる将来性（ｃａｐａｂｉｌｉｔｙ）は、特定のモードにおいて特定のオ ブジェクト（以下の記述において更に説明される）を呼び出す権利である。１９ ９５年Prentice Hall International社発行のA.S.Tanenbaum氏著の「現代のオペ レーティング・システム（Modern Operating System）」に開示されているよう に、その権利は次の３つの要素を含んでいる。 （１）オブジェクトに対するポインタ： 必要なポインタは解決されたリファ レンス、即ち、オブジェクト・リファレンスによって完成される。実行可能 なコードがポインタを有する場合、適切なランタイム・システムが呼出を可 能にするものと仮定される。それは、将来性を有するすべてのエンティティ が対応するメソッドを呼び出すことができるということを意味する。 （２）オブジェクトのタイプ情報： 必要なタイプ情報は付加されたガード・ オブジェクトを通して得られる。将来性のタイプは関連するガード・オブジ ェクトに依存する。 （３）オブジェクトに対するアクセスの権利： 必要なアクセスの権利は付加 されたガード・オブジェクトによって達成される。それらは、呼出元エンテ ィティが特定のメソッドを使用するために供給しなければならない権利をチ ェックすることができる。更に、呼出元エンティティが適正な権利を有する 場合、ガード・オブジェクトは既存の権利を強化するか、或いは、このサー ビスを使用する新たな権利を割り当ててもよい。 オブジェクト・リファレンスを伴うガード・オブジェクトは将来性に類似して いるが、同じではない。インストールされたガード・オブジェクトを有する解決 された名前は、強化された動的将来性と見なされてもよい。将来性の動的要素は 関連のガード・オブジェクトである。 （ｋ）概要 従って、オブジェクト指向システムにおいて資源を保護するための紹介された 方法は次のような特徴のうちの１つ又は複数個のものを含む。オブジェクト指向 パラダイムは、オブジェクト及びそれらのインターフェースを通して資源へのア クセスを制御するために十分に役立つ。アクセス制御は呼出元エンティティに対 するネーム・スペースの制御、従って、解決された名前の可視性の制御を通して 達成される。呼出元エンティティがサービスを見ることができない場合、それは サービスを呼び出すことができない。メソッドの呼出可能性がないと、関連する 資源を使用することができない。解決マネージャ（及び任意選択的ガード・オブ ジェクト）はコンテキスト情報を使用し得るので、それらは、非常に融通性のあ る旦つコンテキストに依存するものとして作用することができる。ガード・オブ ジェクトは、いずれのエンティティを知らなくても外部から付加可能である。そ れらは、呼出元エンティティ及び呼出先エンティティに関する限り、非可視的で あり、透過である。従って、その機構は、パフォーマンス・オーバヘッドによっ て及び動的態様でほとんど費用をかけずに保護する。 Ｂ．インプリメンテーション 以下では、本発明によるセキュリティ機構のインプリメンテーションがＪａｖ ａ環境において開示される。インタープリタ及びランタイム・ライブラリを含む Ｊａｖａ仮想マシン （ＪＶＭ）に対して行われるすべての変更が考察される。更に、Ｊａｖａでイン プリメントされる本発明のセキュリティ機構のコンポーネントも与えられる。 このセクションは.インプリメンテーションの詳細も扱うので、当業者は、Ｊ ＶＭの基本的機構及びＣ言語におけるそれのインプリメンテーション並びにＪａ ｖａプログラミング言語自体には精通しているものと仮定する。Ｊａｖａ言語の 包括的プレゼンテーション及びＪＶＭに関するそれのインプリメンテーションは 、１９９６年Addison-Wesley Publishing社発行のJ.Goslin、B.Joy及びG.Tele著 の「Ｊａｖａ言語仕様（The Java Language Specification）」及び同年同社発 行のT.Lindholm及びF.Yellin著の「Ｊａｖａ仮想マシン仕様（The Java Virtual Machine Specification）」によって開示されている。本発明のセキュリティ機 構のインプリメントされたコンポーネントは、「ＪＶＭのＪａｖａ開発キット（ ＪＤＫ）バージョン１.０.２及びＡＩＸバージョン（the Java Development Kit (JDK)Version 1.0.2 and the AIX Version of the Java）」に基づいている。こ のセクションは、システム・クラスによって表されたシステム資源を保護するコ ンポーネントを開示している。Ｊａｖａ仮想マシンに対する変更はできる限り少 なく保たれたが、わずかな変更が不可避であった。 Ｂ１．機能の概要 本発明のセキュリティ機構のインプリメントされた機能は インターセプト・マネージャ及び幾つかの基本的なガード・オブジェクトのイン プリメンテーションを含む。エンティティという用語は、特定のクラスに適用す るために前のセクションよりも厳密化される。クラスは、それが資源を所有し及 び表示するという意味ではエンティティである。システム資源はＪａｖａライブ ラリにおけるそれらの対応するシステム・クラスを介して表されるので、クラス は、不明瞭ではなく完全に適格化された名前によってよく知られている。従って 、このインプリメンテーションは、Ｊａｖａライブラリに存在するシステムの保 護を行う。名前解決プロセスから受けたオブジェクト・リファレンスは対応する コード・ピースに対するポインタであり、それは、実際には、メソッド記述の始 めを指す。従って、オブジェクト・リファレンスはロケーションの知識を含み、 メソッドを直ちに呼び出すことが可能である。 システム・クラスの保護は、ネーム・スペースを適当に修正することによって それらへのアクセスの制御を通して達成される。オブジェクトの具体的なネーム ・スペースがオブジェクト・リファレンスを含む場合、参照されたメソッドへの その後のアクセスは許容される。従って、上記の仮定において述べたように、プ ログラムは、オブジェクト・リファレンスが得られる資源をアクセスすることが できるだけである。オブジェクトの具体的なネーム・スペースを制御及び修正す るために、レイジイ・バインディング機構及び名前解決が、 前述のようにインターセプト・マネージャを介在させることによって利用される 。オリジナル・メソッドか実行される前にガード・オブジェクトをコールするた めに、そのメソッド呼出方式は、インストールされたガード・オブジェクトに関 するチェックによって拡張される。この機能をインプリメントするためには、次 のような懸念が極めて重要である。 − ネーム・スペースの制御を通した資源保護 − Ｊａｖａ仮想マシンにおけるメソッド呼出コンポーネントの変更 − ネイティブＣコードへのアクセスを提供するインターセプト情報ベース・ク ラス − インターセプト・マネージャのインプリメンテーション − ガード・オブジェクト・ベース・クラス Ｂ２．Ｊａｖａ仮想マシン変更−システム・レベル このセクションはＪａｖａ仮想マシン及びＪａｖａランタイム・ライブラリの 機能強化を説明する。その機能強化はネイティブＣコードにおいてインプリメン トされ、従って、マシン依存するものである。本発明によるセキュリティ機構を インプリメントするために、次のようなコンポーネントが変更された。 − 仮想マシンの名前解決コンポーネント − メソッド呼出を扱うすべてのｏｐコード − メモリにおけるバイナリ・メソッド表示 − スレッド構造 （ａ）ネーム・スペース修正 アクセス制御を、従って、資源保護を達成するために、呼出元オブジェクトの 具体的なネーム・スペースが制御される。それは強化されるか又は拡大される。 親オブジェクトのネーム・スペースを修正するために、Ｊａｖａのレイジイ・ オブジェクト・バインディング・メソッドが利用される。Ｊａｖａのバイナリ・ ファイル・レイアウトは、十分に適格化された名前を記号的に使用して、他のク ラス及びインターフェース、並びに、それらのフィールド、メソッド、及びコン ストラクタを参照する。フィールド及びメソッドに関して、これらのシンボリッ ク・リファレンスは、フィールド又はメソッドを宣言するクラス又はインターフ ェース・タイプの名前及びフィールド又はメソッド自体の名前を適切なタイプ情 報と共に含む。オブジェクトが使用される前に、それの名前がオブジェクト・リ ファレンスに対して解決されなければならない。識別子は、正しいかどうかをチ ェックされ、そして、一般には、そのリファレンスが繰り返して使用される場合 に更に効率的に処理され得るダイレクト・オブジェクト・リファレンスと置換さ れる。エラーが生じる場合、例外が発生されるであろう。これに関しては、１９ ９６年Addison-Wesley Publishing社発行のJ.Goslin、B.Joy及びG.Tele著の「Ｊ ａｖａ言語仕様（The Java Language Specification）」及び同年同社発行のT.L indholm及びF.Yellin著の「Ｊａｖａ仮想マシン仕様（The Java Virtua l Machine Specification）」を参照してほしい。 オブジェクト・リファレンスに対する名前が解決された後、インターセプト・ マネージャが呼び出され、シンボリック・リファレンスの解決が許容されるべき かどうかを決定する（第４図参照）。従って、名前解決がインターセプトされ、 従って、レイジイ・オブジェクト・バインディングがインターセプトされる。イ ンターセプト・マネージャのリターン値に従って、臭体的なネーム・スペース修 正が遂行される。 ・ インターセプト・マネージャが「偽」を返答する場合、クラス・ファイルが 存在しないことを呼び出しファイルに表示するNoClassDefFoundError例外が 発生される。従って、所望の資源の名前は解決され得ず、その結果、対応す るコード・ピースのロケーションは未知である。インターセプト・マネージ ャに要請し、その後例外を生じさせると云うこの方式は、呼出元オブジェク トの具体的なネーム・スペースを強化する。 ・ インターセプト・マネージャが「真」を返答する場合、呼出は通常どおりに 継続し、具体的なネーム・スペースは修正されない。事実、具体的なネーム ・スペースは解決された名前を、即ち、対応するコード・ピースに対するポ インタを、オブジェクト・リファレンスによって拡張される。 下記のコード・フラグメントＣ１は名前解決機能に挿入された新しいコードを 表す。このＣコード・フラグメントは次 のようなステップを遂行する。 （１）ガード・オブジェクトを管理するために必要な構造を初期設定する。 （２）リクエストされた解決が許容されるかどうかをチェックし、それが否定 される場合、メソッドを未処理としてマークし、「偽」を戻す。 （３）そうでない場合、メソッドを解決されたものとしてマークし、シンボリ ック情報をその対応するコード・ピースに対するポインタでもって置換する 。 インターセプト・マネージャは幾つものガード・オブジェクトを付加し得るの で、そのメソッド呼出方式は、名前解決プロセスに加えて修正を必要とした。 （ｂ）コードフラグメントＣ１ このコード・フラグメントは、記号的に参照された名前を解決する機能に挿入 されている。適切な例外が、ic_CheckMethodResolving()メソッドにおいて発生 される。（このコードでは、ガード・オブジェクトは「フィルタ・オブジェクト 」と呼ばれる）。 ［解決メソッド］ （ｃ）メソッド呼出 Ｊａｖａインタプリタは、既に解決しているメソッドを実行する貴任がある。 メソッド呼出関連プロシージャに関する詳細な説明は、前述した１９９６年Addi son-Wesley Publishing社発行のT.Lindholm及びF.Yellin著の「Ｊａｖａ仮想マ シン仕様（The Java Virtual Machine Specification）」に開示されている。第 ４図はメソッド呼出の制御フローの概要を示す。本発明によって加えられた１０ 個の新しいコンポーネントは参照番号１９−２５及び２７−２９であり、他のコ ンポーネントはオリジナルのＪａｖａコンポーネントである。本発明による新た なコンポーネントは、名前解決に関するチェック及びガード・オブジェクトの実 行を含む。 （ｄ）Ｏｐコード ｏｐコードは簡単な用語であり、通常は、特定のオペレーションのセットを表 す数字である。それは特定の機能を表す。例えば、ニーモニックopc_invokevirt ualと関連したｏｐコード１８２（０ｘｂ６）は、仮想メソッドを呼び出すため の基本的ステップを表す。種々のＪａｖａ ｏｐコード及びそれらが提供する機 能に関する詳細な説明は、前述のT.Lindholm氏他による文献においてみることが できる。ガード・オブジェクトをインストール及び維持するために、メソッド呼 出を扱うｏｐコードのインプリメンテーションが変更される。その機能は、ガー ド・オブジェクトに対するチェックによつて及びその後それらを実行するための コードによって拡張さ れる。最後のガード・オブジェクトが実行された後、オリジナル・メソッドが実 行される。 Ｃ２は、メソッド呼出を扱うすべてのｏｐコードに挿入されているＣコード・ フラグメントである。このコード・フラグメントは次のようなステップを遂行す る： （１）ガード・オブジェクトがインストールされているかどうかをチェックす る。ガード・オブジェクトが全くインストールされていない場合、通常どお りに継続する。 （２）メソッドが解決されたかどうかをチェックする。それが解決された場合 、そのインストールされたガード・オブジェクトをコールする。 （３）例外が処理されなければならないかどうかをチェックする。例外が発生 している場合、メソッドの実行を取り止め、それを処理する。 ガード・オブジェクトをオブジェクト・リファレンスに付加するために、オリ ジナル・メソッドのメモリ・レイアウトが拡張される。 （ｅ）コード・フラグメントＣ２ このコード・フラグメントはオリジナル・メソッドの実行前に挿入される。 ［実行メソッド］ （ｆ）メソッド表示 オブジェクトの任意のメソッドを実行するためには、メソッドはメモリにおけ る対応するバイナリ表示を必要とする。メソッドのバイナリ表示は静的コンポー ネントと動的コンポーネントに分離される。静的コンポーネントはそれのクラス 記述及び静的フィールドを含み、動的コンポーネントはそれの動的フィールドを 含む。ＵＮＩＸオペレーティング・システムにおいて実行可能なバイナリの表示 におけるテキスト・セグメント及びデータ・セグメントの間の相違点は類似した コンセプトである。両セグメントともアドレス空間の異なるエリアにマップされ る。テキスト・セグメントは読取専用モードでマップされ、データ・セグメント は読取／書込モードでマップされる。 メソッドの静的コンポーネントは、同じクラス記述からインスタンス化された すべてのオブジェクトによって共用されるが、各オブジェクトはそれ自身の動的 コンポーネントを有する。ガード・オブジェクトはメソッドの静的コンポーネン ト、即ち、fieldblock structureに付加される。従って、ガード・オブジェクト は、同じクラス記述のすべてのインスタンスによっても共用される。ガード・オ ブジェクトは静的コンポーネントに付加されるけれども、インプリメンテーショ ンはガード・オブジェクトを、クラス及びそれらのメソッドにではなく、別のオ ブジェクト及びそれらのメソッドに付加するように準備される。 （ｇ）ガード・ディスパッチ・テーブル ガード・ディスパッチ・テーブルは付加されたガード・オブジェクトを管理す る。それは、各ガード・オブジェクトのリファレンスを保持し、如何に多くのガ ード・オブジェクトがインストールされるかを表す。へッダは次のような管理的 エレメントより成る。（歴史的な理由で、ガード・オブジェクトは、そのコード では「フィルタ・オブジェクト」と呼ばれる）： ・ 如何に多くのガード・オブジェクトが使用されるかを表す変数（used_filte rによって表される） ・ スペースが割り振られるガード・オブジェクトの数を表す変数（res_filter によって表される）。但し、res_filter＞used filterがいつも真でなけれ ばならない ・ そのメソッドが解決されたと見なされるかどうかを表すフラッグ（resolved によって表される） ・ 付加されたメソッド表示を参照するポインタ（mbによって表される） ・ 呼出元オブジェクトのクラス・ファイルに対するポインタ（callerによって 表される） ・ 管理されたガード・オブジェクト構造を含む動的アレイの第１エレメントに 対するポインタ。 以下のコード・フラグメントＣ３はガード・ディスパッチ・テーブル・ヘッダ の構造を示す。 （ｈ）コード・フラグメントＣ３ これはガード・ディスパッチ・テーブルのヘッダを示す。 filtersによって示されたアレイのエレメントのタイプがコード・フラグメン トＣ４において示される。それは次のようなコンポーネントを含む： ・ ガード・オブジェクトのオブジェクト・メモリ・ロケー ションに対するポインタ（objによって表される） ・ 呼び出されるべきメソッドの名前（methodnameによって表される） ・ ２つのメソッドが同じ名前を持つが異なるシグニチャを持つと云うことをイ ンプリメントすることが可能であるので、対応するシグニチャ（signature によって表される） ・ ガード・オブジェクトがそれら自身を対応するオブジェクトから分離する時 にコールされるインターセプト・マネージャ・クラスにおけるメソッドを指 定するコールバック・メソッド・ネーム（notifyによって表される）。 （ｉ）コード・フラグメントＣ４ フィルタ・ディスパッチ・フィールドにおける各エントリはタイプfilterdesc のエントリである。 ガード・オブジェクトはＪａｖａにおいてインプリメントされるので、それら は順次にネーム・スペースの修正のための及びガード・オブジェクトを付加する ための潜在的な候補である。従って、再帰問題を回避するために、実行スレッド がマークされる。 （ｊ）スレッド スレッドはアドレス空間における実行パスである。このアドレス空間は、数多 くの同時に実行するスレッドによって共用可能である。スレッドの概念に関する 詳細な説明は、１９８９年１月６日発行のディジタル・イクイップメント社のSy stem Research Center(SRC)Report誌におけるA.D.Birell氏による「スレッドに よるプログラミング概説（An Introduction to Programming with Threads）」 において示されている。 本発明によるガード・オブジェクト及びインターセプト・マネージャはＪａｖ ａにおいてインプリメントされる。それらは資源もアクセスするので、本発明に よる機構に属するコンポーネント及びそれに属さないコンポーネントの間を区別 するための基準が必要とされる。それがない場合、インターセプト・マネージャ が資源をアクセスする度に、従って、メソッドを呼び出す度に、それは、インタ ーセプト・マネージャ自身によってチェックされる。この再帰は、スレッドを適 正にマークすることによって破られる。スレッドがガード・オブジェクト又はイ ンターセプト・マネージャに入る場合、それは、スレッドがスーパバイザ状態に あるものとしてマークされる。次にそれがガード・オブジェクト又はインターセ プト・マネージャに入ろうとする時には、スレッドがスーパバイザ状態にあるも のとしてマークされているかどうかがチ ェックされる。このマークの存在に従って、ランタイム・システムは、スレッド をその新規な機構に委ねるべきかどうかを決定する。スレッドがガード・オブジ ェクト又はインターセプト・マネージャから離れる場合、そのマークは消去され る。 この一時的に割り当てられたステータスは、システム・コールを実行するプロ セスがシステム・コールを実行しないプロセスよりも、資源をアクセスするため の多くの権利を有するという伝統的なＵＮＩＸシステム・コールの概念に多少類 似している。カーネル・モードにある間、スーパバイザ状態が実行プロセスに一 時的に割り当てられる。これらの特権によって、プロセスは、オペレーティング ・システムによって維持された保護済みの資源へのアクセスを有する。システム ・コールを離れる時、特権状態は消去される。システム・コールの概念の詳細な 説明は、１９９６年Addison Wesley Publishing社発行のS.J.Leffler氏他による 「４.４ＢＳＤＵＮＩＸオペレーティング・システム（4.4 BSD UNIX Operating System）」において示されている。 ガード・オブジェクト及びインターセプト・マネージャは、オリジナル・メソ ッドに供給されたアーギュメントを含むコンテキスト・データをアクセスするこ とができ、それらを修正することも可能である。オリジナル・メソッド呼出がイ ンターセプトされ、しかもインターセプト・マネージャが要請されるか又はガー ド・オブジェクトがコールされる場合、実 行スレッドはオリジナル・メソッドのスタック．フレームに対するポインタを一 時的に割り当てられる。従って、それらはスタック上に存在するメソッド・アー ギュメントへのアクセスを有する。 本発明によるセキュリティ・コンポーネントに入る時、適正なガード・ディス パッチ・テーブルに対するポインタが実行スレッドに割り当てられる。従って、 そのスレッドは、すべてのガード・オブジェクトに対する完全なアクセスを有す る。 上述の機能を達成するために、スレッド構造は次のようなコンポーネントによ って拡大される。これらのコンポーネントはすべて、スレッドが正規のコード及 びセキュリティ・コードの間の境界を横切る時に割り当てられる。 − スレッドがスーパバイザ状態にあるかどうかを表す単一ビット（sv_thread によって表される） − 適正なガード・ディスパッチ・テーブルに対するポインタ（iv_filtertable によって表される） − オリジナル・メソッドの適正なスタック・フレームに対するポインタ（ic_o ptopによって表される） Ｂ３．Ｊａｖａクラス・ハイアラーキ（ユーザ・レベル） このセクションでは、Ｊａｖａでインプリメントされるコンポーネントが説明 される。Ｊａｖａにおける新規なセキュリティのインプリメンテーションは、で きるだけ移植可能であるというＪａｖａの考え方の主要原理の１つに従う。 従って、そのインプリメンテーションのほとんどは、ネイティブＣコードにお いてインプリメントされたコンポーネントに対する明確なインターフェースを使 用して、Ｊａｖａにおいて行われる。ネイティブＣコードにおいてインプリメン トされるルーティンは、InterceptionInfoと呼ばれる抽象的なベース・クラスを 通してアクセス可能である。 （ａ）インターセプト情報 InterceptionInfoはＪａｖａにおいては抽象的なクラスである。それは、本発 明による基本的なセキュリティ機能を提供するために使用される。Ｊａｖａにお けるクラス修飾子の説明は前述のJ.Goslin氏他によって与えられている。このベ ース・クラスのコンポーネントは大雑把に次のようなカテゴリに分割可能である ： − 任意のガード・オブジェクトのインストールを管理する − 任意のガード・オブジェクトの除去を管理する − インストールされたガード・オブジェクトの順序を管理する − 任意のアーギュメントの検索及び修正 − 呼出元オブジェクト／エンティティ及び呼出先オブジェクト／エンティティ の完全に適格化された名前、メソッド名並びにシグニチャ名の検索 InterceptionInfo基本クラスによって提供されたアプリケーション・プログラ ミング・インターフェース（ＡＰＩ）の概要がコード・フラグメントＣ５におい て与えられる。本発 明による完全なセキュリティ機能を得るためには、インターセプト・マネージャ ・クラス及びすべてのガード・オブジェクトが、図示のようにこのInterception Info基本クラスをサブクラス化しなければならない。 （ｂ）コード・フラグメントＣ５ このクラスはインプリメントされたネイティブＣコードに対するインターフェ ースを提供する。 （ｃ）インターセプト・マネージャ・クラス インターセプト・マネージャはＪａｖａにおいてインプリメントされ、最終的 な且つ静的なものとして宣言される。イ ンターセプト・マネージャはInterceptionInfo基本クラスをサブクラス化する。 それは、呼出元エンティティのネーム・スペースを制御及び修正する責任がある 。インターセプト・マネージャは、呼出元エンティティがアプリケーションの一 部であるか又はアプレットの一部であるかに関係なく、即ち、アプリケーション アプレットの間の区別なく、Ｊａｖａ環境に対してセキュリティ・ポリシをイン プリメントする。インターセプト・マネージャは、セキュリティ・サンドボック スの境界を定義し、サンドボックスの外部とのコミュニケーションのためのゲー トを確立する。 Ｊａｖａはそれ自身のメモリ管理を有するので、ガーベッジ・コレクションは 、古くなったオブジェクトを排除してメモリを自由にする責任がある。最早Ｊａ ｖａレベルにおけるリファレンスが存在しない場合、オブジェクトは古くなった ものと見なされる。従って、インターセプト・マネージャは、それが作成しそし てその後インストールしたすべてのガード・オブジェクトを追跡しなければなら ず、そうでない場合、ガーベッジ・コレクションは、メモリをコンパクトにする 時、このオブジェクトを排除するであろう。ガーベッジ・コレクションに関する 詳細な説明は、前述のT.Lindholm氏他によって与えられている。 インターセプト・マネージャはガード・オブジェクトを作成し、どのオブジェ クトをどのメソッドに付加すべきかを決定する。それは、オリジナル・メソッド の前及び（又は）後 にそれらがコールされる順序も指定する。 （ｄ）インターセプトフィルタ Interception Filterクラスはガード・オブジェクトによって必要とされる基 本機能を提供する。インターセプト・マネージャと同じネイティブＣコード・メ ソッドをアクセスするために、それはInterceptionIfoクラスをサブクラス化す る。このクラスはそのサブクラス化されたクラスをメソッドでもって拡張し、そ れ自身をオリジナル・メソッド（それが付加されるオブジェクト・リファレンス ）から切り離させる。実際のインプリメンテーションでは、ガード・オブジェク トは、オリジナル・メソッドがコールされる前に実行される。コード・フラグメ ントＣ６は基本のガード・オブジェクト・ベース・クラスを示す。defaultCallF i1ter()メソッドは、オブジェクト・リファレンスが呼び出される前にデフォル トによってコールされるメソッドである。 （ｅ）コードフラグメントＣ６ これはInterceptionInfoアブストラクト・ベース・クラスを拡張する。 （ｆ）結論 このセクションＢは、セクションＡにおいて示されたアイデアのインプリメン テーションの主たる懸念事項を示した。本発明のセキュリティ機構のインプリメ ンテーションの本質的な機能は、システム資源を表すシステム・クラスに対する アクセスを制御するための及び任意のガード・オブジェクトにおいてコールする ための原理を扱うその提案されたアーキテクチャのサブセットとして説明された 。 Ｊａｖａ仮想マシンにおいて行われる修正は最少に維持された。呼出元オブジ ェクトの具体的なネーム・スペースを修正するために、及びメソッド呼出プロセ スにおいてガード・オブジェクトをコールするために、名前解決プロセスにおい て極めて重要な変更が行われた。今や、ガード・オブジェクトを通したすべての 単一メソッド呼出に対して、或いは、別の方法で且つ選択的に、名前解決プロセ ス中に１回だけセキュリティを保証することか可能である。インターセプト・マ ネージャ及びガード・オブジェクトの両方とも、所望の程度の保護に関して及び 経済的な観点から最適化可能である可変 的なきめの細かさの保護機構をプログラマが形成することを可能にする。

Claims (1)

1. 【特許請求の範囲】 １．名前解決機構を有するデータ処理システム、特に、分散型ネットワーク・シ ステムにおいて、資源（２ａ....２ｎ）、例えば、ファイル又は他のオブジェク トを未承認のアクセスから保護するための方法にして、前記資源は第１エンティ ティ、即ち、呼出元エンティティ（７）によってコールされ、第２エンティティ 、即ち、呼出先エンティティ（９）によって供給されるものであり、 前記資源へのアクセスはシンボリック・ネームを使用して前記呼出元エンティ ティ（７）によって呼び出され、シンボリック・ネーム全体はエンティティに対 する仮のネーム・スペースを形成し、 前記名前解決プロセスはオブジェクト・リファレンスを前記シンボリック・ネ ームに割り当て、前記オブジェクト・リファレンス全体は許容された資源を反映 するエンティティに対する具体的なネーム・スペースを形成し、後者は前記シス テムのすべての資源のサブセットであり、 前記呼出元エンティティ（７）は、前記呼出先エンティティ（９）における前 記具体的なネーム・スペースに対するアクセスだけを許容される 方法。 ２．前記シンボリック・ネームは少なくともエンティティ・ネーム及びメソッド ・ネームを含み、それによって、前記名 前の全体は前記仮のネーム・スペースを形成する、請求の範囲第１項に記載の方 法。 ３．前記アクセスが許容し得るものである場合、名前解決プロセスはシンボリッ ク・ネームを解決して、所望の資源（２ａ....２ｎ）をアクセスすることにより 前記呼出元エンティティ（７）のアクセス、特に、即時アクセスを可能にするオ ブジェクト・リファレンス（６）にし、従って、前記呼出先エンティティ（９） における所望のメソッドを呼び出す、請求の範囲第１項又は第２項に記載の方法 。 ４．ガード・オブジェクト（１３）が供給され、前記ガード・オブジェクトに対 するリファレンスを前記オブジェクト・リファレンス（６）に代用することによ って名前解決プロセスが修正される、請求の範囲第１項乃至第３項のいずれかに 記載の方法。 ５．前記ガード・オブジェクトは、オブジェクト・リファレンス（６ｂ）を前記 呼出元エンティティ（７）から隠蔽すること及び呼出プロセスを制御することに よって所望のメソッドへの条件付きアクセスを提供する、請求の範囲第４項に記 載の方法。 ６．前記ガード・オブジェクトは、前記オブジェクト・リファレンスが使用され る前及び（又は）後にコールされる、請求の範囲第４項及び第５項のいずれかに 記載の方法。 ７．前記ガード・オブジェクトによって提供される条件付きアクセスは、前記名 前解決プロセスにおいて使用される分類 よりも細かい分類を生じる、即ち、より詳細な区分に依存する、請求の範囲第４ 項及び第５項のいずれかに記載の方法。 ８．前記方法のステップの少なくとも１つはオブジェクト指向態様でインプリメ ントされる、請求の範囲第１項乃至第７項のいずれかに記載の方法。 ９．資源（２ａ....２ｎ）、例えば、ファイル又は他のオブジェクトを未承認の アクセスから保護するための手段を含むデータ処理システムにおいて前記資源の ためのアクセス制御システムにして、前記資源は第１エンティティ、即ち、呼出 元エンティティ（７）によってコールされ、第２エンティティ、即ち、呼出先エ ンティティ（９）によって供給されるものであり、 前記呼出元エンティティ（７）が前記資源の任意のものへのアクセスを呼び出 すシンボリック・ネームを解決するための手段であって、前記シンボリック・ネ ーム全体は仮のネーム・スペースを形成することと、 前記シンボリック・ネームの各々にオブジェクト・リファレンスを割り当てる ための手段であって、前記オブジェクト・リファレンス全体は許容された資源を 反映する具体的なネーム・スペースを形成し、後者はすべての資源のサブセット であることと、 前記呼出元エンティティ（７）のアクセスを、前記呼出先エンティティ（９） における前記具体的なネーム・スペースに制限するための手段と、 を含むアクセス制御システム。 １０．ガード・オブジェクト（１３）を確立し、前記ガード・オブジェクトに対 するリファレンスを前記オブジェクト・リファレンス（６）に代用するための手 段（５ｂ）を更に含む請求の範囲第９項に記載のアクセス制御システム。 １１．前記手段のうちの少なくとも１つはオブジェクト指向態様でソフトウエア においてインプリメントされる請求の範囲第９項及び第１０項のいずれかに記載 のアクセス制御システム。 １２．請求の範囲第１項乃至第８項のいずれかに記載の方法及び（又は）請求の 範囲第９項乃至第１１項のいずれかに記載のアクセス制御システムがインプリメ ントされるデータ処理ネットワーク。