次の方法で共有

Power BI 実装計画: テナント管理

  • [アーティクル]

Note

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

この記事では、Fabric テナントを管理するための重要な考慮事項について説明します。 この記事の対象者は次のとおりです。

  • Fabric 管理者: 組織の Fabric 監視を担当する管理者。
  • IT 管理者とシステム管理者: Fabric 管理者と共同作業を行い、組織内のシステムを監視および統合する他の管理者。
  • センター オブ エクセレンス (COE)、BI チーム: 組織内で Power BI を監視し、Power BI ユーザーのサポートを担当するチーム。 これらのチームは、重要な決定を行い、Fabric 管理者と共同作業します。

Power BI サービスの管理は、システム監視の重要な側面の 1 つです。 詳細については、システム監視に関する記事を参照してください。 システム監視に関連する日常的なアクティビティは、一般にシステム管理と呼ばれています。 システム管理アクティビティは、コンテンツ コンシューマーとコンテンツ作成者が常に Power BI で優れたエクスペリエンスを得られるようにするために重要です。

Fabric 導入の成熟度レベルに関する記事で説明したように、組織への導入とは、エンタープライズ BI と管理されたセルフサービス型の BI をサポートして有効にするためのガバナンスおよびデータ管理の実施の有効性を指します。 そのため、分析と BI プラットフォームを管理する管理者は、分析の導入の取り組みの成功に大きな影響を及ぼす可能性があります。

Note

Fabric 容量 (または Premium 容量) の管理と Power BI サービスの管理は、異なる概念です。 ほとんどの組織には Power BI テナントが 1 つだけありますが、組織は異なるワークロードまたはビジネス ユニットに対して複数の容量をプロビジョニングできます。

重要

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

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

責任範囲の定義

Fabric 管理者ロールには単一の定義がないため、Fabric 管理者ロールと日常的な責任は、組織によって異なる可能性があります。 変えてはいけないことは、組織の優先順位と目標が変化するにつれて、その役割は時間の経過と同時に進化できるものであり、また進化すべきであるということです。

戦略的な観点からは、Fabric 管理者は次の内容に重点を置く必要があります。

  • ガバナンス: ガバナンスのガイドラインとポリシーを施行してエンタープライズ BI と管理されたセルフサービス型の BIをサポートします。
  • ユーザー エンパワーメント: 内部のユーザー コミュニティに可能な限り権限を与える内部のプロセスとシステムの実現を促進してサポートするのと同時に、組織の規制や要件に準拠します。
  • 導入: 効果的なガバナンスとデータ管理の実施により、Fabric をより幅広く組織的に導入できるようにします。

ガバナンス、ユーザーのエンパワーメント、導入目標のバランスを取ろうとすると、本質的に優先順位が競合する競合することにつながります。 理想的には、優先順位に関する生産的な議論につながります。 さまざまな役割と責任に対する期待を明確にし、伝えることで、許容できないレベルの摩擦と競合を回避できます。

次の 3 つの Fabric 管理者の例について考えてみましょう。

  • ユーザーの有効化に重点を置く: Riley は、管理されたセルフサービス型の BI に多大な投資を行っている大規模なグローバル組織で働く Fabric 管理者です。 組織全体のユーザーにセルフサービス BI 機能を有効にするために、Riley はセンター オブ エクセレンス (COE) やその他の管理者との意思決定とアクションの調整に多くの時間を費やしています。 必要に応じ、Riley は既存の BI ソリューションをサポートします。
  • ガバナンスとコンプライアンスに重点を置く: Parker は、厳しく規制された組織で働く Fabric 管理者です。 この組織では、ほとんどの BI 開発は、一元化されたエンタープライズ BI チーム内の BI 開発者が処理します。 Parker の管理責任は、主に監査、情報保護、セキュリティなどの領域に焦点を当てています。
  • コンテンツ作成への高い関与: Morgan は、データ カルチャの構築を開始したばかりの小規模な組織で働く Fabric 管理者です。 現在、組織には数名のコンテンツ作成者しかいません。 システム監視の責任に加えて、Morgan は定期的にコンテンツを作成して公開する BI 開発者です。 Morgan は、同僚を指導するために、組織内の BI の専門知識を成長させるのに役立つ共同開発プロジェクトに参加する場合もあります。

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

  • 戦略的フォーカスの決定: Fabric 管理者の戦略的フォーカスを決定します。 意思決定 (およびトレードオフ) を行う必要がある場合に使用する目標と優先順位を明確にします。
  • 特定の役割と責任の特定: Fabric 管理者に期待される具体的な役割を決定します。 役割と責任を明確にドキュメント化し、必要に応じて人事部とともにジョブの説明を更新します。

管理者の任命

Fabric 管理者のアクションは、ユーザー エクスペリエンス、データ カルチャの取り組み、ガバナンスの取り組み、コンテンツを所有および管理するユーザー、組織の導入の取り組みに大きな影響を与えます。 そのため、適切なユーザーを管理者ロールに任命することが重要です。

管理者を選択する場合に考慮すべき重要なポイントをいくつか次に示します。

  • 高い権限を持つロールの性質への意識を維持する。 管理者ロールには、さまざまなテナント設定、ワークスペース アクセス、個人用ワークスペース アクセスを管理する権限があり、すべてのテナント メタデータを表示できるため、高い権限を持つロールです。 詳細については、「Power BI 管理」をご覧ください。
  • 管理者として適任のユーザーを慎重に選択します。 管理者は、多くの場合、ユーザーと COE と共同作業する必要があります。 このため、ビジネス インテリジェンスの概念とユーザーが達成する必要がある内容を理解する必要があります。 威圧的な性格の人や、ユーザーに許可することを厳密に制限する傾向がある人は、セルフサービス BI プラットフォームの管理に適していない可能性があります。
  • 2 ~ 4 人の管理者を選択します。 これは、高い権限を持つロールであるため、数人の管理者のみを任命します。 適切なバランスを取る: 管理者が多すぎると未承認の変更が発生するリスクが高まり、管理者が少なすぎると、システムが十分にサポートされないリスクが高まります。
  • 一時管理者を許可します。 Fabric 管理者権限が "時折" 必要なユーザーがいる場合は、Privileged Identity Management (PIM) を実装することを検討してください。 PIM を使用すると、数時間後に有効期限が切れるジャストインタイムのロール アクセス許可を割り当てられます。 このプロセスにより、リスク (常勤管理者が多すぎること) と使いやすさ (進行状況の発生を許可する) のバランスを取るのに役立つ方法が提供されます。 これは特に、大規模で分散化された組織に当てはまります。 PIM を使用すると、管理者ロールの委任がログに記録され、必要に応じて権限を付与するための承認ワークフローが含まれる場合があります。
  • Fabric の管理を優先します。 多くの場合、BI プラットフォームの管理は、多くの責任の 1 つに過ぎません。 ユーザーを適切にサポートし、システムを十分に管理する方法を検討してください。
  • 誰が関連するすべてのロールに割り当てられているかを定期的に確認します。 Power BI サービスの管理が許可されているロールには、Fabric 管理者、Power Platform 管理者、グローバル管理者の 3 つがあります。 これらのロールのメンバーシップを定期的に監査することが重要です。

詳細については、Microsoft 365 管理センターの管理者の役割について を参照してください。

チェックリスト – 管理者を任命する場合、主な決定事項とアクションは次のとおりです。

  • 現在の Fabric 管理者の特定: 現在 Fabric 管理者のロールに割り当てられているユーザーを確認します。 また、このレビューでは、Power Platform 管理者ロールとグローバル管理者ロールについても検討してください。
  • Fabric 管理者の任命: リスクを軽減するために、Fabric 管理者ロールに 2 人から 4 人を任命します。 現在、4 人以上のユーザーが割り当てられている場合は、Fabric 管理者ロールに割り当てられているユーザーの数を減らします。
  • 一時管理者に PIM を使用する: Fabric 管理者権限が正当に、ただし時折必要なユーザーがいるかどうかを特定します。 PIM を実装して、数時間後に有効期限が切れるジャストインタイムのロール アクセス許可を割り当てます。 承認ワークフローを含むプロセスのしくみを文書化し、伝達します。
  • バックアップの割り当てとクロストレーニングの実施: Fabric 管理の責任を扱うために、導入されているクロストレーニングとドキュメントの状態を確認します。 一貫した方法でタイムリーにユーザーの優先的なニーズを満たすことができるように、必ずバックアップ担当者がトレーニングされているようにします。
  • 管理者の定期的な監査: Fabric 管理者ロールに割り当てられているユーザーを定期的に確認します。

他の管理者と共同作業する

Fabric 管理者は高い権限を持つロールですが、Fabric の管理に限定されます。 そのため、場合によっては、他の管理者と共同作業する必要があります。

Fabric 管理者が他のシステム管理者と共同作業する一般的な理由を次に示します。

  • デバイスのセットアップとインストール: ユーザー デバイスをインストール、更新、または管理するには、IT、インフラストラクチャ チームやデスクトップ サポート チームと連携することが必要になる場合があります。
  • サブスクリプションとライセンス購入: サブスクリプションの管理とライセンスの購入には、Microsoft 365 の課金管理者ロールが必要です。 また、課金管理者がコスト分析と管理を担当する場合もあります。 ライセンスを一元化および分散化 (セルフサービス) する方法の詳細については、「ユーザー ライセンス」を参照してください。
  • ライセンスの割り当てとユーザー管理: 特定のユーザーにライセンス (購入済み) を割り当てるには、Microsoft 365 のライセンス管理者ロールが必要です。 ユーザーのプロパティを管理するには、ユーザー管理者ロールが必要です。 ユーザー プロパティ (ライセンスの自動割り当てやグループの自動割り当てなど) に基づいて自動化を実装する予定の場合は、ユーザー管理者と連携すると便利です。 詳細については、「よく使用される Microsoft 365 管理センターの役割」を参照してください。
  • Microsoft Entra 管理者: Microsoft Entra 管理者と連携する必要がある理由さまざまな理由があります。 多くの場合の理由として、ユーザー、グループ、サービス プリンシパルを設定または管理する必要があります。 詳しくは、「テナント レベルのセキュリティ計画」を参照してください。
  • ソース データ アクセス: コンテンツ作成者に代わってデータにアクセスするには、システム管理者やデータベース管理者と連携する必要がある場合があります。 場合によっては、セマンティック モデルがコンテンツ コンシューマーの ID に基づいてデータ セキュリティを強化場合に、コンテンツ コンシューマーに代わってアクセスを要求することが必要になる場合もあります。
  • データ損失防止とデータ分類: ガバナンスと情報保護のために、Microsoft Purview 管理者と共同作業する必要がある場合があります。
  • Teams の統合: Power BI と Microsoft Teams を統合する場合は、Teams 管理者と共同作業する必要がある場合があります。
  • OneDrive と SharePoint の統合: Power BI を OneDrive または SharePoint と統合する場合は、他の管理者と共同作業する必要がある場合があります。
  • ワークスペースの管理: 特定のワークスペース内のコンテンツを計画、整理、またはセキュリティで保護するには、Fabric ワークスペース管理者と共同作業する必要がある場合があります。
  • ライフサイクル管理: コンテンツに対する変更をデプロイおよび管理する際に、デプロイ パイプライン管理者または Azure DevOps 管理者と共同作業する必要がある場合があります。
  • Premium 容量管理: Premium 容量を管理する場合は、容量管理者と共同作業する必要がある場合があります。
  • データ ゲートウェイの管理: オンプレミスのデータ ゲートウェイを管理およびセキュリティで保護するために、ゲートウェイ管理者と共同作業する必要がある場合があります。 詳細については、「ゲートウェイの管理」を参照してください。
  • Power Platform の管理: Power BI と他の Power Platform アプリ (Power Automate や Power Apps など) の間でソリューションを統合する必要がある場合があります。
  • Azure の管理: Power BI と統合する他の Azure サービス を設定し、アクセスし、セキュリティで保護するには、Azure 管理者と連携する必要がある場合があります。
  • セキュリティ管理と監査: 組織は、特定のコンプライアンス、セキュリティ、またはプライバシー要件を持つ場合があります。 この場合、リスクの特定および軽減のために、セキュリティ チームと共同作業する必要がある場合があります。
  • ネットワーク: 異なるデータ ソースやシステムに接続する場合は、パフォーマンスとセキュリティ上の理由からネットワーク管理者と連携する必要がある場合があります。
  • モバイル デバイスの管理: モバイル デバイス ポリシーとセキュリティを管理するには、Intune 管理者と共同作業する必要がある場合があります。

重要

Fabric 管理者は、独自に決定したり (テナント設定の変更など)、アクションを実行したりしないでください。 すべての重要な決定は、議論し、計画し、文書化する必要があります。 他の管理者との共同作業に加えて、COE と BI 戦略作業チームを十分に関与させるようにしてください。 また、戦略的な意思決定のためにエグゼクティブ スポンサーを関与させることが適切な場合もあります。

チェックリスト – 他の管理者と共同作業する場合、主な決定事項とアクションには次のとおりです。

  • デバイスのセットアップとインストールを管理するユーザーの決定: 組織のデバイスを管理するユーザーを把握したことを確認します。 そのプロセスと要件をよく理解しておいてください。 必要に応じて連携できるように準備します。
  • サブスクリプションとライセンスを管理するユーザーの特定: 組織のサブスクリプションとライセンスを管理するユーザーを把握したことを確認します。 そのプロセスと要件をよく理解しておいてください。 必要に応じて連携できるように準備します。
  • ライセンスを割り当て、ユーザー、グループ、サービス プリンシパルを管理するユーザーの特定: 組織のユーザー、グループ、サービス プリンシパルを管理するユーザーを把握したことを確認します。 そのプロセスと要件をよく理解しておいてください。 必要に応じて連携できるように準備します。
  • 相談する他の管理者の決定: 実装計画プロセスを進める際に、関連する他の管理者を特定します。 関連する会議に招待し、関連する意思決定プロセスに参加させます。 必要に応じてドキュメントとプロセスを更新します。

Power BI サービスの管理

Power BI サービスの管理は、Fabric 管理者の重要な責任の 1 つです。 このセクションでは、Fabric 管理ポータルで多くの一般的な設定と機能を管理する方法について説明します。

テナント設定の管理

テナント設定は、どの Power BI 機能を、組織内のどのユーザーに対して有効にするかを制御する主な方法です。 テナント設定の管理は、Fabric 管理者にとって最も重要な役割の 1 つです。

コンテンツ作成者とコンテンツ コンシューマーは、Power BI で利用できる機能について (ドキュメントから) 簡単に学習できるため、期待した操作を行えないと不満が生じる可能性があります。 これは、ユーザーの不満や、組織への導入、ユーザーへの導入、ソリューションへの導入における効果の低下につながる可能性があります。

こちらに、混乱して不満を感じているユーザーからよく寄せられる質問を示します。

  • ワークスペースを作成できないのはなぜですか?
  • データをエクスポートできないのはなぜですか?
  • カスタム ビジュアルが機能しないのはなぜですか?
  • セマンティック モデルを認証できないのはなぜですか?
  • 秘密度ラベルを割り当てることができないのはなぜですか?
  • 特定のエンド ユーザーにアプリをプッシュできないのはなぜですか?

重要

各テナント設定は、組織内のガバナンス ガイドラインとポリシーに合致させる必要があります。 どの設定を有効または無効にするかを Fabric 管理者が独自に決めている場合、それは、ガバナンス プロセスを改善して洗練させる必要があることを示す明確なインジケーターになります。

このセクションの残りの部分では、テナント設定を管理するための次のプロセスについて説明します。

  1. テナント設定を確認する
  2. テナント設定を決定する
  3. テナント設定を更新する
  4. ドキュメントのテナント設定
  5. テナントの設定の管理
  6. テナント設定を監査する

手順 1: テナント設定を確認する

各テナント設定を確認して、テナントの現在の状態を明確に理解することが重要です。 すべてのテナント設定を確認する必要がある一方で、リスク評価に基づいて、特定の重要な設定に優先順位を付けて最初に確認する場合もあります。

レビュー プロセス中に考慮すべきいくつかの要因を次に示します。

  • 設定: 特定のテナント設定は現在有効か無効か。
  • アクセス許可: 特定のテナント設定は組織全体に適用されますか? または、特定のセキュリティ グループで使用できるか、それとも拒否されますか?

Note

一部のテナント設定は既定で有効になっていますが、他の設定は既定で無効になっています。

テナント設定の現在の状態は、2 つの方法のいずれかでコンパイルできます。

次の表に、テナント設定の現在の状態を記録する方法を示します。

最終確認日 テナント設定 現在値 許可されたセキュリティ グループ 許可されていないセキュリティ グループ 他の管理者に委任されたテナント設定
2023 年 10 月 15 日 ワークスペースを作成する 特定のセキュリティ グループに対して有効 Power BI ワークスペース作成者、Power BI 管理者、Power BI COE、Power BI サポート 該当なし 該当なし
2023 年 10 月 15 日 Excel にエクスポート 特定のセキュリティ グループを除外した組織全体に対して有効 該当なし 営業チーム-ヨーロッパ 該当なし
2023 年 11 月 1 日 ワークスペース間でセマンティック モデルを使用する 組織全体に対して有効にする 該当なし 該当なし 該当なし
2023 年 11 月 1 日 [認定](#certification-phase) 特定のセキュリティ グループに対して有効 Power BI 認定の領域の専門家 (SME) 該当なし ドメイン管理者は有効または無効にできます
2023 年 11 月 5 日 特定のユーザーが外部データ共有を有効にすることを許可する 特定のセキュリティ グループに対して有効 Power BI 外部データ共有 該当なし 該当なし

セキュリティ グループに関するその他の考慮事項については、「Power BI グループの計画」を参照してください。

許可されるテナント設定の状態の詳細については、「テナント設定の使用方法」を参照してください。

注意事項

管理者がテナントを監視した際に、理想的ではない状況が検出される場合があります。 たとえば、ユーザー アクティビティ データのデータ エクスポートが多すぎる場合があります。 この場合、管理者は関連するテナント設定を無効にしたいと考えるかもしれません。 ただし、機能を完全に無効にする前に、まずユーザーが特定の手法に依存している理由を理解しておくことが重要です。 これは、機能を禁止すると、ユーザーが不満を感じて回避策を作成しようとする可能性があるためです。 代わりに、ソリューションを再設計する必要性や、ユーザーの教育とトレーニングをさらに進めることで、問題が軽減される可能性があることを検討してください。

手順 2:テナント設定を決定する

現在のテナント設定を確認したら、次に意思決定プロセスを確認します。 テナント設定ごとに、ワークショップを使用して、許可または禁止する必要がある機能とユーザーについて積極的に議論して決定します。

すべてのテナント設定はガバナンスの決定を表すことに注意してください。 そのため、適切な決定を行うために他のユーザーと共同作業する必要があります。 状況によっては、意思決定プロセスには、COE、エグゼクティブ スポンサー、セキュリティ チーム、BI チーム、またはその他 (利害関係者やチャンピオンなど) との共同作業が含まれる場合があります。

ヒント

最大の課題の 1 つは、既存のテナント設定と目標目的に向けた決定の間に矛盾が発生した場合の対応を決定することです。 このような競合が発生した場合に解決する準備をしてください。

意思決定プロセス中に考慮すべきいくつかの要因を次に示します。

  • どのようなガバナンス上の決定が既に存在しますか? 可能な場合は、既存の決定事項を参照してください。 一貫性があり、効率的であることを常に目指してください。 また、内部または外部のコンプライアンス要件も認識しておく必要があります。 該当する場合、テナント設定は、より広範なガバナンス ポリシーと合致する必要があります。 たとえば、現在のガバナンス ポリシーには、組織外でデータを共有できるタイミング、ユーザー、方法が指定されているかもしれません。
  • 新しいガバナンスの決定を行うのは誰ですか? テナント設定に関する決定を行う必要がある場合は、すべての関係者を会話に参加させます。 通常、Fabric 管理者だけでは、テナント設定に関する決定を行うのに最適な立場にありません。 作業チームの編成とワークショップの実行については、BI 戦略計画を参照してください。
  • 決定は一時的なものですか? テナント設定が短い期間だけ設定される場合があります。 通常、これは、COE、BI、および IT チームが組織全体でより広範にリリースされる前に、新機能に慣れる時間を確保するために行われます。 そうすることで、ガバナンス ガイドラインとの整合性を確認でき、ユーザー コミュニティが適切にサポートされます。
  • 部署やチームによって処理方法は異なりますか? 大きな組織では、単一のアプローチでうまくいくことはほとんどありません。 さまざまなチームのニーズとスキルに対応するために、対象ユーザーごとにテナント設定を変える必要がある場合があります。 ガバナンス ガイドライン内で、有能なチームが可能な限り柔軟に運用できるようにすることを常に目指してください。
  • 承認プロセスはありますか? 特定のテーマによっては、承認が必要な場合があります。 これは、テナント設定がセキュリティまたはコンプライアンスに関連する場合に特に当てはまります。
  • 各決定を再確認するスケジュールにはどのようなものがありますか? 各テナント設定の決定の確認を定期的にスケジュールします。 この目的には、年に 2 回のスケジュールが適しています。

次の表に、決定を記録する方法を示します。

決定日 意思決定 関与した意思決定者 決定の承認者 影響を受けるテナント設定 保留中の操作
2023 年 10 月 15 日 COE は、承認されたコンテンツ作成者に対して、ワークスペースの作成と管理に関するベスト プラクティスについてトレーニングを行います。 承認された作成者は、どの部署に所属していてもかまいません。 COE と利害関係者 Ellis Turner (エグゼクティブ スポンサー) と Taylor Phillips (COE リーダー) ワークスペースを作成する Power BI ワークスペース作成者グループの既存のメンバーを確認する
2023 年 10 月 15 日 Excel へのエクスポートが許可されます。 COE はアクティビティ ログ内のアクションを追跡し、それを使い過ぎたユーザーに連絡します。 現在調査中の問題により、営業チーム (ヨーロッパ) には一時的な制限が存在します。 COE とセキュリティ Ellis Turner (エグゼクティブ スポンサー) と Jessie Irwin (最高技術責任者) Excel にエクスポート 60 日以内のヨーロッパの問題をフォローアップ
2023 年 11 月 1 日 データの再利用を促進し、データ サイロを最小限に抑え、データの重複を減らすために、共有セマンティック モデルを使用することを強くお勧めします。 COE Ellis Turner (エグゼクティブ スポンサー) ワークスペース間でセマンティック モデルを使用する 該当なし
2023 年 11 月 1 日 COE は、承認されたコンテンツ作成者に対して、レポートとデータ資産を認定するためのプロセスと要件に関するトレーニングを行います。 承認された作成者は、どの部署に所属していてもかまいません。 COE と利害関係者 Ellis Turner (エグゼクティブ スポンサー) と Taylor Phillips (COE リーダー) [認定](#certification-phase) Power BI 認定の領域 (SME) グループの既存のメンバーを確認する
2023 年 11 月 5 日 組織のデータ共有ポリシーは、データを組織の外部で共有する方法をカバーしています。 すべてのユーザーは、毎年このポリシーを確認し、承認する必要があります。 COE のトレーニングは、Power BI での作業時にユーザーが遵守するのに役立ちます。 COE、セキュリティ、コンプライアンス Jessie Irwin (最高技術責任者) 特定のユーザーが外部データ共有を有効にすることを許可する Power BI 外部データ共有グループの既存のメンバーを確認する

決定が行われた理由を説明する他のコンテキスト情報を含めることを検討してください。 また、既存の関連ドキュメントまたはポリシーの場所へのリンクも含まれます。

Note

表に示されている例は、ユーザーへの権限付与、コンプライアンス、内部要件のバランスを取る方法を意図的に示しています。 その他の考慮事項については、「ガバナンス」を参照してください。

手順 3: テナント設定を更新する

既存のテナント設定と目的に合った意思決定を利用できるようになったので、テナント設定を更新する準備ができました。

更新プロセス中の考慮事項は次のとおりです。

  • 更新プログラムは誰が処理しますか? 複数の Fabric 管理者がいる場合は、1 人または 2 人の Fabric 管理者が主にテナント設定の更新を担当することが理想的です。 目標は、プロセスに一貫性があり、よく理解され、適切に制御されていることを確認することです。
  • どのようなテスト プロセスが実施されていますか? テナント設定によっては、変更すると他の効果が発生する可能性があります。 広範な変更を行う前に、テストを実施してください。 例については、「ワークスペース全体でセマンティック モデルの使用を制御する」を参照してください。
  • 変更管理プロセスはありますか? 決定、ドキュメント、および結果の更新の間の不一致を回避する方法を検討してください。 チーム間のコミュニケーションは、変更管理における重要な成功要因です。 監査要件によっては、誰が、いつ、何のために変更したかを記録するために内部変更ログを保持することもできます (アクティビティ ログで取得録された内容以上の詳細を記録するため)。
  • ユーザーとの通信はどのように処理されますか? ユーザーができることに影響を与える変更を行う場合は、必ず変更を伝達してください。 ユーザーの不満や不要なサポート リクエストを回避することを常に目指してください。

手順 4: ドキュメントのテナント設定

この時点で、テナントの設定値を文書化するための反復可能な方法があることを確認してください。 簡略化された例については、テナント設定の確認に関する上記の手順 1 の表を参照してください。

ドキュメントで考慮すべき側面をいくつか示します。

  • スナップショット データの抽出: テナント設定の値を文書化するときは、新しいポイントインタイム スナップショットを定期的に作成することをお勧めします。 このため、週に 1 回スナップショットを作成することをお勧めします。 テナント設定の取得 REST API を使用して、プロセスを自動化します。
  • スナップショット データへの管理者アクセス権の付与: 管理者、COE、内部監査担当者は、すべてのスナップショット データにアクセスできる必要があります。 変更されたテナント設定を特定するには、2 つのスナップショットを比較します (例: 今週と先週の比較)。 アクティビティ ログのデータは、スナップショット データを補完して、いつ、誰が、何を変更したかを完全に把握できます。 詳細については、テナント設定の監査に関する以下の手順 6 を参照してください。
  • 現在の設定の概要のユーザーへの提供: テナント設定値は、一元化されたポータルのユーザーのコミュニティで使用できるドキュメントの種類の 1 つです。 これは、たとえば、機能が利用できない理由を理解していないユーザーにとって参考になります。 このドキュメントは、機能を使用する必要がある場合に、どのセキュリティ グループに参加を要求するかをユーザーが把握するのにも役立ちます。 手作業を削減するために、REST API の最新のスナップショット結果を Power BI レポートとしてユーザーに配布できます。 ニーズによっては、データのスナップショットを、手動で保持している他のデータ (テナント設定の説明、設定の理由、追加情報へのリンク、アクセス要求フォームへのリンクなど) とマージする必要がある場合があります。

Note

前述の手順 2 で説明したように、意思決定プロセスに関連するドキュメントもあります。 通常、この種のドキュメントは、(すべての Power BI ユーザーではなく) COE と管理者のみが使用できます。 簡略化された例については、手順 2 を参照してください。

手順 5: テナントの設定の管理

テナントの設定には、継続的な注意が必要です。 考慮すべき側面をいくつか示します。

  • 新しいテナント設定: 新しいテナント設定を使用できるタイミングを把握するにはどうすればいいですか? Fabric は進化を続けるクラウド サービスであるため、新しいテナント設定が定期的に導入されることを期待できます。 新しいテナント設定を認識する 1 つの方法は、管理ポータルのテナント設定ページの上部に通知されたメッセージを表示することです。 もう 1 つの方法は、現在のスナップショットから抽出したデータを前のスナップショットと比較することです (前述の手順 4 で説明)。
  • 既存のテナント設定に対する変更: 既存のテナント設定の動作がいつ変更されたかを把握するにはどうすればいいですか? テナント設定の変更は、通常、Power BI ブログまたは Fabric ブログで通知されます。 通知を認識できるようにするには、これらのブログをフォローしてください。
  • 継続的なユーザー要求: ユーザー要求を管理するにはどうすればいいですか? たとえば、コンテンツを認定するユーザーは、コンテンツを許可する特定のセキュリティ グループのメンバーになるための要求を送信することを把握しています。 これは、(上記の手順 4 で説明したように) ユーザーが参照できるようにテナント設定のドキュメントを公開することで可能になる効果的なワークフローです。 この種の要求を収集するためにフォームを使用することもできます。 または、ヘルプ デスク経由で要求を ルーティングすることもできます。
  • 新しいセキュリティ グループ: テナント設定を特定のセキュリティ グループに限定する場合、適切なセキュリティ グループは既に存在しますか? または、新しいセキュリティ グループを作成する必要がありますか? 必要に応じて新しいセキュリティ グループを作成するために調整するにはどうすればいいですか? 詳細については、「グループの使用に関する戦略」を参照してください。

手順 6: テナント設定を監査する

最後に、テナント設定を定期的に監査するプロセスを用意することが重要です。 テナント設定を監査するタイミングを特定するためのアクションを次にいくつか示します。

  • テナント設定が変更されました:UpdatedAdminFeatureSwitch アクティビティを使用して、アクティビティ ログで変更された値を検索します。 このアクティビティは、何かが更新されたこと (有効か無効か、別のセキュリティ グループが割り当てられているかなど) を示すだけです。 変更内容を理解するには、現在のスナップショットを前のスナップショットと比較する必要があります (前述の手順 4 で説明)。
  • 新しいテナント設定が導入されました: 管理ポータルでメッセージを検索するか、現在のスナップショットから抽出したデータを前のスナップショット (前述の手順 4 で説明) と比較します。
  • グループ メンバーシップが変更されました: 状況によっては、割り当てられているセキュリティ グループを把握するのに十分でない場合があります。 個々のユーザーとサービス プリンシパルを構成できるセキュリティ グループのメンバーシップを決定する必要がある場合があります。 Microsoft Graph を使用して、グループ メンバーシップ データを取得できます。 詳細については、「ユーザーとグループのデータ」を参照してください。

また、テナント設定が更新されたときにアラート通知を受け取ることもできます。 Microsoft 365 または Microsoft Defender for Cloud Apps の監査ログ アラート機能を使用して、テナント設定が変更されたときに通知を受け取ることができます。また、誰が UpdatedAdminFeatureSwitch 監査ログ イベントを使用して通知を受け取るかを確認できます。 アラートの有効化について詳しくは、テナントレベルの監査に関する記事を参照してください。

チェックリスト - テナント設定の計画と管理を行う場合の主な決定事項とアクションは次のとおりです。

  • 現在のすべてのテナント設定を確認する: すべてのテナント設定を確認して、現在の状態を決定します。 各設定に割り当てられているセキュリティ グループを特定します。
  • 既存のポリシーと意思決定を特定する: 既存のガバナンス ポリシーまたは以前の決定をコンパイルして、すぐに使用できるようにします。
  • 話し合いと決定: ワークショップをスケジュールして、許可または禁止する必要がある内容とユーザーを決定します。 すべての決定が、データ カルチャの目標、ガバナンス ガイドライン、および内部ポリシーと一致していることを確認します。 各トピックごとに、関連するすべての意思決定者と利害関係者が関与するようにしてください。 必要に応じて追加の承認を得てください。
  • 意思決定を再確認するスケジュールを作成する: 意思決定とテナント設定を定期的に再確認するスケジュールを設定します (年に 2 回など)。
  • 更新を行う: ワークショップで行われた決定に基づいてテナント設定を更新します。
  • API を使用してスナップショットデータを抽出する: テナント設定の取得 REST API を使用してプロセスをより効率的にし、スケジュールに基づいてスナップショットの作成を自動化する可能性があります。
  • ユーザーのドキュメントを作成する: ユーザーコミュニティのテナント設定のドキュメントを作成します。 ドキュメントを一元化されたポータルに公開します。 機能にアクセスするためにユーザーが属する必要があるセキュリティ グループを含めます。
  • ユーザー要求を処理するプロセスを作成する: ユーザーが機能へのアクセスを要求する方法のプロセスを設定します。
  • テナント設定を定期的に管理するためのプロセスを設定する: できるだけ早く新しいテナント設定を特定できるようにスケジュールを作成します。
  • 監査の設定: 監査プロセスを作成して、テナント設定がいつ変更され、誰が変更したかを追跡できるようにします。

ドメインの管理

ドメインは、Fabric で同様の特性を持つ 2 つ以上のワークスペースをグループ化するために使用されます。 たとえば、すべての販売ワークスペースをグループ化する 1 つのドメインと、財務ワークスペース用の別のドメインを作成することが考えられます。 ドメインは、単一の管理境界を表します。 ドメインを使用すると、組織全体に分散されるワークスペースの所有権と管理責任を促進することもできます。

ドメインの計画の詳細については、「ワークスペース ドメイン」を参照してください。

ヒント

このセクションで説明する Fabric ドメインは、Microsoft 365 のドメインとは異なる概念です。

手順 1: ドメインを確認する

最初の手順は、既存のドメインとテナント環境を確認して、現在の状態を把握できるようにすることです。 レビュー プロセス中に考慮すべきいくつかの要因を次に示します。

  • ドメイン: 存在する場合、どのドメインですか? 各ドメインの名前と説明はその目的を明確に示していますか?
  • アクセス許可: それぞれのドメイン管理者は誰ですか? 各ドメインのドメイン共同作成者は誰ですか? 割り当てられたすべての管理者と共同作成者は、ドメインの目的に合致していますか?
  • 割り当てられたワークスペース: 各ドメインに割り当てられているワークスペースはどれですか? 割り当てられたワークスペースはすべて、ドメインの目的と合致していますか?
  • 委任されたテナント設定: 既定の設定をオーバーライドできるように、ドメイン管理者 (または容量管理者) に委任されているテナント設定はどれですか?

手順 2: ドメインの決定

ドメインを確認したら、次に意思決定プロセスを確認します。

既存のワークスペースでは、単一の管理境界を形成するためにグループ化する方法を検討してください。 関連するワークスペースを整理する方法の詳細については、「ワークスペース ドメイン」を参照してください。

意思決定プロセス中に考慮すべきいくつかの要因を次に示します。

  • どのようなガバナンス上の決定が既に存在しますか? 可能な場合は、既存の決定事項を参照してください。 一貫性があり、効率的なワークスペースとドメイン設定を目指してください。
  • コンテンツの所有権と管理はどのように分散化されますか? 現在、組織全体でコンテンツの所有権と管理がどのように行われているか検討してください。 分散化されたアプローチは、"分散型"、"フェデレーション"、または "データ メッシュ" アーキテクチャと呼ばれる場合があります。 ワークスペースをドメイン別に整理するニーズを分析する場合は、その情報を考慮に入れてください。
  • どのようなドメインのグループ分けが効果的ですか? ワークスペースを単一の管理境界にグループ化するには、さまざまな方法があります。 たとえば、サブジェクト領域、チーム、部署、プロジェクトごとにドメインを整理することを選択できます。 ワークスペースは 1 つのドメインにしか割り当てられないことに注意してください。 詳細については、「ワークスペース ドメイン」を参照してください。
  • 誰に各ドメインの管理者の権限を付与する必要がありますか? 理想的には、ドメイン管理者はドメインのコンテンツを直接所有および管理するユーザーです。 また、ドメイン管理者は、サブジェクト領域の内部、地域、および政府の規制に精通している必要があります。 すべての内部ガバナンスとセキュリティの要件についても精通している必要があります。
  • 誰にドメインへのワークスペースの割り当てを許可するか。 ドメイン共同作成者ロールには、ワークスペースをドメインに割り当てることが許可されているユーザーが含まれます。 ドメイン共同作成者は、ワークスペースをドメインに割り当てるワークスペース管理者である必要もあります。 組織内のセルフサービス ユーザーにどの程度の制御を委任するか検討してください。
  • ドメインによって処理方法は異なりますか? 大規模な組織では、ドメインによってポリシーが異なる場合があります。 さまざまなチームのニーズとスキルに基づいて決定を調整する準備をしてください。 詳細については、「テナント レベルの設定をオーバーライドする」を参照してください。

手順 3: ドメインの更新

この時点で、既存のドメイン設定と目的に応じた決定を利用できます。 これで、ドメインの追加、変更、削除の準備が整いました (必要な場合)。

既存の変更管理プラクティスに従い、変更の影響を受けるすべてのユーザーに通知してください。

手順 4: ドメインの文書化

ドメインの数によっては、管理ポータルで利用可能な情報を補強するためにドキュメントを作成する場合があります。 ドキュメントには次のような内容が含まれる可能性があります。

  • ドメインの目的、別ドメインが有益な理由など、より詳細なコンテキストや詳細。
  • 誰が、いつ、そのドメインを承認したのか。
  • ドメイン所有者またはスチュワードは誰か (管理ポータルで設定されたドメイン管理者と異なる場合)。
  • ドメインに関連するその他のコンプライアンスまたは規制要件。

手順 5: ドメインの管理

ドメインは、管理ポータルで定期的に確認する必要があります。 この目的の場合は、四半期ごと、あるいは年に 2 回が効果的です。

また、新しいドメインの作成、既存のドメインの変更、またはドメインへのワークスペースの追加を希望するユーザーからの要求をどのように管理するかも検討してください。

手順 6: ドメインの監査

ドメインとその設定を定期的に監査するプロセスを持つ必要があります。 ここでは、アクティビティ ログを使用してドメインを監査する場合に特定するためのアクションをいくつか示します。

  • 新しいドメインが作成されました: InsertDataDomainAsAdmin アクティビティを検索します。
  • 既存のドメインが変更されました: UpdateDataDomainAsAdmin アクティビティを検索します。
  • ワークスペースがドメインに割り当てられました: UpdateDataDomainFoldersRelationsAsAdmin アクティビティを検索します。
  • ドメイン管理者またはドメイン共同作成者が変更されました: UpdateDataDomainAccessAsAdmin アクティビティを検索します。

チェックリスト - ドメインを計画および管理するときの、主要な決定事項とアクションは次のとおりです。

  • 現在のドメインを確認する: 管理ポータルですべてのドメインを確認して現在の状態を決定します。
  • 話し合いと決定: ニーズを満たすのに最適なドメインのグループ化の方法を決定します。 ドメインの管理方法を検討する場合は、関係する意思決定者や利害関係者も関与させてください。
  • 承認が必要かどうかを確認する: 新しいドメインの作成時に他のユーザーの承認を得るプロセスを存在させる必要があるかを決定します。
  • 再確認のスケジュールを作成する: 定期的にドメインを再確認するスケジュールを設定します。
  • 更新を行う: 新しいニーズが発生した場合にドメインを更新します。
  • ドキュメントの作成: 他の情報を記録する必要がある場合は、ドメインのドキュメントを作成します。
  • ユーザー要求を処理するプロセスを作成する: ユーザーが新しいドメインを要求する方法のプロセスを設定します。
  • 監査の設定: 監査プロセスを作成して、新しいドメインの作成時、または変更の発生時に追跡できるようにします。

ワークスペースを管理する

ワークスペースは Fabric の基本的な概念です。 ワークスペースは、コンテンツを格納しセキュリティで保護するためのコンテナーとして機能します。 主に、ワークスペースはコンテンツの作成、コラボレーション、コンテンツの配布向けに設計されています。

管理ポータルのワークスペース ページを使用することで、Fabric 管理者はテナント内のすべてのワークスペースを確認および管理できます。

Fabric 管理者がワークスペースの管理に関与する理由を次にいくつか示します。

  • 標準ワークスペースへのアクセスを取得します。 Fabric 管理者は、コンテンツの主な所有者が休暇中などで不在の場合、(データ更新エラーなどの) 状況を支援する必要がある場合があります。 その場合は、ワークスペース ロールに自分自身を割り当てる必要があります。
  • 個人用ワークスペースへの一時的なアクセスを取得します。 Fabric 管理者は、別のユーザーの個人用ワークスペースにアクセスできますが、24 時間のみです。 個人用ワークスペースへの一時的なアクセスは、ワークスペース所有者が組織を離れた場合や休暇中の場合に役立ちます。
  • ワークスペースのロールを管理します。 Fabric 管理者には、テナント内のすべてのワークスペースのワークスペース ロールを管理するアクセス許可があります。 これは、一元化されたチームがワークスペース アクセスを管理する場合に役立ちます。 また、雇用の終了または転送の結果として発生する可能性がある孤立した状態 (ワークスペース管理者がいないことを示す) にワークスペースがある場合にも役立ちます。
  • ワークスペースを再割り当てします。 他の機能のロックを解除するには、ワークスペースのワークスペースのライセンス モードを更新する必要がある場合があります。 たとえば、Fabric 管理者は、ワークスペースを Pro またはPremium Per User (PPU) から容量に変更できます。
  • ワークスペースの種類を決定します。 Fabric 管理者は、ワークスペースが 割り当てられている SKU レベルを確認できます。 たとえば、管理者は、現在 PPU に割り当てられているテナントに 4 つのワークスペースがあることをすぐに確認できます。
  • 削除されたワークスペースの検索や復元。 ワークスペースの状態は、ワークスペースが削除されたことを示すことができます。 しばらくの間、Fabric 管理者は、誤って削除された場合にワークスペースを復元できます。 または、削除された個人用ワークスペースを標準ワークスペースとして復元することもできます。 詳細については、「ワークスペースの保持期間」を参照してください。
  • ワークスペース名を更新します。 ワークスペースの名前が確立された名前付け規則に準拠していないため、Fabric 管理者はワークスペースの名前を変更できます。

Note

ワークスペースの管理に関与するレベルは、Fabric 管理者に割り当てられている役割と責任によって異なります。 コンテンツの所有権と管理の戦略は、Fabric 管理者がワークスペース管理にどの程度関与するかにも影響を与える可能性があります。

手順 1: ワークスペースを確認する

最初の手順は、既存のワークスペースとテナント環境を確認して、現在の状態を把握できるようにすることです。 レビュー プロセス中に考慮すべきいくつかの要因を次に示します。

  • 現在のワークスペース: 現在存在するすべてのワークスペースを確認します。 また、各ワークスペースのロールの割り当てと設定が適切であることを確認することも必要です。
  • 現在のテナント設定: [ワークスペースの作成] テナント設定の現在の設定を確認します。

現在のワークスペースの一覧をコンパイルするには、2 つの方法があります。

  • 管理ポータルでワークスペースの一覧を表示します。 リストは CSV ファイルにエクスポートできます。
  • 次の機能を使用して、管理者 API を使用してテナント インベントリをプログラムで抽出します。
    • メタデータ スキャン API (スキャナー API とも呼ばれます)。 この一連の API を使用すると、変更されたワークスペースを非同期で検索できます。 これは、段階的に変更されたワークスペースを抽出できるため、多数のワークスペースを持つ大規模な組織に最適です。 詳細については、「メタデータ スキャン API」を参照してください。
    • 管理者としてグループを取得 REST API または Get-PowerBIWorkspace PowerShell コマンドレット。 これらのメソッドは、テナント内のすべてのワークスペースのデータを返すため、データ ボリュームが少ない小規模な組織に最適です。 詳細については、「グループ API またはワークスペース コマンドレット」を参照してください。

手順 2: ワークスペースを決定する

ワークスペースを確認したら、次に意思決定プロセスを確認します。

意思決定プロセス中に考慮すべきいくつかの要因を次に示します。

  • どのようなガバナンス上の決定が既に存在しますか? 可能であれば、既存のワークスペース ガバナンスの決定を参照してください。 ワークスペース設定に一貫性があり、効率的に行われることを目指してください。
  • 誰がワークスペースを作成できるようにする必要がありますか? ワークスペース作成のアクセス許可はデータ カルチャであり、ガバナンス上の決定であることを考慮してください。
  • ワークスペースを作成するための特定のプロセスが必要ですか? ユーザーが従うのに簡単で便利な ワークスペース作成プロセス を確立することが重要です。
  • ワークスペースの名前はどのように付ける必要がありますか? ワークスペースの名前付け規則が組織にとって有益かどうかを判断します。
  • ワークスペースはどのように整理されますか? 多くの場合、件名とスコープ別にワークスペースを整理することが役立ちます。 コンテンツをワークスペースに整理する方法は、部門によって異なる可能性があります。
  • 個人用ワークスペースに含まれるコンテンツはどのくらいですか? 組織内で個人用ワークスペースをどのように使用するのが適切か検討してください。
  • 誰がワークスペースにアクセスできるようにする必要がありますか? コンテンツを作成および管理するユーザーには、主にワークスペースのアクセスを制限する必要があります。 詳細については、コンテンツ作成者のセキュリティ計画に関する記事を参照してください。

詳細な考慮事項については、テナント レベルのワークスペース計画とワークスペース レベルのワークスペース計画に関するページを参照してください。

手順 3: ワークスペースの更新

この時点で、既存のワークスペースと目的に応じた決定を利用できます。 名前の変更または再構成するワークスペースを検出した場合は、必要な調整を行う準備ができました。

更新プロセス中の考慮事項は次のとおりです。

  • 更新プログラムは誰が処理しますか? 複数の Fabric 管理者がいる場合は、ワークスペースが 1 つまたは 2 つの特定の管理者によって管理されているかどうかを判断します。 プロセスに一貫性があり、よく理解され、適切に制御されていることを確認してください。
  • 変更管理プロセスはありますか? 決定、ドキュメント、および結果の更新の間の不一致を回避する方法を検討してください。 チーム間のコミュニケーションは、変更管理における重要な成功要因です。 監査要件によっては、誰が、いつ、何のために変更したかを記録するために内部変更ログを保持することもできます (アクティビティ ログで取得録された内容以上の詳細を記録するため)。
  • ユーザーとの通信はどのように処理されますか? ユーザーができることに影響を与える変更を行う場合は、必ず変更を伝達してください。 ユーザーの不満や不要なサポート リクエストを回避することを常に目指してください。

手順 4: ワークスペースの文書化

ワークスペースの数によっては、管理ポータルまたは REST API で利用可能な情報を補強するためにドキュメントを作成する場合があります。 この種のドキュメントは、テナント インベントリの重要な部分です。 ドキュメントには次のような内容が含まれる可能性があります。

  • ワークスペースの使用目的など、より詳細なコンテキストまたは詳細 (ワークスペースの説明にまだメンションされていない場合)。
  • 誰が、いつワークスペースを承認したか。
  • 所有者がワークスペース管理者と異なる場合、ワークスペース所有者として割り当てられているユーザー。
  • ワークスペースに格納されているコンテンツに関連するコンプライアンスまたは規制要件。
  • ワークスペースに特に機密性の高い情報が含まれているかどうか。
  • ワークスペースのガバナンス要件。
  • ワークスペースに適用できるライフサイクル管理プロセス。

手順 5: ワークスペースを管理する

ワークスペースの継続的な管理には、主に次のような内容が含まれます。

  • 新しいワークスペースの作成。
  • ワークスペース メタデータ (名前や説明など) の更新。
  • ワークスペース ロールの更新。
  • 削除されたワークスペースの修復。
  • ワークスペースの再割り当て (Pro から PPU など)。
  • [ワークスペースの作成] テナント設定の管理。

役割と責任に応じて、セカンダリ管理者のアクティビティは次のとおりです。

  • コンテンツ (セマンティック モデルやレポートなど) のワークスペースへの公開。
  • 既存のワークスペース コンテンツに関連する問題のトラブルシューティング。

重要

Fabric 管理者ロールは、多くの上位階層機能を実行できる高い権限を持つロールです。 特に、ロールによってテナント内のすべてのデータへのアクセスが自動的に付与されるわけではありません。 ただし、管理者にはテナント内のワークスペースを管理する権限があるため、自分自身を含む他のユーザーに (ワークスペース ロールを介して) アクセス権を付与できます。

手順 6: ワークスペースを監査する

ワークスペースを定期的に監査するプロセスが必要です。 ここでは、アクティビティ ログを使用してワークスペースを監査する場合に特定するためのアクションをいくつか示します。

  • ワークスペースの作成 テナント設定が変更されました: UpdatedAdminFeatureSwitch アクティビティを使用して、アクティビティ ログで変更されたテナント設定の値を検索します。 項目名は CreateAppWorkspaces になります。
  • Fabric 管理者がユーザーの個人用ワークスペースへのアクセス権を取得しました: AddAdminPersonalWorkspaceAccess アクティビティを検索します。 ワークスペース名は PersonalWorkspace-NameOfUser の形式になります。 システムが自動的にアクセスを取り消した場合、24 時間後に発生するアクティビティはログに記録されません。
  • 新しいワークスペースが作成されました: CreateFolder アクティビティを検索します。
  • 既存のワークスペースが変更されました: UpdateFolder アクティビティを検索します。
  • ワークスペースへのアクセスが変更されました: UpdateWorkspaceAccess アクティビティまたは UpdateFolderAccess アクティビティを検索します。
  • ワークスペースが再割り当てされました: MigrateWorkspaceIntoCapacity アクティビティを検索します。
  • ワークスペースがドメインに割り当てられました: UpdateDataDomainFoldersRelationsAsAdmin アクティビティを検索します。

ヒント

アクティビティ ログの使用に加えて、テナント インベントリを定期的に作成することをお勧めします。 これは、ある時点のスナップショットであり、すべてのワークスペースとそのコンテンツ (セマンティック モデルやレポートなど) が記述されています。 また、ワークスペース アクセスに関する詳細を取得することもできます。 詳細については、「テナント インベントリと「テナント インベントリ データにアクセスする」を参照してください。

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

  • 現在のワークスペースを確認する: 管理ポータルですべてのワークスペースと関連するテナント設定を確認して、現在の状態を確認します。
  • 話し合いと決定: ワークスペースを管理する方法を決定します。 ワークスペースの管理を許可するユーザーを決定するときに、関連する意思決定者と利害関係者を関与させてください。
  • 承認が必要かどうかを確認する: 新しいドメインの作成時に他のユーザーの承認を得るプロセスを存在させる必要があるかを決定します。
  • 再確認のスケジュールを作成する: 定期的にワークスペースを再確認するスケジュールを設定します。
  • 更新を行う: 新しいニーズが生じた場合に、ロールの割り当てを含むワークスペースを更新します。
  • ドキュメントの作成: 補足情報を追跡する必要がある場合は、ワークスペースのドキュメントを作成します。
  • ユーザー要求を処理するプロセスを作成する: ユーザーが新しいワークスペースを要求する方法のプロセスを設定します。
  • 監査の設定: 監査プロセスを作成して、新しいワークスペースの作成時、または変更の発生時に追跡できるようにします。

埋め込みコードの管理

Web への公開機能を使用すると、Power BI によって埋め込みコードが生成されます。 埋め込みコードは、インターネット上で誰でも利用できる Web ページにレポートを埋め込むために使用されます。 この機能は、特定の目的のために使用できます。これは主に、認証の必要なく匿名の対象ユーザーが表示できるパブリック データを含むデータ ジャーナリズムまたはレポートを対象としています。

埋め込みコードの定期的な確認と管理は、Fabric 管理者の重要な責任です。 インターネット上で公開されているレポートの検証が含まれるため、これは特に重要な責任です。

注意事項

管理者の中には、内部アプリケーションまたはイントラネット サイトは、Web レポートへの公開を埋め込む安全な場所であると誤って考えている人がいます。 これは、埋め込んだ場所に関係なく、Web への公開を介して公開されたレポートを検索エンジンで検出できるためです。このような手法を使用することはお勧めできません。 内部の対象ユーザーに Power BI コンテンツを埋め込むには、API 埋め込み機能を使用するか、コードなしの埋め込み手法を使用することをお勧めします。 詳細については、組織向けの埋め込み使用シナリオを参照してください。

手順 1: 埋め込みコードを確認する

最初の手順は、既存の埋め込みコードとテナント環境を確認して、現在の状態を把握できるようにすることです。 レビュー プロセス中に考慮すべきいくつかの要因を次に示します。

手順 2: 埋め込みコードを決定する

埋め込みコードを確認したら、次に意思決定プロセスを確認します。 Web に公開できるコンテンツ (存在する場合) がある場合は、関連する意思決定者や利害関係者をディスカッションに関与させてください。

また、レポートを Web に公開できるユーザーを決定します。 ガバナンス ポリシーまたはセキュリティ ポリシーが存在する場合は、可能な限りそれを参照してください。

重要

[Web への公開] テナント設定は、ごく限られたユーザーに対して有効にすることを強くお勧めします。 機密データを含むレポートを誤って公開するリスクが高いため、コンテンツ作成者による Web への公開を禁止または制限することを検討してください。

手順 3: 埋め込みコードを更新する

この時点で、既存の埋め込みコードと目的に応じた決定を利用できます。 これで、既存の埋め込みコードに一時的または永続的な変更を加える準備ができました。

必要な更新プログラムを決定するには、さらに調査が必要になる場合があります。

  • アクティブな埋め込みコードを含むすべてのレポートを確認して、Web に不適切な情報が公開されていないことを確認します。 また、基になるセマンティック モデルに機密情報や独自の情報が含まれていないことも確認します。
  • レポートを公開したユーザーに連絡して、その目的を明確にしてください。
  • 必要に応じて、コンテンツ所有者と協力して、目的に適した個人用ではないワークスペースにコンテンツを再配置します。 一般公開されているコンテンツが含まれていることを明確に示すワークスペースの使用を検討してください。 たとえば、財務レポート [パブリック] ワークスペース名は、その目的を明確に示します。
  • コンテンツに割り当てられている秘密度ラベルを確認します。 秘密度ラベルが、対象ユーザーが公開対象ユーザーであることを示していることを確認します。

手順 4: 埋め込みコードを文書化する

状況によっては、管理ポータルで使用できる情報を補完するためにドキュメントを作成する場合があります。 ドキュメントには次のような内容が含まれる可能性があります。

  • 目的、意図される対象ユーザー、正当な理由など、より詳細なコンテキストと詳細。
  • 誰が、いつ、公開することを承認したか。
  • コンテンツ所有者が誰であるか (コンテンツ所有者が公開したユーザーと異なる場合)。

手順 5: 埋め込みコードを管理する

埋め込みコードは、管理ポータルで定期的に監視する必要があります。 また、レポートを Web に公開するユーザーからの要求を管理する方法を検討してください。

Note

すべてのレポートが Web への公開で使用をサポートしているわけではありません。 ユーザーは、この機能の使用に関連する質問をサポートする可能性があります。

手順 6: 埋め込みコードを監査する

埋め込みコードを定期的に監査するプロセスを用意することが重要です。 ここでは、アクティビティ ログを使用して埋め込みコードを監査する場合に特定するためのアクションをいくつか示します。

  • 新しい埋め込みコードが作成されました: PublishToWebReport アクティビティを検索します。
  • Web への公開テナント設定が変更されました: UpdatedAdminFeatureSwitch アクティビティを使用して、アクティビティ ログで変更されたテナント設定の値を検索します。 アイテム名は PublishToWeb になります。

チェックリスト - 埋め込みコードを計画および管理するときの、主要な決定事項とアクションは次のとおりです。

  • 現在の埋め込みコードを確認する: 管理ポータルですべての埋め込みコードを確認して、現在の状態を決定します。
  • 現在のテナント設定を確認する: [Web への公開] テナント設定の現在の設定を確認します。
  • 話し合いと決定: 公開できるコンテンツ (存在する場合) とユーザーを決定します。 必要に応じて、関連する意思決定者と利害関係者を関与させていください。 可能であれば、既存のガバナンス ポリシーを参照してください。
  • 承認が必要かどうかを確認する: Web にレポートを公開する際に他のユーザーの承認を得るプロセスを存在させる必要があるかを決定します。
  • 再確認のスケジュールを作成する: 定期的に埋め込みコードを再確認するスケジュールを設定します。
  • 更新を行う: 必要に応じて、現在の埋め込みコードを更新します。 [Web に公開] テナント設定を行われた決定に基づいて更新します (現在公開されている内容と異なる場合)。
  • ドキュメントの作成: 補足情報を追跡する必要がある場合は、埋め込みコードのドキュメントを作成します。
  • ユーザー要求を処理するプロセスを作成する: ユーザーがレポートを Web に公開するよう要求する方法、または独自のレポートを Web に発行するアクセス許可を持つプロセスを設定します。
  • 監査の設定: 監査プロセスを作成して、新しい埋め込みコードが作成されたタイミングと [Web に公開] テナント設定が変更された日時を追跡できるようにします。

組織のビジュアルの管理

Power BI レポート作成者は、Power BI レポート設計で複数の種類のビジュアルを使用できます。

  • コア ビジュアル: Power BI Desktop と Power BI サービスに組み込まれた、すぐに利用できる既定のビジュアル。
  • AppSource の認定済みカスタム ビジュアル: サード パーティのソフトウェア ベンダーまたは世界中の Power BI コミュニティのメンバーによって開発されたカスタム ビジュアル。
  • AppSource の認定済みカスタム ビジュアル: サード パーティのソフトウェア ベンダーまたは世界中の Power BI コミュニティのメンバーによって開発され、Microsoft によって定義された認定プロセスに合格したカスタム ビジュアル。

組織は、許可される特定のビジュアル (およびバージョン) を登録することで、(レポートが Power BI サービスに発行される場合に) カスタム ビジュアルの使用を制限することを選択できます。 許可されるビジュアルは、組織のビジュアルと呼ばれます。

Fabric 管理者は、管理センターで組織のビジュアルを登録および管理する責任があります。 次の情報を登録できます。

組織のビジュアルを登録することには多くの利点があります。

  • 一部またはすべてのカスタム ビジュアルは、すべてのレポート作成者の視覚化ウィンドウで自動的に使用できます。
  • コンテンツ作成者は、Power BI ビジュアル (.pbiviz) ファイルをインポートする必要はありません。
  • カスタム ビジュアルのバージョンは、すべてのレポートで一貫しています。
  • レポートとダッシュボードは、組織のビジュアルが更新されると自動的に更新されます。
  • 新しいカスタム ビジュアルと変更されたカスタム ビジュアルは、組織で広く利用できるようになる前に、体系的にテストおよび事前承認できます。
  • 既存のカスタム ビジュアルが組織の要件を満たさなくなった場合は、すぐに無効にしたり削除したりできます。

(Power BI Desktop で使用するために) ユーザー デバイスにカスタム ビジュアルを配布する場合の詳細については、「カスタム ビジュアル」を参照してください。

このセクションの残りの部分では、組織のビジュアルの管理に焦点を当てます。

手順 1: 組織のビジュアルを確認する

最初の手順は、既存の組織のビジュアルとテナント環境を確認して、現在の状態を把握できるようにすることです。

手順 2: 組織のビジュアルを決定する

組織のビジュアルを確認したら、次に意思決定プロセスを確認します。 カスタム ビジュアルを管理する方法に関して慎重に検討された意思決定を行う準備をする必要があります。

意思決定プロセス中に考慮すべきいくつかの質問を次に示します。

  • カスタム ビジュアルは組織で許可されていますか? カスタム ビジュアルに依存する場合、組織が意図的に選択する理由はいくつかあります。
    • 品質と安定性に対する期待は、カスタム ビジュアルを開発したユーザーによって異なります。
    • 自由に使用できるカスタム ビジュアルには、テクニカル サポートがない場合があります。
    • データ プライバシーに重大な懸念がある組織や、データ漏えいの懸念に非常に敏感な組織の場合、カスタム ビジュアルの使用はリスク プロファイルと互換性がない可能性があります。 これは、カスタム ビジュアルがセマンティック モデルからクエリが実行されたデータにアクセスできるためです。 また、カスタム ビジュアルが Web サービスにデータを送り返す可能性もあります (多くの場合、API の呼び出しや AI アルゴリズムの実行などの正当な目的のため)。
  • カスタム ビジュアルはどのように検証され、使用が承認されますか? カスタム ビジュアルを組織で使用するために、テストと事前承認を行う必要があります。 この検証プロセスにより、信頼できないビジュアルが使用されるリスクが軽減されます。 また、管理者は、テストを行い使用が承認されたバージョンを指定することもできます。
  • カスタム ビジュアルの使用を許可されているのは誰ですか? [Power BI SDK を使用して作成された視覚エフェクトを許可する] テナント設定は、カスタム ビジュアルの追加、共有、操作を許可されたユーザーを制御します。 組織が (AppSource またはインポートされた .pbiviz ファイルから) この機能を制限することを決定した場合、特定のカスタム ビジュアルを許可する方法として組織のビジュアルに依存する可能性があります。
  • 認定済みビジュアルは必須ですか? AppSource が許可されている場合、認定済みビジュアルのみに制限することが好まれる組織もあります。 これは、[認定済みビジュアルのみを追加および使用する] テナント設定を設定することで行われます。 このような状況では、組織のビジュアルを使用して、組織で使用が承認された認定されていないビジュアルを配布できます。
  • カスタム ビジュアルを一元管理する必要はありますか? 個々のレポート作成者が AppSource からビジュアルをダウンロードする場合、バージョンの不一致による問題が発生する可能性があります。 組織のビジュアル リポジトリを使用してカスタム ビジュアルを一元管理すると、テナント内のすべての Power BI レポート作成者が同じ承認済みバージョンを使用できるため、レポート作成者のプロセスが簡略化されます。 ただし、Fabric 管理者が関与する必要があるため、遅延が発生する可能性があります。
  • 許可されるソースは何ですか? 組織のビジュアルは、AppSource または .pbiviz ファイルから取得できます。 AppSource は通常、特に認定済みビジュアルを使用する場合に最適なソースです。 .pbiviz ファイルは、ビジュアルがベンダーから非公開で取得された場合、または内部で開発された場合に適しています。
  • カスタム ビジュアルはいつ視覚化ウィンドウに表示する必要がありますか? 多くの場合、カスタム ビジュアルを視覚化ウィンドウに表示して、すべてのレポート作成者が自動的に使用できるようにすることが適切です。

手順 3: 組織のビジュアルを更新する

この時点で、既存の組織のビジュアルと意図的な決定を利用できます。 これで、既存の組織のビジュアルに一時的または永続的な変更を加える準備ができました。

また、カスタム ビジュアルに関連するテナント設定を変更する必要がある場合もあります (レポート作成者が組織のビジュアル リポジトリにないカスタム ビジュアルのダウンロードとインストールを許可されている場合)。

Note

カスタム ビジュアルに関連するテナント設定は、Power BI Desktop のレポートではなく、公開されたレポートにのみ適用されます。 レポート作成者が Power BI サービス と Power BI Desktop の両方で一貫したカスタム ビジュアル オプションを使用できるようにするには、グループ ポリシーを使用してローカル コンピューターのカスタム ビジュアル (Power BI Desktop 用) を管理する必要があります。 詳細については、「ユーザーのツールとデバイス」を参照してください。

手順 4: 組織のビジュアルを文書化する

状況によっては、管理ポータルで使用できる情報を補完するためにドキュメントを作成する場合があります。 ドキュメントには次のような内容が含まれる可能性があります。

  • カスタム ビジュアルで実現される内容など、より詳細なコンテキストと詳細。
  • カスタム ビジュアルを作成したユーザー (内部開発者やベンダーなど)、または詳細情報の問い合わせ先。
  • ビジュアルを更新する必要がある場合に繰り返すことができるように、ビジュアルを検証するために実行されたテスト。
  • 誰が、いつカスタム ビジュアルの使用を承認したか。

手順 5: 組織のビジュアルを管理する

組織のビジュアルは、管理ポータルで定期的に監視する必要があります。 また、オンラインで見つけた新しいカスタム ビジュアルを使用するユーザーからの要求を管理する方法も検討してください。

場合によっては、各カスタム ビジュアルの最終更新日時も確認する必要があります。 新しいバージョンが使用可能かどうかを調査します。 新しいバージョンが使用可能な場合は、テストに合格していれば、組織のビジュアルを更新できます。

手順 6: 組織のビジュアルを監査する

組織のビジュアルを定期的に監査するプロセスを用意しておくことが重要です。 アクティビティ ログを使用して組織のビジュアルを監査するタイミングを特定するアクションをいくつか次に示します。

  • 新しい組織のビジュアルが追加されました: InsertOrganizationalGalleryItem アクティビティを検索します。
  • 既存の組織のビジュアルが更新されました: UpdateOrganizationalGalleryItem アクティビティを検索します。
  • Power BI SDK を使用して作成された視覚エフェクトを許可する テナント設定が変更されました: UpdatedAdminFeatureSwitch アクティビティを使用して、アクティビティ ログで変更されたテナント設定の値を検索します。 項目名は CustomVisualsTenant になります。
  • 認定済みの視覚エフェクトのみを追加および使用する (未認定はブロック) テナント設定が変更されました: UpdatedAdminFeatureSwitch アクティビティを使用して、アクティビティ ログで変更されたテナント設定の値を検索します。 アイテム名は CertifiedCustomVisualsTenant になります。

チェックリスト – 組織のビジュアルを計画および管理する場合、主な決定事項とアクションは次のとおりです。

  • 現在の組織のビジュアルを確認する: 管理ポータルですべての組織のビジュアルを確認して、現在の状態を決定します。
  • 現在のテナント設定を確認する: Power BI ビジュアルの各テナント設定を確認します。 組織のビジュアルへの依存にどのように影響するかを決定します。
  • 話し合いと決定: カスタム ビジュアルを組織内で誰がどのように使用するかを決定します。 組織のビジュアル、AppSource、.pbiviz ファイルを使用する方法を検討する場合は、関連する意思決定者と利害関係者を関与させてください。
  • 再確認のスケジュールを作成する: 定期的に組織のビジュアルを再確認するスケジュールを設定します。
  • 更新を行う: 必要に応じて、現在の組織のビジュアルを更新します。 決定に基づいて Power BI ビジュアル テナント設定を更新します (現在公開されている内容と異なる場合)。
  • ユーザー マシンを管理する: グループ ポリシーを設定し、カスタム ビジュアルが Power BI サービスと同様の方法で Power BI Desktop で確実に管理されるようにします。
  • ドキュメントの作成: 補足情報を追跡する必要がある場合は、組織のビジュアルのドキュメントを作成します。
  • ユーザー要求を処理するプロセスを作成する: ユーザーがカスタム ビジュアルの使用を要求する方法 (一般) や、特定のカスタム ビジュアルへのアクセスを要求するためのプロセスを設定します。
  • 監査の設定: 新しいカスタム ビジュアルが組織のビジュアルとして登録されたタイミングや、Power BI ビジュアルのテナント設定のいずれかが変更されたタイミングを追跡できるように監査プロセスを作成します。

Azure 接続の管理

Power BI は、Azure サービスと統合して機能を拡張したり、その他の機能を提供したりできます。 Azure 接続を使用する主な理由は 3 つあります。

  • データフロー用のデータ ストレージ (Gen1)。 Power BI データフロー (Gen1) のデータには、Azure で直接アクセスできます。 ワークスペースは、テナント レベルで定義されているストレージ アカウント、またはワークスペースに固有のストレージ アカウントに接続できます。 この手法は、独自のレイクを使用する (BYOL) と呼ばれることもあります。 BYOL 戦略の柔軟性は、他のプロセスや他のユーザーがデータを表示またはアクセスできるようにすることで、Power BI 以外のデータフロー データを再利用する場合に役立ちます。 詳細については、「Azure Data Lake Storage Gen 2 を使用するようにデータフロー ストレージを構成する」とセルフサービスのデータ準備を参照してください。

  • セマンティック モデルのバックアップと復元。 データ保持要件を満たすため、またはデータ モデルを移行するために、ディザスター リカバリーの目的でセマンティック モデルのバックアップと復元が必要になる場合があります。 詳しくは、「Power BI Premium でのセマンティック モデルのバックアップと復元」をご覧ください。

  • Azure Log Analytics の統合。 セマンティック モデルのアクティビティ、パフォーマンス、傾向を分析できます。 Azure Log Analytics を統合することで、Power BI セマンティック モデルをホストする Analysis Services エンジンによって生成された診断データを確認できます。 詳細については、 Semantic モデルのイベント ログを参照してください。

    Note

    データセット名の変更はPower BI サービスとドキュメントでロールアウトされていますが、イベント ログ操作名など変更がまだ発生していない場合があります。

Azure 接続を使用するための主なユース ケースがデータ ストレージの場合 (上記の最初のポイントで説明した BYOL)、代わりにデータフロー Gen2 と OneLake の使用を検討することをお勧めします。 どちらもデータ ストレージに ADLS Gen2 を使用しますが、提供する機能、目的、使用するストレージ オプション (データの書き込み方法による) は異なります。 例: OneLake は表形式のデータとデータフロー Gen2 データを開いた Delta Parquet 形式で格納しますが、Power BI データフロー (Gen1) からの出力 (Azure 接続を使用) では共通データ モデル形式でデータが格納されます。 詳細については、「第 1 世代のデータフローから第 2 世代のデータフローに移行する」を参照してください。

このセクションの残りの部分では、管理ポータルでの Azure 接続の管理に重点を置いています。

手順 1: Azure 接続を確認する

最初の手順は、既存の Azure 接続とテナント環境を確認して、現在の状態を把握できるようにすることです。 確認する領域は 2 つあります。

まず、管理ポータルで既存の設定を確認します。

  • 現在のテナント レベルのストレージ設定: テナント レベルのストレージが現在どのように設定されているかを確認します。 これにより、ワークスペース管理者がワークスペース設定内で接続を選択できる既定の Azure 接続が提供されます。
  • 現在のワークスペースレベルのストレージのアクセス許可: ワークスペースレベルのストレージのアクセス許可が有効になっているかどうかを確認します。 有効にすると、ワークスペース管理者は、ワークスペースを独自の ADLS Gen2 アカウントに接続できます。

次に、[ワークスペース管理者の Azure Log Analytics 接続] テナント設定の設定を確認します。 有効にすると、ワークスペース管理者は、セマンティック モデルの診断データを送信する目的で、ワークスペースを ADLS Gen2 アカウントに接続できます。

手順 2: Azure 接続を決定する

Azure 接続を確認したら、次に意思決定プロセスを確認します。

意思決定プロセス中に考慮すべきいくつかの質問を次に示します。

  • Azure 接続の使用は、データ戦略とユーザーのニーズに合っていますか? Azure 接続がデータフロー (Gen1) のストレージに役立つかどうかを検討してください。 セマンティック モデルのバックアップと復元機能を使用するための要件があるかどうかを判断します。 Azure Log Analytics 統合のニーズがあるかどうかを検討してください。
  • 集中型と分散型のデータ ストレージトはどのようなものですか? 分散型チームのニーズと、個人または部門が現在独自の Azure Storage アカウントを保持しているかどうかを理解してください。 ワークスペース管理者が独自の ADLS Gen2 アカウントへの接続を許可するかどうか、または 1 つの ADLS Gen2 アカウントをすべてのワークスペース (テナント レベルのストレージ) に使用するかどうかを決定します。
  • OneLake は Azure 接続に対してどのように使用されますか? OneLake の導入に伴い、データ ストレージに OneLake を徐々に使用する (BYOL) かどうかを検討してください。

詳細については、「ワークスペースと ADLS Gen2 の統合」を参照してください。

詳細については、「ワークスペースと Azure Log Analytics の統合」を参照してください。

手順 3: Azure 接続を更新する

この時点で、既存の Azure 接続が使用可能になり、データ レイクを Power BI と統合するかどうかについて目的に合った意思決定を行いました。 これで、検索結果に基づいて、必要に応じて設定を調整する準備ができました。

手順 4: Azure 接続を文書化する

状況によっては、管理ポータルで使用できる情報を補完するためにドキュメントを作成する必要があります。 ドキュメントには次のような内容が含まれる可能性があります。

  • 使用が承認されているテナント レベルのデータ レイクの場所。 データ レイクの所有者および管理者と、詳細情報の問い合わせ先を含めます。
  • ワークスペース レベルのデータ レイクを統合できるかどうか。 その他の情報 (重要な決定や理由など) は、将来参照できるように文書化しておく必要があります。

手順 5: Azure 接続を管理する

Azure 接続は、管理ポータルで随時監視する必要があります。

組織内で複数の ADLS Gen2 アカウントをサポートする方法を検討してください (ワークスペース レベルの Azure 接続が許可されている場合)。

また、ワークスペースを Azure Log Analytics に接続するユーザーからの要求を管理する方法を検討してください。

手順 6: Azure 接続を監査する

Azure 接続を定期的に監査するプロセスを用意しておくことが重要です。 アクティビティ ログを使用して Azure 接続を監査するタイミングを特定するためのアクションはいくつかあります。

  • ワークスペースが ADLS Gen2 に接続されている: AddLinkToExternalResource アクティビティを検索します。 ResourceType は、ストレージ アカウントか Log Analytics かを示します。
  • ワークスペースが ADLS Gen2 から切断されました: DeleteLinkToExternalResource アクティビティを検索します。 ResourceType は、ストレージ アカウントか Log Analytics かを示します。
  • テナント レベルのストレージが有効または無効になっている: AddExternalResource アクティビティまたは DeleteLinkToExternalResource アクティビティを使用して、アクティビティ ログで変更された値を検索します。
  • ワークスペース レベルのストレージが有効または無効になっている: UpdatedAdminFeatureSwitch アクティビティを使用して、アクティビティ ログで変更された値を検索します。 項目名は storageAccountAttachForWorkspaceAdminsEnabled になります。 SwitchState は true または false のいずれかになります。
  • [ワークスペース管理者の Azure Log Analytics 接続] テナント設定が変更されました: このテナント設定を使用すると、一部またはすべてのワークスペース管理者が独自の ADLS Gen2 アカウントを統合できます。 UpdatedAdminFeatureSwitch アクティビティを使用して、アクティビティ ログで変更されたテナント設定の値を検索します。 項目名は LogAnalyticsAttachForWorkspaceAdmins になります。

チェックリスト - Azure 接続を計画および管理するときの、主要な決定事項とアクションは次のとおりです。

  • 現在の Azure 接続を確認する: 管理ポータルで Azure 接続のテナント レベルとワークスペース レベルの設定を確認して、現在の状態を決定します。 次に、[ワークスペース管理者の Azure Log Analytics 接続] テナント設定も確認します。
  • 話し合いと決定: Azure 接続を Power BI と統合するかどうかを決定します。 今後、OneLake とデータ ストレージの Azure 接続 (BYOL) の最適な用途を決定します。
  • 承認が必要かどうかを確認する: ワークスペース レベルのストレージ アカウントを使用するための承認を得るためにプロセスが存在する必要があるかどうかを判断します。
  • 再確認のスケジュールを作成する: 定期的に Azure 接続を再確認するスケジュールを設定します。
  • 更新を行う: 必要に応じて現在の Azure 接続を更新して、テナント レベルおよびワークスペース レベルのストレージ アクセス許可を変更します。 また、行われた決定に基づいて、[ワークスペース管理者の Azure Log Analytics 接続] テナント設定の Azure Log Analytics 接続も更新します (現在設定されている内容と異なる場合)。
  • ドキュメントの作成: 補足情報を追跡する必要がある場合は、Azure 接続のドキュメントを作成します。
  • ユーザー要求を処理するプロセスを作成する: ユーザーが Azure 接続を使用できるように要求する方法のプロセスを設定します。
  • 監査の設定: ワークスペースで Azure 接続を設定した場合、または設定が変更された場合に監視できるように監査プロセスを作成します。

Power BI の使用状況の監査

テナント レベルの監査データを利用して、導入作業の分析、使用パターンの理解、ユーザーの教育、ユーザーのサポート、リスクの軽減、コンプライアンスの向上、ライセンス コストの管理、パフォーマンスの監視を実行できます。 データを分析する準備がまだできていない場合でも、Power BI 監査データをできるだけ早く抽出して格納することが重要です。

Power BI でのユーザー、アクティビティ、ソリューションの監査については、「テナント レベルの監査」を参照してください。

Power BI サービスを監視する

監視とは、何が起きているのかを知らせる継続的なアクティビティのことを指します。 監視は通常、アラートと自動化を伴う受け身的な活動ですが、アクティブに実行される場合もあります。

Power BI の監視に関する詳細については、「テナント レベルの監視」を参照してください。

関連するコンテンツ

Power BI の実装の決定に役立つ考慮事項、アクション、意思決定基準、ガイダンスについて詳しくは、「Power BI 実装計画」をご覧ください。