Microsoft Sentinel UEBAの2026年4月更新でまず押さえるべき点は、UEBAを「怪しいユーザーを見つける機能」として単体で見るのではなく、Defenderポータルでの調査、UEBA関連テーブル、Anomalies、UEBA behaviors layer、UEBA Essentialsを組み合わせて運用する機能群として捉えることです。
2026年4月22日に更新されたMicrosoft公式記事「Advanced threat detection with User and Entity Behavior Analytics (UEBA) in Microsoft Sentinel」では、UEBAがユーザー、ホスト、IPアドレス、アプリケーションなどの通常行動を学習し、普段と異なる動きをリスクスコア付きで検出する仕組みが整理されています。特に、セキュリティ管理者、IDチーム、コンプライアンス担当者は、検知精度だけでなく「どのデータを入れるか」「どのスコアを見るか」「誰が調査に使うか」まで見直すべき更新内容です。(Microsoft Learn)
Microsoft Sentinel UEBAの2026年4月更新で押さえるべき全体像
今回の更新ポイントは、単なる機能説明の追加ではありません。Microsoft Sentinel UEBAを、SOCの検知・調査・ハンティングに組み込むための実務ガイドとして読み替える必要があります。
| 更新ポイント | 実務上の意味 | まず取るべき対応 |
|---|---|---|
| UEBAの対象エンティティが明確化 | ユーザーだけでなく、ホスト、IP、アプリケーションなども行動分析の対象になる | IDログだけでなく、端末・クラウド・認証ログの接続状況を確認する |
| Defenderポータルでの調査体験が強調 | ユーザーページ、インシデントグラフ、Advanced HuntingからUEBAを使いやすくなる | SOC手順書をDefenderポータル前提に更新する |
BehaviorAnalyticsとAnomaliesの使い分けが重要に | 単一イベントの優先度と、複数イベントをまたぐ異常度を分けて判断する | スコアの意味をアナリストに周知する |
| UEBA Essentials solutionが導入ルートとして有効 | Azure、AWS、GCP、Oktaなどのハンティングを短期間で始めやすい | 自作クエリの前にMicrosoft提供コンテンツを評価する |
| UEBA behaviors layerが調査文脈を補強 | 生ログを「誰が、何を、誰にしたか」という行動単位で整理できる | Preview機能として制限とコストを確認してから有効化する |
Microsoft公式記事では、UEBAが機械学習で動的な行動プロファイルを作り、過去の本人行動、ピアグループ、組織全体のパターンとの差分をもとに異常を検出すると説明されています。つまり、固定ルールだけでは見逃しやすい「いつもと違うが、単独では判断しにくい動き」を優先順位付きで見つけるのがUEBAの役割です。(Microsoft Learn)
UEBAは何を検知するのか
Microsoft Sentinel UEBAは、組織内の通常行動をベースライン化し、そのベースラインから外れた活動を検出します。たとえば、次のようなケースで効果を発揮します。
- 普段は日本からサインインする管理者が、初めての国や端末から高権限操作を実行した
- 休眠気味のアカウントが突然クラウドリソースを大量に操作した
- 通常業務ではAWSやGCPを触らないユーザーが、クラウド権限や認証設定を変更した
- MFA関連の変更、パスワードリセット、特権付与などが通常とは異なるタイミングで発生した
- 同じ部署の他ユーザーと比べて、明らかに異なるアクセスパターンを示した
公式記事では、UEBAが侵害されたアカウント、内部不正、ラテラルムーブメントなどの検出支援に使えると説明されています。ただし、UEBAは「悪意」を直接断定するものではありません。あくまで、通常と異なる行動を優先度付きで提示し、アナリストが調査すべき対象を絞り込むための機能です。(Microsoft Learn)
更新ポイント：Defenderポータルでの調査がより重要になる
2026年4月更新版で特に目立つのは、Microsoft Defenderポータル内でUEBAを使う体験が具体化されている点です。公式記事では、Defenderポータルのホームページウィジェット、ユーザーページのUEBAコンテキスト、インシデントグラフからの組み込みクエリ、Advanced HuntingでのAnomaliesテーブル連携が説明されています。(Microsoft Learn)
実務では、次のようにSOC手順を変えると効果が出やすくなります。
| 調査場面 | 従来のありがちな対応 | UEBAを使った対応 |
|---|---|---|
| アラート初動 | アラート名と重大度だけで判断する | 関連ユーザーのUEBA異常、直近30日のTop UEBA anomalies、タイムラインを確認する |
| アカウント侵害調査 | サインインログだけを見る | BehaviorAnalytics、Anomalies、ユーザーエンティティページを横断する |
| 高権限ユーザー調査 | 管理者操作ログを個別に検索する | ピアグループとの差分、初回操作、通常と異なる場所や端末を確認する |
| ハンティング | 生ログのスキーマごとにKQLを書く | UEBA関連テーブルや組み込みクエリから調査を始める |
さらに、Microsoftは2027年3月31日以降、Microsoft SentinelをAzureポータルではサポートせず、Microsoft Defenderポータルでのみ利用可能にする方針を示しています。まだAzureポータル中心で運用している組織は、UEBAの更新を機に、調査手順、画面キャプチャ付きの教育資料、RBAC設計をDefenderポータル前提に見直すべきです。(Microsoft Learn)
InvestigationPriorityとAnomaly scoreを混同しない
UEBA運用で失敗しやすいのが、スコアを1種類の危険度として扱ってしまうことです。公式記事では、BehaviorAnalyticsのInvestigationPriorityと、Anomalies側のAnomaly scoreが別の目的を持つと整理されています。(Microsoft Learn)
| 比較項目 | InvestigationPriority | Anomaly score |
|---|---|---|
| 主に見るテーブル | BehaviorAnalytics | Anomalies |
| スコア範囲 | 0〜10 | 0〜1 |
| 向いている用途 | 単一イベントの優先順位付け、初動トリアージ | 複数イベントをまたぐ異常傾向の把握 |
| 処理の考え方 | イベントレベル、比較的即時性のある判断 | 機械学習による集約的な異常検出 |
| 調査での使い方 | 「今すぐ見るべきイベント」を絞る | 「一定期間で異常な行動パターン」を見つける |
たとえば、あるユーザーが初めてAzure操作を実行した場合、InvestigationPriorityは高くなることがあります。しかし、その操作が組織全体では珍しくない通常業務の範囲であれば、Anomaly scoreは低くなる可能性があります。高スコアだから即インシデント、低スコアだから無視、という判断は避けるべきです。(Microsoft Learn)
初動トリアージに使えるKQL例
まずは、直近24時間で調査優先度の高い行動を確認します。
BehaviorAnalytics
| where TimeGenerated >= ago(24h)
| where InvestigationPriority >= 7
| project TimeGenerated, UserPrincipalName, ActivityType, ActionType, SourceIPAddress, SourceIPLocation, InvestigationPriority
| order by InvestigationPriority descBehaviorAnalyticsには、アクション種別、ユーザー、送信元IP、地理情報、InvestigationPriorityなど、UEBAでエンリッチされたイベント情報が格納されます。高優先度のイベントを見つけたら、同じユーザーのサインイン履歴、端末情報、権限変更、関連インシデントを確認します。(Microsoft Learn)
次に、一定期間の異常傾向を見ます。
Anomalies
| where TimeGenerated >= ago(7d)
| where Score >= 0.7
| project TimeGenerated, RuleName, Score, UserPrincipalName, SourceIpAddress, Tactics, Techniques, Description
| order by Score descAnomaliesテーブルには、生成された異常、ルール名、スコア、MITRE ATT&CKの戦術・技術、関連ユーザーなどが格納されます。単発イベントの確認ではなく、複数の異常が同じユーザー、端末、クラウドリソースに集中していないかを見るのがポイントです。(Microsoft Learn)
UEBA関連テーブルは役割で使い分ける
Microsoft Sentinel UEBAでは、複数のテーブルに情報が分散します。どのテーブルを見るべきかを理解していないと、アラートは出ているのに調査が進まない、または生ログだけを追って時間を浪費する原因になります。
| テーブル | 主な役割 | 実務での使いどころ |
|---|---|---|
IdentityInfo | ユーザー、デバイス、グループなどのエンティティ情報 | 調査対象ユーザーの属性、所属、ID情報を確認する |
BehaviorAnalytics | UEBAでエンリッチされた行動イベント | 高優先度イベントの初動調査、行動の文脈確認 |
UserPeerAnalytics | ピアグループ分析 | 同じ部署・近い属性のユーザーと比べて異常かを見る |
Anomalies | 異常として検出されたイベント | 異常検知ルール、スコア、MITRE ATT&CK観点で分析する |
SentinelBehaviorInfo | 生ログから要約された行動情報 | UEBA behaviors layerを有効化した場合の行動単位の調査 |
SentinelBehaviorEntities | 行動に関係するエンティティ情報 | 誰が、何に対して、どの役割で関与したかを確認する |
公式記事では、SentinelBehaviorInfoとSentinelBehaviorEntitiesはUEBA behaviors layerを有効化した場合に作成されるテーブルであり、通常のUEBAとは独立して有効化する機能だと説明されています。導入済みか分からない場合は、まずワークスペースに該当テーブルが存在するか、UEBA behaviors layerが有効化されているかを確認してください。(Microsoft Learn)
UEBA Essentials solutionは自作前に評価する
UEBAを導入した組織が陥りやすいのは、「まず自社専用のKQLを全部作る」という進め方です。もちろん独自ルールは必要ですが、初期段階ではMicrosoftが提供するUEBA Essentials solutionを評価するほうが早く、抜け漏れも減らせます。
公式記事では、UEBA Essentials solutionはMicrosoftのセキュリティ専門家が管理する事前構築済みハンティングクエリの集合であり、Azure、AWS、GCP、Oktaを含むマルチクラウドの異常検出クエリを含むと説明されています。(Microsoft Learn)
特に、次のような環境ではUEBA Essentials solutionを優先的に確認する価値があります。
| 環境 | 評価すべき理由 |
|---|---|
| Entra ID中心のクラウドID環境 | サインイン、監査ログ、特権操作をUEBAで関連付けやすい |
| AWSやGCPを併用している環境 | クラウドごとに分断された操作を、異常行動として横断的に見やすい |
| Oktaを利用している環境 | MFA、セッション、管理操作の異常を検知シナリオに組み込みやすい |
| SOC要員が少ない環境 | 自作クエリだけに依存せず、初期検知パターンを短期間で整備できる |
ただし、UEBA Essentials solutionを入れただけで検知運用が完成するわけではありません。対象データソースが接続されていない、ログ量が少ない、ID属性が不足している、アナリストがスコアの意味を理解していない場合、期待した効果は出にくくなります。
UEBA behaviors layerは「異常検知」ではなく「調査文脈」を作る
今回の更新で特に注目したいのが、UEBA behaviors layerです。これは大量の生ログを集約し、「誰が、何を、誰にしたか」を平易な行動情報として整理する機能です。公式ドキュメントでは、効率、明確さ、文脈、統一スキーマの観点で調査やハンティングを支援すると説明されています。(Microsoft Learn)
重要なのは、behaviorsは必ずしもリスクを示すものではないという点です。アラートや異常検知の代替ではなく、生ログとアラートの間にある「調査しやすい行動の要約」として使います。
| 比較項目 | Anomalies | Alerts | Behaviors |
|---|---|---|---|
| 表すもの | 通常行動から外れたパターン | 対応が必要な可能性のあるセキュリティ信号 | 正常・異常を問わない構造化された行動要約 |
| 主な目的 | 怪しい行動を発見する | インシデント対応を開始する | 調査、ハンティング、検知作成の文脈を補う |
| 実務での使い方 | スコアやMITRE観点で優先順位付け | SOCの対応キューに乗せる | 生ログを読む前に行動の全体像をつかむ |
UEBA behaviors layerを使うと、たとえばAWS CloudTrailやCommonSecurityLogのようにボリュームが多いログでも、関連するイベントをまとめて行動単位で確認しやすくなります。Microsoftの例では、ハンターがMITRE戦術、技術、タイトル、エンティティなどでBehaviorInfoを検索し、複雑なjoinやデータソースごとのスキーマ理解に依存しすぎずに調査できるとされています。(Microsoft Learn)
DefenderポータルとSentinelワークスペースで見るテーブルが違う
UEBA behaviors layerを使う際は、どこでクエリを書くかによって参照するテーブルが変わります。
| 利用場所 | 使うテーブル | 主な用途 |
|---|---|---|
| DefenderポータルのAdvanced Hunting | BehaviorInfo、BehaviorEntities | 検知ルール、インシデント調査、脅威ハンティング |
| Sentinelワークスペース | SentinelBehaviorInfo、SentinelBehaviorEntities | Azure Monitorブック、取り込み監視、ワークスペース内KQL |
DefenderポータルのBehaviorInfoとBehaviorEntitiesには、Microsoft Sentinel UEBA behaviorsだけでなく、接続されたMicrosoft Defenderサービス由来のbehaviorが含まれる場合があります。Sentinel由来に絞る場合は、ServiceSource == "Microsoft Sentinel"のような条件を使います。(Microsoft Learn)
BehaviorInfo
| where ServiceSource == "Microsoft Sentinel"
| where TimeGenerated >= ago(24h)
| project TimeGenerated, Title, Description, Categories, AttackTechniques, ServiceSource
| order by TimeGenerated descワークブックやSentinelワークスペース上のKQLでは、SentinelBehaviorInfoとSentinelBehaviorEntitiesを使う設計にしておくと、ポータル間の混同を避けやすくなります。(Microsoft Learn)
有効化前に確認すべき前提条件
Microsoft Sentinel UEBAを有効化する前に、権限、データソース、コスト、ポータル移行方針を確認しておく必要があります。
| 確認項目 | チェック内容 |
|---|---|
| 権限 | Microsoft Entra IDのSecurity Administrator相当、または必要なAzure RBACが割り当てられているか |
| ワークスペース | 対象ワークスペースにAzureリソースロックがかかっていないか |
| データソース | Microsoft Entra ID、Defender for Identity、Office 365、Azure Activity、Security Eventsなど必要なログが接続されているか |
| Anomaly detection | UEBAだけでなく、Anomaliesの検出設定も有効化しているか |
| コスト | 機能自体の追加ライセンス有無だけでなく、Log Analyticsへの追加データ保存・取り込みコストを見積もっているか |
| ポータル戦略 | 2027年3月31日以降のDefenderポータル移行を前提に運用手順を整備しているか |
公式の有効化手順では、UEBAはワークスペース設定から有効化する方法と、対応データコネクタの設定時に有効化する方法があります。また、UEBA機能に特別なライセンスは不要とされていますが、UEBAが生成するデータはLog Analyticsワークスペース内のテーブルに保存されるため、追加のデータ保存料金が発生し得ます。(Microsoft Learn)
データソース選定ではIDチームの関与が不可欠
UEBAはセキュリティ管理者だけで完結する機能ではありません。特にIDチームの関与が重要です。Microsoft Sentinel UEBAは、Microsoft Entra ID、オンプレミスActive Directory、Defender for Identity、サインインログ、監査ログ、クラウド操作ログなどの情報を使って、ユーザーやエンティティの文脈を補強します。(Microsoft Learn)
IDチームが確認すべきポイントは次の通りです。
| 観点 | 確認ポイント |
|---|---|
| ユーザー属性 | 部署、役職、マネージャー、グループ情報が古くないか |
| 特権アカウント | グローバル管理者、セキュリティ管理者、クラウド管理者の棚卸しができているか |
| サービスプリンシパル | 人間ユーザーだけでなく、非人間IDのサインインや操作を把握できているか |
| オンプレミス連携 | Defender for IdentityやAD連携が必要な範囲で構成されているか |
| 例外運用 | ブレークグラスアカウント、運用代行アカウント、共有アカウントの扱いを決めているか |
UEBAの精度は、入力されるデータとエンティティ情報の品質に左右されます。ID属性が古い、特権アカウントが共有されている、例外アカウントの利用ルールが曖昧、といった状態では、UEBAが示す「いつもと違う行動」の意味を正しく判断しにくくなります。
コンプライアンスチームが見るべきポイント
コンプライアンスチームにとって、UEBAは単なる検知機能ではなく、説明責任を支える材料にもなります。たとえば、特権アカウントの異常操作、アカウント作成、権限付与、データ削除、クラウドストレージからの不自然なデータ転送などは、セキュリティ監査や内部統制の観点でも確認対象になります。
関連するAnomaliesリファレンスでは、UEBAがアカウント作成、アカウント削除、アカウント操作、GCP Audit Logs、Okta、認証、データ破壊、Amazon S3からのデータ転送、特権付与など多様な異常ルールを扱うことが示されています。(Microsoft Learn)
ただし、コンプライアンス用途で使う場合は、次の点を明確にしておくべきです。
- UEBAのスコアは法的な不正認定ではなく、調査優先度の補助情報である
- 調査ログ、インシデント記録、承認フローを別途残す
- 個人情報や従業員監視に関わる社内規程を確認する
- グローバル拠点では、地域ごとのデータ保護要件に合わせてログ保持やアクセス権を設計する
- 検知できなかったことをもって「問題がなかった」とは判断しない
特にUEBA behaviors layerには制限があります。Microsoftは、behaviors layerは1テナントにつき単一のSentinelワークスペースで有効化できること、対応データソースやカバーする行動タイプが限定的であること、behaviorがないからといって活動がなかったとは限らないことを明記しています。(Microsoft Learn)
失敗しやすいポイントと対策
Microsoft Sentinel UEBAは強力ですが、導入直後から自動的に最適運用になるわけではありません。よくある失敗は次の通りです。
| 失敗しやすいポイント | なぜ問題か | 対策 |
|---|---|---|
| UEBAを有効化しただけで満足する | 必要なデータソースが接続されていないと検知範囲が狭い | 対象ログとUEBA対応データソースを一覧化する |
| Anomaliesを有効化していない | UEBA異常を十分に活用できない | UEBA設定とAnomalies設定をセットで確認する |
| スコアを絶対的な危険度として扱う | 業務上の初回操作や例外作業で誤判断しやすい | InvestigationPriorityとScoreを分けて教育する |
| 生ログを見ずにbehaviorだけで判断する | behaviors layerはすべての行動を網羅しない | 重要インシデントでは必ず元ログへドリルダウンする |
| コストを見積もらない | UEBA関連データの保存・取り込みで費用が増える可能性がある | Usageテーブルや請求情報で増加分を監視する |
| Azureポータル前提の手順を残す | 2027年以降の運用移行で混乱する | Defenderポータル前提の手順書に更新する |
また、関連するAnomaliesドキュメントでは、DGA関連の一部異常検知が2026年3月8日時点で結果品質を理由に廃止されたことも示されています。これは、異常検知のカバレッジが固定ではなく、品質や運用上の判断によって変わり得ることを示す重要な例です。(Microsoft Learn)
部門別に取るべき次のアクション
セキュリティ管理者
まず、対象ワークスペースでUEBA、Anomalies、主要データソースが有効かを確認します。次に、UEBA Essentials solutionを導入または評価し、既存の分析ルールやハンティングクエリと重複・補完関係を整理します。
優先すべき作業は次の通りです。
- Microsoft DefenderポータルでUEBAウィジェットとユーザー調査画面を確認する
BehaviorAnalyticsで高InvestigationPriorityのイベントを定期確認するAnomaliesで高Scoreの異常を週次レビューする- UEBA Essentials solutionのクエリを自社環境向けに調整する
- 2027年のDefenderポータル移行に向け、SOC手順書を更新する
IDチーム
IDチームは、UEBAの入力品質を支える役割を担います。Microsoft Entra IDのユーザー属性、グループ、特権ロール、サービスプリンシパル、条件付きアクセス、Defender for Identity連携などを確認してください。
特に、特権ユーザーと非人間IDの棚卸しは優先度が高い作業です。UEBAが異常を出しても、アカウントの所有者や利用目的が不明では調査が止まります。
コンプライアンスチーム
コンプライアンスチームは、UEBAの検知結果を監査や内部統制の文脈でどう扱うかを決める必要があります。特権操作、アカウント作成、権限変更、データ削除、クラウドストレージアクセスなどは、監査対象イベントとして整理しておくとよいでしょう。
ただし、UEBAスコアだけで違反や不正を断定しないことが重要です。調査ログ、承認記録、変更管理、インシデント対応記録と組み合わせて判断してください。
まとめ：2026年4月更新後のUEBAは「検知」より「運用設計」が重要
Microsoft Sentinel UEBAの2026年4月更新ポイントは、UEBAを単なる異常検知機能としてではなく、Defenderポータル、UEBA関連テーブル、Anomalies、UEBA Essentials、UEBA behaviors layerを組み合わせた運用基盤として見ることです。
最初に行うべきことは、次の5つです。
- UEBAとAnomaliesが対象ワークスペースで有効か確認する
- Microsoft Entra ID、Defender for Identity、Office 365、クラウドログなど必要なデータソースを確認する
InvestigationPriorityとScoreの違いをSOC内で共有する- UEBA Essentials solutionを評価し、自作クエリだけに依存しない初期運用を作る
- Defenderポータル前提の調査手順に更新する
UEBAは、導入した瞬間にすべてを検知する魔法の機能ではありません。しかし、ID情報、クラウド操作ログ、端末ログ、ピアグループ分析、MITRE ATT&CK文脈を組み合わせれば、従来のルールベース検知では見えにくかったアカウント侵害や内部不正の兆候を早く見つけやすくなります。2026年4月更新を機に、検知ルールの追加だけでなく、調査フローと部門連携まで見直すことが最も実務的な対応です。
コメント