JP5920668B2 - セキュリティポリシ強制システム及びセキュリティポリシ強制方法 - Google Patents

Description

本発明は、セキュリティポリシ強制システム及びセキュリティポリシ強制方法に関する。

近年、クラウドと呼ばれるサービス提供形態が普及してきている。クラウドとは、プラットフォーム事業者がサービス事業者へ、サービスを構築するためのプラットフォームを提供し、サービス事業者はそのプラットフォーム上で自前のサービスを構築し、ユーザへサービスを提供するモデルである。

そのような環境において、各々のサービス事業者は、サービスを情報漏洩や攻撃から守るために、サービスにセキュリティ機能を実装している。しかし、サービス事業者それぞれが独自にセキュリティ機能を実装しているため、コストが高いという問題がある。また、サービスの機能とセキュリティ機能が密接に連結しているため、セキュリティ機能の更新が困難であるという問題がある。

これらの問題を解決するために、個々のサービスがセキュリティ機能を持つのではなく、サービスのプラットフォームがセキュリティ機能を持ち、サービス事業者はセキュリティポリシを設定するだけで、プラットフォームによってサービスが守られることが望まれる。そのために、幾つかのシステムが提案されている。

例えば、特許文献１に開示されているシステムでは、クライアントとサーバの間に配置されたネットワーク機器が、クライアントから送信されるネットワークパケットを監視し、アクセスコントロールを行うことにより、セキュリティ対策が実施されている。

また、特許文献２に開示されているシステムでは、クライアントとサーバ間のルータが通信をフックし、ファイアウォールやアンチウィルスなどのセキュリティ装置にパケットを転送することにより、セキュリティ対策が実施されている。

また、一般的なセキュリティ対策として、パケットのフィルタリングを行なうファイアウォールや、侵入を検知するＩＤＳ（Intrusion Detection System）、侵入を防止するＩＰＳ（Intrusion Prevention System）が挙げられる。

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

しかしながら、上記のシステムは大規模な環境を想定しておらず、特定の装置に負荷がかかるため、大規模なシステムに適用できない。具体的には、特許文献１に記載のシステムや、一般的なファイアウォール、ＩＤＳ／ＩＰＳでは、セキュリティ対策を行なう装置にネットワークトラフィックが集中してしまう。また、特許文献２に記載のシステムでは、セキュリティ対策を行なう装置は分散しているが、セキュリティ対策を行なう装置を呼び出す装置（トラフィックを振り分ける装置）にネットワークのトラフィックが集中し、セキュリティ対策処理の能力を拡張することが難しい。

本発明はこのような事情に鑑みてなされたものであり、セキュリティ対策の処理負荷を分散するとともに、大規模なシステムにも適用可能に、セキュリティポリシを強制することを目的とする。

本発明の一側面に係るセキュリティポリシ強制システムは、クライアントからサーバに送信されるユーザ情報に対してセキュリティ対策を実行する、複数のポリシ強制部と、ユーザ情報に対して実行すべきセキュリティ対策を示すポリシ情報を記憶するポリシ記憶部と、各ポリシ強制部で実行可能なセキュリティ対策を示す対策配置情報を記憶する対策配置記憶部と、複数のポリシ強制部のうち、ユーザ情報に対してセキュリティ対策を実行させる少なくとも１つのポリシ強制部を、ポリシ情報および対策配置情報に基づいて選択する、ポリシ判定部と、を備え、少なくとも１つのポリシ強制部の各々は、ユーザ情報に対してセキュリティ対策を実行し、ポリシ判定部の選択結果に基づいて、少なくとも１つのポリシ強制部のうちの他のポリシ強制部、または、サーバにユーザ情報を出力する、セキュリティポリシ強制システム。

なお、本発明において、「部」とは、単に物理的手段を意味するものではなく、その「部」が有する機能をソフトウェアによって実現する場合も含む。また、１つの「部」や装置が有する機能が２つ以上の物理的手段や装置により実現されても、２つ以上の「部」や装置の機能が１つの物理的手段や装置により実現されても良い。

本発明によれば、セキュリティ対策の処理負荷を分散するとともに、大規模なシステムにも適用可能に、セキュリティポリシを強制することが可能となる。

セキュリティポリシ強制システムの構成例を示す図である。 サーバの構成例を示す図である。 ポリシ強制部の構成例を示す図である。 情報転送部間におけるメッセージフォーマットの一例を示す図である。 情報転送部が対策実施部を呼び出す際のメッセージフォーマットの一例を示す図である。 対策実施部から情報転送部への返答の際のメッセージフォーマットの一例を示す図である。 ポリシＤＢの一例を示す図である。 対策配置ＤＢの一例を示す図である。 負荷状況ＤＢの一例を示す図である。 情報転送部からポリシ判定への問い合わせの際のメッセージフォーマットの一例を示す図である。 ポリシ判定部から情報転送部への返答の際のメッセージフォーマットの一例を示す図である。 セキュリティポリシ強制システムの動作の一例を示すシーケンス図である。 ポリシ判定動作の一例を示すフローチャートである。 ポリシ判定動作の他の一例を示すフローチャートである。 順序制約ＤＢの一例を示す図である。 依存関係を示した有向グラフのマージの例を示す図である。 ポリシ強制部の順番と、各ポリシ強制部で行う対策を、最初のポリシ強制部へまとめて通知する場合のメッセージフォーマットの一例を示す図である。 セキュリティポリシ強制システムの他の構成例を示す図である。 セキュリティポリシ強制システムの他の構成例を示す図である。

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

＝＝第１の実施形態＝＝
図１は、本実施形態のセキュリティポリシ強制システムの構成を示す図である。セキュリティポリシ強制システム１０は、クライアント１２がサーバ１４から提供されるサービスを利用する際に、セキュリティポリシに応じたセキュリティ対策を実行する情報処理システムである。なお、セキュリティポリシに応じたセキュリティ対策の実行は、セキュリティポリシの「強制」と呼ばれる。また、本実施形態では、セキュリティ対策のことを単に「対策」とも表現する。

クライアント１２は、ユーザが使用する情報処理装置であり、例えば、ユーザの位置情報や、ブログの記事、ドキュメントファイルやプログラムファイルなどの情報（ユーザ情報）を、セキュリティポリシ強制システム１０を介してサーバ１４へ送信する。クライアント１２は、例えばＳｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ（ＳＯＡＰ）を用いて、ポリシ強制システム１０へ情報を送信することができる。クライアント１２は、例えば、ＣＰＵ、ネットワークインタフェースカード（ＮＩＣ）などを備えるコンピュータであり、情報を送信するアプリケーションプログラムを実行することができる。なお、クライアント１２の構成は一般的なものであるため、詳細な説明は省略する。

サーバ１４は、例えば、ブログサービスやレコメンデーションサービスを提供する情報処理装置であり、クライアント１２から送信される情報を、セキュリティポリシ強制システム１０を介して受け取り、内部に保存する。サーバ１４は、図２に示すように、ＣＰＵ３０やメモリ３２、ネットワークインタフェースカード（ＮＩＣ）３４などを備え、その上でサービスを提供するサーバＯＳ・サーバアプリケーション４０が動作する。なお、サーバ１４の構成は一般的であるため、詳細な説明は省略する。

図１に示すように、セキュリティポリシ強制システム１０は、複数のポリシ強制部２０と、ポリシ判定部２２とを含んで構成されている。

ポリシ強制部２０は、クライアント１２とサーバ１４との間で情報を中継し、中継する情報に対してセキュリティ対策を行なう情報処理装置である。本実施形態では、複数のポリシ強制部２０の各々を区別する必要がある場合には、ポリシ強制部２０−１、ポリシ強制部２０−２、・・・、ポリシ強制部２０−Ｎのように、符号に枝番号を付けて表現する。

ポリシ判定部２２は、あらかじめ定められているセキュリティポリシとユーザから送信された情報とに基づいて、どのポリシ強制部２０を経由してサーバ１４に情報を送信すればよいかを決定する情報処理装置である。

図３は、ポリシ強制部２０の構成例を示す図である。ポリシ強制部２０は、情報転送部５０と、複数の対策実施部５２とを含んで構成されている。また、ポリシ強制部２０は、ＣＰＵ６０やメモリ６２を含んでおり、例えば、メモリ６２に記憶されているプログラムをＣＰＵ６０が実行することにより、情報転送部５０および対策実施部５２を実現することができる。

情報転送部５０は、クライアント１２、他のポリシ強制部２０およびサーバ１４の間で情報を転送する。情報転送部５０は、クライアント１２または他のポリシ強制部２０の情報転送部５０から情報を受信すると、実施すべきセキュリティ対策と、情報の転送先とをポリシ判定部２２に問い合わせる。そして、情報転送部５０は、ポリシ判定部２２の指示に従って、対策実施部５２を呼び出す。そして、対策実施部５２での対策実施完了後に、情報転送部５０は、ポリシ判定部２２の指示に従って、他のポリシ強制部２０またはサーバ１４に情報を転送する。他のポリシ強制部２０またはサーバ１４への情報の転送プロトコルとしては、例えばＳＯＡＰを用いることができる。なお、ＳＯＡＰは一例であり、情報が伝送できれば他のプロトコルでもよい。また、情報転送部５０が対策実施部５２を呼び出すプロトコルとしては、例えばプロセス間通信を用いることができる。また、情報転送部５０は、例えば、宛先ＩＰアドレスの書き換えを用いて、ＴＣＰ／ＩＰの層で情報の転送や対策実施部５２の呼び出しを行ってもよい。同様に、イーサネット（登録商標）レイヤーで情報の転送や対策実施部５２の呼び出しが行われることとしてもよい。

情報転送部５０間での情報のやりとりは、例えば、図４に示すフォーマットで行なわれる。ユーザＩＤはユーザを一意に識別できる識別子であり、サービスＩＤはサービスを一意に識別できる識別子である。また、情報は、クライアントから送信された情報であり、例えば、位置情報やブログの記事である。また、実施済みの対策の項目には、ユーザから送信された情報に対して実施された対策が設定される。

また、情報転送部５０が対策実施部５２を呼び出す際には、例えば図５に示すフォーマットが用いられる。ユーザＩＤ、サービスＩＤ、情報は、図４と同様である。対策パラメータとは、対策を実行するために必要となるパラメータであり、例えば、対策実施部５２が暗号化を行なう場合であれば暗号鍵が設定され、匿名化を行なう場合であればＫ匿名性やＬ多様性などの匿名化の指標が設定される。

対策実施部５２は、情報転送部５０から情報を受け取り、受け取った情報に対してあらかじめ規定されたセキュリティ対策処理を行い、処理済みの情報を情報転送部５０へ返す。本実施形態では、複数の対策実施部５２の各々を区別する必要がある場合には、対策実施部５２−１、対策実施部５２−２、・・・、対策実施部５２−Ｍのように、符号に枝番号を付けて表現する。なお、各対策実施部５２は、異なった対策処理を行う。例えば、ポリシ強制部２０−１は暗号化とアンチウィルス、ポリシ強制部２０−２は匿名化とログ記録のように、それぞれのポリシ強制部２０に配置された対策実施部５２によって、ポリシ強制部２０で実施可能な対策が異なる。

また、対策実施部５２は、組み込まれたセキュリティ対策処理を識別可能に構成されている。例えば、対策実施部５２は、組み込まれたセキュリティ対策処理と同じ名前を持つように構成することができる。例えば、暗号化を行なう対策実施部５２は、「暗号化」という名前を持ち、この名前はセキュリティポリシに記述されている対策と同じである。よって、情報転送部５０は、ポリシ判定部２２からの通知を参照すると、どの対策実施部５２を呼び出せばよいか、一意に特定することができる。なお、ポリシの対策と対策実施部５２に割り当てられる名前を異なるようにしたい場合は、ポリシ判定部２２がポリシの対策の記述を対策実施部５２の名前に変換するデータベースを持つこととすればよい。この場合、ポリシに記述された対策の名前が該データベースに基づいて変換されることにより、対策を実施する対策実施部５２を特定することができる。

また、対策実施部５２が対策を行い、情報転送部５０へ情報を返す際には、例えば図６に示すフォーマットが用いられる。ユーザＩＤ、サービスＩＤ、情報、実施済みの対策は、図４及び図５と同様である。対策結果の項目には、対策実施部５２がセキュリティ対策を行なうことができたか否かを記録する。正常に対策を実施できた場合は例えば「成功」が設定され、何らかの理由で失敗した場合には例えば「失敗」が設定される。

ポリシ判定部２２は、ユーザごとに行なうべきセキュリティ対策を示したセキュリティポリシ（ポリシ情報）が記録されたポリシＤＢ（ポリシ記憶部）を持ち、セキュリティポリシに応じて実施するセキュリティ対策と情報の転送先とを判定する。ポリシ判定部２２が保持するポリシＤＢの一例を図７に示す。ポリシＤＢは、ユーザＩＤ、サービスＩＤ、必要な対策リストを含んで構成される。図７では、例として、ユーザＡがリコメンドサービスを使用するときには、匿名化と仮ＩＤ化が必要であり、ユーザＡがブログサービスを使用するときには、アンチウィルスが必要であることが示されている。また、ユーザＢがブログサービスを使用するときには、アンチウィルスとログ記録が必要であることが示されている。図７の例では、サービスＩＤは、リコメンドサービスなどの簡単な文字列を用いたが、サービスを一意に識別できればよく、例えば、ＵＲＬをサービスＩＤとして用いてもよい。また、ポリシＤＢには、対策のためのパラメータが含まれることとしてもよい。例えば、必要な対策リストに暗号化が含まれる場合であれば、必要な対策リストの中に、暗号化の指定とともに暗号化のための鍵が設定されてもよい。なお、ポリシＤＢは、例えば、リレーショナルデータベースを用いてもよいし、データ量が小規模であるなら、プログラム中の配列として実装してもよい。

加えて、ポリシ判定部２２は、情報の転送先を決定するための情報として、各ポリシ強制部２０がどのような対策実施部５２を保持しているかを示す対策配置情報が記録された対策配置ＤＢ（対策配置記憶部）を持つ。ポリシ判定部２２が保持する対策配置ＤＢの一例を図８に示す。対策配置ＤＢは、ポリシ強制部２０のＩＤ（識別子）とそのポリシ強制部２０に配置されている対策実施部５２のリスト（対策リスト）とを含んで構成される。図８の例では、例えば、ＩＤが１番のポリシ強制部２０−１には匿名化を行なう対策実施部５２が配置されていることが示されている。また、例えば、ＩＤが２番のポリシ強制部２０−２には、ログ記録を行なう対策実施５２−１と、アンチウィルスを行なう対策実施部５２−２とが配置されていることが示されている。なお、対策配置ＤＢも、ポリシＤＢと同様に、例えば、リレーショナルデータベースやプログラム中の配列として実装することができる。

さらに、ポリシ判定部２２は、各ポリシ強制部２０の負荷状況を示す負荷情報が記録された、負荷状況ＤＢ（負荷状況記憶部）を内部に持つ。ポリシ判定部２２が保持する負荷状況ＤＢの一例を図９に示す。負荷状況ＤＢは、ポリシ強制部２０のＩＤと負荷とを含んで構成される。図９の例では、1番のＩＤを持つポリシ強制部２０−１は、負荷が８０％であることが示されている。負荷状況ＤＢも、ポリシＤＢや対策配置ＤＢと同様に、例えば、リレーショナルデータベースやプログラム中の配列として実装することができる。

ポリシ判定部２２は、ポリシ強制部２０の情報転送部５０から問い合わせを受けると、問い合わせ元のポリシ強制部２０で実施すべき対策とその対策のパラメータに加えて、次にどのポリシ強制部２０へ情報を転送すべきかをを、問い合わせ元のポリシ強制部５０に対して通知する。なお、実施すべき対策と情報の転送先を決定するアルゴリズムについては後述する。ポリシ強制部２０の情報転送部５０からポリシ判定部２２への問い合わせは、例えば図１０のフォーマットを用いることができる。ユーザＩＤ、サービスＩＤ、実施済み対策は、図４、５と同様であるため説明を省略する。また、ポリシ判定部２２からポリシ強制部２０の情報転送部５０への返答は、例えば図１１のフォーマットを用いることが出来る。対策と対策のパラメータは、例えば暗号化とその鍵である。また、情報の転送先には、ポリシ強制部２０やサービス（サーバ１４）を識別するためのＩＤが設定される。

セキュリティポリシ強制システム１０の動作について説明する。前述したように、セキュリティポリシ強制システム１０は複数のポリシ強制部２０を備えており、クライアント１２から送信された情報は、複数のポリシ強制部２０を経由して最終的にサーバ１４に到達する。そして、個々のポリシ強制部２０を通過する際に、情報に対してセキュリティ対策が実施される。図１２のシーケンス図を参照してセキュリティポリシ強制システム１０の動作の一例について詳細に説明する。

まず、ユーザが使用するクライアント１２が、ポリシ強制部２０−１の情報転送部５０に情報を送信する（Ｓ０１）。ここで、送信される情報には、ユーザがサーバ１４に送信したい情報（位置情報やブログ記事など）の他に、ユーザＩＤ、利用したいサービスの識別子（サービスＩＤ）が含まれる。

情報転送部５０は、情報を受け取ると、実施すべき対策と、次に情報を転送すべき宛先をポリシ判定部２２に問い合わせる（Ｓ０２）。図１０に示したように、問い合わせには、ポリシ強制部ＩＤ、ユーザＩＤ、サービスＩＤが含まれている。また、実施済の対策の情報も、問い合わせに付加される。この例の場合、まだ対策は行なわれていないため、実施済の対策は、「無し」である。

ポリシ判定部２２は、ユーザＩＤ、サービスＩＤに基づいてポリシＤＢからポリシを検索し、必要な対策を判定する（Ｓ０３）。そして、ポリシ判定部２２は、対策配置ＤＢを用いて、必要な対策実施部５２が配置されているポリシ強制部２０を特定する。最後に、ポリシ判定部２２は、例えば図１１のフォーマットを用いて、実施する対策とそのパラメータ、情報の転送先のポリシ強制部２０のＩＤもしくはサービスＩＤを、ポリシ強制部２０−１へ通知する。なお、ポリシ判定の詳細な動作については後述する。

情報転送部５０は、ポリシ判定部２２から、実施すべき対策と、情報の転送先を受信すると、指示された対策について、順番に対策実施部５２を呼び出して、対策実施部５２に情報に対する対策処理を実行させる（Ｓ０４〜Ｓ０７）。

例えば、対策実施部５２−１、５２−Ｍを呼び出すことをポリシ判定部２２から指示された場合、情報転送部５０は、まず対策実施部５２−１を呼び出し、情報と対策を行なうためのパラメータを渡す（Ｓ０４）。前述したように、情報転送部５０が対策実施部５２を呼び出すときには、図５のフォーマットを用いることができる。

そして、対策実施部５２−１は、情報を受け取り、あらかじめ決められた対策アルゴリズムを対策のパラメータを用いて実行することにより情報に対してセキュリティ対策処理を実行し、処理済みの情報を情報転送部５０へ返す（Ｓ０５）。図６に示したように、対策実施部５２は、処理済みの情報に加えて、対策の処理が成功したか否かを示す情報も、呼び出し元の情報転送部５０へ通知する。

もし、ステップＳ０５において、何らかの理由でセキュリティ対策の処理に失敗した場合（図６の対策結果の項目が「失敗」だった場合）は、ポリシ強制部２０は、クライアント１２にエラーを通知し、処理を終了する。ステップＳ０５において対策の処理が成功している場合は、ステップＳ０４と同様に、情報転送部５０は、対策実施部５２−Ｍを呼び出す（Ｓ０６）。そして、対策実施部５２−Ｍは情報に対策を施し、情報転送部５０へ情報を返す（Ｓ０７）。

情報転送部５０は、ポリシ判定部２２から指定されたポリシ強制部２０（正確には、その情報転送部５０）へ情報を転送する（Ｓ０８）。もし、ポリシ強制部２０ではなく、サーバ１４が指定されていた場合、情報転送部５０はサーバ１４へ情報を送信する。

情報を受け取った次のポリシ強制部２０−Ｎも、前のポリシ強制部２０−１と同様に、ポリシ判定部２２に必要な対策と転送先を問い合わせ、対策実施部５２を呼び出すことで対策を行い、最後に情報の転送を行なう（Ｓ０９、Ｓ１０）。図１２の例では、ポリシ強制部２０−Ｎは、ポリシ判定部２２からサーバ１４へ情報を転送するように指示を受け、サーバ１４に情報を転送している。

最後に、サーバ１４は、ポリシ強制部２０−Ｎから情報を受け取り、該情報を内部に保存する（Ｓ１１）。

次に、ポリシ判定部２２における、ポリシ判定の動作の詳細を説明する。図１３は、ポリシ判定動作の一例を示すフローチャートである。まず、ポリシ判定部２２は、ユーザＩＤおよびサービスＩＤに基づいてポリシＤＢを検索し、必要な対策のリストを取得する（Ｓ１３０１）。

続いて、ポリシ判定部２２は、問い合わせ元を示すポリシ強制部ＩＤを用いて、対策配置ＤＢを検索し、問い合わせ元のポリシ強制部２０にどのような対策実施部５２が配置されているかを特定する。そして、ポリシ判定部２２は、ポリシの必要な対策リストに含まれており、かつ、問い合わせ元のポリシ強制部２０に配置されている対策を、問い合わせ元のポリシ強制部２０で実施すべき対策として決定する（Ｓ１３０２）。このとき、ポリシ判定部２２は、問い合わせのフォーマット（図４）の実施済の対策の項目を参照し、実施すべき対策から既に実施済の対策を除外する。

次に、ポリシ判定部２２は、情報の転送先（次のポリシ強制部２０かサーバ１４）の決定を行なう（Ｓ１３０３〜Ｓ１３０５）。個々のステップについて、詳細に説明する。

ポリシ判定部２２は、ポリシの対策リストのうち、まだ情報に対して実施されておらず、かつ、上記の問い合わせ元のポリシ強制部２０で実施すべきではない対策の中から、次に行うべき対策を一つ選ぶ（Ｓ１３０３）。対策の選び方は、ポリシに書かれている順番でもよいし、ランダムでもよい。このとき、対策を選択できない場合、すなわち、問い合わせ元のポリシ強制部２０で対策が行なわれることにより、ポリシで指定されているすべての対策の実施が完了する場合、サーバ１４を情報の転送先として処理を終了する。

ポリシ判定部２２は、ステップＳ１３０３で選択された対策が配置されているポリシ強制部２０を、対策配置ＤＢから検索する（ステップＳ１３０４）。

ステップＳ１３０３で選択された対策が１つのポリシ強制部５２にしか配置されていない場合は、ポリシ判定部２２は、そのポリシ強制部５２を転送先として決定する。また、ステップＳ１３０３で選択された対策が複数のポリシ強制部５２に配置されている場合は、ポリシ判定部２２は、負荷状況ＤＢを参照して、一番負荷が低いポリシ強制部５２を次に情報を転送すべきポリシ強制部５２として決定する（Ｓ１３０５）。

このように、本実施形態のセキュリティポリシ強制システム１０は、セキュリティポリシを分散して強制するように構成されているため、大規模なシステムにも適用することが可能である。

なお、上記の説明では、サーバ１４は１台であったが、サーバ１４が複数台設けられていてもよい。この場合、対策配置ＤＢには、対策実施部５２の配置状況だけではなく、どのサーバ１４にどのサービスが配置されているかを示す情報が管理される。また、負荷状況ＤＢにも同様に、サーバの負荷を示す情報が管理される。そして、ポリシ判定部２２は、サーバ１４を選択する際に、サービスが配置されているサーバ１４のうち、最も負荷が低いサーバ１４を選択し、情報の転送先として情報転送部５０へ通知する。これにより、セキュリティポリシ強制の負荷分散だけではなく、サーバの負荷分散も行なうことが可能となる。

また、上記の説明では、ポリシの必要な対策リストに含まれており、かつ、問い合わせ元のポリシ強制部２０に配置されている対策を、問い合わせ元のポリシ強制部２０で実施すべき対策として決定した。すなわち、ポリシ判定部２２は、複数の対策の実施を一度に指示したが、複数の対策実施を指示せず、1つの対策の実施のみ指示してもよい。同じポリシ強制部２０で、続けて他の対策の処理を行う場合、ポリシ判定部２２は、転送先に同じポリシ強制部２０を指定し、ポリシ強制部２０は転送先が自分自身の場合には、対策のみを行い、情報の転送を行わなければよい。なお、1つの対策の実施のみというのは、一例であり、２つや３つの対策を指示してもよい。

例えば、複数の対策の実施には時間が掛かるため、その間にポリシ強制部２０の負荷の状況が変化し、コンピュータリソースを効率よく使えない可能性が考えられる。１つの対策の実施は複数の対策の実施よりも実施時間が短いため、ポリシ判定部２２への次の問い合わせまでの時間が短くなる。よって、ポリシ強制部２０の負荷の変動により柔軟に対応できる効果がある。本動作は、ポリシ強制部２０からポリシ判定部２２へのポリシ判定要求の回数やポリシ強制部２０間のデータ転送回数が多くなるデメリットがあるが、高速なネットワークの環境では、そのデメリットを無視できる。

また、上記の説明では、ポリシ強制部２０は、自身が実施する対策と転送先を一度に問い合わせていたが、分割して問い合わせてもよい。具体的には、ポリシ強制部２０は、情報を受け取ったときに、実施する対策をポリシ判定部２２に問い合わせて、対策を実施する。そして、対策実施後に、情報の転送先をポリシ判定部２２に問い合わせ、ポリシ判定部２２の指示に応じて情報を転送する。この動作では、情報を転送する直前に転送先を問い合わせるため、最新の負荷状況に応じて転送先を決定できる効果がある。

＝＝第２の実施形態＝＝
セキュリティ対策の実施順序を考慮した、第２の実施形態について説明する。セキュリティ対策には、対策を実施する順序に制約がある場合がある。例えば、暗号化とアンチウィルスを考えると、アンチウィルスは情報にウィルスのパターンが含まれているかを確認するため、暗号化してある情報に対して行なうことが出来ない。よって、アンチウィルスは、暗号化よりも先に実施されなければならない。したがって、図１３に示したポリシ判定部２２の動作では、対策を実施する順番を指定できないため、順番によっては対策を実施できない可能性がある。

そこで、ポリシ判定部２２は、対策の実行順序の制約を示す順序制約情報が記録された順序制約ＤＢ（順序制約記憶部）を内部に持つこととしてもよい。具体的には、ポリシ強制部２０に配置されているすべての対策について優先順序を規定し、ポリシ判定部２２は、図１３の処理におけるステップＳ１３０２、Ｓ１３０３において、この優先順序に従って対策を選択すればよい。

例えば、ログ記録、アンチウィルス、暗号化という対策がポリシ強制部２０に配置されているとする。ここで、次の２つの要件（１）、（２）があるとする。（１）ログには、アンチウィルスによってウィルスが削除される前の情報を記録したい。（２）暗号化されているとアンチウィルスの処理を行うことができない。この場合、ポリシ判定部２２は、「ログ記録→アンチウィルス→暗号化」という優先順序を内部に保持すればよい。

そして、情報を転送するポリシ強制部２０が優先順序に基づいて決定されるように、図１３におけるステップＳ１３０２〜Ｓ１３０５の処理が、例えば、図１４に示す処理に変更される。

ポリシ判定部２２は、問い合わせ元のポリシ強制部２０で実施可能な対策のうち、優先順序が一番高い対策を、問い合わせ元のポリシ強制部２０で実施する対策のリストに追加する（Ｓ１４０１）。

次に、ポリシ判定部２２は、情報に対してまだ実施されておらず、かつ、上記リストに載っていない対策のうち、優先順序が一番高い対策を選択する（Ｓ１４０２）。

そして、ポリシ判定部２２は、対策配置ＤＢを参照し、選択された対策が問い合わせ元のポリシ強制部２０で実施可能か否かを判定する（Ｓ１４０３）。

選択された対策が問い合わせ元のポリシ強制部２０で実施可能である場合（Ｓ１４０３：ＹＥＳ）、ポリシ判定部２２は、選択された対策を問い合わせ元のポリシ強制部２０で実施すべき対策のリストに追加し（Ｓ１４０４）、ステップＳ１４０２へ戻る。

選択された対策が問い合わせ元のポリシ強制部２０で実施可能ではない場合（Ｓ１４０３：ＮＯ）、ポリシ判定部２２は、問い合わせ元のポリシ強制部２０で実施すべき対策のリストの作成を完了する。そして、ポリシ判定部２２は、選択された対策が実施可能なポリシ強制部２０のうち、一番負荷が低いポリシ強制部２０を情報の転送先に決定する（Ｓ１４０５）。

このように、対策に優先順位を設けることにより、依存関係がある対策を確実に実施することが可能となる。

＝＝第３の実施形態＝＝
セキュリティ対策の実施順序を考慮した、第３の実施形態について説明する。第２の実施形態では、すべての対策の優先順位が記憶されていたが、対策の数が多くなると、優先順位を指定することが難しい場合がある。

そこで、ポリシ判定２２は、図１５に示すような、部分的な順序制約を示す順序制約情報が記録された順序制約ＤＢを備えてもよい。順序制約ＤＢには、「対策Ａは対策Ｂよりも先に実行されなければならない（図中ではＡ→Ｂのように示している）」のような対策の順序の制約を示す情報が記録される。図１５の例では、ログ記録は仮ＩＤ化の処理よりも先に実施されなければならないことや、アンチウィルスは暗号化よりも先に実施されなければならないことが示されている。

本実施形態では、ポリシ判定部２２は、順序制約を満たすように対策の順番を並べ替え、次に行うべき対策を選択する。具体的には、ポリシ判定部２２は、対策の順序制約を有向グラフとみなして各順序制約を表す有向グラフのマージを行ない、対策の依存関係を示した有向グラフを作成する。そして、ポリシ判定部２２は、依存関係を示した有向グラフによって示される上位の対策から選択していく。

グラフのマージは、図１６に示すように、共通した対策を１つにまとめることにより行うことができる。例えば、対策Ｂ→対策Ｃと対策Ａ→対策Ｃというグラフがある場合、図１６（ａ）に示すようにマージすることが出来る。また、対策Ａ→対策Ｂと対策Ａ→対策Ｃというグラフがある場合、図１６（ｂ）に示すようにマージすることが出来る。さらに、また、対策Ｂ→対策Ａと対策Ｃ→対策Ａというグラフがある場合、図１６（ｃ）に示すようにマージすることが出来る。

そして、ポリシ判定部２２は、マージした有向グラフの上位から対策を選択し、ポリシの必要な対策リストを並べかえる。選択の順序は、例えばトポロジカルソートを用いて決定すれば良い。トポロジカルソートは、一般的な技術であるため詳細な説明は省略する。

グラフが１つにマージできない場合、例えば、対策Ａ→対策Ｂ→対策Ｃと対策Ｄ→対策Ｅ→対策Ｆという２つのグラフにマージされた場合、それぞれのグラフに同じ対策は出現せず依存関係は無いため、グラフごとに対策の順序が決定されることとすればよい。

このように決定された対策の順序に従って、上述のように、対策が実施されることとなる。

なお、有向グラフに閉路がある場合、例えば、「Ａ→Ｂ→Ｃ→Ａ」のような場合は、依存関係がループしており、どのような順番で対策を実施したとしても、制約を満たすことは出来ない。よって、この場合、ポリシ判定部２２は、管理者もしくはクライアント１２対してエラーを通知する。

このような構成では、プラットフォーム管理者がすべての対策の依存関係を記述しなくても良いため、管理を簡略化することができる。

また、上記の対策の依存関係のグラフが２つ以上になる場合において、各グラフで次に実施可能な対策のうち、いずれかの対策が配置されているポリシ強制部２０を抽出するように構成することができる。そして、それらのポリシ強制部２０のうち、最も負荷が低いポリシ強制部２０に情報を転送するように指示してもよい。

例えば、対策Ａ→対策Ｂ→対策Ｃと対策Ｄ→対策Ｅ→対策Ｆという２つのグラフがあり、対策Ａと対策Ｄが実施済み、もしくは問い合わせ元のポリシ強制部２０で実施されるとすると、次のポリシ強制部２０で実施可能なのは、対策Ｂと対策Ｅである。このとき、例えば、対策Ｂが配置されているポリシ強制部２０が２つあり、それぞれ５０％と６０％の負荷であり、対策Ｅが配置されているポリシ強制部２０が２つあり、それぞれ１０％と９０％の負荷であったとする。このとき、ポリシ判定部２２は、負荷が一番低い（１０％）のポリシ強制部２０への転送を指示する。

また、依存関係のグラフが１つであっても複数の実施可能な対策がある場合、例えば、図１６（ｃ）のグラフの対策Ｂと対策Ｃのような場合も、上記と同じ手順で、それらの対策のいずれかを実施可能なポリシ強制部２０のうち、最も負荷が低いポリシ強制部２０を、情報の転送先に選んでもよい。

また、第１の実施形態のように順序制約がない場合も、同様の手順で情報の転送先を選んでもよい。

このような動作により、情報は一番負荷の低いポリシ強制部２０に転送されるため、効率的にコンピュータリソースを利用することができる。

＝＝第４の実施形態＝＝
ポリシ判定部２２への問い合わせ回数を考慮した、第４の実施形態について説明する。上述の実施形態では、各ポリシ強制部２０がポリシ判定部２２に問い合わせを行なっていた。したがって、ユーザ数の増加に伴って情報の送信回数が増加した場合や、多くのポリシ強制部２０を用いる場合に、ポリシ判定部２２への問い合わせ回数が増加し、この点がボトルネックになる可能性がある。

そこで、ポリシ判定部２２への問い合わせの増加を防ぐために、ポリシ判定部２２は、最初のポリシ強制部２０の問い合わせに対して、最初のポリシ強制部２０への通知だけではなく、その後のポリシ強制部２０に対する通知をまとめて行うこととしてもよい。これにより、問い合わせの回数を減らすことが出来る。

動作を具体的に説明する。ポリシ判定部２２は、図１３に示したステップＳ１３０３〜Ｓ１３０５を繰り返し、すべての対策について
、どのポリシ強制部２０で行なうかを決定する。そして、ポリシ強制部２０の順番と、それぞれのポリシ強制部２０で行う対策を、最初のポリシ強制部２０へまとめて通知する。

図１７は、まとめて通知する場合のフォーマットの例を示している。図１７の例では、情報はＩＤが「２」のポリシ強制部２０−２で匿名化が行なわれ、ＩＤが「３」のポリシ強制部２０−３でアンチウィルス処理が行われることが示されている。

各々のポリシ強制部２０は、まとめた通知を、情報と共に、次のポリシ強制部２０へ転送する。ポリシ強制部２０は、ポリシ判定部２２に問い合わせるのではなく、前のポリシ強制部２０から受け取った通知を基に、指定された対策を呼び出し、次のポリシ強制部２０もしくはサーバ１４に情報を転送する。

例えば、最初にポリシ強制部２０−１がクライアント１２から情報を受け取り、ポリシ判定部２２から図１７に示す通知がなされた場合、ポリシ強制部２０−１は自分のＩＤのフィールドを参照して対策の項目を参照する。この例の場合、対策は「無し」であるので、ポリシ強制部２０−１は、次のポリシ強制部２０、すなわち、２番のＩＤを持つポリシ強制部２０−２へ情報を転送する。

ポリシ強制部２０−２は、自分のＩＤのフィールドを参照して対策の項目を参照し、対策を実施する。この例の場合は、暗号化が実施される。次に、ポリシ強制部２０−２は、次のポリシ強制部２０、この例では３番のＩＤを持つポリシ強制部２０−３へ、情報を転送する。

ポリシ強制部２０−３は、自身のＩＤの対策の項を参照して、アンチウィルスの処理を行う。図１７に示す通知内容はこれが最後であるため、ポリシ強制部２０−３は、サーバ１４へ情報を転送する。

このように、まとめて通知を行なうことにより、ポリシ判定部２２への問い合わせ回数を減らすことが可能となる。

なお、最初のポリシ強制部２０に各ポリシ強制部２０で行なう対策をまとめて通知するのではなく、各ポリシ強制部２０が、ポリシ判定部２２の通知を一定期間キャッシュすることにより、問い合わせ回数を削減してもよい。

また、上記の説明では、対策のためのパラメータは、ポリシ強制部２０から問い合わせがあるたびに、ポリシ判定部２２から情報転送部５０を介して対策実施部５２へ渡されていた。パラメータのサイズが小さい場合は問題ないが、パラメータのサイズが大きいとネットワーク帯域を消費し、性能低下が生じる可能性がある。そのため、対策のパラメータを各対策実施部５２へ事前に通知し、ポリシ判定部２２がポリシ強制部２０からの問い合わせに応答する際には、対策のパラメータの通知を省略することとしてもよい。

＝＝第５の実施形態＝＝
対策実施部５２の動的な配置を考慮した、第５の実施形態について説明する。上述の実施形態では、対策実施部５２はあらかじめポリシ強制部２０に配置されているものとして説明したが、負荷状況に応じて、動的に対策実施部５２の配置や削除を行ってもよい。その場合には、対策配置ＤＢを更新すればよい。

例えば、負荷の低いポリシ強制部２０−４に対策ａを実行する対策実施部５２を配置した場合、図８に示した対策配置ＤＢに（４、対策ａ）という行が追加される。そして、「対策ａ」がポリシによって実施される場合には、ＩＤが「４」のポリシ強制部２０−４へ情報が転送され、「対策ａ」が実施される。

このように、負荷の低いポリシ強制部２０に対策実施部５２を配置することによって、負荷を分散することが可能となる。なお、負荷分散をするために対策実施部５２を新たに配置する例を説明したが、ポリシ強制部２０が実施可能な対策を増やすために、対策実施部５２を配置してもよい。

また、対策実施部５２の配置を行う際に、ネットワークの状況を考慮して配置先を決定してもよい。具体的には、ポリシ判定部２２は、各ポリシ強制部２０間で情報を転送するための時間を示した転送時間データベース（転送時間ＤＢ）を持つ。そして、ポリシ判定部２２は、ある対策Ａをどのポリシ強制部２０に配置すれば転送時間が最短になるかを計算する。

例えば、ユーザがポリシ強制部２０−１に情報を送信すると仮定する。そして、例えば、ポリシ強制部２０−１からポリシ強制部２０−２への情報転送時間が１秒、ポリシ強制部２０−２からサーバ１４への情報転送時間が１秒、ポリシ強制部２０−１からポリシ強制部２０−３への情報転送時間が２秒、ポリシ強制部２０−３からサーバ１４への情報転送時間が２秒であるとする。

対策Ａを行なう対策実施部５２をポリシ強制部２０−２に配置すると、１秒＋１秒で計２秒、ポリシ強制部２０−３に配置すると、２秒＋２秒で計４秒かかる。よって、ポリシ判定部２２は、対策実施部５２をポリシ強制部２０−２に配置すれば良いと判断する。

なお、上記の説明では、ネットワークの状況を示す情報として、ポリシ強制部２０の間における情報の転送時間を用いることとしたが、ネットワークの状況を示す情報はこれに限られない。例えば、ネットワークの速度や帯域の使用率等の情報をネットワークの状況を示す情報として用いることとしてもよい。

また、ネットワークの状況と、ポリシ強制部２０の負荷の両方を考慮して、対策実施部５２の配置先を決めてもよい。具体的には、上記の情報の転送時間に、配置しようとしている対策実施部５２がポリシ強制部２０において情報を処理する時間を加え、合計時間が最短となるポリシ強制部２０に対策実施部５２を配置すればよい。

例えば、負荷が０％のときに１秒かかる対策を配置することを考える。上記の例で、ポリシ強制部２０−２が負荷８０％、ポリシ強制部２０−３が負荷５０％であるとすると、それぞれ、５秒と２秒の対策の処理時間を要する。よって、経路の転送時間と合計すると、ポリシ強制部２０−２に配置した場合は、１秒＋１秒＋５秒の計７秒であり、ポリシ強制部２０−３に配置した場合は、２秒＋２秒＋２秒の計６秒である。よって、ポリシ判定部２２は、ポリシ強制部２０−３に対策実施部５２を配置すれば良いと判断する。

なお、ユーザが複数の場合や、サーバが複数ある場合は、すべての組み合わせについて時間を計算し、合計時間が最短となるポリシ強制部２０に対策処理部５２を配置すればよい。

また、上記とは逆に、対策実施部５２を削除したい場合は、合計時間が大きい経路に配置されている対策実施部５２を削除すればよい。

＝＝第６の実施形態＝＝
仮想マシンを考慮した第６の実施形態について説明する。なお、第１の実施形態と同様の部分については、説明を省略する。

図１８は、本実施形態のセキュリティポリシ強制システムの構成を示す図である。図１８に示すように、第１の実施形態と異なる点は、第１の実施形態のサーバ１４は、サービスを提供するサーバＯＳ・サーバアプリケーション４０しか備えていないのに対し、本実施形態のサーバ１１０は、仮想マシンモニタ（ＶＭＭ）１２０、仮想ポリシ強制部１２２、サーバＯＳ・サーバアプリケーション１２４を備えることである。

ＶＭＭ１２０は、ＣＰＵ１３０やメモリ１３２等のハードウェアを仮想化し、その上で複数のＯＳを動かすことが出来るプログラムである。ＶＭＭ１２０は、一般的な技術であるため、詳細な説明は省略する。ＶＭＭ１２０としては、例えばＶＭＷａｒｅ（登録商標）やＸｅｎ（登録商標）などを用いることが出来る。

仮想ポリシ強制部１２２は、第１の実施形態のポリシ強制部２０と同様に、セキュリティ対策の実施を行なう。第１の実施形態のポリシ強制部２０は物理的に独立したコンピュータにより構成されていたが、本実施形態の仮想ポリシ強制部１２２は、ＶＭＭ１２０によって仮想化されたコンピュータ上で動作する点が異なっている。

また、サーバＯＳ・サーバアプリケーション１２４は、第１の実施形態のサーバ１４と同様にサービスを提供する。第１の実施形態と異なっている点は、サーバＯＳ・サーバアプリケーション１２４が、ＶＭＭ１２０によって仮想化されたコンピュータ上で動作することである。

次に、本実施形態の全体の動作を説明する。基本的には、第１の実施形態と同様である。クライアント１２は、サーバ１１０−１によって提供される仮想ポリシ強制部１２２に情報を送信する。仮想ポリシ強制部１２２は、第１の実施形態と同様に、実施する対策と転送先をポリシ判定部２２に問い合わせ、対策を実施した後、サーバＯＳ・サーバアプリケーション１２４へ情報を送信する。最後に、サーバＯＳ・サーバアプリケーション１２４は、情報を内部に保存する。

本実施形態では、仮想ポリシ強制部１２２とサーバＯＳ・サーバアプリケーション１２４が同じＣＰＵやメモリを共有するため、サーバＯＳ・サーバアプリケーション１２４がＣＰＵやメモリを多く使わないときに、空き時間を仮想ポリシ強制部１２２が使用するため、ＣＰＵやメモリの使用効率を向上させることができる。

＝＝第７の実施形態＝＝
仮想マシンを用いたハイブリッド構成を考慮した第７の実施形態について説明する。図１９は、本実施形態のセキュリティポリシ強制システムの構成を示す図である。図１９に示すように、本実施形態の特徴は、第１の実施形態で示したポリシ強制部２０と、第６の実施形態で示した仮想ポリシ強制部１２２の両方を備える点にある。

ポリシ強制部２０は、基本的に第１の実施形態と同様の動作を行なうが、第１の実施形態ではポリシ強制部２０またはサーバ１４に情報を送信していたのに対し、本実施形態では、仮想ポリシ強制部１２２またはサーバＯＳ・サーバアプリケーション１２４に送信する点が異なっている。

ポリシ強制部２０および仮想ポリシ強制部１２２の動作については、第１および第６の実施形態と同様のため、説明を省略する。

本実施形態では、ポリシ強制部２０およびサーバ１１０の負荷に応じて対策実施部５２を配置し、負荷の低いポリシ強制部２０やサーバ１１０の対策実施部５２を利用することにより、より効率よくコンピュータリソースを使用することができる。

なお、本実施形態は、本発明の理解を容易にするためのものであり、本発明を限定して解釈するためのものではない。本発明は、その趣旨を逸脱することなく、変更／改良され得るととともに、本発明にはその等価物も含まれる。

例えば、上述の実施形態では、各ポリシ強制部２０は複数の対策実施部５２を備えることとしたが、各ポリシ強制部２０は１つの対策実施部５２しか備えないこととしてもよい。この場合、ポリシ判定部２２は、ポリシ強制部５２に対して情報の転送先のみを送信すればよい。なぜならば、ポリシ強制部２０は対策実施部５２を1つしか持たないため、その対策実施部５２を呼び出すことは自明であり、実施する対策を示す情報は省略可能であるからである。

このような構成により、ポリシ判定部２２からポリシ強制部２０に対する応答のためのメッセージサイズを減らすことが可能となる。また、ポリシ強制部２０は、対策実施部５２を１つしか持たないため、この対策実施部５２による対策を、ポリシ判定部２２から転送先についての応答を待つ間に実行してもよい。つまり、図１２のステップＳ０２とＳ０４を並列に実行できるため、より高速な動作が可能となる。

また、例えば、上述の実施形態では、情報転送部５０および対策実施部５２が同じコンピュータ上で動作することとしたが、情報転送部５０および対策実施部５２が異なるコンピュータ上で動作してもよい。その場合、情報転送部５０は、ネットワーク経由で対策実施部５２を呼び出せばよい。

この出願は、２０１１年１月２５日に出願された日本出願特願２０１１−０１３３９２を基礎とする優先権を主張し、その開示の全てをここに取り込む。

以上、実施形態を参照して本願発明を説明したが、本願発明は上記実施形態に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。

本実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限られない。
（付記１）クライアントからサーバに送信されるユーザ情報に対してセキュリティ対策を実行する、複数のポリシ強制部と、前記ユーザ情報に対して実行すべきセキュリティ対策を示すポリシ情報を記憶するポリシ記憶部と、各ポリシ強制部で実行可能なセキュリティ対策を示す対策配置情報を記憶する対策配置記憶部と、前記複数のポリシ強制部のうち、前記ユーザ情報に対してセキュリティ対策を実行させる少なくとも１つのポリシ強制部を、前記ポリシ情報および前記対策配置情報に基づいて選択する、ポリシ判定部と、を備え、前記少なくとも１つのポリシ強制部の各々は、前記ユーザ情報に対してセキュリティ対策を実行し、前記ポリシ判定部の選択結果に基づいて、前記少なくとも１つのポリシ強制部のうちの他のポリシ強制部、または、前記サーバに前記ユーザ情報を出力する、セキュリティポリシ強制システム。
（付記２）各ポリシ強制部の負荷状況を示す負荷情報を記憶する負荷状況記憶部をさらに備え、前記ポリシ判定部は、前記負荷情報に基づいて、前記ポリシ情報に応じたセキュリティ対策を実行可能なポリシ強制部のうち、前記負荷状況が最も低いポリシ強制部を選択する、付記１に記載のセキュリティポリシ強制システム。
（付記３）複数のセキュリティ対策の実行順序の制約を示す順序制約情報を記憶する順序制約記憶部をさらに備え、前記ポリシ判定部は、前記順序制約情報に基づいて、前記制約に従ってセキュリティ対策が実行されるように前記少なくとも１つのポリシ強制部を選択する、付記１または２に記載のセキュリティポリシ強制システム。
（付記４）前記サーバは、ハードウェアを仮想化する仮想マシンモニタを含んで構成され、前記複数のポリシ強制部のうちの少なくとも１つは、前記仮想マシンモニタによって仮想化されたハードウェアを用いて実現される、付記１〜３の何れか一項に記載のセキュリティポリシ強制システム。
（付記５）前記複数のポリシ強制部のうち、前記クライアントから前記ユーザ情報を受信したポリシ強制部は、前記ポリシ判定部に対して前記少なくとも１つのポリシ強制部の選択要求を送信し、前記ポリシ判定部は、前記選択要求に応じて、前記少なくとも１つのポリシ強制部の全ての選択結果を、前記ユーザ情報を受信したポリシ強制部に送信し、前記少なくとも１つのポリシ強制部のうち、前記ユーザ情報を受信したポリシ強制部以外のポリシ強制部は、前記ポリシ判定部に対してポリシ強制部の選択要求を送信することなく、前記選択結果に基づいて、前記少なくとも１つのポリシ強制部のうちの他のポリシ強制部、または、前記サーバに前記ユーザ情報を出力する、付記１〜４の何れか一項に記載のセキュリティポリシ強制システム。
（付記６）前記複数のポリシ強制部の間におけるネットワークの状況を示すネットワーク情報を記憶するネットワーク状況記憶部をさらに備え、前記ポリシ判定部は、前記ネットワーク状況に基づいて、前記ポリシ情報に応じたセキュリティ対策を実行可能なポリシ強制部のうち、前記ユーザ情報の転送に効率的なポリシ強制部を選択する、付記１〜５の何れか一項に記載のセキュリティポリシ強制システム。
（付記７）クライアントからサーバに送信されるユーザ情報に対して実行すべきセキュリティ対策を示すポリシ情報をポリシ記憶部に記憶し、複数のポリシ強制部の各々で実行可能なセキュリティ対策を示す対策配置情報を対策配置記憶部に記憶し、前記複数のポリシ強制部のうち、前記ユーザ情報に対してセキュリティ対策を実行させる少なくとも１つのポリシ強制部を、前記ポリシ情報および前記対策配置情報に基づいて選択し、前記少なくとも１つのポリシ強制部の各々は、前記ユーザ情報に対してセキュリティ対策を実行し、前記選択結果に基づいて、前記少なくとも１つのポリシ強制部のうちの他のポリシ強制部、または、前記サーバに前記ユーザ情報を出力する、セキュリティポリシ強制方法。
（付記８）コンピュータに、クライアントからサーバに送信されるユーザ情報に対して実行すべきセキュリティ対策を示すポリシ情報と、複数のポリシ強制部の各々で実行可能なセキュリティ対策を示す対策配置情報とに基づいて、前記複数のポリシ強制部のうち、前記ユーザ情報に対してセキュリティ対策を実行させる少なくとも１つのポリシ強制部を、前記ポリシ情報および前記対策配置情報に基づいて選択する機能を実現させるためのプログラム。

１０ セキュリティポリシ強制システム
１２ クライアント
１４ サーバ
２０ ポリシ強制部
２２ ポリシ判定部

Claims (7)

1. クライアントからサーバに送信されるユーザ情報に対してセキュリティ対策を実行する、複数のポリシ強制部と、
   前記ユーザ情報に対して実行すべきセキュリティ対策を示すポリシ情報を記憶するポリシ記憶部と、
   各ポリシ強制部で実行可能なセキュリティ対策を示す対策配置情報を記憶する対策配置記憶部と、
   前記複数のポリシ強制部のうち、前記ユーザ情報に対してセキュリティ対策を実行させる少なくとも１つのポリシ強制部を、前記ポリシ情報および前記対策配置情報に基づいて選択する、ポリシ判定部と、を備え、
   前記少なくとも１つのポリシ強制部の各々は、前記ユーザ情報に対してセキュリティ対策を実行し、前記ポリシ判定部の選択結果に基づいて、前記少なくとも１つのポリシ強制部のうちの他のポリシ強制部、または、前記サーバに前記ユーザ情報を出力し、
   前記複数のポリシ強制部のうち、前記クライアントから前記ユーザ情報を受信したポリシ強制部は、前記ポリシ判定部に対して前記少なくとも１つのポリシ強制部の選択要求を送信し、
   前記ポリシ判定部は、前記選択要求に応じて、前記少なくとも１つのポリシ強制部の全ての選択結果を、前記ユーザ情報を受信したポリシ強制部に送信し、
   前記少なくとも１つのポリシ強制部のうち、前記ユーザ情報を受信したポリシ強制部以外のポリシ強制部は、前記ポリシ判定部に対してポリシ強制部の選択要求を送信することなく、前記選択結果に基づいて、前記少なくとも１つのポリシ強制部のうちの他のポリシ強制部、または、前記サーバに前記ユーザ情報を出力する、
   セキュリティポリシ強制システム。
2. 各ポリシ強制部の負荷状況を示す負荷情報を記憶する負荷状況記憶部をさらに備え、
   前記ポリシ判定部は、前記負荷情報に基づいて、前記ポリシ情報に応じたセキュリティ対策を実行可能なポリシ強制部のうち、前記負荷状況が最も低いポリシ強制部を選択する、請求項１に記載のセキュリティポリシ強制システム。
3. 複数のセキュリティ対策の実行順序の制約を示す順序制約情報を記憶する順序制約記憶部をさらに備え、
   前記ポリシ判定部は、前記順序制約情報に基づいて、前記制約に従ってセキュリティ対策が実行されるように前記少なくとも１つのポリシ強制部を選択する、請求項１または２に記載のセキュリティポリシ強制システム。
4. 前記サーバは、ハードウェアを仮想化する仮想マシンモニタを含んで構成され、
   前記複数のポリシ強制部のうちの少なくとも１つは、前記仮想マシンモニタによって仮想化されたハードウェアを用いて実現される、請求項１〜３の何れか一項に記載のセキュリティポリシ強制システム。
5. 前記複数のポリシ強制部の間におけるネットワークの状況を示すネットワーク情報を記憶するネットワーク状況記憶部をさらに備え、
   前記ポリシ判定部は、前記ネットワークの状況に基づいて、前記ポリシ情報に応じたセキュリティ対策を実行可能なポリシ強制部のうち、前記ユーザ情報の転送に効率的なポリシ強制部を選択する、請求項１〜４の何れか一項に記載のセキュリティポリシ強制システム。
6. クライアントからサーバに送信されるユーザ情報に対して実行すべきセキュリティ対策を示すポリシ情報をポリシ記憶部に記憶し、
   複数のポリシ強制部の各々で実行可能なセキュリティ対策を示す対策配置情報を対策配置記憶部に記憶し、
   前記複数のポリシ強制部のうち、前記ユーザ情報に対してセキュリティ対策を実行させる少なくとも１つのポリシ強制部を、前記ポリシ情報および前記対策配置情報に基づいて選択し、
   前記少なくとも１つのポリシ強制部の各々は、前記ユーザ情報に対してセキュリティ対策を実行し、前記選択の結果に基づいて、前記少なくとも１つのポリシ強制部のうちの他のポリシ強制部、または、前記サーバに前記ユーザ情報を出力し、
   前記複数のポリシ強制部のうち、前記クライアントから前記ユーザ情報を受信したポリシ強制部は、前記少なくとも１つのポリシ強制部の選択要求を送信し、
   前記選択することは、前記選択要求に応じて、前記少なくとも１つのポリシ強制部の全ての選択結果を、前記ユーザ情報を受信したポリシ強制部に送信することを含み、
   前記少なくとも１つのポリシ強制部のうち、前記ユーザ情報を受信したポリシ強制部以外のポリシ強制部は、前記ポリシ強制部の選択要求を送信することなく、前記選択結果に基づいて、前記少なくとも１つのポリシ強制部のうちの他のポリシ強制部、または、前記サーバに前記ユーザ情報を出力する、
   セキュリティポリシ強制方法。
7. コンピュータに、
   クライアントからサーバに送信されるユーザ情報に対して実行すべきセキュリティ対策を示すポリシ情報と、複数のポリシ強制部の各々で実行可能なセキュリティ対策を示す対策配置情報とに基づいて、前記複数のポリシ強制部のうち、前記ユーザ情報に対してセキュリティ対策を実行させる少なくとも１つのポリシ強制部を、前記ポリシ情報および前記対策配置情報に基づいて選択するポリシ判定部を実現させ、
   前記複数のポリシ強制部のうち、前記クライアントから前記ユーザ情報を受信したポリシ強制部は、前記ポリシ判定部に対して前記少なくとも１つのポリシ強制部の選択要求を送信し、
   前記ポリシ判定部は、前記選択要求に応じて、前記少なくとも１つのポリシ強制部の全ての選択結果を、前記ユーザ情報を受信したポリシ強制部に送信し、
   前記少なくとも１つのポリシ強制部のうち、前記ユーザ情報を受信したポリシ強制部以外のポリシ強制部は、前記ポリシ判定部に対してポリシ強制部の選択要求を送信することなく、前記選択結果に基づいて、前記少なくとも１つのポリシ強制部のうちの他のポリシ強制部、または、前記サーバに前記ユーザ情報を出力する、
   プログラム。

Images