| Oracle® Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド 12c (12.2.1.3.0) E90110-03 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド 12c (12.2.1.3.0) E90110-03 |
|
|
前 |
次 |
Oracle BIリポジトリ・オブジェクトに使用できるデータ・アクセス・セキュリティについて説明します。
データ・アクセス・セキュリティは、データの参照および変更の権限を制御します。次のデータ・アクセス・セキュリティ・メソッドを使用できます。
行レベルのセキュリティ。
オブジェクト権限。
問合せ制限。
データ・アクセス・セキュリティの実装に必要なタスクには、ユーザー、グループおよびアプリケーション・ロールの管理、カスタムLDAPサーバーの設定、カスタム・オーセンティケータの管理などが含まれます。これらは、Oracle Business Intelligence Enterprise Editionセキュリティ・ガイドに記載されています。
SSL接続の設定。
アプリケーション・ロールと機能グループの定義。
データ・アクセス・セキュリティを実装する前に、ユーザーおよびアプリケーション・ロールを作成する必要があります。
アプリケーション・ロールと機能グループへのユーザーの割当て。
LDAPサーバーの設定。
カスタム・オーセンティケータの定義と管理。
Oracle BI管理ツールで、オンライン・モードを使用してデータ・アクセス・セキュリティを実装します。オフライン・モードを使用している場合は、オフライン・モードでのデータ・アクセス・セキュリティの適用についてを参照してください。Oracle Business Intelligenceの使用状況トラッキングでは、データ・アクセス・セキュリティの監査が実行されます。Oracle Business Intelligence Enterprise Editionシステム管理者ガイドの使用状況トラッキングの管理に関する項を参照してください。
この章のトピックは、次のとおりです:
メタデータ・リポジトリを開発したら、データ・セキュリティ・アーキテクチャを設定する必要があります。
データ・アクセス・セキュリティは次の目標を達成します。
不正なアクセスからのビジネス・データの保護。
リポジトリ・メタデータ(メジャーの定義など)の保護。
個々のユーザーがシステムの全体的なパフォーマンスに悪影響を及ぼすことの防止。
行レベル・データ・セキュリティはリポジトリとデータベースの両方に実装して施行できます。オブジェクト権限および問合せ制限はリポジトリ内に設定され、Oracle BIサーバーのみによって施行されます。
データベース内に行レベル・セキュリティを実装するように選択した場合でも、リポジトリ内にオブジェクト権限および問合せ制限を実装する必要があります。個々の表または他のオブジェクトに対するデータベース・レベルのオブジェクト制限があっても、アクセス権を持たないユーザーがこれらのリポジトリ・オブジェクトを表示することを防ぐことはできません。しかし、これらの表、列または他のオブジェクトに対する問合せは失敗します。これらのオブジェクトをすべてのクライアントから非表示にするには、オブジェクト権限を設定する必要があります。
Oracle BIサーバーには様々なクライアントが接続可能であるため、Oracle BIプレゼンテーション・サービス内でデータ・セキュリティを実装または施行することはできません。Oracle BIプレゼンテーション・サービスのセキュリティ制御のセットを使用すると、Oracle Business Intelligenceユーザー・インタフェース内の機能へのアクセス権限を設定できるほか、ダッシュボードや分析オブジェクトへのアクセス権限を設定できます。Oracle BIサーバーにセキュリティ制御を実装するだけの場合は、リポジトリとデータベースがSQLインジェクションでのハッカー攻撃やその他のセキュリティの脆弱性にさらされます。接続するすべてのクライアントに対して適用されるルールを作成するには、リポジトリ内にオブジェクト・レベルのセキュリティを提供する必要があります。
この表は、Oracle Business Intelligence用のセキュリティ・タスク情報の場所を示しています。
| タスク | 場所 |
|---|---|
デフォルト認証プロバイダ、または代替認証プロバイダを使用したユーザー認証の設定 |
Oracle Business Intelligence Enterprise Editionセキュリティ・ガイドのデフォルト・セキュリティ構成を使用したセキュリティの管理 |
デフォルト認証プロバイダでのユーザーおよびグループの作成と管理 |
Oracle Business Intelligence Enterprise Editionセキュリティ・ガイドの埋込みWebLogic LDAPサーバーでのユーザーとグループの管理 |
アプリケーション・ロールの作成およびデフォルト・ポリシー・ストアでのポリシー管理 |
Oracle Platform Security Servicesによるアプリケーションの保護のポリシー・ストアの管理 |
ポリシー・ストア内でアプリケーション・ロールとともに使用されるデフォルトのOracle Business Intelligenceの権限の表示と理解 |
Oracle Business Intelligence Enterprise Editionセキュリティ・ガイドのデフォルトの権限 |
オフライン・モードでのデータ・アクセス・セキュリティの適用、およびプレースホルダ・アプリケーション・ロールの設定 |
|
行レベル・データ・セキュリティの設定 |
|
リポジトリのオブジェクト権限の設定 |
|
問合せ制限の設定(ガバナー) |
|
シングル・サインオン(SSO)の設定 |
Oracle Business Intelligence Enterprise Editionセキュリティ・ガイドのSSO認証の有効化 |
SSL通信の有効化 |
Oracle Business Intelligence Enterprise Editionセキュリティ・ガイドのOracle Business IntelligenceのSSO構成 |
カスタム・オーセンティケータの管理 |
Oracle Business Intelligence Enterprise Editionセキュリティ・ガイドのカカスタム・オーセンティケータ・プラグインを使用した認証 |
Oracle Business Intelligenceでは、データベースに行レベルのセキュリティが必要です。
接続プールは、Oracle BIサーバーが各ユーザーの資格証明をデータベースに渡すように構成できます。
データベースはこの資格証明を使用して、データベースの行レベル・セキュリティ・ルールをユーザー問合せに適用します。
行レベルのデータベース・セキュリティは、データベース認証とは異なります。Oracle Business Intelligence Enterprise Editionセキュリティ・ガイドの認証に関する項を参照してください。行レベルのデータベース・セキュリティは、データベースの認可を提供し、データベース内の特定の行にアクセス・セキュリティを適用します。
この図は、Oracle Business Intelligenceの問合せにおいて、データベース内で行レベル・セキュリティが施行される方法を示しています。セキュリティ・ルールは接続するすべてのクライアントに適用され、たとえ論理SQL問合せが変更される場合であっても違反は許可されません。この例では、Oracle BIサーバーによって生成されるSQL問合せが同じであったとしても、問合せを生成したユーザーに応じて返される結果は異なります。返される結果は、データベース内に作成、施行されているルールに基づきます。
データベースのユーザー、権限およびセキュリティ・ポリシーを定義する必要があります。詳細は、データベースのドキュメントを参照してください。
行レベルのセキュリティを設定する場合は、次の構成情報について検討してください。
行レベルのセキュリティは、SSOを使用しているときや、偽装(デリバーなど)が関与するケースでは機能しません。これは、エンド・ユーザーのパスワードがOracle BIサーバーでは使用できないためです。
接続スクリプトを使用して、Oracle Databaseデータ・ソースに対して同じ機能を実行できます。
EssbaseまたはHyperion Financial Managementデータ・ソースの場合、接続プールでは、SSOを実装するための追加オプションが表示されます。
リポジトリ内またはデータベース内に行レベル・セキュリティを設定するように選択できます。
リポジトリ内に行レベル・セキュリティを実装することには多くの利点があります。それらを次に示します。
すべてのユーザーがデータベース接続プールを共有することによって、パフォーマンスが向上します。
すべてのユーザーがキャッシュを共有することによって、パフォーマンスが向上します。
多くのフェデレーテッド・データ・ソースに適用されるセキュリティ・ルールを定義し、維持することができます。
一方、データベース内に行レベル・セキュリティを実装することは、複数のアプリケーションでデータベースを共有するような状況において有用です。データベース内に行レベル・セキュリティを実装する場合は、リポジトリ内にオブジェクト権限を定義し適用する必要もあります。
リポジトリとデータベースの両方に行レベル・セキュリティを設定することが可能ですが、特別な必要性がないかぎり、両方の場所で行レベル・セキュリティを施行することは通常はありません。
この項では、次の項目について説明します。
Oracle BI管理ツールを使用して、特定のアプリケーション・ロールのリポジトリ・オブジェクトに対するデータ・フィルタを定義できます。
データベース内に行レベル・セキュリティを実装する場合、通常、データ・フィルタは設定しません。なぜなら、この場合、行レベル・セキュリティのポリシーはOracle BIサーバーではなく、データベースによって施行されるためです。
データ・フィルタは、ビジネス・モデルとマッピング・レイヤーおよびプレゼンテーション・レイヤーのオブジェクトに対して設定できます。論理オブジェクトにフィルタを適用すると、プレゼンテーション・レイヤーのそのオブジェクトを使用するすべてのオブジェクトに影響が及びます。プレゼンテーション・レイヤーのオブジェクトにフィルタを設定すると、基礎となる論理オブジェクトに設定されているその他すべてのフィルタとともに、そのフィルタがオブジェクトに適用されます。
この図は、Oracle BIサーバー内でデータ・フィルタ・ルールが施行される方法を示しています。セキュリティ・ルールは接続するすべてのクライアントに適用され、たとえ論理SQL問合せが変更される場合であっても違反は許可されません。
この例では、アプリケーション・ロールにフィルタが適用されています。Anne Green(そのロールのメンバー)がリクエストを送信するとき、返される結果はこのフィルタに基づいて制限されます。管理者ユーザーのアプリケーション・ロールにはフィルタは適用されないため、すべての結果が返されます。Oracle BIサーバーによって生成されるSQLでは、定義済のすべてのデータ・フィルタが考慮されます。
次のステップを使用してデータ・フィルタを割り当て、リポジトリ内で行レベルのセキュリティ・ルールを施行します。
データ・フィルタは、個々のユーザーに対してではなく、必ず特定のアプリケーション・ロールに対して設定してください。
フィルタを作成するには、まずフィルタを適用するサブジェクト領域からオブジェクトを選択します。次に、個々のオブジェクトに対してフィルタ式情報を設定します。たとえば、表内の他の列の値の範囲に基づいて結果を制限するための、「"Sample Sales"."D2 Market"."M00 Mkt Key" > 5」のようなフィルタを定義できます。
オフライン・モードでアプリケーション・ロールがIdentity Managerに表示されない場合は、オフライン・モードでのデータ・アクセス・セキュリティの適用についてを参照してください。
フィルタ定義の中ではリポジトリ変数およびセッション変数を使用することもできます。それらの変数を含める場合は、正しい構文になるように式ビルダーを使用してください。
論理ファクト表などのリポジトリ・オブジェクトに対して複数のアプリケーション・ロールから異なるレベルのアクセスがある場合、機能グループを作成して、特定のアプリケーション・ロールで表示が制限されているデータがそのアプリケーション・ロールに表示されないようにします。たとえば、地域の店員に対してその割当て地域の四半期の売上を表示しても、すべての地域における全セグメントの売上を表示しないようにして、機密情報がさらされないようにする場合、フィルタ処理する特定のアプリケーション・ロールに適した、異なるアクセス・レベルの機能グループを作成します。アプリケーション・ロールの機能グループの指定を参照してください。
次のステップでは、同じリポジトリ・オブジェクト(通常は論理ファクト表)に対する異なるデータ・アクセス・フィルタを使用してアプリケーション・ロールの機能グループを指定します。
定義された機能グループがない場合、関連付けられたロールにかかわらず、特定の表に適用されたすべてのセキュリティ・フィルタがOR演算子を使用して結合されます。ユーザーはセキュリティ・フィルタによって選択されたすべての行の結合を表示できるため、OR演算子の使用は多くの場合機能します。たとえば、次のようなフィルタがあるとします。
ロールAにフィルタProduct = 'Coke'が割り当てられます
ロールBにフィルタProduct = 'Pepsi'が割り当てられます
ユーザーにロールAとロールBが付与されている場合、そのユーザーはCokeとPepsiの両方の製品のデータを表示できます。
同じ表の2つのセキュリティ・フィルタが問合せで結合される場合、フィルタ条件はOR演算子を使用して結合されます(このことは、ディメンション表で定義されたほとんどのセキュリティ・フィルタに該当します)。次に例を示します。
Product = 'Coke' OR Product = 'Pepsi'
異なるディメンションのデータ・フィルタを使用して1つのファクト表を保護する場合は、機能グループを使用する必要があります。
この例では、ファクト表は次のフィルタを使用して保護されます。
ロールAにフィルタProduct = 'Coke'が割り当てられます
ロールBにフィルタProduct = 'Pepsi'が割り当てられます
ロールCにフィルタRegion = 'Southwest'が割り当てられます
機能グループを使用しない場合、ロールA、BおよびCのユーザーの問合せでは、3つのフィルタ条件がすべてOR演算子を使用して結合されます。次に例を示します。
(Product = 'Coke' OR Product = 'Pepsi' OR Region = 'Southwest')
ProductとRegionは独立したディメンションであるため、ロールA、BおよびCの結果を結合しても意味をなしません。OR演算子を使用して異なるディメンションのデータ・フィルタを結合すると、ユーザーに表示する必要がないデータ値にユーザーがアクセスできるようになります。
この例では、ユーザーはPepsiおよびCoke製品内のすべての地域のデータに加えて、Southwest地域内のすべての製品のデータを表示できます。
想定された動作を得るには(つまり、Southwest地域内のPepsiおよびCoke製品のデータのみをユーザーが表示できるようにするには)、AND演算子を使用して製品フィルタと地域フィルタを結合して、フィルタを変更する必要があります。次に例を示します。
(Product = 'Coke' OR Product = 'Pepsi') AND (Region = 'Southwest')
機能グループを使用してこれを行うには、次のようにセキュリティ・フィルタを機能グループに割り当てる必要があります。
ロールAにフィルタProduct = 'Coke' with functional group "Product"が割り当てられます
ロールBにフィルタProduct = 'Pepsi' with functional group "Product"が割り当てられます
ロールCにフィルタRegion = 'Southwest' with functional group "Region"が割り当てられます
同じ機能グループ内のすべてのフィルタはOR演算子を使用して結合され、異なる機能グループ内のすべてのフィルタのセットはAND演算子を使用して結合されます。各セキュリティ・フィルタに関連付けられた機能グループを選択することで、OR演算子とAND演算子を使用してフィルタを結合する方法を制御できます。
データ・フィルタを作成するには、リポジトリでのデータ・フィルタの設定を参照してください。
Oracle Business Intelligenceを設定するには、データベース内で行レベル・セキュリティを実装する必要があります。接続プールは、Oracle BIサーバーが各ユーザーの資格証明をデータベースに渡すように構成できます。
データベース内に行レベル・セキュリティを設定した後、プレゼンテーション・レイヤーなどのオブジェクトに対応するリポジトリ内でオブジェクト権限を設定する必要があります。また、問合せ制限(ガバナー)を設定することもできます。「オブジェクト権限の設定」および「問合せ制限の設定」を参照してください。
リポジトリでオブジェクト権限を設定すると、プレゼンテーション・レイヤーおよびビジネス・モデルとマッピング・レイヤーのオブジェクトへのアクセスを制御できます
オブジェクト権限はOracle BI管理ツールを使用して設定します。
オブジェクト権限を設定するには、次のようにします。
特定のアプリケーション・ロールに対するデータ・アクセスを設定します。
複数のアプリケーション・ロールで同じオブジェクトに対する異なるレベルのアクセスがある場合、機能グループを指定します。
プレゼンテーション・レイヤーで個々のオブジェクトを選択します。
特定のアプリケーション・ロールを割り当てられたユーザーに共通する一連のオブジェクトにデータ・アクセス権限を定義する場合、アプリケーション・ロールにオブジェクト権限を設定します。データ・アクセスの管理を簡素化するには、個々のユーザーに対してではなく、特定のアプリケーション・ロールに対してオブジェクト権限を設定する必要があります。
次の図は、ユーザーに対する特定のリポジトリ・オブジェクトの表示がオブジェクト権限によって制限されることを示しています。セキュリティ・ルールは受信するすべてのクライアント問合せに適用され、たとえ論理SQL問合せが変更される場合であっても違反は許可されません。この例では、Administratorアプリケーション・ロールにBooked Amount列へのアクセス権が付与されているため、管理者は返される結果を確認できます。ユーザーAnne GreenはBooked Amount列へのアクセス権を持つアプリケーション・ロールのメンバーではないため、Oracle BIアンサーのサブジェクト・エリアでこの列を確認できません。問合せが変更されても、アプリケーション・ロール・ベースのオブジェクト権限が設定されているため、Booked Amount列の結果は返されません。
アプリケーション・ロールに複数のソースからのオブジェクトに対する権限がある場合(たとえば、明示的に設定される場合と、他の1つ以上のアプリケーション・ロールを通じて設定される場合)、その権限は優先度の順序に基づいて適用されます。
子オブジェクトを持つオブジェクトへのアクセスを明示的に拒否した場合、個々のアプリケーション・ロールのメンバーであるユーザーは、子オブジェクトへのアクセスが拒否されます。たとえば、特定の論理表へのアクセスを明示的に拒否している場合、その表に関連付けられているすべての論理列へのアクセスも暗黙的に拒否することになります。
オブジェクト権限はリポジトリ変数およびセッション変数には適用されないため、これらの変数の値は保護されません。変数の名前を知っている人、または変数の名前を推測できる人であれば誰でも、でその変数をOracle BIアンサーの式または論理SQL問合せで使用できます。パスワードなどの機密データは、セッション変数やリポジトリ変数に設定しないでください。
AuthenticatedUserアプリケーション・ロールにデフォルトで付与される権限のレベルを制御できます。AuthenticatedUserは、新しいリポジトリ・オブジェクトに関連付けられるデフォルトのアプリケーション・ロールです。
AuthenticatedUserアプリケーション・ロールは、認証済ユーザーを意味します。AuthenticatedUserアプリケーション・ロールは、Oracle BIリポジトリ内のものです。AuthenticatedUserアプリケーション・ロールは、接続プールおよびプレゼンテーション・レイヤーのオブジェクトの「権限」ダイアログに表示されます。AuthenticatedUserは、Identity Managerのアプリケーション・ロールのリストには表示されません。
NQSConfig.INIファイルのDEFAULT_PRIVILEGESパラメータを更新してください。『Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』のセキュリティ・セクションのパラメータに関する項を参照してください。
次のステップを使用すると、リポジトリで個々のアプリケーション・ロールのオブジェクト権限を設定して、プレゼンテーション・レイヤーおよびビジネス・モデルとマッピング・レイヤーのオブジェクトへのアクセスを制御できます。
最初にオンライン・モードでアプリケーション・ロールを変更した場合を除き、オフライン・モードを使用している場合は、アプリケーション・ロールは表示されません。「オフライン・モードでのデータ・アクセス・セキュリティの適用について」を参照してください。
ユーザーは明示的に付与される権限を持つことができます。また、ユーザーはアプリケーション・ロールのメンバーシップを通じて付与される権限を持つこともできます。さらに、アプリケーション・ロールは他のアプリケーション・ロールのメンバーシップを通じて付与される権限を持つことができます。
ユーザーに対して明示的に付与される権限は、アプリケーション・ロールを通じて付与される権限よりも高い優先度を持ちます。また、アプリケーション・ロールに対して明示的に付与される権限は、他のアプリケーション・ロールを通じて付与される権限よりも高い優先度を持ちます。
ユーザーまたはアプリケーション・ロールに対して、同じレベルで複数のアプリケーション・ロールが作用し、それらが競合するセキュリティ属性を持つ場合、このユーザーまたはアプリケーション・ロールには最も制限の少ないセキュリティ属性が付与されます。今では、あるオブジェクトへのアクセス権を持つアプリケーション・ロールは、オブジェクトのコンテナへのアクセス権も持つ必要があります。たとえば、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の読取り権限を持ちます。
リポジトリおよびOracle BIプレゼンテーション・カタログで使用できるコマンドについて説明します。
次のコマンドを使用して、リポジトリおよびOracle BIプレゼンテーション・カタログに格納されているアプリケーション・ロールおよびユーザーを更新できます。
注意:
残りのアップロードおよび更新コマンド(たとえば、リポジトリのアップロード・コマンドやリポジトリ変数の更新コマンドなど)は、リポジトリのみを更新します。
アプリケーション・ロールおよびユーザー更新コマンドは、リポジトリのアプリケーション・ロールおよびユーザーを更新するRPDプラグインとOracle BIプレゼンテーション・カタログのアプリケーション・ロールおよびユーザーを更新するWEBCATプラグインの2つのプラグインを使用します。
これらのプラグインは個別に機能するため、一方の障害が他方に影響しません。部分的な障害または2つのプラグインのいずれかで障害が発生した場合、障害の根本原因に対処し、最初に実行したようにコマンドを再実行することをお薦めします。正常なプラグインの再適用は結果に影響しませんが、コマンドを再実行すると障害が発生したプラグインが再実行されます。
デフォルトでは、アプリケーション・ロールおよびユーザー更新コマンドは、2つのプラグインを実行します。実行順序はRPD、WEBCATの順になります。ただし、コマンドには、個々のプラグインを指定したり、プラグインのデフォルトの実行順序を逆にできる-Lオプションが含まれています。デフォルトの順序でコマンドを実行してください。1つのプラグインのみを実行したり、プラグインの順序を逆にすることが必要になる場合があります。
renameapprolesコマンドを使用して、特定のサーバー・インスタンスのために名前を変更するアプリケーション・ロールの情報を含むJSONファイルをアップロードします。
renameapprolesコマンドは、ランチャ・スクリプト(UNIXの場合はdatamodel.sh、Windowsの場合はdatamodel.cmd)を介して実行します。
ドメインがデフォルトのフォルダにインストールされている場合、ランチャ・スクリプトの場所は次のようになります。
Oracle_Home/user_projects/domains/Domain_Name/bitools/bin/datamodel.shまたはWindowsの場合はdatamodel.cmd
クライアント・インストールにドメイン名がない場合、ランチャ・スクリプトの場所は次のようになります。
Oracle_Home\bi\bitools\bin\datamodel.cmd
構文
renameapprolesコマンドは、次のパラメータをとります。
renameapproles -T inputfile.json[-L plugin list] -SI service instance -U cred username[-P cred password] [-S hostname] [-N <port number] [-SSL] [-H]
説明
Tは、サーバー・インスタンスのアプリケーション・ロール名の変更を含むJSON入力ファイルの名前を指定します。
SIは、コンポーネント・インスタンスの名前を指定します。
Lは、1つのプラグインの実行またはデフォルトのプラグイン実行順序を逆にすることを指定します。プラグインは、システムがリポジトリまたはOracle BIプレゼンテーション・カタログあるいはその両方に更新を適用する場合を決定します。「ユーザーおよびアプリケーション・ロール・コマンドの概要」を参照してください。
注意:
Lには次のオプションがあります。
RPD: このオプションを指定して、リポジトリのアプリケーション・ロール名のみ変更します。
WEBCAT: このオプションを指定して、Oracle BIプレゼンテーション・カタログのアプリケーション・ロール名を変更します。たとえば、Oracle BIプレゼンテーション・カタログのアプリケーション・ロール名を変更する場合は、-L WEBCATオプションを使用する必要があります。
WEBCAT,RPD: このオプションを指定して、デフォルトのプラグイン実行順序を逆にします。
デフォルトのプラグイン実行順序は、リポジトリ(RPD)、Oracle BIプレゼンテーション・カタログ(WEBCAT)の順になります。
このオプションを省略して、リポジトリ(RPD)、Oracle BIプレゼンテーション・カタログの順のデフォルト順序でプラグインを実行します。
Uは、Oracle BI EE認証に使用する有効なユーザー名を指定します。
Pは、Uに指定したユーザーの名前に対応するパスワードを指定します。パスワードを指定しない場合、コマンドの実行時にパスワードの入力を求められます。自動化されたスクリプティングを使用してコマンドを実行する場合にのみ、コマンドにパスワードを含めることをお薦めします。
Sは、Oracle BI EEホスト名を指定します。クライアント・インストールからコマンドを実行している場合のみ、このオプションを含めます。
Nは、Oracle BI EEポート番号を指定します。クライアント・インストールからコマンドを実行している場合のみ、このオプションを含めます。
SSLは、SSLを使用して Oracle WebLogic Serverに接続してコマンドを実行することを指定します。クライアント・インストールからコマンドを実行している場合のみ、このオプションを含めます。
Hは、使用方法の情報を表示し、コマンドを終了します。-Hを使用するか、パラメータを指定しないで.shを実行すると、ヘルプ・コメントが表示されます。
例
datamodel.sh renameapproles -T approlenames.json -SI bi -U weblogic -P password -S server1.example.com -N 7777 -SSL
アプリケーション・ロールの名前変更JSON入力ファイルの作成
次の構文を使用して、アプリケーション・ロールの名前変更JSON入力ファイルを作成します。
{
"Title":"Target Application Roles",
"App-Roles":[
{ "oldname":"<current_approle1>", "newname":"<new_approle1>" },
{ "oldname":"<current_approle2>", "newname":"<new_approle2>" },
{ "oldname":"<current_approle3>", "newname":"<new_approle3>" }
]
}
deleteapprolesコマンドを使用して、特定のサーバー・インスタンスから削除するアプリケーション・ロールのリストを含むJSONファイルをアップロードします。
ランチャ・スクリプト(UNIXの場合はdatamodel.sh、Windowsの場合はdatamodel.cmd)を介して、ユーティリティを実行します。
ドメインがデフォルトのフォルダにインストールされている場合、ランチャ・スクリプトの場所は次のようになります。
Oracle_Home/user_projects/domains/Domain_Name/bitools/bin/datamodel.shまたはWindowsの場合はdatamodel.cmd
クライアント・インストールにドメイン名がない場合、ランチャ・スクリプトの場所は次のようになります。
Oracle_Home\bi\bitools\bin\datamodel.cmd
「コマンドを使用する前の必知事項」および「ユーザーおよびアプリケーション・ロール・コマンドの概要」を参照してください。
構文
deleteapprolesコマンドは、次のパラメータをとります。
deleteapproles -T inputfile.json[-L plugin list] -SI service_instance -U cred_username[-P cred_password] [-S hostname] [-N port_number] [-SSL} [-H]
説明
Tは、サーバー・インスタンスから削除するアプリケーション・ロールを含むJSON入力ファイルの名前を指定します。
Lは、1つのプラグインの実行またはデフォルトのプラグイン実行順序を逆にすることを指定します。プラグインは、システムがリポジトリまたはOracle BIプレゼンテーション・カタログあるいはその両方に更新を適用する場合を決定します。RPDおよびWEBCATプラグインの使用方法の詳細は、ユーザーおよびアプリケーション・ロール・コマンドの概要を参照してください
次のオプションは、Lの場合に使用できます。
RPD: このオプションを指定して、リポジトリのアプリケーション・ロールのみ削除します。
WEBCAT: このオプションを指定して、Oracle BIプレゼンテーション・カタログのアプリケーション・ロールのみ削除します。アプリケーション・ロールを削除するときは、-L WEBCATオプションを使用する必要があります。
WEBCAT,RPD: このオプションを指定して、デフォルトのプラグイン実行順序を逆にします。デフォルトのプラグイン実行順序は、リポジトリ(RPD)、Oracle BIプレゼンテーション・カタログ(WEBCAT)の順になります。
デフォルトの順序でプラグインを実行する場合は、このオプションを省略します。
SIは、コンポーネント・インスタンスの名前を指定します。
Uは、Oracle BI EE認証に使用する有効なユーザー名を指定します。
Pは、Uに指定したユーザーの名前に対応するパスワードを指定します。パスワードを指定していないと、コマンドの実行時にパスワードの入力を求められます。自動化されたスクリプティングを使用してコマンドを実行する場合にのみ、コマンドにパスワードを含めることをお薦めします。
Sは、Oracle BI EEホスト名を指定します。クライアント・インストールからコマンドを実行している場合のみ、このオプションを含めます。
Nは、Oracle BI EEポート番号を指定します。クライアント・インストールからコマンドを実行している場合のみ、このオプションを含めます。
SSLは、SSLを使用して Oracle WebLogic Serverに接続してコマンドを実行することを指定します。クライアント・インストールからコマンドを実行している場合のみ、このオプションを含めます。
Hは、使用方法の情報を表示し、コマンドを終了します。-Hを使用するか、パラメータを指定しないで.shを実行すると、ヘルプ・コメントが表示されます。
例
datamodel.sh deleteapproles -T approlenames.json -SI bi -U weblogic -P password -S server1.example.com -N 7777 -SSL
アプリケーション・ロールの削除JSON入力ファイルの作成
次の構文を使用して、アプリケーション・ロールの削除JSON入力ファイルを作成します。
{
"Title":"Target Application Roles",
"App-Roles":[
{ "name":"<approle1>" },
{ "name":"<approle2>" },
{ "name":"<approle3>" }
]
}
renameusersコマンドを使用して、特定のサーバー・インスタンスに対して名前変更するユーザーの情報のリストを含むJSONファイルをアップロードします。
ランチャ・スクリプト(UNIXの場合はdatamodel.sh、Windowsの場合はdatamodel.cmd)を介して、ユーティリティを実行します。
ドメインがデフォルトのフォルダにインストールされている場合、ランチャ・スクリプトの場所は次のようになります。
Oracle_Home/user_projects/domains/Domain_Name/bitools/bin/datamodel.shまたはWindowsの場合はdatamodel.cmd
クライアント・インストールにドメイン名がない場合、ランチャ・スクリプトの場所は次のようになります。
Oracle_Home\bi\bitools\bin\datamodel.cmd
「コマンドを使用する前の必知事項」を参照してください。
「ユーザーおよびアプリケーション・ロール・コマンドの概要」を参照してください。
構文
renameusersコマンドは、次のパラメータをとります。
renameusers -T usernames.json[-L plugin list] -SI service instance -U cred username[-P cred password] [-S hostname] [-N port number] [-SSL] [-H]
説明
Tは、サーバー・インスタンスのユーザー名の変更を含むJSON入力ファイルの名前を指定します。
Lは、1つのプラグインの実行またはデフォルトのプラグイン実行順序を逆にすることを指定します。プラグインは、システムがリポジトリまたはOracle BIプレゼンテーション・カタログあるいはその両方に更新を適用する場合を決定します。
注意:
Lには次のオプションがあります。
RPD: このオプションを指定して、リポジトリのユーザー名のみ変更します。
WEBCAT: このオプションを指定して、Oracle BIプレゼンテーション・カタログのユーザー名を変更します。たとえば、Oracle BIプレゼンテーション・カタログのユーザー名を変更する場合、-L WEBCATオプションを使用する必要があります。
WEBCAT,RPD: このオプションを指定して、デフォルトのプラグイン実行順序を逆にします。デフォルトのプラグイン実行順序は、リポジトリ(RPD)、Oracle BIプレゼンテーション・カタログ(WEBCAT)の順になります。
デフォルトの順序でプラグインを実行する場合は、このオプションを省略します。
SIは、コンポーネント・インスタンスの名前を指定します。
Uは、Oracle BI EE認証に使用する有効なユーザー名を指定します。
Pは、Uに指定したユーザーの名前に対応するパスワードを指定します。パスワードを指定していないと、コマンドの実行時にパスワードの入力を求められます。セキュリティ上の目的のため、自動化されたスクリプティングを使用してコマンドを実行する場合のみコマンドにパスワードを含めることをお薦めします。
Sは、Oracle BI EEホスト名を指定します。クライアント・インストールからコマンドを実行している場合のみ、このオプションを含めます。
Nは、Oracle BI EEポート番号を指定します。クライアント・インストールからコマンドを実行している場合のみ、このオプションを含めます。
SSLは、SSLを使用して Oracle WebLogic Serverに接続してコマンドを実行することを指定します。クライアント・インストールからコマンドを実行している場合のみ、このオプションを含めます。
Hは、使用方法の情報を表示し、コマンドを終了します。-Hを使用するか、パラメータを指定しないで.shを実行すると、ヘルプ・コメントが表示されます。
例
datamodel.sh renameusers -T usernames.json -SI bi -U weblogic -P password -S server1.example.com -N 7777 -SSL
ユーザーの名前変更JSON入力ファイルの作成
次の構文を使用して、ユーザーの名前変更JSON入力ファイルを作成します。
{
"Title":"Target Users",
"Users":[
{ "oldname":"<current_user1>", "newname":"<new_user1>" },
{ "oldname":"<current_user2>", "newname":"<new_user2>" },
{ "oldname":"<current_user3>", "newname":"<new_user3>" }
]
}
deleteusersコマンドを使用して、特定のサーバー・インスタンスから削除するユーザーのリストを含むJSONファイルをアップロードします。
ランチャ・スクリプト(UNIXの場合はdatamodel.sh、Windowsの場合はdatamodel.cmd)を介して、ユーティリティを実行します。
ドメインがデフォルトのフォルダにインストールされている場合、ランチャ・スクリプトの場所は次のようになります。
Oracle_Home/user_projects/domains/Domain_Name/bitools/bin/datamodel.shまたはWindowsの場合はdatamodel.cmd
クライアント・インストールにドメイン名がない場合、ランチャ・スクリプトの場所は次のようになります。
Oracle_Home\bi\bitools\bin\datamodel.cmd
「コマンドを使用する前の必知事項」および「ユーザーおよびアプリケーション・ロール・コマンドの概要」を参照してください。
構文
deleteusersコマンドは、次のパラメータをとります。
deleteusers -T usernames.json [-L plugin list] -SI service_instance-U cred_username[-P cred_password] [-S hostname] [-N port_number] [-SSL] [-H]
説明
Tは、サーバー・インスタンスから削除するユーザーを含むJSON入力ファイルの名前を指定します。アプリケーション・ロール入力ファイルの正しい構文の詳細は、ユーザーの削除JSON入力ファイルの作成の構文を参照してください。
Lは、1つのプラグインの実行またはデフォルトのプラグイン実行順序を逆にすることを指定します。プラグインは、システムがリポジトリまたはOracle BIプレゼンテーション・カタログあるいはその両方に更新を適用する場合を決定します。
Lには次のオプションがあります。
RPD: このオプションを指定して、リポジトリのユーザーのみ削除します。
WEBCAT: このオプションを指定して、Oracle BIプレゼンテーション・カタログのユーザーのみを削除します。たとえば、Oracle BIプレゼンテーション・カタログからユーザーを削除する場合、-L WEBCATオプションを使用する必要があります。
WEBCAT,RPD: このオプションを指定して、デフォルトのプラグイン実行順序を逆にします。デフォルトのプラグイン実行順序は、リポジトリ(RPD)、Oracle BIプレゼンテーション・カタログ(WEBCAT)の順になります。
このオプションを省略して、リポジトリ(RPD)、Oracle BIプレゼンテーション・カタログ(WEBCAT)の順のデフォルト順序でプラグインを実行します。
SIは、コンポーネント・インスタンスの名前を指定します。
Uは、Oracle BI EE認証に使用する有効なユーザー名を指定します。
Pは、Uに指定したユーザーの名前に対応するパスワードを指定します。パスワードを指定していないと、コマンドの実行時にパスワードの入力を求められます。自動化されたスクリプティングを使用してコマンドを実行する場合にのみ、コマンドにパスワードを含めることをお薦めします。
Sは、Oracle BI EEホスト名を指定します。クライアント・インストールからコマンドを実行している場合のみ、このオプションを含めます。
Nは、Oracle BI EEポート番号を指定します。クライアント・インストールからコマンドを実行している場合のみ、このオプションを含めます。
SSLは、SSLを使用して Oracle WebLogic Serverに接続してコマンドを実行することを指定します。クライアント・インストールからコマンドを実行している場合のみ、このオプションを含めます。
Hは、使用方法の情報を表示し、コマンドを終了します。-Hを使用するか、パラメータを指定しないで.shを実行すると、ヘルプ・コメントが表示されます。
例
data-model-cmd.sh deleteusers -T usernames.json -SI bi -U weblogic -P password -S server1.us.example.com -N 777 -SSL
ユーザーの削除JSON入力ファイルの作成
次の構文を使用して、ユーザーの削除JSON入力ファイルを作成します。
{
"Title":"Target Users",
"Users":[
{ "name":"<user1>" },
{ "name":"<user2>" },
{ "name":"<user3>" }
]
}
特定のアプリケーション・ロールに対して、リポジトリ内に問合せ制限(ガバナー)を設定することによって、問合せ環境を管理することができます。
返される行数による制限、最大実行時間による制限、特定の時間帯への限定によって、問合せを制限することができます。また、直接データベース・リクエストや移入権限を許可したり、禁止したりすることもできます。
問合せ制限は、個々のユーザーに対してではなく、必ず特定のアプリケーション・ロールに対して設定してください。
この項では、次の項目について説明します。
「ユーザー/アプリケーション・ロール権限」ダイアログの「問合せ制限」タブにアクセスする方法を説明します。
注意:
オフライン・モードの場合、以前にオンライン・モードで変更されているアプリケーション・ロールを除き、リストにアプリケーション・ロールは表示されません。「オフライン・モードでのデータ・アクセス・セキュリティの適用について」を参照してください。
問合せに特定の行数制限を適用することによって、リソース集中型の問合せを制御することができます。
設定する問合せ制限は、エラー・メッセージを回避するために「表ビューのレンダリング時に処理された最大行数」および「最大ダウンロード行数」のプレゼンテーション・サーバー設定を少なくとも500超えている必要があります。リポジトリの「最大行数」問合せ制限を使用して特定のユーザーまたはアプリケーション・ロールにデータ・ソース行制限を課す場合、それらのユーザーは「最大行制限を超過しています」メッセージを受信する可能性があります。
『Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』の表およびピボット・テーブルのデータに対する構成オプションを設定するためのFusion Middleware Controlの使用に関する項および表を表示するために処理される最大行数を設定するためのFusion Middleware Controlの使用に関する項を参照してください。
「ステータス最大行数」のオプションは次のとおりです。
有効化: 行数を指定した値に制限します。行数が「最大行数」の値を超えると、問合せは停止されます。
無効化: 「最大行数」フィールドに設定されているすべての制限を無効にします。
警告: 制限を施行せず、設定されている制限を超える問合せについて問合せログに記録します。
無視: 制限は親のアプリケーション・ロールから継承されます。継承される行制限がない場合は、制限は施行されません。
管理ツール内の問合せ制限機能へのアクセスのステップを実行して、「問合せ制限」タブにアクセスします。
特定の時間帯に問合せを禁止したり、データベース上で実行可能な問合せの最大時間を指定したりすることができます。
特定の時間帯を選択しない場合、アクセス権は変更されません。1つ以上のアプリケーション・ロールのアクセスを明示的に許可または禁止する場合、定義された時間帯において最も制限の少ないアクセス権がユーザーに付与されます。たとえば、あるアプリケーション・ロールでは月曜日の全日に明示的にアクセスが許可されており、別のアプリケーション・ロールでは毎日のすべての時間においてアクセスが禁止されているとします。あるユーザーがこの両方のアプリケーション・ロールのメンバーである場合、このユーザーは月曜日のみアクセス権を持つことになります。
管理ツール内の問合せ制限機能へのアクセスのステップを実行して、「問合せ制限」タブにアクセスします。
データベース上で問合せが実行可能な最大時間を指定するには、「最大時間(分)」列に、各データベースオブジェクトで問合せが実行される最大の時間(分)を入力します。次に、「ステータス最大時間」フィールドで、各データベースに対して次のいずれかのオプションを選択します。
有効化: 指定した値に時間を制限します。
無効化: 「最大時間」フィールドに設定されているすべての制限を無効にします。
警告: 制限を施行せず、設定されている時間制限を超える問合せについて問合せログに記録します。
無視: 制限は親のアプリケーション・ロールから継承されます。継承される時間制限がない場合は、制限は施行されません。
データベースへのアクセスを特定の時間帯に制限するには、「制限」列で省略記号のボタンをクリックします。次に、「制限」ダイアログで次のステップを実行します。
時間帯を選択するには、開始時間をクリックし、終了時間までドラッグします。
明示的にアクセスを許可するには、「許可」をクリックします。
明示的にアクセスを禁止するには、「拒否」をクリックします。
「OK」をクリックします。
「OK」をクリックし、再度「OK」をクリックして、Identity Managerに戻ります。
このタスクを使用して、特定のアプリケーション・ロールに対して、直接データベース・リクエストの実行を許可または禁止することができます。
選択されたロールでは、物理レイヤー内のデータベース・オブジェクトの「デフォルトで直接データベース・リクエストを許可」プロパティよりも、この権限のほうが優先されます。
「直接データベース・リクエストの実行」フィールドのオプションは次のとおりです。
このデータベースに対する直接データベース・リクエストの実行の許可を明示的に付与します。
このデータベースに対する直接データベース・リクエストの実行を明示的に禁止します。
制限は親アプリケーション・ロールから継承されます。継承される制限がない場合、直接データベース・リクエストは、データベース・オブジェクトの「デフォルトで直接データベース・リクエストを許可」プロパティに基づいて許可または禁止されます。
管理ツール内の問合せ制限機能へのアクセスのステップを実行して、「問合せ制限」タブにアクセスします。
基準ブロックがキャッシュされるときに、移入ストアド・プロシージャはデータベースにキャッシュ/保存済結果セットの値を書き込みます。
特定のアプリケーション・ロールに対して、この移入権限を付与または拒否することができます。
選択されたアプリケーション・ロールでは、物理レイヤー内のデータベース・オブジェクトの「デフォルトで問合せの移入を許可」プロパティよりも、この権限のほうが優先されます。
キャッシュ・エントリを書き込むか、または結果セットを保存するOracle Marketing Segmentationのすべてのユーザーは、対象のデータベースの移入権限が割り当てられたアプリケーション・ロールのメンバーである必要があります。
「移入権限」フィールドのオプションは次のとおりです。
このデータベースに対する移入権限を明示的に付与します。すべてのマーケティング・データ・ウェアハウスに対しては、「許可」を選択します。
このデータベースに対する移入権限を明示的に拒否します。
制限は親アプリケーション・ロールから継承されます。継承される制限がない場合、移入権限は、データベース・オブジェクトの 「デフォルトで問合せの移入を許可」プロパティに基づいて許可または拒否されます。
管理ツール内の問合せ制限機能へのアクセスのステップを実行して、「問合せ制限」タブにアクセスします。
オンライン・モードのOracle BI管理ツールで、データ・アクセス・セキュリティ・タスクを実行する必要があります。
管理ツールはリポジトリにユーザーを格納しないため、リポジトリのユーザーを返す問合せは作成できません。
オンライン・モードでリポジトリを開く場合、Identity Managerで「アクション」を選択して、「アプリケーション・ロールの同期」を選択することで、ポリシー・ストアからアプリケーション・ロールの最新のリストを取得できます。
アプリケーション・ロールは、Oracle WebLogic管理コンソールおよびFusion Middleware Controlを使用して、ポリシー・ストア内に作成し、管理できます。
これらのアプリケーション・ロールはオンライン・モードの管理ツール内に表示されるため、それらを使用して、特定のロールのデータ・フィルタ、オブジェクト権限、問合せ制限を設定できます。ポリシー・ストア内のアプリケーション・ロールは、Oracle BIサーバーの開始時にそのサーバーによって取得されます。
ときには、ポリシー・ストア内にまだ定義されていないアプリケーション・ロールのために、データ・アクセス・セキュリティをリポジトリ内に定義しておきたい場合があります。これを実現するには、管理ツール内にプレースホルダ・アプリケーション・ロールを作成し、それからリポジトリ内へのデータ・アクセス・セキュリティ設定に進みます。
管理ツール内にプレースホルダ・アプリケーション・ロールを作成する場合、最終的にはそれらをポリシー・ストアに追加する必要があります。管理ツール内に定義されているものの、まだポリシー・ストアに追加されていないアプリケーション・ロールを特定するには、整合性チェッカをオンライン・モードで実行します。ポリシー・ストア内のプレースホルダ・ロールは、管理ツール内で使用したのと同じ名前を使用する必要があります。
注意:
プレースホルダ・ロールを定義および使用する際には注意が必要です。ポリシー・ストア内に存在するロールをオフライン・モードで変更した場合、次回にOracle BIサーバーに接続するときにその変更は上書きされます。
管理ツールでリポジトリを開きます。
「管理」→「アイデンティティ」を選択します。
「Identity Manager」ダイアログで、「アクション」、「新規」を選択し、次に「アプリケーション・ロール」を選択します。
「アプリケーション・ロール」ダイアログで、次の情報を入力します。
名前: ロールの名前を指定します。
表示名: ロールの表示名を入力します。
説明: (オプション)このアプリケーション・ロールの説明を入力します。
メンバー: 「追加」ボタンと「削除」ボタンを使用して、該当するユーザーおよび他のアプリケーション・ロールを追加または削除します。
権限: 目的に応じてこのアプリケーション・ロールにオブジェクト権限、データ・フィルタ、および問合せ制限を設定します。詳細は、この章の他の項を参照してください。
「OK」をクリックし、「Identity Manager」ダイアログに戻ります。
「Identity Manager」ダイアログでアプリケーション・ロールを右クリックし、「整合性のチェック」を選択することによって、個々のアプリケーション・ロールをチェックすることもできます。
