说明：本文翻译自This is a security data lake^[1]

规模、节流和分析的前景使安全数据湖成为关注的焦点。但在评估SIEM自带存储选项之外的存储选项时，需要注意一些潜在陷阱和问题。随着云数据空间的不断发展，还有令人兴奋的创新值得关注。

什么是数据湖

关于云数据湖，最重要的是它们基于一种称为“对象存储”的技术。AWS S3是最著名的对象存储服务，Azure将其称为Blob存储。这些服务就像天空中一个巨大的虚拟文件柜。每一条数据，无论是照片、文档还是视频，都被存储为“对象”。

像S3这样的对象存储服务可以存储数EB级的数据，只要拥有适当的权限，就可以上传和下载几乎无限量的信息。但是，你不能直接读取这些文件。至少在未使用其他服务的情况下。这就是Snowflake在谈论将存储与计算分离时所指的意思：他们使用一种服务（AWS S3）将数据存储在文件中，并使用另一种服务（AWS EC2）处理这些文件中的数据。

存储与计算的分离在包括AWS安全湖在内的所有数据湖解决方案中都是一致的。下图将S3作为存储部分，并将Amazon Athena和OpenSearch等独立服务用于查询。

云数据湖具有低维护、可靠和灵活的特点。另一个关键优势是，它们可以为多种用例提供服务，而不仅仅是日志搜索。例如，企业可能使用同一个数据湖来报告上个季度的销售数据（BI用例），以及预测未来的趋势（数据科学用例）。安全团队在评估数据平台选项时，应牢记这一方面。

什么不是数据湖

让我们尝试将我们新获得的数据湖专业知识应用于一些流行的日志管理解决方案，这些方案有时会被人误认为是数据湖。我们将看到，了解这些平台的内部架构将帮助我们预见它们的局限性。

例如，Elasticsearch是存储日志数据的热门解决方案。但是，在AWS中运行Elasticsearch是否给了我们一个数据湖？原因如下：Elasticsearch存储与计算紧密耦合。

下图显示了一个由三个节点组成的Elasticsearch集群，其中每个节点（物理或虚拟服务器）存储几个数据分片。如果我们想在这个集群中添加更多的存储，我们很快就需要添加更多的节点。

存储和计算的紧密耦合反映在AWS Elasticsearch部署指南中。尽管部署完全是虚拟化和云化的，但存储部分仍然连接到虚拟机实例。查看卷类型（通用型 SSD 卷）以及“终止时删除”是如何被选中的，因为预期您不希望您的虚拟磁盘在没有虚拟机的情况下被遗留下来。

花时间了解存储和计算之间的关系对于构建可扩展的安全架构至关重要。在评估解决方案时，一个聪明的问题是：“我们的数据将存储在存储卷中还是对象存储中？”

Splunk是另一个流行的日志管理解决方案，当在本地或云上部署时，通常使用磁盘存储。正如在“构建基于AWS的可扩展Splunk架构^[2]”中所描述的，在生产环境中部署Splunk需要您“根据您的需求优化EC2实例和存储大小”，并选择应将哪种EBS存储卷类型附加到您的虚拟机上。这些都是虚拟机和磁盘的相关术语。请注意，在下面的图中，S3用于备份快照，而不是用于主动搜索。

存储和计算之间的紧密耦合是为什么Splunk Cloud默认为90天，并且没有列出超过这个时间范围的费用。拥有一个需要恢复数据的归档层是另一个表明该架构将存储和计算相结合的迹象。

许多关于有效威胁检测和响应的挑战都是存储和计算紧密结合的架构的症状。高昂的前期摄取成本、保留限制和存储层管理都可以通过数据湖方法来解决。但仅靠数据湖本身，对于SOC来说并不是非常有用。

是什么使它成为安全数据湖

我自己的安全数据湖之旅涉及聘请安全工程师来构建数据平台的所有组件。我们使用Python创建了一个规则引擎，并从头开始使用SQL编写所有检测内容。完成该过程花费了超过一年的时间，并且我有幸能够获得那些具有编程、威胁模型和调查告警能力的稀有人才。

幸运的是，过去五年来，供应商环境发生了很大变化。如今，已经出现了繁荣的生态体系，供应商们随时准备将贵公司现有的云数据平台转变为安全数据湖。现成的解决方案可以提供集成、规则引擎、检测内容、调查界面和自动化选项。我看到数十家公司从概念到生产，没有雇佣任何开发人员，证明安全数据湖首次变得不再局限于最大型企业之外的企业。

规则引擎是安全团队将专业知识应用于数据湖的地方。如果没有规则引擎，数据湖只是一个被美化的备份存储库。尤其将Snowflake改造为安全数据湖的规则引擎近些年已经显著成熟。例如，在Anvilogic公司，我们的规则引擎分为两个层面：一个层面用于将日志转换为感兴趣的事件，另一个层面将感兴趣的事件组合为威胁场景。此外，还有版本控制、AI copilot以及其他功能可以使数据湖用于威胁检测和狩猎。

在评估安全数据湖选项时，确保您可以直接访问数据平台。安全数据湖应该支持您想要加载的任何类型的数据，从日志到资产清单、漏洞发现和身份详细信息。虽然您的初始安全用例可能是搜索导向的，但您的数据湖仍应支持报告、数据科学和机器学习，，而无需在不同位置移动数据。这样，您的安全团队就不会错过围绕LLMs和自助分析式的所有创新。如今被认为是尖端的案例很快就会成为基本要求，因此请相应地设计您的架构。

总之，现代安全数据湖具有以下特性：

• 存储基于对象存储（无论是直接在S3中还是像Snowflake那样透明地存储）
• 查询使用与存储分离的计算，可按需提供
• 支持灵活的分析和查询选项，包括企业级仪表盘和数据科学工具
• 将针对安全用例设计的规则引擎插入到数据湖中

凛冬将至：Apache Iceberg

一项重大的发展正在进行中，我预计这将进一步提高安全数据湖的价格/性能并推动其采用。最初由Netflix开发的Open Table Format正在被Google^[3]、AWS^[4]、Snowflake^[5]、Databricks^[6]和其他几乎所有人^[7]接受。Iceberg为您的数据湖提供了一个跟踪元数据的标准，以便文件不会只是闲置在那里——任何兼容的查询引擎都有一种地图来找到用户正在搜索的内容。本质上，Iceberg 在不需要将基于云的数据从其源头移出的情况下实现了性能和治理。

对于在云环境中处理TB级日志数据的SOC，这种方法可能很快就能在基础设施成本上实现更多节流，同时提高查询数据的灵活性。例如，S3 中的 Iceberg 格式数据可能由一个使用 Spark 的团队和另一个使用 Snowflake 的团队进行查询。数据湖创新的速度不同于我们在网络安全行业中所习惯的任何事物。处理大规模数据的安全组织不应再等待，应立即投身其中。

参考