リスクベース認証システムおよびリスクベース認証方法
【課題】ユーザ毎の属性やトランザクションの属性に応じてリスクレベルの評価結果を変化させて追加認証を実行する判断レベルを変化させることで、柔軟性のある認証方法を実現するリスクベース認証システムを提供する。
【解決手段】ルール分析や行動分析によりアクセスについてのリスクレベルを評価し、評価結果に基づいて認証レベルを変更するリスクベース認証システムであって、リスクベース認証部２１０と、ユーザ毎の属性に関する情報に基づいてリスクレベルを評価する属性判断部２２０と、リスクベース認証部２１０および属性判断部２２０を含む認証手段を有する多段認証サーバ２００と、多段認証サーバ２００の各認証手段に対してリスクレベルの評価を依頼してその評価結果を取得するパス判断部１２１と、取得したリスクレベルの評価結果に基づいて最終的なリスクレベルを評価し、評価結果に基づいて認証レベルを変更する合否判定部１２２とを有する。
【解決手段】ルール分析や行動分析によりアクセスについてのリスクレベルを評価し、評価結果に基づいて認証レベルを変更するリスクベース認証システムであって、リスクベース認証部２１０と、ユーザ毎の属性に関する情報に基づいてリスクレベルを評価する属性判断部２２０と、リスクベース認証部２１０および属性判断部２２０を含む認証手段を有する多段認証サーバ２００と、多段認証サーバ２００の各認証手段に対してリスクレベルの評価を依頼してその評価結果を取得するパス判断部１２１と、取得したリスクレベルの評価結果に基づいて最終的なリスクレベルを評価し、評価結果に基づいて認証レベルを変更する合否判定部１２２とを有する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、オンラインシステムなどにおける認証技術に関し、特に、リスクベース認証を行う認証システムおよび認証方法に適用して有効な技術に関するものである。
【背景技術】
【０００２】
昨今インターネットなどのネットワークを通じて金融取引や商品購入などの種々のトランザクションをオンラインで実行する機会が増えており、これに伴い、ＩＤやパスワード等の身元情報の盗難やオンライン詐欺などの件数も増えてきている。これに対し、各システムではログイン時やトランザクション処理時におけるユーザの認証を強化するなどしてセキュリティを強化する対策がとられてきた。
【０００３】
しかし、全てのユーザやトランザクションについて一律にセキュリティを強化する場合、セキュリティレベルが一部のユーザやトランザクションには不十分なものとなったり、逆に、全てのユーザやトランザクションに十分なセキュリティレベルを確保すると高価となり、また通常のユーザには使いにくいものになったりするなど、セキュリティレベルとユーザビリティに不均衡が生ずるものとなっていた。
【０００４】
そこで、現在、ユーザビリティを損ねずに認証強度を上げてセキュリティを強化する手法として、リスクベース認証が注目されている。リスクベース認証とは、アクセスログなどの履歴情報やコンテキスト情報から、ユーザの行動やアクセス環境を解析し、ユーザやトランザクションについてのリスクレベルを評価して、リスクレベルに応じて認証レベルを動的に変更することで、ユーザビリティを維持しつつユーザ認証の確度を高める手法である。
【０００５】
例えば、あるユーザが、通常は東京のオフィスから自分の銀行口座にアクセスしている場合に、同じユーザが大阪からこの銀行口座にアクセスしてきた場合は、通常の行動パターンと異なるためリスクレベルが高いと判断して追加の認証を要求したり、また、東京からアクセスがあった５分後にロシアからアクセスしてきたような場合は、通常あり得ないアクセスであり犯罪の可能性が高いとしてトランザクションを拒否したりすることが可能である。また、例えば、通常はＷｉｎｄｏｗｓ（登録商標）を使用しているユーザがＭａｃｉｎｔｏｓｈ（登録商標）でアクセスしてきた場合は追加認証を要求するといったことも可能である。
【０００６】
追加認証は、トランザクションが詐欺等ではないことを確認するために行う本人確認であり、例えば、オペレータからの電話による本人確認、本人だけが知る情報（生年月日や秘密の質問に対する回答など）の要求など、種々のものがある。
【０００７】
追加認証を要求するか否かの判断は、リスクベース認証システムにおいて、ルール分析（詐欺等の疑いの高いアクセスパターンとの比較）、行動分析（ユーザの過去の行動パターンとの比較）などを行った後、ポリシーを適用（ルール分析と行動分析の結果を数値化）することにより行われる。通常のリスクベース認証システムでは、トランザクションのリスク（怪しさ）を、例えば、４段階のレベルや、１〜１０００までの数値などによって評価している。
【０００８】
上述したリスクベース認証の技術については、例えば、特表２００７−５１４３３３号公報（特許文献１）などに記載されている。
【特許文献１】特表２００７−５１４３３３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
しかし、従来技術によるリスクベース認証システムでは、ルール分析や行動分析の結果を数値化する際に適用するポリシーは、リスクベース認証システムおよびこれを搭載したオンラインシステムで共通であり柔軟性に欠けている部分がある。すなわち、ユーザ毎の属性（例えば、口座残高など）や、トランザクションの属性（例えば、資金異動を伴うトランザクションであるか否かなど）によって、また、ユーザの希望（「ある条件では認証強度を上げて欲しい」など）によってリスクレベルの評価結果を変化させることはできず、追加認証を実行する判断レベルを変化させることはできない。
【００１０】
例えば、口座残高が多いユーザは、口座残高が少ないユーザに比べてより高い認証強度が必要であると考えるであろうし、口座残高に関わらず、一律に高い認証強度を求めるユーザが存在する場合も考えられる。また、残高照会では追加認証はなくても良いが、資金異動の場合は少ない金額でも認証強度を高くしたいと希望する場合も考えられる。
【００１１】
そこで本発明の目的は、ユーザ毎の属性やトランザクションの属性、ユーザからの指示などに応じてリスクレベルの評価結果を変化させて追加認証を実行する判断レベルを変化させることで、柔軟性のある認証方法を実現するリスクベース認証システムを提供することにある。本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。
【課題を解決するための手段】
【００１２】
本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。
【００１３】
本発明の代表的な実施の形態によるリスクベース認証システムは、ルール分析や行動分析を行ってユーザからのアクセスについてのリスクレベルを評価するリスクベース認証部と、前記ユーザ毎の属性に関する情報に基づいて前記アクセスについての前記リスクレベルを評価する属性判断部と、前記リスクベース認証部および前記属性判断部を含む、前記アクセスについての前記リスクレベルを評価する複数の認証手段を有する多段認証部と、前記多段認証部の前記各認証手段に対して、前記リスクレベルの評価の要求を依頼してその評価結果を取得するパス判断部と、前記パス判断部が取得した前記各リスクレベルの評価結果に基づいて前記アクセスについての最終的な前記リスクレベルを評価し、その評価結果に基づいて前記アクセスに対する前記認証レベルを変更する合否判定部とを有することを特徴とするものである。
【発明の効果】
【００１４】
本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。
【００１５】
本発明の代表的な実施の形態によれば、リスクベース認証システムにおいて、ユーザ毎の属性やトランザクションの属性、ユーザからの指示などに応じてリスクレベルの評価結果を変化させて追加認証を実行する判断レベルを変化させることにより、柔軟性のある認証方法を実現することが可能となる。
【００１６】
また、本発明の代表的な実施の形態によれば、ユーザが事前に自分が使用する環境や、環境によって使用可能なアプリケーションおよびその属性などを登録できるようにすることで、複数の環境から使用するユーザの利便性を高めるとともに、自分が使用しない環境からのアクセスに対する認証を強化することが可能となる。
【発明を実施するための最良の形態】
【００１７】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。また、以下においては、本発明の特徴を分かり易くするために、従来の技術と比較して説明する。
【００１８】
＜概要＞
図１１は、従来技術によるリスクベース認証システムを有するオンラインシステムの構成例の概要を示す図である。オンラインシステムは、Ｗｅｂ ＡＰ（Ｗｅｂアプリケーション）サーバ１００、ＡＰＬ（アプリケーション）サーバ３００、ＤＢ（データベース）サーバ４００、リスクベース認証サーバ８００、ネットワーク５００、クライアント端末６００を有する構成となっている。
【００１９】
クライアント端末６００は、ＰＣや携帯端末等のＷｅｂブラウザを有する端末機器であり、インターネット等のネットワーク５００を経由してＷｅｂ ＡＰサーバ１００に接続している。
【００２０】
Ｗｅｂ ＡＰサーバ１００は、主要機能として認証部１１０、ＰＬ（Presentation Logic）基盤部１３０、画面制御部１４０を有するＷｅｂサーバである。Ｗｅｂ ＡＰサーバ１００は、クライアント端末６００からのログインやトランザクションなどのアクセスに対して、認証部１１０によりユーザＩＤ、パスワードによる認証や、ＯＴＰ（One Time Password）による認証、Cookie認証などを行い、ＰＬ基盤部１３０の制御によりＡＰＬサーバ３００およびＤＢサーバ４００によって業務処理を行って、その結果に基づいて画面制御部１４０により表示画面を生成してクライアント端末６００に応答することにより、トランザクションの処理を実行する。
【００２１】
リスクベース認証システムでは、認証部１１０での認証に加えて、必要に応じてログインやトランザクション処理の際の認証強度を上げてセキュリティを強化するため、リスクベース認証サーバ８００によって追加認証の要否の判断を行う。リスクベース認証サーバ８００は、一般的に、アクセス元のＩＰアドレスとブラックリストとを比較してリスクレベルを判断する機能や、ルール分析・行動分析によりリスクレベルを判断する機能などを有しており、これらをそれぞれＩＰアドレス判定部８１０、およびルール・行動分析部８２０として表記している。
【００２２】
ここで、ＩＰアドレスのブラックリストとは、例えば、詐欺等の犯罪に利用されたり、コンピュータウィルスの拡散などのセキュリティ上の脅威を発生させたりなど、危険度の高いＩＰアドレスからなるリストであり、コンピュータやネットワークセキュリティのサービスベンダー等から提供されているものもある。ブラックリストはリスクＤＢ８３１に格納されている。また、ルール・行動分析部８２０は、ＲＢＡ（Risk-Based Authentication） ＤＢ８３２に格納されているユーザ毎のアクセスログなどの履歴情報に基づいて、ルール分析や行動分析を行う。
【００２３】
リスクベース認証サーバ８００は、ＩＰアドレス判定部８１０およびルール・行動分析部８２０での判断結果に対してポリシーを適用して数値化し、トランザクションのリスクレベルを評価する。リスクレベルが所定の閾値よりも高い場合は、ユーザに対してオペレータからの電話による本人確認等の追加認証を要求する。
【００２４】
なお、図１１において、各サーバの各部は一般的にソフトウェアによって実装される。また、図１１の例では、リスクベース認証サーバ８００を含む各サーバを独立した機器として図示しているが、その全部または一部が同一の機器に実装されていてもよい。また、リスクベース認証サーバ８００の機能は、サービスベンダー等からネットワークを介して提供される場合もある。
【００２５】
従来技術によるリスクベース認証システムでは、上述したように、ルール分析や行動分析の結果を数値化する際に適用するポリシーは、リスクベース認証システムおよびこれを搭載したオンラインシステムで共通であり柔軟性に欠けている部分がある。すなわち、ユーザ毎の属性（例えば、口座残高など）や、トランザクションの属性（例えば、資金異動を伴うトランザクションであるか否かなど）によってリスクレベルの評価結果を変化させることはできず、追加認証を実行する判断レベルを変化させることはできない。
【００２６】
そこで、本実施の形態のリスクベース認証システムでは、ユーザ毎の属性やトランザクションの属性、ユーザからの指示などに応じてリスクレベルの評価結果を変化させる機能を有し、これにより追加認証を実行する判断レベルを変化させることを可能として、柔軟性のある認証方法を実現する。また、ユーザが事前に自分の使用する環境や、環境によって使用可能なトランザクションおよびその属性などを登録できる機能を有し、これにより複数の環境から使用するユーザの利便性を高めるとともに、自分が使用しない環境からのアクセスに対する認証を強化する。
【００２７】
＜実施の形態＞
以下、本実施の形態のリスクベース認証システムについて説明する。
【００２８】
［システム構成］
図１は、本実施の形態のリスクベース認証システムを有するオンラインシステムの構成例の概要を示す図である。図１に示すリスクベース認証システムでは、図１１に示したものに加えて、Ｗｅｂ ＡＰサーバ１００において多段認証接続部１２０が追加されている。また、リスクベース認証サーバ８００の代わりに多段認証部である多段認証サーバ２００を有する構成となっている。
【００２９】
多段認証サーバ２００は、図１１におけるリスクベース認証サーバ８００が有する機能と同様の機能をリスクベース認証部２１０として有する。すなわち、図１１におけるＩＰアドレス判定部８１０、ルール・行動分析部８２０と、図１におけるＩＰアドレス判定部２１１、ルール・行動分析部２１２は、同様の機能を有する。
【００３０】
多段認証サーバ２００は、さらに、ユーザ毎の属性やトランザクションの属性等に応じてリスクレベルの評価結果を変化させることを可能とするため、属性判断部２２０、アプリケーション判断部２３０の各認証手段を有する。Ｗｅｂ ＡＰサーバ１００の多段認証接続部１２０は、多段認証サーバ２００における認証内容の制御と、リスクレベルの評価および追加認証の要否の判断を行うため、パス判断部１２１、合否判定部１２２を有する。
【００３１】
多段認証接続部１２０のパス判断部１２１は、Ｗｅｂ ＡＰサーバ１００の認証部１１０での認証に加えてリスクベース認証を行うため、パス判断ＤＢ１５１を参照して、多段認証サーバ２００における認証のパス、すなわち、多段認証サーバ２００の各認証手段のうちいずれを実行するかを判断し、実行すべき各認証手段に対してリスクレベルの評価を依頼する。なお、このパスはユーザ毎に設定可能であり、パス判断ＤＢ１５１に格納される。
【００３２】
多段認証サーバ２００の属性判断部２２０は、ユーザ毎の属性（例えば、口座残高）やユーザの事前登録の内容に応じてリスクレベルを評価し、結果を数値化してパス判断部１２１に応答する。また、アプリケーション判断部２３０は、トランザクションの対象のアプリケーション名や、そのアプリケーションで使用するパラメータなど（例えば、資金異動を伴うトランザクションであるか否かや、異動金額など）に応じてリスクレベルを評価し、結果を数値化してパス判断部１２１に応答する。なお、属性判断部２２０やアプリケーション判断部２３０でリスクレベルを評価する条件はユーザ毎に設定可能であり、それぞれ属性判断ＤＢ２５０、ＡＰＬ判断ＤＢ２６０に格納される。
【００３３】
本実施の形態の多段認証サーバ２００では、ＩＰアドレス判定部２１１、ルール・行動分析部２１２、属性判断部２２０、アプリケーション判断部２３０の４つの認証手段を有しているが、この４つである必要はなく、この一部を有さないものであってもよいし、さらに追加の認証手段を有していてもよい。
【００３４】
多段認証接続部１２０の合否判定部１２２は、パス判断部１２１によって得られた各認証手段でのリスクレベルの評価結果の点数と、各認証手段について設定されている合算時の比率に基づいてリスクレベルの合計点を算出する。この合計点が所定の合格点以上か未満かを判定し、合格点以上であれば合格として、ＰＬ基盤部１３０および画面制御部１４０により通常の画面遷移を実行する。合格点未満であれば不合格として、追加認証もしくはアクセスの拒否を実行する。なお、各認証手段について設定されている合算時の比率や合格点はユーザ毎に設定可能であり、合否判定ＤＢ１５２に格納されている。
【００３５】
このように、本実施の形態のリスクベース認証システムでは、まず、リスクベース認証を行う入口のパス判断の時点で、パス判断ＤＢ１５１により、どの認証手段を実行するか（もしくはどの認証手段の評価結果を全体のリスクレベルの評価の際に用いるか）をユーザ毎にカスタマイズすることができる。また、リスクベース認証についても、リスクベース認証部２１０による従来のリスクベース認証の手段に加えて、ユーザ属性やトランザクション属性によるリスクレベルの評価を行う属性判断部２２０、アプリケーション判断部２３０の認証手段を有し、さらに、属性判断ＤＢ２５０やＡＰＬ判断ＤＢ２６０によりリスクレベルを評価する条件をユーザ毎にカスタマイズすることができる。さらに、リスクベース認証の出口の合否判定の時点でも、合否判定ＤＢ１５２により、リスクレベルの合計点の算出方法や合格点をユーザ毎にカスタマイズすることができる。
【００３６】
［データ構成］
以下では、図１において示された各ＤＢのデータ構成について説明する。本実施の形態では、テーブル形式の構造で記載しているが、ＸＭＬ（eXtensible Markup Language）におけるようなツリー構造であってもよい。また、実際の格納手段も各種データベースシステムやファイルなど種々の手段をとることができる。
【００３７】
図２は、パス判断ＤＢ１５１のデータ構成と具体的なデータの例を示した図である。パス判断ＤＢ１５１は、例えば、ユーザＩＤ、通過認証、認証点数のフィールドからなり、ユーザＩＤ毎に、リスクベース認証において通過させる認証手段のパス、すなわち、多段認証サーバ２００における各認証手段のうちいずれを実行するかを設定しておくテーブルである。通過させる認証手段の種別は通過認証のフィールドに格納される。また、実際に各認証手段を実行し、各認証手段においてリスクレベルが評価された結果の数値が、対応する認証点数のフィールドに格納される。
【００３８】
図２の例では、例えば、ユーザＩＤ“Ａ１０００１”のユーザは、リスクベース認証に際して多段認証サーバ２００のＩＰアドレス判定部２１１と、属性判断部２２０によるリスクレベルの評価のみを行うように設定されており、各認証の結果の評価点数がそれぞれ１００点、３０点であったことを示している。なお、初期状態では認証点数のフィールドには値は格納されていない。また、図２の例では通過認証のフィールドのデータを説明の便宜上“ＩＰアドレス判定”等の文言で表記しているが、実装に際しては各認証手段に割り振られたＩＤなどが設定されていてもよい。
【００３９】
図３は、合否判定ＤＢ１５２のデータ構成と具体的なデータの例を示した図である。合否判定ＤＢ１５２は、例えば、ユーザＩＤ、認証、合算時比率、合格点のフィールドからなり、ユーザＩＤ毎に、各認証手段によるリスクレベルの評価結果に基づいてリスクレベルの合計点を算出して合否判定を行う際のルールを設定しておくテーブルである。ユーザＩＤ毎および多段認証サーバ２００における全ての認証手段毎に、各認証手段におけるリスクレベルの評価結果の数値を合算して合計点を算出する際に各認証手段の評価数値に乗じられる比率が合算時比率のフィールドに格納される。また、算出された合計点との比較の対象となる基準点、すなわち対象のアクセスに対して認証レベルを変更する基準となる点が合格点のフィールドに格納される。
【００４０】
図３の例では、例えば、ユーザＩＤ“Ａ１０００１”のユーザは、リスクレベルの評価数値の合計点を算出する際に、多段認証サーバ２００のＩＰアドレス判定部２１１、ルール・行動分析部２１２、属性判断部２２０、およびアプリケーション判断部２３０によるリスクレベルの評価結果の数値に対して、それぞれ２、１、３、１を掛けてから合算するように設定されていることを示している。また、合算して得られた合計点が２００点以上であれば合格であり、２００点未満であれば不合格となるように設定されていることを示している。
【００４１】
図４は、リスクＤＢ２４１のデータ構成と具体的なデータの例を示した図である。リスクＤＢ２４１は、例えば、ＩＰアドレス、国などのフィールドを含んでおり、ＩＰアドレスのブラックリストの情報などを保持しているテーブルである。リスクＤＢ２４１は、従来技術のリスクベース認証システムにおいても用いられているものであり、他にも種々の項目のデータを有している場合もあり、本実施の形態のリスクベース認証システムにおいて特に構成を規定する必要があるものではない。
【００４２】
図５は、ＲＢＡ ＤＢ２４２のデータ構成と具体的なデータの例を示した図である。ＲＢＡ ＤＢ２４２には、例えば、ユーザＩＤ、ＩＰアドレス、ＵｓｅｒＡｇｅｎｔ（トランザクションのリクエストメッセージに含まれ、Ｗｅｂブラウザなどの利用環境を識別することができる情報）、アクセス時間などのフィールドが含まれ、クライアント端末６００からのアクセスの時間や環境についての履歴情報などを保持しているテーブルである。ＲＢＡ ＤＢ２４２は、従来技術のリスクベース認証システムにおいても用いられているものであり、他にも種々の項目のデータを有している場合もあり、本実施の形態のリスクベース認証システムにおいて特に構成を規定する必要があるものではない。
【００４３】
図６は、属性判断ＤＢ２５０のデータ構成と具体的なデータの例を示した図である。属性判断ＤＢ２５０は、例えば、ユーザＩＤ、認証強化申請、海外利用申請、利用国、利用可能ＡＰＬ（アプリケーション）、口座残高認証強化申請、基準口座残高などのフィールドからなり、ユーザＩＤ毎に、ユーザ属性（ユーザ自身の属性など）やパラメータ属性（口座残高などのパラメータ）毎に、それぞれの値に応じたリスクレベルの評価条件や認証強化の指定などを設定しておくテーブルである。
【００４４】
認証強化申請のフィールドには、ユーザからの申請による事前登録により、属性判断部２２０でのユーザ毎の属性判断によるリスクレベルの評価結果に対してさらに厳しい評価をするか否かを指定するフラグが設定される。このフラグが“Ｙ”になっている場合は、例えば、ユーザ属性による評価結果およびパラメータ属性による評価結果、もしくはその両方の評価結果の数値に対して、一律××点減算したり、××％に圧縮したりすることによって評価結果の数値を低くし、リスクレベルの評価結果を厳しくして認証強度を上げることが可能である。
【００４５】
海外利用申請のフィールドには、ユーザからの申請による事前登録により、アプリケーションを海外で利用する可能性があるか否かを指定するフラグが設定される。このフラグが“Ｙ”になっている場合は、さらに、利用国、利用可能ＡＰＬのフィールドに対象の国およびその国で利用することができるアプリケーションの種別が設定される。これにより、例えば、よく出張する国においては一部のサービスのみ利用可能とし、その他の国からのアクセスに対しては拒否するということも可能である。
【００４６】
口座残高認証強化申請のフィールドには、ユーザからの申請による事前登録により、口座残高に応じてリスクレベルの評価を行うか否かを指定するフラグが設定される。このフラグが“Ｙ”になっている場合は、例えば、図１における顧客ＤＢ４１０に格納されている口座残高が参照され、口座残高に応じたリスクレベルの評価が行われる。このとき、基準口座残高のフィールドに設定された値よりも口座残高が多い場合は、例えば、評価結果の数値に対して××点減算したり、基準口座残高の値との差に応じて××％としたりすることによって評価結果の数値を低くし、リスクレベルの評価結果を厳しくして認証強度を上げることが可能である。
【００４７】
図６の例では、例えば、ユーザＩＤ“Ａ１０００１”のユーザは、属性判断部２２０による評価結果に対してさらに厳しく評価する認証強化申請をしており、また、口座残高１０００万円以上の場合は評価結果を厳しくする認証強化申請をしていることを示している。また、ユーザＩＤ“Ａ２０００１”のユーザは、認証強化申請に加えて、海外での利用環境についても申請しており、米国では株式売買および入出金、英国では株式売買のアプリケーションを利用可能としている。また、口座残高５００万円以上の場合は評価結果を厳しくする認証強化申請もしていることを示している。なお、図６の例では利用可能ＡＰＬのフィールドのデータを説明の便宜上“株式売買”等の文言で表記しているが、実装に際しては各アプリケーションに割り振られたＩＤなどが設定されていてもよい。
【００４８】
図７は、ＡＰＬ判断ＤＢ２６０のデータ構成と具体的なデータの例を示した図である。ＡＰＬ判断ＤＢ２６０は、例えば、ユーザＩＤ、アプリケーション、パラメータ条件のフィールドからなり、ユーザＩＤ毎に、利用するアプリケーション毎のパラメータによるリスクレベルの評価条件を設定しておくテーブルである。
【００４９】
アプリケーションのフィールドには、リスクレベルの評価を厳しくする対象のアプリケーション名が設定される。また、パラメータ条件には、対応するアプリケーションを利用する際にリスクレベルの評価を厳しくするパラメータの条件が設定される。図７の例では、例えば、ユーザＩＤ“Ａ１０００１”は、株式売買のアプリケーションを行う際に、売買代金が１００万円以上となる場合は評価結果の数値に対して××点減算したり、××％に圧縮したりすることによって評価結果の数値を低くし、リスクレベルの評価を厳しくして認証強度を上げることができる。なお、図７の例ではパラメータ条件フィールドのデータを説明の便宜上“売買代金１００万円以上”等の文言で表記しているが、実装に際しては各パラメータに割り振られたＩＤや、ＩＤを用いた条件式のテンプレートなどが設定されていてもよい。
【００５０】
なお、顧客ＤＢ４１０は、ＡＰＬサーバ３００における業務処理において一般的に使用される顧客情報が格納されたＤＢである。本実施の形態では少なくともユーザＩＤで特定される顧客の口座残高を有しているものとし、その他のデータ構成についての説明は省略する。
【００５１】
パス判断ＤＢ１５１、合否判定ＤＢ１５２、属性判断ＤＢ２５０、ＡＰＬ判断ＤＢ２６０は、ユーザＩＤをキー項目としており、上述したように、ユーザ毎、さらに属性毎、アプリケーションの種別毎に設定を変更して保持することが可能である。このとき、例えば、あらかじめ各設定について組み合わせを考慮した値を全ユーザに共通の既定値として保持しておき、初期値としてはこれらの値が設定されるようにし、その後、別途実装された専用のアプリケーションによるユーザからの登録・変更操作や、ユーザからの申請に基づくサーバからの登録などにより設定を変更可能としてもよい。また上記既定値についても、システム管理者等による登録・変更操作等により変更可能としてもよい。
【００５２】
［処理の流れ］
以下では、本実施の形態のリスクベース認証システムにおける認証処理の流れについて説明する。図８は、図１に示したオンラインシステムのうちリスクベース認証システムに該当する多段認証接続部１２０および多段認証サーバ２００に関する部分のみ抽出し、多段認証サーバ２００における各認証手段を全て実行する場合について、その処理の流れの例を示した図である。図中で、各処理および処理の流れは括弧付き数字および実線の矢印で示されており、以下これら各処理について順に内容を説明する。
【００５３】
（１）クライアント端末６００によるユーザからのアクセス要求が発生すると、Ｗｅｂ ＡＰサーバ１００の認証部１１０での通常の認証処理が許可された場合は、多段認証接続部１２０にリスクベース認証が要求される。ユーザからのアクセスはログイン処理だけに限らず、アプリケーションを実行するトランザクション処理など、種々のアクセスについてリスクベース認証を適用することが可能である。
【００５４】
（２）パス判断部１２１は、ユーザからのアクセス要求に含まれるユーザＩＤをキーとしてパス判断ＤＢ１５１を参照し、実行する（通過させる）認証手段を決定する。すなわち、パス判断ＤＢ１５１から、対象のユーザＩＤについて、認証点数のフィールドに値が設定されていない（認証をまだ行っていない）エントリに対応する通過認証のフィールドの値を取得する。ここでは、まず“ＩＰアドレス判定”による認証を行うものと判断される。
【００５５】
（３）パス判断部１２１は、多段認証サーバ２００のＩＰアドレス判定部２１１に対して認証の要求、すなわちリスクレベルの評価の依頼を行う。
【００５６】
（４）ＩＰアドレス判定部２１１は、リスクＤＢ２４１、ＲＢＡ ＤＢ２４２を参照して、アクセス環境のＩＰアドレスおよび国についてのブラックリストによる判定などを行い、リスクレベルの評価結果の数値を算出してパス判断部１２１に応答する。
【００５７】
（５）パス判断部１２１は、（４）でＩＰアドレス判定部２１１から応答されたリスクレベルの評価結果の数値をパス判断ＤＢ１５１の該当のエントリの認証点数のフィールドに格納し、（２）と同様の処理を行う。ここでは、“ルール・行動分析”による認証を行うものと判断される。
【００５８】
（６）パス判断部１２１は、多段認証サーバ２００のルール・行動分析部２１２に対してリスクレベルの評価の依頼を行う。
【００５９】
（７）ルール・行動分析部２１２は、ＲＢＡ ＤＢ２４２を参照して、ルール分析および行動分析を行う。すなわち、ＲＢＡ ＤＢ２４２に格納された当該ユーザのアクセス履歴に基づいて、詐欺等の疑いの高いアクセスパターンとの比較、およびユーザの過去の行動パターンとの比較を行い、リスクレベルの評価結果の数値を算出してパス判断部１２１に応答する。
【００６０】
（８）（５）の処理と同様に、パス判断部１２１は、（７）でルール・行動分析部２１２から応答されたリスクレベルの評価結果の数値をパス判断ＤＢ１５１の該当エントリの認証点数のフィールドに格納し、（２）と同様の処理を行う。ここでは、“属性判断”による認証を行うものと判断される。
【００６１】
（９）パス判断部１２１は、多段認証サーバ２００の属性判断部２２０に対してリスクレベルの評価の依頼を行う。
【００６２】
（１０）属性判断部２２０は、ユーザＩＤをキーとして属性判断ＤＢ２５０、顧客ＤＢ４１０などを参照して属性判断によるリスクレベルの評価を行い、評価結果の数値を算出してパス判断部１２１に応答する。ここでは、属性判断ＤＢ２５０のユーザ毎の設定内容に従って、例えば、口座残高認証強化申請のフィールドが“Ｙ”に設定されている場合は、顧客ＤＢ４１０における口座残高の値と、属性判断ＤＢ２５０の基準口座残高のフィールドの値とを比較し、口座残高が基準口座残高以上である場合は、そうでない場合の評価結果の点数に対して××点減算したり××％に圧縮したりするなどして点数を低くして評価を厳しくすることができる。
【００６３】
また、属性判断ＤＢ２５０の海外利用申請のフィールドが“Ｙ”に設定されている場合は、ユーザのアクセス環境の国および対象のアプリケーションが、属性判断ＤＢ２５０の利用国および利用可能ＡＰＬのフィールドに設定されている国およびアプリケーションに該当する場合は評価結果の点数を高くし、該当しない場合は評価結果の点数を低くして評価を厳しくすることができる。
【００６４】
また、属性判断ＤＢ２５０の認証強化申請のフィールドが“Ｙ”に設定されている場合は、属性判断全体の評価結果の点数からさらに××点減算するなどして点数を低くして評価を厳しくすることが可能である。また、これらの条件だけに限らず、他の条件が追加されていてもよい。
【００６５】
（１１）（５）の処理と同様に、パス判断部１２１は、（１０）で属性判断部２２０から応答されたリスクレベルの評価結果の数値をパス判断ＤＢ１５１の該当エントリの認証点数のフィールドに格納し、（２）と同様の処理を行う。ここでは、“アプリケーション判断”による認証を行うものと判断される。
【００６６】
（１２）パス判断部１２１は、多段認証サーバ２００のアプリケーション判断部２３０に対してリスクレベルの評価の依頼を行う。
【００６７】
（１３）アプリケーション判断部２３０は、ユーザＩＤをキーとしてＡＰＬ判断ＤＢ２６０を参照して、アプリケーションの種別等によるリスクレベルの評価を行い、評価結果の数値を算出してパス判断部１２１に応答する。ここでは、ＡＰＬ判断ＤＢ２６０のユーザ毎の設定内容に従って、例えば、当該トランザクションのアプリケーション名やパラメータが、ＡＰＬ判断ＤＢ２６０のアプリケーションやパラメータ条件のフィールドに設定されているもの該当する場合は、該当しない場合の評価結果の点数に対して××点減算したり××％に圧縮したりするなどして点数を低くして評価を厳しくすることができる。
【００６８】
これにより、例えば、商品購入の際に実際に「購入」ボタンを押す場合と、商品選択時の画面遷移の場合とで認証強度を変えるなど、必要な場合にのみ認証強度を上げることも可能であり、セキュリティを維持しつつ不要な追加認証を避けることが可能である。
【００６９】
（１４）（５）の処理と同様に、パス判断部１２１は、（１３）でアプリケーション判断部２３０から応答されたリスクレベルの評価結果の数値をパス判断ＤＢ１５１の該当エントリの認証点数のフィールドに格納し、（２）と同様の処理を行う。ここでは、全ての認証が終了したものと判断されるため、パス判断ＤＢ１５１に格納された各認証手段についての認証点数を合否判定部１２２に送る。
【００７０】
（１５）合否判定部１２２は、ユーザＩＤをキーとして合否判定ＤＢ１５２を参照して、パス判断部１２１から送られた各認証手段についての認証点数に基づいて、リスクレベルの評価結果の合計点を算出し、最終的な合否判定を行う。リスクレベルの評価結果の合計点の算出は、例えば、各認証手段について、合否判定ＤＢ１５２からそれぞれ合算時比率のフィールドの値を取得し、各認証手段についての認証点数に対してそれぞれ対応する合算時比率の値を掛けたものを合算して合計点とすることができる。すなわち、
合計点＝
（ＩＰアドレス判定による認証点数×ＩＰアドレス判定の合算時比率）
＋（ルール・行動分析による認証点数×ルール・行動分析の合算時比率）
＋（属性判断による認証点数×属性判断の合算時比率）
・・・
＋（アプリケーション判断による認証点数×アプリケーション判断の合算時比率）
となる。さらに、合否判断ＤＢ１５２から、当該ユーザについての合格点のフィールドの値を取得し、算出した合計点と取得した合格点と比較し、合計点が合格点以上か未満かを判定する。合計点が合格点以上であれば合格とし、合格点未満であれば不合格とする。
【００７１】
（１６）（１５）における合否判定の結果が合格である場合は、Ｗｅｂ ＡＰサーバ１００のＰＬ基盤部１３０や画面制御部１４０により通常の画面遷移を行い、クライアント端末６００に応答する。（１５）における合否判定の結果が不合格である場合は、追加認証による本人確認の実行要求もしくはアクセスの拒否を実行する。
【００７２】
［具体例］
以下では、図８における、上述した本実施の形態のリスクベース認証システムにおける認証処理の流れについて、具体的なデータの例を挙げて説明する。各ＤＢの具体的な値は図２〜図７に示した例と同じであるものとし、ユーザＩＤ“Ａ１０００１”のユーザがアクセスしてきたものとする。また、顧客ＤＢ４１０には当該ユーザの口座残高は１５００万円として登録されているものとする。
【００７３】
（１）多段認証接続部１２０のパス判断部１２１は、ユーザＩＤ“Ａ１０００１”のユーザからのアクセスにより、リスクベース認証の要求を受ける。
【００７４】
（２）パス判断部１２１は、ユーザＩＤ“Ａ１０００１”をキーとしてパス判断ＤＢ１５１を参照し、実行する認証手段を決定する。ここでは、まず“ＩＰアドレス判定”による認証を行うものと判断される。
【００７５】
（３）パス判断部１２１は、多段認証サーバ２００のＩＰアドレス判定部２１１に対してリスクレベルの評価の依頼を行う。
【００７６】
（４）ＩＰアドレス判定部２１１は、リスクＤＢ２４１、ＲＢＡ ＤＢ２４２を参照して、アクセス環境のＩＰアドレスおよび国についてのブラックリストによる判定などを行い、リスクレベルの評価結果の数値を算出してパス判断部１２１に応答する。ここでは、リスクレベルの評価結果の数値が１００点であったことを示している。
【００７７】
（５）パス判断部１２１は、（４）でＩＰアドレス判定部２１１から応答されたリスクレベルの評価結果の数値（１００点）をパス判断ＤＢ１５１の該当のエントリの認証点数のフィールドに格納し、（２）と同様の処理を行う。ここでは、“属性判断”による認証を行うものと判断される。
【００７８】
（９）パス判断部１２１は、多段認証サーバ２００の属性判断部２２０に対してリスクレベルの評価の依頼を行う。
【００７９】
（１０）属性判断部２２０は、ユーザＩＤ“Ａ１０００１”をキーとして属性判断ＤＢ２５０、顧客ＤＢ４１０などを参照して、属性判断によるリスクレベルの評価を行い、評価結果の数値を算出してパス判断部１２１に応答する。ここでは、図６の属性判断ＤＢ２５０の例において、ユーザＩＤ“Ａ１０００１”のユーザは口座残高認証強化申請のフィールドの値が“Ｙ”に設定されているため、口座残高についての評価結果を算出して加算する。図６の属性判断ＤＢ２５０の例では、基準口座残高のフィールドが１０００万円と設定されているため、口座残高（１５００万円）が基準口座残高（１０００万円）よりも多いことから、リスクレベルの評価を厳しくするため、通常加算される点数から所定の点数を減算した結果、例えば５０点となったものとする。
【００８０】
また、認証強化申請のフィールドが“Ｙ”に設定されているため、属性判断全体の評価をさらに厳しくするため、属性判断全体の評価点数（この例では５０点）からさらに所定の点数を減算した結果、リスクレベルの評価結果の数値が３０点となったことを示している。
【００８１】
（１４）（５）の処理と同様に、パス判断部１２１は、（１０）で属性判断部２２０から応答されたリスクレベルの評価結果の数値（３０点）をパス判断ＤＢ１５１の該当エントリの認証点数のフィールドに格納し、（２）と同様の処理を行う。ここでは、全ての認証が終了したものと判断されるため、パス判断ＤＢ１５１に格納された各認証手段についての認証点数を合否判定部１２２に送る。
【００８２】
（１５）合否判定部１２２は、ユーザＩＤ“Ａ１０００１”をキーとして合否判定ＤＢ１５２を参照して、パス判断部１２１から送られた各認証手段についての認証点数に基づいて、リスクレベルの評価結果の合計点を算出し、最終的な合否判定を行う。ここで、図３の合否判定ＤＢ１５２において、当該ユーザについては、“ＩＰアドレス判定”の合算時比率が２であり、“属性判断”の合算時比率が３であるため、合計点は、
合計点＝（１００点×２）＋（３０点×３）＝２９０点
となる。ここで、図３の合否判定ＤＢ１５２において、当該ユーザについては合格点が２００点であるため、合格と判定される。
【００８３】
（１６）（１５）における合否判定の結果が合格であるため、Ｗｅｂ ＡＰサーバ１００のＰＬ基盤部１３０や画面制御部１４０により通常の画面遷移を行い、クライアント端末６００に応答する。
【００８４】
なお、本実施の形態のリスクベース認証システムでは、上述した例のように、パス判断ＤＢ１５１の通過認証のフィールドに設定されている認証手段のみを実行し、それ以外の認証手段は行わないように構成しているが、バス判断ＤＢ１５１の設定に関わらずに全ての認証手段について実行し、パス判断ＤＢ１５１の通過認証のフィールドに設定されている認証手段についてのみ、合否判定部１２２におけるリスクレベルの合計点の算出の際に認証点数の加算対象とする（他の認証手段については、リスクレベルの評価は行うが、合計点の算出には寄与しない）という構成にしてもよい。
【００８５】
また、例えば、属性判断部２２０におけるリスクレベルの評価結果の数値化の際に、属性判断ＤＢ２５０における海外利用申請や口座残高認証強化申請のフィールドの値が“Ｙ”となっている場合のみ、当該項目の評価結果を数値化して加算するように構成しているが、値が“Ｎ”となっていた場合は一律に当該項目の評価結果として満点もしくは所定の点数を加算するように構成してもよい。
【００８６】
また、各認証手段におけるリスクレベルの評価結果や、合計点についての具体的な算出方法（各条件に対する配点や比率、評価を厳しくする際に減算する点数や圧縮比率、算出式など）は、上述したような例に限らず、種々の方法をとることができることは当然である。また、点数による評価に限らず、レベル等による評価であってもよい。
【００８７】
［システム構成の変形例］
以下では、本実施の形態のリスクベース認証システムのシステム構成の変形例について説明する。図９は、図１に示した本実施の形態のリスクベース認証システムを有するオンラインシステムのシステム構成例について概略を示した図である。
【００８８】
図９に示す構成では、リスクベース認証システムは多段認証接続部１２０と多段認証サーバ２００から構成され、多段認証接続部１２０は、パス判断部１２１と合否判定部１２２を有し、Ｗｅｂ ＡＰサーバ１００上に配置されている。また、多段認証サーバ２００は、リスクベース認証における各認証を行う認証手段を有する多段認証部であり、本実施の形態のリスクベース認証システムでは、リスクベース認証部２１０および属性判断部２２０、アプリケーション判断部２３０を有している。
【００８９】
図９に示す構成では、図１１に示す従来技術によるリスクベース認証システムに対して、Ｗｅｂ ＡＰサーバ１００とリスクベース認証サーバ８００にソフトウェアを新たに配置することによって実現する構成となっている。ここで、多段認証サーバ２００においては、例えば、従来技術によるリスクベース認証を行うリスクベース認証部２１０が製品等のパッケージとして実装されている場合、属性判断部２２０やアプリケーション判断部２３０を、リスクベース認証部２１０を構成するパッケージとは別のソフトウェアとして実装してもよいし、リスクベース認証部２１０を構成するパッケージ自体の機能拡張という形式で実装してもよい。
【００９０】
一方、図１０は、図９に示した本実施の形態のリスクベース認証システムを有するオンラインシステムの別のシステム構成例について概略を示した図である。図１０に示す構成では、リスクベース認証システムは多段認証サーバ７００とリスクベース認証サーバ８００から構成され、多段認証サーバ７００は、図９に示すパス判断部１２１、合否判定部１２２、属性判断部２２０、アプリケーション判断部２３０と同等の機能を有するパス判断部７１０、合否判定部７２０、属性判断部７３０、アプリケーション判断部７４０を有している。
【００９１】
図１０に示す構成では、リスクベース認証サーバ８００は図１１に示すものと同じであり、図１１に示す従来技術によるリスクベース認証システムに対して、Ｗｅｂ ＡＰサーバ１００とリスクベース認証サーバ８００との間に専用の多段認証サーバ７００を新たに構築することによって実現する構成となっている。
【００９２】
リスクベース認証システムの実装に際しては、図９の例で示したソフトウェアによる実装方式や、図１０の例で示した専用サーバによる実装方式、その他の構成によるものなどをシステム環境等により適宜選択して適用することが可能である。
【００９３】
以上に説明したように、本実施の形態のリスクベース認証システムによれば、従来技術によるリスクベース認証システムにおけるリスクベース認証に加えて、属性判断部２２０やアプリケーション判断部２３０などを有し、ユーザ毎の属性やトランザクションの属性に応じてリスクレベルの評価結果を変化させることが可能である。また、リスクレベルの評価の際の条件をユーザ毎に変更することが可能である。
【００９４】
また、リスクベース認証を行う入口の時点で、パス判断ＤＢ１５１により、どの認証を行うかをユーザ毎にカスタマイズすることができ、リスクレベルを評価する認証手段を必要に応じて新たに追加することも容易である。また、リスクベース認証の出口の合否判定の時点で、合否判定の方法をユーザ毎にカスタマイズすることもできる。これらにより、リスクベース認証においてリスクレベルの評価結果をユーザ属性やトランザクション属性、ユーザからの指示などに応じて変化させることができ、柔軟性のあるリスクベース認証を実現することが可能となる。
【００９５】
また、本実施の形態のリスクベース認証システムによれば、ユーザが事前に自分が使用する環境や、環境によって使用可能なトランザクションおよびその属性などを登録できるようにすることで、複数の環境から使用するユーザの利便性を高めるとともに、自分が使用しない環境からのアクセスに対する認証を強化することも可能となる。
【００９６】
以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。
【産業上の利用可能性】
【００９７】
本発明は、オンラインシステムなどにおいてリスクベース認証を行う認証システムおよび認証方法に利用可能である。
【図面の簡単な説明】
【００９８】
【図１】本発明の一実施の形態のリスクベース認証システムを有するオンラインシステムの構成例の概要を示す図である。
【図２】本発明の一実施の形態におけるパス判断ＤＢのデータ構成と具体的なデータの例を示した図である。
【図３】本発明の一実施の形態における合否判定ＤＢのデータ構成と具体的なデータの例を示した図である。
【図４】本発明の一実施の形態におけるリスクＤＢのデータ構成と具体的なデータの例を示した図である。
【図５】本発明の一実施の形態におけるＲＢＡ ＤＢのデータ構成と具体的なデータの例を示した図である。
【図６】本発明の一実施の形態における属性判断ＤＢのデータ構成と具体的なデータの例を示した図である。
【図７】本発明の一実施の形態におけるＡＰＬ判断ＤＢのデータ構成と具体的なデータの例を示した図である。
【図８】本発明の一実施の形態における処理の流れの例を示した図である。
【図９】本発明の一実施の形態のリスクベース認証システムを有するオンラインシステムのシステム構成例について概略を示した図である。
【図１０】本発明の一実施の形態のリスクベース認証システムを有するオンラインシステムの別のシステム構成例について概略を示した図である。
【図１１】従来技術によるリスクベース認証システムを有するオンラインシステムの構成例の概要を示す図である。
【符号の説明】
【００９９】
１００…Ｗｅｂ ＡＰサーバ、１１０…認証部、１２０…多段認証接続部、１２１…パス判断部、１２２…合否判定部、１３０…ＰＬ基盤部、１４０…画面制御部、１５１…パス判断ＤＢ、１５２…合否判定ＤＢ、２００…多段認証サーバ、２１０…リスクベース認証部、２１１…ＩＰアドレス判定部、２１２…ルール・行動分析部、２２０…属性判断部、２３０…アプリケーション判断部、２４１…リスクＤＢ、２４２…ＲＢＡ ＤＢ、２５０…属性判断ＤＢ、２６０…ＡＰＬ判断ＤＢ、３００…ＡＰＬサーバ、４００…ＤＢサーバ、４１０…顧客ＤＢ、５００…ネットワーク、６００…クライアント端末、
７００…多段認証サーバ、７１０…パス判断部、７２０…合否判定部、７３０…属性判断部、７４０…アプリケーション判断部、８００…リスクベース認証サーバ、８１０…ＩＰアドレス判定部、８２０…ルール・行動分析部、
８３１…リスクＤＢ、８３２…ＲＢＡ ＤＢ。
【技術分野】
【０００１】
本発明は、オンラインシステムなどにおける認証技術に関し、特に、リスクベース認証を行う認証システムおよび認証方法に適用して有効な技術に関するものである。
【背景技術】
【０００２】
昨今インターネットなどのネットワークを通じて金融取引や商品購入などの種々のトランザクションをオンラインで実行する機会が増えており、これに伴い、ＩＤやパスワード等の身元情報の盗難やオンライン詐欺などの件数も増えてきている。これに対し、各システムではログイン時やトランザクション処理時におけるユーザの認証を強化するなどしてセキュリティを強化する対策がとられてきた。
【０００３】
しかし、全てのユーザやトランザクションについて一律にセキュリティを強化する場合、セキュリティレベルが一部のユーザやトランザクションには不十分なものとなったり、逆に、全てのユーザやトランザクションに十分なセキュリティレベルを確保すると高価となり、また通常のユーザには使いにくいものになったりするなど、セキュリティレベルとユーザビリティに不均衡が生ずるものとなっていた。
【０００４】
そこで、現在、ユーザビリティを損ねずに認証強度を上げてセキュリティを強化する手法として、リスクベース認証が注目されている。リスクベース認証とは、アクセスログなどの履歴情報やコンテキスト情報から、ユーザの行動やアクセス環境を解析し、ユーザやトランザクションについてのリスクレベルを評価して、リスクレベルに応じて認証レベルを動的に変更することで、ユーザビリティを維持しつつユーザ認証の確度を高める手法である。
【０００５】
例えば、あるユーザが、通常は東京のオフィスから自分の銀行口座にアクセスしている場合に、同じユーザが大阪からこの銀行口座にアクセスしてきた場合は、通常の行動パターンと異なるためリスクレベルが高いと判断して追加の認証を要求したり、また、東京からアクセスがあった５分後にロシアからアクセスしてきたような場合は、通常あり得ないアクセスであり犯罪の可能性が高いとしてトランザクションを拒否したりすることが可能である。また、例えば、通常はＷｉｎｄｏｗｓ（登録商標）を使用しているユーザがＭａｃｉｎｔｏｓｈ（登録商標）でアクセスしてきた場合は追加認証を要求するといったことも可能である。
【０００６】
追加認証は、トランザクションが詐欺等ではないことを確認するために行う本人確認であり、例えば、オペレータからの電話による本人確認、本人だけが知る情報（生年月日や秘密の質問に対する回答など）の要求など、種々のものがある。
【０００７】
追加認証を要求するか否かの判断は、リスクベース認証システムにおいて、ルール分析（詐欺等の疑いの高いアクセスパターンとの比較）、行動分析（ユーザの過去の行動パターンとの比較）などを行った後、ポリシーを適用（ルール分析と行動分析の結果を数値化）することにより行われる。通常のリスクベース認証システムでは、トランザクションのリスク（怪しさ）を、例えば、４段階のレベルや、１〜１０００までの数値などによって評価している。
【０００８】
上述したリスクベース認証の技術については、例えば、特表２００７−５１４３３３号公報（特許文献１）などに記載されている。
【特許文献１】特表２００７−５１４３３３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
しかし、従来技術によるリスクベース認証システムでは、ルール分析や行動分析の結果を数値化する際に適用するポリシーは、リスクベース認証システムおよびこれを搭載したオンラインシステムで共通であり柔軟性に欠けている部分がある。すなわち、ユーザ毎の属性（例えば、口座残高など）や、トランザクションの属性（例えば、資金異動を伴うトランザクションであるか否かなど）によって、また、ユーザの希望（「ある条件では認証強度を上げて欲しい」など）によってリスクレベルの評価結果を変化させることはできず、追加認証を実行する判断レベルを変化させることはできない。
【００１０】
例えば、口座残高が多いユーザは、口座残高が少ないユーザに比べてより高い認証強度が必要であると考えるであろうし、口座残高に関わらず、一律に高い認証強度を求めるユーザが存在する場合も考えられる。また、残高照会では追加認証はなくても良いが、資金異動の場合は少ない金額でも認証強度を高くしたいと希望する場合も考えられる。
【００１１】
そこで本発明の目的は、ユーザ毎の属性やトランザクションの属性、ユーザからの指示などに応じてリスクレベルの評価結果を変化させて追加認証を実行する判断レベルを変化させることで、柔軟性のある認証方法を実現するリスクベース認証システムを提供することにある。本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。
【課題を解決するための手段】
【００１２】
本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。
【００１３】
本発明の代表的な実施の形態によるリスクベース認証システムは、ルール分析や行動分析を行ってユーザからのアクセスについてのリスクレベルを評価するリスクベース認証部と、前記ユーザ毎の属性に関する情報に基づいて前記アクセスについての前記リスクレベルを評価する属性判断部と、前記リスクベース認証部および前記属性判断部を含む、前記アクセスについての前記リスクレベルを評価する複数の認証手段を有する多段認証部と、前記多段認証部の前記各認証手段に対して、前記リスクレベルの評価の要求を依頼してその評価結果を取得するパス判断部と、前記パス判断部が取得した前記各リスクレベルの評価結果に基づいて前記アクセスについての最終的な前記リスクレベルを評価し、その評価結果に基づいて前記アクセスに対する前記認証レベルを変更する合否判定部とを有することを特徴とするものである。
【発明の効果】
【００１４】
本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。
【００１５】
本発明の代表的な実施の形態によれば、リスクベース認証システムにおいて、ユーザ毎の属性やトランザクションの属性、ユーザからの指示などに応じてリスクレベルの評価結果を変化させて追加認証を実行する判断レベルを変化させることにより、柔軟性のある認証方法を実現することが可能となる。
【００１６】
また、本発明の代表的な実施の形態によれば、ユーザが事前に自分が使用する環境や、環境によって使用可能なアプリケーションおよびその属性などを登録できるようにすることで、複数の環境から使用するユーザの利便性を高めるとともに、自分が使用しない環境からのアクセスに対する認証を強化することが可能となる。
【発明を実施するための最良の形態】
【００１７】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。また、以下においては、本発明の特徴を分かり易くするために、従来の技術と比較して説明する。
【００１８】
＜概要＞
図１１は、従来技術によるリスクベース認証システムを有するオンラインシステムの構成例の概要を示す図である。オンラインシステムは、Ｗｅｂ ＡＰ（Ｗｅｂアプリケーション）サーバ１００、ＡＰＬ（アプリケーション）サーバ３００、ＤＢ（データベース）サーバ４００、リスクベース認証サーバ８００、ネットワーク５００、クライアント端末６００を有する構成となっている。
【００１９】
クライアント端末６００は、ＰＣや携帯端末等のＷｅｂブラウザを有する端末機器であり、インターネット等のネットワーク５００を経由してＷｅｂ ＡＰサーバ１００に接続している。
【００２０】
Ｗｅｂ ＡＰサーバ１００は、主要機能として認証部１１０、ＰＬ（Presentation Logic）基盤部１３０、画面制御部１４０を有するＷｅｂサーバである。Ｗｅｂ ＡＰサーバ１００は、クライアント端末６００からのログインやトランザクションなどのアクセスに対して、認証部１１０によりユーザＩＤ、パスワードによる認証や、ＯＴＰ（One Time Password）による認証、Cookie認証などを行い、ＰＬ基盤部１３０の制御によりＡＰＬサーバ３００およびＤＢサーバ４００によって業務処理を行って、その結果に基づいて画面制御部１４０により表示画面を生成してクライアント端末６００に応答することにより、トランザクションの処理を実行する。
【００２１】
リスクベース認証システムでは、認証部１１０での認証に加えて、必要に応じてログインやトランザクション処理の際の認証強度を上げてセキュリティを強化するため、リスクベース認証サーバ８００によって追加認証の要否の判断を行う。リスクベース認証サーバ８００は、一般的に、アクセス元のＩＰアドレスとブラックリストとを比較してリスクレベルを判断する機能や、ルール分析・行動分析によりリスクレベルを判断する機能などを有しており、これらをそれぞれＩＰアドレス判定部８１０、およびルール・行動分析部８２０として表記している。
【００２２】
ここで、ＩＰアドレスのブラックリストとは、例えば、詐欺等の犯罪に利用されたり、コンピュータウィルスの拡散などのセキュリティ上の脅威を発生させたりなど、危険度の高いＩＰアドレスからなるリストであり、コンピュータやネットワークセキュリティのサービスベンダー等から提供されているものもある。ブラックリストはリスクＤＢ８３１に格納されている。また、ルール・行動分析部８２０は、ＲＢＡ（Risk-Based Authentication） ＤＢ８３２に格納されているユーザ毎のアクセスログなどの履歴情報に基づいて、ルール分析や行動分析を行う。
【００２３】
リスクベース認証サーバ８００は、ＩＰアドレス判定部８１０およびルール・行動分析部８２０での判断結果に対してポリシーを適用して数値化し、トランザクションのリスクレベルを評価する。リスクレベルが所定の閾値よりも高い場合は、ユーザに対してオペレータからの電話による本人確認等の追加認証を要求する。
【００２４】
なお、図１１において、各サーバの各部は一般的にソフトウェアによって実装される。また、図１１の例では、リスクベース認証サーバ８００を含む各サーバを独立した機器として図示しているが、その全部または一部が同一の機器に実装されていてもよい。また、リスクベース認証サーバ８００の機能は、サービスベンダー等からネットワークを介して提供される場合もある。
【００２５】
従来技術によるリスクベース認証システムでは、上述したように、ルール分析や行動分析の結果を数値化する際に適用するポリシーは、リスクベース認証システムおよびこれを搭載したオンラインシステムで共通であり柔軟性に欠けている部分がある。すなわち、ユーザ毎の属性（例えば、口座残高など）や、トランザクションの属性（例えば、資金異動を伴うトランザクションであるか否かなど）によってリスクレベルの評価結果を変化させることはできず、追加認証を実行する判断レベルを変化させることはできない。
【００２６】
そこで、本実施の形態のリスクベース認証システムでは、ユーザ毎の属性やトランザクションの属性、ユーザからの指示などに応じてリスクレベルの評価結果を変化させる機能を有し、これにより追加認証を実行する判断レベルを変化させることを可能として、柔軟性のある認証方法を実現する。また、ユーザが事前に自分の使用する環境や、環境によって使用可能なトランザクションおよびその属性などを登録できる機能を有し、これにより複数の環境から使用するユーザの利便性を高めるとともに、自分が使用しない環境からのアクセスに対する認証を強化する。
【００２７】
＜実施の形態＞
以下、本実施の形態のリスクベース認証システムについて説明する。
【００２８】
［システム構成］
図１は、本実施の形態のリスクベース認証システムを有するオンラインシステムの構成例の概要を示す図である。図１に示すリスクベース認証システムでは、図１１に示したものに加えて、Ｗｅｂ ＡＰサーバ１００において多段認証接続部１２０が追加されている。また、リスクベース認証サーバ８００の代わりに多段認証部である多段認証サーバ２００を有する構成となっている。
【００２９】
多段認証サーバ２００は、図１１におけるリスクベース認証サーバ８００が有する機能と同様の機能をリスクベース認証部２１０として有する。すなわち、図１１におけるＩＰアドレス判定部８１０、ルール・行動分析部８２０と、図１におけるＩＰアドレス判定部２１１、ルール・行動分析部２１２は、同様の機能を有する。
【００３０】
多段認証サーバ２００は、さらに、ユーザ毎の属性やトランザクションの属性等に応じてリスクレベルの評価結果を変化させることを可能とするため、属性判断部２２０、アプリケーション判断部２３０の各認証手段を有する。Ｗｅｂ ＡＰサーバ１００の多段認証接続部１２０は、多段認証サーバ２００における認証内容の制御と、リスクレベルの評価および追加認証の要否の判断を行うため、パス判断部１２１、合否判定部１２２を有する。
【００３１】
多段認証接続部１２０のパス判断部１２１は、Ｗｅｂ ＡＰサーバ１００の認証部１１０での認証に加えてリスクベース認証を行うため、パス判断ＤＢ１５１を参照して、多段認証サーバ２００における認証のパス、すなわち、多段認証サーバ２００の各認証手段のうちいずれを実行するかを判断し、実行すべき各認証手段に対してリスクレベルの評価を依頼する。なお、このパスはユーザ毎に設定可能であり、パス判断ＤＢ１５１に格納される。
【００３２】
多段認証サーバ２００の属性判断部２２０は、ユーザ毎の属性（例えば、口座残高）やユーザの事前登録の内容に応じてリスクレベルを評価し、結果を数値化してパス判断部１２１に応答する。また、アプリケーション判断部２３０は、トランザクションの対象のアプリケーション名や、そのアプリケーションで使用するパラメータなど（例えば、資金異動を伴うトランザクションであるか否かや、異動金額など）に応じてリスクレベルを評価し、結果を数値化してパス判断部１２１に応答する。なお、属性判断部２２０やアプリケーション判断部２３０でリスクレベルを評価する条件はユーザ毎に設定可能であり、それぞれ属性判断ＤＢ２５０、ＡＰＬ判断ＤＢ２６０に格納される。
【００３３】
本実施の形態の多段認証サーバ２００では、ＩＰアドレス判定部２１１、ルール・行動分析部２１２、属性判断部２２０、アプリケーション判断部２３０の４つの認証手段を有しているが、この４つである必要はなく、この一部を有さないものであってもよいし、さらに追加の認証手段を有していてもよい。
【００３４】
多段認証接続部１２０の合否判定部１２２は、パス判断部１２１によって得られた各認証手段でのリスクレベルの評価結果の点数と、各認証手段について設定されている合算時の比率に基づいてリスクレベルの合計点を算出する。この合計点が所定の合格点以上か未満かを判定し、合格点以上であれば合格として、ＰＬ基盤部１３０および画面制御部１４０により通常の画面遷移を実行する。合格点未満であれば不合格として、追加認証もしくはアクセスの拒否を実行する。なお、各認証手段について設定されている合算時の比率や合格点はユーザ毎に設定可能であり、合否判定ＤＢ１５２に格納されている。
【００３５】
このように、本実施の形態のリスクベース認証システムでは、まず、リスクベース認証を行う入口のパス判断の時点で、パス判断ＤＢ１５１により、どの認証手段を実行するか（もしくはどの認証手段の評価結果を全体のリスクレベルの評価の際に用いるか）をユーザ毎にカスタマイズすることができる。また、リスクベース認証についても、リスクベース認証部２１０による従来のリスクベース認証の手段に加えて、ユーザ属性やトランザクション属性によるリスクレベルの評価を行う属性判断部２２０、アプリケーション判断部２３０の認証手段を有し、さらに、属性判断ＤＢ２５０やＡＰＬ判断ＤＢ２６０によりリスクレベルを評価する条件をユーザ毎にカスタマイズすることができる。さらに、リスクベース認証の出口の合否判定の時点でも、合否判定ＤＢ１５２により、リスクレベルの合計点の算出方法や合格点をユーザ毎にカスタマイズすることができる。
【００３６】
［データ構成］
以下では、図１において示された各ＤＢのデータ構成について説明する。本実施の形態では、テーブル形式の構造で記載しているが、ＸＭＬ（eXtensible Markup Language）におけるようなツリー構造であってもよい。また、実際の格納手段も各種データベースシステムやファイルなど種々の手段をとることができる。
【００３７】
図２は、パス判断ＤＢ１５１のデータ構成と具体的なデータの例を示した図である。パス判断ＤＢ１５１は、例えば、ユーザＩＤ、通過認証、認証点数のフィールドからなり、ユーザＩＤ毎に、リスクベース認証において通過させる認証手段のパス、すなわち、多段認証サーバ２００における各認証手段のうちいずれを実行するかを設定しておくテーブルである。通過させる認証手段の種別は通過認証のフィールドに格納される。また、実際に各認証手段を実行し、各認証手段においてリスクレベルが評価された結果の数値が、対応する認証点数のフィールドに格納される。
【００３８】
図２の例では、例えば、ユーザＩＤ“Ａ１０００１”のユーザは、リスクベース認証に際して多段認証サーバ２００のＩＰアドレス判定部２１１と、属性判断部２２０によるリスクレベルの評価のみを行うように設定されており、各認証の結果の評価点数がそれぞれ１００点、３０点であったことを示している。なお、初期状態では認証点数のフィールドには値は格納されていない。また、図２の例では通過認証のフィールドのデータを説明の便宜上“ＩＰアドレス判定”等の文言で表記しているが、実装に際しては各認証手段に割り振られたＩＤなどが設定されていてもよい。
【００３９】
図３は、合否判定ＤＢ１５２のデータ構成と具体的なデータの例を示した図である。合否判定ＤＢ１５２は、例えば、ユーザＩＤ、認証、合算時比率、合格点のフィールドからなり、ユーザＩＤ毎に、各認証手段によるリスクレベルの評価結果に基づいてリスクレベルの合計点を算出して合否判定を行う際のルールを設定しておくテーブルである。ユーザＩＤ毎および多段認証サーバ２００における全ての認証手段毎に、各認証手段におけるリスクレベルの評価結果の数値を合算して合計点を算出する際に各認証手段の評価数値に乗じられる比率が合算時比率のフィールドに格納される。また、算出された合計点との比較の対象となる基準点、すなわち対象のアクセスに対して認証レベルを変更する基準となる点が合格点のフィールドに格納される。
【００４０】
図３の例では、例えば、ユーザＩＤ“Ａ１０００１”のユーザは、リスクレベルの評価数値の合計点を算出する際に、多段認証サーバ２００のＩＰアドレス判定部２１１、ルール・行動分析部２１２、属性判断部２２０、およびアプリケーション判断部２３０によるリスクレベルの評価結果の数値に対して、それぞれ２、１、３、１を掛けてから合算するように設定されていることを示している。また、合算して得られた合計点が２００点以上であれば合格であり、２００点未満であれば不合格となるように設定されていることを示している。
【００４１】
図４は、リスクＤＢ２４１のデータ構成と具体的なデータの例を示した図である。リスクＤＢ２４１は、例えば、ＩＰアドレス、国などのフィールドを含んでおり、ＩＰアドレスのブラックリストの情報などを保持しているテーブルである。リスクＤＢ２４１は、従来技術のリスクベース認証システムにおいても用いられているものであり、他にも種々の項目のデータを有している場合もあり、本実施の形態のリスクベース認証システムにおいて特に構成を規定する必要があるものではない。
【００４２】
図５は、ＲＢＡ ＤＢ２４２のデータ構成と具体的なデータの例を示した図である。ＲＢＡ ＤＢ２４２には、例えば、ユーザＩＤ、ＩＰアドレス、ＵｓｅｒＡｇｅｎｔ（トランザクションのリクエストメッセージに含まれ、Ｗｅｂブラウザなどの利用環境を識別することができる情報）、アクセス時間などのフィールドが含まれ、クライアント端末６００からのアクセスの時間や環境についての履歴情報などを保持しているテーブルである。ＲＢＡ ＤＢ２４２は、従来技術のリスクベース認証システムにおいても用いられているものであり、他にも種々の項目のデータを有している場合もあり、本実施の形態のリスクベース認証システムにおいて特に構成を規定する必要があるものではない。
【００４３】
図６は、属性判断ＤＢ２５０のデータ構成と具体的なデータの例を示した図である。属性判断ＤＢ２５０は、例えば、ユーザＩＤ、認証強化申請、海外利用申請、利用国、利用可能ＡＰＬ（アプリケーション）、口座残高認証強化申請、基準口座残高などのフィールドからなり、ユーザＩＤ毎に、ユーザ属性（ユーザ自身の属性など）やパラメータ属性（口座残高などのパラメータ）毎に、それぞれの値に応じたリスクレベルの評価条件や認証強化の指定などを設定しておくテーブルである。
【００４４】
認証強化申請のフィールドには、ユーザからの申請による事前登録により、属性判断部２２０でのユーザ毎の属性判断によるリスクレベルの評価結果に対してさらに厳しい評価をするか否かを指定するフラグが設定される。このフラグが“Ｙ”になっている場合は、例えば、ユーザ属性による評価結果およびパラメータ属性による評価結果、もしくはその両方の評価結果の数値に対して、一律××点減算したり、××％に圧縮したりすることによって評価結果の数値を低くし、リスクレベルの評価結果を厳しくして認証強度を上げることが可能である。
【００４５】
海外利用申請のフィールドには、ユーザからの申請による事前登録により、アプリケーションを海外で利用する可能性があるか否かを指定するフラグが設定される。このフラグが“Ｙ”になっている場合は、さらに、利用国、利用可能ＡＰＬのフィールドに対象の国およびその国で利用することができるアプリケーションの種別が設定される。これにより、例えば、よく出張する国においては一部のサービスのみ利用可能とし、その他の国からのアクセスに対しては拒否するということも可能である。
【００４６】
口座残高認証強化申請のフィールドには、ユーザからの申請による事前登録により、口座残高に応じてリスクレベルの評価を行うか否かを指定するフラグが設定される。このフラグが“Ｙ”になっている場合は、例えば、図１における顧客ＤＢ４１０に格納されている口座残高が参照され、口座残高に応じたリスクレベルの評価が行われる。このとき、基準口座残高のフィールドに設定された値よりも口座残高が多い場合は、例えば、評価結果の数値に対して××点減算したり、基準口座残高の値との差に応じて××％としたりすることによって評価結果の数値を低くし、リスクレベルの評価結果を厳しくして認証強度を上げることが可能である。
【００４７】
図６の例では、例えば、ユーザＩＤ“Ａ１０００１”のユーザは、属性判断部２２０による評価結果に対してさらに厳しく評価する認証強化申請をしており、また、口座残高１０００万円以上の場合は評価結果を厳しくする認証強化申請をしていることを示している。また、ユーザＩＤ“Ａ２０００１”のユーザは、認証強化申請に加えて、海外での利用環境についても申請しており、米国では株式売買および入出金、英国では株式売買のアプリケーションを利用可能としている。また、口座残高５００万円以上の場合は評価結果を厳しくする認証強化申請もしていることを示している。なお、図６の例では利用可能ＡＰＬのフィールドのデータを説明の便宜上“株式売買”等の文言で表記しているが、実装に際しては各アプリケーションに割り振られたＩＤなどが設定されていてもよい。
【００４８】
図７は、ＡＰＬ判断ＤＢ２６０のデータ構成と具体的なデータの例を示した図である。ＡＰＬ判断ＤＢ２６０は、例えば、ユーザＩＤ、アプリケーション、パラメータ条件のフィールドからなり、ユーザＩＤ毎に、利用するアプリケーション毎のパラメータによるリスクレベルの評価条件を設定しておくテーブルである。
【００４９】
アプリケーションのフィールドには、リスクレベルの評価を厳しくする対象のアプリケーション名が設定される。また、パラメータ条件には、対応するアプリケーションを利用する際にリスクレベルの評価を厳しくするパラメータの条件が設定される。図７の例では、例えば、ユーザＩＤ“Ａ１０００１”は、株式売買のアプリケーションを行う際に、売買代金が１００万円以上となる場合は評価結果の数値に対して××点減算したり、××％に圧縮したりすることによって評価結果の数値を低くし、リスクレベルの評価を厳しくして認証強度を上げることができる。なお、図７の例ではパラメータ条件フィールドのデータを説明の便宜上“売買代金１００万円以上”等の文言で表記しているが、実装に際しては各パラメータに割り振られたＩＤや、ＩＤを用いた条件式のテンプレートなどが設定されていてもよい。
【００５０】
なお、顧客ＤＢ４１０は、ＡＰＬサーバ３００における業務処理において一般的に使用される顧客情報が格納されたＤＢである。本実施の形態では少なくともユーザＩＤで特定される顧客の口座残高を有しているものとし、その他のデータ構成についての説明は省略する。
【００５１】
パス判断ＤＢ１５１、合否判定ＤＢ１５２、属性判断ＤＢ２５０、ＡＰＬ判断ＤＢ２６０は、ユーザＩＤをキー項目としており、上述したように、ユーザ毎、さらに属性毎、アプリケーションの種別毎に設定を変更して保持することが可能である。このとき、例えば、あらかじめ各設定について組み合わせを考慮した値を全ユーザに共通の既定値として保持しておき、初期値としてはこれらの値が設定されるようにし、その後、別途実装された専用のアプリケーションによるユーザからの登録・変更操作や、ユーザからの申請に基づくサーバからの登録などにより設定を変更可能としてもよい。また上記既定値についても、システム管理者等による登録・変更操作等により変更可能としてもよい。
【００５２】
［処理の流れ］
以下では、本実施の形態のリスクベース認証システムにおける認証処理の流れについて説明する。図８は、図１に示したオンラインシステムのうちリスクベース認証システムに該当する多段認証接続部１２０および多段認証サーバ２００に関する部分のみ抽出し、多段認証サーバ２００における各認証手段を全て実行する場合について、その処理の流れの例を示した図である。図中で、各処理および処理の流れは括弧付き数字および実線の矢印で示されており、以下これら各処理について順に内容を説明する。
【００５３】
（１）クライアント端末６００によるユーザからのアクセス要求が発生すると、Ｗｅｂ ＡＰサーバ１００の認証部１１０での通常の認証処理が許可された場合は、多段認証接続部１２０にリスクベース認証が要求される。ユーザからのアクセスはログイン処理だけに限らず、アプリケーションを実行するトランザクション処理など、種々のアクセスについてリスクベース認証を適用することが可能である。
【００５４】
（２）パス判断部１２１は、ユーザからのアクセス要求に含まれるユーザＩＤをキーとしてパス判断ＤＢ１５１を参照し、実行する（通過させる）認証手段を決定する。すなわち、パス判断ＤＢ１５１から、対象のユーザＩＤについて、認証点数のフィールドに値が設定されていない（認証をまだ行っていない）エントリに対応する通過認証のフィールドの値を取得する。ここでは、まず“ＩＰアドレス判定”による認証を行うものと判断される。
【００５５】
（３）パス判断部１２１は、多段認証サーバ２００のＩＰアドレス判定部２１１に対して認証の要求、すなわちリスクレベルの評価の依頼を行う。
【００５６】
（４）ＩＰアドレス判定部２１１は、リスクＤＢ２４１、ＲＢＡ ＤＢ２４２を参照して、アクセス環境のＩＰアドレスおよび国についてのブラックリストによる判定などを行い、リスクレベルの評価結果の数値を算出してパス判断部１２１に応答する。
【００５７】
（５）パス判断部１２１は、（４）でＩＰアドレス判定部２１１から応答されたリスクレベルの評価結果の数値をパス判断ＤＢ１５１の該当のエントリの認証点数のフィールドに格納し、（２）と同様の処理を行う。ここでは、“ルール・行動分析”による認証を行うものと判断される。
【００５８】
（６）パス判断部１２１は、多段認証サーバ２００のルール・行動分析部２１２に対してリスクレベルの評価の依頼を行う。
【００５９】
（７）ルール・行動分析部２１２は、ＲＢＡ ＤＢ２４２を参照して、ルール分析および行動分析を行う。すなわち、ＲＢＡ ＤＢ２４２に格納された当該ユーザのアクセス履歴に基づいて、詐欺等の疑いの高いアクセスパターンとの比較、およびユーザの過去の行動パターンとの比較を行い、リスクレベルの評価結果の数値を算出してパス判断部１２１に応答する。
【００６０】
（８）（５）の処理と同様に、パス判断部１２１は、（７）でルール・行動分析部２１２から応答されたリスクレベルの評価結果の数値をパス判断ＤＢ１５１の該当エントリの認証点数のフィールドに格納し、（２）と同様の処理を行う。ここでは、“属性判断”による認証を行うものと判断される。
【００６１】
（９）パス判断部１２１は、多段認証サーバ２００の属性判断部２２０に対してリスクレベルの評価の依頼を行う。
【００６２】
（１０）属性判断部２２０は、ユーザＩＤをキーとして属性判断ＤＢ２５０、顧客ＤＢ４１０などを参照して属性判断によるリスクレベルの評価を行い、評価結果の数値を算出してパス判断部１２１に応答する。ここでは、属性判断ＤＢ２５０のユーザ毎の設定内容に従って、例えば、口座残高認証強化申請のフィールドが“Ｙ”に設定されている場合は、顧客ＤＢ４１０における口座残高の値と、属性判断ＤＢ２５０の基準口座残高のフィールドの値とを比較し、口座残高が基準口座残高以上である場合は、そうでない場合の評価結果の点数に対して××点減算したり××％に圧縮したりするなどして点数を低くして評価を厳しくすることができる。
【００６３】
また、属性判断ＤＢ２５０の海外利用申請のフィールドが“Ｙ”に設定されている場合は、ユーザのアクセス環境の国および対象のアプリケーションが、属性判断ＤＢ２５０の利用国および利用可能ＡＰＬのフィールドに設定されている国およびアプリケーションに該当する場合は評価結果の点数を高くし、該当しない場合は評価結果の点数を低くして評価を厳しくすることができる。
【００６４】
また、属性判断ＤＢ２５０の認証強化申請のフィールドが“Ｙ”に設定されている場合は、属性判断全体の評価結果の点数からさらに××点減算するなどして点数を低くして評価を厳しくすることが可能である。また、これらの条件だけに限らず、他の条件が追加されていてもよい。
【００６５】
（１１）（５）の処理と同様に、パス判断部１２１は、（１０）で属性判断部２２０から応答されたリスクレベルの評価結果の数値をパス判断ＤＢ１５１の該当エントリの認証点数のフィールドに格納し、（２）と同様の処理を行う。ここでは、“アプリケーション判断”による認証を行うものと判断される。
【００６６】
（１２）パス判断部１２１は、多段認証サーバ２００のアプリケーション判断部２３０に対してリスクレベルの評価の依頼を行う。
【００６７】
（１３）アプリケーション判断部２３０は、ユーザＩＤをキーとしてＡＰＬ判断ＤＢ２６０を参照して、アプリケーションの種別等によるリスクレベルの評価を行い、評価結果の数値を算出してパス判断部１２１に応答する。ここでは、ＡＰＬ判断ＤＢ２６０のユーザ毎の設定内容に従って、例えば、当該トランザクションのアプリケーション名やパラメータが、ＡＰＬ判断ＤＢ２６０のアプリケーションやパラメータ条件のフィールドに設定されているもの該当する場合は、該当しない場合の評価結果の点数に対して××点減算したり××％に圧縮したりするなどして点数を低くして評価を厳しくすることができる。
【００６８】
これにより、例えば、商品購入の際に実際に「購入」ボタンを押す場合と、商品選択時の画面遷移の場合とで認証強度を変えるなど、必要な場合にのみ認証強度を上げることも可能であり、セキュリティを維持しつつ不要な追加認証を避けることが可能である。
【００６９】
（１４）（５）の処理と同様に、パス判断部１２１は、（１３）でアプリケーション判断部２３０から応答されたリスクレベルの評価結果の数値をパス判断ＤＢ１５１の該当エントリの認証点数のフィールドに格納し、（２）と同様の処理を行う。ここでは、全ての認証が終了したものと判断されるため、パス判断ＤＢ１５１に格納された各認証手段についての認証点数を合否判定部１２２に送る。
【００７０】
（１５）合否判定部１２２は、ユーザＩＤをキーとして合否判定ＤＢ１５２を参照して、パス判断部１２１から送られた各認証手段についての認証点数に基づいて、リスクレベルの評価結果の合計点を算出し、最終的な合否判定を行う。リスクレベルの評価結果の合計点の算出は、例えば、各認証手段について、合否判定ＤＢ１５２からそれぞれ合算時比率のフィールドの値を取得し、各認証手段についての認証点数に対してそれぞれ対応する合算時比率の値を掛けたものを合算して合計点とすることができる。すなわち、
合計点＝
（ＩＰアドレス判定による認証点数×ＩＰアドレス判定の合算時比率）
＋（ルール・行動分析による認証点数×ルール・行動分析の合算時比率）
＋（属性判断による認証点数×属性判断の合算時比率）
・・・
＋（アプリケーション判断による認証点数×アプリケーション判断の合算時比率）
となる。さらに、合否判断ＤＢ１５２から、当該ユーザについての合格点のフィールドの値を取得し、算出した合計点と取得した合格点と比較し、合計点が合格点以上か未満かを判定する。合計点が合格点以上であれば合格とし、合格点未満であれば不合格とする。
【００７１】
（１６）（１５）における合否判定の結果が合格である場合は、Ｗｅｂ ＡＰサーバ１００のＰＬ基盤部１３０や画面制御部１４０により通常の画面遷移を行い、クライアント端末６００に応答する。（１５）における合否判定の結果が不合格である場合は、追加認証による本人確認の実行要求もしくはアクセスの拒否を実行する。
【００７２】
［具体例］
以下では、図８における、上述した本実施の形態のリスクベース認証システムにおける認証処理の流れについて、具体的なデータの例を挙げて説明する。各ＤＢの具体的な値は図２〜図７に示した例と同じであるものとし、ユーザＩＤ“Ａ１０００１”のユーザがアクセスしてきたものとする。また、顧客ＤＢ４１０には当該ユーザの口座残高は１５００万円として登録されているものとする。
【００７３】
（１）多段認証接続部１２０のパス判断部１２１は、ユーザＩＤ“Ａ１０００１”のユーザからのアクセスにより、リスクベース認証の要求を受ける。
【００７４】
（２）パス判断部１２１は、ユーザＩＤ“Ａ１０００１”をキーとしてパス判断ＤＢ１５１を参照し、実行する認証手段を決定する。ここでは、まず“ＩＰアドレス判定”による認証を行うものと判断される。
【００７５】
（３）パス判断部１２１は、多段認証サーバ２００のＩＰアドレス判定部２１１に対してリスクレベルの評価の依頼を行う。
【００７６】
（４）ＩＰアドレス判定部２１１は、リスクＤＢ２４１、ＲＢＡ ＤＢ２４２を参照して、アクセス環境のＩＰアドレスおよび国についてのブラックリストによる判定などを行い、リスクレベルの評価結果の数値を算出してパス判断部１２１に応答する。ここでは、リスクレベルの評価結果の数値が１００点であったことを示している。
【００７７】
（５）パス判断部１２１は、（４）でＩＰアドレス判定部２１１から応答されたリスクレベルの評価結果の数値（１００点）をパス判断ＤＢ１５１の該当のエントリの認証点数のフィールドに格納し、（２）と同様の処理を行う。ここでは、“属性判断”による認証を行うものと判断される。
【００７８】
（９）パス判断部１２１は、多段認証サーバ２００の属性判断部２２０に対してリスクレベルの評価の依頼を行う。
【００７９】
（１０）属性判断部２２０は、ユーザＩＤ“Ａ１０００１”をキーとして属性判断ＤＢ２５０、顧客ＤＢ４１０などを参照して、属性判断によるリスクレベルの評価を行い、評価結果の数値を算出してパス判断部１２１に応答する。ここでは、図６の属性判断ＤＢ２５０の例において、ユーザＩＤ“Ａ１０００１”のユーザは口座残高認証強化申請のフィールドの値が“Ｙ”に設定されているため、口座残高についての評価結果を算出して加算する。図６の属性判断ＤＢ２５０の例では、基準口座残高のフィールドが１０００万円と設定されているため、口座残高（１５００万円）が基準口座残高（１０００万円）よりも多いことから、リスクレベルの評価を厳しくするため、通常加算される点数から所定の点数を減算した結果、例えば５０点となったものとする。
【００８０】
また、認証強化申請のフィールドが“Ｙ”に設定されているため、属性判断全体の評価をさらに厳しくするため、属性判断全体の評価点数（この例では５０点）からさらに所定の点数を減算した結果、リスクレベルの評価結果の数値が３０点となったことを示している。
【００８１】
（１４）（５）の処理と同様に、パス判断部１２１は、（１０）で属性判断部２２０から応答されたリスクレベルの評価結果の数値（３０点）をパス判断ＤＢ１５１の該当エントリの認証点数のフィールドに格納し、（２）と同様の処理を行う。ここでは、全ての認証が終了したものと判断されるため、パス判断ＤＢ１５１に格納された各認証手段についての認証点数を合否判定部１２２に送る。
【００８２】
（１５）合否判定部１２２は、ユーザＩＤ“Ａ１０００１”をキーとして合否判定ＤＢ１５２を参照して、パス判断部１２１から送られた各認証手段についての認証点数に基づいて、リスクレベルの評価結果の合計点を算出し、最終的な合否判定を行う。ここで、図３の合否判定ＤＢ１５２において、当該ユーザについては、“ＩＰアドレス判定”の合算時比率が２であり、“属性判断”の合算時比率が３であるため、合計点は、
合計点＝（１００点×２）＋（３０点×３）＝２９０点
となる。ここで、図３の合否判定ＤＢ１５２において、当該ユーザについては合格点が２００点であるため、合格と判定される。
【００８３】
（１６）（１５）における合否判定の結果が合格であるため、Ｗｅｂ ＡＰサーバ１００のＰＬ基盤部１３０や画面制御部１４０により通常の画面遷移を行い、クライアント端末６００に応答する。
【００８４】
なお、本実施の形態のリスクベース認証システムでは、上述した例のように、パス判断ＤＢ１５１の通過認証のフィールドに設定されている認証手段のみを実行し、それ以外の認証手段は行わないように構成しているが、バス判断ＤＢ１５１の設定に関わらずに全ての認証手段について実行し、パス判断ＤＢ１５１の通過認証のフィールドに設定されている認証手段についてのみ、合否判定部１２２におけるリスクレベルの合計点の算出の際に認証点数の加算対象とする（他の認証手段については、リスクレベルの評価は行うが、合計点の算出には寄与しない）という構成にしてもよい。
【００８５】
また、例えば、属性判断部２２０におけるリスクレベルの評価結果の数値化の際に、属性判断ＤＢ２５０における海外利用申請や口座残高認証強化申請のフィールドの値が“Ｙ”となっている場合のみ、当該項目の評価結果を数値化して加算するように構成しているが、値が“Ｎ”となっていた場合は一律に当該項目の評価結果として満点もしくは所定の点数を加算するように構成してもよい。
【００８６】
また、各認証手段におけるリスクレベルの評価結果や、合計点についての具体的な算出方法（各条件に対する配点や比率、評価を厳しくする際に減算する点数や圧縮比率、算出式など）は、上述したような例に限らず、種々の方法をとることができることは当然である。また、点数による評価に限らず、レベル等による評価であってもよい。
【００８７】
［システム構成の変形例］
以下では、本実施の形態のリスクベース認証システムのシステム構成の変形例について説明する。図９は、図１に示した本実施の形態のリスクベース認証システムを有するオンラインシステムのシステム構成例について概略を示した図である。
【００８８】
図９に示す構成では、リスクベース認証システムは多段認証接続部１２０と多段認証サーバ２００から構成され、多段認証接続部１２０は、パス判断部１２１と合否判定部１２２を有し、Ｗｅｂ ＡＰサーバ１００上に配置されている。また、多段認証サーバ２００は、リスクベース認証における各認証を行う認証手段を有する多段認証部であり、本実施の形態のリスクベース認証システムでは、リスクベース認証部２１０および属性判断部２２０、アプリケーション判断部２３０を有している。
【００８９】
図９に示す構成では、図１１に示す従来技術によるリスクベース認証システムに対して、Ｗｅｂ ＡＰサーバ１００とリスクベース認証サーバ８００にソフトウェアを新たに配置することによって実現する構成となっている。ここで、多段認証サーバ２００においては、例えば、従来技術によるリスクベース認証を行うリスクベース認証部２１０が製品等のパッケージとして実装されている場合、属性判断部２２０やアプリケーション判断部２３０を、リスクベース認証部２１０を構成するパッケージとは別のソフトウェアとして実装してもよいし、リスクベース認証部２１０を構成するパッケージ自体の機能拡張という形式で実装してもよい。
【００９０】
一方、図１０は、図９に示した本実施の形態のリスクベース認証システムを有するオンラインシステムの別のシステム構成例について概略を示した図である。図１０に示す構成では、リスクベース認証システムは多段認証サーバ７００とリスクベース認証サーバ８００から構成され、多段認証サーバ７００は、図９に示すパス判断部１２１、合否判定部１２２、属性判断部２２０、アプリケーション判断部２３０と同等の機能を有するパス判断部７１０、合否判定部７２０、属性判断部７３０、アプリケーション判断部７４０を有している。
【００９１】
図１０に示す構成では、リスクベース認証サーバ８００は図１１に示すものと同じであり、図１１に示す従来技術によるリスクベース認証システムに対して、Ｗｅｂ ＡＰサーバ１００とリスクベース認証サーバ８００との間に専用の多段認証サーバ７００を新たに構築することによって実現する構成となっている。
【００９２】
リスクベース認証システムの実装に際しては、図９の例で示したソフトウェアによる実装方式や、図１０の例で示した専用サーバによる実装方式、その他の構成によるものなどをシステム環境等により適宜選択して適用することが可能である。
【００９３】
以上に説明したように、本実施の形態のリスクベース認証システムによれば、従来技術によるリスクベース認証システムにおけるリスクベース認証に加えて、属性判断部２２０やアプリケーション判断部２３０などを有し、ユーザ毎の属性やトランザクションの属性に応じてリスクレベルの評価結果を変化させることが可能である。また、リスクレベルの評価の際の条件をユーザ毎に変更することが可能である。
【００９４】
また、リスクベース認証を行う入口の時点で、パス判断ＤＢ１５１により、どの認証を行うかをユーザ毎にカスタマイズすることができ、リスクレベルを評価する認証手段を必要に応じて新たに追加することも容易である。また、リスクベース認証の出口の合否判定の時点で、合否判定の方法をユーザ毎にカスタマイズすることもできる。これらにより、リスクベース認証においてリスクレベルの評価結果をユーザ属性やトランザクション属性、ユーザからの指示などに応じて変化させることができ、柔軟性のあるリスクベース認証を実現することが可能となる。
【００９５】
また、本実施の形態のリスクベース認証システムによれば、ユーザが事前に自分が使用する環境や、環境によって使用可能なトランザクションおよびその属性などを登録できるようにすることで、複数の環境から使用するユーザの利便性を高めるとともに、自分が使用しない環境からのアクセスに対する認証を強化することも可能となる。
【００９６】
以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。
【産業上の利用可能性】
【００９７】
本発明は、オンラインシステムなどにおいてリスクベース認証を行う認証システムおよび認証方法に利用可能である。
【図面の簡単な説明】
【００９８】
【図１】本発明の一実施の形態のリスクベース認証システムを有するオンラインシステムの構成例の概要を示す図である。
【図２】本発明の一実施の形態におけるパス判断ＤＢのデータ構成と具体的なデータの例を示した図である。
【図３】本発明の一実施の形態における合否判定ＤＢのデータ構成と具体的なデータの例を示した図である。
【図４】本発明の一実施の形態におけるリスクＤＢのデータ構成と具体的なデータの例を示した図である。
【図５】本発明の一実施の形態におけるＲＢＡ ＤＢのデータ構成と具体的なデータの例を示した図である。
【図６】本発明の一実施の形態における属性判断ＤＢのデータ構成と具体的なデータの例を示した図である。
【図７】本発明の一実施の形態におけるＡＰＬ判断ＤＢのデータ構成と具体的なデータの例を示した図である。
【図８】本発明の一実施の形態における処理の流れの例を示した図である。
【図９】本発明の一実施の形態のリスクベース認証システムを有するオンラインシステムのシステム構成例について概略を示した図である。
【図１０】本発明の一実施の形態のリスクベース認証システムを有するオンラインシステムの別のシステム構成例について概略を示した図である。
【図１１】従来技術によるリスクベース認証システムを有するオンラインシステムの構成例の概要を示す図である。
【符号の説明】
【００９９】
１００…Ｗｅｂ ＡＰサーバ、１１０…認証部、１２０…多段認証接続部、１２１…パス判断部、１２２…合否判定部、１３０…ＰＬ基盤部、１４０…画面制御部、１５１…パス判断ＤＢ、１５２…合否判定ＤＢ、２００…多段認証サーバ、２１０…リスクベース認証部、２１１…ＩＰアドレス判定部、２１２…ルール・行動分析部、２２０…属性判断部、２３０…アプリケーション判断部、２４１…リスクＤＢ、２４２…ＲＢＡ ＤＢ、２５０…属性判断ＤＢ、２６０…ＡＰＬ判断ＤＢ、３００…ＡＰＬサーバ、４００…ＤＢサーバ、４１０…顧客ＤＢ、５００…ネットワーク、６００…クライアント端末、
７００…多段認証サーバ、７１０…パス判断部、７２０…合否判定部、７３０…属性判断部、７４０…アプリケーション判断部、８００…リスクベース認証サーバ、８１０…ＩＰアドレス判定部、８２０…ルール・行動分析部、
８３１…リスクＤＢ、８３２…ＲＢＡ ＤＢ。
【特許請求の範囲】
【請求項１】
コンピュータシステムにおいてユーザからのアクセスに対して認証を行う際に、前記ユーザからの過去のアクセスの履歴情報やアクセス元の環境に基づいて、ルール分析や行動分析により前記アクセスについてのリスクレベルを評価し、その評価結果に基づいて前記アクセスに対する認証レベルを変更するリスクベース認証システムであって、
前記ルール分析や前記行動分析を行って前記アクセスについての前記リスクレベルを評価するリスクベース認証部と、
前記ユーザ毎の属性に関する情報に基づいて前記アクセスについての前記リスクレベルを評価する属性判断部と、
前記リスクベース認証部および前記属性判断部を含む、前記アクセスについての前記リスクレベルを評価する複数の認証手段を有する多段認証部と、
前記多段認証部の前記各認証手段に対して、前記リスクレベルの評価を依頼してその評価結果を取得するパス判断部と、
前記パス判断部が取得した前記各リスクレベルの評価結果に基づいて前記アクセスについての最終的な前記リスクレベルを評価し、その評価結果に基づいて前記アクセスに対する前記認証レベルを変更する合否判定部とを有することを特徴とするリスクベース認証システム。
【請求項２】
請求項１に記載のリスクベース認証システムにおいて、
前記多段認証部は、前記認証手段として、さらに、前記アクセスの対象であるアプリケーションの種別および前記アプリケーションに対するパラメータの情報に基づいて前記アクセスについての前記リスクレベルを評価するアプリケーション判断部を有することを特徴とするリスクベース認証システム。
【請求項３】
請求項１に記載のリスクベース認証システムにおいて、
前記属性判断部における前記リスクレベルを評価する際の条件を、前記ユーザ毎および前記属性毎に事前に設定可能であることを特徴とするリスクベース認証システム。
【請求項４】
請求項２に記載のリスクベース認証システムにおいて、
前記アプリケーション判断部における前記リスクレベルを評価する際の条件を、前記ユーザ毎および前記アプリケーションの種別毎に事前に設定可能であることを特徴とするリスクベース認証システム。
【請求項５】
請求項３または４に記載のリスクベース認証システムにおいて、
前記属性判断部における前記リスクレベルを評価する際の条件、および前記アプリケーション判断部における前記リスクレベルを評価する際の条件の組み合わせについての既定値を事前に設定可能であることを特徴とするリスクベース認証システム。
【請求項６】
請求項１または２に記載のリスクベース認証システムにおいて、
前記パス判断部における前記多段認証部に対して前記リスクレベルの評価の要求を依頼する際の対象となる前記認証手段の種類を、前記ユーザ毎に事前に設定可能であることを特徴とするリスクベース認証システム。
【請求項７】
請求項１または２に記載のリスクベース認証システムにおいて、
前記合否判定部における前記アクセスについての最終的な前記リスクレベルを評価する際の条件および前記アクセスに対する前記認証レベルを変更する基準を、前記ユーザ毎に事前に設定可能であることを特徴とするリスクベース認証システム。
【請求項８】
コンピュータシステムにおいてユーザからのアクセスに対して認証を行う際に、前記ユーザからの過去のアクセスの履歴情報やアクセス元の環境に基づいて、ルール分析や行動分析により前記アクセスについてのリスクレベルを評価し、その評価結果に基づいて前記アクセスに対する認証レベルを変更するリスクベース認証方法であって、
前記コンピュータシステムは、前記ユーザからの前記アクセスを受けた際に、
前記ルール分析や前記行動分析を行って前記アクセスについての前記リスクレベルを評価するリスクベース認証と、
前記ユーザ毎の属性に関する情報に基づいて前記アクセスについての前記リスクレベルを評価する属性判断と、
前記アクセスの対象であるアプリケーションの種別および前記アプリケーションに対するパラメータの情報に基づいて前記アクセスについての前記リスクレベルを評価するアプリケーション判断とのうち、
前記ユーザにより事前に設定された条件に基づいて少なくとも１つ以上の認証手順を実行して、前記各認証手順による前記リスクレベルの評価結果を取得し、
前記各認証手順により取得した前記リスクレベルの評価結果に基づいて前記アクセスについての最終的な前記リスクレベルを評価し、その評価結果に基づいて前記アクセスに対する前記認証レベルを変更することを特徴とするリスクベース認証方法。
【請求項１】
コンピュータシステムにおいてユーザからのアクセスに対して認証を行う際に、前記ユーザからの過去のアクセスの履歴情報やアクセス元の環境に基づいて、ルール分析や行動分析により前記アクセスについてのリスクレベルを評価し、その評価結果に基づいて前記アクセスに対する認証レベルを変更するリスクベース認証システムであって、
前記ルール分析や前記行動分析を行って前記アクセスについての前記リスクレベルを評価するリスクベース認証部と、
前記ユーザ毎の属性に関する情報に基づいて前記アクセスについての前記リスクレベルを評価する属性判断部と、
前記リスクベース認証部および前記属性判断部を含む、前記アクセスについての前記リスクレベルを評価する複数の認証手段を有する多段認証部と、
前記多段認証部の前記各認証手段に対して、前記リスクレベルの評価を依頼してその評価結果を取得するパス判断部と、
前記パス判断部が取得した前記各リスクレベルの評価結果に基づいて前記アクセスについての最終的な前記リスクレベルを評価し、その評価結果に基づいて前記アクセスに対する前記認証レベルを変更する合否判定部とを有することを特徴とするリスクベース認証システム。
【請求項２】
請求項１に記載のリスクベース認証システムにおいて、
前記多段認証部は、前記認証手段として、さらに、前記アクセスの対象であるアプリケーションの種別および前記アプリケーションに対するパラメータの情報に基づいて前記アクセスについての前記リスクレベルを評価するアプリケーション判断部を有することを特徴とするリスクベース認証システム。
【請求項３】
請求項１に記載のリスクベース認証システムにおいて、
前記属性判断部における前記リスクレベルを評価する際の条件を、前記ユーザ毎および前記属性毎に事前に設定可能であることを特徴とするリスクベース認証システム。
【請求項４】
請求項２に記載のリスクベース認証システムにおいて、
前記アプリケーション判断部における前記リスクレベルを評価する際の条件を、前記ユーザ毎および前記アプリケーションの種別毎に事前に設定可能であることを特徴とするリスクベース認証システム。
【請求項５】
請求項３または４に記載のリスクベース認証システムにおいて、
前記属性判断部における前記リスクレベルを評価する際の条件、および前記アプリケーション判断部における前記リスクレベルを評価する際の条件の組み合わせについての既定値を事前に設定可能であることを特徴とするリスクベース認証システム。
【請求項６】
請求項１または２に記載のリスクベース認証システムにおいて、
前記パス判断部における前記多段認証部に対して前記リスクレベルの評価の要求を依頼する際の対象となる前記認証手段の種類を、前記ユーザ毎に事前に設定可能であることを特徴とするリスクベース認証システム。
【請求項７】
請求項１または２に記載のリスクベース認証システムにおいて、
前記合否判定部における前記アクセスについての最終的な前記リスクレベルを評価する際の条件および前記アクセスに対する前記認証レベルを変更する基準を、前記ユーザ毎に事前に設定可能であることを特徴とするリスクベース認証システム。
【請求項８】
コンピュータシステムにおいてユーザからのアクセスに対して認証を行う際に、前記ユーザからの過去のアクセスの履歴情報やアクセス元の環境に基づいて、ルール分析や行動分析により前記アクセスについてのリスクレベルを評価し、その評価結果に基づいて前記アクセスに対する認証レベルを変更するリスクベース認証方法であって、
前記コンピュータシステムは、前記ユーザからの前記アクセスを受けた際に、
前記ルール分析や前記行動分析を行って前記アクセスについての前記リスクレベルを評価するリスクベース認証と、
前記ユーザ毎の属性に関する情報に基づいて前記アクセスについての前記リスクレベルを評価する属性判断と、
前記アクセスの対象であるアプリケーションの種別および前記アプリケーションに対するパラメータの情報に基づいて前記アクセスについての前記リスクレベルを評価するアプリケーション判断とのうち、
前記ユーザにより事前に設定された条件に基づいて少なくとも１つ以上の認証手順を実行して、前記各認証手順による前記リスクレベルの評価結果を取得し、
前記各認証手順により取得した前記リスクレベルの評価結果に基づいて前記アクセスについての最終的な前記リスクレベルを評価し、その評価結果に基づいて前記アクセスに対する前記認証レベルを変更することを特徴とするリスクベース認証方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公開番号】特開２０１０−９７４６７（Ｐ２０１０−９７４６７Ａ）
【公開日】平成２２年４月３０日（２０１０．４．３０）
【国際特許分類】
【出願番号】特願２００８−２６８４５２（Ｐ２００８−２６８４５２）
【出願日】平成２０年１０月１７日（２００８．１０．１７）
【出願人】（０００１５５４６９）株式会社野村総合研究所 (1,067)
【Ｆターム（参考）】
【公開日】平成２２年４月３０日（２０１０．４．３０）
【国際特許分類】
【出願日】平成２０年１０月１７日（２００８．１０．１７）
【出願人】（０００１５５４６９）株式会社野村総合研究所 (1,067)
【Ｆターム（参考）】
[ Back to top ]