次の方法で共有

Power BI の実装計画: テナント レベルのセキュリティ計画

  • [アーティクル]

注意

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

テナント レベルのセキュリティ計画に関するこの記事は、主に次の方を対象としています。

  • Fabric 管理者: 組織内の Power BI の監視を担当する管理者。
  • センター オブ エクセレンス、IT、BI チーム: Power BI の監視も担当するチーム。 これらのチームは、Power BI の管理者、情報セキュリティ チーム、その他の関連チームと共同で作業することが必要な場合があります。

また、この記事は、ワークスペース内のコンテンツを作成、発行、管理するセルフサービス Power BI の作成者にも関係する可能性があります。

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

Power BI コンテンツはさまざまな方法で使用およびセキュリティ保護できるため、コンテンツ作成者が多くの戦術的な決定を行います。 ただし、テナント レベルで行う戦略的な計画の決定もいくつかあります。 この記事では、これらの戦略的な計画の決定について重点的に説明します。

テナント レベルのセキュリティの決定は、他のすべてに影響を与えるので、できるだけ早く行うことをお勧めします。 また、セキュリティ全体の目標および目的を明確にすると、個々のセキュリティの決定が容易になります。

Power BI 管理

Fabric 管理者は、Power BI の大々的な制御ができる高い特権を持つロールです。 Fabric 管理者は次のような多くの高レベルの機能を実行できるため、誰にこのロールを割り当てるかを慎重に検討することをお勧めします。

  • テナント設定の管理: 管理者は、管理ポータルでテナント設定を管理できます。 設定を有効または無効にすることや、設定に含まれる特定のユーザーまたはグループを許可または禁止することができます。 テナント設定がユーザー エクスペリエンスに大きな影響を与えることを理解しておくことが重要です。
  • ワークスペース ロールの管理: 管理者は、管理ポータルでワークスペース ロールを更新できます。 どのデータにもアクセスできるようにワークスペースのセキュリティを更新することや、Power BI サービスのデータにアクセスする権限を他のユーザーに付与することが考えられます。
  • 個人用ワークスペースへのアクセス: 管理者はコンテンツにアクセスし、任意のユーザーの個人用ワークスペースを管理できます。
  • テナント メタデータへのアクセス: 管理者はテナント全体のメタデータにアクセスできます。Power BI 管理 API によって取得される Power BI のアクティビティ ログやアクティビティ イベントなどです。

ヒント

ベスト プラクティスとして、Fabric 管理者ロールに 2 人から 4 人のユーザーを割り当ててください。 そうすると、十分なカバレッジとクロストレーニングを確保しながら、リスクを軽減できます。

Power BI の管理者は、次の組み込みロールの少なくとも 1 つに割り当てられています。

  • Fabric 管理者
  • Power Platform 管理者
  • 全体管理者 - これは高い特権ロールであり、メンバーシップを制限する必要があります。

管理者ロールを割り当てる際には、ベスト プラクティスに従うことをお勧めします。

Note

Power Platform 管理者は Power BI サービスを管理できますが、その逆はできません。 Fabric 管理者ロールに割り当てられているユーザーは、Power Platform の他のアプリケーションを管理できません。

チェックリスト - どのユーザーを Fabric 管理者にするかを計画する際の主な決定事項とアクションは次のとおりです。

  • 現在誰が管理者ロールを割り当てられているかを特定する: Power BI を管理できるロールのいずれかに割り当てられているのは誰かを確認します。
  • 誰が Power BI サービスを管理するかを決定する: 管理者が多すぎる場合は、合計人数を減らす計画を作成します。 このような高い特権のロールに適していないユーザーが Power BI の管理者として割り当てられている場合は、問題を解決する計画を作成します。
  • 役割と責任を明確にする: それぞれのPower BI の管理者に対し、その責任を明確にします。 適切なクロストレーニングが行われたことを確認します。

セキュリティとプライバシーの戦略

セキュリティとプライバシーに関連するテナント レベルの決定をいくつか行う必要があります。 取られる戦術と下される決定は以下に依存します。

  • データ カルチャ。 目標は、データのセキュリティと保護は全員の責任であることを理解するデータ カルチャを推進することです。
  • コンテンツの所有権と管理の戦略。 一元化されているか分散型かというコンテンツ管理のレベルは、セキュリティをどのように扱うかに大きく影響します。
  • コンテンツの配信スコープに関する戦略。 コンテンツを閲覧するユーザーの数は、コンテンツのセキュリティをどのように扱うかに影響します。
  • 国際的な規制や、国、地域、業界の規制に準拠するための要件。

ここでは、大まかなセキュリティ戦略の例をいくつか示します。 組織全体に影響を与える決定を選択する場合があるでしょう。

  • 行レベル セキュリティの要件: 行レベル セキュリティ (RLS) を使用して、特定のユーザーのデータ アクセスを制限できます。 つまり、同じレポートにアクセスしたとき、異なるユーザーに異なるデータが表示されます。 Power BI セマンティック モデルまたはデータ ソース (シングル サインオンを使用する場合) は、RLS を適用できます。 詳細については、レポート コンシューマーのセキュリティ計画に関する記事の「コンシューマー ID に基づいてデータ セキュリティを適用する」セクションを参照してください。
  • データの検出可能性: Power BI でデータの検出可能性を推奨する範囲を決定します。 検出可能性は、誰がデータ ハブでセマンティック モデルまたはデータマートを検索できるか、およびコンテンツ作成者がアクセス要求ワークフローを使用してそれらのアイテムへのアクセスを要求できるかどうかに影響します。 詳細については、管理されたカスタマイズ可能なセルフサービス BI の使用シナリオを参照してください。
  • Power BI に保存することが許可されているデータ: Power BI に保存すべきでない特定の種類のデータがあるかどうかを決定します。 たとえば、銀行口座番号や社会保障番号などの特定の機密情報の種類をセマンティック モデルに保存できないように指定できます。 詳細については、情報保護とデータ損失防止に関するページを参照してください。
  • 受信プライベート ネットワーク: プライベート エンドポイントを使用した Power BI へのアクセスによるネットワーク分離に関する要件があるかどうかを決定します。 Azure Private Link を使用すると、データ トラフィックはインターネット経由ではなく、Microsoft プライベート ネットワーク バックボーンを使用して送信されます。
  • 送信プライベート ネットワーク: データ ソースに接続するときに、強化したセキュリティが必要かどうかを決定します。 Virtual Network (VNet) データ ゲートウェイを使用すると、Power BI から VNet 内のデータ ソースへの安全な送信接続が可能になります。 コンテンツが Premium ワークスペースに保存されている場合は、Azure VNet データ ゲートウェイを使用できます。

重要

ネットワーク分離を検討している場合は、Power BI テナント設定を変更する前に、IT インフラストラクチャ チームおよびネットワーク チームと協力してください。 Azure Private Link を使用すると、プライベート エンドポイントを介して "受信" セキュリティを強化できます。また、Azure VNet ゲートウェイを使用することで、データ ソースに接続するときの "送信" セキュリティを強化できます。 Azure VNet ゲートウェイはカスタマー マネージドではなく Microsoft によって管理されるため、オンプレミス ゲートウェイのインストールと監視のオーバーヘッドが排除されます。

組織レベルの決定の一部は、特にコンプライアンスに関連する場合に、強固なガバナンス ポリシーにつながります。 その他の組織レベルの決定により、独自のコンテンツの管理とセキュリティ保護を担当するコンテンツ作成者に提供できるガイダンスが得られます。 結果として得られるポリシーとガイドラインを、一元化されたポータル、トレーニング 資料、コミュニケーション計画に含める必要があります。

ヒント

レポート コンシューマーとコンテンツ作成者のセキュリティ計画に関連するその他の提案については、このシリーズの他の記事を参照してください。

チェックリスト - 大まかなセキュリティ戦略を計画する際の主な決定事項とアクションは次のとおりです。

  • セキュリティに関連する規制要件を特定する: コンプライアンスを確保する方法など、各要件を調査して文書化します。
  • 大まかなセキュリティ戦略を特定する: ガバナンス ポリシーに含める必要がある重要なセキュリティ要件はどれかを決定します。
  • 他の管理者と共同作業を行う: 関連するシステム管理者に連絡を取り、どのような方法でセキュリティ要件を満たすか、また、技術的にどのような前提条件が存在するかについて話し合います。 技術的な概念実証を行うための計画を立てます。
  • Power BI テナントの設定を更新する: 関連する各 Power BI テナント設定を指定します。 定期的なフォローアップ レビューをスケジュールします。
  • ユーザー ガイダンスを作成して公開する: 大まかなセキュリティ戦略のドキュメントを作成します。 プロセスの詳細と、ユーザーが標準プロセスからの除外を要求する方法を含めます。 一元化されたポータルとトレーニング資料でこの情報を入手できるようにします。
  • トレーニング資料を更新する: 大まかなセキュリティ戦略に関して、どの要件またはガイドラインをユーザー トレーニング資料に含める必要があるかを決定します。

Microsoft Entra ID との統合

Power BI のセキュリティは、Microsoft Entra テナントを基盤として構築されています。 Power BI テナントのセキュリティに関連する Microsoft Entra の概念を次に示します。

  • ユーザー アクセス: Power BI サービスへのアクセスには、Free、Power BI Pro、または Premium Per User (PPU) のユーザー アカウントが (Power BI ライセンスに加えて) 必要です。 内部ユーザーとゲスト ユーザーはいずれも、Microsoft Entra ID に追加することもオンプレミスの Active Directory (AD) と同期することもできます。 ゲスト ユーザーの詳細については、「外部ユーザーに関する戦略」を参照してください。
  • セキュリティ グループ: Microsoft Entra セキュリティ グループは、Power BI テナント設定で特定の機能を使用できるようにする場合に必要です。 また、Power BI ワークスペースのコンテンツをセキュリティで保護したり、コンテンツを配布したりするために、新しいグループが必要になる場合もあります。 詳細については、「グループの使用に関する戦略」を参照してください。
  • 条件付きアクセス ポリシー: Power BI サービスと Power BI モバイル アプリへの条件付きアクセスを設定できます。 Microsoft Entra の条件付きアクセスで、さまざまな状況での認証を制限できます。 たとえば、次のようなポリシーを適用できます。
    • 一部またはすべてのユーザーに多要素認証を要求する。
    • 組織のポリシーに準拠しているデバイスのみを許可する。
    • 特定のネットワークまたは IP 範囲からの接続を許可する。
    • ドメインに参加していないマシンからの接続をブロックする。
    • 危険なサインオンに対して接続をブロックする。
    • 特定の種類のデバイスのみに接続を許可する。
    • 特定のユーザーの Power BI へのアクセスを条件付きで許可または拒否する。
  • サービス プリンシパル: サービス プリンシパルをプロビジョニングするために、Microsoft Entra アプリ登録の作成が必要になる場合があります。 Power BI 管理者が、Power BI 管理 API を使用してデータを抽出するスケジュールされた無人スクリプトを実行する場合は、サービス プリンシパル認証をお勧めします。 サービス プリンシパルは、カスタム アプリケーションに Power BI コンテンツを埋め込む場合にも役立ちます。
  • リアルタイム ポリシー: リアルタイム セッション制御またはアクセス制御のポリシーを設定する選択もできます。これには、Microsoft Entra ID と Microsoft Defender for Cloud Apps の両方が含まれます。 たとえば、あるレポートに特定の秘密度ラベルが付いている場合に、Power BI サービスでそれをダウンロードすることを禁止できます。 詳細については、情報保護とデータ損失防止に関する記事を参照してください。

無制限のアクセスと過度に制限されたアクセス (ユーザーを不満にする) の間で適切なバランスを見つけることは、難しい場合があります。 最良の戦略は、Microsoft Entra 管理者と協力して、現在設定されている内容を理解することです。 必要な制限に留意しながら、ビジネスのニーズに継続的に対応するようにします。

ヒント

多くの組織には、クラウド内の Microsoft Entra ID と同期するオンプレミスの Active Directory (AD) 環境があります。 この設定はハイブリッド ID ソリューションと呼ばれ、この記事では範囲外です。 理解すべき重要な概念は、Power BI などのクラウドベースのサービスが機能するためには、ユーザー、グループ、サービス プリンシパルが Microsoft Entra ID に存在する必要があることです。 ハイブリッド ID ソリューションは Power BI で機能します。 組織に最適なソリューションについては、Microsoft Entra 管理者に問い合わせることをお勧めします。

チェックリスト - Microsoft Entra 統合のニーズを特定する際の主な決定事項とアクションは次のとおりです。

  • Microsoft Entra 管理者と協力する: Microsoft Entra 管理者と共同作業して、適用されている既存の Microsoft Entra ポリシーを確認します。 Power BI サービスや Power BI モバイル アプリケーションのユーザー エクスペリエンスに影響を与える (現在または計画済みの) ポリシーがあるかどうかを確認します。
  • ユーザー アクセスとサービス プリンシパルをいつ使用するかを決定する: 自動操作のために、ユーザー アクセスではなくサービス プリンシパルをいつ使用するかを決定します。
  • ユーザー ガイダンスを作成または更新する: Power BI ユーザー コミュニティ向けに文書化する必要があるセキュリティ トピックがあるかどうかを確認します。 そうすることで、グループと条件付きアクセス ポリシーの使用について何が予期されるかを知ることができます。

外部ユーザーに関する戦略

Power BI では、Microsoft Entra Business-to-Business (B2B) をサポートしています。 コラボレーションの目的で、外部ユーザー (顧客やパートナー企業など) を Microsoft Entra ID のゲスト ユーザーとして招待できます。 外部ユーザーは、Power BI やその他の多くの Azure および Microsoft 365 サービスを操作できます。

重要

Microsoft Entra B2B ホワイト ペーパーは、外部ユーザーの扱いに関する戦略について学習するのに最適なリソースです。 この記事では、計画に関連した最も重要な考慮事項についてのみ説明しています。

外部ユーザーが別の組織に属していて、そこにも Microsoft Entra ID が設定されている場合は利点があります。

  • 資格情報がホーム テナントで管理される: ID と資格情報の管理はユーザーのホーム テナントで常に制御されます。 ID を同期する必要はありません。
  • ユーザーの状態がホーム テナントで管理される: ユーザーがその組織を離れ、アカウントの削除または無効化が行われるとすぐに、ユーザーは Power BI コンテンツにアクセスできなくなります。 だれがいつ組織を離れたかわからない可能性があるため、これは大きな利点です。
  • ユーザー ライセンスの柔軟性: コスト効率の高いライセンス オプションがあります。 外部ユーザーは既に Power BI Pro または PPU ライセンスを持っている可能性があります。その場合は、それを割り当てる必要はありません。 また、外部ユーザーに Fabric (無料) ライセンスを割り当てることで、Premium 容量、Fabric F64 以上の容量のワークスペース内のコンテンツへのアクセス権を外部ユーザーに付与することも可能です。

重要

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

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

主要な設定

外部ユーザーのアクセス方法の有効化と管理には、次の 2 つの側面があります。

  • Microsoft Entra 管理者によって管理される Microsoft Entra 設定。 これらの Microsoft Entra 設定が前提条件です。
  • 管理ポータルで Power BI 管理者によって管理される Power BI テナント設定。 これらの設定により、Power BI サービスのユーザー エクスペリエンスが制御されます。

ゲストの招待プロセス

テナントにゲスト ユーザーを招待するには、2 つの方法があります。

  • 計画的な招待: Microsoft Entra ID では外部ユーザーを事前に設定できます。 そうすることで、Power BI ユーザーがアクセス許可 (アプリのアクセス許可など) を割り当てるためにゲスト アカウントを使用する必要がある場合はいつでも、ゲスト アカウントの準備が整います。 これには事前の計画が必要ですが、すべての Power BI セキュリティ機能がサポートされているため、最も一貫したプロセスです。 管理者は PowerShell を使用して、多数の外部ユーザーを効率的に追加できます。
  • アドホック招待: Power BI ユーザーが (以前に設定されていない) 外部ユーザーを相手にコンテンツを共有または配布した時点で、Microsoft Entra ID でゲスト アカウントを自動的に生成できます。 この方法は、だれが外部ユーザーになるのかを事前に把握していない場合に役立ちます。 ただし、この機能はまず Microsoft Entra ID で有効にする必要があります。 アドホック招待という方法は、アドホックな項目ごとのアクセス許可とアプリのアクセス許可に使用できます。

ヒント

Power BI サービスのすべてのセキュリティ オプションでアドホック招待をトリガーすることがサポートされているわけではありません。 このため、アクセス許可 (たとえば、ワークスペースのセキュリティ、項目ごとのアクセス許可、アプリのアクセス許可) を割り当てるときのユーザー エクスペリエンスは一貫していません。 可能な限り、計画的な招待を方法として使用することをお勧めします。それによって一貫したユーザー エクスペリエンスが得られるからです。

お客様のテナント ID

すべての Microsoft Entra テナントには、テナント ID と呼ばれるグローバル一意識別子 (GUID) があります。 Power BI では "顧客テナント ID (CTID)" と呼ばれます。 CTID を使用すると、Power BI サービスで別の組織テナントの観点からコンテンツを検索できます。 外部ユーザーとコンテンツを共有する場合は、CTID を URL に追加する必要があります。

CTID を URL に追加する例を次に示します: https://app.powerbi.com/Redirect?action=OpenApp&appId=abc123&ctid=def456

組織の CTID を外部ユーザーに提供する必要がある場合は、Power BI サービスで [Power BI について] ダイアログ ウィンドウを開いて確認できます。 Power BI サービスの右上にある [ヘルプとサポート] (?) メニューから利用できます。 CTID はテナント URL の末尾に追加されています。

顧客テナント ID が強調表示された [Power BI について] ダイアログ ウィンドウのスクリーンショット。

組織のブランド化

外部ゲストのアクセスが組織内で頻繁に行われる場合は、カスタム ブランドを使用することをお勧めします。 これは、どの組織のテナントにアクセスしているかをユーザーが識別するのに役立ちます。 カスタム ブランドの要素として、ロゴ、カバー イメージ、テーマの色があります。

次のスクリーンショットは、ゲスト アカウントがアクセスしたときの Power BI サービスの外観を示しています。 CTID を URL に追加したときに使用できる "ゲストのコンテンツ" オプションが含まれています。

[ゲストのコンテンツ] オプションが強調表示されている Power BI サービスのスクリーンショット。

外部データ共有

組織によっては、外部ユーザーとレポートを共有する以上のことを行う必要があります。 パートナー、顧客、ベンダーなどの外部ユーザーとセマンティック モデルを共有することが予定されています。

インプレース セマンティック モデル共有 ("クロステナント セマンティック モデル共有" とも呼ばれます) の目標は、作成、管理、提供するデータを使用して、外部ユーザーが独自のカスタマイズされたレポートと複合モデルを作成できるようにすることです。 元の (自分が作成した) 共有セマンティック モデルは、自分の Power BI テナントに残ります。 依存レポートとモデルは、外部ユーザーの Power BI テナントに保存されます。

インプレース セマンティック モデル共有が機能するためのセキュリティの側面がいくつかあります。

  • テナント設定: [ゲスト ユーザーが自身のテナントで共有セマンティック モデルを操作できるようにする]: この設定は、外部データ共有機能を使用できるかどうかを指定します。 他の 2 つの設定 (次に示す) のいずれかを有効にするためには、これを有効にする必要があります。 これは Power BI 管理者が組織全体に対して有効または無効にします。
  • テナント設定: [特定のユーザーが外部データ共有を有効にすることを許可する]: この設定は、外部でデータを共有できるユーザーのグループを指定します。 ここで許可されているユーザーのグループは、(次に説明する) 3 番目の設定を使用できます。 この設定は、Power BI 管理者によって管理されます。
  • セマンティック モデル設定: [外部共有]: この設定は、その特定のセマンティック モデルを外部ユーザーが使用できるかどうかを指定します。 この設定は、特定のセマンティック モデルごとにコンテンツ作成者と所有者によって管理されます。
  • セマンティック モデルのアクセス許可: [読み取り] と [ビルド]: コンテンツ作成者をサポートするための標準セマンティック モデル アクセス許可が、引き続き設定されています。

重要

通常、"コンシューマー" という用語は、組織内の他のユーザーによって生成されたコンテンツを使用する閲覧専用ユーザーを指すために使用されます。 ただし、インプレース セマンティック モデル共有では、セマンティック モデルのプロデューサーとセマンティック モデルのコンシューマーがあります。 このような状況では、セマンティック モデルのコンシューマーは通常、他の組織のコンテンツ作成者です。

セマンティック モデルに行レベルのセキュリティが指定されている場合は、外部ユーザーに適用されます。 詳細については、レポート コンシューマーのセキュリティ計画に関する記事の「コンシューマー ID に基づいてデータ セキュリティを適用する」セクションを参照してください。

外部ユーザーのサブスクリプション

前述のように、外部ユーザーは Microsoft Entra ID でゲスト ユーザーとして管理されるのが最も一般的です。 この一般的なアプローチに加えて、Power BI には、組織外のユーザーにレポート サブスクリプションを配布するためのその他の機能が用意されています。

Power BI の [Allow email subscriptions to be sent to external users] (外部ユーザーへのメール サブスクリプションの送信を許可する) というテナント設定は、まだ Microsoft Entra ゲスト ユーザーではない外部ユーザーにユーザーがメール サブスクリプションを送信できるかどうかを指定します。 このテナント設定は、組織が外部ユーザー アカウントの管理をどの程度厳密に、または柔軟に行うかに合わせて設定することをお勧めします。

ヒント

管理者は、レポート サブスクリプションを管理者として取得する API を使用して、どの外部ユーザーにサブスクリプションが送信されているかを確認できます。 外部ユーザーのメール アドレスが表示されます。 外部ユーザーが Microsoft Entra ID で設定されていないため、プリンシパルの種類は "未解決" です。

チェックリスト - 外部ゲスト ユーザーをどのように取り扱うかを計画する際の主な決定事項とアクションは次のとおりです。

  • Power BI での外部ユーザーの要件を特定する: 外部コラボレーションのユース ケースを決定します。 Microsoft Entra B2B で Power BI を使用するシナリオを明確にします。 外部ユーザーとのコラボレーションがよくあるか、まれにしかないかを判断します。
  • 現在の Microsoft Entra 設定を確認する: Microsoft Entra 管理者と共同作業して、外部コラボレーションが現在どのように設定されているかを確認します。 Power BI で B2B を使用するとどのような影響があるかを判断します。
  • 外部ユーザーを招待する方法を決定する: Microsoft Entra 管理者と共同作業して、Microsoft Entra ID でゲスト アカウントを作成する方法を決定します。 アドホック招待を許可するかどうかを決定します。 計画的な招待のアプローチをどの程度使用するかを決定します。 プロセス全体が理解され、文書化されていることを確認します。
  • 外部ユーザーに関するユーザー ガイダンスを作成して公開する: コンテンツ作成者向けのドキュメントを作成し、外部ユーザーとコンテンツを共有する方法をガイドします (特に、計画的な招待プロセスが必要な場合)。 外部ユーザーがコンテンツを編集および管理する場合に外部ユーザーに適用される制限事項に関する情報を含めます。 この情報を一元化されたポータルとトレーニング資料に公開します。
  • 外部データ共有をどのように扱うかを決定する: 外部データ共有を許可するかどうか、それを承認された特定のコンテンツ作成者のセットに限定するかどうかを決定します。 [ゲスト ユーザーが自身のテナントで共有セマンティック モデルを操作できるようにする] テナント設定と、[特定のユーザーが外部データ共有を有効にすることを許可する] テナント設定を、ご自身の決定に合わせて設定します。 セマンティック モデル作成者の外部データ共有に関する情報を提供します。 この情報を一元化されたポータルとトレーニング資料に公開します。
  • 外部ユーザーの Power BI ライセンスをどのように扱うかを決定する: ゲスト ユーザーに既存の Power BI ライセンスがない場合にライセンスを割り当てるプロセスを決定します。 プロセスが文書化されていることを確認します。
  • 関連するユーザー ドキュメントに CTID を記載する: テナント ID (CTID) を追加する URL をユーザー ドキュメントに記録します。 作成者とコンシューマー向けに、CTID を追加する URL の使用方法に関する例を含めます。
  • Power BI でカスタム ブランドを設定する: 管理ポータルで、外部ユーザーが組織のどのテナントにアクセスしているかを識別しやすいように、カスタム ブランドを設定します。
  • テナント設定を確認または更新する: Power BI サービスでテナント設定が現在どのように設定されているかを確認します。 それらを、外部ユーザー アクセスの管理に関する決定に基づいて、必要に応じて更新します。

ファイルの場所に関する戦略

さまざまな種類のファイルがあり、それらを適切に保存する必要があります。 そのため、ファイルとデータの配置場所に関する要件をユーザーが理解しやすいようにすることが重要です。

Power BI Desktop ファイルや Excel ブックに関連するリスクが発生する可能性があります。それらはインポートされたデータを含む可能性があるためです。 このデータには、顧客情報、個人を特定できる情報 (PII)、財産的価値のある情報、または規制やコンプライアンス要件の対象となるデータが含まれます。

ヒント

Power BI サービスの外部に保存されているファイルは、見落とされがちです。 セキュリティを計画するときは、それらを考慮することをお勧めします。

Power BI の実装に関係する可能性があるファイルの種類をいくつか次に示します。

  • ソース ファイル
    • Power BI Desktop ファイル: Power BI サービスに発行されたコンテンツの作成元ファイル (.pbix)。 ファイルにデータ モデルが含まれている場合は、インポートされたデータが含まれている可能性があります。
    • Excel ブック: Excel ブック (.xlsx) には、Power BI サービス内のセマンティック モデルへの接続が含まれる場合があります。 エクスポートされたデータが含まれることもあります。 Power BI サービスに (ワークスペース内のブック項目として) 発行されるコンテンツの作成元ブックである場合もあります。
    • ページ分割されたレポート ファイル: Power BI サービスに発行されたコンテンツの作成元レポート ファイル (.rdl) であるファイル。
    • ソース データ ファイル: Power BI モデルにインポートされたソース データを含むフラット ファイル (.csv や .txt など) または Excel ブック。
  • エクスポートされたファイルとその他のファイル
    • Power BI Desktop ファイル: Power BI サービスからダウンロードされた .pbix ファイル。
    • PowerPoint ファイルと PDF ファイル: Power BI サービスからダウンロードされた PowerPoint プレゼンテーション (.pptx) と PDF ドキュメント。
    • Excel ファイルと CSV ファイル: Power BI サービスのレポートからエクスポートされたデータ。
    • ページ分割されたレポート ファイル: Power BI サービスのページ分割されたレポートからエクスポートされたファイル。 Excel、PDF、PowerPoint がサポートされています。 ページ分割されたレポートには、その他のエクスポート ファイル形式も存在します。Word、XML、Web アーカイブなどです。 レポートへのファイルのエクスポート API を使用する場合は、画像形式もサポートされます。
    • メール ファイル: サブスクリプションのメールの画像と添付ファイル。

ユーザーがファイルを保存できる場所とできない場所について、いくつかの決定を行う必要があります。 通常、そのプロセスには、ユーザーが参照できるガバナンス ポリシーの作成が含まれます。 承認されたユーザーが適切にアクセスできるように、ソース ファイルとエクスポートされたファイルの場所をセキュリティで保護する必要があります。

ファイルの取り扱いに関する推奨事項をいくつか次に示します。

  • 共有ライブラリにファイルを保存する: Teams サイト、SharePoint ライブラリ、あるいは職場または学校用 OneDrive の共有ライブラリを使用します。 個人用のライブラリとドライブは使用しないでください。 ストレージの場所がバックアップされていることを確認します。 また、以前のバージョンにロールバックできるように、ストレージの場所でバージョン管理が有効になっていることを確認します。
  • 可能な限り Power BI サービスを使用する: コンテンツの共有と配布には、可能な限り Power BI サービスを使用してください。 そうすることで、アクセスの完全な監査が常に行われます。 ファイル システムでのファイルの保存と共有は、コンテンツの共同作業を行う少数のユーザーに制限する必要があります。
  • メールを使用しない: ファイルを共有するためのメールの使用はお勧めしません。 Excel ブックまたは Power BI Desktop ファイルを 10 人のユーザーにメールで送信すると、そのファイルのコピーが 10 個作成されます。 常に、誤った (内部または外部の) メール アドレスを含めてしまうリスクがあります。 また、ファイルが他のユーザーに転送されるリスクが高くなります。 (このリスクを最小限に抑えるには、Exchange Online 管理者と協力して、サイズまたはファイル拡張子の種類の条件に基づいて添付ファイルをブロックするルールを実装します。Power BI のその他のデータ損失防止戦略については、情報保護とデータ損失防止に関する記事を参照してください。)
  • テンプレート ファイルを使用する: 場合によっては、Power BI Desktop ファイルを他のユーザーと共有する正当な必要性があります。 その場合は、Power BI Desktop テンプレート (.pbit) ファイルを作成して共有することを検討します。 テンプレート ファイルにはメタデータのみが含まれているため、ソース ファイルよりもサイズが小さくなります。 この手法では、受信者が、モデル データを更新するためにデータ ソースの資格情報を入力する必要があります。

管理ポータルには、Power BI サービスからのエクスポート時にユーザーが使用できるエクスポート形式を制御するテナント設定があります。 これらの設定を確認して設定することが重要です。 これは、エクスポートされたファイルに使用する必要があるファイルの場所を計画するための補完的なアクティビティです。

ヒント

特定のエクスポート形式では、暗号化を使用したエンドツーエンドの情報保護がサポートされています。 規制要件により、一部の組織においては、ユーザーが使用できるエクスポート形式を制限する妥当な必要性があります。 Power BI の情報保護に関する記事では、テナント設定でどのエクスポート形式を有効または無効にするかを決定するときの、考慮すべき要素について説明しています。 ほとんどの場合、エクスポート機能は、特定の規制要件を満たす必要がある場合にのみ制限することをお勧めします。 一般的なシナリオでは、Power BI アクティビティ ログを使用して、どのユーザーがエクスポートを多く実行しているかを特定することをお勧めします。 その後、より効率的で安全な代替手段について、これらのユーザーに教えることができます。

チェックリスト - ラベルのスコープを計画する際の主な決定事項とアクションは次のとおりです。

  • ファイルをどこに配置する必要があるかを特定する: ファイルを保存する場所を決定します。 使用すべきでない特定の場所があるかどうかを判断します。
  • ファイルの場所に関するドキュメントを作成して公開する: ファイルの管理とセキュリティ保護に関する責任を明確にするユーザー ドキュメントを作成します。 それは、ファイルを保存すべき (またはすべきでない) 場所についても説明している必要があります。 この情報を一元化されたポータルとトレーニング資料に公開します。
  • エクスポートのテナント設定を指定する: サポートするエクスポート形式に関連した各テナント設定を確認して設定します。

グループの使用に関する戦略

次の理由から、Microsoft Entra セキュリティ グループを使用して Power BI コンテンツをセキュリティで保護することをお勧めします。

  • メンテナンスの削減: セキュリティ グループのメンバーシップは、Power BI コンテンツのアクセス許可を変更しなくても変更できます。 新しいユーザーをグループに追加したり、不要なユーザーをグループから削除したりできます。
  • 正確性の向上: グループ メンバーシップの変更は 1 回で済むため、アクセス許可の割り当てがより正確になります。 エラーが検出された場合は、より簡単に修正できます。
  • 委任: グループ メンバーシップを管理する責任をグループ所有者に委任できます。

グループに関する大まかな決定事項

グループをどのように使用するかについて、いくつかの戦略的な決定を行う必要があります。

グループを作成して管理するためのアクセス許可

グループの作成と管理に関する 2 つの重要な決定事項があります。

  • グループの作成を許可されているユーザー 一般に、セキュリティ グループを作成できるのは IT 部門のみです。 ただし、組み込みの "グループ管理者" Microsoft Entra ロールにユーザーを追加することはできます。 そうすることで、Power BI チャンピオンや COE のサテライト メンバーのような特定の信頼されているユーザーは、自身のビジネス ユニットのグループを作成できます。
  • グループのメンバーを管理できるユーザー IT 部門がグループ メンバーシップを管理するのが一般的です。 ただし、グループ メンバーの追加と削除を許可されている 1 人以上の "グループ所有者" を指定できます。 セルフサービス グループ管理を使用すると、分散したチームまたは COE のサテライト メンバーが Power BI 固有のグループのメンバーシップを管理できる場合に役立ちます。

ヒント

セルフサービス グループ管理を許可し、分散したグループ所有者を指定することは、効率や速度とガバナンスのバランスを取るための優れた方法です。

Power BI グループの計画

Power BI コンテンツやその他多くの用途をセキュリティで保護するためのグループの使用方法について、大まかな戦略を作成することが重要です。

グループのさまざまなユース ケース

次のようなグループのユース ケースを考慮します。

ユース ケース 説明 グループ名の例
Power BI センター オブ エクセレンス (COE) とのコミュニケーション COE のすべてのコア メンバーとサテライト メンバーを含む、COE に関連付けられているすべてのユーザーが含まれます。 必要に応じて、コア メンバーのみの別個のグループを作成することもできます。 考えられるものとして、Teams サイトと関連付けられた Microsoft 365 グループがあります。 • Power BI センター オブ エクセレンス
Power BI リーダーシップ チームとのコミュニケーション 組織の Power BI の取り組みを主導することについて共同作業を行う、ビジネス ユニットのエグゼクティブ スポンサーと代表者が含まれます。 • Power BI 推進委員会
Power BI ユーザー コミュニティとのコミュニケーション 任意の種類の Power BI ユーザー ライセンスが割り当てられているすべてのユーザーが含まれます。 組織内のすべての Power BI ユーザーに通知を行う場合に便利です。 考えられるものとして、Teams サイトと関連付けられた Microsoft 365 グループがあります。 • Power BI コミュニティ
Power BI ユーザー コミュニティのサポート Power BI サポートの問題を処理するためにユーザー コミュニティと直接やり取りするヘルプ デスク ユーザーが含まれます。 このメール アドレス (該当する場合は Teams サイト) をユーザー全体が使用および表示できます。 • Power BI のユーザー サポート
エスカレートされたサポートの提供 エスカレートされたサポートを提供する特定のユーザーが (通常は Power BI COE から) 含まれます。 このメール アドレス (および該当する場合は Teams サイト) は、通常はプライベートであり、ユーザー サポート チームのみが使用します。 • Power BI のエスカレートされたユーザー サポート
Power BI サービスの管理 Power BI サービスの管理を許可されている特定のユーザーが含まれます。 必要に応じて、このグループのメンバーを Microsoft 365 のロールに関連付けて、管理を簡略化できます。 • Power BI 管理者
許可された機能の通知と機能の段階的なロールアウト 管理ポータルで特定のテナント設定に対して許可されているユーザー (機能が制限される場合)、または機能をユーザー グループに段階的にロールアウトする場合が含まれます。 多くのテナント設定で、新しい Power BI 固有のグループを作成する必要があります。 • Power BI ワークスペース作成者

• Power BI 外部データ共有
データ ゲートウェイの管理 ゲートウェイ クラスターの管理を許可されている 1 つ以上のユーザー グループが含まれます。 複数のゲートウェイがある場合、または分散したチームがゲートウェイを管理する場合は、この種類のグループが複数存在する可能性があります。 • Power BI ゲートウェイ管理者

• Power BI ゲートウェイ データ ソース作成者

• Power BI ゲートウェイ データ ソース所有者

• Power BI ゲートウェイ データ ソース ユーザー
Premium 容量を管理する Premium 容量の管理を許可されたユーザーが含まれます。 複数の容量がある場合、または分散したチームが容量を管理する場合は、この種類のグループが複数存在する可能性があります。 • Power BI 容量の共同作成者
ワークスペース、アプリ、項目のセキュリティ保護 サブジェクト領域と、Power BI ワークスペース ロール、アプリのアクセス許可、項目ごとのアクセス許可のセキュリティを管理するために許可されているアクセスに基づいた、多数のグループ。 • Power BI ワークスペース管理者

• Power BI ワークスペース メンバー

• Power BI ワークスペース共同作成者

• Power BI ワークスペース閲覧者

• Power BI アプリ閲覧者
コンテンツのデプロイ Power BI デプロイ パイプラインを使用してコンテンツをデプロイできるユーザーが含まれます。 このグループは、ワークスペースのアクセス許可と組み合わせて使用します。 • Power BI デプロイ パイプライン管理者
管理操作の自動化 埋め込みまたは管理の目的で Power BI API を使用することを許可されているサービス プリンシパルが含まれます。 • Power BI サービス プリンシパル

Power BI テナント設定のグループ

設定されている内部プロセスに応じて、必要なグループが他にもあります。 こそらのグループは、テナント設定を管理するときに役立ちます。 次に例をいくつか示します。

  • Power BI ワークスペース作成者: だれがワークスペースを作成できるかを制限する必要がある場合に便利です。 [ワークスペースの作成] テナント設定のセットアップに使用します。
  • Power BI 認定の領域の専門家: コンテンツに対する認定済みの推奨の使用をだれに許可するかを指定する場合に便利です。 これは、[認定] テナント設定のセットアップに使用します。
  • Power BI で承認されたコンテンツ作成者: Power BI Desktop のインストール、あるいは Power BI Pro または PPU ライセンスの取得のために、承認、トレーニング、またはポリシー確認が必要な場合に便利です。 [Power BI セマンティック モデルへの DirectQuery の接続を許可する]、[アプリをエンド ユーザーにプッシュする]、[XMLA エンドポイントを許可する] など、コンテンツ作成機能を勧めるテナント設定で使用します。
  • Power BI 外部ツール ユーザー: 選択的なユーザー グループに対して外部ツールの使用を許可する場合に便利です。 グループ ポリシーで使用するか、ソフトウェアのインストールや要求を慎重に制御する必要がある場合に使用します。
  • Power BI カスタム開発者: Power BI 外部の他のアプリケーションへのコンテンツ埋め込みをだれに許可するかを制御することが必要な場合に便利です。 [アプリにコンテンツを埋め込む] テナント設定のセットアップに使用します。
  • Power BI パブリック発行: データを公開できるユーザーを制限する必要がある場合に便利です。 [Web に公開] テナント設定のセットアップに使用します。
  • 組織全体への Power BI 共有: 組織内のすべてのユーザーとリンクを共有できるユーザーを制限する必要がある場合に便利です。 [共有可能なリンクへのアクセス権を組織内のすべてのユーザーに付与する] テナント設定のセットアップに使用します。
  • Power BI 外部データ共有: 特定のユーザーに外部ユーザーとのセマンティック モデル共有を許可する必要がある場合に便利です。 [特定のユーザーが外部データ共有を有効にすることを許可する] テナント設定のセットアップに使用します。
  • ライセンスが付与された Power BI ゲスト ユーザー アクセス: 組織からライセンスが付与されている承認済みの外部ユーザーをグループ化する必要がある場合に便利です。 これは、[Allow Microsoft Entra guest users access to Power BI] (Microsoft Entra ゲスト ユーザーに Power BI へのアクセスを許可する) テナント設定のセットアップに使用します。
  • Power BI ゲスト ユーザー アクセス BYOL: 自宅組織からライセンスを持ち込む (BYOL) 承認済みの外部ユーザーをグループ化する必要がある場合に便利です。 これは、[Allow Microsoft Entra guest users access to Power BI] (Microsoft Entra ゲスト ユーザーに Power BI へのアクセスを許可する) テナント設定のセットアップに使用します。

ヒント

ワークスペースへのアクセスを計画する際の、グループの使用に関する考慮事項については、ワークスペース レベルの計画に関する記事を参照してください。 ワークスペース、アプリ、項目をセキュリティで保護するための計画の詳細については、レポート コンシューマーのセキュリティ計画に関する記事を参照してください。

グループの種類

さまざまな種類のグループを作成できます。

  • セキュリティ グループ: セキュリティ グループは、リソースへのアクセスを許可することが主な目標である場合に最適な選択肢です。
  • メールが有効なセキュリティ グループ: リソースへのアクセス権を付与し、メールでグループ全体にメッセージを配布する必要がある場合は、メールが有効なセキュリティ グループが適しています。
  • Microsoft 365 グループ: この種類のグループには、Teams サイトとメール アドレスがあります。 これは、Teams サイトでのコミュニケーションまたはコラボレーションが主な目標である場合に最適な選択です。 Microsoft 365 グループにはメンバーと所有者のみが存在し、閲覧者ロールはありません。 このため、その主な目的はコラボレーションです。 この種類のグループは、以前は Office 365 グループ、モダン グループ、または統合グループと呼ばれていました。
  • 配布グループ: 配布グループを使用してユーザーの一覧にブロードキャスト通知を送信できます。 現在、これは下位互換性を提供する従来の概念と見なされています。 新しいユース ケースでは、代わりにメールが有効なセキュリティ グループを作成することをお勧めします。

新しいグループを要求する場合、または既存のグループを使用する場合は、その種類に注意することが重要です。 グループの種類によって、グループの使用方法と管理方法が決まることがあります。

  • Power BI のアクセス許可: あらゆる種類のセキュリティ操作ですべての種類のグループがサポートされているわけではありません。 セキュリティ グループ (メールが有効なセキュリティ グループを含む) は、Power BI セキュリティ オプションの設定に関して最も高いカバレッジを実現します。 Microsoft ドキュメントでは、通常、Microsoft 365 グループをお勧めしています。 ただし、Power BI の場合は、セキュリティ グループほどの機能はありません。 Power BI のアクセス許可の詳細については、セキュリティ計画に関するこのシリーズの後続の記事を参照してください。
  • Power BI テナント設定: セキュリティ グループ (メールが有効なセキュリティ グループを含む) は、Power BI テナント設定を操作することをユーザー グループに許可または禁止する場合にのみ使用できます。
  • 高度な Microsoft Entra 機能: 特定の種類の高度な機能は、すべての種類のグループではサポートされていません。 たとえば、Microsoft 365 グループでは、グループ内のグループの入れ子はサポートされていません。 一部のグループの種類では、Microsoft Entra ID のユーザー属性に基づく動的グループ メンバーシップがサポートされていますが、動的メンバーシップを使用するグループは Power BI ではサポートされていません。
  • 別の方法で管理する: グループの作成または管理の要求は、グループの種類に基づいて別の管理者にルーティングされる場合があります (メールが有効なセキュリティ グループと配布グループは Exchange で管理されます)。 そのため、内部プロセスはグループの種類によって異なります。

グループの名前付け規則

Power BI の実装をサポートするために、Microsoft Entra ID に多くのグループを作ることになる可能性があります。 したがって、グループの名前付け方法について合意されたパターンを持つことが重要です。 適切な名前付け規則は、グループの目的を判断し、管理を簡単にするのに役立ちます。

次の標準的な名前付け規則を使用することを検討してください: <プレフィックス><目的> - <トピック、スコープ、部署><[環境]>

名前付け規則の各部分の説明を次に示します。

  • プレフィックス: すべての Power BI グループをグループ化するために使用します。 グループを複数の分析ツールで使用する場合、プレフィックスは Power BI ではなく単に BI になる可能性があります。 その場合、目的を説明するテキストは、複数の分析ツールに対応するように、より汎用的になります。
  • 目的: 目的はさまざまです。 これは、ワークスペース ロール、アプリのアクセス許可、項目レベルのアクセス許可、行レベルのセキュリティ、またはその他の目的の場合があります。 1 つのグループで複数の目的を満たすことができる場合があります。
  • トピック、スコープ、部署: グループが適用されるユーザーを明確にするために使用します。 多くの場合、グループ メンバーシップについて説明します。 また、グループを管理するユーザーを参照することもできます。 1 つのグループを複数の目的のために使用できる場合があります。 たとえば、財務ワークスペースのコレクションを 1 つのグループで管理できます。
  • 環境: オプション。 開発、テスト、運用を区別するのに役立ちます。

標準の名前付け規則を適用したグループ名の例を次に示します。

  • Power BI ワークスペース管理者 - 財務 [開発]
  • Power BI ワークスペース メンバー - 財務 [開発]
  • Power BI ワークスペース共同作成者 - 財務 [開発]
  • Power BI ワークスペース閲覧者 - 財務 [開発]
  • Power BI アプリ閲覧者 - 財務
  • Power BI ゲートウェイ管理者 - エンタープライズ BI
  • Power BI ゲートウェイ管理者 - 財務

グループごとの決定事項

どのグループが必要かについて計画するときは、いくつかの決定を行う必要があります。

コンテンツ作成者または所有者が新しいグループを要求している場合、フォームを使用して次の情報を提供してもらうのが理想的です。

  • 名前と目的: グループ名の提案とその目的。 グループのスコープを明確に示すために、グループ名に Power BI (または複数の BI ツールがある場合は BI のみ) を含めることを検討してください。
  • メール アドレス: グループ メンバーへの連絡も必要な場合のメール アドレス。 すべての種類のグループでメールを有効にする必要はありません。
  • グループの種類: オプションには、セキュリティ グループ、メールが有効なセキュリティ グループ、Microsoft 365 グループ、配布グループなどがあります。
  • グループ所有者: グループのメンバーを所有および管理できるユーザー。
  • グループ メンバーシップ: グループのメンバーになることが意図されているユーザー。 外部ユーザーと内部ユーザーを追加できるかどうか、または外部ユーザーを別のグループに配置するための正当な理由があるかどうかを検討します。
  • Just-In-Time グループ メンバー割り当ての使用:Privileged Identity Management (PIM) を使用して、グループに対するタイムボックス方式の Just-In-Time アクセスを許可できます。 このサービスは、ユーザーが一時的なアクセスを必要とする場合に役立ちます。 PIM は、時折アクセスする必要がある Power BI 管理者にも役立ちます。

ヒント

組織図に基づく既存のグループは、Power BI の目的のために常に適切に機能するとは限りません。 既存のグループがニーズを満たしている場合は、それを使用します。 ただし、必要に応じて Power BI 固有のグループを作成する準備をしてください。

チェックリスト - グループの使用方法に関する戦略を作成する際の主な決定事項とアクションは次のとおりです。

  • グループの使用に関する戦略を決定する: グループを使用するために必要なユース ケースと目的を決定します。 ユーザー アカウントを使用してセキュリティを適用する場合と、グループが必要または望ましい場合について具体的に確認します。
  • Power BI 固有のグループの名前付け規則を作成する: Power BI のコミュニケーション、機能、管理、またはセキュリティをサポートするグループに対して、一貫した名前付け規則が使用されていることを確認します。
  • だれにグループの作成を許可するかを決定する: すべてのグループ作成が IT 部門を経由する必要があるかどうかを明確にします。 または、特定の個人 (COE のサテライト メンバーなど) に、自身のビジネス ユニットのグループを作成するアクセス許可を付与できるでしょうか。
  • 新しいグループを要求する方法に関するプロセスを作成する: ユーザーが新しいグループの作成を要求するためのフォームを作成します。 新しい要求に迅速に応答するプロセスが存在することを確認します。 要求に時間がかかると、ユーザーは個人アカウントへのアクセス許可の割り当てを始めようとする可能性があることに注意してください。
  • どの場合に分散グループ管理を許可するかを決定する: 特定のチームに適用するグループについて、(IT 部門の外部の) グループ所有者がグループのメンバーを管理できるのはどのような場合かを決定します。
  • Just-In-Time グループ メンバーシップを使用するかどうかを決定する: Privileged Identity Management が役に立つかどうかを判断します。 そうである場合は、どのグループに使用できるかを決定します (Power BI 管理者グループなど)。
  • 現時点で存在するグループを確認する: 使用できる既存のグループと、作成する必要があるグループを特定します。
  • 各テナント設定を確認する: テナント設定ごとに、特定のユーザー セットに対して許可するか禁止するかを決定します。 テナント設定のセットアップのために新しいグループを作成する必要があるかどうかを判断します。
  • グループに関するユーザー向けのガイダンスを作成して公開する: グループを使用するための要件や設定を含むコンテンツ作成者向けのドキュメントを含めます。 新しいグループを要求するときに依頼する内容が確実にわかるようにします。 この情報を一元化されたポータルとトレーニング資料に公開します。

関連するコンテンツ

このシリーズの次の記事では、読み取り専用のレポート コンシューマーにコンテンツを安全に配布する方法について説明します。