Sujets de l’atelier Modèle de sécurité
Cette unité se concentre sur les sujets recommandés qui doivent être abordés dans l’atelier Modèle de sécurité.
Présentation du modèle de sécurité
Dans le=a section Présentation du modèle de sécurité du modèle, vous devez fournir une présentation générale du modèle de sécurité aux participants. Les informations n’ont pas besoin d’être extrêmement granulaires, car nous allons discuter en détail de chaque aspect spécifique ultérieurement dans le modèle.
Ensuite, indiquez comment vous gérez l’accès aux enregistrements. Ceci est utile pour savoir s’il existe des restrictions spécifiques sur les données (par exemple, les vendeurs sont autorisés à consulter uniquement leurs propres données client) ou toute autre information d’accès aux données spéciale qui impacte le modèle de sécurité. En outre, cette section peut inclure des informations techniques, par exemple si l’authentification multifacteur est requise pour accéder aux données du système.
Notions de base
Le modèle contient deux diapositives qui couvrent des informations de base sur le modèle de sécurité. Les questions suivantes figurent sur ces diapositives :
Combien d’utilisateurs comptez-vous (cible) ? - Le nombre d’utilisateurs a un fort impact sur l’évolutivité de votre modèle de sécurité. Par exemple, si le client s’appuie sur le partage d’enregistrements pour fournir l’accès, il doit avoir connaissance de l’impact potentiel sur les performances lorsque de nombreux enregistrements sont partagés entre de nombreux utilisateurs. Certains modèles de sécurité acceptables pour un petit nombre d’utilisateurs deviennent inadaptés à mesure que ce nombre augmente. Voilà pourquoi il est important de prendre en compte la croissance actuelle et future prévue du nombre d’utilisateurs.
De combien de modèles de sécurité ou configurations distinct(e)s disposez-vous dans votre modèle et combien d’utilisateurs y a-t-il dans chaque configuration de modèle ? - Par modèle de sécurité, nous entendons les différentes configurations de sécurité que le client souhaite implémenter pour répondre aux besoins. Par exemple, les membres du département commercial recourent à l’utilisation standard des rôles de sécurité utilisateur, les membres du service clientèle utilisent une combinaison de rôles utilisateur et de hiérarchie du responsable, et le département marketing utilise uniquement des équipes d’accès. En déterminant le nombre de modèles prévu, vous allez identifier si le modèle de sécurité est trop compliqué ou difficile à gérer à long terme.
Quel pourcentage d’utilisateurs présente potentiellement des besoins de sécurité plus complexes que les autres ? - Les clients compliquent parfois excessivement leur modèle de sécurité en le concevant autour d’exceptions de niche au processus standard. Lorsque vous identifiez de nombreux besoins non standard différents, vous devez remettre en question le besoin et recommander une standardisation du processus principal.
Devez-vous restreindre ou filtrer l’accès aux données ? - Cette question distingue les filtres de commodité et les besoins de sécurité réels. Souhaiter fournir aux utilisateurs une vue simplifiée des données qui comptent le plus pour eux est un bon objectif ; cependant, la sécurité ne doit pas servir à atteindre cet objectif. Utilisez des vues pour filtrer les données, tout en permettant d’accéder à d’autres enregistrements.
De combien de rôles de sécurité avez-vous besoin ? - Réduire au maximum le nombre de rôles de sécurité facilite la gestion des tâches administratives. Dynamics 365 offre de nombreux rôles de sécurité standard pour les types d’utilisateurs standard tels que responsable commercial, conseiller du service clientèle et administrateur système. Ces rôles doivent servir de base pour les rôles de sécurité du client.
Si les besoins diffèrent des rôles standard, envisagez de créer des copies des rôles standard et d’effectuer une itération à partir de ceux-ci.
Avez-vous créé des rôles de sécurité au lieu de personnaliser les rôles existants ? - Une bonne pratique recommandée consiste à enregistrer une copie de l’un des rôles de sécurité standard au lieu d’en créer un.
Les rôles de sécurité comprennent de nombreuses autorisations requises pour accéder à l’application, et le fait de créer un rôle est problématique, car le client ne va probablement pas disposer de toutes les autorisations de base nécessaires.
Rappelez au client que souvent, de nouvelles autorisations sont ajoutées aux rôles de sécurité standard à l’aide de mises à jour d’application régulières et que ces autorisations ne sont pas ajoutées automatiquement aux rôles de sécurité personnalisés existants. Si des rôles de sécurité personnalisés sont utilisés, quelqu’un doit se charger d’identifier les autorisations nouvellement ajoutées et de mettre à jour les rôles de sécurité personnalisés après chaque mise à jour, afin d’assurer la continuité de l’accès au système.
Avez-vous tenté de réduire autant que possible le nombre de rôles de sécurité ? - Plus un déploiement Dynamics 365 utilise de rôles de sécurité, plus il est difficile à administrer à long terme. Lorsqu’une nouvelle fonctionnalité est ajoutée, s’il existe 25 rôles de sécurité distincts et que la fonctionnalité est requise par tout le monde, le créateur doit mettre à jour ces 25 rôles pour donner accès à la nouvelle fonctionnalité.
Une stratégie répandue consiste à utiliser un rôle de base, qui fournit la base de fonctionnalités nécessaires pour se connecter à l’application et à toutes les tables à la disposition de tous les utilisateurs. Ensuite, ajoutez le rôle comportant des rôles supplémentaires avec les fonctionnalités requises dédiées à chaque rôle.
Par exemple, si tous les utilisateurs doivent consulter des comptes, mais que seuls les responsables commerciaux doivent être en mesure d’en créer, votre rôle de base contient une autorisation de lecture des comptes au niveau de l’organisation et le rôle de responsable commercial comprend uniquement l’autorisation de création de comptes. Ensuite, si une nouvelle fonctionnalité dont tous les utilisateurs ont besoin est ajoutée, elle ne peut l’être qu’au rôle de base.
Quel est le nombre de rôles de sécurité dont un individu a besoin ? - Plus il y a de rôles de sécurité à ajouter à un utilisateur individuel, plus l’intégration utilisateur est compliquée et plus quelqu’un est susceptible de commettre des erreurs. Si de nombreux rôles existent, ils doivent être consolidés pour faciliter l’administration continue.
Une autre approche utile ici consiste à utiliser des équipes du groupe de sécurité Microsoft Entra ID ou du groupe de bureau Microsoft Entra ID, afin de pouvoir affecter les rôles une fois à l’équipe. Ensuite, les utilisateurs héritent automatiquement des rôles de l’équipe (donc dans le contexte du centre de profit de l’équipe), après avoir été ajoutés au groupe Microsoft Entra ID approprié.
Les rôles de sécurité sont-ils créés au niveau du centre de profit racine ou enfant ? - Bien que vous puissiez créer des rôles dédiés à un centre de profit enfant, nous vous recommandons de créer et de modifier les rôles de sécurité au niveau du centre de profit racine.
La création de rôles au niveau du centre de profit racine permet de les mettre à disposition de tous les centres de profit, tandis que les rôles créés au niveau du centre de profit enfant sont à la disposition d’un seul centre de profit. Si vous disposez d’un rôle dédié à un centre de profit, lorsque vous déplacez un utilisateur vers un autre centre de profit, ce rôle n’est plus disponible. Sinon, vous vous retrouvez avec différentes versions du même rôle dans un autre centre de profit, ce qui complique l’administration du système.
Quelle est votre stratégie de mise à jour des rôles de sécurité lorsque vous déployez de nouvelles tables et fonctionnalités ? - Dans un environnement en évolution rapide avec un développement continu, il peut être facile d’oublier de mettre à jour les rôles ou d’effectuer des tests uniquement avec un accès administrateur système et de manquer la mise à jour des rôles de sécurité pour inclure la nouvelle fonctionnalité. La stratégie du client doit inclure un processus de mise à jour des rôles de sécurité et de test avec la combinaison de rôles de chaque personnage, chaque fois qu’une nouvelle version de configuration est déployée.
Pourquoi nous demandons ces informations
Voici les raisons pour lesquelles vous devriez demander les informations susmentionnées à vos participants :
Un modèle de sécurité est rarement adapté à tous les besoins et rôles utilisateur. Vous devez connaître le nombre de modèles différents que vous allez devoir implémenter dans le cadre du projet.
Des modèles de sécurité complexes sont souvent conçus pour répondre aux besoins d’une fraction d’utilisateurs qui ne font pas partie du modèle principal. Dans ce cas, il pourrait exister une opportunité de remettre en question, le cas échéant, l’impossibilité pour ces utilisateurs d’accéder aux données souhaitées d’une autre manière ou ailleurs, par exemple au moyen du reporting.
Centres de profit
Dans cette section, fournirez une description de la structure hiérarchique de l’organisation interne du client et du centre de profit dans Dynamics 365. Certaines relations doivent exister entre la structure du centre de profit et celle de l’organisation, mais la structure du centre de profit ne doit pas être aussi granulaire que celle de l’organisation. Cependant, le fait que deux groupes appartiennent à des divisions différentes de la société ne signifie pas que vous devez restreindre la visibilité des enregistrements entre les deux groupes. Plusieurs départements peuvent souvent partager le même centre de profit.
Utilisez un outil tel que Microsoft Visio ou une autre application de création de schémas/graphiques visuels pour créer une représentation visuelle de la structure. Si vous disposez déjà d’un document qui représente la hiérarchie organisationnelle de la société, vous pouvez coller une capture d’écran de ce schéma dans le document.
Prêtez attention à deux problèmes potentiels : trop de centres de profit ou pas suffisamment de centres de profit.
Trop de centres de profit
Si le modèle de sécurité proposé identifie entraîne la création de centaines ou de milliers de centres de profit, ce problème doit être signalé comme un risque. Les centres de profit s’apparentent à de grands rochers de granit ; ils sont conçus pour être permanents et rarement déplacés. Bien que les utilisateurs puissent être déplacés entre les centres de profit, il ne s’agit pas d’une opération triviale, surtout s’ils possèdent de nombreux enregistrements.
Lorsque vous déplacez un utilisateur du centre de profit 1 vers le centre de profit 2, le centre de profit associé à chaque enregistrement dont l’utilisateur est propriétaire est modifié. Ce facteur peut causer des surprises aux autres utilisateurs membres du centre de profit d’origine de l’utilisateur, s’ils disposent d’une autorisation de lecture au niveau du centre de profit. Les enregistrements appartenant à l’utilisateur déplacé ne sont plus à sa disposition, mais s’il possède des enregistrements enfants de ces enregistrements, comme des activités, cela peut provoquer des scénarios étranges. En outre, si l’utilisateur possède de nombreux enregistrements, son déplacement entre des centres de profit peut prendre du temps.
Les mises à jour extrêmement lentes des rôles de sécurité sont une autre conséquence potentielle de nombreux centres de profit. Chaque rôle ne se résume pas à un seul enregistrement. Une copie de chaque rôle est ajoutée à chaque centre de profit. Par conséquent, si vous créez des milliers de centres de profit, apporter une légère modification à un rôle de sécurité peut prendre des heures.
Une bonne pratique consiste à réduire au maximum le nombre de vos centres de profit. Utilisez-en uniquement le minimum pour répondre aux véritables besoins de sécurité des centres de profit. Pour une segmentation utilisateur plus granulaire, envisagez de recourir à des équipes. Bien plus flexibles, les équipes permettent de contrôler l’accès sécurisé aux enregistrements et les utilisateurs peuvent être membres de plusieurs équipes.
Pas suffisamment de centres de profit
En cas d’implémentation pour un seul groupe, il est courant de souhaiter utiliser uniquement le centre de profit racine pour tous les utilisateurs.
Bien que l’approche « Faire dans la simplicité » soit excellente, il est fort possible que le client puisse, à un moment donné, disposer de certaines données qu’il ne souhaite pas divulguer à un sous-ensemble d’utilisateurs.
Envisageons les scénarios suivants :
Vous étendez l’utilisation de Dynamics 365 à d’autres parties de la société.
Votre société est rachetée par une grande multinationale.
Le PDG décide de suivre les e-mails et ne souhaite pas que tout le monde les lise.
Le vice-président chargé des ventes découvre que plusieurs contacts de son carnet d’adresses doivent résider dans Dynamics 365, mais qu’il vaut mieux ne pas les divulguer au reste de la société.
Déplacer des personnes entre des centres de profit est fastidieux et il s’agit d’un processus à mettre en œuvre seulement lorsque cela est nécessaire. Si le client commence avec tous les utilisateurs dans le centre de profit de base, en cas de changement nécessitant l’isolement d’un sous-ensemble de données, il doit déplacer nombre ou la totalité des utilisateurs existants, car le centre de profit racine ne peut être apparenté à nouveau.
Pour se prémunir contre cette éventualité, il peut être judicieux de créer initialement un centre de profit enfant et d’y placer tous les utilisateurs. Si des changements métier exigent une segmentation supplémentaire des données, cette approche simplifie ces changements, car le centre de profit avec la majorité des utilisateurs peut être apparenté à nouveau ou certains utilisateurs tels que le PDG peuvent être déplacés vers le centre de profit de base. Un déplacement à grande échelle de tous les utilisateurs vers un centre de profit peut être évité.
Équipes
La section Équipes du modèle de sécurité fournit les informations concernant l’utilisation prévue des enregistrements d’équipe pour la sécurité dans Dynamics 365.
Dans cette section, vous répondrez aux questions suivantes :
Utilisez-vous des équipes propriétaires pour affecter des rôles aux utilisateurs ? - Les équipes propriétaires (notamment les équipes du groupe de sécurité Microsoft Entra ID et du groupe de bureau Microsoft Entra ID) sont un excellent moyen d’affecter des rôles de sécurité aux utilisateurs et de réduire les tâches administratives. Lorsqu’un rôle de sécurité est affecté à une équipe, il est hérité par les utilisateurs membres, mais s’applique à l’étendue du centre de profit de l’équipe.
Utilisez-vous des équipes propriétaires pour gérer la propriété des enregistrements ? - L’utilisation de la propriété des enregistrements par des équipes peut être envisagée pour gérer l’association d’un enregistrement à un centre de profit séparément du centre de profit de l’utilisateur propriétaire par ailleurs standard. Cette approche peut être utile lorsque l’association fonctionnelle de l’enregistrement et d’un centre de profit diffère de l’association de l’utilisateur à un centre de profit.
Vous devez avoir connaissance de certains inconvénients et risques associés à la propriété des enregistrements par des équipes. Généralement, elle doit être automatisée pour être cohérente et conviviale. Certaines fonctionnalités telles que les objectifs et les prévisions dépendent de la propriété utilisateur des enregistrements. En outre, les équipes propriétaires ne peuvent pas réaffecter les enregistrements d’un utilisateur en bloc (par exemple lorsqu’un nouveau vendeur remplace un autre ayant pris sa retraite et hérite de son portefeuille de clients).
La propriété des enregistrements par des équipes permet de simplifier les modèles de sécurité complexes et de réduire le besoin de partage excessif d’enregistrements. Les rôles d’équipe propriétaire accordent des autorisations de sécurité spéciales dans le contexte des enregistrements appartenant à l’équipe. Par conséquent, si les membres d’une équipe commerciale doivent disposer d’un droit de modification des opportunités auxquelles ils sont associés, mais d’un accès en lecture seule pour les opportunités auxquelles ils ne sont pas associés, les équipes de sécurité propriétaires peuvent activer cette exception sans avoir à utiliser un partage complexe.
Automatisez-vous l’affectation des enregistrements et si oui, comment ? - Lors de la création d’un compte, vous devez déterminer comment l’enregistrement sera assigné. En outre, vous devez déterminer si le coordinateur commercial se souviendra d’affecter correctement l’enregistrement manuellement. Pour les types d’enregistrements importants tels que les comptes, nous vous recommandons de disposer d’un processus automatisé qui affecte automatiquement les enregistrements lors de leur création afin de simplifier l’administration continue du système. Une approche peut consister à stocker l’affectation des vendeurs par département sur l’enregistrement de secteur de vente dans Dynamics 365. Ensuite, lors de la création d’un compte, un flux Microsoft Power Automate s’exécute. Celui-ci compare l’état du champ Adresse 1 au champ Département du secteur de vente, puis affecte le compte au secteur de vente et au vendeur appropriés. Ensuite, il envoie un e-mail de notification au vendeur pour lui demander de contacter son nouveau client potentiel.
Utilisez-vous des équipes d’accès (gérées par le système ou manuellement) ? - Les équipes d’accès sont une excellente solution pour gérer des autorisations d’enregistrement spécifiques. Par exemple, si un assistant commercial doit disposer d’autorisations de modification sur 25 comptes différents, au lieu de partager les comptes manuellement avec lui, vous pouvez les ajouter à une sous-grille d’équipe d’accès sur l’enregistrement. Il hérite alors des autorisations de modification sur la base du modèle d’équipe d’accès associé à la grille. Les équipes d’accès sont une excellente solution, car un seul enregistrement de partage pour l’ensemble d’une équipe d’accès est créé dans la table POA, plutôt que des enregistrements individuels pour chaque personne, comme le fait le partage d’enregistrements (voir la section Partage plus haut dans ce module). Cette approche permet également aux administrateurs de voir qui a accès à l’enregistrement.
Si le même groupe d’individus doit accéder à plusieurs enregistrements, les équipes d’accès peuvent également être utilisées pour partager les enregistrements avec cette équipe. Cependant, n’oubliez pas qu’une équipe d’accès ne peut ni posséder des enregistrements, ni se voir affecter des rôles de sécurité.
Automatisez-vous l’appartenance à une équipe d’accès ? - Souvent, une matrice de personnes doit accéder à des enregistrements. Par exemple, un projet de fabrication nécessite un ingénieur, un électricien et un ingénieur en sécurité. Ces affectations sont souvent gérées dans un autre système.
Dans ce cas, une équipe d’accès doit être utilisée, car la combinaison d’individus diffère selon chaque enregistrement et un accès sécurisé est nécessaire pour les membres de l’équipe. Vous pouvez automatiser l’appartenance à l’équipe d’accès à l’aide d’approches telles que l’intégration, les actions ou les plug-ins.
Comment déployez-vous les modèles d’équipe d’accès dans les environnements ? - Les autorisations d’enregistrement d’une équipe d’accès sont établies par un modèle d’équipe d’accès. Le modèle détermine les autorisations partagées avec les membres de l’équipe.
L’un des défis est que les enregistrements de modèle d’équipe d’accès ne sont pas compatibles avec les solutions. Autrement dit, ils ne peuvent pas être ajoutés à des solutions. Lorsque des personnalisations sont déplacées entre des environnements, le modèle d’équipe d’accès doit être transféré ou recréé manuellement dans l’environnement cible. Si vous automatisez l’appartenance à une équipe d’accès, les modèles doivent disposer de GUID identiques dans tous les environnements, car ils sont référencés dans votre logique.
Plusieurs approches vous permettent de migrer les modèles d’équipe d’accès, notamment l’utilitaire de migration des données de configuration, des outils ETL comme Scribe ou SSIS, ou des utilitaires XrmToolBox.
Gérez-vous les droits d’accès à l’aide des groupes synchronisés Microsoft Entra ID ? - Les équipes du groupe de sécurité Microsoft Entra ID ou du groupe de bureau Microsoft Entra ID sont un excellent choix pour automatiser l’affectation d’autorisations de rôle aux utilisateurs et leur utilisation doit être envisagée pour les déploiements plus importants ou plus complexes.
Grâce à Microsoft Entra ID, les autorisations peuvent être entièrement contrôlées à partir d’une seule source.
Avez-vous des besoins auxquels ne répond pas le modèle standard ? - Identifiez les besoins de sécurité non standard. Dans la section sur les conclusions et les recommandations, recommandez des approches pour standardiser les besoins non standard.
Mécanismes de sécurité implémentés
Dans cette section, vous identifierez les méthodes permettant d’automatiser la sécurité, notamment le partage automatisé, la sécurité au niveau du champ, la sécurité hiérarchique, les plug-ins et les comportements relationnels. Consultez la section Outils de sécurité de ce module si vous ne connaissez pas l’une de ces approches.
Pourquoi nous demandons ces informations :
Des problèmes de performances peuvent se produire si vous automatiser le partage à l’échelle. La table PrincipalObjectAccess ou POA est renseignée avec des exceptions au modèle de sécurité standard.
Le partage doit généralement rester un processus manuel pour accorder des exceptions au modèle de sécurité en place et doit être évité à grande échelle.
Bien qu’il soit facile d’ajuster le centre de profit, les équipes et les rôles de l’utilisateur, il peut être complexe d’effectuer une migration des données sur des règles de partage personnalisées après une réorganisation.
La sécurité au niveau du champ ne prend en compte ni l’utilisateur, ni le centre de profit.
La sécurité hiérarchique peut entraîner des problèmes de performance dans les configurations complexes en cas de niveaux trop nombreux dans la profondeur de la hiérarchie.
Le comportement en cascade dans les relations est pratique, mais il peut parfois avoir des conséquences inattendues (telles que la réaffectation des activités fermées lorsqu’un compte est réaffecté). L’affectation ou le partage en cascade peut être désactivé(e) ou modifié(e) par relation, ou à l’aide d’un paramètre ORG DB DisableImplicitSharingOfCommunicationActivities.
Interface utilisateur
De nombreux composants de Dynamics 365 sont compatibles avec les rôles de sécurité. Autrement dit, l’accès à ces éléments peut être limité à un ou plusieurs rôles de sécurité. Cette fonction est importante, car différents utilisateurs nécessitent différentes expériences tout en utilisant des tables communes. En limitant l’accès aux composants d’application non nécessaires aux utilisateurs, vous offrez une expérience utilisateur simplifiée et plus personnalisée.
Les éléments de Dynamics 365 compatibles avec les rôles de sécurité comprennent les suivants :
Applications pilotées par modèle
Tableaux de bord
Formulaires
Flux de processus métier
Sous-zones de plan de site
Boutons de la barre de commandes
Modèles de document
Dans cette section du modèle, vous identifierez si des rôles permettent de simplifier l’accès à ces zones.
Pourquoi nous demandons ces informations :
Les rôles de sécurité et les privilèges de table permettent de personnaliser et simplifier l’expérience de vos utilisateurs.
Moins les utilisateurs voient d’éléments, plus l’expérience est simplifiée.
Les applications pilotées par modèle peuvent être associées à des rôles de sécurité et contribuent à simplifier l’expérience utilisateur globale en réduisant la liste des vues, des graphiques, des tableaux de bord, des formulaires et des flux de processus métier.
Les clients sans stratégie dans ce domaine peuvent rencontrer des problèmes inattendus. Par exemple, les applications Microsoft courantes telles que le Centre des ventes, le Concentrateur du service clientèle et App for Outlook contrôlent l’accès à l’aide des rôles de sécurité d’accès aux applications. Si un client effectue un test uniquement avec un rôle Administrateur système, il peut oublier le fait que les utilisateurs sans ce rôle ont besoin du rôle d’accès à l’application pour l’utiliser (ou elle doit être partagée avec leurs rôles de sécurité personnalisés). Ce scénario peut empêcher les utilisateurs d’accéder aux applications dont ils ont besoin lors du déploiement.
Évolutivité, performances et maintenabilité
Dans cette section du modèle, vous allez étudier des questions qui permettent d’identifier tout problème potentiel susceptible de survenir lorsque l’application est étendue à des utilisateurs supplémentaires et que le volume de données augmente.
Questions de maintenance et raisons de leur importance
Répondez aux questions de maintenance suivantes dans le modèle :
Avez-vous identifié des scénarios où il n’est pas nécessaire que l’enregistrement appartienne à un utilisateur ou une équipe ? - Lors de la création de tables représentant des données référentielles intersociétés n’ayant jamais besoin de granularité par centre de profit, équipe ou utilisateur, envisagez de les créer en tant que tables appartenant à l’organisation.
La propriété des enregistrements est importante lorsque vous devez accorder une visibilité variable ou des autorisations de modification à différents utilisateurs. Cependant, si des enregistrements généraux doivent être visibles par tous les utilisateurs et que ces derniers partagent tous le même niveau d’autorisation en matière de modifications (comme les enregistrements générés à l’aide d’une intégration), une stratégie telle que l’affectation d’enregistrements à l’équipe du centre de profit doit être envisagée, afin que ces enregistrements n’aient pas besoin d’être réaffectés lorsque quelqu’un quitte la société.
Avez-vous identifié un problème d’évolutivité potentiel dans la conception de votre sécurité à des volumes plus élevés ? - Les stratégies telles que le partage d’enregistrements peuvent fonctionner correctement en cas de déploiement modeste, mais deviennent rapidement inefficaces lorsqu’elles sont étendues à de nombreux utilisateurs.
De plus, disposer d’utilisateurs membres de milliers d’équipes dans des milliers de centres de profit peut être un défi en matière de performances et d’évolutivité.
Avez-vous envisagé l’impact de vos données et de vos modèles de sécurité sur la table POA ? - Un partage excessif conduit à une table POA volumineuse et peut dégrader les performances du système.
Mettez-vous régulièrement à jour les enregistrements des utilisateurs, des équipes ou des centres de profit ? - En général, les mises à jour régulières des tables d’utilisateur, d’équipe ou de centre de profit doivent être évitées. Par exemple, la mise à jour d’un attribut sur une table utilisateur peut entraîner le vidage du cache de sécurité et potentiellement impacter les performances.
Avez-vous envisagé l’impact d’une réorganisation d’envergure sur les utilisateurs, les équipes, les centres de profit et les enregistrements ? - Les structures d’entreprise évoluent. De nouvelles sociétés sont rachetées, des divisions sont cédées et des collaborateurs quittent la société ou sont mutés dans d’autres départements. Votre structure doit être suffisamment flexible afin que vous puissiez facilement ajouter ou supprimer des utilisateurs, des équipes ou des centres de profit, sans nécessiter une refonte complète du modèle de sécurité.
Pour les utilisateurs ayant déjà accès à un grand pourcentage des enregistrements, avez-vous envisagé de leur fournir un accès global pour améliorer les performances ? - Fournir un accès en lecture organisationnel/global aux enregistrements peut optimiser les performances pour l’implémentation d’une vue, car le système n’est pas tenu de prendre en compte les principes de sécurité qui s’appliquent à un utilisateur (rôles individuels, rôles d’équipe, enregistrements partagés, hiérarchie) lors de l’extraction d’enregistrements.
Bien qu’un utilisateur puisse avoir accès à tous les enregistrements du point de vue de la sécurité, vous devez personnaliser les vues système qui filtrent le nombre d’enregistrements pour présenter uniquement ceux qui sont pertinents pour leur travail.
Réaffectez-vous des enregistrements en bloc en cas de départ d’un utilisateur ? Avez-vous envisagé l’impact d’une relation en cascade ? - Les paramètres de relation en cascade pour les activités et d’autres enregistrements communs peuvent entraîner des résultats inattendus lors de la réaffectation des enregistrements. Ce comportement doit être modifié si vous ne souhaitez pas que les activités fermées soient réaffectées lorsque vous réaffectez des enregistrements de compte client et de contact.
Tests de sécurité
Le modèle de sécurité se compose de plusieurs éléments œuvrant de concert et il peut échouer dans plusieurs domaines. Dans cette section du modèle, vous examinerez l’approche adoptée pour tester la sécurité, identifier le plan continu de surveillance de l’accès à Dynamics 365 et nous assurer que la conception des rôles de sécurité est bien documentée et simple à maintenir à long terme.
Questions de sécurité et raisons de leur importance
Dans la section Tests de sécurité du Modèle de sécurité, répondez aux questions suivantes :
Disposez-vous d’environnements de test pour valider les données dans le contexte de vos besoins de sécurité ? - Pour tester correctement les rôles de sécurité, votre client a besoin d’un environnement hors production avec la même configuration que l’environnement de production et un jeu de données très semblable à celui de l’environnement de production. Bien que vous n’ayez pas besoin de l’intégralité des données issues de l’environnement de production, les données doivent être suffisamment similaires pour tester avec précision le comportement des rôles de sécurité. Il est également important de disposer d’utilisateurs de test distincts et de ne pas réaffecter des rôles aux mêmes utilisateurs de test. En effet, les utilisateurs disposant initialement d’autorisations supérieures peuvent conserver l’accès à certains enregistrements lorsque le rôle concerné est supprimé à l’aide de la propriété ou du partage d’enregistrements.
Disposez-vous de la feuille Excel de la matrice de sécurité avec des niveaux d’accès et des privilèges définis par votre entreprise ou votre client ? Il est important de disposer d’une documentation sur la conception de la sécurité en dehors du rôle de sécurité Dynamics 365, si quelqu’un apporte une modification au rôle de sécurité dans Dynamics et que vous souhaitez vous rappeler comment il a été conçu. Il peut s’agir d’une feuille de calcul Excel indiquant le niveau d’autorisation approprié par table.
Disposez-vous de cas de test autour de la matrice de sécurité pour tous les rôles de sécurité ? - Les besoins de sécurité du client sont probablement issus des besoins recueillis lors des ateliers précédents du projet. Ils constituent la base des cas de test de sécurité. Chaque restriction de sécurité doit faire l’objet d’un cas de test et être testée en profondeur avant sa mise en service. Les restrictions doivent ensuite être testées dans le contexte de chaque rôle de sécurité ou personnage concerné.
Avez-vous envisagé des tests négatifs sur la sécurité au niveau du champ et les équipes ? - Il est important de tester si une personne ayant un rôle peut voir les champs sécurisés et accéder aux enregistrements affectés à son équipe. De plus, il convient de vérifier que les utilisateurs ne disposant pas de ces rôles ou de ces affectations d’équipe ne peuvent pas accéder à ces éléments.
Allez-vous effectuer des tests d’intrusion sur la plateforme ? - Pour les environnements hautement sécurisés, les tests d’intrusion sont une option. Gardez à l’esprit que les tests d’intrusion doivent suivre les règles d’engagement de Microsoft Cloud relatives aux tests d’intrusion. Pour en savoir plus, consultez Règles d’engagement relatives aux tests d’intrusion.
Autres questions de sécurité Dynamics 365
Dans cette section du modèle de l’atelier Modèle de sécurité, vous examinerez la sécurité concernant les fonctions associées dans Dynamics 365.
Questions de sécurité Dynamics 365 et raisons de leur importance
Répondez aux questions suivantes :
Avez-vous envisagé d’utiliser le privilège Exporter vers Excel ? - Exporter vers Excel est une fonctionnalité très pratique, notamment pour le reporting, mais son utilisation peut également présenter un risque, car elle a déjà permis à des collaborateurs de certains clients d’emporter des données client avec eux lors de leur départ.
Il est important de faire preuve de prudence et d’être conscient que si le privilège Exporter vers Excel peut empêcher certains utilisateurs de télécharger facilement des données depuis Dynamics 365 avec le bouton Exporter vers Excel, quiconque disposant d’un accès en lecture à un enregistrement peut accéder à ces données au moyen d’API et finir par les exporter.
Le cas échéant, comment prévoyez-vous de contrôler la sécurité dans le service d’exportation de données, Azure SQL, le service d’exportation vers Data Lake et Power BI ? - Lorsque des données quittent Microsoft Dataverse à des fins de reporting ou d’intégration, elles ne sont plus protégées par la sécurité Dynamics 365. Les organisations doivent en tenir compte de ce paramètre et planifier la sécurité une fois que les données quittent le système.
Le cas échéant, quelle est votre stratégie de modèle de sécurité pour Power Pages et Unified Service Desk ? - Power Pages vous aide à exposer des données en externe et permet également à des parties externes de mettre à jour les données Dynamics 365. Cependant, il est important d’envisager les conséquences de leur utilisation en matière de sécurité et de s’assurer que les données sécurisées et sensibles ne tombent pas entre de mauvaises mains.
Si vos utilisateurs héritent de leurs rôles de sécurité exclusivement des équipes, avez-vous envisagé d’utiliser l’héritage pour diriger les paramètres utilisateur sur les rôles de sécurité ? Lors de l’affectation d’un rôle de sécurité à une équipe propriétaire (y compris les équipes de groupes de sécurité Microsoft Entra ID ou les équipes de groupes de bureau Azure AD), 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 (et non de niveau centre de profit ou supérieur), comme si le rôle de sécurité leur avait été directement affecté.
Ceci 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.
Si vous prévoyez d’utiliser des tables virtuelles, avez-vous envisagé de créer un modèle de sécurité autour d’elles ? - Les tables virtuelles permettent de créer des tables qui ne stockent pas de données dans Dataverse, mais pointent plutôt vers une source de données externe. Bien que cela soit pratique et, dans de nombreux cas, préférable à la surcharge de Dynamics 365 avec des données, vous devez comprendre qu’une connexion de table virtuelle utilise une seule source de données. Autrement dit, tous les utilisateurs ayant accès à la table virtuelle voient les mêmes enregistrements. En cas d’enregistrements sensibles ne devant pas être visibles par tous les utilisateurs, l’intégration des données est recommandée.
Surveillance de la sécurité
Dans cette section du modèle, vous allez passer en revue la stratégie du client pour surveiller les droits d’accès appropriés et identifier les usages abusifs de l’application. Si les audits d’activité sont activés dans Dynamics 365, de nombreuses activités utilisateur sont enregistrées dans le Centre d’administration Microsoft 365. À l’aide de ces journaux, vous pouvez identifier une activité inhabituelle ou potentiellement malveillante dans le système, y compris des actions courantes telles que les suivantes :
Qui a publié des personnalisations
Qui a été ajouté à une équipe
Qui a ajouté une solution
Qui a publié des personnalisations
Qui a effectué une exportation vers Excel
Qui a consulté un état
Qui a exporté un état
Les journaux d’audit standard surveillent le moment où les utilisateurs accèdent au système. Des outils tels que Microsoft Power Automate peuvent vous avertir de la survenue de certaines activités, et Microsoft Entra ID peut vous informer des tentatives d’accès au système par des personnes se trouvant en dehors des zones géographiques habituelles.
Dans cette section du modèle de l’atelier Modèle de sécurité, vous allez résumer la stratégie de surveillance et de signalement des comportements anormaux et les plans de vérification régulière des autorisations utilisateur dans Dynamics 365.
Réglementations et conformité
Dans cette section du modèle, vous allez identifier les réglementations gouvernementales ou relatives à la conformité en vigueur, qui peuvent avoir un impact sur le modèle de sécurité pour Dynamics 365. Ces réglementations incluent celles relatives à la protection des données des consommateurs telles que la loi américaine HIPAA, et les préoccupations de la SEC et des auditeurs telles que la segmentation métier. Renseignez les informations de la diapositive sur les réglementations et la conformité.
Sécurité au-delà de Dynamics 365
Dans cette section du modèle, vous examinerez des systèmes autres que Dynamics qui s’intègrent à Dynamics 365 et à la sécurité associée. Dynamics 365 n’est pas autonome ; d’autres systèmes interagissent avec ce dernier, ou y sont intégrés. Il est donc important d’adopter une vision holistique de la sécurité, et non uniquement de la sécurité d’éléments individuels. Mettez à jour les diapositives Sécurité au-delà de Dynamics 365 pour répondre aux questions suivantes :
Avez-vous associé vos environnements à un groupe de sécurité pour contrôler les utilisateurs qui y ont accès ? - L’association d’un environnement Dynamics 365 à un groupe de sécurité Microsoft Entra ID permettra de limiter l’accès à l’environnement pour les utilisateurs en dehors du groupe, ainsi que le nombre d’utilisateurs s’affichant comme activés dans le système. Elle simplifie également l’expérience des utilisateurs, car seuls les environnements auxquels ils ont accès s’affichent dans la liste des environnements.
Contrôlez-vous l’accès des utilisateurs à vos données Office 365/Dynamics 365 à l’aide de l’accès conditionnel dans Microsoft Entra ID ? - L’accès conditionnel Microsoft Entra ID permet de limiter la nature des emplacements et des appareils permettant d’utiliser l’environnement, ainsi que la nature des services et connecteurs utilisables.
Gérez-vous une flotte d’appareils (téléphones mobiles, etc.) à l’aide de la gestion des périphériques mobiles ? - À l’aide de solutions de gestion des périphériques mobiles (GPM), telles que Microsoft Intune, vous pouvez appliquer une sécurité à distance, gérer le déploiement des applications mobiles Dynamics 365 et supprimer des données à distance en cas de perte ou de vol d’un appareil.
Utilisez-vous une intégration à SharePoint ? Si oui, comment gérez-vous la sécurité dans SharePoint par rapport à celle dans Dynamics 365 ? - L’intégration de documents SharePoint permet d’automatiser la création de bibliothèques de documents dans SharePoint à partir des enregistrements Dynamics 365 et d’offrir aux utilisateurs Dynamics 365 un accès rapide aux documents stockés dans SharePoint. La sécurité peut être un problème, car la sécurité de la bibliothèque de documents SharePoint ne reflète pas celle de Dynamics 365. Si une personne a accès au site SharePoint où les documents Dynamics 365 sont stockés, elle peut consulter les documents de la bibliothèque, même si elle n’a pas accès à l’enregistrement Dynamics 365 associé. Si cela pose problème, des alternatives doivent être envisagées lorsque les droits d’accès sont plus restreints côté SharePoint (par exemple avec plusieurs sites SharePoint ou une intégration OneDrive Entreprise ou Teams).
Utilisez-vous une intégration à Microsoft Power BI ? Si oui, comment gérez-vous la sécurité dans Power BI par rapport à celle dans Dynamics 365 ? - Lorsqu’un état Power BI est créé directement depuis Dataverse à l’aide du connecteur Microsoft Dataverse standard, il reflète uniquement les données auxquelles l’utilisateur a accès dans le système. Toutefois, si cet état Power BI est partagé, les autres utilisateurs avec lesquels il est partagé voient les données de son propriétaire.
La sécurité au niveau des lignes peut être implémentée pour appliquer la sécurité côté Power BI, mais une autre option consiste à créer un état SQL DirectQuery Power BI qui s’affiche dans le cadre de l’utilisateur connecté. Ensuite, le partage d’un état entraîne alors uniquement le partage de la représentation des données, et non des données elles-mêmes, et le modèle de sécurité Dynamics 365 est pleinement appliqué.
Utilisez-vous d’autres mécanismes de sécurité ? - Parmi les autres mécanismes de sécurité figurent l’authentification multifacteur et les fournisseurs de solutions d’authentification externe, tels qu’Okta, entre autres.
Votre modèle de sécurité présente-t-il des dépendances à des solutions d’éditeurs de logiciels indépendants (ISV) ? Si oui, quelles sont-elles ? - Les ISV fournissent des solutions précieuses qui peuvent améliorer un déploiement de Dynamics 365, mais aussi introduire des risques de sécurité et des dépendances. Il est important de comprendre le mode de déploiement de la solution concernée, son mode de mise à jour et le type d’accès de sécurité dont l’ISV a besoin.
Quels sont vos besoins en matière de modèles de sécurité d’intégration de données ? - En cas de flux de données entre des systèmes, il est important de comprendre quand la sécurité devra être contrôlée au niveau du flux. Assurez-vous de déterminer quel accès de sécurité au système source sera nécessaire dans le cadre de l’intégration et dans Dynamics 365, et sous quel compte le processus d’intégration s’exécutera. Nous vous recommandons de contrôler l’accès aux comptes d’intégration à l’aide d’utilisateurs (non interactifs) d’application.
Si vous utilisez d’autres fonctionnalités Microsoft Power Platform telles que Power Automate et Power Apps, quels sont vos besoins de sécurité et votre conception en la matière ? - Power Apps et Power Automate utilisent des connecteurs pour s’intégrer à des centaines de systèmes différents. Ces outils font partie de la même plateforme que Dynamics 365. Les applications canevas Power Apps et les flux Power Automate utilisent Dataverse tout comme Dynamics 365. Les applications et les flux peuvent être gérés dans des solutions avec d’autres composants Dynamics 365 dans des solutions. L’intégration d’autres connecteurs au processus introduit plusieurs considérations de sécurité supplémentaires, notamment l’accès aux données et la sécurité dans ces systèmes, la stratégie d’environnement pour l’emplacement de création des applications et des flux liés à l’environnement de production Dynamics 365. D’autres considérations de sécurité incluent l’accès des créateurs se connectant à votre environnement de production Dataverse et les règles de protection contre la perte de données (DLP) qui déterminent les connecteurs utilisables conjointement. L’architecte de la solution doit poser des questions de clarification sur la stratégie d’environnement Microsoft Power Platform et la stratégie DLP, et identifier les autorisations de création d’applications et de flux dont disposeront les utilisateurs.
Avez-vous des besoins de sécurité d’infrastructure spécifiques (chiffrement, etc.) ? - Dynamics 365 offre des options de chiffrement avancées, notamment des clés gérées par le client pour les scénarios éligibles. Identifiez si ces options sont utilisées et si le client a établi une stratégie pour gérer ces méthodes à long terme.