はじめに
こんにちは。
本記事はMicroStrategyの権限設計に関する紹介です。
今回は権限のなかでもセキュリティフィルタ（行制御）を
「兼務ユーザ」が利用する場合という観点に絞ってご紹介します。
セキュリティフィルタとは
セキュリティフィルタとは行制御（データ制御）のことです。
以下図を用いてご説明します。
支店がある会社だと仮定し、参照できるデータは自支店のみのデータだとします。
データはA/B/C/D/E支店分のデータがありますが、レポート上ではA支店のユーザが表示できるのはA支店のデータのみ、B支店のユーザが表示できるのはB支店のデータのみ、といったデータ（行）に対する制御となります。
セキュリティフィルタの注意すべき挙動
Microstrategyのセキュリティフィルタは上記のように、各組織に参照させたいデータのみを見せることができますが、「兼務」という複数組織に所属して業務をする場合は設計する際に考慮が必要です。
また図を用いてご説明します。
以下のようにA支店ユーザはAデータのみ参照可能、本社ユーザは全データ参照可な設定とします。では本社とA支店を兼務している場合はどうなるでしょうか？
各プロジェクトの要件によりますが、本社とA支店の兼務であればどちらの権限も保持したうえで業務をする必要があるため、たとえA支店に制御がかかっていようが兼務ユーザは全データ参照可能であるべきです。
以下のようにデータを登録しました。
本社ユーザで実行すると全データ参照可能でSQLにWhere句はかかりません。
A支店ユーザで実行するとA支店データのみ参照可能でWhere句に支店制御が設定されていることがわかります。
では最後に本社とA支店の兼務ユーザを確認します。
本来であれば全データ参照できるはずですがA支店データしか返ってきません。
SQLを見るとA支店のデータ制御のみが設定されていることがわかります。
Microstrategyは複数組織に所属する場合、ユーザにかかるセキュリティフィルタをマージしてレポート実行しにいくので片方が制御なし（全データ参照可）・片方が制御ありだと、制御ありのみが有効となり参照できる範囲が小さくなります。
こちらも図を用いて説明します。
例えばA支店とB支店の兼務ユーザだと制御のマージをした結果、AとBが参照可能となるので、こちらは想定通りです。
ただ片方が制御なし（全データ参照可能）だった場合はマージするセキュリティフィルタがないため、制御ありのみ有効となり、参照できる範囲が小さくなります。この点は盲点になりがちなので、兼務が存在するプロジェクトだとこちらを考慮した要件定義・設計が必要です。
ソリューション
こちらは各プロジェクトの制約等があると思うので、特に推奨案はありません.
1つは全データ参照可能な組織に、全コード値を明示的に設定する方法です。
SQLだと以下のようになり強制的にorで繋がれるような「全データ」を表すセキュリティフィルタを作成する方法です。
こちらはコードの増減がない、または年に数回であれば懸念はないですが、頻繁にコード値の増減があるプロジェクトであればこちらは手メンテ工数がかかり推奨できません。自動化を検討するのも1つですし、NULLがないなら「ISNOTNULL」「Not In 'ダミーデータ'」NULLも含まれる場合は「ISNULLor ISNOTNULL」など。データに問題がないことやパフォーマンスに懸念がないことは各プロジェクトで検討が必要ですが、「全データ」を表すセキュリティフィルタを作成するのが1つの案です。
異なる観点で言うと、本務と兼務でユーザを分けて運用するのも1つの案です（A支店としてMicroStrategyを利用する場合はUserA、本社として利用する場合はUserBを利用するイメージ）。こちらだと1人に対して複数ユーザ払い出すことになるのでセキュリティの観点で確認が必要です。
その制約があるなら、兼務用のユーザグループを作成してしまうのも検討できるかと思います。
さいごに
こちらは設計やテストで盲点になりがちな仕様です。
こちらの記事が、みなさまの調査・業務のお役にたてれば幸いです。