"我们有日志"和"我们能查出来"是两件事。日志的价值不在存储量，而在于：需要的时候，能不能在合理时间内还原出"谁在什么时候做了什么"。
一、先定留存范围
| 类型 | 内容 | 建议留存 |
|---|---|---|
| 登录日志 | 成功与失败、来源地址 | ≥ 6 个月 |
| 操作日志 | 权限变更、配置修改、数据导出 | ≥ 6 个月 |
| 系统日志 | 服务启停、错误、崩溃 | ≥ 3 个月 |
| 网络日志 | 防火墙、设备登录与策略变更 | ≥ 6 个月 |
| 应用日志 | 业务关键操作 | 按业务与合规要求 |
具体期限要看行业与合规要求。无论多少，写进制度并有人负责，比期限本身更重要。
二、时间必须统一
时间不同步是日志分析最大的障碍。一条服务器日志和一条防火墙日志相差两分钟，排查时就要来回猜。
- 所有设备与系统指向同一时间源
- 定期核对偏差，超过 30 秒即告警
- 日志以统一时区存储，展示层再做转换
三、集中收集，别只看单机
- 把关键系统日志集中到日志服务器，避免单机被入侵后日志一并被删
- 日志服务器权限独立，只允许写入和查询，不允许修改
- 重要日志做完整性保护，防止篡改
只读，是日志服务器最重要的属性
如果运维账号能在日志服务器上删记录，那这些日志在审计场景下的证明力就很有限。
四、定期演练"查得到"
建议每季度做一次检索演练：随机设定一个场景（例如"上周三 14 点到 16 点，谁登录过财务系统"），看能否在半小时内给出答案。
- 记录检索耗时
- 记录需要跨几个系统
- 记录发现的问题（字段缺失、时间错乱、日志未采集）
五、把结果写进改进项
演练暴露的问题要进入整改清单：补采集、补字段、改保留期。日志体系是练出来的，不是买出来的。
#日志审计#留存策略#时间同步#运维事业部
