4、审计追踪实施：四层落地方案

审计追踪怎么落地？说白了，就是四个层面都要动手。数据库、文件系统、应用层、网络层，每一层都有自己的脾气。我这些年做项目，见过不少团队只盯着数据库，结果出了事啥也查不到。今天咱们把这四层拆开揉碎，一个个说清楚。

4.1 数据库审计追踪实现

数据库是审计追踪的重灾区。为什么？因为所有业务数据最终都落在这里。我见过最离谱的一次，某公司数据库被删了，结果审计日志也跟着一起被删了——因为日志存在同一个库里。你说这找谁说理去？

数据库审计，主流有三种方式：

实现方式	原理	优点	缺点
原生审计	数据库自带的审计功能	零侵入，厂商支持	性能开销大，功能有限
触发器审计	在表上创建触发器记录变更	灵活，可定制	维护成本高，影响DML性能
日志挖掘	解析数据库事务日志	无侵入，可追溯原始操作	技术门槛高，实时性差

我个人习惯用组合方案。核心业务表用触发器，全量审计用原生功能，归档分析用日志挖掘。举个例子，MySQL 的通用日志审计：

-- 开启通用查询日志
SET GLOBAL general_log = ON;
SET GLOBAL general_log_file = '/var/log/mysql/audit.log';

-- 或者用 audit plugin（推荐）
INSTALL PLUGIN audit_log SONAME 'audit_log.so';
SET GLOBAL audit_log_policy = 'ALL';

4.2 文件系统审计追踪

文件系统审计，很多人容易忽略。你想想看，敏感文档、配置文件、密钥文件，这些都在文件系统里。谁读了？谁改了？谁删了？没有审计，出了事就是一笔糊涂账。

Linux 下最常用的是 auditd。配置起来其实不复杂：

# 安装 auditd
yum install audit -y
systemctl start auditd

# 监控 /etc/shadow 的读写
auditctl -w /etc/shadow -p rwxa -k shadow_access

# 查看审计日志
ausearch -k shadow_access

Windows 下呢？用安全事件日志。我记得有一次帮一家金融公司做审计，他们所有的文件服务器都在 Windows 上。我建议开启文件审计策略：

• 启用「审核对象访问」策略
• 在文件/文件夹属性中配置 SACL
• 设置日志大小至少 1GB，避免日志被覆盖

4.3 应用层审计追踪

应用层审计，这是最贴近业务的。数据库审计只能看到 SQL，但不知道这个 SQL 是哪个用户、哪个操作触发的。应用层审计补上了这个缺口。

怎么做？说白了，就是在业务代码里埋点。我推荐用 AOP（面向切面编程）的方式，统一拦截关键操作。比如 Spring Boot 里：

@Aspect
@Component
public class AuditAspect {
    
    @Around("@annotation(auditLog)")
    public Object logAudit(ProceedingJoinPoint pjp, AuditLog auditLog) throws Throwable {
        // 记录开始时间
        long start = System.currentTimeMillis();
        
        // 获取当前用户
        String user = SecurityContextHolder.getContext().getAuthentication().getName();
        
        // 执行原方法
        Object result = pjp.proceed();
        
        // 记录审计日志
        AuditEvent event = new AuditEvent();
        event.setUserId(user);
        event.setAction(auditLog.action());
        event.setResource(auditLog.resource());
        event.setResult("SUCCESS");
        event.setDuration(System.currentTimeMillis() - start);
        
        auditLogger.save(event);
        
        return result;
    }
}

应用层审计要记录哪些信息？我列了个清单：

• 用户身份：谁做的？用户ID、角色、IP地址
• 操作类型：增删改查？导出？审批？
• 操作对象：哪个资源？哪个订单？哪个客户？
• 操作结果：成功还是失败？失败原因是什么？
• 时间戳：精确到毫秒
• 上下文：浏览器信息、设备信息、会话ID

4.4 网络层审计追踪

网络层审计，很多人觉得这是安全团队的事。其实不然。数据安全合规里，网络层审计能回答一个关键问题：数据到底有没有被非法外传？

网络层审计主要做三件事：

1. 流量捕获：用端口镜像或者 TAP 设备，把网络流量复制一份出来
2. 协议解析：解析 HTTP、SQL、FTP 等协议，提取关键信息
3. 会话重建：把请求和响应关联起来，还原完整的操作过程

举个例子，用 tcpdump 捕获数据库流量：

# 捕获 MySQL 3306 端口的流量
tcpdump -i eth0 -s 0 -w mysql_traffic.pcap port 3306

# 用 Wireshark 分析，或者用 ngrep 实时查看
ngrep -d eth0 -W byline port 3306

网络层审计的典型部署架构：

组件	功能	部署位置
流量采集器	端口镜像、流量复制	核心交换机
协议解析引擎	解析 HTTP/SQL/SSH 等协议	独立服务器
存储与索引	存储解析后的审计数据	分布式存储集群
告警与分析	异常检测、规则匹配	管理平台

4.5 四层联动：审计追踪的完整拼图

单看某一层，都有盲区。数据库审计看不到谁发的 SQL，应用层审计看不到网络层面的异常，网络层审计看不懂业务逻辑。四层联动，才能拼出完整的操作轨迹。

我举个例子。假设有个内部员工批量导出客户数据：

• 网络层：发现大量数据流出，流量异常
• 应用层：记录到用户 A 在 10 分钟内执行了 500 次导出操作
• 数据库层：看到大量 SELECT 查询，返回了上百万条记录
• 文件系统：发现导出文件被保存到了非授权目录

四层证据一交叉，谁也赖不掉。这就是审计追踪的真正价值。