Power BI 実装計画: レポート コンシューマーのセキュリティ計画

このセキュリティ計画の記事では、読み取り専用コンシューマーのための戦略について説明します。 レポートとアプリに対する閲覧者アクセス許可と、データ セキュリティの適用方法に焦点を当てます。 主な対象者は次のとおりです。

• Power BI 管理者: 組織の Power BI 監視を担当する管理者。
• センター オブ エクセレンス、IT、BI チーム: Power BI の監視も担当するチーム。 これらのチームは、Power BI 管理者、情報セキュリティ チーム、その他の関連チームと共同で作業することが必要な場合があります。
• コンテンツの作成者と所有者: 他のユーザーに使用してもらうコンテンツを作成し、発行し、セキュリティ保護し、管理する必要があるセルフサービス BI 作成者。

一連の記事は、Power BI セキュリティに関するホワイト ペーパーの内容を拡張することを目的としています。 Power BI セキュリティ ホワイト ペーパーでは、認証、データ所在地、ネットワーク分離などの主要な技術トピックに焦点を当てていますが、このシリーズの主な目標は、セキュリティとプライバシーの計画に役立つ考慮事項と決定事項を提供することです。

組織内の多くのユーザーが "コンシューマー" に分類されます。 コンシューマーは、他のユーザーによって作成されて公開されたコンテンツを閲覧します。 コンシューマーがこの記事の焦点です。 コンテンツの作成者と所有者に焦点を当てたセキュリティ計画については、コンテンツ作成者のセキュリティ計画の記事を参照してください。

この記事を最大限に活用するために、Power BI のコンテキストでの "共有" と "配布" という用語の意味を理解しておくとよいでしょう。

"共有" とは、1 人のユーザーが別のユーザー (または一群のユーザー) に特定のコンテンツ アイテムへのアクセスを許可することです。 Power BI サービスでの共有機能のスコープは 1 アイテムです。 一般的には、互いを知っていて密接に連携して作業している個人の間で行われます。

"配布" とは、コンテンツを他のユーザー (受信者と呼ばれます) に届けることです。 多くの場合は、複数のチームの多数のユーザーが関与します。 受信者はそのコンテンツを明示的に要求していない場合もありますが、役割を遂行するのにコンテンツが必要であると認識されています。 配布されたコンテンツを使用する受信者は、コンテンツの元の作成者を知っている場合も、知らない場合もあります。 そのため、概念としての配布は共有よりも公式性が強いといえます。

他の人々と話すときは、その人が "共有" という用語を一般的な意味で使っているか、文字どおりの意味で使っているかを判断してください。 "共有" という用語の使用は、2 とおりに解釈できます。

• "共有" という用語は、同僚とのコンテンツ共有に関連する一般的な意味で使用されることがよくあります。 読み取り専用コンテンツを届けるには多数の手法があり、これらについてこの記事で説明します。
• "共有" は、Power BI の特定の機能でもあります。 この機能によって、ユーザーまたはグループに 1 つのアイテムへのアクセスが許可されます。 共有リンクと直接アクセス共有について、この記事で説明します。

読み取り専用コンシューマーに関する戦略

Power BI サービスで、コンシューマーがレポートやダッシュボードを閲覧できるのは次の両方のアクセス許可が付与されているときです。

• 視覚化が含まれている Power BI アイテム (レポートやダッシュボードなど) を閲覧する。
• 基になるデータ (以前はデータセットと呼ばれていたセマンティック モデル、またはその他のソース) を読み取ります。

さまざまな手法を使用して、コンシューマーに読み取り専用アクセスを提供できます。 セルフサービス コンテンツ作成者に使用されている一般的な手法は次のとおりです。

• ユーザーとグループに Power BI アプリへのアクセス権を付与する。
• ユーザーとグループを Power BI ワークスペース閲覧者ロールに追加する。
• 共有リンクを使用してアイテムごとのアクセス許可をユーザーとグループに提供する。
• 直接アクセスを使用してアイテムごとのアクセス許可をユーザーとグループに提供する。

Power BI アプリによる方法、および Power BI ワークスペース閲覧者ロールによる方法では、一連のアイテムに対するアクセス許可の管理が行われます。 2 つのアイテムごとのアクセス許可の手法では、1 つの個別アイテムに対するアクセス許可の管理が行われます。

アイテムのセキュリティ設定をレビューすると、そのアクセス許可が次のいずれかであることがわかります。

• ワークスペースまたはアプリから継承されている。
• アイテムに直接適用されている。

次のスクリーンショットでは、あるレポートに対する "直接アクセス" のアクセス許可が表示されています。 この例では、ワークスペースの管理者とメンバーのロールがそれぞれ 1 つのグループに割り当てられています。 これらのロールがこのレポートに対して表示されているのは、レポート レベルのアクセス権がワークスペースから継承されているからです。 また、レポートに直接適用された "読み取り" アクセス許可を持つユーザーが 1 人います。

読み取り専用コンシューマーに対して選択する戦略は、それぞれ異なる場合があります。 それは、個々のソリューション、ソリューションを管理するユーザーの基本設定、またはコンシューマーのニーズに基づいている必要があります。 このセクションの残りの部分では、使用可能な手法のそれぞれについて、どのようなときに使用を検討するかを説明します。

チェックリスト - 読み取り専用コンシューマーにコンテンツを提供する方法の戦略を作成するときの、主な決定事項とアクションは次のとおりです。

Power BI アプリのアクセス許可

Power BI アプリによって、レポート、ダッシュボード、ブックのコレクションがコンシューマーに届けられます。 アプリではコンシューマーに最高のユーザー エクスペリエンスが提供されますが、それは次のような理由からです。

• アプリのナビゲーション ウィンドウによって、シンプルで直感的なユーザー エクスペリエンスが提供されます。 ワークスペース内のコンテンツに直接アクセスするよりもエクスペリエンスは優れています。
• アプリのナビゲーション ウィンドウの中でコンテンツを論理的にセクションにまとめることができます (フォルダーに似ています)。
• コンシューマーは、アプリの対象ユーザー用に明示的にアプリに含まれている、特定のアイテムにのみアクセスできます。
• 追加の情報、ドキュメント、またはその他のコンテンツへのリンクをその対象ユーザー用にナビゲーション ウィンドウに追加できます。
• "アクセス権の要求" ワークフローが組み込まれています。

ワークスペース コンテンツの一部またはすべてを配布する公式の方法として、ワークスペースごとに 1 つのアプリを作成できます。 アプリは、コンテンツを 1 つの組織内で幅広く配布するための優れた方法です。特に、自分が知らないユーザーや密接な共同作業をしていないユーザーに配布する場合です。

アプリのアクセス許可は、ワークスペース ロールとは別に管理します。 このアクセス許可の分離には、2 つの利点があります。 次のことが促進されます。

• ワークスペース アクセス権をコンテンツ作成者に付与する。 これには、コンテンツでの共同作業を積極的に行っているユーザー (セマンティック モデル作成者、レポート作成者、テスト担当者など) が含まれます。
• アプリのアクセス許可をコンシューマーに付与する。 ワークスペースのアクセス許可とは異なり、アプリのアクセス許可は常に読み取り専用 (またはなし) です。

ワークスペース アクセス権を持つすべてのユーザーは、自動的にアプリの閲覧が可能になります (そのワークスペースに対して Power BI アプリが公開されている場合)。 この動作があるため、概念的には、ワークスペース ロールはアプリの対象ユーザーそれぞれによって "継承される" と考えることができます。 ワークスペース アクセス権を持つユーザーの一部は、割り当てられたワークスペース役割に応じて、Power BI アプリを更新することもできます。

読み取り専用コンシューマーにコンテンツを配布する方法としてアプリの使用が最善の選択肢となるのは、次のときです。

• その対象ユーザーから可視である、特定のアイテムのみをユーザーが閲覧できるようにする必要がある (基になるワークスペース内のすべてのアイテムではなく)。
• アプリの読み取り専用アクセス許可を、ワークスペースとは別に管理する必要がある。
• 読み取り専用ユーザーに関して、アイテムごとのアクセス許可よりもシンプルなアクセス許可管理を必要としている。
• コンシューマーに対して行レベルのセキュリティが確実に適用されるようにする必要がある (基になるセマンティック モデルに対する読み取り専用アクセス許可が付与されているとき)。
• 新規や変更済みのレポートは、アプリが再発行されるまでコンシューマーが閲覧できないようにする必要がある。

レポートとダッシュボードに対する変更は、アプリが再発行されるまでアプリのユーザーからは見えないことは事実ですが、注意が必要な考慮事項が 2 つあります。

• 即時セマンティック モデルの変更: セマンティック モデルの変更は常に直ちに有効になります。 たとえば、ワークスペース内のセマンティック モデルに重大な変更を加えた場合に、その結果として、意図せずレポートが不安定になる可能性があります (まだアプリで再発行されていない場合でも)。 このリスクを軽減するには、2 つの方法があります。1 つは、すべての開発作業を Power BI Desktop で行うことです (ワークスペースから切り離す)。 2 つ目は、開発およびテスト用に別のワークスペースを使用するという方法で運用アプリを隔離することです。 (必要に応じて、開発からテストと運用までのワークスペース コンテンツのデプロイについて、より高いレベルの制御をデプロイ パイプラインを使用して達成できます。)
• コンテンツとアクセス許可は一緒に発行される: アプリを発行すると、そのアクセス許可がコンテンツと同時に発行されます。 たとえば、ワークスペースのレポートの変更が、まだ完了していない、完全にテストされていない、あるいは承認されていない場合があります。 そのため、アクセス許可を更新するためだけにアプリを再発行することはできません。 このリスクを軽減するには、アプリのアクセス許可をセキュリティ グループに割り当てて、アプリのアクセス許可を付与するときにセキュリティ グループ メンバーシップ (個々のユーザーではなく) を使用します。 アクセス許可の変更を適用するためだけにアプリを再発行することは避けてください。

アプリの対象ユーザー

Power BI サービス内の各ワークスペースが持つことができる Power BI アプリは 1 つだけです。 ただし、アプリの中では 1 つ以上の対象ユーザーを作成できます。 次のシナリオについて考えてみます。

• 5 つのセールス レポートがあり、これらはあなたのグローバル セールス組織全体の多数のユーザーに配布されます。
• アプリ内で、セールス担当者を表す対象ユーザーが 1 つ定義されています。 この対象ユーザーは、5 つのレポートのうち 3 つを閲覧できます。
• アプリ内で、セールス リーダーシップ チームを表す別の対象ユーザーが定義されています。 この対象ユーザーは 5 つのレポートをすべて閲覧でき、これにはセールス担当者が利用できない 2 つのレポートも含まれています。

このような、コンテンツと対象ユーザーの自由な組み合わせができることには、次の利点があります。

• 特定のレポートを、複数の対象ユーザーによる閲覧用に提供することができます。 したがって、複数の対象ユーザーを作成すれば、コンテンツをさまざまなワークスペースに複製する必要がなくなります。
• 特定のレポートは、1 つの対象ユーザーのみに提供することができます。 したがって、その 1 つの対象ユーザーのためのコンテンツを、他の関連コンテンツと同じワークスペースに存在させることができます。

次のスクリーンショットは、セールス リーダーシップ (Sales Leadership) とセールス担当者 (Sales Reps) という 2 つの対象ユーザーを持つアプリを示しています。 [対象ユーザー アクセスの管理] ウィンドウで、セールス リーダーシップ (Sales Leadership) という対象ユーザーへのアクセスがセールス リーダーシップ - 北米 (Sales Leadership-North America) とセールス リーダーシップ - ヨーロッパ (Sales Leadership-Europe) の 2 つのセキュリティ グループに提供されています。 セールス リーダーシップという対象ユーザー グループのスクリーンショットに表示されている粗利分析 (Gross Margin Analysis) というレポートは、セールス担当者という対象ユーザー グループが見ることはできません。

アプリのアクセス許可を管理するときは、[直接アクセス] ページで各対象ユーザーのメンバーを見ることができます。 また、ワークスペース ロールを持つユーザーの一覧を "すべて" という対象ユーザーの下で見ることもできます。 [直接アクセス] ページからアプリのアクセス許可を更新することはできません。 代わりに、アプリを再発行する必要があります。 ただし、アプリに対する未処理のアクセス権要求があるときは、[保留中] ページからアプリのアクセス許可を更新できます。

アプリのアクセス許可のオプション

アプリを作成 (または再発行) するときに、対象ユーザーごとに [対象ユーザー アクセスの管理] ウィンドウがあります。 このウィンドウでは、次のアクセス許可を使用できます。

• アクセス権を付与する相手: 対象ユーザーごとに、個々のユーザーとグループにアクセス権を付与できます。 [Publish apps to the entire organization] (アプリを組織全体に発行する) テナント設定によって有効になっている場合は、アプリを組織全体に発行できますが、アプリは自動的にはインストールされません。 可能な限り、グループを対象ユーザーに割り当てることをお勧めします。ユーザーを追加または削除するとアプリの再発行が必要になるからです。 ワークスペース アクセス権を持つ人全員に、それぞれのワークスペース ロールに応じて、アプリを閲覧または更新するためのアクセス許可が自動的に付与されます。
• セマンティック モデルのアクセス許可: 次の 2 種類のセマンティック モデル アクセス許可を、アプリを発行するときに付与できます。
  • セマンティック モデルの再共有: 有効にすると、アプリ ユーザーに、基になるセマンティック モデルを他の人と再共有できるアクセス許可が付与されます。 このオプションを有効にすることが合理的であるのは、基になるセマンティック モデルを誰とでも簡単に再共有できる場合です。 アプリの対象ユーザーに "再共有" アクセス許可を付与する前に、セマンティック モデル所有者の承認を得ることをお勧めします。
  • セマンティック モデルのビルド: 有効にすると、アプリ ユーザーにセマンティック モデルに対するビルドのアクセス許可が付与されます。 "ビルド" アクセス許可が付与されているユーザーは、新しいレポートを作成することや、基になるデータをレポートからエクスポートすることなどができます。 アプリの対象ユーザーに "ビルド" アクセス許可を付与する前に、セマンティック モデル所有者の承認を得ることをお勧めします。

アプリを発行するときにセマンティック モデルの "再共有" または "ビルド" のアクセス許可を追加できる機能は便利です。 ただし、アプリのアクセス許可とセマンティック モデルのアクセス許可の管理を別々に行うことの検討をおすすめします。 その理由を次に示します。

• 共有セマンティック モデルが別のワークスペースに存在する場合がある: セマンティック モデルがアプリとは別のワークスペースに発行されている場合は、そのアクセス許可を直接管理することが必要になります。 アプリを発行するときに "読み取り"、"ビルド"、または "再共有" のアクセス許可を追加できる機能が効果を発揮するのは、セマンティック モデルがアプリと同じワークスペース内にある場合のみです。 このような理由から、セマンティック モデルのアクセス許可を独立して管理することを習慣にすることをおすすめします。
• セマンティック モデルのアクセス許可は別に管理される: あるアプリのアクセス許可を削除または変更する場合に、そのアクションの影響を受けるのはそのアプリのみです。 以前に割り当てられたセマンティック モデル アクセス許可が自動的に削除されることはありません。 このようにして、アプリのアクセス許可とセマンティック モデルのアクセス許可は "切り離されている" と考えることができます。 セマンティック モデルのアクセス許可が変更されたとき、または削除する必要があるときは、アプリとは別にセマンティック モデルを直接管理する必要があります。
• セマンティック モデルのアクセス許可を制御する必要がある: アプリを通じてセマンティック モデルのアクセス許可を付与すると、セマンティック モデルの所有者から制御が削除されます。 "再共有" アクセス許可を付与するときは、そのセマンティック モデルの再共有を選択するユーザーの適切な判断力が望まれます。 再共有が許可されているときは、内部ガバナンスやセキュリティ ガイドラインの管理がさらに困難になる可能性があります。
• コンシューマーと作成者のゴールは異なる: 一般的に、1 つの組織内のコンテンツ コンシューマーの数は作成者をはるかに上回ります。 最小特権の原則に従うと、コンシューマーに必要になるのは基になるセマンティック モデルに対する "読み取り" アクセス許可のみです。 新しいレポートを作成する予定がある場合を除いて、"ビルド" アクセス許可は必要ありません。

アプリ プレインストールの権限

Power BI アプリが発行された後に、一般的にはユーザーがそのアプリをインストールする必要があり、これでそのアプリを開けるようになります。 ユーザーは、アプリを Power BI サービスの [アプリ] ページからインストールするか、別のユーザーから受け取ったリンクを使用してインストールすることができます。 あるアプリを見つける (およびインストールする) ことができるのは、自分がそのアプリの少なくとも 1 つの対象ユーザーに含まれているときです。

アプリをインストールする別の方法は、アプリのコンシューマーに "プッシュ" することです。 その結果としてアプリがプレインストールされ、これで Power BI サービスの [アプリ] ページに自動的に表示されるようになります。 この方法はコンシューマーにとって、アプリを見つけてインストールする必要がないため便利です。 ただし、プレインストールされたアプリはユーザーにとって迷惑なものになる可能性があります。自分に関係のないアプリが多すぎて手に負えなくなるためです。

[アプリをエンド ユーザーにプッシュする] というテナント設定によって、誰にアプリの自動インストールを許可するかが制御されます。 この機能はユーザーにとって便利であるため、使用することをお勧めします。 ただし、使いすぎを防ぐために、いつ使用するかについてコンテンツ作成者を教育することもお勧めします。

チェックリスト - コンテンツ閲覧者のためのアプリ使用の戦略を作成するときの、主な決定事項とアクションは次のとおりです。

ワークスペース閲覧者ロール

ワークスペースの計画の記事で説明されているように、ワークスペースの第一の目的はコラボレーションです。 ワークスペースのコラボレーター、たとえばセマンティック モデル作成者、レポート作成者、テスト担当者は、共同作成者、メンバー、管理者の 3 つのロールのいずれかに割り当てられている必要があります。これらのロールの説明については、コンテンツ作成者のセキュリティ計画の記事を参照してください。

ワークスペースの "閲覧者" ロールをコンシューマーに割り当てることができます。 コンシューマーにワークスペース内のコンテンツへの直接アクセスを許可することが合理的であるのは、緊密に連携する小規模なチームや非公式のチームの場合です。

コンシューマーにワークスペース コンテンツへの直接アクセスを許可することは、次の場合に適しています。

• アプリの公式性 (個別のアクセス許可を持つ) が必要ない。
• 閲覧者には、ワークスペース内に格納されているすべてのアイテムの閲覧が許可されている。
• アイテムごとのアクセス許可よりも単純なアクセス許可管理を必要としている。
• ワークスペース ユーザーはアプリを表示することもできます (アプリがワークスペースに公開されているとき)。
• コンテンツをアプリ内で発行する前に閲覧者にレビューしてもらうことが目的である。

ワークスペース閲覧者をサポートするためのいくつかの提案を次に示します。

• レポート コンシューマーがアイテムを簡単に見つけることができるように、およびセキュリティとの整合性も取れるように、各ワークスペース内のコンテンツを編成します。 通常は、サブジェクト領域またはプロジェクト別にワークスペースを編成すると良い結果が得られます。
• 作業進行中のアイテムに閲覧者がアクセスできないようにするために、開発とテストのコンテンツを運用コンテンツから分離します。
• 処理すべきアクセス権要求が多数あると予想される場合は、アプリ (または、適切であればアイテムごとのアクセス許可) を使用します。 ワークスペースの "アクセス権の要求" ワークフローはありません。

チェックリスト - コンテンツ閲覧者のためのワークスペース使用の戦略を作成するときの、主な決定事項とアクションは次のとおりです。

アイテムごとのアクセス許可

個々のアイテムの共有では、1 つのアイテムに対するアクセス許可が付与されます。 経験の少ないコンテンツ作成者は一般的に、この手法を第一の共有手法として使用していますが、その理由は共有のコマンドが Power BI サービスに目立つように表示されるからです。 このような理由から、さまざまな共有オプションについて (これにはいつワークスペース ロールの代わりにアプリのアクセス許可を使用するかも含まれます) コンテンツ作成者を教育することが重要です。

アイテムごとのアクセス許可は、次の場合に適しています。

• 1 つのアイテム (レポートまたはダッシュボード) への読み取り専用アクセスを提供する必要がある。
• ワークスペースに発行されたすべてのコンテンツをコンシューマーが閲覧できるようにはしたくない。
• あるアプリ対象ユーザー向けに発行されたすべてのコンテンツをコンシューマーが閲覧できるようにはしたくない。

アイテムごとのアクセス許可はあまり頻繁に使用しないでください。共有によって読み取りアクセス許可が付与されるのは 1 つのアイテムだけだからです。 アイテムごとのアクセス許可は、ワークスペース ロールまたはアプリのアクセス許可のオーバーライドと考えることもできます。

アイテムごとのアクセス許可を使用して多数のアイテムを共有することは手間がかかり、エラーが発生しやすくなります。特に、グループではなく個々のユーザーと共有する場合です。 このシナリオを考えてみましょう。あなたは 40 件のレポートを同僚と共有していますが、これには同僚それぞれのユーザー アカウントを使用しています。 ある同僚が別の部署に異動するときは、その人のアクセス権を取り消す必要がありますが、それには 40 件のレポートすべてのアクセス許可を編集する必要があります。

個々のアイテムを共有するときは、アクセス許可に関して多数のオプションがあります。

• "再共有" アクセス許可: 有効化されているときは、ユーザーは他のユーザーとアイテムを共有でき、これにはその基になるセマンティック モデルも含まれます。 このアクセス許可を付与することが合理的であるのは、そのアイテムを誰とでも簡単に共有できる場合です。 そのアイテムを管理する人またはチームが制御することはできなくなります。 そのため、"再共有" アクセス許可が付与されたユーザーの適切な判断力が望まれます。 ただし、再共有が許可されているときは、内部ガバナンスやセキュリティ ガイドラインの管理が困難になる可能性があります。
• "ビルド" アクセス許可: 有効化されているときは、基になるセマンティック モデルに対する "ビルド" アクセス許可がユーザーに付与されます。 "ビルド" アクセス許可が付与されたユーザーは、そのセマンティック モデルに基づく新しいコンテンツを作成できます。 また、基になるデータをレポートからエクスポートすることなどもできます。 "ビルド" アクセス許可の付与に関する考慮事項については、コンテンツ作成者のセキュリティ計画の記事を参照してください。

レポートとダッシュボードに対するアイテムごとのアクセス許可が合理的であるのは、非公式のシナリオでコンテンツが少数のユーザーと共有される場合です。 代わりにアプリとワークスペースでのアクセス許可を管理するようにユーザーを教育することをお勧めします。特に、コンテンツを多数のユーザーと、またはチーム外のユーザーと共有しているときです。 次の点を強調することが重要です。

• どのコンテンツがどのユーザーと共有されているかを特定することが難しくなります。各レポートとダッシュボードに対するアクセス許可を個別にレビューする必要があるからです。
• 多くの場合に "再共有" アクセス許可が設定されていますが、その理由はユーザー エクスペリエンスによってこのオプションが既定で有効になるからです。 そのため、意図したよりも幅広いユーザーとの間でコンテンツが共有されるリスクがあります。 このような結果に至るのを防ぐには、共有時に [受信者にこのレポートの共有を許可する] オプションをオフにします。 この方法で過剰共有を最小限に抑えることは、ユーザー トレーニングで教える必要があります。 共有アクセス許可を設定するコンテンツ作成者は、この選択肢を毎回検討する必要があります。
• レポートとダッシュボードに対する変更はすべて、即座に他のユーザーから閲覧可能になるため、コンテンツの変更作業が進行中の場合はユーザーが混乱する可能性があります。 この懸念を軽減するには、コンテンツをアプリ内で配布するか、別のワークスペースを使用して開発、テスト、運用のコンテンツを分離します。 詳細については、セルフサービス コンテンツ発行という使用シナリオのページを参照してください。
• 自分の個人用ワークスペースからコンテンツを共有しているユーザーが組織を離れると、通常は IT 部門がそのユーザー アカウントを無効にします。 この場合は、直ちに共有コンテンツの受信者全員がそのコンテンツにアクセスできなくなります。

共有の種類は、共有リンク、直接アクセス共有、共有ビューの 3 つがあります。

アイテムごとのアクセス許可リンク

個々のアイテムを共有するときに、既定のエクスペリエンスでは共有リンクが作成されます。 共有リンクは 3 種類があります。

• 組織内のユーザー: Power BI テナント設定で有効化されているときは、この種類の共有リンクを使用すると、単純明快な方法で組織内の全員に読み取り専用アクセスを提供することができます。 ただし、この共有リンクは外部ユーザーに対しては機能しません。 このオプションが最も適しているのは、誰でもそのコンテンツを閲覧できて、リンクを組織全体で自由に共有できる場合です。 "共有可能リンクによる組織内の全員へのアクセス権付与を許可する" というテナント設定で無効化されている場合を除いて、この種類の共有が既定です。
• 既存のアクセス権を持つユーザー: このオプションを選択すると、新しい共有リンクは作成されません。 代わりに、URL を取得して、既にアクセス権を持っている人にこれを送信することができるようになります。
• 特定のユーザー: このオプションを選択すると、特定のユーザーまたはグループのための共有リンクが生成されます。 これによって限定的なアクセス権が提供されるので、ほとんどの場合は、このオプションを使用することをお勧めします。 外部ユーザーと作業することがよくある場合は、Microsoft Entra ID (旧称 Azure Active Directory) に既に存在するゲスト ユーザーに対して、この種類のリンクを使用できます。 ゲスト ユーザーを作成するための計画的な招待のプロセスの詳細については、テナント レベルのセキュリティ計画の記事を参照してください。

共有リンクによって、そのアイテムに対する "読み取り" アクセス許可が追加されます。 "再共有" アクセス許可が既定で選択されます。 また、基になるセマンティック モデルに対する "ビルド" アクセス許可を共有リンク作成と同時に追加することもできます。

共有リンクは直接アクセス共有よりも保守が容易です。特に、一括変更を行う必要があるときです。 これが大きな利点となるのは、グループよりも、個々のユーザーに共有アクセス許可が付与されることが多いとき (セルフサービス ユーザーがアクセス許可の管理を担当する場合に一般的に発生します) です。 次の比較を検討してください。

• 共有リンク: 20 人の個々のユーザーに、共有リンクを使用してアクセス権が付与されます。 1 回でもリンクが変更されると、20 人のユーザーすべてに影響します。
• 直接アクセス: 20 人の個人に、あるアイテムへの直接アクセスが許可されます。 変更を行うには、20 件のユーザー アクセス許可すべてを修正する必要があります。

アイテムごとの直接アクセス許可

"直接アクセス" を使用してアイテムごとのアクセス許可を実現することもできます。 直接アクセスの場合は、1 つのアイテムのアクセス許可を設定する必要があります。 ワークスペース ロールから派生した、継承されたアクセス許可を特定することもできます。

ユーザーに直接アクセスを許可すると、そのアイテムに対する "読み取り" アクセス許可が付与されます。 "ビルド" アクセス許可と同様に、基になるセマンティック モデルの "再共有" アクセス許可が既定で選択されます。 レポートのコンシューマーがコンテンツ作成者でもあり、基になるセマンティック モデルからのレポートの作成、データのエクスポート、または複合モデルの作成を行う必要がある場合にのみ "ビルド" アクセス許可を有効にするよう、コンテンツ作成者を指導することをお勧めします。

共有ビュー

共有ビューを使用すると、レポートの閲覧範囲をフィルターで絞り込んで別のユーザーと共有することができます。 共有ビューを発行するには、共有リンクを使用するか、直接アクセスを使用します。

共有ビューは一時的な概念です。 180 日後に自動的に失効します。 このような理由から、共有ビューが最も適しているのは非公式および一時的な共有シナリオです。 この制限を確実にユーザーに認識させてください。

チェックリスト - アイテムごとのアクセス許可の使用についての戦略を作成するときの、主な決定事項とアクションは次のとおりです。

その他のコンシューマー クエリ手法

コンシューマーが Power BI と対話する最も一般的な方法は、アプリ、ワークスペース、およびアイテムごとのアクセス許可です (この記事で前述)。

その他にも、コンシューマーが Power BI データのクエリに使用できる手法があります。 次に示す各クエリ手法には、セマンティック モデルまたはデータマートの "ビルド" アクセス許可が必要です。

• Excel で分析する: Excel の使用を好むコンシューマーは、Excel で分析を使用して Power BI セマンティック モデルに対してクエリを実行できます。 この機能は Excel へのデータのエクスポートの代わりとして優れていますが、その理由はデータが複製されないからです。 セマンティック モデルへのライブ接続を使用して、ユーザーはピボットテーブル、グラフ、スライサーを作成できます。 そのブックを Power BI サービスのワークスペースに発行すると、コンシューマーがブックを開いて操作できるようになります。
• XMLA エンドポイント: コンシューマーは XMLA エンドポイントに接続することでセマンティック モデルに対してクエリを実行できます。 XMLA 準拠であるアプリケーションからは、Premium ワークスペースに格納されているセマンティック モデルへの接続、クエリ、使用が可能です。 この機能は、コンシューマーが Microsoft エコシステム外のデータ視覚化ツールのデータ ソースとして Power BI のセマンティック モデルを使用する場合に役立ちます。
• データマート エディター: コンシューマーは、データマート エディターを使用して Power BI データマートに対してクエリを実行できます。 これは、ノーコード クエリを作成するための Web ベースのビジュアル クエリ エディターです。 コンシューマーが SQL クエリを書くことを好むときのための Web ベースの SQL エディターもあります。 どちらのエディターでも、Power BI データマートの基になるマネージド Azure SQL Database に対して (組み込みセマンティック モデルではなく) クエリが実行されます。
• SQL エンドポイント: コンシューマーは SQL エンドポイントを使用して Power BI データマートに対してクエリを実行できます。 SQL クエリの実行には Azure Data Studio や SQL Server Management Studio (SSMS) などのツールを使用できます。 SQL エンドポイントによって、Power BI データマートの基になるマネージド Azure SQL Database に (組み込みのセマンティック モデルではなく) クエリが送られます。

"ビルド" アクセス許可の詳細については、コンテンツ作成者のセキュリティ計画の記事を参照してください。

チェックリスト - コンシューマーが使用するクエリ手法を計画するときの、主な決定事項とアクションは次のとおりです。

コンシューマーのためのアクセス権要求ワークフロー

コンテンツを共有するときは、あるユーザーがリンク (URL) を別のユーザーに転送するのが一般的です。 受信者がそのコンテンツを閲覧しようとしたときに、アクセスできないことが判明した場合は、"アクセス権の要求" ボタンを選択できます。 このアクションによってアクセス権の要求ワークフローが開始します。 このときに、ユーザーはアクセス権が必要である理由を説明するメッセージの入力を求められます。

"アクセス権の要求" ワークフローは、次のものに対して存在します。

• Power BI アプリへのアクセス。
• アイテム (レポートやダッシュボードなど) へのアクセス。
• セマンティック モデルへのアクセス。 セマンティック モデルが検出可能であるときの "アクセス権の要求" ワークフローの詳細については、コンテンツ作成者のセキュリティ計画の記事を参照してください。

アプリのアクセス権の要求

アプリに対して提出された、保留中のアクセス権要求について知る方法は 2 つあります。

• メール: アプリの連絡先が電子メール通知を受け取ります。 既定では、この連絡先はアプリの発行者です。 重要なアプリに関してより良いサポートを提供できるように、アクセス権要求にすばやく応答できるグループを連絡先として設定することをお勧めします。
• [アクセス許可の管理] メニュー: ワークスペースの管理者とメンバーは、アクセス権要求を表示、承認、または拒否できます。 [アクセス許可の管理] ページは [アプリ] ページで使用でき、アプリごとに開くことができます。 この機能は、[共同作成者にこのワークスペースのアプリの更新を許可する] 設定が有効化されていればワークスペース共同作成者も使用できます。

アプリに対する保留中アクセス権要求には、ユーザーが入力したメッセージが表示されます。 保留中の各要求を、承認または拒否できます。 要求を承認することを選択した場合は、アプリの対象ユーザーを選択する必要があります。

次のスクリーンショットは、あるユーザーからの保留中アクセス権要求を示しています。 これを承認するには、セールス担当者 (Sales Reps) とセールス リーダーシップ (Sales Leadership) の 2 つのアプリ対象ユーザーのいずれかを選択する必要があります。

アプリを発行すると、コンテンツとアクセス許可が同時に発行されます。 前述のように、コンテンツの変更を発行せずにアプリのアクセス許可のみを発行することはできません。 ただし、1 つ例外があります。保留中のアクセス権要求 (たとえば前のスクリーンショットに示したもの) を承認すると、最新のコンテンツがワークスペース内で発行されることなく、アクセス許可の変更が発生します。

ワークスペース アクセス権要求

ワークスペース アクセス権は、管理ロールまたはメンバー ロールに属するユーザーによって付与されます。

ワークスペースを閲覧しようとするユーザーが、どのワークスペース ロールのメンバーでもない場合は "アクセス拒否" メッセージを受け取ります。 ワークスペースには組み込みの "アクセス権の要求" ワークフローがないため、これの使用が最も適しているのは緊密に連携する小規模なチームや非公式のチームの場合です。 これは、より大規模なチームやより広範なコンテンツ配布シナリオには Power BI アプリが適している理由の 1 つです。

アイテムごとのアクセス権要求

個々のアイテム (たとえばレポート) に対して提出された、保留中のアクセス権要求について知る方法は 2 つあります。

• メール: そのアイテムの連絡先が電子メール通知を受け取ります。 重要なレポートに関してより良いサポートを提供できるように、アクセス権要求にすばやく応答できるグループを連絡先として設定することをお勧めします。
• [アクセス許可の管理] メニュー: ワークスペースの管理者とメンバーは、各アイテムの [アクセス許可の管理] ページにアクセスできます。 保留中のアクセス権要求を表示、承認、または拒否できます。

グループを使用してアクセス権要求を管理する

ユーザーが Power BI アイテム (レポートやセマンティック モデルなど) または Power BI アプリに対する "アクセス権の要求" フォームを送信するときに、その要求は 1 人の個人ユーザーのために提出されます。 ただし、多くの大規模組織では、その内部セキュリティ ポリシーに準拠するためにグループを使用する必要があります。

コンテンツをセキュリティで保護するために、可能であれば個人ではなくグループを使用することをお勧めします。 グループに関する計画の詳細については、テナント レベルのセキュリティ計画の記事を参照してください。

アクセス権を個々のユーザーではなくグループに提供したいと考えている場合は、アクセス権の要求を処理するコンテンツ所有者または管理者が、次のような複数のステップで要求を完了する必要があります。

1. Power BI での保留中の要求を拒否します (1 人の個人ユーザーに関連付けられているためです)。
2. 現在のプロセスに従って、要求者を正しいグループに追加します。
3. アクセス権が付与されたことを要求者に通知します。

チェックリスト - "アクセス権の要求" ワークフローを計画するときの、主な決定事項とアクションは次のとおりです。

コンシューマーの ID に基づいてデータ セキュリティを適用する

データ セキュリティを適用することで、作成するセマンティック モデルとレポートの数を計画的に減らすことができます。 目標は、コンテンツを閲覧するユーザーの ID に基づいてデータ セキュリティを適用することです。

たとえば、1 つのセールス レポートをすべてのセールス担当者 (コンシューマー) と共有して、各セールス担当者は担当地域のセールス結果のみを閲覧できるようにすることを検討します。 この方法を使用すると、"地域ごと" に別のレポートを作成してそのセールス地域のセールス担当者と共有させるという複雑さを回避できます。

組織によっては、承認された (認定または昇格された) セマンティック モデルまたはデータマートに対する固有の要件があります。 広く使用されるデータの場合は、データ セキュリティの使用についての要件が存在する可能性があります。

データ セキュリティを実現するには、複数の方法があります。

• Power BI セマンティック モデル: Power BI データ作成者は、行レベルのセキュリティ (RLS) とオブジェクト レベルのセキュリティ (OLS) を適用できます。 RLS では、ロールとルールが定義されて、これによってデータ モデルの行がフィルター処理されますが、OLS では特定のテーブルまたは列へのアクセスが制限されます。 これらの定義された RLS および OLS ルールは、スライサーやフィルターの選択のようなセマンティック モデルの外部に保存される参照には適用されません。 RLS と OLS の両方の手法について、このセクションで後述します。
• Analysis Services: ライブ接続セマンティック モデルを、Azure Analysis Services (AAS) または SQL Server Analysis Services (SSAS) によってホストされるリモート データ モデルに接続できます。 このリモート モデルでは、コンシューマーの ID に基づいて RLS または OLS を適用できます。
• データ ソース: データ ソースの中には、Azure SQL Database のように、RLS を適用できるものがあります。 これに該当する場合は、(再定義するのではなく) 既存のセキュリティを Power BI モデルで利用できます。 この方法は、ソースで定義された RLS が複雑な場合に大きな利点となる可能性があります。 Power BI サービスの中で、DirectQuery モデルを開発して発行するとともにセマンティック モデルのデータ ソース資格情報を設定することで、シングル サインオン (SSO) を実現することができます。 レポート コンシューマーがレポートを開くと、Power BI によってその ID がデータ ソースに渡されます。 その後、レポート コンシューマーの ID に基づいて、データ ソースで RLS が適用されます。 Azure SQL Database RLS の詳細については、こちらの記事を参照してください。

行レベルのセキュリティ

行レベルのセキュリティ (RLS) を使用すると、データ モデラーがデータのサブセットへのアクセスを制限できます。 この一般的な用途は、一部のレポート コンシューマーに特定のデータ (たとえば他のセールス地域の売上結果) の閲覧を禁止することです。

Power BI レポートで RLS が構成された行を参照している場合、削除されたか存在しないフィールドと同じメッセージが表示されるため、注意してください。 このようなユーザーにとっては、レポートが壊れているように見えます。

RLS を設定するステップは、ルールとロール マッピングの 2 つがあります。

RLS ルール

セマンティック モデルに対して、データ モデラーは Power BI Desktop で 1 つ以上のロールを作成することで RLS を設定できます。 ロールはモデル内で一意の名前を持ち、通常は 1 つ以上のルールを含みます。 ルールは、Data Analysis Expressions (DAX) フィルター式を使用して、モデル テーブルにフィルターを適用します。 既定では、モデルにロールはありません。

ルール式は、行コンテキスト内で評価されます。 行コンテキストは、その行の列の値を使用して各行について式が評価されることを意味します。 式から TRUE が返されたときは、ユーザーがその行を見ることができます。 静的なまたは動的なルールを定義できます。

• 静的ルール:[Region] = "Midwest" のような、定数を参照する DAX 式を使用します。
• 動的ルール: 環境値 (定数ではなく) を返す特定の DAX 関数を使用します。 環境値は、3 つの DAX 関数 (USERNAME、USERPRINCIPALNAME、CUSTOMDATA) から返されます。 動的ルールの定義は、モデル テーブルにユーザー名の値が保存されている場合にシンプルで効果的です。 これにより、データ駆動型 RLS 設計を適用できます。

RLS ロール マッピング

モデルを Power BI サービスに発行した後、ユーザーが関連レポートにアクセスする前にロール マッピングを設定する必要があります。 ロール マッピングには、Microsoft Entra セキュリティ オブジェクトのロールへの割り当てが含まれます。 セキュリティ オブジェクトは、ユーザー アカウントまたはセキュリティ グループにすることができます。

可能であれば、ロールをセキュリティ グループにマップすることをお勧めします。 このようにすると、マッピングが少なくなるとともに、グループ メンバーシップ管理をグループの所有者が処理できるようになります。

コンテンツ作成者が Microsoft Entra からのセキュリティ アカウント情報を使用できるようにすることをお勧めします。 方法の 1 つは、Microsoft Entra ID と同期されたデータを使ってデータフローを作成することです。 このようにすると、コンテンツ作成者がデータフロー データを統合してデータドリブン セマンティック モデルを生成できるようになります。

RLS ユーザー エクスペリエンス

一部の組織は、標準の Power BI アクセス許可に加えて、RLS をセキュリティのセカンダリ レイヤーとして意図的に使用することを選択しています。 次のシナリオを考えてみましょう。あなたは、あるレポートへのリンクを組織全体と共有します。 このレポートを閲覧するユーザーは、RLS ロールの 1 つにマップされている必要があり、これでそのレポート内のデータを見ることができます。 RLS ロールにマップされていない場合は、どのデータも見ることはできません。

RLS が存在することによって、コンシューマーの既定のエクスペリエンスが変化します。

• セマンティック モデルに対して RLS が定義されていないとき: データセットに対して "少なくとも" 読み取りアクセス許可を持つ作成者とコンシューマーは、そのデータセット内の "すべてのデータ" を見ることができます。
• セマンティック モデルに対して RLS が定義されているとき: セマンティック モデルに対して読み取りアクセス許可 "のみ" を持つ作成者とコンシューマーは、自分が閲覧を許可されているデータ (RLS ロール マッピングに基づく) のみを見ることができます。

ユーザーがワークスペースまたはアプリでレポートを閲覧するときに、セマンティック モデルのアクセス許可に応じて、RLS が適用される場合も適用されない場合もあります。 このような理由から、RLS を適用する必要があるときは、コンテンツ コンシューマーと作成者が、基になるセマンティック モデルに対する読み取りアクセス許可のみを持つようにすることが重要です。

RLS が適用されるかどうかを決定するアクセス許可規則を次に示します。

• ユーザーにはセマンティック モデルに対する "読み取り" アクセス許可がある: そのユーザーに RLS が適用されます。
• ユーザーにはセマンティック モデルに対する "読み取り" と "ビルド" のアクセス許可がある: そのユーザーに RLS が適用されます。
• ユーザーにはセマンティック モデルに対する "書き込み" アクセス許可がある: そのユーザーに RLS は適用されません。つまり、セマンティック モデル内のすべてのデータを見ることができます。 "書き込み" アクセス許可が付与されると、セマンティック モデルを編集できるようになります。 これを付与するには、次の 2 つの方法があります。
  • 共同作成者、メンバー、または管理者というワークスペース ロールを使用する (セマンティック モデルが格納されているワークスペースに対して)。
  • 項目ごとの書き込み セマンティック モデルのアクセス許可を持つ。

RLS の詳細については、「Power BI モデル データへのアクセスを制限する」を参照してください。

データマートの RLS

Power BI データマートによって RLS を適用することもできます。 ただし、実装は異なります。

主な違いは、データマートの RLS が、Power BI Desktop ではなく Power BI サービスで設定されることです。

もう 1 つの違いは、データマートによる RLS の適用の対象が、セマンティック モデルと、データマートに関連付けられているマネージド Azure SQL Database の両方であることです。 RLS を両方のレイヤーで適用することによって、一貫性と柔軟性が得られます。 ユーザーがデータに対してクエリを実行する方法にかかわらず、つまりセマンティック モデルに接続するか、マネージド Azure SQL Database に接続するかに関係なく、同じ RLS フィルターが適用されます。

詳細については、データマートの RLS に関するページを参照してください。

オブジェクト レベルのセキュリティ

オブジェクト レベルのセキュリティ (OLS) を使用すると、データ モデラーが特定のテーブルと列、およびそのメタデータへのアクセスを制限できます。 OLS は一般的に、機密性の高い列 (たとえば従業員の給与) を特定のユーザーには見せないようにするために使用されます。 メジャーへのアクセスを制限することはできませんが、制限された列を参照するメジャー自体は制限されます。

従業員テーブルの例を考えてみましょう。 この中にある列に、従業員の名前と電話番号、および給与が格納されます。 OLS を使用すると、特定のユーザー、たとえば人事の上級スタッフだけが給与値を見ることができるようにすることができます。 給与値を見ることができないユーザーにとっては、その列が存在しないのと同じことになります。

注意が必要ですが、その理由は、Power BI レポートのビジュアルに給与が含まれている場合に、そのフィールドにアクセスできないユーザーにはエラー メッセージが表示されるからです。 このメッセージでは、そのオブジェクトが存在しないことが通知されます。 このようなユーザーにとっては、レポートが壊れているように見えます。

現時点では、OLS を設定するためのインターフェイスは Power BI Desktop にはありません。 サードパーティ製のツール Tabular Editor をモデルの作成、保守、管理に使用できます。 詳細については、高度なデータ モデル管理という使用シナリオのページを参照してください。

OLS の詳細については、「Power BI モデル オブジェクトへのアクセスを制限する」を参照してください。

チェックリスト - RLS と OLS の計画を立てるときの、主な決定事項とアクションは次のとおりです。

関連するコンテンツ

このシリーズの次の記事で、セマンティック モデル、データフロー、データマート、レポート、ダッシュボードの作成を担当するコンテンツ作成者のためのセキュリティ計画について学習します。