アプリケーション、データベース、ユーザーおよびグループに対して定義されたセキュリティ・レベルが不足している場合は、Essbaseセキュリティ・フィルタによって、より具体的な制御が提供されます。フィルタを使用すると、どういう種類のアクセスが、データベースのどの部分に、これらの設定が適用されるどのユーザーに許可されているかを定義することによって、データベース内の個々のデータへのアクセスを制御できます。
管理者権限がある場合は、任意のユーザーやグループに対して、任意のフィルタを定義して、割り当てられます。これらのフィルタは、自分自身には影響しません。
アプリケーションの作成/削除の権限がある場合は、自分が作成したアプリケーションに対するフィルタの割当ておよび定義が可能です。
アプリケーション・マネージャまたはデータベース・マネージャの権限がある場合は、自分のアプリケーションまたはデータベース内のフィルタを定義および割り当てできます。
フィルタは、データ値(つまりセル)へのセキュリティ・アクセスを制御します。データベースの特定の部分に対するセキュリティのニーズに対応するフィルタを作成します。フィルタを定義する場合は、特定のデータベース・セルに対する制限を指定します。フィルタは保存されるときに、他のフィルタと区別するための一意の名前が付けられ、サーバーによってセキュリティ・ファイルessbase.secに保管されます。その後、Essbaseサーバー上の任意のユーザーまたはグループにそのフィルタを割り当てることができます。
たとえば、利益情報を含むセルへのアクセスを制限するために、マネージャがREDという名前のフィルタを設計し、それをデータベースに関連付けるとします。このフィルタはREVIEWERSという名前の訪問者グループに割り当てられ、これらのユーザーがデータベースの大部分を読み取れるが変更はできず、「利益」データ値にはアクセスできないようにします。
フィルタは、データベース・メンバーに対する1つ以上のアクセス設定で構成されます。次のアクセス・レベルを指定し、それをメンバーのリストから1つのセルまでの範囲のデータに適用できます:
フィルタ定義で指定されていないセルはすべて、データベース・アクセス・レベルを継承します。ただし、よりデータ固有のフィルタ定義は一般的なデータベース・アクセス・レベルより高い詳細レベルを示すため、データベース・レベルで割り当てられたアクセス権をフィルタで追加または削除できます。
フィルタ定義の対象にならないデータ値には、まずユーザーについて定義したアクセス・レベルが適用され、Essbaseがネイティブ・セキュリティ・モードにある場合は、次にグローバルなデータベース・アクセス・レベルが適用されます。
計算アクセス権は、ユーザーおよびグループに付与された権限によって制御されます。データベースに対する計算アクセス権を持つユーザーは、フィルタによってブロックされず、その計算の実行によって更新されるすべてのデータ要素に影響を与えられます。Essbaseがネイティブ・セキュリティ・モードにある場合は、計算アクセス権もまた、アプリケーションまたはデータベースに対する最小限のグローバル権限によって制御されます。
注： | MDX計算済メンバーの計算中に、ユーザーにアクセス権のないセルは#MISSINGセルとして扱われます。 |
データベース値に対して加える必要のある一連のアクセス制限ごとにフィルタを作成できます。同じアクセス・ニーズを持つユーザーに対して、個別のフィルタを作成する必要はありません。フィルタを作成した後、それを複数のユーザーまたはユーザーのグループに割り当てられます。ただし、1人のユーザーまたは1つのグループに割り当てられるフィルタは、1つのデータベースにつき1つのみです。
1組のメンバー(子や子孫など)を戻す計算関数を使用していて、その結果が空集合になる場合は、セキュリティ・フィルタは作成されません。領域定義の結果が空集合になったことを示すエラーがアプリケーション・ログに書き込まれます。 |
制限。にあるフィルタの命名ルールを確認してください。
図144は、データベース・セルへのアクセスを制御するための異なる方法を示しています。データは、メンバー全体にフィルタをかけるか、メンバーの組合せにフィルタをかけることによって保護できます。
1つ以上のメンバーのすべてのデータにフィルタをかけるには、フィルタ・エディタで、各メンバーの独自の行に対するアクセスを定義します。フィルタの別々の行に対するフィルタ定義は、OR関係で処理されます。
たとえば、売上または1月へのアクセスをブロックするために、ユーザーKSmithに次のフィルタが割り当てられているとします:
アクセス: なし。メンバー指定: 売上。
アクセス: なし。メンバー指定: 1月。
次回ユーザーKSmithがSample.Basicにアクセスすると、Qtr1の収益マージンのスプレッドシート表示(図145)では、このユーザーがメンバーSales、メンバーJanのデータ値にアクセスできない、つまり#NOACCESSが付けられていることを示しています。メンバーSalesの内外で、ビューの売上および1月のすべてのデータはブロックされています。売上の兄弟でマージンの子であるCOGS(売上原価)のデータは、1月のCOGSを例外として、アクセスできます。
メンバーの組合せのデータにフィルタをかけるには、フィルタ・エディタで、行を使用してメンバーの各組合せのアクセスを定義します。フィルタ定義で、カンマで区切られた2つのメンバー・セットは、これらの2つのメンバー・セットの結合として処理されます(AND関係)。
たとえば、ユーザーRChinnが次のフィルターに割り当てられているとします: アクセス: なし。メンバー指定: 売上、1月。
次回ユーザーRChinnがSample.Basicにアクセスすると、Qtr1の収益マージンのスプレッドシート表示(図146)では、このユーザーがメンバーSalesとJanの交差でデータ値にアクセスできない、つまり#NoAccessが付けられていることを示しています。ビューの1月の売上データはブロックされています。ただし、他の月の売上データ、および1月の売上以外のデータはアクセス可能です。
代替変数を使用すると、定期的に変更される情報をより容易に管理できます。各代替変数には、割り当てられた名前と値があります。データベース・マネージャは、この値をいつでも変更できます。フィルタで代替変数が指定された場合は、その時点の代替変数の値が使用されます。
たとえば、ユーザーのグループに現在の月のデータのみを表示したい場合は、CurMonthという名前の代替変数を設定し、フィルタ(MonthlyAccess)を定義できます。ここで、メンバー名に&CurMonthを使用してアクセスを指定します。指定の先頭にアンパサンド(&)を使用すると、Essbaseでは、メンバー名ではなく代替変数として識別されます。MonthlyAccessフィルタを該当するユーザーに割り当てます。
毎月、CurMonth代替変数の値を現在の月のメンバー名(1月や2月など)に変更するだけで済みます。この新しい値は、割り当てられているすべてのユーザーに適用されます。
代替変数の使用を参照してください。
フィルタを使用して、特定の属性を共有している基本メンバーのデータへのアクセスを制限できます。属性次元で定義された特定の属性を持つメンバーのデータにフィルタをかけるには、属性メンバーを@ATTRIBUTE関数または@WITHATTR関数と組み合せて使用します。
たとえば、ユーザーPJonesに次のフィルタが割り当てられているとします。アクセス: なし。メンバー指定: @ATTRIBUTE(Caffeinated_False)。
次回ユーザーPJonesがSample.Basicにアクセスすると、カリフォルニアでの第1四半期のコーラの売上のスプレッドシート表示(図147)では、Caffeinated_Falseに関連付けられた基本次元メンバーのデータ値にアクセスできないことを示しています。ビューのカフェインなしのコーラの売上データはブロックされています。カフェインなしのコーラは基本メンバーで、Caffeinated_Falseは属性次元Caffeinatedの関連付けられたメンバー(前述のスプレッドシート表示には表示されない)ことに注意してください。
フィルタを定義した後、それらのフィルタをユーザーまたはグループに割り当てられます。それにより、同じフィルタ設定を必要とする複数のユーザーを管理できます。フィルタの定義への変更は、そのフィルタのユーザーによって自動的に継承されます。
フィルタは、管理者の役割を持つユーザーには影響を与えません。1人のユーザーまたは1つのグループに割り当てられるフィルタは、1つのデータベースにつき1つのみです。
EPM Systemセキュリティ・モードでは、Oracle Hyperion Shared Services Consoleを使用してフィルタを割り当てます。
ユーザーまたはグループにフィルタを割り当てるには、Shared Servicesでのデータベース計算およびフィルタ・アクセスの割当てを参照してください。
フィルタ内に同一のメンバー指定を持つ行が複数含まれている場合には、次のルールが記載順に適用されて、継承されるアクセス権が決定されます:
たとえば、次のフィルタには、オーバーラップの競合が含まれます:
アクセス: 書込み。メンバー指定: 実績。
アクセス: なし。メンバー指定: 実績。
アクセス: 読取り。メンバー指定: 実績、@IDESCENDANTS(New York)。
3番目の指定は、他の2つより高い詳細レベルでセキュリティを定義します。そのため、ニューヨーク支店内のメンバーのすべての実際データに読取りアクセス権が付与されます。
書込みアクセス権は、なしよりアクセス・レベルが高いため、実際内の残りのデータ値には書込みアクセス権が付与されます。
任意の行内の影響を受けるメンバー・セット(メタ読取りメンバーとその祖先)が、他の行のメタ読取りメンバーと重複していない場合のみ、複数行を使用したメタ読取りフィルタを定義する必要があります。複数行に対するメタ読取りを含むフィルタでは、行ごとに1つの次元を指定することをお薦めします。ただし、祖先とメタ読取りメンバーが重複していないかぎり、1つの次元の異なるメンバーを複数のメタ読取り行の中に指定することは有効です。
たとえば、Sample Basicでは、次のフィルタ定義に重複があります:
アクセス: メタ読取り。メンバー指定: California。
アクセス: メタ読取り。メンバー指定: West。
最初の行では、メタ読取りをCaliforniaに適用すると、Californiaにアクセスできるようになりますが、その祖先へのアクセスはブロックされます。そのため、Westに対するメタ読取りは無視されます。このフィルタが割り当てられているユーザーは、Westへアクセスできません。
CaliforniaのみでなくWestにもメタ読取りアクセスを割り当てるには、これらの行を次の1行にまとめます。アクセス: メタ読取り。メンバー指定: California、West。
ユーザーおよびグループのアクセス権の定義がオーバーラップする場合は、次のルールが、記載順に適用されます:
ユーザーフレッドには、次のデータベース・アクセスが定義されています:
FINPLAN R
CAPPLAN W
PRODPLAN N
彼は、グループ・マーケティングに割り当てられており、グループ・マーケティングには、次のデータベース・アクセスが付与されています:
FINPLAN N
CAPPLAN N
PRODPLAN W
FINPLAN R
CAPPLAN W
PRODPLAN W
ユーザー・メアリーには、次のデータベース・アクセスが定義されています:
FINPLAN R
PRODPLAN N
彼女は、グループ・マーケティングに割り当てられており、グループ・マーケティングには、次のデータベース・アクセスが付与されています:
FINPLAN N
PRODPLAN W
FINPLAN R
PRODPLAN W
さらに、メアリーは(データベースFINPLANのための)フィルタ・アーティファクトREDも使用しています。このフィルタには、次の2つのフィルタ行があります:
アクセス: 読取り。メンバー指定: 実績。
アクセス: 書込み。メンバー指定: 予算、@IDESCENDANTS(New York)。
また、グループ・マーケティングは(データベースFINPLANのための)フィルタ・アーティファクトBLUEも使用しています。このフィルタには、次の2つのフィルタ行があります:
アクセス: 読取り。メンバー指定: 実際、売上。
アクセス: 書込み。メンバー指定: 予算、売上。
フィルタのオーバラップから、メアリーの有効な権限と、メアリーおよびメアリーのグループに割り当てられる権限は次のようになります:
R: FINPLANデータベース全体。
W: New Yorkブランチ内のすべての予算データに対して。
W: 予算および売上に関連するデータ値に対して。