Databricks 与 Google 安全团队面临新的 AI 防御权衡

Databricks 发布了一份新的安全指南，围绕一个核心矛盾展开：AI 可以加速防御，但前提是团队信任其底层的数据和自动化能力。对于正在评估 databricks google 部署的组织而言，这一主张不止关乎分析。Databricks 希望让 lakehouse 成为安全数据、调查、检测工程和 AI 辅助响应的运营层。

该指南发布之际，安全团队正在重新审视传统上集中管理日志和告警的安全信息与事件管理系统，即 SIEM。Databricks 认为，碎片化遥测、高昂的保留成本和彼此脱节的工作流，使防御人员难以有效利用 AI。其提出的解决方案是将受治理的企业数据置于中心，让分析师和 AI 智能体在这一共享上下文中开展工作。

这一立场使 Databricks 面对的竞争者不止是成熟的 SIEM 厂商。它挑战了安全数据必须留在专业安全平台内的观念。Google Security Operations、Microsoft Sentinel、Splunk、CrowdStrike 等厂商也在加入 AI 驱动的调查与响应能力。这场竞争正逐渐演变为：选择一体化安全套件，还是选择为防御场景改造的更广泛数据平台。

Databricks 实际提出了什么

这项发布是一份面向安全运营的战略蓝图，而非经过独立验证的产品基准。

Databricks 于 2026 年 9 月 2 日发布了其安全领导力电子书。该指南将统一数据架构视为现代网络防御的基础。其核心观点是，只要日志、身份、告警和业务上下文仍彼此分离，组织就无法部署可靠的安全智能体。

该公司描述了三项相互关联的变化。安全团队应整合更多遥测数据，让专业工程团队以外的人员也能使用分析能力，并在受治理的工作流中引入 AI 智能体。这种方法让 lakehouse 不再只是长期存储空间，而成为检测、调查、富化和部分响应活动的场所。

这份安全领导力指南列举了多项客户和行业数据。Databricks 表示，72% 的受访安全高管面临数据孤岛问题。它还提到 Arctic Wolf 每周处理八万亿条安全事件。

该指南称，Rivian 在现代化其安全数据架构后，将与 SIEM 相关的成本降低了 60%。另一项案例则称，团队部署检测规则的速度提高了五到六倍。这些数据说明了公司的观点，但仍需谨慎解读。

Databricks 并未将每个数字都呈现为在同等安全环境之间进行的受控比较。工作负载构成、保留策略、人员配置、数据量和既有合同都可能显著影响结果。一次成功的客户实施并不能证明存在普遍适用的节省比例。

更有价值的信号在于这些案例背后的模式。安全团队希望延长保留时间、覆盖更广泛的遥测数据，并更快获得带有上下文的数据。传统 SIEM 的经济性可能迫使他们在摄取前过滤信息，或将较旧的日志移至单独的存储。

这种分割会造成运营摩擦。调查可疑访问的分析师可能需要终端告警、身份历史、云审计记录、资产归属和应用活动。如果这些记录分散在多个系统中，自动化调查也会继承同样的缺口。

lakehouse 改变了存储与分析之间的边界。它可以在保留结构化记录的同时容纳标准化程度较低的信息，并支持 SQL、Python、机器学习和受治理的数据共享。Databricks 将这种架构称为统一的数据、分析和 AI 平台。

该公司还推广 Agent Bricks，即其用于构建特定领域 AI 智能体的环境。在安全运营中，智能体可以汇总相关告警、检索历史活动，或协助起草检测逻辑。但智能体仍依赖于权限、可靠的上下文以及明确的审批路径。

这一区别至关重要。该指南并未证明 AI 智能体能够安全地取代安全分析师。它展示的是 Databricks 希望组织如何为更高程度的自动化做好数据和治理准备。

这是一个更狭窄的主张，但也更具影响力。如果企业接受这一前提，安全架构决策将更接近数据平台团队。SIEM 采购将部分成为关于存储格式、目录、模型访问和可复用企业上下文的问题。

为什么 Databricks 与 Google 的部署现在很重要

databricks google 的意义在于，AI 防御如今横跨数据平台、云控制、身份系统和外部模型提供商。

自两家公司于 2021 年宣布合作以来，Databricks 一直在 Google Cloud 上运行。最初的云合作强调集成分析、机器学习、统一计费、Google 身份支持和更便捷的数据访问。

此后的安全影响不断扩大。Databricks 工作区可以使用 Google Cloud 的存储、网络、身份、加密和审计服务。安全团队也可以在 Databricks 内分析遥测数据，而不将该平台本身视为唯一的防护来源。

当前的 Google Cloud 指南将安全描述为 Databricks、客户和云提供商之间的共同责任。当组织将更多安全数据迁入 lakehouse 时，这一边界至关重要。

Google Cloud 保护其底层基础设施，并为身份、网络、存储和加密提供控制措施。Databricks 保护其托管平台，并提供工作区级能力。客户仍需负责权限、数据分类、工作负载隔离、应用行为以及许多配置选择。

统一安全数据集并不会消除这些边界，而是让它们更加清晰可见。调查可以关联跨系统的操作，但管理员仍必须了解每项控制属于哪一方负责。

例如，Google Cloud 上的 Databricks 支持身份联合、单点登录、私有连接、客户管理密钥和云审计日志。这些控制在配置正确时可以减少暴露风险；但如果团队以为另一方已覆盖相关要求，也可能形成盲区。

因此，databricks google 这一表述可能对应多种不同的采购决策。某个组织可能使用 Databricks 进行分析，同时保留 Google Security Operations 作为其主要 SIEM。另一个组织可能将历史遥测数据卸载至 Databricks。第三个组织则可能直接基于 lakehouse 数据构建检测能力。

这些设计带来的风险各不相同。辅助分析存储并不需要具备主安全控制台中的全部工作流。处理实时分诊、自动遏制和监管证据的系统，则需要更严格的运营保障。

Google 也在推进自身的安全与智能体控制技术栈。其 2026 年的智能体身份框架涵盖身份、访问管理、网关、护栏和自主软件的运行时防御。这与 Databricks 从数据层应对的治理问题存在重叠。

这种重叠既带来合作，也带来竞争。Databricks 受益于 Google Cloud 基础设施，并可服务已投资于 Google 身份和存储的客户。然而，Google 同时销售安全运营平台，争夺遥测数据、分析师注意力和自动化工作负载。

这种张力在云软件中并不罕见。平台常常在基础设施层集成，却在应用栈更高层展开竞争。采购方应评估哪个系统将成为检测、案件、响应审批和证据保留的权威来源。

架构也会影响可移植性。Databricks 强调开放数据格式和多云运行；Google Cloud 强调集成服务和云原生控制。企业可能同时重视两者，但这些目标并不总会导向同一种设计。

开放存储格式可以让安全记录更易于复用，但不会自动让检测规则、事件工作流或自动化操作手册具备可移植性。这些更高层级的资产往往依赖专有架构和 API。

这让安全领导者面临一个更精确的问题。他们并非在抽象意义上选择开放性或集成性，而是在决定哪些地方接受专业化、哪些地方要求可移植性，以及哪些地方的治理必须保持一致。

真正的竞争是数据层与 SIEM 套件之争

Databricks 正押注于：对安全数据的控制将比对传统分析师控制台的所有权更重要。

传统 SIEM 集摄取、规范化、搜索、检测、告警、调查和报告于一体。它的价值来自将这些功能整合进以安全为中心的工作流。其弱点则会在数据量增长快于预算或运营能力时显现。

Databricks 从相反的方向切入这一问题。它首先提供可扩展的数据存储、开放处理工具、集中治理和机器学习，随后再在这一基础之上构建安全功能。

这一模型可以帮助团队保留原始遥测数据以供日后调查，也支持在安全记录与业务上下文之间进行关联。当分析师能将异常登录与员工角色、受管设备、应用负责人和近期访问变更联系起来时，这一事件就更有价值。

AI 驱动的防御受益于这种上下文。仅接收告警标题和少量事件字段的模型，拥有的证据有限。能够检索已获授权历史记录的受治理智能体，更有可能生成有用的摘要。

更多数据并不保证得到更好的答案。糟糕的规范化可能造成相互矛盾的身份、重复事件和误导性的时间线。安全团队仍需维护架构、质量检查、数据血缘和检测逻辑。

这正是 SIEM 厂商仍保有优势的地方。它们提供安全专用内容、成熟的调查界面、连接器、案件管理和响应集成。许多客户宁愿选择这些封装好的能力，也不愿在通用数据平台上自行组装。

Google Security Operations 在专门的运营环境中提供云规模安全分析和威胁情报。Microsoft 将 Sentinel 与其身份、终端、生产力和云产品相连接。CrowdStrike 则正将终端和威胁数据扩展为智能体式安全平台。

Splunk 拥有庞大的既有客户基础、广泛的集成能力和多年积累的检测内容。Palo Alto Networks 及其他安全厂商也在整合数据与自动化。Databricks 进入的是一个采购方早已面对重叠平台主张的市场。

Databricks 最有力的定位并非立即替代，而是提供架构杠杆。组织可以利用 lakehouse 减少遥测数据重复、保留更多历史数据、丰富调查上下文，并在不一次性迁移所有运营流程的前提下测试 AI 辅助工作流。

分阶段推进也让性能更易衡量。团队可以先从日志成本优化或历史威胁狩猎入手，将查询速度、检测覆盖率、工程投入和总体运营成本与现有系统进行比较。

下一阶段可以将部分检测迁入 Databricks。安全工程师可通过熟悉的开发实践管理逻辑，包括版本控制和测试。告警仍可流入既有的案件管理系统。

全面替代需要更多证据。主 SIEM 必须支持可靠的数据摄取、低延迟检测、调查连续性、审计要求和响应协同。它还必须在影响其他企业系统的事件发生期间保持可用。

Databricks 将 Lakewatch 定位为构建在其平台之上的开放式、智能体化 SIEM。产品方向让其竞争意图更加清晰：Databricks 希望从支持安全分析，转向掌控更多运营工作流。

这一转变会在数据保留经济性和数据访问方面向传统供应商施压，同时也要求 Databricks 满足安全领域的特定预期。数据平台的可靠性固然必要，但运营防御系统还承担着额外责任。

买方的主动权来自于将厂商主张拆分为可测试的层面。存储经济性可以独立于检测质量进行评估；智能体生产力可以与响应安全性分开评估；可移植性则可在数据、查询、规则和工作流层面进行测试。

安全负责人还应追踪隐性人力成本。一个平台可能减轻许可证成本压力，却增加工程工作量。模式维护、连接器开发、检测调优、权限管理和待命支持都应纳入比较。

这正是 Databricks 的提议比又一次 AI 功能发布更重要的原因。它重新开启了企业数据基础设施与安全运营中心之间边界的讨论。多年来，这条边界一直塑造着安全预算和工作流。

AI 驱动的防御继承了 AI 治理难题

能够压缩调查流程的同一批智能体，也可能加速错误、未授权访问和监管不足的响应。

Databricks 将治理作为架构的一部分，而非独立的合规步骤。Unity Catalog 控制对数据和 AI 资产的访问；Unity AI Gateway 管理通往模型和工具服务的流量。

该公司的 AI 治理指南称，该网关可以路由模型和 Model Context Protocol 请求，也可以跨不同提供商实施限制、应用策略并记录使用情况。

Model Context Protocol，即 MCP，是一种让 AI 应用连接工具和数据源的标准。在安全环境中，MCP 服务可能会暴露威胁情报、工单功能、资产记录或获批准的响应工具。

集中控制带来实际好处。组织可以通过与其他数据资产相同的访问层，治理外部模型、编程智能体或 MCP 服务。Databricks 表示，这可以涵盖来自 Google、Anthropic 和 OpenAI 的模型。

部分能力仍处于 beta 阶段。Databricks 描述了一类服务策略，可根据内容允许、拒绝或要求批准请求。当这些策略被期望阻止敏感数据暴露或危险工具使用时，预览状态尤为重要。

任何安全负责人都不应将 beta 阶段的护栏视为保护生产环境响应操作的唯一屏障。防御需要重叠式控制：身份限制、范围受限的工具、审批关卡、日志记录、速率限制和可逆操作应彼此强化。

人工审查也需要精确界定。要求分析师批准每一项建议能够保留控制权，但也可能重建原本希望通过自动化减少的队列。允许广泛自治可以提升速度，却会扩大错误决策的影响。

务实的设计会按后果划分操作。只读检索的风险低于禁用账户；起草检测规则不同于部署规则；隔离单个终端不同于修改全网策略。

每个类别都需要独立的授权边界。高置信度、可逆的操作可以获得更多自动化；模糊或高影响的操作则应要求额外证据和明确批准。

数据暴露带来另一项担忧。调查智能体通常需要用户活动、设备详情、应用日志和组织上下文。即使每个来源单独看来无害，这种组合也可能暴露敏感的个人或商业信息。

Databricks 在其 AI 信任文档中表示，合作模型提供商不会存储提示词或响应。它还表示，Unity Catalog 权限决定其 AI 功能可以发送哪些数据。

该文档承认，模型可能产生幻觉或给出错误答案。这一警告在安全领域尤为重要，因为流畅但不准确的摘要可能将调查引向错误方向，或错误牵连某位用户。

具备权限感知能力的检索可减少未授权访问，但无法证明事实准确性。团队需要基于真实事件模式、对抗性输入、不完整遥测数据和相互矛盾证据进行评估。

提示词注入增加了另一种风险。攻击者可能在工单、日志字段、代码库或智能体随后会检索的文档中放入恶意文本。如果系统将这些内容视为指令，调查工作流就可能遭到操纵。

治理策略可以过滤部分攻击，但可靠防御还依赖架构隔离。检索到的数据应始终被视为不可信；工具应在模型之外执行授权；敏感操作不应仅依赖生成出的决策。

可审计性成为最终检验。团队需要记录智能体访问了哪些数据、由哪个模型处理、调用了哪些工具，以及由谁批准结果。缺少这条链路，事件复盘和监管证据都会变得困难。

这同样适用于安全运营中心之外的知识工作。使用 AI knowledge base 的团队也会面临权限、来源质量和可追溯性等类似问题。安全领域提高了后果的严重性，但治理原则依然相同。

Databricks 已为这一问题整合了可信的组件。该公司尚未证明每位客户都能将这些组件组合成安全的自主防御体系。结果取决于实施纪律、衡量方式和运营责任归属。

三项信号将显示该战略是否奏效

下一项考验不是又一次 AI 演示，而是 Databricks 能否在不将成本和风险转移到其他环节的情况下改善防御的证据。

第一个信号是可被独立理解的客户表现。Databricks 需要更多案例研究，明确界定基线、工作负载、部署范围和衡量周期。缺少这些细节的百分比虽然吸引眼球，却只能提供有限指导。

安全负责人应关注检测覆盖率、平均调查时间、误报率、保留深度和总体工程投入。成本主张应包括迁移工作、连接器维护、基础设施和人员配置。

如果客户能够在保留更广泛遥测数据的同时，缩短调查时间并降低运营成本，Databricks 的论据将更有说服力。如果节省依赖大量定制工程，其对较小团队的吸引力就会下降。

第二个信号是受治理智能体运营的成熟度。服务策略、审批控制、工具限制和审计记录必须超越演示阶段。买方需要了解系统在故障、攻击和证据模糊情况下的文档化行为。

一项有价值的验证应展示：智能体遇到恶意检索内容时不会遵从它。另一项则应展示：因请求身份缺乏权限，响应操作被阻止。团队还需要清晰的回滚和事件复盘流程。

如果这些控制措施实现全面可用并经受住对抗性测试，AI 驱动防御的论点将更强。如果关键保障措施仍停留在预览阶段，或需要大量定制工作，自主性就应保持严格边界。

第三个信号是竞争对手的反应。Google、Microsoft、Splunk、CrowdStrike 和 Palo Alto Networks 已掌控重要的安全工作流。它们可以调整保留模式、开放数据访问、扩展智能体治理或深化云集成。

Google 值得特别关注，因为它既是基础设施合作伙伴，也是安全平台竞争对手。databricks google customer 可以组合使用双方的服务，但重叠的控制平面可能导致责任归属不清。

更紧密的互操作性将有利于 Databricks。安全数据可以保持可移植性，而告警、案件、威胁情报和响应操作则通过定义明确的接口流转。买方无需重建每一项工作流，便能获得架构选择权。

更紧密的平台捆绑则可能削弱这一主张。如果既有供应商将可接受的存储经济性与成熟的安全智能体结合，客户可能更倾向于选择单一运营套件。在事件发生期间，便利性和责任明确性往往比架构优雅更重要。

安全负责人不必立即选择最终架构。他们可以针对一个成本高昂或碎片化的工作负载测试 Databricks 模式。历史威胁狩猎、云审计分析和检测开发都提供了边界明确的起点。

试点应保留现有工作流，同时产出可比较的衡量数据。团队应在迁移数据前定义成功标准，也应记录规范化遥测数据并保持检测可靠性所需的人力投入。

一项有用的审查会提出五个问题：新系统是否保留了更多相关数据？分析师是否调查得更快？检测是否得到改善？总体运营投入是否下降？治理是否仍然易于理解？

答案将显示 lakehouse 是否正成为安全运营层，还是仅仅成为日志的又一个目的地。它们也将区分 AI 价值与存储价值，而供应商常常将二者一并呈现。

Databricks 已识别出一个真实约束：智能体无法弥补碎片化、难以访问或治理不善的安全数据。其指南为安全负责人提供了重新审视数据存放位置及控制权归属的理由。

尚未解决的问题是运营信任：一家数据平台公司能否交付一线防御系统所期待的可靠性、安全内容、响应控制和问责能力？

对于评估 databricks google architecture 的团队，下一步应是审慎比较，而非立即替换。选择一个调查工作流，明确其权限，并记录基线结果。随后测试统一上下文是否能在不扩大访问范围或增加隐性人力的情况下改善决策。这些证据将比产品演示中智能体的数量更重要。