1. 日志审计基础：日志的定义与价值、日志标准与规范、法律法规要求
大家好，我是你们这堂课的老朋友。咱们今天聊点实在的——日志。很多人觉得日志就是一堆没用的文本，出事了才想起来翻一翻。说实话，我刚开始干安全那会儿也这么想。直到有一次，一个APT攻击潜伏了半年，最后是靠着一行被忽略的Syslog揪出来的。从那以后，我再也不敢小看任何一条日志了。
1.1 日志到底是什么？它的价值在哪？
日志，说白了就是系统、应用、设备在运行过程中留下的“脚印”。你想想看，一个系统每天处理成千上万个请求，谁来了、干了什么、结果如何，这些信息都会被记录下来。这就是日志。
它的价值，我总结为三点：
- 溯源取证：出了安全事件，日志就是你的“监控录像”。谁在什么时间、从哪个IP、执行了什么操作，一查便知。
- 故障排查：系统崩了，应用挂了，日志里往往藏着最直接的线索。我遇到过好几次，开发说“代码没问题”，结果一看日志，SQL注入都打进去了。
- 合规审计：等保2.0、GDPR这些法规，都明确要求留存日志。没有日志，你连合规的门槛都摸不到。
核心观点：日志不是“可有可无”的附属品，而是安全运营的基石。没有日志，你就像在黑暗中走路，摔了都不知道怎么摔的。
1.2 日志标准与规范：RFC 5424 和 Syslog
聊到日志，就绕不开Syslog。这是目前最主流的日志传输协议。早期用的是RFC 3164，但那玩意儿格式太随意了，解析起来特别痛苦。后来有了RFC 5424，算是给Syslog立了个规矩。
RFC 5424 定义了一个结构化的日志格式，包含以下几个关键字段：
| 字段 | 说明 | 示例 |
|---|---|---|
| PRI | 优先级（设施+严重级别） | <14> |
| VERSION | 协议版本号 | 1 |
| TIMESTAMP | ISO 8601 格式的时间戳 | 2024-01-15T10:30:00+08:00 |
| HOSTNAME | 主机名或IP | web-server-01 |
| APP-NAME | 应用名称 | nginx |
| MSGID | 消息ID，用于标识日志类型 | TCP_IN |
| STRUCTURED-DATA | 结构化数据（键值对） | [example@32473 iut="3" eventSource="Application"] |
| MSG | 日志正文 | Connection from 10.0.0.1:443 |
举个例子，一条标准的RFC 5424日志长这样：
<14>1 2024-01-15T10:30:00+08:00 web-server-01 nginx - TCP_IN [example@32473 iut="3" eventSource="Application"] Connection from 10.0.0.1:443我个人习惯，在搭建日志平台时，强制要求所有设备都输出RFC 5424格式。为什么？因为结构化数据太好用了。你可以直接提取字段做关联分析，不用再写一堆正则去解析。
避坑指南：我曾经遇到过一个项目，客户说“我们所有设备都支持Syslog”，结果一对接，发现防火墙用的是RFC 3164，交换机用的是私有格式，数据库压根不支持Syslog。嗯，这里要注意，一定要提前确认所有数据源的日志格式，不然后面解析起来会非常痛苦。
1.3 日志审计的法律法规要求
聊完技术，咱们再聊聊法规。很多人觉得法规是法务的事，跟技术没关系。其实不然，法规直接决定了你要存什么日志、存多久、怎么保护。
1.3.1 等保2.0 的要求
等保2.0（网络安全等级保护2.0）是国内最核心的安全合规标准。它对日志审计的要求，主要集中在以下几点：
- 日志留存：网络设备、安全设备、服务器等关键设备的日志，至少保存6个月。
- 日志覆盖：需要记录用户行为、系统事件、异常流量、安全事件等。
- 审计能力：能够对日志进行集中收集、分析、告警，并且审计记录不能被删除或篡改。
- 时间同步：所有设备的时间必须统一（NTP同步），否则日志时间对不上，分析起来就是一团乱麻。
我记得有一次做等保测评，客户说“我们日志都存了”，结果一查，防火墙日志只存了3个月，服务器日志只存了1个月。测评老师当场就给了个高风险。所以，日志留存时长是硬指标，千万别打折扣。
1.3.2 GDPR 的要求
GDPR（通用数据保护条例）是欧盟的法规，但如果你有海外业务，或者系统里存了欧盟公民的数据，那就得遵守。它对日志审计的要求更严格：
- 数据最小化：只记录必要的信息，不要过度采集。比如，用户访问日志里，记录IP和URL就够了，没必要记录用户的完整姓名和身份证号。
- 访问控制：日志本身也包含敏感信息，必须严格控制谁能看、谁能改。
- 删除机制：用户有权要求删除自己的数据，包括日志中的个人信息。这就要求你的日志系统支持按用户ID或IP进行精确删除。
- 泄露通知：如果发生数据泄露，必须在72小时内通知监管机构，并且日志要能支撑你快速定位泄露范围和影响。
重要提醒：GDPR对日志的“可删除性”要求非常高。我曾经帮一家跨境电商整改日志系统，他们原来的做法是把所有日志一股脑存到Elasticsearch里，结果用户要求删除数据时，发现根本没法精确删除，只能重建索引。最后花了整整两周才搞定。所以，设计日志系统时，一定要考虑数据的生命周期管理。
1.4 小结
好了，咱们今天把日志的基础聊透了。总结一下：
- 日志是安全运营的基石，价值在于溯源、排障、合规。
- RFC 5424 是Syslog的标准化格式，建议优先采用。
- 等保2.0要求日志至少存6个月，GDPR要求数据可删除、可审计。
下一章，咱们会深入聊聊日志采集的架构设计，包括怎么处理海量日志、怎么保证日志不丢、怎么应对各种奇葩的日志格式。到时候见！