Sécurité de la hiérarchie pour contrôler l’accès

Le modèle de sécurité de hiérarchie est une extension des modèles de sécurité existants qui utilisent des divisions, des rôles de sécurité, le partage et des équipes. Il peut être utilisé avec tous les autres modèles de sécurité existants. La sécurité de la hiérarchie offre un accès plus granulaire aux enregistrements d’une organisation et permet de réduire les coûts de maintenance.

Par exemple, dans des scénarios complexes, vous pouvez commencer par créer plusieurs divisions, puis ajouter la sécurité de la hiérarchie. Cette sécurité supplémentaire fournit un accès plus granulaire aux données avec des coûts de maintenance nettement inférieurs à ceux potentiellement requis par un grand nombre de divisions.

Modèles de sécurité de hiérarchie de responsable et de hiérarchie de poste

Deux modèles de sécurité peuvent être utilisés pour les hiérarchies, la hiérarchie de responsable et la hiérarchie de poste. Avec la hiérarchie de responsable, un responsable doit appartenir à la même division que sa liaison hiérarchique, ou à la division mère de la division de la liaison hiérarchique pour avoir accès aux données de celle-ci. La hiérarchie de poste permet l’accès aux données entre les divisions. Si vous êtes une organisation financière, vous pourriez préférer le modèle de hiérarchie Responsable, pour empêcher les responsables d’accéder aux données externes à leurs divisions. Toutefois, si vous faites partie d’une organisation de service clientèle et que vous voulez que les responsables puissent accéder aux incidents de service traités dans différentes divisions, la hiérarchie Poste pourrait être mieux adaptée.

Note

Si le modèle de sécurité de hiérarchie fournit un certain niveau d’accès aux données, un accès supplémentaires peut être obtenu à l’aide d’autres formulaires de sécurité, tels que les rôles de sécurité.

Hiérarchie Responsable

Le modèle de sécurité de hiérarchie de responsable est basé sur la chaîne de gestion ou la structure de subordination directe, où la relation entre le responsable et le subordonné est établie à l’aide du champ Responsable de la table utilisateur système. Avec ce modèle de sécurité, les responsables peuvent accéder aux données auxquelles leurs subordonnés ont accès. Ils peuvent effectuer du travail pour le compte de leurs subordonnés directs ou accéder à des informations nécessitant une approbation.

Note

Avec le modèle de sécurité de hiérarchie de responsable, le responsable a accès aux enregistrements qui appartiennent à l’utilisateur ou à l’équipe dont un utilisateur est membre, et aux enregistrements qui sont directement partagés avec l’utilisateur ou l’équipe dont un utilisateur est membre. Lorsqu’un enregistrement est partagé par un utilisateur qui est en dehors de la chaîne de gestion avec un utilisateur subalterne direct avec des privilèges de lecture seule, le responsable du subalterne direct a accès uniquement en lecture seule à l’enregistrement partagé.

Lorsque vous avez activé l’option Propriété d’enregistrement dans différentes divisions, les responsables peuvent avoir des subordonnés directs de différentes divisions. Vous pouvez utiliser les paramètres de base de données d’environnement suivants pour supprimer la restriction de division.

Les gestionnaires doivent appartenir à la même unité commerciale ou à l’unité commerciale parente que les rapports

valeur par défaut = true

Vous pouvez la définir sur false et il n’est pas nécessaire que la division d’un responsable soit la même que celle de son subordonné direct.

Outre le modèle de sécurité de hiérarchie de responsable, un responsable doit au moins disposer du privilège Lecture au niveau de l’utilisateur dans une table, pour visualiser les données des subordonnés. Par exemple, si un responsable ne dispose pas de l’accès en lecture sur la table Incident, il ne peut pas voir les incidents auxquels ses subordonnés ont accès.

Pour un subalterne non direct dans la même chaîne de gestion du responsable, un responsable a accès en lecture seule aux données du subalterne non direct. Pour un subordonné direct, le responsable a les accès Lire, Écrire, Ajouter, Ajouter à aux données. Pour illustrer le modèle de sécurité de hiérarchie de responsable, examinons le schéma suivant. Le directeur général peut lire ou mettre à jour les données du Directeur de division et du Directeur des services. Toutefois, le directeur général peut seulement lire les données du directeur commercial et celles du responsable de service, ainsi que les données des ventes et du support. Vous pouvez limiter davantage la quantité de données accessibles par un responsable avec la profondeur. La profondeur est utilisée pour limiter le nombre de niveaux auxquels un responsable a un accès en lecture seule aux données de ses subordonnés. Par exemple, si la profondeur est définie sur 2, le directeur général peut afficher les données du directeur de division, du directeur des services et des responsables des ventes et services. Toutefois, le directeur général n’a pas accès aux données des ventes et du support.

Il est important de noter que si un subordonné direct bénéficie d’un accès de sécurité plus avancé à une table que son responsable, celui-ci ne peut pas afficher tous les enregistrements auquel le subordonné direct a accès. L’exemple suivant illustre ce point.

• Une division possède trois utilisateurs : Utilisateur 1, Utilisateur 2 et Utilisateur 3.

• L’Utilisateur 2 est un subordonné direct de l’Utilisateur 1.

• L’Utilisateur 1 et l’Utilisateur 3 ont un accès en lecture de niveau utilisateur sur la table Compte. Ce niveau d’accès leur donne accès à leurs enregistrements, aux enregistrements partagés avec l’utilisateur et aux enregistrements partagés avec l’équipe dont l’utilisateur est membre.

• L’Utilisateur 2 a accès en lecture de niveau division sur la table Compte. Cet accès permet à l’Utilisateur 2 d’afficher tous les comptes de la division, y compris tous les comptes appartenant à l’Utilisateur 1 et l’Utilisateur 3.

• L’Utilisateur 1, en tant que supérieur direct de l’Utilisateur 2, a accès aux comptes détenus ou partagés par l’Utilisateur 2, y compris les comptes partagés ou détenus par d’autres équipes de l’Utilisateur 2. Toutefois, l’Utilisateur 1 n’a pas accès aux comptes de l’Utilisateur 3, même si son subordonné direct peut accéder aux comptes de l’Utilisateur 3.

Hiérarchie Poste

La hiérarchie Poste n’est pas basée sur la structure de subordination directe, comme la hiérarchie Responsable. Un utilisateur n’a pas besoin d’être le responsable d’un autre utilisateur pour pouvoir accéder aux données de cet utilisateur. En tant qu’administrateur, vous définissez divers postes dans l’organisation et les organisez dans la hiérarchie des postes. Ensuite, vous ajoutez des utilisateurs à un poste donné, ou, comme nous disons également, vous référencez un utilisateur avec un poste spécifique. Un utilisateur peut être référencé avec un seul poste uniquement dans une hiérarchie donnée, mais un poste peut être utilisé pour plusieurs utilisateurs. Les utilisateurs aux postes plus élevés dans la hiérarchie ont accès aux données des utilisateurs occupant des postes moins élevés, dans le chemin ancêtre direct. Les postes plus élevés directs ont un accès Lire, Écrire, Ajouter, Ajouter à aux données des postes moins élevés dans le chemin ancêtre direct. Les postes plus élevés non directs ont un accès Lecture seule aux données des postes moins élevés dans le chemin ancêtre direct.

Pour illustrer le concept de chemin ancêtre direct, examinons le schéma suivant. Le poste de directeur commercial peut accéder aux données des ventes. Toutefois, il n’a pas accès aux données du support, qui se trouvent dans l’autre chemin ancêtre. Il en va de même pour le poste de responsable de service. Il n’a pas accès à des données de ventes, qui se trouvent dans le chemin des ventes. Comme dans la hiérarchie de responsable, vous pouvez limiter la quantité de données accessibles par les postes les plus élevés avec la profondeur. La profondeur limite le nombre de niveaux auxquels un poste élevé a accès en lecture seule aux données des postes subalternes dans le chemin ancêtre direct. Par exemple, si la profondeur est définie sur 3, le poste de directeur général peut afficher toutes les données à partir des postes de directeur de division et directeur des services jusqu’aux postes de ventes et de support.

Note

Avec la sécurité de hiérarchie Poste, un utilisateur ayant un poste élevé a accès aux enregistrements qui appartiennent à un utilisateur de niveau moindre ou à l’équipe dont l’utilisateur est membre, et aux enregistrements qui sont directement partagés avec l’utilisateur ou son équipe.

Outre le modèle de sécurité de hiérarchie des postes, les utilisateurs de niveau supérieur doivent au moins avoir le privilège de lecture au niveau de l’utilisateur dans une table pour afficher les enregistrements auxquels les utilisateurs aux postes moins élevés ont accès. Par exemple, si un utilisateur de niveau supérieur ne dispose pas de l’accès en lecture sur la table Incident, il ne peut pas voir les incidents auxquels les utilisateurs aux postes moins élevés ont accès.

Configuration de la sécurité de la hiérarchie

Pour configurer la sécurité de hiérarchie, assurez-vous de disposer de l’autorisation Administrateur système pour mettre à jour le paramètre.

• Suivez les étapes de la section Affichage de votre profil utilisateur.
• Vous ne disposez pas des autorisations appropriées ? Contactez votre administrateur système.

La sécurité de hiérarchie est désactivée par défaut. Pour activer la sécurité de hiérarchie, procédez comme suit.

1. Sélectionnez un environnement et accédez à Paramètres>Utilisateur + autorisations>Sécurité de la hiérarchie.

2. Sous Modèle de hiérarchie, sélectionnez Activer le modèle de hiérarchie de responsable ou Activer le modèle de hiérarchie de poste en fonction de vos exigences.

   Important

   Pour apporter des modifications dans la Sécurité de la hiérarchie, vous devez disposer du privilège Modifier les paramètres de sécurité hiérarchique.

   Dans la zone Gestion des tables de la hiérarchie, toutes les tables système sont activées par défaut pour la sécurité de la hiérarchie, mais vous pouvez exclure certaines tables de la hiérarchie. Pour exclure des tables spécifiques du modèle de hiéarchie, décochez les tables à exclure et enregistrez vos modifications.

   

3. Définissez la Profondeur sur la valeur souhaitée pour limiter le nombre de niveaux auxquels un responsable a un accès en lecture seule aux données de ses subordonnés.

   Par exemple, si la profondeur est définie sur 2, un responsable peut uniquement accéder à ses propres comptes et aux comptes de ses subordonnés sur deux niveaux. Dans notre exemple, si vous vous connectez aux applications d’engagement client en tant que vice-président des ventes non administrateur, vous ne voyez que les comptes actifs des utilisateurs comme indiqué :

   

   Note

   Bien que la sécurité de la hiérarchie accorde au Directeur de division l’accès aux enregistrements du rectangle rouge, un accès supplémentaire peut être disponible en fonction du rôle de sécurité de ce directeur.

4. Dans la section Gestion des tables de la hiérarchie, toutes les tables système sont activées par défaut pour la sécurité de la hiérarchie. Pour exclure une table spécifique du modèle de hiéarchie, décochez la case en regard du nom de la table et enregistrez vos modifications.

   Nouvelle interface utilisateur moderne dans version préliminaire

   

   Important

   • Cette fonctionnalité est en version préliminaire.
   • Les fonctionnalités en version préliminaire ne sont pas destinées à une utilisation en production et peuvent être restreintes. Ces fonctionnalités sont soumises à des conditions d’utilisation supplémentaires, et sont disponibles avant une version officielle de telle sorte que les clients puissent tirer parti d’un accès anticipé et fournir leurs commentaires.

   Interface utilisateur héritée

   

Configuration des hiérarchies de responsable et de poste

La hiérarchie de responsable est facilement créée l’aide de la relation responsable de l’enregistrement d’utilisateur système. Vous utilisez le champ de recherche Responsable (ParentsystemuserID) pour indiquer le responsable de l’utilisateur. Si vous avez créé la hiérarchie Poste, vous pouvez également référencer l’utilisateur avec un poste spécifique dans la hiérarchie Poste. Dans l’exemple suivant, le commercial est subordonné au directeur commercial dans la hiérarchie de responsable et comporte également le poste de ventes dans la hiérarchie de poste :

Pour ajouter un utilisateur à un poste spécifique dans la hiérarchie des postes, utilisez le champ de recherche Poste dans le formulaire de l’enregistrement utilisateur.

Important

Pour ajouter un utilisateur à un poste ou pour modifier le poste de l’utilisateur, vous devez disposer du privilège Attribuer un poste à un utilisateur.

Pour modifier le poste dans le formulaire de l’enregistrement utilisateur, sur la barre de navigation, sélectionnez Plus (…) et choisissez un autre poste.

Pour créer une hiérarchie des postes, procédez comme suit :

1. Sélectionnez un environnement et accédez à Paramètres>Utilisateur + autorisations>Postes.

   Pour chaque poste, entrez le nom du poste, son parent et sa description. Ajoutez des utilisateurs à ce poste à l’aide du champ de recherche Utilisateurs à ce poste. L’image suivante est un exemple de hiérarchie des postes avec les postes actifs.

   

   L’exemple des utilisateurs activés avec leurs postes correspondants est illustré dans l’image suivante.

   

Inclure ou exclure les enregistrements appartenant à un subordonné direct avec le statut d’utilisateur désactivé

Les responsables peuvent voir les enregistrements de leur subordonné direct avec le statut désactivé pour les environnements dans lesquels la sécurité de la hiérarchie est activée après le 31 janvier 2024. Pour les autres environnements, les enregistrements du subordonné direct avec le statut désactivé ne sont pas inclus dans la vue du responsable.

Pour inclure les enregistrements du subordonné direct avec le statut désactivé :

1. Installez l’outil OrganizationSettingsEditor.
2. Mettez à jour le paramètre AuthorizationEnableHSMForDisabledUsers sur true.
3. Désactivez la Modélisation de la hiérarchie.
4. Réactivez-la à nouveau.

Pour exclure les enregistrements du subordonné direct avec le statut désactivé :

1. Installez l’outil OrganizationSettingsEditor.
2. Mettez à jour le paramètre AuthorizationEnableHSMForDisabledUsers sur false.
3. Désactivez la Modélisation de la hiérarchie.
4. Réactivez-la à nouveau.

Note

• Lorsque vous désactivez et réactivez la modélisation de la hiérarchie, la mise à jour peut prendre un certain temps, car le système doit recalculer l’accès aux enregistrements du responsable.
• Si vous constatez un délai d’attente, réduisez le nombre de tables dans la liste Gestion des tables de la hiérarchie pour inclure uniquement les tables qui doivent être visualisées par le responsable. Si le délai d’attente persiste, envoyez un ticket de support pour demander de l’aide.
• Les enregistrements du subordonné direct avec le statut désactivé sont inclus si ces enregistrements sont partagés avec un autre subordonné direct actif. Vous pouvez exclure ces enregistrements en supprimant le partage.

Considérations relatives aux performances

Pour optimiser les performances, nous vous recommandons de :

• Maintenir la sécurité de hiérarchie effective avec 50 utilisateurs ou moins sous un responsable ou un poste. Votre hiérarchie peut avoir plus de 50 utilisateurs sous un responsable ou un poste, mais vous pouvez utiliser le paramètre Profondeur pour réduire le nombre de niveaux pour l’accès en lecture seule et, avec cette limite, le nombre effectif d’utilisateurs sous un responsable ou un poste à 50 utilisateurs ou moins.

• Utilisez des modèles de sécurité hiérarchique avec d’autres modèles de sécurité existants pour des scénarios plus complexes. D’éviter de créer un grand nombre de divisions. Créez plutôt moins de divisions et ajoutez la sécurité de la hiérarchie.

Voir aussi

Sécurité dans Microsoft Dataverse
Interroger et visualiser des données hiérarchiques