【Power BI】動的な行レベルセキュリティ(RLS)の設定

# はじめに
こんにちは。ATLシステムズの樋口です。

Power BIで作成したレポートを組織内で公開する際、「この人には●●のデータしか見せないようにしたい」「ユーザの所属組織ごとに絞り込んだデータを見せたい」といったアクセスの管理を行いたいケースがあるかと思います。

今回は、その方法についてご説明します。

# 行レベルセキュリティの設定
Power BIで作成したレポートのアクセス管理を行う機能として、「行レベルセキュリティ」を設定する方法があります。

**Power BI での行レベルのセキュリティ (RLS)**
https://learn.microsoft.com/ja-jp/power-bi/enterprise/service-admin-rls


手順も簡単です。
1. Power BI Desktopにロールを作成
1. Power BI サービスに発行
1. Power BI サービスでロールに対しユーザーを紐付け



この機能により簡単にデータへのアクセス制御を行うことができます。

しかし、残念ながら2023年3月末時点では、Power ShellやAPIを使用したロールの一括作成の機能はありません。

例えば組織改正により **ロール(アクセス管理をしたいユーザのグループ)を大量に作成する**ことが必要になったとします。
この場合、Power BI Desktopをポチポチと操作し続ける必要があります。



大量の…例えば、**100個の組織ごとに閲覧範囲の制御をする**ことになった場合。
まずPower BI Desktopを操作し**100個のロールを手動で作成**し、
次にPower BI サービスで**100個のロールに対しそれぞれユーザを追加する**わけですね。

あまり現実的ではないし、やりたいとは思えません…。

そんな時は、ロールとユーザの紐付けをレポート自身にデータで持たせることにより、作成するロールは1つだけで同等のアクセス管理を行うことが可能です。

# 動的な行レベルセキュリティの設定

こんなデータを用意してみます。

**【検証_分析用データ】**
チームごとにデータを管理しています。このデータを使用してレポートを作成するイメージ。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3305633/8813a711-be20-18e6-eefe-af9e460375d3.png)


**【検証_ユーザ】**
『team』が行レベルセキュリティでいう『ロール』。
それに紐付くユーザの管理を行うためのデータです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3305633/fbcd30f9-a28e-8312-7553-791a14f0566b.png)


上記のデータを用いて、『teamAに所属するユーザは、分析用データのteamA部分だけを閲覧可能』とする設定を行います。

ロールとユーザの一覧データさえ作ってしまえば、こちらも手順は簡単です。
1. モデルビューで「チーム」をもとにリレーションシップを設定します。今回は多対多です。
この際、【検証_ユーザ】は公開したくありませんので、非表示にしておきます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3305633/b8ffff93-b1e8-984a-ee27-1d782d5a876a.png)


1. レポートを作成します。(サンプルなのでテーブルでデータを表示しただけです)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3305633/77e99bed-28bc-e42b-1858-325e253273a8.png)


1. リボンの[モデリング]から、[ロールの管理]をクリックします。
今回は【検証_ユーザ】の『e-mail』が**Power BI サービスにサインインしているアカウント**と一致する場合、【検証_分析用データ】を所属するチームのデータに絞り込んで表示するように設定します。
式は`[e-mail] = USERPRINCIPALNAME()`としました。
※DAX：USERPRINCIPALNAME
https://learn.microsoft.com/ja-jp/dax/userprincipalname-function-dax
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3305633/7ed3881c-d5d2-03a1-ff40-68a08693b4f0.png)


1. [表示方法]を使って想定通りの動きをするか等検証します。
「その他ユーザー」にチェックボックスを入れ、【検証_ユーザ】にあるe-mailの情報を入力します。
「ロール名(今回はpermissions)」にも忘れずにチェックを入れてください。
**TESTaccountB**のユーザが見た場合、想定通り表示できるかを確認してみます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3305633/3b678c38-c952-e6ec-b928-98e0cc2e2219.png)
【検証_ユーザ】では**TESTaccountB**をteamA所属のユーザとして管理しています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3305633/3a26e77a-9fe8-5dc3-350e-a4ac033dc027.png)
上手く絞り込まれた状態で表示されました。大丈夫そうですね。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3305633/ce9ed31e-b19c-f4bb-2e11-d3b35652e82b.png)

1. 任意のワークスペースにレポートを発行します。
ここまででPower BI Desktopによる操作は終了です。

---
次は、Power BI サービスで設定を行います。
1. 発行した「データセット」に対し行レベルのセキュリティを設定します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3305633/ff0dcf2f-1d2d-b70c-c6dc-433b78af7e2f.png)

1. **レポートにアクセス可能なすべてのユーザ**を登録します。
今回であれば【検証_ユーザ】の『e-mail』すべてを設定するイメージです。
ここに追加されないユーザは、レポートにアクセスしても閲覧不可となります。
Azure ADでグループを作成しておくと簡単です。(グループはファイル取り込みによるユーザの一括登録が可能なので)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3305633/08a5be58-9089-9621-3207-d6c2bafa74f7.png)


---

これですべての設定は完了しました。
レポートを公開したユーザ(編集権限あり)では全データ表示されますが…
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3305633/0e753fdc-3852-5bec-6cbd-338c703071af.png)


**TESTaccountB**のアカウントでレポートを参照すると、teamAのデータに絞り込んだレポートが表示されています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3305633/b4c3b03a-9659-040d-7c57-48a2e52b456a.png)



今回はレポートをマイワークスペースに発行し、『共有』から『特定のユーザー』を指定しURLを発行しました。
そのため、**TESTaccountB**はレポートに対し読み取りアクセスしかできない状態です。

**もし編集の権限を持つ場合は、行レベルセキュリティの設定を行っていても編集可能となるため注意が必要です。**


# おわりに
- 行レベルセキュリティの設定は簡単に実装可能です。
- ロールを大量作成しなければいけない際などは、ロールだけでなくデータ側で管理を行う方法が有効です。
  - ただし、運用時に設定を変更する個所が増えるので注意も必要です。
  - ユーザの追加・削除が発生した場合は2か所の設定変更をしなければいけません。
    - Power BI サービスから[セキュリティ]の設定変更を行う
    - レポート側のデータ(今回の【検証_ユーザ】)を編集する

まずは自分に必要な要件を確認し、そこから適切な設定・運用方法を選択することで、より利活用の幅が広がると思います。
本記事が参考になりましたら幸いです。