JP5930847B2 - サーバーシステムおよび制御方法およびプログラム - Google Patents

Description

本発明は、マルチテナントサービスにおいて、実行者と異なるテナントのリソースに対するアクセス制御方法に関する。

従来、Ｗｅｂアプリケーションは、サービス提供先の企業や組織ごとに専用のサーバーを用意して提供する形態が主であった。しかしながら、提供先ごとに専用のサーバーを用意する形態はコスト効率が低下する。そのため、近年、共有のサーバー上に展開した同一のＷｅｂアプリケーションを複数の企業や組織に提供する“マルチテナントサービス”という形態が注目されている。ここで“テナント”とは、従来の専用サーバーを用いてサービスを提供していた企業や組織の単位を意味する。

テナントごとに専用のサーバーを用いる方法と比較して、マルチテナントサービスはコスト面で優れているがセキュリティ面で課題がある。従来の形態では、テナントが所有するデータがテナントごとの専用のサーバーで管理されており、物理的に分離されているためデータ漏洩のリスクは低い。しかしながら、マルチテナントサービスは複数テナントのデータを共有のサーバーで管理するため、物理的に分離されておらず、データ漏洩のリスクが高くなる。そこで、マルチテナントサービスでは、テナント間でのデータ漏洩を防ぐために、論理的にデータを分離する仕組みが必須である。

例えば、先行技術では、データを論理的に分離するためのキーとしてテナントＩＤを用いた方法が提案されている。このテナントＩＤを、ユーザーを識別するための属性であるユーザーＩＤと紐づけ、テナントが所有するデータにも同様にテナントＩＤを付与する方法によってマルチテナントサービスを実現している。より詳細には、ユーザー認証によってユーザーＩＤとともにテナントＩＤを特定し、データアクセス時に、同一のテナントＩＤが付与されたデータのみアクセスを許可するアクセス制御方法である。

特開２０１０−２６６５３号公報

マルチテナントサービスでは、テナント毎にデータを論理的に分離し、他テナントのデータにアクセスできないように制御することで、サービス全体のセキュリティを担保している。

しかしながら、マルチテナントサービスの運用において、特別に他テナントのデータへのアクセスが必要になる場合がある。

例えばサービス提供を開始する際に、他テナントのデータへのアクセスが発生する場合がある。新たな企業や組織がクラウドサービスの利用を開始する際には、クラウドサービス上にその顧客用のテナントが必要になるため、テナント作成権限を持つユーザーが新たなテナントを作成する。その際、テナント作成者の権限で、そのテナント内にテナント管理を行えるユーザーアカウントを作成する場合がある。

また、顧客にサービスを販売したユーザーが、その顧客のテナント内の一部のデータにアクセスする場合がある。クラウドサービスにおいてユーザーが有償のサービスを利用するためには、ユーザーはサービスの販売者と契約を結び、サービスのライセンスを購入する必要がある。その際、サービスの販売者が販売管理などの目的で、販売者が契約した顧客のテナントが、現在いくつのライセンスを利用しているかを確認する場合がある。

これまでのマルチテナント実現方法でも、他テナントのデータへのアクセスは、実行者に一時的に対象テナントへのアクセス権を付与したり、全てのテナントに対するアクセス権を持つスーパーユーザーを用意したりして実現はできる。しかし、このような方法では、他テナントのデータへのアクセス権を持つユーザーがテナントを越えて全ての処理を実行出来てしまい、セキュリティ上の問題となる。

例えば上記テナント作成の例では、サービス提供者がテナントおよびそのテナント内にユーザーアカウントを作成することは許されるが、サービス提供後にそのテナント内のユーザーを削除したりすることは許されない。

同様に上記ライセンス数取得の例では、サービスの販売者が、契約した顧客のテナントで利用されている総ライセンス数を取得することは許されるが、ユーザーの氏名や住所、誰にライセンスが紐付いているか、などの個人情報を取得することは許されない。

このように、他テナントのデータへのアクセスを許す場合には、テナントを越えて実行できる処理を制限する必要がある。しかしながら、これまでのマルチテナント実現方法でこのように処理に制限を付けるためには、ユーザー作成時や処理実行時などに、細かいアクセス権の制御が必要になり、アクセス権の管理が複雑になってしまう。

さらに、テナントを越えて実行できる処理は、その処理を実行するユーザーによる制御も必要となる。

例えばクラウドサービスを利用するユーザーを、クラウドサービスを運用するユーザー（運用者）と、サービスを販売するユーザー（販売者）、そしてサービスを利用するユーザー（顧客）に分類したとする。

ここで、運用者はサービスの運用を行うユーザーであり、システム管理者や開発者などが含まれる。運用者は販売者に対してサービス販売の委託を行い、販売者と販売契約を結んで販売者のテナントを作成する。そのため、販売テナント作成やシステム管理のために、販売テナントのデータにアクセスすることがある。

販売者はサービスの販売を行うユーザーであり、顧客と利用契約を結び、顧客のテナントを作成する。また、顧客に対して有償サービスの販売を行い、契約を結んだユーザーにライセンスの発行を行う。そのため、顧客テナントの作成や販売管理のために、顧客テナントのデータにアクセスすることがある。

ここで、販売者は顧客と契約を結んでいるため、顧客テナントのデータにアクセスすることが許されるが、その販売者と契約を結んでいる運用者は、顧客とは契約を結んでいないため、顧客テナントのデータへのアクセスは許されない。もし管理者が顧客テナントのデータにアクセスできてしまうと、それは顧客情報の漏えいとなってしまう。

このように、テナントを越えて実行できる処理は、処理内容の制限に加え、処理の実行者と処理対象による制限も行う必要がある。

本発明は、マルチテナントサービスにおいて、実行者と異なるテナントのデータへのアクセスをセキュアに実行する方法を提供することを目的としている。

上記目的を達成するために、本願発明は、マルチテナントサービスのアクセス制御サービスを提供するサーバーシステムであって、機能の実行を指示した実行者が所属するテナントと前記機能による処理対象のテナントが同一か否かを判定する第１判定手段と、前記第１判定手段により同一であると判定された場合、前記実行者に前記機能の実行を許可する許可手段と、前記第１判定手段により同一でないと判定された場合、前記機能が、前記実行者が所属するテナントと前記機能による処理対象のテナントが同一でない場合であっても処理可能であるか否かを判定する第２判定手段と、前記第２判定手段により、前記機能が、前記実行者が所属するテナントと前記機能による処理対象のテナントが同一でない場合であっても処理可能であると判定された場合、前記実行者が所属するテナントと前記処理対象のテナントとの関係が、前記機能の実行を許可する関係であるかを判定する第３判定手段とを有し、前記第３判定手段により、前記実行者が所属するテナントと前記処理対象のテナントとの関係が、前記機能の実行を許可する関係であると判定された場合、前記許可手段は、前記実行者に処理対象テナントに対して前記機能の実行権限を許可することを特徴とする。

本発明により、マルチテナントサービスにおいて、実行者が自身の所属するテナントと異なるテナントに対して処理を行うことができる。また、テナントを越えた処理をする際に、必要以上の操作や、必要以上の情報の取得を防ぐことができる。

システム構成図 各装置のハードウェア構成図 ログインサービスのソフトウェアモジュールの説明図 アクセス制御サービスのソフトウェアモジュールの説明図 サービスのソフトウェアモジュールの説明図 ユーザー情報のデータ構造の一例を示す図 リソース情報のデータ構造の一例を示す図 ＡＰＩ権限情報のデータ構造の一例を示す図 一般的なＷｅｂアプリケーションのアクセスシーケンス。 （Ａ）アクセス制御のフローチャート。 （Ｂ）リソースへのアクセス可否判定のフローチャート。 （Ｃ）ＡＰＩ実行権限判定のフローチャート。 ユーザー情報のデータの一例を示す図 リソース情報のデータの一例を示す図 ＡＰＩ権限情報のデータの一例を示す図 一例としてのＷｅｂアプリケーションの画面フロー図。 一例としてのＷｅｂアプリケーションのアクセスシーケンス。 ロール制御情報のデータの一例を示す図 テナント作成ＡＰＩ実行のフローチャート マスター管理者を用いた、ＡＰＩ実行権限判定のフローチャート ＡＰＩ実行時の権限判定フローチャート

以下、本発明を実施するための最良の形態について図面を用いて説明する。

図１は、本発明の実施例のシステム構成を示すブロック図である。

図中１０は、Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＷＡＮ１０）であり、本発明ではＷｏｒｌｄ Ｗｉｄｅ Ｗｅｂ（ＷＷＷ）システムが構築されている。図中１１は各構成要素を接続するＬｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＬＡＮ１１）である。

図中１２はＷＡＮ１０を介して各サービスに対してＷｅｂリクエストを発行する複数のクライアント１２Ａ、１２Ｂであり、より具体的にはＷＷＷシステムを利用するためのＷｅｂブラウザを備えたコンピュータである。なお、クライアント１２Ａおよび、クライアント１２Ｂは、不図示のファイアウォール装置により、ＷＡＮ１０に対するリクエスト以外の通信が遮断されている。

図中１３はＷＡＮ１０およびＬＡＮ１１を介して、クライアント１２からのＷｅｂリクエスト要求に応じて、ユーザーを認証するためのログイン画面を提示し、ユーザーからのログインリクエストを受け付けるログインサービス１３である。

図中１４はＬＡＮ１１を介して、ログインサービス１３および、一つないし複数のサービス１５からのアクセス許可リクエストを受け付けるアクセス制御サービス１４である。

図中１５はＷＡＮ１０およびＬＡＮ１１を介して、クライアント１２からのＷｅｂリクエスト要求に応じて、各種サービスを提供する一つないし複数のサービス１５Ａ、サービス１５Ｂである。

図中１６はＬＡＮ１１を介してアクセス制御サービス１４からのデータアクセス要求をうけつけるデータベースサービス１６である。データベースサービス１６は、一般的なＤＢＭＳ（ＤａｔａＢａｓｅ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）が構成されており、アクセス制御サービス１４からのデータアクセスクエリをうけつけ、該当するデータを応答する。

図２は、図１中のクライアント１２、ログインサービス１３、アクセス制御サービス１４、サービス１５、あるいはデータベースサービス１６のハードウェア構成を示すブロック図である。図中、２１は内部バスで接続される各デバイス（後述のＲＯＭ、ＲＡＭ他）を直接或いは間接的に制御し、本発明を実現するためのプログラムを実行するＣＰＵである。２２はＢＩＯＳが格納してあるＲＯＭである。２３はＣＰＵ２１のワーク領域として利用されたり、本発明を実現するためのソフトウェアモジュールをロードするための一時記憶として利用されたりするＲＡＭ（直接記憶装置）。２４は基本ソフトウェアであるＯＳやソフトウェアモジュールが記憶されているＨＤＤ（ハードディスクドライブ）、もしくはＳＳＤ（ソリッドステートドライブ）などの間接記憶装置。２５は入力装置であり不図示のキーボードやポインティングデバイスなどである。２６は出力装置でありディスプレイが接続される。２７はＷＡＮ１０ないしはＬＡＮ１１に接続するためのＩ／Ｆ（Ｉｎｔｅｒｆａｃｅ）であり、一つないしは複数備えている。

これらハードウェアでは、起動後ＣＰＵ２１によりＢＩＯＳが実行されＯＳがＨＤＤ２４からＲＡＭ２３に実行可能にロードされる。ＣＰＵ２１はＯＳの動作に従って後述する各種ソフトウェアモジュールをＨＤＤ２４からＲＡＭ２３に随時、実行可能にロードする。各種ソフトウェアモジュールは上記各デバイスの協調によりＣＰＵ２１によって実行され動作する。また、Ｉ／Ｆ２７はＬＡＮ１１に接続されており、ＯＳの動作に従ってＣＰＵ２１により制御され、各サーバーに格納されたサービス間のリクエストの送受信を実現している。また、Ｉ／Ｆ２７はＬＡＮ１１を経由してＷＡＮ１０に接続されており、ＯＳの動作に従ってＣＰＵ２１により制御され、ＷＷＷシステムにおける通信を実現している。

また、図中１のログインサービス１３、アクセス制御サービス１４、サービス１５、あるいはデータベースサービス１６は、一台、ないしは複数台の図２で示されたハードウェア構成のサーバーによって構成される。複数台のサーバーで構成する場合は、不図示のロードバランサー装置や、不図示のソフトウェアモジュールによって負荷分散構成、もしくは冗長化構成を採用する事ができる。

図３は、ログインサービス１３上で動作するソフトウェアモジュールの構成図である。なお各ソフトウェアモジュールは図２で示したＨＤＤ２４に記憶されており、前述したようにＣＰＵ２１によってＲＡＭ２３にロードされ実行される。

Ｗｅｂサーバー３１は、クライアント１２からのＷｅｂリクエストを受け付けるＷｅｂインタフェースを備えたＷｅｂアプリケーションサーバーである。

ログインアプリケーション３２は、Ｗｅｂサーバー３１上にアプリケーションとして構成され、Ｗｅｂサーバー３１が受け付けたＷｅｂリクエストに対して、ログイン画面を生成する。

アクセス制御エージェント３３は、Ｗｅｂサーバー３１上にフィルタリングアプリケーションとして構成され、ログインアプリケーション３２に対するＷｅｂリクエストをフィルタリングする。そして、アクセス制御サービス１４に構成されるアクセス制御エージェントＩ／Ｆ４１と通信することによりユーザーの認証処理を実行する。

以後、上記ソフトウェアモジュールの協調により実行される一連の認証処理をログインサービス１３で実行される処理と記載する。なお、ログインサービス１３で実行されるユーザーの認証処理の詳細については後述する。

図４は、アクセス制御サービス１４上で動作するソフトウェアモジュールの構成図である。なお各ソフトウェアモジュールは図２で示したＨＤＤ２４に記憶されており、前述したようにＣＰＵ２１によってＲＡＭ２３にロードされ実行される。

図中４１はログインサービス１３、サービス１５に構成されるアクセス制御エージェント３３および５３からのリクエスト受付およびレスポンス応答を行うアクセス制御エージェントＩ／Ｆ４１である。

図中４２はサービス１５に構成されるアクセス制御サービスＩ／Ｆ５４からのＡＰＩ呼出の受付およびＡＰＩ実行結果の応答を行うアクセス制御サービスＡＰＩ４２である。

アクセス制御部４３は、アクセス制御エージェントＩ／Ｆ４１、アクセス制御サービスＡＰＩ４２からアクセス権確認を受け付け、制御するアプリケーションモジュールである。アクセス部４３は、ＤＢドライバ部４４を介してデータベースサービス１６のデータ取得や更新を行う。

以後、上記ソフトウェアモジュールの協調により実行される一連のアクセス制御処理をアクセス制御サービス１４で実行される処理と記載する。なお、アクセス制御サービス１４で実行されるアクセス制御処理の詳細は後述する。

図５は、サービス１５Ａ、１５Ｂ上で動作するソフトウェアモジュールの構成例である。なお各ソフトウェアモジュールは図２で示したＨＤＤ２４に記憶されており、前述したようにＣＰＵ２１によってＲＡＭ２３にロードされ実行される。

Ｗｅｂサーバー５１は、クライアント１２からのＷｅｂリクエストを受け付けるＷｅｂインタフェースを備えたＷｅｂアプリケーションサーバーである。

Ｗｅｂアプリケーション５２は、Ｗｅｂサーバー５１上にアプリケーションとして構成され、Ｗｅｂサーバー５１が受け付けたＷｅｂリクエストに対して、サービスを提供する画面を生成する。

アクセス制御エージェント５３は、Ｗｅｂサーバー５１上にフィルタリングアプリケーションとして構成され、Ｗｅｂアプリケーション５２に対するＷｅｂリクエストをフィルタリングする。そして、アクセス制御サービス１４に構成されるアクセス制御エージェントＩ／Ｆ４１と通信することによりユーザーの認証確認処理および、アクセス制御処理を実行する。

図中５４は、アクセス制御サービス１４に構成されるアクセス制御サービスＡＰＩ４２を呼び出すためのアクセス制御サービスＩ／Ｆ５４である。アクセス制御サービスＩ／Ｆ５４は、Ｗｅｂアプリケーション５２から利用する事ができるよう構成される。

以後、上記ソフトウェアモジュールの協調により実行される一連のＷｅｂアプリケーション処理をサービス１５で実行される処理と記載する。なお、サービス１５で実行されるＷｅｂアプリケーション処理の詳細については後述する。

図６はユーザー情報のデータ構造および、ユーザー認証時に生成する認証トークン情報のデータ構造である。ユーザー情報は、ユーザーテーブル６０、ユーザーロールテーブル６１で構成され、データベースサービス１６にて管理されている。また、認証トークン情報は認証トークンキャッシュ６３で構成され、アクセス制御サービス１４のＲＡＭ２３に格納される。

ユーザーテーブル６０は、ユーザーを識別するためのユーザーＩＤ６０１、秘匿情報であるパスワード６０２、ユーザーのデータアクセス範囲を示すユーザータイプＩＤ６０３、ユーザーが所属するテナントを識別するためのテナントＩＤ６０４から成る。

ユーザーロールテーブル６１は、ユーザーを識別するためのユーザーＩＤ６１１、ユーザーに設定されているロール情報を示すロールＩＤ６１２から成る。

認証トークンキャッシュ６３は、認証トークンを識別するための認証トークンＩＤ６３１、ユーザーを識別するためのユーザーＩＤ６３２、ユーザーに設定されている全てのロールＩＤであるロールＩＤ配列６３３から成る。

なお、認証トークンキャッシュ６３のデータはアクセス制御サービス１４においてユーザーの認証処理が実行され、認証が成功した時に生成される。

図７はロール情報およびリソース情報のデータ構造である。ロール情報はロールテーブル７０、リソース情報はリソーステーブル７１で構成される。また、ロールとリソースの関係はリソースロールテーブル７２で構成される。これらテーブルはデータベースサービス１６にて管理されている。

ロールテーブル７０は、ロールを識別するためのロールＩＤ７０１、ロールのカテゴリを識別するためのロールカテゴリＩＤ７０２から成る。

リソーステーブル７１は、リソースを識別するためのリソースＩＤ７１１、リソースのカテゴリを識別するためのリソースカテゴリＩＤ７１２、リソースとして管理される情報である保護アイテム７１３、リソースに対する権限情報を示す権限７１４から成る。

リソースロールテーブル７２は、リソースを識別するためのリソースＩＤ７２１、ロールを識別するためのロールＩＤ７２２から成る。

図８はテナント情報およびＡＰＩ（機能）の実行権限情報のデータ構造である。テナント情報はテナントテーブル８０、ＡＰＩ（機能）の実行権限情報はＡＰＩ権限テーブル８１で構成され、データベースサービス１６にて管理されている。また、テナント情報の例として、ライセンスを発行できるテナントが管理する契約ライセンス数テーブル８２と、各テナントが管理する利用ライセンス数テーブル８３のデータ構造も示す。

テナントテーブル８０は、テナントを識別するためのテナントＩＤ８０１、テナントに属するユーザーに設定されるユーザータイプＩＤ８０２、テナントのカテゴリを識別するためのテナントカテゴリＩＤ８０３から成る。

ＡＰＩ権限テーブル８１は、ＡＰＩを識別するためのファンクションＩＤ８１１、ロールを識別するためのロールＩＤ８１２、および、操作テナントカテゴリＩＤ８１３、***作テナントカテゴリＩＤ８１４、エレベーション可否８１５からなる。なお、操作テナントカテゴリＩＤ８１３は、ＡＰＩ実行者が所属するテナントのカテゴリを識別するためのＩＤであり、***作テナントカテゴリＩＤ８１４は、ＡＰＩ実行対象のデータが所属するテナントのカテゴリを識別するためのＩＤである。また、エレベーション可否８１５は、そのＡＰＩが、ＡＰＩ実行者のテナントと異なるテナントのデータに対して実行できるかを表す。

契約ライセンス数テーブル８２は、ライセンスを識別するためのライセンスＩＤ８２１、ユーザーのデータアクセス範囲を示すユーザータイプＩＤ８２２、契約しているテナントのテナントＩＤ８２３、契約を行っているライセンス数８２４からなる。利用ライセンス数テーブル８３は、ライセンスを識別するためのライセンスＩＤ８２１、ユーザーのデータアクセス範囲を示すユーザータイプＩＤ８２２、テナント内で利用しているライセンス数８２４からなる。

図６、図７、図８で説明した各データ構造に格納されるデータの処理詳細については後述する。

以下、本発明の各サービスにおける処理フローについてシーケンスおよびフローチャートを用いて説明する。なお、本願のフローチャートは、１台の情報処理装置（例えば、サーバー）、または、複数台の情報処理装置（例えば、複数のサーバー）のＣＰＵ２１が関連するプログラムを読み込んで実行することにより実現される。また、本願では、１台の情報処理装置（例えば、サーバー）が本願の処理を行っても、複数台の情報処理装置（例えば、複数のサーバー）が本願の処理を行っても良い。これらのシステムを本願ではサーバーシステムと呼称する。

図９はクライアント１２のＷｅｂブラウザからサービス１５に対してＷｅｂリクエストを行った場合の基本シーケンスである。なお、以後、クライアント１２のＷｅｂブラウザでの制御をクライアント１２の制御として説明する。

シーケンスＳ９．１において、クライアント１２は、サービス１５のＷｅｂサーバー５１に対してＷｅｂリクエストを実行する。Ｗｅｂサーバー５１は、フィルタリングアプリケーションであるアクセス制御エージェント５３に対して、Ｗｅｂリクエストを通知する（シーケンスＳ９．２）。

シーケンスＳ９．３において、アクセス制御エージェント５３は、アクセス制御サービス１４のアクセス制御エージェントＩ／Ｆ４１を介してアクセス制御部４３にて認証確認を行う。このとき、Ｗｅｂリクエストに含まれている認証トークンをアクセス制御エージェントＩ／Ｆ４１を介してアクセス制御部４３に通知する。アクセス制御部４３は、通知された認証トークンが認証トークンキャッシュ６３に格納されているかを検証する。シーケンスＳ９．３では初回アクセスであるため、通知された認証トークンは認証トークンキャッシュ６３に格納されていない。そのため、認証されていないと判断しアクセス制御エージェントＩ／Ｆ４１を介してアクセス制御エージェント５３に、ログインサービス１３に遷移するよう応答する。

シーケンスＳ９．４において、アクセス制御エージェント５３は、クライアント１２をログインサービス１３のログインアプリケーション３２にリダイレクトさせる。シーケンスＳ９．５において、ログインアプリケーション３２はログイン画面を生成し、クライアント１２に提示する。

シーケンスＳ９．６において、クライアント１２はユーザーからのログイン指示を受けて、その際入力されたユーザー情報をログインアプリケーション３２にログイン通知する。ここで、ユーザー情報としては、ユーザーを識別するためのユーザーＩＤ、および秘匿情報であるパスワードが通知される。

ログイン通知を受けたログインアプリケーション３２は、シーケンスＳ９．７にて、アクセス制御エージェント３３および、アクセス制御エージェントＩ／Ｆ４１を介して、アクセス制御部４３に対して認証リクエストを行う。

認証リクエストを受けたアクセス制御部４３は認証リクエストに含まれるユーザーＩＤ，パスワードの正当であるか検証する。その際、アクセス制御部４３はシーケンスＳ９．８にて、ＤＢドライバ部４４を介してデータベースサービス１６のユーザーテーブル６０に格納されているユーザーＩＤ６０１、パスワード６０２情報と比較検証する。なお、秘匿情報であるパスワード６０２は、例えば、非可逆なハッシュ関数を適用し、秘匿化されて格納されていることが好ましい。その場合は、通知された認証リクエストのパスワード情報をパスワード６０２に格納する際に適用した関数で秘匿化し、比較することで検証が行われる。

シーケンスＳ９．８において、アクセス制御部４３は、検証の結果、ユーザー情報が正当である場合は認証トークンを生成し、認証トークンキャッシュ６３に格納する。その際、ＤＢドライバ部４４を介して、ユーザーロールテーブル６１からユーザーＩＤをキーとして、ロールＩＤ６１２を全て取得し、ユーザーＩＤと共に格納する。そして、アクセス制御部４３は、シーケンスＳ９．９にて、アクセス制御エージェントＩ／Ｆ４１を介してアクセス制御エージェント３３に生成した認証トークンを通知する。

シーケンスＳ９．１０において、アクセス制御エージェント３３は、受け付けた認証トークンを付与して、クライアント１２を、シーケンスＳ９．１にてリクエストされたＷｅｂサーバー５１にリダイレクトさせる。そして、シーケンスＳ９．１１において、Ｗｅｂサーバー５１はシーケンスＳ９．２と同様にアクセス制御エージェント５３にリクエストを通知する。

シーケンスＳ９．１２において、アクセス制御エージェント５３は、アクセス制御サービス１４のアクセス制御エージェントＩ／Ｆ４１を介してアクセス制御部４３にて認証確認を行う。このとき、Ｗｅｂリクエストに含まれている認証トークンをアクセス制御エージェントＩ／Ｆ４１を介してアクセス制御部４３に通知する。アクセス制御部４３は、通知された認証トークンが認証トークンキャッシュ６３に格納されているかを検証する。シーケンスＳ９．１２では通知された認証トークンは認証トークンキャッシュ６３に格納さされている。そのため、認証されていると判断し、リソースアクセス可否確認を行う。リソースアクセス可否確認の処理詳細については後述する。次に、アクセス制御部４３は、リソースアクセスを許可と判断した場合は、ＤＢドライバ部４４を介してユーザーテーブル６０からユーザー情報を取得する。そして、取得したユーザー情報をアクセス制御エージェントＩ／Ｆ４１を介してアクセス制御エージェント５３に通知する。

シーケンスＳ９．１３において、アクセス制御エージェント５３は、Ｗｅｂアプリケーション５２に対してＷｅｂリクエストおよび、ユーザー情報を通知する。ユーザー情報の通知を受けたＷｅｂアプリケーション５２は、不図示の業務用の画面を生成し、シーケンスＳ９．１４にてクライアント１２に提示する。そして、クライアント１２は、ユーザーからの画面操作を受けて、シーケンスＳ９．１６にてＷｅｂサーバー５１に対して操作したことを示すＷｅｂリクエストを通知する。

シーケンスＳ９．１７、シーケンスＳ９．１８、およびシーケンスＳ９．１９は、それぞれ、シーケンスＳ９．１１、シーケンスＳ９．１２、およびシーケンスＳ９．１３と同様の処理であるため、説明を省く。

次に、シーケンスＳ９．１５におけるユーザーの操作に伴って、アクセス制御サービス１４のアクセス制御サービスＡＰＩ４２のＡＰＩが実行されるケースとして説明する。

シーケンスＳ９．２０において、Ｗｅｂアプリケーション５２は、アクセス制御サービスＩ／Ｆ５４を介してアクセス制御サービスＡＰＩ４２のＡＰＩを呼び出す。その際、ＡＰＩの引数として認証トークンを通知する。

シーケンスＳ９．２１において、アクセス制御サービスＡＰＩ４２はＡＰＩ実行権限の確認を行う。ＡＰＩ実行権限の確認処理詳細については後述する。ＡＰＩ実行が許可された場合、アクセス制御サービスＡＰＩ４２はＡＰＩの実行内容に従ってアクセス制御部４３に対してデータ取得をリクエストする（シーケンスＳ９．２２）。その際、認証トークンを通知する。

シーケンスＳ９．２３において、アクセス制御部４３はデータアクセスの可否の確認処理を行う（シーケンスＳ９．２３）。データアクセスの可否の確認処理詳細については後述する。データアクセスが許可された場合、アクセス制御部４３はＤＢドライバ部４４を介してデータを取得し、シーケンスＳ９．２４においてアクセス制御サービスＡＰＩ４２へ通知する。

シーケンスＳ９．２５において、アクセス制御サービスＡＰＩ４２は、取得したデータをもとにＡＰＩ応答を生成し、アクセス制御サービスＩ／Ｆ５４を介してＷｅｂアプリケーション５２に通知する。

シーケンスＳ９．２６において、Ｗｅｂアプリケーション５２はＡＰＩ応答に従った画面を生成し、クライアント１２に提示する。

上記、図９を用いて説明した基本シーケンスによって、ユーザーの認証および、ユーザーのアクセス権制御処理を実行する。

図１０（Ａ）は、図９を用いて説明した基本シーケンスにおける、アクセス制御サービス１４におけるアクセス制御処理フローである。

以下、図９におけるシーケンスＳ９．２０のアクセス制御サービスＡＰＩ４２へのＡＰＩ呼び出しにおいて、ステップＳ１００１が実行されるフローを説明する。

アクセス制御サービスＡＰＩ４２は、ステップＳ１００１にてＡＰＩ呼び出しを受けると、ステップＳ１００２にて通知された認証トークンの有効性を確認する。より具体的には、アクセス制御サービスＡＰＩ４２は、アクセス制御部４３に対して、通知された認証トークンが認証トークンキャッシュ６３に格納されているかを確認する。そして、認証トークンが無効であると判断された場合（認証トークンが格納されていない場合）、ステップＳ１００３にて認証トークンが無効であるため、ＡＰＩが実行できない旨を応答する。認証トークンが有効である場合、ステップＳ１００４にて、アクセス制御サービスＡＰＩ４２は、アクセス制御部４３を介して認証トークンをキーにユーザーＩＤを取得する。続けて、アクセス制御サービスＡＰＩ４２は、ユーザーテーブル６０、テナントテーブル８０よりユーザー情報、テナント情報を取得する。

次に、ステップＳ１００５において、アクセス制御サービスＡＰＩ４２は、ＤＢドライバ部４４を介してＡＰＩ権限テーブルから呼び出されたＡＰＩのファンクションＩＤをキーに情報を取得する。アクセス制御サービスＡＰＩ４２は、ステップＳ１００４にて取得したユーザー情報およびテナント情報とステップＳ１００５にて取得したＡＰＩ権限情報を比較し、ＡＰＩが実行できるかの判定を行う（ステップＳ１００６）。なお、この判定については後述する。

ステップＳ１００６の判定の結果、ＡＰＩ実行が拒否された場合、ステップＳ１００７にて、アクセス制御サービスＡＰＩ４２はＡＰＩ実行を拒否し、ステップＳ１００８にて認可エラーとして応答する。判定の結果ＡＰＩ実行が許可された場合は、アクセス制御サービスＡＰＩ４２はＡＰＩ実行を許可し、ステップＳ１００９にてＡＰＩを実行する。

ステップＳ１０１０において、アクセス制御サービスＡＰＩ４２は、ＡＰＩ実行内容にリソースアクセスを含まない場合は、ステップＳ１０１１にてＡＰＩの実行結果を生成して応答する。ＡＰＩ実行内容にリソースアクセスが含まれる場合は、アクセス制御サービスＡＰＩ４２は、ステップＳ１０１２において、アクセス制御部４３に対してリソースアクセス可否確認を行う。ここでリソースとしては、データベースサービス１６に格納されている情報であるデータリソースや、サービス１５が提供するＷｅｂアプリケーションのＵＲＬリソースである。アクセス制御部４３におけるリソースアクセス可否確認の処理は後述する。

ステップＳ１０１３において、アクセス制御サービスＡＰＩ４２は、アクセス制御部４３におけるリソースアクセス可否確認の結果が拒否だった場合は、ステップＳ１００８にて認可エラーとして応答する。アクセス制御サービスＡＰＩ４２は、アクセス制御部４３におけるリソースアクセス可否確認の結果が許可だった場合は、取得したリソース情報をもとにＡＰＩの実行結果を生成して応答する。

以下、図１０（Ｂ）により、図９におけるシーケンスＳ９．１２、シーケンスＳ９．１８、シーケンスＳ９．２２におけるアクセス制御部４３へのアクセス権限確認においてステップＳ１０２１が実行されるフローを説明する。また、ステップＳ１０２１は、図１０（Ａ）におけるステップＳ１０１１のリソースアクセス可否確認においても実行される。

シーケンスＳ９．１２、シーケンスＳ９．１８では、ＵＲＬリソースに対するリソースアクセス可否確認として、また、シーケンスＳ９．２２では、データリソースに対するリソースアクセス可否確認として、ステップＳ１０２１が実行される。

ステップＳ１０２１において、アクセス制御部４３は、リソースアクセス可否確認のリクエストを受け付ける。この際、リソースアクセスを実行するユーザーの認可トークン、対象のリソースカテゴリ、保護アイテム情報、および保護アイテムに対するアクションを取得する。ここで、保護アイテム情報とは、リソースカテゴリがＵＲＬリソースである場合はＵＲＬ、データリソースである場合は、ユーザータイプＩＤおよび取得条件となる。また、アクションは、保護アイテムに対するＣＲＵＤ（Ｃｒｅａｔｅ， Ｒｅａｄ， Ｕｐｄａｔｅ， Ｄｅｌｅｔｅ）から選択される。

ステップＳ１０２２において、アクセス制御部４３は受け付けた認証トークンが認証トークンキャッシュ６３に格納されているかを確認し、有効性を検証する。検証の結果、無効であった場合はステップＳ１０２３にて認証トークンが無効である旨を通知する。検証の結果、認証トークンが有効であった場合は、ステップＳ１０２４にてユーザーＩＤ６３２およびロールＩＤ配列６３３を取得する。

ステップＳ１０２５において、アクセス制御部４３は、リソースアクセス可否確認のリクエストに含まれるリソースカテゴリを特定し、ＵＲＬリソースであった場合はステップＳ１０２６へ、データリソースだった場合はステップＳ１０２７で、各処理を実行する。

ステップＳ１０２６、ステップＳ１０２７ではアクセス制御部４３は、リソースカテゴリＩＤ、保護アイテム情報をキーとしてリソーステーブル７１および、リソースロールテーブル７２よりリソースに紐づいた全てのロールＩＤおよび権限を取得する。

ステップＳ１０２８において、アクセス制御部４３は、取得したロールＩＤおよび権限と、リクエストで受け付けた認証トークンに紐づくロールＩＤおよび、アクションを比較する。そして、ステップＳ１０２９において、アクセス制御部４３は比較検証の結果、アクセス権限がない場合、つまりアクセス拒否の場合、ステップＳ１０３０にてアクセス拒否通知を行う。アクセス制御部４３は比較検証の結果、アクセス権限がある場合、つまりアクセス許可の場合、ステップＳ１０３１にて対象のリソースを取得する。たとえば、リソースカテゴリがデータリソースであった場合は、指定の取得範囲を条件として、ＤＢドライバ部４４を介してデータを取得する。この際、必ず許可されたユーザータイプＩＤの範囲で取得データ範囲を絞り込まれる。結果、権限を保持していない他のテナントのデータを取得する事を防ぐことができる。

ステップＳ１０３２において、アクセス制御部４３は取得したリソースおよび、アクセス許可を通知する。

なお、図１０（Ｂ）の処理が、図１０（Ａ）のステップＳ１０１１のリソースアクセス可否確認において実行された場合、図１０（Ｂ）の処理に続いて図１０（Ａ）のＳ１０１３が実行される。

以下、図１０（Ｃ）により、図１０（Ａ）のステップＳ１００６で行われるＡＰＩ実行判定フローを説明する。

判定が開始されると、ステップＳ１００６において、アクセス制御サービスＡＰＩ４２は、図８のＡＰＩ権限テーブル８１から対象ＡＰＩの実行可能なロール情報を取得し、ＡＰＩ実行者に紐付いているロールと比較する。

認証トークンを通知したＡＰＩの実行者に対象ＡＰＩを実行可能なロールが紐付いていなかった場合、アクセス制御サービスＡＰＩ４２は、ステップＳ１０４１にて実行権限なしと判断し、ステップＳ１０４２にてＡＰＩ実行拒否を返す。

認証トークンを通知したＡＰＩの実行者に対象ＡＰＩを実行可能なロールが紐付いていた場合、アクセス制御サービスＡＰＩ４２は、ステップＳ１０４３にて実行者と対象ＡＰＩのテナントを比較する。この比較が、第１判定処理に相当する。

実行者と対象ＡＰＩが同じテナントであった場合、アクセス制御サービスＡＰＩ４２は、ステップＳ１０４４にて処理を許可し、ステップＳ１０４５にて処理可能を返す。実行者と対象ＡＰＩのテナントが異なっていた場合、アクセス制御サービスＡＰＩ４２は、ステップＳ１０４６にて対象ＡＰＩの定義より対象ＡＰＩがテナントを越えて実行できるＡＰＩか判定する。具体的には、図８のＡＰＩ権限テーブル８１における対象ＡＰＩのエレベーションの内容により、Ｓ１０４６が実行される。この判定が、第２判定処理に相当する。

対象ＡＰＩが他テナントに対して実行できないＡＰＩであった場合、ステップＳ１０４７にて実行権限なしと判断し、ステップＳ１０４２にてＡＰＩ実行拒否を返す。他テナントに対して実行可能なＡＰＩであった場合、ステップＳ１０４８にて、対象ＡＰＩの定義、実行者のテナントカテゴリと対象ＡＰＩのテナントカテゴリ（図８の８１３−８１４）とを比較する。この比較が、第３判定処理に相当する。

対象ＡＰＩの定義において、実行者のテナントカテゴリが、処理対象テナントに対して処理できないテナントカテゴリであった場合、ステップＳ１０４９にて実行権限なしと判断し、ステップＳ１０４２にて実行拒否を返す。実行者のテナントカテゴリが処理対象のテナントカテゴリに対して処理が可能であった場合、ステップＳ１０５０にて、実行者に対象テナントに対する処理権限を付与し、ステップＳ１０４５にて処理可能を返す。

上記、図９の基本シーケンスおよび、図１０（Ａ）〜（Ｃ）のアクセス制御フローにより、マルチテナントシステムにおいて、異なるテナントのデータに対して処理を実行することが出来る。その際、ＡＰＩ毎の制御と、テナントカテゴリによる制御を行うことで、他テナントへの処理を、処理実行者に対して複雑な設定等をすることなく、詳細な制御を行うことができる。

次に、図６、図７、図８で説明した各データ構造をもつテーブルに対して、データ例として図１１、図１２、図１３を例示する。そして、サービス１５に展開されるサービスを図１４として例示し、具体的な業務フローとしてアクセス制御フローを図１５、図１６を用いて説明する。ここで説明するデータやサービスは一例であり、本発明の内容が説明した内容に制限されるものではない。

また、本例ではテナントを越えて処理を実行するために、全てのテナントのデータにアクセス可能なスーパーユーザーを定義して利用する方法を説明している。この方法についても、本発明の内容が制限されるものではない。例えば、全てのテナントのデータにアクセス可能なロールを定義し、そのロールを実行者に一時的に紐づける方法や、処理対象テナントのデータリソースにアクセス可能なロールを実行者に一時的に紐づける方法など、他の方法で実現してもよい。

図１１において、１１１は、ユーザーテーブル６０のデータ例である。次に、１１２はユーザーロールテーブル６１のデータ例である。

図１２において、１２１はロールカテゴリの定義例である。本例では、データ管理権限を示す管理ロール、ユーザーとの利用契約を示す製品ロール、そして、データに対するアクセス範囲を示すテナントロールが定義されている。

図１２において、１２３はリソースカテゴリの定義例である。本例では、Ｗｅｂアクセスする対象としてのＵＲＬリソース、データベースサービス１６で管理されているデータを示すデータリソースが定義されている。

図１２において、１２２はロールテーブルのデータ例である。次に１２４はリソースロールテーブルのデータ例である。そして、１２５はリソーステーブルのデータ例である。

図１３において、１３１はテナントカテゴリの定義例である。本例では、サービスの運用を行う運用者が所属する運用テナント、ユーザーとの利用契約を行う販売者が所属する販売テナント、利用者である顧客テナント、および、ユーザー本人である自身というカテゴリが定義されている。

図１３において、１３２はテナントテーブルのデータ例である。次に１３３はＡＰＩ権限テーブルのデータ例である。本データ例では、以下のＡＰＩを例示している。新たなテナントを作成するＣｒｅａｔｅＴｅｎａｎｔ。他テナントに対して提供したサービス名、および発行したライセンス数を取得するＧｅｔＬｉｃｅｎｓｅＩｎｆｏ。および、テナント内で利用されているライセンス数をカウントするＣｏｕｎｔＬｉｃｅｎｓｅというＡＰＩを例示している。なお、ＡＰＩ権限テーブルでは、操作テナントカテゴリＩＤ、***作テナントカテゴリＩＤ、エレベーション可否がファンクションＩＤとを対応付けて管理している。

図１３において、１３４はライセンステーブルのデータ例である。また、１３５は契約ライセンス数テーブルのデータ例であり、１３６は利用ライセンス数テーブルのデータ例である。

図１４は、サービス１５が、Ｗｅｂアプリケーション例として、ユーザーやユーザーのロール設定、およびテナント情報を管理するためのＷｅｂアプリケーション（管理サービスとする）を提供したときの画面フロー例である。

１４０１は、ログインサービス１３で生成されるログイン画面の例である。ユーザーが図中のユーザーＩＤおよびパスワードを入力して、ログインボタンを押下し、ログイン成功およびアクセスが許可されるとメニュー画面１４０２に遷移する。本例では、ユーザーテーブルのデータ例１１１に登録されているＳａｌｅｓＵｓｅｒ０１というユーザーでログインしたとする。

１４０２は、管理サービスのメニュー画面の例である。ユーザーが図中のテナント管理リンクを押下しアクセスが許可されると、テナント検索画面１４０２に遷移する。

１４０３は、管理サービスのテナント検索画面の例である。ユーザーが図中のテナントＩＤに検索項目を入力し検索ボタンを押下し、ＣｏｕｎｔＬｉｃｅｎｓｅ ＡＰＩの実行権限が許可されると、指定したテナントで利用されているライセンス数のカウントが実行され、検索結果画面１４０４に遷移する。ここで、検索項目としては「ＴＡ０００００００３」を指定したとする。

１４０４は、管理サービスのテナント管理画面の例である。ここでは、ＴＡ０００００００３が契約しているサービス名と契約数、そしてテナント内で利用されているライセンス数が表示される。

図１５は、図１４の画面フローに従ってユーザーが操作した場合のシーケンスである。

シーケンスＳ１５．１において、クライアント１２はサービス１５のメニュー画面１４０２へＷｅｂリクエストを行う。サービス１５はアクセス制御エージェントＩ／Ｆ４１に対して認証確認を行う。ここで認証確認フローは図９、シーケンスＳ９．３にて説明済みであるため省略する。

シーケンスＳ１５．３において、サービス１５は、クライアント１２をログインサービス１３にリダイレクトさせる。そして、シーケンスＳ１５．４において、ログインサービス１３はログイン画面１４０１を提示する。

シーケンスＳ１５．５において、ユーザーはユーザーＩＤ：ＳａｌｅｓＵｓｅｒ０１としてログイン操作を行う。ログイン操作を受けたログインサービス１３はアクセス制御エージェントＩ／Ｆ４１に対して認証処理を依頼する。

シーケンスＳ１５．６における認証処理については、図９、シーケンスＳ９．７にて説明済みであるため省略する。ここで、認証成功した場合、アクセス制御部４３では、認証トークンキャッシュ６３に、生成した認証トークンのＩＤ、ユーザーＩＤ：ＳａｌｅｓＵｓｅｒ０１および、ロールＩＤを格納する。ここで、ロールＩＤとしてはユーザーロールテーブルのデータ例１１２に基づいて、ログインユーザーの「Ｓａｌｅｓ、ＴＡ０００００００２」が格納される。

認証を受けたログインサービス１３は、認証トークンを付与してシーケンスＳ１５．７にて、クライアント１２をサービス１５のメニュー画面１４０２へリダイレクトさせる。

シーケンスＳ１５．８において、サービス１５はアクセス制御エージェントＩ／Ｆ４１を介してアクセス制御部４３に対して認証確認、アクセス権限確認、およびユーザー情報取得を行う。

アクセス制御部４３では、認証トークンキャッシュ６３に認証トークンが格納されているかを確認し、格納されている場合は、ユーザーＩＤおよびロールＩＤ配列を取得する。今回は格納されているため、ユーザーＩＤ：ＳａｌｅｓＵｓｅｒ０１、ロールＩＤ配列「Ｓａｌｅｓ、ＴＡ０００００００２」が取得される。

次に、アクセス制御部４３では、図１０（Ｂ）におけるステップＳ１０２１が実行される。このとき、対象のリソースとして「ｈｔｔｐ：ｘｘｘ．ｃｏｍ／ｍｅｎｕ／ｘｘｘ．ｈｔｍｌ」が渡されるとする。これは、例えば、ユーザーが上記アドレスをブラウザに入力することにより実現される。このリソースはリソーステーブルのデータ例１２５のリソースＩＤ：Ｒ０００００００１に格納されているデータと一致する。そして、リソースＩＤ：Ｒ０００００００１は、リソースロールテーブルのデータ例１２４にて、ロールＩＤ：Ｓａｌｅｓに割り当てられている。アクセス制御部４３は図１０におけるステップＳ１０２８にて、ロールＩＤ：Ｓａｌｅｓが、認証トークンキャッシュ６３から取得したロールＩＤ配列に含まれるかを確認する。今回のデータ例ではロールＩＤ配列に含まれているため、アクセス制御部４３は、アクセス許可としてユーザーテーブルのデータ例１１１から情報を取得し、サービス１５に通知する。シーケンスＳ１５．９にてサービス１５はクライアント１２にメニュー画面１４０２を提示する。

次に、メニュー画面１４０２にてユーザーがテナント管理リンクを押下した場合のシーケンスを説明する。

シーケンスＳ１５．１０において、テナント管理が選択されると、サービス１５はシーケンスＳ１５．１１にてアクセス制御エージェントＩ／Ｆ４１を介して、アクセス制御部４３に認証確認、アクセス権限確認、ユーザー情報取得を依頼する。

アクセス制御部４３では、認証トークンキャッシュ６３に認証トークンが格納されているかを確認し、格納されている場合は、ユーザーＩＤおよびロールＩＤ配列を取得する。今回は格納されているため、ユーザーＩＤ：ＳａｌｅｓＵｓｅｒ０１、ロールＩＤ配列「Ｓａｌｅｓ、ＴＡ０００００００２」が取得される。

次に、アクセス制御部４３では、図１０（Ｂ）におけるステップＳ１０２１が実行される。このとき、対象のリソースとして「ｈｔｔｐ：ｘｘｘ．ｃｏｍ／ｔｅｎａｎｔ／ｘｘｘ．ｈｔｍｌ」が渡されるとする。このリソースはリソーステーブルのデータ例１２５のリソースＩＤ：Ｒ０００００００２に格納されているデータと一致する。そして、リソースＩＤ：Ｒ００００００２は、リソースロールテーブルのデータ例１２４にて、ロールＩＤ：Ｓａｌｅｓに割り当てられている。アクセス制御部４３は図１０におけるステップＳ１０２８にて、ロールＩＤ：Ｓａｌｅｓが、認証トークンキャッシュ６３から取得したロールＩＤ配列に含まれるかを確認する。今回のデータ例ではロールＩＤ配列に含まれているため、アクセス制御部４３は、アクセス許可としてユーザーテーブルのデータ例１１１から情報を取得し、サービス１５に通知する。シーケンスＳ１５．１２にてサービス１５はクライアント１２にテナント検索画面１４０３を提示する。

次に、テナント検索画面１４０３にてユーザーが検索項目としてテナントＩＤ「ＴＡ０００００００３」を入力し、検索ボタンを押下した場合のシーケンスを説明する。

シーケンスＳ１５．１３において、テナント検索が実行されると、サービス１５はシーケンスＳ１５．１４にてアクセス制御エージェントＩ／Ｆ４１を介して、アクセス制御部４３にライセンス情報取得を依頼する。

アクセス制御部４３では、認証トークンキャッシュ６３に認証トークンが格納されているかを確認し、格納されている場合は、ユーザーＩＤおよびロールＩＤ配列を取得する。今回は格納されているため、ユーザーＩＤ：ＳａｌｅｓＵｓｅｒ０１、ロールＩＤ配列「Ｓａｌｅｓ、ＴＡ０００００００２」が取得される。次に、アクセス制御部４３では、図１０（Ｂ）におけるステップＳ１０２１が実行される。このとき、図１３のテナントテーブル１３２を参照することにより対象のリソースとして「ＴＹ０００００００２」が渡される。このリソースはリソーステーブルのデータ例１２５のリソースＩＤ：Ｒ０００００００４に格納されているデータと一致する。そして、リソースＩＤ：Ｒ００００００４は、リソースロールテーブルのデータ例１２４にて、ロールＩＤ：ＴＡ０００００００２に割り当てられている。アクセス制御部４３は図１０におけるステップＳ１０２８にて、ロールＩＤ：ＴＡ０００００００２が、認証トークンキャッシュ６３から取得したロールＩＤ配列に含まれるかを確認する。今回のデータ例ではロールＩＤ配列に含まれているため、アクセス制御部４３は、アクセス許可と判断する。

その後、アクセス制御部４３は、契約ライセンス数テーブルのデータ例１３５から、契約テナントＩＤが、渡されたテナントＩＤ：ＴＡ０００００００３と一致する情報を取得し、サービス１５に通知する。具体的には、ライセンスＩＤ：ＴＬ０００００００１、ライセンス数：１０本、および、ライセンスＩＤ：ＴＬ０００００００２、ライセンス数：２０本がサービス１５に渡される。

ライセンス情報の通知を受けたサービス１５は、シーケンスＳ１５．１５にて、アクセス制御サービスＡＰＩ４２に対して、ＣｏｕｎｔＬｉｃｅｎｓｅ ＡＰＩを実行する。この際、サービス１５は、認証トークンとライセンス数取得対象テナントのテナントＩＤ、ライセンスＩＤを通知する。

シーケンスＳ１５．１６において、アクセス制御サービスＡＰＩ４２は、図１０（Ａ）におけるステップＳ１００１を実行する。このとき、対象のＡＰＩとしてＣｏｕｎｔＬｉｃｅｎｓｅが渡されるとする。アクセス制御サービスＡＰＩ４２は、認証トークンを検証し、ユーザーＩＤおよびロールＩＤ配列を取得する。次に、図１０（Ａ）におけるステップＳ１００５が実行され、ＡＰＩ権限テーブルのデータ例１３３からファンクションＩＤ：ＣｏｕｎｔＬｉｃｅｎｓｅが取得される。

アクセス制御サービスＡＰＩ４２では、ステップＳ１００６において、ＡＰＩ権限テーブルから取得したデータより、ＡＰＩの実行権限の判断を行う。図１３のＡＰＩ権限テーブル１３３において、ＣｏｕｎｔＬｉｃｅｎｓｅ ＡＰＩはロールＩＤ：Ｐｒｏｖｉｄｅｒ、Ｓａｌｅｓに対して実行を許可している。ここで、認証トークンキャッシュ６３から取得した実行者のロール配列にロールＩＤ：Ｓａｌｓｅが含まれているので、ステップＳ１０４１にて、実行権限ありと判定される。

実行権限ありと判断された後、ステップＳ１０４３にて、アクセス制御サービスＡＰＩ４２は、実行者テナントと対象テナントの確認を行う。渡された対象テナントＩＤ（ＴＡ０００００００３）により、テナントテーブル１３２から利用ライセンス数テーブルのユーザータイプＩＤ：ＴＹ０００００００３がデータ取得範囲となる。ここで、実行者のテナントＩＤ（ＴＡ０００００００２）と異なる他テナント（ＴＡ０００００００３）への処理であるので、ステップＳ１０４４にて、アクセス制御サービスＡＰＩ４２は、異なるテナントに対する処理と判断する。

他テナントへの処理と判断された後、ステップＳ１０４６にて、アクセス制御サービスＡＰＩ４２は、対象ＡＰＩについてテナントを越えた処理が許可されているかを確認する。今回の対象ＡＰＩであるＣｏｕｎｔＬｉｃｅｎｓｅ ＡＰＩは、図１３のＡＰＩ権限テーブル１３３においてエレベーション可否が「Ａｌｌｏｗ」となっており、テナントを越えての実行が許可されている。そのため、ステップＳ１０４７にて、アクセス制御サービスＡＰＩ４２は、テナント越え出来ると判断する。

対象ＡＰＩがテナントを越えての実行が可能と判断された後、ステップＳ１０４８にてアクセス制御サービスＡＰＩ４２は、実行者のテナントカテゴリと処理対象テナントカテゴリを、ＡＰＩ権限テーブル１３３に定義されているテナントカテゴリと比較する。具体的に説明すると、テナントテーブル１３２にて、実行者のテナントＴＡ０００００００２には「ＳａｌｅｓＴｅｎａｎｔ」と定義され、処理対象テナントＴＡ０００００００３には「ＣｕｓｔｏｍｅｒＴｅｎａｎｔ」と定義されている。ここで対象ＡＰＩであるＣｏｕｎｔＬｉｃｅｎｓｅ ＡＰＩは、ＡＰＩ権限テーブル１３３において操作テナントカテゴリ「ＳａｌｅｓＴｅｎａｎｔ」に対して***作テナントカテゴリ「ＣｕｓｔｏｍｅｒＴｅｎａｎｔ」が定義されている。そのため、ステップＳ１０４９にて、アクセス制御サービスＡＰＩ４２は、処理可能と判断する。

テナントカテゴリにより処理可能と判断された後、ステップＳ１０５０にて、アクセス制御ＡＰＩ４２はユーザーテーブル１１１に定義されているＳｕｐｅｒＵｓｅｒでシステムにログインし、認証トークンを発行する。そして、以降のシーケンスはＳａｌｅｓＵｓｅｒ０１が実行するが、ここで発行されたＳｕｐｅｒＵｓｅｒの認証トークンを利用する。

シーケンスＳ１５．１７において、アクセス制御サービスＡＰＩ４２は、図１０におけるステップＳ１０１０にて、データリソースへのアクセスとしてアクセス制御部４３にリソースアクセス可否確認依頼を実行する。その際、ＳｕｐｅｒＵｓｅｒの認証トークンおよび、データ取得範囲として、ユーザーテーブルに対する「ＴＡ０００００００３」を通知する。

シーケンスＳ１５．１８において、アクセス制御部４３では、認証トークンキャッシュ６３に認証トークンが格納されているかを確認し、格納されている場合は、ユーザーＩＤおよびロールＩＤ配列を取得する。今回は格納されているため、ユーザーＩＤ：ＳａｌｅｓＵｓｅｒ０１、ロールＩＤ配列「ＳｕｐｅｒＵｓｅｒ」が取得される。

次に、アクセス制御部４３では、図１０（Ｂ）におけるステップＳ１０２１が実行される。このとき、対象のリソースとして「ＴＡ０００００００３」が渡される。アクセス制御部４３において、保護アイテムは、ユーザーテーブルデータ例１１１に登録されているＴＹ０００００００３となる。このリソースはリソーステーブルのデータ例１２５のリソースＩＤ：Ｒ０００００００５に格納されているデータと一致する。そして、リソースＩＤ：Ｒ０００００００５は、リソースロールテーブルのデータ例１２４にて、ロールＩＤ：ＴＡ０００００００３に割り当てられている。アクセス制御部４３は図１０におけるステップＳ１０２８にて、ロールＩＤ：ＴＡ０００００００３が取得したロールＩＤ配列に含まれるかを確認する。今回のデータ例ではロールＩＤ配列に含まれていないが、ロールＩＤ：ＳｕｐｅｒＵｓｅｒが含まれている。データ例１１１より、ＳｕｐｅｒＵｓｅｒのユーザータイプが「＊」であるため、アクセス制御部４３は、ＴＹ０００００００３の範囲でアクセスを許可する。これにより、利用ライセンス数テーブル１３６から、ユーザータイプＩＤ：ＴＹ０００００００３のライセンスＩＤとライセンス数を取得し、シーケンスＳ１５．１９にてアクセス制御サービスＡＰＩ４２に通知する。なお利用ライセンス数のカウントは、テナント内の全てのユーザーに対して、指定したライセンスが紐付いているかの確認を行い、紐付いているユーザー数をカウントする方法などでも実施できる。

シーケンスＳ１５．２０において、アクセス制御サービスＡＰＩ４２は、ＣｏｕｎｔＬｉｃｅｎｓｅ ＡＰＩの応答として、取得した現在使用されているライセンス数をサービス１５に応答する。

シーケンスＳ１５．２１において、サービス１５は取得したテナント情報からテナント検索結果画面１４０４を生成してクライアント１２に提示する。

上記、図１５のシーケンスおよび、図１０のアクセス制御フローにより、ＡＰＩ実行者に複雑な設定をすることなく、マルチテナントサービスにおいて、異なるテナントのデータに対して処理を実行することが出来る。もし本例において運用者が顧客テナントに対しての処理を要求したとしても、データ例１３３においてＰｒｏｖｉｄｅｒＴｅｎａｎｔはＣｕｓｔｏｍｅｒＴｅｎａｎｔへの操作が許されていないため、図１０（Ｃ）のステップＳ１０４８にて処理が拒否される。また、ＡＰＩ単位でエレベーションの許可・不許可を設定することで必要以上の情報の取得等を防ぐことができる。

次に、本発明を実施するための第２の形態について図面を用いて説明する。

第１の実施例においては、ＡＰＩ毎に他テナントへの処理の可否を定義し、同時に操作者と操作対象のテナントカテゴリを定義して、他テナントに対する処理を制御している。本実施例では、テナント作成時に発行される情報を利用することで、第１の実施例において、他テナントに対する処理をさらに細かく制御する方法を説明する。なお、本実施例においては、第１の実施例と同一部分に関する説明は省略し、その差異についてのみ説明する。

図１６は第２の実施例における、ユーザー情報のデータ構造である。ユーザーテーブル６０およびユーザーロールテーブル６１からなり、データ６０１から６０４、および６１１、６１２は図６と同様であり、ユーザーテーブル６０において、マスターフラグ１６０１が新たに定義されている。マスターフラグ１６０１は、テナントのマスターユーザーを表すフラグである。マスターユーザーとはテナントのマスター管理者として定義され、テナントに１人のみ定義され、テナントが削除されるまで削除されることのないユーザーとする。

以下、第２の実施形態における、テナント作成時のフローおよびＡＰＩ実行時の権限判定について、フローチャートを用いて説明する。

図１７は、第２の実施形態における、サービス１５が、Ｗｅｂアプリケーション例として、ユーザーやユーザーのロール設定、およびテナント情報を管理するためのＷｅｂアプリケーション（管理サービスとする）をサービスしたときの画面フロー例である。

１４０１および１４０２は、前述の図１４のフローと同様である。

１７０１は、管理サービスのテナント検索画面の例である。ユーザーが図中のテナントＩＤおよび、マスター管理者ＩＤに検索項目を入力し検索ボタンを押下すると、第１の実施形態と同様に、ＣｏｕｎｔＬｉｃｅｎｓｅ ＡＰＩの実行権限を確認する。ＣｏｕｎｔＬｉｃｅｎｓｅ ＡＰＩの実行権限が許可されると、指定したテナントで利用されているライセンス数のカウントが実行され、１７０２の検索結果画面に遷移する。

１７０２は、管理サービスのテナント管理画面の例である。ここでは、ＴＡ０００００００３が契約しているサービスとその契約数、そしてテナント内で利用されているライセンス数が表示される。

図１８は、図１０（Ａ）のステップＳ１００５において、テナント作成ＡＰＩが実行された際の処理フローである。ここで、ユーザーテーブル１１１に定義されているＳａｌｅｓＵｓｅｒ０１がテナントを作成した場合を例に説明を行う。

ステップＳ１００５にて対象となるＡＰＩがテナント作成ＡＰＩであった場合、ステップＳ１８０１にて、アクセス制御サービスＡＰＩ１４２は、実行者が持つロールＩＤを確認し、ＡＰＩ実行許可判定を行う。ＳａｌｅｓＵｓｅｒ０１はロールＩＤ：Ｓａｌｅｓを持っているため、ＣｒｅａｔｅＴｅｎａｎｔ ＡＰＩの実行が許可される。

ステップＳ１８０１にてＡＰＩの実行が許可されなかった場合、ステップＳ１８０２にて実行が拒否され、ステップＳ１８０３にて実行エラーが応答される。ＡＰＩ実行が許可された場合、アクセス制御サービスＡＰＩ１４２は、ステップＳ１８０４にてＡＰＩ実行者のテナントカテゴリを取得する。ＳａｌｅｓＵｓｅｒ０１はテナントＩＤ：ＴＡ０００００００１のユーザーであり、テナントテーブル１３２からテナントカテゴリＩＤ：ＳａｌｅｓＴｅｎａｎｔと判断される。

その後ステップＳ１８０５にて、アクセス制御サービスＡＰＩ１４２は、ＡＰＩ権限テーブル１３３に定義されているＣｒｅａｔｅＴｅｎａｎｔ ＡＰＩの操作テナントカテゴリＩＤおよび***作テナントカテゴリＩＤを確認する。そして、、アクセス制御サービスＡＰＩ１４２は作成するテナントカテゴリを判定する。ＡＰＩ権限テーブル１３３にて、テナントカテゴリ：ＳａｌｅｓＴｅｎａｎｔのユーザーはＣｕｓｔｏｍｅｒＴｅｎａｎｔを作成可能と定義されているので、作成されるテナントカテゴリはＣｕｓｔｏｍｅｒＴｅｎａｎｔと判断される。

作成するテナントのテナントカテゴリ判定の結果、作成可能なテナントが存在しなかった場合は、ステップＳ１８０６にて作成不可と判定され、ステップＳ１８０３にて実行エラーを返す。作成可能なテナントが存在した場合は、ステップＳ１８０６にて作成可能と判定され、アクセス制御サービスＡＰＩ１４２は、ステップＳ１８０７にてテナントＩＤを作成する。今回は新たなテナントＩＤとして「ＴＡ０００００００４」を作成したとする。

テナントＩＤが作成されると、ステップＳ１８０８にて、アクセス制御サービスＡＰＩ１４２は、作成されたテナントＩＤに従ってテナントを作成し、ステップＳ１８０９にてユーザータイプＩＤを作成する。今回はユーザータイプＩＤとして「ＴＹ０００００００４」を作成したとする。こうしてアクセス制御サービスＡＰＩ１４２は、作成されたテナントＩＤ：ＴＡ０００００００４、ユーザータイプＩＤ：ＴＹ０００００００４、テナントカテゴリＩＤ：ＣｕｓｔｏｍｅｒＴｅｎａｎｔをテナントテーブル１３２に登録する。

テナントが作成され、テナントテーブルへと登録されると、ステップＳ１８１０にて、アクセス制御サービスＡＰＩ１４２は、テナントのマスター管理者となるテナントのマスターユーザーを作成する。今回はマスターユーザーとして「ＣｕｓｔｏｍｅｒＡｄｍｉｎ０２」を作成したとする。こうして作成されたマスターユーザーＩＤ：ＣｕｓｔｏｍｅｒＡｄｍｉｎ、パスワード、ユーザータイプＩＤ：ＴＹ０００００００４、テナントＩＤ：ＴＡ０００００００４をユーザーテーブル１１１に登録する。

その後ステップＳ１８１１にて、アクセス制御サービスＡＰＩ１４２は、作成したマスターユーザーにクラウドサービスを利用するための管理ロールおよびテナントロールを付与する。今回は、ＣｕｓｔｏｍｅｒＡｄｍｉｎ０２に管理ロールとして「ＣｕｓｔｏｍｅｒＡｄｍｉｎ、Ｃｕｓｔｏｍｅｒ」を、テナントロールとして「ＴＡ０００００００４」を付与する。

マスターユーザーにロールを付与すると、ステップＳ１８１２として処理結果を応答し、処理を終了する。

以上のフローにより、テナント作成時にテナントのマスター管理者が作成される。

図１９は、第２の実施形態における、ＡＰＩ実行時の権限判定フローである。

ステップＳ１００６、およびステップＳ１０４１からステップＳ１０４９は図１０（Ｃ）と同じフローである。

第２の実施形態では、他テナントのデータに対して処理を行う際に、対象となるテナントのテナントＩＤと合わせて、テナントのマスター管理者ＩＤが要求される。

ステップＳ１０４９にてテナントを越えた処理が可能と判断された後に、ステップＳ１９０１にて、アクセス制御サービスＡＰＩ１４２は、実行者が指定したマスター管理者ＩＤが、対象となるテナントのマスター管理者か否かを確認する。つまり、実行者が指定したマスター管理者ＩＤが、新たなテナントに設定されたマスター管理者ＩＤの設定内容と同一か判定される。

マスター管理者ＩＤが正しくなかった場合は、ステップＳ１９０２にて他テナントのデータへのアクセスを拒否し、ステップＳ１０４２にて実行を拒否する。マスター管理者ＩＤが正しかった場合は、ステップＳ１９０２にて処理を許可し、ステップＳ１０５０にて対象テナントに対する処理権限の付与を行う。

これにより、他テナントのデータにアクセス可能なユーザーを、そのテナントのマスター管理者ＩＤを知っているユーザーに制限することが出来る。

本実施例では、契約時にマスターテナントＩＤが作成されるため、テナント作成者以外が、テナントを越えてそのテナントにアクセスすることを防げる。これにより、例えば複数の販売者が存在していた場合、いたずらに顧客テナントのデータにアクセスすることを防ぐことができる。また、すでにサービスを利用しており、テナントがある顧客と契約を行った場合、その顧客からマスター管理者ＩＤを通知してもらうことで、新たに契約した販売者もその顧客テナントのデータにアクセスすることが出来るようになる。

また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

１０ ＷＡＮ
１１ ＬＡＮ
１２ クライアント
１３ ログインサービス
１４ アクセス制御サービス
１５ サービス
１６ データベースサービス

Claims (9)

1. マルチテナントサービスを提供するサーバーシステムであって、
   機能の実行を指示した実行者が所属するテナントと前記機能による処理対象のテナントが同一か否かを判定する第１判定手段と、
   前記第１判定手段により同一であると判定された場合、前記実行者に前記機能の実行を許可する許可手段と、
   前記第１判定手段により同一でないと判定された場合、前記機能が、前記実行者が所属するテナントと前記機能による処理対象のテナントが同一でない場合であっても処理可能であるか否かを判定する第２判定手段と、
   前記第２判定手段により、前記機能が、前記実行者が所属するテナントと前記機能による処理対象のテナントが同一でない場合であっても処理可能であると判定された場合、前記実行者が所属するテナントと前記処理対象のテナントとの関係が、前記機能の実行を許可する関係であるかを判定する第３判定手段とを有し、
   前記第３判定手段により、前記実行者が所属するテナントと前記処理対象のテナントとの関係が、前記機能の実行を許可する関係であると判定された場合、前記許可手段は、前記実行者に処理対象テナントに対して前記機能の実行権限を許可することを特徴とするサーバーシステム。
2. 新たなテナントの作成時に前記新たなテナントに対してマスター管理者を設定する設定手段と、
   前記第３判定手段により、前記実行者が所属するテナントと前記処理対象のテナントとの関係が、前記機能の実行を許可する関係であると判定され、かつ、前記実行者が指定した前記新たなテナントのテナントＩＤとマスター管理者ＩＤの組み合わせが正しいかを、前記設定手段の設定内容に基づいて確認する確認手段を更に有し、
   前記第３判定手段により、前記実行者が所属するテナントと前記処理対象のテナントとの関係が、前記機能の実行を許可する関係であると判定され、かつ、前記確認手段により正しいと判定された場合、前記許可手段は、前記実行者に前記機能の実行権限を許可することを特徴とする請求項１に記載のサーバーシステム。
3. 前記機能について、前記機能の実行者のテナントと、前記処理対象のテナントと、前記実行者が所属するテナントと前記機能による処理対象のテナントが同一でない場合であっても前記機能の処理を許可するか否かを示す情報とが対応づけられた権限情報を記憶する記憶手段を更に有し、
   前記第３判定手段は、前記権限情報を用いて前記実行者が所属するテナントと前記処理対象のテナントとの関係が、前記機能の実行を許可する関係であるかを判定することを特徴とする請求項１または２に記載のサーバーシステム。
4. マルチテナントサービスを提供するサーバーシステムにおいて実行される制御方法であって、
   機能の実行を指示した実行者が所属するテナントと前記機能による処理対象のテナントが同一か否かを判定する第１判定工程と、
   前記第１判定工程により同一であると判定された場合、前記実行者に前記機能の実行を許可する許可工程と、
   前記第１判定工程により同一でないと判定された場合、前記機能が、前記実行者が所属するテナントと前記機能による処理対象のテナントが同一でない場合であっても処理可能であるか否かを判定する第２判定工程と、
   前記第２判定工程により、前記機能が、前記実行者が所属するテナントと前記機能による処理対象のテナントが同一でない場合であっても処理可能であると判定された場合、前記実行者が所属するテナントと前記処理対象のテナントとの関係が、前記機能の実行を許可する関係であるかを判定する第３判定工程とを有し、
   前記第３判定工程により、前記実行者が所属するテナントと前記処理対象のテナントとの関係が、前記機能の実行を許可する関係であると判定された場合、前記許可工程は、前記実行者に処理対象テナントに対して前記機能の実行権限を許可することを特徴とする制御方法。
5. 新たなテナントの作成時に前記新たなテナントに対してマスター管理者を設定する設定工程と、
   前記第３判定工程により、前記実行者が所属するテナントと前記処理対象のテナントとの関係が、前記機能の実行を許可する関係であると判定され、かつ、前記実行者が指定した前記新たなテナントのテナントＩＤとマスター管理者ＩＤの組み合わせが正しいかを、前記設定工程の設定内容に基づいて確認する確認工程を更に有し、
   前記第３判定工程により、前記実行者が所属するテナントと前記処理対象のテナントとの関係が、前記機能の実行を許可する関係であると判定され、かつ、前記確認工程により正しいと判定された場合、前記許可工程は、前記実行者に前記機能の実行権限を許可することを特徴とする請求項４に記載の制御方法。
6. 前記機能について、前記機能の実行者のテナントと、前記処理対象のテナントと、前記実行者が所属するテナントと前記機能による処理対象のテナントが同一でない場合であっても前記機能の処理を許可するか否かを示す情報とが対応づけられた権限情報を記憶する記憶工程を更に有し、
   前記第３判定工程は、前記権限情報を用いて前記実行者が所属するテナントと前記処理対象のテナントとの関係が、前記機能の実行を許可する関係であるかを判定することを特徴とする請求項４または５に記載の制御方法。
7. マルチテナントサービスを提供するサーバーシステムにおいて実行されるプログラムであって、
   機能の実行を指示した実行者が所属するテナントと前記機能による処理対象のテナントが同一か否かを判定する第１判定工程と、
   前記第１判定工程により同一であると判定された場合、前記実行者に前記機能の実行を許可する許可工程と、
   前記第１判定工程により同一でないと判定された場合、前記機能が、前記実行者が所属するテナントと前記機能による処理対象のテナントが同一でない場合であっても処理可能であるか否かを判定する第２判定工程と、
   前記第２判定工程により、前記機能が、前記実行者が所属するテナントと前記機能による処理対象のテナントが同一でない場合であっても処理可能であると判定された場合、前記実行者が所属するテナントと前記処理対象のテナントとの関係が、前記機能の実行を許可する関係であるかを判定する第３判定工程とを有し、
   前記第３判定工程により、前記実行者が所属するテナントと前記処理対象のテナントとの関係が、前記機能の実行を許可する関係であると判定された場合、前記許可工程は、前記実行者に処理対象テナントに対して前記機能の実行権限を許可することを特徴とするコンピュータが読み取り可能なプログラム。
8. 新たなテナントの作成時に前記新たなテナントに対してマスター管理者を設定する設定工程と、
   前記第３判定工程により、前記実行者が所属するテナントと前記処理対象のテナントとの関係が、前記機能の実行を許可する関係であると判定され、かつ、前記実行者が指定した前記新たなテナントのテナントＩＤとマスター管理者ＩＤの組み合わせが正しいかを、前記設定工程の設定内容に基づいて確認する確認工程を更に有し、
   前記第３判定工程により、前記実行者が所属するテナントと前記処理対象のテナントとの関係が、前記機能の実行を許可する関係であると判定され、かつ、前記確認工程により正しいと判定された場合、前記許可工程は、前記実行者に前記機能の実行権限を許可することを特徴とする請求項７に記載のプログラム。
9. 前記機能について、前記機能の実行者のテナントと、前記処理対象のテナントと、前記実行者が所属するテナントと前記機能による処理対象のテナントが同一でない場合であっても前記機能の処理を許可するか否かを示す情報とが対応づけられた権限情報を記憶する記憶工程を更に有し、
   前記第３判定工程は、前記権限情報を用いて前記実行者が所属するテナントと前記処理対象のテナントとの関係が、前記機能の実行を許可する関係であるかを判定することを特徴とする請求項７または８に記載のプログラム。

Images