Power BI の実装計画: テナント レベルの監査

注意

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

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

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

重要

Power BI のリリース計画をよく読み、監査と監視の機能に関する今後の機能強化について理解することをお勧めします。

テナント レベルの監査ソリューションの目的は、Power BI テナントにデプロイされたすべてのユーザー、アクティビティ、ソリューションのデータをキャプチャして分析することです。 このテナント レベルの監査データは、導入作業の分析、使用パターンの理解、ユーザーの教育、ユーザーのサポート、リスクの軽減、コンプライアンスの向上、ライセンス コストの管理、パフォーマンスの監視など、多くの目的の役に立ちます。

安全で運用対応のエンド ツー エンドの監査ソリューションを作成することは、時間のかかる重要なプロジェクトです。 ビジネス インテリジェンスを基にしたビジネス インテリジェンスの構築と考えてください (BI on BI)。 監査データが非常に重要な理由については、監査と監視の概要に関する記事をご覧ください。

レポート作成者を対象とするレポート レベルの監査については、レポート レベルの監査に関する記事をご覧ください。

データ作成者を対象とするデータ資産の監査については、データ レベルの監査に関する記事をご覧ください。

この記事の残りの部分では、テナント レベルの監査に焦点を当てます。

ヒント

この記事で最も重視されているのは、エンド ツー エンドの監査ソリューションの作成を計画するのに役立つようにすることです。 この記事の内容は 4 つのフェーズに編成されているため、複数のフェーズにまたがって情報が必要になります。 たとえば、サービス プリンシパルの使用の計画についてはフェーズ 1 の情報を使い、前提条件とセットアップについてはフェーズ 2 の情報を使います。

そのため、この記事全体を最初に読んで、関係していることについてよく理解することをお勧めします。 その後、監査ソリューションの計画と構築について、何度も繰り返しながら入念に準備する必要があります。

テナント レベルの監査ソリューションの構築を計画するときは、次の 4 つのフェーズに時間を費やすことを計画します。

• フェーズ 1: 計画と決定
  • 要件と優先順位
  • データのニーズ
  • 監査ソリューションの種類
  • アクセス許可と責任
  • 技術に関する決定
  • データ ソースの決定
• フェーズ 2: 前提条件とセットアップ
  • ストレージ アカウントの作成
  • ソフトウェアをインストールしてサービスをセットアップする
  • Microsoft Entra アプリケーションを登録する
  • Power BI テナントの設定を行う
• フェーズ 3: ソリューションの開発と分析
  • 生データを抽出して格納する
  • キュレーションされたデータを作成する
  • データ モデルを作成する
  • データ モデルを強化する
  • 分析レポートを作成する
  • データに基づいてアクションを実行する
• フェーズ 4: 保守、拡張、監視
  • 運用化と改善
  • ドキュメントとサポート
  • アラートの有効化
  • 継続的な管理

フェーズ 1: 計画と決定

最初のフェーズでは、計画と意思決定に重点を置きます。 多くの要件と優先順位について考える必要があるため、十分な時間をかけて、このセクションで説明するトピックを理解することをお勧めします。 目標は、下流のフェーズが円滑に行われるよう、事前に適切な決定を行うことです。

要件と優先順位

最初のフェーズの目標は、最も重要なものを特定することです。 最も重要なことと、組織での影響を測定する方法に焦点を当てます。 技術指向の要件ではなく、ビジネス指向の要件を定義するように努めます。

次のような質問に答える必要があります。

• 答える必要がある重要な質問は何か? 調査できる監査データは大量にあります。 監査に取り組む最も効果的な方法は、特定の質問への回答に注目することです。
• 導入とデータ カルチャの目標は何か? たとえば、組織のセルフサービス BI コンテンツ作成者の数を増やすことが目標であるとします。 その場合は、コンテンツの作成、編集、発行に関連するユーザー アクティビティを測定する必要があります。
• どのような差し迫ったリスクが存在するか? たとえば、過去にコンテンツの過剰共有が発生したことが見つかりました。 その後、ユーザー トレーニングが強化されており、現在は、セキュリティ設定とアクティビティを継続的に監査する必要があります。
• 現在、主要業績評価指標 (KPI) または組織の目標があるか? たとえば、デジタル変革や、よりデータ主導の組織になることに関連する、組織の KPI があるとします。 テナント レベルの監査データは、Power BI の実装がこれらの目標と一致しているかどうかを測定するのに役立ちます。

ヒント

エグゼクティブ スポンサーとセンター オブ エクセレンスに関する監査の要件を確認して、優先順位を設定します。 監査データを抽出し、多くの興味深いデータに基づいてレポートの作成を始めたくなります。 ただし、答える必要がある質問や実行するアクションによって監査ソリューションが主導されない場合、監査ソリューションから高い価値が得られる可能性は低くなります。

監査データを使用できる方法について詳しくは、監査と監視の概要に関する記事をご覧ください。

チェックリスト - 要件と優先順位を明らかにするときの主な決定事項とアクションは次のとおりです。

• 要件を明らかにする: Power BI テナントの監査に関する主要なビジネス要件を収集して文書化します。
• 要件の優先順位を付ける: 要件の優先順位を設定し、それらを最優先、短期、中期、長期 (バックログ) として分類します。
• 最優先事項の計画を立てる: 必要なときに入手できるように、データの収集を始める計画を立てます。
• 要件を定期的に再評価する: 定期的に要件を再評価する計画を作成します (たとえば、年に 2 回)。 監査と監視ソリューションが明らかにされた要件を満たしているかどうかを確認します。 必要に応じて、計画のアクション項目を更新します。

データのニーズ

要件と優先順位 (前述) を定義したら、必要なデータを明らかにする準備が整います。 このセクションでは、4 つのカテゴリのデータについて説明します。

• ユーザー アクティビティ データ
• テナント インベントリ
• ユーザーとグループのデータ
• セキュリティ データ

必要なデータのほとんどは、Power BI テナントに関する豊富なメタデータを提供する管理 API から取得されます。 詳しくは、この記事で後述する「ユーザー API または管理 API を選択する」をご覧ください。

ユーザー アクティビティ データ

ユーザー アクティビティに関するデータを取得することを最優先事項にします。 "イベント" または "操作" とも呼ばれる "ユーザー アクティビティ" は、さまざまな目的に役立ちます。

ほとんどの場合、このデータは "アクティビティ ログ" または "イベント ログ" と呼ばれます。 技術的には、複数の方法でユーザー アクティビティ データを取得できます (アクティビティ ログは 1 つの方法です)。 関連する決定事項とアクティビティについて詳しくは、この記事で後述する「ユーザー アクティビティ データにアクセスする」をご覧ください。

ユーザー アクティビティ データにより、次のような一般的な質問に回答できます。

• 上位のユーザーと上位のコンテンツを見つける
  • 最も頻繁に見られているコンテンツは何で、どのユーザーが見ているか?
  • コンテンツの表示には、日単位、週単位、月単位でどのような傾向があるか?
  • レポート ビューは上昇傾向にあるか、下降傾向にあるか?
  • 何人のユーザーがアクティブか?
• ユーザーの動作について
  • 最もよく使われるセキュリティの種類は何か (アプリ、ワークスペース、またはアイテムごとの共有)?
  • ユーザーが最も頻繁に使うのは、ブラウザーか、モバイル アプリか?
  • 最も積極的にコンテンツを発行および更新しているコンテンツ作成者は誰か?
  • どのようなコンテンツが、いつ、どのユーザーによって、発行または更新されているか?
• ユーザーの教育とトレーニングの機会を特定する
  • 個人のワークスペースから (過度に) 共有しているのはどのユーザーか?
  • 大量のエクスポートを行っているのはどのユーザーか?
  • コンテンツを定期的にダウンロードしているのはどのユーザーか?
  • 多くの新しいセマンティック モデルを公開するのは誰ですか?
  • サブスクリプションを多く使っているのはどのユーザーか?
• ガバナンスとコンプライアンスの作業を改善する
  • テナント設定は、いつ、どの Power BI 管理者によって変更されているか?
  • Power BI 評価版を起動したのは誰か?
  • どの外部ユーザーが、いつ、どのような方法で、どのコンテンツにアクセスしているか?
  • 秘密度ラベルを追加または更新したのはどのユーザーか?
  • 認定されたセマンティック モデルに基づくレポート ビューは何パーセントあるか?
  • 複数のレポートがサポートされるセマンティック モデルは何パーセントあるか?
  • ゲートウェイまたはデータ ソースは、いつ、どのユーザーによって、作成または更新されるか?

このデータの使い方について詳しくは、「使用パターンを理解する」をご覧ください。

重要

ユーザー アクティビティ データの抽出と格納をまだ行っていない場合は、それを最優先の事項にします。 少なくとも、生データを抽出して、安全な場所に保管します。 そうしておけば、データを分析できる状態になったときに利用できます。 履歴は、使用するソースに応じて 30 日間または 90 日間分を入手できます。

詳しくは、後の「ユーザー アクティビティ データにアクセスする」をご覧ください。

テナント インベントリ

多くの場合、2 番目に優先順位が高いのは、"テナント インベントリ" を作成するためのデータを取得することです。 これは、"ワークスペース インベントリ"、"ワークスペース メタデータ"、または "テナント メタデータ" と呼ばれることがあります。

テナント インベントリは、特定の時点でのスナップショットです。 そこでは、テナントで発行されるものが記述されています。 テナント インベントリには、実際のデータや実際のレポートは含まれていません。 そうではなく、すべてのワークスペースとそのアイテム (セマンティック モデルやレポートなど) を記述するメタデータです。

テナント インベントリでは、次のような一般的な質問に回答できます。

• 所有しているコンテンツの量と場所を把握する
  • コンテンツが最も多いワークスペースはどれか?
  • 各ワークスペースでは、どのような種類のコンテンツが発行されているか (特に、レポート ワークスペースとデータ ワークスペースを分けている場合)?
  • アイテムの間にどのような依存関係が存在するか (多くのセマンティック モデルをサポートするデータフローや、他の複合モデルのソースであるセマンティック モデルなど)?
  • どのようなデータ系列か (外部データ ソースを含む、Power BI アイテム間の依存関係)?
  • 孤立したレポートはあるか (セマンティック モデルから切断されているもの)?
• レポートに対するセマンティック モデルの比率を把握する
  • セマンティック モデルの再利用はどれくらい行われているか?
  • 重複している、または非常によく似た、セマンティック モデルがあるか?
  • セマンティック モデルを統合する機会はあるか?
• 時間経過に伴う傾向を把握する
  • 時間と共にレポートの数は増えているか?
  • 時間と共にセマンティック モデルの数は増えているか?
• 未使用のコンテンツを見つける
  • 使われていない (または使用率の低い) レポートはどれか?
  • 使われていない (または使用率の低い) セマンティック モデルはどれか?
  • コンテンツを廃止する機会はあるか?

テナント インベントリは、履歴アクティビティを分析するときに現在の名前を使うのに役立ちます。 テナント内のアイテムのスナップショットには、"その時点での" すべてのアイテムの名前が含まれます。 履歴レポートに現在のアイテムの名前を使うと便利です。 たとえば、3 か月前にレポートの名前が変更された場合、その時点のアクティビティ ログには古いレポート名が記録されます。 データ モデルが適切に定義されていると、最新のテナント インベントリを使って、(以前の名前ではなく) 現在の名前でアイテムを検索できます。 詳しくは、後の「データ モデルを作成する」をご覧ください。

テナント インベントリの使い方について詳しくは、発行されるコンテンツの理解に関する記事をご覧ください。

ヒント

多くの場合、ユーザー アクティビティ イベント ( 前のセクションで説明) とテナント インベントリを組み合わせて、全体像を生成します。 そうすることで、すべてのデータの価値を高めることができます。

テナント インベントリは特定の時点でのスナップショットなので、メタデータを抽出して格納する頻度を決める必要があります。 2 つの時点の比較には、週単位のスナップショットが便利です。 たとえば、ワークスペースのセキュリティ設定を調べたい場合は、以前のテナント インベントリ スナップショット、アクティビティ ログ イベント、現在のテナント インベントリ スナップショットが必要です。

テナント インベントリを構築するには、主に 2 つの方法があります。 関連する決定事項とアクティビティについて詳しくは、後の「テナント インベントリ データにアクセスする」をご覧ください。

ユーザーとグループのデータ

分析のニーズが高まるにつれて、エンド ツー エンドの監査ソリューションにユーザーとグループに関するデータを含める必要があると判断するようになります。 そのデータを取得するには、Microsoft Entra ID のユーザーとグループに関する情報の権限のあるソースである Microsoft Graph を使用できます。

Power BI REST API から取得されるデータには、ユーザーを示すメール アドレス、またはセキュリティ グループの名前が含まれます。 このデータは、特定の時点でのスナップショットです。

Microsoft Graph では、次のような一般的な質問に回答できます。

• ユーザーとグループを識別する
  • ユーザー プロファイルから取得された (メール アドレスに加えて) 完全なユーザー名、部署、または場所は何か?
  • セキュリティ グループのメンバーは誰か?
  • セキュリティ グループの (メンバーを管理するための) 所有者は誰か?
• 追加のユーザー情報を取得する
  • ユーザーに割り当てられているライセンスは何か (Power BI Pro または Power BI Premium Per User (PPU))?
  • 最も頻繁にサインインしているのはどのユーザーか?
  • 最近 Power BI サービスにサインインしていないのはどのユーザーか?

警告

ユーザーとグループのデータにアクセスするための一部の古いメソッド (オンラインの多くのドキュメントに記載されているもの) は非推奨であり、使わないでください。 可能な限り、Microsoft Graph をユーザーとグループのデータの信頼できるソースとして使ってください。

Microsoft Graph からデータにアクセスする方法の詳細と推奨事項については、後の「ユーザーとグループのデータにアクセスする」をご覧ください。

セキュリティ データ

セキュリティ監査を定期的に実行することが必要な場合があります。

Power BI REST API では、次のような一般的な質問に回答できます。

• ユーザーとアプリケーションを識別する
  • ユーザー、グループ、またはサービス プリンシパルがアクセスできるレポートはどれか?
  • メール サブスクリプションでレポートを受け取っているサブスクライバーは、どのユーザー、グループ、またはサービス プリンシパルか?
• コンテンツのアクセス許可を把握する
  • どのワークスペース ロールが、どのユーザーとグループに割り当てられているか?
  • 各 Power BI アプリ対象ユーザーにはどのユーザーとグループが割り当てられているか?
  • どのアイテムごとのアクセス許可が、どのレポートについて、どのユーザーに割り当てられているか?
  • どのアイテムごとのアクセス許可が、どのセマンティック モデルについて、どのユーザーに割り当てられているか?
  • どのセマンティック モデルとデータマートに、行レベルのセキュリティ (RLS) が定義されているか?
  • どのアイテムが、組織全体でユーザーに共有されているか?
  • どのアイテムが、インターネット上でパブリックに発行されているか?
• その他のアクセス許可を把握する
  • デプロイ パイプラインを使って発行するためのアクセス許可を持っているのはどのユーザーか?
  • ゲートウェイとデータ接続を管理するためのアクセス許可を持っているのはどのユーザーか?
  • Premium 容量を管理するためのアクセス許可を持っているのはどのユーザーか?

重要

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

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

ヒント

セキュリティに関するその他の考慮事項については、セキュリティ計画に関する記事をご覧ください。

これらの一般的な質問は、このリストがすべてではありません。さまざまな Power BI REST API を利用できます。 詳しくは、「Power BI REST API を使用する」をご覧ください。

管理 API とユーザー API の使用 (データを抽出するユーザーに必要なアクセス許可に与える影響を含む) について詳しくは、後の「ユーザー API または管理 API を選択する」をご覧ください。

チェックリスト - 監査に必要なデータを明らかにするときの主な決定事項とアクションは次のとおりです。

• ユーザー アクティビティ データの具体的なデータ ニーズを明らかにする: 収集した要件を検証します。 ユーザー アクティビティ データの各要件を満たすために必要な監査データを特定します。
• テナント インベントリ データの具体的なデータ ニーズを明らかにする: 収集した要件を検証します。 テナント インベントリを作成するために必要な監査データを特定します。
• ユーザーとグループのデータの具体的なデータ ニーズを明らかにする: 収集した要件を検証します。 ユーザーとグループのデータの各要件を満たすために必要な監査データを特定します。
• セキュリティ データの具体的なデータ ニーズを明らかにする: 収集した要件を検証します。 セキュリティ データの各要件を満たすために必要な監査データを特定します。
• 優先順位を確認する: 最初に開発するものがわかるように、優先順位を確認します。
• アクティビティをキャプチャする頻度を決める: どれくらいの頻度でアクティビティ イベントをキャプチャするかを決めます (1 日に 1 回など)。
• スナップショットをキャプチャする頻度を決める: テナント インベントリやユーザーとグループのデータなど、スナップショット データをキャプチャする間隔を決めます。

監査ソリューションの種類

テナント レベルの監査は、手動または自動プロセスで行われます。

ほとんどの新しい監査プロセスは、特に開発中やテスト中には、手動プロセスとして開始されます。 手動監査プロセスを発展させて、自動プロセスにできます。 ただし、すべての監査プロセスを完全に自動化する必要はありません。

手動監査プロセス

手動監査は、ユーザー (通常は Power BI 管理者) がオンデマンドで実行するスクリプトとプロセスに依存します。 必要になったら、ユーザーは "対話形式" でクエリを実行して監査データを取得します。

手動監査は、次の場合に最適です。

• 開発およびテストされている新しいスクリプト。
• たまに発生する、1 回限りの監査のニーズ。
• 探索的な監査のニーズ。
• 完全なサポートを必要としない不要不急の監査プロセス。

自動監査プロセス

定期的に必要な監査データは自動化する必要があります。 それは定期的なスケジュールで抽出および処理され、"自動プロセス" と呼ばれます。 "無人プロセス" と呼ばれることもあります。

自動プロセスの目標は、手作業を減らし、エラーのリスクを下げ、一貫性を高め、その実行を個々のユーザーに依存しなくて済むようにすることです。

自動監査は、次の場合に最適です。

• 運用環境で実行する監査プロセス。
• 定期的なスケジュールで実行される無人プロセス。
• 完全にテストされたスクリプト。
• データ ソースとしてそれに依存する他のレポート (または他のプロセス) がある絶対必要な監査プロセス。
• 文書化およびサポートされている監査プロセス。

プロセスの種類 (手動または自動) は、認証の処理方法に影響を与える可能性があります。 たとえば、Power BI 管理者は、手動監査プロセスにはユーザー認証を使い、自動プロセスにはサービス プリンシパルを使うことがあります。 詳しくは、後の「認証方法を決定する」をご覧ください。

ヒント

現在は手動で処理されている監査データを定期的に繰り返し取得する必要がある場合は、それを自動化するために時間を費やすことを検討します。 たとえば、Power BI 管理者が毎日手動でスクリプトを実行して Power BI アクティビティ ログからデータを取得している場合、その人が病気になったり休暇を取ったりするとデータが欠けるリスクがあります。

チェックリスト - 開発する監査ソリューションの種類を検討するときの主な決定事項とアクションは次のとおりです。

• 新しい監査要件ごとに主な目的を決める: 新しい要件ごとに手動プロセスと自動プロセスのどちらを使うかを決めます。 その決定が一時的か永続的かを検討します。
• 自動化する方法の計画を作成する: 特定の監査要件に適している場合は、それをどのように、いつ、誰が自動化するかを計画します。

アクセス許可と責任

この時点では、達成したい内容と最初に必要なデータを明確に把握しておく必要があります。 ユーザーのアクセス許可および役割と責任に関する決定を行うのに良い時期です。

ユーザーのアクセス許可

エンド ツー エンドの監査ソリューションを構築を計画するときは、データにアクセスする必要がある他のユーザーに対するユーザー アクセス許可を検討します。 具体的には、監査データにアクセスして見ることができるユーザーを決めます。

次のことを考慮する必要があります。

監査データへの直接アクセス

監査データに直接アクセスできるユーザーを決める必要があります。 それについて考えるにはいくつかの方法があります。

• 誰が Power BI 管理者になる必要があるか? Power BI 管理者は、管理 API を含むすべてのテナント メタデータにアクセスできます。 Power BI 管理者の決定について詳しくは、「テナント レベルのセキュリティ計画」をご覧ください。
• 既存のサービス プリンシパルを使用できるのは誰か? (ユーザーのアクセス許可ではなく) サービス プリンシパルを使って監査データにアクセスするには、パスワード ベースの認証を実行できるよう、認可されたユーザーにシークレットを提供する必要があります。 シークレット (およびキー) へのアクセスは、非常に厳密に制御する必要があります。
• アクセスを厳密に制御する必要があるか? 規制とコンプライアンスに関する要件がある特定の業界では、他の業界より厳しくアクセスを制御する必要があります。
• アクティビティ データの量は多いか? API の調整制限に達しないようにするため、監査データを生成する API に直接アクセスできるユーザーを厳密に制御することが必要になる場合があります。 この場合は、重複する作業がないことを確認すると役に立ちます。

抽出された生データへのアクセス

抽出されてストレージの場所に書き込まれた生データを見ることができるユーザーを決める必要があります。 最も一般的には、生データへのアクセスは管理者と監査担当者に制限されます。 センター オブ エクセレンス (COE) もアクセスを必要とする場合があります。 詳しくは、後の「監査データを格納する場所を決定する」をご覧ください。

キュレーションされた分析データへのアクセス

分析できる状態のキュレーションされて変換されたデータを表示できるユーザーを決める必要があります。 管理者と監査担当者は、このデータを常に使用できる必要があります。 組織内の他のユーザーがデータ モデルを使用できる場合があります。具体的には、行レベルのセキュリティを使用する Power BI セマンティック モデルを作成したときです。 詳しくは、後の「キュレーションされたデータの作成を計画する」をご覧ください。

ロールと責任

ユーザー アクセス許可の働きを決定したら、役割と責任について考え始めることができます。 早い段階で適切なユーザーを関与させることをお勧めします。複数の開発者またはチームがエンド ツー エンドの監査ソリューションの構築に関わる場合は特にそうです。

次のアクティビティについての責任を負うユーザーまたはチームを決めます。

ロール	責任の種類	ロールを通常実行する人
利害関係者とコミュニケーションを取る	コミュニケーション アクティビティと要件の収集。	IT と協力した COE。 主要な部署から選ばれたユーザーを含めることもできます。
優先順位を決定し、要件に関する方向性を示す	要件を満たす方法を含む、エンド ツー エンドの監査ソリューションに関連する意思決定アクティビティ。	COE など、組織内の Power BI を監督するチーム。 エグゼクティブ スポンサーまたはデータ ガバナンス運営委員会が、重要な意思決定を行ったり、問題をエスカレートしたりするために関与する可能性があります。
生データを抽出して格納する	データにアクセスして抽出するためのスクリプトとプロセスの作成。 ストレージへの生データの書き込みも含まれます。	データ エンジニアリング スタッフ。通常は IT 部署で、COE と協力。
キュレーションされたデータを作成する	スター スキーマ設計でのデータ クレンジング、変換、キュレーションされたデータの作成。	データ エンジニアリング スタッフ。通常は IT 部署で、COE と協力。
データ モデルを作成する	キュレーションされたデータに基づく分析データ モデルの作成。	Power BI コンテンツ作成者。通常は IT 部署または COE。
分析レポートを作成する	キュレーションされたデータを分析するためのレポートの作成。 新しい要件に基づく場合と、新しい監査データが使用可能になったときの、レポートの継続的な変更。	Power BI レポート作成者。通常は IT 部署または COE。
データを分析し、結果に対応する	データを分析し、監査データに対応して行動します。	組織内の Power BI を監督するチーム、通常は COE。 監査結果とアクションによっては、他のチームが含まれることもあります。 他のチームには、セキュリティ、コンプライアンス、法務、リスク管理、または変更管理が含まれる場合があります。
テストと検証	監査要件が満たされていて、提示されたデータが正確であることを、テストして確認します。	Power BI コンテンツ作成者、組織内で Power BI を監督するチームと協力。
データをセキュリティで保護する	生データやキュレーションされたデータなど、各ストレージ レイヤーのセキュリティを設定して管理します。 データを分析するために作成されたセマンティック モデルへのアクセスを管理します。	データを格納するシステムのシステム管理者、組織内で Power BI を監督するチームと協力。
スケジュール設定と自動化	ソリューションを運用化し、選ばれたツールを使ってプロセスのスケジュールを設定します。	データ エンジニアリング スタッフ。通常は IT 部署で、COE と協力。
ソリューションをサポートする	ジョブの実行、エラー、技術的な問題のサポートなど、監査ソリューションを監視します。	Power BI システムのサポートを処理するチーム。通常は IT 部署または COE。

上記の役割と責任の多くは、同じチームまたは人によって実行される場合は統合できます。 たとえば、Power BI 管理者はこれらの役割のいくつかを実行する場合があります。

状況に応じて、異なる人が異なる役割を実行することもあります。 アクションは、監査データと提案されたアクションに応じて状況により異なります。

いくつか例を示します。

• 例 1: 一部のユーザーが Excel にデータを頻繁にエクスポートすることが、監査データで示されています。 実行されるアクション: COE は、特定のユーザーに連絡してニーズを理解し、より良い代替手段を教えます。
• 例 2: 外部ユーザー アクセスが予期しない方法で行われていることが、監査データで示されています。 実行されるアクション: IT システム管理者が、外部ユーザー アクセスに関連する Microsoft Entra ID の設定を更新します。 Power BI 管理者は、外部ユーザー アクセスに関連するテナントの設定を更新します。 COE は、セキュリティを管理するコンテンツ作成者向けのドキュメントとトレーニングを更新します。 詳しくは、「外部ユーザーに関する戦略」をご覧ください。
• 例 3: 同じメジャーの定義が複数のデータ モデルで異なっていることが、監査データで示されています (メタデータ テナントの詳細設定で許可されている場合、メタデータ スキャン API から入手可能)。 実行されるアクション: データ ガバナンス委員会は、共通の定義を作成するプロジェクトを開始します。 COE は、データ モデルを作成するコンテンツ作成者向けのドキュメントとトレーニングを更新します。 また、COE は、コンテンツ作成者と協力し、必要に応じてモデルを更新します。 詳細なメタデータの取得について詳しくは、後の「テナント インベントリ データにアクセスする」をご覧ください。

注意

通常、データ抽出プロセスのセットアップは 1 回限りの作業であり、機能強化やトラブルシューティングがときどき行われます。 データの分析と対応は、繰り返し継続的に行う必要がある作業です。

チェックリスト - アクセス許可と責任を検討するときの主な決定事項とアクションは次のとおりです。

• 関係するチームを明らかにする: 監査ソリューションのエンド ツー エンドの作成とサポートに関係するチームを決めます。
• ユーザー アクセス許可を決定する: 監査データにアクセスするためにユーザー アクセス許可を設定する方法を決めます。 後で参照できるように、重要な決定事項のドキュメントを作成します。
• 役割と責任を決定する: 誰が何を行うのかについて想定されることを明確にします (特に複数のチームが関与している場合)。 役割と責任に関するドキュメントを作成します。これには、想定されるアクションが含まれます。
• 役割と責任を割り当てる: 特定のユーザーまたはチームに、特定の役割と責任を割り当てます。 必要に応じて、人事部が個々の職務の説明を更新します。
• トレーニング計画を作成する: 新しいスキルが必要な場合は、担当者のトレーニング計画を作成します。
• クロストレーニング計画を作成する: 主要な役割について、クロストレーニングとバックアップが行われるようにします。

技術に関する決定

テナント レベルの監査ソリューションを計画する場合は、技術に関していくつかの重要な決定を行う必要があります。 一貫性を向上させ、やり直しを避け、セキュリティを強化するため、できるだけ早くこれらの決定を行うことをお勧めします。

最初の計画フェーズでは、次のことを決めす。

• 監査データにアクセスするための技術を選択する
• 認証方法を決定する
• ユーザー API または管理 API を選択する
• API または PowerShell コマンドレットを選択する
• 監査データを格納する場所を決定する
• キュレーションされたデータの作成を計画する

監査データにアクセスするための技術を選択する

最初に決める必要があるのは、監査データにのアクセスする "方法" です。

作業を開始する最も簡単な方法は、管理者モニタリング ワークスペースに用意された、事前構築済みのレポートを使用することです。

データに直接アクセスし、独自のソリューションを構築する必要がある場合は、API (アプリケーション プログラム インターフェイス) を使用します。 API は、インターネット経由でデータを交換するように設計されています。 Power BI REST API では、HTTP プロトコルを使ったデータの要求がサポートされています。 HTTP 要求を送信して JSON 応答を受信できる場合、任意の言語またはツールを使って Power BI REST API を呼び出すことができます。

ヒント

PowerShell コマンドレットでは、監査データへのアクセスに Power BI REST API が使われます。 詳しくは、後の「API または PowerShell コマンドレットを選択する」をご覧ください。

このセクションでは、技術の選択に焦点を当てます。 "特定の種類" の監査データにアクセスするためのソースに関する考慮事項については、後の「データ ソースの決定」をご覧ください。

プラットフォームのオプション

監査データにアクセスするには、さまざまな方法があります。 選んだ技術によっては、好みの言語を使いたくなるかもしれません。 また、スクリプトの実行をスケジュールする方法について、具体的に決定することが必要な場合もあります。 技術は、学習曲線と始めやすさに大きな違いがあります。

ここでは、Power BI REST API を使ってデータを取得するために使用できる技術をいくつか示します。

テクノロジ	手動監査プロセスに適した選択	自動監査プロセスに適した選択
管理監視ワークスペース
使ってみる
PowerShell
Power BI Desktop
Power Automate
好みの Azure サービス
好みのツール/言語
Microsoft Purview 監査ログ検索
Defender for Cloud Apps
Microsoft Sentinel

このセクションの残りの部分では、表で示されている各オプションについて簡単に説明します。

管理監視ワークスペース

管理者モニタリング ワークスペースには、Power BI サービスの事前定義済みレポートとセマンティック モデルが含まれています。 これは、Fabric 管理者が最近の監査データを表示し、ユーザー アクティビティを把握するのに便利な方法です。

API ドキュメントでの "使ってみる"

"使ってみる" は、Microsoft ドキュメントで Power BI REST API を直接体験できる対話型ツールです。 他のツールやコンピューターでのセットアップが必要ないため、API を簡単に調べることができます。

"使ってみる" を使うと、次のことができます。

• 要求を API に手動で送信して、必要な情報を返すかどうかを確認します。
• スクリプトを記述する前に、URL がどのように構築されるのかを学習します。
• 非公式な方法でデータを調べます。

注意

"使ってみる" を使うには、Power BI ユーザーとしてライセンスを付与され、認証を行う必要があります。 標準のアクセス許可モデルに従っているので、ユーザー API はユーザーのアクセス許可に依存し、管理 API には Power BI 管理者のアクセス許可が必要です。 サービス プリンシパルを使って "使ってみる" の認証を行うことはできません。

"使ってみる" は、対話型であるため、学習、探索、新しい手動監査プロセスに最適です。

PowerShell と Azure Cloud Shell

PowerShell スクリプトは、複数の方法で作成して実行できます。

いくつかの一般的なオプションを次に示します。

• Visual Studio Code: 最新で軽量のソース コード エディター。 これは、自由に利用できるオープンソース ツールであり、Windows、macOS、Linux などの複数のプラットフォームでサポートされています。 Visual Studio Code は、PowerShell (PowerShell 拡張機能を使用) などの多くの言語で使用できます。
• Azure Data Studio: スクリプトとノートブックを作成するためのツール。 Visual Studio Code を基に構築されています。 Azure Data Studio は、単独で、または SQL Server Management Studio (SSMS) で使用できます。 PowerShell 用の拡張機能など、多くの拡張機能があります。
• Azure Cloud Shell: ローカル環境に代わる PowerShell の使用環境。 Azure Cloud Shell はブラウザーからアクセスできます。
• Azure Functions: ローカル環境に代わる PowerShell の使用環境。 Azure Functions は、サーバーレス環境でコードを記述して実行できる Azure サービスです。 PowerShell は、サポートされている複数の言語の 1 つです。

重要

すべての新規開発作業で、最新バージョンの PowerShell (PowerShell Core) を使うことをお勧めします。 Windows PowerShell (PowerShell Core を実行できません) の使用を中止し、代わりに PowerShell Core をサポートする最新のコード エディターのいずれかを使う必要があります。 Windows PowerShell (バージョン 5.1) を使っている多くのオンライン例を参照するときは、最新の (より優れた) コード アプローチが使われていない可能性があるため、注意してください。

PowerShell は、いくつかの異なる方法で使用できます。 この技術に関する決定について詳しくは、後の「API または PowerShell コマンドレットを選択する」をご覧ください。

PowerShell の使用に関する多くのオンライン リソースがあり、多くの場合、PowerShell ソリューションを作成して管理できる経験豊富な開発者を見つけることができます。 PowerShell は、手動と自動両方の監査プロセスの作成に適しています。

Power BI Desktop

Power BI Desktop は API に接続できるため、それを使って監査ソリューションを構築したくなることがあります。 しかし、いくつかの重要な欠点と複雑な点があります。

• 履歴の蓄積: Power BI のアクティビティ ログで提供されるデータは最大 30 日なので、総合的な監査ソリューションを作成するには、すべての履歴イベントを格納する一連のファイルを時間の経過と共に蓄積する必要があります。 履歴ファイルの蓄積は、他のツールで実現する方が簡単です。
• 資格情報とキーの安全な取り扱い: オンラインで見つかるコミュニティ ブロガーの多くのソリューションは、Power Query クエリ内に資格情報とキーがプレーンテキストでハードコーディングされるため、安全ではありません。 その方法は簡単ですが、Power BI Desktop ファイルを取得することで誰でもその値を読めるため、お勧めしません。 次のようにしない限り、パスワード (ユーザー認証を使う場合) またはシークレット (サービス プリンシパルを使う場合) を Power BI Desktop に安全に格納することはできません。
  • Power Query SDK で開発されたカスタム コネクタを使います。 たとえば、カスタム コネクタを使うと、Azure Key Vault または暗号化された値を安全に格納する別のサービスから、機密の値を読み取ることができます。 また、グローバルな Power BI コミュニティから、さまざまなカスタム コネクタ オプションも使用できます。
  • Power BI Desktop で問題なく動作する ApiKeyName オプションを使います。 ただし、キーの値を Power BI サービスに格納することはできません。
• 要求の種類: Power BI Desktop で実行できるものに関して、いくつかの制限が適用される可能性があります。 たとえば、Power Query ではすべての種類の API 要求はサポートされません。 たとえば、Web.Contents 関数を使うときは、GET と POST 要求のみがサポートされます。 監査の場合、通常は GET 要求を送信します。
• 最新の情報に更新する機能: Power BI サービスでセマンティック モデルを最新の状態に正しく更新するには、Power Query の特定の開発パターンに従う必要があります。 たとえば、Power BI サービスでエラーを発生させずに Power BI でデータ ソースの場所を適切に確認できるよう、Web.Contents を使うきは RelativePath オプションを指定する必要があります。

ほとんどの場合、Power BI Desktop は 2 つの目的にのみ使うことをお勧めします。 次のために使う必要があります。

• 既存のキュレーションされたデータに基づいてデータ モデルを構築します (それを使って最初に監査データを抽出するのではなく)。
• データ モデルに基づいて分析レポートを作成します。

Power Automate

Power BI では、多くの方法で Power Automate を使用できます。 監査関連では、Power Automate を使って Power BI REST API に要求を送信した後、抽出されたデータを任意の場所に格納できます。

ヒント

Power BI REST API に要求を送信するには、Power Automate 用のカスタム コネクタを使って、監査データの認証と抽出を安全に行うことができます。 または、Azure Key Vault を使ってパスワードまたはシークレットを参照することもできます。 どちらのオプションも、Power Automate フロー内でパスワードとシークレットをプレーンテキストで格納するより優れています。

Power Automate を使う方法に関するその他のアイデアについては、Power Automate テンプレートのページで Power BI を検索してください。

好みの Azure サービス

Power BI REST API に要求を送信できる Azure サービスがいくつかあります。 次のような好みの Azure サービスを使用できます。

• Azure Functions
• Azure Automation
• Azure Data Factory
• Azure Synapse Analytics

ほとんどの場合、データ抽出のロジックを処理するコンピューティング サービスと、生データ (および必要に応じてキュレーションされたデータ) を格納するストレージ サービスを、組み合わせることができます。 技術的なアーキテクチャの決定に関する考慮事項については、この記事で後ほど説明します。

好みのツールや言語

好みのツールと好みの言語を使って、Power BI REST API に要求を送信できます。 これは、次のような特定のツールや言語に関する専門知識をチームが持っている場合に適したアプローチです。

• Python
• .NET framework での C#。 必要に応じて、Power BI .NET SDK を使用できます。これは、Power BI REST API 上のラッパーとして機能し、一部のプロセスを簡略化して、生産性を向上させます。
• JavaScript

Microsoft Purview 監査検索

Microsoft Purview コンプライアンス ポータル (以前の Microsoft 365 コンプライアンス センター) に含まれるユーザー インターフェイスを使うと、監査ログを表示して検索できます。 統合監査ログには、Power BI と、Microsoft 365 統合監査ログをサポートする他のすべてのサービスが含まれます。

統合監査ログにキャプチャされるデータは、Power BI アクティビティ ログに含まれているのとまったく同じデータです。 Microsoft Purview コンプライアンス ポータルで監査ログの検索を実行すると、キューに要求が追加されます。 データの準備ができるまで、数分 (データの量によってはそれより長く) かかる可能性があります。

監査ログ検索ツールを使う一般的な方法を次に示します。 次のようにすることができます。

• Power BI ワークロードを選んで、一連の日付のイベントを表示します。
• 次のような 1 つ以上の特定のアクティビティを探します。
  • Power BI レポートを削除しました
  • Power BI の個人用ワークスペースに管理者のアクセス権を追加した
• 1 人以上のユーザーのアクティビティを表示します。

十分なアクセス許可を持つ管理者の場合、Microsoft Purview コンプライアンス ポータルの監査ログ検索ツールは、手動監査プロセスに適したオプションです。 詳しくは、後の「Microsoft Purview コンプライアンス ポータル」をご覧ください。

Defender for Cloud Apps のユーザー インターフェイス

Microsoft Defender XDR の管理者は、Defender for Cloud Apps を利用できます (Microsoft 365 ポータル)。 これには、Power BI などのさまざまなクラウド サービスのアクティビティ ログの表示と検索を行うためのユーザー インターフェイスが含まれています。 そこには、Microsoft Entra ID のユーザー サインイン アクティビティなどの他のイベントに加えて、Microsoft Purview コンプライアンス ポータルで発生する同じログ イベントが表示されます。

Defender for Cloud Apps の監査ログ インターフェイスは、手動監査プロセスに適したオプションです。 詳しくは、後の「Defender for Cloud Apps」をご覧ください。

Microsoft Sentinel と KQL

Microsoft Sentinel は、セキュリティ インシデントや脅威を収集、検出、調査、対応できる Azure サービスです。 Microsoft Sentinel では、監査ログが Power BI から Microsoft Sentinel Azure Log Analytics (Azure Monitor サービスのコンポーネント) にストリーミングされるように、Power BI をデータ コネクタとして設定できます。 Kusto 照会言語 (KQL) を使って、Azure Log Analytics に格納されているアクティビティ ログ イベントを分析できます。

KQL を使った Azure Monitor のデータの検索は、監査ログの一部を表示するための優れたオプションです。 手動監査プロセスにも適しています。 詳しくは、後の「Microsoft Sentinel」をご覧ください。

プラットフォームに関する考慮事項

監査データにアクセスする方法に関するいくつかの考慮事項を次に示します。

• 実装している監査プロセスは手動か自動か? 特定のツールは、手動処理または自動処理と強く結び付いています。 たとえば、"使ってみる" 機能は、ユーザーが常に対話形式で実行するため、手動監査プロセスにのみ適しています。
• どのようにして認証を行うか? すべてのオプションですべての認証オプションがサポートされてはいません。 たとえば、"使ってみる" 機能ではユーザー認証のみがサポートされます。
• どのような方法で資格情報を安全に格納するか? 資格情報を格納するためのオプションは、技術によって異なります。 詳しくは、後の「認証方法を決定する」をご覧ください。
• チームが既に熟練している技術はどれか? チームが好む使い慣れたツールがある場合は、そこから始めます。
• チームがサポートできるものは何か? デプロイされたソリューションを別のチームがサポートする場合は、そのチームがそれを適切にサポートできるかどうかを検討します。 また、コンサルタントによって行われた開発を社内チームがサポートする可能性があることも考慮します。
• 使用の承認を得ているツールは何か? 特定のツールと技術では、承認が必要になる場合があります。 それはコストが原因である可能性があります。 また、IT セキュリティ ポリシーが原因である可能性もあります。
• どのようなスケジュール設定が好ましいか? 技術によっては自動的に決定されます。 そうでない場合は、ユーザーが別の決定を行う必要があります。 たとえば、PowerShell スクリプトを記述する場合は、さまざまな方法で実行をスケジュールできます。 逆に、Azure Data Factory などのクラウド サービスを使う場合は、スケジュールが組み込まれます。

監査データにアクセスする技術を選ぶ前に、この記事の残りの部分を確認することをお勧めします。

チェックリスト - 監査データへのアクセスに使う技術を決めるときの主な決定事項とアクションは次のとおりです。

• IT スタッフと話し合う: IT チームと話し合って、承認されている、または望ましい特定のツールがあるかどうかを確認します。
• 小さな概念実証 (POC) を使ってオプションを調べる: 技術的な POC を使って実験します。 最初は学習に集中します。 その後、今後使うものの決定に焦点を当てます。

認証方法を決定する

認証の設定をどのように計画するかは、重要な決定です。 多くの場合、監査と監視を開始する際に最も困難な側面の 1 つです。 利用できるオプションを慎重に検討し、情報に基づいて決定する必要があります。

重要

IT およびセキュリティ チームと、この問題について話し合います。 時間を取って Microsoft Entra ID のセキュリティのしくみの基本について学習してください。

インターネット上のすべての API で認証が必要なわけではありません。 ただし、すべての Power BI REST API には認証が必要です。 テナント レベルの監査データにアクセスするときの認証プロセスは、Microsoft ID プラットフォームによって管理されます。 これは、業界標準のプロトコルに基づいて構築された Microsoft Entra ID サービスの進化形です。

ヒント

Microsoft ID プラットフォームの用語集は、基本的な概念を理解するのに役立つリソースです。

監査データを取得する前にまず、"認証" を行う必要があります。これは "サインイン" と呼ばれます。 認証と認可は異なる概念ですが、関連しています。 "認証" プロセスでは、要求を行っている "ユーザー" の身元が検証されます。 "認可" プロセスでは、ユーザーまたはサービス プリンシパルが実行するアクセス許可を持っている "こと" を検証することで、システムまたはリソースへのアクセスを許可 (または拒否) します。

ユーザーまたはサービス プリンシパルが認証を行うと、Power BI REST API や Microsoft Graph API などのリソース サーバーに対して Microsoft Entra アクセス トークンが発行されます。 既定では、アクセス トークンは 1 時間後に有効期限が切れます。 必要があれば、更新トークンを要求できます。

アクセス トークンには、次の 2 種類があります。

• ユーザー トークン: 既知の ID を持つユーザーのために発行されます。
• アプリ専用トークン: Microsoft Entra アプリケーション (サービス プリンシパル) のために発行されます。

詳細については、Microsoft Entra ID プラットフォームのアプリケーションとサービス プリンシパルのオブジェクトに関するページを参照してください。

Note

Microsoft Entra アプリケーションは、自動化されたプロセスを Microsoft Entra ID と統合できるようにする ID 構成です。 この記事では、"アプリの登録" と呼んでいます。 "サービス プリンシパル" という用語もこの記事で一般的に使っています。 これらの用語については、このセクションで後ほど詳しく説明します。

ヒント

認証を行う最も簡単な方法は、Power BI Management モジュールの Connect-PowerBIServiceAccount コマンドレットを使うことです。 オンラインの記事やブログ記事では、他の認証関連のコマンドレットを目にすることがあります。 たとえば、Login-PowerBI や Login-PowerBIServiceAccount というコマンドレットがありますが、これらは Connect-PowerBIServiceAccount コマンドレットのエイリアスです。 また、プロセスの最後で明示的にサインアウトするために使用できる Disconnect-PowerBIServiceAccount コマンドレットもあります。

次の表では、2 つの認証オプションについて説明します。

認証の種類	説明	対象者	手動監査プロセスに適した選択	自動監査プロセスに適した選択
ユーザー認証	ユーザー プリンシパル名 (メール アドレス) とパスワードを使って、ユーザーとしてサインインします。	予備的、対話形式での使用
サービス プリンシパルの認証	アプリの登録に割り当てられたシークレット (キー) を使って、サービス プリンシパルとしてサインインします。	継続的、スケジュール、無人操作

各認証オプションについては、次のセクションで詳しく説明します。

ユーザー認証

ユーザー認証は、次の状況で役に立ちます。

• 手動監査プロセス: ユーザー アクセス許可を使ってスクリプトを実行する場合。 アクセス許可は、API 要求の種類に応じて、2 つのレベルのいずれかを使用できます。
  • 管理 API の管理者アクセス許可: "管理 API" に要求を送信するには、Power BI 管理者のアクセス許可を使う必要があります。
  • ユーザー API のユーザー アクセス許可: "ユーザー API" に要求を送信するには、Power BI ユーザーのアクセス許可を使う必要があります。 詳しくは、「ユーザー API または管理 API を選択する」をご覧ください。
• 対話型サインイン: 対話形式でサインインする場合。メール アドレスとパスワードを入力する必要があります。 たとえば、Microsoft API のドキュメントにある "使ってみる" エクスペリエンスを使うには、対話形式でサインインする必要があります。
• テナントのメタデータにアクセスしたユーザーを追跡する: 個々のユーザーや管理者が API 要求を送信したときに、それらのユーザーが誰であるかを監査することが必要な場合があります。 サービス プリンシパルで認証を行うときは (次に説明します)、アクティビティ ログによってキャプチャされるユーザー ID はアプリケーション ID です。 複数の管理者が同じサービス プリンシパルを使って認証を行う場合、データにアクセスした管理者がわかりにくいことがあります。
• 共有管理者アカウント: IT チームでは、共有管理者アカウントが使われることがあります。 実装方法と制御方法によっては、ベスト プラクティスではない場合があります。 共有アカウントの代わりに、Microsoft Entra の Privileged Identity Management (PIM) の使用を検討する必要があります。これは、ユーザーに対して一時的な Power BI 管理者権限を付与できます。
• ユーザー認証のみをサポートする API: 場合によっては、サービス プリンシパルによる認証をサポートしていない API を使うことが必要になる場合があります。 ドキュメントでは、API ごとに、サービス プリンシパルでそれを呼び出せるかどうかが示されています。

重要

可能な限り、自動プロセスにはサービス プリンシパル認証を使うことをお勧めします。

サービス プリンシパルの認証

ほとんどの組織に存在する Microsoft Entra テナントは 1 つであるため、用語 "アプリの登録" と "サービス プリンシパル" は同じ意味で使用される傾向があります。 Microsoft Entra アプリを登録するときに、2 つのコンポーネントがあります。

• アプリの登録:アプリの登録はグローバルに一意です。 これは、複数のテナントで使用できる登録済み Microsoft Entra アプリのグローバル定義です。 アプリの登録は、"クライアント アプリケーション" または "アクター" とも呼ばれます。 通常、"クライアント アプリケーション" という用語はユーザー コンピューターを意味します。 ただし、アプリの登録の場合はそうではありません。 Azure portal では、Microsoft Entra アプリケーションは、Microsoft Entra ID の [アプリの登録] ページにあります。
• サービス プリンシパル:サービス プリンシパルは、特定のテナントで使用するアプリ登録のローカル表現です。 サービス プリンシパルは、登録済み Microsoft Entra アプリから派生します。 複数の Microsoft Entra テナントを持つ組織の場合、同じアプリ登録を複数のサービス プリンシパルで参照できます。 Azure portal では、サービス プリンシパルは、Microsoft Entra ID の [エンタープライズ アプリケーション] ページにあります。

サービス プリンシパルはローカル表現であるため、サインインを参照する最も一般的な方法は "サービス プリンシパル認証" という用語です。

ヒント

Microsoft Entra 管理者は、組織内のアプリ登録の作成と同意を許可されているユーザーを通知できます。

サービス プリンシパル認証は、次の状況で役に立ちます。

• 自動監査プロセス: スケジュールに従って無人プロセスを実行する場合。
• Power BI サービスにサインインする必要がない: 接続してデータを抽出することだけが必要な場合。 サービス プリンシパルは、Power BI サービスにサインインできません。
• データへの共有アクセス: (個人的には) Power BI 管理者ではないが、サービス プリンシパルの使用を認可されている場合。 サービス プリンシパルには、管理 API を実行してテナント レベルのデータを取得するアクセス許可があります (または他の特定のアクセス許可)。
• 複数の管理者による使用: 複数の管理者またはユーザーが同じサービス プリンシパルを使用できるようにする場合。
• 技術的な阻害要因: ユーザー認証の使用を妨げる技術的な阻害要因がある場合。 一般的な技術的阻害要因は次のとおりです。
  • 多要素認証 (MFA): 多要素認証が有効になっている場合、自動監査プロセス (無人で実行) はユーザー アカウントを使って認証できません。
  • パスワード ハッシュ同期: Microsoft Entra ID でユーザー アカウントが認証するにはパスワード ハッシュ同期が必要です。 場合によっては、IT またはサイバーセキュリティ チームによってこの機能が無効にされていることがあります。

アプリの登録の目的と名前付け規則

各アプリの登録には、その目的と対象ユーザー (アプリの登録を使用できるユーザー) を説明する明確な名前が必要です。

"<ワークロード> - <目的> - <対象ユーザー> - <オブジェクトの種類>" のような名前付け規則を実装することを検討します

名前付け規則の各部分は次のとおりです。

• ワークロード: 通常、データ ソース (Power BI データ、Microsoft Graph データなど) と同じです。
• 目的: アクセス許可のレベルに似ています (たとえば、Read と ReadWrite)。 以下で説明するように、この目的は、データを読み取ることだけができる個別のアプリの登録を作成するときに、最小特権の原則に従うのに役立ちます。
• 対象ユーザー: 省略可能。 ワークロードと目的によっては、対象ユーザーを使ってアプリの登録の想定されるユーザーを決定できます。
• オブジェクトの種類: 明確にするために EntraApp を含めます。

複数のテナントまたは複数の環境 (開発と運用など) がある場合は、名前付け規則をより具体的にすることができます。

次の表では、テナント レベルの監査データを抽出するために使用できるアプリの登録の例を示します。

アプリの登録の名前	目的	対象読者
PowerBIData-Read-AdminAPIs-EntraApp	Power BI の監査と管理のために、テナント全体のメタデータを抽出します。 管理 API は常に読み取り専用であり、Microsoft Entra ID でアクセス許可が付与されていない可能性があります (Power BI テナント設定のみ)。	Power BI 管理者とセンター オブ エクセレンス
PowerBIData-ReadWrite-PowerBIAdministrators-EntraApp	Power BI テナントを管理します。 リソースを作成または更新するには、読み取り/書き込みアクセス許可が必要です。	Power BI 管理者とセンター オブ エクセレンス
GraphData-Read-PowerBIAdministrators-EntraApp	Power BI の監査と管理のために、ユーザーとグループのデータを抽出します。 読み取りアクセス許可が必要です。	Power BI 管理者とセンター オブ エクセレンス

異なる目的のために複数のアプリの登録を管理する場合は、さらに多くの作業が必要になります。 ただし、いくつかの利点をがあります。

• アプリの登録の使用 "目的" とその理由を示す: 監査データで示されるアプリの登録のクライアント ID を見ると、それが何のために、なぜ使われたかがわかります。 これは、(すべての目的に 1 つだけを使うのではなく) 個別にアプリの登録を作成する大きな利点です。
• アプリの登録を使うことが "想定されている" ユーザーを示す: 監査データで示されるアプリの登録のクライアント ID を見ると、それが何のために、誰がそれを使っていたかがわかります。
• アクセス許可の過剰なプロビジョニングを避ける: 異なるニーズを持つ異なるユーザーのセットに個別のアプリの登録を提供することで、最小特権の原則に従うことができます。 書き込みアクセス許可が必要ない場合は、読み取り専用のアプリの登録を使うことで、アクセス許可の過剰なプロビジョニングを回避できます。 たとえば、自分のセマンティック モデルに関するデータの収集を望んでいる、高度な能力を持つセルフサービス ユーザーがいる場合、そのようなユーザーは "読み取り" アクセス許可を持つサービス プリンシパルにアクセスする必要があります。 一方、財務チームのために働いていて、プログラムでセマンティック モデルを管理する、センター オブ エクセレンスのサテライト メンバーがいる場合、そのようなユーザーは "書き込み" アクセス許可を持つサービス プリンシパルにアクセスする必要があります。
• シークレットを所有する "必要がある" ユーザーを把握する: 各アプリの登録のシークレットは、それを必要とするユーザーとだけ共有する必要があります。 シークレットを "ローテーションする" (このセクションで後述) ときの影響は、異なるニーズごとに個別のアプリの登録を使う方が小さくなります。 これは、ユーザーが組織を離れたり、役割を変更したりするために、シークレットをローテーションする必要がある場合に役立ちます。

アプリの登録とアクセス許可

アプリの登録でデータとリソースにアクセスするには、主に 2 つの方法があります。 これには、アクセス許可と同意が関係します。

• アプリ専用のアクセス許可: アクセスと承認は、ユーザーがサインインすることなしに、サービス プリンシパルによって処理されます。 この認証方法は、自動シナリオで役に立ちます。 アプリ専用のアクセス許可を使用するときは、Microsoft Entra ID でアクセス許可が割り当てられ "ない" ことを理解しておくことが重要です。 そうではなく、次の 2 つの方法のいずれかでアクセス許可が割り当てられます。
  • 管理 API を実行する場合: 特定の Power BI テナント設定により、(テナント全体の監査メタデータを返す) 管理 API のエンドポイントへのアクセスが許可されます。 詳しくは、後の「Power BI テナントの設定を行う」をご覧ください。
  • ユーザー API を実行する場合: Power BI のワークスペースとアイテムのアクセス許可が適用されます。 Power BI の標準のアクセス許可により、(API を呼び出しているユーザーまたはサービス プリンシパルのアクセス許可に基づいて監査データを返す) ユーザー API の実行時にサービス プリンシパルに返すことができるデータが制御されます。
• 委任されたアクセス許可: スコープに基づくアクセス許可が使われます。 サービス プリンシパルは、現在サインインしているユーザーに代わってデータにアクセスします。 つまり、サービス プリンシパルは、サインインしているユーザーがアクセスできるもの以外にはアクセスできません。 これは、前に説明したユーザー専用の認証とは異なる概念であることに注意してください。 ユーザーとアプリのアクセス許可の組み合わせをカスタム アプリケーションで適切に処理する必要があるため、委任されたアクセス許可が監査シナリオに使われることはほとんどありません。 この概念は誤解されることがよくあり、そのために多くのアプリの登録でアクセス許可が過剰にプロビジョニングされます。

重要

この記事の対象は、ユーザー認証またはアプリ専用認証だけです。 Power BI のコンテンツをプログラムで埋め込むときは、(対話型ユーザーとサービス プリンシパルでの) 委任されたアクセス許可が重要な役割を果たす可能性があります。 ただし、監査データを抽出するためには委任されたアクセス許可を設定しないことを強くお勧めします。 すべての API では、実行できる頻度が (スロットリングの適用により) 制限されるため、異なるユーザーが生の監査データに直接アクセスすることは現実的ではありません。 代わりに、(一元化されたプロセスで) 生の監査データを 1 回抽出した後、キュレーションされた監査データを下流の承認されたユーザーが使用できるようにすることをお勧めします。

詳しくは、後の「Microsoft Entra アプリを登録する」を参照してください。

アプリの登録のシークレット

多くの場合、アプリの登録には "シークレット" が割り当てられます。 シークレットは認証のためのキーとして使われ、有効期限があります。 そのため、キーを定期的にローテーションする方法と、承認されたユーザーに新しいキーを伝える方法を、計画する必要があります。

また、シークレットを安全に保管する場所についても注意する必要があります。 Azure Key Vault などの組織のパスワード コンテナーは、優れた選択肢です。

ヒント

シークレットを使うための別のアプローチとしては、"マネージド ID" を使用できます。 マネージド ID を使うと、資格情報を管理する必要がなくなります。 Azure Functions や Azure Data Factory などのサービスを使ってデータを抽出する場合は、マネージド ID を調べることをお勧めします。

資格情報を安全に管理する

ユーザー認証とサービス プリンシパル認証のどちらを使うかに関係なく、最大の課題の 1 つは、パスワード、シークレット、キーを安全に管理する方法です。

注意事項

1 つ目のルールは、多くのユーザーが違反するルールであり、スクリプト内でパスワードとキーをプレーンテキストで使用してはならない、というものです。 オンラインの多くの記事、ブログ、例では、わかりやすくするためにこれが行われています。 しかし、これは避けなければならない不適切なやり方です。 スクリプト (またはファイル) を取得したすべてのユーザーは、作成者がアクセスできるのと同じデータにアクセスできる可能性があります。

パスワード、シークレット、キーの管理に使用できる安全な方法をいくつか次に示します。

• 可能な限り、Azure Key Vault や他の組織パスワード コンテナー システムと統合します。
• PowerShell スクリプトで資格情報とセキュリティで保護された文字列を使います。 資格情報は、ユーザー認証とサービス プリンシパル認証の両方で機能します。 ただし、ユーザー アカウントで多要素認証が有効になっている場合は、資格情報を使用できません。
• PowerShell スクリプトでパスワードの入力を求めるか、ブラウザーで対話型認証を使います。
• Microsoft によって公開されている PowerShell 用のシークレット管理モジュールを使います。 ローカル コンテナーを使って値を格納できます。 また、リモート環境の Azure Key Vault と統合することもでき、同じスクリプトで作業する複数の管理者が組織にいる場合に便利です。
• 資格情報を安全に処理できるように、Power BI Desktop 用のカスタム コネクタを作成します。 コミュニティ メンバー (通常は GitHub) から入手できるカスタム コネクタがいくつかあります。

ヒント

最適な方法を選べるように IT チームとセキュリティ チームに相談するか、ソリューションが安全な方法で資格情報を管理していることを検証することをお勧めします。

Microsoft Authentication Library

Azure AD 認証ライブラリ (ADAL) のサポートは 2022 年 12 月で終了しました。 今後は、Microsoft Authentication Library (MSAL) を使う必要があります。 組織のセキュリティ チームは、この重要な変更についてよく理解している必要があります。

Power BI の専門家が MSAL への移行について深く理解することは重要ではありませんが、次の推奨事項に従う必要があります。

• Connect-PowerBIServiceAccount PowerShell コマンドレットを使って認証を行う場合は、Power BI Management モジュールの最新バージョンを使います。 それは、バージョン 1.0.946 (2021 年 2 月 26 日) で ADAL から MSAL に切り替わりました。
• スクリプトで直接認証を行うときは、Microsoft Entra V2 エンドポイントを使用します。 Microsoft Entra V1 エンドポイントは ADAL を使用しますが、Microsoft Entra V2 エンドポイントは MSAL を使用します。
• 非推奨の API とモジュールの使用を中止します。 詳しくは、後の「非推奨の API とモジュール」をご覧ください。
• オンラインでコミュニティ ソリューションを探す場合は、ADAL ではなく MSAL が認証に使われていることを確認してください。

チェックリスト – 認証の管理方法を決めるときの主な決定事項とアクションは次のとおりです。

• 使用する認証の種類を決める: 作成する監査ソリューションの種類に基づいて、ユーザー認証とサービス プリンシパル認証のどちらが最も適しているかを判断します。
• 必要なアプリの登録を計画する: 要件、ワークロード、対象ユーザー (各アプリの登録のユーザー) を検討します。 これらのニーズをサポートするために作成する必要があるアプリの登録の数を計画します。
• アプリの登録の名前付け規則を作成する: 各アプリの登録の想定されている目的とユーザーを簡単に理解できるような名前付け規則を設定します。
• 資格情報を安全に管理する方法を計画する: パスワード、シークレット、キーを安全に管理する方法を検討します。 必要なドキュメントとトレーニングを検討します。
• MSAL の使用を確認する: ADAL に依存している既存の手動または自動の監査ソリューションがあるかどうかを確認します。 必要な場合は、新しい MSAL 認証ライブラリを使うようにこれらのソリューションを書き換える計画を作成します。

ユーザー API または管理 API を選択する

監査データの取得を計画するときは、適切な種類の API を使うことが重要です。

2 つの種類の API を検討します。

• ユーザー API: サインインしているユーザー (またはサービス プリンシパル) のアクセス許可に依存して、API に要求を送信します。 たとえば、ワークスペース内のセマンティック モデルの一覧を取得するには、ユーザー API を使うのが 1 つの方法です。 セマンティック モデルを読み取るためのアクセス許可は、ワークスペースのロールまたはアイテムごとのアクセス許可によって付与できます。 ユーザー API を実行するには、次の 2 つの方法があります。
  • ユーザー認証: サインインしているユーザーが、ワークスペースまたはアイテムにアクセスするためのアクセス許可を持っている必要があります。
  • サービス プリンシパル認証: サービス プリンシパルが、ワークスペースまたはアイテムにアクセスするためのアクセス許可を持っている必要があります。
• 管理 API: テナントからメタデータを取得します。 これは、"組織スコープ" と呼ばれることもあります。 たとえば、テナント内のすべてのセマンティック モデルの一覧を取得するには、管理 API を使います。 管理 API を実行するには、次の 2 つの方法があります。
  • ユーザー認証: 管理 API を実行するには、サインインしているユーザーが Power BI 管理者である必要があります。
  • サービス プリンシパル認証: サービス プリンシパルが、管理 API を実行するためのアクセス許可を持っている必要があります (ユーザー API のようにセキュリティ アクセス許可には依存しません)。

ヒント

すべての管理 API は、管理操作グループに属しています。 As Admin というサフィックスが付いている API はすべて管理 API であり、残りの API はすべてユーザー API です。

セマンティック モデルの一覧を取得する必要がある例について考えます。 次の表では、これを行うために使用できる 6 つの API オプションを示します。 4 つのオプションはユーザー API で、2 つのオプションは管理 API です。 返されるアイテムのスコープと数は、選んだ API によって異なります。

API 名	API の種類	スコープ	セマンティック モデルの数
Get Dataset	User	個人のワークスペース	1 つ
データセットの取得	User	個人のワークスペース	すべて
Get Dataset in Group	User	1 つのワークスペース	1 つ、サインインしているユーザーがそのセマンティック モデルを読み取るアクセス許可を持っている場合
Get Datasets in Group	User	1 つのワークスペース	すべて、サインインしているユーザーが各セマンティック モデルを読み取るアクセス許可を持っている場合
Get Datasets in Group as Admin	[Admin]	1 つのワークスペース	すべて
Get Datasets as Admin	[Admin]	テナント全体	すべて

注意

一部の API 名には、ワークスペースへの参照として Group という用語が含まれています。 この用語は、Microsoft 365 グループに依存していた元の Power BI セキュリティ モデルに由来します。 Power BI セキュリティ モデルは長年にわたって大幅に進化してきましたが、既存の API 名は、既存のソリューションを壊さないように変更されないまま残っています。

テナントの設定については、後の「Power BI テナントの設定を行う」をご覧ください。

チェックリスト - ユーザー API と管理 API のどちらを使うか選ぶときの主な決定事項とアクションは次のとおりです。

• データ要件を参照する: 監査ソリューションの主要なビジネス要件を収集して文書化します。 必要なデータの種類に基づいて、ユーザー スコープと組織スコープのどちらが適切かを判断します。
• 結果をテストする: 実験を行います。 さまざまな API によって返される結果の正しさをテストします。
• アクセス許可を確認する: 既存の監査ソリューションの場合は、Power BI 管理者とサービス プリンシパルにアクセス許可が正しく割り当てられていることを確認します。 新しい監査ソリューションの場合は、使われる認証方法を確認します。

API または PowerShell コマンドレットを選択する

重要な決定事項は、取得する特定のデータに対して PowerShell コマンドレットを使用できる場合に、それを使うかどうかです。 この決定は、PowerShell が監査データへのアクセスに使う技術の 1 つであると判断した場合に重要です。

PowerShell は、タスク自動化ソリューションです。 PowerShell という用語は、スクリプト言語、コマンド ライン シェル アプリケーション、構成管理フレームワークを指す集合的な用語です。 PowerShell Core は、Windows、Linux、macOS で実行される PowerShell の最新バージョンです。

PowerShell "コマンドレット" は、アクションを実行するコマンドです。 PowerShell "モジュール" は、コマンドレット、プロバイダー、関数、ワークフロー、変数、エイリアスなどの PowerShell メンバーを含むパッケージです。 モジュールをダウンロードしてインストールします。

PowerShell モジュールにより、API 上に抽象化のレイヤーが作成されます。 たとえば、Get-PowerBIActivityEvent コマンドレットは、Power BI テナントの監査イベントを "取得" します。 この PowerShell コマンドレットは、Get Activity Events REST API からそのデータを取得します。 一般に、コマンドレットを使う方が簡単であり、これは基になる API へのアクセスが簡略化されるためです。

PowerShell コマンドレットとして使用できるのは、API のサブセットのみです。 監査ソリューション全体を拡張し続けていると、コマンドレットと API の組み合わせを使うようになる可能性があります。 このセクションの残りの部分は、データにアクセスする方法を決めるのに役立ちます。

PowerShell モジュール

Microsoft から、Power BI に関連するコマンドレットを含む 2 つの PowerShell モジュールが公開されています。 Power BI Management モジュールと Data Gateway モジュールです。 これらの PowerShell モジュールは、基になる Power BI REST API 上の "API ラッパー" として機能します。 これらの PowerShell モジュールを使うと、スクリプトを簡単に記述できます。

ヒント

Microsoft によって公開されているモジュールに加えて、Power BI コミュニティ メンバー、パートナー、Microsoft Most Valued Professional (MVP) によって公開されている PowerShell モジュールとスクリプト (通常は GitHub) を自由に使用できます。

コミュニティ ソリューションから始めることは、エンド ツー エンドの監査ソリューションの構築において重要な役割を果たす場合があります。 自由に利用できるソリューションを使う場合は、必ず完全にテストしてください。 ソリューションを効果的に管理できるよう、時間をかけてそのしくみをよく理解してください。 IT 部署により、一般公開されたコミュニティ ソリューションの使用に関する基準が設けられている場合があります。

Power BI Management モジュール

Power BI Management モジュールは、管理、容量、ワークスペースなどの特定の Power BI モジュールを含むロールアップ モジュールです。 ロールアップ モジュールをインストールしてすべてのモジュールを取得することも、特定のモジュールをインストールすることもできます。 すべての Power BI Management モジュールは、Windows PowerShell と PowerShell Core の両方でサポートされています。

重要

Windows PowerShell の使用を中止することをお勧めします (PowerShell Core を実行できません)。 代わりに、PowerShell Core をサポートする最新のコード エディターのいずれかを使ってください。 Windows PowerShell ISE (統合スクリプト環境) では、更新されなくなった PowerShell バージョン 5.1 のみを実行できます。 Windows PowerShell は非推奨になっているため、すべての新規開発作業に PowerShell Core を使うことをお勧めします。

監査データの取得によく使われるいくつかのコマンドレットを次に示します。

管理モジュール	コマンドレット	目的
プロファイル	Connect-PowerBIServiceAccount	Power BI ユーザーまたはサービス プリンシパルの認証を行います。
[Admin]	Get-PowerBIActivityEvent	テナントの Power BI アクティビティ ログ イベントを表示または抽出します。
ワークスペース	Get PowerBIWorkspace	ワークスペースの一覧を作成します。
Reports	Get-PowerBIReport	ワークスペースまたはテナントのレポートの一覧を作成します。
Data	Get PowerBIDataset	ワークスペースまたはテナントのセマンティック モデルの一覧を作成します。
プロファイル	Invoke-PowerBIRestMethod	REST API 要求 (コマンド) を送信します。 このコマンドレットは、任意の Power BI REST API を呼び出すことができるため、適切なオプションです。 また、Connect-PowerBIServiceAccount コマンドレットを使ってより簡単な形式の認証を使いたい場合と、対応する PowerShell コマンドレットがない API を呼び出したい場合にも適しています。 詳しくは、このセクションで後述する「PowerShell コマンドレットを使用する場合の考慮事項」をご覧ください。

ヒント

コンテンツの管理と発行に使用できるコマンドレットは他にもあります。 ただし、この記事の焦点は監査データの取得です。

Power BI Management モジュールは、PowerShell ギャラリーからダウンロードできます。 モジュールをインストールする最も簡単な方法は、PowerShellGet を使うことです。

Power BI Management ロールアップ モジュールをインストールすることをお勧めします。 そうすることで、必要になる可能性のあるすべてのコマンドレットを使用できます。 少なくとも、プロファイル モジュール (認証用) と、使いたいコマンドレットを含む特定のモジュールが必要です。

注意事項

PowerShell を使うすべてのサーバー、ユーザー コンピューター、クラウド サービス (Azure Automation など) で、モジュールを最新の状態に保つようにしてください。 モジュールを定期的に更新しないと、予期しないエラーや問題が発生する可能性があります。 一部のツール (Visual Studio Code など) は、モジュールの更新を維持するのに役立ちます。 また、新しいバージョンをインストールまたは更新しても、PowerShellGet で古いバージョンのモジュールが自動的にアンインストールされないことに注意してください。 古いバージョンと共に新しいバージョンがインストールされます。 インストールされているバージョンをチェックし、古いバージョンを定期的にアンインストールすることをお勧めします。

Data Gateway モジュール

Data Gateway モジュールには、オンプレミスのデータ ゲートウェイとそのデータ ソースからデータを取得するコマンドレットが含まれています。 Data Gateway モジュールは、PowerShell Core でのみサポートされています。 Windows PowerShell ではサポートされていません。

Power BI Management モジュール (前述) とは異なり、Data Gateway モジュールには管理コマンドレットは含まれません。 多くのコマンドレット (および対応する ゲートウェイ API) では、ユーザーがゲートウェイ管理者権限を持っている必要があります。

警告

サービス プリンシパルをゲートウェイ管理者として割り当てすることはできません (サービス プリンシパルがセキュリティ グループのメンバーである場合でも)。 そのため、データ ゲートウェイに関する情報を取得するときは、ユーザー資格情報を使うことを計画してください。

監査データの取得に使用できる Data Gateway モジュールのいくつかのコマンドレットを次に示します。

コマンドレット	目的
Connect-DataGatewayServiceAccount	Power BI ユーザーの認証を行います (通常は、ユーザーがゲートウェイ管理者ロールに属している必要があります)。
Get-DataGatewayCluster	ゲートウェイ クラスターの一覧を作成します。
Get-DataGatewayClusterDataSource	ゲートウェイ クラスターのデータ ソースの一覧を作成します。
Get-DataGatewayInstaller	組織でゲートウェイのインストールと登録を行うことができるユーザーを確認します。

Data Gateway モジュールは、PowerShell ギャラリーからダウンロードできます。

PowerShell を使用する手法

PowerShell は、いくつかの異なる方法で使用できます。 行う決定が重要な意味を持ちます。

次の表では、PowerShell を使う 3 つの異なる手法について説明します。

手法	説明	例
PowerShell コマンドレットを使って認証を簡略化し、API を直接呼び出します。 推奨される方法	この手法は、簡単さと柔軟性のバランスが取れています。 Invoke-PowerBIRestMethod コマンドレットは、Power BI Management Profile モジュールから利用できます。 このコマンドレットは、任意の Power BI REST API の呼び出しに使用できるため、"スイス アーミー ナイフ" と呼ばれることがよくあります。 この手法を使う利点は、認証が簡略化され、すべての Power BI REST API を呼び出すことができる点です。 この手法を使うことを強くお勧めします。	Connect-PowerBIServiceAccount コマンドレットで認証を行った後、Invoke-PowerBIRestMethod コマンドレットを使って、任意の API からデータを取得します (たとえば、Get Pipeline Users As Admin)。
認証とデータの取得の両方に、可能な限り PowerShell のコマンドレットを使います。	この手法では、PowerShell を広範に使います。 PowerShell を使ってスクリプトの実行を調整し、データへのアクセスには可能な限り PowerShell モジュールを使います。 これにより、複数の側面で PowerShell に大きく依存するようになります。	Connect-PowerBIServiceAccount コマンドレットで認証を行った後、コマンドレット (Get-PowerBIActivityEvent など) を使ってデータを取得します。
PowerShell は、プロセスの実行を調整するためにのみ使います。 PowerShell モジュールは、できるだけ使わないようにします。	この手法での PowerShell は、主として API 呼び出しの調整に使われるため、ツールとしての依存度は低くなります。 API にアクセスするために 1 つの汎用 PowerShell モジュールだけが使われます (Power BI Management モジュールのモジュールは使われません)。	Microsoft Authentication Library (MSAL) を使って認証を行った後、汎用の Invoke-RestMethod コマンドレットを使って任意の API (たとえば Get Pipeline Users As Admin) を呼び出して、データを取得します。

上の表の最初の手法では、使いやすさと柔軟性のバランスを取るアプローチが説明されています。 このアプローチが推奨されるのは、ほとんどの組織のニーズに対して最適なバランスが提供されるためです。 組織によっては、既存の IT ポリシーとスタッフの好みが、PowerShell の使用の決定方法に影響を与える場合があります。

ヒント

Invoke-ASCmd PowerShell コマンドレットを使って、DAX、XMLA、TMSL のスクリプトを作成して実行できます。 ただし、これらのユース ケースはこの記事の範囲外です。 動的管理ビュー (DMV) のクエリについて詳しくは、「データ レベルの監査」をご覧ください。

技術ユーザー (および管理者) は、Power BI Management モジュールを使ってデータを取得したり、コンテンツ管理の特定の側面を自動化したりできます。

• 管理者の場合: テナント全体のエンティティにアクセスするには、-Scope パラメーターを Organization に設定します (たとえば、"すべてのワークスペース" の一覧を取得する場合)。
• 技術ユーザーの場合: ユーザーに属するエンティティにアクセスするには、-Scope パラメーターを Individual に設定します (またはパラメーターを省略します) (たとえば、"ユーザーがアクセス許可を持っている" ワークスペースの一覧を取得する場合)。

セマンティック モデルの一覧を取得する必要があるシナリオについて考えます。 API を直接使用する場合は、呼び出す API を指定する必要があります。 一方、Get-PowerBIDataset コマンドレットを使う場合は、-Scope パラメーターを設定して、ユーザー固有またはテナント全体のセマンティック モデルの一覧を取得できます。 どちらを選ぶかは、PowerShell の使用方法の決定によって異なります (前の表で説明しました)。

次の表では、PowerShell コマンドレットで使われるパラメーターが API PowerShell の呼び出しにどのように変換されるかについて説明します。

コマンドレットのパラメーター	コマンドレットで使われる API	API の種類	スコープ	取得されるアイテム
-DatasetID {DatasetID} -Scope Individual	Get Dataset	User	個人のワークスペース	1 つのセマンティック モデル
-Scope Individual	データセットの取得	User	個人のワークスペース	すべてのセマンティック モデル
-DatasetID {DatasetID} -GroupID {WorkspaceID}	Get Dataset in Group	User	1 つのワークスペース	1 つのセマンティック モデル、サインインしているユーザーがそのセマンティック モデルを読み取るアクセス許可を持っている場合
-GroupID {WorkspaceID}	Get Datasets in Group	User	1 つのワークスペース	すべてのセマンティック モデル、サインインしているユーザーがワークスペースにアクセスしてセマンティック モデルを読み取るアクセス許可を持っている場合
-GroupID {WorkspaceID} -Scope Organization	Get Datasets in Group as Admin	[Admin]	1 つのワークスペース	すべてのセマンティック モデル
-Scope Organization	Get Datasets as Admin	[Admin]	テナント全体	すべてのセマンティック モデル

PowerShell コマンドレットを使用する場合の考慮事項

Power BI PowerShell コマンドレットは、REST API 呼び出しの複雑さの一部が抽象化されるため、使用が簡単です。

以下では、コマンドレットによって監査データへのアクセスがどのように簡単になるのかを説明します。

• 認証: PowerShell スクリプトで認証を行う最も簡単な方法は、Connect-PowerBIServiceAccount コマンドレットを使うことです。
• シンプルさ: 監査データを取得する手法が簡単なので、いっそう簡単に作業を始められます。 Get-PowerBIActivityEvent コマンドレットを使うときは、"1 日分" の監査データを取得することを検討してください。 一方、Get Activity Events REST API を直接呼び出すときは、"1 時間分" の監査データを取得します。 そのため、REST API を使って 1 日の監査データを取得する場合は、ループを使って API を 24 回呼び出して、1 日を 1 時間ごとに抽出する必要があります。
• 大きな結果セットのページネーション: 大きな結果セットは、"ページネーション" によって効率的に取得されます。 ページネーションでは、結果のチャンクが一度に 1 つ取得されます。 ページネーションはコマンドレットによって自動的に管理されます。 一方、REST API を直接使う場合は、スクリプトで後続トークンをチェックして、結果がそれ以上あるかどうかを判断する必要があります。 後続トークンを受け取らなくなるまで、スクリプトで結果のチャンクを取得し続ける必要があります。 後続トークンの使用例については、アクティビティ イベント REST API に関する記事をご覧ください。
• アクセス トークンの有効期限: 認証時に、アクセス トークンが返されます。 既定では、有効期限は 1 時間後です。 アクセス トークンの有効期限は、コマンドレットによって自動的に処理されます。 そのため、ユーザーが更新トークンを要求するロジックを記述する必要はありません。
• 書式設定: コマンドレットによって返されるデータは、REST API によって返されるデータより少し適切に書式設定されています。 出力が、ユーザーにとって使いやすくなります。 自動監査プロセスの場合、これは問題ではないかもしれません。 しかし、手動監査プロセスの場合は、より良い書式設定が役に立つ場合があります。

REST API を直接使用する場合の考慮事項

Power BI REST API を直接呼び出すと利点がある場合があります。

• より多くの API を使用できる: PowerShell コマンドレットより多くの REST API を使用できます。 ただし、任意の Power BI REST API を呼び出すことができる Invoke-PowerBIRestMethod コマンドレットの柔軟性を見落とさないでください。
• 更新の頻度: Microsoft は、PowerShell モジュールの更新より頻繁に REST API を更新します。 たとえば、Get Dataset API の応答に新しい属性が追加された場合、Get-PowerBIDataset コマンドレットの結果で使用できるようになるまでに時間がかかることがあります。
• 言語やツールへの依存が少ない: REST API を (コマンドレットではなく) 直接使用する場合、PowerShell を使う必要はありません。 または、スクリプトでの多くの API の呼び出しを調整するためにだけ PowerShell を使うこともできます。 PowerShell への依存を排除 (または回避) することで、将来的に、ロジックを別の言語で書き換えることができます。 IT チームまたは開発者チームがツールと言語に関して強い好みを持っている場合、依存関係の少なさは重要な考慮点になる可能性があります。

どの方法を選んだ場合でも、REST API は時間が経てば変更される可能性があります。 技術が進化すると、API (および PowerShell モジュール) は非推奨になって置き換えられる場合があります。 したがって、保守が簡単で、変更に対する回復性があるスクリプトを意図して作成することをお勧めします。

チェックリスト - REST API に直接アクセスするか、PowerShell コマンドレットを使うかを選ぶときの主な決定事項とアクションは次のとおりです。

• PowerShell の使用について IT 部署に相談する: 関連する IT チームに問い合わせて、PowerShell の使用方法に関して既存の内部要件または優先事項があるかどうかを判断します。
• PowerShell の使い方を決める: 使用する PowerShell の手法と、PowerShell への依存を意図的に増やすか減らすかを決めます。 内部的な通知またはトレーニングが必要かどうかを検討します。
• PowerShell Core にアップグレードする: PowerShell Core の使用について調べます。 管理者のマシンを更新する必要があるかどうかを判断します。 テストする必要がある既存のスクリプトを検討します。 管理者または開発者のスキルをアップグレードするための追加トレーニングが必要かどうかを判断します。
• 使用する PowerShell モジュールを決める: Power BI Management モジュールと Data Gateway モジュールを使うかどうかを検討します。
• コミュニティ プロジェクトを許可するかどうかを決める: (Microsoft によって公開されたモジュールではなく) オンラインで利用できる PowerShell モジュールの使用が許可されるか (むしろ推奨されるか) どうかを判断します。 IT 部署に問い合わせて、オンラインで取得されるコミュニティ プロジェクトに関する基準があるかどうかを判断します。
• コミュニティ プロジェクトのサポート方法を明確にする: PowerShell コミュニティ プロジェクトが許可される場合、内部で使われるようになった後で、誰がサポートの責任を負うのかを検討します。
• 小さな概念実証 (POC) を行う: 技術的な POC で実験します。 望ましいクライアント ツールとデータへのアクセス方法を確認します。
• 高度なユーザーをサポートする方法を決める: ユーザー API を使って自動化を独自に作成する技術ユーザーをサポートする方法を検討します。

監査データを格納する場所を決定する

エンド ツー エンドの監査ソリューションを構築する予定の場合は、生データ (および次のセクションで説明するキュレーションされたデータ) を格納する場所を決める必要があります。 データ ストレージに関する決定は、"データ統合" の望ましい処理方法に関連しています。

生の監査データを抽出する場合は、複雑にならないようにします。 最初にデータを抽出するときに、特定の属性を選んだり、変換を実行したり、書式設定を適用したりしないことをお勧めします。 代わりに、使用できるすべての属性を抽出し、データを元の状態で格納します。

生データを元の状態で格納するのがベスト プラクティスであるいくつかの理由を次に示します。

• 履歴で使用可能なすべてのデータ: 新しい属性と新しいイベントの種類は、時間が経つに従い使用できるようになります。 すべての生データを格納することは、それを抽出した時点で使用できたすべてのデータに常にアクセスできるようにするのに適した方法です。 新しいデータ属性が使用できることに気付くのに長い時間がかかる場合でも (数週間または数か月を要することもあります)、生データでキャプチャしてあるので、履歴でそれらを分析できます。
• 変更に対する回復性: 生データの形式が変更された場合、データを抽出するプロセスは影響を受けません。 一部の監査データは時間の影響を受けやすいため、ソースが変更されても失敗しないデータ抽出プロセスを設計することが重要です。
• 役割と責任: さまざまなチーム メンバー (データ エンジニアやFabric 管理者など) が、生の監査データのアクセス、抽出、格納を行うプロセスの作成を担当する場合があります。 データ抽出プロセスを簡単にすると、複数のチームが連携しやすくなります。

生データを格納するためのいくつかのオプションを次に示します。

• Data Lake またはオブジェクト ストレージ: 任意の構造のファイル保存専用の、OneLake などのクラウド サービス。 これは、生の監査データの格納に理想的な選択肢です。 データ レイク アーキテクチャでは、生データはブロンズレイヤーに格納される必要があります。
• ファイル システム: ファイル システム (Windows や Linux など) は、生の監査データを格納するための一般的な選択肢です。
• データベース： JSON データは、Azure SQL Database などのリレーショナル データベースに格納できます。 ただし、データ レイクまたはファイル システムにデータを格納するより一般的ではありません。 これは、JSON データのクエリと保守は困難で高コストになる可能性があるためです (特にデータ量が増えた場合)。

ヒント

データ レイク、オブジェクト ストレージ、またはファイル システムを使う場合は、整理とセキュリティ保護が容易な方法でデータを格納することをお勧めします。 また、データがイベントで構成されるかどうか (通常は追加されます)、または特定の時点のスナップショットかどうか (分析するには日付を選ぶ必要があります) についても明確にすることが重要です。

データ レイクの生データ ゾーンを含む例について考えます。 ゾーンには、アクティビティ ログ データを格納するためのフォルダー階層があります: Raw > ActivityLog > YYYY > MM。 フォルダーは年と月でパーティション分割されています。 月フォルダーに格納されるファイルには、次の形式が使われます: PBIActivityLog-YYYYMMDD-YYYYMMDDTTTT.json。 YYYYMMDDD は実際のデータを表し、YYYYMMDDTTTT は抽出タイム スタンプを表します。 抽出タイム スタンプを含めることで、最新のファイルを特定できます (データを再度抽出する必要がある場合)。 たとえば、2023 年 4 月 23 日のアクティビティについて、2023 年 4 月 25 日午前 9 時 (UTC) にデータを抽出する場合、ファイル名は PBIActivityLog-20230523-202305250900 になります。

生データを "不変ストレージ" に書き込める技術を使うことを強くお勧めします。 不変ストレージを使うと、データが書き込まれた後で上書きまたは削除できないことが保証されます。 この区別は監査担当者にとって重要であり、生データが信頼できるものであることを信頼できます。

また、生データを安全に格納する方法も検討する必要があります。 通常、生データにアクセスする必要があるユーザーはごくわずかです。 生データへのアクセスは、通常、データ エンジニアとシステム管理者に対し、必要に応じて提供されます。 また、内部監査担当者もアクセスが必要になる場合があります。 キュレーションされたデータの作成を担当するチーム メンバーも (次に説明します)、生データにアクセスする必要があります。

生データ ストレージの選択に役立つ考慮事項をいくつか次に示します。

• 監査プロセスは手動か自動か? 自動監査プロセスでは、通常、データを格納する方法と場所に関する要件がいっそう厳格になります。
• 対象領域は特に機密性が高いか? 組織には、データの種類と機密性に応じて、格納する方法と場所に関する要件がある場合があります。 Power BI の監査データには、ユーザー情報と IP アドレスを示す情報が含まれているため、セキュリティで保護された領域に格納する必要があります。
• 優先されるストレージ技術はあるか? 組織で使われているため、論理的な選択である、既存のストレージ技術が存在する可能性があります。
• ユーザーはストレージに直接アクセスするか? セキュリティ モデルは重要な考慮事項です。 通常、生データへのアクセスを許可されるユーザーはごくわずかです。 通常、一元化されたデータ モデル (レポートのレイヤーとして機能するセマンティック モデル) の作成を担当する Power BI コンテンツ作成者は、キュレーションされたデータにアクセスできます。
• データ所在地の要件があるか? 一部の組織は、法的または規制上のデータ所在地要件のため、特定のデータ リージョンにデータを格納する必要があります。
• データはどのように整理されますか? 特に データ レイクとレイクハウスの実装では、メダリオン アーキテクチャ の使用が一般的に実践されています。 目的とするのは、データをブロンズ、シルバー、およびゴールドのデータ レイヤーに格納することです。 ブロンズ レイヤーには、元の生データが含まれます。 シルバーレイヤーには、変換に使用される検証済みおよび重複除去済みのデータが含まれます。 ゴールド レイヤーには、分析向けの準備ができている、キュレーション済みで高度に洗練されたデータが含まれます。

チェックリスト - 生データを格納する場所を計画するときの主な決定事項とアクションは次のとおりです。

• IT 部署に相談する: 関連する IT チームに問い合わせて、生の監査データを抽出するために実行されている既存のプロセスがあるかどうかを判断します。 そうである場合は、既存のデータにアクセスできるかどうかを確認します。 新しいデータ抽出プロセスが必要な場合は、データの格納場所に関する優先事項または要件があるかどうかを確認します。
• 生データを格納する場所を決める: 生データの格納に最適なストレージの場所と構造を決めます。
• データ所在地の要件を決める: データを格納できる場所に関する法的要件と規制要件があるかどうかを確認します。
• フォルダー構造と名前付け規則を作る: 生データ ファイルに使う名前付け規則 (フォルダー構造を含む) を決めます。 これらの詳細を技術ドキュメントに含めます。
• 生データのセキュリティのしくみを検討する: 生データ ストレージの場所を設計するのと併せて、データにアクセスする必要があるユーザーと、アクセスを許可する方法を検討します。

キュレーションされたデータの作成を計画する

キュレーションされたデータは分析をサポートし、ユーザー フレンドリに設計されています。 キュレーションされたデータを作成する方法と場所について、いくつかの決定を行う必要があります。 前のセクションで示した技術などから、キュレーションされたデータを格納するための技術を選びます。

キュレーションされたデータの目的は、分析とレポート用に最適化された、よりわかりやすい形式にデータを変換することです。 これは Power BI のデータ モデルのデータ ソースになるため、Power BI のデータ モデルを使って、組織での Power BI の使用方法を分析します。 データ モデルの基本的なガイダンスが適用されます。パフォーマンスと使いやすに最適化された、スター スキーマ設計を採用する必要があります。

キュレーションされたデータの作成には、さまざまな方法を選択できます。 "データ統合" を行う方法と、スター スキーマへの読み込み用にデータを準備する変換を "上流" のどこまで遡って適用するかを、決める必要があります。

データ レイク

変換を適用し、データ レイクにキュレーションされたデータ ファイルを作成できます。 キュレーション済みデータとしてはゴールド レイヤーを使用する必要があります。これは、ブロンズレイヤーに格納されている生データからは論理的に分離されています。 データをレイヤーごとに分離することで、異なるユーザーのアクセス許可の設定も簡単になります。

次の場合、データ レイクを使ってデータの変換とキュレーションを行います。

• ユーザーにとっては、レポートを提供する Power BI データ モデルが複数存在することが想定されます (これは、中間的なシルバー レイヤーの作成を正当化します)。
• テナント レベルの監査データにアクセスする必要がある複数のセルフサービス コンテンツ作成者をサポートする必要がある。
• データの変換と読み込みに使いたい既存のツールとプロセスがある。
• 1 つ以上の Power BI データ モデル内で行う必要がある (そして、重複する可能性がある) データの準備を最小限に抑えたい。

Power BI のデータ モデル

Power BI ですべての変換作業を完了できる場合があります。 Power Query を使って、データにアクセスし、生の状態からキュレーションされた形式に変換します。

次の場合、Power BI データ モデルを使います。

• エンド ツー エンドのアーキテクチャを簡略化し、生データから直接データ モデルを読み込みたい。 (増分更新は、更新期間を短縮するのに役立ちます)。
• データ モデルの読み込み中にすべての変換作業を行うのが望ましい。
• テナント レベルの監査データに、1 つの一元化されたデータ モデルを使いたい。 すべてのレポート (または他のデータ モデル) で、一元化された Power BI セマンティック モデルをソースとして使用できる。
• 一元化された Power BI セマンティック モデルだけにユーザーがアクセスできるようにしたい (ソース データにはアクセスできない)。

ヒント

キュレーションされたデータを作成するときは、以前の日付範囲に関する処理を簡単に再実行できるように設定します。 たとえば、3 か月前に監査ログに新しい属性が出現したことがわかった場合は、最初の出現以降を分析できる必要があります。 キュレーションされたデータ履歴の再読み込みを行えることは、生データを元の状態で格納することが重要であるいくつかの理由の 1 つです (この記事で前に説明しました)。

スター スキーマに含めるディメンション テーブルとファクト テーブルについて詳しくは、後の「データ モデルを作成する」をご覧ください。

チェックリスト - キュレーションされたデータの作成方法を計画するときの主な決定事項とアクションは次のとおりです。

• 変換を行う必要がある場所を決める: 変換作業をどの程度上流まで遡って行う必要があるか、およびそれがアーキテクチャ全体の計画に適合する場所を検討します。
• スター スキーマへのデータの変換に使うツールの決定: 生データをキュレーション済みデータに変換する際に使用される、ツールとサービスを確認します。
• キュレーションされたデータを格納する場所を決める: スター スキーマ形式に変換された生データの格納に関する最適な選択を判断します。 エンド ツー エンド アーキテクチャで中間のシルバー レイヤーが役立つかどうかを決定します。
• 名前付け規則を作成する: キュレーションされたデータのファイルとフォルダーに使う名前付け規則を決めます (該当する場合)。 詳細を技術ドキュメントに含めます。
• キュレーションされたデータに関するセキュリティのしくみを検討する: キュレーションされたデータ ストレージの場所の設計と併せて、データにアクセスする必要があるユーザーと、セキュリティを割り当てる方法を検討します。

データ ソースの決定

この時点では、要件、データのニーズ、アクセス許可が明確になっているはずです。 技術に関する重要な決定が行われています。 次に、特定の種類のデータを取得する方法に関するアプローチについて、いくつかのことを決定する必要があります。

ユーザー アクティビティ データにアクセスする

Power BI のユーザー アクティビティ データ ("アクティビティ ログ" または "監査ログ" と呼ばれることもあります) には、Power BI テナントで起きていることを理解するのに役立つ情報が豊富に含まれています。 データのニーズを明らかにする方法について詳しくは、前の「ユーザー アクティビティ データ」をご覧ください。

Power BI は、そのログを Microsoft Purview 統合監査ログ (以前の Microsoft 365 統合監査ログ) と統合します。 この統合がメリットであるのは、Microsoft 365 内のすべてのサービスが独自のログ方法を実装する必要がないためです。 既定で有効です。

重要

ユーザー アクティビティ データの抽出をまだ行っていない場合は、それを最優先にしてください。 (ソースに応じて) 最新の 30 日または 90 日間のユーザー アクティビティ データを使用できます。 詳細な分析を行う準備ができていない場合でも、できるだけ早くデータの抽出と格納を始めることが重要です。 そうすることで、貴重な履歴を分析に使用できるようになります。

ユーザー アクティビティ データを取得するには、いくつかのオプションがあります。

手法	説明	使用可能な履歴の既定の日数	手動監査プロセスに適した選択	自動監査プロセスに適した選択	アラートの設定に適した選択	すぐ始めるのに適した選択
手動 (ユーザー インターフェイス)	Microsoft Purview コンプライアンス ポータル	90
手動 (ユーザー インターフェイス)	Defender for Cloud Apps	30
プログラムによる	Power BI アクティビティ ログ (API または PowerShell コマンドレット)	30
プログラムによる	Office 365 マネージメント アクティビティ API	7
プログラムによる	Microsoft Sentinel (Azure Monitor)	30

このセクションの残りの部分では、表で示した各手法について説明します。

Microsoft Purview コンプライアンス ポータル

Microsoft Purview コンプライアンス ポータル (以前の Microsoft 365 コンプライアンス センター) の監査検索ツールは、アクティビティとアラートを見るのに便利な場所です。 このツールを使うと、データを抽出してダウンロードするためにスクリプトを作成する必要がありません。 Power BI ワークロードを選んで、一定期間のすべての監査ログ レコードを表示できます。 特定のアクティビティとユーザーを選ぶことで、結果を絞り込むこともできます。 たとえば、マネージャーから、状況について話し合うためにユーザーにすばやく連絡できるよう、その日の早い段階でワークスペースを削除したユーザーを確認するよう求められたような場合です。

監査 (Standard) では、最近 90 日間の履歴を入手できます。 監査 (Premium) では、長期保有を使って、(必要に応じて) さらに長く監査ログを保持できます。 長期保有はライセンスされた E5 ユーザーにのみ適用されるため、E5 以外のユーザーとゲスト ユーザーの監査レコードは除外されます。 そのため、すべてのアクティビティが確実にキャプチャされるようにするには、既定の 90 日間の履歴のみに依存することをお勧めします。

Microsoft Purview コンプライアンス ポータルで監査ログにアクセスするには、ライセンスの要件があります。 監査ログにアクセスするには、昇格された Exchange Online のアクセス許可も必要です。

ヒント

既定では、Power BI 管理者には、Microsoft Purview コンプライアンス ポータルで統合監査ログ検索にアクセスするためのアクセス許可はありません。 それには多くの Microsoft 365 サービスのデータが含まれているため、高い特権を持つロールです。 ほとんどの組織では、これらのアクセス許可は少数の IT 管理者向けに予約されています。 Power BI 管理者が使用できる他のオプションがあり、それについてはこのセクションで後ほど説明します。

Microsoft Purview コンプライアンス ポータルのユーザー インターフェイスは、ユーザー アクティビティの手動監査プロセスや低頻度の調査に役立ちます。

Defender for Cloud Apps

Defender for Cloud Apps のポータルは、データを抽出してダウンロードするスクリプトを作成する必要なしに、アクティビティとアラートを表示できる便利な場所です。 また、Power BI のアクティビティ ログとユーザー サインインのデータを見ることもできます。

Defender for Cloud Apps には、Power BI などのさまざまなクラウド サービスのアクティビティ ログの表示と検索を行うためのユーザー インターフェイスが含まれています。 そこには、Microsoft Purview 統合監査ログで発生する同じログ イベントが表示され、それに Microsoft Entra ID のユーザー サインイン アクティビティなどの他のイベントが含まれています。

Microsoft Purview コンプライアンス ポータル (前のセクションで説明) と同様に、Defender for Cloud Apps には検索可能なユーザー インターフェイスがあります。 ただし、フィルターのオプションは異なります。 標準の 30 日間の履歴に加えて、Defender for Cloud Apps を使うと、最大 6 か月間のアクティビティ ログ履歴 (7 日間単位) を見ることができます。

Defender for Cloud Apps にアクセスするには、ライセンスの要件があります。 個別のアクセス許可も必要です。

ヒント

既定では、Power BI 管理者には Defender for Cloud Apps にアクセスするためのアクセス許可はありません。 Defender for Cloud Apps には Power BI ロールがあります。 このロールに Power BI 管理者を追加することは、制限されたデータ セットへのアクセスを許可する良い方法です。

Defender for Cloud Apps のユーザー インターフェイスは、ユーザー アクティビティの手動監査プロセスと 1 回限りの調査に便利です。

Power BI アクティビティ ログ

Power BI アクティビティ ログは、統合監査ログから生成されます。 それには、Power BI サービスに関連するユーザー アクティビティのみが含まれます。

ヒント

ユーザー アクティビティの抽出を計画している組織では、Power BI アクティビティ ログから始めることをお勧めします。 プログラムで最も簡単にアクセスできるソースです。

Power BI アクティビティ ログにアクセスするには、2 つのオプションがあります。

• 任意のツールを使って、Get Activity Events REST API を呼び出します。
• Get-PowerBIActivityEvent PowerShell コマンドレットを使います。 これは、Power BI Management Admin モジュールから使用できます。

どのオプションを使うかについては、前の「API または PowerShell コマンドレットを選択する」をご覧ください。

ヒント

PowerShell を使って Power BI のアクティビティ ログにアクセスする方法の例については、「Power BI アクティビティ ログへのアクセス」をご覧ください。

Power BI アクティビティ ログのデータは、すべての Fabric 管理者およびPower Platform 管理者が利用できます。 データには統合監査ログからアクセスでき、特定の Exchange Online ロールで使用できます。 詳細については、「Power BI でユーザー アクティビティを追跡する」を参照してください。

Power BI の監査ログ レコードを取得することだけが目的の場合は、Power BI アクティビティ ログを使うことをお勧めします。

注意

監査ログ データでは、ワークスペースは "フォルダー" と呼ばれています。 Power BI REST API では、ワークスペースは "グループ" と呼ばれます。

Office 365 マネージメント アクティビティ API

SharePoint Online、Teams、Exchange Online、Dynamics 365、Power BI など、他のサービスのデータを統合監査ログから抽出できます。 複数のサービスの監査と監視ソリューションを実装することが目的の場合は、Office 365 マネージメント アクティビティ API を使うことをお勧めします。 この API は多くのサービスからデータを返すので、"統合監査 API" (または "統合監査ログ") と呼ばれます。 これは、Office 365管理 API の 1 つです。

新しいソリューションを構築する前に、社内の IT 部署に連絡して、既存の Power BI 監査レコードを使えるかどうか判断することをお勧めします。 プロセスによって既にデータの抽出と格納が行われている可能性があります。 また、新しいソリューションを構築するのではなく、このデータにアクセスするためのアクセス許可を取得できる可能性もあります。

データには、2 つの方法のいずれかでアクセスできます。

• 任意のツールを使って、Office 365 マネージメント アクティビティ API を直接呼び出します。 既定では、API から 24 時間分のデータが返されます。 最大で 7 日間の履歴を取得できます。
• Search-UnifiedAuditLog PowerShell コマンドレットを使います。 これは、Exchange Online PowerShell コマンドレットです。 最大で 90 日間の履歴を取得できます。

重要

Search-UnifiedAuditLog コマンドレットは適切にスケーリングされず、ループ戦略を実装して 5,000 行の制限に対処する必要があります。 このような理由から、低頻度のクエリや、アクティビティが少ない小規模な組織に適しています。 Power BI データのみが必要な場合は、代わりに Get-PowerBIActivityEvent コマンドレットを使うことをお勧めします。

一般に、Office 365 マネージメント アクティビティ API を使って作業を始める方が、Power BI アクティビティ ログ (前述) を使うより困難です。 これは、API からはコンテンツ BLOB が返され、各コンテンツ BLOB に個々の監査レコードが含まれているためです。 大規模な組織の場合、1 日あたり何千ものコンテンツ BLOB になる可能性があります。 お客様とサード パーティのアプリケーションはこの API を頻繁に使うため、サービスを使っても他に悪影響がないよう、Microsoft は調整を実装しています ("ノイズの多い近隣" の問題と呼ばれます)。 そのため、大規模な組織では、大量の履歴を取得することが課題になる可能性があります。 詳しくは、こちらのトラブルシューティングに関する記事をご覧ください。

この API を使うには、Office 365 マネージメント アクティビティ API からデータを取得するためのアクセス許可が付与されているサービス プリンシパルを使って認証を行う必要があります。

ヒント

既定では、Power BI 管理者には、Office 365 マネージメント アクティビティ API にアクセスするためのアクセス許可はありません。 多くの Microsoft 365 サービスのデータが含まれているため、アクセスするには、高い特権の管理者または監査ロールが必要です。 ほとんどの組織では、これらのロールは少数の IT 管理者向けに予約されています。 Power BI アクティビティ ログは、Power BI 管理者が使うためのものです。

Office 365 マネージメント アクティビティ API から監査データをプログラムで取得することは、IT 部署が (Power BI 以外の) さまざまなサービスから監査ログを抽出して格納する必要がある場合に適しています。

Microsoft Sentinel

Microsoft Sentinel は、セキュリティ インシデントや脅威を収集、検出、調査、対応できる Azure サービスです。 Microsoft Sentinel で Power BI を "データ コネクタ" として設定できます。 接続すると、(データのサブセットを含む) 監査ログが Power BI から Azure Monitor の機能である Azure Log Analytics にストリーミングされます。

ヒント

Azure Log Analytics は、ワークスペース レベルのセマンティック モデル イベント ログで使われるのと同じアーキテクチャに基づいています。 セマンティック モデルのイベント ログについて詳しくは、データ レベルの監査に関する記事をご覧ください。

これは別の Azure サービスであるため、Kusto 照会言語 (KQL) クエリを実行する管理者またはユーザーには、Azure Log Analytics (Azure Monitor) でのアクセス許可を付与する必要があります。 アクセス許可があるユーザーは、PowerBIActivity テーブルに格納されている監査データのクエリを実行できます。 ただし、ユーザーにアクセス許可を付与するのは、ほとんどの場合、ブロンズ レイヤーの生データに対してではなく、ゴールド レイヤーにあるキュレーション済みデータに対してであるということを念頭に置いてください。

KQL を使って、Azure Log Analytics に格納されているアクティビティ ログ イベントを分析します。 SQL の経験がある場合は、KQL が多くの点で似ていることがわかります。

Azure Log Analytics に格納されているイベントにアクセスするには、いくつかの方法があります。 使用できるもの:

• 事前構築済みの Log Analytics for Power BI Semantic Models テンプレート アプリ。
• Azure Data Explorer (Kusto) 用の Power BI Desktop コネクタ。
• Azure Data Explorer の Web ベースのクエリ エクスペリエンス。
• KQL クエリを送信できる任意のクエリ ツール。

注意事項

Azure Monitor に格納されるのは Power BI アクティビティ ログ データのサブセットのみであることに注意してください。 組織での Power BI の使用状況と導入に関する包括的な分析を行う場合は、他のオプション (このセクションで前に説明しました) を使ってアクティビティ データを取得することをお勧めします。

取得できる履歴の期間は、Azure Log Analytics ワークスペースのデータ保持ポリシーによって異なります。 保持するデータの量を決めるときは、コストと生データへのアクセスを検討してください。

IT 部署が既に Microsoft Sentinel に投資していて、キャプチャされる詳細レベルがニーズを満たしており、脅威検出などのアクティビティが優先されるときは、Microsoft Sentinel と Azure Monitor が適切なオプションです。 ただし、Microsoft Sentinel ではすべての Power BI アクティビティ データはキャプチャされないため、Power BI の使用状況と導入に関する包括的な分析の実行には対応していません。

ユーザー アクティビティ データに関する考慮事項

ユーザー アクティビティ データのソースを選ぶときに役立つ考慮事項をいくつか次に示します。

• 監査プロセスは手動か自動か? ユーザー インターフェイスのオプションは、手動監査プロセスや、低頻度で 1 回限りのクエリ (特に、特定のアクティビティを調査する必要があるとき) に適しています。 履歴データの分析をサポートするには、スケジュールに従ってユーザー アクティビティ データを抽出する自動監査プロセスも必要です。
• ユーザー アクティビティ データはどのくらいの頻度で必要か? 自動監査プロセスの場合は、現地時刻ではなく協定世界時 (UTC) を使って、現在の日付より少なくとも 1 日前のデータを抽出することを計画します。 たとえば、プロセスが金曜日の朝 (UTC 時刻) に実行される場合は、水曜日以降のデータを抽出する必要があります。 データを抽出するのに 1 日待つ必要があることには、いくつかの理由があります。
  • 常に一度に 24 時間分を完全に抽出した方が、ファイルの処理が簡単になり、結果が半端な日になるのを避けることができます。
  • 一部の監査イベントが欠落するリスクが最小限に抑えられます。 通常、監査イベントは 30 分以内に到着します。 統合監査ログでは、一部のイベントが到着するまでに最大 24 時間かかる場合があります。
• Power BI 以外のデータが必要か? 必要なものにアクセスするための最も効率的な方法を検討します。
  • Power BI のユーザー アクティビティ データのみが必要な場合は、Power BI アクティビティ ログを使います。
  • 複数のサービスからの監査ログが必要な場合は、Office 365 マネージメント アクティビティ API を使って統合監査ログにアクセスします。
• 誰がソリューションを開発するか? ソリューションの構築にある程度の時間をかけるように計画します。 運用対応のスクリプトを作成するには、かなりの作業が必要な場合があります。

チェックリスト - ユーザー アクティビティ データにアクセスする方法を計画するときの主な決定事項とアクションは次のとおりです。

• ニーズの範囲を明確にする: アクセスする必要があるのが Power BI の監査レコードのみか、それとも複数のサービスの監査データかを判断します。
• IT 部署と相談する: 現在 IT 部署で監査ログが抽出されているかどうか、および新しいソリューションを構築する必要がないように生データへのアクセスを取得できるかどうかを確認します。
• データ ソースを決める: ユーザー アクティビティ データへのアクセスに使用する最適なソースを決めます。
• 概念実証を行う: 小規模な技術的概念実証 (POC) の実施を計画します。 それを使って、最終的なソリューションの構築方法に関する決定を検証します。
• 追加のデータ ニーズを追跡する: アクティビティ ログ データを他のソースと関連付けて、データの価値を高めることができます。 これらの機会の発生を追跡し、プロジェクトのスコープに追加できるようにします。

テナント インベントリ データにアクセスする

テナント インベントリは、成熟した監査および監視ソリューションの非常に貴重で必要な部分です。 それは、Power BI に存在するワークスペースとコンテンツ (セマンティック モデル、レポート、その他のアイテム) を理解するのに役立ち、ユーザー アクティビティ データ (前のセクションで説明しました) の優れた補完になります。 データのニーズを明らかにする方法について詳しくは、前の「テナント インベントリ」をご覧ください。

ユーザー アクティビティ (前に説明しました) は、監査対象のイベントであり、ユーザーが特定の日時に実行したアクションの記録です。 テナント インベントリはそれとは異なります。 テナント インベントリは、特定の時点での "スナップショット" です。 Power BI サービスで発行されているすべてのアイテムの、抽出時点での状態が記述されています。

注意

Power BI REST API のドキュメントでは、発行されているアイテムを "成果物" と呼びます。

ヒント

多くの組織で、テナント インベントリを毎週同じ時刻に抽出すると役に立つことがわかっています。

Power BI テナントで起きていることを適切に分析するには、ユーザー アクティビティ データとテナント インベントリの両方が必要です。 それらを組み合わせることで、コンテンツの量と場所を把握できます。 また、使われていないコンテンツや使用量の少ないコンテンツを見つけることもできます (アクティビティ ログにそれに対するイベントがないため)。 テナント インベントリを使って、すべてのアイテムの現在の名前の一覧を作成することもでき、アイテム名が変更されるときに役立ちます。

テナント インベントリの有用性について詳しくは、この記事の中で前述した「テナント インベントリ」を参照してください。

ヒント

Get Unused Artifacts as Admin API を使って、過去 30 日間にユーザー アクティビティがないアイテムを検索できます。 ただし、その期間をカスタマイズすることはできません。 たとえば、四半期ごとにのみ使われる重要なコンテンツがあるとします。 テナント インベントリとユーザー アクティビティ データを組み合わせることで、カスタマイズできる方法で使われていないアイテムを見つけることができます。

テナント インベントリ データは、2 つの異なる方法で取得できます。

手法	説明	最適なもの	手動監査プロセスに適した選択	自動監査プロセスに適した選択
プログラムによる	Get Groups as Admin API または Get-PowerBIWorkspace PowerShell コマンドレットは、テナント全体のワークスペースの一覧を提供できます。 必要に応じて、ワークスペースごとに個々のアイテム (セマンティック モデルやレポートなど) を含めることができます。	小規模の組織、またはデータ量が少ない場合
プログラムによる	一連の非同期管理 API (総称して "メタデータ スキャン API" または "スキャナー API" と呼ばれます) は、ワークスペースの一覧と個々のアイテムを返すことができます。 必要に応じて、詳細なメタデータ (テーブル、列、メジャー式など) も含めることができます。	データ量が多い組織や、詳細な結果を取得する必要がある場合

このセクションの残りの部分では、表で示した各手法について説明します。

Groups API またはワークスペース コマンドレット

ワークスペースの一覧を取得するには、Get Groups as Admin API (任意のツールを使用).など、いくつかの REST API のいずれかを使用できます。 結果には、説明などの追加のメタデータや、ワークスペースが Premium 容量に格納されているかどうかが含まれます。

注意

API の名前には、ワークスペースへの参照として group という用語が含まれています。 この用語は、Microsoft 365 グループに依存していた元の Power BI セキュリティ モデルに由来します。 Power BI セキュリティ モデルは長年にわたって大幅に進化してきましたが、既存の API 名は、既存のソリューションを壊さないように変更されないまま残っています。

Get Groups as Admin REST API には、役に立つ $expand パラメーターが含まれています。 このパラメーターを使うと、必要に応じて結果を拡張し、ワークスペースに発行されたアイテム (セマンティック モデルやレポートなど) の一覧を含めることができます。 users データ型を $expand パラメーターに渡して、ワークスペース ロールに割り当てられているユーザーを含めることもできます。

Get-PowerBIWorkspace PowerShell コマンドレットを使うこともできます。 これは、Power BI Management Workspaces モジュールのものです。 -Scope パラメーターを organization に設定すると、Get Groups as Admin API と同じように機能します。 このコマンドレットは、ワークスペースに発行されたアイテム (セマンティック モデルやレポートなど) を含めるための、-Include パラメーター (REST API の $expand パラメーターと同等) も受け取ります。

ヒント

パラメーターを渡すことで、コマンドレットをさまざまな方法で使用できます。 このセクションでは、テナント全体のインベントリの取得に焦点を当てます。 -Scope パラメーターの使用について詳しくは、前の「ユーザー API または管理 API を選択する」をご覧ください。

使用するオプションの選択については、前の「API または PowerShell コマンドレットを選択する」をご覧ください。

Get Groups as Admin REST API または Get-PowerBIWorkspace PowerShell コマンドレットは、手動監査プロセスと 1 回限りの調査に最適です。 データ量が多い大規模な組織では、通常、これらのオプションを使うのは難しいことがわかります。 REST API とコマンドレットは、常に完全なデータ セットを抽出するため、実行に時間がかかることがあります。 そのため、大規模な組織では、1 時間あたりの許容要求数で制限される可能性もあります ("調整" と呼ばれ、サービスの正常性を保護するために行われます)。 メタデータ スキャン API (次に説明します) では、より信頼性が高くスケーラブルな代替手段が提供されます。

メタデータ スキャン API

メタデータ スキャン API (一般に "スキャナー API" と呼ばれます) は、ワークスペースとその Power BI アイテム (セマンティック モデル、レポート、その他のアイテム) の一覧を返す一連の API です。 概念的には、前のセクションで説明した Groups API またはワークスペース コマンドレットと同じデータ (およびそれ以上) を提供します。 ただし、データの取得に使う方法は異なり、テナント インベントリの抽出にいっそう適しています。

注意

一部のユーザーによる "スキャナー API" という用語または "テナントのスキャン" 語句の使い方に注意してください。 多くの場合、それらの用語は、ユーザー アクティビティ イベントと区別して、"テナント インベントリの作成" を意味するために使われます。 メタデータ スキャン API の使用を文字どおり示している場合とそうでない場合があります。

Get Groups as Admin REST API または Get-PowerBIWorkspace コマンドレット (前に説明しました) ではなく、メタデータ スキャン API の使用を検討する必要がある理由は、主に 2 つあります。

• 増分データの抽出: スキャナー API は、前回実行されてから変更されたデータのみを抽出します。 逆に、Get Groups as Admin REST API と Get-PowerBIWorkspace コマンドレットは、実行するたびに完全なデータ セットを抽出する同期操作です。
• より細かい詳細レベル: 詳細なメタデータのための 2 つのテナント設定によってアクセス許可が付与されている場合、スキャナー API はより小さい単位の詳細情報 (テーブル、列、メジャー式など) を取得できます。 それとは逆に、Get Groups as Admin REST API と Get-PowerBIWorkspace コマンドレットで使用できる最も低い詳細レベルは、アイテムの種類 (ワークスペース内のレポートの一覧など) です。

スキャナー API を使うときは、一連の API を呼び出す必要があるため、作業量が増えます。 また、それは "非同期" プロセスとして実行されます。 非同期プロセスはバックグラウンドで実行されるため、完了するまで待つ必要はありません。 スケジュールされる運用対応のスクリプトを作成するときは、IT 部署または開発者と共同で作業することが必要な場合があります。

スキャナー API を使うときにプロセスが従う必要のある一連の手順を次に示します。

1. サインインする: Power BI 管理者のアカウントまたは管理 API を実行するためのアクセス許可を持つサービス プリンシパルを使って、Power BI サービスにサインインします。 詳しくは、前の「認証方法を決定する」をご覧ください。
2. ワークスペース ID を取得する:ワークスペース ID の一覧を取得する要求を送信します。 初めて実行するときは、変更日がないため、ワークスペースの完全な一覧が返されます。 通常は、変更日を渡して、その時点以降に変更されたワークスペースのみを取得します。 変更日は過去 30 日以内にする必要があります。
3. メタデータ スキャンを開始する: ステップ 2 で取得したワークスペース ID を渡して、ワークスペース情報のスキャンを要求する呼び出しを開始します。 これは POST API であることに注意してください (監査データの取得時に一般的な GET API ではありません)。 POST API は、指定したリソースのデータを作成するか書き込む HTTP 要求です。 このクエリでは、抽出する詳細レベル (データ ソースの詳細、セマンティック モデル スキーマ、セマンティック モデル式、ユーザーなど) を指定します。 送信すると、スキャンの ID が API によって返されます。 また、スキャンの日付と時刻も返されます。これを、スナップショットの日付として記録する必要があります。
4. スキャンの状態を調べる: ステップ 3 で取得したスキャン ID を使って、スキャンの状態を取得します。 この API を複数回呼び出すことが必要な場合があります。 返された状態が "成功" の場合、次のステップに進むことができます。 スキャンにかかる時間は、要求するデータの量によって異なります。
5. 結果を取得する: ステップ 3 で取得したスキャン ID を使って、スキャン結果 を取得し、データを抽出します。 このステップは、ステップ 4 を完了してから 24 時間以内に行う必要があります。 スナップショットのタイム スタンプは、ステップ 5 ではなくステップ 3 と関連付ける必要があることに注意してください (大幅な遅れがある場合)。 そうすることで、正確なスナップショットのタイム スタンプを得られます。 結果を適当なデータ ストレージの場所に保存します。 この記事で既に説明したように、生データを元の状態で格納することをお勧めします。
6. 次のプロセスを準備する: 次にプロセスを実行するときにステップ 2 で使用できるように、ステップ 3 で得られたスキャンのタイム スタンプを記録します。 そうすることで、その時点以降に変更されたデータのみを抽出します。 これ以降のすべてのデータ抽出は、完全なスナップショットではなく増分変更になります。

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

• 要件を確認する: テナント インベントリの作成に関するニーズと、データの分析要件を明確にします。
• テナント インベントリを抽出する頻度を決める: 新しいテナント インベントリが必要な頻度を確認します (毎週など)。
• テナント インベントリを抽出する方法を決める: テナント インベントリ データの取得に使う方法を確認します (API、コマンドレット、またはメタデータ スキャン API)。
• 概念実証を行う: 小規模な技術的概念実証 (POC) の実施を計画します。 それを使って、最終的なソリューションの構築方法に関する決定を検証します。

ユーザーとグループのデータにアクセスする

ユーザー アクティビティ データに含まれる識別情報 (メール アドレスなど) に加えて、場所や組織の詳細などの追加情報を取得すると役に立ちます。 ユーザー、グループ、サービス プリンシパル、ライセンスに関するデータを取得するには、Microsoft Graph を使用できます。 Microsoft Graph は、さまざまなサービスから監査データを取得できる API とクライアント ライブラリのセットで構成されています。

アクセスできる Microsoft Entra オブジェクトの詳細を次に示します。

• ユーザー: 職場、学校、または Microsoft アカウントとして Microsoft Entra ID 内に存在する ID。 組織のユーザーを示すために "ドメイン ユーザー" という用語がよく使われますが、正式には "ユーザー プリンシパル名" (UPN) です。 UPN は、通常、ユーザーのメール アドレスと同じ値です (ただし、メール アドレスが変更されても、UPN は不変であるため変更されません)。 また、ユーザーごとに一意の Microsoft Graph ID もあります。 多くの場合、ユーザー アカウントは 1 人のユーザーに関連付けられます。 組織によっては、自動化されたアクティビティや管理タスクに使われる "サービス アカウント" であるユーザーを作成する場合があります。
• サービス プリンシパル:アプリの登録を作成するとプロビジョニングされる別の種類の ID。 サービス プリンシパルは、無人の自動アクティビティのためのものです。 詳しくは、前の「認証方法を決定する」をご覧ください。
• グループ: ユーザーとサービス プリンシパルのコレクション。 アクセス許可の管理を簡単にするために使用できる複数のグループの種類があります。 詳細については、「グループの使用に関する戦略」を参照してください。

注意

この記事で "ユーザーとグループ" と書かれている場合は、サービス プリンシパルも含まれます。 この短い用語は簡潔にするために使われます。

取得するユーザーとグループのデータは、特定の時点での現在の状態を記述する "スナップショット" です。

ヒント

ユーザー、サービス プリンシパル、グループについて詳しくは、「Microsoft Entra ID との統合」を参照してください。

分析の属性

Power BI のテナント レベルの監査では、Microsoft Graph から次の属性を抽出して格納する場合があります。

• ユーザーのフル ネーム: 多くのデータ ソースには、アクティビティを実行したユーザーまたはロールに割り当てられているユーザーのメール アドレスのみが含まれます。 分析レポートでフル ネーム (表示名) を表示したい場合は、この属性を使います。 フル ネームを使うと、レポートがいっそう使いやすくなります。
• その他のユーザー プロパティ: ユーザーに関するその他の説明属性を、Microsoft Entra ID で使用できる場合があります。 分析に関係する値を持つ組み込みのユーザー プロファイル属性の例としては、役職、部署、マネージャー、地域、オフィスの場所などがあります。
• セキュリティ グループのメンバー: ほとんどのデータ ソースでは、グループの名前が提供されます (たとえば、セキュリティ グループがワークスペース ロールに割り当てられた Power BI アクティビティ ログ レコードなど)。 グループ メンバーシップを取得すると、個々のユーザーが行っていること、またはアクセス権を持っているものを完全に分析する機能が向上します。
• ユーザー ライセンス: ユーザーに割り当てられているユーザー ライセンス (Free、Power BI Pro、または Power BI Premium Per User (PPU)) を分析するのに便利です。 このデータは、ライセンスを使っていないユーザーを特定するのに役立ちます。 また、すべてのユーザー (ライセンスを持つ個別のユーザー) とアクティブなユーザー (最近のアクティビティがあるユーザー) を分析するのにも役立ちます。 Power BI Premium ライセンスの追加または拡張を検討している場合は、ユーザー ライセンス データと共にユーザー アクティビティ データを分析して、コスト分析を実行することをお勧めします。
• 管理者ロールのメンバー: Power BI 管理者 (Power Platform 管理者など) の一覧を作成できます。

Microsoft Graph の監査データで見つけることができる Power BI のライセンス情報の信頼できる参照情報については、「ライセンスのための製品名とサービス プラン 識別子」をご覧ください。

ヒント

グループからメンバーを取得することは、監査データの取得で最も困難な側面の 1 つです。 入れ子になったすべてのメンバーと入れ子になったグループをフラット化するには、"推移的な検索" を実行する必要があります。 グループ メンバーに対して推移的な検索を行うことができます。 この種類の検索は、組織に何千ものグループがある場合は特に困難です。 その場合は、データを取得するためのさらに良い代替手段の検討が必要な場合があります。 1 つのオプションは、Microsoft Graph からすべてのグループとグループ メンバーを抽出することです。 ただし、少数のグループだけが Power BI のセキュリティに使われている場合、それは実際的ではない可能性があります。 もう 1 つのオプションは、任意の種類の Power BI セキュリティ (ワークスペース ロール、アプリのアクセス許可、アイテムごとの共有、行レベルのセキュリティなど) で使われているグループの参照リストを事前に作成することです。 その後、その参照リストをループ処理して、Microsoft Graph からグループ メンバーを取得できます。

抽出して格納することがある他の属性を次に示します。

• ユーザーの種類: ユーザーはメンバーまたはゲストです。 最も一般的に、メンバーは内部ユーザーであり、ゲストは外部 (B2B) ユーザーです。 ユーザーの種類を格納すると、外部ユーザーのアクティビティを分析する必要がある場合に便利です。
• ロールの変更: セキュリティ監査を実行するときは、ユーザーが組織でいつロールを変更したのかがわかると便利です (たとえば、別の部署に異動するときなど)。 そうすることで、Power BI のセキュリティ設定が更新されたか、または更新される必要があるかを確認できます。
• 無効なユーザー: ユーザーが組織を離れると、通常、管理者はそのユーザーのアカウントを無効にします。 無効なユーザーがワークスペース管理者またはセマンティック モデル所有者かどうかをチェックするプロセスを作成できます。

ヒント

Power BI のアクティビティ ログには、ユーザーがいつ試用版ライセンスにサインアップしたかを記録するイベントが含まれます。 そのイベントをユーザー ライセンス データ (Microsoft Entra ID から入手) と組み合わせて、全体像を生成できます。

ユーザーとグループのデータを取得する

ユーザーとグループに関するデータは、さまざまな方法で取得できます。

手法	説明	手動監査プロセスに適した選択	自動監査プロセスに適した選択
手動	Graph エクスプローラー
プログラムによる	Microsoft Graph API と SDK
プログラムによる	Az PowerShell モジュール

このセクションの残りの部分では、表で示した各手法について説明します。 非推奨であり、新しいソリューションに使ってはならないその他の手法については、このセクションの最後で説明します。

注意

多くのツールは名前が似ているため、オンラインで情報を読む場合は注意してください。 Microsoft エコシステムの一部のツールは、名前に Graph という用語が含まれています (Azure Resource Graph、GraphQL、Microsoft Security Graph API など)。 それらのツールは Microsoft Graph には関係ないため、この記事の範囲外です。

Microsoft Graph Explorer

Microsoft Graph エクスプローラーは、Microsoft Graph API について学習できる開発者ツールです。 他のツールやコンピューターのセットアップを必要としないため、簡単に始められる方法です。 サインインしてテナントからデータを取得したり、既定のテナントからサンプル データを取得したりできます。

Graph エクスプローラーを使うと、次のことができます。

• Microsoft Graph API に要求を手動で送信して、必要な情報を返すかどうかを調べます。
• スクリプトを記述する前に、URL、ヘッダー、本体を作成する方法を確認します。
• 非公式な方法でデータを調べます。
• 各 API に必要なアクセス許可を確認します。 新しいアクセス許可に同意することもできます。
• スクリプトの作成時に使うコード スニペットを取得します。

Graph エクスプローラーを開くには、こちらのリンクを使ってください。

Microsoft Graph API と SDK

Microsoft Graph API を使って、ユーザーとグループのデータを取得します。 それを使用して、Microsoft Entra ID、SharePoint Online、Teams、Exchange、Outlook などのサービスからデータを取得することもできます。

Microsoft Graph SDK は、基になる Microsoft Graph API 上の "API ラッパー" として機能します。 SDK は、ツールと機能がバンドルされている "ソフトウェア開発キット" です。 Microsoft Graph SDK では、Microsoft Graph API のセット全体が公開されます。

API に要求を直接送信できます。 または、好みの言語といずれかの SDK を使って、簡略化のレイヤーを追加することもできます。 詳しくは、前の「API または PowerShell コマンドレットを選択する」をご覧ください。

Microsoft Graph SDK は複数の言語をサポートしており、Microsoft Graph PowerShell モジュールもあります。 他に、Python、C#、その他の言語で使用できる SDK があります。

重要

Microsoft Graph PowerShell モジュールは、どちらも非推奨である Azure AD PowerShell モジュールと MSOnline (MSOL) モジュールに代わるものです。 非推奨のモジュールを使って新しいソリューションを作成しないでください。 Microsoft Graph PowerShell モジュールには、多くの機能と利点があります。 詳しくは、「Azure AD PowerShell から Microsoft Graph PowerShell にアップグレードする」をご覧ください。

Microsoft Graph PowerShell モジュールは、PowerShell ギャラリーからインストールできます。 Microsoft Graph は多くの Microsoft 365 サービスで動作するため、インストールする PowerShell モジュールが多数あります。

Power BI のテナント レベル監査でインストールする必要がある最も一般的な PowerShell モジュールを次に示します。

• 認証 (サインイン用)
• ユーザー
• グループ
• アプリケーション (およびサービス プリンシパル)
• ディレクトリ オブジェクト (およびライセンスの詳細)

ヒント

Microsoft は、Microsoft Graph PowerShell モジュールを定期的に更新します。 プレリリース ベースまたはベータ エンドポイントで、プレビュー モジュールを利用できる場合があります。 モジュールをインストールおよび更新するときに、関心のあるバージョンを指定することもできます。 また、オンライン ドキュメントを確認するときは、現在のバージョン番号が URL の末尾に自動的に追加されることに注意してください (そのため、URL を保存または共有するときは注意してください)。

Az PowerShell モジュール

Az PowerShell モジュールを使って、ユーザーとグループのデータを取得することもできます。 その対象となるのは Azure リソースです。

重要

Az PowerShell モジュールは、非推奨になった AzureRM PowerShell モジュールに代わるものです。 非推奨のモジュールを使って新しいソリューションを作成しないでください。

API に対応するコマンドレットがない場合は、Invoke-AzRestMethod コマンドレットを使用できます。 これは、Az PowerShell モジュールを使って任意の Microsoft Graph API に要求を送信できる柔軟なアプローチです。

Az バージョン 7 以降の Az コマンドレットでは、Microsoft Graph API が参照されるようになっています。 そのため、Az モジュールは Microsoft Graph 上の "API ラッパー" として機能します。 Az モジュールには、Microsoft Graph API と PowerShell モジュールに含まれる機能のサブセットがあります。 新しいソリューションの場合は、Microsoft Graph PowerShell SDK を使うことをお勧めします。

非推奨の API とモジュール

このセクションに記載されていない代替オプションを提案する記事やブログ記事がオンラインで見つかる場合があります。 次のいずれかの API またはモジュールを使って、新しいソリューションを作成 (または既存のソリューションを移行) "しないこと" を強くお勧めします。

• AzureRM PowerShell モジュール: 非推奨であり、廃止される予定です。 これらは、Az PowerShell モジュールに置き換えられました。
• Azure AD Graph API と Azure AD PowerShell モジュール: 非推奨であり、廃止される予定です。 この変更は、Azure AD Graph から Microsoft Graph への移行の結果です (両方の名前に Graph が含まれますが、今後は Microsoft Graph であることに注意してください)。 PowerShell に関する今後の投資はすべて、Microsoft Graph PowerShell SDK で行われます。
• MS Online (MSOL) PowerShell モジュール: 非推奨であり、廃止される予定です。 PowerShell に関する今後の投資はすべて、Microsoft Graph PowerShell SDK で行われます。

注意事項

現在使っている非推奨の API またはモジュールの状態を必ず確認してください。 AzureRM の廃止について詳しくは、こちらのお知らせをご覧ください。

Microsoft Entra ID と MSOL の詳細については、こちらの廃止のお知らせに関する投稿をご覧ください。

プログラムによるデータ アクセスの今後の方向性について質問がある場合、または説明が必要な場合は、Microsoft アカウント チームにお問い合わせください。

チェックリスト - ユーザーとグループのデータへのアクセスを計画するときの主な決定事項とアクションは次のとおりです。

• 要件を確認する: ユーザー、グループ、ライセンスに関連するデータの収集に関するニーズを明確にします。
• 要件の優先順位を決める: 最初に時間を費やすべきものがわかるように、最優先の事項を確認します。
• データを抽出する頻度を決める: ユーザーとグループのデータの新しいスナップショットが必要になる頻度を決めます (毎週、毎月など)。
• Microsoft Graph でデータを抽出する方法を決める: データの取得に使う方法を決めます。
• 概念実証を行う: ユーザーとグループのデータの抽出に関する小規模な技術的概念実証 (POC) の実施を計画します。 それを使って、最終的なソリューションの構築方法に関する決定を検証します。

Power BI REST API からデータにアクセスする

優先度はおそらく低いものの、Power BI REST API を使って他のデータを取得することもできます。

たとえば、次に関するデータを取得できます。

• 組織内のすべてのアプリ。
• 組織にインポートされたすべてのセマンティック モデル。
• 組織内のすべてのデプロイ パイプライン。
• 組織内のすべての Premium 容量。

セキュリティ監査の間に、次の情報を明らかにすることが必要になる場合があります。

• 組織全体で広く共有されているアイテム。
• Web への発行を使ってパブリック インターネットで利用できるアイテム。

他の種類の API について詳しくは、前の「ユーザー API または管理 API を選択する」をご覧ください。

チェックリスト - Power BI API からデータへのアクセスを計画するときの主な決定事項とアクションは次のとおりです。

• 要件を取得する: 発生した分析要件をまとめます。 バックログでそれらを追跡します。
• 要件の優先順位を決める: 発生した新しい要件の優先順位を設定します。

フェーズ 2: 前提条件とセットアップ

テナント レベルの監査ソリューションの計画と実装の 2 番目のフェーズの焦点は、前提条件と、ソリューションの開発を始める前に行う必要があるセットアップです。

ストレージ アカウントの作成

この時点では、生データを格納する場所と、キュレーションされたデータを作成する方法の決定が済んでいます。 それらの決定に基づいて、ストレージ アカウントを作成できる状態になっています。 組織のプロセスによっては、IT 部署に要求を送ることが含まれる場合があります。

前に説明したように、生データを不変ストレージに書き込める技術を使うことをお勧めします。 データが書き込まれたら、それを変更または削除することはできません。 これにより、アクセス権を持つ管理者がどのような方法でもそれを変更できないことがわかっているため、生データを信頼できます。 ただし、キュレーションされたデータは、(通常は) 不変ストレージに格納する必要はありません。 キュレーションされたデータは、変更される可能性があるか、または再生成できます。

チェックリスト – ストレージ アカウントを作成するときの主な決定事項とアクションは次のとおりです。

• ストレージ アカウントを作成する: ストレージ アカウントを作成するか、作成要求を送信します。 可能な場合には、生データでは不変ストレージの設定を使用します。
• アクセス許可を設定する: ストレージ アカウントに設定する必要があるアクセス許可を決めます。
• アクセスをテストする: 簡単なテストを行って、ストレージ アカウントの読み取りと書き込みができることを確認します。
• 責任を確認する: ストレージ アカウントを継続的に管理するユーザーが明確になっていることを確認します。

ソフトウェアをインストールしてサービスをセットアップする

この時点では、監査データへのアクセスに使う技術についての決定が済んでいます。 それらの決定に基づいて、ソフトウェアをインストールしてサービスを設定する準備ができています。

管理者ごとに望ましい開発環境を設定します。 開発環境を使って、スクリプトの記述とテストを行うことができるようになります。 Visual Studio Code はスクリプトを開発するための最新のツールであるため、適切なオプションです。 また、多数の拡張機能を Visual Studio Code で使用できます。

PowerShell の使用を決定した場合は (前に説明しました)、PowerShell Core と必要な PowerShell モジュールを次の場所にインストールする必要があります。

• 監査スクリプトを記述またはテストする各管理者や開発者のコンピューター。
• スケジュールされたスクリプトを実行する各仮想マシンまたはサーバー。
• 各オンライン サービス (Azure Functions や Azure Automation など)。

いずれかの Azure サービス (Azure Functions、Azure Automation、Azure Data Factory、Azure Synapse Analytics など) を使うことを選んだ場合は、それらをプロビジョニングして設定する必要があります。

チェックリスト – ソフトウェアをインストールしてサービスを設定するときの主な決定事項とアクションは次のとおりです。

• 管理者と開発者のコンピューターを設定する: 該当する場合は、開発に使う必要があるツールをインストールします。
• サーバーを設定する: 該当する場合は、アーキテクチャに存在するサーバーまたは仮想マシンに必要なツールをインストールします。
• Azure サービスを設定する: 該当する場合は、各 Azure サービスをプロビジョニングして設定します。 開発作業を行う各管理者と開発者にアクセス許可を割り当てます。

Microsoft Entra アプリケーションを登録する

この時点では、認証を行う方法が決まっています。 Microsoft Entra アプリケーション (サービス プリンシパル) を登録することをお勧めします。 一般に "アプリの登録" と呼ばれ、自動化する無人操作に使う必要があります。

テナント レベルの監査データを取得するためのアプリの登録を作成する方法について詳しくは、「読み取り専用の管理 API に対してサービス プリンシパル認証を有効にする」をご覧ください。

チェックリスト – Microsoft Entra アプリケーションを登録するときの主な決定事項とアクションは次のとおりです。

• アプリの登録が既に存在するかどうかを調べる: 管理 API を実行するために利用できる既存のアプリの登録があるかどうかを IT 部署に確認します。 そうである場合は、既存のものを使うか、新しく作成するかを決めます。
• 新しいアプリの登録を作成する: 必要に応じて、アプリの登録を作成します。 目的を明確に示す PowerBI-AdminAPIs-EntraApp などのアプリ名を使用することを検討してください。
• アプリの登録用のシークレットを作成する: アプリの登録が存在するようになったら、そのシークレットを作成します。 シークレットをローテーションする頻度に基づいて、有効期限を設定します。
• 値を安全に保存する: サービス プリンシパルで認証を行うときに必要になるため、シークレット、アプリ ID (クライアント ID)、テナント ID を保管します。 組織のパスワード コンテナーなど、セキュリティで保護された場所を使います。 (IT 部署にアプリの登録の作成を要求する必要がある場合は、これらの値を返してもらう必要があることを指定します)。
• セキュリティ グループを作成する: Power BI に使うセキュリティ グループを作成 (または要求) します。 グループがテナント全体のメタデータへのアクセスに使われることを示す、"Power BI 管理サービス プリンシパル" のようなグループ名を使うことを検討します。
• セキュリティ グループのメンバーとしてサービス プリンシパルを追加する: アプリ ID (クライアント ID) を使い、新しい (または既存の) サービス プリンシパルを新しいセキュリティ グループのメンバーとして追加します。
• Power BI で管理 API のテナント設定を更新する: Power BI 管理ポータルで、[読み取り専用 Power BI 管理 API の使用をサービス プリンシパルに許可] テナント設定にセキュリティ グループを追加します。
• Azure でのアクセス許可の割り当てをスキップする: アプリの登録にアクセス許可を委任しないでください (Power BI の [読み取り専用 Power BI 管理 API の使用をサービス プリンシパルに許可] テナント設定によって、Power BI のテナント レベルの監査データにアクセスできるようになります)。
• アプリの登録で詳細なメタデータにアクセスする必要があるかどうかを決める: テナント インベントリを構築するときに、セマンティック モデル テーブル、列、メジャー式に関する詳細情報を抽出するかどうかを決めます。
• Power BI で詳細なメタデータ テナント設定を更新する: 必要に応じて、Power BI 管理ポータルで、セキュリティ グループを [Enhance admin API responses with detailed metadata] (詳細なメタデータで管理 API の応答を拡張する) テナント設定と、[Enhance admin API responses with DAX and mashup expressions] (DAX とマッシュアップの式で管理 API の応答を拡張する) テナント設定に追加します。
• サービス プリンシパルをテストする: サービス プリンシパルを使ってサインインする簡単なスクリプトを作成し、管理 API からデータを取得できることをテストします。
• アプリの登録のシークレットを管理するプロセスを作成する: シークレットの定期的なローテーションに関するドキュメントとプロセスを作成します。 新しいシークレットを、それを必要とする管理者や開発者に安全に伝える方法を決めます。

Power BI テナントの設定を行う

Power BI 管理ポータルには、テナント レベルの監査データの抽出に関連するいくつかのテナント設定があります。

管理 API

管理 API の実行に関連する 3 つのテナント設定があります。

重要

これらの設定により、テナント全体のメタデータ アクセスが許可されるため (直接 Power BI のアクセス許可を割り当てずに)、それらを厳密に制御する必要があります。

[読み取り専用 Power BI 管理 API の使用をサービス プリンシパルに許可] テナント設定を使うと、管理 API を呼び出すことができるサービス プリンシパルを設定できます。 この設定により、Microsoft Purview が Power BI テナント全体をスキャンすることも可能になり、データ カタログにデータを設定できます。

注意

テナント全体のメタデータに既にアクセスできるため、他の Power BI 管理者を [読み取り専用 Power BI 管理 API の使用をサービス プリンシパルに許可] テナント設定に明示的に割り当てる必要はありません。

[Enhance admin API responses with detailed metadata] (詳細なメタデータで管理 API の応答を拡張する) テナント設定を使うと、詳細なメタデータを取得できるユーザーとサービス プリンシパルを設定できます。 メタデータはメタデータ スキャン API を使って取得され、それにはテーブルや列などが含まれます。 この設定により、Microsoft Purview が Power BI セマンティック モデルに関するスキーマ レベルの情報にアクセスすることも可能になり、データ カタログにそれを格納できます。

[Enhance admin API responses with DAX and mashup expressions] (DAX とマッシュアップの式で管理 API の応答を拡張する) テナント設定を使うと、詳細なメタデータを取得できるユーザーとサービス プリンシパルを設定できます。 メタデータはメタデータ スキャン API から取得され、クエリとセマンティック モデルのメジャー式を含めることができます。

Note

[読み取り専用 Power BI 管理 API の使用をサービス プリンシパルに許可] テナント設定は、特に "管理 API" へのアクセスに関する設定です。 その名前は、"ユーザー API" (次に説明します) にアクセスするためのテナント設定とよく似ています。 管理 API とユーザー API の違いについて詳しくは、前の「ユーザー API または管理 API を選択する」をご覧ください。

ユーザー API

ユーザー API の呼び出しに適用されるテナント設定が 1 つあります。 この場合のサービス プリンシパルには、Power BI のアクセス許可も必要です (ワークスペース ロールなど)。

[Allow service principals to use Power BI APIs] (サービス プリンシパルに Power BI API の使用を許可する) テナント設定を使うと、REST API の実行にアクセスできるサービス プリンシパルを設定できます (前に説明した別のテナント設定によって許可される管理 API は除きます)。

API に関連するテナント設定は他にもあり、それを使うと、埋め込み API、ストリーミング API、エクスポート API、"クエリ実行" API にアクセスできるようになります。 ただし、これらの API はこの記事の範囲外です。

使用状況メトリックに関するテナント設定について詳しくは、レポート レベルの監査に関する記事をご覧ください。

チェックリスト - Power BI のテナント設定をセットアップするときの主な決定事項とアクションは次のとおりです。

• 各サービス プリンシパルが正しいグループに含まれていることを確認する: "Power BI 管理サービス プリンシパル" グループに正しいサービス プリンシパルが含まれていることを確認します。
• Power BI で管理 API のテナント設定を更新する: セキュリティ グループを [読み取り専用 Power BI 管理 API の使用をサービス プリンシパルに許可] テナント設定に追加します。これにより、管理 API を使ってテナント全体のメタデータを取得できます。
• Power BI で詳細なメタデータ テナント設定を更新する: 必要な場合は、セキュリティ グループを [Enhance admin API responses with detailed metadata] (詳細なメタデータで管理 API の応答を拡張する) テナント設定と、[Enhance admin API responses with DAX and mashup expressions] (DAX とマッシュアップの式で管理 API の応答を拡張する) テナント設定に追加します。
• アクセスされるユーザー API を確認する: 1 つ以上のユーザー API が必要かどうかを確認します (管理 API の使用に加えて)。
• Power BI でユーザー API のテナント設定を更新する: セキュリティ グループを、ユーザー API を対象とする [Allow service principals to use Power BI APIs] (サービス プリンシパルに Power BI API の使用を許可する) テナント設定に追加します。

フェーズ 3: ソリューションの開発と分析

テナント レベルの監査ソリューションの計画と実装の 3 番目のフェーズの焦点は、ソリューションの開発と分析です。 この時点では、すべての計画と意思決定が行われ、前提条件を満たし、セットアップが完了しています。 分析を実行し、監査データから分析情報を得ることができるように、ソリューションの開発を始める準備ができています。

生データを抽出して格納する

この時点では、要件と優先順位が明確になっているはずです。 監査データにアクセスする方法と監査データを格納する場所についての技術的に重要な決定が行われています。 推奨されるツールが選択され、前提条件と設定がセットアップされています。 前の 2 つのフェーズの間に、実現可能性を証明するための 1 つ以上の小さなプロジェクト (概念実証) を完了している可能性があります。 次のステップでは、生の監査データを抽出して格納するプロセスを設定します。

ほとんどの Microsoft API によって返されるデータと同様に、監査データは JSON として書式設定されます。 JSON 形式のデータは、構造とデータを含む人間が判読できるテキストであるため、自己記述型です。

JSON は、属性と値のペアおよび配列で構成されるデータ オブジェクトを表します。 たとえば、"state": "Active" という例では、state 属性の値が Active です。 JSON 配列には、コンマで区切られ、角かっこ ([ ]) で囲まれた、要素の順序付きリストが含まれます。 JSON の結果では、入れ子になった配列を検索するのが一般的です。 JSON の結果の階層構造に慣れると、ワークスペース内のセマンティック モデルのリスト (配列) のようなデータ構造を簡単に理解できます。

API から取得された生データを抽出して格納するときの考慮事項を次に示します。

• どのような名前付け規則を使うか? ファイル ベースのシステムでは、ファイル、フォルダー、データ レイク ゾーンに関する名前付け規則が必要です。 データベースでは、テーブルと列に関する名前付け規則が必要です。
• 生データの格納には、どのような形式を使うか? Power BI では継続的に新機能が導入されるため、現在は存在しない新しいアクティビティが出現します。 このため、元の JSON 結果を抽出して保持することをお勧めします。 抽出の間に、データの解析、フィルター処理、または書式設定を行わないでください。 そうすることで、元の生データを使って、キュレーションされた監査データを生成し直すことができます。
• どのようなストレージの場所を使うか? 一般的に、生データの格納にはデータ レイクまたは BLOB ストレージが使われます。 詳しくは、前の「監査データを格納する場所を決定する」をご覧ください。
• どの程度の履歴を保存するか? 履歴を格納できる場所に、監査データをエクスポートします。 少なくとも 2 年間の履歴を蓄積するように計画します。 そうすることで、既定の 30 日間の保持期間を超えて、傾向や変化を分析できます。 組織のデータ保持ポリシーに応じて、データを無期限に格納したり、さらに短い期間にしたりすることがあります。
• プロセスが最後に実行されたときを、どのようにして追跡するか? プロセスの開始時と終了時にタイム スタンプを記録するように、構成ファイル (またはそれに相当するもの) を設定します。 次にプロセスを実行したときに、これらのタイム スタンプを取得できます。 メタデータ スキャン API を使ってデータを抽出する場合は、タイム スタンプを格納することが特に重要です。
• 調整をどのように処理するか? 一部の Power BI REST API と Microsoft Graph API では、調整が実装されています。 API の要求が調整されると、429 エラー (要求が多すぎる) を受け取ります。 大量のデータを取得する必要がある大規模な組織では、調整が一般的な問題になる可能性があります。 調整による試行の失敗を回避する方法は、データのアクセスと抽出に使用する技術によって異なります。 1 つのオプションは、待機期間の後に再試行することで、429 "要求が多すぎる" エラーに対応するロジックを、スクリプトで開発することです。
• コンプライアンスのために監査データが必要か? 多くの組織では、生の監査ログ レコードを使って、コンプライアンス監査を行ったり、セキュリティ調査に対応したりします。 このような場合は、生データを不変ストレージに格納することを強くお勧めします。 こうすることで、書き込まれた後のデータを、管理者や他のユーザーが変更または削除することはできません。
• 要件をサポートするために必要なストレージ レイヤーは何か? 生データを格納するのに最適な場所は、データ レイク (Azure Data Lake Storage Gen2 など) またはオブジェクト ストレージ (Azure Blob Storage など) です。 クラウド サービスがオプションでない場合は、ファイル システムを使うこともできます。

チェックリスト - 生データを抽出して格納するときの主な決定事項とアクションは次のとおりです。

• 要件と優先順位を確認する: 最初に抽出するデータの要件と優先順位を明確にします。
• 抽出するデータのソースを確認する: 必要なデータの種類ごとにソースを確認します。
• データを抽出して生データ ゾーンに読み込むプロセスを設定する: 変換を行わずに、生データを元の状態で抽出して読み込む最初のプロセスを作成します。 プロセスが意図したとおりに動作することをテストします。
• プロセスを実行するスケジュールを作成する: 抽出、読み込み、変換のプロセスを実行する定期的なスケジュールを設定します。
• 資格情報が安全に管理されていることを確認する: パスワード、シークレット、キーが安全な方法で格納および通信されていることを確認します。
• セキュリティが正しく設定されていることを確認する: 生データに対してアクセス許可が正しく設定されていることを確認します。 管理者と監査担当者が生データにアクセスできることを確認します。

監査と監視ソリューションが時間の経過と共にどのように成長するのかについて詳しくは、後の「運用化して改善する」をご覧ください。

キュレーションされたデータを作成する

この時点では、生データが抽出されて格納されています。 次のステップは、キュレーション済みのデータ用として、分離されたゴールド データ レイヤーを作成することです。 その目的は、データ ファイルを変換してスター スキーマに格納することです。 スター スキーマはディメンション テーブルとファクト テーブルで構成され、分析とレポート用に意図的に最適化されています。 キュレーションされたデータ レイヤー内のファイルは、Power BI データ モデルのソースになります (次のトピックで説明します)。

ヒント

複数のデータ モデルが存在すると予想される場合は、キュレーションされたデータ レイヤーに一元化すると特に便利です。

チェックリスト - キュレーションされたデータ レイヤーを作成するときの主な決定事項とアクションは次のとおりです。

• 要件と優先順位を確認する: 変換されたデータ用に中間のシルバー レイヤーを使う場合は、達成しようとしていることに関する要件と目標を明確にします。
• 生データを変換し、キュレーションされたデータ ゾーンに読み込むプロセスを設定する: データを変換してスター スキーマに読み込むプロセスを作成します。 プロセスが意図したとおりに動作することをテストします。
• プロセスを実行するスケジュールを作成する: キュレーションされたデータ レイヤーを設定する定期的なスケジュールをセットアップします。
• セキュリティが正しく設定されていることを確認する: キュレーションされたデータに対してアクセス許可が正しく設定されていることを確認します。 データ モデルの開発者がキュレーションされたデータにアクセスできることを確認します。

データ モデルを作成する

このトピックでは、分析 "データ モデル" の設定について説明します。 データ モデルは、分析用に最適化されたクエリ可能なデータ リソースです。 "セマンティック モデル" または単に "モデル" と呼ばれることもあります。 監査と監視ソリューションの場合、データ モデルは Power BI セマンティック モデルとして実装される可能性があります。

監査と監視のコンテキストでは、データ モデルはキュレーションされた (ゴールド) データ レイヤーをデータのソースにします。 キュレーションされたデータ レイヤーを作成しないことを選んだ場合、データ モデルは生データを直接データのソースにします。

Power BI データ モデルでは、スター スキーマ設計を実装することをお勧めします。 ソース データがキュレーションされたデータ レイヤーである場合、Power BI データ モデルのスター スキーマでは、キュレーションされたデータ レイヤーのスター スキーマを反映する必要があります。

ヒント

スター スキーマ設計の概要については、「スター スキーマと Power BI での重要性を理解する」をご覧ください。

他の Power BI プロジェクトと同様に、データ モデルの作成は反復的なプロセスです。 必要に応じて新しいメジャーを追加できます。 新しい監査イベントが使用できるようになったら、新しいテーブルと列を追加することもできます。 場合によっては、新しいデータ ソースを統合することもあります。

データ モデルに含めることができる便利なディメンション テーブルをいくつか示します。

• 日付: 日、週、月、四半期、年、その他の関連する期間の単位でデータの分析 (スライスとダイス) を行うことができる一連の日付属性。
• 時刻: 時刻単位で分析する必要があり、非常に大量の監査データがある場合は、時刻部分を日付とは別に格納することを検討します。 このようにすると、クエリのパフォーマンスを向上させることができます。
• ユーザー: 監査データの多くのサブジェクトをフィルター処理できるユーザーを記述する属性 (部署や地理的地域など)。 目的は、ファクト テーブルからユーザーの詳細をすべて削除し、このディメンション テーブルに格納して、多くのファクト テーブルをフィルター処理できるようにすることです。 サービス プリンシパルもこのテーブルに格納できます。
• アクティビティ イベント: アクティビティ イベント (操作) をグループ化して記述する属性。 レポートを拡張するには、各アクティビティ イベントを記述するデータ ディクショナリを作成できます。 また、似たアクティビティ イベントをグループ化して分類する階層を作成することもできます。 たとえば、すべてのアイテム作成イベントをグループ化したり、イベントを削除したりできます。
• ワークスペース: テナント内のワークスペースの一覧と、種類 (個人用または標準) や説明などのワークスペースのプロパティ。 ワークスペースに関するさらに詳細な情報を記録する組織もあります (おそらく、SharePoint リストを使って)。 これらの詳細は、このディメンション テーブルに統合できます。 このディメンション テーブルに、ワークスペースの現在の状態のみを格納するか、それともワークスペースの大幅な変更を経時的に反映するバージョン管理されたデータを格納するかを、決める必要があります。 たとえば、ワークスペースの名前が変更されたとき、履歴レポートには、現在のワークスペース名またはその時点でのワークスペース名のどちらを表示しますか。 バージョン管理について詳しくは、「緩やかに変化するディメンション」をご覧ください。
• アイテムの種類: Power BI のアイテムの種類 (セマンティック モデル、レポートなど) のリスト。
• 容量: テナント内の Premium 容量のリスト。
• ゲートウェイ: テナント内のデータ ゲートウェイのリスト。
• データ ソース: セマンティック モデル、データフロー、またはデータマートで使われるデータ ソースのリスト。

データ モデルに含めることができる便利なファクト テーブル (サブジェクト) をいくつか示します。

• ユーザー アクティビティ: 元の JSON データをソースとするファクト データ。 分析値を持たない属性はすべて削除されます。 ディメンション テーブル (上記) に属する属性もすべて削除されます。
• テナント インベントリ: テナントで発行されたすべてのアイテムのポイントインタイム スナップショット。 詳しくは、前の「テナント インベントリ」をご覧ください。
• セマンティック モデル: セマンティック モデル (セマンティック モデルの変更など) または関連するデータ ソースが関係するユーザー アクティビティが含まれます。
• セマンティック モデルの更新: 種類 (スケジュールまたはオンデマンド)、期間、状態、操作を開始したユーザーに関する詳細など、データ更新操作を格納します。
• ワークスペース ロール: ワークスペース ロールの割り当てのポイントインタイム スナップショット。
• ユーザー ライセンス: ユーザー ライセンスのポイントインタイム スナップショット。 ユーザー ライセンスはユーザー ディメンション テーブルに格納したくなるかもしれませんが、その方法では、経時的なライセンス変更と傾向の分析はサポートされません。
• ユーザー グループ メンバーシップ: セキュリティ グループに割り当てられているユーザー (およびサービス プリンシパル) のポイントインタイム スナップショット。
• コミュニティ アクティビティ: トレーニング イベントなど、コミュニティ関連のファクトが含まれます。 たとえば、トレーニングへの参加と比較して Power BI のユーザー アクティビティを分析できます。 このデータは、センター オブ エクセレンスが潜在的な新しいチャンピオンを特定するのに役立ちます。

ファクト テーブルには、レポート作成者がフィルター処理する列を含めることはできません。 代わりに、それらの列は関連するディメンション テーブルに属します。 この設計は、クエリに関していっそう効率的であるだけでなく、複数のファクトによるディメンション テーブルの再利用も促進されます ("ドリル アクロス" と呼ばれます)。 この最後の点は、新しいファクト テーブル (サブジェクト) を追加するときに拡張可能で役に立つ使いやすいデータ モデルを作成するために重要です。

たとえば、ユーザー ディメンション テーブルはすべてのファクト テーブルに関連付けられます。 これは、ユーザー アクティビティ ファクト テーブル (アクティビティを実行したユーザー)、テナント インベントリ ファクト テーブル (発行済みアイテムを作成したユーザー)、その他のすべてのファクト テーブルに関連付けられている必要があります。 ユーザー ディメンション テーブルのユーザーがレポートをフィルター処理すると、そのレポート内の視覚エフェクトに、そのユーザーの関連するファクト テーブルからのファクトを表示できます。

モデルを設計するときは、ある属性がモデル内でただ 1 回だけ表示されるようにします。 たとえば、ユーザーのメール アドレスはユーザー ディメンション テーブルでのみ表示される必要があります。 それは他のファクト テーブルにも存在します (モデルのリレーションシップをサポートするためのディメンション キーとして)。 しかし、各ファクト テーブルでは表示されないようにする必要があります。

データ モデルは、レポートとは別に作成することをお勧めします。 セマンティック モデルとそのレポートを分離すると、多くのレポートに対応できる一元化されたセマンティック モデルが作成されます。 共有セマンティック モデルの使用について詳しくは、管理されたセルフサービス BI の使用シナリオをご覧ください。

センター オブ エクセレンス、監査担当者、管理者以外の他のユーザーが監査データを分析して報告できるように、行レベルのセキュリティ (RLS) を設定することを検討します。 たとえば、RLS ルールを使うと、コンテンツ作成者やコンシューマーに、自分のユーザー アクティビティや開発作業についてレポートすることを許可できます。

チェックリスト - データ モデルを作成するときの主な決定事項とアクションは次のとおりです。

• データ モデルを計画して作成する: データ モデルをスター スキーマとして設計します。 リレーションシップが意図したとおりに機能することを検証します。 モデルを開発するときは、反復的にメジャーを作成し、分析要件に基づいて新しいデータを追加します。 必要に応じて、将来の機能強化をバックログに含めます。
• RLS を設定する: 他の一般ユーザーがデータ モデルを使用できるようにする場合は、行レベルのセキュリティを設定してデータ アクセスを制限します。 RLS ロールが正しいデータを返すことを検証します。

データ モデルを強化する

コンテンツの使用状況とユーザー アクティビティを効果的に分析するには、データ モデルをエンリッチすることをお勧めします。 データ モデルの拡張は、機会と新しい要件の発見に合わせて、時間をかけて少しずつ反復的に行うことができます。

分類を作成する

モデルを拡張し、データの価値を高める方法の 1 つは、データ モデルに分類を追加することです。 これらの分類がレポートで一貫して使われるようにします。

"ユーザー" をその使用レベルに基づいて分類したり、"コンテンツ" をその使用レベルに基づいて分類したりできます。

ユーザーの使用状況の分類

"ユーザーの使用状況" に関しては、次の分類を検討します。

• 頻度の高いユーザー: 過去 1 週間、および過去 12 か月のうち 9 か月でアクティビティが記録されている。
• アクティブなユーザー: 過去 1 か月間にアクティビティが記録されている。
• 頻度の低いユーザー: 過去 9 か月間にアクティビティが記録されているが、過去 1 か月間はアクティビティが記録されていない。
• 非アクティブなユーザー: 過去 9 か月間にアクティビティが記録されていない。

ヒント

特に Pro または PPU ライセンスを使っている場合 (コストが関係します)、低頻度または非アクティブなユーザーを知ると役に立ちます。 また、高頻度で最もアクティブなユーザーを知ることも役に立ちます。 オフィス アワーやトレーニングに参加するよう招待することを検討します。 最もアクティブなコンテンツ作成者は、チャンピオン ネットワークに参加する候補となる可能性があります。

コンテンツの使用状況の分類

"コンテンツの使用状況" に関しては、次の分類を検討します。

• 使用頻度の高いコンテンツ: 過去 1 週間、および過去 12 か月のうち 9 か月でアクティビティが記録されている。
• アクティブに使われているコンテンツ: 過去 1 か月間にアクティビティが記録されている。
• 使用頻度の低いコンテンツ: 過去 9 か月間にアクティビティが記録されているが、過去 1 か月間はアクティビティが記録されていない。
• 使われていないコンテンツ: 過去 9 か月間にアクティビティが記録されていない。

ユーザーの種類の分類

"ユーザーの種類" に関しては、次の分類を検討します。

• コンテンツ作成者: 過去 6 か月間にコンテンツの作成、発行、または編集のアクティビティが記録された。
• コンテンツ視聴者: 過去 6 か月間に、コンテンツ視聴アクティビティは記録されているが、コンテンツ作成アクティビティは記録されていない。

新しさか傾向かを考慮する

ユーザーまたはコンテンツの使用状況の分類を、アクティビティが発生した "新しさ" だけを基にするかどうかを決める必要があります。 また、経時的な "平均" または "傾向" の使用状況を考慮することもできます。

いくつかの例を検討して、単純な分類ロジックにより現実がどのように誤って表されるかを示します。

• あるマネージャーは今週 1 つのレポートを見ました。 しかし、そのマネージャーは、その週より前は、過去 6 か月間どのレポートも見ていませんでした。 最近の使用状況だけに基づいて、このマネージャーを高頻度のユーザーと見なしてはなりません。
• あるレポート作成者は、毎週新しいレポートを発行しています。 高頻度のユーザーによる使用状況の分析では、そのレポート作成者の通常のアクティビティは肯定的であるように見えます。 しかし、さらに調査すると、このユーザーはレポートを編集するたびに、新しいレポート (新しいレポート名で) を再発行していたことがわかりました。 そのレポート作成者はさらにトレーニングしたほうがよさそうです。
• ある役員はレポートを気が向いたときに見るため、使用状況の分類が頻繁に変わります。 役員など、特定の種類のユーザーは、異なる方法で分析する必要があるかもしれません。
• ある内部監査担当者は、重要なレポートを年に 1 回見ています。 その内部監査担当者は、使用頻度が低いため、非アクティブなユーザーのように見えるかもしれません。 誰かが、その人の Pro または PPU ライセンスの削除手順を実行する可能性があります。 または、レポートの使用頻度が低いため、レポートを廃止する必要があると考える可能性があります。

ヒント

DAX タイム インテリジェンス関数を使うことで、平均と傾向を計算できます。 これらの関数の使い方については、「Power BI Desktop モデルで DAX タイム インテリジェンス関数を使用する」学習モジュールをご覧ください。

チェックリスト - 使用状況データの分類を作成するときの主な決定事項とアクションは次のとおりです。

• 分類の定義に関する合意を得る: 分類の定義について、関連する利害関係者と話し合います。 決定するときは、必ず同意を得ます。
• ドキュメントを作成する: コンテンツ作成者とコンシューマー向けのドキュメントに、分類の定義が含まれるようにします。
• フィードバック ループを作成する: ユーザーが質問したり、分類定義の変更を提案したりする方法を設けるようにします。

分析レポートを作成する

この時点では、監査データが抽出されて格納されており、データ モデルを発行してあります。 次のステップは、分析レポートの作成です。

各対象ユーザーに最も関連性の高い重要な情報に焦点を当てます。 監査レポートには複数の対象ユーザーがいる場合があります。 対象ユーザーごとに、関心を持つ情報や目的が異なります。 次のような対象ユーザーにレポートを提供する可能性があります。

• エグゼクティブ スポンサー
• センター オブ エクセレンス
• Power BI 管理者
• ワークスペース管理者
• Premium 容量管理者
• ゲートウェイ管理者
• Power BI 開発者とコンテンツ作成者
• 監査者

監査レポートを作成するときに最初に対応することが必要になる場合がある、最も一般的な分析要件をいくつか次に示します。

• 上位のコンテンツ ビュー: エグゼクティブ スポンサーとリーダーシップ チームは、主に経時的な概要情報と傾向に関心を持つ可能性があります。 ワークスペース管理者、開発者、コンテンツ作成者は、詳細情報により高い関心を持ちます。
• 上位のユーザー アクティビティ: センター オブ エクセレンスは、誰が、どのように、いつ Power BI を使っているのかに関心があります。 Premium 容量管理者は、正常性と安定性を確保するため、容量を使っているユーザーに関心があります。
• テナント インベントリ: Power BI 管理者、ワークスペース管理者、監査担当者は、存在するコンテンツ、場所、系列、そのセキュリティ設定を理解することに関心があります。

この一覧はすべてを網羅するものではありません。 特定のニーズを対象とする分析レポートを作成する方法に関するアイデアを提供することを目的としています。 その他の考慮事項については、前の「データのニーズ」と、監査と監視の概要に関する記事をご覧ください。 これらのリソースには、監査データの使用方法に関する多くのアイデアと、レポートで提供する可能性がある情報の種類が含まれます。

ヒント

多くのデータを提供したくなりますが、対処する準備ができている情報のみを含めるようにします。 すべてのレポート ページで、その目的、実行する必要があるアクション、実行するユーザーがはっきりわかるようにします。

分析レポートを作成する方法については、「Power BI のデザイン効果の高いレポート」ラーニング パスで学習してください。

チェックリスト - 分析監査レポートを計画するときの主な決定事項とアクションは次のとおりです。

• 要件を確認する: 既知のニーズと回答する必要がある特定の質問に基づいて、レポート作成の優先順位を決めます。
• 対象ユーザーを確認する: 監査レポートを使用するユーザーと、その目的を明確にします。
• レポートを作成して展開する: コア レポートの最初のセットを開発します。 時間をかけて徐々に拡張し、強化します。
• アプリでレポートを配布する: すべての監査レポートと監視レポートを含むアプリの作成を検討します。
• レポートにアクセスできるユーザーを検証する: 正しい一連のユーザーがレポート (またはアプリ) を使用できることを確認します。
• フィードバック ループを作成する: レポートのコンシューマーがフィードバックや提案を提供したり、問題を報告したりする方法があることを確認します。

データに基づいてアクションを実行する

監査データに価値があるのは、それが Power BI テナントで起こっていることを理解するのに役立つためです。 当たり前のことのように思われますが、監査データから学んだことへの明確な対処は、見過ごされる可能性があります。 そのため、単に監査レポートを確認するのではなく、測定可能な改善の追跡を担当するユーザーを割り当てることをお勧めします。 そうすることで、Power BI に関する導入と成熟度レベルの段階的で測定可能な拡大を実現できます。

目標と監査データから学んだことに基づいて、さまざまなアクションを実行できます。 このセクションの残りの部分では、いくつかのアイデアについて説明します。

コンテンツの使用状況

コンテンツの使用方法に基づいて実行できるいくつかのアクションを次に示します。

• コンテンツは頻繁に使われている (毎日または毎週): 重要なコンテンツが認められていることを確認します。 所有権が明確であり、ソリューションが適切にサポートされていることを確認します。
• ワークスペース ビューの数が多い: ワークスペース ビューの数が多い場合は、Power BI アプリが使われていない理由を調べます。
• コンテンツはほとんど使われていない: 対象ユーザーに連絡して、ソリューションがニーズを満たしているかどうか、または要件が変わったかどうかを判断します。
• 更新アクティビティが表示より頻繁に発生している: コンテンツ所有者に問い合わせて、セマンティック モデルや関連レポートが最近使われずにセマンティック モデルが定期的に更新される理由を把握します。

ユーザー アクティビティ

ユーザー アクティビティに基づいて実行できるアクションをいくつか次に示します。

• 新しいユーザーによる最初の発行アクション: ユーザーの種類がコンシューマーから作成者に変わったことを特定します。これは、ユーザーがコンテンツを初めて公開した時点で特定できます。 ガイダンスと役に立つリソースへのリンクを提供する標準のメールを送信するのに適した機会です。
• 最も頻度の高いコンテンツ作成者とのエンゲージメント: 最もアクティブなクリエイターを、チャンピオン ネットワークや実践共同体に参加するよう招待します。
• ライセンス管理: アクティブでない作成者に Pro または PPU ライセンスがまだ必要かどうかを確認します。
• ユーザー試用版のアクティブ化: 試用版ライセンスのアクティブ化をきっかけに、試用が終了する前に、ユーザーに永続的なライセンスを割り当てることができます。

ユーザー トレーニングの機会

監査データからわかるユーザー トレーニングの機会をいくつか次に示します。

• 同じコンテンツ作成者による多数のセマンティック モデルの発行: 共有セマンティック モデルについて、および重複するセマンティック モデルを作成しないようにすることが重要な理由について、ユーザーに説明します。
• 個人のワークスペースからの過剰な共有: 個人のワークスペースから多くの共有を行っているユーザーに問い合わせます。 標準ワークスペースについて説明します。
• 個人のワークスペースからの大量のレポート ビュー: レポート ビューの数が多いコンテンツを所有しているユーザーに問い合わせます。 個人のワークスペースより標準ワークスペースの方がどのように優れているかを説明します。

ヒント

また、社内の Power BI コミュニティが回答した質問と、ヘルプ デスクに送られた問題を確認することで、トレーニング コンテンツやドキュメントを改善することもできます。

セキュリティ

アクティブに監視することが必要になる場合があるセキュリティ状況をいくつか次に示します。

• 高い特権を持つ Fabric 管理者ロールに割り当てられているユーザーが多すぎる。
• ワークスペース管理者が多すぎる (メンバー、共同作成者、または視聴者ワークスペース ロールで十分な場合)。
• セマンティック モデルに割り当てられた過剰なビルド アクセス許可 (読み取りアクセス許可で十分な場合)。
• アイテムごとのアクセス許可の高い使用 (Power BI アプリのアクセス許可またはワークスペース視聴者ロールの方がコンテンツ コンシューマーに適している場合)。
• 外部ユーザーとコンテンツを共有する方法。

詳しくは、セキュリティ計画に関する記事をご覧ください。

ガバナンスとリスク軽減

次のような状況が発生する可能性があります。 迅速に対応できるよう、監査レポートでこれらの種類の状況を特に調べることを検討します。

• 承認されていないレポート (および基になるセマンティック モデル) のビューの数が多い。
• 不明なデータ ソースまたは承認されていないデータ ソースの大量の使用。
• ソース ファイルを配置する必要がある場所に関するガバナンス ガイドラインと一致しないファイルの場所。
• ワークスペース名がガバナンス要件と一致していない。
• 秘密度ラベルが情報保護に使われている。
• 一貫したデータ更新エラー。
• 印刷の大量で反復的な使用。
• サブスクリプションの予期しない、または過剰な使用。
• 個人用ゲートウェイの予期しない使用。

各状況で実行する具体的なアクションは、ガバナンス ポリシーによって異なります。 詳しくは、Fabric 導入ロードマップのガバナンスに関する記事をご覧ください。

チェックリスト - 監査データに基づいて可能性のあるアクションを計画するときの主な決定事項とアクションは次のとおりです。

• 予想されることを明確にする: 予想されるアクションについて、一連の予想されることが明確に示された監査レポートを作成します。
• アクションの責任者を明確にする: ロールと責任が割り当てられていることを確認します。
• 自動化を作成する: 可能であれば、反復可能な既知のアクションを自動化します。
• 追跡システムを使う: システムを使って、行われた連絡、次の計画されたアクション、責任者、解決、状態など、観察された状況を追跡します。

フェーズ 4: 保守、拡張、監視

テナント レベルの監査ソリューションの計画と実装の 4 番目のフェーズの重点は、保守、拡張、監視です。 この時点では、監査ソリューションが運用環境で使われています。 現在は、ソリューションの保守、拡張、監視に主に関心があります。

運用化と改善

監査プロセスは、通常、最初の開発とテストが完了し、プロセスが自動化されると、"運用環境" で実行することが想定されています。 運用環境で実行される自動監査プロセスには、(手動プロセスより) いっそう高い品質、信頼性、安定性、サポートが期待されます。

運用レベルの監査プロセスは "運用化" されています。 運用化されたソリューションには、一般に次のような多くの特性が含まれます。

• 安全: 資格情報が安全に保管および管理されています。 スクリプトには、プレーンテキストのパスワードやキーは含まれません。
• スケジューリング: 信頼性の高いスケジューリング システムが使用されています。
• 変更管理: 運用環境が確実に保護されるように、変更管理プラクティスと複数の環境が使用されます。 また、開発環境とテスト環境、または開発環境だけを使用することもあります。
• サポート: ソリューションをサポートするチームが明確に定義されています。 チーム メンバーはトレーニングを受け、運用で期待されることを理解しています。 バックアップ メンバーが特定されており、必要に応じてクロストレーニングが行われます。
• アラート: 問題が発生すると、アラートによってサポート チームに自動的に通知されます。 可能であれば、アラートに (メールだけでなく) ログとメールの両方を含めます。 ログは、ログに記録されたエラーと警告を分析するのに役立ちます。
• ログ: 監査データが更新された日時の履歴が残るよう、プロセスがログに記録されます。 ログされる情報では、開始日時、終了日時、プロセスを実行したユーザーまたはアプリの ID を記録する必要があります。
• エラー処理: スクリプトとプロセスにより、エラーを適切に処理してログに記録します (すぐに終了する、継続する、または待ってやり直す、など)。 エラーが発生すると、アラート通知がサポート チームに送信されます。
• コーディング標準: パフォーマンスがよい適切なコーディング手法を使います。 たとえば、ループは、必要な場合を除き、意識して避けるようにします。 ソリューションの保守とサポートが容易になるように、一貫したコーディング標準、コメント、書式設定、構文を使います。
• 再利用とモジュール化: 重複を最小限に抑えるため、コードと構成の値 (通知の接続文字列やメール アドレスなど) を他のスクリプトやプロセスで再利用できるようにモジュール化します。

ヒント

上で示したすべてのことを一度に行う必要はありません。 経験を積みながら、ソリューションが完全で堅牢になるように、ソリューションを段階的に改善できます。 オンラインで見つかるほとんどの例は、運用品質ではない可能性がある単純な 1 回限りのスクリプト スニペットであることに注意してください。

チェックリスト - 監査ソリューションの運用化と改善を計画するときの主な決定事項とアクションは次のとおりです。

• 既存のソリューションのレベルを評価する: 自動化されている既存の監査ソリューションを改善および安定化する機会があるかどうかを判断します。
• 運用レベルの標準を確立する: 自動監査プロセスに必要な標準を決めます。 時間をかけて追加できる現実的な改善を考慮します。
• 改善に関する計画を作成する: 運用向け監査ソリューションの品質と安定性の向上を計画します。
• 別の開発環境が必要かどうかを判断する: 運用データに対するリスクと依存のレベルを評価します。 開発と運用 (およびテスト) に個別の環境を作成するタイミングを決定します。
• データ保持戦略を検討する: 一定期間後に、または要求に応じて、データを消去するデータ保持プロセスを実装する必要があるかどうかを判断します。

ドキュメントとサポート

運用レベルのソリューションでは、ドキュメントとサポートが重要です。 対象ユーザーと目的に応じて、複数の種類のドキュメントを作成しておくと便利です。

技術ドキュメント

技術ドキュメントは、ソリューションを構築し、時間をかけて少しずつソリューションを改善および拡張する、技術チームを対象にします。 また、サポート チームにとっても役に立つリソースです。

技術ドキュメントには、次のものを含める必要があります。

• アーキテクチャのコンポーネントと前提条件の概要。
• ソリューションを所有および管理しているユーザー。
• ソリューションをサポートしているユーザー。
• アーキテクチャ ダイアグラム。
• 目標、特定の技術的選択が行われた理由、制約 (コストやスキルなど) などの、設計に関する決定。
• セキュリティに関する決定と選択。
• 使われている名前付け規則。
• コーディングと技術に関する標準とガイドライン。
• 変更管理の要件。
• デプロイ、セットアップ、インストールの手順。
• 既知の技術的負債の領域 (行う機会がある場合に改善できる領域)。

サポート ドキュメント

監査ソリューションの重要性のレベルによっては、緊急の問題が発生したときのためのヘルプ デスクまたはサポート チームが設けられている場合があります。 これらは、毎日、一日中利用できる場合があります。

サポート ドキュメントは、"ナレッジ ベース" または Runbook と呼ばれることもあります。 このドキュメントの対象はヘルプ デスクまたはサポート チームであり、次のものが含まれている必要があります。

• 問題が発生したときのためのトラブルシューティング ガイダンス。 たとえば、データ更新エラーが発生した場合。
• 継続的に実行するアクション。 たとえば、問題が解決されるまで、定期的に行う必要がある手動手順が存在する可能性があります。

コンテンツ作成者ドキュメント

組織全体の他のチームに使用状況と導入の分析を提供することで、監査ソリューションからいっそう多くの価値を得られます (必要に応じて、行レベルのセキュリティを適用します)。

コンテンツ作成者ドキュメントの対象は、キュレーションされた監査データをソースとするレポートとデータ モデルを作成するセルフサービスのコンテンツ作成者です。 これには、共通のデータ定義など、データ モデルに関する情報が含まれます。

チェックリスト - 監査ソリューションのドキュメントとサポートを計画するときの主な決定事項とアクションは次のとおりです。

• ソリューションをサポートする必要があるユーザーを確認する: 運用レベルと考えられる (または下流のレポートに依存関係がある) 監査ソリューションをサポートするユーザーを決めます。
• サポート チームの準備状況を確認する: サポート チームが監査ソリューションをサポートできる状態であることを確認します。 準備状況に対処が必要なギャップがあるかどうかを確認します。
• クロストレーニングを手配する: サポート チームの知識移転セッションまたはクロストレーニング セッションを実施します。
• サポート チームに期待されることを明確にする: 対応と解決に関して期待されることが明確に文書化され、伝達されていることを確認します。 監査ソリューションに関連する問題を迅速に解決するため、オンコール要員が必要かどうかを決定します。
• 技術ドキュメントを作成する: 技術的なアーキテクチャと設計上の決定に関するドキュメントを作成します。
• サポート ドキュメントを作成する: ヘルプ デスクのナレッジ ベースを更新して、ソリューションのサポート方法に関する情報を含めます。
• コンテンツ作成者向けのドキュメントを作成する: セルフサービス作成者がデータ モデルを使用するのに役立つドキュメントを作成します。 共通のデータ定義を記述して、使用の一貫性を向上させます。

アラートの有効化

監査データの特定の条件に基づいてアラートを生成することが必要な場合があります。 たとえば、誰かがゲートウェイを削除したとき、または Power BI 管理者がテナントの設定を変更したときに、アラートを発生させることができます。

詳しくは、テナント レベルの監視に関する記事をご覧ください。

継続的な管理

監査ソリューション全体の継続的な管理を実行する必要があります。 次のときは、監査ソリューションの拡張または変更が必要な場合があります。

• 組織で新しいデータ要件が見つかった。
• Power BI REST API から抽出された生データで、新しい監査イベントが示されていた。
• Microsoft が Power BI REST API を変更した。
• 従業員が、ソリューションを改善する方法を見つけた。

重要

破壊的変更はまれですが、発生する可能性があります。 必要に応じて、問題のトラブルシューティングを速やかに行ったり、監査ソリューションを更新したりできるユーザーを確保しておくことが重要です。

チェックリスト - 監査ソリューションの継続的な管理を計画するときの主な決定事項とアクションは次のとおりです。

• 技術の所有者を割り当てる: 監査ソリューション全体に関する所有権と責任を明確にしておきます。
• バックアップが存在することを確認する: サポートで解決できない緊急の問題が発生した場合に関与できるバックアップの技術所有者がいることを確認します。
• 追跡システムを維持する: 新しい要求を把握する方法と、当座の優先順位および短期、中期、長期 (バックログ) の優先順位を決める方法があることを確認します。

関連するコンテンツ

このシリーズの次の記事では、テナント レベルの監視について説明します。