日志留存要能拿出来
日志留存不是设备上开个开关就完成的事，它覆盖从产生、传输、在线存储到归档恢复的完整链路。合规要求通常以不低于六个月的留存期为基准，但真正容易出问题的地方在于「能不能验证」：在线存储的容量够不够，归档后能不能恢复，随机指定一个历史日期还能不能检索到当天记录。
基本信息
| 对象 | 安全设备日志、系统日志、管理员操作审计日志 |
|---|---|
| 周期 | 按法规与内部制度确定，在线存储与归档共同覆盖留存期 |
| 保障条件 | 容量规划、归档介质、恢复流程与定期验证 |
| 验证方式 | 随机抽取历史日期做检索测试，而不是只看配置 |
典型使用场景
- 合规审计：等保与行业检查要求提供一定期限内的日志记录
- 事件回溯：安全事件发生数周后才被发现，需要调取当时的日志
- 责任界定：出现误操作或权限滥用时，用日志还原操作过程
- 容量规划：根据日均日志量与留存期反推存储需求
- 归档演练：定期验证一次恢复流程，避免归档介质实际不可读
留存能力检查
留存能力检查
1. 在线存储可覆盖多长时间，按当前日均日志量测算而不是估算
2. 归档介质与恢复流程是否可用，是否有人会操作
3. 随机抽查历史某一天的日志能否检索到（这是最直接的验证）
4. 设备侧留存策略与平台侧策略是否一致，避免设备本地先被覆盖
5. 留存策略文档与执行情况一致，差异项要有整改记录常见缺口
| 环节 | 缺口表现 | 后果 |
|---|---|---|
| 传输 | 日志发送中断无人发现 | 出现无日志的时间空洞 |
| 在线存储 | 容量按均值估算 | 业务高峰日志被提前覆盖 |
| 归档 | 有归档无恢复验证 | 需要时取不出历史日志 |
| 策略一致性 | 设备本地与平台周期不同 | 审计口径混乱 |
留存能力的判断标准是「能不能取出来」：定期随机抽一个历史日期做检索测试，比任何配置截图都有说服力。