Précédent

Suivant

Accéder à Dataverse

Effectué

Les données doivent toujours être considérées comme un actif précieux. Par conséquent, il est important dans la conception de la sécurité de concevoir un modèle de sécurité qui permette de garantir l’utilisation et l’accès appropriés à ce actif précieux. Microsoft Dataverse stocke des données pour Microsoft Power Platform et fournit des services pour les applications. Microsoft Power Platform a une sécurité en couches pour contrôler l’accès à un environnement Dataverse, mais une fois qu’un utilisateur a obtenu l’accès à l’environnement, l’architecte de solution doit contrôler l’accès au sein de la base de données. Une fonctionnalité clé de Dataverse est son modèle de sécurité enrichi qui peut être adapté en fonction de nombreux scénarios d’utilisation commerciale.

Autorisation

L’autorisation est la fonction de spécification des droits d’accès, ou privilèges, aux ressources. La conception de la sécurité implémente l’autorisation d’accéder aux données et aux fonctionnalités. Décider qui peut obtenir l’accès, à quelles données et à quels services est un élément essentiel de la conception de toute solution.

Une conception de la sécurité inadéquate peut entraîner une mauvaise conception du système, et ces facteurs peuvent avoir un impact considérable et être coûteux à réparer :

• Gérabilité : difficulté de gestion des accès individuels.
• Performances : par exemple, croissance de la table PrincipalAccessObject (POA) lors du partage.
• Facilité d’utilisation : procédures fastidieuses pour accorder l’accès.
• Visibilité : impossibilité de savoir par un examen de l’enregistrement qui y a accès.

Chaque solution a des exigences propres, mais il est possible d’identifier et de réutiliser des fonctionnalités et modèles courants.

Modèles courants

Les modèles d’utilisation courants dans de nombreuses applications professionnelles incluent :

• Implication active : implication régulière et significative directement avec le client/les données. Implication informée, avec une connaissance existante du client/des données et de l’activité actuelle associée, et des actions personnelles basées sur une relation directe avec les personnes impliquées.
• Implication secondaire : implication informée, en conservant une connaissance active de l’activité mais sans participer ni agir directement sur les données ou avec le client, par exemple en intervenant en cas d’absence du personnel activement impliqué. Soutenir d’autres personnes qui ont une relation personnelle avec le client, comme fournir des conseils ou une assistance aux personnes activement impliquées, fournir des connaissances spécialisées sur une donnée ou un client spécifique.
• Interaction transactionnelle : implication spécifique axée sur l’activité, par exemple, recevoir et réagir à une demande de mise à jour de l’adresse d’un client. Aucun engagement personnel ou permanent, comme dans un centre de contact.
• Surveillance de la direction : responsabilité de la direction ou de la gouvernance dans une entreprise ou une zone géographique. Surveiller et orienter l’implication des autres plutôt qu’avoir une implication spécifique.
• Rapports : rapports d’activité agrégés. Les données sont organisées pour préserver l’anonymat plutôt que pour fournir un accès direct aux clients/offres.
• Conformité : supervision de l’accès en lecture seule à tous les enregistrements d’un domaine d’activité.

Lors de la conception de la sécurité, l’architecte de solution doit comprendre comment les utilisateurs travaillent : En d’autres termes, il doit déterminer si les utilisateurs travaillent seuls, font partie d’une équipe statique ou travaillent en équipes dynamiques qui changent en fonction de certaines règles. Ces facteurs auront une incidence sur la conception de la sécurité. Après détermination de ces facteurs, l’architecte de solution doit comprendre comment les autres membres du personnel fournissent un support. Par exemple, l’architecte de la solution doit se demander si les utilisateurs ont affecté du personnel de support et si le personnel de support est partagé entre différents utilisateurs. De plus, l’architecte de la solution doit se demander ce qui se passerait si le personnel de support n’était pas disponible, ou pendant la nuit et le week-end, et comment la surveillance est gérée.

Principes de conception

Lors de la conception de la sécurité, les architectes de solution doivent suivre certains principes :

• La responsabilité attribuée n’a pas toujours besoin d’un accès restreint.
• Traitez les exceptions comme des exceptions, privilégiez les modèles d’accès fréquents.
• Vous ne pouvez pas révoquer l’accès à un enregistrement lorsque vous avez accordé l’accès à un jeu de données plus vaste le contenant.
• Utilisez les centres de profit pour la facilité de gestion et le confinement, et non pour la mise en correspondance de la structure organisationnelle.
• Utilisez la conception la plus simple qui est performante et répond aux exigences.

Remarque

Parfois, la structure organisationnelle s’aligne sur la structure de sécurité requise, mais cela reste rare. Lors de la conception de la sécurité, n’utilisez pas uniquement la structure organisationnelle par défaut.

Fonctionnalités de sécurité

Dataverse fournit de nombreuses fonctionnalités de sécurité pour accéder aux données :

• Propriété de la table
• Utilisateurs
• Équipes
• Centres de profit
• Rôles de sécurité
• Partage
• Groupes de sécurité Microsoft Entra ID
• Sécurité au niveau des colonnes
• Sécurité hiérarchique
• Audit

Les architectes de solution doivent comprendre chacune de ces fonctionnalités et comment elles se combinent pour créer le modèle de sécurité de leurs solutions. Cette unité n’entre pas dans le détail de chacune de ces fonctionnalités de sécurité, mais explique comment elles peuvent être utilisées ensemble pour créer un modèle de sécurité pour votre solution.

Propriété de la table

Les tables dans Dataverse peuvent être détenues soit par un utilisateur/une équipe, soit par une organisation. Les tables détenues par un utilisateur/une équipe ont un champ Propriétaire et chaque ligne de la table peut se voir attribuer un propriétaire. Le propriétaire d’une ligne est utilisé avec les autres fonctionnalités de sécurité pour déterminer qui a accès à la ligne, c’est-à-dire que l’accès aux lignes est granulaire et peut être partitionné horizontalement. Par ailleurs, l’accès aux lignes individuelles des tables détenues par une organisation ne peut pas être restreint et les utilisateurs ont accès à tous les enregistrements ou à aucun.

Remarque

Vous ne pouvez changer le type de propriété une fois qu’une table a été créée. En cas de doute, spécifiez le type de propriété Utilisateur/Équipe lors de la création des tables.

Équipes

Les équipes représentent un ensemble d’utilisateurs qui permettent à ceux-ci d’accéder aux données. Les équipes sont un moyen efficace d’accorder des autorisations aux utilisateurs de manière large, sans microgérer l’accès au niveau de l’utilisateur individuel. Les utilisateurs peuvent être membres de plusieurs équipes.

Il existe trois types d’équipes :

• Propriétaire : ces équipes peuvent détenir des lignes, ce qui donne à tout membre de l’équipe un accès direct à ces lignes.
• Accès : méthode permettant aux utilisateurs de partager facilement une ligne avec quelqu’un d’autre à partir d’un formulaire.
• Groupe Microsoft Entra ID : similaire aux équipes propriétaires, mais l’appartenance à l’équipe est contrôlée dans Microsoft Entra ID.

Rôles de sécurité

Les rôles de sécurité sont essentiels à la sécurité des données dans Dataverse. Vous n’accordez pas de privilèges discrets aux utilisateurs, vous créez des rôles de sécurité. Dataverse utilise la sécurité basée sur les rôles pour regrouper une collection de privilèges.

Les rôles de sécurité peuvent être affectés aux utilisateurs et aux équipes. Les équipes et les utilisateurs peuvent avoir des rôles de sécurité qui fournissent des privilèges agrégés.

Important

Toutes les octrois de privilèges sont cumulables, avec le plus grand nombre d’accès prévalant. Si vous avez accordé un accès en lecture au niveau de l’organisation élargi à tous les enregistrements de contact, vous ne pouvez pas revenir en arrière et masquer un seul enregistrement.

Centres de profit

Les centres de profit comportent des utilisateurs et des équipes et font office de limites de sécurité. Les centres de profit sont la principale méthode de contrôle de l’accès aux sous-ensembles de données dans une table, c’est-à-dire un partitionnement horizontal des données. Avec les centres de profit, vous pouvez segmenter les utilisateurs et leurs données.

Chaque base de données Dataverse a un seul centre de profit racine. Vous pouvez créer des centres de profit enfants pour représenter des groupes d’utilisateurs dans une hiérarchie stricte.

Remarque

Les centres de profit ont une équipe par défaut qui contient tous les utilisateurs de ce centre de profit. Vous ne pouvez pas ajouter ou supprimer manuellement des utilisateurs des équipes par défaut afin qu’ils puissent devenir des bloqueurs pour certains scénarios à mesure que la solution évolue.

Important

C’est la combinaison des rôles de sécurité et des centres de profit qui est à la base du modèle de sécurité de Dataverse.

Les centres de profit offrent un moyen efficace de gérer de nombreux utilisateurs et l’accès aux enregistrements. Les centres de profit ne sont pas visibles par les utilisateurs dans les applications, uniquement par les administrateurs. Vous ne devez pas uniquement refléter l’organigramme d’une organisation, vous devez également concevoir la hiérarchie des centres de profit pour répondre aux exigences de sécurité. Cette approche peut parfois impliquer de créer des centres de profit pour répondre à une exigence de sécurité, par exemple, créer un centre de profit comme parent des centres de profit Ventes et Marketing afin de permettre à certains utilisateurs d’accéder à ces centres de profit tout en empêchant l’accès au centre de profit Opérations.

Partager des lignes

Des lignes individuelles peuvent être partagées avec des utilisateurs et des équipes. Cette fonctionnalité permet aux utilisateurs d’accéder à des enregistrements dont l’accès est restreint par le modèle de sécurité généré par les centres de profit. Le partage permet d’accéder à des lignes en dehors de la hiérarchie stricte des centres de profit.

Rôles de sécurité et équipes

Les rôles de sécurité peuvent être associés à des équipes. Des utilisateurs peuvent ensuite être associés à l’équipe ; de ce fait, tous les utilisateurs associés à l’équipe bénéficieront du rôle. Les utilisateurs auront accès aux lignes détenues par l’équipe et, en fonction d’autres fonctionnalités de sécurité, pourront avoir accès aux lignes détenues par d’autres utilisateurs de l’équipe.

Voici les options sur le rôle de sécurité qui contrôlent la façon dont le rôle de sécurité fonctionne avec une équipe :

• Par défaut – privilèges Équipe uniquement
• Niveau d’accès (basique) Utilisateur direct et privilèges Équipe

Avec l’option Utilisateur direct, les privilèges sont traités comme s’ils étaient directement attribués à l’utilisateur. En utilisant cette option, vous ne devez plus nécessairement attribuer des rôles de sécurité aux utilisateurs et pouvez utiliser à la place les équipes et les rôles de sécurité qui sont attribués aux équipes.

Remarque

Les équipes propriétaires appartiennent aux centres de profit. Un utilisateur ne peut appartenir qu’à un seul centre de profit à la fois, mais peut être ajouté à une équipe dans un autre centre de profit. Cette fonctionnalité permet aux utilisateurs d’accéder aux données d’un centre de profit qui ne se trouve pas dans leur hiérarchie.

Sécurité au niveau des colonnes

Les privilèges fournis par les rôles de sécurité fonctionnent au niveau de la ligne. Si un utilisateur dispose du privilège de mise à jour sur une ligne, il peut mettre à jour toutes les colonnes de cette ligne. Parfois, le contrôle d’accès au niveau des lignes n’est pas adéquat, comme dans le cas des colonnes qui contiennent des informations personnelles identifiables. 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 fonctionne séparément des rôles de sécurité. Les profils de sécurité de colonne définissent le privilège de lecture/écriture sur les colonnes et ces profils sont attribués aux utilisateurs et aux équipes.

Remarque

Si un utilisateur n’a pas les privilèges de lire une colonne sécurisée, il peut toujours voir la colonne sur le formulaire, mais ne pourra pas voir son contenu, c’est-à-dire la valeur des données. Lorsqu’il utilisera un code pour accéder à un champ sécurisé, la valeur sera nulle si l’utilisateur n’a pas les privilèges de lecture.

Sécurité hiérarchique

Un problème lié à l’utilisation des centres de profit est leur hiérarchie stricte. L’accès aux données ne peut suivre que la hiérarchie des centres de profit. Dans le diagramme des centres de profit, un utilisateur du centre de profit Ventes peut avoir accès aux centres de profit Nord, Centre et Sud. À l’inverse, un utilisateur du centre de profit Opérations ne peut pas accéder aux données appartenant à Ventes si l’accès à toutes les données de l’organisation ne lui a pas été octroyé.

Dans la sécurité hiérarchique, l’utilisateur au poste ci-dessus peut lire et écrire toutes les données de ses subordonnés. Il peut également lire les données des utilisateurs qui se trouvent plus bas dans la hiérarchie.

La sécurité hiérarchique est un modèle de sécurité alternatif conçu pour les scénarios où un utilisateur nécessitant une supervision de la direction ne se trouve pas la même partie de la hiérarchie du centre de profit. La sécurité hiérarchique est utile lorsque les responsables se trouvent dans d’autres pays/régions ou départements que leurs subordonnés directs.

La sécurité hiérarchique offre deux options :

• Hiérarchie du responsable : cette option utilise la hiérarchie d’utilisateur sur la table d’utilisateurs système. La restriction est qu’un responsable qui se trouve dans le même centre de profit ou dans la chaîne directe des centres de profit ci-dessus ne peut pas lire et écrire les données des utilisateurs qui se trouvent dans des départements différents.
• Hiérarchie de poste : cette option utilise la table Position. Elle est plus flexible et ignore la structure du centre de profit. La hiérarchie positionnelle permet également d’avoir plus d’une personne à un poste.

Il n’est possible d’utiliser qu’un seul type de hiérarchie à la fois.

Audit

L’audit capture toutes les modifications de données. L’audit permet de contrôler qui a effectué quels changements et d’analyser également la façon dont les utilisateurs utilisent réellement le système. La fonctionnalité d’audit dans Dataverse ne capture pas la lecture des données ou les actions, telles que l’exportation vers Microsoft Excel.

Un autre audit disponible, appelé journalisation des activités, est situé dans le centre de sécurité et de conformité Microsoft 365. Il inclut des lectures de données et d’autres opérations. La journalisation des activités doit être activée et permet d’atteindre les objectifs de conformité.

Gérer la sécurité dans plusieurs environnements

Les rôles de sécurité et les profils de sécurité de colonne peuvent être intégrés dans des solutions et transférés vers d’autres environnements. Les modèles d’équipe d’accès font partie des métadonnées de table et sont inclus avec la table lorsqu’ils sont ajoutés à la solution. D’autres fonctionnalités de sécurité telles que les centres de profit et les équipes ne peuvent pas être intégrées dans des solutions et l’architecte de solution devra planifier leur remplissage dans les environnements.

Stratégies de définition des rôles de sécurité

Il existe trois stratégies de base pour créer des rôles de sécurité :

• Spécifique au poste
• Référence + poste
• Référence + capacité

La stratégie spécifique au poste consiste à créer un rôle de sécurité unique qui contient tous les privilèges requis par la fonction. Les rôles prêts à l’emploi sont spécifiques au poste et sont nommés d’après les fonctions, par exemple, Vendeur. Vous pouvez suivre ce modèle de rôle pour des fonctions spécifiques, mais vous risquez de vous retrouver avec de nombreux rôles de sécurité similaires et que vous devrez gérer. Par exemple, l’ajout d’une nouvelle table personnalisée impliquera de changer de nombreux rôles, sinon tous.

Un modèle plus moderne consiste à utiliser un modèle de sécurité en couches. Dans ce modèle, vous copiez un rôle prêt à l’emploi, tel que Vendeur ou Utilisateur de base, puis modifiez les niveaux d’accès aux niveaux communs ou minimaux nécessaires pour tous les utilisateurs. Vous pouvez nommer ce rôle Référence. Vous créez ensuite de nouveaux rôles et définissez les niveaux d’accès pour les quelques privilèges dont chaque groupe d’utilisateurs a besoin en plus du rôle de référence. Ces rôles minimaux contiennent les autres privilèges requis pour le poste ou la capacité requise.

Dans le diagramme suivant, le rôle de référence est nommé Tout le personnel et ce rôle sera attribué à tous les utilisateurs. Tous les utilisateurs commerciaux se verront également attribuer le rôle nommé Ventes, un rôle de poste, certains utilisateurs commerciaux se verront attribuer le rôle Mobile, un rôle de capacité, qui dispose du privilège Être mobile, et un responsable se verra attribuer le rôle Ventes et le rôle Responsable.

Même si cela n’est peut-être pas évident, les rôles de sécurité sont liés aux centres de profit. Les rôles créés dans le centre de profit racine sont hérités par tous les centres de profit enfants. Vous pouvez créer un rôle de sécurité pour un centre de profit spécifique si vous souhaitez limiter ce rôle aux utilisateurs de ce centre de profit. Cependant, sachez que les rôles de sécurité dans les solutions sont toujours ajoutés au centre de profit racine lorsque la solution est importée.

Équipes de groupe Microsoft Entra ID

Une équipe de groupe Microsoft Entra ID est similaire à une équipe propriétaire en ce sens qu’elle peut détenir des enregistrements et avoir des rôles de sécurité attribués à l’équipe. La différence est que l’appartenance à une équipe dans Dataverse est dynamiquement dérivée de l’appartenance au groupe Microsoft Entra ID associé. L’appartenance à un groupe Microsoft Entra ID peut être attribuée manuellement ou peut être dérivée d’une attribution basée sur des règles en fonction des attributs de l’utilisateur dans Microsoft Entra ID.

Combiner les équipes de groupe Microsoft Entra ID avec l’attribution de rôles de sécurité aux équipes avec l’option Utilisateur direct peut considérablement simplifier la gestion de l’ajout de nouveaux utilisateurs.

Les groupes de sécurité et les groupes Office 365 peuvent être utilisés pour les équipes de groupe Microsoft Entra ID.

Continuer