(57)【要約】【課題】ネットワークを介する攻撃者の不正アクセスを防ぎ、セキュリティを高めることができるアクセス可否管理システムを提供する。【解決手段】アクセス可否管理システム１は、特定の条件が満たされたときにユーザのデータベース４に対するアクセスを行わせるアクセス実行部２２と、ユーザ及びアクセス実行部２２によってアクセス可能に設けられて、アクセス実行部２２との間をＷｅｂＳｏｃｋｅｔ３４によって通信可能に接続するＷｅｂＳｏｃｋｅｔ実行管理部３３とを備え、アクセス実行部２２は、ＷｅｂＳｏｃｋｅｔ実行管理部３３との間にＷｅｂＳｏｃｋｅｔ３４が接続されている間はユーザのクライアント端末８とアクセス実行部２２との間のセッションを継続させる。【選択図】図１
2015158881.tif 000002
【特許請求の範囲】
【請求項１】
特定のアクセス対象に対するユーザごとのアクセスの可否を管理するアクセス可否管理システムであって、
特定の条件が満たされたときに前記ユーザの前記アクセス対象に対するアクセスを行わせるアクセス実行手段と、
前記ユーザ及び前記アクセス実行手段によってアクセス可能に設けられて、前記アクセス実行手段との間を、ＷｅｂＳｏｃｋｅｔ等、ネットワーク上のノード相互間でのデータ送受信に用いられるソケットによって通信可能に接続するセッション管理手段とを備え、
前記アクセス実行手段は、前記セッション管理手段との間に前記ソケットが接続されている間は前記ユーザと前記アクセス実行手段との間のセッションを継続させることを特徴とするアクセス可否管理システム。
【請求項２】
前記セッション管理手段は、前記ユーザのアクセス権限を認証するための認証情報を記録する第一の認証情報記録手段
を備え、
前記アクセス対象にアクセスを行う前記ユーザは、ｈｔｔｐ等、ネットワーク上のノード相互間でのデータ送受信にて用いられるリクエストを用いて、前記認証情報を前記第一の認証情報記録手段に記録させ、
前記ユーザは、自らが所持する前記認証情報を前記アクセス実行手段に送信し、
該アクセス実行手段は、前記セッション管理手段と前記アクセス実行手段との間に接続された前記ソケットを介して、前記ユーザから送信された前記認証情報と前記第一の認証情報記録手段に記録された前記認証情報と照合し、該照合の結果、双方の前記認証情報が適合した場合には前記ユーザを前記アクセス対象にアクセスさせることを特徴とする請求項１に記載のアクセス可否管理システム。
【請求項３】
前記ユーザがアクセス可能に設けられた第二の認証情報記録手段を備え、
該第二の認証情報記録手段には、前記第一の認証情報記録手段に記録されたものと同じ前記認証情報を記録し、
前記ユーザは、前記アクセス対象にアクセスする際、前記第二の認証情報記録手段に記録された前記認証情報を前記アクセス実行手段に送信することを特徴とする請求項２に記載のアクセス可否管理システム。
【請求項４】
前記ユーザの入力した情報に基づいて前記認証情報を生成する認証情報生成手段を備え、
該認証情報生成手段は、個々の前記ユーザを特定するためのユーザ特定情報を用いて、ランダムに生成されるランダムキーとして前記認証情報を生成することを特徴とする請求項２又は３に記載のアクセス可否管理システム。
【請求項５】
前記ユーザ特定情報として、個々の前記ユーザの真正性を識別するための文字、図形、記号等の識別情報を前記ユーザに入力させる、入力画面を表示させることを特徴とする請求項４に記載のアクセス可否管理システム。
【請求項６】
前記ユーザに、前記アクセス対象へのアクセス状態を視認可能に表示させるアクセス状態表示手段を備え、
前記アクセス実行手段は、前記アクセス状態表示手段において前記アクセス状態が視認できる場合にのみ、前記ユーザを前記アクセス対象にアクセスさせることを特徴とする請求項１乃至５の何れか一つに記載のアクセス可否管理システム。
【請求項７】
前記アクセス対象はデータベースであることを特徴とする請求項１乃至６の何れか一つに記載のアクセス可否管理システム。
【請求項８】
コンピュータを請求項１乃至７の何れか一つに記載のアクセス可否管理システムとして機能させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークに接続された各種機器、および、機器内の構成要素に対する他者のアクセスの許可や否定を行う機能を有するシステムに関する。
【背景技術】
【０００２】
複数のクライアントコンピュータがインターネットを通じてアプリケーションサーバに接続している場面において、クライアントがサーバに認識されて通信を連続することをセッションという。インターネット通信で一般的に利用されている通信プロトコルはＨＴＴＰ（Hypertext Transfer Protocol）である。ＨＴＴＰはステートレスの通信であり、以前のステートを保存できない。そこで、ＨＴＴＰでセッションを継続する場合は一般にセッションキーを利用する。
【０００３】
セッションキーはクライアント側とサーバ側に保存される値である。アプリケーションサーバでクライアントを区別するためには値を作成して、クライアントに送る。クライアントはブラウザ内にその値を保存して、毎回サーバにリクエストを送信する際はhttp-header内にセッションキーの値を含めて送信する。この方式は一般的にクッキーと呼ばれている。
【０００４】
多くのアプリケーションサーバがこのクッキーに基づいてセッションを認識する。しかし、第三者がこのクッキーを手に入れると、ブラウザにクッキーを書き込むことでその第三者が他のユーザに成りすます、セッションハイジャック攻撃による不正アクセスが可能になるという問題がある。
【０００５】
従来、このようなセッションの問題点を補うための種々の技術が知られている。例えば、リクエストが来るたびにクッキーを置き換える技術が知られている（例えば、特許文献１参照）。また、Ｗｅｂサーバ上のアプリケーションがセッションごとにレスポンスタイムを測定し、セッションに対するレスポンスタイムが早いか遅いかでセッションハイジャックかどうかを判定する技術が知られている（例えば、特許文献２参照）。また、一のアプリケーションサーバにトラフィックを通過させ、トラフィックを構成するパケットを所定のアルゴリズムを用いて分析することで、不正リクエストを判定する技術が知られている（例えば、特許文献３参照）。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】中国特許第１０３０６７３８５号明細書
【特許文献２】欧州特許第２４６１５３８号明細書
【特許文献３】国際公開第ＷＯ／２０１０／０９１１８６号公報明細書
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかし、上記特許文献１に記載の発明は、セッション継続中の正当なユーザのクッキーを補足すれば有効なリクエストを送信することでセッションを乗っ取ることが出来る問題がある。また、上記特許文献２に記載の発明は、遅延の少ないネットワーク内では遅延時間の正確な測定が難しく、セッションハイジャックの有無の正しい判定が困難という問題がある。また、上記特許文献３に記載の発明は、正当なユーザのクッキーを補足して不正なリクエストが行われた場合、分析の結果に反映されないという問題がある。従って、上記各特許文献に記載の発明は、セッションハイジャック等の不正アクセスを確実に防止できない。
【０００８】
本発明はこのような問題に鑑みてなされたものであり、ネットワークを介して行われる攻撃者の不正アクセスを防ぎ、セキュリティを高めることができる、セッションハイジャック防止のためのアクセス可否管理システムを提供することを課題としている。
【課題を解決するための手段】
【０００９】
かかる課題を達成するために、請求項１に記載の発明は、特定のアクセス対象に対するユーザごとのアクセスの可否を管理するアクセス可否管理システムであって、特定の条件が満たされたときに前記ユーザの前記アクセス対象に対するアクセスを行わせるアクセス実行手段と、前記ユーザ及び前記アクセス実行手段によってアクセス可能に設けられて、前記アクセス実行手段との間を、ＷｅｂＳｏｃｋｅｔ等、ネットワーク上のノード相互間でのデータ送受信に用いられるソケットによって通信可能に接続するセッション管理手段とを備え、前記アクセス実行手段は、前記セッション管理手段との間に前記ソケットが接続されている間は前記ユーザと前記アクセス実行手段との間のセッションを継続させることを特徴とする。
【００１０】
請求項２に記載の発明は、請求項１に記載の構成に加え、前記セッション管理手段は、前記ユーザのアクセス権限を認証するための認証情報を記録する第一の認証情報記録手段を備え、前記アクセス対象にアクセスを行う前記ユーザは、ｈｔｔｐ等、ネットワーク上のノード相互間でのデータ送受信にて用いられるリクエストを用いて、前記認証情報を前記第一の認証情報記録手段に記録させ、前記ユーザは、自らが所持する前記認証情報を前記アクセス実行手段に送信し、該アクセス実行手段は、前記セッション管理手段と前記アクセス実行手段との間に接続された前記ソケットを介して、前記ユーザから送信された前記認証情報と前記第一の認証情報記録手段に記録された前記認証情報と照合し、該照合の結果、双方の前記認証情報が適合した場合には前記ユーザを前記アクセス対象にアクセスさせることを特徴とする。
【００１１】
請求項３に記載の発明は、請求項２に記載の構成に加え、前記ユーザがアクセス可能に設けられた第二の認証情報記録手段を備え、該第二の認証情報記録手段には、前記第一の認証情報記録手段に記録されたものと同じ前記認証情報を記録し、前記ユーザは、前記アクセス対象にアクセスする際、前記第二の認証情報記録手段に記録された前記認証情報を前記アクセス実行手段に送信することを特徴とする。
【００１２】
請求項４に記載の発明は、請求項２又は３に記載の構成に加え、前記ユーザの入力した情報に基づいて前記認証情報を生成する認証情報生成手段を備え、該認証情報生成手段は、個々の前記ユーザを特定するためのユーザ特定情報を用いて、ランダムに生成されるランダムキーとして前記認証情報を生成することを特徴とする。
【００１３】
請求項５に記載の発明は、請求項４に記載の構成に加え、前記ユーザ特定情報として、個々の前記ユーザの真正性を識別するための文字、図形、記号等の識別情報を前記ユーザに入力させる、入力画面を表示させることを特徴とする。
【００１４】
請求項６に記載の発明は、請求項１乃至５の何れか一つに記載の構成に加え、前記ユーザに、前記アクセス対象へのアクセス状態を視認可能に表示させるアクセス状態表示手段を備え、前記アクセス実行手段は、前記アクセス状態表示手段において前記アクセス状態が視認できる場合にのみ、前記ユーザを前記アクセス対象にアクセスさせることを特徴とする。
【００１５】
請求項７に記載の発明は、請求項１乃至６の何れか一つに記載の構成に加え、前記アクセス対象はデータベースであることを特徴とする。
【００１６】
請求項８に記載の発明は、プログラムであって、コンピュータを請求項１乃至７の何れか一つに記載のアクセス可否管理システムとして機能させることを特徴とする。
【発明の効果】
【００１７】
請求項１に記載の発明によれば、アクセス実行手段は、セッション管理手段との間にソケットが接続されている間はユーザとアクセス実行手段との間のセッションを継続させることにより、ユーザとアクセス実行手段とのセッションの継続は、アクセス実行手段とセッション管理手段との間におけるソケットの接続状態によって決定される。すなわち、セッションの継続状態は、ユーザ側のクッキーの有無やクッキーの状態には依存しない。そのため、ログイン画面からログインしたユーザのクッキーを第三者が取得したとしても、その第三者はセッションハイジャックを行えず、セッションが有効の間そのユーザがリクエストを送信している状態を確定できる。これにより、第三者によるセッションハイジャックを防止できる。
【００１８】
請求項２に記載の発明によれば、第一の認証情報記録手段に記録された認証情報とユーザから送信された認証情報とを照合した結果、双方が適合した場合にはユーザをアクセス対象にアクセスさせることにより、認証情報を持たない第三者が不正にアクセス対象にアクセスすることを防止できる。また、認証情報との照合がセッション管理手段とアクセス実行手段との間に接続されたソケットを介して行われることにより、アクセス対象へのアクセスをセッションが継続している期間内とし、不要なアクセス許容時間の発生を抑止してセキュリティを高めることができる。
【００１９】
請求項３に記載の発明によれば、アクセス実行手段は、第二の認証情報記録手段に記録された、第一の認証情報記録手段に記録されたものと同じ認証情報を照合に用いることにより、アクセス権限のあるユーザに認証情報を所持させ、権限のある者のみを確実に認証させ、セキュリティを高めることができる。
【００２０】
請求項４に記載の発明によれば、ユーザの入力した情報に基づいて認証情報を生成することにより、個々のユーザの属性に対する依存性と一意性の高い認証情報を容易に形成できる。また、生成毎に異なるランダムキーとして認証情報を生成することにより、セキュアな認証情報を生成し、セキュリティを一層高めることができる。
【００２１】
請求項５に記載の発明によれば、入力画面へのユーザ自身の入力に基づいて、個々のユーザの属性に対する依存性と一意性の高いユーザ特定情報を取得し、認証情報を形成することができるので、ブルートフォース攻撃による不正アクセスを抑止し、セキュリティを一層高めることができる。
【００２２】
請求項６に記載の発明によれば、アクセス状態表示手段においてアクセス状態が視認できる場合にのみ、ユーザをアクセス対象にアクセスさせるので、ユーザの視認可否の状態を基準にアクセス対象へのアクセスの可否を決定することができる。これにより、アクセス対象へのアクセス時間を、ユーザがアクセスを必要としている時間のみにとどめて、セキュリティを一層高めることができる。
【００２３】
請求項７に記載の発明によれば、データベースに対する第三者の不正アクセスを防止し、セキュリティを一層高めることができる。
【００２４】
請求項８に記載の発明によれば、本発明をプログラムとして構成することにより、特定のハードウェアに依存せず、多様なコンピュータシステム上で本発明を実現することができる。
【図面の簡単な説明】
【００２５】
【図１】この発明の実施の形態に係る認証システム及びアクセス可否管理システムのネットワーク構成図及び機能ブロック図である。
【図２】同上のアクセス可否管理システムの処理手順を示すフローチャートである。
【図３】同上のアクセス可否管理システムの処理手順を示すフローチャートである。
【図４】同上のアクセス可否管理システムの処理手順を示すフローチャートである。
【図５】同上のアクセス可否管理システムにおける入力画面を模式的に示した図である。
【発明を実施するための形態】
【００２６】
図１乃至図５に、この発明の実施の形態を示す。
【００２７】
［基本構成］
図１は、この実施の形態の、セッションハイジャック防止のためのアクセス可否管理システム１（以下「アクセス可否管理システム１」と記載する。）を含む認証システム１Ａのネットワーク構成図及び機能ブロック図である。
【００２８】
このアクセス可否管理システム１は、アクセス権限のあるユーザのみが使用できるデータベースを備えたシステムである。
【００２９】
図１に示す通り、アクセス可否管理システム１は、Ｗｅｂサーバ２と、ＷｅｂＳｏｃｋｅｔサーバ３と、「アクセス対象」としてのデータベース４と、ルータ５とを有し、それらはＬＡＮ等の内部ネットワーク６によって通信可能に接続されている。アクセス可否管理システム１は、インターネット等の外部ネットワーク７を介してクライアント端末８が接続されている。
【００３０】
Ｗｅｂサーバ２は、Ｗｅｂシステムにおいて情報送信を行うサーバコンピュータである。Ｗｅｂサーバ２は、Ｗｅｂを介してデータの送受信を行う。
【００３１】
ＷｅｂＳｏｃｋｅｔサーバ３は、Ｗｅｂサーバ２にアクセスしようとするクライアント端末８のアクセスの可否を決定するための認証を行う。
【００３２】
データベース４は、Wｅｂサーバ２に接続され、ユーザの使用するアプリケーションデータ（テキストデータや図形データも含む）４１と、正当なアクセス権限を有するユーザ名とユーザに付与されたパスワードとの組み合わせがユーザデータ４２として記録されている。データベース４中のアプリケーションデータ４１には、正当なアクセス権限のあるユーザのみにアクセス制限されている。
【００３３】
ルータ５は、内部ネットワーク６と外部ネットワーク７との境界に設けられ、ＩＰアドレスを基にパケットのルーティングを行う。
【００３４】
クライアント端末８は、それぞれ、Ｗｅｂサーバ２へのアクセスを行う者としてのユーザ（以下単に「ユーザ」と称する）が使用する各種端末であり、パーソナルコンピュータ、携帯電話、スマートフォン、タブレットなどが該当する。なお、システム構成上はクライアント端末８が「ユーザ」にあたるが、以下は説明の便宜上クライアント端末８の使用者を「ユーザ」と称する。
【００３５】
クライアント端末８は、キーボードやマウス等の操作部８１、ＬＣＤ等「表示手段」としての表示部８２を備えている。タッチパネル等、操作部８１と表示部８２とが一体化したものでもよい。
【００３６】
この実施の形態において、Ｗｅｂサーバ２、ＷｅｂＳｏｃｋｅｔサーバ３、クライアント端末８は、それぞれ機能手段を備える。この「機能手段」とは、実装されたプログラムがネットワークで接続された計算機等で実行されることで実現される手段のことである。
【００３７】
この実施の形態における、それぞれの機能手段は、スクリプト言語例えばＰＨＰ（Hypertext Preprocessor）やJavaScript(登録商標)で記述されたプログラムによって実現され動的な処理を行う。なお、この実施の形態の機能手段は、同様の構成を形成し、同様の処理を行うものであれば、どのようなスクリプトやプログラミング言語で記述、構成されてもよい。
【００３８】
Ｗｅｂサーバ２は、機能手段として、「認証情報生成手段」としてのチケット生成部２１、「アクセス実行手段」としてのアクセス実行部２２と、セッションストレージ２３を備えている。
【００３９】
チケット生成部２１は、ユーザが操作部８１を用いて入力した入力情報に基づいて、「認証情報」としてのチケット１００を生成する。また、チケット生成部２１は、ＨＴＴＰ等の「リクエスト（ネットワーク上のノード相互間でのデータ送受信に用いられる構成のひとつ。）」等を用いて、チケット１００を仮登録記録部３１等に記録させる。アクセス実行部２２は、特定の条件が満たされたユーザからの要求に基づいて、データベース４にアクセスする。セッションストレージ２３は、認証やセッションで処理されるデータを一時的に保存する。
【００４０】
ＷｅｂＳｏｃｋｅｔサーバ３は、機能手段として、「第一の認証情報記録手段」としてのアクティブ登録記録部３２及び仮登録記録部３１と、「セッション管理手段」としてのＷｅｂＳｏｃｋｅｔ実行管理部３３とを備えている。
【００４１】
アクティブ登録記録部３２には、チケット生成部２１において生成されたチケット１００で、アクティブ登録のもの（即ち認証済みのもの）が記録される。
【００４２】
仮登録記録部３１には、チケット生成部２１において生成されたチケット１００で、認証される前の仮登録状態のものが一時的に記録される。
【００４３】
ＷｅｂＳｏｃｋｅｔ実行管理部３３は、クライアント端末８及びＷｅｂサーバ２のアクセス実行部２２によってアクセス可能である。ＷｅｂＳｏｃｋｅｔ実行管理部３３は、アクセス実行部２２との間でソケット接続による通信を行う。この「ソケット」は、ネットワーク上のノード相互間でのデータ送受信に用いられる。なお、この実施の形態において、ＷｅｂＳｏｃｋｅｔ実行管理部３３によるソケット通信は、実際にはＷｅｂサーバ２とＷｅｂＳｏｃｋｅｔサーバ３との間で行われ、「ソケット」は、ＷｅｂＳｏｃｋｅｔ（ＨＴＭＬ５で規定された、スクリプトから利用するソケット通信）３４を用い、ポート番号は例えば１４４０を用いる。但し同様の通信ができるならばＷｅｂＳｏｃｋｅｔ以外のハートビートを用いるプロトコルでもよい。
【００４４】
また、ＷｅｂＳｏｃｋｅｔ実行管理部３３は、Ｗｅｂサーバ２や、クライアント端末８のブラウザ８３が定期的に発信するハートビート（通信可能に接続されていることを示すための生存信号）を検知し、この検知状況に基づいてＷｅｂＳｏｃｋｅｔ３４の接続、接続状態の維持、切断の制御を行う。
【００４５】
なお、この実施の形態のアクセス可否管理システム１においては、上述のＷｅｂＳｏｃｋｅｔ３４以外にも、ルータ５とＷｅｂサーバ２との間に第一のソケット３５（ポート番号８０）、ルータ５とＷｅｂＳｏｃｋｅｔサーバ３との間に第二のソケット３６（ポート番号１３３７）、Ｗｅｂサーバ２とデータベース４との間に第三のソケット３７（ポート番号２７０１７）、ＷｅｂＳｏｃｋｅｔサーバ３とデータベース４との間に第四のソケット３８（ポート番号２７０１７）が形成される。なお、ＷｅｂＳｏｃｋｅｔ３４、第一〜第四のソケット３５，３６，３７，３８は、上記以外のどのポート番号を用いてもよい。
【００４６】
クライアント端末８の表示部８２には、機能手段として、「アクセス状態表示手段」としてのブラウザ８３が表示される。このブラウザ８３には、タブ８４１，・・・，８４を表示可能である。タブ８４は、一つのブラウザ８３上に複数表示可能である。ユーザはブラウザ８３上の表示により、データベース４のアプリケーションデータ４１へのアクセス状況を視認可能である。
【００４７】
クライアント端末８のブラウザ８３は、機能手段として、「第二の認証情報記録手段」としてのチケット記録部８５を備える。チケット記録部８５には、チケット生成部２１から供給されたチケット１００を記録する。
【００４８】
［処理手順］
図２、図３、図４は、この実施の形態のアクセス可否管理システム１の処理手順を示すフローチャートである。以下、このフローチャートに基づいて処理手順を説明する。
【００４９】
［ステップＳ００１］
まず、アクセス可否管理システム１を使用するユーザは、クライアント端末８のブラウザ８３からログインページのリクエストを送信する。このリクエストはＷｅｂサーバ２に送信されて、Ｗｅｂサーバ２はクライアント端末８にファイル応答を返す。
【００５０】
［ステップＳ００２］
クライアント端末８のブラウザ８３は、ログインページのファイルに基づいて、図５に示す、「入力画面」としてのログインフォーム９０を表示する。
【００５１】
ログインフォーム９０には、個々のユーザの真正性を識別するための文字、図形、記号等の識別情報をユーザに入力させるための構成が設けられている。具体的には、図５に示すように、ログインフォーム９０には、ユーザ名を入力するためのユーザ名入力欄９１、パスワードを入力するためのパスワード入力欄９２、キャプチャ表示欄９３、キャプチャ表示欄９３に表示されたキャプチャ（コンピュータが認識困難な崩し文字等）を入力するためのキャプチャ入力欄９４、送信ボタン９５が表示される。例えば、ユーザがこれらの入力欄９１，９２，９４に以下の入力を行う。
ユーザ名入力欄９１: admin
パスワード入力欄９２: swordfish1932
キャプチャ入力欄９４: elegant fish
ここで、キャプチャ入力欄９４にキャプチャを入力させるのは、ボット等のプログラムを用いたブルートフォース攻撃（総当たり攻撃）でパスワードクラックがされ、攻撃者がデータベース４に不正アクセスするような事態を抑止するためである。なお、キャプチャ以外でも、ブルートフォース攻撃を抑止可能などのような構成を用いてもよい。
【００５２】
［ステップＳ００３］
ユーザがログインフォーム９０のユーザ名入力欄９１、パスワード入力欄９２、キャプチャ入力欄９４に必要事項を入力した上、送信ボタン９５の操作を行うことによって、各入力欄９１，９２，９４に入力されたデータはＷｅｂサーバ２に送信される。  なお、ここでデータを送信する場合、httpなどのネットワーク通信プロトコルで送信するとパケット内にパスワード、ユーザ情報などはテキストとして記録されている。そのため、ＬＡＮアナライザ等のスニッフィングによりパスワードやユーザ情報が第三者に傍受される恐れがある。一方、パスワードなどをMD5、bcryptなどで一重暗号化してリクエスト送信等を行った場合、第三者に対してパスワード等を秘匿できるが、Ｗｅｂサーバ２もパスワード等を認識できなくなってＷｅｂサーバ２において有効なリクエストが不正なリクエストとして認識される恐れがある。そのため、ここでは、クライアント端末８からＷｅｂサーバ２に対し、パブリック・プライベートキー暗号化(TLS-SSL)を利用したネットワーク通信方式(https)でリクエストを送信するのが望ましい。
【００５３】
［ステップＳ００４］
Ｗｅｂサーバ２は、クライアント端末８からログインフォーム９０のデータを受け取った際は、まずキャプチャの入力を確認する。たとえば、キャプチャ表示欄９３に表示されたキャプチャが'elegant fish’である場合は、このキャプチャとキャプチャ入力欄９４に入力されたデータを照合し、
'elegant fish’ == ‘elegant fish’
である場合のみ、入力されたデータが正しいものとして扱い、以下のステップに進む。これにより、ブルートフォース攻撃を抑止できる。
【００５４】
［ステップＳ００５］
次に、Ｗｅｂサーバ２のチケット生成部２１は、クライアント端末８から送信されたパスワードをハッシュに置き換える。具体的には、例えば、パスワードが“swordfish”であった場合、このパスワードを、所定のハッシュ関数を用いて
swordfish => $2a$10$rzKsXaL2EmnRhofMKsmWPevtY9biZHPea6M7OoezcggSiFDXGatHW
のように変換する。
【００５５】
このように、パスワードをハッシュに置き換え、パスワードを暗号化してデータベース４に保存すれば、万が一ユーザデータ４２に不正アクセスがあった場合でもパスワードの漏洩を防止できる。
【００５６】
［ステップＳ００６］
次に、Ｗｅｂサーバ２は、データベース４のユーザデータ４２に基づいて、ユーザ名入力欄９１に入力されたユーザ名とパスワード入力欄９２に入力されたパスワードの組み合わせが正しいかどうかを確認する。Ｗｅｂサーバ２は、データベース４にクライアント端末８から送信されたユーザ名とハッシュに置き換えたパスワードのセットについて、第三のソケット３７を用いてデータベース４にクエリを送信する。例えば、下記のようなクエリを送信する。
user => admin
password => $2a$10$rzKsXaL2EmnRhofMKsmWPevtY9biZHPea6M7OoezcggSiFDXGatHW
データベース４からユーザデータをクエリする際にハッシュに置き換えたパスワードを用いるのは、第三者のＳＱＬインジェクション攻撃（不正スクリプトの入力によりデータベース４からデータを不正取得する攻撃）対策である。即ち、MongoDBを利用して、クエリに含まれるパスワードをハッシュに置き換えれば、不正スクリプトによるクエリを防止できる可能性が高まるからである。なお、ＳＱＬインジェクションを防止しうる構成を有するならば、MongoDB以外をデータベース４として利用してもよい。
【００５７】
ユーザ名とパスワードの組み合わせが正しい場合は、次のステップに進み、組み合わせが正しくない場合はクライアント端末８のブラウザ８３にエラー表示（図示せず）を示す。なお、Ｗｅｂサーバ２は、ユーザが同一のユーザ名に対するパスワードの入力を所定の回数違えた場合、そのユーザから（そのIPアドレスから）のリクエストを受け付けない処理とし、不正アクセスを未然防止する。
【００５８】
［ステップＳ００７］
前述のクエリの結果、データベース４からＷｅｂサーバ２に対し、クエリに一致するユーザ名とパスワードの組み合わせがあったとレスポンスがあった場合は、Ｗｅｂサーバ２のチケット生成部２１は、例えば下記に示すようなランダムキーの値を作成する。ランダムキーの値は毎回ランダムに生成される。このランダムキーがチケット１００として扱われる。
ticket => 29yuCB1MsRn40thTyGQBN708hXAo35EAlBLeHDZb
［ステップＳ００８］
チケットが作成されたら、Ｗｅｂサーバ２のチケット生成部２１から、ＷｅｂＳｏｃｋｅｔサーバ３に対し、第一のソケット３５、第二のソケット３６を用いて、例えば下記に示すような、チケット１００を仮登録するためのリクエストを送信する。
仮ticket => 29yuCB1MsRn40thTyGQBN708hXAo35EAlBLeHDZb
このリクエストにより、図１に示すように、チケット１００をＷｅｂＳｏｃｋｅｔサーバ３の仮登録記録部３１に一旦仮登録する。
【００５９】
チケット１００を仮登録してから、確認（後述）されるまでの時間はわずか数ミリ秒である。後述の処理により、チケット１００がＷｅｂサーバ２のコントロールパネルのページ（Ｗｅｂサーバ２がクライアント端末８のブラウザ８３に表示させる、サービスを開始する画面のページ。図示せず）にリダイレクト（後述）されてから、クライアント端末８からＷｅｂＳｏｃｋｅｔサーバ３に対して行われるＷｅｂＳｏｃｋｅｔリクエスト（後述）までは概ね数秒以内に完了する。もしクライアント端末８からＷｅｂＳｏｃｋｅｔリクエストがない場合は、有効なチケットを残さないためには、レスポンスが完了する、約15秒から約30秒以内にいない仮登録状態のチケット１００をＷｅｂＳｏｃｋｅｔサーバ３から削除するのが望ましい。
【００６０】
［ステップＳ００９］
Ｗｅｂサーバ２にＷｅｂＳｏｃｋｅｔサーバ３からの応答メッセージがきたら、Ｗｅｂサーバ２は、セッションストレージ２３にチケット１００を保存する。この実施の形態においてはPHPを利用しているのでセッションストレージ２３に仮チケットを一旦保存している。PHP以外にも、Ruby,Perlなどのサーバ言語で作成された構成においてはセッションストレージ２３は使用可能である。Ｗｅｂサーバ２上の（ログインフォーム９０から返されたデータが記録された）ログインページからコントロールパネルのページにチケット１００の値を渡すためには、一旦クライアント端末８のブラウザ８３においてクッキーを使う。クッキーには、Ｗｅｂサーバ２上で作成された仮チケットの値が記録され、クッキーはブラウザ８３のチケット記録部８５に記録される。このクッキーがhttp headerに書き込まれてＷｅｂサーバ２に送信される。他のリクエストに対してhttp headerにそのチケット１００の値が入っていれば、Ｗｅｂサーバ２上でそのチケット１００の値を読み込むことができる。このステップに関してはhttp headerに一旦（チケット１００の値の）クッキーを書き込んで、リダイレクトされた後は再度クライアント端末８に渡さずにリダイレクト先であるコントロールパネルのページ（図示せず）でチケット１００の値を確認する。加えて、この実施の形態では、クライアント端末８とＷｅｂサーバ２間をhttpsで通信することで、第三者によるチケット１００の値の盗聴を防止している。
【００６１】
［ステップＳ０１０］
Ｗｅｂサーバ２はクライアント端末８をログイン画面のページからコントロールパネルのページ（図示せず）にリダイレクトする。
【００６２】
［ステップＳ０１１］
コントロールパネルのページ（図示せず）は、Ｗｅｂサーバ２上で読み込まれる時はセッションストレージ２３にチケット１００の値が記録されているかを確認する。
【００６３】
［ステップＳ０１２］
チケット１００の値がセッションストレージ２３に記録されている場合は、Ｗｅｂサーバ２は、ＷｅｂＳｏｃｋｅｔサーバ３に対し、チケットは仮登録されているかの確認リクエストを送信する。具体的には、以下に示すような確認リクエストが送信される。
29yuCB1MsRn40thTyGQBN708hXAo35EAlBLeHDZb => 仮チケット？
この時点で、ログインした時点のユーザのチケット１００は仮登録の状態になっているはずである。ログインを試みる者が仮登録になっていない(アクティブ登録記録部３２に記録されている、またはＷｅｂサーバ２に記録されていない)ということは、この者はユーザのクッキーをコピーしてシステムに不正アクセスしようとしている攻撃者になる。そのため、このステップにおいては、チケット１００が仮登録の状態か否か（つまり、仮登録記録部３１にチケット１００のデータが記録されているか）を確認することにより、第三者の不正アクセスを防ぐことができる。
【００６４】
［ステップＳ０１３］
Ｗｅｂサーバ２は、コントロールパネルのページ（図示せず）をクライアント端末８のブラウザ８３に送信する前に、仮登録状態のチケット１００をJavaScript(登録商標)が読める態様でコントロールパネルのページ（図示せず）内に書き込む。具体的には、以下に示すような態様でチケット１００をコントロールパネルのページ（図示せず）に書き込む。
<script>
key = “29yuCB1MsRn40thTyGQBN708hXAo35EAlBLeHDZb”;
</script>
［ステップＳ０１４］
このコントロールパネルのページ（図示せず）を、Ｗｅｂサーバ２がクライアント端末８に送信する。クライアント端末８のブラウザ８３がコントロールパネルのページ（図示せず）を受け取って、このページ（図示せず）をレンダリングする前の時点で、ページ内のJavaScript(登録商標)が実行され、クライアント端末８のブラウザ８３はＷｅｂＳｏｃｋｅｔサーバ３に対してＷｅｂＳｏｃｋｅｔ接続のリクエストを送信する。
【００６５】
［ステップＳ０１５］
ＷｅｂＳｏｃｋｅｔサーバ３がクライアント端末８から送信されたリクエストを受信すると、ＷｅｂＳｏｃｋｅｔ実行管理部３３はＷｅｂＳｏｃｋｅｔサーバ３とＷｅｂサーバ２との間にＷｅｂＳｏｃｋｅｔ３４を接続させる。接続した時点で、クライアント端末８のブラウザ８３から前述のステップＳ０１３においてコントロールパネルのページ（図示せず）内に書き込まれたチケット１００の値が、ＷｅｂＳｏｃｋｅｔ３４を介してＷｅｂサーバ２からＷｅｂＳｏｃｋｅｔサーバ３に送信される。
【００６６】
［ステップＳ０１６］
ＷｅｂＳｏｃｋｅｔサーバ３上において、チケット１００が仮登録されているかのチェックが行われる。即ち、セッションストレージ２３に記録されたものと同じチケット１００が、仮登録記録部３１に記録されているかをチェックする。
【００６７】
［ステップＳ０１７］
ステップＳ１６のチェックの結果、仮登録されていることが確認された場合、ＷｅｂＳｏｃｋｅｔサーバ３上で、チケット１００を仮チケットの状態からアクティブの状態に変更する。すなわち、チケット１００を仮登録記録部３１からアクティブ登録記録部３２に移す。この状態で、Ｗｅｂサーバ２とＷｅｂＳｏｃｋｅｔサーバ３は、このチケット１００に係るユーザと、チケット１００の送信に用いられたＷｅｂＳｏｃｋｅｔ３４をアクティブなユーザとして認識する。
【００６８】
［ステップＳ０１８］
ＷｅｂＳｏｃｋｅｔ実行管理部３３は、クライアント端末８とＷｅｂＳｏｃｋｅｔサーバ３が接続している間はＷｅｂＳｏｃｋｅｔ３４を接続させたユーザ（つまり、アクティブ登録記録部３２にチケット１００が記録されたユーザ）を、セッションが継続中のユーザとして認識する。これにより、ブラウザ８３からのリクエストはＷｅｂサーバ２に送られ、Ｗｅｂサーバ２上で実行可能となる。具体的には、ユーザは、クライアント端末８から第一のソケット３５を介してＷｅｂサーバ２にアプリケーションデータ４１取得のリクエストを送信する。Ｗｅｂサーバ２は、このリクエストを受けると、第三のソケット３７を介してデータベース４にアクセスし、所望のアプリケーションデータ４１を取得してクライアント端末８のブラウザ８３に返す。
【００６９】
［ステップＳ０１９］
ＷｅｂＳｏｃｋｅｔ実行管理部３３は、クライアント端末８やＷｅｂサーバ２のハートビートを受信することで、クライアント端末８とＷｅｂサーバ２の通信が継続しているかを随時確認する。そして、クライアント端末８において、タブ８４を閉じる、ブラウザ８３を閉じる、または手動でログアウトすることにより、ハートビートの送信が途絶える。ハートビートが途絶えたことを確認すると、ＷｅｂＳｏｃｋｅｔ実行管理部３３はＷｅｂＳｏｃｋｅｔ３４を切断する。
【００７０】
［ステップＳ０２０］
ＷｅｂＳｏｃｋｅｔ実行管理部３３がＷｅｂＳｏｃｋｅｔ３４を切断した時点で、Ｗｅｂサーバ２とＷｅｂＳｏｃｋｅｔサーバ３は、クライアント端末８とＷｅｂサーバ２とのセッションが終了したものと認識し、アクティブ登録記録部３２に記録されたチケット１００と、コネクションの情報とをクリアする。ユーザがクライアント端末８を用いてデータベース４のアプリケーションデータ４１に再びアクセスするためには、再度のログインが必要となる。
【００７１】
以上、この実施の形態においては、アクセス実行部２２は、ＷｅｂＳｏｃｋｅｔサーバ３とＷｅｂサーバ２との間にＷｅｂＳｏｃｋｅｔ３４が接続されている間はユーザとアクセス実行部２２との間のセッションを継続させることにより、ユーザとアクセス実行部２２とのセッションの継続は、ＷｅｂＳｏｃｋｅｔサーバ３とＷｅｂサーバ２との間におけるＷｅｂＳｏｃｋｅｔ３４の接続状態によって決定される。すなわち、セッションの継続状態は、ユーザのクライアント端末８側のクッキーの有無やクッキーの状態には依存しない。そのため、ログインフォーム９０からログインしたユーザのクッキーを第三者が取得したとしても、その第三者はセッションハイジャックを行えず、セッションが有効の間そのユーザがリクエストを送信している状態を確定できる。これにより、第三者によるセッションハイジャックを防止できる。
【００７２】
この実施の形態においては、仮登録記録部３１に記録されたチケット１００とユーザによってクライアント端末８から送信されたチケット１００とを照合した結果、双方が適合した場合にはユーザをデータベース４にアクセスさせることにより、チケットを持たない第三者が不正にデータベース４にアクセスすることを防止できる。また、チケット１００との照合がＷｅｂＳｏｃｋｅｔサーバ３とＷｅｂサーバ２との間に接続されたＷｅｂＳｏｃｋｅｔ３４を介して行われることにより、データベース４へのアクセスをセッションが継続している期間内とし、不要なアクセス許容時間の発生を抑止してセキュリティを高めることができる。
【００７３】
この実施の形態においては、アクセス実行部２２は、チケット記録部８５のクッキーに記録された、仮登録記録部３１に記録されたものと同じチケット１００を照合に用いることにより、アクセス権限のあるユーザにチケット１００を所持させ、権限のある者のみを確実に認証させ、セキュリティを高めることができる。
【００７４】
この実施の形態においては、ユーザがログインフォーム９０に入力した情報に基づいてチケット１００を生成することにより、個々のユーザの属性に対する依存性と一意性の高いチケット１００を容易に形成できる。また、生成毎に異なるランダムキーとしてチケット１００を生成することにより、セキュアなチケット１００を生成し、セキュリティを一層高めることができる。
【００７５】
この実施の形態においては、ログインフォーム９０へのユーザ自身の入力に基づいて、個々のユーザの属性に対する依存性と一意性の高いユーザ特定情報を取得し、チケット１００を形成することができるので、ブルートフォース攻撃による不正アクセスを抑止し、セキュリティを一層高めることができる。
【００７６】
この実施の形態においては、クライアント端末８に表示されたブラウザ８３においてアクセス状態が視認できる場合にのみ、ユーザをデータベース４にアクセスさせるので、ユーザの視認可否の状態を基準にデータベース４へのアクセスの可否を決定することができる。これにより、データベース４へのアクセス時間を、ユーザがアクセスを必要としている時間のみにとどめて、セキュリティを一層高めることができる。
【００７７】
なお、この実施の形態においては、Ｗｅｂサーバ２のデータベース４にアクセスするためにアクセス可否管理システム１を適用したが、これに限らず、内部ネットワーク６内や外部ネットワーク７内に存在するどのような構成、例えばＷｅｂサーバ、クライアント端末としてのパーソナルコンピュータや携帯端末やタブレット等にも適用できる。
【００７８】
上記実施の形態においては、アクセス可否管理システム１をクライアント・サーバシステムのサーバ側に適用したが、これに限定されず、アクセス可否管理システム１の構成の少なくとも一部がクライアント側に構成されているものにも適用できる。また、スタンドアロンのコンピュータにも適用できる。
【００７９】
上記実施の形態においては、アクセス可否管理システム１の各機能手段をプログラムによって構成したが、機能手段のうち一部又は全部をハードウェアロジックによって構成することもできる。
【産業上の利用可能性】
【００８０】
本発明は、高いセキュリティが求められる各種の構成、例えば金融取引用のシステムや、企業や大学等の機密事項（例えば研究データや、社員や学生の個人情報等）を管理するデータベースや、官公庁のＷｅｂサーバやデータベース等に適用することが考えられる。これにより、機密事項や公共性の高い事項に対する不正アクセスを効果的に防止できる。
【符号の説明】
【００８１】
１・・・アクセス可否管理システム
３・・・ＷｅｂＳｏｃｋｅｔサーバ（セッション管理手段）
４・・・データベース（アクセス対象）
８・・・クライアント端末（ユーザ）
２１・・・チケット生成部（認証情報生成手段）
２２・・・アクセス実行部（アクセス実行手段）
３１・・・仮登録記録部（第一の認証情報記録手段）
３２・・・アクティブ登録記録部（第一の認証情報記録手段）
３４・・・ＷｅｂＳｏｃｋｅｔ実行管理部（セッション管理手段）
３５・・・ＷｅｂＳｏｃｋｅｔ
８３・・・ブラウザ（アクセス状態表示手段）
８５・・・チケット記録部（第二の認証情報記録手段）
９０・・・ログインフォーム（入力画面）
１００・・・チケット（認証情報、ランダムキー）
【図１】
2015158881.tif 000003
【図２】
2015158881.tif 000004
【図３】
2015158881.tif 000005
【図４】
2015158881.tif 000006
【図５】
2015158881.tif 000007