RDFデータのファイングレイン・アクセス制御

5 RDFデータのファイングレイン・アクセス制御

Oracle Databaseセマンティク・データ・ストアへのアクセスのデフォルト制御は、モデル・レベルであり、モデルの所有者は、RDFM_<model_name>という名前のビューで適切な権限を付与することによって、他のユーザーにそのモデルでの選択、削除および挿入の権限を付与することができます。ただし、厳密なセキュリティ要件を持つアプリケーションの場合は、Oracle DatabaseのOracle Label Securityオプションを使用して、ファイングレイン・アクセス制御メカニズムを実施できます。

RDFデータのOracle Label Security (OLS)によって、RDFモデルに格納された個々のトリプルに機密性ラベルを関連付けることができます。問合せごとに、それらのラベルとユーザーのセッション・ラベルを比較することで、特定のトリプルに対するアクセス権限が付与されます。また、特定のリソースを記述するすべてのトリプル、または特定の述語で定義されているすべてのトリプルの最小限の機密性ラベルを、それぞれリソースまたは述語に機密性ラベルを直接割り当てることで実施できます。

OLSの使用方法の詳細は、『Oracle Label Security管理者ガイド』を参照してください。

RDFデータのOracle Label Security (OLS)では、セマンティク・データを保護するために2つのオプションが提供されます。

トリプルレベル・セキュリティ(「トリプルレベル・セキュリティ」を参照) (パフォーマンスと使いやすさの点から強くお薦めします)
リソースレベル・セキュリティ(「リソースレベル・セキュリティ」を参照) (通常お薦めしません)

オプションを指定するには、SEM_RDFSA.APPLY_OLS_POLICYプロシージャを使用して、適切なrdfsa_optionsパラメータ値を指定します。

オプションを切り替えるには、SEM_RDFSA.REMOVE_OLS_POLICYプロシージャを使用して既存ポリシーを削除し、SEM_RDFSA.APPLY_OLS_POLICYプロシージャと適切なrdfsa_optionsパラメータ値を使用して新しいポリシーを適用します。

トリプルレベル・セキュリティ
トリプルレベル・セキュリティ・オプションは、RDF固有の機能からなるThinレイヤーであり、ラベル・セキュリティに対するOracle Databaseのネイティブ・サポートに追加されるものです。
リソースレベル・セキュリティ
リソースレベル・セキュリティ・オプションによって、表の行に対するセキュリティ・レベルを定義するセキュリティ・ラベルを、1つまたは複数割り当てることができます。

親トピック: 概念および使用方法に関する情報

5.1 トリプルレベル・セキュリティ

トリプルレベル・セキュリティ・オプションによって、Oracle Databaseによるラベル・セキュリティのネイティブ・サポートに加え、RDF固有の機能のThinレイヤーが提供されます。

このオプションは、特にOLSを使用しながら推論を実行する場合、リソースレベル・セキュリティ(「リソースレベル・セキュリティ」を参照)より高いパフォーマンスを発揮し、容易に使用できます。主な違いは、トリプルレベル・セキュリティでは、個々のトリプル・リソース(主語、プロパティ、目的語)に明示的にも暗黙的にもラベルを割り当てる必要がないところにあります。

トリプルレベル・セキュリティを使用するには、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プロシージャを使用できます。(ここで述べたプロシージャについては、「SEM_OLSパッケージのサブプログラム」を参照してください。)

トリプルレベル・セキュリティでは、異なるラベルを持つ重複トリプルをセマンティク・モデルに挿入できます。(このような重複は、リソースレベル・セキュリティでは許可されません。)たとえば、次のように非常に機密性の高いラベルを持つトリプルがあるとします。

(<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パッケージを使用してセッション・ラベルを変更できることに注意してください。(SQ_UTLの詳細は、『Oracle Label Security管理者ガイド』を参照してください。)

親トピック: RDFデータのファイングレイン・アクセス制御

5.1.1 推論データとラダーベース推論(LBI)のファイングレイン・セキュリティ

トリプルレベル・セキュリティをOracle Databaseに格納されたRDFデータに対してオンにすると、表明されたファクトに、必須アクセス制御を実施するためのデータ・ラベルがタグ付けされます。また、ユーザーがSEM_APIS.CREATE_ENTAILMENTプロシージャを使用して前方向連鎖ベースの推論関数を起動すると、新しく推論された関係には現在の行ラベル(SA_UTL.NUMERIC_ROW_LABEL)がタグ付けされます。

これらの新しく推論される関係は、ユーザーがアクセスを許可されている情報のみに基づいて導出されます。ただし、これらの関係では同じデータ・ラベルが共有されます。このことは、SEM_APIS.CREATE_ENTAILMENTコールが、読取り操作、論理推論による計算および書込み操作の3つのステップで示されることからわかります。読取り操作では推論計算のベースとなる情報が収集されますが、これはアクセス権限、ユーザーのラベルおよびデータ・ラベルによって制限されます。論理的推論計算のステップは完全に数学的です。伴意グラフへの推論情報の最終的な書込みは、前のステップで計算されるいくつかの新しいファクトを表明している同じユーザーと同様に行われます。

ユーザーが単一のラベルのみを所有する場合は、すべての推論された表明に単一のラベルをタグ付けすることで十分です。ユーザーが複数のラベルを持つ場合には、1つのラベルのタグ付けでは不十分です。マルチテナント状態でセットアップを行った場合によく見られる状況です。

たとえば、ユーザー・ラベルとデータ・ラベルをTopSecretと設定したユーザーが、SEM_APIS.CREATE_ENTAILMENTをコールして、Secretという弱い方のラベルに切り替えてからSPARQL問合せを実行したと仮定します。すべての新しく推論された関係はTopSecretラベルにタグ付けされているため、この問合せを参照することはできません。ただし、ユーザーがTopSecretラベルに切り替えて戻した場合、すべての推論された関係が参照可能になります。推論された関係に関するかぎり、これは「すべてまたはゼロ」の処理です(つまり、すべて参照可能またはすべて参照不可です)。

指定ユーザーが複数のラベルを使用できる場合は、通常、異なる推論された関係に異なるラベルを割り当てます。この目的を実現する方法は2つあります。

この2つの方法のうち、ラダーベース推論(Oracle Database 12cリリース1 (12.1)で有効)の方がより単純で便利です。

SEM_APIS.CREATE_ENTAILMENTの複数回の起動

DEFENSEという名前のセキュリティ・ポリシー、SCOTTという名前のユーザー、およびSCOTTが所有する一連のユーザー・ラベルLabel1、Label2、...、Labelnがあるとします。SCOTTによる次のコールは、ラベルをLabel1として設定し、1回目の推論を実行して、新しく推論されたトリプルにLabel1をタグ付けします。

EXECUTE sa_utl.set_label('defense',char_to_label('defense','Label1'));
EXECUTE sa_utl.set_row_label('defense',char_to_label('defense','Label1'));
EXECUTE sem_apis.create_entailment('inf', sem_models('contracts'), sem_rulebases('owlprime'), SEM_APIS.REACH_CLOSURE, null,'');

ここで、SCOTTはラベルをLabel2に切り替え、2回目の推論を実行し、新しく推論されたトリプルにLabel2をタグ付けします。明らかに、Label1がLabel2よりも優位である場合、Label2はLabel1が参照可能な内容以外を参照することはできないため、新しいトリプルは推論されません。Label1がLabel2よりも優位ではない場合、推論プロセスの読取りステップでは、異なるトリプル・セットを参照する可能性があるため、推論コールはいくつかの新しいトリプルを生成できます(それはLabel2がタグ付けされます)。

この例の目的上、1 <= i < j <= nという条件がtrueであること(LabeliがLabeljよりも優位ではないこと)を前提としています。

EXECUTE sa_utl.set_label('defense',char_to_label('defense','Label2'));
EXECUTE sa_utl.set_row_label('defense',char_to_label('defense','Label2'));
EXECUTE sem_apis.create_entailment('inf', sem_models('contracts'), sem_rulebases('owlprime'), SEM_APIS.REACH_CLOSURE, null, 'ENTAIL_ANYWAY=T');

SCOTTは、前のアクションを、Label1、Label2、...、Labelnというラベル順序の残りのラベルで続行します。最後のステップは次のとおりです。

EXECUTE sa_utl.set_label('defense',char_to_label('defense','Labeln'));
EXECUTE sa_utl.set_row_label('defense',char_to_label('defense','Labeln'));
EXECUTE sem_apis.create_entailment('inf', sem_models('contracts'), sem_rulebases('owlprime'), SEM_APIS.REACH_CLOSURE, null, 'ENTAIL_ANYWAY=T');

これらのすべてのアクションを実行すると、推論グラフは様々なラベルがタグ付けされたトリプルで構成される可能性があります。

ラダーベース推論(LBI)の使用

基本的に、1つのAPI内のラダーベース推論(LBI)ラップは、「SEM_APIS.CREATE_ENTAILMENTの複数回の実行」で説明されるすべてのアクションをコールします。視覚的に、これらのアクションは、はしごを登る様子と似ています。あるラベルから次のラベルに進むと、より多くの表明されたファクトが参照可能またはアクセス可能になるため(前のラベルすべてが新しいラベルよりも優位ではない場合)、新しい関係を推論できます。

次の例に、LBIを起動する構文を示します。

EXECUTE sem_apis.create_entailment('inf',
  sem_models('contracts'),
  sem_rulebases('owlprime'),
  SEM_APIS.REACH_CLOSURE,
  null,
  null,
  ols_ladder_inf_lbl_seq=>'numericLabel1 numericLabel2 numericLabel3 numericLabel4'
);

パラメータols_ladder_inf_lbl_seqでは、ラベル順序が指定されます。この順序は、数値ラベルのスペース区切りリストとして提供されます。LBIを使用する場合は、弱い方のラベルが強い方のラベルより前に配置されるように、ラベル順序を配置することをお薦めします。これは、推論されたグラフのサイズを減らすことになります。(ラベルが互いに優位ではない場合、それらはどのような順序でも指定できます。)

親トピック: トリプルレベル・セキュリティ

5.1.2 拡張例: セマンティク・データへのOLSトリプルレベル・セキュリティの適用

この項では、セマンティク・データにOLSトリプルレベル・セキュリティを適用する方法を説明する拡張例を示します。OLSが構成済で、有効であることが前提です。この例は非常に単純化されており、推奨のプラクティスで使用しているユーザー名およびパスワードをそのまま使用しないでください。

特に指定がないかぎり、このステップはSYSDBAとして接続中に実行します。

いくつかの必要な設定ステップを実行します。

SYSDBAとして、A、BおよびCという名前のデータベース・ユーザーを作成します。

create user a identified by <password-for-a>;
grant connect, unlimited tablespace, resource to a;
create user b identified by <password-for-b>;
grant connect, unlimited tablespace, resource to b;
create user c identified by <password-for-c>;
grant connect, unlimited tablespace, resource to c;

SYSDBAとして、セキュリティ管理者を作成し、権限を付与します。

CREATE USER fgac_admin identified by <password-for-fgac_admin>; 
GRANT connect, unlimited tablespace,resource to fgac_admin;
GRANT SELECT ON mdsys.rdf_link$ to fgac_admin;
GRANT EXECUTE ON sa_components TO fgac_admin;
GRANT EXECUTE ON sa_user_admin TO fgac_admin;
GRANT EXECUTE ON sa_label_admin TO fgac_admin;
GRANT EXECUTE ON sa_policy_admin TO fgac_admin;
GRANT EXECUTE ON sa_sysdba to fgac_admin;
GRANT EXECUTE ON TO_LBAC_DATA_LABEL to fgac_admin;
GRANT lbac_dba to fgac_admin;

セキュリティ管理者として接続し、defenseという名前のポリシーを作成します。
```
CONNECT fgac_admin/<password-for-fgac_admin>
EXECUTE SA_SYSDBA.CREATE_POLICY('defense','ctxt1');
```

3つのセキュリティ・レベルを作成します(簡略化のため、コンパートメントおよびグループを省略しています)。

EXECUTE SA_COMPONENTS.CREATE_LEVEL('defense',3000,'TS','TOP SECRET');
EXECUTE SA_COMPONENTS.CREATE_LEVEL('defense',2000,'SE','SECRET');
EXECUTE SA_COMPONENTS.CREATE_LEVEL('defense',1000,'UN','UNCLASSIFIED');

3つのラベルを作成します。

EXECUTE SA_LABEL_ADMIN.CREATE_LABEL('defense',1000,'UN');
EXECUTE SA_LABEL_ADMIN.CREATE_LABEL('defense',1500,'SE');
EXECUTE SA_LABEL_ADMIN.CREATE_LABEL('defense',3100,'TS');

ラベルおよび権限を割り当てます。

EXECUTE SA_USER_ADMIN.SET_USER_LABELS('defense','A','UN');
EXECUTE SA_USER_ADMIN.SET_USER_LABELS('defense','B','SE');
EXECUTE SA_USER_ADMIN.SET_USER_LABELS('defense','C','TS');
EXECUTE SA_USER_ADMIN.SET_USER_LABELS('defense','fgac_admin','TS');
EXECUTE SA_USER_ADMIN.SET_USER_PRIVS('defense','FGAC_ADMIN', 'full');

セマンティク・モデルを作成します。

モデルを作成し、他の何人かのユーザーとそれを共有します。

CONNECT a/<password-for-a>
CREATE TABLE project_tpl (triple sdo_rdf_triple_s) compress for oltp;
EXECUTE sem_apis.create_sem_model('project', 'project_tpl', 'triple');
GRANT select on mdsys.rdfm_project to B;
GRANT select on mdsys.rdfm_project to C;
GRANT select, insert, update, delete on project_tpl to B, C;

バルク・ロードAPIを実行できることを確認します。
```
GRANT insert on project_tpl to mdsys;
```

RDFのOLSポリシーを適用します。

CONNECT fgac_admin/fgac_admin
BEGIN
  sem_rdfsa.apply_ols_policy('defense', sem_rdfsa.TRIPLE_LEVEL_ONLY);
END;
/

この時点で、アプリケーション表にCTXT1という名前の別の列があることに注目してください。

CONNECT a/<password-for-a>a
DESCRIBE project_tpl;
Name                                      Null?    Type
----------------------------------------- -------- --------------------------
 TRIPLE                                             PUBLIC.SDO_RDF_TRIPLE_S
 CTXT1                                              NUMBER(10)

データをセマンティク・モデルに追加します。

-- User A uses incremental APIs to add semantic data
connnect a/<password-for a) 
INSERT INTO project_tpl(triple) values
  (sdo_rdf_triple_s('project','<urn:A>','<urn:hasManager>','<urn:B>')); 
INSERT INTO project_tpl(triple) values
  (sdo_rdf_triple_s('project','<urn:B>','<urn:hasManager>','<urn:C>'));
INSERT INTO project_tpl(triple) values
   (sdo_rdf_triple_s('project','<urn:A>','<urn:expenseReportAmount>','"100"'));
INSERT INTO project_tpl(triple) values 
  (sdo_rdf_triple_s('project','<urn:expenseReportAmount>','rdfs:subPropertyOf','<urn:projExp>'));
COMMIT;

-- User B uses bulk API to add semantic data 
connect b/<password-for-b>
CREATE TABLE  project_stab(RDF$STC_GRAPH varchar2(4000),
RDF$STC_sub varchar2(4000),
RDF$STC_pred varchar2(4000),
RDF$STC_obj varchar2(4000)) compress;
GRANT select on project_stab to mdsys;

-- For simplicity, data types are omitted.
INSERT INTO project_stab values(null, '<urn:B>','<urn:expenseReportAmount>','"200"'); 
INSERT INTO project_stab values(null, '<urn:proj1>','<urn:deadline>','"2012-12-25"');
EXECUTE sem_apis.bulk_load_from_staging_table('project','b','project_stab');

-- As User B, check the contents in the application table
 connect b/<password-for-b> 
SELECT * from a.project_tpl order by ctxt1;
 
SDO_RDF_TRIPLE_S(8.5963E+18, 7, 1.4711E+18, 2.0676E+18, 8.5963E+18)    1000
SDO_RDF_TRIPLE_S(5.1676E+18, 7, 8.5963E+18, 2.0676E+18, 5.1676E+18)    1000
SDO_RDF_TRIPLE_S(2.3688E+18, 7, 1.4711E+18, 4.6588E+18, 2.3688E+18)    1000
SDO_RDF_TRIPLE_S(7.6823E+18, 7, 4.6588E+18, 1.1911E+18, 7.6823E+18)    1000
SDO_RDF_TRIPLE_S(6.6322E+18, 7, 8.5963E+18, 4.6588E+18, 6.6322E+18)    1500
SDO_RDF_TRIPLE_S(8.4800E+18, 7, 6.2294E+18, 5.4118E+18, 8.4800E+18)    1500
 
6 rows selected.
SELECT count(1) from mdsys.rdfm_project;
6
 
-- As User A, check the contents in the application table
-- As expected, A can only see 4 triples
SQL> conn a/<password>
SQL> select * from a.project_tpl order by ctxt1;
SDO_RDF_TRIPLE_S(8.5963E+18, 7, 1.4711E+18, 2.0676E+18, 8.5963E+18)    1000
 
SDO_RDF_TRIPLE_S(5.1676E+18, 7, 8.5963E+18, 2.0676E+18, 5.1676E+18)    1000
 
SDO_RDF_TRIPLE_S(2.3688E+18, 7, 1.4711E+18, 4.6588E+18, 2.3688E+18)    1000
 
SDO_RDF_TRIPLE_S(7.6823E+18, 7, 4.6588E+18, 1.1911E+18, 7.6823E+18)    1000
 
SQL> select count(1) from mdsys.rdfm_project;
4
 
-- User C uses incremental APIs to add semantic data including 2 quads 
connect c/<password-for-c>
INSERT INTO a.project_tpl(triple) values
  (sdo_rdf_triple_s('project','<urn:C>','<urn:expenseReportAmount>','"400"'));
INSERT INTO a.project_tpl(triple) values
  (sdo_rdf_triple_s('project','<urn:proj1>','<urn:hasBudget>','"10000"'));
INSERT INTO a.project_tpl(triple) values
  (sdo_rdf_triple_s('project:<urn:proj2>','<urn:proj2>','<urn:hasBudget>','"20000"'));
INSERT INTO a.project_tpl(triple) values
  (sdo_rdf_triple_s('project:<urn:proj2>','<urn:proj2>','<urn:dependsOn>','<urn:proj1>'));
COMMIT;

デフォルト・ラベルを使用して、異なるユーザーとしてデータを問い合せます。

-- Now as user A, B, C, execute the following query 
select lpad(nvl(g, ' '), 20) || ' ' || s || ' ' || p || ' ' || o from table(sem_match('{ graph ?g { ?s ?p ?o }}',
sem_models('project'),
null,
null,
null,
null,
'GRAPH_MATCH_UNNAMED=T'
            ))
order by g, s, p, o;
 
connect  a/<password-for-a>
-- Repeat the preceding query
SQL> /
 
urn:A urn:expenseReportAmount 100
urn:A urn:hasManager urn:B
urn:B urn:hasManager urn:C
urn:expenseReportAmount http://www.w3.org/2000/01/rdf-schema#subPropertyOf urn:projExp
SQL> connect  b/<password-for-b>
SQL> /
 
urn:A urn:expenseReportAmount 100
urn:A urn:hasManager urn:B
urn:B urn:expenseReportAmount 200
urn:B urn:hasManager urn:C
urn:expenseReportAmount http://www.w3.org/2000/01/rdf-schema#subPropertyOf urn:projExp
urn:proj1 urn:deadline 2012-12-25
SQL> connect  c/<password-for-c>
SQL> /
 
urn:proj2 urn:proj2 urn:dependsOn urn:proj1
urn:proj2 urn:proj2 urn:hasBudget 20000
urn:A urn:expenseReportAmount 100
urn:A urn:hasManager urn:B
urn:B urn:expenseReportAmount 200
urn:B urn:hasManager urn:C
urn:C urn:expenseReportAmount 400
urn:expenseReportAmount http://www.w3.org/2000/01/rdf-schema#subPropertyOf urn:projExp
urn:proj1 urn:deadline 2012-12-25
urn:proj1 urn:hasBudget 10000

予測どおりに、異なるユーザー(異なるラベルを持つ)はプロジェクトRDFグラフの異なるトリプル・セットを参照できます。

異なるラベルを使用しているシングル・ユーザーとして、同じデータを問い合せます。

前のステップで使用した同じ問合せで、6つの一致が生成されます。

urn:A urn:expenseReportAmount 100
urn:A urn:hasManager urn:B
urn:B urn:expenseReportAmount 200
urn:B urn:hasManager urn:C
urn:expenseReportAmount http://www.w3.org/2000/01/rdf-schema#subPropertyOf urn:projExp
urn:proj1 urn:deadline 2012-12-25

6 rows selected.

ユーザーCが最も弱いラベル(unclassified)を選択した場合、ユーザーCが参照する内容はさらに少なくなります。

exec sa_utl.set_label('defense',char_to_label('defense','UN'));
exec sa_utl.set_row_label('defense',char_to_label('defense','UN'));

前のステップで使用した同じ問合せで、4つの一致が生成されます。

urn:A urn:expenseReportAmount 100
urn:A urn:hasManager urn:B
urn:B urn:hasManager urn:C
urn:expenseReportAmount http://www.w3.org/2000/01/rdf-schema#subPropertyOf urn:projExp

ユーザーCが、Secretよりも優位であるデータ・ラベルの付いたトリプル/クワッドに対してのみ問合せを実行した場合:

-- First set the label back
exec sa_utl.set_label('defense',char_to_label('defense','TS')); exec sa_utl.set_row_label('defense',char_to_label('defense','TS'));
select lpad(nvl(g, ' '), 20) || ' ' || s || ' ' || p || ' ' || o
from table(sem_match('{ graph ?g { ?s ?p ?o }}',
sem_models('project'),
null,
null,
null,
null,
'MIN_LABEL=SE POLICY_NAME=DEFENSE GRAPH_MATCH_UNNAMED=T'
            ))
order by g, s, p, o;

この問合せレスポンスでは、ユーザーAによって行われた表明が除外されます。

urn:proj2 urn:proj2 urn:dependsOn urn:proj1
urn:proj2 urn:proj2 urn:hasBudget 20000
urn:B urn:expenseReportAmount 200
urn:C urn:expenseReportAmount 400
urn:proj1 urn:deadline 2012-12-25
urn:proj1 urn:hasBudget 10000
 
6 rows selected.

同じ問合せをユーザーAとして実行できます。ただし、予測どおり、一致は戻されません。

OLSがRDFに対して有効な場合は、セマンティク・データを削除できます。次の例では、SEM_RDFSA.APPLY_OLS_POLICYが正常に実行されること、および前の例と同じユーザー設定およびラベル設計が使用されることを前提とします。

-- First, create a test model as user A and grant access to users B and C
connect a/<password-for-a>
 
create table test_tpl (triple sdo_rdf_triple_s) compress for oltp;
grant select on mdsys.rdfm_test to B,C;
grant select, insert, update, delete on test_tpl to B, C;
 
-- The following will fail with an error message
-- "Error while creating triggers: If OLS
-- is enabled,  you have to apply table policy
-- before creating an OLS-enabled model"
--
EXECUTE sem_apis.create_sem_model('test', 'test_tpl', 'triple');
 
-- You need to run this API first
 
connect fgac_admin/<password-for-fgac_admin>
 
EXECUTE sem_ols.apply_policy_to_app_tab('defense', 'A', 'TEST_TPL');
 
-- Now model creation (after OLS policy has been applied) can go through
connect a/<password-for-a>
EXECUTE sem_apis.create_sem_model('test', 'test_tpl', 'triple');
 
-- Add a triple as User A
INSERT INTO test_tpl(triple) values
  (sdo_rdf_triple_s('test','<urn:A>','<urn:p>','<urn:B>'));
COMMIT;
 
-- Add the same triple as User B
connect b/<password-for-b>
INSERT INTO a.test_tpl(triple) values
  (sdo_rdf_triple_s('test','<urn:A>','<urn:p>','<urn:B>'));
COMMIT;
 
-- Now User B can see both triples in the application table as well as the model view
set numwidth 20
SELECT * from a.test_tpl;
 
SDO_RDF_TRIPLE_S(8596269297967065604, 19, 1471072612573670395, 28121856352072361
78, 8596269297967065604)
                1000
 
SDO_RDF_TRIPLE_S(8596269297967065604, 19, 1471072612573670395, 28121856352072361
78, 8596269297967065604)
                1500
 
SELECT count(1) from mdsys.rdfm_test;
                   2
 
-- User A can only see one triple due to A's label assignment, as expected.
 
SELECT * from a.test_tpl;
 
SDO_RDF_TRIPLE_S(8596269297967065604, 19, 1471072612573670395, 28121856352072361
78, 8596269297967065604)
                1000
 
SELECT count(1) from mdsys.rdfm_test;
                   1
 
 
-- User A issues a delete to remove A's assertions
SQL> delete from a.test_tpl;
1 row deleted.
 
COMMIT;
Commit complete.
 
 
-- Now user A has no assertions left.
 
SELECT * from a.test_tpl;
no rows selected
 
SELECT count(1) from mdsys.rdfm_test;
                   0
 
-- Note that the preceding delete does not affect the same assertion made by B.
connect b/<password-for-b>
SELECT * from a.test_tpl;
 
SDO_RDF_TRIPLE_S(8596269297967065604, 19, 1471072612573670395, 28121856352072361
78, 8596269297967065604)
                1500
 
SELECT count(1) from mdsys.rdfm_test;
                   1
 
-- User B can remove this assertion using a DELETE statement.
-- The following DELETE statement uses the oracle_orardf_res2vid function
-- to narrow down the scope to triples with a particular subject.
DELETE FROM a.test_tpl app_tab
       where app_tab.triple.rdf_s_id =
             sdo_sem_inference.oracle_orardf_res2vid('<urn:A>');
 
1 row deleted.

親トピック: トリプルレベル・セキュリティ

5.2 リソースレベル・セキュリティ

リソースレベル・セキュリティ・オプションによって、表の行にセキュリティ・レベルを定義する1つ以上のセキュリティ・ラベルを割り当てることができます。

注意:

通常、リソースレベル・セキュリティではなくトリプルレベル・セキュリティを使用することをお薦めします。トリプルレベル・セキュリティについては、「トリプルレベル・セキュリティ」を参照してください。

概念上、リレーショナル・データ・モデルの表は、同等のRDFグラフにマップできます。具体的には、リレーショナル表の行を、それぞれが特定の主語に関するファクトを表明するトリプルのセットにマップできます。このシナリオでは、主語は行の主キーを表し、行のキー以外の列と値の各組合せは、対応するトリプルの述語と目的語の値の組合せにマップされます。

リレーショナル・データ・モデルの行は、そのキーによって識別され、OLSは、行レベルのアクセス制御メカニズムとして、キーに関連付けられた値に対するアクセスを効果的に制限します。リレーショナル・データ・モデルとRDFデータ・モデル間のこの概念的なマッピングでは、リレーショナル表の行に対するアクセスを制限することは、特定の主語を含むサブグラフに対するアクセスを制限することと同等です。各トリプルの機密性ラベルをサポートするモデルでは、特定の主語を含むすべてのトリプルに同じラベルを適用することでこれが実施されます。ただし、個々のトリプルが異なるラベルを保持できるようにすることで、すべてのラベルの最小境界を維持しながら、柔軟性を大幅に向上することもできます。

RDFデータに対するOLSサポートではマルチレベル方式が採用されており、トリプル・コンポーネント(主語、述語、目的語)に関連付けられる機密性ラベルが、トリプルの機密性ラベルの最小境界を集合的に形成しています。この方法では、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リポジトリに適用する場合は、データベース・インスタンス内で保護する特定のリソース位置を選択できます。以降の別の項で説明するように、主語、目的語、述語またはその任意の組合せを保護できます。次の例では、RDFリポジトリにdefenseという名前のOLSポリシーを適用して、機密性ラベルとRDFの主語および述語の関連付けを許可します。

begin
  sem_rdfsa.apply_ols_policy(
        policy_name   => 'defense',
        rdfsa_options => sem_rdfsa.SECURE_SUBJECT+
                         sem_rdfsa.SECURE_PREDICATE); 
end;
/

同じRDFリソースは、主語と目的語の両方の位置(および場合によっては述語の位置)に出現することが可能で、このようなリソースは、その位置に基づいて異なる機密性ラベルを持つことができます。特定の位置にあるリソースを使用するトリプルは、そのリソースの位置に対応するラベルを網羅するラベルを持つ必要があります。この場合、トリプルを表明するかトリプルにアクセスできるのは、そのトリプルおよびリソース・ラベルを網羅するラベルを持つユーザーのみです。

特定のRDFリポジトリでは、主語、述語、目的語またはこれらの組合せに対して、データ分類技術に基づいたセキュリティを有効化できます。これによって、リポジトリに追加されたすべてのトリプルは、必ず前述のラベル関係に自動的に準拠します。

親トピック: RDFデータのファイングレイン・アクセス制御

5.2.1 RDFの主語の保護

RDFリソース(通常はURI)は、表明がリソースに関して行われる場合、トリプルの主語の位置に出現します。この場合、リソースに関連付けられた機密性ラベルには、次の特性があります。

ラベルは、リソースを主語として使用するトリプルの最小限の機密性ラベルを表します。つまり、トリプルの機密性ラベルは、主語のラベルに優先するか、それを網羅する必要があります。
新しく追加されたトリプルのラベルは、ユーザーの初期行ラベルに初期化されるか、ラベル関数を使用して生成されます(ラベルを指定した場合)。この操作は、トリプルのラベルが、トリプルの主語に関連付けられたラベルより優先される場合にのみ成功します。
トリプルを読み取ることができるのは、主語のラベルとトリプルのラベルに優先するアクセス・ラベルを持つユーザーのみです。

デフォルトでは、主語の機密性ラベルは、最初にRDFリソースがトリプルの主語の位置で使用されるときにユーザー環境から導出されます。この場合、デフォルトの機密性ラベルは、ユーザーの初期行ラベルに設定されます(ユーザーによって挿入されるすべての行に割り当てられるデフォルト)。

ただし、トリプルで使用される前でも、RDFリソースを主語として分類し、それに機密性ラベルを割り当てることができます。次の例は、projectHLSリソースにSECRET:HLS:USという名前の機密性ラベルを割り当てることによって、このリソースについて新しいトリプルを定義できるユーザー、およびこのリソースを主語として持つ既存のトリプルにアクセスできるユーザーを制限します。

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;

親トピック: リソースレベル・セキュリティ

5.2.2 RDFの述語の保護

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を持つ必要があります。事実上、トリプルの定義またはトリプルへのアクセスを実行できるように、ユーザーのラベルはこのトリプルのラベルよりも優位である必要があります。

親トピック: リソースレベル・セキュリティ

5.2.3 RDFの目的語の保護

RDFトリプルは、その目的語の位置にURIまたはリテラルを持つことができます。トリプルの目的語の位置にあるURIは、リソースを表します。目的語の位置にあるリソースは、それに機密性ラベルを関連付けることで、トリプルの目的語としてリソースを使用する機能を制限するように保護できます。

通常、トリプルの目的語の位置に出現するリソース(URIまたは非リテラル)は、それ自体、追加のRDF文を使用して記述できます。実際、目的語の位置にあるRDFリソースは、他のトリプルの主語の位置に出現することがあります。RDFリソースが明示的な機密性ラベルを使用せずに目的語の位置で保護される場合、主語の位置にある同じリソースに関連付けられたラベルは、目的語のデフォルト・ラベルとして使用されます。

親トピック: リソースレベル・セキュリティ

5.2.4 推論されたトリプルに対するラベルの生成

RDFデータ・モデルでは、宣言ルールの指定が可能で、明示的にリポジトリに追加されていないRDF文の存在を推論できます。次に、単純な宣言ルールを示します(これらのルールは、プロジェクトは部門によって所有可能で、部門には部長が存在し、その場合プロジェクト・リーダーはデフォルトでプロジェクトを所有する部門の部長になるというロジックに関連付けられています)。

RuleID -> projectLedBy
Antecedent Expression -> (?proj :ownedBy ?dept) (?dept :hasVP ?person)
Consequent Expression -> (?proj :isLedBy ?person)

RDFルールは、明示的に表明されたトリプルと、前に推論されたトリプルを前件として使用し、1つ以上の結果トリプルを推論します。通常、推論プロセスは、オフライン操作として実行され、すべての推論されたトリプルが事前生成されて、後続の問合せ操作で使用できるようになります。

基礎となるRDFグラフがOLSを使用して保護される場合、権限のないユーザーにデータを公開することを避けるため、グラフから推論された追加データも保護する必要があります。また、推論プロセスは、完全性を保証するため、より高い権限(特にデータに対する完全なアクセス権限)で実行する必要があります。

RDFデータに対するOLSサポートでは、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つ以上の前件トリプルを持つことができます。前件ラベルの使用の技術では、すべての前件トリプルのラベルが考慮され、新しいトリプルに最も適したラベルを決定するために、競合解決基準が実装されます。推論されたトリプルは、他の推論されたトリプルに依存することがあるため、すべての推論されたトリプルのラベルの生成中は厳密な順序に従います。

前件ラベルの使用の技術では、カスタム・ラベル・ジェネレータを使用する必要があります。カスタム・ラベル・ジェネレータの作成および使用の詳細は、「アプリケーション・ロジックに基づくラベルの使用」を参照してください。

次の例では、特定のルールベースを使用して契約データの伴意(ルール索引)を作成します。この操作は、RDFリポジトリに適用されるOLSポリシーに関して完全なアクセス権限を持つユーザーのみが実行できます。この場合は、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;

生成されたラベルを通じてアクセスされる推論されたトリプルは、ユーザー・アクセス可能なトリプルおよびルールから直接推論される概念上のトリプルとは異なることがあります。システム定義の実装またはカスタム実装を使用して生成されるラベルの正確性は、保証されません。ファイングレイン・アクセス制御(OLS)に関する考慮事項の詳細は、SEM_APISパッケージ・サブプログラムにあるSEM_APIS.CREATE_ENTAILMENTプロシージャの使用方法に関する項を参照してください。

親トピック: リソースレベル・セキュリティ

5.2.5 アプリケーション・ロジックに基づくラベルの使用

MDSYS.RDFSA_LABELGENタイプは索引作成時に適切なラベル・ジェネレータ・ロジックを適用するために使用しますが、このタイプを拡張して、カスタム・ラベル・ジェネレータを実装してアプリケーション・ロジックに基づいたラベルを生成することもできます。ラベル・ジェネレータは、SEM_APIS.CREATE_ENTAILMENTプロシージャのlabel_genパラメータで指定します。システム定義のラベル・ジェネレータを使用するには、「推論されたトリプルのラベルの生成」で説明したようにSEM_RDFSAパッケージ定数を指定します。カスタム・ラベル・ジェネレータを使用するには、カスタム・ラベル・ジェネレータ・タイプを実装して、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);

例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;  
  /

ラベル・ジェネレータ・コンストラクタは、SEM_RDFSAパッケージに定義されている定数のセットを使用して、ラベル・ジェネレータが依存しているリソースのリストを示します。依存リソースは、推論されたトリプルの主語、述語、目的語、トリプルを生成したルール、およびその前件として識別されます。カスタム・ラベル・ジェネレータは、ラベルを生成するためにこれらのリソースの任意のサブセットに依存することが可能で、SEM_RDFSAパッケージに定義されている定数(USE_SUBJECT_LABEL、USE_PREDICATE_LABEL、USE_OBJECT_LABEL、USE_RULE_LABEL、USE_ANTCED_LABEL)を使用してそのコンストラクタにこれを指定できます。次の例では、タイプ本体を作成し、コンストラクタを指定しています。

例5-1では、タイプ本体を作成し、コンストラクタ関数およびgetNumericLabelメンバー関数を指定しています。(アプリケーション固有のロジックはこの例に含まれていません。)

例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;
/

親トピック: リソースレベル・セキュリティ

5.2.6 RDFOLS_SECURE_RESOURCEビュー

MDSYS.RDFOLS_SECURE_RESOURCEビューには、Oracle Label Security (OLS)ポリシーで保護されたリソースと、それらのリソースに関連付けられた機密性ラベルに関する情報が含まれます。

このビューに対するSELECT権限を適切なユーザーに付与できます。特定のモデルに関連付けられたリソースを表示するには、そのモデル(または対応するRDFM_model-nameビュー)に対するSELECT権限も持っている必要があります。

表5-1に、MDSYS.RDFOLS_SECURE_RESOURCEビューの列を示します。

表5-1 MDSYS.RDFOLS_SECURE_RESOURCEビューの列

列名	データ型	説明
MODEL_NAME	VARCHAR2(25)	モデルの名前。
MODEL_ID	NUMBER	モデルの内部識別子。
RESOURCE_ID	NUMBER	リソースの内部識別子(リソースに関する情報用としてMDSYS.RDF_VALUE$.VALUE_ID列に結合)。
RESOURCE_TYPE	VARCHAR2(16)	ラベルが割り当てられるリソース・タイプを示す文字列値(`SUBJECT`、`PREDICATE`、`OBJECT`、`GLOBAL`)のいずれか。
CTXT1	NUMBER	リソースに割り当てられる機密性ラベル。

親トピック: リソースレベル・セキュリティ