5 データ・セキュリティの構成
データ・セキュリティについて
データ・セキュリティとは、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
プロシージャでは表の行を更新するために必要なDMLstatement_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 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
プロシージャによって、表またはビューにデータ・セキュリティ・ポリシーを適用します。
APPLY_OBJECT_POLICYプロシージャを使用したReal Application Securityの有効化
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など)が付与されている必要があります。つまり、列ポリシーによって保護される列では、列を保護しているすべてのポリシーによってアプリケーション・ユーザーにアクセス権が付与される必要があります。
APPLY_OBJECT_POLICYプロシージャによるデータベース表の変更方法について
前述の「データ・レルムの構造の理解について」に示されている次の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」を参照してください。
表データに対するACLの評価方法について
Oracle DatabaseがACLのセットを評価する場合、最初の付与または拒否が検出された時点で評価を停止します。そのため、ACLの順序を慎重に計画することが重要です。表の各行に関連付けられたACLは、次の順序で評価されます。
-
オブジェクト・インスタンスに対する直接の権限付与によるACL (アプリケーション・ユーザー管理のACL識別子)が最初に評価されます。ACLを作成してオブジェクト・インスタンスに追加する方法の詳細は、アクセス制御リストの構成についてを参照してください。
-
静的データ・レルム制約の権限付与によるACLが、アプリケーション・ユーザー管理のACLの次に評価されます。複数の静的データ・レルムがある場合、それらはデータ・セキュリティ・ポリシーに物理的に出現する順序で評価されます。静的データ・レルムの詳細は、静的データ・レルムの使用についてを参照してください。
-
動的データ・レルム制約の権限付与によるACLが、最後に評価されます。複数の動的データ・レルムがある場合、それらはポリシーに物理的に出現する順序で評価されます。動的データ・レルムの詳細は、静的データ・レルムの使用についてを参照してください。
マスター/ディテール関連表のReal Application Securityポリシーの作成について
マスター/ディテール表の詳細は、Oracle Database 2日でJava開発者ガイドのJPAおよびOracle ADFを使用したマスター/ディテール・アプリケーションの作成に関する章を参照してください。
マスター/ディテール関連表のReal Application Securityポリシーについて
マスター/ディテール関連表で使用できるデータ・セキュリティ・ポリシーを作成できます。通常、マスター表を保護するものと同じポリシーでそのディテール表を保護できます。マスター/ディテール表の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')
マスター/ディテール関連表でReal Application Securityポリシーを作成する例
この例では、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データ・セキュリティ・ポリシー
「図5-2 マスター/ディテール関連表に作成されたReal Application Securityデータ・セキュリティ・ポリシー」の説明
これらのマスター/ディテール表のReal Application Securityポリシーを作成するには、次の手順を実行します。
データ・セキュリティ・ポリシーのアプリケーション権限の管理について
Real Application Securityポリシーのセキュリティ確認のバイパスについて
SQL*Plus SET SECUREDCOLコマンドの使用
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.
BEQUEATH CURRENT_USERビューの使用
従来、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
SQLファンクションを使用した起動元アプリケーション・ユーザーの特定
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: 全体のまとめ
この項では、基本的なデータ・セキュリティ・ポリシーを定義するために、Real Application Securityのすべての概念をまとめます。これは、「シナリオ: 従業員情報のセキュリティ人事管理(HR)デモ」で紹介したHR
シナリオ例に基づいています。
この項には、例を参考にしながらシナリオで説明されている各実装タスクについて検討する、次のトピックが含まれます。
基本のHRシナリオ: 実装タスク
Real Application Securityのユーザーとロールを作成するためのSYSユーザーとしての接続
Real Application Securityのユーザーとロールを作成するには、SYS
ユーザーとして接続することのみが必要になります。
例5-9 SYSユーザーとして接続
SQL> connect sys/&passwd as sysdba
Connected.
ロールおよびアプリケーション・ユーザーの作成
データベース・ロールの作成
データベース・ロールDB_EMP
を作成し、このロールに必要な表権限を付与します。このロールを使用して、アプリケーション・ユーザーに必要なオブジェクト権限を付与します。
アプリケーション・ロールの作成
アプリケーション・ロールへのDB_EMPデータベース・ロールの付与
3つのアプリケーション・ロールにDB_EMP
データベース・ロールを付与して、それぞれが表へのアクセスに必要なオブジェクト権限を持つようにします。
アプリケーション・ユーザーの作成
アプリケーション・ユーザーDAUSTIN
を(IT部門に)作成し、ユーザー・アプリケーション・ロールEMPPLOYEE
およびIT_ENGINEER
を付与します。
この例では、次のようになります。
注意:
ログインを簡単にするために、大文字の名前を作成できます。これによって、ユーザーは、SQL*Plusへのログイン時または接続時に引用符を省略できます。たとえば、次のようになります。
sqlplus DAUSTIN
関連項目:
アプリケーション・ユーザーのデータベース・ログインに影響する大/小文字区別の詳細は、単純なアプリケーション・ユーザー・アカウントの作成を参照してください。
アプリケーション・ユーザーSMAVRIS
を(HR部門に)作成し、ユーザー・アプリケーション・ロールEMPLOYEE
およびHR_REPRESENTATIVE
を付与します。
HRユーザーへのポリシー管理権限ADMIN_ANY_SEC_POLICYの付与
HR
ユーザーにADMIN_ANY_SEC_POLICY
権限を付与します。
例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 一般的な従業員用のアプリケーション・ロールEMPLOYEEの作成
SQL> exec sys.xs_principal.create_role(name => 'employee', enabled => true); PL/SQL procedure successfully completed.
例5-12 IT部門用のアプリケーション・ロールIT_ENGINEERの作成
SQL> exec sys.xs_principal.create_role(name => 'it_engineer', enabled => true); PL/SQL procedure successfully completed.
例5-13 HR部門用のアプリケーション・ロールHR_REPRESENTATIVEの作成
SQL> exec sys.xs_principal.create_role(name => 'hr_representative', enabled => true); PL/SQL procedure successfully completed.
例5-14 各アプリケーション・ロールへのDB_EMPデータベース・ロールの付与
SQL> grant db_emp to employee; Grant succeeded. SQL> grant db_emp to it_engineer; Grant succeeded. SQL> grant db_emp to hr_representative; 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', 'XSCONNECT');
PL/SQL procedure successfully completed.
SQL> exec sys.xs_principal.grant_roles('daustin', 'employee');
PL/SQL procedure successfully completed.
SQL> exec sys.xs_principal.grant_roles('daustin', 'it_engineer');
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('daustin', 'XSCONNECT');
PL/SQL procedure successfully completed.
SQL> exec sys.xs_principal.grant_roles('smavris', 'employee');
PL/SQL procedure successfully completed.
SQL> exec sys.xs_principal.grant_roles('smavris', 'hr_representative');
PL/SQL procedure successfully completed.
例5-17 HRユーザーへのポリシー管理権限ADMIN_ANY_SEC_POLICYの付与
SQL> exec sys.xs_admin_util.grant_system_privilege('ADMIN_ANY_SEC_POLICY','HR'); PL/SQL procedure successfully completed.
セキュリティ・クラスおよびACLの作成
セキュリティ・クラスの作成
事前定義済のDMLセキュリティ・クラスに基づいてセキュリティ・クラスHR_PRIVILEGES
を作成します。HR_PRIVILEGES
には、SALARY
列へのアクセスを制御する新しい権限VIEW_SALARY
があります。
ACLの作成
EMP_ACL
、IT_ACL
およびHR_ACL
の3つのACLを作成して、後で定義するデータ・セキュリティ・ポリシーの権限を付与します。
この例では、次のようになります。
-
行11から13:
EMP_ACL
を作成し、EMPLOYEE
にSELECT
およびVIEW_SALARY
権限を付与します。 -
行21から23:
IT_ACL
を作成し、IT_ENGINEER
にSELECT
権限を付与します。 -
行30から33:
HR_ACL
を作成し、HR_REPRESENTATIVE
に対して、すべての従業員のレコードの表示と更新を行うためのSELECT
、INSERT
、UPDATE
、DELETE
データベース権限と、SALARY
列を表示するためのVIEW_SALARY
アプリケーション権限を付与します。
例5-18 HRPRIVSセキュリティ・クラスの作成
SQL> declare 2 begin 3 xs_security_class.create_security_class( 4 name => 'hr_privileges', 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-19 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 EMPLOYEE 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 => 'employee'); 10 11 sys.xs_acl.create_acl(name => 'emp_acl', 12 ace_list => aces, 13 sec_class => 'hr_privileges'); 14 15 -- IT_ACL: This ACL grants IT_ENGINEER 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_engineer'); 20 21 sys.xs_acl.create_acl(name => 'it_acl', 22 ace_list => aces, 23 sec_class => 'hr_privileges'); 24 25 -- HR_ACL: This ACL grants HR_REPRESENTATIVE the privileges to view and update all 26 -- employees' records including SALARY column. 27 aces(1):= xs$ace_type(privilege_list => xs$name_list('select', 'insert', 28 'update', 'delete', 'view_salary'), 29 principal_name => 'hr_representative'); 30 31 sys.xs_acl.create_acl(name => 'hr_acl', 32 ace_list => aces, 33 sec_class => 'hr_privileges'); 34 end; 35 / PL/SQL procedure successfully completed.
データ・セキュリティ・ポリシーの作成
EMPLOYEES
表のデータ・セキュリティ・ポリシーを作成します。ポリシーは、SALARY
列を保護する3つのデータ・レルム制約と1つの列制約を定義します。
この例では、次のようになります。
-
行7から23: 3つのデータ・レルム制約を定義します。
-
行27から30:
SALARY
列の表示にVIEW_SALARY
アプリケーション権限を要求する列制約を定義します。 -
行32から35: 3つのデータ・レルム制約と列制約を含むEMPLOYEES_DSデータ・セキュリティ・ポリシーを作成します。
表へのデータ・セキュリティ・ポリシーの適用
EMPLOYEES
表にデータ・セキュリティ・ポリシーを適用します。
例5-20 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 -- EMPLOYEE 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_ENGINEER 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_REPRESENTATIVE 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-21 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オブジェクトの検証
これらのReal Application Securityオブジェクトを作成した後で、これらを検証してすべて正しく構成されていることを確認します。
例5-22 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-23に、表HR.EMPLOYEES
のデータ・セキュリティを無効にする補足的な操作を示します。
例5-23 表のデータ・セキュリティ・ポリシーの無効化
BEGIN SYS.XS_DATA_SECURITY.DISABLE_OBJECT_POLICY(policy => 'EMPLOYEES_DS', schema => 'HR', object => 'EMPLOYEES'); END; /
セキュリティHRデモの実行
セキュリティHRデモは2通りの方法で実行されます。
-
最初にアプリケーション・ユーザー
DAUSTIN
として直接ログオンを実行してから、アプリケーション・ユーザーSMAVRIS
として実行します。どちらの場合も、各ユーザーが
HR.EMPLOYEES
表に対して問合せを実行し、従業員レコードとSALARY
列にアクセスして表示できるかどうかを示します。このデモの説明は、「直接ログオンを使用したセキュリティHRデモの実行」を参照してください。 -
Real Application Securityセッションに連結します
このデモでは、Real Application Security管理者は、連結するアプリケーション・ユーザーに対してReal Application Securityセッションを作成します。このデモの説明は、Real Application Securityセッションに連結されたセキュリティHRデモの実行を参照してください。
スキーマ・レベルのReal Application Securityポリシー管理について
同じスキーマ内にある様々なアプリケーション全体に渡る、Real Application Securityポリシー管理用のスキーマ・レベル権限の概要を説明します。
Oracle Database 12cリリース2 (12.2)から、Real Application Securityにはスキーマ・レベル権限が追加されました。これによってポリシー管理者は、あるアプリケーション内の付与されたスキーマおよび管理ポリシー強制範囲にのみ、ポリシーを作成、更新および適用できるようになりました。そのため、同じスキーマ内にある様々なアプリケーション全体で、ポリシーを個別に管理および強制できるようになります。各アプリケーションが1つ以上のスキーマで実行されているクラウド・コンピューティング・シナリオには、このようなポリシー管理のレベルが不可欠です。さらに、ポリシー管理者がその環境内の個々のアプリケーションのデータ・セキュリティ・ポリシーを管理および適用できることが望まれるようになります。
スキーマ・レベルのデータ・セキュリティ・ポリシー管理の実現
-
GRANT_SYSTEM_PRIVILEGE
プロシージャとREVOKE_SYSTEM_PRIVILEGE
プロシージャは、schema
パラメータの追加によって機能が拡張され、次の構文に示すように、特定のスキーマのデータベース・ユーザーまたはアプリケーション・ユーザーにReal Application Security権限を付与および取消しできるようになりました。XS_ADMIN_UTIL.GRANT_SYSTEM_PRIVILEGE ( priv_name IN VARCHAR2, user_name IN VARCHAR2, user_type IN PLS_INTEGER := XS_ADMIN_UTIL.PTYPE_DB, schema IN VARCHAR2);
XS_ADMIN_UTIL.REVOKE_SYSTEM_PRIVILEGE ( priv_name IN VARCHAR2, user_name IN VARCHAR2, user_type IN PLS_INTEGER := XS_ADMIN_UTIL.PTYPE_DB, schema IN VARCHAR2);
ここで、
schema
パラメータは権限が付与されるスキーマです。その権限がシステム権限である場合、値はNULL
です。 -
セキュリティ・クラス
ADMIN_SEC_POLICY
権限がポリシー管理(Create, Read, Update, and Delete)操作でのスキーマに対して使用できるように拡張されました。そのため、ポリシー管理者はADMIN_SEC_POLICY
権限を特定のスキーマのユーザーに付与し、付与されたスキーマ内でポリシー・アーティファクトを管理し、個別のアプリケーションにポリシー管理を適用できます。この機能拡張の影響を受けるAPIには、Real Application Security管理者パッケージのXS_ACL
、XS_DATA_SECURITY
およびXS_SECURITY_CLASS
が含まれます。 -
ポリシー管理者が、あるアプリケーションの付与されたスキーマ内にポリシーを強制するための、ポリシー強制用の新しいシステム・セキュリティ・クラス
APPLY_SEC_POLICY
権限が追加されました。データ・セキュリティ・ポリシーの強制前に、次のデータ・セキュリティAPIがチェックされます。-
XS_DATA_SECURITY.APPLY_OBJECT_POLICY
-
XS_DATA_SECURITY.REMOVE_OBJECT_POLICY
-
XS_DATA_SECURITY.ENABLE_OBJECT_POLICY
-
XS_DATA_SECURITY.DISABLE_OBJECT_POLICY
-
-
監査アクション
AUDIT_GRANT_PRIVILEGE
でGRANT_SYSTEM_PRIVILEGE
プロシージャの監査が実行されます。 -
監査アクション
AUDIT_REVOKE_PRIVILEGE
でREVOKE_SYSTEM_PRIVILEGE
プロシージャの監査が実行されます。 -
新しいデータ・ディクショナリ・ビュー
DBA_XS_PRIVILEGE_GRANTS
が追加され、データベース内のすべてのReal Applicaton Securityシステムまたはスキーマ・レベルの権限付与が表示されます。 -
さらに、次のビューが追加されました。ALL_XS_SECURITY_CLASSES、ALL_XS_SECURITY_CLASS_DEP、ALL_XS_PRIVILEGES、ALL_XS_IMPLIED_PRIVILEGES、ALL_XS_ACLS、ALL_XS_ACES、ALL_XS_POLICIES、ALL_XS_REALM_CONSTRAINTS、ALL_XS_INHERITED_REALMS、ALL_XS_ACL_PARAMETERS、ALL_XS_COLUMN_CONSTRAINTS、ALL_XS_APPLIED_POLICIES,、DBA_XS_PRIVILEGE_GRANTS
この項には次のトピックが含まれます: スキーマ・レベルのデータ・セキュリティ・ポリシーの設定および有効化
スキーマ・レベルのデータ・セキュリティ・ポリシーの設定および有効化
2つのアプリケーション管理者用にスキーマ・レベルのデータ・セキュリティ・ポリシーを設定して有効化する方法について説明します。
アプリケーション管理者ユーザーを作成し、必要なロールを付与します。
EXEC SYS.XS_PRINCIPAL.CREATE_USER(NAME => 'app_admin_user1', SCHEMA => 'HR');
EXEC SYS.XS_PRINCIPAL.SET_PASSWORD('app_admin_user1', 'PASSWORD');
EXEC SYS.XS_PRINCIPAL.GRANT_ROLES('app_admin_user1', 'XSCONNECT');
EXEC SYS.XS_PRINCIPAL.CREATE_USER(NAME => 'app_admin_user2', SCHEMA => 'SH');
EXEC SYS.XS_PRINCIPAL.SET_PASSWORD('app_admin_user2', 'PASSWORD');
EXEC SYS.XS_PRINCIPAL.GRANT_ROLES('app_admin_user2', 'XSCONNECT');
SYS
またはユーザーによって付与されたGRANT ANY PRIVILEGE
のいずれかの権限付与を持つReal Application Security管理者が、システム権限ADMIN_SEC_POLICY
とAPPLY_SEC_POLICY
を、HR
とSH
のスキーマに対応する各アプリケーション管理者ユーザーであるReal Application SecurityユーザーPTYPE_XS
に付与します。
EXEC SYS.XS_ADMIN_UTIL.GRANT_SYSTEM_PRIVILEGE('ADMIN_SEC_POLICY', 'app_admin_user1', SYS.XS_ADMIN_UTIL.PTYPE_XS, 'HR');
EXEC SYS.XS_ADMIN_UTIL.GRANT_SYSTEM_PRIVILEGE('APPLY_SEC_POLICY', 'app_admin_user1', SYS.XS_ADMIN_UTIL.PTYPE_XS, 'HR');
EXEC SYS.XS_ADMIN_UTIL.GRANT_SYSTEM_PRIVILEGE('ADMIN_SEC_POLICY', 'app_admin_user2', SYS.XS_ADMIN_UTIL.PTYPE_XS, 'SH');
EXEC SYS.XS_ADMIN_UTIL.GRANT_SYSTEM_PRIVILEGE('APPLY_SEC_POLICY', 'app_admin_user2', SYS.XS_ADMIN_UTIL.PTYPE_XS, 'SH');
次に、ポリシー管理者が目的のオブジェクト・ポリシーをアプリケーションの特定の表に適用し、有効化します。たとえば、EMPLOYEE
表用のデータ・セキュリティ・ポリシーEMPLOYEES_DS
を作成する例は、HRデモ・スクリプト「データ・セキュリティ・ポリシーの作成について」を参照してください。作成したら、ポリシー管理者はHR
スキーマのEMPLOYEES
表にデータ・セキュリティ・ポリシーEMPLOYEES_DS
を適用します。
BEGIN
SYS.XS_DATA_SECURITY.ENABLE_OBJECT_POLICY(policy =>'EMPLOYEES_DS',
schema=>'hr',
object=>'employees');
END;
/
BEGIN
SYS.XS_DATA_SECURITY.ENABLE_OBJECT_POLICY(policy =>'CUSTOMERS_DS',
schema=>'sh',
object=>'customers');
END;
/
データ・セキュリティ・ポリシーの無効化とユーザーのシステム権限の取消し
データ・セキュリティ・ポリシーを無効化しユーザーのシステム権限を取り消す方法について説明します。
データ・セキュリティ・ポリシーを無効化しユーザーのシステム権限を取り消す方法
HR
スキーマのEMPLOYEES
表のEMPLOYEES_DS
データ・セキュリティ・ポリシーを無効化するには、ポリシー管理者が次を実行します。BEGIN
SYS.XS_DATA_SECURITY.DISABLE_OBJECT_POLICY(policy =>'EMPLOYEES_DS',
schema=>'hr',
object=>'employees');
END;
/
SH
スキーマのCUSTOMERS
表のCUSTOMERS_DS
データ・セキュリティ・ポリシーを無効化するには、ポリシー管理者が次を実行します。BEGIN
SYS.XS_DATA_SECURITY.DISABLE_OBJECT_POLICY(policy =>'CUSTOMERS_DS',
schema=>'sh',
object=>'customers');
END;
/
ロールpolicy_admin_role
からではなく(同じロールが有効化されている他のポリシー管理者が存在する可能性があるため)アプリケーション管理者ユーザーapp_admin_user1
とapp_admin_user2
のシステム権限を取り消すには、次に示すように、SYS
権限またはユーザーによって付与されたGRANT ANY PRIVILEGE
権限のいずれかを持つReal Application Security管理者が、ユーザーapp_admin_user1
とapp_admin_user2
のシステム権限ADMIN_SEC_POLICY
とAPPLY_SEC_POLICY
を取り消します。
EXEC SYS.XS_ADMIN_UTIL.REVOKE_SYSTEM_PRIVILEGE('APPLY_SEC_POLICY', 'app_admin_user1', SYS.XS_ADMIN_UTIL.PTYPE_XS, 'HR');
EXEC SYS.XS_ADMIN_UTIL.REVOKE_SYSTEM_PRIVILEGE('ADMIN_SEC_POLICY', 'app_admin_user1', SYS.XS_ADMIN_UTIL.PTYPE_XS, 'HR');
EXEC SYS.XS_ADMIN_UTIL.REVOKE_SYSTEM_PRIVILEGE('APPLY_SEC_POLICY', 'app_admin_user2', SYS.XS_ADMIN_UTIL.PTYPE_XS, 'SH');
EXEC SYS.XS_ADMIN_UTIL.REVOKE_SYSTEM_PRIVILEGE('ADMIN_SEC_POLICY', 'app_admin_user2', SYS.XS_ADMIN_UTIL.PTYPE_XS, 'SH');