| Oracle® Database Real Application Security管理者および開発者ガイド 12cリリース1 (12.1) B71274-08 |
|
 前 |
 次 |
この章では、Oracle Database Real Application Securityでアプリケーション権限およびアクセス制御リスト(ACL)を構成する方法について説明します。ACLを作成、設定および変更する方法や、ACLセキュリティが他のOracle Databaseセキュリティ・メカニズムと相互作用する方法についても説明します。
データベースには、CREATE TABLEなどの事前定義されたシステム権限や、UPDATEなどのオブジェクト権限があります。エンタープライズ・アプリケーションで定義する必要のある多くのカスタム権限は、通常、アプリケーション定義権限と呼ばれます。Real Application Securityでは、アプリケーション権限と呼ばれるこれらの権限の定義をデータベースで導入しています。アプリケーション開発者は、これらのカスタム・アプリケーション権限をアプリケーション・レベルの操作に対するアクセス制御に使用します。これらのアプリケーション・レベルの操作によって、列、行またはセルの粒度レベルでデータにファイングレイン・アクセスすることが可能になります。
アプリケーション権限が表の行や列などのリソースに明示的にバインドされる場合、アプリケーション権限を使用して、データベース・オブジェクトに対するアプリケーション・レベルの操作を保護できます。または、リソースへのバインドが必要ではない場合、システム権限と同じ方法で使用できます。
関連項目:
ACLの権限の確認についてこの項の内容は次のとおりです: 集約権限
Real Application Securityの集約権限には、他のアプリケーション権限のセットが暗黙的に含まれます。集約権限に含まれる暗黙アプリケーション権限は、現在のセキュリティ・クラスまたは継承されたアプリケーション権限によって定義された任意のアプリケーション権限です(詳細は、セキュリティ・クラスの構成についてを参照してください)。集約権限が付与または拒否されると、その暗黙アプリケーション権限も暗黙的に付与または拒否されます。
集約権限AGにアプリケーション権限p1およびp2が暗黙的に含まれる場合、アプリケーション権限にAGを付与すると、p1とp2の両方が付与されます。ただし、p1とp2の両方を付与しても、AGを付与することにはなりません。
集約権限は、次の目的のために役立ちます。
アプリケーション権限のセットをグループ化して単一の権限として付与できるため、アプリケーション権限の管理が簡単になります。グループ名自体がアプリケーション権限でなければ、アプリケーション権限のセットのグループ名または別名によって、グループ内の各アプリケーション権限を確認できるため、セットの確認が簡単になります。
単一のアプリケーション権限チェックに基づいてアプリケーション権限のセットを確認する効率的な方法を使用できます。
例4-1では、UPDATE_INFOという集約権限をHRPRIVSセキュリティ・クラスに追加しています。集約権限には、暗黙権限のUPDATE、DELETEおよびINSERTが含まれます。
グループ名自体が最初のクラス権限の場合、そのメンバーとの関係に基づいて、集約権限に対して複数のセマンティクスが存在する可能性があります。集約権限を表すセマンティクスを定義する場合、集約権限とそのメンバー間の様々な関係(黙示や包含など)を考慮する必要があります。たとえば、Javaセキュリティで黙示関係を考慮する場合、集約権限の付与時にこのセマンティクスを選択すると、そのすべてのメンバーに集約権限ではなく個別にアプリケーション権限を暗黙的に付与することになります。したがって、すべてのメンバーに集約の各アプリケーション権限を付与しても、集約権限を暗黙的に付与することにはなりません。
例4-2では、集約権限UPDATE_INFOに暗黙アプリケーション権限のリストを追加しています。
集約権限は、アプリケーション・ロールではありません。アプリケーション・ロール自体は、リソースを保護するアプリケーション権限ではありません。アプリケーション・ロールは、ロール・ベースのアクセス制御の制約を施行する目的でアプリケーション・ユーザーが使用できるアプリケーション権限をアクティブ化または非アクティブ化するために使用します。
また、集約権限は、セキュリティ・クラスではありません。セキュリティ・クラスは、ユーザーに付与できるアプリケーション権限ではありません。セキュリティ・クラスは、ACLで付与または拒否できる集約権限を含むアプリケーション権限のセットを示します。セキュリティ・クラスで使用できるアプリケーション権限に基づいて、セキュリティ・クラス内で多くの集約権限を定義できます。
集約権限には、そのメンバーとして他の集約権限を含めることができます。集約権限のメンバー権限は、その集約権限と同じセキュリティ・クラス(または祖先のセキュリティ・クラス)で定義する必要があることに注意してください。集約権限の定義では、サイクルは作成されません。
例4-1 セキュリティ・クラスへの集約権限の追加
BEGIN SYS.XS_SECURITY_CLASS.ADD_PRIVILEGES(sec_class=>'HRPRIVS', priv=>'UPDATE_INFO', implied_priv_list=>XS$NAME_LIST('"UPDATE"', '"DELETE"', '"INSERT"')); END;
例4-2 集約権限への暗黙権限の追加
BEGIN SYS.XS_SECURITY_CLASS.ADD_IMPLIED_PRIVILEGES(sec_class =>'HRPRIVS',(priv=>'UPDATE_INFO', implied_priv_list=>XS$NAME_LIST('"UPDATE"', '"DELETE"', '"INSERT"')); END;
この項の内容は次のとおりです: ALL権限
ALL権限は、事前定義された集約権限です。すべてのセキュリティ・クラスにはALL権限があり、これにはそのセキュリティ・クラスのすべてのアプリケーション権限が含まれます。ALLは、すべてのセキュリティ・クラスで明示的に定義されているわけではありませんが、ACLに関連付けられたセキュリティ・クラスに基づいて、システムによって内部的に認識されます。アプリケーション権限がセキュリティ・クラスを対象に追加または削除されるたびに、セキュリティ・クラスのALLのカーディナリティも変化します。
ALL構成要素を使用すると、Real Application Securityで、アプリケーションに対して定義されたアプリケーション・ユーザーu1に、特定の権限p1を除くすべてのアプリケーション権限を付与するといった、アクセス制御ポリシーを表現できます。例4-3に、アプリケーションのすべてのアプリケーション権限が含まれるセキュリティ・クラスAppSecurityClassのACLを示します。ACEの順序付き評価によって、p1を除くALLがアプリケーション・ユーザーu1に付与されることが保証されます。
例4-3 ALL権限付与の使用
select NAME, SECURITY_CLASS, PARENT_ACL from DBA_XS_ACLS; NAME SECURITY_CLASS PARENT_ACL ---------- ---------------- --------------- sampleACL AppSecurityClass select ACL, ACE_ORDER, GRANT_TYPE, PRINCIPAL, PRIVILEGE from DBA_XS_ACES; ACL ACE_ORDER GRANT_TYPE PRINCIPAL PRIVILEGE --------- --------- ---------- ------------ ---------- sampleACL 1 DENY U1 p1 sampleACL 2 GRANT U1 ALL
セキュリティ・クラスは、アプリケーション権限のセットの有効範囲です。複数のセキュリティ・クラスで同じアプリケーション権限を定義できます。セキュリティ・クラスは、ACL内で付与または拒否できるアプリケーション権限のセットを制限します。セキュリティ・クラスは、関連するアプリケーション権限のコレクションを定義する場所であると同時に、ACLをセキュリティ・クラスに関連付ける手段でもあります。
Real Application Securityでは、事前定義されたアプリケーション権限およびセキュリティ・クラスのセットがサポートされていますが、セキュリティ・クラスを使用してアプリケーションで独自のカスタム・アプリケーション権限を定義することもできます。保護されるオブジェクトの各クラスは、そのオブジェクトに実行可能な操作のセットを示すセキュリティ・クラスに関連付けられます。組込みのアプリケーション権限の定義が含まれる事前定義されたセキュリティ・クラスがあります。
セキュリティ・クラスによって、多くのアプリケーション権限を管理するタスクが簡略化されます。1つのACLは、1つのセキュリティ・クラスに関連付けられます。このセキュリティ・クラスによって、ACL内で付与できるアプリケーション権限の有効範囲が定義されます。
各オブジェクト・タイプでは、多くのアプリケーション権限をサポートすることが可能で、多くの異なるオブジェクト・タイプで操作の共通セットを共有できます。これらのタイプの指定を簡略化するため、セキュリティ・クラスでは継承がサポートされます。
セキュリティ・クラスは、親のセキュリティ・クラスからアプリケーション権限を継承できます。子のセキュリティ・クラスには、親のセキュリティ・クラスで定義されているすべてのアプリケーション権限が暗黙的に含まれます。セキュリティ・クラスで使用できるアプリケーション権限は、セキュリティ・クラスで定義されているアプリケーション権限と、親のセキュリティ・クラスから継承されているアプリケーション権限の組合せです。
セキュリティ・クラスでは、親のセキュリティ・クラスのリストを指定できます。これらの親のクラスで使用できるアプリケーション権限は、子のクラスで使用できるようになります。子とその親のセキュリティ・クラスで同じアプリケーション権限名が定義されている場合、子のアプリケーション権限によって親のアプリケーション権限が置換またはオーバーライドされます。
例4-4に、HRPRIVSというセキュリティ・クラスの作成によるセキュリティ・クラスの継承を示します。HRPRIVSセキュリティ・クラスは、2つのアプリケーション権限VIEW_SENSITIVE_INFOおよびUPDATE_INFOを定義しています。UPDATE_INFOは、UPDATE、DELETEおよびINSERTという他の3つの権限が暗黙的に含まれる集約権限です。セキュリティ・クラスHRPRIVSは、parent_listパラメータで指定されたDMLセキュリティ・クラスからアプリケーション権限を継承します。
例4-4 セキュリティ・クラスの継承の表示
DECLARE
pr_list XS$PRIVILEGE_LIST;
BEGIN
pr_list :=XS$PRIVILEGE_LIST(
XS$PRIVILEGE(name=>'VIEW_SENSITIVE_INFO'),
XS$PRIVILEGE(name=>'UPDATE_INFO',
implied_priv_list=>XS$NAME_LIST
('"UPDATE"', '"DELETE"', '"INSERT"')));
sys.xs_security_class.create_security_class(
name=>'HRPRIVS',
parent_list=>XS$NAME_LIST('DML'),
priv_list=>pr_list);
END;
/
ACLには、その有効範囲として単一のセキュリティ・クラスが含まれます。ACLによって、保護対象のデータまたは機能に対するアクセスを制御するためにプリンシパルにアプリケーション権限が付与されますが、付与できるのはそのセキュリティ・クラスで定義されているアプリケーション権限のみです。security_classパラメータを使用して、ACLのセキュリティ・クラスを指定します。ACLに対してアプリケーション権限が確認される場合、アプリケーション権限のセキュリティ・クラスは、ACLのセキュリティ・クラスに基づいて解決されます(ACLには必ず関連付けられたセキュリティ・クラスが含まれるため)。セキュリティ・クラスを指定しない場合、DMLセキュリティ・クラスがデフォルト・セキュリティ・クラスとして使用されます。異なるACLに、その有効範囲として同じセキュリティ・クラスを含めることができます。
DMLセキュリティ・クラスは、事前に定義されているか、インストール中に作成されます。DMLセキュリティ・クラスには、オブジェクト操作のための共通のアプリケーション権限(SELECT、INSERT、UPDATEおよびDELETE)が含まれます。ACLによってそのセキュリティ・クラスが指定されない場合、DMLがACLのデフォルト・セキュリティ・クラスになります。
Real Application SecurityのDMLアプリケーション権限は、データベース・オブジェクト権限と同じであり、その性質上データベースのオブジェクト・レベルの操作によって施行されます。ただし、Real Application SecurityのDMLアプリケーション権限は、データベース表に対してReal Application Securityデータ・セキュリティが有効化されている場合にのみ使用できます。
管理構成の変更後は、必ずReal Application Securityオブジェクトを検証することをお薦めします。XS_DIAGパッケージには、これらの変更がReal Application Securityオブジェクト間の複雑な関係に悪影響を与えないようにする検証APIのセットが含まれます。
セキュリティ・クラスの検証の詳細は、VALIDATE_SECURITY_CLASSファンクションを参照してください。
セキュリティ・クラスを操作するには、セキュリティ・クラスとそのアプリケーション権限を作成、管理および削除するためのプロシージャが含まれるPL/SQLパッケージXS_SECURITY_CLASSのプロシージャを使用します。このパッケージには、セキュリティ・クラスの継承を管理するためのプロシージャも含まれます(XS_SECURITY_CLASSパッケージを参照)。
例4-5では、ADD_PARENTSを起動して、親のセキュリティ・クラスGENPRIVSをHRPRIVSセキュリティ・クラスに追加しています。
例4-6では、REMOVE_PARENTSを起動して、親のセキュリティ・クラスGENPRIVSをHRPRIVSセキュリティ・クラスから削除しています。
例4-7では、ADD_PRIVILEGESを起動して、UPDATE_INFOという集約権限をHRPRIVSセキュリティ・クラスに追加しています。集約権限には、暗黙権限のUPDATE、DELETEおよびINSERTが含まれます。ADD_PRIVILEGESを使用してセキュリティ・クラスに複数のアプリケーション権限を追加できることに注意してください。詳細は、集約権限を参照してください。
例4-8では、REMOVE_PRIVILEGESを起動して、UPDATE_INFOアプリケーション権限をHRPRIVSセキュリティ・クラスから削除しています。
例4-9では、REMOVE_PRIVILEGESを起動して、すべてのアプリケーション権限をHRPRIVSセキュリティ・クラスから削除しています。
例4-10では、ADD_IMPLIED_PRIVILEGESを起動して、暗黙アプリケーション権限のリストを集約権限UPDATE_INFOに追加しています。
例4-11では、REMOVE_IMPLIED_PRIVILEGESを起動して、暗黙権限DELETEを集約権限UPDATE_INFOから削除しています。
例4-12では、REMOVE_IMPLIED_PRIVILEGESを起動して、すべての暗黙アプリケーション権限を集約権限UPDATE_INFOから削除しています。
プロシージャによって、指定したセキュリティ・クラスの説明文字列を設定できます。例4-13では、SET_DESCRIPTIONを起動して、HRPRIVSセキュリティ・クラスの説明文字列を設定しています。
例4-14では、DELETE_SECURITY_CLASSを起動して、デフォルトの削除オプションDEFAULT_OPTIONを使用してHRACL ACLを削除しています。このオプションは、XS_ADMIN_UTILパッケージで定義されています。
例4-5 指定したセキュリティ・クラスでの親のセキュリティ・クラスの追加
BEGIN SYS.XS_SECURITY_CLASS.ADD_PARENTS('HRPRIVS','GENPRIVS'); END;
例4-6 指定したセキュリティ・クラスでの1つ以上の親クラスの削除
BEGIN SYS.XS_SECURITY_CLASS.REMOVE_PARENTS('HRPRIVS','GENPRIVS'); END;
例4-7 セキュリティ・クラスへの1つ以上のアプリケーション権限の追加
BEGIN SYS.XS_SECURITY_CLASS.ADD_PRIVILEGES(sec_class=>'HRPRIVS', priv=>'UPDATE_INFO', implied_priv_list=>XS$NAME_LIST('"UPDATE"', '"DELETE"', '"INSERT"')); END;
例4-8 指定したセキュリティ・クラスからの1つ以上のアプリケーション権限の削除
BEGIN SYS.XS_SECURITY_CLASS.REMOVE_PRIVILEGES('HRPRIVS','UPDATE_INFO'); END;
例4-9 指定したセキュリティ・クラスでのすべてのアプリケーション権限の削除
BEGIN SYS.XS_SECURITY_CLASS.REMOVE_PRIVILEGES('HRPRIVS'); END;
例4-10 集約権限への1つ以上の暗黙アプリケーション権限の追加
BEGIN SYS.XS_SECURITY_CLASS.ADD_IMPLIED_PRIVILEGES(priv=>'UPDATE_INFO', implied_priv_list=>XS$NAME_LIST('"UPDATE"', '"DELETE"', '"INSERT"')); END;
例4-11 集約権限からの特定の暗黙アプリケーション権限の削除
BEGIN SYS.XS_SECURITY_CLASS.REMOVE_IMPLIED_PRIVILEGES('UPDATE_INFO','"DELETE"'); END;
例4-12 集約権限からのすべての暗黙アプリケーション権限の削除
BEGIN SYS.XS_SECURITY_CLASS.REMOVE_IMPLIED_PRIVILEGES('UPDATE_INFO'); END;
例4-13 指定したセキュリティ・クラスの説明文字列の設定
BEGIN SYS.XS_SECURITY_CLASS.SET_DESCRIPTION( 'HRPRIVS','Contains privileges required to manage HR data'); END;
例4-14 指定したセキュリティ・クラスの削除
BEGIN
SYS.XS_SECURITY_CLASS.DELETE_SECURITY_CLASS('HRPRIVS',XS_ADMIN_UTIL.DEFAULT_OPTION);
END;
Real Application Securityは、アクセス制御リスト(ACL)に対応しており、権限付与、拒否および様々な競合解消方法をサポートしています。ACLは、アプリケーション定義権限をサポートするように拡張されており、アプリケーションは、自身にとって意味のある権限を制御できます。認可の問合せは、アプリケーション・ユーザーがACL aの権限pに対して認可されているかを確認する形式になります。アプリケーション定義権限は、中間層とデータベースの両方でサポートされるAPIを通じて実装されます。これらのAPIによって、アプリケーションは、購買注文の承認などの機密操作を保護できます。
機密操作を実行する前に、アプリケーションでは必要なアプリケーション権限を確認する必要があります。たとえば、アプリケーションがapprovePOアプリケーション権限を必要とする場合、目的の購買注文a1に関連付けられたACLを特定し、Real Application Securityのセッションがa1のアプリケーション権限approvePOに対して認可されているかどうかを確認する問合せを発行する必要があります。認可を適切に実行するためには、アプリケーションが信頼されている必要があることに注意してください。データ・セキュリティでは、表の行にACLを関連付ける宣言的な方法を提供することでこの処理を改善しており、データ・セキュリティ・ポリシーによって、管理者または開発者は、SQL述語を使用して表の行のセットを識別し、メンバー行へのアクセスを制御するために使用されるACLにそのセットを関連付けることができます。
データ・セキュリティ・システムには、行に関連付けられたACLを返すSQL演算子があります。このSQL演算子は、行に関連付けられたACL参照を使用して認可チェックを実行します。デフォルトでは、問合せによって、ユーザーが参照を許可されているすべての行が返されます。これらのACL参照を、結果セットを制限するWHERE句の引数として中間層で使用して、特定の行に対する適切なアクセスを決定できます。したがって、ユーザーの認可に基づいてapprovePOなどの特定の操作に対してこれらの行のみを表示するように、結果セットをさらに制限できます。
Real Application Securityシステムでは、データベースのSQL操作がネイティブに実行されるため、アプリケーションのセキュリティ・エラーを原因とする被害の範囲が制限されます。つまり、アプリケーションの1つの部分に対するSQLインジェクション攻撃によって、そのコンポーネントの外部にある表にアクセスされることはありません。
ACLは、リソースに対するプリンシパルのアプリケーション権限を指定することで、リソースを保護します。ACLは、アクセス制御エントリ(ACE)のリストであり、各ACEは、リソースを対象に付与または拒否されているアプリケーション権限とプリンシパルとの間のマッピングを管理します。プリンシパルは、データベース・ユーザーか、Real Application Securityのアプリケーション・ユーザーまたはアプリケーション・ロールです。
アクセス制御エントリ(ACE)
アクセス制御エントリ(ACE)は、アプリケーション権限の付与を表し、ACLは、リソースにバインドされたアプリケーション権限の付与のセットを表します。ここで、リソースとは、データベース表、表の列、またはSQL述語を使用して選択された表の行のセットです。したがって、リソースがアクセスされると、そのリソースに関連付けられたACLのみが、アクセス権を確認されます。
ACEでは、特定のプリンシパルを対象に、アプリケーション機能や他のデータベース・データへのアクセス権を付与または拒否します。ACEそれ自体は、保護するデータを指定しません(これは、ACEおよびACLの外部で、ターゲット・データにACLを関連付けることで行われます)。
ACLの各ACEエントリを作成するために、XS$ACE_TYPEタイプが提供されています。XS$ACE_LISTオブジェクトは、権限のリストと、権限が付与または拒否されるプリンシパルで構成されます。ACE関連の情報には、DBA_XS_ACESビューを通じてアクセスできます。
例4-15では、HRACLというACLを作成しています。このACLには、ace_listに格納されたACEが含まれます。ace_listで使用されているアプリケーション権限は、HRPRIVSセキュリティ・クラスで使用できます。st_dateおよびen_dateパラメータで、このACLのアクティブな開始時間と終了時間を指定します(SELECTおよびVIEW_SENSITIVE_INFOアプリケーション権限のみが一時的であることに注意してください)。
例4-15 アクセス制御リストの作成
DECLARE st_date TIMESTAMP WITH TIME ZONE; en_date TIMESTAMP WITH TIME ZONE; ace_list XS$ACE_LIST; BEGIN st_date := SYSTIMESTAMP; en_date := TO_TIMESTAMP_TZ('2019-06-18 11:00:00 -5:00', 'YYYY-MM-DD HH:MI:SS TZH:TZM'); ace_list := XS$ACE_LIST( XS$ACE_TYPE(privilege_list=>XS$NAME_LIST('"SELECT"','VIEW_SENSITIVE_INFO'), granted=>true, principal_name=>'HRREP', start_date=>st_date, end_date=>en_date), XS$ACE_TYPE(privilege_list=>XS$NAME_LIST('UPDATE_INFO'), granted=>true, principal_name=>'HRMGR'), XS$ACE_TYPE(privilege_list=>XS$NAME_LIST('"SELECT"'), granted=>true, principal_name=>'DB_HR', principal_type=>XS_ACL.PTYPE_DB)); sys.xs_acl.create_acl(name=>'HRACL', ace_list=>ace_list, sec_class=>'HRPRIVS', description=>'HR Representative Access'); END; /
権限付与が否認されると、アプリケーション権限は拒否されます。例4-16では、属性grantedの値をFALSEに設定して、プリンシパルに対するアプリケーション権限を拒否しています。デフォルト値はTRUEです。
Real Application SecurityのACLでは、ACEの順序付き評価のみがサポートされます。リクエストされたアプリケーション権限を付与または拒否する最初のACEは、最終的な付与または拒否に影響します。DBA_XS_ACESの項を参照してください。
例4-16 権限の拒否
XS$ACE_LIST(
XS$ACE_TYPE(privilege_list=>XS$NAME_LIST('UPDATE_INFO'),
granted=>FALSE,
principal_name=>'HRREP'
);
指定したアプリケーション権限を、1つを除くすべてのプリンシパルに付与する場合、そのプリンシパルを反転します(inverted属性をTRUEに設定します)。属性invertedのデフォルト値は、FALSEです。例4-17では、反転されたロールHRGUESTに対する権限付与によって、ロールが有効化されていないすべてのユーザーにアプリケーション権限が付与されています。
例4-17 アプリケーション権限の反転
XS$ACE_LIST(
XS$ACE_TYPE(privilege_list=>XS$NAME_LIST('UPDATE_INFO'),
inverted=>TRUE,
principal_name=>'HRGUEST'
);
ACEごとに、開始日と終了日に基づいた時間制約を設定して、ACEを有効にする期間を指定できます。
例4-18では、TIMESTAMP WITH TIME ZONEデータ型のオプション属性start_dateおよびend_dateによって、ACEの有効期間を定義しています。end_dateの値は、start_dateの値より後の日時にする必要があります。
例4-18 ACEの開始日および終了日の設定
XS$ACE_TYPE(privilege_list=>XS$NAME_LIST('"SELECT"','VIEW_SENSITIVE_INFO'),
granted=>true,
principal_name=>'HRREP',
start_date=>st_date,
end_date=>en_date))
管理構成の変更後は、必ずReal Application Securityオブジェクトを検証することをお薦めします。XS_DIAGパッケージには、これらの変更がReal Application Securityオブジェクト間の複雑な関係に悪影響を与えないようにする検証APIのセットが含まれます。
ACLの検証の詳細は、VALIDATE_ACLファンクションを参照してください。
ACLを操作するには、ACLを作成および管理するプロシージャが含まれるPL/SQLパッケージXS_ACLのプロシージャを使用します。XS_ACLパッケージを参照してください。
例4-19では、APPEND_ACESを起動して、ACEのace_entryをHRACL ACLに追加しています。ACEによって、SELECT権限がDB_HRデータベース・ユーザーに付与されます。
例4-20では、REMOVE_ACESを起動して、HRACLというACLからすべてのACEを削除しています。
プロシージャによって、ACLのセキュリティ・クラスを設定または変更します。例4-21では、SET_SECURITY_CLASSプロシージャを起動して、HRPRIVSセキュリティ・クラスをACLのHRACLに関連付けています。
例4-22では、SET_PARENT_ACLを起動して、AllDepACL ACLをHRACL ACLの親のACLとして設定しています。継承タイプはEXTENDに設定されます。
例4-23では、REMOVE_ACL_PARAMETERSを起動して、ACL1のすべてのACLパラメータを削除しています。
例4-24では、REMOVE_ACL_PARAMETERSを起動して、ACL1のREGIONパラメータを削除しています。
例4-25では、SET_DESCRIPTIONを起動して、ACLのHRACLの説明を設定しています。
例4-26では、DELETE_ACLを起動して、デフォルトの削除オプションを使用してACLのHRACLを削除しています。
例4-19 アクセス制御リストへのACEの追加
DECLARE
ace_entry XS$ACE_TYPE;
BEGIN
ace_entry := XS$ACE_TYPE(privilege_list=>XS$NAME_LIST('"SELECT"'),
granted=>true,
principal_name=>'DB_HR',
principal_type=>XS_ACL.PTYPE_DB);
SYS.XS_ACL.APPEND_ACES('HRACL',ace_entry);
END;
例4-20 ACLからのすべてのACEの削除
BEGIN SYS.XS_ACL.REMOVE_ACES('HRACL'); END;
例4-21 ACLのセキュリティ・クラスの変更
BEGIN SYS.XS_ACL.SET_SECURITY_CLASS('HRACL','HRPRIVS'); END;
例4-22 親のACLの設定または変更
BEGIN
SYS.XS_ACL.SET_PARENT_ACL('HRACL','AllDepACL',XS_ACL.EXTENDED);
END;
例4-23 ACLのすべてのACLパラメータの削除
BEGIN SYS.XS_ACL.REMOVE_ACL_PARAMETERS('ACL1'); END;
例4-24 ACLでの指定したACLパラメータの削除
BEGIN SYS.XS_ACL.REMOVE_ACL_PARAMETERS('ACL1','REGION'); END;
例4-25 ACLの説明文字列の設定
BEGIN SYS.XS_ACL.SET_DESCRIPTION('HRACL', 'Grants privileges to HR representatives and managers.'); END;
例4-26 ACLの削除
BEGIN SYS.XS_ACL.DELETE_ACL('HRACL'); END;
施行には2つの形式があり、システムはデータ・セキュリティで保護されたオブジェクトに対するDML権限を施行し、ユーザーによって追加されたSQL演算子は他のすべてのアプリケーション権限を施行します。
ACLのアプリケーション権限を確認するには、SQL演算子ORA_CHECK_ACLをコールします。
ORA_CHECK_ACL (acls, privilege [,privilege] ... )
ORA_CHECK_ACL SQL演算子は、ACLの順序付きリストについてアプリケーション権限のリストを評価します。評価プロセスは、次の3つのイベントのいずれかが発生するまで継続されます。
指定されたすべてのアプリケーション権限の付与が、同じアプリケーション権限の潜在的な拒否の前に発生している場合。結果として、アプリケーション権限が付与されます。
指定されたアプリケーション権限のいずれかが、潜在的な付与の前に拒否されている場合。結果として、1つ以上のアプリケーション権限が拒否されます。
ACEのリストがすべて検索された場合。結果として、一部のアプリケーション権限が付与されます。
アプリケーション権限を評価するため、Oracleは順序付きのACEを確認し、リクエストされたアプリケーション権限を付与または拒否するACEを検出すると、評価を停止します。
表またはビューの行に関連付けられたACLを検出するには、SQL演算子ORA_GET_ACLIDSをORA_GET_ACLIDS(table, ...)としてコールします。たとえば、表tabに対するアプリケーション権限privを施行するには、ユーザー問合せで次の確認を追加します。
ORA_CHECK_ACL(ORA_GET_ACLIDS(tab), priv)
このファンクションによって、アプリケーション権限が付与されているか拒否されているか(またはそのどちらでもないか)という質問に対する回答を得ることができます。対応するJava APIも使用できます。
マルチレベル認証によって、ユーザーは、システム制約型ACLを通じて、認証のレベルに基づいてアプリケーション権限を指定できます。システム制約型ACLでは、アプリケーション・ユーザーの認証レベルを反映した動的ロールに基づいて、オブジェクトに対するアプリケーション権限の最小限のアプリケーション対象セットを指定します。アプリケーション・ユーザーは、オブジェクトにアクセスしようとすると、ファイアウォールの内部または外部で、次の4つの認証レベルに基づいて厳密認証または簡易認証を受けます。
厳密認証(ファイアウォール内)
厳密認証(ファイアウォール外)
簡易認証(ファイアウォール内)
簡易認証(ファイアウォール外)
システム制約型ACLでは、アプリケーションの各認証レベルでアプリケーション・ユーザーに適用されるアプリケーション権限を指定できます。管理者は、アプリケーション要件に基づいて、必要な基準に従って特定のユーザーに追加のアプリケーション権限を付与できます(このような追加のアプリケーション権限は、システム制約型ACLから独立しています)。例4-28および例4-29では、システム制約型ACLを実装しています。
Real Application Securityのプリンシパル(アプリケーション・ユーザーとアプリケーション・ロール)に加え、Real Application Securityでは、データベース・ユーザーおよびロールに基づく権限付与がサポートされます。システムがReal Application SecurityセッションのコンテキストでACLを評価する場合、データベース・スキーマに基づく権限付与は無視されますが、データベース・ロールに基づく権限付与は考慮されます(それらはReal Application Securityユーザーのロール・リストの一部であるため)。ACL内で、複数のACEによってプリンシパルに権限を付与できます。
アクセスのリクエストには、2つの結果(trueまたはfalse)があります。
trueの結果は、リクエストされたアプリケーション権限が付与されることを意味します。
falseの結果は、リクエストされたアプリケーション権限が付与されないか拒否されることを意味します。
ACEは、ACL内に出現する順序で評価されます。特定のACEを評価した結果は、次のいずれかになります。
アプリケーション権限が付与されます。
アプリケーション権限が拒否されます。
アプリケーション権限の付与も拒否も行われません。
あるACEが前のACEで拒否されているアプリケーション権限を付与している場合、ACEは順番に評価されるため、その結果は拒否になります。
ACLは、単一の親のACLから明示的に継承することが可能で、アプリケーションは複数のオブジェクト全体でポリシーを共有できます。アプリケーション権限に対するリクエストに2つのACLが含まれる場合、アクセス解決アルゴリズムの最終結果は、ACLの個々のアクセス解決結果のセマンティクスに基づきます。Real Application Securityでは、拡張ACL継承(順序付き評価によるOR)および制約ACL継承(AND)という2つのタイプの継承セマンティクスがサポートされます。
拡張ACL継承(順序付き評価によるOR)では、継承ツリーの最下位から最上位まで(子から親まで) ACEが評価されます。拡張ACL継承では、アプリケーション権限は、子または親のACLが権限を付与すると付与され、子または親のACLが権限を拒否すると拒否されます。実際には、リクエストされたアプリケーション権限を明示的に付与または拒否する最初のACLによって、最終結果が決定されます。最初の付与または拒否の後に、残りのACLがさらに評価されることはありません。この評価ルールは、ACL内のACEの順序付き評価と同じであることに注意してください。
次の例では、AllDepACL ACLをHRACL ACLの親のACLとして設定しています。継承タイプはEXTENDEDに設定されます。
例4-27 拡張ACL継承
BEGIN
SYS.XS_ACL.SET_PARENT_ACL('HRACL','AllDepACL',XS_ACL.EXTENDED);
END;
制約ACL継承(AND)では、ACLの確認でtrueに評価されるように、子と親の両方のACLでアプリケーション権限を付与する必要があります。
アプリケーション全体のセキュリティ・ポリシーは、アプリケーションのすべてのACLが同じ親のACLによって制約される場合に施行できます。たとえば、企業ファイアウォール内に存在するものとして認証されたユーザーがSELECT権限以外のアプリケーション権限を持つことができるサンプル・ポリシーを考えます。例4-28は、このポリシーの制約ACLを示しており(継承タイプはCONSTRAINEDに設定されます)、XSPUBLICアプリケーション・ロールを持つすべてのアプリケーション・ユーザーにSELECT権限が付与されます。動的アプリケーション・ロールのFIREWALLが有効になるのは、企業ファイアウォールの内部にいるアプリケーション・ユーザーのみであることに注意してください。したがって、ファイアウォール内部のアプリケーション・ユーザーには、HRPRIVSセキュリティ・クラスのすべてのアプリケーション権限が付与されます。このACLによってguestACLなどのすべてのACLが制約されるため、例4-29は、これらのACLのアプリケーション権限の付与がFIREWALL_ACLによって制約されることを示しています。
例4-28 制約ACL継承: ファイアウォール固有の認証権限
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=>'XSPUBLIC'),
XS$ACE_TYPE(privilege_list=>XS$NAME_LIST('ALL'),
granted=>true,
principal_name=>'FIREWALL'));
sys.xs_acl.create_acl(name=>'FIREWALL_ACL',
ace_list=>ace_list,
sec_class=>'HRPRIVS',
description=>'Only select privilege if not inside firewall');
END;
/
BEGIN
SYS.XS_ACL.SET_PARENT_ACL('GuestACL', 'FIREWALL_ACL',XS_ACL.CONSTRAINED);
END;
例4-29 制約アプリケーション権限の使用
SQL> select ACE_ORDER, GRANT_TYPE, PRINCIPAL, PRIVILEGE
from DBA_XS_ACES
where ACL='FIREWALL_ACL';
ACE_ORDER GRANT_TYPE PRINCIPAL PRIVILEGE
---------- ---------- --------- ----------
1 GRANT XSPUBLIC SELECT
2 GRANT FIREWALL ALL
ACLには次のカタログ・ビューがあります。
DBA_XS_ACLSカタログ・ビュー(DBA_XS_ACLSを参照)
DBA_XS_ACESカタログ・ビュー(DBA_XS_ACESを参照)
セキュリティ・クラスには次のカタログ・ビューがあります。
DBA_XS_SECURITY_CLASSES (DBA_XS_SECURITY_CLASSESを参照)
DBA_XS_SECURITY_CLASS_DEP (DBA_XS_SECURITY_CLASS_DEPを参照)
DBA_XS_PRIVILEGES (DBA_XS_PRIVILEGESを参照)
データ・セキュリティによって、ACLがデータ・レルムと呼ばれる行の論理グループに関連付けられます。
これによって、アプリケーションは、データ・レルムとそのアクセスを定義したポリシーを通じて、データベース・レイヤーでアプリケーション固有の権限を定義および施行できます。これらのデータ・レルムには、行のセットを識別するSQL述語と、識別された行を保護するACLの両方が含まれます。ACLの評価は、スキーマ所有者ではなくアプリケーション・ユーザーに基づきます。
Real Application Securityのデータ・セキュリティ・ポリシーのデータ・レルムによって、ACLが表の行に関連付けられます。データ・レルムには次の2つの側面があります。
行のセットを選択するSQL述語として表現されたルール。
行に対するアクセス・ポリシーを指定するACLのセット。
データ・セキュリティでは、関連するACLによって付与されたDML Real Application Securityアプリケーション権限を管理します。DataSecurityモジュールでは、その性質上、他の(DML以外の) Real Application Securityアプリケーション権限は施行できません。このようなアプリケーション権限は、SQL演算子またはデータ・レルム述語内でCHECK_PRIVILEGE演算子を起動するときに、DML操作の一環としてプログラム的に施行できます。
データベースでは、次の方法でリソースに権限をバインドできます。
権限付与の一環として明示的にバインドできます。たとえば、データベース・オブジェクト権限は、GRANT user_N update ON table_Mなどの権限付与の一環としてリソースにバインドされます。
ALTER SYSTEMやCREATE ANY TABLEシステム権限のように、権限付与文の一部としてリソース名を必要としない権限定義の一環としてグローバルにバインドすることもできます。
同様に、Real Application Securityアプリケーション権限は次のタイプのいずれかになります。
データ・セキュリティ・ポリシーの一部として、ACLおよびデータ・レルムを通じて明示的にバインドされます(データ・セキュリティの構成を参照)。
その定義の一部としてリソースにグローバルにバインドされます。
