内部威胁与 UEBA 用户行为分析

传统边界安全的隐含假设是"内部可信、外部可疑"。但真实事故里，损失最大的往往来自已经持有合法凭证的人——一个即将离职的员工批量导走客户名单，一个被钓鱼拿到账号的攻击者用合法身份缓慢横向移动，一个运维的疏忽把生产库暴露到公网。这类行为的共同点是：凭证是真的，访问是授权的，规则引擎不会报警。UEBA（User and Entity Behavior Analytics，用户与实体行为分析）正是为"识别合法身份下的异常行为"而生的技术。本文讲清内部威胁的画像、UEBA 的数据与算法、检测场景与隐私边界。

一、内部威胁的三类画像

把内部威胁笼统归为"内鬼"是最大的认知误区。按动机与可控性，它至少分三类，检测思路完全不同。

关键差异：

• 恶意内部人最难检测，因为他知道审计在哪、知道正常行为长什么样，会刻意模仿。对策是把多个弱信号关联起来（下载量 + 离职时间 + 非工作时间），而非指望单一规则。
• 疏忽型其实最适合用 DLP（数据防泄漏）与策略引擎解决，UEBA 的作用是发现"策略没覆盖到的盲区"。
• 被攻陷身份本质是外部攻击，UEBA 的价值在于识别"凭证行为与持有人历史行为不一致"，这与零信任的持续验证思路一脉相承。

一个常被引用的经验数据是：内部威胁事件的平均发现周期以月计，且相当比例是被同事或外部发现而非监控系统发现。这直接说明"仅靠日志告警"不够，必须有行为基线。

二、UEBA 的数据基础

UEBA 的输入不是单一日志，而是围绕"实体"聚合的多源行为流。实体（entity）包括用户、设备、IP、应用、服务账号、甚至数据库表。

2.1 核心数据源

采集的关键不是"全量存"，而是规范化成统一的行为事件模型：{时间, 实体, 动作, 对象, 结果, 上下文}。这样才能跨源关联——比如"AD 登录成功 → EDR 启动压缩进程 → 数据库批量导出 → 邮件外发附件"这一条链，单独看每一环都正常，串起来就是数据外泄。

2.2 实体与关系图

UEBA 通常维护一张实体关系图：用户属于哪个部门、使用哪些设备、访问哪些资源、与谁协作。图结构让"peer group（同类群体）“分析成为可能——判断一个行为是否异常，最好的参照不是"全公司”，而是"同岗位、同权限级别的人"。

user:alice ──uses──> device:MBP-0231
    │                    │
    ├─member_of─> dept:finance
    │                    │
    └─accessed─> db:customers (导出 12,000 行)
                 ^
                 └─ peer baseline: finance 组平均 200 行/月

上例中，alice 的导出量是同组均值的 60 倍，这就是一个高价值异常。

2.3 事件规范化与跨源关联

原始日志格式千差万别（Syslog、JSON、CEF、SaaS 各自一套），UEBA 的第一步是把它们统一成行为事件。一个可用的最小模型：

{
  "ts": "2026-10-08T02:13:44+08:00",
  "entity": {"type": "user", "id": "alice", "dept": "finance"},
  "action": "db.export",
  "object": {"type": "table", "id": "customers", "sensitivity": "PII"},
  "result": "success",
  "context": {"src_ip": "10.20.3.7", "device": "MBP-0231", "app": "bi-tool"}
}

有了统一模型，关联就变成"在时间窗口内，把同一实体的事件按时间排序，找异常子序列"：

-- 找出"登录 → 大批量导出 → 外发"在 1 小时内连续发生的用户
SELECT entity_id
FROM behavior_events
WHERE ts > now() - interval '24 hours'
  AND action IN ('auth.login', 'db.export', 'mail.send_attachment')
GROUP BY entity_id
HAVING count(DISTINCT action) = 3
   AND max(ts) - min(ts) < interval '1 hour';

关联的价值在于降低单点误报：单独一次登录、一次导出都太常见，但"凌晨登录 + 批量导出 + 立刻外发"的组合概率极低。这也是 UEBA 与传统规则引擎最本质的区别——它看的是序列与组合，而不是孤立事件。

三、基线建模与异常检测

UEBA 的核心是"先建立正常，再度量偏离"。基线不是静态阈值，而是随时间演化、按群体细分的动态模型。

3.1 基线的几个维度

• 时间基线：某用户通常在几点到几点活动。凌晨 3 点的数据库导出天然异常。
• 体量基线：每日下载量、查询次数、外发附件数。用分位数（如 P95）而非均值，避免被极端值拉偏。
• 群体基线：同岗位/同权限组的行为分布，用于横向对比。
• 序列基线：正常操作序列（登录 → 查工单 → 改配置），顺序异常也值得关注。

3.2 统计方法

对体量类指标，最简单的做法是稳健 z 分数（用中位数与 MAD 代替均值与标准差）：

import numpy as np

def robust_z(value, history):
    med = np.median(history)
    mad = np.median(np.abs(history - med)) or 1.0
    return 0.6745 * (value - med) / mad

# 当日导出量相对该用户历史（近 90 天）的偏离
score = robust_z(today_export_rows, user_export_history)
if score > 3.5:
    alert("unusual_export_volume", user, today_export_rows)

对随时间变化的指标，用指数加权移动平均（EWMA） 跟踪趋势，能更好捕捉缓慢漂移：

EWMA_t = α * x_t + (1 - α) * EWMA_{t-1}     # α 常取 0.1~0.3
偏离 = (x_t - EWMA_t) / σ_residual

3.3 机器学习方法

实战建议：先用统计方法打底，ML 只用于补充。统计方法可解释、易调优、便于向业务解释"为什么报这个警"；纯 ML 的黑盒在安全运营里很难被信任，误报也没法定位原因。

3.4 风险评分

单一异常不该直接触发告警，应聚合成风险分（risk score），随时间衰减，多个弱信号叠加后才越线：

risk(user) = Σ  w_i * decay(t - t_i) * severity_i
decay(Δt) = exp(-Δt / τ)      # τ 为半衰期，如 7 天

这样，一个"下载量偏高 + 登录地点变更 + 权限申请被拒"的组合会累积成高分，而单独的"下载量偏高"只贡献少量分数。风险分从"事件驱动"转向"状态驱动"，是 UEBA 区别于传统规则引擎的关键。

3.5 误报治理

UEBA 最容易死在误报上——分析师被淹没后就会开始"闭眼点掉"，系统形同虚设。治理手段：

• 白名单与例外：明确的高频合法行为（如财务月末批量导出）应进入例外库，并定期复核，防止例外无限膨胀。
• 阈值自适应：用历史分位数而非固定数值，业务量增长时阈值自动跟随。
• 抑制窗口：同一实体同一场景在 N 小时内只告警一次，避免刷屏。
• 告警分级：低分只记录、中分进队列、高分才触发响应，避免"所有告警都紧急"。
• 反馈闭环：分析师的"误报/确认"结论必须回写，用于调阈值与训练模型。

一个务实的起点是先让误报率低于分析师日均处理能力，再谈提升检出率。宁可少报，不可淹没人。

四、典型检测场景与规则

4.1 离职/异动关联

最高价值的场景之一：把 HR 系统的离职流程、调岗、绩效异常与行为数据关联。

场景：离职前数据外带
条件：
  - 该用户在 30 天内有离职/调岗标记
  AND (
      单日下载量 > 该用户历史 P95 的 5 倍
      OR 访问了从未访问过的敏感目录
      OR 向个人邮箱外发附件 > 5 次
  )
动作：高风险告警 + 可选自动限速

4.2 权限与访问异常

4.3 数据流动异常

• 体量突变：导出/查询行数、附件大小远超基线。
• 渠道突变：平时用企业网盘，突然用个人邮箱/USB。
• 对象突变：平时访问公开数据，突然访问标密数据。
• 时间突变：非工作时间、假期、刚登出又立刻登录。

4.4 凭证滥用

被攻陷身份最典型的表现是**“凭证行为与持有人画像不符”**：

• 登录源 IP 与该用户历史地理分布不符（但要小心 VPN、移动网络带来的误报）。
• 用户代理（User-Agent）突变——同一账号从 Chrome 变成脚本工具。
• 会话时长与操作节奏异常：机器化的高频操作。
• 不可能旅行（impossible travel）：短时间内两地登录。

这些信号与 SIEM 与安全运营中心 的关联规则引擎天然契合：UEBA 负责产出"异常评分"，SIEM 负责把评分与其他告警关联、触发响应流程。

4.5 场景优先级矩阵

资源有限时，按下表排序投入：

原则是：优先做"数据齐、逻辑清晰、损失大"的场景，用它们建立平台、跑通流程、赢得业务信任，再去啃横向移动这类需要图分析的高难度场景。

五、隐私与合规平衡

UEBA 天然踩在隐私红线上——它分析的是"员工行为"。做不好，技术再先进也会因合规问题被叫停。

5.1 四条底线

1. 知情同意：员工手册、入职培训中明确告知行为监控的范围与目的。
2. 目的限制：数据只用于安全目的，不得用于绩效、考勤、政治倾向分析。
3. 数据最小化：只采集与安全相关的事件，不采集聊天内容、屏幕截图（除非有明确合规依据与流程）。
4. 最小必要知情：告警的可见范围受限，调查需审批，避免"人人可查同事行为"。

5.2 法规对照

技术上可做的缓冲：

• 假名化：分析阶段用用户 ID 而非姓名，仅在调查需要时解密。
• 聚合优先：先看群体分布，再看个人。
• 留存期限：原始行为数据保留期设上限（如 90 天），长期只留聚合指标。
• 审计审计者：谁查了谁的记录，本身也要留痕。

这些要求与 安全合规与数据保护 中的数据处理原则一致，UEBA 的采集设计应当从一开始就纳入合规评审。

5.3 调查流程与取证

UEBA 告警只是起点，真正定责要靠调查。一个规范的内部调查流程应包含：

1. 证据保全：第一时间固化相关日志与端点镜像，记录保全人与时间戳，保证链条完整。
2. 范围界定：确认涉及哪些账号、哪些数据、影响面多大。
3. 面谈与法律协同：涉及劳动关系处置时必须与 HR、法务同步，避免程序瑕疵导致证据无效。
4. 最小披露：调查结论只在必要范围内传达。
5. 复盘与规则回填：把本次发现的行为模式固化为新的检测规则。

技术侧要提前准备的能力：跨源日志的时间对齐（不同系统时钟漂移是常见坑）、不可篡改存储（WORM 或哈希链）、以及审计审计者——谁在什么时候查了谁的行为数据，本身也要记录。

六、落地路径与度量

6.1 从场景驱动起步

不要一上来就"建平台、接全量数据"。更有效的顺序是：

1. 选 2~3 个高价值场景（离职外带、权限提升、凭证滥用）。
2. 确认每个场景需要的数据源，先把这几条打通。
3. 建立基线，跑观察期（如 30 天）只记录不告警。
4. 校准阈值，把误报压到运营可接受的水平。
5. 接入 SOC 流程，明确告警后谁处理、怎么处理。
6. 再逐步扩场景与数据源。

6.2 关键度量

6.3 与安全运营的协同

UEBA 的输出应当成为 SOC 的"优先级信号"而非"新的一堆告警"。具体做法：

• 把风险分注入 SIEM，作为告警排序的一个维度；数据的采集与管道设计可参考 可观测性 的日志治理实践。
• 高风险分自动触发编排剧本（如临时禁用账号、通知主管），把应急响应的处置动作前置。
• 所有 UEBA 告警与 威胁情报 的 IOC 做交叉比对，区分"内部异常"与"已知攻击者"。

6.4 常见失败模式

内部威胁项目折戟的原因高度相似，提前避开：

一句话总结：内部威胁检测是"人 + 流程 + 数据 + 算法"的系统工程，任何一环缺失都会让整套系统退化成"又一堆没人看的告警"。

小结

内部威胁之所以难，是因为它借用了合法的身份与授权，传统"内外有别"的假设失效。UEBA 的应对思路是把防御从"规则匹配"升级为"行为建模"：用多源数据刻画每个实体"正常应该是什么样"，用统计与 ML 度量偏离，用风险评分聚合弱信号，最后在隐私合规的边界内把结论交给安全运营。技术只是骨架，场景选择、基线校准、误报治理与合规设计才是决定成败的部分。