先回答范围三问
溯源最容易失控的地方是「什么都查一点、什么都没结论」。控制的方法是在动手深挖前先回答三个问题：涉及哪些资产、覆盖哪个时间段、牵涉哪些账号。范围最初可以按告警指认的结果来定，属于粗筛；随后每得到一条新证据就回填到这三个维度里，范围随之修正。范围定了，取证与报告才能按同一口径组织，读者也能清楚知道结论的效力边界。
基本信息
| 用途 | 给深挖设定边界，避免无边界搜索 |
|---|---|
| 输出 | 资产清单 + 时间窗 + 账号清单三份表 |
| 初始依据 | 告警指向的资产与时间，先按可以确认的部分圈定 |
| 修正原则 | 先粗后细，随证据调整并记录每次调整的依据 |
| 时间窗要求 | 写明起止时刻并标注时区，跨时区资产分别列出 |
| 记录要求 | 范围清单与修正记录一并归档，作为报告的范围章节 |
典型使用场景
- 接到告警后先圈定首轮排查范围，避免一上来就全量翻日志
- 多资产环境里按业务系统分组，明确每组的责任人与数据源
- 排查中发现新主机，按修正流程纳入范围并补采证据
- 为报告写明适用范围：结论只对范围内的资产与时间段成立
- 控制调查成本：范围明确的调查比无边界调查快得多
- 与处置方案对齐：范围决定需要隔离和加固的资产清单
范围三问骨架
范围三问骨架
资产：涉及哪些主机、服务、IP 段、云资源
例：web-1、web-2（10.0.3.0/24），负载均衡入口
时间：起止时间（含时区），以及为什么选这个窗口
例：2026-01-02T00:00Z ~ 2026-01-03T00:00Z（首次告警前 6 小时起）
账号：涉及的账号与凭据面（人类账号、服务账号、密钥）
例：ops、deploy、www-data
# 每条新线索都回填到这三个维度，超出范围的就先记录待确认范围声明要素
| 要素 | 说明 | 修正时的动作 |
|---|---|---|
| 资产边界 | 主机、服务、网段与云资源 | 新增资产需补采证据并说明来源 |
| 时间窗 | 起止时刻与理由（含时区） | 窗口扩大要重跑已完成的筛选 |
| 账号面 | 人类账号、服务账号、密钥与令牌 | 新增账号时回查其全部认证记录 |
| 排除项 | 明确说明哪些资产经核查不在范围内 | 排除依据要可复核，不能只写「无异常」 |
| 修正记录 | 每次调整的时间、依据与影响 | 作为报告附录，支撑范围的可信度 |
范围先粗后细：初始按告警指认的资产与时间圈定，随着证据累积逐步收敛。范围修正要有依据记录，否则报告里前后不一致，读者难以自洽。
时间窗的选择要有依据：常见做法是从首次异常时间向前留出足够余量（例如 24-48 小时），因为最早异常点往往不是最早被入侵点。