📚 课程目录第2章审计接口基础

审计接口基础：RESTful API vs SOAP、常见审计协议与数据格式

聊到审计接口集成，甭管你是对接 SIEM、SOC，还是做 DSPM 的数据采集，第一道槛就是搞明白“数据怎么传过来”。我个人习惯先把接口分成两大类：API 调用和日志主动推送。你想想看，一个要你主动去拉，另一个是系统自己送上门，处理逻辑完全不同。

我最早接触审计系统时，还是个纯小白。当时客户说“我们提供 Syslog 审计”，我心想，Syslog 是啥？能吃吗？后来踩过几次坑，才算摸清了门道。今天咱们就把这些基础概念彻底理清楚。

废话不多说，先看这张知识框架图，后面咱们逐个拆解。

一、RESTful API vs SOAP：两种接口哲学

先说说接口。说白了就是服务跟服务之间的“对话协议”。审计系统要拉数据，就得靠这个。

1. RESTful API

RESTful API 是目前的主流。轻量、灵活、基于 HTTP。你在 DSPM 里要拉个审计日志清单，一个 GET 请求就够了：

GET /api/v1/audit-logs?start=2025-01-01&end=2025-01-31
Authorization: Bearer <>
Accept: application/json

返回 JSON，结构清晰，解析也快。我做过的大多数现代审计接口，首选都是 RESTful。为什么？因为它无状态、可缓存、与 Web 生态天然融合。

维度	RESTful API	SOAP
传输协议	HTTP/HTTPS	HTTP、SMTP、JMS 等
数据格式	JSON（首选）、XML	XML（强制）
接口契约	WADL、Swagger/OpenAPI	WSDL
状态管理	无状态（Stateless）	可有状态（WS-* 扩展）
性能开销	低	高（XML 解析 + 协议开销）
适用场景	云审计、移动端、微服务	银行、金融核心、遗留系统

2. SOAP

SOAP 是“老干部”协议。非常严谨，有强类型，有 WSDL 契约。我遇到过一些银行核心系统，审计接口只暴露 SOAP。为什么？因为 SOAP 有一套 WS-Security 标准，可以做消息级别的签名和加密，这一点 RESTful 要靠 HTTPS 外加 JWT 来补齐。

一个 SOAP 审计请求长这样：

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
   <soap:Header>
      <wsse:Security>
         <wsse:UsernameToken>
            <wsse:Username>audit_user</wsse:Username>
            <wsse:Password>audit_pass</wsse:Password>
         </wsse:UsernameToken>
      </wsse:Security>
   </soap:Header>
   <soap:Body>
      <GetAuditLogs>
         <startDate>2025-01-01</startDate>
         <endDate>2025-01-31</endDate>
      </GetAuditLogs>
   </soap:Body>
</soap:Envelope>

我的建议：新项目一律选 RESTful。如果客户强制要求 SOAP，先问他有没有 WSDL 和 XSD。如果不给，那就是画大饼，后期集成要当心了。

二、常见审计协议：谁在用，怎么用

审计数据，不一定都靠 API 去拉。更多时候，是系统主动把日志推出来。这就涉及到审计协议了。

1. Syslog

Syslog 是最经典的日志传输协议。RCF 5424 定义了结构化 Syslog，RCF 3164 定义了老版。你想想看，一台交换机、防火墙、Linux 服务器，基本都支持 Syslog。我最早在数据中心做审计时，每天几十 GB 的日志全走 Syslog。

它简单到什么程度？一个监听端口（通常是 UDP 514），一行字符串，搞定：

<34>1 2025-01-15T10:30:00Z my-firewall-01 kernel - - [example@9999 src="192.168.1.100" dst="10.0.0.50"] Connection blocked

Syslog 主要有三种传输协议：

UDP Syslog：速度快，但不保证送达。局域网内没问题，公网别用。
TCP Syslog：可靠传输，但会引入延迟。适合重要审计日志。
RELP (Reliable Event Logging Protocol)：我最推荐的。有确认机制，保证不丢日志。建议给所有重要审计源上 RELP。

2. SNMP

SNMP 是网络设备的“体检协议”。审计领域主要用 Trap 和 Inform。设备“生病”（CPU 过载、接口 down、配置变更）时，主动发 SNMP Trap 给审计平台。

我这里给一个 Trap 的结构示例：

SNMPv2c Trap
  System.sysUpTime.0 = 123456789
  SNMPv2-MIB::snmpTrapOID.0 = IF-MIB::linkDown
  IF-MIB::ifIndex.1 = 1
  IF-MIB::ifAdminStatus.1 = up
  IF-MIB::ifOperStatus.1 = down

避坑提示：SNMP Trap 默认是 UDP，不可靠。如果你收到“偶尔丢事件”的投诉，先查网络是否有丢包，再考虑上 SNMPv3 的 Inform（带确认）。

3. JDBC

有些审计数据存在关系型数据库里。你没法通过文件或者网络协议去拿，只能用 JDBC 直连查表。我接触过的传统企业审计平台，很多保留方案就是 JDBC：

-- 提取审计日志
SELECT event_id, event_type, user_name, event_time, detail
  FROM audit_log
 WHERE event_time BETWEEN '2025-01-01' AND '2025-01-31'
   AND event_type IN ('LOGIN', 'LOGOUT', 'PERMISSION_CHANGE');
ORDER BY event_time;

这方法最笨，但最管用。问题是，直接连生产库？不行。我建议走只读副本，或者用 CTE（Change Tracking 或数据库审计日志）来做增量抽取。

重要提醒：JDBC 方式要格外小心大数据量。全量扫描一张几亿行的审计表会让数据库 IO 瞬间飙满。我见过某运维直接用 select * 连生产库跑，结果半小时后 DBA 打电话骂娘。切记加时间范围、加索引、走读库。

三、数据格式：JSON、XML、CEF

数据传过来了，用什么格式装？这直接决定你解析的难易程度。

1. JSON

JSON 是我在 DSPM 项目中的首选。轻便、易读、与 Web 生态无缝衔接。一个审计事件用 JSON 表示大概是这样：

{
  "event": {
    "id": "evt-20250115-001",
    "type": "USER_LOGIN",
    "timestamp": "2025-01-15T10:30:00.000Z",
    "source": {
      "ip": "192.168.1.100",
      "user": "zhangsan",
      "device": "workstation-42"
    },
    "action": "AUTHENTICATE",
    "result": "SUCCESS"
  }
}

为什么好？因为压测、解析、转换都很快。我习惯让所有新集成的审计接口优先输出 JSON。

2. XML

XML 在“老系统”里很常见。支持 Schema 校验，有命名空间，适合复杂结构。还是那句话，如果你在集成 SOAP 接口，数据格式只能是 XML。但无论是 Syslog 还是 RESTful，遇到 XML 我建议先问客户：能不能切到 JSON？切不了，再用 XPath/SAX 解析。

我曾经在一个项目中花了两周调 XML 解析性能，最后发现是审计系统把几十个嵌套 namespace 都压到一个事件里。后来客户换了 JSON，一秒解决。

3. CEF

CEF，Common Event Format，是 ArcSight 推出来的标准。本质上是竖线（|）分隔的文本格式。很多 SIEM 原生就吃 CEF。看看结构：

CEF:0|Security|Firewall|1.0|100|Connection Blocked|5|src=192.168.1.100 dst=10.0.0.50 dpt=443 msg=Blocked by policy

CEF 的最大优势是标准化。只要你的厂商支持 CEF，字段映射就很轻松。我建议在对接 ArcSight、QRadar 这类 SIEM 时，优先让上游日志转成 CEF。比你手工写解析器靠谱得多。

CEF 字段	映射内容	示例
CEF:0	版本号	0 表示标准版
Device Vendor	设备厂商	Security
Device Product	产品名	Firewall
Device Version	版本号	1.0
Signature ID	事件标识	100
Name	事件名称	Connection Blocked
Severity	严重级别	5（1-10）
Extension	扩展字段	key=value 列表

我的经验：CEF 虽然老，但兼容性极好。如果你要对接的审计平台列表里包含了 ArcSight、LogRhythm、RSA NetWitness，我建议直接上 CEF。省去后面大量的字段映射工作。

好了，三种格式没有的好坏。JSON 适合现代基础架构，XML 适合遗留系统，CEF 适合 SIEM 生态。你心里要有本账：对接的审计平台偏好什么格式，就优先给它什么格式。

嗯，这一块知识覆盖面挺广，但都是基础中的基础。搞懂了这些，后面讲具体集成方案时，你就知道接口怎么选、协议怎么搭、格式怎么转。