2. 安全审计证据的类型与来源

安全审计证据自动化工程的第一步，不是写采集脚本，而是把“证据”这件事本身拆清楚。审计结论能否站得住脚，取决于证据是否具备可追溯性、完整性和可验证性。不同形态的证据，其采集方式、时效要求、存储成本和自动化边界差异极大。如果一开始就把所有数据都当成“日志”来采，往往会在后期遇到字段缺失、时间错位、权限越界或证据链断裂的问题。

一、七类核心证据形态及其技术特征

从自动化采集的视角，可以把常见审计证据分为七类，每类都有明确的宿主对象和采集接口：

• 日志证据：包括操作系统事件日志（Windows Event Log、Linux syslog/journald）、应用日志、安全设备日志（防火墙、WAF、IDS）。典型字段为时间戳、主机、用户、事件ID、结果。采集方式以日志转发（syslog、Windows Event Forwarding）或代理读取为主，属于流式、持续型证据。
• 配置证据：操作系统安全基线、中间件配置、数据库参数、网络设备ACL。它是状态快照型证据，采集频率低但要求字段结构化，通常通过SSH、WinRM、API或配置管理数据库（CMDB）拉取。
• 流量证据：NetFlow/IPFIX、PCAP、DNS查询记录、TLS元数据。特点是体量大、时效强，全量PCAP通常只保留数小时到数天，自动化采集必须明确采样率和留存窗口。
• 进程证据：进程列表、命令行参数、父进程关系、加载模块、网络连接。属于瞬时状态型证据，必须在目标主机上以高频率轮询或由EDR代理持续上报，否则极易丢失。
• 文件证据：文件哈希、权限位、时间戳（MACB）、内容片段。采集时需注意哈希算法一致性（建议SHA-256）和采集顺序，避免读取行为本身改变访问时间。
• 注册表证据：自启动项、服务配置、安全策略键值、USB使用记录。Windows环境下通过远程注册表或离线挂载采集，属于结构化键值型证据。
• 云审计记录：AWS CloudTrail、Azure Activity Log、阿里云ActionTrail、Kubernetes审计日志。特点是API驱动、多账号、多区域，采集依赖云厂商提供的投递通道（如S3、Event Hub、日志服务）。

二、证据形态与采集边界的对应关系

“自动化采集边界”指的是：哪些证据可以稳定自动获取，哪些只能半自动，哪些必须人工介入。边界由三个因素决定——接口可达性、数据易失性、合规约束。例如，进程命令行在Linux上可通过/proc/<pid>/cmdline读取，但普通用户无法读取其他用户的完整参数，需要root或CAP_SYS_PTRACE；云审计记录虽然API可达，但部分区域默认不开启，且投递存在分钟级延迟。

三、自动化采集边界的判定方法

判断某类证据能否纳入自动化流水线，建议按以下顺序检查：

1. 接口是否存在且稳定：是否有官方API、代理或标准协议。例如Windows事件日志有WEF和WinRM，Linux有journald的journalctl -o json输出，云审计有各厂商的投递通道。若只能靠人工截图或手工导出，则边界应标记为“半自动”。
2. 权限是否可长期持有：采集账号是否具备最小必要权限，且不会因密码轮换、MFA策略或会话超时而中断。实践中建议为采集单独建立服务账号，并纳入特权账号管理。
3. 数据是否会在采集前消失：进程、网络连接、内存中的命令行属于易失数据，必须在采集频率上覆盖其生命周期。例如短命进程可能只存活数百毫秒，轮询间隔若为60秒则必然漏采，此时应改用EDR的进程创建事件而非轮询。
4. 合规与隐私约束：流量中的载荷、文件内容、注册表中的用户痕迹可能涉及个人信息或业务敏感数据。自动化采集前需明确脱敏规则和留存期限，否则即使技术可行，也不应纳入默认采集范围。

四、采集参数示例与结果判读

以Linux主机进程证据采集为例，一个可落地的采集命令如下，用于获取进程PID、命令行、父进程和启动时间：

for pid in $(ls /proc | grep -E '^[0-9]+$'); do
  if [ -r /proc/$pid/cmdline ]; then
    cmd=$(tr '\0' ' ' < /proc/$pid/cmdline)
    ppid=$(awk '/^PPid:/{print $2}' /proc/$pid/status 2>/dev/null)
    start=$(stat -c %Y /proc/$pid 2>/dev/null)
    echo "pid=$pid ppid=$ppid start=$start cmd=$cmd"
  fi
done

该脚本以root或具备CAP_SYS_PTRACE的账号运行，输出为每行一条进程记录。判读时重点关注：cmd中是否出现编码后的命令、ppid是否指向异常父进程、start是否与已知维护窗口冲突。若某进程在两次采集之间消失，且未出现在EDR事件中，则应标记为“采集盲区”，而不是直接判定为无此进程。

五、多源证据的关联与优先级

单一来源的证据往往只能回答“发生了什么”，多源关联才能回答“是否可信”。例如，云审计记录显示某API在凌晨被调用，若同时段该主机的进程证据中出现对应CLI工具、流量证据中出现到云API端点的TLS连接，则证据链显著增强。反之，若只有云审计记录而主机侧无任何对应痕迹，则需要考虑凭证泄露或采集覆盖不足。

在自动化工程中，建议为每类证据定义三个元字段：采集时间戳（UTC）、证据来源标识、完整性哈希。这三个字段是后续关联分析和证据链构建的最小公共集。缺少其中任何一个，跨源关联都会变得脆弱。