本記事の目的
Data Driven経営を実現するセルフサービスBI
Power BIは（IT部門に限らず）組織内の全てのユーザの利用を想定した「セルフサービスBI」という位置付けにある。実際に組織内でIT部門だけで利用しているケースは少なく、現場のユーザが先頭に立って利用していることがほとんどだと思う。
Power BIをはじめとしたセルフサービスBIは、現場のニーズに合ったデータ可視化を高速に行うことができることもあり、Data Driven経営を実現するためのDXの本命と言っても良いかもしれない。
データセキュリティを放任し続けるリスク
一方、全てのユーザが気軽にレポートを作成し共有することができるようになるにしたがって、問題視されるのがデータセキュリティや権限管理だ。
万一、Power BI経由でセキュリティインシデントが起きた場合、実際には運用が不味かっただけだとしても、周りから見れば製品自体が悪いという印象になる可能性がある。
もしマネジメント陣に対して「セルフサービスBIはセキュリティに問題がある」といった印象（誤解）を与えてしまえば、その後の組織展開に甚大な悪影響が出る。
少数のユーザで草の根的に使い始めたときはデータセキュリティの話は（チーム内の運用でカバーできるため）後回しにされがちだが、利用ユーザ数と管理レポート数が増えてくるにしたがって仕組みを考えていく必要がある。
データセキュリティ管理の仕組みを考える
以上を踏まえ、以降はデータセキュリティ管理の仕組みについて考えていきたい。
結論だけ先に書くと
- データセキュリティ管理を誰が行うか、複数シナリオがあることを整理する
- シナリオ1. 各現場のレポート作成者が、レポートに対して個別にデータセキュリティを実装する
- シナリオ2. レポート作成者とは異なるデータ管理者が、まとめてデータセキュリティを実装する
- 組織的にガバナンスを利かせるなら、部分的にでもシナリオ2を取り入れるのが良さそう
- そのためにはDirect QueryやSSOの仕組みが必要となるが、以前はLAN環境内のデータソースには適用不可だった
- 2020年10月のOn-Premise Data Gatewayのバージョンアップにより、LAN環境内へのDirectQuery(SSO)が可能になったことでシナリオ2も現実的なものとなった
データセキュリティ管理を誰が行うか
シナリオ1: レポート作成者がデータセキュリティを管理する
データを持つ各現場のレポート作成者が、アクセスを許可したユーザに対してレポートを公開する。データを「本来見せてはいけない人に見せない」ために、レポートにアクセスできる人を管理/制限する責任は、レポートの作成者が持つ。
セルフサービスBIの性質を考えると、こちらが現場で多く使われている形かと思う。
アクセス権限の制御方法としては、具体的には2つの方法の組み合わせになる。
（※ Connection TypeはImport Modeを想定）
A. レポート単位の権限制御
レポート単位での権限制御を行う。レポートの作成者がワークスペースの管理者となり、ワークスペースまたはアプリに対するアクセス権限を設定する。
B. データレベル単位の権限制御
レポート単位より細かいデータ単位の制御が必要な場合、行レベルセキュリティを使う。手順としては「Power BI desktop上でロールの作成とテーブルフィルターの定義を行う」⇒「Power BI Service上でロールへのユーザの割当を行う」。
Power BI での行レベルのセキュリティ (RLS)
https://docs.microsoft.com/ja-jp/power-bi/admin/service-admin-rls
シナリオ2: データセキュリティを管理する「データ管理者」を立てる
レポートを作成するユーザと、データのセキュリティ管理者を分離する。この場合は、レポートにアクセスできる人を管理/制限する責任はデータ管理者が持ち、レポート作成者はあくまでレポートを作成することに専念できる。
シナリオ1の権限制御はそれぞれのレポートに対して個別に設定をする必要があるので、レポート作成者にとっては面倒に感じられる。また設定のミスがセキュリティインシデントにつながる可能性を考えると、慎重に設定をする必要がある。
シナリオ2はこの面倒な権限管理の部分を切り出して「データ管理者」に担ってもらい、かつ各レポート単位ではなく大元のデータソース側で管理しようという発想だ。具体的には、全社で利活用するデータは一箇所のデータ基盤（Data Warehouse）に集めて、アクセス権限制御は全てこのデータ基盤側でやってしまう、ということになる。
データ管理者によるデータセキュリティ
データ管理者を立てて（中央集権的に）データセキュリティを実現する方法を少し具体的に議論する。
いま実現したいのは「データの権限管理は全てデータ管理者側でやってくれるから、レポート作成者やレポート閲覧者は通常データ権限について意識しない」という状態である。
DirectQueryとシングル サインオン(SSO)
権限制御の設定は大元のデータソース側でしておき、レポート作成者やレポート閲覧者はその権限制御に従う、という仕組みを実現するためには、「Direct Query Mode」というConnection Typeを使う必要がある。
更に、ユーザの認可情報を渡して「アクセスしてきたユーザが誰か」を自動的に判別する必要があるが、これはOAuthという権限認可の仕組みで実現できる。
DirectQueryはレポートが読み込まれるたびにデータをデータソース側まで取りに行くもので、ここにOAuth認証を使ったSSOの仕組みを入れることによって、そのユーザが本来見えるべきデータだけを渡すことができる。
Direct Queryソースのシングル サインオン(SSO)
https://docs.microsoft.com/ja-jp/power-bi/connect-data/power-bi-data-sources#single-sign-on-sso-for-directquery-sources
Azure SQL Database と DirectQuery
https://docs.microsoft.com/ja-jp/power-bi/connect-data/service-azure-sql-database-with-direct-connect
SSO オプションが有効になっている場合、データ ソースを基に作成されたレポートにユーザーがアクセスすると、Power BI によって Azure SQL Database または Data Warehouse へのクエリで、認証済みの Azure AD 資格情報が送信されます。 このオプションを使用すると、Power BI で、データ ソース レベルで構成されているセキュリティ設定を適用できます。
ここまでで一応、目指していた状態は実現できたが、実際にはここで問題に直面した。
それはデータソースであるデータ基盤（Data Warehouse）はインターネットから隔離されたオンプレやPrivate Linkでつながった内部環境にある場合が多いことによるものである。この場合、一つ別の仕組みが必要になる。
On-premise Data Gateway (2020年9月まで)
Power BI Serviceから、インターネット上で晒されていないプライベートな環境内にあるデータソースに接続するためには、On-premise Data Gatewayという踏み台サーバが必要となる。
ただしこれまでのOn-premise Data Gatewayでは、DirectQueryでSSOを使うことができないという制約があった。つまりデータソースがインターネットに公開されていない限り、先ほど議論した「データ管理者を立てた中央集権的なデータセキュリティ」は実現できなかった。
On-premise Data Gateway (October 2020 update)
状況が変わったのが2020年10月のアップデート。ついに、DirectQuery(SSO)がOn-premise Data Gatewayで利用可能になった。
On-premises data gateway October 2020 update is now available
https://powerbi.microsoft.com/ja-jp/blog/on-premises-data-gateway-october-2020-update-is-now-available/
We enabled OAuth via the On-premises data gateway for SQL Server and Kusto connectors in July. This feature was only enabled for Import and not DirectQuery for SQL. **With this version we have enabled DirectQuery as well. **Additionally, many other connectors can now use OAuth via the gateway as well.
ということでついに、社内LAN内のプライベート環境に置いてあるデータソースに対してもDirectQuery×OAuth(SSO)で接続できるようになった。これで（データ管理者がデータソース側で権限設定することによって）レポートの作成者が権限について気にせずに済む状況をつくれるようになった。
終わりに
Microsoftの公式Document等を見て勉強した内容に基づいて執筆していますが、誤り等がありましたら是非ご指摘下さい。Live Connectionについてや、Direct Queryが持つパフォーマンスの問題や一部の機能制限（DAX）についてなどは理解不足なこともあり触れておらず、不十分な点も多々あるかと思います。お気づきの点などあればご指摘いただけると嬉しいです。