2026年5月14日に更新された公式情報で押さえるべき結論は、Microsoft SentinelのデータをPower BIレポート化する手順は、KQLクエリをPower BI用のMクエリとしてエクスポートし、Power BI Desktopで読み込み、Power BIサービスやTeamsで共有する流れだという点です。同時に、Microsoft SentinelはMicrosoft Defenderポータルへの移行が前提になっており、管理者はポータル移行、権限、更新スケジュール、共有範囲をセットで確認する必要があります。(Microsoft Learn)
特に重要なのは、Power BIレポートを共有すると、Microsoft Sentinelへのアクセス権を持たないユーザーにもセキュリティデータを見せられる点です。これはアプリ所有者や管理職への報告には便利ですが、共有設定を誤るとサインイン失敗、アプリ名、検知傾向などの機密性が高い情報を広げてしまう可能性があります。(Microsoft Learn)
Microsoft Defenderの「Create a Power BI report from Microsoft Sentinel data」で確認すべき要点
「Create a Power BI report from Microsoft Sentinel data」は、Microsoft SentinelのログデータをPower BIで可視化するための公式手順です。Microsoft SentinelはLog Analyticsワークスペース上で動作し、Kusto Query Language、つまりKQLでデータを検索します。そのクエリをPower BI用のMクエリとして出力し、Power BI Desktopでレポート化するのが基本です。(Microsoft Learn)
この手順でできることは、単にグラフを作ることではありません。SOC担当者だけが見ていたMicrosoft Sentinelの情報を、Power BIサービスやMicrosoft Teamsを通じて、アプリ担当者、システム管理者、マネージャーなどに見せられるようになります。公式手順でも、Power BIサービスでアクセスを許可されたユーザーやTeamsチャネルのメンバーは、Microsoft Sentinel権限がなくてもレポートを閲覧できると説明されています。(Microsoft Learn)
実務では、次のような用途に向いています。
| 活用シーン | Power BI化するメリット | 注意点 |
|---|---|---|
| アプリ別のサインイン失敗状況を共有する | アプリ所有者が自分の担当アプリの傾向を把握しやすい | ユーザー名やIPなどを出しすぎない |
| 経営層・管理職向けに月次報告する | Sentinel画面を見せずに要約指標を共有できる | 技術詳細より傾向・リスク・対応状況を重視する |
| SOCの定例レビューに使う | 検知件数、失敗率、上位アプリなどを視覚化できる | リアルタイム監視用途には向かない |
| Teamsチャネルで運用チームに共有する | チームの通常業務画面から確認できる | Teamsメンバー全員に見せてよい内容か確認する |
何が変わるのか：Power BI手順だけでなくDefenderポータル移行が前提になる
今回の確認ポイントは、Power BIレポート作成の手順そのものよりも、Microsoft SentinelをMicrosoft Defenderポータルで使う前提が強まっていることです。Microsoft SentinelはMicrosoft Defenderポータルで一般提供されており、Microsoft Defender XDRやE5ライセンスがない顧客でもDefenderポータル上でSentinelを利用できます。(Microsoft Learn)
さらに、2027年3月31日以降、Microsoft SentinelはAzureポータルではサポートされず、Microsoft Defenderポータルのみで利用する形になります。AzureポータルでMicrosoft Sentinelを使っている環境は、Defenderポータルへの移行計画を早めに立てる必要があります。(Microsoft Learn)
ただし、Power BIレポートを今すぐすべて作り直す必要がある、という意味ではありません。Microsoft SentinelとMicrosoft Defenderの統合後も、データ収集の基本構造やLog Analytics側の取り込みパイプライン、データスキーマは維持されると説明されています。影響が出やすいのは、ポータルの操作場所、権限設計、インシデント・アラートの扱い、共有・更新の運用です。(Microsoft Learn)
| 変更・確認ポイント | 実務上の意味 | 管理者が確認すべきこと |
|---|---|---|
| Microsoft Sentinelの利用場所がDefenderポータルへ移行 | Azureポータル前提の手順書や教育資料が古くなる | 社内手順書の画面名、URL、操作導線を見直す |
| KQLクエリをPower BI用Mクエリとしてエクスポート | Power BI DesktopでSentinelデータを読み込める | クエリの集計粒度と対象期間を確認する |
| Sentinel権限なしのユーザーにもPower BIで共有可能 | アプリ担当者や管理職に展開しやすい | Power BIワークスペースとTeamsの閲覧者を棚卸しする |
| スケジュール更新には資格情報が必要 | 更新が止まると古いセキュリティ状況を見せることになる | 読み取り権限を持つアカウントで認証し、更新失敗を監視する |
| Defenderポータルでは一部機能の場所や挙動が変わる | アラート相関、インシデント名、Automationの条件に影響する | 既存の検知・自動化・API連携をテストする |
対象者：誰が影響を受けるのか
この更新は、Microsoft DefenderやMicrosoft Sentinelを直接操作するSOC担当者だけでなく、Power BIでレポートを作る担当者や、Teamsで共有されるレポートを見る業務部門にも関係します。
セキュリティ管理者・SOC担当者
セキュリティ管理者は、Microsoft SentinelのログをどこまでPower BIに出すかを決める立場です。サインイン失敗数、アプリ別の認証傾向、検知数の推移などは共有しやすい指標ですが、生ログ、ユーザー識別子、IPアドレス、端末名、検知詳細をそのまま出すと、閲覧者の範囲によっては過剰共有になります。
SOC担当者は、Power BIを「監視コンソールの代替」としてではなく、「関係者に状況を伝えるレポート基盤」として使うのが現実的です。即時対応が必要なインシデント処理はDefenderポータルやSentinelの機能で行い、Power BIでは傾向分析、月次報告、アプリ別レビューに絞ると運用しやすくなります。
Power BI担当者・データ分析担当者
Power BI担当者は、KQLから出力されたMクエリをPower BI Desktopに貼り付け、可視化を作成します。公式手順では、Microsoft SentinelからエクスポートしたPowerBIQuery.txtの内容をPower Query EditorのAdvanced Editorに貼り付けてデータを取得します。(Microsoft Learn)
この担当者が注意すべきなのは、Power BI側で見た目の良いグラフを作るだけでなく、クエリの意味を理解することです。たとえば「Failed」という列が失敗件数なのか、失敗率なのか、対象期間が7日なのか30日なのかを明確にしないと、管理職が誤った判断をする原因になります。
開発者・自動化担当者
開発者や自動化担当者は、Power BI連携そのものに加えて、Defenderポータル移行後のAPIやインシデント連携の変化を確認する必要があります。公式情報では、統合インシデントやアラートを扱う場合はMicrosoft Graph REST APIの利用が推奨され、Microsoft Sentinel APIは分析ルールやAutomationルールなどSentinelリソース向けに引き続き使われると説明されています。(Microsoft Learn)
既存のServiceNow、Jira、Logic Apps、独自チケットシステムと連携している場合は、Power BIレポートだけでなく、インシデントURL、ステータス、タイトル、更新者などを参照している処理も確認してください。Defenderポータルへの移行では、インシデント名が相関処理によって変わる可能性があり、タイトルをAutomationルールの条件に使う運用は避けるべきです。(Microsoft Learn)
Power BIレポート作成に必要な前提条件
公式手順では、Microsoft Sentinelワークスペースへの少なくとも読み取りアクセス、Microsoft Sentinelワークスペースを読めるPower BIアカウント、Microsoft StoreからインストールしたPower BI Desktopが前提条件として示されています。(Microsoft Learn)
Log Analytics側からPower BIへクエリをエクスポートする場合、ワークスペースに対するMicrosoft.OperationalInsights/workspaces/query/*/read権限が必要です。たとえばLog Analytics Reader組み込みロールが該当します。(Microsoft Learn)
| 必要なもの | 目的 | 確認ポイント |
|---|---|---|
| Microsoft Sentinelワークスペースの読み取り権限 | KQLでログを検索する | 対象ワークスペースを読み取れるか |
| Power BIアカウント | Desktopでサインインし、サービスへ発行する | 組織のPower BI利用ポリシーに合っているか |
| Power BI Desktop | Mクエリを読み込み、レポートを作成する | Microsoft Store版を利用できるか |
| Power BIワークスペース | レポートを共有・管理する | Admin、Member、Contributor、Viewerの役割を適切に割り当てる |
| 更新用の資格情報 | スケジュール更新でLog Analyticsからデータを取得する | 個人退職・異動で更新が止まらない設計にする |
| Teamsチャネル | レポートをチームに共有する | チャネルメンバーに見せてよいデータか確認する |
Power BIの高度な共有、スケジュール更新、データフロー、増分更新などは、Power BI ProまたはPremiumが必要になる場合があります。ライセンス要件はテナントの契約や機能によって変わるため、導入前に組織のPower BI管理者に確認してください。(Microsoft Learn)
Microsoft SentinelデータからPower BIレポートを作成する基本手順
ここでは、公式手順の流れを実務向けに整理します。ポイントは、最初に「誰に何を見せるのか」を決めてからKQLを書くことです。KQLを先に作ると、技術者には便利でも、閲覧者にとって意味の分かりにくいレポートになりがちです。
レポートの目的と閲覧者を決める
最初に、レポートの利用目的を1つに絞ります。
たとえば、アプリ所有者に見せるなら「アプリ別のサインイン失敗状況」、管理職に見せるなら「週次・月次の傾向」、SOC向けなら「失敗率が急増したアプリや対象」を中心にします。
閲覧者がMicrosoft Sentinelを使わない人であれば、KQLや検知ルール名をそのまま出すよりも、次のような表現に変換すると伝わりやすくなります。
| 技術者向けの表現 | 閲覧者向けの表現 |
|---|---|
SigninLogs | サインイン履歴 |
ResultType != 0 | サインイン失敗 |
AppDisplayName | 対象アプリ |
countif() | 条件に一致した件数 |
TimeGenerated > ago(7d) | 直近7日間 |
Microsoft SentinelでKQLクエリを作成する
Microsoft SentinelでLogsを開き、Power BI化したいデータをKQLで検索します。Defenderポータルにオンボード済みのワークスペースでは、Microsoft SentinelのGeneralからLogsを選択する手順が示されています。(Microsoft Learn)
公式例では、直近7日間のサインインログから、アプリ別に試行回数、失敗件数、成功件数を集計し、失敗件数の多いアプリを抽出しています。(Microsoft Learn)
SigninLogs
| where TimeGenerated > ago(7d)
| summarize Attempts = count(), Failed=countif(ResultType !=0), Succeeded = countif(ResultType ==0) by AppDisplayName
| top 10 by Failed
| sort by Failedこのクエリは学習用として分かりやすい例ですが、本番レポートではそのまま使う前に調整してください。たとえば、対象期間をago(30d)にする、特定アプリだけに絞る、失敗率を計算しやすいように列を追加する、といった調整が考えられます。
Power BI用のMクエリとしてエクスポートする
クエリを実行して期待した結果が出ることを確認したら、Exportから「Export to Power BI (M query)」を選びます。出力されるテキストファイルはPowerBIQuery.txtです。(Microsoft Learn)
ここで重要なのは、Power BIに渡す前にKQLの結果を小さく、意味のある形に整えることです。Power BI側で何でも加工しようとすると、データ量が増え、更新時間や権限管理が複雑になります。
おすすめは、Sentinel側のKQLで次の処理を済ませておくことです。
- 期間を明示する
- 必要な列だけを残す
- アプリ、ユーザー種別、検知カテゴリなどで集計する
- 個人情報や機微情報を不要に出さない
- レポート閲覧者に不要な詳細ログを渡さない
Power BI DesktopでMクエリを読み込む
Power BI Desktopを開き、Microsoft Sentinelワークスペースへの読み取り権限を持つPower BIアカウントでサインインします。Get dataからBlank queryを選び、Power Query EditorのAdvanced EditorにPowerBIQuery.txtの内容を貼り付けます。(Microsoft Learn)
読み込んだクエリには、用途が分かる名前を付けます。公式手順ではApp_signin_statsという名前に変更する例が示されています。(Microsoft Learn)
実務では、次のような命名にすると運用しやすくなります。
| 悪い例 | 良い例 |
|---|---|
| Query1 | AppSigninStats_7days |
| Test | FailedSigninByApp_Monthly |
| SentinelData | SentinelSigninSummary_Prod |
| ReportData | AuthFailureSummary_ForAppOwners |
可視化を作成する
公式手順では、テーブル、円グラフ、積み上げ縦棒グラフ、Quick measureを使った失敗率の表示が紹介されています。FailedをAttemptsで割ることで、アプリごとのサインイン失敗率を見せることができます。(Microsoft Learn)
ただし、セキュリティレポートでは見栄えよりも誤解を防ぐことが重要です。たとえば、失敗件数が多いアプリが必ず危険とは限りません。利用者数が多いアプリは、自然に失敗件数も増えます。そのため、件数だけでなく失敗率、前週比、対象ユーザー数も併せて見ると判断しやすくなります。
| 指標 | 見えること | 注意点 |
|---|---|---|
| 失敗件数 | どのアプリで失敗が多いか | 利用者数が多いアプリほど増えやすい |
| 失敗率 | 試行回数に対して失敗が多いか | 試行回数が少ない場合は極端な値になりやすい |
| 成功件数 | 通常利用の規模 | 成功件数だけでは攻撃傾向は分からない |
| 前週比 | 急増・急減の有無 | 祝日やメンテナンスの影響を考慮する |
| アプリ別ランキング | 優先確認すべき対象 | 上位だけを見ると小規模アプリの異常を見落とす |
Power BIサービスへ発行し、ワークスペースで共有する
Power BI Desktopでレポートを作成したら、Power BIサービスのワークスペースへ発行します。公式手順では、Power BIサービスでワークスペースを作成し、ユーザーやグループにAdmin、Member、Contributor、Viewerのロールを割り当てる流れが説明されています。(Microsoft Learn)
共有先は、個人単位よりグループ単位で管理するのが基本です。たとえば、アプリ担当者向けのレポートなら「AppOwners-SecurityReport-Viewers」のようなグループを作り、Power BIワークスペースではViewerとして付与します。
避けたいのは、Power BIワークスペースに広い権限を与えすぎることです。Viewerで足りる閲覧者にMemberやContributorを付けると、レポートやデータセットの変更、再共有、管理上の混乱につながります。
Teamsチャネルにレポートを追加する
公式手順では、TeamsチャネルにPower BIタブを追加し、作成したレポートを選択して保存することで、チャネル内からレポートを閲覧できると説明されています。(Microsoft Learn)
Teams共有では、Power BI側の権限とTeams側のメンバーがずれていないかを必ず確認してください。Teamsチャネルに追加しただけで、すべての閲覧権限問題が解決するわけではありません。Power BIレポートのアクセス権、ワークスペースのロール、Teamsのメンバー範囲をそろえる必要があります。
スケジュール更新で確認すべき設定
Power BIレポートは、作成して終わりではありません。セキュリティ状況を継続的に見せるには、Power BIサービス側でスケジュール更新を設定します。公式手順では、Power BIサービスでデータセットのSettingsを開き、Log Analyticsワークスペースを読み取れるアカウントの資格情報を設定し、Scheduled refreshを有効にする流れが示されています。(Microsoft Learn)
スケジュール更新で失敗しやすいポイントは、次の3つです。
| 失敗しやすいポイント | 起きる問題 | 対策 |
|---|---|---|
| 個人アカウントで認証している | 異動・退職・パスワード変更で更新が止まる | 組織のポリシーに沿った運用アカウントを検討する |
| クエリが重すぎる | 更新に時間がかかる、失敗する | KQL側で期間・列・集計を絞る |
| 共有範囲を確認していない | 機密情報を広く見せてしまう | Power BI、Teams、Microsoft Entra IDグループを棚卸しする |
また、Log AnalyticsからPower BIへエクスポートする処理はQuery APIの制限を受け、クエリ結果が上限を超えると部分的な結果だけがエクスポートされる可能性があります。大規模環境では、日次・週次の集計にする、アプリやテナント単位で分ける、Power BI Dataflowsを使うなど、データ量を抑える設計が必要です。(Microsoft Learn)
Defenderポータル移行で管理者が確認すべき注意点
Microsoft SentinelのDefenderポータル移行では、Power BIレポートそのものよりも、その裏側にあるデータ取得、インシデント管理、アラート相関、自動化の運用に影響が出ることがあります。
Azureポータル前提の手順書を見直す
2027年3月31日以降はMicrosoft SentinelがAzureポータルでサポートされなくなるため、社内手順書に「Azure portalでSentinelを開く」「Logsを選ぶ」といった記載がある場合は、Defenderポータル前提の手順に更新する必要があります。(Microsoft Learn)
特にPower BIレポート作成手順では、次の箇所を見直してください。
| 見直す対象 | 確認内容 |
|---|---|
| 画面キャプチャ | Defenderポータルの画面に差し替える |
| 操作パス | Logs、Advanced hunting、Microsoft Sentinelメニューの場所を確認する |
| 社内研修資料 | Azureポータル前提の説明を減らす |
| 運用チェックリスト | Power BI発行、Teams共有、更新設定を追加する |
| 権限申請フロー | Sentinel、Log Analytics、Power BIの権限を分けて整理する |
データコネクタの表示と実体を混同しない
Defenderポータルへオンボードした後、一部のデータコネクタはDefenderポータルのData connectorsページには表示されません。ただし、統合セキュリティ運用で使われるコネクタとして動作し、Azureポータル側のMicrosoft Sentinelでは引き続き一覧に表示されるものがあります。(Microsoft Learn)
管理者が注意すべきなのは、「Defenderポータルで見えないから接続されていない」と早合点しないことです。Power BIレポートのデータが急に変わった場合は、コネクタの表示有無だけでなく、Log Analyticsワークスペースに対象テーブルのデータが入っているか、KQLの結果が変わっていないかを確認してください。
アラート相関とインシデントの扱いを確認する
Defenderポータルでは、Microsoft Sentinelの分析ルールは引き続き作成・更新・管理できますが、アラート相関やインシデント統合はDefender XDR側のエンジンが大きな役割を持ちます。Microsoft Sentinelのアラートのみを生成し、インシデント作成をオフにしている分析ルールのアラートは、Defenderポータルでは表示されないと説明されています。(Microsoft Learn)
Power BIレポートがインシデントやアラートを集計している場合、この違いは重要です。単純なログ集計レポートであれば影響は小さいことが多い一方、インシデント件数、アラート件数、検知ルール別件数をレポートしている場合は、移行前後で数値の意味が変わる可能性があります。
AutomationルールとPlaybookの条件を見直す
Defenderポータルへの移行では、AutomationルールやPlaybookにも注意が必要です。公式情報では、Microsoft DefenderインシデントがMicrosoft Sentinelに表示されるまで最大5分程度かかる場合があり、その場合はPlaybookのトリガーにも遅延が出ると説明されています。また、Defenderポータル側でインシデント作成・更新後にAutomationルールが実行されるまで最大10分程度かかる可能性も示されています。(Microsoft Learn)
Power BIレポートで「自動対応済み件数」や「チケット作成状況」を見せている場合、短い時間幅での集計にはズレが出る可能性があります。リアルタイム性を求める指標はDefenderポータル側で確認し、Power BIでは日次・週次の集計に寄せると誤解を減らせます。
データ保存・プライバシーの適用ポリシーを確認する
Microsoft SentinelをAzureポータルで使う場合とDefenderポータルで使う場合では、データ保存、処理、保持、共有に関する適用ポリシーの考え方が変わります。公式情報では、Azureポータル利用時はMicrosoft Sentinelのポリシー、Defenderポータル利用時はMicrosoft Defender XDRのポリシーが適用されると説明されています。(Microsoft Learn)
Power BIで外部部門に共有するレポートは、セキュリティログの二次利用にあたります。社内の情報管理基準、監査要件、データ保持ルールに照らして、どの列を出すか、何日分を保持するか、誰が閲覧できるかを明文化しておくことが重要です。
Power BIレポート設計で失敗しないための判断基準
Microsoft SentinelデータをPower BIで見せるときは、「出せるデータ」ではなく「判断に使えるデータ」を選ぶことが重要です。ログをそのまま表にすると、閲覧者は何を見ればよいか分からなくなります。
生ログではなく集計データを基本にする
Power BIレポートは、詳細調査よりも報告・共有に向いています。したがって、次のような集計を基本にします。
| レポート目的 | 推奨する集計 |
|---|---|
| アプリ担当者への通知 | アプリ別の失敗件数、失敗率、前週比 |
| 管理職向け報告 | 月次の傾向、重大度別件数、対応状況 |
| SOC改善 | 誤検知が多いルール、対応時間、再発傾向 |
| ID管理改善 | MFA失敗、条件付きアクセス関連、特定ユーザー群の傾向 |
詳細調査が必要な場合は、Power BIから結論を出すのではなく、DefenderポータルやMicrosoft Sentinelで追加調査する流れにします。
閲覧者ごとに見せる粒度を変える
同じMicrosoft Sentinelデータでも、閲覧者によって必要な粒度は違います。管理職には「傾向と対応状況」、アプリ所有者には「自分の担当アプリの状況」、SOCには「調査につながる詳細」が必要です。
| 閲覧者 | 見せるべき情報 | 出しすぎに注意する情報 |
|---|---|---|
| 経営層・管理職 | 傾向、リスク、対応状況 | 個別ユーザー名、IPアドレス |
| アプリ所有者 | 担当アプリの失敗件数・失敗率 | 他部門アプリの詳細 |
| ヘルプデスク | 問い合わせ対応に必要な概要 | 攻撃手法や詳細な検知ロジック |
| SOC担当者 | 詳細な検知・調査情報 | Power BIだけで完結する設計 |
「失敗件数が多い＝危険」と短絡しない
サインイン失敗レポートでよくある誤解は、失敗件数の多いアプリをそのまま危険なアプリと判断してしまうことです。利用者数が多いアプリ、認証試行が多いアプリ、定期的なバッチ処理があるアプリは、失敗件数も増えやすくなります。
実務では、少なくとも次の3つを並べて見ます。
| 指標 | 判断に使う理由 |
|---|---|
| 失敗件数 | 影響範囲や問い合わせ増加の可能性を把握する |
| 失敗率 | 試行回数に対して異常に失敗が多いかを見る |
| 前週比・前月比 | 急な変化があるかを見る |
この3つを組み合わせると、「件数は多いが通常範囲内」「件数は少ないが失敗率が急増している」といった判断ができます。
開発者・運用担当者向けの移行チェックリスト
Defenderポータル移行とPower BI展開を同時に進める場合は、以下の順で確認すると抜け漏れを減らせます。
| チェック項目 | 確認内容 |
|---|---|
| クエリ | KQLがDefenderポータル移行後も期待どおり実行できるか |
| テーブル | SigninLogsなど参照テーブルにデータが継続して入っているか |
| 権限 | Log Analytics、Sentinel、Power BIの読み取り権限が適切か |
| Mクエリ | PowerBIQuery.txt由来の接続先が正しいワークスペースを参照しているか |
| 更新 | Power BIサービスでスケジュール更新が成功するか |
| 共有 | Power BIワークスペースとTeamsチャネルの閲覧者が一致しているか |
| データ量 | Query API制限や更新時間に引っかからないか |
| 自動化 | Automationルール、Playbook、チケット連携の条件が移行後も有効か |
| インシデント集計 | Defender XDRの相関・統合により件数の意味が変わっていないか |
| 手順書 | Azureポータル前提の記載をDefenderポータル前提に直したか |
特に、既存のレポートを流用する場合は「画面が変わるだけ」と考えない方が安全です。ログ集計は継続していても、インシデントやアラートを扱うレポートでは、Defenderポータル側の相関・統合の影響を受ける可能性があります。
Power BIとWorkbookはどう使い分けるべきか
Microsoft SentinelにはWorkbookによる可視化もあります。Defenderポータル移行後も、Azure WorkbooksはDefenderポータル内でデータ可視化と対話の主要ツールとして機能すると説明されています。(Microsoft Learn)
使い分けの目安はシンプルです。
| 用途 | 向いているツール |
|---|---|
| SOC担当者が調査中に使う | Microsoft Sentinel Workbook、Defenderポータル |
| 管理職や業務部門に定期共有する | Power BI |
| Teamsチャネルで状況を共有する | Power BI |
| インシデント対応中の詳細確認 | Defenderポータル |
| 複数部門向けの月次レポート | Power BI |
| Sentinel内の運用ダッシュボード | Workbook |
Power BIは、Microsoft Sentinelを使わない人にも分かりやすく共有するための道具です。一方、WorkbookやDefenderポータルは、セキュリティ担当者が調査・運用するための道具です。この役割を混同しないことが、運用品質を高めるポイントです。
よくある疑問
Microsoft Sentinelの権限がないユーザーでもPower BIレポートを見られるのか
見られます。公式手順では、Power BIサービスでアクセスを許可されたユーザーやTeamsチャネルのメンバーは、Microsoft Sentinelの権限がなくてもレポートを閲覧できると説明されています。(Microsoft Learn)
ただし、これは便利であると同時にリスクでもあります。Microsoft Sentinelへのアクセス権がない人にもセキュリティ情報を見せることになるため、Power BI側の共有範囲を必ず確認してください。
既存のPower BIレポートは作り直しが必要か
すべてを作り直す必要があるとは限りません。Microsoft SentinelとMicrosoft Defenderの統合後も、Log Analyticsを基盤とするデータ取り込みやスキーマは基本的に維持されると説明されています。(Microsoft Learn)
ただし、Azureポータル前提の操作手順、認証情報、インシデント・アラート集計、AutomationやAPI連携を含むレポートは見直しが必要です。
Power BIレポートはリアルタイム監視に使えるのか
リアルタイム監視の主用途には向きません。Power BIのスケジュール更新は便利ですが、更新間隔、資格情報、Query API制限、処理時間の影響を受けます。即時対応が必要なインシデントは、DefenderポータルやMicrosoft Sentinelのインシデント管理で確認すべきです。
Power BIは、傾向分析、週次・月次報告、アプリ所有者向けの共有に使うと効果的です。
Teamsに追加すれば全員が見られるのか
TeamsチャネルにPower BIレポートを追加しても、Power BI側のアクセス権が適切に設定されていなければ閲覧できない場合があります。逆に、Teamsチャネルのメンバーが広すぎると、意図しない人にレポートの存在を見せることになります。
Power BIワークスペースのロール、レポート共有、Teamsメンバーを合わせて確認してください。
まず実施すべきこと
Microsoft Defender環境で「Create a Power BI report from Microsoft Sentinel data」を確認する管理者は、最初に次の3つを進めるのが現実的です。
1つ目は、Microsoft SentinelのPower BI化対象を決めることです。最初から全ログを可視化しようとせず、アプリ別サインイン失敗、月次の検知傾向、対応状況など、共有価値が高いテーマに絞ります。
2つ目は、Defenderポータル移行を前提に手順書と権限を見直すことです。2027年3月31日以降はAzureポータルでMicrosoft Sentinelがサポートされなくなるため、Azureポータル前提の運用は早めに整理する必要があります。(Microsoft Learn)
3つ目は、Power BI共有のガバナンスを決めることです。Microsoft Sentinelの権限がないユーザーにもレポートを見せられるため、便利さだけでなく、誰に、どの粒度で、どの期間のデータを見せるのかを明確にしてください。
Power BIレポート化は、Microsoft Sentinelの価値をSOC外に広げる有効な方法です。ただし、Defenderポータル移行、権限、更新、Teams共有を同時に設計して初めて、安全に運用できます。まずは小さなレポートを1つ作り、KQL、Power BI更新、共有範囲、閲覧者の理解度を検証してから、本番展開へ広げるのが失敗しにくい進め方です。
コメント