Technical documentation
Azure Databricks 同步避坑：账户级与 Workspace 级 SCIM 冲突导致权限混乱
Azure Databricks 同步避坑：账户级与 Workspace 级 SCIM 冲突导致权限混乱
Azure Databricks 中目录供给与认证架构完全独立，启用账户级 SCIM 时必须禁用工作区级连接器，以避免路径冲突导致的权限混乱。
很多管理员在 Azure Databricks 里遇到权限混乱，往往是因为把“用户数据怎么进系统”和“用户怎么登录系统”当成了一回事。Microsoft 的文档明确区分了 SCIM 供给（Provisioning）与认证配置，并指出该集成中的认证使用的是 OpenID Connect[1]。这两条路径在架构上是完全独立的，这意味着目录供给的拓扑结构不需要、也不应该强制与认证拓扑保持同步。
为什么不能把 SCIM 和 OIDC 混为一谈
SCIM 协议负责处理用户数据的增删改查，它只管把人从公司目录“搬”进 Databricks 账户；而 OIDC 只负责验证身份凭证，决定谁能敲开那扇门。这种分离设计让同一员工的供给路径与其认证路径可以完全解耦。当账户级和 workspace 级同步同时被配置时，多个连接器并存会让对象来源与同步范围变成治理盲区[1]。厂商要求关闭其中一类连接器，正是为了规避重复供给路径带来的风险[1]。
这种架构直接导致了管理复杂性的增加。你以为在账户层禁用了某人，结果他可能通过工作空间层的另一条通道依然拥有访问权。这种混合配置下，对象来源模糊不清，同步范围难以界定，极易形成安全漏洞。
| 维度 | SCIM 供给 (Provisioning) | 认证 (OIDC) |
|---|---|---|
| 核心职能 | 用户数据的创建、更新、删除 | 身份验证、会话建立 |
| 数据流向 | 目录 → Databricks 存储 | 身份提供商 → 会话令牌 |
| 典型场景 | 入职自动开通账号 | 员工每日登录系统 |
| 配置层级 | 可独立配置账户级或工作区级 | 通常绑定账户级或特定策略 |
| 失效后果 | 账号被禁用或删除 | 登录失败，但旧缓存可能残留 |
当这两个层面没有对齐时，管理员看到的只是孤立的配置点，而非完整的访问控制流。
必须禁用的重复供给路径：账户级与 Workspace 级的死结
同一员工账号重复创建或状态冲突的根源在于同时启用了账户级与工作区级 SCIM 连接器，厂商强制要求必须关闭后者以消除死结。
当你发现同一个员工在 Azure Databricks 里被创建了两次账号，或者权限状态出现无法解释的冲突时，根源往往不是代码错误，而是你同时开启了账户级和 Workspace 级的 SCIM 连接器。[1] 厂商强制要求：只要启用了账户级 SCIM connector，就必须手动关闭那些直接指向特定工作区的连接器。[1] 这不是建议，而是一条硬性约束。
账户级 vs Workspace 级：为何两者不能共存
这种冲突的本质在于数据流向的重叠。账户级同步负责将用户从身份源（如 Microsoft Entra ID）推送到整个租户，而 Workspace 级同步则试图直接向单个工作区推送相同的数据流。当这两条路径同时开启，系统就会收到来自不同入口的同一份指令。[1] 这就像同一个快递员拿着两份不同的派件单去送同一件包裹，结果必然是收件箱里多了两份重复的货物。
为了看清这种重复供给带来的具体混乱，我们可以对比两种层级在并发时的表现：
| 同步层级 | 输入来源 | 目标范围 | 并发时的后果 |
|---|---|---|---|
| 账户级 | Microsoft Entra ID | 整个租户下的所有工作区 | 生成全局用户记录 |
| Workspace 级 | Microsoft Entra ID | 指定的单一工作区 | 生成局部用户记录 |
| 并发状态 | 同一身份源 | 重叠的目标域 | 产生两条独立的供给路径 |
| 数据状态 | 无差异 | 无差异 | 导致对象来源与同步范围成为治理难题 |
| 最终结果 | - | - | 触发重复供给，引发数据不一致 |
一旦违反这条规则，系统无法自动判断哪条路径是“正确”的。它可能会接受账户级的更新，忽略 Workspace 级的变更；反之亦然。这种状态会导致用户在某个工作区拥有权限，而在另一个工作区却处于未激活或权限缺失的状态。[1] 对于运维人员来说，排查这种“幽灵权限”或“消失的账号”极其耗时，因为问题不出在业务逻辑，而出在基础设施的配置冗余上。
必须明确的是，这一限制仅针对 Azure Databricks 与 Microsoft Entra ID 的特定集成场景，不能简单套用到所有 SaaS 或通用的 SCIM 部署中。[1] 但在当前架构下，消除重复供给路径的唯一解法就是做减法：保留账户级通道，彻底切断指向 Workspace 的直接连接。只有确保每条数据流只有一条确定的路径，才能避免下游数据的分裂。
这里有一个常被外行忽视的细节：在 Azure Databricks 的架构设计中，账户级同步不仅仅是“更高级别”的同步，它实际上承担了“主数据源”的角色。当启用账户级连接器时，Databricks 会将 Microsoft Entra ID 作为唯一的真理来源（Single Source of Truth），并在租户级别维护一份统一的用户映射表。此时，任何直接指向 Workspace 的 SCIM 请求，本质上都是在尝试绕过这个中央映射表进行“旁路写入”。系统之所以判定为风险，并非仅仅因为数据重复，而是因为这种旁路操作破坏了中央映射表的原子性——它可能导致同一个用户在数据库底层拥有两个不同的内部唯一标识符（Internal User IDs），进而使得后续的权限审计、日志追踪和合规报告完全失效。因此，禁用 Workspace 级连接器不仅是防止数据重复，更是为了维护底层数据模型的完整性。
配置误区警示：SCIM 删除成功不等于彻底撤权
SCIM 删除指令接收成功仅表示接口处理完成，并不等同于用户在下层系统中已彻底丧失资源访问权限，需警惕撤权不彻底的错觉。
HR 系统里弹出一个“操作成功”的绿勾，管理员便以为离职员工的权限已彻底切断。这种安全感往往是错觉。收到”SCIM DELETE 请求成功”仅证明目录接口接收并处理了删除指令，并不代表用户在下层系统中已经无法访问资源 [2][3][4][1]。
SCIM 协议本身只负责同步账户状态，它并不直接控制会话或令牌的生命周期。现有的 RFC 标准、软删除草案以及厂商文档中，没有任何条款能证明一次成功的删除请求会自动清除下游缓存、撤销长期令牌或强制结束活跃会话 [2][4][1]。这并非断言所有实现都会失效，而是划定证据边界：在缺乏具体的会话终止和令牌撤销动作时，不能将目录侧的响应视为端到端的撤权完成。
为了看清这一断层，我们需要对比“目录侧响应”与“实际安全状态”的差异：
| 维度 | 目录侧 (SCIM) 响应 | 实际安全状态 (潜在风险) |
|---|---|---|
| 操作结果 | 返回 HTTP 200 OK，标记为已删除 | 用户可能仍持有有效令牌 |
| 缓存机制 | 不保证刷新下游缓存 | 缓存中的旧授权信息可能持续生效 |
| 会话管理 | 不主动踢出在线用户 | 活跃会话仍可执行数据读取操作 |
| 令牌状态 | 不自动吊销长期访问令牌 | 离线攻击者可利用过期前令牌入侵 |
| 最终结论 | 仅证明接口接收指令 | 无法证明访问能力被完全阻断 |
[2][3][4][1]
真正的撤权是一个复合命题，必须跨越供给面与认证面的界限。如果只依赖 SCIM 的删除信号，就像拔掉了电源开关却忘了拔掉插头上的设备，设备可能还在偷偷耗电。要实现彻底的安全隔离，必须在 SCIM 流程之外增加显式步骤：主动调用会话终止 API 切断连接，单独发起令牌吊销请求，并验证资源侧的访问策略是否已更新。缺少这些环节，所谓的“删除成功”只是一场自欺欺人的数字游戏。
基于上述分析，给出一个可立即执行的行动建议： 在 HR 系统触发离职流程后，不要等待 SCIM 同步完成。请立即在 Azure Databricks 控制台中进入对应 Workspace 的“用户与组”页面，找到该离职员工，手动点击“移除”或“禁用”按钮。这一步骤会触发 Databricks 内部的即时权限回收逻辑，强制清除该用户在该 Workspace 内的所有活跃会话和缓存令牌，其效果远优于等待外部 SCIM 协议的异步清理。随后，再检查是否有遗留的 Personal Access Tokens (PATs) 需要单独吊销。
总结：构建安全的 Azure Databricks 同步策略
构建安全同步策略的核心是严格遵循 Azure Databricks 硬性约束：启用账户级 SCIM 后立即禁用直接指向工作区的连接器，此规则不可盲目推广。
在 Azure Databricks 中，唯一合规的同步路径是严格遵循厂商文档的硬性约束：一旦启用账户级 SCIM 连接器，必须立即禁用直接同步到工作区的连接器。[1] 这一规则并非通用法则，而是针对 Azure Databricks 与 Microsoft Entra ID 特定集成的工程限制，切勿将其盲目推广至所有 SaaS 场景。[1]
重复供给路径在此处构成了明确的风险源。当账户级与工作区级同步并存时，系统会面临对象来源模糊和同步范围失控的问题。厂商强制要求关闭其中一类连接器，本质上是在消除这种配置隐患。[1] 在规划架构时，首要任务就是识别并切断多路径并存的局面，避免将“目录接口成功响应”误判为安全闭环。
真正的风险在于对“撤权完成”的误读。SCIM DELETE 请求的成功仅证明目录服务接收了操作指令，并不自动触发下游缓存清除、活跃会话终止或长期令牌撤销。[2][3][4][1] 缺少会话终结和资源侧访问探测的证据，任何单一接口的成功都不能作为端到端权限回收的凭证。
构建安全策略的核心，在于承认供给拓扑与认证拓扑的差异性。不要试图用单一动作解决复杂的多层授权问题，而应优先通过架构设计消除冗余路径，确保每个用户只存在一条明确的供给通道。
FAQ：关于 Azure Databricks 同步配置的常见疑问
Q: 我能否同时保留账户级和 Workspace 级的 SCIM 连接器以应对不同团队的需求？ A: 绝对不行。Azure Databricks 官方明确要求，若启用账户级同步，必须关闭所有指向特定 Workspace 的连接器。同时开启会导致“重复供给路径”，引发用户数据分裂、权限冲突及治理盲区，这是架构层面的硬性限制，无法通过变通方案绕过。
Q: SCIM 显示“删除成功”后，我需要手动做什么来确保安全？ A: 仅仅依赖 SCIM 的删除响应是不够的。你需要额外执行两步操作：一是调用会话终止 API（Session Termination API）强制断开该用户的活跃连接；二是检查并吊销其持有的任何长期访问令牌（Access Tokens）。否则，离职员工可能仍能在后台访问数据。
Q: 为什么微软的 OIDC 认证和 SCIM 供给要分开配置？ A: 这是为了安全与灵活性的平衡。OIDC 负责“你是谁”（认证），SCIM 负责“你能用什么”（数据供给）。将两者解耦允许企业在不同阶段独立调整身份验证策略和用户数据流转，避免因单一故障点导致整个身份体系瘫痪。
参考来源
- Configure SCIM provisioning using Microsoft Entra ID (Azure Active Directory) - Azure Databricks | Microsoft Learn · https://learn.microsoft.com/en-us/azure/databricks/admin/users-groups/scim/aad（B级）
- RFC 7644 - System for Cross-domain Identity Management: Protocol · https://datatracker.ietf.org/doc/html/rfc7644（S级）
- draft-ansari-scim-soft-delete-00 · https://datatracker.ietf.org/doc/html/draft-ansari-scim-soft-delete-00（A级）
- draft-schreiber-scim-ipsie-profile-00 - SCIM 2.0 IPSIE Profile · https://datatracker.ietf.org/doc/draft-schreiber-scim-ipsie-profile/（A级）