某天运营反馈网站首页被篡改了一小时，运维翻遍了Nginx日志，发现那个时间段的日志居然被清空了。没有日志，安全事件就是一笔糊涂账——知道出了事，但不知道怎么出的、谁干的、影响了多少用户。
日志安全审计这件事，很多团队的理解还停留在Nginx access log层面。但真正能支撑安全追溯的日志体系，远不止于此。
一、三类日志缺一不可
第一类是访问日志，记录所有HTTP请求。但默认的Nginx日志格式不够用，需要扩展字段：加上请求体大小、响应时间、上游处理时间、X-Forwarded-For真实IP。重点接口还要记录请求参数（脱敏后），否则出了问题只知道有人调了接口，不知道传了什么参数。
第二类是操作日志，记录用户在系统里的所有写操作。谁在什么时间修改了什么数据、从哪个IP操作的、修改前后值是什么。这类日志是定责的依据，必须落库存储，不能只写文件。
第三类是系统日志，包括登录日志、权限变更日志、定时任务执行日志、异常报错日志。登录日志要记录登录方式、是否成功、失败原因。很多撞库攻击就是从登录失败日志里发现的——同一IP短时间内大量登录失败，基本可以判定为撞库。
二、留存多久有讲究
日志留存时间不是越长越好，也不是越短越省事。根据《网络安全法》要求，网络日志至少留存六个月。但不同类型日志的留存策略可以分级处理。
访问日志量最大，建议热数据保留7天可快速检索，7天后转冷存储保留180天。操作日志和系统日志量相对小，直接入库保留一年以上。安全告警日志永久保留，这类日志量不大但价值极高。
存储成本可以通过采样和聚合来控制。比如访问日志7天后只保留异常请求（4xx和5xx），正常请求做聚合统计。既满足审计需求，又不会把存储费吃光。
三、怎么分析才有效
日志收上来不分析等于没收集。安全分析不需要多复杂的平台，但需要覆盖几个核心场景。
实时告警：配置规则检测异常行为。单IP一分钟内请求同一接口超过50次、非工作时间管理员账号登录、批量查询用户信息接口——这些都可以用ELK的告警功能或WAF规则实现。
定期巡检：每周跑一次脚本，统计top 10高频访问IP、异常时间段操作记录、权限变更记录。人工扫一眼，能发现不少隐患。
事件追溯：出事后能快速定位。要求日志可以按时间、用户、IP、操作类型多维检索。如果团队规模不大，用ELK加Kibana的仪表盘就够用了，不需要上SIEM平台。
日志体系不是一上来就完美的，先跑起来再迭代。先把三类日志的格式和存储定下来，逐步加分析规则和告警策略，半年下来安全可见性会有质的提升。