结论先行：行为分析落地时最容易走偏的一步，是给全公司建一条行为基线，然后拿它去衡量每个人。结果是研发被判批量下载、财务被判集中导出、运维被判非工作时段登录，一张高风险名单里装满了正常干活的人。可行的顺序反过来：先按岗位与权限把人群划开，用同群体的常态当参照系，再判断某个个体是否偏离。群体划错了，后面所有结论都不成立。

本文只谈群体参照系怎么建、建错了会出什么问题，不谈风险分值怎么算，也不谈发现异常之后的处置流程与岗位职责分工。

个体基线为什么不够用

常见的做法是给每个人建一条自己的历史基线：跟他过去比，突变就是异常。这个思路在长期稳定的岗位上有效，但有三处硬伤。

新员工没有历史。入职三个月以内的人，行为本身就在快速变化，任何波动都可以解释成「还在熟悉」。这类人恰恰是风险窗口期，却恰好落在基线覆盖不到的地方。

岗位本身在变。一个工程师从业务系统转到数据平台，访问的对象、频次、时段全变了。个体基线会把这次转岗判成一次持续数周的异常，然后把分析人员的注意力耗在解释上。

低频行为没有基线。一个人一年只做几次的操作——比如季度结账、年度盘点、系统割接——历史样本太少，算不出「正常」是什么。这类操作恰恰风险高，因为它不常做、容易出错、也容易被利用。

个体基线回答的是「这个人变了没有」，群体基线回答的是「这件事在这个岗位上算不算常态」。两个问题都需要，但后一个问题在前，因为它决定了要不要报警。

群体怎么划：四个维度，按可用性排序

维度划法适用情形局限
岗位按职能归类，如研发、财务、运维、业务运营人数足够、职责边界清楚同一岗位内差异仍可能很大
权限组按可访问的系统与数据范围归组权限管理较规范的场景权限往往划得比实际职责宽
班次与时段按常规工作时段归组有轮班、有值班安排的团队跨时段协作的人会被切到两边
项目与团队按当前参与的项目归组交付型、项目型组织项目结束就得重划

实际落地通常是两三个维度叠加：岗位打底，权限组做修正，班次做时段上的例外。单靠一个维度几乎都不够。

划完之后要做一次检验：随便抽几个人，看他们被划进的群体里，其他人的日常操作和他们像不像。如果不像，说明这个维度选错了，换一个再试。这一步不需要技术，找人问一句就能验证。

群体太小时怎么办

三五个人的小组是常态，尤其是专业岗位。群体太小，算出来的「常态」没有意义——四个人的平均值，本质上就是四个人的差异。

三条可行的处理方式。其一，向上合并：把小组合并到职能相近的大组，代价是精度下降，但比没有参照系强。其二，改用规则而不是基线：这类岗位的行为用明确的规则判断，比如「访问了岗位权限之外的系统」这种二元判断，不需要统计分布。其三，只做留痕不做判断：先把行为完整记录下来，等样本积累到足够量再启用分析。

第三条最容易被跳过，但它常常是正确的选择。为了在上线当天就有告警，硬凑一个基线出来，产出的是一堆无法解释的告警，而无法解释的告警会迅速教会所有人忽略告警。

群体本身被污染时

还有一类情况更麻烦：整个群体都在做某件事，而那件事本身不正常。比如一个团队长期共用同一个高权限账号，或者一批人习惯把数据导到本地处理。在这些行为成为常态之后，任何人做这件事都不会被判异常——因为参照系本身已经偏了。

这类问题靠算法解决不了，只能靠另一条线：把「群体共性行为」单独盘一遍，看里面有没有明显违背权限设计原则的。这件事通常需要人来做，频次不用高，每季度或每次组织调整后做一次即可。

人员流动时，基线要重建

入职、转岗、离职这三件事都会让基线失效，但失效的方式不同。

入职时没有历史，只能挂在目标群体的线上，且头几个月应放宽判断阈值，把注意力放在「访问了群体外的东西」这类硬信号上。转岗时新旧两条基线都保留一段时间，观察是否形成新的稳定模式，再切换。离职窗口则相反，要把判断收紧——这个时期的异常更值得看，因为它和数据的处置有关。

这三件事需要人事系统的信息做输入。如果组织架构、岗位变动只存在于邮件和口头，基线就会长期挂着一个已经不对的群体标签，而且没人知道它已经不对。

落地清单

  • 先定岗位与权限两个维度的分组口径，写下来，作为分析配置的一部分。
  • 抽人验证分组是否合理，不合理就换维度，不要靠调阈值绕过。
  • 五人以下的群体不建独立基线，改用规则判断或只做留痕。
  • 每季度盘一次群体共性行为，找其中违背权限设计原则的部分。
  • 把入职、转岗、离职的变动接进分析配置，人员变动时同步重建。
  • 告警页面上写明本次判断用的是哪条基线、参照群体是谁。

最后一条值得单独说。一条告警如果只写「该用户行为异常」，接收的人无法判断要不要信；写明「与该用户所在研发组近 30 日常态相比偏高三倍，主要贡献项是访问了从未访问过的两台数据库服务器」，判断成本立刻降下来。可解释性不是给审计看的，是给每天要看几十条告警的人看的。

边界与前提

三点说明。其一，行为数据的采集范围应限定在与业务系统交互产生的记录，被监测的人应当知道被监测什么，具体范围与告知方式以内部制度与所在行业要求为准。其二，群体基线的分析结果只作为排查线索，不宜直接作为人员处理依据，把分析结论写进考核会让被监测者开始管理自己的行为数据，模型随即失真。其三，文中所述的分组维度与阈值调整方式属一般性梳理，实际参数须以本项目实测与业务实际为准。

深圳市奇摩计算机有限公司是一家 IT 解决方案服务商，在日志与安全分析类项目交付时，会把分组口径、基线配置与告警解释一并写进配置说明，而不是只交一个能出名单的页面。预约咨询，可以从现有岗位与权限分组开始，先看参照系划得对不对。