Comment la sécurité basée sur les rôles permet de contrôler l'accès aux entités dans Microsoft Dynamics CRM 2015

Date de publication : novembre 2016

S’applique à : Dynamics CRM 2015

Dans Microsoft Dynamics CRM 2015 et Microsoft Dynamics CRM Online le concept fondamental de sécurité basée sur les rôles est le suivant : un rôle contient les privilèges qui définissent un ensemble d’actions qui peuvent être effectuées au sein de l’organisation. Par exemple, le rôle Vendeur se voit attribuer un groupe de privilèges qui concernent les performances des tâches définies pour ce rôle. Un ou plusieurs rôles prédéfinis ou personnalisés doivent être attribués à tous les utilisateurs. Dans Microsoft Dynamics CRM 2015, des rôles peuvent également être attribués à des équipes. Lorsque l’un de ces rôles est affecté à un utilisateur ou à une équipe, la personne ou les membres de l’équipe se voient attribuer un ensemble de privilèges associés à ce rôle. Au moins un rôle doit être attribué à un utilisateur.

Un privilège autorise l’utilisateur à effectuer une action spécifique sur un type d’entité spécifique. Les privilèges s’appliquent à une classe d’objets complète, et non pas à des instances individuelles d’objets. Par exemple, si un utilisateur ne dispose pas du privilège pour lire les comptes, il échouera systématiquement s’il essaie de lire un compte. Un privilège contient un niveau d’accès qui détermine les niveaux auxquels un privilège s’applique dans l’organisation. Chaque privilège peut avoir jusqu’à quatre niveaux d’accès : Basique, Local, Profond et Général.

Contenu de la rubrique

Rôles

Privilèges

Niveaux d’accès

Pour résumer

Liste des rôles de sécurité prédéfinis

Rôles

Microsoft Dynamics 365 comprend quatorze rôles prédéfinis qui reflètent les rôles d’utilisateurs courants avec des niveaux d’accès définis en fonction de l’objectif de meilleures pratiques de sécurité pour autoriser l’accès à la quantité minimale de données commerciales nécessaires pour réaliser la tâche. Ces rôles vous permettent de déployer rapidement un système Microsoft Dynamics 365 sans devoir définir vos propres rôles. Cependant, vous pouvez créer des rôles personnalisés en utilisant des rôles prédéfinis comme modèle ou définir un nouvel ensemble de rôles. Pour obtenir leur liste, voir Liste des rôles de sécurité prédéfinis.

Chaque rôle est associé à un ensemble de privilèges qui détermine l’accès de l’utilisateur ou de l’équipe à des informations dans la société.

Vous pouvez créer des rôles dans Microsoft Dynamics 365 et modifier ou supprimer ces rôles personnalisés en fonction des besoins de votre organisation. Les rôles que vous créez pour votre division sont hérités par tous les divisions de la hiérarchie.

Vous pouvez attribuer au moins un rôle à un utilisateur ou à une équipe. Par exemple, un utilisateur peut disposer du rôle Directeur commercial en plus du rôle Conseiller du service clientèle, auquel cas cet utilisateur possède l’ensemble des privilèges des deux rôles.

Vous ne pouvez pas modifier les privilèges au niveau de l’utilisateur, mais vous pouvez créer un rôle avec les privilèges souhaités. Prenons un exemple : le rôle Vendeur est attribué à John, ce qui l’oblige à accepter tous les prospects qui lui sont attribués. Toutefois, l’administrateur souhaite que John puisse réattribuer les prospects qui lui sont attribués. Par conséquent, l’administrateur doit soit modifier le rôle Vendeur pour que ce soit possible, soit créer un rôle qui intègre ce privilège spécifique et ajouter John à ce rôle. La création d’un rôle est l’option recommandée, sauf si vous pensez qu’il est nécessaire que tous les utilisateurs ayant le rôle Vendeur aient maintenant ce privilège supplémentaire.

Privilèges

Dans Microsoft Dynamics 365, il existe plus de 580 privilèges qui sont prédéfinis à l’échelle du système pendant l’installation. Un privilège est une autorisation permettant d’effectuer une action dans Microsoft Dynamics 365. Certains privilèges s’appliquent de façon générale et d’autres s’appliquent à un type d’entité spécifique. Pour obtenir la liste complète des privilèges disponibles dans Microsoft Dynamics 365, voir Security role and privilege reference.

Microsoft Dynamics 365 utilise des privilèges comme base de la vérification de sécurité sous-jacente. Les privilèges sont « intégrés » au produit et sont utilisés dans l’ensemble de l’application et des couches de la plateforme. Vous ne pouvez pas ajouter ni supprimer de privilèges, ni modifier la façon dont les privilèges sont utilisés pour accorder l’accès à certaines fonctionnalités, mais vous pouvez créer des rôles à partir de l’ensemble de privilèges existant.

Chaque rôle définit un ensemble de privilèges qui détermine l’accès de l’utilisateur ou de l’équipe à des informations dans la société. La plateforme vérifie la présence du privilège et rejette l’opération si l’utilisateur ne dispose pas du privilège nécessaire. Un privilège est associé à une profondeur ou à un niveau d’accès.

Par exemple, le rôle Vendeur peut contenir les privilèges Read Account avec accès Basic et Write Account avec accès Basic, alors que le rôle Vendeur peut contenir des privilèges comme Read Account avec accès Local et Assign Contact avec accès Local.

La plupart des entités disposent d’un ensemble de privilèges possibles pouvant être ajoutés à un rôle correspondant aux différentes actions qu’il est possible d’effectuer sur les enregistrements de cette entité. Pour plus d'informations, voir Privilèges pat entité.

Chaque action du système et chaque message décrit dans la documentation SDK nécessitent un ou plusieurs privilèges pour être exécutée. Pour plus d'informations, voir Privilèges par message.

Niveaux d’accès

Le niveau d’accès ou la profondeur de privilège d’un privilège détermine, pour un type d’entité donné, les niveaux de la hiérarchie de l’organisation auxquels un utilisateur peut intervenir sur ce type d’entité.

Le tableau suivant répertorie les niveaux d’accès dans Microsoft Dynamics 365, en commençant par l’accès le plus large. L’icône apparaît dans l’éditeur de rôle de sécurité de l’application Web.

	Général. Ce niveau d’accès donne à un utilisateur accès à tous les enregistrements au sein de l’organisation, indépendamment du niveau hiérarchique de la division à laquelle l’instance ou l’utilisateur appartient. Les utilisateurs avec accès Général ont automatiquement l’accès Profond, Local et Basique. Étant donné que ce niveau d’accès permet d’accéder aux informations dans toute l’organisation, il doit être limité en fonction du plan de la sécurité des données de l’organisation. Ce niveau d’accès est généralement réservé aux responsables ayant autorité dans l’ensemble de l’organisation. L’application fait référence à ce niveau d’accès en tant que Organisation.
	Profond. Ce niveau d’accès donne à un utilisateur accès aux enregistrements de la division de l’utilisateur, ainsi qu’à ceux de toutes les divisions subordonnées à la division de l’utilisateur. Les utilisateurs avec accès Profond ont automatiquement l’accès Local et Basique. Étant donné que ce niveau d’accès permet d’accéder aux informations dans toute la division et dans les divisions subordonnées, il doit être limité en fonction du plan de la sécurité des données de l’organisation. Ce niveau d’accès est généralement réservé aux responsables ayant autorité dans l’ensemble des divisions. L’application fait référence à ce niveau d’accès en tant que Divis. mère : sous-divisions.
	Local. Ce niveau d’accès donne à un utilisateur accès aux enregistrements situés dans la division de l’utilisateur. Les utilisateurs avec accès Local ont automatiquement l’accès Basique. Étant donné que ce niveau d’accès permet d’accéder aux informations dans toute la division, il doit être limité en fonction du plan de la sécurité des données de l’organisation. Ce niveau d’accès est généralement réservé aux responsables ayant autorité dans l’ensemble de la division. L’application fait référence à ce niveau d’accès en tant que division.
	De base. Ce niveau d’accès donne à un utilisateur accès aux enregistrements qui lui appartiennent, aux objets partagés avec l’utilisateur et aux objets partagés avec une équipe dont il fait partie. Il s’agit du niveau d’accès standard pour les vendeurs et les conseillers du service clientèle. L’application fait référence à ce niveau d’accès en tant qu’utilisateur.
	Aucun. Aucun accès n'est autorisé.

Pour résumer

• Si un utilisateur dispose du privilège Deep Read Account, il peut lire tous les comptes de sa division, ainsi que tous les comptes de toutes les sous-divisions de cette division.

• Si un utilisateur dispose du privilège Local Read Account, il peut lire tous les comptes dans la division locale.

• Si un utilisateur dispose du privilège Basic Read Account, il ne peut lire que les comptes qu’il possède ou les comptes qui sont partagés avec lui.

• Un conseiller du service clientèle disposant du privilège Basic Read Account peut afficher les comptes qu’il possède et tous les comptes qu’un autre utilisateur a partagé avec lui. Cela permet au conseiller de lire les données de compte correspondant à une demande de service, cela ne lui permet pas de les modifier.

• Un analyste des données disposant du privilège Local Read Account peut afficher les données de compte et exécuter des rapports associés à des comptes pour tous les comptes de sa division.

• Un membre du service financier d’une société disposant du privilège Deep Read Account peut afficher les données de compte et exécuter des rapports associés à des comptes pour tous les comptes de sa division et ceux d’une sous-division.

Liste des rôles de sécurité prédéfinis

Le tableau suivant répertorie l’ensemble de rôles prédéfini inclus dans le SDK Microsoft Dynamics CRM :

Voir aussi

Modèle de sécurité de Microsoft Dynamics CRM 2015
Entités de privilège et de rôle
Security role and privilege reference
Comment la sécurité basée sur les enregistrements permet de contrôler l'accès aux enregistrements dans Microsoft Dynamics CRM 2015
Comment la sécurité de champ permet de contrôler l’accès aux valeurs des champs dans Microsoft Dynamics CRM 2015

© 2017 Microsoft. Tous droits réservés. Copyright