1. Oracle Analytics Serverメタデータ・リポジトリの管理
  2. メタデータ・リポジトリの作成
  3. リポジトリ・オブジェクトへのデータ・アクセス・セキュリティの適用
  4. オブジェクト権限

オブジェクト権限

リポジトリでオブジェクト権限を設定すると、プレゼンテーション・レイヤーおよびビジネス・モデルとマッピング・レイヤーのオブジェクトへのアクセスを制御できます

オブジェクト権限はOracle BI管理ツールを使用して設定します。

オブジェクト権限を設定するには:

  • 特定のアプリケーション・ロールに対するデータ・アクセスを設定します。

  • 複数のアプリケーション・ロールで同じオブジェクトに対する異なるレベルのアクセスがある場合、機能グループを指定します。

  • プレゼンテーション・レイヤーで個々のオブジェクトを選択します。

特定のアプリケーション・ロールを割り当てられたユーザーに共通する一連のオブジェクトにデータ・アクセス権限を定義する場合、アプリケーション・ロールにオブジェクト権限を設定します。データ・アクセスの管理を簡素化するには、個々のユーザーに対してではなく、特定のアプリケーション・ロールに対してオブジェクト権限を設定する必要があります。

次の図は、ユーザーに対する特定のリポジトリ・オブジェクトの表示がオブジェクト権限によって制限されることを示しています。セキュリティ・ルールは受信するすべてのクライアント問合せに適用され、たとえ論理SQL問合せが変更される場合であっても違反は許可されません。この例では、Administratorアプリケーション・ロールにBooked Amount列へのアクセス権が付与されているため、管理者は返される結果を確認できます。ユーザーAnne GreenはBooked Amount列へのアクセス権を持つアプリケーション・ロールのメンバーではないため、アンサーのサブジェクト領域でこの列を確認できません。問合せが変更されても、アプリケーション・ロール・ベースのオブジェクト権限が設定されているため、Booked Amount列の結果は返されません。

data_sec_3.gifの説明が続きます
図data_sec_3.gifの説明

  • アプリケーション・ロールに複数のソースからのオブジェクトに対する権限がある場合(たとえば、明示的に設定される場合と、他の1つ以上のアプリケーション・ロールを通じて設定される場合)、その権限は優先度の順序に基づいて適用されます。

  • 子オブジェクトを持つオブジェクトへのアクセスを明示的に拒否した場合、個々のアプリケーション・ロールのメンバーであるユーザーは、子オブジェクトへのアクセスが拒否されます。たとえば、特定の論理表へのアクセスを明示的に拒否している場合、その表に関連付けられているすべての論理列へのアクセスも暗黙的に拒否することになります。

  • オブジェクト権限はリポジトリ変数およびセッション変数には適用されないため、これらの変数の値は保護されません。変数の名前を知っている人、または名前を推測できる人であれば誰でも、アンサーの式または論理SQL問合せの中でその変数を使用できます。パスワードなどの機密データは、セッション変数やリポジトリ変数に設定しないでください。

  • AuthenticatedUserアプリケーション・ロールにデフォルトで付与される権限のレベルを制御できます。AuthenticatedUserは、新しいリポジトリ・オブジェクトに関連付けられるデフォルトのアプリケーション・ロールです。

    AuthenticatedUserアプリケーション・ロールは、認証済ユーザーを意味します。AuthenticatedUserアプリケーション・ロールは、Oracle BIリポジトリ内のものです。AuthenticatedUserアプリケーション・ロールは、接続プールおよびプレゼンテーション・レイヤーのオブジェクトの「権限」ダイアログに表示されます。AuthenticatedUserは、Identity Managerのアプリケーション・ロールのリストには表示されません。

    NQSConfig.INIファイルのDEFAULT_PRIVILEGESパラメータを更新してください。Oracle Analytics Serverの管理のSecurityセクションのパラメータを参照してください。

オブジェクト権限の設定

次のステップを使用すると、リポジトリで個々のアプリケーション・ロールのオブジェクト権限を設定して、プレゼンテーション・レイヤーおよびビジネス・モデルとマッピング・レイヤーのオブジェクトへのアクセスを制御できます。

最初にオンライン・モードでアプリケーション・ロールを変更した場合を除き、オフライン・モードを使用している場合は、アプリケーション・ロールは表示されません。「オフライン・モードでのデータ・アクセス・セキュリティの適用について」を参照してください。

  1. 管理ツールでリポジトリを開きます。
  2. 「管理」→「アイデンティティ」を選択します。
  3. 「Identity Manager」ダイアログのツリー・ペインで、「BIリポジトリ」を選択します。
  4. 右のペインで「アプリケーション・ロール」タブを選択し、オブジェクト権限を設定するアプリケーション・ロールをダブルクリックします。
  5. 「アプリケーション・ロール」ダイアログで「権限」をクリックします。
  6. 「ユーザー/アプリケーション・ロール権限」ダイアログの「オブジェクト権限」タブで、次のいずれかの手順を実行してオブジェクトを選択します。
    • 「追加」ボタンをクリックし、オブジェクトを見つけて「選択」をクリックします。
    • 空の行の「名前」フィールドをクリックし、オブジェクトを見つけて「選択」をクリックします
  7. 各オブジェクトに対して適切な権限を割り当てます。次のいずれかのオプションを選択できます。
    • 読取り: このオブジェクトに対しては読取りアクセスのみを許可します。
    • 読取り/書込み: このオブジェクトに対しては読取りと書込みの両方のアクセスを提供します。
    • アクセス権なし: このオブジェクトに対してはすべてのアクセスを明示的に拒否します。
  8. 「OK」をクリックし、再度「OK」をクリックして、Identity Managerに戻ります。

ユーザーおよびアプリケーション・ロールにおける権限の継承について

ユーザーは明示的に付与される権限を持つことができます。また、ユーザーはアプリケーション・ロールのメンバーシップを通じて付与される権限を持つこともできます。さらに、アプリケーション・ロールは他のアプリケーション・ロールのメンバーシップを通じて付与される権限を持つことができます。

ユーザーに対して明示的に付与される権限は、アプリケーション・ロールを通じて付与される権限よりも高い優先度を持ちます。また、アプリケーション・ロールに対して明示的に付与される権限は、他のアプリケーション・ロールを通じて付与される権限よりも高い優先度を持ちます。

ユーザーまたはアプリケーション・ロールに対して、同じレベルで複数のアプリケーション・ロールが作用し、それらが競合するセキュリティ属性を持つ場合、このユーザーまたはアプリケーション・ロールには最も制限の少ないセキュリティ属性が付与されます。今では、あるオブジェクトへのアクセス権を持つアプリケーション・ロールは、オブジェクトのコンテナへのアクセス権も持つ必要があります。たとえば、ApplicationRole 1が表Bに属する列Aにアクセスする権限を持っている場合、ApplicationRole1は表Bにアクセスする権限も持つ必要があります。ある同一のオブジェクトに関して、ユーザーに対して明示的に作用する権限は、アプリケーション・ロールを通じてユーザーに付与される権限よりも高い優先度を持ちます。

以前のリリースでは、前述のとおり、オブジェクトのコンテナへのアクセス権がアプリケーション・ロールに要求されることはありませんでした。その動作に戻すには、Oracle BIサーバーマシンに移動し、環境変数OBIS_SECURITY_10g_COMPATIBLEを作成して、1に設定します。

一方で、フィルタ定義は常に継承されます。たとえば、User1がRole1およびRole2のメンバーであり、Role1にはフィルタ定義が含まれておりRole2には含まれていない場合、このユーザーはRole1に定義されているフィルタ定義を継承します。

オブジェクト権限は、個々のユーザーにではなく、常にアプリケーション・ロールに対して定義するようにしてください。

inheritance1.gifの説明が続きます
図inheritance1.gifの説明
inheritance2.gifの説明が続きます
図inheritance2.gifの説明

この結果、権限は次のようになります。

  • User1はRole1およびRole2の直接のメンバーであり、Role3、Role4およびRole5の間接的なメンバーです。

  • Role5の優先度レベルはRole2よりも低いため、Role5によって課されるTableAへのアクセス拒否は、Role2を通じて付与される読取り権限によって無効になります。この結果、Role2によってTableAに対する読取り権限が提供されます。

  • Role1から得られる権限は、TableAではアクセス権なし、TableBでは読取り、TableCでは読取りとなります。

  • Role1とRole2は同じレベルの優先度を持ち、それぞれの権限は相反する(Role1ではTableAへのアクセスが拒否され、Role2ではTableAへのアクセスが許可される)ため、User1はより制限の少ないレベルを継承することになります。つまり、User1はTableAの読取りアクセス権を持つことになります。

  • User1に対して総合的に付与される権限は、TableA、TableBおよびTableCの読取りアクセス権です。

権限の継承1

1人のユーザー(User1)がおり、このユーザーにはある表(TableA)の読取り権限が明示的に付与されているとします。また、このUser1はRole1のメンバーであり、Role1はTableAへのアクセスが明示的に拒否されているとします。結果として得られるUser1の権限は、TableAの読取り権限です。

ユーザーに直接付与される権限はアプリケーション・ロールを通じて付与される権限よりも高い優先度を持つため、User1はTableAの読取り権限を持ちます。