この記事は、「NEXTSCAPE Advent Calendar 2020」の4日目です。
Power BI を勉強し始めて1年とすこし経ちますが、まだ使ったことのない機能がたくさんあります。
先日は初めてRLS (Row Level Security：行レベルセキュリティ)を使用した Power BI レポートを作成しました。
1. RLS (Row Level Security：行レベルセキュリティ)とは
Power BI レポートでの、データの閲覧権限を設定することができる機能です。
Power BI Desktop と Service だけで、作成も管理も完結させられるところがいいところかなと思います。
- Power BI Desktopで、タブの「ロール」からRLS専用のフィルターを設定することでロールを作成する
- Power BI Serviceに発行後、設定画面で作成したロールにユーザーを当てる
- Power BI Serviceにログインしたユーザーにロールのフィルターが適用される
2. RLS使用方法について、Qiita記事紹介
RLSの導入検討や実装方法の解説をしてくれているQiita記事がすでにいくつもあります。
私が把握できている記事を勝手に紹介します。大いに学ばせてもらっています。必読！
① Power BIでの行レベルセキュリティを考える (@ryokitaさん)
3種類あるPower BIのデータ接続方式ごとに、RLS導入イメージを解説してくれています。
データ接続方式の違いそのものへのより深い理解も促してくれます。
② Power BI における 行レベルセキュリティ (Row Level Security) (@kenakamuさん)
レポート作成の初めのデータ接続から解説してくれています。とても親切丁寧…
こちらでは、RLSロールを1つ作成するケースが紹介されています。
(userprincipalname()を利用して自分のデータだけを表示する)
③Power BI 勉強帳：行レベルセキュリティ（RLS）(@y-komuroさん)
同じテーブルを使った複数のRSLロールを作成するケースを解説してくれています。
(責任者には自担当の店舗のデータを表示、一般担当には自分のデータだけを表示する)
サンプルデータの社員の名前になごみます。
④Power BI 行レベルセキュリティー (RLS) の応用編 (@neko_daisukiさん)
DAX式でロールフィルターを作成するスマートなやり方を紹介してくれています。
(実は私の実現したかった事はこちらの方法で可能だったのですが思いもつかず、記事を発見したのもレポート作成後でした…)
3. つまづいて自力で調べたこと
Power BI Desktop のリレーションシップ管理画面に、「両方向にセキュリティフィルターを適用する」のチェックボックスがあります。
RLSに関連する項目なのですが、これの取り扱いに苦戦しました。
しかし、その上にある「クロスフィルターの方向」についてもちゃんと学びなおす機会でもありました。
せっかくなので2種類のフィルターそれぞれについて書いた後、苦戦の模様を記します。
3-1. 「クロスフィルターの方向」
レポートのビジュアルで、任意のデータをクリックしたときに他のビジュアルも連動する様子が結構好きなんですが、
その時はこのクロスフィルターが仕事しているんだと思っています。
「クロスフィルターの方向」は、データを絞り込むとき、リレーションシップ上でどちらの方向に働かせるのか設定する項目です。
デフォルトでは、"1"から"多"へ向かうだけの「単一」方向です。
以下の例では、AccountIDによるTransactionテーブルへのクロスフィルターは何の問題もなく動きます。
小さい四角形の中の、白抜きの三角形がフィルターが働く方向を示しています。
(図:Power BI Desktop の双方向クロスフィルター処理のホワイト ペーパーより)
しかし、CustomerIDによるクロスフィルターは届きません。
CustomerAccountテーブルとAccountテーブルが"多対1"なので、そこで流れが途切れるからです。
そこで、CustomerAccountテーブルとAccountテーブルのリレーションシップで「クロスフィルターの方向」を「双方向」に設定すると、
CustomerIDでTransactionテーブルを絞り込めるようになります。
白い三角形が両方向を指しています。
カーディナリティが"1対1"のときは「クロスフィルターの方向」は「双方向」しか選べません。
余談ですが、
ファクトテーブルとディメンションテーブルがちゃんと"多対1"で、「クロスフィルターの方向」も「単一」になっている時に、
ビジュアルでファクトテーブルのデータを触ると、ディメンションテーブルの列を設定しているスライサーがちゃんと連動します。
方向は「単一」なのに、"多"から"1"へのクロスフィルターが動いている…？と謎に思っています。
3-2. 「両方向にセキュリティフィルターを適用する」
RLSを使うときは、まずロールごとに専用のフィルターを作成します。
Power BIの画面ではテーブルフィルターとなってますが、ごちゃごちゃするのでこの記事ではセキュリティフィルターと呼びます。
稼働人員メールアドレステーブルに対して、ログインユーザーのメールアドレスを取得するusername()式でセキュリティフィルターを作り、一般ユーザーロールとしています。
RLSのセキュリティフィルターは、ドキュメントには、
既定では、リレーションシップが一方向と双方向のいずれに設定されているかに関係なく、行レベルのセキュリティ フィルターで一方向のフィルターが使用されるとあります。
つまり、RLSのセキュリティフィルターを"多"から"1"の方向で利かせたいと思っても、
「クロスフィルターの方向」を「双方向」にするだけでは実現できないので、
そういうケースでは「両方向にセキュリティフィルターを適用する」 をオンにしてね、ということかなと考えています。
3-3.「両方向にセキュリティ フィルターを適用する」の制限事項
「両方向にセキュリティ フィルターを適用する」をよくわからないまま、便利だからと使おうとしていた自分が悪いのですが、怒られが多発してしまいました。
ドキュメントには書いてないように見受けられるので、記しておきます。
① あるテーブルにセキュリティフィルターを置くと、そのテーブルのリレーションシップでは「両方向にセキュリティフィルターを適用する」をオンにすることはできない。
②「両方向にセキュリティフィルターを適用する」をオンにできるのは、1つのテーブルについて1リレーションシップだけ。
① 両方向のセキュリティフィルターが適用されているRLSロールは単独で使う必要がある(ほかのRLSロールと同時に有効にはできない。)
制限事項への対策・対応は…？
それぞれのエラーが出る意味を理解するところまでたどり着けていません…
(つまり結局は両方向のセキュリティフィルターがなんたるかわかっていない…)
このときは消極的ですが「両方向にセキュリティフィルターを適用する」をなるべく利用しないという作戦をとりました。
モデリングから修正して、なんとかRLSを実装させることができました。
4. ただしがき
今回の記事は、インポートモードで作成したレポートでのお話です。
「両方向にセキュリティフィルターを適用する」は、DirectQueryを使った場合の記述がドキュメントにありますが、カバーできていないです。
サーバー レベルで、動的な行レベルのセキュリティも実装した場合 (行レベルのセキュリティはユーザー名またはログイン ID に基づく) は、このボックスをオンにする必要があります。
詳細については、「Power BI Desktop での DirectQuery を使用する双方向のクロス フィルタリング」と「表形式の BI セマンティック モデルの保護」の技術記事を参照してください。
5. あとがき
先達の皆さんが記してくださる情報にいつも助けてもらっているので、思い切って苦手なアウトプットに挑んでみましたが…
読みづらく、後半に行くほどとりこぼしが目立つ記事になってしまい、悶えています。精進致します。
間違いのご指摘など、コメントいただけると幸甚に存じます…！
目を通してくださってありがとうございました！
明日は、@zt_meganeさんです！よろしくお願いします！