Sécurité dans les applications
Lors de la configuration de la sécurité, vous pouvez configurer quatre couches de sécurité différentes pour une application :
- Au niveau de l’application : restreint l’accès à l’application.
- Au niveau du formulaire : pour les applications pilotées par modèle, ce niveau de sécurité vous permet d’autoriser uniquement des groupes de sécurité spécifiques à accéder à des formulaires particuliers. Ce niveau est utile si vous souhaitez contrôler la manière dont les utilisateurs saisissent ou affichent des données, en fonction de leur rôle professionnel.
- Au niveau des lignes : le modèle de sécurité Dataverse contrôle l’accès aux lignes.
- Au niveau des colonnes : contrôle l’accès aux colonnes individuelles d’une table.
La sécurité doit être mise en place au niveau de la plateforme, et non pas de la couche de l’application. De nombreux moyens sont à votre disposition pour contrôler la lecture et l’écriture des données dans une application. Vous pouvez définir des colonnes en lecture seule sur votre formulaire piloté par modèle, vous pouvez utiliser JavaScript pour masquer les colonnes de l’expérience utilisateur et vous pouvez masquer les colonnes et les champs des formulaires et des vues. Aucune de ces approches n’implémente réellement la sécurité. Elles ne sécurisent pas les données, et les utilisateurs peuvent toujours accéder à ces dernières par d’autres moyens, par exemple par le biais de fonctionnalités de recherche avancée ou de modification dans Excel Online.
En outre, tous les utilisateurs sont autorisés à utiliser l’API et peuvent accéder aux données par le biais d’outils partenaires et communautaires. Afin d’assurer une sécurité adéquate, les fonctions de sécurité de Dataverse doivent être mises en œuvre.
Privilèges élevés et emprunt d’identité
Vous devez éviter d’accorder aux utilisateurs des niveaux de privilèges élevés. Les assemblages .NET (plug-in), les flux de travail classiques et les flux de cloud Power Automate peuvent s’exécuter avec un accès élevé pour effectuer des actions au nom de l’utilisateur. Le code API peut emprunter l’identité d’un autre utilisateur si nécessaire.
Automatisation
Les architectes de solution doivent envisager d’automatiser les aspects relatifs à la gestion des utilisateurs et à la sécurité. Par exemple, vous pouvez contrôler de nombreux aspects, de la création d’équipes au partage de lignes par le biais de l’API.
Vous pouvez déclencher des plug-ins ou des flux Power Automate basés sur des événements qui se produisent dans le système pour modifier la sécurité d’un utilisateur. Par exemple, vous pouvez élever automatiquement les privilèges d’un chargé de compte secondaire, ou partager ses données, afin que l’utilisateur puisse gérer le compte si le chargé de compte principal est en congés.
Performances
Les solutions comptant un plus grand nombre d’utilisateurs et/ou de données doivent tenir compte de l’impact des choix, par exemple :
- Le partage excessif peut générer des frais généraux considérables.
- Un trop grand nombre d’unités commerciales peut ralentir l’accès.
- Trop de processus s’exécuteront sur des événements.
- Mauvaise conception du plug-in.
Une conception de sécurité peu efficace peut nuire aux performances. Les techniques qui permettent d’améliorer les performances de sécurité incluent :
- Rechercher des moyens d’améliorer la sécurité, comme le partage des données avec une équipe plutôt qu’avec un utilisateur.
- Limiter le nombre d’unités commerciales.
- Utiliser des équipes d’accès au lieu d’équipes propriétaires.
- Exécuter des tests sur les volumes réels et des scénarios de sécurité concrets pour valider la conception.
- Utiliser les outils d’analyse dans le Centre d’administration Microsoft Power Platform pour afficher les appels d’API et les processus à volume élevé.
La meilleure façon d’améliorer les performances consiste à faire en sorte que la conception de la sécurité reste aussi simple que possible.
Séparer et optimiser les modèles d’utilisation
Un architecte de solution doit optimiser sa solution en vue de différents modèles d’utilisation. Plus précisément, vous devez utiliser différentes fonctionnalités du modèle de sécurité pour fournir l’accès nécessaire, avec différents utilisateurs ayant diverses manières d’accéder au même enregistrement, comme illustré dans le diagramme suivant.
Divers domaines d’activité peuvent être modélisés différemment
Les utilisateurs ne travaillent pas tous de la même manière. L’architecte de solution doit réfléchir aux différents modèles de travail adaptés aux différentes parties de l’entreprise, puis modéliser chaque domaine différemment afin d’obtenir une solution optimale, comme illustré dans le diagramme suivant.
Les exceptions doivent être traitées dans le modèle en tant qu’exceptions
Les architectes de solution doivent tenter de modéliser les méthodes d’accès courantes aussi efficacement que possible et utiliser un modèle plus granulaire lorsqu’un accès complexe est requis. Le partage est un bon exemple de traitement des exceptions. Le partage doit se faire avec des équipes dans la mesure du possible.
Séparer les données historiques des données actives
Les données historiques peu consultées mais à volume élevé peuvent avoir un impact sur l’accès actuel aux données. L’architecte de solution doit envisager de partitionner les données du modèle de sécurité dans des tables séparées, puis de fournir un mécanisme secondaire pour l’accès occasionnel.
Examiner le modèle de données pour renforcer la sécurité
Certains ajustements du modèle de données peuvent faciliter la modélisation de la sécurité. L’architecte de la solution doit déterminer si la définition de nouvelles limites de données simplifiera la modélisation de la sécurité. Par exemple, au lieu de définir un accès individuel aux enregistrements d’un compte, vous pouvez déplacer les informations de reporting financier de ces enregistrements de compte vers une table Données financières distincte. Cela permettra à tous les utilisateurs de voir la table Compte, tandis que la table Données financières continuera d’être uniquement accessible aux responsables.