JP6529033B2 - 情報処理装置、方法およびプログラム - Google Patents

Description

本開示は、ネットワーク上でデータを検査するための技術に関する。

従来、データパケットの境界で分割されたパターンを検索するためにコンピュータネットワーク上でデータパケットストリームを検査するための方法として、２つ以上のデータパケットがデータパケットストリームにおいて連続するか否かを判断し、連続するデータパケットからのペイロードを結合し、連続するデータパケットからの結合したペイロードを解析し、文字の組み合わせからなる複数のパターンを検索する方法、および、データパケットが所定時間以上システム中にあるときに、所定の判断基準に基づきデータパケットを出力データストリームに戻す方法、が提案されている（特許文献１を参照）。

また、従来、インターネットへ接続する複数の加入者端末を収容するグループセンター局に接続されているゾーンセンター局内に、各加入者端末のユーザーＩＤ毎に、インターネットとの間で転送されるパケットデータを一時記憶する記憶装置と、記憶装置に記憶された複数のパケットデータをインターネット内のＩＰアドレスとネットワーク内の地域ＩＰアドレスに対応させてファイルデータに組み立てて、組み立てたデータ内にコンピュータウイルスが存在するか否かを判定し、コンピュータウイルスが存在しないと判定したデータを加入者端末へ転送する機能とを備えるゲートウェイが提案されている（特許文献２を参照）。

特表２００９−５１０８１５号公報 特開２００１−２５６０４５号公報

従来、ネットワーク上のデータを検査するために、データが宛先に到達する前にデータを取り込んで検査し、検査が終了した後に当該宛先に転送する技術がある。しかし、このような技術では、データ全体の検査が完了するまでデータをバッファしておく必要があるため、大きな記憶領域が必要である。

本開示は、上記した問題に鑑み、ネットワーク上のデータを取得して検査する際に、検査対象のデータのバッファに必要な記憶領域のサイズを低減させることを課題とする。

本開示の一例は、ネットワークを流れる、コンテンツを含むデータを、宛先に到達する前に取得するデータ取得手段と、所定のサイズを有するバッファ領域に、取得された前記データをバッファするバッファ手段と、前記バッファ手段によってバッファされたデータを、前記宛先で組み立てられることで得られるファイルの前方から後方への順に相当する順序で参照することで、前記コンテンツを検査する検査手段と、前記バッファ手段によってバッファされたデータのうち、前記検査手段による参照が完了した部分を、前記コンテンツ全体の検査が終了する前に、前記宛先に転送する転送手段と、を備える情報処理装置である。

本開示は、情報処理装置、システム、コンピューターによって実行される方法またはコンピューターに実行させるプログラムとして把握することが可能である。また、本開示は、そのようなプログラムをコンピューターその他の装置、機械等が読み取り可能な記録媒体に記録したものとしても把握できる。ここで、コンピューター等が読み取り可能な記録媒体とは、データやプログラム等の情報を電気的、磁気的、光学的、機械的または化学的作用によって蓄積し、コンピューター等から読み取ることができる記録媒体をいう。

本開示によれば、ネットワーク上のデータを取得して検査する際に、検査対象のデータのバッファに必要な記憶領域のサイズを低減させることが可能となる。

実施形態に係るシステムの構成を示す概略図である。 実施形態に係る通信検査装置のハードウェア構成を示す図である。 実施形態に係る通信検査装置の機能構成の概略を示す図である。 実施形態に係るパケット処理の流れの概要を示すフローチャートＡである。 実施形態に係るパケット処理の流れの概要を示すフローチャートＢである。 実施形態に係るパケット処理が実行された場合のコンテンツ全体におけるバッファ処理およびコンテンツの検査の様子を示す図である。 実施形態に係るヘッダー送信処理の流れの概要を示すフローチャートである。 実施形態において、パケット処理およびヘッダー送信処理を実行した場合のパケットの流れを示す図である。 実施形態において、パケット処理およびヘッダー送信処理を実行した場合のパケットの流れのバリエーションを示す図である。

以下、本開示に係る情報処理装置、方法およびプログラムの実施の形態を、図面に基づいて説明する。但し、以下に説明する実施の形態は、実施形態を例示するものであって、本開示に係る情報処理装置、方法およびプログラムを以下に説明する具体的構成に限定するものではない。実施にあたっては、実施の態様に応じた具体的構成が適宜採用され、また、種々の改良や変形が行われてよい。

本実施形態では、本開示に係る情報処理装置、方法およびプログラムを、通信検査装置において実施した場合の実施の形態について説明する。但し、本開示に係る情報処理装置、方法およびプログラムは、ネットワーク上のデータを検査するための技術について広く用いることが可能であり、本開示の適用対象は、本実施形態において示した例に限定されない。

＜システムの構成＞
図１は、本実施形態に係るシステム１の構成を示す概略図である。本実施形態に係るシステム１は、複数の情報処理端末９０（以下、「クライアント９０」と称する）が接続されるネットワークセグメント２と、クライアント９０に係る通信を中継するための通信検査装置２０と、を備える。また、ネットワークセグメント２内のクライアント９０は、インターネットや広域ネットワークを介して遠隔地において接続された各種のサーバーと、通信検査装置２０を介して通信可能である。本実施形態において、通信検査装置２０は、ネットワークセグメント２において、クライアント９０とインターネットとの間に接続されることで、通過するパケットを取得する。そして、通信検査装置２０は、取得したパケットのうち、検査対象でないパケット、および検査の結果転送してもよいと判定されたパケットを転送する。

図２は、本実施形態に係る通信検査装置２０のハードウェア構成を示す図である。通信検査装置２０は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１１、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１２、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１３、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ ａｎｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）やＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）等の記憶装置１４、ＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）１５等の通信ユニット、等を備えるコンピューターである。但し、通信検査装置２０の具体的なハードウェア構成に関しては、実施の態様に応じて適宜省略や置換、追加が可能である。また、通信検査装置２０は、単一の装置に限定されない。通信検査装置２０は、所謂クラウドや分散コンピューティングの技術等を用いた、複数の装置によって実現されてよい。

図３は、本実施形態に係る通信検査装置２０の機能構成の概略を示す図である。通信検査装置２０は、記憶装置１４に記録されているプログラムが、ＲＡＭ１３に読み出され、ＣＰＵ１１によって実行されることで、コンテンツ要求検知部２１、データ取得部２２、送信回数予測部２３、抽出部２４、ヘッダー生成部２５、検査部２６、検査中送信部２７、転送部２８、中止部２９、検査結果通知部３０、バッファ部３１および判定部３２を備える情報処理装置として機能する。なお、本実施形態では、通信検査装置２０の備える各機能は、汎用プロセッサであるＣＰＵ１１によって実行されるが、これらの機能の一部または全部は、１または複数の専用プロセッサによって実行されてもよい。また、これらの機能の一部または全部は、クラウド技術等を用いて、遠隔値に設置された装置や、分散設置された複数の装置によって実行されてもよい。

コンテンツ要求検知部２１は、送信元、宛先および要求コンテンツの種類の少なくとも何れかが所定の条件に合致するコンテンツ要求（接続要求）を検知する。

データ取得部２２は、ネットワークに接続された端末によって送受信される通信に係る、ヘッダーとコンテンツを含むデータを、宛先に到達する前に取得する。なお、本実施形態において、通信検査装置２０は、ネットワークセグメント２に接続されたクライアント９０による通信の他、通信検査装置２０を介する全ての通信を、検査の対象とすることが出来る。

バッファ部３１は、所定のサイズを有するＲＡＭ１３上のコンテンツバッファ領域に、取得されたデータをバッファする。ここで、バッファ部３１は、データが複数のパケットに分割されて順次取得される場合、データのうち新たに取得したパケットに含まれる部分を、未転送のデータがバッファされている領域を除く領域にバッファする。換言すれば、バッファ部３１は、データのうち新たに取得したパケットに含まれる部分を、データがバッファされていない領域または転送済のデータがバッファされている領域にバッファする。以下、未転送のデータがバッファされている領域を除く領域を、「空き領域」と称する。なお、本実施形態において、バッファ部３１によって所定のサイズを有するコンテンツバッファ領域にバッファされるのはデータのうちコンテンツの部分であり、コンテンツのヘッダーについては、ＲＡＭ１３上の別の領域にバッファされる。

判定部３２は、コンテンツバッファ領域において、データのうち新たに取得するパケットに含まれる部分をバッファするための空き領域が足りているか否かを判定する。具体的には、判定部３２は、データのうち新たに取得するパケットに含まれる部分のサイズと、コンテンツバッファ領域の空き領域のサイズとを比較することで、コンテンツバッファ領域において空き領域が足りているか否かを判定する。ここで、空き領域が足りていないと判定された場合、転送部２８に、バッファ部３１によってバッファされたデータのうち、検査部２６による参照が完了した部分を転送させることで、コンテンツバッファ領域を確保する。

送信回数予測部２３は、データ取得部２２によって取得されるコンテンツの検査に必要な検査時間を予測し、予測された検査時間に基づいて、検査中送信部２７による送信回数を予測する。より具体的には、送信回数予測部２３は、検査部２６による検査が開始されてから転送部２８によるコンテンツ部分の先頭部分の転送が開始されるまでの時間を予測する。

抽出部２４は、データ取得部２２によって取得されたデータに含まれるヘッダーから、宛先に受信されるコンテンツを確定させないヘッダーを抽出する。

ヘッダー生成部２５は、宛先に受信されるコンテンツを確定させないヘッダーを生成する。

検査部２６は、データ取得部２２によって取得されたコンテンツが、当該データに設定された宛先への転送が許可されるコンテンツであるか否かを、予め定められた検査項目に従って検査する。例えば、検査部２６は、コンテンツにマルウェアが含まれているか否か、コンテンツに望ましくない表現が含まれているか否か、等を検査する。但し、本開示に係る検査において採用され得る具体的な検査項目や検査手法は、本実施形態における例示に限定されない。具体的な検査項目や検査手法には、既知の、または将来開発される様々な検査項目および検査手法が採用されてよい。

なお、検査部２６は、データ取得部２２によるコンテンツ全体の取得が完了する前に、当該コンテンツの検査を開始する。そして、検査部２６は、バッファ部３１によってバッファされたデータを、宛先で組み立てられることで得られるファイルの前方から後方への順に相当する順序で参照することで、コンテンツを検査する。より具体的には、検査部２６は、コンテンツバッファ領域の参照ポイントを示すポインターを、当該コンテンツバッファ領域におけるデータの並びに関係なく、宛先で組み立てられることで得られるファイルの前方から後方への順に相当する順序で制御して、バッファされたデータを参照する。

即ち、本実施形態に係る検査部２６は、ＲＡＭ１３のコンテンツバッファ領域に、コンテンツ全体が保持されていない状態でコンテンツの検査を行う。上述の通り、検査部２６は、バッファ部３１によってバッファされたデータを、宛先で組み立てられることで得られるファイルの前方から後方への順に相当する順序で参照するが、この際、検査部２６は、検査経過をＲＡＭ１３上において管理し、コンテンツを前方から後方へ参照しながら検査を行い、検査経過を逐次更新する。例えば、検査がパターンマッチングによって行われている場合、検査経過には、パターンマッチングによるマッチングの有無が記録され、検査がハッシュ演算等によって行われている場合、検査経過には、コンテンツにおける参照が完了した位置までのハッシュ演算結果が記録される。

検査中送信部２７は、検査部２６による検査が開始されてから転送部２８によるコンテンツ部分の先頭部分の転送が開始されるまでの間、宛先におけるデータの受信待ち時間がタイムアウトしない間隔で、データに含まれるヘッダーの少なくとも一部を当該データの宛先に送信する。なお、本実施形態では、タイムアウト防止のために送信されるデータとして、ヘッダーを送信することとしているが、タイムアウト防止のために送信されるデータは、クライアント９０に受信される後続データの種類やサイズ等を確定させないものであればよく、ヘッダーに限定されない。

転送部２８は、バッファ部３１によってバッファされたデータのうち、検査部２６による参照が完了した部分を、コンテンツ全体の検査が終了する前に、当該データの宛先に転送する。なお、判定部３２の説明において上述した通り、この転送は、判定部３２によって空き領域が足りていないと判定された場合に行われてもよい。また、転送部２８は、検査部２６によるコンテンツ全体の検査が完了した後、検査結果が、該コンテンツが宛先への転送が許可されるコンテンツであるという検査結果であった場合に、該コンテンツを含むデータのうち送信済みの部分を除くデータを、当該データの宛先に転送する。

中止部２９は、検査部２６による検査結果が、当該コンテンツが当該データの宛先への転送が許可されるコンテンツではないという検査結果であった場合に、転送部２８による転送を中止する。

検査結果通知部３０は、検査部２６による検査結果が、当該コンテンツが当該データの宛先への転送が許可されるコンテンツではないという検査結果であった場合に、当該検査結果をデータの宛先に通知するための情報を、検査中送信部２７または転送部２８によって送信済みの部分に続くデータの一部として、当該宛先に送信する。

＜処理の流れ＞
次に、本実施形態に係るシステム１によって実行される処理の流れを、フローチャートを用いて説明する。なお、以下に説明するフローチャートに示された処理の具体的な内容および処理順序は、本開示を実施するための一例である。具体的な処理内容および処理順序は、本開示の実施の形態に応じて適宜選択されてよい。

図４および図５は、本実施形態に係るパケット処理の流れの概要を示すフローチャートである。本実施形態に係るパケット処理は、通信検査装置２０によって、ネットワーク上を流れる接続要求パケット（例えば、ＴＣＰのＳＹＮパケット）が受信されたことを契機として実行される。

ステップＳ１０１では、接続要求が取り込まれる。コンテンツ要求検知部２１は、受信されたパケットのヘッダーに設定されている送信元および宛先を参照して、取り込みの対象となるパケット（例えば、クライアント９０からサーバーへの接続要求パケット）であるか否かを判定し、取り込みの対象となるパケットを取り込み、ＲＡＭ１２に記憶する（所謂フック処理）。取り込みの対象でないと判定されたパケットは、通信検査装置２０に取り込まれることなく、宛先に転送される（図示は省略する）。取り込みの対象であるか否かは、パケットの送信元および宛先が、予め設定された送信元ＩＰアドレスおよび宛先ＩＰアドレスのリストに登録されているか否かを照合することによって判定される。この照合に用いられるリストは、ホワイトリストであってもブラックリストであってもよい。また、パケットが取り込みの対象であるか否かの判定には、本開示とは異なる手法が採用されてもよい。その後、処理はステップＳ１０２へ進む。

ステップＳ１０２では、クライアント９０の要求に係るコンテンツを検査対象とするか否かが判定される。コンテンツ要求検知部２１は、ステップＳ１０１で取り込まれた接続要求に係るコネクションに属するパケットを受信し、当該パケットのリクエストラインおよびヘッダーを参照して、当該パケットが、検査部２６による検査対象となる所定の種類のコンテンツを要求するパケットであるか否かを判定する。検査対象コンテンツを要求するパケットであるか否かは、パケットのリクエストラインおよびヘッダーが、予め設定された検査対象リストに登録されている情報と合致または近似するか否かを照合することによって判定される。

例えば、ＨＴＴＰパケットが、以下に示されたリクエストラインおよびヘッダーを有する場合、当該パケットは、検査対象のコンテンツを要求するものであると判定される。
GET / HTTP/1.1
Host: sample.site
Accept: */*
User-Agent: UserAgent 1.0
Accept-Language: ja
Accept-Encoding: gzip, deflate
Connection: keep-alive
パケットが検査対象コンテンツを要求するパケットではないと判定された場合、当該パケットによって要求されたコンテンツは検査対象とはならず、パケットは転送され（ステップＳ１１９）、本フローチャートに示された処理は終了する。一方、パケットが検査対象コンテンツを要求するパケットであると判定された場合、当該パケットによって要求されたコンテンツは、後述するステップＳ１１３における検査の対象として設定され、処理はステップＳ１０３へ進む。

ステップＳ１０３およびステップＳ１０４では、接続要求およびコンテンツ要求が送信される。通信検査装置２０は、ステップＳ１０１の接続要求に係るサーバーに接続し、ステップＳ１０２のコンテンツ要求に係るコンテンツを、当該サーバーに要求する。この際、通信検査装置２０は、ステップＳ１０１およびステップＳ１０２で受信されたパケットをそのままサーバーに転送してもよいし、必要に応じて送信元ＩＰアドレスをアドレス変換してからサーバーに送信してもよい。その後、処理はステップＳ１０５へ進む。

ステップＳ１０５では、レスポンスステータスおよび／またはヘッダーを含むパケットが受信される。データ取得部２２は、ステップＳ１０４で送信されたコンテンツ要求パケットへの応答パケットとしてサーバーから送信された、レスポンスステータスまたはヘッダーを含むデータを、クライアント９０に到達する前に取得する。ここで、データが複数のパケットに分割されて送信されている場合には、データ取得部２２は、複数のパケットを組み立てることで、レスポンスステータスまたはヘッダーを含むデータを取得する。また、通信検査装置２０は、ヘッダーの内容を参照して、当該ヘッダーに続くコンテンツを、検査部２６による検査対象とするか否かを判定する。この判定は、例えば、ヘッダーの内容から特定されたコンテンツの種類を、検査対象とする（または、検査対象としない）コンテンツの種類のリストと照合することで行われる。また、この判定は、ヘッダーの内容から特定されたコンテンツのサイズと、検査対象とするサイズの上限とを比較することによって行われてもよい。

例えば、ＨＴＴＰデータが、以下に示されたレスポンスステータスおよびヘッダーを有する場合、後続コンテンツが検査対象であると判定される。
HTTP/1.1 200 OK
Server: Apache
Date: xxxxxxxx GMT
Content-Type: application/octet-stream
Content-Length: 108
Connection: keep-alive
Cache-Control: max-age=0, no-cache
Pragma: no-cache
判定の結果、コンテンツを検査対象としないと判定された場合、当該パケットに係るコネクションは検査の対象外に設定され、本フローチャートに示された処理は終了する（図示は省略する）。一方、コンテンツを検査対象とする場合、処理はステップＳ１０６へ進む。

ステップＳ１０６では、後述するヘッダー送信処理による送信回数が予測される。送信回数予測部２３は、はじめに、ステップＳ１０５で受信されたパケットのヘッダーを参照してヘッダーおよびコンテンツの先頭部分（コンテンツを含む１つ目のパケットに含まれるコンテンツ部分）のサイズを把握し、これを、検査部２６による処理能力（例えば、所定時間あたりに検査可能なデータサイズ）で除算することで、ヘッダーの検査およびコンテンツの先頭部分の検査が完了し、コンテンツの先頭部分の転送が開始されるまでに必要な検査時間を予測する。そして、送信回数予測部２３は、予測された検査時間を、検査中送信部２７による送信間隔で除算することで、送信回数を予測する。ここで、検査中送信部２７による送信間隔には、コンテンツを受信するクライアント９０において、コンテンツに係るパケット受信の待ち時間がタイムアウトしない間隔が予め設定される。その後、処理はステップＳ１０７へ進む。

ステップＳ１０７では、検査中に送信可能なヘッダーの部分が抽出される。抽出部２４は、ステップＳ１０５において受信されたヘッダーから、宛先に受信されるコンテンツを確定させないヘッダー部分を抽出する。換言すれば、抽出部２４は、検査中送信部２７によって送信済みの部分に続くデータの一部として、仮にサーバーから送信されたデータ以外のデータ（例えば、検査結果）が宛先に送信された場合に、該宛先による該データの処理に不都合（例えば、データサイズの矛盾や、コンテンツの種類の矛盾）が生じるヘッダー部分を除外することで、宛先に受信されるコンテンツを確定させないヘッダーを抽出する。

例えば、ステップＳ１０５の説明において例示したヘッダーのうち、以下に示す部分は、コンテンツの種類およびサイズを限定するヘッダー部分であり、その後に送信可能なデータを限定してしまうヘッダー部分である。
Content-Type: application/octet-stream
Content-Length: 108
このため、抽出部２４は、上記したヘッダー部分を除いた部分を、コンテンツを確定させないヘッダーとして抽出する。

なお、本実施形態では、コンテンツの送受信にＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）が用いられる場合を例に挙げて説明しているが、本開示は、その他のプロトコルにも適用可能である。例えば、コンテンツの送受信に用いられるプロトコルがＰＯＰ３（Ｐｏｓｔ Ｏｆｆｉｃｅ Ｐｒｏｔｏｃｏｌ Ｖｅｒｓｉｏｎ ３）である場合には、ヘッダー中のＦｒｏｍフィールド、Ｔｏフィールド、ＣｃフィールドおよびＳｕｂｊｅｃｔフィールド等が、コンテンツの種類およびサイズを限定するヘッダーであるため、抽出部２４は、これらの部分を除くヘッダーを抽出する。

また、抽出部２４は、データ取得部２２によって取得されたデータに含まれるヘッダーから、宛先に受信されるコンテンツを確定させないヘッダーを、ステップＳ１０６で予測された送信回数に応じて決定された量だけ抽出することとしてもよい。具体的には、抽出部２４は、ステップＳ１０６で予測された送信回数に分けて送信可能な量、ヘッダー部分を抽出してもよい。なお、抽出可能なヘッダー部分の量が、送信回数分に満たない場合、抽出部２４は、コンテンツを確定させないヘッダー部分を全て抽出する。その後、処理はステップＳ１０８へ進む。

ステップＳ１０８およびステップＳ１０９では、コンテンツを含むパケットが受信され、コンテンツバッファの空き領域が足りているか否かが判定される。データ取得部２２は、ステップＳ１０４で送信されたコンテンツ要求パケットへの応答パケットとしてサーバーから送信された、コンテンツを含むパケットを受信する（ステップＳ１０８）。そして、判定部３２は、コンテンツバッファの空き領域のサイズと、次にバッファされるデータのサイズとを比較することで、受信されたパケットに含まれるコンテンツをバッファするための空き領域が有るか否かを判定する（ステップＳ１０９）。

具体的には、判定部３２は、コンテンツバッファの空き領域のサイズが、受信されたパケットに含まれるコンテンツ部分のサイズよりも大きい場合には、受信されたコンテンツをバッファするための空き領域が足りていると判定する。空き領域が足りていると判定された場合、空き領域の確保は不要であるため、処理はステップＳ１１２へ進む。一方、判定部３２は、コンテンツバッファの空き領域のサイズが、受信されたコンテンツのサイズよりも小さい場合には、受信されたコンテンツをバッファするための空き領域が不足していると判定する。空き領域が不足していると判定された場合、空き領域の確保が必要であるため、処理はステップＳ１１０へ進む。

ステップＳ１１０およびステップＳ１１１では、コンテンツバッファの空き領域が確保される。転送部２８は、バッファされたデータのうち、最も古い時点でバッファされたデータから順に（ＦＩＦＯ：Ｆｉｒｓｔ Ｉｎ， Ｆｉｒｓｔ Ｏｕｔ）、当該データの宛先であるクライアント９０に転送（送信）する（ステップＳ１１０）。また、バッファ部３１は、ステップＳ１０９で転送されたデータを、コンテンツバッファから削除する（ステップＳ１１１）。なお、ここでいうコンテンツバッファからの削除は、転送済みのデータが記録されていた領域に次に受信されるパケットのデータを記録可能なようにすることであり、データの完全な消去（ゼロクリア等）を意味するものではない。その後、処理はステップＳ１１２へ進む。

ステップＳ１１２からステップＳ１１５では、受信されたコンテンツが検査される。データ取得部２２は、コンテンツを含むデータを、クライアント９０に到達する前に取得し、取得したデータをコンテンツバッファに記録することで、当該データに含まれるコンテンツのうち、少なくとも当該データに係る部分の検査が完了するまで、宛先クライアント９０への転送を保留する（ステップＳ１１２）。

そして、データの転送が保留されている間に、検査部２６は、取得されたコンテンツが、クライアント９０への転送が許可されるコンテンツであるか否かを、予め定められた検査項目に従って検査する（ステップＳ１１３）。ここで、データが複数のパケットに分割されて送信されている場合には、検査部２６は、複数のパケットの夫々がデータ取得部２２によって取得される毎に、パケットからデータを取り出してバッファし、順次検査を行う。コンテンツ全体の検査が完了する前に、即ち検査の途中で、当該コンテンツが、クライアント９０への転送が許可されないコンテンツであると判定された場合（ステップＳ１１４）、コンテンツの検査は中断され、処理はステップＳ１１８へ進む。検査が中断されない場合、ステップＳ１０８からステップＳ１１５の処理はコンテンツ全体の検査が完了するまで繰り返され、コンテンツ全体の検査が完了すると（ステップＳ１１５）、処理はステップＳ１１６へ進む。

なお、ステップＳ１０８からステップＳ１１５におけるコンテンツの受信および検査が行われている間、通信検査装置２０は、クライアント９０における受信待ち時間のタイムアウトを防止するため、ヘッダー送信処理を実行する。ヘッダー送信処理の詳細については、図７を用いて後述する。

ステップＳ１１６では、検査結果が判定される。ステップＳ１０８からステップＳ１１５における検査の結果、コンテンツが、クライアント９０への転送が許可されるコンテンツであると判定された場合、処理はステップＳ１１７へ進む。一方、コンテンツが、クライアント９０への転送が許可されないコンテンツであると判定された場合、処理はステップＳ１１８へ進む。

ステップＳ１１７では、データが転送される。転送部２８は、コンテンツを含むデータのうち、既に送信済みの部分を除くデータ、即ち、バッファされているデータを、当該データの宛先であるクライアント９０に転送（送信）する。その後、本フローチャートに示された処理は終了する。

ステップＳ１１８では、データの転送が中止され、検査結果情報が通知される。中止部２９は、検査部２６による検査結果が、当該コンテンツが当該データの宛先への転送が許可されるコンテンツではないという検査結果であった場合に、転送部２８による転送を中止する。このため、本実施形態に係るシステムによれば、望ましくないコンテンツが、クライアント９０に対して送信されてしまうことを防止することが出来る。そして、検査結果通知部３０は、当該検査結果をデータの宛先に通知するための情報を、検査中送信部２７によって送信済みの部分に続くデータの一部（ヘッダーおよびコンテンツ等）として、当該宛先に送信する。具体的には、検査結果通知部３０は、クライアント９０が要求したコンテンツに、マルウェアや望ましくない表現等が含まれていることを、クライアント９０のユーザーに通知するためのコンテンツ（例えば、Ｗｅｂページ）と、当該コンテンツに適したヘッダー（例えば、コンテンツの種類およびサイズを限定するヘッダー）とを生成し、クライアント９０に対して送信する。その後、本フローチャートに示された処理は終了する。

図６は、本実施形態に係るパケット処理が実行された場合のコンテンツ全体におけるバッファ処理およびコンテンツの検査の様子を示す図である。ここで、コンテンツの検査とは、コンテンツ全体を１つのまとまりとした検査であり、単に順次送信されてくるパケットを検査するパケット検査とは異なる。本実施形態において、コンテンツ検査は、コンテンツ全体を１つのファイルとして、先頭から順に検査を行う。

検査の内容は、例えば、パターンマッチングやハッシュ演算等であるが、このような処理は、コンテンツ（ファイル）全体がＲＡＭ１３上にロードされていることを必ずしも必要としない。即ち、これらの検査は、コンテンツの内容を先頭から順に参照することができれば可能なものであるため、本実施形態に係る通信検査装置２０は、コンテンツ（ファイル）全体をＲＡＭ１３（コンテンツバッファ）に蓄積することなく、コンテンツの先頭からＦＩＦＯ方式でバッファされている部分を順に参照することで、検査を行う。検査が終了した部分については、コンテンツバッファの空き容量に応じてＦＩＦＯ方式で転送され、コンテンツバッファから削除されていくため、コンテンツの先頭から順に「転送済」となる。また、バッファされている部分よりも後方のコンテンツは、サーバーから「未受信」である。但し、コンテンツバッファに余裕がある場合には、コンテンツ（ファイル）全体をＲＡＭ１３（コンテンツバッファ）に蓄積してもよい。

図７は、本実施形態に係るヘッダー送信処理の流れの概要を示すフローチャートである。本実施形態に係るヘッダー送信処理は、図４および図５に示されたパケット処理において、ステップＳ１０８からステップＳ１１５に示されたコンテンツ検査が開始されたことを契機として実行される。

ステップＳ２０１では、ヘッダーの一部が送信される。検査中送信部２７は、データに含まれるヘッダーの少なくとも一部を、当該データの宛先であるクライアント９０に送信する。なお、本実施形態では、タイムアウト防止のために送信されるデータとして、抽出部２４によって抽出されたヘッダーの一部、または、ヘッダー生成部２５によって生成されたヘッダーが用いられているが、タイムアウト防止のために送信されるデータは、クライアント９０に受信される後続データの種類やサイズ等を確定させないものであればよく、ヘッダーに限定されない。その後、処理はステップＳ２０２へ進む。

ステップＳ２０２では、検査の終了またはデータ転送の開始がされたか否かが判定される。検査中送信部２７は、上述したパケット処理のステップＳ１０８からステップＳ１１５に示されたコンテンツ検査が終了したか否か、およびコンテンツバッファの空き領域確保のためのデータ転送が開始されたか否かを判定する。コンテンツ検査が終了していないと判定された場合、処理はステップＳ２０３へ進む。一方、コンテンツ検査が終了したと判定された場合、本フローチャートに示された処理は終了する。なお、本実施形態では、検査部２６によるコンテンツ検査が終了したか否かを確認して、ヘッダー送信処理を継続するか否かを決定することとしているが、ヘッダー送信処理の継続／終了の判定は、検査開始から検査時間（ステップＳ１０６で算出）が経過したか否かに基づいて判定されてもよい。

ステップＳ２０３およびステップＳ２０４では、未送信のヘッダーが無い場合に、タイムアウト防止用のヘッダーが生成される。ヘッダー生成部２５は、ステップＳ１０７で抽出されたヘッダーが全てクライアント９０に対して送信され、送信可能なヘッダーが尽きた場合（ステップＳ２０３のＮＯ）、タイムアウト防止用のヘッダーを生成する（ステップＳ２０４）。ここで生成されるヘッダーは、ステップＳ１０７で抽出されたヘッダーと同様、宛先に受信されるコンテンツを確定させないヘッダーである。また、ヘッダー生成部２５は、宛先に受信されるコンテンツを確定させないヘッダーとして、例えば、名称が「Ｘ−」から始まるオリジナルヘッダーを生成してよい。

なお、本実施形態では、抽出されたヘッダーが尽きた場合に、ヘッダー生成部２５にタイムアウト防止用のヘッダーを生成させ、検査中送信部２７に送信させることとしているが、このような構成に代えて、検査中送信部２７に、サーバーから受信されたデータ中のヘッダー以外の部分（例えば、コンテンツ中の、クライアント９０に送信してよい部分）を少しずつ送信させる構成が採用されてもよい。

ステップＳ２０５では、送信間隔の経過が待たれる。検査中送信部２７は、予め設定された送信間隔の経過を待つ。上述の通り、送信間隔には、コンテンツを受信するクライアント９０において、コンテンツに係るパケット受信の待ち時間がタイムアウトしない間隔が予め設定される。送信間隔が経過すると、処理はステップＳ２０１へ進み、ヘッダーの続きが一部送信される（ステップＳ２０１）。即ち、本実施形態に係るシステムによれば、検査中送信部２７は、検査部２６による検査が行われている間、宛先におけるデータの受信待ち時間がタイムアウトしない間隔で、データに含まれるヘッダーを一部ずつ当該データの宛先に送信する。

図８および図９は、本実施形態において、パケット処理およびヘッダー送信処理を実行した場合のパケットの流れを示す図である。本実施形態に係る情報処理装置、方法およびプログラムによれば、コンテンツ要求に応じてサーバーから送信されたデータを通信検査装置２０が検査している間、データのうちコンテンツを確定させない部分（ヘッダー等）を分割してクライアント９０に送信することで、コンテンツ検査中のタイムアウトを防止することが出来る。

また、図９は、コンテンツのサイズがコンテンツバッファのサイズよりも大きいために、検査中にバッファされているデータがクライアントに転送される場合のパケットの流れが示されている。例えば、１のコネクションまたはクライアントに割り当てられるコンテンツバッファのサイズがパケット２つ分相当であった場合、分割されたコンテンツの３つ目が含まれるパケットをバッファする前に、先頭のコンテンツから順にクライアントへの転送およびコンテンツバッファからの削除が開始される。このコンテンツバッファからの転送・削除の処理は、先述の通りＦＩＦＯ方式で行われる。

なお、受信待ち時間のタイムアウトを防止するための技術として、従来、空のパケットを一定時間毎に送信することで、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）層等の下位層でのタイムアウトを防止する技術（例えば、ＴＣＰにおけるｋｅｅｐ-ａｌｉｖｅ）が用いられることがあるが、これは、アプリケーション層でのタイムアウトを防止するものではなかった。本実施形態に示された情報処理装置、方法およびプログラムによれば、ＴＣＰ層のような下位層におけるタイムアウトのみならず、アプリケーション層におけるタイムアウトも防止することが出来る。

また、本実施形態に係る情報処理装置、方法およびプログラムによれば、クライアント９０において受信待ち時間のタイムアウトを起こさせずに、コンテンツ全体の検査が終了するまでクライアント９０にコンテンツを受信させないようにすることが出来る。更に、不適切なコンテンツが検出された場合には、専用のアプリケーション等を用いることなく、クライアント９０のコンテンツ要求に対する応答データとして、ユーザーに通知することが出来る。

なお、本実施形態では、本発明をＨＴＴＰ１．１において用いる例について説明したが、本発明を適用可能なプロトコルは、本実施形態における開示に限定されない。例えば、本発明は、同一セッション内でリクエストに対して返信されるコンテンツを含むパケットの順序が制限されないようなプロトコル（例えば、ＨＴＴＰ２．０）にも適用することが可能である。

１ システム
２０ 通信検査装置
９０ クライアント

Claims (9)

1. ネットワークを流れる、コンテンツを含むデータを、宛先に到達する前に取得するデータ取得手段と、
   所定のサイズを有するバッファ領域に、取得された前記データをバッファするバッファ手段と、
   前記バッファ手段によってバッファされたデータを、前記宛先で組み立てられることで得られるファイルの前方から後方への順に相当する順序で参照することで、前記コンテンツを検査する検査手段と、
   前記バッファ手段によってバッファされたデータのうち、前記検査手段による参照が完了した部分を、前記コンテンツ全体の検査が終了する前に、前記宛先に転送する転送手段と、
   前記バッファ領域において、前記データのうち新たに取得するパケットに含まれる部分をバッファするための空き領域が足りているか否かを判定する判定手段と、を備え、
   前記転送手段は、前記判定手段によって空き領域が足りていないと判定された場合に、前記バッファ手段によってバッファされたデータのうち、前記検査手段による参照が完了した部分を転送する、
   情報処理装置。
2. 前記バッファ手段は、前記データが複数のパケットに分割されて順次取得される場合、前記データのうち新たに取得したパケットに含まれる部分を、未転送のデータがバッファされている領域を除く領域にバッファする、
   請求項１に記載の情報処理装置。
3. 前記検査手段は、前記バッファ領域の参照ポイントを示すポインターを、宛先で組み立てられることで得られるファイルの前方から後方への順に相当する順序で制御することで、バッファされたデータを前記順序で参照する、
   請求項２に記載の情報処理装置。
4. 前記判定手段は、前記データのうち新たに取得するパケットに含まれる部分のサイズと、前記バッファ領域の空き領域のサイズとを比較することで、前記バッファ領域において空き領域が足りているか否かを判定する、
   請求項１から３の何れか一項に記載の情報処理装置。
5. 前記検査手段は、前記データ取得手段による前記コンテンツ全体の取得が完了する前に、該コンテンツの検査を開始する、
   請求項１から４の何れか一項に記載の情報処理装置。
6. 前記検査手段は、該コンテンツが前記宛先への転送が許可されるコンテンツであるか否かを検査し、
   前記転送手段は、前記検査手段による検査結果が、該コンテンツが前記宛先への転送が許可されるコンテンツであるという検査結果であった場合に、該コンテンツを含むデータのうち送信済みの部分を除く前記データを、前記宛先に転送する、
   請求項１から５の何れか一項に記載の情報処理装置。
7. 前記検査手段による検査結果が、該コンテンツが前記宛先への転送が許可されるコンテンツではないという検査結果であった場合に、前記転送手段による転送を中止する中止手段を更に備える、
   請求項６に記載の情報処理装置。
8. コンピューターが、
   ネットワークを流れる、コンテンツを含むデータを、宛先に到達する前に取得するデータ取得ステップと、
   所定のサイズを有するバッファ領域に、取得された前記データをバッファするバッファステップと、
   前記バッファステップでバッファされたデータを、前記宛先で組み立てられることで得られるファイルの前方から後方への順に相当する順序で参照することで、前記コンテンツを検査する検査ステップと、
   前記バッファステップでバッファされたデータのうち、前記検査ステップにおける参照が完了した部分を、前記コンテンツ全体の検査が終了する前に、前記宛先に転送する転送ステップと、
   前記バッファ領域において、前記データのうち新たに取得するパケットに含まれる部分をバッファするための空き領域が足りているか否かを判定する判定ステップと、を実行し、
   前記転送ステップでは、前記判定ステップにおいて空き領域が足りていないと判定された場合に、前記バッファステップでバッファされたデータのうち、前記検査ステップにおける参照が完了した部分を転送する、
   方法。
9. コンピューターを、
   ネットワークを流れる、コンテンツを含むデータを、宛先に到達する前に取得するデータ取得手段と、
   所定のサイズを有するバッファ領域に、取得された前記データをバッファするバッファ手段と、
   前記バッファ手段によってバッファされたデータを、前記宛先で組み立てられることで得られるファイルの前方から後方への順に相当する順序で参照することで、前記コンテンツを検査する検査手段と、
   前記バッファ手段によってバッファされたデータのうち、前記検査手段による参照が完了した部分を、前記コンテンツ全体の検査が終了する前に、前記宛先に転送する転送手段と、
   前記バッファ領域において、前記データのうち新たに取得するパケットに含まれる部分をバッファするための空き領域が足りているか否かを判定する判定手段と、として機能させ、
   前記転送手段は、前記判定手段によって空き領域が足りていないと判定された場合に、前記バッファ手段によってバッファされたデータのうち、前記検査手段による参照が完了した部分を転送する、
   プログラム。

Images