Microsoft Dataverse中基于所有权的安全性

Dataverse 为许多业务方案提供了灵活的安全模型。 该模型仅适用于具有 Dataverse 数据库的环境。 作为管理员，你可以管理用户、验证其安全配置以及排查访问问题。

小费

观看Microsoft Dataverse - 演示中显示的安全概念。

基于角色的安全性

Dataverse 使用 安全角色 对权限进行分组。 将安全角色直接分配给用户或 Dataverse 团队。 团队成员将收到分配给团队的权限。

安全特权是累积的。 用户获得其所有角色和团队成员身份授予的最广泛访问权限。 例如，如果一个角色授予组织级对所有联系人记录的读取访问权限，则另一个角色无法隐藏用户的特定联系人。

业务部门

观看此视频，了解 Dataverse 中的业务单元：

业务部门使用安全角色来确定用户的访问权限。 它们定义了有助于管理用户和数据的安全边界。 每个 Dataverse 数据库都有一个根业务部门。

创建子业务部门 ，将用户和数据划分为较小的安全边界。 环境中的每个用户都属于业务部门。 业务单元结构可以与组织层级结构一致，但并非一定要这样。

以下示例使用三个业务部门。 Woodgrove 是根业务部门，仍位于层次结构的顶部。 部门 A 和 B 是子业务部门。 每个部门的用户都有不同的访问需求。

分层数据访问结构

使用分层结构分隔类似树的层次结构中的用户和数据。

将每个用户分配到一个业务部门，并为该用户分配该业务部门中的安全角色。 默认情况下，用户的业务部门拥有用户创建的记录。 安全角色确定用户可以在该业务部门中访问哪些记录。

在此示例中，用户 A 属于分区 A，并且具有部门 A 的安全角色 Y。用户 A 可以访问联系人 #1 和联系人 #2。 用户 B 属于分区 B，因此用户 B 无法访问部门 A 的联系人，但可以访问联系人 #3。

矩阵数据访问结构（现代化业务部门）

使用矩阵结构在类似树的层次结构中组织数据，同时允许用户访问多个业务部门中的数据，而不考虑他们所属的业务单位。

对于用户需要访问其数据的每个业务部门，都要为该用户分配一个安全角色。 当用户创建记录时，他们可以选择拥有该记录的业务部门。

在此示例中，用户 A 可以属于任何业务部门，包括根业务部门。 部门 A 中的安全角色 Y 授予用户 A 对联系人 #1 和联系人 #2 的访问权限。 B 部门中的安全角色 Y 授予用户 A 对联系人 #3 的访问权限。

启用矩阵数据访问结构

备注

启用此功能之前，请发布所有自定义项，以便该功能适用于新表。 如果在启用该功能后未发布的表无法正常工作，请使用用于 Microsoft Dynamics CRM 的 OrgDBOrgSettings tool 将 RecomputeOwnershipAcrossBusinessUnits 设置为 true。 此设置允许设置和更新 “拥有业务单位 ”列。

1. 以Dynamics 365管理员或Microsoft Power Platform管理员身份登录到 Power Platform 管理中心。
2. 在导航窗格中，选择管理。
3. 在“ 管理 ”窗格中，选择“ 环境”，然后选择环境。
4. 选择设置>产品>功能。
5. 启用跨业务部门的记录所有权。
6. 选择保存。

启用该功能后，在 向用户分配安全角色时选择一个业务部门。 使用此选项可将不同业务部门的角色分配给用户。 若要运行模型驱动应用，用户还需要自己的业务部门的角色，其中包括所需的 用户设置权限。 基本用户角色用于显示应启用哪些用户设置权限。

如果该用户的某个安全角色对该记录所在表授予了 读取 权限，则可以将该用户设为任意业务部门中的该记录所有者。 用户不需要具有来自拥有该记录的业务部门的安全角色。 有关详细信息，请参阅 现代化业务部门中的记录所有权。

备注

EnableOwnershipAcrossBusinessUnits 设置存储此功能的状态。 还可以使用适用于 Microsoft Dynamics CRM 的 OrgDBOrgSettings 工具更改设置。

将业务部门与 Microsoft Entra 安全组关联

将业务部门映射到Microsoft Entra安全组，以简化用户管理和角色分配。

对于每个业务部门：

1. 创建 Microsoft Entra 安全组。
2. 为安全组创建 Dataverse 组团队 。
3. 将业务部门的安全角色分配给 Dataverse 组团队。
4. 将用户添加到Microsoft Entra安全组。

当用户首次访问环境时，Dataverse 会在根业务部门中创建用户。 用户和 Dataverse 组团队可以继续保留在根业务单元中。 分配的安全角色授予对相应业务部门中的数据的访问权限。

对于矩阵数据访问，请将用户添加到他们需要访问的每个业务部门的Microsoft Entra安全组。

拥有业务部门

每个记录都有一个 “拥有业务单位 ”列，该列标识拥有该记录的业务部门。 当用户创建记录时，该列的默认值为用户的业务单元。 仅当 跨业务部门的记录所有权 处于打开状态时，才能更改该值。

备注

更改所属业务部门可能会导致连锁更改。 有关详细信息，请参阅使用适用于 .NET 的 SDK 配置级联行为。

若要让用户设置 “所属业务部门” 列，请向该用户的安全角色授予对“业务部门”表的本地级别 “追加到” 权限。

将列添加到：

• 表单正文或标题。
• 一个视图。
• 列映射。 如果使用 AutoMapEntity，请在映射中包含列。

备注

如果数据同步作业在其架构中包含 拥有业务部门 ，则当目标环境不包含相同值时，该作业将失败并出现外键约束冲突。 从源架构中删除该列，或将其源值更改为目标环境中存在的业务部门。

将数据复制到外部资源（如 Power BI）时，仅在目标支持该列时才包含 所属业务部门。

表和记录的所有权

Dataverse 支持两种记录所有权类型：

• 组织拥有的： 某项权限要么适用于所有记录，要么不适用。
• 用户或团队拥有： 大多数特权都支持用户、业务部门、父子业务部门和组织访问级别。

创建表时选择所有权类型，以后无法更改它。 例如，用户级对联系人表的 读取 访问权限允许用户仅读取他们拥有的联系人记录。

如果用户 A 属于部门 A，并且具有对联系人表的业务部门级 读取 访问权限，则用户 A 可以读取联系人 #1 和联系人 #2，但不能读取联系人 #3。

配置安全角色时，请为每个特权选择访问级别。

单独配置标准表特权：创建、读取、写入、删除、追加、追加、分配和共享。 权限图标显示授予的访问权限级别。

筛选表记录所有权（预览版）

预览功能不适合生产使用且功能可能受限。 这些功能在正式发布之前可供使用，以便客户可以抢先体验并提供反馈。

筛选后的记录所有权允许管理员使用列值筛选器控制对 Dataverse 记录的访问。 例如，仅向列等于 Redmond 的City记录授予访问权限。 用户可以创建、读取、更新和删除与安全角色中的筛选器匹配的记录。

与传统 Dataverse 表不同，具有筛选记录所有权的表不支持记录所有权、共享或分配。 基于筛选器的权限控制记录访问，并提供精细的行级访问，而无需限制表、列或其他模型对象。

备注

使用筛选的记录所有权授予对符合筛选条件的记录的行级访问权限。 对经过筛选的记录所有权表以及现有用户所有或组织所有的表应用基于筛选条件的权限。 对于现有表，此方法保留基础所有权模型。

在已现代化的业务单元中记录所有权信息

使用现代化业务部门，用户可以在任何业务部门中拥有记录。 用户需要一个来自任意业务单元的安全角色，该角色授予对该记录所在表的读取权限。 用户不需要在每个包含其所拥有记录的业务部门中都具有角色。

如果在预览期间在生产环境中启用了 跨业务部门的记录所有权 ：

1. 安装 组织设置编辑器。
2. 将 RecomputeOwnershipAcrossBusinessUnits 设置为 true. 系统在重新计算期间会锁住，最长可达五分钟。 重新计算后，用户可以跨业务部门拥有记录，而无需每个业务部门具有单独的安全角色。 记录所有者还可以将记录分配给记录所属业务部门之外的用户。
3. 将 AlwaysMoveRecordToOwnerBusinessUnit 设置为 false。 然后，当所有权发生更改时，记录将保留在其原始拥有业务部门中。

对于非生产环境，请将 AlwaysMoveRecordToOwnerBusinessUnit 设置为 false。

备注

如果关闭 跨业务部门的记录所有权 或将 RecomputeOwnershipAcrossBusinessUnits 设置为 false，则无法设置或更新 “拥有业务单位 ”列。 Dataverse 还会更改每个受影响记录的拥有业务部门，以匹配记录所有者的业务部门。

团队（包括组团队）

每个团队都属于一个业务部门。 Dataverse 会自动为每个业务部门创建一个默认团队并管理其成员身份。 默认团队始终包括业务部门中的所有用户。 无法手动添加或删除其成员。 将 用户与业务部门关联或取消关联时，Dataverse 会更新成员身份。

Dataverse 提供两种类型的团队：

• 所有者团队可以作为记录的所有者。 每个团队成员都可以直接访问团队的记录。 用户可以属于多个所有者团队。
• 访问团队 提供对共享记录的访问权限，但不拥有记录或具有安全角色。

记录共享

与用户或团队共享单个记录，以处理所有权和业务部门模型未涵盖的异常。 仅对异常使用共享，因为它的执行效率更低，并且比基于角色的访问更难进行故障排除。 与团队共享比与每个用户单独共享更有效。

使用访问团队模板自动创建访问团队，并为其定义记录的权限。 还可以在没有模板的情况下创建访问团队并手动管理其成员。 访问团队不拥有记录，并且不能具有安全角色。 团队成员会收到访问权限，因为记录与团队共享。

Dataverse 中的记录级安全

用户的记录访问权限结合了其所有安全角色、业务部门成员身份、团队成员身份和共享记录。 在 Dataverse 数据库中，访问权限会累积叠加。 Dataverse 可单独跟踪每个数据库的访问，并且用户必须具有适当的 Dataverse 许可证。

Dataverse 中的列级安全性

当记录级安全性不提供足够的控制时，请使用列级安全性。 为所有自定义列和大多数系统列启用它。 包含个人身份信息（PII）的大多数系统列都支持列级安全性。 系统列的元数据表明是否可以保护该列。

为每个列单独启用列级安全性。 然后创建一个列安全配置文件，该配置文件授予对受保护列 的“创建”、“ 更新”和 “读取 ”访问权限。 将配置文件分配给用户或团队。

列级安全性不授予对记录的访问权限。 只有当用户已具有记录访问权限时，列安全配置文件才能授予其对受保护列的访问权限。 仅在需要时使用列级安全性，因为过度使用可以减少性能。

管理跨多个环境的安全功能

使用 Dataverse 解决方案在环境之间迁移安全角色和列级安全配置文件。 在每个环境中单独创建和管理业务部门和团队。 还必须将用户分配到每个环境中的相应安全组件。

配置用户安全性

创建角色、团队和业务部门后，配置每个用户的访问权限：

1. 将用户与业务部门相关联。 Dataverse 默认使用根业务部门，并将用户添加到该业务部门的默认团队。
2. 分配用户所需的安全角色。
3. 将用户添加到相应的团队。
4. 如果使用列级安全性，请将列安全配置文件分配给该用户或其所属的某个团队。

用户的有效访问权限将直接分配的安全角色与通过团队分配的角色相结合。 Dataverse 始终向这些角色授予最广泛的权限。 有关详细说明，请参阅 配置环境安全。

在部署更改之前，请与管理用户权限的应用创建者和管理员协调重大安全更改。

另请参阅

• Microsoft Dataverse中基于筛选器的安全性
• 配置环境安全性
• 安全角色和特权