| Oracle® Databaseセマンティク・テクノロジ開発者ガイド 11gリリース2 (11.2) E52974-01 |
|
 前 |
 次 |
Oracle Databaseセマンティク・データ・ストアに対するアクセスのデフォルト制御は、モデル・レベルです(モデルの所有者は、RDFM_<model_name>というビューに対する適切な権限を付与することで、モデルに対する選択、削除および挿入権限を他のユーザーに付与できます)。ただし、厳格なセキュリティ要件のあるアプリケーションでは、Oracle Databaseの仮想プライベート・データベース機能またはOracle Label Securityオプションを使用してファイングレイン・アクセス制御メカニズムを実施できます。
RDFデータの仮想プライベート・データベース(VPD)によって、セキュリティ管理者は、特定のRDFクラスまたはプロパティのインスタンスを含むトリプルに対するユーザーのアクセスを条件付きで制限するポリシーを定義できます。VPDを使用すると、RDFモデルに格納されたデータはそのメタデータを使用して分類され、各ユーザー問合せは、アクセス制限を実施するコンテキスト依存のデータ・アクセス制約を含むようにリライトされます。
VPDの使用方法の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。セマンティク・データのあるVPDのサポートの詳細は、5.1項を参照してください。
RDFデータのOracle Label Security (OLS)によって、RDFモデルに格納された個々のトリプルに機密性ラベルを関連付けることができます。問合せごとに、それらのラベルとユーザーのセッション・ラベルを比較することで、特定のトリプルに対するアクセス権限が付与されます。また、特定のリソースを記述するすべてのトリプル、または特定の述語で定義されているすべてのトリプルの最小限の機密性ラベルを、それぞれリソースまたは述語に機密性ラベルを直接割り当てることで実施できます。
OLSの使用方法の詳細は、『Oracle Label Security管理者ガイド』を参照してください。セマンティク・データのあるOLSのサポートの詳細は、5.2項を参照してください。
RDFデータでVPDとOLSのどちらを使用するかを選択する場合に考慮する要素は、次のとおりです。
OLSは、RDFデータに対して有効化されると、ネットワーク・レベルで実施されますが、VPDは個々のRDFモデルに対して実施できます。
Oracleインスタンスで同時にRDFデータに対してVPDとOLSの両方を使用することはできません。
セマンティク・データとともにVPDまたはOLSを実装するためのアプリケーション・プログラミング・インタフェース(API)は、SEM_RDFSA PL/SQLパッケージで提供されます。第13章に、SEM_RDFSAパッケージのプログラムに関するリファレンス情報があります。
RDFデータのVPDおよびOLSサポートは、リリース11.2のセマンティク・テクノロジ・サポートに含まれます。(セマンティク・テクノロジ・サポートを有効化、ダウングレードまたは削除する方法の詳細は、付録Aを参照してください。)
この章には次の項が含まれます。
仮想プライベート・データベース(VPD)機能は、セキュリティ・ポリシーとアプリケーション・コンテキストを使用してリレーショナル表またはビューの特定の行に対するアクセスを制限する行レベルのセキュリティ・メカニズムです。セキュリティ・ポリシーには、ユーザー問合せに対して戻される行ごとに実施される述語を動的に生成するポリシー・ファンクションが含まれます。表に関連付けられたポリシー・ファンクションによって戻されるセキュリティ述語は、通常、表の列を使用して表現されるため、表のメタデータに依存します。実際、セキュリティ述語によって、ユーザー問合せに対して戻される行が、その行の内容に適用される追加の条件を満たすことが保証されます。
リレーショナル・データがRDFにマップされている場合、特定のリレーショナル表に格納されているデータは、特定のRDFクラスのインスタンスを記述するトリプルを表します。この表現では、リレーショナル表の列は、リソースを記述するために使用されるRDFプロパティにマップされます。このマッピングは、さらにVPDポリシーのアプリケーションに拡張できます。
RDFデータに適用されるVPDポリシーによって、グラフ・パターンおよびフィルタ条件の形式でインスタンス・データに述語を適用することで、特定のRDFクラスまたはプロパティのインスタンスにユーザーのアクセスを制限します。たとえば、VPDポリシーを定義して、特定の部門に属するユーザーのみがContract RDFクラスのインスタンスにアクセスできるように制限できます。また、Contract RDFクラスのインスタンスとして識別されるリソースのhasContractValueプロパティに対するアクセスを、契約の管理者のみに制限できます。RDFデータのVPDサポートによって、セキュリティ条件またはデータ・アクセス制約をRDFクラスおよびプロパティに関連付けることができるため、対応するインスタンス・データに対するアクセスが制限されます。
RDFクラスまたはプロパティに関連付けられたデータ・アクセス制約によって、問合せ結果として戻される、対応するすべてのデータ・インスタンスに対して実施する必要のあるグラフ問合せパターンを指定します。たとえば、Contractクラス{?contract :hasDueDate ?due}のすべてのインスタンスの期限日を検出するSPARQL問合せパターンによって、戻された情報が特定の部門に属する契約に関連することを保証するデータ・アクセス制約をアクティブ化できます。これは、次の例のように、追加のグラフ・パターンを含むようにユーザーのグラフ問合せパターンを論理的にリライトすることで実現されます。
{ ?contract :hasDueDate ?due .
?contract :drivenBy dept:Dept1 }
また、リライトされたグラフ問合せパターンにバインドされた値は、セッション・コンテキストを使用して動的アクセス制限を実施できます。次の例では、トリプル・パターンの目的語の位置にあるsys_contextファンクションによって、セッション・コンテキストに基づく適切な部門値をバインドしています。
{ ?contract :hasDueDate ?due .
?contract :drivenBy
"sys_context('sa$appctx','user_dept'}"^^orardf:instruction }
リレーショナル・データ・モデルでは、メタデータは、表定義の形式で常にデータ(表に格納された行)とともに存在するため、メタデータを使用して定義されたVPDポリシーは適切に整形され、ポリシー・ファンクションの手続き型ロジックを使用してセキュリティ条件が生成されます。
ただし、RDFデータ・モデルでは、付随するメタデータのないデータも許容されるため、特定のRDFグラフに対してインスタンス・データのクラス情報を常に使用できるとはかぎりません。たとえば、RDFグラフでは、契約として認識されるリソースに、そのリソースがContractクラスのインスタンスであることを表明するトリプルが付随しないことがあります。通常、このようなトリプルは、リソースを記述するプロパティで使用可能なドメインおよびレンジの指定を使用して推論されます。
同様に、VPDポリシーは、インスタンス・データのクラス情報を導出し、適切なデータ・アクセス制約を実施するためにプロパティのドメインおよびレンジの指定に依存します。ただし、実行時にユーザー・データに依存することを避けるため、VPDポリシーは、表明および推論されたトリプルとは別に、そのディクショナリのクラス情報を導出するために必要な最低限のメタデータを保持します。これによって、VPDポリシーで保持されるメタデータは、表明されたトリプルに必要な情報が存在しない場合でも完全で、データ・アクセス制約とメタデータを保持するVPDポリシーは、自己完結型で外部の依存性なしに移行できることが保証されます。
特定のデータ・アクセス制約とRDFメタデータの指定があるVPDポリシーは、RDFモデルに格納されたデータのアクセス制限を実施するために使用できます。モデルに対して発行された各SPARQL問合せは、その問合せでアクセスされるリソースのクラス情報を推測するために分析され、適切なデータ・アクセス制約が適用されます。インスタンス・データのクラス情報のコンパイル時間分析および導出を容易にするため、バインドされていない述語のあるグラフ問合せパターンは、VPDポリシーが有効な場合は制限されます。たとえば、次の形式のグラフ・パターンがSPARQL問合せパターンのいずれかの場所に存在する場合、基礎となるモデルにVPDポリシーが含まれると例外が発生します。
{ <contract:projectHLS> ?pred ?obj }
VPDポリシーは、SPARQL構文に表現されたSEM_MATCH問合せに対してのみ実施されます。データ・アクセスの他のすべての形式(グラフ・パターンの従来の構文またはモデル・ビューに対する直接問合せなど)は、許可されません。
RDFデータのVPDポリシーは、1つ以上のRDFモデルに格納されたデータに対してアクセス制限を実施するために使用できる名前付きディクショナリ・エンティティです。RDFデータに定義されたVPDポリシーは、一意の特性を持ち、リレーショナル・データにセキュリティ・ポリシーを実施するために再利用できません。データベースに定義されるRDF-VPDポリシーは次のとおりです。
SPARQLユーザー問合せで参照されるデータのクラス情報を導出するために必要なRDFスキーマ文またはメタデータ
インスタンス・データに対してアクセス制限を実施するデータ・アクセス制約
実行時環境に基づいてデータ・アクセス制約のグループの条件付き組込みを可能にするアプリケーション・コンテキスト
RDF-VPDポリシーは、組織のセキュリティ管理者ロールを持つユーザーによって、定義、所有および管理されます。このユーザーは、少なくともSYS.DBMS_RLSパッケージに対するEXECUTE権限を持っている必要があります。RDF-VPDポリシーの所有者は、ポリシーに関連付けられたメタデータを管理し、新しいデータ・アクセス制約を定義して、1つ以上のRDFモデルにポリシーを適用できます。
VPDポリシーのあるRDFモデルに対して発行されたSPARQL問合せが分析され、ポリシーに定義された0個以上のデータ・アクセス制約が実施され、それによって問合せ結果として戻されるデータ・インスタンスもそれらの制約に適合します。ユーザー問合せに実施される正確なデータ・アクセス制約は、問合せとアプリケーション・コンテキストで参照されるリソースに基づいて変化します。たとえば、hasContractValueプロパティに対する管理者のアクセスを制限するポリシーは、部長ロールを持つユーザーに対しては緩和できます。
適用される特定の制約は、アプリケーション・コンテキストで取得されるユーザーのロールに基づいて実行時に決定されます。VPDポリシーで定義された制約のサブセットの動的な組込みを容易にするため、データ・アクセス制約は、アプリケーション・コンテキストに基づいてアクティブ化および非アクティブ化できる名前付きグループに分類されます。問合せの分析中は、アクティブなグループに定義されている制約のみが実施対象とみなされます。
VPDポリシー内の制約グループは、アプリケーション・コンテキストとそのパッケージ実装を使用して管理されます。各VPDポリシーでは、CREATE CONTEXTコマンドで作成されたコンテキストの名前空間を指定できます。コンテキストに関連付けられた各属性は、その値を1に初期化してアクティブ化できる制約グループの名前として扱われます。たとえば、VPDポリシーに関連付けられたコンテキストのMANAGER属性の値を1に設定すると、ユーザー・セッションのMANAGERグループに関連付けられた制約がアクティブ化されます。ユーザー・コンテキストに基づいて特定の制約グループを初期化するロジックは、通常、コンテキスト・タイプに関連付けられたパッケージに組み込まれます。次の例は、このようなパッケージのサンプル実装からの抜粋を示しています。
CREATE CONTEXT contracts_constr_ctx using sec_admin.contracts_ctx_pack;
begin
-- create the VPD policy with a context --
sem_rdfsa.create_vpd_policy(policy_name => 'CONTRACTS_POLICY',
policy_context => 'contracts_constr_ctx');
end;
/
create or replace package sec_admin.contracts_ctx_pack as
procedure init_constr_groups;
end;
/
create or replace package body sec_admin.contracts_ctx_pack as
procedure init_contr_groups is
hrdata EmpRole%rowtype;
begin
-- specific users with FULL access to the data associated with
-- the policy --
if (sys_context('userenv', 'session_user') = 'RDF_ADMIN') then
dbms_session.set_context('contracts_constr_ctx',
sem_rdfsa.VPD_FULL_ACCESS, 1);
return;
end if;
SELECT * into hrdata FROM EmpRole WHERE guid =
sys_context('userenv','session_user');
if (hrdata.emprole = 'VP') then
-- if the user logged in has VP role, activate the constraint
-- group named VP and keep all other groups inactive.
dbms_session.set_context('contracts_constr_ctx','VP', '1');
elsif (hrdata.emprole = 'MANAGER') then
dbms_session.set_context('contracts_constr_ctx', 'MANAGER', '1');
elsif ...
...
else
raise_application_error(-20010, 'unknown user role');
end if;
exception when others then
-- enforce constraints for all groups --
dbms_session.clear_all_context('contracts_constr_ctx');
end init_contr_groups;
end;
/
デフォルトでは、名前空間がRDF-VPDポリシーに関連付けられていない場合、または特定の制約グループがセッションでアクティブ化されていない場合、ポリシーに定義されたすべての制約がアクティブになり、各ユーザー問合せに実施されます。ただし、対応する名前空間属性の値を1に設定して特定の制約グループをアクティブ化すると、そのグループに属している制約と、任意のグループに関連付けられていない他の制約のみが実施されます。特定のセッションでは、1つ以上の制約グループがアクティブ化されることがありますが、その場合、適用可能なすべての制約が結合して実施されます。
作成時に、RDF-VPDポリシーに定義されたデータ・アクセス制約によって、制約グループの名前を指定できます(5.1.3項「データ・アクセス制約」を参照)。データベース・セッション内で、コンテキスト・パッケージによって設定されたセッション・コンテキストに基づいて、制約の適切なグループがアクティブ化されます。データベース・セッションの後続のすべてのSPARQL問合せでは、適切なセキュリティ・ポリシーを実施するために、アクティブなグループに属している制約が参照されます。
VPDポリシーのあるRDFモデルに対するメンテナンス操作では、モデルのデータに対する無制限のアクセスが必要です。これらの操作には、1つ以上のVPD保護モデルを使用した伴意の作成と、ロードまたはデータ処理操作が含まれます。RDFモデルに格納されたデータに対する無制限のアクセスを可能にするには、VPDポリシーに関連付けられた名前空間の予約属性を初期化します。予約属性は、パッケージ定数sem_rdfsa.VPD_FULL_ACCESSによって定義され、前述の例に示されているコンテキスト・パッケージ実装によってRDF_ADMINユーザーに完全なアクセス権限を付与します。
アプリケーション表に対するDML操作は、VPD制約違反については検証されないため、対応するモデルに対する完全なアクセス権限を持つユーザーのみが、既存のトリプルを追加または変更できます。
SEM_MATCH演算子を使用すると、標準のSQL問合せでVPDポリシーのあるRDFモデルを問い合せることや、VPD対応のモデルとVPDポリシーのないモデルの組合せに対してマルチモデル問合せを実行することができます。ただし、マルチモデル問合せの複数のモデルがVPD対応の場合、それらはすべて同じVPDポリシーに関連付けられている必要があります。RDFモデルに関連付けられたVPDポリシーは、モデルから推論された任意のデータに自動的に拡張されます。推論中に複数のRDFモデルが指定される場合、そのセット内のすべてのVPD対応モデルで同じVPDポリシーを使用する必要があります。
VPDポリシーを実施するために使用されるRDFメタデータのタイプは、次のとおりです。
グラフで使用されるプロパティのドメインおよびレンジ情報
グラフのサブクラス関係
グラフのサブプロパティ関係
グラフの等価プロパティ
VPDポリシーに関連付けられているRDFメタデータは、次のプロパティURIのいずれかを使用して、1つ以上のRDFスキーマ文として指定されます。
http://www.w3.org/2000/01/rdf-schema#domain
http://www.w3.org/2000/01/rdf-schema#range
http://www.w3.org/2000/01/rdf-schema#subClassOf
http://www.w3.org/2000/01/rdf-schema#subPropertyOf
http://www.w3.org/2002/07/owl#equivalentProperty
たとえば、contracts_policyに関連付けられている次のRDFスキーマ文は、hasContractValueプロパティのドメインがContractクラスであることを表明しています。述語のレンジ指定は、それらが適切でない場合やリテラル・タイプの場合、スキップされることがあります。
begin
sem_rdfsa.maint_vpd_metadata(
policy_name => 'contracts_policy',
t_subject => '<http://www.myorg.com/pred/hasContractValue>',
t_predicate => '<http://www.w3.org/2000/01/rdf-schema#domain>',
t_object => '<http://www.myorg.com/classes/Contract>');
end;
/
RDF-VPDポリシーによって、表明および推論されたトリプルから独立してメタデータを管理します。このメタデータは、RDFモデルおよび対応する伴意からプログラム的に導出できます。たとえば、プロパティのドメインおよびレンジ情報と、サブクラスおよびサブプロパティの関係が、表明または推論されたトリプルにすでに確立されている場合、基礎となるモデル・ビューに対するSQL問合せを使用して、RDF-VPDポリシーのメタデータを移入できます。
プロパティのドメインおよびレンジ情報は、問合せで参照される用語および非バインド変数のRDFクラス・タイプを問合せ分析で決定する場合に役立ちます。さらに、この情報は、問合せでアクセスされるデータに対して適切なデータ・アクセス制約を実施する場合に使用されます。サブクラス・プロパティに関連するメタデータの使用によって、クラス階層内の特定のクラスに定義されたデータ・アクセス制約がそのすべてのサブクラスに自動的に実施されることが保証されます。同様に、VPDポリシーのサブプロパティ指定の使用によって、プロパティに関連付けられた制約がそのすべてのサブプロパティに実施されます。
VPDポリシーに関連付けられたRDFスキーマ文は、追加の文を推論するためには使用されないため、セキュリティ管理者は、推論データを使用したクロス・チェックによって、VPDポリシーで取得されたメタデータが完全であることを確認する必要があります。たとえば、サブプロパティ・スキーマ文では、スーパープロパティに指定されたドメインとレンジに基づいて、プロパティのドメインおよびレンジ情報が自動的に推論されることはありません。
表明されたトリプルの特定のOWLおよびRDFSプロパティは、チェックされないままの場合、VPDポリシーを回避するために使用できるデータを推論するために使用される可能性があります。たとえば、新しいプロパティが、特定のデータ・アクセス制約を持つプロパティのスーパープロパティとして定義されている場合、推論データによって、スーパープロパティを使用してサブプロパティのすべてのインスタンスが複製される可能性があります。VPDポリシーでスーパープロパティのアクセス制約を明示的に定義していない場合、推論データを使用して、アクセス制限を回避できます。
新しいデータを推論する機能は、完全なアクセス権限を持っているユーザーにのみ付与され、そのようなユーザーは、VPDポリシーに関連付けられたメタデータが新しい推論データに関して完全であることを確認する必要があります。特に、rdfs:subClassOf、rdfs:superClassOf、rdfs:subPropertyOf、rdfs:superPropertyOfまたはowl:equivalentPropertyの新しい表明が推論中に生成される場合、VPDポリシーに関連付けられたメタデータが保持されている必要があります。また、推論に使用されるルールベースによって導入された新しいプロパティでは、それらが機密情報に関連付けられている場合、データ・アクセス制約と同様に、ドメインおよびレンジの指定が必要になることがあります。
VPDポリシーでは、プロパティが別のプロパティと等価であると宣言して、元のプロパティに定義された制約と同様に、ドメインおよびレンジ情報を等価プロパティに対して自動的に複製できます。ただし、VPDポリシー内では、別のプロパティと等価であると宣言されたプロパティに追加のメタデータまたはデータ・アクセス制約を直接割り当てることはできません。
VPDポリシーに関連付けられたデータ・アクセス制約は、実施されるアクセス制限のタイプに基づいて次の2つの一般的なカテゴリに分類されます。
特定のRDFクラスのインスタンスに対するアクセスを制限するもの
特定のRDFプロパティを使用する表明に制限するもの
アクセス制限は、アプリケーション・コンテキストとSPARQL問合せでアクセスされるリソースの特性に基づいて、条件付きで実施されます。データ・アクセス制約は、リソースに関連付けられたプロパティを使用して、RDFクラスまたはプロパティのインスタンスに対するアクセスを制限します。たとえば、Contractクラスのメンバーであるリソースに対するアクセスを、そのリソースに関連付けられたhasMemberプロパティを使用して識別される、契約作業をしているユーザーのみに制限できます。同様に、リソースのhasContractValueプロパティに対するアクセスを、同じリソースに関連付けられたhasManagerプロパティを使用して、契約の管理者として識別されるユーザーに制限できます。
各データ・アクセス制約は、一致パターンおよび適用パターンとして識別される2つのグラフ・パターンを使用して表現されます。制約の一致パターンによって、実施されるアクセス制限のタイプが決定され、ユーザー問合せでアクセスされる対応するデータ・インスタンスに1つ以上の変数がバインドされます。たとえば、次の一致パターンがContractクラスのインスタンスに定義され、SPARQL問合せを通じてアクセスされるすべてのインスタンスに変数がバインドされます。
{ ?contract rdf:type <http://www.myorg.com/classes/Contract> }
同様に、RDFプロパティを含む制約の一致パターンは、SPARQL問合せでアクセスされるプロパティのインスタンスに一致し、それらのインスタンスの主語と目的語の位置にあるリソースに2つの変数がバインドされます。たとえば、hasContractValueプロパティに対する制約の一致パターンは、次のように定義されます。
{ ?contract <http://www.myorg.com/pred/hasContractValue> ?cvalue }
データ・アクセス制約の適用パターンによって、一致パターンに一致するリソースに適用される追加のグラフ・パターンが定義されます(その後、それらを使用して問合せ結果を構成できます)。データ・アクセス制約の一致パターンに定義された1つ以上の変数は、識別されたリソースに対してアクセス制限を実施するために、対応する適用パターンで使用されます。たとえば、次の一致パターンと適用パターンの組合せによって、Andyがアクセスされる契約の管理者である場合にのみ、その契約のhasContractValueにアクセスできることが保証されます。
Match: { ?contract pred:hasContractValue ?cvalue }
Apply: { ?contract pred:hasManager emp:Andy }
SPARQL構文で表現されている一致パターンと適用パターンのあるデータ・アクセス制約をVPDポリシーに追加して、VPDポリシーに関連付けられたRDFモデルに格納されているデータに対してアクセス制限を実施できます。VPDポリシーに制約を追加する次の例では、predおよびempという名前空間の接頭辞に対する適切な名前空間マップでVPDポリシーが定義されていると仮定します。(VPDポリシーに名前空間マップを関連付けるには、SEM_RDFSA.CREATE_VPD_POLICYプロシージャを使用します。)
begin
sem_rdfsa.add_vpd_constraint(
policy_name => 'contracts_policy',
constr_name => 'andy_constraint_1',
match_pattern => '{?contract pred:hasContractValue ?cvalue }',
apply_pattern => '{?contract pred:hasManager emp:Andy }',
constr_group => 'andy');
end;
/
データ・アクセス制約をグループに分類する機能によって、前述の制約がAndyに関連付けられたセッションにのみ適用されることが保証されます。ただし、ユーザーごとに構造的に類似した制約が増大することを避けるため、次の例に示すとおり、適用グラフ・パターンの目的語の位置にあるアプリケーション・コンテキストを使用する共通の制約を定義できます。
begin
sem_rdfsa.add_vpd_constraint(
policy_name => 'contracts_policy',
constr_name => 'manager_constraint_1',
match_pattern => '{?contract pred:hasContractValue ?cvalue }',
apply_pattern => '{?contract pred:hasManager
"sys_context(''sa$appctx'',''app_user_uri''}"^^orardf:instruction }',
constr_group => 'manager');
end;
/
前述の例で、manager制約グループ内に定義されたデータ・アクセス制約は、管理者ロールを持つユーザーを含むすべてのセッションでアクティブ化できます。この場合、ログインしたユーザーのURIを使用してsa$appctx名前空間のapp_user_uri属性を初期化するように、セキュアなアプリケーション・コンテキストをプログラムできます。たとえば、ユーザーAndyがアプリケーションにログインしたときに、app_user_uri属性を<http://www.myorg.com/employee/Andy>に初期化できます(この場合、制約によって、Andyが契約を管理する場合にのみ、ユーザーAndyは契約の値を参照できます)。通常、sys_contextファンクションをグラフ・パターンの目的語の位置で使用して、動的URIまたはリテラル値を問合せの実行時にバインドできます。ただし、コンテキストが適切に初期化されないと、前述の制約はすべてのデータ・インスタンスに対して失敗し、ユーザーは事実上どのデータにもアクセスできなくなります。
VPDポリシーのあるRDFモデルに対して発行されたSPARQL問合せは、ポリシーに定義されたアクティブなすべてのデータ・アクセス制約の一致パターンを使用して分析されます。次の例では、SPARQL問合せでhasContractValueプロパティを参照し、グループがアクティブな場合に制約を実施します。制約を実施することは、ユーザー問合せの適切な変数および用語を使用して、関連するすべての制約の適用パターンを含めるように元のSPARQLグラフ・パターンをリライトすることと論理的に同等です。hasContractValueプロパティに対する前述のアクセス制限では、次の例に示すとおり、SEM_MATCH演算子に渡される次のSPARQLグラフ・パターンが論理的にリライトされます。
Query:
{ ?contr pred:drivenBy ?dept .
?contr pred:hasContractValue ?val }
Rewritten query:
{ ?contr pred:drivenBy ?dept .
?contr pred:hasContractValue ?val .
?contr pred:hasManager
"sys_context('sa$appctx','app_user_uri'}"^^orardf:instruction }
RDFプロパティに対するデータ・アクセス制約の一致パターンがユーザー問合せでアクセスされるパターンに一致する場合、同等のVPD実施問合せによって、一致したパターンに出現する変数および用語を使用して、対応する適用パターンがSPARQL問合せに追加されます。SPARQL問合せにネストしたグラフ・パターンが含まれる場合、データ・アクセス制約は、適切な基本問合せグラフ・パターン・ブロックに適用されます。次の例では、hasContractValueプロパティがOPTIONALグラフ・パターンで参照され、対応する適用パターンがグラフ・パターンのこのブロックに対して実施されます。
Query:
{ ?contr pred:drivenBy ?dept .
OPTIONAL { ?contr pred:hasContractValue ?val } }
Rewritten query:
{ ?contr pred:drivenBy ?dept .
OPTIONAL { ?contr pred:hasContractValue ?val .
?contr pred:hasManager
"sys_context('sa$appctx','app_user_uri'}"^^orardf:instruction }
データ・アクセス制約の適用パターンは、複数のトリプル・パターンとFILTER句のある有効な基本グラフ・パターンになります。たとえば、VPロールを持つユーザーのhasContractValueプロパティに対するアクセス制約によって、そのユーザーは、契約を推進する部門の部長である場合にのみ、プロパティにアクセスできるようになります。このような制約の一致パターンと適用パターンは、次のように定義できます。
Match: { ?contract pred:hasContractValue ?cvalue }
Apply: { ?contract pred:drivenBy ?dept .
?dept pred:hasVP
"sys_context('sa$appctx','app_user_uri'}"^^orardf:instruction }
RDFクラスに関連付けられたデータ・アクセス制約に定義されている一致パターンによって、クラスのインスタンスに認識されているすべての変数および用語が識別されます。VPDポリシーに定義されているRDFメタデータは、各変数のタイプとSPARQL問合せの用語を決定するために使用され、適切なアクセス制約がこれらの変数と用語に適用されます。たとえば、次のVPD制約によって、Contractクラスのメンバーであるリソースに、そのリソースとのhasMember関係を持つユーザーのみがアクセスできることが保証されます。
Match: { ?contract rdf:type <http://www.myorg.com/classes/Contract> }
Apply: { ?contract pred:hasMember
"sys_context('sa$appctx','app_user_uri'}"^^orardf:instruction }
SPARQL問合せに出現する変数または用語のクラス情報は、問合せに出現するプロパティのドメインおよびレンジ情報を使用して導出されます。次の例のSPARQL問合せでは、drivenByプロパティのドメインがContractクラスであると表明するRDFスキーマ文をVPDポリシーが含んでいる場合、変数?contrは、Contractクラスのインスタンスを保持するものとして認識されます。したがって、前に定義されたContractクラスのアクセス制限によって、次の例に示すとおり、ユーザー問合せは適切な適用パターンを含むようにリライトされます。
Query:
{ ?contr pred:drivenBy ?dept .
?contr pred:hasDueDate ?due }
Rewritten query:
{ ?contr pred:drivenBy ?dept .
?contr pred:hasDueDate ?due .
?contr pred:hasMember
"sys_context('sa$appctx','app_user_uri'}"^^orardf:instruction }
SPARQL問合せの基本グラフ・パターンが複数のデータ・アクセス制約に一致する場合、対応する適用パターンは、組み合されて結合グラフ・パターンを構成します(これは、SPARQL問合せを論理的にリライトすることで、後で特定のグラフ・パターンに対して実施されます)。特定のSPARQL問合せに対して実施されるデータ・アクセス制約が考慮される一方で、VPDポリシーに関連付けられたクラスおよびプロパティ階層が参照され、すべての適用可能な制約が自動的に実施されます。
特定のRDFクラスのインスタンスとして識別される変数または用語によって、クラスとそのすべてのスーパークラスに関連付けられている制約が実施されます。
プロパティに関連付けられた制約は、ユーザー問合せによって、そのプロパティ(またはそのサブプロパティや等価プロパティとして定義されたプロパティ)が参照される場合に実施されます。
データ・アクセス制約のsys_contextファンクションを使用して、構造的に類似したグラフ・パターンを持つコンテキスト依存のアクセス制限を実施できます。アプリケーション・コンテキストに基づいて制約グループを動的にアクティブ化および非アクティブ化し、構造的に異なるグラフ・パターンを使用して代替アクセス制限を実施できます。
MDSYS.RDFVPD_POLICIESビューには、スキーマに定義されているすべてのVPDポリシーまたはユーザーが完全なアクセス権限を持っているポリシーに関する情報が含まれます。同じポリシーが複数のモデルに関連付けられている場合、ビューにはそのような関連ごとに1つのエントリが含まれます。このビューは、セマンティク・ネットワークとVPDポリシーが作成された後にのみ存在します。
表5-1に、MDSYS.RDFVPD_POLICIESビューの列を示します。
MDSYS.RDFVPD_MODELSビューには、RDFモデルとそれに関連付けられたVPDポリシーに関する情報が含まれます。このビューは、セマンティク・ネットワークとVPDポリシーが作成された後にのみ存在します。
表5-2に、MDSYS.RDFVPD_MODELSビューの列を示します。
MDSYS.RDFVPD_POLICY_CONSTRAINTSビューには、現在のユーザーがアクセスできるVPDポリシーに定義された制約に関する情報が含まれます。このビューは、セマンティク・ネットワークとVPDポリシーが作成された後にのみ存在します。
表5-3に、MDSYS.RDFVPD_POLICY_CONSTRAINTSビューの列を示します。
表5-3 MDSYS.RDFVPD_POLICY_CONSTRAINTSビューの列
| 列名 | データ型 | 説明 |
|---|---|---|
|
POLICY_OWNER |
VARCHAR2(32) |
VPDポリシーの所有者。 |
|
POLICY_NAME |
VARCHAR2(32) |
VPDポリシーの名前。 |
|
CONSTRAINT_NAME |
VARCHAR2(32) |
制約の名前。 |
|
MATCH_PATTERN |
VARCHAR2(1000) |
制約の一致パターン。 |
|
APPLY_PATTERN |
VARCHAR2(4000) |
制約の適用パターン。 |
|
CONSTRAINT_GROUP |
VARCHAR2(32) |
制約が属している制約グループの名前。(大/小文字の区別なし。) |
MDSYS.RDFVPD_PREDICATE_MDATAビューには、VPDポリシーに関連付けられた述語メタデータに関する情報が含まれます。このビューは、セマンティク・ネットワークとVPDポリシーが作成された後にのみ存在します。
表5-4に、MDSYS.RDFVPD_PREDICATE_MDATAビューの列を示します。
MDSYS.RDFVPD_RESOURCE_RELビューには、VPDポリシーのリソース間に定義されているサブクラス、サブプロパティおよび等価プロパティの関係に関する情報が含まれます。このビューは、セマンティク・ネットワークとVPDポリシーが作成された後にのみ存在します。
表5-5に、MDSYS.RDFVPD_RESOURCE_RELビューの列を示します。
RDFデータのOracle Label Security (OLS)では、セマンティク・データを保護するために2つのオプションが提供されます。
オプションを指定するには、適切なrdfsa_optionsパラメータ値とともにSEM_RDFSA.APPLY_OLS_POLICYプロシージャを使用します。
一方のオプションを他方に切り替えるには、SEM_RDFSA.REMOVE_OLS_POLICYプロシージャを使用して既存のポリシーを削除してから、適切なrdfsa_optionsパラメータ値とともにSEM_RDFSA.APPLY_OLS_POLICYプロシージャを使用して新しいポリシーを適用します。
トリプルレベル・セキュリティ・オプションによって、Oracle Databaseによるラベル・セキュリティのネイティブ・サポートに加え、RDF固有の機能のThinレイヤーが提供されます。このオプションは、特にOLSを使用しながら推論を実行する場合、リソースレベル・セキュリティ(5.2.2項を参照)より高いパフォーマンスを発揮し、容易に使用できます。主な違いは、トリプルレベル・セキュリティでは、個々のトリプル・リソース(主語、プロパティ、目的語)に明示的にも暗黙的にもラベルを割り当てる必要がないところにあります。
|
注意: トリプルレベル・セキュリティを使用するには、My Oracle Supportから入手できるパッチ9819833 SEMANTIC TECHNOLOGIES 11G R2 FIX BUNDLE 2を最初にインストールする必要があります。 |
トリプルレベル・セキュリティを使用するには、SEM_RDFSA.APPLY_OLS_POLICYプロシージャの実行時に、rdfsa_optionsパラメータ値としてSEM_RDFSA.TRIPLE_LEVEL_ONLYを指定します。次に例を示します。
EXECUTE sem_rdfsa.apply_ols_policy('defense', SEM_RDFSA.TRIPLE_LEVEL_ONLY);
SEM_RDFSA.APPLY_OLS_POLICYプロシージャに他の使用可能なパラメータを指定しないでください。
トリプルレベル・セキュリティを使用する場合、ネットワークの各セマンティク・モデルにはOLSが適用されます。つまり、関連する内部表とすべてのアプリケーション表にラベル・セキュリティが適用されるため、既存のセマンティク・モデルのアプリケーション表に手動でポリシーを適用する必要はありません。ただし、OLSポリシーの適用後に追加のモデルを作成する必要がある場合、モデルを作成する前に、SEM_OLS.APPLY_POLICY_TO_APP_TABプロシージャを使用してアプリケーション表にOLSを適用する必要があります。同様に、セマンティク・モデルをすでに削除していて、アプリケーション表を保護する必要がなくなった場合、SEM_OLS.REMOVE_POLICY_FROM_APP_TABプロシージャを使用できます。(これらのプロシージャの詳細は、第10章を参照してください。)
トリプルレベル・セキュリティでは、異なるラベルを持つ重複トリプルをセマンティク・モデルに挿入できます。(このような重複は、リソースレベル・セキュリティでは許可されません。)たとえば、次のように非常に機密性の高いラベルを持つトリプルがあるとします。
(<urn:X>,<urn:P>,<urn:Y>, "TOPSECRET")
この場合でも、権限の低い(UNCLASSIFIED)ユーザーは、トリプル(<urn:X>,<urn:P>,<urn:Y>, "UNCLASSIFIED")を挿入できます。SPARQLおよびSEM_MATCHではラベル情報が戻されないため、問合せでは両方の行が戻され(ユーザーが適切な権限を持っていると仮定)、TOPSECRETトリプルとUNCLASSIFIEDトリプルを簡単に区別することはできません。
セマンティク・モデルを問い合せる際にこのようにセキュリティの低いトリプルをフィルタするには、SEM_MATCHで次のオプションを1つ以上使用します。
POLICY_NAMEは、OLSポリシー名を指定します。
MIN_LABELは、問合せに含まれるトリプルに最小限のラベルを指定します。
つまり、厳密にMIN_LABELより優位性の低いラベルを含むトリプルは、すべて問合せから除外されます。たとえば、UNCLASSIFIEDトリプルをフィルタする場合、次の問合せを使用できます(OLSポリシー名がDEFENSEで、問合せユーザーがUNCLASSIFIEDトリプルとTOPSECRETトリプルに対する読取り権限を持っていると仮定)。
SELECT s,p,y FROM table(sem_match('{?s ?p ?y}' ,
sem_models(TEST'), null, null, null, null,
'MIN_LABEL=TOPSECRET POLICY_NAME=DEFENSE'));
前述の例のフィルタ処理は、ネイティブOLSソフトウェアによって実行されるセキュリティ・チェックに追加して発生します。
トリプルが挿入されると、セマンティク・モデルのアプリケーション表のCTXT1列を使用してラベル情報を表示および更新できます(ラベルを変更するためのWRITEUP権限とWRITEDOWN権限を持っていると仮定)。
トリプルレベル・セキュリティで推論またはバルク・ロードを実行できるユーザーの制限はなく、推論またはバルク・ロードされたトリプルは、すべてユーザーのセッション行ラベルで挿入されます。SA_UTLパッケージを使用してセッション・ラベルを変更できることに注意してください。(詳細は、『Oracle Label Security管理者ガイド』を参照してください。)
リソースレベル・セキュリティ・オプションによって、表の行にセキュリティ・レベルを定義する1つ以上のセキュリティ・ラベルを割り当てることができます。概念上、リレーショナル・データ・モデルの表は、同等のRDFグラフにマップできます。具体的には、リレーショナル表の行を、それぞれが特定の主語に関するファクトを表明するトリプルのセットにマップできます。このシナリオでは、主語は行の主キーを表し、行のキー以外の列と値の各組合せは、対応するトリプルの述語と目的語の値の組合せにマップされます。
リレーショナル・データ・モデルの行は、そのキーによって識別され、OLSは、行レベルのアクセス制御メカニズムとして、キーに関連付けられた値に対するアクセスを効果的に制限します。リレーショナル・データ・モデルとRDFデータ・モデル間のこの概念的なマッピングでは、リレーショナル表の行に対するアクセスを制限することは、特定の主語を含むサブグラフに対するアクセスを制限することと同等です。各トリプルの機密性ラベルをサポートするモデルでは、特定の主語を含むすべてのトリプルに同じラベルを適用することでこれが実施されます。ただし、個々のトリプルが異なるラベルを保持できるようにすることで、すべてのラベルの最小境界を維持しながら、柔軟性を大幅に向上することもできます。
OLSによるRDFデータのサポートでは、マルチレベル・アプローチが採用され、トリプル・コンポーネント(主語、述語、目的語)に関連付けられた機密性ラベルは、トリプルの機密性ラベルの最小境界を集合的に構成します。このアプローチでは、(主語、述語または目的語として使用される) RDFリソースに関連付けられたデータ機密性ラベルによって、権限のないユーザーがそのリソースを含むトリプルにアクセスすることや、そのリソースを含む新しいトリプルを作成することが制限されます。たとえば、主語であるprojectHLSに最小限の機密性ラベルが含まれると、この主語を記述するすべてのトリプルに少なくともprojectHLSのラベルを網羅する機密性ラベルが含まれることが保証されます。また、述語であるhasContractValueにより高い機密性ラベルが含まれると、この述語をprojectHLSとともに使用してトリプルを構成する場合、次の例のように、そのトリプルに少なくとも主語と述語両方のラベルを網羅するラベルが含まれます。
Triple 1: <http://www.myorg.com/contract/projectHLS> :ownedBy <http://www.myorg.com/department/Dept1> Triple 2: <http://www.myorg.com/contract/projectHLS> :hasContractValue "100000"^^xsd:integer
機密性ラベルは、トリプルに出現する位置に基づいてRDFリソース(URI)に関連付けられます。たとえば、同じRDFリソースが、異なるトリプルの異なる位置(主語、述語または目的語)に出現することがあります。3つの一意のラベルを各リソースに割り当てることができるため、適切なラベルの使用によって、トリプルのリソースの位置に基づいてトリプルのラベルが決定されます。OLSポリシーをRDFリポジトリに適用する場合、データベース・インスタンスで保護する特定のリソース位置を選択できます。後続の別の項で説明するとおり、主語、目的語、述語またはその任意の組合せを保護できます。次の例では、defenseというOLSポリシーをRDFリポジトリに適用し、機密性ラベルをRDFの主語と述語に関連付けることができるようにしています。
begin
sem_rdfsa.apply_ols_policy(
policy_name => 'defense',
rdfsa_options => sem_rdfsa.SECURE_SUBJECT+
sem_rdfsa.SECURE_PREDICATE);
end;
/
同じRDFリソースは、主語と目的語の両方の位置(および場合によっては述語の位置)に出現することが可能で、このようなリソースは、その位置に基づいて異なる機密性ラベルを持つことができます。特定の位置にあるリソースを使用するトリプルは、そのリソースの位置に対応するラベルを網羅するラベルを持つ必要があります。この場合、トリプルを表明するかトリプルにアクセスできるのは、そのトリプルおよびリソース・ラベルを網羅するラベルを持つユーザーのみです。
特定のRDFリポジトリでは、主語、述語、目的語またはこれらの組合せに対して、データ分類技術に基づいたセキュリティを有効化できます。これによって、リポジトリに追加されたすべてのトリプルは、必ず前述のラベル関係に自動的に準拠します。
RDFリソース(通常はURI)は、表明がリソースに関して行われる場合、トリプルの主語の位置に出現します。この場合、リソースに関連付けられた機密性ラベルには、次の特性があります。
ラベルは、リソースを主語として使用するトリプルの最小限の機密性ラベルを表します。つまり、トリプルの機密性ラベルは、主語のラベルに優先するか、それを網羅する必要があります。
新しく追加されたトリプルのラベルは、ユーザーの初期行ラベルに初期化されるか、ラベル・ファンクションを使用して生成されます(ラベルを指定した場合)。この操作は、トリプルのラベルが、トリプルの主語に関連付けられたラベルより優先される場合にのみ成功します。
トリプルを読み取ることができるのは、主語のラベルとトリプルのラベルに優先するアクセス・ラベルを持つユーザーのみです。
デフォルトでは、主語の機密性ラベルは、最初にRDFリソースがトリプルの主語の位置で使用されるときにユーザー環境から導出されます。この場合、デフォルトの機密性ラベルは、ユーザーの初期行ラベルに設定されます(ユーザーによって挿入されるすべての行に割り当てられるデフォルト)。
ただし、トリプルで使用する前でも、RDFリソースを主語として分類し、それに機密性ラベルを割り当てることができます。次の例では、SECRET:HLS:USという機密性ラベルをprojectHLSリソースに割り当て、それによってこのリソースに関する新しいトリプルを定義できるユーザーと、このリソースを主語として使用する既存のトリプルにアクセスできるユーザーを制限しています。
begin
sem_rdfsa.set_resource_label(
model_name => 'contracts',
resource_uri => '<http://www.myorg.com/contract/projectHLS>',
label_string => 'SECRET:HLS:US',
resource_pos => 'S');
end;
RDFの述語は、主語と目的語の間の関係を定義します。RDFの述語に関連付けられた機密性ラベルを使用して、すべての主語との特定のタイプの関係に対するアクセスを制限できます。
RDFの述語は、リレーショナル表の列に類似し、特定の述語に対するアクセスを制限する機能は、列レベルでリレーショナル・データを保護することと同等です。主語を保護する場合と同様に、述語の機密性ラベルによって、この述語を使用するトリプルの最小境界が作成されます。また、これは、ユーザーが述語を含むトリプルを定義したり、述語を含むトリプルにアクセスする場合に持っている必要のある最小限の認可権限に相当します。
次の例では、ラベルHSECRET:FIN (このシナリオでは、機密性が高く、かつ経理部に属するラベル)を述語hasContractValueを含むトリプルに割り当て、そのような許可を持つユーザーのみがトリプルを定義し、またはトリプルにアクセスできるようにしています。
begin
sem_rdfsa.set_predicate_label(
model_name => 'contracts',
predicate => '<http://www.myorg.com/pred/hasContractValue>',
label_string => 'HSECRET:FIN');
end;
/
主語と組み合せて述語を保護できます。この場合、主語と述語を使用するトリプルは、少なくとも主語と述語の両方のラベルを網羅する機密性ラベルを持つことが保証されます。前述の例を拡張して、主語であるprojectHLSをラベルSECRET:HLS:USで保護する場合、および述語であるhasContractValueをラベルHSECRET:FIN:で保護する場合、projectHLSの金額値を割り当てるトリプルは、少なくともラベルHSECRET:HLS,FIN:USを持つ必要があります。実際、トリプルを定義し、またはトリプルにアクセスできるようにするには、ユーザーのラベルがこのトリプルのラベルに優先している必要があります。
RDFトリプルは、その目的語の位置にURIまたはリテラルを持つことができます。トリプルの目的語の位置にあるURIは、リソースを表します。目的語の位置にあるリソースは、それに機密性ラベルを関連付けることで、トリプルの目的語としてリソースを使用する機能を制限するように保護できます。
通常、トリプルの目的語の位置に出現するリソース(URIまたは非リテラル)は、それ自体、追加のRDF文を使用して記述できます。実際、目的語の位置にあるRDFリソースは、他のトリプルの主語の位置に出現することがあります。RDFリソースが明示的な機密性ラベルを使用せずに目的語の位置で保護される場合、主語の位置にある同じリソースに関連付けられたラベルは、目的語のデフォルト・ラベルとして使用されます。
RDFデータ・モデルでは、宣言ルールの指定が可能で、明示的にリポジトリに追加されていないRDF文の存在を推論できます。次に、単純な宣言ルールを示します(これらのルールは、プロジェクトは部門によって所有可能で、部門には部長が存在し、その場合プロジェクト・リーダーはデフォルトでプロジェクトを所有する部門の部長になるというロジックに関連付けられています)。
RuleID -> projectLedBy Antecedent Expression -> (?proj :ownedBy ?dept) (?dept :hasVP ?person) Consequent Expression -> (?proj :isLedBy ?person)
RDFルールは、明示的に表明されたトリプルと、前に推論されたトリプルを前件として使用し、1つ以上の結果トリプルを推論します。通常、推論プロセスは、オフライン操作として実行され、すべての推論されたトリプルが事前生成されて、後続の問合せ操作で使用できるようになります。
基礎となるRDFグラフがOLSを使用して保護される場合、権限のないユーザーにデータを公開することを避けるため、グラフから推論された追加データも保護する必要があります。また、推論プロセスは、完全性を保証するため、より高い権限(特にデータに対する完全なアクセス権限)で実行する必要があります。
OLSによるRDFデータのサポートによって、1つ以上のRDFアーティファクトに関連付けられたラベルに基づいて、推論されたトリプルの機密性ラベルを生成するための技術が提供されます。これによって、推論時に起動できるラベル生成技術が提供されます。また、拡張可能な実装によって特定のトリプルの使用可能なラベルのセットを受信し、アプリケーション固有のロジックに基づいてトリプルに最も適した機密性ラベルを決定できる拡張フレームワークも提供されます。推論されたトリプルのラベルを生成する場合に使用できる技術は、次のとおりです(各技術は、前件ラベルの使用を除き、SEM_RDFSAパッケージ定数に関連付けられます)。
ルール・ラベルの使用(SEM_RDFSA.LABELGEN_RULE): 推論されたトリプルは、特定のルールによって直接生成され、状況によってはその前件を通じて他のルールに間接的に依存します。各ルールは、機密性ラベルを持つことが可能で、それはルールによって直接推論されたすべてのトリプルの機密性ラベルとして使用されます。
主語ラベルの使用(SEM_RDFSA.LABELGEN_SUBJECT): 新しいトリプルの主語に関連付けられた機密性ラベルを考慮することで、推論されたトリプルのラベルを導出します。推論された各トリプルは、主語を持ち、それがトリプルの前件のいずれかに含まれる主語、述語または目的語になることが可能です。このようなRDFリソースが保護される場合、新しく推論されたトリプルの主語は、1つ以上のラベルに関連付けることができます。主語ラベルの使用の技術では、推論されたトリプルのラベルは、RDFリソースに関連付けられた一意のラベルに設定されます。リソースに複数のラベルが存在する場合、拡張可能なロジックを実装して新しいトリプルに最も適したラベルを決定できます。
述語ラベルの使用(SEM_RDFSA.LABELGEN_PREDICATE): 新しいトリプルの述語に関連付けられた機密性ラベルを考慮することで、推論されたトリプルのラベルを導出します。推論された各トリプルは、述語を持ち、それがトリプルの前件のいずれかに含まれる主語、述語または目的語になることが可能です。このようなRDFリソースが保護される場合、新しく推論されたトリプルの述語は、1つ以上のラベルに関連付けることができます。述語ラベルの使用の技術では、推論されたトリプルのラベルは、RDFリソースに関連付けられた一意のラベルに設定されます。リソースに複数のラベルが存在する場合、拡張可能なロジックを実装して新しいトリプルに最も適したラベルを決定できます。
目的語ラベルの使用(SEM_RDFSA.LABELGEN_OBJECT): 新しいトリプルの目的語に関連付けられた機密性ラベルを考慮することで、推論されたトリプルのラベルを導出します。推論された各トリプルは、目的語を持ち、それがトリプルの前件のいずれかに含まれる主語、述語または目的語になることが可能です。このようなRDFリソースが保護される場合、新しく推論されたトリプルの目的語は、1つ以上のラベルに関連付けることができます。目的語ラベルの使用の技術では、推論されたトリプルのラベルは、RDFリソースに関連付けられた一意のラベルに設定されます。リソースに複数のラベルが存在する場合、拡張可能なロジックを実装して新しいトリプルに最も適したラベルを決定できます。
上位ラベルの使用(SEM_RDFSA.LABELGEN_DOMINATING): 推論された各トリプルは、最小限で4つの直接コンポーネント(主語、述語、目的語、およびトリプルを生成したルール)を持ちます。上位ラベルの使用の技術では、推論時に、ラベル・ジェネレータによって、各コンポーネントに関連付けられた最上位の機密性ラベルが計算され、それが推論されたトリプルの機密性ラベルとして割り当てられます。様々なラベル間に明確な支配関係を確立できない場合、例外ラベルが割り当てられます。
前件ラベルの使用: 推論された各トリプルの4つの直接コンポーネント(主語、述語、目的語、およびトリプルを生成したルール)に加え、トリプルは、新しいトリプルを推測する手段となる1つ以上の前件トリプルを持つことができます。前件ラベルの使用の技術では、すべての前件トリプルのラベルが考慮され、新しいトリプルに最も適したラベルを決定するために、競合解決基準が実装されます。推論されたトリプルは、他の推論されたトリプルに依存することがあるため、すべての推論されたトリプルのラベルの生成中は厳密な順序に従います。
前件ラベルの使用の技術では、カスタム・ラベル・ジェネレータを使用する必要があります。カスタム・ラベル・ジェネレータの作成および使用の詳細は、5.2.2.5項を参照してください。
次の例では、特定のルールベースを使用して契約データの伴意(ルール索引)を作成しています。この操作は、OLSポリシーがRDFリポジトリに適用されている状態で完全なアクセス権限を持つユーザーによってのみ実行できます。この場合、推論されたトリプルに生成されるラベルは、label_genパラメータでのSEM_RDFSA.LABELGEN_PREDICATEパッケージ定数の使用に従って、述語に関連付けられたラベルに基づきます。
begin
sem_rdfsa.create_entailment(
index_name_in => 'contracts_inf',
models_in => SDO_RDF_Models('contracts'),
rulebases_in => SDO_RDF_Rulebases('contracts_rb'),
options => 'USER_RULES=T',
label_gen => sem_rdfsa.LABELGEN_PREDICATE);
end;
事前定義された、または拡張可能なラベル生成の実装によって、推論されたトリプルに適用される一意のラベルを計算できない場合、トリプルに例外ラベルが設定されます。このようなトリプルには、RDFデータに対する完全なアクセス権限を持っているユーザー(および推論プロセスを開始したユーザー)以外のユーザーはアクセスできません。例外ラベル付きのトリプルは、明確にマークされるため、権限のあるユーザーはそれらにアクセスし、手動で意味のあるラベルを適用できます。推論されたトリプルに機密性ラベルが適用された後は、互換性のあるラベルを持つユーザーのみがそれらのトリプルにアクセスできます。次の例では、例外ラベルが設定されているトリプルの機密性ラベルを更新しています。
update mdsys.rdfi_contracts_inf
set ctxt1 = char_to_label('defense', 'SECRET:HLS:US')
where ctxt1 = -1;
生成されたラベルを通じてアクセスされる推論されたトリプルは、ユーザー・アクセス可能なトリプルおよびルールから直接推論される概念上のトリプルとは異なることがあります。システム定義の実装またはカスタム実装を使用して生成されるラベルの正確性は、保証されません。詳細は、第9章のSEM_APIS.CREATE_ENTAILMENTプロシージャの「使用方法」にある「ファイングレイン・アクセス制御(VPDおよびOLS)に関する考慮事項」を参照してください。
MDSYS.RDFSA_LABELGENタイプは、索引の作成時に適切なラベル・ジェネレータ・ロジックを適用するために使用されますが、このタイプを拡張してカスタム・ラベル・ジェネレータを実装し、アプリケーション・ロジックに基づくラベルを生成することもできます。ラベル・ジェネレータは、SEM_APIS.CREATE_ENTAILMENTプロシージャでlabel_genパラメータを使用して指定します。システム定義のラベル・ジェネレータを使用するには、SEM_RDFSAパッケージ定数(5.2.2.4項を参照)を指定し、カスタム・ラベル・ジェネレータを使用するには、カスタム・ラベル・ジェネレータ・タイプを実装してSEM_RDFSAパッケージ定数のかわりにそのタイプのインスタンスを指定する必要があります。
カスタム・ラベル・ジェネレータ・タイプを作成するには、RDFSA_LABELGENタイプに対するUNDER権限を持っている必要があります。また、RDFデータの索引を作成するには、このタイプに対するEXECUTE権限を持っている必要があります。次の例では、RDF_ADMINというユーザーにこれらの権限を付与しています。
GRANT under, execute ON mdsys.rdfsa_labelgen TO rdf_admin;
カスタム・ラベル・ジェネレータ・タイプは、次の例に示すとおり、コンストラクタを実装する必要があります(このコンストラクタによって、依存リソースを設定し、渡された情報から計算したラベルを戻すgetNumericLabelメソッドを指定します)。
CREATE OR REPLACE TYPE CustomSPORALabel UNDER mdsys.rdfsa_labelgen (
constructor function CustomSPORALabel return self as result,
overriding member function getNumericLabel (
subject rdfsa_resource,
predicate rdfsa_resource,
object rdfsa_resource,
rule rdfsa_resource,
anteced rdfsa_resource)
return number);
ラベル・ジェネレータ・コンストラクタは、SEM_RDFSAパッケージに定義されている定数のセットを使用して、ラベル・ジェネレータが依存しているリソースのリストを示します。依存リソースは、推論されたトリプルの主語、述語、目的語、トリプルを生成したルール、およびその前件として識別されます。カスタム・ラベル・ジェネレータは、ラベルを生成するためにこれらのリソースの任意のサブセットに依存することが可能で、SEM_RDFSAパッケージに定義されている定数(USE_SUBJECT_LABEL、USE_PREDICATE_LABEL、USE_OBJECT_LABEL、USE_RULE_LABEL、USE_ANTCED_LABEL)を使用してそのコンストラクタにこれを指定できます。次の例では、タイプ本体を作成し、コンストラクタを指定しています。
例5-1では、タイプ本体を作成し、コンストラクタ・ファンクションおよびgetNumericLabelメンバー・ファンクションを指定しています。(アプリケーション固有のロジックはこの例に含まれていません。)
例5-1 カスタム・ラベル・ジェネレータ・タイプの作成
CREATE OR REPLACE TYPE BODY CustomSPORALabel AS
constructor function CustomSPORALabel return self as result as
begin
self.setDepResources(sem_rdfsa.USE_SUBJECT_LABEL+
sem_rdfsa.USE_PREDICATE_LABEL+
sem_rdfsa.USE_OBJECT_LABEL+
sem_rdfsa.USE_RULE_LABEL+
sem_rdfsa.USE_ANTECED_LABELS);
return;
end CustomSPORALabel;
overriding member function getNumericLabel (
subject rdfsa_resource,
predicate rdfsa_resource,
object rdfsa_resource,
rule rdfsa_resource,
anteced rdfsa_resource)
return number as
labellst mdsys.int_array := mdsys.int_array();
begin
-- Find dominating label of S P O R A –
–- Application specific logic for computing the triple label –
-- Copy over all labels to labellst --
for li in 1 .. subject.getLabelCount() loop
labellst.extend;
labellst(labellst.COUNT) = subject.getLabel(li);
end loop;
--- Copy over other labels as well ---
--- Find a dominating of all the labels. Generates –1 if no
--- dominating label within the set
return self.findDominatingOf(labellst);
end getNumericLabel;
end CustomSPORALabel;
/
例5-1では、サンプルのラベル・ジェネレータ実装で、トリプルの機密性ラベルを生成するために、推論されたトリプルに提供されるすべてのリソースを使用しています。そのため、コンストラクタは、スーパークラスに定義されたsetDepResourcesメソッドを使用して、そのすべての依存コンポーネントを設定します。この手順で設定される依存リソースのリストによって、ラベル生成ルーチンに渡される値の正確なリストが決定されます。
getNumericLabelメソッドは、推論されたトリプルが依存できるリソースごとに1つの引数を持つラベル生成ルーチンです。対応する依存リソースがコンストラクタの実装に設定されていない場合、いくつかの引数はNULL値になることがあります。
ラベル・ジェネレータの実装では、RDFSA_LABELGENタイプに定義されている汎用の静的ルーチンを使用して、特定のラベル・セットの上位ラベルを検出できます。ラベル・セットは、MDSYS.INT_ARRAYタイプのインスタンスに渡され、メソッドはそのうちの上位ラベルを検出します。そのようなラベルが存在しない場合、例外ラベル-1が戻されます。
カスタム・ラベル・ジェネレータ・タイプを実装した後、次の例に示すとおり、SEM_APIS.CREATE_ENTAILMENTプロシージャのlabel_genパラメータにこのタイプのインスタンスを割り当てることで、推論されたデータのカスタム・ラベル・ジェネレータを使用できます。
begin
sem_apis.create_entailment(
index_name_in => 'contracts_rdfsinf',
models_in => SDO_RDF_Models('contracts'),
rulebases_in => SDO_RDF_Rulebases('RDFS'),
options => '',
label_gen => CustomSPORALabel());
end;
/
MDSYS.RDFOLS_SECURE_RESOURCEビューには、Oracle Label Security (OLS)ポリシーで保護されたリソースと、それらのリソースに関連付けられた機密性ラベルに関する情報が含まれます。
このビューに対するSELECT権限を適切なユーザーに付与できます。特定のモデルに関連付けられたリソースを表示するには、そのモデル(または対応するRDFM_model-nameビュー)に対するSELECT権限も持っている必要があります。
表5-6に、MDSYS.RDFOLS_SECURE_RESOURCEビューの列を示します。
表5-6 MDSYS.RDFOLS_SECURE_RESOURCEビューの列
| 列名 | データ型 | 説明 |
|---|---|---|
|
MODEL_NAME |
VARCHAR2(25) |
モデルの名前。 |
|
MODEL_ID |
NUMBER |
モデルの内部識別子。 |
|
RESOURCE_ID |
NUMBER |
リソースの内部識別子(リソースに関する情報用としてMDSYS.RDF_VALUE$.VALUE_ID列に結合)。 |
|
RESOURCE_TYPE |
VARCHAR2(16) |
ラベルが割り当てられるリソース・タイプを示す文字列値( |
|
CTXT1 |
NUMBER |
リソースに割り当てられる機密性ラベル。 |
