JP6894985B2 - データストレージシステムへのユーザアクセスを制御するための方法、装置、及びシステム - Google Patents

Description

本開示は、複数のデータストレージリソースを提供する１又は複数のノードを含むデータストレージシステムへのユーザアクセスを、特に役割ベースアクセス制御（ＲＢＡＣ）に基づいて制御するための方法、装置、及びシステムに関する。

コンピュータ向けのバックアップシステムは良く知られている。バックアップシステムはデータの冗長な記憶を提供し、そのためコンピュータ上のデータの喪失を生じさせる事象の後でコンピュータを前の状態に復元することができる。当業者なら理解されるように、コンピュータ上に記憶されるデータは非常に貴重である可能性があり、データの喪失は著しい経済的困難を生じさせる場合がある。

銀行、株式仲買、及び他の企業は一般に大量のデータをコンピュータ上に記憶する。このデータはそれらの事業の日々の運営に不可欠である。例えば銀行の通常の業務取引を促進するために、一般にコンピュータ内に記憶される銀行口座の記録が必要であることは容易に理解することができる。

火災、地震、盗難、及びハードディスクの故障等の事象は貴重なコンピュータデータが喪失することを引き起こし得る。企業のデータの唯一の複製が影響を受けたコンピュータ上に記憶されていた場合、その喪失は永続的である可能性があり、壊滅的な結果をもたらす可能性がある。

しかし、データが前もってバックアップされている場合は、データを復元することができ、そのため事業の普段の運営が最小限の中断を伴って継続し得る。従って、コンピュータ上に記憶されているデータをバックアップすることは必要だと考えられており、一般に決まった作業になっている。

バックアップシステムは典型的にはリポジトリ、及びリポジトリを駆動するソフトウェアを含む。ソフトウェアは、コンピュータからリポジトリの媒体にデータの全て又は一部を複製するように構成される。様々な異なる種類のリポジトリが広く使用されている。より少ないデータ記憶要件で、ローカルバックアップドライブ及びデジタル仮想デバイス（ＤＶＤ又はＤＶＤ ＲＯＭ）リポジトリが一般に使用されており、大容量のデータ記憶要件で、テープストレージ又は大容量ディスクドライブがコンピュータ上で又はネットワーク内で使用されている。

コンピュータのネットワーキングは、しばらくの間は、複数のコンピュータのための中央データ記憶位置を提供することによってバックアッププロセスを単純化した。つまり数台のクライアントコンピュータがサーバに共通して接続され、クライアントコンピュータによって使用されるデータの全てがサーバによって中央位置内に記憶された。従って、クライアントコンピュータの全てによって使用されるデータを十分保護するために単一のサーバのみをバックアップする必要があった。

しかしクライアントコンピュータのデータ記憶容量は増加し続け、ネットワーク上のクライアントの数も増加し、クライアントコンピュータによって必要とされる大量のデータは、帯域幅の制約がクライアントコンピュータのデータアクセスを制限するサーバにおいてではなく、クライアントコンピュータ自体に記憶することが結局はより実用的になった。従って、複数のクライアントコンピュータをバックアップしなければならないことに再び直面している。

追加の法的要件及び法定要件も規制によって政府機関により整備されており、地方都市及び州の条例でさえデータをアーカイブ及び保存しなければならない期間並びにアーカイブ及び保存しなければならないデータの種類について要件を設けている。例えば金融データは毎日アーカイブし、７年間記憶しなければならない場合があるのに対し、法的データは毎週アーカイブし、５年間記憶しなければならない。従って現代のネットワークでは、複数のクライアント更にはクライアントコンピュータ上の位置から、複数の異なる位置にある複数の異なるリポジトリのうちの選択されたものにデータがバックアップされ得る。

従来のバックアップソリューションは、非常に粒度の細かいレベルで特定のデータを長期記憶用に設計された特定のリポジトリ上の特定の位置に保存するためのポリシを手動で設定する能力を情報技術管理者（ＩＴ管理者）に与えることによってこれらの問題の一部に対処しようと試みた。不都合なことに、所与の任意のクライアント上に何種類のデータがあるのか、データの各種類に対してある規制の数、データをアーカイブしなければならない頻度、及びデータを要件に基づいてアーカイブするのに最適な位置を理解したらこのプロセスは非常に冗長であり非常に実際的でない。

従って、粒度の細かいレベルでも閲覧する能力を有するシステムビューを可能にする視覚的な方法で、ポリシを用いてリポジトリへのデータ経路内でデータソースを確立する能力を与える中央コマンドモジュールを有する統合データ管理システムをＩＴ管理者が得ることが望ましい。

加えて、役割ベースアクセス制御（ＲＢＡＣ）は、ユーザアクセスが制御されるアクセス制御のための（即ち許可の確認又はアクセス承認プロセスに基づいてデータ構造及び／又はデータリソースへのアクセスを許可し又は拒否することを含むアクセスを制御するための）スキームとして知られている。

例えば米国特許第２００８／００２２３７０ Ａ１号明細書は、コンテンツ管理システムにおける役割ベースアクセス制御（ＲＢＡＣ）のためのシステム及び方法に関し、ストレージリソースに保護クラスが割り当てられる。同じ保護クラス内のストレージリソースは同じアクセス制御ポリシを共用する。様々な役割に付与される許可は特権セット及び保護クラスに基づいて定められる。役割の許可は実行時に動的に決定され得る。更に、新たなストレージリソースが追加されるとき、それらのストレージリソースに既存の保護クラスを割り当てることができる。従って、新たなストレージリソースは保護クラスに付加される様々な許可及び役割を自動で継承することができる。

更に米国特許第２００８／０１２０３０２ Ａ１号明細書は、記憶管理のためのリソースレベルの役割ベースアクセス制御（ＲＢＡＣ）に関する。複数の役割のそれぞれに関する役割識別情報及び操作識別情報に関連して、ネットワークストレージシステムのための役割ベースアクセスデータベース内にリソース識別情報が記憶される。操作識別情報は複数の役割のそれぞれについて１又は複数の承認済みの操作を示し、リソース識別情報はネットワークストレージシステムによって維持される特定のリソースを識別する。ネットワークストレージシステムによって維持されるリソースにアクセスするためのネットワーク記憶クライアントからの要求を許可するか拒否するかを決定するために、役割ベースアクセスデータベース内の役割識別情報、役割の少なくとも１つについて１又は複数の承認済みの操作を示すデータ、及びリソース固有の識別情報が使用される。

複数の記憶資源のデータストレージシステムにおいて、様々な許可レベル及びユーザの種類のユーザアクセス又はアクセス許可を構成する際に非常に柔軟且つ効率的であるユーザアクセス制御メカニズムを提供すること、及びデータストレージシステム内で、とりわけ、データ保護目的に基づいて、正データ構造及びかかる正データ構造に関係する副データ構造を管理するデータストレージシステム内で特に好ましくは役割ベースアクセス制御（ＲＢＡＣ）に基づいて、アクセス制御を行う高信頼且つ効率的な方法を提供することが目的である。

請求項１に係る、複数のデータストレージリソースを提供する１又は複数のノードを含むデータストレージシステムへのユーザアクセスを制御するための方法が提案される。更に、請求項１７に係るデータストレージシステム、及び請求項１８に係るコンピュータプログラム製品が提案される。従属請求項は好ましい例示的実施形態に関する。

一部の態様によれば、複数のデータストレージリソースを提供する１又は複数のノードを含むデータストレージシステムへのユーザアクセスを制御するための方法が提案される。

一部の例示的態様によれば、複数のデータストレージリソースは、１又は複数のユーザアクセス可能な正データ構造及び／１又は複数のユーザアクセス可能な副データ構造を記憶してもよい。副データ構造の一部又はそれぞれは、それぞれの関連正データ構造に基づいて記憶され及び／又は作成されてもよい。

一部の例示的態様では、データストレージシステムは、幾つかの副データ構造又はそれぞれの副データ構造について、それぞれの副データ構造の親データストレージリソース及びオーナデータストレージリソースを示すデータ構造メタデータを記憶してもよい。本明細書では、それぞれの副データ構造の親データストレージリソースは好ましくはそれぞれの副データ構造を記憶するデータストレージリソースであり、及び／又はそれぞれの副データ構造のオーナデータストレージリソースは好ましくはそれぞれの副データ構造のそれぞれの関連正データ構造を記憶するデータストレージリソースである。

一部の例示的態様では、データ記憶システムが、１又は複数のユーザアカウントのそれぞれについて（及び／又は１又は複数のユーザ役割のそれぞれについて、各ユーザアカウントは少なくとも１つのユーザ役割に関連する）、それぞれのユーザアカウント（及び／又はその関連するユーザ役割）に関連するユーザによるユーザアクセスが許可されている１又は複数のデータストレージリソースの少なくとも１つのリソースグループを、示すアクセス制御情報を更に記憶してもよい。

一部の態様によれば、この方法は、それぞれの親データストレージリソース上に記憶される１又は複数の副データ構造の特定の副データ構造にアクセスするためのユーザ要求を受信し、特定の副データ構造について記憶されるデータ構造メタデータに基づいて、特定の副データ構造の個々のオーナデータストレージリソースを決定し、アクセス制御確認プロセスに基づいて、ユーザ要求に関連付けられたユーザアカウント（及び／又はユーザ役割）のユーザが特定の副データ構造にアクセスすることを許可されている否かを判定することを含んでもよい。

一部の例示的態様では、アクセス制御確認プロセスは、アクセス制御情報に基く、特定の副データ構造の決定されたオーナデータストレージリソースがユーザ要求に関連付けられたユーザアカウント（及び／又はユーザ役割）のユーザによってアクセスされることを許可されているか否かの判定を含んでもよい。

一部の例示的態様では、この方法は、ユーザ要求に関連付けられたユーザアカウント（及び／又はユーザ役割）のユーザが特定の副データ構造にアクセスすることを許可されているとアクセス制御確認プロセスが決定した場合、受信されるユーザ要求に基づいて（又は従って）１又は複数の副データ構造の特定の副データ構造にアクセスし、及び／又はユーザ要求に関連付けられたユーザアカウント（及び／又はユーザ役割）のユーザが特定の副データ構造にアクセスすることを許可されていないとアクセス制御確認プロセスが決定した場合、受信されるユーザ要求に基づいて（又は従って）１又は複数の副データ構造の特定の副データ構造にアクセスするのを控えることを更に含んでもよい。

一部の例示的態様では、データストレージシステムが、ユーザ要求を受信するように構成されるユーザインタフェースコントローラを更に含んでもよい。

一部の例示的態様では、データストレージシステムが１又は複数のリソースハンドリングコントローラを更に含んでもよく、各リソースハンドリングコントローラは、好ましくはデータストレージシステムの１又は複数のデータストレージリソースへのユーザアクセスを管理するように構成されてもよい。

好ましくは、ユーザインタフェースコントローラは、例えば１つ又は複数のリソースハンドリングコントローラの１、複数、又は全てにアクセス要求を送信するために、１又は複数のリソースハンドリングコントローラの１、複数、又は全てと通信するように構成される。一部の例示的態様では、リソースハンドリングコントローラは互いに直接通信するように及び／又はユーザインタフェースコントローラを介して間接的に通信するように構成されてもよい。

例えば、特定のデータストレージリソース上に記憶される正データ構造に例えばユーザセッション中にアクセスするためにユーザがログインする場合、そのユーザの正データ構造に対するユーザアクセス要求が、ユーザインタフェースコントローラからそれぞれの正データ構造を記憶する特定のデータストレージリソースを管理するそれぞれのリソースハンドリングコントローラに転送され又は中継される（又は概して最初に受信された要求を修正する場合もしない場合もある、対応するユーザ要求として送信される）ようにユーザインタフェースコントローラにおいて受信されてもよい。

或いは、ユーザインタフェースコントローラはセッション開始時のセッションのセットアップ（例えばユーザ認証及び／又はユーザ承認の処理を含む）を依然として担ってもよいが、後のユーザ要求はそれぞれの正データ構造を記憶する特定のデータストレージリソースを管理するそれぞれのリソースハンドリングコントローラに直接送信されてもよい。

更に、例えば特定のデータストレージリソース上に記憶される正データ構造に例えばユーザセッション中にアクセスするためにユーザがログインするが、異なるリソースハンドリングコントローラによって管理されてもされなくてもよい別のデータストレージリソース上に記憶されるその個々の正データ構造に関連する副データ構造にアクセスしようと試み得る場合、そのユーザの副データ構造に対するユーザアクセス要求が、ユーザインタフェースコントローラからそれぞれの副データ構造を記憶する特定のデータストレージリソースを管理するそれぞれのリソースハンドリングコントローラに転送され又は中継される（又は概して最初に受信された要求を修正する場合もしない場合もある、対応するユーザ要求として送信される）ようにユーザインタフェースコントローラにおいて受信されてもよい。

或いは、ユーザインタフェースコントローラはセッション開始時のセッションのセットアップ（例えばユーザ認証及び／又はユーザ承認の処理を含む）を依然として担ってもよいが、それぞれの副データ構造に対する後のユーザ要求は、それぞれの正データ構造を記憶する特定のデータストレージリソースを管理するそれぞれのリソースハンドリングコントローラに、及び／又はそれぞれの副データ構造を記憶する特定のデータストレージリソースを管理するそれぞれのリソースハンドリングコントローラに直接送信されてもよい。

例えば、それぞれの副データ構造に対するユーザ要求がそれぞれの関連正データ構造を記憶する特定のデータストレージリソースを管理するリソースハンドリングコントローラにおいて受信される場合、それぞれの副データ構造を記憶する特定のデータストレージリソースを管理するそれぞれのリソースハンドリングコントローラが異なるリソースハンドリングコントローラである場合、受信される要求は、それぞれの正データ構造を記憶する特定のデータストレージリソースを管理するそれぞれのリソースハンドリングコントローラから、それぞれの関連服データ構造を記憶する特定のデータストレージリソースを管理するそれぞれのリソースハンドリングコントローラに転送され又は中継されてもよい（又は概して最初に受信された要求を修正する場合もしない場合もある、対応するユーザ要求として送信されてもよい）。

一部の態様では、この方法は、セッションの開始時に（例えばユーザ要求に関連付けられたユーザアカウント（及び／又はユーザ役割）のユーザがユーザインタフェースコントローラに対する通信接続を開始するとき）、例えばアクセス制御情報に基づいて、それぞれのユーザアカウント（及び／又はユーザ役割）に関連するユーザによるユーザアクセスが許可されている１又は複数のデータストレージリソースの少なくとも１つのリソースグループを示すユーザアクセス制御プロファイルを、好ましくは得る承認プロセスを実行し、及び／又はそれぞれのユーザアカウント（及び／又はユーザ役割）に関連付けられたユーザのユーザアクセス制御プロファイルを示すペイロードを、好ましくはユーザインタフェースコントローラによって及び／又は承認モジュール若しくは承認装置によって作成することを更に含んでもよい。

ペイロードはそれぞれのユーザアクセス制御プロファイル情報を符号化形式及び／又は圧縮形式で含んでもよく、或いはそれぞれのユーザアクセス制御プロファイル情報を追加情報として、例えば追加の又は代替的なヘッダ情報として含んでもよい。

一部の態様では、この方法は、ユーザインタフェースコントローラにおいて特定の副データ構造にアクセスするためのユーザ要求を受信するとき、それぞれのユーザアカウント（及び／又はユーザ役割）に関連付けられたユーザのユーザ要求内に作成されたペイロードを含める（例えば追加する、符号化する、付加する、又は挿入する）ことを更に含んでもよい。

一部の態様では、この方法は、ユーザインタフェースコントローラから特定の副データ構造の親データストレージリソースへのアクセスを管理するリソースハンドリングコントローラに作成されたペイロードを含むユーザ要求を送信することを更に含んでもよい。

一部の態様では、各リソースハンドリングコントローラが、それぞれのリソースハンドリングコントローラによって管理される１又は複数のデータストレージリソース上に記憶される副データ構造に関係するデータ構造メタデータを管理するように更に構成されてもよい。

例えばリソースハンドリングコントローラは、そのそれぞれのリソースハンドリングコントローラによって管理される１又は複数のデータストレージリソース上に記憶される副データ構造に関係するデータ構造メタデータをそれぞれのリソースハンドリングコントローラのメタデータストレージセクション内で管理し記憶してもよい。

或いは、リソースハンドリングコントローラは、そのそれぞれのリソースハンドリングコントローラによって管理される１又は複数のデータストレージリソース上に記憶される副データ構造に関係するデータ構造メタデータを、そのそれぞれのリソースハンドリングコントローラによって管理されるそれぞれのデータストレージリソースに例示的に記憶してもよい。例えばリソースハンドリングコントローラは、特定の副データ構造に関係するデータ構造メタデータを、それぞれの特定の副データ構造を記憶するデータストレージリソースに、例えば特定の副データ構造に関係するデータ構造メタデータを特定の副データ構造と共に又は特定の副データ構造の一部としてそれぞれのデータストレージリソース上に記憶することによって例示的に記憶してもよい。

一部の態様では、この方法は、特定の副データ構造の親データストレージリソースへのアクセスを管理するリソースハンドリングコントローラにおいて、作成されたペイロードを含むユーザ要求を受信することを更に含んでもよい。好ましくは、特定の副データ構造の個々のオーナデータストレージリソースを決定し、及び／又はユーザ要求に関連するユーザアカウント（及び／又はユーザ役割）のユーザが、特定の副データ構造にアクセスすることを許可されているかどうかを判定することが、好ましくはそれぞれのリソースハンドリングコントローラによって管理されるデータ構造メタデータ及び／又は受信されるユーザ要求内に含まれるペイロードに基づいて、特定の副データ構造の親データストレージリソースへのアクセスを管理するリソースハンドリングコントローラによって実行される。

一部の態様では、ユーザ要求に関連するユーザアカウント（及び／又はユーザ役割）のユーザが特定の副データ構造にアクセスすることを許可されているかどうかを判定することは、特定の副データ構造の親データストレージリソースが、ユーザ要求に関連するユーザアカウント（及び／又はユーザ役割）のユーザによってアクセスされることを許可されているかどうかをアクセス制御情報に基づいて判定することに更に基づいてもよい。

一部の例示的態様では、この方法は、ユーザ要求に関連するユーザアカウント（及び／又はユーザ役割）のユーザが特定の副データ構造にアクセスすることを許可されている、及び／又はユーザ要求に関連するユーザアカウント（及び／又はユーザ役割）のユーザが特定の副データ構造の親データストレージリソースにアクセスすることを許可されているとアクセス制御確認プロセスが決定した場合、受信されるユーザ要求に基づいて（又は従って）１又は複数の副データ構造の特定の副データ構造にアクセスすること、及び／又はユーザ要求に関連するユーザアカウント（及び／又はユーザ役割）のユーザが特定の副データ構造にアクセスすることを許可されていない、及び／又はユーザ要求に関連するユーザアカウント（及び／又はユーザ役割）のユーザが特定の副データ構造の親データストレージリソースにアクセスすることを許可されていないとアクセス制御確認プロセスが決定した場合、受信されたユーザ要求に基づいて（又は従って）１又は複数の副データ構造の特定の副データ構造にアクセスするのを控えることを更に含んでもよい。

一部の例示的態様では、それぞれのユーザアカウント（及び／又はユーザ役割）に関連するユーザによるユーザアクセスがアクセス制御情報に従って許可されているリソースグループの中に特定の副データ構造のそれぞれの親データストレージリソースが含まれるという条件で、ユーザ要求に関連するユーザアカウント（及び／又はユーザ役割）のユーザは特定の副データ構造にアクセスすることが許可される（認められる）と決定されてもよい。

例えば、それぞれのユーザアカウント（及び／又はユーザ役割）に関連するユーザによるユーザアクセスがアクセス制御情報に従って許可されているリソースグループの中に特定の副データ構造のそれぞれの親データストレージリソースが含まれる、及び／又はそれぞれのユーザアカウント（及び／又はユーザ役割）に関連するユーザによるユーザアクセスがアクセス制御情報に従って許可されているリソースグループの中に特定の副データ構造のそれぞれのオーナデータストレージリソースが含まれるという条件で、ユーザ要求に関連するユーザアカウント（及び／又はユーザ役割）のユーザは特定の副データ構造にアクセスすることを許可される（認められる）と決定されてもよい。

一部の例示的態様では、アクセス制御情報が、それぞれのユーザアカウント（及び／又はユーザ役割）に許可されたアクセスの範囲を示す１又は複数のアクセスレベルを１つ又は複数のユーザアカウントのそれぞれについて（及び／又は１又は複数のユーザ役割のそれぞれについて、各ユーザアカウントは少なくとも１つのユーザ役割に関連する））更に示してもよい。

一部の例示的態様では、１又は複数のアクセスレベルは、（１）第１アクセスレベルに関連付けられたそれぞれのユーザアカウント（及び／又はユーザ役割）のユーザが、それぞれのユーザアカウント（及び／又はユーザ役割）に関連するユーザによるユーザアクセスがアクセス制御情報に従って、許可されているリソースグループの中にそれぞれのオーナデータストレージリソースが含まれている副データ構造に（例えばそれらの副データ構造だけに）それぞれの親データストレージリソース上でアクセスすることを許可されることを示し得る第１アクセスレベル、（２）とりわけそれぞれのユーザアカウント（及び／又はユーザ役割）に関連するユーザによるユーザアクセスがアクセス制御情報に従って、許可されているリソースグループの中に関連するそれぞれのオーナデータストレージリソースが含まれるという条件で、第２アクセスレベルに関連付けられたそれぞれのユーザアカウント（及び／又はユーザ役割）のユーザが、それぞれのユーザが現在ログインしているノードによって提供される１又は複数のオーナデータストレージリソースに関連する副データ構造に（例えばそれらの副データ構造だけに）それぞれの親データストレージリソース上でアクセスすることを許可されることを示し得る第２アクセスレベル、及び／又は（３）それぞれのユーザアカウント（及び／又はユーザ役割）に関連付けられたユーザによるユーザアクセスが、アクセス制御情報に従って、許可されているリソースグループの中に１又は複数の関連するそれぞれのオーナデータストレージリソースが含まれるかどうかに好ましくは関係なく、第３アクセスレベルに関連するそれぞれのユーザアカウント（及び／又はユーザ役割）のユーザが、それぞれの親データストレージリソース上に記憶される１又は複数の（例えば全ての）副データ構造にそれぞれの親データストレージリソース上でアクセスすることを許可されることを示し得る第３アクセスレベルのうちの少なくとも１つを含んでもよい。

一部の例示的態様では、アクセス制御情報が、１又は複数のユーザアカウント（及び／又はユーザ役割）のそれぞれについて、それぞれのユーザアカウント（及び／又はユーザ役割）に関連するユーザによるユーザアクセスが許可されているリソースグループのデータストレージリソースに対してそれぞれのユーザアカウント（及び／又はユーザ役割）に関連するユーザによって実行されることが許可されている少なくとも１つの許容ユーザ活動、及び／又は少なくとも１つの許容ユーザ活動を含む少なくとも１つの活動グループを更に示すことができる。

一部の例示的態様では、ユーザ要求に関連するユーザアカウント（及び／又はユーザ役割）のユーザが特定の副データ構造にアクセスすることを許可されているかどうかを判定することは、アクセス制御情報に基づいて、ユーザ要求によって要求されるそれぞれのユーザ活動がユーザ要求に関連するユーザアカウント（及び／又はユーザ役割）のユーザによって実行されることが許可されているかどうかを決定することに更に基づいてもよい。

一部の例示的態様では、受信したユーザ要求が、特定の副データ構造及び特定の副データ構造に対して行われる要求された活動を示してもよい。かかる状況において、一部の例示的態様では、この方法は、ユーザ要求によって要求されるそれぞれのユーザ活動がユーザ要求に関連するユーザアカウント（及び／又はユーザ役割）のユーザによって実行されることが許可され、且つユーザ要求に関連するユーザアカウント（及び／又はユーザ役割）のユーザが特定の副データ構造にアクセスすることが許可されていると決定された場合、特定の副データ構造に対して要求された活動を実行すること、及び／又はユーザ要求によって要求されるそれぞれのユーザ活動がユーザ要求に関連するユーザアカウント（及び／又はユーザ役割）のユーザによって実行されることが許可されていない、又はユーザ要求に関連するユーザアカウント（及び／又はユーザ役割）のユーザが特定の副データ構造にアクセスすることが許可されていないと決定された場合、特定の副データ構造に対して要求された活動を実行するのを控えることを更に含んでもよい。

一部の例示的態様では、アクセス制御情報がＲＢＡＣ（役割ベースアクセス制御）情報を含んでもよく、ＲＢＡＣ情報は、１又は複数のユーザアカウントのそれぞれについて、それぞれのユーザアカウントに関連するそれぞれのユーザのユーザ役割を更に示してもよい。

一部の例示的態様では、各ユーザ役割は、少なくとも１つの許容ユーザ活動、及び／又は少なくとも１つの許容ユーザ活動を含む少なくとも１つの活動グループに関連付けられていてもよい。

一部の例示的態様では、ユーザアクセス制御プロファイルは、それぞれのユーザアカウントに関連するユーザに関連するユーザ役割を更に示してもよく、及び／又は作成されたペイロードは、それぞれのユーザアカウントに関連するユーザに関連するユーザ役割を更に示してもよい。

一部の例示的態様では、作成済みのペイロードは、少なくとも１つの許容ユーザ活動、及び／又はそれぞれのユーザアカウントに関連するユーザに関連するそれぞれのユーザ役割に関連する少なくとも１つの許容ユーザ活動を含む少なくとも１つの活動グループを更に示してもよい。

一部の例示的態様では、各リソースハンドリングコントローラは、１又は複数のユーザ役割のそれぞれについて、それぞれのユーザ役割に関連する少なくとも１つの許容ユーザ活動、及び／又は少なくとも１つの許容ユーザ活動を含む少なくとも１つの活動グループを示し得る活動メタデータを管理するように更に構成されてもよい。

一部の例示的態様では、ユーザ要求に関連するユーザアカウント（及び／又はユーザ役割）のユーザが特定の副次データ構造にアクセスすることを許可されているかどうかを決定することは、それぞれのリソースハンドリングコントローラによって管理される活動メタデータ及び受信されるユーザ要求内に含まれるペイロードに基づき、ユーザ要求によって要求されるそれぞれのユーザ活動がユーザ要求に関連するユーザアカウント（及び／又はユーザ役割）のユーザによって実行されることが許可されているかどうかを決定することに更に基づいてもよい。

一部の例示的態様では、データ構造メタデータは、データ構造ごとに、それぞれのデータ構造に関連する複数のテナントの１つを示してもよく、及び／又はアクセス制御情報は、１又は複数のユーザアカウントのそれぞれについて、それぞれのユーザアカウントに関連する複数のテナントの１つを示してもよい。

一部の例示的態様では、ユーザ要求に関連するユーザアカウントのユーザが特定の副データ構造にアクセスすることを許可されているかどうかを決定することは、アクセス制御情報及び特定の副データ構造のデータ構造メタデータに基づき、特定の副データ構造に関連するテナントがそれぞれのユーザアカウントに関連するテナントと一致するかどうかを決定することに更に基づいてもよい。

一部の例示的態様では、この方法は、特定の副データ構造に関連するテナントがそれぞれのユーザアカウント（及び／又はユーザ役割）に関連するテナントと一致するとアクセス制御確認プロセスが決定した場合、受信されたユーザ要求に基づいて（又は従って）１又は複数の副データ構造の特定の副データ構造にアクセスすること、及び／又は特定の副データ構造に関連するテナントがそれぞれのユーザアカウント（及び／又はユーザ役割）に関連するテナントと一致しないとアクセス制御確認プロセスが決定した場合、受信されたユーザ要求に基づいて（又は従って）１又は複数の副データ構造の特定の副データ構造にアクセスするのを控えることを更に含んでもよい。

一部の態様によれば、複数のデータストレージリソースを提供する１又は複数のノードを含むデータストレージシステムが更に提案され、複数のデータストレージリソースは１又は複数のユーザアクセス可能正データ構造及び１又は複数のユーザアクセス可能副データ構造を記憶するように構成され、各副データ構造はそれぞれの関連正データ構造に基づいて記憶され、このデータストレージシステムは、副データ構造ごとに、それぞれの副データ構造の親データストレージリソース及びオーナデータストレージリソースを示すデータ構造メタデータを記憶するように構成され、それぞれの副データ構造の親データストレージリソースは、それぞれの副データ構造を記憶するデータストレージリソースであり、それぞれの副データ構造のオーナデータストレージリソースはそれぞれの副データ構造のそれぞれの関連正データ構造を記憶するデータストレージリソースであり、このデータストレージシステムは、１又は複数のユーザアカウントのそれぞれについて、それぞれのユーザアカウントに関連するユーザによるユーザアクセスが許可されている１又は複数のデータストレージリソースの少なくとも１つのリソースグループを示すアクセス制御情報を記憶するように更に構成される。

一部の態様では、データストレージシステム又はデータストレージシステムの１又は複数のノードは、それぞれの親データストレージリソース上に記憶される１又は複数の副データ構造の特定の副データ構造にアクセスするためのユーザ要求を受信すると、特定の副データ構造について記憶されるデータ構造メタデータに基づいて、特定の副データ構造の個々のオーナデータストレージリソースを決定すること、及び／又は、アクセス制御情報に基づいて、特定の副データ構造の決定されたオーナデータストレージリソースが、ユーザ要求に関連するユーザアカウントのユーザによってアクセスされることを許可されているかどうかを決定することを含む判定するアクセス制御確認プロセスに基づいて、ユーザ要求に関連するユーザアカウントのユーザが特定の副データ構造にアクセスすることを許可されているかどうかを決定する決定することを実行するように構成されてもよい。

更に一部の態様では、データストレージシステムは、上記の（及び／又は下記の）態様の１又は複数に従って構成してもよく、及び／又は上記の（及び／又は下記の）方法の態様のうちの１又は複数の１又は複数のステップを実行するように構成してもよい。

一部の態様によれば、複数のデータストレージリソースを提供する１又は複数のノードを含むデータストレージシステムへのユーザアクセスを制御するためのコンピュータプログラム製品が更に提案される。データストレージシステムは上記の態様の１又は複数によって提供することができる。

一部の態様では、コンピュータプログラム製品は、例えばそれぞれの親データストレージリソース上に記憶された１又は複数の副データ構造の特定の副データ構造にアクセスするためのユーザ要求を受信すると、特定の副データ構造について記憶されているデータ構造メタデータに基づいて特定の副データ構造の個々のオーナデータストレージリソースを決定すること、及び／又は、アクセス制御情報に基づいて、特定の副データ構造の決定されたオーナデータストレージリソースが、ユーザ要求に関連するユーザアカウントのユーザによってアクセスされることを許可されているかどうかを決定することを含む判定するアクセス制御確認プロセスに基づいて、ユーザ要求に関連するユーザアカウントのユーザが特定の副データ構造にアクセスすることが許可されているかどうかを決定することを実行させることを、少なくとも１個のプロセッサを有する装置若しくはシステム上で実行されるとき又はかかる装置若しくはシステム内にロードされたときに、少なくとも１個のプロセッサに行わせるコンピュータ可読プログラム命令を含んでもよい。

更に一部の態様では、コンピュータプログラム製品は、例えばそれぞれの親データストレージリソース上に記憶される１又は複数の副データ構造の特定の副データ構造にアクセスするためのユーザ要求を受信すると、上記の（及び／又は下記の）方法の態様のうちの１又は複数の１又は複数のステップを実行することを、少なくとも１個のプロセッサを有する装置若しくはシステム上で実行されるとき又はかかる装置若しくはシステム内にロードされたときに少なくとも１個のプロセッサに行わせるコンピュータ可読プログラム命令を含んでもよい。

特定の例示的態様を上記で説明してきたが、上記の段落の中で記載したものに加えて他の様々な変更、組み合わせ、省略、修正、及び置換が可能なので、それらの態様は広範な発明の限定ではなく例示に過ぎず、例示的態様は図示の及び上記で説明した特定の仕組み及び構成に限定されないことを理解すべきである。

ちょうど記載した態様の様々な適合、修正、及び／又は組み合わせを構成できることを当業者なら理解されよう。従って、本明細書で具体的に記載する以外の更なる態様を実践できることを理解すべきである。例えば別段の定めがない限り、本明細書に記載するプロセスのステップは本明細書に記載するのと異なる順序で実行してもよく、１又は複数のステップを組み合わせる、分割する、又は同時に実行してもよい。

本開示に鑑みて、本明細書に記載の様々な態様を組み合わせて本開示の他の態様を形成できることも当業者なら理解されよう。

図１Ａは、例示的実施形態に係るデータシステムの概略図を例示的に示す。 図１Ｂは、例示的実施形態に係る別のデータシステムの概略図を例示的に示す。 図１Ｃは、例示的実施形態に係る別のデータシステムの概略図を例示的に示す。 図２は、いくつかの例示的実施形態に係るユーザ認証処理のためのプロセスのフローチャートを例示的に示す。 図３は、いくつかの例示的実施形態に係るユーザ承認処理のためのプロセスのフローチャートを例示的に示す。 図４は、いくつかの例示的実施形態に係るユーザとユーザに関係するアクセス制御プロファイルとの間の関連付け、及びアクセス制御プロファイル情報の関連付けの一例を例示的に示す。 図５Ａは、いくつかの例示的実施形態に係るＵＩＣにおけるＵＩＣアクセス要求処理のためのプロセスのフローチャートを例示的に示す。 図５Ｂは、いくつかの例示的実施形態に係るＵＩＣにおけるＵＩＣセッション管理処理のためのプロセスのフローチャートを例示的に示す。 図５Ｃは、いくつか他の例示的実施形態に係るＵＩＣにおけるＵＩＣアクセス要求処理のためのプロセスのフローチャートを例示的に示す。 図５Ｄは、いくつかの他の例示的実施形態に係るＵＩＣにおけるＵＩＣセッション管理処理のためのプロセスのフローチャートを例示的に示す。 図５Ｅは、いくつかの他の例示的実施形態に係るＵＩＣにおけるＵＩＣアクセス要求処理のためのプロセスのフローチャートを例示的に示す。 図６Ａは、いくつかの他の例示的実施形態に係るストレージハンドラにおけるストレージハンドラアクセス要求処理のためのプロセスのフローチャートを例示的に示す。 図６Ｂは、いくつかの他の例示的実施形態に係るストレージハンドラにおけるストレージハンドラアクセス要求処理のためのプロセスのフローチャートを例示的に示す。 図７は、例示的なデータストレージシステムにおけるデータ構造の分布を例示的に示す。

以下、本発明の好ましい態様及び実施形態を添付図面を参照してより詳細に説明する。異なる図面及び実施形態の中の同じ又は同様の特徴は同様の参照番号によって示されている。様々な好ましい態様及び好ましい実施形態に関係する以下の詳細な説明は本発明の範囲を限定することを意図しないことを理解すべきである。

本明細書及び添付の特許請求の範囲で使用するとき、文脈上他の意味に解すべき場合を除き、以下の用語は示されている意味を有するものとする：

「ストレージデバイス」とは、データを記憶するために使用されるデバイス又はシステムである。ストレージデバイスは、１つ又は複数の磁気、若しくは光磁気、若しくは光ディスクドライブ、ソリッドステートストレージデバイス、又は磁気テープを含んでもよい。便宜上、ストレージデバイスは「ディスク」又は「ハードディスク」と呼ぶことがある。データストレージシステムは、同じ又は異なる記憶容量を有する同じ又は異なる種類のストレージデバイスを含み得る。

「ＲＡＩＤコントローラ」とは、幾つかのストレージデバイスの記憶容量を、「システムドライブ」（「ＳＤ」）、「論理ユニット」（「ＬＵ」又は「ＬＵＮ」）、又は「ボリューム」と代替的に呼ばれ得る仮想的な記憶空間の断片へと組み合わせるデバイス又はシステムである。典型的には、ＳＤは単一のストレージデバイスよりも大きく、幾つかのストレージデバイスから空間を取得し、一定数のディスクの故障にデータ喪失なしで耐えることができるように冗長情報を含む。例示的実施形態では、以下「論理ユニット識別子」又は「ＬＵＩＤ」と呼ばれる一意の識別子が各ＳＤに関連付けられ、各ＳＤは、例えば２ＴＢ〜６４ＴＢ又はそれ以上の所定の最大サイズよりも大きくない。

ＳＤにコマンドが送信されるとき、ＲＡＩＤコントローラは典型的にはそのコマンドをＳＤの全てのストレージデバイスに同時に転送する。ＲＡＩＤコントローラは、典型的なストレージデバイスの主な制約の３つ、つまり記ストレージデバイスが典型的にはストレージシステムの最も遅い構成要素であること、破局的故障を最も受けやすいこと、及び典型的には相対的に小さい記憶容量を有することを克服するのを助ける。

「ＲＡＩＤシステム」とは、１つ又は複数のＲＡＩＤコントローラ及び幾つかのストレージデバイスを含むデバイス又はシステムである。典型的には、ＲＡＩＤシステムは（一方が故障しても他方が機能し続けることができるように、更に両方が正常である間は負荷を共有するために）２つのＲＡＩＤコントローラ及び数ダースのストレージデバイスを含む。例示的実施形態では、ＲＡＩＤシステムは典型的には２から３２のＳＤで構成される。ファイルサーバがデータを記憶する又は取得する必要がある場合、ファイルサーバはＲＡＩＤシステムのＲＡＩＤコントローラにコマンドを送信し、次いでそれらのＲＡＩＤコントローラは個々のストレージデバイスにコマンドをルートし、必要に応じてデータを記憶し又は取得する役割を担う。

いくつかのＲＡＩＤシステムでは、ＳＤ間でミラー関係を確立することができ、それにより或るＳＤ（「主ＳＤ」と呼ぶ）に書き込まれるデータが、ＲＡＩＤシステムによって冗長性の目的で他のＳＤ（本明細書では「副ＳＤ」又は「ミラーＳＤ」と呼ぶ）に自動で書き込まれる。副ＳＤは、正ＳＤと同じＲＡＩＤシステムによって又は異なるローカル若しくはリモートのＲＡＩＤシステムによって管理されてもよい。ＳＤのミラーリングは、ＳＤの或いは或る状況では可能性のある複数のＳＤの喪失又は破損からの回復を提供するために、ＳＤにわたるＲＡＩＤ１＋０機能を効果的に提供する。

「ファイルシステム」とは、ファイルストレージシステム内に記憶されるファイル及びディレクトリ（フォルダ）の構造である。ファイルストレージシステム内で、ファイルシステムは典型的には多くの仮想記憶構造を使用して管理され、例示的実施形態では、ファイルシステムはレンジ、ストライプセット、及びスパンと呼ばれる仮想記憶構造の階層を使用して管理される。ファイルサーバのファイルシステム機能は、オブジェクト管理、空き領域管理（例えば割り当て）、及び／又はディレクトリ管理を含んでもよい。

「アーカイブ」とは、長期保持のために作成されるデータの複製又は部分的複製である。

「非同期的複製」の操作は、ストレージに書き込まれ、次いでバックアップ又は複製目的で宛先に送信されるデータトランザクションを指す。データトランザクションは、ネットワーク上で送信される及び／又は宛先に送信される前、メモリ内に保持される。更に、システム障害の場合にデータ喪失を防ぐために、トランザクションはログファイル内に保持されてもよい。トランザクションは、メモリから及び／又はログファイルから宛先に送信されてもよい。

「バックアップ」とは、運用回復及び／又は災害からの回復のために生成されるデータの複製又は部分的複製を指す。バックアップは、保護しようとする全データの完全な複製を表してもよく、又は前のバックアップ以降のデータの差異及び／又は変更を記憶する差分バックアップだけを表してもよい。更にバックアップは、例えば継続的データ保護（ＣＤＰ）、又は索引付けと共に若しくは索引付けなしでリポジトリが継続的にライブアップデートで更新されるライブバックアップによって継続的に処理されてもよい。更に、バックアップはバッチで、例えば周期的に処理されてもよく、バックアップはバッチにおいて作成される。バッチバックアップは、例えば前回のバックアップ以降の変更についてソースデータを走査することを含む、予定された再同期に従ってリポジトリを周期的に又は少なくとも繰り返し更新する操作を指してもよく、変更されたデータ、変更されたファイル、及び／又は変更されたバイトだけが記憶のために宛先に転送される。

「リポジトリ」は、例えばライブバックアップ、バッチバックアップ、バージョニング、及び／又はアーカイビングのためにソースノード（又はノードのソースクラスタ）から受信されるデータを記憶するノード（又はノードのクラスタ）であってもよい。バージョニングは、ファイル、ディレクトリ、及び／又はデータ部分のバージョンがその変更時に取られるデータ保護操作を指し得る（例えば文書がファイル内に保存されるたびに、別のバージョンが保持され索引付けされ、例えば変更履歴に従って複数世代のデータを作成する）。

例示的なシステムの概要
図１Ａは、例示的実施形態に係るデータシステムの概略図を例示的に示す。

図１Ａのデータシステムでは、複数のクライアント装置１００ａ及び１００ｂ（例えばホストコンピュータ）が通信ネットワークを介してウェブサーバ２００に例示的に接続されている。図１Ａのネットワークは有線通信ネットワーク（例えばＬＡＮ）又は無線通信ネットワーク（例えばＷＬＡＮ）としてそれぞれ実装してもよく、又はインターネット接続に代表されてもよく、又はいくつかの例示的実施形態では各通信ネットワークは直接通信接続（有線又は無線）で置き換えてもよい。

クライアント装置１００ａ及び１００ｂのユーザは、例えばＨＴＭＬインタフェース及び／又はＲＥＳＴインタフェース若しくは他のメッセージ転送プロトコルインタフェースを使用してウェブブラウザを介してウェブサーバ２００にアクセスしてもよく、及び／又は例えばＲＥＳＴインタフェース若しくは他のメッセージ転送プロトコルインタフェースを使用してＣＬＩ（コマンドラインインタフェース）を介してウェブサーバ２００にアクセスしてもよく、ウェブサーバ２００は、例えばクライアント装置１００ａ及び１００ｂのウェブブラウザに複数のウェブページ又は他の種類のＨＴＭＬ文書を提供してもよい。

他方で、図１Ａのデータシステム内のウェブサーバ２００は、別の通信ネットワークを介して（又は同じ通信ネットワークを介して）外部ストレージシステム９００に例示的に接続され、ウェブサーバ２００は、別の通信ネットワークを介して（又は同じ通信ネットワークを介して）ＵＩＣ（ユーザインタフェースコントローラ）装置３００に更に例示的に接続されている。

ＵＩＣ装置３００は、別の通信ネットワークによる別のネットワークを介して（又は同じ通信ネットワークを介して）管理コンピュータ８００、認証装置６００、及び承認装置７００に例示的に接続されている。

更にＵＩＣ装置３００は、別の通信ネットワークによる別のネットワークを介して（又は同じ通信ネットワークを介して）複数のストレージハンドラ装置４００ａ、４００ｂ、及び４００ｃ（リソースハンドリングコントローラ）に例示的に接続される。

例示的には、（第１の）ストレージハンドラ装置４００ａは、別の通信ネットワークによる別のネットワークを介して（又は同じ通信ネットワークを介して）複数のストレージノード５００ａ（例えば第１ソースノード）及び５００ｂ（例えば第１宛先ノード）に通信可能に接続される。更に例示的には、（第２の）ストレージハンドラ装置４００ｂは、別の通信ネットワークによる別のネットワークを介して（又は同じ通信ネットワークを介して）ストレージノード５００ｃ（例えば第２ソースノード）に通信可能に接続され、ストレージノード５００ｃがストレージノード５００ｄ（例えば第２宛先ノード）に通信可能に接続される。

上記において、例示的にはストレージノードはデータを記憶するための１又は複数のストレージデバイスを提供する物理ストレージ装置としてもよい。更にストレージノードは、データを記憶するための１又は複数のストレージボリュームを提供する論理ストレージユニットであってもよい。更に他の例示的実施形態では、ストレージノードは統一記憶空間を提供する複数のクラスタノードを有するストレージクラスタを表してもよい。概して、ストレージノードはデータを記憶するための物理的な、論理的な、又は仮想的なストレージエンティティを表してもよい。

概して、ソースノードは管理されるデータを記憶するエンティティ又は機械（例えばサーバ、ワークステーション、又は仮想マシン）を表してもよい。ソースノードは、ホストの１又は複数のファイルシステムをモニタするように構成してもよく、ユーザが定めたデータ保護ポリシに従ってデータ保護操作を実行し開始するように構成してもよい。ソースノードはデータを記憶し、ローカルに記憶されたデータを転送し、又はデータ追跡、ブロッキング、若しくは監査機能を実施するように構成されてもよい。

宛先ノードは、複製構成内のデータの受け手として指定されているリポジトリ又は汎用システム等のデータを受信する（及び記憶する）ように構成されるエンティティ又は機械（例えばサーバ、ファイルサーバ、ワークステーション、又は仮想マシン）を表してもよい。

概して、データ保護ポリシはノード又はノードグールにマップされ、少なくともソースノード及び宛先ノードを定める構成可能な目標である。つまり抽象レベルでは、データ保護ポリシは、データ保護操作のソース（ソースノード）、ソースノードによって管理される保護しようとするデータ、及び管理されるデータに対して行われるデータ保護操作の宛先（宛先ノード）のうちの少なくとも１つを定める。

従ってデータ保護ポリシは、定められたソースノードと宛先ノードとの間のデータ経路によるデータ移動操作を更に定めてもよい。データ移動操作は、例えばミラー操作、複製操作、バックアップ操作（例えばバッチバックアップ及び／又はライブバックアップ）、スナップショット操作、アーカイブ操作、バージョニング操作の、ソースノードと宛先ノードとの間で行われるデータ保護操作の種類及び／又は方向、並びにデータの移動がバッチで行われるべきか（例えばバッチバックアップ）、継続的に行われるべきか（例えば継続的データ保護又はライブバックアップとして）、又はデータを同期的に、非同期的に、若しくはログファイル内にデータを一時的な記憶を伴っての非同期的に移動するのかを定めてもよい。

更に、データ保護操作のそれぞれについて、又は複数の並列若しくはチェーンデータ保護操作のグループについて、データ保護ポリシはデータ保持時間（例えばデータ保護操作によって記憶されるデータがデータを受信する宛先ノードにおいて保持されるべき時間）、データ保護操作が行われるべき頻度、周期性、又は時間窓（例えば目標復旧ポイント等）等の更なるポリシ情報を含んでもよい。更に、追加の目的はどのデータを保護する必要があるのか（例えばファイルの種類、アプリケーションに対する関係に基づいて、ユーザグループ又は個々のユーザの素性に基づいて）、及び他の時間制約（例えばデータ保護操作を行うべきではない除外された時間窓等）を定めることができる。

図１Ａでは、例示的にはユーザはクライアント装置１００ａ又は１００ｂを介してデータストレージシステムにログインしてもよく、又は管理者は管理コンピュータ８００を介してデータストレージシステムにログインしてもよい。但しこの管理コンピュータ８００は任意であってよい。例えばいくつかの例示的実施形態では、（例えば「管理者」のユーザ役割が管理アクセス特権に関連付けられることで）管理アクセス特権を有するユーザがクライアント装置１００ａ又は１００ｂを介して管理者としてログインしてもよいという点で、各クライアント装置１００ａ又は１００ｂは管理コンピュータとして使用されてもよい。

管理コンピュータ８００（及び／又はユーザがクライアント装置１００ａ又は１００ｂを介して管理者としてログインする場合はクライアント装置１００ａ又は１００ｂ）は、データストレージシステムの設定、管理構成、及びポリシ（例えばデータ保護ポリシ）の変更を可能にするように構成されてもよい。

ＵＩＣ装置３００は、例えばストレージノード５００ａから５００ｄの１又は複数に記憶されるデータへの、更には外部ストレージシステム９００へのアクセス要求を管理するために、データストレージシステムに対するユーザアクセス対話を管理する（例えばユーザアクセス要求のルーティングを管理する）ように例示的に構成される。

従って例示的実施形態では、ＵＩＣ装置３００は、ウェブサーバ２００を介してユーザ用のユーザインタフェース（例えばグラフィカルユーザインタフェース／ＧＵＩ、又はコマンドラインインタフェース／ＣＬＩ）を介して通信するように例示的に構成されてもよい。例示的実施形態では、ユーザインタフェースは、ウェブサーバ２００上で又はウェブサーバ２００によってクライアントに提供されてもよい。他の実施形態では、ユーザインタフェースは、ＵＩＣ装置３００によって直接又はウェブサーバ２００を介して間接的にクライアントに提供されてもよい。

ＵＩＣ装置３００は、クライアント装置１００ａ及び１００ｂ及び／又は管理コンピュータ８００のうちの１つからＵＩＣ装置３００において受信されるユーザアクセス要求をストレージハンドラ装置４００ａから４００ｃに通信するように構成される。特に、ＵＩＣ装置３００は、責任を負う１又は複数のストレージハンドラ装置４００ａ、４００ｂ、及び４００ｃにユーザアクセス要求をルートするように例示的に構成されてもよく、それらのストレージハンドラ装置は例示的にはそれぞれのユーザアクセス要求の実行を管理する。

各ストレージハンドラ装置４００ａ、４００ｂ、及び４００ｃは、ストレージノード５００ａから５００ｄ又は外部ストレージシステム９００によって提供されるデータストレージリソースを管理するように構成されてもよい。例えば各ストレージハンドラ装置４００ａ、４００ｂ、及び４００ｃ（リソースハンドリングコントローラ）は、データ記憶システムの１又は複数のストレージノード又は１又は複数のストレージノード上に設けられる１又は複数のストレージリソースを管理するように構成されてもよく、特に、データストレージシステムの各ストレージノード及び／又はストレージリソースは関連する１つのストレージハンドラ装置（リソースハンドリングコントローラ）によって管理され及び／又は制御されてもよい。

例えば図１Ａでは、ストレージハンドラ装置４００ａは、ストレージノード５００ａ及び５００ｂによって提供される１又は複数のデータストレージリソースを管理するように構成されてもよい一方、ストレージハンドラ装置４００ｂはストレージノード５００ｃ及び５００ｄによって提供される１又は複数のデータストレージリソースを管理するように構成されてもよい。

例示的には、データ保護操作は、記憶ノード５００ａから、ストレージハンドラ装置４００ａによって管理される、更にはストレージハンドラ装置４００ａによって複製される記憶ノード５００ｂに、データを複製することを含んでもよく、例示的にはデータ保護操作は、記憶ノード５００ｃから、ストレージハンドラ装置４００ｂによって管理される記憶ノード５００ｄにデータを複製することを含んでもよく、ストレージハンドラ装置４００ｂは記憶ノード５００ｄ（例示的にはストレージハンドラ装置４００ｂに直接接続されていない）にデータを複製するためにかかる複製操作が記憶ノード５００ｃによって実行されるように命令する。

更に例示的には、ストレージハンドラ装置４００ｃは、外部ストレージシステムによって提供される１又は複数のデータストレージリソースを管理するように構成されてもよい。

図１Ａでは、外部ストレージシステム９００は、ウェブサーバ２００に例示的に接続される。他の例示的実施形態では、外部ストレージシステム９００は、ＵＩＣ装置３００、及び／又はストレージハンドラ装置４００ａから４００ｃの１又は複数にも接続されてもよい。

好ましくは、外部ストレージシステム９００へのアクセスの管理は、責任を負う１つ又は複数のストレージハンドラ装置４００ａから４００ｃによって管理されるが、ストレージハンドラ装置４００ａから４００ｃから外部ストレージシステム９００へのメッセージ又はアクセス要求は直接送信されてもよく、又はＵＩＣ装置３００及び／又はウェブサーバ２００を介してルートされてもよい。

例えば外部ストレージシステム９００への接続のために、責任を負うストレージハンドラは外部ストレージシステム９００と接続してもよい。

例えば外部ストレージシステム９００へのユーザ要求は、ウェブサーバ２００及びＵＩＣ装置３００を介してルートすることができ、及び／又は責任を負うストレージハンドラ装置は外部ストレージシステム９００と（例えば直接、又はＵＩＣ装置３００及び／又はウェブサーバ２００を介してルートされて間接的に）対話する。

一部の例示的実施形態では、外部ストレージシステム９００は、例えばウェブサーバ２００を介してではなく、ＵＩＣ装置３００及び／又は、１又は複数のストレージハンドラ装置に直接接続されてもよい。

図１Ｂは、例示的実施形態に係る別のデータシステムの概略図を例示的に示す。

図１Ｂのデータシステムでは、図１Ａと同様に、複数のクライアント装置１００ａ及び１００ｂ（例えばホストコンピュータ）が、通信ネットワークを介してウェブサーバ２００に例示的に接続される。

図１Ｂのデータシステム内のウェブサーバ２００は、別の通信ネットワークを介して（又は同じ通信ネットワークを介して）外部ストレージシステム９００に例示的に接続され、ウェブサーバ２００は別の通信ネットワークを介して（又は同じ通信ネットワークを介して）ストレージ管理装置１０００のＵＩＣ（ユーザインタフェースコントローラ）モジュール３０１に更に例示的に接続される。

例示的には、ストレージ管理装置１０００は、ＵＩＣモジュール３０１を含み、複数のストレージハンドラモジュール４０１ａから４０１ｃを更に含む。ＵＩＣモジュール３０１は、図１ＡのＵＩＣ装置３００と同様に機能してもよく及び／又はＵＩＣ装置３００と同様の処理機能を提供してもよい。ストレージハンドラモジュール４０１ａから４０１ｃは、図１Ａのストレージハンドラ装置４００ａから４００ｃと同様に機能してもよく、及び／又はストレージハンドラ装置４００ａから４００ｃと同様の処理機能を提供してもよい。

ストレージ管理装置１０００のＵＩＣモジュール３０１は、別の通信ネットワークによる別のネットワークを介して（又は同じ通信ネットワークを介して）管理コンピュータ８００、認証装置６００、及び承認装置７００に例示的に接続される。

更にＵＩＣモジュール３０１（ユーザインタフェースコントローラ）は、ストレージ管理装置１０００の環境内の複数のストレージハンドラモジュール４０１ａ、４０１ｂ、及び４０１ｃ（リソースハンドリングコントローラ）に例示的に通信可能に接続される。

例示的には、（第１）ストレージハンドラモジュール４０１ａは、別の通信ネットワークによる別のネットワークを介して（又は同じ通信ネットワークを介して）複数のストレージノード５００ａ（例えば第１ソースノード）及び５００ｂ（例えば第１宛先ノード）に通信可能に接続される。更に例示的には、（第２）ストレージハンドラモジュール４０１ｂは、別の通信ネットワークによる別のネットワークを介して（又は同じ通信ネットワークを介して）ストレージノード５００ｃ（例えば第２ソースノード）に通信可能に接続され、ストレージノード５００ｃがストレージノード５００ｄ（例えば第２宛先ノード）に通信可能に接続される。

図１Ｂでは、例示的にはユーザはクライアント装置１００ａ又は１００ｂを介してデータストレージシステムにログインすることができ、又は管理者はストレージ管理装置１０００に例示的に接続される管理装置８００を介してデータストレージシステムにログインすることができる。但し、このような管理コンピュータ８００は任意であってよい。例えば一部の例示的実施形態では、（例えば「管理者」のユーザ役割が管理アクセス特権に関連付けられることで）管理アクセス特権を有するユーザがクライアント装置１００ａ又は１００ｂによって管理者としてログインしてもよいという点で、各クライアント装置１００ａ又は１００ｂが管理コンピュータとして使用されてもよい。

管理装置８００（及び／又はユーザがクライアント装置１００ａ又は１００ｂによって管理者としてログインする場合はクライアント装置１００ａ又は１００ｂ）は、データストレージシステムの設定、管理構成、及びポリシ（例えばデータ保護ポリシ）の変更を可能にするように構成されてもよい。

ＵＩＣモジュール３０１は、例えばストレージノード５００ａから５００ｄの１又は複数に記憶されるデータへの、更には外部ストレージシステム９００へのアクセス要求を管理するために、データストレージシステムに対するユーザアクセス対話を管理する（例えばユーザアクセス要求のルーティングを管理する）ように例示的に構成される。

従って例示的実施形態では、ＵＩＣモジュール３０１は、ウェブサーバ２００を介してユーザ用のユーザインタフェース（例えばグラフィカルユーザインタフェース／ＧＵＩ、又はコマンドラインインタフェース／ＣＬＩ）を介して通信するように例示的に構成されてもよい。例示的実施形態では、ユーザインタフェースは、ウェブサーバ２００上で又はウェブサーバ２００によってクライアントに提供されてもよい。他の実施形態では、ユーザインタフェースは、ＵＩＣモジュール３０１によって直接又はウェブサーバ２００を介して間接的にクライアントに提供されてもよい。

ＵＩＣモジュール３０１は、クライアント装置１００ａ及び１００ｂ及び／又は管理装置８００のうちの１つからＵＩＣモジュール３０１において受信されるユーザアクセス要求をストレージハンドラモジュール４０１ａから４０１ｃに通信するように構成される。特に、ＵＩＣモジュール３０１は、責任を負う１又は複数のストレージハンドラモジュール４０１ａ、４０１ｂ、及び４０１ｃにユーザアクセス要求をルートするように例示的に構成されてもよく、それらのストレージハンドラモジュールは例示的にはそれぞれのユーザアクセス要求の実行を管理する。

各ストレージハンドラモジュール４０１ａ、４０１ｂ、及び４０１ｃは、ストレージノード５００ａから５００ｄ又は外部ストレージシステム９００によって提供されるデータストレージリソースを管理するように構成されてもよい。例えば各ストレージハンドラモジュール４０１ａ、４０１ｂ、及び４０１ｃ（リソースハンドリングコントローラ）は、データストレージシステムの１つ又は複数のストレージノード、又は１又は複数のストレージノード上に設けられる１又は複数のストレージリソースを管理するように構成されてもよく、特にデータストレージシステムの各ストレージノード及び／又はストレージリソースは関連する１つのストレージハンドラ装置（リソースハンドリングコントローラ）によって管理され及び／又は制御されてもよい。

例えば図１Ｂでは、ストレージハンドラモジュール４０１ａは、ストレージノード５００ａ及び５００ｂによって提供される１又は複数のデータストレージリソースを管理するように構成されてもよい一方、ストレージハンドラモジュール４０１ｂはストレージノード５００ｃ及び５００ｄによって提供される１又は複数のデータストレージリソースを管理するように構成されてもよい。

例示的には、データ保護操作は、ストレージノード５００ａから、ストレージハンドラモジュール４０１ａによって管理される、更にはストレージハンドラモジュール４０１ａによって複製されるストレージノード５００ｂにデータを複製することを含んでもよい、例示的にはデータ保護操作は、ストレージノード５００ｃからストレージハンドラモジュール４０１ｂによって管理されるストレージノード５００ｄにデータを複製することを含んでもよく、ストレージハンドラモジュール４０１ｂは記憶ノード５００ｄ（例示的にはストレージハンドラモジュール４０１ｂに直接接続されていない）にデータを複製するためにかかる複製操作がストレージノード５００ｃによって実行されることを命令する。

更に例示的には、ストレージハンドラモジュール４０１ｃは、外部ストレージシステムによって提供される１又は複数のデータストレージリソースを管理するように構成されてもよい。

従って図１Ａとの違いとして、図１Ｂによる例示的実施形態では、ＵＩＣモジュール３０１及びストレージハンドラモジュール４０１ａから４０１ｂが、図１Ａに例示的に示すように別個の装置として例示的に実装されるのではなく、同じストレージ管理装置１０００上に実装される。更なる例示的実施形態では、ＵＩＣモジュール３０１は、１つの装置上に実装することができ、ストレージハンドラモジュール４０１ａから４０１ｂを別の装置上に実装することができる。

概して、ＵＩＣ（ユーザインタフェースコントローラ）及びストレージハンドラ（リソースハンドリングコントローラ）は、ハードウェア（機械、ワークステーション、コンピュータ、サーバ、更には機械、ワークステーション、コンピュータ、サーバのクラスタ等を含む）によって、又はソフトウェアによって（例えば機械、ワークステーション、コンピュータ、サーバ、更には機械、ワークステーション、コンピュータ、サーバのクラスタ上で実行可能な別個の又は複合ソフトウェアモジュール等によって、又は分散クラウドサービスとしてさえ）、又はハードウェアとソフトウェアとの任意の組み合わせによって（例えば仮想マシンとして又は、１又は複数の仮想マシン上で実行されるもの等として）実装してもよい。

ストレージハンドラ（リソースハンドリングコントローラ）をソフトウェアモジュールとして提供することには、追加のストレージノード又はストレージシステムを追加して更なる管理可能なストレージリソースを提供する場合、その新たに追加したストレージリソースが１又は複数の過去に確立されたストレージハンドラモジュール（リソースハンドリングコントローラ）の１又は複数によって管理されるように割り当てられること、又は新たに追加したストレージリソースの１又は複数を管理するために１又は複数の新たなストレージハンドラモジュールを開始させ、作成させ、又はインストールさせることができることの利点がある。例えば一部の例示的実施形態では、新たに追加されたストレージリソースごとに及び／又は新たに追加されたストレージノードごとに、それぞれの新たに追加されたストレージリソースを管理するために及び／又は新たに追加されたストレージノードを管理するために、それぞれの新たなストレージハンドラモジュール（リソースハンドリングコントローラ）を開始させ、作成させ、又はインストールさせてもよい。

図１Ｂでは、外部ストレージシステム９００がウェブサーバ２００に例示的に接続されている。他の例示的実施形態では、外部ストレージシステム９００がストレージ管理装置１０００に接続されてもよい。

好ましくは、ストレージ記憶システム９００へのアクセスの管理は、責任を負う１又は複数のストレージハンドラモジュール４０１ａから４０１ｃによって管理されるが、ストレージハンドラモジュール４０１ａから４０１ｃから外部ストレージシステム９００へのメッセージ又はアクセス要求は直接送信されてもよく、又はＵＩＣモジュール３０１及び／又はウェブサーバ２００を介してルートされてもよい。

例えば外部ストレージシステム９００への接続のために、責任を負うストレージハンドラは外部ストレージシステム９００とインタフェースで接続してもよい。

例えば外部ストレージシステム９００へのユーザ要求は、ウェブサーバ２００及びＵＩＣモジュール３０１を介してルートすることができ、及び／又は責任を負うストレージハンドラモジュールが外部ストレージシステム９００と（例えば直接、又はＵＩＣモジュール３０１及び／又はウェブサーバ２００を介してルートされて間接的に）対話する。

一部の例示的実施形態では外部ストレージシステム９００が、例えばウェブサーバ２００を介してではなく、ＵＩＣモジュール３０１及び／又はストレージハンドラモジュールの１又は複数に直接接続され得る。

図１Ｃは、例示的実施形態に係る別のデータシステムの概略図を例示的に示す。

図１Ｃのデータシステムでは、図１Ａ及び図１Ｂと同様に複数のクライアント装置１００ａ及び１００ｂ（例えばホストコンピュータ）が通信ネットワークを介してウェブサーバ２００に例示的に接続され、ウェブサーバ２００は別の通信ネットワークを介して（又は同じ通信ネットワークを介して）外部ストレージシステム９００に例示的に接続され、ウェブサーバ２００は、別の通信ネットワークを介して（又は同じ通信ネットワークを介して）ストレージ管理装置１００１のＵＩＣ（ユーザインタフェースコントローラ）モジュール３０１に更に例示的に接続される。

例示的には、ストレージ管理装置１００１は、ＵＩＣモジュール３０１を含み、複数のストレージハンドラモジュール４０１ａから４０１ｃを更に含む。ＵＩＣモジュール３０１は、図１ＡのＵＩＣ装置３００及び図１ＢのＵＩＣモジュール３０１と同様に機能できてもよく及び／又は同様の処理機能を提供できてもよい。ストレージハンドラモジュール４０１ａから４０１ｃは、図１Ａのストレージハンドラ装置４００ａから４００ｃ及び図１Ｂのストレージハンドラモジュール４０１ａから４０１ｃと同様に機能してもよく及び／又はかかるストレージハンドラ装置４００ａから４００ｃ及びストレージハンドラモジュール４０１ａから４０１ｃと同様の処理機能を提供してもよい。

ストレージ管理装置１００１のＵＩＣモジュール３０１は、別の通信ネットワークによる別のネットワークを介して（又は同じ通信ネットワークを介して）管理モジュール８０１、認証モジュール６０１、及び承認モジュール７０１に例示的に接続され、それらのモジュールもストレージ管理装置１００１内に例示的に含まれる。

更にＵＩＣモジュール３０１（ユーザインタフェースコントローラ）は、図１Ｂの構成と同様にストレージ管理装置１００１の環境内の複数のストレージハンドラモジュール４０１ａ、４０１ｂ、及び４０１ｃ（リソースハンドリングコントローラ）に例示的に通信可能に接続される。

図１Ｃでは、例示的にはユーザはクライアント装置１００ａ又は１００ｂを介してデータ記憶システムにログインしてもよく、又は管理者はストレージ管理装置１００１の管理モジュール８０１を介してデータストレージシステムにログインしてもよい。一部の例示的実施形態では、（例えば「管理者」のユーザ役割が管理アクセス特権に関連付けられることで）管理アクセス特権を有するユーザがクライアント装置１００ａ又は１００ｂによって管理者としてログインしてもよいという点で、各クライアント装置１００ａ又は１００ｂが管理コンピュータとして使用されてもよい。

管理モジュール８０１（及び／又はユーザがクライアント装置１００ａ又は１００ｂによって管理者としてログインする場合はクライアント装置１００ａ又は１００ｂ）は、データストレージシステムの設定、管理構成、及びポリシ（例えばデータ保護ポリシ）の変更を可能にするように構成されてもよい。但しこの管理モジュール８０１は任意であってよい。例えば一部の例示的実施形態では、（例えば「管理者」のユーザ役割が管理アクセス特権に関連付けられることで）管理アクセス特権を有するユーザがクライアント装置１００ａ又は１００ｂによって管理者としてログインしてもよいという点で、各クライアント装置１００ａ又は１００ｂが管理コンピュータとして使用されてもよい。

管理モジュール８０１は、構成、設定、及びその変更を入力するためのユーザインタフェースを介して、例えば記憶管理装置１００１におけるＧＵＩ（グラフィカルユーザインタフェース）及び／又はＣＬＩ（コマンドラインインタフェース）を介して通信してもよい。例示的実施形態では、ユーザインタフェースはウェブサーバ２００上で又はウェブサーバ２００によってクライアントに提供されてもよい。他の実施形態では、ユーザインタフェースはＵＩＣモジュール３０１によって直接又はウェブサーバ２００を介して間接的にクライアントに提供されてもよい。

例えば管理モジュール８０１は、ウェブサーバ２００によってクライアント装置（複数も可）に提供されるグラフィカルユーザインタフェース及び／又はコマンドラインインタフェースによってアクセスされるように構成されてもよい。次いでユーザは、管理モジュール８０１にアクセスすることによって管理設定を変更するためにクライアント装置１００ａ又は１００ｂを介してデータストレージシステムにログインしてもよい。

管理モジュール８０１は、ソフトウェア及び／又はハードウェアによって提供されてもよい。一部の例示的実施形態では、管理モジュール８０１はＵＩＣモジュール３０１の一部であってもよく又はＵＩＣモジュール３０１に含まれてもよい。ＵＩＣモジュール３０１は、例えば記憶ノード５００ａから５００ｄの１又は複数に記憶されるデータへの、更には外部ストレージシステム９００へのアクセス要求を管理するために、データストレージシステムに対するユーザアクセス対話を管理するように例示的に構成される。

従って例示的実施形態では、ＵＩＣモジュール３０１は、それぞれのクライアント装置／コンピュータにおいてウェブサーバ２００を通して提供されるように、ユーザ用のユーザインタフェース（例えばグラフィカルユーザインタフェース／ＧＵＩ又はコマンドラインインタフェース／ＣＬＩ）をウェブサーバ２００を介して提供するように例示的に構成されてもよい。

ＵＩＣモジュール３０１は、クライアント装置１００ａ及び１００ｂ及び／又は管理モジュール８０１のうちの１つからＵＩＣモジュール３０１において受信されるユーザアクセス要求をストレージハンドラモジュール４０１ａから４０１ｃに通信するように構成される。

特に、ＵＩＣモジュール３０１は、責任を負う１つ又は複数のストレージハンドラモジュール４０１ａ、４０１ｂ、及び４０１ｃにユーザアクセス要求をルートするように例示的に構成されてもよく、それらのストレージハンドラモジュールは例示的にはそれぞれのユーザアクセス要求の実行を管理する。

各ストレージハンドラモジュール４０１ａ、４０１ｂ、及び４０１ｃは、ストレージノード５００ａから５００ｄ又は外部ストレージシステム９００によって提供されるデータストレージリソースを管理するように構成されてもよい。例えば各ストレージハンドラモジュール４０１ａ、４０１ｂ、及び４０１ｃ（リソースハンドリングコントローラ）は、データストレージシステムの１又は複数のストレージノード又は、１又は複数のストレージノード上に設けられる１又は複数のストレージリソースを管理するように構成されてもよく、特にデータストレージシステムの各ストレージノード及び／又はストレージリソースは、関連する１つのストレージハンドラ装置（リソースハンドリングコントローラ）によって管理され及び／又は制御されてもよい。

例えば外部ストレージシステム９００への接続のために、責任を負うストレージハンドラは外部ストレージシステム９００とインタフェースを介して接続してもよい。例えば外部ストレージシステム９００へのユーザ要求はウェブサーバ２００及びＵＩＣモジュール３０１を介してルートすることができ、責任を負うストレージハンドラは外部ストレージシステム９００と（例えば直接、又はＵＩＣモジュール３０１及びウェブサーバ２００を介してルートされて間接的に）対話する。一部の例示的実施形態では外部記憶システム９００が、例えばウェブサーバ２００を介してではなく、ＵＩＣモジュール３０１及び／又はストレージハンドラモジュールの１又は複数に直接接続され得る。

図１Ｃでは、ストレージハンドラモジュール４０１ａはストレージノード５００ａ及び５００ｂによって提供される１又は複数のデータストレージリソースを管理するように構成されてもよい一方、ストレージハンドラモジュール４０１ｂはストレージノード５００ｃ及び５００ｄによって提供される１又は複数のデータストレージリソースを管理するように構成されてもよい。

例示的には、データ保護操作は、ストレージノード５００ａからストレージハンドラモジュール４０１ａによって管理される、更にはストレージハンドラモジュール４０１ａによって複製されるストレージノード５００ｂにデータを複製することを含んでもよく、例示的にはデータ保護操作は、ストレージノード５００ｃからストレージハンドラモジュール４０１ｂによって管理されるストレージノード５００ｄにデータを複製することを含んでもよく、ストレージハンドラモジュール４０１ｂは（例示的にはストレージハンドラモジュール４０１ｂに直接接続されていない）ストレージノード５００ｄにデータを複製するためにかかる複製操作がストレージノード５００ｃによって実行されることを命令する。

更に例示的には、ストレージハンドラモジュール４０１ｃは、外部ストレージシステムによって提供される１又は複数のデータストレージリソースを管理するように構成されてもよい。

従って図１Ｂと同様だが図１Ａとの違いとして、図１Ｃによる例示的実施形態では、ＵＩＣモジュール３０１及びストレージハンドラモジュール４０１ａから４０１ｂが、図１Ａに例示的に示すように別個の装置として例示的に実装されるのではなく、同じストレージ管理装置１００１上に実装される。更なる例示的実施形態では、ＵＩＣモジュール３０１を１つの装置上に実装することができ、ストレージハンドラモジュール４０１ａから４０１ｂを別の装置上に実装することができる。

図１Ｃでは、外部ストレージシステム９００がストレージ管理装置１００１に例示的に接続されている。他の例示的実施形態では、外部ストレージシステム９００がウェブサーバ２００を介して接続されてもよい。

好ましくは、外部ストレージ記憶システム９００へのアクセスの管理は、責任を負う１又は複数のストレージハンドラモジュール４０１ａから４０１ｃによって管理されるが、ストレージハンドラモジュール４０１ａから４０１ｃから外部ストレージシステム９００へのメッセージ又はアクセス要求は直接送信されてもよく、又はＵＩＣモジュール３０１及び／又はウェブサーバ２００を介してルートされてもよい。

例えば外部ストレージシステム９００への接続のために、責任を負うストレージハンドラは外部ストレージシステム９００とインタフェースにより、接続することができる。

例えば外部ストレージシステム９００へのユーザ要求はウェブサーバ２００及びＵＩＣモジュール３０１を介してルートすることができ、及び／又は責任を負うストレージハンドラモジュールが外部ストレージシステム９００と（例えば直接、又はＵＩＣモジュール３０１及び／又はウェブサーバ２００を介してルートされて間接的に）対話する。

一部の例示的実施形態では外部ストレージシステム９００が、例えばウェブサーバ２００を介してではなく、ＵＩＣモジュール３０１及び／又はストレージハンドラモジュールの１又は複数に直接接続され得る。

概して、ＵＩＣ（ユーザインタフェースコントローラ）及びストレージハンドラ（資源ハンドリングコントローラ）は、ハードウェア（機械、ワークステーション、コンピュータ、サーバ、更には機械、ワークステーション、コンピュータ、サーバのクラスタ等を含む）によって、又はソフトウェアによって（例えば機械、ワークステーション、コンピュータ、サーバ、更には機械、ワークステーション、コンピュータ、サーバのクラスタ上で実行可能な別個の又は複合ソフトウェアモジュール等によって、又は分散クラウドサービスとしてさえ）、又はハードウェアとソフトウェアとの任意の組み合わせによって（例えば仮想マシンとして又は１又は数の仮想マシン上で実行されるもの等として）実装することができる。

ストレージハンドラ（リソースハンドリングコントローラ）をソフトウェアモジュールとして提供することには、追加のストレージノード又はストレージシステムを追加して更なる管理可能なストレージリソースをもたらす場合、その新たに追加したストレージリソースが１又は複数の過去に確立されたストレージハンドラモジュール（リソースハンドリングコントローラ）の１又は複数によって管理されるように指定されてもよい、又は新たに追加したストレージリソースの１又は複数を管理するために１又は複数の新たなストレージハンドラモジュールを開始し、作成し、又はインストールしてもよい利点がある。例えば一部の例示的実施形態では、新たに追加されるストレージリソースごとに及び／又は新たに追加されるストレージノードごとに、それぞれの新たに追加されるストレージリソースを管理するために及び／又は新たに追加されるストレージノードを管理するために、それぞれの新たなストレージハンドラモジュール（リソースハンドリングコントローラ）を開始し、作成し、又はインストールしてもよい。

更に、管理モジュール８０１、認証モジュール６０１、及び承認モジュール７０１は、図１Ａ及び図１Ｂに例示的に示すように別個の装置として例示的に実装されるのではなく、同じ記憶管理装置１００１上に例示的に実装される。

概して、管理、認証、及び承認装置／モジュールは、ハードウェア（機械、ワークステーション、コンピュータ、サーバ、更には機械、ワークステーション、コンピュータ、サーバのクラスタ等を含む）によって、又はソフトウェアによって（例えば機械、ワークステーション、コンピュータ、サーバ、更には機械、ワークステーション、コンピュータ、サーバのクラスタ上で実行可能な別個の又は複合ソフトウェアモジュール等によって、又は分散クラウドサービスとしてさえ）、又はハードウェアとソフトウェアとの任意の組み合わせによって（例えば仮想マシンとして又は、１又は複数の仮想マシン上で実行されるもの等として）実装してもよい。

上記の例示的実施形態では、例示的には、それぞれのストレージハンドラ装置／モジュールはソースノード及び／又は宛先ノードを管理すること、及びソースノードから宛先ノードに行われるデータ保護操作を処理すること、管理すること、又は制御することを担ってもよい。選択的に又は加えて、異なるストレージハンドラ装置／モジュールがソースノード又はソースノードによって提供されるデータストレージリソースを管理してもよく、宛先ノード又は宛先ノードによって提供されるデータストレージリソースは別の（又は他の複数の）ストレージハンドラ装置／モジュールによって管理され、異なるストレージハンドラ装置／モジュールが宛先ノード又は宛先ノードによって提供されるデータストレージリソースを管理してもよく、ソースノード又はソースノードによって提供されるデータストレージリソースは別の（又は他の複数の）ストレージハンドラ装置／モジュールによって管理される。更に例示的実施形態では、１又は複数のストレージハンドラ装置／モジュールは、ソースノード又はソースノードによって提供されるデータストレージリソースのみを管理してもよく、他の１又は複数のストレージハンドラ装置は宛先ノード又は宛先ノードによって提供されるデータストレージリソースのみを管理してもよい。

例示的なユーザ認証プロセス
ユーザ認証プロセスのために、本明細書ではＵＩＣ（ユーザインタフェースコントローラ）とだけ更に呼ぶＵＩＣ装置３００（又はＵＩＣモジュール３０１）は、本明細書では「認証モジュール」とだけ更に呼ぶ認証装置６００（又は認証モジュール６０１）と通信するように例示的に構成される。

例えばユーザが、ウェブサーバ２００によって提供されるグラフィカルユーザインタフェース、コマンドラインインタフェース、又は別のユーザインタフェースによってクライアントコンピュータ（クライアント装置）からＵＩＣにログインする場合、ユーザ名（又は他のユーザ識別子）及びパスワードを示す、対応するログイン要求がＵＩＣにおいて受信されてもよい。

このようなユーザ名（又は他のユーザ識別情報）及びパスワードは、クライアント装置においてＵＩＣ（ユーザインタフェースコントローラ）に与えられる、ウェブサーバ２００のユーザインタフェース（例えばＣＬＩ又はＧＵＩ等）を介してそれぞれのユーザによって入力されてもよい。

図２は、いくつかの例示的実施形態に係るユーザ認証のためのプロセスのフローチャートを例示的に示す。

例示的には、ステップＳ２１で、ＵＩＣ（ユーザインタフェースコントローラ）は、クライアント装置１００ａ又は１００ｂからログインしようとしているユーザのユーザ名（及び／又はユーザ役割；典型的な例示的実施形態において該当し得るようにユーザ役割が含まれない場合、任意選択的にユーザ役割はユーザ名に関連するユーザプロファイルに基づいて後で決定されてもよい）を含むログイン要求を例えばウェブサーバ２００を介して受信する。ログイン要求は、例示的にはユーザから入力されたパスワードを更に含む。パスワードは、ログイン要求と共に（例えば所定のハッシング関数又はハッシングアルゴリズムによってパスワードをハッシングすることによって）符号化形式及び／又は暗号化形式で送信されてもよい。更に、パスワードは、例えばＴＬＳ及び／又はＳＳＬｖ３等のＳＳＬ暗号化を使用すること等の他の暗号化技法を使用してネットワーク上で送信されてもよい。

いくつかの例示的実施形態では、ログイン要求はデータストレージシステムへのログインを試みるユーザのユーザドメインを更に示してもよい。本明細書の全体を通して使用されるユーザドメイン又は単純にドメインと呼ばれる用語は、例えばアクティブディレクトリドメイン等のより狭い意味でのドメインを指してもよく、又はより広い意味ではユーザの認証空間を広く指してもよい。ユーザドメイン又はドメインは、一般的にユーザを追加することができ（又はユーザを除去することができ）、１又は複数の下位グループも有するユーザグループと見なしてもよい。

ステップＳ２２で、ＵＩＣは、受信済みのログイン要求又はログイン要求から取得し若しくは復号した対応するログイン情報を認証モジュールに送信する。複数のユーザドメインがある場合、例えば各認証モジュールが複数のユーザドメインのうちのそれぞれの１又は複数のユーザのユーザ認証を担ってもよい点で、データ記憶システムが複数の認証モジュール（モジュール、装置、又はシステム）を含んでもよい。

このような例示的実施形態では、ステップ２２は、ＵＩＣにおける受信したログイン要求に関連するそれぞれのユーザのユーザドメインを決定すること、及び受信されたログイン要求（又はログイン要求から取得され若しくは復号される対応するログイン情報）を決定された認証モジュールに送信するための責任を負う認証モジュールを決定することを更に含んでもよい。

ステップＳ２３で、認証モジュールは、ＵＩＣからログイン要求（又はログイン要求から取得され若しくは復号される対応するログイン情報）を受信すると、ＵＩＣから受信されたユーザに関連するログイン要求（又はユーザログイン情報）をチェックして、認証モジュールのデータベース内に記憶されている認証データに基づいてユーザを認証できるか否かを決定する。

例えばユーザの認証は、認証モジュールのデータベース内に記憶される認証データがユーザログイン要求に関連するそれぞれのユーザのユーザ名に関する認証データを有し、且つパスワード又はその暗号化表現がユーザログイン要求に関連するそれぞれのユーザのユーザ名に関する認証データと一致する場合は、成功したと決定することができる。さもなければユーザの認証は不成功だと決定される。

いくつかの例示的実施形態では、例えばユーザの資格情報を例えばローカルコンピュータ及び／又はリモートコンピュータ上のアクティブディレクトリ、ＬＤＡＰ、又はローカルセキュリティサービス等のサードパーティ認証システムに照らしてチェックすることにより、外部の認証サービス／システムを使用することによって認証プロセスを実行してもよい。その場合（例えば以下に記載の認証プロセスの代わりに、サードパーティ認証システムとの対話に基づいて認証を付与し又は拒否してもよく、ステップＳ２３、Ｓ２４、Ｓ２５、及び／又はＳ２７若しくは同様のものがサードパーティ認証システムによって実行されてもよい）。

ステップＳ２３で、認証モジュールは、例えばユーザログイン要求が事前登録されたユーザに実際に関連すること（即ちそのユーザが主張通りの人物であること）を認証するために、ユーザログイン要求に関連するそれぞれのユーザのユーザ認証が成功したかどうかを例示的にチェックする。

ステップＳ２３がＮＯを返す場合、認証モジュールはステップＳ２５で拒否メッセージをＵＩＣに単純に送信してもよく、ステップＳ２６でＵＩＣは（例えばエラー又はアクセス拒否のメッセージをユーザに与えるようにウェブサーバ２００に指示することによって）アクセスを拒否してもよい。これでこのプロセスは終了してもよい。

他方でステップＳ２３がＹＥＳを返す場合、認証モジュールは、ステップＳ２７で、例えば認証されたユーザに関連するユーザ情報を含む確認メッセージをＵＩＣに送信し、その確認を受信すると、ステップＳ２８でＵＩＣはログイン要求に関連するユーザのセッション開始を例示的に始め、ステップＳ２９でアクセス制御目的でユーザ承認プロセスを続ける（例えば図３参照）。

Ｓ２７で送信される「ユーザ情報」と呼ばれる情報は、いくつかの例示的実施形態ではユーザ資格情報であってもよい。

いくつかの例示的実施形態では、ユーザ資格情報は、ログイン要求に関連するユーザのユーザ名（及び任意選択的にユーザドメイン）を確認してもよく、又は他の例示的実施形態では、ユーザ資格情報はユーザＩＤ等のユーザ識別子を含んでもよい。ユーザ資格情報は、任意選択的にユーザのパスワードのハッシュ値を追加で含むことができる。但し、そのような情報は通常はユーザのパスワードを含まない。

他の例示的実施形態では、Ｓ２７で送信されるユーザ情報はユーザ名等の個人的ユーザ情報を送信しなくてもよいが、ユーザ情報はユーザが属するグループに関する「メンバシップ情報」又は「グループ情報」を含んでもよい。例えば、そのユーザの「メンバシップ情報」は、ユーザが属するグループ及び／又はユーザのドメインの少なくとも１つを示してもよい。

Ｓ２７で送信される情報は、以下に記載の例示的実施形態の承認プロセスの中で使用してもよい。

上記の認証プロセスは任意選択的であり、いくつかの例示的実施形態では安全な環境内でユーザ認証プロセスを飛ばしてもよいことに留意すべきである。更に、より単純な認証プロセスを使用してもよく、ユーザ認証プロセスはＵＩＣによって直接実行されるようにＵＩＣ内に実装されていてもよい。

更に、上記の例示的な認証プロセスはパスワードの使用に依存するが、顔認識、音声認識、及び／又は指紋識別等のバイオメトリックス情報に基づく及び／又はタッチスクリーンフィンガパターン認証等にも基づく、ログイン要求に関連する特定のユーザを識別するための他の認証プロセスも（代わりに又は追加で）実行されてもよいことに留意すべきである。

例示的なユーザ承認プロセス（アクセス制御承認）
ユーザ承認目的で、例えばアクセス制御に関連して、ＵＩＣは承認モジュール／装置と通信するように例示的に構成される。例えばユーザが（例えばウェブサーバ２００によって提供されるグラフィカルユーザインタフェース（ＧＵＩ）、コマンドラインインタフェース（ＣＬＩ）、又は別のユーザインタフェースによってクライアントコンピュータ（クライアント装置）から）ＵＩＣにログインする場合、ユーザ名（又は他のユーザ識別子）を示す対応するログイン要求がＵＩＣにおいて受信され得る。

例えば上記のように任意選択的な認証プロセスを行うとき、ＵＩＣはログイン要求に関連するユーザのユーザ名に基づいて承認プロセスの開始を実行してもよい。

更にＵＩＣ（ユーザインタフェースコントローラ）は、例えばユーザ名及び／又はユーザＩＤ等のユーザ識別子を使用することにより、又はユーザのグループ及び／又はドメインに関する情報を使用することにより、上記の認証プロセスによって与えられるログイン要求に関連するユーザのユーザ資格情報又はメンバシップ情報等のユーザ情報に基づいて承認プロセスの開始を実行してもよい。

例示的には、いくつかの例示的実施形態におけるユーザ承認は役割ベースアクセス制御（ＲＢＡＣ）スキームを使用することによって行われる。しかし、役割ベースアクセス制御（ＲＢＡＣ）スキームを使用することは好ましい例示的態様だが、いくつかの例示的実施形態では（定められたユーザ役割なしの）他のアクセス制御スキームが使用されてもよい。

概して、役割ベースアクセス制御（ＲＢＡＣ）スキームは、例えば特定のユーザ役割に関連する各ユーザが特定のユーザ役割に関連する活動を実行することを（又はその実行を要求することを）許可されてもよいという点において、１又は複数のユーザ役割のそれぞれとそれぞれのユーザ役割のユーザに関連する１又は複数の許容ユーザ活動との間の関連付けを定めてもよい。

１又は複数のユーザ役割のそれぞれとそれぞれのユーザ役割のユーザに関連する１つ又は複数の許容ユーザ活動との間のそのような関連付けは、そのような関連付けがそれぞれのユーザ役割のユーザについて許可される１又は複数の活動をユーザ役割ごとに定める肯定的方法で定めてもよい。いくつかの例示的実施形態では、（加えて又は代替的に）１又は複数のユーザ役割のそれぞれとそれぞれのユーザ役割のユーザに関連する１又は複数の許容ユーザ活動との間の関連付けは、かかる関連付けがそれぞれのユーザ役割のユーザについて許可すべきではない複数の活動のうちの１又は複数の活動をユーザ役割ごとに定める否定的方法で任意選択的に定めてもよい。

（定められたユーザ役割なしの）別のアクセス制御スキームが使用され得る場合、アクセス制御スキームは、例えば各ユーザが自らに関連付けられた活動を実行することを（又はその実行を要求することを）それぞれ許可され得るという点において、１又は複数のユーザのそれぞれとそれぞれのユーザに関連する１又は複数の許容ユーザ活動との間の関連付けを直接定めてもよい。

複数のユーザのそれぞれとそれぞれのユーザに関連する１又は複数の許容ユーザ活動との間のそのような関連付けは、そのような関連付けがそれぞれのユーザについて許可される１又は複数の活動をユーザごとに定める肯定的方法で定めてもよい。いくつかの例示的実施形態では、（加えて又は代替的に）複数のユーザのそれぞれとそれぞれのユーザに関連する１又は複数の許容ユーザ活動との間のそのような関連付けは、そのような関連付けがそれぞれのユーザについて許可すべきではない複数の活動のうちの１又は複数の活動をユーザごとに定める否定的方法で定めてもよい。

それでもなお、本開示はそれに限定されないが、いくつかの例示的実施形態では役割ベースアクセス制御（ＲＢＡＣ）スキームを使用することは好ましい例示的態様であり、それはかかる役割ベースアクセス制御（ＲＢＡＣ）が個人ユーザごとに許容活動の関連付けを定める必要がないが（システム内には数百人更には数千人ものユーザがいる可能性がある）、（ユーザの総数よりも少ない数の）様々なユーザグループを定めることを許容してもよいからであり、各ユーザグループは１組の特定の１又は複数の許容活動に関連する特定のユーザ役割に関連付けられる。更に、過去に定められている可能性がある適切なユーザ役割を新たなユーザに割り当てるだけでよいので、又は多くのユーザの新たなグループについて新たなユーザ役割を効率的に定めることができるので、システムに新たなユーザ（更には新たなユーザグループ）を追加することがより効率的になる。

概して、ユーザ役割には１又は複数の活動及び／又は活動の１又は複数の活動グループを関連付けてもよく、特定のユーザ役割のユーザは、その特定のユーザ役割に関連する１又は複数の活動及び／又は活動の１又は複数の活動グループを実行することを許可される。例えば第１ユーザ役割は第１活動及び／又は第１活動グループを実行することを許可してもよい一方、他の第２役割は第２活動及び／又は第２活動グループを実行することを許可してもよい。

更にいくつかの例示的実施形態では、例えば特定のユーザ役割をそのそれぞれのユーザ役割のユーザによって特定のリソースに対して行われ得る特定の活動に関連付けることができるという点において、ユーザ役割をリソースに関連付けたり又はリソースに対して制御できたりしてもよいことにも留意すべきである。例えば第１ユーザ役割は第１リソースに対して（及び／又は第１リソースグループに対して）第１活動（及び／又は第１活動グループ）を実行することを許可してもよい一方、他の第２役割は第２リソースに対して（及び／又は第２リソースグループに対して）第２活動（及び／又は第２活動リソース）を実行することを許可してもよい。

更にいくつかの例示的実施形態では、活動を実行することが許可された特定のリソースにユーザ役割を関連付けることができるように、ユーザ役割をリソースに関連付けることができる。例えば第１ユーザ役割は第１リソースに対して（及び／又は第１資源グループ群に対して）１又は複数の活動を実行することを許可してもよい一方、別の第２役割は第２リソースに対して（及び／又は第２資源グループに対して）１又は複数の活動を実行することを許可し得る。

ユーザ承認プロセスの例示的態様を以下で説明するが、ユーザ承認プロセスの全体的な例示的態様は図３に関して以下で説明する。

この例では、ユーザのアクセス許可は、現在システムにログインしている特定のユーザに関連するアクセス制御プロファイル情報内に記載される。例示的には、そのようなユーザ承認プロセスはセッション開始時に（即ちユーザのログイン後に、任意選択的にはユーザ認証プロセスの成功の確認時に）ＵＩＣによって例示的に実行される。

図３は、一部の例示的実施形態に係るユーザ承認プロセスのためのプロセスの流れ図を例示的に示す。

例示的には、ステップＳ３１で（例えば上記の認証プロセスの後、又は特定のユーザからログイン要求を受信してすぐ）ＵＩコントローラ（ＵＩＣ）がユーザ承認プロセスを開始し、（例えばユーザのユーザ名、ユーザのユーザＩＤ、又は認証モジュール若しくは認証装置６００から受信される資格情報を使用することによって例えばユーザの識別情報を示す、及び／又はユーザグループ及び／又はドメインを示す）対応する承認要求を承認モジュール／装置に送信する。

承認モジュールはログイン要求に関連するユーザの、対応する承認要求を受信し、ステップＳ３２で、複数のユーザと１又は複数のアクセス制御プロファイルとの間の関連付けを記憶し得る自らの承認データベースを探索する。承認データベースは、個人ユーザに関するアクセス制御プロファイル（例えばユーザごとの１又は複数の関連するアクセス制御プロファイル）、ユーザグループに関するアクセス制御プロファイル（例えばユーザグループごとの１又は複数の関連するアクセス制御プロファイル）、及び／又はユーザドメインに関するアクセス制御プロファイル（例えばユーザドメインごとの１又は複数の関連するアクセス制御プロファイル）に対する関連付けを記憶してもよい。

従って、承認装置／モジュールは、ログイン要求に関連するユーザの対応する承認要求に基づき、それぞれのユーザ（及び／又はユーザグループ及び／又はユーザドメイン）に関する１又は複数のアクセス制御プロファイル、即ちそれぞれのユーザ（及び／又はユーザグループ及び／又はユーザドメイン）に関連する１又は複数のアクセス制御プロファイルを決定するように、及び／又はそれぞれのユーザ（及び／又はユーザグループ及び／又はユーザドメイン）のユーザ役割に関連する１又は複数のアクセス制御プロファイルを決定するように構成される。

例えば承認データベースは、複数のユーザ（及び／又はユーザグループ及び／又はユーザドメイン）のユーザごとに、それぞれのユーザ（及び／又はユーザグループ及び／又はユーザドメイン）に関連する１又は複数のアクセス制御プロファイルを記憶してもよく、及び／又は、１又は複数のアクセス制御プロファイルのアクセス制御プロファイルごとに、それぞれのアクセス制御プロファイルに関連する０、１、又はそれを上回るユーザ（及び／又はユーザグループ及び／又はユーザドメイン）を記憶してもよい。

加えて又はそれに代えて、承認データベースは、１つ又は複数のユーザ役割のユーザ役割ごとに、それぞれのユーザ役割に関連する１又は複数のアクセス制御プロファイルを記憶してもよく、及び／又は、１又は複数のアクセス制御プロファイルのアクセス制御プロファイルごとに、それぞれのアクセス制御プロファイルに関連する１又は複数のユーザ役割を記憶してもよい。次いで承認データベースは、好ましくは、複数のユーザ（及び／又はユーザグループ及び／又はユーザドメイン）のユーザごとに、それぞれのユーザ（及び／又はユーザグループ及び／又はユーザドメイン）に関連する１つ（又は複数）のユーザ役割を記憶してもよく、及び／又は、承認データベースは、好ましくは、１又は複数のユーザ役割のユーザ役割ごとに、それぞれのユーザ役割に関連する０、１、又はそれを上回るユーザ（及び／又はユーザグループ及び／又はユーザドメイン）も記憶してもよい。

更なる例示的実施形態では、承認データベースは、複数のユーザの各ユーザを１又は複数のユーザグループのうちのそれぞれのユーザグループに関連付けるユーザグループ情報、及び／又は、１又は複数のユーザグループの各ユーザグループを複数のユーザのうちのそれぞれのユーザに関連付けるユーザグループ情報を記憶してもよい。このような例示的実施形態では、承認データベースは、１又は複数のユーザグループのそれぞれを１又は複数のアクセス制御プロファイルに関連付ける、及び／又は、１又は複数のアクセス制御プロファイルのそれぞれを１又は複数のユーザグループに関連付けるアクセス制御プロファイル関連付け情報を更に記憶してもよい。

ここではグループは、ユーザドメインも指してもよく（例えばユーザｂｏｂ＠ｄｏｍａｉｎ．ｃｏｍとｍａｒｙ＠ｄｏｍａｉｎ．ｃｏｍとは同じドメイン「＠ｄｏｍａｉｎ．ｃｏｍ」に属する異なるユーザであってもよい）、及び／又はグループ内の複数のユーザのユーザグループ（例えば特定のドメインの全ユーザの下位グループ）を指してもよい。

概して、上記の内容に基づき、承認データベース内でそれぞれのログイン要求に関連するそれぞれのユーザを探索することにより、承認モジュール／装置は、それぞれのログイン要求に関連するそれぞれのユーザに関連する１又は複数のアクセス制御プロファイルを、例えばユーザとアクセス制御プロファイルとの間の関連付けによって直接、又はそれぞれのログイン要求に関連するそれぞれのユーザに関連するユーザグループ及び／又はユーザ役割を決定することを含む関連付けによって間接的に決定することができる。

以下でより詳細に説明するように、各アクセス制御プロファイルはそれぞれのアクセス制御プロファイル情報に関係することができ、好ましい例示的態様では、特定のアクセス制御プロファイルのアクセス制御プロファイル情報は、好ましくは実行することが許可されている（又はそれぞれのアクセス制御プロファイルに関連すると判定されるユーザによって実行のために要求されることが許可されている）１又は複数の活動（又はユーザ活動）、及びそれぞれのアクセス制御プロファイルに関連すると判定されるユーザによってアクセスされることが許可されている（例えばストレージノード又はストレージノードグループがデータストレージリソースを表し得るという意味で及び／又は、１又は複数のストレージリソースを提供し得るという意味で、例えば上記のようにストレージノードによって与えられる又は上記で論じたようにストレージノードによって表される）１又は複数のデータストレージリソース（例えば許可された活動を実行すること又は要求することをユーザが認められている１又は複数のデータストレージリソース）を少なくとも示してもよい。

上記の内容に加えて（又はその代わりに）、好ましい例示的態様では、特定のアクセス制御プロファイルのアクセス制御プロファイル情報は、好ましくはユーザによって実行されることが許可されている１又は複数の活動（又はユーザ活動）及びそれぞれのアクセス制御プロファイルに関連すると判定されるユーザによってアクセスされることが許可されている１又は複数のデータストレージリソースを少なくとも示してもよく、特定のアクセス制御プロファイルのアクセス制御プロファイル情報は、１又は複数のリソースグループを示すことができ、各リソースグループは１又は複数のデータストレージリソースに関連する。

上記の内容に加えて（又はその代わりに）、好ましい例示的態様では、特定のアクセス制御プロファイルのアクセス制御プロファイル情報は、好ましくはユーザによって実行されることが許可されている１又は複数の活動（又はユーザ活動）及びそれぞれのアクセス制御プロファイルに関連すると判定されるユーザによってアクセスされることが許可されている１又は複数のデータストレージリソースを少なくとも示してもよく、特定のアクセス制御プロファイルのアクセス制御プロファイル情報は、１又は複数の活動グループを示すことができ、各活動群グループは許可される１又は複数の活動に関連する（特定のアクセス制御プロファイルのアクセス制御プロファイル情報は、活動グループに加えて０以上の活動（例えば追加の活動）を更に示してもよい）。

更に好ましくは、役割ベースアクセス制御（ＲＢＡＣ）スキームでは、特定のアクセス制御プロファイルのアクセス制御プロファイル情報は１又は複数のユーザ役割を示すことができ、各ユーザ役割は、１又は複数の活動グループ（各活動グループは１又は複数の活動に関連する）及び０以上の活動、又は（例えば活動グループとの少なくとも１つの関連付けが既にある場合は）１つ又は複数の活動に好ましくは関連する。

更に好ましくは、一部の例示的実施形態では、特定のアクセス制御プロファイルのアクセス制御プロファイル情報は、１又は複数のアクセスレベル（例えばリソースグループごとに１つのアクセスレベル）を好ましくは例示的に示してもよい。アクセスレベル及びその例示的な効果について以下で更に説明する。

図４は、一部の例示的実施形態に係る、ユーザとユーザに関係するアクセス制御プロファイルとの間の関連付け、及びアクセス制御プロファイル情報の関連付けの一例を例示的に示す。

例示的には、図４のアクセス制御プロファイルは役割ベースアクセス制御（ＲＢＡＣ）に基づき、上記で述べたように本発明は役割ベースアクセス制御（ＲＢＡＣ）に限定されない。例えば複数のユーザのそれぞれを少なくとも１つのユーザ役割に関連付ける、及び各ユーザ役割を１又は複数のそれぞれのアクセス制御プロファイルに関連付ける代わりに（又はそれに加えて）、ユーザは例えばユーザ役割を使用することなしに１又は複数のそれぞれのアクセス制御プロファイルに直接関連付けることができる。

概して、好ましい例示的態様では、複数のユーザのそれぞれが１又は複数のアクセス制御プロファイルに（例えばそのユーザ識別情報に依存して、ユーザが属する特定のドメインの１又は複数のユーザグループに従って、及び／又はユーザが属する１又は複数のドメインに従って）関連付けられる。

複数のユーザのそれぞれを１又は複数のそれぞれのアクセス制御プロファイルに関連付ける管理情報により、ＡＣＰ（アクセス制御プロファイル）の関連付けが表される。

例えば承認モジュール／装置の承認データベースは以下の１又は複数を示し得るアクセスプロファイル関連付け情報を記憶してもよい：
・１又は複数の関連付け（アクセス制御プロファイルの関連付け）であり、各関連付けは個人ユーザ、ユーザのグループ（ユーザグループ）、及び／又はドメインについて提供されてもよい。
・各関連付けは１又は複数のアクセス制御プロファイルを示す（又は含む）んでもよい。
・各アクセス制御プロファイルはユーザ役割及び／又はリソースグループを示す（又は含む）んでもよい。
・各アクセス制御プロファイル内で、好ましくはリソースグループごとにアクセスレベルを指定することができる。
・各ユーザ役割は１又は複数の活動及び／又は、１又は複数の活動に関連することができ、各活動グループは１又は複数の活動（ユーザ活動）に関連づけられてもよい。
・各リソースグループは、１又は複数のストレージリソースに関連することができる。

上記の内容に鑑みて、ユーザ（又はユーザが属するユーザグループ）が特定のアクセス制御プロファイル（アクセス制御プロファイルの関連付け）に関連すると判定された場合、それぞれのリソースグループについて示されるそれぞれのアクセスレベルに従って、関連するアクセス制御プロファイル内で示されるリソースグループに含まれるストレージリソースに対して、アクセス制御プロファイル内で示されるユーザ役割に関連する１又は複数の活動、及び／又はユーザ役割に関連する活動グループに関連する１又は複数の活動を実行する／行うことを許可されるようにそのユーザはアクセスを付与されてもよい。

特定のユーザは複数のアクセス制御プロファイルに関連付けることができることに留意すべきである。例えば承認データベースが個人ユーザ、ユーザグループ、及びドメインのアクセス制御プロファイルを記憶する場合、ユーザｂｏｂ＠ｄｏｍａｉｎ．ｃｏｍに複数のアクセス制御プロファイル、例えば個人ユーザ「ｂｏｂ」に関連する第１アクセス制御プロファイルＡＣＰ１、ドメイン「ｄｏｍａｉｎ．ｃｏｍ」に関連する第２アクセス制御プロファイルＡＣＰ２、及びユーザ「ｂｏｂ」が属し得る１又は複数のユーザグループに関連する、潜在的な１又は複数の更なるアクセス制御プロファイルを割り当てることができる。

例えば図４（Ａ）は、図４（Ａ）内の矢印によって例示的に示されているように（複数のユーザのうちの）ユーザ「ユーザ１」が（複数のアクセス制御プロファイルのうちの）アクセス制御プロファイル「ＡＣＰ１」に関連付けられることを例示的に示す。それに代えて又は加えて、例えば図４（Ｂ）にあるように、（複数のユーザのうちの）ユーザ「ユーザ１」は、ここでもアクセス制御プロファイル「ＡＣＰ１」に関連する（１又は複数のユーザにそれぞれ関連する複数のユーザグループのうちの）ユーザグループ「ユーザグループ１」（例えば特定のユーザ役割に関連するユーザグループ、例えば通常ユーザ、スーパユーザ、及び／又は管理者等に関連するユーザ群）に例示的に関連付けられてもよい。

従って、各ユーザは１つ又は複数のアクセス制御プロファイルに関連付けられる。承認モジュール／装置は、そのような承認関連付け情報に基づいて、特定のユーザ、例えばＵＩＣにログインし承認されようとするユーザに関連する１又は複数のアクセス制御プロファイル（又は複数のアクセス制御プロファイル）を決定することができる。

ユーザのアクセス許可は、それぞれのアクセス制御プロファイルに関連するアクセス制御情報内で例示的に示される。その結果、アクセス制御プロファイル情報は、定められたアクセス制御プロファイルごとに例えば図４（Ｃ）の関連付けに従って記憶されてもよい。

図４（Ｃ）では、例示的には、（複数のアクセス制御プロファイルのうちの）アクセス制御プロファイル「ＡＣＰ１」が（複数のユーザ役割のうちの）ユーザ役割「ユーザ役割１」に例示的に関連する。更に例示的には、（複数のユーザ役割のうちの）ユーザ役割「ユーザ役割１」は、（複数の活動グループのうちの）活動グループ「活動グループ１」に関連し、「活動グループ１」は、（複数の活動のうちの）活動「活動１」及び「活動２」に例示的に関連する。ユーザ役割は、複数の活動のうちの０、１、又はそれを上回る活動に直接関連付けられてもよい。各アクセス制御プロファイルは、１又は複数の活動グループ及び０、１、又はそれを上回る活動に関連するユーザ役割に関連付けられてもよく、各活動グループは１又は複数の活動に関連づけられてもよい。

図４（Ｃ）では、例示的には、（複数のアクセス制御プロファイルのうちの）アクセス制御プロファイル「ＡＣＰ１」は、（複数のリソースグループのうちの）リソースグループ「リソースグループ１」に例示的に関連付けられ、（複数のリソースグループのうちの）リソースグループ「リソースグループ１」はストレージリソース「リソース１」、「リソース２」、及び「リソース３」に例示的に関連付けられる。各アクセス制御プロファイルは１又は複数のリソースグループに関連付けられてもよく、各リソースグループは１又は複数のリソースに関連付けられてもよい。

図４（Ｃ）では、例示的には、（複数のアクセス制御プロファイルのうちの）アクセス制御プロファイル「ＡＣＰ１」が（複数のアクセスレベルのうちの）アクセスレベル「アクセスレベル１」に例示的に関連付けられている。各アクセス制御プロファイルは１又は複数のアクセスレベルに関連付けられてもよい。好ましくは、アクセス制御プロファイルは、例えば各リソースグループをそれぞれのアクセスレベルに関連付けることにより、それぞれのアクセス制御プロファイルに関連するリソースグループごとのそれぞれのアクセスレベルに関連付けられている。

要約すれば、図４の関連付け情報及びアクセス制御プロファイル情報は、それぞれのユーザ「ユーザ１」がアクセス制御プロファイル「ＡＣＰ１」に関連付けられ、「ＡＣＰ１」は、ユーザ「ユーザ１」がユーザ役割「ユーザ役割１」を有し、アクセスレベル「アクセスレベル１」に基づいてリソースグループ「リソースグループ１」によるリソースグループ「リソース１」、「リソース２」、及び「リソース４」にアクセスすることを許可されていることを示しており、ユーザ「ユーザ１」は、アクセスレベル「アクセスレベル１」に基づいてリソースグループ「リソースグループ１」によるストレージリソース「リソース１」、「リソース２」、及び「リソース４」に対して活動グループ「活動グループ１」のうちの活動「活動１」、「活動２」、及び「活動５」を実行すること（又はその実行を要求すること）を許可される。

従って例示的には、アクセス制御プロファイルは、それぞれのユーザがそれぞれのアクセス制御プロファイル「ＡＣＰ１」に関連し、関連するアクセスレベルに基づいて関連するリソースグループによるストレージリソースにアクセスすることを許可されること、及びそれぞれのユーザが、関連するアクセスレベルに基づいて関連するリソースグループによるストレージリソースに対して関連する活動グループの活動及び／又は関連する活動を実行すること（又はその実行を要求すること）を許可されることを示す。

図３に戻り、ステップＳ３３で、ステップＳ３２の探索に基づいて承認モジュール／装置が、ログイン要求及び／又は承認要求に関連するユーザに関連する１又は複数のアクセス制御プロファイル（及び／又は対応するアクセス制御プロファイル情報）を取得し、ログイン要求及び／又は承認要求に関連するユーザに関連する決定された１又は複数のアクセス制御プロファイルを示す対応するアクセス制御プロファイル情報を使用してペイロードを作成し（ステップＳ３４）、そのペイロードはステップＳ３５で承認モジュール／装置からＵＩＣ（ユーザインタフェースコントローラ）に送信される。

ステップＳ３７で、ＵＩＣ（ユーザインタフェースコントローラ）は、ウェブサーバ２００を介して確認メッセージを送信することによってその時の（認証済みの且つ）承認済みのユーザに関するセッション開始を例示的に確認する。

例示的には（並列に、ステップＳ３７の前に、又はステップＳ３７の後で実行され得る）ステップＳ３４で、それぞれのユーザに関するアクセス制御情報のペイロードを作成する。従っていくつかの例示的実施形態では、承認装置／モジュールは、ユーザに関連する取得されたアクセス制御プロファイルに基づいてそのそれぞれのユーザのペイロードを作成することを担い、作成されたペイロードはＵＩＣ（ユーザインタフェースコントローラ）に送信される。他の例示的実施形態では、承認装置／モジュールは、ユーザに関連する取得されたアクセス制御プロファイル又はユーザに関連するアクセス制御プロファイルを示すアクセス制御プロファイル情報をＵＩＣに送信してもよく、かかる例示的実施形態ではペイロードは、受信されたアクセス制御プロファイル又はアクセス制御プロファイル情報に基づいてＵＩＣにおいて作成されてもよい。

ペイロードは、ログイン要求に関連するそれぞれのユーザについて承認装置／モジュールによって得られる対応するアクセス制御プロファイル情報を好ましくは示す。いくつかの例示的な好ましい態様では、対応するアクセス制御プロファイル情報は、ペイロードの作成時に例えば圧縮された圧縮データ形式で符号化されてもよい。

そのようなペイロードは、上記の承認プロセスを後で再び行う必要がないという利点を与えるが、それぞれのユーザのそれぞれのアクセス制御プロファイル情報は、（少なくともその間ユーザのアクセス制御プロファイルがリセットされ又は再構成されない限り）再利用のためにユーザが再びログアウトするまで全セッションにわたって又はユーザが再びログインするまで保たれるように更に長く（ＵＩＣの例えばキャッシュ、ＮＶＲＡＭ内に、又はストレージデバイス上に、例えばセッションデータベース内に）記憶しておかなければならない。

更にそのようなペイロードは、ＵＩＣがペイロードをアクセス要求内に（例えばペイロードをかかるアクセス要求に付加することによって、又はペイロードをかかるアクセス要求若しくはそのヘッダセクション内に符号化し若しくは追加することによって）埋め込むことができる利点を与える。すると最初の承認処理はＵＩＣによって集中化された方法で行われるが、ストレージハンドリング装置（リソースハンドリングコントローラ）がアクセス要求ごとの個々のアクセス制御をエンドポイントにおいて、即ちデータ記憶システムのデータアクセスポイントにおいて、例えばストレージハンドリング装置（リソースハンドリングコントローラ）上で、それぞれのノード上で、及び／又はストレージリソースにアクセスするためのストレージコントローラによって行うことができる点において、アクセス要求ごとの後のアクセス制御が分散された方法で効率的且つ高信頼に行うことができる。

従って、（例えばアクセスごとに集中承認システムとの間の問合せを処理する必要性を回避することによって中央承認システム上の作業負荷を著しく減らしながら、及び／又はアクセスごとの集中承認システムとの間の問合せの必要性を回避することによってシステム内の通信帯域幅を著しく減らしながら）分散された方法でのより効率的なアクセス制御。

更に任意選択的なステップＳ３６で、ＵＩＣが、それぞれのユーザについて作成されたペイロード（及び／又は受信されたアクセス制御プロファイル情報）をユーザのセッションに関連するセッション情報として例示的に記憶する。このようなセッション情報は、現在開始されているセッションのそれぞれのユーザを含む現在ログインしている１又は複数のユーザのそれぞれについてセッション管理情報としてセッション管理情報メモリセクション内にＵＩＣによって記憶されてもよい。

この形態は、現在ログインしている（セッションが実行されている）ユーザからアクセス要求がＵＩＣにおいて受信される場合、ＵＩＣがそれぞれのペイロードをアクセス要求内に／上に埋め込んでからそのアクセス要求を責任を負う１又は複数のストレージハンドラ装置（資源ハンドリングコントローラ）にルートできるという利点がある。

更に、現在ログインしている１又は複数のユーザのアクセス制御プロファイルが（例えばリソースグループを再定義すること、リソースグループにリソースを追加すること、若しくはリソースグループからリソースを除去することによって、及び／又はユーザ役割及び／又はユーザ若しくはユーザ役割に関連する活動若しくは活動グループを再定義することによって、及び／又は活動グループを再定義すること、活動グループに活動を追加すること、若しくは活動グループから活動を除去することによって、及び／又はユーザアクセス制御プロファイル内のアクセスレベルを変更すること等によって、例えば承認装置／モジュールによって管理される上記の関連付けの何れかを管理者ユーザが再構成する点において）変わり得る場合、承認装置／モジュールはＵＩＣにしかるべく（例えば通知メッセージによって）知らせてもよい。

ＵＩＣは、アクセス制御プロファイル又は基礎を成す関連付けの通知された変更の影響を受けるセッション情報をチェックするように構成してもよく、蹴決定された影響を受けるセッション情報は、例えば再作成を要求することにより及び／又は関連するペイロード及び／又はアクセス制御プロファイル情報を更新することにより、影響を受けるユーザの現在のセッション中に適切に更新されてもよい。

次いで、影響を受けるユーザから新たなアクセス要求が受信されると、進行中のセッション中の実行時の変更を反映する更新済みの／再作成されたペイロードは、変更されたアクセス制御プロファイルを有する影響を受けるユーザから新たに受信されるそのようなアクセス要求内に／上に、が埋め込まれてもよい。

ここでは、図５Ａから図５Ｅに関して以下で説明するように複数の例示的実施形態を実現することができる。

概してＵＩＣは、変更が加えられた（並びにアクセス制御プロファイル情報及び／又はアクセス制御プロファイル関連付け情報が変更されている可能性がある）という通知を承認モジュール／装置から受信し、及び現在ログインしているどのユーザが影響を受けるのかを明らかにすると、それらのユーザのセッション情報を直ちに更新（又は更新することを要求）してもよい。例えばＵＩＣは、影響を受けるログインユーザについて記憶されたセッション情報及びペイロードが「期限切れ」と示してもよく、そのユーザから新たなアクセス要求が受信されると（例えばＵＩＣが承認モジュール／装置に新たなペイロードの作成を要求することによって）新たなペイロードが作成されてもよい。更に他の例示的実施形態では、変更が加えられたという通知を承認モジュール／装置から受信したとき、影響を受ける全てのユーザのセッション情報及びペイロードが更新／再作成されてもよい。

例示的なＵＩＣアクセス要求処理
図５Ａは、一部の例示的実施形態に係る、ＵＩＣにおけるＵＩＣアクセス要求処理のためのプロセスのフローチャートを例示的に示す。

例示的には、ステップＳ４１で、ユーザインタフェースコントローラ（ＵＩＣ）がストレージへのアクセス要求をユーザから受信してもよく、そのユーザは上記に基づいて過去に認証及び／又は承認されており、及び／又はそのユーザについてセッションが過去に開始されている。アクセス要求は、アクセスされるデータストレージシステムの１又は複数のストレージリソース上に記憶される１又は複数のデータ構造（即ちストレージリソース上のどのデータ構造が、受信アクセス要求によってアクセスされることを要求されるのか）を示していてもよい。

更に一部の例示的実施形態では、アクセス要求が、アクセス要求によって示されるデータストレージシステムの１又は複数のストレージリソース上に記憶される１又は複数のデータ構造に対して実行すべき１又は複数の活動を示してもよい。

アクセス要求は、データストレージシステムの１又は複数のストレージリソースに記憶されるデータ構造のデータに関連する、データの書き込み、データの複製、データの読み出し等のデータ操作に関係してもよい。

但しアクセス要求は、データストレージシステムの１又は複数のストレージリソース上に記憶されるデータ構造のためのデータ保護操作設定を閲覧すること、構成すること、又は変更すること、例えばソースノード及び宛先ノードを定めること、どのデータを何処から何処に何時、どの頻度で、又はどの事象の発生に基づいて複製すべきか等のポリシを設定すること等、データ構造のデータをソースノードから宛先ノードに又はソースデータストレージリソースから宛先データストレージリソースに完全に、部分的に、又は修正された方法で複製するデータ保護操作を実行することに関係する、例えばデータ保護ポリシ、スナップショットポリシ、複製ポリシ、ミラーリングポリシ、バックアップポリシ等を構成すること及び／又は設定することにも関係してもよい。

ステップＳ４２で、受信アクセス要求に基づき（例えばアクセスされるターゲットノード及び／又はターゲットストレージリソース及び／又はターゲットデータ構造に基づき）、ＵＩＣは例えばアクセス要求に基づいてアクセスされるそれぞれのターゲットノード及び／又はターゲットストレージリソース及び／又はターゲットデータ構造を管理する及び／又は制御する責任を負うそれぞれのストレージハンドラ（リソースハンドリングコントローラ）を決定することにより、アクセス要求に基づくアクセスを管理する及び／又は制御する責任を負うストレージハンドラ（リソースハンドリングコントローラ）を決定する。

ユーザは前に承認されているので、受信アクセス要求に関連するユーザに関連する１又は複数のアクセス制御プロファイルを示すペイロードが作成されている。

ステップＳ４３で、受信アクセス要求に関連するユーザに関連する１又は複数のアクセス制御プロファイルを示す過去に作成されたペイロードはアクセス要求に埋め込まれ、ステップＳ４４で、責任を負うストレージハンドラ（リソースハンドリングコントローラ）によって更に処理されるように、埋め込まれたペイロードを有するアクセス要求は、ＵＩＣから決定された責任を負うストレージハンドラ（リソースハンドリングコントローラ）に送信される。

従ってペイロードがアクセス制御プロファイルの情報を含むので、ストレージハンドラはＵＩＣを再び照会する必要なしにペイロードに基づいてアクセス制御処理を効率的且つ高信頼に行うことができる。

しかし（例えばユーザの進行中のセッション中の）その時の管理者が例えばユーザ役割、活動グループ、及び／又はリソースグループ、若しくは上記の関連付けの他の情報を再構成することによって上記の関連付けの何れかを変更する場合、その修正は承認装置／モジュールにおいてリセットされる。そのような潜在的な変更を（アクセス要求の受信ごとに承認処理を行う必要なしに）タイムリーに反映させるために、一部の例示的実施形態ではＵＩＣが、現在ログインしているユーザ及びそれらのペイロード及び／又はアクセス制御プロファイルを示すセッション情報を管理してもよく、ＵＩＣは承認装置／モジュールから受信される構成変更通知に基づき、構成されるそれぞれのセッションデータを更新して更新済みのペイロード情報を保ち、進行中のセッションのユーザからの要求に対して更新済みのペイロードを埋め込んでもよい。

図５Ｂは、一部の例示的実施形態に係る、ＵＩＣにおけるＵＩＣセッション管理処理のためのプロセスのフローチャートを例示的に示す。

例示的には、ステップＳ４５で、ＵＩＣは、アクセス制御プロファイル、ユーザ役割、活動グループ、及び／又はリソースグループ、若しくは上記の関連付けの他の情報がリセットされること、又は再構成されること、又は変更されることにより、アクセス制御プロファイル情報が変更されている可能性があることを示す通知メッセージを承認装置／モジュールから受信する。

ステップＳ４６で、受信した通知メッセージに基づき、ＵＩＣは進行中のセッションの影響を受けるユーザをセッション管理情報に基づいて決定する。例えば通知メッセージ及び現在ログインしているユーザについて記憶されているアクセス制御プロファイル情報に基づき、ＵＩＣはセッション管理情報内に記憶されているアクセス制御プロファイル及び／又はペイロードを決定することで影響を受けるユーザを決定する。

ステップＳ４７で、受信した通知メッセージに基づき、ＵＩＣは影響を受けるユーザのペイロードを更新する又は再作成するように承認装置／モジュールに要求し、更新済みの又は新たに作成されたペイロードを承認装置／モジュールから受信すると、ＵＩＣはステップＳ４８でセッション管理情報をしかるべく更新する。

つまり影響を受けるユーザから新たなアクセス要求が受信される場合、その影響を受けるユーザの進行中のセッション中に変更が行われても、上記のステップＳ４１及びＳ４４に従って埋め込まれるペイロードは影響を受けるユーザのアクセス制御プロファイル情報の変更を既に反映している更新済みのペイロードである。

上記では、例示的にはユーザが更なるアクセス要求を送信し得るかどうかに関係なく、ＵＩＣは影響を受けるユーザを明らかにする。これに代えて他の例示的実施形態では、ユーザからアクセス要求を受信するときだけ、ユーザが最近のアクセス制御プロファイル情報の変更の影響を受けたかどうかを決定することが可能であり（例えば図５Ｃ参照）、又は影響を受けるユーザから別のアクセス要求を受信する場合にのみ、そのユーザのペイロードがアクセス要求の受信時に再作成される／更新されることが可能である（例えば図５Ｄ及び図５Ｅ参照）。

図５Ｃは、他の一部の例示的実施形態に係る、ＵＩＣにおけるＵＩＣアクセス要求処理のためのプロセスのフローチャートを例示的に示す。

例示的には、ステップＳ４５で、ＵＩＣは、アクセス制御プロファイル、ユーザ役割、活動グループ、及び／又はリソースグループ、若しくは上記の関連付けの他の情報がリセットされること、又は再構成されること、又は変更されることにより、アクセス制御プロファイル情報が変更されている可能性があることを示す通知メッセージを承認装置／モジュールから受信する。

例示的には、ステップＳ４１で、ユーザインタフェースコントローラ（ＵＩＣ）がストレージへのアクセス要求をユーザから受信してもよく、そのユーザは上記に基づいて過去に認証及び／又は承認されており、及び／又はそのユーザについてセッションが過去に開始されている。アクセス要求は、アクセスされるデータ記憶システムの１又は複数のストレージリソース上に記憶される１又は複数のデータ構造（即ちストレージリソース上のどのデータ構造が、受信アクセス要求によってアクセスされることを要求されるのか）を示してもよい。

ステップＳ４６’において、ステップＳ４５で受信した通知メッセージに基づき、ＵＩＣは通知メッセージ内で示される変更の影響をそれぞれのユーザが受けたかどうかを、アクセス要求に関連するユーザについて記憶されているセッション管理情報に基づいて、例えばそのそれぞれのユーザに関連する過去に作成されたペイロード及び／又はそれぞ
れのユーザの関連するアクセス制御プロファイルを参照することによって決定する。例えば通知メッセージ及びそれぞれのユーザについて記憶されているアクセス制御プロファイル情報に基づき、ＵＩＣはそれぞれのユーザが変更の影響を受けるかどうかを決定する。

ステップＳ４６’がＮＯを返す場合、このプロセスは上記の図５Ａと同様にステップＳ４２、Ｓ４３、及びＳ４４を続ける。しかしステップＳ４６’がＹＥＳを返す場合、この方法はステップＳ４７’及びＳ４８’を続ける。

ステップＳ４７’で、ＵＩＣは影響を受けるそれぞれのユーザのペイロードを更新する又は再作成するように承認装置／モジュールに要求し、更新済みの又は新たに作成された情報をＵＩＣにおいて受信すると、ＵＩＣはステップＳ４８’で、影響を受けるそれぞれのユーザのセッション管理情報をしかるべく更新する。

つまり影響を受けるユーザから新たなアクセス要求が受信される場合、その影響を受けるユーザの進行中のセッション中に変更が行われても、Ｓ４４内で埋め込まれるペイロードは影響を受けるユーザのアクセス制御プロファイル情報の変更を既に反映している更新されたペイロードである。次いでこのプロセスは上記の図５Ａと同様にステップＳ４２、Ｓ４３、及びＳ４４を続ける。

図５Ｄは、他のいくつかの例示的実施形態に係る、ＵＩＣにおけるＵＩＣセッション管理処理のためのプロセスのフローチャートを例示的に示す。

例示的には、ステップＳ４５で、ＵＩＣは、アクセス制御プロファイル、ユーザ役割、活動グループ、及び／又はリソースグループ、若しくは上記の関連付けの他の情報がリセットされること、又は再構成されること、又は変更されることにより、アクセス制御プロファイル情報が変更されている可能性があることを示す通知メッセージを承認装置／モジュールから受信する。

ステップＳ４６で、受信した通知メッセージに基づき、ＵＩＣは進行中のセッションの影響を受けるユーザをセッション管理情報に基づいて決定する。例えば通知メッセージ及び現在ログインしているユーザについて記憶されているアクセス制御プロファイル情報に基づき、ＵＩＣはセッション管理情報内に記憶されているアクセス制御プロファイル及び／又はペイロードを決定することで影響を受けるユーザを決定する。

ステップＳ４９で、ＵＩＣは、セッション管理情報内で示されるそれらのユーザのペイロード及びアクセス制御プロファイルが更新されていないこと（「期限切れ」）を示すために、決定された影響を受けるユーザのセッション管理情報を更新し、過去に作成されたペイロードが「期限切れ」であることを、決定された影響を受けるユーザについて登録することができる。この形態は、影響を受ける全てのユーザについてペイロードが必ずしも直ちに再作成されず、必要に応じてのみ再作成されるという利点がある（例えば図５Ｅ参照）。

図５Ｅは、他の一部の例示的実施形態に係る、ＵＩＣにおけるＵＩＣアクセス要求処理のためのプロセスのフローチャートを例示的に示す。

例示的には、ステップＳ４１で、ユーザインタフェースコントローラ（ＵＩＣ）はストレージへのアクセス要求をユーザから受信してもよく、そのユーザは上記に基づいて過去に認証及び／又は承認されており、及び／又はそのユーザについてセッションが過去に開始されている。アクセス要求は、アクセスされるデータストレージシステムの１又は複数のストレージリソース上に記憶される１又は複数のデータ構造（即ちストレージリソース上のどのデータ構造が、受信アクセス要求によってアクセスされることを要求されるのか）を示してもよい。

ステップＳ４６’’で、ＵＩＣは、ユーザのペイロードが期限切れかどうかをセッション管理情報が示すかどうかをチェックすることにより、アクセス要求に関連するユーザについて記憶されているセッション管理情報（図５ＤのステップＳ４９で更新されている可能性がある）に基づいて、それぞれのユーザが任意の通知メッセージ内で示された最近の任意の変更の影響を受けたかどうかを決定する。

ステップＳ４６’’がＮＯを返す場合、このプロセスは上記の図５Ａ又は図５Ｃと同様にステップＳ４２、Ｓ４３、及びＳ４４を続ける。しかしステップＳ４６’’がＹＥＳを返す場合、この方法は図５Ｃと同様にステップＳ４７’及びＳ４８’を続ける。

ステップＳ４７’で、ＵＩＣは影響を受けるそれぞれのユーザのペイロードを更新する又は再作成するように承認装置／モジュールに要求し、更新済みの又は新たに作成された情報をＵＩＣにおいて受信すると、ＵＩＣはステップＳ４８’で、影響を受けるそれぞれのユーザのセッション管理情報をしかるべく更新する。

つまり影響を受けるユーザから新たなアクセス要求が受信される場合、その影響を受けるユーザの進行中のセッション中に変更が行われても、ステップＳ４４内で埋め込まれるペイロードは影響を受けるユーザのアクセス制御プロファイル情報の変更を既に反映している更新されたペイロードである。次いでこのプロセスは上記の図５Ａ又は図５Ｃと同様にステップＳ４３及びＳ４４を続ける。

例示的なストレージハンドラアクセス要求処理
図６Ａは、他のいくつかの例示的実施形態に係る、ストレージハンドラにおけるストレージハンドラアクセス要求処理のためのプロセスのフローチャートを例示的に示す。

例示的には、ステップＳ６１で、上記のストレージハンドラ装置又はストレージハンドラモジュール等のストレージハンドラ（リソースハンドリングコントローラ）は、例えば上記のステップＳ４４で送信される特定のユーザに関連するアクセス制御プロファイル情報を示す埋め込みペイロードと共にＵＩＣからユーザのアクセス要求を受信する。

ステップＳ６２で、ストレージハンドラ（リソースハンドリングコントローラ）は、アクセス要求内に埋め込まれているペイロードに基づき、受信アクセス要求に関連する特定のユーザに関連するアクセス制御プロファイル情報を例示的に決定する。

更にストレージハンドラ（リソースハンドリングコントローラ）は、例えば更に説明するステップＳ６４を伴うＳ６３、Ｓ６６を伴うＳ６５、及び／又はＳ６８を伴うＳ６７のうちの１又は複数に（任意の順序で）基づいて非集中（即ちＵＩＣへの更なる問合せなしの）アクセス制御を例示的に行ってもよい。

例示的には、ステップＳ６３で、ストレージハンドラ（リソースハンドリングコントローラ）がアクセス要求に基づいてアクセスされる１又は複数のストレージリソースを決定し、ステップＳ６４で、ストレージハンドラ（リソースハンドリングコントローラ）は、アクセスされる決定された１又は複数のストレージリソースにアクセスすることをアクセス要求に関連するユーザが許可されている／認められているかどうかを決定する。ステップＳ６４がＮＯを返す場合はアクセス処理を停止し、要求されたアクセス要求の実行を控え、（例えばＵＩＣへの拒否メッセージ又はエラーメッセージの送信によって）このプロセスは終了する。

例えばストレージハンドラ（リソースハンドリングコントローラ）は、決定された１又は複数のストレージリソースがそれぞれのユーザに関連するアクセス制御プロファイル情報内で示されるリソースグループに含まれる場合、アクセス要求に関連するユーザが決定された１又は複数のストレージリソースにアクセスすることを許可される／認められると決定してもよい。更にストレージハンドラ（リソースハンドリングコントローラ）は、決定された１又は複数のストレージリソースがそれぞれのユーザに関連するアクセス制御プロファイル情報内で示されるどのリソースグループにも含まれない場合、アクセス要求に関連するユーザが決定された１又は複数のストレージリソースにアクセスすることを許可されない／認められないと決定してもよい。

例示的には、ステップＳ６５で、ストレージハンドラ（リソースハンドリングコントローラ）がアクセス要求に基づいて実行される１又は複数の活動を決定し、ステップＳ６６で、ストレージハンドラ（リソースハンドリングコントローラ）は、実行される決定された１又は複数の活動を実行すること又は要求することをアクセス要求に関連するユーザが許可されている／認められているかどうかを決定する。ステップＳ６６がＮＯを返す場合はアクセス処理を停止し、要求されたアクセス要求の実行を控え、（例えばＵＩＣへの拒否メッセージ又はエラーメッセージの送信によって）このプロセスは終了する。

例えばストレージハンドラ（資源ハンドリングコントローラ）は、決定された１又は複数の活動がそれぞれのユーザに関連するアクセス制御プロファイル情報内で示される活動グループに含まれる場合、又は決定された１又は複数の活動がそれ自体でそれぞれのユーザに関連するアクセス制御プロファイル情報内で示される場合、アクセス要求に関連するユーザが決定された１又は複数の活動を実行すること又は要求することを許可される／認められると決定してもよい。更にストレージハンドラ（リソースハンドリングコントローラ）は、決定された１又は複数の活動がそれぞれのユーザに関連するアクセス制御プロファイル情報内で示されるどの活動グループにも含まれない場合、及び／又は決定済みの１つ又は複数の活動がそれ自体でそれぞれのユーザに関連するアクセス制御プロファイル情報内で示されない場合、アクセス要求に関連するユーザが決定された１又は複数の活動を実行すること又は要求することを許可されない／認められないと決定してもよい。

例示的には、ステップＳ６７で、ストレージハンドラ（リソースハンドリングコントローラ）がアクセス要求に基づいてアクセスされるストレージリソース上の１又は複数のデータ構造を決定し、ステップＳ６８で、ストレージハンドラ（リソースハンドリングコントローラ）は、アクセスされるストレージリソース上の決定済みの１又は複数のデータ構造にアクセスすることをアクセス要求に関連するユーザが許可されている／認められているかどうかを決定する。ステップＳ６８がＮＯを返す場合はアクセス処理を停止し、要求されたアクセス要求の実行を控え、（例えばＵＩＣへの拒否メッセージ又はエラーメッセージの送信によって）このプロセスは終了する。

例えばストレージハンドラ（リソースハンドリングコントローラ）は、それぞれのユーザに関連するアクセス制御プロファイル情報内で示されるアクセスレベルに基づいて、又はそれぞれのユーザに関連するアクセス制御プロファイル情報内の、１又は複数のそれぞれのデータ構造を記憶するストレージリソースのリソースグループについて示されるアクセスレベルに基づいて、決定された１又は複数のデータ構造にアクセスすることをアクセス要求に関連するユーザが許可されている／認められているかどうかを決定することができる。

例示的には、上記のアクセス制御処理がアクセス処理の停止及びアクセスを控えることを生じさせない場合、例えばステップＳ６４、Ｓ６６、及びＳ６８がＹＥＳをもたらす場合、例えば要求された１又は複数のストレージリソースへのアクセスを実行して要求された１又は複数のデータ構造に対する要求された１又は複数の活動を実行することにより、このプロセスは要求されたアクセス操作を行うことで続行する。

図６Ｂは、他のいくつかの例示的実施形態に係る、ストレージハンドラにおけるストレージハンドラアクセス要求処理のためのプロセスのフローチャートを例示的に示す。

いくつかの例示的実施形態によれば、要求されたストレージリソースに対してユーザがどの活動を実行することができるのかをまとめて決定することが重要である場合があり、それはかかる活動が（１又は複数の個々の活動及び／又は１又は複数の許可された活動グループの１又は複数の活動を許可する）ユーザ役割、並びにリソースグループ及びそのリソースグループの指定のアクセスレベルの影響を受ける可能性があるからである。換言すれば、決定されたストレージリソースに対して要求された活動を実行することをユーザが許可されているかどうかをシステムが決定することが好ましい。

例えば、特定のユーザが記憶ノードＮ１に対して活動Ａ１を行うことを許可されてもよく、同じユーザが記憶ノードＮ２に対して活動Ａ２を行うことを許可されてもよく、そのユーザは記憶ノードＮ１に対して活動Ａ２を行うことを許可されなくてもよく、記憶ノードＮ２に対して活動Ａ１を行うことを許可されなくてもよい。従って、これらの決定は図６Ｂの例示的なフローチャートの中の同じステップＳ６８’において例示的に行われる。

更に、ストレージノード上の特定のデータ構造にユーザがアクセス可能かどうかは、そのノードが属するストレージグループについて指定される「アクセスレベル」に基づいて決定されてもよい。アクセスレベルは、アクセス制御プロファイル情報から得てもよい。

例示的には、図６Ｂ及びステップＳ６１において、上記のストレージハンドラ装置又はストレージハンドラモジュール等のストレージハンドラ（リソースハンドリングコントローラ）が、例えば上記のステップＳ４４で送信される特定のユーザに関連するアクセス制御プロファイル情報を示す埋め込みペイロードと共にＵＩＣからユーザのアクセス要求を受信する。

ステップＳ６２で、ストレージハンドラ（リソースハンドリングコントローラ）が、アクセス要求内に埋め込まれたペイロードに基づき、受信アクセス要求に関連する特定のユーザに関連するアクセス制御プロファイル情報を例示的に決定する。

更にストレージハンドラ（リソースハンドリングコントローラ）は、非集中（即ちＵＩＣへの更なる問合せなしの）アクセス制御を例示的に行ってもよい。

例示的には、ステップＳ６３で、ストレージハンドラ（リソースハンドリングコントローラ）がアクセス要求に基づいてアクセスされる１又は複数のストレージリソースを決定する。

例示的には、ステップＳ６５で、ストレージハンドラ（リソースハンドリングコントローラ）がアクセス要求に基づいて実行される１又は複数の活動を決定する。

例示的には、ステップＳ６７で、ストレージハンドラ（リソースハンドリングコントローラ）がアクセス要求に基づいてアクセスされるストレージリソース上の１又は複数のデータ構造を決定する。

次いでステップＳ６８’で、ストレージハンドラ（リソースハンドリングコントローラ）は、ステップＳ６３及びＳ６５で決定されたアクセスされるストレージリソース上の決定済みの１又は複数のデータ構造に対して、ステップＳ６５で決定された活動を実行することをアクセス要求に関連するユーザが許可されている／認められているかどうかを決定する。先に述べたように、ステップＳ６８’の決定はユーザに関連するアクセス制御プロファイルに依存し、ステップＳ６８’は、ユーザのアクセス制御プロファイル情報内の許可された活動及び／又は許可された活動グループ及びリソースグループ並びにリソースグループのアクセスレベルに基づいて実行される。

ステップＳ６８’がＮＯを返す場合はアクセス処理を停止し、要求されたアクセス要求の実行を控え、（例えばＵＩＣへの拒否メッセージ又はエラーメッセージの送信によって）このプロセスは終了する。

例示的には、上記のアクセス制御処理がアクセス処理の停止及びアクセスを控えることを生じさせない場合、ステップＳ６８’がＹＥＳをもたらす場合、例えば要求された１又は複数のストレージリソースへのアクセスを実行して要求された１又は複数のデータ構造に対する要求された１又は複数の活動を実行することにより、このプロセスは要求されたアクセス操作を行うことで続行する。

データストレージシステム内の例示的なデータ構造
図７は、例示的なデータストレージシステムに係るデータ構造の分布を例示的に示す。

例示的には、図７のデータストレージシステムはノードＮ１、Ｎ２、Ｎ３、Ｎ４、Ｎ５、Ｎ６、及びＮ７を含む。ノードＮ１、Ｎ２、Ｎ３、Ｎ４、Ｎ５、Ｎ６、及びＮ７は、ユーザがアクセス可能な１つ又は複数のデータ構造のためのストレージ提供するストレージリソースと呼ぶことがある。

ストレージリソースを表す物理ノード又は論理ノードに加えて、ノード又はノードのクラスタシステム上の論理ストレージエンティティもストレージリソースと呼ぶことがある。

例えば図７では、ノードＮ５、Ｎ６、及びＮ７はデータ構造を記憶するためのストレージリソースとして論理リポジトリＲ１、Ｒ２、及びＲ３をそれぞれ提供する。

「データ構造」は、ユーザがアクセス可能なデータの任意の形式のデータ構造としてもよく、このようなデータ構造はファイル、ファイルグループ、ファイルシステム、ファイルシステムグループ、データベース、データベースグループ、アーカイブ、アーカイブグループ、ストレージボリューム、又は論理ボリューム、仮想ボリュームを含むストレージボリュームグループを示してもよく、データ構造内のデータはファイルベースのストレージ構造、ブロックベースのストレージ構造、又はオブジェクトベースのストレージ構造によって記憶されてもよい。

先に述べたそのようなデータ構造は、ユーザ、管理者によって手動で、又はアプリケーションによってシステムに追加されるという意味で、及び／又は特に別のデータ構造とは独立に、アプリケーションのアクセス及び／又はユーザのアクセスに基づいてそれぞれのデータ構造にデータを読み書きし又は追加するためにユーザアクセス可能（及び／又はアプリケーションアクセス可能）であるという意味で「主データ構造」と呼んでもよい。

他方で、「副データ構造」と呼ばれる別の種類のデータ構造は、動的に及び／又は自動で作成され得るデータ構造及び／又は例えば関連する「主データ構造」のデータの複製を部分的に又は完全に記憶することによって特に「主データ構造」に依存し得るデータ構造を指してもよい。例えば「主データ構造」のデータ（及び／又は「主データ構造」のデータのメタデータ）がデータ保護目的で例えば複製、ミラーコピー、バックアップ、スナップショット等として部分的に又は完全に複製される場合、その「主データ構造」の部分的な又は完全な複製、ミラーコピー、バックアップ、及び／又はスナップショットは特定の「主データ構造」のそれぞれの「副データ構造」と呼ばれる。

そのような「副データ構造」は、データ保護ポリシに基づいて、例えばソースノード及び宛先ノード、ソースデータ、ソースデータの種類（例えば複製、ミラーコピー、バックアップ、スナップショット等、「主データ構造」の種類）を定めることによって、及び二次データ構造を何時、どの頻度間隔で、又はどの事象の発生で作成すべきか及び／又は更新すべきか等の操作ポリシに基づいて「副データ構造」を管理することでシステムによって（例えばストレージハンドラによって）動的に及び／又は自動で作成され得る。

「主データ構造」に関して、図７のデータストレージシステムは、ノードＮ１上にファイルシステムＦＳ１を、ノードＮ２上にファイルシステムＦＳ２を、ノードＮ３上にファイルシステムＦＳ３を例示的に記憶する。更に例示的には、ノードＮ２はデータベースＤＢ１を記憶し、ノードＮ３はデータベースＤＢ２を例示的に記憶する。ノードＮ４はデータベースＤＢ３及びアーカイブＡＲ１を例示的に記憶する。

「副データ構造」に関して、図７のデータストレージシステムは上記の主データ構造のバックアップデータをそれぞれ例示的に記憶する。

例えばノードＮ５は、（矢印によって示すように）ノードＮ１のファイルシステムＦＳ１のバックアップＢＵ１を記憶するリポジトリＲ１を提供する。これはファイルシステムのミラーコピー又はスナップショットに関係してもよく、又はファイルシステムのいくつかのファイルのバックアップコピー又はそのメタデータのバックアップコピー等、ファイルシステムの部分コピーにも関係してもよい。

同様にリポジトリＲ１は、ノードＮ２のファイルシステムＦＳ２のバックアップＢＵ２、及びノードＮ２のデータベースＤＢ１のバックアップコピーＢＵ３を例示的に記憶する。更に例示的には、リポジトリＲ１はノードＮ３のファイルシステムＦＳ３のバックアップＢＵ４を記憶する。

更にノードＮ６は、ノードＮ３のデータベースＤＢ２のバックアップＢＵ５を記憶するリポジトリＲ２を提供する。これはミラーコピー、リモート複製コピー、部分コピー、又はそのメタデータのコピー若しくは部分コピー等に関係してもよい。

同様にリポジトリＲ２は、ノードＮ４のデータベースＤＢ３のバックアップＢＵ６を例示的に記憶する。更に例示的には、リポジトリＲ２はノードＮ４のアーカイブのバックアップＢＵ７を記憶する。これはミラーコピー、リモート複製コピー、部分コピー、又はそのメタデータのコピー若しくは部分コピー等に関係してもよい。

更にノードＮ７は、リポジトリＲ１内のバックアップＢＵ１のバックアップＢＵ８を（例えばＢＵ１のコピー又は部分コピーとして）記憶するリポジトリＲ３を提供する。リポジトリＲ３は、リポジトリＲ１内のバックアップＢＵ２のバックアップＢＵ９を、リポジトリＲ１内のバックアップＢＵ４のバックアップＢＵ１０を、リポジトリＲ２内のバックアップＢＵ５のバックアップＢＵ１１を、及びリポジトリＲ２内のバックアップＢＵ７のバックアップＢＵ１２を更に例示的に記憶する。

更に、責任を負うそれぞれのストレージハンドラのメタデータセクション及び／又はそれぞれの二次データ構造は、副データ構造ごとに、それぞれの親ストレージリソース及びオーナストレージリソースを好ましくは示すデータ構造メタデータを記憶する。

それぞれの副データ構造の「オーナストレージリソース」は、対応する関連「主データ構造」を記憶するストレージリソースである。

従って図７では、例示的には、
−バックアップＢＵ１及びＢＵ８のオーナストレージリソースは両方についてノードＮ１であり、それはノードＮ１がファイルシステムＦＳ１である関連主データ構造を記憶するからである
−バックアップＢＵ２及びＢＵ９のオーナストレージリソースは両方についてノードＮ２であり、それはノードＮ２がファイルシステムＦＳ２である関連主データ構造を記憶するからであり、
−バックアップＢＵ３のオーナストレージリソースはノードＮ２であり、それはノードＮ２がデータベースＤＢ１である関連主データ構造を記憶するからであり、
−バックアップＢＵ４及びＢＵ１０のオーナストレージリソースは両方についてノードＮ３であり、それはノードＮ３がファイルシステムＦＳ３である関連主データ構造を記憶するからであり
−バックアップＢＵ５及びＢＵ１１のオーナストレージリソースは両方についてノードＮ３であり、それはノードＮ３がデータベースＤＢ２である関連主データ構造を記憶するからであり、
−バックアップＢＵ６のオーナストレージリソースはノードＮ４であり、それはノードＮ４がデータベースＤＢ３である関連主データ構造を記憶するからであり、そして、
−バックアップＢＵ７及びＢＵ１２のオーナストレージリソースは両方についてノードＮ４であり、それはノードＮ４がアーカイブＡＲ１である関連主データ構造を記憶するからである。
他方で、それぞれの副データ構造の「親ストレージリソース」は、それぞれの副データ構造を記憶するストレージリソースである。

従って図７では、例示的には、
−バックアップＢＵ１からＢＵ４の親ストレージリソースはその全てについてリポジトリＲ１であり、それはリポジトリＲ１がそれぞれのバックアップＢＵ１からＢＵ４を記憶するからであり、
−バックアップＢＵ５からＢＵ７の親ストレージリソースはその全てについてリポジトリＲ２であり、それはリポジトリＲ２がそれぞれのバックアップＢＵ５からＢＵ７を記憶するからであり、そして、
−バックアップＢＵ８からＢＵ１２の親ストレージリソースはその全てについてリポジトリＲ３であり、それはリポジトリＲ３がそれぞれのバックアップＢＵ８からＢＵ１２を記憶するからである。

従って、以下のメタデータは、それぞれのバックアップとして、責任を負うそれぞれのストレージハンドラ（リソースハンドリングコントローラ）のメタデータセクション内に及び／又はそれぞれの副データ構造と共に記憶されてもよい。。

バックアップＢＵ１について、それぞれのデータ構造メタデータは、親データストレージリソースＲ１（例えばストレージリソースＩＤ形式のリポジトリＲ１）及びオーナデータストレージリソースＮ１（例えばストレージリソースＩＤ形式のノードＮ１）を示してもよい。データ構造メタデータは、示されたテナントのユーザについてのみアクセスを許可するために、それぞれの親ストレージリソース及び／又はオーナストレージリソース若しくはデータ構造に関連するテナントを、例えばテナントＩＤ形式で更に示してもよい。

バックアップＢＵ２について、それぞれのデータ構造メタデータは親データストレージリソースＲ１（例えばストレージリソースＩＤ形式のリポジトリＲ１）及びオーナデータストレージリソースＮ２（例えばストレージリソースＩＤ形式のノードＮ２）を示してもよい。データ構造メタデータは、示されたテナントのユーザについてのみアクセスを許可するために、それぞれの親ストレージリソース及び／又はオーナストレージリソース若しくはデータ構造に関連するテナントを例えばテナントＩＤ形式で更に示してもよい。

バックアップＢＵ３について、それぞれのデータ構造メタデータは親データストレージリソースＲ１（例えばストレージリソースＩＤ形式のリポジトリＲ１）及びオーナデータストレージリソースＮ２（例えばストレージリソースＩＤ形式のノードＮ２）を示してもよい。データ構造メタデータは、示されたテナントのユーザについてのみアクセスを許可するために、それぞれの親ストレージリソース及び／又はオーナストレージリソース若しくはデータ構造に関連するテナントを例えばテナントＩＤ形式で更に示してもよい。

バックアップＢＵ４について、それぞれのデータ構造メタデータは親データストレージリソースＲ１（例えばストレージリソースＩＤ形式のリポジトリＲ１）及びオーナデータストレージリソースＮ３（例えばストレージリソースＩＤ形式のノードＮ３）を示してもよい。データ構造メタデータは、示されたテナントのユーザについてのみアクセスを許可するために、それぞれの親ストレージリソース及び／又はオーナストレージリソース若しくはデータ構造に関連するテナントを例えばテナントＩＤ形式で更に示してもよい。

バックアップＢＵ５について、それぞれのデータ構造メタデータは親データストレージリソースＲ２（例えばストレージリソースＩＤ形式のリポジトリＲ２）及びオーナデータストレージリソースＮ３（例えばストレージリソースＩＤ形式のノードＮ３）を示してもよい。データ構造メタデータは、示されたテナントのユーザについてのみアクセスを許可するために、それぞれの親ストレージリソース及び／又はオーナストレージリソース若しくはデータ構造に関連するテナントを例えばテナントＩＤ形式で更に示しててもよい。

バックアップＢＵ６について、それぞれのデータ構造メタデータは親データストレージリソースＲ２（例えばストレージリソースＩＤ形式のリポジトリＲ２）及びオーナデータストレージリソースＮ４（例えばストレージリソースＩＤ形式のノードＮ４）を示してもよい。データ構造メタデータは、示されたテナントのユーザについてのみアクセスを許可するために、それぞれの親ストレージリソース及び／又はオーナストレージリソース若しくはデータ構造に関連するテナントを例えばテナントＩＤ形式で更に示してもよい。

バックアップＢＵ７について、それぞれのデータ構造メタデータは親データストレージリソースＲ２（例えばストレージリソースＩＤ形式のリポジトリＲ２）及びオーナデータストレージリソースＮ４（例えばストレージリソースＩＤ形式のノードＮ４）を示してもよい。データ構造メタデータは、示されたテナントのユーザについてのみアクセスを許可するために、それぞれの親ストレージリソース及び／又はオーナストレージリソース若しくはデータ構造に関連するテナントを例えばテナントＩＤ形式で更に示してもよい。

バックアップＢＵ８について、それぞれのデータ構造メタデータは親データストレージリソースＲ３（例えばストレージリソースＩＤ形式のリポジトリＲ３）及びオーナデータストレージリソースＮ１（例えばストレージリソースＩＤ形式のノードＮ１）を示してもよい。データ構造メタデータは、示されたテナントのユーザについてのみアクセスを許可するために、それぞれの親ストレージリソース及び／又はオーナストレージリソース若しくはデータ構造に関連するテナントを例えばテナントＩＤ形式で更に示してもよい。

バックアップＢＵ９について、それぞれのデータ構造メタデータは親データストレージリソースＲ３（例えばストレージリソースＩＤ形式のリポジトリＲ３）及びオーナデータストレージリソースＮ２（例えばストレージリソースＩＤ形式のノードＮ２）を示してもよい。データ構造メタデータは、示されたテナントのユーザについてのみアクセスを許可するために、それぞれの親ストレージリソース及び／又はオーナストレージリソース若しくはデータ構造に関連するテナントを例えばテナントＩＤ形式で更に示してもよい。

バックアップＢＵ１０について、それぞれのデータ構造メタデータは親データストレージリソースＲ３（例えばストレージリソースＩＤ形式のリポジトリＲ３）及びオーナデータストレージリソースＮ３（例えばストレージリソースＩＤ形式のノードＮ３）を示してもよい。データ構造メタデータは、示されたテナントのユーザについてのみアクセスを許可するために、それぞれの親ストレージリソース及び／又はオーナストレージリソース若しくはデータ構造に関連するテナントを例えばテナントＩＤ形式で更に示してもよい。

バックアップＢＵ１１について、それぞれのデータ構造メタデータは親データストレージリソースＲ３（例えばストレージリソースＩＤ形式のリポジトリＲ３）及びオーナデータストレージリソースＮ３（例えばストレージリソースＩＤ形式のノードＮ３）を示してもよい。データ構造メタデータは、テナントのユーザについてのみアクセスを許可するために、それぞれの親ストレージリソース及び／又はオーナストレージリソース若しくはデータ構造に関連するテナントを例えばテナントＩＤ形式で更に示してもよい。

バックアップＢＵ１２について、それぞれのデータ構造メタデータは親データストレージリソースＲ３（例えばストレージリソースＩＤ形式のリポジトリＲ３）及びオーナデータストレージリソースＮ４（例えばストレージリソースＩＤ形式のノードＮ４）を示してもよい。データ構造メタデータは、示されたテナントのユーザについてのみアクセスを許可するために、それぞれの親ストレージリソース及び／又はオーナストレージリソース若しくはデータ構造に関連するテナントを例えばテナントＩＤ形式で更に示してもよい。

他方で主データ構造について、それぞれのデータ構造メタデータは、それぞれのデータ構造を記憶するストレージリソースを示してもよい。データ構造メタデータは、示されたテナントのユーザについてのみアクセスを許可するために、それぞれのストレージリソース又はデータ構造に関連するテナントを例えばテナントＩＤ形式で更に示してもよい。

データ構造メタデータ内でテナントが更に示される場合、ユーザは、自らのテナントがデータ構造メタデータ内で示されるテナント（例えばテナントＩＤ）と一致する場合にのみ、特定のストレージリソース（又は特定のストレージリソース上のデータ構造）へのアクセスが与えられる。

リソースグループの例
一例として、図７のデータストレージシステムについて以下のリソースグループを例示的に定めてもよい：
−リソースグループＲＧ１＝｛Ｎ１，Ｎ２，Ｎ５，Ｒ１｝、
−リソースグループＲＧ２＝｛Ｎ２，Ｎ３，Ｎ５，Ｒ１，Ｎ７，Ｒ３｝、
−リソースグループＲＧ３＝｛Ｎ３，Ｎ４，Ｎ６，Ｒ２，Ｎ７，Ｒ３｝、及び
−リソースグループＲＧ４＝｛Ｎ２，Ｎ７，Ｒ３｝。

主データ構造について、ユーザのアクセス制御プロファイル内で示されたリソースグループは、ユーザがその上の主データ構造にアクセスすることができるストレージリソースを示してもよい。

例えば、リソースグループＲＧ１に関連するアクセス制御プロファイルに関連するユーザは、リソースグループＲＧ１のリソース上の主データ構造に、即ち例示的にはノードＮ１上のファイルシステムＦＳ１及びノードＮ２上のファイルシステムＦＳ２並びにノードＮ２上のデータベースＤＢ１にアクセスすることができ、それはノードＮ１及びＮ２がそれぞれのリソースノードＮ１内に含まれるからである。

従って、リソースグループＲＧ１に関連するアクセス制御プロファイルに関連するユーザは、ノードＮ３及びＮ４上の主データ構造ＦＳ３、ＤＢ２、ＤＢ３、及びＡＲ１のどれにたいしてもアクセスが拒否される。

例示的なアクセスレベル
先に論じたように、アクセス制御プロファイル情報は、好ましくは、それぞれのアクセス制御プロファイル内で示される又はそれぞれのアクセス制御プロファイルに関連するリソースグループごとに、それによって、アクセスレベルストレージリソース、特にそのようなストレージリソース上の副データ構造がそれぞれのユーザによってアクセスできる特定のアクセスレベルを好ましくは示してもよい従って好ましくは、アクセス制御プロファイル内の各リソースグループにアクセスレベルが与えられる。

例えば以下のアクセスレベルを与えることができる：
−第１アクセスレベル（グループアクセスレベル、限定アクセスレベルとも呼ばれてもよい）であって、この第１のアクセスレベルは、それぞれのユーザアカウントに関連するユーザによるユーザアクセスが、アクセス制御情報に従って許可される特定のリソースグループの中にそれぞれのオーナデータストレージリソースが含まれる副データ構造に、それぞれの親データストレージリソース上でアクセスすることを特定のリソースグループの第１アクセスレベルに関連するそれぞれのユーザアカウントのユーザが許可されることを示す。換言すれば、ユーザに関連するアクセス制御プロファイル内の特定のリソースグループについて第１アクセスレベルが指定されている場合、ユーザはその同じ特定のリソースグループの中のストレージリソースに由来する副データ構造にアクセスすることを可能にされる（例えば図７のリソースグループＲＧ１への第１アクセスレベルでは、ユーザはＢＵ１、ＢＵ２、及びＢＵ３を（それらがＮ１及びＮ２に由来するので）見ることはできるが、ＢＵ４は見ることができない）、
−第２アクセスレベル（オーナアクセスレベル、パーソナルアクセスレベルとも呼ばれてもよい）であって、この第２アクセスレベルは、特にそれぞれのユーザアカウントに関連するユーザによるユーザアクセスがアクセス制御情報に従って許可される特定のリソースグループの中に関連するそれぞれのオーナデータストレージリソースが含まれるという条件で、ユーザが現在ログインしているノードによって提供されるオーナデータストレージリソースに関連する副データ構造にそれぞれの親データストレージリソース上でアクセスすることを特定のリソースグループの第２アクセスレベルに関連するそれぞれのユーザアカウントのユーザが許可されることを示す。換言すれば、ユーザに関連するアクセス制御プロファイル内の特定のリソースグループについて第２アクセスレベルが指定されている場合、ユーザは自らがログインしているストレージリソースに由来する副データ構造にアクセスすることを可能にされる（例えば図７の資源群ＲＧ１への第２アクセスレベルでは、ノードＮ１においてログインしているユーザはＢＵ１を見ることはできるが、ＢＵ２、ＢＵ３、及びＢＵ４は見ることができず、しかし同じユーザがノードＮ２においてログインする場合、そのユーザはＢＵ２及びＢＵ３を見ることができ、ＢＵ１及びＢＵ４は見ることができない）、そして、
−第３アクセスレベル（フルアクセスレベル）であって、この第３アクセスレベルは、それぞれのユーザアカウントに関連するユーザによるユーザアクセスがアクセス制御情報に従って許可されるリソースグループの中に関連するそれぞれのオーナデータストレージリソースが含まれるかどうかに関係なく、それぞれの親データストレージリソース上に記憶される副データ構造にそれぞれの親データストレージリソース上でアクセスすることを第３アクセスレベルに関連するそれぞれのユーザアカウントのユーザが許可されることを示す。換言すれば、ユーザに関連するアクセス制御プロファイル内の特定のリソースグループについて第３アクセスレベルが指定されている場合、ユーザは特定のリソースグループの中の任意のストレージリソース上の全ての副データ構造にアクセスすることを可能にされる（例えば図７のリソースグループＲＧ１への第３アクセスレベルでは、Ｒ１にフルアクセスが付与されているのでユーザはＲ１上の全てのデータ構造（ＢＵ１、ＢＵ２、ＢＵ３、及びＢＵ４）を見ることができる）。

例えば、ノードＮ１を介してログインし、その上のファイルシステムＦＳ１へのアクセスを許可されており、リソースグループＲＧ１＝｛Ｎ１，Ｎ２，Ｎ５，Ｒ１｝及び第３（フル）アクセスレベルに関連するアクセス制御プロファイルに関連付けられているユーザは、バックアップＢＵ４がユーザの関連するリソースグループＲＧ１内に含まれないノード（ノードＮ３）上の一次データ構造（ＦＳ３）のバックアップコピーであっても、ＢＵ１、ＢＵ２、ＢＵ３、及び特にＢＵ４を含むリポジトリＲ１上の全ての二次データ構造に、アクセスすることができる。

しかし、第３アクセスレベル「フル」にもかかわらず、そのユーザはリポジトリＲ２及びＲ３上のどの副データ構造にも引き続きアクセスすることができず、それはそれらのリポジトリＲ２及びＲ３がリソースグループＲＧ１内に含まれておらず、アクセス制御に基づいて如何なるアクセス要求も拒否されるからである。

更に例示的には、ノードＮ１を介してログインし、リソースグループＲＧ１＝｛Ｎ１，Ｎ２，Ｎ５，Ｒ１｝及び第１（グループ又は限定）アクセスレベルに関連するアクセス制御プロファイルに関連付けられているユーザは、リポジトリＲ１上の副データ構造ＢＵ１、ＢＵ２、ＢＵ３しかアクセスすることができず、それはそれらのオーナストレージリソースがユーザのリソースグループＲＧ１内に含まれるストレージリソース（ノードＮ１及びＮ２）上で与えられるからである。

しかし、バックアップＢＵ４のオーナストレージリソース（ノードＮ３）はユーザのリソースグループＲＧ１内に含まれてないので、ＢＵ４の親ストレージリソース（リポジトリＲ１）がユーザのリソースグループＲＧ１内に含まれていても、それぞれのユーザはバックアップＢＵ４にアクセスすることができない。更に、リポジトリＲ２及びＲ３は資源群ＲＧ１内に含まれておらず、如何なるアクセス要求もアクセス制御に基づいて拒否されるので、そのユーザはリポジトリＲ２及びＲ３上の如何なる副データ構造にもアクセスすることができない。

更に例示的には、ノードＮ１によってログインし、リソースグループＲＧ１＝｛Ｎ１，Ｎ２，Ｎ５，Ｒ１｝及び第２（オーナ又はパーソナル）アクセスレベルに関連するアクセス制御プロファイルに関連付けられたユーザは、リポジトリＲ１上の副データ構造ＢＵ１しかアクセスすることができず、それはユーザがＢＵ１のオーナストレージリソース（ノードＮ１）に現在ログオンしているからである。

しかし、データ構造ＦＳ２及びＤＢ１を記憶するストレージリソースとしてのノードＮ２と、バックアップＢＵ２及びＢＵ３のオーナ記憶資源としてのノードＮ２と、バックアップＢＵ２及びＢＵ３の親ストレージリソース（リポジトリＲ１）は、ユーザのリソースグループＲＧ１及び親内に全て含まれるが、ユーザはバックアップＢＵ２及びＢＵ３のオーナストレージリソースであるノードＮ２に現在ログインしていないので、リポジトリＲ１上のそれらのバックアップＢＵ２及びＢＵ３に依然としてアクセスすることができない。

更に、バックアップＢＵ４のオーナストレージリソース（ノードＮ３）はユーザのリソースグループＲＧ１に含まれていないので、ＢＵ４の親ストレージリソース（リポジトリＲ１）がユーザのリソースグループＲＧ１内に含まれていても、それぞれのユーザはバックアップＢＵ４にアクセスすることができない。更に、リポジトリＲ２及びＲ３はリソースグループＲＧ１内に含まれておらず、如何なるアクセス要求もアクセス制御に基づいて拒否されるのいで、ユーザはリポジトリＲ２及びＲ３上の如何なる副データ構造にもアクセスすることができない。

更に例示的には、アクセスレベルに関係なく、リソースグループＲＧ２＝｛Ｎ２，Ｎ３，Ｎ５，Ｒ１，Ｎ７，Ｒ３｝に関連するアクセス制御プロファイルを有するユーザは、ノードＮ１及びＮ４上の主データ構造のどれにもアクセスすることができず、それは、これは、リソースグループＲＧ２内に含まれないからである。更に、ノードＮ６及びリポジトリＲ２はリソースグループＲＧ２内に含まれてないので、ユーザはノードＮ６及びリポジトリＲ２上の副データ構造のどれにもアクセスすることができない。

但しユーザは、リソースグループＲＧ２内に含まれるノードＮ２及びＮ３上の主データ構造にアクセスすることができる。

ノードＮ５及びＮ７並びにリポジトリＲ１及びＲ３がリソースグループＲＧ２内に含まれているので、アクセスレベルに応じてユーザはリポジトリＲ１及びＲ３上の特定の副データ構造にアクセスすることができる。

特に、「フル」アクセスレベル（第３アクセスレベル）の下では、ユーザはリポジトリＲ１及びＲ３上の全ての副データ構造にアクセスすることができる。

しかし「グループ」アクセスレベル（第１アクセスレベル）の下では、ユーザはリポジトリＲ１上のバックアップＢＵ１（ノードＮ１であるＢＵ１のオーナストレージリソースがリソースグループＲＧ２内に含まれないので）、リポジトリＲ３上のバックアップＢＵ８（ノードＮ１であるＢＵ８のオーナストレージリソースがリソースグループＲＧ２内に含まれないので）、及びリポジトリＲ３上のバックアップＢＵ１２（ノードＮ４であるＢＵ１２のオーナストレージリソースがリソースグループＲＧ２内に含まれないので）のデータ構造にアクセスすることはできない。

リソースグループＲＧ２に関連するユーザが「オーナ」アクセスレベル（第２アクセスレベル）の下でノードＮ２にログインしている場合、ユーザはリポジトリＲ１及びＲ３上のバックアップＢＵ２、ＢＵ３、及びＢＵ９にしかアクセスできず、それはそれらのバックアップはオーナストレージリソースとしてユーザがログインしているノードＮ２を有する副データ構造だからである。

更に例示的には、アクセスレベルに関係なく、リソースグループＲＧ３＝｛Ｎ３，Ｎ４，Ｎ６，Ｒ２，Ｎ７，Ｒ３｝に関連するアクセス制御プロファイルを有するユーザは、ノードＮ１及びＮ２上の主データ構造のどれにもアクセスすることができず、それはノードＮ１及びＮ２がリソースグループＲＧ３内に含まれないからである。更に、ノードＮ５及びリポジトリＲ１はリソースグループＲＧ３内に含まれないので、ユーザはノードＮ５及びリポジトリＲ１上の副データ構造のどれにもアクセスすることができない。

但しユーザは、リソースグループＲＧ３内に含まれるノードＮ３及びＮ４上の主データ構造にアクセスすることができる。ノードＮ６及びＮ７並びにリポジトリＲ２及びＲ３がリソースグループＲＧ３内に含まれるので、アクセスレベルに応じてユーザはリポジトリＲ２及びＲ３上の特定の副データ構造にアクセスすることができる。

特に、「フル」アクセスレベル（第３アクセスレベル）の下では、ユーザはリポジトリＲ２及びＲ３上の全ての副データ構造にアクセスすることができる。

しかし「グループ」アクセスレベル（第１アクセスレベル）の下では、ユーザはリポジトリＲ３上のバックアップＢＵ８（ノードＮ１であるＢＵ８のオーナストレージリソースがリソースグループＲＧ３内に含まれないので）、及びリポジトリＲ３上のバックアップＢＵ９（ノードＮ２であるＢＵ９のオーナストレージリソースがリソースグループＲＧ３内に含まれないので）のデータ構造にアクセスすることはできない。

リソースグループＲＧ３に関連するユーザが「オーナ」アクセスレベル（第２アクセスレベル）の下でノードＮ３にログインしている場合、ユーザはリポジトリＲ２及びＲ３上のバックアップＢＵ５、ＢＵ１０、及びＢＵ１１にしかアクセスできず、それはそれらは、オーナストレージリソースとしてユーザがログインしているノードＮ３を有する副データ構造だからである。

更に例示的には、アクセスレベルに関係なく、リソースグループＲＧ４＝｛Ｎ２，Ｎ７，Ｒ３｝に関連するアクセス制御プロファイルを有するユーザは、ノードＮ１、Ｎ３、及びＮ４上の主データ構造のどれにもアクセスすることができず、それはノードＮ１、Ｎ３、及びＮ４がリソースグループＲＧ４内に含まれないからである。更に、ノードＮ５及びリポジトリＲ１並びにノードＮ６及びリポジトリＲ２はリソースグループＲＧ４内に含まれないので、ユーザはノードＮ５及びリポジトリＲ１並びにノードＮ６及びリポジトリＲ２上の副データ構造のどれにもアクセスすることができない。

但しユーザは、資源群ＲＧ４内に含まれるノードＮ２上の主データ構造にアクセスすることができる。ノードＮ７及びリポジトリＲ３がリソースグループＲＧ４内に含まれるので、アクセスレベルに応じて、ユーザはリポジトリＲ３上の特定の副データ構造にアクセスすることができる。

特に、「フル」アクセスレベル（第３アクセスレベル）の下では、ユーザはリポジトリＲ３上の全ての副データ構造にアクセスすることができる。

しかし「グループ」アクセスレベル（第１アクセスレベル）の下では、又はユーザのリソースグループＲＧ４内に含まれる主データ構造の唯一のノードであるノードＮ２によってログインしている場合は「オーナ」アクセスレベル（第２アクセスレベル）の下でも、ユーザはリポジトリＲ３上のバックアップＢＵ９のデータ構造にしかアクセスすることができず、それはＢＵ９がリソースグループＲＧ４内に含まれるオーナストレージリソースを有するリポジトリＲ３上の唯一の副データ構造だからである。

更に例示的には、「オーナ」アクセスレベル（第２アクセスレベル）の下では、ユーザがアクセスできるリソースグループの何れにも含まれないストレージノードにおいてユーザがログインする場合、そのユーザはストレージリソース上のどの副データ構造も見えない。例えば図７のリソースグループＲＧ１に関する第２アクセスレベルを有するユーザがストレージノードＮ４においてログインする場合、そのユーザはＲ１内のどの副データ構造も見えない。

上記の内容に鑑みて、例示的実施形態では、主データ構造及び副データ構造へのアクセス制御のための効率的且つ高信頼並びに非常に柔軟なアクセス制御スキームを、例えば１又は複数のリソースグループを示す及び／又は主データ構造に基づいて作成される副データ構造へのアクセスに関する様々なアクセスレベルを示すアクセス制御プロファイルに基づいて提供することができる。更に、それらのアクセス制御スキームは、例えばアクセス制御プロファイルに関連する活動グループ及び／又は活動に基づいて役割ベースアクセス制御（ＲＢＡＣ）及び活動許可と高信頼且つ効率的に組み合わせることができる。データストレージリソースへのユーザアクセスをテナントに基づいて許可するために、かかる態様はテナント区別スキームと共に更に定めることができる。

更に、例示的実施形態では、例えば上記の例示的なストレージハンドラ又はリソースハンドリングコントローラ等のエンドポイントコントローラの管理において、ユーザのアクセス制御プロファイルを示すペイロードをユーザのアクセス要求に実装する又は埋め込むことにより、及び／又はデータ構造に関するメタデータを保つことにより、分散システム内に非集中アクセス制御スキームを与えることが有利に可能であり、そのことは中央承認モジュール／装置又は例示的なＵＩＣ（ユーザインタフェースコントローラ）等のユーザインタフェース管理装置／モジュールにおける所要の通信帯域幅及び処理負荷をそのいくつかの例示的実施形態において減らす。

当業者によって理解されるように、上記の及び添付図面に記載の本発明は方法（例えばコンピュータによって実施されるプロセス、ビジネスプロセス、又は他の任意のプロセス）、装置（デバイス、機械、システム、コンピュータプログラム製品、及び／又は他の任意の装置を含む）、又は上記のものの組み合わせとして具体化することができる。

従って、本発明の実施形態は完全にハードウェアの実施形態、完全にソフトウェアの実施形態（ファームウェア、常駐ソフトウェア、マイクロコード等を含む）、又は本明細書で「システム」と広く呼ばれ得るソフトウェアの側面とハードウェアの側面とを組み合わせる実施形態の形を取ってもよい。更に本発明の実施形態は、コンピュータ実行可能プログラムコードが媒体に具体化されたコンピュータ可読媒体上のコンピュータプログラム製品の形を取ってもよい。

図中、矢印は２つ以上のエンティティが関与する通信、転送、又は他の活動を表すために使用されてもよいことに留意すべきである。双方向矢印は活動が双方向に行われ得ること（例えば或る方向のコマンド／要求と他の方向の対応する返信、又は何れかのエンティティによって開始されるピアツーピア通信）を概して示すが、状況によっては活動が必ずしも双方向に行われなくてもよい。

単方向矢印は専ら又は主に一方向の活動を概して示すが、特定の状況ではかかる方向性の活動が実際には双方向の活動（例えば送信者から受信者へのメッセージと受信者から送信者に返される肯定応答、又は転送前の接続の確立と転送後の接続の終了）を含んでもよいことに留意すべきである。従って、特定の活動を表すために特定の図面の中で使用される矢印の種類は例示的であり、限定的と見なすべきではない。

本発明の実施形態を方法及び装置のフローチャート及び／又はブロック図に関して、並びにそれらの方法及び／又は装置によって生成されるグラフィカルユーザインタフェースの幾つかのサンプルビューに関して上記で記載してきた。フローチャート及び／又はブロック図の各ブロック、及び／又は流れ図及び／又はブロック図の中のブロックの組み合わせ、並びにグラフィカルユーザインタフェースはコンピュータ実行可能プログラムコードによって実装され得ることが理解されよう。

コンピュータ実行可能プログラムコードは、特定の機械を作り出すために汎用コンピュータ、専用コンピュータ、又は他のプログラム可能データ処理装置のプロセッサに与えられてもよく、それによりコンピュータ又は他のプログラム可能データ処理装置のプロセッサによって実行されるプログラムコードが、フローチャート、ブロック図の１又は複数のブロック、図面、及び／又は記載の説明の中で明記した機能／動作／出力を実装するための手段を作り出す。

これらのコンピュータ実行可能プログラムコードは、特定の方法で機能するようにコンピュータ又は他のプログラム可能データ処理装置に指示することができるコンピュータ可読メモリ内に記憶してもよく、それによりコンピュータ可読メモリ内に記憶されたプログラムコードがフローチャート、ブロック図の１又は複数のブロック、図面、及び／又は記載の説明の中で明記した機能／動作／出力を実施する命令手段を含む製品をもたらす。
コンピュータ実行可能プログラムコードは、コンピュータ又は他のプログラム可能装置上で実行される一連の動作上のステップを生じさせて、コンピュータによって実施されるプロセスをもたらすためにコンピュータ又は他のプログラム可能データ処理装置上にロードすることもでき、それによりコンピュータ又は他のプログラム可能装置上で実行されるプログラムコードがフローチャート、ブロック図のブロック（複数も可）、図面、及び／又は記載の説明の中で明記した機能／動作／出力を実施するためのステップをもたらす。それに代えて、本発明の実施形態を実行するために、コンピュータプログラムによって実施されるステップ又は動作をオペレータ又は人間によって実施されるステップ又は動作と組み合わせてもよい。

本明細書では、「サーバ」及び「プロセッサ」等の用語は、本発明の特定の実施形態の中で使用され得るデバイスを記述するために使用してもよく、文脈上他の意味に解すべき場合を除き、本発明を或る特定の装置の種類に限定するものだと解釈すべきではない。従ってデバイスは、ブリッジ、ルータ、ブリッジルータ（ブルータ）、スイッチ、ノード、サーバ、コンピュータ、器具、又は他の種類のデバイスを制限なしに含み得る。かかるデバイスは、通信ネットワーク上で通信するための１又は複数のネットワークインタフェース及びデバイスの機能を実行するようにしかるべく構成されるプロセッサ（例えばメモリ及び他の周辺装置及び／又は特定用途向けハードウェアを有するマイクロプロセッサ）を典型的には含む。

通信ネットワークはパブリックネットワーク及び／又はプライベートネットワークを概して含んでもよく、ローカルエリア、広域、都市圏、ストレージ、及び／又は他の種類のネットワークを含んでもよく、アナログ技術、デジタル技術、光学技術、無線技術（例えばＢｌｕｅｔｏｏｔｈ（登録商標））、ネットワーキング技術、及びインターネットワーキング技術を含むがこれだけに決して限定されない通信技術を採用することができる。

デバイスは通信プロトコル及びメッセージ（例えばデバイスによって作成され、伝送され、受信され、記憶され、及び／又は処理されるメッセージ）を使用してもよく、それらのメッセージが通信ネットワーク又は通信媒体によって搬送されてもよいことにも留意すべきである。

文脈上他の意味に解すべき場合を除き、本発明は或る特定の通信メッセージの種類、通信メッセージの形式、又は通信プロトコルに限定されるものとして解釈すべきではない。従って通信メッセージは、典型的に、フレーム、パケット、データグラム、ユーザデータグラム、セル、又は他の種類の通信メッセージを制限なしに含んでもよい。

文脈上他の意味に解すべき場合を除き、特定の通信プロトコルへの言及は例示的であり、代替的実施形態はかかる通信プロトコルの改変形態（例えば適宜行われ得るプロトコルの修正又は拡張）又は既知の若しくは将来開発される他のプロトコルを必要に応じて採用してもよいことを理解すべきである。

本明細書では、ロジックフローは本発明の様々な態様を実証するために本明細書で説明することがあり、或る特定のロジックフロー又はロジック実装に本発明を限定するものだと解釈すべきではない。全体的な結果を変えることなしに、或いは本発明の真の範囲から逸脱することなしに、記載のロジックは様々なロジックブロック（例えばプログラム、モジュール、関数、又はサブルーチン）へと区分化してもよい。

全体的な結果を変えることなしに、或いは本発明の真の範囲から逸脱することなしに、多くの場合、論理要素は追加し、修正し、省略し、異なる順序で実行し、又は様々な論理構造（例えば論理ゲート、ループ基本命令、条件付きロジック、及び他の論理構造）を使用して実装してもよい。

本発明は、プロセッサ（例えばマイクロプロセッサ、マイクロコントローラ、デジタル信号プロセッサ、又は汎用コンピュータ）用のコンピュータプログラムロジック、プログラム可能論理装置（例えば書換可能ゲートアレイ（ＦＰＧＡ）又は他のＰＬＤ）用のプログラム可能ロジック、個別の構成要素、集積回路（例えば特定用途向け集積回路（ＡＳＩＣ））、又はそれらの任意の組み合わせを含む他の任意の手段を含むがこれだけに決して限定されない多くの異なる形式で具体化することができる。記載した機能の一部又は全てを実装するコンピュータプログラムロジックは、典型的にはコンピュータ実行可能形式に変換され、そのようにコンピュータ可読媒体内に記憶され、オペレーティングシステムの制御下でマイクロプロセッサによって実行されるコンピュータプログラム命令のセットとして実装される。記載した機能の一部又は全てを実装するハードウェアベースのロジックは、１又は複数の適切に構成されたＦＰＧＡを使用して実装してもよい。

本明細書で先に記載した機能の全て又は一部を実装するコンピュータプログラムロジックは、ソースコード形式、コンピュータ実行可能形式、及び様々な中間形式（例えばアセンブラ、コンパイラ、リンカ、又はロケータによって生成される形式）を含むがこれだけに決して限定されない様々な形式で実施してもよい。

ソースコードは、様々なオペレーティングシステム又はオペレーティング環境用の、様々なプログラミング言語（例えばオブジェクトコード、アセンブリ言語、又はＦｏｒｔｒａｎ、Ｃ、Ｃ＋＋、ＪＡＶＡ（登録商標）、若しくはＨＴＭＬ等の高級言語）の何れかによって実装される一連のコンピュータプログラム命令を含んでもよい。ソースコードは、様々なデータ構造及び通信メッセージを定義し使用してもよい。ソースコードは、（例えばインタプリタによって）コンピュータ実行可能形式であってもよく、又はソースコードは、（例えばトランスレータ、アセンブラ、又はコンパイラによって）コンピュータ実行可能形式に変換されてもよい。

本発明の実施形態の動作を実行するためのコンピュータ実行可能プログラムコードは、Ｊａｖａ（登録商標）、Ｐｅｒｌ、Ｓｍａｌｌｔａｌｋ、Ｃ＋＋等のオブジェクト指向プログラミング言語、スクリプトプログラミング言語、又は非スクリプトプログラミング言語で書かれてもよい。但し本発明の実施形態の動作を実行するためのコンピュータプログラムコードは、「Ｃ」プログラミング言語又は同様のプログラミング言語等の従来の手続き型プログラミング言語で書かれてもよい。

本明細書で先に記載した機能の全て又は一部を実装するコンピュータプログラムロジックは、単一のプロセッサ上で様々な時点において（例えば同時に）実行されてもよく、又は複数のプロセッサ上で同じ時点若しくは異なる時点において実行されてもよく、単一のオペレーティングシステムプロセス／スレッドの下で又は異なるオペレーティングシステムプロセス／スレッドの下で実行されてもよい。

従って「コンピュータプロセス」という用語は、様々なコンピュータプロセスが同じプロセッサ上で実行されるか異なるプロセッサ上で実行されるかに関係なく、及び様々なコンピュータプロセスが同じオペレーティングシステムプロセス／スレッドの下で実行され又は異なるオペレーティングシステムプロセス／スレッドの下で実行されるかに関係なく、コンピュータプログラム命令のセットの実行を広く指す。

コンピュータプログラムは任意の形式（例えばソースコード形式、コンピュータ実行可能形式、又は中間形式）で、半導体メモリデバイス（例えばＲＡＭ、ＲＯＭ、ＰＲＯＭ、ＥＥＰＲＯＭ、又はフラッシュプログラム可能ＲＡＭ）、磁気メモリデバイス（例えばディスケット又は固定ディスク）、光学メモリデバイス（例えばＣＤ−ＲＯＭ）、ＰＣカード（例えばＰＣＭＣＩＡカード）、又は他のメモリデバイス等の有形の記憶媒体の中に永続的に又は一時的に固定してもよい。

コンピュータプログラムは、アナログ技術、デジタル技術、光学技術、無線技術（例えばＢｌｕｅｔｏｏｔｈ）、ネットワーキング技術、及びインターネットワーキング技術を含むがこれだけに決して限定されない様々な通信技術の何れかを使用してコンピュータに伝送することができる信号の中に任意の形式で固定してもよい。

コンピュータプログラムは、付属の印刷文書又は電子文書を有するリムーバブル記憶媒体（例えばシュリンクラップソフトウェア）として任意の形式で配布させてもよく、コンピュータシステムに（例えばシステムＲＯＭ又は固定ディスク上に）予めロードさせてもよく、又は通信システム（例えばインターネット又はワールドワイドウェブ）上でサーバ又は電子掲示板から配布させてもよい。

本明細書で先に記載した機能の全て又は一部を実装するハードウェアロジック（プログラム可能論理デバイス用のプログラム可能ロジックを含む）は、従来の手動方法を使用して設計してもよく、又は計算機援用設計（ＣＡＤ）、ハードウェア記述言語（例えばＶＨＤＬ又はＡＨＤＬ）、若しくはＰＬＤプログラミング言語（例えばＰＡＬＡＳＭ、ＡＢＥＬ、又はＣＵＰＬ）等の様々なツールを使用して電子的に設計し、捕捉し、シミュレートし、若しくは文書化してもよい。

任意の適切なコンピュータ可読媒体が利用されてもよい。コンピュータ可読媒体は、例えばこれだけに限定されないが、電子、磁気、光学、電磁、赤外、又は半導体のシステム、装置、デバイス、又は媒体であってもよい。

コンピュータ可読媒体のより具体的な例は、これだけに限定されないが、１又は複数の配線を有する電気接続、又はポータブルコンピュータディスケット、ハードディスク、ランダムアクセスメモリ（ＲＡＭ）、読取専用メモリ（ＲＯＭ）、消去可能なプログラム可能読取専用メモリ（ＥＰＲＯＭ又はフラッシュメモリ）、コンパクトディスク読取専用メモリ（ＣＤ−ＲＯＭ）、又は他の光学記憶デバイス若しくは磁気記憶デバイス等の他の有形記憶媒体を含む。

プログラム可能ロジックは、半導体メモリデバイス（例えばＲＡＭ、ＲＯＭ、ＰＲＯＭ、ＥＥＰＲＯＭ、又はフラッシュプログラム可能ＲＡＭ）、磁気メモリデバイス（例えばディスケット又は固定ディスク）、光学メモリデバイス（例えばＣＤ−ＲＯＭ）、又は他のメモリデバイス等の有形記憶媒体の中に永続的に又は一時的に固定してもよい。

プログラム可能ロジックは、アナログ技術、デジタル技術、光学技術、無線技術（例えばＢｌｕｅｔｏｏｔｈ）、ネットワーキング技術、及びインターネットワーキング技術を含むがこれだけに決して限定されない様々な通信技術の何れかを使用してコンピュータに伝送することができる信号の中に固定してもよい。

プログラム可能ロジックは、付属の印刷文書又は電子文書を有するリムーバブル記憶媒体（例えばシュリンクラップソフトウェア）として配布させてもよく、コンピュータシステムに（例えばシステムＲＯＭ又は固定ディスク上に）予めロードしてもよく、又は通信システム（例えばインターネット又はワールドワイドウェブ）上でサーバ又は電子掲示板から配布させてもよい。当然ながら、本発明の一部の実施形態はソフトウェア（例えばコンピュータプログラム製品）及びハードウェア両方の組み合わせとして実装してもよい。本発明の更に他の実施形態は完全にハードウェアとして、又は完全にソフトウェアとして実装される。

特定の例示的実施形態を説明し添付図面の中に示したが、上記の段落の中で記載したものに加えて他の様々な変更、組み合わせ、省略、修正、及び置換が可能なので、それらの実施形態は広範な発明の例示にすぎず、広範な発明を限定しておらず、本発明の実施形態は図示及び説明した特定の仕組み及び構成に限定されないことを理解すべきである。

本発明の範囲及び趣旨から逸脱することなしに、ちょうど記載した実施形態の様々な適合、修正、及び／又は組み合わせを構成できることを当業者なら理解されよう。従って、添付の特許請求の範囲内で、本発明は本明細書で具体的に記載した以外のやり方で実践できることを理解すべきである。例えば別段の定めがない限り、本明細書で記載したプロセスのステップは本明細書に記載したのと異なる順序で実行してもよく、１又は複数のステップを組み合わせる、分割する、又は同時に実行してもよい。

本開示に鑑みて、本明細書に記載した本発明の様々な実施形態を組み合わせて本発明の他の実施形態を形成できることも当業者なら理解されよう。

Claims (15)

1. 複数のデータストレージリソースを提供する１又は複数のノードを含むデータストレージシステムへのユーザアクセスを制御するための方法であって、
   前記複数のデータストレージリソースは、１又は複数のユーザアクセス可能主データ構造及び１又は複数のユーザアクセス可能副データ構造を記憶し、各副データ構造はそれぞれの関連主データ構造に基づいて記憶され、
   前記データストレージシステムは、副データ構造ごとに、前記それぞれの副データ構造の親データストレージリソース及びオーナデータストレージリソースを示すデータ構造メタデータを記憶し、
   前記それぞれの副データ構造の前記親データストレージリソースは、前記それぞれの副データ構造を記憶する前記データストレージリソースであり、前記それぞれの副データ構造の前記オーナデータストレージリソースは前記それぞれの副データ構造の前記それぞれの関連主データ構造を記憶する前記データストレージリソースであり、
   前記データストレージシステムは、１又は複数のユーザアカウントのそれぞれについて、前記それぞれのユーザアカウントに関連する前記ユーザによるユーザアクセスが許可されている１又は複数のデータストレージリソースの少なくとも１つのリソースグループを示すアクセス制御情報を更に記憶し、
   前記方法は、
   −それぞれの親データストレージリソース上に記憶されている前記１又は複数の副データ構造の特定の副データ構造にアクセスするためのユーザ要求を受信し、
   −前記特定の副データ構造について記憶されているデータ構造メタデータに基づいて、前記特定の副データ構造の前記それぞれのオーナデータストレージリソースを決定し、
   −前記ユーザ要求に関連する前記ユーザアカウントの前記ユーザが、前記特定の副データ構造にアクセスすることを許可されているか否かをアクセス制御確認プロセスに基づいて決定し、前記アクセス制御確認プロセスは、前記アクセス制御情報に基づいて、前記特定の副データ構造の前記決定されたオーナデータストレージリソースが前記ユーザ要求に関連する前記ユーザアカウントの前記ユーザによってアクセスされることを許可されているか否かを決定すること を含む、方法。
2. 前記データストレージシステムは、ユーザ要求を受信するように構成されているユーザインタフェースコントローラを更に含み、
   前記方法は、
   −前記ユーザ要求に関連する前記ユーザアカウントの前記ユーザが前記ユーザインタフェースコントローラに対する通信接続を開始するときであるセッションの開始時に、前記アクセス制御情報に基づいて、前記それぞれのユーザアカウントに関連する前記ユーザによるユーザアクセスが許可されている１又は複数のデータストレージリソースの少なくとも１つのリソースグループを示すユーザアクセス制御プロファイルを取得する承認プロセスを実行すること
   を更に含む、請求項１に記載の方法。
3. −前記それぞれのユーザアカウントに関連する前記ユーザの前記ユーザアクセス制御プロファイルを示すペイロードを作成し、
   前記方法は、
   −前記ユーザインタフェースコントローラにおいて前記特定の副データ構造にアクセスするための前記ユーザ要求を受信したとき、前記それぞれのユーザアカウントに関連する前記ユーザの前記ユーザ要求内に前記作成されたペイロードを含めること
   を更に含む、請求項２に記載の方法。
4. 前記データストレージシステムは、１又は複数のリソースハンドリングコントローラを更に含み、各リソースハンドリングコントローラは、前記データストレージシステムの１又は複数のデータストレージリソースへのユーザアクセスを管理するように構成され、
   前記方法は、
   −前記ユーザインタフェースコントローラから前記特定の副データ構造の前記親データストレージリソースへのアクセスを管理する前記リソースハンドリングコントローラに、前記作成されたペイロードを含む前記ユーザ要求を送信すること を更に含む、請求項３に記載の方法。
5. 各リソースハンドリングコントローラは、前記それぞれのリソースハンドリングコントローラによって管理される前記１又は複数のデータストレージリソース上に記憶される前記副データ構造に関係する前記データ構造メタデータを管理するように更に構成され、
   前記方法は、
   −前記特定の副データ構造の前記親データストレージリソースへのアクセスを管理する前記リソースハンドリングコントローラにおいて、前記作成されたペイロードを含む前記ユーザ要求を受信すること
   を更に含み、
   前記特定の副データ構造の前記それぞれのオーナデータストレージリソースを決定すること、及び前記ユーザ要求に関連する前記ユーザアカウントの前記ユーザが前記特定の副データ構造にアクセスすることを許可されているか否かを決定することが、前記それぞれのリソースハンドリングコントローラによって管理される前記データ構造メタデータ及び前記受信されたユーザ要求内に含まれている前記ペイロードに基づいて、前記特定の副データ構造の前記親データストレージリソースへのアクセスを管理する前記リソースハンドリングコントローラによって実行される、
   請求項４に記載の方法。
6. 前記ユーザ要求に関連する前記ユーザアカウントの前記ユーザが前記特定の副データ構造にアクセスすることを許可されているか否かを決定することは、前記特定の副データ構造の前記親データストレージリソースが前記ユーザ要求に関連する前記ユーザアカウントの前記ユーザによってアクセスされることを許可されているか否かを前記アクセス制御情報に基づいて決定することに更に基づく、
   請求項１に記載の方法。
7. 前記それぞれのユーザアカウントに関連する前記ユーザによるユーザアクセスが前記アクセス制御情報に従って許可されているリソースグループの中に前記特定の副データ構造の前記それぞれの親データストレージリソースが含まれるという条件で、前記ユーザ要求に関連する前記ユーザアカウントの前記ユーザは前記特定の副データ構造にアクセスすることを許可されると決定される、
   請求項６に記載の方法。
8. 前記アクセス制御情報は、前記１又は複数のユーザアカウントのそれぞれについて１又は複数のアクセスレベルを更に示し、
   −前記１又は複数のアクセスレベルの第１アクセスレベルは、前記第１アクセスレベルに関連する前記それぞれのユーザアカウントのユーザが、前記それぞれのユーザアカウントに関連する前記ユーザによるユーザアクセスが前記アクセス制御情報に従って許可されるリソースグループの中に前記それぞれのオーナデータストレージリソースが含まれる１又は複数の副データ構造に、それぞれの親データストレージリソース上でアクセスすることを許可されることを示し、
   −前記１又は複数のアクセスレベルの第２アクセスレベルは、前記第２アクセスレベルに関連する前記それぞれのユーザアカウントのユーザが、特に前記それぞれのユーザアカウントに関連する前記ユーザによるユーザアクセスが前記アクセス制御情報に従って許可されるリソースグループの中に前記関連するそれぞれのオーナデータストレージリソースが含まれるという条件で、前記ユーザが現在ログインしているノードによって提供される１又は複数のオーナデータストレージリソースに関連する１又は複数の副データ構造にそれぞれの親データストレージリソース上でアクセスすることを許可されることを示し、及び／又は
   −前記１又は複数のアクセスレベルの第３アクセスレベルは、前記第３アクセスレベルに関連する前記それぞれのユーザアカウントのユーザが、前記それぞれのユーザアカウントに関連する前記ユーザによるユーザアクセスが前記アクセス制御情報に従って許可されるリソースグループの中に前記１又は複数の関連するそれぞれのオーナデータストレージリソースが含まれるかどうかに関係なく、前記それぞれの親データストレージリソース上に記憶される前記１又は複数の副データ構造にそれぞれの親データストレージリソース上でアクセスすることを許可されることを示す、
   請求項１に記載の方法。
9. 前記アクセス制御情報が、前記１又は複数のユーザアカウントのそれぞれについて、前記それぞれのユーザアカウントに関連する前記ユーザによるユーザアクセスが許可されている前記リソースグループのデータストレージリソースに対して前記それぞれのユーザアカウントに関連する前記ユーザによって実行されることが許可されている少なくとも１つの許容ユーザ活動、又は少なくとも１つの許容ユーザ活動を含む少なくとも１つの活動グループを更に示す、
   請求項１に記載の方法。
10. 前記ユーザ要求に関連する前記ユーザアカウントの前記ユーザが前記特定の副データ構造にアクセスすることを許可されているか否かを決定することは、前記ユーザ要求によって要求されるそれぞれのユーザ活動が前記ユーザ要求に関連する前記ユーザアカウントの前記ユーザによって実行されることが許可されているか否かを前記アクセス制御情報に基づいて決定ことに更に基づく、
    請求項９に記載の方法。
11. 前記アクセス制御情報は、ＲＢＡＣ（役割ベースアクセス制御）情報を含み、前記ＲＢＡＣ情報は、前記１又は複数のユーザアカウントのそれぞれについて、前記それぞれのユーザアカウントに関連する前記それぞれのユーザのユーザ役割を更に示し、
    各ユーザ役割は、少なくとも１つの許容ユーザ活動、又は少なくとも１つの許容ユーザ活動を含む少なくとも１つの活動グループに関連付けられ、
    前記ユーザアクセス制御プロファイルは、前記それぞれのユーザアカウントに関連する前記ユーザに関連する前記ユーザ役割を更に示し、前記作成済みのペイロードは、前記それぞれのユーザアカウントに関連する前記ユーザに関連する前記ユーザ役割を更に示す、請求項３に記載の方法。
12. 前記作成されたペイロードは、前記それぞれのユーザアカウントに関連する前記ユーザに関連する前記それぞれのユーザ役割に関連する前記少なくとも１つの許容ユーザ活動、又は少なくとも１つの許容ユーザ活動を含む少なくとも１つの活動グループを更に示す、
    請求項１１に記載の方法。
13. 前記データストレージシステムは、１又は複数のリソースハンドリングコントローラを更に含み、それぞれの各リソースハンドリングコントローラは、１又は複数のユーザ役割のそれぞれについて、前記それぞれのユーザ役割に関連する前記少なくとも１つの許容ユーザ活動、又は少なくとも１つの許容ユーザ活動を含む少なくとも１つの活動グループを示す活動メタデータを管理するように更に構成され、
    前記ユーザ要求に関連する前記ユーザアカウントの前記ユーザが前記特定の副データ構造にアクセスすることを許可されているか否かを決定することが、前記それぞれのリソースハンドリングコントローラによって管理される前記活動メタデータ及び前記受信されるユーザ要求内に含まれる前記ペイロードに基づき、前記ユーザ要求によって要求されるそれぞれのユーザ活動が前記ユーザ要求に関連する前記ユーザアカウントの前記ユーザによって実行されることが許可されているか否かを決定することに更に基づく、
    請求項１２に記載の方法。
14. 複数のデータストレージリソースを提供する１又は複数のノードを含むデータストレージシステムであって、
    前記複数のデータストレージリソースは１又は複数のユーザアクセス可能主データ構造及び１又は複数のユーザアクセス可能副データ構造を記憶するように構成され、各副データ構造はそれぞれの関連主データ構造に基づいて記憶され、
    前記データストレージシステムは、副データ構造ごとに、前記それぞれの副データ構造の親データストレージリソース及びオーナデータストレージリソースを示すデータ構造メタデータを記憶するように構成され、
    前記それぞれの副データ構造の前記親データストレージリソースは前記それぞれの副データ構造を記憶する前記データストレージリソースであり、前記それぞれの副データ構造の前記オーナデータストレージリソースは前記それぞれの副データ構造の前記それぞれの関連主データ構造を記憶する前記データストレージリソースであり、
    前記データストレージシステムは、１又は複数のユーザアカウントのそれぞれについて、前記それぞれのユーザアカウントに関連する前記ユーザによるユーザアクセスが許可されている１又は複数のデータ記憶資源の少なくとも１つのリソースグループを示すアクセス制御情報を記憶するように更に構成され、
    前記データストレージシステム又は前記データストレージシステムの１又は複数のノードは、それぞれの親データストレージリソース上に記憶される前記１又は複数の副データ構造の特定の副データ構造にアクセスするためのユーザ要求を受信するとき、
    −前記特定の副データ構造について記憶されているデータ構造メタデータに基づいて前記特定の副データ構造の前記それぞれのオーナデータストレージリソースを決定すること、及び
    −前記ユーザ要求に関連する前記ユーザアカウントの前記ユーザが前記特定の副データ構造にアクセスすることを許可されているか否かをアクセス制御確認プロセスに基づいて決定することを実行するように構成され、前記アクセス制御確認プロセスは、前記特定の副データ構造の前記決定されたオーナデータストレージリソースが前記ユーザ要求に関連する前記ユーザアカウントの前記ユーザによってアクセスされることを許可されているか否かを前記アクセス制御情報に基づいて決定する
    データストレージシステム。
15. 複数のデータストレージリソースを提供する１又は複数のノードを含むデータストレージシステムへのユーザアクセスを制御するためのコンピュータプログラムであって、
    前記複数のデータストレージリソースは１又は複数のユーザアクセス可能主データ構造及び１又は複数のユーザアクセス可能副データ構造を記憶し、各副データ構造はそれぞれの関連主データ構造に基づいて記憶され、前記データストレージシステムは、前記それぞれの副データ構造の親データストレージリソース及びオーナデータストレージリソースを示すデータ構造メタデータを副データ構造ごとに記憶し、前記それぞれの副データ構造の前記親データストレージリソースは前記それぞれの副データ構造を記憶する前記データストレージリソースであり、前記それぞれの副データ構造の前記オーナデータストレージリソースは前記それぞれの副データ構造の前記それぞれの関連主データ構造を記憶する前記データストレージリソースであり、前記データストレージシステムは、１又は複数のユーザアカウントのそれぞれについて、前記それぞれのユーザアカウントに関連する前記ユーザによるユーザアクセスが許可されている１又は複数のデータストレージリソースの少なくとも１つのリソースグループを示すアクセス制御情報を更に記憶し、
    前記コンピュータプログラムは、それぞれの親データストレージリソース上に記憶される前記１又は複数の副データ構造の特定の副データ構造にアクセスするためのユーザ要求の受信時に、少なくとも１個のプロセッサを有する装置若しくはシステム上で実行されるとき又は装置若しくはシステム内にロードされるとき、
    −前記特定の副データ構造について記憶されるデータ構造メタデータに基づいて前記特定の副データ構造の前記それぞれのオーナデータストレージリソースを決定すること、及び
    −前記ユーザ要求に関連する前記ユーザアカウントの前記ユーザが前記特定の副データ構造にアクセスすることを許可されているか否かをアクセス制御確認プロセスに基づいて決定することであって、、前記アクセス制御確認プロセスは前記特定の副データ構造の前記決定されたオーナデータストレージリソースが前記ユーザ要求に関連する前記ユーザアカウントの前記ユーザによってアクセスされることを許可されているか否かを前記アクセス制御情報に基づいて決定することを含むこと
    を前記少なくとも１個のプロセッサに実行させるコンピュータ可読プログラム命令を含む、
    コンピュータプログラム。

Images