JP2012519893A - アクセス制御ポリシの特定 - Google Patents

Abstract

アクセス制御ポリシを特定するためのシステムは、主体属性、対象、アクション及び認可を含み、アクセス制御ポリシ１０を規定する複数のポリシ規則をユーザが特定することを可能にするユーザインタフェース１３と、翻訳されたデータアクセス制御ポリシ１４を得るために、アクセス制御ポリシを機械可読のデータアクセス制御ポリシ言語に翻訳する翻訳手段と、アクセス制御ポリシ実施ユニット５０に翻訳されたデータアクセス制御ポリシを提供する出力部１１と、起こりうるアクセス要求の拒否及び許容を示す少なくとも２つの競合するポリシ規則を検出する競合検出手段２と、競合に関する情報をユーザに示す競合標示手段６と、競合解決を示すユーザからの情報を取り込む競合解決入力部７と、を有する。

Description

本発明は、アクセス制御ポリシを特定することに関し、特に、医療患者データにアクセスするためのアクセス制御ポリシを特定することに関する。

これまで、ヘルスケア施設は、患者医療情報を扱うために、紙ベースのシステムを使用していた。今日のコンシューマヘルスケアアーキテクチャは、オープンであり、相互接続され、柔軟性をもつ傾向がある。専門の医学分野において、これは、電子ヘルスレコード（Electronic Health Record、ＥＨＲ）システムをもたらした。ＥＨＲシステムの目的は、医療情報をすぐに使えるようにすることによってケアの品質を改善すること；健康情報を電子的に交換することによって、ヘルスケア状況におけるサービス供給の効率を高めること；健康情報の高まる利用可能性及び品質による一層安全な患者ケアを提供すること；及び手動のシステムに関連する費用を節約すること；である。

ＥＨＲシステムは、世界中のへルスケア施設においてすでに広く用いられているが、これは、個人健康情報が、多数のソースからアクセス可能でありえ、従ってセキュリティ違反のリスクのスケールを増大させることを示す。これらの理由は、プライバシ及び機密性の侵害に関する増加する懸念につながり、これは結果的に、ＥＨＲシステムに患者同意（consent）メカニズムを取り入れることになった。同意は、ヒポクラテスの誓いにその原点を有し、それらの患者に対して機密性を誓うために、ヘルスケア提供者によって採用されている。同意（consent）の辞書上の定義は、許可（permission）又は合意（agreement）である。同意は更に、アクションが含むもの、その見込まれる結果及び拒否のオプションの知識に基づく、アクションに対する明示的な又は暗黙的な合意として規定される。患者医療データは、患者の明示的な又は暗黙的な同意によってのみ、明らかにされることができる。この場合、明示的な同意は、口頭で又は書面で患者によって表現され、暗黙的な同意は、個人の行為から推定される。同意は、好適には、誰が患者レコードにアクセスすることができるか又は何の目的でアクセスすることができるかを特定する認可（authorizations）を含む。

患者のプライバシを保護するために、ＥＨＲシステムは、アクセス制御されることができ、これらのアクセス制御メカニズムは、アクセス要求を解決する際、個別の同意を考慮することができる。今日、個人の明示的な同意は、患者がそれに署名するよう求められる標準的な文書に筆記される形で得られ、かかる文書は、特にプライバシ問題（例えばＩＨＥ基本患者プライバシ同意）に関して、患者及びヘルスケア施設の権利及び義務を記述する。

特定の患者に関してＥＨＲシステムにおいて適用されるプライバシポリシは、例えば、ＸＡＣＭＬポリシの形で表現されることができる。ＸＡＣＭＬは、OASIS eXtensible Access Control Markup Language（ＯＡＳＩＳ拡張可能アクセス制御マークアップ言語）の略である。しかしながら、正しくＸＡＣＭＬポリシを特定することは困難である。自由変数タブローを使用してアクセス制御ポリシを解析する方法が、Hiroaki Kamoda他による「Access control policy analysis using free variable tableaux」（IPSJ Digital Courier, Vol. 2, May 2006, pages 207-221）に開示されている。

アクセス制御ポリシを特定するための改善されたシステムを有することが有利である。

この問題によりよく対処するために、本発明の第１の見地において、
−主体（サブジェクト）属性、対象（オブジェクト）、アクション及び認可を含み、アクセス制御ポリシを規定する複数のポリシ規則をユーザが特定することを可能にするユーザインタフェースと、
−アクセス制御ポリシを機械可読のデータアクセス制御ポリシ言語に翻訳して、翻訳されたデータアクセス制御ポリシを得る翻訳手段と、
−アクセス制御ポリシ実施ユニットに翻訳されたデータアクセス制御ポリシを提供する出力部と、
を有するシステムが提示される。

これは、ユーザが、ユーザフレンドリなやり方で、ユーザインタフェースを介してポリシ規則を特定することを可能にする。データアクセス制御ポリシ言語の知識を有することは必要でない。その代わりに、ポリシ規則は、ユーザインタフェースを介して特定されることができ、その後、ポリシ規則は、自動的にデータアクセス制御ポリシ言語に翻訳され、実行のために実施ユニットに提供される。翻訳が自動的に実施されるので、翻訳の生成において生じるエラーが、より少なくて済む。

競合検出手段が、起こりうるアクセス要求の拒否及び許容をそれぞれ示す少なくとも２つの競合するポリシ規則を検出するために提供されることができる。これは、エラーのないポリシを生成することを助ける。その理由は、規則が、実際のアクセス要求に最初に適用される前に、競合が、ポリシ特定ステージにおいて検出されるからである。競合検出手段は、ユーザによって新しいポリシ規則が入力されるとすぐに活性化されるように構成されることができ、これは、ユーザが、ポリシを特定している間に即座のフィードバックを得ることを可能にする。

競合検出手段は、特定の主体による特定の対象に対する特定のタイプのアクセスの拒否及び許容をそれぞれ示す競合するポリシ規則を検出するように構成されることができる。特定の対象に対し特定のタイプのアクセスを実施するための、この特定の主体によるアクセス要求の認可は、一方のポリシ規則がそれを許し、別のポリシ規則がそれを拒否するので、解決されることができない。従って、これは、競合するポリシ規則を検出するための効果的なやり方である。

システムは更に、少なくとも２つの競合するポリシ規則の競合を解決して、修正されたアクセス制御ポリシを得るための競合解決手段を有することができ、競合解決手段は、競合に関する情報をユーザに示すための競合解決手段と、競合解決を示すユーザからの情報を取り込むための競合解決入力部と、を有する。これは、ユーザの要望に従って競合を解決するための効率的なやり方を提供する。

競合解決手段は、競合を解決するために、予め決められた競合解決規則の組を競合するポリシ規則に適用する自動競合解決手段を有し、競合解決入力部は、競合解決規則の組が競合を解決するために十分でない場合に適用される。これは、ユーザが、アクセス制御ポリシを修正するよう求められる回数を低減する。

競合解決手段は、１つの競合するポリシ規則が別の競合するポリシ規則よりも高いプライオリティを有することを示すユーザからの情報を取り込む手段を有することができる。これは、ユーザが、ポリシの実施の間、競合が実際に生じる場合に競合する規則のうちどちらが「勝つか」を特定することを可能にする。

競合検出手段は、ユーザによって示されるポリシ規則のプライオリティの矛盾を検出する手段を有することができる。１つの競合を修正することによってもたらされるプライオリティは、別の競合、すなわちポリシ規則のプライオリティの矛盾、をもたらすことがある。ここでの検出は、この競合を同様に解決することを可能にする。ユーザは、例えばプライオリティを更に洗練することによって、この新しい競合を解決するよう求められることができる。

ユーザインタフェースは、判定テーブルの形でアクセス制御ポリシを表現するように構成されることができる。判定テーブルは、アクセス制御ポリシを特定するための比較的直感的なやり方である。翻訳は、判定テーブルをアクセス制御ポリシ言語に翻訳することを含みうる。競合検出手段及び競合解決手段は、アクセス制御ポリシ言語への翻訳の前に、判定テーブル上で動作するように構成されることができる。

競合検出手段は、ユーザによるポリシ規則の追加又は変更後に活性化されるように構成されることができる。このようにして、迅速なフィードバックがユーザに提供されることができる。

競合検出手段は、競合する規則のうち少なくとも一方において言及される主体属性に基づいて、２つの規則が同じ主体に適用されるかどうかを検証するように構成されることができる。主体属性は、例えば役割（role）又はグループを含みうる。その場合、ポリシ規則は、特定の役割を有する又は特定のグループのメンバである主体に適用されることができる。競合するポリシは、少なくとも１つの主体を共通に有しており、競合する規則のうち一方は、アクセスを拒否し、他方の競合する規則は、主体によるアクセスを許すことができる。

機械可読のセキュリティポリシ言語は、拡張可能アクセス制御マークアップ言語ＸＡＣＭＬを含みうる。ＸＡＣＭＬは、適切なアクセス制御ポリシ言語である。

アクセス制御ポリシ実施ユニットは、翻訳されたアクセス制御ポリシを受け取る入力部と、受け取られたアクセス制御ポリシを実施するためのポリシ実施手段と、を有する。これは、ポリシの効果的な実施を可能にする。

出力部は、広域ネットワークを介して、アクセス制御ポリシ実施ユニットに翻訳されたアクセス制御ポリシを送信するように構成されることができ、かかるアクセス制御ポリシ実施ユニットは、ユーザインタフェース、翻訳手段及び出力部から遠隔している。これは、競合フリーであって、アクセス制御ポリシ言語に翻訳されるポリシをセットアップし、アクセス制御ポリシ実施ユニットにポリシを送信する遠隔クライアントに適した構成である。

医療患者データに関するアクセス制御ポリシを特定する方法は、
−主体属性、対象、アクション及び認可を含み、アクセス制御ポリシを規定する複数のポリシ規則をユーザが特定することを可能にするステップと、
−アクセス制御ポリシを機械可読のデータアクセス制御ポリシ言語に翻訳して、翻訳されたデータアクセス制御ポリシを得るステップと、
−アクセス制御ポリシ実施ユニットに、翻訳されたデータアクセス制御ポリシを提供するステップと、
を含みうる。

コンピュータプログラム製品は、上述される方法の各ステップをプロセッサシステムに実施させるためのコンピュータ実行可能命令を含むことができる。

本発明のこれらの及び他の見地は、図面を参照して更に説明され、記述される。

アクセス制御ポリシを特定するためのシステム及びアクセス制御ポリシ実施ユニットの態様を示すブロック図。 アクセス制御ポリシを特定する方法の各ステップを示すブロック図。 アクセス制御ポリシを特定するシステムの他の態様を示すブロック図。 競合検出の方法の各ステップを示すブロック図。

現代のヘルスケアＩＴシステムにおいて、患者同意は、患者のヘルスデータに対するアクセスを管理するセキュリティメカニズムによって考慮されることができる。ＸＡＣＭＬは、アクセス制御ポリシを特定するためにますます使用されるようになっているＸＭＬ言語である。しかしながら、正しいＸＡＣＭＬポリシを特定することは、その複雑さのため骨が折れる。患者同意に関する高レベルのプライバシポリシを、ＸＡＣＭＬのような機械可読のポリシ言語に自動的に翻訳する方法が、ここに記述される。しかしながら、ＸＡＣＭＬは、非限定的な例にすぎない。この方法は、潜在的な競合の検出及びそれらの解決を含むことができる。

コンシューマウェルネス及びヘルスケア分野において、情報通信技術の進歩は、テレメディシン（遠隔医療）及び遠隔患者モニタリングを含む遠隔ヘルスケアサービス（テレヘルス）を実現可能にしている。多くのサービスが、すでに、測定装置が家庭用ハブを介して遠隔バックエンドサーバに接続されるテレヘルスインフラストラクチャを展開している。ヘルスケア提供者は、このアーキテクチャを使用して遠隔的に測定データにアクセスし、患者を助ける。例は、疾患管理サービス又は緊急時応答サービスである。

測定装置、家庭用ハブ及びバックエンドサービスの相互運用性は、サービスの成功した動作を実現可能にするために重要である。測定装置、家庭用ハブ（アプリケーションホスティング）装置、オンラインヘルスケア／ウェルネスサービス及びヘルスレコードシステム（ＰＨＲ／ＥＨＲ）の間のプロトコルは、標準化されることができる。データフォーマット及び交換の問題の次に、セキュリティ及び安全性の問題が対処されうる。

家庭用ハブ及びバックエンドサービスを含むこのようなアーキテクチャにおいて、測定装置及びアプリケーションホスティング装置は、多少特別な態様でさまざまな異なるサービスに接続することが可能であるべきである。機密性のある患者データは、患者の一生を通じて収集され、疾患管理、ヘルス及びフィットネス、並びに高齢者自立サービスによって実施される測定が、患者のヘルスレコードに含まれうる。多くのオープンで且つ相互運用性のあるシステムを通じた行程において、機密性のあるヘルスデータは、患者が同意した目的のためにのみ使用されるべきであり、すなわち患者のプライバシポリシに従って使用されるべきである。

統制されたヘルスケア分野において実際に使用される筆記による同意は、静的であり、各個別の患者についてカスタマイズされるものではなく、従って、コンシューマウェルネス及びヘルスケア場面における同意及び患者プライバシポリシを十分には表わさない。アクセス制御メカニズムにおいて考慮されるべき患者同意のために、アクセス制御ポリシは、好適には、電子形式で表現される。更に、同意は、（その実施を容易にするために）アクセス制御機構によって認識される形で表現される必要がある。

これを行うやり方は、機械可読形式でポリシを特定することである。機械可読形式でポリシを表現する特定のセキュリティポリシ言語が存在する。ＸＡＣＭＬは、ヘルスケア分野において重要なアプリケーションを見出しているＯＡＳＩＳによって開発された１つの言語である（ＨＬ−７、ＨＩＴＳＰ）。しかしながら、アクセス制御ポリシは、それらが管理する情報の量及び複雑さのため複雑であるので、正しいＸＡＣＭＬポリシを特定することは、骨の折れることである。従って、高レベルの患者同意／プライバシポリシを十分に表わし、それを、アクセス制御及びＤＲＭ（デジタル権利管理）メカニズムによって使用可能な機械可読のＸＡＣＭＬポリシに翻訳することが、有利である。好適には、翻訳されたアクセス制御ポリシが意図されたとおりであり、競合を有しないことをチェックするための方策がとられる。

図１は、アクセス制御ポリシ１０を特定するシステム１を示している。システム１は、例えば、移動電話又はパーソナルコンピュータ又はラップトップのような家庭用装置において実現されることができる。システム１は、例えば病院内の端末において実現されることもでき、その場合、患者又は看護師が、システム１の動作を制御する。システム１は、例えば患者モニタリング機器の一部であるハードウェアのような、他のハードウェアを使用して実現されることもできる。システム１は、ユーザインタフェース１３を含む。ユーザインタフェース１３は、例えばグラフィカルユーザインタフェース又はテキストインタフェースでありうる。ユーザインタフェース１３は、複数のポリシ規則を特定するためにユーザが使用することができるボタン及び／又はテキスト入力フィールドのような、ユーザインタフェース要素を提供する。このようなポリシ規則は、患者に関する医療又は個人データにアクセスするための許可（permissions）を規定することができる。ポリシ規則は、例えば主体属性、対象、アクション及び認可を含むことができる。ここで、主体属性は、ポリシ規則がどの主体に適用されるかを規定する。より具体的には、主体属性は、主体がデータにアクセス可能である必要があるという属性を規定する。それは、名前、役割、ロケーション、免状、証明書、その他でありうる。主体は、ポリシ規則が個人又はエンティティに関して実施されるべきである当該個人又はエンティティでありうる。同時に、ユーザインタフェースを介して入力されるポリシ規則の組は、高レベルのアクセス制御ポリシ１０を規定することができる。このような高レベルのアクセス制御ポリシは、人間可読でありうるが、機械によって容易に使用される形式ではないことがある。このようなアクセス制御ポリシは、例えば特定の患者に関するデータのような、或るデータ部分のアクセス制限を規定するポリシ規則の集まりをさすことができる。こうして、アクセス制御ポリシ１０は、ユーザインタフェースを介したユーザ入力に少なくとも部分的に基づいて、確立される。アクセス制御ポリシ１０は更に、データに関して責任をもつ施設のポリシによって、部分的に規定され又は制約されることができ、例えば、データを保管し又はデータに基づいて患者にケアを提供する施設は、患者が患者のパーソナルアクセス制御ポリシ１０に組み込むことができる予想されるポリシ規則を制限することができる。

システム１は、翻訳されたデータアクセス制御ポリシ１４を得るために、アクセス制御ポリシ１０を機械可読のデータアクセス制御ポリシ言語に翻訳する翻訳手段９を有することができる。ユーザが、ユーザインタフェース１３を介してアクセス制御ポリシ１０を特定した後、ユーザは、例えば、アクセス制御ポリシ１０が完全であり、完成されたことを示すボタンを押す。その後、翻訳手段９は、アクセス制御ポリシ１０のポリシ規則を、標準ポリシ実施手段によって処理されることができる言語記述に翻訳する。標準ポリシ実施手段は、アクセス制御ポリシ言語で規定される翻訳されたアクセス制御ポリシ１４を処理するように構成される。代替として、翻訳手段９は、ユーザインタフェース１３を介してアクセス制御ポリシを規定する処理の間、翻訳１４を更新するように構成されることができる。例えば、ユーザがポリシを追加し、変更し又は削除するたびに、翻訳手段９は、翻訳されたアクセス制御ポリシ１４のテキストを追加し、変更し又は削除する。

システム１は更に、アクセス制御ポリシ実施ユニット５０に翻訳されたデータアクセス制御ポリシ１４を提供するための出力部１１を有することができる。例えば、出力部は、システム１が接続されることができるネットワークを介して、データを送信するように構成される。このようなネットワークは、例えばインターネットのような広域ネットワーク又はローカルエリアネットワークでありうる。別の構造において、システム１は、アクセス制御ポリシ実施ユニットに部分的に又は完全に組み込まれることができる。そのような場合、出力部は、内部システムメッセージによって、又は、例えば特定のロケーションにそれを保存することによって、翻訳されたアクセス制御ポリシ１４をアクセス制御ポリシ実施ユニット５０に提供するように構成されることができる。

システム１は、競合検出手段２を有することができる。競合検出手段２は、競合するポリシ規則がアクセス制御ポリシの中に存在するかどうかを検出するように構成される。競合検出手段２は、起こりうるアクセス要求の拒否及び許容をそれぞれ示す少なくとも２つの競合するポリシ規則を検出するように構成される。通常、すべてのアクセス要求は許可又は拒否のいずれかに決められるべきであるので、これらのポリシ規則は競合する。競合検出手段２は、特定の主体による特定の対象に対する特定のタイプのアクセスの拒否及び許容を示す規則を探すことによって、競合するポリシ規則を検出するように構成されることができる。このようなタイプのアクセス、対象及び主体は、ポリシ規則によって暗黙的に規定されることができる。例えば、主体は、幾つかの主体が有しうる役割又は主体のグループのような主体属性に関して、ポリシ規則に規定されることができる。２つの規則の主体属性が異なる場合、なお１又は複数の同じ主体が異なるポリシ規則によってカバーされることがありえ、これは、競合する許可を引き起こしうる。

（ユーザインタフェース１３によって提供される）競合検出手段２への入力は、属性（例えば主体属性）の間で起こりうるオーバラップを示すことができる属性テーブルの形でありうる。このようなオーバラップを検出する際、例えば外部属性オーソリティ又はアイデンティティ管理システムから取得されることができる追加情報が、使用されることができる。このような外部属性情報は、例えば主体の役割に関する情報を含みうる。

競合解決手段５が、少なくとも２つの競合するポリシ規則の競合を解決するために提供されることができる。このようにして、修正されたアクセス制御ポリシが得られる。図面において、アクセス制御ポリシと修正されたアクセス制御ポリシの間の区別はなされていない。両方とも１０と示されている。競合解決手段は、競合に関する情報をユーザに示すための競合標示手段６を有することができる。例えば、競合するポリシ規則は、強調表示されることができる。更に、規則が競合している（複数の）主体又はケースは、競合が厳密に何であるかを明らかにするために、ユーザに示されることができる。競合解決入力部７が、競合解決を示すユーザからの情報を取り込むために提供されることができる。ユーザは、例えば、（複数の）競合するケースに関して追加のポリシ規則を加え、既存のポリシ規則を調整することを決定することができ、それにより、それらはもはや競合するケースには当てはまらない。

競合解決手段５は、自動競合解決手段８を有することができる。この手段８は、ユーザを巻き込むことなく、競合する規則の少なくとも幾つかを自動的に操り、自動生成された解決をユーザに提案し又は競合解決を十分に自動的に実現することができる。自動競合解決手段８は、競合を解決するために、予め決められた競合解決規則の組を競合するポリシ規則に適用するように構成される。予め決められた競合解決規則の組が、競合を解決しない場合、競合解決標示手段６及び／又は競合解決入力部７が適用されることにより、ユーザが手動で競合を修正することを可能にすることができる。

競合解決入力部７は、１つの競合するポリシ規則が別の競合するポリシ規則よりも高いプライオリティを有するというユーザからの情報を取り込む手段１２を有する。これは、実施の間、競合する状況が発生する場合、プライオリティを有するポリシ規則が他方のポリシ規則に代わって適用されることを意味する。

競合検出手段２は、ユーザによって示されるポリシ規則のプライオリティの矛盾を検出する手段４を有することができる。プライオリティが２回以上付与されなければならない場合、プライオリティの矛盾が引き起こされることがある。このような矛盾は、正しい認可がポリシ実施フェーズの最中に確立されることができないという新たな状況をもたらすので、解決されることが好ましい。

ユーザインタフェースは、判定テーブルの形でアクセス制御ポリシ１０を表現するように構成されることができる。このような判定テーブルは、各行にポリシ規則を含むことができ、各列は、ポリシ規則の特定の属性に関連しうる。例えば、１つの列は、各ポリシ規則の主体属性を含むことができる。このような列は、どの主体がポリシ規則によって認可を許諾され又は拒否されるかを制御する。別の列は、対象を含むことができる。対象は、アクセスが許諾され又は拒否されるデータを規定する。別の列は、効果を含むことができ、すなわち、アクセスが許可されるか又は拒否されるかを含むことができる。より多くの列が、判定テーブルに規定されることができる。一例が、この記述の他の箇所に与えられている。

競合検出手段２は、ユーザによるポリシ規則の追加又は変更の後に活性化されるように構成されることができる。このようにして、競合の検出及び／又は修正は、対話的なものにされる。競合する規則は、それらが生成された直後に識別されることができる。

競合検出手段２は、競合する規則の少なくとも１つにおいて言及される主体属性に基づいて、２つの規則が同じ主体に適用されるかどうかを検証するように構成されることができる。主体属性は、ポリシ規則がどの主体に適用されるかを制御する。原則的に、競合するポリシ規則の両方が関連する少なくとも１つの主体がある場合のみ、規則は競合しうる。

機械可読のセキュリティポリシ言語は、拡張可能アクセス制御マークアップ言語ＸＡＣＭＬを含みうる。翻訳手段９は、アクセス制御ポリシ１０をＸＡＣＭＬポリシに翻訳するように構成されることができる。翻訳手段９は、判定テーブルからのアクセス制御ポリシ１０を、ＸＡＣＭＬポリシに翻訳するように構成されることができる。

更に、アクセス制御ポリシ実施ユニット５０が提供されることができる。これは、出力部１１と連携して、上述した通信手段によってシステム１と接続されることができる。アクセス制御ポリシ実施ユニット５０は、出力部１１を介してシステム１から翻訳されたアクセス制御ポリシを受け取るためのアクセス制御ポリシ入力部５１を有することができる。更に、一例として、アクセス制御ポリシ実施ユニット５０は、受け取られたアクセス制御ポリシを実施するポリシ実施手段５２を有することができる。このポリシ実施手段５２は、翻訳されたアクセス制御ポリシ１４を処理し、その中に表現されている規則を適用して、特定のアクセス要求を許可し及び／又は拒否することができる。ポリシ実施ユニット５０は更に、アクセス要求を受け取り、ポリシ実施手段５２を介して認可を検証し、ポリシ実施手段５２の出力に依存して、要求されるようにアクセスを実行し又はアクセス要求を拒否するためのアクセス要求処理手段５３を有することができる。しかしながら、これは、アーキテクチャの一例にすぎない。例えば、ＸＡＣＭＬ参照アクセス制御システムアーキテクチャを参照することも可能である。

システム１の出力部１１は、広域ネットワークを介して、アクセス制御ポリシ実施ユニットに翻訳されたアクセス制御ポリシを送信するように構成されることもできる。アクセス制御ポリシ実施ユニット５０は、例えばユーザインタフェース１３、翻訳手段９及び出力部１１を含むシステム１から遠隔している。このようにして、アクセス制御ポリシが、システム１によって準備され、アクセス制御ポリシ実施ユニット５０に送信され、そこで、ポリシが直ちに適用されることができる。

図２は、アクセス制御ポリシを特定する方法を示している。方法は、ユーザが、主体属性、対象、アクション及び認可を含む複数のポリシ規則を特定することを可能にするステップ２０１を含む。かかるポリシ規則は、アクセス制御ポリシを規定する。方法は更に、翻訳されたデータアクセス制御ポリシを得るために、アクセス制御ポリシを機械可読のデータアクセス制御ポリシ言語に翻訳するステップ２０２を含む。方法は更に、アクセス制御ポリシ実施ユニットに、翻訳されたデータアクセス制御ポリシを提供するステップ２０３を含む。方法は、方法の各ステップをプロセッサシステムに実施させるためのコンピュータ実行可能命令を含むコンピュータプログラム製品として実現されることができる。

図３は、高レベルのプライバシポリシを、ＸＡＣＭＬポリシのような機械可読ポリシに翻訳する方法であって、例えば潜在的な競合の検出及びそれらの解決を含む方法を示している。この方法は、
−グラフィカルユーザインタフェースを介して、判定テーブル３０２においてプライバシポリシを特定するステップ３０１；
−判定テーブル３０２及び属性テーブル３０３（例えば病院又は全国的なＥＨＲインフラストラクチャのような外部情報に基づいて生成される）を使用して、潜在的な競合を検出するステップ３０４；
−競合解決ポリシ３０６及び／又はユーザ入力３０７を使用して、検出された競合３０５を対話的に解決し、その結果として、判定テーブルのポリシ規則の優先付けされたリスト３０９を生じさせるステップ３０８；及び
−判定テーブルからのポリシ規則の優先付けされたリスト３０９をＸＡＣＭＬポリシ３１１に翻訳するステップ３１０、
を含む。

グラフィカルユーザインタフェースを介して判定テーブルにプライバシポリシを特定するステップは、以下のように実現されることができる。患者同意は、エンティティが、情報に対して何らかのアクションを実施するために、患者の医療情報の一部又は全体に対するアクセスを許諾されるか又は拒否されるかを特定する認可及びこれが行われるべきである条件を表わす。従って、患者は、アクセス制御の間に実施されるであろう認可として、同意のこれらの要素を特定しなければならない。同意の以下の要素が識別されることができる：

−許諾者（grantor）：これは、同意を許諾する人（患者又は患者の法律管理人）である。
−被許諾者（grantee）：これは、同意が許諾される個人、役割又はグループである。
−患者：これは、被許諾者によって患者のデータがアクセスされる当該患者である。
−アクション：これは、被許諾者がデータに対して実施することが許容される又は許容されないアクション又は操作である。このような操作の例は、読み取り、書き込み、収集、アクセス、使用、開示、訂正又は削除を含む。
−データ：患者の医療情報の全部又は一部を表す表現。
−効果：これは、「許可」又は「拒否」でありうる。
−目的：これは、被許諾者がデータにアクセスすることができる目的を特定する。これらは、例えば「処置」、「支払い」、「操作」、「リサーチ」、「公衆衛生」、「計画」、「品質尺度」、「第三者によるヘルスステータス評価」及び「マーケティング」を含むことができる。他の目的が、ニーズに従って規定されることができる。
−コンテクスト：これは、ポリシ規則が適用されるコンテクストを特定する。２つの例示的なコンテクストが識別されている；被許諾者は、「通常」又は「緊急」状況において患者のデータにアクセスすることができる。他のコンテクストが、ニーズに従って規定されることができる。
−有効性期間：これは、ポリシ規則が有効である期間である。

同意は、患者が判定テーブルを埋めることを助けるグラフィカルユーザインタフェースを使用して、特定されることができる。以下の判定テーブルに、同意の一例が特定されている。判定テーブルの最初の２つの行は、デフォルト認可を含み、残りの行は、デフォルト認可に対する例外である特定の認可を含む。例外が適用されない限り、デフォルト認可が、アクセスを許容する一般的な許可でありうる。表１の例において、デフォルト認可は、一般にはアクセスが許容されないことを特定する（一番上の２つの行における効果「−」）。

表１：判定テーブル（一番上の行において、act.はaction（アクション）の略であり、Vは、validity period in years（年単位の有効性期間）の略であり、Tは、Authorization type（認可タイプ）の略である。一番右の列において、Aは、Access（アクセス）の略であり、Dは、Delegate（権限委譲）の略である。「効果」は、認可を意味し、「＋」は許可を意味し、「−」は拒否を意味する。）

２又はそれ以上の認可の目標が、同じ対象に適用される肯定及び否定の認可のため、同時に果たされることができない場合、ポリシの競合が起こりうる。一般に、競合検出のゴールは、発生した実際の競合を識別し及び／又は潜在的な競合が将来発生しうることを予測することである。その次に、実際の又は潜在的な競合が、解決プロセスに伝えられることができる。競合は、反対の認可を有する認可ポリシの主体、リソース、アクション及び条件要素のオーバラップに起因しうる。

競合検出のために、属性テーブルが使用されることができる。属性テーブルは、患者同意ポリシの判定テーブルに特定された被許諾者について、患者ポリシに特定されたもの以外に被許諾者が有しうる可能性のある他の役割又はグループを識別する（例えば、医師は、主治医の役割を更に有することができる、特定のヘルスケア提供者は、いくつかの役割を有することができる、等）。このテーブルは、病院又は全国的なＥＨＲインフラストラクチャのアイデンティティ管理プロバイダによって提供されることができる。

役割は、ユーザの属性とみなされることができる。例えば、２つの規則は、以下のように示されることができる：
規則１：attribute.subjectname="John", object=O1, action=view, deny;
（主体名属性＝「Ｊｏｈｎ」，対象＝Ｏ１、アクション＝ビュー，拒否）
規則２：attribute.role="emergency.doctor", object=O1, action="view", permit
（役割属性＝「応急医師」，対象＝Ｏ１、アクション＝「ビュー」、許可）

Ｊｏｈｎが応急医師の役割を担う場合、これらの２つの規則は競合しうる。異なる属性の組み合わせが、使用されることができる。例えば、他の規則は、ロケーション又は部門に基づく属性を使用してもよい。このような規則もまた、競合を引き起こすことがあり、例えば以下の例において、規則は、オーバラップするロケーションに言及する：
規則１：attribute.location="Hospital1", object=O1, action=view, deny;
（ロケーション属性＝「病院１」，対象＝Ｏ１，アクション＝ビュー、拒否）
規則２：attribute.location="Hospital1.emergency.room", object=O1, action="view", permit
（ロケーション属性＝「病院１応急室」，対象＝Ｏ１，アクション＝ビュー、許可）

アクセスポリシ規則は、あるデータに関連しうる。データは、ＸＰａｔｈ表現によって示されることができる。ＸＰａｔｈは、当技術分野において知られているフォーマットである。しかしながら、これは、この記述において使用される一例にすぎない。それに代わって、データを特定する他のやり方が使用されることができる。

競合検出は、以下を含みうる。
（潜在的な）主体オーバラップが検出される：比較される２つの認可に関して、被許諾者要素が同じ値を有する場合、又は２つの認可のうち一方の被許諾者要素が、属性テーブルのその「可能性のある役割／グループ」列に他の認可規則の被許諾者要素を有する場合、主体オーバラップがありうる。

データオーバラップは、今日、認可の中で患者医療情報を表すＸＰａｔｈ表現においてチェックされる。文献において、ＸＰａｔｈの間の包含関係又は交差を検出する多くのアルゴリズムが提示されている。データオーバラップの検出のために、好適な交差アルゴリズムが、認可規則のデータ要素に対してランされる。ＸＰａｔｈ表現が交わる場合、データオーバラップが存在し、競合が起こりうる。そうではなく、ＸＰａｔｈ表現がオーバラップを有しない場合、認可は、それらが異なるデータ項目に言及するので、互いに競合しない。

アクションオーバラップがチェックされる：２つの認可のアクションが異なる場合、これらの２つの認可は競合しない。これは、これら２つの規則が異なる操作に言及し、両方が同じアクセス要求に適用可能になりえないからである。しかしながら、アクションが同じである場合、競合の潜在性が存在する。アクションが単に比較され、それらが等しい場合、アクションオーバラップが存在する。

条件オーバラップがチェックされる：条件オーバラップのチェックの間に比較される認可の要素は、目的要素（条件１）及びコンテクスト要素（条件２）である。２つの認可規則の条件対は、以下の関係のうちの１つを有しうる：
−条件１及び条件２が交わる(intersect)、
−条件１及び条件２が素(disjoint)である、
−条件１及び条件２が等しい。

２つの条件対は、それらが目的又はコンテクスト要素の一方について同じ値を有するが、他方の要素については異なる値を有する場合、又は認可のうち一方が、目的又はコンテクスト要素に値「すべて」を有する場合、交わると考えられる；後者のケースの理由は、値「すべて」が、他方の認可の目的又はコンテクスト要素に特定されるどの値も含むからである。他方、すべての目的及びコンテクスト値が異なり、両方の認可の目的又はコンテクスト要素のいかなるものも、値「すべて」をもたない場合、２つの条件対は素である。最後に、両方の認可の目的及びコンテクスト値の両方が同じである場合；一方の認可が目的要素について値「すべて」を有し、両方の認可のコンテクスト要素が同じ値を含む場合又はその逆の場合；１つの認可が目的及びコンテクスト要素の両方の要素について値「すべて」を有する場合；又は一方の認可が目的要素について値「すべて」を有し、他方の認可がコンテクスト要素について値「すべて」を有する場合又はその逆である場合、２つの条件対は等しいと考えられる；

条件対が等しい場合、認可規則の他の要素のステータスに依存して、競合の可能性がある。これは、それら条件が同じアクセス要求に適用される可能性があるからである。２つの条件対が交わり又は素である場合、通常は競合の可能性はない。これは、条件対が共通してある要素を有しうるという事実に関係なく、それらの条件対が全体として異なっているからである。この結果は、その条件が交わる又は素である認可規則は通常は同じアクセス要求に適用可能でないということである。それらの条件が異なるので、それらは互いと競合しない。

符号、アクション、主体、データ及び条件オーバラップのチェックは、競合検出アルゴリズムの一部であり、これは、以下に示される競合検出テーブルにまとめられる。

表２：アクション、符号及び条件オーバラップテーブル（−は、効果、アクション及び条件の当該組み合わせについて競合が起こりえないことを意味する。）

表３：主体オーバラップテーブル

表４：データオーバラップテーブル

認可は、比較されることができ、結果は、競合マトリックス（関連する規則の間に競合がある場合、セルがマークされる）に記憶されることができる。

図４は、２つのポリシ規則が競合しているかどうかを検証するプロセスを示している。プロセスは、ステップ４０１で始まる。２つの認可が、競合について比較されるとき、テーブル２が、最初に調べられることができる。２つの認可の符号が、ステップ４０２において比較される。それらが同じである場合、ステップ４０８において、競合検出アルゴリズムは、「競合なし」応答を返し、プロセスが終了する。そうでない場合、２つの認可のアクションが、ステップ４０３において比較される。それらが異なる場合、ステップ４０８において、競合検出アルゴリズムは、「競合なし」応答を送り、プロセスが終了する。そうでない場合、２つの規則の条件が、ステップ４０４において比較される。２つの認可規則の条件が等しい場合、ステップ４０５及び４０６においてチェックされるように被許諾者及びデータ要素がオーバラップするか否かに依存して、競合が起こりうる。条件が交わり又は素である場合、ステップ４０８において、競合検出アルゴリズムは、「競合なし」応答を返し、プロセスが終了する。主体オーバラップテーブルが、データオーバラップテーブルの前に調べられることができる。主体オーバラップがない場合、ステップ４０８において、競合検出アルゴリズムは「競合なし」応答を返し、プロセスが終了する。そうでない場合、データオーバラップテーブルが、ステップ４０６においてチェックされることができる。例えば２つの認可規則のデータ要素であるＸＰａｔｈ表現にオーバラップがない場合、ステップ４０８において、競合検出アルゴリズムは、「競合なし」応答を返し、プロセスが終了する。オーバラップがＸＰａｔｈ表現において検出される場合、ステップ４０７において、競合検出アルゴリズムは、「競合あり」応答を返す。

競合解決は、以下を含むことができる。

競合検出マトリクスが、競合の存在についてチェックされることができる。競合が見つからない場合、競合解決がスキップされることができる。他方、競合が見つかる場合、２つの競合するポリシ規則が、競合解決アルゴリズムへの入力として使用されることができる。

競合解決は、好適には、場所（特定性）競合解決ストラテジを使用して自動的に行われる。しかしながら、これは制限でない。認可の特定性のために、次のことがチェックされうる：
−一方の認可のデータが、他方のサブセットであるか（ＸＰａｔｈ包含関係）、
−一方のアクションが、他方のアクションに含まれるか（アクションが階層を有する）、
−被許諾者が、役割／グループ階層を有する役割／グループであるか、
−一方の認可の条件が、他方のものより特定性があるか。

このストラテジが競合を解決しない場合、又は患者がこのストラテジを使用しないことを好む場合、競合は、手作業によりプライオリティを規則に割り当てることによって、患者自身によって解決されることができる。このプロセスは、２つの競合する規則のうちどちらがプライオリティを有するべきかを患者が決めることを可能にすることによって、サポートされる。しかしながら、より多くの競合がこのようにして解決される場合、あるポイントで、規則が競合することが起こりうる。３つの規則が競合する例では、第１の規則Ａ及びＢが競合し（ユーザは、Ｂがプライオリティを有すると決定した）、規則Ｂ及びＣが競合し（ユーザは、Ｃがプライオリティを有すると決定した）、規則Ａ及びＣが競合する（ユーザは、Ａがプライオリティを有すると決定した）。この例では、３つの規則うちのただ１つが最も高いプライオリティを有することが達成されることができないので、これらの３つの規則の間の競合は適切に解決されなかった。これは、有向グラフとしてプライオリティを解析することによって見つけられることができる。このようなグラフの頂点は、ポリシ規則を表す。このようなグラフの有向辺は、１つのポリシ規則が別のポリシ規則より高いプライオリティを有することを示す。システムは、好適には、患者がグラフに巡回を取り込まないことを助ける。巡回の取り込みを防ぐために、有向非巡回グラフが、競合解決の間、インクリメンタルに生成され、チェックされることができる。グラフは、ちょうど解決されたばかりの両方の競合する規則の存在についてサーチされることができる。これらの規則の一方又は両方が、グラフの頂点として存在せず、又はグラフの切り離されたコンポーネントにある場合、プライオリティに競合はない。この場合、競合解決が進められることができる。そうでない場合、許諾者は、認可の既存のプライオリティを通知される。システムは、（例えば患者が規則を特定した該規則の元の順序のデフォルト競合解決ストラテジに基づいて、）規則に関するプライオリティを患者に提案することができる。

最後に、競合しない規則については、プライオリティ値は、以下の態様で規則に割り当てられることができる：

デフォルト認可規則に、まずプライオリティが割り当てられる。それらは、低い値のプライオリティをランダムに割り当てられる。

その後、特定の認可に、プライオリティが割り当てられる。特定の認可に割り当てられるプライオリティは、デフォルト認可に割り当てられるプライオリティより高い。プライオリティは、ランダムに割り当てられる。

競合を有する規則は、デフォルト及び特定の認可の２つの有向非巡回グラフに対してトポロジカルソートを行うことによって、より高いプライオリティ値を割り当てられる。デフォルト認可を表すグラフが、最初にトラバースされることができ、特定の認可を表すグラフが、２番目にトラバースされることができる。プライオリティ値は、トポロジカルソートによって生成されるリストの昇順で割り当てられることができる。デフォルト認可は、特定の認可より低いプライオリティを与えられる。実施の間、より高いプライオリティ規則が最初に処理される。最も高いプライオリティを適用できる規則が、実施される。

ＸＡＣＭＬのようなアクセスポリシ言語への翻訳は、以下を含むことができる。

翻訳アルゴリズムは、入力として、競合解決アルゴリズムから優先付けされた判定テーブルを得ることができる。認可の各要素は、主体、アクション、リソース又は環境属性としてすでに識別されている。これらの要素は、ポリシターゲット及び規則ターゲットにマップされる。ポリシターゲットは、アクセス要求に対するポリシの適用可能性を識別するために使用され、すべての認可規則のすべての主体、アクション及びリソース要素を含むことができる。これは、主体属性として認可規則のすべての被許諾者及び患者アイデンティティを含め、アクション属性としてすべてのアクションを含めることにより、及びリソース属性として患者医療情報の全てを表すＸＰａｔｈ表現を使用して、行われる。

ポリシターゲットのリソース属性は、患者医療情報の全てを表すＸＰａｔｈ表現であり、デフォルト認可のいずれかから抽出されることができる。患者の固有のアイデンティティは、判定テーブルから抽出され、ポリシターゲットの主体属性として含められる。

各々の認可は、その被許諾者及びアクション要素を導き出すために処理される。これらの要素は、以下のように、ポリシターゲットにおいて使用される：

認可規則の被許諾者は、ターゲットの主体属性に含められる。

認可規則のアクションは、ターゲットのアクション属性として含められる。

規則ターゲットは、より特定性があり、特定の被許諾者、アクション及び任意にはＸＰａｔｈ表現に表わされる患者データのあるセクション又は要素に言及する。

ＸＡＣＭＬ規則ターゲットは、以下のように構成されることができる：

規則のリソース属性は、認可のデータ要素である。しかしながら、データ要素が、患者医療情報の全てを表すＸＰａｔｈ表現である場合、リソース属性は、それがポリシのリソース属性と同様であるので、規則のターゲットから省かれることができる。

ポリシに記述される被許諾者は、ポリシのターゲットの主体属性として含められるので、規則ターゲットは、規則がどの被許諾者に適用されるかに関して特定的でなければならない。従って、規則ターゲットの主体属性は、認可の被許諾者である。

ポリシターゲットの主体属性と同様に、ポリシターゲットのアクション属性は、ポリシに記述されるアクションから構成される。従って、規則ターゲットは、どのアクションが特に規則に適用可能であるかを特定しなければならない。

目的及びコンテクスト要素は、エントリ「すべて」によって表されることができる。コンテクスト及び／又は目的要素に値「すべて」をもつ認可は、目的及び／又はコンテクスト要素の組み合わせがあるのと同じくらい多くの規則によって表されることができる。これらの規則は、それらが導出される認可に与えられたものである同一のプライオリティ値を有することができる。それらはすべてが素であり、それらの目的及びコンテクスト要素における異なる値のため競合しないので、それらは、同じプライオリティ値を有することができる。

アクセス制御メカニズムは、優先付けされたＸＡＣＭＬ規則をサポートすることができる。ＸＡＣＭＬ標準には、ポリシの規則のプライオリティ値を表すやり方が規定されておらず、従ってプライオリティを有するＸＡＣＭＬ規則は直接使用されない。この問題に対処するために、ポリシの規則の中で特定されるプライオリティ値は、ポリシ内の規則の実際の順序に翻訳される。規則は、ＸＡＣＭＬポリシにおいて、プライオリティの降順に並べられる。最も高いプライオリティを有する規則は、ポリシの最上位に書き込まれ、残りの規則は、プライオリティの降順で続く。これは、ＸＡＣＭＬに規定される第１の適用可能な規則組み合わせアルゴリズムの使用を可能にする。この規則組み合わせアルゴリズムは、それらがポリシに書き込まれた順序で、規則を評価する。規則が「許可」又は「拒否」と評価される場合、ポリシの評価は停止し、判定が、ポリシの応答として返される。反対に、規則が「適用不可」と評価される場合、次の規則が評価され、ポリシの終わりに達する場合、アルゴリズムは、該当なし判定を返す。このようにして、最も高いプライオリティを有する規則が、アクセス要求に適用される。これは、ＸＡＣＭＬ標準のいかなる変更もなく、開示された方法の使用を可能にする。

本発明は、本発明を実行するように適応されるコンピュータプログラム、特に担体上又は担体内のコンピュータプログラム、に拡張されることが理解されるであろう。プログラムは、ソースコード、オブジェクトコード、コード中間ソース及び例えば部分的にコンパイルされた形のオブジェクトコードの形でありえ、又は本発明による方法の実現において使用するのに適した任意の他の形でありうる。更に、このようなプログラムが多くの異なるアーキテクチャ設計を有することができることも理解されるであろう。例えば、本発明による方法又はシステムの機能を実現するプログラムコードは、１又は複数のサブルーチンに細分されることができる。これらのサブルーチンの間で機能を分散するための多くの異なるやり方が、当業者には明らかである。サブルーチンは、自立型プログラムを形成するために、１つの実行可能ファイルに一緒に記憶されることができる。このような実行可能ファイルは、例えばプロセッサ命令及び／又はインタプリタ命令（例えばＪａｖａ（登録商標）インタプリタ命令）のような、コンピュータ実行可能命令を含むことができる。代替として、サブルーチンの１つ、複数又は全ては、少なくとも１つの外部ライブラリファイルに記憶されることができ、例えば静的に又は実行時に動的にメインプログラムとリンクされることができる。メインプログラムは、サブルーチンのうちの少なくとも１つに対する少なくとも１つのコールを含む。更に、サブルーチンは、互いに対するファンクションコールを含むことができる。コンピュータプログラム製品に関する一実施形態は、上述された方法のうち少なくとも１つの各処理ステップに対応するコンピュータ実行可能命令を含む。これらの命令は、サブルーチンに細分されることができ、及び／又は静的に又は動的にリンクされうる１又は複数のファイルに記憶されることができる。コンピュータプログラム製品に関する別の実施形態は、上述されたシステム及び／又は製品のうち少なくとも１つの各手段に対応するコンピュータ実行可能命令を含む。これらの命令は、サブルーチンに細分されることができ、及び／又は静的に又は動的にリンクされうる１又は複数のファイルに記憶されることができる。

コンピュータプログラムの担体は、プログラムを担持することが可能な任意のエンティティ又は装置でありうる。例えば、担体は、ＣＤ−ＲＯＭ又は半導体ＲＯＭのようなＲＯＭ、あるいはフロッピー（登録商標）ディスク又はハードディスクのような磁気記録装置でありうる記憶媒体を含むことができる。更に、担体は、電気又は光学ケーブルを介して又はラジオ又は他の手段によって伝えられることができる電気又は光学信号のような送信可能な担体であってもよい。プログラムがこのような信号に組み入れられる場合、担体は、このようなケーブル又は他の装置又は手段によって構成されることができる。代替として、担体は、プログラムが埋め込まれる集積回路でありえ、かかる集積回路は、当該方法を実施するように又は当該方法の実施に使用されるように適応される。

上述の実施形態は、本発明を制限するものではなく、説明するものであり、当業者であれば、添付の請求項の範囲を逸脱することなく多くの代替実施形態を設計することが可能であることに注意すべきである。請求項において、括弧内に置かれる任意の参照符号は、請求項を制限するものとして解釈されるべきでない。動詞「有する、含む（comprise）」及びその活用形の使用は、請求項に記載されるもの以外の構成要素又はステップの存在を除外しない。構成要素に先行する冠詞「a」又は「an」は、そのような構成要素の複数の存在を除外しない。本発明は、幾つかの別個の構成要素を含むハードウェアによって、及び適切にプログラムされたコンピュータによって、実現されることできる。いくつかの手段を列挙する装置の請求項において、これらの手段の幾つかは、同じ１つのハードウェアアイテムによって具体化されてもよい。特定の手段が相互に異なる従属請求項に列挙されているという単なる事実は、これらの手段の組み合わせが有利に使用されることができないことを示さない。

Claims (15)

1. アクセス制御ポリシを特定するシステムであって、
   主体属性、対象、アクション及び認可を含み、アクセス制御ポリシを規定する複数のポリシ規則をユーザが特定することを可能にするユーザインタフェースと、
   前記アクセス制御ポリシを機械可読のデータアクセス制御ポリシ言語に翻訳して、翻訳されたデータアクセス制御ポリシを得る翻訳手段と、
   前記翻訳されたデータアクセス制御ポリシをアクセス制御ポリシ実施ユニットに提供する出力部と、
   を有する、システム。
2. 起こりうるアクセス要求の否定及び許容をそれぞれ示す少なくとも２つの競合するポリシ規則を検出する競合検出手段を更に有する、請求項１に記載のシステム。
3. 前記競合検出手段は、特定の主体による特定の対象に対する特定のタイプのアクセスの拒否及び許容をそれぞれ示す、競合するポリシ規則を検出するように構成される、請求項２に記載のシステム。
4. 前記少なくとも２つの競合するポリシ規則の競合を解決して、修正されたアクセス制御ポリシを得る競合解決手段を更に有し、前記競合解決手段は、
   前記競合に関する情報をユーザに示す競合標示手段と、
   競合解決を示すユーザからの情報を取り込む競合解決入力部と、
   を有する、請求項２に記載のシステム。
5. 前記競合解決手段は更に、予め決められた競合解決規則の組を前記競合するポリシ規則に適用して、前記競合を解決する自動競合解決手段を有し、前記競合解決入力部は、前記競合解決規則の組が前記競合を解決するのに十分でない場合に適用される、請求項４に記載のシステム。
6. 前記競合解決入力部は、１つの競合するポリシ規則が別の競合するポリシ規則より高いプライオリティを有することを示すユーザからの情報を取り込む手段を有する、請求項４に記載のシステム。
7. 前記競合検出手段は、ユーザによって示される前記ポリシ規則のプライオリティの矛盾を検出する手段を有する、請求項６に記載のシステム。
8. 前記ユーザインタフェースは、判定テーブルの形で前記アクセス制御ポリシを表現する、請求項１に記載のシステム。
9. 前記競合検出手段は、ユーザによるポリシ規則の追加又は変更の後、活性化される、請求項２に記載のシステム。
10. 前記競合検出手段は、前記競合する規則のうち少なくとも１つにおいて言及される主体属性に基づいて、２つの規則が同じ主体に適用されるかどうかを検証する、請求項２に記載のシステム。
11. 前記機械可読のセキュリティポリシ言語は、拡張可能アクセス制御マークアップ言語ＸＡＣＭＬを含む、請求項１に記載のシステム。
12. 前記アクセス制御ポリシ実施ユニットを更に有し、前記アクセス制御ポリシ実施ユニットは、前記翻訳されたアクセス制御ポリシを受け取るアクセス制御ポリシ入力部と、前記受け取られたアクセス制御ポリシを実施するポリシ実施手段と、を有する、請求項１に記載のシステム。
13. 前記出力部は、広域ネットワークを介して前記アクセス制御ポリシ実施ユニットに前記翻訳されたアクセス制御ポリシを送信し、前記アクセス制御ポリシ実施ユニットは、前記ユーザインタフェース、前記翻訳手段及び前記出力部から遠隔している、請求項１２に記載のシステム。
14. アクセス制御ポリシを特定する方法であって、
    主体属性、対象、アクション及び認可を含み、アクセス制御ポリシを規定する複数のポリシ規則をユーザが特定することを可能にするステップと、
    前記アクセス制御ポリシを機械可読のデータアクセス制御ポリシ言語に翻訳して、翻訳されたデータアクセス制御ポリシを得るステップと、
    前記翻訳されたデータアクセス制御ポリシをアクセス制御ポリシ実施ユニットに提供するステップと、
    を含む方法。
15. 請求項１４に記載の方法の各ステップをプロセッサシステムに実行させるためのコンピュータ実行可能命令を含むコンピュータプログラム。

Images