3. SOAR平台部署模式与选型评估

SOAR（Security Orchestration, Automation and Response）平台承载的是安全编排、自动化响应与案件管理能力，它既要对接大量安全设备与工单系统，又要执行具有处置权限的自动化动作。因此，部署模式的选择不只是“装在哪里”的运维问题，而是直接决定数据边界、响应时延、扩展弹性、合规约束与总体成本的架构决策。本节围绕本地部署、云原生、混合部署与SaaS四种模式展开对比，并给出容量规划、高可用设计与选型评估矩阵的落地方法。

四种部署模式的本质差异

本地部署将SOAR全部组件安装在客户自有机房或专有云内，编排引擎、数据库、消息队列、执行器（Runner）与前端全部由客户运维。它的核心优势是数据不出域、可深度对接内网设备、满足强合规场景；代价是扩容周期长、需要自建高可用与备份体系、版本升级依赖客户窗口期。

云原生部署通常指部署在客户自有Kubernetes集群或专属云上，以容器化方式运行。它保留了数据自主可控的特点，同时借助K8s获得弹性伸缩、滚动升级与自愈能力。适合已有成熟容器平台、希望兼顾合规与弹性的中大型组织。

混合部署把控制面（编排、案件管理、UI）放在云端或管理区，把执行面（Runner/执行器）下沉到各网络区域或分支机构。控制面统一编排，执行器就近访问本地设备，既减少跨区流量，又避免把高权限凭据集中暴露在单一位置。这是多分支、多隔离域场景中最常见的形态。

SaaS模式由厂商托管全部组件，客户通过浏览器使用，通常以订阅制计费。上线最快、运维负担最低，但需要评估数据出境、凭据托管、API出网与厂商锁定风险。对于安全团队规模小、希望快速获得自动化能力的组织较为友好。

容量规划：从事件量倒推资源

容量规划不能凭感觉，应从日均告警量、自动化触发率、单剧本平均动作数与峰值系数四个输入推导。假设某组织日均原始告警 20 万条，经去重与聚合后进入SOAR的案件约 8000 件，其中 60% 触发自动化剧本，平均每个剧本执行 6 个动作（查询、封禁、通知等），则日均动作数约为 8000 × 60% × 6 = 28800 次。若业务高峰集中在 4 小时内，峰值系数取 3，则峰值动作速率约为 28800 ÷ 4 ÷ 3600 × 3 ≈ 6 次/秒。

据此可估算执行器数量：若单个执行器稳定处理 2 次/秒，则至少需要 3 个执行器并预留 1 个冗余，即 4 个。数据库侧按每案件约 50KB 元数据、保留 12 个月计算，年增量约 8000 × 365 × 50KB ≈ 146GB，加上索引与日志建议预留 300GB 以上。这些数字属于示例假设，实际应以压测结果为准。

高可用设计要点

高可用的核心是消除单点并明确降级策略。编排引擎与前端应至少双副本并置于不同可用区，通过负载均衡分发；消息队列采用集群模式，避免单节点故障导致剧本任务丢失；数据库使用主从或分布式方案，并配置定期备份与恢复演练。执行器本身应无状态化，任务失败可重试，且同一剧本的并发执行需加锁防止重复处置。对于关键剧本，还应设计“人工确认”降级路径：当自动化链路异常时，转为工单派发，保证响应不中断。

选型评估矩阵的落地用法

选型应避免“功能清单打勾”式比较，而应围绕自身约束设定权重。上图中给出的六维加权示例可作为起点：数据合规与内网对接权重最高，因为它们决定方案是否可行；弹性、运维成本与上线速度决定长期体验。打分时建议由安全运营、基础设施、合规三方分别评分后取加权平均，并对得分接近的方案做一次小范围试点验证，例如用真实告警跑通 3 个高频剧本，观察对接成功率与平均响应时延。

最终结论往往不是“哪个模式最好”，而是“在当前合规边界与团队能力下，哪个模式能以可接受的成本达成响应目标”。本地部署适合强合规且具备运维能力的组织；云原生适合已有容器平台、追求弹性的团队；混合部署是多隔离域场景的平衡解；SaaS则适合快速起步、数据敏感度可控的场景。