Planification de l’implémentation de Power BI : planification de la sécurité des consommateurs de rapports

Notes

Cet article fait partie de la série d’articles sur la planification de l’implémentation de Power BI. Cette série se concentre principalement sur la charge de travail Power BI au sein de Microsoft Fabric. Pour une introduction à la série, consultez Planification de l’implémentation de Power BI.

Cet article sur la planification de la sécurité décrit les stratégies pour les consommateurs en lecture seule. L’accent est mis sur les autorisations des viewers pour les rapports et les applications, et sur la façon de déployer la sécurité des données. Il est principalement destiné à :

• Administrateurs Power BI : Les administrateurs chargés de superviser Power BI dans l’organisation.
• Centre d’excellence, service informatique et équipe BI : les équipes qui sont également responsables de la supervision de Power BI. Ils peuvent devoir collaborer avec les administrateurs Power BI, les équipes de sécurité de l’information et d’autres équipes pertinentes.
• Créateurs et propriétaires de contenus : créateurs décisionnels en libre-service qui ont besoin de créer, publier, sécuriser et gérer des contenus que d’autres utilisateurs consomment.

La série d’articles est destinée à approfondir le contenu du Livre blanc sur la sécurité de Power BI. Bien que le livre blanc Sécurité dans Power BI se concentre sur des sujets techniques clés tels que l’authentification, la résidence des données et l’isolement réseau, l’objectif principal de la série est de vous fournir des considérations et décisions pour vous aider à planifier la sécurité et la confidentialité.

Dans une organisation, de nombreux utilisateurs sont classés en tant que consommateurs. Les consommateurs affichent les contenus que d’autres utilisateurs ont créés et publiés. Les consommateurs sont au cœur de cet article. Pour une planification de la sécurité axée sur les créateurs et les propriétaires de contenus, consultez l’article sur la planification de la sécurité du créateur de contenus.

Pour tirer le meilleur parti de cet article, il faut comprendre la signification des termes partage et distribution dans le contexte de Power BI.

Le partage désigne l’endroit où un utilisateur donne à un autre utilisateur (ou groupe d’utilisateurs) l’accès à un élément de contenu spécifique. Dans le service Power BI, la fonctionnalité de partage est limitée à un seul élément. Il se produit le plus souvent entre des personnes qui se connaissent et travaillent en étroite collaboration.

La distribution désigne l’endroit où les contenus sont remis à d’autres utilisateurs, appelés destinataires. Elle implique souvent un plus grand nombre d’utilisateurs dans de multiples équipes. Même si les destinataires n’ont pas explicitement demandé ces contenus, ils en ont clairement besoin pour remplir leur rôle. Les destinataires qui consomment des contenus distribués connaîtront sans doute (ou non) le créateur d’origine des contenus. Par conséquent, la distribution en tant que concept se veut plus formelle que le partage.

Lorsque vous échangez parlez avec d’autres personnes, vous devez déterminer si elles utilisent le terme partage de manière générale ou littérale. L’utilisation du terme partage peut s’interpréter de deux façons.

• Le terme partage est souvent utilisé de manière générale pour désigner le partage de contenus avec des collaborateurs. Cet article décrit les différentes techniques qui permettent de fournir des contenus en lecture seule.
• Le partage est également une fonctionnalité spécifique de Power BI. Cette fonctionnalité permet d’accorder l’accès à un seul élément à un utilisateur ou un groupe. Cet article décrit également le partage de liens et le partage d’accès direct.

Important

Le rôle Administrateur Power BI a été renommé. Le nouveau nom du rôle est Administrateur d’infrastructure.

Stratégie pour les consommateurs en lecture seule

Dans le service Power BI, les consommateurs peuvent afficher un rapport ou un tableau de bord lorsqu’ils sont autorisés à :

• afficher l’élément Power BI qui contient les visualisations (par exemple, un rapport ou un tableau de bord) et à
• Lisez les données sous-jacentes (modèle sémantique, précédemment appelé jeu de données) ou autre source.

Différentes techniques permettent de fournir un accès en lecture seule aux consommateurs. Les créateurs de contenus en libre-service utilisent les techniques courantes suivantes :

• Octroi de l’accès à une application Power BI aux utilisateurs et aux groupes
• Ajout d’utilisateurs et de groupes à un rôle Viewer de l’espace de travail Power BI
• Octroi des autorisations par élément aux utilisateurs et aux groupes à l’aide d’un lien de partage
• Octroi des autorisations par élément aux utilisateurs et aux groupes à l’aide d’un accès direct

Les options du rôle Viewer de l’application Power BI et l’espace de travail Power BI impliquent de gérer les autorisations pour un ensemble d’éléments. Les deux techniques d’autorisation par élément impliquent de gérer les autorisations pour un élément individuel.

Conseil

En règle générale, la meilleure pratique consiste à utiliser une application Power BI avec la plupart des consommateurs. Parfois, le rôle Viewer de l’espace de travail peut également être approprié. Les applications Power BI et le rôle Viewer de l’espace de travail permettent de gérer les autorisations pour de nombreux éléments et doivent être utilisés dans la mesure du possible. La gestion des autorisations pour les éléments individuels peut être fastidieuse, chronophage et sujette aux erreurs. En revanche, la gestion d’un ensemble d’éléments allège la maintenance et améliore la précision.

Lorsque vous examinerez les paramètres de sécurité d’un élément, vous constaterez sans doute que ses autorisations sont soit :

• héritées de l’espace de travail ou d’une application ;
• directement appliquées à l’élément.

Dans la capture d’écran suivante, les autorisations d’accès direct sont affichées pour un rapport. Dans cette instance, les rôles « Admins » (Administrateurs) et « Members » (Membres) de l’espace de travail sont chacun attribués à un groupe. Ces rôles sont affichés pour un rapport, car l’accès au niveau du rapport est hérité de l’espace de travail. Un utilisateur dispose également d’autorisations de lecture appliquées directement au rapport.

La stratégie que vous choisissez pour les consommateurs en lecture seule peut être différente. Elle doit être basée sur la solution individuelle, les préférences de qui gère la solution ou les besoins du consommateur. La suite de cette section décrit quand il convient d’utiliser chacune des techniques disponibles.

Liste de vérification : voici les décisions et les actions clés pour créer une stratégie liée à la fourniture de contenus aux consommateurs en lecture seule :

• Évaluer la stratégie existante pour les consommateurs en lecture seule. Vérifiez comment les contenus sont actuellement distribués et partagés avec les consommateurs. Déterminez s’il existe des possibilités d’amélioration.
• Choisir la stratégie pour les consommateurs en lecture seule. Évaluez vos préférences concernant l’utilisation des autorisations d’application, les rôles de l’espace de travail ou les autorisations par élément. Si vous devez apporter des modifications pour répondre à ces préférences, créez un plan d’amélioration.

Autorisations d’application Power BI

Une application Power BI fournit une collection de rapports, de tableaux de bord et de classeurs aux consommateurs. Une application offre une expérience utilisateur optimale aux consommateurs, car :

• Le volet de navigation de l’application offre une expérience utilisateur simple et intuitive. L’expérience est plus agréable qu’avec un accès aux contenus directement dans l’espace de travail.
• Vous pouvez organiser les contenus de façon logique, en sections (qui ressemblent à des dossiers), dans le volet de navigation de l’application.
• Les consommateurs peuvent uniquement accéder à des éléments spécifiques qui ont été explicitement inclus dans l’application pour l’audience correspondante.
• Vous pouvez ajouter des liens vers des informations complémentaires, des documents ou d’autres contenus dans le volet de navigation pour l’audience correspondante.
• Il existe un workflow de demande d’accès intégré.

Notes

Dans cet article, toutes les références à une application renvoient à une application Power BI. Il s’agit d’un concept différent de celui de Power Apps. Il s’agit également d’un concept différent de celui des applications mobiles Power BI. Cette section se concentre mis sur les applications d’organisation plutôt que sur les applications modèles.

Vous pouvez créer une application pour chaque espace de travail. Vous disposez ainsi d’un moyen formel pour distribuer une partie ou l’intégralité des contenus de l’espace de travail. Les applications sont un moyen efficace de distribuer des contenus à grande échelle au sein d’une organisation, en particulier si vous ne connaissez pas ou ne collaborez pas étroitement avec certains utilisateurs.

Conseil

Pour savoir comment utiliser une application Power BI pour distribuer des contenus à grande échelle, consultez le scénario d’utilisation du décisionnel d’entreprise. Nous recommandons aux créateurs de contenus à distribuer d’opter de préférence pour la création d’une application.

Vous gérez les autorisations d’application séparément des rôles de l’espace de travail. La séparation des autorisations présente deux avantages. Elle encourage :

• L’octroi d’un accès à l’espace de travail aux créateurs de contenus. Cela comprend les utilisateurs qui collaborent activement aux contenus, comme les créateurs de modèle sémantique, les créateurs de rapports et les testeurs.
• L’octroi d’autorisations d’application aux consommateurs. Contrairement aux autorisations d’espace de travail, les autorisations d’application sont toujours en lecture seule (ou inexistantes).

Tous les utilisateurs disposant d’un accès à l’espace de travail peuvent automatiquement afficher l’application (lorsqu’une application Power BI a été publiée pour l’espace de travail). En raison de ce comportement, vous pouvez théoriquement considérer les rôles de l’espace de travail comme hérités par chaque audience d’application. Certains utilisateurs disposant d’un accès à l’espace de travail peuvent également mettre à jour l’application Power BI, en fonction du rôle de l’espace de travail qui leur est attribué.

Conseil

Pour plus d’informations sur les rôles de l’espace de travail, consultez l’article sur la planification de la sécurité du créateur de contenus.

L’utilisation d’une application pour distribuer des contenus aux consommateurs en lecture seule constitue le meilleur choix dans les cas suivants :

• Vous souhaitez que les utilisateurs puissent afficher uniquement certains éléments réservés à l’audience (et non tous les éléments de l’espace de travail sous-jacent).
• Vous souhaitez gérer les autorisations d’application en lecture seule séparément de celles de l’espace de travail.
• Vous souhaitez que la gestion des autorisations pour les utilisateurs en lecture seule soit plus simple que celle des autorisations par élément.
• Vous souhaitez vous assurer que la sécurité au niveau des lignes (SNL) est déployée pour les consommateurs (lorsqu’ils disposent d’une autorisation de lecture seule sur le modèle sémantique sous-jacent).
• Vous souhaitez vous assurer que les consommateurs ne peuvent pas afficher les nouveaux rapports ni les rapports modifiés tant que l’application n’a pas été republiée.

S’il est vrai que les modifications apportées aux rapports et aux tableaux de bord ne sont pas visibles par les utilisateurs de l’application tant que l’application n’a pas été republiée, deux cas de figure imposent la prudence.

• Modifications immédiates du modèle sémantique : les modifications de modèle sémantique prennent toujours effet immédiatement. Par exemple, si vous introduisez des changements cassants dans un modèle sémantique de l’espace de travail, les rapports peuvent devenir instables par inadvertance (et ce, même s’ils n’ont pas été republiés dans l’application). Vous pouvez atténuer ce risque de deux façons. Premièrement, exécutez tous les travaux de développement dans Power BI Desktop (séparément de l’espace de travail). Deuxièmement, isolez l’application de production en utilisant des espaces de travail distincts pour le développement et le test. (Si vous le souhaitez, vous pouvez utiliser des pipelines de déploiement pour augmenter le niveau de contrôle associé au déploiement des contenus de l’espace de travail, du développement au test et à la production.)
• Publication simultanée des contenus et des autorisations. Lorsque vous publiez une application, ses autorisations sont publiées en même temps que les contenus. Par exemple, certaines modifications de rapport d’un espace de travail peuvent ne pas être terminées, entièrement testées ou approuvées. Vous ne pouvez donc pas republier l’application uniquement pour mettre à jour les autorisations. Pour atténuer ce risque, attribuez les autorisations d’application à un ou plusieurs groupes de sécurité et utilisez les appartenances aux groupes de sécurité (et non les utilisateurs individuels) pour octroyer les autorisations d’application. Évitez de republier une application uniquement pour appliquer des modifications d’autorisation.

Audience d’application

Chaque espace de travail du service Power BI ne peut compter qu’une seule application Power BI. Toutefois, vous pouvez créer une ou plusieurs audiences au sein de l’application. Considérons le scénario suivant.

• Vous disposez de cinq rapports commerciaux qui sont distribués à de nombreux utilisateurs dans l’ensemble de l’organisation commerciale internationale.
• Vous avez défini une audience pour les représentants commerciaux dans l’application. Cette audience peut consulter trois rapports sur cinq.
• Vous avez défini une autre audience pour l’équipe de direction commerciale dans l’application. Cette audience peut consulter les cinq rapports (y compris les deux rapports auxquels les représentants commerciaux ne peuvent pas accéder).

Cette capacité à combiner les contenus et les audiences présente les avantages suivants.

• Certains rapports peuvent être consultés par plusieurs audiences. Par conséquent, créer plusieurs audiences permet de ne plus avoir à dupliquer des contenus dans différents espaces de travail.
• Certains rapports ne doivent être disponible que pour une seule audience. Ainsi, les contenus qui lui sont réservés peuvent se trouver dans le même espace de travail que d’autres contenus connexes.

La capture d’écran suivante représente une application avec deux audiences : Sales Leadership (Direction commerciale) et Sales Reps (Représentants commerciaux). Le volet Manage Audience Access (Gérer l’accès à l’audience) permet à deux groupes de sécurité d’accéder au groupe d’audience Sales Leadership (Direction commerciale), à savoir Sales Leadership-North America (Direction commerciale Amérique du Nord) et Sales Leadership-Europe (Direction commerciale Europe). Le rapport Gross Margin Analysis (Analyse de la marge brute) visible dans la capture d’écran du groupe d’audience Sales Leadership (Direction commerciale) ne peut pas être consulté par le groupe d’audience Sales Reps (Représentants commerciaux).

Remarque

Le terme groupe d’audience est parfois utilisé. Il ne s’agit pas d’une référence directe à l’utilisation des groupes de sécurité. Il comprend les membres de l’audience cible pour lesquels la collection de contenus est visible dans l’application Power BI. Même si vous pouvez affecter des utilisateurs individuels à une audience, la meilleure pratique consiste à affecter des groupes de sécurité, des groupes Microsoft 365 ou des groupes de distribution dès que cela est possible. Pour plus d’informations, consultez la stratégie d’utilisation des groupes dans l’article Planification de la sécurité au niveau du locataire.

Lorsque vous gérez les autorisations d’une application, vous pouvez afficher les membres de chaque audience dans la page Accès direct. Vous pouvez également afficher les utilisateurs disposant d’un rôle d’espace de travail sous l’audience Tous. Vous ne pouvez pas mettre à jour les autorisations d’application depuis la page Accès direct. Pour cela, vous devez republier l’application. Vous pouvez toutefois mettre à jour les autorisations d’application depuis la page En attente lorsque des demandes d’accès ont été ouvertes pour l’application.

Conseil

Le principal cas d’usage concernant l’utilisation des audiences d’application consiste à définir des autorisations spécifiques pour différents ensembles d’utilisateurs. Toutefois, vous pouvez faire preuve d’un peu de créativité pour l’utilisation des audiences. Un utilisateur peut être membre de plusieurs audiences. Chaque audience est présentée aux viewers de l’application sous la forme d’un ensemble secondaire de menus. Par exemple, vous pouvez créer une audience nommée Pour démarrer qui contient des informations pour utiliser l’application, savoir qui contacter, transmettre ses commentaires et obtenir de l’aide. Vous pouvez également créer une audience nommée Définition des KPI qui inclut un dictionnaire de données. Ce type d’informations aide les nouveaux utilisateurs et améliore les efforts d’adoption des solutions.

Options d’autorisation d’application

Lorsque vous créez (ou republiez) une application, chaque audience dispose d’un volet Gérer l’accès à l’audience. Ce volet comporte les autorisations ci-dessous.

• Accorder l’accès à. Pour chaque audience, vous pouvez accorder l’accès à des utilisateurs et des groupes individuels. Vous pouvez publier l’application sur l’ensemble de l’organisation lorsqu’elle est activée par le paramètre de locataire Publier les applications sur l’ensemble de l’organisation et que l’application n’est pas installée automatiquement. Dans la mesure du possible, nous recommandons d’affecter des groupes à des audiences, car l’ajout ou la suppression d’utilisateurs impose de republier l’application. Tout utilisateur disposant d’un accès à l’espace de travail a automatiquement l’autorisation d’afficher ou de mettre à jour l’application en fonction de son rôle d’espace de travail.
• Autorisations de modèle sémantique : Vous pouvez accorder deux types d’autorisations de modèle sémantique lors de la publication d’une application :
  • Repartage du modèle sémantique : lorsque cette option est activée, les utilisateurs de l’application bénéficient d’une autorisation de repartage avec d’autres utilisateurs sur le ou les modèles sémantiques sous-jacents. Il est logique d’activer cette option lorsque le ou les modèles sémantiques sous-jacents peuvent être facilement partagés. Nous recommandons d’obtenir l’approbation du ou des propriétaires du modèle sémantique avant d’accorder une autorisation de repartage à une audience d’application.
  • Build du modèle sémantique : lorsque cette option est activée, les utilisateurs de l’application bénéficient de l’autorisation de génération pour les modèles sémantiques. L’autorisation de génération permet aux utilisateurs de créer de nouveaux rapports, d’exporter des données sous-jacentes à partir des rapports, etc. Nous recommandons d’obtenir l’approbation du ou des propriétaires du modèle sémantique avant d’accorder une autorisation de génération à une audience d’application.

La possibilité d’ajouter les autorisations de repartage ou de génération du modèle sémantique lors de la publication d’une application a un aspect pratique. Toutefois, nous recommandons de gérer les autorisations d’application et les autorisations de modèle sémantique séparément. Voici pourquoi.

• Les modèles sémantiques partagés peuvent se trouver dans un espace de travail distinct. Si lemodèle sémantique est publié dans un espace de travail distinct de l’application, vous devez gérer ses autorisations directement. La possibilité d’ajouter des autorisations de lecture, de génération ou de repartage lors de la publication d’une application ne fonctionne que pour les modèles sémantiques qui se trouvent dans le même espace de travail que l’application. Pour cette raison, nous recommandons de prendre l’habitude de gérer indépendamment les autorisations de modèle sémantique.
• Les autorisations de modèle sémantique sont gérées séparément : si vous supprimez ou modifiez les autorisations d’une application, l’action affecte uniquement l’application. Elle ne supprime pas automatiquement les autorisations de modèle sémantique précédemment attribuées. De cette façon, vous pouvez considérer que les autorisations d’application et les autorisations de modèle sémantique sont dissociées. Vous devez gérer le modèle sémantique directement (séparément de l’application) lorsque les autorisations de modèle sémantique changent ou doivent être supprimées.
• Les autorisations de modèle sémantique doivent être contrôlées : l’octroi d’autorisations de modèle sémantique via une application supprime le contrôle du propriétaire du modèle sémantique. L’octroi d’une autorisation de repartage repose sur le discernement des utilisateurs qui choisissent de repartager le ou les modèles sémantiques. La gestion des instructions internes de gouvernance ou de sécurité peut gagner en complexité lorsque le repartage est autorisé.
• Les consommateurs et les créateurs ont des objectifs différents. En règle générale, il y a beaucoup plus de consommateurs que de créateurs de contenus dans une organisation. Conformément au principe du moindre privilège, les consommateurs ont uniquement besoin d’une autorisation de lecture pour le modèle sémantique sous-jacent. Ils n’ont pas besoin d’autorisation de génération, sauf s’ils ont l’intention de créer de nouveaux rapports.

Conseil

Pour savoir quand utiliser des espaces de travail de données et des espaces de travail de rapports distincts, consultez l’article Planification au niveau de l’espace de travail.

Droits de préinstallation d’application

Après avoir publié une application Power BI, l’utilisateur doit généralement l’installer pour l’ouvrir. L’utilisateur peut installer une application depuis la page Applications du service Power BI ou avec le lien qu’il a reçu d’un autre utilisateur. Il peut rechercher (et installer) une application lorsqu’il figure dans au moins une audience de l’application.

Pour installer une application, vous pouvez aussi adresser une transmission de type push aux consommateurs d’applications. Cela entraîne la préinstallation de l’application, de sorte qu’elle apparaît automatiquement dans la page Applications du service Power BI. Cette approche est pratique pour les consommateurs, car ils n’ont pas besoin de rechercher ni d’installer l’application. Toutefois, les applications préinstallées peuvent gêner les utilisateurs submergés par un trop grand nombre d’applications qui ne sont pas toujours pertinentes.

Le paramètre de locataire Effectuer une transmission de type push des applications pour les utilisateurs finaux identifie les personnes autorisées à installer automatiquement des applications. Nous recommandons d’utiliser cette fonctionnalité pour son aspect pratique. Toutefois, nous recommandons d’indiquer aux créateurs de contenus quand ils peuvent l’utiliser, afin d’éviter tout abus.

Conseil

Lorsque vous publiez une application et si vous sélectionnez l’option permettant d’installer automatiquement l’application, vous ne pouvez pas définir une audience comme une organisation entière (si elle est activée par le paramètre de locataire Effectuer une transmission de type push des applications pour les utilisateurs finaux).

Liste de vérification : voici les décisions et les actions clés pour créer une stratégie liée à l’utilisation des applications par les viewers de contenus :

• Choisir la stratégie d’utilisation des applications. Définissez vos préférences concernant l’utilisation des applications. Vérifiez qu’elle est en phase avec votre stratégie globale pour les consommateurs en lecture seule.
• Décider qui peut publier des applications dans l’ensemble de l’organisation. Déterminez quels créateurs de rapports peuvent publier dans l’ensemble de l’organisation. Définissez le paramètre de locataire Publier des applications sur l’ensemble de l’organisation pour l’aligner sur cette décision.
• Déterminer qui peut effectuer une transmission de type push des applications pour les utilisateurs finaux. Déterminez quels créateurs de rapports Power BI peuvent préinstaller des applications. Définissez le paramètre de locataire Effectuer une transmission de type push des applications pour les utilisateurs finaux en fonction de cette décision.
• Créer et publier des instructions pour les créateurs de contenus. Communiquez les documents et les formations aux créateurs de contenus. Incluez les exigences et les préférences concernant l’utilisation optimale des applications.
• Déterminer comment gérer les demandes d’accès aux applications. Assurez-vous qu’il existe un processus pour affecter des contacts et gérer les demandes d’accès aux applications dans les délais impartis.

Rôle Viewer de l’espace de travail

Comme décrit dans les articles sur la planification de l’espace de travail, l’objectif principal d’un espace de travail est la collaboration. Les collaborateurs de l’espace de travail (comme les créateurs de modèle sémantique, les créateurs de rapports et les testeurs) doivent être affectés à l’un de ces trois rôles : Contributeur, Membre ou Administrateur. Ces rôles sont décrits dans l’article sur la planification de la sécurité du créateur de contenus.

Vous pouvez attribuer le rôle Viewer de l’espace de travail aux consommateurs. Il peut être judicieux pour les petites équipes et les équipes informelles qui travaillent en étroite collaboration d’autoriser les consommateurs à accéder directement aux contenus d’un espace de travail.

Il est pertinent d’autoriser les consommateurs à accéder directement aux contenus de l’espace de travail dans les cas suivants :

• La formalité d’une application, avec ses autorisations distinctes, n’est pas nécessaire.
• Les viewers sont autorisés à afficher tous les éléments stockés dans l’espace de travail.
• Vous souhaitez que la gestion des autorisations soit plus simple que celle des autorisations par élément.
• Les utilisateurs de l’espace de travail peuvent également afficher une application (lorsqu’elle a été publiée pour l’espace de travail).
• L’objectif est que les utilisateurs examinent les contenus avant leur publication dans une application.

Voici quelques suggestions pour aider les viewers de l’espace de travail.

• Organisez les contenus dans chaque espace de travail afin que les consommateurs de rapports localisent facilement les éléments et qu’ils soient cohérents en termes de sécurité. L’organisation de l’espace de travail par domaine ou projet fonctionne généralement bien.
• Séparez les contenus de développement et de test des contenus de production afin que les viewers ne puissent pas accéder aux éléments de travail en cours.
• Utilisez les applications (ou des autorisations par élément, le cas échéant) lorsque vous prévoyez de traiter de nombreuses demandes d’accès. Il n’existe pas de workflow de demande d’accès pour les espaces de travail.

Liste de vérification : voici les décisions et les actions clés pour créer une stratégie liée à l’utilisation des espaces de travail par les viewers de contenus :

• Choisir la stratégie d’utilisation du rôle Viewer de l’espace de travail. Définissez vos préférences pour l’utilisation des espaces de travail pour les consommateurs. Vérifiez qu’elle est en phase avec votre stratégie globale pour les consommateurs en lecture seule.
• Créer et publier des instructions pour les créateurs de contenus. Communiquez les documents et les formations aux créateurs de contenus. Incluez les exigences et les préférences concernant l’utilisation optimale des autorisations d’espace de travail.

Autorisations par élément

Le partage d’un élément individuel accorde l’autorisation pour un seul élément. Les créateurs de contenus moins expérimentés utilisent généralement cette technique comme solution de partage principale. En effet, les commandes de partage apparaissent clairement dans le service Power BI. Pour cette raison, il est important d’informer les créateurs de contenus sur les différentes options de partage. Ils doivent savoir quand utiliser les autorisations d’application plutôt que les rôles de l’espace de travail.

Il est pertinent d’utiliser les autorisations par élément dans les cas suivants :

• Vous souhaitez octroyer un accès en lecture seule à un élément (rapport ou tableau de bord).
• Vous ne souhaitez pas que le consommateur puisse consulter tous les contenus publiés dans un espace de travail.
• Vous ne souhaitez pas que le consommateur puisse consulter tous les contenus publiés dans une audience d’application.

Utilisez les autorisations par élément avec parcimonie, car le partage n’accorde l’autorisation de lecture qu’à un seul élément. D’une certaine façon, vous pouvez considérer que les autorisations par élément viennent en remplacement des rôles de l’espace de travail ou des autorisations d’application.

Conseil

Nous recommandons d’utiliser les autorisations d’application dès que possible. Envisagez ensuite d’utiliser les rôles de l’espace de travail pour activer l’accès direct à l’espace de travail. Enfin, utilisez les autorisations par élément lorsqu’elles répondent aux critères ci-dessus. Les autorisations d’application et les rôles de l’espace de travail spécifient la sécurité d’une collection de contenus (plutôt que des éléments individuels). Cette pratique est meilleure en termes de sécurité.

Le partage de nombreux éléments avec autorisations par élément peut être fastidieux et sujet aux erreurs, en particulier lorsque le partage concerne des utilisateurs individuels et non des groupes. Examinez ce scénario : vous avez partagé 40 rapports avec vos collaborateurs en utilisant leurs comptes d’utilisateur individuels. Quand un collaborateur est transféré dans un autre service, vous devez révoquer son accès. Cela implique de modifier les autorisations pour les 40 rapports.

Important

Le partage de contenus depuis un espace de travail personnel doit être très occasionnel. Les espaces de travail personnels se révèlent plus adaptés aux contenus non critiques, informels ou temporaires. Lorsque les créateurs de contenus partagent fréquemment des contenus importants ou critiques depuis leurs espaces de travail personnels, vous devez prendre les actions appropriées pour déplacer ces contenus vers un espace de travail standard. Pour plus d’informations, consultez le scénario d’utilisation du décisionnel personnel.

Lorsque vous partagez un élément individuel, vous disposez de plusieurs options d’autorisation.

• Autorisation de repartage : lorsque cette option est activée, les utilisateurs peuvent partager l’élément avec d’autres utilisateurs, y compris les modèles sémantiques sous-jacents. Il est logique d’accorder cette autorisation lorsque l’élément peut être facilement partagé avec quiconque. Elle supprime le contrôle de la personne ou de l’équipe qui gère l’élément. Par conséquent, elle s’appuie sur le discernement des utilisateurs auxquels l’autorisation de repartage est accordée. Cependant, la gestion des instructions de gouvernance ou de sécurité internes peut gagner en complexité lorsque le repartage est autorisé.
• Autorisation de génération : lorsque cette option est activée, les utilisateurs disposent de l’autorisation de génération pour le modèle sémantique sous-jacent. L’autorisation de génération permet aux utilisateurs de créer des contenus basés sur le modèle sémantique. Elle leur permet également d’exporter des données sous-jacentes à partir de rapports, et bien plus encore. L’article sur la planification de la sécurité du créateur de contenus décrit les considérations relatives à l’octroi de l’autorisation de génération.

L’utilisation des autorisations par élément pour les rapports et les tableaux de bord peut être pertinente avec des scénarios informels, lorsque les contenus sont partagés avec un petit nombre d’utilisateurs. Il est judicieux de former les utilisateurs à utiliser les applications et les espaces de travail pour gérer les autorisations, en particulier lorsqu’ils partagent des contenus avec un grand nombre d’utilisateurs ou en dehors de leur équipe. Il convient de souligner les points ci-dessous.

• Déterminer quels contenus ont été partagés avec quels utilisateurs devient plus difficile. En effet, les autorisations pour chaque rapport et tableau de bord doivent être examinées individuellement.
• Dans de nombreux cas, l’autorisation de repartage est configurée, car l’expérience utilisateur active cette option par défaut. Il existe donc un risque que les contenus soient partagés avec un ensemble d’utilisateurs plus large que prévu. Pour empêcher cela, décochez l’option Autoriser les destinataires à partager ce rapport lors du partage. Cette méthode pour réduire le partage excessif de cette façon relève de la formation des utilisateurs. Un créateur de contenus qui configure les autorisations de partage doit toujours étudier un tel choix.
• Toutes les modifications apportées aux rapports et aux tableaux de bord sont visibles immédiatement par les autres utilisateurs, ce qui risque de les perturber lorsqu’un contenu est en cours de modification. Pour atténuer ce problème, distribuez les contenus dans une application ou utilisez des espaces de travail distincts pour dissocier les contenus de développement, de test et de production. Pour plus d’informations, consultez le scénario d’utilisation sur la publication de contenus en libre-service.
• Lorsqu’un utilisateur partage des contenus depuis son espace de travail personnel et qu’il quitte l’organisation, l’équipe informatique désactive généralement son compte d’utilisateur. Dans ce cas, tous les destinataires des contenus partagés perdent aussitôt l’accès à ces contenus.

Il existe trois types de partage spécifiques : le partage par lien, le partage avec accès direct et les vues partagées.

Liens d’autorisation par élément

Lorsque vous partagez un élément individuel, l’expérience par défaut génère un lien de partage. Il existe trois types de liens de partage.

• Utilisateurs de votre organisation : lorsque cette option est activée dans les paramètres de locataire Power BI, ce type de liens de partage offre un moyen simple pour octroyer un accès en lecture seule à tous les membres de l’organisation. Toutefois, le lien de partage ne fonctionne pas pour les utilisateurs externes. Cette option est la plus adaptée lorsque tous les collaborateurs peuvent consulter le contenu et que le lien peut être partagé librement dans l’ensemble de l’organisation. Sauf s’il est désactivé par le paramètre de locataire Autoriser les liens partageables pour accorder l’accès à tous les membres de votre organisation, il s’agit du type de partage par défaut.
• Utilisateurs qui ont déjà un accès : cette option ne crée pas de lien de partage. Au lieu de cela, elle permet de récupérer l’URL pour l’envoyer à une personne qui y a déjà accès.
• Personnes spécifiques : cette option génère un lien de partage pour des utilisateurs ou des groupes spécifiques. Nous recommandons d’utiliser cette option dans la plupart des cas, car elle fournit un accès spécifique. Si vous collaborez couramment avec des utilisateurs externes, vous pouvez utiliser ce type de lien pour des utilisateurs invités qui existent déjà dans Microsoft Entra ID (précédemment appelé Azure Active Directory). Pour plus d’informations sur le processus d’invitation planifiée permettant de créer des utilisateurs invités, consultez l’article sur la planification de la sécurité au niveau du locataire.

Important

Nous vous recommandons de limiter le paramètre de locataire Autoriser les liens partageables pour accorder l’accès à tous les membres de votre organisation aux membres d’un groupe. Vous pouvez créer un nom de groupe tel que Partage Power BI pour l’ensemble de l’organisation, puis ajouter un petit nombre d’utilisateurs conscients des implications liées au partage à l’échelle de l’organisation. Pour en savoir plus sur les liens qui existent à l’échelle de l’organisation, utilisez l’API administrateur pour rechercher tous les éléments qui ont été partagés avec l’ensemble de l’organisation.

Un lien de partage ajoute une autorisation de lecture à un élément. L’autorisation de repartage est sélectionnée par défaut. Vous pouvez également ajouter une autorisation de génération au modèle sémantique sous-jacent lors de la création du lien de partage.

Conseil

Nous recommandons de former les créateurs de contenus à activer l’option d’autorisation de génération uniquement lorsque le consommateur du rapport est lui aussi un créateur de contenus et peut avoir besoin de créer des rapports, d’exporter des données ou de créer un modèle composite à partir du modèle sémantique sous-jacent.

Les liens de partage sont plus faciles à gérer que les partages avec accès direct, en particulier lorsque vous effectuez des modifications en bloc. Ils offrent un net avantage lorsque les autorisations de partage sont accordées à des utilisateurs individuels et non à des groupes. (Cela se produit généralement lorsque les utilisateurs en libre-service sont responsables de la gestion des autorisations.) Voici un comparatif :

• Lien de partage : 20 utilisateurs individuels bénéficient d’un accès avec lien de partage. Une simple modification du lien affecte les 20 utilisateurs.
• Accès direct : 20 utilisateurs disposent d’un accès direct à un élément. Pour apporter une modification, vous devez modifier les 20 autorisations.

Autorisations d’accès direct par élément

Vous pouvez également définir des autorisations par élément en utilisant l’accès direct. L’accès direct implique de configurer les autorisations pour un élément unique. Vous pouvez également déterminer les autorisations héritées à partir des rôles de l’espace de travail.

Lorsque vous octroyez un accès direct à un utilisateur, il dispose d’une autorisation de lecture pour l’élément. L’autorisation de repartage est sélectionnée par défaut (comme l’autorisation de génération) pour le modèle sémantique sous-jacent. Nous recommandons de former les créateurs de contenus à activer l’option d’autorisation de génération uniquement lorsque le consommateur du rapport est lui aussi un créateur de contenus et peut avoir besoin de créer des rapports, d’exporter des données ou de créer un modèle composite à partir du modèle sémantique sous-jacent.

Conseil

Même si l’expérience utilisateur simplifie l’octroi des autorisations de repartage et de génération, l’utilisateur qui effectue le partage doit toujours vérifier si ces autorisations sont nécessaires.

Vues partagées

Utilisez une vue partagée pour partager la perspective filtrée d’un rapport avec un autre utilisateur. Vous pouvez publier une vue partagée à l’aide d’un lien de partage ou d’un accès direct.

Les vues partagées sont un concept temporaire. Elles expirent automatiquement au bout de 180 jours. Pour cette raison, les vues partagées sont les plus adaptées aux scénarios de partage informels et temporaires. Assurez-vous que vos utilisateurs ont été informés de cette limitation.

Liste de vérification : voici les décisions et les actions clés pour créer une stratégie liée à utilisation des autorisations par élément :

• Choisir la stratégie d’utilisation de la fonctionnalité de partage. Définissez vos préférences pour l’utilisation des autorisations par élément. Vérifiez qu’elle est en phase avec votre stratégie globale pour les consommateurs en lecture seule.
• Décider qui peut publier des liens dans l’ensemble de l’organisation. Déterminez quels créateurs de rapports peuvent publier des liens pour l’ensemble de l’organisation. Configurez le paramètre de locataire Autoriser les liens partageables pour accorder l’accès à tous les membres de votre organisation en fonction de cette décision.
• Créer et publier des instructions pour les créateurs de contenus. Communiquez les documents et les formations aux créateurs de contenus, notamment les exigences et les préférences concernant l’utilisation optimale des autorisations par élément. Assurez-vous qu’ils exposent clairement les avantages et les inconvénients des autorisations par élément. Apportez des instructions sur quand utiliser les liens de partage et les accès directs.

Autres techniques de requête consommateur

Pour interagir avec Power BI, les consommateurs emploient le plus souvent les applications, les espaces de travail et les autorisations par élément (décrites précédemment dans cet article).

D’autres techniques permettent aux consommateurs d’interroger les données Power BI. Chacune des techniques de requête ci-dessous exige une autorisation de génération pour un modèle sémantique ou un datamart.

• Analyser dans Excel : les consommateurs qui préfèrent utiliser Excel peuvent interroger un modèle sémantique Power BI avec l’option Analyser dans Excel. Cette fonctionnalité offre une excellente alternative à l’exportation de données vers Excel, car celles-ci ne sont pas dupliquées. Avec une connexion active au modèle sémantique, les utilisateurs peuvent créer des tableaux croisés dynamiques, des graphiques et des segments. Ils peuvent ensuite publier le classeur dans un espace de travail du service Power BI. Cela permet aux consommateurs de l’ouvrir et d’interagir avec lui.
• Point de terminaison XMLA : les consommateurs peuvent interroger un modèle sémantique en se connectant au point de terminaison XMLA. Une application compatible XMLA peut se connecter à un modèle sémantique stocké dans un espace de travail Premium pour l’interroger et l’utiliser. Cette fonctionnalité est utile lorsque les consommateurs souhaitent utiliser un modèle sémantique Power BI comme source de données d’un outil de visualisation des données en dehors de l’écosystème Microsoft.
• Éditeur de datamart : les consommateurs peuvent interroger un datamart Power BI à l’aide de l’éditeur de datamart. Il s’agit d’un éditeur de requêtes visuelles basé sur le web qui permet de créer des requêtes sans code. Les consommateurs qui préfèrent écrire leurs requêtes SQL disposent également d’un éditeur SQL basé sur le web. Les deux éditeurs interrogent la base Azure SQL Database managée, laquelle est sous-jacente au datamart Power BI (plutôt qu’au modèle sémantique intégré).
• Point de terminaison SQL : les consommateurs peuvent interroger un datamart Power BI à l’aide du point de terminaison SQL. Ils peuvent utiliser des outils comme Azure Data Studio ou SQL Server Management Studio (SSMS) pour exécuter les requêtes SQL. Le point de terminaison SQL interroge la base Azure SQL Database managée, laquelle est sous-jacente au datamart Power BI (plutôt qu’au modèle sémantique intégré).

Pour plus d’informations sur les autorisations de génération, consultez l’article sur la planification de la sécurité du créateur de contenus.

Liste de vérification : voici les décisions et les actions clés pour planifier la stratégie d’utilisation des techniques de requête par les consommateurs :

• Créer des instructions pour les utilisateurs sur l’utilisation de l’analyse dans Excel. Communiquez les documents et les formations aux consommateurs concernant la réutilisation optimale des modèles sémantiques existants avec Excel.
• Créer des instructions pour les utilisateurs sur l’utilisation du point de terminaison XMLA. Communiquez les documents et les formations aux consommateurs concernant la réutilisation optimale des modèles sémantiques existants avec le point de terminaison XMLA.
• Créer des instructions pour les utilisateurs sur l’utilisation des requêtes de datamart. Communiquez les documents et les formations aux consommateurs concernant les techniques d’interrogation des datamarts Power BI.

Workflow de demande d’accès pour les consommateurs

Lors du partage de contenus, il est courant qu’un utilisateur transfère un lien (URL) à un autre utilisateur. Lorsque le destinataire tente d’afficher le contenu et découvre qu’il n’y a pas accès, il peut utiliser le bouton Demander l’accès. Cette action lance le workflow de demande d’accès. L’utilisateur est ensuite invité à saisir un message exposant les raisons pour lesquelles il souhaite y accéder.

Le workflow de demande d’accès existe dans les cas suivants :

• Accès à une application Power BI
• Accès à un élément, comme un rapport ou un tableau de bord
• Accéder à un modèle sémantique. Pour plus d’informations sur le workflow de demander d’accès lorsqu’un modèle sémantique est détectable, consultez l’article sur la planification de la sécurité du créateur de contenus.

Demandes d’accès aux applications

Pour en savoir plus sur les demandes d’accès en attente qui ont été envoyées pour une application, deux solutions s’offrent à vous.

• Email : le ou les contacts de l’application reçoivent une notification par e-mail. Par défaut, ce contact est l’éditeur de l’application. Pour une prise en charge optimale des applications critiques, nous recommandons de définir ce contact sur un groupe capable de répondre rapidement aux demandes d’accès.
• Menu Gérer les autorisations : les administrateurs et les membres de l’espace de travail peuvent afficher, approuver ou refuser les demandes d’accès. La page Gérer les autorisations est disponible depuis la page Applications et peut être ouverte pour chaque application. Cette fonctionnalité est également accessible aux contributeurs d’espace de travail, lorsque le paramètre Autoriser les contributeurs à mettre à jour l’application pour cet espace de travail est activé.

Les demandes d’accès en attente pour une application affichent le message fourni par l’utilisateur. Chaque demande en attente peut être approuvée ou refusée. Lorsque vous approuvez une demande, vous devez sélectionner une audience d’application.

La capture d’écran suivante représente une demande d’accès en attente pour un utilisateur. Pour l’approuver, l’une des deux audiences d’application [Sales Reps (Représentants commerciaux) ou Sales Leadership (Direction commerciale)] doit être sélectionnée.

Lorsque vous publiez une application, les contenus et les autorisations sont publiés en même temps. Comme indiqué précédemment, vous ne pouvez pas publier uniquement les autorisations d’application (sans les modifications de contenu). Cependant, un cas fait figure d’exception : lorsque vous approuvez une demande d’accès en attente (comme celle présentée dans la capture d’écran ci-dessus), la modification des autorisations est effective sans que le contenu le plus récent soit publié dans l’espace de travail.

Demandes d’accès aux espaces de travail

L’accès à un espace de travail est octroyé par les utilisateurs qui disposent d’un rôle d’administrateur ou de membre.

Un utilisateur qui tente de consulter un espace de travail sans en être membre reçoit un message d’accès refusé. En l’absence de workflow de demande d’accès intégré, les espaces de travail sont plus adaptés aux petites équipes et aux équipes informelles qui travaillent en étroite collaboration. C’est l’une des raisons pour lesquelles l’utilisation d’une application Power BI convient mieux aux équipes de plus grande taille et aux scénarios de distribution de contenus plus étendus.

Demandes d’accès par élément

Pour en savoir plus sur les demandes d’accès en attente qui ont été envoyées pour un élément individuel (comme un rapport), deux solutions s’offrent à vous.

• Email : le ou les contacts de l’élément reçoivent une notification par e-mail. Pour une prise en charge optimale des rapports critiques, nous recommandons de définir ce contact sur un groupe capable de répondre rapidement aux demandes d’accès.
• Menu Gérer les autorisations : les administrateurs et les membres de l’espace de travail peuvent accéder à la page Gérer les autorisations de chaque élément. Ils peuvent afficher, approuver ou refuser les demandes d’accès en attente.

Gérer les demandes d’accès pour un groupe

Lorsqu’un utilisateur envoie le formulaire de demander d’accès pour un élément Power BI (comme un rapport ou un modèle sémantique) ou une application Power BI, la demande concerne un utilisateur individuel. Toutefois, nombreuses sont les organisations de grande taille qui doivent utiliser les groupes pour se conformer à leurs stratégies de sécurité internes.

Pour sécuriser les contenus, nous recommandons d’utiliser les groupes (plutôt que les utilisateurs individuels) dès que possible. Pour plus d’informations sur les groupes, consultez l’article sur la planification de la sécurité au niveau du locataire.

Pour octroyer un accès à des groupes plutôt qu’à des utilisateurs individuels, le propriétaire de contenus ou l’administrateur qui traite la demande d’accès doit décomposer la demande en plusieurs étapes :

1. Refusez la demande en attente dans Power BI (car elle est associée à un utilisateur individuel).
2. Ajoutez le demandeur au groupe qui convient, conformément au processus en place.
3. Informez le demandeur qu’il dispose maintenant d’un accès.

Conseil

Pour plus d’informations sur la réponse aux demandes d’accès en génération des créateurs de contenus, consultez le workflow de demande d’accès pour les créateurs. Vous y trouverez également des recommandations sur l’utilisation d’un formulaire pour les demandes d’accès.

Check-list : voici les décisions et actions clés pour planifier le workflow de demande d’accès :

• Déterminer comment traiter les demandes d’accès aux applications. Assurez-vous qu’il existe un processus pour gérer les demandes d’accès aux applications dans les délais impartis. Vérifiez que l’affectation des contacts de l’application est compatible avec le processus.
• Déterminer comment traiter les demandes d’accès par élément. Assurez-vous qu’il existe un processus pour gérer les demandes d’accès par élément dans les délais impartis. Vérifiez que l’affectation des contacts est compatible avec le processus.
• Intégrer ces informations dans les documents et les formations pour créateurs de contenus. Assurez-vous que les créateurs de contenus savent comment gérer les demandes d’accès dans les délais impartis. Apprenez-leur à traiter les demandes lorsqu’un groupe est utilisé à la place d’un utilisateur individuel.
• Intégrer ces informations dans les documents et les formations. Créez des instructions pour les créateurs de contenus concernant la gestion optimale des demandes d’accès. Créez également des instructions pour les consommateurs concernant les informations à inclure dans leur message de demande d’accès.

Déployer la sécurité des données en fonction de l’identité des consommateurs

Vous pouvez planifier la création de moins de modèles sémantiques et de rapports en appliquant la sécurité des données. L’objectif est d’appliquer la sécurité des données en fonction de l’identité de l’utilisateur qui consulte le contenu.

Par exemple, vous pouvez partager un même rapport commercial avec l’ensemble des commerciaux (consommateurs), en sachant que chaque commercial accédera uniquement aux résultats de sa région. Cette approche simplifie le processus, puisque vous n’avez pas à créer différents rapports par région, ni à les partager avec les commerciaux de la région commerciale en question.

Certaines organisations ont des exigences spécifiques concernant les modèles sémantiques ou les datamarts approuvés (certifiés ou diffusés). Pour les données massivement utilisées, il peut être nécessaire de déployer la sécurité des données.

Pour déployer la sécurité des données, plusieurs solutions s’offrent à vous.

• Modèle sémantique Power BI : en tant que créateur de données Power BI, vous pouvez déployer la sécurité au niveau des lignes (SNL) et la sécurité au niveau des objets (SNO). La SNL implique de définir les rôles et les règles qui filtrent les lignes du modèle de données. De son côté, la SNO limite l’accès à des tables ou des colonnes spécifiques. Ces règles SNL et OLS définies ne s’appliquent pas aux références stockées en dehors du modèle sémantique, comme les sélections de segment et de filtre. Les techniques RLS et OLS sont décrites plus loin dans cette section.
• Analysis Services : vous pouvez connecter un modèle sémantique avec une connexion active à un modèle de données distant, qui est hébergé par Azure Analysis Services (AAS) ou SQL Server Analysis Services (SSAS). Le modèle distant peut déployer la SNL ou la SNO en fonction de l’identité des consommateurs.
• Source de données : certaines sources de données (comme Azure SQL Database) peuvent déployer la SNL. Dans ce cas, le modèle Power BI peut exploiter la sécurité existante plutôt que de la redéfinir. Cette approche présente un net avantage lorsque la SNL définie dans la source est complexe. Pour activer l’authentification unique (SSO), vous pouvez développer et publier un modèle DirectQuery, puis définir les informations d’identification de la source de données du modèle sémantique dans le service Power BI. Lorsqu’un consommateur de rapports ouvre un rapport, Power BI transmet son identité à la source de données. La source de données applique ensuite RLS en fonction de l’identité du consommateur de rapports. Pour plus d’informations sur la SNL Azure SQL Database, consultez cet article.

Notes

Les systèmes sources (Azure SQL Database, par exemple) peuvent aussi employer certaines techniques comme les vues pour limiter ce que l’utilisateur peut afficher. Même s’il s’agit d’une technique valide, elle ne relève pas de la présente section.

Sécurité au niveau des lignes

La sécurité au niveau des lignes (RLS) permet à un modélisateur de données de restreindre l’accès à un sous-ensemble de données. Elle est souvent employée pour s’assurer que certaines données (comme les résultats commerciaux d’autres régions) ne sont pas accessibles à certains consommateurs de rapports.

Conseil

Si un utilisateur crée plusieurs modèles de données pour différents groupes de consommateurs, vérifiez si la SNL répond aux exigences. En général, mieux vaut créer, tester et gérer un seul modèle de données plutôt que plusieurs.

Faites attention, car si un rapport Power BI fait référence à une ligne avec SNL configuré, le même message s’affiche comme pour un champ supprimé ou non existant. Pour ces utilisateurs, le rapport semble corrompu.

Deux étapes permettent de configurer la SNL : les règles et les mappages de rôles.

Règles RLS

Pour les modèles sémantiques, vous pouvez utiliser un modélisateur de données pour configurer la SNL dans Power BI Desktop en créant un ou plusieurs rôles. Un rôle a un nom unique dans le modèle et comprend généralement une ou plusieurs règles. Les règles appliquent des filtres au niveau des tables du modèle en utilisant des expressions de filtre DAX (Data Analysis Expressions). Par défaut, un modèle de données n’a pas de rôles.

Important

En l’absence de rôles, les utilisateurs (qui ont l’autorisation d’interroger le modèle de données) ont accès à toutes les données du modèle.

Les expressions des règles sont évaluées dans le contexte de ligne. Cela signifie que l’expression est évaluée pour chaque ligne, selon les valeurs de colonne de la ligne en question. Quand l’expression retourne TRUE, l’utilisateur peut voir la ligne. Vous pouvez définir des règles statiques ou dynamiques.

• Règles statiques : elles utilisent des expressions DAX qui renvoient à des constantes, comme [Region] = "Midwest".
• Règles dynamiques : elles utilisent des fonctions DAX spécifiques qui renvoient des valeurs environnementales (et non des constantes). Les valeurs environnementales sont renvoyées pour les trois fonctions DAX suivantes : USERNAME, USERPRINCIPALNAME et CUSTOMDATA. La définition de règles dynamiques est simple et efficace quand une table de modèle stocke les valeurs de nom d’utilisateur. Ils vous permettent d’appliquer une conception de sécurité au niveau des lignes pilotée par les données.

Mappages de rôles de SNL

Une fois le modèle publié sur le service Power BI, vous devez configurer les mappages de rôles avant que les utilisateurs accèdent aux rapports associés. Le mappage de rôles implique l’attribution d’objets de sécurité Microsoft Entra aux rôles. Les objets de sécurité peuvent être des comptes d’utilisateurs ou des groupes de sécurité.

La meilleure pratique consiste à mapper les rôles vers des groupes de sécurité dès que possible. Cela permet de réduire le nombre de mappages et de confier la gestion des appartenances au groupe au propriétaire du groupe.

Nous vous recommandons de fournir aux créateurs de contenus les informations de compte de sécurité de Microsoft Entra. Vous pouvez créer un flux de données avec des données synchronisées avec Microsoft Entra ID. Cela permet aux créateurs de contenus d’intégrer les données des flux de données pour générer un modèle sémantique piloté par les données.

Conseil

Il est possible de définir un rôle sans règles. Dans ce cas, le rôle donne accès à l’ensemble des lignes de toutes les tables du modèle. La configuration de ce type de rôles est adaptée lorsqu’un administrateur ou un utilisateur est autorisé à afficher toutes les données dans le modèle.

Expérience utilisateur de la SNL

Certaines organisations choisissent d’utiliser la SNL comme couche de sécurité secondaire, en plus des autorisations Power BI standard. Examinez le scénario suivant : vous partagez un lien vers un rapport avec l’ensemble de l’organisation. Tout utilisateur qui consulte le rapport doit être mappé vers un rôle de SNL pour afficher les données du rapport. Dans le cas contraire, aucune donnée n’est affichée.

La SNL modifie l’expérience par défaut des consommateurs.

• Lorsque la SNL n’est pas définie pour le modèle sémantique : les créateurs et les consommateurs qui disposent au moins d’une autorisation de lecture sur le modèle sémantique peuvent consulter toutes les données du modèle sémantique.
• Lorsque la SNL est définie pour le modèle sémantique : les créateurs et les consommateurs qui disposent uniquement d’une autorisation de lecture sur le modèle sémantique ne peuvent consulter que les données qu’ils sont autorisés à afficher (en fonction de mappage de rôles de SNL).

Remarque

Certaines organisations déploient la SNL comme une couche de sécurité supplémentaire, en particulier en présence de données sensibles. C’est pourquoi vous pouvez choisir d’exiger la SNL pour les modèles sémantiques certifiés. L’adoption d’un processus d’examen et d’approbation internes en amont de la certification du modèle sémantique permet de répondre à cette exigence.

Quand un utilisateur consulte un rapport dans un espace de travail ou une application, la SNL peut ou pas être appliquée en fonction de ses autorisations sur le modèle sémantique. Il est donc essentiel que les consommateurs et les créateurs de contenus disposent uniquement de l’autorisation de lecture sur le modèle sémantique sous-jacent lorsque la SNL doit être déployée.

Voici les règles d’autorisation qui déterminent si la SNL est déployée.

• L’utilisateur dispose d’une autorisation de lecture sur le modèle sémantique. La SNL est déployée pour l’utilisateur.
• L’utilisateur dispose d’une autorisation de lecture et de génération sur le modèle sémantique. La SNL est déployée pour l’utilisateur.
• L’utilisateur dispose d’une autorisation d’écriture sur le modèle sémantique. La SNL n’est pas déployée pour l’utilisateur. Il peut ainsi afficher toutes les données du modèle sémantique. L’autorisation d’écriture permet de modifier un modèle sémantique. Pour l’octroyer, deux solutions s’offrent à vous :
  • Avec les rôles de contributeur, de membre ou d’administrateur de l’espace de travail (pour l’espace de travail sur lequel se trouve le modèle sémantique).
  • Avec l’autorisation de modèle sémantique d’écriture par élément.

Conseil

Pour plus d’informations sur l’utilisation de différents espaces de travail de sorte que la SNL fonctionne pour les créateurs de contenus, consultez le scénario d’utilisation sur le décisionnel libre-service managé.

Pour plus d’informations sur la SNL, consultez l’article sur comment restreindre l’accès aux données de modèle Power BI.

SNL pour les datamarts

Les datamarts Power BI peuvent également déployer la SNL. Toutefois, l’implémentation est différente.

La principale différence concerne la configuration de la SNL pour les datamarts, qui s’effectue dans le service Power BI, et non dans Power BI Desktop.

Autre différence, les datamarts appliquent la SNL sur le modèle sémantique et sur la base de données Azure SQL managée associée au datamart. Le déploiement de la SNL sur ces deux couches garantit cohérence et flexibilité. Quelle que soit la façon dont l’utilisateur interroge les données (en se connectant au modèle sémantique ou à la base de données Azure SQL managée), les mêmes filtres de SNL sont utilisés.

Pour plus d’informations, consultez l’article sur la SNL pour les datamarts.

Sécurité au niveau des objets

La sécurité au niveau de l’objet (OLS) permet à un modélisateur de données de restreindre l’accès à des tables et colonnes spécifiques, ainsi qu’à leurs métadonnées. En général, la SNO est utilisée pour s’assurer que les colonnes sensibles (comme le salaire des collaborateurs) ne sont pas visibles par certains utilisateurs. Même s’il est impossible de restreindre l’accès aux mesures, toute mesure qui renvoie à une colonne restreinte est elle-même restreinte.

Examinez cet un exemple de table d’un collaborateur. Elle comporte des colonnes qui stockent le nom et le numéro de téléphone du collaborateur, ainsi que son salaire. Vous pouvez utiliser la SNO pour vous assurer que seuls certains utilisateurs, (comme les membres seniors des ressources humaines) peuvent accéder aux valeurs concernant le salaire. Pour les utilisateurs qui ne peuvent pas afficher ces valeurs, la colonne ne semble pas exister.

Attention, si un visuel de rapport Power BI inclut un salaire, les utilisateurs qui n’ont pas accès à ce champ reçoivent un message d’erreur. Celui-ci les informe que l’objet n’existe pas. Pour ces utilisateurs, le rapport semble corrompu.

Notes

Vous pouvez également définir des perspectives dans un modèle de données. Une perspective définit des sous-ensembles visibles d’objets de modèle pour offrir un focus spécifique aux créateurs de rapport. Les perspectives ne sont pas destinées à restreindre l’accès aux objets de modèle. L’utilisateur peut toujours interroger une table ou une colonne, et ce même s’il ne peut pas l’afficher. Par conséquent, abordez les perspectives comme un outil pratique pour l’utilisateur (et non une fonctionnalité de sécurité).

À l’heure actuelle, il n’existe aucune interface dans Power BI Desktop permettant de configurer la SNO. Vous pouvez utiliser l’éditeur tabulaire, un outil tiers qui permet de créer, d’actualiser et de gérer des modèles. Pour plus d’informations, consultez le scénario d’utilisation Gestion avancée du modèle de données.

Pour plus d’informations sur la SNO, consultez l’article sur comment restreindre l’accès aux objets de modèle Power BI.

Liste de vérification : voici les décisions et les actions clés pour planifier la SNL et la SNO :

• Choisir la stratégie d’utilisation de la SNL. Déterminez les cas d’usage et les finalités liés à l’utilisation de la sécurité au niveau des lignes.
• Choisir la stratégie d’utilisation de la SNO. Déterminez les cas d’usage et les finalités liés à l’utilisation de la sécurité au niveau des objets.
• Examiner les exigences liées aux contenus certifiés. Si vous disposez d’un processus de définition des exigences liées à la certification d’un modèle sémantique, déterminez s’il faut y inclure les exigences spécifiques à la SNL ou la SNO.
• Créer et publier des instructions pour les utilisateurs. Créez les documents pour les utilisateurs qui incluent les exigences et les préférences concernant l’utilisation de la SNL et de la SNO. Le cas échéant, décrivez comment obtenir les informations sur le mappage d’utilisateurs sur un emplacement centralisé.
• Mettre à jour les supports de formation. Intégrez les informations clés sur les exigences et les préférences concernant la SNL et la SNO dans les supports de formation des utilisateurs. Apportez des exemples, afin que les utilisateurs puissent identifier quand utiliser chaque technique de sécurité des données.

Contenu connexe

Dans le prochain article de cette série, découvrez la planification de la sécurité pour les créateurs de contenus chargés de créer des modèles sémantiques, des flux de données, des datamarts, des rapports ou des tableaux de bord.