JP2015011659A

JP2015011659A - 通信装置、アクセス制御方法およびプログラム

Info

Publication number: JP2015011659A
Application number: JP2013138888A
Authority: JP
Inventors: 幸三池上; Kozo Ikegami; 裕章宮田; Hiroaki Miyata
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2013-07-02
Filing date: 2013-07-02
Publication date: 2015-01-19
Anticipated expiration: 2033-07-02
Also published as: JP6059610B2

Abstract

【課題】エンドユーザに負担をかけることなく、正規サイトへの重要情報の送信を許可し、フィッシングサイトへの送信は遮断すること。【解決手段】クライアント端末１００からのリクエストがホワイトリストとブラックリストに該当しない場合、ネットワーク装置４００は、サーバ６００からのレスポンスがクライアント端末１００に対してデータ送信を促しているかどうかを確認し、促している場合はクライアント端末１００から送信されるリクエストに促された情報がふくまれている場合にリクエストを遮断する。または、ネットワーク装置４００は、クライアント端末１００から送信されるリクエストにあらかじめ流出させたくない情報が含まれている場合にリクエストを遮断する。【選択図】図１

Description

本発明は、通信装置、アクセス制御方法およびプログラムに係り、特に、ネットワークセキュリティを確保するための通信装置、アクセス制御方法およびプログラム関する。

インターネットバンキングや通販など、インターネット上でＨＴＴＰ（ＨｙｐｅｒＴｅｘｔＴｒａｎｓｆｅｒＰｒｏｔｏｃｌ、非特許文献２）を利用して商取引が普及して以来、フィッシングサイトに誘導し個人情報やＩＤ・パスワードを盗みとるフィッシング（Ｐｈｉｓｈｉｎｇ）被害が増えている。
フィッシングの有効的な対策として、非特許文献１にはユーザがアクセスしようとするＵＲＬ（ＵｎｉｆｏｒｍＲｅｓｏｕｒｃｅＬｏｃａｔｏｒ）と、あらかじめ用意したＵＲＬのブラックリストを比較し、フィッシングサイトへのアクセスを遮断する方法や、ＥＶＳＳＬ（ＥｘｔｅｎｄｅｄＶａｌｉｄａｔｉｏｎＳｅｃｕｒｅＳｏｃｋｅｔＬａｙｅｒ）を用いた方法が記載されている。
また、サイトアクセスを制御する方法として特許文献１には、クライアントとサーバ間の装置に、アクセス許可サイトのリストを含む第１データベース、アクセス禁止リストのリストを含む第２データベースを備え、第１データベースにある場合はアクセスを許可し、第２データベースにある場合はアクセスを禁止する技術が記載されている。さらに第１データベースおよび第２データベースに含まれないサイトへのアクセスに対しては禁止語キーワードの有無を確認し禁止語がある場合でも有益語が含まれる場合にはアクセスを許可する技術が記載されている。

特許３６０５３４３号公報

フィッシング対策協議会「消費者向けフィッシング対策ガイドライン」２０１２年１２月ＲＦＣ２６１６

フィッシングサイトは次々とサーバを変更しつくられるため、非特許文献１に記述されたブラックリストにより遮断する場合、ブラックリストに登録されるまでの間は被害を防ぐことができない場合がある。
近年、個人情報やＩＤ・パスワードなど第３者に知られたくない情報をサーバへ送信する場合、信頼できるサーバであれば非特許文献１に記述されたＥＶＳＳＬが適用されることが一般的になってきている。ＥＶＳＳＬが適用されているかどうかを最終的に判断するのはエンドユーザであり、フィッシング手口が巧妙化しており、例えば、正規サイトからポップアップによってフィッシングサイトを表示させることで、エンドユーザがＥＶＳＳＬが適用された正規サイトであると誤認識してしまう場合もある。
また、正規サイトをホワイトリストとして登録し、アクセス時に登録されている場合はアクセスを許可する方法もある。ただし、インターネット上で商取引に用いられるサイト自体も日々増えており、ホワイトリストの最新化も難しいため、ホワイトリストにないサイトへのアクセスを許可しない運用も難しいことが想定される。
さらに、特許文献１で記述される方法でフィッシング対策をする場合、フィッシングサイトは正規サイトと誤認識させるために、サイトで使用されるキーワードは正規サイトで使用される有益語を含む場合があり、完全な対処が難しい場合がある。

本発明は、以上の点に鑑み、エンドユーザに負担をかけることなく、正規サイトへの重要情報の送信を許可し、フィッシングサイトへの重要情報の送信を遮断することを目的とする。

本発明の第１の解決手段によると、
ひとつ又は複数のアクセス許可サイトを予め記憶したホワイトリストと、
ひとつ又は複数のフィッシングサイトを予め記憶したブラックリストと、
サーバアドレス及び／又はクライアントアドレスと、特定情報又は流出禁止キーワードとを対応して記憶する特定リストと、
処理部と、
を備え、
前記処理部は、
クライアント端末からサーバに向けたリクエストが、前記ホワイトリストに該当する場合はアクセスを許可し、前記ブラックリストに該当する場合はアクセスを遮断し、
前記ホワイトリストおよび前記ブラックリストのいずれかにも該当しない場合は、
前記リクエストの宛先アドレス及び／又は送信元アドレスが前記特定リストに記録されたサーバアドレス及び／又はクライアントアドレスに該当するかを確認し、
該当した場合に、前記リクエストのパケット種別により前記リクエストの予め定められた領域に、前記特定リスト内に前記サーバアドレス及び／又はクライアントアドレスに対する特定情報又は流出禁止キーワードが含まれないかを確認し、含まれる場合は前記リクエストを廃棄し、含まれない場合は前記リクエストをサーバに向けて転送する
通信装置が提供される。

本発明の第２の解決手段によると、
通信装置におけるアクセス制御方法であって、
前記通信装置は、
ひとつ又は複数のアクセス許可サイトを予め記憶したホワイトリストと、
ひとつ又は複数のフィッシングサイトを予め記憶したブラックリストと、
サーバアドレス及び／又はクライアントアドレスと、特定情報又は流出禁止キーワードとを対応して記憶する特定リストと、
処理部と、
を備え、
前記処理部は、
クライアント端末からサーバに向けたリクエストが、前記ホワイトリストに該当する場合はアクセスを許可し、前記ブラックリストに該当する場合はアクセスを遮断し、
前記ホワイトリストおよび前記ブラックリストのいずれかにも該当しない場合は、
前記リクエストの宛先アドレス及び／又は送信元アドレスが前記特定リストに記録されたサーバアドレス及び／又はクライアントアドレスに該当するかを確認し、
該当した場合に、前記リクエストのパケット種別により前記リクエストの予め定められた領域に、前記特定リスト内に前記サーバアドレス及び／又はクライアントアドレスに対する特定情報又は流出禁止キーワードが含まれないかを確認し、含まれる場合は前記リクエストを廃棄し、含まれない場合は前記リクエストをサーバに向けて転送する
アクセス制御方法が提供される。

本発明の第３の解決手段によると、
通信装置におけるアクセス制御プログラムであって、
前記通信装置は、
ひとつ又は複数のアクセス許可サイトを予め記憶したホワイトリストと、
ひとつ又は複数のフィッシングサイトを予め記憶したブラックリストと、
サーバアドレス及び／又はクライアントアドレスと、特定情報又は流出禁止キーワードとを対応して記憶する特定リストと、
処理部と、
を備え、
前記処理部が、クライアント端末からサーバに向けたリクエストが、前記ホワイトリストに該当する場合はアクセスを許可し、前記ブラックリストに該当する場合はアクセスを遮断する手順と、
前記ホワイトリストおよび前記ブラックリストのいずれかにも該当しない場合は、
前記処理部が、前記リクエストの宛先アドレス及び／又は送信元アドレスが前記特定リストに記録されたサーバアドレス及び／又はクライアントアドレスに該当するかを確認する手順と、
前記処理部が、該当した場合に、前記リクエストのパケット種別により前記リクエストの予め定められた領域に、前記特定リスト内に前記サーバアドレス及び／又はクライアントアドレスに対する特定情報又は流出禁止キーワードが含まれないかを確認し、含まれる場合は前記リクエストを廃棄し、含まれない場合は前記リクエストをサーバに向けて転送する手順と
をコンピュータに実行させるためのアクセス制御プログラムが提供される。

本発明によると、エンドユーザに負担をかけることなく、正規サイトへの重要情報の送信を許可し、フィッシングサイトへの重要情報の送信を遮断することができる。

本実施例のネットワークの構成例を示す図である。実施例１のネットワーク装置４００の構成例を示す図である。ＨＴＴＰパケットフォーマット７００である。クライアント端末１００からのＨＴＴＰリクエストの例を示す説明図である。ホワイトリスト（ＤＢ１）４３１の例である。ブラックリスト（ＤＢ２）４３２の例である。サーバ６００からのＨＴＴＰレスポンス内メッセージボディ７３４の例を示す説明図である。クライアント端末１００のブラウザ表示の例を示す図である。実施例１のネットワーク上のシーケンス図である。実施例１におけるネットワーク装置４００がクライアント側インタフェース４５０を介してパケットを受信したときの処理フローチャートである。実施例１におけるネットワーク装置４００がサーバ側インタフェース４６０を介してパケットを受信したときの処理フローチャートである。更新前のフィルタリングリスト（ＤＢ４）４３４の例である。入力指示項目リスト（ＤＢ３）４３３の例である。更新後のフィルタリングリスト（ＤＢ４）４３４の例である。実施例２のネットワーク装置４００ａの構成例を示す図である。流出禁止キーワードリスト（ＤＢ５）４３６の例である。実施例２におけるネットワーク装置４００がクライアント側インタフェース４５０を介してパケット受信したときの処理フローチャートである。

１．概要

本実施例では、ネットワーク装置は、クライアント端末からのリクエストに対して、まずアクセスが許可されるサーバが記録されたホワイトリストを確認し、クライアント端末がアクセスしようとしているサーバが許可されているかどうかを確認する。
サーバがホワイトリストで許可されていない場合は、ネットワーク装置は、ブラックリストを確認し、クライアント端末がアクセスしようとしているサーバが禁止されているかどうかを確認する。
アクセスしようとしているサーバが、ホワイトリストおよびブラックリストに該当しない場合は、ネットワーク装置は、リクエストをサーバへ転送し、サーバからのレスポンスに対して、クライアント端末にデータ送信を促す内容が含まれていないかを確認する。
データ送信を促す内容が含まれている場合、ネットワーク装置は、そのデータが個人情報やＩＤ・パスワード等の重要情報の送信を促すような入力指示項目がふくまれているかどうかを確認する。
入力指示項目が含まれている場合、ネットワーク装置は、サーバからのレスポンスをもとにサーバのＩＰアドレスとクライアント端末のＩＰアドレスと、入力指示項目に対応した変数名を記録する。
次に、クライアント端末からサーバに対してリクエストを送信する際に、ネットワーク装置は、クライアント端末からのリクエストをもとにサーバのＩＰアドレスとクライアント端末のＩＰアドレスを比較し、上述の手段で記録したＩＰアドレスの組み合わせに該当するかを確認する。
組合せが該当する場合、ネットワーク装置は、Ｍｅｔｈｏｄがｇｅｔの場合はＵＲＩを、ｐｏｓｔの場合はメッセージボディを確認し、上述の手段で記録した変数名に該当する情報が含まれないかを確認する。ネットワーク装置は、変数名に該当する情報が含まれる場合はリクエストを廃棄し、含まれない場合は転送する。
また、より確実に個人情報やＩＤ・パスワード等の重要情報の送信を遮断するために、ネットワーク装置は、あらかじめクライアント端末のＩＰアドレスごとに登録した流出禁止キーワードのリストを利用する。クライアント端末からリクエストが送信される場合、ネットワーク装置は、そのリクエストをもとにクライアント端末のＩＰアドレスが上述のリストに該当しないかを確認する。ＩＰアドレスが該当する場合は、ネットワーク装置は、Ｍｅｔｈｏｄがｇｅｔの場合はＵＲＩを、ｐｏｓｔの場合はメッセージボディを確認し、流出禁止キーワードが含まれないかを確認する。流出禁止キーワードが含まれる場合、ネットワーク装置は、パケットを廃棄する。

２．実施の形態

以下、実施例を、図面を用いて説明する。

本実施例では、主に、アクセス制御を行うネットワーク装置４００の例を説明する。
図１は、本実施例のネットワークの構成例を示す図である。
クライアント端末１００とネットワーク装置４００は第１のネットワーク２００で接続され、ネットワーク装置４００と正規サイトを有するサーバ５００およびフィッシングサイトを有するサーバ６００は第２のネットワーク３００で接続される。

図２は、ネットワーク装置４００の構成例を示す図である。
ネットワーク装置４００は、第１のネットワーク２００に接続されるクライアント側インタフェース４５０と、第２のネットワーク３００に接続されるサーバ側インタフェース４６０、パケット処理を行うＣＰＵ４２０と、処理する際に参照および更新するデータベースＤＢ１４３１、ＤＢ２４３２、ＤＢ３４３３、ＤＢ４４３４および処理のログＬＯＧ４３５が格納されるストレージ４３０と、ＣＰＵ４２０のプログラムが走行するＲＡＭ４１０を備える。また、保守インタフェース４７０は、データベースＤＢ１４３１、ＤＢ２４３２、ＤＢ３４３３、ＤＢ４４３４のメンテナンスおよびログ４３５の取り出し用に用いられる。なお、以下では、データベースＤＢ１４３１をホワイトリスト４３１、データベースＤＢ２４３２をブラックリスト４３２、データベースＤＢ３４３３を入力指示項目リスト４３３、データベースＤＢ４４３４をフィルタリングリスト４３４と呼ぶことがある。

図３は、クライアント端末１００とサーバ５００又は６００の間でやりとりされるＨＴＴＰパケット７００のフォーマットである。
ＨＴＴＰパケット７００は、ＩＰヘッダ７１０、ＴＣＰヘッダ７２０、ＨＴＴＰデータ７３０を含む。ＩＰヘッダ７１０には送信元ＩＰアドレス７１１と宛先ＩＰアドレス７１２が含まれ、ＴＣＰヘッダ７２０には送信元ポート番号７２１と宛先ポート番号７２２が含まれる。ＨＴＴＰデータ７３０は、クライアント端末１００から送信されるリクエストの場合は、リクエスト行７３１、メッセージヘッダ７３２、空白行７３３、メッセージボディ７３４を含み、同様にサーバ５００又は６００から送信されるレスポンスの場合は、ステータス行７３１、メッセージヘッダ７３２、空白行７３３、メッセージボディ７３４を含む。

図４は、クライアント端末１００から送信されるＨＴＴＰリクエストの例を示す説明図である。
リクエスト行７３１にはＭｅｔｈｏｄ、ＵＲＩ（ＵｎｉｆｏｒｍＲｅｓｏｕｒｃｅＩｄｅｎｔｉｆｉｅｒ）、ＨＴＴＰバージョンを含む。メッセージヘッダ７３２にはクライアント端末１００がサポートするデータのタイプ、圧縮方法のほかに要求先サーバのホスト名（Ｈｏｓｔ）が含まれる。図４の例では、ホスト名ｗｗｗ．ｘｘｘ．ｚｚｚのサーバに対して／ｉｎｄｅｘ．ｈｔｍｌのデータを要求することになる。

図５は、ホワイトリスト（ＤＢ１）４３１の例である。
ホワイトリスト（ＤＢ１）４３１は、あらかじめアクセスを許可するサーバのホスト名が保守インタフェース４７０を介して登録されている。

図６は、ブラックリスト（ＤＢ２）４３２の例である。
ブラックリスト（ＤＢ２）４３２は、あらかじめアクセスを禁止するサーバのホスト名が保守インタフェース４７０を介して登録されている。

図１２は、更新前のフィルタリングリスト（ＤＢ４）４３４の例である。
フィルタリングリスト（ＤＢ４）４３４は、宛先ＩＰアドレス（サーバアドレス）、送信元ＩＰアドレス（クライアントアドレス）に対して、ｎａｍｅ等のキーワード（特定情報）を記憶する。

図１３は、入力指示項目リスト（ＤＢ３）４３３の例である。
入力指示項目リスト（ＤＢ３）４３３は、ひとつ又は複数の入力指示項目を記憶する。入力指示項目リスト４３３には、フィッシングサイトが入力を促す項目を、保守インタフェース４７０を介してあらかじめ登録しておくことができる。

図７は、サーバ６００から送信されるＨＴＴＰレスポンスのなかで、クライアント端末１００にデータ入力を促すｆｏｒｍタグが含まれる、メッセージボディ７３４の例を示す説明図である。

図８は、図７に示したようなメッセージボディを含むＨＴＴＰレスポンスを受信したクライアント端末１００のブラウザ表示の例を示す図である。
この例の場合、クライアントは、クライアント端末１００により“ＩＤ”と“ＰＡＳＳＷＯＲＤ”を入力し、確認ボタンを押すと、入力された情報が変数名“ｄａｔａ１”と変数名“ｄａｔａ２”としてサーバに送信される。

図９はネットワーク上のシーケンス図を示す。また、図１０はネットワーク装置４００がクライアント側インタフェース４５０を介してパケットを受信した際の処理フローチャートを示し、図１１はネットワーク装置４００がサーバ側インタフェース４６０を介してパケットを受信した際の処理フローチャートを示す。

まず、クライアント端末１００が、正規サイトを有するサーバ５００にＨＴＴＰリクエスト以外のリクエスト又はＨＴＴＰリクエストを送信した場合の処理を、図９の（ａ）を用いて説明する。
クライアント端末１００が正規サイトを有するサーバ５００向けにリクエストを送信し（Ｆ１）た場合、ネットワーク装置４００のＣＰＵ４２０は、図１０のフローチャートに従って処理を行う。ネットワーク装置４００のＣＰＵ４２０が、リクエストをクライアント側インタフェース４５０を介して受信した（Ｓ０）場合、ＣＰＵ４２０は、パケットのＴＣＰヘッダ７２０の宛先ポート番号７２２を元にパケットがＨＴＴＰかどうかを確認する（Ｓ１）。パケットがＨＴＴＰではないと判断した場合、ＣＰＵ４２０は、そのままパケットをサーバ側インタフェース４６０からサーバ５００向けに転送する（Ｓ１０、Ｆ２）。一方、パケットがＨＴＴＰであると判断した場合、ＣＰＵ４２０は、メッセージヘッダ７３２のホスト名が、図５に示すホワイトリスト（ＤＢ１）４３１に記載されたホスト名のいずれかに該当するかを確認し（Ｓ２）、該当した場合も、ＣＰＵ４２０は、パケットがＨＴＴＰではないと判断した場合と同様にパケットをサーバ側インタフェース４６０からサーバ５００向けに転送する（Ｓ１０、Ｆ２）。
サーバ５００からのレスポンスＦ３をサーバ側インタフェース４６０で受信すると（Ｓ１１）、ネットワーク装置４００のＣＰＵ４２０は、図１１のフローチャートに従って処理を行う。ＣＰＵ４２０は、パケットのＴＣＰヘッダ７２０の送信元ポート番号７２１を元にパケットがＨＴＴＰかどうかを確認する（Ｓ１２）。パケットがＨＴＴＰではないと判断した場合、ＣＰＵ４２０は、そのままパケットをクライアント側インタフェース４５０から転送する（Ｓ１６、Ｆ４）。

次に、クライアント端末１００が図６に示すブラックリスト（ＤＢ２）４３２のいずれかに該当するサーバにＨＴＴＰリクエストを送信した場合の処理を、図９の（ｂ）を用いて説明する。
クライアント端末１００がＨＴＴＰリクエストを送信し（Ｆ５）、ネットワーク装置４００のＣＰＵ４２０がクライアント側インタフェース４５を介してＨＴＴＰリクエストを受信すると（Ｓ０）、ＣＰＵ４２０は、図１０のフローチャートに従って処理を行う。ＣＰＵ４２０は、上述の手順と同等にパケットがＨＴＴＰであることを確認し（Ｓ１）、ホワイトリスト４３１に該当しないことを確認する（Ｓ２）。ＣＰＵ４２０は、その後、メッセージヘッダ７３２内のホスト名が図６に示すブラックリスト（ＤＢ２）４３２に記憶されたホスト名のいずれかに該当するかを確認し（Ｓ３）、該当する場合はパケットを廃棄する（Ｓ９）。

次に、クライアント端末１００が、ホワイトリスト４３１およびブラックリスト４３２に該当しない、フィッシングサイトを有するサーバ６００にＨＴＴＰリクエストを送信した場合の処理を、図９の（ｃ）を用いて説明する。
クライアント端末１００がＨＴＴＰリクエストを送信し（Ｆ６）、ネットワーク装置４００のＣＰＵ４２０がクライアント側インタフェース４５０を介してＨＴＴＰリクエストを受信すると（Ｓ０）、ＣＰＵ４２０は、図１０のフローチャートに従って処理を行う。ＣＰＵ４２０は、上述の手順と同等に、パケットがＨＴＴＰであることを確認し（Ｓ１）、ホワイトリスト４３１に該当しないことを確認する（Ｓ２）。

ＣＰＵ４２０は、メッセージヘッダ７３２のホスト名がブラックリスト４３２に該当しないことを確認すると（Ｓ３）、その後、図１２に示すフィルタリングリスト（ＤＢ４）４３４を確認し、ＩＰヘッダ７１０の送信元ＩＰアドレス７１１と宛先ＩＰアドレス７１２の組み合わせが、このフィルタリングリスト４３４に登録されている送信元ＩＰアドレスと宛先ＩＰアドレスの組み合わせに該当しないかを確認する（Ｓ４）。フィルタリングリスト４３４は、後述するように、フィッシングサイトを有するサーバ６００からレスポンスを受信した際に更新されるため、この時点では、図１２に示すとおり該当するＩＰアドレスの組み合わせがない。このため、ＣＰＵ４２０は、サーバ側インタフェース４６０からパケットをサーバ６００向けに転送する（Ｓ１０、Ｆ７）。

ネットワーク装置４００のＣＰＵ４２０は、サーバ６００からのレスポンスＦ８をサーバ側インタフェース４６０を介して受信すると（Ｓ１１）、図１１のフローチャートに従って処理を行う。まず、ＣＰＵ４２０は、パケットのＴＣＰヘッダ７２０の送信元ポート番号７２１を元にパケットがＨＴＴＰかどうかを確認し（Ｓ１２）、パケットがＨＴＴＰだった場合、メッセージボディ７３４の中に、情報入力を促すｆｏｒｍタグが含まれるかを確認する（Ｓ１３）。ｆｏｒｍタグが含まれない場合、ＣＰＵ４２０は、パケットをクライアント側インタフェース４５０からクライアント端末１００向けに転送する（Ｓ１６、Ｆ９）。

ステップＳ１３で、メッセージボディ７３４の中にｆｏｒｍタグが含まれる場合には、ＣＰＵ４２０は、図１３に示す入力指示項目リスト（ＤＢ３）４３３のいずれかの入力指示項目がｆｏｒｍタグ内に含まれるかを確認する（Ｓ１４）。いずれかの入力指示項目がｆｏｒｍタグ内に含まれない場合、ＣＰＵ４２０は、パケットをクライアント側インタフェース４５０からクライアント端末１００向けに転送する（Ｓ１６、Ｆ９）。
ステップＳ１４で、ｆｏｒｍタグが図７に示す例だった場合は、“ＩＤ”と“ＰＡＳＳＷＯＲＤ”が入力指示項目リスト４３３の入力指示項目に該当することになる。図７に示すように、入力指示項目がｆｏｒｍタグ内に含まれる場合（Ｓ１４）、ＣＰＵ４２０は、宛先ＩＰアドレス、送信元ＩＰアドレスに対して、ｎａｍｅをフィルタリングリスト４３４に記録する（Ｓ１５）。このとき、入力指示項目リスト４３３の複数の入力指示項目に該当する場合は、ＣＰＵ４２０は、宛先ＩＰアドレス、送信元ＩＰアドレスに対して、ｎａｍｅを複数行で記録する。
たとえば、図７の例では、ＣＰＵ４２０は、“ＩＤ”の後ろに記述されるｉｎｐｕｔタグのｎａｍｅで指定する変数名“ｄａｔａ１”をフィルタリングリスト（ＤＢ４）４３４のｎａｍｅ列に、パケットのＩＰヘッダ７１０の送信元ＩＰアドレス７１１をフィルタリングリスト４３４の宛先ＩＰアドレス列に、同ＩＰヘッダ７１０の宛先ＩＰアドレス７１２をフィルタリングリスト４３４の送信元ＩＰアドレス列に対応して記録する（Ｓ１５）。さらに、ＣＰＵ４２０は、“ＰＡＳＳＷＯＲＤ”の後ろに記述されるｉｎｐｕｔタグのｎａｍｅで指定する変数名“ｄａｔａ２”をフィルタリングリスト４３４のｎａｍｅ列に、送信元ＩＰアドレス７１１（サーバアドレス）をフィルタリングリスト４３４の宛先ＩＰアドレス列に、宛先ＩＰアドレス７１２（クライアントアドレス）をフィルタリングリスト４３４の送信元ＩＰアドレス列に対応して記憶する。

図１４は、更新後のフィルタリングリスト（ＤＢ４）４３４の例である。
図１４の例では、図７に対応して、２つの行でフィルタリングリスト（ＤＢ４）４３４が記憶されている。

ステップＳ１５で、ＣＰＵ４２０は、フィルタリングリスト４３４に宛先ＩＰアドレス、送信元ＩＰアドレスおよびｎａｍｅを記録後、パケットをクライアント側インタフェース４５０からクライアント端末１００向けに転送される（Ｓ１６、Ｆ９）。上述のｆｏｒｍタグを含むレスポンスＦ９を受信したクライアント端末１００では、図８のようにブラウザが表示される。このときに、例えば、クライアントは、クライアント端末１００により“ＩＤ”と“ＰＡＳＳＷＯＲＤ”の情報を入力し、確認ボタンを押すとＨＴＴＰリクエストＦ１０がサーバ６００向けに送信される。このＨＴＴＰリクエストをクライアント側インタフェース４５０で受信した（Ｓ０）ネットワーク装置４００のＣＰＵ４２０は、上述と同様に図１０のフローチャートのステップＳ１〜Ｓ３に従って処理を行い、その後、ＩＰヘッダ７１０内の送信元ＩＰアドレス７１１と宛先ＩＰアドレス７１２の組み合わせが、フィルタリングリスト（ＤＢ４）４３４（図１４参照）の送信元ＩＰアドレスと宛先ＩＰアドレスの組み合わせに該当するかを確認する（Ｓ４）。
該当する場合は、ＣＰＵ４２０は、リクエスト行７３１のＭｅｔｈｏｄがｇｅｔなのかｐｏｓｔなのかを確認し（Ｓ５）、ｇｅｔの場合はリクエスト行７３１のＵＲＩをチェックし（Ｓ６）、ｐｏｓｔの場合はメッセージボディ７３４をチェックし（Ｓ７）、フィルタリングリスト（ＤＢ４）４３４（図１４参照）において送信先ＩＰアドレスと宛先ＩＰアドレスの組み合わせが該当した行に記録されたｎａｍｅが含まれるかを確認する（Ｓ８）。ＣＰＵ４２０は、ｎａｍｅが含まれる場合はパケットを廃棄し（Ｓ９）、含まれない場合はサーバ側インタフェース４６０からサーバ向けにパケットを転送する（Ｓ１０）。このとき、送信元ＩＰアドレス７１１と宛先ＩＰアドレス７１２の組み合わせがフィルタリングリスト４３４の複数行に該当した場合は、ＣＰＵ４２０は、該当する行に登録されたｎａｍｅが１つでもパケットに含まれる場合はパケットを廃棄する。

本実施例では、個人情報やＩＤ・パスワード等の流出させたくない情報をより確実に遮断できる方法を説明する。
図１５に、本実施例のネットワーク装置４００ａの構成図を示す。
実施例１のネットワーク装置４００との差分は、ストレージ４３０に入力指示項目リスト（ＤＢ３）４３３およびフィルタリングリスト（ＤＢ４）４３４の代わりに、データベースＤＢ５４３６（以下、流出禁止キーワードリスト４３６と呼ぶことがある。）が配置されることである。

図１６は、流出禁止キーワードリスト（ＤＢ５）４３６の例である。
図１６に示すとおり、流出禁止キーワードリスト（ＤＢ５）４３６は、クライアント端末のＩＰアドレスに対して流出禁止キーワード（Ｋｅｙｗｏｒｄ）を記憶する。流出禁止キーワードリスト４３６には、あらかじめ、クライアント端末ごとに流出させたくない情報を、保守インタフェース４７０を介して登録しておくことができる。図１６の場合、例えば、ＩＰアドレスが１００．１００．１００．１００のクライアント端末に対して、“０９０１２３４５６７８”と“ｈｉｔ−ｐａｓｓ”と“２０１３０１０１”がＫｅｙｗｏｒｄとして登録されている。

図１７は、ネットワーク装置４００ａがクライアント側インタフェース４５０を介してパケットを受信した際の処理フローチャートを示す。
パケットの受信（Ｓ０）、ＨＴＴＰの確認（Ｓ１）、ホワイトリスト（ＤＢ１）４３１の確認（Ｓ２）、ブラックリスト（ＤＢ２）４３２の確認（Ｓ３）の処理は、実施例１と同じであるため説明を省略する。パケットがＨＴＴＰであり（Ｓ１）、メッセージヘッダ７３２のホスト名がホワイトリスト４３１およびブラックリスト４３２に記憶されたホスト名のいずれかに該当しない場合（Ｓ２、Ｓ３）、ＣＰＵ４２０は、ＩＰヘッダ７１０の送信元ＩＰアドレス７１１が流出禁止キーワードリスト（ＤＢ５）４３６のクライアントアドレスに該当するかを確認する（Ｓ１７）。送信元ＩＰアドレス７１１が流出禁止キーワードリスト（ＤＢ５）４３６に該当しない場合は、ＣＰＵ４２０は、サーバ側インタフェース４６０からパケットをサーバ向けに転送する（Ｓ１０）。送信元ＩＰアドレス７１１が流出禁止キーワードリスト（ＤＢ５）４３６に該当する場合は、ＣＰＵ４２０は、実施例１と同様にＭｅｔｈｏｄによってチェックする領域を選択し、クライアントアドレスに対応するＫｅｙｗｏｒｄが選択した領域に含まれないかを確認する（Ｓ１８）。ＣＰＵ４２０は、Ｋｅｙｗｏｒｄが含まれる場合はパケットを廃棄し（Ｓ９）、含まれない場合はサーバ側インタフェース４６０からパケットをサーバ向けに転送する（Ｓ１０）。

３．実施の効果

本実施例によると、フィッシングサイトがＵＲＬを変更した場合、またブラックリストおよびホワイトリストが最新化されない場合でも、ユーザに負担をかけることなく、正規サイトへの重要情報を送信し、ＥＶＳＳＬが適用されていないフィッシングサイトに個人情報やＩＤ・パスワード等の重要情報を誤って送信することを防ぐことができる。

４．付記

実施例１および実施例２では、クライアント端末１００と正規サイトを有するサーバおよびフィッシングサイトを有するサーバの間に配置されるネットワーク装置４００、４００ａでの実施例を説明しているが、ネットワーク装置４００、４００ａのかわりにプロキシサーバでも同様に実施可能である。
さらに、ネットワーク装置４００、４００ａの処理をクライアント端末１００上で動作するソフトウェアで実施してもよい。
また、ネットワーク装置４００、４００ａの各処理内容、変更内容および処理結果の一部もしくはすべてはログ４３５に格納され、ログ４３５は保守インタフェース４７０を介して閲覧および取り出しを行うことができる。

また、以上の説明では主に、ｆｏｒｍタグやｎａｍｅを用いる場合について説明したが、これに限らず、適宜の情報を促すタグやデータに適用することができる。
Ｍｅｔｈｏｄによりチェック領域を定めたが、これに限らず適宜の情報によりチェック領域を定めるようにしてもよい。

なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれている。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。
また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（ＳｏｌｉｄＳｔａｔｅＤｒｉｖｅ）等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。
また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。

また、本発明のアクセス制御方法又はアクセス制御のための装置・システムは、その各手順をコンピュータに実行させるためのアクセス制御プログラム、アクセス制御プログラムを記録したコンピュータ読み取り可能な記録媒体、アクセス制御プログラムを含みコンピュータの内部メモリにロード可能なプログラム製品、そのプログラムを含むサーバ等のコンピュータ、等により提供されることができる。

１００クライアント端末
２００第１のネットワーク
３００第２のネットワーク
４００ネットワーク装置
４１０ＲＡＭ
４２０ＣＰＵ
４３０ストレージ
４５０クライアント側インタフェース
４６０サーバ側インタフェース
４７０保守インタフェース
５００正規サイトを有するサーバ
６００フィッシングサイトを有するサーバ
７００ＨＴＴＰパケット

Claims

ひとつ又は複数のアクセス許可サイトを予め記憶したホワイトリストと、
ひとつ又は複数のフィッシングサイトを予め記憶したブラックリストと、
サーバアドレス及び／又はクライアントアドレスと、特定情報又は流出禁止キーワードとを対応して記憶する特定リストと、
処理部と、
を備え、
前記処理部は、
クライアント端末からサーバに向けたリクエストが、前記ホワイトリストに該当する場合はアクセスを許可し、前記ブラックリストに該当する場合はアクセスを遮断し、
前記ホワイトリストおよび前記ブラックリストのいずれかにも該当しない場合は、
前記リクエストの宛先アドレス及び／又は送信元アドレスが前記特定リストに記録されたサーバアドレス及び／又はクライアントアドレスに該当するかを確認し、
該当した場合に、前記リクエストのパケット種別により前記リクエストの予め定められた領域に、前記特定リスト内に前記サーバアドレス及び／又はクライアントアドレスに対する特定情報又は流出禁止キーワードが含まれないかを確認し、含まれる場合は前記リクエストを廃棄し、含まれない場合は前記リクエストをサーバに向けて転送する
通信装置。
請求項１に記載の通信装置であって、
クライアント端末に特定情報のデータ送信を促すためのひとつ又は複数の入力指示項目を予め記憶した入力指示項目リスト
をさらに備え、
前記特定リストとして、サーバアドレスと、クライアントアドレスと、前記入力指示項目に対応した特定情報とを含むフィルタリングリストを備え、
前記処理部は、
前記ホワイトリストおよび前記ブラックリストのいずれかにも該当しない場合は、
サーバからクライアント端末に向けたレスポンスを受信した場合に、前記レスポンスに、前記入力指示項目リストに記憶された入力指示項目が含まれるかを確認し、含まれる場合は、サーバアドレスと、クライアントアドレスと、前記入力指示項目に対応した特定情報とを前記フィルタリングリストに記録し、

前記ホワイトリストおよび前記ブラックリストのいずれかにも該当しない場合は、
前記処理部は、
クライアント端末からサーバに向けたリクエストを受信した場合に、前記リクエストの宛先アドレスと送信元アドレスの組み合わせが前記フィルタリングリストに記録されたサーバアドレスとクライアントアドレスの組み合わせに該当するかを確認し、
該当した場合に、前記リクエストのデータ種別により前記リクエストの予め定められた領域に、前記フィルタリングリスト内に前記組み合わせに対する特定情報が含まれないかを確認し、含まれる場合は前記リクエストを廃棄し、含まれない場合は前記リクエストをサーバに向けて転送する
ことを特徴とする通信装置。
請求項２に記載の通信装置であって、
前記処理部は、
サーバからクライアント端末に向けたレスポンスを受信すると、
前記レスポンスに、情報入力を促すタグが含まれるかを確認し、
含まれる場合には情報入力を促すタグが前記入力指示項目リスト内に含まれるかを確認し、
含まれる場合、前記レスポンスの送信元アドレス、宛先アドレス、情報入力を促すタグに記述されるキーワードを、前記フィルタリングリストのサーバアドレス、クライアントアドレス、特定情報にそれぞれ記録し、
前記記録後、前記レスポンスをクライアント端末に向けて転送する
ことを特徴とする通信装置。
請求項３に記載の通信装置であって、
前記情報入力を促すタグは、ｆｏｒｍタグであることを特徴とする通信装置。
請求項２に記載の通信装置であって、
前記特定情報は、ｈｔｍｌのｎａｍｅであることを特徴とする通信装置。
請求項２に記載の通信装置であって、
前記処理部は、前記入力指示項目リストに含まれる情報入力が複数ある場合は、前記フィルタリングリストに該当する複数データを記録することを特徴とする通信装置。
請求項２に記載の通信装置であって、
前記処理部は、前記リクエストがＨＴＴＰパケットでない場合、前記リクエストをサーバに向けて転送することを特徴とする通信装置。
請求項２に記載の通信装置であって、
前記処理部は、前記レスポンスがＨＴＴＰパケットでない場合、前記レスポンスをクライアント端末に向けて転送することを特徴とする通信装置。
請求項１に記載の通信装置であって、
前記特定リストとして、クライアントアドレスと流出禁止キーワードとが予め登録された流出禁止キーワードリストを備え、
前記処理部は、
前記ホワイトリストおよび前記ブラックリストのいずれかにも該当しない場合は、
前記リクエストに含まれるクライアントアドレスが前記流出禁止キーワードリストに該当するかを確認し、
該当する場合は、前記リクエストのデータ種別により前記リクエストの予め定められた領域に、前記流出禁止キーワードリスト内にクライアントアドレスに対応した流出禁止キーワードが含まれるかを確認し、含まれる場合は前記リクエストを廃棄し、含まれない場合は前記リクエストをサーバに向けて転送する
ことを特徴とする通信装置。
請求項９に記載の通信装置であって、
前記処理部は、前記リクエストがＨＴＴＰパケットでない場合、前記リクエストをサーバに向けて転送することを特徴とする通信装置。
請求項１に記載の通信装置であって、
前記データ種別は、Ｍｅｔｈｏｄであることを特徴とする通信装置。
請求項１に記載の通信装置であって、
サーバから送信される前記レスポンスは、クライアント端末にデータ入力を促すｆｏｒｍタグが含まれるメッセージボディを含むことを特徴とする通信装置。
請求項１に記載の通信装置であって、
前記レスポンスと受信したクライアント端末に、特定情報である“ＩＤ”と“ＰＡＳＳＷＯＲＤ”を入力するためのブラウザを表示し、クライアント端末から“ＩＤ”と“ＰＡＳＳＷＯＲＤ”が入力され、確認ボタンが押されると、前記処理部は、入力された特定情報を含むリクエストを受信することを特徴とする通信装置。
請求項１に記載の通信装置であって、
前記データ種別はｐｏｓｔ又はｇｅｔであることを特徴とする通信装置。
請求項１４に記載の通信装置であって、
前記処理部は、該当する場合は、前記リクエストのリクエスト行のＭｅｔｈｏｄがｇｅｔなのかｐｏｓｔなのかを確認し、ｇｅｔの場合はリクエスト行のＵＲＩをチェックし、ｐｏｓｔの場合はメッセージボディをチェックすることを特徴とする通信装置。
請求項１に記載の通信装置であって、
前記リクエストは、
送信元ＩＰアドレスと宛先ＩＰアドレスが含まれるＩＰヘッダと、
ＨＴＴＰデータと
を含み、
前記ＨＴＴＰデータは、
Ｍｅｔｈｏｄ、ＵＲＩ（ＵｎｉｆｏｒｍＲｅｓｏｕｒｃｅＩｄｅｎｔｉｆｉｅｒ）を含むリクエスト行と、
要求先サーバのＨｏｓｔ名が含まれるメッセージヘッダと、
メッセージボディと
を含むことを特徴とする通信装置。
請求項２に記載の通信装置であって、
前記ホワイトリスト、前記ブラックリスト、前記入力指示項目リストのいずれかひとつ又は複数を、保守インタフェースを介して変更可能なことを特徴とする通信装置。
請求項２に記載の通信装置であって、
前記処理部は、前記ホワイトリスト、前記ブラックリスト、前記入力指示項目リスト、前記フィルタリングリストのいずれかひとつ又は複数の変更内容をログとして保存し、保守インタフェースを介してログを出力することを特徴とする通信装置。
通信装置におけるアクセス制御方法であって、
前記通信装置は、
ひとつ又は複数のアクセス許可サイトを予め記憶したホワイトリストと、
ひとつ又は複数のフィッシングサイトを予め記憶したブラックリストと、
サーバアドレス及び／又はクライアントアドレスと、特定情報又は流出禁止キーワードとを対応して記憶する特定リストと、
処理部と、
を備え、
前記処理部は、
クライアント端末からサーバに向けたリクエストが、前記ホワイトリストに該当する場合はアクセスを許可し、前記ブラックリストに該当する場合はアクセスを遮断し、
前記ホワイトリストおよび前記ブラックリストのいずれかにも該当しない場合は、
前記リクエストの宛先アドレス及び／又は送信元アドレスが前記特定リストに記録されたサーバアドレス及び／又はクライアントアドレスに該当するかを確認し、
該当した場合に、前記リクエストのパケット種別により前記リクエストの予め定められた領域に、前記特定リスト内に前記サーバアドレス及び／又はクライアントアドレスに対する特定情報又は流出禁止キーワードが含まれないかを確認し、含まれる場合は前記リクエストを廃棄し、含まれない場合は前記リクエストをサーバに向けて転送する
アクセス制御方法。
通信装置におけるアクセス制御プログラムであって、
前記通信装置は、
ひとつ又は複数のアクセス許可サイトを予め記憶したホワイトリストと、
ひとつ又は複数のフィッシングサイトを予め記憶したブラックリストと、
サーバアドレス及び／又はクライアントアドレスと、特定情報又は流出禁止キーワードとを対応して記憶する特定リストと、
処理部と、
を備え、
前記処理部が、クライアント端末からサーバに向けたリクエストが、前記ホワイトリストに該当する場合はアクセスを許可し、前記ブラックリストに該当する場合はアクセスを遮断する手順と、
前記ホワイトリストおよび前記ブラックリストのいずれかにも該当しない場合は、
前記処理部が、前記リクエストの宛先アドレス及び／又は送信元アドレスが前記特定リストに記録されたサーバアドレス及び／又はクライアントアドレスに該当するかを確認する手順と、
前記処理部が、該当した場合に、前記リクエストのパケット種別により前記リクエストの予め定められた領域に、前記特定リスト内に前記サーバアドレス及び／又はクライアントアドレスに対する特定情報又は流出禁止キーワードが含まれないかを確認し、含まれる場合は前記リクエストを廃棄し、含まれない場合は前記リクエストをサーバに向けて転送する手順と
をコンピュータに実行させるためのアクセス制御プログラム。