Présentation du module de sécurité
Dans la 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.