4. 审计日志的基础概念归纳总结
好，我们进入第4章。说实话，审计日志这个词在很多安全文档里都被说得玄乎其玄。其实你把它想简单点——就是一本带时间戳的账本，记下谁在什么时候、通过什么方式、干了什么事。对于TLS握手来说，这本账本里记的就是加密通道建立过程中的关键参数。
我刚开始做安全审计时，总觉得日志就是随便存点数据，够用就行。后来有一次排查一个中间人攻击事件，客户说“我们的TLS连接没问题啊”，我一翻日志发现ServerHello里用的居然是RC4算法——那已经是2015年了。从那以后我才明白：日志里记什么、怎么记，直接决定你能不能在事后把真相挖出来。
4.1 什么是审计日志？
审计日志（Audit Log）是系统运行过程中产生的、具有不可否认性的记录集合。它在TLS场景下至少需要满足三个特性：
- 时序性：每条记录必须带精确的时间戳，毫秒级甚至微秒级。我见过有人只用日期，结果两个握手事件前后顺序根本分不清。
- 完整性：日志一旦写入，就不能被篡改。要么用防篡改存储（如WORM设备），要么用哈希链做完整性校验。
- 可追溯性：能从日志反推出完整的握手交互过程，包括加密套件协商、证书链、DH参数等。
说白了，审计日志就是你把TLS握手的过程拍成电影，而不是只留一张剧照。只记录“握手成功/失败”那种日志，我称之为“废纸”。
4.2 审计日志的核心字段
你想想看，一个完整的TLS握手需要记录哪些东西？我大致列了个清单。这张表你可以直接拿去当设计参考：
| 字段 | 说明 | 示例值 |
|---|---|---|
session_id |
会话标识，用于关联同一个TLS会话的多次握手（如会话恢复） | a3f2c1... (32字节hex) |
client_random |
客户端生成的32字节随机数，用于计算主密钥 | 0x7c... (32字节hex) |
server_random |
服务端生成的32字节随机数 | 0x9e... (32字节hex) |
cipher_suite |
最终协商的加密套件 | TLS_AES_128_GCM_SHA256 |
tls_version |
协商后的TLS协议版本 | TLSv1.3 |
server_cert_chain |
服务端证书链的指纹（SHA-256）或PEM | sha256$ab... |
key_exchange_type |
密钥交换方式：DHE / ECDHE / PSK / 静态DH | ECDHE |
sni |
客户端请求的Server Name Indication | api.example.com |
client_supported_versions |
客户端支持的TLS版本列表（TLS 1.3新增） | [1.3, 1.2, 1.1] |
error_code |
握手失败时的TLS Alert错误码 | 40 (handshake_failure) |
重点：记住，千万不要只记成功握手的日志。失败的握手往往能揭示攻击尝试或配置错误。我曾经因为没记失败日志，被客户追问“那个IP是不是在扫描我们？”——我只能说不知道。
4.3 日志记录的时机与粒度
什么时候该写一条审计日志？大多数人只在握手完成时记一笔。但我建议至少分三个节点：
- ClientHello到达时：记下客户端发来的随机数、支持的套件列表、SNI。这里是追踪攻击源头的黄金窗口。
- ServerHello发出时：记下服务端选择的套件、版本、随机数。如果后面出了事，可以对比这两条日志看协商过程是否被篡改。
- 握手完成或失败时：记下最终结果，包括证书验证状态、会话复用标记。
为什么要记三次？因为中间人攻击往往会在ClientHello和ServerHello之间动手脚。比如降级攻击：客户端说“我支持TLS 1.2和1.3”，中间人篡改成“只支持1.2”，服务端就降级了。如果你只有最后一条日志，根本看不出降级。
4.4 日志的格式与存储
关于格式，我个人偏爱结构化日志（JSON）。为什么？因为TLS握手参数多是键值对，JSON天然适合。给你看看我曾经用的一个日志示例：
{
"timestamp": "2025-04-07T14:32:18.123Z",
"session_id": "a3f2c1d4...",
"event": "client_hello",
"src_ip": "203.0.113.5",
"src_port": 44321,
"sni": "api.example.com",
"client_version": "TLSv1.3",
"supported_ciphers": ["TLS_AES_128_GCM_SHA256", "TLS_CHACHA20_POLY1305_SHA256"],
"extensions": ["key_share", "supported_versions", "psk_key_exchange_modes"]
}这样的日志可读性强，并且方便Elasticsearch等工具做全文检索。你想想看，如果要查某个SNI相关的所有握手记录，一条查询语句就搞定了。
存储方面，我建议：
- 写入时append only，绝不允许修改或删除。
- 按天分片，保留至少180天（法规合规要求常是1年）。
- 对包含随机数、证书指纹的日志，考虑加密存储（虽然随机数本身不敏感，但结合其他信息可能泄露会话密钥）。
4.5 审计日志的生命周期
这里我必须画一张图，帮你理清审计日志从产生到消亡的完整流程。很多同学只关心怎么写，却忽略了日志怎么用、怎么丢。
这张图展示了日志从握手事件触发，到最终销毁的完整链路。注意中间有一个“检索与分析”环节——日志如果不被用起来，它就是一堆垃圾字节。我见过不少团队把所有日志一股脑写到HDFS里，从来没人查，等于白存。
4.6 关键设计原则
最后，我总结几条实用原则，帮你避免常见的设计失误：
- 最少必要记：不要把所有报文都存下来。TLS握手报文有的能达到几KB（特别是证书链），全存的话存储成本飙升。只记关键参数和指纹就行。
- 时间同步：所有服务端的时间必须用NTP对齐。我遇到过因为时间差了一秒，同一握手的两次事件日志跨天了，排查时各种混乱。
- 日志级别与采样：生产环境建议所有握手全部记录（全量审计）。如果流量极大（几十万/秒），可考虑按源IP或SNI做采样，但必须保证失败握手100%记录。
- 不可否认性：日志数据至少定期计算一次哈希，保存到另一个独立的完整性日志中。这样如果有人想改历史日志，你能立刻发现。
一句话总结：审计日志不是“可有可无的附加功能”，它是安全运维的最后一道防线。今天你懒得多写几个字段，明天出事故时就只能两手一摊。
嗯，这一章的基础概念就这些。下一块内容咱们会深入具体的TLS握手参数，比如Cipher Suite的细节、Key Share的结构，到时候结合日志字段一起看会更直观。