3. SOAR平台架构与核心组件

SOAR（Security Orchestration, Automation and Response）平台并不是一个“能跑剧本的脚本工具”，而是一套由多个核心组件协同工作的工程系统。理解它的架构，关键不是记住组件名称，而是看清每个组件承担什么职责、彼此之间传递什么数据、以及当一次告警进入平台后，数据如何在组件之间流动并最终形成可审计的处置闭环。本节围绕七个核心组件展开：编排引擎、剧本库、集成框架、案例管理、资产库、情报库与审计日志。

一、整体架构：控制面与数据面分离

工程化设计的第一条原则是控制面与数据面分离。控制面负责“决定做什么”，包括编排引擎、剧本库、案例管理；数据面负责“实际去做什么”，包括集成框架调用的各类安全设备与外部服务。资产库、情报库、审计日志则作为共享支撑层，被控制面和数据面共同读写。这样划分的好处是：剧本逻辑变更不会直接影响设备连接，设备接口升级也不会破坏剧本结构。

二、编排引擎：任务调度的核心

编排引擎是SOAR的“CPU”。它接收案例管理模块传入的告警上下文，根据剧本定义生成任务图，并按依赖关系依次或并发执行。工程化设计中，编排引擎必须解决四个问题：变量传递、分支判断、失败重试与超时熔断。

以一次“可疑登录”告警为例，剧本可能包含以下任务节点：查询资产库确认主机归属、调用EDR接口隔离主机、调用防火墙接口封禁源IP、发送通知。这些节点之间存在依赖：隔离主机必须在确认资产归属之后执行，封禁IP可以与隔离主机并发。编排引擎需要维护一个任务状态机，每个节点有“待执行、执行中、成功、失败、跳过、超时”六种状态。当某个节点失败时，引擎根据剧本中定义的on_failure策略决定是重试、跳过还是终止整个剧本。

{
  "task_id": "isolate_host_01",
  "action": "edr.isolate_host",
  "params": {
    "host_id": "{{case.asset.host_id}}",
    "reason": "suspicious_login"
  },
  "timeout_sec": 30,
  "retry": { "max": 2, "interval_sec": 5 },
  "on_failure": "continue_with_alert"
}

这段配置说明：隔离主机任务最多重试2次，每次间隔5秒，超时30秒；若最终失败，剧本不终止，而是继续执行并产生一条告警记录。这种设计避免了单点失败导致整个响应流程中断。

三、剧本库：可版本化的响应逻辑

剧本库不是简单的文件存储，而是需要支持版本管理、参数化、审批门禁和回滚。每个剧本应有唯一标识、版本号、适用告警类型、输入参数定义、输出结果定义以及变更记录。工程实践中，剧本应尽量参数化，避免硬编码IP、域名或账号。例如，封禁IP的剧本不应写死某个防火墙地址，而应通过资产库查询“该网段对应的防火墙设备”，再调用集成框架执行。

剧本的发布应经过审批。建议采用“草稿—测试—生产”三态管理：草稿状态允许自由编辑；测试状态只能在仿真环境或只读模式下运行；生产状态才允许对真实设备执行写操作。每次发布生成新版本号，旧版本保留，支持一键回滚。

四、集成框架：连接一切安全能力

集成框架负责与外部系统通信，是SOAR平台与真实世界之间的桥梁。它需要处理认证、协议适配、速率限制、幂等控制和错误映射。以调用EDR接口隔离主机为例，集成框架需要完成：从凭证管理模块获取API Key、构造HTTP请求、处理429限流响应、将设备返回的错误码映射为平台统一错误类型、记录请求与响应日志。

幂等控制尤为重要。如果编排引擎因超时重试而重复调用“封禁IP”接口，集成框架应通过幂等键（如case_id + action + target）判断该操作是否已执行，避免重复封禁或重复通知。对于不支持幂等的设备接口，集成框架应在本地维护操作记录，并在重试前先查询设备当前状态。

五、案例管理、资产库、情报库与审计日志

案例管理是SOAR的“工作台”。它负责将来自SIEM、EDR、邮件网关的原始告警聚合为案例，去重、合并、分派给分析师，并跟踪SLA。一个案例应包含：告警来源、受影响资产、已执行剧本、任务时间线、当前状态、处置结论。案例管理还需要支持人工介入：当剧本执行到需要审批的节点时，案例状态变为“等待审批”，分析师可以在界面上批准或拒绝。

资产库提供“这个IP是谁的、这台主机属于哪个业务、责任人是谁”的查询能力。情报库提供IP、域名、文件哈希的信誉与上下文。两者在剧本执行中被频繁查询：例如，判断一个源IP是否恶意，需要先查情报库；决定是否隔离一台主机，需要先查资产库确认其业务重要性。审计日志则记录所有操作：谁在什么时候执行了什么剧本、调用了什么接口、返回了什么结果。审计日志不仅是合规要求，也是排障和复盘的基础。

六、组件协同的完整数据流

将上述组件串联起来，一次典型的SOAR响应流程如下：SIEM产生告警 → 案例管理创建案例并去重 → 编排引擎根据告警类型匹配剧本 → 剧本查询资产库和情报库获取上下文 → 编排引擎生成任务图 → 集成框架调用EDR、防火墙等设备执行动作 → 执行结果回写案例 → 审计日志记录全过程 → 案例结案或转人工。

这条数据流中，每个组件都有明确的输入和输出。编排引擎的输入是案例上下文和剧本定义，输出是任务执行结果；集成框架的输入是任务参数和凭证，输出是设备响应；案例管理的输入是告警和执行结果，输出是案例状态和处置记录。理解这些输入输出关系，才能在平台出现异常时快速定位是哪个组件出了问题。

七、工程化设计检查要点

最后需要强调：SOAR平台的工程化设计不是一次性完成的，而是随着剧本数量、接入设备数量、日均告警量的增长持续演进。初期可以只实现编排引擎和集成框架的最小闭环，随着运营深入再逐步完善案例管理、资产库和情报库的联动。关键是保持组件边界清晰、数据流可追踪、操作可审计，这样平台才能在真实的安全运营中稳定发挥作用。