如何在 Microsoft Dynamics 365 中使用基于角色的安全性控制对实体的访问权限

 

发布日期： 2017年1月

适用于： Dynamics 365 (online),Dynamics 365 (on-premises),Dynamics CRM 2016,Dynamics CRM Online

在 Microsoft Dynamics CRM 2015 和 Microsoft Dynamics 365 (online) 中，基于角色的安全性的基本概念是，角色包含定义了可以在组织内执行的操作集权限。 例如，为销售员角色分派的权限集与执行为该角色定义的任务相关。 必须为所有用户分派一个或多个预定义角色或自定义角色。 在 Microsoft Dynamics CRM 2015 中，角色还可以分派给团队。 将用户或团队分派给这些角色之一时，会为该用户或团队成员分派与该角色相关联的权限集。 必须将用户至少分派给一个角色。

“权限”授权用户对特定实体类型执行特定操作。 权限适用于整个对象类，而不是单个对象实例。 例如，如果用户不具有读取客户的权限，每次该用户尝试读取客户都将失败。 权限包含用于确定权限适用于组织内的级别的访问级别。 每个权限最多可以具有四个访问级别：基本、本地、深度和全局。

本主题内容

角色

权限

访问级别

把所有放在一起

预定义的安全角色列表

角色

Microsoft Dynamics 365 包含 14 个预定义角色，这些角色反映了常见用户角色，并且定义了访问级别以匹配安全最佳实践目标：提供对完成工作所需的最少量业务数据的访问。 通过这些角色，您无需定义自己的角色即可快速部署 Microsoft Dynamics 365 系统。 然而，您可以使用预定义的角色作为模板来创建自定义角色，也可以定义一组新角色。 有关列表，请参阅预定义的安全角色列表。

每个角色都与一组权限相关联，这些权限确定用户或团队可以对公司信息进行哪些访问。

您可以在 Microsoft Dynamics 365 中创建角色，以及修改或删除这些自定义角色以满足您的业务需求。 您为您所在业务部门创建的角色会由层次结构中的所有业务部门继承。

可以将一个或多个角色分派到用户或团队。 例如，用户可以同时具有“销售经理”角色和“客户服务代表”角色，在这种情况下，用户同时具有两种角色的权限。

不能在用户级别修改权限，但是可以使用所需的权限创建新角色。 例如，为 John 分派的角色为“销售员”，该角色要求 John 接受分派给他的所有潜在客户。 然而，管理员希望 John 能够重新分派为他分派的潜在客户。 因此管理员必须修改“销售员”角色，使其允许执行此操作；或者必须创建一个新角色，在其中包含此特定权限并将 John 添加到此角色。 建议创建新角色，除非您认为分派了“销售员”角色的所有用户现在都有必要具有此附加权限。

权限

在 Microsoft Dynamics 365 中，安装期间在系统范围内预定义了 580 多种权限。 权限就是可以在 Microsoft Dynamics 365 中执行操作的许可。 有些权限适用于通常实体类型，有些则适用于特定实体类型。 有关 Microsoft Dynamics 365 中可用权限的完整列表，请参阅Security role and privilege reference。

Microsoft Dynamics 365 使用权限作为基础安全检查的核心。 权限“内置”于产品中，并用于整个应用程序和平台层。 不能添加或删除权限，也不能更改使用权限来授权访问特定功能的方式，但是可以通过现有权限集构造新角色。

每个角色都定义一组权限，这些权限可确定用户或团队可以对公司信息进行哪些访问。 平台会检查权限，并在用户不具有所需权限时拒绝进行操作。 权限与深度或访问级别结合使用。

例如，“销售员”角色具有访问级别为 Read Account 的 Basic 权限和访问级别为 Write Account 的 Basic 权限，而“销售经理”角色可能具有访问级别为 Read Account 的 Local 权限和访问级别为 Assign Contact 的Local 权限。

大部分实体具有这样一组可能的权限，这组权限会添加到对应于可以对该实体时间的记录进行各种操作的角色。 有关详细信息，请参阅实体特权。

系统中的每个操作，以及 SDK 文档中介绍的每个消息，都要求执行一个或多个权限。 有关详细信息，请参阅Privileges by message。

访问级别

权限的访问级别或权限深度用于为给定实体类型确定用户可以在组织层次结构中的哪些层次上对该实体类型执行操作。

以下列表列出了 Microsoft Dynamics 365 中的访问级别，访问最广泛的首先列出。 Web 应用程序中的安全角色编辑器中显示了该图标。

	全局。 具有此访问级别的用户可以访问组织内的所有记录，无论实例或用户属于哪个业务部门层次级别。 具有“全局”访问级别的用户还将自动具有“深度”、“本地”和“基本”访问级别。 由于具有此访问级别的用户可以访问整个组织内的信息，因此应该限制此访问级别，以符合组织的数据安全计划。 此访问级别通常预留给管理整个组织的经理。 应用程序将此访问级别称为“组织”。
	深度。 具有此访问级别的用户可以访问其所在业务部门以及该业务部门的所有下属业务部门中的用户记录。 具有“深度”访问级别的用户还将自动具有“本地”和“基本”访问级别。 由于具有此访问级别的用户可以访问整个业务部门以及下属业务部门内的信息，因此应该限制此访问级别，以符合组织的数据安全计划。 此访问级别通常预留给管理多个业务部门的经理。 应用程序将此访问级别称为“父：子业务部门”。
	本地。 具有此访问级别的用户可以访问其所在业务部门内的用户记录。 具有“本地”访问级别的用户还将自动具有“基本”访问级别。 由于具有此访问级别的用户可以访问整个业务部门内的信息，因此应该限制此访问级别，以符合组织的数据安全计划。 此访问级别通常预留给管理一个业务部门的经理。 应用程序将此访问级别称为“业务部门”。
	基本。 具有此访问级别的用户可以访问其负责的用户记录、与该用户共享的对象以及与该用户所属团队共享的对象。 这是销售和服务代表的典型访问级别。 应用程序将此访问级别称为“用户”。
	无。 禁止访问。

把所有放在一起

• 如果用户具有 Deep Read Account 权限，则该用户可以读取其所在业务部门中的所有客户，以及该业务部门的所有下级业务部门中的所有客户。

• 如有用户具有 Local Read Account 权限，则该用户可以读取本地业务部门中的所有客户。

• 如果为用户分派了 Basic Read Account 权限，则该用户只能读取其负责的客户或与其共享的客户。

• 具有 Basic Read Account 权限的客户服务代表可以查看其负责的客户以及其他用户与该用户共享的所有客户。 这样，服务代表可以读取与服务要求相关的客户数据，但是不能更改该数据。

• 具有 Local Read Account 权限的数据分析员可以查看客户数据并对其所在业务部门中的所有客户运行与客户相关的报表。

• 公司中具有 Deep Read Account 权限的财务专员可以查看客户数据，并对其所在业务部门中的所有客户以及该业务部门的所有下级业务部门中的客户运行与客户相关的报表。

预定义的安全角色列表

下表列出了 Microsoft Dynamics 365 SDK 包含的预定义角色集。

角色	说明
CEO 业务经理	在企业业务级别对组织进行管理的用户。
客户服务经理	在本地级别或团队级别管理客户服务活动的用户。
客户服务代表 (CSR)	任何等级的客户服务代表 (CSR)。
代理	允许代表另一个用户执行操作的用户。
市场营销经理	在本地级别或团队级别管理市场营销活动的用户。
市场营销业务员	参与任何级别的市场营销活动的用户。
销售经理	在本地级别或团队级别管理销售活动的用户。
销售员	任何级别的销售员。
计划经理	安排服务约会的用户。
计划员	管理服务、所需资源和工作时间的用户。
支持用户	作为客户支持工程师的用户。
系统管理员	定义和实施任何级别流程的用户。
系统定制员	自定义 Microsoft Dynamics 365 实体、属性、关系和窗体的用户。
市场营销副总裁	在业务部门级别管理市场营销活动的用户。
销售副总裁	在业务部门级别管理销售组织的用户。

另请参阅

Microsoft Dynamics 365 的安全模型
权限和角色实体
Security role and privilege reference
如何使用基于记录的安全性来控制对 Microsoft Dynamics 365 中记录的访问
在 Microsoft Dynamics 365 中，如何将字段安全用于控制访问字段值

Microsoft Dynamics 365

© 2017 Microsoft。 保留所有权利。 版权