Microsoft Sentinel の UEBA（User and Entity Behavior Analytics）を調べている管理者がまず押さえるべき結論は、2026年4月22日更新の公式ドキュメントでは、UEBAの有効化手順そのものだけでなく、Defender ポータル中心の運用、対応データソース、異常検知との連携、UEBA behaviors layer の位置付けをセットで確認すべき内容になっているという点です。
特に、security admins、identity teams、compliance teams は「UEBAをオンにするか」だけでなく、どのログを対象にするか、誰に権限を持たせるか、追加データ量をどう管理するか、2027年のDefenderポータル移行にどう備えるかまで含めて判断する必要があります。Microsoft公式の該当ページは、Microsoft Sentinel の UEBA が接続済みデータソースのログやアラートを分析し、ユーザー、ホスト、IPアドレス、アプリケーションなどのエンティティの行動ベースラインを作成し、機械学習で異常な活動を検出する機能だと説明しています。(Microsoft Learn)
Microsoft Sentinelの最新動向: Enable entity behavior analytics to detect advanced threatsで何が変わったか
2026年4月22日に更新された Microsoft Learn の「Enable entity behavior analytics to detect advanced threats」は、Microsoft Sentinel で UEBA を有効化するための実務向けガイドです。単なる機能紹介ではなく、現在の Microsoft Sentinel 運用で確認すべき重要点がいくつか整理されています。(Microsoft Learn)
大きなポイントは次の4つです。
| 更新ポイント | 実務上の意味 |
|---|---|
| Defender ポータルと Azure ポータルの両方に言及 | 現在の運用画面だけでなく、将来の移行計画も考える必要がある |
| UEBAの有効化方法が2系統で整理 | ワークスペース設定から有効化する方法と、対応データコネクタから有効化する方法を選べる |
| 対応データソースが明示 | Microsoft Entra ID、Azure Activity、Security Eventsに加え、AWS、GCP、Oktaなども確認対象になる |
| UEBA behaviors layerへの導線 | 異常検知だけでなく、行動の要約・文脈化を調査やハンティングに使う流れが強まっている |
ここで重要なのは、UEBAを「怪しいログインを見つける機能」と狭く捉えないことです。実際には、ID、端末、クラウド操作、オンプレミスAD、マルチクラウド環境のログを組み合わせ、SOCが調査しやすい文脈を作るための基盤として見るべきです。
UEBAは何を検出する機能なのか
Microsoft Sentinel の UEBA は、接続されたデータソースからログやアラートを取り込み、組織内のユーザーや端末などの通常行動を学習します。そのうえで、通常とは異なるサインイン、初めて使われるアプリ、珍しい国や地域からの接続、不自然な端末利用などを検出し、調査の優先順位付けに役立つ情報を付与します。(Microsoft Learn)
たとえば、次のような場面で効果を発揮します。
| シナリオ | UEBAで見たい観点 | 関係するチーム |
|---|---|---|
| 退職予定者のアカウントが深夜に大量アクセスしている | 通常と異なる時間帯、アクセス先、操作量 | security admins、compliance teams |
| 管理者アカウントが初めて特定の国からサインインした | 国・地域、ISP、端末、過去の利用傾向 | identity teams |
| サービスプリンシパルが普段と異なるAPI操作を行った | IDベースの操作傾向、クラウド操作ログ | cloud security teams |
| AWSやGCPの管理操作が急増した | マルチクラウド上の権限操作、監査ログ | SOC、platform teams |
| 休眠アカウントが突然利用された | dormant account、新規利用、権限の影響範囲 | identity teams、compliance teams |
UEBAの強みは、単一イベントだけを見て「危険」と判断するのではなく、そのユーザーや組織にとって珍しいかどうかを判断材料にできることです。たとえば、海外出張が多い営業担当者の海外サインインと、国内勤務の経理担当者の初めての海外サインインでは、同じイベントでもリスクの意味が変わります。
2026年4月更新で確認すべき有効化方法
公式ドキュメントでは、UEBAを有効化する方法として大きく2つが示されています。1つは Microsoft Sentinel のワークスペース設定から有効化する方法、もう1つは UEBA対応データコネクタの設定時に有効化する方法です。どちらも結果としてUEBAを有効化する点は同じです。(Microsoft Learn)
ワークスペース設定から有効化する
既存の Microsoft Sentinel 環境でUEBAをまとめて有効化したい場合は、ワークスペース設定から進めるのが分かりやすい方法です。
| 手順 | 作業内容 | 確認ポイント |
|---|---|---|
| 1 | Entity behavior configuration を開く | DefenderポータルまたはAzureポータルのどちらで操作するか確認 |
| 2 | Turn on UEBA feature をオンにする | 本番環境では変更管理の承認を取る |
| 3 | 同期するディレクトリサービスを選択 | Microsoft Entra ID、オンプレミスADの扱いを確認 |
| 4 | 対象データソースを選択 | 全接続か、特定データソースのみかを決める |
| 5 | Connect を選択 | 対象ログの取り込み状況を確認 |
| 6 | 必要に応じてAnomaliesを有効化 | 異常検知を使う場合は Detect Anomalies をオンにする |
オンプレミス Active Directory のユーザーエンティティを同期する場合は、Microsoft Defender for Identity へのオンボードと、Active Directory ドメインコントローラーへの MDI センサー導入が必要です。これは identity teams が必ず関与すべきポイントです。(Microsoft Learn)
対応データコネクタから有効化する
新たにデータコネクタを追加する場合は、Microsoft Defender ポータルのデータコネクタ画面からUEBAを有効化できます。公式ドキュメントでは、Microsoft Sentinel > Configuration > Data connectors から対象コネクタを選び、Advanced options の Configure UEBA で対象テーブルを有効化する流れが示されています。(Microsoft Learn)
この方法は、AWS CloudTrail、GCP Audit Logs、Oktaなどを段階的に追加している組織に向いています。グローバル企業では、地域や事業部ごとにクラウド利用状況が異なるため、すべてのデータソースを一度に有効化するより、重要度の高いログから順に有効化したほうが運用負荷を抑えやすくなります。
対象データソースの見直しが重要
2026年4月時点の公式情報では、DefenderポータルとAzureポータルの両方から有効化できるUEBA対象データソースとして、Signin Logs、Audit Logs、Azure Activity、Security Events が示されています。一方、Defenderポータルのみで有効化できるプレビュー扱いのデータソースとして、AAD Managed Identity Signin logs、AAD Service Principal Signin logs、AWS CloudTrail、Device Logon Events、Okta CL、GCP Audit Logs が挙げられています。(Microsoft Learn)
| データソース | 優先度が高い組織 | 見落としやすいポイント |
|---|---|---|
| Signin Logs | Microsoft Entra IDを使うほぼすべての組織 | 条件付きアクセスのイベントと併せて確認する |
| Audit Logs | ID管理変更を監査したい組織 | 管理者ロール変更、アプリ登録変更を見逃さない |
| Azure Activity | Azureリソース運用が多い組織 | Key Vault、Compute、Network関連の操作に注意 |
| Security Events | Windowsサーバーや端末ログを重視する組織 | 4624、4625、4672、4688などのイベント品質を確認 |
| AWS CloudTrail | AWSを併用するグローバル企業 | ConsoleLoginやIAM操作の文脈を確認 |
| GCP Audit Logs | GCPを併用する組織 | PrincipalEmailやMethodNameが適切に入っているか確認 |
| Okta CL | OktaをID基盤に使う組織 | MFA、セッション、なりすまし関連イベントに注意 |
| Device Logon Events | Defender XDR連携を使う組織 | 端末ログオンとIDイベントを関連付ける |
実務では、データソースの数を増やすだけでは不十分です。UEBAが使えるログでも、必要なフィールドが欠けていたり、取り込みが不安定だったりすると、期待した分析結果が出ません。最初に確認すべきなのは「接続済みか」ではなく、分析に必要なイベントが継続的に届いているかです。
権限とロック設定でつまずきやすい
UEBAの有効化には、Microsoft Entra ID の Security Administrator ロールまたは同等の権限に加え、Azure側でも必要なRBACが求められます。公式ドキュメントでは、Owner、Contributor、または最小権限の構成として Microsoft Sentinel Contributor と Log Analytics Contributor の組み合わせが示されています。また、対象ワークスペースに Azure resource lock が設定されていないことも前提です。(Microsoft Learn)
| つまずきやすい点 | 起きる問題 | 対策 |
|---|---|---|
| Entra ID側の権限だけを確認している | Sentinel側の設定変更ができない | Entra IDロールとAzure RBACを両方確認する |
| 最小権限の設計が曖昧 | 管理者権限を広く付与しすぎる | Sentinel Contributor + Log Analytics Contributor を基本候補にする |
| リソースロックが残っている | 設定変更が反映できない | 変更前にワークスペースのロックを確認する |
| 運用チームとIDチームが分断されている | ディレクトリ同期やMDI要件で止まる | 事前に責任分界点を決める |
compliance teams にとっては、誰がUEBAを有効化・無効化できるかも監査対象になります。設定作業者、承認者、変更日時、対象ワークスペース、対象データソースは、変更管理チケットや監査ログで追跡できるようにしておくべきです。
コストは「機能料金なし」でもデータ量に注意
UEBA機能そのものに特別なライセンスは不要で、追加の機能料金もありません。ただし、UEBAが新しいデータを生成し、Log Analyticsワークスペース内の新しいテーブルに保存するため、追加のデータ保存料金が発生する可能性があります。(Microsoft Learn)
この点は、導入時に誤解されやすいポイントです。「UEBAは無料で使える」とだけ説明すると、後からログ量や保存期間に関する費用で問題になります。
導入前に、次の3点を確認してください。
| 確認項目 | 判断基準 |
|---|---|
| 対象データソース | 全ソースを有効化するか、重要なID・管理操作ログから始めるか |
| 保存期間 | 調査・監査に必要な保持期間とコストのバランス |
| 生成テーブル | UEBAの出力データがどのテーブルに保存されるか |
| 検証期間 | 本番全体ではなく、代表ワークスペースでデータ増加量を見る |
最初から全データソースを有効化するより、Signin Logs、Audit Logs、Azure Activityなど基盤となるログを優先し、その後AWS、GCP、Oktaなどを追加するほうが、費用と検出品質を管理しやすくなります。
UEBA behaviors layerは「アラート」ではなく調査文脈を作る機能
2026年4月更新の文脈で特に注目したいのが、UEBA behaviors layer への導線です。公式ドキュメントでは、UEBA behaviors layer は複数データソースで観測されたアクティビティを要約し、調査、ハンティング、検出に使いやすい抽象レイヤーを作るものと説明されています。アラートや異常そのものではなく、必ずしもリスクを示すわけではない点が重要です。(Microsoft Learn)
別の公式ページでは、behaviors layer が大量の生ログを「誰が、何を、誰に対して行ったか」という構造化された行動パターンに変換し、MITRE ATT&CK のマッピングやエンティティの役割情報を付与すると説明されています。(Microsoft Learn)
| 項目 | Anomalies | Alerts | Behaviors |
|---|---|---|---|
| 役割 | ベースラインから外れた活動を示す | 対応が必要な可能性のあるセキュリティシグナル | 通常・異常を問わず行動を構造化して要約 |
| 主な用途 | 異常の発見 | インシデント対応 | 調査、ハンティング、相関分析 |
| SOCでの使い方 | 優先度付けの材料 | 対応開始のトリガー | タイムライン理解、相関ルール、調査効率化 |
| 注意点 | すべてが侵害とは限らない | 誤検知調整が必要 | 単独でリスク判定しない |
たとえば、AWSのアクセスキー作成後に通常と異なるIPアドレスから利用され、さらに特権APIが呼び出された場合、生ログだけで追うには複数テーブルの結合や時系列整理が必要です。behaviors layer を使うと、こうした一連の活動を調査しやすい単位で扱えるため、SOCアナリストや検出エンジニアの作業負荷を下げやすくなります。
なお、UEBA behaviors layer は、AWSCloudTrail、GCPAuditLogs、CommonSecurityLogなどの対応データソースをもとに行動レコードを生成しますが、対象ソースは他のUEBA機能とは別に有効化する必要があります。公式情報では、たとえばAWSCloudTrailをUEBA analyticsやanomalies向けに有効化していても、behaviors向けには別途有効化が必要だと説明されています。(Microsoft Learn)
Azureポータル利用組織は2027年3月31日も見据える
Microsoft Sentinel は Defender ポータルで一般提供されており、Microsoft公式情報では、2027年3月31日以降、AzureポータルでのMicrosoft Sentinelはサポートされず、Defenderポータルのみで利用可能になると案内されています。(Microsoft Learn)
このため、UEBAの有効化を今から検討する組織は、Azureポータル前提の手順書だけを整備するのではなく、Defenderポータルでの操作手順、権限、監査、教育まで含めて準備する必要があります。
特にグローバル組織では、地域ごとにSOC運用が異なることがあります。日本拠点はAzureポータル、海外SOCはDefenderポータルという状態が続くと、インシデント対応時に画面遷移や用語の違いで混乱します。2026年中に、少なくともUEBA、Data connectors、Analytics、Hunting、Incidents の主要操作はDefenderポータル基準で標準化しておくと安全です。
security admins、identity teams、compliance teams別の確認ポイント
UEBA導入は、SOCだけの作業ではありません。関係チームごとに見るべきポイントが異なります。
| チーム | 主な関心 | 具体的な確認事項 |
|---|---|---|
| security admins | 検出品質、調査効率、誤検知 | 対象データソース、Anomalies、UEBA Essentials、ハンティングクエリ |
| identity teams | IDリスク、権限、ディレクトリ同期 | Microsoft Entra ID、オンプレAD、Defender for Identity、特権ID |
| compliance teams | 監査、データ保持、説明責任 | 変更管理、保存期間、アクセス権、調査証跡 |
| cloud platform teams | Azure/AWS/GCPの操作監視 | Azure Activity、AWS CloudTrail、GCP Audit Logs |
| SOC analysts | インシデント調査 | BehaviorAnalytics、IdentityInfo、BehaviorInfo、BehaviorEntities |
UEBAの導入判断では、「検出できること」だけでなく「検出後に誰が何をするか」まで決めることが重要です。たとえば、InvestigationPriority が高いイベントを見つけても、identity teams がアカウント停止やパスワードリセットを実行する手順がなければ、検出価値は半減します。
導入前に決めておくべき運用ルール
Microsoft Sentinel の UEBA を有効化する前に、次のルールを決めておくと運用が安定します。
| 決めること | 推奨される考え方 |
|---|---|
| 最初に有効化するログ | Signin Logs、Audit Logs、Azure ActivityなどIDと管理操作を優先 |
| 本番適用の順序 | 検証ワークスペース、代表部門、本番全体の順に展開 |
| 調査優先度 | 高権限ユーザー、休眠アカウント、新規アカウント、外部IPを優先 |
| 通知ルール | すべてをアラート化せず、重要イベントだけ通知 |
| コスト確認 | 有効化前後でデータ量と保存コストを比較 |
| 例外管理 | 出張、運用代行、定期バッチなど通常と異なる正当な活動を記録 |
失敗しやすいのは、UEBAを有効化した直後にすべての異常をアラート化してしまうケースです。最初の数週間は、検出結果を観察し、業務上正当なパターンと本当に調査すべきパターンを分ける期間として扱うほうが現実的です。
すぐに使える確認用KQL例
UEBAの有効化後は、出力データが実際に生成されているかを確認します。Microsoft Sentinel のUEBA出力では、BehaviorAnalytics テーブルに行動分析データが保存され、IdentityInfo テーブルには Microsoft Entra ID やオンプレミスADから同期されたID情報が保存されます。(Microsoft Learn)
直近24時間のUEBAイベントを確認する
BehaviorAnalytics
| where TimeGenerated >= ago(24h)
| project TimeGenerated, UserPrincipalName, ActivityType, ActionType, SourceIPAddress, InvestigationPriority
| order by TimeGenerated desc調査優先度が高いイベントを見る
BehaviorAnalytics
| where TimeGenerated >= ago(7d)
| where InvestigationPriority >= 7
| project TimeGenerated, UserPrincipalName, ActivityType, ActionType, SourceIPAddress, SourceIPLocation, InvestigationPriority
| order by InvestigationPriority desc, TimeGenerated desc休眠アカウントや新規アカウントの活動を探す
BehaviorAnalytics
| where TimeGenerated >= ago(7d)
| extend UsersInsightsJson = parse_json(UsersInsights)
| where UsersInsightsJson.IsDormantAccount == true or UsersInsightsJson.IsNewAccount == true
| project TimeGenerated, UserPrincipalName, ActivityType, ActionType, UsersInsightsJson, InvestigationPriority
| order by TimeGenerated descこれらのクエリは、そのまま検出ルールにするというより、まずは「どのようなデータが出ているか」「自社で意味のある優先度はどこからか」を確認するために使うのが適しています。
UEBA Essentials solutionも検討する
公式ドキュメントでは、UEBA Essentials solution を任意でインストールできることも案内されています。これは Microsoft のセキュリティ専門家が管理する事前構築済みのハンティングクエリ群で、Azure、AWS、GCP、Oktaをまたぐマルチクラウドの異常検知クエリを含むと説明されています。(Microsoft Learn)
自社で最初からハンティングクエリを作り込む余力がない場合は、UEBA Essentials を起点にすると導入が早くなります。ただし、事前構築済みクエリをそのまま本番アラートに使うのではなく、自社の通常業務、管理者運用、海外拠点、委託先アクセスを踏まえて調整してください。
2026年4月更新を踏まえた実務アクション
今回の更新ポイントを踏まえると、Microsoft Sentinel の UEBA 導入・見直しで次に取るべき行動は明確です。
まず、現在のワークスペースでUEBAが有効か、どのデータソースが対象かを確認します。次に、Signin Logs、Audit Logs、Azure Activity、Security Events など基盤ログの品質を点検します。AWS、GCP、Okta、サービスプリンシパル、マネージドIDを使っている組織では、Defenderポータル側でプレビュー扱いの対応データソースも評価対象に入れます。
そのうえで、次の順番で進めると失敗しにくくなります。
| 順序 | やること | ゴール |
|---|---|---|
| 1 | 現在のSentinelワークスペースとポータル運用を棚卸し | Azureポータル依存を把握する |
| 2 | UEBAに必要な権限とリソースロックを確認 | 有効化時の権限エラーを防ぐ |
| 3 | 重要データソースからUEBAを有効化 | IDと管理操作の可視性を高める |
| 4 | データ量とコストを確認 | 想定外の保存・取り込みコストを避ける |
| 5 | AnomaliesとUEBA Essentialsを評価 | 調査・ハンティングの初期効果を出す |
| 6 | behaviors layerを検証 | マルチクラウド調査や相関分析に活用する |
| 7 | Defenderポータル前提の手順書へ更新 | 2027年以降の運用に備える |
Microsoft Sentinel の UEBA は、オンにするだけで高度な脅威を完全に検出できる魔法の機能ではありません。しかし、適切なログ、権限設計、コスト管理、調査手順と組み合わせれば、ID侵害、クラウド権限の悪用、通常とは異なるユーザー行動を早期に見つけるための強力な基盤になります。
2026年4月更新の公式ドキュメントを読む際は、「設定手順」だけで終わらせず、Defenderポータル移行、マルチクラウド対応、UEBA behaviors layer、調査運用、コンプライアンス証跡まで含めて見直すことが重要です。まずは既存ワークスペースで対象データソースと権限を確認し、代表的なワークスペースでUEBAの出力とコストを検証するところから始めてください。
コメント