Microsoft Dataverse 中的安全概念
Dataverse 的一项重要功能是其可适应大量业务使用方案的丰富安全模型。 本安全模型仅在环境中有 Dataverse 数据库时才起作用。 作为管理员，您不能自己生成整个安全模型，但通常会涉及管理用户并确保他们具有适当的配置和解决与安全访问相关的问题的流程。
小费
请观看以下视频： Microsoft Dataverse –演示中显示的安全概念。
基于角色的安全性
Dataverse 使用基于角色的安全性将一组权限组合在一起。 这些安全角色可能直接与用户关联，也可以与 Dataverse 团队和业务部门关联。 然后，用户可以与团队关联，因此与团队关联的所有用户都可以从该角色中受益。 需要了解的一个关键的 Dataverse 安全概念是，所有权限授予都是累积的，并且接受最大量的访问。 如果您获取了对所有联系人记录的广泛组织级别读取访问权限，则不能返回并隐藏单个记录。
业务部门
小费
请观看以下视频： 实现业务部门现代化。
业务部门使用安全角色确定用户拥有的有效安全性。 业务部门是可帮助管理用户和用户可访问的数据的安全建模构建基块。 业务部门定义安全边界。 每个 Dataverse 数据库都有一个根业务部门。
可以创建下级业务部门，以便帮助进一步细分用户和数据。 分配给环境的每个用户都属于一个业务部门。 因为业务部门可用于为真实的组织层次结构进行 1:1 的建模，所以通常更倾向于仅定义安全边界来帮助满足安全模型需要。
为了加深理解，我们看看以下示例。 我们有三个业务部门。 Woodgrove 是根业务部门，始终在最上层，不可更改。 我们创建了另外两个子业务部门 A 和 B。这些业务部门中的用户具有不同的访问需求。 当我们将用户与此环境关联时，可将此用户设置为下面三个业务部门之一的成员。 用户关联位置决定了哪个业务部门负责该用户是其负责人的记录。 通过这一关联，我们可以定制一个安全角色来允许用户查看该业务部门中的所有记录。
分层数据访问结构
客户可以使用一种数据和用户被划分为树状层次结构的组织结构。
当我们将用户与此环境关联时，我们可以将用户设置为在这三个业务部门中的一个，并将该业务部门的安全角色分配给用户。 当用户创建记录时，用户所关联的业务部门确定哪个业务部门负责记录。 通过建立这种关联，我们可以定制一个安全角色，使用户能够查看该业务部门中的记录。
用户 A 与部门 A 关联，并被分配了部门 A 的安全角色 Y。这允许用户 A 访问联系人 #1 和联系人 #2 记录。 而 Division B 中的用户 B 无法访问 Division A 的联系人记录，但可以访问联系人 #3 记录。
矩阵数据访问结构（现代化业务部门）
客户可以使用一种数据以树状层次结构划分的组织结构，用户可以处理和访问任何业务部门的数据，而不管用户被分配到哪个业务部门。
当我们将用户与此环境关联时，可将此用户设置为下面三个业务部门之一的成员。 对于用户需要访问数据的每个业务部门，该业务部门的安全角色将被分配给该用户。 当用户创建记录时，用户可以将该业务部门设置为负责记录。
用户 A 可以与任何业务部门关联，包括根业务部门。 部门 A 的安全角色 Y 被分配给用户 A，该角色允许用户访问联系人 #1 和联系人 #2 记录。 部门 B 的安全角色 Y 被分配给用户 A，该角色允许用户访问联系人 #3 记录。
启用矩阵数据访问结构
备注
在启用此功能之前，您必须发布所有自定义项，以为此功能启用所有新的未发布表。 如果在启用此功能后发现有未发布的表无法使用此功能，可以使用 Microsoft Dynamics CRM 的 OrgDBOrgSettings 工具设置 RecomputeOwnershipAcrossBusinessUnits 设置。 如果将 RecomputeOwnershipAcrossBusinessUnits 设置为 true，则将允许设置和更新负责的业务部门字段。
- 以管理员（Dynamics 365 管理员或 Power Platform 管理员）身份登录到 管理中心 Microsoft Power Platform 。
- 选择环境，然后选择要为其启用此功能的环境。
- 选择设置>产品>功能。
- 打开切换跨业务部门的记录所有权。
打开此功能切换后，您可以在为用户分配安全角色时选择业务部门。 这允许您将不同业务部门的安全角色分配给用户。 用户还需要其被分配的业务部门中具有用户设置特权的安全角色才能运行模型驱动应用。 您可以参考基本用户安全角色来了解如何启用这些用户设置特权。
您可以将用户分配为任何业务部门的记录负责人，而无需在记录的负责业务部门中分配安全角色，只要用户具有对记录表具有读取权限的安全角色。 请参阅现代化业务部门中的记录所有权。
备注
此功能切换存储在 EnableOwnershipAcrossBusinessUnits 设置中，也可以使用 Microsoft Dynamics CRM 的 OrgDBOrgSettings 工具设置。
将业务部门与 Microsoft Entra 安全组关联
您可以使用 Microsoft Entra 安全组来映射您的业务部门，以简化您的用户管理和角色分配。
Microsoft Entra 为每个业务部门创建一个安全组，并将相应的业务部门安全角色分配给每个组团队。
为每个业务部门创建一个 Microsoft Entra 安全组。 为每个 Microsoft Entra 安全组创建一个 Dataverse 组团队。 将业务部门的相应安全角色分配给每个 Dataverse 组团队。 上图中的用户在用户访问环境时会在根业务部门中创建。 让用户和 Dataverse 组团队位于根业务部门是可以的。 他们只有权访问分配了安全角色的业务部门中的数据。
将用户添加到相应的 Microsoft Entra 安全组中，以授予他们访问业务部门的权限。 用户可以立即运行应用并访问其资源/数据。
在矩阵数据访问中，用户可以处理和访问来自多个业务部门的数据，将用户添加到映射到这些业务部门的 Microsoft Entra 安全组。
负责的业务部门
每条记录都有一个 Owning Business Unit （负责业务部门）列，该列确定哪个业务部门负责该记录。 此列默认为创建记录时用户的业务部门，除非打开功能开关，否则无法更改。
备注
当您更改负责记录的业务部门时，请务必检查以下情况下是否发生级联影响：使用 SDK for .NET 配置级联行为。
当功能切换打开时，您可以管理是否允许您的用户设置“负责业务部门”列。 要设置“负责业务部门”列，您需要向用户的安全角色授予业务部门表的追加到特权以及本地级别权限。
要允许您的用户设置此列，您可以在以下位置启用此列：
- 窗体 - 主体和标头。
- 视图。
- 列映射。 如果您使用的是 AutoMapEntity，则可以在列映射中指定列。
备注
如果您有在环境之间同步数据的作业/流程，并且负责业务部门作为架构的一部分包含，当目标环境没有相同的负责业务部门值时，您的作业将失败并发生外键约束违反错误。
您可以从源架构中删除负责业务部门列，或将源的负责业务部门列值更新为目标的任何业务部门。
如果您有将数据从环境复制到外部资源（例如，PowerBI）的作业/流程，您需要从源中选择或取消选择负责业务部门列。 如果您的资源可以接收它，则选择，否则取消选择。
表/记录所有权
Dataverse 支持两种类型的记录所有权。 负责的组织，以及负责的用户或团队。 这是一个在创建表时进行的选择，无法更改。 出于安全目的，记录为组织所有，唯一的访问级别选择是用户是否可以执行操作。 对于用户和团队拥有的记录，大多数特权的访问级别选择是分层组织、业务部门、业务部门和下级业务部门或仅用户自己的记录。 这意味着，对于联系人的读取权限，我可以设置用户负责的记录，而用户只能查看自己的记录。
再如，假设用户 A 与部门 A 关联，并且我们为其提供联系人的业务部门级读取访问权限。 他们能够查看联系人 #1 和 #2，但不能查看联系人 #3。
配置或编辑安全角色特权时，将为每个选项设置访问级别。 下面是安全角色权限编辑器的示例。
在上面，您可以查看每个表的标准特权类型：创建、读取、写入、删除、追加、追加到、分配和共享。 可以分别编辑这些类型中的每一项。 就您授予的访问级别而言，每一项的可视显示将与下面的密钥匹配。
在上面的示例中，提供了联系人的组织级访问权限，这意味着部门 A 中的用户可以查看和更新任何人负责的联系人。 实际上，最常见的一个管理错误是遇到了权限问题和权限授予过度。 精心制作的安全模型最开始看起来像瑞士奶酪（到处都是孔）。
现代化业务部门中的记录所有权
在现代化业务部门中，您可以将用户作为所有业务部门的记录负责人。 用户只需要有对记录表具有读取权限的安全角色（任何业务部门）。 用户不需要在记录所在的每个业务部门被分配安全角色。
如果在预览期间在生产环境中启用了跨业务部门的记录所有权，您需要执行以下操作来跨业务部门启用此记录所有权：
- 安装组织设置编辑器
- 将 RecomputeOwnershipAcrossBusinessUnits 组织设置设置为 true。 当此设置设为 true 时，系统会被锁定，最多可能需要 5 分钟时间进行重新计算，以使用户现在能够跨业务部门负责记录，而无需从每个业务部门分配单独的安全角色。 这样，记录负责人可以将记录分配给记录的负责业务部门之外的人员。
- 将 AlwaysMoveRecordToOwnerBusinessUnit 设置为 false。 当记录所有权发生更改时，这会让记录仍保留在原始负责业务部门。
对于所有非生产环境，只需将 AlwaysMoveRecordToOwnerBusinessUnit 设置为 false 即可使用此功能。
备注
如果您关闭跨业务部门的记录所有权功能，或使用 Microsoft Dynamics CRM 的 OrgDBOrgSettings 工具将 RecomputeOwnershipAcrossBusinessUnits 设置设为 false，则您将无法设置或更新负责的业务部门字段，并且负责的业务部门字段不同于负责人的业务部门的所有记录都将更新为负责人的业务部门。
团队（包括组团队）
团队也是重要的安全构建基块。 团队由业务部门负责。 每个业务部门有一个默认团队，这个默认团队是在创建该业务部门时自动创建的。 默认团队成员由 Dataverse 管理，始终包含与该业务部门关联的所有用户。 不能在默认团队中手动添加或删除成员，成员由系统动态调整，因为新用户会与业务部门关联/解除关联。 团队分两种，即负责团队和访问团队。
- 负责团队可以负责记录，向任何团队成员提供对该记录的直接访问权限。 用户可以是多个团队的成员。 因此非常适合在不 在单个用户级对访问权限进行微管理的情况下，广泛地为用户授予权限。
- 下一节中将作为记录共享的一部分讨论访问团队。
记录共享
单个记录可以一对一的方式与其他用户共享。 这非常适合处理不涉及记录所有权或业务部门访问模型成员的异常。 这应该是一种例外情况，因为它是一种效能较低的访问控制方式。 共享更难排除故障，因为它不是以一致方式实现的访问控制。 可以同时在用户级和团队级共享。 与团队共享是一种更高效的共享方式。 更高级的共享概念是使用访问团队，这样将自动创建团队并基于应用的访问团队模板（权限的模板）与团队共享记录访问权限。 也可以在没有模板的情况下使用访问团队，只需手动添加或删除其成员即可。 访问团队的性能更高，因为其不允许团队负责记录，也不允许为团队分配安全角色。 用户将获取访问权限，因为记录将与团队共享，而用户则为成员。
Dataverse 中的记录级安全
您可能会好奇，记录访问权限的决定因素是什么？ 这听起来像是一个简单的问题，但对于任何给定用户来说，这是他们所有安全角色、他们关联的业务部门、他们所属的团队以及与他们共享的记录的组合。 请务必注意，所有访问权限在 Dataverse 数据库环境作用范围内所有这些概念中累积。 这些权利仅在单个数据库内授予，并且在每个 Dataverse 数据库中单独跟踪。 这一切都需要它们具有适当的许可证才能访问 Dataverse。
Dataverse 中的列级安全性
有时，对于某些业务方案，记录级访问控制是不够的。 Dataverse 提供列级别安全功能，支持在列级别对安全功能进行更精细的控制。 可以为所有自定义列和大多数系统列启用列级安全性。 可以分别保护大多数包含个人身份信息 (PII) 的系统列。 每个列的元数据定义这是否是系统列的可用选项。
列级安全性按列启用。 然后通过创建列安全配置文件管理访问权限。 配置文件中包含已启用了列级安全性的所有列和这个具体配置文件授予的访问权限。 可以在配置文件内控制每个列的创建、更新和读取访问权限。 然后将列安全配置文件与用户或团队关联，以便为用户授予他们已经可访问的记录的这些权限。 请务必注意，列级安全性与记录级安全性没有任何关系。 用户必须已具有对列安全配置文件的记录的访问权限，才能向他们授予对列的任何访问权限。 列级安全性应该根据需要使用，不应过度使用，因为如果过度使用，可能会带来不利开销。
管理多个环境中的安全
可以打包安全角色和列安全配置文件，并使用 Dataverse 解决方案从一个环境移到下一个环境。 业务部门和团队必须在每个环境中创建和管理，并为必需的安全组件分配用户。
配置用户环境安全
在环境中创建角色、团队和业务部门后，此时可以向用户分派其安全配置。 首先，创建用户时，将该用户与业务部门相关联。 默认情况下，这是组织中的根业务部门。 他们也会添加到该业务部门的默认团队。
此外，还会分配用户所需任何安全角色。 您还会将其添加为任何团队的成员。 请记住，团队也可以具有安全角色，因此用户的有效权限是直接分派的安全角色与属于其成员的任何团队的组合。 安全性通常是锦上添花，它提供其任何权利的约束最少权限。 下面是很好的配置环境安全性演练。
如果您已使用列级安全性，则需要将用户或用户的团队关联到您创建的列安全配置文件之一。
安全性是一篇复杂的文章，最好通过应用程序创建者和管理用户权限的团队之间的共同努力来实现。 应该在将任何重大更改部署到环境中之前，简化这些更改。