Microsoft Defenderの「Advanced threat detection with User and Entity Behavior Analytics (UEBA) in Microsoft Sentinel」は、Microsoft SentinelのUEBAをDefenderポータル上の調査・ハンティング・検知運用に組み込むための公式情報です。結論から言うと、今回押さえるべきポイントは「UEBAを有効化するだけ」ではありません。データソース、異常検知、UEBA Essentials、必要に応じたUEBA behaviors layer、Defenderポータル移行をセットで確認する必要があります。
特に、Microsoft SentinelをAzureポータル中心で運用している組織、Microsoft Defenderポータルでインシデント調査やAdvanced Huntingを行うSOC、KQLでカスタム検知を作る管理者・開発者は、早めに設定と運用手順を見直すべきです。Microsoft Learnの該当ページは2026年5月14日に更新されており、UEBAがユーザー、ホスト、IPアドレス、アプリケーションなどの行動プロファイルを機械学習で作成し、通常と異なる動きを検出する機能であることを説明しています。(Microsoft Learn)
Microsoft DefenderでのUEBAは「Sentinelの異常検知を調査に使いやすくする機能」
UEBAは、User and Entity Behavior Analyticsの略です。日本語では「ユーザーとエンティティの行動分析」と考えると分かりやすいでしょう。
Microsoft SentinelのUEBAは、サインイン、監査ログ、クラウド操作、端末ログオンなどのデータをもとに、ユーザーやデバイスの普段の行動を学習します。そのうえで、通常とは異なる場所、端末、時間帯、操作頻度、同じ役割のユーザーとの違いなどを見つけ、調査の優先順位付けに役立てます。(Microsoft Learn)
重要なのは、UEBAは単なるアラート発生機能ではないという点です。異常な行動を「見つける」だけでなく、調査画面、ユーザーページ、インシデントグラフ、Advanced Hunting、カスタム検知に文脈を追加する役割を持ちます。Microsoft Learnでは、UEBAがMicrosoft SentinelとMicrosoft Defenderポータルにネイティブ統合され、脅威調査と対応を強化すると説明されています。(Microsoft Learn)
今回の公式情報で注目すべき変更点
今回の更新は、製品名が変わったというより、Microsoft Defenderポータル上でUEBAをどう使うべきかが整理された内容です。管理者視点では、次の点を押さえると全体像を理解しやすくなります。
| 注目点 | 内容 | 実務上の意味 |
|---|---|---|
| DefenderポータルでのUEBA活用 | ホーム画面のUEBAウィジェット、ユーザー調査画面、インシデント調査、Advanced HuntingでUEBAデータを利用できる | SOCが異常ユーザーを素早く見つけ、既存のインシデント調査に行動分析を追加しやすくなる |
| スコアの使い分け | BehaviorAnalyticsのInvestigationPriorityと、AnomaliesのAnomalyScoreを別の目的で利用する | 単一イベントの優先度と、複数イベントをまたぐ異常度を混同しないことが重要 |
| UEBA Essentials | Microsoftが用意した事前構築済みハンティングクエリ群を利用できる | 一からKQLを作らず、Azure、AWS、GCP、Oktaなどを含むハンティングを始めやすい |
| UEBA behaviors layer | 大量の生ログを「誰が何を誰に対して行ったか」という行動単位に整理する | 生ログの結合や正規化に時間をかけず、調査・検知ルール作成に使いやすい情報を得られる |
| Defenderポータル移行 | Microsoft Sentinelは2027年3月31日以降、Azureポータルではサポートされず、Defenderポータルで提供される予定 | Azureポータル中心の運用は、権限、手順、検知、プレイブックの見直しが必要 |
Microsoftは、Microsoft SentinelのAzureポータルでのサポートを2027年3月31日以降終了し、Defenderポータルでの利用へ移行する方針を示しています。UEBAの確認は、単体機能の設定確認にとどめず、Defenderポータル移行計画の一部として扱うのが現実的です。(Microsoft Learn)
影響を受ける対象者
この更新で特に確認が必要なのは、次のような担当者です。
| 対象者 | 確認すべきこと |
|---|---|
| セキュリティ管理者 | UEBAの有効化状態、データソース、異常検知の有効化、権限、コスト影響 |
| SOCアナリスト | Defenderポータルのユーザー調査画面、インシデントグラフ、UEBAウィジェットの使い方 |
| 検知エンジニア | BehaviorAnalytics、Anomalies、BehaviorInfo、SentinelBehaviorInfoなどのテーブルを使ったKQL |
| クラウド管理者 | Entra ID、AWS、GCP、Oktaなどのログ連携状況 |
| 開発者・自動化担当者 | カスタム検知、Logic Apps、チケット連携、API連携の影響 |
| 情シス・ID管理担当者 | Microsoft Entra ID、オンプレミスActive Directory、Defender for Identity連携 |
Microsoft Defender for Endpointだけを使っている組織の場合、UEBAが自動的に使えるわけではありません。ここで扱うUEBAは、Microsoft SentinelのワークスペースとDefenderポータル上の統合運用に関係する機能です。UEBA behaviors layerについても、DefenderポータルにオンボードされたMicrosoft Sentinelワークスペースが前提とされています。(Microsoft Learn)
まず確認すべき設定
UEBAの展開で失敗しやすいのは、機能をオンにしただけで必要なログが入っていないケースです。管理者は、次の順番で確認すると抜け漏れを減らせます。
| 確認項目 | 推奨アクション | 注意点 |
|---|---|---|
| 権限 | UEBAを有効化するユーザーに必要なMicrosoft Entra IDロールとAzure RBACを確認する | 最小権限では、Microsoft Sentinel ContributorとLog Analytics Contributorの組み合わせが必要になる場合がある |
| ワークスペース | 対象のMicrosoft Sentinelワークスペースを確認する | 複数ワークスペース環境では、どのワークスペースでUEBAを使うか明確にする |
| UEBA機能 | Entity behavior analyticsの設定画面でUEBAを有効化する | AzureポータルとDefenderポータルの両方に導線があるが、将来を考えるとDefenderポータルでの確認に慣れておく |
| ディレクトリサービス | Microsoft Entra ID、必要に応じてオンプレミスActive Directory連携を選択する | オンプレミスADのユーザー同期には、Defender for Identityとセンサー展開が関係する |
| データソース | 対象ログを選択して接続する | すべて接続すると便利だが、コストとノイズを考えて優先順位を付ける |
| 異常検知 | AnomaliesでDetect Anomaliesが有効か確認する | UEBAを有効化しても、異常検知の設定を別途確認する必要がある |
| UEBA Essentials | Content HubからUEBA Essentialsソリューションの利用を検討する | 初期導入では、Microsoftが用意したハンティングクエリを使うと立ち上げが早い |
| behaviors layer | 必要に応じて別途有効化する | 通常のUEBAとは独立して有効化する機能で、対応データソースにも制限がある |
UEBAの有効化には、Microsoft Entra IDのSecurity Administratorロールまたは同等権限、Azure側ではOwner、Contributor、またはMicrosoft Sentinel ContributorとLog Analytics Contributorなどの権限が必要です。また、対象ワークスペースにAzureリソースロックがかかっていないことも確認が必要です。(Microsoft Learn)
接続すべきデータソースの考え方
UEBAは、取り込んだデータから行動ベースラインを作ります。そのため、どのログを接続するかで検出できる異常が変わります。
公式情報では、UEBAの主要な接続先としてMicrosoft Entra ID、Defender for Identity、Office 365などが挙げられています。また、UEBAで利用できるデータソースには、サインインログ、監査ログ、Azure Activity、Security Eventsのほか、Defenderポータルのみで有効化できるプレビューのデータソースとして、マネージドIDサインイン、サービスプリンシパルサインイン、AWS CloudTrail、Device Logon Events、Okta、GCP Audit Logsなどが示されています。(Microsoft Learn)
実務では、いきなりすべてのデータソースを有効にするより、次の順で広げると運用しやすくなります。
| 優先度 | データソース例 | 理由 |
|---|---|---|
| 高 | Microsoft Entra IDのサインインログ、監査ログ | アカウント侵害、特権操作、不審なログインの検知に直結しやすい |
| 高 | Defender for Identity、端末ログオン関連 | 横展開、認証異常、オンプレミスAD由来のリスク把握に役立つ |
| 中 | Azure Activity | Azureリソース操作、権限変更、Key Vaultやストレージ操作の文脈を追いやすい |
| 中 | Office 365関連 | メール、ファイル、コラボレーション領域の不審操作を調査しやすい |
| 必要に応じて | AWS CloudTrail、GCP Audit Logs、Okta | マルチクラウドや外部ID基盤を利用している場合に有効 |
注意点は、データソースを増やすほど調査の材料は増えますが、Log AnalyticsやMicrosoft Sentinelのデータ量にも影響することです。UEBA自体に追加ライセンス費用はない一方、UEBAで作成されるデータはLog Analyticsテーブルに保存され、標準的なMicrosoft Sentinelの料金体系に従います。(Microsoft Learn)
UEBAで使う主なテーブル
UEBAを運用に組み込むには、どのテーブルに何が入るかを理解しておく必要があります。特にKQLを書く管理者や開発者は、テーブル名だけでなく用途まで押さえておくと、検知ルールや調査クエリを作りやすくなります。
| テーブル | 主な用途 | 使いどころ |
|---|---|---|
IdentityInfo | ユーザー、デバイス、グループなどのエンティティ情報 | ユーザー属性、特権、所属、ID文脈を確認する |
BehaviorAnalytics | UEBAで強化された行動データ | 単一イベントの優先度、位置情報、脅威インテリジェンスなどを使って調査する |
UserPeerAnalytics | 動的に算出されたピアグループ | 同じ役割や近い関係のユーザーと比較して異常を判断する |
Anomalies | 異常として検出されたイベント | 機械学習による異常検知を調査・検知に利用する |
SentinelBehaviorInfo | behaviors layerで作成される行動サマリー | Sentinelワークスペース側で行動のタイトル、説明、MITREマッピングを確認する |
SentinelBehaviorEntities | 行動に関係するエンティティ | 誰が主体で、誰または何が対象だったかを確認する |
SentinelBehaviorInfoとSentinelBehaviorEntitiesは、通常のUEBAを有効化しただけでは作成されません。Microsoft Learnでは、UEBA behaviors layerはUEBAとは別に有効化する機能であり、この2つのテーブルはbehaviors layerを有効化したワークスペースで作成されると説明されています。(Microsoft Learn)
InvestigationPriorityとAnomalyScoreを混同しない
UEBA運用でよくある誤解が、「スコアが高いものだけ見ればよい」という考え方です。Microsoft Sentinel UEBAでは、目的の違う2種類のスコアを使い分けます。
| スコア | テーブル | 範囲 | 何を示すか | 主な使い方 |
|---|---|---|---|---|
InvestigationPriority | BehaviorAnalytics | 0〜10 | 単一イベントがどれだけ通常と異なるか | トリアージ、優先順位付け、単一イベントの深掘り |
AnomalyScore | Anomalies | 0〜1 | 複数イベントや行動全体としての異常度 | パターン検出、集約的な異常検知、検知ルールの補強 |
例えば、あるユーザーが初めてAzure操作を行った場合、単一イベントとしては珍しいためInvestigationPriorityが高くなる可能性があります。一方で、初回操作自体が組織全体で珍しくない場合、AnomalyScoreは低くなることがあります。Microsoft Learnも、両スコアには相関がある場合があるものの、常に一致するわけではないと説明しています。(Microsoft Learn)
実務では、次のように使い分けると判断しやすくなります。
- 一次トリアージでは
InvestigationPriorityを見て、すぐ確認すべき単一イベントを絞り込む - 複数ログをまたぐ不審な流れは
Anomaliesを使って確認する - 検知ルールでは、スコアだけでなくユーザー属性、端末、IP、操作種別、時間帯を組み合わせる
- スコアが低くても、特権アカウントや休眠アカウントの操作は別基準で確認する
以下は、BehaviorAnalyticsで調査優先度の高いイベントを確認するKQL例です。
BehaviorAnalytics
| where TimeGenerated >= ago(7d)
| where InvestigationPriority >= 7
| project TimeGenerated, UserPrincipalName, ActivityType, ActionType, SourceIPAddress, SourceIPLocation, InvestigationPriority
| order by InvestigationPriority descMicrosoft Defenderポータルでの調査体験が強化される
今回の情報で重要なのは、UEBAの結果が単なるログテーブルに閉じていない点です。Microsoft Defenderポータルでは、UEBAデータが複数の調査画面に組み込まれます。
代表的な活用シーンは次のとおりです。
| 場面 | UEBAの使い方 |
|---|---|
| Defenderポータルのホーム画面 | UEBAウィジェットで異常なユーザー行動を確認する |
| ユーザー調査 | ユーザーページのサイドパネルやOverviewでUEBAコンテキストを確認する |
| インシデント調査 | インシデントグラフから対象ユーザーの異常を取得する |
| Advanced Hunting | UEBA関連テーブルとAnomaliesを結合して調査を深める |
| カスタム検知 | 行動分析データを条件に加え、検知精度を高める |
特にユーザーページでは、直近30日間の上位UEBA異常が表示され、事前構築済みクエリやSentinelイベントタイムラインへのリンクから深掘りできます。また、Advanced Huntingやカスタム検知でUEBA関連テーブルを扱う際に、DefenderポータルがAnomaliesテーブルとの結合を促すバナーを表示することも説明されています。(Microsoft Learn)
UEBA behaviors layerは「生ログを行動に変換する」別機能
UEBA behaviors layerは、通常のUEBAと混同しやすい機能です。通常のUEBAがベースラインとの差分を見て異常を検出するのに対し、behaviors layerは大量の生ログを、調査に使いやすい行動サマリーへ変換します。
Microsoft Learnでは、behaviors layerについて、高ボリュームの生ログを「誰が何を誰に対して行ったか」という平易な行動パターンに集約し、MITRE ATT&CKマッピングやエンティティの役割を付与すると説明しています。(Microsoft Learn)
たとえば、AWS CloudTrailの複数イベントを個別に読み解くのではなく、「新しいアクセスキーの作成後、別IPから使用され、特権操作が行われた」といった一連の動きを行動として扱えるようになります。これにより、ハンティング、検知ルール、インシデント調査でのKQLが単純化しやすくなります。(Microsoft Learn)
ただし、behaviors layerには注意点があります。
| 注意点 | 内容 |
|---|---|
| 別途有効化が必要 | UEBA analyticsやanomaliesでAWSCloudTrailなどを有効化していても、behaviors layer用に別途有効化が必要 |
| 対応データソースは限定的 | CommonSecurityLog、AWSCloudTrail、GCPAuditLogsなど、対応範囲は拡大中だが限定されている |
| 1テナント1ワークスペース制限 | 現時点では、テナント内の単一Sentinelワークスペースで有効化できると説明されている |
| 生成されない＝安全ではない | 対応していない操作やログではbehaviorが出ないことがある |
| alertやanomalyではない | behaviorは「発生した行動」の記録であり、悪性・良性の判定そのものではない |
特に「behaviorが出ていないから問題ない」と判断するのは危険です。Microsoft Learnでも、behaviors layerはすべての操作や攻撃技術を捕捉するものではなく、疑わしい場合は生ログを確認する必要があると説明されています。(Microsoft Learn)
Defenderポータル移行で確認すべき運用上の影響
UEBAそのものの設定に加え、Microsoft SentinelをDefenderポータルで運用する影響も確認が必要です。Microsoftは、SentinelをDefenderポータルに統合しても、Log Analyticsの観点では既存の取り込みパイプラインやデータスキーマに変更はないと説明しています。つまり、UEBAの利用開始が既存ログ取り込みを丸ごと作り直すことを意味するわけではありません。(Microsoft Learn)
一方で、インシデント、相関、オートメーション、API連携には影響があります。たとえば、Defenderポータルへオンボード後は、Defender XDRの相関エンジンがインシデント統合を制御し、Microsoft SentinelのFusionルールはDefenderポータル側の相関機能に置き換えられると説明されています。また、インシデント名が変わる可能性や、オートメーションルールでインシデントタイトルを条件にしている場合の注意点も示されています。(Microsoft Learn)
移行前に確認すべき項目は次のとおりです。
| 確認項目 | 見直すべき内容 |
|---|---|
| RBAC | Azure RBAC、Microsoft Entra IDロール、DefenderポータルのUnified RBACの役割分担 |
| アナリティクスルール | Defenderポータルでの表示、インシデント生成、相関の挙動 |
| オートメーション | インシデント名やDescriptionフィールドに依存した条件の有無 |
| Playbook | Defenderポータルで手動実行できない操作や同期遅延の影響 |
| API連携 | Microsoft Sentinel APIとMicrosoft Graph security APIの使い分け |
| チケット連携 | インシデントURL、説明文、プロバイダー名の変化 |
| アナリスト手順 | Azureポータル前提の手順書、画面キャプチャ、教育資料 |
UEBAの導入をきっかけに、既存のSOC手順をDefenderポータル前提に更新しておくと、2027年の移行期限に向けた手戻りを減らせます。
コスト面で注意すべきこと
UEBAはMicrosoft Sentinelに含まれており、追加の機能ライセンス費用は不要と説明されています。ただし、UEBAが生成するデータはLog Analyticsテーブルに保存されるため、データ保存や取り込みに関する標準的なMicrosoft Sentinelの料金が発生します。(Microsoft Learn)
また、UEBA behaviors layerについても追加SKUや追加ライセンスは不要とされていますが、SentinelBehaviorInfoやSentinelBehaviorEntitiesに保存されるbehaviorレコードは取り込み量に加算され、既存のLog AnalyticsまたはSentinelの取り込み料金に影響します。(Microsoft Learn)
コストを抑えつつ効果を出すには、次の考え方が有効です。
- まずID、特権操作、サインイン関連のログから有効化する
- 利用していないクラウドやID基盤のデータソースを安易に接続しない
- behaviors layerは、調査負荷が高いログソースから段階的に試す
UsageテーブルでSentinelBehaviorInfoやSentinelBehaviorEntitiesの増加を監視する- 検知ルールを増やす前に、アナリストが実際に使う調査ビューとKQLを整える
展開時に起きやすい失敗と対策
| 失敗しやすいポイント | 原因 | 対策 |
|---|---|---|
| UEBAを有効化したのに異常が見えない | 必要なデータソースが接続されていない、異常検知が有効でない | UEBA、データソース、Detect Anomaliesをそれぞれ確認する |
| スコアだけで誤検知対応してしまう | InvestigationPriorityとAnomalyScoreの意味を混同している | スコア、ユーザー属性、操作内容、端末、時間帯を組み合わせて判断する |
| behaviors layerの結果をアラートと誤解する | behaviorを「危険判定」と見なしてしまう | behaviorは行動サマリーであり、alertやanomalyとは別物として扱う |
| コストが想定より増える | データソースを一括接続し、生成テーブルの量を見ていない | 段階展開し、UsageテーブルやLog Analyticsの利用状況を確認する |
| 既存の自動化が動かない | Defenderポータル移行でインシデント項目や相関挙動が変わる | タイトルやDescription依存の条件を見直し、アナリティクスルール名やタグを使う |
| アナリストが使いこなせない | テーブルや画面の位置が変わり、手順書がAzureポータル前提のまま | Defenderポータル前提で調査手順、KQL、教育資料を更新する |
管理者・開発者が取るべき次のアクション
まず、Microsoft Sentinelワークスペースごとに、UEBAが有効化されているか、どのデータソースが接続されているかを棚卸ししてください。次に、BehaviorAnalyticsとAnomaliesを使った調査が既存のインシデント対応手順に組み込まれているか確認します。
開発者や検知エンジニアは、既存のKQLやカスタム検知でUEBAデータをどう活用できるかを確認しましょう。特に、ユーザー名やIPアドレスだけで検知しているルールは、InvestigationPriority、AnomalyScore、ユーザー属性、MITREマッピングを組み合わせることで、優先順位付けしやすくなります。
behaviors layerを使う場合は、DefenderポータルのAdvanced HuntingではBehaviorInfoとBehaviorEntities、Sentinelワークスペース側ではSentinelBehaviorInfoとSentinelBehaviorEntitiesを使う点を区別してください。Microsoft Learnでも、DefenderポータルとSentinelワークスペースでは使うテーブルが異なることが示されています。(Microsoft Learn)
BehaviorInfo
| where ServiceSource == "Microsoft Sentinel"
| where TimeGenerated >= ago(7d)
| project TimeGenerated, Title, Description, Categories, AttackTechniques
| order by TimeGenerated desc最後に、Azureポータル中心のMicrosoft Sentinel運用を続けている場合は、UEBAの設定確認と同時にDefenderポータル移行計画を作成してください。2027年3月31日以降のサポート方針を考えると、UEBAの導入は単なる検知機能の追加ではなく、SIEMとXDRを統合した運用へ移るための準備でもあります。(Microsoft Learn)
<最後に確認するチェックリスト>
| チェック | 内容 |
|---|---|
| □ | 対象のMicrosoft SentinelワークスペースがDefenderポータルで管理できる |
| □ | UEBAが有効化されている |
| □ | Microsoft Entra ID、監査ログ、必要なクラウドログが接続されている |
| □ | Detect Anomaliesが有効になっている |
| □ | BehaviorAnalyticsとAnomaliesの使い分けをSOC手順に反映している |
| □ | UEBA Essentialsの導入可否を確認した |
| □ | behaviors layerを使う場合、別途有効化と対応データソースを確認した |
| □ | 生成テーブルによるコスト影響を確認している |
| □ | Defenderポータル移行に伴う自動化、API、チケット連携の影響を確認した |
| □ | アナリスト向けの調査手順をDefenderポータル前提に更新した |
UEBAは、導入しただけで攻撃を自動的に止める魔法の機能ではありません。価値が出るのは、正しいログを取り込み、スコアの意味を理解し、Defenderポータル上の調査・ハンティング・検知ルールに組み込んだときです。まずは対象ワークスペース、データソース、異常検知、コスト、移行影響を確認し、SOCの実際の調査フローにUEBAを組み込むところから始めましょう。
コメント