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

Description

本発明は、内部ネットワークの端末装置と、インターネット等の外部ネットワーク上のサーバ装置との間の通信の中継制御にかかる記録の管理技術に関する。

ネットワーク技術の発展によって、情報のやり取りが非常に簡便に、且つ効率よく行うことが可能となっている。例えば、会議に使用する資料を電子メールに添付して参加者に前もって送付したりすることが、手間も煩わしさもなく行うことが可能となっている。

ただ、このようにネットワーク技術が発達し、情報のやりとりが容易に行われるようになった反面、重要な機密情報が簡単に外部に流出してしまう危険性や外部からコンピュータウイルス等の有害情報が流入してしまう危険性が高まっている。

そこで、企業等では、業務とは直接関係のない情報を提供しているサーバへのアクセスを禁止する等の対策を講じている。

例えば、特定のＵＲＬに対するアクセスを禁止する通信制御であるＵＲＬフィルタリングを行う機器を導入し、アクセスが許可されないＵＲＬに対するリクエストを当該ＵＲＬが示す情報資源を提供する外部サーバに転送しないことで、当該ＵＲＬが示す情報資源にアクセスできないようにしている。

ＵＲＬフィルタリングを行う場合には、アクセスを許可するＵＲＬのリストであるホワイトリストや、アクセスを禁止するＵＲＬのリストであるブラックリストを作成し、それらに対する制御を行うことになる。つまり、ホワイトリストに登録されているＵＲＬに対するリクエストはその通信を中継し、ブラックリストに登録されているＵＲＬに対するリクエストはその通信を中継しないといった制御を行うことになる。

例えば、特許文献１には、閲覧制限が付されたＷＥＢサイトに対してユーザから閲覧要求があった場合、監査者に対して閲覧の記録が通知される仕組みが開示されている。

特開２００８−２３４３３２号公報

しかしながら、閲覧が制限されたＷＥＢサイトに対するアクセス記録についてすべてが通知されることとなると、非常に大量の記録が通知されることになってしまう。

特に、ユーザ指定のＵＲＬだけでなく、複数のＵＲＬアクセスからページ全体が構成されるサイトでは、画像や動画などのファイル取得先が別ＵＲＬで指定されている場合がある。このような場合において、「ユーザが指定したＵＲＬ自体は閲覧許可されているが、そこからリンクされている画像や動画などのファイル取得先であるＵＲＬについては閲覧制限の対象となっている」という場合には、大量の規制ログが通知されてしまう。

このような画像や動画に対するアクセスは、閲覧者が故意に（意図的に）アクセスをしている訳ではないため、このようなアクセス記録は適切な閲覧制限を行う上で有用な記録ではない。

そのため、監査者は、適切なアクセス制限をするために、大量のログの中から、ユーザが故意に（意図的に）アクセスしたログを抽出しなければならないといった手間が生じてしまう。

そこで、本発明は、閲覧者によるＷＥＢサイトへのアクセスを管理する監査者が、効率よくアクセスログを管理することができる仕組みを提供することを目的とする。

本発明の情報処理装置は、端末装置からウェブサーバに対して送信されるデータ取得要求を取得する取得手段と、前記取得手段により取得されたデータ取得要求の中継を許可するか否かを判断する中継制御手段と、前記取得手段により取得されたデータ取得要求に、当該データ取得要求の参照元を示す情報が含まれるか否かを判断する参照元判断手段と、前記中継制御手段により中継を許可しないと判断されたデータ取得要求について、前記参照元判断手段による判断結果に応じて、監査者に通知するか否かを決定する決定手段と、前記決定手段により通知すると決定されたデータ取得要求にかかる情報を監査者に通知する通知手段と、を備えることを特徴とする。

また、本発明は、情報処理装置における情報処理方法であって、前記情報処理装置の取得手段が、端末装置からウェブサーバに対して送信されるデータ取得要求を取得する取得工程と、前記情報処理装置の中継制御手段が、前記取得工程により取得されたデータ取得要求の中継を許可するか否かを判断する中継制御工程と、前記情報処理装置の参照元判断手段が、前記データ取得要求に、当該データ取得要求の参照元を示す情報が含まれるか否かを判断する参照元判断工程と、前記情報処理装置の決定手段が、前記中継制御工程により中継を許可しないと判断されたデータ取得要求について、前記参照元判断工程による判断結果に応じて、監査者に通知するか否かを決定する決定工程と、前記情報処理装置の通知手段が、前記決定工程により通知すると決定されたデータ取得要求にかかる情報を監査者に通知する通知工程と、を備えることを特徴とする。

また、本発明は、情報処理装置において実行可能なプログラムであって、前記情報処理装置を、端末装置からウェブサーバに対して送信されるデータ取得要求を取得する取得手段と、前記取得手段により取得されたデータ取得要求の中継を許可するか否かを判断する中継制御手段と、前記取得手段により取得されたデータ取得要求に、当該データ取得要求の参照元を示す情報が含まれるか否かを判断する参照元判断手段と、前記中継制御手段により中継を許可しないと判断されたデータ取得要求について、前記参照元判断手段による判断結果に応じて、監査者に通知するか否かを決定する決定手段と、前記決定手段により通知すると決定されたデータ取得要求にかかる情報を監査者に通知する通知手段として機能させることを特徴とする。

本発明によれば、閲覧者によるＷＥＢサイトへのアクセスを管理する監査者が、効率よくアクセスログを管理することが可能となる。

本発明の情報処理システムの構成の一例を示す図である 図１のプロキシサーバ１０１として適用可能な情報処理装置のハードウエア構成の一例を示す図である 第１および第２の実施形態における、プロキシサーバ１０１により実行されるアクセス制御処理を示すフローチャートである アクセスルールテーブルの一例を示す図である アクセスログテーブルの一例を示す図である 本発明におけるクライアントＰＣ１０２、プロキシサーバ１０１、ウェブサーバ１０５それぞれの処理の流れを示す図である 本発明におけるクライアントＰＣ１０２、プロキシサーバ１０１、ウェブサーバ１０５それぞれの処理の流れを示す図である 第１の実施形態においてプロキシサーバ１０１により実行される、アクセスログをクライアントＰＣに表示する処理を示すフローチャートである 第１の実施形態においてクライアントＰＣ１０２に表示される条件設定画面の一例を示す図である ステップＳ８０３、ステップＳ１３０３においてクライアントＰＣ１０２に表示されるアクセスログ表示画面の一例を示す図である 第１の実施形態（ステップＳ８１１）、第４の実施形態においてクライアントＰＣ１０２に表示されるアクセスログ表示画面の一例を示す図である プロキシサーバ１０１の機能構成を示すブロック図である。 第２の実施形態においてプロキシサーバ１０１により実行される、アクセスログをクライアントＰＣに表示する処理を示すフローチャートである 第２の実施形態（ステップＳ１３０９）、第３の実施形態においてクライアントＰＣ１０２に表示されるアクセスログ表示画面の一例を示す図である 第３の実施形態においてプロキシサーバ１０１により実行される、アクセス制御処理およびアクセスログの登録処理を示すフローチャートである 第４の実施形態においてプロキシサーバ１０１により実行されるアクセス制御処理およびアクセスログの登録処理を示すフローチャートである ＨＴＴＰリクエストデータの構成を示す図である ステップＳ１５０８において登録されるアクセスログを示す図である ステップＳ１６０９において登録されるアクセスログを示す図である ステップＳ１６０８において判断基準として用いられる閾値が登録されたテーブルである 図２０に示す閾値を設定する画面の一例を示す図である 第３、第４の実施形態においてプロキシサーバ１０１がクライアントＰＣ１０２に対してアクセスログを送信する処理を示すフローチャートである 第３、第４の実施形態における検索条件設定画面の一例を示す図である

以下、図面を参照して本発明の実施形態を詳細に説明する。

図１は、本発明に係る情報処理システムのシステム構成の一例を示す図である。

図１に示すように、本実施形態に係る情報処理システムは、プロキシサーバ１０１、クライアントＰＣ１０２−１乃至１０２−３（以後、まとめて「クライアントＰＣ１０２」とする）、ＬＡＮ１０３、広域ネットワーク１０４、ウェブサーバ１０５−１乃至１０５−３（以後、まとめて「ウェブサーバ１０５」とする）を備えている。

以下、本発明の情報処理システムを構成する各装置について説明する。

プロキシサーバ１０１は、本発明の情報処理装置として機能する装置であり、クライアントＰＣ１０２とウェブサーバ１０５との間のデータ通信を中継する。また、プロキシサーバ１０１は、クライアントＰＣ１０２とウェブサーバ１０５との間でやりとりされるデータに対して、当該データの中継を許可する（中継する）か、または拒否する（中継しない）かといった中継制御ルールに従い、データの通信制御を行う機能を有している。

また、データの通信制御に関するログを記憶する機能を有している。

クライアントＰＣ１０２は、ウェブサーバ１０５が提供する各種のサービス（ホームページの閲覧等）を利用するユーザが使用する端末装置である。また、プロキシサーバ１０１に記憶されたデータ通信制御に関するログを表示する機能を有する。

ＬＡＮ１０３は、プロキシサーバ１０１、クライアントＰＣ１０２を相互にデータ通信可能に接続するネットワークである。

ウェブサーバ１０５は、各種のウェブサービスを提供するサービス事業者により設置されるサーバ装置である。ここで提供されるサービスとしては、例えばホームページの閲覧サービスや、商品の販売サービス、航空券やホテル等の予約サービスなどがあるが、これに限定されない。

プロキシサーバ１０１とウェブサーバ１０５は、インターネット等の広域ネットワーク１０４を介して、相互にデータ通信可能に接続されている。
以上が本発明の情報処理システム構成の一例の説明である。

以下、図２を用いて、図１に示したプロキシサーバ１０１に適用可能な情報処理装置のハードウエア構成の一例について説明する。

図２において、２０１はＣＰＵで、システムバス２０４に接続される各デバイスやコントローラを統括的に制御する。また、ＲＯＭ２０３あるいは外部メモリ２１１には、ＣＰＵ２０１の制御プログラムであるＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ ／ Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）やオペレーティングシステムプログラム（以下、ＯＳ）や、各サーバ或いは各ＰＣの実行する機能を実現するために必要な各種プログラム等が記憶されている。

２０２はＲＡＭで、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。ＣＰＵ２０１は、処理の実行に際して必要なプログラム等をＲＯＭ２０３あるいは外部メモリ２１１からＲＡＭ２０２にロードして、該ロードしたプログラムを実行することで各種動作を実現するものである。

また、２０５は入力コントローラで、入力装置２０９等からの入力を制御する。２０６はビデオコントローラで、液晶ディスプレイ等のディスプレイ装置２１０への表示を制御する。なお、ディスプレイ装置は、液晶ディスプレイに限られず、ＣＲＴディスプレイなどであっても良い。これらは必要に応じてクライアントが使用するものである。

２０７はメモリコントローラで、ブートプログラム，各種のアプリケーション，フォントデータ，ユーザファイル，編集ファイル，各種データ等を記憶するハードディスク（ＨＤ）や、フレキシブルディスク（ＦＤ）、或いはＰＣＭＣＩＡカードスロットにアダプタを介して接続されるコンパクトフラッシュ（登録商標）メモリ等の外部メモリ２１１へのアクセスを制御する。

２０８は通信Ｉ／Ｆコントローラで、ネットワーク（例えば、図１に示したＬＡＮ１０４）を介して外部機器と接続・通信するものであり、ネットワークでの通信制御処理を実行する。例えば、ＴＣＰ／ＩＰを用いた通信等が可能である。

なお、ＣＰＵ２０１は、例えばＲＡＭ２０２内の表示情報用領域へアウトラインフォントの展開（ラスタライズ）処理を実行することにより、ディスプレイ装置２１０上での表示を可能としている。また、ＣＰＵ２０１は、ディスプレイ装置２１０上の不図示のマウスカーソル等でのユーザ指示を可能とする。

ハードウエア上で動作する各種プログラムは、外部メモリ２１１に記録されており、必要に応じてＲＡＭ２０２にロードされることによりＣＰＵ２０１によって実行されるものである。

次に図３を用いて、本発明の第１および第２の実施形態においてプロキシサーバ１０１が行うアクセス制御処理について説明する。

なお、図３のフローチャートで示す処理については、プロキシサーバ１０１のＣＰＵ２０１が所定の制御プログラムを読み出して実行する処理である。

ステップＳ３０１では、プロキシサーバ１０１のＣＰＵ２０１は、クライアントＰＣ１０２から送信されたＨＴＴＰリクエストデータからアクセス先となるＵＲＬを取得する。

ステップＳ３０２では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ３０１で取得したアクセス先ＵＲＬがアクセスルールテーブル（図４）に存在するかを判定する。すなわち、当該アクセス先ＵＲＬについて、いずれかのアクセスルールが適用されるか否かを判定する。

アクセスルールテーブルに存在すると判定された場合（ステップＳ３０２：ＹＥＳ）は、処理をステップＳ３０３に移行する。

他方、アクセスルールテーブルに存在しないと判定された場合（ステップＳ３０２：ＮＯ）は、処理をステップＳ３０６に移行する。

ステップＳ３０３では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ３０２で適用されると判定されたアクセスルールについて、その動作がアクセスを禁止（データ中継を許可しない）であるか否かを判定する。

ステップＳ３０３においてアクセスを許可すると判定された場合（ステップＳ３０３：許可）は、処理をステップＳ３０６に移行する。

他方、ステップＳ３０３においてアクセスを禁止すると判定された場合（ステップＳ３０３：禁止）は、処理をステップＳ３０４に移行する。

ステップＳ３０４では、プロキシサーバ１０１のＣＰＵ２０１は、クライアントＰＣから送信されたＵＲＬに対するアクセスが禁止された旨の結果をアクセスログテーブル（図５）に記録する。

この際、アクセスログテーブルには、アクセスが禁止された旨の結果（ルール結果）だけでなく、クライアントＰＣ１０２からＨＴＴＰリクエストデータが送信された時刻（アクセス時刻）、ＨＴＴＰリクエストデータを送信したクライアントＰＣを識別する情報（ＩＰアドレス等）（クライアントＩＰアドレス）、アクセス先ＵＲＬ等についても記録される。

また、クライアントＰＣ１０２から送信されたＨＴＴＰリクエストデータに「ＲｅｆｅｒｅｒＵＲＬ（参照元ＵＲＬ）」が含まれる場合には、当該ＲｅｆｅｒｅｒＵＲＬもあわせて記録される。

ステップＳ３０５では、プロキシサーバ１０１のＣＰＵ２０１は、リクエスト元であるクライアントＰＣ１０２に対してアクセスが禁止された旨の結果を示すＨＴＴＰレスポンスデータを送信する。
そして本フローチャートに示す処理を終了する。

ステップＳ３０６以降は、ステップＳ３０２においてクライアントＰＣ１０２から送信されたアクセス先ＵＲＬがアクセスルールに該当しなかった場合、または、該当するアクセスルールに設定された動作が「禁止」以外であった場合の処理である。

ステップＳ３０６では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ３０１で取得したアクセス先ＵＲＬが示すウェブサーバ１０５にアクセスをする。

ステップＳ３０７では、プロキシサーバ１０１のＣＰＵ２０１は、クライアントＰＣから送信されたＵＲＬに対するアクセスが許可された旨の結果をアクセスログテーブル（図５）に記録する。この際、ステップＳ３０４における処理と同様に、アクセスログテーブルに対して、クライアントＰＣ１０２からＨＴＴＰリクエストデータが送信された時刻（アクセス時刻）、ＨＴＴＰリクエストデータを送信したクライアントＰＣのＩＰアドレス（クライアントＩＰアドレス）、アクセス先ＵＲＬについても記録される。

また、クライアントＰＣ１０２から送信されたＨＴＴＰリクエストデータに「ＲｅｆｅｒｅｒＵＲＬ」が含まれる場合には、当該ＲｅｆｅｒｅｒＵＲＬもあわせて記録される。

ステップＳ３０８では、プロキシサーバ１０１のＣＰＵ２０１は、ウェブサーバ１０５からレスポンスデータを取得し、当該レスポンスデータをリクエスト元であるクライアントＰＣ１０２に送信する。
そして、本フローチャートに示す処理を終了する。

なお、本実施形態では、アクセスルールテーブルに設定されていないＵＲＬへのアクセスについては、アクセスを許可するように構成しているが、デフォルト処理としてアクセス禁止として設定をしておき、その設定に従って処理を行うように構成しても良い。

以上の処理により、プロキシサーバ１０１において実行された、クライアントＰＣ１０２から送信されたＨＴＴＰリクエストデータに対する処理を記録することができる。

次に、図６を用いて、本発明の第１および第２の実施形態におけるクライアントＰＣ１０２、プロキシサーバ１０１、ウェブサーバ１０５それぞれの処理の流れを説明する。

なお、図６では、「複数のＵＲＬアクセスからページ全体が構成され、ユーザにより指定されたＵＲＬ自体はアクセスが許可されるが、そこからリンクされている画像のファイル取得先であるＵＲＬについてはアクセスが禁止される場合」の処理について説明する。

ステップＳ６０１では、クライアントＰＣ１０２からプロキシサーバ１０１に対してＨＴＴＰリクエストデータが送信される（図３におけるステップＳ３０１に相当）。図６に示す例では、クライアントＰＣ１０２から送信されたＨＴＴＰリクエストデータ（アクセス先ＵＲＬ）は「ｈｔｔｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／ｉｎｄｅｘ．ｈｔｍｌ」であるとする。

そして、ステップＳ６０２では、プロキシサーバ１０１がステップＳ６０１で送信されたＨＴＴＰリクエストデータを取得し、当該データの中継の可否をアクセスルールテーブルをもとに判定する（図３のステップＳ３０２、Ｓ３０３に相当）。

図６に示す例では、クライアントＰＣ１０２から送信されたアクセス先ＵＲＬは「ｈｔｔｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／ｉｎｄｅｘ．ｈｔｍｌ」であるため、アクセスルールテーブルにおけるルールＩＤ：３（「ｈｔｔｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／＊」）に該当することになる。したがって、当該ルールの動作は「許可」であるので、ステップＳ６０２では、クライアントＰＣ１０２から送信されたデータの中継は許可される（図３のステップＳ３０３：許可に相当）。

ステップＳ６０３では、プロキシサーバ１０１が「ｈｔｔｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／ｉｎｄｅｘ．ｈｔｍｌ」が示すウェブサーバ１０５へアクセスをする。そして、ステップＳ６０４でウェブサーバ１０５は、ステップＳ６０３のアクセスに対するレスポンスデータをプロキシサーバ１０１に送信し、プロキシサーバ１０１は当該レスポンスデータを取得する（図３のステップＳ３０６に相当）。

ステップＳ６０５では、プロキシサーバ１０１は、「ｈｔｔｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／ｉｎｄｅｘ．ｈｔｍｌ」に対するアクセスが許可された旨をアクセスログテーブルに記録する（図３のステップＳ３０７に相当）。なお、ステップＳ６０５で記録されるアクセスログは、図５に示すアクセスログテーブルの「ログＩＤ：３」に示すログにあたる。

ステップＳ６０６では、プロキシサーバ１０１は、ウェブサーバ１０５から取得したレスポンスデータをクライアントＰＣ１０２に対して送信する（図３のステップＳ３０８に相当）。

そして、クライアントＰＣ１０２では、ステップＳ６０６でプロキシサーバ１０１から送信されたレスポンスデータを解析し、ウェブページ内に含まれる画像データの取得先であるＵＲＬを取得する。なお、図６に示す例では、レスポンスデータを解析して得られたＵＲＬは「ｈｔｔｐ：／／ｂｂｓ．ｅｘａｍｐｌｅ．ｃｏｍ／ｉｍａｇｅ．ｐｎｇ」であるとする。

ステップＳ６０７では、クライアントＰＣ１０２から、取得したＵＲＬ（ｈｔｔｐ：／／ｂｂｓ．ｅｘａｍｐｌｅ．ｃｏｍ／ｉｍａｇｅ．ｐｎｇ）をアクセス先とするＨＴＴＰリクエストデータがプロキシサーバ１０１に送信される（図３のステップＳ３０１に相当）。このとき、ＨＴＴＰリクエストデータは、ＲｅｆｅｒｅｒＵＲＬとしてリンク元のウェブページのＵＲＬである「ｈｔｔｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／ｉｎｄｅｘ．ｈｔｍｌ」を有する。

そして、ステップＳ６０８では、プロキシサーバ１０１がステップＳ６０７で送信されたＨＴＴＰリクエストデータを取得し、当該データの中継の可否をアクセスルールテーブルをもとに判定する（図３のステップＳ３０２、Ｓ３０３に相当）。

図６に示す例では、クライアントＰＣ１０２から送信されたアクセス先ＵＲＬは「ｈｔｔｐ：／／ｂｂｓ．ｅｘａｍｐｌｅ．ｃｏｍ／ｉｍａｇｅ．ｐｎｇ」であるため、アクセスルールテーブルにおけるルールＩＤ：１（「ｈｔｔｐ：／／ｂｂｓ．ｅｘａｍｐｌｅ．ｃｏｍ／＊」）に該当することになる。したがって、当該ルールの動作は「禁止」であるので、ステップＳ６０８では、クライアントＰＣから送信されたデータの中継は行われない（図３のステップＳ３０３：禁止に相当）。

ステップＳ６０９では、プロキシサーバ１０１は、「ｈｔｔｐ：／／ｂｂｓ．ｅｘａｍｐｌｅ．ｃｏｍ／ｉｍａｇｅ．ｐｎｇ」に対するアクセスが禁止された旨をアクセスログテーブルに記録する（図３のステップＳ３０３０４に相当）。なお、この際、アクセスログテーブルには、ＲｅｆｅｒｅｒＵＲＬである「ｈｔｔｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／ｉｎｄｅｘ．ｈｔｍｌ」があわせて記録される。なお、ステップＳ６０９で記録されるログは、図５に示すアクセスログテーブルの「ログＩＤ：４」に示すログにあたる。

そして、ステップＳ６１０において、プロキシサーバ１０１からクライアントＰＣ１０２に対して、アクセスが禁止された旨の情報が送信される（図３のステップＳ３０５に相当）。

次に、図７を用いて、独立した２つのウェブページへのアクセスが共にアクセス禁止をされるケースについて、クライアントＰＣ１０２、プロキシサーバ１０１、ウェブサーバ１０５それぞれで実行される処理の流れを説明する。

ステップＳ７０１では、クライアントＰＣ１０２からプロキシサーバ１０１に対してＨＴＴＰリクエストデータが送信される（図３におけるステップＳ３０１に相当）。図７に示す例では、クライアントＰＣ１０２から送信されたＨＴＴＰリクエストデータ（アクセス先ＵＲＬ）は「ｈｔｔｐ：／／ｂｂｓ．ｅｘａｍｐｌｅ．ｃｏｍ／ｉｎｄｅｘ．ｈｔｍｌ」であるとする。

そして、ステップＳ７０２では、プロキシサーバ１０１がステップＳ７０１で送信されたＨＴＴＰリクエストデータを取得し、当該データの中継の可否をアクセスルールテーブルをもとに判定する（図３のステップＳ３０２、Ｓ３０３に相当）。

図７に示す例では、クライアントＰＣ１０２から送信されたアクセス先ＵＲＬは「ｈｔｔｐ：／／ｂｂｓ．ｅｘａｍｐｌｅ．ｃｏｍ／ｉｎｄｅｘ．ｈｔｍｌ」であるため、アクセスルールテーブルにおけるルールＩＤ：１（「ｈｔｔｐ：／／ｂｂｓ．ｅｘａｍｐｌｅ．ｃｏｍ／＊」）に該当することになる。したがって、当該ルールの動作は「禁止」であるので、ステップＳ７０２では、クライアントＰＣ１０２から送信されたデータの中継は行われない（図３のステップＳ３０３：禁止に相当）。

ステップＳ７０３では、プロキシサーバ１０１は、「ｈｔｔｐ：／／ｂｂｓ．ｅｘａｍｐｌｅ．ｃｏｍ／ｉｎｄｅｘ．ｈｔｍｌ」に対するアクセスが禁止された旨をアクセスログテーブルに記録する（図３のステップＳ３０３０４に相当）。なお、ステップＳ７０３で記録されるログは、図５に示すアクセスログテーブルの「ログＩＤ：１」に示すログにあたる。

そして、ステップＳ７０４において、プロキシサーバ１０１からクライアントＰＣ１０２に対して、アクセスが禁止された旨の情報が送信される（図３のステップＳ３０５に相当）。

ステップＳ７０５では、クライアントＰＣ１０２からプロキシサーバ１０１に対してＨＴＴＰリクエストデータが送信される（図３におけるステップＳ３０１に相当）。図７に示す例では、クライアントＰＣ１０２から送信されたＨＴＴＰリクエストデータ（アクセス先ＵＲＬ）は「ｈｔｔｐ：／／ｂｂｓ．ｅｘａｍｐｌｅ．ｃｏｍ／ｍａｉｎ．ｈｔｍｌ」であるとする。

そして、ステップＳ７０６では、プロキシサーバ１０１がステップＳ７０５で送信されたＨＴＴＰリクエストデータを取得し、当該データの中継の可否をアクセスルールテーブルをもとに判定する（図３のステップＳ３０２、Ｓ３０３に相当）。

図７に示す例では、クライアントＰＣ１０２から送信されたアクセス先ＵＲＬは「ｈｔｔｐ：／／ｂｂｓ．ｅｘａｍｐｌｅ．ｃｏｍ／ｍａｉｎ．ｈｔｍｌ」であるため、アクセスルールテーブルにおけるルールＩＤ：１（「ｈｔｔｐ：／／ｂｂｓ．ｅｘａｍｐｌｅ．ｃｏｍ／＊」）に該当することになる。したがって、当該ルールの動作は「禁止」であるので、ステップＳ７０６では、クライアントＰＣ１０２から送信されたデータの中継は行われない（図３のステップＳ３０３：禁止に相当）。

ステップＳ７０７では、プロキシサーバ１０１は、「ｈｔｔｐ：／／ｂｂｓ．ｅｘａｍｐｌｅ．ｃｏｍ／ｍａｉｎ．ｈｔｍｌ」に対するアクセスが禁止された旨をアクセスログテーブルに記録する（図３のステップＳ３０３０４に相当）。なお、ステップＳ７０７で記録されるログは、図５に示すアクセスログテーブルの「ログＩＤ：２」に示すログにあたる。このとき、ステップＳ７０５で送信されたＨＴＴＰリクエストデータにはＲｅｆｅｒｅｒＵＲＬがないため、アクセスログテーブルにもＲｅｆｅｒｅｒＵＲＬは記録されない。

そして、ステップＳ７０８において、プロキシサーバ１０１からクライアントＰＣ１０２に対して、アクセスが禁止された旨の情報が送信される（図３のステップＳ３０５に相当）。

次に、図８を用いて、本発明の第１の実施形態におけるプロキシサーバ１０１がアクセスログテーブルに記録されたアクセスログのうち、アクセスが禁止されたログをクライアントＰＣ１０２に表示する処理について説明する。

なお、図８のフローチャートで示す処理については、プロキシサーバ１０１のＣＰＵ２０１が所定の制御プログラムを読み出して実行する処理である。

ステップＳ８０１では、プロキシサーバ１０１のＣＰＵ２０１は、ユーザからアクセスログの検索条件の設定を受け付ける。

なお、検索条件の設定については、クライアントＰＣ１０２に表示される検索条件設定画面（図９）を介して受け付ける。

ここで、図９に一例を示す検索条件設定画面について説明する。

図９に示す画面では、アクセスログを検索する検索条件として、アクセス時刻の時刻条件（期間や時間範囲）や、「自動除外解析」のＯＮ／ＯＦＦおよび「自動除外解析時間」の設定が可能である。

「自動除外解析」がＯＦＦである場合には、時刻条件により検索されたアクセスログの全てが表示対象となる。

「自動除外解析」がＯＮである場合には、時刻条件により検索されたアクセスログのうち、ＲｅｆｅｒｅｒＵＲＬが記録されていないログ、および、ＲｅｆｅｒｅｒＵＲＬが記録されているログのうち当該ＲｅｆｅｒｅｒＵＲＬへのアクセス時刻から「自動除外解析時間」で設定された時間を経過した後にアクセスされたログが表示対象となる。なお、自動除外解析時間については、ユーザにより任意に設定が可能である。

図９に示す例では、アクセスログテーブルに記録されたアクセス時刻が「２０１０年１０月１日（金）〜２０１０年１０月２８日（木）」までの期間であり、「００時００分〜２４時００分」まで（終日）のログが検索されることを示している。

また、自動除外解析がＯＮである（チェックボックスにチェックがされている）ため、上述の通り、時刻条件により検索されたアクセスログのうち、ＲｅｆｅｒｅｒＵＲＬが記録されていないログ、および、ＲｅｆｅｒｅｒＵＲＬが記録されているログのうち当該ＲｅｆｅｒｅｒＵＲＬへのアクセス時刻から１０秒以上経過した後にアクセスされたログが表示対象となる。

ステップＳ８０２では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ８０１で設定された条件のうち、自動除外解析がＯＮに設定されているか否か（チェックボックスにチェックが入れられているか否か）を判断する。

ＯＦＦに設定されている場合（ステップＳ８０２：ＯＦＦ）は、処理をステップＳ８０３に移行する。

ＯＮに設定されている場合（ステップＳ８０３：ＯＮ）は、処理をステップＳ８０４に移行する。

ステップＳ８０３では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ８０１で設定された時刻条件により検索される禁止アクセスログ（ルール結果が禁止として記録されているアクセスログ）の全てをクライアントＰＣ１０２に表示するべく、クライアントＰＣ１０２に送信する。

ステップＳ８０４では、プロキシサーバ１０１のＣＰＵ２０１は、アクセスログテーブルに記録されたアクセスログのうち最初のアクセスログを読み込む。

ステップＳ８０５では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ８０４で読み込んだアクセスログの「ルール結果」が禁止であるか否かを判断する。

禁止であると判断されると（ステップＳ８０５：ＹＥＳ）、処理をステップＳ８０６に移行する。

禁止ではないと判断されると（ステップＳ８０５：ＮＯ）、処理をステップＳ８１２に移行する。すなわち、当該アクセスログは表示対象から除外される。

ステップＳ８０６では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ８０４で読み込んだアクセスログのアクセス時刻が、ステップＳ８０１で設定された時刻条件を満たすか否かを判断する。すなわち、図９の例においては、当該アクセスログのアクセス時刻が「２０１０年１０月１日（金）〜２０１０年１０月２８日（木）」までの期間であるか否かを判断する。

時刻条件を満たすと判断された場合（ステップＳ８０６：ＹＥＳ）は、処理をステップＳ８０７に移行する。

時刻条件を満たさないと判断された場合（ステップＳ８０６：ＮＯ）は、処理をステップＳ８１２に移行する。すなわち、当該アクセスログは表示対象から除外される。

ステップＳ８０７では、ステップＳ８０４で読み込まれたアクセスログのＨＴＴＰメソッドがＧＥＴメソッドであるか否かを判断する。

ＧＥＴメソッドであると判断されると（ステップＳ８０７：ＹＥＳ）、処理をステップＳ８０８に移行する。

ＧＥＴメソッドではないと判断されると（ステップＳ８０７：ＮＯ）、処理をステップＳ８１１に移行する。すなわち、当該アクセスログを表示対象としてクライアントＰＣ１０２へ表示する。

ステップＳ８０８では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ８０４で読み込んだアクセスログにＲｅｆｅｒｅｒＵＲＬが記録されているか否かを判断する。

ＲｅｆｅｒｅｒＵＲＬが記録されていると判断された場合（ステップＳ８０８：ＹＥＳ）は、処理をステップＳ８０９に移行する。

ＲｅｆｅｒｅｒＵＲＬが記録されていないと判断された場合（ステップＳ８０８：ＮＯ）は、処理をステップＳ８１１に移行する。すなわち、当該アクセスログを表示対象としてクライアントＰＣ１０２へ表示する。

ステップＳ８０９では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ８０４で読み込んだアクセスログに記録されたＲｅｆｅｒｅｒＵＲＬに対するアクセスにかかるアクセスログであり、かつ、ステップＳ８０４で読み込んだアクセスログの「クライアントＩＰアドレス」と同じクライアントＩＰアドレスが記録されたアクセスログを取得する。

なお、本実施例では、同一性の判断にアクセス元のクライアントＰＣのＩＰアドレスを用いたが、これに限られるものではなく、他の基準により同一性を判断しても良い。

ステップＳ８１０では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ８０４で読み込んだアクセスログのアクセス時刻が、ステップＳ８０９で取得したアクセスログのアクセス時刻（ＲｅｆｅｒｅｒＵＲＬへのアクセス時刻）からステップＳ８０１で設定された自動除外解析時間を経過した時刻であるか否かを判断する。すなわち、ステップＳ８０４で読み込んだアクセスログにかかるアクセスが、ＲｅｆｅｒｅｒＵＲＬへのアクセスから自動除外解析時間が経過した後のアクセスであるか否かを判断する。

ＲｅｆｅｒｅｒＵＲＬへのアクセスから自動除外解析時間を経過した後のアクセスであると判断された場合（ステップＳ８１０：ＹＥＳ）は、処理をステップＳ８１１に移行する。すなわち、当該アクセスログを表示対象としてクライアントＰＣ１０２へ表示する。

ＲｅｆｅｒｅｒＵＲＬへのアクセスから自動除外解析時間を経過する前のアクセスであると判断された場合（ステップＳ８１０：ＮＯ）は、処理をステップＳ８１２に移行する。すなわち、当該アクセスログは表示対象から除外される。

ステップＳ８１１では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ８０４で読み込んだアクセスログをクライアントＰＣ１０２に表示するべく、クライアントＰＣ１０２に送信する。

ステップＳ８１２では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ８０４で読み込んだアクセスログがアクセスログテーブルに記録されたアクセスログのうち最後のアクセスログであるか否かを判断する。

最後のアクセスログであると判断されると（ステップＳ８１２：ＹＥＳ）、本フローチャートに示す処理を終了する。

最後のアクセスログではないと判断されると（ステップＳ８１２：ＮＯ）、処理をステップＳ８０４に移行し、次のアクセスログを１行読み込む。

以上の処理により、ユーザ（閲覧者）が意図的にアクセスしたログのみを監査者へ通知することが可能なる。これにより、適切なログ管理が可能となる。

具体的には、ＲｅｆｅｒｅｒＵＲＬが記録されたリクエストデータにかかるアクセスは、意図的なアクセスではない可能性が高い。ただ、ＲｅｆｅｒｅｒＵＲＬが記録されたリクエストデータにかかるアクセスのすべてが意図的ではないアクセスとは言えず、ＲｅｆｅｒｅｒＵＲＬが記録されていたとしても意図的なアクセスである可能性はある。そこで、ＲｅｆｅｒｅｒＵＲＬへのアクセスからの経過時間を考慮し、ＲｅｆｅｒｅｒＵＲＬが記録されたアクセスであっても意図的なアクセスであるか否かを判断する。

すなわち、ＲｅｆｅｒｅｒＵＲＬへのアクセスからの経過時間が短い場合には、自動的にブラウザがリクエストをしたログである可能性が高い。他方、ＲｅｆｅｒｅｒＵＲＬへのアクセスから一定時間が経過した後のアクセスについては、ユーザによる意図的なアクセス（リンク先をクリックした等）である可能性が高いといえる。そのため、ＲｅｆｅｒｅｒＵＲＬへのアクセスからの経過時間を考慮することで、意図的なアクセスであるか否かを適切に判断することが可能となる。

このように、意図的なアクセスであるか否かを判断し、意図的ではないアクセスのログについては通知・表示をしないようにすることで、監査者が大量のログに紛れてしまった有用なログを探し出す手間を低減することが可能となる。その結果、効率的なログ管理が可能となる。

さらに、本実施形態においては、ステップＳ８０７においてリクエストが「ＧＥＴメソッドであるか否か」の判断をして、ＧＥＴメソッドではない場合には、表示対象ログとしている。これは、ＧＥＴメソッドではない（例えばＰＯＳＴ等）場合については、ＲｅｆｅｒｅｒＵＲＬの有無や、ＲｅｆｅｒｅｒＵＲＬへのアクセスからの経過時間に関わらず、意図的なアクセスであることが多いためである。このステップＳ８０７における判断処理により、監査に有用なログを表示させることが可能となる。

なお、本発明の目的は、監査に有用ではないアクセスログを表示させないことである。そのため、ステップＳ８０７における処理は、本発明の目的を達成するために必須の処理でなく、省略したとしても本発明の目的は達成される。

次に、図１０および図１１を用いて、図８のフローチャートに示す処理によりクライアントＰＣ１０２に表示されるアクセスログについて具体的に説明する。

図１０に示す画面は、図８のステップＳ８０３においてクライアントＰＣ１０２に表示される画面である。すなわち、アクセスログテーブル（図５）に記録されたアクセスログのうち、ルール結果が禁止であり、かつ、ステップＳ８０１で図９に示す検索条件設定画面を介して設定された時刻条件を満たすアクセスログの全てが表示されている。

図１０に示す画面では、アクセスログテーブルにおけるログＩＤ：１、２、４、５、６、８のアクセスログが表示されている。

図１１に示す画面は、図８のステップＳ８１１においてクライアントＰＣ１０２に表示される画面である。

以下、アクセスログテーブル（図５）および図８のフローチャートを用いて、図１１に表示されるアクセスログについて詳細に説明する。なお、時刻条件としては、図９に示す条件（「２０１０年１０月１日（金）〜２０１０年１０月２８日（木）」までの期間であり、「００時００分〜２４時００分」まで）であるとする。

アクセスログテーブルに示す「ログＩＤ：１」のアクセスログについては、「ルール結果：禁止」、「時刻条件：満たす」、「ＨＴＴＰメソッド：ＧＥＴ」、「ＲｅｆｅｒｅｒＵＲＬ：なし」である。そのため、図８におけるステップＳ８０８でＮＯと判断され、ステップＳ８１１にて表示対象とされる。

「ログＩＤ：２」のアクセスログについては、「ルール結果：禁止」、「時刻条件：満たす」、「ＨＴＴＰメソッド：ＧＥＴ」、「ＲｅｆｅｒｅｒＵＲＬ：なし」であるため、ログＩＤ：１のアクセスログと同様に表示対象とされる。

「ログＩＤ：３」のアクセスログについては、「ルール結果：許可」であるため、図８のステップＳ８０５においてＮＯと判断され、表示対象から除外される。

「ログＩＤ：４」のアクセスログについては、「ルール結果：禁止」、「時刻条件：満たす」、「ＨＴＴＰメソッド：ＧＥＴ」、「ＲｅｆｅｒｅｒＵＲＬ：あり」、「ＲｅｆｅｒｅｒＵＲＬへのアクセスからの時間差：自動除外解析時間以内」であるため、図８のステップＳ８１０でＮＯと判断され、表示対象から除外される。

なお、ＲｅｆｅｒｅｒＵＲＬへのアクセスにかかるアクセスログは、「ログＩＤ：３」のログであり、当該アクセスからの時間差は０秒である。そのため、自動除外解析時間（１０秒）以内のアクセスであると判断される。

「ログＩＤ：５」のアクセスログについては、ログＩＤ：４のアクセスログと同様に表示対象から除外される。

なお、ＲｅｆｅｒｅｒＵＲＬへのアクセスにかかるアクセスログは、「ログＩＤ：３」のログであり、当該アクセスからの時間差は２秒である。そのため、自動除外解析時間（１０秒）以内のアクセスであると判断される。

「ログＩＤ：６」のアクセスログについては、「ルール結果：禁止」、「時刻条件：満たす」、「ＨＴＴＰメソッド：ＧＥＴ」、「ＲｅｆｅｒｅｒＵＲＬ：あり」、「ＲｅｆｅｒｅｒＵＲＬへのアクセスからの時間差：自動除外解析時間経過後」、であるため、ステップＳ８１０でＹＥＳと判断され、ステップＳ８１１にて表示対象とされる。

なお、ＲｅｆｅｒｅｒＵＲＬへのアクセスにかかるアクセスログは、「ログＩＤ：３」のログであり、当該アクセスからの時間差は２０秒である。そのため、自動除外解析時間（１０秒）を経過した後のアクセスであると判断される。

「ログＩＤ：７」のアクセスログについては、「ルール結果：許可」であるため、図８のステップＳ８０５でＮＯと判断され、表示対象から除外される。

「ログＩＤ：８」のアクセスログについては、「ルール結果：禁止」、「時刻条件：満たす」、「ＨＴＴＰメソッド：ＰＯＳＴ」であるため、図８のステップＳ８０７でＮＯと判断されステップＳ８１１で表示対象とされる。

図１２は、本発明におけるプロキシサーバ１０１の機能構成を示すブロック図である。

取得部１２０１は、クライアントＰＣ１０２からウェブサーバに対して送信されるデータ取得要求（リクエストデータ）を取得する。

参照元判断手段１２０２は、取得部１２０１が取得したリクエストデータに参照元ＵＲＬが含まれているか否かを判断する。

通知部１２０３は、第１決定部１２０５、第２決定部１２０８により通知すると決定されたアクセスログを監査者に対して通知する。

時間差算出部１２０４は、取得部１２０１が取得したリクエストデータがクライアントＰＣ１０２から送信された時刻と、当該リクエストデータに含まれる参照元ＵＲＬに対してリクエストデータが送信された時刻との時間差を算出する。

第１決定部１２０５は、時間差算出部１２０４により算出された時間差に応じて、監査者に対してアクセスログを通知するか否かを決定する。

時間差設定受付部１２０６は、第１決定部１２０５がアクセスログを通知するか否かを決定するための基準となる時間差の設定を受け付ける。

中継制御部１２０７は、クライアントＰＣ１０２から送信されるリクエストデータの中継の可否を決定する。

第２決定部１２０８は、中継制御部１２０７により決定された中継の可否により、当該リクエストデータにかかるアクセスログを監査者に通知するか否かを決定する。

記憶部１２０９は、クライアントＰＣ１０２から送信されたリクエストデータをログとして記憶する。

検索条件受付部１２１０は、記憶部１２０９に記憶されたログデータを検索するための条件の設定を監査者等から受け付ける。

抽出部１２１１は、検索条件受付部１２１０で受け付けた検索条件に合致するログデータを、記憶部１２０９に記憶されたログデータから抽出する。
＜第２の実施形態＞
次に、本発明の第２の実施形態について説明する。

第１の実施形態においては、自動除外解析がＯＮである場合には、ＲｅｆｅｒｅｒＵＲＬへのアクセスからの経過時間を考慮して、アクセスログを表示するか否かを判断した。

これに対して第２の実施形態は、ＲｅｆｅｒｅｒＵＲＬへのアクセスからの経過時間については考慮せず、リクエストデータにＲｅｆｅｒｅＵＲＬが含まれるか否かによって、アクセスログを表示するか否かを判断する実施形態である。

すなわち、第１の実施形態における条件設定画面（図９）では、自動除外解析時間の設定が可能であったが、第２の実施形態における条件設定画面（不図示）では、当該設定ができない画面となる（自動除外解析をするか否かの設定のみが可能な画面となる）。

図１３は、本発明の第２の実施形態において、プロキシサーバ１０１がアクセスログテーブルに記録されたアクセスログのうち、アクセスが禁止されたログをクライアントＰＣ１０２に表示処理を示すフローチャートである。すなわち、第１の実施形態における図８に代わるフローチャートである。

なお、図１３のフローチャートで示す処理については、プロキシサーバ１０１のＣＰＵ２０１が所定の制御プログラムを読み出して実行する処理である。

ステップＳ１３０１〜ステップＳ１３０７に示す処理については、図８におけるステップＳ８０１〜Ｓ８０７に示す処理と同じ処理である。そのため、ここでの説明は省略する。

ステップＳ１３０８では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ１３０４で読み込んだアクセスログにＲｅｆｅｒｅｒＵＲＬが記録されているか否かを判断する。

ＲｅｆｅｒｅｒＵＲＬが記録されていると判断された場合（ステップＳ１３０８：ＹＥＳ）は、処理をステップＳ１３１０へ移行する。

ＲｅｆｅｒｅｒＵＲＬが記録されていないと判断された場合（ステップＳ１３０８：ＮＯ）は、処理をステップＳ１３０９へ移行する。

ステップＳ１３０９では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ１３０４で読み込んだアクセスログをクライアントＰＣ１０２に表示するべく、クライアントＰＣ１０２に送信する。

ステップＳ１３１０では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ１３０４で読み込んだアクセスログが、アクセスログテーブルに記録されたアクセスログのうち最後のアクセスログであるか否かを判断する。

最後のアクセスログであると判断されると（ステップＳ１３１０：ＹＥＳ）、本フローチャートに示す処理を終了する。

最後のアクセスログではないと判断されると（ステップＳ１３１０：ＮＯ）、処理をステップＳ１３０４に移行し、次のアクセスログを１行読み込む。

以上のように、第２の実施形態における処理は、第１の実施形態におけるステップＳ８０９およびステップＳ８１０に示す処理を実行しないものである。これにより、ＲｅｆｅｒｅｒＵＲＬへのアクセスからの経過時間にかかわらず、リクエストデータにＲｅｆｅｒｅｒＵＲＬが存在するアクセスログについては表示対象としないことが可能となる。

図１４に示す画面は、第２の実施形態における図１３のステップＳ１３１１の処理によりクライアントＰＣ１０２に表示される画面である。

アクセスログテーブル（図５）におけるログＩＤ：１、２、８のアクセスログが表示されている。

すなわち、設定された時刻条件を満たすログのうち、「アクセスが禁止されたログであり、かつＲｅｆｅｒｅｒＵＲＬが記録されていないログ」および、「アクセスが禁止されたログであり、ＧＥＴメソッドではないログ」が表示される。

以上の処理により、ユーザ（閲覧者）が意図的にアクセスしたログのみを監査者へ通知することが可能なる。その結果、適切なログ管理が可能となる。

具体的には、ＲｅｆｅｒｅｒＵＲＬが記録されたリクエストデータにかかるアクセスは、ユーザによる意図的なアクセス（リンク先をクリックする等）ではなく、ブラウザが自動的にデータを取得した可能性が高いといえる。

このように、ＲｅｆｅｒｅｒＵＲＬの有無により、意図的なアクセスであるか否かを判断し、意図的ではないアクセスのログについては通知・表示をしないようにすることで、監査者が大量のログに紛れてしまった有用なログを探し出す手間を低減することが可能となる。それにより、効率的なログ管理が可能となる。

さらに、本実施形態においては、ステップＳ１３０７においてリクエストが「ＧＥＴメソッドであるか否か」の判断をして、ＧＥＴメソッドではない場合には、表示対象ログとしている。これは、ＧＥＴメソッドではない（例えばＰＯＳＴ等）場合については、ＲｅｆｅｒｅｒＵＲＬの有無に関わらず、意図的なアクセスであることが多いためである。このステップＳ１３０７における判断処理により、監査に有用なログを表示させることが可能となる。

なお、本発明の目的は、監査に有用ではないアクセスログを表示させないことであるため、ステップＳ１３０７における処理は、本発明の目的を達成するために必須の処理でなく、省略したとしても本発明の目的は達成される。
＜第３の実施形態＞
次に、本発明の第３の実施形態について説明する。

第３の実施形態は、リクエストデータにＲｅｆｅｒｅｒＵＲＬが含まれるか否かにより、当該リクエストに関するアクセスログを残すか否かを判断するものである。

第１および第２の実施形態においては、全てのリクエストに関するアクセスログを残し（図３参照）、当該ログを表示させる際にＲｅｆｅｒｅｒＵＲＬの有無や、ＲｅｆｅｒｅｒＵＲＬへのアクセスからの経過時間を考慮して表示させるか否かを判断した（図８、図１３参照）。

第３の実施形態では、ＲｅｆｅｒｅｒＵＲＬの有無によりアクセスログを残すか否かを決定する構成について説明する。

図１５は、本発明の第３の実施形態において、プロキシサーバ１０１がクライアントＰＣ１０２から送信されたリクエストデータを受信し、当該リクエストにかかるアクセスログを記録する処理を示すフローチャートである。すなわち、第１および第２の実施形態における図３のフローチャートに代わる図である。

なお、図１５のフローチャートで示す処理については、プロキシサーバ１０１のＣＰＵ２０１が所定の制御プログラムを読み出して実行する処理である。

ステップＳ１５０１では、プロキシサーバ１０１のＣＰＵ２０１は、クライアントＰＣ１０２から送信されたＨＴＴＰリクエストデータを取得し、当該リクエストデータからアクセス先となるＵＲＬを取得する。

ステップＳ１５０２では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ１５０１で取得したアクセス先ＵＲＬがアクセスルールテーブル（図４）に存在するか否かを判定する。すなわち、当該アクセス先ＵＲＬについて、いずれかのアクセスルールが適用されるか否かを判定する。

アクセスルールテーブルに存在すると判定された場合（ステップＳ１５０２：ＹＥＳ）は、処理をステップＳ１５０４へ移行する。

他方、アクセスルールテーブルに存在しないと判断された場合（ステップＳ１５０２：ＮＯ）は、処理をステップＳ１５０３に移行する。

ステップＳ１５０３では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ１５０２で適用されると判定されたアクセスルールについて、その動作がアクセスを禁止（データ中継を許可しない）であるか否かを判定する。

ステップＳ１５０３においてアクセスを許可すると判定された場合（ステップＳ１５０３：許可）は、処理をステップＳ１５０４に移行する。

他方、ステップＳ１５０３においてアクセスを禁止すると判定された場合（ステップＳ１５０３：禁止）は、処理をステップＳ１５０６に移行する。

ステップＳ１５０４では、プロキシサーバ１０１のＣＰＵ２０１は、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ１５０１で取得したアクセス先ＵＲＬが示すウェブサーバ１０５にアクセスをする。

ステップＳ１５０５では、プロキシサーバ１０１のＣＰＵ２０１は、ウェブサーバ１０５からレスポンスデータを取得し、当該レスポンスデータをリクエスト元であるクライアントＰＣ１０２に送信する。
そして、本フローチャートに示す処理を終了する。

ステップＳ１５０６では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ１５０１で取得したＨＴＴＰリクエストデータのメソッドがＧＥＴメソッドであるか否かを判断する。

ＧＥＴメソッドであると判断された場合（ステップＳ１５０６：ＹＥＳ）は、処理をステップＳ１５０７に移行する。

ＧＥＴメソッドではないと判断された場合（ステップＳ１５０６：ＮＯ）は、処理をステップＳ１５０８に移行する。

ステップＳ１５０７では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ１５０１で取得したリクエストデータにＲｅｆｅｒｅｒＵＲＬが記録されているか否かを判断する。

ＲｅｆｅｒｅｒＵＲＬが記録されていると判断された場合（ステップＳ１５０７：ＹＥＳ）は、処理をステップＳ１５０９に移行する。

ＲｅｆｅｒｅｒＵＲＬが記録されていないと判断された場合（ステップＳ１５０７：ＮＯ）は、処理をステップＳ１５０８に移行する。

ステップＳ１５０８では、プロキシサーバ１０１のＣＰＵ２０１は、クライアントＰＣからリクエストされたＵＲＬに対するアクセスが禁止された旨の結果をアクセスログテーブル（図１８）に記録する。

この際、アクセスログテーブルには、アクセスが禁止された旨の結果（ルール結果）だけでなく、クライアントＰＣ１０２からＨＴＴＰリクエストデータが送信された時刻（アクセス時刻）、ＨＴＴＰリクエストデータを送信したクライアントＰＣを識別する情報（ＩＰアドレス等）（クライアントＩＰアドレス）、アクセス先ＵＲＬ等についても記録される。

ステップＳ１５０９では、プロキシサーバ１０１のＣＰＵ２０１は、リクエスト元であるクライアントＰＣ１０２に対してアクセスが禁止された旨の結果を示すＨＴＴＰレスポンスデータを送信する。
そして、本フローチャートに示す処理を終了する。

なお、本実施形態では、アクセスルールテーブルに設定されていないＵＲＬへのアクセスについては、アクセスを許可するように構成しているが、デフォルト処理としてアクセス禁止として設定をしておき、その設定に従って処理を行うように構成しても良い。

以上の処理により、ユーザ（閲覧者）が意図的にアクセスしたログのみを記録することが可能なる。これにより、適切なログ管理が可能となる。

具体的には、ＲｅｆｅｒｅｒＵＲＬが記録されたリクエストデータにかかるアクセスは、ユーザによる意図的なアクセス（リンク先をクリックする等）ではなく、ブラウザが自動的にデータを取得した可能性が高いといえる。

このように、ＲｅｆｅｒｅｒＵＲＬの有無により、意図的なアクセスであるか否かを判断し、意図的ではないアクセスのログについては記録として残さないようにすることで、監査者が大量のログに紛れてしまった有用なログを探し出す手間を低減することが可能となる。これにより、効率的なログ管理が可能となる。

さらに、本実施形態においては、ステップＳ１５０６においてリクエストが「ＧＥＴメソッドであるか否か」の判断をして、ＧＥＴメソッドではない場合には、記録としてログを残している。これは、ＧＥＴメソッドではない（例えばＰＯＳＴ等）については、ＲｅｆｅｒｅｒＵＲＬの有無に関わらず、意図的なアクセスであることが多いためである。このステップＳ１５０６における判断処理により、監査に有用なログを記録することが可能となる。

なお、本発明の目的は、監査に有用ではないアクセスログについては登録しない（記録として残さない）ことであるため、ステップＳ１５０６における処理は、本発明の目的を達成するために必須の処理でなく、省略したとしても本発明の目的は達成される。

また、監査に必要なログと不要なログとをアクセスログを記録する際に判断する構成を採ることで、ログを表示させる際の判断が不要となる。このように、不要なログを記録しないことで、プロキシサーバ等の資源（記憶領域等）を有効に利用することが可能となる。

図２２は、本発明の第３の実施形態において、プロキシサーバ１０１がクライアントＰＣ１０２にアクセスログを表示するべくクライアントＰＣ１０２にアクセスログを送信する処理を示すフローチャートである。

なお、図２２のフローチャートで示す処理については、プロキシサーバ１０１のＣＰＵ２０１が所定の制御プログラムを読み出して実行する処理である。

ステップＳ２２０１では、プロキシサーバ１０１のＣＰＵ２０１は、ユーザからアクセスログの検索条件の設定を受け付ける。なお、検索条件の設定については、クライアントＰＣ１０２に表示される検索条件設定画面（図２３）を介して受け付ける。

ここで、図２３に一例を示す検索条件設定画面について説明する。

図２３に示す画面では、アクセスログを検索する条件として、アクセス時刻の時刻条件（期間や時間範囲）の設定が可能である。

図２３に示す例では、アクセスログテーブルに記録されたアクセス時刻が、「２０１０年１０月１日（金）〜２０１０年１０月２８日（木）」までの期間であり、「００時００分〜２４時００分」まで（終日）のログが検索されることを示している。

ステップＳ２２０２では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ２２０１で受け付けた検索条件に合致するアクセスログをアクセスログテーブルから抽出する。

ステップＳ２２０３では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ２２０２で抽出されたアクセスログを、クライアントＰＣ１０２で表示すべくクライアントＰＣ１０２に送信する。

以上の処理により送信されたアクセスログをクライアントＰＣ１０２が受信すると、クライアントＰＣ１０２には、図１４に一例を示す画面が表示される（表示される画面は第２の実施形態と同じである）。
＜第４の実施形態＞
次に、本発明の第４の実施形態について説明する。

第４の実施形態は、リクエストデータにＲｅｆｅｒｅｒＵＲＬが含まれるか否か、およびＲｅｆｅｒｅｒＵＲＬへのアクセスからの経過時間によって、当該リクエストに関するアクセスログを残すか否かを判断するものである。

すなわち、第３の実施形態においては、ＲｅｆｅｒｅｒＵＲＬが含まれるリクエストデータにかかるアクセスログについては全て記録を残さなかった（ログを記憶しなかった）が、第４の実施形態においては、ＲｅｆｅｒｅｒＵＲＬが含まれるリクエストデータにかかるアクセスログについても、当該ＲｅｆｅｒｅｒＵＲＬへのアクセスからの経過時間によってログを記憶するか否かを決定する。

図１６は、本発明の第４の実施形態において、プロキシサーバ１０１がクライアントＰＣ１０２から送信されたリクエストデータを受信し、当該リクエストにかかるアクセスログを記録する処理を示すフローチャートである。

なお、図１６のフローチャートで示す処理については、プロキシサーバ１０１のＣＰＵ２０１が所定の制御プログラムを読み出して実行する処理である。

なお、ステップＳ１６０１〜Ｓ１６０６の処理については、第３の実施形態における図１５のステップＳ１５０１〜Ｓ１５０６と同じ処理であるため、ここでの説明は省略する。

ステップＳ１６０７では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ１６０１で取得したリクエストデータにＲｅｆｅｒｅｒＵＲＬが記録されているか否かを判断する。

ＲｅｆｅｒｅｒＵＲＬが記録されていると判断された場合（ステップＳ１６０７：ＹＥＳ）は、処理をステップＳ１６０８に移行する。

ＲｅｆｅｒｅｒＵＲＬが記録されていないと判断された場合（ステップＳ１６０７：ＮＯ）は、処理をステップＳ１６０９に移行する。

ステップＳ１６０８では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ１６０１で取得したリクエストデータの送信時刻と、ステップＳ１６０７で判断されたＲｅｆｅｒｅｒＵＲＬへのアクセス時刻との差が、図２０に示す閾値を超えるか否かを判断する。すなわち、ＲｅｆｅｒｅｒＵＲＬへのアクセスから閾値を超える時間を経過した後のアクセスであるかを判断する。なお、図２０に示す閾値は、図２１に示す設定画面を介して監査者等により設定される。

ＲｅｆｅｒｅｒＵＲＬへのアクセス時刻から閾値を超える時間が経過していると判断された場合（ステップＳ１６０８：ＹＥＳ）は、処理をステップＳ１６０９に移行する。

ＲｅｆｅｒｅｒＵＲＬへのアクセス時刻からの経過時間が閾値を超えないと判断された場合（ステップＳ１６０８：ＮＯ）は、処理をステップＳ１６１０に移行する。

ステップＳ１６０９では、プロキシサーバ１０１のＣＰＵ２０１は、クライアントＰＣから送信されたＵＲＬに対するアクセスが禁止された旨の結果をアクセスログテーブル（図１９）に記録する。

この際、アクセスログテーブルには、アクセスが禁止された旨の結果（ルール結果）だけでなく、クライアントＰＣ１０２からＨＴＴＰリクエストデータが送信された時刻（アクセス時刻）、ＨＴＴＰリクエストデータを送信したクライアントＰＣを識別する情報（ＩＰアドレス等）（クライアントＩＰアドレス）、アクセス先ＵＲＬ等についても記録される。

また、クライアントＰＣ１０２から送信されたＨＴＴＰリクエストデータに「ＲｅｆｅｒｅｒＵＲＬ（参照元ＵＲＬ）」が含まれる場合には、当該ＲｅｆｅｒｅｒＵＲＬもあわせて記録される。

ステップＳ１６１０では、プロキシサーバ１０１のＣＰＵ２０１は、リクエスト元であるクライアントＰＣ１０２に対してアクセスが禁止された旨の結果を示すＨＴＴＰレスポンスデータを送信する。
そして、本フローチャートに示す処理を終了する。

以上の処理により、ユーザ（閲覧者）が意図的にアクセスしたログのみを記録することが可能なる。これにより、適切なログ管理が可能となる。

具体的には、ＲｅｆｅｒｅｒＵＲＬが記録されたリクエストデータにかかるアクセスは、ユーザによる意図的なアクセスではなく、ブラウザが自動的にアクセスした可能性が高い。ただ、ＲｅｆｅｒｅｒＵＲＬが記録されたリクエストデータにかかるアクセスのすべてが意図的ではないアクセスとは言えず、ＲｅｆｅｒｅｒＵＲＬが記録されていたとしても意図的なアクセスである可能性はある。そこで、ＲｅｆｅｒｅｒＵＲＬへのアクセスからの経過時間を考慮し、ＲｅｆｅｒｅｒＵＲＬが記録されたアクセスであっても意図的なアクセスであるか否かを判断する。

すなわち、ＲｅｆｅｒｅｒＵＲＬへのアクセスからの経過時間が短い場合には、自動的にブラウザがリクエストをしたログである可能性が高い。他方、ＲｅｆｅｒｅｒＵＲＬへのアクセスから一定時間が経過した後のアクセスについては、ユーザによる意図的なアクセス（リンク先をクリックした等）である可能性が高いといえる。そのため、ＲｅｆｅｒｅｒＵＲＬへのアクセスからの経過時間を考慮することで、意図的なアクセスであるか否かを適切に判断することが可能となる。

このように、意図的なアクセスであるか否かを判断し、意図的ではないアクセスのログについては記録として残さないようにすることで、監査者が大量のログに紛れてしまった有用なログを探し出す手間を低減することが可能となる。その結果、効率的なログ管理が可能となる。

さらに、本実施形態においては、ステップＳ１６０６においてリクエストが「ＧＥＴメソッドであるか否か」の判断をして、ＧＥＴメソッドではない場合には、表示対象ログとしている。これは、ＧＥＴメソッドではない（例えばＰＯＳＴ等）については、ＲｅｆｅｒｅｒＵＲＬの有無や、ＲｅｆｅｒｅｒＵＲＬへのアクセスからの経過時間に関わらず、意図的なアクセスであることが多いためである。このステップＳ１６０６における判断処理により、監査に有用なログを表示させることが可能となる。

なお、本発明の目的は、監査に有用ではないアクセスログを表示させないことであるため、ステップＳ１６０６における処理は、本発明の目的を達成するために必須の処理でなく、省略したとしても本発明の目的は達成される。

また、監査に必要なログと不要なログとをアクセスログを記録する際に判断する構成を採ることで、ログを表示させる際の判断が不要となる。このように、不要なログを記録しないことで、プロキシサーバ等の資源（記憶領域等）を有効に利用することが可能となる。

第４の実施形態において、プロキシサーバ１０１がクライアントＰＣ１０２にアクセスログを表示するべく、クライアントＰＣ１０２にアクセスログを送信する処理については、図２２のフローチャートで示す（第３の実施形態と同じ処理である）。

第４の実施形態において、図２２の処理により送信されたアクセスログをクライアントＰＣ１０２が受信した際にクライアントＰＣ１０２に表示される画面については、図１１に示す画面である（第１の実施形態と同じ画面である）。

ここで、図１７を参照して、ＨＴＴＰリクエストデータの構成について説明する。図１７に示すようにＨＴＴＰデータのリクエスト行１７０１、１７０２には、メソッド（図１７の例ではＧＥＴメソッド）、宛先となるＵＲＬ情報（リクエストＵＲＬ）、ＨＴＴＰのバージョン情報が設定される。

本発明の第１〜第４の実施形態では、このリクエスト行１７０１、１７０２に設定されているＵＲＬ情報をアクセス先ＵＲＬとして中継制御ルールと照合する。

またＲｅｆｅｒｅｒ１７０３には、このＨＴＴＰデータの送信元となったＵＲＬ情報（ＲｅｆｅｒｅｒＵＲＬ（参照元ＵＲＬ））が設定される。本発明の第１〜第４の実施形態では、ＨＴＴＰデータに、このＲｅｆｅｒｅｒ１７０３が記録されているか否かを判断する。

なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されることは言うまでもない。

また、本発明におけるプログラムは、図３、図６〜図８の処理方法をコンピュータが実行可能なプログラムである。なお、本発明におけるプログラムは図３、図６〜図８の各装置の処理方法ごとのプログラムであってもよい。

以上のように、前述した実施形態の機能を実現するプログラムを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムを読み出し、実行することによっても本発明の目的が達成されることは言うまでもない。

この場合、記録媒体から読み出されたプログラム自体が本発明の新規な機能を実現することになり、そのプログラムを記録した記録媒体は本発明を構成することになる。

プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＤＶＤ−ＲＯＭ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＥＥＰＲＯＭ、シリコンディスク等を用いることが出来る。

また、コンピュータが読み出したプログラムを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

また、本発明は、複数の機器から構成されるシステムに適用しても、ひとつの機器から成る装置に適用しても良い。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。

さらに、本発明を達成するためのプログラムをネットワーク上のサーバ、データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。なお、上述した各実施形態およびその変形例を組み合わせた構成も全て本発明に含まれるものである。

１０１ プロキシサーバ
１０２ クライアント端末
１０３ ＬＡＮ
１０４ 広域ネットワーク
１０５ ウェブサーバ

Claims (7)

1. 端末装置からウェブサーバに対して送信されるデータ取得要求を取得する取得手段と、
   前記取得手段により取得されたデータ取得要求の中継を許可するか否かを判断する中継制御手段と、
   前記取得手段により取得されたデータ取得要求に、当該データ取得要求の参照元を示す情報が含まれるか否かを判断する参照元判断手段と、
   前記中継制御手段により中継を許可しないと判断されたデータ取得要求に対する前記参照元判断手段による判断結果に応じて、当該データ取得要求の中継が許可されなかった旨を監査者に通知するか否かを決定する決定手段と、
   前記決定手段により通知すると決定された場合、当該データ取得要求の中継が許可されなかった旨を監査者に通知する通知手段と、
   を備えることを特徴とする情報処理装置。
2. 前記決定手段は、さらに、
   前記データ取得要求が、前記中継制御手段により中継を許可しないと判断され、かつ前記参照元判断手段により参照元を示す情報が含まれないと判断された場合、当該データ取得要求の中継が許可されなかった旨を監査者に通知すると決定することを特徴とする請求項１に記載の情報処理装置。
3. 前記決定手段は、さらに、
   前記データ取得要求が、前記中継制御手段により中継を許可しないと判断され、かつ前記参照元判断手段により参照元を示す情報が含まれていると判断された場合、当該データ取得要求の中継が許可されなかった旨を監査者に通知しないと決定することを特徴とする請求項１または２に記載の情報処理装置。
4. 前記データ取得要求が送信された時刻と、当該データ取得要求の参照元に対してデータ取得要求が送信された時刻との時間差を算出する時間差算出手段をさらに備え、
   前記決定手段は、さらに、
   前記データ取得要求が、前記中継制御手段により中継を許可しないと判断され、かつ前記参照元判断手段により参照元を示す情報が含まれていると判断され、かつ前記時間差算出手段により算出された時間差が所定の時間差を超える場合、当該データ取得要求の中継が許可されなかった旨を監査者に通知すると決定することを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
5. 前記所定の時間差の設定を受け付ける時間差設定受付手段をさらに備え、
   前記決定手段は、さらに、
   前記データ取得要求が、前記中継制御手段により中継を許可しないと判断され、かつ前記参照元判断手段により参照元を示す情報が含まれていると判断され、かつ前記時間差算出手段により算出された時間差が、前記時間差設定受付手段により設定を受け付けた時間差を超える場合、当該データ取得要求の中継が許可されなかった旨を監査者に通知をすると決定することを特徴とする請求項４に記載の情報処理装置。
6. 情報処理装置における情報処理方法であって、
   前記情報処理装置の取得手段が、端末装置からウェブサーバに対して送信されるデータ取得要求を取得する取得工程と、
   前記情報処理装置の中継制御手段が、前記取得工程により取得されたデータ取得要求の中継を許可するか否かを判断する中継制御工程と、
   前記情報処理装置の参照元判断手段が、前記取得工程により取得されたデータ取得要求に、当該データ取得要求の参照元を示す情報が含まれるか否かを判断する参照元判断工程と、
   前記情報処理装置の決定手段が、前記中継制御工程により中継を許可しないと判断されたデータ取得要求に対する前記参照元判断工程による判断結果に応じて、当該データ取得要求の中継が許可されなかった旨を監査者に通知するか否かを決定する決定工程と、
   前記情報処理装置の通知手段が、前記決定工程により通知すると決定された場合、当該データ取得要求の中継が許可されなかった旨を監査者に通知する通知工程と、
   を備えることを特徴とする情報処理方法。
7. 情報処理装置において実行可能なプログラムであって、
   前記情報処理装置を、
   端末装置からウェブサーバに対して送信されるデータ取得要求を取得する取得手段と、
   前記取得手段により取得されたデータ取得要求の中継を許可するか否かを判断する中継制御手段と、
   前記取得手段により取得されたデータ取得要求に、当該データ取得要求の参照元を示す情報が含まれるか否かを判断する参照元判断手段と、
   前記中継制御手段により中継を許可しないと判断されたデータ取得要求に対する前記参照元判断手段による判断結果に応じて、当該データ取得要求の中継が許可されなかった旨を監査者に通知するか否かを決定する決定手段と、
   前記決定手段により通知すると決定された場合、当該データ取得要求の中継が許可されなかった旨を監査者に通知する通知手段として機能させることを特徴とするプログラム。

Images