特許 7596414 マルチテナント管理システムおよび方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-11-29

(45)【発行日】2024-12-09

(54)【発明の名称】マルチテナント管理システムおよび方法

(51)【国際特許分類】

   G06F 21/62 20130101AFI20241202BHJP

   G06F 21/31 20130101ALI20241202BHJP

【ＦＩ】

G06F21/62 318

G06F21/31

【請求項の数】 10

(21)【出願番号】P 2023006837

(22)【出願日】2023-01-19

(65)【公開番号】P2024102743

(43)【公開日】2024-07-31

【審査請求日】2024-03-13

(73)【特許権者】

【識別番号】524132520

【氏名又は名称】日立ヴァンタラ株式会社

(74)【代理人】

【識別番号】110002365

【氏名又は名称】弁理士法人サンネクスト国際特許事務所

(72)【発明者】

【氏名】在塚 俊之

(72)【発明者】

【氏名】中村 隆喜

(72)【発明者】

【氏名】平井 達哉

(72)【発明者】

【氏名】篠原 智寛

【審査官】岸野 徹

(56)【参考文献】

【文献】特開２０１３－１８２２９５（ＪＰ，Ａ）

【文献】特開２００９－２３７６７１（ＪＰ，Ａ）

【文献】特表２０１３－５０９６５７（ＪＰ，Ａ）

【文献】特開２０１５－１２５５１０（ＪＰ，Ａ）

【文献】米国特許第１０００９３３７（ＵＳ，Ｂ１）

【文献】米国特許出願公開第２０１４／０００７１７８（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０１７／０３２９９５７（ＵＳ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ ２１／３１－２１／６４

(57)【特許請求の範囲】

【請求項1】

ユーザに関する情報であるユーザ情報と、テナントに関する情報であるテナント情報と、複数のリソースのうちのアクセス先のリソースを指定したリソースアクセス要求とをユーザ端末から受け付けるインタフェース装置と、
テナント毎の名前空間を含む複数の名前空間の各々について、当該名前空間に対応のテナントに関連付けられたユーザに関する情報を含んだユーザ管理情報を記憶した記憶装置と、
前記インタフェース装置および前記記憶装置に接続されたプロセッサと
を備え、
各名前空間について、前記ユーザ管理情報は、１または２以上のテナントの各々についてのリソースアクセス範囲のラベルであるテナントスコープを表す情報を含み、
前記記憶装置は、全てのテナントスコープの各々について当該テナントスコープに対応のリソースアクセス範囲を表す情報である全体スコープ管理情報を記憶し、
前記プロセッサは、
受け付けられた前記テナント情報が表すテナントに対応した名前空間を選択し、
受け付けられた前記ユーザ情報が選択された名前空間のユーザ管理情報が有する情報に適合するかの判定である認証判定を行い、
前記認証判定の結果が真の場合、受け付けられた前記リソースアクセス要求に従うアクセス先のリソースが、前記選択された名前空間のユーザ管理情報が表すいずれかのテナントスコープに対応し前記全体スコープ管理情報から特定されるリソースアクセス範囲に属するか否かの判定である認可判定を行い、
前記認可判定の結果が真の場合、受け付けられた前記リソースアクセス要求を実行させる、
マルチテナント管理システム。

【請求項2】

前記複数の名前空間は、不特定テナントに対応の名前空間としてのシステム管理用の名前空間を含み、
前記システム管理用の名前空間に関連付けられた１または２以上のテナントスコープは、全体のリソースの範囲が対応付けられたシステムスコープを含む、
請求項１に記載のマルチテナント管理システム。

【請求項3】

前記システム管理用の名前空間のユーザ管理情報が、前記システム管理用の名前空間とは別の名前空間に対応のテナントのためのテナントスコープを表し、
受け付けられた前記テナント情報から前記システム管理用の名前空間が選択され、前記システム管理用の名前空間のユーザ管理情報を用いて前記認証判定の結果が真となった場合、前記プロセッサは、前記認可判定において、前記リソースアクセス要求を基に、前記システム管理用の名前空間に関連付けられている、前記別の名前空間に対応のテナントのためのテナントスコープを特定し、当該テナントスコープに対応のリソースアクセス範囲を前記全体スコープ管理情報から特定する、
請求項２に記載のマルチテナント管理システム。

【請求項4】

前記各名前空間について、前記ユーザ管理情報は、ユーザのグループ毎に、当該グループに関連付けられた１または２以上のテナントスコープを表す情報を含む、
請求項１に記載のマルチテナント管理システム。

【請求項5】

前記複数のリソースは、ストレージシステムのリソースである、
請求項１に記載のマルチテナント管理システム。

【請求項6】

第１のテナントの第１のユーザに関する情報と第２のテナントの第２のユーザに関する情報とが単一の名前空間のユーザ管理情報に含まれている場合、前記プロセッサは、
前記第２のテナントに対応の名前空間を生成し、
生成した当該名前空間のユーザ管理情報に、前記第２のテナントの前記第２のユーザに関する情報を移す、
請求項１に記載のマルチテナント管理システム。

【請求項7】

前記複数の名前空間のうちの或る名前空間のユーザ管理情報が、当該或る名前空間と異なる１以上の名前空間のユーザ管理情報に登録されている１以上のユーザに関する情報を含む、
請求項１に記載のマルチテナント管理システム。

【請求項8】

前記或る名前空間のユーザ管理情報は、前記１以上のユーザの各々について、当該ユーザに関する情報が登録されている名前空間を表す情報を含み、
前記プロセッサは、
前記或る名前空間のユーザ管理情報から、前記ユーザ情報が表すユーザに対応の名前空間を特定し、
特定された当該名前空間のユーザ管理情報と前記ユーザ情報とを基に前記認証判定を行う、
請求項７に記載のマルチテナント管理システム。

【請求項9】

前記記憶装置が、ユーザ毎に当該ユーザが登録されている名前空間を表す情報であるユーザ所属情報を記憶し、
前記プロセッサは、
前記ユーザ所属情報から、前記ユーザ情報が表すユーザに対応の名前空間を特定し、
特定された当該名前空間のユーザ管理情報と前記ユーザ情報とを基に前記認証判定を行う、
請求項１に記載のマルチテナント管理システム。

【請求項10】

コンピュータが、ユーザに関する情報であるユーザ情報と、テナントに関する情報であるテナント情報と、複数のリソースのうちのアクセス先のリソースを指定したリソースアクセス要求とをユーザ端末から受け付け、
コンピュータが、受け付けられた前記テナント情報が表すテナントに対応した名前空間を選択し、
コンピュータが、受け付けられた前記ユーザ情報が選択された名前空間のユーザ管理情報が有する情報に適合するかの判定である認証判定を行い、
テナント毎の名前空間を含む複数の名前空間の各々について、ユーザ管理情報が、当該名前空間に対応のテナントに関連付けられたユーザに関する情報と、１または２以上のテナントの各々についてのリソースアクセス範囲のラベルであるテナントスコープを表す情報とを含み、
前記認証判定の結果が真の場合、コンピュータが、受け付けられた前記リソースアクセス要求に従うアクセス先のリソースが、前記選択された名前空間のユーザ管理情報が表すいずれかのテナントスコープに対応し全体スコープ管理情報から特定されるリソースアクセス範囲に属するか否かの判定である認可判定を行い、
前記全体スコープ管理情報は、全てのテナントスコープの各々について当該テナントスコープに対応のリソースアクセス範囲を表す情報であり、
前記認可判定の結果が真の場合、コンピュータが、受け付けられた前記リソースアクセス要求を実行させる、
マルチテナント管理方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、概して、マルチテナントで利用されるシステムにおけるリソースへのユーザアクセスに関する。

【背景技術】

【0002】

ストレージシステム等のシステムにおけるリソースへのアクセスを、許可されたユーザからのアクセス且つ許可された操作のためのアクセスに制限することにより、不正アクセスを防止し、セキュリティ性を高めることが知られている。アクセス制御方式の１つであるＲＢＡＣ（Ｒｏｌｅ Ｂａｓｅｄ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）では、リソースにアクセスするユーザに、業務等に応じてアクセス権を付与したロールが割り当てられ、ユーザに割り当てられたロールに基づいてリソースへのアクセス可否が判定される。これにより、想定外のリソース操作や誤操作等の意図しないリソースアクセスを防止し、ユーザの管理負荷を軽減することができる。

【0003】

異なる複数の組織や異なる複数の部署を複数の「テナント」としたマルチテナント管理システムが知られている。「テナント」は、当該テナントとしての組織や部署に属するユーザのグループでよい。マルチテナント管理システムでは、テナント毎に、リソースが対応付けられる。マルチテナント管理システムでは、テナント間の独立性を担保するために、テナント毎にユーザを独立に管理したり、特定のリソースへのアクセス権を、当該リソースが対応付けられたテナントに限定したり、といったテナント単位でのアクセス制御が必要になる。一方で、複数のテナントにリソースを提供するシステム管理者には、テナントに対応付けられたリソースにアクセスして状態を監視する等の特定の操作を実行する権限が必要になることがある。システム管理者に対して予め任意のテナントに対応付けられたリソースへのアクセス権限を付与しておくことも考えられるが、テナント管理の独立性の観点や、システム管理者の管理負荷低減の観点から、システム管理者に対しても、必要以上に広い権限を付与することは望ましくない。

【0004】

例えば、マルチテナント管理に関する技術を開示する先行技術文献として、特許文献１および特許文献２がある。

【先行技術文献】

【特許文献】

【0005】

【文献】ＷＯ２０１５／２００３７９

【文献】特開２０１３－８２２９号公報

【発明の概要】

【発明が解決しようとする課題】

【0006】

各テナントに名前空間を割り当て、テナント毎に独立にユーザを管理し、テナントに所属するユーザにロールを割り当てることが考えられる。ユーザは、名前空間に対し認証が成功した場合に、当該名前空間に割り当てられたテナントに対応付けられたリソースにアクセスすることができる。しかし、システム管理者が、複数のテナントそれぞれに対応付けられたリソースへのアクセスが必要な場合は、システム管理者が、テナント別に、当該テナントに対応の名前空間について認証がされる必要がある。このように、テナントの数だけ認証が必要となり、管理が煩雑である。

【0007】

この問題の解決の方法として、複数のテナントを単一の名前空間に割り当て、システム管理者を同じ名前空間に登録することが考えられる。しかし、複数のテナントを単一の名前空間で管理するため、テナント間の独立性を担保することができない。例えば、テナントＡのユーザＡが先に名前空間に登録されていて、テナントＢにユーザＡと氏名が同じユーザＢが存在する場合、テナントが異なっているがユーザＡと氏名が同じためユーザＢを名前空間に登録することができない。

【課題を解決するための手段】

【0008】

本開示の代表的な例は、マルチテナント管理システム（以下、この段落において「システム」）が、ユーザに関する情報であるユーザ情報と、テナントに関する情報であるテナント情報と、複数のリソースのうちのアクセス先のリソースを指定したリソースアクセス要求とをユーザ端末から受け付ける。システムが、受け付けられたテナント情報が表すテナントに対応した名前空間を選択する。システムが、受け付けられたユーザ情報が選択された名前空間のユーザ管理情報が有する情報に適合するかの判定である認証判定を行う。テナント毎の名前空間を含む複数の名前空間の各々について、ユーザ管理情報が、当該名前空間に対応のテナントに関連付けられたユーザに関する情報と、１または２以上のテナントの各々についてのリソースアクセス範囲のラベルであるテナントスコープを表す情報とを含む。認証判定の結果が真の場合、システムが、受け付けられたリソースアクセス要求に従うアクセス先のリソースが、選択された名前空間のユーザ管理情報が表すいずれかのテナントスコープに対応し全体スコープ管理情報から特定されるリソースアクセス範囲に属するか否かの判定である認可判定を行う。全体スコープ管理情報は、全てのテナントスコープの各々について当該テナントスコープに対応のリソースアクセス範囲を表す情報である。認可判定の結果が真の場合、システムが、受け付けられたリソースアクセス要求を実行させる。

【発明の効果】

【0009】

本発明の代表的な一例によれば、テナント間の独立性を担保しつつ、ユーザが名前空間毎の認証無しに複数のテナントのリソースにアクセスすることができる。前述した以外の課題、構成および効果は、以下の実施例の説明により明らかにされる。

【図面の簡単な説明】

【0010】

【図1】実施形態に係る計算機システムの構成例を示す。

【図2】比較例に係る計算機システムの論理構成例を示す。

【図3】実施形態に係るリソースアクセスコマンドの例を示す。

【図4】実施形態に係るユーザ管理テーブルの例を示す。

【図5】実施形態に係るポリシ管理テーブルの例を示す。

【図6】比較例に係るスコープ管理テーブルの例を示す。

【図7】比較例に係るマルチテナント管理の例を示す。

【図8】比較例に係るマルチテナント管理の別の例を示す。

【図9】実施形態に係る計算機システムの論理構成例を示す。

【図10】実施形態に係る全体スコープ管理テーブルの例を示す。

【図11】実施形態に係るユーザ管理テーブルの例を示す。

【図12】実施形態に係るスコープ管理部の論理構成例を示す。

【図13】実施形態に係るマルチテナント管理の例を示す。

【図14】実施形態に係るマルチテナント管理の一変形例を示す。

【図15】実施形態に係るユーザ作成および権限設定のフローの例を示す。

【図16】実施形態に係るシステム管理者に関する認証および認可フローを示す。

【図17】実施形態に係るテナント１管理者に関する認証および認可フローを示す。

【図18】実施形態に係るテナント２管理者に関する認証および認可フローを示す。

【図19】実施形態に係るマルチテナント管理移行の例を示す。

【図20】実施形態に係るマルチテナント管理の別の例を示す。

【図21】実施形態に係るマルチテナント管理のまた別の例を示す。

【図22】実施形態に係るマルチテナント管理のまた別の例を示す。

【図23】実施形態に係るマルチテナント管理のまた別の例を示す。

【図24】実施形態に係るユーザ所属テーブルの例を示す。

【発明を実施するための形態】

【0011】

以下の説明では、「インタフェース装置」は、１以上のインタフェースデバイスでよい。当該１以上のインタフェースデバイスは、下記のうちの少なくとも１つでよい。
・１以上のＩ／Ｏ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）インタフェースデバイス。Ｉ／Ｏ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）インタフェースデバイスは、Ｉ／Ｏデバイスと遠隔の表示用計算機とのうちの少なくとも１つに対するインタフェースデバイスである。表示用計算機に対するＩ／Ｏインタフェースデバイスは、通信インタフェースデバイスでよい。少なくとも１つのＩ／Ｏデバイスは、ユーザインタフェースデバイス、例えば、キーボードおよびポインティングデバイスのような入力デバイスと、表示デバイスのような出力デバイスとのうちのいずれでもよい。
・１以上の通信インタフェースデバイス。１以上の通信インタフェースデバイスは、１以上の同種の通信インタフェースデバイス（例えば１以上のＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ））であってもよいし２つ以上の異種の通信インタフェースデバイス（例えばＮＩＣとＨＢＡ（Ｈｏｓｔ Ｂｕｓ Ａｄａｐｔｅｒ））であってもよい。

【0012】

また、以下の説明では、「メモリ」は、１以上の記憶デバイスの一例である１以上のメモリデバイスであり、典型的には主記憶デバイスでよい。メモリにおける少なくとも１つのメモリデバイスは、揮発性メモリデバイスであってもよいし不揮発性メモリデバイスであってもよい。

【0013】

また、以下の説明では、「永続記憶装置」は、１以上の記憶デバイスの一例である１以上の永続記憶デバイスでよい。永続記憶デバイスは、典型的には、不揮発性の記憶デバイス（例えば補助記憶デバイス）でよく、具体的には、例えば、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、ＮＶＭＥ（Ｎｏｎ－Ｖｏｌａｔｉｌｅ Ｍｅｍｏｒｙ Ｅｘｐｒｅｓｓ）ドライブ、または、ＳＣＭ（Ｓｔｏｒａｇｅ Ｃｌａｓｓ Ｍｅｍｏｒｙ）でよい。

【0014】

また、以下の説明では、「記憶装置」は、メモリと永続記憶装置の少なくともメモリでよい。

【0015】

また、以下の説明では、「プロセッサ」は、１以上のプロセッサデバイスでよい。少なくとも１つのプロセッサデバイスは、典型的には、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）のようなマイクロプロセッサデバイスでよいが、ＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）のような他種のプロセッサデバイスでもよい。少なくとも１つのプロセッサデバイスは、シングルコアでもよいしマルチコアでもよい。少なくとも１つのプロセッサデバイスは、プロセッサコアでもよい。少なくとも１つのプロセッサデバイスは、処理の一部または全部を行うハードウェア記述言語によりゲートアレイの集合体である回路（例えばＦＰＧＡ（Ｆｉｅｌｄ－Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）、ＣＰＬＤ（Ｃｏｍｐｌｅｘ Ｐｒｏｇｒａｍｍａｂｌｅ Ｌｏｇｉｃ Ｄｅｖｉｃｅ）またはＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ））といった広義のプロセッサデバイスでもよい。

【0016】

また、以下の説明では、「ｘｘｘテーブル」といったテーブル現にて、入力に対して出力が得られる情報を説明することがあるが、当該情報は、どのような構造のデータでもよいし（例えば、構造化データでもよいし非構造化データでもよいし）、入力に対する出力を発生するニューラルネットワーク、遺伝的アルゴリズムやランダムフォレストに代テーブルされるような学習モデルでもよい。したがって、「ｘｘｘテーブル」を「ｘｘｘ情報」と言うことができる。また、以下の説明において、各テーブルの構成は一例であり、１つのテーブルは、２つ以上のテーブルに分割されてもよいし、２つ以上のテーブルの全部または一部が１つの表であってもよい。

【0017】

また、以下の説明では、「ｙｙｙ部」の表現にて機能を説明することがあるが、機能は、１以上のコンピュータプログラムがプロセッサによって実行されることで実現されてもよいし、１以上のハードウェア回路（例えばＦＰＧＡまたはＡＳＩＣ）によって実現されてもよいし、それらの組合せによって実現されてもよい。プログラムがプロセッサによって実行されることで機能が実現される場合、定められた処理が、適宜に記憶装置および／またはインタフェース装置等を用いながら行われるため、機能はプロセッサの少なくとも一部とされてもよい。機能を主語として説明された処理は、プロセッサあるいはそのプロセッサを有する装置が行う処理としてもよい。プログラムは、プログラムソースからインストールされてもよい。プログラムソースは、例えば、プログラム配布計算機または計算機が読み取り可能な記録媒体（例えば非一時的な記録媒体）であってもよい。各機能の説明は一例であり、複数の機能が１つの機能にまとめられたり、１つの機能が複数の機能に分割されたりしてもよい。

【0018】

また、以下の説明では、要素の識別情報の一例としてＩＤが採用されるが、識別情報は、名前等、要素を識別可能な情報であればよい。

【0019】

また、以下の説明では、同種の要素を区別しないで説明する場合には、参照符号のうちの共通符号を使用し、同種の要素を区別して説明する場合には、参照符号を使用することがある。

【0020】

以下、図面に基づいて、本発明の実施の形態を説明する。なお、以下の記載および図面は、本発明を説明するための例示であって、説明の明確化のため、適宜、省略および簡略化がなされており、本発明は、他の種々の形態でも実施する事が可能であり、特に限定しない限り、各構成要素は単数でも複数でも構わない。

【0021】

また、以下に説明する実施例は特許請求の範囲に係る発明を限定するものではなく、実施例の中で説明されている要素の組み合わせの全てが、発明の解決手段に必須であるとは限らない。

【0022】

以下において、本発明の一実施形態に係るマルチテナント管理を説明する。

【0023】

本実施形態に係るストレージシステム（マルチテナント管理システムの一例）は、個別テナントやテナント以外のシステム管理用にそれぞれ別々の名前空間を割り当て、名前空間毎にテナントユーザやシステム管理者ユーザの認証、および特定リソース種別に対するアクセス権限と特定操作の実行権限を設定し、名前空間毎に当該権限の認可判定処理を行う。さらに、ストレージシステムは、テナントやシステムに対応付けたリソース範囲を名前空間を限定せずに管理することにより、ある名前空間に登録したユーザが、別の名前空間に対応付けたリソース範囲を指定してアクセスおよび操作を実行できるようにする。本開示は、ストレージシステムと異なる対象システムへのリソースアクセス制御に適用されてもよい。アクセス実行権限は、例えばユーザのロールに応じて与えられてもよく、他の条件項目を基準に与えれてもよい。

【0024】

図１は、本実施形態に係る計算機システムの構成例を示す。

【0025】

計算機システムは、ユーザ端末１００、ホストサーバ１１０、管理サーバ１２０およびストレージシステム１３０、を含む。これらは、ネットワーク１６０を介して通信可能である。ストレージシステム１３０は、分散型構成を取ることも可能である。例えば、複数のストレージノード１４０で構成されたストレージシステム１３０が採用されてもよい。なお、ストレージノードの数は限定されるものではなく、必要に応じて追加または削減する。分散型ストレージシステムは、既存の技術を用いて構成することが可能である。なお、これら構成要素それぞれの数は任意である。また、ユーザ端末１００が、ホストサーバ１１０、および／または管理サーバ１２０の機能を含んでもよい。

【0026】

ネットワーク１６０は、例えば、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）やＳＡＮ（Ｓｔｏｒａｇｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）であってもよい。ホストサーバ１１０と管理サーバ１２０は、異なるネットワークを介してストレージシステム１３０にアクセスしてもよく、ユーザ端末１００は、ネットワーク１６０と異なるネットワークを介して、ホストサーバ１１０または管理サーバ１２０にアクセスしてもよい。

【0027】

ユーザ端末１００は、ユーザから計算機システムへのアクセスを可能とする装置である。ユーザ端末１００は、例えば一般的な計算機構成を有することができ、例えば、インタフェース装置、記憶装置およびそれらに接続されたプロセッサを含む。ユーザ端末１００は、特定処理専用のハードウェアを含んでもよい。ユーザ端末１００は、Ｉ／Ｏデバイス（例えば、キーボード、ポインティングおよび表示デバイス）を有してよい。

【0028】

ホストサーバ１１０は、ユーザアプリケーション等が動作するホストマシンである。ホストサーバ１１０は、例えば一般的な計算機構成を有することができ、インタフェース装置、記憶装置およびそれらに接続されたプロセッサを含む。ホストサーバ１１０は、特定処理専用のハードウェアを含んでもよい。ホストサーバ１１０は、様々なソフトウェアプログラムを実行することができ、例えば、データベースやＷｅｂサービスを実行し、それらにより作られたデータを、ネットワーク１６０を介してストレージシステム１３０にライトおよびリードする。ホストサーバ１１０は、後述するリソース利用アプリケーションを実行してもよい。

【0029】

管理サーバ１２０は、ストレージシステム１３０を管理する。管理サーバ１２０は、例えば一般的な計算機構成を有することができ、インタフェース装置、記憶装置およびそれらに接続されたプロセッサを含む。管理サーバ１２０は、特定処理専用のハードウェアを含んでもよい。管理サーバ１２０は、後述する認証および認可システムを管理するソフトウェアプログラムを実行してもよい。

【0030】

計算機システムは、後述する認証および認可システムを含む。

【0031】

ストレージシステム１３０は、コントローラ１３１およびドライブボックス１３７を含む。コントローラ１３１は、ホストインタフェース１３２、管理インタフェース１３３、ドライブインタフェース１３４、メモリ１３６、およびそれらに接続されたプロセッサ１３５、を含む。これら構成要素の数は任意である。

【0032】

ホストインタフェース１３２は、ホストサーバ１１０との通信のためのインタフェース装置である。管理インタフェース１３３は、管理サーバ１２０との通信のためのインタフェース装置である。ドライブインタフェース１３４は、ドライブボックス１３７との通信のためのインタフェース装置である。

【0033】

ドライブボックス１３７は、ホストサーバ１１０のアプリケーションプログラムが使用する各種データを格納する１以上の不揮発性または揮発性の記憶ドライブを収容する。ドライブボックス１３７は、コントローラ１３１のドライブインタフェース１３４に接続される。図１の構成例において、ドライブボックス１３７は、複数のハードディスクドライブ（ＨＤＤ）１３８および複数のソリッドステートドライブ（ＳＳＤ）１３９を含む。複数の記憶ドライブ１３８、１３９は、ＲＡＩＤ（Ｒｅｄｕｎｄａｎｔ Ａｒｒａｙｓ ｏｆ Ｉｎｄｅｐｅｎｄｅｎｔ Ｄｉｓｋｓ）等のデータ冗長化のためのグループを構成してもよい。

【0034】

コントローラ１３１は、ストレージシステム１３０の制御を行う。コントローラ１３１は、ホストサーバ２１０のデータを格納するためのボリュームを、ホストサーバ２１０に提供する。コントローラ１３１は、記憶ドライブ１３８および１３９の物理的な記憶領域をボリュームに割り当てて、データを記憶ドライブ１３８および１３９に格納する。コントローラ１３１は、ホストサーバ１１０にストレージとしての機能を提供する。

【0035】

プロセッサ１３５は、ホストサーバ１１０からのリードコマンドやライトコマンドに応じて、対応するドライブボックス１３７に格納されたデータを転送指示する。コントローラ１３１のメモリ１３６は、例えば、ＳＤＲＡＭ（Ｓｙｎｃｈｒｏｎｏｕｓ Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等の半導体メモリで構成される。メモリは、揮発メモリと不揮発メモリと組み合わせて構成してもよい。

【0036】

プロセッサ１３５は、ストレージシステム１３０の制御、ホストサーバ１１０、管理サーバ１２０およびドライブボックス１３７との通信のための処理を実行する。メモリ１３６は、プロセッサ１３５の主記憶として、制御や通信のためのプログラムおよび各種データを格納する。メモリ１３６は、後述する認証および認可システムを実現するソフトウェアプログラムを格納する。また、メモリ１３６は、コントローラ１３１のディスクキャッシュ（キャッシュメモリ）としても使用される。プロセッサ１３５は、メモリ１３６に格納されている、命令コードを含むプログラムを実行することで所定の機能を実現する。

【0037】

複数のコントローラ１３１が冗長化のために実装されていてもよい。複数のコントローラ１３１は、ストレージシステム１３０内のネットワークを介して通信する。コントローラ１３１は、ストレージシステム１３０内のネットワークを介して、ライトデータの２重化やメタデータの共有等を行う。一方のコントローラ１３１が保守や障害等で閉塞しても、もう一方のコントローラ１３１により、ストレージ処理を継続可能となる。なお、ストレージシステム１３０は、一般的なサーバ計算機を用いて構成してもよく、また、特定処理専用のハードウェアを含んでもよい。また、前述したように、例えば構成要素１３０、１４０、１５０をストレージノードとし、これらを連携して１つのストレージシステムを構成してもよい。なお、ストレージノードの数は限定されるものではなく、必要に応じて追加または削減する。分散型ストレージシステムは、既存の技術を用いて構成することが可能である。

【0038】

なお、計算機システムは、ここで示したもの以外も含んでよい。例えば、ネットワークには、スイッチやルーター等のネットワーク機器が間に接続されてもよい。また、パブリッククラウド上のストレージサービスに外部ネットワークを経由して接続する構成でもよい。

【0039】

図２は、比較例に係る計算機システムの論理構成例を示す。また、図では、名前空間を「ＮＳ」と略記する。

【0040】

計算機システムは、リソース利用アプリケーション２２０、認証基盤２３０、認可基盤２４０、およびリソース管理基盤２５０を含む。これらは、計算機システムに実装されるソフトウェア構成要素または例えばプロセッサにより実現される機能構成要素である。

【0041】

リソース利用アプリケーション２２０は、例えば、ホストサーバ１１０に含まれる。認証基盤２３０、認可基盤２４０、リソース管理基盤２５０、および名前空間管理基盤２６０は、例えば、ストレージシステム１３０に含まれる。各機能がいずれのハードウェア装置に実装されるかは、計算機システムの設計に依存する。例えば、ＩＤａａＳ（Ｉｄｅｎｔｉｔｙ ａｓ ａ Ｓｅｒｖｉｃｅ）等の共通認証および認可サーバとして提供されているサービスが、認証基盤２３０、認可基盤２４０、および／または名前空間管理基盤２６０として用いられてもよい。

【0042】

図２に示すように、ユーザ２００は、ユーザ端末１００を使用して、計算機システムのソフトウェアリソースまたはハードウェアリソースにアクセスする。ユーザ端末１００は、ユーザからの入力に応じて、リソース利用アプリケーション２２０にアクセスする。ユーザは、ユーザ端末１００を介してリソース利用アプリケーション２２０に対し、対象リソース、リソースに対する操作、および操作パラメータを指定したコマンドを発行することにより、リソースアクセスを要求する。

【0043】

ユーザ端末１００は、ユーザインタフェース（Ｉ／Ｆ）２１１、ユーザ取得部２１２、コマンド取得部２１３、およびテナント取得部２１４を含む。ユーザインタフェース２１１は、ユーザ２００がユーザ端末１００を用いてリソース操作の実行を要求するためのユーザインタフェースであり、例えば、Ｗｅｂブラウザを利用することができる。

【0044】

ユーザ取得部２１２は、ユーザ２００が入力したユーザ名、アカウント名、ログインＩＤ、パスワード等のユーザ情報を取得する。コマンド取得部２１３は、ユーザがユーザインタフェース２１１を介して入力したリソースアクセスコマンドを取得し、リソースアクセスコマンドを、認可基盤２４０のポリシ判定部２４２、およびリソース利用アプリケーション２２０のリソースアクセス実行部２２３に送信する。テナント取得部２１４は、ユーザ２００が入力した、自身が所属するテナントや、ユーザがアクセスを要求するリソースを対応付けたテナント等のテナントのテナント情報を取得し、取得したテナント情報を、認証基盤２３０の名前空間選択部２３１、および認可基盤の名前空間選択部２４１に送信する。

【0045】

リソース利用アプリケーション２２０は、ストレージリソース、コンピュートリソース（ベアマシン、ＶＭ（Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ）、コンテナを含む）、ネットワークリソース等のリソースにアクセスして処理を実行する。リソース利用アプリケーション２２０は、認証要否判定部２２１、アクセス権判定部２２２、リソースアクセス実行部２２３およびリソース利用実行部２２４を含む。

【0046】

認証要否判定部２２１は、ユーザ２００がリソースアクセス要求を行った際に（リソースアクセスコマンドを送信した際に）、該ユーザを識別する情報、例えばアカウント名をユーザ端末１００のユーザ取得部２１２から取得し、認証が必要かまたはすでに認証済ユーザかを判定する。認証が必要かつ未認証だった場合、認証要否判定部２２１は、認証基盤２３０に認証を要求する。ユーザ２００が認証済み、あるいは認証基盤２３０によって認証が完了した通知を受信した場合に、認証要否判定部２２１は、認可基盤２４０に、リソースアクセス要求（リソースアクセスコマンド）の認可判定を要求する。

【0047】

リソースアクセス実行部２２３は、ユーザ端末１００のコマンド取得部２１３からリソースアクセスコマンドを取得する。なお、リソースアクセス実行部２２３によるリソースアクセスコマンド取得は、認可基盤２４０のポリシ判定部２４２による判定の結果、当該リソースへのアクセスおよび操作の実行が認可されてからでもよい。

【0048】

アクセス権判定部２２２は、ユーザ２００が要求したリソースアクセスが認可されているかを判定する。認可済の場合、アクセス権判定部２２２は、リソースアクセスコマンドの実行を、リソースアクセス実行部２２３に許可する。

【0049】

リソースアクセス実行部２２３は、リソースアクセスコマンドをリソース管理基盤２５０に発行する。リソース利用実行部２２４は、リソースアクセスに基づいて所定の処理を実行する。

【0050】

認証基盤２３０は、リソース利用アプリケーション２２０の認証要否判定部２２１から認証要求を受けた場合に、ユーザ認証を実行する。認証基盤２３０は、名前空間選択部２３１およびユーザ認証部２３２を含む。名前空間選択部２３１は、ユーザ端末１００のテナント取得部２１４から取得したテナント情報に基づいて、テナントに割り当てられた名前空間を選択する。ユーザ認証部２３２は、ユーザ２００からのサインインを処理する。具体的には、ユーザ認証部２３２は、例えば、ユーザ２００からユーザ端末１００を介して入力されたパスワードおよび／または指紋や顔の生体情報等を用いて、ユーザ２００が計算機システムに予め登録されたユーザ本人であることを認証する。

【0051】

名前空間管理基盤２６０は、１以上の名前空間２６１、および、名前空間セレクタ２６２および２６４を含む。名前空間２６１は、ユーザ管理テーブル（ＴＢＬ）２６３、ポリシ管理テーブル２６５、およびスコープ管理テーブル２６６を含む。

【0052】

名前空間管理基盤２６０は、認証基盤２３０のユーザ認証部２３２がユーザ管理テーブル２６３へのアクセスを要求した際に、名前空間選択部２３１が選択した名前空間に基づいて、名前空間セレクタ２６２により選択したいずれかの名前空間２６１のユーザ管理テーブル２６３をユーザ認証部２３２に連結する。

【0053】

ユーザ管理テーブル２６３は、認証対象として登録されたユーザの情報、例えば、ユーザ名、役職、Ｅ－ｍａｉｌアドレス、パスワード、生体情報を照合するための情報、所属グループ、アクセス日時、割り当てたロール、アクセス対象リソース種別のアクセス範囲を示すスコープ等を格納する。いずれかの名前空間２６１のスコープ管理テーブル２６６に含まれるスコープがユーザに割り当てられる。ユーザ認証部２３２は、ユーザ２００がサインイン時に入力したユーザ情報と、名前空間管理基盤２６０のユーザ管理テーブル２６３に格納されている情報とを照合することにより、ユーザ認証を行う。

【0054】

ユーザ認証部２３２によって認証が成功した場合は、ユーザ認証部２３２は、当該ユーザに割り当てられたロールおよびスコープを含むユーザ情報を、認可基盤２４０のポリシ判定部２４２に送信する。

【0055】

なお、最初にユーザ認証を実行した際に取得されたユーザ情報は、対象ユーザの認証が有効な間（有効セッション中）、リソース利用アプリケーション２２０、認証基盤２３０および認可基盤２４０のいずれか、またはその全てに保持されてよい。同一ユーザによるリソースアクセス要求が発行された場合には、保持されたユーザ情報を用いてポリシ判定が行われてもよい。保持されたユーザ情報は、セッション有効期間終了と共に破棄されてもよい。

【0056】

認可基盤２４０は、認証基盤２３０において認証されたユーザ２００に対し、該ユーザ２００がアクセス要求したリソースへのアクセス権およびリソースに対する操作の実行権を有するかを判定する。ユーザ２００が、アクセス権および操作の実行権を有する場合、認可基盤２４０は実行を認可する。ユーザ２００がアクセス権または操作の実行権を有しない場合は、認可基盤２４０は実行を認可しない。

【0057】

認可基盤２４０は、名前空間選択部２４１、ポリシ判定部２４２、およびアクセス認可部２４３を含む。

【0058】

名前空間選択部２４１は、ユーザ端末１００のテナント取得部２１４から取得したテナント情報に基づいて、テナントに割り当てられた名前空間を選択する。名前空間管理基盤２６０は、認可基盤２４０のポリシ判定部２４２がポリシ管理テーブル２６５およびスコープ管理テーブル２６６へのアクセスを要求した際に、名前空間選択部２４１が選択した名前空間に基づいて、名前空間セレクタ２６４により選択したいずれかの名前空間２６１のポリシ管理テーブル２６５およびスコープ管理テーブル２６６をポリシ判定部２４２に連結する。

【0059】

ポリシ判定部２４２は、ユーザ認証部２３２から、認証済ユーザについて、ロールおよびスコープを含むユーザ情報を取得する。また、ポリシ判定部２４２は、要求されたリソースアクセスコマンドが対象とするリソースおよび当該リソースに対する操作の情報を、ユーザ端末１００のコマンド取得部２１３から取得する。

【0060】

ポリシ判定部２４２は、取得されたそれらの情報を、名前空間管理基盤２６０のいずれかの名前空間２６１に対応付けられた、ポリシ管理テーブル２６５に格納されたアクセスポリシの情報（ポリシ情報）、およびスコープ管理テーブル２６６に格納されたアクセス範囲の情報（スコープ情報）と照合し、該ユーザ２００が、要求したリソース種別のリソース範囲へのアクセス権および操作実行権を有するかを判定する。

【0061】

ポリシ管理テーブル２６５は、ポリシ判定部２４２で使用するポリシ情報を格納する。ポリシ情報には、例えば、ロール、ロールに付与された権限、権限がアクセスを許可するリソース、および該リソースに対し許可する操作を対応付けた判定ルールが含まれる。ポリシ判定部２４２は、ポリシ管理テーブル２６５を参照し、ユーザ認証部２３２で認証されたユーザ２００に割り当てられているロールに、要求されたリソースアクセスおよびリソースに対する操作を実行する権限が付与されているかを判定する。また、ポリシ判定部２４２は、スコープ管理テーブル２６６を参照し、ユーザ認証部２３２で認証されたユーザ２００に割り当てられているスコープに、要求されたリソース範囲へのアクセス権限が付与されているかを判定する。

【0062】

アクセス認可部２４３は、ポリシ判定部２４２によって判定した結果、ユーザ２００が、要求したリソース種別のリソース範囲へのアクセス権および要求操作の実行権を有する場合に、当該リソースへのアクセスおよび操作を認可する。アクセス認可部２４３は、認可コードをリソース利用アプリケーション２２０に送信する。

【0063】

リソース利用アプリケーション２２０、認証基盤２３０および認可基盤２４０のいずれか、またはその全てに保持されているロールおよびスコープ割り当て情報は、セッション有効期間が終了した際に、セッション情報と共に破棄されてもよい。

【0064】

他の例において、保持されているユーザ情報は、必要なタイミングで、ユーザにロールおよびスコープを割り当てる通常の手段等を用いて更新された際に、認証基盤２３０のユーザ管理テーブル２６３のロールおよびスコープ割り当て情報と同期させ、新たなセッションを開始した時に使用されてもよい。これにより、セッション有効期間終了後に、同一ユーザによって新たなリソースアクセスが要求された際には、既存のロールおよびスコープ割り当て情報に基づいてポリシ判定を実行することができる。

【0065】

リソース管理基盤２５０は、ストレージリソース（ボリューム、プール、ファイルディレクトリ等）や、コンピュートリソース（ＶＭ、コンテナ等）、ネットワークリソース（ドメイン、ポート、チャネル、プロトコル等）等のリソースを管理する。リソース管理基盤２５０は、１または複数のリソース２５を含む。

【0066】

例えば、リソース２５Ａは、データストレージのボリュームである。リソース２５Ｂは、データストレージのファイルディレクトリである。リソース２５Ｃは、ＶＭである。リソース２５Ｄは、コンテナである。リソース２５Ｅは、ネットワークリソースのドメインである。リソースＦ２５Ｆは、ネットワークリソースのポートである。

【0067】

図２は、比較例に係る認証、認可およびリソースアクセス処理の流れの例を示す。認証および認可プロトコルは、例えば、ＯＡｕｔｈ２、ＯｐｅｎＩＤ Ｃｏｎｎｅｃｔ、ＳＡＭＬ等の規格に基づいて実行され得る。認証および認可に必要な情報を含有するデータ（例えば種々のトークン）が、ユーザ端末１００、リソース利用アプリケーション２２０、認証基盤２３０、および認可基盤２４０の間でやり取りされ、セキュリティを保全しながら認証および認可処理が実行され得る。上述のように、ユーザ２００は、ユーザ端末１００を利用して、リソースアクセスコマンドを送信する。

【0068】

図３は、ユーザ端末１００のコマンド取得部２１３が発行するリソースアクセスコマンドの例を示す。

【0069】

リソースアクセスコマンドは、コマンドの項目３１１および項目毎の指定３１２といった情報を有する。項目３１１は、項目を表す。指定３１２は、項目についての具体的な値を表す。リソースアクセス実行部２２３がリソース管理基盤２５０にこのようなリソースアクセスコマンドを発行する。

【0070】

リソースアクセスコマンドは、対象のリソース、リソースに対する操作、および操作におけるパラメータ等を指定する。例えば、ＲＥＳＴ ＡＰＩのようなアプリケーションプログラミングインタフェースを用いてストレージリソースアクセスを実行することができる。アクセス対象のリソースは、例えば、プールやボリューム等のストレージシステムのデータ格納領域である。上述のように、アクセスおよび操作されるリソースは、ストレージリソースに限定されない。

【0071】

アクセス対象のリソースＵＲＩ（Ｕｎｉｖｅｒｓａｌ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）３０１は、リソース（本例ではボリューム）を同定する。リソースＵＲＩ３０１で指定したリソースに対し、リソースアクセスコマンドは、ボリューム容量を変更する操作３０２を定義する。操作３０２のために指定されるパラメータは、ストレージボリュームＩＤ３０３、ボリュームタイプ３０４、ボリューム容量３０５、を含む。操作３０２例は、他にボリューム作成、ボリューム削除、ボリューム情報取得等を含む。

【0072】

他のリソースアクセスの例は、コンピュートリソースにアクセスし、仮想マシン（ＶＭ）や、Ｄｏｃｋｅｒ Ｃｏｎｔａｉｎｅｒの生成、削除、変更等を行う。他のリソースアクセスの例は、ネットワークリソースにアクセスし、特定ドメインの情報を取得または特定ネットワークポートを作成する。

【0073】

ユーザ２００が、ユーザ端末１００を介してリソースアクセスを要求した際、リソース利用アプリケーション２２０内の認証要否判定部２２１は、ユーザ２００がすでに認証済みかを判定する。まだ認証されていないユーザ２００の場合に、認証基盤２３０のユーザ認証部２３２に、ユーザ認証を要求する。

【0074】

ユーザ認証部２３２は、単独の認証タイプまたは複数の認証タイプの組み合わせを用いて、ユーザ認証を実行し、正当なユーザであるかを判定する。認証方法は、種々の認証システムで用いられている公知の方法を用いることができる。また、外部の認証システムに認証処理を委託することも可能である。

【0075】

図４は、ユーザ管理テーブル２６３の例を示す。

【0076】

図４に例示のユーザ管理テーブル２６３は、テナント１を管理する名前空間に割り当てたユーザ情報を格納する。ユーザ情報には、例えばユーザ名、所属グループ、役職、Ｅ－ｍａｉｌアドレス、パスワード、生体情報を照合するための情報、アクセス日時、割り当てたロールおよびスコープ等を格納する。図４には、ユーザ情報に含まれる情報の例として、ユーザＩＤ４０１、ユーザ名４０２、所属グループ名４０３、ロール名４０４、およびスコープ４０５がある。ユーザＩＤ４０１は、ユーザＩＤを表す。ユーザ名４０２は、ユーザの名前を表す。所属グループ名４０３は、ユーザが所属するユーザグループの名前を表す。ロール名４０４は、ユーザグループに属するユーザのロールの名前を表す。スコープ４０５は、アクセス対象リソースの範囲のラベルを表す。

【0077】

図４が示す例によれば、ＩＤ１のユーザに対し、ユーザ１、グループＳ１、ロール２、ロール４、ロール１０、ロール１２、およびテナント１スコープが設定されている。ロール名４０４およびスコープ４０５は、アクセス制御対象テナントを管理する名前空間にユーザを登録した際等に割り当てる。例えば、ユーザ１はグループ１に所属し、ロール２、ロール４、ロール１０、ロール１２、およびテナント１スコープが割り当てられている。また、ユーザ２はグループＴ１に所属し、ロール３、ロール４、ロール１１、ロール１２、およびテナント１スコープが割り当てられている。ユーザ３およびユーザ４はグループＴ１－２に所属し、ロール４、ロール１２、およびテナント１スコープが割り当てられている。

【0078】

図５は、ポリシ情報を格納するポリシ管理テーブル２６５の例を示す。

【0079】

ロールそれぞれに対し、実行権限を付与する操作と対象リソース種別が対応づけられている。具体的には、図５に例示のポリシ管理テーブル２６５は、ロール毎に、ロールＩＤ５０１、ロール名５０２、およびポリシ５０３といった情報を有する。ロールＩＤ５０１は、ロールのＩＤを表す。ロール名５０２は、ロールの名前を表す。ポリシ５０３は、ロールに対応付けられているリソース種別５０４およびリソースに対する操作５０５といった情報を含む。

【0080】

例として、ロール１には、対象リソース種別として、ボリューム（／Ｏｂｊ／Ｖｏｌｕｍｅ）、ＬＵＮ（／Ｏｂｊ／ＬＵＮ）、プール（／Ｏｂｊ／Ｐｏｏｌ）、ドライブ（／Ｏｂｊ／Ｄｒｉｖｅ）、性能（／Ｏｂｊ／Ｐｅｒｆｏｒｍａｎｃｅ）、コンピュートノード（／Ｏｂｊ／Ｃｏｍｐｕｔｅ＿ｎｏｄｅ）が、それらのリソース種別に対する操作として、情報取得（ＧＥＴ）権限が、付与されている。

【0081】

また、ロール２には、ボリュームリソース種別（／Ｏｂｊ／Ｖｏｌｕｍｅ）に対し、作成（ＰＯＳＴ）操作権限が、ロール３には、ボリュームリソース種別（／Ｏｂｊ／Ｖｏｌｕｍｅ）に対し、更新（ＰＡＴＣＨ）操作権限が、ロール４には、ボリュームリソース種別（／Ｏｂｊ／Ｖｏｌｕｍｅ）に対し、参照（ＧＥＴ）操作権限が付与されている。これに基づいて、例えばロール１を割り当てたユーザには、ボリューム、ＬＵＮ、プール、性能、コンピュートノードリソース種別に対する情報取得権限が付与される。またロール２を割り当てたユーザには、ボリュームリソース種別の作成権限が、ロール３を割り当てたユーザには、ボリュームリソース種別の更新権願がそれぞれ付与される。なお、ポリシ管理テーブルは、名前空間毎に独立に定義してもよいし、システム全体で共通のポリシ管理テーブルを用いてもよい。

【0082】

図６は、比較例に係るスコープ管理テーブル２６６の例を示す。

【0083】

図６に例示のスコープ管理テーブル２６６は、テナント１のスコープ情報を格納する。スコープ情報は、例えばスコープ名、リソース種別、リソース種別に対するアクセス範囲等の情報を含む。図６が示す例によれば、例えば、スコープ管理テーブル２６６は、スコープＩＤ６０１、スコープ名６０２、リソース種別６０３、およびアクセス範囲６０４といった情報を含む。スコープＩＤ６０１は、スコープのＩＤを表す。スコープ名６０２は、スコープの名前を表す。リソース種別６０３は、リソースの種別を表す。アクセス範囲６０４は、リソースの範囲を表す。

【0084】

図６が示す例によれば、テナント１スコープの対象リソース種別として、ボリューム（／Ｏｂｊ／Ｖｏｌｕｍｅ）、コンピュートノード（／Ｏｂｊ／Ｃｏｍｐｕｔｅ＿ｎｏｄｅ）が指定され、ボリュームリソース種別のアクセス範囲としてＶｏｌｕｍｅ＿ＩＤ＝１～９が割り当てられ、コンピュートノードリソース種別のアクセス範囲としてＣｏｍｐｕｔｅ＿ｎｏｄｅ＿ＩＤ＝１～５が割り当てられる。これにより、テナント１スコープを割り当てたユーザは、ボリュームリソース種別のＶｏｌｕｍｅ＿ＩＤ＝１～９、およびコンピュートノードリソース種別のＣｏｍｐｕｔｅ＿ｎｏｄｅ＿ＩＤ＝１～５のアクセス範囲へのアクセスが可能になる。図４が示す例では、ユーザ１にテナント１スコープが割り当てられている。したがって、ユーザ１は、テナント１スコープとして規定したリソース種別のアクセス範囲へのアクセスが可能である。

【0085】

例えば、テナント１を管理する名前空間に登録されたユーザ１が、テナント２のリソースにもアクセスしたい場合は、テナント２を管理する名前空間に、テナント２スコープを割り当てたユーザ登録を行う。この場合は、テナント１に対応付けたリソースにアクセスする場合と、テナント２に対応付けたリソースにアクセスする場合のそれぞれにおいて、ユーザ１は、独立にユーザ認証およびアクセス認可を行う必要がある。

【0086】

図７は、比較例に係るマルチテナント管理の例を示す。

【0087】

図７が示す例では、テナント管理対象外のシステムリソースも、本論理構成により、システム用名前空間を用いて管理される。名前空間２６１の一例であるシステム用名前空間２６１－１には、システム管理者が、ユーザとして登録され、グループＳ０に所属される。グループＳ０には、システム編集ロールとシステムスコープが割り当てられている。「システムリソース」は、システム管理者による管理対象のリソースであって、ストレージシステム１３０における全てのリソース種別のリソース（例えば、プール、ポート、ドライブ、ストレージノード等）である。「システム編集ロール」は、システムリソースに属するリソースに対する作成、削除、設定変更、更新等の編集操作を許可するロール（例えば図５に例示の“ロール５”や“ロール６”等）である。「システムスコープ」は、システムリソースをアクセス範囲として規定する。グループＳ０に所属するユーザは、システムスコープが規定するリソースアクセス範囲に対し、システム編集ロールが規定する操作を実行する権限を有する。システム管理者は、グループＳ０に所属するため、システムリソースに対し、システム編集ロールが許可する操作を実行することができる。

【0088】

名前空間２６１の他の一例であるテナント１用名前空間２６１－２には、システム管理者およびテナント１管理者がユーザとして登録される。システム管理者はグループＳ１に所属され、テナント１管理者がグループＴ１に所属される。グループＳ１にはリソース作成ロールとテナント１スコープが割り当てられている。また、グループＴ１にはリソース更新ロールとテナント１スコープが割り当てられている。「テナント１リソース」は、ボリュームやコンピュートノード等のリソースのうち、テナント１に対応付けたアクセス範囲のリソースである。「リソース作成ロール」は、テナント１リソースに属するリソースに対する作成操作（例えば図５に例示の“ロール２”や“ロール１０”）を許可するロールである。また、「リソース更新ロール」は、テナント１リソースに属するリソースに対する設定変更等の更新操作（例えば図５に例示の“ロール３”や“ロール１１”）を許可するロールである。「テナント１スコープ」は、テナント１リソースをアクセス範囲として規定する。グループＳ１に所属するユーザは、テナント１スコープが規定するテナント１リソースに対し、リソース作成ロールが規定する操作を実行する権限を有する。また、グループＴ１に所属するユーザは、テナント１スコープが規定するテナント１リソースに対し、リソース更新ロールが規定する操作を実行する権限を有する。

【0089】

テナント１名前空間２６１－２に登録されたシステム管理者は、グループＳ１に所属するため、テナント１リソースに対し、リソース作成ロールが許可する操作を実行することができる。また、テナント１名前空間２６１－２に登録されたテナント１管理者は、グループＴ１に所属するため、テナント１リソースに対し、リソース更新ロールが許可する操作を実行することができる。

【0090】

名前空間２６１のさらに他の一例であるテナント２用名前空間２６１－３についても、テナント１用名前空間２６１－２と同様のユーザ管理を行うことができる。さらに別のテナントを管理する場合には、テナント用名前空間を追加して同様の管理を行う。例えば、１人のシステム管理者が、システムリソース、テナント１スコープ、テナント２スコープのように、別々の名前空間に対応付けたリソースアクセス範囲に対し、必要な操作を行うためには、各名前空間へのユーザ登録および管理が必要となるため、１人のユーザが複数のアカウント情報を扱うことになり管理が煩雑である。

【0091】

このようにテナント毎に独立に認証および認可を行う煩雑さを避ける方法として、図８に例示の方法がある。

【0092】

図８は、比較例に係るマルチテナント管理の別の例を示している。

【0093】

図８が示す例によれば、複数のテナントが単一の名前空間で管理される。例えば、システム用名前空間２６１－１に、システム管理者、テナント１管理者、およびテナント２管理者がユーザとして登録される。システム管理者はグループＳに、テナント１管理者はグループＴ１に、テナント１管理者はグループＴ２に所属される。グループＳにはシステム編集ロールおよびリソース作成ロール、システムスコープ、テナント１スコープおよびテナント２スコープが割り当てられている。また、グループＴ１にはリソース更新ロールとテナント１スコープが割り当てられている。さらに、グループＴ２にはリソース更新ロールとテナント２スコープが割り当てられている。各ロール、スコープ、およびリソース定義については、図７と同様であるため説明を省略する。

【0094】

グループＳに所属するユーザは、システムスコープが規定するシステムリソースに対し、システム編集ロールが規定する操作を実行する権限を有するとともに、テナント１スコープが規定するテナント１リソース、およびテナント２スコープが規定するテナント２リソースに対し、リソース作成ロールが規定する操作を実行する権限を有する。また、グループＴ１に所属するユーザは、テナント１スコープが規定するテナント１リソースに対し、リソース更新ロールが規定する操作を実行する権限を有する。さらに、グループＴ２に所属するユーザは、テナント２スコープが規定するテナント２リソースに対し、リソース更新ロールが規定する操作を実行する権限を有する。

【0095】

システム管理者は、グループＳに所属するため、システムリソースに対するシステム編集ロールが規定する操作、テナント１リソースに対するリソース作成ロールが許可する操作、およびテナント２リソースに対するリソース作成ロールが許可する操作を実行することができる。さらに別のテナントを管理する場合には、テナント管理者を登録して同様の管理を行う。このように単一名前空間に登録したユーザは、システムリソースを含む複数のテナントリソースへのアクセスおよび操作を実行することができる。ただし、この場合は、名前空間内でユーザやグループ等のＲＢＡＣ等で定義される構成要素は一意に登録する必要があるため、例えば、同じ名前空間で管理するユーザは、テナントが異なっても同一ユーザ名のユーザを登録することができない。つまり、テナント間の独立性を担保することができない。

【0096】

そこで、図７に例示のマルチテナント管理に関する課題と図８に例示のマルチテナント管理に関する課題の両方を解決するマルチテナント管理（図９以降を参照して説明するマルチテナント管理）が構築される。

【0097】

図９は、本実施形態に係る計算機システムの論理構成例を示す。図９を参照して、図２に例示の計算機システムとの相違点を主に説明する。

【0098】

名前空間管理基盤９１０は、図２で説明した名前空間管理基盤２６０と異なり、名前空間毎にスコープ管理テーブルを割り当てない。スコープ情報は、名前空間管理基盤９１０内の全体スコープ管理テーブル９１２に格納されまとめて管理される。全体スコープ管理テーブル９１２はスコープ管理部９１３が管理する。ユーザ管理テーブル９１４に格納した情報に対応のユーザに割り当てるスコープは、全体スコープ管理テーブル９１２から選択される。したがって、ユーザには、当該ユーザ自らが所属するテナント以外に対応付けたリソースのアクセス範囲を規定するスコープを割り当てることが可能である。これにより、システムを管理する名前空間に登録されたユーザや、特定テナントを管理する名前空間に登録されたユーザが、当該ユーザ自らが所属する名前空間においてのみユーザ認証し、同名前空間で規定したユーザ情報、およびポリシ情報に基づく認可を行うことにより、当該ユーザ自らが所属する名前空間のみならず、当該ユーザ自らが所属しない名前空間に対応付けたアクセス範囲のリソースにアクセスすることができる。

【0099】

図１０は、全体スコープ管理テーブル９１２の例を示す。

【0100】

全体スコープ管理テーブル９１２は、複数のテナント管理用名前空間に対応付けた、リソース種別毎のアクセス範囲を規定するスコープ情報を格納する。スコープ情報は、スコープ毎に、図６に示したのと同様の構成要素であるスコープＩＤ１００１、スコープ名１００２、リソース種別１００３、およびアクセス範囲１００４を含む。また、スコープ情報は、スコープ毎に、スコープを指定することが可能な名前空間の情報である指定可能名前空間１００５を含む。図１０が示す例では、例えば、システムスコープの対象リソース種別として、プール（／Ｏｂｊ／Ｐｏｏｌ）、ポート（／Ｏｂｊ／Ｐｏｒｔ）、ドライブ（／Ｏｂｊ／Ｄｒｉｖｅ）、ストレージノード（／Ｏｂｊ／Ｓｔｏｒａｇｅ＿ｎｏｄｅ）が指定され、各リソース種別のアクセス範囲としてシステム全体が割り当てられる。また、テナント１スコープの対象リソース種別として、ボリューム（／Ｏｂｊ／Ｖｏｌｕｍｅ）、コンピュートノード（／Ｏｂｊ／Ｃｏｍｐｕｔｅ＿ｎｏｄｅ）が指定され、ボリュームリソース種別のアクセス範囲としてＶｏｌｕｍｅ＿ＩＤ＝１～９、コンピュートノードリソース種別のアクセス範囲としてＣｏｍｐｕｔｅ＿ｎｏｄｅ＿ＩＤ＝１～５が割り当てられる。これにより、テナント１スコープを割り当てたユーザは、ボリュームリソース種別のＶｏｌｕｍｅ＿ＩＤ＝１～９、およびコンピュートノードリソース種別のＣｏｍｐｕｔｅ＿ｎｏｄｅ＿ＩＤ＝１～５のアクセス範囲へのアクセスが可能になる。また、テナント１スコープをアクセス対象として指定可能な名前空間は、システム管理用名前空間、およびテナント１管理用名前空間である。同様に、テナント２スコープ、テナント３スコープ等、ユーザがアクセスするテナントに対応付けたリソース範囲を既定するスコープが登録される。

【0101】

図１１は、ユーザ管理テーブル９１４の例を示す。

【0102】

ユーザ管理テーブル９１４は、システム管理用名前空間で管理するユーザ管理テーブルの例である。ユーザ管理テーブル９１４は、図４に例示のテーブル２６３と同様に、ユーザ情報に含まれる情報として、例えば、ユーザＩＤ１１０１、ユーザ名１１０２、所属グループ名１１０３、ロール名１１０４、およびスコープ１１０５を有する。情報１１０１～１１０５は、図４に例示の情報４０１～４０５と同様である。システム管理者であるユーザ１には、ロール１、ロール５、ロール６、およびシステムスコープが割り当てられている。したがって、ユーザ１は、システムスコープが規定したシステムリソースへのアクセス、およびシステムリソースに対するロール１、ロール５、ロール６が規定する操作が可能である。また、別のシステム管理者であるユーザ２には、ロール１、ロール２、ロール５、ロール６、ロール１０、システムスコープおよびテナント１スコープが割り当てられている。したがって、ユーザ１は、システムスコープが規定したシステムリソースに対するロール１、ロール５、ロール６が規定する操作と、テナント１スコープが規定したテナント１リソースに対するロール２、ロール１０が規定する操作が可能である。

【0103】

テナント１の管理は、図４に示したテナント１管理用名前空間のユーザ管理テーブル２６３を用いて行われる。このため、システム管理用名前空間のユーザ、ユーザグループ等のＲＢＡＣで定義される構成要素は、例えばテナント１管理用名前空間において重複して登録することが可能である。他のテナント管理についても同様である。

【0104】

図１２は、スコープ管理部９１３の論理構成例を示す。

【0105】

システム全体を管理する管理者等のユーザは、図１０に例示したスコープ情報の設定値を、スコープ設定Ｉ／Ｆ（インタフェース）１２０１を用いて、例えばテナント作成時やテナント管理情報更新時等のタイミングで設定する。スコープ設定Ｉ／Ｆ１２０１は、専用ソフトウェアおよび／またはハードウェアを用いて構成してもよいし、例えばストレージ管理インタフェース等のストレージシステムを管理するＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）やＣＬＩ（Ｃｏｍｍａｎｄ Ｌｉｎｅ Ｉｎｔｅｒｆａｃｅ）等のユーザインタフェース機能の一部として構成してもよい。このとき設定するスコープ情報には、リソースアクセス範囲としてスコープを割り当てることを許可する名前空間の指定を含む。スコープ管理部９１３のスコープ設定値登録部１２０２は、スコープ設定Ｉ／Ｆ１２０１を介してシステム管理者等のユーザが設定したスコープ設定値を、全体スコープ管理テーブル９１２に格納する。この時、設定対象スコープが参照するリソース種別や、アクセス範囲、指定可能な名前空間等の設定値の設定範囲に予め制限を設けておき、スコープ設定Ｉ／Ｆ１２０１あるいはスコープ設定値登録部１２０２の中に、ユーザが設定可能なスコープ情報設定値の範囲を限定する機能を設け、スコープ設定Ｉ／Ｆ１２０１において、設定可能な設定値のみをユーザに提示するか、あるいはスコープ設定値登録部１２０２において、ユーザが入力した設定値が制限範囲以外であった場合に設定を拒否する等により、設定値を制限範囲に限定してもよい。

【0106】

図１３は、本実施形態に係るマルチテナント管理の例を示す。

【0107】

図１３の例では、名前空間９１１の１例であるシステム管理用名前空間９１１－１には、システム管理者１が、ユーザとして登録され、グループＳ１に所属される。グループＳ１にはシステム編集ロールとシステムスコープが割り当てられている。グループＳ１に所属するユーザは、システムスコープが規定するリソースアクセス範囲に対し、システム編集ロールが規定する操作を実行する権限を有する。システム管理者１は、グループＳ１に所属するため、システムスコープが規定するシステムリソースに対し、システム編集ロールが許可する操作を実行することができる。

【0108】

また、システム管理者２が、ユーザとして登録され、グループＳ２に所属される。グループＳ２には、システム編集ロールおよびリソース作成ロールと、システムスコープ、テナント１スコープ、およびテナント２スコープとが割り当てられている。グループＳ２に所属するユーザは、システムスコープが規定するシステムリソースに対し、システム編集ロールが規定する操作を実行する権限を有する。また、グループＳ２に所属するユーザは、テナント１スコープが規定するテナント１リソースに対し、リソース作成ロールが規定する操作を実行する権限を有する。さらに、グループＳ２に所属するユーザは、テナント２スコープが規定するテナント２リソースに対し、リソース作成ロールが規定する操作を実行する権限を有する。システム管理者２は、グループＳ２に所属するため、システムリソースに対し、システム編集ロールが規定する操作を実行することができる。また、システム管理者２は、テナント１リソースおよびテナント２リソースに対し、リソース作成ロールが規定する操作を実行することができる。

【0109】

なお、図１３の例では、システム管理者２がグループＳ２に所属され、グループＳ２にシステム編集ロールおよびリソース作成ロールと、システムスコープ、テナント１スコープ、およびテナント２スコープとが割り当てられているが、例えば、図１４に示すように、グループＳ２－１にシステム編集ロールおよびシステムスコープが割り当てられ、グループＳ２－２にシステムリソース作成ロールおよびテナント１スコープが割り当てられ、システム管理者２が、グループＳ２－１およびグループＳ２－２に所属されても、同様の権限設定を行うことが可能である。

【0110】

図１３に例示のテナント１用名前空間９１１－２には、テナント１管理者が、ユーザとして登録され、グループＴ１に所属される。グループＴ１にはリソース更新ロールとテナント１スコープが割り当てられている。グループＴ１に所属するユーザは、テナント１スコープが規定するテナント１リソースに対し、リソース更新ロールが規定する操作を実行する権限を有する。テナント１名前空間に登録されたテナント１管理者は、グループＴ１に所属するため、テナント１リソースに対し、リソース更新ロールが許可する操作を実行することができる。名前空間２６１のさらに他の１例であるテナント２用名前空間９１１－３についても、テナント１用名前空間と同様のユーザ管理を行うことができる。さらに別のテナントを管理する場合には、テナント用名前空間が追加されて同様の管理が行われる。

【0111】

なお、システム管理用名前空間に登録されたシステム管理者２が、他の名前空間であるテナント１管理用名前空間に対応付けたテナント１リソースにアクセスする際に許可する操作と、テナント１管理用名前空間に登録したテナント１管理者が、自らが登録されている名前空間であるテナント１管理用名前空間に対応付けたテナント１リソースにアクセスする際に許可する操作が異なってもよい。図１３の例では、システム管理者２がテナント１リソースにアクセスする場合に許可される操作は、リソース作成ロールによって権限付与された操作であり、テナント１管理者がテナント１リソースにアクセスする場合に許可される操作は、リソース更新ロールによって権限付与された操作としている。これにより、特定リソースへのアクセス権限を、ユーザの所属の違いによって変えることができる。

【0112】

本実施形態によれば、例えば、１人のシステム管理者が、システムリソース、テナント１スコープ、テナント２スコープのように、別々の名前空間に対応付けたリソースアクセス範囲に対し、システム管理用名前空間へのユーザ登録および管理で（他の名前空間へのユーザ登録および管理不要に）、システムリソースを含む複数のテナントリソースへのアクセスおよび操作を実行することができる。また、システム管理者とテナント管理者は別々の名前空間で管理するため、ＲＢＡＣ等で定義される構成要素を独立に登録することができ、したがって、例えば名前空間毎に重複するユーザ名等を登録することができる。

【0113】

なお、図１３に例示の構成は、図７に示したマルチテナント管理や図８に示したマルチテナント管理を組み合わせて用いることを妨げるものではないため、比較例に係るマルチテナント管理からの移行時等、必要に応じて本実施形態に係るマルチテナント管理と、比較例に係るマルチテナント管理を併用することも可能である。

【0114】

図１５は、本実施形態に係るマルチテナント管理においてユーザ作成および権限設定を行うフローの一例を示す。

【0115】

図１５の例では、システム管理者（システムリソース、および、テナントに対応付けたリソースの管理を行うユーザ）、および、システム管理者が所属するグループＳが、システム管理用名前空間９１１－１に作成されて登録される。また、テナント１に対応付けたリソースの管理を行うテナント１管理者、および、テナント１管理者が所属するグループＴ１が、テナント１管理用名前空間９１１－２に作成されて登録される。さらに、テナント２に対応付けたリソースの管理を行うテナント２管理者、および、テナント２管理者が所属するグループＴ２が、テナント２管理用名前空間９１１－３に作成されて登録される。

【0116】

図１６は、本実施形態に係るマルチテナント管理においてシステム管理者の認証および認可を行うフローの一例を示す。

【0117】

システム管理者２がリソースにアクセスして操作を行う際は、システム管理者２が、まずシステム（ストレージシステム１３０）にログインする。図９に示した認証基盤２３０は、ログインした者がシステム管理用名前空間９１１－１に登録された正当なユーザであるかを判定する。システム管理者２は、正当なユーザとして認証許可（ＯＫ）となった後、リソース操作コマンドの実行を要求する。

【0118】

例えば、システム管理者２がシステムリソースの編集コマンドの実行を要求した場合は、図９に示した認可基盤２４０が、当該ユーザに設定されたユーザ情報、およびポリシ情報に基づいて、要求されたコマンドの実行権限を判定する。認可が許可（ＯＫ）された場合に、図９に示したリソース利用アプリケーション２２０を介してリソース管理基盤２５０に対しシステムリソースの編集コマンドが実行される。

【0119】

また、システム管理者２がテナント１のリソースを作成するコマンドの実行を要求した場合は、図９に示した認可基盤２４０が、当該ユーザに設定されたユーザ情報、およびポリシ情報に基づいて要求されたコマンドの実行権限を判定する。認可が許可（ＯＫ）された場合に、図９に示したリソース利用アプリケーション２２０を介してリソース管理基盤２５０に対しテナント１のリソースを作成するコマンドが実行される。

【0120】

さらに、システム管理者２がテナント２のリソースを作成コマンドの実行を要求した場合は、図９に示した認可基盤２４０が、当該ユーザに設定されたユーザ情報、およびポリシ情報に基づいて、要求されたコマンドの実行権限を判定する。認可が許可（ＯＫ）された場合に、図９に示したリソース利用アプリケーション２２０を介してリソース管理基盤２５０に対しテナント２のリソースを作成するコマンドが実行される。この時、システム管理者に対する認証は１回のみでよい。

【0121】

なお、本図（および後の図１７および図１８）では、認証、および認可処理の結果が不許可であった場合のフローが省略されているが、認証、または認可処理の結果が不許可であった場合は、ユーザ端末等を介してエラー情報をユーザに提示し、処理を停止するか、あるいは認証または認可に必要な情報の再入力を要求する等の、通常の認証および認可手順が実行されてよい。

【0122】

図１７は、本実施形態に係るマルチテナント管理においてテナント１管理者の認証および認可を行うフローの一例を示す。

【0123】

テナント１管理者がテナント１に対応付けたリソースにアクセスして操作を行う際は、まずシステム（ストレージシステム）にログインする。図９に示した認証基盤２３０は、ログインした者がテナント１管理用名前空間に登録された正当なユーザであるかを判定する。テナント１管理者は、正当なユーザとして認証許可（ＯＫ）となった後、リソース操作コマンドの実行を要求する。図９に示した認可基盤２４０は、当該ユーザに設定されたユーザ情報、およびポリシ情報に基づいて、要求されたコマンドの実行権限を判定する。認可が許可（ＯＫ）された場合に、図９に示したリソース利用アプリケーション２２０を介してリソース管理基盤２５０に対しテナント１のリソースを作成するコマンドが実行される。

【0124】

図１８に例示するように、テナント２管理者についても、図１７に例示の認証および認可フローと同様のフローが走る。

【0125】

図１９は、図８に例示したマルチテナント管理から図１３に例示したマルチテナント管理への移行の例を示す。

【0126】

名前空間管理基盤２６０が、システム管理用名前空間１９０１に登録され管理されていたテナント１管理者、テナント１管理者が所属するグループＴ１、およびグループＴ１に割り当てられたロールおよびスコープを表す情報を、システム管理用名前空間１９０１で管理するユーザ管理テーブルから抽出し、当該情報を、テナント１管理用名前空間１９０２が管理するユーザ管理テーブルに格納する。このとき、テナント１管理用名前空間１９０２が未作成だった場合は、名前空間管理基盤２６０が、まずテナント１管理用名前空間１９０２を作成する。テナント１スコープは、全体スコープ管理テーブル９１２およびスコープ管理部９１３により、名前空間をまたがって管理されている。このため、テナント１管理者の登録が、システム管理用名前空間１９０１からテナント１管理用名前空間１９０２に移動しても、テナント１管理者のグループＴ１への所属は維持される。このとき、システム管理用名前空間１９０１に登録されたシステム管理者が所属するグループＳに、引き続きテナント１スコープを割り当てておくことにより、システム管理用名前空間１９０１に登録されたシステム管理者は、テナント１スコープが指定するテナント１リソースへのアクセスおよび操作を実行する権限を有する。

【0127】

図２０は、本実施形態に係るマルチテナント管理の別の例を示す。

【0128】

テナント管理者が複数のテナントに対応付けられたリソースにアクセスすることができる。図２０の例では、テナント１管理用名前空間９１１－２に登録されたグループＴ１＿２に、リソース作成ロール、テナント１スコープ、およびテナント２スコープが割り当てられている。テナント１＿２管理者がグループＴ１＿２に所属されることにより、テナント１＿２管理者は、テナント１リソース、およびテナント２リソースにアクセスすることが可能になる。このためには、図１０に示した全体スコープ管理テーブル９１２のテナント２スコープを指定可能な名前空間として、テナント１管理用名前空間を予め登録しておく必要がある。

【0129】

図２１は、本実施形態に係るマルチテナント管理のまた別の例を示す。

【0130】

異なる名前空間に登録されたユーザがマルチテナント管理システム（本実施形態ではストレージシステム１３０）全体で一意に管理される。ユーザを異なる名前空間で管理する場合、通常は異なる名前空間で同じユーザ名等を作成して登録することが可能である。しかし、同一組織内の異なる部署が異なるテナントである等の場合、組織内で一意なユーザ名で管理を行いたい等の理由により、システム全体でユーザ名の重複を避けたいことがある。このような場合には、テナント管理用名前空間にユーザを登録する際には、例えば、名前空間管理基盤９１０は、システム管理用名前空間９１１－１等の単一の名前空間にまずユーザ登録を行う。その後、名前空間管理基盤９１０は、登録しようとするユーザが既にシステム管理用名前空間９１１－１に登録済みでないことを確認してから、対象のテナント管理用名前空間に当該ユーザのユーザ登録を行う。もし、登録しようとするユーザが既にシステム管理用名前空間９１１－１に登録済みであった場合は、名前空間管理基盤９１０は、当該ユーザのユーザ登録を許可しない。これにより、システム管理用名前空間９１１－１には、マルチテナント管理システムの全ての名前空間に登録されているユーザが登録されることになり、マルチテナント管理システム内で一意にユーザを管理することが可能である。グループ名等、ＲＢＡＣ等で定義される一意な管理が必要な他の構成要素についても、同様の方法を用いることが可能である。なお、テナント管理用名前空間に登録するユーザに対応する、システム管理用名前空間のユーザについては、ユーザ情報として、ユーザＩＤおよびユーザ名が含まれていればよく、グループ、ロール、スコープ等の情報については必須ではない。

【0131】

図２２は、本実施形態に係るマルチテナント管理のまた別の例を示す。

【0132】

図２２が示す例によれば、システム管理用名前空間９１１－１の、テナント管理用名前空間に登録したユーザに対応するユーザに、当該ユーザを登録している名前空間の情報が対応付けて管理される。名前空間毎に独立にユーザを登録および管理するシステムにおいて、ユーザ認証を行う際に、認証を要求したユーザがどの名前空間に登録されているかを判別する情報が付与されなかった場合は、名前空間管理基盤９１０は、システム上に存在する全ての名前空間に対し、認証を要求したユーザの、ユーザ名やパスワード、生体情報等のユーザ情報が合致して認証が成功するまで、順番に認証操作を繰り返す必要がある。システム上に名前空間が多数存在する場合等では、認証を要求したユーザが登録されている名前空間に対し認証を実行する順番が下位になるほど、認証を実行するのに要する時間がかかり、ユーザの利便性が損なわれる可能性がある。そこで、テナント管理用名前空間に登録されているユーザに対応付けた、システム管理用名前空間に登録したユーザに、当該ユーザが登録されている名前空間の情報を付与する。ユーザと名前空間の対応付けは、例えば図１１に示したユーザ管理テーブル９１４に追記してもよいし、独立のテーブルを用意してもよい。ユーザが認証を要求した際に、認証基盤２３０は、最初にシステム管理用名前空間９１１－１に対して認証を実行してよい。照合したユーザが、他のテナント管理用名前空間に登録されている場合は、認証基盤２３０は、当該ユーザが登録されている名前空間の情報を上記ユーザと名前空間の対応付け情報に基づいて抽出し、次に、抽出した名前空間に対し認証を実行してよい。これにより、認証に係る時間を短縮することが可能になる。

【0133】

図２３は、本実施形態に係るマルチテナント管理のまた別の例を示す。

【0134】

認証対象となる全ての名前空間に登録されている全ユーザと各ユーザが登録されている名前空間とを対応付けた情報を格納したユーザ所属テーブル２３０１を、名前空間管理基盤９１０が保持する。システムに対しユーザ認証が要求された際には、まず名前空間管理基盤９１０が、ユーザ所属テーブル２３０１を参照し、認証対象ユーザが登録されている名前空間を抽出して、当該名前空間に対し認証を実行する。これにより、ユーザ認証を実行する際に、必ず当該ユーザが登録されている名前空間を選択することができ、認証に係る時間を短縮することが可能になる。

【0135】

図２４は、ユーザ所属テーブル２３０１の例を示す。

【0136】

図２４が示す例によれば、システム管理者１は、システム管理用名前空間に対応付けられている。また、テナント１管理者は、テナント１管理用名前空間に対応付けられている。例えば、テナント１管理者ユーザが認証を要求した場合は、ユーザ所属テーブル２３０１を照合し、テナント１管理者ユーザが登録されている名前空間がテナント１管理用名前空間であることを抽出して、テナント１管理用名前空間に対し認証を実行する。

【0137】

なお、本発明は上記した実施形態に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明したすべての構成を備えるものに限定されるものではない。また、ある実施形態の構成の一部を他の実施形態の構成に置き換えることが可能であり、また、ある実施形態の構成に他の実施形態の構成を加えることも可能である。また、各実施形態の構成の一部について、他の構成の追加、削除および／または置換をすることが可能である。

【0138】

また、上記の各構成、機能および処理部等は、それらの一部または全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記録装置、または、ＩＣカード、ＳＤカード等の記録媒体に置くことができる。

【0139】

また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしもすべての制御線や情報線を示しているとは限らない。実際には殆どすべての構成が相互に接続されていると考えてもよい。

【0140】

以上の説明を、例えば、下記のように総括することができる。下記の総括は、上述の説明の補足説明や変形例の説明を含んでよい。

【0141】

マルチテナント管理システムは、複数のテナントに使用され得る複数のリソースを有するシステム（例えば、ストレージシステム１３０）でもよいし、複数のリソースを有するシステムとユーザとの間に介在し、マルチテナント管理システムそれ自体が、複数のテナントに使用され得る複数のリソースを有さないでもよい。また、以下の説明では、「テナント」は、組織または組織内の部署といった要素でもよいし、複数の組織や複数の部署全体を管理する要素（つまり、１または２以上の「テナント」を管理する「テナント」）でもよい。

【0142】

マルチテナント管理システムが、インタフェース装置（例えばホストＩ／Ｆ１３２）、記憶装置（例えばメモリ１３６）、および、それらに接続されたプロセッサ（例えばプロセッサ１３５）を有する。インタフェース装置が、ユーザに関する情報であるユーザ情報と、テナントに関する情報であるテナント情報と、複数のリソースのうちのアクセス先のリソースを指定したリソースアクセス要求とをユーザ端末１００から受け付ける。リソースアクセス要求では、ユーザ所望の操作が指定されてもよい。記憶装置が、テナント毎の名前空間を含む複数の名前空間（例えば２６１または９１１）の各々について、当該名前空間に対応のテナントに関連付けられたユーザに関する情報を含んだユーザ管理情報（例えばユーザ管理テーブル９１４または２６３）と、全てのテナントスコープの各々について当該テナントスコープに対応のリソースアクセス範囲を表す情報である全体スコープ管理情報（例えば全体スコープ管理テーブル９１２）とを記憶する。各名前空間について、ユーザ管理情報は、１または２以上のテナントの各々についてのリソースアクセス範囲のラベルであるテナントスコープを表す情報を含む。ユーザ管理情報は、１または２以上の操作を表す情報を含んでもよい。

【0143】

プロセッサは、受け付けられたテナント情報が表すテナントに対応した名前空間を選択する。プロセッサは、受け付けられたユーザ情報が選択された名前空間のユーザ管理情報が有する情報に適合するかの判定である認証判定を行う。認証判定の結果が真の場合、プロセッサは、受け付けられたリソースアクセス要求に従うアクセス先のリソースが、選択された名前空間のユーザ管理情報が表すいずれかのテナントスコープに対応し全体スコープ管理情報から特定されるリソースアクセス範囲に属するか否かの判定である認可判定を行う。認可判定は、受け付けられたリソースアクセス要求に従う操作が、選択された名前空間のユーザ管理情報が表す操作に該当するか否かの判定を含んでもよい。認可判定の結果が真の場合、プロセッサは、受け付けられた前記リソースアクセス要求を実行させる。

【0144】

これにより、テナント間の独立性を担保しつつ、ユーザが名前空間毎の認証無しに複数のテナントのリソースにアクセスすることができる。具体的には、名前空間は、分離（独立）が目的の要素であるため、通常、複数の名前空間の共通化はされない。しかし、テナントスコープの管理が、異なる名前空間で共通とされる（異なる名前空間に跨る）。このため、テナント間の独立性を維持した状態で、名前空間別の認証および認可といった煩わしさ（異なるテナントのリソースをユーザが管理するにあたりテナント毎の名前空間について認証および認可が必要になるといった煩わしさ）を解消することができる。

【0145】

複数の名前空間は、不特定テナントに対応の名前空間としてのシステム管理用の名前空間（例えば、名前空間９１１－１）を含んでよい。システム管理用の名前空間に関連付けられた１または２以上のテナントスコープは、全体のリソースの範囲が対応付けられたシステムスコープを含んでよい。これにより、システム管理用の名前空間での認証を通じて、別の名前空間についての認証無しに、システムスコープに対応のリソースや、テナントスコープに対応のリソースのいずれにもユーザがアクセスすることができる。具体的には、例えば、システム管理用の名前空間のユーザ管理情報が、システム管理用の名前空間とは別の名前空間に対応のテナントのためのテナントスコープを表してよい。受け付けられたテナント情報からシステム管理用の名前空間が選択され、システム管理用の名前空間のユーザ管理情報を用いて認証判定の結果が真となった場合、プロセッサは、認可判定において、リソースアクセス要求を基に、システム管理用の名前空間に関連付けられている、別の名前空間に対応のテナントのためのテナントスコープを特定し、当該テナントスコープに対応のリソースアクセス範囲を前記全体スコープ管理情報から特定してよい。

【0146】

各名前空間について、ユーザ管理情報は、ユーザのグループ毎に、当該グループに関連付けられた１または２以上のテナントスコープを表す情報を含んでよい。つまり、ユーザのグループ単位で、テナントスコープの関連付けが可能である。

【0147】

第１のテナントの第１のユーザに関する情報と第２のテナントの第２のユーザに関する情報とが単一の名前空間（例えば図２０の名前空間９１１－２）のユーザ管理情報に含まれている場合、プロセッサは、第２のテナントに対応の名前空間（例えば図２０の名前空間９１１－３）を生成し、生成した当該名前空間のユーザ管理情報に、第２のテナントの前記第２のユーザに関する情報を移してよい。これにより、単一名前空間での複数のテナントの管理を、テナント間の独立性が担保された管理に移行することができる。

【0148】

複数の名前空間のうちの或る名前空間（例えば図２２の名前空間９１１－１）のユーザ管理情報が、当該或る名前空間と異なる１以上の名前空間のユーザ管理情報に登録されている１以上のユーザに関する情報を含んでよい。或る名前空間のユーザ管理情報は、１以上のユーザの各々について、当該ユーザに関する情報が登録されている名前空間を表す情報を含んでよい。プロセッサは、或る名前空間のユーザ管理情報から、ユーザ情報が表すユーザに対応の名前空間（例えば、テナント２管理者に対応のテナント２名前空間９１１－３）を特定し、特定された当該名前空間のユーザ管理情報と上記受け付けられたユーザ情報（例えば、テナント２管理者のユーザ情報）とを基に認証判定を行ってよい。これにより、ユーザは、自身が登録されている名前空間を探すために個々の名前空間について認証を試みること無しに、当該ユーザが登録されている名前空間について認証を受けることが期待できる。

【0149】

記憶装置が、ユーザ毎に当該ユーザが登録されている名前空間を表す情報であるユーザ所属情報（例えば図２４のユーザ所属テーブル２３０１）を記憶してよい。プロセッサは、ユーザ所属情報から、ユーザ情報が表すユーザに対応の名前空間を特定し、特定された当該名前空間のユーザ管理情報と上記ユーザ情報とを基に認証判定を行ってよい。これにより、ユーザは、自身が登録されている名前空間を探すために個々の名前空間について認証を試みること無しに、当該ユーザが登録されている名前空間について認証を受けることが期待できる。

【符号の説明】

【0150】

１００ ユーザ端末
１１０ ホストサーバ
１２０ 管理サーバ
１３０ ストレージシステム

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】