ユーザー・エンティティ行動分析(UEBA, User and Entity Behavior Analytics)

1. 概要

定義: UEBA(User and Entity Behavior Analytics)とは、ユーザー(User)および端末・サーバー・サービスアカウント等のエンティティ(Entity)の正常な行動を機械学習で学習して行動ベースライン(Baseline)を確立し、このベースラインから統計的に逸脱する異常兆候(Anomaly)をリスクスコアに換算して、内部不正や乗っ取られたアカウントを検知するセキュリティ分析技術をいう。

UEBAが登場した背景は、「ルール(Rule)ベース検知の限界」と「境界(Perimeter)の崩壊」という二つの流れから出発する。従来のSIEM・IDSは、「ログイン失敗5回以上」「業務時間外アクセス」といった事前に定義されたルール(Signature)に合致する事象のみを検知した。しかし攻撃者が正常なアカウントの資格情報を窃取して正当な権限でログインすると、その行為自体はいかなるルールにも違反しない。同様に、権限を持つ内部従業員が普段と異なる量のデータを持ち出しても、ルールでは濾し取れない。すなわち「誰がアクセスしたか(認証)」ではなく「その人物が普段と異なって行動しているか」を見るべきだという認識が、UEBAの出発点である。

もう一つの背景は、セキュリティ境界の消滅である。クラウド・リモートワーク・BYODが普遍化するにつれ、「内部網の中なら信頼」という前提が崩れ、アイデンティティ(Identity)が新たな境界となった。データ漏洩の相当数が外部侵入ではなく内部者または窃取された内部アカウントに起因するという業界報告が蓄積されるにつれ、ファイアウォールの外を塞ぐだけでは不十分であり、内部で発生する異常行動を継続的に観察せねばならないという要求が高まった。UEBAはこの要求に対するデータ分析的な応答である。

この転換は、検知の責任を「人がルールをどれだけうまく書くか」から「データが正常をどれだけうまく代表するか」へと移す。ルールベース検知が既知の攻撃の辞書(Dictionary)を広げる軍拡競争であったとすれば、UEBAは正常のモデルを精緻化してそれ以外の全てを疑うアプローチである。この発想の転換ゆえに、UEBAはシグネチャのない新種攻撃や正当な権限を悪用する脅威のように、ルールでは原理的に捕捉不可能であった領域を狙えるようになった。ただし「正常」をデータで定義した瞬間、そのデータの偏り・不完全性がそのまま検知の死角となるという新たな責任も併せて生じる。

UEBAの本質的特徴は四つに要約される。第一に、ベースライン学習(Baselining) — ルールを人が事前に書く代わりに、個人・グループ・エンティティ別の正常パターンをデータから学習する。第二に、エンティティ拡張(Entity-centric) — 分析対象を人だけでなくサーバー・IoT・サービスアカウントへ広げ、非人格的主体の異常も捕捉する。第三に、リスクスコア化(Risk Scoring) — 個別の異常を真偽の二分法ではなく累積リスクスコアに換算して優先順位を付ける。第四に、文脈相関(Contextualization) — 複数の弱い信号を時間・主体単位でまとめ、一つの脅威の物語として再構成する。この四つの特徴は、UEBAが単なる検知ルールの追加ではなく検知パラダイムの転換であることを示している。

2. UEBA全体構造と構成要素

UEBAは、多様なログソースからデータを収集して正規化し、ベースラインを学習したうえで異常スコアを算出し、SOC・SOARへ流し込む階層型分析パイプラインで構成される。下の概念図は、データ収集から対応連携までの全体構造を表す。

flowchart TB
  subgraph SRC["データソース層"]
    IDP["認証ログ(IAM/AD)"]
    EP["エンドポイント(EDR)"]
    NW["ネットワークフロー(NetFlow)"]
    APP["アプリケーション/DB監査"]
    CL["クラウド活動ログ"]
  end
  subgraph CORE["UEBA分析コア"]
    ING["収集・正規化・エンティティ解決"]
    BASE["ベースラインモデル(ML学習)"]
    DET["異常検知エンジン"]
    RISK["リスクスコア集計(Risk Engine)"]
  end
  subgraph OUT["対応・運用層"]
    ALERT["優先順位付きアラート"]
    SOAR["SOAR自動対応"]
    SOC["SOCアナリスト調査"]
  end
  IDP --> ING
  EP --> ING
  NW --> ING
  APP --> ING
  CL --> ING
  ING --> BASE
  BASE --> DET
  DET --> RISK
  RISK --> ALERT
  ALERT --> SOAR
  ALERT --> SOC
  SOC -->|フィードバック| BASE

データソース層はUEBAの原材料を供給する。認証ログ(ログイン時刻・場所・成否)、エンドポイントのプロセス実行記録、ネットワークフロー、アプリケーション・DBアクセス監査、クラウドAPI呼び出しログが代表的である。UEBAの検知品質は入力データの幅と整合性に比例するため、ソースが広く時間・主体が正確に識別されるほどベースラインが精緻になる。特に複数のログに散らばった識別子(アカウント名・IP・ホスト名)を一つのエンティティへ帰属(Entity Resolution)させる作業が中核の前処理である。

エンティティ解決の品質はUEBA全体の土台である。一人が複数のアカウント・端末・IPとして現れ、一つのIPを複数人が共有することもあるため、散らばった識別子を正しい主体へ帰属できなければベースライン自体が汚染される。したがって成熟したUEBAはIAM・資産管理(CMDB)・HRシステムと連携してアカウント-人-役割-端末の関係を継続的に同期し、組織変更が発生するたびにエンティティマッピングを更新する。

分析コアはUEBAの頭脳である。収集・正規化の段階で異質なログを共通スキーマへ変換しエンティティを解決したうえで、ベースラインモデルが各主体の正常範囲を学習する。異常検知エンジンは新規イベントをベースラインと対照して偏差を計算し、リスクスコアエンジンは個別の偏差を時間・主体単位で累積して総合リスク度を算出する。重要な点は、単一の異常一つでアラートを出さず、複数の弱い信号が同一主体に累積したときにスコアが閾値を越える構造だということである。これは誤検知(False Positive)を抑制しつつ、密かな攻撃を捕捉するための設計である。

対応・運用層は分析結果を行動に移す。リスクスコアの高い主体を優先順位付きアラートとして提示し、SOARプレイブックと連携してアカウント無効化・セッション終了・追加認証要求といった自動対応を行うか、SOCアナリストへ調査タスクとして引き渡す。アナリストの判定結果(正検知/誤検知)は再びベースラインモデルへフィードバックされ、検知精度を漸進的に改善する。

構成要素を貫く設計原則は「広く集め、狭く警報する」に要約される。収集は可能な限り多くのソースから幅広く行うが、警報は複数の信号を累積して確信が立ったときのみ狭く発令する。この非対称な構造は可視性(Visibility)を最大化しつつアナリストの認知負荷を制御するためのもので、UEBAパイプラインが単なる検知器の羅列ではなく信号対雑音比(Signal-to-Noise Ratio)を最適化する分析体系であることを明らかにする。したがって、いずれか一層のみを高度化しても効果は限定的であり、収集の幅・学習の精緻さ・スコア集計の論理・対応の自動化がバランスよく成熟して初めて価値が発現する。

3. 検知メカニズムと類型

UEBAの核心は、「正常を学習して異常を測定する」統計・機械学習パイプラインである。下のプロセス詳細図は、一つのイベントがベースラインと対照されてリスクスコアに換算され、対応へつながる流れを示す。

sequenceDiagram
  participant E as イベント(ログ)
  participant N as 正規化/エンティティ解決
  participant B as ベースラインモデル
  participant S as リスクスコアエンジン
  participant R as 対応(SOAR/SOC)
  E->>N: 生ログ収集
  N->>B: エンティティ別特徴ベクトル生成
  B->>B: ベースラインとの偏差計算(統計/ML)
  B->>S: 個別異常信号の伝達
  S->>S: 時間・主体単位でスコア累積
  alt 閾値超過
    S->>R: 高リスクアラート発令
    R->>B: アナリスト判定フィードバック
  else 閾値以下
    S->>S: スコア減衰(時間経過)
  end

検知手法は大きく三類型に区分され、それぞれ検知範囲と誤検知率のトレードオフが異なる。第一に、統計的異常検知は平均・標準偏差・分位数といった統計量で「普段比で何倍」の偏差を測定する。例えば普段1日50MBをダウンロードしていたユーザーが突然5GBをダウンロードすれば、100倍の偏差として即座に捕捉される。実装が単純で説明可能性が高いが、正常分布が季節性を帯びると誤検知が増えうる。

第二に、教師なし機械学習(Unsupervised ML)はラベルのないデータから、クラスタリング(Clustering)・孤立度(Isolation Forest)・オートエンコーダの再構成誤差などで稀なパターンを見つけ出す。事前ラベルがなくても未知の攻撃を捕捉できるため、内部不正のような「知られていない正常逸脱」に強いが、なぜ異常かを説明しにくく、アナリストの信頼確保が課題である。第三に、ピアグループ分析(Peer Group Analysis)は職務・部署が類似した集団の平均行動と対照し、「同じチームの誰もアクセスしないシステムに単独でアクセス」といった相対的異常を捕捉する。個人の過去のみを見る自己ベースラインと異なり、集団比の逸脱を捉える点で補完的である。

三手法は排他的ではなく、アンサンブル(Ensemble)として組み合わされたときに最も強力である。実務では統計的手法で明白な極値を素早く濾し取り、教師なしMLで微妙なパターン逸脱を補い、ピアグループ分析で個人ベースラインの死角を埋める形で多層防御を構成する。各手法が算出した偏差は共通尺度へ正規化されてリスクスコアエンジンに集まるが、ここで時間重み付けが重要である。より最近の逸脱ほど大きな重みを与え古い信号は減衰させることで、過去の一度きりの異常が主体を永続的に高リスクと烙印する副作用を防ぐ。また、リスクスコアは絶対値より傾向が重要であるため、短い時間窓でスコアが急上昇する主体を優先調査対象とする運用原則が広く用いられる。

検知対象シナリオの面で、UEBAは四つの軸をカバーする — 乗っ取りアカウント(異常なログインの地理・時間)、内部不正(権限濫用・大量持ち出し)、権限昇格(Lateral Movement)、データ漏洩(異常なデータアクセス)。下の表は各類型の補助的比較である。

検知手法	中核原理	強み	限界
統計的異常	平均・標準偏差の偏差	説明容易、軽量	季節性・傾向に脆弱
教師なしML	クラスタ・孤立・再構成誤差	未知攻撃の捕捉	説明可能性が低い
ピアグループ分析	集団平均比の逸脱	相対的異常の捕捉	グループ定義の品質に依存

四つの検知シナリオをもう少し解きほぐすと、それぞれの特徴が鮮明になる。

A. 乗っ取りアカウント(Compromised Account): 正常な資格情報でログインするが、アクセスの地理・時間・端末・速度が普段と異なる場合である。例えばソウルでログインした10分後に地球の反対側から同じアカウントがアクセスする不可能な移動(Impossible Travel)は代表的な信号である。認証は成功しているためルールベースでは検知が難しく、ベースライン比の文脈逸脱としてのみ捕捉される。
B. 内部不正(Insider Threat): 権限を正当に保持する従業員が普段の範囲を越えてデータを閲覧・持ち出す場合である。悪意ある内部者だけでなく、ミスやポリシー無知による非意図的漏洩も含む。個人ベースラインとピアグループ分析を組み合わせてこそ効果的に捕捉される。
C. 権限昇格・横方向移動(Lateral Movement): 侵入に成功した攻撃者が内部でより高い権限とより重要な資産へ移動する段階である。普段アクセスしないホスト・サービスへの連鎖アクセスパターンが中核の信号であり、グラフベース分析が特に強みを見せる。
D. データ漏洩(Data Exfiltration): 機微データを外部へ持ち出す最終段階である。異常な大容量転送、外部ストレージへのアップロード、業務時間外の大量ダウンロードがベースライン比の逸脱として測定される。

4. SIEM・UEBA比較と適用事例

UEBAはしばしばSIEMと混同されるが、志向が異なる。SIEMは広範なログを収集・保管し、ルールと相関分析で既知の脅威を検知するのに強く、コンプライアンス(Compliance)証跡に最適化されている。一方UEBAは学習したベースライン比の逸脱に焦点を置き、ルールで表現しにくい未知・内部の脅威を狙う。両者は競合関係というより補完関係であり、実際に多くの商用SIEMはUEBAモジュールを吸収して「次世代SIEM」へ統合される趨勢にある。差が生じる根本的理由は検知知識の出所にある — SIEMは人が作成したルール(明示知)に依存し、UEBAはデータから帰納されたベースライン(暗黙知)に依存する。したがってSIEMは「何を探すか分かる」脅威に、UEBAは「何を探すか分からない」脅威にそれぞれ強い。

この差は運用モデルにも反映される。SIEM中心のSOCは「ルールを整備し新たな脅威に合わせてルールを追加する」先制的な知識管理が中核の能力である一方、UEBA中心のSOCは「モデルが算出した異常を解釈・検証し、その判定をモデルへ還流する」データサイエンス的能力が中核となる。したがって組織がUEBAを導入する際は、ツールを入れるだけでなく、異常信号を調査・判定できるアナリスト能力とフィードバックプロセスを併せて備えねばならない。この能力がなければUEBAのアラートは、もう一つの解釈不能な雑音へと転落する。

具体的事例として、ある金融機関で業務時間外の早朝の時間帯に特定のサービスアカウントが普段アクセスしない顧客DBへ数百件のクエリを投げた事案が挙げられる。個別のクエリはすべて権限範囲内でありSIEMルールには引っかからなかったが、UEBAは「当該サービスアカウントの時間帯・対象・頻度」がベースラインから同時に逸脱した点を累積して高リスクアラートを出し、調査の結果、自動化スクリプトに埋め込まれた資格情報が窃取された事例として明らかになった。別の事例として、退職を控えた従業員が普段10件ほどであった文書ダウンロードを1日で400件ほどに増やした場合、ピアグループ平均比で40倍以上の逸脱として捕捉され、データ持ち出しの試みが事前に遮断された事例が報告される。このようにUEBAの価値は、「ルールなしでも普段との相違」を数値で証明する点にある。

三つ目の事例として、製造業のOT(運用技術)環境で特定のエンジニアリングワークステーションが普段と異なり夜間に多数のPLC(制御装置)へ設定変更命令を送信した場合が挙げられる。人ではないエンティティ(ワークステーション)の行動ベースライン逸脱として捕捉され、感染した端末が制御網へ横方向移動を試みる初期段階で遮断されたと報告される。この事例は、UEBAの分析対象が人を越えて非人格的エンティティへ拡張されるとき、OT・IoTのようにユーザーアカウントの概念が希薄な環境でも有効であることを示している。

5. 深化 — 最新動向とITDR・ゼロトラスト連携

近年UEBAは独立製品から脱して、XDR・SIEM・ITDR(Identity Threat Detection and Response)に内蔵される分析エンジンへ進化している。特にアイデンティティが攻撃の中核標的となるにつれ、アイデンティティ層の行動を集中分析するITDRの心臓部としてUEBAが定着した。従来のEDR・NDRが端末・ネットワークを見ていたとすれば、ITDRは「アカウント・トークン・セッション」の異常な使用をUEBA手法で検知し、乗っ取り・権限昇格を早期に遮断する。

UEBAはゼロトラスト(Zero Trust)アーキテクチャの中核入力としても再照明される。ゼロトラストの「継続検証(Continuously Verify)」原則は、1回の認証で終えずセッションの間じゅう信頼を再評価することを要求するが、UEBAのリアルタイムリスクスコアがまさにその再評価信号となる。例えばログイン後の行動がベースラインを逸脱するとリスクスコアが上昇し、これを受けたポリシーエンジンが適応型アクセス制御(Adaptive Access)で追加認証を要求するかセッションを隔離する。すなわちUEBAは、「誰にどれだけの信頼を今付与するか」を動的に調整する根拠を提供する。

技術的進化の軸では、グラフベース分析とリアルタイムストリーミング処理が際立つ。従来のUEBAが個別主体の時系列を見ていたとすれば、グラフUEBAはユーザー-端末-資源間のアクセス関係をグラフでモデル化し、「普段つながらないノードが短時間に連鎖してつながる」横方向移動(Lateral Movement)の経路を構造的に検知する。また、バッチ(Batch)学習からストリーミング推論へ重心が移るにつれ、ログが発生して数秒以内にリスクスコアが更新され、リアルタイムの適応型対応が可能になりつつある。これは平均検知・対応時間(MTTD/MTTR)短縮というSOCの根本目標に直結する。

生成AIの台頭もUEBAに両面で作用する。防御の面では、LLMが複雑な異常の物語を自然言語で要約・説明してアナリストの調査時間を短縮し、教師なしMLの説明可能性の弱点を補う。攻撃の面では、AIが正常な行動をより精緻に模倣してベースラインを回避しようと試みるため、UEBAも敵対的頑健性(Adversarial Robustness)とベースライン再学習周期を併せて設計せねばならない。加えて、サービスアカウント・ボット・AIエージェント等の非人格的エンティティ(NHI, Non-Human Identity)が急増するにつれ、人中心であったUEBAがマシンエンティティ行動分析へ重心を移すことも明確な流れである。

6. 考慮事項および示唆点

技術士の観点から、UEBAの導入は単なるソリューション購入ではなく、データ・組織・プライバシー・運用を包括する戦略的課題として取り組むべきである。

データ品質とベースライン安定化戦略: UEBAの成否は入力データの幅・整合性とエンティティ解決の品質に左右される。導入初期2〜8週間の学習(Warm-up)期間は誤検知が多いため、漸進的なソース拡張とベースライン成熟度を前提とした段階的展開ロードマップが必要である。組織改編・業務変化が頻繁ならベースラインが揺らぐため、再学習周期とドリフト(Drift)監視を併行する。
誤検知・アラート疲労と運用トレードオフ: 感度を上げると見逃しは減るが誤検知が激増してSOCが麻痺し、下げると逆になる。リスクスコア閾値・スコア減衰(Decay)・ピアグループ定義を組織の文脈に合わせてチューニングし、アナリストのフィードバックループで継続的に補正する運用体系が成否を分ける。UEBAは「設置型」ではなく「運用型」ソリューションであることを認識せねばならない。
プライバシー・労働監視リスクとガバナンス: 従業員の行動を常時分析する特性上、個人情報保護法・労働者監視規制と衝突しうる。収集最小化・仮名化・目的制限・アクセス統制の原則を適用し、労使合意と透明な告知を通じて監視ではなくセキュリティ目的であることを制度的に保証せねばならない。ガバナンスなきUEBAは法的・倫理的逆風を招く。
説明可能性とアナリスト信頼の確保: 教師なしMLベースのUEBAは「なぜ異常か」を説明しにくく、アナリストがアラートを信頼できなければ、いかに正確でも現場で敬遠される。したがってリスクスコアに寄与した信号を遡って提示する根拠提示(Explainability)機能と、生成AIベースの自然言語要約を併せて備え、アナリストの調査信頼度を高めることが導入成功の隠れた条件である。技術は精度だけでなく受容性(Adoption)で評価されるべきである。
アーキテクチャ連携と展望: UEBAは単独では価値が限定的であり、SIEM・SOAR・EDR・ITDR・IAMと統合されたとき初めて閉ループ対応が完成する。今後はゼロトラストのリアルタイム信頼評価エンジンであり、非人格的エンティティ管理の中心として役割が拡大する展望である。したがってセキュリティアーキテクチャ設計時にUEBAを独立製品ではなく共通分析層として位置づけ、標準ログスキーマ(OCSF等)とAPI連携を前提に選定することが望ましい。

参考資料

Gartner, "Market Guide for User and Entity Behavior Analytics", https://www.gartner.com/en/documents
NIST SP 800-207, "Zero Trust Architecture", https://csrc.nist.gov/publications/detail/sp/800-207/final
MITRE ATT&CK, "Insider Threat & Valid Accounts (T1078)", https://attack.mitre.org/techniques/T1078/
OCSF(Open Cybersecurity Schema Framework), https://schema.ocsf.io/

一言まとめ: UEBAはユーザー・エンティティの正常な行動を機械学習で学習したベースラインとの逸脱をリスクスコアに換算し、ルールでは捕えられない乗っ取りアカウント・内部不正を検知する行動ベースのセキュリティ分析技術であり、ゼロトラスト・ITDRの中核分析エンジンへ進化している。