JA
English
Deutsch
Español
Français
Italiano
Português
Nederlands
Polski
Bahasa Indonesia
Русский
Українська
العربية
עברית
한국어Microsoft Graphで見落とされがちなM365コンプライアンスの盲点を明らかにする
By Mirko Peters ·
ポッドキャストと関連技術ブログへ、ようこそお戻りくださいました！ Microsoft 365 のコンプライアンス ダッシュボードを既定の状態のまま信頼し、すべてが…と思い込んだことがあるなら…
Automatically translated with AI from the original post. Read the English original
ポッドキャストと関連する技術ブログへようこそ。標準のMicrosoft 365コンプライアンスダッシュボードをそのまま信頼し、すべてが完全に把握できていると考えているなら、それは誤った安心感に陥っているかもしれません。既定のコンプライアンスダッシュボードは要約を示すためのものであり、絶対的な真実を示すものではありません。データ損失防止（DLP）の検出、eDiscoveryのアクション、基盤となるセキュリティアラートといった重要なシグナルは、多くの場合、別途アクセス許可、高度なクエリパラメーター、適切なデータの結合を必要とするMicrosoft Graphのエンドポイントの裏側にあります。このディープダイブでは、標準のレポートで重要な情報が欠けている理由を探り、照会すべきGraphエンドポイントを正確に整理し、その未加工の証拠をMicrosoft Purviewに直接取り込んで、明確で根拠のあるレポートを作成する方法を紹介します。このトピックに関する詳しい議論は、関連するポッドキャストエピソード「Find Missing Microsoft 365 Compliance Data with Graph」でお聴きいただけます。
概要
既定のコンプライアンスダッシュボードは要約であり、真実そのものではありません。重要なシグナル（DLPの検出、eDiscoveryのアクション、セキュリティアラート）は、別のアクセス許可が必要なGraphエンドポイントの裏側にあることが多いのです。本記事では、正確なAPI、スコープ、スクリプトのパターンを整理し、完全な忠実度の証拠を取得して、明確で根拠のあるレポートのためにPurviewへ集約する方法を紹介します。
対象読者
監査に耐えうる証拠を必要とするコンプライアンス、法務、リスク管理の担当者
レポートと自動化を構築するM365およびEntraの管理者
DLP、eDiscovery、アラートのテレメトリを相関分析するセキュリティチーム
見落としの原因（標準ダッシュボードで欠けるもの）
集計と遅延: UIの要約では、入れ子になったインシデントの詳細や最近のアクティビティが省略されます
範囲の欠落: eDiscoveryのアクションやDLPの一致は、標準のエクスポートの対象外になる場合があります
分割されたアクセス許可: /security と /compliance のエンドポイントでは、必要なスコープが異なります
結合の欠如: ダッシュボードでは、インシデントをユーザー、カストディアン、ケースの手順と関連付けることがほとんどありません
利用価値の高いGraphエンドポイント（そのままコピーして使えるリスト）
セキュリティアラート（網羅性）
エンドポイント:
/security/alertsまたは/security/alerts_v2アプリのアクセス許可（例）:
SecurityEvents.Read.All（新しいモデルでは Alerts.Read.All）用途: アラートのタイムライン、重大度、状態、担当者の確認
DLPポリシーとアクティビティ（データ損失）
エンドポイント（テナントによって利用可否が異なります）:
/security/dataLossPreventionPolicies（ポリシーの一覧）/security/dlpIncidents、またはセキュリティ名前空間の高度なDLPインシデントエンドポイント（テナントに依存）
アプリのアクセス許可:
SecurityEvents.Read.All（利用可能な場合は、特定のDLP読み取りスコープと組み合わせて使用）用途: 一致内容、場所（Exchange、SharePoint、Teams）、処理結果
eDiscovery（ケースとアクション）
/compliance/ediscovery/cases子パス:
/custodians、/searches、/reviewSets、/noncustodialDataSources、/operationsアプリのアクセス許可:
eDiscovery.Read.All（ケースを管理する場合は書き込みも）用途: ケースの状態、保持、カストディアン、エクスポート、レビューアーの操作
監査とサインインのコンテキスト（補足的な証拠）
/auditLogs/directoryAudits、/auditLogs/signInsアプリのアクセス許可:
AuditLog.Read.All、Directory.Read.All用途: 誰が、いつ、何を変更したか、セッションのコンテキスト
ヒント: コンプライアンス関連のペイロードは深く入れ子になっていることが多いため、
$expandの使用を検討し、@odata.nextLinkでページングし、表示名や部署を取得するために/users/{id}と結合してください。
認証とアクセス許可（トラブルのない方法）
無人で実行するジョブには、アプリケーションのアクセス許可（サービスプリンシパル）を使用します
組織で権限の分離が求められる場合は、セキュリティ用と基本のGraph用に別々のアプリを登録します
同意は最小特権のスコープだけに限定し、シークレットと証明書は Key Vault に格納してください。
429および503に対して指数バックオフを実装し、ログに
x-ms-request-idを記録します
スクリプトのパターン（PowerShellまたはPython）
Select と Expand: 必要なフィールドだけを
$select=…で要求し、入れ子になったエンティティには$expand=…を使用しますフィルターと時間枠の設定: 差分取得には
$filter=createdDateTime ge {ISO8601}を使用ページング処理:
@odata.nextLinkでループし、結果が 1 ページに収まるとは想定しない正規化: 読みやすい出力にするため、ユーザー ID やオブジェクト ID を事前に名前と部署へ変換する
コンテキストの結合: エクスポート前に、インシデントへユーザー、サイト、チーム、ケースのメタデータを追加する
Purview への組み込み（データを意思決定につなげる）
出力の標準化: フィールド名を統一した CSV/JSON で出力する（tenant、incidentId、workload、userId、userUPN、severity、status、created、lastAction、caseId）
取り込み: Purview が読み取れるセキュアなストレージ（例: ADLS Gen2）にファイルを配置する
タグ付けとラベル付け: ルーティング用に秘密度ラベルまたはカスタムタグ（例: 「DLP-PII-High」）を適用する
ダッシュボード: 傾向、担当者、SLA の経過日数を確認するため、Purview（または Purview のデータを使った Power BI）を利用する
自動化: 繰り返し発生やエスカレーションの際にケース担当者へ通知するルールを設定し、週次の PDF ダイジェストを作成する
30 分パイロット（手順）
0～10 分: アプリの登録、
SecurityEvents.Read.AllとeDiscovery.Read.Allを付与し、シークレットまたは証明書を作成する10～20 分: 1 つのエンドポイント（アラートまたはケース）について、ページング処理と過去 7 日間を対象とした
$filterを使ってスクリプトを作成する20～30 分:
/usersで情報を補完し、CSV にエクスポートして ADLS のパスに配置し、基本的なグラフで可視化する
価値を示す KPI
担当者と処分結果が入力されているインシデントの割合
インシデントからケース（またはレビュー担当者への割り当て）までの平均時間
30 日あたりの繰り返し違反を起こしたアカウントおよび場所の数
標準のダッシュボードの件数との差分（ギャップの解消状況）
監査サイクルの所要時間（証拠準備にかかる時間の削減量）
よくある落とし穴と対処法
結果が空になる → スコープの誤りか、Application が必要な場面で委任（Delegated）を使用している
詳細情報が不足する →
$expandを指定し忘れている、またはネストされたコレクションが解析されていないデータが一部しか取得できない → ページング処理がなく、最初のページしか取得されていない
名前が一致しない →
/usersや人事データとの結合による補完が行われていないダッシュボードが古いまま → 定期実行が設定されていない。ジョブを追加し、失敗時のアラートを設定する
今週すぐに始められるクイックwins
直近 7 日間の
/security/alertsのデータを取得し、ポータルの件数と比較するオープン状態の eDiscovery ケースとカストディアンをエクスポートし、法務部門に確認を依頼する
DLP インシデントの一斉確認を実施して繰り返し発生分にタグを付け、Purview でフォローアップを開始する
週次の証拠パッケージ（CSV と PDF）をコンプライアンス用のメールボックスへ送信するようスケジュールする
よくある質問
開発者である必要はありますか？ いいえ。PowerShell や短い Python スクリプトで十分です。
なぜアプリのアクセス許可が必要なのですか？ /security および /compliance のエンドポイントの多くは、ユーザー操作を伴わない、信頼性の高いアクセスを必要とするためです。
PowerShell のままで対応できますか？ はい。Microsoft Graph PowerShell SDK を使用し、
$top、$filter、$expand、ページング処理を扱ってください。Purview は必須ですか？ 厳密には必須ではありません。ただし、生の JSON を監査可能なワークフローやダッシュボードに変えられます。
まとめ
ダッシュボードは要約を示しますが、Graph は全体像を示します。適切なエンドポイントを取得し、認証を整え、ページング処理と展開を行ったうえで、Purview に集約してください。これにより、チェックボックス型のコンプライアンスから、根拠を示せるリアルタイムの可視化へ移行できます。手作業のエクスポートに追われることもなくなります。これらの死角に直接取り組むための詳しい解説や専門家のヒントについては、専用のポッドキャストエピソード Find Missing Microsoft 365 Compliance Data with Graph もぜひお聴きください。スクリプトの改善を続け、アプリのアクセス許可を安全に管理し、ダッシュボードが見落としてきたデータを表面化させていきましょう。