情報処理装置、情報処理方法及びプログラム
【課題】データの送信先に応じてデータの拡張子が偽装されているかを判定することにより、情報漏洩を防止する。
【解決手段】ファイルの送信先を特定する送信先情報と、当該送信先に対して当該ファイルの拡張子の偽装があるときに当該ファイルの送信を許可するか禁止するかが設定された設定情報とを対応づけた送信ルール情報を記憶し、クライアント装置から出力されたファイルの送信要求に対して、当該ファイル内のデータから判定されるファイル形式と当該ファイルのファイル名の拡張子から判定されるファイル形式とが同じであるかを判定し、異なると判定された場合、該ファイルの送信先に対応した送信ルール情報に従って、該ファイルの送信を許可するか禁止するかを制御する。
【解決手段】ファイルの送信先を特定する送信先情報と、当該送信先に対して当該ファイルの拡張子の偽装があるときに当該ファイルの送信を許可するか禁止するかが設定された設定情報とを対応づけた送信ルール情報を記憶し、クライアント装置から出力されたファイルの送信要求に対して、当該ファイル内のデータから判定されるファイル形式と当該ファイルのファイル名の拡張子から判定されるファイル形式とが同じであるかを判定し、異なると判定された場合、該ファイルの送信先に対応した送信ルール情報に従って、該ファイルの送信を許可するか禁止するかを制御する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、情報処理方法及びプログラムに関し、特に、データの送信制御技術に関するものである。
【背景技術】
【０００２】
ウェブサーバ上で電子メールの閲覧や送信を可能にするウェブメールサービスやドキュメントファイルの管理や共有を行うドキュメント管理サービスが提供されている。従来これらのサービスは、ユーザのコンピュータ上でソフトウェアを実行することにより行われてきたが、近年ではコンピューターネットワーク上にあるサービス提供者のコンピュータでソフトウェアを実行し、ユーザはサービスを利用するといった形態で行われることが多くなってきている。このようなサービスの利用はこれまで一般ユーザが主であったが、近年では、企業などがこれらのサービスを業務で利用する事例も増えてきている。これらのサービスはＳａａＳなどと呼ばれ、今後利用が増えてくると考えられる。
【０００３】
これらのサービスは便利である反面、企業などが業務として利用する場合は外部ネットワークに重要な情報が漏えいしてしまうといった危険性がある。特にＨＴＴＰ通信でデータファイルを送信するようなサービスの増加が考えられるため、ＨＴＴＰ通信で送信されるデータファイルの制御が重要となる。また、業務としての利用を許可している以外のサービスを利用することによって重要な情報が漏えいしてしまうといった事態も考えられる。
【０００４】
以上の問題への対応として、ＨＴＴＰアクセスを特定のウェブサイトにのみ制限したり、データファイルの送信を制御したりすることが必要となる。
【０００５】
特定のウェブサイトにのみアクセスを許可するような技術としては、例えば特許文献１が開示されている。係る技術によれば、特定のサイトにのみＨＴＴＰアクセスを許可するといった制御が可能となる。
【０００６】
また、データファイルの形式を判定する技術としては、例えば特許文献２が開示されている。係る技術によれば、データファイルの特徴を解析し、その結果からデータファイルの形式を推定することが可能となる。
【特許文献１】特開２００４−３４８２０２号公報
【特許文献２】特開２００１−１０１０４９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
ＨＴＴＰリクエストで送信されるデータファイルの制御を行うには、ＨＴＴＰリクエストに添付されるデータファイルのファイル形式を判定する必要がある。
【０００８】
また、データファイルに対して特定のキーワードが含まれていないか検査する場合、あらかじめ、ファイル形式に適した方法でテキスト情報を抽出する必要があり、データファイルのファイル形式の判定が必要となる。
【０００９】
ＨＴＴＰリクエストに添付されるデータファイルのファイル形式はブラウザ等のＨＴＴＰクライアントがＨＴＴＰリクエストに付与するＣｏｎｔｅｎｔ−Ｔｙｐｅで判定することが可能である。しかし、通常ＨＴＴＰクライアントはファイルの拡張子に関連付けてＣｏｎｔｅｎｔ−Ｔｙｐｅを決定するため、ファイルに誤った拡張子が付与されていたり、意図的に変更されたりしている場合は、Ｃｏｎｔｅｎｔ−Ｔｙｐｅからファイル形式が判定できないという問題がある。
【００１０】
また、Ｃｏｎｔｅｎｔ−ＴｙｐｅはＨＴＴＰクライアントが付与するものであるため、そもそも信頼できないといった問題もある。そのため、ＨＴＴＰリクエストのＣｏｎｔｅｎｔ−Ｔｙｐｅに基づく制御では、ＨＴＴＰリクエストによるデータファイルの送信を正しく制御できないという問題がある。
【００１１】
そのため、例えば、情報漏洩を防止するため、所定のファイル形式の文書データのみを、所定のウェブサイトへの送信許可とする送信制御システムを運用する場合、Ｃｏｎｔｅｎｔ−Ｔｙｐｅに基づく制御のみでは、悪意のあるユーザが、ファイル名の拡張子を送信が許可されているファイル形式の拡張子に変更することにより、あたかも送信が許可されているファイルであるかのように判断され送信されてしまう恐れがある。
本発明の目的は、データの送信先に応じてデータの拡張子が偽装されているかを判定することにより、情報漏洩を防止する仕組みを提供することである。
【課題を解決するための手段】
【００１２】
本発明は、データを出力するクライアント装置と通信可能であり、当該データの送信制御を行う情報処理装置であって、ファイルの送信先を特定する送信先情報と、当該送信先に対して当該ファイルの拡張子の偽装があるときに当該ファイルの送信を許可するか禁止するかが設定された設定情報とを対応づけた送信ルール情報を記憶する記憶手段と、前記クライアント装置から出力された前記ファイルの送信要求に対して、当該ファイル内のデータから判定されるファイル形式と当該ファイルのファイル名の拡張子から判定されるファイル形式とが同じであるかを判定する偽装判定手段と、前記偽装判定手段でファイル形式が異なると判定された場合、前記ファイルの送信先に対応した前記送信ルール情報に従って、当該ファイルの送信を許可するか禁止するかを制御する送信制御手段と、を備えることを特徴とする。
【００１３】
本発明は、データを出力するクライアント装置と通信可能であり、当該データの送信制御を行う情報処理装置における情報処理方法であって、記憶手段が、ファイルの送信先を特定する送信先情報と、当該送信先に対して当該ファイルの拡張子の偽装があるときに当該ファイルの送信を許可するか禁止するかが設定された設定情報とを対応づけた送信ルール情報を記憶する記憶工程と、偽装判定手段が、前記クライアント装置から出力された前記ファイルの送信要求に対して、当該ファイル内のデータから判定されるファイル形式と当該ファイルのファイル名の拡張子から判定されるファイル形式とが同じであるかを判定する偽装判定工程と、送信制御手段が、前記偽装判定工程でファイル形式が異なると判定された場合、前記ファイルの送信先に対応した前記送信ルール情報に従って、当該ファイルの送信を許可するか禁止するかを制御する送信制御工程と、を備えることを特徴とする。
【００１４】
本発明は、データを出力するクライアント装置と通信可能であり、当該データの送信制御を行う情報処理装置として機能させるプログラムであって、ファイルの送信先を特定する送信先情報と、当該送信先に対して当該ファイルの拡張子の偽装があるときに当該ファイルの送信を許可するか禁止するかが設定された設定情報とを対応づけた送信ルール情報を記憶する記憶手段と、前記クライアント装置から出力された前記ファイルの送信要求に対して、当該ファイル内のデータから判定されるファイル形式と当該ファイルのファイル名の拡張子から判定されるファイル形式とが同じであるかを判定する偽装判定手段と、前記偽装判定手段でファイル形式が異なると判定された場合、前記ファイルの送信先に対応した前記送信ルール情報に従って、当該ファイルの送信を許可するか禁止するかを制御する送信制御手段として機能させることを特徴とする。
【発明の効果】
【００１５】
本発明によれば、データの送信先に応じてデータの拡張子が偽装されているかを判定することにより、情報漏洩を防止することができる。
【図面の簡単な説明】
【００１６】
【図１】本発明の一実施形態に係るシステムの構成を示す図である。
【図２】情報処理装置のハードウェア構成を示す図である。
【図３】図３は、プロキシサーバ１０１の機能構成を示す図である。
【図４】図４は、本発明における第１の制御処理の一例を示すフローチャートである。
【図５】図５は、本発明における第２の制御処理の一例を示すフローチャートである。
【図６】図６は、規制ルール設定画面の一例を示す図である。
【図７】図７は、規制ルール詳細設定画の一例を示す図である。
【図８】図８は、規制ルール移動画面の一例を示す図である。
【図９】図９は、規制ルールテーブルの一例を示す図である。
【図１０】図１０は、本発明における第３の制御処理の一例を示すフローチャートである。
【図１１】図１１は、図１０に示す第３の制御処理のステップＳ１００２の詳細処理を示すフローチャートである。
【図１２】図１２は、ＵＲＬＤＢ１００２の一例を示す図である。
【図１３】図１３は、本発明における第４の制御処理の一例を示すフローチャートである。
【図１４】図１４は、ファイル形式識別子とシグネチャの対応表の一例を示す図である。
【図１５】図１５は、本発明における第５の制御処理の一例を示すフローチャートである。
【図１６】図１６は、本発明における第６の制御処理の一例を示すフローチャートである。
【図１７】図１７は、ファイル形式を表すファイル形式識別子１７０１と、そのファイル形式に対して一般的に付与される拡張子１７０２との対応を示した表の一例である。
【発明を実施するための最良の形態】
【００１７】
以下、添付図面を参照して、本発明を好適な実施形態に従って詳細に説明する。
図１は、本実施形態に係るシステムの構成例を示す図である。
【００１８】
図１に示す如く、本実施形態に係るシステムは、プロキシサーバ１０１、ＵＲＬＤＢ１０２、規制ルールＤＢ１０３、クライアントＰＣ１０４−１乃至１０４−３（以後、まとめて「クライアントＰＣ１０４」とする）、ＬＡＮ（ローカルエリアネットワーク）１０５、広域ネットワーク１０６（以下、ネットワーク）、ウェブサーバ１０７−１乃至１０７−３（以後、まとめて「ウェブサーバ１０７」とする）により構成されている。以下、本実施形態に係るシステムを構成するこれらについて説明する。
プロキシサーバ１０１は、本発明の情報処理装置として機能する装置であり、クライアントＰＣ１０４とウェブサーバ１０７との間のデータ通信を中継する。
【００１９】
また、プロキシサーバ１０１は、ウェブサイトのＵＲＬを特定カテゴリごとに集めたＵＲＬＤＢ１０２および、クライアントＰＣ１０４からウェブサーバ１０７へのＨＴＴＰリクエストを許可する／拒否するといった制御に使用する規制ルールが登録されている規制ルールＤＢ１０３を備えている。
【００２０】
また、プロキシサーバ１０１は、さらに規制ルールＤＢ１０３に設定されている情報の登録、修正等を行わせるための設定ページの提供等を行うウェブサーバ機能なども有している。尚、ＵＲＬＤＢ１０２および規制ルールＤＢ１０３は、プロキシサーバ１０１内に備えていても、別のコンピュータ内に実装しても構わない。
【００２１】
ＵＲＬＤＢ１０２はウェブサイトのＵＲＬをカテゴリごとに集めたデータベースであり、通常ＵＲＬＤＢ作成業者から購入するなどする場合が多い。ＵＲＬＤＢ１０２の更新はプロキシサーバ１０１の更新プログラムで行っても良いし、他の手段により更新してもよい。
クライアントＰＣ１０４は、ウェブサーバ１０７が提供するサービスを利用するユーザが使用する端末装置である。
【００２２】
ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）１０５は、プロキシサーバ１０１及びクライアントＰＣ１０４をデータ通信可能に相互に接続させるものである。広域ネットワーク１０６は、インターネット等の広域ネットワークを示す。
【００２３】
ウェブサーバ１０７は、ウェブメールサービスやドキュメント管理サービスなどウェブサーバ上で提供されるさまざまなサービスを提供するサーバを表す。
図２は、プロキシサーバ１０１のハードウェア構成を示すブロック図である。
【００２４】
図２において、２０１はＣＰＵで、ＲＡＭ２０２やＲＯＭ２０３に記憶されているプログラムやデータを用いてプロキシサーバ１０１全体の制御を行うとともに、プロキシサーバ１０１が行う後述の各処理を実行する。
【００２５】
２０２はＲＡＭで、ＨＤＤ（ハードディスクドライブ）２０４や記録媒体ドライブ２０６からロードされたプログラムやデータ、ネットワークＩ／Ｆ（インターフェース）２０５を介して他の機器から受信したプログラムやデータ等を一時的に記憶するためのエリアや、ＣＰＵ２０１が各種の処理を実行する際に用いるワークエリア等、各種のエリアを適宜提供することができる。
【００２６】
２０３はＲＯＭで、プロキシサーバ１０１の設定データや、ブートプログラム等を記憶する。
【００２７】
２０４はＨＤＤで、ＯＳ（オペレーティングシステム）や、プロキシサーバ１０１が行う後述の各処理をＣＰＵ２０１に実行させるためのプログラムやデータ等を保存するものであり、これらはＣＰＵ２０１による制御に従って適宜ＲＡＭ２０２にロードされ、ＣＰＵ２０１の処理対象となる。
【００２８】
２０５はネットワークＩ／Ｆで、プロキシサーバ１０１を上記ＬＡＮ１０５、広域ネットワーク１０６に接続させるためのものであり、プロキシサーバ１０１はこのネットワークＩ／Ｆ２０５を介してＬＡＮ１０５や広域ネットワーク１０６に接続されている各装置とのデータ通信を行う。
【００２９】
２０６は記録媒体ドライブで、ＣＤ−ＲＯＭ、ＣＤ−Ｒ／ＲＷ、ＤＶＤ−ＲＯＭ、ＤＶＤ−Ｒ／ＲＷ、ＤＶＤ−ＲＡＭ等の記録媒体に記録されているプログラムやデータを読み出し、ＲＡＭ２０２やＨＤＤ２０４に出力する。なお、ＨＤＤ２０４が保持しているデータのうちの一部をこれら記録媒体に記憶させておいても良い。
【００３０】
２０７はキーボード、２０８はマウスやジョイスティック等により構成されているポインティングデバイスで、プロキシサーバ１０１の操作者が操作することで、各種の指示をＣＰＵ２０１に対して入力する入力部として機能する。
２０９は表示部で、ＣＲＴや液晶画面などにより構成されており、ＣＰＵ２０１による処理結果を画像や文字などで表示する。
【００３１】
２１０は外部機器接続Ｉ／Ｆで、周辺機器をプロキシサーバ１０１に接続させるためものポートである。プロキシサーバ１０１は、この外部機器接続Ｉ／Ｆ２１０を介して、周辺機器とのデータ通信を行う。外部機器接続Ｉ／Ｆ２１０は、ＵＳＢやＩＥＥＥ１３９４等により構成されており、通常複数の外部機器接続Ｉ／Ｆ２１０を有する。周辺機器との接続形態は有線／無線を問わない。
【００３２】
２１１はバスで、上述の各部２０１〜２１０を接続する。
【００３３】
なお、プロキシサーバ１０１のハードウェア構成は、図２に示した構成を有するとして説明するが、必ずしも同図の構成を有することに限定するものではなく、プロキシサーバ１０１が行う後述の各種処理を実行可能であればプロキシサーバ１０１の構成は適宜変更しても良い。
【００３４】
また、クライアントＰＣ１０４、ウェブサーバ１０７のハードウェア構成も、これらには一般的なコンピュータを適用するので、周知の如く、概ね図２に示した構成を有する。
【００３５】
図３は、プロキシサーバ１０１の機能構成を示す図である。
【００３６】
図３に示すように、プロキシサーバ１０１は、規制ルール受付手段３０１、規制ルール記録手段３０２、ＵＲＬカテゴリ判定手段３０３、リクエストの詳細情報取得手段３０４、通信中継制御手段３０５、通信許可／不許可応答送信手段３０６を備えている。
【００３７】
規制ルール受付手段３０１は、ＨＴＴＰリクエストの許可／不許可を判断するための規制ルールの入力を受け付ける。規制ルール記録手段３０２は、規制ルール受付手段３０１で受け付けたルール（詳細は後述する図９）を規制ルールＤＢ１０３に登録する。
【００３８】
ＵＲＬカテゴリ判定手段３０３は、ＵＲＬＤＢ１０２に登録された情報に基づいて、クライアントＰＣ１０４からリクエストされたＵＲＬがどのカテゴリに属するかを判定する。
【００３９】
リクエストの詳細情報取得手段３０４は、ＨＴＴＰリクエストに添付されたデータファイルのシグネチャからデータファイルのファイル形式を判定する。
【００４０】
通信中継制御手段３０５は、ＵＲＬカテゴリ判定手段３０３によって取得したＨＴＴＰリクエストのカテゴリ情報と、リクエストの詳細情報取得手段３０４よって取得したファイル形式情報を、規制ルールＤＢ１０３に記録された規制ルールに照らし合わせ、その結果によりＨＴＴＰリクエストの許可／拒否の制御（送信規制制御）を行う。
【００４１】
通信許可／不許可応答送信手段３０６は、通信中継制御手段３０５で許可したＨＴＴＰリクエストを行ったクライアントＰＣ１０３に対してウェブサーバからの応答を中継する、あるいは不許可としたＨＴＴＰリクエストを行ったクライアントＰＣに対してＨＴＴＰリクエストを拒否した旨の通知を行う。
【００４２】
なお、プロキシサーバ１０１のＨＤＤ２０４には、規制ルール受付手段３０１、規制ルール記録手段３０２、ＵＲＬカテゴリ判定手段３０３、リクエストの詳細情報取得手段３０４、通信中継制御手段３０５、通信許可／不許可応答送信手段３０６としてプロキシサーバを制御させるためのプログラムが記録されている。そして、これらのプログラムをプロキシサーバ１０１のＣＰＵ２０１がＲＡＭ２０２にロードして実行することにより上記各手段３０１〜３０６が実現される。
【００４３】
次に、フローチャートを参照してプロキシサーバ１０１によって行われる処理について説明する。
【００４４】
図４は、本発明における第１の制御処理の一例を示すフローチャートであり、プロキシサーバ１０１によって行われる全体的な処理の概要を示すフローチャートに対応する。なお、このフローチャートの処理はプロキシサーバ１０１のＣＰＵ２０１がＨＤＤ２０４に格納されるプログラムをＲＡＭ２０２にロードして実行することにより実現される。
【００４５】
まず、ＣＰＵ２０１は、ユーザから規制ルールの設定変更要求を受け付けたか否かを判断する（ステップＳ４０１）。そして、設定変更要求を受けたと判断した場合には（ステップＳ４０１でＹｅｓ）、ＣＰＵ２０１は規制ルールの設定処理を行う（ステップＳ４０２）。なお、ステップＳ４０２の処理の詳細については図５を参照して後述する。そして、ステップＳ４０２の処理が終わると、ＣＰＵ２０１はステップＳ４０３に処理を進める。
【００４６】
ステップＳ４０３では、ＣＰＵ２０１は、クライアントＰＣ１０４がリクエストしたＵＲＬからカテゴリを判定し、ＨＴＴＰリクエストの詳細情報を取得し、それらの情報に基づいてステップＳ４０２で設定した規制ルールと照らし合わせてＨＴＴＰリクエストの制御処理を行う。なお、ステップＳ４０３の処理の詳細については、図１０を参照して後述する。そして、ステップＳ４０３の処理が終わると、ＣＰＵ２０１はステップＳ４０４に処理を進める。
【００４７】
ステップＳ４０４では、ＣＰＵ２０１は、ＨＴＴＰリクエストの制御処理の終了指示を受けたかどうか判断する。そして、終了指示を受けていないと判断した場合には（ステップＳ４０４でＮｏ）、ＣＰＵ２０１は、ステップＳ４０１に処理を戻す。
【００４８】
一方、ＨＴＴＰリクエストの制御処理の終了指示を受けたと判断した場合には（ステップＳ４０４でＹｅｓ）、ＣＰＵ２０１は、そのまま本フローチャートの処理を終了する。即ち、ＣＰＵ２０１は、上記のＳ４０１〜Ｓ４０３の処理を、ＨＴＴＰリクエストの制御処理の終了指示を受けるまで（ステップＳ４０４でＹｅｓと判断するまで）繰り返す。
以下、図５を参照して、図４のステップＳ４０２に示した規制ルールの設定処理を詳細に説明する。
【００４９】
図５は、本発明における第２の制御処理の一例を示すフローチャートであり、図４のステップＳ４０２に示した規制ルールの設定処理の詳細を示すフローチャートに対応する。即ち、本処理は、プロキシサーバ１０１のＣＰＵ２０１によって行われる。なお、本処理を行う際に、ＣＰＵ２０１は、規制ルール受付手段３０１及びウェブメール規制ルール記録手段３０２としてプロキシサーバ１０２を機能させるためのプログラムをＨＤＤ２０４からＲＡＭ２０２にロードし、そのプログラムの制御に基づいて以下に示す処理を行うこととなる。
【００５０】
まず、プロキシサーバ１０１のＣＰＵ２０１は、規制ルールの設定要求を送信してきたクライアントＰＣ１０４に対して、図６に示すような規制ルール設定画面６００を表示するための表示情報を送信する（ステップＳ５０１）。当該表示情報に従って、クライアントＰＣ１０４のディスプレイ装置には規制ルール設定画面６００が表示される。ここで規制ルール設定画面６００について説明する。
【００５１】
図６は、規制ルール設定画面の一例を示す図である。
【００５２】
図６において、６０１はルールＩＤ表示欄であって、規制ルールを一意に示すＩＤが表示される。規制ルールは規制ルール設定画面に表示される順番に適用される。
６０２はルール名表示欄であって、当該詳細ルールに設定されているルール名が表示される。
【００５３】
６０３は動作表示欄であって、当該ルールに合致したＨＴＴＰリクエストを許可する／不許可とするかの設定が表示される。
【００５４】
各ルールは、それぞれのルールを表示している行の編集ボタン６０４を押下することで編集が、削除ボタン６０５を押下することで削除することが可能である。また、移動ボタン６０６を押下することでルール移動画面が表示され、ルールの適用順位を変更することができる。
【００５５】
また、追加ボタン６０７を押下すると規制ルールの追加が可能になる。以上が図６に示す規制ルール設定画面の説明である。
以下、図５のフローチャートの説明に戻る。
【００５６】
ステップＳ５０２において、ＣＰＵ２０１は、規制ルールの詳細設定要求を受け付けたか否かを判断する。この詳細設定要求は、クライアントＰＣのディスプレイ上に表示されている規制ルール設定画面６００の追加ボタン６０７もしくは編集ボタン６０４が押下された場合に発行されるものである。
【００５７】
追加ボタン６０７が押下された場合には新規の詳細設定を、編集ボタン６０４が押下された場合には、すでに設定されている詳細設定の変更処理を行うことになる。
【００５８】
そして、規制ルールの詳細設定要求を受け付けたと判断した場合には（ステップＳ５０２でＹｅｓ）、ＣＰＵ２０１は、規制ルール詳細設定画面（図７）を表示するための表示情報を、規制ルールの詳細設定要求を送信してきたクライアントＰＣ１０４に対して送信する（ステップＳ５０３）。以下図７の規制ルール詳細設定画面７００について説明する。
【００５９】
図７において、７０１はルールＩＤ表示欄であって、規制ルールを一意に示すルールＩＤ（条件ＩＤ）表示欄である。このＩＤは自動的に付与しても、ユーザの入力部からの入力指示に基づいて設定しても（規制ルール内での重複は許さない）構わない。
７０２は規制ルール名入力欄であって、当該規制ルールの名称の入力を受け付ける。
【００６０】
ＵＲＬ条件では、特定のＵＲＬを指定するか（ＵＲＬラジオボタン７０３を選択する）若しくはカテゴリを指定するか（カテゴリラジオボタン７０４を選択する）が選択可能である。そしてＵＲＬラジオボタン７０３が選択された場合にはＵＲＬ入力欄７０５への入力が、カテゴリラジオボタン７０４が選択された場合にはカテゴリ選択セレクトボックス７０６によるカテゴリの選択が可能である。本実施例では、ＵＲＬ条件にＵＲＬ指定もしくはカテゴリ指定のどちらかによる設定を行うことになっているが、双方を同時に設定させても勿論かまわない。クライアントＰＣから送信されたＨＴＴＰリクエストのＵＲＬがこれらの条件に合致した場合ＵＲＬ条件が合致したと判定される。
【００６１】
７０７は添付されたデータファイルのファイル形式を選択するためのセレクトボックスであって、データファイルのファイル形式を選択する。
【００６２】
７０８は添付ファイルのサイズ入力欄であって添付ファイルのサイズを入力する。７０９は添付ファイルのサイズが７０８で指定したサイズ以上／以下を選択するラジオボタンであって、添付ファイルのサイズが７０８で指定したサイズ以上の場合にルールを合致させたい場合は以上を、添付ファイルのサイズが７０８で指定したサイズ以下の場合にルールに合致させたい場合は以下を指定する。
【００６３】
７１０は添付ファイルのファイル形式と付与されている拡張子が一致する／しないを指定するラジオボタンであって、添付ファイルのファイル形式と付与された拡張子が一致する場合にルールに合致させたい場合は一致する、ファイル形式と付与された拡張子が一致しない場合にルールに合致させたい場合は一致しないを指定する。
【００６４】
７１１はキーワード条件の入力欄であって、ＨＴＴＰリクエストに添付されたデータファイルおよびＨＴＴＰリクエストのそれ以外のフィールドに記載されたテキスト情報に合致させるキーワード条件を入力する。キーワード入力欄には複数のキーワードを入力することが可能であり、またそれらの結合条件（ＡＮＤ条件：例えば「＆」で設定、ＯＲ条件：例えば「｜」で設定、結合優先度設定：例えば括弧「（）」で設定）の設定も可能である。
【００６５】
そして上記条件に合致した場合に（ＵＲＬ条件、添付ファイル条件、キーワード条件をＡＮＤ条件で結合）、ＨＴＴＰリクエストを許可／不許可のどちらかに設定するかを動作ラジオボタン７１２で指定する。ＵＲＬ条件、添付ファイル条件、キーワード条件の結合方法を入力するための領域を設定して、その領域に結合条件を入力し、その結合条件を満たした場合に送信を許可／不許可とするといった設定を用いても勿論かまわない。
【００６６】
そして更新ボタン７１３が押下された場合、上記設定した詳細ルールの登録要求をプロキシサーバ１０１に対して行うことになる。また、キャンセルボタン７１４が押下された場合は、ルールの変更もしくは追加を実施せずに規制ルールの詳細設定処理を終了する。以上が図７に示す規制ルール詳細設定画面７００の説明である。
以下、図５のフローチャートの説明に戻る。
【００６７】
ステップＳ５０４において、ＣＰＵ２０１は、規制ルールの移動要求を受け付けたか否かを判断する。この要求は、クライアントＰＣのディスプレイ上に表示されている規制ルール設定画面６００の移動ボタン６０６が押下された場合に発行されるものである。
【００６８】
そして、規制ルールの移動要求を受け付けたと判断した場合には（ステップＳ５０４でＹｅｓ）、ＣＰＵ２０１は、規制ルール移動画面（図８）を表示するための表示情報を、規制ルールの移動要求を送信してきたクライアントＰＣ１０４に対して送信する（ステップＳ５０５）。ここで規制ルール移動画面８００について説明する。
【００６９】
図８は、規制ルール移動画面８００の一例を示す図である。規制ルールは規制ルール設定画面６００に表示される順番に優先度が高くなる。ＨＴＴＰリクエストへの規制ルールの適用は優先度が高い順に行われ、条件に合致した規制ルールがあった場合にはその規制ルールで示す条件式に合致した場合の動作を行わせる。よって、条件に合致した規制ルールよりも優先度の低い規制ルールの適用は基本的に行われない。規制ルール移動画面８００は、規制ルール設定画面６００で表示するルールの順番を変更するために用いられる。
図８において、８０１は移動対象となる規制ルールの行番号表示欄であって、何行目の規制ルールを移動させるかを表す。
【００７０】
８０２は対象規制ルールを何行目の規制ルールの上もしくは下に移動させるかを入力させる入力欄である。８０３は対象規制ルールを８０２で指定した行番号の規制ルールの上もしくは下に移動させるかを選択するセレクトボックスであって、対象規制ルールを８０２で指定した行番号の規制ルールの上に移動させたい場合は上に、下に移動させたい場合は下に、を選択する。
【００７１】
そして移動ボタン８０４が押下された場合、上記設定した規制ルールの移動要求をプロキシサーバ１０１に対して行うことになる。また、キャンセルボタン８０５が押下された場合は、規制ルールの移動を実施せずに規制ルールの移動処理を終了する。以上が図８に示す規制ルール移動画面８００の説明である。
以下、図５のフローチャートの説明に戻る。
【００７２】
ステップＳ５０６では、ＣＰＵ２０１は、規制ルールの詳細設定用の画面および移動画面を介して入力された入力情報を受信したか否かを判断する。そして、受信したと判断した場合には（ステップＳ５０６でＹｅｓ）、ＣＰＵ２０１は、受信した情報を規制ルールＤＢ１０３に保存する（ステップＳ５０７）。尚、受信した情報は、図９の規制ルールテーブル９００に登録されることになる。ここで、規制ルールテーブル９００について説明する。
【００７３】
図９は、規制ルールテーブル９００の一例を示す図である。このテーブルには規制ルール詳細設定画面７００を介して入力された規制ルールが登録されることになる。また、規制ルール移動画面８００で設定した適用順が登録される。
【００７４】
図９において、９０１はルールＩＤであって、規制ルールを一意に識別するＩＤ情報が登録される。９０２は適用順であって、規制ルールの適用の優先順位が登録されている。９０３はルール名であって、規制ルールのルール名が登録される。
【００７５】
９０４にはＵＲＬが登録される。９０５にはカテゴリが登録される。９０６には添付ファイルのファイル形式が登録される。９０７には添付ファイルのサイズが登録される。９０８には添付ファイルのサイズが９０７に登録したサイズ以上もしくは以下の場合にルールに合致させるかの情報が登録される。９０９はファイル形式と拡張子の一致条件が登録される。９１０にはキーワード条件を登録する。９１０動作であって、条件式に合致したウェブメールに対して送信を許可する／不許可とするという送信制御（中継制御）方法の設定が登録される。以上が図９の規制ルールテーブル９００説明である。
以下、図５のフローチャートの説明に戻る。
【００７６】
ステップＳ５０８では、ＣＰＵ２０１は、ステップＳ５０７で規制ルールＤＢ１０３に保存した情報を含む規制ルール設定画面６００をクライアントＰＣ１０４に送信し、ステップＳ５０２に処理を戻す。
【００７７】
また、ステップＳ５０６において、規制ルールの詳細設定用の画面７００および規制ルールの移動画面８００を介して入力された入力情報を受信していないと判断した場合には（ステップＳ５０６でＮｏ）、ＣＰＵ２０１は、ステップＳ５０９に処理を進める。
【００７８】
ステップＳ５０９では、ＣＰＵ２０１は、規制ルールの設定処理の終了指示を受けたかどうか判断する。なお、規制ルールの設定処理終了指示とは、例えば規制ルール設定画面６００中の終了ボタン（不図示）が押下された場合や、ブラウザアプリケーションの終了指示があった場合に発行されることになる。
【００７９】
そして、規制ルールの設定処理の終了指示を受けていないと判断した場合には（ステップＳ５０９でＮｏ）、ＣＰＵ２０１は、ステップＳ５０２に処理を戻す。
【００８０】
一方、規制ルールの設定処理の終了指示を受けたと判断した場合には（ステップＳ５０９でＹｅｓ）、ＣＰＵ２０１は、そのまま本フローチャートの処理を終了する。即ち、ＣＰＵ２０１は、上記のＳ５０２〜Ｓ５０８の処理を、規制ルールの設定処理の終了指示を受けるまで（ステップＳ５０９でＹｅｓと判断するまで）繰り返す。以上がプロキシサーバ１０１のＣＰＵ２０１によって行われる規制ルール情報設定処理の一例である。
【００８１】
以下、図１０を参照して、図４のステップＳ４０３に示したＨＴＴＰリクエストの制御処理を詳細に説明する。
【００８２】
図１０は、本発明における第３の制御処理の一例を示すフローチャートであり、図４のステップＳ４０３に示したＨＴＴＰリクエストの制御処理の詳細を示すフローチャートに対応する。即ち、本処理は、プロキシサーバのＣＰＵ２０１によって行われる。なお、本処理を行う際に、ＣＰＵ２０１は、ＵＲＬカテゴリ判定手段３０３、リクエストの詳細情報取得手段３０４、通信中継制御手段３０５及び通信許可／不許可応答送信手段３０６としてプロキシサーバ１０１を機能させるためのプログラムをＨＤＤ２０４からＲＡＭ２０２にロードし、そのプログラムの制御に基づいて以下に示す処理を行うこととなる。
【００８３】
プロキシサーバ１０１のＣＰＵ２０１は、常時ＬＡＮ１０５上を流れるパケットを常時監視している。そして、クライアントＰＣ１０４から広域ネットワーク１０６に設置されているウェブサーバ１０７に対してのＨＴＴＰリクエストを受け付ける（ステップＳ１００１）。
【００８４】
そして、ＣＰＵ２０１は、リクエストされたＵＲＬをＵＲＬＤＢ１０２中に登録されているかを確認してカテゴリを判定する（ステップＳ１００２）。ここで、ＵＲＬカテゴリの判定処理の詳細について図１１を参照して説明する。
【００８５】
図１１は、本発明における第３の制御処理の一例を示すフローチャートであり、図１０のステップＳ１００２に示したＵＲＬカテゴリ判定処理の詳細を示すフローチャートに対応する。即ち、本処理は、プロキシサーバのＣＰＵ２０１によって行われる。なお、本処理を行う際に、ＣＰＵ２０１は、ＵＲＬカテゴリ判定手段３０３としてプロキシサーバ１０１を機能させるためのプログラムをＨＤＤ２０４からＲＡＭ２０２にロードし、そのプログラムの制御に基づいて以下に示す処理を行うこととなる。
【００８６】
図１１のステップＳ１１０１において、ＣＰＵ２０１は、ＵＲＬＤＢ１０２からリクエストされたＵＲＬがどのカテゴリに属するか検索する。ここでＵＲＬＤＢの詳細について図１２を参照して説明する。
【００８７】
図１２はＵＲＬＤＢ１００２の一例を示す図である。図１２では、各ＵＲＬ１２０３を大カテゴリ１２０１と小カテゴリ１２０２に分類して格納している。
【００８８】
図１１のステップＳ１１０１では、ＵＲＬＤＢ１００２からリクエストされたＵＲＬがどのカテゴリに属するか検索する。
【００８９】
次に、ステップＳ１１０２において、ＣＰＵ２０１は、ステップＳ１１０１で検索した結果該当するカテゴリがない場合は（ステップＳ１１０２でＮｏ）カテゴリなしと判定する。
【００９０】
一方、ステップＳ１１０２において、該当するカテゴリがあると判定した場合（ステップＳ１１０２でＹｅｓ）にはステップＳ１１０３に進み、ＨＴＴＰリクエストに対するカテゴリ情報をセットし、以降の処理を行う。
【００９１】
以下、図１０のフローチャートの説明に戻る。
【００９２】
図１０のステップＳ１００３において、ＣＰＵ２０１は、ＨＴＴＰリクエストの詳細情報を取得する。ここで、図１３を参照してファイル形式の判定処理の詳細について説明する。
【００９３】
図１３は、本発明における第４の制御処理の一例を示すフローチャートであり、図１０のステップＳ１００３に示したリクエストの詳細情報取得処理の詳細を示すフローチャートに対応する。即ち、本処理は、プロキシサーバのＣＰＵ２０１によって行われる。なお、本処理を行う際に、ＣＰＵ２０１は、リクエストの詳細情報取得手段３０４としてプロキシサーバ１０１を機能させるためのプログラムをＨＤＤ２０４からＲＡＭ２０２にロードし、そのプログラムの制御に基づいて以下に示す処理を行うこととなる。
【００９４】
図１３のステップＳ１３０１においてＨＴＴＰリクエストにデータファイルが添付されているかを判定する。データファイルが添付されていない（ステップＳ１３０１でＮｏ）場合は、ステップＳ１３０７の処理に進む。
【００９５】
一方、ステップＳ１３０１でＨＴＴＰリクエストにデータファイルが添付されていると判定された（ステップＳ１３０１でＹｅｓ）場合は、ステップＳ１３０２において、データファイルの先頭もしくは末尾にあるシグネチャからデータファイルのファイル形式を判定する。データファイルのファイル形式の判定には図１４に示すようなファイル形式識別子とシグネチャの対応表を使用する。これは、プロキシサーバ１０１の記憶領域にきおくされている。尚、添付ファイルが圧縮データであった場合にはそのデータを解凍し、解凍後のデータを用いて以降の処理を行う。
【００９６】
図１４に示すようにデータファイルがＰＤＦの場合は先頭の４バイトが％ＰＤＦとなる。データファイルにはこのようにデータファイルの先頭や末尾にそれぞれのデータファイルに固有のシグネチャがあるため、この情報を用いてステップＳ１３０２においてデータファイルのファイル形式を判定する。
【００９７】
ステップＳ１３０３では、データファイルに付与されている拡張子を取得する。
【００９８】
ステップＳ１３０４では、データファイルのサイズを取得する。
【００９９】
その後、判定した添付ファイルのファイル形式がテキスト情報を含む形式であるかをステップＳ１３０５において判定する。テキスト情報を含まない画像のような形式（ステップＳ１３０５でＮｏ）の場合は、ステップＳ１３０７に処理を進める。
【０１００】
一方、添付ファイルがテキスト情報を含む形式である（ステップＳ１３０５でＹｅｓ）場合は、ステップＳ１３０２で取得したデータファイルのファイル形式に適した方法でデータファイルからテキスト情報を取得する（ステップＳ１３０６）。
【０１０１】
ステップＳ１３０７ではＨＴＴＰリクエストのＢｏｄｙから添付ファイルのフィールド以外にテキスト情報が含まれる場合は、それらのフィールドからテキスト情報を取得する。この処理で取得したテキスト情報は、以降で説明する規制ルール適用処理においてキーワード条件が合致するかを判定するために使用される。
以下、図１０のフローチャートの説明に戻る。
【０１０２】
図１０のステップ１００４においてＣＰＵ２０１は、ステップＳ１００２、およびステップＳ１００３で取得したＵＲＬのカテゴリや添付ファイルに関する情報などをもとに規制ルールを適用する。なお、規制ルールの適用処理の詳細は図１５を参照して後述する。
【０１０３】
次に、ステップＳ１００５において、ＣＰＵ２０１は、ステップＳ１００４の規制ルールの適用処理で通信許可となったか否かを判断する。そして、規制ルールの適用処理で通信不許可となったと判断した場合には（ステップＳ１００５でＮｏ）、ＣＰＵ２０１は、ＨＴＴＰリクエストを送信したクライアントＰＣ１０４に対して不許可応答を送信し（ステップＳ１００６）、本フローチャートの処理を終了する。
【０１０４】
一方、ステップＳ１００５において、ステップＳ１００４の規制ルールの適用処理で通信許可となったと判断した場合には（ステップＳ１００５でＹｅｓ）、ＣＰＵ２０１は、ステップＳ１００７に処理を進める。
ステップＳ１００７では、ＣＰＵ２０１は、ステップＳ１００５で送信許可とされたＨＴＴＰリクエストをウェブサーバに中継する。
【０１０５】
ステップＳ１００８では、ＣＰＵ２０１は、ウェブサーバからの応答を受信するまで待機し、ウェブサーバからの応答を受信したと判断した場合には、ステップＳ１００９に処理を進める。
【０１０６】
ステップＳ１００９では、ＣＰＵ２０１は、ＨＴＴＰリクエストを送信したクライアントＰＣ１０４に対してウェブサーバの応答を中継し、本フローチャートの処理を終了する。
【０１０７】
以下、図１５を参照して、図１０のステップＳ１００４に示した規制ルールの適用処理について詳細に説明する。
【０１０８】
図１５は、本発明における第５の制御処理の一例を示すフローチャートであり、図１０のステップＳ１００４に示した規制ルールの適用処理の詳細を示すフローチャートに対応する。即ち、本処理は、プロキシサーバのＣＰＵ２０１によって行われる。なお、本処理を行う際に、ＣＰＵ２０１は、通信中継制御手段３０５としてプロキシサーバ１０１を機能させるためのプログラムをＨＤＤ２０４からＲＡＭ２０２にロードし、そのプログラムの制御に基づいて以下に示す処理を行うこととなる。
【０１０９】
図１５のステップＳ１５０１において、まだ適用していない規制ルールがあるかどうか否かを判断する。まだ適用していない規制ルールがあった場合には（ステップＳ１５０１でＹｅｓ）、ＣＰＵ２０１は、規制ルールテーブル９００に登録されているまだ未適用の規制ルールを適用順９０２に従って取得する（ステップＳ１５０２）。
【０１１０】
ステップＳ１５０３では、ＣＰＵ２０１は、ＨＴＴＰリクエストのＵＲＬもしくはＵＲＬが属するカテゴリ、添付ファイルのファイル形式、拡張子などの情報がステップＳ１５０２で取得した規制ルールの条件に合致（マッチ）するか否かを判断する。また、規制ルールの合致を判断する処理では、添付ファイルのファイル形式と拡張子が一致するかについても確認を行う。ここで、ＨＴＴＰリクエストが規制ルールに合致するか判定する処理の詳細について図１６を用いて説明する。
【０１１１】
図１６は、本発明における第６の制御処理の一例を示すフローチャートであり、図１５のステップＳ１５０３に示したＨＴＴＰリクエストが規制ルールにマッチするか判定する処理の詳細を示すフローチャートに対応する。即ち、本処理は、プロキシサーバのＣＰＵ２０１によって行われる。
【０１１２】
図１６のステップＳ１６０１において、規制ルール９００のうち、ステップＳ１５０２で取得した規制ルールのＵＲＬ９０４にＵＲＬが登録されているか否かを判断する。ＵＲＬが登録されていない場合は（ステップＳ１６０１でＮｏ）、ＣＰＵ２０１は、ステップＳ１６０３に処理を進める。一方、ＵＲＬが登録されている場合は（ステップＳ１６０１でＹｅｓ）、ＣＰＵ２０１は、ステップＳ１６０２に処理を進める。
【０１１３】
ステップＳ１６０２では、ＨＴＴＰリクエストのＵＲＬとＵＲＬ９０４に登録されているＵＲＬがマッチするか否かを判断する。マッチしないと判断した場合は（ステップＳ１６０２でＮｏ）、ＨＴＴＰリクエストに規制ルールがマッチしないと判断して処理を終了する（ステップＳ１６１４）。一方、マッチすると判断した場合は（ステップＳ１６０２でＹｅｓ）、ＣＰＵ２０１は、ステップＳ１６０３に処理を進める。
【０１１４】
ステップＳ１６０３では、規制ルール９００のうち、ステップＳ１５０２で取得した規制ルールのＵＲＬ９０５にカテゴリが登録されているか否かを判断する。カテゴリが登録されていない場合は（ステップＳ１６０３でＮｏ）、ＣＰＵ２０１は、ステップＳ１６０５に処理を進める。一方、カテゴリが登録されている場合は（ステップＳ１６０３でＹｅｓ）、ＣＰＵ２０１は、ステップＳ１６０４に処理を進める。
【０１１５】
ステップＳ１６０４では、ＨＴＴＰリクエストからＵＲＬカテゴリ判定手段３０３で取得したカテゴリとカテゴリ９０５に登録されているカテゴリがマッチするか否かを判断する。マッチしないと判断した場合は（ステップＳ１６０４でＮｏ）、ＨＴＴＰリクエストに規制ルールがマッチしないと判断して処理を終了する（ステップＳ１６１４）。また、ＵＲＬカテゴリ判定手段３０３でカテゴリなしと判定された場合もＨＴＴＰリクエストに規制ルールがマッチしないと判断して処理を終了する（ステップＳ１６１４）。一方、マッチすると判断した場合は（ステップＳ１６０４でＹｅｓ）、ＣＰＵ２０１は、ステップＳ１６０５に処理を進める。
【０１１６】
ステップＳ１６０５では、規制ルール９００のうち、ステップＳ１５０２で取得した規制ルールのファイル形式９０６にファイル形式が登録されているか否かを判断する。ファイル形式が登録されていない場合は（ステップＳ１６０５でＮｏ）、ＣＰＵ２０１は、ステップＳ１６０７に処理を進める。一方、ファイル形式が登録されている場合は（ステップＳ１６０５でＹｅｓ）、ＣＰＵ２０１は、ステップＳ１６０６に処理を進める。
【０１１７】
ステップＳ１６０６では、ＨＴＴＰリクエストからリクエストの詳細情報取得手段３０４で取得したファイル形式とファイル形式９０６に登録されているファイル形式がマッチするか否かを判断する。マッチしないと判断した場合は（ステップＳ１６０６でＮｏ）、ＨＴＴＰリクエストに規制ルールがマッチしないと判断して処理を終了する（ステップＳ１６１４）。また、ＨＴＴＰリクエストにデータファイルが添付されていない場合も、ＨＴＴＰリクエストに規制ルールがマッチしないと判断して処理を終了する（ステップＳ１６１４）。一方、マッチすると判断した場合は（ステップＳ１６０６でＹｅｓ）、ＣＰＵ２０１は、ステップＳ１６０７に処理を進める。
【０１１８】
ステップＳ１６０７では、規制ルール９００のうち、ステップＳ１５０２で取得した規制ルールにサイズ９０７及びサイズ条件９０８が登録されているか否かを判断する。サイズ及びサイズ条件が登録されていない場合は（ステップＳ１６０７でＮｏ）、ＣＰＵ２０１は、ステップＳ１６０９に処理を進める。一方、サイズ及びサイズ条件が登録されている場合は（ステップＳ１６０７でＹｅｓ）、ＣＰＵ２０１は、ステップＳ１６０８に処理を進める。
【０１１９】
ステップＳ１６０８では、ＨＴＴＰリクエストからリクエストの詳細情報取得手段３０４で取得したデータファイルのサイズがサイズ９０７およびサイズ条件９０８に登録されている条件にマッチするか否かを判断する。マッチしないと判断した場合は（ステップＳ１６０８でＮｏ）、ＨＴＴＰリクエストに規制ルールがマッチしないと判断して処理を終了する（ステップＳ１６１４）。また、ＨＴＴＰリクエストにデータファイルが添付されていない場合も、ＨＴＴＰリクエストに規制ルールがマッチしないと判断して処理を終了する（ステップＳ１６１４）。一方、マッチすると判断した場合は（ステップＳ１６０８でＹｅｓ）、ＣＰＵ２０１は、ステップＳ１６０９に処理を進める。
【０１２０】
ステップＳ１６０９では、規制ルール９００のうち、ステップＳ１５０２で取得した規制ルールのファイル形式と拡張子９０９にファイル形式と拡張子の一致条件が登録されているか否かを判断する。ファイル形式と拡張子の一致条件が登録されていない場合は（ステップＳ１６０９でＮｏ）、ＣＰＵ２０１は、ステップＳ１６１１に処理を進める。一方、ファイル形式と拡張子の一致条件が登録されている場合は（ステップＳ１６０９でＹｅｓ）、ＣＰＵ２０１は、ステップＳ１６１０に処理を進める。
【０１２１】
ステップＳ１６１０では、ＨＴＴＰリクエストからリクエストの詳細情報取得手段３０４で取得したデータファイルのファイル形式と拡張子がファイル形式と拡張子９０９に登録されている条件にマッチするか否かを判断する。ここで添付ファイルのファイル形式と拡張子が一致するかを確認する処理について図１７を用いて説明する。
【０１２２】
図１７は、ファイル形式を表すファイル形式識別子１７０１と、そのファイル形式に対して一般的に付与される拡張子１７０２の対応を示したものである。図１７に示す対応表は、プロキシサーバ１０１に記憶されている。ここで図１７のファイル形式識別子１７０１は、ＨＴＴＰリクエストに添付されたデータファイルのファイル形式を判定するためのデータ１４００（図１４）のファイル形式識別子１４０１に対応する。ファイル形式識別子に対する拡張子の対応データ１７００は、規制ルール適用処理プログラムに組み込んでもよいし、他の形式で保持していても構わない。
【０１２３】
添付ファイルのファイル形式と付与されている拡張子が一致しているか否かの判断では、添付ファイルのファイル形式と付与されている拡張子をファイル形式識別子に対する拡張子の対応データ１７００と照らし合わせて、一致するもしくは一致しないを判断する。つまり、添付ファイルのファイル形式に対応する識別子をファイル形式識別子１７０１から検索し、そのファイル形式に対して一般的に付与される拡張子１７０２を取得する。添付ファイルに付与されている拡張子が慨取得した拡張子１７０２の中にある場合は添付ファイルのファイル形式と付与されている拡張子が一致すると判断し、ない場合は一致しないと判断する。
【０１２４】
以下、図１６のフローチャートの説明に戻る。
【０１２５】
ステップＳ１６１０において、ＨＴＴＰリクエストからリクエストの詳細情報取得手段３０４で取得したデータファイルのファイル形式と拡張子がファイル形式と拡張子９０９に登録されている条件にマッチするか判断し、マッチしないと判断した場合は（ステップＳ１６１０でＮｏ）、ＨＴＴＰリクエストに規制ルールがマッチしないと判断して処理を終了する（ステップＳ１６１４）。また、ＨＴＴＰリクエストにデータファイルが添付されていない場合も、ＨＴＴＰリクエストに規制ルールがマッチしないと判断して処理を終了する（ステップＳ１６１４）。一方、マッチすると判断した場合は（ステップＳ１６１０でＹｅｓ）、ＣＰＵ２０１は、ステップＳ１６１１に処理を進める。
【０１２６】
ステップＳ１６１１では、規制ルール９００のうち、ステップＳ１５０２で取得した規制ルールのキーワード９１０にキーワードが登録されているか否かを判断する。キーワードが登録されていない場合は（ステップＳ１６１１でＮｏ）、ＣＰＵ２０１は、ステップＳ１６１３に処理を進める。一方、キーワードが登録されている場合は（ステップＳ１６１１でＹｅｓ）、ＣＰＵ２０１は、ステップＳ１６１２に処理を進める。
【０１２７】
ステップＳ１６１２では、ＨＴＴＰリクエストからリクエストの詳細情報取得手段３０４で取得したテキスト情報がキーワード９１０に登録されているキーワードにマッチするか判断する。マッチしないと判断した場合は（ステップＳ１６１２でＮｏ）、ＨＴＴＰリクエストに規制ルールがマッチしないと判断して処理を終了する（ステップＳ１６１４）。また、ＨＴＴＰリクエストにテキスト情報が含まれない場合も、マッチしないと判断して処理を終了する（ステップＳ１６１４）。一方、マッチすると判断した場合は（ステップＳ１６１２でＹｅｓ）、ＣＰＵ２０１は、ステップＳ１６１３に処理を進める。
【０１２８】
ステップＳ１６１３では、ＨＴＴＰリクエストが規制ルールにマッチすると判断して処理を終了する。
以下、図１５のフローチャートの説明に戻る。
【０１２９】
規制ルールの条件に合致（マッチ）すると判断した場合には（ステップＳ１５０３でＹｅｓ）、ＣＰＵ２０１は、当該規制ルールの動作として示されている制御を行い（許可／不許可し）（ステップＳ１５０４）、本フローチャートの処理を終了する。
一方、規制ルールの条件に合致（マッチ）しないと判断した場合には（ステップＳ１５０３でＮｏ）、ＣＰＵ２０１はステップＳ１５０１に処理を戻す。
【０１３０】
そしてステップＳ１５０１で、まだ適用していない規制ルールがないと判断した場合には（ステップＳ１５０１でＮｏ）、ＣＰＵ２０１は、予め規制ルールＤＢ１０３に設定されているデフォルト（全ての規制ルールに適合しなかった場合の）動作を行い（許可／不許可）（ステップＳ１５０５）、本フローチャートの処理を終了する。以上が図１０のステップＳ１００４の規制ルール適用処理の詳細な説明である。
【０１３１】
以上説明したように、本発明によれば、ＨＴＴＰリクエストに付与されているＣｏｎｔｅｎｔ−Ｔｙｐｅによらず、ＨＴＴＰリクエストに添付されているデータファイルのファイル形式を判定し、データファイルのファイル形式に適した方法でデータファイルの情報を取得し、データファイルの送信制御を行うことが可能となる。また、データファイルのファイル形式と付与されている拡張子が一致しない場合にもＨＴＴＰリクエストを許可もしくは不許可とするといった制御を行うことが可能となる。
【０１３２】
以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記録媒体等としての実施態様をとることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
【０１３３】
また、規制ルール詳細設定画面７００においてクライアントＰＣのＩＰアドレスを設定できるようにしても良い。この場合は、特定のＩＰアドレスを持つクライアントＰＣ１０４が行ったＨＴＴＰリクエストに対して規制ルールを適用するといった制御が可能になる。
【０１３４】
もしくは、規制ルール詳細設定画面７００においてユーザおよびユーザグループを設定できるようにしても良い。この場合は、特定のユーザおよびユーザグループが行ったＨＴＴＰリクエストに対して規制ルールを適用するといった制御が可能になる。
【０１３５】
また、ＨＴＴＰＳといった暗号化通信の場合は、リクエストの詳細情報を取得して規制ルールを適用することができないが、その場合は暗号化通信であれば、リクエストを不許可とするように設定可能にしても良い。もちろん、何らかの手段により、暗号化されたリクエストの詳細情報を取得できる場合は、規制ルールを適用して許可／不許可の制御を行っても構わない。
【０１３６】
以上説明したように、本実施の形態によれば、データの送信先に応じてデータの拡張子が偽装されているかを判定することにより、情報漏洩を防止させることができる。
【０１３７】
以上、本発明の一実施形態を詳述したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様をとることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
【０１３８】
また、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出し実行することによっても、達成されることは言うまでもない。
【０１３９】
この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、プログラムコード自体及びそのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【０１４０】
プログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭ等を用いることができる。
【０１４１】
また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（基本システム或いはオペレーティングシステム）などが実際の処理の一部又は全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１４２】
さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部又は全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【符号の説明】
【０１４３】
１０１ プロキシサーバ １０２ ＵＲＬデータベース １０３ 期性ルールデータベース １０４−１ クライアントＰＣ １０４−２ クライアントＰＣ １０４−３ クライアントＰＣ １０５ ＬＡＮ １０６ 広域ネットワーク １０７−１ ウェブサーバ １０７−２ ウェブサーバ １０７−３ ウェブサーバ
【技術分野】
【０００１】
本発明は、情報処理装置、情報処理方法及びプログラムに関し、特に、データの送信制御技術に関するものである。
【背景技術】
【０００２】
ウェブサーバ上で電子メールの閲覧や送信を可能にするウェブメールサービスやドキュメントファイルの管理や共有を行うドキュメント管理サービスが提供されている。従来これらのサービスは、ユーザのコンピュータ上でソフトウェアを実行することにより行われてきたが、近年ではコンピューターネットワーク上にあるサービス提供者のコンピュータでソフトウェアを実行し、ユーザはサービスを利用するといった形態で行われることが多くなってきている。このようなサービスの利用はこれまで一般ユーザが主であったが、近年では、企業などがこれらのサービスを業務で利用する事例も増えてきている。これらのサービスはＳａａＳなどと呼ばれ、今後利用が増えてくると考えられる。
【０００３】
これらのサービスは便利である反面、企業などが業務として利用する場合は外部ネットワークに重要な情報が漏えいしてしまうといった危険性がある。特にＨＴＴＰ通信でデータファイルを送信するようなサービスの増加が考えられるため、ＨＴＴＰ通信で送信されるデータファイルの制御が重要となる。また、業務としての利用を許可している以外のサービスを利用することによって重要な情報が漏えいしてしまうといった事態も考えられる。
【０００４】
以上の問題への対応として、ＨＴＴＰアクセスを特定のウェブサイトにのみ制限したり、データファイルの送信を制御したりすることが必要となる。
【０００５】
特定のウェブサイトにのみアクセスを許可するような技術としては、例えば特許文献１が開示されている。係る技術によれば、特定のサイトにのみＨＴＴＰアクセスを許可するといった制御が可能となる。
【０００６】
また、データファイルの形式を判定する技術としては、例えば特許文献２が開示されている。係る技術によれば、データファイルの特徴を解析し、その結果からデータファイルの形式を推定することが可能となる。
【特許文献１】特開２００４−３４８２０２号公報
【特許文献２】特開２００１−１０１０４９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
ＨＴＴＰリクエストで送信されるデータファイルの制御を行うには、ＨＴＴＰリクエストに添付されるデータファイルのファイル形式を判定する必要がある。
【０００８】
また、データファイルに対して特定のキーワードが含まれていないか検査する場合、あらかじめ、ファイル形式に適した方法でテキスト情報を抽出する必要があり、データファイルのファイル形式の判定が必要となる。
【０００９】
ＨＴＴＰリクエストに添付されるデータファイルのファイル形式はブラウザ等のＨＴＴＰクライアントがＨＴＴＰリクエストに付与するＣｏｎｔｅｎｔ−Ｔｙｐｅで判定することが可能である。しかし、通常ＨＴＴＰクライアントはファイルの拡張子に関連付けてＣｏｎｔｅｎｔ−Ｔｙｐｅを決定するため、ファイルに誤った拡張子が付与されていたり、意図的に変更されたりしている場合は、Ｃｏｎｔｅｎｔ−Ｔｙｐｅからファイル形式が判定できないという問題がある。
【００１０】
また、Ｃｏｎｔｅｎｔ−ＴｙｐｅはＨＴＴＰクライアントが付与するものであるため、そもそも信頼できないといった問題もある。そのため、ＨＴＴＰリクエストのＣｏｎｔｅｎｔ−Ｔｙｐｅに基づく制御では、ＨＴＴＰリクエストによるデータファイルの送信を正しく制御できないという問題がある。
【００１１】
そのため、例えば、情報漏洩を防止するため、所定のファイル形式の文書データのみを、所定のウェブサイトへの送信許可とする送信制御システムを運用する場合、Ｃｏｎｔｅｎｔ−Ｔｙｐｅに基づく制御のみでは、悪意のあるユーザが、ファイル名の拡張子を送信が許可されているファイル形式の拡張子に変更することにより、あたかも送信が許可されているファイルであるかのように判断され送信されてしまう恐れがある。
本発明の目的は、データの送信先に応じてデータの拡張子が偽装されているかを判定することにより、情報漏洩を防止する仕組みを提供することである。
【課題を解決するための手段】
【００１２】
本発明は、データを出力するクライアント装置と通信可能であり、当該データの送信制御を行う情報処理装置であって、ファイルの送信先を特定する送信先情報と、当該送信先に対して当該ファイルの拡張子の偽装があるときに当該ファイルの送信を許可するか禁止するかが設定された設定情報とを対応づけた送信ルール情報を記憶する記憶手段と、前記クライアント装置から出力された前記ファイルの送信要求に対して、当該ファイル内のデータから判定されるファイル形式と当該ファイルのファイル名の拡張子から判定されるファイル形式とが同じであるかを判定する偽装判定手段と、前記偽装判定手段でファイル形式が異なると判定された場合、前記ファイルの送信先に対応した前記送信ルール情報に従って、当該ファイルの送信を許可するか禁止するかを制御する送信制御手段と、を備えることを特徴とする。
【００１３】
本発明は、データを出力するクライアント装置と通信可能であり、当該データの送信制御を行う情報処理装置における情報処理方法であって、記憶手段が、ファイルの送信先を特定する送信先情報と、当該送信先に対して当該ファイルの拡張子の偽装があるときに当該ファイルの送信を許可するか禁止するかが設定された設定情報とを対応づけた送信ルール情報を記憶する記憶工程と、偽装判定手段が、前記クライアント装置から出力された前記ファイルの送信要求に対して、当該ファイル内のデータから判定されるファイル形式と当該ファイルのファイル名の拡張子から判定されるファイル形式とが同じであるかを判定する偽装判定工程と、送信制御手段が、前記偽装判定工程でファイル形式が異なると判定された場合、前記ファイルの送信先に対応した前記送信ルール情報に従って、当該ファイルの送信を許可するか禁止するかを制御する送信制御工程と、を備えることを特徴とする。
【００１４】
本発明は、データを出力するクライアント装置と通信可能であり、当該データの送信制御を行う情報処理装置として機能させるプログラムであって、ファイルの送信先を特定する送信先情報と、当該送信先に対して当該ファイルの拡張子の偽装があるときに当該ファイルの送信を許可するか禁止するかが設定された設定情報とを対応づけた送信ルール情報を記憶する記憶手段と、前記クライアント装置から出力された前記ファイルの送信要求に対して、当該ファイル内のデータから判定されるファイル形式と当該ファイルのファイル名の拡張子から判定されるファイル形式とが同じであるかを判定する偽装判定手段と、前記偽装判定手段でファイル形式が異なると判定された場合、前記ファイルの送信先に対応した前記送信ルール情報に従って、当該ファイルの送信を許可するか禁止するかを制御する送信制御手段として機能させることを特徴とする。
【発明の効果】
【００１５】
本発明によれば、データの送信先に応じてデータの拡張子が偽装されているかを判定することにより、情報漏洩を防止することができる。
【図面の簡単な説明】
【００１６】
【図１】本発明の一実施形態に係るシステムの構成を示す図である。
【図２】情報処理装置のハードウェア構成を示す図である。
【図３】図３は、プロキシサーバ１０１の機能構成を示す図である。
【図４】図４は、本発明における第１の制御処理の一例を示すフローチャートである。
【図５】図５は、本発明における第２の制御処理の一例を示すフローチャートである。
【図６】図６は、規制ルール設定画面の一例を示す図である。
【図７】図７は、規制ルール詳細設定画の一例を示す図である。
【図８】図８は、規制ルール移動画面の一例を示す図である。
【図９】図９は、規制ルールテーブルの一例を示す図である。
【図１０】図１０は、本発明における第３の制御処理の一例を示すフローチャートである。
【図１１】図１１は、図１０に示す第３の制御処理のステップＳ１００２の詳細処理を示すフローチャートである。
【図１２】図１２は、ＵＲＬＤＢ１００２の一例を示す図である。
【図１３】図１３は、本発明における第４の制御処理の一例を示すフローチャートである。
【図１４】図１４は、ファイル形式識別子とシグネチャの対応表の一例を示す図である。
【図１５】図１５は、本発明における第５の制御処理の一例を示すフローチャートである。
【図１６】図１６は、本発明における第６の制御処理の一例を示すフローチャートである。
【図１７】図１７は、ファイル形式を表すファイル形式識別子１７０１と、そのファイル形式に対して一般的に付与される拡張子１７０２との対応を示した表の一例である。
【発明を実施するための最良の形態】
【００１７】
以下、添付図面を参照して、本発明を好適な実施形態に従って詳細に説明する。
図１は、本実施形態に係るシステムの構成例を示す図である。
【００１８】
図１に示す如く、本実施形態に係るシステムは、プロキシサーバ１０１、ＵＲＬＤＢ１０２、規制ルールＤＢ１０３、クライアントＰＣ１０４−１乃至１０４−３（以後、まとめて「クライアントＰＣ１０４」とする）、ＬＡＮ（ローカルエリアネットワーク）１０５、広域ネットワーク１０６（以下、ネットワーク）、ウェブサーバ１０７−１乃至１０７−３（以後、まとめて「ウェブサーバ１０７」とする）により構成されている。以下、本実施形態に係るシステムを構成するこれらについて説明する。
プロキシサーバ１０１は、本発明の情報処理装置として機能する装置であり、クライアントＰＣ１０４とウェブサーバ１０７との間のデータ通信を中継する。
【００１９】
また、プロキシサーバ１０１は、ウェブサイトのＵＲＬを特定カテゴリごとに集めたＵＲＬＤＢ１０２および、クライアントＰＣ１０４からウェブサーバ１０７へのＨＴＴＰリクエストを許可する／拒否するといった制御に使用する規制ルールが登録されている規制ルールＤＢ１０３を備えている。
【００２０】
また、プロキシサーバ１０１は、さらに規制ルールＤＢ１０３に設定されている情報の登録、修正等を行わせるための設定ページの提供等を行うウェブサーバ機能なども有している。尚、ＵＲＬＤＢ１０２および規制ルールＤＢ１０３は、プロキシサーバ１０１内に備えていても、別のコンピュータ内に実装しても構わない。
【００２１】
ＵＲＬＤＢ１０２はウェブサイトのＵＲＬをカテゴリごとに集めたデータベースであり、通常ＵＲＬＤＢ作成業者から購入するなどする場合が多い。ＵＲＬＤＢ１０２の更新はプロキシサーバ１０１の更新プログラムで行っても良いし、他の手段により更新してもよい。
クライアントＰＣ１０４は、ウェブサーバ１０７が提供するサービスを利用するユーザが使用する端末装置である。
【００２２】
ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）１０５は、プロキシサーバ１０１及びクライアントＰＣ１０４をデータ通信可能に相互に接続させるものである。広域ネットワーク１０６は、インターネット等の広域ネットワークを示す。
【００２３】
ウェブサーバ１０７は、ウェブメールサービスやドキュメント管理サービスなどウェブサーバ上で提供されるさまざまなサービスを提供するサーバを表す。
図２は、プロキシサーバ１０１のハードウェア構成を示すブロック図である。
【００２４】
図２において、２０１はＣＰＵで、ＲＡＭ２０２やＲＯＭ２０３に記憶されているプログラムやデータを用いてプロキシサーバ１０１全体の制御を行うとともに、プロキシサーバ１０１が行う後述の各処理を実行する。
【００２５】
２０２はＲＡＭで、ＨＤＤ（ハードディスクドライブ）２０４や記録媒体ドライブ２０６からロードされたプログラムやデータ、ネットワークＩ／Ｆ（インターフェース）２０５を介して他の機器から受信したプログラムやデータ等を一時的に記憶するためのエリアや、ＣＰＵ２０１が各種の処理を実行する際に用いるワークエリア等、各種のエリアを適宜提供することができる。
【００２６】
２０３はＲＯＭで、プロキシサーバ１０１の設定データや、ブートプログラム等を記憶する。
【００２７】
２０４はＨＤＤで、ＯＳ（オペレーティングシステム）や、プロキシサーバ１０１が行う後述の各処理をＣＰＵ２０１に実行させるためのプログラムやデータ等を保存するものであり、これらはＣＰＵ２０１による制御に従って適宜ＲＡＭ２０２にロードされ、ＣＰＵ２０１の処理対象となる。
【００２８】
２０５はネットワークＩ／Ｆで、プロキシサーバ１０１を上記ＬＡＮ１０５、広域ネットワーク１０６に接続させるためのものであり、プロキシサーバ１０１はこのネットワークＩ／Ｆ２０５を介してＬＡＮ１０５や広域ネットワーク１０６に接続されている各装置とのデータ通信を行う。
【００２９】
２０６は記録媒体ドライブで、ＣＤ−ＲＯＭ、ＣＤ−Ｒ／ＲＷ、ＤＶＤ−ＲＯＭ、ＤＶＤ−Ｒ／ＲＷ、ＤＶＤ−ＲＡＭ等の記録媒体に記録されているプログラムやデータを読み出し、ＲＡＭ２０２やＨＤＤ２０４に出力する。なお、ＨＤＤ２０４が保持しているデータのうちの一部をこれら記録媒体に記憶させておいても良い。
【００３０】
２０７はキーボード、２０８はマウスやジョイスティック等により構成されているポインティングデバイスで、プロキシサーバ１０１の操作者が操作することで、各種の指示をＣＰＵ２０１に対して入力する入力部として機能する。
２０９は表示部で、ＣＲＴや液晶画面などにより構成されており、ＣＰＵ２０１による処理結果を画像や文字などで表示する。
【００３１】
２１０は外部機器接続Ｉ／Ｆで、周辺機器をプロキシサーバ１０１に接続させるためものポートである。プロキシサーバ１０１は、この外部機器接続Ｉ／Ｆ２１０を介して、周辺機器とのデータ通信を行う。外部機器接続Ｉ／Ｆ２１０は、ＵＳＢやＩＥＥＥ１３９４等により構成されており、通常複数の外部機器接続Ｉ／Ｆ２１０を有する。周辺機器との接続形態は有線／無線を問わない。
【００３２】
２１１はバスで、上述の各部２０１〜２１０を接続する。
【００３３】
なお、プロキシサーバ１０１のハードウェア構成は、図２に示した構成を有するとして説明するが、必ずしも同図の構成を有することに限定するものではなく、プロキシサーバ１０１が行う後述の各種処理を実行可能であればプロキシサーバ１０１の構成は適宜変更しても良い。
【００３４】
また、クライアントＰＣ１０４、ウェブサーバ１０７のハードウェア構成も、これらには一般的なコンピュータを適用するので、周知の如く、概ね図２に示した構成を有する。
【００３５】
図３は、プロキシサーバ１０１の機能構成を示す図である。
【００３６】
図３に示すように、プロキシサーバ１０１は、規制ルール受付手段３０１、規制ルール記録手段３０２、ＵＲＬカテゴリ判定手段３０３、リクエストの詳細情報取得手段３０４、通信中継制御手段３０５、通信許可／不許可応答送信手段３０６を備えている。
【００３７】
規制ルール受付手段３０１は、ＨＴＴＰリクエストの許可／不許可を判断するための規制ルールの入力を受け付ける。規制ルール記録手段３０２は、規制ルール受付手段３０１で受け付けたルール（詳細は後述する図９）を規制ルールＤＢ１０３に登録する。
【００３８】
ＵＲＬカテゴリ判定手段３０３は、ＵＲＬＤＢ１０２に登録された情報に基づいて、クライアントＰＣ１０４からリクエストされたＵＲＬがどのカテゴリに属するかを判定する。
【００３９】
リクエストの詳細情報取得手段３０４は、ＨＴＴＰリクエストに添付されたデータファイルのシグネチャからデータファイルのファイル形式を判定する。
【００４０】
通信中継制御手段３０５は、ＵＲＬカテゴリ判定手段３０３によって取得したＨＴＴＰリクエストのカテゴリ情報と、リクエストの詳細情報取得手段３０４よって取得したファイル形式情報を、規制ルールＤＢ１０３に記録された規制ルールに照らし合わせ、その結果によりＨＴＴＰリクエストの許可／拒否の制御（送信規制制御）を行う。
【００４１】
通信許可／不許可応答送信手段３０６は、通信中継制御手段３０５で許可したＨＴＴＰリクエストを行ったクライアントＰＣ１０３に対してウェブサーバからの応答を中継する、あるいは不許可としたＨＴＴＰリクエストを行ったクライアントＰＣに対してＨＴＴＰリクエストを拒否した旨の通知を行う。
【００４２】
なお、プロキシサーバ１０１のＨＤＤ２０４には、規制ルール受付手段３０１、規制ルール記録手段３０２、ＵＲＬカテゴリ判定手段３０３、リクエストの詳細情報取得手段３０４、通信中継制御手段３０５、通信許可／不許可応答送信手段３０６としてプロキシサーバを制御させるためのプログラムが記録されている。そして、これらのプログラムをプロキシサーバ１０１のＣＰＵ２０１がＲＡＭ２０２にロードして実行することにより上記各手段３０１〜３０６が実現される。
【００４３】
次に、フローチャートを参照してプロキシサーバ１０１によって行われる処理について説明する。
【００４４】
図４は、本発明における第１の制御処理の一例を示すフローチャートであり、プロキシサーバ１０１によって行われる全体的な処理の概要を示すフローチャートに対応する。なお、このフローチャートの処理はプロキシサーバ１０１のＣＰＵ２０１がＨＤＤ２０４に格納されるプログラムをＲＡＭ２０２にロードして実行することにより実現される。
【００４５】
まず、ＣＰＵ２０１は、ユーザから規制ルールの設定変更要求を受け付けたか否かを判断する（ステップＳ４０１）。そして、設定変更要求を受けたと判断した場合には（ステップＳ４０１でＹｅｓ）、ＣＰＵ２０１は規制ルールの設定処理を行う（ステップＳ４０２）。なお、ステップＳ４０２の処理の詳細については図５を参照して後述する。そして、ステップＳ４０２の処理が終わると、ＣＰＵ２０１はステップＳ４０３に処理を進める。
【００４６】
ステップＳ４０３では、ＣＰＵ２０１は、クライアントＰＣ１０４がリクエストしたＵＲＬからカテゴリを判定し、ＨＴＴＰリクエストの詳細情報を取得し、それらの情報に基づいてステップＳ４０２で設定した規制ルールと照らし合わせてＨＴＴＰリクエストの制御処理を行う。なお、ステップＳ４０３の処理の詳細については、図１０を参照して後述する。そして、ステップＳ４０３の処理が終わると、ＣＰＵ２０１はステップＳ４０４に処理を進める。
【００４７】
ステップＳ４０４では、ＣＰＵ２０１は、ＨＴＴＰリクエストの制御処理の終了指示を受けたかどうか判断する。そして、終了指示を受けていないと判断した場合には（ステップＳ４０４でＮｏ）、ＣＰＵ２０１は、ステップＳ４０１に処理を戻す。
【００４８】
一方、ＨＴＴＰリクエストの制御処理の終了指示を受けたと判断した場合には（ステップＳ４０４でＹｅｓ）、ＣＰＵ２０１は、そのまま本フローチャートの処理を終了する。即ち、ＣＰＵ２０１は、上記のＳ４０１〜Ｓ４０３の処理を、ＨＴＴＰリクエストの制御処理の終了指示を受けるまで（ステップＳ４０４でＹｅｓと判断するまで）繰り返す。
以下、図５を参照して、図４のステップＳ４０２に示した規制ルールの設定処理を詳細に説明する。
【００４９】
図５は、本発明における第２の制御処理の一例を示すフローチャートであり、図４のステップＳ４０２に示した規制ルールの設定処理の詳細を示すフローチャートに対応する。即ち、本処理は、プロキシサーバ１０１のＣＰＵ２０１によって行われる。なお、本処理を行う際に、ＣＰＵ２０１は、規制ルール受付手段３０１及びウェブメール規制ルール記録手段３０２としてプロキシサーバ１０２を機能させるためのプログラムをＨＤＤ２０４からＲＡＭ２０２にロードし、そのプログラムの制御に基づいて以下に示す処理を行うこととなる。
【００５０】
まず、プロキシサーバ１０１のＣＰＵ２０１は、規制ルールの設定要求を送信してきたクライアントＰＣ１０４に対して、図６に示すような規制ルール設定画面６００を表示するための表示情報を送信する（ステップＳ５０１）。当該表示情報に従って、クライアントＰＣ１０４のディスプレイ装置には規制ルール設定画面６００が表示される。ここで規制ルール設定画面６００について説明する。
【００５１】
図６は、規制ルール設定画面の一例を示す図である。
【００５２】
図６において、６０１はルールＩＤ表示欄であって、規制ルールを一意に示すＩＤが表示される。規制ルールは規制ルール設定画面に表示される順番に適用される。
６０２はルール名表示欄であって、当該詳細ルールに設定されているルール名が表示される。
【００５３】
６０３は動作表示欄であって、当該ルールに合致したＨＴＴＰリクエストを許可する／不許可とするかの設定が表示される。
【００５４】
各ルールは、それぞれのルールを表示している行の編集ボタン６０４を押下することで編集が、削除ボタン６０５を押下することで削除することが可能である。また、移動ボタン６０６を押下することでルール移動画面が表示され、ルールの適用順位を変更することができる。
【００５５】
また、追加ボタン６０７を押下すると規制ルールの追加が可能になる。以上が図６に示す規制ルール設定画面の説明である。
以下、図５のフローチャートの説明に戻る。
【００５６】
ステップＳ５０２において、ＣＰＵ２０１は、規制ルールの詳細設定要求を受け付けたか否かを判断する。この詳細設定要求は、クライアントＰＣのディスプレイ上に表示されている規制ルール設定画面６００の追加ボタン６０７もしくは編集ボタン６０４が押下された場合に発行されるものである。
【００５７】
追加ボタン６０７が押下された場合には新規の詳細設定を、編集ボタン６０４が押下された場合には、すでに設定されている詳細設定の変更処理を行うことになる。
【００５８】
そして、規制ルールの詳細設定要求を受け付けたと判断した場合には（ステップＳ５０２でＹｅｓ）、ＣＰＵ２０１は、規制ルール詳細設定画面（図７）を表示するための表示情報を、規制ルールの詳細設定要求を送信してきたクライアントＰＣ１０４に対して送信する（ステップＳ５０３）。以下図７の規制ルール詳細設定画面７００について説明する。
【００５９】
図７において、７０１はルールＩＤ表示欄であって、規制ルールを一意に示すルールＩＤ（条件ＩＤ）表示欄である。このＩＤは自動的に付与しても、ユーザの入力部からの入力指示に基づいて設定しても（規制ルール内での重複は許さない）構わない。
７０２は規制ルール名入力欄であって、当該規制ルールの名称の入力を受け付ける。
【００６０】
ＵＲＬ条件では、特定のＵＲＬを指定するか（ＵＲＬラジオボタン７０３を選択する）若しくはカテゴリを指定するか（カテゴリラジオボタン７０４を選択する）が選択可能である。そしてＵＲＬラジオボタン７０３が選択された場合にはＵＲＬ入力欄７０５への入力が、カテゴリラジオボタン７０４が選択された場合にはカテゴリ選択セレクトボックス７０６によるカテゴリの選択が可能である。本実施例では、ＵＲＬ条件にＵＲＬ指定もしくはカテゴリ指定のどちらかによる設定を行うことになっているが、双方を同時に設定させても勿論かまわない。クライアントＰＣから送信されたＨＴＴＰリクエストのＵＲＬがこれらの条件に合致した場合ＵＲＬ条件が合致したと判定される。
【００６１】
７０７は添付されたデータファイルのファイル形式を選択するためのセレクトボックスであって、データファイルのファイル形式を選択する。
【００６２】
７０８は添付ファイルのサイズ入力欄であって添付ファイルのサイズを入力する。７０９は添付ファイルのサイズが７０８で指定したサイズ以上／以下を選択するラジオボタンであって、添付ファイルのサイズが７０８で指定したサイズ以上の場合にルールを合致させたい場合は以上を、添付ファイルのサイズが７０８で指定したサイズ以下の場合にルールに合致させたい場合は以下を指定する。
【００６３】
７１０は添付ファイルのファイル形式と付与されている拡張子が一致する／しないを指定するラジオボタンであって、添付ファイルのファイル形式と付与された拡張子が一致する場合にルールに合致させたい場合は一致する、ファイル形式と付与された拡張子が一致しない場合にルールに合致させたい場合は一致しないを指定する。
【００６４】
７１１はキーワード条件の入力欄であって、ＨＴＴＰリクエストに添付されたデータファイルおよびＨＴＴＰリクエストのそれ以外のフィールドに記載されたテキスト情報に合致させるキーワード条件を入力する。キーワード入力欄には複数のキーワードを入力することが可能であり、またそれらの結合条件（ＡＮＤ条件：例えば「＆」で設定、ＯＲ条件：例えば「｜」で設定、結合優先度設定：例えば括弧「（）」で設定）の設定も可能である。
【００６５】
そして上記条件に合致した場合に（ＵＲＬ条件、添付ファイル条件、キーワード条件をＡＮＤ条件で結合）、ＨＴＴＰリクエストを許可／不許可のどちらかに設定するかを動作ラジオボタン７１２で指定する。ＵＲＬ条件、添付ファイル条件、キーワード条件の結合方法を入力するための領域を設定して、その領域に結合条件を入力し、その結合条件を満たした場合に送信を許可／不許可とするといった設定を用いても勿論かまわない。
【００６６】
そして更新ボタン７１３が押下された場合、上記設定した詳細ルールの登録要求をプロキシサーバ１０１に対して行うことになる。また、キャンセルボタン７１４が押下された場合は、ルールの変更もしくは追加を実施せずに規制ルールの詳細設定処理を終了する。以上が図７に示す規制ルール詳細設定画面７００の説明である。
以下、図５のフローチャートの説明に戻る。
【００６７】
ステップＳ５０４において、ＣＰＵ２０１は、規制ルールの移動要求を受け付けたか否かを判断する。この要求は、クライアントＰＣのディスプレイ上に表示されている規制ルール設定画面６００の移動ボタン６０６が押下された場合に発行されるものである。
【００６８】
そして、規制ルールの移動要求を受け付けたと判断した場合には（ステップＳ５０４でＹｅｓ）、ＣＰＵ２０１は、規制ルール移動画面（図８）を表示するための表示情報を、規制ルールの移動要求を送信してきたクライアントＰＣ１０４に対して送信する（ステップＳ５０５）。ここで規制ルール移動画面８００について説明する。
【００６９】
図８は、規制ルール移動画面８００の一例を示す図である。規制ルールは規制ルール設定画面６００に表示される順番に優先度が高くなる。ＨＴＴＰリクエストへの規制ルールの適用は優先度が高い順に行われ、条件に合致した規制ルールがあった場合にはその規制ルールで示す条件式に合致した場合の動作を行わせる。よって、条件に合致した規制ルールよりも優先度の低い規制ルールの適用は基本的に行われない。規制ルール移動画面８００は、規制ルール設定画面６００で表示するルールの順番を変更するために用いられる。
図８において、８０１は移動対象となる規制ルールの行番号表示欄であって、何行目の規制ルールを移動させるかを表す。
【００７０】
８０２は対象規制ルールを何行目の規制ルールの上もしくは下に移動させるかを入力させる入力欄である。８０３は対象規制ルールを８０２で指定した行番号の規制ルールの上もしくは下に移動させるかを選択するセレクトボックスであって、対象規制ルールを８０２で指定した行番号の規制ルールの上に移動させたい場合は上に、下に移動させたい場合は下に、を選択する。
【００７１】
そして移動ボタン８０４が押下された場合、上記設定した規制ルールの移動要求をプロキシサーバ１０１に対して行うことになる。また、キャンセルボタン８０５が押下された場合は、規制ルールの移動を実施せずに規制ルールの移動処理を終了する。以上が図８に示す規制ルール移動画面８００の説明である。
以下、図５のフローチャートの説明に戻る。
【００７２】
ステップＳ５０６では、ＣＰＵ２０１は、規制ルールの詳細設定用の画面および移動画面を介して入力された入力情報を受信したか否かを判断する。そして、受信したと判断した場合には（ステップＳ５０６でＹｅｓ）、ＣＰＵ２０１は、受信した情報を規制ルールＤＢ１０３に保存する（ステップＳ５０７）。尚、受信した情報は、図９の規制ルールテーブル９００に登録されることになる。ここで、規制ルールテーブル９００について説明する。
【００７３】
図９は、規制ルールテーブル９００の一例を示す図である。このテーブルには規制ルール詳細設定画面７００を介して入力された規制ルールが登録されることになる。また、規制ルール移動画面８００で設定した適用順が登録される。
【００７４】
図９において、９０１はルールＩＤであって、規制ルールを一意に識別するＩＤ情報が登録される。９０２は適用順であって、規制ルールの適用の優先順位が登録されている。９０３はルール名であって、規制ルールのルール名が登録される。
【００７５】
９０４にはＵＲＬが登録される。９０５にはカテゴリが登録される。９０６には添付ファイルのファイル形式が登録される。９０７には添付ファイルのサイズが登録される。９０８には添付ファイルのサイズが９０７に登録したサイズ以上もしくは以下の場合にルールに合致させるかの情報が登録される。９０９はファイル形式と拡張子の一致条件が登録される。９１０にはキーワード条件を登録する。９１０動作であって、条件式に合致したウェブメールに対して送信を許可する／不許可とするという送信制御（中継制御）方法の設定が登録される。以上が図９の規制ルールテーブル９００説明である。
以下、図５のフローチャートの説明に戻る。
【００７６】
ステップＳ５０８では、ＣＰＵ２０１は、ステップＳ５０７で規制ルールＤＢ１０３に保存した情報を含む規制ルール設定画面６００をクライアントＰＣ１０４に送信し、ステップＳ５０２に処理を戻す。
【００７７】
また、ステップＳ５０６において、規制ルールの詳細設定用の画面７００および規制ルールの移動画面８００を介して入力された入力情報を受信していないと判断した場合には（ステップＳ５０６でＮｏ）、ＣＰＵ２０１は、ステップＳ５０９に処理を進める。
【００７８】
ステップＳ５０９では、ＣＰＵ２０１は、規制ルールの設定処理の終了指示を受けたかどうか判断する。なお、規制ルールの設定処理終了指示とは、例えば規制ルール設定画面６００中の終了ボタン（不図示）が押下された場合や、ブラウザアプリケーションの終了指示があった場合に発行されることになる。
【００７９】
そして、規制ルールの設定処理の終了指示を受けていないと判断した場合には（ステップＳ５０９でＮｏ）、ＣＰＵ２０１は、ステップＳ５０２に処理を戻す。
【００８０】
一方、規制ルールの設定処理の終了指示を受けたと判断した場合には（ステップＳ５０９でＹｅｓ）、ＣＰＵ２０１は、そのまま本フローチャートの処理を終了する。即ち、ＣＰＵ２０１は、上記のＳ５０２〜Ｓ５０８の処理を、規制ルールの設定処理の終了指示を受けるまで（ステップＳ５０９でＹｅｓと判断するまで）繰り返す。以上がプロキシサーバ１０１のＣＰＵ２０１によって行われる規制ルール情報設定処理の一例である。
【００８１】
以下、図１０を参照して、図４のステップＳ４０３に示したＨＴＴＰリクエストの制御処理を詳細に説明する。
【００８２】
図１０は、本発明における第３の制御処理の一例を示すフローチャートであり、図４のステップＳ４０３に示したＨＴＴＰリクエストの制御処理の詳細を示すフローチャートに対応する。即ち、本処理は、プロキシサーバのＣＰＵ２０１によって行われる。なお、本処理を行う際に、ＣＰＵ２０１は、ＵＲＬカテゴリ判定手段３０３、リクエストの詳細情報取得手段３０４、通信中継制御手段３０５及び通信許可／不許可応答送信手段３０６としてプロキシサーバ１０１を機能させるためのプログラムをＨＤＤ２０４からＲＡＭ２０２にロードし、そのプログラムの制御に基づいて以下に示す処理を行うこととなる。
【００８３】
プロキシサーバ１０１のＣＰＵ２０１は、常時ＬＡＮ１０５上を流れるパケットを常時監視している。そして、クライアントＰＣ１０４から広域ネットワーク１０６に設置されているウェブサーバ１０７に対してのＨＴＴＰリクエストを受け付ける（ステップＳ１００１）。
【００８４】
そして、ＣＰＵ２０１は、リクエストされたＵＲＬをＵＲＬＤＢ１０２中に登録されているかを確認してカテゴリを判定する（ステップＳ１００２）。ここで、ＵＲＬカテゴリの判定処理の詳細について図１１を参照して説明する。
【００８５】
図１１は、本発明における第３の制御処理の一例を示すフローチャートであり、図１０のステップＳ１００２に示したＵＲＬカテゴリ判定処理の詳細を示すフローチャートに対応する。即ち、本処理は、プロキシサーバのＣＰＵ２０１によって行われる。なお、本処理を行う際に、ＣＰＵ２０１は、ＵＲＬカテゴリ判定手段３０３としてプロキシサーバ１０１を機能させるためのプログラムをＨＤＤ２０４からＲＡＭ２０２にロードし、そのプログラムの制御に基づいて以下に示す処理を行うこととなる。
【００８６】
図１１のステップＳ１１０１において、ＣＰＵ２０１は、ＵＲＬＤＢ１０２からリクエストされたＵＲＬがどのカテゴリに属するか検索する。ここでＵＲＬＤＢの詳細について図１２を参照して説明する。
【００８７】
図１２はＵＲＬＤＢ１００２の一例を示す図である。図１２では、各ＵＲＬ１２０３を大カテゴリ１２０１と小カテゴリ１２０２に分類して格納している。
【００８８】
図１１のステップＳ１１０１では、ＵＲＬＤＢ１００２からリクエストされたＵＲＬがどのカテゴリに属するか検索する。
【００８９】
次に、ステップＳ１１０２において、ＣＰＵ２０１は、ステップＳ１１０１で検索した結果該当するカテゴリがない場合は（ステップＳ１１０２でＮｏ）カテゴリなしと判定する。
【００９０】
一方、ステップＳ１１０２において、該当するカテゴリがあると判定した場合（ステップＳ１１０２でＹｅｓ）にはステップＳ１１０３に進み、ＨＴＴＰリクエストに対するカテゴリ情報をセットし、以降の処理を行う。
【００９１】
以下、図１０のフローチャートの説明に戻る。
【００９２】
図１０のステップＳ１００３において、ＣＰＵ２０１は、ＨＴＴＰリクエストの詳細情報を取得する。ここで、図１３を参照してファイル形式の判定処理の詳細について説明する。
【００９３】
図１３は、本発明における第４の制御処理の一例を示すフローチャートであり、図１０のステップＳ１００３に示したリクエストの詳細情報取得処理の詳細を示すフローチャートに対応する。即ち、本処理は、プロキシサーバのＣＰＵ２０１によって行われる。なお、本処理を行う際に、ＣＰＵ２０１は、リクエストの詳細情報取得手段３０４としてプロキシサーバ１０１を機能させるためのプログラムをＨＤＤ２０４からＲＡＭ２０２にロードし、そのプログラムの制御に基づいて以下に示す処理を行うこととなる。
【００９４】
図１３のステップＳ１３０１においてＨＴＴＰリクエストにデータファイルが添付されているかを判定する。データファイルが添付されていない（ステップＳ１３０１でＮｏ）場合は、ステップＳ１３０７の処理に進む。
【００９５】
一方、ステップＳ１３０１でＨＴＴＰリクエストにデータファイルが添付されていると判定された（ステップＳ１３０１でＹｅｓ）場合は、ステップＳ１３０２において、データファイルの先頭もしくは末尾にあるシグネチャからデータファイルのファイル形式を判定する。データファイルのファイル形式の判定には図１４に示すようなファイル形式識別子とシグネチャの対応表を使用する。これは、プロキシサーバ１０１の記憶領域にきおくされている。尚、添付ファイルが圧縮データであった場合にはそのデータを解凍し、解凍後のデータを用いて以降の処理を行う。
【００９６】
図１４に示すようにデータファイルがＰＤＦの場合は先頭の４バイトが％ＰＤＦとなる。データファイルにはこのようにデータファイルの先頭や末尾にそれぞれのデータファイルに固有のシグネチャがあるため、この情報を用いてステップＳ１３０２においてデータファイルのファイル形式を判定する。
【００９７】
ステップＳ１３０３では、データファイルに付与されている拡張子を取得する。
【００９８】
ステップＳ１３０４では、データファイルのサイズを取得する。
【００９９】
その後、判定した添付ファイルのファイル形式がテキスト情報を含む形式であるかをステップＳ１３０５において判定する。テキスト情報を含まない画像のような形式（ステップＳ１３０５でＮｏ）の場合は、ステップＳ１３０７に処理を進める。
【０１００】
一方、添付ファイルがテキスト情報を含む形式である（ステップＳ１３０５でＹｅｓ）場合は、ステップＳ１３０２で取得したデータファイルのファイル形式に適した方法でデータファイルからテキスト情報を取得する（ステップＳ１３０６）。
【０１０１】
ステップＳ１３０７ではＨＴＴＰリクエストのＢｏｄｙから添付ファイルのフィールド以外にテキスト情報が含まれる場合は、それらのフィールドからテキスト情報を取得する。この処理で取得したテキスト情報は、以降で説明する規制ルール適用処理においてキーワード条件が合致するかを判定するために使用される。
以下、図１０のフローチャートの説明に戻る。
【０１０２】
図１０のステップ１００４においてＣＰＵ２０１は、ステップＳ１００２、およびステップＳ１００３で取得したＵＲＬのカテゴリや添付ファイルに関する情報などをもとに規制ルールを適用する。なお、規制ルールの適用処理の詳細は図１５を参照して後述する。
【０１０３】
次に、ステップＳ１００５において、ＣＰＵ２０１は、ステップＳ１００４の規制ルールの適用処理で通信許可となったか否かを判断する。そして、規制ルールの適用処理で通信不許可となったと判断した場合には（ステップＳ１００５でＮｏ）、ＣＰＵ２０１は、ＨＴＴＰリクエストを送信したクライアントＰＣ１０４に対して不許可応答を送信し（ステップＳ１００６）、本フローチャートの処理を終了する。
【０１０４】
一方、ステップＳ１００５において、ステップＳ１００４の規制ルールの適用処理で通信許可となったと判断した場合には（ステップＳ１００５でＹｅｓ）、ＣＰＵ２０１は、ステップＳ１００７に処理を進める。
ステップＳ１００７では、ＣＰＵ２０１は、ステップＳ１００５で送信許可とされたＨＴＴＰリクエストをウェブサーバに中継する。
【０１０５】
ステップＳ１００８では、ＣＰＵ２０１は、ウェブサーバからの応答を受信するまで待機し、ウェブサーバからの応答を受信したと判断した場合には、ステップＳ１００９に処理を進める。
【０１０６】
ステップＳ１００９では、ＣＰＵ２０１は、ＨＴＴＰリクエストを送信したクライアントＰＣ１０４に対してウェブサーバの応答を中継し、本フローチャートの処理を終了する。
【０１０７】
以下、図１５を参照して、図１０のステップＳ１００４に示した規制ルールの適用処理について詳細に説明する。
【０１０８】
図１５は、本発明における第５の制御処理の一例を示すフローチャートであり、図１０のステップＳ１００４に示した規制ルールの適用処理の詳細を示すフローチャートに対応する。即ち、本処理は、プロキシサーバのＣＰＵ２０１によって行われる。なお、本処理を行う際に、ＣＰＵ２０１は、通信中継制御手段３０５としてプロキシサーバ１０１を機能させるためのプログラムをＨＤＤ２０４からＲＡＭ２０２にロードし、そのプログラムの制御に基づいて以下に示す処理を行うこととなる。
【０１０９】
図１５のステップＳ１５０１において、まだ適用していない規制ルールがあるかどうか否かを判断する。まだ適用していない規制ルールがあった場合には（ステップＳ１５０１でＹｅｓ）、ＣＰＵ２０１は、規制ルールテーブル９００に登録されているまだ未適用の規制ルールを適用順９０２に従って取得する（ステップＳ１５０２）。
【０１１０】
ステップＳ１５０３では、ＣＰＵ２０１は、ＨＴＴＰリクエストのＵＲＬもしくはＵＲＬが属するカテゴリ、添付ファイルのファイル形式、拡張子などの情報がステップＳ１５０２で取得した規制ルールの条件に合致（マッチ）するか否かを判断する。また、規制ルールの合致を判断する処理では、添付ファイルのファイル形式と拡張子が一致するかについても確認を行う。ここで、ＨＴＴＰリクエストが規制ルールに合致するか判定する処理の詳細について図１６を用いて説明する。
【０１１１】
図１６は、本発明における第６の制御処理の一例を示すフローチャートであり、図１５のステップＳ１５０３に示したＨＴＴＰリクエストが規制ルールにマッチするか判定する処理の詳細を示すフローチャートに対応する。即ち、本処理は、プロキシサーバのＣＰＵ２０１によって行われる。
【０１１２】
図１６のステップＳ１６０１において、規制ルール９００のうち、ステップＳ１５０２で取得した規制ルールのＵＲＬ９０４にＵＲＬが登録されているか否かを判断する。ＵＲＬが登録されていない場合は（ステップＳ１６０１でＮｏ）、ＣＰＵ２０１は、ステップＳ１６０３に処理を進める。一方、ＵＲＬが登録されている場合は（ステップＳ１６０１でＹｅｓ）、ＣＰＵ２０１は、ステップＳ１６０２に処理を進める。
【０１１３】
ステップＳ１６０２では、ＨＴＴＰリクエストのＵＲＬとＵＲＬ９０４に登録されているＵＲＬがマッチするか否かを判断する。マッチしないと判断した場合は（ステップＳ１６０２でＮｏ）、ＨＴＴＰリクエストに規制ルールがマッチしないと判断して処理を終了する（ステップＳ１６１４）。一方、マッチすると判断した場合は（ステップＳ１６０２でＹｅｓ）、ＣＰＵ２０１は、ステップＳ１６０３に処理を進める。
【０１１４】
ステップＳ１６０３では、規制ルール９００のうち、ステップＳ１５０２で取得した規制ルールのＵＲＬ９０５にカテゴリが登録されているか否かを判断する。カテゴリが登録されていない場合は（ステップＳ１６０３でＮｏ）、ＣＰＵ２０１は、ステップＳ１６０５に処理を進める。一方、カテゴリが登録されている場合は（ステップＳ１６０３でＹｅｓ）、ＣＰＵ２０１は、ステップＳ１６０４に処理を進める。
【０１１５】
ステップＳ１６０４では、ＨＴＴＰリクエストからＵＲＬカテゴリ判定手段３０３で取得したカテゴリとカテゴリ９０５に登録されているカテゴリがマッチするか否かを判断する。マッチしないと判断した場合は（ステップＳ１６０４でＮｏ）、ＨＴＴＰリクエストに規制ルールがマッチしないと判断して処理を終了する（ステップＳ１６１４）。また、ＵＲＬカテゴリ判定手段３０３でカテゴリなしと判定された場合もＨＴＴＰリクエストに規制ルールがマッチしないと判断して処理を終了する（ステップＳ１６１４）。一方、マッチすると判断した場合は（ステップＳ１６０４でＹｅｓ）、ＣＰＵ２０１は、ステップＳ１６０５に処理を進める。
【０１１６】
ステップＳ１６０５では、規制ルール９００のうち、ステップＳ１５０２で取得した規制ルールのファイル形式９０６にファイル形式が登録されているか否かを判断する。ファイル形式が登録されていない場合は（ステップＳ１６０５でＮｏ）、ＣＰＵ２０１は、ステップＳ１６０７に処理を進める。一方、ファイル形式が登録されている場合は（ステップＳ１６０５でＹｅｓ）、ＣＰＵ２０１は、ステップＳ１６０６に処理を進める。
【０１１７】
ステップＳ１６０６では、ＨＴＴＰリクエストからリクエストの詳細情報取得手段３０４で取得したファイル形式とファイル形式９０６に登録されているファイル形式がマッチするか否かを判断する。マッチしないと判断した場合は（ステップＳ１６０６でＮｏ）、ＨＴＴＰリクエストに規制ルールがマッチしないと判断して処理を終了する（ステップＳ１６１４）。また、ＨＴＴＰリクエストにデータファイルが添付されていない場合も、ＨＴＴＰリクエストに規制ルールがマッチしないと判断して処理を終了する（ステップＳ１６１４）。一方、マッチすると判断した場合は（ステップＳ１６０６でＹｅｓ）、ＣＰＵ２０１は、ステップＳ１６０７に処理を進める。
【０１１８】
ステップＳ１６０７では、規制ルール９００のうち、ステップＳ１５０２で取得した規制ルールにサイズ９０７及びサイズ条件９０８が登録されているか否かを判断する。サイズ及びサイズ条件が登録されていない場合は（ステップＳ１６０７でＮｏ）、ＣＰＵ２０１は、ステップＳ１６０９に処理を進める。一方、サイズ及びサイズ条件が登録されている場合は（ステップＳ１６０７でＹｅｓ）、ＣＰＵ２０１は、ステップＳ１６０８に処理を進める。
【０１１９】
ステップＳ１６０８では、ＨＴＴＰリクエストからリクエストの詳細情報取得手段３０４で取得したデータファイルのサイズがサイズ９０７およびサイズ条件９０８に登録されている条件にマッチするか否かを判断する。マッチしないと判断した場合は（ステップＳ１６０８でＮｏ）、ＨＴＴＰリクエストに規制ルールがマッチしないと判断して処理を終了する（ステップＳ１６１４）。また、ＨＴＴＰリクエストにデータファイルが添付されていない場合も、ＨＴＴＰリクエストに規制ルールがマッチしないと判断して処理を終了する（ステップＳ１６１４）。一方、マッチすると判断した場合は（ステップＳ１６０８でＹｅｓ）、ＣＰＵ２０１は、ステップＳ１６０９に処理を進める。
【０１２０】
ステップＳ１６０９では、規制ルール９００のうち、ステップＳ１５０２で取得した規制ルールのファイル形式と拡張子９０９にファイル形式と拡張子の一致条件が登録されているか否かを判断する。ファイル形式と拡張子の一致条件が登録されていない場合は（ステップＳ１６０９でＮｏ）、ＣＰＵ２０１は、ステップＳ１６１１に処理を進める。一方、ファイル形式と拡張子の一致条件が登録されている場合は（ステップＳ１６０９でＹｅｓ）、ＣＰＵ２０１は、ステップＳ１６１０に処理を進める。
【０１２１】
ステップＳ１６１０では、ＨＴＴＰリクエストからリクエストの詳細情報取得手段３０４で取得したデータファイルのファイル形式と拡張子がファイル形式と拡張子９０９に登録されている条件にマッチするか否かを判断する。ここで添付ファイルのファイル形式と拡張子が一致するかを確認する処理について図１７を用いて説明する。
【０１２２】
図１７は、ファイル形式を表すファイル形式識別子１７０１と、そのファイル形式に対して一般的に付与される拡張子１７０２の対応を示したものである。図１７に示す対応表は、プロキシサーバ１０１に記憶されている。ここで図１７のファイル形式識別子１７０１は、ＨＴＴＰリクエストに添付されたデータファイルのファイル形式を判定するためのデータ１４００（図１４）のファイル形式識別子１４０１に対応する。ファイル形式識別子に対する拡張子の対応データ１７００は、規制ルール適用処理プログラムに組み込んでもよいし、他の形式で保持していても構わない。
【０１２３】
添付ファイルのファイル形式と付与されている拡張子が一致しているか否かの判断では、添付ファイルのファイル形式と付与されている拡張子をファイル形式識別子に対する拡張子の対応データ１７００と照らし合わせて、一致するもしくは一致しないを判断する。つまり、添付ファイルのファイル形式に対応する識別子をファイル形式識別子１７０１から検索し、そのファイル形式に対して一般的に付与される拡張子１７０２を取得する。添付ファイルに付与されている拡張子が慨取得した拡張子１７０２の中にある場合は添付ファイルのファイル形式と付与されている拡張子が一致すると判断し、ない場合は一致しないと判断する。
【０１２４】
以下、図１６のフローチャートの説明に戻る。
【０１２５】
ステップＳ１６１０において、ＨＴＴＰリクエストからリクエストの詳細情報取得手段３０４で取得したデータファイルのファイル形式と拡張子がファイル形式と拡張子９０９に登録されている条件にマッチするか判断し、マッチしないと判断した場合は（ステップＳ１６１０でＮｏ）、ＨＴＴＰリクエストに規制ルールがマッチしないと判断して処理を終了する（ステップＳ１６１４）。また、ＨＴＴＰリクエストにデータファイルが添付されていない場合も、ＨＴＴＰリクエストに規制ルールがマッチしないと判断して処理を終了する（ステップＳ１６１４）。一方、マッチすると判断した場合は（ステップＳ１６１０でＹｅｓ）、ＣＰＵ２０１は、ステップＳ１６１１に処理を進める。
【０１２６】
ステップＳ１６１１では、規制ルール９００のうち、ステップＳ１５０２で取得した規制ルールのキーワード９１０にキーワードが登録されているか否かを判断する。キーワードが登録されていない場合は（ステップＳ１６１１でＮｏ）、ＣＰＵ２０１は、ステップＳ１６１３に処理を進める。一方、キーワードが登録されている場合は（ステップＳ１６１１でＹｅｓ）、ＣＰＵ２０１は、ステップＳ１６１２に処理を進める。
【０１２７】
ステップＳ１６１２では、ＨＴＴＰリクエストからリクエストの詳細情報取得手段３０４で取得したテキスト情報がキーワード９１０に登録されているキーワードにマッチするか判断する。マッチしないと判断した場合は（ステップＳ１６１２でＮｏ）、ＨＴＴＰリクエストに規制ルールがマッチしないと判断して処理を終了する（ステップＳ１６１４）。また、ＨＴＴＰリクエストにテキスト情報が含まれない場合も、マッチしないと判断して処理を終了する（ステップＳ１６１４）。一方、マッチすると判断した場合は（ステップＳ１６１２でＹｅｓ）、ＣＰＵ２０１は、ステップＳ１６１３に処理を進める。
【０１２８】
ステップＳ１６１３では、ＨＴＴＰリクエストが規制ルールにマッチすると判断して処理を終了する。
以下、図１５のフローチャートの説明に戻る。
【０１２９】
規制ルールの条件に合致（マッチ）すると判断した場合には（ステップＳ１５０３でＹｅｓ）、ＣＰＵ２０１は、当該規制ルールの動作として示されている制御を行い（許可／不許可し）（ステップＳ１５０４）、本フローチャートの処理を終了する。
一方、規制ルールの条件に合致（マッチ）しないと判断した場合には（ステップＳ１５０３でＮｏ）、ＣＰＵ２０１はステップＳ１５０１に処理を戻す。
【０１３０】
そしてステップＳ１５０１で、まだ適用していない規制ルールがないと判断した場合には（ステップＳ１５０１でＮｏ）、ＣＰＵ２０１は、予め規制ルールＤＢ１０３に設定されているデフォルト（全ての規制ルールに適合しなかった場合の）動作を行い（許可／不許可）（ステップＳ１５０５）、本フローチャートの処理を終了する。以上が図１０のステップＳ１００４の規制ルール適用処理の詳細な説明である。
【０１３１】
以上説明したように、本発明によれば、ＨＴＴＰリクエストに付与されているＣｏｎｔｅｎｔ−Ｔｙｐｅによらず、ＨＴＴＰリクエストに添付されているデータファイルのファイル形式を判定し、データファイルのファイル形式に適した方法でデータファイルの情報を取得し、データファイルの送信制御を行うことが可能となる。また、データファイルのファイル形式と付与されている拡張子が一致しない場合にもＨＴＴＰリクエストを許可もしくは不許可とするといった制御を行うことが可能となる。
【０１３２】
以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記録媒体等としての実施態様をとることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
【０１３３】
また、規制ルール詳細設定画面７００においてクライアントＰＣのＩＰアドレスを設定できるようにしても良い。この場合は、特定のＩＰアドレスを持つクライアントＰＣ１０４が行ったＨＴＴＰリクエストに対して規制ルールを適用するといった制御が可能になる。
【０１３４】
もしくは、規制ルール詳細設定画面７００においてユーザおよびユーザグループを設定できるようにしても良い。この場合は、特定のユーザおよびユーザグループが行ったＨＴＴＰリクエストに対して規制ルールを適用するといった制御が可能になる。
【０１３５】
また、ＨＴＴＰＳといった暗号化通信の場合は、リクエストの詳細情報を取得して規制ルールを適用することができないが、その場合は暗号化通信であれば、リクエストを不許可とするように設定可能にしても良い。もちろん、何らかの手段により、暗号化されたリクエストの詳細情報を取得できる場合は、規制ルールを適用して許可／不許可の制御を行っても構わない。
【０１３６】
以上説明したように、本実施の形態によれば、データの送信先に応じてデータの拡張子が偽装されているかを判定することにより、情報漏洩を防止させることができる。
【０１３７】
以上、本発明の一実施形態を詳述したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様をとることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
【０１３８】
また、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出し実行することによっても、達成されることは言うまでもない。
【０１３９】
この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、プログラムコード自体及びそのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【０１４０】
プログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭ等を用いることができる。
【０１４１】
また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（基本システム或いはオペレーティングシステム）などが実際の処理の一部又は全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１４２】
さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部又は全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【符号の説明】
【０１４３】
１０１ プロキシサーバ １０２ ＵＲＬデータベース １０３ 期性ルールデータベース １０４−１ クライアントＰＣ １０４−２ クライアントＰＣ １０４−３ クライアントＰＣ １０５ ＬＡＮ １０６ 広域ネットワーク １０７−１ ウェブサーバ １０７−２ ウェブサーバ １０７−３ ウェブサーバ
【特許請求の範囲】
【請求項１】
データを出力するクライアント装置と通信可能であり、当該データの送信制御を行う情報処理装置であって、
ファイルの送信先を特定する送信先情報と、当該送信先に対して当該ファイルの拡張子の偽装があるときに当該ファイルの送信を許可するか禁止するかが設定された設定情報とを対応づけた送信ルール情報を記憶する記憶手段と、
前記クライアント装置から出力された前記ファイルの送信要求に対して、当該ファイル内のデータから判定されるファイル形式と当該ファイルのファイル名の拡張子から判定されるファイル形式とが同じであるかを判定する偽装判定手段と、
前記偽装判定手段でファイル形式が異なると判定された場合、前記ファイルの送信先に対応した前記送信ルール情報に従って、当該ファイルの送信を許可するか禁止するかを制御する送信制御手段と、
を備えることを特徴とする情報処理装置。
【請求項２】
前記記憶手段に記憶される送信ルール情報は、更に、前記送信先情報に対応して送信が許可されるファイル形式が記憶されており、
前記クライアント装置から出力された前記ファイルの送信要求に対して、当該ファイル内のデータから判定されるファイル形式が、前記送信ルール情報に記憶された、前記ファイルの送信先に対応した、送信が許可されたファイル形式であるかを判定する許可形式判定手段と、
前記許可形式判定手段による判定結果に応じて、当該ファイルの送信を許可するか禁止するかを制御する形式送信制御手段と、
を更に備え、
前記形式送信制御手段は、前記送信制御手段による送信制御を優先して実行することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記記憶手段は、更に、複数の送信ルール情報に対して、当該送信ルール情報を適用する優先順位を記憶し、
前記送信制御手段は、前記優先順位の順番で適用される前記送信ルール情報に従って、当該ファイルの送信を許可するか禁止するかを制御することを特徴とする請求項１又は２に記載の情報処理装置。
【請求項４】
前記記憶手段に記憶される送信ルール情報の送信先情報は、送信先の分野を示すカテゴリを含み、
ファイルの送信先と、当該送信先の分野を示すカテゴリとを含むカテゴリ情報を記憶したカテゴリ記憶手段と、
前記カテゴリ記憶手段に記憶されたカテゴリ情報に従って、前記ファイルの送信先から、当該送信先に対応するカテゴリを判定するカテゴリ判定手段と、
を更に備え、
前記形式送信制御手段は、前記送信ルール情報を用いて、前記カテゴリ判定手段により判定されたカテゴリに従って、送信を許可するファイル形式を決定する決定手段と、
を更に備えることを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
【請求項５】
データを出力するクライアント装置と通信可能であり、当該データの送信制御を行う情報処理装置における情報処理方法であって、
記憶手段が、ファイルの送信先を特定する送信先情報と、当該送信先に対して当該ファイルの拡張子の偽装があるときに当該ファイルの送信を許可するか禁止するかが設定された設定情報とを対応づけた送信ルール情報を記憶する記憶工程と、
偽装判定手段が、前記クライアント装置から出力された前記ファイルの送信要求に対して、当該ファイル内のデータから判定されるファイル形式と当該ファイルのファイル名の拡張子から判定されるファイル形式とが同じであるかを判定する偽装判定工程と、
送信制御手段が、前記偽装判定工程でファイル形式が異なると判定された場合、前記ファイルの送信先に対応した前記送信ルール情報に従って、当該ファイルの送信を許可するか禁止するかを制御する送信制御工程と、
を備えることを特徴とする情報処理方法。
【請求項６】
データを出力するクライアント装置と通信可能であり、当該データの送信制御を行う情報処理装置として機能させるプログラムであって、
ファイルの送信先を特定する送信先情報と、当該送信先に対して当該ファイルの拡張子の偽装があるときに当該ファイルの送信を許可するか禁止するかが設定された設定情報とを対応づけた送信ルール情報を記憶する記憶手段と、
前記クライアント装置から出力された前記ファイルの送信要求に対して、当該ファイル内のデータから判定されるファイル形式と当該ファイルのファイル名の拡張子から判定されるファイル形式とが同じであるかを判定する偽装判定手段と、
前記偽装判定手段でファイル形式が異なると判定された場合、前記ファイルの送信先に対応した前記送信ルール情報に従って、当該ファイルの送信を許可するか禁止するかを制御する送信制御手段として機能させることを特徴とするプログラム。
【請求項１】
データを出力するクライアント装置と通信可能であり、当該データの送信制御を行う情報処理装置であって、
ファイルの送信先を特定する送信先情報と、当該送信先に対して当該ファイルの拡張子の偽装があるときに当該ファイルの送信を許可するか禁止するかが設定された設定情報とを対応づけた送信ルール情報を記憶する記憶手段と、
前記クライアント装置から出力された前記ファイルの送信要求に対して、当該ファイル内のデータから判定されるファイル形式と当該ファイルのファイル名の拡張子から判定されるファイル形式とが同じであるかを判定する偽装判定手段と、
前記偽装判定手段でファイル形式が異なると判定された場合、前記ファイルの送信先に対応した前記送信ルール情報に従って、当該ファイルの送信を許可するか禁止するかを制御する送信制御手段と、
を備えることを特徴とする情報処理装置。
【請求項２】
前記記憶手段に記憶される送信ルール情報は、更に、前記送信先情報に対応して送信が許可されるファイル形式が記憶されており、
前記クライアント装置から出力された前記ファイルの送信要求に対して、当該ファイル内のデータから判定されるファイル形式が、前記送信ルール情報に記憶された、前記ファイルの送信先に対応した、送信が許可されたファイル形式であるかを判定する許可形式判定手段と、
前記許可形式判定手段による判定結果に応じて、当該ファイルの送信を許可するか禁止するかを制御する形式送信制御手段と、
を更に備え、
前記形式送信制御手段は、前記送信制御手段による送信制御を優先して実行することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記記憶手段は、更に、複数の送信ルール情報に対して、当該送信ルール情報を適用する優先順位を記憶し、
前記送信制御手段は、前記優先順位の順番で適用される前記送信ルール情報に従って、当該ファイルの送信を許可するか禁止するかを制御することを特徴とする請求項１又は２に記載の情報処理装置。
【請求項４】
前記記憶手段に記憶される送信ルール情報の送信先情報は、送信先の分野を示すカテゴリを含み、
ファイルの送信先と、当該送信先の分野を示すカテゴリとを含むカテゴリ情報を記憶したカテゴリ記憶手段と、
前記カテゴリ記憶手段に記憶されたカテゴリ情報に従って、前記ファイルの送信先から、当該送信先に対応するカテゴリを判定するカテゴリ判定手段と、
を更に備え、
前記形式送信制御手段は、前記送信ルール情報を用いて、前記カテゴリ判定手段により判定されたカテゴリに従って、送信を許可するファイル形式を決定する決定手段と、
を更に備えることを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
【請求項５】
データを出力するクライアント装置と通信可能であり、当該データの送信制御を行う情報処理装置における情報処理方法であって、
記憶手段が、ファイルの送信先を特定する送信先情報と、当該送信先に対して当該ファイルの拡張子の偽装があるときに当該ファイルの送信を許可するか禁止するかが設定された設定情報とを対応づけた送信ルール情報を記憶する記憶工程と、
偽装判定手段が、前記クライアント装置から出力された前記ファイルの送信要求に対して、当該ファイル内のデータから判定されるファイル形式と当該ファイルのファイル名の拡張子から判定されるファイル形式とが同じであるかを判定する偽装判定工程と、
送信制御手段が、前記偽装判定工程でファイル形式が異なると判定された場合、前記ファイルの送信先に対応した前記送信ルール情報に従って、当該ファイルの送信を許可するか禁止するかを制御する送信制御工程と、
を備えることを特徴とする情報処理方法。
【請求項６】
データを出力するクライアント装置と通信可能であり、当該データの送信制御を行う情報処理装置として機能させるプログラムであって、
ファイルの送信先を特定する送信先情報と、当該送信先に対して当該ファイルの拡張子の偽装があるときに当該ファイルの送信を許可するか禁止するかが設定された設定情報とを対応づけた送信ルール情報を記憶する記憶手段と、
前記クライアント装置から出力された前記ファイルの送信要求に対して、当該ファイル内のデータから判定されるファイル形式と当該ファイルのファイル名の拡張子から判定されるファイル形式とが同じであるかを判定する偽装判定手段と、
前記偽装判定手段でファイル形式が異なると判定された場合、前記ファイルの送信先に対応した前記送信ルール情報に従って、当該ファイルの送信を許可するか禁止するかを制御する送信制御手段として機能させることを特徴とするプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【公開番号】特開２０１０−２７７４８７（Ｐ２０１０−２７７４８７Ａ）
【公開日】平成２２年１２月９日（２０１０．１２．９）
【国際特許分類】
【出願番号】特願２００９−１３１６１２（Ｐ２００９−１３１６１２）
【出願日】平成２１年５月２９日（２００９．５．２９）
【出願人】（５９２１３５２０３）キヤノンＩＴソリューションズ株式会社 (528)
【Ｆターム（参考）】
【公開日】平成２２年１２月９日（２０１０．１２．９）
【国際特許分類】
【出願日】平成２１年５月２９日（２００９．５．２９）
【出願人】（５９２１３５２０３）キヤノンＩＴソリューションズ株式会社 (528)
【Ｆターム（参考）】
[ Back to top ]