云服务器日志审计与操作追踪：谁在什么时候做了什么？

去年一个客户，服务器被入侵后，花了三天时间才搞清楚攻击者是怎么进来的、进来了做了什么。不是因为入侵手法有多高级，而是因为服务器上的日志分散在各处，有的被删了，有的没开，有的记录了但没人知道怎么看。他说：“如果能早一点知道谁在什么时候做了什么，就不会拖这么久。”

日志审计的价值，在出事之前看不出来，出事之后，它是唯一能告诉你真相的东西。

核心结论：日志审计不只是为了合规，更是为了在出事之后，你还能弄清楚“到底发生了什么”。

01 日志审计到底审什么？

等保2.0对日志审计有明确要求：审计范围应覆盖服务器上的每个操作系统用户和数据库用户；审计记录应包括事件日期、时间、用户、事件类型、事件结果等信息；日志留存时间不少于6个月。但合规只是最低要求，真正的日志审计要做到三件事：全记录、可追溯、能查询。

全记录：谁（用户/进程）、什么时候（精确到秒）、从哪来（登录IP）、做了什么（执行的命令或操作）、结果如何（成功/失败）。

可追溯：出事之后，能沿着日志链条还原攻击路径，知道对方进来了多久、动了什么、拿走了什么。没有完整的日志链，溯源就是猜。

能查询：日志不是存起来就完事了。出事的时候要能在几分钟内查到特定时间段的特定操作，而不是对着几百个日志文件从头翻到尾。

02 日志从哪里来？

系统日志（auth.log / secure）：记录登录行为——谁从哪个IP登录、登录成功还是失败、sudo提权操作。这是溯源的第一站。入侵者登录失败的那些尝试，全部记录在这里。

auditd审计日志：Linux内核级别的审计框架，能监控关键文件变更、特权命令执行、系统调用。比如/etc/passwd被谁改了、/etc/shadow被谁读了——这些普通系统日志不记录的事情，auditd都能记下来。配置后还能通过ausearch和aureport工具进行查询与统计。

云厂商操作审计（AWS CloudTrail / 阿里云ActionTrail）：记录通过控制台、API、SDK对云资源的所有操作。谁创建了服务器、谁删了安全组、谁改了存储桶策略——这些在服务器日志里看不到，但操作审计里都有。默认保留90天，可投递到日志服务长期保存。

03 集中日志管理：分散的日志等于没日志

日志分散在各台服务器上，出事时根本查不过来。入侵者还可能直接删掉本机日志。集中日志管理是溯源的基础。

方案一：云厂商日志服务（阿里云SLS、华为云LTS等）：服务器日志实时投递到中心化平台，支持快速检索、告警、可视化、长期存储。符合等保180天留存要求。

方案二：自建ELK：Elasticsearch + Logstash + Kibana，开源方案，灵活但需要自己维护。适合有运维能力的团队。

04 一个真实案例

某公司数据被内部人员泄露，怀疑是运维干的。但服务器日志只有登录记录，没有操作记录。后来启用了auditd，监控/etc/passwd、关键业务数据的访问和修改、特权命令执行。两周后，异常行为被捕获——某运维在凌晨通过sudo执行了数据导出命令，日志中完整记录了用户、时间、执行的命令。证据确凿。

写在最后

有日志不一定能审计，但没日志一定无法溯源。那家客户后来重建了日志审计体系：系统日志实时投递到SLS、auditd监控关键文件、开启云厂商操作审计。他说：“以前出事靠猜，现在出事能查。”这是日志审计的意义——不是为了让坏人进不来，而是在坏人进来之后，还能把整件事还原清楚。