Comment la sécurité basée sur les rôles permet de contrôler l’accès aux entités

Dans Dynamics 365 Customer Engagement (on-premises), 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 Dynamics 365 Customer Engagement (on-premises), 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.

Rôles

Dynamics 365 Customer Engagement (on-premises) 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 Dynamics 365 Customer Engagement (on-premises) 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 en obtenir la 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 Dynamics 365 Customer Engagement (on-premises) 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 Dynamics 365 Customer Engagement (on-premises), 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 Dynamics 365 Customer Engagement (on-premises). Certains privilèges s’appliquent de façon générale et d’autres s’appliquent à un type d’entité spécifique.

Dynamics 365 Customer Engagement (on-premises) 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é.

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.

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 Dynamics 365 Customer Engagement (on-premises), 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.

Niveau d’accès	Description
	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 de toute l’organisation, il doit être limité afin de respecter le plan de sécurité des données de l’organisation. Ce niveau d’accès est généralement réservé aux responsables ayant autorité sur l’organisation. L’application fait référence à ce niveau d’accès comme Organisation.
	Profond. Ce niveau d’accès permet à un utilisateur d’accéder aux enregistrements du centre de profit de l’utilisateur et de toutes les unités commerciales subordonnées à cette dernière. Les utilisateurs qui disposent d’un accès Approfondi bénéficient également d’un accès Local et De base. Étant donné que ce niveau d’accès permet d’accéder aux informations de tout le centre de profit et des centres de profit subordonnés, il doit être limité afin de respecter le plan de sécurité des données de l’organisation. Ce niveau d’accès est généralement réservé aux responsables ayant autorité sur les unités commerciales. L’application fait référence à ce niveau d’accès comme Divis. mère : sous-divisions.
	Local. Ce niveau d’accès permet à un utilisateur d’accéder aux enregistrements du centre de profit de l’utilisateur. Les utilisateurs qui disposent d’un accès Local bénéficient également d’un accès De base. Étant donné que ce niveau d’accès permet d’accéder aux informations de tout le centre de profit, il doit être limité afin de respecter le plan de sécurité des données de l’organisation. Ce niveau d’accès est généralement réservé aux responsables ayant autorité sur le centre de profit. L’application fait référence à ce niveau d’accès comme Centre de profit.
	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 qui lui appartiennent 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 qui lui appartiennent 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 prédéfini de rôles qui sont inclus.

Voir aussi

Le modèle de sécurité de Microsoft Dynamics 365 Customer Engagement (on-premises)
Entités de privilège et de rôle
Utiliser la sécurité basée sur les enregistrements pour contrôler l’accès aux enregistrements
Comment la sécurité de champ permet de contrôler l’accès aux valeurs des champs dans Microsoft Dynamics 365 Customer Engagement (on-premises)