JP6564841B2 - 照合サーバ、照合方法及びコンピュータプログラム - Google Patents

Description

本発明は、ユーザに対して所定のサービスを提供する各種サイトが利用しうる照合サーバに関する。また、当該照合サーバによる照合方法及び関連するコンピュータプログラムに関する。

従来、インターネットなどのネットワーク上でユーザに対して種々のサービスを提供するＷｅｂサイト（サービス提供システム）が知られている。

このＷｅｂサイトを利用したいユーザは、与えられているＩＤとパスワートを用いて、Ｗｅｂサイトにアクセス・ログインを行い、Ｗｅｂサイトを利用して所望のサービスを受けることができる。

例えば、ショッピングモールのＷｅｂサイトを利用するユーザは、ＩＤとパスワードを利用してそのＷｅｂサイトにログインし、そのＷｅｂサイトが提供する各ページを移動し、所望の商品を見つけることができたページで商品の購入を実行することができる。

従来のＷｅｂサイトにおいては、正規のユーザのみが利用可能にするために、ＩＤとパスワードが利用される場合が多い。このＩＤとパスワードとを利用することによって、いわゆる悪意の侵入者を排除することができ、円滑なサービスの利用を図ることができると考えられている。

＜悪意のアクセス＞
しかし、近年、悪意のある第三者が不正な手段を用いて他人のＩＤとパスワードとを入手する事件が報告されている。このように悪意のある第三者が（正規のユーザである）他人のＩＤとパスワードを用いて、Ｗｅｂサイトにログインした場合、そのＩＤとパスワードだけでは、そのログイン者が、正規のユーザか、悪意のある第三者かを区別することは困難である。

そこで、近年、正規のユーザが実行するログイン以降の動作の情報を記録しておき、ホワイトリストとしてデータベース化しておく仕組みが知られている。ここで、記録する動作の情報としては、例えば、下記のような情報が好ましい。

・ＯＳ
・ブラウザ
・言語
・ＩＰアドレス（アクセスを実行しているユーザの地理的な位置を表す）
・時間（アクセスした時刻）
これらの情報を記録し、いわゆるホワイトリスト（ＷｈｉｔｅＬｉｓｔ）としてデータベースを構築しておけば、ログインしてきたユーザがいつもと異なる動作をとっていることを検知することが可能である。このように、いつもと異なる動作をとるユーザに対しては、悪意のある第三者ではないことを確認するため、追加認証を実行することが好ましい。例えば、ユーザの携帯電話やスマートホン等に対して、「現在貴方のＩＤを用いて以下のＷｅｂサイトへのアクセスが行われています。このアクセスは貴方自身によるものですか。そうでない場合は、ＮＯボタンを押下（タッチ）してください」というメッセージを送り、「ＮＯボタン」が押された（タッチされた）場合は、正規のユーザではなく、悪意のある第三者がアクセスしていると判断することができる。そして、直ちに当該ユーザのアクセスを切断する処理をとることができる。

例えば、いつもとは別の場所（ＩＰアドレス）からアクセスされた場合や、いつもとは異なるパソコン（ＯＳ、ブラウザ）からアクセスされた場合等が挙げられる。このような場合に、追加認証が実行されて、正規のユーザか否かが確認される（本人確認とも呼ばれる）。
また、ホワイトリストは、当該正規のユーザによる過去の数１０回程度のアクセスに基づき構築される場合が多いが、より少ない場合もあり（数回）、またより多い場合（数１００回）もある。さらに、ホワイトリストは、正規のユーザがアクセスする度に新しい情報と置き換えられ、更新されるように構成される場合もある。
また、同様に、悪意の第三者のデータを、ブラックリストとして構築することも利用されている。これら、ホワイトリストや部落リストを用いれば、悪意の第三者と、正規のユーザとを効率的に区別することができると考えられている。

先行特許文献
例えば、下記特許文献１には、ホワイトリストと、ブラックリストとを用いて、コンテンツの情報を検索する装置が開示されている。両リストを用いることによって、プライバシーが保護されると同文献には記載されている。

また、例えば、下記特許文献２には、ホワイトリストと、ブラックリストとを用いて、Ｗｅｂサイトへのアクセスを制御するアクセス制御システムが開示されている。
また、例えば、下記特許文献３には、記憶媒体へのアクセスを制限する仕組みについて工夫された記憶媒体が開示されている。その仕組みにおいて、ホワイトリスト、ブラックリストが利用されている。

特開２０１２−１５９９３９号公報 特開２０１１−３１３２号公報 特開２０１１−２４８４７４号公報

このように、従来のＷｅｂサイトにおいては、正規ユーザのアクセスの動作の情報をホワイトリストとして記録しておき、このホワイトリストと大きく異なる動作をとるユーザに対しては適宜追加認証を行っていた。

しかし、悪意のある第三者は、当然巧妙に正規のユーザ本人になりすましているので、それを見破ることは一般に困難であることもある。したがって、セキュリティ担当者の経験則によって対処している場合も多い。例えば、金融機関のＷｅｂサイトにおける預金口座からの引き出し限度額一杯の預金の引き出しは、悪意のある第三者である可能性が高い等の経験則に頼り、悪意のある第三者を発見している場合もある。

さらに、ＩＤやパスワードは、複数のＷｅｂサイトに対して、共通のＩＤとパスワードが用いられる場合も多い。この場合、１組のＩＤ及びパスワードが不正に悪意のある第三者に取得されてしまった場合、複数のＷｅｂサイトに対して連続して不正なアクセスが実行されてしまう場合も散見される。
このような場合、ある一つのＷｅｂサイトへの不正アクセスが検出された場合に、その情報を他のＷｅｂサイトの事業者に提供することが、上述した共通のＩＤとパスワードを利用することによる連続した不正アクセスを防ぐために効果的であると考えられる。

本願発明者は、そのような仕組みについて、２０１６年５月３日に、特許出願の特願２０１６−０９２８５０（以下、先行特許出願と呼ぶ）をしている。
本願発明者によるこの先行特許出願においては、ホワイトリストだけでなく、ブラックリストを用いて、不正なアクセスを効率的に検出し、その結果を共有する仕組みを提案している。

ホワイトリストやブラックリスト等は、アクセスしてきた者の情報を記録するものであり、これらに基づきアクセスをしてきたユーザが正規ユーザか否かの検知をより効率的にすることができると考えられる。
しかし、悪意でアクセスを行う者は、例えば同一のサイトに対して何度も失敗アクセスを繰り返すような、正規のユーザとは明らかに異なる振る舞いを行うことが経験的に知られている。

ここで、ホワイトリストやブラックリストは、アクセスしてきた者の人的・静的なデータであり、どのようなログイン行為（履歴）を行っているか、どのようなログイン動作をこれまで実行してきたかのような「ログイン履歴」「振る舞い」に関する情報はほとんど有していない。

そこで、上述したホワイトリスト、ブラックリストに加えて、いわゆるログインヒストリーを用いて、アクセスしてきた者の振る舞いに基づいて、正規ユーザか、悪意のアクセス者か、を判断する仕組みがあれば好ましいが、未だ、そのような仕組みは知られていない。

本発明は、係る課題に鑑みなされたものであり、その目的は、いわゆるログインヒストリーを利用してそのアクセスが、不正なアクセスであるか、正規ユーザによる正当なアクセスであるか、をより効率的に検知する技術を提供することである。

（１）本発明は、上記課題を解決するために、外部との通信を行う通信部であって、外部からログイン履歴を受信し、制御部に送信する通信部と、前記通信部から送信されてきたログイン履歴をログインヒストリーデータベースに登録する前記制御部と、前記ログイン履歴を保持する前記ログインヒストリーデータベースと、を備える照合サーバであって、前記制御部は、前記送信されてきたログイン履歴が成功履歴である場合に、前記ログイン履歴を、前記ログインヒストリーデータベースが保持するログイン履歴と比較し、前記ログインがこれまでのログインの振る舞いと同様の振る舞いではないときに、本人らしくない旨のメッセージを、前記通信部を介して送信することを特徴とする照合サーバである。

（２）また、本発明は、（１）記載の照合サーバにおいて、さらに、悪意のハッカーの情報を保持するブラックリストデータベース、を備え、前記制御部は、前記送信されてきたログイン履歴が成功履歴である場合に、前記ログイン履歴を、前記ブラックリストデータベースの登録内容と比較し、同様のデータが存在する場合は、悪意のハッカーである旨のメッセージを前記通信部を介して送信することを特徴とする照合サーバである。

（３）また、本発明は、（１）記載の照合サーバにおいて、さらに、正規のユーザの情報を保持するホワイトリストデータベース、を備え、前記制御部は、前記送信されてきたログイン履歴が成功履歴である場合に、前記ログイン履歴を、前記ホワイトリストデータベースの登録内容と比較し、同様のデータが存在する場合は、正規のユーザである旨のメッセージを前記通信部を介して送信することを特徴とする照合サーバである。

（４）本発明は、上記課題を解決するために、外部との通信を行う通信部であって、外部からログイン履歴を受信し、制御部に送信する通信部と、前記通信部から送信されてきたログイン履歴をログインヒストリーデータベースに登録する前記制御部と、前記ログイン履歴を保持する前記ログインヒストリーデータベースと、悪意のハッカーの情報を保持するブラックリストデータベースと、正規のユーザの情報を保持するホワイトリストデータベースと、を備える照合サーバであって、前記制御部は、前記送信されてきたログイン履歴が成功履歴である場合に、前記ログイン履歴を、前記ブラックリストデータベースの登録内容と比較し、同様のデータが存在する場合は、悪意のハッカーである旨のメッセージを前記通信部を介して送信し、前記ブラックリストデータベースの登録内容と比較の結果、同様のデータが存在しない場合は、前記ログイン履歴を、前記ログインヒストリーデータベースが保持するログイン履歴と比較し、前記ログインヒストリーデータベースが保持するログイン履歴と比較の結果、前記ログイン履歴がこれまでのログインの振る舞いと同様の振る舞いではないときは、前記ログイン履歴を、前記ホワイトリストデータベースの登録内容と比較し、前記ホワイトリストデータベースの登録内容との比較の結果、同様のデータが存在する場合は、正規のユーザである旨のメッセージを前記通信部を介して送信し、同様のデータが存在しない場合は、本人らしくない旨のメッセージを、前記通信部を介して送信することを特徴とする照合サーバである。

（５）また、本発明は、（２）又は（４）記載の照合サーバにおいて、前記通信部は、外部からブラックリスト登録要求を受信し、前記制御部に送信し、前記制御部は、前記通信部から送信されてきたブラックリスト登録要求に含まれる悪意のハッカーの情報を、前記ブラックリストデータベースに登録することを特徴とする照合サーバである。

（６）また、本発明は、（３）又は（４）記載の照合サーバにおいて、前記通信部は、外部からホワイトリスト登録要求を受信し、前記制御部に送信し、前記制御部は、前記通信部から送信されてきたホワイトリスト登録要求に含まれる正規のユーザの情報を、前記ホワイトリストデータベースに登録することを特徴とする照合サーバである。

（７）本発明は、上記課題を解決するために、外部との通信を行う通信部であって、外部からログイン履歴を受信し、制御部に送信する通信部と、前記通信部から送信されてきたログイン履歴をログインヒストリーデータベースに登録する前記制御部と、前記ログイン履歴を保持する前記ログインヒストリーデータベースと、を備える照合サーバを用いて、前記ログイン履歴が、本人らしいか否か照合する照合方法であって、前記制御部が、前記送信されてきたログイン履歴が成功履歴である場合に、前記ログイン履歴を、前記ログインヒストリーデータベースが保持するログイン履歴と比較し、前記ログインがこれまでのログインの振る舞いと同様の振る舞いではないときに、本人らしくない旨のメッセージを、前記通信部を介して送信するステップ、を含むことを特徴とする照合方法である。

（８）本発明は、上記課題を解決するために、外部との通信を行う通信部であって、外部からログイン履歴を受信し、制御部に送信する通信部と、前記通信部から送信されてきたログイン履歴をログインヒストリーデータベースに登録する前記制御部と、前記ログイン履歴を保持する前記ログインヒストリーデータベースと、悪意のハッカーの情報を保持するブラックリストデータベースと、正規のユーザの情報を保持するホワイトリストデータベースと、を備える照合サーバを用いて、前記ログイン履歴が、本人らしいか否か照合する照合方法であって、前記制御部が、前記送信されてきたログイン履歴が成功履歴である場合に、前記ログイン履歴を、前記ブラックリストデータベースの登録内容と比較し、同様のデータが存在する場合は、悪意のハッカーである旨のメッセージを前記通信部を介して送信するステップと、前記制御部が、前記ブラックリストデータベースの登録内容と比較の結果、同様のデータが存在しない場合は、前記ログイン履歴を、前記ログインヒストリーデータベースが保持するログイン履歴と比較するステップと、前記制御部が、前記ログインヒストリーデータベースが保持するログイン履歴と比較の結果、前記ログイン履歴がこれまでのログインの振る舞いと同様の振る舞いではないときは、前記ログイン履歴を、前記ホワイトリストデータベースの登録内容と比較するステップと、前記制御部が、前記ホワイトリストデータベースの登録内容との比較の結果、同様のデータが存在する場合は、正規のユーザである旨のメッセージを前記通信部を介して送信し、同様のデータが存在しない場合は、本人らしくない旨のメッセージを、前記通信部を介して送信するステップと、を含むことを特徴とする照合方法である。

（９）本発明は、上記課題を解決するために、外部との通信を行う通信部であって、外部からログイン履歴を受信し、制御部に送信する通信部と、前記通信部から送信されてきたログイン履歴をログインヒストリーデータベースに登録する前記制御部と、前記ログイン履歴を保持する前記ログインヒストリーデータベースと、を備える照合サーバとして、コンピュータを動作させるコンピュータプログラムであって、前記制御部が、前記送信されてきたログイン履歴が成功履歴である場合に、前記ログイン履歴を、前記ログインヒストリーデータベースが保持するログイン履歴と比較し、前記ログインがこれまでのログインの振る舞いと同様の振る舞いではないときに、本人らしくない旨のメッセージを、前記通信部を介して送信する手順、を前記コンピュータに実行させることを特徴とするコンピュータプログラムである。

（１０）本発明は、上記課題を解決するために、外部との通信を行う通信部であって、外部からログイン履歴を受信し、制御部に送信する通信部と、前記通信部から送信されてきたログイン履歴をログインヒストリーデータベースに登録する前記制御部と、前記ログイン履歴を保持する前記ログインヒストリーデータベースと、悪意のハッカーの情報を保持するブラックリストデータベースと、正規のユーザの情報を保持するホワイトリストデータベースと、を備える照合サーバとして、コンピュータを動作させるコンピュータプログラムであって、前記制御部が、前記送信されてきたログイン履歴が成功履歴である場合に、前記ログイン履歴を、前記ブラックリストデータベースの登録内容と比較し、同様のデータが存在する場合は、悪意のハッカーである旨のメッセージを前記通信部を介して送信する手順と、前記制御部が、前記ブラックリストデータベースの登録内容と比較の結果、同様のデータが存在しない場合は、前記ログイン履歴を、前記ログインヒストリーデータベースが保持するログイン履歴と比較する手順と、前記制御部が、前記ログインヒストリーデータベースが保持するログイン履歴と比較の結果、前記ログイン履歴がこれまでのログインの振る舞いと同様の振る舞いではないときは、前記ログイン履歴を、前記ホワイトリストデータベースの登録内容と比較する手順と、前記制御部が、前記ホワイトリストデータベースの登録内容との比較の結果、同様のデータが存在する場合は、正規のユーザである旨のメッセージを前記通信部を介して送信し、同様のデータが存在しない場合は、本人らしくない旨のメッセージを、前記通信部を介して送信する手順と、を前記コンピュータに実行させることを特徴とするコンピュータプログラムである。

このように、本発明によれば、ログインヒストリーを用いて、正規のユーザであるか否かを判断する仕組みを構築しているので、正規のユーザではないと判断されたユーザによるアクセスをより効率的に検出することが可能となる。

本実施形態１において、悪意のハッカーが複数のサイトにアクセスする様子を示す説明図である。 本実施形態２において、正当なユーザ１８が複数のサイトにアクセスする様子を示す説明図である。 本実施形態１における照合サーバ２０の動作を表すフローチャートである。 本実施形態１における照合サーバ２０の動作を表すフローチャートの続きである。 本実施形態２における照合サーバ４０の動作を表すフローチャートである。 本実施形態２における照合サーバ４０の動作を表すフローチャートの続きである。 本実施形態１、２におけるログインヒストリーデータベース２６、４６に登録する内容の例を示す説明図である。 本実施形態１、２におけるホワイトリストデータベース４８、ブラックリストデータベース２８に登録する内容の例を示す説明図である。

以下、本発明の好適な実施形態を図面に基づき説明する。
実施形態１
１−１．基本的構成
本実施形態１は、複数のサイトが、自サイトにアクセスするユーザが正規のユーザであるか否かを、共通の照合サーバを利用して判断する例を説明する。図１には、このような複数のサイト（例えばショッピングモール）が、共通の照合サーバ２０を利用する例が示されている。

図１において、ハッカー８は、悪意のあるハッカーであり、正規のユーザではないが、正規のユーザになりすます等の不正な手段を用いて、サイト１０ａ、１０ｂ、１０ｃ、１０ｄ等にアクセスしようとしている。

ハッカー８は、インターネット等のネットワークを介して提供するためのサイト１０ａ、１０ｂ、１０ｃ、１０ｄに対して不正なアクセスを試みる。例えば、ハッカー８は、リスト型攻撃やなりすまし等の手法を用いて不正アクセスを試みる。
なりすましは、他人になりすまして所定のサイトやサービスにアクセスして乗っ取る攻撃手法であり、近年は、いわゆるリスト型攻撃と呼ばれる手段が利用されることも多い。

リスト型攻撃は、各種のサイトやサービスに対して、そのユーザのアカウントを乗っ取る攻撃手法の一つである。例えば、別のサービスやシステムから流出したアカウント情報を用いてそのサービスやサイトにログインを試みる手法である。これは、同じアカウント名とパスワードとを複数のサイトやサービスに利用しているユーザが多いことを利用した攻撃手法であり、ある一つのサイトから流出したアカウント名（ＩＤ）やパスワードを用いて、他のサイトに侵入を試みるものである。同じアカウント名（ＩＤ）やパスワードを用いていれば、当該他のサイトにおいてユーザのアカウントが乗っ取られてしまう。リスト型攻撃は、パスワードリスト攻撃、リスト型アカウントハッキング、アカウントリスト攻撃等とも呼ばれる。

１−２．動作
図１の例では、ハッカー８は、正規のユーザのＩＤとパスワード（ＰＷ）を入手し、この情報を用いてリスト型攻撃を利用し、サイト１０ａ、１０ｂ、１０ｃ、１０ｄに対して不正なアクセスを試みる。
照合サーバ２０は、各サイト１０ａ、１０ｂ、１０ｃ、１０ｄにおけるログインの情報（ログイン履歴）を各サイト１０（ａ〜ｄ）から受信し、内部のログインヒストリーに記憶していく。本実施形態１において特徴的な構成は、この照合サーバ２０であり、各サイト１０（ａ〜ｃ）からのログイン履歴を蓄積することによって、各サイト１０（ａ〜ｃ）に代わって、アクセスしてきた者が正規ユーザとして怪しい（本人らしくない）か否かを判断するので、各サイト１０（ａ〜ｃ）にとって便利である。

図１に示すように、照合サーバ２０は、通信部２２と、制御部２４と、ログインヒストリーデータベース２６と、ブラックリストデータベース２８と、を備えている。ログインヒストリーデータベース２６は、外部の種々のサイトからの指示・依頼によって当該サイトへのログインのヒストリー（ログイン履歴）を記憶するデータベースである。ログイン履歴は、ログインが成功する場合も失敗する場合も含めて記憶する。

通信部２２は、インターネット等のネットワークを介して外部の各種サイト等と通信を行うインターフェースであり、インターネット以外の通信手段を利用してもよく、いわゆる（携帯）電話網を利用する通信インターフェースであってもよい。通信部２２は、請求の範囲の通信部の好適な一例に相当する。

制御部２４は、照合サーバ２０の動作を司る手段であり、具体的には、ログインヒストリーデータベース２６と、ブラックリストデータベース２８との記憶を制御し、また、これらデータベースに関する種々の動作を実行する。例えばＣＰＵとそのＣＰＵが実行するプログラムとから構成してよい。そのプログラムは、照合サーバ２０が実行する処理が記述されているプログラムである。また、そのプログラムは、請求の範囲のコンピュータプログラムの好適な一例に相当する。

ログインヒストリーデータベース２６は、照合サーバ２０がサポートしているサイト１０（ａ〜ｄ）からユーザ（または悪意のハッカー８）がログインした際のログインの情報（ログイン履歴（ログインヒストリー））を記憶するデータベースである。
ブラックリストデータベース２８は、悪意のあるハッカー８であると判断された相手の情報を記憶するデータベースである。
ログインヒストリーデータベース２６も、ブラックリストデータベース２８も、例えばハードディスク等の記憶手段で構成することができる。また、半導体記憶装置や、光学式の記憶装置を用いて構成してもよい。また、ログインヒストリーデータベース２６は、請求の範囲のログインヒストリーデータベースの好適な一例に相当する。また、ブラックリストデータベース２８も、請求の範囲のブラックリストデータベースの好適な一例に相当する。

ログイン
サイト１０ａは、ユーザがパスワードを定期的に変更しているサイト１０ａであり、その結果、ハッカー８は、そのサイト１０ａにとっては古いＩＤとパスワードとを使用することになり、ログインが失敗する。すると、サイト１０ａは、そのログインが失敗したというログイン失敗履歴を、照合サーバ２０に送信する。照合サーバ２０は、送信されてきたログイン失敗履歴（ログイン履歴（ログインヒストリー））を、その内部のログインヒストリーデータベース２６に記憶する。

サイト１０ｂも、サイト１０ａと同様に、ユーザがパスワードを頻繁に更新しているサイト１０ｂであり、その結果、ハッカー８は、そのサイト１０ｂにとっては古いＩＤとパスワードとを使用することになり、ログインを失敗する。すると、サイト１０ｂは、サイト１０ａと同様に、そのログインが失敗したというログイン失敗履歴を、照合サーバ２０に送信する。照合サーバ２０は、送信されてきたログイン動作（ログイン履歴）を、その内部のログインヒストリーデータベース２６に記憶する。

サイト１０ｃは、サイト１０ａ、１０ｂとは異なり、ユーザがパスワードを頻繁に更新しておらず、その結果、ハッカー８は、他所から流出した正規ユーザのＩＤやパスワードを流用してそのサイト１０ｃに適用して、ログインが成功してしまう。すると、サイト１０ｃにおいて、ハッカー８はログインを成功させてしまう。
ログインが成功する／失敗するにかかわらず、各サイト１０（ａ〜ｄ）はログインの情報を照合サーバ２０に送信する。サイト１０ｃも、ログインが成功したが、上記サイト１０ａ、１０ｂと同様に、ハッカー８によるログイン動作を照合サーバ２０に送信し、照合サーバ２０はログイン履歴をログインヒストリーデータベース２６に記憶していく。

照合サーバ２０によるログイン履歴の検査
照合サーバ２０は、送信されてくるログイン履歴がログイン失敗履歴であっても成功履歴であってもログインヒストリーデータベース２６に記憶していく。
上で述べたように、サイト１０ｃでは、正しいＩＤとパスワードによって、本人認証が成功し、ログインが成功する。そして、サイト１０ｃは、そのログイン（成功）履歴を照合サーバ２０に送信する。
ログイン履歴が送信されてきた場合の照合サーバ２０の動作が、図３、図４のフローチャートに記載されている。

図３のステップＳ３−１において、まず、所定のサイト１０（ａ〜ｃ）からログイン履歴が送信されてきた場合、通信部２２がこれを受信し、制御部２４に送る。
ステップＳ３−２において、制御部２４は、送られてきたログイン履歴をログインヒストリーデータベース２６に順次格納していく。
ステップＳ３−３において、制御部２４は、送られてきたログイン履歴を見て、そのログイン履歴が成功履歴であるか否か判断する。判断の結果、成功履歴であった場合は、ステップＳ３−４に移行し、失敗履歴であった場合は、終了する。

ステップＳ３−４において、制御部２４は、送られてきたログイン履歴を、ブラックリストデータベース２８の登録内容と比較する。
ステップＳ３−５において、上記ステップＳ３−４における比較の結果、同様のデータが登録されていた場合は、アクセスをしてきた者は、悪意のあるアクセス者であると判断できるので、ステップＳ３−６に移行する。一方、同様のデータが登録されていない場合は、図４のステップＳ４−１に移行する。

ステップＳ３−６において、制御部２４は、悪意のあるハッカーである旨のメッセージを通信部２２を介して、ログイン履歴を送信してきたサイト１０（ａ〜ｄ）に送信する。そして、処理を終了する。この結果、当該サイト１０（ａ〜ｄ）は、ログイン拒否を実行することができ、悪意のあるアクセスを防止することができる。
図１に示す例において、サイト１０ｃがログイン成功履歴を送信してきた場合、図３のステップＳ３−５において、同様のデータが、まだブラックリストデータベース２８には登録されていなかった場合の動作を説明する。この場合、ステップＳ３−５において、アクセスしてきた者と同様のデータがブラックリストデータベース２８に登録されていないので、図４のステップＳ４−１に移行する。

図４のステップＳ４−１において、制御部２４は、送られてきたログイン履歴を送ったサイトのこれまでのログイン履歴をログインヒストリーデータベース２６から参照する。
次に、ステップＳ４−２において、参照したこれまでのログイン履歴のログインの様子と、今回のログイン（成功）履歴とを比較し、ログイン動作の振る舞いがこれまでと同様か否かを判断する。判断の結果、これまでのログイン動作の振る舞いと異なる場合は、本人（正規のユーザ）らしくないと判断し、ステップＳ４−３に移行する。一方、判断の結果、これまでのログイン動作の振る舞いと同様である場合は、ログイン履歴の検査の動作を終了し、ログイン履歴の記憶動作を終了する。そして、次のログイン履歴が送信されてくるのを待つ状態となる。
振る舞いの判断は、種々の手法を利用してよい。着目しているログイン動作を、ログインヒストリーデータベース２６中の内容と比較し、一致・類似するパラメータが多い場合を、振る舞いが同様である（共通する・類似する）と判断してもよい。また、多くのパラメータが一致・類似・共通すれば、大きく異なるパラメータが一つ見つかっても同様の振る舞いであると判断してもよい。また、パラメータの種類に応じて重みを設けてもよい。

ステップＳ４−３において、制御部２４は、正規のユーザである本人らしくないことをサイト１０ｃに伝える。例えば、「本人らしくない」等のメッセージを当該サイト１０ｃに、通信部２２を介して送信する。

このように、本実施形態の照合サーバ２０は、単にログイン履歴を記憶していくだけでなく、
・送信されてきたログイン履歴から、同様の内容がブラックリストデータベース２８に登録されているか否か判断する。ブラックリストデータベース２８に登録されていた場合は、その旨を当該サイト１０に送信する。
・さらに、ブラックリストデータベース２８に登録されていない場合でも、ログイン履歴の振る舞いを、ログインヒストリーデータベース２６中の当該サイト１０（ａ〜ｃ）のログイン履歴と同様の振る舞いか否かを判断し、これまでと異なるログイン動作の振る舞いである場合は、その旨（例えば、「本人らしくない」等のメッセージ）を当該サイト１０ｃに送信している。
このような動作によって、各サイト１０は、アクセスしてきた者が、正規のユーザであるか否か（悪意のアクセス者であるか否か）を効率的に判断することができ、便利である。

サイト１０ｃにおける２要素認証の実行
さて、図１に示す例では、サイト１０ｃが、ログインは成功したが、照合サーバ２０から「本人らしくない」とのメッセージを受信する（図４のステップＳ４−３）。サイト１０ｃは、これを受けて、例えば、２要素認証３０を実行することができる。
２要素認証とは、異なる２要素に基づき認証を行う方式である。例えば、サイト１０ｃは、ワンタイムパスワードをログインしようとしている「ユーザ」の携帯電話に送信する。ユーザは自己の携帯電話からワンタイムパスワードを読み取り、サイト１０ｃに入力する。サイト１０ｃは、入力されたワンタイムパスワードが自己が送信したワンタイムパスワードと同一パスワードであれば、正当な本人であると判断する。

いわゆる認証のための認証データには、「本人のみが知っていること（もの）（パスワード）」、「本人だけが所有するもの（キャッシュカード、携帯電話）」、「本人自身の特性（バイオメトリックデータ）」、等およそ３種の認証データが用いられるが、このうち異なる２種を使用して認証する方式は「２要素認証」と呼ばれる。上で説明した例では、最初の「パスワード」に加えて、新たに本人のみが所有する「携帯電話」が２番目の認証データとして用いられている。その電話番号の携帯電話は本人のみが所有するはずであることに基づくものである。本実施形態１では、このような２種の認証データを用いているが、他の２種の認証データを用いてもよい。

図１に示す例では、この２要素認証３０の結果、本人ではないことが判明したので、ログインは拒否している（図１中、ログイン拒否３２）。このログイン拒否３２となった場合は、悪意のハッカー８であると認定し、ブラックリストデータベース２８に登録する。すなわち、サイト１０ｃは、照合サーバ２０に対してブラックリスト登録要求を送信する。

照合サーバ２０によるブラックリストデータベース２８への登録
照合サーバ２０は、送信されてくるブラックリスト登録要求を受信すると、その内容をブラックリストデータベース２８に登録する。
具体的には、まず通信部２２がブラックリスト登録要求を受信する。
次に、通信部２２がブラックリスト登録要求を制御部２４に送信する。
制御部２４は、ブラックリスト登録要求を受信すると、その要求に従って、ハッカー８に付いての情報を、ブラックリストデータベース２８に登録する。このブラックリストデータベース２８の登録内容は、ハッカー８を識別することができればどのような登録内容でもよい。

ログインヒストリーデータベース２６とブラックリストデータベース２８の活用
図１の例によれば、ハッカー８は、サイト１０ｄにも、他のサイト１０ａ、１０ｂ、１０ｃと同様に、リスト型攻撃を実行する例が記載されている。
サイト１０ｄも照合サーバ２０を利用しており、ログイン履歴を照合サーバ２０中のログインヒストリーデータベース２６に登録している。また、サイト１０ｄは、上記の通り本人ではないことが判明した場合は、ブラックリストデータベース２８に登録要求を行う。

図１に示す例においては、サイト１０ｄは、サイト１０ａ、１０ｂ、１０ｃと同様に、まずログイン履歴を照合サーバ２０に送信している。この場合の照合サーバ２０の動作は、図３のフローチャートで説明した通りである。特に、図１に示したサイト１０ｄの場合は、ＩＤとパスワード（ＩＤ／ＰＷ）によるログインは成功したので、ステップＳ３−３、Ｓ３−４、Ｓ３−５と処理が進む。

特に、図１に示したサイト１０ｄでは、ログインしてきたアクセス者が、既にブラックリストデータベース２８に登録されている。つまり、上述したように、ハッカー８は、サイト１０ｃが送信したブラックリスト登録要求（図１参照）によって、ブラックリストデータベース２８に登録されている。したがって、サイト１０ｄのログイン履歴に対して、照合サーバ２０は図３のステップＳ３−５において、同様のデータが存在することが判明する。その結果、ステップＳ３−６に移行し、ブラックリストに載っている悪意のハッカーであるとのメッセージが、制御部２４によって、（通信部２２を介して、）サイト１０ｄに送られる。
サイト１０ｄは、このメッセージを受信することによって、アクセス者であるハッカー８が悪意のハッカー８であることを知ることができ、ログイン拒否を実行することができる。

このように、本実施形態１において、サイト１０ｄは他のサイト１０（ａ〜ｃ）が登録したログインヒストリーデータベース２６や、ブラックリストデータベース２８を利用することができ、不正なログインを行おうとする者を効率的に検出することができる。すなわち、他のサイト１０（ａ〜ｃ）の記録した内容に基づき、アクセスしてきた者を正当なユーザか否かを判断することができる。

ここで、記録する内容としては、さまざまな種類の内容に設定することができる。ログイン履歴として、アクセスしてきた者のＩＰアドレス、時刻、入力したＩＤやパスワードの入力速度、位置情報、アクセスしてきたデバイスの種別、利用しているブラウザの種類やバーション、ＯＳの名称やバージョン等、種々のパラメータを登録内容に含めることができる。これらの内、一部の情報のみを登録内容としてもよいし、さらに多くの他の種類の情報を含めてもよい。

また、ログインヒストリーデータベース２６や、ブラックリストデータベース２８には、信頼度またはそれに準ずる指標となるデータを登録しておいてもよい。また例えば、上述した２要素認証３０の結果、悪意のハッカーであると判断してログイン拒否３２した場合、そのログイン履歴（ログインヒストリーデータベース２６内のログイン履歴）に、悪意のハッカーと判断したフラグを付加しておいてもよい。

なお、本実施形態においては、各サイト１０（ａ〜ｄ）が送信してきたデータに基づき、制御部２４が、ログインヒストリーデータベース２６中を検索し、また、ブラックリストデータベース２８を検索している。しかし、照合サーバ２０のユーザである各サイト１０（ａ〜ｄ）が直接、ログインヒストリーデータベース２４や、ブラックリストデータベース２８に対してアクセスできるように構成してもよい。そして、それらの内容から、サイト１０（ａ〜ｄ）自身が判断できるように構成してもよい。

１−３．まとめ
このように実施形態１によれば、ログイン履歴を蓄積していくログインヒストリーデータベース２６を備えた照合サーバ２０を利用すれば、ショッピングモール等のサイト１０（ａ〜ｄ）は、アクセスしてきた者のアクセス履歴を参照することができるので、正当なユーザか否かを効率的に検出することができる。

また、特に、照合サーバ２０は、ログインヒストリーデータベース２６の内容に基づき、
「本人らしくない」アクセスを検知することができる。したがって、各サイト１０（ａ〜ｄ）が、ＩＤとパスワードだけでは判断しにくい「疑いのある」アクセスを知ることができる。特に、照合サーバ２０は、他サイト１０のアクセス履歴に基づき、「疑いのある」「本人らしくない」者を判断してくれるので、利用するサイト１０（ａ〜ｄ）は「疑いのある」「本人らしくない」者を容易に知ることができ、上述したように、２要素認証等を実行することができる。

例えば、このような動作を自サイトのみで実行しようとすれば、ユーザのアクセス履歴をある程度、自サイトで蓄積する必要がある。さらに、初めてそのサイト１０（ａ〜ｄ）にアクセスするユーザに対してはアクセス履歴の蓄積がないので、判断が困難である。
これに対して、本実施形態１によれば、他サイト１０（ａ〜ｄ）が蓄積したアクセス履歴を利用した判断を照合サーバ２０から得られるので、初めてそのサイト１０（ａ〜ｄ）にアクセスするユーザに対しても正規のユーザか否かを判断できる可能性がある。

さらに、本実施形態１によれば、照合サーバ２０は、ブラックリストデータベース２８を構築（登録）しているので、当該ブラックリストデータベース２８中に該当する者が見いだされ場合は、すぐにログイン拒否をすることができ、サイトの安全性をより強力に担保することができる。

ブラックリストデータベース２８に該当する者が登録されているか否かは、各サイトが照合サーバ２０に問いあわせを行って各サイト１０が判断してもよい。また、各サイト１０が図１に示すようにログイン履歴を登録しようとしたときに、照合サーバ２０の制御部２４が、別途ブラックリストデータベース２８の登録内容を確認するように構成してもよい。この場合、ブラックリストデータベース２８に該当する内容が登録されていた場合は、照合サーバ２０の制御部２４がその旨のメッセージをサイト１０に送信することも好ましい。

実施形態２
上述した実施形態１及び図１においては、ログインヒストリーデータベース２６と、ブラックリストデータベース２８とを備える照合サーバ２０について説明した。このような構成によって、ログイン履歴とブラックリストとを組み合わせて不正のアクセスを効率的に判断することができる。
しかし、ログイン履歴をホワイトリストと組み合わせることも好適である。本実施形態２においては、このようにログイン履歴とホワイトリストと組み合わせる例について説明する。

本実施形態２は、実施形態１と同様に、複数のサイトが、自サイトにアクセスするユーザが正規のユーザであるか否かを、共通の照合サーバ４０を利用して判断する例を説明する。図２には、このような複数のサイト（例えばショッピングモール）が、共通の照合サーバ４０を利用する例が示されている。

図１において、ユーザ１８は、一般ユーザ又は正規の登録を行った正規ユーザである。ユーザ１８は、通常のログイン動作によって、サイト１０ａ、１０ｂ、１０ｃ、１０ｄ等にアクセスしようとしている。

ユーザ１８は、インターネット等のネットワークを介して提供するためのサイト１０ａ、１０ｂ、１０ｃ、１０ｄに対して通常のログインを実行する。

２−２．動作
図２の例では、ユーザ１８は、初めてアクセスするユーザの場合は、そのサイトに登録してＩＤとパスワードを設定して入手する。既に登録している正規ユーザである場合は、その正規のユーザのＩＤとパスワード（ＰＷ）を用いて、サイト１０ａ、１０ｂ、１０ｃ、１０ｄに対してアクセス（ログイン）を実行する。
照合サーバ４０は、各サイト１０ａ、１０ｂ、１０ｃ、１０ｄにおけるログインの情報（ログイン履歴）を各サイト１０（ａ〜ｄ）から受信し、内部のログインヒストリーに記憶していく。本実施形態２においても、実施形態１と同様に、この照合サーバ４０は、各サイト１０（ａ〜ｄ）からのログイン履歴を蓄積することによって、各サイト１０（ａ〜ｄ）に代わって、アクセスしてきた者が正規ユーザとして怪しい（本人らしくない）か否かを判断するので、各サイト１０（ａ〜ｄ）にとって便利である。ログインヒストリーに関する動作は、上述した実施形態１とほぼ同様である。

図２に示すように、照合サーバ４０は、通信部４２と、制御部４４と、ログインヒストリーデータベース４６と、ホワイトリストデータベース４８と、を備えている。
ログインヒストリーデータベース４６は、実施形態１（図１）のログインヒストリーデータベース２６と同様のデータベースである。通信部４２も、実施形態１（図１）の通信部２２と同様の通信インターフェースである。通信部４２も、請求の範囲の通信部の好適な一例に相当する。

制御部４４は、照合サーバ４０の動作を司る手段であり、具体的には、ログインヒストリーデータベース４６と、ホワイトリストデータベース４８とに対する書き込み・読み出しを制御し、また、これらデータベースに関する種々の動作を実行する。例えばＣＰＵとそのＣＰＵが実行するプログラムとから構成してよい。そのプログラムは、照合サーバ４０が実行する処理が記述されているプログラムである。また、そのプログラムは、請求の範囲のコンピュータプログラムの好適な一例に相当する。

ホワイトリストデータベース４８は、正規のユーザ１８であると判断された相手の情報を記憶するデータベースである。本実施形態２は、ログイン履歴を、このホワイトリストと連動させて効率的な判断を提供することができる照合サーバ４０に関する実施形態である。
ホワイトリストデータベース４８は、ログインヒストリーデータベース４６と同様に、例えばハードディスク等の記憶手段で構成することができる。また、半導体記憶装置や、光学式の記憶装置を用いて構成してもよい。また、ログインヒストリーデータベース４６は、請求の範囲のログインヒストリーデータベースの好適な一例に相当する。また、ホワイトリストデータベース４８も、請求の範囲のホワイトリストデータベースの好適な一例に相当する。

ログイン
サイト１０ａは、ユーザ１８が正規ユーザとして登録し、正規にＩＤとパスワードとを取得しているサイト１０ａであり、ユーザ１８は、通常の手続きでログインが成功する。すると、サイト１０ａは、そのログインが成功したというログイン成功履歴を、照合サーバ４０に送信する。照合サーバ４０は、送信されてきたログイン成功履歴（ログイン履歴（ログインヒストリー））を、その内部のログインヒストリーデータベース４６に記憶する。

サイト１０ｂも、サイト１０ａと同様に、ユーザ１８がパスワードを頻繁に更新しているサイト１０ｂであり、その結果、ユーザ１８は、そのサイト１０ｂにとって正しいＩＤとパスワードとを使用することにより、ログインを成功する。すると、サイト１０ｂは、サイト１０ａと同様に、そのログインが成功したというログイン成功履歴を、照合サーバ４０に送信する。照合サーバ４０は、送信されてきたログイン動作（ログイン履歴）を、その内部のログインヒストリーデータベース２６に記憶する。

サイト１０ｃは、サイト１０ａ、１０ｂと同様に、ユーザ１８が正しいＩＤとパスワードを用いて正常にログイン可能である。その結果、サイト１０ｃもログインの情報を照合サーバ４０に送信する。サイト１０ｃも、ユーザ１８によるログイン動作を照合サーバ２０に送信し、照合サーバ４０はログイン履歴をログインヒストリーデータベース４６に登録していく。
次に、ログイン履歴が送信されてきた照合サーバ４０の動作をフローチャートに基づき説明する。

照合サーバ４０によるログイン履歴の検査
照合サーバ４０は、送信されてくるログイン履歴がログイン失敗履歴であっても成功履歴であってもログインヒストリーデータベース４６に登録する。
ログイン履歴が送信されてきた場合の照合サーバ４０の動作が、図５、図６のフローチャートに記載されている。

図５のステップＳ５−１において、まず、所定のサイト１０（ａ〜ｃ）からログイン履歴が送信されてきた場合、通信部４２がこれを受信し、制御部４４に送る。
ステップＳ５−２において、制御部４４は、送られてきたログイン履歴をログインヒストリーデータベース４６に順次登録していく。

ステップＳ５−３において、制御部４４は、送られてきたログイン履歴を見て、そのログイン履歴が成功履歴であるか否か判断する。判断の結果、成功履歴であった場合は、ステップＳ５−４に移行する。一方、失敗履歴であった場合は、照合サーバ４０の、そのログイン履歴に対する処理は終了し、次のログイン履歴の送信を待つ状態となる。図２に示す場合は、正規のユーザ１８による通常のログイン動作を表しているので、その場合は、ステップＳ５−４に処理が移行する。

ステップＳ５−４において、制御部４４は、送られてきたログイン履歴を送ったサイト１０（ａ〜ｃ）のこれまでのログイン履歴をログインヒストリーデータベース４６から参照する。
ステップＳ５−５において、制御部４４は、参照したこれまでのログイン履歴のログインの様子と、今回のログイン（成功）履歴とを比較し、ログイン動作の振る舞いがこれまでと同様か否かを判断する。判断の結果、これまでのログイン動作の振る舞いと異なる場合は、本人（正規のユーザ）らしくない振る舞いと判断し、ステップＳ５−６に移行する。

一方、判断の結果、これまでのログイン動作の振る舞いと同様である場合は、ログイン履歴の検査の動作を終了し、ログイン履歴の記憶動作を終了する。そして、次のログイン履歴が送信されてくるのを待つ状態となる。
図２に示すサイト１０ｃの例の場合は、本人らしくないログインが行われている。例えばいつもとは異なる端末からログインした、又は、新しい位置（地理的位置）からログインした等、これまでとは異なるログインが行われている例である。このような場合は、上述したように、ステップＳ５−６に移行する。

ステップＳ５−６において、制御部４４は、今回記憶したログイン履歴と、ホワイトデータベース４８の登録内容と比較する。そして、図６のステップＳ６−１に移行する。
図６のステップＳ６−１において、上記ステップＳ５−６における比較の結果、同様のデータが登録されていた場合は、アクセスをしてきた者は、正当な権限を有するアクセス者であると判断し、ステップＳ６−２に移行する。一方、同様のデータが登録されていない場合は、図６のステップＳ６−３に移行する。

ステップＳ６−２において、制御部４４は、例えば「ホワイトリストに載っている正規のユーザである」等のメッセージを、通信部４２を介して当該サイト（ａ〜ｄ）に送信する。その後、当該ログイン履歴の処理を終了する。この結果、当該サイト１０（ａ〜ｄ）は、本人らしくない振る舞いでアクセスが行われているが、正規のユーザ１８であることが確認済みであることを認識することができる。

ステップＳ６−３において、制御部４４は、例えば「本人らしくない」等のメッセージを通信部４２を介して、ログイン履歴を送信してきたサイト１０（ａ〜ｄ）に送信する。そして、処理を終了する。この結果、当該サイト１０（ａ〜ｄ）は、ＩＤとパスワードは正しいが、本人らしくない振る舞いでアクセスが行われたことを認識することができる。

このように、本実施形態の照合サーバ４０は、単にログイン履歴を記憶していくだけでなく、
・送信されてきたログイン履歴を、これまでのログイン履歴と比較し、同様の振る舞いでない場合は、同様の内容がホワイトリストデータベース４８に登録されているか否か判断する。ホワイトリストデータベース４８に登録されていた場合は、その旨を当該サイト１０に送信する。
・さらに、ホワイトリストデータベース４８に登録されていない場合は、ログイン履歴の振る舞いが、これまでと異なるログイン動作の振る舞いであるので、その旨（例えば、「本人らしくない」等のメッセージ）を当該サイト１０（上の例では１０ｃ）に送信している。
このような動作によって、各サイト１０は、アクセスしてきた者が、正規のユーザであるか否か（悪意のアクセス者であるか否か）を効率的に判断することができ、便利である。

サイト１０ｃにおける２要素認証の実行
さて、図２に示す例では、サイト１０ｃが、ログインは成功したが、照合サーバ４０から「本人らしくない」とのメッセージを受信する（図６のステップＳ６−１）。サイト１０ｃは、これを受けて、例えば、２要素認証５０を実行することができる。２要素認証については、実施形態１で説明した通りである。

図２に示す例では、この２要素認証５０の結果、本人であることが判明したので、ログインを許可している（図２中、ログイン許可５２）。このログイン許可５２となった場合は、正当な正規ユーザ１８であると認定し、サイト１０ｃは、ホワイトリスト登録要求を照合サーバ４０に対して送信する。

照合サーバ４０によるホワイトリストデータベース４８への登録
照合サーバ４０は、送信されてくるホワイトリスト登録要求を受信すると、その内容をホワイトリストデータベース４８に登録する。
具体的には、まず通信部４２がホワイトリスト登録要求を受信する。
次に、通信部４２がホワイトリスト登録要求を制御部４４に送信する。
制御部４４は、ホワイトリスト登録要求を受信すると、その要求に従って、ユーザ１８に付いての情報を、ホワイトリストデータベース４８に登録する。このホワイトリストデータベース４８の登録内容は、ユーザ１８を識別することができればどのような登録内容でもよい。

ログインヒストリーデータベース４６とホワイトリストデータベース４８の活用（サイト１０ｄの場合の動作）
図２の例によれば、ユーザ１８は、サイト１０ｄにも、他のサイト１０ａ、１０ｂ、１０ｃと同様に、正規のＩＤとパスワードを用いて通常のログイン動作を実行する例が記載されている。
サイト１０ｄも照合サーバ４０を利用しており、ログイン履歴を照合サーバ４０中のログインヒストリーデータベース４６に登録している。また、サイト１０ｄは、上記の通り２要素認証によって本人であることが判明した場合は、ホワイトリストデータベース４８に登録要求を行う。

図２に示す例においては、サイト１０ｄは、サイト１０ａ、１０ｂ、１０ｃと同様に、まずログイン履歴を照合サーバ４０に送信している。この場合の照合サーバ４０の動作は、図５のフローチャートで説明した通りである。特に、図２に示したサイト１０ｄの場合は、ＩＤとパスワード（ＩＤ／ＰＷ）によるログインは成功したので、ステップＳ５−３、Ｓ５−４、Ｓ５−５と処理が進む。

ステップＳ５−５において、ログイン履歴との比較で同様の振る舞いであれば、照合サーバ４０における処理は終了するが、ログイン履歴との比較で異なる振る舞いであった場合は、ステップＳ５−６においてホワイトリストデータベース４８との比較処理が実行される。

図２に示したサイト１０ｄでは、ログインしてきたアクセス者が、既にホワイトリストデータベース４８に登録されている。つまり、上述したように、ユーザ１８は、サイト１０ｃが送信したホワイトリスト登録要求（図２参照）によって、ホワイトリストデータベース４８に登録されている。

したがって、サイト１０ｄのログイン履歴に対して、照合サーバ４０は図６のステップＳ６−１において、同様のデータが存在するとの判断がなされる。その結果、ステップＳ６−２において、制御部４８は、例えば「ホワイトリストに登録されています」等のメッセージをサイト１０ｄに、通信部４２を介して送信する。このようにして、照合サーバ４０における処理が終了する。

このように、本実施形態２において、サイト１０ｄは他のサイト１０（ａ〜ｃ）が登録したログインヒストリーデータベース４６や、ホワイトリストデータベース４８を利用することができ、正規のユーザ１８であることを効率的に検出することができる。すなわち、他のサイト１０の記録した内容に基づき、アクセスしてきた者を正当なユーザか否かを判断することができる。
ここで、記録した内容はさまざまな内容に設定することができる。ログイン履歴として、アクセスしてきた者のＩＰアドレス、時刻、入力したＩＤやパスワードの入力速度、位置情報、アクセスしてきたデバイスの種別、利用しているブラウザの種類やバーション、ＯＳの名称やバージョン等、種々のパラメータを登録内容に含めることができる。

また、ログインヒストリーデータベース４６や、ホワイトリストデータベース４８には、信頼度またはそれに準ずる指標となるデータを登録しておいてもよい。また例えば、上述した２要素認証５０の結果、正規のユーザ１８であると判断してログイン許可５２した場合、そのログイン履歴（ログインヒストリーデータベース４６内のログイン履歴）に、正規のユーザ１８と判断したフラグを付加しておいてもよい。

なお、本実施形態２においては、各サイト１０（ａ〜ｄ）が送信してきたデータに基づき、制御部４４が、ログインヒストリーデータベース４６中を検索し、また、ホワイトリストデータベース４８を検索している。しかし、照合サーバ４０のユーザである各サイト１０（ａ〜ｄ）が直接、ログインヒストリーデータベース２４や、ホワイトリストデータベース４８に対してアクセスできるように構成してもよい。そして、それらの内容から、サイト１０（ａ〜ｄ）自身が判断できるように構成してもよい。

２−３．まとめ
このように実施形態２によれば、ログイン履歴を蓄積していくログインヒストリーデータベース４６を備えた照合サーバ４０を利用しているので、ショッピングモール等のサイト１０（ａ〜ｄ）は、アクセスしてきた者のアクセス履歴を参照することができる。その結果、各サイト１０（ａ〜ｄ）は、アクセスしてきた者を正当なユーザか否かを効率的に検出することができる。

また、実施形態１と同様に、照合サーバ４０は、ログインヒストリーデータベース４６の内容に基づき、「本人らしくない」アクセスを検知することができる。したがって、各サイト１０（ａ〜ｄ）が、ＩＤとパスワードだけでは判断しにくい「疑いのある」アクセスを知ることができる。特に、照合サーバ４０は、他サイト１０のアクセス履歴に基づき、「疑いのある」「本人らしくない」者を判断することができるので、利用するサイト１０（ａ〜ｃ）は「疑いのある」「本人らしくない」者を容易に知ることができ、照合サーバの判断に基づき、適宜上述したように２要素認証等を実行することができる。

例えば、このような動作を自サイトのみで実行しようとすれば、ユーザのアクセス履歴をある程度、自サイトで蓄積する必要がある。さらに、初めてそのサイト１０（ａ〜ｄ）にアクセスするユーザに対してはアクセス履歴の蓄積がないので、判断が困難である。
これに対して、本実施形態２によれば、他サイト１０（ａ〜ｄ）が蓄積したアクセス履歴を利用した判断を照合サーバ４０から得られるので、初めてそのサイト１０（ａ〜ｄ）にアクセスするユーザに対しても正規のユーザか否かを判断できる可能性がある。

さらに、本実施形態２によれば、照合サーバ４０は、ホワイトリストデータベース４８を構築（登録）しているので、当該ホワイトリストデータベース４８中に該当する者が見いだされ場合は、サイト１０（ａ〜ｄ）は（そのアクセス者が自サイトにとって初めてのアクセス者であったとしても）すぐにログイン許可をすることができる。

ホワイトリストデータベース４８に該当する者が登録されているか否かは、各サイトが照合サーバ４０に問いあわせを行って各サイト４０が個別に判断してもよい。また、各サイト１０が図１に示すようにログイン履歴を登録しようとしたときに、照合サーバ４０の制御部４４が、別途ホワイトリストデータベース４８の登録内容を確認するように構成してもよい。この場合、ホワイトリストデータベース４８に該当する内容が登録されていた場合は、照合サーバ４０の制御部４４がその旨のメッセージをサイト１０に送信することも好ましい。

実施形態１、２ まとめ
（１）効果
このように、実施形態１、２においては、ログインヒストリーデータベース２６、４６を構築し、それを複数のサイト１０間で共有（照合サーバ２０、４０で共有）することができるので、これまでとは異なる振る舞いのアクセスを効率的に検知することが可能である。

また、特に、実施形態１においては、ブラックリストデータベース２８を構築しているので、悪意のハッカーであることを効率的に判断することができる。特に、その情報を、照合サーバ２０によって複数のサイトが共有することができるので、より効率的に不正アクセスを防止することができる。
なお、悪意のハッカー８は、人間が自ら操作してアクセスを実行している場合もあれば、コンピュータ等が機械的にその正当なユーザになりすましてアクセスを実行している場合も含む。

実施形態２において、ホワイトリストデータベース４８を構築しているので、一度至当なアクセス者であることが判明しているユーザーをその振る舞いにかかわらず判断することができる。特に、その情報を、照合サーバ４００によって複数のサイトが共有することができるので、より効率的に正当なユーザであることを効率的に判断することができる。

（２）追加認証（リスクベース認証：Risk Based Authentication）の採用
実施形態１、２においては、２要素認証を用いる例を説明したが、その他、種々の追加認証（リスクベース認証：Risk Based Authentication）を実行してもよい。

（３）ログインヒストリーデータベース２６、４６の内容
ログインヒストリーデータベース２６、４６は、様々なログイン情報を記録してよい。
例えば、図７に示す様々な種別のデータをログイン毎に登録してもよい。
図７には、ログインヒストリーデータベース２６、４６の登録例を示す説明図が示されている。この図においては、１回のログインで登録される情報の例が示されており、実際には、ログインの度にこれらの情報がログインヒストリーデータベース２６、４６に登録されてよい。
同図に示すように、ログインヒストリーデータベース２６、４６に記録される内容は、例えば、５種類に分けられてよい。

第１の種類の情報は、ユーザ情報であり、主としてＩＤとパスワードである。このユーザ情報は、動作の主体であるユーザを特定する情報である。
このＩＤやパスワードとしては例えばハッシュ化されたＩＤ、および、ハッシュ化されたパスワードが記録されてもよい。これは、データの量をコンパクトにして比較演算等を容易にするためであり、また、個人を完全に特定されてしまうことを防止し、個人情報の漏洩の可能性を減少させるためである。

第２の種類の情報は、端末情報であり、ユーザがサイト１０にアクセスした際に用いた端末の情報であり、用いられる端末の種類とＯＳの種類等が記録される。また、使用言語に関する情報も記録されてよい。

第３の種類の情報は、ユーザが使用しているブラウザ等の情報である。このブラウザの情報も、使用する端末毎に記録される。使用するブラウザが複数種類ある場合も、複数のブラウザの情報が記録される。ここでは、「ブラウザ」と呼んでいるが、およそそのサイト１０にアクセスするための手段・プログラム全般を含めてよい。

第４の種類の情報は、アクセスするユーザのＩＰアドレスである。このＩＰアドレスからユーザの位置を知ることができる。
第５の種類の情報は、ページ遷移である。この情報は、図７に示すように、例えばリファラーＵＲＬ等であり、どこからそのサイトに遷移してきたかを示す。

これらは、ログイン履歴の一例であり、より少ない情報をログイン履歴として登録するように構成してもよい。上の説明や図７では、種別が５種類の例を示したが、種別の数はより少なくてもよい（例えば１種でもよい）し、より多くてもよい。また、利用するサイトによって、登録されるログイン履歴の内容が異なっていてもよい。ログインヒストリーデータベース２６、４６中には、ログイン毎にこれらログイン履歴が登録され、蓄積されていく。

（４）ホワイトリストデータベース４８と、ブラックリストデータベース２８の内容
本実施形態１、２で構築するホワイトリストデータベース４８と、ブラックリストデータベース２８の内容は、種々のパラメータを含めてよい。
両者は記録する内容としては同様であってもよいし、異なる内容であってもよい。
図８には、正規のユーザであると判断されたユーザの情報を記録したホワイトリストデータベース４８の記録例と、正規のユーザになりすました悪意のあるハッカー情報を記録したブラックリストデータベース２８との記録例を示す説明図が示されている。
同図に示すように、ホワイトリストデータベース４８（およびブラックリストデータベース２８）に記録される内容は、図７で示したログインヒストリーデータベース２６、４６の登録内容とほぼ同様であり、例えば、５種類に分けられる。

第１の種類の情報〜第４の種類の情報は、上で述べたとおりである。
第５の種類の情報は、ページ遷移である。この情報も、図７に示すように、例えばリファラーＵＲＬ等である。特に、ホワイトリストデータベース４８やブラックリストデータベース２８では、その他に、Ｗｅｂサイト１０上でどのようなページを閲覧したかを示す情報も含めてよい。例えば、図８の例では、ホワイトリストデータベース４８の正規のユーザは、ログインした後、購入履歴ページで購入履歴を確認した後、ポイント確認ページを閲覧して利用可能なポイントを確認する〜等の閲覧履歴を示す場合がある。また、ブラックリストデータベースの正規のユーザになりすました悪意のあるハッカーは、ログイン後、すぐにポイント交換ページに行き、ポイント交換をしようとする閲覧履歴である場合もある。このように、Ｗｅｂサイト１０で閲覧するページが、正規のユーザとなりすました悪意のハッカーとでは大きく異なることが、経験的に知られている。

さらに、ページ遷移の情報においては、Ｗｅｂサイト１０に滞在した時間も記録されてよい。一般に正規のユーザと比較して、悪意のあるハッカーはＷｅｂサイト１０に滞在する時間が短いことが知られている。このような時間の情報としては、さらに、閲覧した各ページにおいて滞在した時間も記録しておいてよい。

なお、悪意のあるハッカーは、人間である場合もあるし、規のユーザになりすました機械（コンピュータ）である場合もある。このようなコンピュータが正規のユーザになりすましている場合は、Ｗｅｂサイト１０全体の滞在時間も、各ページに滞在する時間も非常に短い場合が多く、滞在時間に基づいて人間と区別することができる場合もある。また、文字入力のスピードが異常に速いことでも人間と区別することが可能な場合もある。

上記以外でも種々の情報を含めてもよい。例えば、文字入力のスピード等も含めてもよい。人間になりすました悪意のプログラムは、キー入力が異常に早いことが経験的に知られている。

ここで説明した記録内容は、一例であり、もっと多種多様な種類の情報を記録してもよい。また、ここで説明した記録内容は、標準的な例を示したものであり、より少ない種類の情報を用いてホワイトリストデータベースやブラックリストデータベースを構成してもよい。また、上の説明や図８では、種別が５種類の例を示したが、種別の数はより少なくてもよいし、ブラックリストとホワイトリストで種別の数が異なっていてもよい。用途によっては１種類でも有用である。

実施形態３．照合サーバ２０、４０の細部、関連技術
（１）照合サーバ
上で説明した照合サーバ２０、４０は、複数のサイト１０から利用され、ログイン履歴を蓄積していくサーバである。個別のサイト１０が自身でログイン履歴を蓄積するのに比べて、あるユーザ１８のログイン履歴をより多く蓄積することができるので、ログインの振る舞いから、当該アクセスがこれまでと同様の振る舞いか否かをより効率的に判断して、その結果を各サイト１０に通知することができる。

その結果、各サイト１０は、ユーザ１８に対して、２要素認証３０等、正当性のさらなる認証を実行することができ、不正アクセスを効率的に検出することができる。
さらに、各サイト１０は、正当性のさらなる認証を行った結果に基づき、ブラックリストデータベース２８や、ホワイトリストデータベース４８に登録要求できる。したがって、ブラックリストデータベース２８やホワイトデータベース４８に登録されれば、より確実にそのアクセス者が正当なユーザか否かを（照合サーバ２０、４０（の制御部２４，４４）が）判断することができ、その結果を各サイト１０に提供することが可能である。

（２）ログインヒストリーデータベース
本実施形態１、２に係るログインヒストリーデータベース２６、４６は、ログイン成功の場合も、ログイン失敗の場合もログイン履歴を蓄積していく。蓄積の方法は、種々の方法が採用可能であるが、当該ログ有限であるので、古いデータは適時削除していくことも好ましい。

ログインヒストリーデータベース２６、４６は、上述した図７の情報を、ログイン毎に蓄積していけばよいが、同じユーザ１８のログイン成功履歴は、最新の所定個数だけ蓄積しておき、古い順に消去していくことも好ましい。
このような動作は、制御部２４、４４が実行してよい。

また、ログインヒストリーデータベース２６、４６は、ログイン失敗履歴についても、上述した図７の情報を、ログイン毎に蓄積していくが、これらはどの履歴が同じハッカー８であるか否かは判断がしにくい。そのため、ログイン失敗履歴については、まとめてその最大蓄積データ量を所定量に予め決めておき、その所定量の記憶容量を超えた場合に、古いログイン失敗履歴から削除していくことも好ましい。このような動作も、制御部２４、４４が実行してよい。

又は、サイト毎に蓄積データ量をきめておいてもよい。各サイト１０に対して、ログイン失敗履歴を蓄積する最大蓄積データ量を決めておき、その量を超えた場合に古いログイン失敗履歴から削除していくことも好ましい。
又は、蓄積時間を決めておき、その時間を超えた古いログイン履歴は削除していくように構成してもよい。
このような動作も、制御部２４、４４が実行してよい。

（３）ブラックリストデータベース２８と、ホワイトリストデータベース４８と、の共存
上述した実施形態１、２では、ブラックリストデータベース２８を備えた照合サーバ２０と、ホワイトリストデータベース４８を備えた照合サーバ４０と、を説明したが、ブラックリストデータベース２８とホワイトリストデータベース４８とを共に備えた照合サーバを構成してもよい。

そのような構成の場合は、
・ブラックリストデータベース２８の登録内容との比較
・ログイン履歴との比較
・ホワイトリストデータベース４８の登録内容との比較
を順に実行するように構成してよい。
具体的に言えば、図３のステップＳ３−５において「Ｎｏ」側に続けて、図５のステップＳ５−４に移行するように処理を行ってよい。

第４．意義・効果
近年では、悪意のある第三者が入手した一組のＩＤとパスワードを用いて、複数のサイト１０への不正アクセスが連続して行われる例が数多くみられる。このような連続した不正アクセスに対して、本実施形態における照合サーバ２０、４０は特に有用な対抗手段となり得る。また、本実施形態１、２では、単にユーザ１８のＩＤやパスワードだけではなく、ユーザ１８やハッカー８の動作のログイン履歴を記録してログインヒストリーデータベース２６、４６を構築して、それを複数のサイト間で共有する仕組みを提供している。したがって、単に１個のサイトが自前でユーザの履歴を管理することに比べて、より効率的にユーザ１８の認定、ハッカー８の検出を行うことが可能である。

第５．他の変形例
（１）上述した実施形態では、照合サーバ２０、４０は、各サイト１０からアクセスできる場所であれば、インターネット上のどこに位置してもよい。例えば、所定のサイト１０（例えば１０ａ）と同一のサーバ内に位置していてもよい。この場合は、照合サーバ＋サイトとの組み合わせた、照合サーバ付きサイトを構成することができる。

（２）ホワイトリストデータベース４８中の同一のユーザの情報（レコード）の記録数を固定（例えばｎ個（ｎは自然数））して設定してもよいが、より少ない数でもよいし、また、多くてもかまわない。また、状況に応じて登録数を動的に調整するように構成してもよい。

（３）上述した実施形態では、ブラックリストデータベース２８中のレコード数は制限を設けていないが、比較照合の演算速度等を考慮して、最大登録数に制限を設けてもよい。その場合は、例えば、古いレコードから削除していく等の処理を行ってもよい。

（４）上述した実施形態では、ホワイトリストデータベース４８中のデータは実際のアクセスに基づき記録していったが、人為的に予め典型的な正規のデータを記録しておいてもよい。また、ブラックリストデータベース２８中に、予め判明している不正なアクセスの例を人為的に記憶させておいてもよい。

（５）上述した実施形態では、ホワイトリストデータベース４８のデータは、新しいアクセスの度に更新され、古いデータは削除されていってよいが、人為的に固定したレコードを指定しておいてもよい。アクセスの頻度が低いユーザ１８を考慮したものである。

（６）また、ホワイトリストデータベース４８、ブラックリストデータベース２８のレコードは人為的な手段、または他の手段で適宜チューニングを施してもよく、また、人の手によって、あまり重要でないレコードを削除してもよい。種々の人為的な作業を施してもよい。

（７）上記実施形態では、ハッシュ化されたＩＤと、ハッシュ化されたパスワードとが、ホワイトリストデータベース４８、ブラックリストデータベース２８に記録されるが、ハッシュ化されないデータを用いてもよく、また所定の暗号化が施されたＩＤとパスワードを利用してもよい。

また、本発明の実施形態について詳細に説明したが、前述した実施形態は、本発明を実施するにあたっての具体例を示したに過ぎない。本発明の技術的範囲は、前記実施形態に限定されるものではない。本発明は、その趣旨を逸脱しない範囲において種々の変更が可能であり、それらも本発明の技術的範囲に含まれる。

８ ハッカー
１０ １０ａ、１０ｂ、１０ｃ、１０ｄ サイト
１８ ユーザ
２０、４０ 照合サーバ
２２、４２ 通信部
２４、４４ 制御部
２６、４６ ログインヒストリーデータベース
２８ ブラックリストデータベース
３０、５０ ２要素認証（の実行）
３２ ログイン拒否
４８ ホワイトリストデータベース
５２ ログイン許可

Claims (9)

1. 外部との通信を行う通信部であって、外部からログイン履歴を受信し、制御部に送信する通信部と、
   前記通信部から送信されてきたログイン履歴をログインヒストリーデータベースに登録する前記制御部と、
   前記ログイン履歴を保持する前記ログインヒストリーデータベースと、
   悪意のハッカーの情報を保持するブラックリストデータベースと、
   を備える照合サーバであって、
   前記制御部は、
   前記送信されてきたログイン履歴が成功履歴である場合に、前記ログイン履歴を、前記ログインヒストリーデータベースが保持するログイン履歴と比較し、前記ログインがこれまでのログインの振る舞いと同様の振る舞いではないときに、本人らしくない旨のメッセージを、前記通信部を介して送信し、
   前記送信されてきたログイン履歴が成功履歴である場合に、前記ログイン履歴を、前記ブラックリストデータベースの登録内容と比較し、同様のデータが存在する場合は、悪意のハッカーである旨のメッセージを前記通信部を介して送信する
   ことを特徴とする照合サーバ。
2. 請求項１記載の照合サーバにおいて、さらに、
   正規のユーザの情報を保持するホワイトリストデータベース、
   を備え、
   前記制御部は、前記送信されてきたログイン履歴が成功履歴である場合に、前記ログイン履歴を、前記ホワイトリストデータベースの登録内容と比較し、同様のデータが存在する場合は、正規のユーザである旨のメッセージを前記通信部を介して送信することを特徴とする照合サーバ。
3. 外部との通信を行う通信部であって、外部からログイン履歴を受信し、制御部に送信する通信部と、
   前記通信部から送信されてきたログイン履歴をログインヒストリーデータベースに登録する前記制御部と、
   前記ログイン履歴を保持する前記ログインヒストリーデータベースと、
   悪意のハッカーの情報を保持するブラックリストデータベースと、
   正規のユーザの情報を保持するホワイトリストデータベースと、
   を備える照合サーバであって、
   前記制御部は、
   前記送信されてきたログイン履歴が成功履歴である場合に、前記ログイン履歴を、前記ブラックリストデータベースの登録内容と比較し、同様のデータが存在する場合は、悪意のハッカーである旨のメッセージを前記通信部を介して送信し、
   前記ブラックリストデータベースの登録内容と比較の結果、同様のデータが存在しない場合は、前記ログイン履歴を、前記ログインヒストリーデータベースが保持するログイン履歴と比較し、
   前記ログインヒストリーデータベースが保持するログイン履歴と比較の結果、前記ログイン履歴がこれまでのログインの振る舞いと同様の振る舞いではないときは、前記ログイン履歴を、前記ホワイトリストデータベースの登録内容と比較し、
   前記ホワイトリストデータベースの登録内容との比較の結果、同様のデータが存在する場合は、正規のユーザである旨のメッセージを前記通信部を介して送信し、同様のデータが存在しない場合は、本人らしくない旨のメッセージを、前記通信部を介して送信することを特徴とする照合サーバ。
4. 請求項１又は３記載の照合サーバにおいて、
   前記通信部は、外部からブラックリスト登録要求を受信し、前記制御部に送信し、
   前記制御部は、前記通信部から送信されてきたブラックリスト登録要求に含まれる悪意のハッカーの情報を、前記ブラックリストデータベースに登録することを特徴とする照合サーバ。
5. 請求項２又は３記載の照合サーバにおいて、
   前記通信部は、外部からホワイトリスト登録要求を受信し、前記制御部に送信し、
   前記制御部は、前記通信部から送信されてきたホワイトリスト登録要求に含まれる正規のユーザの情報を、前記ホワイトリストデータベースに登録することを特徴とする照合サーバ。
6. 外部との通信を行う通信部であって、外部からログイン履歴を受信し、制御部に送信する通信部と、
   前記通信部から送信されてきたログイン履歴をログインヒストリーデータベースに登録する前記制御部と、
   前記ログイン履歴を保持する前記ログインヒストリーデータベースと、
   悪意のハッカーの情報を保持するブラックリストデータベースと、
   を備える照合サーバを用いて、前記ログイン履歴が、本人らしいか否か照合する照合方法であって、
   前記制御部が、前記送信されてきたログイン履歴が成功履歴である場合に、前記ログイン履歴を、前記ログインヒストリーデータベースが保持するログイン履歴と比較し、前記ログインがこれまでのログインの振る舞いと同様の振る舞いではないときに、本人らしくない旨のメッセージを、前記通信部を介して送信するステップと、
   前記制御部が、前記送信されてきたログイン履歴が成功履歴である場合に、前記ログイン履歴を、前記ブラックリストデータベースの登録内容と比較し、同様のデータが存在する場合は、悪意のハッカーである旨のメッセージを前記通信部を介して送信するステップと、
   を含むことを特徴とする照合方法。
7. 外部との通信を行う通信部であって、外部からログイン履歴を受信し、制御部に送信する通信部と、
   前記通信部から送信されてきたログイン履歴をログインヒストリーデータベースに登録する前記制御部と、
   前記ログイン履歴を保持する前記ログインヒストリーデータベースと、
   悪意のハッカーの情報を保持するブラックリストデータベースと、
   正規のユーザの情報を保持するホワイトリストデータベースと、
   を備える照合サーバを用いて、前記ログイン履歴が、本人らしいか否か照合する照合方法であって、
   前記制御部が、前記送信されてきたログイン履歴が成功履歴である場合に、前記ログイン履歴を、前記ブラックリストデータベースの登録内容と比較し、同様のデータが存在する場合は、悪意のハッカーである旨のメッセージを前記通信部を介して送信するステップと、
   前記制御部が、前記ブラックリストデータベースの登録内容と比較の結果、同様のデータが存在しない場合は、前記ログイン履歴を、前記ログインヒストリーデータベースが保持するログイン履歴と比較するステップと、
   前記制御部が、前記ログインヒストリーデータベースが保持するログイン履歴と比較の結果、前記ログイン履歴がこれまでのログインの振る舞いと同様の振る舞いではないときは、前記ログイン履歴を、前記ホワイトリストデータベースの登録内容と比較するステップと、
   前記制御部が、前記ホワイトリストデータベースの登録内容との比較の結果、同様のデータが存在する場合は、正規のユーザである旨のメッセージを前記通信部を介して送信し、同様のデータが存在しない場合は、本人らしくない旨のメッセージを、前記通信部を介して送信するステップと、
   を含むことを特徴とする照合方法。
8. 外部との通信を行う通信部であって、外部からログイン履歴を受信し、制御部に送信する通信部と、
   前記通信部から送信されてきたログイン履歴をログインヒストリーデータベースに登録する前記制御部と、
   前記ログイン履歴を保持する前記ログインヒストリーデータベースと、
   悪意のハッカーの情報を保持するブラックリストデータベースと、
   を備える照合サーバとして、コンピュータを動作させるコンピュータプログラムであって、
   前記制御部が、前記送信されてきたログイン履歴が成功履歴である場合に、前記ログイン履歴を、前記ログインヒストリーデータベースが保持するログイン履歴と比較し、前記ログインがこれまでのログインの振る舞いと同様の振る舞いではないときに、本人らしくない旨のメッセージを、前記通信部を介して送信する手順と、
   前記制御部が、前記送信されてきたログイン履歴が成功履歴である場合に、前記ログイン履歴を、前記ブラックリストデータベースの登録内容と比較し、同様のデータが存在する場合は、悪意のハッカーである旨のメッセージを前記通信部を介して送信する手順と、
   を前記コンピュータに実行させることを特徴とするコンピュータプログラム。
9. 外部との通信を行う通信部であって、外部からログイン履歴を受信し、制御部に送信する通信部と、
   前記通信部から送信されてきたログイン履歴をログインヒストリーデータベースに登録する前記制御部と、
   前記ログイン履歴を保持する前記ログインヒストリーデータベースと、
   悪意のハッカーの情報を保持するブラックリストデータベースと、
   正規のユーザの情報を保持するホワイトリストデータベースと、
   を備える照合サーバとして、コンピュータを動作させるコンピュータプログラムであって、
   前記制御部が、前記送信されてきたログイン履歴が成功履歴である場合に、前記ログイン履歴を、前記ブラックリストデータベースの登録内容と比較し、同様のデータが存在する場合は、悪意のハッカーである旨のメッセージを前記通信部を介して送信する手順と、
   前記制御部が、前記ブラックリストデータベースの登録内容と比較の結果、同様のデータが存在しない場合は、前記ログイン履歴を、前記ログインヒストリーデータベースが保持するログイン履歴と比較する手順と、
   前記制御部が、前記ログインヒストリーデータベースが保持するログイン履歴と比較の結果、前記ログイン履歴がこれまでのログインの振る舞いと同様の振る舞いではないときは、前記ログイン履歴を、前記ホワイトリストデータベースの登録内容と比較する手順と、
   前記制御部が、前記ホワイトリストデータベースの登録内容との比較の結果、同様のデータが存在する場合は、正規のユーザである旨のメッセージを前記通信部を介して送信し、同様のデータが存在しない場合は、本人らしくない旨のメッセージを、前記通信部を介して送信する手順と、
   を前記コンピュータに実行させることを特徴とするコンピュータプログラム。

Images