| Oracle XML DB開発者ガイド 11gリリース1（11.1） E05669-02 |
|
 戻る |
 次へ |
Oracle Databaseでは、データベース・ユーザーが行レベルおよび列レベルでセキュアにアクセスできるなど、従来型のデータベース・セキュリティが提供されています。また、Oracle Fusionユーザー（必ずしもデータベース・ユーザーではない）がセキュアにアクセスできるように、Oracle XML DBリポジトリ内の表データやリソースに対するファイングレイン・アクセス制御も提供されています。この章では、このようなファイングレイン・アクセス制御を可能にするアクセス制御リストおよびセキュリティ・クラスについて説明します。ACLの作成、設定、変更方法、およびACLセキュリティと他のOracle Databaseセキュリティ・メカニズムとの相互作用の方法も説明します。
この章の内容は次のとおりです。
|
関連項目:
|
この項では、アクセス制御の用語および概念について説明します。ここで説明するエンティティ（ユーザー、ロール、プリンシパル、権限、セキュリティ・クラス、アクセス制御リスト（ACL）およびアクセス制御エントリ（ACE））はそれぞれ、XML文書またはフラグメントとして宣言的に実装されます。
セキュアな認可を行うためには、どのユーザー、アプリケーションまたは関数が、どのような種類の操作を実行するために、どのデータにアクセスできるかを定義することが必要です。つまり、（1）どのユーザーが（2）どの操作を（3）どのデータに対して実行できるか、という3つの局面があります。この3つの局面をそれぞれ、（1）プリンシパル、（2）権限、（3）オブジェクトと呼びます。プリンシパルは、ユーザーまたはロールです。
プリンシパルと権限（局面1と2）は、アクセス制御リストを定義することにより、宣言的に関連付けられます。その後、これらは3番目の局面であるデータに、様々な方法で宣言的または手続き的に関連付けられます。たとえば、Oracle XML DBリポジトリのリソースまたは表データを保護するには、PL/SQLプロシージャDBMS_XDB.setACLを使用して、それを制御するACLを設定します。
ファイングレイン・データベース・アクセス制御との関連において、プリンシパルはユーザーまたはロールです。ユーザーは、データベース内の情報にアクセスする個人またはアプリケーションです。ロールは、ユーザーまたは他のロールで構成されますが、この再帰は循環型にできません。最終的には、各ロール（つまり各プリンシパル）はユーザーのセットに対応します。
ユーザーは、アクセス制御の目的で要素userを持つXMLフラグメントで表されます。ロールは、要素roleを持つフラグメントで表されます。
Oracle Databaseでは、プリンシパルとして次のものをサポートしています。
データベース・ユーザーおよびデータベース・ロール。データベース・ユーザーは、データベース・スキーマまたはユーザー・アカウントと呼ばれることもあります。個人またはアプリケーションはデータベースにログオンするとき、データベース・ユーザー（スキーマ）およびパスワードを使用します。データベース・ロールは、データベース・ユーザー、アプリケーションまたは他のデータベース・ロールに付与できるデータベース権限のセットに対応しています（「データベース・ロールによるデータベース権限のユーザーへのマップ」を参照）。
Oracle FusionユーザーおよびOracle Fusionロール。軽量ユーザーおよび軽量ロールと呼ばれることもあります。これらはアプリケーションにより定義されます。データベース・ユーザーやデータベース・ロールに関連付ける必要はありません。
Oracle Fusionユーザーがデータベース情報のユーザーになることもありますが、Oracle Fusionユーザーとデータベース・ユーザー（スキーマ）とは区別されています。Oracle Fusionロールは、Oracle Fusionユーザーのセットに対応しています。
LDAPユーザーおよびLDAPユーザー・グループ。LDAPプリンシパルの使用方法の詳細は、「Oracle XML DBのLDAPとの統合」を参照してください。
この章で「ユーザー」または「ロール」のように何も付かない語が使用されている場合、その語はすべてのタイプのユーザーまたはロールに適用されます。タイプを区別することが重要な場合は、「データベース」または「Oracle Fusion」という語が付いています。
データベース・ロールは従来的にはデータベース・ユーザーのセットではなくデータベース権限の名前付きセットとして考えられるため、ここで示すロールの概念はOracle Fusionロールの場合と完全に同じではありません。
実際、データベース・ユーザーに権限を付与できるのと同様、データベース・ロールにも権限が付与されます。データベース・ロール・サーバーは、データベース権限をデータベース・ユーザー（およびアプリケーション）にマップするための媒介となります。つまり、ロールに権限が付与されてから、そのロールがユーザーに付与されます（それによりユーザーに権限が付与されます）。ユーザーのグループと、それらのユーザーに付与された権限のグループとの違いは、データベース・ロールの概念においては少しあいまいです。データベース・ロールによって、ユーザーにマップされた権限をグループ化したり、権限がマップされたユーザーをグループ化したりすることもできるためです。マッピングは、ロールを定義してユーザーに付与することにより行われます。従来の用語では、ロールを、それに割り当てられた権限のセットと同じものとして考えます。
ファイングレイン・アクセス制御の関連においては、別のメカニズムであるアクセス制御リスト（ACL）が、権限をユーザーにマップする媒介として使用されます。Oracle Fusionロールは単なるユーザーのセットです。また、権限の名前付きセットはセキュリティ・クラスの形式をとります。この場合、権限をユーザーおよびロールに関連付ける操作はデータベース権限ではありません。この操作は、ACLのランタイム評価やACL競合の解消とともに、宣言的なACLエントリです。
混同しないように、この用語の違いに注意してください。権限をユーザーにマップする手段として、Oracle Fusionでは（1）プリンシパル、（2）権限およびセキュリティ・クラス、（3）ACLとして分類されている機能のいくつかは、データベース・ロールではまとめられています。アクセス制御の用語においては、ロールはユーザーとともにプリンシパルとして分類されます。これに対し、従来のデータベース用語においては、ロールは権限のセットとして分類されます。
ロール・セットは、一連のロールです。一度にアクティブになることのできるロールは、最大1つです。ロール・セット内の1つのロールをアクティブにすると、同じセット内の他のロールは非アクティブになります。ロール・セットは一連のラジオ・ボタンとして考えることができます。つまり、一度に押した状態にできるのは1つのボタンのみです。（ただし、ロール・セット内のいずれかのロールをアクティブにする必要はありません。すべてのロールを同時に非アクティブにすることもできます。）Oracle Databaseではこの動作が自動的に適用されるため、アプリケーションのロジックを簡略化できます。
1つのロールは任意の数のロール・セットに属することができます。また、1つのロール・セットには任意の数のロールを含めることができます。常に、すべてのロール・セットが適用されます。つまり、複数のロール・セットに属する1つのロールがアクティブになると、同じロール・セット内の他のロールはすべて非アクティブになります。たとえば、ロール・セットAにロールr1、r2およびr3が含まれ、ロール・セットBにロールr2、r4およびr5が含まれる場合、ロールr2がアクティブになるたびに、r1、r3、r4およびr5が非アクティブになります。
権限とは、プリンシパルに対して付与または拒否される特定の権限です。Oracle Databaseには、システム定義の権限のセット（READやUPDATEなど）が存在します。アプリケーションで追加のカスタム権限を定義できます。
権限は、次のいずれかになります。
集約権限は、権限の数が多くなった場合の操作性を簡略化し、ACLクライアント間の相互運用性を高めます。事前定義の基本システム権限および集約システム権限の詳細は、「システム・セキュリティ・クラス」を参照してください。
集約権限はそのまま保持され、対応する基本（リーフ）権限に分割されません。WebDAVの用語において、Oracle Databaseの集約権限は抽象的でありません。つまり、集約権限は、それらのコンポーネントのコピーではなく、そのコンポーネント権限へのポインタのセットとして機能します。したがって、コンポーネントの定義が変更された場合でも、集約権限は常に最新の状態を保持します。
プリンシパルに付与された権限のセットによって、プリンシパルが保護するデータに対して特定の操作を実行できるかどうかが制御されます。たとえば、プリンシパル（データベース・ユーザー）HRが特定のリソースに対してread操作を実行するには、読取り操作の前にHRに読取り権限が付与されている必要があります。
セキュリティ・クラスとは、名前付きの権限セットのことです。セキュリティ・クラスには、他のセキュリティ・クラスから継承した権限が含まれます。また、それ自身が定義する権限が含まれることもあります。ユーザーが作成したセキュリティ・クラス内に定義された権限を、カスタム権限といいます。Oracle Databaseにより事前定義されている権限を、システム権限といいます。
この章で説明するファイングレイン・アクセス制御を使用すると、ほとんどすべてのデータベース・データを保護できます。この章では、Oracle XML DBリポジトリのリソースの保護について説明します。
アクセス制御エントリ（ACE）とは、アクセス制御リスト（ACL）内のエントリであるXML要素（ace）のことです。ACEは、特定のプリンシパル（ユーザーまたはロール）によるリポジトリ・リソースまたはその他のデータベース・データへのアクセスを許可または拒否します。ACE自身は、保護対象のデータを指定しません。この指定はACEおよびACLの外側で、ACLをターゲット・データに関連付けることによって行われます。その関連付けを行う方法として、PL/SQLプロシージャDBMS_XDB.setACLを使用する方法があります。
「ACLおよびACEの評価」を参照してください。
Oracle XML DB ACEは、プリンシパルの権限を付与または拒否します。ace要素は、次を含みます。
操作: grantまたはdenyのいずれか。
プリンシパル: 有効なプリンシパル（要素principal）。
権限: 特定のプリンシパルに対して付与または拒否される権限のセット（要素privilege）。
Principal format (optional): The format of the principal.LDAPの識別名（DN）、短縮名（データベース・ユーザー/ロールまたはLDAPのニックネーム）またはLDAP GUID。デフォルト値はshort nameです。プリンシパル名がデータベース・ユーザーとLDAPニックネームの両方に一致している場合は、LDAPのニックネームを示すとみなされます。
コレクション（オプション）: プリンシパルがユーザーのコレクション（LDAPグループまたはデータベース・ロール）であるか、単一のユーザー（LDAPまたはデータベース・ユーザー）であるかどうかを指定するBOOLEAN属性。
例27-1に、プリンシパルDAV::ownerに権限DAV::allを付与する単純なACEを示します。つまり、ACLが適用されるリソースの所有者にすべての権限を付与します。
アクセス制御リスト（ACL）とは、アクセス制御エントリ（ACE）のリストです。デフォルトでは、リスト内の順序に意味があります（「ACLおよびACEの評価」を参照）。例27-2に、例27-1のACEのみを含む単純なACLを示します。
例27-2 システム権限を付与する単純なアクセス制御リスト（ACL）
<acl description="myacl"
xmlns="http://xmlns.oracle.com/xdb/acl.xsd"
xmlns:dav="DAV:"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/xdb/acl.xsd
http://xmlns.oracle.com/xdb/acl.xsd">
<ace>
<grant>true</grant>
<principal>dav:owner</principal>
<privilege>
<dav:all/>
</privilege>
</ace>
</acl>
表27-1に、Oracle XML DBリポジトリのリソースに対するいくつかの一般的な操作に必要なデータベース権限を示します。必要な権限列に示された権限の他に、そのリソースが属するフォルダおよびその親フォルダすべて（ルート・フォルダまで）に対するresolve権限が必要です。
表27-1 Oracle XML DBリソースの操作に必要なデータベース権限
| 操作 | 説明 | 必要な権限 |
|---|---|---|
|
|
フォルダFに新しいリソースを作成します。 |
フォルダFに対する |
|
|
フォルダFからリソースRを削除します。 |
Rに対する |
|
|
リソースRのコンテンツまたはプロパティを更新します。 |
Rに対する |
|
|
FTPまたはHTTP(S)によるリソースRの取出し。 |
Rに対する |
|
|
リソースRのACLを設定します。 |
Rに対する |
|
|
フォルダFのリソースをリストします。 |
フォルダFに対する |
セキュリティ・クラスは、カスタム権限（システム権限でない権限）のセットを定義します。再利用性を高めるため、セキュリティ・クラスは1つ以上の他のセキュリティ・クラスから権限を継承できます。継承循環は許可されないため、セキュリティ・クラスがそれ自身から直接的または間接的に権限を継承することはできません。
例27-3に、iStorePurchaseOrderという名前の単純なセキュリティ・クラスを定義するXML文書を示します。
例27-3 単純なセキュリティ・クラス
<securityClass xmlns="http://xmlns.oracle.com/xdb/security.xsd"
xmlns:is="xmlns.oracle.com/iStore"
xmlns:oa="xmlns.oracle.com/OracleApps"
targetNamespace="xmlns.oracle.com/iStore">
name="iStorePurchaseOrder">
<title xml:lang="ja" xdb:srclang="true">
Security Class Example
</title>
<inherits-from>oa:PurchaseOrder</inherits-from>
<privilege name="privilege1"/>
<aggregatePrivilege name="iStorePOApprover">
<title xml:lang="ja">
iStore Purchase Order Approver
</title>
<privilegeRef name="is:privilege1"/>
<privilegeRef name="oa:submitPO"/>
<privilegeRef name="oa:privilege3"/>
</aggregatePrivilege>
<privilege name="privilege2">
<title xml:lang="ja" xdb:srclang="true">
Secondary Privilege
</title>
<title xml:lang="fr">
Deuxieme Privilège
</title>
</privilege>
</securityClass>
セキュリティ・クラスiStorePurchaseOrderによって定義されている権限は、iStorePOApprover、privilege1およびprivilege2です。このセキュリティ・クラスによって使用可能になるのは、これらの権限のみです。これらの権限はすべて、接頭辞isが付いたiStorePurchaseOrderのターゲットXML名前空間にあります。
セキュリティ・クラスiStorePurchaseOrderは、セキュリティ・クラスoa:PurchaseOrderから継承します。つまり、oa:PurchaseOrderからの権限が含まれる可能性があります。
権限privilege1およびprivilege2は、基本権限です（要素privilegeで定義されています）。権限iStorePOApproverは集約権限です（要素aggregatePrivilegeで定義されています）。iStorePOApproverを構成する権限は、is:privilege1、oa:submitPOおよびoa:privilege3です。
権限oa:submitPOおよびoa:privilege3は、セキュリティ・クラスoa:PurchaseOrderから継承されたため、接頭辞oaを使用する名前空間にあります。権限privilege1は、ターゲット名前空間isにあります。
セキュリティ・クラス定義内のtitle要素は、セキュリティ・クラス（Security Class Example）の画面名と、それに含まれる2つの権限（権限iStorePOApproverに対応するiStore Purchase Order Approverおよび権限privilege2に対応するSecondary Privilege）を定義しています。権限privilege1には、タイトルは定義されていません。権限privilege2には実際に、異なる2つの言語に対応する2種類のタイトルがあります。Secondary Privilegeはデフォルト言語である英語（xml:lang="en"）のタイトルであり、Deuxieme Privilegeはフランス語（xml:lang="fr"）のタイトルです。
アクセス制御リスト（ACL）のタイプは、単一のセキュリティ・クラスです。ACLはプリンシパルに権限を付与して、保護対象のデータまたは機能へのアクセスを制御します。このため、ACLはそのセキュリティ・クラス内に定義されている権限のみを付与できます。ACLは、要素security-classを使用してそのセキュリティ・クラスを宣言します（例27-6を参照）。この要素がACLに存在しない場合、ACLのタイプはデフォルトのセキュリティ・クラスであるDAV::davとなり、システム権限が定義されます。異なるACLが、同じセキュリティ・クラスをタイプとして持つことができます。
この項では、Oracle Databaseで提供されている事前定義のセキュリティ・クラス（システム・セキュリティ・クラス）について説明します。これらのセキュリティ・クラスにより定義される権限は、システム権限です。権限名は、XML要素名として使用されます。
セキュリティ・クラスdav自身は、XML名前空間DAV:にあります。脚注1 これには、2つの名前空間にある権限が含まれます。
WebDAV名前空間であるDAV:
Oracle XML DB ACL名前空間であるhttp://xmlns.oracle.com/xdb/acl.xsd（事前定義された接頭辞xdbが付く）
セキュリティ・クラスDAV::davには、WebDAV標準により定義されているすべての権限が含まれています。
|
関連項目: RFC 3744: 2004年5月の「Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol」の「IETF Network Working Group Request For Comments #3744」を参照してください。 |
表27-2に、セキュリティ・クラスDAV::davにより使用可能になる基本権限を示します。
表27-2 セキュリティ・クラスDAV::davの基本権限
| 基本権限 | 説明 | データベースでの操作 |
|---|---|---|
|
|
WebDAVロックを使用してリソースをロックします。 |
|
|
|
リソースの |
なし |
|
|
リソースの所有権を取得します。 |
なし |
|
|
WebDAVロックを使用してロックされたリソースのロックを解除します。 |
|
|
|
リソースのコンテンツを変更します。 |
|
|
|
リソースのプロパティを変更します。リソースをロックまたはロック解除します。変更可能なプロパティには、 |
|
|
|
リソースからのリンクの作成を可能にします。 |
|
|
|
リソースへのリンクの作成を可能にします。 |
なし |
|
|
リソースのACLを読み取ります。 |
|
|
|
リソースのコンテンツを読み取ります。 |
|
|
|
リソースのプロパティを読み取ります。 |
|
|
|
フォルダを検索します（フォルダの場合のみ）。 |
|
|
|
リソースからのリンクの削除を可能にします。 |
|
|
|
リソースへのリンクの削除を可能にします。 |
なし |
|
|
リソースのACLのコンテンツを変更します。 |
|
|
|
リソースのACLOIDを変更します。 |
|
表27-3に、セキュリティ・クラスDAV::davにより使用可能になる集約権限、およびそれらを構成する基本権限を示します。
表27-3 セキュリティ・クラスDAV::davにより定義される集約権限
| 集約権限 | コンポーネントの基本システム権限 |
|---|---|
|
|
セキュリティ・クラスにより定義されるすべての基本権限（ |
|
|
セキュリティ・クラス |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
セキュリティ・クラスPrincipalSecurityClassは、拡張可能セキュリティの名前空間http://xmlns.oracle.com/xs内に権限を定義します。これはセキュリティ・クラスDAV::davから継承します。
表27-4に、セキュリティ・クラスPrincipalSecurityClassにより定義される基本権限を示します。
表27-4 セキュリティ・クラスPrincipalSecurityClassにより定義される基本権限
| 基本権限 | 説明 |
|---|---|
|
|
ユーザー文書内の |
|
|
ロール文書内の |
|
|
現在のロールをロール・セットに追加します。 |
|
|
Oracle Fusionセッションを作成します。 |
|
|
Oracle Fusionセッションを終了します。 |
|
|
Oracle Fusionセッションに連結します。 |
|
|
Oracle Fusionセッションの内容を変更します。 |
|
|
Oracle Fusionセッションのユーザーを切り替えます。 |
|
|
ユーザーを匿名のOracle Fusionセッションに割り当てます。 |
|
|
Oracle Fusionユーザーのパスワードを変更します。 |
|
|
名前空間のプロパティを作成、削除または変更します。 |
|
|
Oracle Fusionセッション属性を設定します。 |
|
|
Oracle Fusionセッション属性の値を読み取ります。 |
表27-5に、セキュリティ・クラスPrincipalSecurityClassにより定義される集約権限、およびそれらを構成する基本権限を示します。名前空間接頭辞のない権限は、拡張可能セキュリティの名前空間http://xmlns.oracle.com/xsにあります。
表27-5 セキュリティ・クラスPrincipalSecurityClassにより定義される集約権限
| 集約権限 | コンポーネントの基本システム権限 |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
アクセス制御リスト（ACL）は、Javaなどの言語やMicrosoft Windowsなどのオペレーティング・システムで使用される、標準のセキュリティ・メカニズムです。ACLは、WebDAV標準の一部でもあります。ACLは、リソースを保護するために使用されます。Oracle Databaseの場合、リソースはOracle XML DBリポジトリ内のリソース（ファイルおよびフォルダ）か、データベース表のデータのいずれかです。
リポジトリのリソースには、WebDAVを使用してアクセスできます。リソースを保護するACLは、WebDAV ACLとして機能します。各リポジトリ・リソースは、ACLによって保護されます。リソースを保護するACLは、リソースのアクセス方法（WebDAV、SQL、またはその他の方法）にかかわらず適用されます。
Oracle XML DBリポジトリに新しいリソースが作成されると、デフォルトでは、親フォルダのACLを使用してリソースが保護されます。リソースの作成後に、新しいACLを設定できます。
Oracle Database内のACLは、/sys/schemas/PUBLIC/xmlns.oracle.com/xdb/acl.xsdのOracle XML DBリポジトリにあるOracle Database ACL XMLスキーマに基づいて検証されるXML文書です。ACL自体はリポジトリ内にリソースとして格納され、管理されます。
ACLで保護されたデータに対してプリンシパルが操作を実行する前に、保護されたデータに対するユーザー権限が確認されます。確認される権限は、実行される操作によって異なります。
集約権限は、他の権限で構成されます。ACLが保存されると、そのACLが参照する集約権限は、それらのコンポーネント権限へのポインタのセットとなります。このため、カスタムの集約権限が追加の子権限を含むように後で更新された場合に、その権限を参照するACLに変更を加える必要はありません。ACLは、その参照先との関連においては常に最新の状態に保持されます。
すべてのACLは、データベース・ユーザーXDBが所有するXDB$ACLという表に格納されます。この表は、XML Schemaに基づくXMLType表です。したがって、この表のすべての行（つまり各ACL）に、OBJECT_IDという名前の列としてアクセスできるシステム生成のオブジェクトID（OID）があります。
Oracle XML DBリポジトリのすべてのリソースには、ACLOIDという名前のプロパティがあります。ACLOIDには、リソースを保護するACLのOIDが格納されます。ACL自身はリソースであり、ACL（たとえば/sys/acls/all_all_acl.xml）のXMLRefプロパティは、ACLの内容を含む表XDB$ACL内の行に対するREFです。これらの2つのプロパティが、Oracle XML DBリソースを格納する表XDB$RESOURCEと表XDB$ACLをリンクしています。
|
関連項目:
|
一部のACLは事前定義されており、Oracle Databaseで提供されています。これらのACLはシステムACLと呼ばれます。
自己保護型のACL（それ自体の内容によって保護されるACL）は1つしかありません。これはブートストラップACLと呼ばれるシステムACLであり、Oracle XML DBリポジトリの/sys/acls/bootstrap_acl.xmlにあります。ブートストラップACLは、すべてのユーザーにREAD権限を付与します。また、ブートストラップACLは、データベース・ロールXDBADMIN（Oracle XML DB ADMIN）およびDBAにFULL ACCESS権を付与します。データベース・ロールXDBADMINは特に、グローバルXML Schemaの登録を必要とするユーザーに役立ちます。
この他に、次のようなACLがあります。いずれもブートストラップACLにより保護されています。
all_all_acl.xml: すべての権限をすべてのユーザーに付与します。
all_owner_acl.xml: すべての権限をリソースの所有者に付与します。
ro_all_acl.xml: read権限をすべてのユーザーに付与します。
システムACLは、ファイル・ネーミング規則<privilege>_<users>_acl.xmlを使用します。ここで<privilege>は付与される権限を示し、<users>はリソースへのアクセスを許可されるユーザーを示します。独自のACLを定義する場合は、任意の名前を使用できます。
プリンシパルが、1つ以上のACLによって保護されたリポジトリ・リソースなどのデータベース・オブジェクトへのアクセスを許可される前に、権限が確認されます。この確認は、そのプリンシパルのACLの保護を順に評価することによって行われます。このようなACLごとに、プリンシパルに適用されるACEが順に検査されます。
1つのACEが現行ユーザーになんらかの権限を付与し、他のACEがユーザーに対してその権限を拒否すると、競合が発生します。同一のプリンシパルに対するACE間の競合を管理する方法は2つあります。
ace-orderと呼ばれるデフォルトの動作では、指定されたプリンシパルに対して発生する最初のACEのみが使用されます。そのプリンシパルに対する追加のACEは無効です。この場合、ACEの順序に意味があります。
ただし、deny-trumps-grantという代替の動作を使用するようにデータベースを構成できます。この場合、特定のプリンシパルに対して子denyを持つACEはいずれも、そのプリンシパルに対してgrantの子を持つ他のACEの有無にかかわらず、そのプリンシパルへの権限を拒否します。この場合、denyは常にgrantよりも優先され、ACEの順序は関係ありません。
構成ファイルxdbconfig.xml内の構成パラメータacl-evaluation-methodをace-orderまたはdeny-trumps-grantのいずれかに設定し、ACL評価の動作を構成できます。デフォルトの構成ファイルではace-methodが指定されますが、メソッドが指定されない場合に使用される要素acl-evaluation-methodはdeny-trumps-grantです。
|
注意: Oracle Database 11gリリース1より前のリリースでは、ACL評価動作は、deny-trumps-grantの1つのみが利用可能でした（ただし、構成ファイル内では指定されません）。
|
ACLは作成されると、ACL用のXML Schemaに基づいて検証され、いくつかの正確性テスト（ACEの開始日と終了日が時間的に矛盾していないことの確認など）が実行されます。ACLの作成時に、ACL間のリレーションまたはACLとセキュリティ・クラスとのリレーションについての完全チェックは行われません。たとえば、作成時に、親ACLとセキュリティ・クラスが存在しているかどうか、およびそれらが正しいかどうかはチェックされません。また、セキュリティ・クラス内に定義されていない権限など、未解決または無効なカスタム権限についてもチェックは行われません。
このようなACLの正確性に関する完全なチェックをACL妥当性チェックといいます。これをXML Schemaの妥当性と混同しないでください。ACLが（ACLとして）有効になるためには、同時にXML Schemaでも有効である必要がありますが、その逆は言えません。
プリンシパルに操作を行うための適切な権限があるかどうかをチェックするためにACLが評価されるたびに、完全なACL妥当性チェックが実行時に行われます。このチェックによりACLが無効であると判断された場合、そのACLが指定されたプリンシパルに付与するすべての権限は拒否されます。
PL/SQLプロシージャDBMS_XDBZ.validateACLを起動して、ACLの妥当性を、権限確認のための実行時使用とは無関係に確認することもできます。この確認をあらかじめ行うことで、ACLが無効であるためにランタイム・エラーや権限否認が発生することを回避できます。
ACLは、別のACLからACE（プリンシパルと権限のアソシエーション）を継承できます。継承を使用すると、定義の柔軟性が高まり、アクセス制御ポリシーの再利用性が高まります。
セキュリティ・クラスの継承とは異なり、これは多重継承ではありません。つまり、ACLは最大で1つの他のACLからしか継承しません。継承連鎖において循環は許可されていません。つまり、ACL自身から直接的または間接的に継承したACLは無効です。また、存在しないACLから継承したACLも無効です。
ACL継承には拡張継承と制約継承の2種類があり、それぞれ要素extends-fromまたは要素constrained-withを使用して指定されます。どちらの要素も、継承元のACLを参照します。1つのACLは、最大で1つのextends-fromまたはconstrained-with要素を持つことができます。例27-4にextends-from要素を示し、例27-5にconstrained-with要素を示します。
拡張継承は、継承元のACL（親ACL）により定義されているいくつかの権限によって、継承するACL（子ACL）内で明示的に宣言されている権限を拡張します。たとえば、ACL A1がACL A2から拡張することを宣言している場合、A1にはA2からのACEを含めることができます。
制約継承は、継承するACL内で明示的に宣言されている権限を、継承元のACLによっても定義されている権限に制限します。たとえば、ACL A1が制約継承によりACL A2から継承することを宣言している場合、A1内のすべてのACEがA2でも定義されている必要があります。
拡張継承は設定されたunion操作であり、制約継承は設定されたintersection操作です。ACL A1がACL A2から拡張する場合、A1とA2のACEを結合して、特定のプリンシパルに特定の権限が付与されているかどうかを判別できます。ACL A1がACL A2によって制約される場合、A1とA2の両方に共通のACEのみが権限付与の判別に使用されます。
より正確には、ACL A1がACL A2から継承し、特定のプリンシパルに特定の権限セットが付与されているかどうかを調べるためにA1が確認される場合、判別の処理は次のように実行されます。
A1がA2から拡張する場合: A1で明示的に宣言されているACEが最初に検査されます。ACEで対象となる権限全部がプリンシパルに付与されているわけではない場合、または権限のいずれかが拒否されている場合、A1の親extending-fromで定義されているACEが検査されます。このため、A2で明示的に宣言されているACEで、対象となる権限全部がプリンシパルに付与されているわけではない場合、または権限のいずれかが拒否されている場合、A2がA3から拡張していれば、A3が検査されます。
A1がA2により制約される場合: A1で明示的に宣言されているACEと、A2に定義されているACEがそれぞれ個別に検査され、指定されたプリンシパルに対して対象となる権限全部が付与されていることが確認されます。A2がACL A3により制約される場合も、同じ方法でA2のチェックが行われます。
言い換えると、拡張継承は付与された権限を蓄積し、制約継承は拒否された権限を蓄積します。拡張継承においては、子または親のACLがプリンシパルに権限を付与した場合、その権限が付与されます。制約継承においては、子または親のACLが権限を拒否した場合、その権限は拒否されます。
別のプリンシパル・セットを補完することによりプリンシパル・セットを定義するほうが便利な場合もあります。ACE要素invertは、この目的で使用します。追加するプリンシパルをすべてリストするのではなく、invertを使用して、除外するプリンシパルのリストを囲みます。
例27-6の最初のACEは、IntranetUsers以外のすべてのプリンシパルに対して権限privilege1を拒否しています。（デフォルトで）ACEは出現順に考慮されるため、後続のACEはすべて最初のACEによりオーバーライドされます。このため、プリンシパルNonIntraNetUserは明示的に権限を付与されているにもかかわらず、権限privilege1を拒否されます。
例27-6 要素invertを使用したプリンシパル・セットの補完
<acl description="iStore ACL"
xmlns="http://xmlns.oracle.com/xdb/acl.xsd"
xmlns:is="xmlns.oracle.com/iStore"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/xdb/acl.xsd
http://xmlns.oracle.com/xdb/acl.xsd">
<security-class>is:iStorePurchaseOrder</security-class>
<extends-from type="simple" href="/sys/acls/parent_acl.xml"/>
<ace>
<grant>false</grant>
<invert><principal>IntranetUsers</principal></invert>
<privilege><is:privilege1/></privilege>
</ace>
<ace>
<grant>true</grant>
<principal>NonIntraNetUser</principal>
<privilege><is:privilege1/></privilege>
</ace>
</acl>
（XML SchemaタイプdateTimeの）オプションの属性start_dateおよびend_dateを使用して、ACEの有効期間を定義できます。start_dateが指定されている場合、その日からACEは有効になります。end_dateが指定されている場合、その日からACEは無効になります。end_dateの値は時間的にstart_dateより後の値か、または同じ値である必要があります。そうでない場合、ACEおよびそのACLは無効になります。XML SchemaのdateTime値でタイムゾーンが指定されていない場合、GMT（UTC）が想定されます。例27-7に、開始日と終了日が指定されたACEを示します。
Oracle Databaseのアクセス制御リスト（ACL）はそれ自身がOracle XML DBリポジトリ内のリソースなので、リポジトリのリソースを操作するメソッドはすべてACLにも適用されます。さらに、ACLsinパッケージDBMS_XDBに固有のAPIもいくつかあります。これらのプロシージャやファンクションを使用すると、PL/SQLを使用してOracle XML DBのセキュリティ・メカニズムにアクセスし、特定のACLに基づいてユーザーの権限を確認して、特定のACLやリソースに対して現行ユーザーが所有している権限のセットをリストできます。
例27-8では、ACLをファイル・リソース/TESTUSER/acl1.xmlとして作成します。リソースに適用されると、このACLはすべての権限をリソースの所有者に付与します。
例27-8 DBMS_XDB.createResourceを使用したACLの作成
DECLARE
b BOOLEAN;
BEGIN
b := DBMS_XDB.createFolder('/TESTUSER');
b := DBMS_XDB.createResource(
'/TESTUSER/acl1.xml',
'<acl description="myacl"
xmlns="http://xmlns.oracle.com/xdb/acl.xsd"
xmlns:dav="DAV:"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/xdb/acl.xsd
http://xmlns.oracle.com/xdb/acl.xsd">
<ace>
<grant>true</grant>
<principal>dav:owner</principal>
<privilege>
<dav:all/>
</privilege>
</ace>
</acl>');
END;
|
注意: 現在のトランザクション中に作成されたACLファイル・リソースを使用する操作を実行する前に、COMMIT操作を実行する必要があります。それまでは、ACLファイルを使用するたびにORA-22881エラー「REFの参照先がありません」が発生します。 |
例27-9は、ACL文書のOracle XML DBリポジトリ内の場所がわかっている場合にACL文書を取得する方法を示しています。
例27-9 リポジトリのパスがある場合のACL文書の取得
SELECT a.OBJECT_VALUE FROM RESOURCE_VIEW r, XDB.XDB$ACL a
WHERE ref(a) = extractValue(r.RES, '/Resource/XMLRef')
AND equals_path(r.RES, '/TESTUSER/acl1.xml') = 1;
OBJECT_VALUE
--------------------------------------------------------------------------------
<acl description="myacl" xmlns="http://xmlns.oracle.com/xdb/acl.xsd" xmlns:dav="
DAV:" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="
http://xmlns.oracle.com/xdb/acl.xsd http://xm
lns.oracle.com/xdb/acl.xsd" shared="true">
<ace>
<grant>true</grant>
<principal>dav:owner</principal>
<privilege>
<dav:all/>
</privilege>
</ace>
</acl>
1 row selected.
例27-11に、プロシージャDBMS_XDB.deleteResourceを使用してACLを削除する方法を示します。
例27-11 ACLの削除
この例では、例27-8で作成したACLを削除します。
CALL DBMS_XDB.deleteResource('/TESTUSER/acl1.xml');
リソースが削除するACLによって保護されている場合は、ACLを削除する前にそのリソースのACLを変更してください。
ACLの更新は、リソースを更新するための標準メソッドを使用して実行できます。特にACLはXML文書なので、ACLの操作にはSQL関数updateXMLやその他のXML更新関数を使用できます。Oracle XML DBのACLは、高速評価のためにキャッシュされます。ACLを更新するトランザクションがコミットされると、Oracle XML DBの構成ファイル/xdbconfig.xmlに指定されたタイムアウトの経過後、既存のデータベース・セッションによって、変更済のACLが取り出されます。このtimoutパラメータのXPath位置は、/xdbconfig/sysconfig/acl-max-ageです。値を表す単位は秒です。ACLの変更後に開始されるセッションでは、新しいACLが遅延なしに使用されます。ACLリソースが非ACLコンテンツで更新される場合、ACLの削除と同じ規則が適用されます。つまり、リソースが更新対象のACLによって保護されている場合は、最初にそのACLを変更してください。
FTPまたはWebDAVを使用してACLを更新できます。これらのプロトコルの使用方法の詳細は、第28章「プロトコルを使用したリポジトリへのアクセス」を参照してください。RESOURCE_VIEWを使用して、ACLの更新や、アクセス制御エントリ（ACE）の変更を行えます。
例27-12 アクセス制御リストの更新（置換）
この例では、SQL関数updateXMLを使用して、ACL /TESTUSER/acl1.xmlを完全に置換することによって更新しています。その結果、プリンシパル値DAV::ownerがTESTUSERで置換されます。置換ACLの他の部分は以前と同じです。
UPDATE RESOURCE_VIEW r
SET r.RES =
updateXML(
r.RES,
'/r:Resource/r:Contents/a:acl',
'<acl description="myacl"
xmlns="http://xmlns.oracle.com/xdb/acl.xsd"
xmlns:dav="DAV:"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/xdb/acl.xsd
http://xmlns.oracle.com/xdb/acl.xsd">
<ace>
<grant>true</grant>
<principal>TESTUSER</principal>
<privilege>
<dav:all/>
</privilege>
</ace>
</acl>',
'xmlns:r="http://xmlns.oracle.com/xdb/XDBResource.xsd"
xmlns:a="http://xmlns.oracle.com/xdb/acl.xsd"')
WHERE equals_path(r.RES, '/TESTUSER/acl1.xml') = 1;
例27-13 アクセス制御リストへのACEの追加
この例では、SQL関数appendChildXMLを使用して、既存のACLにACEを追加しています。このACEは、ユーザーhrに、権限read-propertiesおよびread-contentsを付与します。
UPDATE RESOURCE_VIEW r
SET r.RES =
appendChildXML(
r.RES,
'/r:Resource/r:Contents/a:acl',
XMLType('<ace xmlns="http://xmlns.oracle.com/xdb/acl.xsd">
<grant>true</grant>
<principal>HR</principal>
<privilege>
<read-properties/>
<read-contents/>
</privilege>
</ace>'),
'xmlns:r="http://xmlns.oracle.com/xdb/XDBResource.xsd"
xmlns:a="http://xmlns.oracle.com/xdb/acl.xsd"')
WHERE equals_path(r.RES, '/TESTUSER/acl1.xml') = 1;
例27-14 アクセス制御リストからのACEの削除
この例では、SQL関数deleteXMLを使用して、既存のACLからACEを削除しています。最初のACEはここで削除されます。
UPDATE RESOURCE_VIEW r
SET r.RES =
deleteXML(r.RES,
'/r:Resource/r:Contents/a:acl/a:ace[1]',
'xmlns:r="http://xmlns.oracle.com/xdb/XDBResource.xsd"
xmlns:a="http://xmlns.oracle.com/xdb/acl.xsd"')
WHERE equals_path(r.RES, '/TESTUSER/acl1.xml') = 1;
例26-2は、関数DBMS_XDB.getACLDocumentを指標して、指定されたリソースを保護するACL文書を取得する方法を示しています。
例27-15 リソースのACL文書の取得
SELECT DBMS_XDB.getACLDocument('/TESTUSER/po1.xml').getCLOBVal() FROM DUAL;
DBMS_XDB.GETACLDOCUMENT('/TESTUSER/PO1.XML').GETCLOBVAL()
--------------------------------------------------------------------------------
<acl description="myacl" xmlns="http://xmlns.oracle.com/xdb/acl.xsd" xmlns:dav="
DAV:" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="
http://xmlns.oracle.com/xdb/acl.xsd http://x
mlns.oracle.com/xdb/acl.xsd">
<ace>
<grant>true</grant>
<principal>TESTUSER</principal>
<privilege>
<dav:all/>
</privilege>
</ace>
<ace xmlns="http://xmlns.oracle.com/xdb/acl.xsd">
<grant>true</grant>
<principal>HR</principal>
<privilege>
<read-properties/>
<read-contents/>
</privilege>
</ace>
</acl>
1 row selected.
例27-16に、DBMS_XDB.getPrivilegesファンクションを使用して現行ユーザーに付与された権限を取得する方法を示します。
例27-16 特定のリソースに対して現行ユーザーに付与された権限の取得
SELECT DBMS_XDB.getPrivileges('/TESTUSER/po1.xml').getCLOBVal() FROM DUAL;
DBMS_XDB.GETPRIVILEGES('/TESTUSER/PO1.XML').GETCLOBVAL()
--------------------------------------------------------------------------------
<privilege xmlns="http://xmlns.oracle.com/xdb/acl.xsd" xmlns:xsi="http://www.w3.
org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.oracle.com/xdb/acl
.xsd http://xmlns.oracle.com/xdb/acl.xsd DAV: http://xmlns.oracle.com/xdb/dav.xs
d" xmlns:xdbacl="http://xmlns.oracle.com/xdb/acl.xsd" xmlns:dav="DAV:">
<dav:take-ownership/>
<dav:execute/>
<dav:unlock/>
<read-properties/>
<dav:lock/>
<read-contents/>
<dav:read-current-user-privilege-set/>
<write-config/>
<dav:write-content/>
<resolve/>
<dav:write-properties/>
<unlink-from/>
<unlink/>
<read-acl/>
<write-acl-ref/>
<update-acl/>
<link/>
</privilege>
1 row selected.
例27-17に、DBMS_XDB.checkPrivilegesファンクションを使用して、現行ユーザーがリソースに対する特定の権限セットを所有しているかどうかを確認する方法を示します。ユーザーがその権限を所有している場合、このファンクションは、0（ゼロ）以外の値を戻します。
例27-17 あるリソースに対してユーザーが特定の権限を所有しているかどうかの確認
この例では、リソース/TESTUSER/po1.xmlに対するアクセス権限read-contentsおよびread-propertiesが、現行ユーザーに付与されているかどうかを確認しています。戻り値が正の整数であれば、ユーザーがその権限を持っていることを示しています。
SELECT DBMS_XDB.checkPrivileges(
'/TESTUSER/po1.xml',
XMLType('<privilege
xmlns="http://xmlns.oracle.com/xdb/acl.xsd"
xmlns:dav="DAV:"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/xdb/acl.xsd
http://xmlns.oracle.com/xdb/acl.xsd">
<read-contents/>
<read-properties/>
</privilege>'))
FROM DUAL;
DBMS_XDB.CHECKPRIVILEGES('/TESTUSER/PO1.XML',
---------------------------------------------
1
1 row selected.
ファンクションDBMS_XDB.ACLCheckPrivilegesは、通常、ユーザーによる操作の実行を許可する前に、独自にACLの評価を実行する必要のあるアプリケーションによって使用されます。
例27-18 ACLCheckPrivilegesを使用したユーザー権限の確認
この例では、ACL /TESTUSER/acl1.xmlにより、権限read-contentsおよびread-propertiesが、現行ユーザーshに付与されているかどうかを確認しています。2番目の引数TESTUSERは、確認時にACLのDAV::ownerに置き換えられたユーザーです。shは、指定された権限を付与されたユーザーのいずれにも一致しないため、戻り値はゼロです。
CONNECT sh Enter password: <password> Connected. SELECT DBMS_XDB.ACLCheckPrivileges( '/TESTUSER/acl1.xml', 'TESTUSER', XMLType('<privilege xmlns="http://xmlns.oracle.com/xdb/acl.xsd" xmlns:dav="DAV:" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.oracle.com/xdb/acl.xsd http://xmlns.oracle.com/xdb/acl.xsd"> <read-contents/> <read-properties/> </privilege>')) FROM DUAL; DBMS_XDB.ACLCHECKPRIVILEGES('/TESTUSER/ACL1.XML','TESTUSER', ------------------------------------------------------------ 0 1 row selected.
例27-19では、RESOURCE_VIEW問合せを使用して、特定のリソースを保護するACLのパスを取得します。問合せでは、リソースの要素XMLRefおよびACLOIDが、ACLとリソースをリンクしているという事実が使用されます。
例27-19 特定のリソースを保護するACLのパスの取得
この例は、ACLによって保護されたリソースの指定を受けて、ACLへのパスを取得しています。保護されたリソース（r）のACLOIDには、それを保護しているACLリソース（a）のOIDが格納されています。ACLリソースのREFは、保護されたリソースACLOIDにより識別されるオブジェクトのものと同じです。
リソースACLOIDのREFは、SQL関数make_refを使用して取得できます。指定されたOIDを持つオブジェクト行へのREFが戻されます。
この例では、make_refは、リソース/TESTUSER/po1.xml（r）に対して、OIDが/Resource/ACLOIDである表XDB$ACLの行へのREFを戻しています。内部問合せがリソースのACLOIDを取得します。外部問合せが、対応するACLへのパスを戻します。
SELECT a.ANY_PATH
FROM RESOURCE_VIEW a
WHERE extractValue(a.RES, '/Resource/XMLRef')
= make_ref(XDB.XDB$ACL,
(SELECT extractValue(r.RES, '/Resource/ACLOID')
FROM RESOURCE_VIEW r
WHERE equals_path(r.RES, '/TESTUSER/po1.xml') = 1));
ANY_PATH
------------------
/TESTUSER/acl1.xml
1 row selected.
例27-20では、特定のACLにより保護されているすべてのリソースのパスを取得します。
例27-20 特定のACLによって保護されたすべてのリソースのパスの取得
この例では、パスが/TESTUSER/acl1.xmlであるACLリソースのREFに対してACLOID REFが一致しているリソースへのパスを取得します。ファンクションmake_refはリソースACLOID REFを戻します。
内部問合せは、指定されたACLのREFを取得します。外部問合せは、ACLOID REFが指定されたACLのREFに一致するリソースのパスを選択します。
SELECT r.ANY_PATH
FROM RESOURCE_VIEW r
WHERE make_ref(XDB.XDB$ACL, extractValue(r.RES, '/Resource/ACLOID'))
= (SELECT extractValue(a.RES, '/Resource/XMLRef')
FROM RESOURCE_VIEW a
WHERE equals_path(a.RES, '/TESTUSER/acl1.xml') = 1);
ANY_PATH
-----------------
/TESTUSER/po1.xml
1 row selected.
ACLはその保護対象データへのアクセスのたびに確認されるため、ACLの確認操作のパフォーマンスは、Oracle XML DBリポジトリ・リソースを含むこのようなデータのパフォーマンスにとって重要な問題です。Oracle XML DBでは、このリポジトリ操作に必要なパフォーマンスは、複数のキャッシュを使用することによって達成されます。
ACLは、データベース・インスタンス内のすべてのセッションが共有するキャッシュに保存されます。ACLが更新されると、キャッシュ内のACLエントリが、そのすべての従属オブジェクトとともに無効化されます。ACLが次に使用されるときに、その新しいコピーがキャッシュに入れられます。可能なかぎり、リソース間でACLを共有することをお薦めします。
特定のACLによって特定のユーザーに付与された権限をキャッシュする、セッション固有のキャッシュがあります。このキャッシュのエントリには、Oracle XML DB構成ファイル（/xdbconfig.xml）の要素<acl-max-age>によって、タイムアウト（秒単位）が指定されます。パフォーマンスを最大限にするために、このタイムアウトは可能なかぎり長く設定してください。ただし、この場合トレードオフが存在します。タイムアウトが長いほど、現行セッションが更新されたACLを取り出す時間が長くなります。
Oracle XML DBは、LDAPプリンシパル（LDAPグループまたはユーザー）が設定されたACLの使用時にも、パフォーマンスを向上させるためにキャッシュを保持します。これらのキャッシュの目的は、LDAPサーバーとのネットワーク通信を最小化することです。キャッシュの1つは、LDAP GUIDを対応するLDAPのニックネームおよび識別名（DN）にマップする共有キャッシュです。これは、ACL文書が表示されているとき（または、XMLTypeインスタンスからCLOB値またはVARCHAR2値に変換されているとき）に使用されます。このキャッシュを消去する場合は、プロシージャDBMS_XDBZPurgeLDAPCacheを使用します。もう1つのキャッシュは、セッション固有のキャッシュで、LDAPグループをそのメンバー（ネストされたメンバーシップ）にマップします。Oracle XML DBでは、LDAPグループをセッションで最初に検出するたびに、LDAPサーバーからそのグループのネストされたメンバーシップを取得します。そのため、可能なかぎりメンバーとネスト・レベルの少ないグループを使用することをお薦めします。
Oracle XML DBリポジトリのリソースには、次の2タイプがあります。
LOBベース（コンテンツはリソースの一部であるLOBに格納されます）。アクセスは、リソースを保護するACLによってのみ決定されます。
REFベース（コンテンツはXMLであるため、データベース表に格納されます）。ユーザーは、XMLコンテンツが格納されている基礎となる表またはビューに対する適切な権限、およびリソースに対するACLを介した権限を所有している必要があります。
REFベースのリソースのコンテンツは表に格納されるため、その表に対するSQL問合せを使用してこのデータに直接アクセスできます。均一なアクセス制御メカニズムは、アクセスに必要な権限がアクセスの方法（FTP、HTTPまたはSQLなど）に依存しないメカニズムです。ACLを使用した均一なセキュリティ・メカニズムを提供するためには、最初に、表の行を参照するリソースをOracle XML DBに挿入する前に、基礎となる表が階層に対応している必要があります。
XML Schemaの登録により作成されたデフォルト表は、階層対応になっています。つまり、階層の有効化はXML SchemaをOracle XML DBに登録したときのデフォルトの動作です。登録後に階層を有効化することもできます。それにはプロシージャDBMS_XDBZ.enable_hierarchyを使用します。
リソース表で階層を有効にすると、次の動作が行われます。
表の行を参照するリソースのACLOIDおよびOWNERを格納する非表示列が2つ追加されます。
その表に行レベルのセキュリティ（RLS）・ポリシーが追加されます。このポリシーは、SELECT文、UPDATE文またはDELETE操作がその表に対して実行されるたびに、ACLを確認します。
コンテンツが格納されているXMLType表で表が更新されたとき、それに対応する最後に変更されたリソース情報が常に更新されることを保証する、パス索引トリガーと呼ばれるデータベース・トリガーが作成されます。
|
関連項目:
|
指定された任意の表で、オブジェクトの一部だけがOracle XML DBリソースにマップされることがあります。マップされたオブジェクトのみがACLチェックを受けますが、すべてのオブジェクトに表レベルのセキュリティがあります。
|
注意: 表外に格納する場合は、XMLType表のデータを他のユーザーに対して非表示にすることはできません。表外のデータは、ACLセキュリティによって保護されません。 |
この項では、LDAPユーザーがACLを含むOracle XML DBの機能を使用できるようにするための処理について説明します。典型的なシナリオでは、単一の共有データベース・スキーマ（ユーザー）に、複数のLDAPユーザーがマップされています。このマッピングは、Oracle Internet Directoryで維持されています。エンド・ユーザーは、LDAPユーザー名およびパスワードを使用して、データベースにログインできます。ログインすると、対応する共有データベース・スキーマに自動的にマップされます。（ログインには、SQLまたはOracle XML DBでサポートされている任意のプロトコルを使用できます。）暗黙的なACL解決は、現行のLDAPユーザーおよび対応するLDAPグループのメンバーシップ情報に基づいています。
Oracle XML DB ACLのプリンシパルとしてLDAPユーザーおよびLDAPグループを使用する場合は、その前に次の条件を満たす必要があります。
Oracle Internet Directoryが設定され、データベースがそれに登録されている必要があります。
SSL認証がデータベースとOracle Internet Directoryの間に設定されている必要があります。
共有データベース・スキーマに対応するデータベース・ユーザーが作成されている必要があります。
Oracle Internet DirectoryでLDAPユーザーが作成され、共有データベース・スキーマにマップされる必要があります。
LDAPグループが作成され、そのメンバーが指定されている必要があります。
LDAPグループやLDAPユーザーに対してACLが定義され、それを使用してLDAPユーザーがアクセスするリポジトリ・リソースが保護される必要があります。
|
関連項目:
|
例27-21 LDAPユーザーを参照するACL
これはLDAPユーザーのためのACLの例です。要素<principal>には、LDAPユーザーの完全識別名（この場合cn=user1,ou=Americas,o=oracle,l=redwoodshores,st=CA,c=US）が含まれています。
<acl description="/public/txmlacl1/acl1.xml"
xmlns="http://xmlns.oracle.com/xdb/acl.xsd" xmlns:dav="DAV:"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/xdb/acl.xsd
http://xmlns.oracle.com/xdb/acl.xsd">
<ace principalFormat="DistinguishedName">
<grant>true</grant>
<principal>cn=user1,ou=Americas,o=oracle,l=redwoodshores,st=CA,c=US
</principal>
<privilege>
<dav:all/>
</privilege>
</ace>
</acl>
|
関連項目: LDAPユーザー識別名のフォーマットについては『Oracle Internet Directory管理者ガイド』 |
例27-22 LDAPグループを参照するACL
これはLDAPグループのためのACLの例です。要素<principal>には、LDAPグループの完全識別名が含まれています。
<acl xmlns="http://xmlns.oracle.com/xdb/acl.xsd" xmlns:dav="DAV:"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/xdb/acl.xsd
http://xmlns.oracle.com/xdb/acl.xsd">
<ace principalFormat="DistinguishedName">
<grant>true</grant>
<principal>cn=grp1,ou=Americas,o=oracle,l=redwoodshores,st=CA,c=US</principal>
<privilege>
<dav:read/>
</privilege>
</ace>
</acl>
|
関連項目: LDAPグループ識別名のフォーマットについては『Oracle Internet Directory管理者ガイド』 |
脚注の凡例
脚注1:DAV:は接頭辞ではなく名前空間そのものです。このため、セキュリティ・クラスの完全なQNameは、DAV::davとなります。名前空間DAV:に広く使用される接頭辞はdavですが、これは慣例的なものにすぎません。davは、Oracle XML DBで事前定義されている接頭辞ではありません。