JP2013190971A - 統合アクセス制御システム - Google Patents

Abstract

【課題】複数のシステム環境を組み合わせて構築される情報処理システムにおいて、アプリケーションの各層での認証やアクセス制御の機能を各システム環境間でシームレスに利用することを可能とする。
【解決手段】個別システム３と共通システム４と外部システム２とを含むシステム環境上で稼働する情報処理システムにおいて各層の機能に対するアクセスの制御もしくは認証を行う統合アクセス制御システム１であって、個別システム３および外部システム２において、プレゼンテーション層２０により提供される画面へのアクセスに対して、ユーザおよびチャネルの少なくとも１つに基づいて認証処理を行う認証処理部と、ログイン数に応じて新たなユーザのログインを制限するログイン制御部とを有する認証制御部１０と、外部システム２により提供される画面へのアクセスの際に個別システム３にアクセスした際の認証結果を連携させるための認証連携ＩＦ２１とを有する。
【選択図】図１

Description

本発明は、情報処理システムの構築および運用管理の技術に関し、特に、クラウドコンピューティング環境を含む複数のシステム環境にまたがる情報処理システムにおけるアクセス制御を管理・支援する統合アクセス制御システムに適用して有効な技術に関するものである。

企業等が情報処理システムを構築する際、従来は、ＳＩ（System Integration）等により固有のシステムを一から開発して構築したり、同様の既存システムに対してカスタマイズ等を行なって横展開したりするのが一般的であった。しかし、近年では、例えば、クラウドコンピューティング環境により提供される各種のサービス（ソフトウェア、プラットフォーム、インフラなど）を有効活用し、作る開発から、作らない、もしくは利用する開発手法を積極的に採用することにより、システム開発や運用にかかるコストを削減することが望まれ、今後もそのような傾向はより強くなるものと考えられる。

このような情報処理システムでは、複数のシステムやサービスを組み合わせることで、全体のシステムやサービスが構築される。また、ユーザがシステムを利用する入り口となる手段、すなわち、企業がユーザと接触するためのチャネルについても、様々に多様化している。例えば、デバイスについては、従来のＰＣ（Personal Computer）上のＷｅｂブラウザからのサイトへのアクセスによるものだけではなく、いわゆるタブレット型端末やスマートフォンなどの携帯型端末、テレビやキオスク端末など、種々のものがあり得る。また、サービスについても、ホームページ上での提供に限らず、Ｗｅｂサイト上での広告やデジタルサイネージ、ＳＮＳ（Social Networking Service）サイト、音声応答システムなど様々である。また、ユーザがアクセスする時間帯や、ユーザの属性（例えば、一般ユーザ／優良ユーザや、店舗窓口担当者、渉外営業員など）・権限なども様々である。

このように、複数のシステムやサービスが組み合わされた情報処理システムに対して、多様なチャネルやユーザからアクセスが行われるようになると、各システムやサービスにおけるアクセス制御や認証について適切に管理する仕組みが必要となってくる。

例えば、特開２０１０−３９７６３号公報（特許文献１）には、複数のサービスをＷｅｂサーバを介してクライアント端末に提供するサーバシステムにおいて、Ｗｅｂサーバは、セッション管理テーブルと、サービス時間管理テーブルと、クライアント端末から利用要求を受けたサービスについて、サービス時間管理テーブルが保持する情報と現在時刻との比較に基づいて前記サービスの提供可否を判定するサービス制御部とを有し、サービス制御部にて前記サービスが提供不可であると判定した場合は、前記サービスが提供不可である旨の応答をクライアント端末に対して送信することで、提供可能な時間帯やユーザの権限等が異なる複数のサービスを提供するサーバシステムにおいて、提供不可であるサービスに対してアクセスがあった場合でも、アプリケーションサーバに余計なアクセスが発生しないように制御する技術が記載されている。

特開２０１０−３９７６３号公報

上述したように、近年では、情報処理システムの構築の際、従来は固有のシステムとして一から開発していた構成要素のうち、可能なものについては、例えば、企業内でのいわゆるプライベート・クラウドや、さらには外部のパブリック・クラウドなどによって提供されるサービスを利用する構成として、これらを組み合わせてシステムを構築することで、開発や運用のコストを低減させようとする傾向が強くなってきている。

一方で、情報処理システムによって提供するサービスや業務の内容、システムの特性などの各種要因から、システムの構成要素の全てをパブリック・クラウドなどの外部のサービスを利用して構築する、もしくは既存のシステムの全体をこれらの外部のサービスに移行・移管するというようなことは困難である。実際上は、パブリック・クラウドなどによって提供される外部のサービスを積極的に利用しつつも、一方で、いわゆるオンプレミス型のシステムやプライベート・クラウド上で構築、提供されるシステムやサービスも残ることになる。すなわち、情報処理システムはこれらを必要に応じて組み合わせた形で構築されることになる。

例えば、通常の情報系システムや、汎用的なＩＴサービス（例えば、メールサービスやＳＮＳサービス、オフィス用アプリケーションやツール、業界や業種に固有の一般的業務処理やサービス）などについては、外部のパブリック・クラウドを利用して提供する傾向が強くなる一方で、取引処理を行う基幹系システムや重要情報を取り扱う情報系システムなどは、オンプレミス型のシステムやプライベード・クラウド上で構築される、というように組み合わせられることになる。

これらの複数のシステム環境（オンプレミス型システムや、プライベート／パブリック・クラウドなど）の間では、インフラの層からアプリケーションの層に至るまで、それぞれインタフェースが異なっていたり、同様な機能がそれぞれ異なる形で実装されていたりする場合が多い。例えば、上述したような、各システムや機能に対する認証やアクセス制御についても、各層において各システム環境間でそれぞれ異なる形で認証機能やアクセス制御の機能が独自に実装されている場合が多い。

従って、情報処理システムの構築や運用管理を効率的にし、コスト削減の効果を確実に得るためには、これらのシステム環境間にまたがった形で、システム環境間の相違をアプリケーションの実行や運用管理の仕組みから可能な限り隠蔽して、シームレスに利用することができるよう支援する仕組みを提供するのが望ましい。この点、上述した特許文献１に記載された技術は、外部システムとの連携についての考慮はされているものの、主に固有のシステム内でのいわゆる３層構造アーキテクチャにおける複数のサービスの連携を対象としたものであり、上述したような複数のシステム環境からなる構成における適用について詳細には言及されていない。

そこで本発明の目的は、異なる複数のシステム環境を組み合わせて構築される情報処理システムにおいて、アプリケーションプログラムの階層モデルにおける各層での認証やアクセス制御の機能を各システム環境間でシームレスに利用することを可能とする統合アクセス制御システムを提供することにある。

本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。

本発明の代表的な実施の形態による統合アクセス制御システムは、自社により運用され、１つ以上のサービスを提供する個別システムと、１つ以上のサービスから共通で利用されるサービスを提供する共通システムと、自社の外部においてサービスを提供する外部システムと、を含む複数のシステム環境上で稼働するソフトウェアの連携により業務サービスを提供する階層モデルからなるアプリケーションプログラムを有する情報処理システムにおいて、前記アプリケーションプログラムの各層の機能に対するアクセスの制御もしくは認証を行う統合アクセス制御システムであって、以下の特徴を有するものである。

すなわち、統合アクセス制御システムは、前記個別システムおよび前記外部システムにおいて、前記アプリケーションプログラムにおけるプレゼンテーション層により提供される画面へのアクセスに対して、ユーザおよびユーザがアクセスのために利用しているチャネルの少なくとも１つに基づいて認証処理を行う認証処理部と、前記認証処理部でのユーザ認証を介してログインしたユーザの数に応じて新たなユーザのログインを制限するログイン制御部と、を有する認証制御部と、前記外部システムにより提供される画面へのアクセスの際に、前記個別システムにアクセスした際の認証結果を前記外部システムに対して連携させるための認証連携インタフェース部とを有することを特徴とするものである。

本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。

すなわち、本発明の代表的な実施の形態によれば、異なる複数のシステム環境を組み合わせて構築される情報処理システムにおいて、アプリケーションプログラムの階層モデルにおける各層での認証やアクセス制御の機能を各システム環境間でシームレスに利用することが可能となる。

本発明の一実施の形態である統合アクセス制御システムの構成例について概要を示した図である。 パブリック・クラウドの利用が拡大している状況と、情報処理システムおよびその運用管理の仕組みの構成について概要を示した図である。 本発明の一実施の形態における認証制御部およびプレゼンテーション層に係る部分の構成例について概要を示した図である。 本発明の一実施の形態におけるサービスアクセス制御部およびサービス層に係る部分の構成例について概要を示した図である。 本発明の一実施の形態におけるモジュールアクセス制御部およびモジュール層に係る部分の構成例について概要を示した図である。 本発明の一実施の形態におけるデータアクセス制御部およびデータ層に係る部分の構成例について概要を示した図である。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。

＜概要＞
上述したように、近年では、情報処理システムの構築の際、従来は固有のシステムとして一から開発していた構成要素のうち、可能なものについては、プライベート・クラウドや、さらには外部のパブリック・クラウドなどによって提供されるサービスを利用する構成として、これらを組み合わせてシステムを構築することで、開発や運用のコストを低減させようとする傾向が強くなってきている。

図２は、パブリック・クラウドの利用が拡大している状況と、情報処理システムおよびその運用管理の仕組みの構成について概要を示した図である。図２に示すように、企業等の内部におけるオンプレミス型やプライベート・クラウドを利用したシステムでは、ファシリティからハードウェア／ＯＳ（Operating System）、ミドルウェア、アプリケーションに至るまで、全てを自社開発する必要がある（枠内の網掛けが自社開発であることを示す）。一方、パブリック・クラウドを利用する場合、いわゆるＩａａＳ（Infrastructure as a Service）やＰａａＳ（Platform as a Service）、ＳａａＳ（Software as a Service）などのサービス形態によってそれぞれ提供される部分の開発が不要となるため、開発コストを低減させることが可能である。

一方で、上述したように、情報処理システムによって提供するサービスや業務の内容やシステムの特性などの各種要因から、システムの構成要素の全てをパブリック・クラウドなどの外部のサービスを利用して構築するということは困難であり、実際上は、パブリック・クラウドなどによって提供される外部のサービスを積極的に利用しつつも、一方で、オンプレミス型のシステムやプライベート・クラウド上で構築、提供されるシステムやサービスも残ることになり、これらを連携させて組み合わせた形で情報処理システムが構築されることになる。

従って、外部のシステムやサービスを利用することで情報処理システムの構築や運用管理を効率的にし、これによるコスト削減の効果を確実に得るためには、これらのシステム環境間をまたがった形で、システム環境間の相違をアプリケーションや運用管理の仕組みから可能な限り隠蔽して、シームレスに利用することができるよう支援する仕組みを提供することが要望される。

そこで、本発明の一実施の形態である統合アクセス制御システムは、例えば、ＳＩなどにより開発した個別システム（オンプレミス型もしくはプライベート・クラウドの利用）と、複数の個別システムやチャネル間で共通に利用可能なサービスを提供する共通システム、およびＳａａＳ等によってサービスを提供する外部システムの複数のシステム環境を連携させて組み合わせた形で構築される情報処理システムにおいて、各システム環境の間にまたがって、アプリケーションプログラムの階層モデルにおける各層での認証やアクセス制御の機能を各システム環境間でシームレスに利用することを可能とするための機能やインタフェースからなるサービスを提供するシステムである。

本実施の形態により提供される統合アクセス制御サービスの他にも、同様のコンセプトから、例えば、ビジネスやサービスにおいて所定のサービスレベルが達成されるよう各システム環境間で連携して運用監視するサービスや、各システム環境間でシームレスにデータの連携を行うサービス、離れた拠点間にある各システム環境間で災害対策も含めたＢＣＰ（Business Continuity Plan：事業継続計画）を実現するために連携するためのサービス、インフラレベルでの連携や運用管理などのサービス等を提供するシステムを構築することが可能である。

＜システム構成＞
図１は、本発明の一実施の形態である統合アクセス制御システムの構成例について概要を示した図である。図１の例では、外部システム２、個別システム３および共通システム４を組み合わせて（またがって）構築された業務システムを例としている。当該業務システムは、システム利用の入り口であるチャネルとしてフロント業務５やミドル・バック業務６を有し、ユーザは、これらの業務を実施するために、多様なデバイスからインターネットやイントラネット等のネットワーク７を介して当該情報処理システムにアクセスする。なお、ここでのユーザには、顧客以外に、例えば、オペレータや支店の職員、バックオフィサなど、当該情報処理システムにより顧客に対してサービスを提供する企業側のユーザに加え、例えば、個人のファイナンシャルアドバイザー（ＦＡ）などの契約社員、仲介業者（例えば、証券業の場合は銀行代理店など）のユーザなども含まれる。

フロント業務５に含まれるチャネルとしては、例えば、顧客がＷｅｂブラウザを介して当該企業等のＷｅｂサイトなどを経由して情報処理システムにアクセスするネットチャネルや、顧客がコールセンタのオペレータに電話をし、オペレータがその対話内容に基づいて情報処理システムにアクセスするコールセンタチャネル、顧客が支店等に赴いて支店職員と対話し、支店職員がその対話内容に基づいて情報処理システムにアクセスする支店チャネルなどがある。顧客に対して個人のＦＡや仲介業者等が商品販売する際にＦＡや仲介業者の職員が情報処理システムにアクセスするチャネルなども想定される。また、ミドル・バック業務６に含まれるチャネルとしては、例えば、支店職員や本店職員などのバックオフィサが、共通サービスを利用するために情報処理システムにアクセスする本社・支店チャネルなどがある。

本実施の形態の統合アクセス制御システム１は、このように多様なチャネルやユーザからアクセスが行われるような場合に、ユーザやチャネルの種別や属性等に応じて、情報処理システムにおいて利用可能なメニューやサービス、取り扱うことができるデータなどを適宜制限できるようにするための認証やアクセス制御の仕組みを提供するものである。

本実施の形態では、情報処理システムは、プレゼンテーション層２０、サービス層４０、モジュール層６０、およびデータ層８０の４層からなる階層構造アーキテクチャを有する。プレゼンテーション層２０は、画面（コンテンツ）を含むユーザインタフェースを提供する層であり、アプリケーションのフロントエンドとしてチャネル毎に個別に提供され、例えば、Ｗｅｂアプリケーションにおける「画面」として、ＰＣや携帯型端末などの各デバイスやメディアに対して、それぞれに適した様々な形態により実装される。各画面コンテンツは、例えば、外部システム２ではＳａａＳやパッケージソフトウェアにより提供される画面であり、個別システム３ではＳＩなどにおいてマルチベンダにより開発された画面（後述するモジュール（ソフトウェアプログラム）の開発と合わせて一括して開発される）である。

サービス層４０は、ユーザが利用可能なサービスを提供する層であり、チャネル毎に個別に提供される。サービスでの実際の処理内容は、後述するモジュール（ビジネスロジック）とデータによる処理により実現される。個別システム３で提供されるサービスの形態は、大きく２種類に分類される。１つは「フロント完結型サービス」であり、チャネル毎の固有性が高く、対応するモジュールとデータが個別システム３において個別に実装されているタイプのサービスである。もう１つは「中継型サービス」であり、共通システム４により提供されるチャネル間で共通のサービスに係るモジュール（ビジネスロジック）を呼び出し、処理結果をチャネル固有のサービスに対して連携させる機能を有する。なお、外部システム２で提供される外部サービスについてはフロント完結型サービスと同様の形態となる。

モジュール層６０およびデータ層８０は、サービスにおける業務処理の内容を規定したビジネスロジック（モジュール）と利用するデータをそれぞれ提供する層である。個別システム３では、チャネル毎のサービスに対応して個別に実装・定義され、ＳＩなどにおいてマルチベンダにより開発される。一方、共通システム４では、各チャネルからのアクセスに対して共通に利用される基本的な共通サービスに係るモジュールとデータがそれぞれ実装・定義される。共通サービスは、チャネル固有の特徴やプロセスロジックを廃し、再利用性の高いシンプルな形で提供されるものとし、例えば、個別システム３の中継型サービスから呼び出されるビジネスロジックが中心のオンラインサービスと、他の個別システム３等のサービスやデータに対して自身のデータを転送して連携させるバッチサービスとに分類される。

上記のような情報処理システムの各層に対して、統合アクセス制御システム１は、ミドルウェアとして、例えば、認証制御部１０、サービスアクセス制御部３０、モジュールアクセス制御部５０、およびデータアクセス制御部７０などの各部を有する。また各層で共通なアクセスや制御を可能とするためのインタフェース（以下では「ＩＦ」と記載する場合がある）として、例えば、認証連携ＩＦ２１、コンテンツ連携ＩＦ２２、外部サービス連携ＩＦ４１、モジュール連携ＩＦ６１、およびデータ連携ＩＦ８１などの各インタフェースを有する。

認証制御部１０は、ユーザ認証に係る機能について、外部システム２と個別システム３のプレゼンテーション層２０に対して共通のシステム基盤を提供するミドルウェアである。図３は、認証制御部１０およびプレゼンテーション層２０に係る部分の構成例について概要を示した図である。認証制御部１０は、複数種類のクライアントの形態やデバイスに対応するよう実装され、例えば、認証処理部１１、不正検知部１２、およびログイン制御部１３などの各部を有する。

認証処理部１１は、ユーザからの認証（ログイン）要求に対して、ユーザのアカウント情報等を保持するユーザ管理テーブル９２を参照してユーザ認証処理を行う。このときさらに、ユーザがアクセスに利用しているチャネルの内容に基づいて、チャネル毎の認証の可否に係る情報を保持するチャネル管理テーブル９１を参照することで、ユーザとチャネルの内容の少なくとも１つに基づいて認証可否を判断するようにしてもよい。例えば、コールセンタなど特定のチャネルが障害その他の理由により利用できない場合に、チャネル管理テーブル９１にその旨を設定することで、特定のチャネルからのアクセスを一律に制限することができる。また、ユーザ管理テーブル９２での保持内容を拡張することで、例えば、ユーザ毎に利用可能なチャネルを制限するような制御も可能である。なお、本実施の形態で用いられる各テーブルは、例えば、データベースやファイルテーブルなどにより適宜実装されるものとする。

不正検知部１２は、ユーザの認証要求に対して、なりすましその他の詐欺的な不正アクセスであるか否かを判定する。不正アクセスか否かの判定手法については一般的に用いられている公知の手法を適宜用いることができる。

ログイン制御部１３は、情報処理システムに対する負荷を制御するため、ログインしているユーザの数を一定数に制限する。すなわち、ログインしているユーザの数を常時把握しておき、一定数に達している場合は、ユーザからの新たな認証要求に対して認証を拒否するとともに、混雑している旨を表示する画面を応答させる。このとき、例えば、ログイン可能なユーザの数を、ユーザの属性や利用しているチャネル毎に個別に設定可能とし、一般ユーザが混雑のためログイン拒否されるような場合でも、優良顧客や重要なチャネルについてはログインを許可するというような制御を行うことも可能である。

一方、プレゼンテーション層２０では、外部システム２により提供される画面に対するアクセスの際に、認証処理部１１での認証結果（個別システム３にアクセスした際の認証結果）に基づくシングルサインオン（ＳＳＯ：Single Sign-On）を実現するための外部インタフェースとして認証連携ＩＦ２１を有する。ＳＳＯの実現手法については一般的に用いられている公知の手法を適宜用いることができる。また、個別システム３により提供される画面が外部システム２により提供される画面と連携するための外部インタフェースとしてコンテンツ連携ＩＦ２２を有する。ここでは、例えば、いわゆるマッシュアップの手法により、個別システム３により提供される画面（コンテンツ）に外部システム２により提供される画面を組み合わせることで両者を連携させる。

なお、いずれのインタフェースについても、個別システム３における画面やユーザインタフェースとの統一性や、プロセスの連続性を考慮したインタフェースとなるよう考慮して実装されるものとし、外部システム２はこれらのインタフェースに適合するように実装することができるものとする。

上記の構成により、ユーザが利用するチャネルからのプレゼンテーション層２０（画面）へのアクセス要求に対して、認証制御部１０での１回のユーザ認証を経た後、アクセス対象に応じて外部システム２もしくは個別システム３により提供される画面を呼び出すとともに、個別システム３により提供される画面は、ユーザによる操作内容などに応じてコンテンツ連携ＩＦ２２により外部システム２により提供される画面を呼び出すことで適宜連携することが可能となる。

図１に戻り、サービスアクセス制御部３０は、サービスの実行処理に係る機能について、外部システム２と個別システム３のサービス層４０に対して共通のシステム基盤を提供するミドルウェアである。図４は、サービスアクセス制御部３０およびサービス層４０に係る部分の構成例について概要を示した図である。サービスアクセス制御部３０は、マルチベンダにより開発されたサービスに対応するよう実装され、例えば、アクセス制御部３１、およびサービスキャパシティ制御部３２などの各部を有する。

アクセス制御部３１は、プレゼンテーション層２０（画面）からのサービスへのアクセス要求（すなわち業務処理の実行要求）に対して、チャネル管理テーブル９１、ユーザ管理テーブル９２、およびサービス毎の利用可能時間（サービスの提供時間）を含むサービスの提供状況に係る情報を保持するサービス管理テーブル９３を参照して、サービスへのアクセスの可否を判定するアクセス制御を行う。すなわち、サービスの利用を要求しているユーザおよびその利用チャネル、さらに時刻情報の少なくとも１つに基づいてアクセスの可否を判断する。

例えば、資産運用状況の参照などの特定のサービスが障害その他の理由により利用できない場合に、サービス管理テーブル９３にその旨を設定することで、特定のサービスに対するアクセスを一律に制限することができる。また、現在時刻（もしくはユーザが要求したときの時刻）が対象のサービスの利用可能時間帯の外の場合は当該サービスへのアクセスを拒否するという制御が可能である。これにより、２４時間（３６５日）でサービスを提供するものについてはこれを可能としつつ、サービス利用可能時間帯以外のサービスについては不要なアクセスを抑制することができ、サービス提供の２４時間化に効率的かつ効果的に対応することができる。また、ユーザとチャネル、時間帯の組み合わせに応じてアクセス可能なサービスを制限するような制御も可能である。

サービスキャパシティ制御部３２は、情報処理システムに対する負荷を制御するため、実行中（提供中）のサービスの数を一定数に制限する。すなわち、実行中のサービスの数を常時把握しておき、一定数に達している場合は、サービスへのアクセス要求に対して拒否するとともに混雑しているため処理を行わない旨を応答させる。このとき、例えば、実行可能なサービスの数を、ユーザの属性や利用しているチャネル毎に個別に設定可能とし、一般ユーザが混雑のためサービスの実行を拒否されるような場合でも、優良顧客や重要なチャネルについてはサービスの実行を許可するというような制御を行うことも可能である。

一方、サービス層４０では、外部システム２により提供される各サービスを呼び出すための共通の外部インタフェースとして外部サービス連携ＩＦ４１を有する。外部システム２はこのインタフェースに適合するように実装することができるものとする。また、個別システム３により提供される各サービスについては、マルチベンダにより開発されることが想定されるが、サービスアクセス制御の観点から、個別システム３により提供される各サービスを呼び出すために、外部サービス連携ＩＦ４１と同様の共通の内部インタフェース（図示しない）を有していてもよい。

上記の構成により、外部システム２のプレゼンテーション層２０により提供される画面からの各サービスへのアクセス要求に対しては、アクセスの可否を判断し、外部システム２により提供されるサービスを適宜呼び出すとともに、個別システム３のプレゼンテーション層２０により提供される画面からの各サービスへのアクセス要求に対しては、アクセスの可否を判断し、要求内容に応じて外部システム２もしくは個別システム３により提供されるサービスを適宜呼び出すという形で連携することが可能である。

図１に戻り、モジュールアクセス制御部５０は、サービス内容を実現するためのモジュールの実行処理に係る機能について、個別システム３と共通システム４のモジュール層６０に対して共通のシステム基盤を提供するミドルウェアである。図５は、モジュールアクセス制御部５０およびモジュール層６０に係る部分の構成例について概要を示した図である。モジュールアクセス制御部５０は、マルチベンダにより開発されたＩＴサービスを提供するモジュールに対応するよう実装され、例えば、アクセス制御部５１、およびシステムキャパシティ制御部５２などの各部を有する。

アクセス制御部５１は、サービス層４０からのモジュールへのアクセス要求（すなわちサービスに係る処理の実行要求）に対して、チャネル管理テーブル９１、ユーザ管理テーブル９２、およびモジュール毎のアクセス権に係る情報を含む情報を保持するモジュール管理テーブル９４を参照して、モジュールへのアクセスの可否を判定するアクセス制御を行う。すなわち、モジュール（これにより提供されるサービス）の利用を要求しているユーザと利用チャネルの内容の少なくとも１つに基づいてアクセスの可否を判断する。

例えば、取引履歴照会などの特定のサービスにおいて特定の機能を実現するモジュールが障害その他の理由により利用できない場合に、モジュール管理テーブル９４にその旨を設定する（アクセスを許可しない設定をする）ことで、特定のサービスにおける特定のモジュール（機能）に対するアクセスを一律に制限することができる。また、ユーザとチャネルの組み合わせに応じてアクセス可能なモジュールを制限するような制御も可能である。

システムキャパシティ制御部５２は、情報処理システムに対する負荷を制御するため、モジュールを実行するサーバのＣＰＵやネットワーク帯域の使用率、レスポンスタイムなどのシステムのパフォーマンス／キャパシティについての測定情報に基づいてモジュールへのアクセスの許否を判断することで、当該情報処理システムにおけるトラフィック量を制限する。なお、パフォーマンス／キャパシティに係る情報の測定手法については、一般的に用いられる公知の手法を適宜用いることができる。

一方、モジュール層６０では、個別システム３および共通システム４により提供される各モジュールについては、マルチベンダにより開発されることが想定されるが、モジュールアクセス制御の観点から、個別システム３および共通システム４により提供される各モジュールを呼び出すために共通の内部インタフェースとしてモジュール連携ＩＦ６１を有する。共通システム４により提供されるモジュールに対するインタフェースは、当該モジュール（および当該モジュールが利用するデータ）の再利用性を向上させるよう考慮して実装されるのが望ましい。

上記の構成により、個別システム３のサービス層４０により提供される各サービスからの各モジュールへのアクセス要求に対して、アクセスの可否を判断し、アクセス対象に応じて個別システム３もしくは共通システム４により提供されるモジュールを適宜呼び出すという形で連携することが可能である。

図１に戻り、データアクセス制御部７０は、サービス内容を実現するためのモジュールの実行の際に利用されるデータについて、個別システム３と共通システム４のデータ層８０に対して共通のシステム基盤を提供するミドルウェアである。図６は、データアクセス制御部７０およびデータ層８０に係る部分の構成例について概要を示した図である。データアクセス制御部７０は、各サービスの実行処理において利用されるデータに対応するよう実装され、例えば、アクセス制御部７１、およびシステムキャパシティ制御部７２などの各部を有する。

アクセス制御部７１は、モジュール層６０からのデータへのアクセス要求に対して、ユーザ管理テーブル９２、およびデータ毎のアクセス（利用）の可否を含む情報を保持するデータ管理テーブル９５を参照して、データへのアクセスの可否を判定するアクセス制御を行う。すなわち、データの利用を要求しているユーザの属性等に応じてアクセスの可否を判断する。

例えば、取引履歴データなどの特定のデータが障害その他の理由により利用できない場合に、データ管理テーブル９５にその旨を設定することで、特定のデータに対するアクセスを一律に制限することができる。また、ユーザ毎にアクセス可能なデータを制限するような制御も可能である。また、ユーザがオペレータや支店の職員など、当該情報処理システムによるサービスの提供側の者である場合、さらに、対応している顧客の属性（例えば、一般顧客か優良顧客かなど）に応じてアクセス可能なデータを制限するような制御も可能である。

システムキャパシティ制御部７２は、情報処理システムに対する負荷を制御するため、データを保持するサーバのＣＰＵやネットワーク帯域の使用率、レスポンスタイムなどのシステムのパフォーマンス／キャパシティについての測定情報に基づいてデータへのアクセスの許否を判断することで、情報処理システムにおけるトラフィック量を制限する。なお、パフォーマンス／キャパシティに係る情報の測定手法については、一般的に用いられる公知の手法を適宜用いることができる。

一方、データ層８０では、顧客がいずれのチャネルを利用しても同様の情報や処理結果を得ることができるよう、共通システム４が保持するデータを個別システム３のデータに転送して連携するための内部インタフェースとしてデータ連携ＩＦ８１を有する。個別システム３のデータに対する連携だけではなく、外部システム２のデータに転送するための外部インタフェース（図示しない）を有して、外部システム２により提供されるサービスと連携可能なように構成してもよい。なお、上述したように、これらのデータ連携は、例えば、共通システム４が提供するバッチサービスにより定期的なバッチ処理として実行される。

上記の構成により、個別システム３および共通システム４のモジュール層６０の各モジュールからのデータへのアクセス要求に対して、アクセスの可否を判断し、また、共通システム４が保持するデータを個別システム３（および／または外部システム２）が保持するデータに転送するという形で連携することが可能である。

以上に説明したように、本発明の一実施の形態である統合アクセス制御システム１によれば、例えば、ＳＩなどにより開発した個別システム３と、複数の個別システム３やチャネル間で共通に利用可能なサービスを提供する共通システム４、およびＳａａＳ等によってサービスを提供する外部システム２の複数のシステム環境を組み合わせて構築される情報処理システムにおいて、各システム環境の間をまたがって、アプリケーションプログラムの階層モデルにおける各層での認証やアクセス制御の機能を各システム環境間でシームレスに利用することを可能とするための一連の機能やインタフェースからなるサービスを提供することが可能となる。

これにより、情報処理システムの構築の際に、固有のシステムに対して、プライベート・クラウドや、さらには外部のパブリック・クラウドなどによって提供されるサービスを適宜組み合わせて構築することを支援し、情報処理システムの開発や運用のコストを大きく低減させることが可能となる。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。

例えば、アプリケーションプログラムの各層に対応する処理部（認証制御部１０、サービスアクセス制御部３０、モジュールアクセス制御部５０、データアクセス制御部７０）およびインタフェース（認証連携ＩＦ２１、コンテンツ連携ＩＦ２２、外部サービス連携ＩＦ４１、モジュール連携ＩＦ６１、データ連携ＩＦ８１）は、全てが必須の構成要素というものではなく、情報処理システムの規模や提供するサービス内容などに応じて必要な構成要素のみを適宜組み合わせて実装することも可能である。

本発明は、クラウドコンピューティング環境を含む複数のシステム環境にまたがる情報処理システムにおけるアクセス制御を管理・支援する統合アクセス制御システムに利用可能である。

１…統合アクセス制御システム、２…外部システム、３…個別システム、４…共通システム、５…フロント業務、６…ミドル・バック業務、７…ネットワーク、
１０…認証制御部、１１…認証処理部、１２…不正検知部、１３…ログイン制御部、
２０…プレゼンテーション層、２１…認証連携インタフェース（ＩＦ）、２２…コンテンツ連携インタフェース（ＩＦ）、
３０…サービスアクセス制御部、３１…アクセス制御部、３２…サービスキャパシティ制御部、
４０…サービス層、４１…外部サービス連携インタフェース（ＩＦ）、
５０…モジュールアクセス制御部、５１…アクセス制御部、５２…システムキャパシティ制御部、
６０…モジュール層、６１…モジュール連携インタフェース（ＩＦ）、
７０…データアクセス部、７１…アクセス制御部、７２…システムキャパシティ制御部、
８０…データ層、８１…データ連携インタフェース（ＩＦ）、
９１…チャネル管理テーブル、９２…ユーザ管理テーブル、９３…サービス管理テーブル、９４…モジュール管理テーブル、９５…データ管理テーブル。

Claims (11)

1. 自社により運用され、１つ以上のサービスを提供する個別システムと、
   １つ以上のサービスから共通で利用されるサービスを提供する共通システムと、
   自社の外部においてサービスを提供する外部システムと、を含む複数のシステム環境上で稼働するソフトウェアの連携により業務サービスを提供する階層モデルからなるアプリケーションプログラムを有する情報処理システムにおいて、前記アプリケーションプログラムの各層の機能に対するアクセスの制御もしくは認証を行う統合アクセス制御システムであって、
   前記個別システムおよび前記外部システムにおいて、前記アプリケーションプログラムにおけるプレゼンテーション層により提供される画面へのアクセスに対して、ユーザおよびユーザがアクセスのために利用しているチャネルの少なくとも１つに基づいて認証処理を行う認証処理部と、
   前記認証処理部でのユーザ認証を介してログインしたユーザの数に応じて新たなユーザのログインを制限するログイン制御部と、を有する認証制御部と、
   前記外部システムにより提供される画面へのアクセスの際に、前記個別システムにアクセスした際の認証結果を前記外部システムに対して連携させるための認証連携インタフェース部とを有することを特徴とする統合アクセス制御システム。
2. 請求項１に記載の統合アクセス制御システムにおいて、
   さらに、前記プレゼンテーション層において、前記個別システムにより提供される画面に対して前記外部システムにより提供される画面を組み込むためのコンテンツ連携インタフェース部を有することを特徴とする統合アクセス制御システム。
3. 請求項１または２に記載の統合アクセス制御システムにおいて、
   さらに、前記個別システムおよび前記外部システムにおいて、前記プレゼンテーション層により提供される画面からの、前記アプリケーションプログラムにおけるサービス層により提供されるサービスへのアクセスに対して、ユーザ、ユーザの利用しているチャネル、および時間帯の少なくとも１つに基づいてアクセスの許否の判断を行う第１のアクセス制御部を有するサービスアクセス制御部を有することを特徴とする統合アクセス制御システム。
4. 請求項３に記載の統合アクセス制御システムにおいて、
   さらに、前記外部システムもしくは前記個別システムの前記プレゼンテーション層により提供される各画面が前記外部システムの前記サービス層により提供されるサービスへアクセスするための共通の外部インタフェースとして外部サービス連携インタフェース部を有することを特徴とする統合アクセス制御システム。
5. 請求項３または４に記載の統合アクセス制御システムにおいて、
   前記サービスアクセス制御部は、さらに、
   前記サービス層で実行中のサービスの数に応じて、前記プレゼンテーション層により提供される画面からの前記サービス層により提供されるサービスへの新たなアクセスを制限するサービスキャパシティ制御部を有することを特徴とする統合アクセス制御システム。
6. 請求項１〜５のいずれか１項に記載の統合アクセス制御システムにおいて、
   さらに、前記個別システムおよび前記共通システムにおいて、前記サービス層により提供されるサービスからの、前記アプリケーションプログラムにおけるモジュール層により提供されるモジュールへのアクセスに対して、ユーザおよびユーザの利用しているチャネルの少なくとも１つに基づいてアクセスの許否の判断を行う第２のアクセス制御部を有するモジュールアクセス制御部を有することを特徴とする統合アクセス制御システム。
7. 請求項６に記載の統合アクセス制御システムにおいて、
   さらに、前記個別システムの前記サービス層により提供されるサービスが前記個別システムもしくは前記共通システムの前記モジュール層により提供されるモジュールへアクセスするための共通の内部インタフェースとしてモジュール連携インタフェース部を有することを特徴とする統合アクセス制御システム。
8. 請求項６または７に記載の統合アクセス制御システムにおいて、
   前記モジュールアクセス制御部は、さらに、
   前記モジュール層におけるアクセスの対象のモジュールが稼働する機器において測定された性能情報に応じて、前記サービス層により提供されるサービスからの前記モジュール層により提供されるモジュールへの新たなアクセスを制限する第１のシステムキャパシティ制御部を有することを特徴とする統合アクセス制御システム。
9. 請求項１〜８のいずれか１項に記載の統合アクセス制御システムにおいて、
   さらに、前記個別システムおよび前記共通システムにおいて、前記モジュール層により提供されるモジュールからの、前記アプリケーションプログラムにおけるデータ層により保持されるデータへのアクセスに対して、ユーザの属性に基づいてアクセスの許否の判断を行う第３のアクセス制御部を有するデータアクセス制御部を有することを特徴とする統合アクセス制御システム。
10. 請求項９に記載の統合アクセス制御システムにおいて、
    さらに、前記共通システムの前記データ層により保持されるデータを前記個別システムの前記データ層により保持されるデータへ転送するための内部インタフェースとしてデータ連携インタフェース部を有することを特徴とする統合アクセス制御システム。
11. 請求項９または１０に記載の統合アクセス制御システムにおいて、
    前記データアクセス制御部は、さらに、
    前記データ層におけるアクセス対象のデータが保持される機器において測定された性能情報に応じて、前記モジュール層により提供されるモジュールからの前記データ層により保持されるデータへの新たなアクセスを制限する第２のシステムキャパシティ制御部を有することを特徴とする統合アクセス制御システム。

Images