JP2004094958A - データ管理システム、データベースアクセス方法及びセキュリティ機構 - Google Patents

Abstract

【課題】　ネットワークに接続されたデータベースを複数の組織のユーザで共用するにあたり、自分の組織のデータのみにアクセスでき、他の組織のデータへのアクセスが拒否できるようにする。
【解決手段】　複数のデータライブラリを格納するデータベース、データベースにあるデータライブラリのデータの蓄積を制御し、複数の外部組織による当該データへのアクセス許可を下すインタフェースを持つデータ管理システムであり、各組織に１人又はそれ以上のそれぞれのメンバが参加し、しかも組織のメンバのアクセスを制御するセキュリティ機構を含むインタフェースとする。
【選択図】図１

Description

　本発明は、データ管理システム、そのデータ管理システムの一部として組織が共通データベースにアクセスするデータベースアクセス方法、及び当該データ管理システムとデータベースアクセス方法を実施するセキュリティ機構に関する。

　１つの組織のコンピュータシステム内で、中央のデータベースを例えばサーバ上に設け、その組織のメンバがアクセスできるようにすることは周知である。そのデータベース内の各種データファイルに対するメンバのアクセスを制御するセキュリティ機構も周知である。特に、データファイルは各メンバに所有されているものであり、それらのデータファイルに関する特定の権利が各メンバに付与される。同様に、それぞれのデータファイルに関し、例えば読む、書く、編集する等といったその許可の中で定義された機能をメンバが実行できるように定義され、それらの許可が付与される。例えばユーザＩＤ及びユーザパスワードを管理する等の他の機能は、管理権を有する特定のメンバのみに限定される。これらのメンバは、データベースの如何なる部分にもアクセスでき、また変更できる完全な自由を有することになる。

　ＷＯ０１／７７８６３に記載の発明のように、多数の異なる組織がアクセスできるマルチメディア素材の外部データベースを提供することは周知である。そのデータベースを使用する権限の与えられた組織は、マルチメディア素材の全てを見ることができ、システムに組み込まれた手順規則に従って許可されたマルチメディア素材のコピーが取得できる。

ＷＯ０１／７７８６３

　本発明は、例えばマルチメディア素材を格納する外部データベースの提供が必要であるという認識に基づいてなされたものであり、それにより、同じデータを異なる関係者が使用し、作業することを可能とする。本発明は、更に同一のデータベース上において、異なる組織が有するデータを提供することによる問題点を認識している。特にある組織は他の組織が自分達のデータを見るのを好まないし、更に自分達のデータがデータベースにあること自体、さらには自分達がデータベースを使用していること自体を知られたくない場合がある。

　あるメンバに対して特定のファイルを見ることを許可しないとしても、それらのメンバには、ファイルが存在していることが依然として分かっている、それぞれの組織内部で以前より使用していた既存のシステムは不適切である。確かにもっと重要なことは、管理権を有するメンバはいつでも如何なるファイルでも見ることができることである。本発明の目的は、これらの問題を防ぎ、あるいは少なくとも解消させることにある。

　本発明によれば、メディア管理システムのようなデータ管理システムが設けられ、これには次のものを含む。すなわち、データ管理システムは、複数のデータライブラリを格納するデータベースと、データベースのデータライブラリにあるデータの蓄積を制御し、複数の外部組織にそのデータへのアクセスを許可するインタフェースを含み、各組織には１人かそれ以上の各メンバがおり、しかもこのインタフェースは、その組織のメンバによるデータへのアクセスを管理するセキュリティ機構を含む。

　本発明によれば、複数のデータライブラリを有する共通データベースへのアクセスを複数の外部組織に提供する方法が設けられ、各組織には、１人かそれ以上の各メンバがおり、前記方法は組織のメンバによるそのデータライブラリへのアクセスを管理するセキュリティ機構を含む。

　更に本発明によれば、複数のデータライブラリを蓄積するデータベースに使用されるセキュリティ機構が提供される。このセキュリティ機構は、異なる外部組織とデータライブラリのデータ間にインタフェースが設置され、各組織には１人かそれ以上の各メンバがおり、セキュリティ機構は異なる組織のメンバがデータライブラリにアクセスするのを制御する。

　このように、各組織内の各メンバの権利とは関係なく、セキュリティ機構は複数の異なる外部組織に対し同じデータベースの使用を許可するが、メンバ全てのアクセスを制御している。このようなセキュリティ機構を提供することにより、特定のデータファイルのデータについて異なる組織とそのメンバ達が共同作業を行える共通データベースの提供が可能となる一方、他の組織はそれらのデータファイルが存在すること、あるいは前記組織がデータベースで作業を行っていることすら知るに十分なアクセスができないようになし得る。１つ以上の組織のメンバが同じデータへのアクセスを有している場合でもこのセキュリティ機構によれば、そのうちの何人かのメンバに、低いレベルの操作、例えば他のメンバと比較して見るだけの操作が許されるようにすることができる。

　組織が、データベースに対する外部接続をも含めて、それぞれのデータ蓄積／通信システムを通常操作することが提供される。すなわちこのセキュリティ機構は、共通データベースを持った異なる組織のシステム間を結ぶインタフェースを可能にする。このセキュリティ機構の制御により、データベースのデータは複数の異なる組織からのアクセス及び操作が可能となる。

　データ蓄積／通信システムは各システムに関する各管理権を含む。このセキュリティ機構により全組織の各メンバの権利は、各データ蓄積／通信システムとは全く別に決定される。したがって、１つの組織のメンバは、異なる組織が有するデータライブラリのデータに関する権利を持つ必要はない。好ましくは、メンバのデータへのアクセスは、少なくとも、データの読出、書込及び編集を含む。かくして、各メンバに対しこのセキュリティ機構は、特定のデータライブラリからのデータの読出、書込、編集を制御する。さらにセキュリティ機構が、データライブラリのデータの操作に直接関係しない機能を含めて、アクセスの他の機能を管理することも可能である。

　好ましくは、データライブラリはそれぞれ異なる所有権を有する。このセキュリティ機構は、データが検索されるデータライブラリの所有権に従い、メンバのデータへのアクセスを制御できる。異なる各組織は、１個又はそれ以上のデータライブラリを所有できる。したがって、各組織は複数の異なるデータファイルを格納する自分のデータライブラリを保有することができる。特定のデータライブラリを所有する組織のメンバは、そのデータライブラリにフルアクセスできるが、一方セキュリティ機構は、他の組織のメンバが前記データライブラリのデータに関して特定の機能の操作をすることを防止することができる。特に、このセキュリティ機構は、他の組織のメンバが前記データライブラリのファイル削除の許可を与えることを防止できる。

　好ましくは、このセキュリティ機構は、データへのアクセスを含むデータベースに関する機能の操作をメンバが要求できるようにする。したがって、メンバは特定データの読出、書込又は編集を要求できる。さらにメンバは、データベース用パスワードの変更など他の機能も要求できる。

　好ましくは、１つの組織のメンバがある機能を要求した場合、このセキュリティ機構はこのメンバのＩＤの認証を要求する。このように、データベースに対するアクセスが試行された場合、このセキュリティ機構はそれがＩＤの認証が行われたメンバでない限りそのアクセスを拒否する。

　好ましくは、このセキュリティ機構は組織の各メンバが使える機能のリストを有し、組織のあるメンバがある機能を要求するとき、このセキュリティ機構はそのメンバがその機能を使うことができると判断されることを要求する。このように、異なるメンバに対して、このシステムにおける異なるレベルの機能性を付与する。特にこのセキュリティ機構は、特定データに関するどのような許可がそのメンバに付与されたかとは関係なく、特定のメンバにデータを読み取ることだけを許し、その結果そのメンバは前記データの読出だけができる。このように、１つの組織のメンバは、この組織のそのメンバ又は複数のメンバに前もって許されている範囲を超えて他組織のメンバに許可を付与することはできない。

　好ましくは、セキュリティ機構は各組織に１個又はそれ以上の役割を含み、各役割は１個又はそれ以上の機能に関係し、役割の１個又はそれ以上の機能の操作の資格がある前記組織のメンバを定める。このように、メンバが利用できる機能が定められる。メンバが役割の一部分として定められれば、定めた役割には定めた機能を操作する資格（少なくとも一般的に）がある。これは、特定メンバに対しいろいろな機能を定める、比較的直線的な方法を提供する。また、これにより、このセキュリティ機構が比較的直線的かつ便利な方法で操作が可能となされている。特に、異なる機能の任意の選択を個々のメンバに定義するというより（したがって、どのメンバにどの機能が利用できるかを見失わないようにすることが困難になる）、前もって定めた役割は、全体の機能セットを定め、その結果、メンバには各役割の一部分として１個又はそれ以上のセットが付与される。

　好ましくは、セキュリティ機構は１個又はそれ以上のテンプレートを含む。各テンプレートは、役割が定められたメンバが利用できる１個又はそれ以上の機能を示すように、テンプレートを指し示すポインタを有した１個又はそれ以上の機能及び役割のリストを提供する。役割が各組織に関係するのに対して、テンプレートは、どの組織によっても使用するために設けることができる。このように、異なる組織は、異なるテンプレートに属する同じ名称の役割を持つことがある。したがって、例えば、データライブラリを所有する組織は、読出、書込、編集機能を十分に提供するテンプレートに属する「ユーザ」と呼ばれる役割を有することもあるが、一方関連する組織は、読出とコピー機能のみのテンプレートに属する、同じ「ユーザ」と呼ばれる役割を保持してもよい。

　好ましくは、セキュリティ機構は、各組織に対して、その各組織が可視（見える）である他の組織全ての示唆を含む。そして、１つの組織のメンバがある機能を要求すれば、セキュリティ機構は、この機能がメンバの組織に見えない組織が所有するデータライブラリのデータへのアクセスを要求しないとの判断を要求する。このように、データベースを使用する組織は、セキュリティ機構の中に可視であると特に記録されている他組織に対してのみ見える。したがって、他のどのような権利とも関係なく、組織のメンバは、それに対して見えない組織が所有するデータのアクセス、閲覧又は使用が不可能である。確かに、この点に関して、可視性を許可する他組織によってそれらの組織が記入されていない限り、１つの組織のメンバは、そのデータベースを使用しているもう１つの組織の存在を知り得ない。

　好ましくは、セキュリティ機構は、関連する機能の各目標に対して１個又はそれ以上の許可を与え、その許可によって定めた機能の定めたメンバによる操作を可能にする。そして、１つの組織のメンバがある機能を要求すれば、セキュリティ機構は、要求された機能とそのメンバが機能の目標の許可の中に含まれるとの判断を要求する。このように、要求をするメンバの権利とは関係なく、このセキュリティ機構は、機能自体がそのメンバにより使用可能であることを確実とする構造を提供する。したがって、メンバのパスワードを変更する要求は、その要求がそのメンバによって、若しくは適切な組織に対する管理権を有するメンバによってなされた場合、このセキュリティ機構によって許可される。もう１つの組織に対して管理権を有するその組織のメンバの場合には、必ずしも許可が与えられない。

　好ましくは、セキュリティ機構は、各機能が複数の目標を対象とするようにする。この機能の最終の権限付与は、各機能と関連するオプショナルなビジネス論理（権限付与の目標で）の評価に依存する。これによりシステムは、複数の組織に（潜在的に）わたる複数の目標に関する複雑な動作を可能にする。

　好ましくは、データライブラリのデータファイルは許可と関連されており、その許可とは、定められた機能が、定められたメンバにより各データファイルに関して実行可能とするものであり、１つの組織のメンバがデータファイルに関してある機能を要求すれば、このセキュリティ機構は要求された機能とそのメンバがデータファイルの許可に含まれるとの判断を要求する。このように、特定のメンバが特定の機能、例えば、削除を実行する権利を持っていても、このセキュリティ機構はデータファイル自体が、当該メンバがこの機能を実行する許可を含んでいない限り前記機能の実行を許可しない。

　本発明によれば、プログラムがコンピュータ上で実行されているとき、セキュリティ機構の全ステップ実行のプログラムコード手段よりなるコンピュータプログラムの提供も可能である。また本発明によれば、また、プログラム製品がコンピュータで実行されているとき、セキュリティ機構の全ステップ実行の、コンピュータ読取可能媒体に格納されたプログラムコード手段よりなるコンピュータプログラム製品の提供も可能である。

　本発明によれば、ネットワークに接続されたデータベースを複数の組織のユーザで共用するにあたり、自分の組織のデータのみのアクセスでき、他の組織のデータへのアクセスが拒否できるようにする。さらには自分の組織のデータがそのデータベースにあることや、そのデータベースを使用していることさえ知られずにそのデータベースを複数の組織で共用することが可能となる。

　本発明は、複数の会社又は組織がデジタルメディアの管理及び作業フローにおいて協力できるように設計されたメディア管理システム（ＭＭＳ：Media Management System）を提供する。例えば、ＭＭＳは、２社が同じ広告キャンペーンに従事し、デジタルメディア（例えば、ビデオと画像）を共用し、作業することを可能にする。ＭＭＳは、データベースが様々な部分に分割されるように、データがデータライブラリに分割された共通のデータベースを使用する。通常、少なくともＭＭＳを使用する組織は、それぞれのデータライブラリの所有権を有する。

　図１に示すように、データベース２はデータを格納するために用いられる。このデータは、データファイル６に区画化されたデータライブラリ４に整理されている。複数の組織８は、インターネット又はワールドワイドウェブ（ＷＷＷ）などの外部ネットワーク１０を用いてデータベース２にアクセスできる。各組織８は、１人又はそれ以上のメンバ１２を含み、各組織８自体の内部システムの一部分としてネットワークでリンクされている。

　外部の組織８は、セキュリティ機構１４によりデータベース２とインタフェースされる。下記で明らかになるように、セキュリティ機構１４は、組織８、メンバ１２、データライブラリ４及びデータファイル６に関し、どのメンバによるどのアクセスが許可されるかを判断する情報を蓄積している。さらに、データベース２に関する機能をメンバ１２が要求したとき、許可できるアクセスの検査を行う手順を実行する。

　セキュリティ機構１４は、インタフェース又はデータベース２の一部として一体的に構成されてもよい。しかしながら、セキュリティ機構１４は従来のハードウェアとは異なり、ソフトウェアで実現され、制御に用いられることを、本発明は提案する。

　ここでのＭＭＳの意図する範囲のセキュリティとは、２個の主セクションよりなると考えられる。これらのセクションは、システムセキュリティとアプリケーションセキュリティである。システムセキュリティは、ＭＭＳアーキテクチャ構成要素と、それらが個々及び全体としてどのように保全されるかとに関連したシステムの側面の記述である。システムセキュリティは、各構成要素に関し次の項目を定義する。

　・構成要素のシステム内のアクセス方法である、各構成要素に対するアクセス経路（データファイル６のような）
　データベースサーバにとって、これはどの構成要素がサーバに接続して構造化検索言語ＳＱＬ動作を実行するかを記述する。これは、構成要素へ通じるネットワーク経路（通常の操作の場合）を理解するために重要である。

　・構成要素にアクセスする実体（メンバ１２のような）の識別情報
　ウェブアプリケーションの場合、アプリケーションサーバは、システム内のバックエンド構成要素のプロキシの役目を果たす。これは、バックエンド構成要素がアプリケーションサーバにアクセスされ、ユーザの識別情報が不明という事実以外を知らない可能性が強いことを意味する。この結果、ユーザが許可されている操作を実行しているだけであることを確認するために、アプリケーションサーバ内で実行されるアプリケーションにより重要な条件が要求される。

　・ＭＭＳシステムの意図する範囲内における認証証明書伝播方法
　これは、ユーザＩＤ／パスワードをシステムユーザ（すなわち、組織８のメンバ１２）に伝達する方法及びアプリケーションサーバをバックエンドサービスにアクセスできるためにアプリケーションサーバが要求する証明書の移動及び蓄積方法を含む。

　・システム内の各構成要素のバックアップ及び復旧手順
　これは、構成要素が怪しくなったとき、それを以前の有効状態に確実に復旧させるために必要である。

　・システムセキュリティの最後の焦点は、各構成要素用に書き込まれた方針の検査、検証の仕組みを理解することである。

　システムセキュリティの定義を要する構成要素は、ディレクトリサーバ、ウェブサーバ、データベース、ＵＮＩＸ（登録商標）システム、ＦＴＰサーバ、アプリケーションサーバ、資産ストレージ及びネットワークである。アプリケーションセキュリティは、いかにアプリケーションがそれ自体でセキュリティを行使するかを取り扱う。これは、ウェブサーバ／アプリケーションサーバがユーザとバックエンド資源（図２参照）間のプロキシの役目を果たすため、ｎ層システム（特にウェブに基づくシステム）に特に関係が深い。

　ユーザ又はメンバに関する限り、ユーザがアプリケーションと持つただ１つの相互作用は、アプリケーションサーバを通じて行われる。その他の相互作用は、アプリケーションサーバで実行中のアプリケーションが要求する資源に対して達成される。ユーザが、実際多数あるシステムのうち唯１個のシステムに確実に連絡がつくという視点から、これは満足できる。問題は、バックエンド資源はユーザを直接知らないことである。それらは、アプリケーションが指示することを信じるしかない。通常の効果的な使用の筋書きでは、アプリケーションサーバには、データベースなどに接続する１人のユーザとパスワードがある。このＩＤは、全ユーザ用の動作を実行するのに十分な許可をデータベース内に有する。ということは、アプリケーションサーバは、潜在的にシステムの他の構成要素をアタックするポイントである。この問題は、アプリケーションサーバを通じてデータを送信し、ユーザができないかもしれない動作をアプリケーションサーバに実行させるため、「混乱したプロキシ」問題として説明できる。この結論は、アプリケーションサーバ内のコードは、どんな動作でも処理しているとき、次の３点を認識する必要がある。
１）誰が動作を実行しているか
２）どの動作を実行しているのか
３）何に対してその動作を実行しているのか

　本発明は、主としてシステムセキュリティに関する。セキュリティ機構１４を実行するために、ディレクトリサーバ及びＬＤＡＰ（ライトウェイトディレクトリアクセスプロトコル）に、特定の構造が用いられている。このＬＤＡＰは、階層ディレクトリ内で整理された情報にアクセスする構造として開発されたプロトコルである。このツリーの中の項目は、その識別名（ＤＮ）で位置がわかる。ツリーはイニシャルの接尾辞の下に整理されている。ＤＮの構成要素は、階層内に存在する場所を記入する。

　図３は、３項目を有するツリーを示す。このツリーの接尾辞ＤＮはo=mmsである。他の項目はＭＭＳに記憶された組織に該当し、それらのＤＮはそれぞれ、o=Son Marcomms、o=mms、o=Design Agency、o=mmsである。ＤＮは、その親リーフのＤＮと共に新属性値対の組合せであることは注目に値する。したがって、新組織ユニットを、o=Son Marcomms、o=mmsの下のPeopleに追加する必要がある場合、そのＤＮは、ou=People、o=Son Marcomms、o=mmsとなる。データは、ツリーに属する各ＤＮに対して記憶され、表示できるフィールドは、ディレクトリ図式で管理される。

　ＬＤＡＰプロトコル自体は、非常に簡単であり、表現的及び機能的な問合せインタフェースを提供できることよりも、記入項目への能率的なアクセスを主眼に設計されている。ＬＤＡＰは、ＡＤＤ、ＭＯＤＩＦＹ、ＤＥＬＥＴＥ、ＭＯＤＲＤＮ、ＢＩＮＤ、ＵＮＢＩＮＤ及びＲＥＢＩＮＤという７個の操作を含む。

　ＭＭＳ用ディレクトリサーバに蓄積された階層の構造は、どのようにデータが整理され、どのようにセキュリティの定義に要するマッピングが作成されたかを理解する鍵となる。ＭＭＳディレクトリサーバ内における全ユーザ情報の基礎接尾辞は、o=mmsである。それ以下の階層は、アプリケーションの要求を反映するように設計されている。最初の階層グループ分けは、ＭＭＳに属する組織のグループ分けである。これらの組織及びその関連役割、グループ及びメンバ（下記に説明）はお互いに分離しており、これがツリー構造に反映されることが必要である。図３の例は、２個の組織を有するツリーを示す。それらの組織の項目は、ＤＩＴ（ディレクトリ情報ツリー）内の組織の下に添付されている。組織は、また見ることができる他組織のリストを含む。組織の可視性は重要な要因であり、以下に説明する。

　組織８は、多数の（０又はそれ以上）ユーザ／メンバ１２を有する。これらのユーザ／メンバ１２は、組織のメンバ分岐の下でグループ分けされ、uid属性（ユーザＩＤ）に従って蓄積されている。これを図４に示す。また、組織８は、管理目標のため、そして資産への幾つかのアクセス許可と共に、ユーザ／メンバ１２を集めるのに用いられる多数のグループを有している。これらのグループは、cn属性（共通名）に従い組織のグループ分岐の下で記憶されている。これを図５に示す。グループ自体は、それ自体グループであるメンバよりなる。各メンバは、ユーザ又は他のグループを参照する識別名である。

　また、組織８は、組織８内におけるユーザ／メンバ１２の機能的許可決定に用いる多数の役割を有する。各役割には、メンバとそれが参照するグローバルな役割のリストがある。ＭＭＳに対する役割情報は、ＤＩＴのテンプレートセクション内にグローバル的に蓄積されている。このテンプレートセクションは複数のテンプレートを含み、各テンプレートは読出、書込、編集などの機能の特定な集合を定める。テンプレートは、また、ただ１つの各機能の定義に提供されることもある。組織８用に作成された役割は、ＤＩＴのテンプレートセクション内に単一のテンプレートを参照する。これにより、さらにテンプレートエリア内のテンプレートを参照できる。組織の役割は、図６が示すように、ＤＩＴの役割分岐の下で判る。システム内の役割が機能するには、異なる組織が参照するグローバルなマスタリストが必要となる。この情報は、ＤＩＴのou=Roles、cn=Globals、o=mms部分の下に蓄積されている。テンプレート情報は、ツリー全体を通じて参照される組織及び役割のデフォルト情報を含む。

　何が何と関係しているかというグループと役割の関係は、図７に示されている。図７を要約すれば、１個のグループ２０は、０又はそれ以上のメンバ１２と、０又はそれ以上のグループ２０とを有し、１つの役割２２は、０又はそれ以上のメンバ１２を有し、そしてメンバ１２及び１個のテンプレート２４を参照し、１個のテンプレート２４は、０又はそれ以上の役割２２から参照され、０又はそれ以上のテンプレート２４を参照する。メンバ１２は、暗に０又はそれ以上のグループ２０のメンバ及び役割２２となり得る。

　ディレクトリサーバの構造と蓄積されたデータが与えられると、ユーザのグループメンバシップが取得できる処理を定める必要がある。この処理は、ＤＩＴの弾力性に応える必要があるが、後日の最適化の可能性を考慮に入れる。この最適化は、結果をキャッシングによって達成しなければならない。この処理は、下記の説明の要領で実行される。

　・ユーザＤＮを取得
　この動作開始には、ユーザ又はメンバ１２の識別名が利用できる状態でなければならない。これは、下記のＬＤＡＰフィルタを使うユーザのuid属性（ディレクトリ内でこれがユニークなので）を用いて取得できる。
（uid=userid）

　・ユーザが直属するグループ名をリストする
　見つけたいメンバシップのユーザ１２のＤＮにより、下記のＬＤＡＰフィルタを使ってユーザ１２がメンバであるグループ２０のリストを取得する。
(&(objectclass=mmsGroup)(|(uniquemember=userDN)(mmsAdministrator=userDN)(mmsOwner=userDN)))

　・フルリストを見つけるためにグループを横断
　グループ２０内のuniquememberフィールド内の各グループ２０　dn参照用に、それがメンバであるグループ２０を取得する（この動作は再帰的）。循環参照をチェックするために、ユーザ１２がメンバであるグループ２０のリストは、セット内で蓄積される必要がある。下記のＬＤＡＰフィルタを使ってグループ２０が属するグループ２０をチェックする。
(&(objectclass=mmsGroup)(uniquemember=groupDN))

　下記の説明は、ユーザ１２が実行できる役割２２のリストを取得するための処理に関する。この処理は、高スループット環境における結果をキャッシュメモリを用いて、最適化する必要がある。この処理は下記の説明のように実行される。

　・ユーザＤＮを取得
　この動作開始には、ユーザ又はメンバ１２の識別名が利用できる状態でなければならない。これは、下記のＬＤＡＰフィルタを使うユーザのuid属性（ユニークである）を用いて取得できる。
（uid=userid）

　・ユーザが属する役割をリストする
　次の段階は、組織８内にユーザ１２が割り当てられた役割２２をリストする。これは、下記のＬＤＡＰフィルタを使って行う。
(&(objectclass=mmsRole)(uniquemember=userDN))

・最終リストを作るためにグループを横断
　組織８内の役割２２のリストが明らかになると、これらのそれぞれは、許可された役割２２と参照テンプレート２４で定義された機能の最終リストにマップされる（テンプレート情報を経て）必要がある。組織８用の各呼び出された役割２２に対して、それに内蔵されたサブ役割を取得するために検索を行わなければならない。これは、役割の階層を横断する回帰的操作であり、各役割２２の属性をローディングし、サブ役割を見つけるためにユニークなメンバ（uniquemember）属性を用いることによって、実行される。

　媒体管理システムは、外部組織８からアクセスできるデータベース２を提供する。各組織８は、１人又はそれ以上のメンバ１２を有する。メンバ１２は、したがって、システムのユーザ１２である。ユーザ１２が、先ずシステムに機能を実行しようと試みたとき、セキュリティ機構１４はユーザ１２の認証を試みる。

　認証条件を充たすために、セキュリティ機構は２つのことをサポートする。
１）証明書セットを認証できる能力
　ユーザ１２が認証されるには、証明書セットをシステムに提供しなければならない。これらの証明書の１つは、必ずユーザの識別情報（useridが該当する）である。第２の必要条件は、ユーザが、パスワードなどの正当性を立証できる証拠を提出することである。そうすれば、ＭＭＳは、これらの証明書をディレクトリサーバ内の中央に蓄積されている書類と照合して、ユーザ１２を認証すべきか判断する。

２）何時でも現在の証明書を認識している能力
　一旦ユーザが認証されると、システムは実行中いつでもこの情報を呼び出す。すなわち、アプリケーション制御のフローの任意の時点で、現在認証されたユーザ１２の識別情報を得ることが可能である。

　一旦システム内でユーザ１２が認証されると、動作又は機能の発信者がアプリケーションに対して明らかなため、権限付与に関する３つの必要条件の第１の条件が充たされる。また、セキュリティ機構１４はこの情報を用いてＭＭＳシステム内で誰が動作を実行したか監査できることを意味する。

　セキュリティ機構の意思決定のフローという観点から、これは、図８が示すようにチェーンの第一歩となる。機能的アクセス必要条件は、システム内の機能性にアクセスするのを制限するＭＭＳ内の必要条件を規定する。ＭＭＳ内の機能アクセスの制限方法は、役割２２を通じて行う。上述の通り、役割２２は、ＭＭＳ内において実行される機能を定める。最も単純なレベルでは、役割２２は、許可を受けたユーザ１２に対する機能性のマッピングである。したがって、役割２２は、その使用を許可された全ユーザ１２の参照を有する。さらに、機能ブロック（グループのグループを持つのと大方同じ方法で）を形成するために、役割２２のグループ化が可能でなければならない。

　ＭＭＳの意図する範囲内で、ユーザ１２が動作実行権限付与を与えられることができるように２つの情報が提供される。ユーザ１２はＭＭＳに認証されなければならず（上述のように）、ユーザ１２は、実行を試みようとする役割２２のメンバでなければならない。役割２２自体は、システムの必要条件に基づきＭＭＳで決められる。役割２２と役割２２のグループの定義には、中央のソースが必要である。組織８は、必要に応じてこれから引き出せばよい。これにより、異なる組織がＭＭＳ内で使用できる機能性について制限を受けるようにすることができる。また、中央の基準を変更して、ＭＭＳに機能性を簡単に追加したり、削除できることを意味する。ユーザ相互作用の観点から、役割メンバシップモデルは、実行許可のある機能、例えば収集者だけが収集タブを見るなどに基づいて、開発者にユーザ１２に対してインタフェースを提供する能力を与える。

　動作実行をユーザに許可するかどうかの判断に必要な意思決定のフローを詳しく説明するフローチャートから、図９に示す更新図が得られる。図９は、操作又は機能を許可すべきかをチェックする最初の２つのステップを示す。機能自体は、必ずしもそれ程重要ではない（その目標は重要であるが）。このモデルが使用できるためには、システムのエンドユーザ１２に、役割２２の割当て及び委任の管理を可能にするインタフェースの提供が重要である。この機能性を最もよく表現する方法は、使用の事例と実行者の定義による。使用の事例は、ここでは資源管理に定義されたものと多少重複するが、これはシステム内で役割２２を配分する主要なソースである。

　操作／役割を実行：
　この動作は、ユーザ１２がＭＭＳ内で動作の実行を試みることである。これはＭＭＳ内のあらゆる種類の動作に対する汎用使用事例である。これに対する権限付与は、ユーザ１２が適切な役割２２のメンバであるかどうか、そして、また動作が実行されているデータが実行許可を得たものであるかどうかの判断に基づいて与えられる。これは、図１０を参照して下記に説明されている。

　役割の作成：
　この動作は、新しい役割２２を作成することである。これは管理機能である。この動作に要する情報は、作成する役割の役割についての詳細である。役割２２は、組織８の意図する範囲外で作成され、この役割の使用が可能な組織用のテンプレートとして用いられる。

　役割の除去：
　この動作は、既存の役割２２を除去することである。役割２２はＭＭＳ内でそれに関する全参照と共に除去される。これで、役割を全員から除去する。これは管理機能である。

　役割の付与：
　この動作は、組織８内のユーザ１２に役割２２のメンバシップを与える。この動作に対する必要情報は、許可を与えられるユーザ１２及び役割２２への照会である。この付与は、簡単なメンバシップ及び役割管理者の形を取る。この動作に関する権限付与は、ユーザがユーザ管理者又は組織管理者であるかに基づいて与えられる。

　役割を役割に追加：
　この動作は、役割２２内で役割２２をグループ化するために用いられる。それは、役割２２をもう１個の役割２２に追加できるようにする。これは、機能をグループ化し、アプリケーションセキュリティの管理をやり易くするための、役割パッケージ作成を可能にする。この動作の入力は、追加される役割２２の照会と追加を受ける役割２２の照会である。これは管理操作である。

　役割から役割を除去：
　この動作は、役割２２をもう１個の役割から非グループ化する際に用いられる。これは前記と逆の機能である。この動作の入力は、除去される役割の照会と除去を受ける役割の照会である。これはアプリケーション内容外の管理操作である。

　役割の取消：
　この動作は、役割からユーザの許可を除去する。役割メンバシップと役割管理特権の両方を取り消すのに用いられる。この動作の入力は、役割への照会とそれから除去されるユーザへの照会である。この動作はユーザ管理者であり組織管理者であるユーザのみが利用できる。

　役割を組織に配分：
　この動作は、役割２２（又は役割の集合）を組織８に渡す際に用いられる。異なる組織８に異なる機能性が提供される場合に用いられる。この動作の入力は、配分する役割２２への照会とそれを配分する組織８への照会である。これは管理操作である。

　組織から役割の取消：
　この動作は、役割２２（又は役割の集合）を組織８から除去する際に用いられる。この動作の入力は、除去する役割２２への照会とそれを除去する組織８への照会である。これは管理操作である。

　前述のように、このセキュリティ機構１４によるセキュリティのフローは、ユーザ１２が機能又はＭＭＳ内の役割２２の実行許可を得ているかどうかを解決するため、認証に必要な初期条件から作成した。特定の動作又は機能へのアクセスの付与を可能にするために、セキュリティ機構１４が必要なことがもう１つあり、それは動作が目標としている資源を理解することである。この必要条件を組み入れれば、図１０にあるようにセキュリティ機構の最終決定のフローが誕生する。

　このステップの一部として、セキュリティ機構１４は、ユーザ１２が要求機能を実行する許可を得ているとして、当該目標に記入されているか否かを決定する。データファイル６に関する動作又は機能自身の場合、データファイル６は、ユーザ１２及び読出、書込、編集といった機能のどれを実行する許可があるかの詳細を関連情報として持っている。同様に、目標がユーザ１２に関するデータである場合、もしユーザ１２がそれ自身のデータに基づいて行動しているか、又はユーザ１２が該当する組織８に対する管理権を有している場合、動作のみが許可される。図１３は、パスワード変更を試みるユーザ１２に関するフローチャートである。このセキュリティ機構１４は、データとフォルダに対する許可を蓄積する構造を含む。これらの許可は、ユーザ１２自身か、それともユーザ１２がそれらの許可を配分したグループ２０のメンバであるか否かに基づく。許可は、また資産メタデータレベルで特定できる。

　ユーザ１２が他のユーザ１２に編集の許可を与えられるような、許可階層の設定を提案する。下記の表は、ＬＤＡＰで付与／取消許可リストの平坦化したものを特定することにより、これがいかに構成可能かを示している。

　付与は、一貫性を確実にするために取消前に処理される。例えば、付与削除と取消ビューはこの順序で処理され、両者が確実に相殺するように行う。ユーザ相互作用の観点から、許可モデルは、ユーザインタフェース開発者に、資産とメタデータ許可に基づいてインタフェースをユーザに提出する能力を与える。例えば、入力フィールドとボタンは、もしユーザが資産の編集の許可を得ていない場合、ダブリンコア（Ｄｕｂｌｉｎ　Ｃｏｒｅ）メタデータ画面上では無効とされるかもしれない。

　資産には、所有する組織８と所有者がいる。所有者は、資産／フォルダを作成したユーザでありそうに思えるが、この所有権は時間と共に変化し得る（例えば、元の所有者が会社を去る）。所有する組織は、所有者の組織でありそうに思えるが、他組織の代表として資産作成が可能である。

　プロキシ資産は、マスタと同じ組織を有する。この規則は、次の場合行使される。

　・プロキシ権が収集される。

　・所有する組織がマスタで変更される。

　同様に、「新バージョン」の資産は、「以前のバージョン」と同じ組織を有する。この規則は、次の場合実施される。

　・バージョンが収集される。

　資産制御の役割の必要条件を理解する最良の方法は、ＭＭＳ内の資産関連の使用事例及び資産と資産管理に関連する種類の役割をよく調べることである。使用事例とは、ＭＭＳ内のフォルダと資産管理に関係する動作で実行されるものをいう。

　ルートフォルダの作成：
　この動作は、ユーザ又はグループフォルダの作成能力である。

　サブフォルダの作成：
　この動作は、フォルダ内にフォルダを作成する能力である。

　フォルダの編集：
　この動作は、例えば有効日付の変更といったフォルダを編集する能力である。

　フォルダ所有者の設定：
　この動作は、フォルダ所有者又は所有組織を変更する能力である。

　フォルダの除去：
　この動作は、フォルダ及びそれが参加している（親及び／又はサブフォルダとして）入れ物関係を除去する能力である。ソフト又はハード削除が可能（ＬＤＡＰを用いて構成可能）。ソフト削除の終端にはフォルダの日付をいれるため、もはや効果的ではなく、それに反してハード削除は記録を除去する。

　フォルダへのビューアクセス：
　この動作は、フォルダに関するアクセス許可を見る能力である。

　フォルダへのアクセス付与：
　この動作は、フォルダへのアクセスを付与する能力である。

　フォルダへのアクセス取消：
　この動作は、フォルダへのアクセスを取り消す能力である。

　フォルダダブリンコアメタデータの編集：
　この動作は、フォルダのダブリンコアメタデータを編集する能力である。

　フォルダにユーザ定義メタデータ追加：
　この動作は、ユーザ定義メタデータをフォルダに追加する能力である。

　フォルダのユーザ定義メタデータ編集：
　この動作は、フォルダのユーザ定義メタデータを編集する能力である。

　フォルダのユーザ定義メタデータ除去：
　この動作は、フォルダのユーザ定義メタデータを除去する能力である。

　フォルダのユーザ定義メタデータへのビューアクセス：
　この動作は、フォルダのユーザ定義メタデータに対するアクセス許可を見る能力である。

　フォルダユーザ定義メタデータへのアクセス付与：
　この動作は、フォルダのユーザ定義メタデータに対するアクセスを付与する能力である。

　フォルダのユーザ定義メタデータへのアクセス取消：
　この動作は、フォルダのユーザ定義メタデータに対するアクセスを取り消す能力である。

　リンクの作成：
　この動作は、フォルダともう１個のフォルダ／資産間の入れ物関係を作成する能力である。

　リンクの除去：
　この動作は、フォルダともう１個のフォルダ／資産間の入れ物関係を除去する能力である。ソフト又はハード削除が可能（ＬＤＡＰを用いて構成可能）。ソフト削除の終端にフォルダの日付をいれるため、もはや効果的ではなく、それに反してハード削除は記録を除去する。

　プロキシの収集：
　これは、もう１個の資産のプロキシである資産を収集／作成する能力である。プロキシは読出のみであるべきである。すなわち、プロキシに対する編集許可は許されない。もしユーザによってそれが許された場合、ＭＭＳシステムは、業務層で静かにダウンする。

　バージョンの収集：
　これは、既存資産の新バージョンである資産を収集／作成する能力である。既存資産はバックエンド日付なので、もはや有効でない。新バージョンは、既存資産が入っているフォルダに置かれる。

　資産の編集：
　この動作は、資産を編集する能力である。すなわち、有効日を変更することである。

　資産所有者の設定：
　この動作は、資産の所有者又は所有組織を変更する能力である。

　資産の除去
この動作は、資産及びそれが参加している関係を除去する能力である。ソフト又はハード削除が可能（ＬＤＡＰを用いて構成可能）。ソフト削除の終端に資産の日付をいれるため、もはや効果的ではなく、それに反してハード削除は記録を除去する。

　資産へのビューアクセス：
　この動作は、資産に対するアクセス許可を見る能力である。

　資産へのアクセス付与：
　この動作は、資産に対するアクセスを付与する能力である。

　資産へのアクセス取消：
　この動作は、資産に対するアクセスを取り消す能力である。

　資産ダブリンコアメタデータの編集：
　この動作は、資産のダブリンコアメタデータを編集する能力である。

　資産フォーマットメタデータの編集：
　この動作は、資産のフォーマットメタデータを編集する能力である。この動作は、資産のフォーマットメタデータが再抽出された場合、例えば、新フォーマットメタデータエクストラクタが用意されたときにのみ実行される。

　資産へのユーザ定義のメタデータ追加：
　この動作は、資産にユーザ定義のメタデータを追加する能力である。

　資産ユーザ定義のメタデータの編集：
　この動作は、資産のユーザ定義のメタデータを編集する能力である。

　資産ユーザ定義のメタデータ除去：
　この動作は、資産のユーザ定義のメタデータを除去する能力である。

　資産ユーザ定義のメタデータへのビューアクセス：
　この動作は、資産のユーザ定義のメタデータに対するアクセス許可を見る能力である。

　資産ユーザ定義のメタデータへのアクセス付与：
　この動作は、資産のユーザ定義のメタデータに対するアクセスを付与する能力である。

　資産ユーザ定義のメタデータへのアクセス取消：
　この動作は、資産にユーザ定義のメタデータに対するアクセスを取り消す能力である。

　プロキシ関係の作成：
　この動作は、２つの資産間のプロキシ関係を作成する能力である。プロキシは読出のみであるべきで、そのため、プロキシに関する全編集許可は除去される。

　プロキシ関係の除去：
　この動作は、２つの資産間のプロキシ関係を除去する能力である。

　グループの作成：
　認証されたユーザは、ＭＭＳ内でグループを作成する能力を有する。このグループは、その組織の範囲内で作成され、ユーザは、自動的にグループ所有者として設置される。そうすればこのグループは、他のグループとユーザの集まりを持つために用いられ、それから、ＭＭＳ内の資産への許可の制限に使用される。この動作の入力は作成されるグループ名となる。

　グループの削除：
　グループの削除とは、それをシステムから除去することである。これは、グループ及び、また、よそから存在したそれに関する照会を除去する。（グループに対する照会があれば、警告メッセージが表示されるべきである。）この動作の入力はグループへの照会となる。この動作の権限付与は、ユーザがグループ所有者、組織管理者、あるいはＭＭＳ管理者であるかに基づき付与される。

　グループへのメンバシップの付与：
　これは、ユーザがグループ内のメンバシップをもう１個の実体（ユーザかグループ）に付与する動作である。この動作の入力は、メンバシップを付与するグループと追加されるユーザ／グループへの照会である。この動作の権限付与は、ユーザがグループ所有者、グループ管理者、領域管理者あるいはＭＭＳ管理者であるかに基づき付与される。

　グループメンバシップの取消：
　これは、ユーザがグループから実体（ユーザかグループ）を除去する動作である。この動作の入力は、グループの照会とそれから除去される実体への照会である。この動作の権限付与は、ユーザがグループ所有者、グループ管理者、領域管理者あるいはＭＭＳ管理者であるかに基づき付与される。メンバシップは、グループ所有者に対しても取り消される。

　このセクションは、本明細書で使用されている用語を定義する。この理由は、ＡＳＰ（アプリケーションサービスプロバイダ）内の役割に基づくセキュリティ機構環境は複雑な操作であるからである。

　さて、セキュリティ機構には、定められた動作が何で作動しているか理解できるようにという必要条件があることを念頭に置き、次の段階では、ＭＭＳ内の目標表現方法を定義する。これは、前述の図３から６で検討した。記号表現要求の方法とは、十分に汎用的で、セキュリティ管理者は、全ての目標について知るよりも、寧ろ要求が許可されたかを見つけるためには、どこに尋ねればよいかを知っているだけでよい。これは、全ての現存する役割について知らなくても、役割の規則をどのように解釈するかを知るとのと同じである。したがって、枠組みは、該当する資源について中立であり、データベースにある資産やフォルダのようなことにアクセスし、さらに、ディレクトリサーバに属する役割２２、ユーザ１２及び組織８に対する探索を処理できる土台を提供している。

　図１０に示す目標表示の最後の側面は、ＭＭＳに属する資源と情報が有する可視性である。１つの組織８は、組織８が協力する用意のあるそれらの組織８を特定できなければならない。この関係は明確にする必要がある。これは、フローにある「実行目標は許可された？」で最初のチェックの１つでなければならない。したがって、データライブラリ４とかデータファイル６のような資源は、組織８及び所有組織の組織の好みで達成させたアクセスが所有される必要がある。

　ＭＭＳ運用に際して、いろいろな操作者又は実行者に、ＭＭＳ所属としての職務に従い、異なるレベルの制御が許可されている。図１１は、ＭＭＳ内で関係しているいろいろな実行者を例示している。ユーザ１２はＭＭＳ内の基礎ユニットである。ユーザ１２は、新資産収集とは別に、システム内のほとんどの動作を実行できる。ユーザは、自身のデータアクセスできるデータを修正でき、グループ２０を作成及び制御し、資産を探索／ダウンロードする。ユーザ１２のシステムに対するアクセスは、組織８及び所属するグループ２０に左右される。

　ユーザ管理者３０は、ユーザ１２ができることが全て可能な許可を得ており、ＭＭＳ内のユーザ１２作成及び管理に関して追加の能力を有している。ユーザ管理者３０は同じ組織８内の役割２２、パスワードとユーザ１２の個人的詳細を制御できる。また、新ユーザ１２を彼らの組織内で作成できる。

　フォルダ管理者３２は、ユーザ１２ができることが全て可能な許可を得ており、フォルダの管理、すなわち、データファイル６の集まりに関して追加の能力を有している。フォルダ管理者３２は、組織８の範囲内でどのフォルダも管理できる。これには、作成、削除とそれらの許可が含まれる。

　グループ管理者３４は、ユーザ１２ができることが全て可能な許可を得ており、グループの管理に関して追加の能力を有している。グループ管理者３４は、組織８の範囲内にあるどのグループも管理できる。

　資産管理者３６は、ユーザ１２ができることが全て可能な許可を得ており、資産に関して追加の責任と能力を有している。資産管理者３６は、組織が所有するどの資産に対しても管理特権を有し、そして新資産を収集する能力も有している。組織管理者３８は、組織８の範囲に属するあらゆるもの対して管理特権を有する。収集者４０とは、新資産をシステムに導入できるけれども既存資産を探索し、見る能力に欠ける人々のために用いる特別な役割である。この職務は、新資産を大量に収集する作業を与えられた誰に割り当てられるか、この職務をファイル収集の追加特権を与えるためにユーザ１２に追加できる。

　ＭＭＳは、また、監査の機能をも含むことがある。セキュリティの観点から考えて、監査という用語には２つの使い方がある。アプリケーションかシステムのセキュリティを監査する能力と、アプリケーション内で発生したことを監査する能力である。これの能力は、両方とも重要である。これらの必要条件を理解するには、セキュリティがＭＭＳの状況に応じて、どのように制御されているかを理解することが大切である。

　図１２に示されているように、アプリケーションにおけるセキュリティ機構１４の基本的なフローは、動作が実行されるために、そこへ渡される。前述のように、セキュリティ機構は、それから、動作実行を試みるユーザ１２の許可、それらの役割及びそれらが動作の実行を試みる対象に基づいて、動作を実行するか否かの決定を行う。この時点で、機構は、試みられた動作とそれが許可されたか拒否されたかを記録する。そして、それは動作を実行しようと試み、発信者に応答を返すか、又は要求された動作実行に対する十分な許可を有していないと発信者に知らせる。

　アプリケーションをリリースする前に、そのセキュリティは検査される。ウェブアプリケーションは、ＨＴＴＰプロトコルが無国籍なので、この面で興味深いチャレンジを提供する。したがって、必ずしも直前のページに返らなくとも、ページを要求できる。ユーザ１２が認証されたセッションを持てば、システム内で如何なる動作も始動（理論上）できる。その結果、セキュリティ機構１４が、アプリケーション内でアクセス制限時に適切に機能することを確実にするために、十分な再検討及び検査処理が必要である。この視点から、この検査実行のために実施する必要のある唯１つのインタフェースがあるためには、セキュリティ機構１４ができるだけ少ない数のエントリーポイント（このケース１では）を有することが大切である。

　アプリケーションが作動すると、ユーザ１２は、異なるレベルの許可を有する機能性にアクセスできる。システム内のありうる問題点が追跡できることが重要で、そうすれば、システム内のありうる問題点が追跡可能になる。すなわち、アプリケーション内の全ての動作がつぶさに記録できることが大切である。ウェブサーバの記録を分析するソフトウェアを使用し、この機能性に非常に近接することは可能である。ここでの問題点は、動作を要求したユーザ１２が必ずしも捕捉されるとは限らず、また、動作のパラメータと詳細が捕捉できないこともある。したがって、システム内で起こる全ての動作は記録される。これができることにより、次のことが可能になる。

　サポートデスク：
　技術サポート機能は、ユーザの問題解決をサポートするために、ユーザ１２が（ある段階で）どの動作を試みていたのか知る必要がある。ヘルプデスクの観点から、ユーザが何をしていたと考えたかをユーザから聞き出し、それと彼らが何をしていたと考えたかをシステムから知るために、ユーザが何をしようとしているのかについて両方の見方を得る方がよりよい。また、システムのユーザインタフェース内の不一致エリアへの非常によいフィードバックとなる。

　説明責任：
　監査データベースに何かが姿を見せると、そのユーザがその動作を実行（又は試みた）したという可能性がある。技術サポートと話をするときに、ユーザエラーをかばうためにアプリケーションエラーだとする組織に対するサポート状況にとっては有用である。企業が潜在的にお互いの資産を共用できるＡＳＰ環境において、法的な観点から、ＭＭＳプロバイダにとっても重要であろう。この状況では、２社の競合相手は、お互いに自社の資産／企業構造の可視性を得たくない。このアクセスが付与されるかもしれない状況では、ＭＭＳプロバイダが、このエラーを犯したアプリケーションによってこのアクセスが与えられたのではないと証明できるために大切である。アクセスが危うくなるuseridの場合、ＭＭＳは、依然として、セキュリティ違反は特定の得意先が危険な目に会ったからだと主張できる。

　セキュリティ弱体化の検証：
　理論的には、ハッカーはＭＭＳが運用するシステムに不法侵入し、アプリケーションの規定外とする変更をする。監査の追跡は、この変更の性質と範囲を判定できるために、何か比較するものを与える。

　ありうる不法侵入の試みの認識：
　監査データベースは、また、ユーザがアクセスを得ていないことにアクセスする試みを記録する。完璧なユーザインタフェースでは、これは起こるべきでない。実際の世界では起こるが、頻繁に起こるべきでない。実行失敗動作の数が判れば、ありうる不法侵入の試みとセキュリティ違反の試みの状況が得られる。例えば、ユーザのアカウントが弱められ、ハッカーがＨＴＴＰ要求を操作して他の動作を引き起こすよう試みるため、ハッカーはそれを使う。このような種類の活動は、記録の分析で表面化し、ＭＭＳ管理者が、ユーザアカウントのモニターかロックが必要と主張できる。

　以下は前記で使用された幾つかの用語の定義である。

　ＡＳＰ（アプリケーションサービスプロバイダ）：
　ＡＳＰは、複数の組織のプロバイダである。すなわち、この種類のアプリケーションは、個人の複数の集まりに対してサービスを提供する。予想される影響といえば、必ずしも同じでない各組織へ機能性のブロックの提供というアプリケーションの観点から生じる。さらに、アプリケーションは、それらのセキュリティ必要条件（これはまた、データの可視性に影響する）を理解するために、ユーザの識別情報と、それらが属する組織の識別情報の両方を知らなければならない。

　グループ：
　この明細書の中で、グループとは、資産へのアクセスに関してユーザの集まりを組織化するのに用いられる実体である。グループとは、１つのグループに複数の組織のメンバがいるため、組織を横断する存在である。グループは、また、階層化が可能で、ＭＭＳの枠組み内でグループのグループを持つことできる。

　役割：
　役割とは、ＭＭＳ内の責任と利用できる機能性を定義する構造である。役割は、ユーザの機能性能力をグループ化する構造である。それは、複数の組織を横断するより、寧ろ単一の組織の範囲内に存在する。この理由は、役割とグループ間に非常に強力な分離状態を保持するためである。異なる組織に異なる機能性を付与できるように、役割はＭＭＳ全体に亘ってグローバルに格納され、そして各組織の要求により参照される。グローバルな役割は、包含する役割のリストを有しているため、役割をパッケージにグループ化できる。組織のレベルでは、このグループ化は起こらない。

　認証：
　認証とは、ＭＭＳのエンド・ユーザから証明書のセットを取り、中央に保有する記憶装置に照合して権限を付与する処理である。最終結果は、妥当な程度の確信をもって認証されたユーザは、本人がそうだという本人であると主張できる。

　権限付与：
　権限付与とは、認証されたユーザを扱い、それに動作又は操作をＭＭＳ内で実行させるか決定する行為である。権限付与は、認証されたユーザに対してのみ起こる。

　ユーザ：
　ユーザとは、ＭＭＳアプリケーションを使用する個人である。ユーザは単一の組織に属する。ユーザは、また、０又はそれ以上のグループに所属でき、０又はそれ以上の役割を割り当てられる。

　組織：
　組織とは、ＭＭＳを用いて所有するデジタル資産を管理する実体である。１つの組織は、多くのユーザ、グループそして役割よりなる。

　資産：
　資産とは、ＭＭＳ内に格納されているデジタル媒体である。

　ディレクトリサーバ：
　ディレクトリサーバは、ＭＭＳ内の全ユーザ、グループ、組織そして役割のディレクトリを格納するＭＭＳ内の構成要素である。

　アプリケーションサーバ：
　アプリケーションサーバとは、ＭＭＳアプリケーションが載っているプラットフォームである。それは、アプリケーションが立脚する基礎となるサービス（例えば、Ｊ２ＥＥウェブとビーンコンテナ）を提供する。

　動作：
　動作とは、ユーザによりＭＭＳシステム内で実行される機能／操作である。これはまた、操作として参照される。

　フォルダ：
　フォルダとは、ＭＭＳ内で品目をグループ化する方法である。ＭＭＳは、媒体資産の仮想ファイルシステムとして考えられる。この内容で、フォルダは資産又は他のフォルダのリストを有するコンテナである。

　可視性：
　ＡＳＰ環境における可視性の概念を理解することは大切である。通常、ＡＳＰ内で、組織は、他組織の可視性（見える）を有していない。ＭＭＳの場合、組織はお互いの可視性が許されており、そして、組織間の協力及び媒体の共用ができるために、確かにそれを必要とする。デフォルトにより、組織は（そして全ての関連資源）ＭＭＳ内の他組織に対して可視ではない。この可視性は、組織間作業実施を可能にする（関係は、暗黙より明確であるが）ために変更できる。

本発明の全体配置図である。 ユーザ／アプリケーションサーバの相互作用図である。 セキュリティ機構のディレクトリ構造を説明するための図である。 セキュリティ機構のディレクトリ構造を説明するための図である。 セキュリティ機構のディレクトリ構造を説明するための図である。 セキュリティ機構のディレクトリ構造を説明するための図である。 グループ、ユーザやメンバ、役割及びテンプレートの関係を説明するための図である。 セキュリティ機構のチェックのフローを説明するためのフローチャートである。 セキュリティ機構のチェックのフローを説明するためのフローチャートである。 セキュリティ機構のチェックのフローを説明するためのフローチャートである。 システムの実行者を説明するための図である。 セキュリティ機構の全体構成図である。 ユーザのパスワード変更のフローチャートである。

符号の説明

　２　データベース、４　データライブラリ、６　データファイル、８　組織、１０　外部ネットワーク、１２　メンバ、１４　セキュリティ機構

Claims (19)

1. 　複数のデータライブラリを蓄積するデータベースと、
   　前記データベースのデータライブラリに対するデータの蓄積を制御するとともに、前記データに対しそれぞれ１人又は複数人のメンバを有した複数の外部組織からのアクセスを許可するインタフェースとを備え、
   　前記インタフェースは、前記組織のメンバの前記データに対するアクセスを制御するセキュリティ機構を有することを特徴とするデータ管理システム。
2. 　複数のデータライブラリを含む共通データベースへのアクセスを１人又は複数人のメンバを有した各外部組織に許可するデータベースアクセス方法において、
   　前記組織のメンバの前記データに対するアクセスを制御するセキュリティ機構のステップを有することを特徴とするデータベースアクセス方法。
3. 　複数のデータライブラリを蓄積するデータベースと共に使われるセキュリティ機構において、
   　当該セキュリティ機構は、異なる外部組織と前記データライブラリのデータとのインタフェースを司り、各組織は１人又は複数人のメンバを有し、当該セキュリティ機構は、前記異なる組織のメンバの前記データライブラリのデータに対するアクセスを制御することを特徴とするセキュリティ機構。
4. 　前記組織は、それぞれのデータ蓄積／通信システムを操作し、前記データベースに対する外部接続を含むことを特徴とする請求項１に記載のデータ管理システム。
5. 　前記データ蓄積／通信システムは、前記それぞれのシステムに対するそれぞれの管理者権を含むことを特徴とする請求項４に記載のデータ管理システム。
6. 　前記メンバの前記データに対するアクセスは、少なくとも前記データの読出、書込及び編集を含むことを特徴とする請求項１、４又は５に記載のデータ管理システム。
7. 　前記データライブラリは、それぞれ異なる所有者であることを特徴とする請求項１、請求項４乃至６のいずれか１項に記載のデータ管理システム。
8. 　１つ又は複数の前記データライブラリは、各組織によって所有されていることを特徴とする請求項１、請求項４乃至７のいずれか１項に記載のデータ管理システム。
9. 　前記セキュリティ機構は、前記データに対するアクセスを含む前記データベースに関連する機能の操作の要求を前記メンバに許可することを特徴とする請求項１、請求項４乃至８のいずれか１項に記載のデータ管理システム。
10. 　前記１つの組織のメンバが１つの機能を要求するとき、前記セキュリティ機構は、そのメンバのＩＤが認証されることを要求することを特徴とする請求項９に記載のデータ管理システム。
11. 　前記セキュリティ機構は、前記組織の各メンバに提供できる機能のリストを含み、前記１つの組織のメンバが１つの機能を要求するとき、前記セキュリティ機構は、要求された機能が前記メンバに提供できると判断されることを要求することを特徴とする請求項９又は１０に記載のデータ管理システム。
12. 　前記セキュリティ機構は、各組織に対して１つ又は複数の役割を含み、各役割は１つ又は複数の機能に関係し、前記役割での１つ又は複数の機能を操作する権限の与えられる前記組織の前記メンバを決定することを特徴とする請求項１１に記載のデータ管理システム。
13. 　前記セキュリティ機構は、１つ又は複数のテンプレートを含み、各テンプレートは、前記役割に対して決定された前記メンバに権限が与えられた前記１つ又は複数の機能を示すことができるように、前記複数のテンプレートに対するポインタを有した前記１つ又は複数の機能及び役割のリストを提供することを特徴とする請求項１２に記載のデータ管理システム。
14. 　前記セキュリティ機構は、各組織に対して各組織が見ることのできる他の全ての組織の表示を含み、前記１つの組織のメンバが１つの機能を要求するとき、前記セキュリティ機構は、その機能は前記メンバの組織には見えない組織によって所有されているデータライブラリのデータにアクセスすることを要求しないと判断されることを要求することを特徴とする請求項９乃至１３のいずれか１項に記載のデータ管理システム。
15. 　前記セキュリティ機構は、それに関連した機能の各目標に対し、１つ又は複数の認証を与え、その認証は限られたメンバによって操作される限られた機能を司り、前記１つの組織のメンバが１つの機能を要求するとき、前記セキュリティ機構は、前記要求された機能及びメンバは、前記機能の目標の認証の中に含まれると判断されることを要求することを特徴とする請求項９乃至１４のいずれか１項に記載のデータ管理システム。
16. 　前記セキュリティ機構が複数の目標に各機能を許可することを特徴とする請求項９乃至１５のいずれか１項に記載のデータや管理システム。
17. 　前記認証は限られた機能を限られたメンバによりそれぞれのデータファイル上で操作されるようになされ、前記１つの組織のメンバがデータファイル上の１つの機能を要求するとき、前記セキュリティ機構は、前記要求された機能及びメンバは、前記データファイルの認証の中に含まれると判断されることを要求することを特徴とする請求項１、請求項４乃至１６のいずれか１項に記載のデータ管理システム。
18. 　コンピュータプログラム製品において、
    　当該コンピュータプログラム製品がコンピュータ上で稼動するとき、請求項１乃至１７のいずれか１項に於ける全てのステップを実行するためのプログラムコードで構成されることを特徴とするコンピュータプログラム製品。
19. 　コンピュータプログラム製品において、
    　当該コンピュータプログラム製品がコンピュータ上で稼動するとき、請求項１乃至１７のいずれか１項に於ける全てのステップを実行するためのコンピュータで読出可能な媒体に蓄積されたプログラムコードで構成されることを特徴とするコンピュータプログラム製品。
    

Images