3. 审计日志基础：定义、作用与常见规范
审计日志这个东西，听起来很抽象，是吧？
我刚开始做安全合规项目时，也觉得它就是个“记录本”。后来被审计老师傅教育了几次，才发现这里面的门道深着呢。
这一章，我们就把它彻底讲清楚。
3.1 什么是审计日志？
说白了，审计日志就是系统里“谁、在什么时候、干了什么事、结果怎么样”的完整记录。
它不是普通日志。普通日志可能只关注程序跑没跑起来，而审计日志更看重“可追溯性”。
举个例子。我在某政务云项目里做过一次密钥销毁操作的复盘。当时系统出了个小故障，操作员说他没按过销毁按钮。我们翻出审计日志一看——时间、操作员IP、操作命令、返回码，一条线全对上了。有了证据，事故定责就清晰得多。
| 维度 | 普通日志 | 审计日志 |
| 记录对象 | 系统运行状态、异常 | 用户操作、权限变更、密钥生命周期 |
| 保留周期 | 常用固定天数（如7天） | 按法规保存6个月～数年，部分永久 |
| 篡改防护 | 可被运维人员后删或修改 | 防篡改设计（如签名链、哈希链） |
| 用途 | 调试、故障排查 | 安全审计、合规检查、法律取证 |
你想想看，如果密钥销毁这么关键的操作，日志还能被事后改掉，那整个信任体系就崩塌了。所以，审计日志要解决的核心问题就是：记录不可抵赖、不可篡改、全程可追溯。
3.2 审计日志的核心作用
作用其实就三条，但每一条都很有分量。
- 1. 溯责（Who done it）
用户执行了密钥销毁、授权审批、导出等操作，出问题后能回溯到具体的人和时间。我踩过的坑是：日志里只录了进程名，没录用户ID，结果一个服务重启后操作者成了system账号，根本查不到谁干的。后来我强制要求每一条审计日志都必须包含user_id和session_id。 - 2. 合规（证明给监管看）
密评、等保测评、行业检查时，审计日志是硬性要求。我曾经配合过一个密评整改项目，评审老师直接抽查了最近3个月的密钥销毁日志，要求每条都包含操作时间、操作员、操作类型和返回状态码。要是漏了或者格式不对，直接扣分。 - 3. 预警（异常行为检测）
系统自动化扫描审计日志，发现短时间内多次密钥销毁、非工作时间操作、异地IP登录等，立刻告警。这样能防住内部人员越权或者外部渗透。
这三条，你在设计SM2密钥销毁的审计日志方案时，得一条条对过去，才能避免以后被监管“翻旧账”。
3.3 常见审计规范解读
规范这东西，你看着头疼，但它是护身符。国内最常碰到的就是GB/T 22239，也就是等保2.0。
“等保”全称叫《网络安全等级保护基本要求》。它里面专门有“安全审计”这一节，条条框框列得很细。
等保2.0里关于审计日志的几个核心条款，我整理成了下面这个表。做SM2密钥销毁日志方案时，可以直接拿来当checklist用。
| 条款编号 | 要求内容 | 对密钥销毁的影响 |
|---|---|---|
| A.7.1.3.1 | 应启用审计功能，覆盖重要安全事件 | 密钥销毁必须列为“重要安全事件”， |
| A.7.1.3.2 | 审计记录应包括日期、时间、类型、主体、客体、结果 | 每条销毁记录必须包含完整六要素 |
| A.7.1.3.3 | 审计记录应受保护，防止未授权删除或修改 | 日志必须采用防篡改机制（如签名链） |
| A.7.1.3.4 | 审计记录保存期限应不少于6个月 | 密钥销毁日志建议保存2年以上 |
| A.7.1.3.5 | 应对审计进程进行保护，防止中断 | 销毁程序必须保证日志写入完成后才返回成功 |
除了等保，还有GB/T 39786-2021《金融信息系统安全审计指南》，对审计日志的格式、存储、查询有更细的要求。不过万变不离其宗，核心就三个字：保真、保完整、保时效。
3.4 审计日志字段设计的最佳实践
我推荐你使用这种结构来设计SM2密钥销毁的审计日志：
{
"event_id": "AUD-20250615-001",
"timestamp": "2025-06-15T14:30:00.123+08:00",
"user_id": "zhangsan@example.com",
"session_id": "sess_abc123def456",
"source_ip": "192.168.1.100",
"event_type": "SM2_KEY_DESTROY",
"target_key_id": "sm2-key-prod-v1-2025-001",
"operation": "销毁",
"result_code": 0,
"result_message": "成功",
"signature": "3046022100e4a3...（SM2签名值）"
}
这里面有个坑，我特别想讲一下。字段的签名那条，容易被忽略。
有些系统只给日志内容本体签名，但存储的时候日志被转成了JSON或别的格式。签名的时候没包含格式信息，结果核查时就得重新算。我建议把签名的范围定为日志的规范化字符串或二进制序列，这样不论怎么存、怎么展示，签名都能验。
曾经在某个项目中，研发团队为了“图方便”，审计日志字段的signature只签了明文部分，字段顺序严格按照他们在代码里写的顺序。结果后来日志被迁移到另一个存储系统，字段顺序变了，签名验不过……出问题时翻了好几天才找到根因。从那以后，我要求所有审计日志签名都走规范化的JSON Canonicalization或CBOR序列化。
3.5 一张图看懂审计日志知识体系
下面这张图，帮你把这一章的重点串起来。
从定义出发，向下分解为三个核心作用、三大规范体系，最后落地到字段设计与防篡改签名实践。SM2密钥销毁日志的设计就是在这个框架下展开的。
3.6 小结
这一章内容不多，但很基础。
你理解了审计日志是干什么的，知道了等保要求哪些字段、保存多久，就能知道你手头的SM2密钥销毁日志要写成什么样。