一、背景：为什么我们需要自建威胁检测平台
随着公司业务规模快速扩张，线上资产从最初的几台服务器增长到上千个节点，传统的安全防护手段逐渐力不从心。WAF、IDS 等边界设备每天产生海量告警，但真正有价值的威胁信号被淹没在噪声之中。安全团队每天花费大量时间人工研判，响应效率极低，多次出现从入侵发生到发现间隔超过 48 小时的情况。
管理层提出了明确要求：建立一套自动化的威胁检测体系，将平均检测时间（MTTD）从小时级压缩到分钟级。经过三个月的调研与方案设计，我们正式启动了威胁检测平台的建设。
二、平台架构设计
威胁检测平台的整体架构分为四个核心层：数据采集层、规则引擎层、告警管理层和响应编排层。每一层都承担独立职责，层与层之间通过消息队列解耦，确保系统在高并发场景下依然稳定可靠。
2.1 数据采集层
数据采集是整个检测链路的起点。我们需要对接的数据源包括：网络设备日志（防火墙、交换机）、主机日志（Linux syslog、Windows EventLog）、应用日志（Nginx access log、业务系统审计日志）以及安全设备告警（WAF、IDS/IPS）。
采集端采用 Filebeat + Logstash 的组合方案。Filebeat 部署在各业务节点上，轻量级采集日志并发送到 Kafka 集群；Logstash 负责对接无法安装 Agent 的设备，通过 Syslog 和 SNMP Trap 接收数据。所有原始日志统一写入 Kafka 的 raw-logs topic，作为下游消费的唯一数据源。
2.2 规则引擎层
规则引擎是平台的"大脑"，负责从海量日志中识别出真正的威胁行为。我们选择了 Apache Flink 作为流式计算引擎，原因有三：一是 Flink 原生支持事件时间语义，能准确处理乱序和延迟数据；二是其状态管理机制成熟，可以维护复杂的会话窗口和模式匹配；三是 Flink SQL 降低了规则编写门槛，安全分析师无需掌握 Java 即可编写检测规则。
规则体系分为三个层级：基础规则基于单条日志的字段匹配，例如检测 SSH 暴力破解（同一源 IP 在 5 分钟内登录失败超过 20 次）；关联规则跨多个数据源进行关联分析，例如将 WAF 拦截记录与主机登录日志关联，识别绕过 Web 攻击后的横向移动；行为规则基于用户和实体的行为基线，检测偏离正常模式的异常活动。
2.3 告警管理层
规则引擎输出的原始告警量依然庞大，直接推送给分析师会造成"告警疲劳"。告警管理层的核心能力是聚合、去重和优先级排序。
我们使用 Elasticsearch 作为告警存储和检索引擎。每条告警写入 ES 后会经过以下处理流程：首先按攻击源 IP、目标资产、攻击类型三个维度进行聚合，将同一攻击行为产生的多条告警合并为一个安全事件；然后基于资产重要性和攻击成功概率计算优先级评分；最后将高优先级事件推送到值班分析师的告警队列，低优先级事件进入待审池定期批量复核。
2.4 响应编排层
检测到威胁只是第一步，快速响应才能降低损失。响应编排层提供了一套可视化的 playbook 编辑器，安全运营人员可以通过拖拽方式定义响应流程。例如，针对"确认主机被入侵"场景，playbook 自动执行以下步骤：调用 CMDB 接口获取受影响资产信息 → 通知资产负责人 → 在防火墙上封禁攻击源 IP → 对受影响主机执行隔离 → 创建工单跟踪后续处置。
所有响应动作都通过标准化的 API 适配器与现有 IT 系统对接，目前已集成 CMDB、防火墙、工单系统和企业微信通知。整个响应流程从人工判断到自动化执行，平均处置时间从 4 小时缩短到 15 分钟。
三、关键技术选型
技术选型是平台建设中最关键的决策之一。以下是我们的核心选型思路和最终方案：
3.1 消息队列：Apache Kafka
日志采集的峰值吞吐量可达每秒 50 万条，需要一个高吞吐、持久化能力强的消息中间件。Kafka 的分区机制天然支持水平扩展，配合 MirrorMaker 可以实现跨机房的数据同步。我们将 Kafka 集群部署为 6 broker、3 副本的配置，单 topic 设置 64 个分区，实测可稳定承载峰值流量。
3.2 流式计算：Apache Flink
在评估了 Flink、Spark Streaming 和 Kafka Streams 之后，我们选择了 Flink。核心考量是 Flink 的 CEP（Complex Event Processing）库非常适合安全场景下的模式匹配，例如检测"端口扫描 → 漏洞利用 → 权限提升"这类多步骤攻击链。此外 Flink 的 Checkpoint 机制保证了故障恢复时数据不丢失，这对安全审计的完整性至关重要。
3.3 存储与检索：Elasticsearch
安全数据的检索需求有两个特点：一是查询模式多样，既有精确匹配也有模糊搜索和聚合统计；二是数据量大但热数据集中在近 7 天。Elasticsearch 的倒排索引和聚合能力完美匹配这些需求。我们采用热-温-冷三层索引策略：近 7 天的热数据存放在 SSD 节点上保证查询性能，7-30 天的温数据迁移到 HDD 节点，30 天以上的冷数据压缩归档到对象存储。
四、落地经验与踩坑总结
4.1 日志标准化是最大的坑
项目初期我们低估了日志标准化的难度。不同设备、不同应用输出的日志格式千差万别，有的用 JSON，有的用空格分隔，有的字段名完全不统一。我们花了将近两个月时间才建立起统一的日志 schema，定义了包括 event_type、src_ip、dst_ip、action、severity 等 30 多个标准字段。建议后来者在项目启动时就投入足够资源做日志治理，否则下游的规则引擎会因为数据质量问题频繁误报。
4.2 规则调优是持久战
规则上线初期误报率高达 40%，安全团队怨声载道。我们的应对策略是：新规则先以"观察模式"运行两周，只记录不告警，期间统计误报和漏报数据；根据统计结果调整阈值和条件，误报率降到 5% 以下才切换为"告警模式"。这个过程虽然慢，但能有效建立团队对平台的信任。
4.3 不要忽视运维成本
Kafka + Flink + Elasticsearch 的技术栈对运维能力要求很高。上线半年内我们经历了两次 Kafka 集群因磁盘写满导致的数据丢失事故，以及一次 Flink 作业因状态过大导致 Checkpoint 超时的性能问题。建议团队至少配备一名专职的大数据运维工程师，并建立完善的监控告警体系，对集群的磁盘使用率、作业延迟、Checkpoint 耗时等关键指标进行实时监控。
五、总结与展望
经过一年的建设和持续优化，威胁检测平台已经覆盖公司 90% 以上的核心资产，日均处理日志量超过 2 亿条，平均检测时间从最初的 48 小时降低到 8 分钟，成功拦截了多起高级持续性威胁攻击。
下一步我们计划引入机器学习能力，利用无监督学习算法检测未知威胁；同时探索 SOAR（Security Orchestration, Automation and Response）的深度融合，进一步提升自动化响应能力。安全建设永远在路上，希望本文的实践经验能为正在或即将搭建威胁检测平台的同行提供一些参考。