3、审计日志设计：日志记录原则、关键字段设计、不可篡改性设计

日志设计这件事，我做了快十年审计项目，踩过的坑比写过的代码还多。很多人觉得日志嘛，就是随便记一笔，出事了再查。但真等到被监管问询、被黑客删库跑路的时候，你才发现——日志要么没记全，要么被人改了，要么根本不知道谁干的。

说白了，审计日志不是为了好看，是为了出事的时候能还原现场。今天我就把日志设计的三个核心问题掰开揉碎讲清楚。

3.1 日志记录原则：别等出事才后悔

我总结了一套原则，叫“五必须”。你照着做，基本不会出大问题。

原则	说明	我踩过的坑
必须全量记录	所有敏感操作、权限变更、数据访问、配置修改，一条不能少	曾经有个项目只记了增删改，没记查询日志，结果数据泄露了根本查不到谁看过
必须实时记录	操作发生的同时写日志，不能批量、不能延迟	有一次系统崩溃，批量日志没刷盘，丢了整整两小时的操作记录
必须按时间排序	每条日志要有精确到毫秒的时间戳，且全局统一时钟	多服务器时间不同步，排查问题时顺序全是乱的
必须独立存储	日志库和应用库分开，不能存在同一张表里	有人通过SQL注入把日志表truncate了，你想想看多可怕
必须定期归档	日志不能无限堆积，但也不能随便删，按法规保留至少6个月到2年	金融行业要求保留5年，我见过硬盘撑爆的案例

3.2 关键字段设计：5W1H 模型

日志字段怎么设计？我习惯用 5W1H 模型来拆解。说白了就是回答六个问题：谁、什么、何时、何地、结果、怎么做的。

下面这张图是我自己项目里常用的字段结构，你直接拿去用就行。

每个字段具体怎么设计？我给你一个实际项目里用的表结构：

字段名	类型	示例值	说明
user_id	VARCHAR(64)	zhangsan@company.com	谁操作的，必须是唯一标识，不能是显示名
user_role	VARCHAR(32)	admin / operator / auditor	操作时的角色，方便权限审计
action_type	VARCHAR(16)	DELETE	操作类型，枚举值：CREATE/READ/UPDATE/DELETE/EXPORT/LOGIN
target_type	VARCHAR(32)	user_table	操作对象类型，比如表名、API路径
target_id	VARCHAR(128)	user_id=10086	操作对象的具体标识
timestamp	DATETIME(3)	2025-03-15 14:23:45.123	精确到毫秒，使用UTC时间
source_ip	VARCHAR(45)	192.168.1.100	客户端IP，支持IPv6
user_agent	VARCHAR(256)	Mozilla/5.0 ...	浏览器或客户端信息
result_code	INT	0 或 403	0=成功，非0=错误码
detail	TEXT	{"old":"xxx","new":"yyy"}	变更前后的数据快照，JSON格式
session_id	VARCHAR(64)	abc123def456	会话ID，用于关联同一会话的多次操作

3.3 日志不可篡改性设计：防删、防改、防抵赖

日志如果可以被随意修改，那还不如不记。我见过最离谱的事——某公司DBA嫌日志占空间，直接 truncate 了审计表。所以不可篡改是日志设计的底线。

常用的方案有三种，我按推荐程度排个序：

方案一：写前校验 + 链式哈希（推荐）

这个方案我用了好几年，效果很好。核心思路是：每条日志都包含上一条日志的哈希值，形成一条链。如果有人改了中间某条，后面的哈希全部对不上。

// 伪代码示例：链式哈希日志写入
public class AuditLogger {
    private String lastHash;
    
    public void writeLog(LogEntry entry) {
        // 1. 计算当前日志内容的哈希
        String contentHash = SHA256(entry.toJson());
        
        // 2. 将上一条哈希拼接到当前日志
        entry.setPrevHash(this.lastHash);
        
        // 3. 计算整条日志的最终哈希
        entry.setHash(SHA256(contentHash + this.lastHash));
        
        // 4. 写入日志存储（数据库或文件）
        storage.append(entry);
        
        // 5. 更新内存中的上一条哈希
        this.lastHash = entry.getHash();
    }
    
    public boolean verifyChain() {
        // 从第一条开始，逐条验证哈希链
        // 任何一条不匹配，说明日志被篡改
    }
}

方案二：日志服务器独立部署

把日志写到另一台服务器上，应用服务器只有写权限，没有读和删权限。这样即使应用被攻破，攻击者也删不了日志。

我建议的架构是这样的：

方案三：日志文件只追加 + 定期备份

如果不用数据库，用文件系统存日志，那就用 append-only 模式。Linux 下可以用 chattr +a 设置文件只追加属性，root 用户都删不了。

3.4 避坑指南：我踩过的那些坑

• 时间戳不准：多服务器时间不同步，排查问题时顺序全是乱的。一定要用 NTP 统一对时，日志里存 UTC 时间。
• 日志字段太随意：有人把 user_id 写成中文名，有人写成工号，还有人写成邮箱。统一规范，用唯一标识。
• 忘记记录查询操作：很多系统只记增删改，不记查询。但数据泄露往往是通过查询发生的。查询日志必须记。
• 日志存储空间不足：曾经有个系统一天产生 50GB 日志，三天硬盘就满了。提前规划好日志轮转和归档策略。
• 日志权限管理缺失：开发和运维人员都能直接查日志，那日志里的敏感数据就全暴露了。日志本身也要做权限控制。