11 Oracle Virtual Private Databaseを使用したデータ・アクセスの制御
Oracle Virtual Private Database (VPD)を使用すると、データにアクセスするユーザーをフィルタ処理できます。
- Oracle Virtual Private Databaseについて
Oracle Virtual Private Database (VPD)には、ユーザーによるデータへのアクセスをフィルタ処理する場合の重要なメリットがあります。 - Oracle Virtual Private Databaseポリシーのコンポーネント
VPDポリシーは関数を使用して動的WHERE
句を生成し、ポリシーを使用して保護するオブジェクトに関数を付加します。 - Oracle Virtual Private Databaseのポリシーの構成
DBMS_RLS
PL/SQLパッケージで、Oracle Virtual Private Database (VPD)ポリシーを構成できます。 - 例: Oracle Virtual Private Databaseポリシーの作成
このチュートリアルでは、簡単なデータベース・セッション・ベースのOracle Virtual Privateポリシーの作成方法と、ポリシー・グループの作成方法を説明します。 - 他のOracle機能でのOracle Virtual Private Databaseの使用
Oracle Virtual Private DatabaseをOracleの他の機能と併用することの影響を理解しておく必要があります。 - Oracle Virtual Private Databaseのデータ・ディクショナリ・ビュー
Oracle Databaseには、Oracle Virtual Private Databaseポリシーに関する情報を表示するデータ・ディクショナリ・ビューが用意されています。
親トピック: データへのアクセス制御
11.1 Oracle Virtual Private Databaseについて
Oracle Virtual Private Database (VPD)には、ユーザーによるデータへのアクセスをフィルタ処理する場合の重要なメリットがあります。
- Oracle Virtual Private Database
Oracle Virtual Private Database(VPD)で、行および列レベルでデータベース・アクセスを制御するセキュリティ・ポリシーを作成します。 - Oracle Virtual Private Databaseポリシーを使用するメリット
Oracle Virtual Private Databaseポリシーには、重要なメリットがあります。 - Oracle Virtual Private Databaseポリシーの作成者とは
DBMS_RLS
PL/SQLパッケージでは、VPDポリシーを作成できます。 - Oracle Virtual Private Databaseポリシー関数を実行するための権限
Oracle Virtual Private Database (VPD)ポリシー関数を実行するには、正しい権限を使用する必要があります。 - Oracle Virtual Private Databaseでのアプリケーション・コンテキストの使用
Oracle Virtual Private Databaseポリシーを使ったアプリケーション・コンテキストを使用できます。 - マルチテナント環境でのOracle Virtual Private Database
アプリケーション・ルートで仮想プライベート・データベース・ポリシーを作成して、関連付けられたすべてのアプリケーションPDBで使用できます。
11.1.1 Oracle Virtual Private Database
Oracle Virtual Private Database(VPD)で、行および列レベルでデータベース・アクセスを制御するセキュリティ・ポリシーを作成します。
ノート:
Oracle Databaseリリース12cでは、VPDにかわってReal Application Security (RAS)が採用されました。アプリケーションで行レベルおよび列レベルのアクセス制御が必要な新規プロジェクトにはRASを使用することをお薦めします。
基本的には、Oracle Virtual Private Databaseのセキュリティ・ポリシーが適用された表、ビューまたはシノニムに対して発行されるSQL文に、動的なWHERE
句が追加されます。
Oracle Virtual Private Databaseを使用すると、データベース表、ビューまたはシノニムに対するセキュリティを直接詳細なレベルまで規定できます。これらのデータベース・オブジェクトにセキュリティ・ポリシーを直接付加すると、ユーザーがデータにアクセスするたびにポリシーが自動的に適用されるため、セキュリティを回避できません。
ユーザーがOracle Virtual Private Databaseポリシーで保護されている表、ビューまたはシノニムに直接的または間接的にアクセスすると、Oracle DatabaseはユーザーのSQL文を動的に変更します。この変更は、セキュリティ・ポリシーを実装する関数によって戻されたWHERE
条件(述語)に基づいて行われます。Oracle Databaseでは、関数内に記述された条件、または関数が戻す条件を使用して、動的かつユーザーに対して透過的に文が変更されます。Oracle Virtual Private Databaseポリシーは、SELECT
、INSERT
、UPDATE
、INDEX
およびDELETE
文に適用できます。
たとえば、ユーザーが次の問合せを実行するとします。
SELECT * FROM OE.ORDERS;
Oracle Virtual Private Databaseポリシーにより、WHERE
句の文が動的に追加されます。たとえば:
SELECT * FROM OE.ORDERS
WHERE SALES_REP_ID = 159;
この例では、ユーザーは営業担当者159の受注のみを表示できます。
このユーザーのセッション情報(ユーザーのIDなど)に基づいてユーザーをフィルタ処理する場合は、WHERE
句を作成してアプリケーション・コンテキストを使用できます。たとえば:
SELECT * FROM OE.ORDERS
WHERE SALES_REP_ID = SYS_CONTEXT('USERENV','SESSION_USER');
ノート:
Oracle Virtual Private Databaseでは、DDL(TRUNCATE
文やALTER TABLE
文)のフィルタ処理はサポートされていません。
11.1.2 Oracle Virtual Private Databaseポリシーを使用するメリット
Oracle Virtual Private Databaseポリシーには、重要なメリットがあります。
- アプリケーションではなくデータベース・オブジェクトに基づくセキュリティ・ポリシー
Oracle Virtual Private Databaseにはセキュリティ、簡易性、柔軟性という利点があります。 - Oracle Databaseによるポリシー関数の評価方法の制御
ポリシー関数を複数回実行すると、パフォーマンスに影響を与える可能性があります。
11.1.2.1 アプリケーションではなくデータベース・オブジェクトに基づくセキュリティ・ポリシー
Oracle Virtual Private Databaseにはセキュリティ、簡易性、柔軟性という利点があります。
すべてのアプリケーションでアクセス制御を実装するのではなく、Oracle Virtual Private Databaseセキュリティ・ポリシーをデータベース表、ビューまたはシノニムに付加すると、次のようなメリットがあります。
-
セキュリティ。データベース表、ビューまたはシノニムにポリシーを対応付けることで、アプリケーション・セキュリティの重大な問題を解決できます。たとえば、アプリケーションの使用を許可されているユーザーが、そのアプリケーションに対応付けられている権限を利用し、SQL*Plusなどの非定型の問合せツールを使用してデータベースを誤って変更してしまう可能性があります。ファイングレイン・アクセス・コントロールでは、セキュリティ・ポリシーを表、ビューまたはシノニムに直接付加することによって、ユーザーがどのような方法でデータにアクセスしても、同じセキュリティが施行されます。
-
簡潔性。セキュリティ・ポリシーは、表ベース、ビュー・ベースまたはシノニム・ベースのアプリケーションごとに繰り返し追加するのではなく、表、ビューまたはシノニムに1回のみ追加します。
-
柔軟性。
SELECT
文には1つのセキュリティ・ポリシーを、INSERT
文には別のポリシーを、さらにUPDATE
文およびDELETE
文にはまた別のポリシーを指定できます。たとえば、人事部門の担当者には、その部門内のすべての社員のレコードに対するSELECT
権限を付与し、名字がA
からF
で始まるその部門内の社員の給与のみを更新できるように指定できます。さらに、各表、ビューまたはシノニムに対して複数のポリシーを作成できます。
11.1.2.2 Oracle Databaseによるポリシー関数の評価方法の制御
ポリシー関数を複数回実行すると、パフォーマンスに影響を与える可能性があります。
Oracle DatabaseがOracle Virtual Private Database述語をキャッシュする方法を構成することによって、ポリシー関数のパフォーマンスを制御できます。
次のオプションを使用できます。
-
各問合せについてポリシーを1回評価します(静的ポリシー)。
-
ポリシー関数内のアプリケーション・コンテキストが変更された場合のみ、ポリシーを評価します(状況依存ポリシー)。
-
実行ごとにポリシーを評価します(動的ポリシー)。
11.1.3 Oracle Virtual Private Databaseポリシーの作成者とは
DBMS_RLS
PL/SQLパッケージでは、VPDポリシーを作成できます。
DBMS_RLS
PL/SQLパッケージのEXECUTE
権限が付与されたユーザーは、Oracle Virtual Private Databaseポリシーを作成できます。すべての権限と同様、この権限は信頼できるユーザーにのみ付与してください。ユーザーに付与された権限を確認するには、DBA_SYS_PRIVSデータ・ディクショナリ・ビューに問い合せます。
11.1.4 Oracle Virtual Private Databaseポリシー関数を実行するための権限
Oracle Virtual Private Database (VPD)ポリシー関数を実行するには、正しい権限を使用する必要があります。
セキュリティを強化するために、Oracle Virtual Private Database ポリシー関数は、定義者権限で宣言されたかのように実行されます。
実行者権限として宣言すると、自分自身だけでなく、コードをメンテナンスする他のユーザーも混乱させてしまうため、実行者権限では宣言しないでください。
関連項目:
定義者権限の詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。
11.1.5 Oracle Virtual Private Databaseでのアプリケーション・コンテキストの使用
Oracle Virtual Private Databaseポリシーを使ったアプリケーション・コンテキストを使用できます。
アプリケーション・コンテキストを作成すると、ユーザー情報が安全にキャッシュされます。キャッシュ環境を設定できるのは、指定されたアプリケーション・パッケージのみです。ユーザーやパッケージ外部からの変更はできません。さらに、データがキャッシュされるため、パフォーマンスが向上します。
たとえば、ORDERS_TAB
表へのアクセスを顧客ID番号を基にして行うとします。顧客ID番号が必要になるたびにログインしたユーザーに問い合せるのではなく、アプリケーション・コンテキスト内に顧客ID番号を格納しておくことができます。このようにすると、顧客番号は必要なときにセッションで使用できます。
アプリケーション・コンテキストは、セキュリティ・ポリシーが複数のセキュリティ属性に基づく場合に特に役立ちます。たとえば、WHERE
述語が4つの属性(従業員番号、コスト・センター、職位、支出制限など)に基づくポリシー関数は、この情報を取得するために複数の副問合せを実行する必要があります。このデータがアプリケーション・コンテキストを介して使用可能な場合、パフォーマンスは大きく向上します。
アプリケーション・コンテキストを使用すると、述語により規定される正しいセキュリティ・ポリシーを戻すことができます。たとえば、「顧客は自分の注文のみを参照でき、社員はすべての顧客のすべての注文を参照できる」というルールを規定している受注管理アプリケーションを想定します。この場合は、2つの異なるポリシーがあります。position
属性でアプリケーション・コンテキストを定義できます。この属性はポリシー関数内でアクセスでき、その属性の値に基づいて正しい述語を戻します。そのため、職位がclerk (社員)
であるユーザーはすべての注文を取得できるようにし、customer (顧客)
であるユーザーは自分に関連するレコードのみ参照できるようにすることができます。
属性に対して特定の述語を戻すファイングレイン・アクセス・コントロール・ポリシーを設計するには、ポリシーを実装する関数内でアプリケーション・コンテキストにアクセスする必要があります。たとえば、顧客が自分のレコードのみを参照するように制限する必要があるとします。ユーザーは次の問合せを実行します。
SELECT * FROM orders_tab
ファイングレイン・アクセス・コントロールによって、この問合せはWHERE
述語が含まれるように動的に変更されます。
SELECT * FROM orders_tab WHERE custno = SYS_CONTEXT ('order_entry', 'cust_num');
前述の例で、50,000人の顧客が存在し、各顧客が受け取る述語を同じにするとします。すべての顧客は同一のWHERE
述語を共有し、自分の注文のみを参照できます。顧客間で異なるのは、顧客番号のみです。
アプリケーション・コンテキストを使用して、50,000人の顧客に適用されるポリシー関数内で1つのWHERE
述語を返すことができます。結果として、顧客番号が実行時に評価されるため、顧客ごとに実行方法が異なる1つの共有カーソルが存在することになります。この値は、すべての顧客で異なります。このようにアプリケーション・コンテキストを使用することで、最適なパフォーマンスと行レベルのセキュリティが実現します。
SYS_CONTEXT
関数がバインド変数のように動作するのは、SYS_CONTEXT
引数が定数の場合のみです。
11.1.6 マルチテナント環境でのOracle Virtual Private Database
アプリケーション・ルートで仮想プライベート・データベース・ポリシーを作成して、関連付けられたすべてのアプリケーションPDBで使用できます。
CDBの制限は、共有の状況依存ポリシーのほか、仮想プライベート・データベース・ポリシー関連のビューにも適用されます。マルチテナント環境全体に仮想プライベート・データベース・ポリシーを作成することはできません。
アプリケーション・コンテナについては、仮想プライベート・データベース・ポリシーを作成して、アプリケーション・ルートに属するすべてのPDBに共通ポリシーを適用することで、アプリケーション共通オブジェクトを保護できます。つまり、アプリケーション・ルートにアプリケーションをインストールすると、共通オブジェクトを保護するすべての共通仮想プライベート・データベース・ポリシーは、アプリケーション・コンテナのすべてのPDBに適用され、即座に実施されます。
次のことに注意してください。
-
アプリケーション・ルートでは共通仮想プライベート・データベース・ポリシーおよびそれに関連するPL/SQLファンクションのみを作成し、それをアプリケーション共通オブジェクトに付加することができます。ファンクションがポリシーと同じ場所にない場合、実行時にエラーが発生します。
-
共通オブジェクトに適用される仮想プライベート・データベース・ポリシーは、アプリケーションPDBからアプリケーション共通オブジェクトにアクセスする場合、アプリケーション・コンテナに属するPDBで自動的に強制される共通ポリシーと見なされます。
-
アプリケーション共通仮想プライベート・データベース・ポリシーは、アプリケーション共通オブジェクトのみを保護できます。
-
アプリケーション・ルートのアプリケーション共通オブジェクトに適用され、すべてのアプリケーションPDBに適用される仮想プライベート・データベース・ポリシーは、共通仮想プライベート・データベース・ポリシーと見なされます。ローカル・データベース表に適用され、1つのPDBで実施されるポリシーは、ローカル仮想プライベート・データベース・ポリシーと見なされます。
たとえば、ポリシー
VPD_P1
がアプリケーション・ルートのアプリケーション共通表T1
に適用される場合は、共通ポリシーと見なされます。このポリシーは各アプリケーションPDBに強制されます。VPD_P1
というポリシーがPDB1
のT1
というローカル表に適用される場合は、ローカル・ポリシーと見なされ、PDB1
のみがその影響を受けます。VPD_P1
というポリシーがアプリケーション・ルートのT1
というローカル表に適用される場合も、アプリケーション・ルートのみが影響を受けるため、ローカル・ポリシーと見なされます。この概念は、仮想プライベート・データベース・ポリシーの有効化、無効化および削除などの他の操作にも適用されます。 -
アプリケーション共通仮想プライベート・データベース・ポリシーはアプリケーション共通オブジェクトのみを保護し、ローカル仮想プライベート・データベース・ポリシーはローカル・オブジェクトのみを保護します。
-
アプリケーション・コンテキストを使用している場合は、共通データベース・セッション・ベースのアプリケーション・コンテキストおよび共通グローバル・アプリケーション・コンテキスト・オブジェクトを共通仮想プライベート・データベース構成で使用するようにしてください。
-
アプリケーション・コンテナの仮想プライベート・データベース・ポリシーは、アプリケーション・ルートに格納されます。PDBにはローカル・ポリシーのみが格納されます。PDBをアプリケーション・コンテナに接続する場合、共通ポリシーはローカル・ポリシーに変換されません。かわりに、Oracle Databaseがアプリケーション・ルートからそれらをロードし、ポリシーからローカルPDBの共通オブジェクトにアクセスがあると、ローカルPDBでそれらを強制します。
11.2 Oracle Virtual Private Databaseポリシーのコンポーネント
VPDポリシーは関数を使用して動的WHERE
句を生成し、ポリシーを使用して保護するオブジェクトに関数を付加します。
- 動的なWHERE句を生成する関数
Oracle Virtual Private Database (VPD)関数で、適用する制限を定義します。 - 保護するオブジェクトに関数を付加するポリシー
Oracle Virtual Private Databaseポリシーで、VPD関数を表やビュー、シノニムに関連付けます。
11.2.1 動的なWHERE句を生成する関数
Oracle Virtual Private Database (VPD)関数で、適用する制限を定義します。
Oracle Virtual Private Database (VPD)の動的なWHERE
句(述語)を生成するには、これらの制限を定義した関数(プロシージャではなく)を作成する必要があります。この関数は、定義者権限関数です。
通常は、セキュリティ管理者が自分のスキーマにこの関数を作成します。別の関数のコールを含めたり、ログイン失敗を追跡するためのチェックを追加するなど、複雑な動作が必要な場合は、これらの関数を1つのパッケージ内に作成します。
関数では、次の動作が必要です。
-
引数としてスキーマ名、入力としてオブジェクト(表、ビューまたはシノニム)名を取る必要があります。これらの情報を保持するように入力パラメータを定義しますが、関数内でスキーマ名とオブジェクト名自体を指定しないでください。
DBMS_RLS
パッケージ(保護するオブジェクトに関数を付加するポリシーを参照)を使用して作成したポリシーによって、スキーマ名、およびポリシーが適用されるオブジェクトが提供されます。最初にスキーマのパラメータを作成し、その後にオブジェクトのパラメータを作成する必要があります。 -
生成するWHERE句述語の戻り値を提供する必要があります。
WHERE
句の戻り値は、常にVARCHAR2
データ型です。 -
有効なWHERE句を生成する必要があります。このコードは、例: 単純なOracle Virtual Private Databaseポリシーの作成に示すように基本的なもので、
WHERE
句はログインするすべてのユーザーに共通です。ただし、ほとんどの場合、各ユーザー、ユーザーの各グループ、または保護するオブジェクトにアクセスする各アプリケーションに異なる
WHERE
句を設計する必要があります。たとえば、マネージャがログインする場合は、そのマネージャの権限に固有のWHERE
句を生成できます。これを行うには、ユーザー・セッション情報にアクセスするアプリケーション・コンテキストをWHERE
句の生成コードに組み込みます。チュートリアル: セッション・ベースのアプリケーション・コンテキスト・ポリシーの実装では、アプリケーション・コンテキストを使用するOracle Virtual Private Databaseポリシーの作成方法について説明します。アプリケーション・コンテキストを使用しないOracle Virtual Private Database関数を作成することもできますが、アプリケーション・コンテキストを使用すると、ユーザーのセッション属性(ユーザーIDなど)に基づいてユーザー・アクセスが安全に行われるため、より強固なOracle Virtual Private Databaseポリシーを作成できます。様々なタイプのアプリケーション・コンテキストの詳細は、「アプリケーション・コンテキストを使用したユーザー情報の取得」を参照してください。
さらに、CまたはJavaコールを埋め込み、オペレーティング・システム情報にアクセスしたり、オペレーティング・システム・ファイルや他のソースから
WHERE
句を戻すことができます。 -
関連するポリシー関数内の表から選択しないでください。表へのポリシーの定義は可能ですが、表に定義されたポリシーから表を選択することはできません。
-
純粋関数である必要があります。VPD関数は、受け取ったアプリケーション・コンテキストおよび引数のみに依存して、
WHERE
句を生成するものでなければなりません。この関数がパッケージ変数に依存することは許可されません。
ノート:
関数を様々なエディションで実行する場合、関数の結果がすべてのエディションで同一か、または関数が実行されているエディションによって異なるかに関係なく、関数の結果を制御できます。詳細は、エディションがグローバル・アプリケーション・コンテキストのPL/SQLパッケージの結果に与える影響を参照してください。
11.2.2 保護するオブジェクトに関数を付加するポリシー
Oracle Virtual Private Databaseポリシーで、VPD関数を表やビュー、シノニムに関連付けます。
このポリシーを作成するには、DBMS_RLS
パッケージを使用します。SYS
でない方は、DBMS_RLS
パッケージを使用するためにEXECUTE
権限を付与される必要があります。このパッケージには、ポリシーの管理とファイングレイン・アクセス・コントロールの設定が可能になるプロシージャが含まれています。たとえば、ポリシーを表に付加するには、DBMS_RLS.ADD_POLICY
プロシージャを使用します。この設定の中で、たとえばユーザーがSELECT
文やUPDATE
文を表またはビューで発行するとポリシーが有効になるよう設定して、ファイングレイン・アクセス・コントロールを設定します。
Oracle Virtual Private Databaseポリシーの作成とは、関数を作成し、その関数を表またはビューに適用することを意味します。
11.3 Oracle Virtual Private Databaseのポリシーの構成
DBMS_RLS
PL/SQLパッケージで、Oracle Virtual Private Database (VPD)ポリシーを構成できます。
- Oracle Virtual Private Databaseポリシーについて
Oracle Virtual Private Databaseポリシーで、VPD関数をデータベース表やビュー、シノニムに関連付けます。 - データベース表、ビューまたはシノニムへのポリシーの付加
DBMS_RLS
PL/SQLパッケージで、表、ビューまたはシノニムにポリシーを付加できます。 - 例: 表への単純なOracle Virtual Private Databaseポリシーの付加
DBMS_RLS.ADD_POLICY
プロシージャで、Oracle Virtual Private Database (VPD)ポリシーを表、ビューまたはシノニムに付加できます。 - 特定のSQL文に対するポリシーの規定
Oracle Virtual Private Databaseポリシーは、SELECT
、INSERT
、UPDATE
、INDEX
およびDELETE
文に規定できます。 - 例: DBMS_RLS.ADD_POLICYを使用したSQL文の指定
DBMS_RLS.ADD_POLICY
プロシージャのstatement_types
パラメータで、ポリシーのSELECT
文とINDEX
文を指定できます。 - ポリシーを使用した列データ表示の制御
セキュリティに関連する列が問合せで参照される際に行レベルのセキュリティを規定するポリシーを作成できます。 - Oracle Virtual Private Databaseポリシー・グループ
Oracle Virtual Private Databaseポリシー・グループは、アプリケーションに適用できるVPDポリシーの名前付きコレクションです。 - Oracle Virtual Private Databaseポリシー・タイプを使用したパフォーマンスの最適化
Oracle Virtual Private Database (VPD)の動的、静的または共有ポリシー・タイプを使用して、パフォーマンスを最適化できます。
11.3.1 Oracle Virtual Private Databaseポリシーについて
Oracle Virtual Private Databaseポリシーで、VPD関数をデータベース表やビュー、シノニムに関連付けます。
この関数はOracle Virtual Private Database WHERE
句のアクションを定義します。この関数を、Oracle Virtual Private Database (VPD)アクションが適用されるデータベース表に関連付ける必要があります。
これを行うには、Oracle Virtual Private Databaseポリシーを構成します。ポリシーとは、仮想プライベート・データベース関数を管理するメカニズムです。また、ポリシーを使用すると、ファイングレイン・アクセス・コントロールを追加できるため、たとえば、SQL文のタイプを指定したり、特定の表列にポリシーを適用できます。ユーザーがこのデータベース・オブジェクト内のデータにアクセスすると、ポリシーが自動的に有効になります。
表11-1に、DBMS_RLS
パッケージに含まれているプロシージャを示します。
表11-1 DBMS_RLSのプロシージャ
プロシージャ | 説明 |
---|---|
個別ポリシーの処理用 |
- |
|
表、ビューまたはシノニムにポリシーを追加します。 |
|
表、ビューまたはシノニムに事前に追加したポリシーを使用可能または使用禁止にします。 |
|
属性とポリシーの関連付けまたは関連付けの解除のため、既存のポリシーを変更します。 |
|
静的ポリシー以外のポリシーに対応付けられたカーソルを無効にします。 |
|
表、ビューまたはシノニムからポリシーを削除します。 |
グループ・ポリシーの処理用 |
- |
|
ポリシー・グループを作成します。 |
|
ポリシー・グループを変更します。 |
|
ポリシー・グループを削除します。 |
|
特定のポリシー・グループにポリシーを追加します。 |
|
グループ内のポリシーを使用可能にします。 |
|
リフレッシュされたポリシーに対応付けられたSQL文を再解析します。 |
|
グループ内のポリシーを使用禁止にします。 |
|
特定のグループに属するポリシーを削除します。 |
アプリケーション・コンテキストの処理用 |
- |
|
アクティブなアプリケーションのコンテキストを追加します。 |
|
アプリケーションのコンテキストを削除します。 |
11.3.2 データベース表、ビューまたはシノニムへのポリシーの付加
DBMS_RLS
PL/SQLパッケージで、表、ビューまたはシノニムにポリシーを付加できます。
-
ポリシーをデータベース表、ビューまたはシノニムに付加するには、
DBMS_RLS.ADD_POLICY
プロシージャを使用します。
ポリシーを追加する表、ビューまたはシノニム、およびポリシーの名前を指定する必要があります。また、ポリシーが制御する文のタイプ(SELECT
、INSERT
、UPDATE
、DELETE
、CREATE INDEX
またはALTER INDEX
)など、その他の情報も指定できます。
次のガイドラインに従ってください。
-
拡張データリンク・オブジェクトとしてビューを作成した場合は、ビューの基礎となるオブジェクトの場合と同じVPDポリシーをこのタイプのビュー適用することをお薦めします。
-
VPDポリシーを追加するベース・オブジェクトに依存オブジェクトが含まれているかどうかを判別します。依存オブジェクトが含まれている場合は、そのVPDポリシーがベース・オブジェクトに追加されるとこれらのオブジェクトは無効になり、使用時には自動的に再コンパイルされます。
あるいは、
ALTER ... COMPILE
文を使用してこれらを各自でプロアクティブに再コンパイルできます。依存オブジェクトを(そのベース・オブジェクトにVPDポリシーを追加することにより)を無効にすると、それらを再コンパイルする必要が生じ、これが原因でシステム全体のパフォーマンスが低下する可能性がある点に注意してください。依存オブジェクトが含まれるオブジェクトにVPDポリシーを追加する操作は、オフピーク時またはスケジュールされた停止時間のみに行うことをお薦めします。 -
1つのオブジェクトに作成できるポリシーの最大数は255であることに注意してください。
11.3.3 例: 表への単純なOracle Virtual Private Databaseポリシーの付加
DBMS_RLS.ADD_POLICY
プロシージャで、Oracle Virtual Private Database (VPD)ポリシーを表、ビューまたはシノニムに付加できます。
例11-1に、DBMS_RLS.ADD_POLICY
を使用して、secure_update
というOracle Virtual Private DatabaseポリシーをHR.EMPLOYEES
表に付加する方法を示します。ポリシーに付加される関数はcheck_updates
です。
例11-1 表への単純なOracle Virtual Private Databaseポリシーの付加
BEGIN DBMS_RLS.ADD_POLICY( object_schema => 'hr', object_name => 'employees', policy_name => 'secure_update', policy_function => 'check_updates', ...
関数がパッケージ内に作成されている場合は、パッケージ名を指定します。たとえば:
policy_function => 'pkg.check_updates', ...
表へのポリシーの定義は可能ですが、表に定義されたポリシーから表を選択することはできません。
11.3.4 特定のSQL文に対するポリシーの規定
Oracle Virtual Private Databaseポリシーは、SELECT
、INSERT
、UPDATE
、INDEX
およびDELETE
文に規定できます。
-
ポリシーに対してSQL文のタイプを指定するには、
DBMS_RLS.ADD_POLICY
プロシージャのstatement_types
パラメータを使用します。複数指定するには、それぞれをカンマで区切ります。リストは一重引用符で囲みます。
文のタイプを指定しない場合、Oracle DatabaseではデフォルトでSELECT
、INSERT
、UPDATE
およびDELETE
が指定されますが、INDEX
は指定されません。これらの文のタイプの組合せを入力できます。
statement_types
パラメータを指定する場合は、次の機能に注意してください。
-
Virtual Private Databaseポリシーによる影響を受けるアプリケーション・コードとして、MERGE INTO文が含まれる場合があります。しかし、Virtual Private Databaseポリシーでは、
statement_types
パラメータにINSERT
、UPDATE
、およびDELETE
の3つの文すべてを含めてポリシーを正常に機能させる必要があります。あるいは、statement_types
パラメータを省略できます。 -
索引をメンテナンスする権限を持っているユーザーは、たとえこのユーザーがSELECTのような標準問合せでは完全な表アクセスを持っていない場合でも、すべての行データを参照できることに注意してください。たとえばユーザーは、列値を引数とする、ユーザー定義関数を含む関数ベースの索引を作成できます。索引作成時に、Oracle Databaseがあらゆる行の列値をユーザー関数へ渡して、索引を作成するユーザーが行データを使用できるようにします。
INDEX
をstatement_types
パラメータで指定することにより、Oracle Virtual Private Databaseポリシーを索引メンテナンス操作で適用できます。
11.3.5 例: DBMS_RLS.ADD_POLICYを使用したSQL文の指定
DBMS_RLS.ADD_POLICY
プロシージャのstatement_types
パラメータで、ポリシーのSELECT
文とINDEX
文を指定できます。
例11-2に、これを行う方法を示します。
例11-2 DBMS_RLS.ADD_POLICYを使用したSQL文の指定
BEGIN
DBMS_RLS.ADD_POLICY(
object_schema => 'hr',
object_name => 'employees',
policy_name => 'secure_update',
policy_function => 'check_updates',
statement_types => 'SELECT,INDEX');
END;
/
11.3.6 ポリシーを使用した列データ表示の制御
セキュリティに関連する列が問合せで参照される際に行レベルのセキュリティを規定するポリシーを作成できます。
- 列レベルのOracle Virtual Private Databaseのポリシー
列レベルのポリシーによって、セキュリティに関連する列が問合せで参照される際の行レベルのセキュリティを規定できます。 - 例: 列レベルのOracle Virtual Private Databaseポリシーの作成
CREATE FUNCTION文およびDBMS_RLS.ADD_POLICYプロシージャで、列レベルのOracle Virtual Private Databaseポリシーを構成できます。 - 問合せに関連する列の行のみの表示
デフォルトで、列レベルのOracle Virtual Private Databaseでは、機密情報が含まれた列が問合せで参照された場合、戻される行の数が制限されます。 - 機密性の高い列をNULL値で表示するための列のマスク
問合せで機密性の高い列を参照する場合、デフォルトの列レベルのOracle Virtual Private Databaseでは、戻される行の数が制限されます。 - 例: Oracle Virtual Private Databaseポリシーへの列のマスクの追加
DBMS_RLS.ADD_POLICYプロシージャで、列レベルのOracle Virtual Private Database列のマスク動作を構成できます。
11.3.6.1 列レベルのOracle Virtual Private Databaseのポリシー
列レベルのポリシーによって、セキュリティに関連する列が問合せで参照される際の行レベルのセキュリティを規定できます。
列レベルのOracle Virtual Private Databaseポリシーは、表やビューに適用できますが、シノニムには適用できません。ポリシーを列に適用するには、DBMS_RLS.ADD_POLICY
プロシージャのSEC_RELEVANT_COLS
パラメータを使用して、セキュリティ関連の列を指定します。このパラメータによって、問合せで列が明示的または暗黙的に参照されるたびに、セキュリティ・ポリシーが適用されます。
たとえば、人事部門以外のユーザーは、通常、各自の社会保障番号を参照することのみが許可されます。販売担当者が次の問合せを開始するとします。
SELECT fname, lname, ssn FROM emp;
セキュリティ・ポリシーを実装する関数は述語ssn='my_ssn'
を戻します。Oracle Databaseは次のように問合せをリライトして実行します。
SELECT fname, lname, ssn FROM emp WHERE ssn = 'my_ssn';
親トピック: ポリシーを使用した列データ表示の制御
11.3.6.2 例: 列レベルのOracle Virtual Private Databaseポリシーの作成
CREATE FUNCTION文およびDBMS_RLS.ADD_POLICYプロシージャで、列レベルのOracle Virtual Private Databaseポリシーを構成できます。
例11-3は、営業部門(部門番号30)のユーザーは他部門の従業員の給与を参照できないというOracle Virtual Private Databaseポリシーを示します。このポリシーに関連する列は、sal
およびcomm
です。最初にOracle Virtual Private Databaseポリシー関数を作成し、次にDBMS_RLS
PL/SQLパッケージを使用して追加します。
例11-3 列レベルのOracle Virtual Private Databaseポリシーの作成
CREATE OR REPLACE FUNCTION hide_sal_comm ( v_schema IN VARCHAR2, v_objname IN VARCHAR2) RETURN VARCHAR2 AS con VARCHAR2 (200); BEGIN con := 'deptno=30'; RETURN (con); END hide_sal_comm;
次に、DBMS_RLS.ADD_POLICY
プロシージャを使用して、ポリシーを構成します。
BEGIN
DBMS_RLS.ADD_POLICY (
object_schema => 'scott',
object_name => 'emp',
policy_name => 'hide_sal_policy',
policy_function => 'hide_sal_comm',
sec_relevant_cols => 'sal,comm');
END;
親トピック: ポリシーを使用した列データ表示の制御
11.3.6.3 問合せに関連する列の行のみの表示
デフォルトで、列レベルのOracle Virtual Private Databaseでは、機密情報が含まれた列が問合せで参照された場合、戻される行の数が制限されます。
これらのセキュリティ関連の列を指定するには、例11-3
に示すように、DBMS_RLS.ADD_POLICY
プロシージャのSEC_RELEVANT_COLUMNSパラメータを使用します。
たとえば、営業部門ユーザーはemp
表に対してSELECT
権限を持っており、この表は例11-3で作成された列レベルのOracle Virtual Private Databaseポリシーによって保護されている場合を想定します。ユーザー(たとえば、ユーザーSCOTT
)は次の問合せを実行します。
SELECT ENAME, d.dname, JOB, SAL, COMM FROM emp e, dept d WHERE d.deptno = e.deptno;
データベースは次の行を戻します。
ENAME DNAME JOB SAL COMM ---------- -------------- --------- ---------- ---------- ALLEN SALES SALESMAN 1600 300 WARD SALES SALESMAN 1250 500 MARTIN SALES SALESMAN 1250 1400 BLAKE SALES MANAGER 2850 TURNER SALES SALESMAN 1500 0 JAMES SALES CLERK 950 6 rows selected.
表示されるのは、行のすべての列に対してユーザーがアクセス権を持っている行のみです。
親トピック: ポリシーを使用した列データ表示の制御
11.3.6.4 機密性の高い列をNULL値で表示するための列のマスク
問合せで機密性の高い列を参照する場合、デフォルトの列レベルのOracle Virtual Private Databaseでは、戻される行の数が制限されます。
列のマスク動作を利用すると、機密性の高い列を参照している場合にもすべての行が表示されます。ただし、機密性の高い列はNULL
値で表示されます。列のマスク動作を有効にするには、DBMS_RLS.ADD_POLICYプロシージャの
SEC_RELEVANT_COLS_opt
パラメータを設定します。
たとえば、前述の例に記載されている販売担当者の問合せ結果を考えてみます。列のマスクを使用すると、販売担当者自身の詳細と社会保障番号が格納されている行のみが表示されるのではなく、emp
表からすべての行が表示されますが、ssn
列の値はNULL
になります。この動作は、行のサブセットのみを戻す他のあらゆるタイプのOracle Virtual Private Databaseポリシーとは基本的に異なることに注意してください。
列レベルのOracle Virtual Private Databaseに関するデフォルトのアクションとは対照的に、列のマスク動作ではすべての行が表示されますが、機密情報が含まれた列の値はNULL
として戻されます。ポリシーに列のマスク動作を含めるには、DBMS_RLS.ADD_POLICY
プロシージャのSEC_RELEVANT_COLS_OPT
パラメータをDBMS_RLS.ALL_ROWS
に設定します。
列のマスクに関する考慮事項は次のとおりです。
-
列のマスクが適用されるのは、
SELECT
文に対してのみです。 -
通常のOracle Virtual Private Database述語とは異なり、ポリシー関数によって生成される列マスク条件は、単純なブール式であることが必要です。
-
計算を実行するアプリケーションや、
NULL
値が戻されることが想定されていないアプリケーションの場合は、標準の列レベルのOracle Virtual Private Databaseを使用して、列のマスク動作オプションSEC_RELEVANT_COLS_OPT
ではなくSEC_RELEVANT_COLS
を指定します。 -
オブジェクト・データ型(
XMLtype
を含む)の列をsec_relevant_cols
設定に含めないでください。この列型は、sec_relevant_cols
設定ではサポートされていません。 -
UPDATE AS SELECT
とともに使用される列のマスク動作によって更新されるのは、ユーザーが表示を許可されている列のみです。 -
問合せによっては、列のマスク動作により一部の行が表示されない場合があります。たとえば:
SELECT * FROM emp WHERE sal = 10;
列のマスク動作オプションが設定されているため、
salary
列にNULL
値が戻される場合は、この問合せを実行しても行が戻されない場合があります。
親トピック: ポリシーを使用した列データ表示の制御
11.3.6.5 例: Oracle Virtual Private Databaseポリシーへの列のマスクの追加
DBMS_RLS.ADD_POLICYプロシージャで、列レベルのOracle Virtual Private Database列のマスク動作を構成できます。
例11-4は、列レベルのOracle Virtual Private Database列のマスク動作を示しています。これは、例: 列レベルのOracle Virtual Private Databaseポリシーの作成と同じVPDポリシーを使用していますが、sec_relevant_cols_opt
をDBMS_RLS.ALL_ROWS
として指定しています。
例11-4 Oracle Virtual Private Databaseポリシーへの列のマスクの追加
BEGIN DBMS_RLS.ADD_POLICY( object_schema => 'scott', object_name => 'emp', policy_name => 'hide_sal_policy', policy_function => 'hide_sal_comm', sec_relevant_cols =>' sal,comm', sec_relevant_cols_opt => dbms_rls.ALL_ROWS); END;
emp
表に対するSELECT
権限を持つ営業部門のユーザー(たとえば、SCOTT
)が、次の問合せを実行するとします。
SELECT ENAME, d.dname, job, sal, comm FROM emp e, dept d WHERE d.deptno = e.deptno;
データベースは、この問合せで指定されたすべての行を戻しますが、Oracle Virtual Private Databaseポリシーによって一部の値はマスクされています。
ENAME DNAME JOB SAL COMM ---------- -------------- --------- ---------- ---------- CLARK ACCOUNTING MANAGER KING ACCOUNTING PRESIDENT MILLER ACCOUNTING CLERK JONES RESEARCH MANAGER FORD RESEARCH ANALYST ADAMS RESEARCH CLERK SMITH RESEARCH CLERK SCOTT RESEARCH ANALYST WARD SALES SALESMAN 1250 500 TURNER SALES SALESMAN 1500 0 ALLEN SALES SALESMAN 1600 300 JAMES SALES CLERK 950 BLAKE SALES MANAGER 2850 MARTIN SALES SALESMAN 1250 1400 14 rows selected.
列のマスク動作により、営業部門のユーザーの問合せで要求された列がすべて戻されますが、営業部門以外の従業員に関してはsal
列とcomm
列がNULL
になっています。
親トピック: ポリシーを使用した列データ表示の制御
11.3.7 Oracle Virtual Private Databaseポリシー・グループ
Oracle Virtual Private Databaseポリシー・グループは、アプリケーションに適用できるVPDポリシーの名前付きコレクションです。
- Oracle Virtual Private Databaseポリシー・グループについて
複数のセキュリティ・ポリシーをまとめてグループ化して、1つのアプリケーションに適用できます。 - Oracle Virtual Private Databaseの新しいポリシー・グループの作成
DBMS_RLS.ADD_GROUPED_POLICY
プロシージャで、VPDポリシーをVPDポリシー・グループに追加します。 - SYS_DEFAULTポリシー・グループを使用したデフォルト・ポリシー・グループ
セキュリティ・ポリシーのグループ内で、1つのセキュリティ・ポリシーをデフォルトのセキュリティ・ポリシーになるよう指定できます。 - 各表、ビューまたはシノニムに対する複数のポリシー
同一の表、ビューまたはシノニムに対して複数のポリシーを設定できます。 - データベースへの接続に使用されるアプリケーションの検証
駆動コンテキストを実装するパッケージは、データベースへの接続に使用されるアプリケーションを正しく検証する必要があります。
11.3.7.1 Oracle Virtual Private Databaseポリシー・グループについて
複数のセキュリティ・ポリシーをまとめてグループ化して、1つのアプリケーションに適用できます。
ポリシー・グループとは、アプリケーションに属する一連のセキュリティ・ポリシーです。有効なポリシー・グループを示すようにアプリケーション・コンテキスト(駆動コンテキストまたはポリシー・コンテキストと呼ばれます)を指定できます。ユーザーが表、ビュー、またはシノニム列にアクセスすると、Oracle Databaseが駆動コンテキストを検索して、有効なポリシー・グループを特定します。ポリシー・グループに属しているすべての関連ポリシーが適用されます。
ポリシー・グループは、複数のセキュリティ・ポリシーを持つ複数のアプリケーションが同一の表、ビューまたはシノニムを共有する場合に便利です。ポリシー・グループによって、表、ビューまたはシノニムがアクセスされたときに有効にするポリシーを識別できます。
たとえば、ホスト環境で、A社が、B社およびC社に対してBENEFIT
表をホスティングするとします。この表は、2つの異なるセキュリティ・ポリシーを持つ、Human Resources(人事管理)およびFinance(財務管理)という2つアプリケーションによってアクセスされます。Human Resourcesアプリケーションは社内の序列に基づいてユーザーを認可し、Financeアプリケーションは部門に基づいてユーザーを認可します。これらの2つのポリシーをBENEFIT
表に統合するには、2つの企業が共同でポリシーを開発する必要がありますが、それは現実的ではありません。ベース・オブジェクトに一連の特定のポリシーを規定するアプリケーション・コンテキストを定義することにより、各アプリケーションがセキュリティ・ポリシーの集合を個別に実装できます。
これを行うには、セキュリティ・ポリシーをグループ化します。アプリケーション・コンテキストを参照することにより、実行時に有効にするポリシーのグループをOracle Databaseが判断します。サーバーは、そのポリシー・グループに属するすべてのポリシーを規定します。
11.3.7.2 Oracle Virtual Private Databaseの新しいポリシー・グループの作成
DBMS_RLS.ADD_GROUPED_POLICY
プロシージャで、VPDポリシーをVPDポリシー・グループに追加します。
有効にするポリシーを指定するには、DBMS_RLS.ADD_POLICY_CONTEXT
プロシージャを使用して駆動コンテキストを追加できます。駆動コンテキストが不明なポリシー・グループを戻した場合は、エラーが戻されます。
駆動コンテキストが定義されていない場合は、すべてのポリシーが実行されます。同様に、駆動コンテキストがNULL
である場合は、すべてのポリシー・グループのポリシーが規定されます。データにアクセスするアプリケーションは、セキュリティ設定モジュール(アプリケーション・コンテキストを設定するモジュール)を回避できないため、該当するすべてのポリシーが適用されます。
同一の表、ビューまたはシノニムに複数の駆動コンテキストを適用して、それぞれを個別に処理できます。これによって、複数のアクティブなポリシーを設定して規定できます。
たとえば、福利厚生アプリケーションと財務アプリケーションをホスティングするホスト企業があり、これらのアプリケーションが、いくつかのデータベース・オブジェクトを共有している場合を想定します。この2つのアプリケーションは、SYS_DEFAULT
ポリシー・グループのSUBSCRIBER
ポリシーを使用して、ホスティング用にストライプ化されます。データ・アクセスは、最初にサブスクライバIDごとにパーティション化され、次に、ユーザーが福利厚生アプリケーションと財務アプリケーションのどちらにアクセスしているか(駆動コンテキストによって決定される)によってパーティション化されます。ホスティング・サービスを使用するA社が、自社のデータ・アクセスにのみ関連したカスタム・ポリシーを適用するとします。この場合は、駆動コンテキスト(COMPANY A SPECIAL
など)を追加して、追加の特殊ポリシー・グループの適用をA社のデータ・アクセスのみに限定できます。このポリシーはA社のみに関連しているため、SUBSCRIBER
ポリシーの下では適用できません。基本的なホスティング・ポリシーは、他のポリシーから分離した方がより効率的です。
11.3.7.3 SYS_DEFAULTポリシー・グループを使用したデフォルト・ポリシー・グループ
セキュリティ・ポリシーのグループ内で、1つのセキュリティ・ポリシーをデフォルトのセキュリティ・ポリシーになるよう指定できます。
これは、セキュリティ・ポリシーをアプリケーション別に分割して常に有効になるようにする場合に便利です。デフォルト・セキュリティ・ポリシーを使用すると、開発者はすべての条件下で基礎となるセキュリティを規定できます。一方、アプリケーションごとにセキュリティ・ポリシーを分割(セキュリティ・グループを使用)すると、デフォルト・セキュリティ・ポリシーにアプリケーション固有のセキュリティ・レイヤーを追加できます。デフォルト・セキュリティ・ポリシーを実装するには、このデフォルト・セキュリティ・ポリシーをSYS_DEFAULT
ポリシー・グループに追加します。
このグループ内に定義されている、特定の表、ビューまたはシノニムに対するポリシーは、駆動コンテキストが指定するポリシー・グループとともに実行されます。前述のとおり、駆動コンテキストは、有効なポリシー・グループを指定するアプリケーション・コンテキストです。SYS_DEFAULT
ポリシー・グループには、ポリシーが含まれる場合と含まれない場合があります。SYS_DEFAULT
ポリシー・グループは削除できません。このポリシー・グループを削除すると、Oracle Databaseでエラーが発生します。
SYS_DEFAULT
ポリシー・グループに、複数のオブジェクトに対応付けられているポリシーを追加する場合、各オブジェクトには個別にSYS_DEFAULT
ポリシー・グループが対応付けられます。たとえば、scott
スキーマのemp
表に1つのSYS_DEFAULT
ポリシー・グループがある場合、scott
スキーマのdept
表には別のSYS_DEFAULT
ポリシー・グループが対応付けられます。これは、次のようにツリー構造に編成されます。
SYS_DEFAULT - policy1 (scott/emp) - policy3 (scott/emp) SYS_DEFAULT - policy2 (scott/dept)
同一の名前を持つ複数のポリシー・グループを作成できます。特定のポリシー・グループを選択すると、対応付けられているスキーマとオブジェクト名が、画面右側のプロパティ・シートに表示されます。
11.3.7.4 各表、ビューまたはシノニムに対する複数のポリシー
同一の表、ビューまたはシノニムに対して複数のポリシーを設定できます。
たとえば、受注用の基本アプリケーションがあり、社内の各部門にはそれぞれ独自のデータ・アクセス規則があるとします。基本アプリケーションのポリシー関数を作成しなおさなくても、部門固有のポリシー関数を表に追加できます。
表に適用されるすべてのポリシーは、AND
構文で規定されます。そのため、CUSTOMERS
表に3つのポリシーを適用している場合、各ポリシーが表に適用されます。データにアクセスするアプリケーションに応じて異なるポリシーが適用されるように、ポリシー・グループおよびアプリケーション・コンテキストを使用して、ファイングレイン・アクセス・コントロールの規定を分割できます。これによって、開発グループ間でポリシーを調整する必要がなくなり、アプリケーションの開発が容易になります。また、常に適用する(たとえば、ホスト環境でサブスクライバによりデータ分割を規定する)デフォルト・ポリシー・グループを保持することもできます。
11.3.7.5 データベースへの接続に使用されるアプリケーションの検証
駆動コンテキストを実装するパッケージは、データベースへの接続に使用されるアプリケーションを正しく検証する必要があります。
Oracle Databaseは、コール・スタックをチェックして、駆動コンテキストを実装するパッケージによるコンテキスト属性の設定を確認しますが、パッケージ内では不適切な検証が発生する可能性があります。たとえば、データベース・ユーザーまたはエンタープライズ・ユーザーがデータベースに認識されているアプリケーションの場合、ユーザーには、駆動コンテキストを設定するパッケージに対するEXECUTE
権限が必要です。BENEFITS
アプリケーションの方がHR
アプリケーションよりもアクセスが自由であることを理解しているユーザーについて考えてみます。(正しいポリシー・グループを駆動コンテキスト内に設定する)setctx
プロシージャでは、実際に接続しているアプリケーションを判断するための検証が実行されないこと。つまり、このプロシージャでは、(3層システムに対する)着信接続のIPアドレス、またはユーザー・セッションのproxy_user
属性がチェックされないこと。
ユーザーは、アクセスがより自由なBENEFITS
ポリシー・グループにコンテキストを設定する引数を駆動コンテキスト・パッケージに渡してから、かわりにHR
アプリケーションにアクセスできます。setctx
ではアプリケーションに対してそれ以上の検証を行わないため、このユーザーは限定的なHRセキュリティ・ポリシーをバイパスしてしまいます。
一方、Oracle Virtual Private Databaseによるプロキシ認証を実装すると、ユーザーのかわりにデータベースに接続する中間層(およびアプリケーション)の識別情報を確認できます。これによって、データ・アクセスを仲介するアプリケーションごとに正しいポリシーが適用されます。
たとえば、開発者は、プロキシ認証機能を使用して、データベースに接続しているアプリケーション(中間層)がHRAPPSERVER
であることを確認できます。このように、駆動コンテキストを実装するパッケージでは、ユーザー・セッションのproxy_user
がHRAPPSERVER
かどうかを検証できます。その場合、HR
ポリシー・グループを使用するよう駆動コンテキストを設定できます。proxy_user
がHRAPPSERVER
でない場合は、アクセスを拒否できます。
このような場合に、次の問合せが実行されるとします。
SELECT * FROM apps.benefit;
Oracle Databaseは、デフォルト・ポリシー・グループ(SYS_DEFAULT
)およびアクティブなネームスペースHR
のポリシーを選択します。この問合せは、内部で次のようにリライトされます。
SELECT * FROM apps.benefit WHERE company = SYS_CONTEXT('ID','MY_COMPANY') AND SYS_CONTEXT('ID','TITLE') = 'MANAGER';
11.3.8 Oracle Virtual Private Databaseポリシー・タイプを使用したパフォーマンスの最適化
Oracle Virtual Private Database (VPD)の動的、静的または共有ポリシー・タイプを使用して、パフォーマンスを最適化できます。
- Oracle Virtual Private Databaseポリシー・タイプについて
ポリシーのポリシー・タイプを指定すると、Oracle Virtual Private Databaseポリシーの実行パフォーマンスを最適化できます。 - ポリシー関数の自動再実行のための動的ポリシー・タイプ
DYNAMIC
ポリシー・タイプを指定すると、ユーザーが仮想プライベート・データベースで保護されたデータベース・オブジェクトにアクセスするたびに、ポリシー関数が実行されます。 - 例: DBMS_RLS.ADD_POLICYを使用したDYNAMICポリシーの作成
DBMS_RLS.ADD_POLICY
プロシージャで、動的なOracle Virtual Private Databaseポリシーを作成できます。 - ポリシー関数の問合せごとの再実行を回避するための静的ポリシー
静的ポリシー・タイプを指定すると、インスタンス内のすべてのユーザーに対して同じ述語が規定されます。 - 例: DBMS_RLS.ADD_POLICYを使用した静的ポリシーの作成
DBMS_RLS.ADD_POLICY
プロシージャで、静的なOracle Virtual Private Database (VPD)ポリシーを作成できます。 - 例: 複数オブジェクト間でポリシーを共有するための共有の静的ポリシー
複数オブジェクト間でポリシーを共有するために、DBMS_RLS.ADD_POLICY
プロシージャで共有の静的Oracle Virtual Private Databaseポリシーを作成できます。 - 静的ポリシーおよび共有の静的ポリシーを使用する場合
静的ポリシーは、すべての問合せに同じ述語が必要で、高いパフォーマンスが不可欠なホスト環境などに最適です。 - 変更されるアプリケーション・コンテキスト属性の状況依存ポリシー
状況依存ポリシーは、どの述語が問合せを実行しているかに応じて異なる述語を適用する必要がある場合に便利です。 - 例: DBMS_RLS.ADD_POLICYを使用した状況依存ポリシーの作成
DBMS_RLS.ADD_POLICY
プロシージャで、Oracle Virtual Private Database状況依存ポリシーを作成できます。 - 例: VPD状況依存ポリシーのキャッシュされた文のリフレッシュ
DBMS_RLS.REFRESH_POLICY文で、Oracle Virtual Private Database状況依存ポリシーのキャッシュされた文をリフレッシュできます。 - 例: 既存の状況依存ポリシーの変更
DBMS_RLS.ALTER_POLICY
プロシージャで、Oracle Virtual Private Databaseポリシーを変更できます。 - 例: 共有の状況依存ポリシーの使用による複数オブジェクト間でのポリシーの共有
複数オブジェクトがあるポリシーを共有するために、DBMS_RLS.ADD_POLICY
プロシージャを使用して、共有の状況依存のOracle Virtual Private Databaseポリシーを作成できます。 - 状況依存ポリシーおよび共有の状況依存ポリシーを使用する場合
状況依存ポリシーは、ユーザー・セッションごとに述語を変える必要はないが、ポリシーが異なるユーザーまたはグループに複数の異なる述語を規定する必要がある場合に使用します。 - 5種類のOracle Virtual Private Databaseポリシー・タイプの要約
Oracle Virtual Private Databaseには、ユーザーのニーズ(ホスト環境での使用など)に基づいて、5種類のポリシー・タイプが用意されています。
11.3.8.1 Oracle Virtual Private Databaseポリシー・タイプについて
ポリシーのポリシー・タイプを指定すると、Oracle Virtual Private Databaseポリシーの実行パフォーマンスを最適化できます。
ポリシー・タイプを使用して、Oracle DatabaseがOracle Virtual Private Databaseポリシーの述語をキャッシュする方法を制御します。ポリシー関数を実行すると、システム・リソースを大量に消費する場合があるため、ポリシーに対してポリシー・タイプを設定することを検討してください。ポリシー関数の実行回数を最小限に抑えることで、データベースのパフォーマンスを最適化できます。
選択できるポリシー・タイプは、DYNAMIC
、STATIC
、SHARED_STATIC
、CONTEXT_SENSITIVE
およびSHARED_CONTEXT_SENSITIVE
の5種類です。これらのポリシー・タイプによって、ポリシーの述語を変更する頻度を正確に指定できます。ポリシー・タイプを指定するには、DBMS_RLS.ADD POLICY
プロシージャのpolicy_type
パラメータを設定します。
11.3.8.2 ポリシー関数の自動再実行のための動的ポリシー・タイプ
DYNAMIC
ポリシー・タイプを指定すると、ユーザーが仮想プライベート・データベースで保護されたデータベース・オブジェクトにアクセスするたびに、ポリシー関数が実行されます。
DBMS_RLS.ADD_POLICY
プロシージャにポリシー・タイプを指定しない場合、ポリシーはデフォルトで動的になります。ポリシーを動的に構成するには、DBMS_RLS.ADD_POLICY
プロシージャのpolicy_type
パラメータをDYNAMIC
に設定します。
動的ポリシー・タイプでは、静的ポリシーや状況依存ポリシー・タイプの場合と異なり、データベースのパフォーマンスは最適化されません。ただし、ポリシーを静的または状況依存に設定する前に、その都度実行されるDYNAMIC
ポリシー・タイプでテストすることをお薦めします。最初にポリシー関数をDYNAMIC
ポリシーでテストすると、何もキャッシュされていないため、ポリシー関数が各問合せに与える影響を調べることができます。これにより、パフォーマンスを最適化するために静的ポリシーまたは状況依存ポリシーを使用可能にする前に、関数が正常に機能することを確認できます。
文の実行開始時間と終了時間を測定するには、DBMS_UTILITY.GET_TIME
関数を使用します。たとえば:
-- 1. Get the start time: SELECT DBMS_UTILITY.GET_TIME FROM DUAL; GET_TIME ---------- 2312721 -- 2. Run the statement: SELECT COUNT(*) FROM HR.EMPLOYEES; COUNT(*) ---------- 107 -- 3. Get the end time: SELECT DBMS_UTILITY.GET_TIME FROM DUAL; GET_TIME ---------- 2314319
11.3.8.3 例: DBMS_RLS.ADD_POLICYを使用したDYNAMICポリシーの作成
DBMS_RLS.ADD_POLICY
プロシージャで、動的なOracle Virtual Private Databaseポリシーを作成できます。
例11-5に、DYNAMIC
ポリシー・タイプの作成方法を示します。
例11-5 DBMS_RLS.ADD_POLICYを使用したDYNAMICポリシーの作成
BEGIN DBMS_RLS.ADD_POLICY( object_schema => 'hr', object_name => 'employees', policy_name => 'secure_update', policy_function => 'hide_fin', policy_type => dbms_rls.DYNAMIC); END; /
11.3.8.4 ポリシー関数の問合せごとの再実行を回避するための静的ポリシー
静的ポリシー・タイプを指定すると、インスタンス内のすべてのユーザーに対して同じ述語が規定されます。
Oracle Databaseでは静的ポリシーの述語がSGAに格納されるため、ポリシー関数は問合せごとに再実行されません。その結果、パフォーマンスが向上します。
静的ポリシーを使用可能にするには、そのポリシーを複数のオブジェクト間で共有するかどうかに応じて、DBMS_RLS.ADD_POLICY
プロシージャのpolicy_type
パラメータをSTATIC
またはSHARED_STATIC
のいずれかに設定します。
述語が同じでも、同じカーソルを実行するたびに異なる行セットが生成される場合があります。これは、述語によるデータのフィルタ処理がSYS_CONTEXT
やSYSDATE
などの属性によって異なるためです。
たとえば、ポリシーをSTATIC
またはSHARED_STATIC
ポリシー・タイプとして使用可能にする場合を想定します。この場合は、ポリシーで保護されたデータベース・オブジェクトに対して実行されるすべての問合せに次の述語が追加されます。
WHERE dept = SYS_CONTEXT ('hr_app','deptno')
述語は、問合せごとに変わりませんが、SYS_CONTEXT
のセッション属性に基づいて問合せに適用されます。前述の例の述語では、ポリシーで保護されたデータベース・オブジェクトを問い合せているユーザーの部門番号がSYS_CONTEXT
のdeptno
属性と一致する行のみを戻します。
ノート:
共有の静的ポリシーを使用する場合は、ポリシーの述語に、列名など特定のデータベース・オブジェクト固有の属性が含まれていないことを確認してください。
11.3.8.5 例: DBMS_RLS.ADD_POLICYを使用した静的ポリシーの作成
DBMS_RLS.ADD_POLICY
プロシージャで、静的なOracle Virtual Private Database (VPD)ポリシーを作成できます。
例11-6に、STATIC
ポリシー・タイプの作成方法を示します。
例11-6 DBMS_RLS.ADD_POLICYを使用した静的ポリシーの作成
BEGIN DBMS_RLS.ADD_POLICY( object_schema => 'hr', object_name => 'employees', policy_name => 'secure_update', policy_function => 'hide_fin', policy_type => DBMS_RLS.STATIC); END; /
11.3.8.6 例: 複数オブジェクト間でポリシーを共有するための共有の静的ポリシー
複数オブジェクト間でポリシーを共有するために、DBMS_RLS.ADD_POLICY
プロシージャで共有の静的Oracle Virtual Private Databaseポリシーを作成できます。
たとえば、使用する財務データを含むHR
スキーマの2番目の表に例11-6のポリシーを適用する場合、両方の表でSHARED_STATIC
設定を使用します。
例11-7に、同じポリシーを共有する2つの表に対してSHARED_STATIC
ポリシー・タイプを設定する方法を示します。
例11-7 複数オブジェクト間でポリシーを共有するための共有の静的ポリシーの作成
-- 1. Create a policy for the first table, employees: BEGIN DBMS_RLS.ADD_POLICY( object_schema => 'hr', object_name => 'employees', policy_name => 'secure_update', policy_function => 'hide_fin', policy_type => dbms_rls.SHARED_STATIC); END; / -- 2. Create a policy for the second table, fin_data: BEGIN DBMS_RLS.ADD_POLICY( object_schema => 'hr', object_name => 'fin_data', policy_name => 'secure_update', policy_function => 'hide_fin', policy_type => dbms_rls.SHARED_STATIC); END; /
11.3.8.7 静的ポリシーおよび共有の静的ポリシーを使用する場合
静的ポリシーは、すべての問合せに同じ述語が必要で、高いパフォーマンスが不可欠なホスト環境などに最適です。
このような環境では、ポリシー関数がすべての問合せに同じ述語を追加すると、ポリシー関数を再実行するたびに不要なオーバーヘッドがシステムに加わります。たとえば、競争相手である複数の顧客企業に関する市場調査データが含まれたデータ・ウェアハウスを考えてみます。このウェアハウスでは、各企業が自社の市場調査データのみを参照できるポリシーを規定する必要があり、このポリシーは次の述語で表現されます。
WHERE subscriber_id = SYS_CONTEXT('customer', 'cust_num')
アプリケーション・コンテキストに対してSYS_CONTEXT
を使用すると、データベースでは、戻される行を動的に変更できます。関数を再実行する必要はなく、述語はSGAにキャッシュされるため、システム・リソースを節約でき、パフォーマンスが向上します。
11.3.8.8 変更されるアプリケーション・コンテキスト属性の状況依存ポリシー
状況依存ポリシーは、どの述語が問合せを実行しているかに応じて異なる述語を適用する必要がある場合に便利です。
たとえば、マネージャには述語WHERE group
がmanagers
に設定され、従業員には述語WHERE empno_ctx
がemp_id
に設定される場合を考えてみます。状況依存ポリシーでは、マネージャのログイン時にマネージャが確認する必要がある情報のみ表示し、従業員のログイン時に従業員が確認する必要がある情報のみ表示できます。このポリシーは、アプリケーション・コンテキストを使用して、使用する述語を決定します。
静的ポリシーとは対照的に、状況依存ポリシーは必ずしも述語をキャッシュしません。状況依存ポリシーの場合、データベースでは、述語は文の解析後に変更されると想定しています。ただし、ローカル・アプリケーション・コンテキストに変更がない場合、Oracle Databaseはユーザー・セッション内でポリシー関数を再実行しません。ユーザー・セッション中にアプリケーション・コンテキストの属性の変更がある場合、デフォルトでは、データベースはポリシー関数を再実行して、初期解析からの述語へのすべての変更を取得していることを確認します。これにより、関連付けられている属性が変更されていない場合、ポリシー関数の再実行が必要なくなります。namespace
およびattribute
パラメータを含めて、特定のアプリケーション・コンテキストへの評価を制限できます。
ポリシーでnamespace
およびattribute
パラメータを使用する場合、次のガイドラインに従います。
-
1つだけではなく
namespace
およびattribute
パラメータの両方を指定していることを確認します。 -
ポリシーに
DBMS_RLS.CONTEXT_SENSITIVE
またはSHARED_CONTEXT_SENSITIVE
に設定されているpolicy_type
引数があることを確認します。静的または動的ポリシーのnamespace
およびattribute
パラメータを使用できません。
仮想プライベート・データベースのポリシー関数に関連付けられている属性がない場合、Oracle Databaseは、アプリケーション・コンテキストの変更の状況依存関数を評価します。
共有の状況依存ポリシーは、複数のデータベース・オブジェクト間で共有できる点を除いて、通常の状況依存ポリシーと同じように動作します。このポリシー・タイプの場合、すべてのオブジェクトがUGAのポリシー関数を共有でき、この場合、述語はローカル・セッション・コンテキストが変更されるまでキャッシュされます。
11.3.8.9 例: DBMS_RLS.ADD_POLICYを使用した状況依存ポリシーの作成
DBMS_RLS.ADD_POLICY
プロシージャで、Oracle Virtual Private Database状況依存ポリシーを作成できます。
例11-8は、empno_ctx
ネームスペースおよびemp_id
属性への変更のみにポリシーが評価されるCONTEXT_SENSITIVE
ポリシーの作成方法を示しています。
例11-8 DBMS_RLS.ADD_POLICYを使用した状況依存ポリシーの作成
BEGIN DBMS_RLS.ADD_POLICY( object_schema => 'hr', object_name => 'employees', policy_name => 'secure_update', policy_function => 'hide_fin', policy_type => dbms_rls.CONTEXT_SENSITIVE, namespace => 'empno_ctx', attribute => 'emp_id'); END; /
11.3.8.10 例: VPD状況依存ポリシーのキャッシュされた文のリフレッシュ
DBMS_RLS.REFRESH_POLICY文で、Oracle Virtual Private Database状況依存ポリシーのキャッシュされた文をリフレッシュできます。
例11-9は、DBMS_RLS.REFRESH_POLICY
プロシージャを実行して仮想プライベート・データベースの状況依存ポリシーに関連付けられているすべてのキャッシュされた文を手動でリフレッシュできることを示しています。
例11-9 VPD状況依存ポリシーのキャッシュされた文のリフレッシュ
BEGIN DBMS_RLS.REFRESH_POLICY( object_schema => 'hr', object_name => 'employees', policy_name => 'secure_update'); END; /
11.3.8.11 例: 既存の状況依存ポリシーの変更
DBMS_RLS.ALTER_POLICY
プロシージャで、Oracle Virtual Private Databaseポリシーを変更できます。
例11-10は、関連するコンテキスト属性が変更される場合にのみorder_update_pol
ポリシー関数を実行するためにDBMS_RLS.ALTER_POLICY
文を使用して既存の状況依存ポリシーを変更する方法を示しています。
例11-10 既存の状況依存ポリシーの変更
BEGIN DBMS_RLS.ALTER_POLICY( object_schema => 'oe', object_name => 'orders', policy_name => 'order_update_pol', alter_option => DBMS_RLS.ADD_ATTRIBUTE_ASSOCIATION, namespace => 'empno_ctx', attribute => 'emp_role'); END; /
11.3.8.12 例: 共有の状況依存ポリシーの使用による複数オブジェクト間でのポリシーの共有
複数オブジェクトがあるポリシーを共有するために、DBMS_RLS.ADD_POLICY
プロシージャを使用して、共有の状況依存のOracle Virtual Private Databaseポリシーを作成できます。
例11-11は、複数の表でポリシーを共有する2つの共有の状況依存ポリシーを作成する方法およびempno_ctx
ネームスペースおよびemp_id
属性への変更のみに評価を制限する方法を示しています。
例11-11 DBMS_RLS.ADD_POLICYを使用した共有の状況依存ポリシー
-- 1. Create a policy for the first table, employees: BEGIN DBMS_RLS.ADD_POLICY( object_schema => 'hr', object_name => 'employees', policy_name => 'secure_update', policy_function => 'hide_fin', policy_type => dbms_rls.SHARED_CONTEXT_SENSITIVE, namespace => 'empno_ctx', attribute => 'emp_id'); END; / --2. Create a policy for the second table, fin_data: BEGIN DBMS_RLS.ADD_POLICY( object_schema => 'hr', object_name => 'fin_data', policy_name => 'secure_update', policy_function => 'hide_fin', policy_type => dbms_rls.SHARED_CONTEXT_SENSITIVE, namespace => 'empno_ctx', attribute => 'emp_id'); END; /
次のことに注意してください。
-
共有の状況依存ポリシーを使用する場合は、ポリシーの述語に、列名など特定のデータベース・オブジェクト固有の属性が含まれていないことを確認してください。
-
仮想プライベート・データベースの共有の状況依存ポリシーに関連付けられているすべてのキャッシュされた文を手動でリフレッシュするには、
DBMS_RLS.REFRESH_GROUPED_POLICY
プロシージャを実行します。
11.3.8.13 状況依存ポリシーおよび共有の状況依存ポリシーを使用する場合
状況依存ポリシーは、ユーザー・セッションごとに述語を変える必要はないが、ポリシーが異なるユーザーまたはグループに複数の異なる述語を規定する必要がある場合に使用します。
たとえば、単一のポリシーを持つsales_history
表を考えてみます。このポリシーでは、アナリストは自分の製品のみを参照でき、地域担当者は自分の地域のみを参照できます。この場合、データベースは、ユーザーのタイプが変わるたびにポリシー関数を再実行する必要があります。サーバーによるポリシー関数の再実行なしに、ユーザーがログインして保護されたオブジェクトに対していくつかのDML文を発行できる場合は、パフォーマンスが向上します。
ノート:
複数のクライアントが1つのデータベース・セッションを共有するセッション・プーリングの場合は、クライアント切替え時に中間層でコンテキストを再設定する必要があります。
11.3.8.14 5種類のOracle Virtual Private Databaseポリシー・タイプの要約
Oracle Virtual Private Databaseには、ユーザーのニーズ(ホスト環境での使用など)に基づいて、5種類のポリシー・タイプが用意されています。
表11-2に、使用可能なポリシー・タイプの要約を示します。
表11-2 DBMS_RLS.ADD_POLICYのポリシー・タイプ
ポリシー・タイプ | ポリシー関数の実行 | 使用例 | 複数オブジェクト間での共有 |
---|---|---|---|
|
ポリシーで保護されたデータベース・オブジェクトがアクセスされるたびに、ポリシー関数を再実行します。 |
日中の特定時間は、ユーザーによるデータベース・オブジェクトへのアクセスを拒否する時間依存のポリシーなど、ポリシーの述語を問合せごとに生成する必要があるアプリケーション。 |
いいえ |
|
1回。それから述語はSGAにキャッシュされます脚注 1 |
ビューの置換 |
いいえ |
|
|
同じ述語を複数のデータベース・オブジェクトに適用する必要があるデータ・ウェアハウスなどのホスト環境。 |
はい |
|
|
ポリシーによって異なるユーザーまたはグループに複数の述語が規定される、3層セッション・プーリング・アプリケーション。 |
いいえ |
|
データベース・セッションで最初にオブジェクトが参照されたとき。 述語はプライベート・セッション・メモリーであるUGAにキャッシュされるため、ポリシー関数を複数のオブジェクト間で共有できます。 |
|
はい |
脚注1
述語が同じでも、同じカーソルを実行するたびに異なる行セットが生成される場合があります。これは、述語によるデータのフィルタ処理がSYS_CONTEXT
やSYSDATE
などの属性によって異なるためです。
11.4 例: Oracle Virtual Private Databaseポリシーの作成
このチュートリアルでは、簡単なデータベース・セッション・ベースのOracle Virtual Privateポリシーの作成方法と、ポリシー・グループの作成方法を説明します。
- 例: 単純なOracle Virtual Private Databaseポリシーの作成
このチュートリアルでは、OE
ユーザー・アカウントを使用して単純なOracle Virtual Private Databaseポリシーを作成する方法を説明します。 - チュートリアル: セッション・ベースのアプリケーション・コンテキスト・ポリシーの実装
このチュートリアルでは、データベース・セッション・ベースのアプリケーション・コンテキストを使用するOracle Virtual Private Databaseポリシーの作成方法を示します。 - 例: Oracle Virtual Private Databaseポリシー・グループの実装
このチュートリアルでは、Oracle Virtual Private Databaseポリシー・グループの作成方法を示します。
11.4.1 例: 単純なOracle Virtual Private Databaseポリシーの作成
このチュートリアルでは、OE
ユーザー・アカウントを使用して単純なOracle Virtual Private Databaseポリシーを作成する方法を説明します。
- このチュートリアルについて
このチュートリアルでは、アクセスを営業担当者159が作成したOE.ORDERS
表内の受注に制限するVPDポリシーの作成方法を示します。 - ステップ1: OEユーザー・アカウントがアクティブであることの確認
まず、OE
ユーザー・アカウントが有効であることを確認する必要があります。 - ステップ2: ポリシー関数の作成
次に、ポリシー関数を作成します。 - ステップ3: Oracle Virtual Private Databaseポリシーの作成
ポリシー関数の作成後、その関数をVPDポリシーに関連付けます。 - ステップ4: ポリシーのテスト
Oracle Virtual Private Databaseポリシーを作成した直後に、ポリシーは有効になります。 - ステップ5: このチュートリアルのコンポーネントの削除
このチュートリアルのコンポーネントが不要になった場合、それらを削除できます。
11.4.1.1 このチュートリアルについて
このチュートリアルでは、アクセスを営業担当者159が作成したOE.ORDERS
表内の受注に制限するVPDポリシーの作成方法を示します。
このポリシーは、基本的に次の文で表現されます。
SELECT * FROM OE.ORDERS;
この文を次のように変換します。
SELECT * FROM OE.ORDERS WHERE SALES_REP_ID = 159;
ノート:
マルチテナント環境を使用している場合、このチュートリアルは現在のPDBのみに適用されます。
11.4.1.3 ステップ2: ポリシー関数の作成
次に、ポリシー関数を作成します。
ユーザーSYS
として、次の関数を作成します。この関数はWHERE SALES_REP_ID = 159
句を、OE.ORDERS
表の任意のSELECT
文に追加します。(最初の行のCREATE OR REPLACE
の前にカーソルを置くことで、このテキストをコピーして貼り付けることができます。)
CREATE OR REPLACE FUNCTION auth_orders(
schema_var IN VARCHAR2,
table_var IN VARCHAR2
)
RETURN VARCHAR2
IS
return_val VARCHAR2 (400);
BEGIN
return_val := 'SALES_REP_ID = 159';
RETURN return_val;
END auth_orders;
/
この例では、次のようになります。
-
schema_var
およびtable_var
は、スキーマ名(OE
)および表名(ORDERS
)を格納するために指定する入力パラメータを作成します。最初に、スキーマ用のパラメータを定義し、次に、オブジェクト(この例では表)用のパラメータを定義します。パラメータは常にこの順序で作成します。作成する仮想プライベート・データベース・ポリシーでは、OE.ORDERS
表を指定するためにこれらのパラメータが必要です。 -
RETURN VARCHAR2
は、WHERE
述語句に使用される文字列を返します。戻り値は常にVARCHAR2
データ型になります。 -
IS ... RETURN return_val
は、WHERE SALES_REP_ID = 159
述語の作成が含まれます。
11.4.1.4 ステップ3: Oracle Virtual Private Databaseポリシーの作成
ポリシー関数の作成後、その関数をVPDポリシーに関連付けます。
-
DBMS_RLS
パッケージのADD_POLICY
プロシージャを使用して、次のポリシーを作成します。BEGIN DBMS_RLS.ADD_POLICY ( object_schema => 'oe', object_name => 'orders', policy_name => 'orders_policy', function_schema => 'sys', policy_function => 'auth_orders', statement_types => 'select' ); END; /
この例では、次のようになります。
-
object_schema => 'oe'
は、保護するスキーマ(この例ではOE
)を指定します。 -
object_name => 'orders'
は、保護するスキーマ内のオブジェクト(この例ではORDERS
表)を指定します。 -
policy_name => 'orders_policy'
は、このポリシーの名前をorders_policy
と指定します。 -
function_schema => 'sys'
は、auth_orders
関数が作成されたスキーマを指定します。この例では、auth_orders
はSYS
スキーマに作成されています。ただし、通常は、セキュリティ管理者のスキーマに作成する必要があります。 -
policy_function => 'auth_orders'
は、ポリシーを規定する関数を指定します。この例では、「ステップ2: ポリシー関数の作成」で作成したauth_orders
関数を指定します。 -
statement_types => 'select'
は、ポリシーを適用する操作を指定します。この例では、ユーザーが実行するすべてのSELECT
文にポリシーが適用されます。
-
11.4.1.5 ステップ4: ポリシーのテスト
Oracle Virtual Private Databaseポリシーを作成した直後に、ポリシーは有効になります。
ユーザー(スキーマの所有者を含む)が次にOE.ORDERS
に対してSELECT
文を実行すると、営業担当者159の受注のみにアクセスできます。
11.4.2 チュートリアル: セッション・ベースのアプリケーション・コンテキスト・ポリシーの実装
このチュートリアルでは、データベース・セッション・ベースのアプリケーション・コンテキストを使用するOracle Virtual Private Databaseポリシーの作成方法を示します。
- このチュートリアルについて
この例では、データベース・セッション・ベースのアプリケーション・コンテキストを使用して、顧客が自分の注文のみを参照できるというポリシーを実装する方法を示しています。 - ステップ1: ユーザー・アカウントとサンプル表の作成
まず、ユーザー・アカウントとサンプル表を作成します。 - ステップ2: データベース・セッション・ベースのアプリケーション・コンテキストの作成
次に、データベース・セッション・ベースのアプリケーション・コンテキストを作成します。 - ステップ3: アプリケーション・コンテキストを設定するPL/SQLパッケージの作成
アプリケーション・コンテキストの作成後、パッケージを作成してコンテキストを設定します。 - ステップ4: アプリケーション・コンテキストのPL/SQLパッケージを実行するログイン・トリガーの作成
ログイン・トリガーがPL/SQLパッケージ・プロシージャを実行し、次回のユーザー・ログイン時にアプリケーション・コンテキストが設定されるようにします。 - ステップ5: ログイン・トリガーのテスト
ログイン・トリガーは、sysadmin_vpd.orders_ctx_pkg.set_custnum
プロシージャの実行時に、そのユーザーのアプリケーション・コンテキストを設定します。 - ステップ6: ユーザー・アクセスを自分の注文に制限するPL/SQLポリシー関数の作成
次に、ユーザーの問合せの表示を制御するPL/SQL関数を作成します。 - ステップ7: 新しいセキュリティ・ポリシーの作成
最後に、VPDセキュリティ・ポリシーを作成します。 - ステップ8: 新しいポリシーのテスト
これで、すべてのコンポーネントが作成されたため、ポリシーをテストします。 - ステップ9: このチュートリアルのコンポーネントの削除
このチュートリアルのコンポーネントが不要になった場合、それらを削除できます。
11.4.2.1 このチュートリアルについて
この例では、データベース・セッション・ベースのアプリケーション・コンテキストを使用して、顧客が自分の注文のみを参照できるというポリシーを実装する方法を示しています。
マルチテナント環境を使用している場合、このチュートリアルは現在のPDBのみに適用されます。
このチュートリアルでは、次の層のセキュリティを作成します。
-
ユーザーがログインするとき、データベース・セッション・ベースのアプリケーション・コンテキストによって顧客かどうかがチェックされます。顧客でないユーザーでもログインできますが、このユーザーはこの例で作成する注文表にアクセスできません。
-
ユーザーが顧客の場合はログインできます。顧客がログインした後、Oracle Virtual Private Databaseポリシーによって、このユーザーは自分の注文のみを参照できるように制限されます。
-
さらなる制限として、Oracle Virtual Private Databaseポリシーによって、ユーザーは注文を追加、変更、または削除できなくなります。
11.4.2.2 ステップ1: ユーザー・アカウントとサンプル表の作成
まず、ユーザー・アカウントとサンプル表を作成します。
orders_tab
受注表には、2名のサンプル顧客tbrooke
とowoods
の購買レコードがあります。この段階では、これらの顧客がこの表を参照すると、すべての受注を参照できます。
11.4.2.4 ステップ3: アプリケーション・コンテキストを設定するPL/SQLパッケージの作成
アプリケーション・コンテキストの作成後、パッケージを作成してコンテキストを設定します。
-
ユーザー
sysadmin_vpd
として、次のPL/SQLパッケージを作成します。このパッケージは、顧客tbrooke
およびowoods
がそれぞれのアカウントにログインすると、データベース・セッション・ベースのアプリケーション・コンテキストを設定します。CREATE OR REPLACE PACKAGE orders_ctx_pkg IS PROCEDURE set_custnum; END; / CREATE OR REPLACE PACKAGE BODY orders_ctx_pkg IS PROCEDURE set_custnum AS custnum NUMBER; BEGIN SELECT cust_no INTO custnum FROM SCOTT.CUSTOMERS WHERE cust_email = SYS_CONTEXT('USERENV', 'SESSION_USER'); DBMS_SESSION.SET_CONTEXT('orders_ctx', 'cust_no', custnum); EXCEPTION WHEN NO_DATA_FOUND THEN NULL; END set_custnum; END; /
この例では、次のようになります。
-
custnum NUMBER
は、顧客IDを保持するcustnum
変数を作成します。 -
SELECT cust_no INTO custnum
は、SELECT
文を実行し、scott.customers
表のcust_no
列データに格納されている顧客IDをcustnum
変数にコピーします。 -
WHERE cust_email = SYS_CONTEXT('USERENV', 'SESSION_USER')
は、WHERE
句を使用して、ログインしたユーザーのユーザー名と一致するすべての顧客IDを検索します。 -
DBMS_SESSION.SET_CONTEXT('orders_ctx', 'cust_no', custnum)
は、cust_no
属性を作成した後、custnum
変数に格納されている値に設定することで、orders_ctx
アプリケーション・コンテキストの値を設定します。 -
EXCEPTION ... WHEN
は、WHEN NO_DATA_FOUND
システム例外を追加して、SELECT cust_no INTO custnum ...
文のSELECT
文によって発生した可能性のあるno data found
エラーを捕捉します。
-
要約すると、sysadmin_vpd.set_cust_num
プロシージャは、セッション・ユーザーの顧客IDを選択してcustnum
変数に格納することによって、ユーザーが登録済顧客かどうかを識別します。ユーザーが登録済顧客の場合、Oracle Databaseによってこのユーザーにアプリケーション・コンテキスト値が設定されます。「ステップ6: ユーザー・アクセスを自分の注文に制限するPL/SQLポリシー関数の作成」に示すように、ポリシー関数では、コンテキスト値を使用して、ユーザーがorders_tab
表内のデータに対して持つアクセスを制御します。
11.4.2.5 ステップ4: アプリケーション・コンテキストのPL/SQLパッケージを実行するログイン・トリガーの作成
ログイン・トリガーがPL/SQLパッケージ・プロシージャを実行し、次回のユーザー・ログイン時にアプリケーション・コンテキストが設定されるようにします。
-
ユーザー
sysadmin_vpd
で、次のログイン・トリガーを作成します。CREATE TRIGGER set_custno_ctx_trig AFTER LOGON ON DATABASE BEGIN sysadmin_vpd.orders_ctx_pkg.set_custnum; END; /
11.4.2.6 ステップ5: ログオン・トリガーのテスト
ログイン・トリガーは、sysadmin_vpd.orders_ctx_pkg.set_custnum
プロシージャの実行時に、そのユーザーのアプリケーション・コンテキストを設定します。
11.4.2.7 ステップ6: ユーザー・アクセスを自分の注文に制限するPL/SQLポリシー関数の作成
次のステップは、ユーザーの問合せの表示を制御するPL/SQL関数を作成します。
SELECT * FROM scott.orders_tab
問合せを実行したときに、関数の出力がそのユーザーの発注に制限されるようにします。
この関数は、「表示される注文がログインしたユーザーに属する場合」に変換されるWHERE
述語を作成して返します。それからこのWHERE
述語を、このユーザーがscott.orders_tab
表に対して実行するあらゆる問合せに追加します。問合せが追加されると、この関数をorders_tab
表に適用するOracle Virtual Private Databaseポリシーを作成できます。
11.4.2.8 ステップ7: 新しいセキュリティ・ポリシーの作成
最後に、VPDセキュリティ・ポリシーを作成します。
-
ユーザー
sysadmin_vpd
として、DBMS_RLS.ADD_POLICY
プロシージャを使用して、ポリシーを次のように作成します。BEGIN DBMS_RLS.ADD_POLICY ( object_schema => 'scott', object_name => 'orders_tab', policy_name => 'orders_policy', function_schema => 'sysadmin_vpd', policy_function => 'get_user_orders', statement_types => 'select', policy_type => DBMS_RLS.CONTEXT_SENSITIVE, namespace => 'orders_ctx', attribute => 'cust_no'); END; /
この文は、SCOTT
スキーマで、orders_policy
という名前のポリシーを作成して、顧客が自分の注文について問い合せるためのorders_tab
表に適用します。get_user_orders
関数が実装するこのポリシーは、sysadmin_vpd
スキーマに格納されます。このポリシーは、さらに、ユーザーがSELECT
文のみを発行するように制限します。namespace
およびattribute
パラメータは、以前に作成したアプリケーション・コンテキストを指定します。
11.4.2.9 ステップ8: 新しいポリシーのテスト
これで、すべてのコンポーネントが作成されたため、ポリシーをテストします。
次のことに注意してください。
-
ユーザーの職位に基づいて複数の述語を作成できます。たとえば、営業担当者は自分の担当顧客のレコードのみを参照でき、受注入力担当はすべての顧客注文を参照できます。ユーザーの職位のコンテキスト値に基づいて別の述語を返すように
custnum_sec
機能を拡張できます。 -
ファイングレイン・アクセス・コントロール・パッケージ内でアプリケーション・コンテキストを使用することによって、実際には解析済の文の中にバインド変数が指定されます。たとえば:
SELECT * FROM scott.orders_tab WHERE cust_no = SYS_CONTEXT('order_entry', 'cust_num');
この文は完全に解析および最適化されますが、
order_entry
コンテキストに対するユーザーのcust_num
属性値の評価は、実行時に行われます。これは、最適化された文には、その文を発行するユーザーごとに異なる形態で実行されるという利点があることを意味します。ノート:
この例の関数のパフォーマンスは、
cust_no
に索引を作成するとさらに向上します。 -
コンテキスト属性は、データベース表(複数も可)のデータ、またはLightweight Directory Access Protocol(LDAP)を使用するディレクトリ・サーバーのデータに基づいて設定できます。
ノート:
トリガーの詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。
動的に生成された述語の中でアプリケーション・コンテキストを使用するこの例と、述語の中で副問合せを使用するOracle Virtual Private Databaseポリシーについてを比較してください。
11.4.3 例: Oracle Virtual Private Databaseポリシー・グループの実装
このチュートリアルでは、Oracle Virtual Private Databaseポリシー・グループの作成方法を示します。
- このチュートリアルについて
このチュートリアルでは、Oracle Virtual Private Database (VPD)を使用してポリシー・グループを作成する方法を示します。 - ステップ1: この例で使用するユーザー・アカウントと他のコンポーネントの作成
まず、このチュートリアルのユーザー・アカウントと表を作成し、適切な権限を付与する必要があります。 - ステップ2: 2つのポリシー・グループの作成
次に、2人の非データベース・ユーザーprovider_a
およびprovider_b
にそれぞれポリシー・グループを作成する必要があります。 - ステップ3: ポリシー・グループを制御するPL/SQLファンクションの作成
ポリシー・グループには、ユーザーのデータ・アクセスをアプリケーションでどのように制御するかを定義する関数が必要です。 - ステップ4: 駆動アプリケーション・コンテキストの作成
アプリケーション・コンテキストにより、ログインする非データベース・ユーザーが使用する必要があるポリシーが決定されます。 - ステップ5: PL/SQLファンクションのポリシー・グループへの追加
必要な関数を作成したら、適切なポリシー・グループに関数を関連付ける必要があります。 - ステップ6: ポリシー・グループのテスト
これで、2つのポリシー・グループをテストできます。 - ステップ7: このチュートリアルのコンポーネントの削除
このチュートリアルのコンポーネントが不要になった場合、それらを削除できます。
11.4.3.1 このチュートリアルについて
このチュートリアルでは、Oracle Virtual Private Database (VPD)を使用してポリシー・グループを作成する方法を示します。
アプリケーションで使用する一連のポリシーをグループ化する方法は、「Oracle Virtual Private Databaseのポリシー・グループ」を参照してください。非データベース・ユーザーがアプリケーションにログインすると、Oracle Databaseでは、適切なポリシー・グループ内で定義されたポリシーに基づいてユーザーにアクセス権が付与されます。
列レベルのアクセス制御の場合、各列または非表示の列セットが1つのポリシーで制御されます。この例では、2つの列セットを非表示にする必要があります。そのため、非表示にする列セットごとに1つずつ、2つのポリシーを作成する必要があります。ユーザーごとに必要なポリシーは1つのみのため、駆動アプリケーション・コンテキストによってポリシーが分割されます。
ノート:
マルチテナント環境を使用している場合、このチュートリアルは現在のPDBのみに適用されます。
11.4.3.3 ステップ2: 2つのポリシー・グループの作成
次に、2人の非データベース・ユーザーprovider_a
およびprovider_b
にそれぞれポリシー・グループを作成する必要があります。
11.4.3.4 ステップ3: ポリシー・グループを制御するPL/SQLファンクションの作成
ポリシー・グループには、ユーザーのデータ・アクセスをアプリケーションでどのように制御するかを定義する関数が必要です。
provider_a
とprovider_b
に適用されます。
11.5 他のOracle機能でのOracle Virtual Private Databaseの使用
Oracle Virtual Private DatabaseをOracleの他の機能と併用することの影響を理解しておく必要があります。
- Oracle Virtual Private Databaseポリシーとエディション
エディションを扱う場合のOracle VPDの使用方法について理解しておく必要があります。 - VPD保護表に対するユーザーの問合せでのSELECT FOR UPDATE文
原則として、ユーザーは、Virtual Private Database保護表を問い合せる場合にFOR UPDATE
句を含めないようにします。 - Oracle Virtual Private Databaseポリシーと外部結合またはANSI結合
Oracle Virtual Private Databaseでは、動的ビューを使用して、SQLをリライトします。 - Oracle Virtual Private Databaseセキュリティ・ポリシーとアプリケーション
Oracle Virtual Private Databaseセキュリティ・ポリシーは、アプリケーション内ではなく、データベース内で適用されます。 - ファイングレイン・アクセス・コントロールのポリシー関数に対する自動再解析
各ポリシーに対して最新の述語が使用されるように、ファイングレイン・アクセス・コントロール対応のオブジェクトに対する問合せでポリシー関数が実行されます。 - Oracle Virtual Private Databaseポリシーとフラッシュバック問合せ
データベース上での操作では、直前にコミットされた使用可能データが使用されます。 - Oracle Virtual Private DatabaseとOracle Label Security
Oracle Virtual Private DatabaseとOracle Label Securityは併用できますが、その場合、セキュリティの例外に注意してください。 - EXPDPユーティリティのaccess_methodパラメータを使用したデータのエクスポート
VPDポリシーが定義されているオブジェクトからデータをエクスポートする場合は注意してください。 - ユーザー・モデルとOracle Virtual Private Database
Oracle Virtual Private Databaseは、複数のタイプのユーザー・モデルで使用できます。
11.5.1 Oracle Virtual Private Databaseポリシーとエディション
エディションを扱う場合のOracle VPDの使用方法について理解しておく必要があります。
アプリケーションをエディションベースの再定義用に準備し、アプリケーションで使用される各表をエディショニング・ビューで保護する場合は、これらの表を保護するVirtual Private Databaseポリシーをエディショニング・ビューに移動する必要があります。
エディション付きオブジェクトにVirtual Private Databaseポリシーが付加されている場合、そのオブジェクトが表示されるすべてのエディションにそのポリシーが適用されます。エディション付きオブジェクトが実現化されると、そのオブジェクトに付加されているVPDポリシーが新しい実際のオブジェクトに新たに付加されます。継承されたエディション付きオブジェクトに新たにVPDポリシーを適用すると、そのオブジェクトが実現化されます。
関連項目:
エディションの詳細は、『Oracle Database開発ガイド』を参照してください。
11.5.2 VPD保護表に対するユーザーの問合せでのSELECT FOR UPDATE文
原則として、ユーザーは、Virtual Private Database保護表を問い合せる場合にFOR UPDATE
句を含めないようにします。
Virtual Private Databaseテクノロジは、VPDポリシー関数によって生成されたVPD述語を含むインライン・ビューに対するユーザーの問合せをリライトする処理に基づいています。このため、ビューに対する制限事項はVPD保護表にも同様に適用されます。VPD保護表に対するユーザーの問合せでSELECT
文にFOR UPDATE
句が含まれていると、ほとんどの場合、その問合せは動作しません。ただし、VPDによって生成されたインライン・ビューが非常に単純である場合、ユーザーの問合せが動作することがあります。
関連項目:
SELECT
文のFOR UPDATE
句の制限事項の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
11.5.3 Oracle Virtual Private Databaseポリシーと外部結合またはANSI結合
Oracle Virtual Private Databaseでは、動的ビューを使用して、SQLをリライトします。
SQLに外部結合操作またはANSI操作が含まれていると、一部のビューがマージされない場合や、一部の索引が使用されない場合があります。この問題は既知の最適化制限です。この問題に対処するには、SQLをリライトして外部結合操作やANSI操作が使用されないようにします。
11.5.4 Oracle Virtual Private Databaseセキュリティ・ポリシーとアプリケーション
Oracle Virtual Private Databaseセキュリティ・ポリシーは、アプリケーション内ではなく、データベース内で適用されます。
したがって、ユーザーが異なるアプリケーションを使用してデータにアクセスしようとしても、Oracle Virtual Private Databaseセキュリティ・ポリシーを回避できません。データベースにセキュリティ・ポリシーを作成するもう1つの利点は、複数のアプリケーションで各セキュリティ・ポリシーを保持するのではなく、1箇所でセキュリティ・ポリシーを保持できることです。このため、Oracle Virtual Private Databaseは、アプリケーション・ベースのセキュリティよりも強力なセキュリティを提供し、所有権のコストもより低くなります。
データにアクセスしているアプリケーションに応じて、異なるセキュリティ・ポリシーを規定する必要がある場合があります。Order Entry(受注管理)およびInventory(在庫管理)の2つのアプリケーションが、両方ともorders
表にアクセスする場合を考えてみます。Inventoryアプリケーションで、製品の種類に基づいてアクセスを制限するポリシーを使用するとします。同時に、Order Entryアプリケーションでも、顧客番号に基づいてアクセスを制限するポリシーを使用するとします。
この場合、アプリケーションによるファイングレイン・アクセスの使用を分割する必要があります。分割しないと、2つのポリシーが自動的に連結され、目的とする結果が得られません。複数のポリシー・グループ、および特定のトランザクションに対して有効なポリシー・グループを判断する駆動アプリケーションのコンテキストを指定できます。また、データ・アクセスに対して必ず適用するデフォルト・ポリシーも指定できます。たとえば、ホスティングされたアプリケーションでは、データ・アクセスはサブスクライバIDによって制限されます。
11.5.5 ファイングレイン・アクセス・コントロールのポリシー関数に対する自動再解析
各ポリシーに対して最新の述語が使用されるように、ファイングレイン・アクセス・コントロール対応のオブジェクトに対する問合せでポリシー関数が実行されます。
たとえば、問合せを午前8時から午後5時の間に限定する時間ベースのポリシー関数の場合は、正午にカーソルの実行を解析すると、その時点でこのポリシー関数が実行され、問合せに対してポリシーが再度参照されます。カーソルが午前9時に解析された場合でも、そのカーソルが後で(たとえば、正午に)実行されると、Virtual Private Databaseポリシー関数が再び実行され、カーソルの実行が現時点(正午)でも引き続き許可されるようになります。これにより、常に最新のセキュリティ・チェックが実行されます。
Virtual Private Databaseポリシー関数の自動再実行は、ポリシーを追加するときにDBMS_RLS.ADD_POLICY
設定のSTATIC_POLICY
をTRUE
に設定した場合は行われません。この設定の場合、ポリシー関数は同じ述語を戻します。
11.5.6 Oracle Virtual Private Databaseポリシーとフラッシュバック問合せ
データベース上での操作では、直前にコミットされた使用可能データが使用されます。
フラッシュバック問合せ機能により、過去のどこかの時点でのデータベースの問合せが可能になります。
フラッシュバック問合せを使用するアプリケーションを作成するには、SQL問合せでAS OF
句を使用して、時間とシステム変更番号(SCN)のどちらかを指定して、指定された時間からコミット済データに対して問い合せます。DBMS_FLASHBACK
PL/SQLパッケージを使用することもできます。このPL/SQLパッケージでは必要なコードが増えますが、複数の操作を実行でき、これらの操作のすべてが同じ時点を参照します。
ただし、Oracle Virtual Private Databaseポリシーで保護されているデータベース・オブジェクトに対してフラッシュバック問合せを使用すると、現行のポリシーが過去のデータに適用されます。現行のOracle Virtual Private Databaseポリシーをフラッシュバック問合せのデータに適用すると、最新のビジネス・ポリシーが反映されるため、安全性が高まります。
関連項目:
-
フラッシュバック問合せ機能、およびフラッシュバック問合せを使用するアプリケーションの作成方法の詳細は、『Oracle Database開発ガイド』を参照してください。
-
DBMS_FLASHBACK
PL/SQLパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
11.5.7 Oracle Virtual Private DatabaseとOracle Label Security
Oracle Virtual Private DatabaseとOracle Label Securityは併用できますが、その場合、セキュリティの例外に注意してください。
- Oracle Virtual Private Databaseを使用したOracle Label Securityポリシーの規定
Oracle Virtual Private Databaseポリシーを使用して、Oracle Label Securityユーザー認可に基づいて列または行レベルのアクセス制御を提供できます。 - Oracle Virtual Private DatabaseおよびOracle Label Securityの例外
Oracle Virtual Private DatabaseおよびOracle Label Securityを使用する場合は、セキュリティ例外に注意してください。
11.5.7.1 Oracle Virtual Private Databaseを使用したOracle Label Securityポリシーの規定
Oracle Virtual Private Databaseポリシーを使用して、Oracle Label Securityユーザー認可に基づいて列または行レベルのアクセス制御を提供できます。
一般に、次のステップを実行する必要があります。
-
Oracle Label Securityのポリシーを作成したら、保護する必要がある表にこのポリシーを適用しないでください。(作成した仮想プライベート・データベース・ポリシーによって自動的に処理されます。)
SA_SYSDBA.CREATE_POLICY
プロシージャで、default_options
パラメータをNO_CONTROL
に設定します。 -
Oracle Label Securityのラベル・コンポーネントを作成し、通常どおりユーザーを認可します。
-
Oracle Virtual Private Databaseポリシーを作成する際には、次の操作を行います。
-
ポリシーについて作成するPL/SQLファンクションでは、Oracle Label Securityの
DOMINATES
ファンクションを使用して、ユーザーの認可をステップ2で作成したラベルと比較します。DOMINATES
ファンクションにより、ユーザーの認可が比較で使用されたラベルと等しい、またはラベルより機密性が高いかどうかが判別されます。ユーザー認可が通過した場合、ユーザーは列に対するアクセス権を付与されます。通過しない場合、ユーザーはアクセスを拒否されます。 -
仮想プライベート・データベース・ポリシー定義で、保護する必要がある表にこのファンクションを適用します。
DBMS_RLS.ADD_POLICY
プロシージャで、機密性の高い列(SEC_RELEVANT_COLS
パラメータ)および列のマスク(SEC_RELEVANT_COLS_OPT
パラメータ)機能を使用して、Oracle Label Securityユーザー認可に基づいて列を表示または非表示にします。
-
関連項目:
支配ファンクションの詳細は、『Oracle Label Security管理者ガイド』を参照してください。11.5.7.2 Oracle Virtual Private DatabaseおよびOracle Label Securityの例外
Oracle Virtual Private DatabaseおよびOracle Label Securityを使用する場合は、次の例外に注意してください。
これらのセキュリティ例外を次に示します。
-
データのエクスポート時、Oracle Virtual Private DatabaseおよびOracle Label Securityのポリシーはダイレクト・パス・エクスポート操作では規定されません。ダイレクト・パス・エクスポート操作では、Oracle Databaseはディスクからバッファ・キャッシュにデータを読み込み、行をエクスポート・クライアントに直接転送します。
-
Oracle Virtual Private DatabaseおよびOracle Label Securityのポリシーは、SYSスキーマのオブジェクトに適用できません。
SYS
ユーザーおよびデータベースにDBA権限でアクセスするユーザー(CONNECT/AS SYSDBA
など)の場合、それらのユーザーのアクションにOracle Virtual Private DatabaseまたはOracle Label Securityのポリシーは適用されません。したがって、データベース・ユーザーSYS
は、データベースからデータを抽出するために使用するエクスポート・モード、アプリケーションまたはユーティリティに関係なく、常にOracle Virtual Private DatabaseまたはOracle Label Securityの規定対象から除外されます。ただし、
SYSDBA
のアクションは、インストール時に監査を有効にし、監査証跡をオペレーティング・システムの保護位置に格納するように指定することによって監査できます。SYS
ユーザーはOracle Database Vaultを使用して詳細に監視できます。 -
EXEMPT ACCESS POLICY権限を直接的またはデータベース・ロールを介して付与されているデータベース・ユーザーは、Oracle Virtual Private Databaseの規定対象から除外されます。システム権限
EXEMPT ACCESS POLICY
を持つユーザーは、すべてのSELECT
またはDML操作(INSERT
、UPDATE
およびDELETE
)において、ファイングレイン・アクセス・コントロール・ポリシーの対象から除外されます。これによって、インストールや、SYS
以外のスキーマを介したデータベースのインポートとエクスポートなどの管理アクティビティが使いやすくなります。ただし、ポリシーを規定する次のオプションは、
EXEMPT ACCESS POLICY
が付与されている場合も規定されます。-
INSERT_CONTROL
、UPDATE_CONTROL
、DELETE_CONTROL
、WRITE_CONTROL
、LABEL_UPDATE
およびLABEL_DEFAULT
-
Oracle Label Securityのポリシーに
ALL_CONTROL
オプションを指定した場合は、READ_CONTROL
およびCHECK_CONTROL
以外のすべてが規定の対象として適用されます。
EXEMPT ACCESS POLICY
は、ファイングレイン・アクセス・コントロールを無効にするため、この権限は、ファイングレイン・アクセス・コントロールの規定を回避する正当な理由を持つユーザーに対してのみ付与する必要があります。この権限はWITH ADMIN OPTION
を使用して付与しないでください。これを使用すると、ユーザーが他のユーザーにEXEMPT ACCESS POLICY
権限を譲渡して、ファイングレイン・アクセス・コントロールを回避する権限が伝播する可能性があります。 -
ノート:
-
EXEMPT ACCESS POLICY
権限は、SELECT
、INSERT
、UPDATE
およびDELETE
などのオブジェクト権限の規定には影響しません。これらのオブジェクト権限は、ユーザーにEXEMPT ACCESS POLICY
権限が付与されている場合も規定されます。 -
Oracle Virtual Private Databaseが使用する
SYS_CONTEXT
値は、フェイルオーバーのためのセカンダリ・データベースには伝播されません。
関連項目:
ダイレクト・パス・エクスポート操作の詳細は、『Oracle Databaseユーティリティ』を参照してください。11.5.8 EXPDPユーティリティのaccess_methodパラメータを使用したデータのエクスポート
VPDポリシーが定義されているオブジェクトからデータをエクスポートする場合は注意してください。
access_method
パラメータがdirect_path
に設定されたOracle Data Pump Export (EXPDP
)ユーティリティを使用して、データをスキーマからエクスポートしようとするとき、このスキーマに仮想プライベート・データベース・ポリシーが定義されているオブジェクトが含まれていると、ORA-31696
エラー・メッセージが表示される場合があり、エクスポート操作は失敗します。
エラー・メッセージは次のとおりです。
ORA-31696: unable to export/import TABLE_DATA:"schema.table" using client specified DIRECT_PATH method
この問題は、スキーマ・レベルのエクスポートを、EXP_FULL_DATABASE
ロールを付与されていないユーザーとして実行する場合にのみ発生します。EXP_FULL_DATABASE
ロールを必要とするフル・データベース・エクスポート時には発生しません。EXP_FULL_DATABASE
ロールにはEXEMPT ACCESS POLICY
システム権限が含まれており、これにより仮想プライベート・データベース・ポリシーが無視されます。
潜在的な問題を見つけるには、EXPDP
起動を再度試してください。ただし、access_method
パラメータをdirect_path
には設定しないでください。かわりに、automatic
とexternal_table
のどちらかを使用してください。潜在的な問題とは、たとえば次のような権限の問題です。
ORA-39181: Only partial table data may be exported due to fine grain access control on "schema_name"."object_name"
関連項目:
データ・ポンプ・エクスポートの使用に関する詳細は、『Oracle Databaseユーティリティ』を参照してください
11.5.9 ユーザー・モデルとOracle Virtual Private Database
Oracle Virtual Private Databaseは、複数のタイプのユーザー・モデルで使用できます。
これらのユーザー・モデルを次に示します。
-
アプリケーション・ユーザーがデータベース・ユーザーでもある場合。Oracle Databaseでは、ユーザーがデータベース・ユーザーか、データベースに認識されないアプリケーション・ユーザーかに関係なく、アプリケーションはユーザーごとにファイングレイン・アクセス・コントロールを規定できます。アプリケーション・ユーザーがデータベース・ユーザーでもある場合、Oracle Virtual Private Databaseは次のように規定されます。ユーザーがデータベースに接続すると、アプリケーションは各セッションに対するアプリケーション・コンテキストを設定します (様々な種類のユーザー・セッション・データを取得するための多くのパラメータを提供する、デフォルトの
USERENV
アプリケーション・コンテキスト・ネームスペースを使用できます)。各セッションは異なるユーザー名で開始されるため、各ユーザーに対して異なるファイングレイン・アクセス・コントロール条件を規定できます。 -
OCIまたはJDBC/OCIを使用したプロキシ認証。プロキシ認証により、ユーザーごとに異なるファイングレイン・アクセス・コントロールが可能になります。これは、各セッション(OCIまたはJDBC/OCI)がそれぞれのアプリケーション・コンテキストを持つ個別のデータベース・セッションであるためです。
-
エンタープライズ・ユーザー・セキュリティと統合されたプロキシ認証。エンタープライズ・ユーザー・セキュリティを使用してプロキシ認証を統合した場合、Oracle Internet Directoryからユーザー・ロールおよび他の属性を取得してOracle Virtual Private Databaseポリシーを規定できます。(さらに、グローバルに初期化されたアプリケーション・コンテキストもこのディレクトリから取得できます。)
-
ユーザーがOne Big Application Userとして接続する場合。すべてのユーザーのかわりにシングル・ユーザーとしてデータベースに接続するアプリケーションでは、ユーザーごとのファイングレイン・アクセス・コントロールを規定できます。この1セッションのユーザーは、「One Big Application User」と呼ばれます。ただし、アプリケーション開発者は、そのセッションのコンテキスト内で、個別のアプリケーション・ユーザー(たとえば、REALUSER)を表す
グローバル・アプリケーション・コンテキスト属性を作成できます。すべてのデータベース・セッションおよびすべての監査レコードはOne Big Application Userに対して作成されますが、各セッションはエンド・ユーザーに応じて異なる属性を保持できます。このモデルは、ユーザーの数が限定されていて、セッションが再利用されないアプリケーションに最適です。このモデルの場合、各セッションは同一のデータベース・ユーザーとして作成されるため、ロールやデータベース監査の範囲が限定されます。
-
Webベースのアプリケーション。Webベースのアプリケーションには、通常は何百人ものユーザーがいます。多数のユーザー要求に対するデータの取得をサポートするためにデータベースへの接続が持続的に行われる場合でも、このような接続は特定のWebベース・ユーザーに固有のものではありません。通常、Webベースのアプリケーションはスケーラビリティを提供するために、ユーザーごとに異なるセッションを保持するのではなく、接続を設定して再利用します。たとえば、WebユーザーJaneおよびAjitが中間層アプリケーションに接続すると、このアプリケーションは、2人のユーザーのかわりに、使用するデータベース・セッションを1つ確立します。通常、JaneもAjitもデータベースには認識されません。アプリケーションが接続するユーザー名を切り替えるため、どの時点でも、セッションを使用しているのはJaneまたはAjitのいずれかです。
Oracle Virtual Private Databaseを使用すると、複数のグローバル・アプリケーション・コンテキストにアクセスする複数の接続が可能になり、接続プーリングが促進されます。この機能によって、個別ユーザー・セッションごとに別々のアプリケーション・コンテキストを確立する必要がなくなります。
表11-3に、Oracle Virtual Private Databaseをユーザー・モデルに適用する方法の要約を示します。
表11-3 様々なユーザー・モデルでのOracle Virtual Private Database
ユーザー・モデル | 個別のデータベース接続 | ユーザーごとの個別アプリケーション・コンテキスト | 単一データベース接続 | アプリケーションによるユーザー名の切替え |
---|---|---|---|---|
アプリケーション・ユーザーがデータベース・ユーザーでもある場合 |
はい |
はい |
いいえ |
いいえ |
OCIまたはJDBC/OCIを使用したプロキシ認証 |
はい |
はい |
いいえ |
いいえ |
エンタープライズ・ユーザー・セキュリティ脚注2と統合されたプロキシ認証 |
いいえ |
いいえ |
はい |
はい |
One Big Application User |
いいえ |
いいえ脚注3 |
いいえ |
はい2 |
Webベースのアプリケーション |
いいえ |
いいえ |
はい |
はい |
脚注2
ユーザー・ロールとその他の属性(グローバルに初期化されたアプリケーション・コンテキストも含む)は、Oracle Internet Directoryから取得してOracle Virtual Private Databaseを規定できます。
脚注3
アプリケーション開発者は、個別アプリケーション・ユーザー(たとえば、REALUSER
)を表すグローバル・アプリケーション・コンテキスト属性を作成できます。その後、この属性を使用して、各セッション属性を制御したり、監査することができます。
11.6 Oracle Virtual Private Databaseのデータ・ディクショナリ・ビュー
Oracle Databaseには、Oracle Virtual Private Databaseポリシーに関する情報を表示するデータ・ディクショナリ・ビューが用意されています。
表11-4に、仮想プライベート・データベース固有のビューを示します
表11-4 VPDポリシーに関する情報を表示するデータ・ディクショナリ・ビュー
ビュー | 説明 |
---|---|
|
現行ユーザーがアクセス可能なオブジェクトに対するすべてのOracle Virtual Private Databaseセキュリティ・ポリシーが表示されます。 |
|
ログインしたユーザーがVPDポリシーの所有者であるか、VPDポリシーが |
|
現行ユーザーがアクセス可能なシノニム、表およびビューに定義されている駆動コンテキストが表示されます。駆動コンテキストは、Oracle Virtual Private Databaseポリシーで使用されるアプリケーション・コンテキストです。 |
|
現行ユーザーがアクセス可能なシノニム、表およびビューに定義されているOracle Virtual Private Databaseポリシー・グループが表示されます。 |
|
現行ユーザーがアクセス可能な表とビューに対するセキュリティ・ポリシーのセキュリティ関連列が表示されます。 |
|
データベース内のすべてのOracle Virtual Private Databaseセキュリティ・ポリシーが表示されます。 |
|
状況依存および共有の状況依存仮想プライベート・データベース・ポリシーのすべてのアプリケーション・コンテキスト・ネームスペース、属性および仮想プライベート・データベース・ポリシーの関連付けが表示されます。 |
|
データベース内のすべてのポリシー・グループが表示されます。 |
|
データベース内のすべての駆動コンテキストが表示されます。このビューの列は、 |
|
データベース内のすべてのセキュリティ・ポリシーのセキュリティ関連列が表示されます。 |
|
統合監査およびファイングレイン監査のために、 |
|
現行ユーザーが所有するオブジェクトに対応付けられたすべてのOracle Virtual Private Databaseセキュリティ・ポリシーが表示されます。このビューには |
|
仮想プライベート・データベース・ポリシーの所有者が現在のユーザーである場合のすべてのアプリケーション・コンテキスト・ネームスペース、属性および仮想プライベート・データベース・ポリシーの関連付けが表示されます。 |
|
現行ユーザーが所有するシノニム、表およびビューに定義されている駆動コンテキストが表示されます。このビューの列は、 |
|
現行ユーザーが所有している表とビューに対するセキュリティ・ポリシーのセキュリティ関連列が表示されます。このビューの列は、 |
|
現行ユーザーが所有するシノニム、表およびビューに定義されているポリシー・グループが表示されます。このビューには |
|
現在のPDBの場合、現在ライブラリ・キャッシュにキャッシュされているカーソルに対応付けられた、すべてのファイングレイン・セキュリティ・ポリシーと述語が表示されます。このビューは、SQL文に適用されたポリシーを検索するのに便利です。 |
ヒント:
仮想プライベート・データベース・ポリシーを使用するアプリケーションでエラーが見つかった場合は、これらのビューに加え、データベース・トレース・ファイルも確認してください。USER_DUMP_DEST
初期化パラメータは、トレース・ファイルの現在の位置を示します。このパラメータの値は、SQL*PlusでSHOW PARAMETER USER_DUMP_DEST
を発行して確認できます。
関連項目:
-
これらのビューの詳細は、『Oracle Databaseリファレンス』を参照してください。
-
トレース・ファイルの詳細は、『Oracle Database SQLチューニング・ガイド』を参照してください。