📚 课程目录第4章审计日志的生成策略

4. 审计日志的生成策略：四个层面的要点

一份完整的审计日志，不能只盯着应用层。你想想看，如果数据库管理员偷偷删了表，应用日志里根本看不到。反过来，如果业务逻辑有漏洞，系统日志也抓不住。

我一般把日志生成分成四个层面：应用、系统、数据库、网络设备。每个层面都有它自己的“脾气”。下面我把这些年踩过的坑和总结的要点摊开来讲。

应用日志是审计链条中最贴近业务的一环。说白了，就是记录“谁、在什么时间、用什么IP、操作了什么资源、结果如何”。

我个人习惯在框架层用AOP（面向切面编程）统一拦截所有敏感操作。这样不会漏，也不会重复。我在一个金融项目里曾遇到这样的情况：开发人员只在controller里手动打日志，结果漏掉了批量导入接口的日志。后来加上注解式切面，问题才解决。

  应用日志必记字段：
  用户唯一标识（UID/用户名）
操作时间（精确到毫秒，UTC最佳）
源IP（不要信任前端传的，从request里拿）
操作类型（增/删/改/查/登录/登出）
资源ID及操作内容摘要
执行结果（成功/失败+错误码）

⚠️ 我曾经踩过一个坑：

某个项目用Log4j直接将敏感信息（身份证、银行卡号）打进了审计日志。审计合规检查时直接不合格。记住：应用日志要做脱敏，不要在日志里打印明文密码或完整证件号。

系统层面的日志主要来自操作系统本身。Linux 的 /var/log 目录里藏着大量宝藏：secure、auth.log、syslog、audit.log。Windows 则是事件查看器里的安全日志、系统日志、应用日志。

我建议重点盯三个方向：

认证与授权：SSH登录成功/失败、sudo提权、用户创建/删除。有一次我排查入侵事件，就是靠 auth.log 里的一行“Failed password for root”结合时间戳锁定了攻击源。
系统调用审计：Linux的 auditd 可以监控文件访问、进程启动等。把它和应用程序的PID关联起来，能追查到谁执行了危险命令。
时间同步：每个系统都要配NTP。你想想看，如果网络设备和应用的时钟差了十分钟，排查事件链时根本对不上。

# 配置 auditd 监控 /etc/passwd 的写操作
-w /etc/passwd -p wa -k user_modify

# 查看审计日志
ausearch -k user_modify | aureport -f

💡 小提示：

系统日志不要只收默认的。我习惯把 cron 任务执行日志、dmesg 内核消息也纳入审计范围，偶尔能发现定时器后门。

数据库日志是合规审计的重灾区。很多公司只开了慢查询日志，根本没开启审计功能。一旦有人直接连数据库改了数据，应用日志就形同虚设。

不同的数据库做法不同：

数据库	审计方式	关键配置
MySQL	通用日志 / 审计插件（如MariaDB Audit Plugin）	`general_log=ON` 或安装 `server_audit.so`
Oracle	Fine-Grained Auditing (FGA)	`DBMS_FGA.ADD_POLICY` 指定表、列、条件
PostgreSQL	`pgaudit` 扩展	`shared_preload_libraries = 'pgaudit'`
SQL Server	SQL Server Audit（服务器级别与数据库级别）	创建审计对象，绑定到操作

我在项目中遇到过数据库审计表被撑爆的情况。当时开了MySQL的general_log，忘记设置轮转，结果日志文件占满磁盘，数据库直接 hang 了。后来改用专门的审计插件，并设置日志大小上限和自动归档。

⚠️ 关键点：

网络设备日志常常被忽略，但它能提供全局的流量视图和访问控制记录。防火墙、路由器、交换机、负载均衡器都要考虑。

常见的日志类型：

防火墙日志：源/目标IP、端口、协议、动作（allow/deny）、连接持续时间。我习惯把“deny”动作单独拉出来，因为很多攻击试探会触发拒绝规则。
NetFlow / sFlow：流量统计，能看到谁在跟谁通信，流量有多大。如果发现内网某台服务器突然对外大量发包，很可能被入侵了。
ACL 变更日志：谁改了防火墙规则？什么时候改的？这是安全管理中的关键审计点。
VPN / 远程接入日志：用户名、源IP、连接时长、断开原因。有一次我们追踪数据泄露事件，就是从VPN日志里发现某员工在非工作时间从境外IP接入下载了全量客户数据。

# 思科设备 syslog 配置示例
logging host 192.168.1.100
logging trap warnings
logging facility local7

# 华为设备
info-center loghost 192.168.1.100

⏰ 时间同步是网络设备日志最大的坑。

我曾经排查一起事故，网络设备和服务器时间相差8分钟，导致安全事件关联完全失败。所有网络设备必须统一使用NTP，并且把时区设成UTC，不要用本地时间。

层面	主要日志来源	需要关注的事件	常见问题
应用层面	业务系统、中间件	用户操作、API调用、异常	漏打、脱敏不足、格式不一致
系统层面	操作系统、auditd、syslog	登录、提权、文件变更	时间不同步、日志轮转缺失
数据库层面	数据库审计插件/功能	DML、DDL、连接断开	审计撑爆、遗漏直接连接
网络设备层面	防火墙、路由器、交换机	ACL变更、拒绝流量、VPN	时间偏移、日志量过大

嗯，这四个层面覆盖了从业务到基础设施的全链路。实际落地时，我建议先做数据库和系统层面，因为它们最容易被合规检查员盯上。应用层面需要开发配合，网络层面则需要网络团队支持。但只要你把每个层面的要点都卡住，审计问题就不大。