Important
此功能目前以公共预览版提供。
独占访问是一种模式，它使数据访问变为 显式启用，而不是默认提供的。 使用常规 Unity 目录权限时，权限遵循用户：用户随着时间的推移累积权限，并随处携带权限，因此其访问权限是他们直接授予的权限之和，以及他们从他们所属的所有组继承的权限的总和。 专属访问模式使客户能够将对敏感数据的访问设计为需要经过明确的主动操作才能获得——用户必须主动切换到某个角色才能访问这些数据，而不是默认持续拥有访问权限。 这可以防止他们以自己的身份访问数据，并跨用例、临床试验、项目或客户端混合数据。
为了帮助描述此模式，我们对涉及的不同标识使用两个术语。 这些是解释性标签，不是正式Azure Databricks术语：
- 访问角色：一个没有成员但拥有对敏感数据权限的组。 用户承担此角色来访问数据。 访问角色必须为空：访问角色的任何成员都会直接继承其权限，并且无需切换到该角色即可访问敏感数据，这就破坏了独占访问。 在Azure Databricks中，访问角色作为组实现。
- 成员组：其成员是允许用户承担访问角色的组。 向成员组授予访问角色的“Assume”权限后，该组的所有成员都可以承担该角色。 成员组是一种方便，而不是一项要求，还可以直接向单个用户或服务主体授予“假设”。 它可以让你省去管理 Assume 授权一次只能授予一个主体这一限制的麻烦。
配置完成后，用户可以通过任一受支持的方法切换到该访问角色：角色切换器、分配给组的专用访问模式集群、CLI、API 或第三方 BI 工具。 请参阅 “切换角色”。
Azure Databricks支持创建访问角色的两种方法。 选择最符合贵组织身份管理方式的一项：
- 帐户本地访问角色：创建Azure Databricks帐户本地组作为访问角色。 在Azure Databricks中创建组比创建新的Microsoft Entra ID组更简单（例如，当Microsoft Entra ID更改需要 IT 票证或内部评审时）。
- 从 Microsoft Entra ID 同步的访问角色：使用空的 Microsoft Entra ID 组作为访问角色，并通过 SCIM 同步到 Azure Databricks。 如果你已在 Microsoft Entra ID 中管理组，并且希望将所有组生命周期管理都保留在其中，这种方式最适合。
要求
- 启用 Unity Catalog 的工作区。
- 帐户管理员或工作区管理员权限，用于创建组并授予“假设”。
方法 1：帐户本地访问角色
在此方法中，访问角色对应于一个 Azure Databricks 账户本地组，该组完全在 Azure Databricks 内部进行管理。 成员组可以是任何有权承担该访问角色的组：通常是从 Microsoft Entra ID 同步而来的组，其中包含获准访问敏感数据的用户。
步骤 1：创建访问角色并将其分配给工作区
创建一个帐户级组，其中没有要充当访问角色的成员。 Databricks 建议使用一致的命名前缀（例如 role-），将访问角色与常规组区分开来。 例如，如果允许的用户的成员组是 clinical-trial-1-ds，则可以将访问角色 role-clinical-trial-1-ds命名。
创建访问角色：
帐户控制台
- 作为帐户管理员，登录到帐户控制台。
- 在边栏中，单击“用户管理”。
- 在“组”选项卡上，单击“添加组”。
- 输入访问角色的名称。 不要添加成员。
- 单击“确认”。
帐户组 API
databricks api post /api/2.0/account/scim/v2/Groups --json '{
"displayName": "<access-role-name>"
}'
创建访问角色后，将其分配给应可用的工作区。 请查看 分配一个组到工作区。
步骤 2：授予对数据和工作区资产的访问权限
使用标准Azure Databricks工具授予对敏感数据和工作区资产的访问权限：
-
Unity 目录安全对象：使用
GRANT语句或目录资源管理器向访问角色授予 UC 权限。 - 工作区资产：使用访问控制列表（ACL）授予对笔记本、作业、SQL 仓库和其他工作区对象的访问权限。
例如，若要授予访问角色读取 Unity Catalog 表的权限：
GRANT USE SCHEMA ON <catalog>.<schema> TO `<access-role-name>`;
GRANT SELECT ON TABLE <catalog>.<schema>.<table> TO `<access-role-name>`;
步骤 3：授予“Assume”权限
向用户、服务主体或应该能够承担此角色的成员组授予 “假定 ”权限。 请参阅 对组的管理权限。
步骤 4：用户承担角色
对访问角色具有“假设”权限的用户可以承担该角色。 有关可用方法，请参阅 “切换角色 ”。
方法 2：从Microsoft Entra ID同步的访问角色
使用此方法管理Microsoft Entra ID中的访问角色，并使用 SCIM 将其同步到Azure Databricks，而不是创建单独的Azure Databricks托管访问角色。 访问角色和成员组都源自Microsoft Entra ID。
在此方法中：
- 访问角色组是一个空的 Microsoft Entra ID 组，已同步到 Azure Databricks，并被授予对敏感数据的访问权限。
- 成员组是一个现有的 Microsoft Entra ID 组，其成员是可担任该访问角色的用户。 在访问角色上向成员组授予 Assume 权限，因此其所有成员都会自动继承 Assume 权限。
注释
访问角色必须在Microsoft Entra ID中保持为空。 添加到Microsoft Entra ID访问角色的成员将同步到Azure Databricks并直接继承角色的权限，这意味着他们可以访问敏感数据，而无需承担该角色。 这会中断独占访问模型。
步骤 1：在 Microsoft Entra ID 中设置组
如何设置组取决于是要启动全新组还是重新利用已在Azure Databricks中具有权限的现有Microsoft Entra ID组。
全新设置
在您的身份提供商中：
- 创建一个空组以充当访问角色。 例如：
role-clinical-trial-1-ds。 - 标识或创建其成员应能够承担访问角色的成员组。 例如：
clinical-trial-1-ds。
重新调整现有用途
如果您已经有一个从 Microsoft Entra ID 同步的组，并且其成员已被授予对 Azure Databricks 中敏感数据的访问权限，请使用此变体。 将现有组重新调整为访问角色可避免重新授予对新组的所有权限。
在您的身份提供商中：
- 创建新的Microsoft Entra ID组以充当成员组。 例如，如果现有组为
clinical-trial-1-ds，请创建clinical-trial-1-ds-members。 - 将现有Microsoft Entra ID组的所有成员移动到新的成员组中。
- 现有的 Microsoft Entra ID 组现在在 Microsoft Entra ID 中已为空组，并成为访问角色。 由于它保留其现有Azure Databricks权限，因此可以跳过下面的步骤 3。
步骤 2：将这两个组分配到工作区
将访问角色和成员组分配到应可用的工作区。 请查看 分配一个组到工作区。
步骤 3：授予对数据和工作区资产的访问权限
注释
如果在步骤 1 中重新调整了现有Microsoft Entra ID组，则访问角色已具有其Azure Databricks权限，可以跳过此步骤。
按照方法 1 中的步骤 2，相同步骤为 访问角色 授予对敏感数据和工作区资产的权限。
步骤 4：向成员组授予 Assume 权限
向 成员组 授予对 访问角色的“假定”权限。 该成员组中的所有成员都会自动继承 Assume。 请参阅 对组的管理权限。
步骤 5：用户承担角色
成员组中的成员可以承担该访问角色。 有关可用方法，请参阅 “切换角色 ”。
后续步骤
- 管理假设权限：使用 UI 或 API 授予或撤销对访问角色的“假设”。 请参阅 对组的管理权限。
- 假设角色：使用角色切换器、专用访问模式群集、CLI、API 或第三方 BI 工具。 请参阅 “切换角色”。
- 限制工作区资产共享：阻止假定具有访问权限角色的用户共享角色拥有的工作区资产。 请参阅 工作区资产共享控件。
- 查看限制事项：了解承担角色时哪些 Azure Databricks 功能不受支持，以及其他限制，例如工作区 SCIM API 在组管理方面的不足。 请参阅 基于角色的访问控制（RBAC）限制。