Oracle Database Real Application Securityの概要

1.1 Oracle Database Real Application Securityとは

Oracle Database Real Application Securityは、次のようなデータベース認可モデルです。

宣言的なセキュリティ・ポリシーをサポートします。
複数層アプリケーションに対してエンドツーエンド・セキュリティを有効にします。
セキュアなデータベースおよびアプリケーション・リソースに統合ソリューションを提供します。
インターネット用に開発されたアプリケーションの既存の要件および最新の要件を満たすようにOracle Databaseのセキュリティ・アーキテクチャを拡張します。

従来のセキュリティは、クライアント/サーバー・システムを対象に設計されていました。これらのシステムのユーザーの数は、インターネット用に設計された新しいアプリケーションと比べると相当に少ない状態でした。アプリケーション開発者が従来のセキュリティを不十分であると認めると、それはデータベース・レイヤーからアプリケーション・レイヤーに移動されるのが普通でした。これを行うため、開発者は、頻繁に独自の表を作成し、独自のアプリケーション・ユーザーを定義していました。セキュリティはデータベースではなくアプリケーション・レイヤーでエンコードされていたため、アプリケーション・ユーザーとアプリケーション・ロールは、通常、アプリケーションのみが認識していました。つまり、データベース・ユーザーはアプリケーション・レベルのユーザーではないため、データベースでのアクセス制御の決定時にユーザー・アイデンティティは認識されていませんでした。さらに、データベース操作はアプリケーション・レベルのタスクまたは操作を表さないDDLおよびDMLに限定されるため、操作コンテキストもデータベースでのアクセス制御の決定時に認識されていませんでした。このような使用方法によって、データベースのセキュリティが低下していました。

Real Application Securityは次の目的で設計されています。

データベース・ユーザーではなくアプリケーション・ユーザーのアプリケーション・セキュリティを管理します。
開発者がアプリケーション・レベルのタスクのセキュリティを管理できるようにします。
セキュリティの施行中にアプリケーション・ユーザー・アイデンティティを認識できるようにします。
開発者がセキュリティをデータベース・レイヤーに増分的に、または一度に戻すことができるようにします。

この項では、従来のセキュリティとReal Application Securityについて説明し、Real Application Securityが従来のセキュリティをどのように改善しているかを示します。

この項では、次の概念について説明します。

1.1.1 アプリケーション・ユーザーを管理する従来のセキュリティのデメリット

従来のセキュリティ・モデルを使用する場合、通常、特に次のセキュリティ・タスクを実行する際に3層アプリケーションを管理することが困難でした。

アプリケーション・コードから独立したセキュリティ・ポリシーの拡張
アプリケーション・ユーザーが不明なデータベース・レベルでのセキュリティ・ポリシーの施行
特権的な2層コンポーネントに完全なアクセス権が付与されるような最小権限の原則の施行

1.1.2 Real Application Securityのメリット

Real Application Securityによって、次のセキュリティ・タスクが可能になり、データベースのセキュリティおよびパフォーマンスが向上します。

3層および2層アプリケーションは、データベース・レイヤーでアクセス制御要件を宣言的に定義、提供および施行できます。
データベースは、すべての層にわたって統一されたセキュリティ・モデルを提供し、複数のアプリケーション・ユーザー・ストアをサポートできます(関連ロール、認証資格証明、データベース属性およびアプリケーション定義属性を含む)。このモデルによって、アプリケーション・ユーザーは、Oracleエンタープライズ全体にわたって一意でグローバルな単一のアイデンティティを保持できます。
Oracle Databaseは、アプリケーション・セキュリティ・コンテキストをネイティブにサポートできます。データベースでは、アプリケーションとデータベースの両方を対象とする統合ポリシーの指定および施行がサポートされるため、アプリケーションでは、アプリケーション・コードを通じてこれを行う必要がありません。また、データベースではアプリケーション・セキュリティ・コンテキストの情報が格納されるため、ネットワーク・トラフィックも削減されます。
開発者は、Real Application Securityを使用して、Oracleエンタープライズのすべてのコンポーネントを通じて一般的な方法で、Oracle Databaseのデータに対するアプリケーション・ユーザーのアクセスを制御できます。

データ・セキュリティ・ポリシーとアクセス制御要件の定義の詳細は、データ・セキュリティの構成を参照してください。

1.1.3 Real Application Securityのアーキテクチャ

Real Application Securityは、PL/SQLおよびJava APIのコレクションを通じて管理されます。このアーキテクチャによって、そのコンポーネント(アプリケーション・ユーザー、アプリケーション・ロール、セッションなどのセキュリティ関連のコンポーネント)を構成できます。Real Application Securityでは、表に格納されたエンティティの使用を通じて、従来のユーザー、ロールおよびセッションに対応するものをアプリケーション側で構成します。

図1-1に、Oracle Database Real Application Securityで使用される様々なコンポーネントを示します。これには、アプリケーション・ユーザー、アプリケーション・ロール、アクセス制御リスト、セキュリティ・クラスおよびアプリケーション・セッションが含まれます。これらのコンポーネントについては、後続の項で説明します。図1-1は、データベースに対してアプリケーション・セッションを確立するWebアプリケーションも示しています。

図1-1 Oracle Database Real Application Securityのコンポーネント

「図1-1 Oracle Database Real Application Securityのコンポーネント」の説明

1.2 Real Application Securityで使用されるデータ・セキュリティの概念

この項では、Real Application Securityを構成する前に理解しておく必要のあるアクセス制御の用語および概念について説明します。PL/SQL管理インタフェースを使用して、ここで説明しているエンティティ(アプリケーション・ユーザー、アプリケーション・ロール、プリンシパル、アプリケーション権限、セキュリティ・クラス、アクセス制御リスト(ACL)、アクセス制御エントリ(ACE)およびデータ・レルム)を作成および管理できます。

注意:

ここでアプリケーション・ユーザーやアプリケーション・ロールなどの用語が使用される場合、それはReal Application Securityに適用されます(データベース・タイプを識別することが重要な場合、修飾子を使用しないか、データベースという修飾子を使用します)。

1.2.1 Oracle Database Real Application Securityによるデータ・セキュリティについて

有効なセキュリティでは、どのアプリケーション・ユーザー、アプリケーションまたは機能が、どのような種類の操作を実行するために、どのデータにアクセスできるかを定義する必要があります。したがって、有効なセキュリティには次の3つの次元があります。

操作を実行するアプリケーション・ユーザー
実行可能な操作
対象となるデータ

これらの3つの次元について、それぞれ(1)プリンシパル、(2)アプリケーション権限および(3)オブジェクトを定義します。プリンシパルは、ユーザーおよびロールです。ロールは、アプリケーション・ユーザーの属性、システムの状態、またはコードの一部を表します。

プリンシパルとアプリケーション権限は、ACLを定義することで、宣言的に関連付けられます。次に、これらのACLは、表データの行および列を保護するデータ・セキュリティ・ポリシーを定義することで、データに関連付けられます。たとえば、PL/SQLプロシージャを使用してACLの制御を設定することで、表データを保護できます。

図1-2に、ユーザーProjectManagerがチームAのプロジェクトで構成されるデータ・レルムに対してModifyProject権限を持っている場合の例を示します。

図1-2 データ・セキュリティの3つの次元

「図1-2 データ・セキュリティの3つの次元」の説明

1.2.2 プリンシパル: ユーザーおよびロール

ファイングレインなデータベース・アクセス制御について検討する場合、プリンシパルは、アプリケーション・ユーザーまたはアプリケーション・ロールであるか、データベース・ユーザーまたはデータベース・ロールです。アプリケーション・ユーザーは、データベースの情報にアクセスする個人または自律型のアプリケーション・プロセスです。アプリケーション・ロールは、現実のタスクを実行するために必要なアプリケーション権限を論理的にグループ化したものです。アプリケーション・ロールには、他のアプリケーション・ロールを含めることができますが、この再帰操作を循環させることはできません。アプリケーション・ロールを使用して、アプリケーション・ユーザー(データベース・ユーザーとアプリケーション・ユーザーの両方)を権限に関連付けます。

Oracle Databaseでは、プリンシパルとして次のものをサポートしています。

データベース・ユーザーおよびデータベース・ロール

データベース・ユーザーは、データベース・スキーマまたはユーザー・アカウントと呼ばれることもあります。個人またはアプリケーションはデータベースにログオンするとき、データベース・ユーザー(スキーマ)およびパスワードを使用します。

データベース・ロールは、データベース・ユーザー、アプリケーションまたは他のデータベース・ロールに付与できるデータベース権限のセットに対応しています(データベース・ロールとアプリケーション・ロールの相違点の理解を参照)。
アプリケーション・ユーザーおよびアプリケーション・ロール

Real Application Securityで使用されるアプリケーションという用語は、アプリケーション・ユーザーがログオンしているアプリケーションに関連する情報のみを含むアプリケーション・ユーザー、アプリケーション・ロールまたはセッションの作成を示します。アプリケーション・ユーザーとアプリケーション・ロールは、アプリケーションによって定義されるため、いずれかのデータベース・スキーマに関連付ける必要はありません。

アプリケーション・ユーザーは、データベースに直接接続することで、重量データベース・セッションを作成することもできます。これらは、直接ログイン・アプリケーション・ユーザーと呼ばれます。「直接ログイン・アプリケーション・ユーザー・アカウントの作成について」を参照してください。アプリケーション・ユーザーが重量データベース・セッションを作成すると、ユーザーのデフォルト・スキーマは、名前解決目的専用で事前構成された値に設定されます(HRなど)。

アプリケーション・ロールは、アプリケーション・ユーザーまたは別のアプリケーション・ロールにのみ付与できます。データベース権限をアプリケーション・ユーザーおよびアプリケーション・ロールに直接付与することはできません。詳細は、アプリケーション・ユーザーおよびアプリケーション・ロールへのデータベース権限の付与を参照してください。
関連項目:
- アプリケーション・ユーザーの構成について
- アプリケーション・ロールの構成について

この節の内容は以下のとおりです。

1.2.2.1 データベース・ユーザーとアプリケーション・ユーザーの相違点の理解

データベース・ユーザーは、従来のユーザーとも呼ばれ、次の特徴を持っています。

スキーマとパスワードに関連付けられます。
関連付けられているスキーマに対する重量セッションを作成できます。

アプリケーション・ユーザーは、アプリケーションによって定義され、次の特徴を持っています。

データベース・スキーマを所有しません。
中間層を通じたデータベースに対するアプリケーション・セッションを作成できます。
データベースに直接接続することで、重量データベース・セッションを作成できます。(直接ログイン・アプリケーション・ユーザー・アカウントの作成についてを参照してください。)

注意:

重量セッションでは、ユーザーは、デフォルト・スキーマに関連付けられます。

1.2.2.2 データベース・ロールとアプリケーション・ロールの相違点の理解

データベース・ロールは、一般的に、データベース権限の名前付きセットであると考えられます。

データベース・ロールは、次の特徴を持っています。

データベース・ユーザーに権限が付与されるのと同様に、権限が付与されます。
データベース権限をデータベース・ユーザー(およびアプリケーション)にマップするための媒介として機能します。つまり、ロールに権限が付与されてから、そのロールがユーザーに付与されます(それによりユーザーに権限が付与されます)。
1. 権限をデータベース・ロールに付与します。
2. データベース・ロールをデータベース・ユーザーに付与します。
これで、データベース・ユーザーはデータベース・ロールの権限を持ちます。

注意:

従来のデータベース用語では、ロールは、それに付与されている権限のセットと同じものとみなされます。

アプリケーション・ロールは、宣言的なアクセス制御リスト(ACL)のメカニズムを使用して関連付けられたアプリケーション定義権限のセットと考えることができます(アクセス制御リスト(ACL)を参照)。

アプリケーション・ロールは、次の特徴を持っています。

アプリケーション権限をユーザーまたはロールにマップする媒体として、データベースの権限付与ではなくアクセス制御リスト(ACL)を使用します。
アプリケーション・ユーザーまたはアプリケーション・ロールにのみ付与できます。
データベース・ロールには付与できません(データベース・ロールをアプリケーション・ロールに付与できるのとは異なります)。

注意:

アクセス制御の用語では、アプリケーション・ロールは、アプリケーション・ユーザーとともにプリンシパルに分類されます。

1.2.2.3 アプリケーション・ユーザーおよびアプリケーション・ロールへのデータベース権限の付与

データベース権限をアプリケーション・ユーザーおよびアプリケーション・ロールに直接付与することはできません。かわりに、データベース権限をデータベース・ロールに付与してから、次のステップでデータベース・ロールをアプリケーション・ロールに付与します。

データベース権限をデータベース・ロールに付与します。
データベース・ロールをアプリケーション・ロールに付与します。

次のコードの文では、データベースのSELECT権限をアプリケーション・ロールのHRREPに有効に付与して、これを適切に実行しています。

CREATE ROLE db_hrrep;
GRANT SELECT ON hr.employees TO db_hrrep;
GRANT db_hrrep TO HRREP;

すでに作成されているか、後で作成されるアプリケーション・ユーザーが、このアプリケーション・ロールを持つことで、このアプリケーション権限を取得します。

1.2.3 アプリケーション権限

アプリケーション権限とは、プリンシパルに対して付与または拒否される特定の権限です。アプリケーション開発者は、セキュリティ・クラスでアプリケーション権限を定義します。

プリンシパルに付与されたアプリケーション権限のセットによって、プリンシパルが保護するデータに対して特定の操作を実行できるかどうかが制御されます。たとえば、プリンシパル(データベース・ユーザー) HRが特定のリソースに対してSELECT操作を実行するには、SELECT操作の前にプリンシパルHRにSELECT権限が付与されている必要があります。

アプリケーション権限は集約することもできます。集約権限は、他のアプリケーション権限が暗黙的に含まれるアプリケーション権限です。これらの暗黙権限は、現在のセキュリティ・クラスまたは継承された権限によって定義された任意のアプリケーション権限です。集約権限が付与または拒否されると、その暗黙アプリケーション権限も暗黙的に付与または拒否されます。

集約権限は、アプリケーション権限の数が増加した場合でも簡単に使用できるようにします。たとえば、各アプリケーション権限を個別に付与するかわりに、関連するアプリケーション権限を集約権限にグループ化できます。次に、単一の権限付与によって、集約権限に含まれるすべてのアプリケーション権限にプリンシパルがアクセスできるようにすることが可能です。

1.2.4 Oracle Database Real Application Securityのセキュリティ・クラス

セキュリティ・クラスは、アプリケーション権限のセットの有効範囲です。

セキュリティ・クラスには、他のセキュリティ・クラスから継承したアプリケーション権限が含まれますが、それ自体の定義によるアプリケーション権限が含まれることもあります。

セキュリティ・クラスは、通常、アクセス制御リスト(ACL)に関連付けられており、ACLによってセキュリティ・クラスのアプリケーション権限を特定のプリンシパルに付与できます。アクセス制御リスト(ACL)を参照してください。

例4-4に、セキュリティ・クラス・ポリシーを作成する方法を示します。

1.2.5 アクセス制御エントリ(ACE)

アクセス制御エントリ(ACE)は、特定のプリンシパル(アプリケーション・ユーザーまたはアプリケーション・ロール)に対してアプリケーション権限を付与または拒否します。

ACEは、ace_listという配列の要素です。配列全体は、アクセス制御リスト(ACL)によって呼び出され、その一部になります。

ACEそれ自体は、保護するデータを指定しません(これは、受注表の行のセットなどのターゲット・データにACLを関連付けることで行われます)。この関連付けを作成するには、データ・レルムを作成してユーザーがそれらの行のみを変更するように制限するか、PL/SQLプロシージャのXS_DATA_SECURITY.SET_ACLSを使用します。

1.2.6 アクセス制御リスト(ACL)

アクセス制御リスト(ACL)は、1つ以上のプリンシパルに対してアプリケーション権限を許可または拒否するアクセス制御エントリ(ACE)のリストです。

作成したACLが独自のセキュリティ・クラスで定義されたカスタム・アプリケーション権限のセットに依存している場合、そのセキュリティ・クラスを明示的にACLに関連付ける必要があります。この例は、例4-15 を参照してください。

ACLで使用されているアプリケーション権限のみがDMLセキュリティ・クラスに定義されている場合、それがデフォルトであるため、セキュリティ・クラスの関連付けは不要です。DMLセキュリティ・クラスの説明を参照してください。

1.2.7 データ・セキュリティ・ポリシー

データベース表内のデータを保護するには、データ・セキュリティ・ポリシーを作成する必要があります。データベース・レコードは、行レベルと列レベルの両方で、この項で説明しているファイングレイン・アクセス制御を使用して保護できます。

データ・セキュリティ・ポリシーは、次の機能を実行します。

保護するデータを指定します。データは、設計する1つ以上の行のデータ・レルム内のWHERE句で指定できます。関連付け演算子を使用して、矢印(=>)の左側のパラメータを矢印の右側の実際のパラメータに割り当てることにより、名前付き表記を使用して定義することもできます。たとえば、例5-20では、各realmは関連付け演算子を使用して定義されています。

データ・セキュリティ・ポリシーには、1つ以上のデータ・レルムを含めることができます。
データ・レルムの行および列にアクセスするために必要なアプリケーション権限を指定する1つ以上のアクセス制御リスト(ACL)に各データ・レルムを関連付け、データ・レルム制約と呼ばれるものを作成します。指定されたACLは、指定されたデータ・レルムを保護し、特定のアプリケーション・ユーザーまたはアプリケーション・ロール(プリンシパル)へのアクセスを制御します。(ACLの詳細は、アクセス制御リスト(ACL)を参照してください。)
オプションで、特定の列を保護するために追加のアプリケーション権限を適用して、列制約と呼ばれるものを作成します。これは、機密データのためにセキュリティの特別なレイヤーを追加する必要がある場合に役立ちます。
追加のカスタム・アプリケーション権限を関連付けます。たとえば、管理者は、ユーザーが行に特定のアクションを実行できるかどうかを制御するAPPROVE_TRANSACTION権限を作成できます。SELECT権限がすべてのユーザーに付与されている場合、すべてのユーザーが行を参照できますが、トランザクション承認アクションを実行できるのは一部のユーザーのみです。

つまり、ログインしたアプリケーション・ユーザーは、関連付けられたACLのアプリケーション権限に基づいて、データ・レルム内のレコード(データの個々の行を含む)に対してDMLなどの操作の実行のみが許可されます。このように、データ・セキュリティ・ポリシーは、関連付けられたACLに含まれるアプリケーション権限を持つアプリケーション・ユーザーにアクセスを許可することでデータ・レルムを保護するデータ・レルム制約および列制約で構成されます。

たとえば、すべての販売担当者、その地域、担当製品、製品カテゴリおよび製品価格をリストした販売表があるとします。各販売担当者がログオンすると、データ・レルム制約に基づいて、特定の製品カテゴリの販売担当者など、他のすべての販売担当者の選択データが表示されます。製品価格の表示を、地域ごとの販売担当者に制限する場合、製品価格が表示される列に追加のアプリケーション権限を適用できます(この場合は列制約を使用します)。

データベース・オブジェクトの保護方法の詳細は、データ・セキュリティの構成を参照してください。

1.3 アプリケーション・セキュリティで使用されるアプリケーション・セッションの概念

Real Application Securityでは、アプリケーション・セッションの概念が導入されています。アプリケーション・セッションのコンテキストでは、3つのタイプのユーザー・アイデンティティがあります。

アプリケーション・セッション・ユーザー: アプリケーション・セッションに関連付けられたユーザー。

データベース・オブジェクトへのアプリケーション・セッション・アクセスは、このユーザーに付与された権限に対してチェックされます。
従来の(重量)セッション・ユーザー: データベース・セッションを確立したユーザー。

データベース認証資格証明が使用できるかぎり、このユーザーはアプリケーション・ユーザーまたはデータベース・ユーザーです。
スキーマ所有者: データベース・スキーマは、従来のデータベース・セッションに関連付けられているスキーマであり、オブジェクト名の解決にのみ使用されます。

従来のデータベース・ユーザー・セッションは、次の特徴を持っています。

トランザクションやカーソルなどの独自のデータベース・リソースを保持します。
多くのサーバー・リソースを消費します。

アプリケーション・セッションには次の特性があります。

アプリケーションのみに関連する情報を含みます。
各エンド・アプリケーション・ユーザー専用にできます。
アプリケーション・ユーザーがアプリケーションをログアウトするか、アプリケーションが異常終了するまで維持できます。

アプリケーション・セッションの詳細は、アプリケーション・セッションの構成を参照してください。

1.4 設計および開発のフロー

Real Application Securityを最大限に利用するには、この章で説明されている概念をよく理解する必要があります。

一般的には、データ・アクセスを制御するためにアプリケーション権限を必要とする、アプリケーションが実行するすべてのタスクを識別します。その後、適切なアプリケーション権限をセキュリティ・クラスに追加して、それらをACLで参照し、アプリケーション・ユーザーやアプリケーション・ロールに付与できるようにします。このプロセスは、次のタスクで構成されます。

アプリケーションが提供する機能に基づいて、有効なアプリケーション・ロールのデフォルト・セットを作成します。
アプリケーション表の設計およびセキュリティ要件に基づいて、データ・セキュリティ保護を必要とする表を識別し、データ・レルムを定義します(列の保護を含む)。
アプリケーション要件と表に適用されるルールに基づいて、データ・セキュリティ・ポリシーを定義します。
データ・セキュリティ・ポリシーおよび機能セキュリティで使用されるACLによって、アプリケーション・ロールに適切なアプリケーション権限が付与されることを確認します。

この項の内容は次のとおりです。

1.4.1 設計フェーズ

設計フェーズでは、データ・アクセスを制御するためのアプリケーション権限が必要となる、アプリケーションが実行するすべてのタスクを識別します。

たとえば、アプリケーション・ポリシー設計者は設計フェーズで次の項目を識別する必要があります。

アクセス制御が必要な一連のアプリケーション・レベル操作。
アプリケーション・レベル操作の中でアクセスできる表やビューの行と列。
それらの操作を実行できる一連のアクターまたはプリンシパル(ユーザーおよびロール)。
表またはビューの行を特定するランタイム・アプリケーション・セッション属性。これらの属性名は、認可する行を選択する述語内で使用され、属性の値はアプリケーションの実行時に設定されます。

1.4.2 開発フロー・ステップ

開発フェーズでは、Real Application Security管理者として、Real Application Securityコンポーネントを使用してデータ・セキュリティ・ポリシーを開発します。

次のステップに従い、データ・セキュリティ・ポリシーを開発します。

対応するアプリケーション・ユーザーおよびロールを作成します。外部ディレクトリ・サーバーを使用している場合は、そのディレクトリ・サーバーでアプリケーション・ユーザーおよびロールまたはユーザー・グループを作成します。次の手順に従って、これらのプリンシパルをデータベース固有になるように作成します。
1. アプリケーション・ロールを作成し、必要に応じてアプリケーション・ロールをアプリケーション・ロールに付与します。「アプリケーション・ロールの構成について」を参照してください。
2. アプリケーション・ユーザーを作成し、アプリケーション・ロールをアプリケーション・ユーザーに付与します。「アプリケーション・ユーザーの構成について」を参照してください。
3. 外部ストアのプリンシパルが使用されている場合に、ユーザーおよびロールをフェッチするようにディレクトリ・サーバーを構成するには、『Oracle Database Real Application Security管理』のRASADM構成情報を参照してください。
4. 外部ディレクトリ・サーバーのユーザーおよびロールについては、『Oracle Database Real Application Security管理』のRASADMをディレクトリ・サーバーとともに使用するためのパラメータ設定の管理を参照してください。
アプリケーションのセキュリティ・ポリシーの開発に使用する各権限クラスを作成します。各権限クラスは、ACLで定義して参照可能で、アプリケーション・ユーザーおよびアプリケーション・ロールに付与することもできる1つ以上の適切な権限で構成されます。各権限クラスは、ACLを使用して、データ・セキュリティ・ポリシーの必要なアプリケーション・レベルの操作を認可します。「セキュリティ・クラスの構成について」および「アクセス制御リストの構成について」を参照してください。
異なるアプリケーション・セッション間で使用できる1つ以上のセッション・ネームスペースを作成します。これは、セッション・ネームスペース、そのプロパティ(アプリケーション属性)のセット、リストからの選択または作成が可能な、関連付けられたアクセス制御ポリシーまたはACLの定義で構成されます。「アプリケーション・セッションの状態の操作について」を参照してください。
各データ・レルムとACLを関連付けることで、データ・セキュリティ・ポリシーを作成します。必要に応じて、データ・レルム認可と列認可の両方を作成します。「データ・セキュリティについて」を参照してください。

このプロセスは、次の4つの部分で構成されます。
1. ポリシー情報 - 保護されるオブジェクトと、オブジェクトを保護する権限クラスを選択し、ポリシー名を指定して、ポリシー所有者を選択します。「データ・セキュリティ・ポリシーの構造の理解」を参照してください。
2. 列レベルの認可 - 保護される列の名前を選択し、列にアクセスするために付与される権限を選択します。この列はステップ3aで選択した権限クラスに関連付けられています。「列への追加のアプリケーション権限の適用」を参照してください。
3. データ・レルム認可 - 保護されるデータ・レルムを表すSQL述語を作成し、それぞれをデータ・レルム付与リストに追加します。それから、データ・レルムを保護するACLを選択または作成します。次に、各プリンシパルと、適切な権限を選択することでそのプリンシパルが許可された認可か拒否された認可かどうかで構成される、権限付与リストに追加される権限付与を作成します。「データ・レルムの設計について」を参照してください。
4. ポリシーの適用 - 作成しているデータ・セキュリティ・ポリシーを適用、削除、有効化または無効化でき、特定の適用オプションを指定するよう選択できます。これにより、表またはビューの所有者は、このデータ・セキュリティ・ポリシー、およびこのポリシーの文タイプを施行するかどうかを省略できます。「データベース表またはビューに対するデータ・セキュリティ・ポリシーの有効化について」を参照してください。

1.5 シナリオ: 従業員情報のセキュリティ人事管理(HR)デモ

この項では、Real Application Securityの概要を示すサンプル・ポリシーを紹介します。これは、Real Application Securityの基本概念の説明を目的とした単純なシナリオです。Real Application Securityで使用されるデータ・セキュリティの概念で説明されている次の概念をよく理解する必要があります。

プリンシパル: アプリケーション・ユーザーおよびアプリケーション・ロール
セキュリティ・クラスおよびアプリケーション権限
アクセス制御リストおよびエントリ(ACLおよびACE)
データ・セキュリティ・ポリシー

Real Application Securityの様々なコンポーネントを説明するために、このマニュアル全体で同じシナリオが使用されます。Real Application Securityの高度な概念を使用して複雑なポリシーを処理する方法を示すために、Real Application Security HRデモおよびReal Application Security HRデモ・ファイルでも詳細に説明されています。

この項には次のトピックが含まれます:

1.5.1 基本的なHRデモ・シナリオ: 説明とセキュリティ要件

Susan Mavris (SMAVRIS)は、人事管理部門の従業員です。彼女の職種は、人事担当です。この資格で、部門60 (IT)を含むすべての従業員の人事情報の管理を担当します。SALARY列を含むすべての従業員レコードを表示および更新できます。

David Austin (DAUSTIN)は、IT部門の従業員です。彼の職種は、アシスタント部門マネージャです。この資格で、IT部門の従業員レコードを表示できますが、自分の給与レコード以外のSALARY列は表示できません。

セキュアな認可では、どのアプリケーション・ユーザーおよびアプリケーション・ロールが、どのような種類の操作を実行するために、どのデータにアクセスできるかを定義することが必要です。保護対象データ、プリンシパルおよびアプリケーション権限というセキュリティ上の3つの次元を定義する必要があります(Oracle Database Real Application Securityによるデータ・セキュリティについてを参照)。

この基本シナリオの場合:

保護するデータは従業員情報で、3通りの方法で保護されます。
- SALARY列を含む、従業員自身のレコードへのアクセス。
- SALARY列を除く、IT部門のすべてのレコードへのアクセス。
- SALARY列を含むすべての従業員レコードへのアクセス。
ユーザーは、次の方法で従業員データにアクセスできます。
- 各ユーザーが、SALARY列を含む自分のレコードを表示できます。
- アシスタント部門マネージャとしてのロールでのアプリケーション・ユーザーDAUSTINは、SALARY列を除き、IT部門のすべてのレコードを表示できます。
- 人事担当者としてのロールでのアプリケーション・ユーザーSMAVRISは、SALARY列を含むすべての従業員レコードを表示および更新できます。
データベース・ロールDB_EMPが作成され、HR.EMPLOYEESに対するSELECT、INSERT、UPDATEおよびDELETE権限が付与されます。
アプリケーション・ロールは次のように作成されます。
- EMPLOYEEロールは、DAUSTINとSMAVRISの両方のアプリケーション・ユーザーに付与されます。データベース・ロールDB_EMPはEMPLOYEEロールに付与されます。
- IT_ENGINEERロールはアプリケーション・ユーザーDAUSTINにのみ付与されます。データベース・ロールDB_EMPはIT_ENGINEERロールに付与されます。
- HR_REPRESENTATIVEロールはアプリケーション・ユーザーSMAVRISにのみ付与されます。データベース・ロールDB_EMPはHR_REPRESENTATIVEロールに付与されます。
VIEW_SALARYアプリケーション権限が作成され、SALARY列へのアクセスを制御します。VIEW_SALARYアプリケーション権限の有効範囲を指定するHR_PRIVILEGESセキュリティ・クラスが作成されます。
ACLが作成され、従業員レコードへのアクセスのレベルを次の方法で定義します。
- EMP_ACLは、SALARY列を含む従業員自身のレコードを表示するためのSELECTデータベース権限とVIEW_SALARYアプリケーション権限をEMPLOYEEロールに付与します。
- IT_ACLは、IT_ENGINEERロールにIT部門内の従業員レコードを表示するためのSELECTデータベース権限のみ付与し、SALARY列へのアクセスに必要なVIEW_SALARY権限は付与しません。
- HR_ACLは、HR_REPRESENTATIVEロールに対して、すべての従業員のレコードの表示と更新を行うためのSELECT、INSERT、UPDATE、DELETEデータベース権限と、SALARY列を表示するためのVIEW_SALARYアプリケーション権限を付与します。
HRデモは、次の3つのデータ・レルムおよび列制約を持つデータ・セキュリティ・ポリシーEMPLOYEES_DSを作成および適用することで、HR.EMPLOYEE表を保護します。
- 従業員の固有のレコード・レルム。ACL EMP_ACLはこのレルムを制御し、SALARY列を含むレルムにアクセスするためのEMPLOYEE権限をアプリケーション・ロールに付与します。
- IT部門レルム内のすべてのレコード。ACL IT_ACLはこのレルムを制御し、SALARY列を除くレルムにアクセスするためのIT_ENGINEER権限をアプリケーション・ロールに付与します。
- すべての従業員レコード・レルム。ACL HR_ACLは、このレルムを制御し、SALARY列を含むレルムにアクセスするためのHR_REPRESENTATIVE権限をアプリケーション・ロールに付与します。
- 機密データの表示にVIEW_SALARY権限を要求することでSALARY列を保護する列制約。

1.5.2 基本のHRシナリオ: 実装の概要

基本の人事セキュリティ・シナリオを実装するには、保護対象データ、プリンシパルおよびアプリケーション権限を識別することに加え、次のものを定義する必要があります。

Real Application Security管理者としてのデータベース・ユーザー、Real Application Security管理者として接続してコンポーネントを作成します。
プリンシパルがデータベースに接続してデータにアクセスする方法。
アプリケーション権限および任意のデータベース権限をプリンシパルに付与するアクセス制御リスト(ACL)。
ACLを、プリンシパルがアクセスする必要のある特定のデータ(行)に関連付けるデータ・セキュリティ・ポリシー。

この基本的なシナリオでは、アプリケーション・ユーザーSMAVRISおよびDAUSTINはプリンシパルとしてデータベースに直接接続します。

アプリケーション・ユーザーSMAVRISおよびDAUSTINに対して作成されるアプリケーション・ユーザー・アカウントは、このシナリオではプリンシパルです。各アプリケーション・ユーザー・アカウントには、最終的に、従業員情報を含むデータベース表に対するSELECT権限を持つアプリケーション・ロールが付与されます。アプリケーション・ロールは、このシナリオにおけるプリンシパルです。

データベース権限はデータベース・ユーザーおよびロールにのみ付与できるため、データベース・ロールDB_EMPは、アプリケーション・ロールとデータベース権限間の中間ロールとして機能します。つまり、必要なデータベース権限がデータベース・ロールに付与され、そのロールが各アプリケーション・ロール(プリンシパル)に付与されます。

データベースのSELECT権限は、表全体に適用されます。プリンシパルには、DML SELECT権限などのReal Application Securityアプリケーション権限も付与する必要があります(データベース表の特定の行に制限可能)。この制限は、アクセス制御リスト(ACL)とデータ・セキュリティ・ポリシーを使用して実装されます。

HRシナリオでは、セキュリティ・モデルに次の構成要素が必要です。

保護されたデータ: 従業員情報は、サンプル・データベース・スキーマHR (Oracle Databaseに付属)のEMPLOYEES表に格納されます。
アプリケーション・ロール: アプリケーション・ロールEMPLOYEE、IT_ENGINEERおよびHR_REPRESENTATIVEはタスクの実行用に作成されます。アプリケーション・ロールはXS_PRINCIPAL.CREATE_ROLEプロシージャで定義されます。
アプリケーション・ユーザー: アプリケーション・ユーザーSMAVRISおよびDAUSTINが作成および定義されます。SMAVRISにアプリケーション・ロールEMPLOYEEおよびHR_REPRESENTATIVEが付与されます。DAUSTINにアプリケーション・ロールEMPLOYEEおよびIT_ENGINEERが付与されます。
データベース・アクセス: アプリケーション・ユーザーSMAVRISおよびDAUSTINに、直接データベース・ログイン用のデータベース・パスワードが付与されます。EMPLOYEES表に対するSELECT、INSERT、UPDATEおよびDELETE権限をアプリケーション・ロールEMPLOYEE、IT_ENGINEER、HR_REPRESENTATIVEに付与するには、データベース・ロールDB_EMPが作成され、これらのデータベース権限が付与されている必要があります。アプリケーション・ロールにこのデータベース・ロールが付与されます。
アプリケーション権限: 単一のカスタム・アプリケーション権限VIEW_SALARY_を定義する単一のセキュリティ・クラスHR_PRIVILEGESが作成されます。継承を通じて、事前定義されたアプリケーション権限SELECTもこのセキュリティ・クラスで使用できます。これらのアプリケーション権限は、従業員情報への読取りアクセスを許可するためにデータ・セキュリティ・ポリシーと組み合せて使用されます。セキュリティ・クラスは、XS.SECURITY_CLASS.CREATE_SECURITY_CLASSプロシージャによって作成されます。
ACL: XS_ACL.CREATE_ACLプロシージャで作成されたアクセス制御リスト(ACL) EMP_ACLによって、SELECTおよびVIEW_SALARY権限がアプリケーション・ロールEMPLOYEEに付与されます。XS_ACL.CREATE_ACLプロシージャによって作成されたACL IT_ACLによって、SELECT権限がアプリケーション・ロールIT_ENGINEERに付与されます。XS_ACL.CREATE_ACLプロシージャで作成されたHR_ACLというACLによって、アプリケーション・ロールHR_REPRESENTATIVEに、すべての従業員のレコードを表示および更新するためSELECT、INSERT、UPDATEおよびDELETE権限と、SALARY列を表示するためのVIEW_SALARYアプリケーション権限が付与されます。
データ・セキュリティ・ポリシー: データ・セキュリティ・ポリシーは、XS_DATA_SECURITY.CREATE_POLICYプロシージャで定義および作成されます。このデータ・セキュリティ・ポリシーは、3つのデータ・レルム(SALARY列を含むレルムを表示できる従業員の固有レコード・レルム、SALARY列を除くIT部門を表示できるIT部門内のすべてのレコードのレルム、およびSALARY列を含むレルムを表示できるすべての従業員レコードのレルム)と列制約を定義します。データ・セキュリティ・ポリシーは、ACL EMP_ACL、IT_ACLおよびHR_ACLをそれぞれのデータ・レルムに関連付けます。

この章でこの例を紹介した目的は、Real Application Securityを使用してポリシーを実装するための要件の概要を示すことにあります。これらのタスクを実際に実装する場合、この章で紹介したReal Application Securityの概念と、後続の章で検討する概念をすべて体系的に理解する必要があります。実装の詳細を含む完全な例は、Real Application Security: 全体のまとめを参照してください。

1.6 Oracle Database Real Application Security環境での監査について

セキュリティのもう1つの側面は、Oracle Database Real Application Security環境で監査を行うことです。統合監査ポリシーを構成および有効化することで、Real Application Securityの管理アクションおよび実行時アクションを監査できます。Oracle Database Real Application Security環境での統合監査については『Oracle Databaseセキュリティ・ガイド』を参照してください。

Oracle Database Real Application Securityの監査ポリシーのために、次の静的データ・ディクショナリ・ビューが定義されています。

DBA_XS_AUDIT_POLICY_OPTIONS - Real Application Securityの統合監査ポリシーに定義された監査オプションを記述します。詳細は、『Oracle Databaseリファレンス』を参照してください。
DBA_XS_AUDIT_TRAIL - 監査されたReal Application Securityの詳細情報が提供されます。詳細は、『Oracle Databaseリファレンス』を参照してください。
DBA_XS_ENB_AUDIT_POLICIES - Real Application Securityの統合監査ポリシーが有効なユーザーのリストを表示します。詳細は、『Oracle Databaseリファレンス』を参照してください。

1.7 プラガブル・データベースのサポート

マルチテナント・アーキテクチャにより、Oracle Databaseにスキーマ、スキーマ・オブジェクトおよび非スキーマ・オブジェクトのポータブル・コレクションを含めることができ、これらはOracle Real Application Securityアプリケーション・ユーザーに個別のデータベースとして表示されます。マルチテナント・コンテナ・データベース(CDB)は、1つ以上のユーザー作成のプラガブル・データベース(PDB)を含むOracle Databaseです。

Oracle Real Application SecurityをOracle Multitenantとともに使用すると、統合のセキュリティがさらに強化されます。

Oracle Real Application Securityのエンティティの有効範囲はPDB内に指定されるため、各PDBには、ユーザー、ロール、権限、ACL、データ・セキュリティ・ポリシーなどの独自のReal Application Securityメタデータが存在します。そのため、Real Application Securityでは、PDB内でのアプリケーション間、およびコンテナ・データベースでのPDBと共通特権ユーザー間の特権ユーザー・アクセスを禁止できます。

SYSがOracle Real Application Securityエンティティのスキーマ所有者であるため、rootで作成されたReal Application SecurityエンティティはrootのSYSユーザーによってのみアクセスできます。同様に、その他のオペレーティング・システムにおいても、Oracle Real Application Securityエンティティのスキーマ所有者はSYSユーザーであり、これらのエンティティにアクセスできるのはSYSユーザーのみです。同じように、ローカルPDB内に作成されたReal Application Securityエンティティには、ローカルPDB内でのみアクセスできます。

Oracle Real Application Security直接ログイン・ユーザーにはパスワードが関連付けられているため、これらのユーザーをサポートするための単一のsqlnet.oraパラメータを使用して、PDB内でプロビジョニングされます。

Oracle Real Application Securityの管理にはPDB固有の管理権限とスキーマが含まれ、Real Application Securityエンティティの名前が修飾されます。スキーマ名を共有にすることはできますが、共通スキーマの命名有効範囲に基づいて作成された共通スキーマは共通ではありません。

Oracle Real Application Securityの監査はPDB固有です。

Oracle Real Application Securityのアプリケーション・ユーザーは、関連するPDBにプラガブル・データベースが適切に設定されているサービスを使用してそのPDBに接続できます。