安全数据的语义层战争：Google SecOps 搜索规范背后的算力经济学

一份教你省钱的文档，暴露了整个行业的结构变化

Google Security Operations（前身为 Chronicle）发布了一份关于 UDM 搜索最佳实践的文档。它读起来像典型的厂商技术文档：讲字段、讲操作符、讲性能调优、讲故障排查。

但把它放回上下文，这份文档其实在说一件更大的事：在现代安全运营平台上，搜索不再是一个免费动作。

文档开篇就给出警告——如果查询构造不当，搜索会消耗大量计算资源，性能还会随实例中数据的规模与复杂度而变化。随后它几乎用一种成本顾问的语调，逐条列出“高性能字段”“被排除的字段”“如何收窄时间范围”。

这不是语法教学。这是算力经济学。当一份安全产品的官方文档需要花大量篇幅教用户如何少花钱、少算、少扫数据，说明安全运营的核心矛盾已经从“能不能看见攻击”转移到了“看得起吗”。

字段白名单：Schema 就是基础设施权力

文档最有信息量的部分，是它为每一类查询场景给出了一份明确的“高性能 UDM 字段”清单。元数据、主体（principal）、源、目标、网络、安全结果——六大类字段被逐一列出，并明确说明这些字段“针对快速检索做了优化”。

这反映了一个成熟但常被忽视的事实：统一数据模型不只是数据规范，它是查询能力的边界定义。

在原始日志世界里，任何字段理论上都能搜，代价是扫全表。在 UDM 世界里，一部分字段被接入索引与检索路径，另一部分则活在原文里，只在必要时被解析。这个分层不是技术细节，而是产品设计者对未来安全调查方式的一次下注——他们认为调查员真正频繁使用的，是主机名、IP、文件哈希、进程 ID、用户标识、电子邮件地址、HTTP 方法、安全规则名。

这套名单本身就是一份“安全调查行为学”的侧写：现代威胁狩猎的原子单位，是可关联的实体标识，而不是自由文本。

对竞争者而言，这份名单更是一道墙。谁定义了字段，谁就定义了检测规则的写法、分析师的心智模型，以及从这家平台迁移出去的成本。模式（schema）从来不是中立的，它是基础设施权力的具体形态。

被刻意排除的字段：算力经济学露出的边角

文档里有一段罕见的坦率：某些字段被故意排除在搜索过滤器之外，包括 metadata.id、metadata.product_log_id 以及所有 *.timestamp 字段。理由说得很直接——这些字段的唯一值带来高基数（high cardinality），会引入统计方差，损害搜索性能。

这句话值得反复读。

在可观测性与安全数据领域，高基数一直是成本结构里最难缠的对手。一个包含数百万甚至数十亿唯一值的字段，几乎不可能被高效索引。厂商面对它的选择只有两个：要么硬扛，把成本转嫁给用户；要么把它挡在快速检索层之外，让用户在需要时付出更高代价。

Google 选了后者，而且写进了公开文档。这意味着它承认了一件事：在安全数据平台里，不是所有数据都生而平等。

更微妙的是时间戳被归入这一类。时间本应是安全调查的第一维度，但恰恰因为时间的取值近乎无限，它无法作为高性价比的精确匹配条件。文档给出的替代方案是用 Unix epoch 秒数做比较，或者调用 YARA-L 的时间函数做日期换算——换句话说，把“人类可读的时间”翻译成“机器可索引的整数”，由用户承担这个翻译成本。

这是一个典型的工程妥协，也是一个典型的商业模式选择。

两种时钟：事件时间与摄取时间的分裂

文档里另一个容易被忽略但意义深远的细节，是关于“新摄取但时间戳较旧的数据”的说明：搜索的时间范围基于解析后的事件时间戳，而不是原始日志的摄取时间戳。

它甚至给出了对策——如果要在旧事件时间戳中搜索新摄入的日志，必须使用 All time 选项，并改为查询 metadata.ingested_timestamp。

这背后是流处理领域一个老问题在安全场景下的重演：事件时间（event time）与处理时间（processing time）的分离。分布式系统里，日志迟到、时钟漂移、代理缓存、离线设备补传，都会让数据到达时间与事件发生时间脱钩。

而在安全调查里，这个技术细节直接决定结论对错。一次入侵的时间线重建，如果分析师默认搜索窗口是按摄取时间划分的，就可能完全漏掉攻击者在数周前埋下的、直到今天才被上传的日志。

更深一层的问题是：安全平台把“时间”这个概念拆成两个字段，实际上是把时间语义的解释权部分交还给了用户。这既是灵活性，也是责任转移。当平台不再替你决定“哪个时间才重要”，分析师就需要自己回答一个本应属于数据工程的问题。

实体与事件的分裂：上下文数据被单独对待

文档明确指出：如果用 metadata.log_type = "..." 去搜 AZURE_AD_CONTEXT、WORKSPACE_USERS 这类实体或上下文的日志类型，会返回空结果——因为 UDM 搜索只查询 UDM 事件记录。要访问这些数据，必须改用 graph 语法，通过 graph.metadata.event_metadata.log_type 或 graph.entity.user.email_addresses 这样的路径。

这个细节揭示的是安全数据架构的一次分叉：事件（events）和实体（entities）正在被分离存储与查询。

事件是“发生了什么”，实体是“谁是谁”。过去十年，SIEM 主要在处理前者。但现代安全运营越来越依赖后者——身份图谱、资产上下文、用户画像。攻击者很少只用一次事件暴露自己；他们的痕迹分散在大量事件里，只有通过实体把事件串起来，异常才会浮现。

用完全不同的语法去查询实体数据，是一个架构层面的信号：实体数据不是事件的附属，而是另一套需要独立建模、独立优化的数据结构。这也解释了为什么图查询（graph）正在成为安全平台的标配能力，而不仅仅是威胁情报的专属工具。

对创业生态而言，这里存在一个清晰的机会窗口：实体解析、身份归一化、跨源实体对齐，正在成为独立于 SIEM 之外的一层基础设施。

重复字段与 any 的沉默陷阱

文档中有一段关于“重复字段”的说明，语气平淡，但后果不小。principal.ip、target.file.md5 这类字段可以在单个事件中保存多个值。默认情况下，它们用 any 操作符求值：只要字段中任意一个值满足条件，整个谓词就为真。

文档给出的例子很有代表性：搜索 principal.ip != "1.2.3.4"，如果某个事件同时包含 1.2.3.4 和 5.6.7.8，这个事件依然会被匹配到。因为 5.6.7.8 满足了“不等于”的条件。

对人类分析师来说，这几乎是反直觉的。对构建自动检测规则的工程师来说，这是一个能直接导致误报和漏报的陷阱。

它揭示了一个更普遍的问题：安全查询语言的语义，正在成为一门需要专门学习的学科。当逻辑操作符的行为依赖于数据模型内部的存储结构，检测工程就不再只是“写出正确的逻辑”，而是“理解底层数据结构如何求值”。

这也解释了为什么文档特意提到，括号内逻辑操作符有上限（169 个），为什么枚举字段不能用正则，为什么 RE2 引擎的行为需要被单独说明。安全查询语言的复杂度正在逼近一门小型编程语言——而每一种新语言，都会催生一门新的专业分工。

AI 调查代理的前置条件，被写在了这份文档里

如果把这份文档当作对未来的一次铺垫来读，它最有意思的地方在于：它在无意中定义了一个 AI 安全代理要能工作，必须先满足哪些条件。

条件一：查询成本必须可预测。一个自主运行的调查代理，如果每次探索性查询都可能触发不可控的算力消耗，就没有人敢让它自由行动。字段白名单、时间窗约束、被排除的高基数字段，本质上都是把成本模型变得可预算。

条件二：语义必须确定。any 操作符的默认行为、重复字段的逐元素求值、事件时间与摄取时间的区分，这些都是代理必须精确掌握、不能含糊的规则。机器不能靠直觉绕过语义陷阱。

条件三：接口必须结构化。文档建议用参考列表（reference lists）替代大规模值匹配，用 Unix epoch 替代人类时间字符串，用明确的字段路径替代自由文本搜索——这些都是在把“调查”从一个模糊的人类活动，改造成一组可被程序调用的确定步骤。

换句话说，agentic SOC 这样的概念并不是先有代理，再去适配平台。真实顺序恰好相反：平台先把数据模型、查询语义和成本边界整理成机器可用的形式，代理才有落脚之处。这份文档属于这场准备工作的一部分，尽管它自己并不这么说。

模式标准化：一场安静但关键的竞争

把视角拉远，这份文档所处的战场，是安全数据模式（schema）的标准化竞争。

一边是厂商自有模式，比如 Google 的 UDM。它的优势是深度优化、与自家检索和检测引擎紧密结合；代价是迁移成本与生态封闭性。另一边是行业联合推动的开放模式方向，目标是让不同来源的日志拥有一致的字段语义，降低跨平台协作门槛。

这场竞争不会以发布会或营销战的方式呈现在公众面前。它体现在更枯燥的地方：字段命名、可搜索字段清单、时间戳的表示方式、实体与事件是否分离、正则引擎的选择。

但这些细节决定了下一代的现实：检测规则能否跨平台复用，威胁情报能否在组织间交换，AI 代理能否理解来自不同厂商的数据，以及安全团队在被锁定之前还剩多少谈判空间。

结语：安全运营正在从存储生意变成语义层生意

过去二十年，SIEM 的核心叙事是“把日志集中起来”。存储是成本，检索是功能。

现在这个关系反过来了。存储相对廉价，而让数据变得可查询、可关联、可被机器理解，才是真正昂贵且真正有价值的部分。

这份 Google SecOps 文档的价值，不在于它教了什么语法，而在于它诚实地暴露了新游戏规则：字段是有等级的，时间是有歧义的，查询是有价格的，语义是有边界的。

谁能定义这些边界，谁就不只是在卖一个安全平台，而是在定义安全调查本身的语法。这比任何一次产品发布都更值得关注。

---

信息源头：Search best practices | Google Security Operations