(57)【要約】【課題】セキュリティポリシーの関連を考慮してセキュリティポリシー間の整合性を検証できるようにすることを目的とする。【解決手段】セキュリティポリシー２９１はアクセス元とアクセス先とアクセス可否との組み合わせを示す。依存関係情報２９２は依存元と依存先との組み合わせを示す。モデル生成部２１０は、依存関係情報２９２に示される依存元と依存先との組み合わせに対応するアクセス元とアクセス先との組み合わせを有するセキュリティポリシー２９１が存在するか否かを判定する。当該セキュリティポリシー２９１が存在しない場合、モデル生成部２１０は、セキュリティポリシー２９１を補完する。モデル生成部２１０は、補完したセキュリティポリシー２９１を分解して整合性検証モデル２９３を生成する。モデル検証部２２０は、整合性検証モデル２９３を検証し、検証結果データ２９４を生成し、生成した検証結果データ２９４を出力する。【選択図】図２
2012248092.tif 000002
【特許請求の範囲】
【請求項１】
特定のデータと特定のプログラムとのいずれかを対象アクセス先として識別するアクセス先識別子と、対象アクセス先を使用するプログラムを対象アクセス元として識別するアクセス元識別子と、対象アクセス元による対象アクセス先の使用を許可するか否かを識別する使用可否識別子とを含んだ複数のルール情報を記憶するルール情報記憶部と、
複数のプログラムと複数のデータとを関連付ける複数の依存関係情報であって、いずれかのプログラムを対象依存元として識別する依存元識別子と、対象依存元に関連付けられるデータまたはプログラムを対象依存先として識別する依存先識別子とを含んだ複数の依存関係情報を記憶する依存関係情報記憶部と、
前記依存関係情報記憶部に記憶される依存関係情報毎に依存先識別子と依存元識別子との組み合わせに一致するアクセス先識別子とアクセス元識別子との組み合わせを含んだルール情報が前記ルール情報記憶部に記憶されているか否かを判定し、当該ルール情報が前記ルール情報記憶部に記憶されていない依存関係情報を使用不可関係情報として特定する使用不可関係情報特定部と、
前記使用不可関係情報特定部によって特定された使用不可関係情報に基づいて、依存先識別子をアクセス先識別子として含み、依存元識別子をアクセス元識別子として含み、使用不可を示す使用可否識別子を含むルール情報を追加のルール情報として生成するルール情報追加部と、
前記ルール情報記憶部に記憶される複数のルール情報と前記ルール情報追加部によって生成された追加のルール情報とに基づいて、前記複数のルール情報が整合しているか否かを検証するルール情報検証部と
を備えることを特徴とするルール検証装置。
【請求項２】
前記複数のルール情報は、自ルール情報が使用される条件をルール条件として識別するルール条件識別子を含み、
前記ルール情報検証部は、
前記複数のルール情報と前記追加のルール情報とに基づいて特定のアクセス元識別子を含むルール情報を先頭のルール情報として判定し、先頭のルール情報または他のルール情報のアクセス先識別子をアクセス元識別子として含む１つ以上のルール情報を中間のルール情報として判定し、いずれかの中間のルール情報のアクセス先識別子をアクセス元識別子として含み対象アクセス先が無いことを示すアクセス先識別子を含むルール情報を最終のルール情報として判定し、先頭のルール情報と中間のルール情報と最終のルール情報とから成るルール情報の複数の組み合わせを複数のルール情報群として生成し、
生成したルール情報群毎に、先頭のルール情報と中間のルール情報と最終のルール情報とのそれぞれの使用可否識別子と、先頭のルール情報と中間のルール情報と最終のルール情報とのそれぞれのルール条件識別子とに基づいて、ルール情報群のルール条件を示すルール条件式と、ルール情報群の使用可否識別子とを判定し、
最終のルール情報のアクセス元識別子が一致するルール情報群の組み合わせを判定し、判定したルール情報群の組み合わせのうちルール条件式と使用可否識別子との少なくともいずれかが一致しないルール情報群の組み合わせをルール情報群の不整合な組み合わせとして判定し、
判定したルール情報群の不整合な組み合わせを示す検証結果データを生成し、生成した検証結果データを出力する
ことを特徴とする請求項１記載のルール検証装置。
【請求項３】
前記ルール情報検証部は、
ルール情報群毎に、先頭のルール情報と中間のルール情報と最終のルール情報とのうち使用許可を識別する使用可否識別子を含んだルール情報を当該ルール情報群の肯定のルール情報として判定し、
ルール情報群毎に、先頭のルール情報と中間のルール情報と最終のルール情報とのうち使用不可を識別する使用可否識別子を含んだルール情報を当該ルール情報群の否定のルール情報として判定し、
ルール情報群毎に、肯定のルール情報のルール条件と、否定のルール情報のルール条件を否定するルール条件とを含む式を当該ルール情報群のルール条件式として生成する
ことを特徴とする請求項２記載のルール検証装置。
【請求項４】
前記ルール情報検証部は、ルール情報群毎に、最終のルール情報の使用可否識別子を当該ルール情報群の使用可否識別子として判定する
ことを特徴とする請求項３記載のルール検証装置。
【請求項５】
前記ルール情報検証部は、前記最終のルール情報に該当するルール情報が存在しない場合、いずれかの中間のルール情報のアクセス先識別子をアクセス元識別子として含み、先頭のルール情報のアクセス元識別子と中間のルール情報のアクセス元識別子とのいずれかをアクセス先識別子として含むルール情報を最終のルール情報として判定する
ことを特徴とする請求項２から請求項４いずれかに記載のルール検証装置。
【請求項６】
前記複数のルール情報は、対象アクセス先を使用する使用方法を識別する１つ以上の使用方法識別子を含み、
前記ルール情報追加部は、所定の使用方法を識別する１つ以上の使用方法識別子を含んだ追加のルール情報を生成し、
前記ルール情報検証部は、最終のルール情報のアクセス元識別子が一致し、少なくともいずれかの使用方法識別子が一致し、ルール条件式と使用可否識別子との少なくともいずれかが一致しないルール情報群の組み合わせをルール情報群の不整合な組み合わせとして判定する
ことを特徴とする請求項２から請求項５いずれかに記載のルール検証装置。
【請求項７】
特定のデータと特定のプログラムとのいずれかを対象アクセス先として識別するアクセス先識別子と、対象アクセス先を使用するプログラムを対象アクセス元として識別するアクセス元識別子と、対象アクセス元による対象アクセス先の使用を許可するか否かを識別する使用可否識別子とを含んだ複数のルール情報を記憶するルール情報記憶部と、
複数のプログラムと複数のデータとを関連付ける複数の依存関係情報であって、いずれかのプログラムを対象依存元として識別する依存元識別子と、対象依存元に関連付けられるデータまたはプログラムを対象依存先として識別する依存先識別子とを含んだ複数の依存関係情報を記憶する依存関係情報記憶部と、
使用不可関係情報特定部と、ルール情報追加部と、ルール情報検証部とを備えるルール検証装置のルール検証方法であって、
前記使用不可関係情報特定部が、前記依存関係情報記憶部に記憶される依存関係情報毎に依存先識別子と依存元識別子との組み合わせに一致するアクセス先識別子とアクセス元識別子との組み合わせを含んだルール情報が前記ルール情報記憶部に記憶されているか否かを判定し、当該ルール情報が前記ルール情報記憶部に記憶されていない依存関係情報を使用不可関係情報として特定し、
前記ルール情報追加部が、前記使用不可関係情報特定部によって特定された使用不可関係情報に基づいて、依存先識別子をアクセス先識別子として含み、依存元識別子をアクセス元識別子として含み、使用不可を示す使用可否識別子を含むルール情報を追加のルール情報として生成し、
前記ルール情報検証部が、前記ルール情報記憶部に記憶される複数のルール情報と前記ルール情報追加部によって生成された追加のルール情報とに基づいて、前記複数のルール情報が整合しているか否かを検証する
ことを特徴とするルール検証装置のルール検証方法。
【請求項８】
特定のデータと特定のプログラムとのいずれかを対象アクセス先として識別するアクセス先識別子と、対象アクセス先を使用するプログラムを対象アクセス元として識別するアクセス元識別子と、対象アクセス元による対象アクセス先の使用を許可するか否かを識別する使用可否識別子とを含んだ複数のルール情報を記憶するルール情報記憶部と、
複数のプログラムと複数のデータとを関連付ける複数の依存関係情報であって、いずれかのプログラムを対象依存元として識別する依存元識別子と、対象依存元に関連付けられるデータまたはプログラムを対象依存先として識別する依存先識別子とを含んだ複数の依存関係情報を記憶する依存関係情報記憶部と
を備えるルール検証装置を機能させるルール検証プログラムであって、
前記依存関係情報記憶部に記憶される依存関係情報毎に依存先識別子と依存元識別子との組み合わせに一致するアクセス先識別子とアクセス元識別子との組み合わせを含んだルール情報が前記ルール情報記憶部に記憶されているか否かを判定し、当該ルール情報が前記ルール情報記憶部に記憶されていない依存関係情報を使用不可関係情報として特定する使用不可関係情報特定部と、
前記使用不可関係情報特定部によって特定された使用不可関係情報に基づいて、依存先識別子をアクセス先識別子として含み、依存元識別子をアクセス元識別子として含み、使用不可を示す使用可否識別子を含むルール情報を追加のルール情報として生成するルール情報追加部と、
前記ルール情報記憶部に記憶される複数のルール情報と前記ルール情報追加部によって生成された追加のルール情報とに基づいて、前記複数のルール情報が整合しているか否かを検証するルール情報検証部としてルール検証装置を機能させる
ことを特徴とするルール検証プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、例えば、セキュリティポリシーを構成するルールを検証するルール検証装置、ルール検証装置のルール検証方法およびルール検証プログラムに関するものである。
【背景技術】
【０００２】
特許文献１には、ポリシーをモデルに変換し、モデルをチェッカー（検証装置）にかけて「ウェブサービス構成のセキュリティチェック」という目標を実現しているか否かを判定する技術が開示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００５−３２２２３４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
特許文献１の技術には、「目標」を達成しているかを検証することはできるが、「ポリシー同士」の整合性を検証することができないという課題がある。
ポリシー同士の整合性を検証するためには、ポリシー全体の関係を把握する必要があり、業務やサービスの依存関係の情報が必要となるが、特許文献１の技術では依存関係情報に基づいた検証を行っていないからである。
【０００５】
本発明は、例えば、複数のレイヤ（例えば、アプリケーション、サービス、データ）のセキュリティポリシーの関連を考慮してセキュリティポリシー間の整合性を検証できるようにすることを目的とする。
【課題を解決するための手段】
【０００６】
本発明のルール検証装置は、
特定のデータと特定のプログラムとのいずれかを対象アクセス先として識別するアクセス先識別子と、対象アクセス先を使用するプログラムを対象アクセス元として識別するアクセス元識別子と、対象アクセス元による対象アクセス先の使用を許可するか否かを識別する使用可否識別子とを含んだ複数のルール情報を記憶するルール情報記憶部と、
複数のプログラムと複数のデータとを関連付ける複数の依存関係情報であって、いずれかのプログラムを対象依存元として識別する依存元識別子と、対象依存元に関連付けられるデータまたはプログラムを対象依存先として識別する依存先識別子とを含んだ複数の依存関係情報を記憶する依存関係情報記憶部と、
前記依存関係情報記憶部に記憶される依存関係情報毎に依存先識別子と依存元識別子との組み合わせに一致するアクセス先識別子とアクセス元識別子との組み合わせを含んだルール情報が前記ルール情報記憶部に記憶されているか否かを判定し、当該ルール情報が前記ルール情報記憶部に記憶されていない依存関係情報を使用不可関係情報として特定する使用不可関係情報特定部と、
前記使用不可関係情報特定部によって特定された使用不可関係情報に基づいて、依存先識別子をアクセス先識別子として含み、依存元識別子をアクセス元識別子として含み、使用不可を示す使用可否識別子を含むルール情報を追加のルール情報として生成するルール情報追加部と、
前記ルール情報記憶部に記憶される複数のルール情報と前記ルール情報追加部によって生成された追加のルール情報とに基づいて、前記複数のルール情報が整合しているか否かを検証するルール情報検証部とを備える。
【発明の効果】
【０００７】
本発明によれば、例えば、複数のレイヤ（例えば、アプリケーション、サービス、データ）のセキュリティポリシー（ルール情報）の関連（依存関係情報）を考慮してセキュリティポリシー間の整合性を検証することができる。
【図面の簡単な説明】
【０００８】
【図１】実施の形態１におけるポリシー検証システム１００の構成図。
【図２】実施の形態１におけるポリシー検証装置２００の機能構成図。
【図３】実施の形態１におけるセキュリティポリシー２９１のモデルを示すインスタンス図。
【図４】実施の形態１におけるセキュリティポリシー２９１の「Ｓｕｂｊｅｃｔ」と「Ｒｅｓｏｕｒｃｅ」との関係を示すベン図。
【図５】実施の形態１におけるセキュリティポリシー２９１の一例を示す図。
【図６】実施の形態１における依存関係情報２９２のモデルを示すインスタンス図。
【図７】実施の形態１における依存関係情報２９２の「Ｄｅｐｅｎｄｅｎｔ」と「Ａｎｔｅｃｅｄｅｎｔ」との関係を示すベン図。
【図８】実施の形態１における依存関係情報２９２の一例を示す図。
【図９】実施の形態１における整合性検証モデル２９３を示すインスタンス図。
【図１０】実施の形態１における整合性検証モデル２９３の一例を示す図。
【図１１】実施の形態１におけるセキュリティポリシー２９１のモデルと整合性検証モデル２９３との関係を示す対応表。
【図１２】実施の形態１におけるポリシー検証装置２００のポリシー検証方法を示すフローチャート。
【図１３】実施の形態１におけるポリシー追加処理（Ｓ１１０）のフローチャート。
【図１４】実施の形態１におけるセキュリティポリシー生成処理（Ｓ１１４）の説明を補足する表。
【図１５】実施の形態１におけるモデル生成処理（Ｓ１２０）のフローチャート。
【図１６】実施の形態１におけるモデル検証処理（Ｓ１３０）のフローチャート。
【図１７】実施の形態１におけるルールリスト生成処理（Ｓ１３３）の概要図。
【図１８】実施の形態１における統合ルール生成処理（Ｓ１３４）のフローチャート。
【図１９】実施の形態１における適用条件判定処理（Ｓ１３４ｂ−Ｓ１３４ｆ）の概要図。
【図２０】実施の形態１における統合ルール生成処理（Ｓ１３４ｇ）の説明を補足する対応表。
【図２１】実施の形態１における整合性判定処理（Ｓ１３５）のフローチャート。
【図２２】実施の形態１における統合ルール２８１の不整合条件を示す表。
【図２３】実施の形態１における検証結果画面２８３の一例を示す図。
【図２４】実施の形態１におけるポリシー検証装置２００のハードウェア資源の一例を示す図。
【発明を実施するための形態】
【０００９】
実施の形態１．
各種のポリシーの整合性を検証するシステムの形態について説明する。
ポリシーとは、プログラムやデータを使用するための規則を定義したものである。
【００１０】
図１は、実施の形態１におけるポリシー検証システム１００の構成図である。
実施の形態１におけるポリシー検証システム１００の構成について、図１に基づいて説明する。
【００１１】
ポリシー検証システム１００は、ポリシー検証装置２００（ルール検証装置の一例）と、業務ポリシー管理装置１１０と、サービスポリシー管理装置１２０と、データポリシー管理装置１３０と、依存関係管理装置１４０とを備える。
【００１２】
ポリシー検証装置２００は、ディスプレイ装置９１１、キーボード９１２、記憶装置（図示省略）、通信装置（図示省略）などのハードウェアを備える。
各ポリシー管理装置（符号１１０，１２０，１３０，１４０）および依存関係管理装置１４０は、ポリシー検証装置２００と同様に、各種ハードウェアを備える。
【００１３】
ポリシーを管理する管理者（図示省略）は、ポリシー管理装置（符号１１０，１２０）を用いてポリシーを生成する。
例えば、業務に関するポリシー（業務ポリシー１１９）を管理する管理者は、業務ポリシー管理装置１１０の入力装置（例えば、キーボード）を操作して業務ポリシー１１９に設定する事項を入力する。
業務ポリシー管理装置１１０のポリシー生成部（図示省略）は、入力された事項を設定したデータ（ファイルともいう）を「業務ポリシー１１９」として生成し、生成した「業務ポリシー１１９」を記憶装置に記憶する。
【００１４】
データとプログラムとの依存関係を管理する管理者（図示省略）は、依存関係管理装置１４０を用いて依存関係を定義した依存関係情報（例えば、業務関係情報１４８、サービス関係情報１４９）を生成する。
例えば、管理者は、依存関係管理装置１４０の入力装置を操作して、業務に関する依存関係やサービスに関する依存関係を入力する。
依存関係管理装置１４０は、入力された依存関係を設定したデータ（ファイルともいう）を「業務関係情報１４８」または「サービス関係情報１４９」として生成し、生成した「業務関係情報１４８」または「サービス関係情報１４９」を記憶装置に記憶する。
【００１５】
検証者１０１は、業務ポリシー１１９とサービスポリシー１２９とデータポリシー１３９とを各ポリシー管理装置から記憶媒体（例えば、ＵＳＢメモリ）にコピーする。さらに、検証者１０１は、依存関係管理装置１４０から業務関係情報１４８とサービス関係情報１４９とを記憶媒体にコピーする。
検証者１０１は、記憶媒体を用いて、業務ポリシー１１９とサービスポリシー１２９とデータポリシー１３９とをポリシー検証装置２００の記憶装置に記憶する。さらに、検証者１０１は、記憶媒体を用いて、業務関係情報１４８とサービス関係情報１４９とをポリシー検証装置２００の記憶装置に記憶する。また、検証者１０１は、経営者１０２が定めた会社規則１０３などに基づいてポリシー検証装置２００に新たなポリシーに設定する事項を入力しても構わない。この場合、ポリシー検証装置２００のポリシー生成部（図示省略）は、入力された事項を設定して新たなポリシーを生成し、生成したポリシーを記憶装置に記憶する。
検証者１０１は、ポリシー検証装置２００の入力装置（例えば、キーボード９１２）を操作してポリシー検証プログラム（ルール検証プログラムの一例）を起動する。
【００１６】
ポリシー検証装置２００は、ポリシー検証プログラムを実行する。
これにより、業務ポリシー１１９とサービスポリシー１２９とデータポリシー１３９との整合性が業務関係情報１４８とサービス関係情報１４９とを用いて検証され、検証結果が出力される。
【００１７】
以下、業務ポリシー１１９、サービスポリシー１２９、データポリシー１３９およびその他のポリシーを総称して「セキュリティポリシー」という。
また、業務関係情報１４８、サービス関係情報１４９およびその他の依存関係情報を総称して「依存関係情報」という。
【００１８】
図２は、実施の形態１におけるポリシー検証装置２００の機能構成図である。
実施の形態１におけるポリシー検証装置２００の機能構成について、図２に基づいて説明する。
【００１９】
ポリシー検証装置２００（ルール検証装置の一例）は、モデル生成部２１０（使用不可関係情報特定部、ルール情報追加部の一例）と、モデル検証部２２０（ルール情報検証部の一例）と、検証装置記憶部２９０（ルール情報記憶部、依存関係情報記憶部の一例）とを備える。
【００２０】
検証装置記憶部２９０は、ポリシー検証装置２００が使用するデータを記憶する。
セキュリティポリシー２９１（ポリシー情報、ルール情報の一例）、依存関係情報２９２（依存関係情報の一例）、整合性検証モデル２９３（ルール情報）、検証結果データ２９４は、検証装置記憶部２９０に記憶するデータの一例である。
【００２１】
セキュリティポリシー２９１は、１つ以上のアクセス先識別子（後述するＲｅｓｏｕｒｃｅまたはＴｏ）と、１つ以上のアクセス元識別子（後述するＳｕｂｊｅｃｔまたはＦｒｏｍ）と、１つの使用可否識別子（後述するＥｆｆｅｃｔ）と、１つ以上のルール条件識別子（後述するＣｏｎｄｉｔｉｏｎ）と、１つ以上の使用方法識別子（後述するＡｃｔｉｏｎ）を含んだデータ（またはファイル）である。
アクセス先識別子は、特定のデータと特定のプログラムとのいずれかを対象アクセス先（またはアクセス先）として識別する。
アクセス元識別子は、対象アクセス先を使用するプログラムを対象アクセス元（またはアクセス元）として識別する。
使用可否識別子は、対象アクセス元による対象アクセス先の使用を許可するか否かを識別する。
ルール条件識別子は、自己のセキュリティポリシー２９１が使用される条件をルール条件（または適用条件）として識別する。
使用方法識別子は、対象アクセス先を使用する使用方法（または操作内容）を識別する。
【００２２】
依存関係情報２９２は、複数のプログラムと複数のデータとを関連付けるデータ（またはファイル）である。
依存関係情報２９２は、依存元識別子（後述するＤｅｐｅｎｄｅｎｔ）と、依存先識別子（後述するＡｎｔｅｃｅｄｅｎｔ）とを含む。
依存元識別子は、いずれかのプログラムを対象依存元（または依存元）として識別する。
依存先識別子は、対象依存元に関連付けられるデータまたはプログラムを対象依存先（または依存先）として識別する。
【００２３】
整合性検証モデル２９３は、アクセス先識別子とアクセス元識別子との組み合わせ毎に分解した複数のセキュリティポリシー２９１（後述するセキュリティルール）を有するデータ（またはファイル）である。
【００２４】
検証結果データ２９４は、整合性検証モデル２９３を検証した結果を示すデータである。
【００２５】
モデル生成部２１０は、依存関係情報２９２毎に依存先識別子と依存元識別子との組み合わせに一致するアクセス先識別子とアクセス元識別子との組み合わせを含んだセキュリティルールが記憶されているか否かを判定する。
モデル生成部２１０は、当該セキュリティルールが記憶されていない依存関係情報２９２を使用不可関係情報として特定する（使用不可関係情報特定処理）。
【００２６】
モデル生成部２１０は、使用不可関係情報に基づいて、依存先識別子をアクセス先識別子として含み、依存元識別子をアクセス元識別子として含み、使用不可（後述するＤｅｎｙ）を示す使用可否識別子を含み、所定の使用方法を識別する１つ以上の使用方法識別子とを含むセキュリティルールを追加のセキュリティルールとして生成する（ルール情報追加処理）。
【００２７】
モデル検証部２２０は、検証装置記憶部２９０に記憶される複数のセキュリティルールとモデル生成部２１０によって生成された追加のセキュリティルールとに基づいて、複数のセキュリティルールが整合しているか否かを検証する（ルール情報検証処理）。
【００２８】
例えば、モデル検証部２２０は、以下のように複数のセキュリティルールを検証する。
モデル検証部２２０は、複数のセキュリティルールと追加のセキュリティルールとに基づいて特定のアクセス元識別子を含むセキュリティルールを先頭のセキュリティルールとして判定する。
モデル検証部２２０は、先頭のセキュリティルールまたは他のセキュリティルールのアクセス先識別子をアクセス元識別子として含む１つ以上のセキュリティルールを中間のセキュリティルールとして判定する。
モデル検証部２２０は、いずれかの中間のセキュリティルールのアクセス先識別子をアクセス元識別子として含み対象アクセス先が無いことを示すアクセス先識別子を含むセキュリティルールを最終のセキュリティルールとして判定する。但し、当該セキュリティルールが存在しない場合、いずれかの中間のセキュリティルールのアクセス先識別子をアクセス元識別子として含み先頭のセキュリティルールのアクセス元識別子と中間のセキュリティルールのアクセス元識別子とのいずれかを含むセキュリティルールを最終のセキュリティルールとして判定する。
モデル検証部２２０は、先頭のセキュリティルールと中間のセキュリティルールと最終のセキュリティルールとから成るセキュリティルールの複数の組み合わせを複数のルール集合（ルール情報群の一例）として生成する。
モデル検証部２２０は、生成したルール集合毎に、先頭のセキュリティルールと中間のセキュリティルールと最終のセキュリティルールとのそれぞれの使用可否識別子と、先頭のセキュリティルールと中間のセキュリティルールと最終のセキュリティルールとのそれぞれのルール条件識別子とに基づいて、ルール集合のルール条件を示すルール条件式と、ルール集合の使用可否識別子とを判定する。
モデル検証部２２０は、最終のセキュリティルールのアクセス元識別子が一致し、少なくともいずれかの使用方法識別子が一致するルール集合の組み合わせを判定する。
モデル検証部２２０は、判定したルール集合の組み合わせのうちルール条件式と使用可否識別子との少なくともいずれかが一致しないルール集合の組み合わせをルール集合の不整合な組み合わせとして判定する。
モデル検証部２２０は、判定したルール集合の不整合な組み合わせを示す検証結果データ２９４を生成し、生成した検証結果データ２９４を出力する。
【００２９】
例えば、モデル検証部２２０は、以下のようにルール集合のルール条件式を生成する。
モデル検証部２２０は、ルール集合毎に、先頭のセキュリティルールと中間のセキュリティルールと最終のセキュリティルールとのうち使用許可を識別する使用可否識別子（後述するＰｅｒｍｉｔ）を含んだセキュリティルールを当該ルール集合の肯定のセキュリティルールとして判定する。
モデル検証部２２０は、ルール集合毎に、先頭のセキュリティルールと中間のセキュリティルールと最終のセキュリティルールとのうち使用不可を識別する使用可否識別子（後述するＤｅｎｙ）を含んだセキュリティルールを当該ルール集合の否定のセキュリティルールとして判定する。
モデル検証部２２０は、ルール集合毎に、肯定のセキュリティルールのルール条件と否定のセキュリティルールのルール条件を否定するルール条件とを含む式を当該ルール集合のルール条件式として生成する。
【００３０】
例えば、モデル検証部２２０は、以下のようにルール集合の使用可否識別子を判定する。
モデル検証部２２０は、ルール集合毎に、最終のセキュリティルールの使用可否識別子を当該ルール集合の使用可否識別子として判定する。
【００３１】
図３は、実施の形態１におけるセキュリティポリシー２９１のモデルを示すインスタンス図である。
実施の形態１におけるセキュリティポリシー２９１のデータ構造について、図３に基づいて説明する。
【００３２】
ここで、セキュリティポリシー２９１の集合体を「ＰｏｌｉｃｙＳｅｔ（ポリシーセット）」と記す。
【００３３】
「ＰｏｌｉｃｙＳｅｔ」は、０個以上のセキュリティポリシー２９１を有する。
「Ｐｏｌｉｃｙ（ポリシー）」は、セキュリティポリシー２９１を識別する識別子を示す。
【００３４】
「Ｐｏｌｉｃｙ」（ポリシー情報、ルール情報の一例）は、属性として「Ｅｆｆｅｃｔ（エフェクト）」を有する。
「Ｅｆｆｅｃｔ」（使用可否識別子の一例）は、「Ｐｅｒｍｉｔ（許可）」または「Ｄｅｎｙ（不許可）」を示す。
【００３５】
「Ｐｏｌｉｃｙ」は、子要素として「Ｓｕｂｊｅｃｔ（サブジェクト）」と、「Ｒｅｓｏｕｒｃｅ（リソース）」と、「Ａｃｔｉｏｎ（アクション）」と、「Ｃｏｎｄｉｔｉｏｎ（コンディション）」とを有する。
【００３６】
「Ｓｕｂｊｅｃｔ」（アクセス元識別子の一例）は、１つ以上のアクセス元の識別子を示す。アプリケーションプログラム、業務プログラム、サービスプログラムまたはユーザはアクセス元の一例である。
「Ｒｅｓｏｕｒｃｅ」（アクセス先識別子の一例）は、１つ以上のアクセス先の識別子を示す。アプリケーションプログラム、業務プログラム、サービスプログラムまたはデータはアクセス先の一例である。
【００３７】
アクセス元はアクセス先を操作する。
【００３８】
「Ａｃｔｉｏｎ」（使用方法識別子の一例）は、１つ以上の操作内容の識別子を示す。読み取り、書き込み、呼び出しまたは複製は操作内容の一例である。
【００３９】
「Ｃｏｎｄｉｔｉｏｎ」（ルール条件識別子の一例）は、「Ｐｏｌｉｃｙ」を適用する０個以上の識別子を示す。年度、業務の種類または部署は適用条件の一例である。
【００４０】
図４は、実施の形態１におけるセキュリティポリシー２９１の「Ｓｕｂｊｅｃｔ」と「Ｒｅｓｏｕｒｃｅ」との関係を示すベン図である。
アクセス先であるアプリケーションプログラム、業務プログラム、サービスプログラムまたはユーザは、他のプログラムやデータにアクセスするアクセス元にもなるため、アクセス元「Ｓｕｂｊｅｃｔ」とアクセス先「Ｒｅｓｏｕｒｃｅ」とは部分的に重複する（図４参照）。
【００４１】
図５は、実施の形態１におけるセキュリティポリシー２９１の一例を示す図である。
例えば、セキュリティポリシー２９１は、図５に示すようにＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）を用いて記述され、ファイルとして記憶される。
セキュリティポリシー２９１の要素（または属性）は、タグ「＜・・・＞」を用いて記される。
【００４２】
図６は、実施の形態１における依存関係情報２９２のモデルを示すインスタンス図である。
実施の形態１における依存関係情報２９２のデータ構造について、図６に基づいて説明する。
【００４３】
ここで、依存関係情報２９２の集合体を「ＤｅｐｅｎｄｅｎｃｙＳｅｔ（ディペンデンシーセット）」と記す。
【００４４】
「ＤｅｐｅｎｄｅｎｃｙＳｅｔ」は、０個以上の依存関係情報２９２を有する。
「Ｄｅｐｅｎｄｅｎｃｙ（ディペンデンシー）」は、依存関係情報２９２を識別する識別子を示す。
【００４５】
「Ｄｅｐｅｎｄｅｎｃｙ」（依存関係情報の一例）は、子要素として「Ｄｅｐｅｎｄｅｎｔ（ディペンデント）」と、「Ａｎｔｅｃｅｄｅｎｔ（アンティシーデント）」とを有する。
【００４６】
「Ｄｅｐｅｎｄｅｎｔ」（依存元識別子の一例）は、１つの依存元の識別子を示す。アプリケーションプログラム、業務プログラム、サービスプログラムまたはユーザは依存元の一例である。
「Ａｎｔｅｃｅｄｅｎｔ」（依存先識別子の一例）は、０個以上の依存先の識別子を示す。アプリケーションプログラム、業務プログラム、サービスプログラムまたはデータは依存先の一例である。
【００４７】
依存元と依存先とは互いに関連する。
【００４８】
図７は、実施の形態１における依存関係情報２９２の「Ｄｅｐｅｎｄｅｎｔ」と「Ａｎｔｅｃｅｄｅｎｔ」との関係を示すベン図である。
依存先であるアプリケーションプログラム、業務プログラム、サービスプログラムまたはユーザは、他のプログラムやデータと関連する依存元にもなるため、依存元「Ｄｅｐｅｎｄｅｎｔ」と依存先「Ａｎｔｅｃｅｄｅｎｔ」とは部分的に重複する（図７参照）。
【００４９】
図８は、実施の形態１における依存関係情報２９２の一例を示す図である。
例えば、依存関係情報２９２は、図８に示すようにＸＭＬを用いて記述され、ファイルとして記憶される。依存関係情報２９２の要素はタグを用いて記される。
【００５０】
図９は、実施の形態１における整合性検証モデル２９３を示すインスタンス図である。
実施の形態１における整合性検証モデル２９３のデータ構造について、図９に基づいて説明する。
【００５１】
ここで、整合性検証モデル２９３を「Ｍｏｄｅｌ（モデル）」と記す。
【００５２】
「Ｍｏｄｅｌ」は、０個以上のセキュリティルールを有する。
「Ｒｕｌｅ（ルール）」は、セキュリティルールを識別する識別子を示す。
【００５３】
「Ｒｕｌｅ」（ルール情報の一例）は、属性として「Ｅｆｆｅｃｔ」を有する。
【００５４】
「Ｒｕｌｅ」は、子要素として「Ｆｒｏｍ」と、「Ｔｏ」と、「Ａｃｔｉｏｎ」と、「Ｃｏｎｄｉｔｉｏｎ」とを有する。
【００５５】
「Ｆｒｏｍ」（アクセス元識別子の一例）は、１つの遷移元の識別子を示す。アプリケーションプログラム、業務プログラム、サービスプログラムまたはユーザは遷移元の一例である。
「Ｔｏ」（アクセス先識別子の一例）は、１つの遷移先の識別子を示す。アプリケーションプログラム、業務プログラム、サービスプログラムまたはデータは遷移先の一例である。
【００５６】
「Ｅｆｆｅｃｔ」（使用可否識別子の一例）、「Ａｃｔｉｏｎ」（使用方法識別子の一例）、「Ｃｏｎｄｉｔｉｏｎ」（ルール条件識別子の一例）はセキュリティポリシー２９１のモデル（図３参照）と同様である。
【００５７】
図１０は、実施の形態１における整合性検証モデル２９３の一例を示す図である。
例えば、整合性検証モデル２９３は、セキュリティポリシー２９１（図５参照）と同様に、ＸＭＬを用いて記述され、ファイルとして記憶される。
【００５８】
図１１は、実施の形態１におけるセキュリティポリシー２９１のモデルと整合性検証モデル２９３との関係を示す対応表である。
セキュリティポリシー２９１のモデル（図３参照）と整合性検証モデル２９３（図９参照）との関係について、図１１に基づいて説明する。
【００５９】
セキュリティポリシー２９１のモデルの要素（または属性）と、整合性検証モデル２９３の要素（または属性）とは、図１１に示すように対応する。
【００６０】
つまり、整合性検証モデル２９３の「Ｍｏｄｅｌ」は、セキュリティポリシー２９１の「ＰｏｌｉｃｙＳｅｔ」に対応する。
同様に、整合性検証モデル２９３の「Ｍｏｄｅｌ」「Ｒｕｌｅ」「Ｅｆｆｅｃｔ」「Ｆｒｏｍ」「Ｔｏ」「Ａｃｔｉｏｎ」「Ｃｏｎｄｉｔｉｏｎ」は、セキュリティポリシー２９１の「Ｐｏｌｉｃｙ」「Ｅｆｆｅｃｔ」「Ｓｕｂｊｅｃｔ」「Ｒｅｓｏｕｒｃｅ」「Ａｃｔｉｏｎ」「Ｃｏｎｄｉｔｉｏｎ」に対応する。
【００６１】
整合性検証モデル２９３は、セキュリティポリシー２９１をアクセス元（Ｓｕｂｊｅｃｔ）とアクセス先（Ｒｅｓｏｕｒｃｅ）との組み合わせ毎に分解したものである。
【００６２】
図１２は、実施の形態１におけるポリシー検証装置２００のポリシー検証方法を示すフローチャートである。
実施の形態１におけるポリシー検証装置２００のポリシー検証方法（ルール検証方法、ルール検証プログラムＮ一例）について、図１２に基づいて説明する。
【００６３】
Ｓ１１０において、モデル生成部２１０は、セキュリティポリシー２９１と依存関係情報２９２とを比較する。
ここで、依存関係情報２９２の依存元と依存先との組み合わせに対応するアクセス元とアクセス先との組み合わせを有するセキュリティポリシー２９１が存在しない場合、その依存関係情報２９２に対応するセキュリティポリシーが不足している。
そこで、モデル生成部２１０は、不足しているセキュリティポリシーを生成することにより、セキュリティポリシー２９１を補完する。
Ｓ１１０の後、Ｓ１２０に進む。
【００６４】
Ｓ１２０において、モデル生成部２１０は、補完したセキュリティポリシー２９１を分解して整合性検証モデル２９３を生成する。
Ｓ１２０の後、Ｓ１３０に進む。
【００６５】
Ｓ１３０において、モデル検証部２２０は、整合性検証モデル２９３を検証し、検証結果データ２９４を生成し、生成した検証結果データ２９４を出力する。
Ｓ１３０により、ポリシー検証方法は終了する。
【００６６】
次に、ポリシー検証方法の各処理（Ｓ１１０−Ｓ１３０）について詳細を説明する。
【００６７】
図１３は、実施の形態１におけるポリシー追加処理（Ｓ１１０）のフローチャートである。
実施の形態１におけるポリシー追加処理（Ｓ１１０）について、図１３に基づいて説明する。
【００６８】
Ｓ１１１において、モデル生成部２１０は、検証装置記憶部２９０から依存関係情報２９２を一つ選択する。
以下、選択した依存関係情報２９２を「選択依存関係」という。
Ｓ１１１の後、Ｓ１１２に進む。
【００６９】
Ｓ１１２において、モデル生成部２１０は、選択依存関係の依存元（Ｄｅｐｅｎｄｅｎｔ）をアクセス元（Ｓｕｂｊｅｃｔ）として有し、選択依存関係の依存先（Ａｎｔｅｃｅｄｅｎｔ）をアクセス先（Ｒｅｓｏｕｒｃｅ）として有するセキュリティポリシー２９１を検索する。
Ｓ１１２の後、Ｓ１１３に進む。
【００７０】
Ｓ１１３において、モデル生成部２１０は、該当するセキュリティポリシー２９１が検索で見つかったか否かを判定する。
該当するセキュリティポリシー２９１が検索で見つかった場合（ＹＥＳ）、Ｓ１１５に進む。
該当するセキュリティポリシー２９１が検索で見つからなかった場合（ＮＯ）、Ｓ１１４に進む。
【００７１】
Ｓ１１４において、モデル生成部２１０は、選択依存関係に対応するセキュリティポリシーを生成し、生成したセキュリティポリシーを検証装置記憶部２９０に新たに記憶する。
【００７２】
図１４は、実施の形態１におけるセキュリティポリシー生成処理（Ｓ１１４）の説明を補足する表である。
選択依存関係に対応するセキュリティポリシーの設定内容について、図１４に基づいて説明する。
【００７３】
（１）モデル生成部２１０は、セキュリティポリシーの「Ｓｕｂｊｅｃｔ」に選択依存関係の「Ｄｅｐｅｎｄｅｎｔ」を設定する。
【００７４】
（２）モデル生成部２１０は、セキュリティポリシーの「Ｒｅｓｏｕｒｃｅ」に選択依存関係の「Ａｎｔｅｃｅｄｅｎｔ」を設定する。
【００７５】
（３）モデル生成部２１０は、セキュリティポリシーの「Ａｃｔｉｏｎ」に全ての操作内容の識別子を設定する。全ての操作内容の識別子はアクションリストとして検証装置記憶部２９０に予め記憶しておく。
【００７６】
（４）モデル生成部２１０は、セキュリティポリシーの「Ｃｏｎｄｉｔｉｏｎ」に適用条件が無いことを示す識別子を設定する。つまり、このセキュリティポリシーは適用条件が無く、常に適用される。
【００７７】
（５）モデル生成部２１０は、セキュリティポリシーの「Ｅｆｆｅｃｔ」に「Ｄｅｎｙ（不許可）」を設定する。
「Ｐｅｒｍｉｔ（許可）」のセキュリティポリシー２９１が定義されていない場合、プログラムやデータの使用は許可されないためである。また、ポリシー管理者が「Ｄｅｎｙ」のセキュリティポリシー２９１を定義せず、セキュリティポリシー２９１の管理を簡略化する場合があるためである。
【００７８】
図１３に戻り、ポリシー追加処理（Ｓ１１０）の説明をＳ１１５から続ける。
【００７９】
Ｓ１１５において、モデル生成部２１０は、未選択の依存関係情報２９２が検証装置記憶部２９０に残っているか否かを判定する。
未選択の依存関係情報２９２が残っている場合（ＹＥＳ）、Ｓ１１１に戻る。
未選択の依存関係情報２９２が残っていない場合（ＮＯ）、ポリシー追加処理（Ｓ１１０）は終了する。
【００８０】
ポリシー追加処理（Ｓ１１０）により、省略されたセキュリティポリシー２９１や定義漏れのセキュリティポリシー２９１を依存関係情報２９２に基づいて生成することができる。
【００８１】
図１５は、実施の形態１におけるモデル生成処理（Ｓ１２０）のフローチャートである。
実施の形態１におけるモデル生成処理（Ｓ１２０）について、図１５に基づいて説明する。
【００８２】
Ｓ１２１において、モデル生成部２１０は、検証装置記憶部２９０からセキュリティポリシー２９１を選択する。選択するセキュリティポリシー２９１には、ポリシー追加処理（Ｓ１１０）で生成したセキュリティポリシーを含む。
以下、選択したセキュリティポリシー２９１を「選択ポリシー」という。
Ｓ１２１の後、Ｓ１２２に進む。
【００８３】
Ｓ１２２において、モデル生成部２１０は、選択ポリシーを「アクセス元（Ｓｕｂｊｅｃｔ）」毎に分解する。
例えば、選択ポリシーの「Ｓｕｂｊｅｃｔ」が２つのアクセス元を含んでいる場合、モデル生成部２１０は、選択ポリシーを２つのセキュリティポリシーに分解する。
Ｓ１２２の後、Ｓ１２３に進む。
【００８４】
Ｓ１２３において、モデル生成部２１０は、Ｓ１２２で得られた各セキュリティポリシーを「アクセス先（Ｒｅｓｏｕｒｃｅ）」毎に分解する。
例えば、各セキュリティポリシーの「Ｒｅｓｏｕｒｃｅ」が３つのアクセス先を含んでいる場合、モデル生成部２１０は、各セキュリティポリシーを３つに分解する。
つまり、選択ポリシーが「Ｓｕｂｊｅｃｔ」に２つのアクセス元を含み、「Ｒｅｓｏｕｒｃｅ」に３つのアクセス先を含んでいる場合、選択ポリシーは６つのセキュリティポリシーに分解される。６つのセキュリティポリシーは、「Ｓｕｂｊｅｃｔ」に１つのアクセス元を含み、「Ｒｅｓｏｕｒｃｅ」に１つのアクセス先を含む。
Ｓ１２３の後、Ｓ１２４に進む。
【００８５】
Ｓ１２４において、モデル生成部２１０は、Ｓ１２３で得られた各セキュリティポリシーを整合性検証モデル２９３のセキュリティルール（図９のＲｕｌｅ）に変換し、変換により得られたセキュリティルールを検証装置記憶部２９０に新たに記憶する。
つまり、Ｓ１２３で６つのセキュリティポリシーが得られた場合、モデル生成部２１０は６つのセキュリティポリシーから６つのセキュリティルールを生成する。
セキュリティポリシーの項目とセキュリティルール（整合性検証モデル２９３）の項目は、図１１に示したように１対１に対応する。
Ｓ１２４の後、Ｓ１２５に進む。
【００８６】
Ｓ１２５において、モデル生成部２１０は、未選択のセキュリティポリシー２９１が検証装置記憶部２９０に残っているか否かを判定する。
未選択のセキュリティポリシー２９１が残っている場合（ＹＥＳ）、Ｓ１２１に戻る。
未選択のセキュリティポリシー２９１が残っていない場合（ＮＯ）、モデル生成処理（Ｓ１２０）は終了する。
【００８７】
モデル生成処理（Ｓ１２０）により、アクセス元とアクセス先とを１つまたは複数有するセキュリティポリシー２９１からアクセス元とアクセス先とを１つずつ有するセキュリティルールを得ることができる。
【００８８】
図１６は、実施の形態１におけるモデル検証処理（Ｓ１３０）のフローチャートである。
実施の形態１におけるモデル検証処理（Ｓ１３０）について、図１６に基づいて説明する。
【００８９】
Ｓ１３１において、モデル検証部２２０は、検証装置記憶部２９０から整合性検証モデル２９３を取得し、整合性検証モデル２９３に含まれる複数のセキュリティルールを参照する。
そして、モデル検証部２２０は、少なくともいずれかのセキュリティルールに設定されている遷移元（Ｆｒｏｍ）を一覧にしてリストを生成する。
以下、遷移元を一覧にしたリストを「サブジェクトリスト」という。
Ｓ１３１の後、Ｓ１３２に進む。
【００９０】
Ｓ１３２において、モデル検証部２２０は、サブジェクトリストから遷移元を選択する。
以下、選択した遷移元を「スタートサブジェクト」という。
Ｓ１３２の後、Ｓ１３３に進む。
【００９１】
Ｓ１３３において、モデル検証部２２０は、スタートサブジェクトからセキュリティルールの遷移先（Ｔｏ）を「深さ優先探索」によって辿り、関連する複数のセキュリティルールを判定する。
そして、モデル検証部２２０は、関連する複数のセキュリティルールを一覧にしてリストを生成する。
以下、関連する複数のセキュリティルールを「ルール集合」といい、関連する複数のセキュリティルールを一覧したリストを「ルールリスト」という。
【００９２】
図１７は、実施の形態１におけるルールリスト生成処理（Ｓ１３３）の概要図である。
実施の形態１におけるルールリスト生成処理（Ｓ１３３）の一例について、図１７に基づいて説明する。
【００９３】
ここで、スタートサブジェクトを“サブジェクト”と記す。
【００９４】
モデル検証部２２０は、“サブジェクト”を検索キーにして、「Ｆｒｏｍ（遷移元）」に“サブジェクト”が設定されているセキュリティルールを検索する。
検索の結果、“ルールＡ”と“ルールＥ”とが該当した。
【００９５】
モデル検証部２２０は、“ルールＡ”の「Ｔｏ（遷移先）」に設定されている“リソースＡ”を検索キーにして、「Ｆｒｏｍ」に“リソースＡ”が設定されているセキュリティルールを検索する。
検索の結果、“ルールＢ”が該当した。
【００９６】
モデル検証部２２０は、“ルールＢ”の「Ｔｏ」に設定されている“リソースＣ”を検索キーにして、「Ｆｒｏｍ」に“リソースＣ”が設定されているセキュリティルールを検索する。
検索の結果、“ルールＣ”と“ルールＧ”とが該当した。
【００９７】
モデル検証部２２０は、“ルールＣ”の「Ｔｏ」に設定されている“リソースＤ”を検索キーとして、「Ｆｒｏｍ」に“リソースＤ”が設定されているセキュリティルールを検索する。
検索の結果、“ルールＤ”が該当した。
【００９８】
モデル検証部２２０は、“ルールＤ”の「Ｔｏ」に設定されている“リソースＦ”を検索キーとして、「Ｆｒｏｍ」に“リソースＦ”が設定されているセキュリティルールを検索する。
検索の結果、該当するセキュリティルールは存在しなかった。したがって、“ルールＤ”が末端のセキュリティルールであり、“リソースＦ”が末端の遷移先である。
【００９９】
末端の遷移先に到達した場合、モデル検証部２２０は、末端の遷移先に到達するまでに検索で見つかったセキュリティルールを検索順に並べてルールリストを生成する。
つまり、モデル検証部２２０は、ルールリスト（１）として「ルールＡ、ルールＢ、ルールＣ、ルールＤ」を設定したファイルを生成する。
【０１００】
以下、スタートサブジェクト（サブジェクト）から末端の遷移先（リソースＦ）までの経路を「遷移ルート」という。
【０１０１】
遷移ルートが途中でループする場合、ループする一つ前の遷移先を末端の遷移先とする。
例えば、「Ｆｒｏｍ」が“リソースＦ”であり、「Ｔｏ」が“リソースＤ”である“ルールＺ”が存在する場合、“ルールＤ”と“ルールＺ”とによって“リソースＤ”と“リソースＦ”との間で遷移ルートがループしてしまう。
この場合、“リソースＦ”が末端の遷移先である。また、“ルールＤ”および“ルールＺ”が末端のセキュリティルールである。
【０１０２】
末端のセキュリティルールに到達した場合、モデル検証部２２０は、末端の遷移先からスタートオブジェクトへ戻りながら、全ての遷移ルートを特定する。
【０１０３】
例えば、モデル検証部２２０は、対象とする遷移先を末端の遷移先“リソースＦ”から一つ前の遷移先“リソースＤ”に戻す。
しかし、「Ｆｒｏｍ」に“リソースＤ”が設定されているセキュリティルールのうち処理していないセキュリティルールは残っていないため、モデル検証部２２０は、対象とする遷移先をさらに一つ前の遷移先“リソースＣ”に戻す。
ここで、「Ｆｒｏｍ」に“リソースＣ”が設定されているセキュリティルールのうち“ルールＧ”が未処理であるため、モデル検証部２２０は、“ルールＧ”を用いて遷移ルートの検索を行う。
【０１０４】
つまり、モデル検証部２２０は、“ルールＧ”の「Ｔｏ」に設定されている“リソースＥ”を検索キーとして、「Ｆｒｏｍ」に“リソースＥ”が設定されているセキュリティルールを検索する。
検索の結果、“ルールＨ”が該当した。また、“ルールＨ”の「Ｔｏ」には“リソースＦ”が設定されているため、“ルールＨ”は末端のセキュリティルールである。
したがって、モデル検証部２２０は、ルールリスト（２）として「ルールＡ、ルールＢ、ルールＧ、ルールＨ」を設定したリストを生成する。
【０１０５】
以後、モデル検証部２２０は、対象とする遷移先を“サブジェクト”まで戻し、“ルールＥ”を用いて遷移ルートの検索を行う。
そして、モデル生成部２１０は、ルールリスト（３）「ルールＥ、ルールＦ、ルールＣ、ルールＤ」と、ルールリスト（４）「ルールＥ、ルールＦ、ルールＧ、ルールＨ」を生成する。
【０１０６】
図１６に戻り、モデル検証処理（Ｓ１３０）の説明をＳ１３４から続ける。
【０１０７】
Ｓ１３４において、モデル検証部２２０は、ルート集合毎に、ルール集合に含まれるセキュリティルールをルールリストに基づいて統合する。
【０１０８】
図１８は、実施の形態１における統合ルール生成処理（Ｓ１３４）のフローチャートである。
実施の形態１における統合ルール生成処理（Ｓ１３４）について、図１８に基づいて説明する。
【０１０９】
モデル検証部２２０は、以下に説明する処理（Ｓ１３４ａ−Ｓ１３４ｇ）をルールリスト（ルール集合）毎に実行する。
【０１１０】
Ｓ１３４ａにおいて、モデル検証部２２０は、ルールリストを複製する。
以下、複製してルールリストを「作業用リスト２８２」という。
Ｓ１３４ａの後、Ｓ１３４ｂに進む。
【０１１１】
Ｓ１３４ｂにおいて、モデル検証部２２０は、作業用リスト２８２を参照し、セキュリティルールを上位から順に選択する。
以下、選択したセキュリティルールを「上位のセキュリティルール」という。
Ｓ１３４ｂの後、Ｓ１３４ｃに進む。
【０１１２】
Ｓ１３４ｃにおいて、モデル検証部２２０は、上位のセキュリティルールの適用結果（Ｅｆｆｅｃｔ）が“Ｐｅｒｍｉｔ（許可）”と“Ｄｅｎｙ（不許可）”とのどちらであるかを判定する。
“Ｐｅｒｍｉｔ”である場合、Ｓ１３４ｄに進む。
“Ｄｅｎｙ”である場合、Ｓ１３４ｅに進む。
【０１１３】
Ｓ１３４ｄにおいて、モデル検証部２２０は、上位のセキュリティルールの適用条件（Ｃｏｎｄｉｔｉｏｎ）を一つ下位のセキュリティルールの適用条件に追加する。
Ｓ１３４ｄの後、Ｓ１３４ｆに進む。
【０１１４】
Ｓ１３４ｅにおいて、モデル検証部２２０は、上位のセキュリティルールの適用条件の否定形を一つ下位のセキュリティルールの適用条件に追加する。
Ｓ１３４ｅの後、Ｓ１３４ｆに進む。
【０１１５】
但し、Ｓ１３４ｄまたはＳ１３４ｅによって、下位のセキュリティルールの適用条件に同じ条件の肯定系と否定形とを含んだ場合、モデル検証部２２０は、以降の処理（Ｓ１３４ｆ，Ｓ１３４ｇ）を行わず、当該ルールリスト（ルール集合）の統合ルール生成処理（Ｓ１３４）を終了してもよい。
【０１１６】
図１９は、実施の形態１における適用条件判定処理（Ｓ１３４ｂ−Ｓ１３４ｆ）の概要図である。
実施の形態１における適用条件判定処理（Ｓ１３４ｂ−Ｓ１３４ｆ）の一例について、図１９に基づいて説明する。
【０１１７】
ここで、セキュリティルールを上位から順に「Ｒｕｌｅ１、Ｒｕｌｅ２、Ｒｕｌｅ３」とする。また、「ＲｕｌｅＸ」（Ｘは整数）の適用条件を「ＣｏｎｄＸ」と記す。
【０１１８】
「Ｒｕｌｅ１」の適用結果が“Ｐｅｒｍｉｔ”である場合、「Ｒｕｌｅ１」の適用条件“Ｃｏｎｄ１”が「Ｒｕｌｅ２」に加わり、「Ｒｕｌｅ２」の適用条件は“Ｃｏｎｄ１＆Ｃｏｎｄ２”になる。
【０１１９】
さらに、「Ｒｕｌｅ２」の適用結果が“Ｐｅｒｍｉｔ”である場合、「Ｒｕｌｅ２」の適用条件“Ｃｏｎｄ１＆Ｃｏｎｄ２”が「Ｒｕｌｅ３」に加わり、「Ｒｕｌｅ３」の適用条件は“Ｃｏｎｄ１＆Ｃｏｎｄ２＆Ｃｏｎｄ３”になる。
【０１２０】
また、「Ｒｕｌｅ１」の適用結果が“Ｄｅｎｙ”である場合、「Ｒｕｌｅ１」の適用条件“Ｃｏｎｄ１”の否定形“ＮｏｔＣｏｎｄ１”が「Ｒｕｌｅ２」に加わり、「Ｒｕｌｅ２」の適用条件は“ＮｏｔＣｏｎｄ１＆Ｃｏｎｄ２”になる。
【０１２１】
さらに、「Ｒｕｌｅ２」の適用結果が“Ｄｅｎｙ”である場合、「Ｒｕｌｅ２」の適用条件“ＮｏｔＣｏｎｄ１＆Ｃｏｎｄ２”の否定形“Ｃｏｎｄ１＆ＮｏｔＣｏｎｄ２”が「Ｒｕｌｅ３」に加わり、「Ｒｕｌｅ３」の適用条件は“Ｃｏｎｄ１＆ＮｏｔＣｏｎｄ２＆Ｃｏｎｄ３”になる。
【０１２２】
図１８に戻り、統合ルール生成処理（Ｓ１３４）の説明をＳ１３４ｆから続ける。
【０１２３】
Ｓ１３４ｆにおいて、モデル検証部２２０は、作業用リスト２８２に下位のセキュリティルールが残っているか否かを判定する。
下位のセキュリティルールが残っている場合（ＹＥＳ）、Ｓ１３４ｂに戻る。
下位のセキュリティルールが残っていない場合（ＮＯ）、Ｓ１３４ｇに戻る。
【０１２４】
Ｓ１３４ｇにおいて、モデル検証部２２０は、作業用リスト２８２に基づいて統合ルール２８１を生成し、生成した統合ルール２８１を検証装置記憶部２９０に記憶する。
統合ルール２８１は、ルール集合に含まれるセキュリティルールを統合した統合ルールを示すデータ（またはファイル）である。
Ｓ１３４ｇにより、統合ルール生成処理（Ｓ１３４）は終了する。
【０１２５】
図２０は、実施の形態１における統合ルール生成処理（Ｓ１３４ｇ）の説明を補足する対応表である。
実施の形態１における統合ルール生成処理（Ｓ１３４ｇ）について、図２０に基づいて説明する。
【０１２６】
（１）モデル検証部２２０は、作業用リスト２８２に設定されているセキュリティルールのうち最上位のセキュリティルールを判定し、最上位のセキュリティルールの依存元（Ｆｒｏｍ）をルール集合の依存元として統合ルール２８１に設定する。
【０１２７】
（２）モデル検証部２２０は、作業用リスト２８２に設定されているセキュリティルールのうち最下位のセキュリティルールを判定し、最下位のセキュリティルールの依存先（Ｔｏ）をルール集合の依存先として統合ルール２８１に設定する。
【０１２８】
（３）モデル検証部２２０は、作業用リスト２８２に設定されている全ての操作内容（Ａｃｔｉｏｎ）をルール集合の操作内容として統合ルール２８１に設定する。
【０１２９】
（４）モデル検証部２２０は、最下位のセキュリティルールの適用条件（Ｃｏｎｄｉｔｉｏｎ）をルール集合の適用条件として統合ルール２８１に設定する。
ここで、最下位のセキュリティルールとは、適用条件判定処理（Ｓ１３４ｂ−Ｓ１３４ｆ）によって上位のセキュリティルールの適用条件（またはその否定形）が追加された後の最下位のセキュリティルールのことである。
【０１３０】
（５）モデル検証部２２０は、最下位のセキュリティルールの適用結果（Ｅｆｆｃｔ）をルール集合の操作内容として統合ルール２８１に設定する。
【０１３１】
図１６に戻り、モデル検証処理（Ｓ１３０）の説明をＳ１３５から続ける。
【０１３２】
Ｓ１３５において、モデル検証部２２０は、ルール集合の組み合わせ毎に統合ルール２８１の整合性を判定する。
Ｓ１３５の後、Ｓ１３６に進む。
【０１３３】
図２１は、実施の形態１における整合性判定処理（Ｓ１３５）のフローチャートである。
実施の形態１における整合性判定処理（Ｓ１３５）について、図２１に基づいて説明する。
【０１３４】
Ｓ１３５ａにおいて、モデル検証部２２０は、Ｓ１３２（図１６参照）で選択したスタートサブジェクトの２つ（または３つ以上）のルール集合を総当たりで組み合わせ、ルール集合の組み合わせリストを生成する。
ルール集合の組み合わせリストとは、ルール集合の組み合わせ毎に、ルール集合の組み合わせを識別する組み合わせ識別子と、ルール集合を識別するルール集合識別子とを対応付けて設定したデータ（またはファイル）である。
Ｓ１３５ａの後、Ｓ１３５ｂに進む。
【０１３５】
Ｓ１３５ｂにおいて、モデル検証部２２０は、ルール集合の組み合わせリストからルール集合の組み合わせを選択する。
以下、選択したルール集合の組み合わせを「選択組み合わせ」という。
Ｓ１３５ｂの後、Ｓ１３５ｃに進む。
【０１３６】
Ｓ１３５ｃにおいて、モデル検証部２２０は、選択組み合わせを構成するルール集合毎にルール集合の統合ルール２８１を検証装置記憶部２９０から取得する。
モデル検証部２２０は、取得した統合ルール２８１を比較し、統合ルール間の整合性を判定する。
【０１３７】
図２２は、実施の形態１における統合ルール２８１の不整合条件を示す表である。
モデル検証部２２０は、図２２に示す不整合条件に基づいて、統合ルール２８１間の整合性を判定する。
つまり、（１）依存先（Ｔｏ）が同じであり、且つ、（２）共通する操作内容（Ａｃｔｉｏｎ）を含み、且つ、不整合条件（３）を満たす場合、モデル検証部２２０は「統合ルール間に整合性がない（不整合である）」と判定する。
不整合条件（３）とは、（Ａ）適用条件（Ｃｏｎｄｉｔｉｏｎ）が異なり又は矛盾することと、（Ｂ）適用結果（Ｅｆｆｅｃｔ）が異なることとの少なくともいずれかを満たす、という条件である。
例えば、一方の統合ルール２８１の適用条件が“Ｃｏｎｄ１”であり、他方の統合ルール２８１の適用条件が“Ｃｏｎｄ２”である場合、適用条件は異なる。
また、一方の統合ルール２８１の適用条件が肯定系“Ｃｏｎｄ１”であり、他方の統合ルール２８１の適用条件が否定形“ＮｏｔＣｏｎｄ１”である場合、適用条件は矛盾する。
【０１３８】
図２１に戻り、整合性判定処理（Ｓ１３５）の説明をＳ１３５ｄから進める。
【０１３９】
Ｓ１３５ｄにおいて、モデル検証部２２０は、判定結果を検証結果データ２９４に設定する。
例えば、モデル検証部２２０は、判定結果（整合、不整合）と、選択組み合わせの組み合わせ識別子とを対応付けて検証結果データ２９４に設定する。
Ｓ１３５ｄの後、Ｓ１３５ｅに進む。
【０１４０】
Ｓ１３５ｅにおいて、モデル検証部２２０は、ルール集合の未選択の組み合わせが残っているか否かを判定する。
未選択の組み合わせが残っている場合（ＹＥＳ）、Ｓ１３５ｂに進む。
未選択の組み合わせが残っていない場合（ＮＯ）、Ｓ１３５ｆに進む。
【０１４１】
Ｓ１３５ｆにおいて、モデル検証部２２０は、検証結果データ２９４を出力する。
例えば、モデル検証部２２０は、検証結果データ２９４に基づいて検証結果画面２８３を生成し、生成した検証結果画面２８３をディスプレイ装置９１１に表示する。
Ｓ１３５ｆにより、整合性判定処理（Ｓ１３５）は終了する。
【０１４２】
図２３は、実施の形態１における検証結果画面２８３の一例を示す図である。
例えば、モデル検証部２２０は、検証結果データ２９４に基づいて図２３に示すような検証結果画面２８３を表示する。
【０１４３】
このとき、モデル検証部２２０は、検証結果データ２９４を参照し、整合性がないルール集合の組み合わせを判定する。以下、整合性がないルール集合の組み合わせを「不整合組み合わせ」という。
モデル検証部２２０は、不整合組み合わせを構成するルール集合のルールリストを検証装置記憶部２９０から取得し、取得したルールリストからルール集合を構成する複数のセキュリティルールを取得する。
そして、モデル検証部２２０は、取得した複数のセキュリティルールに基づいてルール集合の遷移ルートを判定し、判定した遷移ルートを表す画面として検証結果画面２８３を生成し、生成した検証結果画面２８３を表示する。
【０１４４】
図２３の検証結果画面は、“ルールＡ”と“ルールＢ”とから成る第一のルール集合の遷移ルートと、“ルールＣ”と“ルールＤ”とから成る第二のルール集合の遷移ルートとを記すことにより、第一のルール集合と第二のルール集合との組み合わせが「不整合」であることを示している。
【０１４５】
図１６に戻り、モデル検証処理（Ｓ１３０）の説明をＳ１３６から続ける。
【０１４６】
Ｓ１３６において、モデル検証部２２０は、サブジェクトリストに未選択の遷移元（Ｆｒｏｍ）が残っているか否かを判定する。
未選択の遷移元が残っている場合（ＹＥＳ）、Ｓ１３２に戻る。
未選択の遷移元が残っていない場合（ＮＯ）、モデル検証処理（Ｓ１３０）は終了する。
【０１４７】
図２４は、実施の形態１におけるポリシー検証装置２００のハードウェア資源の一例を示す図である。
図２４において、ポリシー検証装置２００は、ＣＰＵ９０１（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）を備えている。ＣＰＵ９０１は、バス９０２を介してＲＯＭ９０３、ＲＡＭ９０４、通信ボード９０５、ディスプレイ装置９１１、キーボード９１２、マウス９１３、ドライブ装置９１４、磁気ディスク装置９２０と接続され、これらのハードウェアデバイスを制御する。ドライブ装置９１４は、ＦＤ（Ｆｌｅｘｉｂｌｅ  Ｄｉｓｋ  Ｄｒｉｖｅ）、ＣＤ（Ｃｏｍｐａｃｔ  Ｄｉｓｃ）、ＤＶＤ（Ｄｉｇｉｔａｌ  Ｖｅｒｓａｔｉｌｅ  Ｄｉｓｃ）などの記憶媒体を読み書きする装置である。
【０１４８】
通信ボード９０５は、有線または無線で、ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、インターネット、電話回線などの通信網に接続している。
【０１４９】
磁気ディスク装置９２０には、ＯＳ９２１（オペレーティングシステム）、プログラム群９２２、ファイル群９２３が記憶されている。
【０１５０】
プログラム群９２２には、実施の形態において「〜部」として説明する機能を実行するプログラムが含まれる。プログラムは、ＣＰＵ９０１により読み出され実行される。すなわち、プログラムは、「〜部」としてコンピュータを機能させるものであり、また「〜部」の手順や方法をコンピュータに実行させるものである。
【０１５１】
ファイル群９２３には、実施の形態において説明する「〜部」で使用される各種データ（入力、出力、判定結果、計算結果、処理結果など）が含まれる。
【０１５２】
実施の形態において構成図およびフローチャートに含まれている矢印は主としてデータや信号の入出力を示す。
【０１５３】
実施の形態において「〜部」として説明するものは「〜回路」、「〜装置」、「〜機器」であってもよく、また「〜ステップ」、「〜手順」、「〜処理」であってもよい。すなわち、「〜部」として説明するものは、ファームウェア、ソフトウェア、ハードウェアまたはこれらの組み合わせのいずれで実装されても構わない。
【０１５４】
実施の形態１により、例えば、以下のような効果を奏することができる。
（１）個別に設定されている複数のレイヤ（例えば、業務、サービス、データ）のポリシーが全体として矛盾しているか否かを検証することができる。
（２）「一般社員の人事秘へのアクセスを禁止する」などの会社規則とシステムのポリシーとが矛盾しているか否かを検証することができる。
（３）同じリソースに対して許可と不許可とを同時に与えてしまうような明らかな矛盾を検出することができる。
（４）適用条件付きのポリシーが特定の条件の場合に矛盾することを検出することができる。
【符号の説明】
【０１５５】
１００  ポリシー検証システム、１０１  検証者、１０２  経営者、１０３  会社規則、１１０  業務ポリシー管理装置、１１９  業務ポリシー、１２０  サービスポリシー管理装置、１２９  サービスポリシー、１３０  データポリシー管理装置、１３９  データポリシー、１４０  依存関係管理装置、１４８  業務関係情報、１４９  サービス関係情報、２００  ポリシー検証装置、２１０  モデル生成部、２２０  モデル検証部、２８１  統合ルール、２８２  作業用リスト、２８３  検証結果画面、２９０  検証装置記憶部、２９１  セキュリティポリシー、２９２  依存関係情報、２９３  整合性検証モデル、２９４  検証結果データ、９０１  ＣＰＵ、９０２  バス、９０３  ＲＯＭ、９０４  ＲＡＭ、９０５  通信ボード、９１１  ディスプレイ装置、９１２  キーボード、９１３  マウス、９１４  ドライブ装置、９２０  磁気ディスク装置、９２１  ＯＳ、９２２  プログラム群、９２３  ファイル群。
【図１】
2012248092.tif 000003
【図２】
2012248092.tif 000004
【図３】
2012248092.tif 000005
【図４】
2012248092.tif 000006
【図５】
2012248092.tif 000007
【図６】
2012248092.tif 000008
【図７】
2012248092.tif 000009
【図８】
2012248092.tif 000010
【図９】
2012248092.tif 000011
【図１０】
2012248092.tif 000012
【図１１】
2012248092.tif 000013
【図１２】
2012248092.tif 000014
【図１３】
2012248092.tif 000015
【図１４】
2012248092.tif 000016
【図１５】
2012248092.tif 000017
【図１６】
2012248092.tif 000018
【図１７】
2012248092.tif 000019
【図１８】
2012248092.tif 000020
【図１９】
2012248092.tif 000021
【図２０】
2012248092.tif 000022
【図２１】
2012248092.tif 000023
【図２２】
2012248092.tif 000024
【図２３】
2012248092.tif 000025
【図２４】
2012248092.tif 000026