Microsoft Sentinel 与 Splunk：选择 SIEM

两种工具都做同样的核心工作：收集日志、关联事件，并浮现出重要的告警。差异体现在定价模式、查询语言，以及你需要承担多少基础设施责任上。

每个产品的实际情况

Microsoft Sentinel 是构建在 Azure Log Analytics 上的云原生 SIEM。没有基础设施需要打补丁，没有索引器集群需要调整大小，所有操作都使用 Kusto Query Language (KQL)，从狩猎到检测规则都是如此。按摄入工作区的 GB 数计费，有几个层级（按使用量付费、从 100 GB/天左右开始的承诺层级），改变单位 GB 费率。

Splunk 起初是一个本地日志平台，在很多地方仍然这样运行，不过 Splunk Cloud 现在是新部署的默认推荐。它使用 SPL（搜索处理语言），这是一种较老、更成熟的语言，在 Splunkbase 上有一个更大的社区应用库。从历史上看，Splunk 也按摄入量计费，但他们已经将客户推向基于工作负载的定价模式，按计算资源（搜索作业、索引）而不是原始数据量计费——值得检查当前条款，因为这已经改变了不止一次。

查询语言：KQL vs SPL

KQL 读起来像是过滤器的管道，类似于 LINQ（如果你接触过 C#）：

SecurityEvent
| where EventID == 4625
| summarize FailedLogons = count() by Account, bin(TimeGenerated, 1h)
| where FailedLogons > 10

SPL 用不同的语法做同样的事：

index=wineventlog EventCode=4625
| bucket _time span=1h
| stats count as FailedLogons by Account, _time
| where FailedLogons > 10

用过 SQL 的分析师往往能更快地上手 KQL。SPL 对于 transaction、eventstats 和机器学习工具包集成等内置命令有更多支持，如果你在做超出简单阈值的异常检测，这很重要。两种语言都没有客观的好坏之分——真正的代价是重新培训已经在其中一种上花了多年肌肉记忆的团队。

数据摄入和连接器

如果你的资产已经主要是 Microsoft，Sentinel 有优势：对 Azure AD（Entra ID）登录日志、Defender for Endpoint、Office 365 和 Azure 活动日志有原生、低摩擦的连接器。通过 Azure Monitor Agent 管道输入 AWS 或本地 Syslog 数据工作得很好，但与原生 Azure 源相比，这是额外的一跳。

Splunk 的连接器生态在原始数量上更广，因为它存在的时间更长——Splunkbase 有数千个应用和附加组件，包括社区维护的小众产品应用。如果你从混合环境（Cisco 防火墙、遗留本地 AD、各种没有现代 API 的随意 SaaS 应用）摄入数据，你可能会在找到等效的 Sentinel 连接器之前先找到 Splunk 的预制技术附加组件 (TA)。

检测规则和威胁情报

Sentinel 附带映射到 MITRE ATT&CK 的分析规则模板，Microsoft 自己的威胁情报源（Microsoft Threat Intelligence）直接集成。Fusion 是 Sentinel 的关联引擎，自动将低保真告警链接到单个事件中，这对于没有专门检测工程团队的小型团队减少告警疲劳很有帮助。

Splunk Enterprise Security（一个单独的付费附加组件，不包含在基础 Splunk 中）为你提供 Notable Events、基于风险的告警和一个更可定制的关联搜索框架。基于风险的告警特别是——随时间对实体评分而不是在单个事件上触发——是任何一个平台中可用的更强大的检测模式之一，Splunk 已经有它更长时间了。

成本和运营开销

Sentinel 的无服务器模式意味着不需要为索引器或搜索头进行容量规划，但如果你在记录冗长的源（如 DNS 或防火墙流量）而没有先过滤，摄入成本可能会迅速上升。数据收集规则 (DCR) 让你在数据进入工作区前进行过滤和转换，这值得早期设置，而不是在你的第一张惊人的账单之后。

Splunk 本地给你对保留和硬件大小调整的完全控制，但意味着有人拥有索引器集群、许可证使用和升级周期。Splunk Cloud 消除了大部分，但在较新的定价模式下你仍然为计算密集型搜索付费，所以写得很糟的 SPL 查询在你的钱包上更直接地击中你，而不是在旧的基于摄入的方案中。

什么适合你的环境

如果你已经深入 Azure 和 Microsoft 365，Sentinel 通常成本更低来建立和维护。如果你需要广泛的第三方集成、成熟的应用生态，或你的团队已经了解 SPL，Splunk 的灵活性值得付出，尽管运营难度更高。许多大型企业实际上运行两个——Splunk 用于遗留本地源，Sentinel 用于 Azure 原生一侧——并在它们之间转发汇总数据，而不是专门选择一个。

有关构建检测规则和日志管道的更多信息，请查看 Korra Studio 上相关的 SIEM 和蓝队部分。