等保 2.0 的安全审计要求对邮件日志意味着什么？审计记录本身要怎么保护？

阅读 GB/T 22239-2019 时容易忽略的一点是：安全审计并非只在一处出现。它在安全区域边界层面出现一次（针对边界与重要网络节点），在安全计算环境层面又出现一次（针对操作系统、数据库、应用），安全管理中心层面还有独立的审计管理与集中管控要求。

这种重复不是冗余，而是分层：边界审计回答「流量从哪来到哪去」，计算环境审计回答「谁在系统里做了什么」，管理中心审计回答「审计本身是否被正确管理」。邮件系统横跨这三层，因此三处要求都要落。

实践中最常见的缺口，是只做了边界层的 SMTP 日志，而漏掉了计算环境层的应用行为日志——谁登录了谁的邮箱、谁设置了自动转发、谁被授予了代收权限、谁批量导出了邮件。这些恰恰是账号失陷与内部数据外泄场景下最关键的记录，也恰恰是默认配置下最容易缺失的记录。

标准对审计记录内容的要求是明确的：审计记录应包括事件的日期和时间、用户、事件类型、事件是否成功及其他与审计相关的信息。这四项是硬性的，把它们逐一对照邮件系统，会发现每一项都有坑。

• 日期和时间。多台服务器时钟不同步，日志就无法拼接成时间线。必须统一时间源，并在日志中记录时区。跨时区的组织尤其要留意——同一事件在两台机器上相差数小时的记录，在追溯时会直接导致误判。
• 用户。这是邮件系统最难的一项。SMTP 会话可能是匿名的（外部投递），此时「用户」应记录为可追溯的对端标识（源地址、EHLO 名、TLS 证书主体）；提交与访问会话则必须记录认证主体。把信头 From 当作「用户」记录是错误的，它不经认证，可以任意伪造。
• 事件类型。需要区分：连接、认证、投递、拒绝、隔离、放行、登录、读取、导出、规则变更、权限变更。类型划分粗糙会导致后续无法按类检索。
• 是否成功。失败必须记录，且要记录失败原因。认证失败的记录比认证成功的记录更有价值——密码喷洒攻击的全部痕迹都在失败记录里。若系统为了减少日志量而丢弃失败记录，就是主动放弃了最重要的检测数据。

此外应记录 SMTP 层面的响应码与增强状态码。RFC 5321 定义的响应码体系使得拒绝原因可被机器解析，把它原样记入日志能大幅降低后续分析成本。

标准中有一条独立要求：应对审计记录进行保护，定期备份，避免受到未预期的删除、修改或覆盖等。这条要求的技术含义比字面看起来重得多。

「覆盖」二字尤其值得注意。大多数日志系统的默认行为就是滚动覆盖——按文件大小或数量循环写入，旧记录被自动丢弃。在流量突增或遭受攻击时，日志量激增会导致滚动加速，结果恰恰是攻击发生时段的记录最先被覆盖掉。这是一个非常典型且隐蔽的失效模式。

可落地的保护措施：

1. 集中收集，实时外送。日志产生后尽快离开产生它的主机。攻击者取得主机权限后清理本地日志是标准动作，本地留存的日志在取证上价值有限。
2. 写入即不可改。集中侧采用追加写入、写后不可修改的存储方式，并对存储介质本身做访问控制。
3. 完整性校验。对日志批次计算摘要并单独保存，使「日志是否被动过」成为一个可验证的问题而非一个信任问题。
4. 容量与滚动策略要按峰值算。按平均流量估算的容量，在攻击时段必然不够。应设置容量水位告警，并明确「日志写满时」的行为——是停止服务还是继续覆盖，这是一个需要事先决策的取舍，不能留给默认值。
5. 对日志的访问本身也要审计。谁查询了、导出了哪些日志，需要留痕。邮件日志可还原出组织的通信关系图，属于高敏感数据。

留存期是合规推理中最容易失衡的一点。网络安全法要求采取监测、记录网络运行状态与网络安全事件的技术措施，并按照规定留存相关的网络日志不少于六个月。这是下限。

但另一个方向同样有约束。邮件日志几乎必然包含个人信息——收发件人地址可识别到具体自然人，连接与登录记录可反映其行为轨迹与作息规律。个人信息保护法确立了处理个人信息应当遵循合法、正当、必要与诚信原则，不得过度处理，并要求个人信息的保存期限应当为实现处理目的所必要的最短时间，法律、行政法规另有规定的除外。

正是这个「另有规定的除外」，为网络安全法的留存义务提供了合法性基础；但它的射程仅限于该义务所要求的范围，不能被扩张解释为「所有邮件数据都可以无限期保存」。

由此得到一个可操作的分层框架：

• 会话元数据（时间、地址、信封、结果、状态码）：信息量小、追溯价值最高、个人信息浓度相对低，应优先保障其完整性与较长的保留期。
• 认证与访问记录：账号失陷溯源的核心依据，保留期应与安全事件的典型发现周期匹配。失陷往往在数月后才被发现，保留期若只到下限，很可能刚好取不到失陷当时的记录。
• 邮件内容与附件：个人信息浓度最高，其留存必须单独论证目的与范围，并配套更严的访问控制与审批。不要把「归档全部邮件」与「日志留存义务」混为一谈，二者依据不同、约束不同。

1. 做一份日志清单。逐项列出：日志类别、产生组件、字段、保留期、依据、存储位置、访问权限、销毁方式。说不清依据的字段，就是应当考虑不记录的字段；说不清保留期的日志，测评时无法举证。
2. 验证「覆盖到每个用户」。随机抽取几个账号，验证能否从日志中完整还原其一段时间内的收发与登录行为。抽不出来，说明覆盖不完整。
3. 验证时间线可拼接。取一封已知邮件，从网关入站、策略判定、投递落盘到用户读取，看能否用统一标识串起全链路。串不起来说明缺少贯穿性的报文标识。
4. 验证防篡改真的有效。在测试环境尝试删改一条集中侧日志，确认能被发现或被拒绝。没有被验证过的防篡改机制，不能假定它有效。
5. 按 RFC 3227 的原则准备取证流程。该文档给出了证据收集与归档的通行做法，核心是按易失性顺序收集、记录每一步操作与时间、保持保管链连续。审计日志是取证的原料，取证流程是把原料变成证据的工序，两者缺一不可。
6. 到期真正销毁。保留期到了却仍留在备份磁带、离线归档与测试环境中，等同于没有保留期。销毁流程必须覆盖全部副本并留下销毁记录。