(57)【要約】      （修正有）【課題】インターネットに於けるあらゆるサービス形態に対応し、カバートチャネルを分析・制御する使い勝手の良いシステムを提供する。【解決手段】この情報フィルタは、アクセスされる関係データベース及びＸＭＬデータベースを格納するデータベースと、アクセスする主体、アクセスされる客体及びパミッションを有するアクセストリプルと、アクセスしようとする主体、アクセスされる客体及びアクセスされる客体を保有している組織体との関係をデータベース化した属性データベースと、カバートチャネル分析エンジンと、組織体と組織体の関係、組織体と主体の関係及び主体と客体の関係を示すアクセスルールをデータベース化したアクセスルールベースと、アクセス要求がある時にアクセスルールに従ってカバートチャネルか否かを決定する推論エンジンと、データベースへのアクセス要求に対するアクセス制御を実行する情報フィルタ部と、を備えて構成される。【選択図】図１
2007102645.tif 000002
【特許請求の範囲】
【請求項１】
アクセスされる関係データベース及びＸＭＬデータベースを格納するデータベースと、アクセスする主体、アクセスされる客体及びパミッションのデータを記憶するアクセストリプルと、アクセスしようとする主体、アクセスされる客体及びアクセスされる客体を保有若しくは所有している複数の組織体との関係をデータベース化した属性データベースと、前記パミッションを与えない場合と与える場合を分析するカバートチャネル分析エンジンと、前記各組織体間の関係、前記組織体と主体の関係及び前記主体と客体の関係を示すアクセスルールをデータベース化したアクセスルールベースと、アクセス要求がある時にアクセスルールベースに格納されたアクセスルールに従って前記カバートチャネルか否かを決定する推論エンジンと、前記データベースへのアクセス要求に対するアクセス制御を実行する情報フィルタ部と、を備えたことを特徴とする情報フィルタ。
【請求項２】
前記情報フィルタ部は、前記データベースへのアクセス要求に対するアクセス制御を実行するために、前記アクセストリプルを参照することを特徴とする請求項１に記載の情報フィルタ。
【請求項３】
前記アクセストリプルは、前記アクセス要求がある前に前記カバートチャネル分析エンジンによって、既にあるアクセストリプルの集合のカバーとチャネルを分析し、情報フィルタを設置したうえで、前記アクセス要求が生じた時、更にそのアクセストリプルで新たに生じるカバーとチャネルを分析し、前記パミッションを与えない場合と与える場合とを前記アクセスルールベースのルールによって判断することを特徴とする請求項１又は２に記載の情報フィルタ。
【請求項４】
前記情報フィルタの対象は前記関係データベースのスキーマ若しくはインスタンス、又は前記ＸＭＬデータベースのタグの中のタイトル、或いはこれらの組み合わせであることを特徴とする請求項１、２又は３に記載の情報フィルタ。
【請求項５】
前記情報フィルタの対象は情報の名前と情報の内容を扱うデータベースにおける情報の名前若しくは情報の内容、或いはこれらの組み合わせであることを特徴とする請求項１、２又は３に記載の情報フィルタ。
【請求項６】
データベースのデータに対するアクセス要求がある時、アクセスしようとする主体、アクセスされる客体及びアクセスされる客体を保有若しくは所有している複数の組織体との関係をデータベース化しておき、前記各組織体間の関係、前記組織体と主体の関係、前記主体と客体の関係を示すアクセスルールをデータベース化したアクセスルールベースを作成し、前記アクセス要求がある時にアクセスルールベースに格納されたアクセスルールに従って前記カバートチャネルか否かを決定することを特徴とする情報フィルタの制御方法。
【請求項７】
請求項６に記載の情報フィルタの制御方法をコンピュータが制御可能にプログラミングしたことを特徴とする情報フィルタの制御プログラム。
【請求項８】
請求項７に記載の情報フィルタの制御プログラムをコンピュータが読み取り可能な形式で記録したことを特徴とする記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報フィルタ及び情報フィルタの制御方法に関し、さらに詳しくは、Ｗｅｂアプリケーションシステムに於けるデータベースのアクセス制御に関するものである。
【背景技術】
【０００２】
現在、インターネットを介した電子商取引や銀行決済、或いは電子図書館の進展など様々なサービスが普及している。また近年、企業が互いに連携することにより、複数のサービスに対してユーザはシングルサインオンでポータルサーバーにアクセスできるサービスの提供が盛んに行われつつある。これらのサービスを実現するシステムは、一般にＷｅｂアプリケーションシステムと呼ばれている。しかし、この様なインターネットを介したコンピュータシステムへの不正なアクセス、或いはサービス提供側の内部による不正アクセスにより、個人情報が漏洩したり、或いは改竄される事件が大きな社会問題となっている。
この問題を防止するために、サービス提供者サイドでは、「ファイアウォールをインターネットの境界に設置してＩＰパケットをフィルタリングする」、「ユーザ認証、サーバ認証を行って互いに身元を確認する」、「データを暗号化してインターネット内部の盗聴を防止する」と言う技術を導入する。そして、更にシステムの最深部にあるデータベースへのアクセス制御によってユーザのアクセスを限定することにより最低限のガードを行っているが、これだけでは情報の読み書きに伴うカバートチャネルを防止することができない。そこで、カバートチャネルを分析する技術が必要である。
従来、この問題に対してセキュリティモデルを実現するメカニズムにより対処している。著名なセキュリティモデルには、Chinese Wallモデル、米国のBell and LaPadula(BLP)モデル、ＡＮＳＩ標準のRole Based Access Control(RBAC)モデル等がある。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかし上記のセキュリティモデルであるChinese Wallモデルは、カバートチャネルを分析しているが、競合する２社と仲介的な１社の間で情報をやりとりすると言う限定的な場合しか使えない。またＢＬＰモデルはカバートチャネルを分析制御の対象にせず、情報の流れを１方向にのみ限定する制御をするにとどまっている。即ちこれらのモデルは、モデルが対象とするサービスが軍用などの非常に制限されたサービス、つまり、セキュリティは高いが、使い勝手が悪いサービスに適用されている。またＲＢＡＣモデルは企業に於ける職位等、役割に対するパミッション（アクセス権（リード権、ライト権））を決めるモデルであり、カバートチャネルを積極的に扱っていない。
【０００４】
図９を参照してカバートチャネルの概念について説明する。図９（ａ）は図９（ｂ）のアクセス行列に基づいて複数のユーザ間を情報ファイルが転送されていく様子を示した図である。図９（ｂ）はユーザなどのアクセス主体（Ｓｕｂｊｅｃｔ）がアクセスされるファイルなどの客体（Ｏｂｊｅｃｔ）に対して持っているアクセス権（リード権、ライト権）を行と列に配置したアクセス行列の一例を示す図である。この図９（ｂ）において、アクセスを起こすアクセス主体は、列方向にＳ１、Ｓ２、Ｓ３、Ｓ４が配置され、ユーザ名やプログラム名などがこれに当たる。また、アクセスされる客体は、行方向にＯ１、Ｏ２、Ｏ３が配置され、ディレクトリ名やファイル名などの情報がこれに当たる。そして、枠内の対応位置にはそれぞれアクセス権が設定されていて、Ｒはリード権、Ｗはライト権、¬Ｒはリード権の否定をそれぞれ意味している。この例では、主体Ｓ１は客体Ｏ１、Ｏ２、Ｏ３をリードする権利があり、更にＯ２をライトする権利がある。主体Ｓ２は客体Ｏ１、Ｏ２、Ｏ３をリードする権利があり、更にＯ３をライトする権利がある。主体Ｓ３は客体Ｏ１、Ｏ２をリードする権利がなく、客体Ｏ３のみをリードする権利がある。また主体Ｓ４は客体Ｏ１、Ｏ２、Ｏ３をリードする権利のみがある。
【０００５】
このアクセス権に基づいて動作例を説明すると、ユーザＳ１が秘密情報４０が記載されたファイルＯ１をファイルサーバ４１からリードする。次にユーザＳ１がファイルＯ１をファイルＯ２にコピーペーストすると、この時点でファイルＯ２には秘密情報４０が記載された内容がライトされる。そのファイルＯ２をユーザＳ２がリードして、ファイルＯ３にコピーペーストする。この時点でファイルＯ３には秘密情報４０が記載された内容がライトされる。次にユーザＳ３はファイルＯ３をリードする権利があるので、ファイルＯ３をリードする。ここまでは図９（ｂ）のアクセス行列に従った動作であるが、本来ファイルＯ１をリードする権利がないユーザＳ３が実質的にファイルＯ１の秘密情報４０を読み取ったことと等価となり、秘密情報がこの時点で漏洩したことになる。一般にこの様な現象をカバートチャネル（Covert Channel）と言う。
そこで、インターネットに於けるあらゆるサービス形態に対応し、カバートチャネルを分析・制御する使い勝手の良いシステムが求められている。また、アクセスされるデータが格納されるデータベースも、関係データベースだけでなく、ＸＭＬデータベースにおいて特にカバートチャネルが問題となるが、これら２種類併用する場合にも対処しなくてはならない。（一般にその他のあらゆる形態のデータベースにおいてもカバートチャネルの問題がある）。
本発明は、かかる課題に鑑み、データベース（関係データベース、ＸＭＬデータベース等）のカバートチャネルを分析・制御するための情報フィルタをシステムに備えることにより、インターネットに於けるあらゆるサービス形態に対応し、カバートチャネルを分析・制御する使い勝手の良いシステムを提供することを目的とする。
【課題を解決するための手段】
【０００６】
本発明はかかる課題を解決するために、請求項１は、アクセスされる関係データベース及びＸＭＬデータベースを格納するデータベースと、アクセスする主体、アクセスされる客体及びパミッションのデータを記憶するアクセストリプルと、アクセスしようとする主体、アクセスされる客体及びアクセスされる客体を保有若しくは所有している複数の組織体との関係をデータベース化した属性データベースと、前記パミッションを与えない場合と与える場合を分析するカバートチャネル分析エンジンと、前記各組織体間の関係、前記組織体と主体の関係及び前記主体と客体の関係を示すアクセスルールをデータベース化したアクセスルールベースと、アクセス要求がある時にアクセスルールベースに格納されたアクセスルールに従って前記カバートチャネルか否かを決定する推論エンジンと、前記データベースへのアクセス要求に対するアクセス制御を実行する情報フィルタ部と、を備えたことを特徴とする。
また、本発明ではデータベースを関係データベース、ＸＭＬデータベースとして説明するが、オブジェクト指向データベース等、他のデータベースでも「情報の名前」と「その内容」を「情報の名前」から検索すると言うデータベースの本質的な機能を持つ全てのデータベースが本発明の対象となる事は言うまでもない。
本発明の情報フィルタは、データベースのデータに対するアクセス要求がある時、アクセスしようとする主体、アクセスされる客体及びアクセスされる客体を保有している組織体との関係を属性データベースにデータベース化しておき、組織体と組織体の関係、組織体と主体の関係、主体と客体の関係からカバートチャネルであるか否かを判定するルールベースをアクセスルールベースにより作成し、アクセス要求がある時にアクセスルールに従ってカバートチャネルか否かを決定するものである。
【０００７】
請求項２は、前記情報フィルタ部は、前記データベースへのアクセス要求に対するアクセス制御を実行するために、前記アクセストリプルを参照することを特徴とする。
アクセストリプルは＜主体、客体、パミッション＞の３つの組合せである。アクセストリプルの具体例は、＜氏名、ファイル名（設計書）、ＲＥＡＤ＞であれば、氏名の対象がファイル名をＲＥＡＤする事を表し、或いは＜役職（部長）、人事ファイル名、（ＲＥＡＤ、ＷＲＩＴＥ）＞と記されている場合は、部長が人事ファイル名を（ＲＥＡＤ、ＷＲＩＴＥ）する事を表す。
本発明の情報フィルタは、アクセストリプルが有するこれらのデータを参照することにより、パミッションが与えられるか否かを的確に判断することができる。
請求項３は、前記アクセストリプルは、前記アクセス要求がある前に前記カバートチャネル分析エンジンによって、既にあるアクセストリプルの集合（アクセス行列）のカバートチャネルを分析し、情報フィルタを設置下上で、前記アクセス要求が生じた時、更にそのアクセストリプルで新たに生じるカバートチャネルを分析し、前記パミッションを与えない場合と与える場合とを前期アクセスルールベースのルールによって判断することを特徴とする。
例えば、ある会社のアクセストリプルを作成する場合、アクセス要求は、１）会社内部のアクセストリプルを取りまとめて整理する。このとき、社員からのアクセス要求をシステム管理者が取りまとめる場合や、システム管理者が単独で設計する場合がある。２）作成したアクセストリプルの集合（アクセス行列）についてカバートチャネルを分析する。これによって会社内部だけのカバートチャネルの制御が可能になる。３）次に他の会社からのアクセス要求についてアクセストリプルとして受信し、社内のアクセス行列と照らして情報漏えいと情報改ざんがないかどうかカバートチャネルを分析する。
【０００８】
請求項４は、前記情報フィルタの対象は前記関係データベースのスキーマ若しくはインスタンス、又は前記ＸＭＬデータベースのタグの中のタイトル、或いはこれらの組み合わせであることを特徴とする。
ファイアウォールとの比較において、ファイアウォールはＩＰパケットのＩＰアドレスとポート番号を検出し、ＩＰアドレスとポート番号をフィルタ処理するだけである。つまり、データベースの「情報の名前」をＩＰパケットから分析する事は困難である。「情報の名前」を分析するためにはデータベースのアプリケーションソフトのレベルで実行しなければならない。本発明の情報フィルタはＲＤＢのスキーマ、インスタンス、又はＸＭＬデータベースのタグの中のタイトルの分析のためにＷｅｂアプリケーションシステムと言う上位層での実装を行う。従って「情報の名前」に相当するスキーマ、インスタンス、タグ等を直接的に分析制御することができる。
請求項５は、前記情報フィルタの対象は情報の名前と情報の内容を扱うデータベースにおける情報の名前若しくは情報の内容、或いはこれらの組み合わせであることを特徴とする。
【０００９】
請求項６は、データベースのデータに対するアクセス要求がある時、アクセスしようとする主体、アクセスされる客体及びアクセスされる客体を保有若しくは所有している複数の組織体との関係をデータベース化しておき、前記各組織体間の関係、前記組織体と主体の関係、前記主体と客体の関係を示すアクセスルールをデータベース化したアクセスルールベースを作成し、前記アクセス要求がある時にアクセスルールに従って前記カバートチャネルか否かを決定することを特徴とする。
本発明は請求項１と同様の作用効果を奏する。
請求項７は、請求項６に記載の情報フィルタの制御方法をコンピュータが制御可能にプログラミングしたことを特徴とする。
請求項８は、請求項７に記載の情報フィルタの制御プログラムをコンピュータが読み取り可能な形式で記録したことを特徴とする。
【発明の効果】
【００１０】
本発明によれば、情報フィルタは、データベースのデータに対するアクセス要求がある時、アクセスしようとする主体、アクセスされる客体及びアクセスされる客体を保有している組織体との関係を属性データベースにデータベース化しておき、組織体と組織体の関係、組織体と主体の関係、主体と客体の関係からカバートチャネルであるか否かを判定するルールベースをアクセスルールベースにより作成し、アクセス要求がある時にアクセスルールに従ってカバートチャネルか否かを決定するので、インターネットに於けるあらゆるサービス形態に対応し、カバートチャネルを分析・制御することができる。
【発明を実施するための最良の形態】
【００１１】
以下、本発明を図に示した実施形態を用いて詳細に説明する。但し、この実施形態に記載される構成要素、種類、組み合わせ、形状、その相対配置などは特定的な記載がない限り、この発明の範囲をそれのみに限定する主旨ではなく単なる説明例に過ぎない。
図１は本発明の情報フィルタの基本的な機能ブロック図である。この情報フィルタ１００は、アクセスされる関係データベース（ＲＤＢ）及びＸＭＬデータベース（ＸＭＬＤＢ）を格納するデータベース２と、アクセスする主体、アクセスされる客体及びパミッションのデータを記憶するアクセストリプル（アクセス行列）３と、アクセスしようとする主体、アクセスされる客体及びアクセスされる客体を保有若しくは所有している組織体との関係をデータベース化した属性データベース４と、パミッションを与えない場合と与える場合とを分析するカバートチャネル分析エンジン７と、組織体と組織体の関係、組織体と主体の関係及び主体と客体の関係を示すアクセスルールをデータベース化したアクセスルールベース５と、アクセス要求がある時にアクセスルールベースに格納されたアクセスルールに従ってカバートチャネルか否かを決定する推論エンジン６と、データベース２へのアクセス要求に対するアクセス制御を実行する情報フィルタ部１と、を備えて構成される。また、情報フィルタ部１とデータベース２の間には関係データベースのインスタンスを検出するＲＤＢインスタンス検出部２−１と、ＸＭＬボディのＲＤＢ呼び出し検出部２−２とを備えている。
そして情報フィルタ部１は、データベース２へのアクセス要求０に対するアクセス制御を実行するために、アクセストリプル３を参照する。アクセストリプルとは、アクセスする主体、アクセスされる客体、パミッションを指す。アクセストリプル（アクセス行列）３は、アクセス要求がある前に、カバートチャネル分析エンジン７によって、パミッションを与えない場合と与える場合とを分析しておく。この様な操作を情報フィルタと呼んでいる。この機能は情報をフィルタリングすると言う意味ではファイアウォールの機能と似ている様に見えるが、次の２点が大きく異なる。即ち、フィルタする情報がファイアウォールではＩＰパケットのＩＰアドレス、及びポート番号であるが、本発明の情報フィルタの対象は関係データベース（ＲＤＢ）のスキーマ、或いはインスタンスであり、又はＸＭＬデータベースのタグの中のタイトルである点と、カバートチャネル分析結果が反映される点である。
データベースのデータに対するアクセス要求がある時、アクセスしようとする主体、アクセスされる客体、アクセスされる客体を保有・所有している組織体（コミュニティと呼ぶ）との関係（これを属性と呼ぶ）を属性データベース４にデータベース化しておき、コミュニティとコミュニティの関係、コミュニティと主体の関係、主体と客体の関係を示すアクセスルールをデータベース化したアクセスルールベース５を作成し、アクセス要求がある時に、アクセスルールに従ってカバートチャネルかどうかを推論エンジン６により決定する。
【００１２】
図２はアクセス制御属性のリンク構造を示す図である。以下で定義する各属性は、属性の関係を持つと定義する。このように属性間を関係付けた構造が、属性データベース４の内容である。
以下、コミュニティ１０、主体１１、客体１２の属性の定義を示す。
＜コミュニティ１０の属性の定義＞
コミュニティ１０はコミュニティの名称を示す名前１０ａと言う属性を持つ。コミュニティ同士の関係については、競合１０ｂという属性を持ち、競合するか否かと言う関係がコミュニティの属性として重要である。競合１０ｂは他のコミュニティとの関係で競合・連携・独立の何れかに設定される。
Ｆｅｄｅｒａｔｉｏｎ：連携しているコミュニティ名
Ｃｏｎｆｌｉｃｔ：競合しているコミュニティ名
Ｄｅｐｅｎｄｅｎｃｅ：他のコミュニティに従属するコミュニティ名
Ｉｎｄｅｐｅｎｄｅｎｃｅ：単独で存在するコミュニティ名
またコミュニティ内は主体に対する役割１０ｃ、階層１０ｄと言う属性を持つ。
＜主体１１の属性の定義＞
（１）名前属性：主体名
（２）競合属性：主体が属するコミュニティから刻印される競合属性
（３）役割属性：主体の役割
（４）階層属性：主体のセキュリティレベル
（５）プライベート属性：プライベートな情報に関する属性
＜客体１２の属性の定義＞
客体１２の属性は、主体１１の属性が刻印された競合、所有、階層、役割、プライベートと言うアクセス制御属性の他に、メタ言語・コノーテーションと言う構造を持つ。
（１）名前属性：データベースに格納するための名前
（２）所有属性：客体を所有する主体
（３）競合属性：主体から刻印される競合属性
（４）役割属性：客体にアクセス許可される主体の役割
（５）階層属性：客体のセキュリティレベル
（６）プライベート属性：客体が主体のプライベートな情報を含む場合に刻印される
【００１３】
＜客体の属性２：客体自体の属性の定義＞
メタ言語１２ｆ、コノーテーション１２ｇ：
Ｔｉｔｌｅ（客体名）：資源に与えられた名前
Ｓｕｂｊｅｃｔ：資源の内容の主題
Ｄｅｓｃｒｉｐｔｉｏｎ：資源の内容の説明
Ｔｙｐｅ：資源の内容の種類またはジャンル
Ｉｄｅｎｔｉｆｉｅｒ：特定の文脈での曖昧さの無い資源への参照
Ｓｏｕｒｃｅ：ある派生した資源から、元の資源への参照
Ｒｅｌａｔｉｏｎ：関連するリソースへの参照
Ｃｏｖｅｒａｇｅ：資源の範囲または領域
その他１２ａ：
Ｄａｔｅ：資源のライフサイクルに於けるイベントに関連する日
Ｆｏｒｍａｔ：資源の物理的または電子的形式
Ｌａｎｇｕａｇｅ：資源の内容を記述する言語
【００１４】
次にコミュニティ、主体、客体、及びそれらを構成する属性の構造、即ち、各属性間の関係を定義する。
＜アクセス制御属性のリンク構造の定義＞
１）コミュニティ１０の属性“競合”１０ｂはコミュニティ内名前属性を介して役割と階層にリンクする。
２）主体１１の属性と客体１２の属性“所有”１２ｅは、その主体１１がアクセス許可される客体１２にリンクする。
３）コミュニティ１０の属性“役割”１０ｃは、コミュニティ１０に属する主体１１の名前１１ａにリンクする。更にその主体１１がアクセス許可される客体１２にリンクする。
４）コミュニティの属性“階層”は、コミュニティに属する主体の名前にリンクする。更にその主体がアクセス許可される客体にリンクする。
５）主体１１との属性“プライベート”１１ｂは、その主体１１がアクセス許可される客体１２にリンクする。
尚、図２中、矢印は始点の属性が終点の属性に刻印されることを意味する。ここで刻印とは、始点が持つアクセス制御に必要な機能要求が終点の属性に転写されることを意味する。例えば、コミュニティ１０と主体１１の間の“役割”１０ｃ、１１ｃと言う属性は、コミュニティ１０（その名前）が要求するコミュニティ内の“役割”１０ｃと言う機能が、そのコミュニティ１０に参画する主体１１の“役割”１１ｃとなる。言い換えれば、矢印の始点の属性側から終点の属性側に対して“アクセス権限を始点側が指定する様にしてください”と指示していると見るのである。
【００１５】
また主体１１と客体１２の間は、主体１１を書き留めておく“書かれたもの”としての客体１２に対して、主体１１の属性“役割”１１ｃ、“階層”１１ｄが刻印される。また、主体１１と客体１２の特別な場合として、主体１１が客体１２を産出したという“所有”１２ｅ、或いは、主体１１が社会システムの中に於いて客体１２を交換することによって“所有”すると言う場合が刻印される。
また個人情報は、本来主体１１が持っているプライベートと言う個人情報を侵犯されない権利を“記述した”客体であり、主体から客体へのプライベート１１ｂと言う属性で刻印されるとする。この様に主体１１によって刻印される客体１２の属性は、Dublin Coreの中の属性の一部として必要十分にまとまっている。Dublin Coreとは図書館、博物館・美術館、インターネットなどいろいろなコミュニティからの草の根参加者によって構成されたDublin Core Metadata Initiative(DCMI)と呼ばれる組織によって進められてきたメタデータであり、ネットワーク上の情報資源の発見のためのメタデータとして広く認められ、いろいろな分野での利用が進んでいる。
客体１２の属性には、客体１２自体が持つ“記号と意味の構造”で分類されるメタ言語１２ｆ、コノーテーション１２ｇがある。この構造を導入しないとメタ言語１２ｆだけでは表現できないレトリック等、記号の象徴的意味をも扱うデータベースを構築できない。モデルではメタ言語１２ｆ、コノーテーション１２ｇの２つを属性として規定する。なぜなら、メタ言語１２ｆとしての客体１２と、コノーテーション１２ｇとしての客体１２では、アクセス権限の制約が異なるからである。
【００１６】
次に属性データベースの作成と、客体への書き込みによって記載される属性について説明する。図１の属性データベース４、および、図２のアクセス制御属性のリンク構造に於いて、システム管理者は、コミュニティ間の競合の関係、コミュニティ内の主体の役割などを属性データベース４に登録する。
主体１１はデータベース２にアクセスする時、可能な限り主体１１の属性を記入する。
データベースへ２の書き込みが許可された主体１１の属性は、客体１２の中のヘッダ部に書き込まれる。この様にして、主体１１の属性が客体１２に自動的に書き込まれる機能を有す。
客体１２の属性、所有、その他客体自身の属性は、客体１２に書き込む主体１１が入力する、あるいは、所定フォーマットのデータシートを使用する。
図１の属性データベース４と推論エンジン６は次のように使用される。
アクセス要求＝＜主体の属性、客体の属性、パミッション＞がデータベースに来る、データベースが設置されているコミュニティの属性と、アクセス要求主体が属しているコミュニティの関係、主体の属性間の関係、客体との関係、を属性データベースから引いてくる。
アクセス要求からだけでは記載が不十分な場合でも、推論エンジン（６）によって、属性間の関係を推論する。この場合、不足している情報があるゆえに、危険になる事がないような制御を行う。
【００１７】
次にアクセスルールベース５について説明する。図１のアクセスルールベース５に書き込むアクセスルールの一例を示す。
（アクセスルール）
２つの属性集合ξ、ηをコミュニティ、主体、客体の属性の任意の組合せであるとし、アクセス規則を適用するための比較をξ．Ｒ．η（．Ｒ．は２項関係を表す）とする。
（属性間のアクセスルール）
（１）競合属性はアクセスの判定に於いて全てに優先する。
（２）ξ．Ｒ．ηの少なくとも一方が役割属性と階層属性を２つ同時に含む時、ξ、η間のアクセスルールは階層属性のルールに従う。
（３）ξ．Ｒ．ηの少なくとも一方が所有属性を含む時、（１）（２）のルールの下で所有属性のルールに従う。
（４）ξ．Ｒ．ηの少なくとも一方がプライベート属性を含む時、（１）（２）のルールの下でプライベート属性のルールに従う。
【００１８】
（属性のアクセス禁止ルール）
［競合属性］
（１）ξとηがそれぞれコミュニティ名属性と役割属性の組合せを含み、かつそれらが競合関係であるならば、ξ．Ｒ．ηに於いて競合属性間のアクセスが禁止される。
［階層属性］
（１）ξが階層属性（セキュリティレベル）を含み、ηが階層属性を含まない時、かつ、セキュリティレベルが機密性を目的とするならば、ξ．Ｒ．ηによってξの階層属性からηへの客体流出が禁止される。
（２）ξが階層属性（セキュリティレベル）を含み、ηが階層属性を含まない時、かつ、セキュリティレベルがインテグリティを目的とするならば、ξ．Ｒ．ηによってξの階層属性からηへの客体流入が禁止される。
［所有属性］
（１）ξ．Ｒ．ηの一方、ηが所有属性を含む時、ηはξからのＷＲＩＴＥが禁止される。
（２）ξ．Ｒ．ηが所有属性を含み、所有関係に矛盾がない時、ξはηへＷＲＩＴＥ可能である。
（３）所有属性に対するＲＥＡＤのアクセスは、競合属性、階層属性に従う。
［プライベート属性］
（１）ξ．Ｒ．ηの一方、ηが所有属性を含む時、ηはξからのアクセスが禁止される。  
（２）ξ．Ｒ．ηの一方、ηが所有属性を含む時、かつ、ηのプライベート属性にアクセス許可された属性の値をξが持つ場合、ξ．Ｒ．ηのアクセスが許可される。
（３）ξ．Ｒ．ηに於いて、ξとηが同一のプライベート属性の値を持つ時、ξ．Ｒ．ηのアクセスが許可される。
図１のアクセスルールベース５と推論エンジン６は次のように使用される。
アクセス要求＝＜主体の属性、客体の属性、パミッション＞がデータベースに来る、属性データベースから、カバートチャネル分析に必要な属性を揃える（前述：図１の属性データベース４と推論エンジン６）。
アクセストリプル３に既に登録済みでない場合、カバートチャネル分析エンジン７でカバートチャネル分析する。その結果を、アクセスルールベース５に照らして判定する。判定は推論エンジン６で実行される。
判定結果は情報フィルタ部１へ転送され、アクセス要求に対して許可、不許可を処理する。即ち、許可ならデータベース２へのアクセスを許可する。不許可ならアクセス不許可をアクセス要求元に送り返す。
【００１９】
次に本発明の実施例について説明する。関係データベース（ＲＤＢ）、ＸＭＬデータベースに於いて、何をアクセストリプル３の客体とするかを示す。関係データベースでは、関数従属と言う特性に基づいて客体に従属関係が付く。また、ＲＤＢのインスタンスの中にＸＭＬデータベースを呼び出す機能がある場合は、図１のＲＤＢインスタンス検出部２−１でアクセス要求を再度検出し、情報フィルタ部１に戻す。図１のＸＭＬボディのＲＤＢ呼び出し検出部２−２では、ＸＭＬデータベースのデータのボディからＲＤＢを呼ぶリンクが張られている場合であり、これもアクセス要求と見做して情報フィルタ部１に戻す。図１のＸＭＬボディのＲＤＢ、ＸＭＬＤＢ呼び出し検出部２−２では、ＸＭＬデータベースのデータのボディからＲＤＢ、或いはＸＭＬＤＢを呼ぶリンクが張られている場合であり、これもアクセス要求と見做して情報フィルタ部１に戻す。
（実施例１）：ＸＭＬデータベースの場合
図３はＸＭＬデータフォーマットの模式図である。客体はタグ＜ｔｉｔｌｅ＞に書かれる客体の属性である。タグ＜Ｂｏｄｙ＞１３の内容はテキストや図表などの情報の内容である。＜Ｂｏｄｙ＞１３の中に、更にＵＲＬやＲＤＢの検索文が書き込まれる場合も想定される。その場合、アクセス要求主体はＵＲＬやＲＤＢの検索文が書き込まれているＸＭＬデータにアクセスした主体であるとして、再びアクセス要求が情報フィルタ部１に入力される。
【００２０】
（実施例２）：ＲＤＢの場合
図４はＲＤＢの関数従属の場合の図である。ＤＢの関数従属に於ける客体ＲＤＢ１４を、Ｒ（ａ０、ｂ０、ｃ０、ｄ０）、Ｒ（ａ１、ｂ１、ｃ１、ｅ１）、Ｒ（ｄ２、ｆ２、ｇ２）とする（図４）。この時、関数従属とＲＤＢのスキーマ１５のａが決まればｂが決まる事を言い、Ｒ（ａ）→Ｒ（ｂ）と書く。この時パミッションの割付はＲ（ａ）、Ｒ（ｂ）をそれぞれ客体とし、各々に割り振れるようにしておかないと、カバートチャネルが発生する。つまり、関数従属でＲ（ａ）→Ｒ（ｂ）が成り立つから、Ｒ（ａ）にアクセスできるならば、従属しているＲ（ｂ）にもアクセス可能である、と無制限にパミッションを割り振ると、カバートチャネルが引き起こされる。例えば、図４に於いて関数従属が、
Ｒ（ａ０、ｂ０、ｃ０）→Ｒ（ａ１、ｂ１、ｃ１）
Ｒ（ａ０、ｂ０、ｃ０）→Ｒ（ｄ０）
Ｒ（ｄ０）→Ｒ（ｄ２）
である場合、もし、Ｒ（ａ１、ｂ１、ｃ１、ｅ１）とＲ（ｄ２、ｆ２、ｇ２）が競合するコミュニティに属していると、
Ｒ（ｄ２）→Ｒ（ｄ０）、Ｒ（ｄ０）→Ｒ（ａ０、ｂ０、ｃ０）、Ｒ（ａ０、ｂ０、ｃ０）→Ｒ（ａ１、ｂ１、ｃ１）
となり、仲介的コミュニティにあるＲ（ａ０、ｂ０、ｃ０、ｄ０）を介してＲ（ｄ２）が競合コミュニティに漏えいする。
（実施例３）：ＲＤＢの場合
図５はＲＤＢのインスタンスごとのアクセス制御の場合の図である。ＲＤＢのインスタンスを介したアクセス制御ＲＤＢでは、インスタンスをまとめてタグを振り、インスタンスごとにアクセス制御する場合がある。この場合の客体は、Ｒ（τ）、Ｒ（ａ、ｂ、ｃ）である。
【００２１】
（実施例４）：ＲＤＢの場合
図６はＲＤＢのインスタンスにＵＲＬ或いはＸＭＬデータベースへのリンクが張ってある場合の図である。ＲＤＢのインスタンスにＵＲＬ、或いはＸＭＬデータベースへのリンクが張ってある場合、客体はＲ（ａ、ｂ、ｃ）である。インスタンスにＵＲＬ、ＸＭＬデータベースへのリンクがある場合、それを検知し、アクセス要求主体はＵＲＬやＸＭＬデータベースの検索文が書き込まれているＲＤＢにアクセスした主体であるとして、そのアクセス要求が、再び情報フィルタ部１に入力される。
（実施例５）：ＸＭＬＤＢの場合
図７はＸＭＬＤＢ内の文書のボディにＲＤＢへのリンクが刻印された場合を示す図である。ＸＭＬ文書のボディにはＵＲＬ等を用いて他のＷｅｂアプリケーションシステムのＤＢにアクセスすることが可能である。これは同一Ｗｅｂアプリ内にあるＤＢへのアクセスも同様にして実行される。
【００２２】
図８はＸＭＬボディのＲＤＢ、ＸＭＬＤＢ呼び出し検出部の詳細を示す図である。ＸＭＬパーサ部２−２−１は、ＸＭＬ文書を分析しデータベース２へのリンクを検出する。アクセストリプル検出部２−２−２は、ＸＭＬパーサ部２−２−１で検出されたデータベース２へのアクセス記述から、誰が（主体）、どういうデータに（客体）、この場合はＲＥＡＤしようとしているのかを抽出し、アクセストリプルとして取りまとめ、改めてカバートチャネル分析を実行する。カバートチャネル分析した結果、カバートチャネルが無ければＸＭＬパーサ分析したＸＭＬデータのアクセスを許可する。もしカバートチャネルが見つかれば、改めて情報フィルタをかけ、ＸＭＬパーサ分析したＸＭＬデータのアクセスを許可するか、或いはアクセスを禁止する。
この様な処理は、ＸＭＬボディの中にＸＭＬＤＢがリンクされている場合も同様にして実行される。またこの処理はＸＭＬＤＢにアクセスした時、実行される方式や、現在情報フィルタ部が把握しているアクセストリプル全てについて、ＸＭＬＤＢのボディを事前にチェックする方式が考えられる。
【図面の簡単な説明】
【００２３】
【図１】本発明の情報フィルタの基本的な機能ブロック図である。
【図２】アクセス制御属性のリンク構造を示す図である。
【図３】ＸＭＬデータフォーマットの模式図である。
【図４】ＲＤＢの関数従属の場合の図である。
【図５】ＲＤＢのインスタンスごとのアクセス制御の場合の図である。
【図６】ＲＤＢのインスタンスにＵＲＬ或いはＸＭＬデータベースへのリンクが張ってある場合の図である。
【図７】ＸＭＬＤＢ内の文書のボディにＲＤＢへのリンクが刻印された場合を示す図である。
【図８】ＸＭＬボディのＲＤＢ、ＸＭＬＤＢ呼び出し検出部の詳細を示す図である。
【図９】（ａ）は（ｂ）のアクセス行列に基づいて複数のユーザ間を情報ファイルが伝送していく様子を示した図であり、（ｂ）はユーザなどのアクセス主体がアクセスされるファイルなどの客体に対して持っているアクセス権（リード権、ライト権）を行と列に配置したアクセス行列の一例を示す図である。
【符号の説明】
【００２４】
１  情報フィルタ部、２  データベース、２−１  ＲＤＢインスタンス検出部、２−２  ＸＭＬボディのＲＤＢ呼び出し検出部、３  アクセストリプル、４  属性データベース、５  アクセスルールベース、６  推論エンジン、７  カバートチャネル分析エンジン、１００  情報フィルタ
【図１】
2007102645.tif 000003
【図２】
2007102645.tif 000004
【図３】
2007102645.tif 000005
【図４】
2007102645.tif 000006
【図５】
2007102645.tif 000007
【図６】
2007102645.tif 000008
【図７】
2007102645.tif 000009
【図８】
2007102645.tif 000010
【図９】
2007102645.tif 000011