Databricks Apps 用户授权现已 GA，但身份边界仍然重要

Databricks 于 10 月 7 日宣布 Databricks Apps 用户授权正式发布，此前该功能已进行了超过 18 个月的公开预览。该功能使应用能够以已登录用户的身份调用受支持的平台服务。这改变了数据应用和 AI agents 的一项核心安全决策：每项请求应由谁的权限来约束？

此前，开发者通常依赖应用的服务主体（service principal），这是一种分配给单个应用实例的非人类身份。除非开发者在应用内重新实现用户级访问规则，否则每位用户都可能通过这个共享身份获得结果。新模式可让现有的 Unity Catalog 策略随用户进入应用请求。

这项承诺附带一个重要前提。代表用户授权（on-behalf-of-user authorization），即 OBO，并不会默认让应用变得安全。开发者必须区分用户驱动的操作和后台任务，请求范围有限的 scopes，保护转发的 tokens，并在缺少预期身份时拒绝请求。

这项公告将 Databricks 置于平台托管授权与应用托管权限逻辑之间更广泛的竞争中。Microsoft 通过自身的 OBO 流程支持委托身份，而其他云平台则提供独立的身份和策略组件。Databricks 正将这一模式直接连接到其平台上受治理的企业数据、SQL warehouses、agents 和应用。

Databricks Apps 用户授权改变了每项请求的治理主体

GA 版本为开发者提供了一种受支持的方式，可在整个应用请求过程中保留用户现有的数据权限。

Databricks Apps 在无服务器基础设施上托管数据应用、运营工具、仪表板和自定义 agents。每个已部署的应用都会获得专属服务主体，可访问授予该应用的资源。这种应用授权仍然可用，并继续适用于共享或自动化操作。

用户授权增加了第二条身份路径。当已登录用户发起受支持的操作时，Databricks 会将访问 token 转发至应用运行时。随后，应用可使用该用户的身份和权限调用获准的 Databricks API。

平台的授权模型采用 OAuth 2.0，即用于委托访问的标准协议。它区分用户到机器授权与机器到机器授权：前者代表交互式用户，后者代表应用或自动化工作负载。

当应用访问受治理的数据时，Unity Catalog 会评估用户已有的授权。行过滤器可限制显示哪些记录，而列掩码可隐藏或转换敏感字段。Warehouse 权限也决定用户是否能够执行所请求的查询。

结果取决于发起请求的人。区域销售经理可能只能获得某一地区的数据，而全国负责人则能看到所有地区。两人可以使用同一应用和请求路径，但不会获得完全相同的访问权限。

这项行为很重要，因为应用无需为每条治理规则单独维护副本。当管理员更改 Unity Catalog 策略时，后续应用请求将依据更新后的策略进行评估。开发者可避免维护一套可能偏离平台控制措施的并行授权系统。

Databricks 最早于 2025 年 3 月 26 日为 Apps 推出 OBO 授权的公开预览。预览版本涵盖 Unity Catalog 表和模型服务端点等资源。正式发布意味着 Databricks 现已认为，在其已记录的限制范围内，这一模式适合用于生产环境。

GA 并未取代应用授权。Databricks 明确将两种模式定位为互补关系。应用可以使用自身身份处理共享配置、遥测或日常维护，再使用当前用户的身份执行受治理的查询。

以回答账户业绩问题的销售洞察助手为例。其应用身份可能读取通用配置并记录运营指标；其用户身份路径则会查询请求员工有权访问的客户和销售记录。

这种划分正是此次发布的基础。应用仍然拥有身份，但该身份不再需要成为每项交互式操作的通用网关。开发者可决定每项操作由哪个主体来治理。

因此，这项变化所解决的不止是登录问题。身份验证决定谁在场，而授权决定该身份可以做什么。Databricks Apps 用户授权将后一项决策延伸至下游的数据和服务调用。

真正的压力落在应用托管的访问控制上

Databricks 正在挑战一种做法：在每个应用中重新构建企业数据权限。

仅使用共享服务主体的应用通常只会看到一套固定权限。随后，开发者必须决定每位员工可以获得哪些结果。这往往需要自定义角色、策略映射、过滤逻辑或另一项授权服务。

这些控制措施可以发挥作用，但也引入了第二个事实来源。治理团队可能更新了 Unity Catalog 授权，而应用的本地角色映射仍未变化。由此产生的不匹配可能导致信息暴露，或拒绝合法访问。

对于受支持的 Databricks 资源，用户授权减少了这种重复。请求者既有的权限成为执行上下文的一部分。应用代码可以专注于所请求的任务，而平台则负责评估受治理的访问。

这对 AI agents 日益重要。传统仪表板提供预定义的视图和查询；agent 则可以理解开放式语言、选择工具、组合查询，并通过多个步骤检索信息。

这种灵活性扩大了访问受保护数据的路径数量。开发者无法可靠地预判员工可能提出的每一个问题。保留员工的授权上下文，为下游平台提供了另一道执行边界。

当组织将原型推进至生产环境时，这种压力尤为明显。早期演示通常使用开发者凭证或拥有广泛权限的服务账户运行。当应用面向承担不同角色、负责不同区域且有不同保密要求的员工时，这种捷径就很难辩护。

一个应用可能同时服务销售、财务、运营和管理层。这些群体不应自动继承对客户详情、预测数据或员工信息的同一视图。随着受众扩大，集中式策略的价值也会提升。

Databricks 还在减少治理管理员与应用团队之间的摩擦。安全团队可以继续通过 Unity Catalog 管理数据权限；开发者无需将每项策略转换为特定框架的中间件。

这并不意味着开发工作会消失。团队仍须判断某项操作应属于用户还是应用，也必须了解哪些 Databricks API 支持 OBO，以及每项操作需要哪些授权 scopes。

替代平台并不缺少委托身份。Microsoft 的OBO 流程会将用户身份和委托权限从上游 API 传递给下游 API。Google Cloud 提供身份感知的应用访问能力，而 AWS 则为自定义应用提供细粒度授权组件。

Databricks 的差异化之处在于其与数据治理环境的集成。授权决策与 Unity Catalog 权限、SQL 访问和受支持的平台服务相结合。对于数据已经位于 Databricks 内部的应用，这可以减少集成工作。

代价是更高的平台依赖性。围绕 Unity Catalog 规则和 Databricks 特定 scopes 构建的应用会继承实用的控制措施，但也会与单一平台的身份模型紧密绑定。多云团队可能仍需要为 Databricks 之外的资源增加另一层授权机制。

因此，对企业买家而言，问题不在于其他地方是否存在委托身份，而在于 Databricks 是否能够充分简化受治理应用的开发，以便将更多数据和 AI 工作负载留在其平台内。

代表用户授权如何形成两道权限边界

OBO 请求只有在同时满足用户权限和应用获准 API scope 的范围内才能成功。

第一道边界涉及数据和资源。用户不能仅因应用发出请求，就访问 Unity Catalog 表、SQL warehouse 或受支持的服务；该用户必须已经拥有必要权限。

第二道边界涉及应用。开发者声明 API scopes，用于定义应用可代表用户执行的操作类别。Scope 不会授予用户新的数据访问权限，但会限制应用如何使用既有访问权限。

对于只读 SQL 分析，Databricks 记录了 sql:restricted-query scope。应用可作为当前用户提交受限查询，而不会获得广泛的权限来管理 warehouses 或执行无关的管理工作。

这些交叉边界支持最小权限原则，即仅授予完成一项任务所需的访问权限。高权限用户可能可直接访问大量数据集；范围受限的应用仍不应能够行使该用户拥有的每一项权限。

Workspace 管理员控制另一项上限。他们可以决定开发者可向 workspace 中应用添加哪些用户授权 scopes。允许列表可以包含所有受支持 API、选定 scopes，或完全不允许用户授权。

这一结构划分了责任。开发者请求产品所需的最小能力；管理员则决定应用开发者可在 workspace 内请求哪些能力。

不过，管理员不能仅依赖配置。Databricks 表示，即使 workspace 允许列表排除了某些 scopes，账户管理员仍可添加这些 scopes。现有应用也可在允许的 scope 被移除后继续运行。

根据公告，受影响的应用在移除不被允许的 scope 前，后续将无法启动、部署或更新。这种行为避免了立即中断服务，但也形成了一段当前执行状态与当前策略并不完全一致的时期。

因此，团队应将 scope 变更视为受治理的运营事件。管理员需要掌握已部署应用、请求的 scopes、责任人和业务依赖关系的清单。缺少这些背景便移除某项能力，可能延误补救工作，或在应用下一次部署时使其陷入停滞。

应用代码也必须将两种身份分开。用户范围的客户端应处理受治理的交互式操作；应用范围的客户端则应处理共享配置、指标，以及必须在没有用户会话时持续运行的工作。

这不仅仅是命名偏好的问题。通用客户端可能掩盖究竟是哪个身份在执行敏感路径。将依赖项、测试和请求处理程序分开，可让非预期凭证使用情况更容易被发现。

最严格的规则涉及缺失的用户令牌。如果某条路由需要用户授权，但未提供转发令牌，应用程序应当默认拒绝访问。它应拒绝该请求，而不是悄然切换到自身的服务主体。

回退机制或许会在完全不同的权限下生成技术上有效的答案。用户几乎没有理由怀疑应用访问的信息范围比预期更广或更窄。这使得静默的身份变更尤其危险。

转发令牌应仅在当前请求期间存在。Databricks 建议开发者绝不要打印、记录或持久化该令牌。后台作业应使用应用授权，而不是在交互式会话结束后保留用户令牌。

对于构建内部 AI 工具的团队而言，这种身份分离应与其他工程控制措施并列。一个可搜索的技术知识库可以将授权决策、威胁模型和审查证据与实现文档一同保留。

AI Agent 让身份边界更难维持

Agent 可受益于用户专属权限，但其多步骤行为会让身份错误带来更严重的后果。

Databricks 表示，通过 Apps 部署的自定义 Agent 可以采用相同的授权模型。必须在当前的 invoke 或 stream 处理程序内初始化以用户为作用域的工作区客户端。转发令牌仅在请求运行期间可用。

这一时序约束避免开发者将用户身份视为全局应用状态。一个 Agent 进程可以服务许多人，而应用启动并不属于任何单一用户。过早创建以用户为作用域的客户端，可能导致请求上下文缺失或混淆。

Agent 工作流还会组合不同类型的任务。某一步可能通过应用身份检索共享指令；另一步可能以用户身份查询受治理的财务数据；第三步可能写入通用遥测数据，但不保留用户凭证。

每一次切换都会形成一项授权决策。开发者需要为每次工具调用识别主体、范围、资源和预期的失败方式。单一的通用 Agent 客户端可能模糊这些区别。

当 Agent 调用另一项服务时，挑战会进一步加大。只有在下游集成支持该模型的情况下，OBO 才能保留用户上下文。外部 API 可能需要单独的凭证、同意授权、权限范围和审计控制。

Agent 不应假定授权会自动跨越整个工具链传递。令牌是为特定受众和用途签发的。Microsoft 的 OBO 指南同样警告，不应将中间层令牌转发给非预期接收方。

这意味着，用户授权不应被描述为全面的身份模拟。应用只会在已配置的范围和受支持的请求路径内代表用户行事。这样的措辞很重要，因为“代表用户行事”否则可能暗示不受限制的访问。

提示词注入也构成了另一个需要谨慎的理由。攻击者可能在 Agent 检索的内容中植入指令，诱使其调用工具或披露信息。OBO 将可访问数据限制在当前用户范围内，但它并不能判断某项请求的操作是否合理。

用户自身的权限也可能非常广泛。一位高管、管理员或分析师可能拥有访问多个业务职能中敏感数据集的权限。被入侵的应用若使用该人员的有效身份，仍会构成严重风险。

在这种情况下，权限范围提供了重要的第二道边界。只读查询范围可以防止无关的管理操作，但它无法判断每一项允许的查询是否符合用户意图。应用仍需要输入处理、工具约束、输出控制和监控。

同意授权同样值得审视。用户可能在不了解 Agent 将如何组合服务或处理结果的情况下批准所请求的权限。清晰的范围名称有所帮助，但同意授权不能替代管理审查和受约束的应用行为。

可审计性变得至关重要。安全团队需要区分由应用身份执行的操作与代表个人执行的操作。日志应标识相关主体和操作，但不应记录持有者令牌或敏感响应内容。

测试必须涵盖具有不同权限的用户。仅使用管理员账户进行测试可能掩盖错误，因为该账户很少遇到访问拒绝。Databricks 建议在治理策略发生变化后重复测试。

有用的测试案例包括：具有区域访问权限的用户、拥有更广泛访问权限的用户，以及完全无权访问所查询表的人员。团队应同时验证返回的数据和拒绝行为，还应确认缺失令牌绝不会触发应用身份回退。

因此，核心限制很明确。Databricks Apps 的用户授权可以实施现有平台权限，但无法修复过于宽泛的授权。组织仍必须维护准确的用户组、目录权限、仓库访问权限、行过滤器和列掩码。

安全承诺取决于运营纪律

该设计最强的部分是其分层控制模型，而最薄弱的部分仍是围绕该模型的实现和治理。

Databricks 可以转发适当的身份并实施已声明的范围，但它无法确保每个开发团队都将正确身份分配给每条代码路径。这一决策仍属于应用架构的一部分。

团队可能正确地对 SQL 查询使用 OBO，却意外地对相关文件请求使用应用身份。用户界面可能合并两种响应，却不揭示其中不同的授权上下文。

后台处理则构成另一道边界。用户可能发起一项在请求结束后继续运行的长时间任务。由于转发令牌属于活跃请求，开发者不能简单地将其保留以供后续执行。

更安全的设计是确定延迟执行的任务是属于应用，还是需要另一种受支持的委派模式。如果它属于应用，服务主体需要经过谨慎限制的权限；如果它需要用户上下文，开发者必须遵循已记录的平台行为，而不是保留令牌。

跨环境的可用性也需要确认。随着服务和合规配置的扩展，Databricks 文档会不断变化。团队应在将 GA 视为普遍可用之前，验证云环境、区域、工作区和安全配置文件支持情况。

Apps 本身不能是匿名的公共应用。Databricks 表示用户必须进行身份验证，外部协作者则需要通过受支持的身份联合完成接入。这使该模型最适合采用托管身份的员工和合作伙伴场景。

应用权限与数据授权之间的区分可能让审查人员感到困惑。CAN USE 和 CAN MANAGE 决定谁可以运行或管理应用，但并不决定某人可以通过应用访问哪些表或记录。

某人可能拥有使用应用的权限，却没有查询其底层数据的权限。该请求应失败或仅返回受限结果。反之，仅具备数据访问权限也未必赋予其打开应用的权限。

因此，文档中的权限级别需要与 Unity Catalog 授权分开审查。将两者视为同一项控制措施，可能在审计期间造成虚假的安全感。

管理性范围允许列表带来了另一项治理任务。根据公告，默认设置可以包含所有受支持的 API。注重安全的组织应在广泛采用应用之前，决定这一默认设置是否符合其开发模式。

收窄允许列表可以降低风险，但也可能阻碍合法产品。正确的流程是将受限的基线与有文档记录的例外路径相结合。否则，团队可能为规避范围限制而寻求权限更广泛的应用身份。

检测同样面临挑战。一个应用可能只请求获批范围，却仍在这些范围内行为不当。运行时监控应关注异常查询模式、重复拒绝、意外的数据量以及应用行为变化。

目前尚无独立基准能够证明该功能节省了多少开发时间，或企业在多大程度上避免了权限缺陷。GA 公告解释了其机制和推荐做法，但采用成效仍有待验证。

Databricks 也有动力让其治理层成为内部应用和 Agent 的默认基础。买方应将这一战略优势与可移植性、集成工作量以及其现有授权系统的成熟度一并评估。

相关比较并非简单的 Databricks 对 Microsoft 之争。Microsoft 的委派身份模式已经成熟，并可广泛适用于各种 API。Databricks 则围绕自身的数据、计算、治理和应用运行时，封装了一个相关原则。

Google 的身份感知访问侧重于控制对托管应用和上下文策略的访问。AWS 提供可由开发者与身份提供商和应用资源组合使用的授权组件。每种方法都会将不同的工作分配给平台和应用团队。

组织应比较策略存放位置、覆盖哪些资源、身份如何跨越服务边界，以及拒绝访问如何呈现给用户。它们还应测试审计记录能否清晰地将一项操作同时关联到应用和发起该操作的人员。

GA 标签降低了一项采用障碍，但并未解决这些架构问题。当数据治理已驻留在 Unity Catalog 中，且应用主要调用受支持的 Databricks 服务时，该功能最具说服力。

三项信号将表明此次 GA 发布是否兑现承诺

下一项考验在于，企业能否在不扩大令牌风险、策略复杂性或平台锁定的情况下采用具备用户感知能力的应用。

第一个信号是内部 Agent 和运营应用在生产环境中的采用情况。Databricks 描述了清晰的销售洞察场景，但实际部署将涉及更复杂的 SQL、模型、文件、仪表板和外部服务组合。

成熟采用的证据将包括可重复使用的架构模式、参考实现和清晰的审计工作流。它还应包括能够服务权限存在实质差异的用户、且无需在代码中重复这些规则的应用。

薄弱的采用情况将表明受支持的范围、下游服务或组织流程仍然过于有限。尽管已有 GA 选项，团队仍可能继续使用拥有宽泛权限的服务主体或单独的授权产品。

第二个信号是受支持 API 范围的扩展和细化。更窄的范围使最小权限设计更容易实现，因为开发者可以请求一种能力，而不会获得无关的权限。

范围更广但粗粒度的权限会削弱第二道权限边界。更细粒度的范围、更完善的管理控制和更清晰的同意体验，将强化 Databricks 的主张：应用可以代表用户行事而不过度越权。

对合规安全配置文件支持的调整同样重要。Databricks 表示，用户授权将在 2026 年 9 月下旬扩展至采用合规安全配置文件的工作区。客户应在自身环境中确认可用性与限制。

第三个信号是竞争对手如何将委托身份整合进其 Agent 平台。Microsoft 已为传统 API 和较新的托管 Agent 场景提供了 OBO 文档。其他平台也在将用户身份、工具使用、策略引擎和托管应用运行时连接起来。

如果这些替代方案需要大量定制集成，Databricks 将在围绕受治理企业数据构建的应用中占据优势。如果竞争对手也能在数据和 Agent 工具之间提供同样直接的策略继承，买方将更关注可移植性和生态覆盖范围。

开发者应关注运营层面的证据，而非公告措辞。令牌处理事故、令人困惑的同意流程、权限范围蔓延以及身份回退漏洞，都会削弱这一主张。清晰的审计记录和更低的授权维护成本则会为其提供支持。

眼下的工程任务很容易说明，即使执行时需要严格自律。将每一项应用操作映射为使用应用身份或当前用户身份。授予最小权限范围，拒绝缺失凭据的请求，并使用确实不同的用户进行测试。

团队还应在通过 Agent 暴露现有 Unity Catalog 权限之前对其进行审查。OBO 会如实执行这些权限，其中也包括那些本就超出预期范围的权限。委托无法改善薄弱的源策略。

因此，Databricks Apps 用户授权具有重要意义，因为它让具备身份感知能力的治理更接近数据和应用运行时。它以平台强制执行取代了部分重复的权限逻辑，同时为共享工作保留了应用身份。

它能否成功，将取决于开发者在应用变得复杂后是否仍能维护这一边界。在部署下一款内部助手之前，请针对每一条请求路径问一个问题：这项操作应以应用身份运行，还是以使用该应用的人员身份运行？