Microsoft Defenderで「Enable entity behavior analytics to detect advanced threats」を確認している管理者がまず押さえるべき点は、これはMicrosoft Defender単体の新機能というより、Microsoft Defenderポータル上で利用するMicrosoft SentinelのUEBA（User and Entity Behavior Analytics）設定に関する公式手順だということです。2026年5月6日に更新されたMicrosoft Learnでは、UEBAの有効化方法、対応データソース、権限要件、Azure portalからDefender portalへの移行前提が整理されています。(Microsoft Learn)
結論から言えば、管理者が今確認すべきなのは、UEBAが有効か、必要なログソースが接続されているか、異常検知がオンになっているか、そして2027年3月31日以降にMicrosoft SentinelがAzure portalではサポートされなくなることを前提に、Microsoft Defenderポータル側で運用できる状態になっているかです。(Microsoft Learn)
Enable entity behavior analytics to detect advanced threatsとは
「Enable entity behavior analytics to detect advanced threats」は、Microsoft SentinelでUEBAを有効化し、ユーザー、ホスト、IPアドレス、アプリケーションなどのエンティティの通常行動を学習させ、通常とは異なる行動を検出しやすくするための設定です。
UEBAは、接続済みデータソースのログやアラートを分析し、組織内のエンティティごとにベースラインとなる行動プロファイルを作ります。そのうえで、機械学習を使って侵害済みアカウント、内部不正、ラテラルムーブメントなどにつながる可能性のある異常な行動を検出します。(Microsoft Learn)
たとえば、次のようなケースで価値が出ます。
| 検知したい状況 | UEBAで見たい観点 |
|---|---|
| 普段とは異なる国や端末からのサインイン | ユーザーの過去の行動、地理情報、端末情報との差分 |
| 管理者権限を持つユーザーの不自然な操作 | Azure Activity、Audit Logs、Signin Logsとの相関 |
| クラウド環境での認証情報悪用 | AWS CloudTrail、GCP Audit Logs、Oktaなどの行動パターン |
| 端末ログオンの異常 | Device Logon EventsやSecurity Eventsとの比較 |
| インシデント調査時の優先順位付け | Investigation priority scoreやAnomaly scoreの活用 |
重要なのは、UEBAは「単独で万能な検知ルールを追加する機能」ではなく、既存のログをもとに行動の文脈を加える機能だという点です。ログ収集が薄い環境では、期待したほどの分析結果が出ません。
今回の公式情報で押さえるべき変更点
2026年5月6日更新の公式情報で特に確認したいポイントは、UEBAを有効化する導線と、Microsoft Defenderポータル中心の運用に向けた整理です。公式ページでは、Microsoft SentinelのUEBAを有効化する方法として、SIEM workspacesタブ、UEBAタブ、対応データコネクタからの設定という3つの方法が示されています。(Microsoft Learn)
| 確認ポイント | 内容 | 管理者への影響 |
|---|---|---|
| 対象環境 | Microsoft Defenderポータル上のMicrosoft Sentinel、Azure portal上のMicrosoft Sentinel | Defenderポータルでの運用確認が必須になる |
| 有効化方法 | ワークスペース設定、UEBAタブ、対応データコネクタから有効化 | 管理画面の導線を運用手順書に反映する |
| 対応データソース | Signin Logs、Audit Logs、Azure Activity、Security Eventsなど | 接続済みログの棚卸しが必要 |
| Defender portal限定のプレビュー対象 | AAD Managed Identity Signin logs、AAD Service Principal Signin logs、AWS CloudTrail、Device Logon Events、Okta CL、GCP Audit Logs | マルチクラウドやID基盤の監視強化に関係する |
| コスト | UEBA機能自体に追加ライセンスは不要だが、生成されるデータの保存には追加ストレージ料金が発生し得る | Log Analyticsのデータ量とコスト監視が必要 |
| 移行期限 | 2027年3月31日以降、Microsoft SentinelはAzure portalでサポートされず、Microsoft Defenderポータルで利用する形になる | Azure portal前提の手順や教育資料の見直しが必要 |
特に見落としやすいのは、UEBAをオンにするだけでは終わらない点です。データソースを接続し、さらにMicrosoft Sentinelワークスペースで異常検知を有効化する必要があります。公式手順では、ワークスペース設定のAnomaliesで「Detect Anomalies」をオンにする流れが示されています。(Microsoft Learn)
対象となる管理者・開発者・SOC担当者
この更新の影響を受けやすいのは、Microsoft Defender、Microsoft Sentinel、Microsoft Entra ID、Log Analyticsを組み合わせて運用している組織です。
セキュリティ管理者
セキュリティ管理者は、UEBAの有効化状況、必要な権限、ワークスペースのロック有無、データソース接続状況を確認する必要があります。UEBAの有効化または無効化には、Microsoft Entra IDのSecurity Administrator相当の権限に加え、Azure側ではOwner、Contributor、または最小権限構成としてMicrosoft Sentinel ContributorとLog Analytics Contributorなどが必要です。(Microsoft Learn)
SOCアナリスト
SOCアナリストにとっては、UEBAがアラートのノイズを単純に減らす機能というより、インシデント調査の文脈を増やす機能である点が重要です。Defenderポータルでは、ユーザーページ、インシデントグラフ、高度なハンティングクエリなどにUEBAの情報を組み込めます。(Microsoft Learn)
検知ルールやKQLを扱う開発者
KQLで検知ルールやハンティングクエリを作成している担当者は、BehaviorAnalytics、IdentityInfo、UserPeerAnalytics、AnomaliesなどのUEBA関連テーブルを理解しておく必要があります。UEBAのデータは、ユーザーや端末の文脈、異常スコア、行動の履歴を組み合わせて調査するために使われます。(Microsoft Learn)
管理者が最初に確認すべき設定
UEBAの導入で失敗しやすいのは、「機能をオンにしたのに検知が増えない」「期待したデータが出ない」「コストが増えた理由が分からない」という状態です。まずは次の順番で確認すると、原因を切り分けやすくなります。
| 確認順 | 確認項目 | 判断基準 |
|---|---|---|
| 1 | SentinelワークスペースがDefenderポータルで管理できるか | Microsoft DefenderポータルのMicrosoft Sentinel設定に対象ワークスペースが表示される |
| 2 | UEBA機能がオンか | Entity behavior analyticsまたはUEBAタブで有効化されている |
| 3 | ディレクトリサービスの同期元 | Microsoft Entra ID、必要に応じてオンプレミスActive Directoryが選択されている |
| 4 | データソース | Signin Logs、Audit Logs、Azure Activity、Security Eventsなどが接続されている |
| 5 | 異常検知 | AnomaliesでDetect Anomaliesがオンになっている |
| 6 | Log Analyticsのテーブル | UEBA関連テーブルにデータが生成されている |
| 7 | コスト | 新規テーブルへの保存量が想定範囲内か |
オンプレミスActive Directoryのユーザーエンティティを同期したい場合は、Microsoft Defender for Identityのオンボードと、Active DirectoryドメインコントローラーへのMDIセンサー導入が必要です。ハイブリッドID環境では、この条件を満たしていないと、オンプレミス側の行動文脈が十分に反映されません。(Microsoft Learn)
UEBAの有効化手順
Microsoft DefenderポータルでUEBAを有効化する場合は、概ね次の流れで確認します。実際の画面表示はテナントやロール、ポータル更新状況によって変わる可能性があるため、運用手順書には画面名だけでなく「どのワークスペースに対して何を有効化するか」も明記しておくと安全です。
| 手順 | 作業 | 補足 |
|---|---|---|
| 1 | Microsoft Defenderポータルを開く | Sentinelを利用する管理者権限でアクセスする |
| 2 | Settings > Microsoft Sentinel > SIEM workspacesへ移動 | 対象ワークスペースを選択する |
| 3 | Entity behavior analytics > Configure UEBAを開く | UEBA設定画面に入る |
| 4 | Turn on UEBA featureをオンにする | 機能の有効化 |
| 5 | 同期するディレクトリサービスを選ぶ | Microsoft Entra ID、必要に応じてオンプレAD |
| 6 | データソースを選択する | すべて接続、または必要なものを個別選択 |
| 7 | Connectを選択する | 設定を反映 |
| 8 | AnomaliesでDetect Anomaliesをオンにする | 異常検知を有効化 |
データコネクタ側からUEBAを有効化する方法もあります。Microsoft DefenderポータルでMicrosoft Sentinel > Configuration > Data connectorsに移動し、UEBA対応コネクタの詳細画面からAdvanced optionsを開き、Configure UEBAで対象テーブルを有効化します。(Microsoft Learn)
対応データソースと優先順位の付け方
UEBAは、接続されたログをもとに行動のベースラインを作ります。そのため「何を接続するか」が検知品質に直結します。
まず優先したいのは、IDと認証に関するログです。アカウント侵害や不正利用は、サインイン、監査ログ、権限操作、端末ログオンに痕跡が残りやすいためです。
| 優先度 | データソース | 使いどころ |
|---|---|---|
| 高 | Signin Logs | 不審なサインイン、場所や端末の変化を検出 |
| 高 | Audit Logs | 権限変更、アプリ登録、グループ操作などを確認 |
| 高 | Azure Activity | Azureリソース操作の異常を把握 |
| 高 | Security Events | Windowsログオン、特権付与、プロセス作成などを分析 |
| 中 | Device Logon Events | 端末ログオンの行動分析を強化 |
| 中 | AWS CloudTrail | AWS管理操作やIAM関連操作の文脈化 |
| 中 | GCP Audit Logs | GCP上のIAM、Compute、Storageなどの操作を分析 |
| 中 | Okta CL | Okta認証、MFA、セッション関連イベントの分析 |
| 中 | AAD Service Principal Signin logs | サービスプリンシパルの不審な利用を確認 |
| 中 | AAD Managed Identity Signin logs | マネージドIDのサインイン行動を確認 |
公式リファレンスでは、UEBAが分析する入力データソースとして、Microsoft Entra IDのサインインログや監査ログ、Azure Activity、Security Eventsに加え、AWS CloudTrail、GCP Audit Logs、Okta、Device Logon Eventsなどが整理されています。(Microsoft Learn)
すべてを一度に有効化するのではなく、まずはID、監査、Azure操作ログから始めるのが現実的です。その後、AWS、GCP、Oktaなど、実際に使っている外部クラウドやID基盤を追加します。使っていないデータソースを有効化しても価値は出ませんし、ログ量やコストだけが増える可能性があります。
Azure portalからDefender portalへの移行で注意すべきこと
Microsoft Sentinelは2027年3月31日以降、Azure portalではサポートされず、Microsoft Defenderポータルで利用する形になると公式情報で案内されています。したがって、今からUEBAを設定する場合は、Azure portalではなくDefenderポータルでの運用を前提に設計したほうが安全です。(Microsoft Learn)
移行で見落としやすいのは、単に画面の場所が変わるだけではない点です。Defenderポータルでは、SIEM、SOAR、XDR、クラウドセキュリティ、脅威インテリジェンスなどを統合した運用体験が提供されます。Microsoft Sentinelもその統合された運用画面の中で扱われます。(Microsoft Learn)
移行前に確認する項目
| 項目 | 確認内容 |
|---|---|
| ワークスペース | 既存のSentinelワークスペースがDefenderポータルにオンボードされているか |
| 権限 | Azure RBACとDefenderポータル側の権限設計に矛盾がないか |
| データコネクタ | 既存コネクタが継続して動作しているか |
| インシデント運用 | Defender XDR側のインシデントキューと重複・抜け漏れがないか |
| 手順書 | Azure portal前提の画面手順をDefender portal前提に更新したか |
| CMK | カスタマー管理キーを利用している場合、暗号化の扱いを確認したか |
| データ保持・プライバシー | Azure portal利用時とDefender portal利用時のポリシー差分を確認したか |
公式の移行ガイドでは、SentinelをDefenderポータルに統合しても、Log Analytics視点のデータ取り込みパイプラインやデータスキーマに基本的な変更はないと説明されています。一方で、ポータル統合後はデータ保管、処理、保持、共有に関するポリシーの違いや、Defender XDRコネクタの扱いを確認する必要があります。(Microsoft Learn)
コストとライセンスで誤解しやすいポイント
UEBAはMicrosoft Sentinelに含まれており、UEBA機能を追加するための特別なライセンスは不要とされています。ただし、UEBAが新しいデータを生成し、Log Analyticsワークスペース内の新しいテーブルに保存するため、データ保存に伴う追加料金は発生し得ます。(Microsoft Learn)
ここは現場で誤解が起きやすい箇所です。
「ライセンス追加なし」は「完全に無料」と同じではありません。UEBAによってBehaviorAnalytics、IdentityInfo、Anomaliesなどのテーブルにデータが蓄積されると、取り込み量や保持期間に応じたコスト管理が必要になります。
コスト管理で見るべき観点
| 観点 | 確認方法の例 |
|---|---|
| UEBA関連テーブルのデータ量 | Log AnalyticsでUsageテーブルや対象テーブルの件数を確認 |
| 保持期間 | Sentinelワークスペースの保持設定を確認 |
| データソース追加の影響 | 追加前後で取り込み量を比較 |
| マルチクラウドログ | AWS、GCP、Oktaなどのログ量が想定を超えていないか確認 |
| 検知価値 | 追加したログがインシデント調査やハンティングに実際に使われているか確認 |
最初から全ログを広く取り込むより、調査・検知に使うシナリオを決めてから段階的に有効化するほうが、費用対効果を評価しやすくなります。
UEBA EssentialsとBehaviors layerはどう使い分けるか
公式情報では、任意の追加ステップとしてUEBA Essentials solutionのインストールも紹介されています。これは、Microsoftのセキュリティ専門家が管理する事前構築済みハンティングクエリのコレクションで、Azure、AWS、GCP、Oktaなどを対象にしたマルチクラウドの異常検知クエリを含みます。(Microsoft Learn)
さらに、UEBA behaviors layerは、複数データソースから観測された活動を要約し、調査、ハンティング、検知のために分かりやすい行動情報へ変換する機能です。アラートや異常そのものではなく、「誰が、何を、誰に対して行ったか」を整理する抽象化レイヤーとして位置付けられています。(Microsoft Learn)
| 機能 | 目的 | 向いている使い方 |
|---|---|---|
| UEBA | ベースラインとの差分から異常行動を検出 | 侵害アカウント、内部不正、ラテラルムーブメントの兆候検出 |
| UEBA Essentials | 事前構築済みハンティングクエリを使う | UEBAデータを使った調査を早く始める |
| UEBA behaviors layer | 生ログを行動単位に要約する | 複数ログをまたぐ調査、検知ルール作成、MITRE ATT&CK文脈の付与 |
Behaviors layerを使う場合は、通常のUEBAとは別に有効化が必要です。また、サポートされるデータソースや制限は変わる可能性があるため、本番導入前に対象ログとワークスペースの条件を確認してください。公式情報では、Behaviors layerはサポートされるデータソースが接続され、Analytics tierにログが送信されている場合に行動を集約すると説明されています。(Microsoft Learn)
実務で失敗しやすいポイント
UEBAの導入では、設定ミスよりも「運用設計の不足」でつまずくケースが多くなります。
ログが足りないのに検知精度を期待してしまう
UEBAはログを分析する機能です。サインインログ、監査ログ、Azure Activity、Security Eventsなどが十分に入っていなければ、行動ベースラインも限定的になります。
まずは、どの攻撃シナリオを見たいのかを決めてください。たとえば「管理者アカウント侵害」を重視するなら、サインイン、監査ログ、Azure Activity、特権操作のログが必要です。
有効化後すぐに判断してしまう
UEBAは過去の行動と現在の活動を比較します。有効化直後は、十分なベースラインが形成されていない場合があります。
導入直後に「検知が少ないから不要」と判断せず、対象データソース、テーブル生成状況、異常検知の有効化、ログ量を確認してから評価しましょう。
スコアを絶対視してしまう
UEBAには、調査優先度や異常スコアの考え方があります。ただし、スコアが高いから必ず侵害、低いから安全とは限りません。Microsoft Learnでも、Investigation priority scoreとAnomaly scoreは用途が異なり、常に一致するわけではないと説明されています。(Microsoft Learn)
現場では、次のように使い分けると実務に落とし込みやすくなります。
| スコアや情報 | 使い方 |
|---|---|
| Investigation priority | 単一イベントの調査優先度を素早く判断 |
| Anomaly score | 複数イベントをまたぐ異常パターンの把握 |
| IdentityInfo | ユーザーやグループ、デバイスなどの文脈確認 |
| BehaviorAnalytics | 行動イベントの詳細調査 |
| Anomalies | 機械学習エンジンが検出した異常の確認 |
Azure portal前提の手順を残してしまう
2027年3月31日以降の運用を考えると、Azure portal前提の手順書、教育資料、運用フローを残したままにするのはリスクです。
特に、SOCの一次対応手順、インシデント調査手順、KQLの実行場所、データコネクタ設定手順は、Defenderポータル前提に更新しておきましょう。
展開時のおすすめ手順
本番環境にいきなり広く展開するのではなく、段階的に有効化して効果とコストを確認するのが安全です。
| フェーズ | 実施内容 | 成功条件 |
|---|---|---|
| 事前確認 | 権限、ワークスペース、データソース、ロック有無を確認 | UEBAを有効化できる状態になっている |
| 小規模有効化 | Entra ID、Signin Logs、Audit Logsなどから開始 | UEBA関連テーブルにデータが出る |
| 異常検知確認 | AnomaliesとDetect Anomaliesを確認 | 異常検知の結果を調査画面で追える |
| SOC連携 | インシデント対応手順にUEBA確認を組み込む | アナリストが調査時にUEBAデータを参照できる |
| 拡張 | AWS、GCP、Okta、Device Logon Eventsなどを追加 | 検知価値とコストのバランスが取れている |
| 定着化 | クエリ、ブック、検知ルール、教育資料を整備 | 継続運用できる状態になる |
導入時は、次のような簡単な運用ルールを決めておくと効果が出やすくなります。
| ルール | 例 |
|---|---|
| 調査対象 | 高権限ユーザー、サービスプリンシパル、外部アクセスユーザーを優先 |
| 確認頻度 | 週次でUEBA関連アラートと異常を確認 |
| エスカレーション条件 | 高リスクユーザー、普段と異なる国、特権操作の組み合わせを優先 |
| コスト確認 | 月次でUEBA関連テーブルのデータ量を確認 |
| 改善サイクル | ノイズが多い行動、見逃した行動をKQLやルールに反映 |
開発者・検知エンジニアが見るべきKQL活用ポイント
UEBAを有効化した後は、KQLで関連テーブルを活用できるかが重要です。特に、既存の検知ルールにUEBAの文脈を加えると、単純な条件一致よりも調査しやすいアラートになります。
たとえば、次のような観点でクエリを設計できます。
| 活用目的 | 見るテーブルの例 | 設計の考え方 |
|---|---|---|
| 不審なユーザー行動の確認 | BehaviorAnalytics | イベント単位の行動と優先度を見る |
| 異常パターンの確認 | Anomalies | 機械学習で検出された異常を見る |
| ユーザー属性の文脈化 | IdentityInfo | 部署、役割、グループなどの情報を補足 |
| ピアグループ比較 | UserPeerAnalytics | 同じ属性のユーザー群と比較 |
| 行動要約の活用 | BehaviorInfo、BehaviorEntities、SentinelBehaviorInfoなど | Behaviors layerを使う場合に行動単位で調査 |
既存の検知ルールにUEBAを加える場合は、「異常スコアが一定以上なら即アラート」のように単純化しすぎないほうが安全です。業務上の例外や一時的な作業も異常に見えることがあります。
実務では、次のように複数条件を組み合わせると扱いやすくなります。
| 条件の組み合わせ | 例 |
|---|---|
| 異常行動 + 高権限 | 管理者ユーザーが通常と異なる場所からAzure操作 |
| 異常行動 + 重要資産 | 重要サーバーへの初回アクセスや大量操作 |
| 異常行動 + 時間帯 | 深夜・休日の特権操作 |
| 異常行動 + 複数データソース | サインイン異常後にAWSやGCPで権限操作 |
| 異常行動 + インシデント文脈 | 既存インシデントに関係するユーザーの追加異常 |
導入前チェックリスト
UEBAを有効化する前に、次の項目を確認してください。
| チェック項目 | 確認 |
|---|---|
| Microsoft Defenderポータルで対象Sentinelワークスペースを管理できる | □ |
| 管理者に必要なMicrosoft Entra IDとAzure RBAC権限がある | □ |
| ワークスペースにAzure resource lockが設定されていない | □ |
| Signin Logs、Audit Logs、Azure Activityなど必要ログが接続されている | □ |
| オンプレADを使う場合、Microsoft Defender for IdentityとMDIセンサーを確認した | □ |
| UEBA有効化後にAnomaliesのDetect Anomaliesをオンにする手順を含めた | □ |
| UEBA関連テーブルのデータ量とコストを監視する方法を決めた | □ |
| SOCの調査手順にUEBA確認を組み込んだ | □ |
| Azure portal前提の手順をDefender portal前提へ更新した | □ |
| 2027年3月31日以降の運用方針を決めた | □ |
まとめ：まずはDefenderポータルでUEBAの有効化状態とログ接続を確認する
「Enable entity behavior analytics to detect advanced threats」で重要なのは、UEBAを単にオンにすることではありません。Microsoft Defenderポータル上でMicrosoft Sentinelのワークスペースを管理し、必要なデータソースを接続し、異常検知を有効化し、SOCの調査フローに組み込むことが本質です。
最初に取るべき行動は明確です。対象ワークスペースをDefenderポータルで開き、UEBA、データソース、Anomalies、権限、コスト監視の5点を確認してください。そのうえで、IDログから小さく始め、AWS、GCP、Okta、Device Logon Eventsなどの外部・端末系ログを段階的に追加すると、検知品質と運用負荷のバランスを取りやすくなります。
2027年3月31日以降のAzure portalサポート終了も踏まえると、今後のMicrosoft Sentinel運用はDefenderポータル中心で設計するのが現実的です。UEBAはその移行を進めるうえで、ID、端末、クラウド、インシデント調査をつなぐ重要な分析基盤になります。
コメント