特開 2023-118208 アクセス制御システム及びアクセス制御方法

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

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2023118208

(43)【公開日】2023-08-25

(54)【発明の名称】アクセス制御システム及びアクセス制御方法

(51)【国際特許分類】

   G06F 21/62 20130101AFI20230818BHJP

【ＦＩ】

G06F21/62 318

【審査請求】未請求

【請求項の数】14

【出願形態】ＯＬ

(21)【出願番号】P 2022021028

(22)【出願日】2022-02-15

(71)【出願人】

【識別番号】000005108

【氏名又は名称】株式会社日立製作所

(74)【代理人】

【識別番号】110001678

【氏名又は名称】藤央弁理士法人

(72)【発明者】

【氏名】在塚 俊之

(72)【発明者】

【氏名】山本 貴大

(72)【発明者】

【氏名】平井 達哉

(72)【発明者】

【氏名】斎藤 秀雄

(57)【要約】

【課題】システムのセキュリティ性の低下を抑制しつつ、ユーザ必要なリソースアクセスを実行することを許可する。
【解決手段】アクセス制御システムは、ユーザそれぞれのリソースアクセスの実行を許可する条件を規定する情報を格納する。アクセス制御システムは、第１ユーザによる対象システム内の第１リソースに対する操作を示す第１アクセス要求を取得し、上記情報に基づき、第１アクセス要求の許否を判定し、第１アクセス要求の不許可判定に対して第１アクセス要求の追加の許否判定の結果を取得し、許可を示す追加の許否判定の結果に従って第１ユーザによる第１アクセス要求の実行権限を付与する。
【選択図】図２

【特許請求の範囲】

【請求項1】

ユーザのリソースへのアクセスを制御するアクセス制御システムであって、
１以上のプロセッサと、
ユーザそれぞれのリソースアクセスの実行を許可する条件を規定する情報を格納する、１以上の記憶装置と、を含み、
前記１以上のプロセッサは、
第１ユーザによる対象システム内の第１リソースに対する操作を示す第１アクセス要求を取得し、
前記情報に基づき、前記第１アクセス要求の許否を判定し、
前記第１アクセス要求の不許可判定に対して、前記第１アクセス要求の追加の許否判定の結果を取得し、
許可を示す前記追加の許否判定の結果に従って、前記第１ユーザによる前記第１アクセス要求の実行権限を付与する、アクセス制御システム。

【請求項2】

請求項１に記載のアクセス制御システムであって、
前記１以上のプロセッサは、
前記第１アクセス要求の不許可判定に対して、前記第１アクセス要求の前記追加の許否判定の要求を管理者に提示し、
前記管理者から前記追加の許否判定の結果を受け取る、アクセス制御システム。

【請求項3】

請求項２に記載のアクセス制御システムであって、
前記１以上のプロセッサは、前記追加の許否判定の要求と共に、前記対象システムの状態及び前記第１ユーザの状態の少なくとも一方の情報を前記管理者に提示する、アクセス制御システム。

【請求項4】

請求項２に記載のアクセス制御システムであって、
前記１以上の記憶装置は、補助情報を格納し、
前記補助情報は、
前記対象システムの状態及び前記第１ユーザを含む１以上のユーザの状態の少なくとも一方の情報と、
前記追加の許否判定の基準の情報と、を含み、
前記１以上のプロセッサは、前記追加の許否判定の基準を満たす前記少なくとも一方の情報を前記管理者に提示する、アクセス制御システム。

【請求項5】

請求項１に記載のアクセス制御システムであって、
前記１以上の記憶装置は、補助情報を格納し、
前記補助情報は、
前記対象システムの状態及び前記第１ユーザを含む１以上のユーザの状態の少なくとも一方の情報と、
前記追加の許否判定の基準の情報と、を含み、
前記１以上のプロセッサは、前記補助情報に基づいて、前記第１アクセス要求の追加の許否判定を実行する、アクセス制御システム。

【請求項6】

請求項２に記載のアクセス制御システムであって、
前記１以上の記憶装置は、１以上のリソースアクセスグループを定義するリソースアクセス管理情報を格納し、
前記１以上のプロセッサは、
前記リソースアクセス管理情報から、前記第１アクセス要求と同一のリソースアクセスグループに含まれる付随リソースアクセスの情報を取得し、
前記付随リソースアクセスの情報を前記管理者に提示し、
前記管理者から、前記付随リソースアクセスの許否の判定結果を取得する、アクセス制御システム。

【請求項7】

請求項５に記載のアクセス制御システムであって、
前記１以上の記憶装置は、１以上のリソースアクセスグループを定義するリソースアクセス管理情報を格納し、
前記１以上のプロセッサは、
前記リソースアクセス管理情報から、前記第１アクセス要求と同一のリソースアクセスグループに含まれる付随リソースアクセスの情報を取得し、
前記付随リソースアクセスの許否判定を前記補助情報に基づいて実行する、アクセス制御システム。

【請求項8】

ユーザのリソースへのアクセスを制御する、アクセス制御方法であって、
システムが、第１ユーザによる対象システム内の第１リソースに対する操作を示す第１アクセス要求を取得し、
前記システムが、ユーザそれぞれのリソースアクセスの実行を許可する条件を規定する情報に基づき、前記第１アクセス要求の許否を判定し、
前記システムが、前記第１アクセス要求の不許可判定に対して、前記第１アクセス要求の追加の許否判定の結果を取得し、
前記システムが、許可を示す前記追加の許否判定の結果に従って、前記第１ユーザによる前記第１アクセス要求の実行権限を付与する、アクセス制御方法。

【請求項9】

請求項８に記載のアクセス制御方法であって、
前記システムが、前記第１アクセス要求の不許可判定に対して、前記第１アクセス要求の前記追加の許否判定の要求を管理者に提示し、
前記システムが、前記管理者から前記追加の許否判定の結果を受け取る、アクセス制御方法。

【請求項10】

請求項９に記載のアクセス制御方法であって、
前記システムが、前記追加の許否判定の要求と共に、前記対象システムの状態及び前記第１ユーザの状態の少なくとも一方の情報を前記管理者に提示する、アクセス制御方法。

【請求項11】

請求項９に記載のアクセス制御方法であって、
前記システムが補助情報を参照し、前記補助情報は、前記対象システムの状態及び前記第１ユーザを含む１以上のユーザの状態の少なくとも一方の情報と、前記追加の許否判定の基準の情報と、を含み、
前記システムが、前記追加の許否判定の基準を満たす前記少なくとも一方の情報を前記管理者に提示する、アクセス制御方法。

【請求項12】

請求項８に記載のアクセス制御方法であって、
前記システムが補助情報を参照し、前記補助情報は、前記対象システムの状態及び前記第１ユーザを含む１以上のユーザの状態の少なくとも一方の情報と、前記追加の許否判定の基準の情報と、を含み、
前記システムが、前記補助情報に基づいて、前記第１アクセス要求の追加の許否判定を実行する、アクセス制御方法。

【請求項13】

請求項９に記載のアクセス制御方法であって、
前記システムが、１以上のリソースアクセスグループを定義するリソースアクセス管理情報から、前記第１アクセス要求と同一のリソースアクセスグループに含まれる付随リソースアクセスの情報を取得し、
前記システムが、前記付随リソースアクセスの情報を前記管理者に提示し、
前記システムが、前記管理者から、前記付随リソースアクセスの許否の判定結果を取得する、アクセス制御方法。

【請求項14】

請求項１２に記載のアクセス制御方法であって、
前記システムが、１以上のリソースアクセスグループを定義するリソースアクセス管理情報から、前記第１アクセス要求と同一のリソースアクセスグループに含まれる付随リソースアクセスの情報を取得し、
前記システムが、前記付随リソースアクセスの許否判定を前記補助情報に基づいて実行する、アクセス制御方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、リソースへのアクセス制御に関する。

【背景技術】

【0002】

ストレージシステム等のリソースへのアクセスを、許可されたユーザに限定する制御を行うことにより、不正アクセスを防止し、セキュリティ性を高める機能が用いられる。良く用いられるアクセス制御方式の１つであるＲＢＡＣ（Ｒｏｌｅ Ｂａｓｅｄ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）では、リソースにアクセスするユーザに、業務等の役割に応じてアクセス権を付与したロールを割り当て、認可判定部が、ユーザに割り当てられたロールに基づいてリソースへのアクセス可否を判定して認可する。

【0003】

例えば、本開示の背景技術を開示する先行文献として、米国特許出願公開第２０１９／０３６１７２６号がある。米国特許出願公開第２０１９／０３６１７２６号は、仮想化技術を利用したリソースに対するアクセス制御を開示する。具体的には、複数のリソースを有する計算機システムは、リソース及びリソースグループを対応付けた情報を格納するリソース管理情報と、リソースグループを利用可能なユーザ及びプログラムを対応付けた情報を格納するリソースグループ管理情報と、を含む。リソース利用プログラムから、プログラムを使用するユーザにかかるリソースを指定したリクエストを受信した場合に、制御部は、リソースグループ管理情報と、リソース管理情報とを用いて、リクエストにかかるリソースへのアクセス可否を判定する。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】米国特許出願公開第２０１９／０３６１７２６号

【発明の概要】

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

【0005】

従来は、ユーザに不必要な権限を与えるリスクを避けるため、予め付与するリソースアクセス権限を限定していた。この場合は、後から必要になったリソースアクセス権限は、ユーザに付与されてない可能性があった。逆に、ユーザの利便性を向上させるため、後から必要となる可能性のあるリソースアクセス権限を、予め付与していた。この場合は、必要のないリソースアクセス実行権限が付与されてセキュリティ性が低下してしまうリスクがあった。

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

【0006】

本開示の代表的な例は、ユーザのリソースへのアクセスを制御するアクセス制御システムであって、１以上のプロセッサと、ユーザそれぞれのリソースアクセスの実行を許可する条件を規定する情報を格納する、１以上の記憶装置と、を含み、前記１以上のプロセッサは、第１ユーザによる対象システム内の第１リソースに対する操作を示す第１アクセス要求を取得し、前記情報に基づき、前記第１アクセス要求の許否を判定し、前記第１アクセス要求の不許可判定に対して、前記第１アクセス要求の追加の許否判定の結果を取得し、許可を示す前記追加の許否判定の結果に従って、前記第１ユーザによる前記第１アクセス要求の実行権限を付与する。

【発明の効果】

【0007】

本発明の代表的な一例によれば、システムのセキュリティ性の低下を抑制しつつ、ユーザ必要なリソースアクセスを実行することを許可できる。前述した以外の課題、構成及び効果は、以下の実施例の説明により明らかにされる。

【図面の簡単な説明】

【0008】

【図1】本明細書の第１の実施例に係る計算機システムの構成例を示す。

【図2】計算機システムの論理構成例を模式的に示す。

【図3】ユーザ端末のコマンド取得部が発行するリソースアクセスコマンドの例を示す。

【図4】ユーザ認証部がユーザ認証において利用することができる認証タイプの例を示す。

【図5】ユーザ管理テーブルの例を示す。

【図6】ポリシ管理テーブルの例を示す。

【図7】本明細書の第１の実施例に係るリソースアクセス制御の処理フローの例を示す。

【図8】本明細書の第２の実施例に係る計算機システムの論理構成例を模式的に示す。

【図9】判定補助情報管理テーブルの例を示す。

【図10】本明細書の第３の実施例に係る計算機システムの論理構成例を模式的に示す。

【図11】本明細書の第４の実施例に係る計算機システムの論理構成例を模式的に示す。

【図12】ロール管理テーブルの例を示す。

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

【0009】

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

【0010】

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

【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】

上述のように、システム管理者２０は、補助情報によって、ユーザによるリソース操作の必要性やリソース操作許可時の問題発生の蓋然性（安全性）を知ることができる。これにより、システム管理者２０はより適切な判定を行うことができる。なお、リソース又はユーザの一方のみの補助情報、例えば、リソースについての補助情報のみをシステム管理者２０に提示してもよい。