"特定のデータと特定のプログラムとのいずれかを対象アクセス先として識別するアクセス先識別子と、対象アクセス先を使用するプログラムを対象アクセス元として識別するアクセス元識別子と、対象アクセス元による対象アクセス先の使用を許可するか否かを識別する使用可否識別子とを含んだ複数のルール情報を記憶するルール情報記憶部と、複数のプログラムと複数のデータとを関連付ける複数の依存関係情報であって、いずれかのプログラムを対象依存元として識別する依存元識別子と、対象依存元に関連付けられるデータまたはプログラムを対象依存先として識別する依存先識別子とを含んだ複数の依存関係情報を記憶する依存関係情報記憶部と、前記依存関係情報記憶部に記憶される依存関係情報毎に依存先識別子と依存元識別子との組み合わせに一致するアクセス先識別子とアクセス元識別子との組み合わせを含んだルール情報が前記ルール情報記憶部に記憶されているか否かを判定し、当該ルール情報が前記ルール情報記憶部に記憶されていない依存関係情報を使用不可関係情報として特定する使用不可関係情報特定部と、前記使用不可関係情報特定部によって特定された使用不可関係情報に基づいて、依存先識別子をアクセス先識別子として含み、依存元識別子をアクセス元識別子として含み、使用不可を示す使用可否識別子を含むルール情報を追加のルール情報として生成するルール情報追加部と、前記ルール情報記憶部に記憶される複数のルール情報と前記ルール情報追加部によって生成された追加のルール情報とに基づいて、前記複数のルール情報が整合しているか否かを検証するルール情報検証部とを備えることを特徴とするルール検証装置。前記複数のルール情報は、自ルール情報が使用される条件をルール条件として識別するルール条件識別子を含み、前記ルール情報検証部は、前記複数のルール情報と前記追加のルール情報とに基づいて特定のアクセス元識別子を含むルール情報を先頭のルール情報として判定し、先頭のルール情報または他のルール情報のアクセス先識別子をアクセス元識別子として含む1つ以上のルール情報を中間のルール情報として判定し、いずれかの中間のルール情報のアクセス先識別子をアクセス元識別子として含み対象アクセス先が無いことを示すアクセス先識別子を含むルール情報を最終のルール情報として判定し、先頭のルール情報と中間のルール情報と最終のルール情報とから成るルール情報の複数の組み合わせを複数のルール情報群として生成し、生成したルール情報群毎に、先頭のルール情報と中間のルール情報と最終のルール情報とのそれぞれの使用可否識別子と、先頭のルール情報と中間のルール情報と最終のルール情報とのそれぞれのルール条件識別子とに基づいて、ルール情報群のルール条件を示すルール条件式と、ルール情報群の使用可否識別子とを判定し、最終のルール情報のアクセス元識別子が一致するルール情報群の組み合わせを判定し、判定したルール情報群の組み合わせのうちルール条件式と使用可否識別子との少なくともいずれかが一致しないルール情報群の組み合わせをルール情報群の不整合な組み合わせとして判定し、判定したルール情報群の不整合な組み合わせを示す検証結果データを生成し、生成した検証結果データを出力することを特徴とする請求項1記載のルール検証装置。前記ルール情報検証部は、ルール情報群毎に、先頭のルール情報と中間のルール情報と最終のルール情報とのうち使用許可を識別する使用可否識別子を含んだルール情報を当該ルール情報群の肯定のルール情報として判定し、ルール情報群毎に、先頭のルール情報と中間のルール情報と最終のルール情報とのうち使用不可を識別する使用可否識別子を含んだルール情報を当該ルール情報群の否定のルール情報として判定し、ルール情報群毎に、肯定のルール情報のルール条件と、否定のルール情報のルール条件を否定するルール条件とを含む式を当該ルール情報群のルール条件式として生成することを特徴とする請求項2記載のルール検証装置。前記ルール情報検証部は、ルール情報群毎に、最終のルール情報の使用可否識別子を当該ルール情報群の使用可否識別子として判定することを特徴とする請求項3記載のルール検証装置。前記ルール情報検証部は、前記最終のルール情報に該当するルール情報が存在しない場合、いずれかの中間のルール情報のアクセス先識別子をアクセス元識別子として含み、先頭のルール情報のアクセス元識別子と中間のルール情報のアクセス元識別子とのいずれかをアクセス先識別子として含むルール情報を最終のルール情報として判定することを特徴とする請求項2から請求項4いずれかに記載のルール検証装置。前記複数のルール情報は、対象アクセス先を使用する使用方法を識別する1つ以上の使用方法識別子を含み、前記ルール情報追加部は、所定の使用方法を識別する1つ以上の使用方法識別子を含んだ追加のルール情報を生成し、前記ルール情報検証部は、最終のルール情報のアクセス元識別子が一致し、少なくともいずれかの使用方法識別子が一致し、ルール条件式と使用可否識別子との少なくともいずれかが一致しないルール情報群の組み合わせをルール情報群の不整合な組み合わせとして判定することを特徴とする請求項2から請求項5いずれかに記載のルール検証装置。特定のデータと特定のプログラムとのいずれかを対象アクセス先として識別するアクセス先識別子と、対象アクセス先を使用するプログラムを対象アクセス元として識別するアクセス元識別子と、対象アクセス元による対象アクセス先の使用を許可するか否かを識別する使用可否識別子とを含んだ複数のルール情報を記憶するルール情報記憶部と、複数のプログラムと複数のデータとを関連付ける複数の依存関係情報であって、いずれかのプログラムを対象依存元として識別する依存元識別子と、対象依存元に関連付けられるデータまたはプログラムを対象依存先として識別する依存先識別子とを含んだ複数の依存関係情報を記憶する依存関係情報記憶部と、使用不可関係情報特定部と、ルール情報追加部と、ルール情報検証部とを備えるルール検証装置のルール検証方法であって、前記使用不可関係情報特定部が、前記依存関係情報記憶部に記憶される依存関係情報毎に依存先識別子と依存元識別子との組み合わせに一致するアクセス先識別子とアクセス元識別子との組み合わせを含んだルール情報が前記ルール情報記憶部に記憶されているか否かを判定し、当該ルール情報が前記ルール情報記憶部に記憶されていない依存関係情報を使用不可関係情報として特定し、前記ルール情報追加部が、前記使用不可関係情報特定部によって特定された使用不可関係情報に基づいて、依存先識別子をアクセス先識別子として含み、依存元識別子をアクセス元識別子として含み、使用不可を示す使用可否識別子を含むルール情報を追加のルール情報として生成し、前記ルール情報検証部が、前記ルール情報記憶部に記憶される複数のルール情報と前記ルール情報追加部によって生成された追加のルール情報とに基づいて、前記複数のルール情報が整合しているか否かを検証することを特徴とするルール検証装置のルール検証方法。特定のデータと特定のプログラムとのいずれかを対象アクセス先として識別するアクセス先識別子と、対象アクセス先を使用するプログラムを対象アクセス元として識別するアクセス元識別子と、対象アクセス元による対象アクセス先の使用を許可するか否かを識別する使用可否識別子とを含んだ複数のルール情報を記憶するルール情報記憶部と、複数のプログラムと複数のデータとを関連付ける複数の依存関係情報であって、いずれかのプログラムを対象依存元として識別する依存元識別子と、対象依存元に関連付けられるデータまたはプログラムを対象依存先として識別する依存先識別子とを含んだ複数の依存関係情報を記憶する依存関係情報記憶部とを備えるルール検証装置を機能させるルール検証プログラムであって、前記依存関係情報記憶部に記憶される依存関係情報毎に依存先識別子と依存元識別子との組み合わせに一致するアクセス先識別子とアクセス元識別子との組み合わせを含んだルール情報が前記ルール情報記憶部に記憶されているか否かを判定し、当該ルール情報が前記ルール情報記憶部に記憶されていない依存関係情報を使用不可関係情報として特定する使用不可関係情報特定部と、前記使用不可関係情報特定部によって特定された使用不可関係情報に基づいて、依存先識別子をアクセス先識別子として含み、依存元識別子をアクセス元識別子として含み、使用不可を示す使用可否識別子を含むルール情報を追加のルール情報として生成するルール情報追加部と、前記ルール情報記憶部に記憶される複数のルール情報と前記ルール情報追加部によって生成された追加のルール情報とに基づいて、前記複数のルール情報が整合しているか否かを検証するルール情報検証部としてルール検証装置を機能させることを特徴とするルール検証プログラム。特許文献1の技術には、目標を達成しているかを検証することはできるが、ポリシー同士の整合性を検証することができないという課題がある。ポリシー同士の整合性を検証するためには、ポリシー全体の関係を把握する必要があり、業務やサービスの依存関係の情報が必要となるが、特許文献1の技術では依存関係情報に基づいた検証を行っていないからである。本発明は、例えば、複数のレイヤ例えば、アプリケーション、サービス、データのセキュリティポリシーの関連を考慮してセキュリティポリシー間の整合性を検証できるようにすることを目的とする。本発明のルール検証装置は、特定のデータと特定のプログラムとのいずれかを対象アクセス先として識別するアクセス先識別子と、対象アクセス先を使用するプログラムを対象アクセス元として識別するアクセス元識別子と、対象アクセス元による対象アクセス先の使用を許可するか否かを識別する使用可否識別子とを含んだ複数のルール情報を記憶するルール情報記憶部と、複数のプログラムと複数のデータとを関連付ける複数の依存関係情報であって、いずれかのプログラムを対象依存元として識別する依存元識別子と、対象依存元に関連付けられるデータまたはプログラムを対象依存先として識別する依存先識別子とを含んだ複数の依存関係情報を記憶する依存関係情報記憶部と、前記依存関係情報記憶部に記憶される依存関係情報毎に依存先識別子と依存元識別子との組み合わせに一致するアクセス先識別子とアクセス元識別子との組み合わせを含んだルール情報が前記ルール情報記憶部に記憶されているか否かを判定し、当該ルール情報が前記ルール情報記憶部に記憶されていない依存関係情報を使用不可関係情報として特定する使用不可関係情報特定部と、前記使用不可関係情報特定部によって特定された使用不可関係情報に基づいて、依存先識別子をアクセス先識別子として含み、依存元識別子をアクセス元識別子として含み、使用不可を示す使用可否識別子を含むルール情報を追加のルール情報として生成するルール情報追加部と、前記ルール情報記憶部に記憶される複数のルール情報と前記ルール情報追加部によって生成された追加のルール情報とに基づいて、前記複数のルール情報が整合しているか否かを検証するルール情報検証部とを備える。本発明によれば、例えば、複数のレイヤ例えば、アプリケーション、サービス、データのセキュリティポリシールール情報の関連依存関係情報を考慮してセキュリティポリシー間の整合性を検証することができる。実施の形態1.各種のポリシーの整合性を検証するシステムの形態について説明する。ポリシーとは、プログラムやデータを使用するための規則を定義したものである。図1は、実施の形態1におけるポリシー検証システム100の構成図である。実施の形態1におけるポリシー検証システム100の構成について、図1に基づいて説明する。ポリシー検証システム100は、ポリシー検証装置200ルール検証装置の一例と、業務ポリシー管理装置110と、サービスポリシー管理装置120と、データポリシー管理装置130と、依存関係管理装置140とを備える。ポリシー検証装置200は、ディスプレイ装置911、キーボード912、記憶装置図示省略、通信装置図示省略などのハードウェアを備える。各ポリシー管理装置符号110,120,130,140および依存関係管理装置140は、ポリシー検証装置200と同様に、各種ハードウェアを備える。ポリシーを管理する管理者図示省略は、ポリシー管理装置符号110,120を用いてポリシーを生成する。例えば、業務に関するポリシー業務ポリシー119を管理する管理者は、業務ポリシー管理装置110の入力装置例えば、キーボードを操作して業務ポリシー119に設定する事項を入力する。業務ポリシー管理装置110のポリシー生成部図示省略は、入力された事項を設定したデータファイルともいうを業務ポリシー119として生成し、生成した業務ポリシー119を記憶装置に記憶する。データとプログラムとの依存関係を管理する管理者図示省略は、依存関係管理装置140を用いて依存関係を定義した依存関係情報例えば、業務関係情報148、サービス関係情報149を生成する。例えば、管理者は、依存関係管理装置140の入力装置を操作して、業務に関する依存関係やサービスに関する依存関係を入力する。依存関係管理装置140は、入力された依存関係を設定したデータファイルともいうを業務関係情報148またはサービス関係情報149として生成し、生成した業務関係情報148またはサービス関係情報149を記憶装置に記憶する。検証者101は、業務ポリシー119とサービスポリシー129とデータポリシー139とを各ポリシー管理装置から記憶媒体例えば、USBメモリにコピーする。さらに、検証者101は、依存関係管理装置140から業務関係情報148とサービス関係情報149とを記憶媒体にコピーする。検証者101は、記憶媒体を用いて、業務ポリシー119とサービスポリシー129とデータポリシー139とをポリシー検証装置200の記憶装置に記憶する。さらに、検証者101は、記憶媒体を用いて、業務関係情報148とサービス関係情報149とをポリシー検証装置200の記憶装置に記憶する。また、検証者101は、経営者102が定めた会社規則103などに基づいてポリシー検証装置200に新たなポリシーに設定する事項を入力しても構わない。この場合、ポリシー検証装置200のポリシー生成部図示省略は、入力された事項を設定して新たなポリシーを生成し、生成したポリシーを記憶装置に記憶する。検証者101は、ポリシー検証装置200の入力装置例えば、キーボード912を操作してポリシー検証プログラムルール検証プログラムの一例を起動する。ポリシー検証装置200は、ポリシー検証プログラムを実行する。これにより、業務ポリシー119とサービスポリシー129とデータポリシー139との整合性が業務関係情報148とサービス関係情報149とを用いて検証され、検証結果が出力される。以下、業務ポリシー119、サービスポリシー129、データポリシー139およびその他のポリシーを総称してセキュリティポリシーという。また、業務関係情報148、サービス関係情報149およびその他の依存関係情報を総称して依存関係情報という。図2は、実施の形態1におけるポリシー検証装置200の機能構成図である。実施の形態1におけるポリシー検証装置200の機能構成について、図2に基づいて説明する。ポリシー検証装置200ルール検証装置の一例は、モデル生成部210使用不可関係情報特定部、ルール情報追加部の一例と、モデル検証部220ルール情報検証部の一例と、検証装置記憶部290ルール情報記憶部、依存関係情報記憶部の一例とを備える。検証装置記憶部290は、ポリシー検証装置200が使用するデータを記憶する。セキュリティポリシー291ポリシー情報、ルール情報の一例、依存関係情報292依存関係情報の一例、整合性検証モデル293ルール情報、検証結果データ294は、検証装置記憶部290に記憶するデータの一例である。セキュリティポリシー291は、1つ以上のアクセス先識別子後述するResourceまたはToと、1つ以上のアクセス元識別子後述するSubjectまたはFromと、1つの使用可否識別子後述するEffectと、1つ以上のルール条件識別子後述するConditionと、1つ以上の使用方法識別子後述するActionを含んだデータまたはファイルである。アクセス先識別子は、特定のデータと特定のプログラムとのいずれかを対象アクセス先またはアクセス先として識別する。アクセス元識別子は、対象アクセス先を使用するプログラムを対象アクセス元またはアクセス元として識別する。使用可否識別子は、対象アクセス元による対象アクセス先の使用を許可するか否かを識別する。ルール条件識別子は、自己のセキュリティポリシー291が使用される条件をルール条件または適用条件として識別する。使用方法識別子は、対象アクセス先を使用する使用方法または操作内容を識別する。依存関係情報292は、複数のプログラムと複数のデータとを関連付けるデータまたはファイルである。依存関係情報292は、依存元識別子後述するDependentと、依存先識別子後述するAntecedentとを含む。依存元識別子は、いずれかのプログラムを対象依存元または依存元として識別する。依存先識別子は、対象依存元に関連付けられるデータまたはプログラムを対象依存先または依存先として識別する。整合性検証モデル293は、アクセス先識別子とアクセス元識別子との組み合わせ毎に分解した複数のセキュリティポリシー291後述するセキュリティルールを有するデータまたはファイルである。検証結果データ294は、整合性検証モデル293を検証した結果を示すデータである。モデル生成部210は、依存関係情報292毎に依存先識別子と依存元識別子との組み合わせに一致するアクセス先識別子とアクセス元識別子との組み合わせを含んだセキュリティルールが記憶されているか否かを判定する。モデル生成部210は、当該セキュリティルールが記憶されていない依存関係情報292を使用不可関係情報として特定する使用不可関係情報特定処理。モデル生成部210は、使用不可関係情報に基づいて、依存先識別子をアクセス先識別子として含み、依存元識別子をアクセス元識別子として含み、使用不可後述するDenyを示す使用可否識別子を含み、所定の使用方法を識別する1つ以上の使用方法識別子とを含むセキュリティルールを追加のセキュリティルールとして生成するルール情報追加処理。モデル検証部220は、検証装置記憶部290に記憶される複数のセキュリティルールとモデル生成部210によって生成された追加のセキュリティルールとに基づいて、複数のセキュリティルールが整合しているか否かを検証するルール情報検証処理。例えば、モデル検証部220は、以下のように複数のセキュリティルールを検証する。モデル検証部220は、複数のセキュリティルールと追加のセキュリティルールとに基づいて特定のアクセス元識別子を含むセキュリティルールを先頭のセキュリティルールとして判定する。モデル検証部220は、先頭のセキュリティルールまたは他のセキュリティルールのアクセス先識別子をアクセス元識別子として含む1つ以上のセキュリティルールを中間のセキュリティルールとして判定する。モデル検証部220は、いずれかの中間のセキュリティルールのアクセス先識別子をアクセス元識別子として含み対象アクセス先が無いことを示すアクセス先識別子を含むセキュリティルールを最終のセキュリティルールとして判定する。但し、当該セキュリティルールが存在しない場合、いずれかの中間のセキュリティルールのアクセス先識別子をアクセス元識別子として含み先頭のセキュリティルールのアクセス元識別子と中間のセキュリティルールのアクセス元識別子とのいずれかを含むセキュリティルールを最終のセキュリティルールとして判定する。モデル検証部220は、先頭のセキュリティルールと中間のセキュリティルールと最終のセキュリティルールとから成るセキュリティルールの複数の組み合わせを複数のルール集合ルール情報群の一例として生成する。モデル検証部220は、生成したルール集合毎に、先頭のセキュリティルールと中間のセキュリティルールと最終のセキュリティルールとのそれぞれの使用可否識別子と、先頭のセキュリティルールと中間のセキュリティルールと最終のセキュリティルールとのそれぞれのルール条件識別子とに基づいて、ルール集合のルール条件を示すルール条件式と、ルール集合の使用可否識別子とを判定する。モデル検証部220は、最終のセキュリティルールのアクセス元識別子が一致し、少なくともいずれかの使用方法識別子が一致するルール集合の組み合わせを判定する。モデル検証部220は、判定したルール集合の組み合わせのうちルール条件式と使用可否識別子との少なくともいずれかが一致しないルール集合の組み合わせをルール集合の不整合な組み合わせとして判定する。モデル検証部220は、判定したルール集合の不整合な組み合わせを示す検証結果データ294を生成し、生成した検証結果データ294を出力する。例えば、モデル検証部220は、以下のようにルール集合のルール条件式を生成する。モデル検証部220は、ルール集合毎に、先頭のセキュリティルールと中間のセキュリティルールと最終のセキュリティルールとのうち使用許可を識別する使用可否識別子後述するPermitを含んだセキュリティルールを当該ルール集合の肯定のセキュリティルールとして判定する。モデル検証部220は、ルール集合毎に、先頭のセキュリティルールと中間のセキュリティルールと最終のセキュリティルールとのうち使用不可を識別する使用可否識別子後述するDenyを含んだセキュリティルールを当該ルール集合の否定のセキュリティルールとして判定する。モデル検証部220は、ルール集合毎に、肯定のセキュリティルールのルール条件と否定のセキュリティルールのルール条件を否定するルール条件とを含む式を当該ルール集合のルール条件式として生成する。例えば、モデル検証部220は、以下のようにルール集合の使用可否識別子を判定する。モデル検証部220は、ルール集合毎に、最終のセキュリティルールの使用可否識別子を当該ルール集合の使用可否識別子として判定する。図3は、実施の形態1におけるセキュリティポリシー291のモデルを示すインスタンス図である。実施の形態1におけるセキュリティポリシー291のデータ構造について、図3に基づいて説明する。ここで、セキュリティポリシー291の集合体をPolicySetポリシーセットと記す。PolicySetは、0個以上のセキュリティポリシー291を有する。Policyポリシーは、セキュリティポリシー291を識別する識別子を示す。Policyポリシー情報、ルール情報の一例は、属性としてEffectエフェクトを有する。Effect使用可否識別子の一例は、Permit許可またはDeny不許可を示す。Policyは、子要素としてSubjectサブジェクトと、Resourceリソースと、Actionアクションと、Conditionコンディションとを有する。Subjectアクセス元識別子の一例は、1つ以上のアクセス元の識別子を示す。アプリケーションプログラム、業務プログラム、サービスプログラムまたはユーザはアクセス元の一例である。Resourceアクセス先識別子の一例は、1つ以上のアクセス先の識別子を示す。アプリケーションプログラム、業務プログラム、サービスプログラムまたはデータはアクセス先の一例である。アクセス元はアクセス先を操作する。Action使用方法識別子の一例は、1つ以上の操作内容の識別子を示す。読み取り、書き込み、呼び出しまたは複製は操作内容の一例である。Conditionルール条件識別子の一例は、Policyを適用する0個以上の識別子を示す。年度、業務の種類または部署は適用条件の一例である。図4は、実施の形態1におけるセキュリティポリシー291のSubjectとResourceとの関係を示すベン図である。アクセス先であるアプリケーションプログラム、業務プログラム、サービスプログラムまたはユーザは、他のプログラムやデータにアクセスするアクセス元にもなるため、アクセス元Subjectとアクセス先Resourceとは部分的に重複する図4参照。図5は、実施の形態1におけるセキュリティポリシー291の一例を示す図である。例えば、セキュリティポリシー291は、図5に示すようにXMLExtensibleMarkupLanguageを用いて記述され、ファイルとして記憶される。セキュリティポリシー291の要素または属性は、タグ<>を用いて記される。図6は、実施の形態1における依存関係情報292のモデルを示すインスタンス図である。実施の形態1における依存関係情報292のデータ構造について、図6に基づいて説明する。ここで、依存関係情報292の集合体をDependencySetディペンデンシーセットと記す。DependencySetは、0個以上の依存関係情報292を有する。Dependencyディペンデンシーは、依存関係情報292を識別する識別子を示す。Dependency依存関係情報の一例は、子要素としてDependentディペンデントと、Antecedentアンティシーデントとを有する。Dependent依存元識別子の一例は、1つの依存元の識別子を示す。アプリケーションプログラム、業務プログラム、サービスプログラムまたはユーザは依存元の一例である。Antecedent依存先識別子の一例は、0個以上の依存先の識別子を示す。アプリケーションプログラム、業務プログラム、サービスプログラムまたはデータは依存先の一例である。依存元と依存先とは互いに関連する。図7は、実施の形態1における依存関係情報292のDependentとAntecedentとの関係を示すベン図である。依存先であるアプリケーションプログラム、業務プログラム、サービスプログラムまたはユーザは、他のプログラムやデータと関連する依存元にもなるため、依存元Dependentと依存先Antecedentとは部分的に重複する図7参照。図8は、実施の形態1における依存関係情報292の一例を示す図である。例えば、依存関係情報292は、図8に示すようにXMLを用いて記述され、ファイルとして記憶される。依存関係情報292の要素はタグを用いて記される。図9は、実施の形態1における整合性検証モデル293を示すインスタンス図である。実施の形態1における整合性検証モデル293のデータ構造について、図9に基づいて説明する。ここで、整合性検証モデル293をModelモデルと記す。Modelは、0個以上のセキュリティルールを有する。Ruleルールは、セキュリティルールを識別する識別子を示す。Ruleルール情報の一例は、属性としてEffectを有する。Ruleは、子要素としてFromと、Toと、Actionと、Conditionとを有する。Fromアクセス元識別子の一例は、1つの遷移元の識別子を示す。アプリケーションプログラム、業務プログラム、サービスプログラムまたはユーザは遷移元の一例である。Toアクセス先識別子の一例は、1つの遷移先の識別子を示す。アプリケーションプログラム、業務プログラム、サービスプログラムまたはデータは遷移先の一例である。Effect使用可否識別子の一例、Action使用方法識別子の一例、Conditionルール条件識別子の一例はセキュリティポリシー291のモデル図3参照と同様である。図10は、実施の形態1における整合性検証モデル293の一例を示す図である。例えば、整合性検証モデル293は、セキュリティポリシー291図5参照と同様に、XMLを用いて記述され、ファイルとして記憶される。図11は、実施の形態1におけるセキュリティポリシー291のモデルと整合性検証モデル293との関係を示す対応表である。セキュリティポリシー291のモデル図3参照と整合性検証モデル293図9参照との関係について、図11に基づいて説明する。セキュリティポリシー291のモデルの要素または属性と、整合性検証モデル293の要素または属性とは、図11に示すように対応する。つまり、整合性検証モデル293のModelは、セキュリティポリシー291のPolicySetに対応する。同様に、整合性検証モデル293のModelRuleEffectFromToActionConditionは、セキュリティポリシー291のPolicyEffectSubjectResourceActionConditionに対応する。整合性検証モデル293は、セキュリティポリシー291をアクセス元Subjectとアクセス先Resourceとの組み合わせ毎に分解したものである。図12は、実施の形態1におけるポリシー検証装置200のポリシー検証方法を示すフローチャートである。実施の形態1におけるポリシー検証装置200のポリシー検証方法ルール検証方法、ルール検証プログラムN一例について、図12に基づいて説明する。S110において、モデル生成部210は、セキュリティポリシー291と依存関係情報292とを比較する。ここで、依存関係情報292の依存元と依存先との組み合わせに対応するアクセス元とアクセス先との組み合わせを有するセキュリティポリシー291が存在しない場合、その依存関係情報292に対応するセキュリティポリシーが不足している。そこで、モデル生成部210は、不足しているセキュリティポリシーを生成することにより、セキュリティポリシー291を補完する。S110の後、S120に進む。S120において、モデル生成部210は、補完したセキュリティポリシー291を分解して整合性検証モデル293を生成する。S120の後、S130に進む。S130において、モデル検証部220は、整合性検証モデル293を検証し、検証結果データ294を生成し、生成した検証結果データ294を出力する。S130により、ポリシー検証方法は終了する。次に、ポリシー検証方法の各処理S110-S130について詳細を説明する。図13は、実施の形態1におけるポリシー追加処理S110のフローチャートである。実施の形態1におけるポリシー追加処理S110について、図13に基づいて説明する。S111において、モデル生成部210は、検証装置記憶部290から依存関係情報292を一つ選択する。以下、選択した依存関係情報292を選択依存関係という。S111の後、S112に進む。S112において、モデル生成部210は、選択依存関係の依存元Dependentをアクセス元Subjectとして有し、選択依存関係の依存先Antecedentをアクセス先Resourceとして有するセキュリティポリシー291を検索する。S112の後、S113に進む。S113において、モデル生成部210は、該当するセキュリティポリシー291が検索で見つかったか否かを判定する。該当するセキュリティポリシー291が検索で見つかった場合YES、S115に進む。該当するセキュリティポリシー291が検索で見つからなかった場合NO、S114に進む。S114において、モデル生成部210は、選択依存関係に対応するセキュリティポリシーを生成し、生成したセキュリティポリシーを検証装置記憶部290に新たに記憶する。図14は、実施の形態1におけるセキュリティポリシー生成処理S114の説明を補足する表である。選択依存関係に対応するセキュリティポリシーの設定内容について、図14に基づいて説明する。1モデル生成部210は、セキュリティポリシーのSubjectに選択依存関係のDependentを設定する。2モデル生成部210は、セキュリティポリシーのResourceに選択依存関係のAntecedentを設定する。3モデル生成部210は、セキュリティポリシーのActionに全ての操作内容の識別子を設定する。全ての操作内容の識別子はアクションリストとして検証装置記憶部290に予め記憶しておく。4モデル生成部210は、セキュリティポリシーのConditionに適用条件が無いことを示す識別子を設定する。つまり、このセキュリティポリシーは適用条件が無く、常に適用される。5モデル生成部210は、セキュリティポリシーのEffectにDeny不許可を設定する。Permit許可のセキュリティポリシー291が定義されていない場合、プログラムやデータの使用は許可されないためである。また、ポリシー管理者がDenyのセキュリティポリシー291を定義せず、セキュリティポリシー291の管理を簡略化する場合があるためである。図13に戻り、ポリシー追加処理S110の説明をS115から続ける。S115において、モデル生成部210は、未選択の依存関係情報292が検証装置記憶部290に残っているか否かを判定する。未選択の依存関係情報292が残っている場合YES、S111に戻る。未選択の依存関係情報292が残っていない場合NO、ポリシー追加処理S110は終了する。ポリシー追加処理S110により、省略されたセキュリティポリシー291や定義漏れのセキュリティポリシー291を依存関係情報292に基づいて生成することができる。図15は、実施の形態1におけるモデル生成処理S120のフローチャートである。実施の形態1におけるモデル生成処理S120について、図15に基づいて説明する。S121において、モデル生成部210は、検証装置記憶部290からセキュリティポリシー291を選択する。選択するセキュリティポリシー291には、ポリシー追加処理S110で生成したセキュリティポリシーを含む。以下、選択したセキュリティポリシー291を選択ポリシーという。S121の後、S122に進む。S122において、モデル生成部210は、選択ポリシーをアクセス元Subject毎に分解する。例えば、選択ポリシーのSubjectが2つのアクセス元を含んでいる場合、モデル生成部210は、選択ポリシーを2つのセキュリティポリシーに分解する。S122の後、S123に進む。S123において、モデル生成部210は、S122で得られた各セキュリティポリシーをアクセス先Resource毎に分解する。例えば、各セキュリティポリシーのResourceが3つのアクセス先を含んでいる場合、モデル生成部210は、各セキュリティポリシーを3つに分解する。つまり、選択ポリシーがSubjectに2つのアクセス元を含み、Resourceに3つのアクセス先を含んでいる場合、選択ポリシーは6つのセキュリティポリシーに分解される。6つのセキュリティポリシーは、Subjectに1つのアクセス元を含み、Resourceに1つのアクセス先を含む。S123の後、S124に進む。S124において、モデル生成部210は、S123で得られた各セキュリティポリシーを整合性検証モデル293のセキュリティルール図9のRuleに変換し、変換により得られたセキュリティルールを検証装置記憶部290に新たに記憶する。つまり、S123で6つのセキュリティポリシーが得られた場合、モデル生成部210は6つのセキュリティポリシーから6つのセキュリティルールを生成する。セキュリティポリシーの項目とセキュリティルール整合性検証モデル293の項目は、図11に示したように1対1に対応する。S124の後、S125に進む。S125において、モデル生成部210は、未選択のセキュリティポリシー291が検証装置記憶部290に残っているか否かを判定する。未選択のセキュリティポリシー291が残っている場合YES、S121に戻る。未選択のセキュリティポリシー291が残っていない場合NO、モデル生成処理S120は終了する。モデル生成処理S120により、アクセス元とアクセス先とを1つまたは複数有するセキュリティポリシー291からアクセス元とアクセス先とを1つずつ有するセキュリティルールを得ることができる。図16は、実施の形態1におけるモデル検証処理S130のフローチャートである。実施の形態1におけるモデル検証処理S130について、図16に基づいて説明する。S131において、モデル検証部220は、検証装置記憶部290から整合性検証モデル293を取得し、整合性検証モデル293に含まれる複数のセキュリティルールを参照する。そして、モデル検証部220は、少なくともいずれかのセキュリティルールに設定されている遷移元Fromを一覧にしてリストを生成する。以下、遷移元を一覧にしたリストをサブジェクトリストという。S131の後、S132に進む。S132において、モデル検証部220は、サブジェクトリストから遷移元を選択する。以下、選択した遷移元をスタートサブジェクトという。S132の後、S133に進む。S133において、モデル検証部220は、スタートサブジェクトからセキュリティルールの遷移先Toを深さ優先探索によって辿り、関連する複数のセキュリティルールを判定する。そして、モデル検証部220は、関連する複数のセキュリティルールを一覧にしてリストを生成する。以下、関連する複数のセキュリティルールをルール集合といい、関連する複数のセキュリティルールを一覧したリストをルールリストという。図17は、実施の形態1におけるルールリスト生成処理S133の概要図である。実施の形態1におけるルールリスト生成処理S133の一例について、図17に基づいて説明する。ここで、スタートサブジェクトをサブジェクトと記す。モデル検証部220は、サブジェクトを検索キーにして、From遷移元にサブジェクトが設定されているセキュリティルールを検索する。検索の結果、ルールAとルールEとが該当した。モデル検証部220は、ルールAのTo遷移先に設定されているリソースAを検索キーにして、FromにリソースAが設定されているセキュリティルールを検索する。検索の結果、ルールBが該当した。モデル検証部220は、ルールBのToに設定されているリソースCを検索キーにして、FromにリソースCが設定されているセキュリティルールを検索する。検索の結果、ルールCとルールGとが該当した。モデル検証部220は、ルールCのToに設定されているリソースDを検索キーとして、FromにリソースDが設定されているセキュリティルールを検索する。検索の結果、ルールDが該当した。モデル検証部220は、ルールDのToに設定されているリソースFを検索キーとして、FromにリソースFが設定されているセキュリティルールを検索する。検索の結果、該当するセキュリティルールは存在しなかった。したがって、ルールDが末端のセキュリティルールであり、リソースFが末端の遷移先である。末端の遷移先に到達した場合、モデル検証部220は、末端の遷移先に到達するまでに検索で見つかったセキュリティルールを検索順に並べてルールリストを生成する。つまり、モデル検証部220は、ルールリスト1としてルールA、ルールB、ルールC、ルールDを設定したファイルを生成する。以下、スタートサブジェクトサブジェクトから末端の遷移先リソースFまでの経路を遷移ルートという。遷移ルートが途中でループする場合、ループする一つ前の遷移先を末端の遷移先とする。例えば、FromがリソースFであり、ToがリソースDであるルールZが存在する場合、ルールDとルールZとによってリソースDとリソースFとの間で遷移ルートがループしてしまう。この場合、リソースFが末端の遷移先である。また、ルールDおよびルールZが末端のセキュリティルールである。末端のセキュリティルールに到達した場合、モデル検証部220は、末端の遷移先からスタートオブジェクトへ戻りながら、全ての遷移ルートを特定する。例えば、モデル検証部220は、対象とする遷移先を末端の遷移先リソースFから一つ前の遷移先リソースDに戻す。しかし、FromにリソースDが設定されているセキュリティルールのうち処理していないセキュリティルールは残っていないため、モデル検証部220は、対象とする遷移先をさらに一つ前の遷移先リソースCに戻す。ここで、FromにリソースCが設定されているセキュリティルールのうちルールGが未処理であるため、モデル検証部220は、ルールGを用いて遷移ルートの検索を行う。つまり、モデル検証部220は、ルールGのToに設定されているリソースEを検索キーとして、FromにリソースEが設定されているセキュリティルールを検索する。検索の結果、ルールHが該当した。また、ルールHのToにはリソースFが設定されているため、ルールHは末端のセキュリティルールである。したがって、モデル検証部220は、ルールリスト2としてルールA、ルールB、ルールG、ルールHを設定したリストを生成する。以後、モデル検証部220は、対象とする遷移先をサブジェクトまで戻し、ルールEを用いて遷移ルートの検索を行う。そして、モデル生成部210は、ルールリスト3ルールE、ルールF、ルールC、ルールDと、ルールリスト4ルールE、ルールF、ルールG、ルールHを生成する。図16に戻り、モデル検証処理S130の説明をS134から続ける。S134において、モデル検証部220は、ルート集合毎に、ルール集合に含まれるセキュリティルールをルールリストに基づいて統合する。図18は、実施の形態1における統合ルール生成処理S134のフローチャートである。実施の形態1における統合ルール生成処理S134について、図18に基づいて説明する。モデル検証部220は、以下に説明する処理S134a-S134gをルールリストルール集合毎に実行する。S134aにおいて、モデル検証部220は、ルールリストを複製する。以下、複製してルールリストを作業用リスト282という。S134aの後、S134bに進む。S134bにおいて、モデル検証部220は、作業用リスト282を参照し、セキュリティルールを上位から順に選択する。以下、選択したセキュリティルールを上位のセキュリティルールという。S134bの後、S134cに進む。S134cにおいて、モデル検証部220は、上位のセキュリティルールの適用結果EffectがPermit許可とDeny不許可とのどちらであるかを判定する。Permitである場合、S134dに進む。Denyである場合、S134eに進む。S134dにおいて、モデル検証部220は、上位のセキュリティルールの適用条件Conditionを一つ下位のセキュリティルールの適用条件に追加する。S134dの後、S134fに進む。S134eにおいて、モデル検証部220は、上位のセキュリティルールの適用条件の否定形を一つ下位のセキュリティルールの適用条件に追加する。S134eの後、S134fに進む。但し、S134dまたはS134eによって、下位のセキュリティルールの適用条件に同じ条件の肯定系と否定形とを含んだ場合、モデル検証部220は、以降の処理S134f,S134gを行わず、当該ルールリストルール集合の統合ルール生成処理S134を終了してもよい。図19は、実施の形態1における適用条件判定処理S134b-S134fの概要図である。実施の形態1における適用条件判定処理S134b-S134fの一例について、図19に基づいて説明する。ここで、セキュリティルールを上位から順にRule1、Rule2、Rule3とする。また、RuleXXは整数の適用条件をCondXと記す。Rule1の適用結果がPermitである場合、Rule1の適用条件Cond1がRule2に加わり、Rule2の適用条件はCond1Cond2になる。さらに、Rule2の適用結果がPermitである場合、Rule2の適用条件Cond1Cond2がRule3に加わり、Rule3の適用条件はCond1Cond2Cond3になる。また、Rule1の適用結果がDenyである場合、Rule1の適用条件Cond1の否定形NotCond1がRule2に加わり、Rule2の適用条件はNotCond1Cond2になる。さらに、Rule2の適用結果がDenyである場合、Rule2の適用条件NotCond1Cond2の否定形Cond1NotCond2がRule3に加わり、Rule3の適用条件はCond1NotCond2Cond3になる。図18に戻り、統合ルール生成処理S134の説明をS134fから続ける。S134fにおいて、モデル検証部220は、作業用リスト282に下位のセキュリティルールが残っているか否かを判定する。下位のセキュリティルールが残っている場合YES、S134bに戻る。下位のセキュリティルールが残っていない場合NO、S134gに戻る。S134gにおいて、モデル検証部220は、作業用リスト282に基づいて統合ルール281を生成し、生成した統合ルール281を検証装置記憶部290に記憶する。統合ルール281は、ルール集合に含まれるセキュリティルールを統合した統合ルールを示すデータまたはファイルである。S134gにより、統合ルール生成処理S134は終了する。図20は、実施の形態1における統合ルール生成処理S134gの説明を補足する対応表である。実施の形態1における統合ルール生成処理S134gについて、図20に基づいて説明する。1モデル検証部220は、作業用リスト282に設定されているセキュリティルールのうち最上位のセキュリティルールを判定し、最上位のセキュリティルールの依存元Fromをルール集合の依存元として統合ルール281に設定する。2モデル検証部220は、作業用リスト282に設定されているセキュリティルールのうち最下位のセキュリティルールを判定し、最下位のセキュリティルールの依存先Toをルール集合の依存先として統合ルール281に設定する。3モデル検証部220は、作業用リスト282に設定されている全ての操作内容Actionをルール集合の操作内容として統合ルール281に設定する。4モデル検証部220は、最下位のセキュリティルールの適用条件Conditionをルール集合の適用条件として統合ルール281に設定する。ここで、最下位のセキュリティルールとは、適用条件判定処理S134b-S134fによって上位のセキュリティルールの適用条件またはその否定形が追加された後の最下位のセキュリティルールのことである。5モデル検証部220は、最下位のセキュリティルールの適用結果Effctをルール集合の操作内容として統合ルール281に設定する。図16に戻り、モデル検証処理S130の説明をS135から続ける。S135において、モデル検証部220は、ルール集合の組み合わせ毎に統合ルール281の整合性を判定する。S135の後、S136に進む。図21は、実施の形態1における整合性判定処理S135のフローチャートである。実施の形態1における整合性判定処理S135について、図21に基づいて説明する。S135aにおいて、モデル検証部220は、S132図16参照で選択したスタートサブジェクトの2つまたは3つ以上のルール集合を総当たりで組み合わせ、ルール集合の組み合わせリストを生成する。ルール集合の組み合わせリストとは、ルール集合の組み合わせ毎に、ルール集合の組み合わせを識別する組み合わせ識別子と、ルール集合を識別するルール集合識別子とを対応付けて設定したデータまたはファイルである。S135aの後、S135bに進む。S135bにおいて、モデル検証部220は、ルール集合の組み合わせリストからルール集合の組み合わせを選択する。以下、選択したルール集合の組み合わせを選択組み合わせという。S135bの後、S135cに進む。S135cにおいて、モデル検証部220は、選択組み合わせを構成するルール集合毎にルール集合の統合ルール281を検証装置記憶部290から取得する。モデル検証部220は、取得した統合ルール281を比較し、統合ルール間の整合性を判定する。図22は、実施の形態1における統合ルール281の不整合条件を示す表である。モデル検証部220は、図22に示す不整合条件に基づいて、統合ルール281間の整合性を判定する。つまり、1依存先Toが同じであり、且つ、2共通する操作内容Actionを含み、且つ、不整合条件3を満たす場合、モデル検証部220は統合ルール間に整合性がない不整合であると判定する。不整合条件3とは、A適用条件Conditionが異なり又は矛盾することと、B適用結果Effectが異なることとの少なくともいずれかを満たす、という条件である。例えば、一方の統合ルール281の適用条件がCond1であり、他方の統合ルール281の適用条件がCond2である場合、適用条件は異なる。また、一方の統合ルール281の適用条件が肯定系Cond1であり、他方の統合ルール281の適用条件が否定形NotCond1である場合、適用条件は矛盾する。図21に戻り、整合性判定処理S135の説明をS135dから進める。S135dにおいて、モデル検証部220は、判定結果を検証結果データ294に設定する。例えば、モデル検証部220は、判定結果整合、不整合と、選択組み合わせの組み合わせ識別子とを対応付けて検証結果データ294に設定する。S135dの後、S135eに進む。S135eにおいて、モデル検証部220は、ルール集合の未選択の組み合わせが残っているか否かを判定する。未選択の組み合わせが残っている場合YES、S135bに進む。未選択の組み合わせが残っていない場合NO、S135fに進む。S135fにおいて、モデル検証部220は、検証結果データ294を出力する。例えば、モデル検証部220は、検証結果データ294に基づいて検証結果画面283を生成し、生成した検証結果画面283をディスプレイ装置911に表示する。S135fにより、整合性判定処理S135は終了する。図23は、実施の形態1における検証結果画面283の一例を示す図である。例えば、モデル検証部220は、検証結果データ294に基づいて図23に示すような検証結果画面283を表示する。このとき、モデル検証部220は、検証結果データ294を参照し、整合性がないルール集合の組み合わせを判定する。以下、整合性がないルール集合の組み合わせを不整合組み合わせという。モデル検証部220は、不整合組み合わせを構成するルール集合のルールリストを検証装置記憶部290から取得し、取得したルールリストからルール集合を構成する複数のセキュリティルールを取得する。そして、モデル検証部220は、取得した複数のセキュリティルールに基づいてルール集合の遷移ルートを判定し、判定した遷移ルートを表す画面として検証結果画面283を生成し、生成した検証結果画面283を表示する。図23の検証結果画面は、ルールAとルールBとから成る第一のルール集合の遷移ルートと、ルールCとルールDとから成る第二のルール集合の遷移ルートとを記すことにより、第一のルール集合と第二のルール集合との組み合わせが不整合であることを示している。図16に戻り、モデル検証処理S130の説明をS136から続ける。S136において、モデル検証部220は、サブジェクトリストに未選択の遷移元Fromが残っているか否かを判定する。未選択の遷移元が残っている場合YES、S132に戻る。未選択の遷移元が残っていない場合NO、モデル検証処理S130は終了する。図24は、実施の形態1におけるポリシー検証装置200のハードウェア資源の一例を示す図である。図24において、ポリシー検証装置200は、CPU901CentralProcessingUnitを備えている。CPU901は、バス902を介してROM903、RAM904、通信ボード905、ディスプレイ装置911、キーボード912、マウス913、ドライブ装置914、磁気ディスク装置920と接続され、これらのハードウェアデバイスを制御する。ドライブ装置914は、FDFlexibleDiskDrive、CDCompactDisc、DVDDigitalVersatileDiscなどの記憶媒体を読み書きする装置である。通信ボード905は、有線または無線で、LANLocalAreaNetwork、インターネット、電話回線などの通信網に接続している。磁気ディスク装置920には、OS921オペレーティングシステム、プログラム群922、ファイル群923が記憶されている。プログラム群922には、実施の形態において~部として説明する機能を実行するプログラムが含まれる。プログラムは、CPU901により読み出され実行される。すなわち、プログラムは、~部としてコンピュータを機能させるものであり、また~部の手順や方法をコンピュータに実行させるものである。ファイル群923には、実施の形態において説明する~部で使用される各種データ入力、出力、判定結果、計算結果、処理結果などが含まれる。実施の形態において構成図およびフローチャートに含まれている矢印は主としてデータや信号の入出力を示す。実施の形態において~部として説明するものは~回路、~装置、~機器であってもよく、また~ステップ、~手順、~処理であってもよい。すなわち、~部として説明するものは、ファームウェア、ソフトウェア、ハードウェアまたはこれらの組み合わせのいずれで実装されても構わない。実施の形態1により、例えば、以下のような効果を奏することができる。1個別に設定されている複数のレイヤ例えば、業務、サービス、データのポリシーが全体として矛盾しているか否かを検証することができる。2一般社員の人事秘へのアクセスを禁止するなどの会社規則とシステムのポリシーとが矛盾しているか否かを検証することができる。3同じリソースに対して許可と不許可とを同時に与えてしまうような明らかな矛盾を検出することができる。4適用条件付きのポリシーが特定の条件の場合に矛盾することを検出することができる。"