单看每条都合规，加在一起才叫异常

结论先行：内部人员带走数据，很少表现为一次明显的异常操作。更常见的形态是一万次单独的查询与导出，每一条都有权限、在工作时段、也能对上一个理由。日志平台擅长回答「某一次操作合不合规」，不擅长回答「这个人这段时间累计拿了多少」，因为后者不是一条规则，而是一个计量口径。把累计做成能告警的判据，需要先定下三件事：计数对象是什么、时间窗多长、跟谁比。

本文只谈累计口径怎么定（计数对象、时间窗、比较基线、告警归属）；不谈单条检测规则怎么写，不谈一个自然人对应多个账号时怎么归一，也不谈风险分与处置分级。

为什么单条规则抓不到

单条视角与累计视角看的是两个不同的东西。

问题在于，绝大多数日志平台的能力建设是从单条开始的：解析、字段、检索、规则。累计需要一个额外的动作——把记录按主体和时间汇总，再和一群人比较。这一步不是加一条规则，是换一种数据结构。

三件事定下来，累计才能用

其一，计数对象。按人、按账号、还是按设备，结论完全不同。同一个自然人在系统里对应多个账号是常态，按账号计会把一个人的行为摊薄成几份，看起来都不突出；按人计则需要先有一张「人—账号」对照表——这张表怎么建是另一件事，但如果没有它，累计就只能停在账号层。

其二，时间窗。班次内、自然日、滚动三十天，三种窗口抓的是不同形态。班次窗口抓「一次性大批量」，自然日抓「一天内的异常密度」，滚动窗口抓「温水式」——每天不多不少，持续很久。想抓后一种，窗口必须长于一个考核周期，否则每到月初就重新计数，永远攒不起来。

其三，比较基线。给累计设一个固定数字（比如一天导出不超过五百条）在多数环境里活不下去：不同岗位的差异太大，定紧了全是误报，定松了等于没有。可行的做法是拿同岗位、同权限的一组人做分布，取一个分位值作为观察线，且这条线按季度重算。

其四，告警落在谁那里。这一项常被漏掉，而它决定了整套机制能不能跑。累计告警天然带着「可能是误会」，落在安全团队会被当成噪声，落在一线又没有人有权判断。常见的做法是分两级：观察线以上先落到班组长复核，复核后才进入安全流程。

一个能跑起来的起步做法

不要一上来铺全场景。先只做一件事：按「人—账号」统计导出对象数与不同对象数，滚动三十天，取同岗位分位值作为观察线，只在超出时给班组长一条提示。

• 阈值不公示。公示的阈值会变成一条可以贴着走的线。
• 先复核再定级。累计异常的头一版一定有误报，误报处理不好，三个月后就没有人再看这条提示。
• 记录判断过程。复核结论要留档，否则半年后无法解释为什么某条被放过。

深圳市奇摩计算机有限公司在日志类项目交付时，会把「人—账号」对照表与这份累计口径说明一起列进交付清单，因为这两样东西一旦缺一项，平台上线后能查的是记录，能回答的却还是单条。

边界与前提

三点说明。其一，本文所述做法取自通用日志与行为分析方案的公开描述，属对行业通行做法的一般性梳理，不针对任何具体产品或项目；文中比例与阈值均为示意，实际取值以本项目实测为准。其二，累计口径涉及个人信息处理，采集范围、告知与留存期限应事先由合规侧确认，本文不构成合规意见。其三，累计只能提高发现概率，不能替代权限治理——权限本身过宽时，累计做得再好也只是把合规行为的规模看清楚。

如果你的日志平台现在只能按单条检索，欢迎预约咨询，可以先从那张「人—账号」对照表的口径开始对齐。