| Oracle® Database Real Application Security管理者および開発者ガイド 12cリリース1 (12.1) B71274-08 |
|
 前 |
 次 |
この章の内容は、次のとおりです。
データ・セキュリティとは、Oracleエンタープライズのすべてのコンポーネントを通じて、統一された方法を使用してOracle Databaseのデータに対するアプリケーション・ユーザーのアクセスを制御する機能です。Oracle Database Real Application Securityでデータベースの表またはビューを保護するには、データ・レルム(「データ・レルム」も参照)を作成して保護する行を指定する必要があります。
データ・レルムへのアクセスを制限するには、データ・レルムごとにアプリケーション・ユーザーまたはアプリケーション・ロールとその権限を示した1つ以上のアクセス制御リスト(ACL)を関連付けます。データ・レルムとその関連するACLの組合せは、データ・レルム制約と呼ばれます。
らさに特定の列に対するアクセスを制限するには、各列に1つ以上のアプリケーション権限を適用します。これは、権限のあるアプリケーション・ユーザーのみにその列のデータを参照させる場合に便利です。
データ・セキュリティは、Oracle Virtual Private Database (VPD)の拡張機能です。アプリケーション・ユーザーがデータベース表を選択または変更するたびに、データ・アクセスを制限するWHERE条件がVPDによって追加されます。VPDの詳細は、Oracle Databaseセキュリティ・ガイドを参照してください。Oracle Database Real Application Securityでは、ACLを各オブジェクトに関連付けることによって行と列に対するアクセスを詳細に制限できる認可モデルを実装して、VPDの概念をさらに拡張しています。また、アプリケーション・セッションおよびセッション・コンテキストは、(ユーザー・ロールとセッション・ネームスペースを通じて)よりセキュアになっています。さらに、Real Application Securityには、独自のデータ・ディクショナリがあります。
Oracle Database Real Application Securityでデータ・セキュリティを構成するには、次の手順を実行する必要があります。
データ・セキュリティ・ポリシーを作成します。データ・セキュリティ・ポリシーによって、1つ以上のデータ・レルムを定義し、各データ・レルムのACLを関連付けてデータ・レルム制約を作成します。データ・セキュリティ・ポリシーに列固有の属性を含め、データ・アクセスを詳細に制御することもできます。複数の表またはビューで、同じデータ・セキュリティ・ポリシーを共有できます。これにより、表およびビューのセット全体で使用できる統一されたセキュリティ計画を作成できます。
保護する表またはビューにデータ・セキュリティ・ポリシーを関連付けます。
XS_DATA_SECURITY.APPLY_OBJECT_POLICY PL/SQLプロシージャを実行して、保護するデータ・レルムおよび列を含む表やビューに対してデータ・セキュリティ・ポリシーを有効化できます。
アプリケーション・セキュリティで、表の行を更新し、同時に同じ表の特定の列に読取りアクセスを制限する必要がある場合、2つのAPPLY_OBJECT_POLICYプロシージャを使用して、両方のデータ・セキュリティ・ポリシーを施行する必要があります。たとえば、一方のAPPLY_OBJECT_POLICYプロシージャでは表の行を更新するために必要なDML statement_typesを施行し(INSERT、UPDATE、DELETEなど)、他方のAPPLY_OBJECT_POLICYプロシージャでは列制約のためにSELECTのstatement_typesのみを施行します。
例5-5例5-5に、APPLY_OBJECT_POLICYプロシージャの使用方法を示します。詳細は、APPLY_OBJECT_POLICYプロシージャを参照してください。
データ・セキュリティ・ポリシーを検証します。詳細は、データ・セキュリティ・ポリシーの検証を参照してください。
管理構成の変更後は、必ずReal Application Securityオブジェクトを検証することをお薦めします。XS_DIAGパッケージには、これらの変更がReal Application Securityオブジェクト間の複雑な関係に意図せず悪影響を与えないようにする検証APIのセットが含まれます。
データ・セキュリティ・ポリシーの検証の詳細は、VALIDATE_DATA_SECURITYファンクションを参照してください。
データ・セキュリティ・ポリシーを作成するには、XS_DATA_SECURITY.CREATE_POLICY PL/SQLプロシージャを使用します。
図5-1に、データ・レルム制約と列制約(どちらもEMPLOYEES表に適用される)から作成されるHR.EMPLOYEES_DSというReal Application Securityデータ・セキュリティ・ポリシーの構造を示します。データ・レルム制約では、データ・セキュリティ・ポリシーが適用される行(60または100の値を持つDEPARTMENT_ID)と、それらの行に関連付けられたACL (HRACL)を定義しています。列制約では、この機密データを表示するために必要なVIEW_SENSITIVE_INFO権限を使用して、EMPLOYEES表のSALARY列に含まれる機密列データの制約を定義しています。
図5-1 EMPLOYEES表に作成されるReal Application Securityデータ・セキュリティ・ポリシー
例5-1では、図5-1に示されているデータ・セキュリティ・ポリシーを作成しています。
関連項目:
データ・セキュリティ・ポリシーは、作成後に検証する必要があります。詳細は、VALIDATE_DATA_SECURITYファンクションを参照してください。
データ・セキュリティ・ポリシーの主なパラメータは次のとおりです。
ポリシー名: これは、データ・セキュリティ・ポリシーの名前を定義します。
例5-1では、作成するデータ・セキュリティ・ポリシーの名前としてEMPLOYEES_DSを使用しています。
データ・レルム制約: データ・レルム制約では、データ・セキュリティ・ポリシーが適用されるデータ・レルム(行)と、それらのデータ・レルムに関連付けられるACLを定義します。
例5-1では、realm_consリストを使用して、EMPLOYEES_DSポリシーのデータ・レルム制約を定義しています。realm_consは、60または100のDEPARTMENT_ID値を持つ行で構成されます。これらの行は、HRACLアクセス制御リストに関連付けられます。
列制約: 列制約では、データ・レルム制約の機密列データに対する追加制約を定義します。
例5-1では、column_cons列制約をEMPLOYEES_DSポリシーに関連付けています。column_consは、VIEW_SENSITIVE_INFO権限によってSALARY列を保護しています。
例5-1 データ・セキュリティ・ポリシーの構造
-- Create the ACL HRACL.
DECLARE
ace_list XS$ACE_LIST;
BEGIN
ace_list := XS$ACE_LIST(
XS$ACE_TYPE(privilege_list => XS$NAME_LIST('SELECT'),
granted => true,principal_name => 'Employee_Role'),
XS$ACE_TYPE(privilege_list => XS$NAME_LIST('SELECT', 'VIEW_SENSITIVE_INFO'), granted => true, principal_name => 'Manager_Role'));
sys.xs_acl.create_acl(name => 'HRACL',ace_list => ace_list, sec_class => 'HR.EMPOLYEES_SC');
END;
-- Create variables to store the data realm constraints and the column constraint.
DECLARE
realm_cons XS$REALM_CONSTRAINT_LIST;
BEGIN
-- Create a data realm constraint comprising of a data realm (rule) and
-- an associated ACL.
realm_cons :=
XS$REALM_CONSTRAINT_LIST(
XS$REALM_CONSTRAINT_TYPE(realm=> 'DEPARTMENT_ID in (60, 100)',
acl_list=> XS$NAME_LIST('HRACL')));
-- Create the column constraint.
column_cons :=
XS$COLUMN_CONSTRAINT_LIST(
XS$COLUMN_CONSTRAINT_TYPE(column_list=> XS$LIST('SALARY'),
privilege=> 'VIEW_SENSITIVE_INFO'));
-- Create the data security policy.
SYS.XS_DATA_SECURITY.CREATE_POLICY(
name=>'HR.EMPLOYEES_DS',
realm_constraint_list=>realm_cons,
column_constraint_list=>column_cons);
-- Enforce the data security policy to protect READ access of the EMPLOYEES table
-- and restrict access to the SALARY column using the VIEW_SENSITIVE_INFO
-- privilege.
sys.xs_data_security.apply_object_policy(
policy => 'HR.EMPLOYEES_DS',
schema => 'HR',
object => 'EMPLOYEES',
statement_types => 'SELECT',
owner_bypass => true);
END;
データ・レルムは、1つ以上のオブジェクト・インスタンスの集まりです。オブジェクト・インスタンスは、表またはビューの単一の行に関連付けられ、オブジェクトの格納表に含まれる行の主キー値によって識別されます。表では、静的データ・レルムと動的データ・レルムの両方を同時に定義できます。前述したとおり、ACLでは、データ・レルムに対するアプリケーション権限の付与を定義します。
データ・レルム制約を使用して、データ・レルムをACLに関連付けます。例5-2では、realm_consというデータ・レルム制約を作成しています。データ・レルム制約には、データ・レルムを作成するためのメンバーシップ・ルールが含まれます。データ・レルムには、DEPARTMENT_IDが60または100の行が含まれます。realm_consでは、データ・レルムに関連付けるためのHRACLというACLも宣言しています。
データ・レルム内のオブジェクト・インスタンスのメンバーシップは、SQL述語の形式のルールで決定されますが、それはオブジェクトの格納表に対する単一表問合せのWHERE句で使用できる必要があります。例5-2のSQL述語は、DEPARTMENT_ID in (60, 100)です。
記述したSQLで「ORA-28113: ポリシー述語にエラーがあります。」などのエラーが発生した場合、トレース・ファイルを使用してエラーの原因を検出できます。詳細は、トレース・ファイルを使用したポリシー述語エラーの確認を参照してください。
例5-2では、HRACLという単一のACLを使用しています。データ・レルムは、複数のACLに関連付けることが可能で、同じACLを複数のデータ・レルム全体で使用できます。
OEサンプル・スキーマのORDERS購買注文表の次の列について検討します。
| ORDER_ID | CUSTOMER_ID | ORDER_STATUS | SALES_REP_ID | ORDER_TOTAL |
|---|---|---|---|---|
2354 |
104 |
0 |
155 |
46257 |
2355 |
104 |
8 |
NULL |
94513.5 |
2356 |
105 |
5 |
NULL |
29473.8 |
2357 |
108 |
5 |
158 |
59872.4 |
2358 |
105 |
2 |
155 |
7826 |
ORDERS表の各行は、購買注文オブジェクトのオブジェクト・インスタンスです。ORDER_ID列に示されている数値は、購買注文オブジェクト・インスタンスを一意に識別するための主キーです。たとえば、次のようになります。
1つのオブジェクト・インスタンス(1つの行)で構成されるデータ・レルム。たとえば、ORDER_ID=2354というWHERE条件を使用できます。
複数のオブジェクト・インスタンスで構成されるデータ・レルム。たとえば、CUSTOMER_ID=104というWHERE条件を使用して複数の行を指定できます。
表の内容全体で構成されるデータ・レルム(1=1というWHERE条件で定義されます)。
データ・レルムの定義方法の例は次のとおりです。
表の列などの有効なSQL属性を使用します。
この場合、次のようにWHERE条件を使用します。
CUSTOMER_ID=104
行と列のデータに加えられた変更は、データ・レルムによって収集されたデータに自動的に反映されます。
WHERE条件でパラメータを使用します。
次のようにデータ・レルムをパラメータ化できます。
CUSTOMER_ID=&PARAM
この例では、パラメータPARAMが様々な顧客IDに関連付けられていると想定しています。この状況で権限を付与する場合、特定のパラメータ値に権限を付与する必要があります。このタイプのWHERE条件を含むデータ・レルムに関連付けられたACLでパラメータの値を指定する必要があります。これにより、顧客ID固有の多くのデータ・レルムを作成することなく、顧客IDに基づいて権限付与を作成できます。
ランタイム・アプリケーション・セッション変数または副問合せに基づくメンバーシップ・ルールを使用します。
このタイプのメンバーシップ・ルールの例は、次のとおりです。
CUSTOMER_ID=XS_SYS_CONTEXT('order', 'cust_id')
ただし、セッション変数または副問合せに基づくメンバーシップ・ルールは、慎重に作成してください。たとえば、現在のアプリケーション・ユーザーを反映するセッション変数USERを、メンバーシップ・ルールcol=USERで使用するとします。Oracle Databaseでは、結果の行セットを事前計算できません(この結果は決定論的ではないため)。アプリケーション・ユーザーSCOTTとアプリケーション・ユーザーJSMITHでは、同じ行で異なる結果となる可能性があります。ただし、メンバーシップ・ルールcol='SCOTT'は、常に任意の行で同じ結果に評価されるため、正常に機能します。
データ・レルムの作成の詳細は、静的データ・レルムの使用についてを参照してください。XS_SYS_CONTEXTの詳細は、XS_SYS_CONTEXTファンクションも参照してください。
例5-2 データ・レルム制約の構成要素
realm_cons := XS$REALM_CONSTRAINT_TYPE(realm=> 'DEPARTMENT_ID in (60, 100)',
acl_list=> XS$NAME_LIST('HRACL'));静的データ・レルムでは、Oracle Databaseによって、データの更新時にデータ・レルムの影響を受けるデータの変更が評価されます。静的データ・レルムは表では使用できますが、ビューでは使用できません。
データ・レルムを静的にするには、そのis_static属性をtrueに設定します。次の例では、静的データ・レルムを作成しています。
realm_cons := XS$REALM_CONSTRAINT_TYPE(realm=> 'DEPARTMENT_ID in (60, 100)',
acl_list=> XS$NAME_LIST('HRACL'),
is_static=> TRUE);
マテリアライズド・ビュー(MV)を使用して、保護される表の行と、それらを保護するACLとの間のバインドを維持します。これらは、静的データ・レルムがデータ・セキュリティ・ポリシーに含まれるたびに自動的に生成されます。これらのMVでは、完全リフレッシュのみがサポートされ、最大125個のACLが任意の単一行に関連付けられます。
生成されるMVの形式は、mv(TABLEROWID, ACLIDLIST)となりますが、ここでTABLEROWIDは保護される表の行を示し、ACLIDLISTはRAW型の列に格納されているACLID値のリストです。個々の16バイト値が連結されてリストが構成されます。
Oracle Databaseでは、アプリケーション・ユーザーがデータ・レルムのデータに対して問合せを実行するたびに、動的データ・レルムが評価されます。動的データ・レルムを使用して、表とビューの両方の行を保護できます。動的データ・レルムは、静的データ・レルムに必要とされる要件に制約されないため、最も柔軟性があります。動的データ・レルム定義内の過度に複雑なルールは、パフォーマンスに影響する可能性があることに注意してください。
実表の更新がほとんどないか、データ・レルム・メンバーの評価ルールが複雑な場合、静的データ・レルムを使用して実表を保護することを検討する必要があります。頻繁に更新される実表は、ACLIDSの格納MVが適切にリフレッシュされなければ、そのMVとの同期を何度も失う可能性があります。管理者は、実表の統計やシステムのパフォーマンス要件に基づいて処理を決定する必要があります。
データ・レルム制約を動的にするには、そのis_static属性をFALSEに設定するか、is_static属性を省略します。次の例では、動的データ・レルムを作成しています。
realm_cons := XS$REALM_CONSTRAINT_TYPE(realm=> 'DEPARTMENT_ID in (60, 100)',
acl_list=> XS$NAME_LIST('HRACL'),
is_static=> FALSE);
realm要素で定義されたSQLで「ORA-28113: ポリシー述語にエラーがあります。」などのメッセージが表示された場合、トレース・ファイルを使用してエラーの原因を検出できます。トレース・ファイルには、実際のエラーと、問題の原因を示したVPDビューが出力されます。通常、ビューのSQLテキストを分析して解決できる単純なエラーがビューの構文に含まれます。
トレースを有効にするには、ALTER SESSION権限を持つユーザーとしてSQL*Plusにログインします。
すべてのデータ・レルム制約ルールを(解決されたパラメータ値とともに)トレース・ファイルにダンプする場合、次の文を入力します。
ALTER SESSION SET EVENTS 'TRACE[XSXDS] disk=high';
問合せの初期(ハード)解析中にXDS対応表のVPDビューをダンプする場合、次の文を入力します。
ALTER SESSION SET EVENTS 'TRACE[XSVPD] disk=high';
または、データベース・インスタンスの初期化ファイルに次の行を追加して、トレースを有効にできます。
event="TRACE[XSXDS] disk=high" event="TRACE[XSVPD] disk=high"
このトレース・ファイルの場所を検出するには、次のSQLコマンドを発行します。
SHOW PARAMETER USER_DUMP_DEST;
トレースを無効にする必要がある場合、次の文を発行します。
ALTER SESSION SET EVENTS 'TRACE[XSVPD] off'; ALTER SESSION SET EVENTS 'TRACE[XSXDS] off';
関連項目:
トレース・ファイルの使用方法の詳細は、Oracle Database管理者ガイドを参照してください。
デフォルトでは、行に対するアクセスは、データ・レルムに関連付けられたACLによって保護されます。また、カスタム・アプリケーション権限を使用して特定の列を保護できます。
表Tの列を保護するには、表Tに適用されるデータ・セキュリティ・ポリシーに列制約のリストを追加します。
注意:
Real Application Securityでは内部仮想列を使用して認可インジケータを計算および格納するため、1000列に近い表の場合は、保護できる列数に制限があります。列数と保護対象列数の合計が1000以下であることが必要です。(表の列数 + 表の保護対象列数 <=1000)。たとえば、表の列数が998の場合は、最大2列の保護が許可される一方、表の列数が990の場合は、最大10列の保護が許可されます。保護対象の列数が許可された数を超える場合は、「ORA-28113: ポリシー述語にエラーがあります。」が戻されます。
たとえば、OEスキーマのPRODUCT_INFORMATION表には、LIST_PRICE列が含まれます。製品価格の表示を特定のカテゴリに制限する場合、ログインしている販売担当者のみが自分の管理しているカテゴリの製品の定価を参照できるように、追加のアプリケーション権限をLIST_COLUMN表に適用できます。
例5-3に、ACCESS_PRICEアプリケーション権限でLIST_PRICE列を保護する列制約を示します。
列制約を追加する前には、カテゴリ13および14の製品に対応するOE.PRODUCT_INFORMATION表の次の列を対象とするSELECT文によって、次の出力が示されます。
| PRODUCT_ID | PRODUCT_NAME | CATEGORY_ID | LIST_PRICE |
|---|---|---|---|
3400 |
HD 8GB /SE |
13 |
389 |
3355 |
HD 8GB /SI |
13 |
NULL |
2395 |
32MB Cache /M |
14 |
123 |
1755 |
32MB Cache /NM |
14 |
121 |
... |
... |
... |
... |
列制約の適用後、カテゴリ13を管理する販売担当者には、次の出力が示されます。
| PRODUCT_ID | PRODUCT_NAME | CATEGORY_ID | LIST_PRICE |
|---|---|---|---|
3400 |
HD 8GB /SE |
13 |
389 |
3355 |
HD 8GB /SI |
13 |
NULL |
2395 |
32MB Cache /M |
14 |
NULL |
1755 |
32MB Cache /NM |
14 |
NULL |
... |
... |
... |
... |
これに対し、カテゴリ14を管理する販売担当者には、次の出力が示されます。
| PRODUCT_ID | PRODUCT_NAME | CATEGORY_ID | LIST_PRICE |
|---|---|---|---|
3400 |
HD 8GB /SE |
13 |
NULL |
3355 |
HD 8GB /SI |
13 |
NULL |
2395 |
32MB Cache /M |
14 |
123 |
1755 |
32MB Cache /NM |
14 |
121 |
... |
... |
... |
... |
これらの例では、製品3355の定価はNULLです。中間層アプリケーションで認可済データの実際の値(NULLを含むことが可能)と未認可の値(常にNULL)を区別するには、COLUMN_AUTH_INDICATOR SQLファンクションを使用して行の列値が認可されているかどうかを確認します。未認可のデータをNULL以外の値でマスクするには、COLUMN_AUTH_INDICATOR SQLファンクションを含むDECODEまたはCASE関数を使用するようにSELECT文を変更します。
例5-4に、COLUMN_AUTH_INDICATORファンクションを使用して未認可のデータを確認し、DECODE関数を使用してNULLを値restrictedに置換するSELECT文を示します。
これ以降、NULLのかわりにマスクされた値が表示されます。たとえば、カテゴリ13の販売担当者がログオンして製品の定価を検索すると、次の出力が示されます。
| PRODUCT_ID | PRODUCT_NAME | CATEGORY_ID | LIST_PRICE |
|---|---|---|---|
3400 |
HD 8GB /SE |
13 |
389 |
3355 |
HD 8GB /SI |
13 |
NULL |
2395 |
32MB Cache /M |
14 |
restricted |
1755 |
32MB Cache /NM |
14 |
restricted |
... |
... |
... |
... |
関連項目:
列レベルのセキュリティを使用する既存の表をリストした列制約のデータ・ディクショナリ・ビューの詳細は、Oracle Database Real Application Securityデータ・ディクショナリ・ビューを参照してください。
データ・セキュリティ・ポリシー内の列制約要素の例は、例5-1を参照してください。
アプリケーションでOracle Call Interface (OCI)またはJDBCを使用する場合、列の認可のためのOCIおよびJDBCアプリケーションの構成を参照してください。
例5-3 適用された追加のアプリケーション権限のある列
column_cons :=
XS$COLUMN_CONSTRAINT_LIST(
XS$COLUMN_CONSTRAINT_TYPE(column_list=> XS$LIST('LIST_PRICE'),
privilege=> 'ACCESS_PRICE'));
例5-4 認可済データの確認およびNULL値のマスク
SELECT PRODUCT_ID, PRODUCT_NAME, CATEGORY_ID DECODE(COLUMN_AUTH_INDICATOR(LIST_PRICE), 0, 'restricted', 1, LIST_PRICE) LIST_PRICE FROM PRODUCT_INFORMATION WHERE CATEGORY_ID = 13;
XS_DATA_SECURITY.APPLY_OBJECT_POLICYプロシージャによって、表またはビューにデータ・セキュリティ・ポリシーを適用します。
XS_DATA_SECURITY.APPLY_OBJECT_POLICYプロシージャを使用して、データベース表またはビューに対してReal Application Securityを有効にします。例5-5では、OE.ORDERS表に対してORDERS_DSデータ・セキュリティ・ポリシーを有効にしています。詳細は、APPLY_OBJECT_POLICYプロシージャを参照してください。
例5-5 XS_DATA_SECURITY.APPLY_OBJECT_POLICYの使用
BEGIN SYS.XS_DATA_SECURITY.APPLY_OBJECT_POLICY(policy=>'ORDERS_DS',
schema=>'OE',
object=>'ORDERS');
END;
表またはビューに対して複数のデータ・セキュリティ・ポリシーを適用できます。表またはビューが複数のデータ・セキュリティ・ポリシーによって保護されている場合、アプリケーション・ユーザーは、すべてのポリシーによって許可されている行にのみアクセスできます。たとえば、ある行がポリシー1のデータ・レルムに含まれているが、同じ行がポリシー2のデータ・レルムに含まれていない場合、アプリケーション・ユーザーはその行にアクセスできません。
列セキュリティも同じように機能します。列Col1が複数のポリシーで保護されている場合について検討します(Policy1がPriv1で列を保護し、Policy2がPriv2で列を保護するなど)。Col1にアクセスするには、アプリケーション・ユーザーにすべてのアプリケーション権限(Priv1、Priv2など)が付与されている必要があります。つまり、列ポリシーによって保護される列では、列を保護しているすべてのポリシーによってアプリケーション・ユーザーにアクセス権が付与される必要があります。
前述のデータ・レルムの構造の理解についてに示されている次のOE.ORDERS表は、XS_DATA_SECURITY.APPLY_OBJECT_POLICYを使用して有効化されています。これには、SYS_ACLOID非表示列が追加されています。この列は、データ型がNUMBERで、アプリケーション・ユーザー管理のACL識別子をリストしています。次の表には、アプリケーション・ユーザー管理のACL識別子の500が含まれており、これは注文ID 2356によって識別されるオブジェクト・インスタンスに対する直接の権限付与です。
注意:
SYS_ACLOID非表示列は、XS_DATA_SECURITYプロシージャの起動時にapply_optionパラメータに値XS_DATA_SECURITY.APPLY_ACLOID_COLUMNを渡すことによって有効化できます。Real Application Securityでは、1つのACLIDのみをSYS_ACLOID列に追加できます。
| ORDER_ID | CUSTOMER_ID | ORDER_STATUS | SALES_REP_ID | ORDER_TOTAL | SYS_ALCOID |
|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
システム管理の静的ACL識別子は、マテリアライズド・ビュー(MV)に格納されます。
| TABLEROWID | ACLIDLIST |
|---|---|
|
|
|
|
表に関連付けられたデータ・レルムまたはデータ・レルム制約の詳細情報を確認するには、DBA_XS_REALM_CONSTRAINTSデータ・ディクショナリ・ビューを問い合せます。詳細は、DBA_XS_REALM_CONSTRAINTSを参照してください。
Oracle DatabaseがACLのセットを評価する場合、最初の付与または拒否が検出された時点で評価を停止します。そのため、ACLの順序を慎重に計画することが重要です。表の各行に関連付けられたACLは、次の順序で評価されます。
オブジェクト・インスタンスに対する直接の権限付与によるACL (アプリケーション・ユーザー管理のACL識別子)が最初に評価されます。ACLを作成してオブジェクト・インスタンスに追加する方法の詳細は、アクセス制御リストの構成についてを参照してください。
静的データ・レルム制約の権限付与によるACLが、アプリケーション・ユーザー管理のACLの次に評価されます。複数の静的データ・レルムがある場合、それらはデータ・セキュリティ・ポリシーに物理的に出現する順序で評価されます。静的データ・レルムの詳細は、静的データ・レルムの使用についてを参照してください。
動的データ・レルム制約の権限付与によるACLが、最後に評価されます。複数の動的データ・レルムがある場合、それらはポリシーに物理的に出現する順序で評価されます。動的データ・レルムの詳細は、静的データ・レルムの使用についてを参照してください。
マスター/ディテール表の詳細は、Oracle Database 2日でJava開発者ガイドのJPAおよびOracle ADFを使用したマスター/ディテール・アプリケーションの作成に関する章を参照してください。
マスター/ディテール関連表で使用できるデータ・セキュリティ・ポリシーを作成できます。通常、マスター表を保護するものと同じポリシーでそのディテール表を保護できます。マスター/ディテール表のReal Application Securityポリシーを作成すると、これらの表にアクセスするすべてのユーザーが、マスター表からディテール表に継承できる統一されたポリシーに従ってこれを行うことができます。
ポリシーおよびマスター/ディテール表で使用可能な継承パスは、次のとおりです。
複数のディテール表は、1つのマスター表からポリシーを継承できます。
ディテール表は、他のディテール表からポリシーを継承できます。
1つのディテール表は、複数のマスター表からポリシーを継承できます。
マスター表のポリシーのいずれかが満たされると、アプリケーション・ユーザーは、ディテール表の対応する行にアクセスできます。
マスター/ディテール関連表のReal Application Securityポリシーを作成するには、表ごとにデータ・セキュリティ・ポリシーを作成する必要があります。ディテール表の各データ・セキュリティ・ポリシーで、マスター/ディテール・データ・レルムを含めることで、ディテール表の継承元であるマスター表を示します。マスター/ディテール関連表でReal Application Securityポリシーを作成する例の手順4、6および7に、マスター/ディテール・データ・レルムを作成および使用する方法と、マスター/ディテール・データ・セキュリティ・ポリシーを作成してマスター/ディテール表に適用する方法の例を示します。
例5-6に、マスター/ディテール・データ・レルムの例を示します。
次のように指定します。
when_conditionでは、WHERE句と同様に、データをフィルタするためのディテール表の条件を指定します。when_conditionがtrueに評価されると、Oracle Databaseによってマスター・ポリシーが適用されます。この要素はオプションです。
parent_schemaでは、マスター表を含むスキーマの名前を指定します。
parent_objectでは、マスター表の名前を指定します。
primary_keyでは、マスター表の主キーを指定します。
foreign_keyでは、ディテール表の外部キーを指定します。
例5-6 マスター/ディテール・データ・レルム
realm_cons := XS$REALM_CONSTRAINT_TYPE
(parent_schema=> 'OE',
parent_object=> 'CUSTOMERS',
key_list=> XS$KEY_LIST(XS$KEY_TYPE(primary_key=> 'CUSTOMER_ID',
foreign_key=> 'CUSTOMER_ID',
foreign_key_type=> 1)),
when_condition=> 'ORDER_STATUS IS NOT NULL')
この例では、SHサンプル・スキーマを使用します。SHスキーマには、マスター表であるCUSTOMERSという表があります。マスター表のCUSTOMERSには、SALESというディテール表と、COUNTRIESというもう1つのディテール表が含まれます。次の例では、CUSTOMERS表とSALES表の読取りアクセスのためにCOUNTRIES表で定義された地域境界とともに顧客および販売データを実質的に分割するReal Application Securityポリシーを施行する方法を示します。また、ユーザーに対して列CUST_INCOME_LEVELおよびCUST_CREDIT_LIMITのデータをマスクする要件があります(ビジネス分析のために完全な表アクセスを必要とするビジネス・アナリストなどのユーザーを除く)。
注意:
この例のすべての管理コマンドは、データベースのDBAロールを持つSYSTEMアカウントなどのデータベース・ユーザーによって実行できます(DBAロールには、Real Application Security管理タスクの適切な権限が付与されているため)。さらに、セキュリティ・クラス、ACLおよびデータ・セキュリティ・ポリシーはスキーマ修飾オブジェクトであるため、これらのオブジェクトは、APIに指定する場合は目的のスキーマ名を明示的に使用する必要があり、データベース・セッションのデフォルト・スキーマであるSYSTEMではオブジェクトに解決されません。
すべて同じスキーマ(SH)に含まれる3つの表の説明は、次のとおりです。
-- SH.CUSTOMERS in the master table. Name Null? Type ----------------------------------------- -------- ---------------------------- CUST_ID NOT NULL NUMBER CUST_FIRST_NAME NOT NULL VARCHAR2(20) CUST_LAST_NAME NOT NULL VARCHAR2(40) CUST_GENDER CHAR(1) CUST_YEAR_OF_BIRTH NUMBER(4) CUST_MARITAL_STATUS VARCHAR2(20) CUST_STREET_ADDRESS NOT NULL VARCHAR2(40) CUST_POSTAL_CODE NOT NULL VARCHAR2(10) CUST_CITY NOT NULL VARCHAR2(30) CUST_STATE_PROVINCE VARCHAR2(40) COUNTRY_ID NOT NULL CHAR(2) CUST_MAIN_PHONE_NUMBER VARCHAR2(25) CUST_INCOME_LEVEL VARCHAR2(30) CUST_CREDIT_LIMIT NUMBER CUST_EMAIL VARCHAR2(30) -- SH.SALES is a detail table. Name Null? Type ----------------------------------------- -------- ---------------------------- PROD_ID NOT NULL NUMBER(6) CUST_ID NOT NULL NUMBER TIME_ID NOT NULL DATE CHANNEL_ID NOT NULL CHAR(1) PROMO_ID NOT NULL NUMBER(6) QUANTITY_SOLD NOT NULL NUMBER(3) AMOUNT_SOLD NOT NULL NUMBER(10,2) -- SH.COUNTRIES is a detail table. Name Null? Type ----------------------------------------- -------- ---------------------------- COUNTRY_ID NOT NULL CHAR(2) COUNTRY_NAME NOT NULL VARCHAR2(40) COUNTRY_SUBREGION VARCHAR2(30) COUNTRY_REGION VARCHAR2(20)
図5-2に、作成されてマスター/ディテール関連表(CUSTOMERS - SALES - COUNTRIES)に適用される完全なReal Application Securityデータ・セキュリティ・ポリシーの概要を示します(次の手順で概要を、この図に続く手順で詳細を説明します)。
ビジネス・アナリスト・ロールおよび関連するアプリケーション・ユーザーに加えて、ヨーロッパ、アメリカ、アジアおよびアフリカという4つの地理的地域ごとにプリンシパル(アプリケーション・ロールおよびアプリケーション・ユーザー)を作成します。
VIEW_SENSITIVE_INFO権限を作成し、その権限を対象範囲とするSH.CUST_SEC_CLASSを作成します。
ビジネス・アナリスト・ロールにVIEW_SENSITIVE_INFO権限を付与します。
後でポリシーで使用する文字列®IONをシステムで認識するため、地域をパラメータ化するルールを含むデータ・レルム制約を定義します。
VIEW_SENSITIVE_INFO権限を使用して2つの列CUST_INCOME_LEVELおよびCUST_CREDIT_LEVELを保護する列制約を作成します。
前に作成したデータ・レルム制約および列制約を指定するデータ・セキュリティ・ポリシーSH.CUSTOMER_DSを作成します。
SH.CUSTOMER_DSデータ・セキュリティ・ポリシーのルールにパラメータの名前およびデータ型を登録します。
地域ごとにACLを作成して、読取りアクセスを必要とする各ロールに対して読取りアクセス権を許可します。ヨーロッパ地域の例では、SELECT権限をEurope_salesロールに付与し、SELECTおよびVIEW_SENSITIVE_INFO権限をBusiness_Analystロールに付与します。
パラメータREGIONの値が地域名(ヨーロッパなど)と等しいというルールを満たす行に、各地域の各ACLを関連付けます。4つの各地域に対してこれを行い、このACLをSH.CUSTOMER_DSデータ・セキュリティ・ポリシーに追加します。
マスター/ディテール表のデータ・レルム制約を作成し、CUSTOMERSマスター表の親の行に対するアクセスがユーザーに許可されている場合にのみ、ユーザーがSALESディテール表のレコードにアクセスできるようにします。
SH.SALES_DSデータ・セキュリティ・ポリシーを作成してこのデータ・レルム制約を施行します。
図5-2のマスター/ディテール表には、主キー(PK)・フィールドおよび外部キー(FK)・フィールドと、データ・レルム制約および列制約を作成する際に使用される複数の追加フィールドも示されています。これらのPKおよびFK関係を使用すると、マスター表に適用されるものと同じデータ・セキュリティ・ポリシーがディテール表にも適用されます。この特定の場合、たとえば、SELECT権限をCUSTOMERSマスター表に付与し、SH.CUSTOMER_DSデータ・セキュリティ・ポリシーによって施行されるすべてのACLもSALESディテール表に適用されます。
図5-2 マスター/ディテール関連表に作成されたReal Application Securityデータ・セキュリティ・ポリシー
これらのマスター/ディテール表のReal Application Securityポリシーを作成するには、次の手順を実行します。
SQL*Plus SET SECUREDCOLコマンドでは、列を参照する権限を持たないユーザーや、セキュリティが不明な列を対象とするSQL*Plusの出力で、セキュアな列値を表示する方法をカスタマイズできます。デフォルト・テキストを選択するか、表示するテキストを指定できます。デフォルトは、OFFです。
列レベルのセキュリティが有効で、SET SECUREDCOLがONに設定されている場合、保護された列またはセキュリティ・レベルが不明な列を対象とするSQL*Plusの出力は、カスタマイズされたテキストまたはデフォルト・インジケータに置き換えられます。これは、スカラー・データ型にのみ適用されます。複合オブジェクトのデータ出力は影響を受けません。
構文
SET SECUREDCOL {OFF¦ON} [UNAUTH[ORIZED] text][UNK[NOWN] text]
パラメータ
| パラメータ | 説明 |
|---|---|
|
列を表示する権限のないユーザーには、列値のかわりにデフォルト・インジケータのアスタリスク( デフォルトでは、このコマンドは |
|
列を表示する権限のないアプリケーション・ユーザーの列値のかわり、および列のセキュリティ・レベルが不明な列値のかわりに、NULL値が表示されます。 |
|
テキストによって、列を表示する権限のないアプリケーション・ユーザーに対して、保護された列に表示するテキストを指定できます。このテキストは、デフォルトの 列長または最大30文字まで任意の英数字テキストを指定できます。これより長いテキストは切り捨てられます。空白を含むテキストは、引用符で囲む必要があります。 |
|
テキストによって、セキュリティ・レベルが不明な列に表示されるテキストを指定できます(列に適用されている特定の権限が不明でない場合)。このテキストは、デフォルトの 列長または最大30文字まで任意の英数字テキストを指定できます。これより長いテキストは切り捨てられます。空白を含むテキストは、引用符で囲む必要があります。 |
例1
SET SECUREDCOL ON SELECT empno, ename, sal FROM emp ORDER BY deptno;
この例の出力は次のとおりです。
EMPNO ENAME DEPTNO SAL ----- ------ ------ -------- 7539 KING 10 ******** 7369 SMITH 20 800 7566 JONES 20 2975 7788 SCOTT 20 3000 7521 WARD 30 ******** 7499 ALLEN 30 ******** 6 rows selected.
例2
SET SECUREDCOL ON UNAUTH notallowed SELECT empno, ename, sal FROM emp ORDER BY deptno;
この例の出力は次のとおりです。
EMPNO ENAME DEPTNO SAL ----- ------ ------ ------- 7539 KING 10 notallowed 7369 SMITH 20 800 7566 JONES 20 2975 7788 SCOTT 20 3000 7521 WARD 30 notallowed 7499 ALLEN 30 notallowed 6 rows selected.
従来、Oracle Databaseのビューは定義者権限を使用しています。つまり、アイデンティティまたは権限に影響を受けるSQLファンクションを実行する場合や、実行者権限のPL/SQLまたはJavaファンクションを実行する場合に、現在のスキーマおよび現在のユーザーがビューの所有者に設定され、現在有効になっているロールがファンクションの実行範囲内でビューの所有者に加えてPUBLICに設定されます。
実行者権限と定義者権限のバックグラウンド情報を必要とする場合、Oracle Database PL/SQL言語リファレンスを参照してください。
注意:
一部の組込みSQLファンクション(SYS_CONTEXT()やUSERENV()など)は、前述のルールの例外です。これらのファンクションは、定義者権限のビューからコールされても、常に現在のアプリケーション・ユーザーの環境を使用します。
Oracle Database 12cリリース1 (12.1)以降では、この動作を構成するBEQUEATH句でビューを作成できます。BEQUEATH句は、アイデンティティまたは権限に影響を受けるSQLファンクション、実行者権限のPL/SQLプログラム・ユニット、およびビューで参照されているJavaファンクションが現在のスキーマ、現在のユーザーおよび現在有効になっているロールを問合せ元ユーザーの環境から継承するかどうかを決定します。これは、起動元のアプリケーション・ユーザーの環境で頻繁にコードを実行する必要のあるReal Application Securityアプリケーションにとって特に便利です。
ビュー定義でBEQUEATH CURRENT_USERを使用して、ビューで参照されている、権限に影響を受ける実行者権限のファンクションが現在のスキーマ、現在のユーザーおよび現在有効になっているロールを問合せ元ユーザーの環境から継承することを許可するビューを作成します。CREATE OR REPLACE VIEW文の構文は、Oracle Database SQL言語リファレンスを参照してください。
例5-7に、BEQUEATH CURRENT_USERビューで、実行者権限のプログラム・ユニットを起動元のアプリケーション・ユーザーの環境で実行できるようにする方法を示します。USER2がUSER1のビューから選択する場合、実行者権限のファンクションはUSER2の環境で起動されます。
ビュー定義でBEQUEATH DEFINERを使用して、ビューで参照されている、権限に影響を受ける実行者権限のファンクションが現在のスキーマ、現在のユーザーおよび現在有効になっているロールをビュー定義者の環境から継承させるビューを作成します。BEQUEATH句が指定されていない場合、BEQUEATH DEFINERであるとみなされます。
BEQUEATH_DEFINERビューにBEQUEATH CURRENT_USERビューへの参照が含まれる場合、参照されるビューの実行者権限のファンクションでは親ビューの所有者の権限が使用されます。
例5-8に、BEQUEATH DEFINERビューによって、ビュー所有者の環境でネストした実行者権限のプログラム・ユニットを実行するための境界を定義する方法を示します。USER2がUSER1のビューから選択を行うと、ビューの実行者権限のファンクションがUSER1の環境で起動されます。
関連項目:
VPDおよびFGAポリシーでの実行者権限および定義者権限の使用の詳細は、Oracle Databaseセキュリティ・ガイドを参照してください。
例5-7 BEQUEATH CURRENT_USERビューの動作方法
SQL> CONNECT USER1/USER1
Connected.
SQL>
SQL> -- You first create an invoker's rights function to determine who the current SQL> -- user really is.
SQL> CREATE OR REPLACE FUNCTION CALLED_AS_USER RETURN VARCHAR2 AUTHID CURRENT_USER IS
2 BEGIN
3 RETURN SYS_CONTEXT('USERENV', 'CURRENT_USER');
4 END;
5 /
Function created.
SQL> -- Note that you do not need to grant EXECUTE to called_as_user, because even
SQL> -- BEQUEATH CURRENT_USER views do name resolution and privilege checking on
SQL> -- the references present in the view body using definer's rights.
SQL> CREATE OR REPLACE VIEW BEQUEATH_INVOKER_VIEW BEQUEATH CURRENT_USER AS
2 SELECT CALLED_AS_USER FROM DUAL;
View created.
SQL> GRANT SELECT ON BEQUEATH_INVOKER_VIEW TO PUBLIC;
Grant succeeded.
SQL> CONNECT USER2/USER2
Connected.
SQL> SELECT * FROM USER1.BEQUEATH_INVOKER_VIEW;
CALLED_AS_USER
--------------------------------------------------------------------------------
USER2
例5-8 BEQUEATH DEFINERビューの動作方法
SQL> CONNECT USER1/USER1
Connected.
SQL>
SQL> -- You first create an invoker's rights function to determine who the current SQL> -- user really is.
SQL> CREATE OR REPLACE FUNCTION CALLED_AS_USER RETURN VARCHAR2 AUTHID CURRENT_USER IS
2 BEGIN
3 RETURN SYS_CONTEXT('USERENV', 'CURRENT_USER');
4 END;
5 /
Function created.
SQL> -- Note that you do not need to grant EXECUTE to called_as_user, because even
SQL> -- BEQUEATH CURRENT_USER views do name resolution and privilege checking on
SQL> -- the references present in the view body using definer's rights.
SQL> CREATE OR REPLACE VIEW BEQUEATH_DEFINER_VIEW BEQUEATH DEFINER AS
2 SELECT CALLED_AS_USER FROM DUAL;
View created.
SQL> GRANT SELECT ON BEQUEATH_DEFINER_VIEW TO PUBLIC;
Grant succeeded.
SQL> CONNECT USER2/USER2
Connected.
SQL> SELECT * FROM USER1.BEQUEATH_DEFINER_VIEW;
CALLED_AS_USER
--------------------------------------------------------------------------------
USER1
SYS_CONTEXT()、USERENV()、XS_SYS_CONTEXT()などのSQLファンクションは、定義者権限のビューからコールされた場合でも、常に現在のアプリケーション・ユーザーの環境を返します。場合によっては、アプリケーションは文で参照されているビューのセキュリティ・コンテキスト(BEQUEATHプロパティ)に基づいて起動元のアプリケーション・ユーザーを決定する必要があります。
Oracle Database 12cリリース1 (12.1)で導入された次の新しいファンクションでは、文で参照されているビューのBEQUEATHプロパティを考慮して、起動元のアプリケーション・ユーザーを特定できます。
ORA_INVOKING_USER: このファンクションを使用すると、コンテキストが現在使用されているデータベース・ユーザーの名前が返されます。ファンクションが定義者権限の境界内から起動されると、データベース・オブジェクト所有者の名前が返されます。起動するユーザーがReal Application Securityアプリケーション・ユーザーである場合、定数XS$USERが返されます。
ORA_INVOKING_USERID: このファンクションを使用すると、コンテキストが現在使用されているデータベース・ユーザーの識別子(ID)が返されます。ファンクションが定義者権限の境界内から起動されると、データベース・オブジェクト所有者のIDが返されます。
起動するユーザーがReal Application Securityアプリケーション・ユーザーである場合、ファンクションによって、すべてのReal Application Securityアプリケーション・ユーザーに共通だが、任意のデータベース・ユーザーの識別子とは異なる識別子が返されます。
ORA_INVOKING_XS_USER: このファンクションを使用すると、コンテキストが現在使用されているReal Application Securityアプリケーション・ユーザーの名前が返されます。
起動するユーザーがデータベース・ユーザーである場合、値NULLが返されます。
ORA_INVOKING_XS_USER_GUID: このファンクションを使用すると、コンテキストが現在使用されているReal Application Securityアプリケーション・ユーザーの識別子(ID)が返されます。
起動するユーザーがデータベース・ユーザーである場合、値NULLが返されます。
次の例に、ORA_INVOKING_USERおよびORA_INVOKING_XS_USERを問い合せるデータベース・ユーザーUSER1を示します。このユーザーはReal Application Securityアプリケーション・ユーザーではないため、ORA_INVOKING_XS_USERではNULLが返されます。
SQL> CONNECT USER1 Enter password: Connected. SQL> SELECT ORA_INVOKING_USER FROM DUAL; ORA_INVOKING_USER -------------------------------------------------------------------------------- USER1 SQL> SELECT ORA_INVOKING_XS_USER FROM DUAL; ORA_INVOKING_XS_USER --------------------------------------------------------------------------------
関連項目:
前述のSQLファンクションおよびSYS_CONTEXTなどの他のファンクションの詳細は、Oracle Database SQL言語リファレンスを参照してください。
この項では、基本的なデータ・セキュリティ・ポリシーを定義するために、Real Application Securityのすべての概念をまとめます。これは、シナリオ: 従業員情報のセキュリティ人事管理(HR)デモで紹介したHRシナリオ例に基づいています。
この項では、例を参考にしながら、シナリオで説明されている各実装タスクについて検討します。
Real Application Securityコンポーネントを作成する前に、まずデータベース・ユーザーをReal Application Security管理者として作成し、この管理者にdbaおよびxs_session_admin権限を付与してから、Real Application Security管理者としてデータベースに接続する必要があります。
例5-9 データベース・ユーザーの作成
SQL> connect sys/password as sysdba Connected. SQL> grant dba, xs_session_admin to rasadm identified by rasadm; Grant succeeded. SQL> connect rasadm/password; Connected.
データベース・ロールの作成
データベース・ロールDB_EMPを作成し、このロールに必要な表権限を付与します。このロールを使用して、アプリケーション・ユーザーに必要なオブジェクト権限を付与します。
アプリケーション・ロールの作成
アプリケーション・ロールへのDB_EMPデータベース・ロールの付与
3つのアプリケーション・ロールにDB_EMPデータベース・ロールを付与して、それぞれが表へのアクセスに必要なオブジェクト権限を持つようにします。
アプリケーション・ユーザーの作成
アプリケーション・ユーザーDAUSTINを(IT部門に)作成し、ユーザー・アプリケーション・ロールEMP_ROLEおよびIT_ROLEを付与します。
この例では、次のようになります。
注意:
ログインを簡単にするために、大文字の名前を作成できます。これによって、ユーザーは、SQL*Plusへのログイン時または接続時に引用符を省略できます。たとえば、次のようになります。
sqlplus DAUSTIN
関連項目:
アプリケーション・ユーザーのデータベース・ログインに影響する大/小文字区別の詳細は、単純なアプリケーション・ユーザー・アカウントの作成を参照してください。
アプリケーション・ユーザーSMAVRISを(HR部門に)作成し、ユーザー・アプリケーション・ロールEMP_ROLEおよびHR_ROLEを付与します。
例5-10 DB_EMPデータベース・ユーザーの作成
SQL> create role db_emp; Role created. SQL> grant select, insert, update, delete on hr.employees to db_emp; Grant succeeded.
例5-11 一般的な従業員用のアプリケーション・ロールEMP_ROLEの作成
SQL> exec sys.xs_principal.create_role(name => 'emp_role', enabled => true); PL/SQL procedure successfully completed.
例5-12 IT部門用のアプリケーション・ロールIT_ROLEの作成
SQL> exec sys.xs_principal.create_role(name => 'it_role', enabled => true); PL/SQL procedure successfully completed.
例5-13 HR部門用のアプリケーション・ロールHR_ROLEの作成
SQL> exec sys.xs_principal.create_role(name => 'hr_role', enabled => true); PL/SQL procedure successfully completed.
例5-14 各アプリケーション・ロールへのDB_EMPデータベース・ロールの付与
SQL> grant db_emp to emp_role; Grant succeeded. SQL> grant db_emp to it_role; Grant succeeded. SQL> grant db_emp to hr_role; Grant succeeded.
例5-15 アプリケーション・ユーザーDAUSTINの作成
SQL> exec sys.xs_principal.create_user(name => 'daustin', schema => 'hr');
PL/SQL procedure successfully completed.
SQL> exec sys.xs_principal.set_password('daustin', 'password');
PL/SQL procedure successfully completed.
SQL> exec sys.xs_principal.grant_roles('daustin', 'emp_role');
PL/SQL procedure successfully completed.
SQL> exec sys.xs_principal.grant_roles('daustin', 'it_role');
PL/SQL procedure successfully completed.
例5-16 アプリケーション・ユーザーSMAVRISの作成
SQL> exec sys.xs_principal.create_user(name => 'smavris', schema => 'hr');
PL/SQL procedure successfully completed.
SQL> exec sys.xs_principal.set_password('smavris', 'password');
PL/SQL procedure successfully completed.
SQL> exec sys.xs_principal.grant_roles('smavris', 'emp_role');
PL/SQL procedure successfully completed.
SQL> exec sys.xs_principal.grant_roles('smavris', 'hr_role');
PL/SQL procedure successfully completed.
セキュリティ・クラスの作成
事前定義済のDMLセキュリティ・クラスに基づいてセキュリティ・クラスHRPRIVSを作成します。HRPRIVSには、SALARY列へのアクセスを制御する新しい権限VIEW_SALARYがあります。
ACLの作成
EMP_ACL、IT_ACLおよびHR_ACLの3つのACLを作成して、後で定義するデータ・セキュリティ・ポリシーの権限を付与します。
この例では、次のようになります。
行11から13: EMP_ACLを作成し、EMP_ROLEにSELECTおよびVIEW_SALARY権限を付与します。
行21から23: IT_ACLを作成し、IT_ROLEにSELECT権限を付与します。
行30から32: HR_ACLを作成し、HR_ROLEにALL権限を付与します。ALL権限は、ACLのセキュリティ・クラス内のすべての権限を意味します。この場合、ALL権限には、すべての従業員のレコードの表示と更新を行うためのSELECT、INSERT、UPDATEおよびDELETEデータベース権限と、SALARY列を表示するためのVIEW_SALARYアプリケーション権限の付与が含まれます。
例5-17 HRPRIVSセキュリティ・クラスの作成
SQL> declare
2 begin
3 xs_security_class.create_security_class(
4 name => 'hrprivs',
5 parent_list => xs$name_list('sys.dml'),
6 priv_list => xs$privilege_list(xs$privilege('view_salary')));
7 end;
8 /
PL/SQL procedure successfully completed.
例5-18 ACLの作成: EMP_ACL、IT_ACLおよびHR_ACL
SQL> declare
2 aces xs$ace_list := xs$ace_list();
3 begin
4 aces.extend(1);
5
6 -- EMP_ACL: This ACL grants EMP_ROLE the privileges to view an employee's
7 -- own record including SALARY column.
8 aces(1) := xs$ace_type(privilege_list => xs$name_list('select','view_salary'),
9 principal_name => 'emp_role');
10
11 sys.xs_acl.create_acl(name => 'emp_acl',
12 ace_list => aces,
13 sec_class => 'hrprivs');
14
15 -- IT_ACL: This ACL grants IT_ROLE the privilege to view the employee
16 -- records in IT department, but it does not grant the VIEW_SALARY
17 -- privilege that is required for access to SALARY column.
18 aces(1) := xs$ace_type(privilege_list => xs$name_list('select'),
19 principal_name => 'it_role');
20
21 sys.xs_acl.create_acl(name => 'it_acl',
22 ace_list => aces,
23 sec_class => 'hrprivs');
24
25 -- HR_ACL: This ACL grants HR_ROLE the privileges to view and update all
26 -- employees' records including SALARY column.
27 aces(1):= xs$ace_type(privilege_list => xs$name_list('all'),
28 principal_name => 'hr_role');
29
30 sys.xs_acl.create_acl(name => 'hr_acl',
31 ace_list => aces,
32 sec_class => 'hrprivs');
33 end;
34 /
PL/SQL procedure successfully completed.
EMPLOYEES表のデータ・セキュリティ・ポリシーを作成します。ポリシーは、SALARY列を保護する3つのデータ・レルム制約と1つの列制約を定義します。
この例では、次のようになります。
行7から23: 3つのデータ・レルム制約を定義します。
行27から30: SALARY列の表示にVIEW_SALARYアプリケーション権限を要求する列制約を定義します。
行32から35: 3つのデータ・レルム制約と列制約を含むEMPLOYEES_DSデータ・セキュリティ・ポリシーを作成します。
表へのデータ・セキュリティ・ポリシーの適用
EMPLOYEES表にデータ・セキュリティ・ポリシーを適用します。
例5-19 EMPLOYEES_DSデータ・セキュリティ・ポリシーの作成
SQL> declare
2 realms xs$realm_constraint_list := xs$realm_constraint_list();
3 cols xs$column_constraint_list := xs$column_constraint_list();
4 begin
5 realms.extend(3);
6
7 -- Realm #1: Only the employee's own record.
8 -- EMP_ROLE can view the realm including SALARY column.
9 realms(1) := xs$realm_constraint_type(
10 realm => 'email = xs_sys_context(''xs$session'',''username'')',
11 acl_list => xs$name_list('emp_acl'));
12
13 -- Realm #2: The records in the IT department.
14 -- IT_ROLE can view the realm excluding SALARY column.
15 realms(2) := xs$realm_constraint_type(
16 realm => 'department_id = 60',
17 acl_list => xs$name_list('it_acl'));
18
19 -- Realm #3: All the records.
20 -- HR_ROLE can view and update the realm including SALARY column.
21 realms(3) := xs$realm_constraint_type(
22 realm => '1 = 1',
23 acl_list => xs$name_list('hr_acl'));
24
25 -- Column constraint protects SALARY column by requiring VIEW_SALARY
26 -- privilege.
27 cols.extend(1);
28 cols(1) := xs$column_constraint_type(
29 column_list => xs$list('salary'),
30 privilege => 'view_salary');
31
32 sys.xs_data_security.create_policy(
33 name => 'employees_ds',
34 realm_constraint_list => realms,
35 column_constraint_list => cols);
36 end;
37 /
PL/SQL procedure successfully completed.
例5-20 EMPLOYEES表へのEMPLOYEES_DSセキュリティ・ポリシーの適用
SQL> begin 2 sys.xs_data_security.apply_object_policy( 3 policy => 'employees_ds', 4 schema => 'hr', 5 object =>'employees'); 6 end; 7 / PL/SQL procedure successfully completed.
これらのReal Application Securityオブジェクトを作成した後で、これらを検証してすべて正しく構成されていることを確認します。
例5-21 Real Application Securityオブジェクトの検証
SQL> set serveroutput on;
SQL> begin
2 if (xs_diag.validate_workspace()) then
3 dbms_output.put_line('All configurations are correct.');
4 else
5 dbms_output.put_line('Some configurations are incorrect.');
6 end if;
7 end;
8 /
All configurations are correct.
PL/SQL procedure successfully completed.
SQL> -- XS$VALIDATION_TABLE contains validation errors if any.
SQL> -- Expect no rows selected.
SQL> select * from xs$validation_table order by 1, 2, 3, 4;
no rows selected
例5-22に、表HR.EMPLOYEESのデータ・セキュリティを無効にする補足的な操作を示します。
例5-22 表のデータ・セキュリティ・ポリシーの無効化
BEGIN SYS.XS_DATA_SECURITY.DISABLE_OBJECT_POLICY(policy => 'EMPLOYEES_DS', schema => 'HR', object => 'EMPLOYEES'); END; /
セキュリティHRデモは2通りの方法で実行されます。
最初にアプリケーション・ユーザーDAUSTINとして直接ログオンを実行してから、アプリケーション・ユーザーSMAVRISとして実行します。
どちらの場合も、各ユーザーがHR.EMPLOYEES表に対して問合せを実行し、従業員レコードとSALARY列にアクセスして表示できるかどうかを示します。このデモの説明は、直接ログオンを使用したセキュリティHRデモの実行を参照してください。
Real Application Securityセッションに連結します
このデモでは、Real Application Security管理者は、連結するアプリケーション・ユーザーに対してReal Application Securityセッションを作成します。このデモの説明は、Real Application Securityセッションに連結されたセキュリティHRデモの実行を参照してください。
