JP4894241B2 - コンピュータシステム、認証制御方法、プログラム及びサーバ・クライアントシステム - Google Patents

Description

本発明は、コンピュータシステムにおけるユーザ認証に関し、特にアカウントロック制御に関する。

ユーザ認証を行うコンピュータシステムにおいては、必ず悪意のユーザによる攻撃が想定される。そのため、この種のシステムにおいては、アカウントロック機能が設けられていることが一般的である。アカウントロック機能は、ログイン試行が短期間の間に何度か続けて失敗すると、攻撃と判断してログインが試みられたアカウントをロックし、そのアカウントでのログインを認めないよう制御する機能である。攻撃に曝されたアカウントをロックすることで、そのアカウントのパスワードが破られる危険性を低減できる。

このように、アカウントロック機能はシステムへの不正侵入を防ぐ意味で重要な役割を果たすが、欠点もある。例えば、悪意あるユーザが他人のアカウントに対して適当なパスワードを用いてログイン試行を繰り返すことで、そのアカウントをロックさせることが起こり得る。また、悪意のあるユーザによらなくとも、例えば一般のユーザが自分のユーザＩＤを間違って入力しログイン試行を繰り返すと、その間違ったユーザＩＤがたまたま他人のユーザＩＤに一致していた場合、後者がアカウントロック状態となってしまう。

いったんアカウントがロックされると、システム管理者などシステムの管理情報を操作する権限を持った人に要請してアカウントが利用可能な状態に変更してもらうまでは、ユーザは自分のアカウントでログインができなくなるため、正当なユーザが不自由を強いられる。

この問題に対する従来技術として、特許文献１に示される装置では、ユーザがパスワードを間違えて入力した時、装置が、入力されたパスワードと正しいパスワードとの相違を調べ、キーボードの単純な打ち間違いと判断されるケースに該当する場合には、再試行を認める。これにより、正当なユーザが打鍵ミスによりアカウントロック状態となる事態を減らしている。

また特許文献２に示される認証方法では、パスワードの入力間違いが数度続くごとに、認証のために要求するパスワードの入力回数を増やしていく。すなわち、例えば最初は正しいパスワードを１回入力すればよいところを、何度か入力間違いが行われると、正しいパスワードを例えば２回続けて入力しないと認証成功としないように制御している。

また特許文献３には、パスワードの入力誤りがあるとある遅延時間が経過するまでパスワード入力を受け付けず、誤りの回数が増えるに連れてその遅延時間を長くしていく技術が示される（同文献第５段落）。また、同文献には、例えば破られやすい短いパスワードほど誤り時の遅延時間を大きくするなど、パスワードを構成する文字列の長さに応じて遅延時間の長さを決定する方式も示されている。

これらの従来技術は、いずれも悪意のユーザによる攻撃を行いにくくしたり、攻撃が成功する確率を下げたりすることはできるが、最終的に攻撃とみなされた場合には結局アカウントをロックせざるを得ない。アカウントをロックしない限り、攻撃が続く可能性があるからである。

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

本発明は、何らかの理由でアカウントがロックされた場合でも、正当なユーザならシステムへのログインができる機会を増やせる方式を提供する。

本発明は、クライアントを操作するユーザから入力されたユーザＩＤと認証情報を、当該クライアントから受け取り、受け取ったユーザＩＤと認証情報に基づき所定の認証手段を用いてユーザ認証を行い、該ユーザ認証が成功した場合にユーザのログインを許可し、該ユーザ認証において所定の不正アクセス条件が満足された場合には当該ユーザのユーザＩＤをアカウントロック状態とすると共に、ユーザＩＤのアカウントロック状態を解除するためには特定のシステム管理者からの操作を必要とするコンピュータシステムに対し、前記認証手段によるユーザ認証が成功した場合に、成功記録情報を生成してユーザ宛に送信し、前記成功記録情報と前記ユーザのユーザＩＤと前記クライアントのＩＤとの組合せを成功記録記憶手段に記憶し、クライアントからユーザＩＤ及び認証情報に対応づけて成功記録情報を受け取った場合、当該ユーザＩＤがアカウントロック状態である場合でも、当該ユーザＩＤと当該クライアントのＩＤと当該成功記録情報との組合せが前記成功記録記憶手段に登録されたものであれば、アカウントロック状態を維持したままログインを許可し、クライアントからユーザＩＤ及び認証情報を受け取ったが成功記録情報は受け取らなかった場合、当該ユーザＩＤがアカウントロック状態であれば、ログインを許可しない、処理を実行させるためのプログラムを提供する。

この構成において、認証手段は、当該コンピュータシステム自身が内蔵していてもよいし、当該コンピュータシステムからアクセス可能な他の装置であってもよい。

好適な態様では、前記成功記録記憶手段には、成功記録情報を発行した発行時刻が登録される。

更に好適な態様では、コンピュータシステムが、ユーザから受け取った成功記録情報の発行時刻を前記成功記録記憶手段から求め、その発行時刻が現在時刻より所定時間以上前の場合には、そのユーザＩＤとその成功記録情報とが前記成功記録記憶手段に登録されたものであっても、ログインを許可しないようにする。

別の好適な態様では、コンピュータシステムが、ユーザから受け取った成功記録情報の発行時刻を前記成功記録記憶手段から求め、求めた発行時刻を示す情報を前記ユーザに提供する、ようにする。

更に別の好適な態様では、コンピュータシステムが、アカウントロック状態のユーザに対してログインを許可した場合、アカウントロック状態である旨を示す通知を前記ユーザに送信する、ようにする。

以下、図面を参照して、本発明の実施の形態を説明する。

図１に示すように、この実施の形態のシステムは、サーバ１０と、このサーバ１０にアクセスしてサービスの提供を受けるクライアント２０とを含む。サーバ１０がクライアント２０に提供するサービスは特に問わない。サーバ１０とクライアント２０とは、インターネット等のネットワークを介して接続されている。サーバ１０は、クライアント２０を操作するユーザからログイン要求を受けた場合、ログインの認められた正当なユーザであるか否かの認証を行う。図１には、サーバ１０の持つ構成要素群のうち、このユーザ認証に係る構成要素群を主として示している。

ログイン処理部１２は、ユーザからのログイン要求を処理する機能モジュールである。ログイン処理部１２は、例えば、クライアント２０からユーザのログイン要求を受け取り、認証処理部１４やアカウントロックＤＢ（データベース）１８などを用いて、そのログイン要求を認めるかどうかを判定する。

認証ＤＢ１６には、サーバ１０へのログインを許可する各ユーザのユーザＩＤと認証情報（例えばパスワード）のペアが登録されている。認証処理部１４は、ユーザの入力したユーザＩＤ及び認証情報のペアをログイン処理部１２から受け取り、そのペアが認証ＤＢ１６に登録されている正しいペアであるか否かを判定し、正しければ認証成功とし、そうでなければ認証失敗とする。ログイン処理部１２は、この認証の結果に応じ、ユーザからのログイン要求を認めるか否かを判定する。

ログイン処理部１２は、あらかじめ定めた期間にユーザ認証の失敗が所定回数以上連続して繰り返された場合、当該ユーザのアカウントをロックする。なお、この判定の基準とする期間の長さや、認証失敗の回数は他の条件に応じて可変としてもよい。

アカウントロックＤＢ１８は、アカウントロック状態にあるユーザを登録するデータベースである。例えば、アカウントロック状態にあるユーザのユーザＩＤが登録される。また、所定時間経過後にアカウントロック状態を自動解除する場合は、アカウントロックされた時刻の情報も登録される。ログイン処理部１２は、あるユーザについてアカウントロックの条件が満たされた場合、そのユーザをアカウントロックＤＢ１８に登録するとともに、アクセスしてきたユーザのユーザＩＤがアカウントロックＤＢ１８に登録されているか否かを調べることで、当該ユーザがアカウントロック状態であるかどうかを判定する。

成功記録リポジトリ３０は、ユーザがログインに成功した場合に成功記録ＩＤを発行し、図２に示すように、この成功記録ＩＤをそのユーザのユーザＩＤと対応づけて記録する。図示例では、成功記録リポジトリ３０は、サーバ１０内に内蔵されている。しかし、これは必須のことではない。成功記録リポジトリ３０をサーバ１０と別のコンピュータ装置上に構築し、サーバ１０とインターネット等のネットワーク経由又は専用ケーブル経由で接続してもよい。

成功記録ＩＤは、ログインが成功したという事実（イベント）を個別に識別するための一意な識別情報である。同じユーザが同じクライアント２０の同じブラウザ２４からログインした場合でも、ログインの時刻が異なれば、異なる成功記録ＩＤが付与される。成功記録ＩＤとしては、例えば、乱数発生器が発生する乱数（又は擬似乱数）を用いることができる。十分な桁数の乱数を用いれば、実用的な範囲でＩＤに重複が生じる可能性は低い。また、成功記録ＩＤとして乱数を用いることで、攻撃者による成功記録ＩＤの推測を困難にすることができる。また、サーバ１０がネットワーク上に複数存在する場合を考慮すると、成功記録ＩＤとしては、サーバ１０の識別情報と、乱数などといったそのサーバ１０内での識別情報との組み合わせを用いてもよい。なお、複数のサーバ１０に対する成功記録ＩＤの発行及び管理を、１つの成功記録リポジトリ３０が担う構成をとる場合は、成功記録リポジトリ３０は、全てのサーバ１０の間で一意な成功記録ＩＤを発行し、発行した成功記録ＩＤに対し、そのＩＤに対応するログインが行われたサーバの識別情報を対応づけて記録しておく。

成功記録ＩＤは、（ログイン（すなわちユーザ認証）が成功したことのある）正当なユーザであることを示すいわば「信用情報」として機能する。すなわち、この実施の形態では、サーバ１０から成功記録ＩＤを受け取ったユーザのクライアント２０のブラウザ２４（ここでは、サーバ１０がウェブサーバである場合を想定している）は、その成功記録ＩＤを成功記録保存部２２に保存する。そして、後で再びユーザがサーバ１０にログインする際には、ブラウザ２４がその成功記録ＩＤをサーバ１０に送る。サーバ１０は、ユーザからのログイン要求が正当な成功記録ＩＤを伴っていれば、少なくとも前にログインを認めた正当なユーザが自分のクライアント２０からログイン要求をしてきたことが分かる。そのように正当な成功記録ＩＤを伴うログイン要求が到来した場合、ログイン処理部１２は、仮にそのユーザがアカウントロック状態であったとしても、過去にログインが成功したという事実をいわば信頼して、アカウントロック状態とは取り扱わないようにする。

すなわち、従来は、アカウントロック状態の場合、ユーザを門前払い（すなわちユーザＩＤ及び認証情報の入力すら認めない）とするか、或いは正当なユーザＩＤ及び認証情報をユーザが提示してもログインは認めなかった。これに対し、このログイン処理部１２は、正当な成功記録ＩＤがユーザから提示された場合にはユーザを門前払いとせず、正しいユーザＩＤと認証情報が入力されればログインを認める。ここで、「正当な成功記録ＩＤ」とは、例えば、成功記録リポジトリ３０に登録されているユーザＩＤと成功記録ＩＤのペアに合致するもののことをいう。すなわち、あるユーザＩＤのユーザがある成功記録ＩＤをログイン処理部１２に提示した場合、そのユーザＩＤと成功記録ＩＤのペアが成功記録リポジトリ３０に登録されていれば、その成功記録ＩＤは「正当な成功記録ＩＤ」である。

なお、ログインが成功したことを一種の「信用」として利用するとは言っても、その成功があまりに遠い過去のことであれば、その間に成功記録ＩＤが漏洩するなどのリスクがあり、信用度は下がる。そこで、発行した成功記録ＩＤに対して有効期限又は有効期間を設定し、成功記録ＩＤが提示されても、その有効期限又は有効期間が切れていれば、成功記録ＩＤの提示がないものとして取り扱うことも好適である。この場合、成功記録リポジトリ３０は、図３に示すように、成功記録ＩＤを記録する際に、その成功記録ＩＤの発行時刻（又は記録時刻）も併せて記録するようにしてもよい。この発行時刻を基準に、有効期間が過ぎたかどうかを判断できる。また、成功記録リポジトリ３０が、成功記録ＩＤを発行した際、その成功記録ＩＤの有効期限を定め（例えばその発行時刻に所定の有効期間を足すなど）、その有効期間を成功記録ＩＤと対応づけて記録するようにしてもよい。また、成功記録リポジトリ３０が、自分の管理する各成功記録ＩＤの発行時刻や有効期限を例えば定期的に調べ、有効期間が過ぎた成功記録ＩＤを発見した場合には、そのような成功記録ＩＤを削除するようにしてもよい。この場合、クライアント２０が有効期限を過ぎた成功記録ＩＤを送ってきたとしても、それは成功記録リポジトリ３０にないので、そのクライアントの要求はそのＩＤの提示がないものとして取り扱われる。

また、ユーザに対して発行した成功記録ＩＤが、コピーなどにより不正利用されるリスクを低減するために、図４に示すように成功記録ＩＤを送ったクライアント２０の識別情報（クライアントＩＤ）を併せて成功記録リポジトリ３０に記録するようにしてもよい。クライアントＩＤとしては、クライアント２０のＩＰアドレスやＭＡＣアドレスなど、クライアント２０を一意に特定できるものを用いればよい。サーバ１０がクライアント２０から成功記録ＩＤを伴うログイン要求を受けた場合、そのクライアント２０のクライアントＩＤがその成功記録ＩＤに対応して成功記録リポジトリ３０に登録されたクライアントＩＤと一致しているか否かが判定され、一致していなければ、その成功記録ＩＤは無効とみなされる。これにより、ユーザが、自分が以前にサーバ１０にログインする際に利用したクライアント２０以外からは、成功記録ＩＤを利用できないようにすることができる。

以上、サーバ１０を中心に説明した。これに対し、クライアント２０は、ユーザが操作するパーソナルコンピュータなどのコンピュータ装置である。

ここでは、サーバ１０がウェブサーバである場合を想定しているので、ユーザはクライアント２０にインストールされたブラウザ（ウェブブラウザ）２４を介してサーバ１０にアクセスする。このブラウザ２４は、サーバ１０から送られてきた成功記録ＩＤをクライアント２０の記憶装置に保存するための仕組みを備える。これには、例えばＷｅｂのクッキー(HTTP cookie)技術を利用することができる。この場合、サーバ１０は、ログインページでのログイン認証が成功した場合成功記録ＩＤをクッキーとしてブラウザ２４に提供し、ブラウザ２４はそのクッキーをテキストファイルとして保存する。そして、次に同じサーバ１０のログインページにアクセスする際には、そのクッキーをそのサーバ１０に送る。このようなクッキーの処理機構はウェブブラウザに標準的に搭載されているので、ブラウザ２４としては一般的なウェブブラウザをそのまま利用できる。

成功記録保存部２２は、サーバ１０から受け取った成功記録ＩＤを保存する記憶装置である。成功記録ＩＤがクッキーとして提供される場合、ブラウザ２４がそのクッキーがどのサーバ１０（のどのページ）からのものであるかを管理するので、成功記録保存部２２は単なるファイルシステムでよい。ブラウザ２４が持っていないプロトコルを用いて成功記録ＩＤをサーバ・ブラウザ間で受け渡す場合は、その受け渡しのための管理を行うプログラムを例えばブラウザ２４にプラグインするなどの方法をとればよい。この受け渡しの管理のためのプログラムは、成功記録ＩＤをサーバ１０から受け取った場合、その成功記録ＩＤをそのサーバの識別情報と対応づけて成功記録保存部２２に保存し、ブラウザがサーバ１０のログインページにアクセス（ログイン要求）する場合には、そのサーバ１０に対応する成功記録ＩＤが成功記録保存部２２にあるかどうかを調べ、あればその成功記録ＩＤをそのログイン要求に付加する。

なお、サーバ１０がウェブサーバでない場合は、クライアント２０には、ブラウザ２４に代えて、サーバ１０との間での処理を行うのに必要なプロトコルを有する対サーバ処理部を設ければよい。そして、その対サーバ処理部が成功記録ＩＤの保存と、サーバ１０への送信との管理を行えばよい。

次に、図５〜図９を参照して、このシステムにおけるログイン処理の流れを説明する。まず、図５を参照して、成功記録ＩＤを持たないクライアントからアカウントロック状態でないユーザがサーバにログインを試みた場合の処理の流れを説明する。

この処理では、
［１］まず、ユーザの指示に従いクライアント２０（以下では、特記しない限りブラウザ２４のことを指す）がサーバ１０にログイン要求を行う。ログイン要求は、例えばサーバ１０が提供するログインページを要求するHTTP要求をブラウザ２４が発行することによりなされる。この例では、クライアント２０はサーバ１０からの成功記録ＩＤを持っていないので、ログイン要求には成功記録ＩＤが付随しない。

［１Ｒ］このようなログイン要求を受けたサーバ１０は、ログイン要求に成功記録ＩＤが伴っていないことを認識すると共に、ユーザＩＤとパスワードを入力するためのログインフォーム（ログインページ）をクライアント２０に返す。以下では、「サーバ１０」と示した場合、特記しなければ、ログイン処理部１２のことを指すものとする。

［２］そのログインフォームに対し、クライアント２０を操作するユーザがユーザＩＤとパスワードを入力すると、それらユーザＩＤとパスワードとがサーバ１０に送信される。

［２．１］サーバ１０は、クライアント２０から受け取ったユーザＩＤ及びパスワードを認証処理部１４に渡し、ユーザ認証を行わせる。ここで、仮にそのユーザ認証が失敗した場合は、サーバ１０はログイン失敗の旨と再度ユーザＩＤとパスワードを入力するためのフォームとを示したページをクライアント２０に提供し、再入力を受け付ける。アカウントロックの条件が満足される（例えば所定時間以内に所定回数以上続けて認証失敗となるなど）までは、正しいユーザＩＤとパスワードが入力されるまでその再入力のための処理が繰り返される。なお、図５の例では、ユーザ認証が成功し、ログインが認められたものとする。

［２．２］ユーザ認証が成功した場合、サーバ１０は、成功記録リポジトリ３０に対して成功記録の登録を要求する。この要求には、認証が成功したことを示す情報と、認証が成功したユーザのユーザＩＤとが含まれる。

［２．２Ｒ］成功記録リポジトリ３０は、サーバ１０の要求に応じ、一意な成功記録ＩＤを生成し、この成功記録ＩＤをサーバ１０に対して発行する。また、成功記録リポジトリ３０は、発行したい成功記録ＩＤを、サーバ１０からの要求に示されるユーザＩＤと対応づけて（また構成によっては更に発行時刻又は有効期限と共に、別の例ではクライアントＩＤと共に）記録する。

［２Ｒ］サーバ１０は、ログインが成功した旨を示す情報（例えばログイン成功時に提供するウェブページ）と共に、成功記録リポジトリ３０から受け取った成功記録ＩＤをクライアント２０に、例えばクッキー情報の形で送信する。

［３］クライアント２０は、サーバ１０から受け取った成功記録ＩＤを、例えばクッキーとして、自分の記憶装置に保存する。

以上に説明した図５の処理は、成功記録ＩＤに関連する処理以外は、従来のログイン認証処理と同様の流れでよい。

次に、図６を参照して、成功記録ＩＤを持つクライアントからアカウントロック状態でないユーザがサーバにログインを試みた場合の処理の流れを説明する。

［１］このケースでは、クライアント２０は、ユーザからサーバ１０へのログインを指示された場合、自分の成功記録保存部２２に保存されているそのサーバ１０についての成功記録ＩＤを読み出し（クッキーの場合はブラウザ２４の機能により自動的に読み出される）、ログイン要求と対応づけてこの成功記録ＩＤをサーバ１０に送る。

［１．１］サーバ１０は、その成功記録ＩＤが有効か否かを成功記録リポジトリ３０に問い合わせる。

［１．１Ｒ］成功記録リポジトリ３０は、サーバ１０からの要求に応じその成功記録ＩＤが有効か否かを判定する。１つの例では、その成功記録ＩＤがリポジトリ３０内に記録されていれば有効と、そうでなければ無効と判定する。また、成功記録ＩＤに有効期間又は期限が設定されている場合は、その有効期間又は期限が切れているか否かを確認し、切れていればその成功記録ＩＤは無効と判定する。図６は、成功記録ＩＤが有効と判定された場合であり、成功記録リポジトリ３０は有効である旨の回答をサーバ１０に返している。

なお、クライアント２０からの成功記録ＩＤが無効である場合は、成功記録リポジトリ３０は無効の旨の回答をサーバ１０に返す。この場合、サーバ１０は、ユーザからのログイン要求を、成功記録ＩＤがない場合と同様に取り扱う。

［１Ｒ］成功記録ＩＤが有効である旨の回答を受けたサーバ１０は、クライアント２０に対してログインフォームを送信する。このログインフォームは、図５のステップ１Ｒ．で送信するログインフォームと同じものでよい。以下の他のケースでも、ログインフォームは同じものでよい。

［２］そのログインフォームに対し、クライアント２０を操作するユーザがユーザＩＤとパスワードを入力すると、それらユーザＩＤとパスワードとがサーバ１０に送信される。

［２．１］サーバ１０は、クライアント２０から受け取ったユーザＩＤ及びパスワードを認証処理部１４に渡し、ユーザ認証を行わせる。図６の例では、ユーザ認証が成功し、ログインが認められたものとする。

［２．２］ユーザ認証が成功した場合、サーバ１０は、ログイン要求元のユーザのユーザＩＤを成功記録リポジトリ３０に送り、チェックを依頼する。

［２．２．１］チェック依頼を受けた成功記録リポジトリ３０は、受け取ったユーザＩＤと、ステップ１．１で受け取った成功記録ＩＤのペア（ステップ２．２でサーバ１０からユーザＩＤと成功記録ＩＤのペアを送った場合はそのペア）が、成功記録リポジトリ３０に記録されているペアと一致するか否かを判定する。これは成功記録ＩＤの正当性の検査である。また、成功記録リポジトリ３０は、自分の記録しているデータの中から、その成功記録ＩＤに対応するエントリを削除する。これは、一度利用された成功記録ＩＤを削除するためである。

［２．２Ｒ］成功記録リポジトリ３０は、ユーザＩＤと成功記録ＩＤのペアが自分の記録したものと一致したかどうかの判定結果をサーバ１０に返す。

［２．３］図６の例では、ステップ２．１のユーザ認証が成功しているので、サーバ１０は、成功記録リポジトリ３０に対してユーザＩＤを送り、成功記録の登録を要求する。

［２．３Ｒ］成功記録リポジトリ３０は、サーバ１０の要求に応じ一意な成功記録ＩＤを生成し、この新たな成功記録ＩＤをサーバ１０に対して発行すると共に、これをユーザＩＤと対応づけて記録する。

［２Ｒ］サーバ１０は、ログインが成功した旨を示す情報（例えばログイン成功時に提供するウェブページ）と共に、成功記録リポジトリ３０から受け取った成功記録ＩＤをクライアント２０に送信する。

［３］クライアント２０は、サーバ１０から受け取った成功記録ＩＤを保存する。

なお、成功記録リポジトリ３０に成功記録ＩＤの発行時刻を記録する構成の場合、ステップ２．２．１で削除した古い成功記録ＩＤの発行時刻を、新たに発行された成功記録ＩＤと共に、成功記録リポジトリ３０からサーバ１０に渡すこともできる。この場合、サーバ１０は、その古い成功記録ＩＤの発行時刻を当該ユーザのサーバ１０に対する最終ログイン時刻として示す画面（例えばウェブページ）を生成し、クライアント２０にこれを提供して表示させてもよい。この時刻は、そのユーザＩＤのユーザがそのクライアント２０から最後にアクセスした時刻を示す。このシステムでは、成功記録ＩＤは、クライアント２０からサーバ１０へ送られると必ず成功記録リポジトリ３０から削除されるので、成功記録ＩＤとクライアント２０とは必ず一対一に対応している。このため、成功記録ＩＤの発行時刻は、そのクライアント２０からの最終ログイン時刻を示すことになる。サーバ１０は、これとは別に、一般にユーザＩＤごとにその最終ログイン時刻を管理しているので、これも併せてユーザに提供すれば、ユーザは、ユーザＩＤに対応する最終ログイン時刻と、当該クライアント２０からの最終ログイン時刻との比較ができる。ユーザが最後にログインしたのがそのクライアント２０からだと認識していて、ユーザＩＤに対応する最終ログイン時刻がそのクライアント２０からの最終ログイン時刻より後であることが分かれば、誰かが別のコンピュータから自分になりすましてログインしたことが分かる。なお、このようなクライアント２０ごとの最終ログイン時刻の提供は、後述する図９の処理の場合にも適用できる。

図６の例では、ログイン要求を行ったユーザはアカウントロック状態ではなく、またステップ２．１の認証も成功したので、ステップ２．２Ｒにおける判定結果の如何によらず、新たな成功記録ＩＤは発行される。

また、図６の処理では、成功記録ＩＤの有効性のみをまずステップ１．１で判定し、ステップ２．２で成功記録ＩＤとユーザＩＤのペアの正当性を判定したが、ステップ２．２において有効性及びペアの正当性を併せて判定してもよい。

次に、図７を参照して、ユーザがクライアント２０からサーバ１０へ不正ログインを試みた場合の処理の流れを説明する。ここでは、ユーザは正しいパスワードを知らないため、様々なパスワードを入力して侵入を試みたとする。

［１］まず、クライアント２０からサーバ１０にログイン要求が行われる。ここで、サーバ１０についての成功記録ＩＤがクライアント２０に保持されている場合は、その成功記録ＩＤもサーバ１０に渡され、サーバ１０はその成功記録ＩＤの有効性をリポジトリ３０に問い合わせ、リポジトリ３０はその有効性の判定結果をサーバ１０に返す（図示省略）。

［１Ｒ］サーバ１０はログインフォームをクライアント２０に返す。

［２］クライアント２０は、ユーザが入力したユーザＩＤ及びパスワードをサーバ１０に送信する。

［２．１］サーバ１０は、受け取ったユーザＩＤ及びパスワードを認証処理部１４に渡してユーザ認証を行わせる。図７の例では、このユーザ認証が所定の期間の間に同じユーザＩＤについて所定回数以上連続して失敗するなど、アカウントロックの条件が満たされるとする。この場合、サーバ１０は、そのユーザＩＤをアカウントロックＤＢ１８に登録する。

［２．２］ステップ１のログイン要求に成功記録ＩＤが伴っていた場合は、サーバ１０は成功記録リポジトリ３０にその成功記録ＩＤの削除を指示する。これは、一度使用された成功記録ＩＤが再び使用されることをなくすためである。なお、ログイン要求に成功記録ＩＤが伴っていなかった場合は、このステップは不要である。

［２Ｒ］サーバ１０は、クライアント２０に対してログイン失敗の旨を回答（例えばログイン失敗のメッセージを表示したウェブページ）する。この回答を受けたクライアント２０は、その回答を画面表示するなどの処理を行う。

次に、図８を参照して、成功記録ＩＤを持たないクライアントからアカウントロック状態のユーザがサーバにログインを試みた場合の処理の流れを説明する。

［１］まず、クライアント２０からサーバ１０にログイン要求が行われる。このケースでは成功記録ＩＤは伴わない。

［１Ｒ］サーバ１０はログインフォームをクライアント２０に返す。

［２］クライアント２０は、ユーザが入力したユーザＩＤ及びパスワードをサーバ１０に送信する。

［２．１］サーバ１０は、受け取ったユーザＩＤ及びパスワードに対する認証処理を行うが、このときアカウントロックＤＢ１８にそのユーザＩＤが登録されているかどうかを判定する（この判定は、図５〜７の処理でも行われているが、煩雑さを避けるため説明を省略した）。図８のケースでは、そのユーザＩＤはアカウントロックＤＢ１８に登録されている（すなわち、アカウントロック状態）なので、ユーザ認証を行うまでもなく、ログイン失敗となる（ただし、ユーザＩＤとパスワードを用いたユーザ認証を行ってももちろんよい）。

［２Ｒ］サーバ１０は、クライアント２０に対してログイン失敗の旨を回答する。

以上に説明した図８の処理は、従来のログイン認証処理において、アカウントロック状態のユーザからのログイン要求を処理する処理と同様でよい。

次に、図９を参照して、成功記録ＩＤを持つクライアントからアカウントロック状態のユーザがサーバにログインを試み、成功する場合の処理の流れを説明する。

［１］クライアント２０は、ユーザからサーバ１０へのログインを指示された場合、そのサーバ１０についての成功記録ＩＤを読み出し、ログイン要求と対応づけてこの成功記録ＩＤをサーバ１０に送る。

［１．１］サーバ１０は、その成功記録ＩＤが有効か否かを成功記録リポジトリ３０に問い合わせる。

［１．１Ｒ］成功記録リポジトリ３０は、サーバ１０からの要求に応じその成功記録ＩＤが有効か否かを判定する。この例では、成功記録ＩＤが有効と判定され、成功記録リポジトリ３０は有効である旨の回答をサーバ１０に返す。なお、成功記録ＩＤが無効と判定された場合は、成功記録リポジトリ３０は無効の旨の回答をサーバ１０に返し、サーバ１０は、ユーザからのログイン要求を、成功記録ＩＤがない場合と同様に取り扱う（すなわち図８と同様の取り扱い）。

［１Ｒ］成功記録ＩＤが有効である旨の回答を受けたサーバ１０は、クライアント２０に対してログインフォームを送信する。

［２］そのログインフォームに対し、クライアント２０を操作するユーザがユーザＩＤとパスワードを入力すると、それらユーザＩＤとパスワードとがサーバ１０に送信される。

［２．１］サーバ１０は、ユーザＩＤ及びパスワードを受け取った場合、アカウントロックＤＢ１８にそのユーザＩＤが登録されているかどうかを判定する。このケースでは、ユーザＩＤはアカウントロックＤＢ１８に登録されている。従来なら、これで直ちにログイン失敗となるが、この例では、クライアント２０から提示された成功記録ＩＤが有効だったので、ユーザＩＤとパスワードを用いたユーザ認証を行う。図９の例では、ユーザ認証は成功したものとする。

［２．２］ユーザ認証が成功した場合、サーバ１０は、ログイン要求元のユーザのユーザＩＤを成功記録リポジトリ３０に送り、チェックを依頼する。なお、このユーザ認証が失敗した場合、ユーザは、ログイン失敗の旨をクライアント２０に通知する。

［２．２．１］チェック依頼を受けた成功記録リポジトリ３０は、図６のステップ２．２．１と同様、ユーザＩＤと成功記録ＩＤのペアが成功記録リポジトリ３０に記録されているペアと一致するか否かを判定すると共に、自分の記録しているデータの中から、その成功記録ＩＤに対応するエントリを削除する。

［２．２Ｒ］成功記録リポジトリ３０は、ユーザＩＤと成功記録ＩＤのペアが自分の記録しているものと一致したかどうかの判定結果をサーバ１０に返す。

ここで、ユーザＩＤと成功記録ＩＤのペアが記録されたものと一致しなければ、サーバ１０は、ユーザ認証の結果によらず、ログイン失敗と判定する。これは、成功記録ＩＤが正当なものである場合にのみ、アカウントロック時のログイン認証を認めるという立場にしたがったものである。

ユーザＩＤと成功記録ＩＤのペアが記録されたものと一致していれば、ステップ２．１のユーザ認証は成功しているので、ログイン成功となる。

［２．３］このケースではログイン成功なので、サーバ１０は、成功記録リポジトリ３０に対してユーザＩＤを送り、成功記録の登録を要求する。

［２．３Ｒ］成功記録リポジトリ３０は、サーバ１０の要求に応じ一意な成功記録ＩＤを生成し、この新たな成功記録ＩＤをサーバ１０に対して発行すると共に、これをユーザＩＤと対応づけて記録する。

［２Ｒ］サーバ１０は、ログインが成功した旨を示す情報（例えばログイン成功時に提供するウェブページ）と共に、成功記録リポジトリ３０から受け取った成功記録ＩＤをクライアント２０に送信する。

［３］クライアント２０は、サーバ１０から受け取った成功記録ＩＤを保存する。

ここで、サーバ１０は、ログイン成功後にクライアント２０に提供する画面（例えばウェブページ）で、アカウントロック状態であることをユーザに通知することも好適である。ユーザはこの通知を見て、システム管理者に事情の調査やアカウントロック状態の解除を依頼するなどの処置をとることができる。

図９の処理では、成功記録ＩＤの有効性のみをまずステップ１．１で判定し、ステップ２．２で成功記録ＩＤとユーザＩＤのペアの正当性を判定したが、ステップ２．２において有効性及びペアの正当性を併せて判定してもよい。

以上、図１のシステムにおけるログイン認証処理について説明した。このシステムによれば、あるユーザが何らかの事情であるサーバ１０においてアカウントロック状態となっていたとしても、そのユーザが以前にそのサーバ１０に対しログインに成功したクライアント２０からなら、即座に門前払いとなることなく、ユーザ認証に合格すればログインできる。従来ならば、システム管理者がアカウントロックを解除するまでは、正当なユーザはログインが不可能であったが、図１のシステムによればそのような不便は軽減される。

以上のシステムでは、サーバ１０自身が認証処理部１４及び認証ＤＢ１６を備えていたが、サーバ１０に認証処理部１４及び認証ＤＢ１６を設けず、ネットワーク上にある認証サーバに対しサーバ１０が認証を依頼するようにしてもよい。

また、以上の例では、成功記録ＩＤをクッキーとしてクライアント２０に保存したが、この代わりに、ActiveX（マイクロソフト社の登録商標）コンポーネント等の技術を用いることで、その成功記録ＩＤをクライアント２０のハードウエア固有の情報（例えばＭＡＣアドレスやハードディスクドライブのシリアル番号など）を用いて暗号化した上で、クライアント２０に保存することも好適である。このようにすることで、その成功記録ＩＤをコピーして別のコンピュータで不正利用されることを防止できる。

以上説明したサーバ１０やクライアント２０の各機能は、汎用コンピュータに対し、それら各機能を記述したプログラムを実行させることにより実現される。それらプログラムは、ＣＤ−ＲＯＭ等の可搬型の記録媒体から、又はネットワークからのダウンロードにより、そのコンピュータに付属する固定記憶装置にインストールされ、実行可能となる。

実施の形態のシステム構成を示す図である。 成功記録リポジトリが記録する成功記録データの例を示す図である。 成功記録リポジトリが記録する成功記録データの別の例を示す図である。 成功記録リポジトリが記録する成功記録データの更に別の例を示す図である。 成功記録ＩＤを持たないクライアントからアカウントロック状態でないユーザがサーバにログインを試み、成功する場合の処理の流れを示す図である。 成功記録ＩＤを持つクライアントからアカウントロック状態でないユーザがサーバにログインを試み、成功する場合の処理の流れを示す図である。 不正ログイン時の処理の流れを示す図である。 成功記録ＩＤを持たないクライアントからアカウントロック状態のユーザがサーバにログインを試みた場合の処理の流れを示す図である。 成功記録ＩＤを持つクライアントからアカウントロック状態のユーザがサーバにログインを試み、成功する場合の処理の流れを示す図である。

符号の説明

１０ サーバ、１２ ログイン処理部、１４ 認証処理部、１６ 認証ＤＢ、１８ アカウントロックＤＢ、２０ クライアント、２２ 成功記録保存部、２４ ブラウザ、３０ 成功記録リポジトリ。

Claims (7)

1. クライアントを操作するユーザから入力されたユーザＩＤと認証情報を、当該クライアントから受け取り、受け取ったユーザＩＤと認証情報に基づき所定の認証手段を用いてユーザ認証を行い、該ユーザ認証が成功した場合にユーザのログインを許可し、該ユーザ認証において所定の不正アクセス条件が満足された場合には当該ユーザのユーザＩＤをアカウントロック状態とすると共に、ユーザＩＤのアカウントロック状態を解除するためには特定のシステム管理者からの操作を必要とするコンピュータシステムに対し、
   前記認証手段によるユーザ認証が成功した場合に、成功記録情報を生成してユーザ宛に送信し、
   前記成功記録情報と前記ユーザのユーザＩＤと前記クライアントのＩＤとの組合せを成功記録記憶手段に記憶し、
   クライアントからユーザＩＤ及び認証情報に対応づけて成功記録情報を受け取った場合、当該ユーザＩＤがアカウントロック状態である場合でも、当該ユーザＩＤと当該クライアントのＩＤと当該成功記録情報との組合せが前記成功記録記憶手段に登録されたものであれば、アカウントロック状態を維持したままログインを許可し、
   クライアントからユーザＩＤ及び認証情報を受け取ったが成功記録情報は受け取らなかった場合、当該ユーザＩＤがアカウントロック状態であれば、ログインを許可しない、
   処理を実行させるためのプログラム。
2. 請求項１記載のプログラムであって、前記成功記録記憶手段には、成功記録情報を発行した発行時刻が登録されることを特徴とする、プログラム。
3. 請求項２記載のプログラムであって、前記コンピュータシステムに対し、
   ユーザから受け取った成功記録情報の発行時刻を前記成功記録記憶手段から求め、
   その発行時刻が現在時刻より所定時間以上前の場合には、そのユーザＩＤとその成功記録情報とが前記成功記録記憶手段に登録されたものであっても、ログインを許可しない、
   処理を実行させることを特徴とするプログラム。
4. 請求項２記載のプログラムであって、前記コンピュータシステムに対し、
   ユーザから受け取った成功記録情報の発行時刻を前記成功記録記憶手段から求め、
   求めた発行時刻を示す情報を前記ユーザに提供する、
   処理を実行させることを特徴とするプログラム。
5. 請求項１記載のプログラムであって、前記コンピュータシステムに対し、
   アカウントロック状態のユーザに対してログインを許可した場合、アカウントロック状態である旨を示す通知を前記ユーザに送信する、
   処理を更に実行させることを特徴とするプログラム。
6. クライアントを操作するユーザから入力されたユーザＩＤと認証情報を、当該クライアントから受け取り、受け取ったユーザＩＤと認証情報に基づき所定の認証手段を用いてユーザ認証を行い、該ユーザ認証が成功した場合にユーザのログインを許可し、該ユーザ認証において所定の不正アクセス条件が満足された場合には当該ユーザのユーザＩＤをアカウントロック状態とすると共に、ユーザＩＤのアカウントロック状態を解除するためには特定のシステム管理者からの操作を必要とするコンピュータシステムであって、
   前記認証手段によるユーザ認証が成功した場合に、成功記録情報を生成してユーザ宛に送信する成功記録発行手段と、
   前記成功記録発行手段が発行した成功記録情報と前記ユーザのユーザＩＤと前記クライアントのＩＤとの組合せを記憶する成功記録記憶手段と、
   クライアントからユーザＩＤ及び認証情報に対応づけて成功記録情報を受け取った場合、当該ユーザＩＤがアカウントロック状態である場合でも、当該ユーザＩＤと当該クライアントのＩＤと当該成功記録情報との組合せが前記成功記録記憶手段に登録されたものであれば、アカウントロック状態を維持したままログインを許可し、クライアントからユーザＩＤ及び認証情報を受け取ったが成功記録情報は受け取らなかった場合、当該ユーザＩＤがアカウントロック状態であれば、ログインを許可しない、ログイン制御手段と、
   を備えるコンピュータシステム。
7. クライアントを操作するユーザから入力されたユーザＩＤと認証情報を、当該クライアントから受け取り、受け取ったユーザＩＤと認証情報に基づき所定の認証手段を用いてユーザ認証を行い、該ユーザ認証が成功した場合にユーザのログインを許可し、該ユーザ認証において所定の不正アクセス条件が満足された場合には当該ユーザのユーザＩＤをアカウントロック状態とすると共に、ユーザＩＤのアカウントロック状態を解除するためには特定のシステム管理者からの操作を必要とするサーバと、このサーバに対してアクセスするクライアントからなるサーバ・クライアントシステムであって、
   サーバは、
   前記認証手段によるユーザ認証が成功した場合に、成功記録情報を生成してクライアント宛に送信する成功記録発行手段と、
   前記成功記録発行手段が発行した成功記録情報と前記ユーザのユーザＩＤと前記クライアントのＩＤとの組合せを記憶する成功記録記憶手段と、
   クライアントから、ユーザのユーザＩＤ及び認証情報に対応づけて成功記録情報を受け取った場合、当該ユーザＩＤがアカウントロック状態である場合でも、当該ユーザＩＤと当該クライアントのＩＤと当該成功記録情報との組合せが前記成功記録記憶手段に登録されたものであれば、アカウントロック状態を維持したままログインを許可し、クライアントからユーザＩＤ及び認証情報を受け取ったが成功記録情報は受け取らなかった場合、当該ユーザＩＤがアカウントロック状態であれば、ログインを許可しない、ログイン制御手段と、
   を備え、
   クライアントは、
   前記サーバから受信した成功記録情報を保存する保存手段と、
   前記サーバにログイン要求を行う際、そのサーバに対応する成功記録情報が前記保存手段に保存されていれば、当該成功記録情報を前記サーバに送信する手段と、
   を備える、
   ことを特徴とするサーバ・クライアントシステム。

Images