説明

ルール検証装置、ルール検証装置のルール検証方法およびルール検証プログラム

【課題】セキュリティポリシーの関連を考慮してセキュリティポリシー間の整合性を検証できるようにすることを目的とする。
【解決手段】セキュリティポリシー291はアクセス元とアクセス先とアクセス可否との組み合わせを示す。依存関係情報292は依存元と依存先との組み合わせを示す。モデル生成部210は、依存関係情報292に示される依存元と依存先との組み合わせに対応するアクセス元とアクセス先との組み合わせを有するセキュリティポリシー291が存在するか否かを判定する。当該セキュリティポリシー291が存在しない場合、モデル生成部210は、セキュリティポリシー291を補完する。モデル生成部210は、補完したセキュリティポリシー291を分解して整合性検証モデル293を生成する。モデル検証部220は、整合性検証モデル293を検証し、検証結果データ294を生成し、生成した検証結果データ294を出力する。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、例えば、セキュリティポリシーを構成するルールを検証するルール検証装置、ルール検証装置のルール検証方法およびルール検証プログラムに関するものである。
【背景技術】
【0002】
特許文献1には、ポリシーをモデルに変換し、モデルをチェッカー(検証装置)にかけて「ウェブサービス構成のセキュリティチェック」という目標を実現しているか否かを判定する技術が開示されている。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特開2005−322234号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
特許文献1の技術には、「目標」を達成しているかを検証することはできるが、「ポリシー同士」の整合性を検証することができないという課題がある。
ポリシー同士の整合性を検証するためには、ポリシー全体の関係を把握する必要があり、業務やサービスの依存関係の情報が必要となるが、特許文献1の技術では依存関係情報に基づいた検証を行っていないからである。
【0005】
本発明は、例えば、複数のレイヤ(例えば、アプリケーション、サービス、データ)のセキュリティポリシーの関連を考慮してセキュリティポリシー間の整合性を検証できるようにすることを目的とする。
【課題を解決するための手段】
【0006】
本発明のルール検証装置は、
特定のデータと特定のプログラムとのいずれかを対象アクセス先として識別するアクセス先識別子と、対象アクセス先を使用するプログラムを対象アクセス元として識別するアクセス元識別子と、対象アクセス元による対象アクセス先の使用を許可するか否かを識別する使用可否識別子とを含んだ複数のルール情報を記憶するルール情報記憶部と、
複数のプログラムと複数のデータとを関連付ける複数の依存関係情報であって、いずれかのプログラムを対象依存元として識別する依存元識別子と、対象依存元に関連付けられるデータまたはプログラムを対象依存先として識別する依存先識別子とを含んだ複数の依存関係情報を記憶する依存関係情報記憶部と、
前記依存関係情報記憶部に記憶される依存関係情報毎に依存先識別子と依存元識別子との組み合わせに一致するアクセス先識別子とアクセス元識別子との組み合わせを含んだルール情報が前記ルール情報記憶部に記憶されているか否かを判定し、当該ルール情報が前記ルール情報記憶部に記憶されていない依存関係情報を使用不可関係情報として特定する使用不可関係情報特定部と、
前記使用不可関係情報特定部によって特定された使用不可関係情報に基づいて、依存先識別子をアクセス先識別子として含み、依存元識別子をアクセス元識別子として含み、使用不可を示す使用可否識別子を含むルール情報を追加のルール情報として生成するルール情報追加部と、
前記ルール情報記憶部に記憶される複数のルール情報と前記ルール情報追加部によって生成された追加のルール情報とに基づいて、前記複数のルール情報が整合しているか否かを検証するルール情報検証部とを備える。
【発明の効果】
【0007】
本発明によれば、例えば、複数のレイヤ(例えば、アプリケーション、サービス、データ)のセキュリティポリシー(ルール情報)の関連(依存関係情報)を考慮してセキュリティポリシー間の整合性を検証することができる。
【図面の簡単な説明】
【0008】
【図1】実施の形態1におけるポリシー検証システム100の構成図。
【図2】実施の形態1におけるポリシー検証装置200の機能構成図。
【図3】実施の形態1におけるセキュリティポリシー291のモデルを示すインスタンス図。
【図4】実施の形態1におけるセキュリティポリシー291の「Subject」と「Resource」との関係を示すベン図。
【図5】実施の形態1におけるセキュリティポリシー291の一例を示す図。
【図6】実施の形態1における依存関係情報292のモデルを示すインスタンス図。
【図7】実施の形態1における依存関係情報292の「Dependent」と「Antecedent」との関係を示すベン図。
【図8】実施の形態1における依存関係情報292の一例を示す図。
【図9】実施の形態1における整合性検証モデル293を示すインスタンス図。
【図10】実施の形態1における整合性検証モデル293の一例を示す図。
【図11】実施の形態1におけるセキュリティポリシー291のモデルと整合性検証モデル293との関係を示す対応表。
【図12】実施の形態1におけるポリシー検証装置200のポリシー検証方法を示すフローチャート。
【図13】実施の形態1におけるポリシー追加処理(S110)のフローチャート。
【図14】実施の形態1におけるセキュリティポリシー生成処理(S114)の説明を補足する表。
【図15】実施の形態1におけるモデル生成処理(S120)のフローチャート。
【図16】実施の形態1におけるモデル検証処理(S130)のフローチャート。
【図17】実施の形態1におけるルールリスト生成処理(S133)の概要図。
【図18】実施の形態1における統合ルール生成処理(S134)のフローチャート。
【図19】実施の形態1における適用条件判定処理(S134b−S134f)の概要図。
【図20】実施の形態1における統合ルール生成処理(S134g)の説明を補足する対応表。
【図21】実施の形態1における整合性判定処理(S135)のフローチャート。
【図22】実施の形態1における統合ルール281の不整合条件を示す表。
【図23】実施の形態1における検証結果画面283の一例を示す図。
【図24】実施の形態1におけるポリシー検証装置200のハードウェア資源の一例を示す図。
【発明を実施するための形態】
【0009】
実施の形態1.
各種のポリシーの整合性を検証するシステムの形態について説明する。
ポリシーとは、プログラムやデータを使用するための規則を定義したものである。
【0010】
図1は、実施の形態1におけるポリシー検証システム100の構成図である。
実施の形態1におけるポリシー検証システム100の構成について、図1に基づいて説明する。
【0011】
ポリシー検証システム100は、ポリシー検証装置200(ルール検証装置の一例)と、業務ポリシー管理装置110と、サービスポリシー管理装置120と、データポリシー管理装置130と、依存関係管理装置140とを備える。
【0012】
ポリシー検証装置200は、ディスプレイ装置911、キーボード912、記憶装置(図示省略)、通信装置(図示省略)などのハードウェアを備える。
各ポリシー管理装置(符号110,120,130,140)および依存関係管理装置140は、ポリシー検証装置200と同様に、各種ハードウェアを備える。
【0013】
ポリシーを管理する管理者(図示省略)は、ポリシー管理装置(符号110,120)を用いてポリシーを生成する。
例えば、業務に関するポリシー(業務ポリシー119)を管理する管理者は、業務ポリシー管理装置110の入力装置(例えば、キーボード)を操作して業務ポリシー119に設定する事項を入力する。
業務ポリシー管理装置110のポリシー生成部(図示省略)は、入力された事項を設定したデータ(ファイルともいう)を「業務ポリシー119」として生成し、生成した「業務ポリシー119」を記憶装置に記憶する。
【0014】
データとプログラムとの依存関係を管理する管理者(図示省略)は、依存関係管理装置140を用いて依存関係を定義した依存関係情報(例えば、業務関係情報148、サービス関係情報149)を生成する。
例えば、管理者は、依存関係管理装置140の入力装置を操作して、業務に関する依存関係やサービスに関する依存関係を入力する。
依存関係管理装置140は、入力された依存関係を設定したデータ(ファイルともいう)を「業務関係情報148」または「サービス関係情報149」として生成し、生成した「業務関係情報148」または「サービス関係情報149」を記憶装置に記憶する。
【0015】
検証者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)を操作してポリシー検証プログラム(ルール検証プログラムの一例)を起動する。
【0016】
ポリシー検証装置200は、ポリシー検証プログラムを実行する。
これにより、業務ポリシー119とサービスポリシー129とデータポリシー139との整合性が業務関係情報148とサービス関係情報149とを用いて検証され、検証結果が出力される。
【0017】
以下、業務ポリシー119、サービスポリシー129、データポリシー139およびその他のポリシーを総称して「セキュリティポリシー」という。
また、業務関係情報148、サービス関係情報149およびその他の依存関係情報を総称して「依存関係情報」という。
【0018】
図2は、実施の形態1におけるポリシー検証装置200の機能構成図である。
実施の形態1におけるポリシー検証装置200の機能構成について、図2に基づいて説明する。
【0019】
ポリシー検証装置200(ルール検証装置の一例)は、モデル生成部210(使用不可関係情報特定部、ルール情報追加部の一例)と、モデル検証部220(ルール情報検証部の一例)と、検証装置記憶部290(ルール情報記憶部、依存関係情報記憶部の一例)とを備える。
【0020】
検証装置記憶部290は、ポリシー検証装置200が使用するデータを記憶する。
セキュリティポリシー291(ポリシー情報、ルール情報の一例)、依存関係情報292(依存関係情報の一例)、整合性検証モデル293(ルール情報)、検証結果データ294は、検証装置記憶部290に記憶するデータの一例である。
【0021】
セキュリティポリシー291は、1つ以上のアクセス先識別子(後述するResourceまたはTo)と、1つ以上のアクセス元識別子(後述するSubjectまたはFrom)と、1つの使用可否識別子(後述するEffect)と、1つ以上のルール条件識別子(後述するCondition)と、1つ以上の使用方法識別子(後述するAction)を含んだデータ(またはファイル)である。
アクセス先識別子は、特定のデータと特定のプログラムとのいずれかを対象アクセス先(またはアクセス先)として識別する。
アクセス元識別子は、対象アクセス先を使用するプログラムを対象アクセス元(またはアクセス元)として識別する。
使用可否識別子は、対象アクセス元による対象アクセス先の使用を許可するか否かを識別する。
ルール条件識別子は、自己のセキュリティポリシー291が使用される条件をルール条件(または適用条件)として識別する。
使用方法識別子は、対象アクセス先を使用する使用方法(または操作内容)を識別する。
【0022】
依存関係情報292は、複数のプログラムと複数のデータとを関連付けるデータ(またはファイル)である。
依存関係情報292は、依存元識別子(後述するDependent)と、依存先識別子(後述するAntecedent)とを含む。
依存元識別子は、いずれかのプログラムを対象依存元(または依存元)として識別する。
依存先識別子は、対象依存元に関連付けられるデータまたはプログラムを対象依存先(または依存先)として識別する。
【0023】
整合性検証モデル293は、アクセス先識別子とアクセス元識別子との組み合わせ毎に分解した複数のセキュリティポリシー291(後述するセキュリティルール)を有するデータ(またはファイル)である。
【0024】
検証結果データ294は、整合性検証モデル293を検証した結果を示すデータである。
【0025】
モデル生成部210は、依存関係情報292毎に依存先識別子と依存元識別子との組み合わせに一致するアクセス先識別子とアクセス元識別子との組み合わせを含んだセキュリティルールが記憶されているか否かを判定する。
モデル生成部210は、当該セキュリティルールが記憶されていない依存関係情報292を使用不可関係情報として特定する(使用不可関係情報特定処理)。
【0026】
モデル生成部210は、使用不可関係情報に基づいて、依存先識別子をアクセス先識別子として含み、依存元識別子をアクセス元識別子として含み、使用不可(後述するDeny)を示す使用可否識別子を含み、所定の使用方法を識別する1つ以上の使用方法識別子とを含むセキュリティルールを追加のセキュリティルールとして生成する(ルール情報追加処理)。
【0027】
モデル検証部220は、検証装置記憶部290に記憶される複数のセキュリティルールとモデル生成部210によって生成された追加のセキュリティルールとに基づいて、複数のセキュリティルールが整合しているか否かを検証する(ルール情報検証処理)。
【0028】
例えば、モデル検証部220は、以下のように複数のセキュリティルールを検証する。
モデル検証部220は、複数のセキュリティルールと追加のセキュリティルールとに基づいて特定のアクセス元識別子を含むセキュリティルールを先頭のセキュリティルールとして判定する。
モデル検証部220は、先頭のセキュリティルールまたは他のセキュリティルールのアクセス先識別子をアクセス元識別子として含む1つ以上のセキュリティルールを中間のセキュリティルールとして判定する。
モデル検証部220は、いずれかの中間のセキュリティルールのアクセス先識別子をアクセス元識別子として含み対象アクセス先が無いことを示すアクセス先識別子を含むセキュリティルールを最終のセキュリティルールとして判定する。但し、当該セキュリティルールが存在しない場合、いずれかの中間のセキュリティルールのアクセス先識別子をアクセス元識別子として含み先頭のセキュリティルールのアクセス元識別子と中間のセキュリティルールのアクセス元識別子とのいずれかを含むセキュリティルールを最終のセキュリティルールとして判定する。
モデル検証部220は、先頭のセキュリティルールと中間のセキュリティルールと最終のセキュリティルールとから成るセキュリティルールの複数の組み合わせを複数のルール集合(ルール情報群の一例)として生成する。
モデル検証部220は、生成したルール集合毎に、先頭のセキュリティルールと中間のセキュリティルールと最終のセキュリティルールとのそれぞれの使用可否識別子と、先頭のセキュリティルールと中間のセキュリティルールと最終のセキュリティルールとのそれぞれのルール条件識別子とに基づいて、ルール集合のルール条件を示すルール条件式と、ルール集合の使用可否識別子とを判定する。
モデル検証部220は、最終のセキュリティルールのアクセス元識別子が一致し、少なくともいずれかの使用方法識別子が一致するルール集合の組み合わせを判定する。
モデル検証部220は、判定したルール集合の組み合わせのうちルール条件式と使用可否識別子との少なくともいずれかが一致しないルール集合の組み合わせをルール集合の不整合な組み合わせとして判定する。
モデル検証部220は、判定したルール集合の不整合な組み合わせを示す検証結果データ294を生成し、生成した検証結果データ294を出力する。
【0029】
例えば、モデル検証部220は、以下のようにルール集合のルール条件式を生成する。
モデル検証部220は、ルール集合毎に、先頭のセキュリティルールと中間のセキュリティルールと最終のセキュリティルールとのうち使用許可を識別する使用可否識別子(後述するPermit)を含んだセキュリティルールを当該ルール集合の肯定のセキュリティルールとして判定する。
モデル検証部220は、ルール集合毎に、先頭のセキュリティルールと中間のセキュリティルールと最終のセキュリティルールとのうち使用不可を識別する使用可否識別子(後述するDeny)を含んだセキュリティルールを当該ルール集合の否定のセキュリティルールとして判定する。
モデル検証部220は、ルール集合毎に、肯定のセキュリティルールのルール条件と否定のセキュリティルールのルール条件を否定するルール条件とを含む式を当該ルール集合のルール条件式として生成する。
【0030】
例えば、モデル検証部220は、以下のようにルール集合の使用可否識別子を判定する。
モデル検証部220は、ルール集合毎に、最終のセキュリティルールの使用可否識別子を当該ルール集合の使用可否識別子として判定する。
【0031】
図3は、実施の形態1におけるセキュリティポリシー291のモデルを示すインスタンス図である。
実施の形態1におけるセキュリティポリシー291のデータ構造について、図3に基づいて説明する。
【0032】
ここで、セキュリティポリシー291の集合体を「PolicySet(ポリシーセット)」と記す。
【0033】
「PolicySet」は、0個以上のセキュリティポリシー291を有する。
「Policy(ポリシー)」は、セキュリティポリシー291を識別する識別子を示す。
【0034】
「Policy」(ポリシー情報、ルール情報の一例)は、属性として「Effect(エフェクト)」を有する。
「Effect」(使用可否識別子の一例)は、「Permit(許可)」または「Deny(不許可)」を示す。
【0035】
「Policy」は、子要素として「Subject(サブジェクト)」と、「Resource(リソース)」と、「Action(アクション)」と、「Condition(コンディション)」とを有する。
【0036】
「Subject」(アクセス元識別子の一例)は、1つ以上のアクセス元の識別子を示す。アプリケーションプログラム、業務プログラム、サービスプログラムまたはユーザはアクセス元の一例である。
「Resource」(アクセス先識別子の一例)は、1つ以上のアクセス先の識別子を示す。アプリケーションプログラム、業務プログラム、サービスプログラムまたはデータはアクセス先の一例である。
【0037】
アクセス元はアクセス先を操作する。
【0038】
「Action」(使用方法識別子の一例)は、1つ以上の操作内容の識別子を示す。読み取り、書き込み、呼び出しまたは複製は操作内容の一例である。
【0039】
「Condition」(ルール条件識別子の一例)は、「Policy」を適用する0個以上の識別子を示す。年度、業務の種類または部署は適用条件の一例である。
【0040】
図4は、実施の形態1におけるセキュリティポリシー291の「Subject」と「Resource」との関係を示すベン図である。
アクセス先であるアプリケーションプログラム、業務プログラム、サービスプログラムまたはユーザは、他のプログラムやデータにアクセスするアクセス元にもなるため、アクセス元「Subject」とアクセス先「Resource」とは部分的に重複する(図4参照)。
【0041】
図5は、実施の形態1におけるセキュリティポリシー291の一例を示す図である。
例えば、セキュリティポリシー291は、図5に示すようにXML(Extensible Markup Language)を用いて記述され、ファイルとして記憶される。
セキュリティポリシー291の要素(または属性)は、タグ「<・・・>」を用いて記される。
【0042】
図6は、実施の形態1における依存関係情報292のモデルを示すインスタンス図である。
実施の形態1における依存関係情報292のデータ構造について、図6に基づいて説明する。
【0043】
ここで、依存関係情報292の集合体を「DependencySet(ディペンデンシーセット)」と記す。
【0044】
「DependencySet」は、0個以上の依存関係情報292を有する。
「Dependency(ディペンデンシー)」は、依存関係情報292を識別する識別子を示す。
【0045】
「Dependency」(依存関係情報の一例)は、子要素として「Dependent(ディペンデント)」と、「Antecedent(アンティシーデント)」とを有する。
【0046】
「Dependent」(依存元識別子の一例)は、1つの依存元の識別子を示す。アプリケーションプログラム、業務プログラム、サービスプログラムまたはユーザは依存元の一例である。
「Antecedent」(依存先識別子の一例)は、0個以上の依存先の識別子を示す。アプリケーションプログラム、業務プログラム、サービスプログラムまたはデータは依存先の一例である。
【0047】
依存元と依存先とは互いに関連する。
【0048】
図7は、実施の形態1における依存関係情報292の「Dependent」と「Antecedent」との関係を示すベン図である。
依存先であるアプリケーションプログラム、業務プログラム、サービスプログラムまたはユーザは、他のプログラムやデータと関連する依存元にもなるため、依存元「Dependent」と依存先「Antecedent」とは部分的に重複する(図7参照)。
【0049】
図8は、実施の形態1における依存関係情報292の一例を示す図である。
例えば、依存関係情報292は、図8に示すようにXMLを用いて記述され、ファイルとして記憶される。依存関係情報292の要素はタグを用いて記される。
【0050】
図9は、実施の形態1における整合性検証モデル293を示すインスタンス図である。
実施の形態1における整合性検証モデル293のデータ構造について、図9に基づいて説明する。
【0051】
ここで、整合性検証モデル293を「Model(モデル)」と記す。
【0052】
「Model」は、0個以上のセキュリティルールを有する。
「Rule(ルール)」は、セキュリティルールを識別する識別子を示す。
【0053】
「Rule」(ルール情報の一例)は、属性として「Effect」を有する。
【0054】
「Rule」は、子要素として「From」と、「To」と、「Action」と、「Condition」とを有する。
【0055】
「From」(アクセス元識別子の一例)は、1つの遷移元の識別子を示す。アプリケーションプログラム、業務プログラム、サービスプログラムまたはユーザは遷移元の一例である。
「To」(アクセス先識別子の一例)は、1つの遷移先の識別子を示す。アプリケーションプログラム、業務プログラム、サービスプログラムまたはデータは遷移先の一例である。
【0056】
「Effect」(使用可否識別子の一例)、「Action」(使用方法識別子の一例)、「Condition」(ルール条件識別子の一例)はセキュリティポリシー291のモデル(図3参照)と同様である。
【0057】
図10は、実施の形態1における整合性検証モデル293の一例を示す図である。
例えば、整合性検証モデル293は、セキュリティポリシー291(図5参照)と同様に、XMLを用いて記述され、ファイルとして記憶される。
【0058】
図11は、実施の形態1におけるセキュリティポリシー291のモデルと整合性検証モデル293との関係を示す対応表である。
セキュリティポリシー291のモデル(図3参照)と整合性検証モデル293(図9参照)との関係について、図11に基づいて説明する。
【0059】
セキュリティポリシー291のモデルの要素(または属性)と、整合性検証モデル293の要素(または属性)とは、図11に示すように対応する。
【0060】
つまり、整合性検証モデル293の「Model」は、セキュリティポリシー291の「PolicySet」に対応する。
同様に、整合性検証モデル293の「Model」「Rule」「Effect」「From」「To」「Action」「Condition」は、セキュリティポリシー291の「Policy」「Effect」「Subject」「Resource」「Action」「Condition」に対応する。
【0061】
整合性検証モデル293は、セキュリティポリシー291をアクセス元(Subject)とアクセス先(Resource)との組み合わせ毎に分解したものである。
【0062】
図12は、実施の形態1におけるポリシー検証装置200のポリシー検証方法を示すフローチャートである。
実施の形態1におけるポリシー検証装置200のポリシー検証方法(ルール検証方法、ルール検証プログラムN一例)について、図12に基づいて説明する。
【0063】
S110において、モデル生成部210は、セキュリティポリシー291と依存関係情報292とを比較する。
ここで、依存関係情報292の依存元と依存先との組み合わせに対応するアクセス元とアクセス先との組み合わせを有するセキュリティポリシー291が存在しない場合、その依存関係情報292に対応するセキュリティポリシーが不足している。
そこで、モデル生成部210は、不足しているセキュリティポリシーを生成することにより、セキュリティポリシー291を補完する。
S110の後、S120に進む。
【0064】
S120において、モデル生成部210は、補完したセキュリティポリシー291を分解して整合性検証モデル293を生成する。
S120の後、S130に進む。
【0065】
S130において、モデル検証部220は、整合性検証モデル293を検証し、検証結果データ294を生成し、生成した検証結果データ294を出力する。
S130により、ポリシー検証方法は終了する。
【0066】
次に、ポリシー検証方法の各処理(S110−S130)について詳細を説明する。
【0067】
図13は、実施の形態1におけるポリシー追加処理(S110)のフローチャートである。
実施の形態1におけるポリシー追加処理(S110)について、図13に基づいて説明する。
【0068】
S111において、モデル生成部210は、検証装置記憶部290から依存関係情報292を一つ選択する。
以下、選択した依存関係情報292を「選択依存関係」という。
S111の後、S112に進む。
【0069】
S112において、モデル生成部210は、選択依存関係の依存元(Dependent)をアクセス元(Subject)として有し、選択依存関係の依存先(Antecedent)をアクセス先(Resource)として有するセキュリティポリシー291を検索する。
S112の後、S113に進む。
【0070】
S113において、モデル生成部210は、該当するセキュリティポリシー291が検索で見つかったか否かを判定する。
該当するセキュリティポリシー291が検索で見つかった場合(YES)、S115に進む。
該当するセキュリティポリシー291が検索で見つからなかった場合(NO)、S114に進む。
【0071】
S114において、モデル生成部210は、選択依存関係に対応するセキュリティポリシーを生成し、生成したセキュリティポリシーを検証装置記憶部290に新たに記憶する。
【0072】
図14は、実施の形態1におけるセキュリティポリシー生成処理(S114)の説明を補足する表である。
選択依存関係に対応するセキュリティポリシーの設定内容について、図14に基づいて説明する。
【0073】
(1)モデル生成部210は、セキュリティポリシーの「Subject」に選択依存関係の「Dependent」を設定する。
【0074】
(2)モデル生成部210は、セキュリティポリシーの「Resource」に選択依存関係の「Antecedent」を設定する。
【0075】
(3)モデル生成部210は、セキュリティポリシーの「Action」に全ての操作内容の識別子を設定する。全ての操作内容の識別子はアクションリストとして検証装置記憶部290に予め記憶しておく。
【0076】
(4)モデル生成部210は、セキュリティポリシーの「Condition」に適用条件が無いことを示す識別子を設定する。つまり、このセキュリティポリシーは適用条件が無く、常に適用される。
【0077】
(5)モデル生成部210は、セキュリティポリシーの「Effect」に「Deny(不許可)」を設定する。
「Permit(許可)」のセキュリティポリシー291が定義されていない場合、プログラムやデータの使用は許可されないためである。また、ポリシー管理者が「Deny」のセキュリティポリシー291を定義せず、セキュリティポリシー291の管理を簡略化する場合があるためである。
【0078】
図13に戻り、ポリシー追加処理(S110)の説明をS115から続ける。
【0079】
S115において、モデル生成部210は、未選択の依存関係情報292が検証装置記憶部290に残っているか否かを判定する。
未選択の依存関係情報292が残っている場合(YES)、S111に戻る。
未選択の依存関係情報292が残っていない場合(NO)、ポリシー追加処理(S110)は終了する。
【0080】
ポリシー追加処理(S110)により、省略されたセキュリティポリシー291や定義漏れのセキュリティポリシー291を依存関係情報292に基づいて生成することができる。
【0081】
図15は、実施の形態1におけるモデル生成処理(S120)のフローチャートである。
実施の形態1におけるモデル生成処理(S120)について、図15に基づいて説明する。
【0082】
S121において、モデル生成部210は、検証装置記憶部290からセキュリティポリシー291を選択する。選択するセキュリティポリシー291には、ポリシー追加処理(S110)で生成したセキュリティポリシーを含む。
以下、選択したセキュリティポリシー291を「選択ポリシー」という。
S121の後、S122に進む。
【0083】
S122において、モデル生成部210は、選択ポリシーを「アクセス元(Subject)」毎に分解する。
例えば、選択ポリシーの「Subject」が2つのアクセス元を含んでいる場合、モデル生成部210は、選択ポリシーを2つのセキュリティポリシーに分解する。
S122の後、S123に進む。
【0084】
S123において、モデル生成部210は、S122で得られた各セキュリティポリシーを「アクセス先(Resource)」毎に分解する。
例えば、各セキュリティポリシーの「Resource」が3つのアクセス先を含んでいる場合、モデル生成部210は、各セキュリティポリシーを3つに分解する。
つまり、選択ポリシーが「Subject」に2つのアクセス元を含み、「Resource」に3つのアクセス先を含んでいる場合、選択ポリシーは6つのセキュリティポリシーに分解される。6つのセキュリティポリシーは、「Subject」に1つのアクセス元を含み、「Resource」に1つのアクセス先を含む。
S123の後、S124に進む。
【0085】
S124において、モデル生成部210は、S123で得られた各セキュリティポリシーを整合性検証モデル293のセキュリティルール(図9のRule)に変換し、変換により得られたセキュリティルールを検証装置記憶部290に新たに記憶する。
つまり、S123で6つのセキュリティポリシーが得られた場合、モデル生成部210は6つのセキュリティポリシーから6つのセキュリティルールを生成する。
セキュリティポリシーの項目とセキュリティルール(整合性検証モデル293)の項目は、図11に示したように1対1に対応する。
S124の後、S125に進む。
【0086】
S125において、モデル生成部210は、未選択のセキュリティポリシー291が検証装置記憶部290に残っているか否かを判定する。
未選択のセキュリティポリシー291が残っている場合(YES)、S121に戻る。
未選択のセキュリティポリシー291が残っていない場合(NO)、モデル生成処理(S120)は終了する。
【0087】
モデル生成処理(S120)により、アクセス元とアクセス先とを1つまたは複数有するセキュリティポリシー291からアクセス元とアクセス先とを1つずつ有するセキュリティルールを得ることができる。
【0088】
図16は、実施の形態1におけるモデル検証処理(S130)のフローチャートである。
実施の形態1におけるモデル検証処理(S130)について、図16に基づいて説明する。
【0089】
S131において、モデル検証部220は、検証装置記憶部290から整合性検証モデル293を取得し、整合性検証モデル293に含まれる複数のセキュリティルールを参照する。
そして、モデル検証部220は、少なくともいずれかのセキュリティルールに設定されている遷移元(From)を一覧にしてリストを生成する。
以下、遷移元を一覧にしたリストを「サブジェクトリスト」という。
S131の後、S132に進む。
【0090】
S132において、モデル検証部220は、サブジェクトリストから遷移元を選択する。
以下、選択した遷移元を「スタートサブジェクト」という。
S132の後、S133に進む。
【0091】
S133において、モデル検証部220は、スタートサブジェクトからセキュリティルールの遷移先(To)を「深さ優先探索」によって辿り、関連する複数のセキュリティルールを判定する。
そして、モデル検証部220は、関連する複数のセキュリティルールを一覧にしてリストを生成する。
以下、関連する複数のセキュリティルールを「ルール集合」といい、関連する複数のセキュリティルールを一覧したリストを「ルールリスト」という。
【0092】
図17は、実施の形態1におけるルールリスト生成処理(S133)の概要図である。
実施の形態1におけるルールリスト生成処理(S133)の一例について、図17に基づいて説明する。
【0093】
ここで、スタートサブジェクトを“サブジェクト”と記す。
【0094】
モデル検証部220は、“サブジェクト”を検索キーにして、「From(遷移元)」に“サブジェクト”が設定されているセキュリティルールを検索する。
検索の結果、“ルールA”と“ルールE”とが該当した。
【0095】
モデル検証部220は、“ルールA”の「To(遷移先)」に設定されている“リソースA”を検索キーにして、「From」に“リソースA”が設定されているセキュリティルールを検索する。
検索の結果、“ルールB”が該当した。
【0096】
モデル検証部220は、“ルールB”の「To」に設定されている“リソースC”を検索キーにして、「From」に“リソースC”が設定されているセキュリティルールを検索する。
検索の結果、“ルールC”と“ルールG”とが該当した。
【0097】
モデル検証部220は、“ルールC”の「To」に設定されている“リソースD”を検索キーとして、「From」に“リソースD”が設定されているセキュリティルールを検索する。
検索の結果、“ルールD”が該当した。
【0098】
モデル検証部220は、“ルールD”の「To」に設定されている“リソースF”を検索キーとして、「From」に“リソースF”が設定されているセキュリティルールを検索する。
検索の結果、該当するセキュリティルールは存在しなかった。したがって、“ルールD”が末端のセキュリティルールであり、“リソースF”が末端の遷移先である。
【0099】
末端の遷移先に到達した場合、モデル検証部220は、末端の遷移先に到達するまでに検索で見つかったセキュリティルールを検索順に並べてルールリストを生成する。
つまり、モデル検証部220は、ルールリスト(1)として「ルールA、ルールB、ルールC、ルールD」を設定したファイルを生成する。
【0100】
以下、スタートサブジェクト(サブジェクト)から末端の遷移先(リソースF)までの経路を「遷移ルート」という。
【0101】
遷移ルートが途中でループする場合、ループする一つ前の遷移先を末端の遷移先とする。
例えば、「From」が“リソースF”であり、「To」が“リソースD”である“ルールZ”が存在する場合、“ルールD”と“ルールZ”とによって“リソースD”と“リソースF”との間で遷移ルートがループしてしまう。
この場合、“リソースF”が末端の遷移先である。また、“ルールD”および“ルールZ”が末端のセキュリティルールである。
【0102】
末端のセキュリティルールに到達した場合、モデル検証部220は、末端の遷移先からスタートオブジェクトへ戻りながら、全ての遷移ルートを特定する。
【0103】
例えば、モデル検証部220は、対象とする遷移先を末端の遷移先“リソースF”から一つ前の遷移先“リソースD”に戻す。
しかし、「From」に“リソースD”が設定されているセキュリティルールのうち処理していないセキュリティルールは残っていないため、モデル検証部220は、対象とする遷移先をさらに一つ前の遷移先“リソースC”に戻す。
ここで、「From」に“リソースC”が設定されているセキュリティルールのうち“ルールG”が未処理であるため、モデル検証部220は、“ルールG”を用いて遷移ルートの検索を行う。
【0104】
つまり、モデル検証部220は、“ルールG”の「To」に設定されている“リソースE”を検索キーとして、「From」に“リソースE”が設定されているセキュリティルールを検索する。
検索の結果、“ルールH”が該当した。また、“ルールH”の「To」には“リソースF”が設定されているため、“ルールH”は末端のセキュリティルールである。
したがって、モデル検証部220は、ルールリスト(2)として「ルールA、ルールB、ルールG、ルールH」を設定したリストを生成する。
【0105】
以後、モデル検証部220は、対象とする遷移先を“サブジェクト”まで戻し、“ルールE”を用いて遷移ルートの検索を行う。
そして、モデル生成部210は、ルールリスト(3)「ルールE、ルールF、ルールC、ルールD」と、ルールリスト(4)「ルールE、ルールF、ルールG、ルールH」を生成する。
【0106】
図16に戻り、モデル検証処理(S130)の説明をS134から続ける。
【0107】
S134において、モデル検証部220は、ルート集合毎に、ルール集合に含まれるセキュリティルールをルールリストに基づいて統合する。
【0108】
図18は、実施の形態1における統合ルール生成処理(S134)のフローチャートである。
実施の形態1における統合ルール生成処理(S134)について、図18に基づいて説明する。
【0109】
モデル検証部220は、以下に説明する処理(S134a−S134g)をルールリスト(ルール集合)毎に実行する。
【0110】
S134aにおいて、モデル検証部220は、ルールリストを複製する。
以下、複製してルールリストを「作業用リスト282」という。
S134aの後、S134bに進む。
【0111】
S134bにおいて、モデル検証部220は、作業用リスト282を参照し、セキュリティルールを上位から順に選択する。
以下、選択したセキュリティルールを「上位のセキュリティルール」という。
S134bの後、S134cに進む。
【0112】
S134cにおいて、モデル検証部220は、上位のセキュリティルールの適用結果(Effect)が“Permit(許可)”と“Deny(不許可)”とのどちらであるかを判定する。
“Permit”である場合、S134dに進む。
“Deny”である場合、S134eに進む。
【0113】
S134dにおいて、モデル検証部220は、上位のセキュリティルールの適用条件(Condition)を一つ下位のセキュリティルールの適用条件に追加する。
S134dの後、S134fに進む。
【0114】
S134eにおいて、モデル検証部220は、上位のセキュリティルールの適用条件の否定形を一つ下位のセキュリティルールの適用条件に追加する。
S134eの後、S134fに進む。
【0115】
但し、S134dまたはS134eによって、下位のセキュリティルールの適用条件に同じ条件の肯定系と否定形とを含んだ場合、モデル検証部220は、以降の処理(S134f,S134g)を行わず、当該ルールリスト(ルール集合)の統合ルール生成処理(S134)を終了してもよい。
【0116】
図19は、実施の形態1における適用条件判定処理(S134b−S134f)の概要図である。
実施の形態1における適用条件判定処理(S134b−S134f)の一例について、図19に基づいて説明する。
【0117】
ここで、セキュリティルールを上位から順に「Rule1、Rule2、Rule3」とする。また、「RuleX」(Xは整数)の適用条件を「CondX」と記す。
【0118】
「Rule1」の適用結果が“Permit”である場合、「Rule1」の適用条件“Cond1”が「Rule2」に加わり、「Rule2」の適用条件は“Cond1&Cond2”になる。
【0119】
さらに、「Rule2」の適用結果が“Permit”である場合、「Rule2」の適用条件“Cond1&Cond2”が「Rule3」に加わり、「Rule3」の適用条件は“Cond1&Cond2&Cond3”になる。
【0120】
また、「Rule1」の適用結果が“Deny”である場合、「Rule1」の適用条件“Cond1”の否定形“NotCond1”が「Rule2」に加わり、「Rule2」の適用条件は“NotCond1&Cond2”になる。
【0121】
さらに、「Rule2」の適用結果が“Deny”である場合、「Rule2」の適用条件“NotCond1&Cond2”の否定形“Cond1&NotCond2”が「Rule3」に加わり、「Rule3」の適用条件は“Cond1&NotCond2&Cond3”になる。
【0122】
図18に戻り、統合ルール生成処理(S134)の説明をS134fから続ける。
【0123】
S134fにおいて、モデル検証部220は、作業用リスト282に下位のセキュリティルールが残っているか否かを判定する。
下位のセキュリティルールが残っている場合(YES)、S134bに戻る。
下位のセキュリティルールが残っていない場合(NO)、S134gに戻る。
【0124】
S134gにおいて、モデル検証部220は、作業用リスト282に基づいて統合ルール281を生成し、生成した統合ルール281を検証装置記憶部290に記憶する。
統合ルール281は、ルール集合に含まれるセキュリティルールを統合した統合ルールを示すデータ(またはファイル)である。
S134gにより、統合ルール生成処理(S134)は終了する。
【0125】
図20は、実施の形態1における統合ルール生成処理(S134g)の説明を補足する対応表である。
実施の形態1における統合ルール生成処理(S134g)について、図20に基づいて説明する。
【0126】
(1)モデル検証部220は、作業用リスト282に設定されているセキュリティルールのうち最上位のセキュリティルールを判定し、最上位のセキュリティルールの依存元(From)をルール集合の依存元として統合ルール281に設定する。
【0127】
(2)モデル検証部220は、作業用リスト282に設定されているセキュリティルールのうち最下位のセキュリティルールを判定し、最下位のセキュリティルールの依存先(To)をルール集合の依存先として統合ルール281に設定する。
【0128】
(3)モデル検証部220は、作業用リスト282に設定されている全ての操作内容(Action)をルール集合の操作内容として統合ルール281に設定する。
【0129】
(4)モデル検証部220は、最下位のセキュリティルールの適用条件(Condition)をルール集合の適用条件として統合ルール281に設定する。
ここで、最下位のセキュリティルールとは、適用条件判定処理(S134b−S134f)によって上位のセキュリティルールの適用条件(またはその否定形)が追加された後の最下位のセキュリティルールのことである。
【0130】
(5)モデル検証部220は、最下位のセキュリティルールの適用結果(Effct)をルール集合の操作内容として統合ルール281に設定する。
【0131】
図16に戻り、モデル検証処理(S130)の説明をS135から続ける。
【0132】
S135において、モデル検証部220は、ルール集合の組み合わせ毎に統合ルール281の整合性を判定する。
S135の後、S136に進む。
【0133】
図21は、実施の形態1における整合性判定処理(S135)のフローチャートである。
実施の形態1における整合性判定処理(S135)について、図21に基づいて説明する。
【0134】
S135aにおいて、モデル検証部220は、S132(図16参照)で選択したスタートサブジェクトの2つ(または3つ以上)のルール集合を総当たりで組み合わせ、ルール集合の組み合わせリストを生成する。
ルール集合の組み合わせリストとは、ルール集合の組み合わせ毎に、ルール集合の組み合わせを識別する組み合わせ識別子と、ルール集合を識別するルール集合識別子とを対応付けて設定したデータ(またはファイル)である。
S135aの後、S135bに進む。
【0135】
S135bにおいて、モデル検証部220は、ルール集合の組み合わせリストからルール集合の組み合わせを選択する。
以下、選択したルール集合の組み合わせを「選択組み合わせ」という。
S135bの後、S135cに進む。
【0136】
S135cにおいて、モデル検証部220は、選択組み合わせを構成するルール集合毎にルール集合の統合ルール281を検証装置記憶部290から取得する。
モデル検証部220は、取得した統合ルール281を比較し、統合ルール間の整合性を判定する。
【0137】
図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”である場合、適用条件は矛盾する。
【0138】
図21に戻り、整合性判定処理(S135)の説明をS135dから進める。
【0139】
S135dにおいて、モデル検証部220は、判定結果を検証結果データ294に設定する。
例えば、モデル検証部220は、判定結果(整合、不整合)と、選択組み合わせの組み合わせ識別子とを対応付けて検証結果データ294に設定する。
S135dの後、S135eに進む。
【0140】
S135eにおいて、モデル検証部220は、ルール集合の未選択の組み合わせが残っているか否かを判定する。
未選択の組み合わせが残っている場合(YES)、S135bに進む。
未選択の組み合わせが残っていない場合(NO)、S135fに進む。
【0141】
S135fにおいて、モデル検証部220は、検証結果データ294を出力する。
例えば、モデル検証部220は、検証結果データ294に基づいて検証結果画面283を生成し、生成した検証結果画面283をディスプレイ装置911に表示する。
S135fにより、整合性判定処理(S135)は終了する。
【0142】
図23は、実施の形態1における検証結果画面283の一例を示す図である。
例えば、モデル検証部220は、検証結果データ294に基づいて図23に示すような検証結果画面283を表示する。
【0143】
このとき、モデル検証部220は、検証結果データ294を参照し、整合性がないルール集合の組み合わせを判定する。以下、整合性がないルール集合の組み合わせを「不整合組み合わせ」という。
モデル検証部220は、不整合組み合わせを構成するルール集合のルールリストを検証装置記憶部290から取得し、取得したルールリストからルール集合を構成する複数のセキュリティルールを取得する。
そして、モデル検証部220は、取得した複数のセキュリティルールに基づいてルール集合の遷移ルートを判定し、判定した遷移ルートを表す画面として検証結果画面283を生成し、生成した検証結果画面283を表示する。
【0144】
図23の検証結果画面は、“ルールA”と“ルールB”とから成る第一のルール集合の遷移ルートと、“ルールC”と“ルールD”とから成る第二のルール集合の遷移ルートとを記すことにより、第一のルール集合と第二のルール集合との組み合わせが「不整合」であることを示している。
【0145】
図16に戻り、モデル検証処理(S130)の説明をS136から続ける。
【0146】
S136において、モデル検証部220は、サブジェクトリストに未選択の遷移元(From)が残っているか否かを判定する。
未選択の遷移元が残っている場合(YES)、S132に戻る。
未選択の遷移元が残っていない場合(NO)、モデル検証処理(S130)は終了する。
【0147】
図24は、実施の形態1におけるポリシー検証装置200のハードウェア資源の一例を示す図である。
図24において、ポリシー検証装置200は、CPU901(Central Processing Unit)を備えている。CPU901は、バス902を介してROM903、RAM904、通信ボード905、ディスプレイ装置911、キーボード912、マウス913、ドライブ装置914、磁気ディスク装置920と接続され、これらのハードウェアデバイスを制御する。ドライブ装置914は、FD(Flexible Disk Drive)、CD(Compact Disc)、DVD(Digital Versatile Disc)などの記憶媒体を読み書きする装置である。
【0148】
通信ボード905は、有線または無線で、LAN(Local Area Network)、インターネット、電話回線などの通信網に接続している。
【0149】
磁気ディスク装置920には、OS921(オペレーティングシステム)、プログラム群922、ファイル群923が記憶されている。
【0150】
プログラム群922には、実施の形態において「〜部」として説明する機能を実行するプログラムが含まれる。プログラムは、CPU901により読み出され実行される。すなわち、プログラムは、「〜部」としてコンピュータを機能させるものであり、また「〜部」の手順や方法をコンピュータに実行させるものである。
【0151】
ファイル群923には、実施の形態において説明する「〜部」で使用される各種データ(入力、出力、判定結果、計算結果、処理結果など)が含まれる。
【0152】
実施の形態において構成図およびフローチャートに含まれている矢印は主としてデータや信号の入出力を示す。
【0153】
実施の形態において「〜部」として説明するものは「〜回路」、「〜装置」、「〜機器」であってもよく、また「〜ステップ」、「〜手順」、「〜処理」であってもよい。すなわち、「〜部」として説明するものは、ファームウェア、ソフトウェア、ハードウェアまたはこれらの組み合わせのいずれで実装されても構わない。
【0154】
実施の形態1により、例えば、以下のような効果を奏することができる。
(1)個別に設定されている複数のレイヤ(例えば、業務、サービス、データ)のポリシーが全体として矛盾しているか否かを検証することができる。
(2)「一般社員の人事秘へのアクセスを禁止する」などの会社規則とシステムのポリシーとが矛盾しているか否かを検証することができる。
(3)同じリソースに対して許可と不許可とを同時に与えてしまうような明らかな矛盾を検出することができる。
(4)適用条件付きのポリシーが特定の条件の場合に矛盾することを検出することができる。
【符号の説明】
【0155】
100 ポリシー検証システム、101 検証者、102 経営者、103 会社規則、110 業務ポリシー管理装置、119 業務ポリシー、120 サービスポリシー管理装置、129 サービスポリシー、130 データポリシー管理装置、139 データポリシー、140 依存関係管理装置、148 業務関係情報、149 サービス関係情報、200 ポリシー検証装置、210 モデル生成部、220 モデル検証部、281 統合ルール、282 作業用リスト、283 検証結果画面、290 検証装置記憶部、291 セキュリティポリシー、292 依存関係情報、293 整合性検証モデル、294 検証結果データ、901 CPU、902 バス、903 ROM、904 RAM、905 通信ボード、911 ディスプレイ装置、912 キーボード、913 マウス、914 ドライブ装置、920 磁気ディスク装置、921 OS、922 プログラム群、923 ファイル群。

【特許請求の範囲】
【請求項1】
特定のデータと特定のプログラムとのいずれかを対象アクセス先として識別するアクセス先識別子と、対象アクセス先を使用するプログラムを対象アクセス元として識別するアクセス元識別子と、対象アクセス元による対象アクセス先の使用を許可するか否かを識別する使用可否識別子とを含んだ複数のルール情報を記憶するルール情報記憶部と、
複数のプログラムと複数のデータとを関連付ける複数の依存関係情報であって、いずれかのプログラムを対象依存元として識別する依存元識別子と、対象依存元に関連付けられるデータまたはプログラムを対象依存先として識別する依存先識別子とを含んだ複数の依存関係情報を記憶する依存関係情報記憶部と、
前記依存関係情報記憶部に記憶される依存関係情報毎に依存先識別子と依存元識別子との組み合わせに一致するアクセス先識別子とアクセス元識別子との組み合わせを含んだルール情報が前記ルール情報記憶部に記憶されているか否かを判定し、当該ルール情報が前記ルール情報記憶部に記憶されていない依存関係情報を使用不可関係情報として特定する使用不可関係情報特定部と、
前記使用不可関係情報特定部によって特定された使用不可関係情報に基づいて、依存先識別子をアクセス先識別子として含み、依存元識別子をアクセス元識別子として含み、使用不可を示す使用可否識別子を含むルール情報を追加のルール情報として生成するルール情報追加部と、
前記ルール情報記憶部に記憶される複数のルール情報と前記ルール情報追加部によって生成された追加のルール情報とに基づいて、前記複数のルール情報が整合しているか否かを検証するルール情報検証部と
を備えることを特徴とするルール検証装置。
【請求項2】
前記複数のルール情報は、自ルール情報が使用される条件をルール条件として識別するルール条件識別子を含み、
前記ルール情報検証部は、
前記複数のルール情報と前記追加のルール情報とに基づいて特定のアクセス元識別子を含むルール情報を先頭のルール情報として判定し、先頭のルール情報または他のルール情報のアクセス先識別子をアクセス元識別子として含む1つ以上のルール情報を中間のルール情報として判定し、いずれかの中間のルール情報のアクセス先識別子をアクセス元識別子として含み対象アクセス先が無いことを示すアクセス先識別子を含むルール情報を最終のルール情報として判定し、先頭のルール情報と中間のルール情報と最終のルール情報とから成るルール情報の複数の組み合わせを複数のルール情報群として生成し、
生成したルール情報群毎に、先頭のルール情報と中間のルール情報と最終のルール情報とのそれぞれの使用可否識別子と、先頭のルール情報と中間のルール情報と最終のルール情報とのそれぞれのルール条件識別子とに基づいて、ルール情報群のルール条件を示すルール条件式と、ルール情報群の使用可否識別子とを判定し、
最終のルール情報のアクセス元識別子が一致するルール情報群の組み合わせを判定し、判定したルール情報群の組み合わせのうちルール条件式と使用可否識別子との少なくともいずれかが一致しないルール情報群の組み合わせをルール情報群の不整合な組み合わせとして判定し、
判定したルール情報群の不整合な組み合わせを示す検証結果データを生成し、生成した検証結果データを出力する
ことを特徴とする請求項1記載のルール検証装置。
【請求項3】
前記ルール情報検証部は、
ルール情報群毎に、先頭のルール情報と中間のルール情報と最終のルール情報とのうち使用許可を識別する使用可否識別子を含んだルール情報を当該ルール情報群の肯定のルール情報として判定し、
ルール情報群毎に、先頭のルール情報と中間のルール情報と最終のルール情報とのうち使用不可を識別する使用可否識別子を含んだルール情報を当該ルール情報群の否定のルール情報として判定し、
ルール情報群毎に、肯定のルール情報のルール条件と、否定のルール情報のルール条件を否定するルール条件とを含む式を当該ルール情報群のルール条件式として生成する
ことを特徴とする請求項2記載のルール検証装置。
【請求項4】
前記ルール情報検証部は、ルール情報群毎に、最終のルール情報の使用可否識別子を当該ルール情報群の使用可否識別子として判定する
ことを特徴とする請求項3記載のルール検証装置。
【請求項5】
前記ルール情報検証部は、前記最終のルール情報に該当するルール情報が存在しない場合、いずれかの中間のルール情報のアクセス先識別子をアクセス元識別子として含み、先頭のルール情報のアクセス元識別子と中間のルール情報のアクセス元識別子とのいずれかをアクセス先識別子として含むルール情報を最終のルール情報として判定する
ことを特徴とする請求項2から請求項4いずれかに記載のルール検証装置。
【請求項6】
前記複数のルール情報は、対象アクセス先を使用する使用方法を識別する1つ以上の使用方法識別子を含み、
前記ルール情報追加部は、所定の使用方法を識別する1つ以上の使用方法識別子を含んだ追加のルール情報を生成し、
前記ルール情報検証部は、最終のルール情報のアクセス元識別子が一致し、少なくともいずれかの使用方法識別子が一致し、ルール条件式と使用可否識別子との少なくともいずれかが一致しないルール情報群の組み合わせをルール情報群の不整合な組み合わせとして判定する
ことを特徴とする請求項2から請求項5いずれかに記載のルール検証装置。
【請求項7】
特定のデータと特定のプログラムとのいずれかを対象アクセス先として識別するアクセス先識別子と、対象アクセス先を使用するプログラムを対象アクセス元として識別するアクセス元識別子と、対象アクセス元による対象アクセス先の使用を許可するか否かを識別する使用可否識別子とを含んだ複数のルール情報を記憶するルール情報記憶部と、
複数のプログラムと複数のデータとを関連付ける複数の依存関係情報であって、いずれかのプログラムを対象依存元として識別する依存元識別子と、対象依存元に関連付けられるデータまたはプログラムを対象依存先として識別する依存先識別子とを含んだ複数の依存関係情報を記憶する依存関係情報記憶部と、
使用不可関係情報特定部と、ルール情報追加部と、ルール情報検証部とを備えるルール検証装置のルール検証方法であって、
前記使用不可関係情報特定部が、前記依存関係情報記憶部に記憶される依存関係情報毎に依存先識別子と依存元識別子との組み合わせに一致するアクセス先識別子とアクセス元識別子との組み合わせを含んだルール情報が前記ルール情報記憶部に記憶されているか否かを判定し、当該ルール情報が前記ルール情報記憶部に記憶されていない依存関係情報を使用不可関係情報として特定し、
前記ルール情報追加部が、前記使用不可関係情報特定部によって特定された使用不可関係情報に基づいて、依存先識別子をアクセス先識別子として含み、依存元識別子をアクセス元識別子として含み、使用不可を示す使用可否識別子を含むルール情報を追加のルール情報として生成し、
前記ルール情報検証部が、前記ルール情報記憶部に記憶される複数のルール情報と前記ルール情報追加部によって生成された追加のルール情報とに基づいて、前記複数のルール情報が整合しているか否かを検証する
ことを特徴とするルール検証装置のルール検証方法。
【請求項8】
特定のデータと特定のプログラムとのいずれかを対象アクセス先として識別するアクセス先識別子と、対象アクセス先を使用するプログラムを対象アクセス元として識別するアクセス元識別子と、対象アクセス元による対象アクセス先の使用を許可するか否かを識別する使用可否識別子とを含んだ複数のルール情報を記憶するルール情報記憶部と、
複数のプログラムと複数のデータとを関連付ける複数の依存関係情報であって、いずれかのプログラムを対象依存元として識別する依存元識別子と、対象依存元に関連付けられるデータまたはプログラムを対象依存先として識別する依存先識別子とを含んだ複数の依存関係情報を記憶する依存関係情報記憶部と
を備えるルール検証装置を機能させるルール検証プログラムであって、
前記依存関係情報記憶部に記憶される依存関係情報毎に依存先識別子と依存元識別子との組み合わせに一致するアクセス先識別子とアクセス元識別子との組み合わせを含んだルール情報が前記ルール情報記憶部に記憶されているか否かを判定し、当該ルール情報が前記ルール情報記憶部に記憶されていない依存関係情報を使用不可関係情報として特定する使用不可関係情報特定部と、
前記使用不可関係情報特定部によって特定された使用不可関係情報に基づいて、依存先識別子をアクセス先識別子として含み、依存元識別子をアクセス元識別子として含み、使用不可を示す使用可否識別子を含むルール情報を追加のルール情報として生成するルール情報追加部と、
前記ルール情報記憶部に記憶される複数のルール情報と前記ルール情報追加部によって生成された追加のルール情報とに基づいて、前記複数のルール情報が整合しているか否かを検証するルール情報検証部としてルール検証装置を機能させる
ことを特徴とするルール検証プログラム。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8】
image rotate

【図9】
image rotate

【図10】
image rotate

【図11】
image rotate

【図12】
image rotate

【図13】
image rotate

【図14】
image rotate

【図15】
image rotate

【図16】
image rotate

【図17】
image rotate

【図18】
image rotate

【図19】
image rotate

【図20】
image rotate

【図21】
image rotate

【図22】
image rotate

【図23】
image rotate

【図24】
image rotate