Présentation
Pour garantir une plus grande sécurité du déploiement de Microsoft Dynamics 365 par le client, l’architecte de solution doit planifier et animer un atelier Modèle de sécurité. L’objectif de l’atelier est d’évaluer le modèle de sécurité proposé, de fournir un feedback et des recommandations soulignant les risques et problèmes techniques, et d’identifier les bonnes pratiques.
L’atelier Modèle de sécurité doit avoir lieu lors de la phase d’implémentation du projet. Il doit fournir un résumé de tous les aspects liés à la sécurité précédemment abordés lors des ateliers précédents.
Vous pouvez télécharger des exemples de modèles pour chaque atelier du module et les utiliser lorsque vous effectuez ces ateliers pour trouver des solutions.
Pourquoi la sécurité est importante
Dynamics 365 stimule les activités de vos clients. Les données commerciales sensibles concernant les clients, les informations financières et les processus commerciaux critiques contenues dans le système doivent être sécurisées pour les clients qui adoptent le système.
La stratégie de sécurité adéquate permet de trouver le juste équilibre entre les exigences de sécurité légitimes et le besoin d’accès au système et de collaboration intersociétés. Lors de la mise en œuvre de Dynamics 365, vous devez équilibrer deux préoccupations ; l’accès des utilisateurs et la sécurité du système.
D’une part, il est important de se soucier de la sécurité des données et du système. Vos données sont le moteur de votre entreprise. Vos clients, vos commandes, les informations de contact des principaux contacts commerciaux sont autant d’éléments que vous ne voulez pas voir tomber entre les mains d’un concurrent. Avec la réglementation relative aux données personnelles, votre entreprise peut être tenue responsable si une violation de données affecte les données personnelles.
D’autre part, vous vous préoccupez de l’utilisation du système et de l’adoption par les utilisateurs. L’une des principaux objectifs de l’implémentation de Dynamics 365 est d’augmenter la visibilité et le partage des données d’entreprise entre les groupes, et d’éliminer les silos de données dans votre organisation. En donnant de la visibilité aux contacts et aux comptes dans l’ensemble de votre organisation, les équipes peuvent collaborer efficacement plutôt que se concurrencer. Ainsi, vous êtes assuré de disposer d’une seule version des informations de contact et de compte. Si vous allez trop loin dans un sens comme dans l’autre, vous risquez l’échec de votre implémentation.
Si vous êtes trop laxiste avec la sécurité, les utilisateurs peuvent modifier des données qu’ils ne devraient pas pouvoir changer et donc polluer les données, ce qui donne l’impression que les données contenues dans le système ne sont pas fiables.
Si vous êtes trop strict dans votre stratégie de sécurité et que vous verrouillez tout pour que les utilisateurs ne puissent voir qu’un petit sous-ensemble des enregistrements dans le système, vous diminuez la valeur de Dynamics 365 en tant qu’outil de collaboration. Ensuite, par conception, vous reviendrez aux anciens silos de données, simplement dans un endroit différent.
Considérations relatives au modèle de sécurité
Avant d’entrer dans les détails de l’atelier, les sections suivantes passeront en revue des éléments de sécurité clés communs à la plupart des implémentations de Dynamics 365.
Élaborer une stratégie de sécurité
Bien que la stratégie de sécurité de chacun diffère légèrement, les directives suivantes peuvent être utiles pour votre implémentation.
Soyez plus restrictif en mode écriture qu’en mode lecture
Pour maintenir une bonne qualité des données, il est judicieux de limiter les personnes autorisées à modifier ou supprimer des enregistrements en restreignant, par exemple, les droits de modification ou de suppression aux seuls propriétaires des enregistrements. Il est souvent plus logique d’être moins restrictif sur les enregistrements que les autres utilisateurs peuvent lire. Cette approche préserve la convivialité de Dynamics 365 et permet aux utilisateurs de maîtriser le contexte dans lequel leurs enregistrements sont liés à d’autres enregistrements, comme les comptes parents. Cependant, cette approche élimine le risque de modification ou de suppression d’enregistrements dont ils ne sont pas propriétaires, par malveillance ou par erreur.
Simplifier
Il existe de nombreux outils dans la boîte à outils de sécurité Dynamics 365, mais avant de les utiliser tous, tenez compte de la façon dont vous allez gérer le modèle de sécurité à long terme. Si l’administrateur doit penser à affecter quatre rôles différents à un nouvel utilisateur et à les ajouter à plusieurs équipes pour que le modèle de sécurité fonctionne, il est peu probable que le client puisse maintenir la stratégie à long terme. L’architecte de la solution doit prendre en compte de l’impact de la conception de la sécurité sur l’expérience utilisateur. De plus, il doit déterminer la complexité de la gestion de la stratégie de sécurité pour les administrateurs système. Les meilleures stratégies de sécurité sont simples, bien documentées et reproductibles. C’est pour cette raison que l’utilisation de fonctionnalités telles que les groupes de sécurité Active Directory est une excellente idée pour les déploiements plus importants et plus complexes, car l’affectation du rôle, de l’équipe et du centre de profit peut être automatisée et le risque d’erreur humaine réduit.
Assurez-vous que la conception de la sécurité est fondée sur des exigences commerciales légitimes
Veillez à déterminer si vos décisions en matière de conception de sécurité sont prises en raison d’un sentiment de crainte ou d’une préoccupation commerciale légitime. Si elles sont motivées par un sentiment de crainte, vous prenez peut-être votre décision sur la base d’une erreur commise par quelqu’un dans le passé. La crainte n’est jamais bonne conseillère, en particulier la crainte de vos collaborateurs. Vous leur faites confiance pour faire leur travail, représenter votre entreprise et vendre vos produits. Une conception de sécurité trop stricte peut être parfois un révélateur des problèmes de confiance fondamentaux entre la direction et les collaborateurs.
Documentez et réévaluez périodiquement votre conception de sécurité
La conception de la sécurité doit être prise en compte au début d’une implémentation de Dynamics 365, mais elle sera parfois négligée par la suite. Parfois, lorsque les modèles d’utilisation du client changent ou que sa base d’utilisateurs évolue, les décisions de conception de sécurité initiales peuvent ne pas être adaptées et doivent être ajustées.
Par exemple, lorsque votre base d’utilisateurs est réduite, une conception à un seul centre de profit peut fonctionner parfaitement. Toutefois, si votre base d’utilisateurs augmente et englobe plusieurs départements ayant des exigences diverses, il peut s’avérer nécessaire d’ajouter des centres de profit pour étendre votre déploiement à une base d’utilisateurs plus large. Aucune règle absolue ne peut être établie, mais il est recommandé d’examiner périodiquement la stratégie et la conception de la sécurité, à évaluer ses points forts et ses points faibles et à identifier les aspects à améliorer. Par conséquent, il est important de documenter le modèle de sécurité dans le cadre de Success by Design. En effet, une documentation est créé, qui peut être périodiquement revue par le client et le consultant et mise à jour à mesure que les exigences de sécurité évoluent.
La stratégie de sécurité détermine les choix de configuration
Lorsque le client ou le partenaire conçoit la structure de sa table, il doit garder à l’esprit sa stratégie de sécurité. La configuration de table prend en charge votre stratégie de sécurité. Par exemple, si des tables sont créées avec la propriété au niveau de l’organisation, le client ne pourra pas restreindre l’accès aux enregistrements de table selon la propriété ou le centre de profit. Même si vous ne prévoyez pas de restreindre l’accès à la table, il est recommandé de toujours sélectionner la propriété de l’utilisateur ou de l’équipe, à moins que la table soit utilisée uniquement pour les données de référence intersociétés, par exemple, pour alimenter une liste de recherche. Gardez également à l’esprit la façon dont la sécurité d’une table doit affecter la sécurité de la table associée. Si l’accès à un enregistrement parent doit s’étendre en cascade aux enregistrements enfants, vous pouvez utiliser des types de relations parentales ou configurables en cascade.
La sécurité doit être au niveau de la plateforme, et non de la couche de l’application
De nombreux moyens permettent de contrôler la lecture et la modification des données. Vous pouvez définir des champs en lecture seule sur votre formulaire basé sur un modèle, vous pouvez utiliser JavaScript pour masquer les champs de l’expérience utilisateur et vous pouvez masquer les champs des formulaires et des vues. Aucune de ces approches n’est véritablement sécurisée, car bien qu’elles guident le comportement des utilisateurs, elles ne sécurisent pas vraiment les données. Les utilisateurs peuvent accéder aux données par d’autres moyens. Pour mettre en place une sécurité réelle, vous devez utiliser des fonctionnalités de sécurité telles que les rôles, les équipes et les centres de profit.
Composants du modèle de sécurité
Dynamics 365 offre plusieurs outils qui peuvent être utilisés ensemble pour répondre à presque toutes les exigences de sécurité. Cette section aborde brièvement les principaux outils dont dispose un architecte de la solution pour fournir un modèle de sécurité complet.
Centres de profit
Les centres de profit offrent un cadre pour définir la structure organisationnelle de vos utilisateurs et enregistrements dans Dynamics 365. Les centres de profit regrouperont les utilisateurs et les équipes selon une hiérarchie organisationnelle. Ils peuvent fonctionner avec des rôles de sécurité pour accorder ou restreindre l’accès aux données.
L’aptitude des centres de profit vient de leur nature hiérarchique. Les utilisateurs peuvent avoir accès aux enregistrements uniquement dans leur centre de profit, ou bien dans leur centre de profit et ceux situés aux niveaux inférieurs. Par exemple, la nature hiérarchique des centres de profit peut vous permettre de limiter l’accès aux enregistrements au niveau du site, du district, de la région et de l’entreprise.
Facteurs à prendre en compte concernant les centres de profit :
Le centre de profit racine est créé lorsqu’une base de données Microsoft Dataverse est approvisionnée.
Un utilisateur ou une équipe peut être membre uniquement d’un seul centre de profit.
Les enregistrements sont liés à un seul centre de profit au moyen de leur utilisateur ou équipe propriétaire.
Un utilisateur ou une équipe peut être déplacé(e) vers un autre centre de profit. Lors du transfert d’un utilisateur ou d’une équipe entre des centres de profit, il se peut que tous les enregistrements appartenant à l’utilisateur ou à l’équipe doivent être réassociés au nouveau centre de profit. Les personnes disposant d’une sécurité de lecture au niveau du centre de profit dans l’ancien centre de profit perdront l’accès à ces enregistrements.
Lors du déplacement d’un utilisateur ou d’une équipe vers un nouveau centre de profit, tous les rôles de sécurité devront être réappliqués à l’utilisateur ou à l’équipe.
Les centres de profit non racine peuvent être supprimés une fois désactivés.
Les centres de profit peuvent être déplacés dans la hiérarchie, mais il est impossible de redéfinir un parent pour le centre de profit racine.
La structure du centre de profit s’apparente généralement à l’organigramme d’une entreprise, mais elle n’a pas besoin d’être aussi granulaire, à moins qu’il y ait une raison commerciale spécifique. Vous devez considérer les centres de profit comme des éléments constitutifs de votre modèle de sécurité. Dans la plupart des cas, vous n’avez pas besoin de créer un centre de profit pour chaque département de votre entreprise. Par exemple, sur un site, les départements commercial et marketing peuvent être en mesure de partager le même centre de profit s’il n’y a aucun enregistrement à restreindre entre les groupes. Gardez à l’esprit que les rôles de sécurité fonctionnent avec les centres de profit. Ainsi, même si le département commercial et le département marketing se trouvent dans le même centre de profit, les utilisateurs ne pourront pas nécessairement voir tous les enregistrements, si leurs rôles de sécurité les limitent au niveau de l’utilisateur.
Rôles de sécurité
Les rôles de sécurité déterminent le niveau d’autorisation dont disposent les utilisateurs au sein des entités de l’organisation. Les rôles de sécurité peuvent être affectés aux utilisateurs ou aux équipes. Les rôles de sécurité déterminent les tables auxquelles l’utilisateur peut accéder, les enregistrements de la table sur lesquels il agit et les autorisations dont il dispose concernant ces enregistrements.
Lorsqu’il est affecté à un utilisateur ou à une équipe, le rôle de sécurité s’applique toujours dans le cadre du centre de profit de l’utilisateur ou de l’équipe. Par conséquent, si un utilisateur hérite d’un rôle de sécurité d’une équipe, les privilèges accordés par ce rôle de sécurité sont en vigueur dans le cadre du centre de profit de l’équipe, et non de l’utilisateur. Cette approche peut être utile pour étendre l’étendue des droits d’accès d’un utilisateur à d’autres centres de profit. Par exemple, grâce au diagramme de centre de profit précédent, un utilisateur du centre de profit du Bureau de Chicago peut être ajouté à une équipe liée au centre de profit du Bureau d’Atlanta et se voir octroyer des droits de lecture sur les enregistrements du centre de profit.
Équipes
Les équipes sont un autre moyen de regrouper les utilisateurs ; elles peuvent jouer un rôle dans votre stratégie de sécurité. Plusieurs types d’équipes sont disponibles dans Dynamics 365 :
Les équipes de propriétaires peuvent se voir affecter des rôles de sécurité et être utilisées en tant que propriétaires d’enregistrements dans Dynamics 365. Lorsqu’un utilisateur est ajouté en tant que membre d’une équipe propriétaire, il hérite du rôle de sécurité de l’équipe, mais ce rôle s’applique dans le contexte du centre de profit de l’équipe. Les équipes propriétaires peuvent être utiles pour lier un enregistrement à un centre de profit spécifique.
Les équipes du groupe de sécurité Microsoft Entra ID sont similaires aux équipes de propriétaires, mais elles sont liées à un groupe de sécurité Microsoft Entra ID. Les utilisateurs ajoutés au groupe de sécurité Microsoft Entra ID avec une licence Dynamics 365 sont activés automatiquement dans le système et ajoutés à l’équipe Dynamics 365 liée lorsqu’ils se connectent à l’environnement. Cette fonction est utile pour gérer les droits d’accès des utilisateurs en dehors de Dynamics 365, car les utilisateurs peuvent hériter des rôles de sécurité affectés aux équipes Dynamics 365.
Les équipes de groupes de bureau Microsoft Entra ID sont comme les équipes de groupes de sécurité Microsoft Entra ID, mais elles utilisent un groupe Office 365 au lieu d’un groupe de sécurité Microsoft Entra ID. La principale différence est que les groupes Office 365 peuvent être créés et que la gestion des groupes peut être effectuée par des personnes qui ne sont pas des administrateurs Active Directory.
Les équipes d’accès sont un type particulier d’équipe qui ne peut pas posséder d’enregistrements, ni avoir d’association de rôles de sécurité. Cependant, tout comme les équipes propriétaires, les équipes d’accès peuvent partager des enregistrements entre elles. Lorsqu’elle sont activées au niveau de la table, les équipes d’accès peuvent accorder des autorisations de niveau d’enregistrement spécifiques au membre de l’équipe d’accès de l’enregistrement. Il s’agit d’une alternative au partage manuel de l’enregistrement avec un utilisateur ou une équipe. Pour les entités configurées pour les équipes d’accès, la création de ces équipes est automatisée au moyen de modèles d’équipe d’accès.
Lors de l’affectation d’un rôle de sécurité à une équipe propriétaire (y compris les équipes de groupes de sécurité Azure AD ou les équipes de groupes de bureau Microsoft Entra ID), le paramètre d’héritage des privilèges de son membre doit être vérifié pour s’assurer qu’il est correctement défini. Ce paramètre peut permettre aux utilisateurs membres de l’équipe d’hériter des privilèges de niveau utilisateur, comme si le rôle de sécurité leur avait été directement affecté. Cette fonction est utile pour permettre aux utilisateurs de posséder des enregistrements en leur nom, même s’ils ne disposent pas d’un rôle de sécurité directement affecté. Avec ce paramètre, les utilisateurs peuvent, par exemple, posséder des vues personnelles. Avec les équipes propriétaires, les rôles de sécurité n’ont pas besoin d’être affectés directement à des utilisateurs individuels, ce qui permet de réduire l’effort d’administration.
Sécurité de la hiérarchie
La sécurité de la hiérarchie peut être utilisée pour accorder la visibilité sur les enregistrements appartenant à l’utilisateur au niveau du responsable et aux niveaux supérieurs de la hiérarchie de cet utilisateur. Par exemple, un directeur des ventes avec une équipe de cinq personnes a besoin de voir les enregistrements appartenant à un membre de son équipe, la sécurité de la hiérarchie peut fournir cet accès. La sécurité de la hiérarchie prend en charge deux modèles de hiérarchie différents :
La hiérarchie du responsable accorde l’accès en fonction de la relation entre les responsables. Avec le modèle de sécurité de la hiérarchie de responsables, un responsable a accès aux enregistrements appartenant à l’utilisateur ou à l’équipe dont un utilisateur fait partie, et aux enregistrements qui sont directement partagés avec l’utilisateur ou l’équipe.
La hiérarchie de postes accorde un accès basé sur des niveaux de poste définissables. Ce modèle est utile lorsque l’accès de sécurité doit être fourni sur la base de structures de hiérarchie indirecte. Avec le modèle de sécurité de hiérarchie de postes, un responsable occupant un poste à un niveau supérieur a accès aux enregistrements appartenant à un utilisateur ou à l’équipe de niveau inférieur dont un utilisateur fait partie, et aux enregistrements qui sont directement partagés avec l’utilisateur ou l’équipe.
Sécurité de champ
La sécurité de champ vous permet de sécuriser les données au niveau des champs, dans les cas où certains utilisateurs ont besoin d’afficher ou de modifier un enregistrement mais sans voir de détails spécifiques. Cette fonctionnalité est importante dans les situations où les données doivent être véritablement sécurisées, car elles sont sécurisées au niveau de la plateforme. En d’autres termes, qu’un utilisateur se connecte à une application pilotée par modèle, à une application de canevas, qu’il exporte des données vers Microsoft Excel ou qu’il exécute un état, les profils de sécurité de champ sécurisent les données.
Une fois qu’un utilisateur détient un accès (par exemple, en lecture) à un ensemble de champs sécurisés au moyen d’un profil de sécurité de champ, il a accès à ces champs sur tous les enregistrements auxquels il a accès avec sa configuration de sécurité ou par partage.
Partage
Le partage permet d’accorder un accès au niveau de l’enregistrement spécifique à des utilisateurs et des équipes donnés. L’utilisation du partage doit être limitée à la gestion des exceptions, dans la mesure du possible. Auparavant, il était fréquent d’utiliser et d’automatiser le partage d’enregistrements pour des scénarios d’accès aux enregistrements complexes. Le partage peut être utile, car il donne aux administrateurs et aux utilisateurs les autorisations appropriées, la possibilité d’accorder des autorisations spécifiques à des enregistrements donnés, et il est utile pour gérer les exceptions à la règle. Supposons que vous deviez demander au Vendeur A de gérer les comptes du Vendeur B pendant son absence d’un mois, le partage peut vous aider dans cette tâche. Le partage peut également être automatisé, ce qui signifie que si vous avez besoin d’une condition spécifique pour partager automatiquement des enregistrements avec un utilisateur ou une équipe, vous pouvez utiliser des plugins simples, des assemblages de flux de travail ou des outils ETL. Cette fonctionnalité a permis à de nombreux clients Dynamics 365 de répondre à leurs besoins en matière de sécurité par le passé.
Bien que le partage soit une fonctionnalité utile, il engendre également plusieurs problèmes potentiels, notamment :
Performances : le partage est facilité par la table Principal Object Access (POA). Lorsque vous partagez un enregistrement avec un utilisateur ou une équipe, un enregistrement est créé dans la table POA contenant l’ID de l’utilisateur, l’ID de l’enregistrement et l’autorisation dont il doit disposer. La nature en cascade du partage signifie que s’il existe une relation parentale ou configurable en cascade pour laquelle le partage est activé, les enregistrements enfants de ces relations seront également partagés avec l’utilisateur ou l’équipe (et des enregistrements supplémentaires seront ajoutés à la table POA). Des scénarios de partage complexes ou hérités peuvent également créer des enregistrements, ce qui peut entraîner une augmentation rapide de la table POA. Des problèmes de performances surviennent lorsque la table s’agrandit (entre 20 millions et 2 milliards d’enregistrements). Lorsque vous interrogez Dynamics 365, par exemple lors de l’ouverture d’une vue, d’une recherche avancée ou de l’affichage d’un graphique, les résultats sont filtrés par la table POA. Si la table est volumineuse ou si les index ne sont pas optimisés, cela peut entraîner un ralentissement des performances système.
Défis administratifs : il est difficile d’identifier quels enregistrements sont partagés avec un utilisateur. Bien que vous puissiez sélectionner un enregistrement et montrer avec qui celui-ci est directement partagé, il n’existe pas de méthode pour vous aider à accomplir cette tâche pour tous les enregistrements. De plus, les partages en cascade ou hérités ne s’affichent pas dans la boîte de dialogue de partage de l’enregistrement. Si vous n’ouvrez pas chaque enregistrement dans le contexte de cet utilisateur, il est quasiment impossible de savoir si votre stratégie de partage fonctionne correctement.
Partages oubliés : un scénario a été précédemment abordé dans le cadre duquel vous partagiez les enregistrements du Vendeur B avec le Vendeur A, qui gérait les comptes de ses collègues pendant qu’ils étaient en congé pendant un mois. Il y a de fortes chances que l’administrateur oublie de mettre fin au partage de ces enregistrements, ce qui pourrait créer des problèmes si le Vendeur B devait se reconnecter avec les individus associés à son flux de travail.
Je n’arrive pas à faire les choses correctement : après avoir utilisé le système pendant un an ou deux, il peut décider que celui-ci manque de précision ou qu’il est trop ancien. Il peut également décider d’apporter une modification globale à sa stratégie de partage, et souhaiter effectuer un traitement par lots pour définir et mettre à jour tous les enregistrements avec l’autorisation de partage appropriée. Il n’existe aucune méthode simple pour effectuer cette tâche à l’aide du partage.
Alternatives au partage
Voici quelques mesures que vous pouvez prendre pour éviter les problèmes de partage :
Utilisez la propriété d’équipe : avec la propriété d’équipe, vous pouvez affecter des enregistrements à des équipes d’utilisateurs dans plusieurs centres de profit.
Partagez avec des équipes, et non avec des utilisateurs : si vous partagez un enregistrement avec 10 utilisateurs, 10 enregistrements POA sont créés, fois 10 enregistrements POA pour chaque enregistrement partagé en cascade enfant. Si vous partagez l’enregistrement avec une équipe de 10 utilisateurs, un seul enregistrement POA est créé (ainsi qu’un enregistrement POA pour chaque partage en cascade). Cette approche réduit considérablement la taille de votre table POA. Si vous souhaitez retirer les autorisations d’un utilisateur, vous pouvez le supprimer de l’équipe.
Utilisez des équipes d’accès pour un partage contrôlé : utilisez cette approche si vous ne parvenez pas à créer d’équipes propriétaires, mais que vous souhaitiez tout de même pouvoir accorder un accès ponctuel à des enregistrements spécifiques à des utilisateurs particuliers. Dans ce scénario, vous souhaitez autoriser certains utilisateurs à lire uniquement l’enregistrement, tandis que d’autres utilisateurs doivent pouvoir consulter et modifier l’enregistrement. Les équipes d’accès permettent de gérer une telle situation. Vous pouvez avoir plusieurs modèles d’équipe d’accès, un pour la lecture, un pour la lecture/écriture. Les équipes d’accès sont conçues dans une optique de performance : elles ne créent pas réellement l’équipe et ne partagent pas l’enregistrement tant que vous n’avez pas ajouté le premier membre de l’équipe. Lorsqu’un enregistrement est partagé avec une équipe d’accès, un autre enregistrement est également créé dans la table POA.
Exemple de scénario de sécurité
Le scénario suivant explique comment ces outils peuvent être combinés pour fournir un modèle de sécurité complet. Dans cet exemple, Contoso LTD est une société de produits de consommation qui souhaite s’assurer que les utilisateurs ont accès aux informations nécessaires pour faire leur travail tout en protégeant les données sensibles. En combinant les outils de sécurité dans Dynamics 365, l’entreprise peut aborder chacun des scénarios suivants.
Bob
La sécurité au niveau du terrain empêche Bob de voir des informations sensibles sur un enregistrement, et la sécurité de l’équipe ou du centre de profit limite sa vue aux problèmes de sa société.
Ingénieur de fabrication
Doit être en mesure de voir les problèmes de qualité signalés par les clients
Ne doit pas pouvoir voir l’e-mail ni le numéro de téléphone mobile du client
Ne doit pas voir les problèmes d’autres entreprises
Amy
La sécurité du centre de profit signifie qu’Amy peut voir les enregistrements appartenant à quelqu’un d’autre dans la division, mais elle ne peut pas voir ni modifier les enregistrements dans d’autres divisions.
Conseiller du service clientèle
Crée des incidents de service clientèle à partir de plaintes d’utilisation
Doit être en mesure de voir les informations client et l’historique des incidents des clients qui utilisent les produits de sa division
Ne doit pas voir les données des clients d’autres divisions
Roy
La sécurité de hiérarchie permet à Roy de voir les enregistrements appartenant à ses subordonnés directs ou indirects, mais pas aux autres utilisateurs.
Directeur commercial
A besoin de voir les enregistrements de ses subordonnés directs
Ne doit pas voir les données des autres directeurs commerciaux
Linda
Le rôle de sécurité de Linda lui donne une visibilité au niveau de l’organisation des données contenues dans Dynamics 365.
Directeur général
A besoin de visibilité pour toutes les données client et les problèmes associés
Atelier Modèle de sécurité
L’atelier Modèle de sécurité doit être limité à environ une heure et se déroule souvent dans le cadre d’une réunion Microsoft Teams si tous les participants ne se trouvent pas au même endroit. Les participants doivent comprendre les principales parties prenantes des équipes client et partenaire. La participation des architectes de solutions et des responsables fonctionnels et techniques est obligatoire.
Les détails de sécurité du modèle de l’atelier Blueprint de la solution doivent être ajoutés aux références en préparation de l’atelier Modèle de sécurité.