JP2000035949A - セキュア分散型ネットワークにおけるデータベースアクセス制御を供給するシステム及び方法 - Google Patents

Abstract

(57)【要約】 （修正有） 【課題】セキュア分散型ネットワークにおける管理情報
へのＳＱＬアクセスを供給する方法を提供する。 【解決手段】アクセス制御データベースは、特定の組の
管理オブジェクトへのネットワークから管理情報を取得
することを含む。アクセス権利を特定する情報を集合的
に記憶するアクセス制御オブジェクトを有する。アクセ
ス制御データベースによるアクセスに従ってアクセス制
御サーバは、管理オブジェクトへのアクセスを行う。情
報転送機構は、管理情報をネットワークからデータベー
ス管理システム（ＤＢＭＳ）に送り、データベーステー
ブルは、管理オブジェクトに対応して管理情報を記憶す
る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、主にコンピュータ
ネットワークの管理に関し、特にマッチングアクセス制
限をネットワークにおける管理情報の少なくとも一部へ
のＳＱＬアクセスに供給すると共に管理オブジェクトへ
のアクセス及び管理オブジェクトの許可されたユーザへ
の通知を制限するシステム及び方法に関する。

【０００２】

【従来の技術】ＳＮＭＰ（Simple Network Management
Protocol: シンプルネットワーク管理プロトコル）は、
マルチベンダな、相互運用ネットワーク管理のためのツ
ールを供給すべく開発された。ＳＮＭＰは、プロトコ
ル、データベース構造仕様を含んでいる、ネットワーク
管理に対する一組の標準、及び一組のデータオブジェク
トを供給する。ＳＮＭＰは、１９８９年にＴＣＰ／ＩＰ
を利用したインターネットに対する標準として採用され
た。ＳＮＭＰ技術の説明は、この書類の範囲を越えるも
のでありかつ読者は、ＳＮＭＰに精通しているか、又は
従来技術情報としてそれ全体が参考文献としてここに採
り入れられる、William Stallings, "SNMP, SNMPv2 and
RMON," Addison Wesley (1996) のような、主題の通常
の参考書へのアクセスを有するものであると想定する。

【０００３】ＣＭＩＰは、それがＯＳＩ標準に基づくこ
とを除き、ＳＮＭＰのようなネットワーク管理プロトコ
ルである。文献：William Stallings による"SNMP, SNM
Pv２and CMIP: The Practical Guide to Network Manag
ement Standards" は、ＣＭＩＰ、及びＣＭＩＰ関連標
準に関する基礎情報の優れたソースであり、従来技術情
報としてそれ全体が参考文献としてここに採り入れられ
る。多くのネットワークは、ネットワークを管理するた
めにネットワークマネージャ及びシンプルネットワーク
管理プロトコル（ＳＮＭＰ）又はＣＭＩＰのある形式を
用いる。その管理タスクの中では、ネットワークマネー
ジャは、ネットワーク上のデバイスの状態を自動的に監
視する。ネットワークマネージャは、事象要求をデバイ
スに送り、デバイスは、ある一定の事象が発生した場合
に応答を戻すことが要求されている。例えば、ディスク
エージェントは、利用可能ディスク空間が５０％以下に
なったならば応答を送ることが要求されるであろう。

【０００４】ＳＮＭＰ−管理可能（又はＣＭＩＰ−管理
可能）デバイスは、管理情報ベース（Management Infor
mation Base:ＭＩＢ）、デバイスの異なる態様（例え
ば、構成、統計、状態、制御）をテーブルわしているオ
ブジェクト又は変数の収集をそのメモリに記憶する。デ
バイスの各クラスに対して、ＭＩＢは、標準変数のコア
を有する。デバイスの各ベンダーは、それがそのデバイ
スの管理に対して重要であると思われる変数を、コアに
追加する。ネットワークにおける管理可能デバイスに対
するＭＩＢｓは、検索することができる管理情報を記憶
するだけでなく、ｓの値が、ネットワークマネージャに
よって変更されるときに、デバイスのオペレーションを
変更する、変数も含む。簡単な例は、デバイスのオペレ
ーションを不能にすること、デバイスによって実行され
る異なるタスクに割当てられる優先順位を変えること、
及びデバイスによって生成された一組のメッセージとそ
れらのメッセージが送られる一組の宛先を変えることで
ある。

【０００５】明らかに、不許可の者がネットワークの管
理情報オブジェクトをアクセスすることを防ぐことは、
重要である。さもなければ、不許可の者によって機密情
報が取得されるばかれでなく、ネットワークが妨害行為
に対してオープンになってしまう。本発明は、ネットワ
ーク管理情報オブジェクトに対するアクセス制御の問題
に取り組む。ITU-T X.741(1995) は、「Data Networks
and Open System Communications,OSI Management」と
いうテーブル題の、先にCCITT として知られた、Intern
ational Telecommunication Union のTelecommunicatio
n standardization sectorによって出版された、業界標
準（規格）である。X.741 標準は、ＯＳＩ（開放型シス
テム間相互接続）システム管理に関連付けられたアクセ
ス制御を生成しかつ管理するために必要なアクセス制御
セキュリティモード及び管理情報を特定する。

【０００６】本発明に関係があるＯＳＩシステム管理に
関する関連ITU-T 標準、特にX.740(1992)(security aud
it trail function)及びX.812(1995)(data networks an
d open systems communications security) が存在す
る。これらX.741(1995), X.740(1992)及びX.812(1995)
の全て３つは、ここに従来技術情報として参考文献で採
り入れられる。X.740,X.741 及びX.812 標準は、管理オ
ブジェクト（しばしばネットワーク管理オブジェクトと
も呼ばれる）へのアクセスを制御するための相当に包括
的なアクセス制御フレームワークを定義するが、これら
の標準によって取り組まれていないかまたは解決されて
いない多数のアクセス制御及び管理問題が残されてい
る。

【０００７】特に、X.741 及び関連標準は、管理オブジ
ェクトへのアクセスを制限するためのアクセス制御を定
義するが、これらの標準は、事象報告書へのアクセスを
制限するための機構に取り組まないかまたはそれを特定
しない。オブジェクトが生成され、削除され、または管
理パラメータが特定された閾値を渡すときに生成された
報告書のような、（通常、事象通知書と呼ばれる）事象
報告書は、多くのシステムで、聴取者に放送される。ネ
ットワークが、例えば、大規模な電気通信（電信）会社
によって所有される電話切替えネットワークであり、か
つ事象報告書が特定の顧客に対して導入又は利用される
資源に係わるならば、これは、明らかに許容できない。
即ち、顧客Ａは、顧客Ｂのために用いられるネットワー
ク資源についての事象報告書を受け取ることを許容され
るべきではない。

【０００８】実際、X.741 及び関連標準における仮定
は、事象報告書セキュリティが管理オブジェクトへのア
クセスを制限するために用いられるアクセス制御機構と
は別の機構を用いて実施されるべきであるということで
ある。結局、管理オブジェクトに対するアクセス制御
は、オブジェクトへのアクセスを要求しているインバウ
ンド（市内へ向かう）メッセージをフィルタし、事象報
告書は、アウトバウンド（市外へ向かう）メッセージで
ある。しかしながら、多くの場合、ある人がアクセスす
ることを禁止されているオブジェクトは、また、その人
がそれから事象報告書を受け取るべきでないオブジェク
トである、ということが本発明の発明者によって観察さ
れている。例えば、上記の例を用いると、顧客Ａの従業
員は、顧客Ｂに割当てられているオブジェクトのいずれ
に対する事象報告書をアクセスすべきでなくまたは受け
取るべきではない。

【０００９】

【発明が解決しようとする課題】X.741 によって取り組
まれていない別の問題は、大規模ネットワークの顧客が
しばしばを“ＳＱＬ" 型報告書ジェネレータを用いてネ
ットワーク管理報告書を生成する機能（能力）を強く主
張するということである。即ち、そのようなネットワー
クのユーザは、それらのネットワーク資源の状態に関す
る報告書を生成する機能（能力）を欲するかまたは必要
とすると共に、ＳＮＭＰ（またはあらゆる他のネットワ
ーク管理プロトコル）を用いたネットワーク管理情報検
索の複雑性を回避する。X.741 及び関連標準は、管理報
告書を生成するための目的で管理オブジェクトデータベ
ースへのあらゆる型の直接ＳＱＬ−型アクセスを要求し
ないし、或いは提案もしない。事実、それがセキュリテ
ィ漏洩の潜在的な源なので、直接ＳＱＬ−型アクセス
は、X.741 の目的に反するように思われうる。

【００１０】本発明の課題は、他の型のオブジェクトア
クセスとは対照的に、報告書生成の目的に対して管理オ
ブジェクトデータベースへの直接ＳＱＬ−型アクセスを
提供することにある。直接アクセス機構の目的は、ネッ
トワークオブジェクトの状態又は過去のパフォーマンス
に関する報告書を定義しかつ生成すべくユーザに標準Ｄ
ＢＭＳ報告書ジェネレータを使用させると共に、通常の
管理情報アクセス要求に適用されるものと同じアクセス
制限を供給することである。

【００１１】

【課題を解決するための手段】纏めると、本発明は、コ
ンピュータネットワークにおける管理オブジェクトへの
アクセスを制御するためのシステム及び方法である。ア
クセス制御データベースは、管理オブジェクトの特定さ
れた組へのユーザによるアクセス権利を特定する情報を
集合的に記憶するアクセス制御オブジェクトを有する。
特定されたアクセス権利は、ネットワークから管理情報
を取得するためのアクセス権利を含む。アクセス制御サ
ーバは、アクセス制御データベースによって特定された
アクセス権利に従って管理オブジェクトへのアクセスを
ユーザに提供する。情報転送機構は、ネットワークから
データベース管理システムへ管理情報を送る。データベ
ース管理システムは、一組のデータベーステーブルに情
報転送機構によって送られた管理情報を記憶する。各デ
ータベーステーブルは、対応する管理オブジェクトに対
する管理情報を個々の行に記憶する。

【００１２】一組のビューは、データベーステーブルに
記憶された管理情報へのアクセスを制限する。各ビュー
は、このビューを用いるときにアクセス可能であるデー
タベーステーブルにおける行のサブセットを定義する。
一組の各ビューを用いるときにアクセス可能である一組
のデータベーステーブル行は、少なくとも一人のユーザ
に対してアクセス制御データベースによって特定される
管理オブジェクトアクセス権利に対応している。ビュー
アクセス制御手段は、一組のビューにおけるどのビュー
がユーザの特定したものによって使用可能であるかを特
定する。データベースアクセスエンジンは、ユーザがア
クセス制御データベースによってアクセスすることを許
される一組のデータベーステーブルにおける管理情報だ
けを各ユーザにアクセスさせるように一組のビューを用
いて一組のデータベーステーブルにおける情報をアクセ
スする。

【００１３】本発明の更なる目的及び特徴は、図面に関
連して、以下の詳細な説明及び特許請求の範囲からより
容易に理解できるであろう。

【００１４】

【発明の実施の形態】図１を参照すると、ネットワーク
１０６における管理オブジェクトへのイニシエータ１０
４（例えば、ユーザ、及びユーザのために動作している
アプリケーションプログラム）によるアクセスを制限す
るアクセス制御エンジン（ＡＣＥ）１０２を有している
ネットワーク管理システム１００が示されている。ネッ
トワーク１０６は、管理機能を実行するための管理プロ
トコルを用いる実質的にあらゆる型のコンピュータを利
用したネットワークでありうる。この書類の目的に対し
て、我々は、管理情報及び資源制御変数を含む、ネット
ワークにおける管理オブジェクトだけを考える。更に、
この書類の目的に対して、我々は、管理情報及び資源制
御変数を含む、管理オブジェクトへのアクセスおよび管
理オブジェクトによって生成された事象通知へのアクセ
スを制限する方法を主に考えるので、我々は、管理オブ
ジェクトの内容及び機能について特に考えない。

【００１５】多くの書類では、管理オブジェクトは、
“管理オブジェクトインスタンス" （ＭＯＩ' ｓ）と呼
ばれるということに注目すべきである。そのような書類
では、略語“ＯＩ" 及び“ＯＣ" は、“オブジェクトイ
ンスタンス" 、“オブジェクトクラス" を意味する。こ
の書類の用語では、全てのオブジェクトが対応オブジェ
クトクラスのインスタンスなので、オブジェクトは、実
際にはオブジェクトインスタンスである。例えば、ネッ
トワークの各“ルータオブジェクト" は、対応管理オブ
ジェクトクラスのインスタンスである。明瞭化のために
必要であると思われる場合を除き、この書類では“オブ
ジェクトインスタンス" の代わりに用語“オブジェク
ト" を用いる。また、好ましい実施例では全ての管理オ
ブジェクト及びアクセス制御オブジェクトは、ＧＤＭＯ
コンプライアントである。

【００１６】アクセス制御エンジンは、アクセス制御デ
ータベース１０８を含む。ネットワークそれ自体のよう
に、アクセス制御データベース１０８は、オブジェクト
の階層構造で構成されている。本発明で実施されるよう
な、種々の形態のアクセス制御データベースを以下に詳
述する。アクセス制御データベース１０８は、そのよう
な要求を否認すべきかまたは認可すべきかを決定するた
めにアクセス要求に適用することができる、アクセス制
御規則を含む。アクセス制御決定ファンクション（ＡＣ
ＤＦ）１１０は、管理オブジェクトへの要求されたアク
セスを認可すべきかまたは否認すべきかを決定するよう
に各アクセス要求にアクセス制御規則を適用する手順
（または一組の手順）である。以下に詳述するように、
アクセス要求が二つ以上の管理オブジェクトのターゲッ
トを有する場合、アクセス要求のある部分は、認可さ
れ、他の部分は、否認される。

【００１７】アクセス制御実施ファンクション（ＡＣＥ
Ｆ）１１２は、ＡＣＤＦ１１０によってなされた決定を
実施するための手順（または一組の手順）である。特
に、ＡＣＥＦ１１２は、ＡＣＤＦ１１０がアクセス否認
を戻す場合にアクセス否認応答を送り、アクセスが認可
される場合に適当な管理オブジェクトにアクセス要求を
送る。図２を参照すると、各アクセス要求１２０は、一
組の所定のフィールドを包含しているオブジェクトまた
はデータ構造であり、以下のものを含んでいる：・ us
er information（ユーザ情報）、要求イニシエータを識
別する；・ operation(オペレーション）, 特定された
ターゲットオブジェクト上で実行されるべきオペレーシ
ョンの型； defined operation（定義されたオペレーシ
ョン）は、get, set, create, delete, action, filte
r, multiple object selection,及び“receive notific
ations from";“receive notifications from" オペレ
ーション（この書類の或る部分では“event notificati
on（事象通知）" 動作と通常呼ばれる）は、X.741 によ
って定義されるoperationsの一つではなく、以下に説明
する理由により発明者によって追加されたnew operatio
n （新しいオペレーション）であるということに注目す
る；・ mode（モード）, 確認済(confirmed) 又は未確
認済(unconfirmed) に等しい、管理情報サーバがイニシ
エータに応答メッセージを送るべきかどうかを示す；mo
deが未確認済に等しい場合、応答メッセージ（例えば、
アクセス否認メッセージ）はイニシエータに送られな
い；modeが確認済に等しい場合、応答メッセージはイニ
シエータに送られる；・ synch （シンク）, “atomi
c" 又は“best effort"に等しい; synch がatomicに設
定されたならば、二つ以上のオブジェクトに指向された
アクセス要求は、要求のいずれか一部が否認されたなら
ば、打ち切られる；synch がbest effortに設定された
ならば、アクセスが認可されたオブジェクト上でアクセ
ス要求が実行されかつ対応する結果がイニシエータに戻
される；及び ・ target（ターゲット），イニシエータがアクセスす
ること欲しているオブジェクトを特定するを含む。

【００１８】アクセス要求１２０のtarget（ターゲッ
ト）は、３つのフィールドによって特定される： ・ base object （ベースオブジェクト）, 管理オブジ
ェクトツリーの特定のobject（オブジェクト）を示す； ・ scope （スコープ）, アクセスされるべきツリーに
おけるbase object （ベースオブジェクト）の上下のob
ject（オブジェクト）の範囲を示す；好ましい実施例で
はbase object （ベースオブジェクト）は、常にroot(
ルート) に最も近いtarget set（ターゲットセット）の
object（オブジェクト）でありかつscope（スコープ）
は、ターゲットセットの一部として含まれるべきベース
オブジェクトの下（即ち、ルートから離れた）の多数の
オブジェクトツリーレベルをテーブルわす；及び ・ filter（フィルタ）、ターゲットセットに含まれた
オブジェクトの組を制限するためのフィルタ条件（例え
ば、フィルタは、Menlo Park, Californiaのルータに対
する管理オブジェクトだけがターゲットセットに含まれ
るということをテーブルわしうる）を設定する；フィル
タフィールドは、データベース問合せ“where"clauseに
等しい。フィルタは、ユーザが受け取ることを欲する事
象通知の型（例えば、ＳＮＭＰ又はＣＭＩＰ事象通知）
を特定するために用いることもできる。たった一つのオ
ブジェクトのターゲットセットを有する要求は、要求の
スコープフィールドが未使用なので、“non-scoped" re
quest(非スコープ要求) であると考えられる。二つ以上
のオブジェクトのターゲットセットを有する要求は、要
求のスコープフィールドが二つ以上のオブジェクトがア
クセスされるべきでるということをテーブルわすので、
“scoped" request(スコープ要求) であると考えられ
る。

【００１９】複数のサーバにわたるアクセス制御の分散 図３を参照すると、アクセス制御エンジン１０２（図
１）は、アクセス制御が処理されるスピードを増すよう
に複数のサーバにわたり分散される。図３の以下の説明
は、図３に示したシステムコンポーネントのあるものに
よって実行されるファンクションの簡潔な“overview
（概観）" 説明を含み、かつ上述した標準（例えば、X.
741 ）において特定されなかった本発明の形態のより詳
細な説明がこの書類の他のセクションに提供されるとい
うことが理解されるべきである。

【００２０】電話ネットワークのような、多くのインス
タンスにおいて、管理オブジェクトの数は、非常に大き
く、管理オブジェクトへのアクセスを要求する人の数
は、アクセス要求の日常の量のように、対応して大き
い。ほとんどのアクセス要求は、適正に狭くフォーカス
されている。例えば、典型的なアクセス要求は、特定の
位置における特定の型の管理オブジェクトへのアクセス
を要求する。別の例では、ネットワークの一部が修理の
ために遮断されることが必要ならば、アクセス要求に対
するターゲットセットは、遮断されるべきデバイスに対
する管理オブジェクトを指定する。他のアクセス要求、
特に状態情報収集要求(status informationgathering r
equests) は、非常に大きなターゲットセットを含むこ
とができる。管理情報サーバ（ＭＩＳ）１５０は、全て
の管理オブジェクトアクセス要求１２０を受け取り、か
つ各要求、または要求の部分を、要求によって参照され
た管理オブジェクトツリーの部分に従って、一組の補助
サーバ１５２に分散する。各サーバ１５０及び１５２
は、アクセス制御ファンクション及び要求応答収集ファ
ンクションの両方を実行する。それゆえに、アクセス制
御処理は、ＭＩＳ１５０と補助のサーバ１５２との間に
分割され、ヘビー要求トラフィックの期間中のアクセス
要求のより高速な処理を可能にしている。

【００２１】特に、ＭＩＳ１５０は、管理オブジェクト
ツリーの最上部におけるオブジェクトに対するアクセス
制御を実行するだけであり、補助サーバのそれぞれは、
管理オブジェクトツリーのそれぞれ指定されたサブツリ
ーにおけるオブジェクトに対するアクセス制御を実行す
る。上記ステートメントに対する一つの重要な例外は、
事象通知に対する全てのアクセス要求（即ち、“receiv
e notification from"のオペレーションにより）は、ど
のオブジェクトがアクセス要求のターゲットであるかに
係わりなく、ＭＩＳの事象レジストリモジュールに送付
される。これは、事象通知アクセス制御に関して以下に
より詳細に説明される。更に、特別補助サーバ１５４
は、（以下に説明する理由により、従来技術のアクセス
制御データベース１９８と同じではない）アクセス制御
オブジェクトツリー１７０に対する全ての更新を扱うた
めに用いられる。ある実施では、特別補助サーバ１５４
は、ＭＩＳ１５０又は正規の補助サーバ１５２の一つと
マージされうる。代替的に、比較的低いアクセス要求ト
ラフィックを有するシステムでは、特別補助サーバ１５
４は、他のサーバの一つと同じ物理サーバハードウェア
上で個別ソフトウェアエンティティとして実施すること
ができる。ＭＩＳ１５０及び各補助サーバ１５２、１５
４は、アクセス制御オブジェクトツリー１７０の全コピ
ーを記憶するが、管理オブジェクトツリーの対応部分を
アクセスすることの要求を処理することに対してのみリ
スポンシブルである。代替実施例では、ＭＩＳ及び補助
サーバのそれぞれは、その割当てられたアクセス制御フ
ァンクションを実行するのに必要なアクセス制御オブジ
ェクトツリー１７０の一部だけを記憶することができ
る。

【００２２】アクセス要求が二つ以上のサーバによって
サービスされる管理オブジェクトツリーの一部分のター
ゲットオブジェクトを有するならば、アクセス要求は、
ＭＩＳ１５０によってアクセスサブ−リクエストに分け
られかつ適当な補助サーバ１５２に送られる。全てのサ
ーバによって生成されたアクセスサブ−リクエスト応答
は、ＭＩＳ１５０によって照合されかつ要求しているユ
ーザ又はアプリケーションと一緒にそれらに戻される。
ＭＩＳ１５０は、以下のものを含む： ・ アクセス要求を受け取るインタフェース１６０； ・ ＭＩＳのメモリ１６４に記憶されるアクセス制御手
順を実行する一つ以上の中央処理装置（ＣＰＵ' ｓ）１
６２； ・ 揮発性高速ＲＡＭ及び磁気ディスク記憶装置のよう
な不揮発性記憶装置の両方を含んでいる、メッセージ１
６４； ・ ＭＩＳ１５０と補助アクセス制御サーバ１５２、１
５４との間のセキュア通信を扱うインタフェース１６
６；及び ・ ＭＩＳ１５０の上記素子間でデータ及びプログラム
を通信する一つ以上の内部バス１６８。

【００２３】メモリ１６４は、以下のものを記憶しう
る： ・ アクセス制御ツリーの部分的又は完全なコピー１７
０；好ましい実施例のアクセス制御ツリー１７０は、X.
741 において特定されたものとは異なるコンポーネント
及び編成を有し、従って図１のアクセス制御ツリー１０
８は、本発明で用いられるアクセス制御ツリー１７０と
同じではないということに注目すべきである； ・ アクセス要求をアクセスサブ−リクエストに分割
(partitioning) しかつアクセス制御処理のために適当
なサーバにアクセスサブ−リクエストを経路指定(routi
ng) するアクセス要求分割及び経路指定手順１７２； ・ アクセス制御処理に対して各アクセス要求が送られ
るべきサーバを決定するためにＭＩＳ１５０に対して必
要な情報を記憶する、サーバマッピングテーブル１７３
に対するサブツリー； ・ そのファンクショナリティ（機能性）が図１に示し
たＡＣＥＦ１１２のものと同じである、アクセス制御エ
ンフォースメントファンクション１７４； ・ そのファンクショナリティが図１に示したＡＣＤＦ
１１０のものと同じであるアクセス制御決定ファンクシ
ョン１７６； ・ 種々のサーバによって生成された応答を各別個のア
クセス要求にマージしかつイニシエータに単一の組合さ
れた応答を戻す要求応答組合せ手順１７８； ・ その処理がまだ完了されていないアクセス要求につ
いての状態情報のアレイ１８０； ・ 全てのアクセス要求の記録を保持する安全保護監査
トレール１８２； ・ 特定のユーザが要求した事象通知を追跡する機構で
ある、事象レジストリ１８４；及び ・ （Ａ）それらの事象通知を要求し、かつ（Ｂ）それ
らを受け取ることを許可されたユーザ又はアプリケーシ
ョンに事象通知を送るモジュールである、事象ルータ１
８６。

【００２４】図３に示されていないＭＩＳ１５０の他の
形態を以下に説明する。ＭＩＳ１５０及び補助サーバ１
５２，１５４は、全て、アクセス制御手順のライブラリ
の同一のコピー並びにアクセス制御オブジェクトツリー
１７０のコピーを保持する。それゆえに、各補助サーバ
１５２、１５４は、（Ａ）アクセス要求の受取りと分
割、及び応答の組合せを扱うために用いられるＭＩＳの
特別手順（１７２，１７８）、及び（Ｂ）それらがそれ
ぞれアクセス要求を受け取りかつ応答を戻すためのたっ
た一つのインタフェース１６０／１６６を有することを
除き、ＭＩＳ１５０で見出されるものと同じハードウェ
ア及びソフトウェア素子を含む。各補助サーバ１５２
は、アクセス制御オブジェクトツリーの完全なコピー１
７０、またはその補助サーバによって扱われるべきアク
セス要求を扱うための必要なその一部分のいずれかを維
持する。

【００２５】特別補助サーバ１５４は、アクセス制御オ
ブジェクトがアクセス制御システムまたはそのある部分
がある理由により再ブートされるかまたは再スタートさ
れるときにはいつでも全てのアクセス制御サーバによる
使用に対して利用可能であるように永続的記憶装置にア
クセス制御オブジェクトツリー１７０のコピー１９０を
維持する。また、特別補助サーバ１５４は、アクセス制
御オブジェクトツリー１７０に対する全ての更新を扱う
ことに対してもリスポンシブルがある。他のサーバと共
有のアクセス制御ライブラリ手順に加えて、特別補助１
５４は、アクセス制御オブジェクトツリー１７０／１９
０へのアクセス制御を扱いかつアクセス制御オブジェク
トツリー１７０／１９０の更新を扱うための更なる手順
１９４を有する。管理オブジェクトへのアクセスを制限
するために用いられる同じ型のアクセス制御は、また、
アクセス制御オブジェクトツリー１９０／１７０へのア
クセスを制限するためにも用いられる。換言すると、ア
クセス制御オブジェクトツリー１７０のターゲットオブ
ジェクト及び記憶オブジェクトのあるものは、アクセス
制御オブジェクトへのアクセス権利を定義するために用
いられ、かつ特別補助サーバ１５４は、それらのアクセ
ス制御オブジェクトによって定義された規則に従ってア
クセス制御オブジェクトへのアクセスを制限する。この
ようにして許可されたユーザだけがアクセス制御オブジ
ェクトツリー１７０／１９０をアクセスしかつ更新する
ことができる。

【００２６】ＭＩＳ１５０は、どの補助サーバが各要求
をサービスするために必要であるかを知るためにネット
ワークにおけるオブジェクトツリーの十分な知識を有す
る。特に、ＭＩＳ１５０は、アクセス要求分割及び経路
指定手順１７２及び一組の“ツリー分割点オブジェクト
(tree division point objects)"（分割点ノード(divis
ion point nodes)とも称される）を識別する情報を記憶
するマッピングテーブル１７３を有する。より特定的に
は、マッピングテーブル１７３は、一連の記録を含む。
各記録は、ツリー分割点オブジェクト(tree division p
oint object)と呼ばれる最上位オブジェクトによって識
別された、管理オブジェクトサブツリーを識別し、かつ
その管理オブジェクトサブツリーのオブジェクトへのア
クセス要求を扱うためのサーバ１５２も識別する。各ア
クセス要求に対して、ＭＩＳ１５０は、以下に詳述す
る、“大域否認規則(global deny rules)"をまず適用す
る。要求が大域否認規則によって拒絶されないならば、
次いで、ＭＩＳ１５０は、アクセス要求を更に処理する
ために必要なサーバを識別するようにネットワークオブ
ジェクトツリー１７０をトラバースする。

【００２７】より特定的には、各受け取ったアクセス要
求（事象通知に対するアクセス要求以外の）に対してＭ
ＩＳは、それが分割点オブジェクトのいずれかに到達す
るまでネットワークオブジェクトツリーをトラバースす
る。分割点オブジェクトより下の全ての管理オブジェク
トが対応している補助サーバによって処理されるので、
ツリートラバーザルは、それらのオブジェクトで停止す
る。アクセス管理デューティがサーバ間で分割される方
法により、単一アクセス要求は、二つ以上のアクセスサ
ブ要求に分割されかつ更なる処置のために二つ以上のサ
ーバに送られなければならないということが可能であ
る。要求が二つ以上のサーバによって処理されるために
区分される場合、アクセス要求の各区分の基本オブジェ
クト及びスコープ部分（即ち、各サブ要求）は、対応し
ているサーバによってサービスされる管理オブジェクト
ツリーの一部だけを取り囲むように変更される。

【００２８】また、ＭＩＳ１５０は、その処理がまだ完
了していない各アクセス要求の状態情報１８０を保全す
る。状態情報１８０は、完全な応答をイニシエータに戻
すことができる前に部分応答が必要である全てのサーバ
を識別する。実施に応じて、ＭＩＳ１５０は、各要求に
対して大域否認規則を適用することに加えて、いずれの
補助サーバにも割当てられていない管理オブジェクトツ
リーの種々の部分へのアクセスを制限することに対して
もリスポンシブルでありうる。例えば、ＭＩＳ１５０
は、管理オブジェクトツリーのルートノードへのアクセ
スを制限することに対して一般的にリスポンシブルであ
りかつ管理オブジェクトツリーのあらゆる特定のブラン
チ（枝）に対してもリスポンシブルであるようにするこ
とができる。

【００２９】代替実施例では、アクセス制御リスポンシ
ビリティは、例えば、ターゲットオブジェクトで実行さ
れるべきオペレーションの型に基づくような、他の方法
でサーバ間に分割することができる。それゆえに、一つ
のサーバは、セットオペレーションを扱うことに対して
リスポンシブルであり、別のサーバは、オペレーション
を生成しかつ削除する、等である。アクセスセキュリテ
ィ規則は、ＭＩＳ１５０及び各補助サーバ１５２にて、
永続記憶装置に記憶され、最近使用された部分もキャッ
シュメモリに記憶される。アクセス制御規則が更新さ
れ、削除され又はシステムに追加されるときにはいつで
も、全ての補助サーバの規則ベースは、他の型の事象メ
ッセージを扱うためにも用いられる事象伝播機構を用い
て同期方式で更新される。アクセス制御ツリー１７０を
更新する処理は、以下に詳述する。

【００３０】アクセス制御データベース X.741 は、オブジェクトアクセスがユーザを基本として
ユーザ上で制御されることを示すが、本発明は、グルー
プを基本としてグループ上でオブジェクトアクセスを制
御する。ユーザグループ特徴は、各アクセス規則を定義
するために必要なデータ量をかなり低減することを援助
する。システムにおける情報をアクセスすることを認可
された各ユーザは、一つ以上のグループに割当てられ
る。アクセス規則は、グループのアクセス権利により定
義される。例えば、オブジェクトパラメータ読取り権利
は、オブジェクトパラメータ設定規則とは異なるグルー
プを用いて割当てられるであろう。また、規則は、それ
らのグループに関して階層構造的に一般に定義され、例
えば、Customer A（カスタマＡ）グループメンバーまた
はシステム管理者グループメンバーのいずれでもない全
てのものに対するオブジェクトのCustomer Aのサブツリ
ーへのアクセスを否認し、次いでCustomer Aによって設
定されたユーザのグループに従ってCustomer Aのサブツ
リー内のオブジェクトに対する権利を更に定義する。図
４を参照すると、アクセス制御ツリー１７０の主コンポ
ーネントは、グループ定義２００、ユーザ定義２０２、
ターゲット定義２０４、アクセス規則２０６、及び省略
時規則２０８である。各グループ定義２００は、以下の
フィールドを有している、グループオブジェクトによっ
てテーブルわされる： ・ グループ名；及び ・ グループに含まれるユーザの一覧テーブル。 グループオブジェクトは、グループをユーザにマップす
るために用いられる。各ユーザ定義２０２は、以下のフ
ィールドを有しているユーザオブジェクトによってテー
ブルわされる： ・ ユーザ名；及び ・ ユーザがメンバーであるグループの一覧テーブ
ル。

【００３１】ユーザオブジェクトは、特定のユーザが属
する全てのグループを識別するために用いられる。用語
“ユーザ" は、アクセス権利が認可されるユーザ以外の
エンティティを含むということがここで注目されるべき
である。例えば、補助サーバ、ログサーバ、及びシステ
ムにおけるオブジェクトでさえもそれらのエンティティ
に従うべきアクセス権利を定義する目的に対して“ユー
ザ" として設定することができる。各ターゲット定義２
０４は、以下のフィールドを有している、ターゲットオ
ブジェクトによってテーブルわされる： ・ ターゲット名；及び ・ このターゲットオブジェクトによって識別される
ターゲットセットに含まれるべきベース管理オブジェク
トの一覧テーブル； ・ 管理オブジェクトクラスの一覧テーブル；このフ
ィールドは、ターゲットセットが、フィルタ条件（以下
を参照のこと）の対象となる、特定のクラスの全ての管
理オブジェクトを含む場合にのみ用いられる； ・ ターゲットセットに含まれるべき一覧テーブルに
掲げられたベース管理オブジェクトの下の管理オブジェ
クトツリーレベルの数を示している、スコープ（適用範
囲）；及び ・ ターゲットセットに含まれるオブジェクトのセッ
トを限定するために用いられるオプショナルフィールド
である、フィルタ；フィルタフィールドは、データベー
ス問合せの“where"句に等しい；及び ・ ターゲットセットが適用可能であるオペレーショ
ン（get,set,等）を一覧テーブルにする、オペレーショ
ン一覧テーブル。各規則定義２０６は、以下のフィール
ドを有している、規則オブジェクトによってテーブルわ
される： ・ 規則を識別するための規則名； ・ 規則が適用可能な全てのユーザグループを識別す
る、グループ一覧テーブル； ・ 規則が適用可能なターゲットオブジェクトの一覧
テーブルである、ターゲット一覧テーブル；及び ・ ユーザの特定されたグループが特定されたターゲ
ットセットへのアクセスを有するか有しないかを示して
いる、エンフォースメントアクション；好ましい実施例
ではエンフォースメントアクションは、Deny with Resp
onse（応答付き否認）, Deny without Response （応答
なし否認）, またはGrant （認可）に設定することがで
きる。

【００３２】省略時規則２０８は、以下のフィールドを
有している、省略時規則オブジェクトによってテーブル
わされる： ・ オペレーション（例えば、get, set, create, de
lete, 等）の対応する所定の一覧テーブルに対する省略
時エンフォースメントアクションの一覧テーブル；省略
時エンフォースメントアクションの最も一般的な一覧テ
ーブルは、全てのオペレーション型に対するアクセスを
否認することであるが、ある実施ではシステム管理は、
get オペレーションのような、あるオペレーションに対
するデフォルトを、“grant(認可)"にすべく決定しう
る； ・ 事象通知に対する省略時エンフォースメントアク
ション；及び ・ 省略時否認応答（即ち、応答を有する否認または
応答なし否認）。

【００３３】デフォルト２０８は、特定のアクセス要求
に適用される規則が定義されない場合に各オペレーショ
ンに対して定義される省略時応答である。例えば、デフ
ォルトは、そのオペレーションが“Get"である“Grant"
アクセス要求、及びそのオペレーションが“Get"以外の
ものである“Deny with Response" アクセス要求に設定
されうる。しかしながら、ほとんどの実施では全てのデ
フォルトは、“Deny with Response" 又は“Deny witho
ut Response"のいずれかに設定されうるということが期
待される。デフォルト２０８は、定義されたオペレーシ
ョンのそれぞれに対する認可又は否認フラグを含む単一
のDefault （デフォルト）オブジェクトによって定義さ
れるのが好ましい。アクセス制御ツリーの各“rule（規
則）" は、規則オブジェクトで参照されたターゲットオ
ブジェクトによって特定された、一組のターゲットオブ
ジェクトへの（規則オブジェクトにおいて参照されたグ
ループオブジェクトによって識別される）ユーザのある
一定のグループによるアクセスを認可または否認する。
X.741 とは異なり、アクセス規則は、ユーザに基づいて
ユーザで定義されないが、グループに基づいてグループ
で定義される。その結果、特定のユーザが本発明を用い
て会社のに参加しかつ去るときに、それらのユーザに適
用される全ての規則オブジェクトを更新しなければなら
ない代わりに、ユーザ及びグループオブジェクトだけが
更新されることを必要とする。

【００３４】一組のターゲット管理オブジェクトを特定
する規則オブジェクトに加えて、システムは、一つのグ
ローバル否認規則オブジェクト及び一つのグローバル許
容記憶オブジェクトを有することができる。グローバル
規則オブジェクトのそれぞれは、正規の規則オブジェク
トと同じ構造を有するが、規則がグローバル規則である
ことを示す、空ターゲット一覧テーブルフィールドを有
する。グローバル否認規則は、定義されたならば、いず
れかの管理オブジェクト上でいずれかのオペレーション
を実行することができないユーザのグループを特定す
る。グローバル認可規則は、定義されたならば、全ての
管理オブジェクト上で全てのオペレーションを実行する
ことが許可される“スーパーユーザ(super users)"（例
えば、システム管理者）のグループを特定する。

【００３５】アクセス制御ツリー１７０のオブジェクト
が追加、削除又は変更されるときにはいつでも、アクセ
ス制御ツリー１７０を自己矛盾が無いように保ために他
のアクセス制御オブジェクトも変更されなけらばならな
い。例えば、ユーザオブジェクトがユーザオブジェクト
のグループリストに先に含まれていた全てのグループを
削除しかつ識別されたユーザを先に定められた“DenyAl
l"グループのメンバーにすべく変更されたならば、ユー
ザオブジェクトにリストされていた全てのグループオブ
ジェクトは、それらのユーザリストからこのユーザを削
除すべく更新され、かつDenyAll グループオブジェクト
は、このユーザをそのユーザリストに追加することによ
って更新する必要がある。別の例では、ターゲットオブ
ジェクトがアクセスオブジェクトツリー１７０から削除
されるならば、削除されたターゲットオブジェクトを参
照する全ての規則オブジェクトは、削除されたターゲッ
トオブジェクトをそれらのターゲットオブジェクトリス
トから取り除くように変更する必要がある。

【００３６】アクセス制御オブジェクトツリー１７０を
自己矛盾がない状態に維持するということを確実にする
ために、アクセス制御オブジェクトツリー１７０に対す
る全ての変更は、アクセス制御構成手順(Access Contro
l Configuration procedure)２１０と称される手順によ
って実行される。Access Control Configuration proce
dure２１０は、アクセス制御ツリー１７０を変更するこ
とが認可されたユーザに図的ユーザインタフェース２１
２を供給する。Access Control Configurationprocedur
e２１０は、認可されたユーザにアクセス制御ツリー１
７０をナビームゲートさせ、検査させかつ変更させる。
認可されたユーザがアクセス制御ツリー１７０に対して
なされる変更を特定する毎に、Access Control Configu
ration procedure２１０も、それを自己矛盾がないよう
に維持するために要求されるアクセス制御ツリー１７０
に対する全ての他の変更を行う。

【００３７】要求にアクセス制御規則を適用する 図５を参照して、一つ以上のサーバによる処理に対する
分割要求のインパクトを考慮せずにアクセス制御決定機
能１７６のオペレーションをまず説明する。後で、要求
分割及びサーバ間のデューティの部門を説明する。アク
セス要求を受け取った場合、アクセス要求は、グローバ
ル否定規則（ステップ２２０）、ターゲット型否定規則
（ステップ２２２）、グローバル認可規則（ステップ２
２４）、及びターゲット型許可規則（ステップ２２６）
の順番で、連続的に比較される。アクセス要求に合致す
ることが見出された最初の規則は、それに適用される
（ステップ２３０）。合致する規則が見出されないなら
ば、適当なデフォルト規則が適用される（ステップ２３
２）。最初に否認規則、次いで認可規則を適用すること
によって、アクセス否認規則は、アクセス認可規則より
も高い優先度が与えられる。また、この構造は、ユーザ
の広いグループに対してある一定の認可権利を認可すべ
く一組のアクセス規則を定めることを比較的容易にさせ
るが、それらのアクセス権利が否認されるべきサブグル
ープを特定する。

【００３８】アクセス要求が二つ以上のターゲットオブ
ジェクトを伴うターゲットセットを有する場合、異なる
規則が要求によって特定されるターゲットオブジェクト
の異なるものに対して適用されうる。その場合、各特定
ターゲットオブジェクト又はターゲットオブジェクトの
サブグループに適用可能であるということが見出された
最初の規則は、そのターゲット又はターゲットのサブグ
ループに適用される。その結果、アクセス要求のある部
分は、認可されると同時に、他の部分は、否認されう
る。図６を参照すると、アクセス要求分割及び経路指定
手順１７２、アクセス制御決定ファンクション及びアク
セス制御エンフォースメントファンクション１７６、１
７４、及び要求応答組合せて手順１７８によって実行さ
れる動作の順番が示されている。この説明は、事象レジ
ストリによって別個に処理される、事象通知に対するア
クセス要求に適用されないということに注目する。

【００３９】各アクセス要求は、ＭＩＳ１５０によって
受け取られ、それは、次いでアクセス要求をグローバル
否認規則と比較する（ステップ２４０）。合致が見出さ
れたならば、要求は否認され、かつ妥当ならば応答はイ
ニシエータに戻される（ステップ２４２）。（Ａ）適用
可能なグローバル否認規則が“Deny without Response
（応答なし否認）" の強制動作を特定する場合、又は
（Ｂ）要求それ自体が“unconfirmed （確証がない）"
モードを特定する場合には、応答はイニシエータに戻さ
れない。グローバル否認規則で合致が見出されなかった
ならば、ＭＩＳは、処理のために要求が送られるサーバ
を決定すべく要求において特定されたターゲットセット
をサーバマッピングテーブル１７３に対するサブツリー
と比較する（ステップ２４４）。要求のターゲットセッ
トが二つ以上のサーバのドメイン内にあるならば、アク
セス要求はサブ要求に区分され、次いで、各サブ要求は
その対応サーバに送られる。要求が区分された場合、最
初の要求におけるターゲットセットは、関連サーバのド
メインを有するターゲットオブジェクトだけを特定する
ように各サブ要求に対して調整される。

【００４０】要求のターゲットセットが単一サーバのド
メイン内にあるならば、要求全体は、処理のためにその
単一サーバに送られる。ある場合には、要求を処理する
ためのサーバは、ＭＩＳであり、そのような場合には要
求は、ＭＩＳの局所要求キューの末尾に追加される。Ｍ
ＩＳから要求を受け取る各補助サーバは、受け取った要
求を処理のためにその局所要求キューに配置する。ＭＩ
Ｓは、それらが処理のために送られたサーバのテーブル
示により、全ての顕著なアクセス要求に対して状態情報
アレイ１８０（図３）を保持する。アクセス要求が処理
のために送られる各サーバにおいて、アクセス要求は、
アクセス制御決定ファンクションそしてアクセス制御強
制ファンクションを実行することによって実行される。
より特定的には、図５を再び参照すると、ステップ２２
０がＭＩＳによって既に実行されているので、アクセス
制御決定ファンクションのステップ２２２から２３２ま
では、各サーバにおいて実行される。各アクセス要求に
対する否認／認可決定は、安全保護監査トレールに記憶
されうる。

【００４１】本発明の好ましい実施例では、アクセス制
御決定ファンクションは、グローバル構成パラメータの
使用を通して、安全保護監査トレールにおけるアクセス
決定の“logging （ロギング）" の以下のレベルのいず
れかを呼び出すべく構成することができる：（Ａ）情報
がログされないで、オフ、（Ｂ）アクセス要求認可及び
否認についての要約情報を記憶し、イニシエータの識
別、要求されたオペレーション、及びアクセスが認可又
は否認されたターゲットオブジェクト又はオブジェクト
のセットだけを示す、（Ｃ）各アクセス要求認可又は否
認に対して、アクセス要求全体がログされる、全ロギン
グレベル、並びに、アクセスが認可又は否認されたター
ゲットオブジェクトについての全情報。各サーバにおい
て、要求及びサブ要求によって生成された応答は、決定
されかつＭＩＳに送り返される（ステップ２４６）。そ
して、ＭＩＳにおいて、要求が二つ以上のサブ要求に区
分されたならば、応答は、組合され、かつ組合された応
答は、もしあれば、イニシエータに戻される（ステップ
２４８）。要求が区分されなければ、応答は、もしあれ
ば、イニシエータに送られる。また、アクセス要求は、
未決定要求状態テーブル（係属中の要求状態テーブル）
１８０から削除される（図３）。

【００４２】要求が二つ以上のターゲットオブジェクト
を有する場合に応答を組み合わせること 図７は、アクセス要求のターゲットセットが二つ以上の
管理オブジェクトを含む場合にアクセス要求応答が組合
される方法を示しているチャートである。図７のチャー
トは、要求によって特定された少なくとも一つのターゲ
ットオブジェクトへのアクセスが否認された場合にのみ
適用される。全てのターゲットオブジェクトへのアクセ
スが認可される場合には、全てのターゲットオブジェク
トによって生成された応答は、単に組み合わされかつイ
ニシエータに戻される。図７におけるチャートの“non-
scoped operation（非有効範囲動作）" 行に対応してい
る、要求のターゲットセットに一つのオブジェクトだけ
がある場合、応答を組み合わせる必要はない。要求が承
認済要求であれば、適用可能な規則によって生成された
アクセス否認応答は、イニシエータに戻される。適用可
能な規則によって生成された応答が“deny without res
ponse （応答なし否認）" であれば、何の応答も戻され
ない。要求が未承認要求であれば、要求が認可されたか
否認されたかに係わらず何の応答も戻されない。

【００４３】要求が図７におけるチャートの“scoped o
peration（有効範囲動作）" 部分に対応している、二つ
以上のターゲットオブジェクトを特定する場合、戻され
る応答の型は、要求のシンクパラメータ(synch paramet
er) に依存する。要求がアトミック要求であれば、ター
ゲットオブジェクトのいずれかへのアクセスが否認され
る場合には、オペレーション全体が失敗する。要求が承
認済要求であれば、単一の“access denied （アクセス
否認）" 応答がイニシエータに戻される。さもなけれ
ば、要求が未承認要求であれば、何の応答もイニシエー
タに戻されない。要求が二つ以上のターゲットオブジェ
クトを特定し（“scoped operation（有効範囲動作）"
）かつ“best effort （最良努力）" シンクモード(sy
nch mode)を特定する場合には、アクセスが認可される
オブジェクトによって生成された応答は、ユーザに戻さ
れる。アクセスが否認される各オブジェクトに対して、
要求が承認済要求でありかつ適用可能な規則が“deny w
ith response（応答を有する否認）" の強制作用を有す
るならば“access denied （アクセス否認）" 応答が戻
される。さもなければ、適用可能な規則が“deny witho
ut response （応答なし否認）" の強制作用を有するな
らば、アクセスが否認されるオブジェクトに対して何の
応答も戻されない。

【００４４】そして、要求が未承認要求であるならば、
要求のどの部分が認可されどの部分が否認されたかに係
わらずイニシエータに何の応答も戻されない。定義によ
り“get(ゲット)"応答の目的が情報を検索することなの
で、未承認要求は、“get(ゲット)"オペレーションを有
することができないということに注目すべきである。図
７において要約された応答組合せオペレーションは、要
求又はサブ要求が処理される各サーバ１５０、１５２で
まず実行され、かつサブ要求に区分される要求に対して
ＭＩＳで再び実行される。二つ以上のサーバにおいて区
分されかつ処理されるアトミックアクセス要求に対し
て、アクセス制御強制ファンクションは、アクセス制御
決定ファンクションに対する結果がＭＩＳによって組み
合された後にだけ実行される。アクセス要求が一つのサ
ーバだけで処理される（即ち、全てのそのターゲットオ
ブジェクトが単一サーバ１５０，１５２のドメイン内に
ある）場合には、応答組合せオペレーションは、要求を
処理しているサーバによってだけ実行される。

【００４５】事象通知へのアクセスを制限する 本発明では、事象（Event ）（通知(Notifications) ）
へのアクセスは、アクセス制御規則ベースの規則を用い
て、オブジェクトをアクセスするのと同じ方法で制御さ
れる。Ｘ．７４１は、Ｘ．７４１のアクセス制御機構が
適用可能であるオペレーションタイプの一つのタイプと
して事象通知を含まない。事象通知アクセス制御問題の
例は、次の通りである：電話ネットワークプロバイダ
は、顧客Ａが顧客Ｂに対して設置された新しいネットワ
ーク資源についての通知を受け取ることを欲しないが、
顧客Ａは、全ての事象通知を受け取るべくそれ自身を登
録する。本発明は、（Ａ）アクセス規則データベースの
規則によって支配される一組のオペレーション型に事象
通知を追加し、かつ（Ｂ）アクセス規則データベースの
規則に基づき事象通知メッセージをフィルタするシステ
ムの事象ルータにフィルタリング機構を追加することに
よって事象通知アクセス制御問題を解決する。それゆえ
に、ターゲットオブジェクトがアクセス制御オブジェク
トツリー１７０において画定される場合、ターゲットオ
ブジェクトのオペレーションリストにおいて特定するこ
とができるオペレーションの一つは、“事象通知（even
t notifications"である。好ましい実施例では、ターゲ
ットオブジェクトにおいて特定された事象通知オペレー
ションは、一組の特定管理オブジェクトに対する全ての
事象通知を特定することができるか、またはターゲット
オブジェクトに含まれるべき事象通知の型を特定すべく
ターゲットオブジェクトのフィルタフィールドを用いて
ある一定の特定の型の事象通知を特定することができ
る。例えば、ターゲットオブジェクトは、ＳＮＭＰ又は
ＣＭＩＰ生成事象に適用されうるが、オブジェクト生成
及び削除事象のような他の型の事象には適用されない。

【００４６】更に、特定のターゲットオブジェクトは、
事象通知を含んでいる複数のオペレーションに対する一
組の管理オブジェクトへのアクセス権利を画定するため
に用いることができる。例えば、特定の組の管理オブジ
ェクトに関するいずれか及び全ての情報へのアクセスを
否認するために否認規則と共に用いられるべきターゲッ
トオブジェクトは、そのオペレーションのリストに事象
通知を一般的に含む。代替的に、適当である場合には、
別個のターゲットオブジェクトは、事象通知アクセス権
利を画定するために用いることができる。図８を参照す
ると、ＭＩＳ１５０は、事象レジストリ１８４を保持す
る。より精確には、事象レジストリ１８４は、ユーザ事
象要求のテーブル２６０を保持するソフトウェアモジュ
ールである。ＭＩＳは、どのオブジェクトが要求によっ
て特定されるかに係わりなく、その特定オペレーション
型が“事象通知" である全てのアクセス要求を事象レジ
ストリ１８４に指向する。テーブル２６０は、どのユー
ザ又は他のエンティティがそれらの事象通知のコピーを
受け取る要求を登録したかということを、管理オブジェ
クト又はアクセス制御オブジェクトのいずれかによって
生成することができる特定の事象通知に対して、示して
いる情報を記憶する。事象レジストリテーブル２６０
は、ユーザ及び他のエンティティが要求した事象につい
ての情報だけを記憶する。事象通知登録要求（“事象通
知" と同様なオペレーション型を有するアクセス要求で
ある）は、特定オブジェクト、オブジェクトの特定クラ
ス、又はオブジェクトの特定サブツリーのいずれかによ
り特定することができる。それゆえに、例えば、ユーザ
は、ルータオブジェクト（即ち、オブジェクトのクラス
である）に対する全ての事象通知の受取りを要求しうる
し、かつのカリフォルニア州に配置されたルータ又は特
定の会社によって製造されたルータだけのような、フィ
ルタを更に特定しうる。ユーザ及びエンティティは、先
の要求を取り消すこともできる。

【００４７】好ましい実施例では、事象レジストリ１８
４は、要求が意味的に正しくかつ事象が要求さあれる特
定オブジェクトが実際に存在することを確実にすべく登
録要求をチェックするだけである。それゆえに、好まし
い実施例では事象レジストリ１８４は、登録要求が要求
通知を実際に受け取るようにセキュリティクリアランス
を有するようにするユーザ又はエンティティであるかど
うかを確認しない。そのジョブは、事象ルータ１８６に
与えられ、各事象通知が処理されるときに事象通知アク
セス権利をチェックする。その結果、事象通知に対する
ユーザのアクセス権利におけるあらゆる変化が事象ルー
タによって考慮されかつ事象レジストリ１８４に記憶さ
れた情報に影響を及ぼさない。事象通知を受け取ること
を登録することができるユーザ以外のエンティティは、
ＭＩＳ１５０及び補助サーバ１５２、ログサーバ（以下
に詳述する）、及びアクセス制御エンジンの一部である
事象オブジェクト（例えば、以下に詳述するデータベー
スオブジェクト）を含む。

【００４８】（図８で“other event sources （他の事
象源）" によって示される）管理オブジェクトによって
生成された事象通知及び（図８の特別補助サーバ１５４
によって示される）アクセス制御オブジェクトによって
生成される事象通知を含んでいる全ての事象通知は、Ｍ
ＩＳ１５０の事象ルータ１８６に送られる。事象ルータ
１８６は、また、事象レジストリ１８４のユーザ事象要
求２６０のテーブル及びアクセス制御ツリー１７０への
アクセスを有する。事象ルータ１８６によって受け取ら
れた各事象通知に対して、事象ルータは、どのユーザ及
びエンティティがその事象通知のコピーを要求したかを
まず決定し、そして、それらのユーザ及びエンティティ
のどれがそれらの事象通知を受け取るための権利を有す
るかを決定する。事象通知へのアクセス権利の決定は、
図５に示すように、アクセス制御決定ファンクションを
用いて実行される。それゆえに、事象ルータは、マッチ
ング規則が識別されるまでグローバル否認規則、ターゲ
ット否認規則、グローバル認可規則及びターゲット認可
規則を順番に調べる。マッチング規則が見出されないな
らばデフォルト規則が適用される。マッチング規則は、
（Ａ）“事象通知"オペレーションに適用し、（Ｂ）事
象通知を生成したオブジェクトに適用し、かつ（Ｃ）リ
クエスタがメンバであるグループに適用しなければなら
ない。

【００４９】その事象通知へのアクセス権利を有する事
象通知の各リクエスタに対して、事象ルータは、それぞ
れが単一の認可されたユーザ又はエンティティにアドレ
ス指定される、対応する事象通知メッセージを生成す
る。それゆえに単一事象通知は、対応するアクセス権利
を有するリクエスタの数により、ゼロ事象通知メッセー
ジ、または多くの事象通知メッセージを結果として生じ
うる。好ましい実施例で用いられる事象レジストリ１８
４及び事象ルータの一つの特定のアプリケーションは、
以下の通りである。アクセス制御ツリー１７０への全て
のアクセス要求及びアクセス制御ツリー１７０の変更を
扱う特別補助サーバ１５４が存在する。換言すると、そ
のターゲットセットがアクセス制御ツリー１７０に位置
決めされる（事象通知アクセス要求以外の）アクセス要
求は、特別補助サーバ１５４にＭＩＳ１５０によって送
られる。更に、アクセス制御ツリー１７０に対する全て
の変更は、事象ルータ１８６に送られる事象通知の発生
を結果として生ずる。特に、新しいアクセス制御オブジ
ェクトの生成、アクセス制御オブジェクトの削除、及び
あらゆるアクセス制御オブジェクトの属性の変更は、全
て、事象通知の発生を結果として生ずる。

【００５０】ＭＩＳ１５０及び補助サーバ１５２は、ア
クセス制御ツリー１７０における変更に関する全ての事
象通知を受け取るべく事象レジストリ１８４に全て自動
的に登録される。また、ＭＩＳ１５０及び補助サーバ
は、全ての事象通知へのアクセス権利を有する一組の
“super users （スーパーユーザ）" にも含まれる。更
に、ＭＩＳ１５０及び補助サーバ１５２によって共有さ
れるライブラリ手順の間では、事象受け取り及び処理手
順２６２である。ＭＩＳ１５０及び補助サーバ１５２が
アクセス制御ツリー１７０における変更を示しているあ
らゆる事象通知を受け取る場合には、各サーバによって
呼出される事象処理手順２６２は、アクセス制御ツリー
１７０のサーバの局所コピーに対して同じ変更を行う。
その結果、サーバ１５０，１５２のそれぞれにおけるア
クセス制御ツリー１７０の局所コピーは、実質的に同時
に更新される。 管理情報への直接データベースアクセス Ｘ．７４１は、管理オブジェクトデータベースへのＳＱ
Ｌアクセスを求めないし、提案さえもしない。事実、Ｄ
ＢＭＳ機構を介する直接アクセスは、それがセキュリテ
ィ漏れの潜在的な源なので、Ｘ．７４１の目標と反対で
あるとして見られうる。しかしながら、大きな通信ネッ
トワークのコーポレートカスタマは、レポート生成の目
的のために管理情報への直接“読取り専用" アクセスを
要求している。本発明の直接アクセス機構は、ネットワ
ークオブジェクトの状態又は過去の性能についてのレポ
ートを画定しかつ発生すべく標準ＤＢＭＳレポートジェ
ネレータを用いて管理情報への、制限された、読取り専
用アクセスを供給する。これは、ユーザにとっては、都
合がよく、かつ実行されるべき唯一のタスクが状態レポ
ート及び他のネットワークシステム解析レポートの生成
である場合にＳＮＭＰ（又は他のネットワーク管理プロ
トコル）を用いてネットワーク管理情報検索の複雑さを
回避する。

【００５１】本発明の直接アクセス機構は、ネットワー
クへの普通の管理インタフェースを介して要求されたな
らば認可されるであろう情報へのアクセスだけをユーザ
に許容する。図９を参照すると、直接情報アクセス機構
の主要構成要素は、以下のものである：それぞれが種々
のユーザが直接ＳＱＬ型アクセスを要求した事象通知を
記憶する、事象ログ２８２を記憶するための通常のデー
タベース管理システム（ＤＢＭＳ）２８０；及びその主
要ファンクションが事象通知を事象通知を事象ログに記
憶するためのＳＱＬ挿入文に変換することであるログサ
ーバ２９０。通常のＤＢＭＳ２８０は、情報のテーブル
を記憶する。図９は、事象ログ２８２を示すが、各事象
ログは、実際には一つ以上のデータベーステーブルであ
り、各データベーステーブルは、異なる型の事象通知を
記憶する。ＤＢＭＳ２８０は、また、ＤＢＭＳのテーブ
ルのそれぞれへのアクセス権利を構成（即ち、確立）す
る、アクセス特権モジュール２８４も有する。例えば、
アクセス特権モジュール２８４は、どのユーザが事象ロ
グ２８２を構成するテーブルへのアクセスを有するかを
示しているアクセス権利情報を記憶するアクセス特権テ
ーブルを有しうる。しかしながら、アクセス特権モジュ
ール２８４は、各データベーステーブルを伴うアクセス
特権情報を記憶することによるような、他の方法で実行
されうる。本発明は、データベーステーブルアクセス権
利を確立するためにアクセス特権モジュール２８４によ
って用いられる特定の機構に依存しない。

【００５２】好ましい実施例では、特定のユーザが特定
のテーブルへの読取りアクセスを有すると共に、（シス
テム管理者以外に）ログサーバ２９０だけが事象ログテ
ーブルへの書込みアクセスを有する。標準ＳＱＬエンジ
ン２８６は、ログサーバ２９０からの挿入文並びに、ユ
ーザ通信インタフェース２８８を介して提出されるユー
ザ処理又はワークステーション３００からの読取り要求
を処理する。ログサーバ２９０は、システムによって生
成された全ての事象通知を受け取るべく事象レジストリ
で登録され、かつ対応しているアクセス権利を有する。
ログサーバ２９０は、ＭＩＳ１５０と同じコンピュータ
又はコンピュータノード上で実行されるソフトウェアエ
ンティティ又は処理であるのが好ましい。ログサーバ２
９０の一組のフィルタ２９１、２９４は、どの事象通知
がどこへ記憶されかということを決定する。ログサーバ
の第１のフィルタ２９１は、セキュリティオーディット
トレールフィルタ(security audit trail filter) と呼
ばれる。このフィルタ２９１は、ＭＩＳ１５０及び補助
サーバ１５２によって生成された“access grant（アク
セス認可）" 及び“access denial （アクセス否認）"
事象通知をパスする（図８参照）。セキュリティオーデ
ィットトレールフィルタ２９１は、事象通知全体、又は
その特定された部分のいずれかを、セキュリティオーデ
ィットトレールファイル１８２に選択的に記憶すること
ができる。より特定的には、セキュリティオーディット
トレールが詳細モードで稼動すべく構成される場合に
は、セキュリティオーディットトレール１８２は、全て
のアクセス要求及びその全体の対応する出力を記憶す
る。セキュリティオーディットトレールが短縮モードで
稼動すべく構成される場合には、セキュリティオーディ
ットトレール１８２は、全てのアクセス要求の短かくさ
れたテーブル現及び対応する出力を記憶する。

【００５３】セキュリティアラームフィルタと呼ばれ
る、別のログサーバフィルタ２９２は、セキュリティア
ラームが生成されかつオブジェクトアクセスの否認が存
在する場合にのみログに記憶される、セキュリティオー
ディットトレール１８２から分離するSecurity Alarm
（セキュリティアラーム）ログ２９３を生成するために
用いられる。好ましい実施例では、記憶されたセキュリ
ティアラームは、各否認されたアクセス要求を起動した
ユーザを識別する。図９に示した他の型のログサーバフ
ィルタは、事象ログフィルタ２９４である。各事象ログ
フィルタは、事象通知の特定の組だけをパスすべく設定
される。例えば、特定のカスタマは、そのカスタマに割
当てられた管理オブジェクトに対する全てのＳＮＭＰ／
ＣＭＩＰ事象通知への直接アクセスをその従業員のある
一定のグループが有するということを要求しうる。ログ
生成／削除手順２９６は、以下によって対応する事象ロ
グを画定するために用いられる： （Ａ）要求事象通知（別個の事象通知型毎に一つの別個
のＤＢＭＳテーブル）を記憶するためのＤＢＭＳテーブ
ル２８２の対応する組（即ち、事象ログ）を画定しかつ
初期化すること； （Ｂ）データベースオブジェクト２９８を画定しかつ生
成し、かつそれらの事象通知を受け取るためにユーザの
権利に影響を及ぼしている事象通知を受け取るべく事象
レジストリを有するデータベースオブジェクト２９８を
登録する；データベースオブジェクト２９８は、事象ロ
グが記憶されるＤＢＭＳテーブルのリストを含む第１の
属性、及び事象通知へのアクセス権利を伴うグループの
リストを含む第２の属性を含む； （Ｃ）グループ名がデータベースオブジェクト２９８に
まず追加されて、データベースオブジェクト２９８は、
事象ログ２８２を構成しているテーブルへのアクセス権
利を伴うユーザの初期セットを画定すべくデータベース
テーブルアクセス認可コマンドの初期セットをＤＢＭＳ
に送る；及び （Ｄ）要求された事象通知だけをパスしかつ各パスされ
た事象通知をＤＢＭＳテーブルの対応するものに挿入す
るためにそれらをＳＱＬ挿入文に変換するために事象ロ
グフィルタ２８２を画定しかつ生成する。

【００５４】各事象ログ２８２に対して、（１）事象通
知が事象ログに記憶されるべき管理オブジェクトのター
ゲットセット、及び（２）事象ログに含まれるべき事象
通知の型を画定するアクセス制御オブジェクトツリー１
７０に一つ以上の対応ターゲットオブジェクトが存在す
る。特定の事象ログに対して、承認されたユーザのグル
ープのセットは、その事象ログの全ての事象通知に対し
て同じでなければならない。事象ログへのアクセスを認
可されるべきユーザのグループにおけるあらゆる変更
は、事象ログに対応しているターゲットオブジェクトへ
の属性変更についての事象通知を受け取るべく事象レジ
ストリでデータベースオブジェクトを登録することによ
って対応データベースオブジェクト１９８に通信され
る。また、データベースオブジェクト２９８は、事象ロ
グへのアクセス権利を有するグループに対するグループ
オブジェクトへの属性変更の事象通知を受け取るべく登
録される。

【００５５】特定事象ログ２８２に対するデータベース
オブジェクト２９８が事象ログ２９１へのアクセス権利
を伴うグループの一つのメンバーシップにおける変更
（即ち、追加及び／又は削除）、又は事象ログの事象通
知へのアクセスが与えられるべきグループのセットにお
ける変更を通知される場合にはいつでも、データベース
オブジェクト２９８は、対応アクセス認可及びアクセス
取り消しコマンドをＤＢＭＳ２８０に送る。次いで、ア
クセス特権モジュール２８４は、それによりデータベー
ステーブルアクセス権利を再構成する。事象ログに対応
している事象通知が生成されると、事象通知は、ログサ
ーバ９０に事象ルータ１８６によって送られる。ログサ
ーバ２９０は、事象通知を事象ログのフィルタ２９４に
送り、そこで事象通知は、ＳＱＬ挿入文に変換されかつ
記憶のためにＤＢＭＳ２８０に送られる。同じ事象通知
のあるものが二つ（又はそれ以上）の異なる事象ログ２
８２に含まれるならば、同じ事象通知は、ＤＢＭＳｎｏ
異なるテーブルに二度（又はそれ以上）記憶されるであ
ろう。

【００５６】ＳＱＬエンジン２８６は、事象ログに対し
て先に画定されたアクセス制限を強制する。特に、ＤＢ
ＭＳのテーブルからの情報に対する全てのユーザ問合せ
は、アクセス特権モジュール２８４によって確立された
アクセス権利に対してＳＱＬエンジン２８６によってチ
ェックされ、かつそれらのアクセス権利に完全に従う問
合せだけが処理される。ユーザがアクセス権利を有さな
いテーブルからの情報を要求しているユーザ問合せは、
ＳＱＬエンジン２８６によって拒否される。ＤＢＭＳ２
８０からの情報に対するユーザ要求は、ＳＱＬ問合せの
形で提出されなければならないので、ＤＢＭＳに対して
利用可能な全てのレポートジェネレータツールは、管理
情報に対するＳＱＬ問合せを生成することに適用するこ
とができる。それゆえに、図９に示したＤＢＭＳアクセ
ス機構は、管理情報サーバによって供給されたものと同
じアクセス制限を供給すると同時に、高速でかつよく知
られたＤＢＭＳアクセスツールを使用することの便利さ
を供給する。更に、ＤＢＭＳ２８０によって課せされた
アクセス制限は、対応事象通知へのアクセス権利が、管
理オブジェクトツリーの情報へのアクセスを制御する主
要アクセス制御エンジンにおいて変更されるときにはい
つでも自動的に更新される。

【００５７】代替実施例 管理オブジェクトデータベースに記憶される管理情報へ
の直接ＳＱＬアクセスの一実施例は、上述された。以下
に更なる二つの実施例を説明する。アクセス制御は、上
記の説明ではユーザのグループに制限されているけれど
も、以下に説明する第２及び第３の実施例の両方では、
アクセス制御は、グループだけでなく個々のユーザも含
むべく拡張される。本発明の直接アクセス機構は、ネッ
トワークへの正規の管理インタフェースを介して要求さ
れたならば認可されるであろう情報へのアクセスをユー
ザに許容する。以下の説明では、同様な参照番号は、既
に説明した構成要素を含む、同様な構成要素を参照する
ための用いられる。

【００５８】直接情報アクセスシステムの第２の実施例 図１０を参照すると、ビューを用いる直接情報アクセス
システム１０００が示されている。直接情報アクセスシ
ステム１０００の主要構成要素は、テーブル３１０、３
２０を記憶するための通常のＤＢＭＳ２８０、アクセス
制御サーバ３３０、アクセス制御ツリー１７０、情報転
送モジュール３４０、及びネットワーク１０６。ネット
ワーク１０６及びアクセス制御ツリー１７０は、上述し
た。アクセス制御サーバ３３０は、上述したアクセス制
御決定ファンクション１１０及びアクセス制御エンフォ
ースメントファンクション１１２を備えている。情報転
送モジュール３４０は、上述した事象ルータ１８６及び
ログサーバ２９０を備えている。更に、情報転送モジュ
ール３４０は、ネットワーク１０６からＤＢＭＳ２８０
のテーブル３１０、３２０に管理オブジェクト状態値の
ような、非事象関連情報を転送することができる。上述
したように、好ましい実施例では、特定のユーザが特定
のテーブルへの読取りアクセスを有すると同時に、情報
転送モジュール３４０及びシステム管理者だけがテーブ
ルへの書込みアクセスを有する。ＳＱＬエンジンのよう
な標準データベースアクセスエンジン２８６は、情報転
送モジュール３４０からの挿入文並びにユーザ処理又は
ワークステーション３００からの読取り要求を処理す
る。

【００５９】ＤＢＭＳ２８０は、情報のテーブル、Tabl
e 1 からTable Ｎ、３１０及び３２０をそれぞれ記憶す
る。より特定的には、各テーブル３１０，３２０は、事
象ログのエントリ又は管理オブジェクトの一つのクラス
に対する管理情報（例えばルータ）のいずれかを記憶す
る。テーブル３１０，３２０は、行３１１、３１２、３
２１、３２２に管理情報を記憶する。また、図１１Ａを
参照すると、データベーステーブルの各行のフォーマッ
トは、データの列：Data 1, …, Data Nが後に続く管理
オブジェクトの“fully distinguished name（完全識別
ネーム）" （ＦＤＮ）と呼ばれるフィールドを含むのが
好ましい。好ましくは、各行に対するＦＤＮは、その情
報がその行に記憶される管理オブジェクトに対するツリ
ー経路（管理オブジェクトツリーを通して）を表わす。
オブジェクトに対するツリー経路は、a 、b 及びc がツ
リー経路に沿ったノードを示す、“a/b/c/…" の形で表
わされうる。例えば、ＦＤＮは、 /systemid= “sys1"/owner=“abccompany"/devicetype=
“router"/… のようになる。

【００６０】ＦＤＮは、テーブルに記憶されたデータに
対して主要キーとして動作する。以下に説明するセキュ
リティ機構を用いて、ＦＤＮは、どの管理オブジェクト
を特定のユーザがアクセス又は変更することを許可され
るか決定するキーとして用いられる。図１０を再び参照
すると、上述した実施例とは異なり、この実施例では、
テーブル３１０、３２０の行３１１、３１２、３２１、
３２２は、多くのユーザのネットワークに関連する管理
オブジェクトに対する管理情報を含む。本発明は、各ユ
ーザが当該ユーザがアクセス制御サーバ３３０によりア
クセスすることを許可されるであろう管理情報へのアク
セスだけを許可されるようにデータベーステーブル３１
０、３２０の管理情報へのアクセスを制限する方法を提
供する。即ち、アクセス制御ツリー１７０によって表わ
される同じ管理情報アクセス権利及び制限もまたＤＢＭ
Ｓによって強制される。 Views （ビュー） テーブルに記憶される管理情報へのユーザアクセスを制
限するために、この第２の実施例は、“Views （ビュ
ー）" と呼ばれるデータベースファンクションを用い
る。ＤＢＭＳ２８０のデータベースアクセスエンジン２
８６は、Views をインプリメントするモジュールを有す
る。Views は、データベースエンジンによって用いられ
るよく知られたツールである。Views は、例えば、デー
タベーステーブル列に容易に覚えられるエイリアスを割
当てることによって、未経験なユーザが問合せを生成す
ることを容易にさせるためにしばしば用いられる。View
s は、ユーザにアクセス可能であるデータベーステーブ
ルの列及び行を制限するためにも用いることができると
いうこともよく知られている。

【００６１】Viewは、本質的に、ユーザからある一定の
列及び行を隠すことによって、又は代替的に特に指定さ
れた列及び行へのユーザのアクセスを制限することによ
って、アクセスを制限するために用いることができる。
また、あるデータベースエンジンは、ユーザの特定のセ
ットに特定のViewの使用を制限するためのセキュリティ
機構も供給する。Views のこれらのファンクションは、
当業者によく知られており、それらが本発明のこの実施
例によって利用されるということを除いて、詳細に説明
しない。ＳＱＬコマンドのパラメータとしてテーブルの
ネームを用いることによって、テーブル３１０，３２０
の列（フィールド）を直接アクセスする代わりに、ユー
ザは、ユーザがアクセス権利を与えられたViewを介して
データベーステーブルをアクセスしなければならない。
Viewは、ユーザがアクセスを与えられたテーブル列及び
行を制限するようにユーザのデータアクセス要求をフィ
ルタする。

【００６２】この実施例では、ユーザ及びデータベース
テーブルの各可能なペアリングに対して別々のViewが用
いられかつ各Viewは、ユーザ−テーブルペアを識別する
ような方法で命名される。好ましくは、Views に対する
命名規定は、“view#tablename#username"であり、ここ
で“tablename"は、テーブルのネームを表わし、“user
name" は、ユーザのネームを表わす。例えば、Views ３
５０のセットは、ネーム“view#Table1#user1"を伴うvi
ew３５１を含む。また、図１１Ｂを参照すると、管理情
報に対するユーザ要求１１０２は、要求の一部として一
つ以上のViewネームを含み、各Viewネームは、“view#t
ablename#username"命名規定を後続する。Viewの各ネー
ムは、対応テーブルネームの代わりにＳＱＬコマンドに
おいて用いられる。例えば、そのＦＤＮが“/a/b/c" に
等しい管理オブジェクトに対する“table １" と命名さ
れたテーブルのデータを読取るために、“Max"と命名さ
れた承認されたユーザは、 ＳＱＬコマンド：SELECT^* FROM view#table1#max WHERE
FDN= “/a/b/c" を用いるであろう。

【００６３】好ましい実施例では、Views は、各所望の
ユーザネーム- テーブルネームペアリングに対して生成
される。代替的に、Views は、各所望のグループネーム
−テーブルネームペアリングに対して生成されうる。代
替実施例では、個々のViewは、各ユーザネームに対して
画定されるが、複数のテーブルをアクセスするために用
いられる。代替的に、各Viewは、ユーザのグループ（単
一のグループネームに対応している）に対して画定され
かつ複数のテーブルをアクセスするために用いられる。

【００６４】Viewを生成する Viewを使う前に、Viewを生成しなければならない。好ま
しくは、システム管理責任者３０２は、アクセス制御サ
ーバ３３０に記憶される“Create#View"procedure （手
順）３６２を呼出すことによってViews ３５０を生成す
る。システム管理責任者３０２は、Create#View proced
ure ３６２に対する呼出しを呼出し、それは次いで所望
のViewを生成すべくＤＢＭＳ２８０にCreate View SQL
command３６０を実行させる。Create#View procedure
３６２は、View３５１、３５２を生成すべくアクセス制
御ツリー１７０によって画定されたユーザアクセス権利
をＳＱＬコマンドにマップする。この第２の実施例では
（及び第３の実施例においても同様に）、アクセス制御
ツリー１７０は、管理オブジェクトをアクセスことを許
可される全てのユーザを一緒にリストするグループオブ
ジェクト２００及びグループオブジェクト２０２を含
む。Create#View procedure ３６２を呼出す場合、手順
にパスされるパラメータは、ユーザネームのリスト及び
管理オブジェクトを含んでいるデータベーステーブルの
リストを含む。リストされたユーザネーム及びテーブル
の全ての可能なペアリングに対するViews は、リストさ
れたテーブルに対する現行オブジェクトアクセス規則に
基づいて生成される。所与のユーザ及びデータベーステ
ーブルに対して、Create#View procedure ３６２は、us
erTargetMap と呼ばれる固有のユーザターゲットマップ
を生成する。userTargetMap は、global Deny Flag（グ
ローバル否認フラグ）、ｇlobal Grant Flag（グローバ
ル認可フラグ）、item Deny list（項目否認リスト）、
item Grant list （項目容認リスト）を有する。項目
は、行に対応しかつ行は、一つの管理オブジェクトに関
連する管理情報を記憶する。userTargetMap を構築する
ために、Create#View procedure ３６２は、所望のユー
ザが、事実、少なくともある管理オブジェクトへのアク
セスを有する承認されたユーザであるかどうかを決定す
べくアクセス制御ツリー１７０の規則をチェックする。
そうであれば、Create#View procedure ３６２は、所与
のユーザ及び所与のテーブルのオブジェクトの両方に適
用可能な全ての規則を解析しかつuserTargetMap の適当
なフラグを設定するか又はitem Deny list（項目否認リ
スト）及び/ 又はitem Grant list （項目容認リスト）
におけるＦＤＮｓのリストを更新するかによってuserTa
rgetMap を更新する。

【００６５】次いで、Create#View procedure ３６２
は、ユーザ- テーブルペアに対するuserTargetMap を
“Create View"ＳＱＬコマンド３６０に変換する。View
を生成するための例示的ＳＱＬステートメントは、次の
ようである： CREATE VIEW view#Table1##scott FROM Table1 WHERE FDN IN [FDN for managed object 1, FDN for managed object 2, …] このコマンドによって生成されたViewを用いてアクセス
可能であるテーブルの全ての行は、Where クローズ
（句）にリストされたそれらのＦＤＮｓを有する。テー
ブルのどの行をWhere クローズにリストすべきかを決定
するために、userTargetMap は、次のように解釈され
る： ・ global Deny Flagが設定されたならば、Create#V
iew procedure ３６２は、empty view（エンプティビュ
ー）を生成する。 ・ デフォルトアクセスアクションがアクセスを認可
することであるか、またはglobal Grant Flag がＴＲＵ
Ｅ（真）であるならば、Create#View procedure３６２
は、item Deny Listを検査しかつitem Deny Listに含ま
れない適用可能なテーブルの全ての行（項目）のＦＤＮ
をWhere クローズに追加する。 ・ さもなければ、Create#View procedure ３６２
は、item Grant List にリストされるオブジェクトを決
定し、かつitem Grant List に含まれる各行（項目）の
ＦＤＮをWhere クローズに追加する。 代替実施例では、“Create View"ＳＱＬコマンドのWher
e クローズは、アクセス制御ツリー１７０のターゲット
オブジェクトのスコープ及びフィルタフィールドを対応
する Whereクローズ条件にマッピングすることによって
短縮することができる。その結果、Where クローズのあ
る項目は、管理オブジェクトのサブツリー全体を表わす
ようにワイルドカード文字を用いうる。Ｗｈｅｒｅの他
の項目は、オブジェクトのサブツリー、或いはオブジェ
クトのツリー全体にも条件を設けうるし、それにより、
Viewに含まれるべきオブジェクトを間接的に特定する。
Viewに含まれるべきオブジェクトのグループを特定する
これらの方法の両方を示しているCreate View command
の例は、次のようである： ここで、“/partial#path1/%" 及び“/partial#path2/
%" は、両方ともに、その経路が特定の部分経路で始ま
る管理オブジェクトサブツリーにおける全てのオブジェ
クトが画定されたViewに含まれるということを示す。

【００６６】Viewを生成した後、Create＿View procedu
re３６２は、Viewが生成されたユーザにそれを用いる許
可を認可する。例えば、Viewを用いるための許可を認可
するためのＳＱＬコマンドは、以下のようである： Format of Grant command: GRANT privilege type ON view#name To user Example of Grant Command: GRANT SELECT ON view#Table1#scott To scott. このGRANT ステートメントを実行した後、システム管理
責任者、“scott"と命名されたユーザは、“view#Table
1#scott"と命名されたViewを利用することができる。代
替実施例では、複数のテーブルに記憶される管理情報を
アクセスするために単一のViewを生成することができ
る。代替的に、単一ツリーのViewを生成することがで
き、かつViewへのアクセスは、グループ認可コマンドを
用いて、又は複数のユーザをリストしている一つ以上の
Grant コマンドを実行することによって、グループネー
ムを有しているグループの全てメンバーであるユーザの
グループに許可することができる。

【００６７】Viewを問合せる 図１０を再び参照すると、一度Viewが生成されると、ユ
ーザ３００がＤＢＭＳ２８０をアクセスすべくＳＱＬコ
マンドを発行する場合、データベースアクセスエンジン
２８６は、Viewが要求されていたということをネームか
ら認識しかつｖiew アクセスコントローラ３８０は、ユ
ーザ３００がViewを問い合わせる許可を有するというこ
とをチェックする。ｖiew アクセスコントローラ３８０
は、データベースエンジン２８６に、ユーザのＳＱＬコ
マンドで命名されたViewを問い合わせるかどうかを知ら
せるべくデータベースエンジン２８６に応答する。

【００６８】Viewを更新する この実施例では、アクセス制御サーバ３３０は、アクセ
ス制御データベースに対する全ての変更を実行するアク
セス制御構成手順２１０（図４参照）を有する。この実
施例では、アクセス制御構成手順２１０は、コマンド、
Call to an Update#View procedure３７２を発行する。
Update#View procedure ３７２は、ＤＢＭＳにDelete V
iew SQL instruction ３７０を実行させることによって
既存のViewを削除する。次いで、Update#View procedur
e ３７２は、Viewを再生成するためにCreate#View proc
edure ３６２を呼出す。

【００６９】メモリ 図１２Ａ及び１２Ｂを参照すると、アクセス制御サーバ
のメモリ及びＤＢＭＳは、更なるデータ及び手順を記憶
する。図１２Ａは、先に記述されたもの並びにこの第２
の実施例に対してアクセス制御サーバ３３０のメモリに
記憶される更なる情報を示す： ・ アクセス制御ツリー１７０； ・ ターゲットオブジェクト２０４、規則オブジェク
ト２０６、グループオブジェクト２００及びユーザオブ
ジェクト２０２を含む、アクセス制御ツリー１７０の規
則２６０； ・ ＤＢＭＳ２８０のCreate View SQL command ３６
０を呼出すためのCreate#View procedure ３６２；及び ・ 上述したようなUpdate#View procedure ３７２。
図１２Ｂは、第２の実施例に対してＤＢＭＳ２８０のメ
モリに記憶される情報のあるものを示す： ・ それぞれが行３１１、３１２、３２１、３２２を
有している、データベーステーブル１からＮ３１０、３
２０； ・ データベースアクセスエンジン２８６； ・ ユーザのグループに対して生成された個々のユー
ザ及び/ 又はView３５３、３５４に対して生成されたVi
ew３５１、３５２を含んでいる、Views のセット３５
０； ・ Create View SQL command ３６０； ・ Delete View SQL command ３７０； ・ grant access SQL command（アクセス認可ＳＱＬ
コマンド）３７４； ・ revoke access SQL command （アクセス取り消し
ＳＱＬコマンド）３７６；及び ・ view（ビュー）アクセスコントローラ３８０。 管理オブジェクトへの直接アクセスを制御する方法 図１３Ａは、ユーザ及びグループに対して管理オブジェ
クトへの直接ユーザアクセスをそれぞれ制御する方法を
示す。

【００７０】ユーザによる直接アクセス 図１３Ａを参照すると、ステップ１３１２及び１３１４
は、アクセス制御サーバ及びその後続の利用の初期構成
を表わす。より特定的には、ステップ１３１２ではアク
セス制御オブジェクトを含んでいるアクセス制御データ
ベースが記憶される。アクセス制御オブジェクトは、管
理オブジェクトの特定のセットへのユーザ（並びにユー
ザのグループ）によるアクセス権利を特定する情報を集
合的に記憶する。特定のアクセス権利は、ネットワーク
から管理情報を取得するためのアクセス権利を含む。ス
テップ１３１４は、アクセス制御を用いてアクセス制御
データベースによって特定されたアクセス権利に従って
管理オブジェクトへのアクセスをユーザに供給する。ス
テップ１３１６、１３１８、１３２０、１３２２及び１
３２４は、アクセス制御サーバによって強制されたもの
と調和するアクセス制限を伴う、管理情報への直接アク
セスを少なくともあるユーザに供給すべくＤＢＭＳを設
定するための手順を表わす。ステップ１３１６では、管
理情報は、ネットワークからデータベース管理システム
へ送られる。換言すると、ある一定の型の管理オブジェ
クトに対して、管理情報は、複製されかつＤＢＭＳに記
憶される。一般的に、個々のＤＢＭＳテーブルは、ＤＢ
ＭＳを介してアクセス可能であるべくそれぞれ別個の型
の管理オブジェクトに対して設定される。第２及び第３
の実施例では、ログ及びログエントリは、他の全てのオ
ブジェクトのように処理される。

【００７１】ステップ１３１８は、データベース管理シ
ステムの一組のデータベーステーブルに情報転送モジュ
ールによって送られた管理情報を記憶する。テーブル
は、対応する管理オブジェクトに対して個別の行に管理
情報を記憶する。換言すると、ＤＢＭＳは、その管理オ
ブジェクト型に対して設定されたテーブルの別個の行に
各管理オブジェクトに対する情報を記憶する。ステップ
１３２０では、テーブルのユーザの特定されたセット及
び管理オブジェクトの特定されたサブセットに対する一
組のViews が生成される。ステップ１３２２では、一組
のViews は、データベース管理システムに記憶される。
一組のViews は、テーブルに記憶される管理情報へのア
クセスを制限する。セットの各Viewは、このViewを用い
てアクセス可能である特定のテーブルの行のサブセット
を画定する。アクセス可能な行のセットは、特定のユー
ザ（又はユーザのグループ）に対してアクセス制御デー
タベースによって特定される管理オブジェクトアクセス
権利に対応する。

【００７２】ステップ１３２４は、どのViews がデータ
ベース管理システムの特定されたユーザ（又はユーザの
グループ）によって使用可能であるかを特定する。ステ
ップ１３２６では、テーブルの情報は、各ユーザが当該
ユーザがデータベース管理システムのアクセス制御デー
タベースによってアクセスすることを許可される管理情
報だけをアクセスするようにviews を用いてアクセスさ
れる。一度ＤＢＭＳが先のステップによって設定された
ならば、ユーザは、制限なくＤＢＭＳのViews 及び情報
を利用し続けることができる。ＤＢＭＳに管理情報を送
るためのステップ１３１６、１３１８は、サン新情報が
ＤＢＭＳに記憶されることを確実にすべく継続的又は周
期的ベースで動作するのが好ましい。また、ステップ１
３２０、１３２２は、進行中の処理を表わす。アクセス
制御データベースに対する変更は、Views 定義に対して
対応する変更を行うことによってＤＢＭＳに複製され
る。

【００７３】グループによる直接アクセス Views が個々のユーザの代わりにユーザのグループに対
して生成される場合、ユーザの各グループは、アクセス
制御ツリー１７０のグループオブジェクトの一つに対応
し、かつ各Viewは、ユーザの一グループだけによって使
用可能である。各承認されたユーザは、ＤＢＭＳにログ
される場合、Views が生成されたグループの一つのメン
バーとして識別される。ユーザが二つ以上のグループの
メンバーであれば、ユーザは、ユーザがＤＢＭＳのデー
タをアクセスする場合に用いるであろうグループアクセ
ス権利を識別することを要求される。 Views を更新する方法 図１３Ｂを参照すると、新しい管理オブジェクトが管理
オブジェクトツリーに追加されたときにはいつでも（ス
テップ１３３０）、ＤＢＭＳで定義されたViews のセッ
トを更新するようにUpdate#View procedure が呼出され
る（１３３２）。同様に、アクセス規則がアクセス制御
データベースにおいて追加（ステップ１３３４）、削除
（ステップ１３３６）または変更（ステップ１３３８）
されたときにはいつでも、ＤＢＭＳで定義されたViews
のセットを更新するようにUpdate#View procedure が呼
出される（１３３２）。

【００７４】管理オブジェクトの属性値が変わる場合に
は（ステップ１３４０）、Update#View procedure が呼
出されうる（ステップ１３３２）。アクセス制御データ
ベースのフィルタフィールドは、管理オブジェクトの属
性値を用いてアクセス権利を画定する方法である。上記
したように、フィルタフィールドは、ＳＱＬ“WHERE"ク
ローズと同等である。特に、アクセス制御データベース
の規則が変更された管理オブジェクトに関するユーザの
アクセス権利及びフィルタを有するならばUpdate#View
procedure は、呼出される。この実施例では、管理オブ
ジェクトが削除される場合には、Views は、更新されな
い。Viewが問合せられた場合には、削除された管理オブ
ジェクトに対する管理情報は、ユーザに戻されない。代
替実施例では、管理オブジェクトが削除される場合に
は、Update#View procedure ３７２は、呼出される。

【００７５】Update#View procedure を呼出す場合に
は、手順にパスされたパラメータは、ユーザネームのリ
スト及び管理オブジェクトを含んでいるデータベーステ
ーブルのリストを含む。リストされたユーザネーム及び
テーブルの全ての可能なペアリングに対するViews は、
リストされたテーブルに対する現行オブジェクトアクセ
ス規則に基づいて再生成される。次に説明するように、
Views が更新されるデータベーステーブルのリストは、
管理オブジェクト生成又はアクセス規則の変更によって
潜在的に影響を受けるViews に制限されるのが好まし
い。オブジェクトが管理オブジェクトツリーに追加され
るか、またはアクセス規則が追加されるか或いはオブジ
ェクトに関して変更される場合には、変更されることが
必要なViews だけが、そのオブジェクトのオブジェクト
型についての情報を記憶するために用いられるテーブル
に対するViews である。各オブジェクト型に対してデー
タベースに一つのテーブルだけが存在し、従って、対応
オブジェクトが追加されるかまたは対応オブジェクトに
対する規則が生成されるか又は変更される場合にその一
つのテーブルに対するViews だけが更新される必要があ
る。

【００７６】事象ログテーブルに関して、そのようなテ
ーブルに対するViews は、管理オブジェクトツリーへの
オブジェクトの追加によって一般的に影響を受けない
が、ある状況では、アクセス制御規則に対する変更は、
事象ログテーブル並びに一つ以上の管理オブジェクトテ
ーブルの両方へのアクセスに影響を与えうる。例えば、
全ての管理情報への特定ユーザアクセスを全体的に否認
する規則変更は、多数のViews に対する変更をもたらし
うるか、または代替的にそのユーザに対する全てのView
s をＤＢＭＳから削除させうる。同様に、管理オブジェ
クトの大きなサブツリーへの広範囲なアクセス権利をユ
ーザに与える規則変更は、多数のViews に対する更新を
もたらす。新しい管理オブジェクトの生成によってもた
らされたView更新の例は、次の通りである。XTable、Yt
able及びZTableと呼ばれるデータベースは、それぞれX-
MOC 、Y-MOC 及びZ-MOC と呼ばれる管理オブジェクトの
クラスを表わすものと想定する。また、XTableがX1-MO
I、X ２−MOI 及びX3-MOIを表わしている３つの行を有
し、二つのユーザU1及びU2が存在し、かつXTableに対し
て二つのViews ：view#XTable#U1及びview#XTable#U2が
存在するものと想定する。X4-MOIと呼ばれる新しい管理
オブジェクトインスタンスが生成されたならば、Update
#View procedure ３７２は、X4-MOIが二つのviews のい
ずれかに追加されるべきかどうかを決定すべくアクセス
制御データベースをチェックする。アクセス制御データ
ベースをチェックした後に、Update#View procedure
が、X4#MOIがX-MOC クラスにだけ属するということを決
定したならば、XTableに影響を与えているViews は、更
新される必要がある。他のテーブル、YTable及びZTable
が影響を受けないので、それらのviews は、影響を受け
ない。纏めると、X4-MOIオブジェクトの生成は、view#X
Table#U1及びview#XTable#U2Views だけが更新されるこ
とを必要とする。しかしながら、実際に変更されるView
s は、新たに追加されたオブジェクトへの読取りアクセ
スを有するユーザに対するものだけである。

【００７７】Update View Procedure のオペレーション Update#View procedure ３７２に対するパラメータリス
トは、ユーザネームのリスト及びデータベーステーブル
のリストを含む。リストされたユーザネーム及びテーブ
ルの全ての可能なペアリングに対するViews は、リスト
されたテーブルに対する現行オブジェクトアクセス規則
に基づいて再生成される。換言すると、これらのユーザ
- テーブルペアに対する既存のViews は、削除されかつ
更新されたものが生成される。データベースViews を生
成するためのCreate#View procedure ３６２の上記説明
を参照のこと。代替的に、ある一定の状況において、先
に生成されたViews を再生成する代わりに変更すること
ができる。例えば、新しい管理オブジェクトが生成され
た場合、先に生成されたViews の定義は、新たに生成さ
れたオブジェクトに対するrFDNs を先に生成されたView
s の適用可能なものに追加することによって変更するこ
とができる。

【００７８】直接情報アクセスシステムの第３の実施例 図１４を参照すると、トリガを用いる直接情報アクセス
システム１４００が示されている。直接情報アクセスシ
ステム１４００の主要構成要素は、テーブル３１０、３
２０を記憶するための通常のＤＢＭＳ２８０、アクセス
制御サーバ３３０、アクセス制御ツリー１７０、情報転
送モジュール３４０、及びネットワーク１０６である。
以下に示すことを除き、図１０を参照して説明したシス
テム１０００の構成要素は、この第３の実施例での使用
にも適する。直接情報アクセスシステムの第２の実施例
に対して説明したデータベーステーブル３１０、３２０
及び行３１１、３１２、３２１、３２２は、第３の実施
例での使用にも適する。第２の実施例のように、第３の
実施例では、テーブル３１０、３２０の行３１１、３１
２、３２１、３２２は、管理オブジェクトに対する管理
情報を含む。アクセス制御ツリー１７０によって表わさ
れる同じ管理情報アクセス権利及び制限がこの第３の実
施例のＤＢＭＳによっても強制される。第３の実施例
は、ある一定のＳＱＬコマンドが受信されたときにはい
つでもアクセス制御手順４０４の実行を起動すべくデー
タベーストリガ４０２を用いる。アクセス制御手順４０
４は、ＤＢＭＳに記憶される管理情報へのアクセスを認
可または否認するかを決定すべく許可テーブル４０６を
用いる。トリガ機構は、ＤＢＭＳ２８０のデータベース
アクセスエンジン２８６の特徴でありそして特に、この
ＤＢＭＳ２８０は、ＳＱＬ選択コマンドがＤＢＭＳによ
って受け取られるときにはいつでもトリガ４０２を呼出
すべく構成されている。

【００７９】許可テーブル この第３の実施例では、特定の管理オブジェクト上の特
定のユーザに対するアクセス制御は、許可テーブル４０
６によって画定される。本発明は、access Grant table
（アクセス認可テーブル）４０８及びaccess Deny tabl
e （アクセス否認テーブル）４１０を有するのが好ま
し。 許可テーブルを生成する システム管理責任者３０２は、エンドユーザによるＤＢ
ＭＳ２８０の使用の前に許可テーブルを生成する。生成
許可手順４４２に対する呼出し４４０は、許可テーブル
を生成するために用いられる。“Create#Permissions#T
ables"procedure ４４２は、ＤＢＭＳ２８０に記憶され
る。システム管理責任者３０２は、ＤＢＭＳ２８０の
“Create#Permissions#Tables"procedure ４４２に対す
る呼出し４４０を呼出す。Create#Permissions#Tables
procedure ４４２は、アクセス制御ツリー１７０によっ
て定義されたユーザアクセス権利を許可テーブル用の適
当なフォーマットにマップする。また、図１５Ａ及び図
１５Ｂを参照すると、許可エントリ１５０２、１５０４
は、以下に示すように、３つのフィールドを有している
タプルである：

【００８０】（ユーザネーム、オブジェクトネーム、オ
ペレーション型）図１５Ａ及び図１５Ｂは、単一“word
（語）" として各許可エントリにおいてオブジェクトネ
ームを示すけれども、オブジェクトネームは、管理オブ
ジェクトに対するＦＤＮであるのが好ましい。ユーザネ
ームは、そのアクセス権利が許可エントリによって表わ
されるユーザ（又はユーザのグループ）の名前であり、
オブジェクトネームは、許可エントリが適用される管理
オブジェクトを識別し、オペレーション型は、特定のユ
ーザが特定のオブジェクトに関して認可されたか又は否
認されたオペレーションである。オペレーション型は、
選択、削除、挿入又は更新オペレーションでありうる。
二つの許可テーブルは、Ｘ．７４１アクセス規則が特定
される方法を反映する：Global grant（グローバル認
可）, Global grant with item deny （項目否認を伴う
グローバル認可）, Global deny with item grant （項
目認可を伴うグローバル否認）, 及びGlobal deny （グ
ローバル否認）。Grant table （許可テーブル）４０８
は、全てのaccess Grant permissions（アクセス認可許
可）のリストを記憶する。Deny table（否認テーブル）
４１０は、全てのaccess Deny permissions （アクセス
否認許可）のリストを記憶する。アクセスが特定のオペ
レーションに対して許可されるべきかどうかをチェック
する場合には、アクセス制御手順４０４は、両方のテー
ブルをチェックする。

【００８１】許可テーブルを実装する 許可テーブル４０６は、アクセス制御ツリー１７０のア
クセス制御規則２０６に対応すべく実装される。慣例と
して、許可テーブル４０６は、“all objects（全ての
オブジェクト）" を表わすべく、データベースＮＵＬＬ
値のような、特別なオブジェクトネームの値、及び“al
l operation types （全てのオペレーション型）" を
表わすべく、データベースＮＵＬＬ値のような、特別な
オペレーション型の値を用いる。許可テーブル４０６
は、次のように実装される： ・ アクセス制御データベースの規則がオペレーショ
ン型Op1 に対してユーザU1への“global grand" を特定
するならば、エントリは、（U1,NULL,Op1 ）である許可
テーブル４０８になされる。 ・ アクセス制御データベースの規則がオペレーショ
ン型Op1 に対して“項目X1,X2 及びX3に対する項目否認
を伴うユーザU1へのglobal grand" を特定するならば、
次のエントリは、許可テーブル４０８及び否認テーブル
４１０になされる。 ・ アクセス制御データベースの規則がオペレーショ
ン型Op1 に対して“項目X1,X2 及びX3を除く全ての項目
へのdeny user U1 access(否認ユーザU1アクセス)"を特
定するならば、次のエントリは、否認テーブル４１０及
び認可テーブル４０８になされる。 ・ 規則がオペレーション型Op1 に対してユーザU1へ
の“global deny"を言及するならば、次のエントリは、
否認テーブル４１０になされる： DENY TABLE: （U1,NULL,Op1 ） 上記の全てにおいて、異なるオペレーション型に対して
複数のエントリがなされうる。管理オブジェクト上のユ
ーザの許可が全てのオペレーション型に対して同じなら
ば、NULLオペレーション型を有する単一のエントリで十
分である。

【００８２】上述した方法は、明示的認可規則だけを記
憶すること又は明示的否認規則だけを記憶することより
もアクセス制御規則を記憶するためのより効率的な方法
である。例えば、認可規則だけを記憶するならば、５，
０００の管理オブジェクトを伴うシステムでは、単一項
目否認を伴うグローバル認可が与えられた新しいユーザ
は、Grant Table （許可テーブル）４０８において４，
９９９の記録を必要としうる。上述した方法を用いて、
新しいユーザは、二つだけのエントリを有するであろ
う：Grant Table （許可テーブル）に一つのエントリそ
してDeny table（否認テーブル）４１０に別のエント
リ。スコープ及びフィルタにより画定されるアクセス制
御ツリー１７０における規則は、エントリが認可テーブ
ル４０８及び否認テーブル４１０になされる前に評価さ
れる。例えば、管理オブジェクトテーブルのスコープ及
びフィルタが、残りが全体的に否認されると共に、アク
セスが許可されなければならない一組の１０の管理オブ
ジェクトを結果として生ずるならば、１０のエントリ
は、許可テーブル" 部r ４０８になされかつ単一の否認
エントリが否認テーブル４１０になされる。

【００８３】アクセス制御を強制する 許可テーブルに基づくAccess Control Rules（アクセス
制御規則）の強制は、オペレーションがユーザU1によっ
て要求されることを想定する、以下のアルゴリズムによ
り行われる。これらのステップは、その場合にはアルゴ
リズムが出る、いずれかの一つのステップにおいて認可
又は否認決定が到達しない限り、順番に行われる。 １． User U1 がグローバル否認（即ち、全てのオブ
ジェクトに対する否認）を有するかどうか調べるために
Deny table（否認テーブル）をチェックする。そうであ
れば、ユーザが特定の認可された項目（オブジェクト）
を有するかどうかを調べるべくGrant table （認可テー
ブル）をチェックする。そのようなオブジェクトが存在
するならば、現行オペレーションが Grant tableにおい
て特定されたオペレーションとマッチするならばアクセ
スを認可し、さもなければ、アクセスを否認する。 ２． User U1 がグローバル認可（即ち、全てのオブ
ジェクトに対する認可）を有するかどうか調べるために
Grant table （認可テーブル）をチェックする。そうで
あれば、ユーザが特定の否認された項目（オブジェク
ト）を有するかどうかを調べるべくDeny table（否認テ
ーブル）をチェックする。そのようなオブジェクトが存
在するならば、現行オペレーションがDeny tableにおい
て特定されたオペレーションとマッチするならばアクセ
スを否認し、さもなければ、アクセスを認可する。 ３． User U1 が特定の否認された項目（オブジェク
ト）を有するかどうかを調べるべくDeny table（否認テ
ーブル）をチェックし、かつ現行オペレーションがDeny
tableにおいて特定されたオペレーションとマッチする
ならばアクセスを否認する。 ４． User U1 が特定の認可された項目（オブジェク
ト）を有するかどうかを調べるべくGrant table （認可
テーブル）をチェックし、かつ現行オペレーションがGr
ant table において特定されたオペレーションとマッチ
するならばアクセスを認可する。 ５． 全- ユーザグローバル否認（即ち、全てのユー
ザに対して全てのオブジェクトを否認する）を有するか
どうか調べるためにDeny table（否認テーブル）をチェ
ックする。そうであれば、全てのユーザが否認に対する
除外である特定の認可された項目（オブジェクト）を有
するかどうかを調べるべくGrant table （認可テーブ
ル）をチェックする。そのようなオブジェクトが存在す
るならば、現行オペレーションがGrant table において
特定されたオペレーションとマッチするならばアクセス
を認可し、さもなければ、アクセスを否認する。 ６． 全- ユーザグローバル認可（即ち、全てのユー
ザに対して全てのオブジェクトを認可する）を有するか
どうか調べるためにGrant table （認可テーブル）をチ
ェックする。そうであれば、全てのユーザが認可に対す
る除外である特定の否認された項目（オブジェクト）を
有するかどうかを調べるべくDeny table（否認テーブ
ル）をチェックする。そのようなオブジェクトが存在す
るならば、現行オペレーションがDeny tableにおいて特
定されたオペレーションとマッチするならばアクセスを
否認し、さもなければ、アクセスを認可する。 ７． 全てのユーザが特定の否認項目（オブジェク
ト）を有するかどうかを調べるためにDeny table（否認
テーブル）をチェックする。そうであれば、現行オペレ
ーションがDeny tableにおいて特定されたオペレーショ
ンとマッチするならばアクセスを否認する。 ８． 全てのユーザが特定の認可項目（オブジェク
ト）を有するかどうかを調べるためにGrant table （認
可テーブル）をチェックする。現行オペレーションがGr
ant table において特定されたオペレーションとマッチ
するならばアクセスを認可する。 ９．上記のステップの後で認可／否認の決定に至らなか
ったならば、デフォルトAccess Control Rule （アクセ
ス制御規則）（デフォルト否認又はデフォルト認可）を
適用する。 ユーザが、ネットワークにおける全てのルータの状態に
対する要求又は管理オブジェクトの特定リストについて
の情報に対する要求のような、複数のオブジェクトへの
アクセスを要求する問合せを提出する場合には、アクセ
ス制御手順４０４は、全ての要求したオブジェクトに対
する適用可能なアクセス権利チェッキング方法を実行す
る。アクセスは、ユーザが適切なアクセス権利を有する
オブジェクトに対してだけ許可される。データベースの
他のオブジェクトに対するユーザへは、なんの情報も戻
されないので、ユーザは、あらゆるオブジェクトに対し
てアクセスが否認されたということを知らされない。こ
れは、重要である、なぜならばユーザは、その人の範囲
内ではないオブジェクトの存在さえも知らされてはなら
ないからである。また、ユーザは、ユーザがアクセスを
有さない問合せからオブジェクトを除外することについ
て考えなければならないことなく、特定の型の“all ob
jects （全てのオブジェクト）" についての情報を単に
要求できるべきである。

【００８４】問合せにおいて特定されたオブジェクトの
全てへのアクセスが否認された場合には、問合せは、ユ
ーザに詳細な説明を供給することなく否認される。アク
セスがあるオブジェクトに対して認可されるが他のオブ
ジェクトには認可されない場合には、アクセス制御手順
４０４は、ユーザの問合せをアクセスが認可されるオブ
ジェクト上で実行させることができる。特に、好ましい
実施例ではアクセス制御手順４０４は、それらのオブジ
ェクトに対してユーザ問合せを実行しかつユーザに結果
を戻す。その結果、データベースアクセスエンジンによ
る通常の問合せ処理は、回避されかつアクセス制御手順
４０４によって実行された（または起動された）処理に
よって置き換えられる。アクセス制御手順４０４によっ
てＤＢＭＳテーブルから読取られたデータは、問合せが
データベースアクセスエンジンによって処理された場合
にデータが戻されるのと同じ方法で要求しているユーザ
又は処理に戻される。

【００８５】例示的許可テーブル 図１５Ａ及び１５Ｂは、例示的Grant table （許可テー
ブル）及びDeny table（否認テーブル）をそれぞれ示
す。代替実施例では、許可テーブルは、ユーザのグルー
プによるアクセスを管理するためにユーザネームに加え
てグループネーム５１０を用いることができる。ユーザ
により許可テーブル直接アクセスを用いて直接アクセス
を制御する方法図１６Ａを参照すると、ステップ１６０
２及び１６０４は、アクセス制御サーバ及びその後続利
用の初期構成を表わし、かつ図１３Ａのステップ１３１
２及び１３１４と実質的に同じである。ステップ１６０
６、１６０８、１６１０及び１６１２は、アクセス制御
サーバによって強制されたものと調和するアクセス制限
を伴って、少なくともあるユーザに管理情報への直接ア
クセスを供給すべくＤＢＭＳを設定するための手順を表
わす。ステップ１６０６では、管理情報は、ネットワー
クからデータベース管理システムに送られる。換言する
と、ある一定の型の管理オブジェクトに対して、管理情
報は、複製されかつＤＢＭＳに記憶される。一般的に、
個々のＤＢＭＳテーブルは、（Ａ）ＤＢＭＳを介してア
クセス可能である各個別の型の管理オブジェクト、及び
（Ｂ）（上述したような）ログサーバにおいて画定され
た各個々のログファイルに対して設定される。

【００８６】ステップ１６０８は、情報転送モジュール
によって送られた管理情報をデータベース管理システム
の一組のデータベーステーブルに記憶する。テーブル
は、対応する管理オブジェクトに対して個別の行に管理
情報を記憶する。換言すると、ログテーブルを除いて、
ＤＢＭＳは、各管理オブジェクトに対する情報をその管
理オブジェクト型に対して設定されたテーブルの個々の
行に記憶する。ステップ１６１０では、許可オブジェク
トを含んでいる、少なくとも一つの許可テーブルが記憶
される。許可オブジェクトは、管理オブジェクトの特定
のセットへのユーザによるアクセス権利を特定する情報
を集合的に記憶し、特定のアクセス権利は、ネットワー
クから管理情報を取得するためのアクセス権利を含む。
許可オブジェクトによって特定されたアクセス権利は、
少なくとも一人のユーザに対するアクセス制御データベ
ースによって特定される管理オブジェクトアクセス権利
に対応する。

【００８７】ステップ１６１２は、ＤＢＭＳトリガのア
クション（動作）を表わし、それは、データベースの所
望のテーブルに記憶される管理オブジェクトに記憶され
る管理情報をアクセスするためのユーザアクセス要求を
インタセプトし、次いでアクセス制御手順４０４を呼出
す。ステップ１６１４は、一組のデータベーステーブル
に記憶された管理情報へのアクセスを制限する、アクセ
ス制御手順４０４の動作を表わす。アクセス制御手順
は、インタセプトされた問合せによって特定されたデー
タの、もしあれば、どの行がユーザによってアクセス可
能であるかを決定すべく許可テーブルに記憶される一組
のアクセス権利を用いる。ステップ１６１８では、アク
セス制御手順は、アクセスがユーザによって許可される
要求された行のサブセットに記憶された管理情報をアク
セスする。

【００８８】グループによる直接アクセス 許可テーブルがユーザのグループに対する権利を確立す
べく構成される場合、ＤＢＭＳは、ユーザネームをグル
ープネームにマップさせることができるグループテーブ
ル４７０を含むのが好ましい。ユーザのアクセス権利
は、次いで、ユーザがメンバーであるグループのアクセ
ス権利に従って決定される。 アクセス制御手順のオペレーション アクセス制御手順４０４は、二つの方法でデータベース
アクセスエンジン２８６と対話できる。これら二つの方
法の第１の方法は、図１６Ｂによって表わされ、第２の
方法は、図１６Ｃによって表わされる。図１６Ｂを参照
すると、トリガが検出されかつアクセス制御手順が呼出
された後、アクセス制御手順４０４は、上述した方法の
一つを用いて許可テーブルをチェックし（ステップ１６
６２）、かつ許可済み管理オブジェクトのリストを形成
する（ステップ１６６４）。いずれの管理オブジェクト
も許可されないならば、ナル(null)リストが形成され
る。ステップ１６６６は、ＳＱＬコマンドの実行を完了
すべくデータベースアクセスエンジン２８６に許可済み
管理オブジェクトのリストを戻す。また、アクセス制御
手順４０４は、ＳＱＬコマンドの実行が継続されるべき
か又は打ち切られるべきかを示すべくデータベースアク
セスエンジン２８６にリターンコードを供給する。リタ
ーンコードの値がＳＱＬコマンドの実行が継続されるべ
きであるということを示すならば、データベースアクセ
スエンジンは、戻されたリストによって特定されたテー
ブル行をアクセスしかつ合成情報をユーザに戻す。リタ
ーンコードの値がＳＱＬコマンドの実行を打ち切るべき
であるということを示すならば、データベースアクセス
エンジン２８６は、ユーザにナル結果を戻す。

【００８９】図１６Ｃを参照すると、第2 の方法の最初
の二つのステップ（１６７２及び１６７４）は、第1 の
方法の最初の二つのステップ（１６６２及び１６６４）
と同じである。しかしながら、第2 の方法では、アクセ
ス制御手順４０４は、許可済み管理オブジェクトの先に
形成されたリストによって特定された、テーブル行を、
もしあれば、直接的にアクセスし（ステップ１６７
６）、そして、受け取ったＳＱＬコマンドの処理が完了
するまでデータベースアクセスエンジンに制御を戻すこ
となく、合成情報をユーザに戻す（ステップ１６７
８）。

【００９０】許可テーブルを更新すること 図１６Ｄは、許可テーブルが更新される場合を示してい
るフローチャートである。管理オブジェクトは、生成、
削除できるか、またはそれらの属性値を変更できる。こ
れらの変更は、アクセス制御規則の定義により、管理オ
ブジェクトのアクセス制御許可に影響を与えうる。この
第3 の実施例では、アクセス制御構成手順２１０は、Ｄ
ＢＭＳにupdate#permissions#tables ４５２手順を実行
させるupdate#permissions#tables ４５２手順に対して
呼出し４５０を発行する。許可テーブルは、管理オブジ
ェクトに何の変化が生ずるかにより更新される。許可テ
ーブルは、管理オブジェクトが削除され（１７０２）、
新しい管理オブジェクトが追加され（１７０４）、属性
値が変更され（１７０６）、ユーザが削除され（１７０
８）、新しいユーザが追加され（１７１０）、新しい規
則が追加され（１７１２）、規則が削除され（１７１
４）、規則が変更され（１７１６）、グループが追加さ
れ（１７１８）、かつグループが削除される（１７２
０）場合にupdate#permissions#tables 手順を呼出すこ
とによって更新される。

【００９１】管理オブジェクトが削除されたならば、ス
テップ１７２２では、update#permissions#tables ４５
２手順は、許可テーブル４０６からその管理オブジェク
トネームを有している全ての記録を削除する。管理オブ
ジェクトが生成されたならば、ステップ１７２２では、
update#permissions#tables ４５２手順は、どのユーザ
が管理オブジェクトをアクセスしうるかを決定すべく全
てのアクセス制御規則をチェックし、かつ適切なエント
リが許可テーブルになされる。管理オブジェクトがその
属性値が変更されたならば、ステップ１７２２では、up
date#permissions#tables ４５２手順は、どのユーザが
管理オブジェクトをアクセスできるかを決定すべく全て
のアクセス制御規則をチェックする。いずれかのアクセ
ス制御規則が変更された属性の値に依存するならば、適
切なエントリが許可テーブル４０６になされる（及び/
又はリバイズされる）。

【００９２】ユーザが削除されたならば（即ち、アクセ
ス制御エンジンによって認識された一組のユーザから取
り除かれた）、ステップ１７２２では、update#permiss
ions#tables ４５２手順は、許可テーブル４０６からそ
のユーザネームを有する全ての記録を削除する。新しい
ユーザが追加されかつ特定のアクセス制御規則が新しい
ユーザに対して画定されないならば、ステップ１７２２
では、update#permissions#tables ４５２手順は、デフ
ォルトアクセス制御規則を新しいユーザに適用しかつ許
可テーブルを更新する。特定のアクセス制御規則が新し
いユーザに対して画定されるならば、update#permissio
ns#tables ４５２手順は、特定のアクセス制御規則を適
用する。許可テーブルは、それに従って更新される。

【００９３】グループが検出されたならば、ステップ１
７２２では、update#permissions#tables ４５２手順
は、許可テーブル４０６からそのグループネームを有す
る全ての記録を削除する。新しいグループが追加される
ならば、ステップ１７２２では、update#permissions#t
ables ４５２手順は、特定のアクセス制御規則が新しい
グループに対して画定されるかどうかを決定する。そう
でなければ、update#permissions#tables４５２手順
は、デフォルトアクセス制御規則を新しいグループに適
用しかつ許可テーブルを更新する。そうであれば、upda
te#permissions#tables ４５２手順は、特定のアクセス
制御規則を適用する。許可テーブルは、それに従って更
新される。 メモリ 図１２Ａ及び図１２Ｂを再び参照すると、アクセス制御
サーバ及びＤＢＭＳのメモリは、直接アクセスファシリ
ティの第３の実施例を支援すべく更なるデータ及び手順
を記憶する。図１２Ａに示すように、この第３の実施例
に対してアクセス制御サーバ３３０のメモリに記憶され
る追加の手順は、 ・ Create#Permissions#Tables４４０に対する呼出
し； ・ Update#Permissions#Tables４５０に対する呼出
し；及び ・ Create#Group#Table ４７２に対する呼出し を含む。

【００９４】図１２Ｂに示すように、この第３の実施例
に対してＤＢＭＳ２８０のメモリに記憶される追加デー
タ及び手順は、 ・ コマンドインタセプタ４９０（以下に説明）； ・ グループテーブル４７０； ・ トリガ４０２； ・ アクセス制御手順４０４； ・ 許可テーブル４０８及び否認テーブル４１０を含
む許可テーブル４０６； ・ Create#Permissions#Tables ４４２手順; ・ Update#Permissions#Tables ４５２手順；及び ・ Create#group#table４７４手順（以下に説明） を含む。

【００９５】拡張 また、第３の実施例は、ユーザがグループに属しかつア
クセス制御がユーザのグループに対して画定されるよう
なユーザのグループに適用することもできる。許可テー
ブルでは、“user name(ユーザネーム)"は、“group na
me（グループネーム）" によって置き換えられかつ許可
テーブルは、ユーザのグループに対するエントリを含
む。許可は、グループに対してだけ画定されうるか、ま
たはグループと個々のユーザの組合せに対して画定され
うる。

【００９６】グループテーブル４７０は、ユーザネーム
をグループネームにマップし、アクセス制御手順４０４
は、どのグループにユーザが属するかを決定すべくグル
ープテーブルをチェックし、そして上述した方法に従っ
て許可テーブルの全てのそのようなグループに対する許
可をチェックする。アクセス制御サーバのメモリは、Ｄ
ＢＭＳのcreate#group#table４７４手順に対する呼出し
４７２（図１２Ａ参照）を含む。システム管理責任者３
０２は、上述した許可テーブルに類似する方法でグルー
プテーブルを生成する。別の実施例では、アクセス制御
手順４０４は、アプリケーションの特定のポリシーに基
づいてそのユーザへのアクセスを認可又は否認する。例
えば、ポリシーが“most restrictive( 最も限定され
た)"であれば、特定のオブジェクトへのアクセスは、ユ
ーザのグループのいずれかのものがそのオブジェクトへ
のアクセスを否認されたならば、ユーザに対して否認さ
れる。ポリシーが“least restrictive （ほとんど限定
されていない）" であれば、ユーザのグループのいずれ
かのものがそのオブジェクトへのアクセスを認可された
ならば、オブジェクトへのアクセスは、ユーザに認可さ
れる。

【００９７】代替実施例では、トリガに対して同等の機
構は、アクセスを制御するために全てのユーザ問合せを
インタセプトしかつ記憶された手順を呼出すべくＳＵＮ
ＳｏｌｓｔｉｃｅＥｎｔｅｒｐｒｉｓｅマネージャのem
#sqlのようなアクセス制御アプリケーションレイヤーを
挿入することによって供給される。図１４では、コマン
ドインタセプタ４９０は、ユーザ要求３００をインタセ
プトしかつアクセス制御手順４０４を実行するかどうか
を決定する。代替的に、コマンドインタセプタ４９０
は、ＳＱＬＳＥＬＥＣＴコマンドが検出された場合にア
クセス制御手順４０４を呼出す。第２及び第３の実施例
ではビュー及び許可テーブルは、全てのユーザに対して
またはユーザの指定されたサブセットに対してのいずれ
かに生成されうる。

【００９８】また、本発明の第２及び第３の実施例は、
“guaranteed commit （保証された完遂）" 特徴を有し
ているシステムでの使用にも適する。そのようなシステ
ムは、既存の管理オブジェクトのあるもの又は全てに対
するシャドウオブジェクトを伴うシャドウデータベース
を有しうる。シャドウデータベースでは、管理オブジェ
クトが利用不可能であれば、シャドウオブジェクトが管
理オブジェクトに対する変更を受け入れる。シャドウオ
ブジェクトは、管理オブジェクトをポーリングしかつ管
理オブジェクトが利用可能にあった場合に管理オブジェ
クトに対する変更をプッシュする。シャドウデータベー
スは、本発明のＤＢＭＳ２８０のデータベーステーブル
３１０、３２０に記憶されるべき事象及びメッセージ情
報を送ることができる。本発明は、２〜３の特定な実施
例を参照して記述されたが、記述は、本発明の説明のた
めであり本発明を限定することを企図していない。添付
した特許請求の範囲によって定義される本発明の真の精
神及び範疇から逸脱することなく種々の変更が当業者に
よって生起されうる。

【図面の簡単な説明】

【図１】図１は、ネットワークにおける管理オブジェク
トへのアクセスを制限するためのアクセス制御エンジン
のブロック図である。

【図２】図２は、アクセス要求のデータ構造を示す図で
ある。

【図３】本発明の好ましい実施例による分散アクセス制
御エンジン（ＡＣＥ）を示す図である。

【図４】アクセス制御データベース、及びデータベース
にオブジェクトを追加しかつデータベースに既に存在す
るオブジェクトを変更する機構を示す図である。

【図５】各アクセス要求を処理するためにアクセス規則
が適用される順番を示す図である。

【図６】アクセス要求を処理し、それをリスポンシブル
アクセスサービス間に分割し、応答を照合しかつ組合せ
た応答をイニシエータに戻すための手順を示す図であ
る。

【図７】アクセス要求のターゲットが二つ以上の管理オ
ブジェクトを含むときにアクセス要求応答が組合される
方法をテーブルわすためのチャートを示す図である。

【図８】本発明の好ましい実施例における管理情報サー
バの事象レジストリ及び事象ルータ部分を示す図であ
る。

【図９】管理オブジェクトによって生成された事象通知
に関する、ログ記録へのＳＱＬ型読取り専用アクセスを
供給すると共に、ネットワークに対して管理情報サーバ
によって供給されたものと同じセキュリティ制限を管理
オブジェクト情報へのアクセスに対して維持するための
補足アクセス機構を示す図である。

【図１０】管理オブジェクトに関する情報を記憶してい
る一組のデータベーステーブルへのＳＱＬ型読取り専用
アクセスを供給すると共に、ネットワークに対して管理
情報サーバによって供給されたものと同じセキュリティ
制限を管理オブジェクト情報へのアクセスに対して維持
するための補足アクセス機構の第２の実施例のブロック
図である。

【図１１Ａ】管理オブジェクトの完全識別ネーム（ＦＤ
Ｎ）を用いている好ましい行フォーマットを示す。

【図１１Ｂ】view#tablename#username のフォーマット
を伴うビューネーム(viewname)を有しているユーザ要求
を示す図である。

【図１１Ｃ】明示ビュー：ユーザネーム、テーブルネー
ム及び許可リストを生成するために用いられるパラメー
タを示す図である。

【図１１Ｄ】暗示ビュー：ユーザネーム、テーブルネー
ム及びＳＱＬ許可規則を生成するために用いられるパラ
メータを示す図である

【図１２Ａ】この第２実施例及び第３実施例に対するア
クセス制御サーバのメモリに記憶される既存及び追加情
報を示す図である。

【図１２Ｂ】この第２実施例及び第３実施例に対するＤ
ＢＭＳのメモリに記憶される既存及び追加情報を示す図
である。

【図１３Ａ】ユーザに対して管理オブジェクトへの直接
ユーザアクセスを制御するための方法を示す図である。

【図１３Ｂ】ビューが更新される場合を示しているフロ
ーチャートである。

【図１４】アクセス制御手順へ選択照会の処理を再指向
するためにトリガを用いる直接情報アクセスシステムの
第３の実施例のブロック図である。

【図１５Ａ】タプルによってテーブルわされるフィール
ドの組合せとして許可エントリを示す図である。

【図１５Ｂ】タプルによってテーブルわされるフィール
ドの組合せとして許可エントリを示す図である。

【図１６Ａ】ＤＢＭＳに記憶される管理情報へのユーザ
アクセスを制御するための方法を示す図である。

【図１６Ｂ】トリガが検出された後のアクセス制御手順
に対するオペレーションの第１の方法を示す図である。

【図１６Ｃ】トリガが検出された後のアクセス制御手順
に対するオペレーションの第２の方法を示す図である。

【図１６Ｄ】許可テーブルが更新される場合を示してい
るフローチャートである。

───────────────────────────────────────────────────── フロントページの続き (71)出願人 591064003 901 ＳＡＮ ＡＮＴＯＮＩＯ ＲＯＡＤ ＰＡＬＯ ＡＬＴＯ，ＣＡ 94303，Ｕ. Ｓ．Ａ. (72)発明者 バート リー フィッシャー アメリカ合衆国 カリフォルニア州 94086 サニーヴェイル サウス フェア オークス アベニュー 655 アパート メント エイチ209 (72)発明者 ラジーヴ アンガル アメリカ合衆国 カリフォルニア州 95051 サンタ クララ プルーンリッジ アベニュー 3655−１ (72)発明者 サイ ヴィー エス アーラヴァルプ アメリカ合衆国 カリフォルニア州 94566 プレザントン セント ジョン サークル 755 (72)発明者 スボド バパト アメリカ合衆国 カリフォルニア州 94303 パロ アルト ヒルバー レーン 546

Claims (15)

【特許請求の範囲】
1. 【請求項１】 分散型ネットワークの管理オブジェクト
   へのアクセスを制御するアクセス制御システムであっ
   て、 アクセス制御オブジェクトが管理オブジェクトの特定の
   セットに対するユーザによるアクセス権利を特定する情
   報を集合的に記憶し、該特定されたアクセス権利が該ネ
   ットワークから管理情報を取得するためのアクセス権利
   を含む、該アクセス制御オブジェクトを含んでいるアク
   セス制御データベースと、 前記アクセス制御データベースによって特定された前記
   アクセス権利に従って前記管理オブジェクトへのアクセ
   スをユーザに供給する少なくとも一つのアクセス制御サ
   ーバと、 データベース管理システムと、 前記ネットワークから前記データベース管理システムに
   管理情報を送る情報転送機構とを備えており、 前記データベース管理システムは、 前記情報転送機構によって送られた前記管理情報を一組
   のデータベーステーブルに記憶するデータベーステーブ
   ル；アクセス制御データベースに記憶された前記アクセ
   ス権利の少なくともサブセットに対応しているテーブル
   アクセス権利を確立するデータベースアクセス特権モジ
   ュール；及び前記データベーステーブルに記憶された管
   理情報に対するユーザ要求を受け取り、かつ前記データ
   ベースアクセス特権モジュールによって確立された前記
   テーブルアクセス権利に従って前記データベーステーブ
   ルに記憶された管理情報へのユーザアクセスを制限する
   データベースアクセスエンジンを含むことを特徴とする
   アクセス制御システム。
2. 【請求項２】 前記一組のデータベーステーブルの各テ
   ーブルは、対応する管理オブジェクトに対する管理情報
   を個々の行に記憶し；前記データベースアクセス特権モ
   ジュールは、前記一組のデータベーステーブルに記憶さ
   れる前記管理情報へのアクセスを制限するための一組の
   ビューを生成し、前記一組における各ビューは、このビ
   ューを用いるときにアクセス可能である前記データベー
   ステーブルの少なくとも一つにおける行のサブセットを
   画定し、前記組における各ビューを用いるときにアクセ
   ス可能である前記データベーステーブル行の一組は、前
   記ユーザの少なくとも一つに対する前記アクセス制御デ
   ータベースによって特定された前記管理オブジェクトア
   クセス権利に対応し；前記データベースアクセス特権モ
   ジュールは、前記一組のビューのどのビューが前記ユー
   ザの特定のものによって使用可能であるかを特定し；か
   つ前記データベースアクセスエンジンは、各ユーザが当
   該ユーザがアクセスすることを前記アクセス制御データ
   ベースによって許可されるであろう前記一組のデータベ
   ーステーブルの管理情報へのアクセスだけを許可される
   ように前記一組のビューを用いて前記一組のデータベー
   ステーブルの情報をアクセスすることを特徴とする請求
   項１に記載のシステム。
3. 【請求項３】 前記データベースアクセス特権モジュー
   ルは、前記特定の組のユーザの特定のユーザがアクセス
   することを許可される各行への明示的参照を生成するこ
   とによって少なくとも一つのビューを発生することを特
   徴とする請求項２に記載のシステム。
4. 【請求項４】 前記アクセス制御データベースは、グル
   ープにユーザをグループ分けするための手段を供給し、
   該グループは、複数のユーザを有するように構成されて
   おり、該アクセス制御データベースは、グループによる
   アクセス権利を特定し、かつ前記データベース管理シス
   テムは、 前記一組のデータベース評に記憶される管理情報へのア
   クセスを制限するための一組のグループビューを更に含
   み、該組の各ビューは、このビューを使用するときにア
   クセス可能である前記データベーステーブルの少なくと
   も一つにおける行のサブセットを画定し、前記組の各ビ
   ューを使用するときにアクセス可能である前記一組のデ
   ータベーステーブル行は、前記グループの少なくとも一
   つに対してアクセス制御データベースによって特定され
   る前記管理オブジェクトアクセス権利に対応し、 前記データベースアクセス特権モジュールは、前記ビュ
   ーの組のどのビューが前記グループの特定のものによっ
   て使用可能であるかを特定し、かつ 前記一組のグループを用いて前記一組のデータベーステ
   ーブルにおける情報をアクセスするためのデータベース
   アクセスエンジンは、特定のグループに属している特定
   のユーザが、特定のグループがアクセス制御データベー
   スによってアクセスすることを許可されるであろう一組
   のデータベーステーブルの管理情報へのアクセスだけを
   許されるように、ビューすることを特徴とする請求項２
   に記載のシステム。
5. 【請求項５】 前記データベース管理システムにアクセ
   ス権利情報を送るためのオブジェクトを含んでおり、該
   送られたアクセス権利情報は、前記アクセス制御オブジ
   ェクトによって特定されたアクセス権利に対応してお
   り、 前記データベースアクセス特権モジュールは、前記オブ
   ジェクトによって送られた前記アクセス権利情報に従っ
   て前記アクセス権利を確立することを特徴とする請求項
   １に記載のアクセス制御システム。
6. 【請求項６】 前記データベース管理システムにアクセ
   ス権利情報を送るための少なくとも一つのオブジェクト
   を含んでおり、 前記少なくとも一つのオブジェクトは、前記アクセス制
   御オブジェクトの生成及び削除並びに前記アクセス制御
   オブジェクトに対する属性変化に対応している事象通知
   メッセージを前記事象ルータから受け取り、該受け取っ
   た事象通知メッセージをアクセス権利更新メッセージに
   変換し、かつアクセス権利更新メッセージを前記データ
   ベース管理システムに送り、 前記データベースアクセス特権モジュールは、前記少な
   くとも一つのオブジェクトによって送られた前記アクセ
   ス権利更新メッセージに従って前記確立されたテーブル
   アクセス権利を更新することを特徴とする請求項１に記
   載のアクセス制御システム。
7. 【請求項７】 前記アクセス制御オブジェクトは、 それぞれがグループ及び該グループのメンバーである一
   組のユーザを画定する、グループオブジェクト；及びそ
   れぞれが、一組のグループオブジェクト、一組の管理オ
   ブジェクト、及び前記特定の一組の管理オブジェクトへ
   の前記特定の一組のグループオブジェクトによって画定
   された前記グループのメンバーである前記ユーザによる
   アクセス権利を特定する、規則オブジェクトの第１のサ
   ブセット、及びそれぞれが、一組のグループオブジェク
   ト、一組の管理オブジェクト、及び前記特定の一組の管
   理オブジェクトによって生成される事象通知への前記特
   定の一組のグループオブジェクトによって画定されたグ
   ループのメンバーであるユーザによるアクセス権利を特
   定する、前記アクセス制御データベースにおける規則オ
   ブジェクトの第２のサブセットからなる規則オブジェク
   トとを含んでおり；前記システムは、前記管理オブジェ
   クトによって生成された事象通知を受け取りかつ前記ア
   クセス制御データベースで特定されたアクセス権利に従
   って対応する事象通知メッセージをそれらの事象通知へ
   のアクセス権利を有するグループのユーザにだけ送る事
   象ルータを含み；前記少なくとも一つのアクセス制御サ
   ーバは、ユーザからアクセス要求を受け取りかつ前記ア
   クセス制御データベースにおいて特定されたアクセス権
   利に従って前記管理オブジェクトへのアクセスを制御
   し；前記アクセス要求のサブセットは、前記特定された
   一組の管理オブジェクトで実行されるべきオペレーショ
   ンを特定し；前記少なくとも一つのアクセス制御サーバ
   は、前記アクセス制御データベースにおいて特定された
   前記アクセス権利に従って各アクセス要求を認可し、否
   認しかつ部分的に認可しかつ否認することによって前記
   ユーザからの前記アクセス要求に応答し；かつ前記事象
   ルータは、前記管理オブジェクトによって生成された前
   記事象通知の少なくともサブセットを前記データベース
   管理システムに送る手段を含み；前記データベーステー
   ブルは、一組のデータベーステーブルに前記事象ルータ
   によって送られた前記事象通知を記憶するためのテーブ
   ルを含み；前記データベースアクセス特権モジュール
   は、前記規則オブジェクトの第２のサブセットによって
   テーブルわされる前記アクセス権利の少なくともサブセ
   ットに対応しているテーブルアクセス権利を確立し；か
   つ前記データベーステーブルに記憶される事象通知情報
   に対するユーザ要求を受け取り、かつ前記データベース
   アクセス特権モジュールによって確立された前記テーブ
   ルアクセス権利に従って前記データベーステーブルに記
   憶される事象通知情報へのユーザアクセスを制限するた
   めのデータベースアクセスエンジンを含んでいることを
   特徴とする請求項１に記載のアクセス制御システム。
8. 【請求項８】 分散型ネットワークの管理オブジェクト
   へのアクセスを制御する方法であって、 アクセス制御オブジェクトが管理オブジェクトの特定の
   セットに対するユーザによるアクセス権利を特定する情
   報を集合的に記憶し、該特定されたアクセス権利が該ネ
   ットワークから管理情報を取得するためのアクセス権利
   を含む、該アクセス制御オブジェクトを含んでいるアク
   セス制御データベースを記憶し、 アクセス要求のサブセットが特定の組の管理オブジェク
   ト上で実行されるべきオペレーションを特定する、該ア
   クセス要求を前記ユーザから受け取り、かつ前記アクセ
   ス制御データベースで特定されたアクセス権利に従って
   各アクセス要求を認可及び否認し並びに部分的に認可及
   び否認することによって受け取ったアクセス要求を処理
   し、 前記ネットワークからデータベース管理システムに管理
   情報を送る段階を具備し、 前記データベース管理システムでは、 前記情報転送機構によって送られた前記管理情報を一組
   のデータベーステーブルに記憶し；アクセス制御データ
   ベースに記憶される前記アクセス権利の少なくともサブ
   セットに対応しているテーブルアクセス権利を確立し；
   かつ前記データベーステーブルに記憶される管理情報に
   対するユーザ要求を受け取り、かつ前記確立されたテー
   ブルアクセス権利に従って前記データベーステーブルに
   記憶される前記管理情報へのユーザアクセスを制限する
   段階を具備することを特徴とする方法。
9. 【請求項９】 前記データベース管理システムにおい
   て、 前記記憶する段階は、対応する管理オブジェクトに対し
   て前記テーブル管理情報を個々の行に記憶することを含
   み；前記一組のデータベーステーブルに記憶される前記
   管理情報へのアクセスを制限するために一組のビューを
   記憶し、該一組の各ビューは、このビューを用いるとき
   にアクセス可能である前記データベーステーブルの少な
   くとも一つにおける行のサブセットを画定し、前記組の
   各ビューを用いるときにアクセス可能である該一組のデ
   ータベーステーブル行は、少なくとも一人のユーザに対
   して前記アクセス制御データベースによって特定される
   前記管理オブジェクトアクセス権利に対応し；前記一組
   のビューのどのビューが前記ユーザの特定されらものに
   よって使用可能であるかを特定し；かつ各ユーザは、該
   ユーザがアクセスすることを該アクセス制御データベー
   スによって許可されるであろう前記一組のデータベース
   テーブルの管理情報へのアクセスだけが許可されるよう
   に前記一組のビューを用いて前記一組のデータベーステ
   ーブルの情報をアクセスすることを含むことを特徴とす
   る請求項８に記載の方法。
10. 【請求項１０】 特定された組のユーザ及び特定された
    組のデータベーステーブルに対して前記一組のビューを
    生成する段階を更に具備し、前記一組のビューの少なく
    ともサブセットのビューは、固有のユーザ−テーブルペ
    アリングに対応することを特徴とする請求項９に記載の
    アクセス制御方法。
11. 【請求項１１】 前記一組のビューを生成する段階は、
    前記特定された組のユーザの特定のユーザがアクセスす
    ることを許可される各行への明示参照を生成することに
    よって少なくとも一つのビューを生成することを特徴と
    する請求項９に記載のアクセス制御方法。
12. 【請求項１２】 ユーザをグループにグループ分けし；
    前記グループのアクセス権利を特定し；かつ前記一組の
    データベーステーブルに記憶される前記管理情報へのア
    クセスを一組のビューを用いて制限し、前記一組の各ビ
    ューは、このビューを用いるときにアクセス可能である
    データベーステーブルの少なくとも一つにおける行のサ
    ブセットを画定し、前記組の各ビューを用いるときにア
    クセス可能である前記一組のデータベーステーブル行
    は、前記グループの少なくとも一つに対して前記アクセ
    ス制御データベースによって特定される管理オブジェク
    トアクセス権利に対応し、 前記一組のビューのどのビューが前記グループの特定さ
    れたものによって使用可能であるかを特定し、かつ特定
    のグループの特定のユーザは、前記特定のグループがア
    クセスすることを前記アクセス制御データベースによっ
    て許可されるであろう前記一組のデータベーステーブル
    の管理情報へのアクセスだけが許可されるように前記一
    組のビューを用いて前記一組のデータベーステーブルの
    情報をアクセスする段階を更に具備することを特徴とす
    る請求項１０に記載のアクセス制御システム。
13. 【請求項１３】 アクセス権利情報を前記データベース
    管理システムに送り、該送られたアクセス権利情報は、
    前記アクセス制御オブジェクトによって特定されたアク
    セス権利に対応し、かつ前記データベース管理システム
    に送られたアクセス権利情報に従って前記テーブルアク
    セス権利を確立することを含む請求項１２に記載のアク
    セス制御方法。
14. 【請求項１４】 前記アクセス制御オブジェクトの生成
    及び削除及び前記アクセス制御オブジェクトに対する属
    性変更に対応している事象通知メッセージを受け取り、
    前記受け取った事象通知メッセージをアクセス権利更新
    メッセージに変換し、かつ該アクセス権利更新メッセー
    ジを前記データベース管理システムに送ることによって
    前記データベース管理システムにアクセス権利情報を送
    ることを含み；前記テーブルアクセス権利を確立する段
    階は、前記データベース管理システムに送られた前記ア
    クセス権利更新メッセージに従って前記確立されたテー
    ブルアクセス権利情報を更新することを含むことを特徴
    とする請求項８に記載のアクセス制御方法。
15. 【請求項１５】 前記記憶されたアクセス制御オブジェ
    クトは、 それぞれがグループ及び該グループのメンバーである一
    組のユーザを画定する、グループオブジェクト；及びそ
    れぞれが、一組のグループオブジェクト、一組の管理オ
    ブジェクト、及び前記特定の一組の管理オブジェクトへ
    の前記特定の一組のグループオブジェクトによって画定
    された前記グループのメンバーである前記ユーザによる
    アクセス権利を特定する、規則オブジェクトの第１のサ
    ブセット、及びそれぞれが、一組のグループオブジェク
    ト、一組の管理オブジェクト、及び前記特定の一組の管
    理オブジェクトによって生成される事象通知への前記特
    定の一組のグループオブジェクトによって画定されたグ
    ループのメンバーであるユーザによるアクセス権利を特
    定する、前記アクセス制御データベースにおける規則オ
    ブジェクトの第２のサブセットからなる規則オブジェク
    トとを含んでおり；前記管理オブジェクトによって生成
    された事象通知を受け取りかつ前記アクセス制御データ
    ベースで特定されたアクセス権利に従って対応する事象
    通知メッセージをそれらの事象通知へのアクセス権利を
    有するグループのユーザにだけ送り；かつ前記管理オブ
    ジェクトによって生成された前記事象通知の少なくとも
    サブセットを前記データベース管理システムに送り；前
    記データベース管理システムでは：前記データベーステ
    ーブルに前記事象ルータによって送られた前記事象通知
    を記憶し；前記規則オブジェクトの前記第２のサブセッ
    トによってテーブルわされる前記アクセス権利の少なく
    ともサブセットに対応するように前記テーブルアクセス
    権利を確立し；前記データベーステーブルに記憶される
    事象通知情報に対するユーザ要求を受け取り；かつ前記
    データベースアクセス特権モジュールによって確立され
    た前記テーブルアクセス権利に従って前記データベース
    テーブルに記憶される前記事象通知情報へのユーザアク
    セスを制限することを特徴とする請求項８に記載のアク
    セス制御方法。