JP7282113B2 - ユーザのリソースへのアクセスを制御するシステム及び方法 - Google Patents

Description

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

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

米国特許出願公開第２０１９／０３６１７２６号

リソースへのアクセスを、許可されたユーザに限定するセキュリティ機能は、ユーザの役割や属性に基づくことができる。複数業務や作業に従事するユーザは、リソースアクセス権限を区分するため複数の役割や属性が割り当てられる。しかし、例えばユーザが保守員業務を担当し、状況に応じて異なる作業を実施する場合、このアクセス制御機能は、ある時点でどの作業従事者としてリソースにアクセスしているかを判別できず、セキュリティリスクが高まる。

本開示の代表的な例は、ユーザのリソースへのアクセスを制御するシステムであって、１以上のプロセッサと、リソースの操作に対する条件を規定するポリシ情報を格納する、１以上の記憶装置と、を含み、前記１以上のプロセッサは、ユーザ端末から、ユーザによる第１リソースに対する所定操作を示す第１アクセス要求を取得し、前記ユーザ端末から、前記ユーザの現在の状態を示すユーザ状態情報を取得し、前記ユーザ状態情報に基づき、前記ユーザによるアクセス時の条件を判定し、前記ポリシ情報及び前記アクセス時の条件に基づき、前記第１アクセス要求の許否を判定する。

本発明の代表的な実施例によれば、リソースアクセスにおけるセキュリティリスクを低減できる。前記した以外の課題、構成および効果は、以下の実施例の説明により明らかにされる。

本明細書の一実施例に係る計算機システムの構成例を示す。 計算機システムの論理構成例を模式的に示す。 ユーザ端末のコマンド発行部が発行するリソースアクセスコマンドの例を示す。 ユーザ認証部がユーザ認証において利用することができる認証タイプの例を示す。 アクセス状態取得部が取得する情報の例を示す。 ユーザ状態を判定するために使用できる状態取得デバイス、取得データ及び取得データからユーザ状態を判定する方法、の例を示す。 アクセス条件判定方法の例を示す。 ユーザのリソースアクセス条件を用いたポリシの例を示す ユーザアクセス条件に基づくリソースアクセス認証及び認可システムの処理フローの例を示す。 リソース操作パラメータの認可を行う認証及び認可システムの構成例を示す。 リソース操作パラメータの認可判定を行うポリシの例を示す。

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

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

以下の説明では、「テーブル」、「リスト」、「キュー」等の表現にて各種情報を説明することがあるが、各種情報は、これら以外のデータ構造で表現されていてもよく、データ構造に依存しないことを示すため、「ｘｘｘのテーブル」、「ｘｘｘのリスト」、「ｘｘｘのキュー」等を「ｘｘｘ情報」等と称することがある。以下の説明では、識別情報について説明する際に、「識別情報」、「識別子」、「名」、「ＩＤ」、「番号」等の表現を用いるが、これらについてはお互いに置換が可能である。

以下の説明では、同一あるいは同様な機能を有する構成要素が複数ある場合には、基本的に同一の符号を付して説明するが、機能が同じであっても機能を実現するための手段が異なる場合がある。さらに、後述する本発明の実施例は、汎用計算機上で稼動するソフトウェアで実装してもよいし、専用ハードウェア又はソフトウェアとハードウェアの組み合わせで実装してもよい。

また、以下の説明では「プログラム」を主語として処理を説明することがあるが、プログラムはプロセッサ（例えば、ＣＰＵ：Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ） によって実行されることによって、定められた処理に対して、適宜に記憶資源（例えば、メモリ）、および／または、インタフェースデバイス（通信ポート）等を用いながら行うため、処理の主体がプロセッサとして説明してもよい。

プログラムを主語として説明された処理は、プロセッサを有する計算機（例えば、計算ホスト、ストレージ装置）が行う処理としてもよい。また、以下の説明では、「コントローラ」の表現で、プロセッサ又はプロセッサが行う処理の一部又は全部を行うハードウェア回路を指してもよい。

プログラムは、プログラムソース（例えば、プログラム配布サーバや、計算機が読み取り可能な記憶メディア）から、各計算機にインストールされてもよく、この場合、プログラム配布サーバはＣＰＵと記憶資源を含み、記憶資源はさらに配布プログラムと配布対象であるプログラムを記憶し、配布プログラムをＣＰＵが実行することで、プログラム配布サーバのＣＰＵは配布対象のプログラムを他の計算機に配布してもよい。

また、以下の説明において、２以上のプログラムが１つのプログラムとして実現されてもよいし、１つのプログラムが２以上のプログラムとして実現されてもよい。

また、以下の説明において、記憶ドライブ又は単にドライブは、物理的な記憶デバイスを意味し、典型的には、不揮発性の記憶デバイス（例えば補助記憶デバイス）でもよい。ドライブは、例えば、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）又はＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）でもよい。ストレージシステムに異なる種類のドライブが混在していてもよい。

以下において、本明細書の一実施形態に係るリソースアクセス制御を説明する。ストレージリソース等へのアクセスを、許可されたユーザに限定するセキュリティ機能が要求される。ユーザの役割や属性に基づくアクセス制御は、複数の業務又は作業に従事するユーザに、リソースアクセス権限を区分するため複数の役割や属性情報を割り当てる。しかし、例えばユーザが保守員業務を担当し、状況に応じて異なる作業を実施する場合、このアクセス制御技術は、ある時点でどの作業従事者としてリソースにアクセスしているかを判別することができず、誤操作といったセキュリティリスクが高まる。

本明細書の一実施形態は、リソースへの操作を示すアクセス要求を行ったユーザのアクセス状態に基づき、アクセス条件を判定する。アクセス要求に対して規定された条件とアクセス条件とを比較して、当該アクセス要求の拒否を判定する。これにより、リソースアクセスにおけるセキュリティリスクを低減できる。以下において、ストレージリソースへのアクセス制御の例を説明する。本開示の特徴は、ストレージシステムと異なるシステムへのリソースアクセス制御に適用することができる。

図１は、本明細書の一実施例に係る計算機システムの構成例を示す。計算機システムは、ユーザ端末１００、ホストサーバ２１０、管理サーバ２２０及びストレージシステム２３０と、を含む。これらは、ネットワーク２５０を介して通信可能である。なお、これら構成要素それぞれの数は任意である。また、ユーザ端末１００が、ホストサーバ２１０又は管理サーバ２２０の機能を含んでもよい。

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

ユーザ端末１００は、ユーザから計算機システムへのアクセスを可能とする装置である。ユーザ端末１００は、例えば一般的な計算機構成を有することができ、１以上のプロセッサ、１以上の記憶装置及び１以上のネットワークインタフェース及び１以上の入出力インタフェースを含む。ユーザ端末１００は、特定処理専用のハードウェアを含んでもよい。

ホストサーバ２１０は、ユーザアプリケーション等が動作するホストマシンである。ホストサーバ２１０は、例えば一般的な計算機構成を有することができ、１以上のプロセッサ、１以上の記憶装置及び１以上のインタフェースを含む。ホストサーバ２１０は、特定処理専用のハードウェアを含んでもよい。

ホストサーバ２１０は、様々なソフトウェアプログラムを実行することができ、例えば、データベースやＷｅｂサービスを実行し、それらにより作られたデータを、ネットワーク２５０を介してストレージシステム２３０にライト及びリードする。ホストサーバ２１０は、後述するリソース利用アプリケーションを実行してもよい。

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

計算機システムは、後述する認証及び認可システムを含む。ストレージシステム２３０は、コントローラ２３１及びドライブボックス２３７を含む。コントローラ２３１は、ホストインタフェース２３２、管理インタフェース２３３、ドライブインタフェース２３４、プロセッサ２３５、及びメモリ２３６を含む。これら構成要素の数は任意である。

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

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

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

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

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

複数のコントローラが冗長化のために実装されていてもよい。複数コントローラは、ストレージシステム２３０内のネットワークを介して通信する。コントローラは、ネットワークを介して、ライトデータの２重化やメタデータの共有等を行う。一方のコントローラが保守や障害等で閉塞しても、もう一方のコントローラにより、ストレージ処理を継続可能となる。

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

図２は、本明細書の一実施例に係る計算機システムの論理構成例を模式的に示す。計算機システムは、リソースアクセス認証及び認可システムを含む。リソース計算機システムは、リソース利用アプリケーション１２０、認証基盤１３０、認可基盤１４０、及びリソースサーバ１５０を含む。これらは、計算機システムに実装されるソフトウェア構成要素又は例えばプロセッサにより実現される機能構成要素を表す。

リソース利用アプリケーション１２０は、例えば、ホストサーバ２１０に含まれる。認証基盤１３０、認可基盤１４０、及びリソースサーバ１５０は、例えば、ストレージシステム２３０に含まれる。

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

ユーザ端末１００は、ユーザインタフェース１０１、コマンド発行部１０２及びアクセス状態取得部１０３を実行する。ユーザインタフェース１０１は、ユーザ１０がユーザ端末１００を用いてリソース操作の実行を要求するためのユーザインタフェースであり、例えば、Ｗｅｂブラウザを利用することができる。

コマンド発行部１０２は、ユーザ１０が入力したリソースアクセス要求を、リソース利用アプリケーション１２０が解釈可能なアクセス先リソース、操作及びパラメータを実行コマンドに変換して発行する。

アクセス状態取得部１０３は、ユーザ１０がリソースへの操作を要求した時の状態の情報を取得する。アクセス状態は、ユーザ１０の状態及びユーザ端末１００の状態を含む。例えば、ユーザ端末１００が接続しているネットワークドメイン（ＷＡＮ、ＬＡＮ、Ｐｒｉｖａｔｅ ＮＷ）、ユーザ端末種別（デスクトップＰＣ、ノートＰＣ、タブレット、スマートフォン、公共端末等）、ネットワークセキュリティ状態（公開ネットワーク、ＶＰＮ（Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）等）、アクセス日時、状態取得デバイス１１０を用いて取得した情報、及びユーザ１０が自ら入力した状態情報を含む。

状態取得デバイス１１０は、ユーザ端末１００に接続される又はユーザ端末１００に内蔵されるデバイスである。状態取得デバイス１１０は、各種センサ、例えば、加速度センサ、照度センサ、温度及び湿度センサ、マイク、カメラ等を含むことができる。状態取得デバイス１１０は、ユーザ状態の情報を取得する。ユーザ状態情報は、ユーザ１０自身の体勢や動き及びユーザ１０の周囲環境の情報を含む。

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

認証要否判定部１２１は、ユーザ１０がリソースアクセス要求を行った際に、該ユーザを識別する情報、例えばアカウント名を取得し、認証が必要か又はすでに認証済ユーザかを判定する。未認証だった場合、認証要否判定部１２１は、認証基盤１３０に認証を要求する。

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

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

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

認証基盤１３０は、リソース利用アプリケーション１２０からの認証要求を受け、ユーザ認証を実行する。認証基盤１３０は、ユーザ認証部１３２及びユーザ管理テーブル１３１を含む。ユーザ認証部１３２は、ユーザ１０からのサインインを処理する。具体的には、ユーザ認証部１３２は、ユーザ１０から入力されたパスワード又は指紋や顔の生体情報を用いて、ユーザ１０が本人であることを認証する。

ユーザ管理テーブル１３１は、認証対象として登録されたユーザの情報、例えば、ユーザ名、所属、Ｅ－ｍａｉｌアドレス、パスワード、役割、グループ、アクセス日時等を格納する。ユーザ認証部１３２は、ユーザ１０のサインイン時の入力情報とユーザ管理テーブル１３１に格納されている情報とを照合することにより、ユーザ認証を行う。

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

認可基盤１４０は、ポリシ判定部１４１、ポリシ管理テーブル１４２、リソース及び操作管理テーブル１４３、アクセス認可部１４４、及びアクセス条件判定部１４５を含む。アクセス条件判定部１４５は、アクセス状態取得部１０３によって取得したユーザ状態情報を含むアクセス情報場情報から、ユーザ１０がリソースアクセスを要求した時のアクセス時の条件（アクセス条件）を判定する。例えば、アクセス状態取得部１０３が取得した各種データから、予め設定されているルールに基づいて、アクセス条件を判定する。または、機械学習により生成されるモデルを利用するＡＩ（Ａｒｔｉｆｉｃｉａｌ Ｉｎｔｅｌｌｉｇｅｎｃｅ）手法等により、アクセス条件を判定してもよい。

ポリシ判定部１４１は、ユーザ認証部１３２で認証されたユーザの情報、アクセス要求されたリソース及び操作の情報を、認証基盤１３０及びリソース利用アプリケーション１２０から受け取る。ポリシ判定部１４１は、さらに、アクセス条件判定部１４５によって判定したアクセス条件を取得する。

ポリシ判定部１４１は、それらをポリシ管理テーブル１４２に予め設定されたリソースアクセスポリシと照合して、該ユーザ１０が要求されたリソースへのアクセス権及び操作実行権を有するか判定する。

ポリシ管理テーブル１４２は、ポリシ判定部１４１で使用するアクセスポリシの情報（ポリシ情報）を格納する。ポリシは、リソース毎に、リソースにアクセス及び操作するための判定ルールを定義している。ポリシ管理テーブル１４２は、ユーザ認証部１３２で認証されたユーザ１０の情報と、アクセス条件判定部１４５で判定されたユーザ１０のアクセス条件とに基づいて、リソースアクセス権及びリソース操作実行権の認可を判定するポリシを格納する。

リソース及び操作管理テーブル１４３は、リソース利用アプリケーション１２０のアクセス対象リソース及び操作のリストを格納する。ポリシ判定部１４１は、ユーザがアクセス要求したリソース及び操作がリソース及び操作管理テーブル１４３に登録された正当なリソース及び操作かを判定し、ポリシに従ってアクセス権及び操作実行権の認可判定を行う。

アクセス認可部１４４は、ポリシ判定部１４１によって判定した結果、認証されたユーザ１０が、要求リソースへのアクセス権及び要求操作の実行権を有するとされた場合に、当該リソースへのアクセス及び操作を認可し、認可コードをリソース利用アプリケーション１２０に送信する。アクセスが認可されなかった場合は、アクセス認可部１４４は、非認可メッセージ（エラーコード）を送信する。

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

リソース例Ａ１５１は、例えばデータストレージのボリュームであり、リソース例Ｂ１５２は、例えばデータストレージのファイルディレクトリである。リソース例Ｃ１５３は、例えばコンピュートのＶＭ（仮想マシン）であり、リソース例Ｄ１５４は、例えばコンピュートのＤｏｃｋｅｒコンテナである。リソース例Ｅ１５５は、例えばネットワークリソースのドメインであり、リソース例Ｆ１５６は、例えばネットワークリソースのポートである。

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

上述のように、ユーザ１０は、ユーザ端末１００を利用して、リソースアクセスのためのコマンドを送信する。図３は、ユーザ端末１００のコマンド発行部１０２が発行するリソースアクセスコマンドの例を示す。図３は、コマンドの項目３１１及びそれらの指定例３１２を示す。このコマンドに応じて、リソースアクセス実行部１２３がリソースサーバ１５０にリソースアクセスコマンドを発行する。リソースアクセスコマンドは、対象のリソース、リソースに対する操作、及び操作におけるパラメータ等を指定する。

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

アクセス対象のリソースＵＲＩ（Ｕｎｉｖｅｒｓａｌ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）３０１は、リソース及びその格納場所を同定する。リソースＵＲＩ３０１で指定したリソース（ストレージボリュームの場所）に対し、ストレージリソースアクセスコマンドは、ボリュームを作成する操作３０２を定義する。

操作３０２のために指定されるパラメータは、ボリュームを作成するストレージプールＩＤ３０３、作成するボリューム数３０４、作成するボリュームサイズ３０５、作成するボリュームの形式３０６を含む。操作３０２例は、他にボリューム削除、ボリュームサイズ変更、ボリューム情報取得等を含む。ボリュームタイプを示すパラメータ３０６の例は、通常ボリューム（データ読み書き用）、バックアップ用ボリューム等を含む。

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

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

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

図４は、ユーザ認証部１３２がユーザ認証において利用することができる認証タイプの例を示す。図４は、認証タイプ３３１及びそれらの概要３３２を示す。認証タイプの例として、パスワード認証３２１、ワンタイムパスワード認証３２２、指紋認証３２３、顔認証３２４及び静脈認証３２５を示す。

パスワード認証３２１は、ユーザ１０が入力したパスワードを、認証基盤１３０のユーザ管理テーブル１３１の情報と照合する。ワンタイムパスワード認証３２２は、ユーザ端末１００と認証基盤１３０のそれぞれで、ワンタイムパスワードを生成し、ユーザ１０が入力したパスワードを双方で照合する。

指紋認証３２３は、ユーザ端末１００等に接続した指紋センサを用いてユーザ１０の指紋に基づくデータを、ユーザ管理テーブル１３１の登録データと照合する。顔認証３２４は、ユーザ端末１００等に接続したカメラ等を用いて取得したユーザ１０の顔画像に基づくデータを、ユーザ管理テーブル１３１の登録データと照合する。静脈認証３２５は、ユーザ端末１００等に接続した赤外線センサ等を用いて取得したユーザ１０の静脈パターンに基づくデータを、ユーザ管理テーブル１３１の登録データと照合する。

ユーザ端末１００のアクセス状態取得部１０３は、ユーザのアクセスの状態を示す種々の情報を取得する。図５は、アクセス状態取得部１０３が取得する情報の例を示す。図５は、情報の種別３５１、並びに、種別３５１それぞれの取得手段３５２及び取得状態例３５３を示す。

図５が示すアクセス状態情報の例は、ネットワーク情報３４１、デバイス情報３４２、体勢及び動態情報３４３、環境情報３４４及びカスタム情報３４５を含む。ネットワーク情報３４１は、ユーザ端末１００がアクセスするネットワークに関する情報を示す。例えば、ネットワークドメイン（ＷＡＮかＬＡＮか等）、ネットワークセキュリティ（公共ネットワークからのアクセスか、ＶＰＮ（Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）を介しているか、ファイアウォールが設定されているか等）、ネットワークを介したアタック検知（接続ネットワークに不審なアタックの兆候を示すパケットが無いか等）についての情報を含む。ネットワーク情報３４１は、ユーザ端末１００のＯＳ又は他のプログラムが持つネットワーク管理機能がネットワークを管理する際に使用する情報に基づいた、既存の方法を用いて取得することができる。

デバイス情報３４２は、ユーザ端末１００の種類につての情報を示す。例えば、固定端末（有線ネットワークに接続している等）、移動端末（無線ネットワークに接続している等）、又は公共端末（公共ネットワークに接続されている等）等を示す。デバイス情報３４２は、例えば、ユーザ端末１００に割り当てられた固有ＩＤ（マシンアドレス、電話番号、端末種別識別番号等）を、予め格納されている端末種別情報と照合する既存の方法を用いて取得することができる。

体勢及び動態情報３４３は、ユーザ１０の体勢及び動態についての情報を示す。体勢及び動態情報３４３が示す体勢及び動態は、例えば、移動、静止、歩行、座位、又は乗り物移動を含む。体勢及び動態情報３４３は、状態取得デバイス１１０、例えば、ユーザ端末１００に接続されている又は内蔵されている加速度センサその他の種々センサにより取得したデータに基づいて判定することができる。

環境情報３４４は、ユーザ１０が存在する環境についての情報を示す。環境情報３４４は、例えば、場所、建物、階数などのユーザ１０が存在する位置の情報の他、ユーザが屋内又は屋外のいずれに存在するか、周囲の人の有無等を示す。ユーザの位置情報は、状態取得デバイス１１０、例えば、ユーザ端末１００に接続されている又は内蔵されているＧＰＳや高度センサを用いて取得したデータに基づいて判定することができる。

屋内外又は周囲の人の有無は、状態取得デバイス１１０、例えば、ユーザ端末１００に接続されている又は内蔵されているマイク、カメラその他各種センサを用いて取得したデータに基づいて判定することができる。屋内外は、位置情報からも判定可能である。

カスタム情報３４６は、ユーザ１０によって設定された情報である。例えば、作業中に部外者が近傍に存在していることや、一時的にユーザ端末１００を離れている等、外部要因等によりセキュリティ観点でユーザ状態が変化した際に、ユーザ１０が、状態を、ユーザ端末１００から入力する。

図５に示す例において、体勢及び動態情報３４３及び環境情報３４４は、ユーザ状態情報に含まれる。また、図５が示すカスタム情報３４５の例も、ユーザ状態情報に含まれる。ネットワーク情報３４１及びデバイス情報３４２は、ユーザの属性情報に含まれる。ユーザの役割情報及びユーザ状態情報以外の情報を、ユーザ属性情報に含めることができる。なお、図５はユーザ状態の例を示すものであって、これらの一部のみが取得されてもよく、これらと異なる状態の情報が取得されてもよい。

上述のように、ユーザ状態は、状態取得デバイス１１０により取得されたデータに基づき判定することができる。図６は、ユーザ状態を判定するために使用できる状態取得デバイス、取得データ及び取得データからユーザ状態を判定する方法、の例を示す。図６は、判定方法が対象とするデータを取得するデバイス３７１、取得されるデータ３７２及び具体的な判定の方法３５３を示す。

カメラを使用した状態判定方法３６１は、カメラ（イメージセンサ）によってユーザ１０及びその周囲の画像を取得する。方法３６１は、ユーザの画像解析により、ユーザ１０の動態や体勢を判定する。また、周囲画像のパターン照合により、場所（屋内又は屋外、通常勤務場所、組織外等）を判定する。

マイクを使用した状態判定方法３６２は、マイクによってユーザ１０の周囲音を収集する。方法３６２は、周囲音のノイズ照合（音声、空調音等）により、ユーザ１０がいる場所、例えば、データセンタ内、居室、公共エリア、工場等を判定する。

加速度センサを使用した状態判定方法３６３は、加速度センサによって、ユーザ端末１００及びそれを保持するユーザ１０の加速度を取得する。方法３６３は、加速度変動からユーザ１０の歩行、静止、電車移動等を判定する。

温度及び湿度センサを使用した状態判定方法３６４は、温度及び湿度センサによって、ユーザ１０の周囲の温度及び湿度を取得する。方法３６４は、温度・湿度およびその変動から屋内・屋外等を判定する。照度センサを使用した状態判定方法３６５は、照度センサによって、ユーザ１０の周囲の明るさのデータを取得する。方法３６５は、明るさ及びその変動から屋内・屋外等を判定する。

ＧＰＳを使用した状態判定方法３６６は、ＧＰＳによって、ユーザ１０の位置（緯度経度）を取得する。方法３６６は、経緯度を地図と照合することにより、場所を判定する。高度センサを使用した状態判定方法３６７は、高度センサによって、ユーザ１０の位置（高度）を取得する。方法３６７は、ＧＰＳによる場所の情報と、高度及びその変動、周辺の気圧情報等から、ユーザ１０が存在する建物の階を判定する。

上述のように、アクセス状態取得部１０３は、種々デバイスを用いて取得したデータに対し、取得方法に示したような公知の解析方法を適用することによって、図５のアクセス状態の「取得状態例」に示したようなユーザ状態を取得（判定）する。ユーザ状態は、ユーザの体勢、動態、位置、周囲の環境を含む。

ユーザ状態の判定方法は、センサ等からのデータの組み合わせに対し、ヒューリスティックな手法に基づいて生成したルールに基づいてもよい。他の例は、ＡＩ技術を利用してもよい。例えば、実際にユーザがリソースアクセスした際の状態を教師とし、その時にセンサ等で取得したデータを学習データに用いて、機械学習や回帰分析等の手法により、判定モデルを生成してもよい。

上述のように、認可基盤１４０のアクセス条件判定部１４５は、ユーザ端末１００から送信されたアクセス状態情報に基づいて、リソースアクセス時の条件（アクセス条件）を判定する。図７は、アクセス条件判定方法の例を示す。図７に示す例は、予め設定されてる判定ルールに従って、ユーザのアクセス状態からアクセス条件を判定する。

アクセス条件判定部１４５は、図５及び６を参照して説明したような状態情報に基づいて、アクセス条件を判定する。具体的には、ネットワークの状態、端末の状態、ユーザ状態（ユーザ自身及びその環境の状態を含む）、及びカスタム状態を含むことができる。

図７は、三つの判定ルール３４１から３４３を例として示し、アクセス状態から判定されるユーザの作業３９１、判定に用いる状態３９２、判定ルールの具体的内容３９３及び判定結果のアクセス条件３９４を示す。

判定ルール３８１は、ユーザが静止し、デスクトップ端末が使用され、ユーザ端末が有線ＬＡＮに接続し、かつユーザデータセンタがある建物内にいるとき、データセンタ内の管理端末作業であると判定する。アクセス条件は、「Ｕｓｅｒ＿ｃｏｎｄｉｔｉｏｎ＝ＤＣ＿Ｄｅｓｋｔｏｐ＿Ｌｏｃａｌ」と表される。

判定ルール３８２は、ユーザが歩行し、タブレット端末が使用され、ユーザ端末が無線ＬＡＮに接続し、かつユーザデータセンタがある建物内にいるとき、データセンタ内の移動作業であると判定する。アクセス条件は、「Ｕｓｅｒ＿ｃｏｎｄｉｔｉｏｎ＝ＤＣ＿Ｔａｂｌｅｔ＿ＷｉＦｉ」と表される。

判定ルール３８３は、ユーザが歩行し、スマートフォンが使用され、ユーザ端末が携帯網に接続し、かつ音声帯域ノイズレベルが６０ｄＢ以上であるとき、公共エリアの移動作業であると判定する。アクセス条件は、「Ｕｓｅｒ＿ｃｏｎｄｉｔｉｏｎ＝Ｐｕｂｌｉｃ＿Ｓｍａｒｔｐｈｏｎｅ＿Ｃｅｌｌｅｒ」と表される。

判定ルールは、ユーザによるアクセス状態の組み合わせに対し、ヒューリスティックな手法に基づいて生成することができる。または、実際にユーザがリソースアクセスした際のアクセス条件を教師とし、その時のユーザの状態の学習データとして、機械学習や回帰分析等の手法を行うことにより、判定モデルを生成してもよい。

上述のように、ポリシ判定部１４１は、ユーザがアクセス要求したリソース及び操作がリソース及び操作管理テーブル１４３に登録された正当なリソース及び操作かを判定し、ポリシに従ってアクセス権及び操作実行権の認可判定を行う。図８は、ユーザのリソースアクセス条件を用いたポリシの例を示す。図８は、例として、二つのポリシ４０１及び４０２を示す。各ポリシは、項目４１１及び項目４１１それぞれの指定内容４１２を示す。

ポリシ１（４０１）は、説明項目４５７に示すように、ストレージボリューム操作は、ストレージ管理者（条件１）、かつ管理グループ所属（条件２）、かつ公共エリア内のスマートフォンから携帯網を介してアクセスしていること（条件３）を必要とする。ポリシ１（４０１）は、判定対象リソースＵＲＩ４５１、判定対象操作４５２、認可条件４５３から４５５、及び認可判定の要求条件４５６を示す。

つまり、ポリシ１（４０１）は、指定したリソース４５１に対し、三つの条件４５３から４５５の全てが満たされる場合に、指定したコマンド（Ｇｅｔ Ｖｏｌｕｍｅ Ｉｎｆｏｒｍａｔｉｏｎ）４５２を認可する。三つの条件は、以下の通りである。条件１（４５３）は、ユーザの役割（ｒｏｌｅ）がｃｕｓｔｏｍｅｒであることである。条件２（４５４）は、ユーザがｅｎｇｉｎｅｅｒｉｎｇグループに属していることである。条件３（４５５）は、ユーザのアクセス条件が「Ｐｕｂｌｉｃ＿Ｓｍａｒｔｐｈｏｎｅ＿ＣｅｌｌｅｒまたはＤＣ＿Ｄｅｓｋｔｏｐ＿Ｌｏｃａｌ」（ユーザがデータセンタ内のデスクトップ端末から有線ＬＡＮを介して、又は公共エリア内のスマートフォンから携帯網を介してアクセスしている）であることである。

ポリシ２（４０２）は、説明項目４６７に示すように、ストレージボリューム操作は、ストレージ管理者（条件１）、かつ管理グループ所属（条件２）、かつデータセンタ内のデスクトップ端末から有線ＬＡＮを介してアクセスしていることを必要とする。ポリシ２（４０２）は、判定対象リソースＵＲＩ４６１、判定対象操作４６２、認可条件４６３から４６５、及び認可判定の要求条件４６６を示す。

つまり、ポリシ２（４０２）は、指定したリソース４６１に対し、三つの条件４６３から４６５の全てが満たされる場合に、指定したコマンド（Ｃｒｅａｔｅ Ｖｏｌｕｍｅ）４６２を認可する。三つの条件は、以下の通りである。条件１（４６３）は、ユーザの役割（ｒｏｌｅ）がａｄｍｉｎｉｓｔｒａｔｏｒであることである。条件２（４６４）は、ユーザがｍａｎａｇｅｍｅｎｔグループに属していることである。条件３（４６５）は、ユーザのアクセス条件が「ＤＣ＿Ｄｅｓｋｔｏｐ＿Ｌｏｃａｌ」（ユーザがデータセンタのデスクトップ端末から有線ＬＡＮ接続している）であることである。

例えば、あるユーザに、ｃｕｓｔｏｍｅｒとａｄｍｉｎｉｓｔｒａｔｏｒの役割が割り当てられており、同ユーザがｅｎｇｉｎｅｅｒ とｍａｎａｇｅｍｅｎｔの両方のグループに属しているとする。該ユーザのアクセス条件が、データセンタ内デスクトップ端末からの有線ＬＡＮ接続（ＤＣ＿Ｄｅｓｋｔｏｐ＿Ｌｏｃａｌ）であるとする。

リソースＵＲＩ（ｈｔｔｐ：／／ｓａｍｐｌｅ．ｄｏｍａｉｎ．ｃｏｍ／ｓｔｏｒａｇｅ／ｖｏｌｕｍｅｓ）に対し、ポリシ１（４０２）が認可対象とするコマンド（Ｇｅｔ Ｖｏｌｕｍｅ Ｉｎｆｏｒｍａｔｉｏｎ）の実行を要求した場合、該ユーザに対し、コマンドの実行は認可される。同様に、ポリシ２が認可対象とするコマンド（Ｃｒｅａｔｅ Ｖｏｌｕｍｅ）の実行を要求した場合、該ユーザに対し、コマンドの実行は認可される。

他の例として、該ユーザのアクセス条件が、公共エリアのスマートフォンからの携帯網接続（Ｐｕｂｌｉｃ＿Ｓｍａｒｔｐｈｏｎｅ＿Ｃｅｌｌｅｒ）であるとする。ポリシ１（４０１）が認可対象とするコマンド（Ｇｅｔ Ｖｏｌｕｍｅ Ｉｎｆｏｒｍａｔｉｏｎ） の実行を要求した際は認可される。しかし、ポリシ２（４０２）が認可対象とするコマンド（Ｃｒｅａｔｅ Ｖｏｌｕｍｅ）の実行を要求した際は、アクセス条件が判定要件を満たさないため認可されない。

このように、ユーザの役割及び所属グループに加え、アクセス時の条件をポリシ判定に用いる。これにより、同一ユーザが複数の役割を持ち、かつ／または複数のグループに属して、異なるリソースアクセスおよびコマンド実行を要求した場合に、ユーザが正当なアクセス条件の基で要求した時にのみ認可することが可能となる。なお、図８に示すポリシは一例であって、例示された条件の一部のみ又は他の条件が要求されてもよい。例えば、ユーザの役割及び所属グループは条件に含まれなくてもよい。

図９は、ユーザアクセス条件に基づくリソースアクセス認証及び認可システムの処理フローの例を示す。まず、ユーザ端末１００は、ユーザ１０からの指示に応じてリソース利用アプリケーション１２０にアクセスする（Ｓ１０２）。ユーザ端末１００のコマンド発行部１０２は、ユーザ入力に応じて、特定のリソースへのアクセス及び操作の実行を、リソース利用アプリケーション１２０に要求する（Ｓ１０３）。

リソース利用アプリケーション１２０は、ユーザ端末１００から、ユーザの識別情報と、リソースアクセスコマンドを取得する（Ｓ１０４）。認証要否判定部１２１は、認証済みユーザを示す管理情報を参照して、当該ユーザ１０のユーザ認証が済んでいるか判定する（Ｓ１０５）。

ユーザ認証が済んでいない場合（Ｓ１０５：ＮＯ）、認証要否判定部１２１は、認証基盤１３０にユーザ認証を要求する（Ｓ１０６）。認証基盤１３０のユーザ認証部１３２は、ユーザ認証に必要な情報を認証要否判定部１２１から取得し、ユーザ管理テーブル１３１を参照して、ユーザ認証を実行する（Ｓ１０７）。

ユーザが正当なユーザではない場合（Ｓ１０８：ＮＯ）、認証要否判定部１２１はその判定結果をユーザ認証部１３２から取得し、エラーメッセージをユーザ端末１００に送信する。ユーザ端末１００は、そのエラーメッセージをユーザ１０に提示する（Ｓ１０９）。エラー処理としては、アプリケーションを終了するか、ユーザからのアプリケーションへのアクセスを遮断しても良いし、ユーザに新しいパスワードの入力を促す等により、認証処理を再実行してもよい。

ユーザが正当なユーザである場合（Ｓ１０８：ＹＥＳ）、認証要否判定部１２１は、ユーザ認証成功通知をリソース利用アプリケーション１２０に通知する（Ｓ１１１）。認証要否判定部１２１は、ユーザの情報（属性、役割、グループ等）を認可基盤１４０に送付する（Ｓ１１２）。

ステップＳ１１２の後、又は、ステップＳ１０５においてユーザ認証が済んでいる場合（Ｓ１０５：ＹＥＳ）、ユーザ端末１００のアクセス状態取得部１０３は、リソース利用アプリケーション１２０を介して、状態取得デバイス１１０及び他のリソースから得られたアクセス状態の情報を、認可基盤１４０に送信する（Ｓ１１３）。アクセス状態は、例えば、ユーザが正当と認証されたとの通知をユーザ端末１００が受信したことに応答して、送信されてよい。

上述のように、ユーザ認証が一度実行されると、その後のユーザ認証は省略される。これにより、リソースへのアクセスの度に認証を行う必要がなく、一度の認証で複数のリソースへのアクセスに認可を実行できる。なお、ユーザ認証をアクセス要求毎に実行してもよい。なお、認証は、ＯｐｅｎＩＤ ＣｏｎｎｅｃｔやＳＡＭＬ等の認証・認可プロトコルに則って実行することとしてよい。これらのプロトコルでは、認証成功時にトークンと呼ばれる識別情報が発行され、認証済みのユーザかどうかの判定は、トークンの有効性判定に基づいて行われる。

次に、認可基盤１４０のアクセス条件判定部１４５は、受信したアクセス状態の情報から、アクセス条件を判定する（Ｓ１１４）。認可基盤１４０のポリシ判定部１４１は、ユーザ情報、リソースアクセスコマンド、及びアクセス条件を取得する（Ｓ１１５）。ポリシ判定部１４１は、ユーザ１０によるリソースアクセスコマンド実行の認可を、ユーザ情報及びアクセス条件に基づいて判定する（Ｓ１１６）。

なお、１回の認証に対し、複数のリソースアクセス要求を、時間を置かず実行する場合等、複数のリソースアクセス要求発生時のアクセス条件が、変わらないと判定できる場合においては、２回目以降のリソースアクセス要求に対する認可判定フロー（Ｓ１１３～Ｓ１１５）において、アクセス条件判定（Ｓ１１４）を省略し、１回目に取得したアクセス条件を２回目以降に用いてもよい。

判定結果が、コマンド実行が不当であることを示す場合（Ｓ１１７：ＮＯ）、アクセス認可部１４４は、リソース利用アプリケーション１２０を介して、エラーメッセージをユーザ端末１００に送信し、ユーザ端末１００はそのエラーメッセージをユーザ１０に提示する（Ｓ１１８）。エラー処理として、アプリケーションを終了するか、ユーザからのアプリケーションへのアクセスを遮断しても良いし、ユーザに新しいリソースアクセスコマンドの入力を促す等により、認可処理を再実行してもよい。

判定結果が、コマンド実行が正当であることを示す場合（Ｓ１１７：ＹＥＳ）、アクセス認可部１４４は、コマンド実行の認可通知を、リソース利用アプリケーション１２０のアクセス権判定部１２２に送信する。アクセス権判定部１２２は、認可通知に応答して、ユーザ１０に、リソースへのアクセス権および操作の実行権を付与する（Ｓ１２０）。

リソースアクセス実行部１２３は、リソースサーバ１５０を介してリソースにアクセスし、操作を実行する（Ｓ１２１）。また、リソース利用処理実行部１２４は、リソースアクセスに基づく処理を実行する（Ｓ１２２）。処理完了の通知が、リソース利用アプリケーション１２０からユーザ端末１００に送信される。

上記構成例は、ユーザによるリソース操作の許否を判定する。以下に説明する構成例は、リソースの操作に加えて、操作のパラメータについて許否を判定する。これにより、ストレージリソースの操作のように、制御パラメータ（サイズ、ＲＷ権限等）も指定する操作に対しても、制御パラメータを含めた細かなアクセス制御を行うことができる。

図１０は、認証及び認可システムにおいて、リソース操作パラメータの認可を行う場合の構成例を示す。以下において、図２に示す構成例との相違点を主に説明する。図１０に示す構成例は、図２に示すリソースアクセス認証及び認可システムに対して、操作パラメータを認可処理に対象とする。システムは、ポリシ判定部１４１及びリソース及び操作管理テーブル１４３に代えて、ポリシ判定部７０１及びリソース、操作及びパラメータ管理テーブル７０２を含む。

ポリシ判定部７０１は、ユーザ認証部１３２で認証されたユーザ１０の情報、アクセス要求されたたリソース、リソースへの操作、及び操作のパラメータの情報を、認証基盤１３０及びリソース利用アプリケーション１２０から受け取る。ポリシ判定部１４１は、さらに、アクセス条件判定部１４５によって判定したアクセス条件を取得する。ポリシ判定部１４１は、それらをポリシ管理テーブル１４２に予め設定されたリソースアクセスポリシと照合して、該ユーザ１０が要求されたリソースへのアクセス権、リソースに対する操作、及び操作時に指定するパラメータの実行権を有するか判定する。

リソース、操作及びパラメータ管理テーブル７０２は、リソース利用アプリケーション１２０のアクセス対象リソースに加え、リソースに対する操作、及び操作時のパラメータの組み合わせのリストを格納する。ポリシ判定部７０１は、ユーザがアクセス要求したリソース、操作及びパラメータがリソース、操作及びパラメータ管理テーブル７０２に登録された正当なリソース、操作及びパラメータかを判定し、ポリシに従ってアクセス権及び操作実行権及びパラメータ設定権の認可判定を行う。

図１１は、リソース操作パラメータの認可判定を行うポリシの例を示す。ポリシ３（４０３）は、説明項目４７８に示すように、ユーザがストレージ管理者であり（条件１）かつ管理グループに所属し（条件２）、さらに、データセンタ内のデスクトップ端末から有線ＬＡＮを介してアクセスしているとき、Ｐｏｏｌ＿ＩＤは１～６まで選択可能であることを定義する。

つまり、ポリシ３（４０３）は、三つの条件４７４から４７６の全てが満たされる場合に、指定したリソース４７１に対し、指定したコマンド（Ｃｒｅａｔｅ Ｖｏｌｕｍｅ）４７２において、指定するパラメータ（Ｐｏｏｌ＿ＩＤ＝１，２，３，４，５，６）４７３の設定を認可する。

三つの条件は、以下の通りである。条件１（４７４）は、ユーザの役割（ｒｏｌｅ）がａｄｍｉｎｉｓｔｒａｔｏｒであることである。条件２（４７５）は、ユーザがｍａｎａｇｅｍｅｎｔグループに属していることである。条件３（４７６）は、ユーザのアクセス条件が「ＤＣ＿Ｄｅｓｋｔｏｐ＿Ｌｏｃａｌ」（ユーザがデータセンタ内のデスクトップ端末から有線ＬＡＮを介してアクセスしている）であることである。

ポリシ４（４０４）は、説明項目４８８に示すように、ストレージ管理者（条件１）、かつ管理グループ所属（条件２）、かつデータセンタ内のタブレット端末から無線ＬＡＮを介してアクセスしているとき、Ｐｏｏｌ＿ＩＤは１，２，３が選択可能であることを定義する。

つまり、ポリシ４（４０４）は、三つの条件４８４から４８６の全てが満たされる場合に、指定したリソース４８１に対し、指定したコマンド（Ｃｒｅａｔｅ Ｖｏｌｕｍｅ）４８２において、指定するパラメータ（Ｐｏｏｌ＿ＩＤ＝１，２，３）４８３の設定を認可する。

三つの条件は、以下の通りである。条件１（４８４）は、ユーザの役割（ｒｏｌｅ）がａｄｍｉｎｉｓｔｒａｔｏｒであることである。条件２（４８５）は、ユーザがｍａｎａｇｅｍｅｎｔグループに属していることである。条件３（４８６）は、ユーザのアクセス条件が「ＤＣ＿Ｔａｂｌｅｔ＿ＷｉＦｉ」（ユーザがデータセンタのタブレット端末から無線ＬＡＮ接続している）であることである。

例えば、あるユーザに、ａｄｍｉｎｉｓｔｒａｔｏｒの役割が割り当てられており、同ユーザがｍａｎａｇｅｍｅｎｔグループに属し、該ユーザのアクセス条件が、データセンタ内でデスクトップ端末から有線ＬＡＮ接続でアクセスしているとする。このとき、ボリュームを作成可能なストレージプールは、ＩＤが１から６のストレージプールから選択可能である。

一方、同ユーザが、データセンタ内でタブレット端末から無線ＬＡＮ接続でアクセスしている場合は、ボリュームを作成可能なストレージプールは、ＩＤが１から３のストレージプールのみから選択可能である。

ストレージプールが、種別によってセキュリティレベルが異なる場合、データセンタ内のデスクトップ端末から有線ＬＡＮ接続であれば、高いセキュリティレベルを要求するＩＤ（４，５，６）にアクセスしてボリュームを作成することが可能である。しかし、同じデータセンタ内でも、タブレット端末を用いて移動しながらメンテナンス作業を行っており、通信に無線ＬＡＮを使用している場合では、通信傍受の危険性が有線接続の場合より高い。そのため、よりセキュリティレベルの低いストレージプール（ＩＤ＝１，２，３）へのアクセス、及びボリューム作成作業のみが認可される。

このように、本例は、同一ユーザであっても、リソースアクセス時の条件によって、指定されたパラメータでのリソース操作実行権をポリシによって制御できる。これにより、ストレージのように細かいパラメータ設定が必要なリソースに対するアクセス及び操作に対し、きめ細かい管理を行うことが可能になる。

アクセス制御の対象となり得るパラメータは、上記プールＩＤの他、パリティグループＩＤ、ドライブロケーションＩＤ、ＬＵＮ ＩＤ、ボリューム容量、ポートタイプ（Ｆｉｂｒｅ， ＳＣＳＩ等）、ポートＩＤ、サイズ等を含むことができる。ストレージシステムと異なるシステムでは、これらと異なる任意パラメータが指定され得る。

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

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

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

１０ ユーザ
１００ ユーザ端末
１０１ ユーザインタフェース
１０２ コマンド発行部
１０３ アクセス状態取得部
１１０ 状態取得デバイス
１２０ リソース利用アプリケーション
１２１ 認証要否判定部
１２２ アクセス権判定部
１２３ リソースアクセス実行部
１２４ リソース利用処理実行部
１３０ 認証基盤
１３１ ユーザ管理テーブル
１３２ ユーザ認証部
１４０ 認可基盤
１４１ ポリシ判定部
１４２ ポリシ管理テーブル
１４３ リソース及び操作管理テーブル
１４４ アクセス認可部
１４５ アクセス条件判定部
１５０ リソースサーバ
２１０ ホストサーバ
２２０ 管理サーバ
２３０ ストレージシステム
２３１ コントローラ
２３２ ホストインタフェース
２３３ 管理インタフェース
２３４ ドライブインタフェース
２３５ プロセッサ
２３６ メモリ
２３７ ドライブボックス
２３８、２３９ 記憶ドライブ
２５０ ネットワーク
７０１ ポリシ判定部
７０２ リソース、操作及びパラメータ管理テーブル

Claims (8)

1. ユーザのリソースへのアクセスを制御するシステムであって、
   １以上のプロセッサと、
   リソースの操作に対する条件を規定するポリシ情報を格納する、１以上の記憶装置と、を含み、
   前記ポリシ情報は、複数のリソースの操作それぞれに対する条件を規定し、
   前記複数のリソースの操作のそれぞれに対する条件は、ユーザのアクセス時の条件、及び、前記ユーザの役割かつ／またはグループを含み、
   前記１以上のプロセッサは、
   ユーザ端末から、第１ユーザによる第１リソースに対する所定操作を示す第１アクセス要求を取得し、前記第１ユーザは、複数の役割を持ち、かつ／または複数のグループに所属し、
   前記ユーザ端末から、前記第１ユーザにより入力された前記第１ユーザについての情報を取得し、
   前記ユーザ端末から、前記第１ユーザの現在の状態を示すユーザ状態情報を取得し、
   前記第１ユーザについての情報に基づき前記第１ユーザのユーザ認証を実行し、
   前記第１ユーザについての情報に基づき、前記第１ユーザの複数の役割、かつ／または複数のグループを判定し、
   前記ユーザ状態情報に基づき、前記第１ユーザによるアクセス時の条件を判定し、
   前記第１ユーザによるアクセス時の条件が前記第１リソースに対する前記所定操作に対して前記ポリシ情報が規定するアクセス時の条件を満たし、かつ、前記ポリシ情報が規定する前記第１リソースに対する前記所定操作のユーザの役割、かつ／またはグループが、前記第１ユーザの複数の役割、かつ／または複数のグループに含まれる、ことを条件として、前記第１アクセス要求を許可し、
   前記第１アクセス要求の後の前記第１ユーザからのアクセス要求の許否を、前記第１ユーザのユーザ認証を行うことなく判定する、システム。
2. 請求項１に記載のシステムであって、
   前記ユーザ状態情報は、前記第１ユーザの体勢及び動態の少なくとも一つを示す、システム。
3. 請求項１に記載のシステムであって、
   前記１以上のプロセッサは、
   前記ユーザ端末から前記ユーザ端末の情報を取得し、
   前記ユーザ状態情報及び前記ユーザ端末の情報に基づき、前記第１ユーザによるアクセス時の条件を判定する、システム。
4. 請求項１に記載のシステムであって、
   前記１以上のプロセッサは、
   前記ユーザ端末が接続するネットワークの情報を取得し、
   前記ユーザ状態情報及び前記ネットワークの情報に基づき、前記第１ユーザによるアクセス時の条件を判定する、システム。
5. 請求項１に記載のシステムであって、
   前記第１アクセス要求は、前記所定操作の指定パラメータをさらに含み、
   前記ポリシ情報は、前記第１リソースの前記所定操作が指定可能なパラメータを示す、システム。
6. 請求項１に記載のシステムであって、
   前記リソースは、ストレージシステムのデータ格納領域である、システム。
7. 請求項１に記載のシステムであって、
   前記ユーザ端末は、センサが測定したデータに基づき前記ユーザ状態情報を生成する、システム。
8. システムが、ユーザのリソースへのアクセスを制御する方法であって、
   前記システムは、リソースの操作に対する条件を規定するポリシ情報を格納し、
   前記ポリシ情報は、複数のリソースの操作それぞれに対する条件を規定し、
   前記複数のリソースの操作のそれぞれに対する条件は、ユーザのアクセス時の条件、及び、前記ユーザの役割かつ／またはグループを含み、
   前記方法は、
   前記システムが、ユーザ端末から、第１ユーザによる第１リソースに対する所定操作を示す第１アクセス要求を取得し、前記第１ユーザは、複数の役割を持ち、かつ／または複数のグループに所属し、
   前記システムが、前記ユーザ端末から、前記第１ユーザにより入力された前記第１ユーザについての情報を取得し、
   前記システムが、前記ユーザ端末から、前記第１ユーザの現在の状態を示すユーザ状態情報を取得し、
   前記システムが、前記第１ユーザについての情報に基づき前記第１ユーザのユーザ認証を実行し、
   前記システムが、前記第１ユーザについての情報に基づき、前記第１ユーザの複数の役割、かつ／または複数のグループを判定し、
   前記システムが、前記ユーザ状態情報に基づき、前記第１ユーザによるアクセス時の条件を判定し、
   前記システムが、前記第１ユーザによるアクセス時の条件が前記第１リソースに対する前記所定操作に対して前記ポリシ情報が規定するアクセス時の条件を満たし、かつ、前記ポリシ情報が規定する前記第１リソースに対する前記所定操作のユーザの役割、かつ／またはグループが、前記第１ユーザの複数の役割、かつ／または複数のグループに含まれる、ことを条件として、前記第１アクセス要求を許可し、
   前記システムが、前記第１アクセス要求の後の前記第１ユーザからのアクセス要求の許否を、前記第１ユーザのユーザ認証を行うことなく判定する、方法。

Images