Power BI 実装計画: コンテンツ作成者のセキュリティ計画

注意

この記事は、Power BI 実装計画 シリーズの記事の一部です。 このシリーズでは、主に Microsoft Fabric 内での Power BI のエクスペリエンスに焦点を当てます。 シリーズの概要については、「Power BI 実装計画」を参照してください。

このセキュリティ計画の記事では、セマンティック モデル、データフロー、データマート、レポート、またはダッシュボードの作成を担当するコンテンツ作成者向けの戦略について説明します。 主な対象者は次のとおりです。

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

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

組織では、多くのユーザーが "コンテンツ作成者" です。 コンテンツ作成者は、他のユーザーに見られるコンテンツを生成して公開します。 この記事の焦点はコンテンツ作成者です。

ヒント

最初に、レポート コンシューマーのセキュリティ計画に関する記事を確認することをお勧めします。 データ セキュリティを適用する方法など、読み取り専用コンシューマーにコンテンツを安全に提供するための戦略が説明されています。

コンテンツ作成者のための戦略

適切に管理されたセルフサービス BI システムの基礎は、コンテンツ作成者と所有者から始まります。 これらのユーザーはセマンティック モデルとレポートを作成し、検証します。 多くの場合、コンテンツ作成者はコンテンツのセキュリティを管理するためのアクセス許可も設定します。

ヒント

データのセキュリティと保護をすべてのユーザーの役割の通常の一部にするデータ カルチャを育てることをお勧めします。 その目的を達成するには、ユーザーの教育、サポート、トレーニングが不可欠です。

セキュリティとアクセス許可の目的の場合は、コンテンツ作成者にはデータ作成者とレポート作成者の 2 種類があることを考慮します。 その人達は、エンタープライズ BI またはセルフサービス BI のコンテンツの作成と管理を担当できます。

データ作成者

データ作成者は、セマンティック モデル、データフロー、またはデータマートを作成する Power BI ユーザーです。

データ作成者の一般的なシナリオを次に示します。

• 新しいセマンティック モデルを作成する: Power BI Desktop で新しいデータ モデルを作成してテストします。 その後、多くのレポートの共有セマンティック モデルとして使用できるよう、Power BI サービスにそれを公開します。 共有セマンティック モデルの再利用の詳細については、マネージド セルフサービス BI の使用シナリオを参照してください。
• セマンティック モデルを拡張してカスタマイズする: Power BI Desktop の既存の共有セマンティック モデルへのライブ接続を作成します。 ライブ接続をローカル モデルに変換します。これにより、新しいテーブルまたは列でモデル設計を拡張できます。 共有セマンティック モデルの拡張とカスタマイズの詳細については、カスタマイズ可能なマネージド セルフサービス BI の使用シナリオを参照してください。
• 新しいデータフローを作成する: Power BI サービスで、多くのセマンティック モデルでソースとして使用できるように、新しいデータフローを作成します。 データ準備アクティビティの再利用について詳しくは、セルフサービス データ準備の使用シナリオをご覧ください。
• 新しいデータマートを作成する: Power BI サービスで、新しいデータマートを作成します。

データ作成者は、多くの場合、エンタープライズ BI チームやセンター オブ エクセレンス (COE) に属しています。 また、独自のデータを維持および管理する分散型のビジネス ユニットと部署で果たす重要な役割もあります。

ビジネス主導の BI、マネージド セルフサービス BI、エンタープライズ BI に関するその他の考慮事項については、コンテンツの所有権と管理に関する記事をご覧ください。

レポートの作成者

レポート作成者は、既存のセマンティック モデルから取得されたデータを視覚化するためのレポートとダッシュボードを作成します。

レポート作成者の一般的なシナリオを次に示します。

• データ モデルを含む新しいレポートを作成する: Power BI Desktop で新しいレポートとデータ モデルを作成してテストします。 1 つ以上のレポート ページとデータ モデルを含む Power BI Desktop ファイルを、Power BI サービスに公開します。 新しいコンテンツ作成者は、通常、共有セマンティック モデルの使用を認識する前に、この方法を使います。 また、データを再利用する必要がない狭いユース ケースにも適しています。
• ライブ接続レポートを作成する: Power BI サービス内の共有セマンティック モデルに接続する新しい Power BI レポートを作成します。 共有セマンティック モデルの再利用の詳細については、マネージド セルフサービス BI の使用シナリオを参照してください。
• 接続された Excel ブックを作成する: Power BI サービス内の共有セマンティック モデルに接続する新しい Excel レポートを作成します。 データのダウンロードではなく、接続された Excel エクスペリエンスを強くお勧めします。
• DirectQuery レポートを作成する: サポートされているデータ ソースに DirectQuery モードで接続する新しい Power BI レポートを作成します。 この方法が役に立つ状況の 1 つは、ソース システムによって実装されているユーザー セキュリティを利用する場合です。

レポート作成者は、組織内のすべての部署にいます。 通常、組織には、データ作成者よりレポート作成者の方が多くいます。

ヒント

すべてのセマンティック モデルが共有セマンティック モデルであるわけではありませんが、それでもマネージド セルフサービス BI 戦略を採用する価値はあります。 この戦略では、可能な限り共有セマンティック モデルを再利用します。 そのようにすると、レポートの作成とデータの作成が "切り離されます"。 どの部署のコンテンツ作成者も、この戦略を効果的に使用できます。

作成者のアクセス許可

このセクションでは、データ作成者とレポート作成者に関する最も一般的なアクセス許可について説明します。

このセクションは、考えられるすべてのアクセス許可の包括的なリストを意図したものではありません。 そうではなく、さまざまな種類のコンテンツ作成者をサポートするための戦略を計画するのに役立ちます。 最小限の特権の原則に従うことを目指す必要があります。 この原則では、ユーザーの生産性を高めるのに十分なアクセス許可だけにして、アクセス許可をプロビジョニングし過ぎないようにします。

新しいコンテンツの作成

新しいコンテンツを作成するには、通常、次のアクセス許可が必要です。

権限	レポート作成者	セマンティック モデル作成者	データフロー作成者	データマート作成者
基になるデータ ソースへのアクセス
セマンティック モデルの読み取りとビルドのアクセス許可
データフローの読み取りアクセス許可 (データフローがソースとして使用されているときは、ワークスペース閲覧者ロールを使用)
元の Power BI Desktop ファイルが格納されている場所へのアクセス
カスタム ビジュアルを使用するためのアクセス許可

コンテンツの発行のアクセス許可

コンテンツを公開するには、通常、次のアクセス許可が必要です。

権限	レポート作成者	セマンティック モデル作成者	データフロー作成者	データマート作成者
ワークスペース ロール: 共同作成者、メンバー、または管理者
セマンティック モデル書き込みアクセス許可 (ユーザーがワークスペース ロールに属していない場合)
項目を公開するデプロイ パイプライン ロール (オプション)

データの更新中

データの更新には、通常、次のアクセス許可が必要です。

権限	レポート作成者	セマンティック モデル作成者	データフロー作成者	データマート作成者
割り当てられた所有者 (設定をセットアップした、または項目を引き継いだユーザー)
基になるデータ ソースへのアクセス (ゲートウェイが使われていない場合)
ゲートウェイ内のデータ ソースへのアクセス (ソースがオンプレミスまたは仮想ネットワーク内にある場合)

この記事の残りの部分では、コンテンツ作成者のアクセス許可に関する考慮事項について説明します。

ヒント

コンテンツの表示に関連するアクセス許可については、レポート コンシューマーのセキュリティ計画に関する記事をご覧ください。

チェックリスト - コンテンツ作成者のためのセキュリティ戦略を計画するときの、主な決定事項とアクションは次のとおりです。

• データ作成者を決定する: セマンティック モデル、データフロー、データマートを誰が作成しているのかを把握しておきます。 セキュリティ計画アクティビティを始める前に、その人達のニーズを理解していることを確認します。
• レポート作成者を決定する: レポート、ダッシュボード、ブック、スコアカードを誰が作成しているのかを把握しておきます。 セキュリティ計画アクティビティを始める前に、その人達のニーズを理解していることを確認します。

作成者のためのコンテンツを見つける

ユーザーは、"データ検出" を利用してセマンティック モデルとデータマートを見つけることができます。 Power BI の機能であるデータ検出を使うことで、コンテンツ作成者は、そのコンテンツに対するアクセス許可を持っていない場合でも、既存のデータ資産を検索できます。

既存のデータの検出は、次の場合に役立ちます。

• 新しいレポートに既存のセマンティック モデルを使いたいレポート作成者。
• 既存のデータマートのデータのクエリを実行したいレポート作成者。
• 新しい複合モデルに既存のセマンティック モデルを使いたいセマンティック モデル作成者。

Note

Power BI でのデータ検出は、データ セキュリのティアクセス許可ではありません。 これは、レポート作成者がメタデータを読み取れるようにする設定であり、データを検出してアクセスを要求するのに役立ちます。

セマンティック モデルまたはデータマートを承認 (認定または昇格) するときに、それを検出可能として設定できます。 検出可能になっていると、コンテンツ作成者はデータ ハブでそれを見つけることができます。

コンテンツ作成者は、セマンティック モデルまたはデータマートへのアクセスを要求することもできます。 基本的に、アクセス要求はビルド アクセス許可を要求するものであり、それに基づいて新しいコンテンツを作成するために必要です。 アクセスの要求に応答する場合は、個々のユーザーではなくグループを使うことを検討してください。 この目的にグループを使う方法について詳しくは、「コンシューマーのアクセス ワークフローを要求する」をご覧ください。

以下の 3 つの例を検討してください。

• Sales Summary セマンティック モデルは認定されています。 これは、販売追跡のための信頼できて権限のあるソースです。 組織全体の多くのセルフサービス レポート作成者がこのセマンティック モデルを使います。 そのため、セマンティック モデルに基づく多くの既存のレポートと複合モデルがあります。 他の作成者がセマンティック モデルを見つけて使えるように、検出可能として設定されています。
• Inventory Stats セマンティック モデルは認定されています。 これは、インベントリ分析のための信頼できて権限のあるソースです。 セマンティック モデルとそれに関連するレポートは、エンタープライズ BI チームによって管理および配布されます。 セマンティック モデルの設計は複雑なので、インベントリ コンテンツの作成と管理はエンタープライズ BI チームのみに許可されています。 レポート作成者がセマンティック モデルを使用できないようにするのが目的なので、検出可能として設定されていません。
• Executive Bonuses セマンティック モデルには、機密情報が含まれています。 このセマンティック モデルを表示または更新するためのアクセス許可は、少数のユーザーに制限されています。 このセマンティック モデルは検出可能として設定されていません。

次に示すのは、Power BI サービスのデータ ハブでのセマンティック モデルのスクリーンショットです。 具体的には、検出可能なセマンティック モデルの "アクセス要求" メッセージの例を示しています。 このメッセージは、ユーザーが現在アクセス権を持っていない場合に表示されます。 "アクセス要求" メッセージは、セマンティック モデルの設定でカスタマイズされています。

"アクセス要求" メッセージの表示: "MTD/QTD/YTD の標準的な売上レポートの場合、このセマンティック モデルは承認および認定されたソースです。https://COE.contoso.com/RequestAccess にあるフォームに入力して、セマンティック モデルへのアクセスを要求してください。簡単な業務上の正当な理由を求められます。また、センター オブ エクセレンスのマネージャーが要求を承認する必要もあります。アクセスは 6 か月ごとに監査されます。"

Note

データカルチャと、データの民主化に対する姿勢が、データ検出を有効にするかどうかに強く影響するはずです。 データ検出について詳しくは、カスタマイズ可能なマネージド セルフサービス BI の使用シナリオをご覧ください。

検出に関連する 3 つのテナント設定があります。

• [コンテンツの検出] テナント設定を使用すると、Power BI 管理者は、データの検出が許可されるユーザーのグループを設定できます。 これは主に、レポートの作成時に既存のセマンティック モデルを検索する必要があるレポート作成者を対象としています。 また、複合モデルの開発で使用できる既存のデータを探すセマンティック モデル作成者にも役立ちます。 特定のセキュリティ グループに対してそれを設定することはできますが、組織全体で設定を有効にすることをお勧めします。 個々のセマンティック モデルとデータフローでの検出設定は、検出可能な内容を制御します。 一般的でありませんが、承認されたコンテンツ作成者のみにこの機能を制限することを検討する場合があります。
• [認定コンテンツを検出可能にする] テナント設定を使うと、Power BI 管理者は、コンテンツを検出可能に設定できるグループを設定できます (項目を編集するアクセス許可と、[照明] テナント設定によって付与されるコンテンツを認定するアクセス許可も持っている場合)。 コンテンツを認定する機能は、厳しく制御する必要があります。 ほとんどの場合は、コンテンツの認定を許可されているのと同じユーザーに、検出可能としての設定を許可する必要があります。 状況によっては、この機能を承認されたデータ作成者のみに制限することが必要な場合があります。
• [昇格したコンテンツを検出可能にする] テナント設定を使うと、Power BI 管理者は、コンテンツを検出可能として設定できるグループを設定できます (データを編集するアクセス許可も持っている場合)。 コンテンツを昇格させる機能はすべてのコンテンツ作成者が使用できるので、ほとんどの場合、すべてのユーザーがこの機能を利用できる必要があります。 一般的でありませんが、承認されたコンテンツ作成者のみにこの機能を制限することを検討する場合があります。

チェックリスト - コンテンツ作成者のデータ検出を計画する場合、主な決定事項とアクションは次のとおりです。

• データ検出の必要性を明確にする: コンテンツ作成者に既存のセマンティック モデルとデータマートの検索を促すことに対する、組織の立場を検討します。 必要に応じて、データ検出の使用方法に関するガバナンス ポリシーを作成します。
• コンテンツを検出できるユーザーを決定する: すべての Power BI ユーザーにコンテンツの検出を許可するか、または特定のユーザー グループ (承認されたコンテンツ作成者のグループなど) に検出を制限する必要があるかを決定します。 この決定に合わせて、テナント設定 [コンテンツの検出] を設定します。
• 認定コンテンツを検出可能に設定できるユーザーを決定する: すべての Power BI ユーザー (セマンティック モデルまたはデータマートを編集するアクセス許可と、それを認定するアクセス許可を持つユーザー) がそれを検出可能として設定できるようにするかどうかを決めます。 この決定に合わせて、テナント設定 [認定コンテンツを検出可能にする] を設定します。
• 昇格したコンテンツを検出可能に設定できるユーザーを決定する: すべての Power BI ユーザー (セマンティック モデルまたはデータマートを編集するアクセス許可を持つユーザー) がそれを検出可能として設定できるようにするかどうかを決めます。 この決定に合わせて、[昇格したコンテンツを検出可能にする] テナント設定を設定します。
• セマンティック モデル作成者向けのドキュメントとトレーニングに含める: セマンティック モデル作成者が所有および管理するセマンティック モデルとデータマートにデータ検出を使うのが適切なタイミングに関するガイダンスを含めます。
• レポート作成者向けのドキュメントとトレーニングに含める: データ検出のしくみと期待される内容に関するコンテンツ作成者向けのガイダンスを含めます。

作成者のアクセス要求ワークフロー

ユーザーは、2 つの方法でコンテンツへのアクセスを要求できます。

• コンテンツ コンシューマーの場合: ユーザーは、Power BI サービス内の既存のレポートまたはアプリへのリンクを受け取ります。 コンシューマーは、[アクセスの要求] ボタンを選ぶことで、項目を表示できます。 詳しくは、レポート コンシューマーのセキュリティ計画に関する記事をご覧ください。
• コンテンツ コンシューマーの場合: ユーザーは、データ ハブ内のセマンティック モデルまたはデータマートを検出します。 コンテンツ作成者は、[アクセスの要求] ボタンを選ぶことで、既存のデータを基にして新しいレポートまたは複合モデルを作成できます。 このセクションでは、このエクスペリエンスに焦点を当てます。

既定では、セマンティック モデルまたはデータマートへのアクセス要求は所有者に送られます。 所有者とは、データ更新を最後にスケジュールした、または資格情報を入力したユーザーです。 アクセス要求の処理を 1 人のユーザーに頼るのは、チームのセマンティック モデルに関しては許容される場合があります。 しかし、それでは実用的でないか信頼性が高くない場合があります。

1 人の所有者に任せるのではなく、ユーザーがセマンティック モデルまたはデータマートへのアクセスを要求したときに提示されるカスタム手順を定義できます。 カスタム手順は、次の場合に役に立ちます。

• セマンティック モデルが検出可能として設定されています。
• アクセス要求の承認が、データ所有者以外のユーザーによって行われます。
• アクセス要求で従う必要がある既存のプロセスがあります。
• 誰が、いつ、どのような理由でアクセスを要求したかを追跡することが、監査またはコンプライアンス上の理由で必要です。
• アクセスを要求し、望ましい結果を設定する方法について、説明する必要があります。

次に示すスクリーンショットは、ユーザーがビルド アクセス許可を要求したときに表示されるカスタム命令の設定の例です。 カスタム命令の表示: "MTD/QTD/YTD の標準的な売上レポートの場合、このセマンティック モデルは承認および認定されたソースです。https://COE.contoso.com/RequestAccess にあるフォームに入力して、セマンティック モデルへのアクセスを要求してください。簡単な業務上の正当な理由を求められます。また、センター オブ エクセレンスのマネージャーが要求を承認する必要もあります。アクセスは 6 か月ごとに監査されます。"

フォームを作成するには、多くのオプションがあります。 Power Apps と Microsoft Forms は、どちらもローコードで使いやすいオプションです。 1 人のユーザーに依存しない方法でフォームを作成することをお勧めします。 適切なチームによってフォームが作成、管理、監視されていることが重要です。

以下について役に立つ情報を作成することをお勧めします。

• アクセスを要求したときに予想されることを、コンテンツ作成者がわかるようにします。
• 送信された要求を管理する方法を、コンテンツ所有者と管理者がわかるようにします。

ヒント

コンシューマーからの読み取りアクセスの要求への応答について詳しくは、コンシューマーのアクセス ワークフローの要求に関する説明をご覧ください。 また、(個々のユーザーではなく) グループの使用に関する情報も含まれます。

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

• アクセス要求を処理する方法の優先設定を明確にする: 所有者の承認が受け入れられる状況と、別のプロセスを使用する必要があるときを決定します。 必要に応じて、アクセス要求の処理方法に関するガバナンス ポリシーを作成します。
• セマンティック モデルとデータマートの作成者向けのドキュメントとトレーニングに含める: アクセス要求のカスタム手順を設定する方法とタイミングについての、セマンティック モデルとデータマート作成者向けのガイダンスを含めます。
• レポート作成者向けのドキュメントとトレーニングに含める: セマンティック モデルとデータマートのビルド アクセス許可を要求するときに予想されることに関する、レポート作成者向けのガイダンスを含めます。

コンテンツを作成して公開する

このセクションには、コンテンツ作成者に適用されるセキュリティの側面が含まれます。

注意

レポート、ダッシュボード、スコアカードを表示するコンシューマーの場合は、レポート コンシューマーのセキュリティ計画に関する記事をご覧ください。 その記事でも、アプリのアクセス許可に関連する考慮事項について説明されています。

ワークスペースのロール

ワークスペースのロールにユーザーまたはグループ (セキュリティ グループ、Microsoft 365 グループ、配布リストを含む) を追加することによって、ワークスペースへのアクセスを許可します。 ユーザーをワークスペースのロールに割り当てることで、ワークスペースとそのコンテンツで実行できる操作を指定できます。

Note

ワークスペースの計画の考慮事項について詳しくは、ワークスペースの計画に関する記事をご覧ください。 グループについて詳しくは、テナント レベルのセキュリティ計画に関する記事をご覧ください。

ワークスペースの主な目的はコラボレーションであるため、ワークスペースへのアクセスは主に、そのコンテンツを所有して管理するユーザーに関連します。 ワークスペースのロールの計画を始めるときは、次のことを自問自答すると役に立ちます。

• ワークスペースでのコラボレーション方法には、どのようなことが求められますか?
• ワークスペース内のコンテンツの管理は誰が担当しますか?
• 個々のユーザーまたはグループをワークスペース ロールに割り当てるつもりですか?

Power BI ワークスペースには、管理者、メンバー、共同作成者、閲覧者の 4 つのロールがあります。 最初の 3 つのロールは、コンテンツを作成して公開するコンテンツ作成者に関連します。 閲覧者ロールは、読み取り専用のコンシューマーに関連します。

4 つのワークスペース ロールのアクセス許可は入れ子になっています。 つまり、ワークスペース管理者は、メンバー、共同作成者、閲覧者が使用できるすべての機能を持っています。 同様に、メンバーには、共同作成者と閲覧者が使用できるすべての機能があります。 共同作成者には、閲覧者が利用できるすべての機能があります。

ヒント

4 つの各ロールの正式なリファレンスについては、ワークスペースのロールに関するドキュメントをご覧ください。

ワークスペース管理者

管理者ロールに割り当てられたユーザーは、ワークスペース管理者になります。 ユーザー (他のワークスペース管理者を含む) の追加や削除など、すべての設定を管理し、すべてのアクションを実行できます。

ワークスペース管理者は、Power BI アプリを更新または削除できます (存在する場合)。 必要に応じて、ワークスペースのアプリの更新を共同作成者に許可できます。 詳しくは、後の「ワークスペースのロールのバリエーション」をご覧ください。

ヒント

管理者に言及するときは、ワークスペース管理者または Power BI テナント レベル管理者のどちらのことかを明確にしてください。

信用されていて信頼できる個人のみをワークスペース管理者にするように注意してください。 ワークスペース管理者は高い特権を持っています。 ワークスペース内のすべてのコンテンツを表示および管理するためのアクセス権を持っています。 任意のワークスペース ロールのユーザー (他の管理者を含む) を追加および削除できます。 また、ワークスペースを削除することもできます。

主席管理者が作業できないときにバックアップできるよう、少なくとも 2 人の管理者を設けることをお勧めします。 管理者がいないワークスペースは、"孤立したワークスペース" と呼ばれます。 孤立状態は、ユーザーが組織を離れ、ワークスペースに別の管理者が割り当てられていない場合に発生します。 孤立したワークスペースを検出して修正する方法について詳しくは、「ワークスペースの表示」記事をご覧ください。

理想的には、ワークスペースの管理者とメンバー (およびワークスペースに指定された連絡先) が誰であるかによって、ワークスペースのコンテンツについて責任を負う担当するユーザーがわかるようにする必要があります。 しかし、組織では、ワークスペースの作成を特定のユーザーまたはグループに制限するコンテンツの所有権と管理の戦略を採用している場合があります。 その場合、通常、IT 部署が管理するワークスペース作成プロセスが確立されています。 このような場合は、コンテンツを直接作成して公開するユーザーではなく、IT 部署がワークスペース管理者になります。

ワークスペース メンバー

メンバー ロールに割り当てられたユーザーは、他のワークスペース ユーザーを追加できます (管理者を追加することはできません)。 また、ワークスペース内のすべてのコンテンツのアクセス許可を管理することもできます。

ワークスペース メンバーは、ワークスペースのアプリを公開または公開解除したり、ワークスペースの項目やアプリを共有したり、他のユーザーがアプリのワークスペース項目を共有するのを許可したりできます。

ワークスペース メンバーは、ワークスペース コンテンツの作成を管理してアプリを公開する必要があるユーザーに限定する必要があります。 場合によっては、ワークスペース管理者がその目的を満たすため、メンバー ロールにユーザーまたはグループを割り当てる必要がない場合があります。 ワークスペース管理者がワークスペースのコンテンツに直接関係ない場合 (たとえば、IT 部門がワークスペース作成プロセスを管理するため)、ワークスペースのメンバーがワークスペースのコンテンツについて責任を負う真の所有者である可能性があります。

ワークスペースの共同作成者

共同作成者ロールに割り当てられたユーザーは、ワークスペースのコンテンツを作成、編集、または削除できます。

共同作成者は、ワークスペースの設定で許可されていない限り、Power BI アプリ (ワークスペースに存在する場合) を更新できません。 詳しくは、後の「ワークスペースのロールのバリエーション」をご覧ください。

組織内のほとんどのコンテンツ作成者は、ワークスペース共同作成者です。

ワークスペース ビューアー

閲覧者ロールに割り当てられたユーザーは、すべてのワークスペース コンテンツを表示および操作できます。

小規模なチームや非公式のシナリオでは、閲覧者ロールは読み取り専用コンシューマーに関連します。 詳しくは、レポート コンシューマーのセキュリティ計画に関する記事をご覧ください。

ワークスペースの所有権に関する考慮事項

新しいワークスペースを設定するために次のアクションを実行する例を考えてみます。

1. センター オブ エクセレンス (COE) の特定の Power BI チャンピオンとサテライト メンバーには、テナントの設定で新しいワークスペースを作成するためのアクセス許可が付与されています。 その人達は、コンテンツ組織の戦略と名前付け標準でのトレーニングを受けています。
2. あなた (コンテンツ作成者) は、自分が管理する新しいプロジェクト用のワークスペースを作成する要求を送信します。 ワークスペースには、プロジェクトの進捗状況を追跡するレポートが含まれます。
3. 部署の Power BI チャンピオンが要求を受け取ります。 新しいワークスペースは正当であると判断されます。 次に、その人達はワークスペースを作成し、(部署の) Power BI チャンピオン セキュリティ グループをワークスペース管理者ロールに割り当てます。
4. Power BI チャンピオンは、あなた (コンテンツ作成者) をワークスペースのメンバー ロールに割り当てます。
5. あなたは、信頼できる同僚をワークスペースのメンバー ロールに割り当てて、あなたが留守のときにバックアップできるようにします。
6. 他の同僚は、セマンティック モデルやレポートを含むワークスペース コンテンツの作成を担当するため、あなたはその人達をワークスペース共同作成者ロールに割り当てます。
7. マネージャーがプロジェクトの進行状況を監視するためにアクセスしたいといったので、あなたはマネージャーをワークスペース閲覧者ロールに割り当てます。 マネージャーは、あなたがアプリを公開する前に、ワークスペースのコンテンツを確認したいと考えています。
8. あなたは、説明や連絡先など、ワークスペースの他のプロパティを管理する責任を負っています。 また、ワークスペース アクセスの継続的な管理も担当しています。

前の例は、分散したビジネス ユニットが独立して機能できるようにする効果的な方法を示しています。 また、最小限の特権の原則も示されています。

ガバナンス対象のコンテンツ、または管理の厳しい重要なコンテンツの場合は、個人のユーザー アカウントではなく、グループをワークスペース ロールに割り当てるのがベスト プラクティスです。 そうすることで、ワークスペースとは別にグループ メンバーシップを管理できます。 ただし、グループをロールに割り当てると、ユーザーが複数のワークスペース ロールに割り当てられる可能性があります (ユーザーが複数のグループに属しているため)。 その場合、有効になるアクセス許可は、割り当てられている中で最も高いロールに基づいています。 その他の考慮事項については、「グループを使用するための戦略」をご覧ください。

ワークスペースが複数の個人またはチームによって共同所有されている場合、コンテンツの管理が複雑になる可能性があります。 ワークスペースを分けることで、複数のチームが所有権を持つシナリオを回避してください。 そうすることで、責任が明確になり、ロールの割り当ての設定が簡単になります。

ワークスペースのロールのバリエーション

ワークスペースの 4 つのロール (前述) に対して 2 つのバリエーションがあります。

• 既定では、ワークスペース用のアプリを作成、公開、更新できるのは、ワークスペースの管理者とメンバーだけです。 [Allow contributors to update the app option for this workspace] (共同作成者にこのワークスペースのアプリ オプションの更新を許可する) 設定はワークスペース レベルの設定であり、ワークスペース管理者はそれを使って、ワークスペース用アプリを更新する機能を共同作成者に委任できます。 ただし、共同作成者は、新しいアプリを公開したり、それを編集するアクセス許可を持つユーザーを変更したりすることはできません。 この設定は、共同作成者にアプリの更新を許可する必要があり (ワークスペースにアプリが存在する場合)、メンバーが使用できる他のアクセス許可をまだ付与していない場合に便利です。
• [Block republish and disable package refresh] (再公開をブロックしてパッケージの更新を無効にする) テナント設定では、セマンティック モデル所有者のみが更新を公開できます。 有効にすると、ワークスペースの管理者、メンバー、共同作成者は、最初にセマンティック モデルを所有者として引き継がない限り、変更を公開できません。 この設定は組織全体に適用され、テナントのすべてのセマンティック モデルに影響するため、有効にするときは注意してください。 ワークスペースのロールの通常の動作が変更されるため、セマンティック モデル作成者に予想されることを伝える必要があります。

重要

項目ごとのアクセス許可は、ワークスペースの標準ロールのオーバーライドと考えることもできます。 項目ごとのアクセス許可について詳しくは、レポート コンシューマーのセキュリティ計画に関する記事をご覧ください。

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

• 責任のマトリックスを作成する: コンテンツの作成、保守、公開、セキュリティ保護、サポートを行うときに、各機能を処理することが期待されるユーザーを計画します。 ワークスペースのロールを計画するときは、この情報を使用します。
• コンテンツ作成者にワークスペースのロールを割り当てる戦略を決定する: 管理者、メンバー、または共同作成者にする必要があるユーザーと、そうする状況 (職務や対象領域など) を決定します。 不一致が原因でセキュリティ上の問題が発生する場合は、ワークスペースをより適切に編成する方法を再検討します。
• ワークスペースのロールにセキュリティ グループまたは個人のどちらかを使う必要があるときの方法を決定する: グループを使用する必要があるユース ケースと目的を決定します。 ユーザー アカウントを使用してセキュリティを適用する必要がある場合と、グループが必要または優先される場合について具体的に決定します。
• ワークスペースのロールの管理に関するコンテンツ作成者向けのガイダンスを提供する: ワークスペースのロールの管理方法に関するコンテンツ作成者向けのドキュメントを含めます。 この情報を一元化されたポータルとトレーニング資料に公開します。
• ワークスペースのロールの割り当てを設定してテストする: コンテンツの編集と公開に必要な機能をコンテンツ作成者が持っていることを確認します。

アプリ作成者のアクセス許可

ワークスペース管理者またはメンバーであるコンテンツ作成者は、Power BI アプリを作成して公開できます。

ワークスペース管理者は、ワークスペース共同作成者がアプリを更新できるようにする設定をワークスペースで指定することもできます。 これは、通常は持っていない他のアクセス許可を共同作成者に付与するため、ワークスペース ロールのセキュリティのバリエーションです。 この設定は、ワークスペースごとに設定されます。

ヒント

読み取り専用コンシューマーにコンテンツを配信する方法について詳しくは、レポート コンシューマーのセキュリティ計画に関する記事をご覧ください。 この記事には、アプリの対象ユーザーなど、アプリ コンシューマーに対するアプリのアクセス許可に関する情報が含まれています。

チェックリスト - アプリ作成者のアクセス許可を計画するときの、主な決定事項とアクションは次のとおりです。

• Power BI アプリを作成して公開できるユーザーに関する戦略を決定する: Power BI アプリの作成と公開を許可する必要があるユーザーを明確にします。
• 共同作成者が Power BI アプリを更新できるタイミングを決定する: 共同作成者に Power BI アプリの更新を許可する必要がある状況を明確にします。 この機能が必要な場合は、ワークスペースの設定を更新します。

データ ソースのアクセス許可

データ作成者が新しいプロジェクトを始めるとき、外部データ ソースにアクセスするために必要なアクセス許可は、セキュリティ関連の最初の考慮事項の 1 つです。 また、それらでは、プライバシー レベル、ネイティブ データベース クエリ、カスタム コネクタなど、他のデータ ソース関連のことに関するガイダンスが必要な場合もあります。

データ ソースにアクセスする

データ作成者は、セマンティック モデル、データフロー、またはデータマートを作成するとき、データを取得するためにデータ ソースで認証を行う必要があります。 通常、認証にはユーザー資格情報 (アカウントとパスワード) が含まれ、それはサービス アカウント用のものである場合があります。

データ ソースにアクセスするための特定のサービス アカウントを作成すると便利な場合があります。 組織でサービス アカウントを使うときに必要な方法についてのガイダンスを、IT 部門に確認します。 許可されている場合、サービス アカウントを使って次のことができます。

• データ ソースに必要なアクセス許可を一元化します。
• データ ソースへのアクセス許可を必要とする個々のユーザーの数を減らします。
• ユーザーが組織を離れたときのデータ更新エラーを回避します。

ヒント

サービス アカウントを使う場合は、資格情報にアクセスできるユーザーを厳密に制御することをお勧めします。 定期的に (3 か月ごとなど)、またはアクセス権を持つユーザーが組織を離れたときに、パスワードをローテーションします。

データ ソースにアクセスするときは、最小限の特権の原則を適用して、ユーザー (またはサービス アカウント) が必要なデータ "のみ" を読み取るアクセス許可を持つようにします。 データの変更を実行するアクセス許可を持たないようにする必要があります。 これらのサービス アカウントを作成するデータベース管理者は、予想されるクエリとワークロードについて問い合わせて、適切な最適化 (インデックスなど) とリソースを確実に配置するための手順を実行する必要があります。

ヒント

セルフサービス データ作成者に直接データ ソース アクセスを提供することが難しい場合は、間接アプローチの使用を検討します。 Power BI サービスでデータフローを作成し、そこからデータを取得することをセルフサービス データ作成者に許可できます。 この方法にはさらに、データ ソースに対するクエリの負荷が減り、データの一貫したスナップショットが配信されるという利点があります。 詳しくは、セルフサービス データ準備と高度なデータ準備の使用シナリオに関する記事をご覧ください。

資格情報 (アカウントとパスワード) は、2 つの方法のいずれかで適用できます。

• Power BI Desktop: 資格情報は暗号化され、ユーザー コンピューターにローカルに格納されます。
• Power BI サービス: 資格情報は暗号化され、次のいずれかのために安全に格納されます。
  • セマンティック モデル (データ ソースにアクセスするためにデータ ゲートウェイが使われていない場合)。
  • ゲートウェイ データ ソース (データ ソースにアクセスするために標準ゲートウェイまたは仮想ネットワーク ゲートウェイ サービスが使われている場合)。

ヒント

セマンティック モデル データ ソースの資格情報を既に入力している場合は、接続文字列とデータベース名が完全に一致すると、Power BI サービスによってそれらの資格情報が他のセマンティック モデル データ ソースに自動的にバインドされます。 Power BI サービスと Power BI Desktop のどちらでも、データ ソースごとに資格情報を入力しているように見えます。 ただし、同じ所有者を持つ一致するデータ ソースに同じ資格情報を適用できます。 その点で、セマンティック モデルの資格情報は所有者に "スコープ設定" されています。

Power BI Desktop と Power BI サービスのどちらでも、資格情報は暗号化されて、データ モデルとは別に格納されます。 このデータ分離には、セキュリティに関して次のような利点があります。

• 複数のセマンティック モデル、データフロー、データマートでの資格情報の再利用が容易になります。
• セマンティック モデルのメタデータを解析しても、資格情報を抽出できません。
• Power BI Desktop では、別のユーザーは、最初に資格情報を適用しないと、元のデータ ソースに接続してデータを更新することはできません。

一部のデータ ソースではシングル サインオン (SSO) がサポートされており、Power BI サービスに資格情報を入力するときに設定できます (セマンティック モデルまたはゲートウェイ データ ソースの場合)。 SSO を有効にすると、Power BI は認証されたユーザーの資格情報をデータ ソースに送信します。 このオプションを使うと、データ ソースで設定されているセキュリティ設定 (行レベル セキュリティなど) を Power BI で優先できます。 SSO は、データ モデルのテーブルで DirectQuery ストレージ モードが使われている場合に特に便利です。

プライバシーのレベル

データ プライバシー レベルは、あるデータ ソースが他のデータ ソースから分離される程度を定義する分離レベルを指定します。 適切に設定すると、ソース間で互換性のあるデータのみが Power Query によって送信されることが保証されます。 Power Query がデータ ソース間でデータを送信できると、クエリの効率が上がり、Power BI に送信されるデータの量が減る可能性があります。 データ ソース間でデータを送信できないと、パフォーマンスが低下する可能性があります。

3 つのプライバシー レベルがあります。

• プライベート: 他のすべてのデータ ソースから分離する必要がある機密データが含まれます。 これは制限が最も厳しいレベルです。 プライベート データ ソースのデータを他のデータ ソースと共有することはできません。 たとえば、従業員の給与の値を含む人事データベースは、プライベート プライバシー レベルに設定する必要があります。
• 組織: パブリック データ ソースからは分離されますが、他の組織データ ソースからは見ることができます。 これは最も一般的なレベルです。 組織データ ソースのデータは、プライベート データ ソースまたは他の組織データ ソースと共有できます。 ほとんどの内部運用データベースは、組織プライバシー レベルで設定できます。
• パブリック: 任意のデータ ソースで表示できる機密ではないデータ。 これは制限が最も少ないレベルです。 パブリック データ ソースのデータは、他のデータ ソースと共有できます。 たとえば、政府の Web サイトから取得した国勢調査レポートは、パブリック プライバシー レベルに設定できます。

異なるデータ ソースのクエリを組み合わせるときは、適切なプライバシー レベルを設定することが重要です。 プライバシー レベルが正しく設定されていると、あるデータ ソースのデータが別のデータ ソースに送信されて、効率的にデータのクエリが実行される可能性があります。

セマンティック モデル作成者に Excel ブックと Azure SQL データベース内のテーブルという 2 つのデータ ソースがあるシナリオについて考えます。 Excel ブックから取得された値を使って、Azure SQL Database テーブル内のデータをフィルター処理する必要があります。 Azure SQL Database 用の SQL ステートメントを Power Query で生成する最も効率的な方法は、WHERE 句を適用して必要なフィルター処理を実行することです。 ただし、その SQL ステートメントには、Excel ブックから取得された値を含む WHERE 句述語が含まれます。 Excel ブックに機密データが含まれている場合は、データベース管理者はトレース ツールを使って SQL ステートメントを表示できるため、セキュリティ侵害が発生する可能性があります。 効率は低くなりますが、代わりに、Power Query マッシュアップ エンジンでデータベース テーブルの結果セット全体をダウンロードし、Power BI サービスでそれ自体のフィルター処理を実行できます。 このアプローチは効率が低く、遅くなりますが、安全です。

プライバシー レベルは、次の方法でデータ ソースごとに設定できます。

• データ モデラーが Power BI Desktop で。
• セマンティック モデル所有者が Power BI サービスで (ゲートウェイを必要としないクラウド データ ソースの場合)。
• ゲートウェイのデータ ソース作成者と所有者が Power BI サービスで (ゲートウェイ データ ソースの場合)。

重要

Power BI Desktop で設定したプライバシー レベルは、Power BI サービスに転送されません。

プライバシー レベルを無視してパフォーマンスを向上させることができる Power BI Desktop のセキュリティ オプションがあります。 データ セキュリティが侵害されるリスクがないときは (機密ではない開発データやテスト データを使っているため)、データ モデルの開発中に、このオプションを使ってクエリのパフォーマンスを向上させることができます。 ただし、この設定は Power BI サービスでは適用されません。

詳細については、Power BI Desktop のプライバシー レベルに関するページを参照してください。

ネイティブ データベース クエリ

効率的な Power Query クエリを作成するには、"ネイティブ クエリ" を使ってデータにアクセスできます。 ネイティブ クエリは、データ ソースによってサポートされている言語で記述されたステートメントです。 ネイティブ クエリは、特定のデータ ソースによってのみサポートされており、通常は Azure SQL Database のようなリレーショナル データベースです。

ネイティブ クエリは、悪意のある SQL ステートメントを実行する可能性があるため、セキュリティ リスクになることがあります。 悪意のあるステートメントにより、データの変更が実行されたり、データベースのレコードが削除されたりする可能性があります (ユーザーがデータ ソースで必要なアクセス許可を持っている場合)。 このため、既定では、Power BI Desktop でのネイティブ クエリの実行をユーザーが承認する必要があります。

Power BI Desktop には、事前の承認を不要にできるセキュリティ オプションがあります。 特に、Power BI Desktop のファイルが他のユーザーによって更新される可能性がある場合は、ユーザーの承認を必要とする既定の設定のままにすることをお勧めします。

カスタム コネクタ

開発者は、Power Query SDK を使って "カスタム コネクタ" を作成できます。 カスタム コネクタを使うと、独自のデータ ソースにアクセスしたり、カスタム データ拡張機能を使って特定の認証を実装したりできます。 一部のカスタム コネクタは、Microsoft の認定コネクタとして認定され配布されています。 認定コネクタは監査およびレビューされて、Microsoft がテストして承認した特定の指定コード要件を満たしていることが保証されています。

Power BI Desktop には、非認定コネクタの使用を制限するデータ拡張機能セキュリティ オプションがあります。 既定では、非認定コネクタを読み込もうとすると、エラーが発生します。 非認定コネクタを許可するようにこのオプションを設定すると、カスタム コネクタは検証や警告を受けずに読み込まれます。

データ拡張機能セキュリティ レベルを高いレベルに保つことをお勧めします。これにより、非認定コードの読み込みを防ぐことができます。 ただし、自分で開発したコネクタや、Microsoft 認定パス外の信頼できるコンサルタントやベンダーから提供されたコネクタなど、特定のコネクタを読み込むことが必要になる場合があります。

Note

社内で開発されたコネクタの開発者は、証明書でコネクタに署名する手順を実行し、ユーザーがセキュリティ設定を変更しないでコネクタを使用できるようにすることができます。 詳しくは、「信頼されたサードパーティ製コネクタ」をご覧ください。

チェックリスト - データ ソースのアクセス許可を計画するときの、主な決定事項とアクションは次のとおりです。

• 各データ ソースに直接アクセスできるユーザーを決定する: データ ソースに直接アクセスすることを許可されるデータ作成者を決めます。 直接アクセスできるユーザーの数を減らす戦略がある場合は、推奨される代替手段 (おそらくデータフローを使用) を明確にします。
• データ ソースへのアクセス方法を決定する: データ ソースへのアクセスに個々のユーザー資格情報を使うか、またはその目的のためのサービス アカウントを作成する必要があるかを決めます。 どのようなときにシングル サインオンが適切かを決定します。
• データ ソースへのアクセスに関するガイダンスをセマンティック モデル作成者に提供する: 組織のデータ ソースにアクセスする方法に関するコンテンツ作成者向けのドキュメントを含めます。 この情報を一元化されたポータルとトレーニング資料に公開します。
• プライバシー レベルに関するガイダンスをセマンティック モデル作成者に提供する: プライバシー レベルと、機密データを操作するときのその影響を認識させるためのガイダンスを、セマンティック モデル作成者に提供します。 この情報を一元化されたポータルとトレーニング資料に公開します。
• プライバシー レベルに関するガイダンスをゲートウェイ接続作成者に提供する: プライバシー レベルと、機密データを操作するときのその影響を認識させるためのガイダンスを、セマンティック モデル作成者に提供します。 この情報を一元化されたポータルとトレーニング資料に公開します。
• ネイティブ データベース クエリの使用に関する戦略を決定する: ネイティブ データベース クエリを使用するための戦略を検討します。 どのような方法で、どのようなときに、Power BI Desktop のネイティブ データベース クエリ オプションを設定して、Power Query でネイティブ クエリを実行するときの事前承認を無効にするのかについて、セマンティック モデル作成者を教育します。
• カスタム コネクタの使用に関する戦略を決定する: カスタム コネクタを使用するための戦略を検討します。 非認定コネクタの使用が正当化されるかどうかを判断し、される場合は、Power BI Desktop のデータ拡張機能オプションを設定すべきときと方法について、セマンティック モデル作成者を教育します。

セマンティック モデル作成者のアクセス許可

セマンティック モデルを編集するアクセス許可を、ユーザーまたはグループに、さまざまな方法で割り当てることができます。

• ワークスペース ロール: いずれかのワークスペース ロールに割り当てて、ワークスペース内のすべてのセマンティック モデルにアクセスできるようにします。 既存のセマンティック モデルを表示または編集する機能は、割り当てるワークスペース ロールによって異なります。 管理者、メンバー、共同作成者は、ワークスペース内のコンテンツを公開または編集できます。
• 項目ごとのアクセス許可リンク: レポート用の共有リンクを作成した場合、セマンティック モデルを読み取るためのアクセス許可 (およびオプションで、ビルド、書き込み、再共有) もリンクによって間接的に付与されます。
• 項目ごとの直接アクセスのアクセス許可: 特定のセマンティック モデルに直接アクセスのアクセス許可を割り当てることができます。

次のスクリーンショットでは、Call Center Data セマンティック モデルに割り当てられているアクセス許可に注意してください。 1 人のユーザーが読み取りアクセス許可を持っており、これは項目ごとの直接アクセスのアクセス許可を使って付与されました。 残りのユーザーとグループは、ワークスペース ロールに割り当てられているため、アクセス許可を持っています。

ヒント

項目ごとのアクセス許可 (リンクまたは直接アクセス) の使用は、ユーザーまたはグループがワークスペース内の 1 つの特定の項目を表示または編集する場合に最適です。 ワークスペース内のすべての項目へのアクセスをユーザーが許可されていない場合に最適です。 ほとんどの場合、セキュリティをワークスペースのロールで管理するのが簡単になるようにワークスペースを設計することをお勧めします。 可能な限り、項目ごとのアクセス許可は設定しないでください。

セマンティック モデルのアクセス許可

次のセマンティック モデルのアクセス許可を割り当てることができます。

• 読み取り: レポート コンシューマーを主な対象とするこのアクセス許可があると、レポートでセマンティック モデル内のデータのクエリを実行できます。 読み取り専用コンテンツを表示するためのアクセス許可について詳しくは、レポート コンシューマーのセキュリティ計画に関する記事をご覧ください。
• ビルド: レポート作成者を対象とするこのアクセス許可があると、ユーザーは共有セマンティック モデルを基にして新しいレポートを作成できます。 詳しくは、後の「レポート作成者のアクセス許可」セクションをご覧ください。
• 書き込み: セマンティック モデルを作成、公開、管理するセマンティック モデル作成者を対象とするこのアクセス許可があると、ユーザーはセマンティック モデルを編集できます。 これについてはこのセクションで後ほど説明します。
• 再共有: セマンティック モデルに対する既存のアクセス許可を持つすべてのユーザーを対象とするこのアクセス許可があると、ユーザーはセマンティック モデルを別のユーザーと共有できます。 これについてはこのセクションで後ほど説明します。

ワークスペース管理者またはメンバーは、セマンティック モデルのアクセス許可を編集できます。

セマンティック モデルの読み取りアクセス許可

セマンティック モデルの読み取りアクセス許可は、主にコンシューマーを対象としています。 このアクセス許可は、ユーザーがレポートに表示されるデータを見ることができるために必要です。 セマンティック モデルに基づくレポートには、読み取りアクセス許可も必要であることに注意してください。そうしないと、レポートの読み込みが失敗します。 レポートの読み取りアクセス許可の設定について詳しくは、レポート コンシューマーのセキュリティ計画に関する記事をご覧ください。

セマンティック モデルのビルド アクセス許可

コンテンツ作成者には、セマンティック モデルの読み取りアクセス許可に加えて、セマンティック モデルのビルド アクセス許可も必要です。 具体的には、ビルド アクセス許可でレポート作成者は次のことができます。

• セマンティック モデルを基にして新しい Power BI レポートを作成します。
• [Excel で分析] を使ってセマンティック モデルに接続します。
• XMLA エンドポイントを使ってセマンティック モデルのクエリを実行します。
• Power BI レポートのビジュアルの基になるデータをエクスポートします (ビジュアルによって取得された集計データの代わりに)。
• Power BI セマンティック モデルへの DirectQuery 接続を作成します。 この場合、新しいセマンティック モデルは、1 つ以上の既存の Power BI セマンティック モデルに接続します ("チェーン" と呼ばれます)。 セマンティック モデル作成者がチェーンされたセマンティック モデルのクエリを実行するには、すべてのアップストリーム セマンティック モデルに対するビルド アクセス許可が必要です。 詳細については、この記事で後述する「チェーンされたセマンティック モデル」を参照してください。

ユーザーまたはグループへのビルド アクセス許可の付与は、直接または間接のさまざまな方法で行うことができます。

• ビルドを直接許可するには次のようにします。
  • Power BI サービスのセマンティック モデル設定ページで、セマンティック モデルのアクセス許可を設定します。
  • Power BI REST API を使って、セマンティック モデルのアクセス許可を設定します。
• ビルドを間接的に許可するには次のようにします。
  • レポートまたはダッシュボードを共有し、セマンティック モデルのビルド アクセス許可を付与するオプションを設定します。
  • Power BI アプリを公開し、(対象ユーザー向けの) 詳細オプションを設定して、関連するセマンティック モデルに対するビルド アクセス許可を付与します。
  • 管理、メンバー、または共同作成者のワークスペース ロールにユーザーを割り当てます。

項目ごとにきめ細かくセキュリティを管理したい場合は、セマンティック モデルにビルド アクセス許可を直接設定するのが適しています。 間接的な方法のいずれかを使ってコンテンツを表示または使用するユーザーが、新しいコンテンツの作成も行う場合は、間接的にビルド アクセス許可を設定するのが適しています。

ヒント

レポートまたは Power BI アプリを表示するユーザーが、基になるセマンティック モデルを使って新しいコンテンツを作成するユーザーと異なることがよくあります。 ほとんどのコンシューマーは閲覧者のみであるため、新しいコンテンツを作成する必要はありません。 必要最小限の数のアクセス許可を付与するよう、コンテンツ作成者を教育することをお勧めします。

セマンティック モデルの書き込みアクセス許可

通常、セマンティック モデルを編集および管理できるユーザーに対するアクセス許可の設定は、管理者、メンバー、または共同作成者のワークスペース ロールにユーザーを割り当てることによって行われます。 ただし、特定のセマンティック モデルに対する書き込みアクセス許可を設定することもできます。

アクセス許可を管理および監査する最も簡単な方法であるため、可能な限りワークスペース ロールを使うことをお勧めします。 作成するワークスペースの数が少なく、異なるアクセス許可管理を必要とする異なる対象領域のセマンティック モデルがワークスペースに含まれるときは、項目ごとのセマンティック モデル書き込みアクセス許可を使います。

ヒント

ワークスペースの編成方法のガイダンスについては、ワークスペースの計画に関する記事をご覧ください。

セマンティック モデルの再共有アクセス許可

既存のアクセス許可を持つユーザーに、セマンティック モデルの再共有アクセス許可を割り当てると、セマンティック モデルを他のユーザーと共有できます。 ユーザーの裁量でセマンティック モデル内のコンテンツを自由に共有できる場合は、このアクセス許可を付与できます。

多くの場合、セマンティック モデルのアクセス許可が慎重に制御されるように、再共有アクセス許可の使用を制限することをお勧めします。 再共有アクセス許可を付与する前に、セマンティック モデル所有者から承認を得ます。

セマンティック モデルのデータ セキュリティ

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

セマンティック モデル作成者は、2 つの方法でデータのセキュリティを適用できます。

• 行レベル セキュリティ (RLS) を使うと、データ モデラーはデータのサブセットへのアクセスを制限できます。
• オブジェクト レベル セキュリティ (OLS) をデータ モデラーが使用すると、特定のテーブルと列、およびそのメタデータへのアクセスを制限できます。

RLS と OLS の実装の対象はレポート コンシューマーです。 詳しくは、レポート コンシューマーのセキュリティ計画に関する記事をご覧ください。 セマンティック モデルの表示専用アクセス許可を持つコンシューマーに対し、どのようにして、いつ RLS と OLS を適用するかが説明されています。

他のレポート作成者を対象とする RLS と OLS については、後の「レポート作成者のアクセス許可」セクションをご覧ください。

チェーンされたセマンティック モデル

Power BI のセマンティック モデルは、"チェーン" と呼ばれるプロセス (アップストリームのセマンティック モデルへの接続) で他のセマンティック モデルに接続できます。 詳細については、Power BI セマンティック モデルと Analysis Services に DirectQuery を使用する方法に関するページを参照してください。

[Allow DirectQuery connections to Power BI semantic models] (Power BI セマンティック モデルへの DirectQuery の接続を許可する) テナント設定を使うと、Power BI 管理者は、チェーンされたセマンティック モデルを作成できるコンテンツ作成者のグループを設定できます。 セマンティック モデル作成者によるセマンティック モデルのチェーンを制限したくない場合は、組織全体についてこの設定を有効のままにして、ワークスペース アクセスとセマンティック モデルのアクセス許可に任せることができます。 場合によっては、この機能を承認されたコンテンツ作成者に制限することを検討することもできます。

Note

セマンティック モデル作成者は、自分のセマンティック モデルへのチェーンを制限できます。 これを行うには、Power BI Desktop で [Discourage DirectQuery connection to this dataset] (このセマンティック モデルへの DirectQuery の接続を禁止する) オプションを有効にします。 詳細については、「公開済みのセマンティック モデルに対する DirectQuery 接続を管理する」を参照してください。

セマンティック モデル API のクエリ

状況によっては、Power BI REST API を使って DAX クエリを実行することが必要になる場合があります。 たとえば、データ品質の検証を実行するような場合です。 詳しくは、「データセット - クエリの実行」をご覧ください。

[Dataset Execute Queries REST API] (データセット クエリの実行 REST API) テナント設定を使うと、Power BI 管理者は、Power BI REST API を使って DAX クエリを送信できるユーザーのグループを設定できます。 ほとんどの場合は、組織全体についてこの設定を有効のままにして、ワークスペース アクセスとセマンティック モデルのアクセス許可に任せることができます。 場合によっては、この機能を承認されたコンテンツ作成者に制限することを検討することもできます。

チェックリスト - セマンティック モデル作成者のアクセス許可を計画するときの、主な決定事項とアクションは次のとおりです。

• セマンティック モデル作成者に対するアクセス許可の戦略を決定する: セマンティック モデル作成者のセキュリティの管理に関して存在する優先設定と要件を決めます。 対象領域とデータの機密性のレベルを検討します。 また、一元化および分散化された部署でデータとアクセス許可の管理を担当することが許されるユーザーを検討します。
• セマンティック モデル作成者についてワークスペースのロールを処理する方法を確認する: ワークスペースの設計プロセスに与える影響を判断します。 各対象領域のワークスペース ロールとセマンティック モデル セキュリティをより簡単に管理できるように、対象領域ごとに個別のデータ ワークスペースを作成します。
• アクセス許可の管理に関するガイダンスをセマンティック モデル作成者に提供する: セマンティック モデルのアクセス許可を管理する方法に関するセマンティック モデル作成者向けのドキュメントを含めます。 この情報を一元化されたポータルとトレーニング資料に公開します。
• Power BI セマンティック モデルに対する DirectQuery 接続を使用できるユーザーを決定する: Power BI セマンティック モデルへの接続を作成できる (セマンティック モデルに対するビルド アクセス許可を既に持っている) Power BI セマンティック モデル作成者に制限を設ける必要があるかどうかを決定します。 [Allow DirectQuery connections to Power BI semantic models] (Power BI セマンティック モデルへの DirectQuery 接続を許可する) テナント設定を、この決定に合わせて設定します。 この機能を制限する場合は、"Power BI で承認されたセマンティック モデル作成者" などのグループを使うことを検討します。
• REST API を使って Power BI セマンティック モデルのクエリを実行できるユーザーを決定する: Power BI コンテンツ作成者が Power BI REST API を使って Power BI セマンティック モデルのクエリを実行するのを制限するかどうかを決定します。 [Dataset Execute Queries REST API] (データセット クエリの実行 REST API) テナント設定を、この決定に合わせて設定します。 この機能を制限する場合は、"Power BI で承認されたレポート作成者" などのグループを使うことを検討します。
• セマンティック モデル作成者に対する RLS または OLS の使用に関する戦略を決定する: RLS または OLS を使用するユース ケースと目的を検討します。 セマンティック モデル作成者に RLS または OLS を適用する場合は、ワークスペースの設計戦略と、読み取りアクセス許可と編集アクセス許可を持つユーザーを考慮します。

レポート作成者のアクセス許可

レポート作成者が、Power BI サービスでレポートを作成したり、Power BI Desktop からレポートを公開したりするには、ワークスペースのアクセス権が必要です。 そのようなユーザーは、ターゲット ワークスペースの管理者、メンバー、または共同作成者である必要があります。

可能な限り、レポート作成者は (ライブ接続または DirectQuery を介して) 既存の共有セマンティック モデルを使う必要があります。 そうすることで、レポート作成プロセスがセマンティック モデル作成プロセスから "切り離されます"。 この種類の分離には、セキュリティとチーム開発のシナリオに関する多くの利点があります。

レポート作成者は、ワークスペースの管理者、メンバー、または共同作成者である必要があります。

セマンティック モデルとは異なり、レポートの書き込みアクセス許可はありません。 レポート作成者をサポートするには、ワークスペースのロールを使う必要があります。 このため、コンテンツの編成とセキュリティのニーズのバランスが取られた最適なワークスペース設計にすることが重要です。

ヒント

レポート コンシューマーをサポートするためのアクセス許可 (項目ごとの読み取りと再共有のアクセス許可を含む) については、レポート コンシューマーのセキュリティ計画に関する記事をご覧ください。

基になるセマンティック モデルの読み取りとビルドのアクセス許可

レポート作成者は、レポートで使うセマンティック モデル (チェーンされたセマンティック モデルを含む) に対する読み取りとビルドのアクセス許可を持っている必要があります。 そのアクセス許可は、個々のセマンティック モデルに対して明示的に付与することも、レポート作成者がワークスペースの管理者、メンバー、または共同作成者である場合に、ワークスペース セマンティック モデルに対して暗黙的に付与することもできます。

[ワークスペースをまたいでセマンティック モデルを使用] テナント設定を使うと、Power BI 管理者は、他のワークスペースにあるセマンティック モデルを使用するレポートを作成できるユーザーのグループを設定できます。 この設定の対象は、セマンティック モデルとレポートの作成者です。 通常は、組織全体についてこの設定を有効のままにして、ワークスペースのアクセス設定とセマンティック モデルのアクセス許可に任せることをお勧めします。 そうすることで、既存のセマンティック モデルの使用を促進できます。 場合によっては、この機能を承認されたコンテンツ作成者のみに制限することを検討することもできます。

[ライブ接続の許可] というテナント設定もあり、Power BI 管理者は、Power BI Desktop または Excel のセマンティック モデルへのライブ接続を作成できるユーザーのグループを設定できます。 それはレポート作成者を特に対象としており、対象者はレポートで使われるセマンティック モデルに対する読み取りとビルドのアクセス許可も付与されている必要があります。 組織全体についてこの設定を有効のままにして、ワークスペース アクセスとセマンティック モデルのアクセス許可に任せることをお勧めします。 そうすることで、既存のセマンティック モデルの使用を促進できます。 場合によっては、この機能を承認されたコンテンツ作成者のみに制限することを検討することもできます。

基になるセマンティック モデルのデータ セキュリティ

RLS と OLS (この記事で前に説明しました) の対象は、レポート コンシューマーです。 ただし、レポート作成者に対して適用することが必要な場合もあります。 レポート作成者とレポート コンシューマーに RLS を適用する必要がある場合は、個別のワークスペースの作成が正当化されます。

次のシナリオについて考えてみます。

• RLS を使って一元管理される共有セマンティック モデル: エンタープライズ BI チームは、Sales Data ワークスペースに販売セマンティック モデルを公開しました。 これらのセマンティック モデルでは、レポート コンシューマーの割り当て販売担当地域の売上データを表示するために RLS が適用されています。
• 分散セルフサービス レポート作成者: 営業およびマーケティング部門には、独自のレポートを作成する多くの有能なアナリストがいます。 その人達は、Sales Analytics ワークスペースにレポートを公開します。
• セマンティック モデルの読み取りとビルドのアクセス許可: アナリストは可能な限り、Sales Data ワークスペースのセマンティック モデルを使って、データの不要な重複を回避します。 アナリストが持っているのは、これらのセマンティック モデルに対する読み取りとビルドのアクセス許可のみなので (書き込みまたは編集のアクセス許可はありません)、RLS はレポート作成者に (レポート コンシューマーにも) 適用されます。
• レポート ワークスペースの編集アクセス許可: アナリストは、Sales Analytics ワークスペースについてはさらに多くの権限を持っています。 管理者、メンバー、または共同作成者のワークスペース ロールを使うと、レポートを公開および管理できます。

RLS と OLS について詳しくは、レポート コンシューマーのセキュリティ計画に関する記事をご覧ください。 セマンティック モデルの表示専用アクセス許可を持つコンシューマーに対し、どのようにして、いつ RLS と OLS を適用するかが説明されています。

外部セマンティック モデルへの接続

レポート作成者は、レポートの共有セマンティック モデルに接続するときに、通常、独自の Power BI テナントで公開された共有セマンティック モデルに接続します。 アクセス許可が付与されている場合は、別のテナントの共有セマンティック モデルにも接続できます。 他のテナントとしては、パートナー、顧客、ベンダーなどがあります。

この機能は、インプレース セマンティック モデル共有と呼ばれます ("クロステナント セマンティック モデル共有" とも呼ばれます)。 レポート作成者によって作成されたレポート (またはセマンティック モデル作成者によって作成された新しい複合モデル) は、通常のプロセスを使って Power BI テナントに格納され、セキュリティで保護されます。 元の共有セマンティック モデルは元の Power BI テナントに残っており、すべてのアクセス許可はそこで管理されます。

詳細については、コンシューマーのセキュリティ プランのレポートに関する記事を参照してください。 これには、外部共有を機能させるテナントの設定とセマンティック モデルの設定に関する情報が含まれます。

おすすめのテーブル

Power BI Desktop では、セマンティック モデル作成者はモデル テーブルを "おすすめのテーブル" になるように設定できます。 セマンティック モデルを Power BI サービスに公開するとき、レポート作成者は Excel のデータ型ギャラリーを使っておすすめのテーブルを検索し、おすすめのテーブルのデータを追加して Excel ワークシートを拡張できます。

[Allow connections to featured tables] (おすすめテーブルへの接続を許可する) テナント設定を使うと、Power BI 管理者は、おすすめのテーブルにアクセスできるユーザーのグループを設定できます。 その対象は、Excel の組織のデータ型で Power BI のおすすめのテーブルにアクセスすることを望む Excel ユーザーです。 組織全体についてこの設定を有効のままにして、ワークスペース アクセスとセマンティック モデルのアクセス許可に任せることをお勧めします。 そうすることで、おすすめのテーブルの使用を促進できます。

カスタム ビジュアルのアクセス許可

Power BI レポート作成者は、コア ビジュアルに加えて "カスタム ビジュアル" を使用できます。 Power BI Desktop では、カスタム ビジュアルを Microsoft AppSource からダウンロードできます。 また、Power BI SDK を使って社内でそれらを開発し、ビジュアル ファイル (.pbviz) を開いてインストールすることもできます。

AppSource からダウンロードできるビジュアルの一部は、"認定済みのビジュアル" です。 認定済みの Power BI ビジュアルは、Power BI チームがテストして承認した、特定の指定されたコード要件を満たしています。 テストでは、ビジュアルが外部のサービスやリソースにアクセスしないことがチェックされます。

Power BI 管理者は、テナント設定 [Allow visuals created by the Power BI SDK] (Power BI SDK によって作成されたビジュアルを許可する) を使うことで、カスタム ビジュアルを使用できるユーザーのグループを制御できます。

また、[認定済みのカスタム視覚化のみを許可] テナント設定もあり、これを使うと、Power BI 管理者は Power BI サービスでの認定されていないビジュアルの使用をブロックできます。 この設定は、組織全体で有効または無効にすることができます。

Note

認定済みではないビジュアルの使用のブロックは、Power BI サービスにのみ適用されます。 Power BI Desktop でのその使用を制限したい場合は、グループ ポリシー設定を使って Power BI Desktop での使用をブロックするよう、システム管理者に依頼します。 この手順を実行すると、レポート作成者は Power BI サービスに公開しても機能しないレポートの作成に時間と労力を無駄にしないで済みます。 Power BI サービス (テナント設定を使用) と Power BI Desktop (グループ ポリシーを使用) でユーザーのエクスペリエンスが一貫するように設定することを強くお勧めします。

Power BI Desktop には、レポート作成者がカスタム ビジュアルをレポートに追加するとセキュリティ警告を表示するオプションがあります。 レポート作成者は、このオプションを無効にできます。 このオプションでは、ビジュアルが認定済みかどうかはテストされません。

Power BI 管理者は、組織用のカスタム ビジュアルを承認してデプロイできます。 レポート作成者は、これらのビジュアルを簡単に検出、更新、使用できます。 その後、管理者は、バージョンを更新したり、特定のカスタム ビジュアルを無効や有効にして、これらのビジュアルを管理できます。 この方法は、社内で開発されたビジュアルをレポート作成者が使用できるようにする場合や、AppSource にないカスタム ビジュアルをベンダーから取得する場合に便利です。 詳しくは、「Power BI 組織のビジュアル」をご覧ください。

組織のビジュアルをデプロイして例外を処理しながら、(前述のテナント設定とグループ ポリシーを使用して) 認定済みのカスタム ビジュアルのみを組織内で有効にする、バランスの取れた戦略を検討してください。

チェックリスト - レポート作成者のアクセス許可を計画するときの、主な決定事項とアクションは次のとおりです。

• レポート作成者に対するアクセス許可の戦略を決定する: レポート作成者のセキュリティの管理に関して存在する優先設定と要件を決めます。 対象領域とデータの機密性のレベルを検討します。 また、一元化および分散化された部署でレポートの管理を担当するユーザーも検討します。
• レポート作成者についてワークスペースのロールを処理する方法を確認する: ワークスペースの設計プロセスに与える影響を判断します。 対象領域のワークスペース ロール (および基になるセマンティック モデルのセキュリティ) が簡素化されるように、対象領域ごとに個別のデータ ワークスペースとレポート ワークスペースを作成します。
• アクセス許可の管理に関するガイダンスをレポート作成者に提供する: レポート コンシューマーのアクセス許可を管理する方法に関するレポート作成者向けのドキュメントを含めます。 この情報を一元化されたポータルとトレーニング資料に公開します。
• 共有セマンティック モデルを使用できるユーザーを決定する: ワークスペースをまたいでセマンティック モデルを使用できる Power BI レポート作成者 (セマンティック モデルに対する読み取りとビルドのアクセス許可を既に持っているユーザー) について制限を設ける必要があるかどうかを決定します。 この決定に合わせて、テナント設定 [ワークスペースをまたいでセマンティック モデルを使用] を設定します。 この機能を制限する場合は、"Power BI で承認されたレポート作成者" などのグループを使うことを検討します。
• ライブ接続を使用できるユーザーを決定する: ライブ接続を使用できる Power BI レポート作成者 (セマンティック モデルに対する読み取りとビルドのアクセス許可を既に持っているユーザー) について制限を設ける必要があるかどうかを決定します。 この決定に合わせて、テナント設定 [ライブ接続の許可] を設定します。 この機能を制限する場合は、"Power BI で承認されたレポート作成者" などのグループを使うことを検討します。
• レポート作成者に対する RLS の使用に関する戦略を決定する: どのユース ケースと目的に行レベルのセキュリティを使用するかを検討します。 レポート作成者に RLS が確実に適用されるように、ワークスペース設計戦略を考慮します。
• カスタム ビジュアルの使用に関する戦略を決定する: レポート作成者がカスタム ビジュアルを使用できる戦略を検討します。 この決定に合わせて、テナント設定 [Allow visuals created by the Power BI SDK] (Power BI SDK によって作成されたビジュアルを許可する) を設定します。 必要に応じて、組織のビジュアルを使うためのプロセスを作成します。

データフロー作成者のアクセス許可

データフローは、Power Query で行われる作業が多くのセマンティック モデルで繰り返されないように、データの準備を一元化するのに役立ちます。 これらは、"単一の正しい情報源" を実現するための構成要素であり、アナリストがソースに直接アクセスする必要がないようにして、抽出、変換、読み込み (ETL) 操作の大規模な実行を支援します。

データフロー作成者は、ワークスペースの管理者、メンバー、または共同作成者である必要があります。

セマンティック モデル作成者は、閲覧者ロールを含む任意のワークスペース ロールに属していれば、データフローを使用できます (たとえば、Power BI Desktop または別のワークスペースで作成された新しいデータ モデルから)。 データフローに RLS の概念はありません。

ワークスペースのロールに加えて、[データフローの作成と使用] テナント設定を有効にする必要があります。 このテナント設定は組織全体に対して適用されます。

次のシナリオについて考えてみます。

• 組織内の多くのセマンティック モデルで、動的 RLS を適用する必要があります。 ユーザー プリンシパル名 (UPN) をセマンティック モデルに格納する必要があります (レポート コンシューマーの ID でフィルター処理するため)。
• 人事部に属するデータフロー作成者は、UPN を含む現在の従業員の詳細のデータフローを作成します。 毎日更新するようにデータフローを設定します。
• セマンティック モデル作成者は、次に、モデル設計のデータフローを使って RLS を設定します。

データフローの使用について詳しくは、セルフサービス データ準備と高度なデータ準備の使用シナリオに関する記事をご覧ください。

チェックリスト - データフロー作成者のアクセス許可を計画するときの、主な決定事項とアクションは次のとおりです。

• データフロー作成者に対するアクセス許可の戦略を決定する: データフロー作成者のセキュリティの管理に関して存在する優先設定と要件を決めます。 一元化および分散化された部署でデータ準備アクティビティの管理を担当することが許される、または推奨されるユーザーを検討します。
• データフローを作成できるユーザーを決定する: データフローを作成できる Power BI データ作成者に制限を設ける必要があるかどうかを決定します。 この決定に合わせて、テナント設定 [データフローの作成と使用] を設定します。
• データフロー作成者についてワークスペースのロールを処理する方法を確認する: ワークスペースの設計プロセスに与える影響を判断します。 必要に応じて、対象領域ごとにワークスペースのロールとアクセス許可を個別に処理できるように、対象領域ごとに個別のデータフロー ワークスペースを作成します。

データマート作成者のアクセス許可

データマートは、ユーザーがフル マネージド リレーショナル データベースに読み込まれたデータを格納して探索できるようにする、セルフサービス分析ソリューションです。 また、自動生成されたセマンティック モデルも含まれます。

データマートでは、さまざまなデータ ソースからデータを取り込み、Power Query Online を使ってデータの抽出、変換、読み込み (ETL) を行うための、シンプルなローコード エクスペリエンスが提供されます。 データは、フル マネージドで、チューニングや最適化を必要としない Azure SQL データベースに読み込まれます。 自動生成されたセマンティック モデルは、DirectQuery モードであるため、常にマネージド データベースと同期されます。

ワークスペースの管理者、メンバー、または共同作成者は、データマートを作成できます。 ワークスペースのロールは、Azure SQL Database のデータベース レベルのロールにもマップされます (ただし、データベースはフル マネージドであるため、リレーショナル データベースでユーザーのアクセス許可を編集または管理することはできません)。

Power BI 管理者は、[データマートの作成] テナント設定を使って、データマートを作成できるユーザーのグループを設定できます。

データマートの共有

データマートの場合、"共有" という用語には、他の Power BI コンテンツ タイプとは異なる意味があります。 通常、共有操作は、レポートなどの 1 つの項目への読み取り専用アクセス許可を提供するため、コンシューマーを対象としています。

データマートの共有は、(コンシューマーではなく) コンテンツ作成者を対象としています。 それによって読み取りとビルドのアクセス許可が付与され、ユーザーは必要に応じてセマンティック モデルまたはリレーショナル データベースのどちらのクエリでも実行できます。

データマートを共有すると、コンテンツ作成者は次のことができます。

• 自動生成されたセマンティック モデルを使ってコンテンツをビルドする: セマンティック モデルは、Power BI レポートを構築できるセマンティック レイヤーです。 ほとんどのレポート作成者は、セマンティック モデルを使う必要があります。
• Azure SQL データベースに接続してクエリを実行する: リレーショナル データベースは、新しいセマンティック モデルまたはページ割り付けレポートを作成するコンテンツ作成者に役立ちます。 構造化クエリ言語 (SQL) でクエリを記述し、SQL エンドポイントを使ってデータを取得できます。

データマートの行レベル セキュリティ

データマートに RLS を定義して、指定したユーザーにデータ アクセスを制限できます。 RLS は、Power BI サービスのデータマート エディターで設定され、自動生成されたセマンティック モデルと Azure SQL データベースに (セキュリティ規則として) 自動的に適用されます。

ユーザーがデータマートに接続する方法に関係なく (セマンティック モデルまたはデータベース)、同じ RLS アクセス許可が適用されます。

チェックリスト - データマート作成者のアクセス許可を計画するときの、主な決定事項とアクションは次のとおりです。

• データマート作成者に対するアクセス許可の戦略を決定する: データマート作成者のセキュリティの管理に関して存在する優先設定と要件を決めます。 一元化および分散化された部署でデータの管理を担当することが許される、または推奨されるユーザーを検討します。
• データマートを作成できるユーザーを決定する: データマートを作成できる Power BI データ作成者に制限を設ける必要があるかどうかを決定します。 この決定に合わせて、テナント設定 [データマートの作成] を設定します。 データマートを作成できるユーザーを制限する場合は、"Power BI の承認済みデータマート作成者" といったグループの使用を検討します。
• データマート作成者についてワークスペースのロールを処理する方法を確認する: ワークスペースの設計プロセスに与える影響を判断します。 対象領域に対するワークスペースのロールとセマンティック モデルのセキュリティを簡略化できるよう、対象領域ごとに個別のデータ ワークスペースを作成します。
• アクセス許可の管理に関するガイダンスをデータマート作成者に提供する: データマートのアクセス許可を管理する方法に関するデータマート作成者向けのドキュメントを含めます。 この情報を一元化されたポータルとトレーニング資料に公開します。
• データマートでの RLS の使用に関する戦略を決定する: データマート内で RLS を使用するユース ケースと目的を検討します。

スコアカード作成者のアクセス許可

Power BI のメトリックを使うと、特定のメトリックを作成し、主要なビジネス目標に対してそれらを追跡できます。 メトリックはスコアカードに追加され、他のユーザーと共有して 1 つのウィンドウに表示できます。

スコアカードは、次の 3 つのレベルのアクセス許可で保護できます。

• ワークスペース。
• スコアカード (項目ごと) のアクセス許可。
• メトリック (スコアカード内)。

スコアカードを作成または完全に管理するユーザーは、ワークスペースの管理者、メンバー、または共同作成者である必要があります。

多くの場合、メトリックは複数の対象領域にまたがるため、作成者とコンシューマーのアクセス許可を個別に管理できるように、別のワークスペースを作成することをお勧めします。

Power BI 管理者は、[Create and use metrics] (メトリックの作成と使用) テナント設定を使って、スコアカードのメトリックを作成できるユーザーのグループを設定できます。

スコアカードのアクセス許可

次のスコアカードのアクセス許可を割り当てることができます。

• 読み取り: このアクセス許可があると、ユーザーはスコアカードを表示できます。
• 再共有: スコアカードに対する既存のアクセス許可を持つすべてのユーザーを対象とするこのアクセス許可があると、ユーザーはスコアカードを別のユーザーと共有できます。

Power BI サービスの他のコンテンツ タイプと同じように、ある項目を別のユーザーと共有することが目的のときは、項目ごとのアクセス許可が役に立ちます。 可能な限り、ワークスペースのロールとアプリのアクセス許可を使うことをお勧めします。

メトリック レベルのアクセス許可

各スコアカードには、スコアカードの設定で設定できるメトリック レベルのアクセス許可のセットがあります。 (スコアカード内の) メトリック レベルのアクセス許可は、ワークスペースまたはスコアカード (項目ごと) のアクセス許可とは異なる方法で付与できます。

メトリック レベルのロールを使うと、次の設定を行うことができます。

• スコアカードで個々のメトリックを表示できるユーザー。
• 次の方法で個々のメトリックを更新できるユーザー:
  • チェックインの間の状態の更新。
  • チェックインの間のメモの追加。
  • チェックインの間の現在値の更新。

将来のメンテナンスのレベルを下げるため、将来作成するサブメトリックによって継承される既定のアクセス許可を設定できます。

チェックリスト - メトリック作成者のアクセス許可を計画するときの、主な決定事項とアクションは次のとおりです。

• スコアカード作成者に対するアクセス許可の戦略を決定する: スコアカード作成者のセキュリティの管理に関して存在する優先設定と要件を決めます。 一元化および分散化された部署でデータの管理を担当することが許される、または推奨されるユーザーを検討します。
• スコアカードを作成できるユーザーを決定する: スコアカードを作成できる Power BI データ作成者に制限を設ける必要があるかどうかを決定します。 この決定に合わせて、テナント設定 [Create and use Metrics] (メトリックの作成と使用) を設定します。 スコアカードを作成できるユーザーを制限する場合は、"Power BI の承認済みスコアカード作成者" といったグループの使用を検討します。
• スコアカード作成者についてワークスペースのロールを処理する方法を確認する: ワークスペースの設計プロセスに与える影響を判断します。 コンテンツが複数の対象領域にまたがる場合は、スコアカード用に別のワークスペースを作成することを検討します。
• アクセス許可の管理に関するガイダンスをスコアカード作成者に提供する: メトリック レベルのアクセス許可を管理する方法に関するスコアカード作成者向けのドキュメントを含めます。 この情報を一元化されたポータルとトレーニング資料に公開します。

コンテンツの公開

このセクションには、コンテンツ作成者に関連のある、コンテンツの公開関連のトピックが含まれます。

Workspaces

コンテンツ作成者がワークスペースにコンテンツを公開するには、管理者、メンバー、または共同作成者ロールのアクセス権が必要です。 詳しくは、前に説明したワークスペースのロールをご覧ください。

個人用 BI の場合を除き、コンテンツ作成者には、個人用ワークスペースではなく、標準ワークスペースにコンテンツを公開することをお勧めします。

[Block republish and disable package refresh] (再公開をブロックしてパッケージの更新を無効にする) テナント設定は、セマンティック モデルの公開の動作を変更します。 有効にすると、ワークスペース管理者、メンバー、または共同作成者はセマンティック モデルへの変更を公開できません。 セマンティック モデル所有者のみが更新を公開できます (更新されたセマンティック モデルを公開する前にセマンティック モデルの引き継ぎを強制)。 このテナント設定は組織全体に適用され、テナント全体のすべてのセマンティック モデルに影響するため、有効にするときは注意してください。 ワークスペースのロールの通常の動作が変更されるため、セマンティック モデル作成者に予想されることを伝える必要があります。

Power Apps の同期

埋め込み Power BI レポートを含む Power Apps ソリューションを作成できます。 Power Apps プロセスにより、Power BI のレポートとセマンティック モデルを格納してセキュリティ保護するための専用の Power BI ワークスペースが自動的に作成されます。 Power Apps と Power BI の両方に存在する項目を管理するには、同期プロセスがあります。

このプロセスでは、セキュリティ ロールが同期されて、Power Apps で最初に設定されたのと同じロールが Power BI によって確実に継承されます。 また、コンテンツ作成者は、Power App に埋め込まれている Power BI レポート (および関連セマンティック モデル) を表示できるユーザーのアクセス許可を管理することもできます。

Power Apps のロールと Power BI ワークスペースのロールの同期について詳しくは、「Power Apps 環境と Power BI ワークスペース間の権限の同期」をご覧ください。

デプロイ パイプラインのアクセス

コンテンツの作成者と所有者は、セルフサービス コンテンツの公開に Power BI のデプロイ パイプラインを使用できます。 デプロイ パイプラインを使うと、公開プロセスが簡素化されて、新しいコンテンツをリリースするときの制御レベルが向上します。

パイプラインのアクセス許可 (デプロイ パイプラインでコンテンツをデプロイできるユーザーに対するもの) は、ワークスペースのロールとは別に管理します。 デプロイを実行するユーザーには、ワークスペースとデプロイ パイプラインの両方へのアクセス権が必要です。

コンテンツ作成者には、次のものも必要な場合があります。

• ワークスペース作成アクセス許可 (パイプラインでワークスペースを作成する必要がある場合)。
• Premium またはファブリックの容量のアクセス許可 (ワークスペースがパイプラインによって割り当てられる場合)。

重要

この記事では、Power BI Premium またはその容量サブスクリプション (P SKU) に言及することがあります。 現在、Microsoft は購入オプションを統合し、容量あたりの Power BI Premium SKU を廃止していることに注意してください。 新規および既存のお客様は、代わりに Fabric 容量サブスクリプション (F SKU) の購入をご検討ください。

詳細については、「Power BI Premium ライセンスに関する重要な更新」と「Power BI Premium のよく寄せられる質問」を参照してください。

詳しくは、「デプロイ パイプラインへのアクセス」をご覧ください。

XMLA エンドポイント

XMLA エンドポイントでは XMLA プロトコルを使用して、表形式データ モデルのすべての機能が公開されます。これには、Power BI Desktop でサポートされていない一部のデータ モデリング操作も含まれます。 Tabular Object Model (TOM) API を使って、プログラムでデータ モデルを変更できます。

XMLA エンドポイントも接続を提供します。 セマンティック モデルに接続できるのは、ワークスペースのライセンス モードが Premium Per User、Premium Per Capacity、または Embedded に設定されている場合に限られます。 接続されたら、XMLA に準拠したツールで、データ モデルを操作してデータの読み取りまたは書き込みを行うことができます。 セマンティック モデルの管理に XMLA エンドポイントを使用できる方法の詳細については、高度なデータ モデル管理の使用シナリオを参照してください。

XMLA エンドポイント経由のアクセスでは、既存のアクセス許可が優先されます。 ワークスペースの管理者、メンバー、共同作成者には、暗黙的にセマンティック モデル書き込みアクセス許可があります。つまり、Visual Studio から新しいセマンティック モデルをデプロイし、SQL Server Management Studio (SSMS) で Tabular Model Scripting Language (TMSL) スクリプトを実行できます。

セマンティック モデルのビルド アクセス許可を持つユーザーは、XMLA エンドポイントを使って、データの使用と視覚化のためにセマンティック モデルに接続して参照できます。 RLS ルールが適用され、ユーザーは内部セマンティック モデル メタデータを見ることはできません。

[XMLA エンドポイントとオンプレミスのセマンティック モデルによる "Excel で分析" の許可] テナント設定は、2 つの機能を参照します。これは、XMLA エンドポイントを使って Power BI サービス内のセマンティック モデルのクエリや保守を実行できる、ユーザーのグループを制御します。 また、オンプレミスの SQL Server Analysis Services (SSAS) モデルで "Excel で分析" を使用できるかどうかを決定します。

注意

そのテナント設定の "Excel で分析" は、オンプレミスの SQL Server Analysis Services (SSAS) モデルにのみ適用されます。 Power BI サービスの Power BI セマンティック モデルに接続する標準の "Excel で分析" 機能は、[ライブ接続の許可] テナント設定によって制御されます。

Web に公開

"Web に公開" は、インターネット上のユーザーが Power BI レポートにアクセスできるようにする機能です。 認証は必要ありませんし、アクセスは監査目的でログに記録されません。 レポート コンシューマーは組織に属していたり、Power BI ライセンスを持っている必要がないため、この手法は、データ ジャーナリズム (ブログ投稿、Web サイト、電子メール、またはソーシャル メディアにレポートが埋め込まれるプロセス) に非常に適しています。

注意事項

Web に公開すると、誤って、または意図的に、機密データが公開される可能性があります。 そのため、この機能は既定で無効になっています。 "Web に公開" は、誰が見てもよいデータが含まれるレポートにのみ使う必要があります。

[Web に公開] テナント設定を使うと、Power BI 管理者は、レポートを Web に公開できるユーザーのグループを制御できます。 より高いレベルの制御を維持するため、このテナント設定には他のグループ (Power BI 管理者や、他の種類のコンテンツ作成者など) を含めないようにすることをお勧めします。 代わりに、"Power BI パブリック公開" のようなセキュリティ グループを使って、特定のユーザー アクセスを強制します。 セキュリティ グループが適切に管理されていることを確認してください。

カスタム アプリへの埋め込み

[アプリにコンテンツを埋め込む] テナント設定を使うと、Power BI 管理者は、Power BI サービスの外部に Power BI コンテンツを埋め込むことができるユーザーを制御できます。 カスタム アプリケーションに Power BI コンテンツを埋め込む予定の場合は、アプリ開発者などの特定のグループに対してこの設定を有効にします。

PowerPoint での埋め込み

[Enable Power BI add-in for PowerPoint] (PowerPoint 用 Power BI アドインを有効にする) テナント設定を使うと、Power BI 管理者は、PowerPoint プレゼンテーションに Power BI レポートのページを埋め込むことができるユーザーを制御できます。 必要に応じて、レポート作成者などの特定のグループに対してこの設定を有効にします。

注意

この機能を動作させるには、ユーザーは PowerPoint 用 Power BI アドインをインストールする必要があります。 アドインを使うには、ユーザーが Office アドイン ストアにアクセスできるか、または管理者によって管理されるアドインとしてアドインをユーザーが利用できる必要があります。 詳しくは、PowerPoint 用 Power BI アドインに関する記事をご覧ください。

レポート作成者に対して、PowerPoint プレゼンテーションを保存する場所と共有相手に注意することを教育します。 これは、ユーザーがプレゼンテーションを開くと、Power BI レポート ビジュアルの画像が表示されるためです。 その画像は、最後に接続されたときの PowerPoint ファイルからキャプチャされます。 ただし、その画像で、受信するユーザーが表示するアクセス許可を持っていないデータが誤って表示される可能性があります。

Note

この画像は、受け取ったユーザーがまだアドインを持っていない場合や、アドインが Power BI サービスに接続してデータを取得するまで、役に立つことがあります。 ユーザーが接続すると、ユーザーが見ることのできるデータのみ (RLS の適用) が Power BI から取得されます。

テンプレート アプリ

"テンプレート アプリ" を使うと、Power BI パートナーやソフトウェア ベンダーは、コードをほとんど、あるいはまったく記述せずに Power BI アプリを作成して、Power BI の顧客に展開できます。

[テンプレート アプリの公開] テナント設定を使うと、Power BI 管理者は、AppSource Microsoft などにより、組織外にテンプレート アプリを公開できるユーザーを制御できます。 ほとんどの組織では、このテナント設定を無効にするか、厳密に制御する必要があります。 "Power BI 外部テンプレート アプリ作成者" のようなセキュリティ グループを使うことを検討しています。

電子メール サブスクリプション

Power BI のレポート、ダッシュボード、ページ分割されたレポートに、自分や他のユーザーをサブスクライブできます。 その後、Power BI は、ユーザーが設定したスケジュールでメールを送信します。 メールには、スナップショットと、レポートまたはダッシュボードのリンクが含まれます。

ワークスペースの管理者、メンバー、または共同作成者は、他のユーザーを含むサブスクリプションを作成できます。 レポートが Premium ワークスペース内にある場合は、グループ (ドメイン内に存在するかどうかに関係なく) と外部ユーザーをサブスクライブできます。 サブスクリプションを設定するときに、項目に対するアクセス許可を付与するオプションもあります。 この目的には項目ごとの直接アクセス許可が使われます。これについては、レポート コンシューマーのセキュリティ計画に関する記事で説明されています。

注意事項

メール サブスクリプション機能では、内部および外部の対象ユーザーとコンテンツが共有される可能性があります。 また、基になるセマンティック モデルに RLS が適用されていると、サブスクライブしているユーザーのセキュリティ コンテキストを使って添付ファイルと画像が生成されます。

[メール サブスクリプション] テナント設定を使うと、Power BI 管理者は、組織全体でこの機能を有効または無効にするかどうかを制御できます。

ライセンスとテナント設定の制限に関連して、添付ファイルに関するいくつかの制限があります。 詳しくは、「Power BI サービスのレポートとダッシュボードのメール サブスクリプション」をご覧ください。

チェックリスト - コンテンツの公開を計画する場合、主な決定事項とアクションは次のとおりです。

• コンテンツを公開する場所、方法、ユーザーの戦略を決定する: コンテンツが公開される場所に関する優先設定と要件を決定します。
• ワークスペースのアクセスを検証する: ワークスペースの設計方法を確認します。 ワークスペース アクセス ロールを使ってコンテンツを公開する場所の戦略をサポートする方法を確認します。
• デプロイ パイプラインのアクセス許可を処理する方法を決定する: デプロイ パイプラインを使ってコンテンツを発行できるユーザーを決定します。 それに応じてデプロイ パイプラインのアクセス許可を設定します。 ワークスペース アクセスも提供されることを確認します。
• XMLA エンドポイントを使用してセマンティック モデルに接続できるユーザーを決定する: XMLA エンドポイントを使ってセマンティック モデルのクエリまたは管理を実行できるユーザーを決定します。 この決定に合わせて、テナント設定 [XMLA エンドポイントとオンプレミスのセマンティック モデルによる "Excel で分析" の許可] を設定します。 この機能を制限する場合は、"Power BI で承認されたコンテンツ作成者" のようなグループを使うことを検討します。
• レポートを一般に公開できるユーザーを決定する: Power BI レポートを公開できるユーザーを決定します (いる場合)。 この決定に合わせて、テナント設定 [Web に公開] を設定します。 "Power BI パブリック公開" のようなグループを使います。
• カスタム アプリにコンテンツを埋め込むことができるユーザーを決定する: Power BI サービスの外部でのコンテンツの埋め込みを許可する必要があるユーザーを決定します。 この決定に合わせて、テナント設定 [アプリにコンテンツを埋め込む] を設定します。
• PowerPoint にコンテンツを埋め込むことができるユーザーを決定する: PowerPoint へのコンテンツの埋め込みを許可する必要があるユーザーを決定します。 この決定に合わせて、テナント設定 [Enable Power BI add-in for PowerPoint] (PowerPoint 用 Power BI アドインを有効にする) を設定します。
• テンプレート アプリを公開できるユーザーを決定する: 組織の外部でテンプレート アプリを使用するための戦略を決定します。 この決定に合わせて、テナント設定 [テンプレート アプリの公開] を設定します。
• サブスクリプションを有効にするかどうかを決定する: サブスクリプションの使用に関する戦略を確認します。 この決定に合わせて、テナント設定 [メール サブスクリプション] を設定します。

データの更新

公開した後、データ作成者は、セマンティック モデルとデータフロー (インポートされたデータを含む) が定期的に更新されるようにする必要があります。 また、セマンティック モデルとデータフローの所有者に関する適切な戦略を決定する必要もあります。

セマンティック モデル所有者

各セマンティック モデルには所有者がいて、これは 1 つのユーザー アカウントです。 セマンティック モデル所有者は、セマンティック モデルの更新を設定し、セマンティック モデルのパラメーターを設定する必要があります。

既定では、セマンティック モデル所有者は、ビルド アクセス許可を必要とするレポート作成者からのアクセス要求も受け取ります (セマンティック モデルの "アクセスの要求の設定" がカスタム手順を提供するように設定されていない場合)。 詳しくは、この記事の「作成者のアクセス要求ワークフロー」セクションをご覧ください。

Power BI では、2 つの方法で、セマンティック モデルを更新するための資格情報を取得できます。

• セマンティック モデル所有者は、セマンティック モデルの設定に資格情報を格納します。
• セマンティック モデル所有者は、セマンティック モデルの設定 (データ ソースと格納された資格情報を含む) 内のゲートウェイを参照します。

別のユーザーが更新やセマンティック モデル パラメーターを設定する必要がある場合は、セマンティック モデルの所有権を取得する必要があります。 セマンティック モデルの所有権は、ワークスペースの管理者、メンバー、または共同作成者が引き継ぐことができます。

注意事項

セマンティック モデルの所有権を取得すると、格納されているセマンティック モデルの資格情報が完全に削除されます。 データ更新操作を再開できるようにするには、資格情報を再入力する必要があります。

セマンティック モデル所有者は、セマンティック モデルを担当するユーザーであることが理想的です。 セマンティック モデル所有者の離織時、または役割が変わったときは、セマンティック モデル所有者を更新する必要があります。 また、セマンティック モデル所有者のユーザー アカウントが Microsoft Entra ID で無効になっている場合、データ更新は自動的に無効になることに注意してください。 この場合、データ更新操作を再開できるようにするには、別のユーザーがセマンティック モデルの所有権を取得する必要があります。

データフロー所有者

セマンティック モデルと同様に、データフローにも所有者がいて、それは単一のユーザー アカウントです。 セマンティック モデル所有者に関して前のトピックで説明した情報とガイダンスは、データフロー所有者にも当てはまります。

チェックリスト - データ更新プロセスに関連するセキュリティを計画する場合、主な決定事項とアクションは次のとおりです。

• セマンティック モデル所有者に関する戦略を決定する: セマンティック モデル所有者の管理に関する優先設定と要件を決定します。
• データフロー所有者に関する戦略を決定する: データフロー所有者の管理に関する優先設定と要件を決定します。
• セマンティック モデル作成者に関するドキュメントとトレーニングに含める: 項目の種類ごとに所有者を管理する方法に関する、データ作成者向けのガイダンスを含めます。

関連するコンテンツ

Power BI の実装の決定に役立つその他の考慮事項、アクション、意思決定基準、推奨事項について詳しくは、検討するサブジェクト領域をご覧ください。