4. 身份与访问管理实战

在 Databricks 的多团队协作场景中，身份与访问管理（IAM）决定了“谁能以什么身份、对哪些对象、执行哪些操作”。如果一开始就采用逐人授权的方式，随着人员流动、项目更替和团队扩张，权限表会迅速膨胀，最终变成难以审计、难以回收、难以复现的运维负担。本节围绕三个核心对象——用户、组、服务主体——以及 account-level 与 workspace-level 两级身份同步机制，说明如何设计一套以组为中心的权限分配策略。

三类身份对象：用户、组、服务主体

Databricks 中的身份对象可以理解为访问控制的主体。用户（User）代表自然人，通常通过企业身份提供商（如 Azure Entra ID、Okta 等）以 SCIM 方式同步进来，携带邮箱、显示名等属性。组（Group）是权限分配的主要载体，成员可以是用户，也可以是其他组，从而形成嵌套结构。服务主体（Service Principal）代表非人类身份，用于自动化任务、CI/CD 流水线、外部系统集成等场景，它拥有独立的 application ID 和凭据，不依赖某个员工的账号生命周期。

这三者的关系决定了权限策略的稳定性：用户会离职、会转岗，服务主体会轮换密钥，但组作为抽象层可以保持稳定。因此一条基本原则是——权限授予组，成员加入组，而不是把权限直接授予个人。当人员变动时，只需调整组成员关系，无需触碰任何数据对象上的授权记录。

account-level 与 workspace-level 身份同步

Databricks 采用两级身份模型。Account（账户）层是身份的“源头”，集中管理用户、组、服务主体，并通过 SCIM 与企业 IdP 同步。Workspace（工作区）层是实际执行计算和访问数据的地方，它从账户层继承身份，也可以为特定工作区做局部配置。理解这两层的关系，是避免“同步了却看不到人”这类问题的关键。

典型同步流程是：企业 IdP 中维护用户和组 → 通过 SCIM Provisioning Connector 同步到 Databricks Account → Account 中的身份自动可用或被分配到各 Workspace。组在 Account 层创建后，可以在多个 Workspace 中复用，这正是跨团队协作的基础。需要注意的是，如果只在 Workspace 层手工添加用户，该用户不会出现在 Account 层，也无法被其他 Workspace 统一管理，长期看会形成“身份孤岛”。

设计基于组的权限分配策略

把权限授予组之后，还需要决定“组怎么划分、权限怎么映射”。实践中常见的做法是按职责划分组，而不是按项目临时建组。例如可以建立 data-eng、data-analyst、data-scientist、svc-automation 等职责组，再按数据域建立 domain-sales、domain-finance 等资源组。权限授予时，把职责组与资源组做交叉映射，例如 data-analyst 对 domain-sales 拥有 SELECT，data-eng 对 domain-sales 拥有 MODIFY。

在 Unity Catalog 中，权限对象分为三层：Catalog、Schema、Table/View。授权语句可以直接作用于组，例如：

-- 授予分析组对销售域的只读权限
GRANT USE CATALOG ON CATALOG prod TO `data-analyst`;
GRANT USE SCHEMA ON SCHEMA prod.sales TO `data-analyst`;
GRANT SELECT ON SCHEMA prod.sales TO `data-analyst`;

-- 授予工程组对销售域的读写权限
GRANT USE CATALOG ON CATALOG prod TO `data-eng`;
GRANT USE SCHEMA ON SCHEMA prod.sales TO `data-eng`;
GRANT MODIFY ON SCHEMA prod.sales TO `data-eng`;

-- 服务主体组用于自动化写入
GRANT USE CATALOG ON CATALOG prod TO `svc-automation`;
GRANT USE SCHEMA ON SCHEMA prod.sales TO `svc-automation`;
GRANT MODIFY ON SCHEMA prod.sales TO `svc-automation`;

注意这里授权对象是组名，而不是个人邮箱。当新员工加入分析团队时，只需在 IdP 中把他加入 data-analyst 组，SCIM 同步后他自动获得对应权限，无需在 Databricks 中做任何额外操作。员工转岗时，从原组移除、加入新组即可，权限随之自动调整。

服务主体的接入与权限隔离

服务主体常用于自动化场景，例如每晚运行的 ETL Job、CI/CD 中部署 Notebook 的流水线。服务主体不应复用某个员工的个人身份，否则该员工离职时自动化任务会中断。正确做法是在 Account 层创建服务主体，把它加入专门的 svc-automation 组，再为该组授予最小必要权限。服务主体的凭据（如 OAuth secret 或证书）应存放在密钥管理服务中，并设置轮换周期。

服务主体与用户组的权限应尽量隔离。例如 svc-automation 只需要对特定 Schema 的 MODIFY 权限，不应拥有 CREATE CATALOG 或 MANAGE 等管理权限。这样即使凭据泄露，影响范围也被限制在最小集合内。

避免逐人授权的运维负担

逐人授权的代价不仅在于初次配置，更在于后续的审计与回收。当权限分散在几十个用户身上时，回答“谁有权访问这张表”需要逐条查询；当某人离职时，需要逐一撤销其所有授权，极易遗漏。基于组的模型把这个问题转化为“组有哪些权限、谁在组里”，审计时只需检查组的授权记录和组成员列表，回收时只需从组中移除成员。

为了保持模型清晰，建议遵循几条实践原则：第一，组名与职责或数据域对应，避免出现 temp-group-1 这类临时命名；第二，控制组的嵌套深度，一般不超过两层，否则权限继承链难以追踪；第三，定期审查组成员，尤其是拥有 MODIFY 或 MANAGE 权限的组；第四，服务主体单独成组，不与人类用户混用；第五，所有授权语句纳入版本控制，作为基础设施即代码的一部分。

一个可参考的组与权限映射示例

下表给出一个简化的映射关系，用于说明职责组、资源组与权限级别的对应方式。实际使用时可根据团队规模和数据敏感度调整。

当权限模型稳定后，日常运维就变成两件简单的事：在 IdP 中调整组成员，以及在代码仓库中审查授权语句的变更。身份与访问管理不再是每次新项目都要重新讨论的难题，而是一套可复用、可审计、可自动化的基础设施。