(57)【要約】【課題】コンテンツに対する情報通信の要求に関する情報（例えばＵＲＬ）から、該コンテンツへの情報通信の安全性を判定する場合よりも、正確にコンテンツへの情報通信の安全性を判定する。【解決手段】信頼度ＤＢ１１２にはリクエストとこれに対するレスポンスのダイジェスト値であるリクエストＩＤとレスポンスＩＤのペア毎にエントリが作成される。エントリには、そのペアに該当する通信の回数と、そのレスポンスについてのウイルスチェック結果とが記憶される。レスポンスＩＤ計算部１１０は、ユーザ端末のリクエストに対するサーバからのレスポンスのレスポンスＩＤを計算する。信頼度簡易判定部１０６は、そのレスポンスＩＤに対応するエントリが信頼度ＤＢ１１２内にある場合、そのエントリ内のウイルスチェック結果がウイルス無しであれば、そのレスポンスをユーザ端末に中継し、ウイルス有りであればそのレスポンスを遮断する。【選択図】図２
2017046310.tif 000002
【特許請求の範囲】
【請求項１】
第１の情報処理装置による情報通信の要求を受信する第１の受信手段と、
前記要求に対する第２の情報処理装置からの情報通信の応答を受信する第２の受信手段と、
前記要求と、前記応答と、前記要求に対するウイルスチェック結果が対応づけられた要求応答情報を記憶する記憶手段と、
前記記憶手段に記憶されている前記要求応答情報に基づいて、前記受信手段が受信した情報通信の要求を拒否または許可する制御を行う制御手段と、
を含む情報処理装置。
【請求項２】
前記制御手段は、前記第１の受信手段が受信した前記要求と前記第２の受信手段が受信した前記応答が、前記記憶手段に記憶されていた場合、前記要求と前記応答に対応づけられたウイルスチェック結果に応じて、前記第１の受信手段が受信した前記情報通信の要求を拒否または許可する制御を行うことを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記制御手段は、前記受信手段が受信した前記要求と前記第２の受信手段が受信した前記応答が前記記憶手段に記憶されていなかった場合、前記第１の受信手段が受信した前記要求に対してウイルスチェックを実行させ、これによって得たウイルス結果に応じて前記受信手段が受信した前記要求を許可または拒否するする制御を行うことを特徴とする請求項１に記載の情報処理装置。
【請求項４】
前記記憶手段は、前記要求と前記応答の通信回数を、前記要求と前記応答にさらに対応づけて記憶し、
前記制御手段は、前記要求と前記応答が前記記憶手段に記憶されており、前記通信回数があらかじめ定めた閾値以上である場合に、前記要求と前記応答に対応づけられて記憶された前記ウイルスチェック結果に応じて、前記要求を許可または拒否する制御を行うことを特徴とする請求項１に記載の情報処理装置。
【請求項５】
前記記憶手段は、前記ウイルスチェック結果の最終更新時刻を更に記憶し、
前記情報処理装置は、
前記記憶手段内に前記最終更新時刻からあらかじめ定めた判定期間が経過した前記要求と前記応答がある場合に、前記要求について前記ウイルスチェックを実行させ、得られたウイルスチェック結果を、前記記憶手段内の前記要求と前記応答に対して更新する、
ことを特徴とする請求項２又は３に記載の情報処理装置。
【請求項６】
コンピュータを、
第１の情報処理装置による情報通信の要求を受信する第１の受信手段、
前記要求に対する第２の情報処理装置からの情報通信の応答を受信する第２の受信手段、
前記要求と、前記応答と、前記要求に対するウイルスチェック結果が対応づけられた要求応答情報を記憶する記憶手段、
前記記憶手段に記憶されている前記要求応答情報に基づいて、前記受信手段が受信した情報通信の要求を拒否または許可する制御を行う制御手段、
として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置及びプログラムに関する。
【背景技術】
【０００２】
コンピュータウイルスのチェック技術として、例えば特許文献１に開示されるものがある。この従来技術では、一度ウイルスチェックを実施したファイルに対して、その時に使用したウイルスチェック手段およびウイルス定義ファイルの情報を添付し、次回のウイルスチェック時に同じウイルスチェック手段およびウイルス定義ファイルを使用しているか否か判断して、ウイルスチェックの実行が必要か否かを決定する。さらに、コンピュータウイルスのパターンを含む数により、複数のウイルス定義ファイルを用意して、ウイルスチェックする際に最適なウイルス定義ファイルを選択する。この従来技術では、ウイルスチェック手段及びウイルス定義ファイルが変化しない間は、ウイルスチェックが省略される。
【０００３】
また、特許文献２に開示される方法では、ゲートウェイ機器がユーザ端末からインターネットサーバへ送信された要求メッセージをインターセプトしてその要求メッセージからＵｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ（ＵＲＬ）情報を抽出し、ＵＲＬ情報に従ってＵＲＬに対応するセキュリティ水準を判定する。そして、判定したセキュリティ水準に従って、要求パケットに対して破棄、警告等のフィルタリング処理を実行する。セキュリティ水準は、クラウドやローカル上のデータベースに問い合わせる。データベースは、定期的にサーバと通信することで更新される。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１２−５２２２９５号公報
【特許文献２】特開２００７−２００１０２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
コンテンツにアクセスし、該コンテンツを閲覧等する際、該コンテンツの安全性を確かめてから該コンテンツへのアクセスを許可する技術として、一般的に、コンテンツに対して情報通信の要求を行い、情報通信の要求を受けたコンテンツにウイルスがあるか否かをチェックし、該情報通信の要求に応じた応答を行った上で、該コンテンツへの情報通信の要求を許可または拒否する技術がある。しかし、過去に情報通信を要求したことがあるコンテンツに対しても、毎回ウイルスチェックを行ってしまうと、コンテンツへの情報通信に時間がかかってしまい、情報通信の効率性が悪かった。
コンテンツには、静的コンテンツと動的コンテンツがある。静的コンテンツは、該コンテンツへの情報通信の要求に依存しないコンテンツであるため、静的コンテツに対して情報通信の要求をした場合、該情報通信の要求と該情報通信の要求に対応する応答は一対一対応になる。これに対して従来技術としては、コンテンツに対する情報通信の要求と該コンテンツへのウイルスチェック結果を対応づけて記憶しておき、該コンテンツに対する情報通信の要求があった場合、対応づけられて記憶されたウイルスチェックに応じて、該コンテンツに対する情報通信の要求を許可または拒否する制御を行う技術がある。しかし静的コンテンツと異なって、動的コンテンツは該コンテンツへの情報通信の要求がある度に生成されるコンテンツであるため、動的コンテンツに対して情報通信の要求をした場合、該情報通信の要求と該情報通信に対応する応答が一対一対応とならない場合がある。このような場合では、同じコンテンツに対する情報通信の要求に対して、ある場合には該コンテンツはウイルスを含まないという安全を示す応答が返り、別の場合には該コンテンツはウイルスを含むという危険を示す応答が返ってくることがある。
【０００６】
本発明は、コンテンツに対する情報通信の要求に関する情報（例えばＵＲＬ）から、該コンテンツへの情報通信の安全性を判定する場合よりも、正確にコンテンツへの情報通信の安全性を判定することを目的とする。
【課題を解決するための手段】
【０００７】
請求項１に係る発明は、第１の情報処理装置による情報通信の要求を受信する第１の受信手段と、前記要求に対する第２の情報処理装置からの情報通信の応答を受信する第２の受信手段と、前記要求と、前記応答と、前記要求に対するウイルスチェック結果が対応づけられた要求応答情報を記憶する記憶手段と、前記記憶手段に記憶されている前記要求応答情報に基づいて、前記受信手段が受信した情報通信の要求を拒否または許可する制御を行う制御手段と、を含む情報処理装置である。
【０００８】
請求項２に係る発明は、前記制御手段は、前記第１の受信手段が受信した前記要求と前記第２の受信手段が受信した前記応答が、前記記憶手段に記憶されていた場合、前記要求と前記応答に対応づけられたウイルスチェック結果に応じて、前記第１の受信手段が受信した前記情報通信の要求を拒否または許可する制御を行うことを特徴とする請求項１に記載の情報処理装置である。
【０００９】
請求項３に係る発明は、前記制御手段は、前記受信手段が受信した前記要求と前記第２の受信手段が受信した前記応答が前記記憶手段に記憶されていなかった場合、前記第１の受信手段が受信した前記要求に対してウイルスチェックを実行させ、これによって得たウイルス結果に応じて前記受信手段が受信した前記要求を許可または拒否するする制御を行うことを特徴とする請求項１に記載の情報処理装置である。
【００１０】
請求項４に係る発明は、前記記憶手段は、前記要求と前記応答の通信回数を、前記要求と前記応答にさらに対応づけて記憶し、前記制御手段は、前記要求と前記応答が前記記憶手段に記憶されており、前記通信回数があらかじめ定めた閾値以上である場合に、前記要求と前記応答に対応づけられて記憶された前記ウイルスチェック結果に応じて、前記要求を許可または拒否する制御を行うことを特徴とする請求項１に記載の情報処理装置である。
【００１１】
請求項５に係る発明は、前記記憶手段は、前記ウイルスチェック結果の最終更新時刻を更に記憶し、前記情報処理装置は、前記記憶手段内に前記最終更新時刻からあらかじめ定めた判定期間が経過した前記要求と前記応答がある場合に、前記要求について前記ウイルスチェックを実行させ、得られたウイルスチェック結果を、前記記憶手段内の前記要求と前記応答に対して更新する、ことを特徴とする請求項２又は３に記載の情報処理装置である。
【００１２】
請求項６に係る発明は、コンピュータを、第１の情報処理装置による情報通信の要求を受信する第１の受信手段、前記要求に対する第２の情報処理装置からの情報通信の応答を受信する第２の受信手段、前記要求と、前記応答と、前記要求に対するウイルスチェック結果が対応づけられた要求応答情報を記憶する記憶手段、前記記憶手段に記憶されている前記要求応答情報に基づいて、前記受信手段が受信した情報通信の要求を拒否または許可する制御を行う制御手段、として機能させるためのプログラムである。
【発明の効果】
【００１３】
請求項１〜３又は６に係る発明によれば、コンテンツに対する情報通信の要求に関する情報（例えばＵＲＬ）から、該コンテンツへの情報通信の安全性を判定する場合よりも、正確にコンテンツへの情報通信の安全性を判定することができる。
【００１４】
請求項４に係る発明によれば、要求と応答の通信回数が、信頼に足る十分な回数（閾値）以上である場合に、その要求と応答に対応付けられたウイルスチェック結果に応じて、要求の段階で許可又は拒否の制御を行うことができる。
【００１５】
請求項５に係る発明によれば、記憶手段内の情報の更新を行わない場合よりも、記憶手段内の情報に基づいてより正確な判定を行うことができる。
【図面の簡単な説明】
【００１６】
【図１】実施形態のシステム構成の例を示す図である。
【図２】実施形態のゲートウェイ装置の機能構成の例を示す図である。
【図３】信頼度ＤＢ（データベース）のデータ内容の例を示す図である。
【図４】リクエスト受信時の処理手順の例を示す図である。
【図５】リクエストＩＤに基づく信頼度判定処理の例を示す図である。
【図６】レスポンス受信時の処理手順の例を示す図である。
【図７】レスポンスＩＤに基づく信頼度判定処理の例を示す図である。
【図８】信頼度ＤＢの更新処理の例を示す図である。
【図９】第１の変形例における信頼度ＤＢのデータ内容の例を示す図である。
【図１０】第２の変形例における信頼度ＤＢのデータ内容の例を示す図である。
【図１１】第２のゲートウェイ装置の機能構成の例を示す図である。
【発明を実施するための形態】
【００１７】
本実施形態の制御は、ローカルネットワーク２５０とインターネット３５０との間の通信を中継するゲートウェイ装置１００で実行される。ローカルネットワーク２５０は、例えば、ローカルエリアネットワークやイントラネット等である。例えば、ゲートウェイ装置１００は、ローカルネットワーク２５０上のユーザ端末２００からの、サーバ３００宛のリクエストをインターネット３５０へと中継する。インターネット３５０に送出されたそのリクエストは、宛先であるサーバ３００に伝達される。またゲートウェイ装置１００は、そのリクエストに対するサーバ３００からのレスポンスをインターネット３５０経由で受け取り、ユーザ端末２００へと転送する。なお、これに限定されるものではないが、ユーザ端末２００は例えばパーソナルコンピュータであり、サーバ３００はウェブサーバである。図では、ユーザ端末２００及びサーバ３００を１つずつしか示さなかったが、ローカルネットワーク２５０上にはユーザ端末２００は複数存在し、それらユーザ端末２００がインターネット３５０上の様々なサーバ３００にリクエストを送り、レスポンスを受け取る。
【００１８】
図２に、本実施形態のゲートウェイ装置１００の機能的な構成の例を示す。
【００１９】
図示のゲートウェイ装置１００において、送受信部１０２は、ローカルネットワーク２５０との間でデータ（例えばパケット）の送受信を行う。例えば、送受信部１０２は、ユーザ端末２００からサーバ３００へのリクエストをローカルネットワーク２５０から受信する。受信されたリクエストのデータは、リクエストＩＤ計算部１０４に渡される。また、送受信部１０２は、そのリクエストに対するサーバ３００からのレスポンスを、ローカルネットワーク２５０を介してユーザ端末２００に送信する。
【００２０】
リクエストＩＤ計算部１０４は、ユーザ端末２００からのサーバ３００宛のリクエストのリクエストＩＤ（識別情報）を計算する。リクエストＩＤは、リクエスト毎に事実上ユニーク（一意）な識別情報であり、本実施形態ではそのリクエストＩＤをリクエストのデータ自体から計算で求める。一例として、この実施形態では、リクエストの特定の一部、又は全部、のダイジェスト値（ハッシュ値）を、そのリクエストのＩＤとする。ダイジェスト値は、ＭＤ５やＳＨＡ−１等の公知のハッシュ関数を用いて計算すればよい。
【００２１】
ＨＴＴＰ（Hypertexet Transfer Protocol）のリクエストの場合、例えばリクエストのヘッダに含まれるＵＲＬとＵｓｅｒ−Ａｇｅｎｔ値とＣｏｏｋｉｅの組み合わせを「特定の一部」とし、そのダイジェスト値をリクエストＩＤとしてもよい。ＵＲＬが同じでも、Ｕｓｅｒ−Ａｇｅｎｔ値やＣｏｏｋｉｅが異なると、リクエストに対するレスポンスの内容が変わってくるので、リクエストをＵＲＬで識別するだけでは、リクエストに対するレスポンスの内容が絞りきれない。これに対し、ＵＲＬとＵｓｅｒ−Ａｇｅｎｔ値とＣｏｏｋｉｅの組み合わせから求めたリクエストＩＤを用いた場合、リクエストＩＤに対してレスポンス内容が一意に決まる可能性が高くなる。
【００２２】
また、リクエストのヘッダ全体をその「特定の一部」として用い、そのダイジェスト値を求めてもよい。ヘッダ全体から求めたリクエストＩＤを用いれば、ヘッダの一部の情報から求めたリクエストＩＤを用いる場合よりも、対応するレスポンスの内容が一意に決まる可能性が更に高い。
【００２３】
また、ヘッダに加えてボディも含めたリクエストの全部からリクエストＩＤを求めれば、レスポンスの内容が一意に決まる可能性が更に高くなる。
【００２４】
なお、リクエストのヘッダのうち、送信日時等のように、リクエスト毎に変わり、かつレスポンスの内容に影響を与えない項目については、リクエストＩＤを計算する元データ（例えばヘッダ）から削除しておく。
【００２５】
信頼度簡易判定部１０６は、ユーザ端末２００からのリクエストに対して、サーバ３００から返されるレスポンスのコンテンツの信頼度（すなわち安全度）を簡易的に判定する。「簡易的に判定する」とは、レスポンスのコンテンツに対してウイルスチェックを行わず、信頼度ＤＢ１１２（データベース）に保持されている過去のチェック実績の情報の参照で判定することである。信頼度簡易判定部１０６は、上述したリクエストＩＤ又は後述するレスポンスＩＤをキーとして信頼度ＤＢ１１２を検索し、検索の結果により、レスポンスの信頼度を判定する。信頼度簡易判定部１０６における判定手法については、後で詳しく説明する。
【００２６】
送受信部１０８は、インターネット３５０との間でデータの送受信を行う。例えば、送受信部１０８は、信頼度簡易判定部１０６を通過したユーザ端末２００からのリクエストを、インターネット３５０を介してサーバ３００へ送信する。また、送受信部１０８は、そのリクエストに対するサーバ３００からのレスポンスをインターネット３５０から受信する。受信されたレスポンスのデータは、レスポンスＩＤ計算部１１０に渡される。
【００２７】
レスポンスＩＤ計算部１１０は、サーバ３００からのレスポンスのレスポンスＩＤを計算する。レスポンスＩＤは、レスポンスの事実上ユニークな識別情報であり、本実施形態ではそのレスポンスのデータ内容から計算で求める。１つの例では、リクエストＩＤと同様、レスポンスのデータのダイジェスト値をレスポンスＩＤとする。レスポンスＩＤは、レスポンスのデータ全体、又はレスポンスのうちボディを含む一部のデータから計算する。ウイルスはボディに含まれる可能性が高いからである。
【００２８】
信頼度ＤＢ１１２は、レスポンスの信頼度の簡易判定に用いる判定材料の情報を記憶するデータベースである。信頼度ＤＢ１１２には、サーバ３００群からの多くのレスポンスに対して信頼度精密判定部１１４で行ったウイルスチェックの結果が蓄積される。
【００２９】
図３に信頼度ＤＢ１１２に登録されているデータの例を示す。例示する信頼度ＤＢ１１２には、リクエストＩＤ、レスポンスＩＤ、通信回数、ウイルス有無の４つの項目からなるエントリが蓄積されている。すなわち１つのエントリは、リクエストＩＤとレスポンスＩＤの組合せについて、その組み合わせとなる通信（リクエストとこれに対するレスポンス）がユーザ端末２００群とサーバ３００との間で行われた回数（「通信回数」）と、そのレスポンスＩＤが示すレスポンスからウイルスが見つかったか否か（「ウイルス有無」）を示している。
【００３０】
図示例では、リクエストＩＤが「adk1dig3950...」であるエントリが２つある。これは、同じリクエストＩＤ「adk1dig3950...」に対して、レスポンスＩＤが「01d03kdvb88...」及び「d8920dkvob1...」である異なる２つのエントリが存在する。これは、リクエストＩＤ「adk1dig3950...」ではレスポンスは一意に特定されない（すなわちレスポンスが動的コンテンツである可能性がある）ことを示す。レスポンスＩＤが「01d03kdvb88...」であるレスポンスからはウイルスは見つからず、「d8920dkvob1...」であるレスポンスからはウイルスは見つかっている。そして、それら各レスポンスＩＤに対応する通信回数はそれぞれ１回である。ここから分かることは、リクエストＩＤが「adk1dig3950...」であるリクエストについては、ウイルスを含むレスポンス、含まないレスポンスのどちらが返ってくるか分からないということである。
【００３１】
一方、リクエストＩＤ「kf987q235r...」及び「mbjf890t04e...」についてはそれぞれエントリが１つしかなく、それらエントリの通信回数は１００回である。そして、前者はウイルスチェックの結果が１００回とも「ウイルス無し」であり、後者は１００回とも「ウイルス有り」である。このことは、それら２つのリクエストＩＤについては、対応するレスポンスがほぼ確実に一意に決まり、前者のレスポンスはほぼ確実にウイルスを含まず、後者はほぼ確実にウイルスを含むということを示す。
【００３２】
この例では１００回を閾値とし、同一のリクエストＩＤとなるリクエストについての通信回数が少なくともこの閾値に達するまでは、対応するレスポンスのレスポンスＩＤを調査する。そして、そのリクエストＩＤに対応するレスポンスＩＤが、調査開始からその閾値の回数以上続けて一致した場合、そのリクエストＩＤのリクエストに対するレスポンスは、コンテンツが動的に変化しない静的コンテンツであるとみなす。新たなリクエストのリクエストＩＤに対応するレスポンスが静的コンテンツであるとみなせる場合、そのレスポンスに対してウイルスチェックを行わなくても、信頼度ＤＢ１１２内のそのリクエストＩＤのエントリ（これは上述の通り唯一である）の「ウイルス有無」の値をそのまま適用できる。図３の例では、静的コンテンツであるとみなすための通信回数の閾値が、ウイルスがある場合もない場合も同じ値（図示例では１００回）であったが、それら２つの場合で閾値を異ならせてもよい。例えば、ウイルス無しの静的コンテンツ（「安全」）と判定するための閾値は、ウイルス有りの静的コンテンツ（「危険」）と判定するための閾値よりも大きい値としてもよい。
【００３３】
上述した信頼度簡易判定部１０６は、リクエストのリクエストＩＤに対応する信頼度ＤＢ１１２内のエントリを調べることで、そのリクエストＩＤに対応するレスポンスが静的コンテンツであるかどうかを判定する。そして、静的コンテンツである場合は、そのリクエストＩＤに対応する唯一のエントリ内の「ウイルス有無」の値を、そのリクエストに対するレスポンスのウイルス判定結果の予測値とする。信頼度簡易判定部１０６は、サーバ３００からのレスポンスがウイルスを含むかどうかを、信頼度ＤＢ１１２の情報から高い確度で推定できる場合（例えば、上述したリクエストに対するレスポンスが静的コンテンツであると見なせる場合）には、ウイルスチェックを省略する。そして、信頼度ＤＢ１１２の情報をもとにウイルスの有無を判定する。これに対し、レスポンスが静的コンテンツでないと予測される場合など特定の場合には、信頼度精密判定部１１４に、そのレスポンスについてのウイルスチェックを依頼する。
【００３４】
信頼度精密判定部１１４は、サーバ３００からのレスポンスのうち、信頼度簡易判定部１０６から依頼された特定のものに対してウイルスチェックを行う。すなわち信頼度の「精密判定」とは、レスポンスに対して実際にウイルスチェック処理を適用することで、そのレスポンスがウイルスを含んでいるか否か（及び含んでいるウイルスの種類）を判定することである。
【００３５】
信頼度更新部１１６は、信頼度精密判定部１１４によるウイルスチェックの結果を用いて、信頼度ＤＢ１１２内のデータを更新する。この更新の具体的な処理の例は後で説明する。
【００３６】
信頼度簡易判定部１０６又は信頼度精密判定部１１４でウイルス無しと判定されたレスポンスは、送受信部１０２を介して、リクエスト発信元のユーザ端末２００に送られる。
【００３７】
以上、実施形態のゲートウェイ装置１００の構成について説明した。次に、ゲートウェイ装置１００の処理手順の例を説明する。
【００３８】
図４は、ユーザ端末２００からサーバ３００宛のリクエストを受けたときのゲートウェイ装置１００の処理手順を示す。この手順では、まず送受信部１０２がリクエストを受信すると（Ｓ１０）、リクエストＩＤ計算部１０４が、そのリクエストのリクエストＩＤを計算する（Ｓ１２）。すなわち、そのリクエスト中の特定の情報（例えばヘッダの一部、ヘッダ全体、あるいはリクエスト全体）のダイジェスト値を計算し、計算したダイジェスト値をそのリクエストのリクエストＩＤとする。信頼度簡易判定部１０６は、そのリクエストＩＤをキーとして信頼度ＤＢ１１２を検索することで、そのリクエストに対応するサーバ３００からのレスポンスの信頼度を判定（予測）する（Ｓ１４）。信頼度の判定結果は、「安全」、「危険」、及び「未知」（判定不能）の３種類である。「安全」とはそのリクエストに対するレスポンスが高い確度で「ウイルス無し」といえる場合であり、「危険」とはそのリクエストに対するレスポンスが高い確度で「ウイルス有り」といえる場合である。また「未知」とは、そのリクエストに対するレスポンスが静的コンテンツでない場合や、静的コンテンツとみなすにはサンプルが足りない（すなわち通信回数が閾値未満）である場合である。信頼度簡易判定部１０６は、判定した信頼度が「安全」又は「未知」である場合、当該リクエストを通過させる（Ｓ１６）。リクエストを通過させた場合、信頼度簡易判定部１０６は、そのリクエストのリクエストＩＤを保持する。信頼度簡易判定部１０６を通過したリクエストは送受信部１０８を介してインターネット３５０へと送出され、宛先のサーバ３００へと送られる。一方、判定した信頼度が「危険」である場合、信頼度簡易判定部１０６は、当該リクエストをブロック（遮断）する（Ｓ１８）。この場合、そのリクエストは宛先のサーバ３００へは送られず、例えば破棄される。ユーザ端末２００からのリクエストをブロックした場合、ゲートウェイ装置１００は、そのユーザ端末２００に対して、「アクセス先のコンテンツは危険なので、アクセスを遮断しました」等のエラーメッセージを返してもよい。
【００３９】
図５は、Ｓ１４の信頼度簡易判定部１０６の処理の詳細な手順を示す。この手順では、まず信頼度簡易判定部１０６は、リクエストＩＤ計算部１０４が計算したリクエストＩＤを含むエントリが信頼度ＤＢ１１２内にあるかどうかを調べる（Ｓ１４２）。ない場合は、そのリクエストは初めてのものであり、これに対するレスポンスが安全か危険かは判断できない。この場合、そのリクエストに対応する信頼度を「未知」と判定する（Ｓ１５０）。
【００４０】
Ｓ１４２で、そのリクエストＩＤを含むエントリが信頼度ＤＢ１１２内にあれば、次に信頼度簡易判定部１０６は、そのようなエントリが１つだけか否（複数存在）かを判定する（Ｓ１４４）。複数存在する場合（判定結果がＮｏ）、そのリクエストに対しては複数の異なる内容のレスポンスが返ってくる可能性があり、そのいずれかにウイルスが含まれる可能性も考えられる。そこで、その場合には、そのリクエストの信頼度を「未知」と判定する（Ｓ１５０）。
【００４１】
Ｓ１４４でそのリクエストＩＤに対応するエントリが１つだけと判定した場合、信頼度簡易判定部１０６は、更にそのエントリ内の通信回数の値があらかじめ定められた閾値以上であるかどうかを判定する（Ｓ１４６）。この判定結果がＮｏの場合は、そのリクエストＩＤについてはまだ情報が不十分であり、その唯一のエントリの情報が十分に信頼できない。この場合には、そのリクエストの信頼度を「未知」と判定する（Ｓ１５０）。
【００４２】
Ｓ１４６の判定結果がＹｅｓの場合は、そのリクエストに対するレスポンスが一意に定まる（静的コンテンツである）可能性が十分に高いと過去の通信の実績から言えるので、信頼度ＤＢ１１２の情報から信頼度が判定できる。この場合、信頼度簡易判定部１０６は、そのリクエストＩＤに対応する唯一のエントリの「ウイルス有無」の値を調べる（Ｓ１４８）。そして、その値が「有り」の場合は、そのリクエストは「危険」と判定し（Ｓ１５２）、「無し」の場合はそのリクエストは「安全」と判定する（Ｓ１５４）。
【００４３】
次に図６を参照して、ユーザ端末２００からのリクエストに対するサーバ３００からのレスポンスをゲートウェイ装置１００が受信した際の処理手順を説明する。
【００４４】
送受信部１０８がサーバ３００からレスポンスを受信する（Ｓ２０）と、レスポンスＩＤ計算部１１０がそのレスポンスのデータのダイジェスト値を計算することで、レスポンスＩＤを求める（Ｓ２２）。信頼度簡易判定部１０６は、そのレスポンスＩＤをキーとして信頼度ＤＢ１１２を検索することで、そのレスポンスに対応するサーバ３００からのレスポンスの信頼度を判定（予測）する（Ｓ２４）。信頼度の判定結果は、リクエストの場合と同様、「安全」、「危険」、及び「未知」（判定不能）の３種類である。「安全」とはそのレスポンスが高い確度で「ウイルス無し」といえる場合であり、「危険」とはそのレスポンスが高い確度で「ウイルス有り」といえる場合である。また「未知」とは、そのレスポンスが信頼度簡易判定部１０６にとって初めて出会ったもの（すなわち信頼度ＤＢ１１２内にそのレスポンスのＩＤを含んだエントリがない）である場合である。信頼度簡易判定部１０６は、判定した信頼度が「安全」である場合、そのレスポンスを通過させる（Ｓ２６）。この場合、レスポンスは送受信部１０２を介してローカルネットワーク２５０へと送出され、宛先のユーザ端末２００へと送られる。一方、判定した信頼度が「危険」である場合、信頼度簡易判定部１０６は、当該レスポンスをブロック（遮断）する（Ｓ２８）。この場合、そのリクエストは宛先のユーザ端末２００へは送られず、例えば破棄される。ユーザ端末２００へのレスポンスをブロックした場合、ゲートウェイ装置１００は、そのユーザ端末２００に対して、「アクセス先のコンテンツは危険なので、アクセスを遮断しました」等のエラーメッセージを返してもよい。
【００４５】
Ｓ２４でレスポンスが「未知」であると判定した場合、信頼度簡易判定部１０６は、そのレスポンスを信頼度精密判定部１１４に渡し、ウイルスチェックを実行させる（Ｓ３０）。このウイルスチェックの結果、レスポンス中からウイルスが検知されると、信頼度更新部１１６がそのことを信頼度ＤＢ１１２に反映（Ｓ３６）したあと、そのレスポンスをブロックする（Ｓ３８）。この場合も、レスポンスの宛先のユーザ端末２００に対して、エラーメッセージを送ってもよい。また、ウイルスチェックでレスポンス中からウイルスが検知されなかった場合、信頼度更新部１１６がそのことを信頼度ＤＢ１１２に反映（Ｓ３４）したあと、そのレスポンスを通過させる（Ｓ２６）。通過したレスポンスは、送受信部１０２を介して、リクエスト発信元のユーザ端末２００に送られる。
【００４６】
図７は、Ｓ２４における信頼度簡易判定部１０６によるレスポンスの信頼度の簡易判定の手順を示す。この手順では、まず判定対象のレスポンスの元になったリクエストについての信頼度簡易判定部１０６の判定結果が「安全」であったか否（すなわち「未知」）であったかを判定する（Ｓ２４２）。判定結果が「安全」であった場合には、リクエストの段階で過去の実績から安全と判定されているので、この例ではレスポンスについて重ねて信頼度ＤＢ１１２を調べることはせず、自動的にそのレスポンスは「安全」と判定する（Ｓ２５０）。
【００４７】
Ｓ２４２の判定結果がＮｏ（すなわち対応するリクエストの信頼度は「未知」）の場合、信頼度簡易判定部１０６は、レスポンスＩＤ計算部１１０が計算したレスポンスＩＤを含むエントリが信頼度ＤＢ１１２内にあるかどうかを調べる（Ｓ２４４）。信頼度簡易判定部１０６は、そのレスポンスの元になったリクエストのＩＤを保持しているので、Ｓ２４では、信頼度ＤＢ１１２内のそのリクエストＩＤに対応するエントリの中から、そのレスポンスＩＤを含むものを探すようにしてもよい。
そのレスポンスＩＤを含むエントリが信頼度ＤＢ１１２内にない場合は、そのレスポンスは初めてのものであり、信頼度ＤＢ１１２の情報からは安全か危険かは判断できない。この場合、そのレスポンスに対応する信頼度を「未知」と判定する（Ｓ２５２）。この場合、そのレスポンスには信頼度精密判定部１１４でウイルスチェックが行われる。
【００４８】
Ｓ２４４で、そのレスポンスＩＤを含むエントリが信頼度ＤＢ１１２内にあれば、次に信頼度簡易判定部１０６は、そのエントリの「ウイルス有無」の値を調べる（Ｓ２４６）。ダイジェスト値を求めるのに用いるハッシュ関数を適切であれば、異なる内容のレスポンスについてのレスポンスＩＤ同士が同じになることは非常に稀なので、そのレスポンスＩＤを含むエントリは、信頼度ＤＢ１１２内にあるとしても高々１つである。そのエントリの「ウイルス有無」の値が「有り」の場合は、そのリクエストは「危険」と判定し（Ｓ２５４）、「無し」の場合はそのリクエストは「安全」と判定する（Ｓ２５２）。
【００４９】
図７の例では、Ｓ２４４で、レスポンスＩＤを含むエントリが信頼度ＤＢ１１２内にある場合には、「通信回数」の値によらず、そのエントリの「ウイルス有無」を信頼したが、これは一例に過ぎない。この代わりに、そのような場合に、更にそのエントリの「通信回数」が閾値（図３の例では１００回）に達しているかどうかを判定し、達している場合にのみそのエントリの「ウイルス有無」を信頼し、「安全」か「危険」かを判定する（Ｓ２４６）するようにしてもよい。この場合、「通信回数」が閾値に達していなければ、そのレスポンスの信頼度を「未知」とし、そのレスポンスにウイルスチェックがなされるようにする。
【００５０】
図７の手順では、リクエストについての判定（図４のＳ１４）の結果が安全である場合、レスポンスについての判定（Ｓ２４）を省略したが、リクエストが安全と判定した場合でもレスポンスについてＳ２４の判定を行うようにしてもよい。
【００５１】
図８を参照して、Ｓ３４及びＳ３６での信頼度ＤＢ１１２の更新処理について説明する。この処理では、信頼度更新部１１６は、信頼度ＤＢ１１２（図３参照）に新規エントリを作成し（Ｓ３４２）、その新規エントリに対して、Ｓ１６で保持していたリクエストＩＤ、Ｓ２２で計算したレスポンスＩＤ、Ｓ３０で行われたウイルスチェックの結果（「ウイルス有無」）を登録する（Ｓ３４４）。また、「通信回数」を「１」とする。Ｓ３４又はＳ３６に達するのは、そのリクエストＩＤとレスポンスＩＤの組を含んだエントリが信頼度ＤＢ１１２にない場合なので、このように新規エントリを作成するのである。
＜第１変形例＞
【００５２】
次に、第１の変形例について説明する。
【００５３】
この変形例では、図９に示すように、ウイルスチェックで求められたウイルスの種別も信頼度ＤＢ１１２に登録する。すなわち、信頼度精密判定部１１４でのウイルスチェックでは、レスポンスにウイルスが含まれるか否かだけでなく、含まれるウイルスの種別も検知される。この検知されたウイルス種別を、信頼度更新部１１６が信頼度ＤＢ１１２に登録すればよい。登録したウイルス種別の情報は、例えば次のように利用される。
【００５４】
ユーザ端末２００から受信したリクエストのＩＤに対応するエントリが信頼度ＤＢ１１２内に複数ある場合や、そのようなエントリが１つしかなくても通信回数が閾値に達していない場合には、リクエストだけでは危険性が判定できない（「未知」判定）となる。このため、リクエストはサーバ３００に送られ、サーバ３００からのレスポンスに対してウイルスチェックを行う可能性がある。そこで、信頼度簡易判定部１０６は、受信したリクエストのＩＤに対応するＳ１４（図４）の判定結果が「未知」であり、そのリクエストＩＤを含む１以上のエントリの中にウイルス「有り」のものがある場合には、そのエントリ中の「ウイルス種別」を信頼度精密判定部１１４に通知する。信頼度精密判定部１１４は、通知された「ウイルス種別」を検知するためのウイルス定義をあらかじめ先読みしておく。これにより、レスポンスが到来したときには、先読みしたウイルス定義を用いて素早くそのウイルス種別の有無を判定する。
【００５５】
また別の利用例として、信頼度精密判定部１１４は、受信したリクエストのＩＤに対応する信頼度ＤＢ１１２内のエントリの中に「ウイルス種別」の値（例えば「W32Fbound」というウイルス名）を含むものがある場合は、その「ウイルス種別」の値を含んだ警告をリクエスト元のユーザ端末２００に通知する。そして、ユーザに対して、そのリクエストについての処置を、例えばリクエストを取りやめる、続行する（レスポンスからウイルスが検知された場合は取りやめる）、ウイルスがあってもレスポンスを受信する、等の選択肢から選択させる。
＜第２変形例＞
【００５６】
上記実施形態では、信頼度ＤＢ１１２に登録された情報に特に使用期限を設けていなかった。また、それら登録情報は、ユーザ端末２００からサーバ３００への実際のリクエストを用いて作成していた。
【００５７】
これに対して、本実施形態では、時間の経過に伴ってサーバ３００がウイルス感染する可能性があることも考慮し、信頼度ＤＢ１１２内の登録情報（各エントリ）に対して使用期限（すなわちそのエントリがいつまで信頼できるかを示す期限）を設ける。そして、その期限が過ぎると、再度当該エントリに対応するリクエストをサーバ３００に送り、それに対するレスポンスに対してウイルスチェックを行い、そのエントリの情報を更新する。
【００５８】
このために、この変形例では、図１０に示すように、信頼度ＤＢ１１２の各エントリに対して、「ウイルスチェック最終更新時刻」と「リクエスト再現情報」とを記録する。
【００５９】
「ウイルスチェック最終更新時刻」は、そのエントリについて最後にウイルスチェックを行った時刻である。ここでは一例として、この最終更新時刻にあらかじめ定めた長さの判定期間（例えば１日、又は１週間など）を加えた時刻を、そのエントリの情報の使用期限とする。
例えば、エントリの「通信回数」が閾値に達するまでは、そのエントリに対応するレスポンスが来る毎に信頼度精密判定部１１４によりウイルスチェックが行われ、そのレスポンスに対応するエントリの「ウイルスチェック最終更新時刻」が更新される。また、「通信回数」が閾値に達しているエントリについては、そのエントリのレスポンスＩＤが示すレスポンスについて最後にウイルスチェックを行った日時が「ウイルスチェック最終更新時刻」が記録されて入る。そして、それ以降そのエントリの使用期限が来るまでは、そのエントリに該当するレスポンスについてはウイルスチェックがなされない。
【００６０】
「リクエスト再現情報」は、過去にユーザ端末２００からサーバ３００に実際に送られたリクエストを再現できる情報であり、例えばそのリクエストのヘッダ（図示例ではＨＴＴＰヘッダ）をダンプした情報である。もちろんヘッダだけでなく、ボディを含むリクエスト全体のダンプを「リクエスト再現情報」として記録してもよい。例えばリクエストＩＤを、リクエストのヘッダのうちの一部の項目（例えばＵＲＬとＵｓｅｒ−Ａｇｅｎｔ値とＣｏｏｋｉｅの組）のみから計算している場合、リクエストＩＤが同じでも、ヘッダ全体（あるいはリクエスト全体）が異なる複数のリクエストが存在し得る。「リクエスト再現情報」には、そのようなリクエストＩＤ（及びレスポンスＩＤ）を共通とするそれら異なる複数のリクエストについての情報を記録しておく。
【００６１】
この「リクエスト再現情報」は、信頼度ＤＢ１１２のエントリの使用期限が過ぎた場合に、そのエントリの更新のためにゲートウェイ装置１００からサーバ３００に送るリクエストとして用いる。すなわち、この変形例では、信頼度ＤＢ１１２のエントリの更新時には、ユーザ端末２００から実際にリクエストが来るのを待たず、ゲートウェイ装置１００が「リクエスト再現情報」に記録したリクエスト群をサーバ３００に送ることで、情報収集を行う。このエントリの更新処理は、ゲートウェイ装置１００の処理負荷が低い時間帯（例えば夜間や休日など）に実行する。
【００６２】
図１１に、この変形例のゲートウェイ装置１００の構成を示す。図１１に示すゲートウェイ装置１００は、図２に示した要素群の他に更新部１１８を備える。信頼度更新部１１６は、受信したレスポンスに対して信頼度精密判定部１１４がウイルスチェックを行う都度、信頼度ＤＢ１１２内のそのレスポンスに対応するエントリの「ウイルスチェック最終更新時刻」を記録又は更新する。更新部１１８は、バックグラウンドで、信頼度ＤＢ１１２内の各エントリの「ウイルスチェック最終更新時刻」を例えば定期的（例えば処理負荷が低い時間帯が到来する毎に）に監視し、「ウイルスチェック最終更新時刻」からあらかじめ定めた判定期間を過ぎているエントリがないか確認する。そして、そのようなエントリがあれば、信頼度簡易判定部１０６等がユーザ端末２００からのリクエストやそれに対するレスポンスを処理している間に、バックグラウンドで、そのエントリの更新情報の収集を行う。この更新情報の収集処理では、更新部１１８は、そのエントリに含まれる「リクエスト再現情報」を用いて様々なリクエストを再現し、サーバ３００に送信する。そしてサーバ３００からのレスポンスに対して信頼度精密判定部１１４にウイルスチェックを行わせ、その結果を記録する。記録する情報項目は、信頼度ＤＢ１１２（図１０参照。ただし「リクエスト再現情報」は不要）と同じである。このとき行う処理は、上記実施形態における信頼度精密判定部１１４及び信頼度更新部１１６の処理と同じである（信頼度簡易判定部１０６の処理は、情報収集の目的から外れるので、行わない）。
【００６３】
「リクエスト再現情報」に記憶されている情報のバリエーションが十分であれば、エントリの「通信回数」が閾値に達するまで再現リクエスト群を繰り返しサーバ３００に送り、返されてくるレスポンス群をウイルスチェックし、チェック結果を記録していくことで、そのエントリが静的コンテンツであるかどうかを確認してもよい。「リクエスト再現情報」に記憶されている情報のバリエーションが少ない場合は、それらバリエーションの範囲内で可能なリクエストを再現し、サーバ３００に送って情報を収集する。そして、この更新処理の中で生成されるエントリの「通信回数」が閾値に達するか、「リクエスト再現情報」のバリエーションの範囲内で作成可能全てのリクエストについての情報（対応するレスポンスのウイルスチェック結果）の収集が終わると、情報収集を終了する。そして、その終了時点で生成されているエントリの情報を、信頼度ＤＢ１１２内の、対応する古いエントリの情報と置き換える。これにより、信頼度ＤＢ１１２内の各エントリの情報が、サーバ３００の最新の状態を反映した形に更新される。
【００６４】
以上に例示したゲートウェイ装置１００は、内蔵されるコンピュータにそれら各装置の機能を表すプログラムを実行させることにより実現される。ここで、コンピュータは、例えば、ハードウエアとして、ＣＰＵ等のマイクロプロセッサ、ランダムアクセスメモリ（ＲＡＭ）およびリードオンリメモリ（ＲＯＭ）等のメモリ（一次記憶）、ＨＤＤ（ハードディスクドライブ）を制御するＨＤＤコントローラ、各種Ｉ／Ｏ（入出力）インタフェース、ローカルエリアネットワークなどのネットワークとの接続のための制御を行うネットワークインタフェース等が、たとえばバスを介して接続された回路構成を有する。また、そのバスに対し、例えばＩ／Ｏインタフェース経由で、ＣＤやＤＶＤなどの可搬型ディスク記録媒体に対する読み取り及び／又は書き込みのためのディスクドライブ、フラッシュメモリなどの各種規格の可搬型の不揮発性記録媒体に対する読み取り及び／又は書き込みのためのメモリリーダライタ、などが接続されてもよい。上に例示した各機能モジュールの処理内容が記述されたプログラムがＣＤやＤＶＤ等の記録媒体を経由して、又はネットワーク等の通信手段経由で、ハードディスクドライブ等の固定記憶装置に保存され、コンピュータにインストールされる。固定記憶装置に記憶されたプログラムがＲＡＭに読み出されＣＰＵ等のマイクロプロセッサにより実行されることにより、上に例示した機能モジュール群が実現される。
【符号の説明】
【００６５】
１００  ゲートウェイ装置、１０２  送受信部、１０４  リクエストＩＤ計算部、１０６  信頼度簡易判定部、１０８  送受信部、１１０  レスポンスＩＤ計算部、１１２  信頼度ＤＢ（データベース）、１１４  信頼度精密判定部、１１６  信頼度更新部、１１８  更新部、２００  ユーザ端末、２５０  ローカルネットワーク、３００  サーバ、３５０  インターネット。
【図１】
2017046310.tif 000003
【図２】
2017046310.tif 000004
【図３】
2017046310.tif 000005
【図４】
2017046310.tif 000006
【図５】
2017046310.tif 000007
【図６】
2017046310.tif 000008
【図７】
2017046310.tif 000009
【図８】
2017046310.tif 000010
【図９】
2017046310.tif 000011
【図１０】
2017046310.tif 000012
【図１１】
2017046310.tif 000013