Atlassian联手Databricks：OCSF安全湖仓如何降噪20年日志

Atlassian的安全团队曾长期被一个看似简单的问题困扰：如何在每天产生的海量日志中，精准捞出真正的威胁信号？二十年积累的日志数据、全球分布的云基础设施、不断膨胀的安全告警——这些因素叠加在一起，让传统SIEM（安全信息与事件管理）架构不堪重负。

他们给出的答案，是联合Databricks构建一个基于OCSF（Open Cybersecurity Schema Framework，开放网络安全模式框架）的安全湖仓。这套系统不仅降低了噪音，还重新定义了安全数据的处理方式。

为什么传统安全架构撑不住了

Atlassian的业务覆盖全球，云环境横跨多个区域和平台。安全团队需要从数百个数据源中采集日志，包括云服务审计日志、网络流量、终端检测与响应（EDR）告警以及自研应用的审计事件。

问题在于，这些数据源的格式各不相同。每个厂商都有自己的字段命名和日志结构，导致安全分析师需要花费大量时间做字段映射和归一化，而不是专注于威胁狩猎。

更棘手的是成本。传统SIEM通常按数据摄入量计费，而Atlassian的日志量以PB级计算。如果将所有原始日志都灌入SIEM，成本会迅速失控。如果只保留部分数据，又可能遗漏关键证据。

Atlassian的工程团队意识到，需要一种既能保留全量数据、又能低成本查询的架构。安全湖仓的概念由此进入视野。

SIEM（Security Information and Event Management）是一类集中采集、关联和分析安全日志的平台，长期被视为企业安全运营中心（SOC）的核心工具。传统SIEM在设计上偏向于结构化事件采集和实时规则匹配，其计费模式通常与数据摄入量或峰值吞吐挂钩。这种模式在日志量较低、数据源有限的时代较为经济，但当企业进入多云、容器化和微服务阶段，日志种类和数量呈指数级增长时，按量计费会迅速放大成本。与此同时，传统SIEM的存储层往往与计算层耦合，难以单独扩展，导致企业不得不在保留周期和查询能力之间妥协。这正是Atlassian所面临的困境：不是SIEM没有用，而是它的经济模型和架构假设已经不再适配PB级、多源异构的安全数据环境。

OCSF：让安全数据说同一种语言

OCSF由AWS、Splunk、CrowdStrike等厂商联合发起，目标是定义一套开放、可扩展的安全事件模式。它把安全事件抽象为几个核心类别：认证、网络活动、进程活动、文件活动、漏洞发现等。每个类别有标准化的字段定义。

这意味着，无论日志来自哪家云厂商或安全工具，都可以映射到同一套字段体系。对于Atlassian而言，OCSF解决了困扰多年的数据归一化问题。

具体做法是：在数据摄入管道中增加一层转换逻辑，将原始日志解析并映射为OCSF格式，然后写入Databricks的Delta Lake表。安全分析师用SQL或Spark查询时，面对的是一张统一的、带模式的表，而不是几十种不同格式的原始日志。

这一转变带来的效率提升是显著的。过去需要写自定义解析脚本的查询，现在可以直接用标准字段完成。

安全数据归一化之所以困难，根本原因在于安全遥测天然是异构的。云厂商的审计日志、EDR的进程事件、网络设备的流量记录、自研应用的业务日志，它们不仅字段命名不同，连事件的时间粒度、主体标识方式和语义边界都不一致。过去企业通常为每个数据源单独编写解析规则，这些规则分散在不同团队、不同脚本中，难以复用和维护。OCSF的价值在于它提供了一套厂商中立的语义模型：事件被归入有限的类别，字段有明确定义，扩展也有规范。这样一来，解析规则可以从“针对某个厂商的日志”转变为“映射到某个OCSF类别”，大幅降低了新增数据源时的工程成本，也让跨数据源的关联分析在模式层面成为可能。

Databricks湖仓如何支撑安全分析

选择Databricks，Atlassian看重的是三个能力：开放存储、弹性计算和统一分析。

Delta Lake作为开放表格式，把数据存储在云对象存储上，避免了厂商锁定。安全团队可以保留全量原始日志，同时通过时间旅行和ACID事务保证数据一致性。

计算层面，Databricks的弹性集群让Atlassian可以根据查询负载动态调整资源。日常的告警查询使用小集群，月末的合规审计或大规模威胁狩猎则临时扩展到更大规模。这种按需付费的模式，比固定容量的SIEM更灵活。

统一分析则体现在：安全团队和数据工程团队可以在同一平台上协作。安全分析师用SQL做威胁狩猎，数据工程师用Spark做ETL，机器学习团队用MLflow训练异常检测模型——所有工作都基于同一份数据。

据Atlassian披露，迁移到湖仓架构后，安全数据的查询性能提升了数倍，而存储成本大幅下降。具体数字虽未公开，但团队表示“不再需要在数据保留和成本之间做痛苦取舍”。

湖仓（Lakehouse）是一种将数据湖的开放存储与数据仓库的事务能力结合起来的架构。它通常以开放表格式（如Delta Lake、Apache Iceberg）为基础，在云对象存储之上提供ACID事务、模式演进和时间旅行等能力。对安全场景而言，这意味着企业可以在低成本对象存储中保留全量原始日志，同时用SQL或Spark进行高性能查询，而不必在“全量保留”和“快速查询”之间二选一。存储与计算分离还带来了弹性：日常查询使用小规模集群，大规模威胁狩猎或合规审计时临时扩展计算资源，成本与实际使用量挂钩。这种模式与SIEM的固定容量授权形成鲜明对比，尤其适合日志量波动大、查询模式多样的安全运营场景。

降噪的关键：从告警洪流到信号过滤

安全团队真正的痛点不是数据量，而是信噪比。Atlassian每天收到的安全告警中，大量是误报或低优先级事件。分析师时间被消耗在重复的排查工作中。

OCSF湖仓为降噪提供了基础。由于所有事件都在同一张表中，团队可以编写更复杂的关联规则。例如：将云审计日志中的异常登录与EDR中的进程行为关联，只有当两者同时触发时才生成高优先级告警。

此外，历史数据的可用性让基线分析成为可能。团队可以计算某个用户或服务的正常行为模式，然后对偏离基线的活动自动标记。这种基于历史上下文的检测，比单纯的阈值告警准确得多。

Atlassian还利用Databricks的机器学习能力，对告警进行聚类和优先级排序。相似告警被合并，低风险事件被自动降级，分析师只看最值得关注的那部分。

安全告警降噪的常见技术包括关联规则、基线建模和告警聚类。关联规则通过将多个数据源中的事件按时间、主体或会话关联起来，过滤掉单一来源的误报；例如，仅凭一次异常登录可能只是用户出差，但如果同一主体随后出现异常进程行为，威胁置信度就会显著上升。基线分析则依赖历史数据建立正常行为轮廓，再用统计或机器学习方法检测偏离。告警聚类通常使用相似度算法将大量重复或近似告警合并为一个事件，并按风险评分排序。这些方法都需要一个前提：历史数据可查、多源数据可关联。传统SIEM由于存储成本限制，往往只保留短期热数据，导致基线分析和跨源关联难以长期运行，而湖仓架构恰好补上了这一短板。

对安全数据架构的启示

Atlassian的实践反映了安全数据分析的一个趋势：从专用SIEM向开放湖仓迁移。

OCSF作为开放模式，正在获得越来越多厂商的支持。它让安全数据摆脱了特定平台的束缚，可以在不同工具之间流动。对于像Atlassian这样拥有多云环境的企业，这种互操作性尤为重要。

湖仓架构则解决了安全数据的成本与保留矛盾。通过将存储和计算分离，企业可以用低成本对象存储保留全量数据，只在需要时启动计算资源。

当然，这一架构并非没有挑战。OCSF映射需要前期投入，数据管道的维护也需要专业工程能力。对于安全团队规模较小的企业，直接采用托管SIEM可能仍是更务实的选择。

但对于日志量巨大、多云环境复杂、且有数据工程能力的企业，Atlassian的路径提供了一个值得参考的范本：用开放模式统一数据，用湖仓降低成本和打破孤岛，最终让安全分析师回归分析本身，而不是困在数据清洗里。