代码审计里的日志集中告警：六个检查点

时间戳统一到 UTC，跨时区排查时本地时间会误导判断

正着读代码容易漏，因为入口太多；反着找危险点，数据流只有那么几条。

先说结论

先列危险点，再回溯入口，最后确认校验与权限。

• 检查点一：所有外部入口是否都过统一校验
• 检查点二：危险函数是否集中封装
• 检查点三：校验是否只做一次、是否白名单
• 检查点四：权限判断是否在服务端
• 检查点五：错误信息是否泄露内部细节
• 检查点六：是否有兜底日志

检查点一：入口

采集端必须有本地缓冲，网络抖动时直接丢弃是很常见的设计缺陷，缓冲要按峰值流量算足，磁盘也要预留一倍。

把入口列全：HTTP 参数、请求头、上传、消息队列、定时任务的外部输入。漏一个就白审。

检查点二：危险点

全文索引的成本是原始存储的五到十倍，冷数据应该只做归档，超过 30 天的查询本来就少，归档要能查回来。

检查点三：校验逻辑

告警分级没有出口规则，P1 会被 P3 淹没，最后没人再看，分级没有出口等于没有分级，出口规则要写下来。

看到「先替换再校验」「只在一个接口校验」这两种写法，基本可以直接标红。

这个问题的几个审计细节

实际代码里最容易漏的几处：

• 时间戳统一到 UTC，跨时区排查时本地时间会误导判断

检查点四到六

时间戳统一到 UTC，跨时区排查时本地时间会误导判断。

越权是审计里性价比最高的方向：少一行判断，就是一个中高危。错误信息要统一，日志要记入口摘要。

再补充几点

这几条不改变结论，但会改变你评估风险时的顺序。

• 日志量失控的主因是 debug 级别误开到生产，能占到总量的七成
• 保留 180 天不是数字游戏，是为了能回溯三个月前的一次异常，到期前先确认冷数据查得回来
• 所有日志都开 debug，磁盘一周就写满
• 告警全发到同一个群，两周后全员免打扰
• 采集端不做缓冲，重启期间的日志全丢

审计的产出不是「找到几个洞」，是「知道这类洞在哪个模式里反复出现」。