Databricks安全: Databricks数据和AI安全审查工作流

Databricks数据和AI应用程序的Databricks安全取决于受控访问、可信证据和明确的行动边界。代理可以帮助收集信息并路由审查，但敏感决策仍需要明确的策略和负责的负责人。将平台控制连接到应用程序的实际记录、工具和网络路径，然后验证预期的限制。

2026 年 9 月 24 日，Databricks 发布了一篇关于构建基于代理的安全审查的文章。作者描述了在 Databricks 内部完成的工作。本文从该文章和相关的官方文档中汲取了实施经验。它不声称 ImadDhin 构建了该系统，实现了供应商的成果，或运营着已部署的 Xion 安全产品。

基于代理的安全审查的实际经验教训是什么？

供应商文章描述了通过专注于帮助理解请求、应用标准、寻找缺失信息以及识别何时需要人工介入的代理来扩展现有审查流程。有用的设计原则是具有证据和升级机制的受控工作流。自动化可以处理可预测的工作，而组织则保留对新颖或高风险决策的人工判断。

首先确定审查问题以及回答这些问题所需的记录。关于常规集成的请求可能需要与暴露敏感数据的新架构不同的路径。应用程序应区分缺失的证据和支持批准的证据。模型流畅的解释本身并不能证明存在控制措施或请求符合组织的策略。

对于提议的实施，在选择模型之前，请定义输入、允许的数据访问、决策输出和升级负责人。记录决策使用的策略版本以及支持该决策的证据。当证据不完整或相互矛盾时，流程应要求澄清或路由给相关人员。这些是工作流要求，可以独立于代理文本听起来有多令人信服进行测试。

Unity Catalog 权限应如何连接到应用程序？

Databricks 通过对受控资产的特权来描述 Unity Catalog 访问控制。将该模型转换为应用程序的身份和操作。识别哪个用户或服务主体执行每个查询，它需要哪些资产以及它可以执行哪些操作。广泛的服务身份可能会破坏原本谨慎的用户端限制。

将最小特权应用于工作流，而不是为每个代理提供配置它的开发人员的访问权限。汇总一个团队记录的代理不应仅仅因为实施通过共享管理员身份运行而获得导出所有客户数据的权限。应用程序需要将调用者的允许目的和记录绑定到工具执行，并且数据平台需要相应的访问策略。

使用代表实际用户和服务的身份进行测试，而不仅仅是所有者帐户。验证读取、写入、导出和更改策略承载资产的拒绝情况。包括使用不同身份的任何备用应用程序端点。作为管理员的成功笔记本查询演示了功能，但它不能证明权限较低的应用程序流遵守了预期的数据边界。

分类和掩码为设计增加了什么？

Databricks 于 2026 年 5 月 13 日宣布 ABAC 行过滤、列掩码、受控标签和数据分类全面可用。该公告将这些功能与策略驱动的治理联系起来。在确定具体的实施设计之前，请在文档中确认当前的功能支持、计算要求和限制。

分类有助于识别敏感数据；策略决定如何处理它。标记为敏感的列并不能自动证明每个读取者都收到掩码值。定义允许的组、目的和访问路径，然后验证策略如何应用于您使用的资产和运行时。考虑派生表和导出以及源记录，因为敏感值可能会移动到新位置。

测试时使用带有合成标识符的代表性数据。针对预期的行和列行为检查特权用户、普通用户和服务身份。确认允许的工作流仍然接收所需的信息。如果集成无法对导出的副本强制执行相同的策略，请将其记录为具有自己控制的单独边界，而不是假设源策略随处遵循数据。

为什么 AI 代理需要独立的工具授权？

Databricks 的提示注入缓解指南讨论了针对结合敏感数据、不受信任的输入和外部操作的代理的分层控制。重要的应用问题是工具调用获得何种权限。检索到的文档、用户消息和模型生成的参数不能仅仅因为它们出现在一个代理工作流中就成为不受限制的授权源。

将受信任的工作流定义与代理读取的内容分开。为每个工具提供受限接口，验证其参数并检查调用者对请求记录或操作的权限。可以发出退款、更改账户或导出记录的工具需要在操作执行时进行这些检查。不要仅仅依靠指示模型负责任地行事的指令作为唯一的强制机制。

交互式网络安全实验室展示了一个需要范围访问和人工决策的导出请求。其 Xion 视图显示了模拟的允许、阻止和批准结果。这些结果是预期策略行为的示例，而不是运行时保护引擎正在运行的证据。生产实施需要可强制执行的检查、经过身份验证的批准以及针对真实集成边界的验证。

人工升级和批准应如何运作？

决定哪些请求可以自动完成，哪些必须停止，以及哪些需要负责任的审查员。标准应参考操作和证据，而不是仅仅是代理的置信度分数。缺少数据分类或新的出站集成可能需要与已知的低风险读取操作不同的审查。保留路由的原因，以便操作员可以评估其是否适当。

将批准绑定到确切的操作、参数和授权执行者。如果提议的导出在批准后发生更改，则先前的批准不应静默授权新范围。定义过期、撤销以及当事人未响应时发生的情况。界面应区分已批准的操作和等待批准的操作，并且执行服务应验证决策，而不是信任浏览器字段。

测试被拒绝的操作、已批准的操作、过期的批准和更改的参数。检查工作流是否无法通过通过另一个端点重试或使用更高级别的服务身份来绕过其审查。清晰的审计跟踪应解释谁批准了什么以及可用的证据。当引用足够时，将敏感文档内容排除在普通操作消息之外。

哪些网络和出站数据边界很重要？

访问权限和网络限制解决不同的问题。正确认证的应用程序仍可能将数据发送到预期工作流之外的目的地。清点应用程序可以访问的外部 API、存储位置和模型服务。决定每个操作允许哪些目的地以及哪些类别的数据可以离开受管环境。

Databricks 的无服务器网络安全指南描述了特定于平台的连接控制。评估您的云和部署模式支持的配置，而不是假设每个私有网络模式都适用于每个工作负载。记录应用程序、模型和工具的执行位置，因为相关的出站连接源自该运行时。

使用与应用程序相同的身份和运行时测试被拒绝和允许的目的地。单独考虑 URL 获取工具、回调和导出目的地。当模型输出包含 URL 时，将其视为获取操作的不受信任输入。记录决策和必要的引用，同时保护凭据和不必要的个人数据。网络控制补充而不是取代记录级权限检查。

审查证据和监控应如何治理？

供应商审查文章描述了治理堆栈中的标准、请求数据、证据、决策和操作输出。实施应将访问策略应用于这些记录本身。安全审查文档可能包含架构详细信息和敏感集成信息。公共仪表板或对证据存储的广泛读取权限可能会引入新的暴露，而审查过程试图减少另一个暴露。

记录足够的上下文以重现和质疑决策：请求身份、策略版本、相关证据引用、路由、审查员和最终操作。建立适合组织的保留和访问要求。避免在跟踪中存储完整的秘密或不必要的客户记录。为审查员提供一种纠正错误分类的方法，而不会抹去工作流所做操作的历史记录。

监控应标记重要的执行失败、指示问题的被拒绝操作以及缺乏负责任所有者的队列。解释哪些警报是可操作的以及谁负责响应。少量警报并不能证明安全性；大量警报也不能证明有用的检测。在声称操作控制已完成之前，测试通知和响应路径。

哪些控制属于哪个安全层？

此比较将治理能力与它们必须支持的应用程序行为分开。策略可以成功配置，而应用程序却使用了错误的身份或暴露了派生数据集。评估需要在执行点提供证据，而不仅仅是控制设置的屏幕截图。Supabase 策略指南 提供了一个较小的应用程序示例，说明了相同的拥有权问题。

企业团队对范围界定的项目有何期望？

从范围内的应用程序、身份、敏感资产和重要操作开始。生成一份带有证据和实施参考的优先发现列表。对于补救措施，就策略更改、应用程序检查和测试达成一致，以证明原始故障已得到解决。在验收集中包含合法的工作流程，这样限制性更改就不会悄悄地扰乱使用平台的人员。

在交接时，将已完成的配置、已验证的行为和未解决的依赖项分开。架构提案不是认证或合规性保证。使用合成数据进行演示有助于解释设计，但不能替代在预期运行时中的测试。同样的区别也适用于较小应用程序的 vibe-code rescue 工作。

要讨论受控数据访问、AI 工具或审查工作流程，请预约 30 分钟的安全通话。我们将确定实际评估所需的系统和证据。网络安全实践 将该评估与实施、支付和数据强化以及运营交接联系起来。