📚 课程目录第4章证据采集代理与探针设计

4. 证据采集代理与探针设计

安全审计证据自动化工程的核心难点，不在于“能不能采到数据”，而在于“能否在主机、网络和云环境中以低开销、可管控、可追溯的方式持续采到可信证据”。采集代理与探针正是承担这一职责的轻量级组件。它们不是简单的日志转发器，而是需要同时处理采集、过滤、缓冲、签名、上报和自愈等任务的边缘执行单元。本节从架构、部署和可靠性三个维度展开，重点说明实际工程中如何设计一个可落地的采集组件。

一、采集组件的三种形态与职责边界

在审计证据体系中，采集组件通常分为三类：主机代理、网络探针和云环境采集器。主机代理运行在服务器或终端操作系统内，负责采集进程启动、文件变更、用户登录、命令执行等系统级事件；网络探针以旁路或串接方式部署在网络节点，负责采集流量元数据、DNS 查询、TLS 握手信息和会话摘要；云环境采集器则通过云厂商提供的 API、事件总线和日志服务，采集控制面操作、对象存储访问和容器运行时事件。三者的共同职责是：在本地完成初步过滤与归一化，减少回传数据量，并为每条证据附加来源标识、时间戳和完整性校验值。

需要明确的是，采集组件不应承担“判断是否违规”的职责。它的核心任务是忠实记录、可靠传输、可验证来源。分析、关联和告警应交给后端平台，否则代理会变得臃肿，且规则更新会带来频繁的版本发布风险。

二、轻量级代理的参考架构

一个可落地的主机代理通常由五个模块组成：采集源适配层、过滤与归一化引擎、本地环形缓冲区、传输通道和健康与自愈模块。采集源适配层对接不同操作系统的接口，例如 Linux 上的 eBPF、auditd、inotify，Windows 上的 ETW、Sysmon 事件通道。过滤与归一化引擎负责将异构原始事件转换为统一 schema，并按规则丢弃低价值事件。本地环形缓冲区用于应对网络中断或后端不可用，通常采用固定大小、先进先出、落盘加密的方式。传输通道支持 gRPC、HTTPS 或消息队列协议，并支持批量压缩和断点续传。健康与自愈模块负责心跳上报、资源占用监控和异常重启。

三、部署方式的选择与权衡

主机代理的部署方式主要有三种：系统服务、容器 DaemonSet和Sidecar 注入。系统服务适合传统物理机和虚拟机，通过 systemd 或 Windows Service 管理生命周期，升级时需要滚动重启。DaemonSet 适合 Kubernetes 集群，每个节点运行一个代理 Pod，能够自动随节点扩缩容，但需要处理特权模式和主机路径挂载。Sidecar 模式将采集器与业务容器同 Pod 部署，隔离性好，但资源开销随 Pod 数量线性增长，通常只用于高价值业务。

网络探针的部署需要关注流量可见性和时间同步。旁路镜像方式不改变现有拓扑，但交换机镜像口可能丢包；TAP 方式更可靠，但需要硬件投入。无论哪种方式，探针都必须与后端保持 NTP 或 PTP 时间同步，否则跨主机证据关联会出现时间偏差。云环境采集器则优先使用云厂商的原生审计服务，通过只读凭证和增量拉取接口获取数据，避免在每台云主机上安装代理。对于无法通过 API 获取的运行时事件，再考虑轻量级 DaemonSet 补充。

四、可靠性设计的四个关键机制

采集组件运行在业务环境中，必须做到“不干扰业务、不丢失关键证据、不成为攻击跳板”。可靠性设计围绕以下四个机制展开：

资源限额与降级：代理应设置 CPU、内存和磁盘上限。例如 CPU 占用超过 2% 或内存超过 128MB 时，自动降低采集频率或关闭非关键采集源。缓冲区磁盘占用超过 512MB 时，按优先级丢弃低价值事件，优先保留登录、提权、配置变更等关键证据。
断点续传与本地缓冲：网络中断时，事件写入本地环形缓冲区，恢复后按时间顺序补传。缓冲区采用加密落盘，防止证据被篡改或泄露。每条记录携带单调递增序列号，后端据此检测丢失和重复。
完整性校验与来源绑定：代理在本地对每条证据计算 SHA-256 摘要，并使用设备证书对摘要签名。后端验证签名后入库，确保证据来源可信、内容未被篡改。设备证书应支持轮换，避免长期凭证泄露。
健康心跳与自愈：代理定期上报心跳，包含采集速率、缓冲水位、丢弃计数和版本号。后端发现心跳中断或指标异常时，触发告警并尝试远程重启。代理自身也应具备看门狗机制，在进程挂死时自动重启。

五、一个可参考的代理配置示例

以下是一个主机代理的配置片段示例，用于说明关键参数如何落地。该示例为教学假设，实际部署时需根据业务负载调整。

agent:
  name: audit-agent-01
  collect:
    - source: ebpf_process
      enabled: true
      priority: high
    - source: file_integrity
      enabled: true
      paths: ["/etc", "/usr/local/bin"]
      priority: medium
    - source: network_flow
      enabled: false
      priority: low
  filter:
    drop_events:
      - process_name: "logrotate"
      - process_name: "updatedb"
  buffer:
    type: ring_file
    max_disk_mb: 512
    encrypt: true
    overflow_policy: drop_low_priority
  transport:
    protocol: grpc
    endpoint: "audit-backend.example.com:443"
    batch_size: 500
    retry_interval_sec: 10
  limits:
    max_cpu_percent: 2
    max_memory_mb: 128
  heartbeat:
    interval_sec: 30
    include_metrics: true

该配置中，priority 决定缓冲区溢出时的丢弃顺序，overflow_policy 控制溢出行为，heartbeat 用于后端监控代理存活状态。实际运行时，可以通过代理暴露的本地指标接口查看采集速率和缓冲水位，例如 curl http://127.0.0.1:9100/metrics，观察 agent_events_total、agent_buffer_usage_bytes 和 agent_dropped_total 三个指标的变化。若 agent_dropped_total 持续增长，说明缓冲区容量不足或后端不可用，需要扩容或排查网络。

采集组件的设计原则可以概括为：采集要全、过滤要准、缓冲要稳、传输要断点续传、来源要可验证。代理越轻量，越容易在各类环境中长期稳定运行；职责越单一，越不容易因为规则变更而频繁升级。

不要将分析规则直接下发到代理执行。代理只做采集、过滤和签名，分析逻辑放在后端。否则一旦规则出错，可能导致关键证据被误丢弃，且难以追溯。

综上，主机、网络和云环境的采集组件虽然形态不同，但设计目标一致：以最小侵入性获取可信证据，并在网络抖动、后端故障和资源受限的条件下保持可靠。实际工程中，应优先选择与现有基础设施匹配的部署方式，明确资源限额和降级策略，并通过心跳、签名和缓冲机制保证证据链完整。只有这样，后续的审计分析和取证才有可靠的数据基础。