3. 证据自动化工程的需求分析与目标定义

在安全审计证据自动化工程中，需求分析不是简单地把“要什么证据”列成清单，而是要把三类上游输入——审计目标、合规要求、事件响应场景——翻译成可被采集器、解析器、关联引擎和证据库执行的工程需求。如果跳过这一步直接写采集脚本，常见后果是：证据字段缺失、时间戳口径不一致、采集频率与保留周期不匹配、关键证据无法证明控制措施有效。因此，本节的核心任务是建立一条从“审计问题”到“可执行证据需求”的推导链，并为每条需求定义可验证的目标。

三类输入如何转化为证据需求

审计目标回答“我们要证明什么”。例如审计目标为“验证特权账号操作均经过审批且可追溯”，它本身不是证据，而是一个待证明的命题。把它拆解后，需要三类证据：审批记录（谁在何时批准了哪次操作）、操作日志（特权账号在目标系统上执行了什么）、身份映射（操作账号与自然人、工单的对应关系）。这三类证据分别来自工单系统、主机审计日志、IAM 目录，说明需求分析必须同时确定证据来源系统。

合规要求回答“必须留下什么、留多久、以什么形式留”。以等保2.0三级中“安全审计”相关控制项为例，通常要求审计记录包含事件日期时间、用户、事件类型、事件结果等字段，并要求审计记录受到保护、定期备份。这类要求会直接转化为字段级约束和保留策略：日志必须包含 event_time、user_id、event_type、result，且证据存储需具备写保护与至少 180 天的保留能力。合规条款是硬约束，不能因采集成本高而删减字段。

事件响应场景回答“出事后需要多快拿到什么”。例如针对“主机失陷排查”场景，响应人员需要在 15 分钟内获取某主机近 7 天的进程创建、网络连接、账号登录和文件变更记录。这会把需求从“有日志”提升为“可检索、可关联、低延迟”：采集延迟需小于 1 分钟，索引需支持按主机名和时间范围快速过滤，且进程与网络事件需能通过进程 ID 关联。

需求条目的标准结构与示例

为了让需求可执行、可验收，每条证据需求应包含固定字段。下面给出一份可直接使用的需求条目模板，字段均来自本节推导链，不引入无关管理字段。

以 R2 为例，其验证方法可以具体化为一条检查命令：从证据库中随机抽取 100 条主机审计记录，检查 event_time、user、event_type、result 四个字段的非空率。若缺失率低于 0.1%，且时间戳与源主机时间偏差小于 5 秒，则判定该需求达成。这个阈值不是凭空设定，而是根据审计取证对时间线还原的要求反推得出：时间偏差过大将导致跨主机事件无法正确排序。

目标定义的三个维度

需求分析的最后一步是把每条需求转成可验收的目标。目标定义应覆盖三个维度：

• 可度量：字段、频率、延迟、保留期必须是具体数值，不能写“尽快”“长期”。例如“采集延迟 ≤ 10 秒”“保留 180 天”。
• 可验证：每条需求都要有对应的检查方法和通过阈值。验证方法可以是字段完整性检查、抽样比对、关联查询测试或时间偏差测量。
• 可追溯：每条需求必须能回溯到至少一个上游来源（审计目标、合规条款或响应场景）。无法追溯的需求应删除，避免采集器无限膨胀。

常见偏差与纠正

实际项目中，需求分析最容易出现三类偏差。第一类是“有日志就算有证据”，忽略了字段完整性。纠正方法是把必需字段写成检查项，并在采集器上线前做字段缺失率测试。第二类是“保留期一刀切”，所有证据都保留 30 天，导致合规审计时无法提供 180 天前的记录。纠正方法是按来源分别定义保留期，并在证据库中设置生命周期策略。第三类是“响应场景需求缺失”，只考虑合规字段，未考虑进程与网络的关联字段，导致失陷排查时无法还原攻击链。纠正方法是在需求评审时强制加入至少一个事件响应场景的走查。

完成本节的需求分析与目标定义后，应产出一份证据需求清单，每条需求都具备编号、来源、字段、频率、保留期、验证方法和通过阈值。这份清单是后续采集器设计、解析规则编写和证据库建模的直接输入，也是验收阶段判断自动化工程是否达标的依据。