JP6450331B2 - 情報管理システム及び情報管理プログラム - Google Patents

Description

本発明は、ネットワークを介して一のコンピュータから他のコンピュータに送信される情報を中継し管理する技術に関する。

近年、企業や団体による個人情報や機密情報の漏洩事件が後を絶たず、情報セキュリティに関する話題がしばしば報道で取り上げられている。情報の漏洩経路としては、主にインターネットやＵＳＢ等の可搬型記録媒体、電子メール、ＰＣやスマートフォン等の小型デバイス等があげられるが、中でもインターネット経由での漏洩件数が圧倒的に多いのが特徴的である。また、情報の漏洩原因は、必ずしも過失によるものばかりではなく、特定の情報を故意に外部へ送信して漏洩させるケースや、サイバー攻撃により大量のデータが流出してしまうケースも存在する。
こうした事件を背景として、個人情報保護法や不正競争防止法が改正され、個人情報や営業秘密に対する法律面からの保護の強化が図られている。また、２０１６年より運用が開始されたマイナンバー（社会保障・税番号：以下同じ。）についても、番号法に則った厳重な管理が求められている。

これに対し、企業や団体は、サイバー攻撃からガードするための設備を導入することにより外的要因による情報漏洩を防止しつつ、日々の業務における外部へのデータ送信やインターネットサイトの利用を監視し状況に応じて制御することにより内的要因による情報漏洩を防止する急務に迫られている。インターネット上には信頼できるサイトばかりではなく、例えばウィルス感染が確認された危険なサイトやネット詐欺に利用されている違法サイトも混在しており、仮にこのようなサイトに対して情報をアップロードした場合、その情報が利用者の想定外の用途に転用されてしまう懸念がある。また、掲載されているコンテンツの性質上、社内からのアクセスを控えさせたいサイトも存在する。

そこで、このようなサイトの利用を制限するために様々なフィルタリング技術が開発されている。例えば、予めデータベースに設定したアクセス許可サイト／アクセス禁止サイト及び有益語キーワード／禁止語キーワードの各情報に基づいてアクセスの許可又は禁止を決定する閲覧制御方法の発明が知られている（例えば、特許文献１参照。）。この方法では、利用者から閲覧要求されたサイト（以下、「要求サイト」と称する。）がアクセス許可サイトに該当する場合はアクセスを許可し、アクセス禁止サイトに該当する場合はアクセスを禁止する。また、何れにも該当しない場合には、プロキシサーバが要求サイトにアクセスしてそのサイトの内容をチェックする。具体的には、コンテンツに禁止語キーワードが含まれない場合は要求サイトへのアクセスを許可し、禁止語キーワードが含まれる場合には併せて有益語キーワードも含まれる場合にのみ要求サイトへのアクセスを許可する。

また、予めデータベースにカテゴリで分類したサイト情報を登録するとともに、各カテゴリ又はサイトに対し規制するリクエストメソッドを設定しておき、データ中継装置でＨＴＴＰリクエストを受信した際に、そのリクエストメソッドの使用が要求サイトに対して許可されているか否かを判定する技術が開示されている（例えば、特許文献２参照。）。例えば、サイトＡに対してＰＯＳＴメソッドのみが規制対象として設定されているとき、データ中継装置が受信したリクエストがサイトＡに対するＧＥＴメソッドによるリクエストである場合は、リクエストが許可され利用者がサイトＡにアクセス可能となるが、リクエストがサイトＡに対するＰＯＳＴメソッドによるリクエストである場合には、リクエストが規制され利用者はサイトＡにアクセスすることができない。

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

前者の先行技術によれば、要求サイトがアクセスして問題のないサイトであるかについて、サイトのＵＲＬに加えそのサイトのコンテンツに含まれるキーワードも加味してアクセスの許可又は禁止を決定するため、予め設定されたＵＲＬベースのサイト／カテゴリ情報に基づいて行われるフィルタリングに比べ、サイトの実情に合わせたより細やかなアクセス制御が実現できると考えられる。また、後者の先行技術によれば、サイト／カテゴリ情報とリクエストメソッドとを掛け合わせた制御により、同一のサイトでも要求の種類に応じて許可／禁止を切り替えることができるため、例えば閲覧は許可するが掲示板への書き込みは禁止するといった制御が可能となる。

しかしながら、いずれの先行技術においても、利用者の端末から要求サイトに対して送信される内容の確認はなされないため、書き込まれた情報やアップロードしたファイルに個人情報や機密情報が含まれていたとしても、サイトへのアクセスが許可された場合にはその送信要求が実行されることとなる。結果として、個人情報や機密情報が外部サーバに送信されてしまい、情報漏洩の発生を未然に防止することができない。

そこで、本発明は、送信されつつあるデータの内容に応じて保護の必要性の度合いを判断し、その結果に応じてデータ送信を制御する技術の提供を目的とする。

すなわち、本発明の情報管理システムは、データベースに記憶されている保護情報を構成する要素を用いてデータに保護情報が含まれるか否かを検査し、検査結果を出力する検査手段と、検査手段により出力された前記検査結果を記録する記録手段と、検査結果に基づいて前記データが保護の必要性の度合いに応じて複数に分類されるうちの１つの分類である要保護データに該当するか否かを判定する一方、検査手段により検査結果が出力されなかった場合にはデータが要保護データとは異なる分類の判定不能データに該当すると判定する保護要否判定手段と、保護要否判定手段によりデータが要保護データに該当しないと判定された場合にはデータがさらに異なる分類の要規制データにしないと判定する一方、データが要保護データ又は判定不能データに該当すると判定された場合には、予め設定された判定条件に基づいてデータが要規制データに該当するか否かを判定する規制要否判定手段とを備えている。

データベースは、保護情報を構成する要素として例えば名簿を構成する苗字や都道府県市区町村名のキーワードや、メールアドレスや電話番号のような定型情報を形成する形式等、保護情報として識別するために必要となる情報を予め記憶している。したがって、このデータベースを用いることにより、データに含まれる保護情報を効率よく検出させることができる。

また、情報管理システムが対象とするデータは、検査結果に基づき判断される保護の必要性の度合いに応じ複数に分類される。具体的には、まず検査結果に応じてデータが「要保護データに該当する」、「要保護データに該当しない」、「判定不能データに該当する」の３分岐のいずれかに分類される。この分類を受けて、「要保護データに該当する」又は「判定不能データに該当する」データが「要規制データに該当する」、「要規制データに該当しない」の２分岐のいずれかに分類される。上述の態様によれば、後者の分類は予め設定された判定条件に基づいてなされるため、利用環境に応じた判定条件を設定しておくことにより「要規制データに該当する」か否かの判定を精度よく行うことが可能となる。

また、保護要否判定手段は、データに含まれる保護情報の件数がその保護情報に対し予め設定されている閾値以上である場合にはデータが要保護データに該当すると判定し、閾値以下である場合にはデータを要保護データに該当しないと判定する。

保護すべき情報の内容は、業種や職務内容等によって様々である。住所（所在地）情報が多数記載されるデータを検討してみると、顧客名簿や社員名簿のように個人情報の一部として住所が記載されたデータの場合には、含まれる住所の件数が少ないとしても保護の必要性が高いため要保護データに該当すると考えられる。これに対し、企業の事業所リストや弁護士、税理士等のいわゆる士業を営む者の所属先名簿のように、一般に公開されている情報の一部として所在地が記載されたデータの場合には、含まれる所在地の件数が多いとしても保護の必要性は低いことからこのデータは要保護データに該当しないと考えられる。このように、保護すべき情報の軽重は一律に定められるものではなく、仮に一律で定められた判定条件に基づいて要保護データに該当するか否かが判定された場合、その判定結果は利用場面によっては無用の長物になりかねない。

上述した態様によれば、どの保護情報がデータに何件以上含まれていた場合にそのデータが「要保護データに該当する」と判定するか、すなわち保護情報の種類毎の閾値を利用環境に応じて柔軟に設定でき、予め設定されたこの閾値が判定条件として用いられるため、「要保護データに該当する」か否かの判定を精度よく行うことが可能となる。

好ましくは、情報管理システムは、規制要否判定手段により判定されるデータが要規制データに該当するか否かの判定条件を予め設定するルール事前設定手段をさらに備えている。

規制要否判定手段が判定対象とするデータは、検査手段による検査の結果に基づき「要保護データに該当する」とされたデータと、データが参照できず検査できなかった「判定不能データに該当する」データであり、それぞれ性質が異なるものである。そのため、規制要否判定手段がこれらのデータを対象として保護要否判定手段とは異なる分類を行う上では、データ毎に異なる判断基準が適用されることが望ましい。

上述した態様によれば、判定対象とするデータ毎に異なる判定条件を予め設定しておき、規制要否判定手段がこれらのデータを「要規制データに該当する」、「要規制データに該当しない」の２分岐のいずれかに分類する際に、この判定条件を適用させることができる。したがって、より実情に即した形で「要規制データに該当する」か否かの判定を下すことが可能となる。

さらに好ましくは、ルール事前設定手段は、判定条件としてデータサイズの閾値を設定するほかに、保護要否判定手段によりデータが要保護データ又は判定不能データに該当すると判定された場合に、データを一律に要規制データに該当すると判定するか、データを一律に要規制データに該当しないと判定するか、もしくはそのデータサイズに応じてデータが要規制データに該当するか否かを判定するかを設定し、規制要否判定手段は、ルール事前設定手段により予め設定された判定条件に基づいてデータが要規制データに該当するか否かを判定する。

このような態様によれば、「要保護データに該当する」データが「要規制データに該当する」か否かを判定するための条件と、「判定不能データに該当する」データが「要規制データに該当する」か否かを判定するための条件とを、異なる内容で設定することができ、判定条件の一部をなすデータサイズの閾値についても、各々の場合で異なる値を設定することができる。したがって、性質の異なる２パターンのデータを対象として、より細やかな判定条件により「要規制データに該当する」か否かの判定を下すことが可能となる。

また、情報管理システムは、ユーザ端末から送信される外部サーバに対する要求を受信する受信手段をさらに備えており、検査手段は、受信手段により受信された要求に伴いアップロードされたユーザデータに保護情報が含まれるか否かを検査する。

このような態様によれば、ユーザ端末から外部サーバに対して送信されつつあるデータを対象として保護情報が含まれるかを検査し、この検査結果に基づいてデータが「要規制データに該当する」か否かを判定することができる。したがって、ユーザ端末から送信された要求を外部サーバに向けて転送すべきか否かを決定する際に、この判定結果を１つの判断材料とすることが可能となる。

本発明の情報管理プログラムは、外部サーバに対する要求を送信するコンピュータを、上述した各態様の情報管理システムが備える手段として機能させるためのプログラムであって、検査手段としての機能は、要求に伴い外部サーバに送信されつつあるデータに保護情報が含まれるか否かの検査の実行を含む。

外部サーバに対する要求を送信するコンピュータとは、ユーザが入力装置を介して行った操作に起因して外部サーバに対する要求を送信するコンピュータであり、ユーザ端末と言い換えることができる。
このような態様によれば、情報管理システムに設けられていた各手段をユーザ端末のみですべて実装することができるため、ネットワークの混雑状況や他のコンピュータの負荷状況等の影響を受けることなく、外部サーバに送信されつつあるデータの検査を行い、その結果に応じてデータ送信の制御を行うことが可能となる。

言い方を変えると、本発明の情報管理プログラムは、外部サーバに対する要求を送信するコンピュータに、データベースに記憶されている保護情報を構成する要素を用いて要求に伴い外部サーバに送信されつつあるデータに保護情報が含まれるか否かを検査し、検査結果を出力する検査ステップと、検査ステップにより出力された検査結果を記録する記録ステップと、検査結果に基づいてデータが保護の必要性の度合いに応じて複数に分類されるうちの１つの分類である要保護データに該当するか否かを判定する一方、検査ステップにより検査結果が出力されなかった場合にはデータが要保護データとは異なる分類の判定不能データに該当すると判定する保護要否判定ステップと、保護要否判定ステップによりデータが要保護データに該当しないと判定された場合にはデータがさらに異なる分類の要規制データに該当しないと判定する一方、データが要保護データ又は判定不能データに該当すると判定された場合には、予め設定された判定条件に基づいて前記データが要規制データに該当するか否かを判定する規制要否判定ステップとを実行させる。
また、保護要否判定ステップは、データに含まれる保護情報の件数がその保護情報に対し予め設定されている閾値以上である場合にはデータが要保護データに該当すると判定し、閾値以下である場合にはデータを要保護データに該当しないと判定する。
好ましくは、規制要否判定ステップにより判定されるデータが要規制データに該当するか否かの判定条件を予め設定するルール事前設定ステップをさらに含む。
さらに好ましくは、ルール事前設定ステップは、判定条件としてデータサイズの閾値を設定するほかに、保護要否判定ステップによりデータが要保護データ又は判定不能データに該当すると判定された場合に、データを一律に要規制データに該当すると判定するか、データを一律に要規制データに該当しないと判定するか、もしくはそのデータサイズに応じてデータが要規制データに該当するか否かを判定するかを設定し、規制要否判定ステップは、ルール事前設定ステップにより予め設定された判定条件に基づいてデータが要規制データに該当するか否かを判定する。

本発明は、送信されつつあるデータの内容に応じた保護の必要性の度合いを判断し、その結果に応じたデータ送信の制御を実現することができる。

情報管理システムが動作する環境の構成図である。 情報管理システムが利用される場面を説明する図である。 情報管理システムの機能ブロック図である。 ルール設定画面の例を示す図である。 保護情報に関するポリシー設定画面の例を示す図である。 情報管理処理の手順例を示すフローチャートである。 情報管理メイン処理の手順例を示すフローチャートである。 保護情報検査処理の手順例を示すフローチャートである。 情報管理システムが外部サーバに対し送信されるデータを管理する際の動作例を示すシーケンス図である。 情報管理システムが実行する制御により画面上に表示されるアラートメッセージの例を表した図である。 情報管理プログラムが動作する環境の構成図である。 情報管理プログラムの機能ブロック図である。 情報管理処理の手順例を示すフローチャートである。 情報管理メイン処理の手順例を示すフローチャートである。 保護情報検査処理の手順例を示すフローチャートである。 情報管理プログラムが外部サーバに対し送信されるデータを管理する際の動作例を示すシーケンス図である。 情報管理システム／プログラムにおける情報管理メイン処理の異なる手順例を示すフローチャートである。

以下、本発明の実施形態について、図面を参照しながら説明する。なお、以下の実施形態は好ましい例示であり、本発明はこの例示に限定されるものではない。
図１は、一実施形態における情報管理システム１００が動作する環境の構成図である。情報管理システム１００は、例えば一般的な企業に想定されるような社内ＬＡＮに接続されたコンピュータ環境に適用することができる。

この図に示されるように、社内ＬＡＮに相当するネットワーク２０は、ファイアウォール６０の内側に架線されている。ネットワーク２０には、ユーザが日々の業務で利用する端末１０に加え、端末１０が送信元となる通信を中継するプロキシサーバ３０が接続されている。ユーザが端末１０上で、例えばウェブブラウザを起動させて外部のウェブサイトを表示したり外部のメールアドレス宛のメールを送信したりする際に、端末１０はこれらの操作に伴う要求をインターネット７０上（ファイアウォール６０の外側）に存在する外部サーバに向けて送信する。端末１０から送信されるこれらの要求及びこれに伴いアップロードされるデータは、プロキシサーバ３０により中継される。プロキシサーバ３０はウェブプロキシであり、端末１０と外部サーバとの間のＨＴＴＰによる接続を中継する。

ところで、ユーザが例えば社員名簿が掲載されているファイルを外部に向けて送信した場合、ユーザの操作が故意か過失かに関わらず、一旦そのファイルが社外に出ればその後の通信経路を辿る過程で情報漏洩する危険性が生じる。したがって、外部に向けたこのような情報の発信は必要最小限に抑制することが望ましい。

情報管理システム１００は、このような場面で有効に機能するよう構成されている。情報管理システム１００は、ネットワーク２０を介して相互に接続可能なプロキシサーバ３０と検査サーバ４０とに跨って構成される。プロキシサーバ３０には、インターネット７０に接続されている外部サーバに対して端末１０から送信される要求及びこの要求に伴うデータを中継し管理するための機能が実装される。また、検査サーバ４０には、プロキシサーバ３０により中継されたデータに含まれる機密情報や個人情報等の取扱いに注意を要する情報（以下、「保護情報」と称する。）を検出し、さらに検出された保護情報の種類及びその件数を加味してこのデータが保護を要するデータ（以下、「要保護データ」と称する。）であるか否かを検査するための機能が実装される。つまり、プロキシサーバ３０は中継・管理装置として機能し、検査サーバ４０は検査装置として機能する。

より具体的には、プロキシサーバ３０は、端末１０から外部サーバに向けて発せられた要求を受信すると、この要求に伴うアップロードデータの有無をまず確認する。そして、アップロードデータが存在する場合には、このデータを検査サーバ４０に送信する。検査サーバ４０は、アップロードデータを受信すると、辞書データベース５０を用いてこのデータを対象とした保護情報の検査を行い、検査結果をプロキシサーバ３０に送信する。プロキシサーバ３０は、この検査結果にデータサイズ等の条件を併せて加味し、アップロードデータが送信の規制を要するデータ（以下、「要規制データ」と称する。）であるか否かを判定する。その上で、プロキシサーバ３０は、要求の送信先ＵＲＬに基づくフィルタリングを行うことにより端末１０からの要求を外部サーバに向けて転送すべきか否かの判定（以下、「サイト判定」と称する）を行い、要求の転送又は破棄を行う。各判定に関する具体的な処理や保護情報の検査処理については、詳しく後述する。

なお、図１には１台のプロキシサーバ３０が示されているが、プロキシサーバ３０が複数台で構成され、情報管理システム１００の中継・管理機能が各サーバに実装されてもよい。また、辞書データベース５０は、検査サーバ４０の内部記憶領域内に実装されてもよいし、ＵＳＢやＳＣＳＩ等の各種ポートを介して接続されるＵＳＢメモリや外付けのハードディスクドライブ（ＨＤＤ）等の外部記憶媒体、或いはネットワーク２０を介して接続可能な他のコンピュータ上に実装されてもよい。さらに、情報管理システム１００の全ての機能、すなわち中継・管理機能と検査機能とが同一のサーバ（プロキシサーバ３０）上に実装されてもよい。

図２は、情報管理システム１００が機能する場面を説明する図である。
図２中（Ａ）：外部のウェブページに書き込んだ内容を送信する場面が示されている。このウェブページにはお問合せフォームが用意されており、予め用意された複数の選択肢から１つを選択する欄、質問内容をテキスト形式で自由に入力する欄に加え、補足資料を最大３つまで添付可能とするアップロード欄とが組み合わされている。

ユーザが端末１０上でこのウェブページを開き、各欄の入力を終えてから［送信］ボタンを押下すると、端末１０は入力されたデータをこのウェブページで指定されたＵＲＬに対し送信するための要求を送信する。情報管理システム１００はこの場面で機能し、要求を受信し入力データを検査した上で、このデータが要規制データであるか否かを判定する。このケースで入力データとして送信されるのは、お問合せフォーム上で入力した全ての内容、すなわち、「分類」で選択した選択肢と「質問詳細」で入力したテキストと「補足資料」としてアップロードしたファイルであり、これらが保護情報の検査対象となる。

図２中（Ｂ）：ウェブメール画面を起動して外部のメールアドレス宛にメールを送信する場面が示されている。このメールには、テキスト入力された件名及びメール本文の他に、１つの添付ファイルがセットされている。ユーザがこの状態で［送信］ボタンを押下すると、端末１０からメールが送信される。情報管理システム１００はここで機能し、端末１０から送信されたメールを受信し検査した上で、このメールにより送信されるデータが要規制データであるか否かを判定する。このケースでは、「件名」と「メール本文」と「添付ファイル」として添付されたファイルが、保護情報の検査対象となる。

図２中（Ｃ）：クラウドサービスを利用した共有フォルダにファイルをアップロードする場面が示されている。この例では、「ａｒｃｈｉｖｅ」というフォルダのファイル一覧が表示された画面の前面側に、このフォルダに新たなファイルをアップロードするためのメニューが表示された画面が出現しており、アップロード候補として既に２つのファイルが追加されている。ユーザがこの状態で［上記ファイルをアップロード］ボタンを押下すると、端末１０はこれら２ファイルをクラウドサービスで指定された所定のＵＲＬに対し送信するための要求を送信する。情報管理システム１００はこの場面で機能し、上述した例と同様の処理が実行される。このケースでは、クラウド上の共有フォルダにアップロードされつつある２つのファイルが、保護情報の検査対象となる。

図３は、情報管理システム１００の機能ブロック図である。この図に示されるように、情報管理システム１００は、ルール管理部１１０、リクエスト受信部１２０、データ送信部１３０、検査結果受信部１４０、データ判定部１５０、サイト判定部１６０、ログ記録部１７０、リクエスト処理部１８０、パターン記憶部２００、ポリシー管理部２１０、データ受信部２２０、保護情報検出部２３０、要保護判定部２４０及び検査結果送信部２５０を有している。情報管理システム１００は、プロキシサーバ３０と検査サーバ４０とに跨って構成されており、中継及び管理に関わる機能がプロキシサーバ３０に実装され、データの検査に関わる機能が検査サーバ４０に実装される。これにより、プロキシサーバ３０は中継・管理装置として機能し、検査サーバ４０は検査装置として機能する。

情報管理システム１００が中継、検査及び管理の対象とするデータは、ユーザにより端末１０から外部サーバに向けて送信されるデータである。端末１０は、情報管理システム１００の範疇には含まれないが、端末１０から外部サーバに向けて送信される要求を中継し管理するプロキシサーバ３０との関係性を説明するため図３中に併せて示されている。端末１０は、ウェブブラウザやメールクライアント等の外部サーバとのＨＴＴＰ通信に用いられるアプリケーションを有しており、このアプリケーションから送信される要求をプロキシサーバ３０が受信する。また、この要求に対しプロキシサーバ３０から何らかの通知が返された場合には、アプリケーション１８がこれを表示する。

プロキシサーバ３０には、ルール管理部１１０からリクエスト処理部１８０までの機能が実装され、検査サーバ４０には、パターン記憶部２００から検査結果送信部２５０までの機能が実装される。機能間の相互関係を説明する便宜のため、図３に対する以下の説明は各機能に付された符号の順序不同に記述される。

ルール管理部１１０は、情報管理システム１００が端末１０から送信された要求の中継及び管理を行う上で必要となる詳細事項を、例えば社内の情報管理者（以下、「管理者」と略称する。）によりルール設定画面を介してなされた指定に沿って事前に設定し、その設定内容をプロキシサーバ３０の内部記憶領域３６に記憶させる。要求の中継及び管理に関する詳細事項（以下、「ルール」と称する。）とは、例えば、要求の転送可否を判定する際に用いる外部サイトのＵＲＬフィルタリング情報や、要求に伴うアップロードデータを対象とした保護情報の検査結果の記録形態、また保護情報の検査結果に基づきアップロードデータの送信規制の要否を判定するための条件等である。

リクエスト受信部１２０は、端末１０のアプリケーション１８から送信される外部サーバに対する要求を受信して一時的にバッファさせ、この要求に伴うアップロードデータの有無を確認する。
データ送信部１３０は、リクエスト受信部１２０によりバッファされた要求にアップロードデータが存在する場合に、このデータを検査サーバ４０のデータ受信部２２０に送信する。
データ受信部２２０は、プロキシサーバ３０のデータ送信部１３０により送信されたアップロードデータを受信し、検査サーバ４０の内部記憶領域４６に一時保存する。

パターン記憶部２００は、検査サーバ４０の辞書データベース５０に相当し、保護情報を構成する要素、より具体的には苗字、都道府県名や市区町村名等を示すキーワードや定型保護情報を形成するパターン等を記憶している。ここで、「定型保護情報」とは、例えばクレジットカード番号、電話番号、生年月日やメールアドレス等のように定型フォーマットで形成される保護情報である。「定型保護情報を形成するパターン」とは、例えばクレジットカード番号の場合は、連続する１６桁のアラビア数字、或いは１６桁のアラビア数字が４桁ずつハイフン又はスペースで区切られた形式等を指す。

ポリシー管理部２１０は、情報管理システム１００が端末１０からアップロードされたデータに保護情報が含まれるか否かを検査する上で必要となる詳細事項を、例えば管理者によりポリシー設定画面を介してなされた指定に沿って事前に設定し、その設定内容を検査サーバ４０の内部記憶領域４６に記憶させる。保護情報の検査に関する詳細事項（以下、「ポリシー」と称する。）とは、検査対象データが要保護データであると判定するための条件等である。

保護情報検出部２３０は、データ受信部２２０により一時保存されたアップロードデータを対象として、このデータに含まれる保護情報を検出する。保護情報の検出は、パターン記憶部２００に記憶されている情報とのマッチング等により実行される。保護情報検出部２３０は、検出された保護情報の種類と種類毎の検出件数を出力する。

要保護判定部２４０は、保護情報検出部２３０により出力された結果とポリシー管理部２１０に設定されているポリシーに基づいて、アップロードデータが要保護データであるか否かを判定する。例えば、ポリシー管理部２１０に「対象データ中に、メールアドレスが１０件以上、又はクレジットカード番号が５件以上含まれる場合は、要保護データであると判定する」との判定条件が記憶されており、保護情報検出部２３０により「メールアドレス：１２件、クレジットカード番号：２件」との検出結果が出力された場合、要保護判定部２４０はメールアドレスの検出件数がポリシーに設定された閾値以上であることから「アップロードデータは要保護データである」と判定することとなる。

検査結果送信部２５０は、アップロードデータを対象とした保護情報の検査結果、より具体的には保護情報検出部２３０による出力内容及び要保護判定部２４０による判定結果を、プロキシサーバ３０の検査結果受信部１４０に送信すると共に、データ受信部２２０により一時保存されたデータを削除する。
検査結果受信部１４０は、検査サーバ４０の検査結果送信部２５０により送信された検査結果を受信する。

データ判定部１５０は、検査結果受信部１４０により受信された検査結果とルール管理部１１０に設定されているルールに基づいて、アップロードデータが要規制データであるか否かを判定する。
サイト判定部１６０は、ルール管理部１１０に設定されているルールに基づいて、リクエスト受信部１２０によりバッファされた要求を外部サーバに向けて転送すべきか否かを判定する。バッファされた要求に伴うアップロードデータが存在する場合、サイト判定部１６０は、フィルタリング情報に加えデータ判定部１５０により下された判定結果を踏まえて要求の転送可否を判定する。

ログ記録部１７０は、検査結果受信部１４０により受信された検査結果やデータ判定部１５０、サイト判定部１６０により下された判定結果等を、ルール管理部１１０に設定されているルールに従いプロキシサーバ３０の内部記憶領域３６に記録する。

リクエスト処理部１８０は、サイト判定部１６０の判定結果に基づいて、リクエスト受信部１２０によりバッファされた要求を処理する。リクエスト処理部１８０は、転送可と判定された場合にはこの要求を外部サーバに向けて転送し、転送不可と判定された場合にはこの要求を破棄する。要求を破棄する場合には、リクエスト処理部１８０はさらに端末１０に対し要求が破棄された（データ送信がキャンセルされた）旨を示すアラートメッセージ（ＨＴＭＬファイル）を送信する。端末１０がこの通知を受信すると、要求の送信元であるアプリケーション１８がプロキシサーバ３０のリクエスト処理部１８０から送信されたアラートメッセ―ジ（ＨＴＭＬファイル）を表示する。

図４は、ルール管理部１１０により提供されるルールの設定画面の例を表した図である。この図に示されるように、ルールの設定画面には情報管理システム１００が要求の中継及び管理を行う上で必要となる事項が表示される。管理者は、この設定画面を通じて要求の中継及び管理に関するルールを事前に設定することができる。

ルール管理部１１０は、例えば、サイト判定対象ＵＲＬ、ログの記録形態、データ検査結果に基づく要求の転送可否等を設定するための画面を提供する。

「サイト判定対象ＵＲＬ」では、要求の送信先、すなわちユーザがアクセスしようとしたサイトが問題のないサイトか否かをサイト判定部１６０が判定する際に用いるＵＲＬ、いわばＵＲＬに基づく外部サイトのフィルタリング情報を設定する。サイト判定対象ＵＲＬは、「無条件許可サイト」、「規制サイト」及び「規制例外サイト」の３つに分類されており、いずれも該当するサイトのＵＲＬが指定される。
無条件許可サイトとは、信頼できるサイトであることが確認されており無条件にアクセスを許可するサイトを指す。情報管理システム１００は、無条件許可サイトに対する要求の転送を全て許可する。要求にアップロードデータが伴う場合には、情報管理システム１００は、このデータを対象とした保護情報の検査は行わずに要求の転送を許可する。

規制サイトとは、何らかの理由によりアクセスを許可すべきでないため無条件にアクセスを規制するサイトを指す。情報管理システム１００は、規制サイトに対する要求の転送を全て破棄し、要求の送信元である端末１０に対しその旨を通知する。要求にアップロードデータが伴う場合には、情報管理システム１００は、このデータを対象とした保護情報の検査を行い、規制サイトに対しどのような情報が送信されつつあったかについてログを記録した上でその要求を破棄する。
規制例外サイトとは、文字通り「規制サイトの例外」であり、アクセスを許可しつつアップロードデータの監視も行うサイトを指す。情報管理システム１００は、規制例外サイトに対する要求を許可するとともに、これに伴うアップロードデータを対象とした保護情報の検査及びログの記録を行う。

なお、上述した３つの分類に設定されたＵＲＬのいずれにも該当しないサイトは、アクセスを規制すべき理由がサイト側には存在しないか、事前に把握されていない。したがって、このようなサイトに対する要求は、アップロードデータが伴わない場合には全て転送される。これに対し、アップロードデータが伴う場合には、そのデータに保護情報がどの程度含まれるかにより要求が転送されるか否かが決定される。より具体的には、アップロードデータが伴う場合の要求の転送可否は、図４に示されたルール設定画面の下部にある「データ検査結果に基づくリクエスト転送の可否」で設定する判定条件に沿って判定されることとなる。

「ログの記録形態」では、要求に伴うアップロードデータを対象に実施された保護情報の検査結果の記録形態を設定させる。「検査結果の出力のみ」が選択された場合、情報管理システム１００は、アップロードデータに含まれた保護情報の種類及び種類毎の件数等を記録する。「検査結果の出力及び検査対象データの保存」が選択された場合、情報管理システム１００は、検査結果を記録するとともに検査対象としたアップロードデータを保存する。

「データ検査結果に基づくリクエスト転送の可否」では、保護情報の検査結果に基づきアップロードデータが要規制データであるか否かを判定するための条件を設定させる。アップロードデータが問題なく参照可能な状態であれば、情報管理システム１００は保護情報の検査を行い要保護データであるか否かの判定を下すことができる。ところが、アップロードデータが参照不可能な状態の場合、例えばデータがファイル形式であり、このファイルにパスワードが付いていたり、ファイルが暗号化されていたり、或いは破損していたりする場合には、情報管理システム１００はその内容をチェックできないため保護情報の検査を行うことができない。

そこで、検査結果としてあらかじめ想定し得る３つのパターン、すなわち「データが要保護と判定された場合（問題なく検査できた場合）」、「データが検査不能ファイル（パスワード付きファイル）であった場合」及び「データが検査不能ファイル（その他の理由）であった場合」に、情報管理システム１００がどのような判定基準でこのデータを要規制データであると判定するかを事前設定できるようにしている。

例えば、図４に示されるように、「データが要保護と判定された場合」において「一部規制（対象データサイズ：５ＭＢ以上）」と設定された場合には、閾値として指定されたファイルサイズ（５ＭＢ）を境に下される判定が変わり、データが５ＭＢ以上の場合は要規制データであると判定され規制対象として扱われる一方、５ＭＢ未満の場合には要規制データでないと判定され規制対象外として扱われる。また、「データが検査不能ファイルである場合」において「全て規制」が選択された場合には、一律で要規制データであると判定され、検査できなかったデータは全て規制対象として扱われることとなる。

なお、データが検査不能ファイルであった場合はデータの検査ができていないため、そのデータが保護情報を含むものであるか否かが一切分からない。しかしながら、参照不可能なデータであるということは、仮に外部サーバに送信されたとしても、そのデータがどのようなファイルであるかを知る者でなければ開くことができないため、むしろ保護された状態である（規制が不要である）、とみることもできる。例えば、送信されつつあるメールが検査対象となり、このメールに添付されていたデータがパスワード付きファイルであったために参照できず検査できなかった場合、メールの受信者がパスワードを知っていれば添付ファイルを開くことができるが、転送過程で何らかの事情によりこのメールが傍受されたとしても、パスワードが分からなければファイルが開かれる心配はない。そこで、検査不能ファイルについても、検査できた場合（データが要保護と判定された場合）と同様に、「全て許可」、「一部規制」及び「全て規制」の３つの選択肢を用意している。

図５は、ポリシー管理部２１０により提供される保護情報に関するポリシーの設定画面の例を表した図である。この図に示されるように、ポリシーの設定画面には、情報管理システム１００が管理対象とする端末１０からの要求に伴いアップロードされたデータを対象として保護情報の検査を行う上で必要となるポリシーが表示される。管理者は、この設定画面を通じてポリシーを事前に設定することができる。

ポリシー管理部２１０は、例えば、端末１０からの要求に伴いアップロードされたデータが要保護データであるか否かを判定するための条件として、保護情報として検出する項目及び各項目に対する閾値を設定する。例えば、データ中にメールアドレスとして識別される記載が１０箇所以上ある場合に要保護データとして扱いたい場合には、「メールアドレス」に対する閾値に「１０」を設定する。検出する項目の機密度、ひいては保護の必要性が高いほど閾値には小さな値を設定するのが好ましい。例えば、図５では「マイナンバー」に対する閾値が「１」と設定されているが、これはデータ内にマイナンバーとして識別される記載が１箇所でも存在する場合には要保護データとして判定することを意味する。

また、個々の項目の検出条件をＡＮＤ／ＯＲのいずれで連結させるかを選択することができ、利用環境に合わせたより柔軟な判定条件の指定を可能としている。例えば、図５では、１行目から３行目（電話番号・住所・苗字）と４行目から５行目（苗字・生年月日）がＡＮＤで連結され、その他の行はＯＲで連結されている。この場合は、「電話番号が２箇所以上、かつ、住所が２箇所以上、かつ、苗字が２箇所以上」又は「苗字が１０箇所以上、かつ、生年月日が１０箇所以上」又は「マイナンバーが１箇所以上」又は「メールアドレスが１０箇所以上」又は‥‥（以下略）のような判定条件が設定されることとなる。このような判定条件を予め指定することにより、検査対象データが要保護データであるか否かを精度よく検査することが可能となる。

図６は、情報管理システム１００による情報管理処理の手順例を示すフローチャートである。情報管理処理は、プロキシサーバ３０のＯＳ起動に伴いその動作を開始し、意図的に強制終了されない限りはプロキシサーバ３０がシャットダウンするまで動作し続ける。なお、図６〜８のフローチャートに示された各処理を実行するのは情報管理システム１００であり、より具体的には、情報管理システム１００が有する各機能部１１０〜２５０であるが、情報管理システム１００を動作させる主体は情報管理システム１００が有する各機能が実装されるサーバ３０，４０のＣＰＵ３２，４２である。つまり、厳密にはＣＰＵ３２，４２がこれらのフローチャートに示された各処理をサーバ３０，４０に実装された各機能部に実行させることにより、情報管理システム１００が機能する。

以下、手順例に沿って説明する。
ステップＳ１００：ＣＰＵ３２は、リクエスト受信部１２０に端末１０から送信された外部サーバに対する要求を受信させ、これを一時的にバッファさせる。
ステップＳ１０２：ＣＰＵ３２は、サイト判定部１６０に前ステップＳ１００でバッファされた要求の送信先が無条件許可サイトでないか否かを確認させる。無条件許可サイトでない場合（Ｙｅｓ）、ＣＰＵ３２は次にステップＳ１０４を実行する。無条件許可サイトである場合（Ｎｏ）、ＣＰＵ３２は次にステップＳ１１２を実行する。
ステップＳ１０４：ＣＰＵ３２は、情報管理メイン処理を実行する。情報管理メイン処理の詳細は後述する。

ステップＳ１０６：ＣＰＵ３２は、前ステップＳ１０４で返された判定結果を確認する。（端末１０から送信された要求に伴うアップロードデータが）要規制データであると判定された場合（Ｙｅｓ）、ＣＰＵ３２は次にステップＳ１０８を実行する。要規制データでないと判定された場合（Ｎｏ）、ＣＰＵ３２は次にステップＳ１１０を実行する。
ステップＳ１０８：ＣＰＵ３２は、サイト判定部１６０にステップＳ１００でバッファされた要求の送信先が規制例外サイトであるか否かを確認させる。規制例外サイトである場合（Ｙｅｓ）、ＣＰＵ３２は次にステップＳ１１２を実行する。規制例外サイトでない場合（Ｎｏ）、ＣＰＵ３２は次にステップＳ１１４を実行する。
ステップＳ１１０：ＣＰＵ３２は、サイト判定部１６０にステップＳ１００でバッファされた要求の送信先が規制サイトでないか否かを確認させる。規制サイトでない場合（Ｙｅｓ）、ＣＰＵ３２は次にステップＳ１１２を実行する。規制サイトである場合（Ｎｏ）、ＣＰＵ３２は次にステップＳ１０８を実行する。

ステップＳ１１２：ＣＰＵ３２は、リクエスト処理部１８０にステップＳ１００でバッファされた要求を外部サーバに向けて転送させる。
ステップＳ１１４：ＣＰＵ３２は、リクエスト処理部１８０にステップＳ１００でバッファされた要求を破棄させる。
ステップＳ１１６：ＣＰＵ３２は、リクエスト処理部１８０に要求が破棄された旨を要求の送信元である端末１０へ通知させる。
以上の処理を終えると、端末１０から送信された１つの要求に対しプロキシサーバ３０（中継・管理装置）が実行する情報管理処理が終了する。

図７は、情報管理システム１００による情報管理メイン処理の手順例を示すフローチャートである。以下、手順例に沿って説明する。

ステップＳ１５０：ＣＰＵ３２は、リクエスト受信部１２０に端末１０から送信された外部サーバに対する要求がアップロードデータを伴うか否かを確認させる。要求がアップロードデータを伴う場合（Ｙｅｓ）、ＣＰＵ３２は次にステップＳ１５２を実行する。要求がアップロードデータを伴わない場合（Ｎｏ）、ＣＰＵ３２は次にステップＳ１６８を実行する。
ステップＳ１５２：ＣＰＵ３２は、データ送信部１３０に要求に伴うアップロードデータを検査サーバ４０へ送信させる。
ステップＳ１５４：検査サーバ４０のＣＰＵ４２は、保護情報検査処理を実行する。保護情報検査処理の詳細は後述する。
ステップＳ１５６：ＣＰＵ３２は、検査結果受信部１４０に前ステップＳ１５４で実行された保護情報検査処理の結果を検査サーバ４０から受信させる。

ステップＳ１６０：ＣＰＵ３２は、データ判定部１５０にルール管理部１１０に予め設定されたルールを参照させ、以降のステップで実行される処理に備える。
ステップＳ１６２：ＣＰＵ３２は、データ判定部１５０にステップＳ１５６で受信された検査結果を確認させる。（端末１０から送信された要求に伴うアップロードデータが）要保護データであると判定された場合（Ｙｅｓ）、ＣＰＵ３２は次にステップＳ１６４を実行する。要保護データでないと判定された場合（Ｎｏ）、ＣＰＵ３２は次にステップＳ１６８を実行する。要保護データか否かが不明である場合（不明）、すなわちデータが検査不能ファイルである場合には、ＣＰＵ３２は次にステップＳ１７０を実行する。

ステップＳ１６４：ＣＰＵ３２は、データ判定部１５０に要保護データに対する規制の要否に関するルール設定を確認させる。要保護データを伴う要求の転送を全て許可する設定である場合（全て許可）、ＣＰＵ３２は次にステップＳ１６８を実行する。要保護データのデータサイズに応じて要求の転送を規制するか否か決定する設定である場合（一部規制）、ＣＰＵ３２は次にステップＳ１６６を実行する。要保護データを伴う要求の転送を全て規制する設定である場合（全て規制）、ＣＰＵ３２は次にステップＳ１７４を実行する。
ステップＳ１６６：ＣＰＵ３２は、データ判定部１５０に要保護データ（アップロードデータ）のデータサイズがルールで設定されたサイズ未満であるか否かを確認させる。規定サイズ未満である場合（Ｙｅｓ）、ＣＰＵ３２は次にステップＳ１６８を実行する。規定サイズ以上である場合（Ｎｏ）、ＣＰＵ３２は次にステップＳ１７４を実行する。

ステップＳ１６８：ＣＰＵ３２は、サイト判定部１６０にアップロードデータが要規制データではないと判定させる。
ステップＳ１７０：ＣＰＵ３２は、データ判定部１５０に検査不能ファイルに対する規制の要否に関するルール設定を確認させる。検査不能ファイルを伴う要求の転送を全て許可する設定である場合（全て許可）、ＣＰＵ３２は次にステップＳ１６８を実行する。検査不能ファイルのファイルサイズに応じて要求の転送を規制するか否か決定する設定である場合（一部規制）、ＣＰＵ３２は次にステップＳ１７２を実行する。検査不能ファイルを伴う要求の転送を全て規制する設定である場合（全て規制）、ＣＰＵ３２は次にステップＳ１７４を実行する。

ステップＳ１７２：ＣＰＵ３２は、データ判定部１５０に検査不能ファイル（アップロードデータ）のデータサイズがルールで設定されたサイズ以上であるか否かを確認させる。規定サイズ以上である場合（Ｙｅｓ）、ＣＰＵ３２は次にステップＳ１７４を実行する。規定サイズ未満である場合（Ｎｏ）、ＣＰＵ３２は次にステップＳ１６８を実行する。
ステップＳ１７４：ＣＰＵ３２は、サイト判定部１６０にアップロードデータが要規制データであると判定させる。

ステップＳ１７６：ＣＰＵ３２は、ログ記録部１７０にステップＳ１５６で受信された検査結果とステップＳ１６８又はステップＳ１７４で下された要規制データであるか否かの判定結果とを記録させる。なお、アップロードデータが無い場合（ステップＳ１５０：Ｎｏ）は、検査対象となるデータが存在していないためこの処理をスキップしてもよい。
以上の処理を終えると、ＣＰＵ３２は、ステップＳ１６８又はステップＳ１７４で下された要規制データであるか否かの判定結果を情報管理メイン処理の呼び出し元である図６中のステップＳ１０４に返し、情報管理処理（図６）に復帰する。

図８は、情報管理システム１００による保護情報検査処理の手順例を示すフローチャートである。保護情報検査処理では、ポリシー管理部２１０に予め設定されている内容に沿って、検査対象データが要保護データであるか否か（検査対象となるデータに保護情報が規定件数以上含まれるか否か）の検査がなされる。
以下、手順例に沿って説明する。

ステップＳ２００：ＣＰＵ４２は、データ受信部２２０にプロキシサーバ３０から送信されたデータを受信させ一時保存させる。

ステップＳ２０２：ＣＰＵ４２は、保護情報検出部２３０にステップＳ２００で一時保存されたデータに含まれる保護情報を検出させる。保護情報の検出は、パターン記憶部２００に記憶されているキーワードやパターンとのマッチング等により行われる。
ステップＳ２０４：ＣＰＵ４２は、要保護判定部２４０に前ステップＳ２０２で検出された保護情報の種類毎の件数がポリシー管理部２１０に予め設定されている保護情報の種類毎の検出件数の閾値以上であるか否かを確認させる。検出件数が規定の閾値以上である場合（Ｙｅｓ）、ＣＰＵ４２は次にステップＳ２０６を実行する。検出件数が規定の閾値未満である場合（Ｎｏ）、ＣＰＵ４２は次にステップＳ２０８を実行する。

ステップＳ２０６：ＣＰＵ４２は、要保護判定部２４０に検査対象データが要保護データであると判定させる。
ステップＳ２０８：ＣＰＵ４２は、要保護判定部２４０に検査対象データが要保護データでないと判定させる。
ステップＳ２１０：ＣＰＵ４２は、検査結果送信部２５０にステップＳ２００で一時保存されたデータを対象として以上のステップで実行された保護情報の検査結果をプロキシサーバ３０に送信させてから一時保存されたデータを削除させる。
以上の処理を終えると、保護情報検査処理の呼び出し元である情報管理メイン処理（図７）中のステップＳ１５４に戻り、処理の制御が検査サーバ４０のＣＰＵ４２から中継サーバのＣＰＵ３２に復帰する。

図９は、情報管理システム１００が外部サーバに対し送信されるデータを管理する際の動作例を示すシーケンス図である。プロキシサーバ３０が管理・中継装置として、検査サーバ４０が検査装置としてそれぞれ機能する。コンピュータ間でパケットを送受信する際に事前に行われるプロトコルのネゴシエーションやセッション確立に相当するステップについては一般的事項であるため記載を省略している。以下、動作例に沿って説明する。

ユーザが端末１０でウェブブラウザを起動して外部のウェブサイトにアクセスし、何らかの情報を入力して送信ボタンをクリックすると、このタイミングで端末１０から外部サーバに対する要求が送信される（Ｓ１１）。これをプロキシサーバ３０が受信し、この要求に伴ってアップロードされたデータの有無を確認する（Ｓ１２）。今回はユーザが入力した情報を送信しようとしておりアップロードデータが存在するため、プロキシサーバ３０はこのデータを検査サーバ４０に送信する（Ｓ１３）。検査サーバ４０は、受信したデータに保護情報が含まれるか否かを検査し（Ｓ１４）、検査結果をプロキシサーバ３０に送信する（Ｓ１５）。プロキシサーバ３０は、受信した検査結果に基づいて今回の要求に伴うアップロードデータが要規制データであるか否かを判定し（Ｓ１６）、検査結果と判定結果をログに記録する（Ｓ１７）。その上で、要求の送信先ＵＲＬに対するサイト判定を行う（Ｓ１８）。今回のアップロードデータは要規制データではあるが、要求の送信先が規制例外サイトに該当するため、プロキシサーバ３０は外部サーバに向けて要求を転送する（Ｓ１９）。要求の転送に伴いアップロードデータが外部サーバに送信される。このようにして、端末１０から送信された１つ目の要求に対し実行される一連の処理が完了する。

しばらくして、ユーザが端末１０で上記とは異なるウェブサイトにアクセスし、何らかの情報を入力して送信ボタンをクリックすると、このタイミングで端末１０から外部サーバに対する要求が送信される（Ｓ２１）。これをプロキシサーバ３０が受信し、この要求に伴ってアップロードされたデータの有無を確認する（Ｓ２２）。今回もアップロードデータが存在するため、プロキシサーバ３０はこのデータを検査サーバ４０に送信する（Ｓ２３）。検査サーバ４０は、受信したデータに保護情報が含まれるか否かを検査し（Ｓ２４）、検査結果をプロキシサーバ３０に送信する（Ｓ２５）。プロキシサーバ３０は、受信した検査結果に基づいて今回の要求に伴うアップロードデータが要規制データであるか否かを判定し（Ｓ２６）、検査結果と判定結果をログに記録する（Ｓ２７）。その上で、要求の送信先ＵＲＬに対するサイト判定を行う（Ｓ２８）。今回のアップロードデータは要規制データであり、要求の送信先が規制サイトに該当するため、プロキシサーバ３０は要求を外部サーバには転送せずに破棄する（Ｓ２９）。プロキシサーバ３０は、要求が破棄された旨、すなわちアップロードデータが外部サーバに送信されなかった旨をこの要求の送信元である端末１０に対して通知する（Ｓ３０）。このようにして、端末１０から送信された２つ目の要求に対し実行される一連の処理が完了する。

図１０が、情報管理システム１００が実行する制御により端末１０のディスプレイ上に表示されるアラートメッセージの例を表した図である。

図１０中（Ａ）：ユーザが外部サーバに対し送信しようとしたデータが要保護データであると判定され、且つルールにおいて「データが要保護と判定された場合」に要求の転送が規制されるよう設定されている場合には、データ送信がキャンセルされた（外部サーバに対する要求が破棄された）旨のアラートメッセージが表示される。このとき、どの保護情報に起因してデータが要保護データであると判定されたのかを併せてユーザに通知する。この図に示される例では、データ中にマイナンバーとして識別される情報が閾値以上の件数検出されたことが示されている。
図１０中（Ｂ）：ユーザが外部サーバに対し送信しようとしたデータがパスワード付きファイルであり、且つルールにおいて「データが検査不能ファイル（パスワード付きファイル）である場合」に要求の転送が規制されるように設定されている場合には、パスワード付きファイルを送信しようとしたためにデータ送信がキャンセルされた旨のアラートメッセージが表示される。

〔情報管理プログラム〕
図１１は、一実施形態における情報管理プログラム３００が動作する環境の構成図である。情報管理プログラム３００は、一般的なクライアント環境に適用することができる。ここでは、情報管理プログラム３００が企業内で社内ＬＡＮに接続されたクライアント環境に適用される場合を例に挙げて説明する。

この図に示されるように、社内ＬＡＮに相当するネットワーク２０がファイアウォール６０の内側に配架されている。ネットワーク２０には、クライアント環境に相当する端末１１に加え、端末１１とインターネット７０上（ファイアウォール６０の外側）に存在する外部サーバとの間でやりとりされるＨＴＴＰによる通信を中継するプロキシサーバ３１が接続されている。端末１１から外部サーバに対し送信される要求及びこの要求に伴ってアップロードされるデータは、プロキシサーバ３１により中継される。

情報管理プログラム３００は端末１１で動作する。端末１１は、ウェブブラウザやメールクライアント等の外部サーバとのＨＴＴＰ通信に用いられるアプリケーションを有しており、例えば、ユーザが端末１１でウェブブラウザを起動させて外部のウェブサイトを表示したり外部のメールアドレス宛のメールを送信したりしようとすると、端末１１はこれらの操作に伴う要求を外部サーバに対して送信する。このとき情報管理プログラム３００は、外部サーバに対する要求が端末１１から送信される前に、この要求に伴うデータに保護情報が含まれるか否かを検査するとともに要求先ＵＲＬに対するサイト判定を実施し、これらの結果に応じて要求を制御する。情報管理プログラム３００は、送信して問題ない要求であると判断した場合にはこの要求を送信する一方、送信を規制すべき要求であると判断した場合にはこの要求を破棄する。

なお、端末１１から要求が送信されると、この要求はプロキシサーバ３１により受信されたのち、外部サーバに向けて転送される。プロキシサーバ３１は情報管理プログラム３００の範疇には含まれないが、端末１１との関係性を説明するために図１２中に併せて示されている。

図１２は、情報管理プログラム３００の機能ブロック図である。この図に示されるように、情報管理プログラム３００は、パターン記憶部３１０、ポリシー管理部３２０、ルール管理部３３０、リクエスト検出部３４０、データ取得部３５０、保護情報検出部３６０、要保護判定部３７０、データ判定部３８０、サイト判定部３９０、ログ記録部４００、リクエスト処理部４１０及びアラート出力部４２０を有している。

図１〜１０に沿って説明した先述の情報管理システム１００においては、要求を中継・管理するための機能がプロキシサーバ３０に実装される一方、要求に伴うデータを検査するための機能が検査サーバ４０に実装され、これらのサーバ３０，４０が連携し合うことにより情報管理システム１００が機能した。これに対し、情報管理プログラム３００は、要求を中継・管理するための機能と要求に伴うデータを検査するための機能とを合わせた全ての機能が端末１１に実装され、端末１１のみで機能する。

パターン記憶部３１０は、保護情報を構成するさまざまな要素を記憶している。
ポリシー管理部３２０は、情報管理プログラム３００が要求に伴うデータに保護情報が含まれるか否かを検査する上で必要となる詳細事項（ポリシー）を、例えば管理者によりポリシー設定画面を介してなされた指定に沿って事前に設定し、その設定内容を内部記憶領域１６に記憶させる。ポリシー管理部３２０により提供されるポリシー設定画面は、図５に示された情報管理システム１００におけるポリシー設定画面と同等のものである。

ルール管理部３３０は、情報管理プログラム３００が外部サーバに対する要求の中継及び管理を行う上で必要となる詳細事項（ルール）を、例えば管理者によりルール設定画面を介してなされた指定に沿って事前に設定し、その設定内容を内部記憶領域１６に記憶させる。ルールが予め設定されている場合には、情報管理プログラム３００は内部記憶領域１６に記憶された設定内容に沿って要求の中継及び管理を行う。一方、ルールが設定されていない場合には、情報管理プログラム３００はプログラム内で初期値として指定されている内容に沿って要求の中継及び管理を行う。

なお、ここでは、ルールやポリシーが設定画面を介して管理者により予め指定された内容で設定される形態を例示したが、これに限定されない。例えば、管理者により設定されたルールやポリシーを更新ファイルとして提供する形態とし、この更新ファイルを端末１１のユーザによりメールやファイルサーバ等を介して取得させるか、或いは更新ファイルをネットワーク２０経由で端末１１に自動配信し、情報管理プログラム３００の起動中に更新ファイルに設定された内容でルールやポリシーが自動的に更新されるような機能を実装してもよい。

リクエスト検出部３４０は、端末１１と他のコンピュータとの間でネットワーク２０を介してなされる通信を常時監視し、端末１１から外部サーバに対し送信される要求を検出するとこれを一時的にバッファさせる。
データ取得部３５０は、リクエスト検出部３４０によりバッファされた要求にアップロードデータが伴うか否かを確認し、アップロードデータが存在する場合にこのデータを取得し内部記憶領域１６に一時保存する。
保護情報検出部３６０は、データ取得部３５０により一時保存されたデータを対象として、このデータに含まれる保護情報を検出する。保護情報の検出は、パターン記憶部３１０に記憶されている情報とのマッチング等により実行される。保護情報検出部３６０は、検出された保護情報の種類と種類毎の検出件数を出力する。

要保護判定部３７０は、保護情報検出部３６０により出力された結果とポリシー管理部３２０に設定されているポリシーに基づいて、検査されたデータが要保護データであるか否かを判定する。
データ判定部３８０は、保護情報検出部３６０により出力された検出結果とルール管理部３３０に設定されているルールに基づいて、アップロードデータが要規制データであるか否かを判定する。
サイト判定部３９０は、ルール管理部３３０に設定されているルールに基づいて、リクエスト検出部３４０によりバッファされた要求を外部サーバに向けて送信すべきか否かを判定する。バッファされた要求に伴うアップロードデータが存在する場合、サイト判定部３９０はルールに加えデータ判定部３８０により下された判定結果を踏まえて要求の送信可否を判定する。

ログ記録部４００は、保護情報検出部３６０により出力された検出結果やデータ判定部３８０、サイト判定部３９０により下された判定結果等を、ルール管理部３３０に設定されているルールに従い内部記憶領域１６に記録する。

リクエスト処理部４１０は、サイト判定部３９０により下された判定結果に基づいて、リクエスト検出部３４０によりバッファされた要求を処理したのち、データ取得部３５０により一時保存されたデータを削除する。リクエスト処理部４１０は、転送可と判定された場合にはこの要求を外部サーバに向けて送信し、転送不可と判定された場合にはこの要求を破棄する。なお、転送可と判断された場合に送信される要求は、プロキシサーバ３１が元来有する機能３８により中継された後に外部サーバに向けて転送されることとなる。
アラート出力部４２０は、リクエスト処理部４１０により要求が破棄された場合に、端末１１のディスプレイ上に要求が破棄された（データ送信がキャンセルされた）旨のアラートメッセージを出力する。

図１３は、情報管理プログラム３００による情報管理処理の手順例を示すフローチャートである。情報管理処理は、端末１１のＯＳ起動に伴いその動作を開始し、意図的に強制終了されない限りは端末１１がシャットダウンするまで動作し続ける。なお、図１３〜１５のフローチャートに示された各処理を実行するのは情報管理プログラム３００であり、より具体的には、情報管理プログラム３００が有する各機能部３１０〜４２０であるが、情報管理プログラム３００を動作させる主体は端末１１のＣＰＵ１２である。つまり、厳密にはＣＰＵ１２がこれらのフローチャートに示された処理を各機能部に実行させることにより、情報管理プログラム３００が機能する。

以下、手順例に沿って説明する。
ステップＳ３００：ＣＰＵ１２は、リクエスト検出部３４０に外部サーバに対する要求を検知させ、これを一時的にバッファさせる。
ステップＳ３０２：ＣＰＵ１２は、サイト判定部３９０に前ステップＳ３００でバッファされた要求の送信先が無条件許可サイトでないか否かを確認させる。無条件許可サイトでない場合（Ｙｅｓ）、ＣＰＵ１２は次にステップＳ３０４を実行する。無条件許可サイトである場合（Ｎｏ）、ＣＰＵ１２は次にステップＳ３１２を実行する。
ステップＳ３０４：ＣＰＵ１２は、情報管理メイン処理を実行する。情報管理メイン処理の詳細は後述する。

ステップＳ３０６：ＣＰＵ１２は、前ステップＳ３０４で返された判定結果を確認する。（要求に伴うアップロードデータが）要規制データであると判定された場合（Ｙｅｓ）、ＣＰＵ１２は次にステップＳ３０８を実行する。要規制データでないと判定された場合（Ｎｏ）、ＣＰＵ１２は次にステップＳ３１０を実行する。
ステップＳ３０８：ＣＰＵ１２は、サイト判定部３９０にステップＳ３００でバッファされた要求の送信先が規制例外サイトであるか否かを確認させる。規制例外サイトである場合（Ｙｅｓ）、ＣＰＵ１２は次にステップＳ３１２を実行する。規制例外サイトでない場合（Ｎｏ）、ＣＰＵ１２は次にステップＳ３１４を実行する。
ステップＳ３１０：ＣＰＵ１２は、サイト判定部３９０にステップＳ３００でバッファされた要求の送信先が規制サイトでないか否かを確認させる。規制サイトでない場合（Ｙｅｓ）、ＣＰＵ１２は次にステップＳ３１２を実行する。規制サイトである場合（Ｎｏ）、ＣＰＵ１２は次にステップＳ３０８を実行する。

ステップＳ３１２：ＣＰＵ１２は、リクエスト処理部４１０にステップＳ３００でバッファされた要求を外部サーバに向けて転送させる。
ステップＳ３１４：ＣＰＵ１２は、リクエスト処理部４１０にステップＳ３００でバッファされた要求を破棄させる。
ステップＳ３１６：ＣＰＵ１２は、アラート出力部４２０に外部サーバに対する要求が破棄された旨をアラートメッセージとして端末１１のディスプレイ上に出力させる。
以上の処理を終えると、端末１１から送信されつつある１つの要求に対し実行される情報管理処理が終了する。

図１４は、情報管理プログラム３００による情報管理メイン処理の手順例を示すフローチャートである。以下、手順例に沿って説明する。

ステップＳ３５０：ＣＰＵ１２は、データ取得部３５０に外部サーバに対する要求がアップロードデータを伴うか否かを確認させる。要求がアップロードデータを伴う場合（Ｙｅｓ）、ＣＰＵ１２は次にステップＳ３５２を実行する。要求がアップロードデータを伴わない場合（Ｎｏ）、ＣＰＵ１２は次にステップＳ３６４を実行する。
ステップＳ３５２：ＣＰＵ１２は、保護情報検査処理を実行する。保護情報検査処理の詳細は後述する。

ステップＳ３５６：ＣＰＵ１２は、データ判定部３８０にルール管理部３３０に予め設定されたルールを参照させ、以降のステップで実行される処理に備える。
ステップＳ３５８：ＣＰＵ１２は、データ判定部３８０にステップＳ３５２で返された検査結果を確認させる。（要求に伴うアップロードデータが）要保護データであると判定された場合（Ｙｅｓ）、ＣＰＵ１２は次にステップＳ３６０を実行する。要保護データでないと判定された場合（Ｎｏ）、ＣＰＵ１２は次にステップＳ３６４を実行する。要保護データか否かが不明である場合（不明）、すなわちデータが検査不能ファイルである場合には、ＣＰＵ１２は次にステップＳ３６６を実行する。

ステップＳ３６０：ＣＰＵ１２は、データ判定部３８０に要保護データに対する規制の要否に関するルール設定を確認させる。要保護データを伴う要求の転送を全て許可する設定である場合（全て許可）、ＣＰＵ１２は次にステップＳ３６４を実行する。要保護データのデータサイズに応じて要求の転送を規制するか否か決定する設定である場合（一部規制）、ＣＰＵ１２は次にステップＳ３６２を実行する。要保護データを伴う要求の転送を全て規制する設定である場合（全て規制）、ＣＰＵ１２は次にステップＳ３７０を実行する。
ステップＳ３６２：ＣＰＵ１２は、データ判定部３８０に要保護データ（アップロードデータ）のデータサイズがルールで設定されたサイズ未満であるか否かを確認させる。規定サイズ未満である場合（Ｙｅｓ）、ＣＰＵ１２は次にステップＳ３６４を実行する。規定サイズ以上である場合（Ｎｏ）、ＣＰＵ１２は次にステップＳ３７０を実行する。

ステップＳ３６４：ＣＰＵ１２は、サイト判定部３９０にアップロードデータが要規制データではないと判定させる。
ステップＳ３６６：ＣＰＵ１２は、データ判定部３８０に検査不能ファイルに対する規制の要否に関するルール設定を確認させる。検査不能ファイルを伴う要求の転送を全て許可する設定である場合（全て許可）、ＣＰＵ１２は次にステップＳ３６４を実行する。検査不能ファイルのファイルサイズに応じて要求の転送を規制するか否か決定する設定である場合（一部規制）、ＣＰＵ１２は次にステップＳ３６８を実行する。検査不能ファイルを伴う要求の転送を全て規制する設定である場合（全て規制）、ＣＰＵ１２は次にステップＳ３７０を実行する。

ステップＳ３６８：ＣＰＵ１２は、データ判定部３８０に検査不能ファイル（アップロードデータ）のデータサイズがルールで設定されたサイズ以上であるか否かを確認させる。規定サイズ以上である場合（Ｙｅｓ）、ＣＰＵ１２は次にステップＳ３７０を実行する。規定サイズ未満である場合（Ｎｏ）、ＣＰＵ１２は次にステップＳ３６４を実行する。
ステップＳ３７０：ＣＰＵ１２は、サイト判定部３９０にアップロードデータが要規制データであると判定させる。

ステップＳ３７２：ＣＰＵ１２は、ログ記録部４００にステップＳ３５２で返された
検査結果とステップＳ３６４又はステップＳ３７０で下された要規制データであるか否かの判定結果とを記録させる。なお、アップロードデータが無い場合（ステップＳ３５０：Ｎｏ）は、検査対象となるデータが存在していないためこの処理をスキップしてもよい。
以上の処理を終えると、ＣＰＵ１２は、ステップＳ３６４又はステップＳ３７４で下された要規制データであるか否かの判定結果を情報管理メイン処理の呼び出し元である図１３中のステップＳ１０４に返し、情報管理処理に復帰する。

図１５は、情報管理プログラム３００による保護情報検査処理の手順例を示すフローチャートである。以下、手順例に沿って説明する。

ステップＳ４００：ＣＰＵ１２は、データ取得部３５０に要求に伴うアップロードデータを取得させる。

ステップＳ４０２：ＣＰＵ１２は、保護情報検出部３６０にステップＳ４００で取得されたデータに含まれる保護情報を検出させる。保護情報の検出は、パターン記憶部３１０に記憶されているキーワードやパターンとのマッチング等により行われる。
ステップＳ４０４：ＣＰＵ１２は、要保護判定部３７０に前ステップＳ４０２で検出された保護情報の種類毎の件数がポリシー管理部３２０に予め設定されている保護情報の種類毎の検出件数の閾値以上であるか否かを確認させる。検出件数が規定の閾値以上である場合（Ｙｅｓ）、ＣＰＵ１２は次にステップＳ４０６を実行する。検出件数が規定の閾値未満である場合（Ｎｏ）、ＣＰＵ１２は次にステップＳ４０８を実行する。

ステップＳ４０６：ＣＰＵ１２は、要保護判定部３７０に検査対象データが要保護データであると判定させる。
ステップＳ４０８：ＣＰＵ１２は、要保護判定部３７０に検査対象データが要保護データでないと判定させる。
以上の処理を終えると、ＣＰＵ１２は、以上のステップで実行された保護情報の検査結果を保護情報検査処理の呼び出し元である図１４中のステップＳ３５２に返し、情報管理メイン処理に復帰する。

図１６は、情報管理プログラム３００が外部サーバに対し送信しようとするデータを管理する際の動作例を示すシーケンス図である。先述の情報管理システム１００においてはプロキシサーバ３０が管理・中継装置として、また検査サーバ４０が検査装置としてそれぞれ機能していたのに対し、情報管理プログラム３００においては端末１１が管理・中継・検査装置として機能する。以下、動作例に沿って説明する。

ユーザが端末１１でウェブブラウザを起動して外部のウェブサイトにアクセスし、何らかの情報を入力して送信ボタンをクリックすると、このタイミングで端末１１は外部サーバに対する要求を検知し（Ｓ４１）、この要求に伴ってアップロードされるデータの有無を確認する（Ｓ４２）。今回はユーザが入力した情報が送信されつつありアップロードデータが存在するため、このデータに保護情報が含まれるか否かを検査し（Ｓ４３）、この検査結果に基づいて今回の要求に伴うアップロードデータが要規制データであるか否かを判定して（Ｓ４４）、検査結果と判定結果をログに記録する（Ｓ４５）。その上で、要求の送信先ＵＲＬに対するサイト判定を行う（Ｓ４６）。今回のアップロードデータは要規制データではあるが、要求の送信先が規制例外サイトに該当するため、端末１１は外部サーバに向けて要求を送信する（Ｓ４７）。プロキシサーバ３１がこの要求を受信し外部サーバに転送する。要求が転送されることにより、アップロードデータが外部サーバに送信される。このようにして、端末１１から送信されつつあった１つ目の要求に対する一連の処理が完了する。

しばらくして、ユーザが端末１１で上記とは異なるウェブサイトにアクセスし、何らかの情報を入力して送信ボタンをクリックすると、このタイミングで端末１１は外部サーバに対する要求を検知し（Ｓ５１）、この要求に伴ってアップロードされるデータの有無を確認する（Ｓ５２）。今回もアップロードデータが存在するため、このデータに保護情報が含まれるか否かを検査し（Ｓ５３）、この検査結果に基づいて今回の要求に伴うアップロードデータが要規制データであるか否かを判定して（Ｓ５４）、検査結果と判定結果をログに記録する（Ｓ５５）。その上で、要求の送信先ＵＲＬに対するサイト判定を行う（Ｓ５６）。今回のアップロードデータは要規制データであり、要求の送信先が規制サイトに該当するため、端末１１は要求を外部サーバには送信せずに破棄するとともに（Ｓ５７）、要求が破棄された旨、すなわちアップロードデータが外部サーバに送信されなかった旨を端末１１のディスプレイ上にアラートメッセージとして表示しユーザに通知する（Ｓ５８）。このようにして、端末１１から送信されつつあった２つ目の要求に対する一連の処理が完了する。

図１７は、情報管理システム１００及び情報管理プログラム３００による情報管理メイン処理の異なる手順例を示すフローチャートである。この手順例は、要求の送信先が規制サイトであるか否かの判定が要求に伴うデータの検査に先行して行われる点で、上述した情報管理システム１００による情報管理処理（図６）及び情報管理プログラム３００による情報管理処理（図１３）と大きく異なっている。
なお、この手順例の実行主体や各ステップに関わる機能部は、情報管理システム１００と情報管理プログラム３００のいずれにより動作させるかにより異なる。ここでは説明の便宜のため、情報管理システム１００により動作させる場合の手順例を説明する。

ステップＳ５００：ＣＰＵ３２は、リクエスト受信部１２０に端末１０から送信された外部サーバに対する要求を受信させ、これを一時的にバッファさせる。
ステップＳ５０２：ＣＰＵ３２は、サイト判定部１６０に前ステップＳ５００でバッファされた要求の送信先が無条件許可サイトでないか否かを確認させる。無条件許可サイトでない場合（Ｙｅｓ）、ＣＰＵ３２は次にステップＳ５０４を実行する。無条件許可サイトである場合（Ｎｏ）、ＣＰＵ３２は次にステップＳ５１２を実行する。
ステップＳ５０４：ＣＰＵ３２は、サイト判定部１６０にステップＳ５００でバッファされた要求の送信先が規制サイトでないか否かを確認させる。規制サイトでない場合（Ｙｅｓ）、ＣＰＵ３２は次にステップＳ５０６を実行する。規制サイトである場合（Ｎｏ）、ＣＰＵ３２は次にステップＳ５１０を実行する。

ステップＳ５０６：ＣＰＵ３２は、情報管理メイン処理を実行する。情報管理メイン処理の詳細は後述する。
ステップＳ５０８：ＣＰＵ３２は、前ステップＳ５０６で返された判定結果を確認する。（端末１０から送信された要求に伴うアップロードデータが）要規制データであると判定された場合（Ｙｅｓ）、ＣＰＵ３２は次にステップＳ５１０を実行する。要規制データでないと判定された場合（Ｎｏ）、ＣＰＵ３２は次にステップＳ５１２を実行する。
ステップＳ５１０：ＣＰＵ３２は、サイト判定部１６０にステップＳ１００でバッファされた要求の送信先が規制例外サイトであるか否かを確認させる。規制例外サイトである場合（Ｙｅｓ）、ＣＰＵ３２は次にステップＳ５１２を実行する。規制例外サイトでない場合（Ｎｏ）、ＣＰＵ３２は次にステップＳ５１４を実行する。

ステップＳ５１２：ＣＰＵ３２は、リクエスト処理部１８０にステップＳ１００でバッファされた要求を外部サーバに向けて転送させる。
ステップＳ５１４：ＣＰＵ３２は、リクエスト処理部１８０にステップＳ１００でバッファされた要求を破棄させる。
ステップＳ５１６：ＣＰＵ３２は、リクエスト処理部１８０に要求が破棄された旨を要求の送信元である端末１０へ通知させる。
以上の処理を終えると、端末１０から送信された１つの要求に対しプロキシサーバ３０（中継・管理装置）が実行する情報管理処理が終了する。

このように、この手順例においては、要求の送信先が規制サイトであるか否かの判定が情報管理メイン処理（要求に伴うデータの検査、要規制データであるか否かの判定）に先行して実行される。要求の送信先が規制サイトである場合、これが規制例外サイトでなければ要求が転送されずに破棄され、規制例外サイトであれば要求が転送され要求に伴うデータが外部サーバに送信されることとなる。規制例外サイトは、予め例外としてルールに設定されているサイトで、ある程度は信頼できるサイトとも捉えられ、要規制データと判定され得るデータが送信されたとしても情報漏洩が発生する虞は低いと考えられる。
したがって、このような手順例を採用することにより、要求に伴うデータの検査を必要最小限に抑えて処理に要するコンピュータ上のリソースを節約でき、情報管理システム１００及び情報管理プログラム３００の処理効率を向上させることが可能となる。

本発明は、上述した実施形態に制約されることなく、種々に変更して実施することが可能である。例えば、検査結果のログやルール／ポリシー設定の保存先を中継・管理装置として機能するコンピュータの内部記憶領域としたが、外部記憶媒体やネットワーク２０を介して接続可能なデータベース等に保存させてもよい。

また、情報管理メイン処理の手順例を検査不能ファイルの種類に応じて細分化させてもよい。検査不能ファイルを一緒くたに扱わず、例えば、検査不能とされた理由に応じて、例えば「パスワード付きファイルの場合」「暗号化ファイルの場合」「その他の理由による場合」の３つに分岐させ、以降の手順はそれぞれの場合に対するルール設定に応じて構成することも可能である。その他の理由に該当する条件が予め把握できている場合は、さらに分岐を増やしてもよい。

ルール設定の「サイト判定対象ＵＲＬ」では、３つの分類の対象とするサイトがＵＲＬにより指定されているが、既存のウェブフィルタリングツールと連携させ、このツールで用意されたカテゴリにより対象サイトを指定してもよい。例えば、ウェブフィルタリングツールと連携させ、このツールで定義された「差別」「ドラッグ」というカテゴリを「規制サイト」の対象として指定し、このツールにより「差別」「ドラッグ」に該当すると認識されるサイトを一括して「規制サイト」として扱うよう実装することも可能である。

また、ルール設定の「データ検査結果に基づくリクエスト転送の可否」では、データを場合分けし、それぞれの場合に対し「全て許可」「一部規制」「全て規制」の３つの選択肢の中から１つを選択させる形態としているが、さらに「ユーザの判断に委ねる」という４つ目の選択肢を加え、この選択肢が選択された場合には、データを本当に外部サーバに送信してよいか（要求の転送を本当に実行してよいか）を問う意思確認のアラートメッセージを端末のディスプレイ上に表示させ、これに対しユーザから送信される回答に沿って実行するよう処理を構成してもよい。但し、情報管理システム１００をこのように構成する場合、ユーザからの回答がプロキシサーバ３０に送信されるまで終始、要求をバッファさせなければならず、プロキシサーバ３０が各端末との通信を識別する上で必要となるセッション管理にサーバのリソースを大幅に消費する虞がある。したがって、こうした構成を採用するためには、プロキシサーバ３０のリソースに十分な余裕があることが前提となる。

１０，１１ 端末
２０，２０ｄ ネットワーク
３０，３１ プロキシサーバ
４０ 検査サーバ
５０ 辞書データベース
６０ ファイアウォール
７０ インターネット
１００ 情報管理システム
３００ 情報管理プログラム

Claims (6)

1. データベースに記憶されている保護情報を構成する要素を用いて送信要求に伴うデータに保護情報が含まれるか否かを検査し、検査結果を出力する検査手段と、
   前記検査手段により出力された前記検査結果を記録する記録手段と、
   前記検査結果に基づいて前記データが保護の必要性の度合いに応じて複数に分類されるうちの１つの分類である要保護データに該当するか否かを判定する一方、前記検査手段により前記検査結果が出力されなかった場合には前記データが前記要保護データとは異なる分類の判定不能データに該当すると判定する保護要否判定手段と、
   前記保護要否判定手段により前記データが要保護データに該当しないと判定された場合には、前記データがさらに異なる分類であり前記データに係る前記送信要求を破棄することを示す要規制データに該当しないと判定する一方、前記データが要保護データ又は判定不能データに該当すると判定された場合には、予め設定された一律の判定条件に基づいて前記データが要規制データに該当するか否かを判定する規制要否判定手段と
   を備えた情報管理システム。
2. 請求項１に記載の情報管理システムにおいて、
   前記保護要否判定手段は、
   前記データに含まれる保護情報の件数がその保護情報に対し予め設定されている閾値以上である場合には前記データが要保護データに該当すると判定し、前記閾値以下である場合には前記データを要保護データに該当しないと判定することを特徴とする情報管理システム。
3. 請求項１又は２に記載の情報管理システムにおいて、
   前記規制要否判定手段により判定される前記データが要規制データに該当するか否かの前記判定条件を予め設定するルール事前設定手段をさらに備えたことを特徴とする情報管理システム。
4. 請求項３に記載の情報管理システムにおいて、
   前記ルール事前設定手段は、
   前記判定条件としてデータサイズの閾値を設定するほかに、前記保護要否判定手段により前記データが要保護データ又は判定不能データに該当すると判定された場合に、前記データを一律に要規制データに該当すると判定するか、前記データを一律に要規制データに該当しないと判定するか、もしくはそのデータサイズに応じて前記データが要規制データに該当するか否かを判定するかを設定し、
   前記規制要否判定手段は、
   前記ルール事前設定手段により予め設定された判定条件に基づいて前記データが要規制データに該当するか否かを判定することを特徴とする情報管理システム。
5. 請求項１から４のいずれかに記載の情報管理システムにおいて、
   ユーザ端末から送信される外部サーバに対する要求を受信する受信手段をさらに備え、
   前記検査手段は、
   前記受信手段により受信された前記要求に伴いアップロードされたユーザデータに保護情報が含まれるか否かを検査することを特徴とする情報管理システム。
6. 外部サーバに対する要求を送信するコンピュータを、
   請求項１から４のいずれかに記載の情報管理システムが備える前記各手段として機能させるための情報管理プログラムであって、
   前記検査手段としての機能は、前記要求に伴い前記外部サーバに送信されつつあるデータに保護情報が含まれるか否かの検査の実行を含むことを特徴とする情報管理プログラム。

Images