Microsoft DefenderのDLPアラートをSentinelで調査する更新ポイントと管理者チェックリスト

Microsoft Defender の「Investigate data loss prevention alerts with Microsoft Sentinel」は、Microsoft Purview DLPで発生した情報漏えい対策アラートを、Microsoft Defender XDRとMicrosoft Sentinelの両方で調査しやすくするための実務手順です。結論から言うと、管理者が確認すべき中心は「Microsoft Defender XDRコネクタでDLPインシデントをSentinelへ取り込むこと」と「CloudAppEventsを使って、アラートに紐づく実際のユーザー操作を追跡できる状態にすること」です。Microsoft Learnでは、Defender XDRコネクタでDLPインシデントをSentinelに取り込み、CloudAppEventsを有効化してOffice 365監査ログをSentinelへ取り込む流れが示されています。(Microsoft Learn)

この更新は、単にDLPアラートを「見る場所」が増える話ではありません。SOCがMicrosoft Sentinelで扱うネットワーク、ID、クラウド、エンドポイントのログと、DLPアラートを同じ調査線上で結び付けられるようにする変更です。特にグローバル企業では、国や拠点ごとに異なるデータ保護ルール、監査要件、SOC運用をまたいで、DLPアラートの優先度判断と初動対応を標準化しやすくなります。

まず押さえるべき更新ポイント

今回のポイントは、Microsoft Defender XDRとMicrosoft Sentinelを連携させ、DLPアラートを「単独のコンプライアンス通知」ではなく「セキュリティインシデント調査の一部」として扱えるようにすることです。Microsoft Sentinel側では、Defender XDRコネクタを使ってインシデント、アラート、Advanced Huntingイベントを取り込み、両ポータル間でインシデントを同期できます。すでにMicrosoft SentinelをDefenderポータルへオンボードしている場合、Defender XDRコネクタは自動的に有効化されるため、Azureポータル側で同じ手順を手動実行する必要はありません。(Microsoft Learn)

DLPアラート調査で重要になるのは、アラートそのものだけでなく、その前後にユーザーが何をしたかです。Microsoftの手順では、Sentinelに取り込まれたDLPアラートを起点に、SystemAlertId、AlertType、StartTime、EndTimeを使ってCloudAppEventsテーブルを照合し、アラート発生時間帯のユーザー活動を抽出する方法が示されています。(Microsoft Learn)

確認項目	実務上の意味	管理者が取るべき対応
Defender XDRコネクタ	DLPを含むDefender XDRインシデントをSentinelで扱う入口	Sentinelのデータコネクタ状態を確認する
CloudAppEvents	SharePoint、OneDrive、Exchangeなどのクラウド操作ログを調査に使う	イベント取り込みが有効か、データが流れているか確認する
DLPアラート	Microsoft Purview DLPポリシーに一致した操作を通知する	PurviewでDLPポリシーのアラート設定を確認する
KQL調査	アラートと実際のユーザー操作を紐付ける	SOC向けの標準クエリとして保存する
SOAR連携	Sentinelの自動化ルールやプレイブックで対応を広げる	誤検知時の自動クローズや通知条件を見直す

何が変わるのか：DLPアラート調査の主役が「単発アラート」から「相関インシデント」へ移る

従来のDLP運用では、Microsoft Purview側でポリシー違反を確認し、必要に応じてファイル、メール、ユーザー、デバイスを個別に追う流れになりがちでした。現在のMicrosoft推奨の考え方では、DLPアラートはMicrosoft Defender XDRの統合インシデントキューで管理し、必要に応じてPurviewのDLPダッシュボードやActivity explorer、Content explorerを併用します。Microsoft Learnでも、DLPアラートの調査・管理はMicrosoft Defender XDRダッシュボードが推奨され、DLPポリシーの作成・編集はMicrosoft Purviewポータルが推奨されています。(Microsoft Learn)

このため、運用設計では「誰がDLPポリシーを作るか」と「誰がアラートを調査するか」を分けて考える必要があります。たとえば、情報管理部門がDLPポリシーを作成し、SOCがSentinelで相関分析を行い、法務・人事・内部監査部門が重大案件の判断に参加する、といった分担が現実的です。

観点	以前の運用で起きやすい課題	更新後に意識したい運用
調査範囲	DLPダッシュボードだけを見て判断しがち	SentinelでID、端末、クラウド操作ログと相関する
初動対応	アラートの重要度判断が属人化する	インシデント単位で重大度、所有者、タグを管理する
ログ確認	ユーザー操作の前後関係を手作業で追う	CloudAppEventsとアラートをKQLで結合する
自動化	DLPとSOCのワークフローが分断される	SentinelのSOARで通知、割り当て、抑制を標準化する
グローバル運用	拠点ごとに判断基準がばらつく	ポリシー名、タグ、重大度、対応SLAを統一する

影響範囲：SOC、DLP管理者、Sentinel管理者の全員に関係する

今回の更新で直接影響を受けるのは、Microsoft Defender XDR、Microsoft Sentinel、Microsoft Purview DLPを併用している組織です。特に、Microsoft Sentinelを既存のSIEM基盤として使っているSOCでは、DLPアラートが他の検知ソースと同じインシデント調査フローに入るため、アラート分類、担当者割り当て、プレイブック、KQLクエリの見直しが必要になります。

Microsoft Defender XDRでは、DLPアラートをインシデントキューで確認でき、他のDLPアラートやDefender for Endpoint、Defender for Office 365、Microsoft Sentinelなどのアラートと相関された状態で扱えます。また、Advanced Huntingでコンプライアンスログとセキュリティログを組み合わせて調査し、ユーザー、ファイル、デバイスに対する修復アクションも実行できます。(Microsoft Learn)

影響を受ける担当者を整理すると、次のようになります。

担当者	主な影響	確認すべきこと
SOCアナリスト	Sentinel上でDLPアラートを含むインシデントを調査する	KQL、インシデントタグ、重大度判断、エスカレーション手順
Sentinel管理者	Defender XDRコネクタとCloudAppEventsの取り込みを管理する	コネクタ状態、課金、スキーマ変更、プレイブック影響
DLP管理者	PurviewでDLPポリシーとアラート条件を調整する	アラート量、集約設定、誤検知、ユーザー通知
Microsoft 365管理者	監査ログ、ライセンス、権限を管理する	監査ログ保持、ロール、テナント設定
コンプライアンス担当	重大な情報持ち出しの判断に関与する	証跡、対応履歴、規制要件、承認フロー

必要な設定変更：Defender XDRコネクタとCloudAppEventsを確認する

最初に確認すべき設定は、Microsoft SentinelのMicrosoft Defender XDRコネクタです。AzureポータルでSentinelを使っている場合は、Microsoft Sentinelの「Data connectors」からMicrosoft Defender XDRを選択し、インシデントとアラートの接続を有効化します。Microsoftの手順では、重複インシデントを避けるため、対象製品のMicrosoftインシデント作成ルールを無効化するチェック項目も推奨されています。(Microsoft Learn)

ただし、ここで注意が必要です。Defender XDRコネクタを有効化すると、既存の個別Defender製品コネクタはバックグラウンドで自動的に切断されます。画面上は接続済みに見える場合がありますが、データは流れなくなります。また、スタンドアロンコネクタからXDRコネクタへ置き換えるとアラートのスキーマが変わり、既存のKQL、分析ルール、Workbook、プレイブックに影響する可能性があります。(Microsoft Learn)

設定確認の順序は、次の流れが安全です。

手順	作業内容	確認ポイント
1	PurviewでDLPポリシーのアラート設定を確認	対象ポリシーでアラートが生成される設定になっているか
2	SentinelでMicrosoft Defender XDRコネクタを確認	インシデントとアラートが接続済みか
3	CloudAppEventsの取り込みを確認	DLP調査に必要なクラウド操作ログが流れているか
4	テスト用DLPイベントを発生させる	実データではなく検証用ファイルで確認する
5	SentinelでDLPインシデントを開く	インシデント、アラート、エンティティが表示されるか
6	KQLでユーザー操作を追跡する	アラート時間帯の操作履歴を抽出できるか
7	自動化ルールを確認する	重複通知、誤クローズ、古いスキーマ参照がないか

KQLでDLPアラートの原因操作を追う方法

DLPアラートをSentinelで調査する際は、まず該当アラートのSystemAlertIdを確認します。その後、SecurityAlertから対象アラートを取得し、CloudAppEventsの相関IDと結合することで、アラートの発生時間帯に行われたユーザー操作を確認します。Microsoft Learnでは、SystemAlertIdを指定してSecurityAlertを取得し、CloudAppEventsと照合するサンプルクエリが示されています。(Microsoft Learn)

let TargetAlertId = "<調査対象のSystemAlertIdを入力>";
let Alert =
    SecurityAlert
    | where TimeGenerated > ago(30d)
    | where SystemAlertId == TargetAlertId;
CloudAppEvents
| extend correlationId = tostring(parse_json(tostring(RawEventData.Data)).cid)
| join kind=inner Alert on $left.correlationId == $right.AlertType
| where todatetime(RawEventData.CreationTime) > StartTime
| where todatetime(RawEventData.CreationTime) < EndTime
| project
    TimeGenerated,
    ActionType,
    AccountDisplayName,
    AccountObjectId,
    IPAddress,
    Application,
    ObjectName,
    SystemAlertId,
    AlertName,
    RawEventData

このクエリで見るべきポイントは、「どのユーザーが」「どのファイルやメールに」「どのアプリケーション経由で」「どの時刻に」「どの操作をしたか」です。たとえば、SharePoint上の機密ファイルをダウンロードした直後に外部共有が行われている場合、単なるDLPポリシー違反ではなく、意図的な持ち出しやアカウント侵害の可能性を検討します。

クエリ結果を見るときは、1件の操作だけで判断しないことが重要です。直前のサインイン、IPアドレスの変化、端末情報、メール送信、ファイル共有、外部クラウドへのアップロードなどを時系列で並べると、誤検知と重大インシデントを分けやすくなります。

ライセンスと権限：DLP調査は最小権限で設計する

DLPアラートをMicrosoft Defenderポータルで調査するには、Microsoft Office 365 E5/A5、Microsoft 365 E5/A5、Microsoft 365 E5/A5 Compliance、Microsoft 365 E5/A5 Information Protection and Governanceなど、対象機能を含むライセンスが必要です。Microsoft Learnでは、DLPアラート調査に必要なライセンスと、DLPアラートへのアクセス権限が整理されています。(Microsoft Learn)

権限設計では、SOC担当者に過剰なコンテンツ閲覧権限を与えないことが大切です。DLPアラートのメタデータを見るだけでよい担当者と、実際のファイル内容や一致した機密情報を確認する担当者は分けるべきです。Microsoft PurviewのDLPアラートでは、コンテンツプレビューや一致した機密情報を確認するには、Content Explorer Content Viewerに関連する権限が必要です。(Microsoft Learn)

ロール設計の観点	推奨される考え方
SOC一次対応	アラート、エンティティ、時系列、重大度を確認できればよい
DLP調査担当	DLPポリシー名、ルール、SIT、ユーザー操作を確認できる権限を付与する
コンテンツ確認担当	必要な場合のみ、ファイル内容や一致箇所を確認できる権限を付与する
グローバル管理者	日常調査では使わず、設定変更や緊急時に限定する
外部委託SOC	機密内容を見せず、メタデータとインシデント運用に絞る

グローバル企業では、国や地域によって個人情報や従業員監視に関する規制が異なります。そのため、DLPアラートの本文、ファイル内容、ユーザー行動履歴を誰が閲覧できるかを、テナント全体のRBACだけでなく、地域別の運用ルールとしても整理しておく必要があります。

課金とデータ量：SecurityAlertだけでなくCloudAppEventsの量を見る

Defender XDRのアラートとインシデント、つまりSecurityAlertやSecurityIncidentに入るデータは、Microsoft Sentinelに無料で取り込まれ同期されます。一方で、Defenderコンポーネント由来のAdvanced Huntingテーブルなど、その他のイベントデータは課金対象になります。Microsoft Learnでも、DeviceInfo、DeviceFileEvents、EmailEventsなどのイベントテーブルは課金対象になることが説明されています。(Microsoft Learn)

DLP調査ではCloudAppEventsが重要になりますが、これはアラート本文ではなくイベントログです。つまり、DLP調査を高度化するほど、監査ログ・クラウド操作ログの取り込み量が増える可能性があります。特に、SharePoint、OneDrive、Exchange、Teams、クラウドアプリの利用量が多い組織では、いきなり全量を取り込むのではなく、検証ワークスペースで1週間から2週間ほどデータ量を測り、月額コストを見積もってから本番展開するのが安全です。

コスト確認項目	見るべき指標	実務上の判断
DLPインシデント件数	1日あたりの件数、重大度別件数	SOCが処理できる量か確認する
CloudAppEvents量	GB/日、ピーク時間帯、対象ワークロード	取り込み対象と保持期間を調整する
保持期間	調査要件、監査要件、法務要件	長期保存はデータレイクやアーカイブも検討する
プレイブック実行数	通知、チケット作成、自動クローズ回数	誤検知による無駄な自動処理を削減する
多拠点運用	国・地域・部門別のデータ量	ワークスペース分割やタグ設計を検討する

移行期限：SentinelのAzureポータル運用は2027年3月31日以降に変わる

DLPアラート調査そのものの移行期限ではありませんが、Microsoft Sentinelの運用ポータルには重要な期限があります。Microsoft Learnでは、2027年3月31日以降、Microsoft SentinelはAzureポータルでサポートされなくなり、Microsoft Defenderポータルでのみ利用可能になると説明されています。AzureポータルでSentinelを運用している組織は、Defenderポータルへの移行計画を進める必要があります。(Microsoft Learn)

これは、DLPアラート調査にも影響します。現在AzureポータルでSentinelのインシデント、Workbook、Automation、Huntingを運用している場合、Defenderポータルで同じ調査導線を再現できるか確認しなければなりません。Microsoft Defenderポータルでは、Sentinelのインシデント管理、Hunting、Workbook、Data connectors、Automationなどの配置がAzureポータルとは異なります。Microsoft Learnでは、AzureポータルとDefenderポータルのナビゲーション差分も整理されています。(Microsoft Learn)

期限・変更点	影響	今やるべきこと
2027年3月31日以降、SentinelはDefenderポータル中心へ	Azureポータル前提の運用手順が使えなくなる	SOC手順書をDefenderポータル前提に更新する
Defender XDRコネクタ利用	既存の個別Defenderコネクタとスキーマが変わる	KQL、Workbook、分析ルールを棚卸しする
統合インシデントキュー	DLPとセキュリティアラートが同じ流れに入る	タグ、重大度、担当者割り当てを標準化する
CloudAppEvents活用	調査精度は上がるがデータ量も増える	コスト見積もりと保持期間を決める
グローバル運用	地域ごとの権限・監査要件が絡む	ロール、承認、証跡保存を地域別に設計する

管理者が確認すべきチェックリスト

Microsoft DefenderでDLPアラートをSentinel連携する前に、以下を確認しておくと、導入後の混乱を避けやすくなります。

DLPポリシーとアラートの確認

Microsoft Purviewで、対象のDLPポリシーがアラートを生成する設定になっているか確認します。DLPアラートは、ポリシールールの条件に一致したときに生成されます。アラートは単一イベントとして生成することも、しきい値や時間枠で集約することもできます。Microsoft Learnでは、単一イベントアラートと集約イベントアラートの考え方が説明されています。(Microsoft Learn)

特に注意したいのは、アラート量です。たとえば「外部共有1件ごとにアラート」を作ると、グローバル組織ではすぐに大量のインシデントが発生します。重要度の高い情報種別、外部ドメイン、機密ラベル、ダウンロード量、短時間の繰り返し操作などを条件にし、SOCが処理できる量に調整してください。

Sentinel側の取り込み確認

Sentinel側では、Defender XDRコネクタが有効で、DLPインシデントがSecurityIncidentやSecurityAlertとして確認できるかを見ます。Microsoftの手順では、ProviderName == "Microsoft XDR"でMicrosoft XDR由来のインシデントを確認するKQLが示されています。(Microsoft Learn)

SecurityIncident
| where ProviderName == "Microsoft XDR"
| summarize count() by bin(TimeGenerated, 1d), Severity
| order by TimeGenerated desc

次に、CloudAppEventsに実データが入っているか確認します。DLPアラートが見えていても、CloudAppEventsが空であれば、アラートの背景にあるユーザー操作をSentinel上で十分に追えません。

CloudAppEvents
| summarize count() by bin(TimeGenerated, 1d)
| order by TimeGenerated desc

既存のKQLと自動化ルールの棚卸し

Defender XDRコネクタに切り替えると、スタンドアロンコネクタ時代のスキーマ前提で作られたクエリや自動化が壊れる可能性があります。特に、インシデント名、プロダクト名、アラートID、エンティティ形式、カスタム詳細を条件にしているルールは要確認です。Microsoft Learnでは、Defender XDRコネクタ接続時にMicrosoftインシデント作成ルールが無効化されること、またインシデントタイトルを条件にした自動化ルールは影響を受けやすいためタグなど別条件の利用が推奨されることが説明されています。(Microsoft Learn)

確認すべき代表例は次のとおりです。

対象	確認内容
Analytics rules	DLPやDefender系アラートを旧スキーマで参照していないか
Automation rules	インシデント名だけで分岐していないか
Playbooks	アラートID、エンティティ、ユーザー情報の取得方法が変わっていないか
Workbooks	SecurityAlert、SecurityIncident、CloudAppEventsの列名変更に弱くないか
通知テンプレート	DLPの機密情報を不要にメールやTeamsへ転送していないか

失敗しやすいポイント

最も多い失敗は、DLPインシデントだけをSentinelに取り込んで満足してしまうことです。DLPアラートの実務調査では、「なぜ発生したか」「どの操作が影響したか」「同じユーザーが他に何をしたか」を追う必要があります。そのため、CloudAppEventsを使った時系列調査までを標準手順に含めるべきです。

次に多いのは、権限の与えすぎです。SOC全員にコンテンツ閲覧権限を与えると、調査効率は上がるように見えますが、個人情報や機密文書へのアクセス範囲が広がります。一次トリアージ担当、詳細調査担当、コンテンツ確認担当、承認者を分け、監査ログでアクセス履歴を追えるようにしてください。

また、保持期間の誤解にも注意が必要です。MicrosoftのDLPアラート調査の説明では、Defenderポータルのインシデント履歴は6か月、DLPアラート管理ダッシュボードのアラートは30日保持されると説明されています。長期調査や監査対応が必要な組織では、Sentinel側の保持期間、アーカイブ、エクスポート方針を別途設計する必要があります。(Microsoft Learn)

失敗例	起きる問題	回避策
CloudAppEventsを有効化していない	アラートの原因操作を追えない	DLP調査用の取り込み確認クエリを定期実行する
旧コネクタ前提のクエリを使い続ける	Workbookやプレイブックが失敗する	Defender XDRコネクタ前提でKQLを更新する
DLPアラート量を見積もらない	SOCがアラート疲れを起こす	集約アラート、重大度、タグで優先度を調整する
権限を広く付与する	機密データ閲覧範囲が拡大する	最小権限と承認制を徹底する
Azureポータル前提の手順を残す	2027年以降の運用移行で混乱する	Defenderポータル前提の手順書へ更新する

実務での活用シーン

この連携が特に効果を発揮するのは、DLPアラートだけでは判断しにくいケースです。たとえば、営業担当者が退職前に大量の顧客リストをダウンロードし、その直後に個人メールへ送信した疑いがある場合、DLPアラート単体では「ポリシー違反があった」ことしか分かりません。SentinelでCloudAppEvents、サインインログ、端末ログ、メールログを組み合わせることで、意図的な持ち出しなのか、通常業務なのか、アカウント侵害なのかを判断しやすくなります。

別の例として、海外拠点のユーザーが深夜にSharePointの機密ファイルを大量ダウンロードした場合も、DLPアラートだけでは判断が難しいことがあります。普段と異なるIPアドレス、通常と違うデバイス、短時間の大量操作、外部共有、メール送信が連続していれば、優先度を上げて対応すべきです。

実務では、次のような判定基準を作ると運用しやすくなります。

判定材料	低リスクの例	高リスクの例
ユーザー	通常業務の担当者	退職予定者、異動直前、権限変更直後
操作量	数件の閲覧や編集	短時間の大量ダウンロード
共有先	社内ユーザー	個人メール、外部ドメイン、不明なクラウド
時間帯	通常勤務時間	深夜、休日、現地時間と合わない時間
端末・IP	管理端末、通常の拠点IP	未管理端末、匿名化サービス、不審な国・地域
データ種別	低機密の社内資料	個人情報、顧客情報、知財、財務情報

まず管理者が取るべき次のアクション

最初にやるべきことは、既存のDLPアラートが「誰に届き、どこで調査され、どのログで裏取りされているか」を棚卸しすることです。そのうえで、Microsoft Defender XDRコネクタ、CloudAppEvents、DLPポリシー、Sentinelの自動化ルールを順番に確認します。

短期的には、代表的なDLPポリシーを1つ選び、検証用イベントを発生させて、Sentinelでインシデント確認からKQL調査、チケット化、担当者割り当て、クローズまでを通しで試してください。中期的には、DefenderポータルへのSentinel移行を前提に、手順書、ロール設計、KQL、Workbook、プレイブックを更新します。

Microsoft DefenderのDLPアラート調査は、Purviewだけ、Sentinelだけ、Defenderだけで完結させるよりも、役割を分けて連携させたほうが実務に向いています。Purviewではポリシーを設計し、Defender XDRでは統合インシデントとして優先度を判断し、Sentinelでは他データソースと相関して証跡を深掘りする。この分担を明確にすることが、今回の更新を活かす一番のポイントです。