| Oracle® Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド 12c (12.2.1.1.0) E77227-02 |
|
 前へ |
 次へ |
| Oracle® Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド 12c (12.2.1.1.0) E77227-02 |
|
|
前へ |
次へ |
リポジトリでオブジェクト権限を設定すると、プレゼンテーション・レイヤーおよびビジネス・モデルとマッピング・レイヤーのオブジェクトへのアクセスを制御できます。
オブジェクト権限は管理ツールを使用して設定します。
オブジェクト権限を設定する方法は2つあります。
Identity Manager (特定のアプリケーション・ロールの場合)。
「プレゼンテーション」レイヤー(個別のオブジェクトの場合)。
プレゼンテーション・レイヤーの個々のオブジェクトにオブジェクト権限を設定する方法の詳細は、プレゼンテーション・レイヤー・オブジェクトに対する権限の設定を参照してください。
多くのオブジェクトに一括で権限を定義する場合、特定のアプリケーション・ロールにオブジェクト権限を設定する方法が便利です。個々のユーザーではなく、必ず特定のアプリケーション・ロールにオブジェクト権限を設定するようにしてください。
この図は、ユーザーが閲覧可能な内容がオブジェクト権限によって制限される様子を示しています。セキュリティ・ルールは接続するすべてのクライアントに適用され、たとえ論理SQL問合せが変更される場合であっても違反は許可されません。この例では、管理者が属するアプリケーション・ロールにBooked Amount列へのアクセス権が付与されており、したがって管理者は返される結果を参照することができます。ユーザーAnne Greenはこのオブジェクトへのアクセス権を持つアプリケーション・ロールのメンバーではなく、アンサーのサブジェクト・エリアでこの列を参照することはできません。リクエストSQLが変更される場合であっても、設定されているアプリケーション・ロール・ベースのオブジェクト権限によって、この列の結果は返されません。
次の点を考慮してください。
アプリケーション・ロールに複数のソースからのオブジェクトに対する権限がある場合(たとえば、明示的に設定される場合と、他の1つ以上のアプリケーション・ロールを通じて設定される場合)、その権限は優先度の順序に基づいて適用されます。
子オブジェクトを持つオブジェクトへのアクセスを明示的に拒否した場合、個々のアプリケーション・ロールのメンバーであるユーザーは、子オブジェクトへのアクセスが拒否されます。たとえば、特定の論理表へのアクセスを明示的に拒否している場合、その表に関連付けられているすべての論理列へのアクセスも暗黙的に拒否することになります。
オブジェクト権限はリポジトリ変数およびセッション変数には適用されないため、これらの変数の値は保護されません。変数の名前を知っている人、または変数の名前を推測できる人であれば誰でも、でその変数をOracle BIアンサーの式または論理SQL問合せで使用できます。パスワードなどの機密データは、セッション変数やリポジトリ変数に設定しないでください。
AuthenticatedUserアプリケーション・ロールにデフォルトで付与される権限のレベルを制御できます。AuthenticatedUserは、新しいリポジトリ・オブジェクトに関連付けられるデフォルトのアプリケーション・ロールです。
NQSConfig.INIファイルのDEFAULT_PRIVILEGESパラメータを更新してください。詳細は、『Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』のセキュリティ・セクションのパラメータに関する項を参照してください。
AuthenticatedUserアプリケーション・ロールは、認証済ユーザーを意味します。AuthenticatedUserアプリケーション・ロールは、Oracle BIリポジトリ内のものです。AuthenticatedUserアプリケーション・ロールは、接続プールおよび「プレゼンテーション」レイヤーのオブジェクトの「権限」ダイアログに表示されますが、Identity Managerのアプリケーション・ロールのリストには表示されません。
個々のアプリケーション・ロールに対してオブジェクト権限を設定するには:
ユーザーは明示的に付与される権限を持つことができます。また、ユーザーはアプリケーション・ロールのメンバーシップを通じて付与される権限を持つこともできます。さらには、アプリケーション・ロールは他のアプリケーション・ロールのメンバーシップを通じて付与される権限を持つことができます。
ユーザーに対して明示的に付与される権限は、アプリケーション・ロールを通じて付与される権限よりも高い優先度を持ちます。また、アプリケーション・ロールに対して明示的に付与される権限は、他のアプリケーション・ロールを通じて付与される権限よりも高い優先度を持ちます。
ユーザーまたはアプリケーション・ロールに対して、同じレベルで複数のアプリケーション・ロールが作用し、それらが競合するセキュリティ属性を持つ場合、このユーザーまたはアプリケーション・ロールには最も制限の少ないセキュリティ属性が付与されます。今では、あるオブジェクトへのアクセス権を持つアプリケーション・ロールは、オブジェクトのコンテナへのアクセス権も持つ必要があります。たとえば、ApplicationRole 1が表Bに属する列Aにアクセスする権限を持っている場合、ApplicationRole1は表Bにアクセスする権限も持つ必要があります。ある同一のオブジェクトに関して、ユーザーに対して明示的に作用する権限は、アプリケーション・ロールを通じてユーザーに付与される権限よりも高い優先度を持ちます。
以前のリリースでは、前述のとおり、オブジェクトのコンテナへのアクセス権がアプリケーション・ロールに要求されることはありませんでした。その動作に戻すには、Oracle BIサーバーマシンに移動し、環境変数OBIS_SECURITY_10g_COMPATIBLEを作成して、1に設定します。
一方で、フィルタ定義は常に継承されます。たとえば、User1がRole1およびRole2のメンバーであり、Role1にはフィルタ定義が含まれておりRole2には含まれていない場合、このユーザーはRole1に定義されているフィルタ定義を継承します。
オブジェクト権限は、個々のユーザーにではなく、常にアプリケーション・ロールに対して定義するようにしてください。
この結果、権限は次のようになります。
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の読取り権限を持ちます。
権限の継承2
権限例の図に示されている状況について検討します。
