クライアントからサーバに送信されるユーザ情報に対してセキュリティ対策を実行する、複数のポリシ強制部と、前記ユーザ情報に対して実行すべきセキュリティ対策を示すポリシ情報を記憶するポリシ記憶部と、各ポリシ強制部で実行可能なセキュリティ対策を示す対策配置情報を記憶する対策配置記憶部と、前記複数のポリシ強制部のうち、前記ユーザ情報に対してセキュリティ対策を実行させる少なくとも1つのポリシ強制部を、前記ポリシ情報および前記対策配置情報に基づいて選択する、ポリシ判定部と、を備え、前記少なくとも1つのポリシ強制部の各々は、前記ユーザ情報に対してセキュリティ対策を実行し、前記ポリシ判定部の選択結果に基づいて、前記少なくとも1つのポリシ強制部のうちの他のポリシ強制部、または、前記サーバに前記ユーザ情報を出力する、セキュリティポリシ強制システム。各ポリシ強制部の負荷状況を示す負荷情報を記憶する負荷状況記憶部をさらに備え、前記ポリシ判定部は、前記負荷情報に基づいて、前記ポリシ情報に応じたセキュリティ対策を実行可能なポリシ強制部のうち、前記負荷状況が最も低いポリシ強制部を選択する、請求項1に記載のセキュリティポリシ強制システム。複数のセキュリティ対策の実行順序の制約を示す順序制約情報を記憶する順序制約記憶部をさらに備え、前記ポリシ判定部は、前記順序制約情報に基づいて、前記制約に従ってセキュリティ対策が実行されるように前記少なくとも1つのポリシ強制部を選択する、請求項1または2に記載のセキュリティポリシ強制システム。前記サーバは、ハードウェアを仮想化する仮想マシンモニタを含んで構成され、前記複数のポリシ強制部のうちの少なくとも1つは、前記仮想マシンモニタによって仮想化されたハードウェアを用いて実現される、請求項1~3の何れか一項に記載のセキュリティポリシ強制システム。前記複数のポリシ強制部のうち、前記クライアントから前記ユーザ情報を受信したポリシ強制部は、前記ポリシ判定部に対して前記少なくとも1つのポリシ強制部の選択要求を送信し、前記ポリシ判定部は、前記選択要求に応じて、前記少なくとも1つのポリシ強制部の全ての選択結果を、前記ユーザ情報を受信したポリシ強制部に送信し、前記少なくとも1つのポリシ強制部のうち、前記ユーザ情報を受信したポリシ強制部以外のポリシ強制部は、前記ポリシ判定部に対してポリシ強制部の選択要求を送信することなく、前記選択結果に基づいて、前記少なくとも1つのポリシ強制部のうちの他のポリシ強制部、または、前記サーバに前記ユーザ情報を出力する、請求項1~4の何れか一項に記載のセキュリティポリシ強制システム。前記複数のポリシ強制部の間におけるネットワークの状況を示すネットワーク情報を記憶するネットワーク状況記憶部をさらに備え、前記ポリシ判定部は、前記ネットワーク状況に基づいて、前記ポリシ情報に応じたセキュリティ対策を実行可能なポリシ強制部のうち、前記ユーザ情報の転送に効率的なポリシ強制部を選択する、請求項1~5の何れか一項に記載のセキュリティポリシ強制システム。クライアントからサーバに送信されるユーザ情報に対して実行すべきセキュリティ対策を示すポリシ情報をポリシ記憶部に記憶し、複数のポリシ強制部の各々で実行可能なセキュリティ対策を示す対策配置情報を対策配置記憶部に記憶し、前記複数のポリシ強制部のうち、前記ユーザ情報に対してセキュリティ対策を実行させる少なくとも1つのポリシ強制部を、前記ポリシ情報および前記対策配置情報に基づいて選択し、前記少なくとも1つのポリシ強制部の各々は、前記ユーザ情報に対してセキュリティ対策を実行し、前記選択結果に基づいて、前記少なくとも1つのポリシ強制部のうちの他のポリシ強制部、または、前記サーバに前記ユーザ情報を出力する、セキュリティポリシ強制方法。コンピュータに、クライアントからサーバに送信されるユーザ情報に対して実行すべきセキュリティ対策を示すポリシ情報と、複数のポリシ強制部の各々で実行可能なセキュリティ対策を示す対策配置情報とに基づいて、前記複数のポリシ強制部のうち、前記ユーザ情報に対してセキュリティ対策を実行させる少なくとも1つのポリシ強制部を、前記ポリシ情報および前記対策配置情報に基づいて選択する機能を実現させるためのプログラム。しかしながら、上記のシステムは大規模な環境を想定しておらず、特定の装置に負荷がかかるため、大規模なシステムに適用できない。具体的には、特許文献1に記載のシステムや、一般的なファイアウォール、IDS/IPSでは、セキュリティ対策を行なう装置にネットワークトラフィックが集中してしまう。また、特許文献2に記載のシステムでは、セキュリティ対策を行なう装置は分散しているが、セキュリティ対策を行なう装置を呼び出す装置トラフィックを振り分ける装置にネットワークのトラフィックが集中し、セキュリティ対策処理の能力を拡張することが難しい。本発明はこのような事情に鑑みてなされたものであり、セキュリティ対策の処理負荷を分散するとともに、大規模なシステムにも適用可能に、セキュリティポリシを強制することを目的とする。本発明の一側面に係るセキュリティポリシ強制システムは、クライアントからサーバに送信されるユーザ情報に対してセキュリティ対策を実行する、複数のポリシ強制部と、ユーザ情報に対して実行すべきセキュリティ対策を示すポリシ情報を記憶するポリシ記憶部と、各ポリシ強制部で実行可能なセキュリティ対策を示す対策配置情報を記憶する対策配置記憶部と、複数のポリシ強制部のうち、ユーザ情報に対してセキュリティ対策を実行させる少なくとも1つのポリシ強制部を、ポリシ情報および対策配置情報に基づいて選択する、ポリシ判定部と、を備え、少なくとも1つのポリシ強制部の各々は、ユーザ情報に対してセキュリティ対策を実行し、ポリシ判定部の選択結果に基づいて、少なくとも1つのポリシ強制部のうちの他のポリシ強制部、または、サーバにユーザ情報を出力する、セキュリティポリシ強制システム。なお、本発明において、部とは、単に物理的手段を意味するものではなく、その部が有する機能をソフトウェアによって実現する場合も含む。また、1つの部や装置が有する機能が2つ以上の物理的手段や装置により実現されても、2つ以上の部や装置の機能が1つの物理的手段や装置により実現されても良い。本発明によれば、セキュリティ対策の処理負荷を分散するとともに、大規模なシステムにも適用可能に、セキュリティポリシを強制することが可能となる。以下、図面を参照して本発明の一実施形態について説明する。==第1の実施形態==図1は、本実施形態のセキュリティポリシ強制システムの構成を示す図である。セキュリティポリシ強制システム10は、クライアント12がサーバ14から提供されるサービスを利用する際に、セキュリティポリシに応じたセキュリティ対策を実行する情報処理システムである。なお、セキュリティポリシに応じたセキュリティ対策の実行は、セキュリティポリシの強制と呼ばれる。また、本実施形態では、セキュリティ対策のことを単に対策とも表現する。クライアント12は、ユーザが使用する情報処理装置であり、例えば、ユーザの位置情報や、ブログの記事、ドキュメントファイルやプログラムファイルなどの情報ユーザ情報を、セキュリティポリシ強制システム10を介してサーバ14へ送信する。クライアント12は、例えばSimpleObjectAccessProtocolSOAPを用いて、ポリシ強制システム10へ情報を送信することができる。クライアント12は、例えば、CPU、ネットワークインタフェースカードNICなどを備えるコンピュータであり、情報を送信するアプリケーションプログラムを実行することができる。なお、クライアント12の構成は一般的なものであるため、詳細な説明は省略する。サーバ14は、例えば、ブログサービスやレコメンデーションサービスを提供する情報処理装置であり、クライアント12から送信される情報を、セキュリティポリシ強制システム10を介して受け取り、内部に保存する。サーバ14は、図2に示すように、CPU30やメモリ32、ネットワークインタフェースカードNIC34などを備え、その上でサービスを提供するサーバOSサーバアプリケーション40が動作する。なお、サーバ14の構成は一般的であるため、詳細な説明は省略する。図1に示すように、セキュリティポリシ強制システム10は、複数のポリシ強制部20と、ポリシ判定部22とを含んで構成されている。ポリシ強制部20は、クライアント12とサーバ14との間で情報を中継し、中継する情報に対してセキュリティ対策を行なう情報処理装置である。本実施形態では、複数のポリシ強制部20の各々を区別する必要がある場合には、ポリシ強制部20-1、ポリシ強制部20-2、、ポリシ強制部20-Nのように、符号に枝番号を付けて表現する。ポリシ判定部22は、あらかじめ定められているセキュリティポリシとユーザから送信された情報とに基づいて、どのポリシ強制部20を経由してサーバ14に情報を送信すればよいかを決定する情報処理装置である。図3は、ポリシ強制部20の構成例を示す図である。ポリシ強制部20は、情報転送部50と、複数の対策実施部52とを含んで構成されている。また、ポリシ強制部20は、CPU60やメモリ62を含んでおり、例えば、メモリ62に記憶されているプログラムをCPU60が実行することにより、情報転送部50および対策実施部52を実現することができる。情報転送部50は、クライアント12、他のポリシ強制部20およびサーバ14の間で情報を転送する。情報転送部50は、クライアント12または他のポリシ強制部20の情報転送部50から情報を受信すると、実施すべきセキュリティ対策と、情報の転送先とをポリシ判定部22に問い合わせる。そして、情報転送部50は、ポリシ判定部22の指示に従って、対策実施部52を呼び出す。そして、対策実施部52での対策実施完了後に、情報転送部50は、ポリシ判定部22の指示に従って、他のポリシ強制部20またはサーバ14に情報を転送する。他のポリシ強制部20またはサーバ14への情報の転送プロトコルとしては、例えばSOAPを用いることができる。なお、SOAPは一例であり、情報が伝送できれば他のプロトコルでもよい。また、情報転送部50が対策実施部52を呼び出すプロトコルとしては、例えばプロセス間通信を用いることができる。また、情報転送部50は、例えば、宛先IPアドレスの書き換えを用いて、TCP/IPの層で情報の転送や対策実施部52の呼び出しを行ってもよい。同様に、イーサネット登録商標レイヤーで情報の転送や対策実施部52の呼び出しが行われることとしてもよい。情報転送部50間での情報のやりとりは、例えば、図4に示すフォーマットで行なわれる。ユーザIDはユーザを一意に識別できる識別子であり、サービスIDはサービスを一意に識別できる識別子である。また、情報は、クライアントから送信された情報であり、例えば、位置情報やブログの記事である。また、実施済みの対策の項目には、ユーザから送信された情報に対して実施された対策が設定される。また、情報転送部50が対策実施部52を呼び出す際には、例えば図5に示すフォーマットが用いられる。ユーザID、サービスID、情報は、図4と同様である。対策パラメータとは、対策を実行するために必要となるパラメータであり、例えば、対策実施部52が暗号化を行なう場合であれば暗号鍵が設定され、匿名化を行なう場合であればK匿名性やL多様性などの匿名化の指標が設定される。対策実施部52は、情報転送部50から情報を受け取り、受け取った情報に対してあらかじめ規定されたセキュリティ対策処理を行い、処理済みの情報を情報転送部50へ返す。本実施形態では、複数の対策実施部52の各々を区別する必要がある場合には、対策実施部52-1、対策実施部52-2、、対策実施部52-Mのように、符号に枝番号を付けて表現する。なお、各対策実施部52は、異なった対策処理を行う。例えば、ポリシ強制部20-1は暗号化とアンチウィルス、ポリシ強制部20-2は匿名化とログ記録のように、それぞれのポリシ強制部20に配置された対策実施部52によって、ポリシ強制部20で実施可能な対策が異なる。また、対策実施部52は、組み込まれたセキュリティ対策処理を識別可能に構成されている。例えば、対策実施部52は、組み込まれたセキュリティ対策処理と同じ名前を持つように構成することができる。例えば、暗号化を行なう対策実施部52は、暗号化という名前を持ち、この名前はセキュリティポリシに記述されている対策と同じである。よって、情報転送部50は、ポリシ判定部22からの通知を参照すると、どの対策実施部52を呼び出せばよいか、一意に特定することができる。なお、ポリシの対策と対策実施部52に割り当てられる名前を異なるようにしたい場合は、ポリシ判定部22がポリシの対策の記述を対策実施部52の名前に変換するデータベースを持つこととすればよい。この場合、ポリシに記述された対策の名前が該データベースに基づいて変換されることにより、対策を実施する対策実施部52を特定することができる。また、対策実施部52が対策を行い、情報転送部50へ情報を返す際には、例えば図6に示すフォーマットが用いられる。ユーザID、サービスID、情報、実施済みの対策は、図4及び図5と同様である。対策結果の項目には、対策実施部52がセキュリティ対策を行なうことができたか否かを記録する。正常に対策を実施できた場合は例えば成功が設定され、何らかの理由で失敗した場合には例えば失敗が設定される。ポリシ判定部22は、ユーザごとに行なうべきセキュリティ対策を示したセキュリティポリシポリシ情報が記録されたポリシDBポリシ記憶部を持ち、セキュリティポリシに応じて実施するセキュリティ対策と情報の転送先とを判定する。ポリシ判定部22が保持するポリシDBの一例を図7に示す。ポリシDBは、ユーザID、サービスID、必要な対策リストを含んで構成される。図7では、例として、ユーザAがリコメンドサービスを使用するときには、匿名化と仮ID化が必要であり、ユーザAがブログサービスを使用するときには、アンチウィルスが必要であることが示されている。また、ユーザBがブログサービスを使用するときには、アンチウィルスとログ記録が必要であることが示されている。図7の例では、サービスIDは、リコメンドサービスなどの簡単な文字列を用いたが、サービスを一意に識別できればよく、例えば、URLをサービスIDとして用いてもよい。また、ポリシDBには、対策のためのパラメータが含まれることとしてもよい。例えば、必要な対策リストに暗号化が含まれる場合であれば、必要な対策リストの中に、暗号化の指定とともに暗号化のための鍵が設定されてもよい。なお、ポリシDBは、例えば、リレーショナルデータベースを用いてもよいし、データ量が小規模であるなら、プログラム中の配列として実装してもよい。加えて、ポリシ判定部22は、情報の転送先を決定するための情報として、各ポリシ強制部20がどのような対策実施部52を保持しているかを示す対策配置情報が記録された対策配置DB対策配置記憶部を持つ。ポリシ判定部22が保持する対策配置DBの一例を図8に示す。対策配置DBは、ポリシ強制部20のID識別子とそのポリシ強制部20に配置されている対策実施部52のリスト対策リストとを含んで構成される。図8の例では、例えば、IDが1番のポリシ強制部20-1には匿名化を行なう対策実施部52が配置されていることが示されている。また、例えば、IDが2番のポリシ強制部20-2には、ログ記録を行なう対策実施52-1と、アンチウィルスを行なう対策実施部52-2とが配置されていることが示されている。なお、対策配置DBも、ポリシDBと同様に、例えば、リレーショナルデータベースやプログラム中の配列として実装することができる。さらに、ポリシ判定部22は、各ポリシ強制部20の負荷状況を示す負荷情報が記録された、負荷状況DB負荷状況記憶部を内部に持つ。ポリシ判定部22が保持する負荷状況DBの一例を図9に示す。負荷状況DBは、ポリシ強制部20のIDと負荷とを含んで構成される。図9の例では、1番のIDを持つポリシ強制部20-1は、負荷が80であることが示されている。負荷状況DBも、ポリシDBや対策配置DBと同様に、例えば、リレーショナルデータベースやプログラム中の配列として実装することができる。ポリシ判定部22は、ポリシ強制部20の情報転送部50から問い合わせを受けると、問い合わせ元のポリシ強制部20で実施すべき対策とその対策のパラメータに加えて、次にどのポリシ強制部20へ情報を転送すべきかをを、問い合わせ元のポリシ強制部50に対して通知する。なお、実施すべき対策と情報の転送先を決定するアルゴリズムについては後述する。ポリシ強制部20の情報転送部50からポリシ判定部22への問い合わせは、例えば図10のフォーマットを用いることができる。ユーザID、サービスID、実施済み対策は、図4、5と同様であるため説明を省略する。また、ポリシ判定部22からポリシ強制部20の情報転送部50への返答は、例えば図11のフォーマットを用いることが出来る。対策と対策のパラメータは、例えば暗号化とその鍵である。また、情報の転送先には、ポリシ強制部20やサービスサーバ14を識別するためのIDが設定される。セキュリティポリシ強制システム10の動作について説明する。前述したように、セキュリティポリシ強制システム10は複数のポリシ強制部20を備えており、クライアント12から送信された情報は、複数のポリシ強制部20を経由して最終的にサーバ14に到達する。そして、個々のポリシ強制部20を通過する際に、情報に対してセキュリティ対策が実施される。図12のシーケンス図を参照してセキュリティポリシ強制システム10の動作の一例について詳細に説明する。まず、ユーザが使用するクライアント12が、ポリシ強制部20-1の情報転送部50に情報を送信するS01。ここで、送信される情報には、ユーザがサーバ14に送信したい情報位置情報やブログ記事などの他に、ユーザID、利用したいサービスの識別子サービスIDが含まれる。情報転送部50は、情報を受け取ると、実施すべき対策と、次に情報を転送すべき宛先をポリシ判定部22に問い合わせるS02。図10に示したように、問い合わせには、ポリシ強制部ID、ユーザID、サービスIDが含まれている。また、実施済の対策の情報も、問い合わせに付加される。この例の場合、まだ対策は行なわれていないため、実施済の対策は、無しである。ポリシ判定部22は、ユーザID、サービスIDに基づいてポリシDBからポリシを検索し、必要な対策を判定するS03。そして、ポリシ判定部22は、対策配置DBを用いて、必要な対策実施部52が配置されているポリシ強制部20を特定する。最後に、ポリシ判定部22は、例えば図11のフォーマットを用いて、実施する対策とそのパラメータ、情報の転送先のポリシ強制部20のIDもしくはサービスIDを、ポリシ強制部20-1へ通知する。なお、ポリシ判定の詳細な動作については後述する。情報転送部50は、ポリシ判定部22から、実施すべき対策と、情報の転送先を受信すると、指示された対策について、順番に対策実施部52を呼び出して、対策実施部52に情報に対する対策処理を実行させるS04~S07。例えば、対策実施部52-1、52-Mを呼び出すことをポリシ判定部22から指示された場合、情報転送部50は、まず対策実施部52-1を呼び出し、情報と対策を行なうためのパラメータを渡すS04。前述したように、情報転送部50が対策実施部52を呼び出すときには、図5のフォーマットを用いることができる。そして、対策実施部52-1は、情報を受け取り、あらかじめ決められた対策アルゴリズムを対策のパラメータを用いて実行することにより情報に対してセキュリティ対策処理を実行し、処理済みの情報を情報転送部50へ返すS05。図6に示したように、対策実施部52は、処理済みの情報に加えて、対策の処理が成功したか否かを示す情報も、呼び出し元の情報転送部50へ通知する。もし、ステップS05において、何らかの理由でセキュリティ対策の処理に失敗した場合図6の対策結果の項目が失敗だった場合は、ポリシ強制部20は、クライアント12にエラーを通知し、処理を終了する。ステップS05において対策の処理が成功している場合は、ステップS04と同様に、情報転送部50は、対策実施部52-Mを呼び出すS06。そして、対策実施部52-Mは情報に対策を施し、情報転送部50へ情報を返すS07。情報転送部50は、ポリシ判定部22から指定されたポリシ強制部20正確には、その情報転送部50へ情報を転送するS08。もし、ポリシ強制部20ではなく、サーバ14が指定されていた場合、情報転送部50はサーバ14へ情報を送信する。情報を受け取った次のポリシ強制部20-Nも、前のポリシ強制部20-1と同様に、ポリシ判定部22に必要な対策と転送先を問い合わせ、対策実施部52を呼び出すことで対策を行い、最後に情報の転送を行なうS09、S10。図12の例では、ポリシ強制部20-Nは、ポリシ判定部22からサーバ14へ情報を転送するように指示を受け、サーバ14に情報を転送している。最後に、サーバ14は、ポリシ強制部20-Nから情報を受け取り、該情報を内部に保存するS11。次に、ポリシ判定部22における、ポリシ判定の動作の詳細を説明する。図13は、ポリシ判定動作の一例を示すフローチャートである。まず、ポリシ判定部22は、ユーザIDおよびサービスIDに基づいてポリシDBを検索し、必要な対策のリストを取得するS1301。続いて、ポリシ判定部22は、問い合わせ元を示すポリシ強制部IDを用いて、対策配置DBを検索し、問い合わせ元のポリシ強制部20にどのような対策実施部52が配置されているかを特定する。そして、ポリシ判定部22は、ポリシの必要な対策リストに含まれており、かつ、問い合わせ元のポリシ強制部20に配置されている対策を、問い合わせ元のポリシ強制部20で実施すべき対策として決定するS1302。このとき、ポリシ判定部22は、問い合わせのフォーマット図4の実施済の対策の項目を参照し、実施すべき対策から既に実施済の対策を除外する。次に、ポリシ判定部22は、情報の転送先次のポリシ強制部20かサーバ14の決定を行なうS1303~S1305。個々のステップについて、詳細に説明する。ポリシ判定部22は、ポリシの対策リストのうち、まだ情報に対して実施されておらず、かつ、上記の問い合わせ元のポリシ強制部20で実施すべきではない対策の中から、次に行うべき対策を一つ選ぶS1303。対策の選び方は、ポリシに書かれている順番でもよいし、ランダムでもよい。このとき、対策を選択できない場合、すなわち、問い合わせ元のポリシ強制部20で対策が行なわれることにより、ポリシで指定されているすべての対策の実施が完了する場合、サーバ14を情報の転送先として処理を終了する。ポリシ判定部22は、ステップS1303で選択された対策が配置されているポリシ強制部20を、対策配置DBから検索するステップS1304。ステップS1303で選択された対策が1つのポリシ強制部52にしか配置されていない場合は、ポリシ判定部22は、そのポリシ強制部52を転送先として決定する。また、ステップS1303で選択された対策が複数のポリシ強制部52に配置されている場合は、ポリシ判定部22は、負荷状況DBを参照して、一番負荷が低いポリシ強制部52を次に情報を転送すべきポリシ強制部52として決定するS1305。このように、本実施形態のセキュリティポリシ強制システム10は、セキュリティポリシを分散して強制するように構成されているため、大規模なシステムにも適用することが可能である。なお、上記の説明では、サーバ14は1台であったが、サーバ14が複数台設けられていてもよい。この場合、対策配置DBには、対策実施部52の配置状況だけではなく、どのサーバ14にどのサービスが配置されているかを示す情報が管理される。また、負荷状況DBにも同様に、サーバの負荷を示す情報が管理される。そして、ポリシ判定部22は、サーバ14を選択する際に、サービスが配置されているサーバ14のうち、最も負荷が低いサーバ14を選択し、情報の転送先として情報転送部50へ通知する。これにより、セキュリティポリシ強制の負荷分散だけではなく、サーバの負荷分散も行なうことが可能となる。また、上記の説明では、ポリシの必要な対策リストに含まれており、かつ、問い合わせ元のポリシ強制部20に配置されている対策を、問い合わせ元のポリシ強制部20で実施すべき対策として決定した。すなわち、ポリシ判定部22は、複数の対策の実施を一度に指示したが、複数の対策実施を指示せず、1つの対策の実施のみ指示してもよい。同じポリシ強制部20で、続けて他の対策の処理を行う場合、ポリシ判定部22は、転送先に同じポリシ強制部20を指定し、ポリシ強制部20は転送先が自分自身の場合には、対策のみを行い、情報の転送を行わなければよい。なお、1つの対策の実施のみというのは、一例であり、2つや3つの対策を指示してもよい。例えば、複数の対策の実施には時間が掛かるため、その間にポリシ強制部20の負荷の状況が変化し、コンピュータリソースを効率よく使えない可能性が考えられる。1つの対策の実施は複数の対策の実施よりも実施時間が短いため、ポリシ判定部22への次の問い合わせまでの時間が短くなる。よって、ポリシ強制部20の負荷の変動により柔軟に対応できる効果がある。本動作は、ポリシ強制部20からポリシ判定部22へのポリシ判定要求の回数やポリシ強制部20間のデータ転送回数が多くなるデメリットがあるが、高速なネットワークの環境では、そのデメリットを無視できる。また、上記の説明では、ポリシ強制部20は、自身が実施する対策と転送先を一度に問い合わせていたが、分割して問い合わせてもよい。具体的には、ポリシ強制部20は、情報を受け取ったときに、実施する対策をポリシ判定部22に問い合わせて、対策を実施する。そして、対策実施後に、情報の転送先をポリシ判定部22に問い合わせ、ポリシ判定部22の指示に応じて情報を転送する。この動作では、情報を転送する直前に転送先を問い合わせるため、最新の負荷状況に応じて転送先を決定できる効果がある。==第2の実施形態==セキュリティ対策の実施順序を考慮した、第2の実施形態について説明する。セキュリティ対策には、対策を実施する順序に制約がある場合がある。例えば、暗号化とアンチウィルスを考えると、アンチウィルスは情報にウィルスのパターンが含まれているかを確認するため、暗号化してある情報に対して行なうことが出来ない。よって、アンチウィルスは、暗号化よりも先に実施されなければならない。したがって、図13に示したポリシ判定部22の動作では、対策を実施する順番を指定できないため、順番によっては対策を実施できない可能性がある。そこで、ポリシ判定部22は、対策の実行順序の制約を示す順序制約情報が記録された順序制約DB順序制約記憶部を内部に持つこととしてもよい。具体的には、ポリシ強制部20に配置されているすべての対策について優先順序を規定し、ポリシ判定部22は、図13の処理におけるステップS1302、S1303において、この優先順序に従って対策を選択すればよい。例えば、ログ記録、アンチウィルス、暗号化という対策がポリシ強制部20に配置されているとする。ここで、次の2つの要件1、2があるとする。1ログには、アンチウィルスによってウィルスが削除される前の情報を記録したい。2暗号化されているとアンチウィルスの処理を行うことができない。この場合、ポリシ判定部22は、ログ記録→アンチウィルス→暗号化という優先順序を内部に保持すればよい。そして、情報を転送するポリシ強制部20が優先順序に基づいて決定されるように、図13におけるステップS1302~S1305の処理が、例えば、図14に示す処理に変更される。ポリシ判定部22は、問い合わせ元のポリシ強制部20で実施可能な対策のうち、優先順序が一番高い対策を、問い合わせ元のポリシ強制部20で実施する対策のリストに追加するS1401。次に、ポリシ判定部22は、情報に対してまだ実施されておらず、かつ、上記リストに載っていない対策のうち、優先順序が一番高い対策を選択するS1402。そして、ポリシ判定部22は、対策配置DBを参照し、選択された対策が問い合わせ元のポリシ強制部20で実施可能か否かを判定するS1403。選択された対策が問い合わせ元のポリシ強制部20で実施可能である場合S1403:YES、ポリシ判定部22は、選択された対策を問い合わせ元のポリシ強制部20で実施すべき対策のリストに追加しS1404、ステップS1402へ戻る。選択された対策が問い合わせ元のポリシ強制部20で実施可能ではない場合S1403:NO、ポリシ判定部22は、問い合わせ元のポリシ強制部20で実施すべき対策のリストの作成を完了する。そして、ポリシ判定部22は、選択された対策が実施可能なポリシ強制部20のうち、一番負荷が低いポリシ強制部20を情報の転送先に決定するS1405。このように、対策に優先順位を設けることにより、依存関係がある対策を確実に実施することが可能となる。==第3の実施形態==セキュリティ対策の実施順序を考慮した、第3の実施形態について説明する。第2の実施形態では、すべての対策の優先順位が記憶されていたが、対策の数が多くなると、優先順位を指定することが難しい場合がある。そこで、ポリシ判定22は、図15に示すような、部分的な順序制約を示す順序制約情報が記録された順序制約DBを備えてもよい。順序制約DBには、対策Aは対策Bよりも先に実行されなければならない図中ではA→Bのように示しているのような対策の順序の制約を示す情報が記録される。図15の例では、ログ記録は仮ID化の処理よりも先に実施されなければならないことや、アンチウィルスは暗号化よりも先に実施されなければならないことが示されている。本実施形態では、ポリシ判定部22は、順序制約を満たすように対策の順番を並べ替え、次に行うべき対策を選択する。具体的には、ポリシ判定部22は、対策の順序制約を有向グラフとみなして各順序制約を表す有向グラフのマージを行ない、対策の依存関係を示した有向グラフを作成する。そして、ポリシ判定部22は、依存関係を示した有向グラフによって示される上位の対策から選択していく。グラフのマージは、図16に示すように、共通した対策を1つにまとめることにより行うことができる。例えば、対策B→対策Cと対策A→対策Cというグラフがある場合、図16aに示すようにマージすることが出来る。また、対策A→対策Bと対策A→対策Cというグラフがある場合、図16bに示すようにマージすることが出来る。さらに、また、対策B→対策Aと対策C→対策Aというグラフがある場合、図16cに示すようにマージすることが出来る。そして、ポリシ判定部22は、マージした有向グラフの上位から対策を選択し、ポリシの必要な対策リストを並べかえる。選択の順序は、例えばトポロジカルソートを用いて決定すれば良い。トポロジカルソートは、一般的な技術であるため詳細な説明は省略する。グラフが1つにマージできない場合、例えば、対策A→対策B→対策Cと対策D→対策E→対策Fという2つのグラフにマージされた場合、それぞれのグラフに同じ対策は出現せず依存関係は無いため、グラフごとに対策の順序が決定されることとすればよい。このように決定された対策の順序に従って、上述のように、対策が実施されることとなる。なお、有向グラフに閉路がある場合、例えば、A→B→C→Aのような場合は、依存関係がループしており、どのような順番で対策を実施したとしても、制約を満たすことは出来ない。よって、この場合、ポリシ判定部22は、管理者もしくはクライアント12対してエラーを通知する。このような構成では、プラットフォーム管理者がすべての対策の依存関係を記述しなくても良いため、管理を簡略化することができる。また、上記の対策の依存関係のグラフが2つ以上になる場合において、各グラフで次に実施可能な対策のうち、いずれかの対策が配置されているポリシ強制部20を抽出するように構成することができる。そして、それらのポリシ強制部20のうち、最も負荷が低いポリシ強制部20に情報を転送するように指示してもよい。例えば、対策A→対策B→対策Cと対策D→対策E→対策Fという2つのグラフがあり、対策Aと対策Dが実施済み、もしくは問い合わせ元のポリシ強制部20で実施されるとすると、次のポリシ強制部20で実施可能なのは、対策Bと対策Eである。このとき、例えば、対策Bが配置されているポリシ強制部20が2つあり、それぞれ50と60の負荷であり、対策Eが配置されているポリシ強制部20が2つあり、それぞれ10と90の負荷であったとする。このとき、ポリシ判定部22は、負荷が一番低い10のポリシ強制部20への転送を指示する。また、依存関係のグラフが1つであっても複数の実施可能な対策がある場合、例えば、図16cのグラフの対策Bと対策Cのような場合も、上記と同じ手順で、それらの対策のいずれかを実施可能なポリシ強制部20のうち、最も負荷が低いポリシ強制部20を、情報の転送先に選んでもよい。また、第1の実施形態のように順序制約がない場合も、同様の手順で情報の転送先を選んでもよい。このような動作により、情報は一番負荷の低いポリシ強制部20に転送されるため、効率的にコンピュータリソースを利用することができる。==第4の実施形態==ポリシ判定部22への問い合わせ回数を考慮した、第4の実施形態について説明する。上述の実施形態では、各ポリシ強制部20がポリシ判定部22に問い合わせを行なっていた。したがって、ユーザ数の増加に伴って情報の送信回数が増加した場合や、多くのポリシ強制部20を用いる場合に、ポリシ判定部22への問い合わせ回数が増加し、この点がボトルネックになる可能性がある。そこで、ポリシ判定部22への問い合わせの増加を防ぐために、ポリシ判定部22は、最初のポリシ強制部20の問い合わせに対して、最初のポリシ強制部20への通知だけではなく、その後のポリシ強制部20に対する通知をまとめて行うこととしてもよい。これにより、問い合わせの回数を減らすことが出来る。動作を具体的に説明する。ポリシ判定部22は、図13に示したステップS1303~S1305を繰り返し、すべての対策について、どのポリシ強制部20で行なうかを決定する。そして、ポリシ強制部20の順番と、それぞれのポリシ強制部20で行う対策を、最初のポリシ強制部20へまとめて通知する。図17は、まとめて通知する場合のフォーマットの例を示している。図17の例では、情報はIDが2のポリシ強制部20-2で匿名化が行なわれ、IDが3のポリシ強制部20-3でアンチウィルス処理が行われることが示されている。各々のポリシ強制部20は、まとめた通知を、情報と共に、次のポリシ強制部20へ転送する。ポリシ強制部20は、ポリシ判定部22に問い合わせるのではなく、前のポリシ強制部20から受け取った通知を基に、指定された対策を呼び出し、次のポリシ強制部20もしくはサーバ14に情報を転送する。例えば、最初にポリシ強制部20-1がクライアント12から情報を受け取り、ポリシ判定部22から図17に示す通知がなされた場合、ポリシ強制部20-1は自分のIDのフィールドを参照して対策の項目を参照する。この例の場合、対策は無しであるので、ポリシ強制部20-1は、次のポリシ強制部20、すなわち、2番のIDを持つポリシ強制部20-2へ情報を転送する。ポリシ強制部20-2は、自分のIDのフィールドを参照して対策の項目を参照し、対策を実施する。この例の場合は、暗号化が実施される。次に、ポリシ強制部20-2は、次のポリシ強制部20、この例では3番のIDを持つポリシ強制部20-3へ、情報を転送する。ポリシ強制部20-3は、自身のIDの対策の項を参照して、アンチウィルスの処理を行う。図17に示す通知内容はこれが最後であるため、ポリシ強制部20-3は、サーバ14へ情報を転送する。このように、まとめて通知を行なうことにより、ポリシ判定部22への問い合わせ回数を減らすことが可能となる。なお、最初のポリシ強制部20に各ポリシ強制部20で行なう対策をまとめて通知するのではなく、各ポリシ強制部20が、ポリシ判定部22の通知を一定期間キャッシュすることにより、問い合わせ回数を削減してもよい。また、上記の説明では、対策のためのパラメータは、ポリシ強制部20から問い合わせがあるたびに、ポリシ判定部22から情報転送部50を介して対策実施部52へ渡されていた。パラメータのサイズが小さい場合は問題ないが、パラメータのサイズが大きいとネットワーク帯域を消費し、性能低下が生じる可能性がある。そのため、対策のパラメータを各対策実施部52へ事前に通知し、ポリシ判定部22がポリシ強制部20からの問い合わせに応答する際には、対策のパラメータの通知を省略することとしてもよい。==第5の実施形態==対策実施部52の動的な配置を考慮した、第5の実施形態について説明する。上述の実施形態では、対策実施部52はあらかじめポリシ強制部20に配置されているものとして説明したが、負荷状況に応じて、動的に対策実施部52の配置や削除を行ってもよい。その場合には、対策配置DBを更新すればよい。例えば、負荷の低いポリシ強制部20-4に対策aを実行する対策実施部52を配置した場合、図8に示した対策配置DBに4、対策aという行が追加される。そして、対策aがポリシによって実施される場合には、IDが4のポリシ強制部20-4へ情報が転送され、対策aが実施される。このように、負荷の低いポリシ強制部20に対策実施部52を配置することによって、負荷を分散することが可能となる。なお、負荷分散をするために対策実施部52を新たに配置する例を説明したが、ポリシ強制部20が実施可能な対策を増やすために、対策実施部52を配置してもよい。また、対策実施部52の配置を行う際に、ネットワークの状況を考慮して配置先を決定してもよい。具体的には、ポリシ判定部22は、各ポリシ強制部20間で情報を転送するための時間を示した転送時間データベース転送時間DBを持つ。そして、ポリシ判定部22は、ある対策Aをどのポリシ強制部20に配置すれば転送時間が最短になるかを計算する。例えば、ユーザがポリシ強制部20-1に情報を送信すると仮定する。そして、例えば、ポリシ強制部20-1からポリシ強制部20-2への情報転送時間が1秒、ポリシ強制部20-2からサーバ14への情報転送時間が1秒、ポリシ強制部20-1からポリシ強制部20-3への情報転送時間が2秒、ポリシ強制部20-3からサーバ14への情報転送時間が2秒であるとする。対策Aを行なう対策実施部52をポリシ強制部20-2に配置すると、1秒1秒で計2秒、ポリシ強制部20-3に配置すると、2秒2秒で計4秒かかる。よって、ポリシ判定部22は、対策実施部52をポリシ強制部20-2に配置すれば良いと判断する。なお、上記の説明では、ネットワークの状況を示す情報として、ポリシ強制部20の間における情報の転送時間を用いることとしたが、ネットワークの状況を示す情報はこれに限られない。例えば、ネットワークの速度や帯域の使用率等の情報をネットワークの状況を示す情報として用いることとしてもよい。また、ネットワークの状況と、ポリシ強制部20の負荷の両方を考慮して、対策実施部52の配置先を決めてもよい。具体的には、上記の情報の転送時間に、配置しようとしている対策実施部52がポリシ強制部20において情報を処理する時間を加え、合計時間が最短となるポリシ強制部20に対策実施部52を配置すればよい。例えば、負荷が0のときに1秒かかる対策を配置することを考える。上記の例で、ポリシ強制部20-2が負荷80、ポリシ強制部20-3が負荷50であるとすると、それぞれ、5秒と2秒の対策の処理時間を要する。よって、経路の転送時間と合計すると、ポリシ強制部20-2に配置した場合は、1秒1秒5秒の計7秒であり、ポリシ強制部20-3に配置した場合は、2秒2秒2秒の計6秒である。よって、ポリシ判定部22は、ポリシ強制部20-3に対策実施部52を配置すれば良いと判断する。なお、ユーザが複数の場合や、サーバが複数ある場合は、すべての組み合わせについて時間を計算し、合計時間が最短となるポリシ強制部20に対策処理部52を配置すればよい。また、上記とは逆に、対策実施部52を削除したい場合は、合計時間が大きい経路に配置されている対策実施部52を削除すればよい。==第6の実施形態==仮想マシンを考慮した第6の実施形態について説明する。なお、第1の実施形態と同様の部分については、説明を省略する。図18は、本実施形態のセキュリティポリシ強制システムの構成を示す図である。図18に示すように、第1の実施形態と異なる点は、第1の実施形態のサーバ14は、サービスを提供するサーバOSサーバアプリケーション40しか備えていないのに対し、本実施形態のサーバ110は、仮想マシンモニタVMM120、仮想ポリシ強制部122、サーバOSサーバアプリケーション124を備えることである。VMM120は、CPU130やメモリ132等のハードウェアを仮想化し、その上で複数のOSを動かすことが出来るプログラムである。VMM120は、一般的な技術であるため、詳細な説明は省略する。VMM120としては、例えばVMWare登録商標やXen登録商標などを用いることが出来る。仮想ポリシ強制部122は、第1の実施形態のポリシ強制部20と同様に、セキュリティ対策の実施を行なう。第1の実施形態のポリシ強制部20は物理的に独立したコンピュータにより構成されていたが、本実施形態の仮想ポリシ強制部122は、VMM120によって仮想化されたコンピュータ上で動作する点が異なっている。また、サーバOSサーバアプリケーション124は、第1の実施形態のサーバ14と同様にサービスを提供する。第1の実施形態と異なっている点は、サーバOSサーバアプリケーション124が、VMM120によって仮想化されたコンピュータ上で動作することである。次に、本実施形態の全体の動作を説明する。基本的には、第1の実施形態と同様である。クライアント12は、サーバ110-1によって提供される仮想ポリシ強制部122に情報を送信する。仮想ポリシ強制部122は、第1の実施形態と同様に、実施する対策と転送先をポリシ判定部22に問い合わせ、対策を実施した後、サーバOSサーバアプリケーション124へ情報を送信する。最後に、サーバOSサーバアプリケーション124は、情報を内部に保存する。本実施形態では、仮想ポリシ強制部122とサーバOSサーバアプリケーション124が同じCPUやメモリを共有するため、サーバOSサーバアプリケーション124がCPUやメモリを多く使わないときに、空き時間を仮想ポリシ強制部122が使用するため、CPUやメモリの使用効率を向上させることができる。==第7の実施形態==仮想マシンを用いたハイブリッド構成を考慮した第7の実施形態について説明する。図19は、本実施形態のセキュリティポリシ強制システムの構成を示す図である。図19に示すように、本実施形態の特徴は、第1の実施形態で示したポリシ強制部20と、第6の実施形態で示した仮想ポリシ強制部122の両方を備える点にある。ポリシ強制部20は、基本的に第1の実施形態と同様の動作を行なうが、第1の実施形態ではポリシ強制部20またはサーバ14に情報を送信していたのに対し、本実施形態では、仮想ポリシ強制部122またはサーバOSサーバアプリケーション124に送信する点が異なっている。ポリシ強制部20および仮想ポリシ強制部122の動作については、第1および第6の実施形態と同様のため、説明を省略する。本実施形態では、ポリシ強制部20およびサーバ110の負荷に応じて対策実施部52を配置し、負荷の低いポリシ強制部20やサーバ110の対策実施部52を利用することにより、より効率よくコンピュータリソースを使用することができる。なお、本実施形態は、本発明の理解を容易にするためのものであり、本発明を限定して解釈するためのものではない。本発明は、その趣旨を逸脱することなく、変更/改良され得るととともに、本発明にはその等価物も含まれる。例えば、上述の実施形態では、各ポリシ強制部20は複数の対策実施部52を備えることとしたが、各ポリシ強制部20は1つの対策実施部52しか備えないこととしてもよい。この場合、ポリシ判定部22は、ポリシ強制部52に対して情報の転送先のみを送信すればよい。なぜならば、ポリシ強制部20は対策実施部52を1つしか持たないため、その対策実施部52を呼び出すことは自明であり、実施する対策を示す情報は省略可能であるからである。このような構成により、ポリシ判定部22からポリシ強制部20に対する応答のためのメッセージサイズを減らすことが可能となる。また、ポリシ強制部20は、対策実施部52を1つしか持たないため、この対策実施部52による対策を、ポリシ判定部22から転送先についての応答を待つ間に実行してもよい。つまり、図12のステップS02とS04を並列に実行できるため、より高速な動作が可能となる。また、例えば、上述の実施形態では、情報転送部50および対策実施部52が同じコンピュータ上で動作することとしたが、情報転送部50および対策実施部52が異なるコンピュータ上で動作してもよい。その場合、情報転送部50は、ネットワーク経由で対策実施部52を呼び出せばよい。この出願は、2011年1月25日に出願された日本出願特願2011-013392を基礎とする優先権を主張し、その開示の全てをここに取り込む。以上、実施形態を参照して本願発明を説明したが、本願発明は上記実施形態に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。本実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限られない。付記1クライアントからサーバに送信されるユーザ情報に対してセキュリティ対策を実行する、複数のポリシ強制部と、前記ユーザ情報に対して実行すべきセキュリティ対策を示すポリシ情報を記憶するポリシ記憶部と、各ポリシ強制部で実行可能なセキュリティ対策を示す対策配置情報を記憶する対策配置記憶部と、前記複数のポリシ強制部のうち、前記ユーザ情報に対してセキュリティ対策を実行させる少なくとも1つのポリシ強制部を、前記ポリシ情報および前記対策配置情報に基づいて選択する、ポリシ判定部と、を備え、前記少なくとも1つのポリシ強制部の各々は、前記ユーザ情報に対してセキュリティ対策を実行し、前記ポリシ判定部の選択結果に基づいて、前記少なくとも1つのポリシ強制部のうちの他のポリシ強制部、または、前記サーバに前記ユーザ情報を出力する、セキュリティポリシ強制システム。付記2各ポリシ強制部の負荷状況を示す負荷情報を記憶する負荷状況記憶部をさらに備え、前記ポリシ判定部は、前記負荷情報に基づいて、前記ポリシ情報に応じたセキュリティ対策を実行可能なポリシ強制部のうち、前記負荷状況が最も低いポリシ強制部を選択する、付記1に記載のセキュリティポリシ強制システム。付記3複数のセキュリティ対策の実行順序の制約を示す順序制約情報を記憶する順序制約記憶部をさらに備え、前記ポリシ判定部は、前記順序制約情報に基づいて、前記制約に従ってセキュリティ対策が実行されるように前記少なくとも1つのポリシ強制部を選択する、付記1または2に記載のセキュリティポリシ強制システム。付記4前記サーバは、ハードウェアを仮想化する仮想マシンモニタを含んで構成され、前記複数のポリシ強制部のうちの少なくとも1つは、前記仮想マシンモニタによって仮想化されたハードウェアを用いて実現される、付記1~3の何れか一項に記載のセキュリティポリシ強制システム。付記5前記複数のポリシ強制部のうち、前記クライアントから前記ユーザ情報を受信したポリシ強制部は、前記ポリシ判定部に対して前記少なくとも1つのポリシ強制部の選択要求を送信し、前記ポリシ判定部は、前記選択要求に応じて、前記少なくとも1つのポリシ強制部の全ての選択結果を、前記ユーザ情報を受信したポリシ強制部に送信し、前記少なくとも1つのポリシ強制部のうち、前記ユーザ情報を受信したポリシ強制部以外のポリシ強制部は、前記ポリシ判定部に対してポリシ強制部の選択要求を送信することなく、前記選択結果に基づいて、前記少なくとも1つのポリシ強制部のうちの他のポリシ強制部、または、前記サーバに前記ユーザ情報を出力する、付記1~4の何れか一項に記載のセキュリティポリシ強制システム。付記6前記複数のポリシ強制部の間におけるネットワークの状況を示すネットワーク情報を記憶するネットワーク状況記憶部をさらに備え、前記ポリシ判定部は、前記ネットワーク状況に基づいて、前記ポリシ情報に応じたセキュリティ対策を実行可能なポリシ強制部のうち、前記ユーザ情報の転送に効率的なポリシ強制部を選択する、付記1~5の何れか一項に記載のセキュリティポリシ強制システム。付記7クライアントからサーバに送信されるユーザ情報に対して実行すべきセキュリティ対策を示すポリシ情報をポリシ記憶部に記憶し、複数のポリシ強制部の各々で実行可能なセキュリティ対策を示す対策配置情報を対策配置記憶部に記憶し、前記複数のポリシ強制部のうち、前記ユーザ情報に対してセキュリティ対策を実行させる少なくとも1つのポリシ強制部を、前記ポリシ情報および前記対策配置情報に基づいて選択し、前記少なくとも1つのポリシ強制部の各々は、前記ユーザ情報に対してセキュリティ対策を実行し、前記選択結果に基づいて、前記少なくとも1つのポリシ強制部のうちの他のポリシ強制部、または、前記サーバに前記ユーザ情報を出力する、セキュリティポリシ強制方法。付記8コンピュータに、クライアントからサーバに送信されるユーザ情報に対して実行すべきセキュリティ対策を示すポリシ情報と、複数のポリシ強制部の各々で実行可能なセキュリティ対策を示す対策配置情報とに基づいて、前記複数のポリシ強制部のうち、前記ユーザ情報に対してセキュリティ対策を実行させる少なくとも1つのポリシ強制部を、前記ポリシ情報および前記対策配置情報に基づいて選択する機能を実現させるためのプログラム。