Microsoft Dataverse中的安全概念

语言 Chinese, Simplified

SEO Title

Security concepts in Microsoft Dataverse

基于角色的安全性

Dataverse使用基于角色的安全性将特权集合分组在一起。这些安全角色可以直接与用户关联，也可以与Dataverse团队和业务单元关联。然后，用户可以与团队关联，因此与团队关联的所有用户都将从该角色中受益。需要理解的Dataverse安全性的一个关键概念是，所有权限授予都是以最大的访问量累积的。如果您允许广泛的组织级读取访问所有联系人记录，则无法返回并隐藏单个记录。

业务部门

提示

视频符号查看以下视频：Modernize business units.

业务单元使用安全角色来确定用户具有的有效安全性。业务单元是一个安全建模构建块，有助于管理用户及其可以访问的数据。业务单元定义了一个安全边界。每个Dataverse数据库都有一个根业务单元。

您可以创建子业务单元，以帮助进一步细分用户和数据。分配给环境的每个用户都将属于一个业务单元。虽然业务单元可以用于1:1建模一个真正的组织层次结构，但它们通常更倾向于仅定义的安全边界，以帮助实现安全模型的需求。

为了更好地理解，让我们看看下面的例子。我们有三个业务部门。Woodgrove是根业务部门，并将永远处于顶端，这是不可改变的。我们创建了另外两个子业务单元A和B。这些业务单元中的用户有非常不同的访问需求。当我们将用户与此环境关联时，我们可以将用户设置为这三个业务单元中的一个。用户的关联位置将确定哪个业务单元拥有该用户所属的记录。有了这个关联，我们就可以定制一个安全角色，允许用户查看该业务单元中的所有记录。

分层数据访问结构

客户可以使用一种组织结构，其中数据和用户被划分为树状层次结构。

当我们将用户与此环境关联时，我们可以将用户设置为这三个业务单元中的一个，并将业务单元的安全角色分配给用户。当用户创建记录时，与用户关联的业务单元确定哪个业务单元拥有这些记录。通过具有该关联，我们可以定制一个安全角色，允许用户查看该业务单元中的记录。

用户A与部门A相关联，并从部门A分配了一个安全角色Y。这允许用户A访问联系人#1和联系人#2记录。而部门B中的用户B不能访问部门A的联系人记录，但可以访问联系人#3记录。

矩阵数据访问结构示例

矩阵数据访问结构（现代化的业务单元）
客户可以使用一种组织结构，其中数据以树状层次结构划分，用户可以工作和访问任何业务部门的数据，而不管用户被分配到哪个业务部门。

当我们将用户与此环境关联时，我们可以将用户设置为这三个业务单元中的一个。对于用户需要访问数据的每个业务单元，都会将该业务单元的安全角色分配给用户。当用户创建记录时，用户可以将业务部门设置为拥有该记录。

用户A可以与任何业务单元相关联，包括根业务单元。将来自部门A的安全角色Y分配给用户A，该角色允许用户访问联系人#1和联系人#2记录。来自部门B的安全角色Y被分配给用户A，这允许用户访问联系人#3记录。

分层数据访问结构示例

启用矩阵数据访问结构

笔记

启用此功能之前，必须发布所有自定义项，以便为该功能启用所有新的未发布表。如果打开此功能后发现有未发布的表无法使用此功能，则可以使用Microsoft Dynamics CRM的OrgDBOrgSettings工具设置RecomputerOwnershipAcrossBusinessUnits设置。将RecomputerownershipAcrossBusiness Units设置为true可以设置和更新“拥有的业务单元”字段。

登录到 Power Platform管理中心作为管理员（Dynamics 365管理员、全局管理员或Microsoft Power Platform管理员）。
选择“环境”，然后选择要启用此功能的环境。
选择“设置”>“产品”>“功能”。
打开“跨业务单元记录所有权”开关。

打开此功能开关后，您可以在为用户分配安全角色时选择“业务部门”。这允许您将不同业务部门的安全角色分配给用户。用户还需要业务部门的安全角色，该业务部门为用户分配了运行模型驱动应用程序的用户设置权限。您可以参考基本用户安全角色来了解如何启用这些用户设置权限。

只要用户具有对记录表具有读取权限的安全角色，就可以将用户分配为任何业务单元中的记录所有者，而无需在记录所属业务单元中分配安全角色。参见现代化业务单元中的记录所有权。

笔记

此功能开关存储在EnableOwnershipAcrossBusinessUnits设置中，可以使用Microsoft Dynamics CRM的OrgDBOrgSettings工具进行设置。

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

您可以使用Microsoft Entra安全组来映射您的业务部门，以简化用户管理和角色分配。

为每个业务单元创建一个Microsoft Entra安全组，并将相应的业务单元安全角色分配给每个组团队。

为每个业务部门创建一个Microsoft Entra安全组。

为每个业务单元创建一个Microsoft Entra安全组。为每个Microsoft Entra安全组创建一个Dataverse组团队。将业务部门的相应安全角色分配给每个Dataverse组团队。当用户访问环境时，上图中的用户将在根业务单元中创建。让用户和Dataverse组团队在根业务单元中是很好的。他们只能访问分配了安全角色的业务单元中的数据。

将用户添加到相应的Microsoft Entra安全组中，以授予他们访问业务部门的权限。用户可以立即运行应用程序并访问其资源/数据。

在矩阵数据访问中，用户可以从多个业务部门工作和访问数据，将用户添加到映射到这些业务部门的Microsoft Entra安全组中。

拥有的业务单元

每条记录都有一个“拥有的业务单元”列，用于确定哪个业务单元拥有该记录。创建记录时，此列默认为用户的业务部门，除非打开功能开关，否则无法更改。

笔记

当您更改哪个业务单元拥有一条记录时，请确保检查以下级联效果：使用的SDK。NET来配置级联行为。

当功能开关打开时，您可以管理是否允许用户设置“拥有的业务单元”列。若要设置“拥有业务单元”栏，您需要向用户的安全角色授予具有本地级别权限的“业务单元”表的“附加到”权限。

若要允许用户设置此列，可以在以下位置启用此列：

表单-正文和页眉。
视图
列映射。如果使用的是AutoMapEntity，则可以在列映射中指定列。

笔记

如果您有一个作业/流程在环境之间同步数据，并且“拥有的业务单元”作为架构的一部分包含在内，那么如果目标环境没有相同的“拥有的事业单元”值，则您的作业将失败，并违反外键约束。

您可以从源架构中删除Owning Business Unit列，也可以将source的Owning BusinessUnit列值更新为目标的任何业务单元。

如果您有将数据从环境复制到外部资源（例如PowerBI）的作业/流程，则需要从源中选择或取消选择Owning Business Unit列。如果您的资源可以接收，请选择它，否则请取消选择它。

表/记录所有权

Dataverse支持两种类型的记录所有权。组织所有，用户或团队所有。这是在创建表时发生的选择，不能更改。出于安全目的，对于组织所有的记录，唯一的访问级别选择是用户可以执行操作或不能执行操作。对于用户和团队所有的记录，大多数权限的访问级别选择是分层的组织、业务单元、业务单元和子业务单元，或者只选择用户自己的记录。这意味着对于联系人的读取权限，我可以设置用户所有，并且用户只能看到自己的记录。

举另一个例子，假设用户A与部门A相关联，我们在Contact上为他们提供业务单元级别的Read访问权限。他们可以看到联系人#1和#2，但不能看到联系人#3。

当您配置或编辑安全角色权限时，您正在为每个选项设置访问级别。以下是安全角色权限编辑器的示例。

在上面，您可以看到每个表的标准权限类型创建、读取、写入、删除、附加、附加到、分配和共享。您可以单独编辑其中的每一个。每个的视觉显示将与下面的键相匹配，以确定您授予的访问级别。

安全角色特权密钥。

在上面的示例中，我们为组织级别的联系人提供了访问权限，这意味着A部门的用户可以查看和更新任何人拥有的联系人。事实上，最常见的管理错误之一是对权限感到沮丧，并只是过度授予访问权限。很快，一个精心制作的安全模型就开始看起来像瑞士奶酪（到处都是洞！）。

现代化企业单位的记录所有权

在现代化的业务单元中，您可以让用户成为任何业务单元的记录所有者。用户所需要的只是一个对记录表具有读取权限的安全角色（任何业务单元）。用户不需要在记录所在的每个业务单元中分配安全角色。

如果在预览期间在生产环境中启用了跨业务部门的记录所有权，则需要执行以下操作才能启用跨业务部门记录所有权：

安装组织设置编辑器
将RecomputerownershipAcrossBusinessUnits组织设置设置为true。当此设置设置为true时，系统将被锁定，并且可能需要长达5分钟的时间来进行重新计算，以启用用户现在可以跨业务单元拥有记录的功能，而无需从每个业务单元分配单独的安全角色。这允许记录的所有者将他们的记录分配给记录所属业务部门之外的人。
将AlwaysMoveRecordToOwnerBusinessUnit设置为false。这样，当记录所有权发生变化时，记录将保留在原始拥有的业务单元中。

对于所有非生产环境，只需将AlwaysMoveRecordToOwnerBusinessUnit设置为false即可使用此功能。

笔记

如果使用Microsoft Dynamics CRM的OrgDBOrgSettings工具关闭“跨业务部门记录所有权”功能或将RecomputerOwnershipAcrossBusinessUnits设置设置为false，则将无法设置或更新“拥有的业务部门”字段，并且“拥有的业务部门”字段与所有者的业务部门不同的所有记录都将更新为所有者的业务单位。

团队（包括小组团队）

团队是另一个重要的安全构建块。团队归一个业务部门所有。每个业务单元都有一个默认团队，该团队在创建业务单元时自动创建。默认团队成员由Dataverse管理，并且始终包含与该业务单元关联的所有用户。您不能手动添加或删除默认团队中的成员，当新用户与业务部门关联/解除关联时，系统会动态调整这些成员。有两种类型的团队，拥有团队和访问团队。

拥有团队可以拥有记录，这使任何团队成员都可以直接访问该记录。用户可以是多个团队的成员。这将使其成为一种强大的方式，以广泛的方式向用户授予权限，而无需在单个用户级别对访问进行微观管理。
访问团队将在下一节中作为记录共享的一部分进行讨论。

记录共享

单个记录可以在逐个的基础上与另一个用户共享。这是一种处理不属于记录所有权或属于业务单元访问模型成员的异常的强大方法。不过，这应该是一个例外，因为这是一种性能较差的访问控制方式。共享更难排除故障，因为它不是一种一致实现的访问控制。共享可以在用户和团队级别进行。与团队共享是一种更有效的共享方式。更高级的共享概念是与Access Teams共享，它提供了团队的自动创建，并基于应用的Access team模板（权限模板）与团队共享记录访问权限。访问团队也可以在没有模板的情况下使用，只需手动添加或删除其成员。访问团队的绩效更高，因为他们不允许团队拥有记录或将安全角色分配给团队。用户可以访问，因为记录是与团队共享的，并且用户是团队成员。

Dataverse中的记录级安全性

您可能想知道，是什么决定了对记录的访问权限？这听起来像是一个简单的问题，但对于任何给定的用户来说，这都是他们所有安全角色、与他们相关的业务部门、他们所属的团队以及与他们共享的记录的组合。需要记住的关键是，所有访问都是在Dataverse数据库环境范围内的所有这些概念中累积的。这些权利仅在单个数据库中授予，并在每个Dataverse数据库中单独跟踪。这一切都要求他们拥有访问Dataverse的适当许可证。

Dataverse中的列级安全性

有时，记录级别的访问控制对于某些业务场景来说是不够的。Dataverse具有列级安全功能，可以在列级对安全性进行更精细的控制。可以在所有自定义列和大多数系统列上启用列级安全性。包括个人可识别信息（PII）的大多数系统列都能够被单独保护。每列的元数据都定义了这是否是系统列的可用选项。

列级安全性是逐列启用的。然后通过创建列安全配置文件来管理访问。配置文件包含启用了列级安全性的所有列以及该特定配置文件授予的访问权限。每个列都可以在配置文件中进行控制，以便进行“创建”、“更新”和“读取”访问。然后，列安全配置文件与一个或多个用户或团队相关联，以将这些特权授予用户对他们已经有权访问的记录的访问权限。需要注意的是，列级安全性与记录级安全性无关。用户必须已经有权访问列安全配置文件的记录，才能授予他们对列的任何访问权限。列级安全性应根据需要使用，而不是过度使用，因为如果过度使用，会增加有害的开销。

跨多个环境管理安全性

可以使用Dataverse解决方案将安全角色和列安全配置文件打包并从一个环境移动到另一个环境。必须在每个环境中创建和管理业务单元和团队，同时将用户分配给必要的安全组件。

配置用户环境安全

一旦在环境中创建了角色、团队和业务单元，就可以为用户分配他们的安全配置了。首先，当您创建一个用户时，您将该用户与一个业务单元相关联。默认情况下，这是组织中的根业务单元。他们也被添加到该业务部门的默认团队中。

此外，您还可以分配用户需要的任何安全角色。您也可以将他们添加为任何团队的成员。请记住，团队也可以具有安全角色，因此用户的有效权限是直接分配的安全角色与他们所属的任何团队的安全角色的组合。安全性始终是附加性的，提供了他们任何权利中限制性最小的许可。以下是配置环境安全性的良好演练。

如果您使用了列级安全性，则需要将用户或用户团队与您创建的某个列安全性配置文件相关联。

安全性是一篇复杂的文章，最好由应用程序制造商和管理用户权限的团队共同努力来实现。任何重大更改都应在将更改部署到环境中之前进行协调。

另请参阅

本文地址

https://architect.pub

登录发表评论
11 次浏览

发布日期

星期五, 五月 3, 2024 - 11:17

最后修改