(58)【調査した分野】(Int.Cl.,DB名)
クライアント端末からサーバ装置宛てに送信される情報要求メッセージ及び前記情報要求メッセージに応じて前記サーバ装置から送信される応答メッセージのペア、又は、該情報要求メッセージから、ユーザ識別データとセッション識別データとの組を抽出する抽出手段と、
前記抽出手段により抽出された前記ユーザ識別データと前記セッション識別データとの組を関連付けて格納する要求情報格納手段と、
情報要求メッセージに応じて前記サーバ装置から送信される応答メッセージに含まれる個人情報の数を個人情報種毎にそれぞれカウントするカウント手段と、
前記個人情報が含まれている前記応答メッセージに含まれるセッション識別データと関連付けられて前記要求情報格納手段に格納される前記ユーザ識別データを取得し、取得されたユーザ識別データと前記カウント手段によりカウントされた個人情報種毎の個人情報の数とを関連付けたデータを、該ユーザ識別データに関する個人情報種毎の個人情報の制限数を示すデータとして、生成する制限情報生成手段と、
を備えることを特徴とする制限情報生成装置。
前記抽出手段は、前記情報要求メッセージから、該情報要求メッセージにより要求される情報の情報所在データ、及び、該情報要求メッセージに応じて前記サーバ装置から送信される応答メッセージと該情報要求メッセージとの対応関係を示す対応関係データを更に抽出し、
前記要求情報格納手段は、前記情報所在データ及び前記対応関係データの組を関連付けて更に格納し、
前記制限情報生成手段は、前記個人情報が含まれている前記応答メッセージに含まれるセッション識別データ又は対応関係データと関連付けられて前記要求情報格納手段に格納される前記ユーザ識別データ及び前記情報所在データを取得し、取得されたユーザ識別データと取得された情報所在データと前記カウント手段によりカウントされた個人情報種毎の個人情報の数とを関連付けたデータを、該ユーザ識別データに関する個人情報種毎の個人情報の制限数を示すデータとして、生成する、
ことを特徴とする請求項3に記載の制限情報生成装置。
前記抽出手段は、前記情報要求メッセージから、該情報要求メッセージにより要求される情報の情報所在データ、及び、該情報要求メッセージに応じて前記サーバ装置から送信される応答メッセージと該情報要求メッセージとの対応関係を示す対応関係データを更に抽出し、
前記要求情報格納手段は、前記情報所在データ及び前記対応関係データの組を関連付けて更に格納し、
前記制限情報生成手段は、前記個人情報が含まれている前記応答メッセージに含まれるセッション識別データ又は対応関係データと関連付けられて前記要求情報格納手段に格納される前記ユーザ識別データ及び前記情報所在データを取得し、取得されたユーザ識別データと取得された情報所在データと前記カウント手段によりカウントされた個人情報種毎の個人情報の数とを関連付けたデータを、該ユーザ識別データに関する個人情報種毎の個人情報の制限数を示すデータとして、生成する、
ことを特徴とする請求項11に記載のプログラム。
【発明を実施するための形態】
【0016】
以下、本発明の実施の形態としてのWEBサーバ装置について説明する。なお、以下に挙げる各実施形態はそれぞれ例示であり、本発明は以下の各実施形態の構成に限定されない。例えば、本発明は、WEBシステムにのみ適用可能なものではなく、通信を介して個人情報をやりとりする様々な態様に適用可能である。
【0017】
[第1実施形態]
〔システム構成〕
図1は、第1実施形態におけるWEBサーバ装置(以降、単にWEBサーバと表記する)10を含むWEBシステムの構成例を概念的に示す図である。第1実施形態におけるWEBサーバ10は、ネットワーク3を介して複数のクライアント端末1に通信可能に接続される。ネットワーク3は、インターネット等のような公衆網、WAN(Wide Area Network)、LAN(Local Area Network)、無線通信ネットワーク等である。本実施形態において、WEBサーバ10と各クライアント端末1との間の接続形態及び通信形態は限定されない。
【0018】
WEBサーバ10は、一般的なパーソナルコンピュータ(PC)等のような汎用コンピュータで構築されてもよいし、専用コンピュータで構築されてもよい。
図1には、WEBサーバ10のハードウェア構成例が示されている。WEBサーバ10は、ハードウェア構成として、バス8等で相互に接続される、CPU(Central Processing Unit)5、メモリ6、入出力インタフェース(I/F)7等を備える。メモリ6は、RAM(Random Access Memory)、ROM(Read Only Memory)、ハードディスク、可搬型記憶媒体等を含む。入出力I/F7は、ネットワーク3を介して各クライアント端末1と通信を行う通信装置等と接続される。また、入出力I/F7は、表示装置や入力装置等のようなユーザインタフェース装置と接続されてもよい。なお、本実施形態は、WEBサーバ10のハードウェア構成を限定しない。
【0019】
クライアント端末1は、PC、携帯型PC、携帯電話等のような一般的な情報処理端末である。クライアント端末1は、WEBサーバ10にアクセスしデータを受け得る一般的な通信機能、WEBサーバ10から提供されたデータに基づく画面を表示及び操作することができる一般的なユーザインタフェース機能等を有するものであればよい。本実施形態では、WEBサーバ10とクライアント端末1との間のインタフェースとしてWEBシステムが利用される例を挙げているため、クライアント端末1は、ユーザインタフェース機能としていわゆるWEBブラウザを有し、HTTP(Hypertext Transfer Protocol)を実行する通信機能を有する。なお、本実施形態は、クライアント端末1のハードウェア構成及び機能構成を限定しない。
【0020】
クライアント端末1の中には、WEBサーバ10から大量の個人情報を不正に取得しようとするユーザ(以降、不正ユーザと表記する)により操作される端末が含まれる。本実施形態では、この不正ユーザは、少なくとも1つのクライアント端末1において、WEBアプリケーションの脆弱性を悪用してWEBサーバ10に攻撃を仕掛ける。
【0021】
WEBサーバ10は、正当なユーザが利用するクライアント端末1からの要求に応じて、所望のWEBサービスを提供しつつ、上述のような不正ユーザによる不正アクセスを検出し、不正アクセスによる個人情報の漏洩を未然に防止する。以下、WEBサーバ10の構成について具体的に説明する。
【0022】
〔装置構成〕
図2は、第1実施形態におけるWEBサーバ10の構成例を概念的に示す図である。第1実施形態におけるWEBサーバ10は、
図2に示すように、通信部11、WEBアプリケーション12、WEBページ格納部13、アクセス制御情報格納部14、情報漏洩防止部15等を有する。これら各処理部は、タスク、プロセス、関数、データ格納領域のようなソフトウェア部品(断片)であるソフトウェア構成要素としてそれぞれ実現される。よって、各処理部は、例えば、
図1に示す、CPU5がメモリ6に格納されるプログラムを実行することによりそれぞれ実現される。WEBページ格納部13及びアクセス制御情報格納部14は、メモリ6上で実現される。
【0023】
通信部11は、入出力I/F7に接続されるネットワークインタフェースカード等を制御し、HTTP等のプロトコルによりクライアント端末1とやりとりされるデータの送受信を行う。例えば、通信部11は、WEBアプリケーション12又は情報漏洩防止部15から送られるWEBページ等のデータを受け、そのデータを含むHTTPパケットをクライアント端末1へ送信する。また、通信部11は、クライアント端末1から送信されるHTTPパケットを受信すると、それに含まれるデータをWEBアプリケーション12又は情報漏洩防止部15へ送る。
【0024】
なお、本実施形態では、WEBサーバ10とクライアント端末1との間のインタフェースとしてWEBシステムが利用される例を挙げているため、HTTPで送受されるデータのみを対象に説明するが、通信部11は他の通信プロトコルも実行可能である。
【0025】
以降、説明の便宜のため、クライアント端末1から送信される、任意のWEBページを求めるHTTPパケットをHTTPリクエストと表記する。このHTTPリクエストは、一般的には、情報要求メッセージと呼ぶこともできる。また、WEBサーバ10から送信される、クライアント端末1から要求された情報を提供する一連のHTTPパケットをHTTPレスポンスと表記する。このHTTPレスポンスは、提供される情報のデータ量が大きい場合等、複数のHTTPパケットから形成される場合もある。HTTPレスポンスは、一般的には、応答メッセージと呼ぶこともできる。
【0026】
WEBアプリケーション12は、周知の一般的なWEBサーバ機能を有する。例えば、WEBアプリケーション12は、クライアント端末1からのHTTPリクエストで要求されるデータをWEBページ格納部13から抽出し、当該データを含むHTTPレスポンスを通信部11を介してクライアント端末1へ送信する。WEBページ格納部13には、複数のWEBページ及びそれを形成する各種データが格納される。WEBページ格納部13には、多種多数の個人情報が格納される。
【0027】
また、WEBアプリケーション12は、アクセス制御情報格納部14に格納される情報に基づいて、制御対象のWEBページに対してアクセス制御を行う。このアクセス制御は、周知の一般的な制御であればよいため、ここでは説明を簡略化する。アクセス制御情報格納部14には、各アカウントIDについてのアクセス権限情報がそれぞれ格納される。アクセス権限情報には、例えば、アクセスが許可されているページ、アクセスが許可されていないページ、閲覧可能な個人情報数、閲覧可能な個人情報種等が含まれる。これら情報を用いて、WEBアプリケーション12は、アクセス元が持つアクセス権限に応じて、アクセス制御対象のWEBページに関し、閲覧可否等の制御を行う。
【0028】
上述のようにアクセス制御には、アカウントIDが利用される。アカウントIDは、例えば、WEBアプリケーション12により提供されるログイン画面を介して、ユーザにより入力される。このアカウントIDは、HTTPリクエストに含められることで、クライアント端末1からWEBサーバ10へ送られる。
【0029】
更に、WEBアプリケーション12は、セッション管理を行う。このセッション管理についても周知の一般的な処理であればよいため、ここでは説明を簡略化する。例えば、WEBアプリケーション12は、アカウントIDを含むHTTPリクエストを受け、そのアカウントIDの認証に成功すると、そのアカウントIDのためのセッションIDを発行する。WEBアプリケーション12は、このセッションIDとアカウントIDとの対応関係を保持し、このセッションIDを用いてアクセス制御を行いつつクライアント端末1とWEBページのやりとりを行う。なお、このセッション管理には、Cookieが利用されてもよい。
【0030】
アカウントIDは、ログインを望むユーザを識別するためのデータであり、ユーザ識別データと呼ぶこともできる。また、セッションIDは、クライアント端末1とWEBサーバ10との間における、アカウントIDの認証の成功(ログイン)後から切断(ログオフ)までの一連の通信を特定するための識別データであり、セッション識別データと呼ぶこともできる。
【0031】
HTTPリクエストには、要求元情報、要求先情報、情報所在データ、アカウントID、セッションID等が含まれる。要求元情報には、要求元であるクライアント端末1を特定するための情報(IPアドレス等)が含まれ、要求先情報には、要求先であるWEBサーバ10を特定するための情報(IPアドレス等)が含まれ、情報所在データには、所望のWEBページ等の情報の所在を示すURL(Uniform Resource Locator)等のような情報が含まれる。また、アカウント認証時には、HTTPリクエストにアカウントIDが含まれる。更に、アカウント認証の成功後、セッションIDが、HTTPリクエストに含まれる。
【0032】
HTTPレスポンスには、対応するHTTPリクエストに含まれていた要求元情報及び要求先情報と共に、要求先情報で指定された情報が含まれる。また、アカウント認証の成功後、セッションIDが、HTTPレスポンスに含まれる。なお、HTTPリクエストには、アカウントID及びセッションIDの両方が含まれる場合もあり得る。
【0033】
情報漏洩防止部15は、通信部11とWEBアプリケーション12との間に介在する。情報漏洩防止部15は、要求情報取得部101、抽出部102、要求情報格納部105、制限情報格納部107、応答情報取得部111、個人情報解析部112、制限情報取得部113、応答処理部115、個人情報定義データベース(DB)117等を有する。情報漏洩防止部15が有するこれら各処理部についても、上記ソフトウェア構成要素としてそれぞれ実現される。
【0034】
要求情報取得部101及び抽出部102は、HTTPリクエストに関連する処理を行うため、要求処理系17と呼ぶこともできる。また、要求処理系17と要求情報格納部105と制限情報格納部107とを除く他の各処理部は、HTTPレスポンスに関連する処理を行うため、応答処理系18と呼ぶこともできる。要求情報格納部105は、要求処理系17及び応答処理系18で共用される。
【0035】
<要求処理系17>
要求情報取得部101は、通信部11で受信されたHTTPリクエストに関する情報を取得する。要求情報取得部101は、通信部11から当該HTTPリクエストに関する情報を取得してもよいし、通信部11からWEBアプリケーション12へ送られた当該HTTPリクエストに関する情報をWEBアプリケーション12から取得してもよい。また、要求情報取得部101は、HTTPリクエストを形成するパケットデータそのものを取得してもよいし、当該HTTPリクエストに関する所定の情報を取得してもよい。
【0036】
抽出部102は、要求情報取得部101で取得された情報(HTTPリクエスト)からアカウントIDとセッションIDとのペアを抽出し、抽出されたペアを要求情報格納部105に格納する。この処理は、アカウントIDとセッションIDとを含むHTTPリクエストが存在する形態において実行される。
【0037】
一方、上述したように、アカウントIDとセッションIDとが1つのHTTPリクエスト内に存在しない形態もあり得る。例えば、アカウント認証前には、HTTPリクエストにアカウントIDが含まれ、アカウント認証成功後は、HTTPリクエスト及びHTTPレスポンスにはアカウントIDが含まれずセッションIDが含まれるような形態である。
【0038】
このような形態では、抽出部102は、後述する応答情報取得部111と協働することにより、HTTPリクエスト及びHTTPレスポンスから、アカウントIDとセッションIDとの組を抽出する。具体的には、抽出部102は、要求情報取得部101で取得された情報から、アカウントID及びHTTPリクエストとHTTPレスポンスとの対応関係を示す対応関係データを抽出し、そのアカウントIDと対応関係データとを対応付けて要求情報格納部105に格納する。応答情報取得部111は、取得されたHTTPレスポンスに関する情報からセッションID及び上記対応関係データを抽出し、この対応関係データと関連付けられて要求情報格納部105に格納されるアカウントIDと、そのセッションIDとを関連付けて要求情報格納部105に格納する。
【0039】
当該対応関係データは、HTTPリクエスト及びHTTPレスポンスの双方に含まれるデータであって、要求元情報、要求先情報、リクエスト番号、情報所在データ、パラメータ等の複数の組み合わせである。なお、この対応関係データは、HTTPリクエスト及びHTTPレスポンスの双方に含まれるデータであって、HTTPレスポンスからHTTPリクエストを特定し得るデータであればよく、その具体的態様は制限されない。
【0040】
抽出部102は、HTTPリクエストから上述のように所定のデータを抽出すると、そのHTTPリクエストをそのままWEBアプリケーション12へ送る。
【0041】
要求情報格納部105は、アカウントIDとセッションIDとの組を関連付けて格納する。
図3は、要求情報格納部105の例を示す図である。要求情報格納部105は、
図3の例とは異なり、上述したように、アカウントIDとセッションIDとの組に加えて、対応関係データを格納するようにしてもよい。
【0042】
<応答処理系18>
応答情報取得部111は、上述のような要求処理系17で処理されたHTTPリクエストに対して、WEBアプリケーション12で生成されたHTTPレスポンスのデータを取得する。応答情報取得部111は、WEBアプリケーション12から当該HTTPレスポンスのデータを取得してもよいし、WEBアプリケーション12から通信部11へ送られた当該HTTPレスポンスのデータを、通信部11がネットワーク3方向へ送出する前に、通信部11から取得してもよい。
【0043】
個人情報解析部112は、応答情報取得部111により取得されたHTTPレスポンスのデータを解析することにより、当該HTTPレスポンスに含まれる個人情報の数を個人情報種毎にそれぞれカウントする。これにより、個人情報解析部112は、カウント部と表記することもできる。例えば、個人情報解析部112は、HTTPレスポンスのデータと、個人情報定義DB117に格納される個人情報種毎の正規表現パターンとをマッチングさせることにより、個人情報種毎の個人情報の数をカウントする。
【0044】
図4は、個人情報定義DB117の例を示す図である。個人情報定義DB117には、個人情報種を識別する各個人情報種IDについて、正規表現パターンがそれぞれ格納される。
図4の例によれば、クレジット番号の個人情報は、0から9までの数のいずれか1つが4つ並べられた4ケタの数字が、ハイフン(−)を挟んで4つ結合されることにより形成されていることが示される。当該個人情報のカウント処理には周知な手法が利用されればよいため、ここでは説明が簡略化されている。
【0045】
制限情報取得部113は、個人情報が含まれているHTTPレスポンスから抽出されたセッションIDと関連付けられて要求情報格納部105に格納されるアカウントIDを取得し、このアカウントIDに関する、個人情報種毎の個人情報の制限数を制限情報格納部107から抽出する。
【0046】
図5は、制限情報格納部107の例を示す図である。
図5に示されるように、制限情報格納部107は、各アカウントIDについて、個人情報種毎の個人情報の制限数をそれぞれ格納する。
図5の例によれば、「suzuki」のアカウントに関し、CREDIT_NOで示される個人情報種の制限数が5であり、INSURANCE_NOで示される個人情報種の制限数が3であり、TELEPHONE_NOで示される個人情報種の制限数が10である。同様に、「yamamoto」のアカウントに関し、CREDIT_NOで示される個人情報種の制限数が3であり、INSURANCE_NOで示される個人情報種の制限数が1であり、TELEPHONE_NOで示される個人情報種の制限数が2である。
【0047】
応答処理部115は、制限情報取得部113により取得された個人情報種毎の個人情報の制限数と、個人情報解析部112によりカウントされた個人情報種毎の個人情報の数との比較結果により、HTTPレスポンスに含まれる個人情報が要求元のクライアント端末1で受信されないように当該HTTPレスポンスに対して防御処理を適用する。例えば、カウントされた個人情報の数が制限数を超えた個人情報種が1つでも存在する場合に、応答処理部115は、当該HTTPレスポンスに対して防御処理を適用する。また、全ての個人情報種においてカウントされた個人情報の数が制限数を超えている場合に、応答処理部115は、当該HTTPレスポンスに対して防御処理を適用するようにしてもよい。この防御処理は、当該HTTPレスポンスの送信の取りやめであってもよいし、当該HTTPレスポンス内の個人情報を他のデータに置き換える処理であってもよい。
【0048】
〔動作例〕
以下、第1実施形態における情報漏洩防止部15の動作例を説明する。
【0049】
図6は、第1実施形態における情報漏洩防止部15の応答処理系18の動作例を示すフローチャートである。
図6の例では、セッションID及びアカウントIDの双方がHTTPリクエストに含まれていない形態において、応答情報取得部111がセッションIDを抽出し、そのセッションIDを要求情報格納部105に格納する処理については言及されていない。即ち、要求情報格納部105には、アカウントIDとセッションIDとの組が既に格納されていると仮定する。
【0050】
アカウントIDとセッションIDとの組の格納のために、情報漏洩防止部15は以下のように動作する。アカウントID及びセッションIDが含まれるHTTPリクエストのデータを取得すると、情報漏洩防止部15は、そのHTTPリクエストから抽出されたアカウントIDとセッションIDとの組を要求情報格納部105に格納する。一方、アカウントIDがHTTPリクエストに含まれ、セッションIDがHTTPレスポンスに含まれる場合には、情報漏洩防止部15は、HTTPリクエストとHTTPレスポンスとのペアが対応関係データに基づいて特定されることにより、HTTPリクエストから抽出されたアカウントIDとHTTPレスポンスから抽出されたセッションIDとの組を要求情報格納部105に格納する。
【0051】
ところで、WEBサーバ10において、HTTPリクエストが受信されると、WEBアプリケーション12がそれに応じたHTTPレスポンスを生成する。情報漏洩防止部15は、その生成されたHTTPレスポンスのデータを取得する(S60)。
【0052】
続いて、情報漏洩防止部15は、個人情報定義DB117に格納されるデータを用いて、HTTPレスポンスのデータを解析することにより、HTTPレスポンスに含まれる個人情報の数を個人情報種毎にそれぞれカウントする(S61)。ここで、HTTPレスポンスに個人情報が含まれていない場合には(S62;NO)、情報漏洩防止部15は、そのHTTPレスポンスをネットワーク3方向へそのまま送出する(S68)。
【0053】
情報漏洩防止部15は、HTTPレスポンスに個人情報が含まれている場合(S62;YES)、HTTPレスポンスから更にセッションIDを抽出する(S63)。続いて、情報漏洩防止部15は、抽出されたセッションIDと関連付けられて要求情報格納部105に格納されるアカウントIDを取得する(S64)。これにより、個人情報を含むWEBページを要求したアカウントIDが特定される。
【0054】
次に、情報漏洩防止部15は、制限情報格納部107から、そのアカウントIDに関する個人情報種毎の個人情報の制限数を抽出する(S65)。このとき、情報漏洩防止部15は、処理(S61)でカウントされた個人情報種のみについて制限数を取得するようにしてもよい。
【0055】
情報漏洩防止部15は、処理(S61)でカウントされた個人情報数が処理(S65)で取得された制限数を超える個人情報種が存在するか否かを判定する(S66)。全ての個人情報種の個人情報数が制限数以内であれば(S66;NO)、情報漏洩防止部15は、そのHTTPレスポンスをそのままネットワーク3方向へ送出する(S68)。一方、制限数を超える個人情報種が存在する場合には(S66;YES)、情報漏洩防止部15は、そのHTTPレスポンスに個人情報の防御処理を適用する(S67)。このとき、情報漏洩防止部15は、制限数を超えた個人情報種の個人情報に対してのみ、個人情報の防御処理を適用してもよいし、全ての個人情報種の個人情報に対して防御処理を適用してもよい。そして、情報漏洩防止部15は、防御処理が適用されたHTTPレスポンスをネットワーク3方向へ送出する(S68)。
【0056】
なお、上述の処理(S66)は、全個人情報種の個人情報数が各制限数をそれぞれ超えるか否かの判定に置き換えてもよい。この場合には、全個人情報種の個人情報数が各制限数をそれぞれ超える場合に(S66;YES)、情報漏洩防止部15は、HTTPレスポンスに個人情報の防御処理を適用する。
【0057】
〔第1実施形態における作用及び効果〕
第1実施形態では、HTTPリクエスト、又は、HTTPリクエスト及びHTTPレスポンスから抽出されるデータに基づいて、アカウントIDとセッションIDとの組が格納される。また、予め、各アカウントIDに関し、個人情報種毎の個人情報の制限数がそれぞれ格納されている。
【0058】
その上で、第1実施形態では、HTTPレスポンスのデータが取得されると、そのHTTPレスポンスに含まれる個人情報の数が個人情報種毎にそれぞれカウントされる。そして、HTTPレスポンスに含まれるセッションIDと関連付けられて格納されるアカウントIDが特定され、そのアカウントIDに関する個人情報種毎の個人情報の制限数が取得される。
【0059】
最終的に、HTTPレスポンスに含まれていた個人情報種毎の個人情報の数と、それらの制限数との比較結果により、HTTPレスポンスに含まれる個人情報が要求元のクライアント端末1で受信されないように当該HTTPレスポンスに防御処理が適用される。
【0060】
これにより、第1実施形態によれば、HTTPレスポンスに含まれていた個人情報の数が制限数を超える個人情報種が存在する場合に、そのHTTPレスポンス内の個人情報がクライアント端末1で受信されないように制御することができる。即ち、第1実施形態によれば、アカウントID毎に予め決められる制限数を超える個人情報を取得しようとする通信は、不正な通信(攻撃)と判定することができる。このような制御は、攻撃パターンが既知であるか否かに依存されず実行され得る。即ち、第1実施形態によれば、通信を介した未知の攻撃による個人情報の漏洩を未然に防止することができる。
【0061】
更に、第1実施形態によれば、例えば、一般利用者権限のアカウントIDを不正に用いて、脆弱性を突いた攻撃がシステムに加えられた場合であっても、第1実施形態によれば、一般利用者権限で許可されていない個人情報数や個人情報種が盗み取られることを未然に防止することができる。
【0062】
[第2実施形態]
第1実施形態における制限情報格納部107に格納される制限数の情報は、装置稼働前等に予め設定されてもよいし、通信により他の装置から取得されてもよい。第2実施形態におけるWEBサーバ10は、制限情報格納部107に格納される情報を自動生成する。以下、第2実施形態におけるWEBサーバ10について第1実施形態と異なる内容を中心に説明し、第1実施形態と同様の内容については適宜省略する。
【0063】
図7は、第2実施形態におけるWEBサーバ10の構成例を概念的に示す図である。第2実施形態におけるWEBサーバ10は、第1実施形態で示された各構成に加えて、制限情報処理部21を更に有する。制限情報処理部21についても、他の処理部と同様に、ソフトウェア構成要素として実現される。
【0064】
制限情報処理部21は、クライアント端末1とWEBサーバ10との間でやりとりされるHTTPリクエスト及びHTTPレスポンスの各データを用いて、制限情報格納部107に格納される情報を生成する。WEBサーバ10は、制限情報処理部21及び情報漏洩防止部15のいずれか一方を動作させるように制御してもよいし、両方を並行に動作させるように制御してもよい。通信部11は、前者の形態では、受信されたHTTPリクエストのデータを、制限情報処理部21及び情報漏洩防止部15のどちらか動作中のほうに送り、後者の形態では、両方に送る。また、前者の形態では、入出力I/F7に接続されるユーザインタフェース装置(図示せず)をユーザが操作することにより、動作中の処理部が切り替えられるようにしてもよい。
【0065】
制限情報処理部21も、情報漏洩防止部15と同様に、通信部11とWEBアプリケーション12との間に介在する。制限情報処理部21は、要求情報取得部201、抽出部202、要求情報格納部205、応答情報取得部211、個人情報解析部212、制限情報生成部213、応答処理部215、個人情報定義データベース(DB)217等を有する。制限情報処理部21が有するこれら各処理部についても、上記ソフトウェア構成要素としてそれぞれ実現される。
【0066】
制限情報処理部21における制限情報生成部213を除く他の各処理部は、情報漏洩防止部15における要求情報取得部101、抽出部102、要求情報格納部105、応答情報取得部111、個人情報解析部112、応答処理部115、個人情報定義DB117と同様の処理を行えばよいため、ここではそれらの説明を省略する。
【0067】
制限情報生成部213は、要求情報格納部205から、HTTPレスポンスに含まれるセッションIDと関連付けられて格納されているアカウントIDを抽出し、このアカウントIDと個人情報解析部212によりカウントされた個人情報種毎の個人情報の数とを関連付けたデータを、制限情報格納部107に格納されるべきデータとして生成する。なお、制限情報生成部213は、生成されたデータを制限情報格納部107に直接格納してもよい。
【0068】
〔動作例〕
以下、第2実施形態における制限情報処理部21の動作例を説明する。
【0069】
図8は、第2実施形態における制限情報処理部21の応答処理系23の動作例を示すフローチャートである。このとき、要求情報格納部205には、第1実施形態における要求情報格納部105と同様に、アカウントIDとセッションIDとの組が既に格納されていると仮定する。
【0070】
WEBサーバ10において、HTTPリクエストが受信されると、WEBアプリケーション12がそれに応じたHTTPレスポンスを生成する。制限情報処理部21は、情報漏洩防止部15と共に、その生成されたHTTPレスポンスのデータを取得する(S80)。以降、処理(S81)から処理(S84)までの各処理は、
図6に示される情報漏洩防止部15の処理(S61)から処理(S64)までの各処理と同様である。
【0071】
制限情報処理部21は、処理(S84)において要求情報格納部205から抽出されたアカウントIDと、処理(S81)においてカウントされた個人情報種毎の個人情報数とを関連付けたデータを、制限情報格納部107に格納すべきデータ(レコード)として生成する(S85)。
【0072】
その後、制限情報処理部21は、そのHTTPレスポンスをネットワーク3方向にそのまま送出する(S86)。
【0073】
〔第2実施形態における作用及び効果〕
第2実施形態では、情報漏洩防止部15において利用される、各アカウントIDに関する個人情報種毎の個人情報の制限数が、クライアント端末1とWEBサーバ10との間で実際にやりとりされるHTTPリクエスト及びHTTPレスポンスのデータを用いて自動で生成される。これにより、第2実施形態で生成されたデータを制限情報格納部107に格納すれば、制限情報格納部107へのデータの設定処理の負担を軽減することができる。
【0074】
[第3実施形態]
上述の各実施形態では、個人情報数が個人情報種毎に制限されたが、更に、情報所在データ毎に制限が設定されるようにしてもよい。第3実施形態では、個人情報数を、情報所在データ毎及び個人情報種毎に制限する新たな構成が上述の第2実施形態に組み込まれた例が示される。なお、そのような新たな構成は、第1実施形態に組み込まれてもよい。
【0075】
WEBサーバ10の装置構成は、上述の第2実施形態と同様である。但し、処理内容が上述の第2実施形態と異なる処理部が存在する。以下、第3実施形態におけるWEBサーバ10について上述の第2実施形態と異なる内容を中心に説明し、上述の第2実施形態と同様の内容についてはその説明を適宜省略する。
【0076】
抽出部102は、要求情報取得部101で取得された情報(HTTPリクエスト)から、情報所在データ、及び、そのHTTPリクエストとそれに対するHTTPレスポンスとの対応関係を示す対応関係データを抽出し、それらを対応付けて要求情報格納部205に格納する。対応関係データについては上述したとおりである。
【0077】
図9は、第3実施形態における要求情報格納部105の例を示す図である。要求情報格納部105は、上述の各実施形態における内容(アカウントIDとセッションIDとの組など)に加えて、対応関係データと情報所在データとの組を格納する。
図9の例では、情報所在データとして、URLデータが格納されている。
【0078】
図10は、第3実施形態における制限情報格納部107の例を示す図である。
図10に示されるように、制限情報格納部107には、アカウントID、情報所在データ、個人情報種ID及び制限数を含むレコードが格納されている。
図10の例によれば、「suzuki」のアカウントに関し、「/user/accountinfo」から提供されるWEBページにおいて、CREDIT_NOで示される個人情報種の制限数が5であり、「/data/info」から提供されるWEBページにおいて、CREDIT_NOで示される個人情報種の制限数が20である。
【0079】
制限情報取得部113は、個人情報が含まれるHTTPレスポンスから、セッションID及び当該対応関係データを抽出し、更に、当該対応関係データと関連付けられて格納される情報所在データ、及び、当該セッションIDと関連付けられて格納されるアカウントIDを要求情報格納部105から抽出する。制限情報取得部113は、このように取得された情報所在データ及びアカウントIDに関する、個人情報種毎の個人情報の制限数を制限情報格納部107から抽出する。
【0080】
なお、制限情報処理部21における抽出部202及び要求情報格納部205の各処理は、上述の抽出部102及び要求情報格納部105と同様である。
【0081】
制限情報生成部213は、個人情報が含まれるHTTPレスポンスから、セッションID及び当該対応関係データを抽出し、更に、当該対応関係データと関連付けられて格納される情報所在データ、及び、当該セッションIDと関連付けられて格納されるアカウントIDを要求情報格納部105から抽出する。制限情報生成部213は、このように取得された情報所在データとアカウントIDとに、カウントされた個人情報種毎の個人情報数が対応付けられたデータを生成する。
【0082】
〔動作例〕
図11は、第3実施形態における情報漏洩防止部15の動作例を示すフローチャートである。
図11では、第1実施形態及び第2実施形態の動作例を示す
図6の処理と同一内容には
図6と同一の符号が付されている。以下、第3実施形態における情報漏洩防止部15の動作を第1実施形態及び第2実施形態と異なる内容を中心に説明する。
【0083】
このとき、要求情報格納部105には、アカウントIDとセッションIDとの組、及び、HTTPリクエストで要求された情報所在データと対応関係データとの組が既に格納されている。
【0084】
情報漏洩防止部15は、HTTPレスポンスに個人情報が含まれている場合(S62;YES)、HTTPレスポンスから更にセッションID及び対応関係データを抽出する(S111)。続いて、情報漏洩防止部15は、抽出されたセッションIDと関連付けられて要求情報格納部105に格納されるアカウントIDを取得する(S64)。これにより、個人情報を含むWEBページを要求したアカウントIDが特定される。
【0085】
更に、情報漏洩防止部15は、抽出された対応関係データに関連付けられて要求情報格納部105に格納される情報所在データを取得する(S112)。これにより、個人情報を含むWEBページの所在を示す情報所在データが特定される。
【0086】
情報漏洩防止部15は、制限情報格納部107から、処理(S64)で取得されたアカウントID、及び、処理(S112)で取得された情報所在データに関する、個人情報種毎の個人情報の制限数を抽出する(S113)。以降、情報漏洩防止部15は、この抽出された制限数を用いて、第1実施形態と同様に処理を行う。
【0087】
図12は、第3実施形態における制限情報処理部21の動作例を示すフローチャートである。
図12では、第2実施形態の動作例を示す
図8の処理と同一内容には
図8と同一の符号が付されている。以下、第3実施形態における制限情報処理部21の動作を第2実施形態と異なる内容を中心に説明する。処理(S80)から処理(S82)までの各処理、処理(S121)、処理(S84)及び処理(S122)は、
図11に示される情報漏洩防止部15の処理(S60)から処理(S62)までの各処理、処理(S111)、処理(S64)及び処理(S112)と同様である。
【0088】
制限情報処理部21は、処理(S84)及び処理(S122)において要求情報格納部205から抽出されたアカウントID及び情報所在データと、処理(S81)においてカウントされた個人情報種毎の個人情報数とを関連付けたデータを、制限情報格納部107に格納すべきデータ(レコード)として生成する(S123)。その後、制限情報処理部21は、そのHTTPレスポンスをネットワーク3方向にそのまま送出する(S86)。
【0089】
〔第3実施形態における作用及び効果〕
上述のように、第3実施形態では、各アカウントIDについて、情報所在データ毎でかつ個人情報種毎の個人情報の制限数が管理され、かつ、実際に送受信されるHTTPリクエスト及びHTTPレスポンスから、セッションIDとアカウントIDとの組、及び、個人情報を含むWEPページの情報所在データが保持される。その上で、HTTPレスポンスに含まれる個人情報の数が個人情報種毎にそれぞれカウントされる。
【0090】
そして、個人情報を含むHTTPレスポンスが検知されると、セッションID及び対応関係データをキーに用いて、対応するアカウントID及び対応する情報所在データが特定され、そのアカウントID及び情報所在データに関する個人情報種毎の個人情報の制限数が取得される。結果、この制限数と、カウントされた個人情報数との比較結果に応じて、個人情報が要求元のクライアント端末1で受信されないように当該HTTPレスポンスに防御処理が適用される。
【0091】
このように、第3実施形態によれば、アカウントIDのみでなく、個人情報を含むWEBページの情報所在データ毎に、個人情報の制限数を設定することができるため、不正アクセスの検知及び個人情報の漏洩の未然防止を一層緻密に行うことができる。例えば、所定URLで通常提供されている数を超える個人情報数がHTTPレスポンスに含まれる場合には、その通信を不正アクセスであると判定することができる。
【0092】
[変形例]
上述の各実施形態では、要求情報格納部105には、HTTPリクエスト及びHTTPレスポンスの一部のデータ(アカウントID、セッションID等)が格納されたが、HTTPリクエストの全データ(セッションIDを含む)が格納されてもよい。
【0093】
また、上述の第2実施形態では、HTTPレスポンスに含まれる個人情報の数がそのまま制限数として利用される例が示されたが、カウントされた個人情報数に所定演算が施された値が制限数に設定されるようにしてもよい。この場合、個人情報種毎に所定演算が予め決められているようにしてもよい。例えば、クレジット番号については2を加算すること、電話番号については2倍することがそれぞれ予め決められており、HTTPレスポンスにクレジット番号が3件、かつ、電話番号が5件含まれていた場合には、クレジット番号の制限数が5件に設定され、電話番号の制限数が10件に設定される。
【0094】
また、上述の第2実施形態及び第3実施形態では、情報漏洩防止部15及び制限情報処理部21が、処理内容の共通する各処理部をそれぞれ備えていたが、処理内容の共通する各処理部は、情報漏洩防止部15及び制限情報処理部21で共有されるようにしてもよい。この場合、要求情報取得部101及び201のペア、抽出部102及び202のペア、要求情報格納部105及び205のペア、応答情報取得部111及び211のペア、個人情報解析部112及び212のペア、応答処理部115及び215のペア、個人情報定義DB117及び217のペアは、それぞれ1つの処理部として実現されればよい。
【0095】
また、上述の各実施形態では、WEBサーバ10に情報漏洩防止部15及び制限情報処理部21が搭載される例を示したが、情報漏洩防止部15及び制限情報処理部21は、WEBサーバ10とは別のコンピュータ上で実現されてもよい。
図13は、WEBシステムの第1変形例の構成を概念的に示す図である。
図13の例では、要求情報取得部101及び201は、クライアント端末1から送信されたHTTPリクエストをネットワーク3上から受信し、応答情報取得部111及び211は、WEBサーバ10からHTTPレスポンスを取得してもよいし、WEBサーバ10により送信されたHTTPレスポンスをネットワーク3を介して受信してもよい。このとき、応答情報取得部111は、WEBサーバ10から送信されたHTTPレスポンスが宛先となるクライアント端末1で受信されないように当該HTTPレスポンスを受信する。
【0096】
また、制限情報処理部21は、情報漏洩防止部15と異なるコンピュータとして、クライアント端末1に搭載されてもよい。
図14は、WEBシステムの第2変形例の構成を概念的に示す図である。
図14の例では、要求情報取得部201は、クライアント端末1からHTTPリクエストを取得し、応答情報取得部211は、ネットワーク3を介してHTTPレスポンスを受信する。
【0097】
なお、上述の説明で用いた複数のフローチャートでは、複数のステップ(処理)が順番に記載されているが、本実施形態で実行される処理ステップの実行順序は、その記載の順番に制限されない。本実施形態では、図示される処理ステップの順番を内容的に支障のない範囲で変更することができる。また、上述の各実施形態及び各変形例は、内容が相反しない範囲で組み合わせることができる。