3. 身份与认证机制

在 Databricks 中，访问控制的第一道门是“你是谁”，第二道门才是“你能做什么”。身份与认证机制解决的是第一道门：把请求映射到一个可被审计、可被授权的主体（Principal）。Databricks 中的主体主要有三类：用户（User）、服务主体（Service Principal）和组（Group）。用户代表自然人，服务主体代表自动化程序、CI/CD 流水线或外部应用，组则是权限批量授予的载体。理解三者的差异与配合方式，是后续所有权限模型的基础。

三类主体的定位与差异

用户由身份提供方（IdP）或 Databricks 账户直接创建，拥有交互式登录能力，适合人通过浏览器或 CLI 操作工作区。服务主体没有交互式登录界面，它通过 OAuth 令牌或 PAT 以程序身份调用 API、运行作业、访问数据，是生产自动化的标准身份。组本身不“登录”，它是一组用户和服务主体的集合，权限授予组而非个人，可以显著降低权限维护成本，也避免人员离职后权限残留。

一个常见的误区是把个人 PAT 用于生产作业。个人 PAT 绑定在某个用户身上，一旦该用户离职或被禁用，作业立即失败，且审计日志中所有操作都记在该用户名下，无法区分“人”与“程序”。正确做法是：生产作业一律使用服务主体，个人 PAT 仅用于本地开发和临时调试。

SSO、OAuth、PAT 与密钥的适用场景

Databricks 支持多种认证方式，它们并非互相替代，而是面向不同场景：

• SSO（单点登录）：基于 SAML 或 OIDC，用户通过企业 IdP 登录工作区，实现统一身份、集中禁用和 MFA。这是人类用户访问工作区的推荐方式。
• OAuth：面向服务主体和外部应用的现代认证方式，支持 M2M（机器对机器）令牌和用户到机器（U2M）授权。OAuth 令牌有明确有效期，可自动轮换，是自动化场景的首选。
• PAT（个人访问令牌）：长期有效的静态令牌，配置简单但安全性较弱，适合本地开发、临时脚本，不建议用于生产。
• 服务主体密钥：包括 OAuth 客户端密钥（Client Secret）和用于生成 OAuth 令牌的凭据，是服务主体认证的核心材料，必须严格保管和轮换。

下图展示了从主体类型到认证方式再到访问目标的整体关系，帮助建立全局认知：

服务主体的创建与 OAuth 配置

在账户控制台中创建服务主体后，需要为其生成 OAuth 凭据。典型流程是：账户管理员在 Account Console 的“服务主体”页面新建 SP，记录其 Application ID；随后为该 SP 生成 OAuth Secret（客户端密钥）。这个 Secret 只在生成时显示一次，必须立即写入密钥管理服务（如 Azure Key Vault、AWS Secrets Manager 或 Databricks Secret Scope）。

使用 OAuth M2M 获取令牌的请求示例如下（参数为示例值）：

POST https://<workspace-url>/oidc/v1/token
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials
&client_id=<service-principal-application-id>
&client_secret=<oauth-secret>
&scope=all-apis

返回的 access_token 默认有效期约 1 小时，过期后需重新获取。因此生产代码不应缓存令牌超过其有效期，而应使用 Databricks SDK 或官方客户端库自动处理刷新。若使用 databricks-cli，可通过 profile 配置 client_id 与 client_secret，CLI 会自动完成令牌交换。

PAT 的配置与风险控制

PAT 通过工作区“用户设置 → 开发者 → 访问令牌”生成，可设置有效期（建议不超过 90 天）。PAT 以明文形式仅在生成时展示一次，之后无法再次查看。使用 PAT 时，请求头为 Authorization: Bearer <token>。由于 PAT 是静态长期凭据，一旦泄露，攻击者可在有效期内持续访问，因此必须遵循最小权限原则：为 PAT 所属用户或 SP 仅授予必要的工作区权限，并定期审计令牌列表，及时撤销不再使用的令牌。

组的管理与权限继承

组是权限治理的枢纽。Databricks 支持账户级组和工作区级组，推荐在账户级创建组并同步到工作区。组可以嵌套，子组自动继承父组权限。典型实践是建立“角色组”，例如 data-engineers、data-analysts、ml-team，再将具体用户和服务主体加入对应组。授予 Unity Catalog 权限时，直接对组授予 USE CATALOG、SELECT、MODIFY 等权限，而不是对个人授予。

需要特别注意的是，服务主体也应加入组，而不是单独授予权限。这样当自动化项目增多时，权限模型仍然清晰：新增一个 SP，只需将其加入已有角色组，即可获得该组全部权限，无需逐项配置。

凭据轮换与审计

无论使用 OAuth 还是 PAT，都应建立轮换机制。OAuth Secret 建议每 90 天轮换一次，PAT 建议每 60～90 天轮换。轮换时先在密钥管理服务中更新新凭据，再更新 Databricks 中的配置，最后撤销旧凭据，避免服务中断。审计方面，应定期检查账户审计日志中的 tokenLogin、generateToken、revokeToken 等事件，确认没有异常来源或未授权令牌。对于服务主体，还应监控其 API 调用频率和访问的数据范围，及时发现权限过大或凭据泄露的迹象。

总结来看，Databricks 的身份与认证体系围绕“主体—凭据—权限”三层展开。用户、服务主体和组定义了“谁”，SSO、OAuth、PAT 和密钥定义了“如何证明身份”，而组和 Unity Catalog 权限定义了“能做什么”。把生产自动化交给服务主体与 OAuth，把人类访问交给 SSO，把权限授予组，把凭据交给密钥管理服务并定期轮换，就能在保证可用性的同时，把身份相关的安全风险控制在可接受范围内。