戻る次へこのページのスクリプトの内容はナビゲーション目的であり、その内容は変更されません。Databaseを使用したデータ・アクセスの制御この章の内容は、次のとおりです。Databaseの概要この項の内容は、次のとおりです。Database(VPD)を使用すると、行および列レベルでデータベース・アクセスを制御するセキュリティ・ポリシーを作成できます。Databaseのセキュリティ・ポリシーが適用された表、ビューまたはシノニムに対して発行されるSQL文に、動的なWHERE句が追加されます。Databaseを使用すると、データベース表、ビューまたはシノニムに対するセキュリティを直接詳細なレベルまで規定できます。これらのデータベース・オブジェクトにセキュリティ・ポリシーを直接付加すると、ユーザーがデータにアクセスするたびにポリシーが自動的に適用されるため、セキュリティを回避できません。DatabaseはユーザーのSQL文を動的に変更します。この変更は、セキュリティ・ポリシーを実装する関数によって戻されたWHERE条件(述語)に基づいて行われます。Databaseでは、関数内に記述された条件、または関数が戻す条件を使用して、動的かつユーザーに対して透過的にSQL文が変更されます。Databaseポリシーは、SELECT、INSERT、UPDATE、INDEXおよびDELETE文に適用できます。ユーザーが次の問合せを実行するとします。Databaseポリシーにより、WHERE句の文が動的に追加されます。159;この例では、ユーザーは営業担当者159の受注のみを表示できます。このユーザーのセッション情報(ユーザーのIDなど)に基づいてユーザーをフィルタ処理する場合は、WHERE句を作成してアプリケーション・コンテキストを使用できます。TABLE文)のフィルタ処理はサポートされていません。Databaseポリシーを使用するメリットは、次のとおりです。Databaseセキュリティ・ポリシーをデータベース表、ビューまたはシノニムに付加すると、次のようなメリットがあります。データベース表、ビューまたはシノニムにポリシーを対応付けることで、アプリケーション・セキュリティの重大な問題を解決できます。アプリケーションの使用を許可されているユーザーが、そのアプリケーションに対応付けられている権限を利用し、SQL*Plusなどの非定型の問合せツールを使用してデータベースを誤って変更してしまう可能性があります。ファイングレイン・アクセス・コントロールでは、セキュリティ・ポリシーを表、ビューまたはシノニムに直接付加することによって、ユーザーがどのような方法でデータにアクセスしても、同じセキュリティが施行されます。セキュリティ・ポリシーは、表ベース、ビュー・ベースまたはシノニム・ベースのアプリケーションごとに繰り返し追加するのではなく、表、ビューまたはシノニムに1回のみ追加します。SELECT文には1つのセキュリティ・ポリシーを、INSERT文には別のポリシーを、さらにUPDATE文およびDELETE文にはまた別のポリシーを指定できます。人事部門の担当者には、その部門内のすべての社員のレコードに対するSELECT権限を付与し、名字がAからFで始まるその部門内の社員の給与のみを更新できるように指定できます。各表、ビューまたはシノニムに対して複数のポリシーを作成できます。Databaseによるポリシー関数の評価方法の制御ポリシー関数を複数回実行すると、パフォーマンスに影響を与える可能性があります。Database述語をキャッシュする方法を構成することによって、ポリシー関数のパフォーマンスを制御できます。次のオプションがあります。各問合せについてポリシーを1回評価します(静的ポリシー)。ポリシー関数内のアプリケーション・コンテキストが変更された場合のみ、ポリシーを評価します(状況依存ポリシー)。実行ごとにポリシーを評価します(動的ポリシー)。Databaseポリシー・タイプを使用したパフォーマンスの最適化」を参照してください。ポリシー関数は、定義者権限で宣言されたかのように実行されます。実行者権限として宣言するとユーザーおよび他のコード保守管理者を混乱させてしまうため、実行者権限では宣言しないでください。PL/SQL言語リファレンス』を参照してください。Databaseポリシーでは、アプリケーション・コンテキストを使用できます。アプリケーション・コンテキストを作成すると、ユーザー情報が安全にキャッシュされます。キャッシュ環境を設定できるのは、指定されたアプリケーション・パッケージのみです。ユーザーまたはパッケージ外部では変更できません。データがキャッシュされるため、パフォーマンスが向上します。アプリケーション・コンテキストの詳細は、第6章「アプリケーション・コンテキストを使用したユーザー情報の取得」を参照してください。ORDERS_TAB表へのアクセスを顧客ID番号を基にして行うとします。顧客ID番号が必要になるたびにログインしたユーザーに問い合せるのではなく、アプリケーション・コンテキスト内に顧客ID番号を格納しておくことができます。このようにすると、顧客番号は必要なときにセッションで使用できます。アプリケーション・コンテキストは、セキュリティ・ポリシーが複数のセキュリティ属性に基づく場合に特に役立ちます。)に基づくポリシー関数は、この情報を取得するために複数の副問合せを実行する必要があります。このデータがアプリケーション・コンテキストを介して使用可能な場合、パフォーマンスは大きく向上します。アプリケーション・コンテキストを使用すると、述語により規定される正しいセキュリティ・ポリシーを戻すことができます。「顧客は自分の注文のみを参照でき、社員はすべての顧客のすべての注文を参照できる」というルールを規定している受注管理アプリケーションを考えてみます。この場合は、2つの異なるポリシーがあります。position属性でアプリケーション・コンテキストを定義できます。この属性はポリシー関数内でアクセスでき、その属性の値に基づいて正しい述語を戻します。そのため、職位がclerk(社員)であるユーザーはすべての注文を取得できるようにし、customer(顧客)であるユーザーは自分に関連するレコードのみ参照できるようにすることができます。属性に対して特定の述語を戻すファイングレイン・アクセス・コントロール・ポリシーを設計するには、ポリシーを実装する関数内でアプリケーション・コンテキストにアクセスする必要があります。顧客が自分のレコードのみを参照するように制限する必要があるとします。ユーザーは次の問合せを実行します。orders_tabファイングレイン・アクセス・コントロールによって、この問合せはWHERE述語が含まれるように動的に変更されます。'cust_num');前述の例で、50,000人の顧客が存在し、各顧客が受け取る述語を同じにするとします。すべての顧客は同一のWHERE述語を共有し、自分の注文のみを参照できます。顧客間で異なるのは、顧客番号のみです。アプリケーション・コンテキストを使用すると、50,000人の顧客に適用するポリシー関数内で、1つのWHERE述語を戻すことができます。その結果、1つの共有カーソルが、顧客ごとに異なる形態で実行されます。これは、実行時に顧客番号が評価されるためです。この値は、顧客ごとに異なります。このようなアプリケーション・コンテキストの使用によって、最適なパフォーマンスに加えて行レベルのセキュリティが得られます。SYS_CONTEXT関数がバインド変数のように動作するのは、SYS_CONTEXT引数が定数の場合のみです。Databaseを実装するには、動的なWHERE句を生成する関数、および保護するオブジェクトにその関数を付加するポリシーを作成する必要があります。動的なWHERE句(述語)を生成するには、規定する制限を定義した関数(プロシージャではなく)を作成する必要があります。通常は、セキュリティ管理者が自分のスキーマにこの関数を作成します。別の関数のコールを含めたり、ログイン失敗を追跡するためのチェックを追加するなど、複雑な動作が必要な場合は、これらの関数を1つのパッケージ内に作成します。関数では、次の動作が必要です。引数としてスキーマ名、入力としてオブジェクト(表、ビューまたはシノニム)名を取る必要があります。これらの情報を保持するように入力パラメータを定義しますが、関数内でスキーマ名とオブジェクト名自体を指定しないでください。DBMS_RLSパッケージ(「保護するオブジェクトに関数を付加するポリシーの作成」を参照)を使用して作成したポリシーによって、スキーマ名、およびポリシーが適用されるオブジェクトが提供されます。最初にスキーマのパラメータを作成し、その後にオブジェクトのパラメータを作成する必要があります。生成するWHERE句述語の戻り値を提供する必要があります。WHERE句の戻り値は、常にVARCHAR2データ型です。有効なWHERE句を生成する必要があります。Databaseポリシーの作成」に示すように基本的なもので、WHERE句はログインするすべてのユーザーに共通です。ほとんどの場合、各ユーザー、ユーザーの各グループ、または保護するオブジェクトにアクセスする各アプリケーションに異なるWHERE句を設計する必要があります。マネージャがログインする場合は、そのマネージャの権限に固有のWHERE句を生成できます。これを行うには、ユーザー・セッション情報にアクセスするアプリケーション・コンテキストをWHERE句の生成コードに組み込みます。データベース・セッション・ベースのアプリケーション・コンテキストを使用したポリシーの実装」で説明します。Databaseポリシーを作成できます。様々なタイプのアプリケーション・コンテキストの詳細は、第6章「アプリケーション・コンテキストを使用したユーザー情報の取得」を参照してください。CまたはJavaコールを埋め込み、オペレーティング・システム情報にアクセスしたり、オペレーティング・システム・ファイルや他のソースからWHERE句を戻すことができます。Databaseポリシーを作成する必要があります。ポリシーは、DBMS_RLSパッケージを使用して作成します。SYS以外のユーザーがDBMS_RLSパッケージを使用するには、EXECUTE権限が付与されている必要があります。このパッケージには、ポリシーを管理してファイングレイン・アクセス・コントロールを設定できるプロシージャが含まれています。ポリシーを表に付加するには、DBMS_RLS.ADD_POLICYプロシージャを使用します。この設定内でファイングレイン・アクセス・コントロールを設定します。ユーザーが表またはビューに対してSELECTまたはUPDATE文を発行するとポリシーが有効になるように設定します。Databaseポリシーの作成とは、関数を作成し、その関数を表またはビューに適用することを意味します。Databaseポリシーの作成」を参照してください。Databaseポリシーの構成」を参照してください。Databaseポリシーの構成この項の内容は、次のとおりです。DatabaseのWHERE句のアクションを定義する関数を作成した後は、VPDアクションを適用するデータベース表にその関数を対応付ける必要があります。Databaseポリシーを構成します。ポリシーとは、仮想プライベート・データベース関数を管理するメカニズムです。ポリシーを使用すると、ファイングレイン・アクセス・コントロールを追加できるため、たとえば、SQL文のタイプを指定したり、特定の表列にポリシーを適用できます。ユーザーがこのデータベース・オブジェクト内のデータにアクセスすると、ポリシーが自動的に有効になります。ここでは、ポリシーを表、ビューおよびシノニムに付加する一般的な方法について説明します。Databaseポリシーを管理するには、DBMS_RLSパッケージを使用します。PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。表7-1に、DBMS_RLSパッケージに含まれているプロシージャを示します。個別ポリシーの処理用DBMS_RLS.ADD_POLICY表、ビューまたはシノニムにポリシーを追加します。DBMS_RLS.ENABLE_POLICY表、ビューまたはシノニムに事前に追加したポリシーを使用可能または使用禁止にします。DBMS_RLS.REFRESH_POLICY静的ポリシー以外のポリシーに対応付けられたカーソルを無効にします。DBMS_RLS.DROP_POLICY表、ビューまたはシノニムからポリシーを削除します。グループ・ポリシーの処理用DBMS_RLS.CREATE_POLICY_GROUPポリシー・グループを作成します。DBMS_RLS.DELETE_POLICY_GROUPポリシー・グループを削除します。DBMS_RLS.ADD_GROUPED_POLICY特定のポリシー・グループにポリシーを追加します。DBMS_RLS.ENABLE_GROUPED_POLICYグループ内のポリシーを使用可能にします。DBMS_RLS.REFRESH_GROUPED_POLICYリフレッシュされたポリシーに対応付けられたSQL文を再解析します。DBMS_RLS.DISABLE_GROUPED_POLICYグループ内のポリシーを使用禁止にします。DBMS_RLS.DROP_GROUPED_POLICY特定のグループに属するポリシーを削除します。アプリケーション・コンテキストの処理用DBMS_RLS.ADD_POLICY_CONTEXTアクティブなアプリケーションのコンテキストを追加します。DBMS_RLS.DROP_POLICY_CONTEXTアプリケーションのコンテキストを削除します。Databaseポリシーのコンポーネント」を参照してください。Databaseポリシーでアプリケーション・コンテキストを使用する場合は(ほとんどの場合に使用します)、第6章「アプリケーション・コンテキストを使用したユーザー情報の取得」を参照してください。Databaseポリシーの作成」を参照してください。データベース表、ビューまたはシノニムへのポリシーの付加ポリシーを表、ビューまたはシノニムに付加するには、DBMS_RLS.ADD_POLICYプロシージャを使用します。ポリシーを追加する表、ビューまたはシノニム、およびポリシーの名前を指定する必要があります。INDEX)など、その他の情報も指定できます。DatabaseポリシーをHR.EMPLOYEES表に付加する方法を示します。ポリシーに付加される関数はcheck_updatesです。'check_updates',...関数がパッケージ内に作成されている場合は、パッケージ名を指定します。'pkg.check_updates',...注意:表へのポリシーの定義は可能ですが、表に定義されたポリシーから表を選択することはできません。Databaseポリシーは、SELECT、INSERT、UPDATE、INDEXおよびDELETE文に規定できます。DatabaseではデフォルトでSELECT、INSERT、UPDATEおよびDELETEが指定されますが、INDEXは指定されません。DBMS_RLS.ADD_POLICYプロシージャのstatement_typesパラメータを使用して、これらの文の組合せを入力します。リストは一重引用符で囲みます。例7-2に、ポリシーに対してSELECT文とINDEX文を指定する方法を示します。'SELECT,INDEX');END;重要:索引をメンテナンスする権限を持つユーザーは、表に対する完全なアクセス権がない場合でも、SELECTなど通常の問合せですべての行データを参照できます。ユーザーは、関数の引数として列値を持つユーザー定義関数が含まれたファンクション索引を作成できます。Databaseはすべての行の列値をユーザー関数に渡します。これによって、索引を作成するユーザーは行データを使用できるようになります。Databaseポリシーを規定できます。ポリシーを使用した列データ表示の制御セキュリティに関連する列が問合せで参照される際に行レベルのセキュリティを規定するポリシーを作成できます。列レベルのポリシーによって、セキュリティに関連する列が問合せで参照される際の行レベルのセキュリティを規定できます。Databaseポリシーは、表やビューに適用できますが、シノニムには適用できません。ポリシーを列に適用するには、DBMS_RLS.ADD_POLICYプロシージャのsec_relevant_colsパラメータを使用して、セキュリティ関連の列を指定します。このパラメータによって、問合せで列が明示的または暗黙的に参照されるたびに、セキュリティ・ポリシーが適用されます。人事部門以外のユーザーは、通常、各自の社会保障番号を参照することのみが許可されます。販売担当者が次の問合せを開始するとします。emp;セキュリティ・ポリシーを実装する関数は述語ssn='my_ssn'を戻します。Databaseは次のように問合せをリライトして実行します。Databaseポリシーを示します。このポリシーに関連する列は、salおよびcommです。PL/SQLパッケージを使用して追加します。hide_sal_comm;次に、DBMS_RLS.ADD_POLICYプロシージャを使用して、ポリシーを構成します。Databaseに関するデフォルトの動作では、機密情報が含まれた列を参照する問合せから戻される行の数を制限します。例7-3に示すように、セキュリティ関連の列は、DBMS_RLS.ADD_POLICYプロシージャのsec_relevant_colsパラメータを使用して指定します。emp表に対するSELECT権限を持つ営業部門のユーザーを考えてみます。Databaseポリシーで保護されています。ユーザーSCOTT)は次の問合せを実行します。e.deptno;データベースは次の行を戻します。selected.表示されるのは、行のすべての列に対してユーザーがアクセス権を持っている行のみです。Databaseのデフォルト動作では、戻される行の数が制限されます。列のマスク動作を利用すると、機密性の高い列を参照している場合にもすべての行が表示されます。機密性の高い列はNULL値で表示されます。列のマスク動作を有効にするには、DBMS_RLS.ADD_POLICYプロシージャのsec_relevant_cols_optパラメータを設定します。前述の例に記載されている販売担当者の問合せ結果を考えてみます。列のマスクを使用すると、販売担当者自身の詳細と社会保障番号が格納されている行のみが表示されるのではなく、emp表からすべての行が表示されますが、ssn列の値はNULLになります。Databaseポリシーとは基本的に異なることに注意してください。Databaseに関するデフォルトのアクションとは対照的に、列のマスク動作ではすべての行が表示されますが、機密情報が含まれた列の値はNULLとして戻されます。ポリシーに列のマスク動作を含めるには、DBMS_RLS.ADD_POLICYプロシージャのsec_relevant_cols_optパラメータをdbms_rls.ALL_ROWSに設定します。Databaseに関する列のマスク動作を示します。例7-3と同じVPDポリシーを使用しますが、sec_relevant_cols_optはdbms_rls.ALL_ROWSとして指定されています。dbms_rls.ALL_ROWS);END;emp表に対するSELECT権限を持つ営業部門のユーザー(たとえば、SCOTT)が、次の問合せを実行するとします。Databaseポリシーによって一部の値はマスクされています。selected.列のマスク動作により、営業部門のユーザーの問合せで要求された列がすべて戻されますが、営業部門以外の従業員に関してはsal列とcomm列がNULLになっています。列のマスク動作には次の考慮事項が適用されます。列のマスクが適用されるのは、SELECT文に対してのみです。Database述語とは異なり、ポリシー関数によって生成される列マスク条件は、単純なブール式であることが必要です。Databaseを使用して、列のマスク動作オプションsec_relevant_cols_optではなくsec_relevant_colsを指定します。SELECTとともに使用される列のマスク動作によって更新されるのは、ユーザーが表示を許可されている列のみです。問合せによっては、列のマスク動作により一部の行が表示されない場合があります。10;列のマスク動作オプションが設定されているため、salary列にNULL値が戻される場合は、この問合せを実行しても行が戻されない場合があります。複数のセキュリティ・ポリシーをグループ化して、そのグループをアプリケーションに適用できます。この項の内容は、次のとおりです。Databaseポリシー・グループの実装」ポリシー・グループの概要ポリシー・グループは、1つのアプリケーションに属する一連のセキュリティ・ポリシーです。アプリケーション・コンテキスト(駆動コンテキストまたはポリシー・コンテキスト)を指定して、有効なポリシー・グループを指定できます。Databaseは駆動コンテキストを検索し、有効なポリシー・グループを判断します。Databaseは、そのポリシー・グループに属するすべての関連ポリシーを規定します。ポリシー・グループは、複数のセキュリティ・ポリシーを持つ複数のアプリケーションが同一の表、ビューまたはシノニムを共有する場合に便利です。ポリシー・グループによって、表、ビューまたはシノニムがアクセスされたときに有効にするポリシーを識別できます。ホスト環境で、A社が、B社およびC社に対してBENEFIT表をホスティングするとします。Resources(人事管理)およびFinance(財務管理)という2つアプリケーションによってアクセスされます。Resourcesアプリケーションは社内の序列に基づいてユーザーを認可し、Financeアプリケーションは部門に基づいてユーザーを認可します。これらの2つのポリシーをBENEFIT表に統合するには、2つの企業が共同でポリシーを開発する必要がありますが、それは現実的ではありません。ベース・オブジェクトに一連の特定のポリシーを規定するアプリケーション・コンテキストを定義することにより、各アプリケーションがセキュリティ・ポリシーの集合を個別に実装できます。これを行うには、セキュリティ・ポリシーをグループ化します。Databaseが判断します。サーバーは、そのポリシー・グループに属するすべてのポリシーを規定します。表、ビューまたはシノニムにポリシーを追加するには、DBMS_RLS.ADD_GROUPED_POLICYプロシージャを使用して、そのポリシーが属するグループを指定します。有効にするポリシーを指定するには、DBMS_RLS.ADD_POLICY_CONTEXTプロシージャを使用して駆動コンテキストを追加できます。駆動コンテキストが不明なポリシー・グループを戻した場合は、エラーが戻されます。駆動コンテキストが定義されていない場合は、すべてのポリシーが実行されます。同様に、駆動コンテキストがNULLである場合は、すべてのポリシー・グループのポリシーが規定されます。データにアクセスするアプリケーションは、セキュリティ設定モジュール(アプリケーション・コンテキストを設定するモジュール)を回避できないため、該当するすべてのポリシーが適用されます。同一の表、ビューまたはシノニムに複数の駆動コンテキストを適用して、それぞれを個別に処理できます。これによって、複数のアクティブなポリシーを設定して規定できます。福利厚生アプリケーションと財務アプリケーションをホスティングするホスト企業があり、これらのアプリケーションが、いくつかのデータベース・オブジェクトを共有している場合を考えてみます。この2つのアプリケーションは、SYS_DEFAULTポリシー・グループのSUBSCRIBERポリシーを使用して、ホスティング用にストライプ化されます。データ・アクセスは、最初にサブスクライバIDごとにパーティション化され、次に、ユーザーが福利厚生アプリケーションまたは財務アプリケーションのどちらにアクセスしているか(駆動コンテキストによって決定される)によってパーティション化されます。ホスティング・サービスを使用するA社が、自社のデータ・アクセスにのみ関連したカスタム・ポリシーを適用するとします。SPECIALなど)を追加して、特別な追加のポリシー・グループの適用先をA社のデータ・アクセスのみに限定できます。このポリシーはA社のみに関連しているため、SUBSCRIBERポリシーの下では適用できません。基本的なホスティング・ポリシーは、他のポリシーから分離した方がより効率的です。SYS_DEFAULTポリシー・グループを使用したデフォルト・ポリシー・グループの指定セキュリティ・ポリシーのグループ内で、1つのセキュリティ・ポリシーをデフォルト・セキュリティ・ポリシーに指定できます。これは、アプリケーションごとにセキュリティ・ポリシーを分割して、セキュリティ・ポリシーを常に有効にする場合に便利です。デフォルト・セキュリティ・ポリシーを使用すると、開発者はすべての条件下で基礎となるセキュリティを規定できます。アプリケーションごとにセキュリティ・ポリシーを分割(セキュリティ・グループを使用)すると、デフォルト・セキュリティ・ポリシーにアプリケーション固有のセキュリティ・レイヤーを追加できます。デフォルト・セキュリティ・ポリシーを実装するには、SYS_DEFAULTポリシー・グループにポリシーを追加してください。このグループ内に定義されている、特定の表、ビューまたはシノニムに対するポリシーは、駆動コンテキストが指定するポリシー・グループとともに実行されます。前述のとおり、駆動コンテキストは、有効なポリシー・グループを指定するアプリケーション・コンテキストです。SYS_DEFAULTポリシー・グループには、ポリシーが含まれる場合と含まれない場合があります。SYS_DEFAULTポリシー・グループは削除できません。Databaseでエラーが発生します。SYS_DEFAULTポリシー・グループに、複数のオブジェクトに対応付けられているポリシーを追加する場合、各オブジェクトには個別にSYS_DEFAULTポリシー・グループが対応付けられます。scottスキーマのemp表に1つのSYS_DEFAULTポリシー・グループがある場合、scottスキーマのdept表には別のSYS_DEFAULTポリシー・グループが対応付けられます。これは、次のようにツリー構造に編成されます。(scott/dept)同一の名前を持つ複数のポリシー・グループを作成できます。特定のポリシー・グループを選択すると、対応付けられているスキーマとオブジェクト名が、画面右側のプロパティ・シートに表示されます。同一の表、ビューまたはシノニムに対して複数のポリシーを設定できます。受注用の基本アプリケーションがあり、社内の各部門にはそれぞれ独自のデータ・アクセス規則があるとします。基本アプリケーションのポリシー関数を作成しなおさなくても、部門固有のポリシー関数を表に追加できます。表に適用されるすべてのポリシーは、AND構文で規定されます。そのため、CUSTOMERS表に3つのポリシーを適用している場合、各ポリシーが表に適用されます。データにアクセスするアプリケーションに応じて異なるポリシーが適用されるように、ポリシー・グループおよびアプリケーション・コンテキストを使用して、ファイングレイン・アクセス・コントロールの規定を分割できます。これによって、開発グループ間でポリシーを調整する必要がなくなり、アプリケーションの開発が容易になります。常に適用する(たとえば、ホスト環境でサブスクライバによりデータ分割を規定する)デフォルト・ポリシー・グループを保持することもできます。駆動コンテキストを実装するパッケージは、データベースへの接続に使用されるアプリケーションを正しく検証する必要があります。Databaseは、コール・スタックをチェックして、駆動コンテキストを実装するパッケージによるコンテキスト属性の設定を確認しますが、パッケージ内では不適切な検証が発生する可能性があります。データベース・ユーザーまたはエンタープライズ・ユーザーがデータベースに認識されているアプリケーションの場合、ユーザーには、駆動コンテキストを設定するパッケージに対するEXECUTE権限が必要です。次のことを認識しているユーザーを考えてみます。BENEFITSアプリケーションの方がHRアプリケーションよりもアクセスが自由であること。(正しいポリシー・グループを駆動コンテキスト内に設定する)setctxプロシージャでは、実際に接続しているアプリケーションを判断するための検証が実行されないこと。このプロシージャでは、(3層システムに対する)着信接続のIPアドレス、またはユーザー・セッションのproxy_user属性がチェックされないこと。ユーザーは、アクセスがより自由なBENEFITSポリシー・グループにコンテキストを設定する引数を駆動コンテキスト・パッケージに渡してから、かわりにHRアプリケーションにアクセスできます。setctxではアプリケーションに対してそれ以上の検証を行わないため、このユーザーは限定的なHRセキュリティ・ポリシーをバイパスしてしまいます。Databaseによるプロキシ認証を実装すると、ユーザーのかわりにデータベースに接続する中間層(およびアプリケーション)の識別情報を確認できます。これによって、データ・アクセスを仲介するアプリケーションごとに正しいポリシーが適用されます。開発者は、プロキシ認証機能を使用して、データベースに接続しているアプリケーション(中間層)がHRAPPSERVERであることを確認できます。HRAPPSERVERかどうかを検証できます。proxy_userがHRAPPSERVERの場合は、HRポリシー・グループを使用するように駆動コンテキストを設定できます。proxy_userがHRAPPSERVERでない場合は、アクセスを拒否できます。このような場合に、次の問合せが実行されるとします。Databaseは、デフォルト・ポリシー・グループ(SYS_DEFAULT)およびアクティブなネームスペースHRのポリシーを選択します。この問合せは、内部で次のようにリライトされます。Databaseポリシー・タイプを使用したパフォーマンスの最適化ポリシーに対してポリシー・タイプを指定すると、ポリシーの各実行のパフォーマンスを最適化できます。Databaseポリシーの述語をキャッシュする方法を制御します。ポリシー関数を実行すると、システム・リソースを大量に消費する場合があるため、ポリシーに対してポリシー・タイプを設定することを検討してください。ポリシー関数の実行回数を最小限に抑えることで、データベースのパフォーマンスを最適化できます。選択できるポリシー・タイプは、DYNAMIC、STATIC、SHARED_STATIC、CONTEXT_SENSITIVEおよびSHARED_CONTEXT_SENSITIVEの5種類です。これらのポリシー・タイプによって、ポリシーの述語を変更する頻度を正確に指定できます。POLICYプロシージャのpolicy_typeパラメータを設定します。この項の内容は、次のとおりです。動的ポリシー・タイプの使用によるポリシー関数の自動再実行DYNAMICポリシー・タイプを指定すると、ユーザーが仮想プライベート・データベースで保護されたデータベース・オブジェクトにアクセスするたびに、ポリシー関数が実行されます。DBMS_RLS.ADD_POLICYプロシージャにポリシー・タイプを指定しない場合、ポリシーはデフォルトで動的になります。ポリシーを動的に構成するには、DBMS_RLS.ADD_POLICYプロシージャのpolicy_typeパラメータをDYNAMICに設定します。動的ポリシー・タイプでは、静的ポリシーや状況依存ポリシー・タイプの場合と異なり、データベースのパフォーマンスは最適化されません。ポリシーを静的または状況依存に設定する前に、その都度実行されるDYNAMICポリシー・タイプでテストすることをお薦めします。最初にポリシー関数をDYNAMICポリシーでテストすると、何もキャッシュされていないため、ポリシー関数が各問合せに与える影響を調べることができます。これにより、パフォーマンスを最適化するために静的ポリシーまたは状況依存ポリシーを使用可能にする前に、関数が正常に機能することを確認できます。文の実行開始時間と終了時間を測定するには、DBMS_UTILITY.GET_TIMEプロシージャを使用します。2314319例7-5に、DYNAMICポリシー・タイプの作成方法を示します。静的ポリシー・タイプを指定すると、インスタンス内のすべてのユーザーに対して同じ述語が規定されます。Databaseでは静的ポリシーの述語がSGAに格納されるため、ポリシー関数は問合せごとに再実行されません。その結果、パフォーマンスが向上します。静的ポリシーを使用可能にするには、そのポリシーを複数のオブジェクト間で共有するかどうかに応じて、DBMS_RLS.ADD_POLICYプロシージャのpolicy_typeパラメータをSTATICまたはSHARED_STATICのいずれかに設定します。例7-6に、STATICポリシー・タイプの作成方法を示します。dbms_rls.STATIC);END;述語が同じでも、同じカーソルを実行するたびに異なる行セットが生成される場合があります。これは、述語によるデータのフィルタ処理がSYS_CONTEXTやSYSDATEなどの属性によって異なるためです。ポリシーをSTATICまたはSHARED_STATICポリシー・タイプとして使用可能にする場合を想定します。この場合は、ポリシーで保護されたデータベース・オブジェクトに対して実行されるすべての問合せに次の述語が追加されます。('hr_app','deptno')述語は、問合せごとに変わりませんが、SYS_CONTEXTのセッション属性に基づいて問合せに適用されます。前述の例の述語では、ポリシーで保護されたデータベース・オブジェクトを問い合せているユーザーの部門番号がSYS_CONTEXTのdeptno属性と一致する行のみを戻します。注意:共有の静的ポリシーを使用する場合は、ポリシーの述語に、列名など特定のデータベース・オブジェクト固有の属性が含まれていないことを確認してください。共有の静的ポリシーの使用による複数オブジェクト間でのポリシーの共有たとえば、使用する財務データを含むHRスキーマの2番目の表に例7-6のポリシーを適用する場合、両方の表でSHARED_STATIC設定を使用します。例7-7に、同じポリシーを共有する2つの表に対してSHARED_STATICポリシー・タイプを設定する方法を示します。静的ポリシーは、すべての問合せに同じ述語が必要で、高いパフォーマンスが不可欠なホスト環境などに最適です。このような環境では、ポリシー関数がすべての問合せに同じ述語を追加すると、ポリシー関数を再実行するたびに不要なオーバーヘッドがシステムに加わります。競争相手である複数の顧客企業に関する市場調査データが含まれたデータ・ウェアハウスを考えてみます。このウェアハウスでは、各企業が自社の市場調査データのみを参照できるポリシーを規定する必要があり、このポリシーは次の述語で表現されます。'cust_num')アプリケーション・コンテキストに対してSYS_CONTEXTを使用すると、データベースでは、戻される行を動的に変更できます。関数を再実行する必要はなく、述語はSGAにキャッシュされるため、システム・リソースを節約でき、パフォーマンスが向上します。静的ポリシーとは対照的に、状況依存ポリシーは必ずしも述語をキャッシュしません。状況依存ポリシーの場合、データベースでは、述語は文の解析後に変更されると想定しています。Databaseはユーザー・セッション内でポリシー関数を再実行しません。コンテキストに変更があった場合、データベースはポリシー関数を再実行して、最初の解析以降の述語に対する変更を取得します。状況依存ポリシーを使用可能にするには、DBMS_RLS.ADD_POLICYプロシージャのpolicy_typeパラメータをCONTEXT_SENSITIVEまたはSHARED_CONTEXT_SENSITIVEに設定します例7-8に、CONTEXT_SENSITIVEポリシー・タイプの作成方法を示します。dbms_rls.CONTEXT_SENSITIVE);END;状況依存ポリシーは、異なる述語を、問合せを実行するユーザーに応じて適用する必要がある場合に便利です。empnoがemp_idに設定される場合を考えてみます。共有の状況依存ポリシーは、複数のデータベース・オブジェクト間で共有できることを除いて、通常の状況依存ポリシーと同様に機能します。このポリシー・タイプの場合、すべてのオブジェクトはUGAからポリシー関数を共有できます。述語は、ローカル・セッションのコンテキストに変更があるまで、UGAにキャッシュされます。注意:共有の状況依存ポリシーを使用する場合は、ポリシーの述語に、列名など特定のデータベース・オブジェクト固有の属性が含まれていないことを確認してください。例7-9に、複数の表で1つのポリシーを共有する、2つの共有の状況依存ポリシーを作成する方法を示します。状況依存ポリシーは、ユーザー・セッションごとに述語を変える必要はないが、ポリシーが異なるユーザーまたはグループに複数の異なる述語を規定する必要がある場合に便利です。単一のポリシーを持つsales_history表を考えてみます。このポリシーでは、アナリストは自分の製品のみを参照でき、地域担当者は自分の地域のみを参照できます。この場合、データベースは、ユーザーのタイプが変わるたびにポリシー関数を再実行する必要があります。サーバーによるポリシー関数の再実行なしに、ユーザーがログインして保護されたオブジェクトに対していくつかのDML文を発行できる場合は、パフォーマンスが向上します。注意:複数のクライアントが1つのデータベース・セッションを共有するセッション・プーリングの場合は、クライアント切替え時に中間層でコンテキストを再設定する必要があります。表7-2に、使用可能なポリシー・タイプの要約を示します。複数オブジェクト間での共有DYNAMICポリシーで保護されたデータベース・オブジェクトがアクセスされるたびに、ポリシー関数を再実行します。日中の特定時間は、ユーザーによるデータベース・オブジェクトへのアクセスを拒否する時間依存のポリシーなど、ポリシーの述語を問合せごとに生成する必要があるアプリケーション。なしSTATIC1回実行され、述語はSGAにキャッシュされます。なしSHARED_STATICSTATICと同じです。同じ述語を複数のデータベース・オブジェクトに適用する必要があるデータ・ウェアハウスなどのホスト環境。ありCONTEXT_SENSITIVE文の解析時。文の実行時(カーソルが最後に使用された後にローカル・アプリケーション・コンテキストが変更された場合)。ポリシーによって異なるユーザーまたはグループに複数の述語が規定される、3層セッション・プーリング・アプリケーション。なしSHARED_CONTEXT_SENSITIVEデータベース・セッションで最初にオブジェクトが参照されたとき。述語はプライベート・セッション・メモリーであるUGAにキャッシュされるため、ポリシー関数を複数のオブジェクト間で共有できます。CONTEXT_SENSITIVEと同じですが、複数のオブジェクトがセッションのUGAからポリシー関数を共有できます。述語が同じでも、同じカーソルを実行するたびに異なる行セットが生成される場合があります。これは、述語によるデータのフィルタ処理がSYS_CONTEXTやSYSDATEなどの属性によって異なるためです。Databaseポリシーの作成この項の内容は、次のとおりです。Databaseポリシーを作成する必要があるとします。このポリシーは、基本的に次の文で表現されます。OE.ORDERS;このポリシーを次のように変換します。159;手順は、次のとおりです。SYSDBA権限を使用して接続します。passwordDBA_USERSデータ・ディクショナリ・ビューに対して、次のSELECT文を実行します。'OE';DBA_USERSビューに、ユーザーOEがロックされて期限切れになっていると表示された場合は、次の文を入力して、OEアカウントのロックを解除し、新しいパスワードを作成します。password;passwordを安全なパスワードに置き換えます。Databaseで使用されたパスワードを再利用しないでください。詳細は、「パスワードの最低要件」を参照してください。次の関数を作成します。159句を追加します。auth_orders;/この例の説明は、次のとおりです。スキーマ名OEと表名ORDERSを格納するために指定する入力パラメータを作成します。最初に、スキーマ用のパラメータを定義し、次に、オブジェクト(この例では表)用のパラメータを定義します。パラメータは常にこの順序で作成します。作成する仮想プライベート・データベース・ポリシーでは、OE.ORDERS表を指定するためにこれらのパラメータが必要です。WHERE述語句で使用する文字列を戻します。戻り値は常にVARCHAR2データ型になります。159述語の作成を含みます。次に、DBMS_RLSパッケージのADD_POLICYプロシージャを使用して、次のポリシーを作成します。END;/この例の説明は、次のとおりです。保護するスキーマ(この例ではOE)を指定します。保護するスキーマ内のオブジェクト(この例ではORDERS表)を指定します。このポリシーの名前をorders_policyと指定します。auth_orders関数が作成されたスキーマを指定します。この例では、auth_ordersはSYSスキーマに作成されています。通常は、セキュリティ管理者のスキーマに作成する必要があります。ポリシーを規定する関数を指定します。ポリシー関数の作成」で作成したauth_orders関数を指定します。ポリシーを適用する操作を指定します。この例では、ポリシーは、ユーザーが実行可能なすべてのSELECT文、INSERT文、UPDATE文およびDELETE文に適用されます。Databaseポリシーを作成した直後に、ポリシーは有効になります。ユーザー(スキーマの所有者を含む)が次にOE.ORDERSに対してSELECT文を実行すると、営業担当者159の受注のみにアクセスできます。ユーザーOEでログインします。passwordConnected.次のSELECT文を入力します。ORDERS;次の出力が表示されます。7ポリシーはユーザーOEに対して有効です。ここに示すように、受注表の105行の内、7行のみが戻されます。管理権限を持つユーザーは、表のすべての行にアクセスできます。ユーザーSYSで再度ログインします。passwordConnected.次のSELECT文を入力します。OE.ORDERS;次の出力が表示されます。この例で使用したコンポーネントの削除ユーザーSYSで、次のように関数とポリシーを削除します。DBMS_RLS.DROP_POLICY('OE','ORDERS','ORDERS_POLICY');OEアカウントをロックして期限切れにする必要がある場合は、次の文を入力します。データベース・セッション・ベースのアプリケーション・コンテキストを使用したポリシーの実装この例では、データベース・セッション・ベースのアプリケーション・コンテキストを使用して、顧客が自分の注文のみを参照できるというポリシーを実装する方法を示しています。次のようにセキュリティのレイヤーを作成します。ユーザーがログインするとき、データベース・セッション・ベースのアプリケーション・コンテキストによって顧客かどうかがチェックされます。顧客でないユーザーでもログインできますが、このユーザーはこの例で作成する注文表にアクセスできません。ユーザーが顧客の場合はログインできます。Databaseポリシーによって、このユーザーは自分の注文のみを参照できるように制限されます。Databaseポリシーによって、ユーザーは自分の注文の表示のみが許可されます。ユーザーは、注文の追加、変更または削除はできません。手順は、次のとおりです。ユーザー・アカウントとサンプル表の作成SQL*Plusを起動して、管理権限を持つユーザーとしてログインします。Databaseポリシーを管理する、次の管理ユーザーを作成します。次のSQL文では、このユーザーを作成してから、この例を終了するのに必要な権限をユーザーに付与します。sysadmin_vpd;passwordを安全なパスワードに置き換えます。詳細は、「パスワードの最低要件」を参照してください。次のユーザー・アカウントを作成します。password;passwordを安全なパスワードに置き換えます。詳細は、「パスワードの最低要件」を参照してください。この例で使用するサンプル・ユーザーSCOTTのステータスをチェックします。'SCOTT';DBA_USERSビューに、ユーザーSCOTTがロックされて期限切れになっていると表示された場合は、次の文を入力して、SCOTTアカウントのロックを解除し、新しいパスワードを作成します。password;passwordを安全なパスワードに置き換えます。Databaseで使用されたパスワードを再利用しないでください。詳細は、「パスワードの最低要件」を参照してください。ユーザーSCOTTで接続し、customers表を作成して値を入力します。Woods');ユーザーの電子メール・アドレスを入力する際には、大文字で入力します。後でアプリケーション・コンテキストのPL/SQLパッケージを作成するときに、SYS_CONTEXTファンクションのSESSION_USERパラメータではユーザー名が大文字であると想定されます。大文字でないと、そのユーザー用のアプリケーション・コンテキストを設定できません。ユーザーsysadmin_vpdには、ユーザーSCOTTと同様にcustomers表のSELECT権限が必要になるため、この権限をsysadmin_vpdに付与します。sysadmin_vpd;orders_tab表を作成して値を入力します。4592);ユーザーtbrookeとowoodsはorders_tab表を問い合せる必要があるため、これらのユーザーにSELECT権限を付与します。owoods;orders_tab受注表には、2名のサンプル顧客tbrookeとowoodsの購買レコードがあります。この段階では、これらの顧客がこの表を参照すると、すべての受注を参照できます。データベース・セッション・ベースのアプリケーション・コンテキストの作成ユーザーsysadmin_vpdで接続します。passwordConnected.次の文を入力します。orders_ctx_pkg;この文は、orders_ctxアプリケーション・コンテキストを作成します。ユーザーsysadmin_vpdがこのコンテキストを作成してsysadmin_vpdスキーマに対応付けた場合でも、SYSスキーマがこのアプリケーション・コンテキストを所有することに注意してください。アプリケーション・コンテキストを設定するPL/SQLパッケージの作成ユーザーsysadmin_vpdで、次のPL/SQLパッケージを作成します。このパッケージによって、顧客tbrookeおよびowoodsがアカウントにログインしたときに、データベース・セッション・ベースのアプリケーション・コンテキストが設定されます。set_custnum;END;/この例の説明は、次のとおりです。顧客IDを保持するcustnum変数を作成します。SELECT文を実行し、scott.customers表のcust_no列データに格納されている顧客IDをcustnum変数にコピーします。WHERE句を使用して、ログインしたユーザーのユーザー名と一致するすべての顧客IDを検索します。cust_no属性を作成し、この属性をcustnum変数に格納された値に設定して、orders_ctxアプリケーション・コンテキスト値を設定します。foundエラーを捕捉します。要約すると、sysadmin_vpd.set_cust_numプロシージャは、セッション・ユーザーの顧客IDを選択してcustnum変数に格納することによって、ユーザーが登録済顧客かどうかを識別します。Databaseによってこのユーザーにアプリケーション・コンテキスト値が設定されます。ユーザー・アクセスを自分の注文に制限するPL/SQLポリシー関数の作成」に示すように、ポリシー関数では、コンテキスト値を使用して、ユーザーがorders_tab表内のデータに対して持つアクセスを制御します。アプリケーション・コンテキストを設定するPL/SQLパッケージの作成」で作成したPL/SQLパッケージのプロシージャが実行されるため、アプリケーション・コンテキストを設定できます。ユーザーsysadmin_vpdで、次のトリガーを作成します。END;/関連項目:「データベース・セッション・ベースのアプリケーション・コンテキスト・パッケージを実行するためのログイン・トリガーの作成」この段階で、tbrookeまたはowoodsでログインすると、ログイン・トリガーによってsysadmin_vpd.orders_ctx_pkg.set_custnumプロシージャの起動時にユーザー用のアプリケーション・コンテキストが設定されます。これは次のようにテストできます。DUAL;次の出力が表示されます。scott.orders_tab問合せを実行するとそのユーザーの注文のみが表示されるように、PL/SQLファンクションを作成します。ユーザーsysadmin_vpdで、次の関数を作成します。orders_pred;END;/この関数は、「ログインしたユーザーに属する注文を表示」するWHERE述語を作成して戻します。このWHERE述語は、ユーザーがscott.orders_tab表に対して実行する問合せに追加されます。Databaseポリシーを作成する必要があります。新しいセキュリティ・ポリシーの作成ユーザーsysadmin_vpdで、次のポリシーを作成します。'select');END;/この文は、orders_policyというポリシーを作成して、SCOTTスキーマのorders_tab表(顧客が注文を問い合せる表)に適用します。get_user_orders関数がこのポリシーを実装します。この関数はsysadmin_vpdスキーマに格納されます。このポリシーにより、ユーザーはSELECT文のみの発行に制限されます。新しいポリシーのテストユーザーtbrookeでログインします。passwordConnected.ユーザーtbrookeは、アプリケーション・コンテキストに定義した要件を通過できるため、ログインできます。ユーザーtbrookeで、購買レコードにアクセスします。scott.orders_tab;次の出力が表示されます。9876ユーザーtbrookeは、2番目のテストを通過します。このユーザーは、scott.orders_tab表にある自分の注文のみにアクセスできます。ユーザーowoodsでログインし、購買レコードにアクセスします。scott.orders_tab次の出力が表示されます。4592ユーザーtbrookeとユーザーowoodsはログインでき、自分の注文のリストを参照できます。次のことに注意してください。ユーザーの職位に基づいて複数の述語を作成できます。営業担当者は自分の担当顧客のレコードのみを参照でき、受注入力担当はすべての顧客注文を参照できます。get_user_orders関数は、ユーザーの職位のコンテキスト値に基づいて異なる述語を戻すように拡張できます。ファイングレイン・アクセス・コントロール・パッケージ内でアプリケーション・コンテキストを使用することによって、実際には解析済の文の中にバインド変数が指定されます。'cust_num');この文は完全に解析および最適化されますが、order_entryコンテキストに対するユーザーのcust_num属性値の評価は、実行時に行われます。これは、最適化された文には、その文を発行するユーザーごとに異なる形態で実行されるという利点があることを意味します。注意:この例の関数のパフォーマンスは、cust_noに索引を作成するとさらに向上します。Protocol(LDAP)を使用するディレクトリ・サーバーのデータに基づいて設定できます。Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。Databaseポリシーの概要」を比較してください。この例で使用したコンポーネントの削除ユーザーOEで接続し、orders_tabおよびcustomers表を削除します。SYSDBAで接続します。passwordConnected.次の文を実行して、この例で使用したコンポーネントを削除します。Databaseポリシー・グループの実装アプリケーションで使用する一連のポリシーをグループ化する方法については、「ポリシー・グループの使用」を参照してください。Databaseでは、適切なポリシー・グループ内で定義されたポリシーに基づいてユーザーにアクセス権が付与されます。列レベルのアクセス制御の場合、各列または非表示の列セットが1つのポリシーで制御されます。この例では、2つの列セットを非表示にする必要があります。そのため、非表示にする列セットごとに1つずつ、2つのポリシーを作成します。ユーザーごとに必要なポリシーは1つのみのため、駆動アプリケーション・コンテキストによってポリシーが分割されます。手順は、次のとおりです。この例で使用するコンポーネントの作成ユーザーSYSとしてSYSDBA権限でログインします。passwordConnected.次のユーザーを作成します。password;passwordを安全なパスワードに置き換えます。詳細は、「パスワードの最低要件」を参照してください。ユーザーsysadmin_pgに次の権限を追加付与します。sysadmin_pg;ユーザーOEでログインします。passwordConnected.OEアカウントがロックされて期限切れになっている場合、SYSDBA権限を持つユーザーSYSとして再接続してから、次の文を入力してアカウントのロックを解除し、新しいパスワードを指定します。password;passwordを安全なパスワードに置き換えます。Databaseで使用されたパスワードを再利用しないでください。詳細は、「パスワードの最低要件」を参照してください。product_code_names表を作成します。varchar2(32));product_code_names表に値をいくつか挿入します。Dumont','2003');COMMIT;product_code_names表のSELECT権限をapp_userユーザーに付与します。次に、2人の非データベース・ユーザーprovider_aおよびprovider_bにそれぞれポリシー・グループを作成する必要があります。ユーザーsysadmin_pgで接続します。passwordConnected.ユーザーprovider_aにより使用されるprovider_a_groupポリシー・グループを作成します。'provider_a_group');END;/ユーザーprovider_bにより使用されるprovider_b_groupポリシー・グループを作成します。2つのポリシー・グループの作成」で作成した各ポリシー・グループには、ユーザーprovider_aおよびprovider_bのデータ・アクセスをアプリケーションで制御する方法を定義した関数が必要です。ユーザーprovider_aがアクセスするデータを制限するvpd_function_provider_a関数を作成します。predicate;END;/この関数では、ログインするユーザーが確かにユーザーprovider_aであるかどうかがチェックされます。間違いない場合、provider_aが表示できるのは、product_code_names表の列group_aおよびyear_a内のデータのみとなります。列group_bおよびyear_b内のデータは、provider_aに表示されません。'1=2'を設定すると関連列が非表示になります。PL/SQLファンクションのポリシー・グループへの追加」では、これらの列をSEC_RELEVANT_COLSパラメータに指定します。この関数タイプのコンポーネントの詳細は、「動的なWHERE句を生成する関数の作成」を参照してください。ユーザーprovider_aがアクセスするデータを制限するvpd_function_provider_b関数を作成します。predicate;END;/vpd_function_provider_a関数と同様に、この関数では、ログインするユーザーが確かにユーザーprovider_bであるかどうかがチェックされます。間違いない場合、provider_bが表示できるのは、列group_bおよびyear_b内のデータのみであり、group_aおよびyear_a内のデータはprovider_bには表示されません。PL/SQLファンクションのポリシー・グループへの追加」でSEC_RELEVANT_COLSパラメータに指定する関連列が非表示になります。必要な関数を作成したら、適切なポリシー・グループに関数を関連付ける必要があります。vpd_function_provider_a関数をprovider_a_groupポリシー・グループに追加します。DBMS_RLS.ALL_ROWS);END;/SEC_RELEVANT_COLSパラメータで指定したgroup_bおよびyear_b列は、ユーザーprovider_aに対して非表示になります。vpd_function_provider_b関数をprovider_b_groupポリシー・グループに追加します。DBMS_RLS.ALL_ROWS);END;/SEC_RELEVANT_COLSパラメータで指定したgroup_aおよびyear_a列は、ユーザーprovider_bに対して非表示になります。駆動アプリケーション・コンテキストの作成アプリケーション・コンテキストにより、ログインする非データベース・ユーザーが使用する必要があるポリシーが決定されます。ユーザーsysadmin_pgで、次の駆動アプリケーション・コンテキストを作成します。provider_packageパッケージを作成します。set_provider_context;END;/provider_ctxアプリケーション・コンテキストをproduct_code_names表に関連付け、名前を指定します。=>'policy_group');END;/apps_userアカウントにprovider_packageパッケージに対するEXECUTE権限を付与します。ポリシー・グループのテストこれで、2つのポリシー・グループをテストできます。ユーザーapps_userとして接続した後、次の文を入力して、後で作成する出力の書式が適切に設定されるようにします。a16;セッション識別子をprovider_aに設定します。DBMS_SESSION.SET_IDENTIFIER('provider_a');ここで、アプリケーションが識別子を設定します。識別子をprovider_aに設定すると、apps_userユーザーは、provider_a_groupポリシー・グループ内の製品に使用可能な製品のみが表示されるユーザーとして設定されます。provider_packageを実行し、コンテキストに基づいてポリシー・グループを設定します。sysadmin_pg.provider_package.set_provider_context;この時点で、アプリケーション・コンテキストが設定されたことを、次のように確認できます。DUAL;次の出力が表示されます。END_USER-----------------provider_a次のSELECT文を入力します。oe.product_code_names;次の出力が表示されます。2006クライアント識別子をprovider_bに設定し、次の文を入力します。oe.product_code_names;次の出力が表示されます。この例で使用したコンポーネントの削除ユーザーOEで接続し、product_code_names表を削除します。product_code_names;ユーザーSYSで接続し、この例で使用したアプリケーション・コンテキストとユーザーを削除します。Databaseの使用この項の内容は、次のとおりです。Databaseセキュリティ・ポリシーは、アプリケーション内ではなく、データベース内で適用されます。Databaseセキュリティ・ポリシーを回避できません。データベースにセキュリティ・ポリシーを作成するもう1つの利点は、複数のアプリケーションで各セキュリティ・ポリシーを保持するのではなく、1箇所でセキュリティ・ポリシーを保持できることです。Databaseは、アプリケーション・ベースのセキュリティよりも強力なセキュリティを提供し、所有権のコストもより低くなります。データにアクセスしているアプリケーションに応じて、異なるセキュリティ・ポリシーを規定する必要がある場合があります。Entry(受注管理)およびInventory(在庫管理)の2つのアプリケーションが、両方ともorders表にアクセスする場合を考えてみます。Inventoryアプリケーションで、製品の種類に基づいてアクセスを制限するポリシーを使用するとします。Entryアプリケーションでも、顧客番号に基づいてアクセスを制限するポリシーを使用するとします。この場合、アプリケーションによるファイングレイン・アクセスの使用を分割する必要があります。分割しないと、2つのポリシーが自動的に連結され、目的とする結果が得られません。複数のポリシー・グループ、および特定のトランザクションに対して有効なポリシー・グループを判断する駆動アプリケーションのコンテキストを指定できます。データ・アクセスに対して必ず適用するデフォルト・ポリシーも指定できます。ホスティングされたアプリケーションでは、データ・アクセスはサブスクライバIDによって制限されます。Databaseポリシー・グループの実装」を参照してください。ファイングレイン・アクセス・コントロールのポリシー関数に対する自動再解析の使用デフォルトでは、各ポリシーに対して最新の述語が使用されるように、ファイングレイン・アクセス・コントロール対応のオブジェクトに対する問合せでポリシー関数が実行されます。問合せを午前8時から午後5時の間に限定する時間ベースのポリシー関数の場合は、正午にカーソルの実行を解析すると、その時点でこのポリシー関数が実行され、問合せに対してポリシーが再度参照されます。自動再解析は、ポリシーを追加するときにDBMS_RLS.ADD_POLICY設定のSTATIC_POLICYをTRUEに設定した場合は実行されません。この設定の場合、ポリシー関数は同じ述語を戻します。Databaseポリシーとフラッシュバック問合せの使用デフォルトでは、データベースでの操作には、使用可能な最新のコミット済データが使用されます。フラッシュバック問合せ機能を使用すると、過去の特定時点におけるデータベースに対して問合せを実行できます。OF句を使用して、時間またはシステム変更番号(SCN)を指定し、指定した時間のコミット済データに対して問合せを実行します。PL/SQLパッケージを使用することもできますが、コードの量が増えます。この方法では、同じ時点を参照する複数の操作を実行できます。Databaseポリシーで保護されているデータベース・オブジェクトに対してフラッシュバック問合せを使用すると、現行のポリシーが過去のデータに適用されます。Databaseポリシーをフラッシュバック問合せのデータに適用すると、最新のビジネス・ポリシーが反映されるため、安全性が高まります。Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。Securityの使用この項の内容は、次のとおりです。Securityユーザー認可に基づいて列または行レベルのアクセス制御を提供できます。一般に、次の手順を実行する必要があります。Securityのポリシーを作成したら、保護する必要がある表にこのポリシーを適用しないでください。(作成した仮想プライベート・データベース・ポリシーによって自動的に処理されます。)SA_SYSDBA.CREATE_POLICYプロシージャで、default_optionsパラメータをNO_CONTROLに設定します。Securityのラベル・コンポーネントを作成し、通常どおりユーザーを認可します。Databaseポリシーを作成する際には、次の操作を行います。SecurityのDOMINATESファンクションを使用して、ユーザーの認可を手順2で作成したラベルと比較します。Security管理者ガイド』を参照してください。)DOMINATESファンクションにより、ユーザーの認可が比較で使用されたラベルと等しい、またはラベルより機密性が高いかどうかが判別されます。ユーザー認可が通過した場合、ユーザーは列に対するアクセス権を付与されます。通過しない場合、ユーザーはアクセスを拒否されます。仮想プライベート・データベース・ポリシー定義で、保護する必要がある表にこのファンクションを適用します。Securityユーザー認可に基づいて列を表示または非表示にします。Networkのサイトにアクセスしてください。Securityを使用する場合は、次の例外に注意してください。Securityのポリシーはダイレクト・パス・エクスポート操作では規定されません。Databaseはディスクからバッファ・キャッシュにデータを読み込み、行をエクスポート・クライアントに直接転送します。Databaseユーティリティ』を参照してください。Securityのポリシーは、SYSスキーマのオブジェクトに適用できません。Securityのポリシーは適用されません。Securityの規定対象から除外されます。SYSDBAのアクションは、インストール時に監査を有効にし、監査証跡をオペレーティング・システムの保護位置に格納するように指定することによって監査できます。詳細は、「SYS管理ユーザーの監査」を参照してください。Vaultを使用して詳細に監視できます。Databaseの規定対象から除外されます。POLICYを持つユーザーは、すべてのSELECTまたはDML操作(INSERT、UPDATEおよびDELETE)において、ファイングレイン・アクセス・コントロール・ポリシーの対象から除外されます。これによって、インストールや、SYS以外のスキーマを介したデータベースのインポートとエクスポートなどの管理アクティビティが使いやすくなります。POLICYが付与されている場合も規定されます。SecurityのポリシーにALL_CONTROLオプションを指定した場合は、READ_CONTROLおよびCHECK_CONTROL以外のすべてが規定の対象として適用されます。POLICYは、ファイングレイン・アクセス・コントロールを無効にするため、この権限は、ファイングレイン・アクセス・コントロールの規定を回避する正当な理由を持つユーザーに対してのみ付与する必要があります。OPTIONを使用して付与しないでください。POLICY権限を譲渡して、ファイングレイン・アクセス・コントロールを回避する権限が伝播する可能性があります。権限は、SELECT、INSERT、UPDATEおよびDELETEなどのオブジェクト権限の規定には影響しません。POLICY権限が付与されている場合も規定されます。Databaseが使用するSYS_CONTEXT値は、フェイルオーバーのためのセカンダリ・データベースには伝播されません。Databaseは、次のタイプのユーザー・モデルで使用できます。アプリケーション・ユーザーがデータベース・ユーザーでもある場合。Databaseでは、ユーザーがデータベース・ユーザーか、データベースに認識されないアプリケーション・ユーザーかに関係なく、アプリケーションはユーザーごとにファイングレイン・アクセス・コントロールを規定できます。Databaseは次のように規定されます。ユーザーがデータベースに接続すると、アプリケーションは各セッションに対するアプリケーション・コンテキストを設定します(様々な種類のユーザー・セッション・データを取得するための多くのパラメータを提供する、デフォルトのUSERENVアプリケーション・コンテキスト・ネームスペースを使用できます)。各セッションは異なるユーザー名で開始されるため、各ユーザーに対して異なるファイングレイン・アクセス・コントロール条件を規定できます。JDBCを使用したプロキシ認証。プロキシ認証を使用すると、ユーザーごとに異なるファイングレイン・アクセス・コントロールができます。JDBC)が独自のアプリケーション・コンテキストを持つ個別のデータベース・セッションであるためです。エンタープライズ・ユーザー・セキュリティに統合されているプロキシ認証。Databaseポリシーを規定できます(また、グローバルに初期化されたアプリケーション・コンテキストもディレクトリから取得できます)。Userとして接続する場合。すべてのユーザーのかわりにシングル・ユーザーとしてデータベースに接続するアプリケーションでは、ユーザーごとのファイングレイン・アクセス・コントロールを規定できます。Userと呼ばれます。アプリケーション開発者は、そのセッションのコンテキスト内で、個別のアプリケーション・ユーザー(たとえば、REALUSER)を表すグローバル・アプリケーション・コンテキスト属性を作成できます。Userに対して作成されますが、各セッションはエンド・ユーザーに応じて異なる属性を保持できます。このモデルは、ユーザーの数が限定されていて、セッションが再利用されないアプリケーションに最適です。このモデルの場合、各セッションは同一のデータベース・ユーザーとして作成されるため、ロールやデータベース監査の範囲が限定されます。グローバル・アプリケーション・コンテキストの詳細は、「グローバル・アプリケーション・コンテキストの使用」を参照してください。Webベースのアプリケーション。Webベースのアプリケーションには、通常は何百人ものユーザーがいます。多数のユーザー要求に対するデータの取得をサポートするためにデータベースへの接続が持続的に行われる場合でも、このような接続は特定のWebベース・ユーザーに固有のものではありません。通常、Webベースのアプリケーションはスケーラビリティを提供するために、ユーザーごとに異なるセッションを保持するのではなく、接続を設定して再利用します。WebユーザーJaneおよびAjitが中間層アプリケーションに接続すると、このアプリケーションは、2人のユーザーのかわりに、使用するデータベース・セッションを1つ確立します。通常、JaneもAjitもデータベースには認識されません。アプリケーションが接続するユーザー名を切り替えるため、どの時点でも、セッションを使用しているのはJaneまたはAjitのいずれかです。Databaseを使用すると、複数のグローバル・アプリケーション・コンテキストにアクセスする複数の接続が可能になり、接続プーリングが促進されます。この機能によって、個別ユーザー・セッションごとに別々のアプリケーション・コンテキストを確立する必要がなくなります。Databaseをユーザー・モデルに適用する方法の要約を示します。Databaseを規定できます。アプリケーション開発者は、個別アプリケーション・ユーザー(たとえば、REALUSER)を表すグローバル・アプリケーション・コンテキスト属性を作成できます。その後、この属性を使用して、各セッション属性を制御したり、監査することができます。Databaseポリシーに関する情報の検索に使用できるデータ・ディクショナリ・ビューをリストします。Databaseリファレンス』を参照してください。Databaseセキュリティ・ポリシーが表示されます。ALL_POLICY_CONTEXTS現行ユーザーがアクセス可能なシノニム、表およびビューに定義されている駆動コンテキストが表示されます。Databaseポリシーで使用されるアプリケーション・コンテキストです。Databaseポリシー・グループが表示されます。ALL_SEC_RELEVANT_COLS現行ユーザーがアクセス可能な表とビューに対するセキュリティ・ポリシーのセキュリティ関連列が表示されます。Databaseセキュリティ・ポリシーが表示されます。DBA_POLICY_GROUPSデータベース内のすべてのポリシー・グループが表示されます。DBA_POLICY_CONTEXTSデータベース内のすべての駆動コンテキストが表示されます。このビューの列は、ALL_POLICY_CONTEXTSの各列と同じです。DBA_SEC_RELEVANT_COLSデータベース内のすべてのセキュリティ・ポリシーのセキュリティ関連列が表示されます。Databaseセキュリティ・ポリシーが表示されます。このビューにはOBJECT_OWNER列が表示されません。USER_POLICY_CONTEXTS現行ユーザーが所有するシノニム、表およびビューに定義されている駆動コンテキストが表示されます。このビューの列は、OBJECT_OWNER列以外はALL_POLICY_CONTEXTSの各列と同じです。USER_SEC_RELEVANT_COLS現行ユーザーが所有している表とビューに対するセキュリティ・ポリシーのセキュリティ関連列が表示されます。このビューの列は、OBJECT_OWNER列以外はALL_SEC_RELEVANT_COLSの各列と同じです。USER_POLICY_GROUPS現行ユーザーが所有するシノニム、表およびビューに定義されているポリシー・グループが表示されます。このビューにはOBJECT_OWNER列が表示されません。V$VPD_POLICY現在、ライブラリ・キャッシュにキャッシュされているカーソルに対応付けられた、すべてのファイングレイン・セキュリティ・ポリシーと述語が表示されます。このビューは、SQL文に適用されたポリシーを検索するのに便利です。ヒント:仮想プライベート・データベース・ポリシーを使用するアプリケーションでエラーが見つかった場合は、これらのビューに加え、データベース・トレース・ファイルも確認してください。Databaseパフォーマンス・チューニング・ガイド』を参照してください。USER_DUMP_DEST初期化パラメータは、トレース・ファイルの現在の位置を示します。USER_DUMP_DESTを発行して確認できます。reserved.法律上の。