安全审计功能有哪些

做运维或系统管理的人常遇到这种场面：出了事要复盘，翻遍日志发现关键操作没记、记了的又缺主体和结果，只能靠猜。这篇不谈概念，直接给一份安全审计能力清单——日志该覆盖哪些字段、告警怎么分级和排优先级、追溯时按什么顺序查，以及哪些条件下这套做法不适用。

做运维或系统管理的人常遇到这种场面：出了事要复盘，翻遍日志发现关键操作没记、记了的又缺主体和结果，只能靠猜。这篇不谈概念，直接给一份安全审计能力清单——日志该覆盖哪些字段、告警怎么分级和排优先级、追溯时按什么顺序查，以及哪些条件下这套做法不适用。

下面的内容按「先分清边界、再补字段、然后排覆盖优先级、定告警规则、定追溯顺序、管留存防篡改、最后做一次自查」的顺序走，每一步都尽量落到能直接动手的动作上。哪一步卡住了，说明那一环就是当前最该补的缺口。

先分清：日志、监控、审计不是一回事

这三样经常被混着说，但判断标准不一样。监控关心的是系统稳不稳，比如延迟、错误率、资源水位；审计关心的是谁在什么时候对什么做了什么、结果怎么样。两者数据源可以共用，但字段要求差很多，监控里一个计数就够了的地方，审计里必须留下主体和结果。

判断一条日志能不能当审计用，有个很直接的办法：把这条日志单独拎出来，能不能回答「谁、何时、对什么、做了什么、结果如何」这五问。答不全就是审计缺口。普通应用日志之所以顶不上，通常就是缺主体、缺结果、缺上下文（从哪来、改前改后是什么）。

审计日志最小字段清单

字段这件事，宁可先少而准，也别先多而乱。下面四组是底线，缺哪组都会让后面的追溯断链。字段命名和格式要固定下来，别这次叫 user、下次叫 uid，否则跨服务串联时得写一堆映射规则。

主体维度

账号标识、来源 IP 与大致地理位置、凭证类型是长期 Key 还是临时凭证、会话或请求 ID

动作维度

操作类型、目标对象标识、参数摘要（敏感值脱敏后保留结构）、操作前后的值对比

结果维度

成功还是失败、失败原因分类、耗时、被拒绝时命中的策略名

时间维度

统一时区和精度，跨服务至少留一个请求 ID 能串起来

参数摘要这块容易走极端：要么全记，把身份证号、手机号原样写进日志；要么干脆不记，事后完全不知道请求里带了什么。合理的做法是保留结构、脱敏取值，比如把手机号写成前三位加后两位，把订单号保留格式但去掉中间段。脱敏要在写入前完成，写进去再脱敏等于没脱敏。

哪些操作必须进审计，按这个优先级排

不可能所有操作都按同一力度记，按影响面排优先级更现实。下面这张表可以直接拿去对着现有系统打标，标完就知道缺口大概在哪。

落地动作很具体：把现有接口清单拉出来，逐条打标。标不出来的那些接口，说明连谁在调都不清楚，得先补文档再加日志。这个顺序别反，先加日志再补文档，最后记了一堆看不懂的东西。

告警怎么分级，别让真事件淹在噪音里

分级依据建议用「影响面乘可逆性」：涉及凭证、资金、大批量数据外发的直接顶格；配置类变更次之；单点失败再次之。可逆性很关键——能一键回滚的改动和不可逆的数据外发，不该是同一个级别。

• 每条告警要有明确的处置人和处置时限，没有归属的告警等于没有告警
• 抑制规则要写下来：维护窗口、已知批处理时段、灰度发布期的正常抖动，都要提前登记
• 告警内容里要带足上下文：谁触发的、什么对象、从哪来，否则收到的人还得先查一遍才能判断
• 定期回看误报率，连续误报的规则要么改阈值要么降级，别让它继续消耗信任
• 顶格告警建议走独立通道，别和日常通知混在同一个群里

有个反面情形值得提一下：如果团队只有一两个人轮值，告警条数比告警质量更致命。半夜被叫醒几次之后，人就会开始关通知。这种情况下宁可先只留顶格那几条，跑顺了再往上加。

出事后的追溯顺序：从结论往回到证据

追溯最忌讳一上来就全量搜日志，搜索框一敲，几万条结果出来，人先懵了。合理的顺序是先缩小范围，再逐层回推证据。下面这套顺序按步骤走，能省掉大量无效排查。

1. 锁定时间窗和影响对象先确定异常大概从什么时候开始、影响了哪些对象，把范围缩到一个可处理的大小，别全量搜。
2. 用请求 ID 或会话 ID 串链路拿一个具体请求去跨服务串联，找出是哪一跳开始出现异常，确认是应用层、网关层还是底层。
3. 回到主体看历史行为这个账号或凭证还做过什么，同期有没有别的 IP、别的设备在用同一个身份，跨地域同时出现通常是强信号。
4. 检查变更记录异常开始前有没有配置、权限、依赖版本的改动。很多看起来像攻击的现象，其实是自己人改出来的。
5. 交叉验证并留档把结论和支撑证据一起记下来，别只留一句结论，下次复盘还得重新查一遍。

排查工具和监控口径可以参考站内 /tools/quality-monitor 的思路，具体指标和展示形式以页面当时的内容为准。追溯过程中还有一个常被忽略的点：时间。跨机器时间不同步，链路顺序就会错乱，先统一时钟源再谈聚合。

留存与防篡改：审计数据本身也得被保护

审计日志的价值在于它可信，如果谁都能改，那它出事时就没有证据效力。留存期要同时满足业务复盘和合规要求，两边取长的那个，别只按磁盘预算砍。磁盘紧张可以分层存储，冷数据放便宜介质，但别直接删。

• 审计日志与业务库分离存储，写权限收窄到写入通道，日常运维账号不具备改写或删除能力
• 定期做完整性校验，比如生成摘要或哈希链，能证明某段日志没被动过
• 访问审计库本身也要留记录，谁查过、导出过什么，这层元审计容易被忽略
• 脱敏在写入前完成，事后再处理的产品形态救不回已经泄露的内容
• 备份和恢复演练要覆盖审计库，别等到要用时才发现备的是空的

哪些字段不该进日志、留存策略该怎么配，可以对照站内 /log-redaction-retention 的清单，按自己业务的实际要求取舍。这套做法在合规审计场景下最有用；如果只是内部小工具，可以简化，但主体和结果这两个字段建议保留。

一次可执行的审计能力自查，按顺序做

上面的内容看一遍容易，真正判断有没有缺口还得动手验。下面这五步可以安排在一个下午完成，产出是一张缺口清单，不是一份报告。

1. 列敏感操作清单把系统里会改状态、碰权限、动数据的操作列出来，逐条标注当前有没有审计记录。
2. 抽验还原随机取三条历史操作，试着只靠日志还原完整过程。还原不出来就记下缺哪个字段，别只记「不行」。
3. 测一条高优先级告警人为触发一条顶格规则，看是否真的通知到人、多久到、通知里信息够不够判断。
4. 查权限和留存看一眼审计库的访问名单，确认没有多余的写权限；确认留存策略是配置真的生效，而不是文档里写着。
5. 补整体检查上线前或大改前的整体安全面可以对照站内 /prelaunch-security-checklist，避免只盯审计漏掉别的口子。

自查的频率取决于变更节奏：频繁改权限和配置的团队，建议每次大改后跑一遍抽验；相对稳定的系统，按季度过一遍清单也够。重点不是形式，而是每次都能发现一两个具体缺口。

这套东西什么时候不够用

审计能力再全也有边界，下面几种情况单靠日志解决不了，提前知道能省掉不少误判。写清不适用条件，比多列几个功能点更有用。

审计的目标不是记下一切，而是在需要的时候能说清一件事的来龙去脉；记不全要补，记太多没人看同样是问题。