留存期为什么是硬指标
审计日志的价值取决于能不能查到过去：等保要求留存不少于 6 个月，意味着今天的事件要能在半年后仍被还原。留存不达标通常不是因为没记录，而是因为轮转策略太小或磁盘写满导致提前覆盖。核查要做两件事：看策略写了多久，再看磁盘上实际还有多久——两者都达标才算符合。
基本信息
| 加固项 | 审计日志留存期 |
|---|---|
| 适用平台 | Linux 与 Windows 通用 |
| 风险等级 | 高 |
| 基线 | 审计日志留存不少于 6 个月 |
| 核查对象 | 审计服务自身配置、系统日志轮转、平台事件日志、集中留存平台 |
典型使用场景
- 等保测评：留存期是安全审计条款里的明确数值要求，必须能给出证明
- 容量规划：估算当前日志量能撑多久，提前扩容而不是等写满
- 事件回溯：发生时间较早的事件能否查询，直接取决于留存配置
- 集中审计建设：确认本地与集中两处的覆盖范围与保留时长
- 运维排障：日志被覆盖导致无法复盘，是排障阶段最常遇到的痛点
Linux 侧核心配置
Linux 侧核心配置
grep -E 'num_logs|max_log_file|max_log_file_action' /etc/audit/auditd.conf
grep -E 'MaxRetentionSec|SystemMaxUse|Storage' /etc/systemd/journald.conf
grep -rE 'rotate|maxage' /etc/logrotate.conf /etc/logrotate.d/ | head -20
ls -lt /var/log/audit/ | head # 看实际文件时间跨度
journalctl --disk-usage # 日志当前占用Windows 侧对照
Windows 侧对照
wevtutil gl Security | findstr /i "maxSize retention" # 日志大小与保留策略
Get-WinEvent -ListLog Security | Select-Object LogName, MaximumSizeInBytes, FileSize, LogMode
Get-WinEvent -ListLog * | Where-Object RecordCount -gt 0 | Select-Object -First 10 LogName, RecordCount四处配置与口径
| 位置 | 关注参数 | 说明 |
|---|---|---|
| auditd.conf | num_logs、max_log_file | 审计日志的轮转份数与单文件上限，直接决定时长 |
| journald.conf | Storage、SystemMaxUse、MaxRetentionSec | 决定系统日志落在磁盘还是内存，以及上限 |
| logrotate | rotate、maxage | 常规系统日志的轮转份数与最长保留天数 |
| Windows 事件日志 | 最大大小与覆盖方式 | 默认覆盖最旧记录，需按容量换算留存天数 |
| 集中留存平台 | 保留周期与防删策略 | 本地之外的副本，是证据链的关键一环 |
留存期等于策略与实测双达标：光看配置不算，必须结合磁盘上的实际文件时间跨度确认。报告里建议写上估算过程，例如「轮转份数乘单文件上限除以日均写入量」，这比一句「已配置 6 个月」更能支撑结论。
时间不同步会让留存结论失效：日志都存在但时间戳错乱，事件回溯就无法对齐。核查留存时顺带确认 NTP 或时间同步服务状态，这是审计有效性的前提条件。
容量估算怎么做
先量日均写入：取最近一周的日志总量除以天数，得到日增量；再用可用的日志总量上限除以日增量，得出理论留存天数。这个数字与 6 个月对比就得到结论。若不足，优先顺序是扩大日志分区或提高上限，其次才是集中留存，因为本地日志缺失会直接影响现场取证。