4、异常检测基础：统计学方法，规则引擎归纳总结

说到异常检测，很多人第一反应就是上机器学习。但说实话，在我经手的大多数密钥监控项目里，真正扛大梁的反而是那些基础的统计学方法和规则引擎。为什么？简单，可解释，上线快。

我记得有一次帮一家金融公司处理滥用问题。他们之前用了一套很复杂的深度学习模型，结果业务方根本不买账——模型说“异常”，但说不出为什么异常。后来我帮他们换了一套基于统计学的基线方案，配合几十条规则引擎，一周内就定位了三个数据泄露源头。嗯，这里有个教训：解释成本往往比模型精度更关键。

4.1 统计学方法：给数据画个“正常范围”

统计学方法的核心思想很简单——你想想看，正常访问就应该遵循某种分布。偏离太远的，大概率就是异常。我习惯把这类方法分成三档，由浅入深。

4.1.1 均值与标准差（Z-Score）

这是最基础的方法。假设你的访问量符合正态分布，那么大多数数据会落在均值附近。Z-Score 衡量的是当前数据点偏离均值多少个标准差。

Z = (X - μ) / σ

其中：
X = 当前观测值
μ = 历史均值
σ = 历史标准差

我在项目中通常设 Z > 3 就算异常。为什么呢？正态分布下，Z > 3 的概率只有 0.3% 左右。也就是说，1000 次访问里最多出现 3 次，突然冒出几十次，肯定有问题。

4.1.2 移动平均与滑动窗口

在密钥访问场景里，数据往往有很强的周期性。白天高，夜里低，周末更是另一副样子。这时候直接用全局均值和标准差不靠谱。

我个人的做法是用滑动窗口 + 移动平均。比如取过去 10 分钟的访问量做均值，然后看当前分钟的值是否超过这个均值的 3 倍。这样能自动适应日夜变化和周末低谷。

滑动平均 MA(t) = (V(t-9) + V(t-8) + ... + V(t)) / 10

异常判定：|V(t+1) - MA(t)| > k * σ(滑动窗口内标准差)

当然，k 值怎么定？我建议先跑一周的历史数据，调 k 到误报率低于 1% 为止。这里没有银弹，得根据你的业务容忍度来。

4.1.3 百分位法（分位数）

有一种场景特别头疼——数据不是正态的，而且你不想做变换。比如某些冷门密钥，一天调用几次算正常，突然调用 50 次算不算异常？Z-Score 会告诉你“不算”（因为均值很小，标准差也很小）。

这时我推荐用百分位法。简单说，就是把历史数据从小到大排好，取 P95、P99 作为阈值。只要当前值超过 P99，我就报警。

4.2 规则引擎：当业务逻辑“写”进代码里

统计学方法擅长发现“量的异常”，但有些异常是“质的异常”。比如一个运维密钥突然被从境外 IP 调用——调用量可能完全正常（正常运维很频繁），但地理位置的异常必须抓。这时候就得靠规则引擎。

4.2.1 规则的三要素

我个人设计规则引擎时，习惯把一条规则拆成三个部分：

• 事件/指标：你要监控什么？比如密钥的调用地域、调用时间、调用频率。
• 条件/阈值：什么情况下触发？比如地域不在白名单内，或者调用时段不在工作时间。
• 动作/响应：触发了怎么办？比如发告警、临时封禁密钥、通知安全负责人。

举个例子来说，你写一个规则，专门处理“境外调用”问题：

规则名称：境外IP调用 - 高敏感密钥
事件：密钥调用日志（包含 source_ip, key_id, api_name）
条件：
  - key_id 属于“高敏感密钥列表”
  - source_ip 的 GeoIP 不在中国大陆
  - 同一 key_id 在过去 5 分钟内的境外调用次数 > 3
动作：
  - 等级：严重
  - 自动禁用该 key_id 30 分钟
  - 发送企微告警到 @安全值班组

4.2.2 静态规则 vs 动态规则

静态规则好理解——阈值是写死的。比如“单密钥每分钟调用不超过 100 次”。但问题在于，业务做活动时，正常的调用量可能就是平时的 10 倍。这时静态规则就会误报。

我建议在规则引擎里引入动态阈值。也就是用上一节说的统计学方法，给规则引擎提供“活”的基线。比如：

• 今天 14:00 的调用基线是 200 QPS（由移动平均算出）
• 规则引擎的阈值自动设为 200 * 3 = 600 QPS
• 结果 14:05 真的到了 650 QPS——告警触发

你看，这样既保留了规则引擎的精准性，又兼顾了统计方法的弹性。

4.2.3 规则编排与优先级

规则多了以后，你得考虑优先级。假设你同时有两条规则：

1. 如果调用量 > 1000 QPS，告警
2. 如果调用量 > 1000 QPS 且 IP 来自黑名单，封禁+告警

这两条规则有重叠。我建议把动作更严厉的规则放前面。当规则 2 命中时，规则 1 就不必再执行了，避免重复告警。

4.3 统计学 + 规则引擎：混合检测架构

光用统计学，你会漏掉很多业务语义层面的异常。光用规则引擎，你又会陷入阈值配置的海洋。两者结合才是正解。

我在架构上习惯这么搭：

首先，数据流进来后，先过统计学模块。移动平均、百分位、Z-Score 三路并行跑一遍，每个结果都打上“异常分数”（比如 0~100）。

然后，数据再进规则引擎。规则引擎不仅仅是靠硬编码的白名单，它也会读取统计学模块给出的异常分数。比如一条规则可以是：
“如果 Z-Score > 3 且 IP 来自陌生地域，则该异常分数加权到 100，直接封禁。”

这样，规则引擎就有了“统计学大脑”，统计学方法也有了“业务约束”。

4.4 避坑指南与经验总结

这一章的东西看着简单，但我在真实项目里摔过不少跟头。总结几个我反复踩的坑：

• 阈值设太死：我曾经给一个核心密钥设了 100 QPS 的硬阈值。结果业务上线大促，直接崩了。后来我学会了动态阈值的自适应。
• 规则没去重：同一个异常触发了多条规则，导致安全组在同一分钟收到 5 条一样的告警。后来我加了告警聚合窗口（比如 5 分钟内的同类告警只发一条）。
• 完全不考虑冷启动：新的密钥或新的接口刚上线，历史数据为空。统计学方法直接没数据。我的做法是先用规则引擎撑着，等积累了一周数据后再加统计学基线。