WO2017090142A1 - サービス提供システム - Google Patents

サービス提供システム Download PDF

Info

Publication number
WO2017090142A1
WO2017090142A1 PCT/JP2015/083181 JP2015083181W WO2017090142A1 WO 2017090142 A1 WO2017090142 A1 WO 2017090142A1 JP 2015083181 W JP2015083181 W JP 2015083181W WO 2017090142 A1 WO2017090142 A1 WO 2017090142A1
Authority
WO
WIPO (PCT)
Prior art keywords
tenant
data
schema
common
application
Prior art date
Application number
PCT/JP2015/083181
Other languages
English (en)
French (fr)
Inventor
実留 門田
心平 柳生
Original Assignee
株式会社野村総合研究所
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社野村総合研究所 filed Critical 株式会社野村総合研究所
Priority to JP2017504838A priority Critical patent/JPWO2017090142A1/ja
Priority to PCT/JP2015/083181 priority patent/WO2017090142A1/ja
Publication of WO2017090142A1 publication Critical patent/WO2017090142A1/ja

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/62Protecting access to data via a platform, e.g. using keys or access control rules

Definitions

  • the present invention relates to a technique for providing a service to a user via a network, and more particularly to a technique that is effective when applied to a multi-tenant type service providing system that is used by a provider who provides a service in a shared manner. is there.
  • SaaS Software Service Service
  • each tenant that shares the vehicle needs to be handled separately and independently from the viewpoint of security, etc., and the data that each tenant can use and reference is limited to its own, and other tenants Access control needs to be performed so that the data related to cannot be used / referenced.
  • Patent Document 1 acquires a user ID based on a login request, and sets the tenant ID corresponding to the user ID as a tenant ID. Acquired from the management table and recorded in the identification information storage means, and upon receiving an access request to the database from the application software, based on the tenant ID recorded in the identification information storage means, out of a plurality of data areas in the database A technique is described that simplifies development of an application that accesses a database having a different data area for each user by transmitting an access request to the data area corresponding to the tenant ID to the database management unit.
  • the application stores the data unique to each tenant in a different area (table or the like) on the database, and the application It is possible to hide the part related to access control to each table for each tenant when accessing the application from the application. It also describes the configuration of tables with different schemas for each tenant.
  • each company has data such as data exchanged with institutions with a public role, such as securities exchanges and settlement institutions such as the Bank of Japan, and data related to currencies.
  • institutions with a public role such as securities exchanges and settlement institutions such as the Bank of Japan
  • data related to currencies There is a tendency to handle common data compared to other industries. Therefore, in a multi-tenant type SaaS system, etc., not all data is individually separated and held by each tenant, but data common to each tenant is held centrally and can be used by each tenant. It is more efficient to do.
  • Patent Document 1 does not consider the configuration of the database including such common data, and has a configuration in which all the data used by each tenant is individually separated and held. It has become.
  • an object of the present invention is to separate and hold data unique to each tenant in a mechanism for providing a service in a multi-tenant type, and to centrally hold data common to each tenant.
  • the object is to provide a service providing system that enables each tenant to handle data seamlessly.
  • a service providing system is a service providing system in which a plurality of tenants provide a service individually to a user via a network in a shared manner, and executes processing related to the service
  • An application server having an application; and a database server for holding data used for the processing on the database.
  • the database includes a common schema and an individual schema corresponding to each tenant, and the common schema includes only common data accessible to each tenant and each corresponding tenant only.
  • Each of the individual schemas has a view for accessing the actual data on the common schema, and the view uses the identification information of the tenant as a parameter, Only the unique data related to the tenant corresponding to the common data and the identification information can be accessed.
  • the application determines the tenant used by the user, and accesses data on the database via the view of the individual schema corresponding to the determined tenant.
  • each tenant individually separates and holds unique data, and data common to each tenant is stored. These data are stored centrally and each tenant can be handled seamlessly.
  • FIG. 1 is a diagram showing an outline of a configuration example of a service providing system according to an embodiment of the present invention.
  • the service providing system 1 includes, for example, one or more application servers 10 and one or more databases (for example, server devices in a data center or virtual servers constructed on a cloud computing environment).
  • DB server devices in a data center or virtual servers constructed on a cloud computing environment.
  • the server 20 is configured.
  • a plurality of tenants share a shared service on the service providing system 1 to a user terminal 3 that is an information processing terminal used by a user such as a customer via a network (NW) 2 such as the Internet.
  • NW network
  • the tenant provides the service.
  • the application server 10 and the DB server 20 can communicate with each other via a network (not shown).
  • the application server 10 and the DB server 20 are built on the same server system, and the processes can be performed without using the network. It is also possible to adopt a configuration in which communication is performed by communication or the like.
  • a web server or a load distribution server may be included.
  • the application server 10 includes various units such as an application 11 and an authentication unit 12 that are implemented as software programs that run on middleware such as an OS (Operating System) and a DBMS (DataBase Management System) (not shown). Further, as will be described later, a connection pool function included in a general DBMS is used, and the connection pool management unit 13 is implemented as a component of the DBMS.
  • middleware such as an OS (Operating System) and a DBMS (DataBase Management System) (not shown).
  • DBMS DataBase Management System
  • the application 11 is a software program in which processing related to services and operations that the service providing system 1 can provide to the user terminal 3 is implemented. There are various specific processing contents depending on the contents of the service provided by the execution of the application 11, but at least a function of accessing the data held on the DB server 20 is provided. Basically, it is assumed that each tenant sharing the service providing system 1 is implemented by a common program or module.
  • the authentication unit 12 has authority to use the service provided by the service providing system 1 by referring to a user management table (not shown) or the like in response to a request from the application 11, for example. User authentication is performed. At that time, it is also determined which tenant the user is, and responds to the application 11 with respect to identification information (for example, “company code” and “tenant ID”) of the tenant to be used. When the application 11 generates a transaction related to the service, the application 11 specifies the identification information of the tenant related to the target user as an input parameter.
  • identification information for example, “company code” and “tenant ID”
  • connection pool management unit 13 The setting contents of the connection pool management unit 13 will be described later.
  • the DB server 20 separates and stores the unique data (unique data) of each tenant as a database that operates on middleware such as an OS or DBMS (not shown), as described above. Data common to each tenant (common data) is stored centrally.
  • the data structure as described above is realized by defining a plurality of schemas on a database by a schema function of a general DBMS.
  • common data 24 and unique data (in the figure, A unique data 25a to D unique data 25d corresponding to four tenants A to D are shown. Hereinafter, these are collectively referred to as unique data 25) Each of which is). These data may be held in different areas as different tables or the like, or the common data 24 and the plurality of unique data 25 may be held together in one table. In any case, each unique data 25 can be specified and accessed by identification information such as a company code that uniquely identifies the target tenant.
  • a view 22 for accessing the substance of data held on the common schema 23 is defined.
  • the view 22 can access only the common data 24 that can be accessed regardless of the tenant and the specific data 25 related to the target tenant by receiving the designation of the identification information of the tenant as a parameter. Is defined as
  • the identification information such as the company code of the tenant A is specified, whereby the A specified by the common data 24 and the identification information of the tenant A
  • the access range is limited at the DBMS layer so that only the unique data 25a can be accessed.
  • the access range is limited so that only the common data 24 and the unique data 25 corresponding to the target tenant can be accessed.
  • the application 11 is mounted so as to access the database only through the view 22.
  • the data access range is determined by itself. Can only be limited to those related to tenants.
  • the security is improved and the influence on the processing performance of other tenants due to the difference in the data amount for each tenant is suppressed. For example, when the amount of data held by tenant A is 100 times or 1000 times the amount of data held by tenant B, access to data related to tenant B is delayed due to a large amount of access to data related to tenant A We will suppress the possibility of such effects as much as possible.
  • connection pool management unit 13 of the application server 10 in response to dividing the schema (individual schema 21) for each tenant, the connection pool management unit 13 of the application server 10 further establishes a plurality of connections established for each individual schema 21 (in the figure).
  • Pooled connection pools shown in the figure as connection pools (schema A) (14a) and connection pool (schema B) (14b) respectively corresponding to schema A (21a) and schema B (21b). May be collectively referred to as connection pool 14 It is assumed that to create that).
  • the application 11 uses the connection 15 pooled in the connection pool 14 of the individual schema 21 corresponding to the target tenant when accessing the database.
  • the application 11 automatically accesses the view 22 of the target individual schema 21 without being particularly aware of the range of accessible data due to tenant differences, and on the common schema 23 via the view 22. Access control is performed so that only the common data 24 and the company-specific data 25 can be accessed.
  • each connection 15 used by the application 11 is preset with identification information such as a company code of a tenant corresponding to the individual schema 21 to which the connection 15 belongs, and the view of the target individual schema 21 In 22, the tenant identification information is acquired from the attribute value of the connection 15 to be used and used as a parameter.
  • the company code “001” is set as the attribute value in the connection (schema A) 15a, and in the schema A (21a), the view 22 is changed from the attribute value of the connection (schema A) 15a to this company.
  • the value of code “001” is acquired and used as a parameter.
  • the range of accessible data is limited only to the common data 24 and the unique data 25 corresponding to its own company code “001”.
  • the application 11 determines the connection pool 14 to be used based on, for example, input information (information that can identify a tenant) in a transaction. For example, when the user authenticates the user through the authentication unit 12 at the start of use of the application 11, the authentication unit 12 responds together with the identification information of the tenant to which the user belongs, and sends this information to the session of the application 11. Keep it as related information. The application 11 uses the identification information as input information in the transaction.
  • connection pool 14 used by the application for example, when the application server 10 is started, a correspondence relationship between the identification information of the connection pool 14 and the tenant identification information is created in advance and held in a memory table or the like.
  • the application 11 refers to this and identifies the corresponding connection pool 14 based on the identification information of the tenant to which the user belongs.
  • identification information such as a tenant's company code is set in advance as an attribute value as described above.
  • the setting of the identification information to the attribute value of the connection 15 is automatically set for each connection 15 using the DBMS logon trigger function when the connection pool 14 and the connection 15 are created when the application server 10 is started. can do.
  • the schema is divided for each tenant, and in addition to limiting the data access range with the common data 24 and the specific data 25, the connection pool 14 is individually provided for each schema. Accordingly, it is possible to easily realize seamless access to the common data 24 and the specific data 25 by concealing the portion related to the multi-tenant in the database access from the implementation of the application 11 by the DBMS layer. In addition to improving security among tenants, it is possible to reduce the influence on the overall processing performance based on the difference in the amount of data for each tenant and improve performance.
  • the present invention made by the present inventor has been specifically described based on the embodiments.
  • the present invention is not limited to the above-described embodiments, and various modifications can be made without departing from the scope of the invention. Needless to say.
  • the above-described embodiment has been described in detail for easy understanding of the present invention, and is not necessarily limited to the one having all the configurations described.
  • the present invention is applicable to a multi-tenant type service providing system that is used by a company that provides services individually in a multi-carpool.
  • 1 ... service providing system, 2 ... network, 3 ... user terminal, DESCRIPTION OF SYMBOLS 10 ... Application server, 11 ... Application, 12 ... Authentication part, 13 ... Connection pool management part, 14 ... Connection pool, 14a, b ... Connection pool (schema A, B), 15 ... Connection, 15a, b ... Connection (schema) A, B), 20 ... DB server, 21 ... Individual schema, 21a-d ... Schema A-D, 22 ... View, 23 ... Common schema, 24 ... Common data, 25 ... Specific data, 25a-d ... A-D specific data

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

マルチテナント型でサービスを提供する仕組みにおいて、各テナントで固有のデータを個別に分離して保持するとともに、各テナントで共通となるデータを一元的に保持し、これらのデータを各テナントがシームレスに取り扱うことを可能とするサービス提供システムである。データベースは共通スキーマと各テナントにそれぞれ対応した個別スキーマとを有し、共通スキーマには、各テナントが共通にアクセス可能な共通データと、各テナントのみがそれぞれアクセス可能な固有データとを保持する。各個別スキーマにはそれぞれ、共通スキーマ上の実データにアクセスするためのビューを有し、ビューは、テナントの識別情報をパラメータとし、共通データおよび識別情報に対応するテナントに係る固有データのみにアクセス可能である。アプリケーションは、ユーザが利用するテナントを判別し、対応する個別スキーマのビューを介してデータベースにアクセスする。

Description

サービス提供システム
 本発明は、ネットワークを介してユーザにサービスを提供する技術に関し、特に、個別にサービスを提供する事業者が複数相乗りで利用するマルチテナント型のサービス提供システムに適用して有効な技術に関するものである。
 ASP(Application Service Provider)やSaaS(Software as a Service)などにより、企業などの事業者がソフトウェアやアプリケーションの機能をネットワークを介してサービスとして利用者に提供する形態が広く用いられてきている。特に、SaaSのように、システムベンダがデータセンターやクラウド環境上に構築して運用するシステム上に同種のサービスを提供する複数の企業や事業者が相乗りしてサービスを提供する形態のマルチテナント型の仕組みの利用も広がってきている。
 マルチテナント型においても、セキュリティ等の観点から、相乗りする個々のテナントは分離独立して取り扱われる必要があり、各テナントが利用・参照することができるデータは自身に関するものに限られ、他のテナントに関するデータは利用・参照できないようにアクセス制御がされる必要がある。
 マルチテナント型でのサービス提供に関する技術として、例えば、特開2010-26653号公報(特許文献1)には、ログイン要求に基づいてユーザIDを取得し、該ユーザIDに対応するテナントIDをテナントID管理テーブルから取得して識別情報記憶手段に記録するとともに、アプリケーションソフトウェアからデータベースへのアクセス要求を受け付けると、識別情報記憶手段に記録されているテナントIDに基づいて、データベースにおける複数のデータ領域のうち該テナントIDに対応するデータ領域に対するアクセス要求をデータベース管理部に送信することで、利用者ごとに異なるデータ領域を有するデータベースにアクセスするアプリケーションの開発を簡便化させる技術が記載されている。
特開2010-26653号公報
 特許文献1に記載されたような技術を用いることで、マルチテナント型のSaaS等の仕組みにおいて、テナント毎に固有のデータをデータベース上の異なる領域(テーブル等)に保持した上で、アプリケーションがデータベースにアクセスする際のテナント毎の各テーブルへのアクセス制御に係る部分をアプリケーションから隠蔽することができる。また、テナント毎にテーブルを異なるスキーマで構成することについても記載されている。
 しかしながら、特許文献1に記載された技術では、上記のアクセス制御に係る部分をアプリケーションから隠蔽するための機能(特許文献1における図1のマルチテナント制御部14)を開発・実装することが必要となる。
 また、例えば証券会社などの金融機関における業務では、証券取引所や日本銀行等の決済機関など、公共的な役割を有する機関との間で授受されるデータや、通貨に係るデータなど、各社において共通となるデータを取り扱うことが他の業種と比べて多い傾向にある。したがって、マルチテナント型のSaaS等の仕組みにおいて、全てのデータを各テナントで個別に分離して保持するのではなく、各テナントで共通となるデータは一元的に保持して各テナントが利用可能とする方がより効率的である。
 しかしながら、特許文献1に記載された技術を含む従来技術では、このような共通データを含むデータベースの構成を考慮しておらず、各テナントが利用するデータは全て個別に分離して保持する構成となっている。
 そこで本発明の目的は、マルチテナント型でサービスを提供する仕組みにおいて、各テナントで固有のデータを個別に分離して保持するとともに、各テナントで共通となるデータを一元的に保持し、これらのデータを各テナントがシームレスに取り扱うことを可能とするサービス提供システムを提供することにある。
 本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。
 本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。
 本発明の代表的な実施の形態によるサービス提供システムは、複数のテナントが相乗りでユーザに対してネットワークを介して個別にサービスを提供するサービス提供システムであって、前記サービスに係る処理を実行するアプリケーションを有するアプリケーションサーバと、前記処理に用いられるデータをデータベース上に保持するデータベースサーバと、を有する。
 前記データベースは、共通スキーマと、前記各テナントにそれぞれ対応した個別スキーマと、を有し、前記共通スキーマには、前記各テナントが共通にアクセス可能な共通データと、対応する前記各テナントのみがそれぞれアクセス可能な固有データと、を保持し、前記各個別スキーマには、それぞれ、前記共通スキーマ上の実データにアクセスするためのビューを有し、前記ビューは、前記テナントの識別情報をパラメータとし、前記共通データおよび前記識別情報に対応する前記テナントに係る前記固有データのみにアクセス可能である。また、前記アプリケーションは、前記ユーザが利用する前記テナントを判別し、判別した前記テナントに対応する前記個別スキーマの前記ビューを介して前記データベース上のデータにアクセスする。
 本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。
 すなわち、本発明の代表的な実施の形態によれば、マルチテナント型でサービスを提供する仕組みにおいて、各テナントで固有のデータを個別に分離して保持するとともに、各テナントで共通となるデータを一元的に保持し、これらのデータを各テナントがシームレスに取り扱うことが可能となる。
本発明の一実施の形態であるサービス提供システムの構成例について概要を示した図である。
 以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。一方で、ある図において符号を付して説明した部位について、他の図の説明の際に再度の図示はしないが同一の符号を付して言及する場合がある。
 図1は、本発明の一実施の形態であるサービス提供システムの構成例について概要を示した図である。本実施の形態のサービス提供システム1は、例えば、データセンター内のサーバ機器や、クラウドコンピューティング環境上に構築された仮想サーバにより実装された1つ以上のアプリケーションサーバ10および1つ以上のデータベース(DB)サーバ20により構成される。このサービス提供システム1上に複数のテナントが相乗りして共同利用する形で、顧客等のユーザが利用する情報処理端末であるユーザ端末3に対してインターネット等のネットワーク(NW)2を介して各テナントがサービスを提供する。
 アプリケーションサーバ10とDBサーバ20は図示しないネットワークを介して相互に通信することが可能であるが、アプリケーションサーバ10とDBサーバ20とを同一のサーバシステム上に構築してネットワークを介さずにプロセス間通信等により通信する構成とすることも可能である。また、アプリケーションサーバ10とDBサーバ20以外にも、例えば、図示しないWebサーバや負荷分散サーバなどを有していてもよい。
 アプリケーションサーバ10は、図示しないOS(Operating System)やDBMS(DataBase Management System)などのミドルウェア上で稼働するソフトウェアプログラムとして実装されたアプリケーション11や認証部12などの各部を有する。さらに、後述するように一般的なDBMSが有するコネクションプールの機能を利用しており、DBMSの構成要素として実装されているコネクションプール管理部13を有している。
 アプリケーション11は、サービス提供システム1がユーザ端末3に対して提供することができるサービスや業務に係る処理を実装したソフトウェアプログラムである。アプリケーション11の実行により提供するサービス等の内容に応じて具体的な処理内容は様々であるが、少なくともDBサーバ20上に保持されたデータにアクセスする機能を有する。基本的には当該サービス提供システム1を共同利用する各テナント間で共通のプログラムやモジュールによって実装されているものとする。
 認証部12は、例えばアプリケーション11からの要求に応じて、図示しないユーザ管理テーブル等を参照し、ユーザ端末3を利用するユーザがサービス提供システム1により提供されるサービスを利用する権限を有するか否かのユーザ認証を行う。その際に、いずれのテナントのユーザであるかについても判別し、利用対象のテナントの識別情報(例えば「会社コード」や「テナントID」等)についてもアプリケーション11に応答する。アプリケーション11は、サービスに係るトランザクションを発生させる際に、対象のユーザに係るテナントの識別情報を入力パラメータとして指定する。
 コネクションプール管理部13の設定内容については後述する。
 一方、DBサーバ20は、図示しないOSやDBMSなどのミドルウェア上で稼働するデータベースとして、各テナントの固有のデータ(固有データ)を分離して個別のテーブル上に保持するとともに、上述したように、各テナントで共通となるデータ(共通データ)を一元的に保持する。本実施の形態では、一般的なDBMSが有するスキーマ機能によりデータベース上に複数のスキーマを定義することで上記のようなデータ構成を実現する。
 図1の例では、各テナントのデータへのアクセスに対応した個別のスキーマ(図中ではA~Dの4つのテナントに対応したスキーマA(21a)~スキーマD(21d)で示され、以下ではこれらを個別スキーマ21と総称する場合がある)と、共通スキーマ23が定義されている。個別スキーマ21は、図1の例では4つ定義されているが、実際にはサービス提供システム1によりサービスを提供するテナントの数だけ定義される。
 共通スキーマ23には、共通データ24および固有データ(図中ではA~Dの4つのテナントに対応したA固有データ25a~D固有データ25dで示され、以下ではこれらを固有データ25と総称する場合がある)の実体をそれぞれ保持している。これらのデータは、それぞれ別のテーブル等として異なる領域に保持してもよいし、1つのテーブルに共通データ24や複数の固有データ25をまとめて保持してもよい。いずれの場合も、各固有データ25はそれぞれ、対象のテナントを一意に識別する会社コード等の識別情報により特定してアクセスすることができるものとする。
 そして、各個別スキーマ21では、共通スキーマ23上に保持されたデータの実体にアクセスするためのビュー22が定義されている。本実施の形態では、ビュー22は、テナントの識別情報の指定をパラメータとして受け付けることで、テナントに関わらずにアクセス可能な共通データ24と、対象のテナントに係る固有データ25にのみアクセス可能となるように定義されている。
 具体的には、例えば、テナントAに対応したスキーマA(21a)では、テナントAの会社コード等の識別情報が指定されることにより、共通データ24、およびテナントAの識別情報で特定されるA固有データ25aにのみアクセス可能となるよう、DBMSのレイヤーでアクセス範囲が制限される。他のテナントに対応した個別スキーマ21についても同様であり、共通データ24および対象のテナントに対応する固有データ25のみアクセス可能となるようアクセス範囲が制限される。本実施の形態では、アプリケーション11は、このビュー22を介してのみデータベースにアクセスするように実装されているものとする。
 このように、共通スキーマ23上に保持されたデータの実体に対して、アプリケーション11がテナント毎の個別スキーマ21のビュー22を介してのみアクセスするように制限することで、データのアクセス範囲を自身のテナントに関連するもののみに制限することができる。これにより、セキュリティを向上させるとともに、テナント毎のデータ量の相違による他のテナントの処理性能への影響を抑止する。例えば、テナントAの保持するデータ量がテナントBの保持するデータ量の100倍や1000倍などの場合に、テナントAに関連するデータに対する大量のアクセスによってテナントBに関連するデータに対するアクセスが遅延する等の影響が生じ得ることを可能な限り抑止する。
 本実施の形態では、テナント毎にスキーマ(個別スキーマ21)を分けたことに対応して、さらに、アプリケーションサーバ10のコネクションプール管理部13において、個別スキーマ21毎に確立した複数のコネクション(図中ではスキーマA(21a)、スキーマB(21b)にそれぞれ対応したコネクション(スキーマA)(15a)、コネクション(スキーマB)(15b)で示され、以下ではこれらをコネクション15と総称する場合がある)をプーリングしたコネクションプール(図中ではスキーマA(21a)、スキーマB(21b)にそれぞれ対応したコネクションプール(スキーマA)(14a)、コネクションプール(スキーマB)(14b)で示され、以下ではこれらをコネクションプール14と総称する場合がある)を作成するものとしている。
 アプリケーション11は、データベースにアクセスする際に、対象のテナントに対応する個別スキーマ21のコネクションプール14にプーリングされているコネクション15を用いるものとする。これにより、アプリケーション11は、テナントの相違によるアクセス可能なデータの範囲を特に意識することなく、自動的に対象の個別スキーマ21のビュー22にアクセスし、当該ビュー22を介して共通スキーマ23上の共通データ24および自社の固有データ25にのみアクセス可能となるようアクセス制御がされる。
 具体的には、アプリケーション11が使用する各コネクション15には、その属性値として、属する個別スキーマ21に対応するテナントの会社コード等の識別情報が予め設定されており、対象の個別スキーマ21のビュー22では、使用するコネクション15の属性値からテナントの識別情報を取得してパラメータとして用いる。図1の例では、コネクション(スキーマA)15aには属性値に会社コード「001」が設定されており、スキーマA(21a)では、ビュー22がコネクション(スキーマA)15aの属性値からこの会社コード「001」の値を取得してパラメータとして用いる。これにより、アクセス可能なデータの範囲は、共通データ24および自身の会社コード「001」に対応する固有データ25のみに制限される。
 アプリケーション11は、例えば、トランザクションにおける入力情報(テナントを識別することができる情報)に基づいて、利用するコネクションプール14を判定する。例えば、ユーザがアプリケーション11の利用開始時に認証部12を介してユーザ認証を行ったときに、認証部12が当該ユーザが属するテナントの識別情報を併せて応答し、この情報をアプリケーション11のセッションに関連する情報として保持しておく。アプリケーション11は、当該識別情報をトランザクションにおける入力情報として利用する。
 また、アプリケーション11が利用するコネクションプール14の判定については、例えば、アプリケーションサーバ10の起動時にコネクションプール14の識別情報とテナントの識別情報との対応関係を予め作成してメモリテーブル等に保持しておき、アプリケーション11がこれを参照して、ユーザが属するテナントの識別情報に基づいて対応するコネクションプール14を特定する。
 アプリケーション11が実際に使用する各コネクション15には、上述したように属性値にテナントの会社コード等の識別情報が予め設定されている。コネクション15の属性値への識別情報の設定は、例えば、アプリケーションサーバ10の起動時におけるコネクションプール14およびコネクション15の作成時に、DBMSのログオントリガ機能を用いて各コネクション15に対して自動的に設定することができる。
 このように、本実施の形態では、テナント毎にスキーマを分けて、共通データ24と固有データ25でデータのアクセス範囲を制限するのに加えて、スキーマ毎に個別にコネクションプール14を設ける。これにより、アプリケーション11の実装からデータベースアクセスにおけるマルチテナントに係る部分をDBMSのレイヤーで隠蔽して、共通データ24と固有データ25に対するシームレスなアクセスを容易に実現することが可能となる。また、テナント間のセキュリティを向上させるとともに、テナント毎のデータ量の相違に基づく全体の処理性能への影響を低減し、性能向上を図ることができる。
 以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は上記の実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。例えば、上記の実施の形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、上記の実施の形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。
 本発明は、個別にサービスを提供する事業者が複数相乗りで利用するマルチテナント型のサービス提供システムに利用可能である。
1…サービス提供システム、2…ネットワーク、3…ユーザ端末、
10…アプリケーションサーバ、11…アプリケーション、12…認証部、13…コネクションプール管理部、14…コネクションプール、14a、b…コネクションプール(スキーマA、B)、15…コネクション、15a、b…コネクション(スキーマA、B)、
20…DBサーバ、21…個別スキーマ、21a~d…スキーマA~D、22…ビュー、23…共通スキーマ、24…共通データ、25…固有データ、25a~d…A~D固有データ

Claims (3)

  1.  複数のテナントが相乗りでユーザに対してネットワークを介して個別にサービスを提供するサービス提供システムであって、
     前記サービスに係る処理を実行するアプリケーションを有するアプリケーションサーバと、
     前記処理に用いられるデータをデータベース上に保持するデータベースサーバと、を有し、
     前記データベースは、共通スキーマと、前記各テナントにそれぞれ対応した個別スキーマと、を有し、
     前記共通スキーマには、前記各テナントが共通にアクセス可能な共通データと、対応する前記各テナントのみがそれぞれアクセス可能な固有データと、を保持し、
     前記各個別スキーマには、それぞれ、前記共通スキーマ上の実データにアクセスするためのビューを有し、
     前記ビューは、前記テナントの識別情報をパラメータとし、前記共通データおよび前記識別情報に対応する前記テナントに係る前記固有データのみにアクセス可能であり、
     前記アプリケーションは、前記ユーザが利用する前記テナントを判別し、判別した前記テナントに対応する前記個別スキーマの前記ビューを介して前記データベース上のデータにアクセスする、サービス提供システム。
  2.  請求項1に記載のサービス提供システムにおいて、
     前記アプリケーションサーバは、前記アプリケーションが前記データベースにアクセスするためのコネクションを複数プーリングしたコネクションプールを前記個別スキーマ毎に有し、
     前記アプリケーションは、前記ユーザが利用するものとして判別した前記テナントに対応する前記個別スキーマに係る前記コネクションプールを特定し、特定した前記コネクションプールに含まれる前記コネクションを利用して前記データベースにアクセスする、サービス提供システム。
  3.  請求項2に記載のサービス提供システムにおいて、
     前記コネクションの属性値には、前記コネクションに係る前記個別スキーマに対応する前記テナントの識別情報が設定されている、サービス提供システム。
PCT/JP2015/083181 2015-11-26 2015-11-26 サービス提供システム WO2017090142A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2017504838A JPWO2017090142A1 (ja) 2015-11-26 2015-11-26 サービス提供システム
PCT/JP2015/083181 WO2017090142A1 (ja) 2015-11-26 2015-11-26 サービス提供システム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2015/083181 WO2017090142A1 (ja) 2015-11-26 2015-11-26 サービス提供システム

Publications (1)

Publication Number Publication Date
WO2017090142A1 true WO2017090142A1 (ja) 2017-06-01

Family

ID=58763229

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2015/083181 WO2017090142A1 (ja) 2015-11-26 2015-11-26 サービス提供システム

Country Status (2)

Country Link
JP (1) JPWO2017090142A1 (ja)
WO (1) WO2017090142A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112889054A (zh) * 2019-01-31 2021-06-01 易享信息技术有限公司 多租户数据库管理系统中数据库加密的系统和方法
EP4332746A1 (en) 2022-08-29 2024-03-06 Fujitsu Limited Data processing method and data processing program

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004303051A (ja) * 2003-03-31 2004-10-28 Nippon Digital Kenkyusho:Kk データ管理方法、データ管理装置、情報処理装置、及び通信ネットワークシステム
JP2006268265A (ja) * 2005-03-23 2006-10-05 Dainippon Printing Co Ltd データベースシステム、データベースサーバ、プログラム、及び、記録媒体
JP2009145972A (ja) * 2007-12-11 2009-07-02 Hitachi Information Systems Ltd データべースシステム及びデータべースシステムの制御方法
JP2013182310A (ja) * 2012-02-29 2013-09-12 Mitsubishi Electric Corp アクセス制御装置及びアクセス制御方法及びプログラム

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004303051A (ja) * 2003-03-31 2004-10-28 Nippon Digital Kenkyusho:Kk データ管理方法、データ管理装置、情報処理装置、及び通信ネットワークシステム
JP2006268265A (ja) * 2005-03-23 2006-10-05 Dainippon Printing Co Ltd データベースシステム、データベースサーバ、プログラム、及び、記録媒体
JP2009145972A (ja) * 2007-12-11 2009-07-02 Hitachi Information Systems Ltd データべースシステム及びデータべースシステムの制御方法
JP2013182310A (ja) * 2012-02-29 2013-09-12 Mitsubishi Electric Corp アクセス制御装置及びアクセス制御方法及びプログラム

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112889054A (zh) * 2019-01-31 2021-06-01 易享信息技术有限公司 多租户数据库管理系统中数据库加密的系统和方法
JP2021533619A (ja) * 2019-01-31 2021-12-02 セールスフォース ドット コム インコーポレイティッド マルチテナントデータベース管理システムにおけるデータベース暗号化のシステム及び方法
JP7193615B2 (ja) 2019-01-31 2022-12-20 セールスフォース ドット コム インコーポレイティッド マルチテナントデータベース管理システムにおけるデータベース暗号化のシステム及び方法
CN112889054B (zh) * 2019-01-31 2023-07-04 硕动力公司 多租户数据库管理系统中数据库加密的系统和方法
US11841967B2 (en) 2019-01-31 2023-12-12 Salesforce, Inc. Systems and methods of database encryption in a multitenant database management system
EP4332746A1 (en) 2022-08-29 2024-03-06 Fujitsu Limited Data processing method and data processing program

Also Published As

Publication number Publication date
JPWO2017090142A1 (ja) 2018-09-13

Similar Documents

Publication Publication Date Title
JP6491774B2 (ja) マルチテナントアイデンティティおよびデータセキュリティ管理クラウドサービス
US20210217001A1 (en) Decentralized tokenization technologies
US9503501B2 (en) Cross domain in-browser proxy
JP6417472B2 (ja) 共通エンドポイントにアクセスするために異なるディレクトリに記憶される認証情報を使用すること
US10152577B2 (en) Cross tenant data access
US10320773B2 (en) Validation for requests
US11411921B2 (en) Enabling access across private networks for a managed blockchain service
US11962511B2 (en) Organization level identity management
CN112005264A (zh) 实施跨链事务的区块链
JP2019532368A (ja) マルチテナントアイデンティティクラウドサービスのためのデータ管理
US20130080514A1 (en) System and method for auto-tab completion of context sensitive remote managed objects in a traffic director environment
US20100306393A1 (en) External access and partner delegation
US11783071B2 (en) Authenticating accesses to a shared datastore of a multi-tenant computer system
CN104376272A (zh) 一种云计算企业信息系统及该系统的用户权限设定方法
WO2017090142A1 (ja) サービス提供システム
US20240095055A1 (en) Endpoints for virtual private label clouds
US11102140B2 (en) Abstraction layer to cloud services
US10623370B1 (en) Secure data flow for virtual workspaces
US10628594B2 (en) Managing multi-tenant systems using object-oriented models
US11297065B2 (en) Technology for computing resource liaison
JP5732419B2 (ja) 統合アクセス制御システム
Saraswathi et al. Multitenant SaaS model of cloud computing: issues and solutions
US11579901B1 (en) Provisioning engine hosting solution for a cloud orchestration environment
Nagesh et al. Design Issues in Cloud-Hosted Applications
US20140067480A1 (en) Systems and methods for enterprise-level context management

Legal Events

Date Code Title Description
ENP Entry into the national phase

Ref document number: 2017504838

Country of ref document: JP

Kind code of ref document: A

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15909261

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15909261

Country of ref document: EP

Kind code of ref document: A1