ネイティブ SQL および MDX の安全な使用
更新 : 2009-04-30
Planning Server には、計算ルールを簡単に指定できる言語が用意されています。計算ルールを使用して、モデルへのデータの入力、モデル内またはモデル間でのデータの移動、既存データからの新しい値の計算などの機能を実行できます。モデル管理者ロールのメンバは、Planning Business Modeler を使用して 2 とおりの方法で計算ルールを実行できます。最初の方法では、ジョブの一部としてルールを実行し、ビジネス ユーザーに対してジョブをスケジュールするか、割り当てます。2 番目の方法では、データを変更するとシステムによってルールが自動的に実行されるようにします。モデル管理者のメンバは、Microsoft SQL Server 2005 または MDX で実行を指定することもできます。Microsoft SQL Server 2005 と MDX は、それぞれ機能とパフォーマンスにおいて利点と欠点があります。
状況によっては、上級ユーザーにとって PerformancePoint 記述言語 (PEL) は制約が多すぎる場合があります。特に該当する状況として、SQL Server または MDX に習熟したユーザーが、パフォーマンスのためにストアド プロシージャを拡張したり、非公開の SQL Server ビルトイン関数を使用したり、PEL で対応していない処理を行ったりすることを希望する場合があります。ルールのインフラストラクチャの便利さに加えて、PEL が提供する生の SQL Server または MDX の機能によって、さまざまな形式での実行が可能です。
これを実現するために、PEL は NativeSql および NativeMdxScript と呼ばれる新しいルールを実装して公開しています。ただし、これらの新しい実装によって、セキュリティ上のリスクが生じる可能性があります。1 つのモデル サイトのみへのアクセス権を持つユーザーが、アプリケーション全体の複数のモデル サイトに大幅な変更を加えることが可能になります。具体的には、Planning Server はこれらのルールを分析できません。これらのルールは SQL または MDX で記述されており、Planning Server で簡単に解析することはできません。そのため、ルールの新しい実装をサービス ID として実行する必要があります。サービス ID には、アプリケーション データベースを格納している SQL Server コンピュータに対するデータベース所有者のアクセス権限が必あります。その結果、モデル管理者ロールの悪意のあるメンバは、アプリケーション内のあらゆる場所でデータを変更できるようになり、テーブルの削除や監査証跡の変更などの多数の操作を実行できるようになります。
このリスクを軽減するには、2 つのオプションがあります。1 つは承認システムを使用する方法、もう 1 つはすべてのルールを低特権ユーザーとして実行する方法です (後者については別のドキュメントで説明しています)。
サンプル
承認システムを使用してネイティブ ルールを作成および実行する方法を次の手順に示します。
Planning 管理コンソールで、グローバル管理者ロールのメンバが [ネイティブの SQL/MDX ルールの有効化] チェック ボックスをオンにする必要があります。この操作によって、対応するフラグが "True" に設定されます。このフラグは、アプリケーション オブジェクトにブール値として格納されます。アプリケーション レベルの EditMetadata 権限を持つユーザーには、このフラグを変更するアクセス権があります。標準ルールに対してこの手順を実行する必要はありません。
Planning Business Modeler で、モデル管理者ロールのメンバが生のルールを記述し、そのルールを非アクティブ状態で保存する必要があります。Planning Server では、ルールを編集した内容を保存する場合 (標準ルールに対する編集を含む)、ルールを保存するモデルのコンテキストで EditRules という操作の種類がチェックされます。さらに、生のルールの場合は、アプリケーションの [ネイティブの SQL/MDX ルールの有効化] フラグが有効 (チェック ボックスがオン) になっているかどうか、および各ネイティブ ルールが非アクティブであるかどうかがチェックされます。非アクティブに設定されたルールをデータベースまたは OLAP キューブに展開して実行することはできません。
SQL Server データベースで、データベース管理者がルールの "IsActive" フラグを true に設定して、ルールを承認する必要があります。このフラグは、RuleSetsOrRules テーブルの IsActivated 列に保存されます。このテーブルへのアクセスは、標準の SQL 権限に従って制御されます。標準ルールに対してこの手順を実行する必要はありません。
モデル管理者ロールのメンバが、ルールを含むモデルを展開する必要があります。この手順は、標準ルールに対しても実行する必要があります。モデルを展開する際には、展開するモデルのスコープ内で GenerateApplication の操作の種類が Planning Server によって必ずチェックされます。さらに、生のルールの場合は、アプリケーションの [ネイティブの SQL/MDX ルールの有効化] フラグが有効であるかどうかがチェックされます。このフラグが "非アクティブ" に設定されている場合、標準ルールおよびネイティブ ルールはどちらも展開されません。
モデル管理者ロールのメンバは、標準の実行パスを使用してネイティブ ルールを実行できるようになりました。Planning Business Modeler で直接実行する場合、モデルのコンテキストで ExecuteRule の操作の種類がチェックされます。モデル管理者のメンバがジョブを作成し、ユーザーに対してジョブをスケジュールまたは割り当てる場合、モデルが属するモデル サイトのスコープで ManageWorkflow の操作の種類がチェックされます。システムによって実行されるようにルールを設定した場合 (ルールの作成時に設定しておく必要がある)、その他の操作の種類はチェックされません。ここでの標準のチェック (すべてのルールに適用されるチェック) に加えて、いずれかのコード パスからネイティブ ルールが実行されると、[ネイティブの SQL/MDX ルールの有効化] フラグが追加でチェックされます。このフラグが "false" の場合、実行は失敗します。
ネイティブ ルールに変更を加えた場合は、手順 2 で説明したように非アクティブ状態で保存する必要があります。再度ルールを承認するには、手順 3 および 4 を繰り返す必要があります。これによって、すべてのネイティブ ルールに対して承認プロセスが発生することになります。グローバル管理者のメンバが、Planning アプリケーションにネイティブ ルールが必要ないと判断する場合もあります。その場合、[ネイティブの SQL/MDX ルールの有効化] フラグを常に無効にしておくという選択肢があります。既定では、このフラグは False に設定されています。このフラグが True に設定されている場合でも、すべてのルールはモデル管理者ロールのメンバによって作成され、データベース管理者によって承認される必要があります。その結果、ルールを有効にする前に使用するレビュー システムの構築が可能となります。また、グロバール管理者のメンバは、システムに生のルールが不要になったと判断した場合は、[ネイティブの SQL/MDX ルールの有効化] フラグを無効にすることもできます。フラグを無効にした場合、ネイティブ ルールの作成、更新、展開、実行はできません。ネイティブ ルールの削除のみが可能になります。