Utiliser la sécurité au niveau des champs pour contrôler l’accès aux valeurs des champs
Dans Dynamics 365 Customer Engagement (on-premises), utilisez la sécurité au niveau des champs pour limiter l’accès aux champs à fort impact sur les activités à des utilisateurs et des équipes spécifiques. Par exemple, utilisez cette option pour permettre à certains utilisateurs de lire ou de mettre à jour le score de crédit d’un client. Pour cette version, la sécurité au niveau du champ peut être appliquée à la fois aux champs personnalisés et à de nombreux champs prêts à l’emploi.
Les étapes suivantes montrent comment limiter l’accès à un champ :
Activation de la sécurité au niveau du champ pour un attribut
Création d’un profil de sécurité au niveau du champ
Association des utilisateurs ou des équipes au profil
Ajout d’autorisations spécifiques au champ, telles que la création, la mise à jour ou la lecture à un attribut spécifique du profil
Le diagramme suivant illustre l’interaction entre la sécurité basée sur les rôles et la sécurité au niveau du champ.
La sécurité basée sur les rôles vous permet d’afficher les enregistrements d’un type d’entité spécifique, la sécurité basée sur les enregistrements vous permet de consulter chaque enregistrement, et la sécurité au niveau des champs vous permet de voir des champs spécifiques.
Vidéo : Sécurité au niveau des champs dans Microsoft Dynamics CRM 2015
Forums aux questions
Quels rôles de sécurité vous permettent de voir les champs sécurisés ?
Comment les champs sécurisés se comportent-ils pour Retrieve et RetrieveMultiple ?
Comment les champs sécurisés se comportent-ils pour la création ou la mise à jour ?
Comment les champs sécurisés se comportent-ils lorsque des enregistrements sont partagés ?
Comment les champs sécurisés se comportent-ils pour les vues filtrées ?
Comment les champs sécurisés se comportent-ils pour la synchronisation hors ligne ?
Quels attributs peuvent être sécurisés ?
Pour afficher les attributs pouvant être sécurisés, vous pouvez interroger les métadonnées de l’entité pour les propriétés suivantes :
-
Il existe des milliers d’attributs pouvant être sécurisés. Il existe donc deux moyens plus simples de rechercher cette information. Pour afficher les métadonnées d’entité pour votre organisation, installez la solution Navigateur de métadonnées décrite dans l’article Accès aux métadonnées de votre organisation. Vous pouvez également accéder à la documentation de référence pour les entités dans Référence d’entité.
Il existe des règles supplémentaires qui s’appliquent à certains types de données d’attribut :
Les attributs booléens peuvent être sécurisés pour les opérations de création et de mise à jour, mais pas pour la lecture.
Les attributs de groupes d’options peuvent être sécurisés pour la création, la mise à jour et la lecture, lorsqu’une valeur par défaut n’est pas spécifiée.
Quels rôles de sécurité vous permettent de voir les champs sécurisés ?
Le profil de sécurité du champ Administrateur système donne l’accès complet à tous les champs sécurisés dans Dynamics 365 Customer Engagement (on-premises). Par défaut, tous les utilisateurs ayant le rôle de sécurité Administrateur système disposent de ce profil. Ce profil est géré par le système et ne peut pas être mis à jour ni supprimé.
Comment les champs sécurisés se comportent-ils pour Retrieve et RetrieveMultiple ?
Lorsque vous appelez la méthode ou le message Retrieve ou RetrieveMultiple, Dynamics 365 Customer Engagement (on-premises) évalue si l’appelant et l’utilisateur représenté ont accès à chaque enregistrement récupéré (il s’agit du processus de sécurité standard) et à chaque champ sécurisé. L’appel ne lève aucune exception si les critères contiennent les champs sécurisés auxquels l’appelant n’a pas accès. À la place, des valeurs Null sont retournées pour les champs sécurisés s’ils font partie de l’ensemble de colonnes de sortie.
Vous trouverez ci-dessous plus d’informations sur les différents comportements de récupération des champs sécurisés.
Lorsqu’un attribut sécurisé se trouve dans l’ensemble de colonnes
Si l’appelant (ou l’utilisateur représenté ) n’a pas accès en lecture aux champs sécurisés inclus dans un ensemble de colonnes, la valeur retournée est null. Vous ne pouvez pas faire la différence entre une valeur null retournée provoquée par l’absence de données ou provoquée par un accès insuffisant.
Lorsqu’un attribut sécurisé se trouve dans le critère de filtre
Si l’appelant (ou l’utilisateur représenté) n’a pas accès aux champs sécurisés inclus dans les critères de filtre, la valeur du champ est remplacée par null pendant l’évaluation du filtre.
Dans le tableau suivant, l’appelant a accès à tous les attributs, excepté ceux désignés par un astérisque (*).
| Numéro d’enregistrement | Valeur de l’attribut Nom | Valeur de l’attribut Description | Valeur de l’attribut Peut être contacté |
|---|---|---|---|
| 1 | A | AAA | True |
| 2 | B | BBB | False |
| 3 | C | CCC | True* |
| 4 | D | DDD | Null |
| 5* | E* | EEE* | Null* |
Lorsque le filtre est CanbeContacted == True, seul l’enregistrement un est renvoyé.
Lorsque le filtre est IsNULL (CanbeContacted), les enregistrements 3 et 4 sont renvoyés. Comme l’enregistrement 3 n’est pas visible par l’utilisateur, il est traité en tant que valeur null pendant l’évaluation du critère et est évalué comme True pour ISNull.
Lors de l’agrégation sur la base des attributs sécurisés
Les valeurs sécurisées sont remplacées par une valeur null, par conséquent le comportement d’agrégation SQL normal s’applique.
Lors du regroupement sur la base des attributs sécurisés
Si l’appelant (ou l’utilisateur représenté) n’a pas accès à l’attribut utilisé pour le regroupement, la valeur est traitée comme étant null et les résultats sont regroupés avec toutes les valeurs null.
Dans l’exemple suivant, l’appelant a accès à certains attributs. Le format gras indique qu’il n’y a pas d’accès aux attributs et associé au format . *italique désigne un enregistrement pour lequel l’appelant n’a pas d’accès en lecture; aussi indiqué par **.
| Nom | Description | Nombre de commandes | Région |
|---|---|---|---|
| A | AAA | 1 | WA |
| B | BBB | 4 | WA |
| C | CCC | 4 | CA |
| D** | DDD** | 3** | MA** |
| E | EEE | 0 | Rhône-Alpes |
| F | FFF | 0 | WA* |
| G | GGG | 2 | CA* |
Select State, Total(orders) Group by (STATE) donne les résultats suivants :
WA–5
CA–4
null–2
Lors du classement sur la base des attributs sécurisés
Si l’appelant (ou l’utilisateur représenté ) n’a pas accès aux champs sécurisés inclus dans un ordre par condition, les valeurs seront traitées comme si elles étaient null.
Dans l’exemple suivant, l’appelant a accès aux attributs qui sont en texte brut. Le format gras indique qu’il n’y a pas d’accès aux attributs et associé à un astérisque (). *italique désigne un enregistrement pour lequel l’appelant n’a pas d’accès en lecture; aussi indiqué par **.
| Nom | Description | CanbeContacted |
|---|---|---|
| A | AAA | Vrai |
| B | BBB | False |
| C | CCC* | True* |
| D | DDD | Null |
| E | EEE* | Null* |
| F** | FFF** | True** |
| G | Null | Vrai |
Select Name order by Description ascending donne les résultats suivants :
{G, E, C}, A, B, D seront renvoyés.
Comment les champs sécurisés se comportent-ils pour la création ou la mise à jour ?
Un programmeur peut générer un client qui utilise les méthodes Create et Update qui interagissent avec les champs sécurisés. Lorsque vous appelez la méthode Create ou Update, en transmettant des données pour les champs sécurisés et que l’appelant ne dispose pas d’autorisations suffisantes, une exception est levée.
Comment les champs sécurisés se comportent-ils lorsque des enregistrements sont partagés ?
Un utilisateur ayant accès à un champ sécurisé dans un enregistrement peut le partager avec un autre utilisateur ou une autre équipe. L’utilisateur peut uniquement accorder l’accès dont il dispose sur l’enregistrement. Par exemple, pour partager l’enregistrement et bénéficier des privilèges de mise à jour, l’utilisateur doit avoir des privilèges de mise à jour.
Vous pouvez partager un champ sécurisé sur un enregistrement spécifique avec la lecture et/ou la mise à jour avec un principal de sécurité (utilisateur ou équipe). L’utilisateur ou les membres de l’équipe avec lesquels l’enregistrement a été partagé disposent maintenant de ce type d’accès de champ sécurisé uniquement sur les champs sécurisés partagés pour seulement cet enregistrement en particulier, même si l’utilisateur ou le membre de l’équipe avec lequel il a été partagé n’a pas de profil de sécurité de champ qui lui fournit l’acccès.
Comment les champs sécurisés se comportent-ils pour les vues filtrées ?
Un administrateur sécurise l’accès à un certain nombre de champs dans l’application et souhaite que ces champs ne soient pas disponibles dans les rapports. Cela permet de conserver le même ensemble de rapports pour tous les utilisateurs. Les vues filtrées ne renverront aucune donnée pour les champs sécurisés si l’utilisateur appelant n’a pas d’autorisation pour ces champs. Si aucune sécurité de champ n’est appliquée aux attributs de la vue, les vues filtrées retourneront des données complètes.
Comment les champs sécurisés se comportent-ils pour la synchronisation hors ligne ?
Si vous utilisez Dynamics 365 for Microsoft Office Outlook avec accès hors ligne, seules les valeurs de champ sécurisées auxquelles vous avez accès sont répliquées dans la base de données hors connexion. Si vous n’avez pas accès aux données, elles ne seront pas enregistrées hors connexion.
Voir aussi
Vidéo : Sécurité au niveau des champs dans Microsoft Dynamics CRM 2015
Le modèle de sécurité de Microsoft Dynamics 365 Customer Engagement
Comment la sécurité basée sur les rôles permet de contrôler l’accès aux entités dans Microsoft Dynamics 365 Customer Engagement
Utiliser la sécurité basée sur les enregistrements pour contrôler l’accès aux enregistrements