开工先盘点日志源
分析开始前先把「有哪些日志、在哪里、留多久、谁能取」列清楚：主机系统日志、应用日志、网络设备日志、安全设备日志、云平台与 SaaS 审计日志各一份。这份清单决定后面能做什么结论：保留期短于事件跨度的来源，只能明确写成证据缺口，不能用推测替代。盘点的产出是日志源清单，与范围清单一起构成分析的边界。
基本信息
| 用途 | 确认证据可获得性，明确证据缺口 |
|---|---|
| 输出 | 日志源清单：位置、保留期、访问方式、负责人、时区 |
| 覆盖范围 | 主机、应用、网络设备、安全设备、云平台与 SaaS 审计 |
| 关键字段 | 保留期与轮转策略，决定能回溯到多久以前 |
| 访问方式 | 本地读取、集中平台查询、导出申请，逐一确认时效 |
| 时区标注 | 每个来源的时区单独记录，后续统一换算 |
典型使用场景
- 确认某时间窗内的日志是否还在，避免查到一半才发现被轮转
- 识别证据缺口：关键来源保留期过短，报告需如实说明
- 明确各类日志的获取时效与审批路径，安排调查节奏
- 为跨源分析准备时区表，减少后续换算错误
- 与业务方确认日志是否开启过审计，避免把「没记录」当成「没发生」
- 为整改建议提供依据：哪些日志需要延长保留或新开采集
清单骨架
清单骨架
# 先看本机日志来源与保留情况
ls -la /var/log/ | head -20
ls -la /var/log/journal 2>/dev/null | head -5
grep -E 'rotate|compress|maxage' /etc/logrotate.conf /etc/logrotate.d/* 2>/dev/null | head -20
# 记录格式示例（写入报告附录）
# 来源 | 位置 | 保留期 | 访问方式 | 时区
# web-1 认证日志 | /var/log/auth.log* | 约 90 天 | SSH 本地读取 | UTC+8
# 防火墙会话 | 集中平台 | 180 天 | 平台查询导出 | UTC盘点项与缺口处理
| 盘点项 | 要确认的内容 | 缺口处理方式 |
|---|---|---|
| 位置 | 文件路径或平台入口 | 位置不明时先找负责人确认，不臆测 |
| 保留期 | 轮转周期与最久可回溯范围 | 窗口超出保留期，报告写明缺口 |
| 访问方式 | 本地、平台查询或导出申请 | 需审批的提前启动流程，避免中途卡住 |
| 时区 | 该来源时间戳的定义时区 | 统一换算到 UTC 并保留原始值 |
| 审计开关 | 相关审计是否曾经开启 | 未开启要说明「无记录」而非「无行为」 |
保留期小于事件时间跨度时，要在报告里明确写出「证据缺口」与影响范围，而不要用推测填补。缺口本身也是结论的一部分。
云端与自建日志的时区经常不一致，逐项标注是最省事的做法：清单上多写一列，后续省去反复确认。