先列矩阵再关联
关联分析最容易犯的错误是先有假设再去凑证据。稳妥的做法是先做一张矩阵：行是日志来源，列是可用字段（用户名、来源 IP、进程、文件路径、会话 ID、域名），把每个来源实际能提供哪些字段逐格标出来，再据此决定用哪几个键去串联不同来源。
共同键决定关联强度
同一台主机内部的日志常有进程号、用户名这类强键，可以直接串联；跨主机之间往往只有来源 IP 与时间可用，属于弱关联，结论表述要留余地。没有共同键的两类日志（例如某主机的进程创建与另一台设备的连接记录）只能靠时间与行为模式间接关联。
基本信息
| 适用平台 | 跨平台，与具体采集工具无关 |
|---|---|
| 矩阵行 | 日志来源：auth 日志、Web 访问日志、审计日志、流量日志、租户日志等 |
| 矩阵列 | 用户、来源 IP、进程、文件、会话 ID、域名 |
| 强键示例 | 同一主机的 PID 加时间、用户加会话 ID |
| 弱键示例 | 跨主机的来源 IP 加时间窗 |
典型使用场景
- 确定用哪个键串联身份与动作：先看矩阵哪一列两个来源都填了 Y
- 评估结论强度：只有弱键支撑的推断，报告里要用推测性表述
- 发现采集缺口：某列整行都是空白，说明该来源缺失关键字段
- 指导补充采集：按空白列去申请对应的日志或审计策略
- 写进报告方法章节：说明各结论分别由哪些来源、哪些键支撑
矩阵草稿与字段核对
矩阵草稿与字段核对
# 先按实际字段名标注，不要凭印象填
来源 | 用户 | 来源IP | 进程 | 文件 | 会话ID
auth.log | Y | Y | - | - | -
Web 访问日志 | - | Y | - | Y | -
进程创建审计 | Y | - | Y | Y | -
DNS 客户端事件 | - | - | Y | - | Y
防火墙连接日志 | - | Y | - | - | -
# 用实际字段名验证一列，避免矩阵与数据不符
head -1 auth.log | cut -c1-80关联键与适用场景
| 关联键 | 能串起来的来源 | 注意事项 |
|---|---|---|
| 用户名 | 认证日志、审计日志、应用日志 | 同名账号可能被多人使用 |
| 来源 IP | 认证、Web、防火墙、代理 | NAT 后一个 IP 对应多台主机 |
| 进程号 | 同一主机的进程与文件日志 | 跨主机没有意义，重启后复用 |
| 会话 ID | 应用日志与中间件日志 | 不同系统的 ID 命名与格式不同 |
| 时间窗 | 任意两类日志 | 精度受各来源时间粒度限制 |
矩阵画在分析笔记里就够用，但结论章节应当把「哪个结论由哪些来源、通过什么键得出」写出来，否则复核者无法判断关联强度。
字段名不要凭产品印象填写：同一类日志在不同版本里的字段名会变（例如来源 IP 可能叫 src_ip、client_ip 或 remote_addr），按实际样本核对后再入表。