很多团队上了日志平台和告警机器人，真出事时却说不清「到底该监测什么」：告警要么全是噪音，要么关键动作一条都没覆盖。这篇不讲原则，只给一份可对照的内容清单——按数据流、身份、行为、外部渠道分层列出该盯的项，以及每项怎么设阈值、怎么留证、什么情况下不适用。
很多安全团队其实不缺工具：日志平台接了、告警机器人也配了、值班表排得挺整齐，可一旦真出了数据被带走的事，回头翻记录才发现——关键动作一条都没覆盖，推送记录里全是无关痛痒的噪音。问题往往不出在工具，而出在「监测范围」这四个字没人认真定过。你到底要盯哪些库、哪些接口、哪几个人的什么动作，这些想不清楚，规则写出来就是随机数。
这篇不聊原则也不聊框架，直接给一份可以拿来对照的清单：按数据流转、身份凭据、行为基线、外部渠道几层，列出该盯的项，以及每一项怎么设阈值、怎么留证、什么情况下这套做法不适用。你可以拿它当 checklist，把现有监测范围和它对一遍，缺哪块补哪块。
先定范围：监测预警不是把日志全接进来
最常见的错误是想一步到位，把所有数据源全量接进告警系统，觉得覆盖面越大越安全。结果正好相反：采集面越宽，噪音越多，真正该看的那几条被淹没。正确顺序是先从数据资产清单反推——先确定哪些库、哪些盘、哪些接口里装的是敏感数据，再决定这些地方要采什么、报什么。
- 先分目标再定规则：合规留痕型只要证明有人在管，采集频率和阈值可以松；实战阻断型要真能拦住动作，阈值就得紧、响应就得快
- 每个数据源登记三项信息：责任人、数据等级、可接受访问窗口，缺一项就暂时不接入告警，只做归档
- 优先接入有明确责任人且访问窗口清晰的数据源，责任人不明的先补齐再谈采集
- 把「不确定算不算敏感」的资源单独放一个待定池，别急着设阈值，先观察两周看实际访问情况
数据流转层：谁把数据搬出去了
这一层的核心思路是盯出口不盯入口。日常读操作量本来就大，盯着没意义；真正值得报的是批量导出、跨库同步、非工作时间的大结果集查询这类「搬运」动作。判断标准不是绝对值，而是基线倍数：先跑一段时间统计出正常水位，之后看多少倍算异常。
| 监测项 | 看什么 | 判断思路 |
|---|---|---|
| 批量导出 | 单次导出的行数、文件体积 | 按该账号历史水位算倍数，超过基线的明显倍数再看 |
| 跨库同步 | 调用方身份、目标库位置 | 目标是否为外部或非授权存储，是就先报 |
| 大结果集查询 | 单次返回行数、查询时段 | 非工作时间的大量拉取，优先级高于工作时间的同量操作 |
| 调用来源 | 调用方 IP 归属地、是否首次出现 | 首次出现的来源单独标记，和后续动作串起来看 |
阈值这件事没有万能数字，按「基线倍数」比按固定值靠谱得多。每个数据源先安静跑一段时间，只记录不推送，等水位统计稳定了再设倍数门槛。整条链路的审计口径可以到 /guides/data-boundary-audit 核对，本文只负责指出哪几个点该设告警。
身份与凭据层：谁在用、是不是本人
异常登录这类信号单独看基本没用，新设备、异地、非常用时段，任何一条拎出来都可能是正常出差。它的价值在于和后续操作串起来：一个平时只读报表的账号，突然在凌晨从陌生 IP 登录并批量导出，这组合才有意义。凭据异常同理，Key 的作用范围和使用模式变了才是重点。
- 同一 Key 在多个不同 IP 同时调用，先看是不是被复制出去了，而不是急着封号
- 调用方 UA 突然变化、开始试探权限范围外的接口，这两个动作往往连在一起出现
- 账号权限和实际操作长期对不上——比如只读账号频繁尝试写操作，值得单独立规则
- 离职、转岗、外包交接这些窗口期，调用量的变化单独出一份日报给对应负责人
行为基线层：偏离日常动作的才有价值
基线要分两类建：人看操作节奏和访问对象的变化，服务看调用量和时段分布。同一个动作，放在一个每天正常跑批的服务身上很正常，放在一个平时只点几下网页的人身上就很可疑。基线的意义不是定义「什么算坏」，而是定义「什么算不一样」。
- 先观察，后告警新规则先跑静默模式，只记录命中情况不推送，看一段时间内的命中率和分布，再决定是否上线。
- 标注白名单窗口发版、数据迁移、跑批这些已知的高波动时段，用时间窗口标白，而不是直接关掉规则。
- 定期回看基线业务变了，基线也会漂。每次复盘时确认一下当前基线还代不代表正常状态。
典型异常动作有几个：深夜批量查询、连续试探没有权限的资源、短时间内遍历大量表名。这几个动作单看每个都不算证据，但组合起来往往就是有人在摸底。规则设计时要允许这种「组合触发」，而不是要求单条动作就定性。
外部渠道与第三方：数据出去了还能不能追
第三方接入是监测的天然盲区：对方怎么存、存多久、有没有二次转发，本地日志通常看不到。能做的至少有两块：一是盯对外接口的调用方身份和拉取频率，二是检查响应内容里有没有未脱敏的字段被带走。前者是行为，后者是内容，两条线都要有。
| 关注点 | 能本地监测到的 | 监测不到的 |
|---|---|---|
| 调用行为 | 调用方身份、频率、时段 | 对方内部谁在用这批数据 |
| 响应内容 | 是否含未脱敏字段 | 数据落到对方环境后怎么存 |
| 拉取模式 | 异常高频或异常的字段组合 | 是否存在二次转发 |
| 准入变化 | 接口权限、密钥的变更记录 | 对方自身的合规状态变化 |
如果链路中间用了中转或代理类服务，把它本身的信誉变化也纳入观察范围——服务方换了、口碑掉了，都值得重新评估一次接口暴露面。这块可以到 /sites 和 /rankings 看当时的目录与排行，具体数字以页面为准，这里不写死。
告警怎么设计才有人看
每条告警必须能回答三个问题：发生了什么、影响哪些数据、下一步该点哪里。答不全的，值班的人看了也不知道干什么，本质上就是无效告警。分级也不建议超过三档，分档依据是「是否需要人立刻介入」，而不是「看起来严不严重」——后者会导致大量中档告警堆积，最后谁都不看。
| 降噪手段 | 优先级 | 说明 |
|---|---|---|
| 白名单窗口 | 最高 | 发版、跑批等已知波动直接排除，不损失覆盖 |
| 合并同类 | 次高 | 同一主体短时间内的同类动作合并成一条 |
| 提高阈值 | 再次 | 调整倍数门槛，可能漏掉慢速异常 |
| 关规则 | 最低 | 等于放弃这条监测线，不到万不得已不用 |
值班交接要有固定字段，别靠口头交代：未闭环的告警有哪些、当时怎么判断的、下次该什么时候检查。这三个字段写清楚，换班的人才接得住。降噪手段按优先级来，能标白名单就别合并，能合并就别动阈值，动阈值是最后一步。
留证与报告：事后能复盘才叫监测
留证的目的是事后能复盘，不是为了存档好看。日志保留要覆盖「发现问题到处理完」的整个过程，涉及敏感字段的记录先脱敏再长期留存，别为了留证反而制造新的泄露面。证据要素有六项：时间戳、操作主体、数据对象、动作、结果、判定依据，缺一项事后就说不清。
- 时间戳
- 以统一时区为准，跨系统对齐，避免对不上时间线
- 操作主体
- 精确到账号或密钥，不写「某用户」这种模糊表述
- 数据对象
- 指明具体是哪张表、哪个盘、哪个接口，不要笼统说「敏感数据」
- 判定依据
- 写清是根据哪条规则、哪个基线判断的异常，方便复核
报告不要写成流水账。按「发现—判断—处置—残留风险」四段写，评审的人才看得下去，也才能判断这次处置到不到位。涉及对外报送或纠纷的场景，证据形式要求更严，留存口径可以参考 /guides/dispute-evidence-keep，具体标准以页面说明为准。
复盘的节奏：多久看一次才算在管
复盘不是走过场，要按不同周期看不同东西：周维度看告警命中率和误报率，月维度看规则覆盖跟不跟得上数据资产的变化，季维度重估一次整体监测范围。三个节奏各管一层，混在一起看反而什么都看不出。
- 周复盘看两个数：命中率、误报率，误报高的规则当周就要调
- 月复盘看覆盖：新上的业务系统有没有被纳入监测范围
- 季复盘重估范围：数据资产清单变了，监测对象就得跟着变
- 触发重估的信号要记牢：新系统上线、组织调整、外部服务变更、出现一次真实事件
- 每次复盘至少产出一条「这轮要改什么」，只写结论不动规则等于没做
常见问题
监测预警和风险评估是不是一回事，能互相替代吗？
不能。风险评估是周期性判断「哪里可能出事」，监测预警是持续判断「现在是不是正在出事」，一个管面一个管点。评估定下来的风险项，正好是监测要盯的对象；只有评估没有监测，等于写完清单就放着。
小团队没人值夜班，告警设多少合适？
宁可少而准。先把只影响合规留痕的低危项设成只记录不推送，只把涉及批量导出、越权访问、异常凭据调用这几类推到人手上。误报太多团队会集体无视告警，这比漏报更麻烦。
日志里带敏感字段，直接存会不会又变成新的风险点？
会。常规做法是采集端就做脱敏或哈希，原始内容不进长期存储，只保留可追溯的标识和操作元数据。确需留原值的，单独隔离存储并限制访问，同时记录谁查过这些日志。脱敏和加密怎么选可参考站内相关页面的对照。
怎么判断一条告警规则是真有用还是摆设？
看它有没有被处理过。上线一段时间内零命中，可能是阈值太松；命中很多但没人处理，说明分级或描述有问题。每条规则都应该有人能说出「上一次命中的是什么情况」。保持规则数量可控，比堆一堆规则更有效。
用了第三方模型或接口，这部分还要自己监测吗？
要，只是能监测的深度不同。至少记录调用了什么、传了什么字段、响应里有没有回带敏感信息，以及调用量的异常变化。对方内部怎么处理你看不到，所以对外传输前的脱敏和边界控制更重要。
