Concepts de sécurité dans Microsoft Dataverse

L’une des fonctionnalités clés de Dataverse est son modèle de sécurité enrichi qui peut s’adapter à de nombreux scénarios d’utilisation professionnelle. Ce modèle de sécurité est en jeu seulement si une base de données Dataverse est disponible dans l’environnement. En tant qu’administrateur, vous ne construirez probablement pas l’intégralité du modèle de sécurité vous-même, mais serez souvent impliqué dans le processus de gestion des utilisateurs, de vous assurer qu’ils disposent de la configuration appropriée et de résoudre les problèmes liés à l’accès de sécurité.

Pourboire

Regardez la vidéo suivante : Microsoft Dataverse - Concepts de sécurité présentés dans les démos.

la sécurité basée sur les rôles,

Dataverse utilise la sécurité basée sur les rôles pour regrouper une collection de privilèges. Ces rôles de sécurité peuvent être associés directement aux utilisateurs, ou peuvent être associés à des équipes et des divisions Dataverse. Des utilisateurs peuvent ensuite être associés à l’équipe, et donc tous les utilisateurs associés à l’équipe bénéficient du rôle. Un concept clé de la sécurité Dataverse vise à comprendre que tous les privilèges accordés sont cumulés avec la plus grande quantité d’accès prévalant. Si vous avez accordé un accès en lecture au niveau de toute l’organisation à tous les enregistrements de contact, vous ne pouvez pas revenir en arrière et masquer un seul enregistrement.

Divisions

Astuce

Regardez la vidéo suivante : Moderniser les divisions.

Les divisions utilisent des rôles de sécurité pour déterminer la sécurité effective d’un utilisateur. Les divisions sont un bloc de construction de modélisation de sécurité qui permet de gérer les utilisateurs et les données auxquelles ils peuvent accéder. Les divisions définissent les limites de sécurité. Chaque base de données Dataverse comporte une seule division racine.

Vous pouvez créer des sous-divisions enfants pour aider à segmenter davantage vos utilisateurs et leurs données. Chaque utilisateur affecté à un environnement fait partie d’un centre de profit. Bien que les divisions puissent être utilisées pour modéliser une véritable hiérarchie d’organisation 1:1, il arrive plus souvent qu’elles s’orientent vers des limites de sécurité définies correctement afin de répondre aux besoins du modèle de sécurité.

Voyons l’exemple pour mieux comprendre. Nous avons trois divisions. Woodgrove est la division racine et reste en haut, ce qui est inchangeable. Nous avons créé deux autres divisions enfant, A et B. Les utilisateurs de ces divisions ont des besoins d’accès très différents. Lorsque nous associons un utilisateur à cet environnement, nous pouvons définir que l’utilisateur figure dans une de ces trois divisions. L’emplacement auquel l’utilisateur est associé détermine la division qui possède les enregistrements dont l’utilisateur est propriétaire. En ayant cette association, cela nous permet de personnaliser un rôle de sécurité qui permet à l’utilisateur de voir les enregistrements dans cette division.

Structure hiérarchique d’accès aux données

Les clients peuvent utiliser une structure d’organisation où les données et l’utilisateur sont compartimentés dans une hiérarchie arborescente.

Lorsque nous associons un utilisateur à cet environnement, nous pouvons définir l’utilisateur comme étant dans l’une de ces trois divisions et attribuer un rôle de sécurité de la division à l’utilisateur. la division à laquelle l’utilisateur est associé détermine quelle division possède les enregistrements lorsque l’utilisateur crée un enregistrement. En ayant cette association, cela nous permet de personnaliser un rôle de sécurité qui permet à l’utilisateur de voir les enregistrements dans cette division.

L’utilisateur A est associé à la division A et se voit attribuer un rôle de sécurité Y de la division A. Cela permet à l’utilisateur A d’accéder aux enregistrements Contact #1 et Contact #2. Alors que l’utilisateur B de la division B ne peut pas accéder aux enregistrements de contact de la division A, mais peut accéder à l’enregistrement de contact #3.

Structure d’accès aux données matricielles (divisions modernisées)

Les clients peuvent utiliser une structure organisationnelle dans laquelle les données sont compartimentées dans une hiérarchie arborescente, et les utilisateurs peuvent travailler et accéder aux données de n’importe quelle division, quelle que soit la division à laquelle l’utilisateur est affecté.

Lorsque nous associons un utilisateur à cet environnement, nous pouvons définir que l’utilisateur figure dans une de ces trois divisions. Pour chaque division dont un utilisateur a besoin pour accéder aux données, un rôle de sécurité de cette division est attribué à l’utilisateur. Lorsque l’utilisateur crée un enregistrement, l’utilisateur peut définir la division pour qu’elle soit propriétaire de l’enregistrement.

L’utilisateur A peut être associé à n’importe quelle division, y compris la division racine. Un rôle de sécurité Y de la division A est attribué à l’utilisateur A, ce qui lui donne accès aux enregistrements Contact #1 et Contact #2. Un rôle de sécurité Y de la division B est attribué à l’utilisateur A, ce qui lui donne accès à l’enregistrement Contact #3.

Activer la structure d’accès aux données matricielles

Note

Avant d’activer cette fonctionnalité, vous devez publier toutes vos personnalisations pour activer toutes vos nouvelles tables non publiées pour la fonctionnalité. Si vous constatez que vous avez des tables non publiées qui ne fonctionnent pas avec cette fonctionnalité après l’avoir activée, vous pouvez définir le paramètre RecomputeOwnershipAcrossBusinessUnits à l’aide de l’outil OrgDBOrgSettings pour Microsoft Dynamics CRM. Définir RecomputeOwnershipAcrossBusinessUnits sur true permet de définir et de mettre à jour le champ Division propriétaire.

1. Connectez-vous au centre d’administration Power Platform en tant qu’administrateur (administrateur Dynamics 365, administrateur général ou administrateur Microsoft Power Platform).
2. Sélectionnez Environnements, puis choisissez l’environnement pour lequel vous souhaitez activer cette fonctionnalité.
3. Sélectionnez Paramètres>Produit>Fonctionnalités.
4. Activez le commutateur Propriété d’enregistrement dans différentes divisions.

Une fois ce commutateur de fonction activé, vous pouvez sélectionner la division lorsque vous attribuez un rôle de sécurité à un utilisateur. Cela vous permet d’affecter le rôle de sécurité de différentes divisions à un utilisateur. L’utilisateur a également besoin d’un rôle de sécurité de l’unité commerciale à laquelle l’utilisateur est affecté avec les privilèges des paramètres utilisateur pour exécuter des applications pilotées par modèle. Vous pouvez vous référer au rôle de sécurité Utilisateur de base pour savoir comment ces privilèges de paramètres utilisateur sont activés.

Vous pouvez affecter un utilisateur en tant que propriétaire d’enregistrement dans n’importe quelle division sans avoir besoin d’affecter un rôle de sécurité dans l’unité commerciale propriétaire de l’enregistrement tant que l’utilisateur dispose d’un rôle de sécurité avec privilège de lecture sur la table d’enregistrement. Consultez Propriété des enregistrements dans les divisions modernisées.

Note

Ce commutateur de fonctionnalité est stocké dans les paramètres de base de données d’environnement EnableOwnershipAcrossBusinessUnits et peut également être configuré à l’aide de l’outil OrgDBOrgSettings pour Microsoft Dynamics CRM.

Associer une division à un groupe de sécurité Microsoft Entra

Vous pouvez utiliser un groupe de sécurité Microsoft Entra pour cartographier votre division afin de rationaliser votre administration des utilisateurs et l’attribution des rôles.

Crééz un groupe de sécurité Microsoft Entra pour chaque division et attribuez le rôle de sécurité de division respectif à chaque équipe de groupe.

Pour chaque division, créez un groupe de sécurité Microsoft Entra. Créez une équipe de groupe Dataverse pour chaque groupe de sécurité Microsoft Entra. Attribuez le rôle de sécurité respectif de la division à chaque équipe de groupe Dataverse. L’utilisateur dans le diagramme ci-dessus est créé dans la division racine lorsque l’utilisateur accède à l’environnement. C’est bien d’avoir l’utilisateur et les équipes de groupe Dataverse dans la division racine. Ils ont uniquement accès aux données de la division à laquelle le rôle de sécurité est attribué.

Ajouter des utilisateurs dans le groupe de sécurité Microsoft Entra respectif pour leur accorder l’accès à la division. Les utilisateurs peuvent immédiatement exécuter l’application et accéder à ses ressources/données.

Dans l’accès aux données matricielles, où les utilisateurs peuvent travailler et accéder aux données de plusieurs divisions, ajoutez les utilisateurs aux groupes de sécurité Microsoft Entra mappés à ces divisions.

Unité commerciale propriétaire

Chaque enregistrement possède une colonne Division propriétaire qui détermine quelle division est propriétaire de l’enregistrement. Cette colonne est définie par défaut sur la division de l’utilisateur lors de la création de l’enregistrement et ne peut être modifié que lorsque le commutateur de fonctionnalité est activé.

Note

Lorsque vous changez la division propriétaire d’un enregistrement, assurez-vous de vérifier les effets en cascade suivants : Utilisation du SDK pour .NET pour configurer le comportement en cascade.

Vous pouvez décider si vous souhaitez autoriser votre utilisateur à définir la colonne Division propriétaire lorsque le commutateur de fonctionnalité est activé. Pour définir la colonne Division propriétaire, vous devez accorder au rôle de sécurité de l’utilisateur le privilège Ajouter à de la table Division avec l’autorisation au niveau local.

Pour autoriser votre utilisateur à définir cette colonne, vous pouvez activer cette colonne dans les endroits suivants :

1. Formulaire : à la fois dans le corps et dans l’en-tête.
2. Affichage.
3. Mappages de colonnes. Si vous utilisez AutoMapEntity, vous pouvez spécifier la colonne dans le mappage de colonnes.

Note

Si vous disposez d’une tâche/d’un processus pour synchroniser les données entre différents environnements et que la division propriétaire fait partie du schéma, votre tâche échouera, en raison de la vilotaion de la contrainte de Clé étrangère si l’environnement cible ne comporte pas la même valeur pour la division propriétaire.

Vous pouvez supprimer la colonne Division propriétaire du schéma source ou mettre à jour la valeur de la colonne Division propriétaire de la Source afin d’indiquer n’importe quelle division de la cible.

Si vous disposez d’une tâche/d’un processus pour copier des données d’un environnement vers une ressource externe, par exemple PowerBI, vous aurez besoin de sélectionner ou de désélectionner la colonne Division propriétaire de votre source. Sélectionnez le champ si votre ressource peut la récupérer, sinon désélectionnez-le.

Propriété de la table/l’enregistrement

Dataverse prend en charge deux types de propriété d’enregistrement : appartenant soit à une organisation, soit à un utilisateur ou une équipe. Ce choix est effectué lors de la création de la table et ne peut pas être modifié. Pour des raisons de sécurité, les seuls choix de niveau d’accès pour les enregistrements appartenant à une organisation sont les suivants : l’utilisateur peut ou non effectuer l’opération. Pour les enregistrements appartenant aux utilisateurs et aux équipes, les choix de niveau d’accès pour la plupart des privilèges sont hiérarchisés comme suit : Organisation, Division, Division et division enfant, ou uniquement les propres enregistrements de l’utilisateur. Cela signifie que pour le privilège de lecture sur le contact, je peux définir appartenant à l’utilisateur, et l’utilisateur verrait uniquement ses propres enregistrements.

Pour donner un autre exemple, disons l’utilisateur A est associé à la Division A, et nous allons lui donner l’accès en lecture de niveau Division sur le Contact. Il pourrait voir les contacts n° 1 et n° 2, mais pas le contact n° 3.

Lorsque vous configurez ou modifiez des privilèges rôle de sécurité, vous définissez le niveau d’accès pour chaque option. L’exemple suivants présente un rôle de sécurité d’éditeur de privilège.

Dans ce qui précède, vous pouvez voir les types de privilèges standard pour chaque table Créer, Lire, Écrire, Supprimer, Ajouter, Ajouter à, Attribuer et Partager. Vous pouvez modifier chacune individuellement. L’affichage visuel de chacune correspondra à la clé ci-dessous, indiquant le niveau d’accès que vous avez accordé.

Dans l’exemple ci-dessus, nous avons fourni l’accès de niveau organisation à Contact ce qui signifie que l’utilisateur dans la Division A peut afficher et mettre à jour des contacts appartenant à tous. En fait, l’une des erreurs administratives les plus courantes est d’accorder des accès excessifs parce que les autorisations sont frustrantes. Très rapidement un modèle de sécurité correctement généré commence à ressembler à fromage suisse (plein de trous !).

Propriété des enregistrements dans les divisions modernisées

Dans Divisions modernisées, vous pouvez avoir des utilisateurs propriétaires d’enregistrements dans n’importe quelle division. Tout ce dont les utilisateurs ont besoin est un rôle de sécurité (toute division) disposant du privilège de lecture sur la table d’enregistrement. Les utilisateurs n’ont pas besoin d’avoir un rôle de sécurité attribué dans chaque division où réside l’enregistrement.

Si Propriété d’enregistrement dans différentes divisions a été activé dans votre environnement de production pendant la période de version préliminaire, vous devez effectuer les opérations suivantes pour activer cette propriété d’enregistrement dans la division :

1. Installer l’éditeur de paramètres d’organisation
2. Définir les paramètres d’organisation RecomputeOwnershipAcrossBusinessUnits sur true. Lorsque ce paramètre est défini sur true, le système est verrouillé et peut prendre jusqu’à 5 minutes pour effectuer le recalcul afin d’activer la fonctionnalité permettant aux utilisateurs de posséder désormais des enregistrements dans toutes les divisions sans avoir besoin d’avoir des rôle de sécurité distincts attribués à chaque division. Cela permet au propriétaire d’un enregistrement d’attribuer son enregistrement à une personne extérieure à la division propriétaire de l’enregistrement.
3. Définir AlwaysMoveRecordToOwnerBusinessUnit sur false. Ainsi, l’enregistrement reste dans la division propriétaire d’origine lorsque la propriété d’enregistrement est modifiée.

Pour tous les environnements hors production, il vous suffit de définir AlwaysMoveRecordToOwnerBusinessUnit sur false pour utiliser cette fonctionnalité.

Note

Si vous désactivez la fonctionnalité Propriété d’enregistrement dans différentes divisions ou définissez le paramètre RecomputeOwnershipAcrossBusinessUnits sur false avec l’outil OrgDBOrgSettings pour Microsoft Dynamics CRM, vous ne pouvez pas définir ou mettre à jour le champ Division propriétaire, et tous les enregistrements où le champ Division propriétaire est différent de la division du propriétaire seront mis à jour vers la division du propriétaire.

Les équipes (dont les équipes de groupe)

Les équipes sont un autre bloc de construction de sécurité important. Les équipes appartiennent à un centre de profit. Chaque centre de profit possède une équipe par défaut créée automatiquement lors de sa création. Les membres de l’équipe par défaut sont gérés par Dataverse et contiennent toujours tous les utilisateurs associés au centre de profit concerné. Vous ne pouvez pas ajouter ou supprimer manuellement des membres d’une équipe par défaut ; ils sont dynamiquement ajustés par le système à mesure que de nouveaux utilisateurs sont associés/dissociés des divisions. Il existe deux types d’équipes, les équipes propriétaires et les équipes d’accès.

• Les équipes propriétaires peuvent posséder des enregistrements, ce qui donne à tout membre de l’équipe un accès direct à cet enregistrement. Les utilisateurs peuvent être membres de plusieurs équipes. Celui lui permet d’être un moyen puissant d’accorder des autorisations aux utilisateurs dans une large manière sans accès au micro-management au niveau des utilisateurs.
• Les équipes d’accès sont abordées dans la section suivante dans le cadre du partage d’enregistrements.

Partage d’un enregistrement

Les enregistrements individuels peuvent être partagés un par un avec un autre utilisateur. Il s’agit d’un moyen puissant de gérer les exceptions qui ne relèvent pas de la propriété d’enregistrement ou est un membre d’un modèle d’accès de la division. Cela devrait cependant être une exception, car il s’agit d’un moyen moins performant de contrôler l’accès. Le partage est plus difficile à dépanner, car il ne s’agit pas d’un contrôle d’accès implémenté de manière homogène. Le partage peut être effectuée au niveau de l’utilisateur et de l’équipe. Partager avec une équipe est un mode de partage plus efficace. Un concept de partage plus avancé avec les équipes d’accès permet de créer automatiquement une équipe et de partager l’accès à des enregistrements avec l’équipe sur la base de l’application d’un modèle d’équipe d’accès (modèle d’autorisations). Les équipes d’accès peuvent également être utilisées sans les modèles, simplement en ajoutant ou supprimant manuellement leurs membres. Les équipes d’accès sont plus performantes car elles ne permettent pas de posséder les enregistrements par l’équipe ou d’avoir des rôles de sécurité attribués à l’équipe. Les utilisateurs ont accès car l’enregistrement est partagé avec l’équipe et l’utilisateur est membre.

Sécurité au niveau des enregistrements dans Dataverse

Vous pouvez vous demander ce qui détermine l’accès à un enregistrement. C’est probablement une question simple mais pour tout utilisateur donné il s’agit de la combinaison de tous leurs rôles de sécurité, de la division à laquelle ils sont associés, des équipes dont ils sont membres et des enregistrements qui sont partagés avec eux. Le principal est que tout accès est cumulé dans tous ces concepts de l’étendue de l’environnement de base de données Dataverse. Ces droits ne sont accordés que dans une seule base de données et sont suivis individuellement dans chaque base de données Dataverse. Tout cela nécessite bien sûr qu’ils aient une licence appropriée pour accéder à Dataverse.

Sécurité au niveau des colonnes dans Dataverse

Parfois le contrôle au niveau de l’enregistrement de l’accès n’est pas adéquat pour certains scénarios d’entreprise. Dataverse dispose d’une fonctionnalité de sécurité au niveau des colonnes pour permettre un contrôle plus granulaire de la sécurité au niveau de la colonne. La sécurité au niveau des colonnes peut être activée sur toutes les colonnes personnalisées et sur la plupart des colonnes système. La plupart des colonnes système qui incluent des informations d’identification personnelle (PII) sont capables d’être individuellement sécurisées. Les métadonnées de chaque colonne définissent s’il s’agit d’une option disponible pour la colonne système.

La sécurité au niveau des colonnes est activée colonne par colonne. L’accès est ensuite géré en créant un profil de sécurité de colonne. Le profil contient toutes les colonnes avec la sécurité au niveau des colonnes activée et l’accès accordé par ce profil spécifique. Chaque colonne peut être contrôlée dans le profil pour l’accès en Création, Mise à jour et Lecture. Les profils de sécurité des colonnes sont ensuite associés à un utilisateur ou des équipes pour accorder ces privilèges aux utilisateurs aux enregistrements auxquels ils ont déjà accès. Il est important de noter que la sécurité au niveau des colonnes n’a rien à voir avec la sécurité au niveau des enregistrements. Un utilisateur doit déjà avoir accès à l’enregistrement pour que le profil de sécurité de colonne lui accorde un accès aux colonnes. La sécurité au niveau des colonnes sera utilisée si nécessaire et pas excessivement car elle peut ajouter surcharge qui porte préjudice en cas d’utilisation excessive.

Gestion de la sécurité entre plusieurs environnements

Les rôles de sécurité et les profils de sécurité des colonnes peuvent être mis en package et déplacés d’un environnement à un autre grâce aux solutions Dataverse. Les divisions et les équipes doivent être créées et gérées dans chaque environnement avec l’attribution d’utilisateurs aux composants de sécurité nécessaires.

Configuration de la sécurité d’un environnement utilisateur

Une fois que les rôles, les équipes et les divisions sont créés au sein d’un environnement, il est temps d’attribuer aux utilisateurs leurs configurations de sécurité. Tout d’abord, lorsque vous créez un utilisateur, vous l’associez à une division. Par défaut, c’est la division racine de l’organisation. Il est également ajouté à l’équipe par défaut de cette division.

En outre, vous devez attribuer tous les rôles de sécurité dont l’utilisateur a besoin. Vous devez l’ajouter également comme membre de toutes les équipes. Souvenez-vous que les équipes peuvent également avoir des rôles de sécurité, donc les droits effectifs de l’utilisateur sont la combinaison des rôles de sécurité qui lui sont attribués directement et de ceux de toutes les équipes dont il est membre. La sécurité est toujours une offre additionnelle de l’autorisation la moins restrictive de tous les droits. Le guide pas-à-pas suivant présente la configuration de la sécurité de l’environnement.

Si vous avez utilisé la sécurité au niveau des colonnes, vous devez associer l’utilisateur ou une équipe de l’utilisateur à l’un des profils de sécurité de colonne que vous avez créés.

La sécurité est un sujet complexe et il est préférable de l’aborder dans le cadre d’un effort conjoint entre les créateurs d’applications et l’équipe qui administre les autorisations des utilisateurs. Tous les modifications majeures doivent être coordonnés très en amont du déploiement des modifications dans l’environnement.

Voir aussi

Configurer la sécurité d’un environnement
Rôles et privilèges de sécurité