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

Abstract

【課題】ネットワーク上でデータを検査する通信検査装置において、検査の継続性を高めることを課題とする【解決手段】１つ以上のセキュリティ検査項目についての検査を実行する情報処理装置に、該情報処理装置のＯＳによって提供されるファイルシステムを含むリソースが互いに隔離されるコンテナ型の仮想端末である、複数のコンテナと、ネットワークを流れるデータを、宛先に到達する前に取得するデータ取得部２１、２５と、前記宛先に前記データを送信するデータ送信部２４、２７と、を備え、前記複数のコンテナの一部は、前記検査を実行するためのアプリケーションが実装された検査コンテナであり、前記検査コンテナは、取得された前記データについて前記検査を実行する検査部５２を備えた。【選択図】図５

Description

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

従来、仮想ネットワークインフラストラクチャの仮想サーバ内の仮想マシンについての変化を検出し、仮想セキュリティ装置が仮想サーバ内で構成されるかどうかを判断し、仮想セキュリティ装置を仮想サーバ内で作成するよう要求を送信するステップを含み、更に、仮想セキュリティ装置が仮想マシン内で作成されるときに、仮想マシンが開始するのを許可するステップを含み、仮想セキュリティ装置は、仮想マシンから送信されるネットワークパケットに対してセキュリティ検査を実行し、更に、仮想マシンからのネットワークパケットをインターセプトするインターセプト機構を仮想サーバ内に作成するステップを含み、１つ又は複数のセキュリティポリシーが、１つ又は複数の仮想セキュリティ装置を識別し、仮想マシンからのネットワークパケットを処理する方法、が提案されている（特許文献１を参照）。

また、従来、メイン仮想マシンと、サブ仮想マシンと、物理ネットワークカードと、を備え、メイン仮想マシンとサブ仮想マシンとの動作状態をそれぞれ取得するステップと、メイン仮想マシンに障害が生じていると検出された場合、仮想マシンと前記物理ネットワークカードとのバインディング関係を切り替えるように制御するステップと、サブ仮想マシンを新たなメイン仮想マシンに切り替えるように制御し、障害が生じているメイン仮想マシンを新たなサブ仮想マシンに切り替えるように制御するステップと、を実行する、物理ネットワークセキュリティ装置およびその制御方法が提案されている（特許文献２を参照）。

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

従来、ネットワーク上のデータを検査するために、データが宛先に到達する前に通信検査装置や通信検査装置が備える仮想マシンでデータを取り込んで検査し、検査が終了した後に宛先に転送する技術がある。このような通信検査装置では、検査を実行するためのアプリケーションがストレージに格納されており、ＯＳ（オペレーティングシステム）がアプリケーションをメインメモリに読み込んで実行することで、当該検査を行っている。しかし、従来の技術では、アプリケーション等の更新に伴い、通信検査装置や仮想マシンの再起動等が必要となり、検査を継続的に実施できないという問題があった。

本開示は、上記した問題に鑑み、ネットワーク上でデータを検査する通信検査装置において、検査の継続性を高めることを課題とする。

本開示の一例は、１つ以上のセキュリティ検査項目についての検査を実行する情報処理装置であって、該情報処理装置のＯＳによって提供されるファイルシステムを含むリソースが互いに隔離されるコンテナ型の仮想端末である、複数のコンテナと、ネットワークを流れるデータを、宛先に到達する前に取得するデータ取得手段と、前記宛先に前記データを送信するデータ送信手段と、を備え、前記複数のコンテナの一部は、前記検査を実行するためのアプリケーションが実装された検査コンテナであり、前記検査コンテナは、取得した前記データについて前記検査を実行する検査手段を備える、情報処理装置である。

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

本開示によれば、ネットワーク上でデータを検査する通信検査装置において、検査の継続性を高めることが可能となる。

実施形態に係る従来の仮想化技術の構成を示す概略図である。 実施形態に係るＬｉｎｕｘコンテナの構成を示す概略図である。 実施形態に係るシステムの構成を示す概略図である。 実施形態に係る通信検査装置のハードウェア構成を示す図である。 実施形態に係る通信検査装置の機能構成の概略を示す図である。 実施形態に係るコネクション管理テーブルの構成を示す図である。 実施形態に係る第一経路テーブルの構成を示す図である。 実施形態に係る第二経路テーブルの構成を示す図である。 実施形態に係る契約情報テーブルの構成を示す図である。 実施形態に係るコンテナの機能構成の概略を示す図である。 実施形態に係るＩＰフィルタコンテナ＃２のコンテナ用経路テーブルの構成を示す図である。 実施形態に係るＭＡＩＬフィルタコンテナ＃１のコンテナ用経路テーブルの構成を示す図である。 実施形態に係るパケット処理の流れの概要を示すフローチャートＡである。 実施形態に係るパケット処理の流れの概要を示すフローチャートＢである。 実施形態に係るパケット処理の流れの概要を示すフローチャートＣである。 実施形態に係る応答パケット処理の流れの概要を示すフローチャートＡである。 実施形態に係る応答パケット処理の流れの概要を示すフローチャートＢである。 実施形態に係るアプリケーション更新（少量モジュールの更新）処理の流れの概要を示すフローチャートである。 実施形態に係るアプリケーション更新（大量モジュールの更新）処理の流れの概要を示すフローチャートである。 実施形態に係る経路設定処理の流れの概要を示すフローチャートである。 実施形態に係るアプリケーション更新に伴うコンテナ切り替え処理の流れの概要を示すフローチャートである。 実施形態に係るコネクション管理テーブルの構成を示す図である。 実施形態に係る第一経路テーブルＡの構成を示す図である。 実施形態に係る第一経路テーブルＢの構成を示す図である。

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

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

＜コンテナについて＞
本実施形態では、コンテナ型の仮想端末として、Ｌｉｎｕｘ（登録商標）コンテナ（Ｌｉｎｕｘ−Ｃｏｎｔａｉｎｅｒｓ、ＬＸＣ）を用いるが、Ｌｉｎｕｘコンテナはコンテナ型の仮想端末を例示するものであって、本開示に係る技術を実施するにあたっては、他の種類のコンテナ型の仮想端末が適宜採用されてもよい。

図１は、本実施形態に係る従来の仮想化技術の構成を示す概略図である。図２は、本実施形態に係るＬｉｎｕｘコンテナの構成を示す概略図である。Ｌｉｎｕｘコンテナは、仮想化技術の１つであり、ＯＳ上にシステムのその他の部分から隔離されたアプリケーション（ユーザープロセス）実行環境を構築するものである。従来のサーバー仮想化技術では、ホストＯＳもしくはハイパーバイザー（仮想化ソフトウェア）上で、仮想マシン（Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ、ＶＭ）が作り出される。この仮想マシン内部では、個々の独立したゲストＯＳが実行され、複数のＯＳ環境を構築可能にしている。具体的には、物理マシン上の共有リソース（ＣＰＵ、メモリ、ハードディスク等）がハイパーバイザーにより複数に分割され、仮想マシンにそれぞれ提供されることで、仮想的なハードウェア環境を作り出している。そのため、このような仮想化技術は「ハードウェア仮想化」とも呼ばれる。

一方、Ｌｉｎｕｘコンテナでは、物理マシン上で稼働するＯＳはホストＯＳ一つでよい。ホストＯＳの内部は、物理リソースを管理する「カーネル空間」と、ユーザープロセスを実行する「ユーザ空間」とに分けられる。Ｌｉｎｕｘコンテナのようなコンテナ型の仮想化では、コンテナと呼ばれる仮想的なユーザ空間が複数作られ、その隔離された空間でアプリケーションが実行される。具体的には、Ｌｉｎｕｘコンテナでは、ＯＳを通じて利用できるコンピューターのリソースをコンテナ毎に隔離することで、ホストＯＳ上で直接動作するアプリケーションや他のコンテナから独立した空間（ＯＳ環境）を作り出すことを可能にしている。そのため、このようなコンテナ型の仮想化技術は「ＯＳレベルの仮想化」とも呼ばれる。

コンテナ環境では、Ｌｉｎｕｘカーネルの機能であるＮａｍｅｓｐａｃｅ（名前空間）とｃｇｒｏｕｐｓ（コントロールグループ）と呼ばれる資源管理の仕組みを用いることで、単一のＯＳ内で複数のコンテナをプロセスとして稼働することを可能にしている。

Ｎａｍｅｓｐａｃｅは、単一のＯＳ上に複数の分離された空間を実現するものであり、プロセスやファイルシステム等へのアクセスの分離を実現し、分離された空間のプロセスは、別の分離された空間からは不可視にするといった制御を実現する。なお、特定のコンテナに属さない外部の環境からは、コンテナの内部を含め、すべてのプロセスを見ることが可能である。ここで、名前空間は、「名前空間」という機能がひとつ存在するわけではなく、独立させたいリソース（項目）により複数の機能がある。「名前空間」の例として、ｍｎｔ名前空間（マウント名前空間）、ｎｅｔ名前空間（ネットワーク名前空間）等が挙げられる。

ｍｎｔ名前空間は、プロセスから見えるファイルシステムのマウント情報を分離するものである。よって、このｍｎｔ名前空間の機能により、各コンテナは独立したファイルシステムを有し、異なる名前空間のファイルシステムにアクセスすることができないようにすることが可能である。ｎｅｔ名前空間は、ネットワークの制御を行う名前空間であり、各種ネットワークリソースを名前空間ごとに独立して持つことが可能である。具体的にはネットワークデバイス、ＩＰアドレス、ルーティングテーブル、ポート番号、フィルタリングテーブル等を独立して持つことが可能である。よって、このｎｅｔ名前空間の機能により、各コンテナがホストＯＳとは別に個別のＩＰアドレスを持つことが可能であり、複数のコンテナとホストＯＳ間でネットワーク通信を行うことができる。

Ｌｉｎｕｘコンテナではこれらの機能を用い、各種リソースが分離された空間を複数作成することで、コンテナを実現しているが、この分離された名前空間毎にハードウェア資源（リソース）を割り当て、リソースの使用制限を行うのがｃｇｒｏｕｐｓである。具体的には、ｃｇｒｏｕｐｓは、プロセスをグループ化し、ＣＰＵ、メモリ、ネットワーク等のリソースやそれらの組み合わせをプロセスの間で割り当て、制限することができる。この機能により、あるコンテナがホストＯＳのリソースを使い尽くし、ホストＯＳ上のプロセスや他のコンテナに影響を与えないようにすることが可能となる。

コンテナは、上述した特徴を有することにより、従来の仮想化技術と比較した場合に幾つかの利点を有する。例えば、コンテナの起動は、ＯＳから見ると単にプロセスが起動しているだけであり、従来の仮想化技術にあるような仮想マシンのシャットダウンやブートという概念が存在しないため、仮想環境の起動や停止を高速で行うことができる。また、コンテナは、従来の仮想化技術のようなハードウェアの仮想化が不要であり、隔離された空間を作るだけで済むため、仮想化によるオーバーヘッドが少なく、コンテナでは、アプリケーションのプロセスがコンテナ毎に分離されるが、ホストＯＳ環境から直接実行されるため、コンテナ上のＣＰＵの利用において、ホストＯＳと同等の性能を発揮できるという利点を有する。

本実施形態におけるコンテナ型の仮想技術では、各アプリケーションを独立化することで、アプリケーションの更新等の際、他のコンテナ内のアプリケーションに対する影響を抑えることが出来るため、従来の通信検査装置における検査と比較して、検査の継続性を高めることが出来る。また、コンテナ型の仮想技術では、上述の通り、従来の仮想マシンと比較した場合に、アプリケーションの更新等の際に必要となる仮想環境の停止や起動を高速で行うことができるため、従来の通信検査装置や仮想マシン上で検査が行われる場合と比較して、検査の継続性を高めることが出来る。さらに、検査項目（アプリケーション）毎に複数のコンテナを構築し、稼働中でないコンテナにおけるアプリケーションについて更新処理を行ったり、または、更新後のアプリケーションが実装された稼働中でないコンテナを新たに構築したりすることで、稼働中のコンテナを長時間停止する必要がなくなる。すなわち、データの転送経路に使用されるコンテナを、現在稼働中のコンテナから、アプリケーションの更新が完了したコンテナに切り替えるだけで、当該転送経路に使用されるコンテナにおけるアプリケーションの更新処理が完了することとなる。よって、アプリケーションの更新処理による検査の中断がほぼ発生せず、検査の継続性を高めることができる。

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

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

[通信検査装置]
図５は、本実施形態に係る通信検査装置２０の機能構成の概略を示す図である。通信検査装置２０は、記憶装置１４に記録されているプログラムが、ＲＡＭ１３に読み出され、ＣＰＵ１１によって実行されることで、データ取得部２１、第一転送部２２、経路設定部２３、データ送信部２４、応答データ取得部２５、第二転送部２６、応答データ送信部２７、コンテナ管理部２８、契約情報設定部２９、拒否処理部３３、コネクション管理部３４を備える情報処理装置として機能する。なお、本実施形態では、通信検査装置２０の備える各機能は、汎用プロセッサであるＣＰＵ１１によって実行されるが、これらの機能の一部または全部は、１または複数の専用プロセッサによって実行されてもよい。また、これらの機能の一部または全部は、クラウド技術等を用いて、遠隔地に設置された装置や、分散設置された複数の装置によって実行されてもよい。なお、データ取得部２１および第一転送部２２は、例えば、通信検査装置２０においてクライアント９０側に位置するバランサーとして機能し、応答データ取得部２５および第二転送部２６は、通信検査装置２０においてサーバー８０側に位置するアウトバウンドとして機能するようにしてもよい。本実施形態では、当該バランサーおよびアウトバンドは、各々個別のＩＰアドレスを有するが、中継機器であるブリッジに、バランサーおよびアウトバウンドを備える場合は、バランサーおよびアウトバウンドの両者で一つのＩＰアドレスを有するようにしてもよい。

通信検査装置２０は、１つまたは複数の第一経路テーブル３０および第二経路テーブル３１（それぞれ本願の発明の「経路テーブル」の一例である）、契約情報テーブル３２、コネクション管理テーブル３５、３６を備えており、各テーブルは記憶装置１４に記憶されている。また、通信検査装置２０は、例えばＬｉｎｕｘサーバーであり、コンテナ型の仮想端末であるＬｉｎｕｘコンテナが作成（構築）される。本実施形態では、通信検査装置２０において、１つまたは複数の、Ｌｉｎｕｘコンテナであるフィルタコンテナ（検査コンテナ）５０およびデータベースコンテナ６０が作成されている。

図６は、本実施形態に係るコネクション管理テーブル３５、３６の構成を示す図である。コネクション管理テーブル３５、３６は、クライアント９０とサーバー８０との間で接続中のコネクション（既存コネクション）を管理するためのテーブルであり、既存コネクションを特定する情報を保持（記憶）する。図示するように、コネクション管理テーブル３５、３６の各列には、送信元ＩＰアドレス、送信元ポート番号、宛先ＩＰアドレス、宛先ポート番号、マーク情報の項目が保持されている。本実施形態において、「送信元ＩＰアドレス」および「送信元ポート番号」は、データの送信元（クライアント９０やサーバー８０）のアドレスおよびポート番号を示す情報であり、「宛先ＩＰアドレス」および「宛先ポート番号」は、データの宛先（クライアント９０やサーバー８０）のアドレスおよびポート番号を示す情報である。

「マーク情報」には、データのプロトコル（ＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）プロトコルが例示される）の種類（サーバー８０が提供するサービスの種類）により定められたマークが格納される。プロトコルの種類により定められたマークは、例えば、ＨＴＴＰＳに関するプロトコルの場合（サーバー側のポート番号が４４３等の場合）にはマーク１、ＭＡＩＬに関するプロトコルの場合（サーバー側のポート番号が２５、１１０、１４３等の場合）にはマーク２、それ以外のプロトコルの場合はマークなし等、任意に設定（定義）可能である。また、マーク情報には、後述する、既存コネクションであることを示すマーク（既存コネクションマーク）が格納されるようにしてもよい。なお、「マーク情報」は、受信したデータがどのプロトコルに関するものであるか判別できる情報であればよいため、上述した数字による「マーク情報」に限定されるものではなく、記号等を用いるようにしてもよい。

図７は、本実施形態に係る第一経路テーブル３０の構成を示す図である。第一経路テーブル３０は、クライアント９０から受信したデータの次転送先（次に転送すべき転送先）を決定するために参照される情報を保持するテーブルである。図示するように、第一経路テーブル３０の各列には、送信元ＩＰアドレス、転送先アドレスの項目が保持されている。本実施形態において、「送信元ＩＰアドレス」は、データの送信元であるクライアント９０のアドレスを示す情報であり、「転送先アドレス」は、データの次転送先のアドレスを示す情報である。

図８は、本実施形態に係る第二経路テーブル３１の構成を示す図である。第二経路テーブル３１は、サーバー８０から受信した応答データの次転送先を決定するために参照される情報を保持するテーブルである。図示するように、第二経路テーブル３１の各列には、宛先ＩＰアドレス、転送先アドレスの項目が含まれている。本実施形態において、「宛先ＩＰアドレス」は、応答データの宛先であるクライアント９０のアドレスを示す情報であり、「転送先アドレス」は、応答データの次転送先のアドレスを示す情報である。

図９は、本実施形態に係る契約情報テーブル３２の構成を示す図である。契約情報テーブル３２は、クライアント９０が必要とする１つ以上の検査項目（契約情報）を、クライアント９０のアドレス情報と関連付けて保持し、クライアント９０が要する検査を実行するようデータの転送経路を決定するために参照されるテーブルである。図示するように、契約情報テーブル３２の各列には、クライアント名、クライアント９０のアドレス情報、検査項目（フィルタリング種類）が含まれている。本実施形態では、「検査項目」として、ＩＰフィルタリング、ＭＡＩＬフィルタリング、ＵＲＬフィルタリング、ＨＴＴＰ（Ｓ）フィルタリングを例示する。なお、契約情報テーブル３２に記憶される項目は、上述した項目に限るものではなく、例えば、当該フィルタリングを行う対象となるデータのプロトコルの種類を示す情報等が含まれてもよい。

データ取得部２１（本願の発明の「データ取得手段」の一例である）は、ネットワークを流れるデータを、宛先に到達する前に取得する。例えば、本実施形態におけるクライアント９０から送信されたデータを、サーバー８０に到達する前に取得する。なお、本実施形態において、通信検査装置２０は、ネットワークセグメント２に接続されたクライアント９０による通信の他、通信検査装置２０を介する全ての通信を、検査の対象とすることが出来る。

また、データ取得部２１は、取得したデータにプロトコルの種類により定められたマークを付与する。具体的には、データ取得部２１は、コネクション管理部３４によりコネクション管理テーブル３５に格納された、当該データに対応するコネクション情報（コネクションを特定する情報）を参照し、当該コネクション情報として格納されたマークと同一のマークをデータに付与する。なお、この際、データ取得部２１は、取得したデータに設定された送信元ＩＰアドレス、宛先ＩＰアドレスおよび宛先ポート番号に基づきコネクション管理テーブル３５を参照し、これらの情報が一致するコネクションを、当該データに対応するコネクションであると判定する。なお、データ取得部２１は、当該三つの情報に送信元ポート番号を加えた四つの情報に基づきコネクション管理テーブル３５を参照し、対応するコネクションを判定するようにしてもよい。また、パケットにマークを付ける機能（パケットのマーク機能）は、パケット自体にマークを付けるのではなく、ＯＳ内のパケットを管理するデータにマークを付けるものであり、マークを付けたＯＳ内でのみ有効なものである。このように、マーク情報がデータに付与され、当該マーク情報を参照することで当該データの転送先が決定されることにより、データの種類（プロトコルの種類）に応じた検査を行うことが可能となる。

コネクション管理部３４は、データ取得部２１または応答データ取得部２５により取得されたデータについてのコネクション情報をコネクション管理テーブル３５、３６に格納する。具体的には、コネクション管理部３４は、取得されたデータについてのコネクションが、コネクション管理テーブル３５、３６に格納されていないコネクション（新たなコネクション）である場合に、当該コネクションを特定する情報（送信元ＩＰアドレス、送信元ポート番号、宛先ＩＰアドレス、宛先ポート番号、マーク）をコネクション管理テーブル３５、３６に格納する。なお、コネクション管理部３４は、サーバーのポート番号（取得したデータのＴＣＰヘッダにおける宛先ポート番号または送信元ポート番号）を参照することで、当該データのプロトコルを判定し、当該プロトコルに対応するマークをコネクション管理テーブル３５、３６のマーク情報の欄に格納する。

第一転送部２２は、経路設定部２３が設定したルールおよび第一経路テーブル３０に基づき、データ取得部２１が取得したデータを、フィルタコンテナ５０またはデータ送信部２４に転送する。第一転送部２２は、データ取得部２１により取得されたデータに付与されたマーク情報および当該データのＩＰヘッダにおける送信元ＩＰアドレスに基づき、前記ルールで指定された第一経路テーブル３０を参照する。これにより、第一転送部２２は、取得されたデータの転送先（転送先アドレス）を決定し、当該転送先へデータを転送する。なお、第一転送部２２により、通信検査装置２０における検査の対象でないと判断されたデータについては、フィルタコンテナ５０を経由することなくデータ送信部２４へ転送される。

経路設定部２３は、データの送信元または宛先であるクライアント９０毎（または複数のクライアント９０毎）に、当該クライアントが必要とする１つ以上の検査を実行するよう、各検査に対応するフィルタコンテナ５０を経由するデータの転送経路を決定する。経路設定部２３は、契約情報テーブル３２に基づき、クライアント毎に（各クライアントのプロトコル種類毎に）、データの転送経路を決定する。経路設定部２３は、決定された転送経路に基づき、第一経路テーブル３０、第二経路テーブル３１、および各フィルタコンテナ５０が有するコンテナ用経路テーブル５５を作成、更新する。

また、経路設定部２３は、データに付与されたマーク情報に基づき参照すべき経路テーブルを特定できるよう、当該マーク情報に対応する経路テーブルを指定するルールを設定する。また、経路設定部２３は、当該マーク情報およびクライアント情報に基づき参照すべき経路テーブルを特定できるよう、当該マーク情報およびクライアント情報に対応する経路テーブルを指定するルールを設定するようにしてもよい。なお、当該ルール（コマンドデータ）は、経路テーブルと同様に、記憶装置１４に記憶される。

さらに、経路設定部２３は、フィルタコンテナ５０における更新部５４により更新されたアプリケーションが実装されたフィルタコンテナ５０やコンテナ管理部２８により新たに構築された、更新後のアプリケーションが実装されたフィルタコンテナ５０を、前記データの転送経路に使用するフィルタコンテナとして設定する。

データ送信部２４（本願の発明の「データ送信手段」の一例である）は、クライアント９０から送信されたデータを、第一転送部２２またはフィルタコンテナ５０から受信し、宛先であるサーバー８０に送信する。

応答データ取得部２５（本願の発明の「データ取得手段」の一例である）は、ネットワークを流れるデータを、宛先に到達する前に取得する。例えば、本実施形態におけるサーバー８０から送信された応答データを、クライアント９０に到達する前に取得する。

また、応答データ取得部２５は、取得した応答データにプロトコルの種類により定められたマークを付与する。具体的には、応答データ取得部２５は、コネクション管理部３４によりコネクション管理テーブル３６に格納された、当該応答データに対応するコネクション情報を参照し、当該コネクション情報として格納されたマークと同一のマークを当該応答データに付与する。なお、この際、応答データ取得部２５は、取得した応答データに設定された送信元ＩＰアドレス、送信元ポート番号および宛先ＩＰアドレスに基づきコネクション管理テーブル３６を参照し、これらの情報が一致するコネクションを、当該応答データに対応するコネクションであると判定する。なお、応答データ取得部２５は、当該三つの情報に宛先ポート番号を加えた四つの情報に基づきコネクション管理テーブル３６を参照し、対応するコネクションを判定するようにしてもよい。マークの付与方法については、上述したデータ取得部２１の場合と同様である。

第二転送部２６は、経路設定部２３が設定したルールおよび第二経路テーブル３１に基づき、応答データ取得部２５が取得した応答データを、フィルタコンテナ５０または応答データ送信部２７に転送する。第二転送部２６は、応答データ取得部２５により取得された応答データに付与されたマーク情報および当該応答データのＩＰヘッダにおける宛先ＩＰアドレスに基づき、前記ルールで指定された第二経路テーブル３１を参照する。これにより、第二転送部２６は、取得された応答データの転送先（転送先アドレス）を決定し、当該転送先へ応答データを転送する。なお、第二転送部２６により、通信検査装置２０における検査の対象でないと判断された応答データについては、フィルタコンテナ５０を経由することなく応答データ送信部２７へ転送される。

応答データ送信部２７（本願の発明の「データ送信手段」の一例である）は、サーバー８０から送信された応答データを、第二転送部２６またはフィルタコンテナ５０から受信し、クライアント９０に送信する。

コンテナ管理部２８は、通信検査装置２０の管理者等の要求に応じて、コンテナ型の仮想端末であるコンテナを作成し、コンテナ内でアプリケーションを実行する。なお、コンテナ内ではアプリケーションが自動起動されるようにしてもよい。また、コンテナ管理部２８は、アプリケーションサーバーから、機能改善や不具合修正等が行われたことによるアプリケーションの更新通知および更新用データを受信し、当該アプリケーションについての更新処理を行う。コンテナ管理部２８は、アプリケーション内の少量モジュールについて更新が必要な場合、フィルタコンテナ５０に当該更新要求および更新用データを送信する。この際、コンテナ管理部２８は、当該アプリケーションに対応するセキュリティ検査項目について構築された（当該アプリケーションが実装された）複数のフィルタコンテナ５０のうち、稼働中でないフィルタコンテナを決定し、この決定されたコンテナに対して更新要求等を送信する。一方、コンテナ管理部２８は、アプリケーション内の大量モジュールについて更新が必要な場合、受信された更新用データを使用することで、更新に係るセキュリティ検査項目について更新前のアプリケーションで稼働中のフィルタコンテナとは別に、当該セキュリティ検査項目について更新後のアプリケーションが実装された稼働中でないフィルタコンテナを新たに構築する。なお、本実施形態において、「稼働中でないフィルタコンテナ」とは、データの転送（経路）に使用されていないフィルタコンテナである。

契約情報設定部２９は、クライアント９０のアドレス情報および当該クライアント９０が必要とする１以上の検査を示す契約情報を受信し、これらを関連付けて契約情報テーブル３２に記憶する。契約情報設定部２９は、固定ＩＰアドレスを有するクライアント９０の場合、当該クライアント９０から、または複数の当該クライアント９０を管理する管理者であるクライアント９０から、１以上の当該クライアント９０についてのＩＰアドレス（固定ＩＰアドレス）を受信する。また、契約情報設定部２９は、変動（動的）ＩＰアドレスを有するクライアント９０の場合、当該クライアント９０を管理するＶＰＮサーバーから、１以上の当該クライアント９０についてのＩＰアドレス（変動ＩＰアドレス）を受信する。なお、本実施形態では、クライアントの固定ＩＰアドレスを管理者であるクライアント等から受信し、クライアントの変動ＩＰアドレスをＶＰＮサーバーから受信するようにしたが、これに限るものではなく、インターネットを介して通信検査装置２０に接続する他の情報処理端末であってもよい。また、契約情報設定部２９は、クライアント９０または複数の当該クライアント９０を管理する管理者であるクライアント９０等から、契約情報を受信する。なお、契約情報設定部２９は、当該検査を行う対象となるデータのプロトコルの種類を示す情報を受信するようにしてもよい。

拒否処理部３３は、フィルタコンテナ５０により宛先へのデータの転送を拒否された場合に、当該データの送信元または宛先であるクライアント９０に対してデータ転送についての拒否処理を行う。拒否処理部３３は、例えば、ＩＰフィルタリングによりデータ転送が拒否された場合、クライアント９０との接続を拒否する（接続を切断する）。また、拒否処理部３３は、例えば、ＭＡＩＬフィルタリングによりデータ転送が拒否された場合、クライアント９０へデータ転送を拒否することを示すメール（エラーメール）を送信する。また、拒否処理部３３は、例えば、ＵＲＬフィルタリングやＨＴＴＰ（Ｓ）フィルタリングによりデータ転送が拒否された場合、ＨＴＴＰやＨＴＴＰ（Ｓ）のページ上で転送を拒否することを示すメッセージが表示されるよう、クライアント９０へ当該メッセージ（データ）を送信する。

フィルタコンテナ５０は、取得したデータについてセキュリティ検査を実行するためのアプリケーションが実装された、セキュリティ検査を実行するコンテナである。フィルタコンテナ５０は、取得したデータについてセキュリティ検査を実行し、当該データに設定された宛先へのデータ転送を許可してよいか否かを決定する。本実施形態では、セキュリティ検査の検査項目として、ＩＰフィルタリング、ＵＲＬフィルタリング、ＭＡＩＬフィルタリング、ＨＴＴＰ（Ｓ）フィルタリングを例示する。但し、本開示に係る検査において採用され得る具体的な検査項目や検査手法は、本実施形態における例示に限定されない。具体的な検査項目や検査手法には、既知の、または将来開発される様々な検査項目および検査手法が採用されてよい。

各種フィルタリングでは、取得したデータを宛先に通過させてよいか否かをフィルタ条件（検査条件）と照合することで判定し、宛先へのデータの転送を制限したり許可したりする（フィルタリングする）。ＩＰフィルタリングは、ＩＰ、ＴＣＰ、ＵＤＰ、ＩＣＭＰ等のヘッダ情報に基づいて、フィルタリングを行う（データの通過、拒否を制御する）機能である。これにより、例えば、特定のＩＰアドレスを宛先とするデータについては、データの転送を拒否することができる。ＵＲＬフィルタリングは、アクセス、閲覧できるインターネット上のＷｅｂサイトをフィルタリングするものであり、アクセス等を許可する（または拒否する）ＵＲＬのリスト（テーブル）と照合を行うことでフィルタリングを行う。ＭＡＩＬフィルタリングは、主にＳＰＡＭフィルタおよびウィルスフィルタであり、メールの中から、迷惑な広告などのメール（スパムメール、迷惑メール）やウィルス感染したメール等をフィルタリングする。ＨＴＴＰ（Ｓ）フィルタリングは、ＨＴＴＰ（Ｓ）通信に係るデータにウィルスが含まれているか否かをフィルタリングする機能であり、アプリケーションレベルで解析することにより、ＩＰフィルタリングおよびＵＲＬフィルタリングを併せて行うことができる。なお、応答データについては、クライアントからの要求に応じたコンテンツを送信するためのデータであるため、ＩＰフィルタリングおよびＵＲＬフィルタリングは不要である。

本実施形態では、セキュリティ検査項目毎にフィルタコンテナ５０が構築される。すなわち、各フィルタコンテナ５０は、１検査項目についての検査（１アプリケーション）のみを実行する。例えば、ＩＰフィルタリングを行うためのアプリケーションが実装されたコンテナ（ＩＰフィルタコンテナ）、ＵＲＬフィルタリングを行うためのアプリケーションが実装されたコンテナ（ＵＲＬフィルタコンテナ）、ＭＡＩＬフィルタリングを行うためのアプリケーションが実装されたコンテナ（ＭＡＩＬフィルタコンテナ）、ＨＴＴＰ（Ｓ）フィルタリングを行うためのアプリケーションが実装されたコンテナ（ＨＴＴＰ（Ｓ）フィルタコンテナ）、等のようにフィルタコンテナが構築される。但し、これに限られるものではなく、１つのフィルタコンテナに複数のアプリケーションが実装され、複数の検査項目に係る検査が実行されるようにしてもよい。

また、本実施形態では、セキュリティ検査項目毎に複数のフィルタコンテナ５０が構築される。換言すれば、同一のアプリケーションが実装されたフィルタコンテナ５０が複数構築される。例えば、ＩＰフィルタコンテナ＃１、ＩＰフィルタコンテナ＃２、ＭＡＩＬフィルタコンテナ＃１、ＭＡＩＬフィルタコンテナ＃２等のように、各フィルタコンテナを複数構築する。

データベースコンテナ６０は、セキュリティ検査（フィルタリング）に必要とされる、セキュリティに関するフィルタ条件（脅威情報等）が記憶されたデータベースを保持するコンテナである。データベースコンテナ６０は、取得したデータの検査対象となる部分がフィルタ条件に合致するか否かを判定する。本実施形態では、フィルタ条件が記憶されたデータベース（後述する「フィルタ条件データベース」に該当）として、ＩＰデータベース、ＵＲＬデータベース、ＳＰＡＭデータベース、ＶＩＲＵＳデータベースが例示される。

本実施形態では、フィルタ条件テータベースの種類毎にデータベースコンテナが構築される。すなわち、各データベースコンテナは、一種類のフィルタ条件データベースのみを備える。例えば、ＩＰデータベースを備えるＩＰデータベースコンテナ、ＵＲＬデータベースを備えるＵＲＬデータベースコンテナ、ＳＰＡＭデータベースを備えるＳＰＡＭデータベースコンテナ、ＶＩＲＵＳデータベースを備えるＶＩＲＵＳデータベースコンテナ、等のようにデータベースコンテナが構築される。但し、これに限定するものではなく、一つのデータベースコンテナが、複数種類のフィルタ条件データベースを備えていてもよい。なお、同一のフィルタ条件データベースを備えるデータベースコンテナを、複数構築するようにしてもよい。

[コンテナ]
図１０は、本実施形態に係るコンテナの機能構成の概略を示す図である。フィルタコンテナ５０は、記憶装置１４に記録されているプログラムが、ＲＡＭ１３に読み出され、ＣＰＵ１１によって実行されることで、転送データ受信部５１、検査部５２、転送部５３、更新部５４を備えるコンテナとして機能する。データベースコンテナ６０は、記憶装置１４に記録されているプログラムが、ＲＡＭ１３に読み出され、ＣＰＵ１１によって実行されることで、検査対象受信部６１、判定部６２、判定結果通知部６３、更新部６４を備えるコンテナとして機能する。なお、本実施形態では、フィルタコンテナ５０およびデータベースコンテナ６０の備える各機能は、汎用プロセッサであるＣＰＵ１１によって実行されるが、これらの機能の一部または全部は、１または複数の専用プロセッサによって実行されてもよい。

フィルタコンテナ５０は、コンテナ用経路テーブル５５を備えており、データベースコンテナ６０は、フィルタ条件データベース６５を備えており、各テーブルは記憶装置１４に記憶されている。

[フィルタコンテナ]
図１１は、本実施形態に係るＩＰフィルタコンテナ＃２のコンテナ用経路テーブル５５の構成を示す図である。図１２は、本実施形態に係るＭＡＩＬフィルタコンテナ＃１のコンテナ用経路テーブル５５の構成を示す図である。コンテナ用経路テーブル５５は、クライアント９０やサーバー８０から受信したデータの次転送先を決定するためにコンテナにおいて参照される情報を保持するテーブルである。コンテナ用経路テーブル５５の各列には、送信元ＩＰアドレス、宛先ＩＰアドレス、転送先アドレス等の項目が保持される。コンテナ用経路テーブル５５の「送信元ＩＰアドレス」は、クライアント９０からサーバー８０に送信されるデータを転送する場合に参照される項目であり、コンテナ用経路テーブル５５の「宛先ＩＰアドレス」は、サーバー８０からクライアント９０に送信される応答データを転送する場合に参照される項目である。なお、フィルタリングの種類（検査内容）によっては、サーバー８０からの応答データ（戻りパケット）については実施する必要のない検査があり、そのような検査に係るフィルタコンテナ５０においては、コンテナ用経路テーブル５５の「宛先ＩＰアドレス」の項目は設けなくてもよい。

例えば、図１１、図１２では、ＩＰフィルタコンテナとＭＡＩＬフィルタコンテナのコンテナ用経路テーブル５５を例示しているが、サーバー８０からの応答データについてはＩＰフィルタリングを行う必要がないため、ＩＰフィルタコンテナのコンテナ用経路テーブルには「宛先ＩＰアドレス」の項目を設けていない。なお、フィルタコンテナ５０においても、受信したデータのプロトコルにより次転送先を分岐させたい場合は、経路テーブルと同様に、コンテナ用経路テーブル５５に「マーク情報」や「ポート番号」の項目を含むようにしてもよい。また、本実施形態では、図１２に示すように、クライアント９０からのデータを転送する際に参照するレコード（データ）と、サーバー８０からの応答データを転送する際に参照するレコードの両者が同一の経路テーブルに含まれているが、これらを各々別の経路テーブルに格納するようにしてもよい。

転送データ受信部５１は、第一転送部２２、第二転送部２６、または他のフィルタコンテナ５０から転送されたデータを受信する。

検査部５２は、受信（取得）したデータについてセキュリティ検査項目についての検査を実行する。

さらに、検査部５２は、抽出部５２１、検査対象送信部５２２、判定結果受信部５２３、転送可否判定部５２４を備えている。

抽出部５２１は、取得したデータから、フィルタリング（検査）の設定項目に該当する部分である、検査対象となる部分を抽出する。例えば、ＩＰフィルタコンテナの場合、抽出部５２１は、ＩＰヘッダを抽出するようにしてもよい。なお、ＭＡＩＬフィルタコンテナのように複数のフィルタリング（検査）を必要とするフィルタコンテナの場合、抽出部５２１は、各検査について検査対象となる部分を抽出する。例えば、ＭＡＩＬフィルタコンテナの場合は、ＳＰＡＭフィルタリングおよびＶＩＲＵＳフィルタリングを行うため、抽出部５２１は、取得したデータから、これら各々の検査について、検査対象となる部分を抽出する。

検査対象送信部５２２は、抽出部５２１により抽出された、取得したデータ内の検査対象となる部分を、当該フィルタリングに使用されるフィルタ条件データベース６５を備えるデータベースコンテナ６０に送信する。なお、上述の通り、複数のフィルタリング（検査）を必要とするフィルタコンテナの場合、検査対象送信部５２２は、各検査について抽出された検査対象となる部分を、それぞれ対応するデータベースコンテナ６０へ送信する。

判定結果受信部５２３は、データ内の検査対象となる部分を受信したデータベースコンテナ６０の判定結果通知部６３（後述する）から、検査対象となる部分がフィルタ条件に合致するか否か判定された結果を受信する。なお、上述の通り、複数のフィルタリング（検査）を必要とするフィルタコンテナの場合、判定結果受信部５２３は、複数のデータベースコンテナ６０から、それぞれの検査に係る判定結果を受信する。

転送可否判定部５２４は、判定結果受信部５２３が受信した判定結果に基づき宛先への転送可否を判定する。転送可否判定部５２４は、例えば、ＩＰフィルタリングにより、取得したデータの宛先ＩＰアドレスが、データを通過させない（拒否する）フィルタ条件に該当するという判定結果を受信することで、取得したデータを宛先へ転送させないと判定する。なお、上述の通り、複数のフィルタリング（検査）を必要とするフィルタコンテナの場合、転送可否判定部５２４は、複数のデータベースコンテナ６０から送信された各判定結果に基づき、転送可否を判定する。例えば、複数の判定結果のうち一つでもデータを通過させないフィルタ条件に該当していると判定された結果が存在する場合、取得したデータを転送させないと判定する。

転送部５３は、転送可否判定部５２４により宛先への転送が許可されたデータを、コンテナ用経路テーブル５５を参照することで、次転送先へ転送する。転送部５３は、転送データ受信部５１により受信されたデータのＩＰヘッダにおける送信元ＩＰアドレスまたは宛先ＩＰアドレスに基づき、コンテナ用経路テーブル５５を参照する。これにより、転送部５３は、クライアント９０やサーバー８０から取得されたデータの転送先を決定し、当該転送先へデータを転送する。

更新部５４は、コンテナ管理部２８からアプリケーションの更新要求および更新用データを受信し、フィルタコンテナ５０が備える、検査を実行するための当該アプリケーションを更新する。更新部５４は、アプリケーションの更新が完了すると、コンテナ管理部２８へ更新完了通知を送信する。

[データベースコンテナ]
フィルタ条件（検査条件）データベース６５には、セキュリティ検査項目についての検査に使用されるフィルタ条件（セキュリティに関するフィルタ条件）が保持されている。フィルタ条件データベース６５には、フィルタリングを行う際の、データの転送を許可または拒否するためのフィルタ条件が保持される。フィルタ条件データベース６５は、フィルタ条件として、フィルタリングする項目（パラメータ）、その具体的な値等、およびデータ通過の許可または拒否等のフィルタ種別を保持することができる。例えば、ＩＰデータベースコンテナの有するフィルタ条件データベース６５では、フィルタ条件として、パラメータである宛先ＩＰアドレスが「１０．１．１．１」である場合にデータ転送を「拒否」するという条件が保持される。

検査対象受信部６１は、検査対象送信部５２２から、データ内の検査対象となる部分を受信する。

判定部６２は、検査対象受信部６１が取得した、データ内の検査対象となる部分が、フィルタ条件データベースに保持されたフィルタ条件に合致するか否かを判定する。例えば、ＩＰデータベースコンテナの判定部６２は、フィルタ条件が、宛先ＩＰアドレスが「１０．１．１．１」である場合にデータ転送を「拒否」するものである場合、検査対象受信部６１が取得した、データ内の検査対象となる部分に含まれる宛先ＩＰアドレスが、当該アドレスに合致するか否かを判定する。

判定結果通知部６３は、判定部６２により判定された、データ内の検査対象となる部分がフィルタ条件に合致したか否かを示す判定結果についての情報を、判定結果受信部５２３に送信する。

更新部６４は、データベースコンテナ６０が備えるフィルタ条件データベース６５および当該フィルタ条件データベースの管理を行うアプリケーション等の更新を行う。更新部６４は、コンテナ管理部２８からフィルタ条件データベース６５や当該データベースを管理するアプリケーションの更新要求および更新用データを受信し、当該フィルタ条件データベース６５や当該アプリケーションを更新する。更新部６４は、当該更新処理が完了すると、コンテナ管理部２８へ更新完了通知を送信する。

なお、本実施形態では、フィルタコンテナ５０とは別にデータベースコンテナ６０を構築することで、検査を行うアプリケーションを備える環境とデータベースを備える環境とを分離している。これより、検査を行うアプリケーションおよびデータベースをそれぞれ独立化することができ、それぞれを更新する際の他への影響を低減させている。但し、本開示に係る通信検査装置２０は、データベースコンテナ６０を独立して構築するものに限定されず、フィルタコンテナ５０や通信検査装置２０（コンテナ外）においてデータベースを備えるようにしてもよい。

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

図１３から図１５は、本実施形態に係るパケット処理の流れの概要を示すフローチャートである。本実施形態では、ＩＰフィルタリングおよびＭＡＩＬフィルタリングの検査を必要とするクライアント９０（ＩＰアドレスが「１９２．１６８．１．２」）からの、ＭＡＩＬに関連するパケットの処理を例示する。本実施形態に係るパケット処理は、通信検査装置２０によって、ネットワーク上を流れるクライアント９０からのパケット（例えば、ＴＣＰパケット）が受信されたことを契機として実行される。

ステップＳ１０１では、パケット（データ）を受信し、当該パケットに係るコネクションの管理およびパケットへのマーク付与が行われる。データ取得部２１が、クライアント９０からパケットを受信すると、コネクション管理部３４は、受信したパケットに係るコネクションがコネクション管理テーブル３５に格納されているか否かを確認する。具体的には、パケットに設定された送信元ＩＰアドレス、送信元ポート番号、宛先ＩＰアドレスおよび宛先ポート番号に基づき、コネクション管理テーブル３５を参照することにより、当該パケットに係るコネクションの格納有無を確認する。

当該パケットに係るコネクションが格納されていない場合（初めてのコネクションの場合）、コネクション管理部３４は、当該コネクションに関するコネクション情報をコネクション管理テーブル３５に格納する。この際、コネクション管理部３４は、受信パケットの宛先ポート番号を参照することで当該パケットのプロトコルを判定し、判定されたプロトコルの種類に対応するマーク情報を格納する。データ取得部２１は、パケットに設定された送信元ＩＰアドレス、宛先ＩＰアドレスおよび宛先ポート番号に基づき、コネクション管理テーブル３５を参照することで、当該パケットに対応するコネクションに付与されたマークと同一のマークをパケットに付与する。本実施形態では、クライアント９０からのパケットに係るコネクションについての情報が格納されるが（図６参照）、この際、当該パケットのプロトコル（ＭＡＩＬ関連）に基づくマーク情報としてマーク「２」が格納され、且つ取得されたデータに対してマーク「２」が付与される。その後、処理はステップＳ１０２へ進む。

ステップＳ１０２では、データの次転送先が決定される。第一転送部２２は、ステップＳ１０１で取得されたデータに付与されたマーク情報「２」および送信元ＩＰアドレス「１９２．１６８．１．２」に基づき、第一経路テーブル３０を参照することで、当該データの転送先を、「１７２．１６．１２９．１２（ＩＰフィルタコンテナ＃２）」と決定する。具体的には、経路設定部２３により設定された、送信元ＩＰアドレス「１９２．１６８．１．２」からのマーク情報「２」に係るデータは、第一経路テーブル＃１（図７）を参照することとのルールに基づき、第一転送部２２は、図７に示す第一経路テーブルを参照することで次転送先を決定する。その後、処理はステップＳ１０３へ進む。

ステップＳ１０３では、データが次転送先に転送される。第一転送部２２は、ステップＳ１０１で取得されたデータを、ステップＳ１０２で決定された転送先へ転送する。本実施形態では、取得されたデータがＩＰフィルタコンテナ＃２へ転送される。その後、処理はステップＳ１０４へ進む。

ステップＳ１０４では、ＩＰフィルタコンテナ＃２において、転送されたデータが受信される。転送データ受信部５１は、ステップＳ１０３で転送された、クライアント９０からのデータを受信する。その後、処理はステップＳ１０５へ進む。

ステップＳ１０５では、ＩＰフィルタコンテナ＃２において、検査対象となる部分のデータが抽出される。抽出部５２１は、例えば、ステップＳ１０４で受信されたデータから、ＩＰフィルタリングの対象となるＩＰヘッダを抽出する。その後、処理はステップＳ１０６へ進む。

ステップＳ１０６では、抽出された検査対象となる部分が、ＩＰデータベースコンテナ６０に送信される。検査対象送信部５２２は、ステップＳ１０５で抽出された検査対象となる部分（ＩＰヘッダ）を、ＩＰフィルタリングに使用されるフィルタ条件データベース６５を備えるＩＰデータベースコンテナ６０に送信する。その後、処理はステップＳ１０７へ進む。

ステップＳ１０７では、ＩＰデータベースコンテナ６０において、検査対象となる部分が受信される。検査対象受信部６１は、ステップＳ１０６で送信された、検査対象となる部分を受信する。その後、処理はステップＳ１０８へ進む。

ステップＳ１０８では、ＩＰデータベースコンテナ６０において、検査対象となる部分がフィルタ条件に合致するか否か判定される。判定部６２は、ステップＳ１０７で受信された検査対象となる部分が、フィルタ条件データベース６５に保持されたフィルタ条件に合致するか否かを判定する。その後、処理はステップＳ１０９へ進む。

ステップＳ１０９では、判定結果がＩＰフィルタコンテナ＃２に通知（送信）される。判定結果通知部６３は、ステップＳ１０８で判定された判定結果をＩＰフィルタコンテナ＃２に送信する。その後、処理はステップＳ１１０へ進む。

ステップＳ１１０では、ＩＰフィルタコンテナ＃２において、判定結果が受信される。判定結果受信部５２３は、ステップＳ１０９で送信された判定結果を受信する。その後、処理はステップＳ１１１へ進む。

ステップＳ１１１では、ＩＰフィルタコンテナ＃２において、判定結果に基づき宛先へのデータ転送可否が判定される。ステップＳ１１０で受信された判定結果に基づき、転送可否判定部５２４が、クライアント９０から送信されたデータの宛先への転送を許可できないと判定した場合、データ転送を拒否することを示す拒否通知が通信検査装置２０に送信され、処理はステップＳ１１２へ進む。一方、転送可否判定部５２４が、クライアント９０から送信されたデータの宛先への転送を許可してよいと判定した場合、処理はステップＳ１１３へ進む。

ステップＳ１１２では、データの転送についての拒否処理が行われる。実施形態では、拒否処理部３３は、クライアント９０との通信（接続）を切断する。その後、本フローチャートに示された処理は終了する。

ステップＳ１１３では、宛先への転送が許可されたデータの次転送先が決定される。転送部５３は、ステップＳ１０４で取得されたデータの送信元ＩＰアドレス「１９２．１６８．１．２」に基づき、コンテナ用経路テーブル５５を参照することで、当該データの転送先を、「１７２．１６．１２９．１３（ＭＡＩＬフィルタコンテナ＃１）」と決定する。その後、処理はステップＳ１１４へ進む。

ステップＳ１１４では、データが次転送先に転送される。転送部５３は、ステップＳ１０４で取得されたデータを、ステップＳ１１３で決定された転送先へ転送する。本実施形態では、ＩＰフィルタコンテナ＃２における転送部５３が、取得されたデータをＭＡＩＬフィルタコンテナ＃１へ転送する。その後、処理はステップＳ１１５へ進む。

ステップＳ１１５では、ＭＡＩＬフィルタコンテナ＃１において、ＩＰフィルタコンテナ＃２から転送されたデータが受信される。転送データ受信部５１は、ステップＳ１１４で転送された、クライアント９０からのデータを受信する。その後、処理はステップＳ１１６へ進む。

ステップＳ１１６では、ＭＡＩＬフィルタコンテナ＃１において、検査対象となる部分のデータが抽出される。抽出部５２１は、例えば、ステップＳ１１５で受信されたデータから、ＭＡＩＬフィルタリングであるＳＰＡＭフィルタリングおよびＶＩＲＵＳフィルタリングの各々について、検査対象となる部分を抽出する。なお、クライアント９０からの受信データのプロトコルがＭＡＩＬ送信プロトコルの場合は、ステップＳ１１６〜Ｓ１１２３におけるＭＡＩＬフィルタリング（ＳＰＡＭフィルタリングおよびＶＩＲＵＳフィルタリング）が行われ、ＭＡＩＬ受信プロトコルの場合は、当該受信データがメール受信要求に係るデータであるため、当該ＭＡＩＬフィルタリングが行われないよう設定されてもよい。その後、処理はステップＳ１１７へ進む。

ステップＳ１１７では、抽出された検査対象となる部分がそれぞれ、ＳＰＡＭデータベースコンテナおよびＶＩＲＵＳデータベースコンテナに送信される。検査対象送信部５２２は、ステップＳ１１６で抽出された、ＳＰＡＭフィルタリングおよびＶＩＲＵＳフィルタリングの各々についての検査対象となる部分を、ＭＡＩＬフィルタリングに使用されるフィルタ条件データベース６５を備えるＳＰＡＭデータベースコンテナおよびＶＩＲＵＳデータベースコンテナに送信する。その後、処理はステップＳ１１８へ進む。なお、図１４には、ステップＳ１１７〜Ｓ１２１において、ＭＡＩＬフィルタコンテナとＳＰＡＭデータベースコンテナとの間で行われるデータ処理のみを示しているが、ＭＡＩＬフィルタコンテナとＶＩＲＵＳデータベースコンテナとの間においても、ステップＳ１１７〜Ｓ１２１と同様の処理が行われる。ＭＡＩＬフィルタコンテナとＶＩＲＵＳデータベースコンテナとの間で行われるデータ処理は、ステップＳ１１７〜Ｓ１２１と同様の処理であるため、説明を省略する。

ステップＳ１１８では、ＭＡＩＬデータベースコンテナ６０において、検査対象となる部分が受信される。検査対象受信部６１は、ステップＳ１１７で送信された、検査対象となる部分を受信する。その後、処理はステップＳ１１９へ進む。

ステップＳ１１９では、ＳＰＡＭデータベースコンテナ６０において、検査対象となる部分がフィルタ条件に合致するか否か判定される。判定部６２は、ステップＳ１１８で受信された検査対象となる部分が、フィルタ条件データベース６５に保持されたフィルタ条件に合致するか否かを判定する。その後、処理はステップＳ１２０へ進む。

ステップＳ１２０では、判定結果がＭＡＩＬフィルタコンテナ＃１に通知（送信）される。判定結果通知部６３は、ステップＳ１１９で判定された判定結果をＭＡＩＬフィルタコンテナ＃１に送信する。その後、処理はステップＳ１２１へ進む。

ステップＳ１２１では、ＭＡＩＬフィルタコンテナ＃１において、判定結果が受信される。判定結果受信部５２３は、ステップＳ１２０で送信された判定結果を受信する。その後、処理はステップＳ１２２へ進む。

ステップＳ１２２では、ＭＡＩＬフィルタコンテナ＃１において、判定結果に基づき宛先へのデータ転送可否が判定される。ステップＳ１２１で受信された判定結果に基づき、転送可否判定部５２４が、クライアント９０から送信されたデータの宛先への転送を許可できないと判定した場合、データ転送を拒否することを示す拒否通知が通信検査装置２０に送信され、処理はステップＳ１２３へ進む。一方、転送可否判定部５２４が、クライアント９０から送信されたデータの宛先への転送を許可してよいと判定した場合、処理はステップＳ１２４へ進む。

ステップＳ１２３では、データの転送についての拒否処理が行われる。実施形態では、拒否処理部３３は、クライアント９０へデータ転送を拒否することを示すメールを送信する。その後、本フローチャートに示された処理は終了する。

ステップＳ１２４では、宛先への転送が許可されたデータの次転送先が決定される。転送部５３は、ステップＳ１１５で取得されたデータの送信元ＩＰアドレス「１９２．１６８．１．２」に基づき、コンテナ用経路テーブル５５を参照することで、当該データの転送先を、「１７２．１６．１２９．１００（通信検査装置（データ送信部２４））」と決定する。その後、処理はステップＳ１２５へ進む。

ステップＳ１２５では、データが次転送先に転送される。転送部５３は、ステップＳ１１５で取得されたデータを、ステップＳ１２４で決定された転送先へ転送する。本実施形態では、転送部５３が、取得されたデータをデータ送信部２４へ転送する。その後、処理はステップＳ１２６へ進む。

ステップＳ１２６では、ＭＡＩＬフィルタコンテナ＃１から転送されたデータが受信される。データ送信部２４は、ステップＳ１２５で転送された、クライアント９０からのデータを受信する。その後、処理はステップＳ１２７へ進む。

ステップＳ１２７では、データが宛先へ転送される。データ送信部２４は、ステップＳ１２６で受信したデータを、宛先であるサーバー８０へ転送する。その後、本フローチャートに示された処理は終了する。上述した方法により、クライアント９０からのデータのうち、当該クライアント９０が必要とする全ての検査を完了し、当該検査で転送許可と判定されたデータのみを、サーバー８０に送信することが出来る。

また、上述した方法により、各アプリケーションを独立化させることが可能となり、アプリケーションの更新の際、他のコンテナ内のアプリケーションや通信検査装置（コンテナ外）内のアプリケーション等に対する影響を抑えることが出来るため、従来の通信検査装置における検査と比較して、検査の継続性を高めることが出来る。また、検査がコンテナ型の仮想端末で実行されることにより、従来の仮想マシンと比較し、アプリケーションの更新等の際に必要となる仮想環境の停止や起動を高速で行うことができるため、従来の通信検査装置や仮想マシン上で検査が行われる場合と比較して、検査の継続性を高めることが出来る。

なお、図１３から図１５では、クライアント９０の要する検査項目（契約情報）が、ＩＰフィルタリングおよびＭＡＩＬフィルタリングである場合について例示したが、他の契約状況（他のフィルタリングの組み合わせ）の場合も同様に、フィルタコンテナを経由することで当該コンテナにおいて検査が実行される。例えば、図９の契約情報テーブル３２の第１レコード（ユーザ１、ＩＰ）に示される通り、ユーザ１から受信されたデータ（ＩＰパケット）は全て、ＩＰフィルタコンテナを経由し転送される。また、図９の契約情報テーブル３２の第３レコード（ユーザ３、ＩＰとＵＲＬ）に示される通り、ユーザ３から受信されたデータ（ＩＰパケット）は全てＩＰフィルタコンテナに転送され、その後、当該データのうちＨＴＴＰ等関連のデータについては更にＵＲＬフィルタコンテナに転送される。また、図９の契約情報テーブル３２の第４レコード（ユーザ４、ＩＰとＵＲＬとＨＴＴＰＳ）に示される通り、ユーザ４から受信されたデータ（ＩＰパケット）のうち、ＨＴＴＰＳ関連のデータについてはＨＴＴＰＳフィルタコンテナに転送され、その他のデータについてはＩＰフィルタコンテナに転送される。

また、本実施形態のように、同一クライアントからのデータであっても、当該データのプロトコルの種類に応じて、転送先のフィルタコンテナを変えるようにしてもよい。例えば、ユーザ２から受信されたＭＡＩＬに関するデータについては、ＩＰフィルタコンテナ＃２へ、ユーザ２から受信されたデータのうちＭＡＩＬに関するデータ以外のデータについては、ＩＰフィルタコンテナ＃１へ転送されるようにしてもよい。なお、本実施形態では、複数のクライアント９０が、同一のフィルタコンテナやデータベースコンテナを使用することとしたが、これに限るものではなく、通信検査装置２０が、クライアント９０専用または複数のクライアント９０からなるグループ専用のフィルタコンテナやデータベースコンテナを備えるようにしてもよい。

また、本実施形態では、受信パケットのプロトコル種類に応じたマーク情報が当該パケットに付与され、当該マーク情報およびルールに基づき、当該パケットについて参照すべき経路テーブルが決定され、当該パケットの次転送先が決定される。そのため、経路テーブルおよびコンテナ用経路テーブルにおいてプロトコル情報（ポート番号やマーク情報等）は格納されていない。しかし、本開示の実施の態様はこれに限定されるものではなく、他の実施形態として、受信パケットにプロトコル種類に応じたマーク情報が付与されず、経路テーブルやコンテナ用経路テーブルにプロトコル情報が格納され、当該パケットの宛先ポート番号等と照合することで、当該パケットの次転送先が決定されるようにしてもよい。また、他の実施形態として、本実施形態と同様、受信パケットにプロトコル種類に応じたマーク情報が付与されるものの、ルールの設定は行わず、経路テーブルやコンテナ用経路テーブルにマーク情報を格納することで、当該経路テーブルのマーク情報と当該パケットに付与されたマーク情報を照合することで、次転送先が決定されるようにしてもよい。

図１６および図１７は、本実施形態に係る応答パケット処理の流れの概要を示すフローチャートである。本実施形態では、ＩＰフィルタリングおよびＭＡＩＬフィルタリングの検査を必要とするクライアント９０（ＩＰアドレスが「１９２．１６８．１．２」）からの、ＭＡＩＬに関連するデータに対するサーバー８０からの応答データ（応答パケット）の処理を例示する。本実施形態に係るパケット処理は、通信検査装置２０によって、ネットワーク上を流れるサーバー８０からの応答パケットが受信されたことを契機として実行される。

ステップＳ２０１では、応答パケットを受信し、当該パケットに係るコネクションの管理およびパケットへのマーク付与が行われる。応答データ取得部２５が、サーバー８０からクライアント９０への応答パケットを受信すると、コネクション管理部３４は、受信したパケットに係るコネクションがコネクション管理テーブル３６に格納されているか否かを確認する。当該パケットに係るコネクションが格納されていない場合（初めてのコネクションの場合）、コネクション管理部３４は、当該コネクションに関するコネクション情報をコネクション管理テーブル３６に格納する。この際、コネクション管理部３４は、受信パケットの送信元ポート番号を参照することで当該パケットのプロトコルを判定し、判定されたプロトコルの種類に対応するマーク情報を格納する。応答データ取得部２５は、パケットに設定された送信元ＩＰアドレス、送信元ポート番号および宛先ＩＰアドレスに基づき、コネクション管理テーブル３６を参照することで、当該パケットに対応するコネクションに付与されたマークと同一のマークをパケットに付与する。本実施形態では、サーバー８０からのパケットに係るコネクションについての情報が格納されるが、この際、当該パケットのプロトコル（ＭＡＩＬ関連）に基づくマーク情報としてマーク「２」が格納され、且つ取得されたデータに対してマーク２が付与される。その後、処理はステップＳ２０２へ進む。

ステップＳ２０２では、データの次転送先が決定される。第二転送部２６は、ステップＳ２０１で取得された応答データに付与されたマーク情報「２」および宛先ＩＰアドレス「１９２．１６８．１．２」に基づき、第二経路テーブル３１を参照することで、当該応答データの転送先を、「１７２．１６．１２９．１３（ＭＡＩＬフィルタコンテナ＃１）」と決定する。具体的には、経路設定部２３により設定された、宛先ＩＰアドレス「１９２．１６８．１．２」のマーク情報「２」に係るデータは、第二経路テーブル＃１（図８）を参照することとのルールに基づき、第二転送部２６は、図８に示す第二経路テーブルを参照することで次転送先を決定する。その後、処理はステップＳ２０３へ進む。

ステップＳ２０３では、応答データが次転送先に転送される。第二転送部２６は、ステップＳ２０１で取得されたデータを、ステップＳ２０２で決定された転送先へ転送する。本実施形態では、取得されたデータをＭＡＩＬフィルタコンテナ＃１へ転送する。その後、処理はステップＳ２０４へ進む。

ステップＳ２０４では、ＭＡＩＬフィルタコンテナ＃１において、転送されたデータが受信される。転送データ受信部５１は、ステップＳ２０３で転送された、サーバー８０からの応答データを受信する。その後、処理はステップＳ２０５へ進む。

ステップＳ２０５では、ＭＡＩＬフィルタコンテナ＃１において、検査対象となる部分のデータが抽出される。抽出部５２１は、例えば、ステップＳ２０４で受信されたデータから、ＭＡＩＬフィルタリングであるＳＰＡＭフィルタリングおよびＶＩＲＵＳフィルタリングの各々について、検査対象となる部分を抽出する。なお、サーバー８０からの応答データのプロトコルがＭＡＩＬ受信プロトコルの場合は、ステップＳ２０５〜Ｓ２１２におけるＭＡＩＬフィルタリング（ＳＰＡＭフィルタリングおよびＶＩＲＵＳフィルタリング）が行われ、ＭＡＩＬ送信プロトコルの場合は、当該応答データがメール送信データに対する応答データであるため、当該ＭＡＩＬフィルタリングが行われないよう設定されてもよい。その後、処理はステップＳ２０６へ進む。

ステップＳ２０６では、抽出された検査対象となる部分がそれぞれ、ＳＰＡＭデータベースコンテナおよびＶＩＲＵＳデータベースコンテナに送信される。検査対象送信部５２２は、ステップＳ２０５で抽出された、ＳＰＡＭフィルタリングおよびＶＩＲＵＳフィルタリングの各々についての検査対象となる部分を、ＭＡＩＬフィルタリングに使用されるフィルタ条件データベース６５を備えるＳＰＡＭデータベースコンテナおよびＶＩＲＵＳデータベースコンテナに送信する。その後、処理はステップＳ２０７へ進む。なお、図１６には、ステップＳ２０６〜Ｓ２１０において、ＭＡＩＬフィルタコンテナとＳＰＡＭデータベースコンテナとの間で行われるデータ処理のみを示しているが、ＭＡＩＬフィルタコンテナとＶＩＲＵＳデータベースコンテナとの間においても、ステップＳ２０６〜Ｓ２１０と同様の処理が行われる。ＭＡＩＬフィルタコンテナとＶＩＲＵＳデータベースコンテナとの間で行われるデータ処理は、ステップＳ２０６〜Ｓ２１０と同様の処理であるため、説明を省略する。

ステップＳ２０７では、ＭＡＩＬデータベースコンテナ６０において、検査対象となる部分が受信される。検査対象受信部６１は、ステップＳ２０６で送信された、検査対象となる部分を受信する。その後、処理はステップＳ２０８へ進む。

ステップＳ２０８では、ＳＰＡＭデータベースコンテナ６０において、検査対象となる部分がフィルタ条件に合致するか否か判定される。判定部６２は、ステップＳ２０７で受信された検査対象となる部分が、フィルタ条件データベース６５に保持されたフィルタ条件に合致するか否かを判定する。その後、処理はステップＳ２０９へ進む。

ステップＳ２０９では、判定結果がＭＡＩＬフィルタコンテナ＃１に通知（送信）される。判定結果通知部６３は、ステップＳ２０８で判定された判定結果をＭＡＩＬフィルタコンテナ＃１に送信する。その後、処理はステップＳ２１０へ進む。

ステップＳ２１０では、ＭＡＩＬフィルタコンテナ＃１において、判定結果が受信される。判定結果受信部５２３は、ステップＳ２０９で送信された判定結果を受信する。その後、処理はステップＳ２１１へ進む。

ステップＳ２１１では、ＭＡＩＬフィルタコンテナ＃１において、判定結果に基づき宛先へのデータ転送可否が判定される。ステップＳ２１０で受信された判定結果に基づき、転送可否判定部５２４が、サーバー８０から送信された応答データのクライアント９０への転送を許可できないと判定した場合、データ転送を拒否することを示す拒否通知が通信検査装置２０に送信され、処理はステップＳ２１２へ進む。一方、転送可否判定部５２４が、サーバー８０から送信された応答データのクライアント９０への転送を許可してよいと判定した場合、処理はステップＳ２１３へ進む。

ステップＳ２１２では、データの転送についての拒否処理が行われる。実施形態では、拒否処理部３３は、クライアント９０へデータ転送を拒否することを示すメールを送信する。その後、本フローチャートに示された処理は終了する。

ステップＳ２１３では、クライアント９０への転送が許可された応答データの次転送先が決定される。転送部５３は、ステップＳ２０４で取得された応答データの宛先ＩＰアドレス「１９２．１６８．１．２」に基づき、コンテナ用経路テーブル５５を参照することで、当該応答データの転送先を、「１７２．１６．１２９．１（通信検査装置（応答データ送信部２７））」と決定する。その後、処理はステップＳ２１４へ進む。

ステップＳ２１４では、応答データが次転送先に転送される。転送部５３は、ステップＳ２０４で取得された応答データを、ステップＳ２１３で決定された転送先へ転送する。本実施形態では、転送部５３が、取得された応答データを応答データ送信部２７へ転送する。その後、処理はステップＳ２１５へ進む。

ステップＳ２１５では、ＭＡＩＬフィルタコンテナ＃１から転送されたデータが受信される。応答データ送信部２７は、ステップＳ２１４で転送された、サーバー８０からの応答データを受信する。その後、処理はステップＳ２１６へ進む。

ステップＳ２１６では、応答データがクライアント９０に転送される。応答データ送信部２７は、ステップＳ２１５で受信したデータを、クライアント９０へ転送する。その後、本フローチャートに示された処理は終了する。上述した方法により、クライアント９０からのデータに対応する応答データのうち、当該クライアント９０が必要とする全ての検査を完了し、当該検査で転送許可と判定された応答データのみを、クライアント９０に送信することが出来る。

図１６および図１７では、クライアント９０の要する検査項目（契約情報）が、ＩＰフィルタリングおよびＭＡＩＬフィルタリングである場合について例示したが、他の契約状況の場合も同様に、フィルタコンテナを経由することで当該コンテナにおいて検査が実行される。例えば、図９の契約情報テーブル３２の第４レコード（ユーザ４、ＩＰとＵＲＬとＨＴＴＰＳ）に示される通り、ユーザ４からのコンテンツ要求に対応する応答データ（ＩＰパケット）のうち、ＨＴＴＰＳ関連の応答データについてはＨＴＴＰＳフィルタコンテナに転送され、ＶＩＲＵＳデータベース等に基づき検査が実行される。

図１８は、本実施形態に係るアプリケーション更新（少量モジュールの更新）処理の流れの概要を示すフローチャートである。本実施形態では、ＭＡＩＬフィルタリングに係るアプリケーション内の少量のモジュールについて更新処理が必要な場合を例示する。本実施形態に係るパケット処理は、通信検査装置２０によって、ＭＡＩＬフィルタリングに係るアプリケーションサーバーからのアプリケーションの更新通知および更新用データが受信されたことを契機として実行される。

ステップＳ３０１では、更新通知および更新用データが受信される。コンテナ管理部２８は、アプリケーションサーバーから、ＭＡＩＬフィルタリングに係るアプリケーション（少量モジュール）の更新について、更新通知および更新用データを受信する。その後、処理はステップＳ３０２へ進む。

ステップＳ３０２では、稼働中でないコンテナが決定される。コンテナ管理部２８は、ステップＳ３０２で受信された更新通知に係るアプリケーションが実装された複数のＭＡＩＬフィルタコンテナのうち、稼働中でないコンテナ（ＭＡＩＬフィルタコンテナ＃２）を決定する。コンテナ管理部２８は、例えば、経路設定部２３により、経路テーブル３０、３１およびコンテナ用経路テーブル５５に、データの転送経路として使用するよう設定されていないＭＡＩＬフィルタコンテナを抽出することで、稼働中でないコンテナを決定してもよい。その後、処理はステップＳ３０３へ進む。

ステップＳ３０３では、フィルタコンテナ５０に更新要求および更新用データが送信される。コンテナ管理部２８は、ステップＳ３０２で決定された稼働中でないフィルタコンテナであるＭＡＩＬフィルタコンテナ＃２へ、ステップＳ３０１で受信された更新通知および更新用データを送信する。その後、処理はステップＳ３０４へ進む。

ステップＳ３０４では、ＭＡＩＬフィルタコンテナ＃２において、更新要求および更新用データを受信する。更新部５４は、ステップＳ３０３で送信された更新要求および更新用データを受信する。その後、処理はステップＳ３０５へ進む。

ステップＳ３０５では、ＭＡＩＬフィルタコンテナ＃２において、アプリケーションが更新される。更新部５４は、ステップＳ３０４で受信した更新用データを使用することにより、ＭＡＩＬフィルタリングに係るアプリケーションを更新する。当該更新処理に伴い、フィルタコンテナの起動、停止が必要な場合は、起動、停止処理をアプリケーションの更新と併せて行うようにしてもよい。その後、処理はステップＳ３０６へ進む。

ステップＳ３０６では、アプリケーションの更新完了通知が送信される。更新部５４は、ＭＡＩＬフィルタリングに係るアプリケーションの更新処理が完了した後、通信検査装置２０へ更新完了通知を行う。その後、処理はステップＳ３０７へ進む。

ステップＳ３０７では、通信検査装置２０において、アプリケーションの更新完了通知が受信される。コンテナ管理部２８は、ステップＳ３０６で送信された更新完了通知を受信する。その後、処理はステップＳ３０８へ進む。

ステップＳ３０８では、データ転送（経路）に使用されるフィルタコンテナとして、アプリケーションの更新が完了したフィルタコンテナが設定される。コンテナ管理部２８は、経路テーブルおよびコンテナ用経路テーブルを更新することで、データ転送に使用されるＭＡＩＬフィルタコンテナを、稼働中のＭＡＩＬフィルタコンテナ＃１から、アプリケーションの更新が完了したＭＡＩＬフィルタコンテナ＃２に切り替える。その後、本フローチャートに示された処理は終了する。

このように、アプリケーション内の少量のモジュールについて更新が必要な場合は、通信検査装置２０からの更新要求に従い、当該アプリケーションが実装された稼働中でないフィルタコンテナ５０において当該アプリケーションの更新処理が行われる。

上述した方法により、アプリケーションの更新の際に稼働中のコンテナを長時間停止する必要がなく、データの転送経路に使用されるコンテナを、現在稼働中のコンテナから、更新後のアプリケーションが実装されたコンテナに切り替えるだけで、当該転送経路に使用されるコンテナにおけるアプリケーションの更新処理を完了させることができる。換言すれば、アプリケーションの更新に伴う仮想端末の再起動等が不要となるため、当該アプリケーションを使用することができない時間が大幅に削減され、検査の継続性を高めることが出来る。

なお、図１８では、フィルタコンテナ５０におけるアプリケーションの更新処理について例示したが、データベースコンテナ６０における更新処理についても、当該フィルタコンテナの場合と同様の流れにより行われる。具体的には、データベースコンテナ６０が備える更新部６４が、コンテナ管理部２８から、フィルタ条件データベース６５や当該データベースを管理するアプリケーションについての更新要求および更新用データを受信することで、フィルタ条件データベース６５や当該アプリケーションを更新する。

図１９は、本実施形態に係るアプリケーション更新（大量モジュールの更新）処理の流れの概要を示すフローチャートである。本実施形態では、ＭＡＩＬフィルタリングに係るアプリケーション内の大量のモジュールについて更新処理が必要な場合を例示する。本実施形態に係るパケット処理は、通信検査装置２０によって、ＭＡＩＬフィルタリングに係るアプリケーションサーバーからのアプリケーションの更新通知および更新用データが受信されたことを契機として実行される。

ステップＳ４０１では、更新通知および更新用データが受信される。コンテナ管理部２８は、アプリケーションサーバーから、ＭＡＩＬフィルタリングに係るアプリケーション（大量モジュール）の更新について、更新通知および更新用データを受信する。その後、処理はステップＳ４０２へ進む。

ステップＳ４０２では、更新後のアプリケーションが実装されたフィルタコンテナが新たに構築（作成）される。本実施形態では、コンテナ管理部２８は、ステップＳ４０１で受信された更新用データを使用することにより、更新前のアプリケーションで稼働中のＭＡＩＬフィルタコンテナ＃１とは別に、更新後のアプリケーションが実装されたＭＡＩＬフィルタコンテナ＃２を新たに構築する。その後、処理はステップＳ４０３へ進む。

ステップＳ４０３では、データ転送（経路）に使用されるフィルタコンテナとして、アプリケーションの更新が完了したフィルタコンテナが設定される。コンテナ管理部２８は、経路テーブルおよびコンテナ用経路テーブルを更新することで、データ転送に使用されるＭＡＩＬフィルタコンテナを、稼働中のＭＡＩＬフィルタコンテナ＃１から、アプリケーションの更新が完了したＭＡＩＬフィルタコンテナ＃２に切り替える。その後、本フローチャートに示された処理は終了する。

このように、アプリケーション内の大量のモジュールについて更新が必要な場合は、通信検査装置２０において、当該アプリケーションに対応するセキュリティ検査項目について、更新後のアプリケーションが実装された稼働中でないフィルタコンテナが新たに構築される。

上述した方法により、アプリケーション内の少量のモジュールを更新する場合と同様に、アプリケーションの更新に伴う仮想端末の再起動等が不要となり、当該アプリケーションを使用することができない時間が大幅に削減され、検査の継続性を高めることが出来る。

図２０は、本実施形態に係る経路設定処理の流れの概要を示すフローチャートである。当該経路設定処理は、通信検査装置２０による検査が実施される前の準備処理として行われるものであるが、契約情報テーブル３２の各項目に変更が生じた場合は、適宜経路設定（転送経路の変更）が行われる。本実施形態では、管理者であるクライアント９０等やＶＰＮサーバー等からクライアントのアドレス情報が受信されたことを契機として実行される。

ステップＳ５０１では、クライアント９０のアドレス情報が受信される。契約情報設定部２９は、例えば、固定ＩＰアドレスを有するクライアント９０についてのＩＰアドレスを、当該クライアント９０または当該クライアント９０を管理する管理者であるクライアント９０から受信する。本実施形態では、例えばユーザ２についてのＩＰアドレス「１９２．１６８．１．２」が受信される。その後、処理はステップＳ５０２へ進む。

ステップＳ５０２では、契約情報（クライアントが要する検査項目）が受信される。契約情報設定部２９は、クライアント９０または複数の当該クライアント９０を管理する管理者であるクライアント９０等から、契約情報を受信する。本実施形態では、例えばユーザ２についての契約情報である、「ユーザ２が検査項目「ＩＰ（フィルタリング）、ＭＡＩＬ（フィルタリング）」を要する」との情報が受信される。

なお、ステップＳ５０１〜ステップＳ５０２は順不同であり、契約情報設定部２９によりクライアント９０の契約情報が取得された後に、契約情報設定部２９よりクライアント９０のアドレス情報が取得されるようにしてもよい。また、契約情報設定部２９により、クライアント９０のアドレス情報および契約情報が同時に取得されるようにしてもよい。その後、処理はステップＳ５０３へ進む。

ステップＳ５０３では、クライアント９０のアドレス情報および契約情報が保持される。契約情報設定部２９は、ステップＳ５０１で取得されたクライアント９０のアドレス情報およびステップＳ５０２で取得された当該クライアント９０の契約情報を関連付けて、契約情報テーブル３２に記憶する。本実施形態では、例えば、ユーザ２について、アドレス情報「１９２．１６８．１．２」、および、契約情報「ＩＰ（フィルタリング）、ＭＡＩＬ（フィルタリング）を行うこと」が関連付けられて契約情報テーブル３２に記憶される。その後、処理はステップＳ５０４へ進む。

ステップＳ５０４では、各経路テーブルが作成または更新される。経路設定部２３は、契約情報テーブル３２に基づき、データの転送経路を決定し、参照すべき経路テーブル（第一経路テーブルや第二経路テーブル）を指定するルール、および、第一経路テーブル３０、第二経路テーブル３１、コンテナ用経路テーブル５５を作成または更新する。本実施形態では、例えば経路設定部２３は、図９の契約情報テーブル３２の第２レコード「ユーザ２、ＩＰアドレス「１９２．１６８．１．２」、検査項目「ＩＰ（フィルタリング）、ＭＡＩＬ（フィルタリング）」」に基づき、ユーザ２からのＭＡＩＬに関するデータおよび対応する応答データが、通信検査装置（第一転送部２２）、ＩＰフィルタコンテナ＃２、ＭＡＩＬフィルタコンテナ＃１、通信検査装置（データ送信部２４）、通信検査装置（第二転送部２６）、ＭＡＩＬフィルタコンテナ＃１、通信検査装置（応答データ送信部２７）の順に転送されるよう転送経路を決定する。そして、経路設定部２３は、ユーザ２から受信したＭＡＩＬに関するデータが当該転送経路により転送されるよう、前記ルールおよび、図７、図８、図１１、図１２に例示されるように、第一経路テーブル３０、第二経路テーブル３１、コンテナ用経路テーブル５５を作成または更新する。その後、本フローチャートに示された処理は終了する。

上述した方法により、クライアント９０から受信されたデータについて、当該クライアント９０が要する検査が実行されるよう、当該検査に対応するコンテナを経由する転送経路を決定することができる。

なお、通信検査装置２０やその他の情報処理装置において、フィルタコンテナおよびデータベースコンテナのログが収集されるようにしてもよい。例えば、フィルタコンテナから、各クライアントについて、どのような検査が実行されその検査結果がどのようなものであったかを示すログを収集し、当該ログをクライアント等に提供するようにしてもよい。また、例えば、データベースコンテナから、ネットワーク上の脅威情報を収集し、ネットワーク上の脅威についての傾向を把握する等に活用するようにしてもよい。

図２１は、本実施形態に係るアプリケーション更新に伴うコンテナ切り替え処理の流れの概要を示すフローチャートである。図１８、図１９では、アプリケーションの更新に伴い、データの転送経路に使用するフィルタコンテナが、更新前の当該アプリケーションが実装された現在稼働中のフィルタコンテナ（旧コンテナ）から、更新後のアプリケーションが実装されたフィルタコンテナ（新コンテナ）へ、一括して切り替えられる。ここで、データが複数のパケットに分割して送信される場合や、通信の整合性確認のため行きのパケットと戻りのパケット（応答データ）が同一のフィルタコンテナを通過する場合（ＨＴＴＰ、ＨＴＴＰＳ関連等）等には、上記のようにフィルタコンテナが一括して切り替えられることにより、コネクションが切断されてしまう可能性がある。図２１では、このようなアプリケーションの更新に伴うフィルタコンテナの切り替えによるコネクションの切断の発生を防止する、コンテナ切り替え処理を例示する。

具体的には、アプリケーション更新の際、確立済のコネクション（既存コネクション）については、当該アプリケーションを実装したフィルタコンテナの切り替えを一定期間行わず、現在稼働中の旧コンテナの使用を継続し、一定期間経過後に更新後のアプリケーションを実装した新コンテナを通過する新経路に切り替える。

本実施形態では、ＨＴＴＰＳフィルタリングに係るアプリケーションについて更新処理が必要な場合を例示する。本実施形態に係るパケット処理は、通信検査装置２０によって、ＨＴＴＰＳフィルタリングに係るアプリケーションサーバーからのアプリケーションの更新通知および更新用データが受信されたことを契機として実行される。

ステップＳ６０１では、更新通知および更新用データが受信される。コンテナ管理部２８は、アプリケーションサーバーから、ＨＴＴＰＳフィルタリングに係るアプリケーションの更新について、更新通知および更新用データを受信する。その後、処理はステップＳ６０２へ進む。

ステップＳ６０２では、アプリケーション更新済みのＨＴＴＰＳフィルタコンテナ＃２が構築される。具体的には、図１８（少量モジュールの更新）のステップＳ３０２〜ステップＳ３０７または図１９（大量モジュールの更新）のステップＳ４０２と同様の処理が行わる。本実施形態では、ＨＴＴＰＳフィルタコンテナ＃１が稼働中のコンテナであり、アプリケーションの更新が完了した稼働中でないＨＴＴＰＳフィルタコンテナ＃２が構築される。その後、処理はステップＳ６０３へ進む。

ステップＳ６０３では、アプリケーションの更新が完了したフィルタコンテナが起動される。コンテナ管理部２８は、アプリケーションの更新が完了したＨＴＴＰＳフィルタコンテナ＃２を起動する。その後、処理はステップＳ６０４へ進む。

ステップＳ６０４では、コネクション管理テーブル３５、３６に格納された既存コネクションに、既存コネクションであることを示すマーク（既存コネクションマーク）が付与される。コネクション管理部３４は、コネクション確認時点でコネクション管理テーブル３５、３６に格納されているコネクション、すなわち、その時点でクライアント９０とサーバー８０との間で接続中のコネクションを既存コネクションであると決定（判定）する。そして、コネクション管理部３４は、各既存コネクションについて、コネクション管理テーブル３５、３６のマーク情報の欄に既存コネクションマークを付与する。なお、既存コネクションマークは、プロトコルの種類により定められたマークとは異なるマークとなるよう、例えば９や１０等、任意に設定可能である。

図２２は、本実施形態に係るコネクション管理テーブルの構成を示す図である。図示するように、本実施形態に係るコネクション管理テーブルには、既存コネクションＡとして、ユーザ４（送信元ＩＰアドレスが「１９２．１６８．１．４」、送信元ポート番号が「５５５５５」）とサーバー（宛先ＩＰアドレスが「８．８．８．８」、宛先ポート番号が「４４３」）との間のコネクションが格納されている。コネクション管理部３４は、当該コネクションを既存コネクションであると決定し、コネクション管理テーブルの対応するレコード（マーク情報の欄）に既存コネクションマーク「９」を付与する。なお、当該コネクションは、既存コネクションマークを付与される以前は、宛先ポート番号「４４３」に基づきＨＴＴＰＳ関連のコネクションであると判定され、例えばマーク「１」が付与されていたものである。

また、コネクション管理テーブルに既存コネクションが付与された後に新たに確立されたコネクションについては、図１３のステップＳ１０１の処理と同様の方法でマークの付与が行われる。具体的には、図２２のコネクション管理テーブルの第二レコードに例示されるように、コネクション確認後に新たに確立されたコネクションには、通常通りプロトコルに基づくマーク情報（例えば、１）が付与される。図２２の第二レコードは、既存コネクションＡと同一のユーザーおよびサーバー間で同一のプロトコルのコネクション（送信元ポート番号のみが異なるコネクション）が新たに確立された際に、当該コネクションの情報が格納されたものである。その後、処理はステップＳ６０５へ進む。

ステップＳ６０５では、既存コネクションに該当する受信パケットに、既存コネクションマークの付与が開始される。通信検査装置２０は、受信したパケットが、既存コネクションに該当する（既存コネクションを通過する）場合、当該受信したパケットに、ステップＳ６０４で付与した既存コネクションマークを付与する。例えば、受信したパケットの送信元ＩＰアドレス、送信元ポート番号、宛先ＩＰアドレスおよび宛先ポート番号の組み合わせが、既存コネクションのこれらの組み合わせと一致する場合に、当該パケットに既存コネクションマークが付与される。本実施形態では、コネクション管理テーブル３５、３６を参照することにより、クライアント９０から受信したパケットについては、通信検査装置２０におけるデータ取得部２１が、サーバー８０から受信した応答パケットについては、通信検査装置２０における応答データ取得部２５が、既存コネクションマークを付与する。なお、当該既存コネクションマークの付与は、上述したパケットのマーク機能により行う。その後、処理はステップＳ６０６へ進む。

ステップＳ６０６では、ＨＴＴＰＳフィルタコンテナ＃１を通過する既存コネクション（旧経路）の切替先経路として、アプリケーションの更新が完了したＨＴＴＰＳフィルタコンテナ＃２を通過する新たな経路が設定される。本実施形態では、経路設定部２３は、ＨＴＴＰＳフィルタコンテナ＃１（ＩＰアドレス「１７２．１６．１２９．２１」）を通過する旧経路とは別に、旧経路において通過するＨＴＴＰＳフィルタコンテナがＨＴＴＰＳフィルタコンテナ＃２（ＩＰアドレス「１７２．１６．１２９．２２」）となるよう新経路を設定する。具体的には、経路設定部２３は、更新に係るアプリケーションを実装した旧コンテナの前後に位置し、当該旧コンテナにデータを転送するバランサー、アウトバウンド、およびフィルタコンテナにおいて、旧経路が設定されている経路テーブルおよびコンテナ用経路テーブルとは別に、新コンテナを転送先とする新経路を設定した経路テーブルおよびコンテナ用経路テーブルを作成する。本実施形態では、ＨＴＴＰＳフィルタコンテナ＃１の前後に位置するバランサーおよびアウトバウンドにおいて、新経路が設定された経路テーブル（第一経路テーブルおよび第二経路テーブル）が新たに作成される。

図２３および図２４は、本実施形態に係る第一経路テーブルの構成を示す図である。図２３は、ＨＴＴＰＳフィルタコンテナ＃１（ＩＰアドレス「１７２．１６．１２９．２１」）を通過する旧経路が設定された第一経路テーブルＡであり、図２４は、アプリケーションの更新が完了したＨＴＴＰＳフィルタコンテナ＃２（ＩＰアドレス「１７２．１６．１２９．２２」）を通過する新経路が設定された第一経路テーブルＢである。ステップＳ６０６では、例えば、第一経路テーブルＡとは別に、第一経路テーブルＢが作成される。同様に、第二経路テーブルについても、新たに新経路が設定された第二経路テーブルが作成される。

また、ステップＳ６０６では、経路設定部２３は、既存コネクションマークが付与されていないパケットについては新経路が設定された経路テーブルを参照し、既存コネクションマークが付与されているパケットについては旧経路が設定された経路テーブルを参照するよう、ルールを設定する。本実施形態では、例えば、既存コネクションマーク「９」が付与されていないパケットについては、第一経路テーブルＢを参照し、既存コネクションマーク「９」が付与されたパケットについては、第一経路テーブルＡを参照するよう、ルール設定が行われる。なお、ステップＳ６０３とステップＳ６０４〜Ｓ６０６とは順不同であり、コネクション管理テーブルや受信パケットに既存コネクションマークが付与された後に、ＨＴＴＰＳフィルタコンテナ＃２が起動されてもよい。その後、処理はステップＳ６０７へ進む。

ステップＳ６０７では、ステップＳ６０５で開始した受信パケットへの既存コネクションマーク付与を終了し、経路テーブルおよびコンテナ用経路テーブルから旧経路が削除される。データ取得部２１および応答データ取得部２５は、ステップＳ６０６実行後一定期間（時間）が経過した後、受信パケットに対する既存コネクションマークの付与を終了する。また、経路設定部２３は、更新に係るアプリケーションを実装した旧コンテナの前後に位置するバランサー、アウトバウンド、およびフィルタコンテナにおける経路テーブルにおいて、旧コンテナを転送先とする旧経路を削除する。さらに、既存コネクションマークが付与されているパケットについては旧経路が設定された経路テーブルを参照するよう設定されたルールを削除するようにしてもよい。

なお、更新に係るアプリケーションを実装したフィルタコンテナを通過しない既存コネクションについては、ステップＳ６０７において、経路テーブルから旧経路を削除する代わりに、マーク情報の欄の既存コネクションマークを削除し、プロトコル種別に基づくマーク情報の付与を行う。これにより、当該コネクションについては、パケットへの既存コネクションマーク付与終了後も、引き続き既存コネクションを使用可能とする。

このように、ステップＳ６０６の後、一定期間経過後にステップＳ６０７の処理が行われることで、当該期間中に全既存コネクション（または大半の既存コネクション）が終了すること、即ち、旧コンテナを使用するコネクションが終了することが期待され、これにより、コンテナ切り替えによる既存コネクション切断の発生を防止することが可能となる。なお、受信パケットへのマーク付与終了と旧経路削除との間には、時間間隔（タイムラグ）が生じてもよい。なお、経路テーブルから旧経路が削除される代わりに、旧経路が設定された経路テーブル（例えば、第一経路テーブルＡ）が削除されるようにしてもよい。その後、処理はステップＳ６０８へ進む。

ステップＳ６０８では、更新前のアプリケーションを実装したＨＴＴＰＳフィルタコンテナ＃１が更新される。具体的には、図１８のステップＳ３０３〜ステップＳ３０７と同様の処理が行わる。その後、本フローチャートに示された処理は終了する。

なお、本実施形態では、ステップＳ６０４において、コネクション管理テーブルに格納されている全てのコネクションについて既存コネクションマークが付与されるが、これに限定されるものではなく、フィルタコンテナの切り替えにより接続が切断されてしまうコネクションにのみ既存コネクションマークが付与されるようにしてもよい。また、ステップＳ６０６において、新経路が設定された経路テーブルおよびコンテナ用経路テーブルが新たに作成されることとしたが、これに限定されるものではなく、既存の経路テーブルおよびコンテナ用経路テーブルに新経路が追加されるようにしてもよい。

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

Claims (16)

1. １つ以上のセキュリティ検査項目についての検査を実行する情報処理装置であって、
   該情報処理装置のＯＳによって提供されるファイルシステムを含むリソースが互いに隔離されるコンテナ型の仮想端末である、複数のコンテナと、
   ネットワークを流れるデータを、宛先に到達する前に取得するデータ取得手段と、
   前記宛先に前記データを送信するデータ送信手段と、を備え、
   前記複数のコンテナの一部は、前記検査を実行するためのアプリケーションが実装された検査コンテナであり、
   前記検査コンテナは、取得された前記データについて前記検査を実行する検査手段を備える、
   情報処理装置。
2. 前記セキュリティ検査項目毎に前記検査コンテナが構築される、
   請求項１に記載の情報処理装置。
3. 前記データについて必要な１つ以上の検査が実行されるよう、該データが各検査に対応する検査コンテナを経由して前記データ送信手段に転送される転送経路を決定する経路設定手段を更に備え、
   前記経路設定手段は、前記アプリケーションの更新に伴い、前記転送経路に使用されている更新前の該アプリケーションが実装された検査コンテナとは別に構築された、前記更新後の該アプリケーションが実装された稼働中でない検査コンテナを、前記データの転送経路に使用する検査コンテナとして設定する、
   請求項２に記載の情報処理装置。
4. 前記セキュリティ検査項目毎に複数の前記検査コンテナが構築され、
   前記アプリケーションについての更新処理を行うコンテナ管理手段を更に備え、
   前記コンテナ管理手段は、前記アプリケーションを更新する際、該アプリケーションに対応する前記セキュリティ検査項目について構築された前記複数の検査コンテナのうち、稼働中でない検査コンテナに、前記アプリケーションの更新要求を送信する、
   請求項３に記載の情報処理装置。
5. 前記複数のコンテナの夫々は、該情報処理装置のＯＳによって提供されるネットワークリソースが互いに隔離される仮想端末であり、
   前記稼働中でない検査コンテナは、前記データの転送経路に使用されていない検査コンテナである、
   請求項３または４に記載の情報処理装置。
6. 前記検査コンテナは、前記更新要求を受信し、前記アプリケーションを更新する更新手段を更に備え、
   前記経路設定手段は、前記更新手段により更新されたアプリケーションが実装された検査コンテナを、前記データの転送経路に使用する検査コンテナとして設定する、
   請求項４または５に記載の情報処理装置。
7. 前記アプリケーションを更新する際、前記転送経路に使用されている更新前の該アプリケーションが実装された検査コンテナとは別に、更新後の該アプリケーションが実装された稼働中でない検査コンテナを新たに構築するコンテナ管理手段を更に備える、
   請求項３に記載の情報処理装置。
8. 前記複数のコンテナの夫々は、該情報処理装置のＯＳによって提供されるネットワークリソースが互いに隔離される仮想端末であり、
   前記稼働中でない検査コンテナは、前記データの転送経路に使用されていない検査コンテナであり、
   前記経路設定手段は、前記更新後のアプリケーションが実装された検査コンテナを、前記データの転送経路に使用する検査コンテナとして設定する、
   請求項７に記載の情報処理装置。
9. 前記経路設定手段は、前記アプリケーションの更新の際に確立済のコネクションに係る前記データについては、該確立済のコネクションにおいて使用中の前記更新前の該アプリケーションが実装された検査コンテナを通過する既存の転送経路を一定期間継続して使用するよう前記転送経路を設定する、
   請求項３に記載の情報処理装置。
10. 前記複数のコンテナは、セキュリティに関する検査条件が記憶された検査条件データベースを備えるデータベースコンテナを更に備え、
    前記データベースコンテナは、データ内の検査対象となる部分が前記検査条件に合致するか否かを判定する判定手段を備え、
    前記検査手段は、前記データベースコンテナに対して、前記判定手段による判定を依頼することで、前記検査を実行する、
    請求項１から９の何れか一項に記載の情報処理装置。
11. 前記検査手段は、前記判定手段による判定結果に基づいて、前記宛先への転送可否を判定する、
    請求項１０に記載の情報処理装置。
12. 前記データの送信元または宛先であるユーザ端末毎に、該送信元が必要とする１つ以上の前記検査が実行されるよう、該データが各検査に対応する検査コンテナを経由して前記データ送信手段に転送される転送経路を決定する経路設定手段を更に備える、
    請求項１または２に記載の情報処理装置。
13. 前記ユーザ端末が必要とする１つ以上の前記検査を示す契約情報を設定する契約情報設定手段を更に備え、
    前記経路設定手段は、設定された前記契約情報に基づき、前記転送経路を決定する、
    請求項１２に記載の情報処理装置。
14. 前記データの次転送先が記憶された経路テーブルを更に備え、
    前記検査コンテナは、前記データの次転送先が記憶されたコンテナ用経路テーブルを更に備え、
    前記経路設定手段は、前記ユーザ端末について決定された前記転送経路を、前記経路テーブルおよび前記コンテナ用経路テーブルに設定する、
    請求項１２または１３に記載の情報処理装置。
15. 該情報処理装置のＯＳによって提供されるファイルシステムを含むリソースが互いに隔離される仮想端末である、複数のコンテナを備えた、１つ以上のセキュリティ検査項目についての検査を実行するコンピュータが、
    ネットワークを流れるデータを、宛先に到達する前に取得するステップと、
    前記宛先に前記データを送信するステップと、
    前記複数のコンテナの一部である、前記検査を実行するためのアプリケーションが実装された検査コンテナにおいて、取得した前記データについて前記検査を実行するステップと、
    を実行する方法。
16. 該情報処理装置のＯＳによって提供されるファイルシステムを含むリソースが互いに隔離される仮想端末である、複数のコンテナを備えた、１つ以上のセキュリティ検査項目についての検査を実行するコンピュータを、
    ネットワークを流れるデータを、宛先に到達する前に取得するデータ取得手段と、
    前記宛先に前記データを送信するデータ送信手段と、
    前記複数のコンテナの一部である、前記検査を実行するためのアプリケーションが実装された検査コンテナにおいて、取得した前記データについて前記検査を実行する検査手段と、
    として機能させるプログラム。
    
    

Images