Planification de l’implémentation de Power BI : planification de la sécurité du créateur de contenu

Article
11/24/2023

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 la mise en œuvre de Power BI.

Cet article sur la planification de la sécurité décrit des stratégies pour les créateurs de contenu chargés de créer des modèles sémantiques (auparavant appelés jeux de données), des flux de données, des datamarts, des rapports ou des tableaux de bord. 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 contenu : créateurs BI libre-service qui doivent créer, publier, sécuriser et gérer du contenu que d’autres 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 créateurs de contenu. Les créateurs de contenu produisent et publient du contenu qui est consulté par d’autres personnes. Les créateurs de contenu sont l’objet de cet article.

Conseil

Nous vous recommandons de consulter d’abord l’article Planification de la sécurité des consommateurs de rapports. Il décrit des stratégies pour fournir du contenu de manière sécurisée aux consommateurs en lecture seule, notamment comment appliquer la sécurité des données.

Stratégie pour les créateurs de contenu

La base d’un système BI libre-service bien géré commence par les créateurs et les propriétaires de contenu. Ils créent et valident des modèles sémantiques et des rapports. Dans de nombreux cas, les créateurs de contenu configurent également des autorisations pour gérer la sécurité de leur contenu.

Conseil

Nous vous recommandons de favoriser une culture des données qui intègre la sécurité et la protection des données naturellement dans le rôle de chacun. Pour atteindre cet objectif, l’éducation, le soutien et la formation des utilisateurs sont essentiels.

Pour des raisons de sécurité et d’autorisations, considérez qu’il existe deux types de créateurs de contenu : les créateurs de données et les créateurs de rapports. Ils peuvent être chargés de la création et de la gestion du contenu BI d’entreprise ou BI libre-service.

Créateurs de données

Un créateur de données est un utilisateur Power BI qui crée des modèles sémantiques, des flux de données ou des datamarts.

Voici quelques scénarios courants des créateurs de données.

Créer un modèle sémantique : il s’agit de créer et tester un modèle de données dans Power BI Desktop. Il est ensuite publié sur le service Power BI pour être utilisé comme modèle sémantique partagé pour de nombreux rapports. Pour plus d’informations sur la réutilisation des modèles sémantiques partagés, consultez le scénario d’utilisation du décisionnel libre-service managé.
Étendre et personnaliser un modèle sémantique : il s’agit de créer une connexion active à un modèle sémantique partagé existant dans Power BI Desktop. Il faut ensuite convertir la connexion active en modèle local, ce qui permet d’étendre la conception du modèle avec de nouvelles tables ou colonnes. Pour plus d’informations sur l’extension et la personnalisation des modèles sémantiques partagés, consultez le scénario d’utilisation du décisionnel libre-service managé personnalisable.
Créer un flux de données : dans le service Power BI, il s’agit de créer un flux de données utilisé comme source de nombreux modèles sémantiques. Pour plus d’informations sur la réutilisation des activités de préparation de données, consultez le scénario d’utilisation Préparation de données libre-service.
Créer un datamart. Dans le service Power BI, il s’agit de créer un datamart.

Les créateurs de données sont souvent présents dans les équipes BI d’entreprise et dans le Centre d’excellence. Ils ont également un rôle clé à jouer dans les divisions décentralisées, et les services qui entretiennent et gèrent leurs propres données.

Pour d’autres considérations sur le BI piloté par l’entreprise, le BI libre-service managé et le BI d’entreprise, consultez l’article Propriété et gestion du contenu.

Créateurs de rapports

Les créateurs de rapports créent des rapports et des tableaux de bord pour visualiser les données des modèles sémantiques existants.

Voici quelques scénarios courants des créateurs de rapports.

Créer un rapport comprenant un modèle de données : il s’agit de créer et tester un rapport et un modèle de données dans Power BI Desktop. Le fichier Power BI Desktop qui contient une ou plusieurs pages de rapport et comprend un modèle de données est publié sur le service Power BI. Les nouveaux créateurs de contenu utilisent généralement cette méthode avant d’utiliser les modèles sémantiques partagés. Elle est également adaptée aux cas d’usage limités qui n’ont pas besoin de réutiliser les données.
Créer un rapport de connexion active : il s’agit de créer un rapport Power BI qui se connecte à un modèle sémantique partagé dans le service Power BI. Pour plus d’informations sur la réutilisation des modèles sémantiques partagés, consultez le scénario d’utilisation du décisionnel libre-service managé.
Créer un classeur Excel connecté : il s’agit de créer un rapport Excel qui se connecte à un modèle sémantique partagé dans le service Power BI. Les expériences Excel connectées, plutôt que les téléchargements de données, sont fortement encouragées.
Créer un rapport DirectQuery : il s’agit de créer un rapport Power BI qui se connecte à une source de données prise en charge en mode DirectQuery. Cette méthode est utile, par exemple, quand vous voulez tirer parti de la sécurité des utilisateurs implémentée par le système source.

Les créateurs de rapports sont présents dans chaque division de l’organisation. Il y a généralement beaucoup plus de créateurs de rapports dans une organisation que de créateurs de données.

Conseil

Bien que tous les modèles sémantiques ne soient pas des modèles sémantiques partagés, il est toujours utile d’adopter une stratégie de décisionnel libre-service managé. Cette stratégie réutilise les modèles sémantiques partagés dans la mesure du possible. De cette façon, la création de rapports et la création de données sont dissociées. N’importe quel créateur de contenu de n’importe quelle division peut utiliser efficacement cette stratégie.

Autorisations pour les créateurs

Cette section décrit les autorisations les plus courantes pour les créateurs de données et les créateurs de rapports.

Cette section ne présente pas la liste complète de toutes les autorisations possibles. Elle est plutôt destinée à vous aider à planifier votre stratégie pour prendre en charge les différents types de créateur de contenu. Vous devez suivre le principe du moindre privilège. Ce principe autorise suffisamment d’autorisations pour que les utilisateurs soient productifs, sans toutefois en donner trop.

Création de contenu

Les autorisations suivantes sont généralement nécessaires pour créer du contenu.

Permission	Créateur de rapports	Créateur de modèle sémantique	Créateur de flux de données	Créateur de datamarts
Accès à la source de données sous-jacente
Autorisations Lire et Générer sur le modèle sémantique
Autorisation Lire sur le flux de données (quand un flux de données est utilisé comme source, à travers le rôle Lecteur de l’espace de travail)
Accès à l’emplacement de stockage du fichier Power BI Desktop d’origine
Autorisation d’utilisation des visuels personnalisés

Autorisations de publication du contenu

Les autorisations suivantes sont généralement nécessaires pour publier du contenu.

Permission	Créateur de rapports	Créateur de modèle sémantique	Créateur de flux de données	Créateur de datamarts
Rôle d’espace de travail : Contributeur, Membre ou Administrateur
Autorisation Écrire sur le modèle sémantique (quand l’utilisateur n’appartient pas à un rôle d’espace de travail)
Rôle de pipeline de déploiement pour publier des éléments (facultatif)

Actualisation des données

Les autorisations suivantes sont généralement nécessaires pour actualiser les données.

Permission	Créateur de rapports	Créateur de modèle sémantique	Créateur de flux de données	Créateur de datamarts
Propriétaire attribué (qui a configuré les paramètres ou pris le contrôle de l’élément)
Accès à la source de données sous-jacente (quand aucune passerelle n’est utilisée)
Accès à la source de données dans une passerelle (quand la source est locale ou dans un réseau virtuel)

Le reste de cet article décrit les considérations relatives aux autorisations du créateur de contenu.

Conseil

Pour obtenir les autorisations liées à la lecture du contenu, consultez l’article Planification de la sécurité des consommateurs de rapports.

Check-list : voici les décisions et actions clés pour planifier votre stratégie de sécurité pour les créateurs de contenu :

Déterminez qui sont vos créateurs de données : vérifiez que vous savez qui sont les personnes qui créent des modèles sémantiques, des flux de données et des datamarts. Vérifiez que vous comprenez quels sont leurs besoins avant de commencer vos activités de planification de la sécurité.
Déterminez qui sont vos créateurs de rapports : vérifiez que vous savez qui sont les personnes qui créent des rapports, des tableaux de bord, des classeurs et des cartes de performance. Vérifiez que vous comprenez quels sont leurs besoins avant de commencer vos activités de planification de la sécurité.

Découvrir du contenu pour les créateurs

Les utilisateurs peuvent s’appuyer sur la découverte de données pour trouver des modèles sémantiques et des datamarts. La découverte de données est une fonctionnalité Power BI qui permet aux créateurs de contenu de localiser des ressources de données existantes, même s’ils n’ont pas d’autorisations sur ce contenu.

La découverte de données existantes est utile pour :

Créateurs de rapports qui souhaitent utiliser un modèle sémantique existant pour un nouveau rapport.
Les créateurs de rapports qui souhaitent interroger les données d’un datamart existant.
Créateurs de modèles sémantiques qui souhaitent utiliser un modèle sémantique existant pour un nouveau modèle composite.

Remarque

La découverte de données dans Power BI n’est pas une autorisation de sécurité des données. Il s’agit d’un paramètre qui permet aux créateurs de rapports de lire les métadonnées, pour pouvoir découvrir des données et en demander l’accès.

Vous pouvez configurer un modèle sémantique ou un datamart pour qu’il soit découvrable une fois qu’il a été approuvé (certifié ou promu). Quand il est découvrable, les créateurs de contenu peuvent le trouver dans le hub de données.

Un créateur de contenu peut également demander l’accès au modèle sémantique ou au datamart. En substance, une demande d’accès demande l’autorisation Générer, qui est nécessaire pour créer du contenu. Quand vous répondez aux demandes d’accès, utilisez des groupes au lieu d’utilisateurs individuels. Pour plus d’informations sur l’utilisation des groupes à cet effet, consultez Workflow de demande d’accès pour les consommateurs.

Prenez les trois exemples suivants.

Le modèle sémantique Sales Summary est certifié. Il s’agit de la source approuvée et officielle pour le suivi des ventes. De nombreux créateurs de rapports libre-service au sein de l’organisation utilisent ce modèle sémantique. Il existe donc de nombreux rapports et modèles composites basés sur le modèle sémantique. Pour encourager d’autres créateurs à trouver et à utiliser le modèle sémantique, il est défini comme découvrable.
Le modèle sémantique Inventory Stats est certifié. Il s’agit d’une source approuvée et officielle pour l’analyse de l’inventaire. Le modèle sémantique et les rapports associés sont gérés et distribués par l’équipe BI d’entreprise. En raison de la conception complexe du modèle sémantique, seule l’équipe BI d’entreprise est autorisée à créer et à gérer le contenu de l’inventaire. Comme l’objectif est de décourager les créateurs de rapports d’utiliser le modèle sémantique, il n’est pas défini comme découvrable.
Le modèle sémantique Executive Bonuses contient des informations hautement confidentielles. Les autorisations pour voir ou mettre à jour ce modèle sémantique sont limitées à quelques utilisateurs. Ce modèle sémantique n’est pas défini comme découvrable.

La capture d’écran suivante montre un modèle sémantique dans le hub de données du service Power BI. Plus précisément, il montre un exemple de message de demande d’accès pour un modèle sémantique découvrable. Ce message s’affiche quand l’utilisateur n’y a pas accès. Le message de demande d’accès a été personnalisé dans les paramètres du modèle sémantique.

Le message de demande d’accès est le suivant : Pour les rapports de ventes standard (cumul mensuel, trimestriel ou annuel), ce modèle sémantique est la source faisant autorité et certifiée. Demandez l’accès au modèle sémantique en remplissant le formulaire situé à l’adresse https://COE.contoso.com/RequestAccess. Vous serez invité à fournir une brève justification commerciale, et le responsable du Centre d’excellence devra également approuver la demande. L’accès sera audité tous les six mois.

Capture d’écran du message de demande d’accès dans le hub de données pour un modèle sémantique défini comme découvrable.

Remarque

Votre culture des données et votre position sur la démocratisation des données doivent fortement influencer l’activation de la découverte des données. Pour plus d’informations sur la découverte des données, consultez le scénario d’utilisation BI libre-service managé personnalisable.

Il existe trois paramètres de locataire associés à la découverte.

Le paramètre de locataire Découvrir le contenu permet aux administrateurs Power BI de définir les groupes d’utilisateurs qui sont autorisés à découvrir des données. Cela s’adresse principalement aux créateurs de rapports qui devront sans doute localiser des modèles sémantiques existants pour créer des rapports. Il est également utile pour les créateurs de modèles sémantiques qui peuvent rechercher des données existantes à utiliser dans le développement de leur modèle composite. Bien qu’il soit possible de le définir pour des groupes de sécurité spécifiques, il vaut mieux activer le paramètre pour l’ensemble de l’organisation. Le paramètre de découverte sur des modèles sémantiques et des flux de données individuels contrôle ce qui est découvrable. Plus rarement, vous pouvez restreindre cette fonctionnalité uniquement aux créateurs de contenu approuvés.
Le paramètre de locataire Rendre découvrable le contenu certifié permet aux administrateurs Power BI de définir les groupes qui peuvent définir le contenu pour qu’il soit découvrable (quand ils ont également l’autorisation de modifier l’élément ainsi que l’autorisation de certifier le contenu, qui est accordée par le paramètre de locataire Certification). La capacité de certifier le contenu doit être étroitement contrôlée. Dans la plupart des cas, les utilisateurs autorisés à certifier le contenu doivent être autorisés à le définir comme découvrable. Dans certains cas, vous pouvez restreindre cette fonctionnalité uniquement aux créateurs de données approuvés.
Le paramètre de locataire Rendre découvrable le contenu promu permet aux administrateurs Power BI de définir les groupes qui peuvent définir le contenu comme découvrable (quand ils ont également l’autorisation de modifier les données). Comme la possibilité de promouvoir du contenu est ouverte à tous les créateurs de contenu, dans la plupart des cas, cette fonctionnalité doit être disponible pour tous les utilisateurs. Plus rarement, vous pouvez restreindre cette fonctionnalité uniquement aux créateurs de contenu approuvés.

Check-list : voici les décisions et actions clés pour planifier la découverte de données pour vos créateurs de contenu :

Clarifier les besoins en matière de découverte des données : réfléchissez à la position de votre organisation sur l’encouragement des créateurs de contenu à rechercher des modèles sémantiques et des datamarts existants. Si nécessaire, créez une stratégie de gouvernance sur la façon dont la découverte des données doit être utilisée.
Choisir qui peut découvrir le contenu : déterminez si tous les utilisateurs Power BI sont autorisés à découvrir du contenu ou si la découverte doit être limitée à certains groupes d’utilisateurs (par exemple, un groupe de créateurs de contenu approuvés). Définissez le paramètre de locataire Découvrir le contenu conformément à cette décision.
Choisir qui peut définir le contenu certifié comme découvrable : déterminez si tous les utilisateurs Power BI (qui ont l’autorisation de modifier le modèle sémantique ou le datamart, ainsi que l’autorisation de le certifier) peuvent le définir comme découvrable. Définissez le paramètre de locataire Rendre découvrable le contenu certifié conformément à cette décision.
Choisir qui peut définir le contenu promu comme découvrable : déterminez si tous les utilisateurs Power BI (qui ont l’autorisation de modifier le modèle sémantique ou le datamart) peuvent le définir comme découvrable. Définissez le paramètre de locataire Rendre découvrable le contenu promu conformément à cette décision.
Ajouter de la documentation et une formation pour les créateurs de modèles sémantiques : ajoutez des conseils pour indiquer à vos créateurs de modèles sémantiques quand utiliser la découverte de données pour les modèles sémantiques et les datamarts dont ils sont propriétaires et qu’ils gèrent.
Ajouter de la documentation et une formation pour les créateurs de rapports : ajoutez des conseils pour vos créateurs de contenu indiquant comment fonctionne la découverte de données et à quoi ils peuvent s’attendre.

Workflow de demande d’accès pour les créateurs

Un utilisateur peut demander l’accès au contenu de deux manières.

Pour les consommateurs de contenu : un utilisateur reçoit un lien vers un rapport ou une application qui existent dans le service Power BI. Pour voir l’élément, le consommateur peut sélectionner le bouton Demander l’accès. Pour plus d’informations, consultez l’article Planification de la sécurité des consommateurs de rapports.
Pour les créateurs de contenu : l’utilisateur découvre un modèle sémantique ou un datamart dans le hub de données. Pour créer un rapport ou un modèle composite à partir des données existantes, le créateur de contenu peut sélectionner le bouton Demander l’accès. Cette expérience est l’objet de cette section.

Par défaut, une demande d’accès à un modèle sémantique ou à un datamart est adressée au propriétaire. Le propriétaire est l’utilisateur qui a planifié la dernière actualisation des données ou entré les informations d’identification. Vous pouvez désigner un utilisateur pour traiter les demandes d’accès aux modèles sémantiques d’une équipe. Toutefois, ce n’est peut-être ni pratique ni fiable.

Au lieu de vous fier à un seul propriétaire, vous pouvez définir des instructions personnalisées qui sont présentées aux utilisateurs quand ils demandent l’accès à un modèle sémantique ou à un datamart. Les instructions personnalisées sont utiles quand :

Le modèle sémantique est défini comme découvrable.
L’approbation de la demande d’accès est effectuée par une personne autre que le propriétaire des données.
Un processus existant doit être suivi pour les demandes d’accès.
Le suivi de qui a demandé l’accès, quand et pourquoi est nécessaire pour des raisons d’audit ou de conformité.
Une explication est nécessaire pour faire la demande d’accès et définir les attentes.

La capture d’écran suivante montre un exemple de configuration des instructions personnalisées présentées à un utilisateur quand il demande l’autorisation Générer. Les instructions personnalisées sont les suivantes : Pour les rapports de ventes standard (cumul mensuel, trimestriel ou annuel), ce modèle sémantique est la source faisant autorité et certifiée. Demandez l’accès au modèle sémantique en remplissant le formulaire situé à l’adresse https://COE.contoso.com/RequestAccess. Vous serez invité à fournir une brève justification commerciale, et le responsable du Centre d’excellence devra également approuver la demande. L’accès sera audité tous les six mois.

Capture d’écran de la définition de la demande d’accès pour un modèle sémantique dans le service Power BI.

Il existe de nombreuses options pour créer un formulaire. Power Apps et Microsoft Forms sont des options faciles à utiliser et nécessitant peu de code. Nous vous recommandons de créer un formulaire de manière généralisée pour tous les utilisateurs. Il est essentiel que votre formulaire soit créé, géré et monitoré par l’équipe appropriée.

Nous vous recommandons de créer des informations utiles pour :

Les créateurs de contenu, afin qu’ils sachent à quoi s’attendre quand ils demandent l’accès.
Les propriétaires et administrateurs de contenu, afin qu’ils sachent comment gérer les demandes envoyées.

Conseil

Pour plus d’informations sur la réponse aux demandes d’accès en lecture des consommateurs, consultez Workflow de demande d’accès pour les consommateurs. Il comprend également des informations sur l’utilisation de groupes (au lieu d’utilisateurs individuels).

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

Clarifier les préférences de gestion des demandes d’accès : déterminez les situations dans lesquelles il faut l’approbation du propriétaire et quand un processus différent doit être utilisé. Si nécessaire, créez une stratégie de gouvernance sur la façon dont les demandes d’accès doivent être gérées.
Ajouter de la documentation et une formation pour les créateurs de modèles sémantiques et de datamarts : ajoutez des conseils pour indiquer à vos créateurs de modèles sémantiques et de datamarts comment et quand définir des instructions personnalisées pour les demandes d’accès.
Ajouter de la documentation et une formation pour les créateurs de rapports : ajoutez des conseils pour indiquer à vos créateurs de rapports à quoi ils peuvent s’attendre quand ils demandent l’autorisation Générer sur des modèles sémantiques et des datamarts.

Créer et publier du contenu

Cette section décrit les aspects de sécurité qui s’appliquent aux créateurs de contenu.

Notes

Pour les consommateurs qui consultent les rapports, les tableaux de bord et les cartes de performance, consultez l’article Planification de la sécurité des consommateurs de rapports. Les considérations relatives aux autorisations d’application sont également abordées dans cet article.

Rôles d’espace de travail

Vous accordez l’accès à l’espace de travail en ajoutant des utilisateurs ou des groupes (y compris les groupes de sécurité, les groupes Microsoft 365 et les listes de distribution) à des rôles d’espace de travail. L’attribution d’utilisateurs à des rôles d’espace de travail vous permet de spécifier ce qu’ils peuvent faire dans l’espace de travail et avec son contenu.

Notes

Pour plus d’informations sur la planification d’espace de travail, consultez les articles sur la planification d’espace de travail. Pour plus d’informations sur les groupes, consultez l’article Planification de la sécurité au niveau du locataire.

Comme l’objectif principal d’un espace de travail est la collaboration, l’accès à l’espace de travail est principalement pertinent pour les utilisateurs qui en sont propriétaires et qui gèrent son contenu. Lorsque vous commencez à planifier des rôles d’espace de travail, il est utile de vous poser les questions suivantes.

Quelles sont les attentes quant à la façon dont la collaboration se produira dans l’espace de travail ?
Qui sera responsable de la gestion du contenu dans l’espace de travail ?
L'intention est-elle d'assigner des utilisateurs individuels ou des groupes à des rôles d'espace de travail ?

Il existe quatre rôles d’espace de travail Power BI : Administrateur, Membre, Contributeur et Lecteur. Les trois premiers rôles sont pertinents pour les créateurs de contenu, qui créent et publient du contenu. Le rôle Lecteur est pertinent pour les consommateurs en lecture seule.

Les autorisations des quatre rôles d’espace de travail sont imbriquées. Cela signifie que les administrateurs d’espace de travail ont accès à toutes les fonctionnalités des membres, des contributeurs et des lecteurs. De même, les membres ont accès à toutes les fonctionnalités des contributeurs et des lecteurs. Les contributeurs ont accès à toutes les fonctionnalités des lecteurs.

Conseil

Consultez la documentation des rôles d’espace de travail pour les informations de référence officielles de chacun des quatre rôles.

Administrateur d’espace de travail

Les utilisateurs attribués au rôle Administrateur deviennent les administrateurs de l’espace de travail. Ils peuvent gérer tous les paramètres et effectuer toutes les actions, y compris ajouter ou supprimer des utilisateurs (notamment d’autres administrateurs de l’espace de travail).

Les administrateurs d’espace de travail peuvent mettre à jour ou supprimer l’application Power BI (le cas échéant). Ils peuvent, éventuellement, autoriser les contributeurs à mettre à jour l’application pour l’espace de travail. Pour plus d’informations, consultez Variantes des rôles d’espace de travail plus loin dans cet article.

Conseil

Quand vous faites référence à un administrateur, veillez à préciser si vous parlez d’un administrateur d’espace de travail ou d’un administrateur au niveau du locataire Power BI.

Vérifiez que seules les personnes approuvées et fiables sont administrateurs d’espace de travail. Un administrateur d’espace de travail a des privilèges élevés. Il peut voir et gérer tout le contenu de l’espace de travail. Il peut ajouter et supprimer des utilisateurs (y compris d’autres administrateurs) dans n’importe quel rôle d’espace de travail. Il peut également supprimer l’espace de travail.

Nous vous recommandons de désigner au moins deux administrateurs pour que l’un d’eux puisse remplacer l’administrateur principal s’il n’est pas disponible. Un espace de travail qui n’a pas d’administrateur est appelé espace de travail orphelin. L’état orphelin se produit quand un utilisateur quitte l’organisation et qu’aucun autre administrateur n’est attribué à l’espace de travail. Pour plus d’informations sur la détection et la rectification des espaces de travail orphelins, consultez l’article Voir les espaces de travail.

Dans l’idéal, vous devez pouvoir déterminer qui est responsable du contenu de l’espace de travail en regardant qui sont les administrateurs et membres de l’espace de travail (et des contacts spécifiés pour l’espace de travail). Toutefois, certaines organisations adoptent une stratégie de propriété et gestion du contenu qui limite la création d’espace de travail à des utilisateurs ou des groupes spécifiques. Ils ont généralement un processus de création d’espace de travail établi et gérable par le service informatique. Dans ce cas, les administrateurs d’espace de travail seraient des membres du service informatique plutôt que les utilisateurs qui créent, puis publient directement le contenu.

Membre de l’espace de travail

Les utilisateurs attribués au rôle Membre peuvent ajouter d’autres utilisateurs de l’espace de travail (mais pas des administrateurs). Ils peuvent également gérer les autorisations pour tout le contenu de l’espace de travail.

Les membres de l’espace de travail peuvent publier ou annuler la publication de l’application pour l’espace de travail, partager un élément d’espace de travail de l’application, et autoriser d’autres utilisateurs à partager des éléments d’espace de travail de l’application.

Les membres de l’espace de travail doivent être limités aux utilisateurs qui doivent gérer la création du contenu de l’espace de travail et publier l’application. Dans certains cas, les administrateurs de l’espace de travail remplissent cet objectif et vous n’avez pas besoin d’attribuer des utilisateurs ou des groupes au rôle Membre. Quand les administrateurs d’espace de travail ne sont pas directement liés au contenu de l’espace de travail (par exemple, parce que le service informatique gère le processus de création de l’espace de travail), les membres de l’espace de travail peuvent être les véritables propriétaires chargés du contenu de l’espace de travail.

Contributeur d’espace de travail

Les utilisateurs attribués au rôle Contributeur peuvent créer, modifier ou supprimer le contenu de l’espace de travail.

Les contributeurs ne peuvent pas mettre à jour l’application Power BI (quand il y en a une pour l’espace de travail), sauf s’ils y sont autorisés par le paramètre d’espace de travail. Pour plus d’informations, consultez Variantes des rôles d’espace de travail plus loin dans cet article.

La plupart des créateurs de contenu de l’organisation sont des contributeurs d’espace de travail.

Visionneuse d’espace de travail

Les utilisateurs attribués au rôle Lecteur peuvent voir tout le contenu de l’espace de travail et interagir avec ce contenu.

Le rôle Lecteur est pertinent pour les consommateurs en lecture seule dans les petites équipes et les scénarios informels. Il est entièrement décrit dans l’article Planification de la sécurité des consommateurs de rapports.

Considérations relatives à la propriété de l’espace de travail

Prenez l’exemple où les actions suivantes sont effectuées pour configurer un nouvel espace de travail.

Des champions Power BI spécifiques et des membres satellites du Centre d’excellence ont reçu l’autorisation dans les paramètres de locataire de créer des espaces de travail. Ils ont été formés aux stratégies d’organisation de contenu et aux conventions de nommage.
Vous (un créateur de contenu) envoyez une demande de création d’espace de travail pour un nouveau projet que vous gérez. L’espace de travail comprend des rapports qui suivent la progression de votre projet.
Un champion Power BI de votre division reçoit la demande. Il détermine qu’un nouvel espace de travail est justifié. Il crée ensuite un espace de travail et attribue le groupe de sécurité des champions Power BI (pour sa division) au rôle Administrateur d’espace de travail.
Le champion Power BI vous (le créateur de contenu) attribue le rôle Membre de l’espace de travail.
Vous attribuez un collègue approuvé au rôle Membre de l’espace de travail pour qu’il puisse vous remplacer en cas d’absence.
Vous attribuez d’autres collègues au rôle Contributeur d’espace de travail, car ils doivent créer le contenu de l’espace de travail, y compris les modèles sémantiques et les rapports.
Vous attribuez à votre responsable le rôle Lecteur de l’espace de travail, car il a demandé l’accès pour monitorer la progression du projet. Votre responsable souhaite passer en revue le contenu de l’espace de travail avant la publication d’une application.
Vous êtes chargé de gérer les autres propriétés de l’espace de travail, comme la description et les contacts. Vous êtes également chargé de gérer les accès à l’espace de travail.

L’exemple précédent montre un moyen efficace de permettre à une division décentralisée d’agir de manière indépendante. Il montre également le principe du moindre privilège.

Pour le contenu régi ou le contenu critique géré de manière plus stricte, la bonne pratique est d’attribuer des groupes plutôt que des comptes d’utilisateur individuels aux rôles d’espace de travail. De cette façon, vous pouvez gérer l’appartenance au groupe séparément de l’espace de travail. Toutefois, quand vous attribuez des groupes à des rôles, des utilisateurs peuvent être attribués à plusieurs rôles d’espace de travail (car l’utilisateur appartient à plusieurs groupes). Dans ce cas, leurs autorisations effectives sont basées sur le rôle le plus élevé auquel ils sont attribués. Pour plus d’informations, consultez Stratégie d’utilisation des groupes.

Quand un espace de travail est co-détenu par plusieurs personnes ou équipes, la gestion du contenu peut devenir plus complexe. Essayez d’éviter les scénarios où plusieurs équipes sont propriétaires en divisant les espaces de travail. De cette façon, les responsabilités sont claires et les attributions de rôle sont simples à configurer.

Variantes des rôles d’espace de travail

Il existe deux variantes pour les quatre rôles d’espace de travail (décrits précédemment).

Par défaut, seuls les administrateurs et les membres de l’espace de travail peuvent créer, publier et mettre à jour l’application pour l’espace de travail. Le paramètre Autoriser les contributeurs à mettre à jour l’application pour cet espace de travail s’applique au niveau de l’espace de travail et permet aux administrateurs d’espace de travail de déléguer la possibilité de mettre à jour l’application pour l’espace de travail aux contributeurs. Toutefois, les contributeurs ne peuvent pas publier une nouvelle application ni changer les personnes autorisées à la modifier. Ce paramètre est utile si vous voulez que les contributeurs puissent mettre à jour l’application (quand il en existe une pour l’espace de travail), sans accorder les autres autorisations des membres.
Le paramètre de locataire Bloquer la republication et désactiver l’actualisation du package autorise uniquement les propriétaires de modèles sémantiques à publier des mises à jour. Quand ce paramètre est activé, les administrateurs, les membres et les contributeurs de l’espace de travail ne peuvent pas publier de changements, sauf s’ils prennent d’abord le contrôle du modèle sémantique en tant que propriétaire. Comme ce paramètre s’applique à l’ensemble de l’organisation, activez-le avec précaution, car il affecte tous les modèles sémantiques du locataire. Veillez à communiquer à vos créateurs de modèles sémantiques les effets de ce paramètre, car il change le comportement normal des rôles d’espace de travail.

Important

Les autorisations par élément peuvent également être considérées en remplacement des rôles d’espace de travail standard. Pour plus d’informations sur les autorisations par élément, consultez l’article Planification de la sécurité des consommateurs de rapports.

Check-list : voici les décisions et actions clés pour planifier les rôles d’espace de travail :

Créez une matrice de responsabilité : Mapper qui doit gérer chaque fonction lors de la création, de la maintenance, de la publication, de la sécurisation et de la prise en charge du contenu. Utilisez ces informations pendant la planification de vos rôles d’espace de travail.
Choisir votre stratégie d’attribution de rôles d’espace de travail pour les créateurs de contenu : déterminez les utilisateurs qui doivent être administrateurs, membres ou contributeurs, et dans quelles circonstances (par exemple, en fonction du poste ou du domaine). En cas d’incompatibilités entraînant un problème de sécurité, réfléchissez à la façon de réorganiser au mieux vos espaces de travail.
Déterminer quand utiliser des groupes de sécurité ou des utilisateurs individuels pour les rôles d’espace de travail : déterminez les cas d’usage et les raisons pour lesquels vous avez besoin d’utiliser des groupes. Précisez bien quand la sécurité doit être appliquée avec des comptes d’utilisateurs ou quand un groupe est nécessaire ou préférable.
Fournir des conseils aux créateurs de contenu sur la gestion des rôles d’espace de travail : ajoutez de la documentation pour les créateurs de contenu indiquant comment gérer les rôles d’espace de travail. Publiez ces informations sur votre portail centralisé et vos supports de formation.
Configurer et tester les attributions de rôle d’espace de travail : vérifiez que les créateurs de contenu ont les fonctionnalités dont ils ont besoin pour modifier et publier du contenu.

Autorisations du créateur d’applications

Les créateurs de contenu qui sont administrateurs ou membres de l’espace de travail peuvent créer et publier une application Power BI.

Un administrateur d’espace de travail peut également spécifier un paramètre dans l’espace de travail pour permettre aux contributeurs de l’espace de travail de mettre à jour l’application. Il s’agit d’une variante de la sécurité du rôle d’espace de travail, car elle accorde aux contributeurs une autorisation qu’ils n’ont pas normalement. Ce paramètre est défini pour chaque espace de travail.

Conseil

Pour plus d’informations sur la distribution de contenu aux consommateurs en lecture seule, consultez l’article Planification de la sécurité des consommateurs de rapports. Cet article contient des informations sur les autorisations d’application pour les consommateurs de l’application, y compris les audiences de l’application.

Check-list : voici les décisions et actions clés pour planifier les autorisations du créateur d’applications :

Choisir votre stratégie concernant qui peut créer et publier des applications Power BI : précisez qui doit être autorisé à créer et publier des applications Power BI.
Déterminer quand les contributeurs peuvent mettre à jour les applications Power BI : précisez les situations dans lesquelles un contributeur doit être autorisé à mettre à jour des applications Power BI. Mettez à jour le paramètre de l’espace de travail quand cette fonctionnalité est nécessaire.

Autorisations des sources de données

Quand un créateur de données démarre un nouveau projet, les autorisations nécessaires pour accéder aux sources de données externes sont l’un des premiers aspect de sécurité à prendre en compte. Il pourrait aussi avoir besoin d’aide sur d’autres questions liées aux sources de données, notamment les niveaux de confidentialité, les requêtes de base de données natives et les connecteurs personnalisés.

Accès à une source de données

Quand un créateur de données crée un modèle sémantique, un flux de données ou un datamart, il doit s’authentifier sur les sources de données pour récupérer les données. En règle générale, l’authentification implique les informations d’identification de l’utilisateur (compte et mot de passe), qui peuvent être celles d’un compte de service.

Il est parfois utile de créer des comptes de service spécifiques pour accéder aux sources de données. Contactez votre service informatique pour obtenir des conseils sur l’utilisation des comptes de service dans votre organisation. Quand elle est autorisée, l’utilisation des comptes de service peut :

Centraliser les autorisations nécessaires pour les sources de données.
Réduire le nombre d’utilisateurs individuels qui ont besoin d’autorisations sur une source de données.
Éviter les échecs d’actualisation des données quand un utilisateur quitte l’organisation.

Conseil

Si vous choisissez d’utiliser des comptes de service, nous vous recommandons de contrôler précisément qui a accès aux informations d’identification. Permutez les mots de passe régulièrement (par exemple, tous les trois mois) ou dès qu’une personne ayant accès quitte l’organisation.

Quand vous accédez à des sources de données, appliquez le principe du moindre privilège pour que les utilisateurs (ou les comptes de service) soient autorisés à lire uniquement les données dont ils ont besoin. Ils ne doivent jamais avoir l’autorisation d’effectuer des modifications de données. Les administrateurs de base de données qui créent ces comptes de service doivent se renseigner sur les requêtes et charges de travail attendues et prendre des mesures pour vérifier que les optimisations (comme les index) et les ressources appropriées sont en place.

Conseil

S’il vous est difficile de fournir aux créateurs de données libre-service un accès direct à la source de données, utilisez une approche indirecte. Vous pouvez créer des flux de données dans le service Power BI et autoriser les créateurs de données libre-service à en extraire des données. Cette approche présente les avantages supplémentaires de réduire la charge des requêtes sur la source de données et de fournir un instantané cohérent des données. Pour plus d’informations, consultez les scénarios d’utilisation Préparation de données libre-service et Préparation de données avancée.

Les informations d’identification (compte et mot de passe) peuvent être appliquées de deux façons.

Power BI Desktop : les informations d’identification sont chiffrées et stockées localement sur la machine utilisateur.
Service Power BI : les informations d’identification sont chiffrées et stockées de manière sécurisée pour :
- Le modèle sémantique (quand aucune passerelle de données n’est utilisée pour accéder à la source de données).
- La source de données de la passerelle (quand une passerelle standard ou un service de passerelle de réseau virtuel est utilisé pour accéder à la source de données).

Conseil

Si vous avez déjà entré les informations d’identification d’une source de données de modèle sémantique, le service Power BI associe automatiquement ces informations d’identification à d’autres sources de données de modèles sémantiques en cas de correspondance exacte entre la chaîne de connexion et le nom de la base de données. Le service Power BI et Power BI Desktop font comme si vous aviez entré des informations d’identification pour chaque source de données. Toutefois, ils peuvent appliquer les mêmes informations d’identification aux sources de données correspondantes qui ont le même propriétaire. Dans ce contexte, les informations d’identification du modèle sémantique sont limitées au propriétaire.

Les informations d’identification sont chiffrées et stockées séparément du modèle de données dans Power BI Desktop et le service Power BI. Cette séparation des données présente les avantages de sécurité suivants.

Elle facilite la réutilisation des informations d’identification pour plusieurs modèles sémantiques, flux de données et datamarts.
Quand une personne analyse les métadonnées d’un modèle sémantique, elle ne peut pas extraire les informations d’identification.
Dans Power BI Desktop, un autre utilisateur ne peut pas se connecter à la source de données d’origine pour actualiser les données sans d’abord appliquer les informations d’identification.

Certaines sources de données prennent en charge l’authentification unique (SSO), qui peut être définie en entrant les informations d’identification dans le service Power BI (pour les sources de données de modèles sémantiques ou de passerelle). Quand vous activez SSO, Power BI envoie les informations d’identification de l’utilisateur authentifié à la source de données. Cette option permet à Power BI d’honorer les paramètres de sécurité qui sont configurés dans la source de données, comme la sécurité au niveau des lignes. SSO est particulièrement utile quand les tables du modèle de données utilisent le mode de stockage DirectQuery.

Niveaux de confidentialité

Les niveaux de confidentialité des données spécifient des niveaux d’isolement qui définissent le degré d’isolement d’une source de données par rapport aux autres sources de données. Quand ils sont correctement définis, ils garantissent que Power Query transmet uniquement des données compatibles entre les sources. Quand Power Query peut transmettre des données entre des sources de données, les requêtes sont plus efficaces et le volume de données envoyées à Power BI est réduit. Quand il ne peut pas transmettre des données entre des sources de données, les performances peuvent être plus lentes.

Il y a trois niveaux de confidentialité.

Privé : comprend des données sensibles ou confidentielles qui doivent être isolées de toutes les autres sources de données. Ce niveau est le plus restrictif. Les données de sources de données privées ne peuvent pas être partagées avec d’autres sources de données. Par exemple, une base de données des Ressources Humaines qui contient la valeur des salaires des employés doit être définie sur le niveau de confidentialité Privé.
Organisationnel : les données sont isolées des sources de données publiques, mais visibles par les autres sources de données organisationnelles. Ce niveau est le plus courant. Les données de sources de données organisationnelles peuvent être partagées avec des sources de données privées ou d’autres sources de données organisationnelles. La plupart des bases de données opérationnelles internes peuvent être définies avec le niveau de confidentialité Organisationnel.
Public : données non sensibles qui peuvent être vues par n’importe quelle source de données. Ce niveau est le moins restrictif. Les données de sources de données publiques peuvent être partagées avec toutes les autres sources de données. Par exemple, un rapport de recensement obtenu à partir d’un site web du gouvernement peut être défini sur le niveau de confidentialité Public.

Quand vous combinez des requêtes de différentes sources de données, veillez à définir les niveaux de confidentialité appropriés. Quand les niveaux de confidentialité sont correctement définis, les données d’une source de données peuvent être transmises à une autre source de données pour une interrogation efficace des données.

Prenez l’exemple d’un scénario où un créateur de modèle sémantique a deux sources de données : un classeur Excel et un tableau dans une base de données Azure SQL. Il veut filtrer les données de la table de base de données Azure SQL en utilisant une valeur du classeur Excel. Le moyen le plus efficace pour Power Query de générer une instruction SQL pour la base de données Azure SQL est d’appliquer une clause WHERE pour effectuer le filtrage nécessaire. Toutefois, cette instruction SQL contient un prédicat de clause WHERE avec une valeur du classeur Excel. Si le classeur Excel contient des données sensibles, il risque d’y avoir une violation de la sécurité, car l’administrateur de base de données risque de voir l’instruction SQL avec un outil de traçage. Bien que moins efficace, l’alternative est que le moteur mashup Power Query télécharge l’ensemble du jeu de résultats de la table de base de données et effectue le filtrage lui-même dans le service Power BI. Cette approche est moins efficace et plus lente, mais sécurisée.

Des niveaux de confidentialité peuvent être définis pour chaque source de données :

Par les modélisateurs de données dans Power BI Desktop.
Par les propriétaires de modèles sémantiques dans le service Power BI (pour les sources de données cloud, qui ne nécessitent pas de passerelle).
Par les créateurs et propriétaires de sources de données de passerelle dans le service Power BI (pour les sources de données de passerelle).

Important

Les niveaux de confidentialité que vous définissez dans Power BI Desktop ne sont pas transférés au service Power BI.

Il existe une option de sécurité Power BI Desktop qui permet d’ignorer les niveaux de confidentialité pour améliorer les performances. Vous pouvez utiliser cette option pour améliorer les performances des requêtes pendant le développement d’un modèle de données quand il n’y a aucun risque de violation de la sécurité des données (parce que vous utilisez des données de développement ou de test qui ne sont pas sensibles). Toutefois, ce paramètre n’est pas suivi par le service Power BI.

Pour plus d’informations, consultez Niveaux de confidentialité Power BI Desktop.

Requêtes de base de données natives

Pour créer des requêtes Power Query efficaces, vous pouvez utiliser une requête native pour accéder aux données. Une requête native est une instruction écrite dans un langage pris en charge par la source de données. Les requêtes natives sont uniquement prises en charge par des sources de données spécifiques, qui sont généralement des bases de données relationnelles comme Azure SQL Database.

Les requêtes natives peuvent présenter un risque de sécurité, car elles peuvent exécuter une instruction SQL malveillante. Une instruction malveillante peut effectuer des modifications de données ou supprimer des enregistrements de base de données (quand l’utilisateur a les autorisations nécessaires sur la source de données). Pour cette raison, par défaut, les requêtes natives nécessitent l’approbation de l’utilisateur pour s’exécuter dans Power BI Desktop.

Il existe une option de sécurité Power BI Desktop qui vous permet de désactiver l’exigence de pré-approbation. Nous vous recommandons de garder le paramètre par défaut qui demande l’approbation de l’utilisateur, en particulier si le fichier Power BI Desktop doit être actualisé par d’autres utilisateurs.

Connecteurs personnalisés

Les développeurs peuvent utiliser le SDK Power Query pour créer des connecteurs personnalisés. Les connecteurs personnalisés autorisent l’accès aux sources de données propriétaires ou implémentent une authentification spécifique avec des extensions de données personnalisées. Certains connecteurs personnalisés sont certifiés et distribués par Microsoft en tant que connecteurs certifiés. Les connecteurs certifiés ont été audités et passés en revue pour vérifier qu’ils répondent à certaines exigences de code spécifiées que Microsoft a testées et approuvées.

Il existe une option de sécurité d’extension de données Power BI Desktop qui limite l’utilisation des connecteurs non certifiés. Par défaut, une erreur est générée en cas de tentative de chargement d’un connecteur non certifié. Quand vous définissez cette option pour autoriser les connecteurs non certifiés, les connecteurs personnalisés sont chargés sans validation ni avertissement.

Nous vous recommandons de conserver le plus haut niveau de sécurité de votre extension de données, pour empêcher le chargement de code non certifié. Toutefois, dans certains cas, vous souhaiterez sans doute charger des connecteurs spécifiques, ceux que vous avez développés ou ceux qui vous sont fournis par un consultant ou un fournisseur approuvé en dehors du chemin d’accès de certification Microsoft.

Remarque

Les développeurs de connecteurs développés en interne peuvent prendre des mesures pour signer un connecteur avec un certificat, ce qui vous permet de l’utiliser sans avoir à changer vos paramètres de sécurité. Pour plus d’informations, consultez Connecteurs tiers de confiance.

Check-list : voici les décisions et actions clés pour planifier les autorisations des sources de données :

Choisir qui peut accéder directement à chaque source de données : déterminez les créateurs de données qui sont autorisés à accéder directement à une source de données. S’il existe une stratégie pour réduire le nombre de personnes ayant un accès direct, précisez l’alternative par défaut (peut-être l’utilisation de flux de données).
Choisir comment accéder aux sources de données : déterminez si chaque utilisateur doit utiliser ses informations d’identification pour accéder à une source de données ou s’il faut créer un compte de service à la place. Déterminez quand l’authentification unique est appropriée.
Fournir des conseils aux créateurs de modèles sémantiques sur l’accès aux sources de données : ajoutez de la documentation pour indiquer aux créateurs de contenu comment accéder aux sources de données de l’organisation. Publiez les informations sur votre portail centralisé et vos supports de formation.
Fournir des conseils aux créateurs de modèles sémantiques sur les niveaux de confidentialité : fournissez des conseils aux créateurs de modèles sémantiques pour les sensibiliser aux niveaux de confidentialité et à leurs implications en cas d’utilisation de données sensibles ou confidentielles. Publiez ces informations sur votre portail centralisé et vos supports de formation.
Fournir des conseils aux créateurs de connexion de passerelle sur les niveaux de confidentialité : fournissez des conseils aux créateurs de modèles sémantiques pour les sensibiliser aux niveaux de confidentialité et à leurs implications en cas d’utilisation de données sensibles ou confidentielles. Publiez ces informations sur votre portail centralisé et vos supports de formation.
Choisir la stratégie d’utilisation des requêtes de base de données natives : réfléchissez à votre stratégie d’utilisation des requêtes de base de données natives. Indiquez aux créateurs de modèles sémantiques quand et comment définir l’option de requêtes de base de données natives dans Power BI Desktop pour désactiver la préapprobation quand Power Query exécute des requêtes natives.
Choisir la stratégie d’utilisation des connecteurs personnalisés : réfléchissez à votre stratégie d’utilisation des connecteurs personnalisés. Déterminez si l’utilisation de connecteurs non certifiés est justifiée, auquel cas indiquez aux créateurs de modèles sémantiques quand et comment définir l’option d’extension de données Power BI Desktop.

Autorisations de créateur de modèle sémantique

Vous pouvez attribuer l’autorisation de modifier un modèle sémantique à un utilisateur ou à un groupe de différentes manières.

Rôle d’espace de travail : l’attribution à l’un des rôles d’espace de travail donne accès à tous les modèles sémantiques de l’espace de travail. La possibilité de voir ou de modifier un modèle sémantique existant dépend du rôle d’espace de travail que vous attribuez. Les administrateurs, les membres et les contributeurs peuvent publier ou modifier du contenu au sein d’un espace de travail.
Liens d’autorisation par élément : si un lien de partage a été créé pour un rapport, l’autorisation de lecture du modèle sémantique (et éventuellement, de génération, d’écriture et/ou de repartage) est également indirectement octroyée par le lien.
Autorisations d’accès direct par élément : vous pouvez attribuer l’autorisation d’accès direct à un modèle sémantique spécifique.

Dans la capture d’écran suivante, notez les autorisations attribuées au modèle sémantique Call Center Data. Un utilisateur a l’autorisation Lire, qui a été accordée avec des autorisations d’accès direct par élément. Les autres utilisateurs et groupes ont des autorisations parce qu’ils sont attribués à des rôles d’espace de travail.

Capture d’écran du service Power BI montrant les autorisations d’accès direct sur un modèle sémantique pour des utilisateurs et des groupes.

Conseil

L’utilisation d’autorisations par élément (liens ou accès direct) fonctionne mieux quand l’intention est qu’un utilisateur ou un groupe puisse voir ou modifier un élément spécifique dans l’espace de travail. Elle convient mieux quand l’utilisateur n’est pas autorisé à accéder à tous les éléments de l’espace de travail. Dans la plupart des cas, nous vous recommandons de concevoir vos espaces de travail de sorte à simplifier la gestion de la sécurité avec des rôles d’espace de travail. Évitez si possible de définir des autorisations par élément.

Autorisations de modèle sémantique

Vous pouvez attribuer les autorisations de modèle sémantique suivantes.

Lire : destinée principalement aux consommateurs de rapports, cette autorisation permet à un rapport d’interroger des données dans le modèle sémantique. Pour plus d’informations sur les autorisations de lecture du contenu en lecture seule, consultez l’article Planification de la sécurité des consommateurs de rapports.
Générer : destinée aux créateurs de rapports, cette autorisation permet aux utilisateurs de créer des rapports basés sur le modèle sémantique partagé. Pour plus d’informations, consultez la section Autorisations du créateur de rapports plus loin dans cet article.
Écrire : destinée aux créateurs de modèle sémantique qui créent, publient et gèrent des modèles sémantiques, cette autorisation permet aux utilisateurs de modifier le modèle sémantique. Elle est décrite plus loin dans cette section.
Repartager : destinée à toute personne ayant une autorisation existante sur le modèle sémantique, cette autorisation permet aux utilisateurs de partager le modèle sémantique avec un autre utilisateur. Elle est décrite plus loin dans cette section.

Un administrateur ou un membre de l’espace de travail peut modifier les autorisations d’un modèle sémantique.

Autorisation de modèle sémantique Lire

L’autorisation de modèle sémantique Lire est principalement destinée aux consommateurs. Cette autorisation est nécessaire pour que les utilisateurs puissent voir les données affichées dans les rapports. N’oubliez pas que les rapports basés sur le modèle sémantique doivent également avoir l’autorisation Lire ; sinon, le chargement du rapport échoue. Pour plus d’informations sur la définition des autorisations Lire, consultez l’article Planification de la sécurité des consommateurs de rapports.

Autorisation de modèle sémantique Générer

En plus de l’autorisation de modèle sémantique Lire, les créateurs de contenu ont également besoin de l’autorisation Générer sur le modèle sémantique. Plus précisément, l’autorisation Générer permet aux créateurs de rapports de :

Créer des rapports Power BI basés sur le modèle sémantique.
Se connecter au modèle sémantique avec Analyser dans Excel.
Interroger le modèle sémantique avec le point de terminaison XMLA.
Exporter les données sous-jacentes du visuel de rapport Power BI (au lieu des données récapitulatives récupérées par le visuel).
Créer une connexion DirectQuery à un modèle sémantique Power BI. Dans ce cas, le nouveau modèle sémantique se connecte à un ou plusieurs modèles sémantiques Power BI existants (processus appelé chaînage). Pour interroger des modèles sémantiques chaînés, le créateur de modèle sémantique a besoin de l’autorisation Générer sur tous les modèles sémantiques amont. Pour plus d’informations, consultez Modèles sémantiques chaînés plus loin dans cet article.

Vous pouvez accorder l’autorisation Générer à un utilisateur ou un groupe, directement ou indirectement, de différentes manières.

Pour accorder l’autorisation Générer directement, vous pouvez :
- Définir des autorisations de modèle sémantique dans la page des paramètres du modèle sémantique du service Power BI.
- Définir des autorisations de modèle sémantique avec l’API REST Power BI.
Pour accorder l’autorisation Générer indirectement, vous pouvez :
- Partager un rapport ou un tableau de bord, et définir l’option pour octroyer l’autorisation de modèle sémantique Générer.
- Publier une application Power BI et définir l’option avancée (pour un public) permettant d’octroyer l’autorisation Générer sur les modèles sémantiques associés.
- Attribuer des utilisateurs aux rôles d’espace de travail Administrateur, Membre ou Contributeur.

La définition de l’autorisation Générer directement pour un modèle sémantique est appropriée si vous voulez gérer la sécurité sur une base granulaire par élément. La définition de l’autorisation Générer indirectement est appropriée quand les utilisateurs qui voient ou utilisent le contenu à travers une des méthodes indirectes créent également du contenu.

Conseil

Souvent, les utilisateurs qui consultent un rapport ou une application Power BI sont différents de ceux qui créent du contenu à partir des modèles sémantiques sous-jacents. La plupart des consommateurs sont des lecteurs uniquement, ils n’ont donc pas besoin de créer du contenu. Nous vous recommandons d’indiquer à vos créateurs de contenu d’accorder le moins d’autorisations nécessaires.

Autorisation de modèle sémantique Écrire

En règle générale, la définition des autorisations pour modifier et gérer des modèles sémantiques est effectuée en attribuant des utilisateurs au rôle d’espace de travail Administrateur, Membre ou Contributeur. Toutefois, vous pouvez aussi définir l’autorisation Écrire pour un modèle sémantique spécifique.

Nous vous recommandons d’utiliser des rôles d’espace de travail si possible, car c’est le moyen le plus simple de gérer et d’auditer les autorisations. Utilisez les autorisations de modèle sémantique Écrire par élément quand vous avez choisi de créer moins d’espaces de travail, et qu’un espace de travail contient des modèles sémantiques pour différents domaines qui nécessitent une gestion différente des autorisations.

Conseil

Pour obtenir des conseils sur l’organisation des espaces de travail, consultez les articles sur la planification des espaces de travail.

Autorisation de modèle sémantique Repartager

L’autorisation de modèle sémantique Repartager permet à un utilisateur ayant une autorisation existante de partager le modèle sémantique avec d’autres utilisateurs. Vous pouvez octroyer cette autorisation quand le contenu du modèle sémantique peut être partagé librement, à la discrétion de l’utilisateur.

Dans de nombreux cas, nous vous recommandons de limiter l’utilisation de l’autorisation Repartager pour garder un contrôle strict sur les autorisations de modèle sémantique. Obtenez l’approbation du ou des propriétaires de modèles sémantiques avant d’octroyer l’autorisation Repartager.

Sécurité des données de modèle sémantique

Vous pouvez prévoir de créer 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.

Un créateur de modèle sémantique peut appliquer la sécurité des données de deux manières.

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.
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.

L’implémentation de RLS et OLS est destinée aux consommateurs de rapports. Pour plus d’informations, consultez l’article Planification de la sécurité des consommateurs de rapports. Il décrit comment et quand les sécurités SNL et OLS sont appliquées pour les consommateurs qui sont uniquement autorisés à afficher le modèle sémantique.

Pour les sécurités RLS et OLS ciblant d’autres créateurs de rapports, consultez la sécurité des données dans la section Autorisations des créateurs de rapports plus loin dans cet article.

Modèles sémantiques chaînés

Les modèles sémantiques Power BI peuvent se connecter à d’autres modèles sémantiques dans un processus appelé chaînage. Il s’agit de connexions à des modèles sémantiques en amont. Pour plus d’informations, consultez Utilisation de DirectQuery pour les modèles sémantiques Power BI et Analysis Services.

Le paramètre de locataire Autoriser les connexions DirectQuery aux modèles sémantiques Power BI permet aux administrateurs Power BI de configurer les groupes de créateurs de contenu qui peuvent créer des modèles sémantiques chaînés. Si vous ne souhaitez pas empêcher les créateurs de modèles sémantiques de chaîner ces modèles, vous pouvez laisser ce paramètre activé pour l’ensemble de l’organisation, et utiliser l’accès à l’espace de travail et les autorisations de modèle sémantique. Dans certains cas, vous envisagerez sans doute de restreindre cette fonctionnalité aux créateurs de contenu approuvés.

Remarque

En tant que créateur de modèle sémantique, vous pouvez restreindre le chaînage à votre modèle sémantique. Pour ce faire, activez l’option Décourager la connexion DirectQuery à ce modèle sémantique dans Power BI Desktop. Pour plus d’informations, consultez Gérer les connexions DirectQuery à un modèle sémantique publié.

Requêtes d’API de modèle sémantique

Dans certains cas, vous pouvez exécuter une requête DAX avec l’API REST Power BI. Par exemple, si vous voulez effectuer des validations de qualité des données. Pour plus d’informations, consultez Jeux de données - Exécuter des requêtes.

Le paramètre de locataire API REST Exécuter des requêtes de jeu de données permet aux administrateurs Power BI de définir les groupes d’utilisateurs qui peuvent envoyer des requêtes DAX avec l’API REST Power BI. Dans la plupart des cas, vous pouvez laisser ce paramètre activé pour l’ensemble de l’organisation, et utiliser l’accès à l’espace de travail et les autorisations de modèle sémantique. Dans certains cas, vous envisagerez sans doute de restreindre cette fonctionnalité aux créateurs de contenu approuvés.

Check-list – Voici les décisions et actions clés pour planifier les autorisations du créateur de métriques :

Choisir la stratégie pour les autorisations du créateur de modèles sémantiques : déterminez les préférences et les exigences de gestion de la sécurité pour les créateurs de modèles sémantiques. Tenez compte du domaine et du niveau de confidentialité des données. Prenez également en compte qui est autorisé à assumer la responsabilité de la gestion des données et des autorisations dans les divisions centralisées et décentralisées.
Vérifier comment les rôles d’espace de travail sont gérés pour les créateurs de modèles sémantiques : déterminez l’impact sur le processus de conception de votre espace de travail. Créez des espaces de travail de données distincts pour chaque domaine afin de pouvoir gérer plus facilement les rôles d’espace de travail et la sécurité des modèles sémantiques de chaque domaine.
Fournir des conseils aux créateurs de modèles sémantiques sur la gestion des autorisations : ajoutez de la documentation pour indiquer aux créateurs de modèles sémantiques comment gérer les autorisations de modèle sémantique. Publiez ces informations sur votre portail centralisé et vos supports de formation.
Choisir qui peut utiliser les connexions DirectQuery pour les modèles sémantiques Power BI : déterminez si vous voulez limiter les créateurs de modèles sémantiques Power BI (qui ont déjà l’autorisation Générer sur un modèle sémantique) qui peuvent créer une connexion à un modèle sémantique Power BI. Définissez le paramètre de locataire Autoriser les connexions DirectQuery aux modèles sémantiques Power BI conformément à cette décision. Si vous décidez de limiter cette fonctionnalité, utilisez un groupe de type Créateurs de modèles sémantiques approuvés Power BI.
Choisir qui peut interroger les modèles sémantiques Power BI avec l’API REST : choisissez s’il faut empêcher les créateurs de contenu Power BI d’interroger les modèles sémantiques Power BI avec l’API REST Power BI. Définissez le paramètre de locataire API REST Exécuter des requêtes de jeu de données conformément à cette décision. Si vous décidez de limiter cette fonctionnalité, utilisez un groupe de type Créateurs de rapports approuvés Power BI.
Choisir la stratégie d’utilisation de SNL ou OLS pour les créateurs de modèles sémantiques : déterminez les cas d’usage et les raisons pour lesquels vous voulez utiliser SNL ou OLS. Tenez compte de la stratégie de conception de l’espace de travail et des personnes qui ont des autorisations de lecture ou de modification quand vous souhaitez appliquer SNL ou OLS pour les créateurs de modèles sémantiques.

Autorisations du créateur de rapports

Les créateurs de rapports ont besoin d’un accès à l’espace de travail pour créer des rapports dans le service Power BI ou les publier à partir de Power BI Desktop. Ils doivent être administrateurs, membres ou contributeurs dans l’espace de travail cible.

Dans la mesure du possible, les créateurs de rapports doivent utiliser un modèle sémantique partagé existant (via une connexion active ou DirectQuery). De cette façon, le processus de création de rapports est dissocié du processus de création du modèle sémantique. Ce type de séparation offre de nombreux avantages pour les scénarios de sécurité et de développement d’équipe.

Un créateur de rapports doit être administrateur, membre ou contributeur de l’espace de travail.

Contrairement aux modèles sémantiques, il n’y a pas d’autorisation Écrire pour les rapports. Pour prendre en charge les créateurs de rapports, vous devez utiliser les rôles d’espace de travail. Pour cette raison, une conception optimale des espaces de travail est importante pour équilibrer les besoins en matière d’organisation et de sécurité du contenu.

Conseil

Pour connaître les autorisations qui permettent de prendre en charge les consommateurs de rapports (y compris les autorisations Lire et Repartager par élément), consultez l’article Planification de la sécurité des consommateurs de rapports.

Autorisations Lire et Générer pour le modèle sémantique sous-jacent

Les créateurs de rapports doivent avoir les autorisations Lire et Générer sur les modèles sémantiques que leurs rapports utilisent, notamment les modèles sémantiques chaînés. Cette autorisation peut être octroyée soit explicitement sur les modèles sémantiques individuels, soit implicitement pour les modèles sémantiques d’espace de travail quand le créateur de rapports est administrateur, membre ou contributeur de l’espace de travail.

Le paramètre de locataire Utiliser des modèles sémantiques dans plusieurs espaces de travail permet aux administrateurs Power BI de configurer les groupes d’utilisateurs qui peuvent créer des rapports utilisant des modèles sémantiques situés dans d’autres espaces de travail. Ce paramètre est destiné aux créateurs de modèles sémantiques et de rapports. En règle générale, nous vous recommandons de laisser ce paramètre activé pour l’ensemble de l’organisation, et d’utiliser les paramètres d’accès à l’espace de travail et les autorisations de modèle sémantique. De cette façon, vous pouvez encourager l’utilisation des modèles sémantiques existants. Dans certains cas, vous envisagerez sans doute de restreindre cette fonctionnalité aux créateurs de contenu approuvés uniquement.

Il existe également le paramètre de locataire Autoriser les connexions actives, qui permet aux administrateurs Power BI de configurer les groupes d’utilisateurs qui peuvent créer des connexions actives à des modèles sémantiques dans Power BI Desktop ou Excel. Il s’adresse spécifiquement aux créateurs de rapports et nécessite également qu’ils aient les autorisations Lire et Générer sur le modèle sémantique que le rapport utilise. Nous vous recommandons de laisser ce paramètre activé pour l’ensemble de l’organisation, et d’utiliser l’accès à l’espace de travail et les autorisations de modèle sémantique. De cette façon, vous pouvez encourager l’utilisation des modèles sémantiques existants. Dans certains cas, vous envisagerez sans doute de restreindre cette fonctionnalité aux créateurs de contenu approuvés uniquement.

Sécurité des données pour le modèle sémantique sous-jacent

Les types de sécurité RLS et OLS (décrits précédemment dans cet article) s’adressent aux consommateurs de rapports. Toutefois, ils doivent parfois également être appliqués pour les créateurs de rapports. La création d’espaces de travail distincts est justifiée quand la sécurité RLS doit être appliquée aux créateurs de rapports et aux consommateurs de rapports.

Considérons le scénario suivant.

Modèles sémantiques partagés centralisés avec SNL : l’équipe BI d’entreprise a publié des modèles sémantiques de ventes dans l’espace de travail Sales Data. Ces modèles sémantiques appliquent SNL pour afficher les données de ventes concernant la région de vente attribuée au consommateur de rapports.
Créateurs de rapports libre-service décentralisés : la division commerciale et marketing compte de nombreux analystes compétents qui créent leurs propres rapports. Ils publient leurs rapports dans l’espace de travail Sales Analytics.
Autorisations Lire et Générer pour les modèles sémantiques : dans la mesure du possible, les analystes utilisent les modèles sémantiques de l’espace de travail Sales Data pour éviter la duplication inutile des données. Comme les analystes ont uniquement les autorisations Lire et Générer sur ces modèles sémantiques (sans les autorisations Écrire ni Modifier), la sécurité SNL est appliquée pour les créateurs de rapports (ainsi que les consommateurs de rapports).
Autorisations Modifier pour l’espace de travail de création de rapports : les analystes ont plus de droits dans l’espace de travail Sales Analytics. Les rôles d’espace de travail Administrateur, Membre ou Contributeur leur permettent de publier et de gérer leurs rapports.

Pour plus d’informations sur RLS et OLS, consultez l’article Planification de la sécurité des consommateurs de rapports. Il décrit comment et quand les sécurités SNL et OLS sont appliquées pour les consommateurs qui sont uniquement autorisés à afficher le modèle sémantique.

Connexion à des modèles sémantiques externes

Quand un créateur de rapport se connecte à un modèle sémantique partagé pour son rapport, le modèle sémantique partagé auquel il se connecte a généralement été publié dans son propre locataire Power BI. Une fois l’autorisation octroyée, il peut aussi se connecter à un modèle sémantique partagé dans un autre locataire. L’autre locataire peut être un partenaire, un client ou un fournisseur.

Cette fonctionnalité est appelée partage de modèles sémantiques sur place (ou partage de modèles sémantiques entre locataires). Les rapports créés par le créateur de rapports (ou les modèles composites créés par un créateur de modèles sémantiques) sont stockés et sécurisés dans votre locataire Power BI en utilisant votre processus normal. Le modèle sémantique partagé d’origine reste dans son locataire Power BI d’origine et toutes les autorisations y sont gérées.

Pour plus d’informations, consultez l’article Planification de la sécurité au niveau du locataire. Il comprend des informations sur les paramètres de locataire et les paramètres de modèle sémantique qui permettent au partage externe de fonctionner.

Tables recommandées

Dans Power BI Desktop, les créateurs de modèles sémantiques peuvent définir une table modèle pour qu’elle devienne une table recommandée. Quand le modèle sémantique est publié sur le service Power BI, les créateurs de rapports peuvent utiliser la galerie de types de données dans Excel pour rechercher la table recommandée, ce qui leur permet d’ajouter les données de la table recommandée pour augmenter leurs feuilles de calcul Excel.

Le paramètre de locataire Autoriser les connexions aux tables recommandées permet aux administrateurs Power BI de configurer les groupes d’utilisateurs qui peuvent accéder aux tables recommandées. Il s’adresse aux utilisateurs Excel qui souhaitent accéder aux tables recommandées Power BI dans les types de données d’organisation Excel. Nous vous recommandons de laisser ce paramètre activé pour l’ensemble de l’organisation, et d’utiliser l’accès à l’espace de travail et les autorisations de modèle sémantique. De cette façon, vous pouvez encourager l’utilisation des tables recommandées.

Autorisations des visuels personnalisés

En plus des visuels de base, les créateurs de rapports Power BI peuvent utiliser des visuels personnalisés. Dans Power BI Desktop, vous pouvez télécharger des visuels personnalisés à partir de Microsoft AppSource. Ils peuvent également être développés en interne avec Power BI SDK et installés en ouvrant le fichier du visuel (.pbviz).

Certains visuels disponibles en téléchargement à partir d’AppSource sont des visuels certifiés. Les visuels certifiés suivent certaines exigences de codes spécifiées qui ont été testées et approuvées par l’équipe Power BI. Les tests vérifient que les visuels n’ont pas accès à des services ou ressources externes.

Le paramètre de locataire Autoriser les visuels créés par Power BI SDK permet aux administrateurs Power BI de contrôler les groupes d’utilisateurs qui peuvent utiliser des visuels personnalisés.

Il existe également le paramètre de locataire Ajouter et utiliser des visuels certifiés uniquement, qui permet aux administrateurs Power BI d’empêcher l’utilisation de visuels non certifiés dans le service Power BI. Ce paramètre peut être activé ou désactivé pour l’ensemble de l’organisation.

Notes

Si vous empêchez l’utilisation des visuels non certifiés, cela s’applique uniquement au service Power BI. Si vous souhaitez restreindre leur utilisation dans Power BI Desktop, demandez aux administrateurs système d’utiliser un paramètre de stratégie de groupe pour empêcher leur utilisation dans Power BI Desktop. Cette étape garantit que les créateurs de rapports ne perdent pas de temps et d’énergie à créer un rapport voué à l’échec s’il est publié sur le service Power BI. Nous vous recommandons vivement de configurer vos utilisateurs pour qu’ils aient des expériences cohérentes dans le service Power BI (avec le paramètre de locataire) et Power BI Desktop (avec la stratégie de groupe).

Power BI Desktop a une option pour montrer un avertissement de sécurité quand un créateur de rapports ajoute un visuel personnalisé au rapport. Les créateurs de rapports peuvent désactiver cette option. Cette option ne vérifie pas si le visuel est certifié.

Les administrateurs Power BI peuvent approuver et déployer des visuels personnalisés pour leur organisation. Les créateurs de rapports peuvent facilement découvrir, mettre à jour et utiliser ces visuels. Les administrateurs peuvent ensuite gérer ces visuels en mettant à jour des versions, ou en désactivant/activant des visuels personnalisés spécifiques. Cette approche est utile quand vous souhaitez rendre disponible un visuel développé en interne pour vos créateurs de rapports ou quand vous achetez un visuel personnalisé auprès d’un fournisseur qui n’est pas dans AppSource. Pour plus d’informations, consultez Visuels organisationnels Power BI.

Utilisez une stratégie équilibrée qui active uniquement des visuels personnalisés certifiés dans votre organisation (avec le paramètre de locataire et la stratégie de groupe décrits précédemment), tout en déployant des visuels organisationnels pour gérer les exceptions.

Check-list : voici les décisions et actions clés pour planifier les autorisations du créateur de rapports :

Choisir la stratégie pour les autorisations du créateur de rapports : déterminez les préférences et les exigences de gestion de la sécurité pour les créateurs de rapports. Tenez compte du domaine et du niveau de confidentialité des données. Prenez également en compte qui est autorisé à assumer la responsabilité de la création et de la gestion des rapports dans les divisions centralisées et décentralisées.
Vérifier comment les rôles d’espace de travail sont gérés pour les créateurs de rapports : déterminez l’impact sur le processus de conception de votre espace de travail. Créez des espaces de travail de données et des espaces de travail de rapports distincts pour chaque domaine, de manière à simplifier les rôles d’espace de travail (et la sécurité du modèle sémantique sous-jacent) pour le domaine.
Fournir des conseils aux créateurs de rapports sur la gestion des autorisations : ajoutez de la documentation pour les créateurs de rapports indiquant comment gérer les autorisations pour les consommateurs de rapports. Publiez ces informations sur votre portail centralisé et vos supports de formation.
Choisir qui peut utiliser les modèles sémantiques partagés : déterminez si vous voulez limiter les créateurs de rapports Power BI (qui ont déjà les autorisations Lire et Générer sur un modèle sémantique) qui peuvent utiliser des modèles sémantiques dans plusieurs espaces de travail. Définissez le paramètre de locataire Utiliser des modèles sémantiques dans plusieurs espaces de travail conformément à cette décision. Si vous décidez de limiter cette fonctionnalité, utilisez un groupe de type Créateurs de rapports approuvés Power BI.
Choisir qui peut utiliser des connexions actives : déterminez si vous voulez limiter les créateurs de rapports Power BI (qui ont déjà les autorisations Lire et Générer sur un modèle sémantique) qui peuvent utiliser des connexions actives. Définissez le paramètre de locataire Autoriser les connexions actives conformément à cette décision. Si vous décidez de limiter cette fonctionnalité, utilisez un groupe de type Créateurs de rapports approuvés Power BI.
Choisir la stratégie d’utilisation de RLS pour les créateurs de rapports : déterminez les cas d’usage et les raisons pour lesquels vous voulez utiliser la sécurité au niveau des lignes. Tenez compte de la stratégie de conception de l’espace de travail pour vérifier que la sécurité RLS est appliquée pour les créateurs de rapports.
Choisir la stratégie d’utilisation des visuels personnalisés : réfléchissez à une stratégie pour indiquer les créateurs de rapports qui peuvent utiliser des visuels personnalisés. Définissez le paramètre de locataire Autoriser les visuels créés par Power BI SDK conformément à cette décision. Créez un processus pour utiliser des visuels organisationnels, si nécessaire.

Autorisations du créateur de flux de données

Les flux de données sont utiles pour centraliser la préparation des données afin que le travail effectué dans Power Query ne soit pas répété sur de nombreux modèles sémantiques. Ils sont fondamentaux pour obtenir une même source de vérité, évitant aux analystes d’avoir besoin d’un accès direct aux sources et les aidant à effectuer des opérations d’extraction, de transformation et de chargement (ETL) à grande échelle.

Un créateur de flux de données doit être Administrateur, Membre ou Contributeur de l’espace de travail.

Pour consommer un flux de données (par exemple, à partir d’un nouveau modèle de données créé dans Power BI Desktop ou dans un autre espace de travail), un créateur de modèles sémantiques peut appartenir à n’importe quel rôle d’espace de travail, y compris le rôle Lecteur. Il n’y a pas de concept de RLS pour les flux de données.

En plus des rôles d’espace de travail, le paramètre de locataire Créer et utiliser des flux de données doit être activé. Ce paramètre de locataire s’applique à toute l’organisation.

Considérons le scénario suivant.

De nombreux modèles sémantiques de l’organisation doivent appliquer une sécurité SNL dynamique. Elle nécessite que les noms d’utilisateurs principaux (UPN) soient stockés dans le modèle sémantique (pour filtrer selon l’identité du consommateur de rapports).
Un créateur de flux de données, qui appartient au service des Ressources Humaines, crée un flux de données avec les informations actuelles des employés, y compris leurs UPN. Il configure le flux de données pour qu’il s’actualise tous les jours.
Les créateurs de modèles sémantiques consomment ensuite le flux de données dans leurs conceptions de modèle pour configurer SNL.

Pour plus d’informations sur l’utilisation des flux de données, consultez les scénarios d’utilisation Préparation de données libre-service et Préparation de données avancée.

Check-list : voici les décisions et actions clés pour planifier les autorisations du créateur de flux de données :

Choisir la stratégie pour les autorisations du créateur de flux de données : déterminez les préférences et les exigences de gestion de la sécurité pour les créateurs de flux de données. Déterminez qui est autorisé ou encouragé à prendre en charge la gestion des activités de préparation des données dans les divisions centralisées et décentralisées.
Choisir qui peut créer des flux de données : déterminez si vous devez limiter les créateurs de données Power BI qui peuvent créer des flux de données. Définissez le paramètre de locataire Créer et utiliser des flux de données conformément à cette décision.
Vérifier comment les rôles d’espace de travail sont gérés pour les créateurs de flux de données : déterminez l’impact sur le processus de conception de votre espace de travail. Créez des espaces de travail de flux de données distincts par domaine afin de pouvoir gérer les rôles et les autorisations d’espace de travail séparément pour chaque domaine, si nécessaire.

Autorisations du créateur de datamarts

Un datamart est une solution analytique libre-service qui permet aux utilisateurs de stocker et d’explorer des données chargées dans une base de données relationnelle complètement managée. Il comprend également un modèle sémantique généré automatiquement.

Les datamarts fournissent une expérience simple utilisant peu de code pour ingérer des données à partir de différentes sources de données, et extraire, transformer et charger (ETL) les données avec Power Query Online. Les données sont chargées dans une base de données Azure SQL qui est complètement managée et ne nécessite aucun paramétrage ni optimisation. Le modèle sémantique généré automatiquement est toujours synchronisé avec la base de données managée, car il est en mode DirectQuery.

Vous pouvez créer un datamart quand vous êtes Administrateur, Membre ou Contributeur d’espace de travail. Les rôles d’espace de travail sont également mappés aux rôles au niveau de la base de données Azure SQL (toutefois, comme la base de données est complètement managée, les autorisations utilisateur ne peuvent pas être modifiées ni gérées dans la base de données relationnelle).

Le paramètre de locataire Créer des datamarts permet aux administrateurs Power BI de configurer les groupes d’utilisateurs qui peuvent créer des datamarts.

Pour les datamarts, le terme partage prend une signification différente que pour les autres types de contenu Power BI. En règle générale, une opération de partage s’adresse à un consommateur, car elle fournit une autorisation en lecture seule sur un élément, comme un rapport.

Le partage d’un datamart s’adresse aux créateurs de contenu (plutôt qu’aux consommateurs). Il octroie les autorisations Lire et Générer, qui permettent aux utilisateurs d’interroger le modèle sémantique ou la base de données relationnelle, selon ce qu’ils préfèrent.

Le partage d’un datamart permet aux créateurs de contenu de :

Générer du contenu à l’aide du modèle sémantique généré automatiquement : le modèle sémantique est la couche sémantique sur laquelle les rapports Power BI peuvent être générés. La plupart des créateurs de rapports doivent utiliser le modèle sémantique.
Se connecter à la base de données Azure SQL et l’interroger : la base de données relationnelle est utile pour les créateurs de contenu souhaitant créer des modèles sémantiques ou des rapports paginés. Ils peuvent écrire des requêtes SQL (Structured Query Language) pour récupérer des données à partir du point de terminaison SQL.

Sécurité au niveau des lignes du datamart

Vous pouvez définir RLS pour les datamarts afin de limiter l’accès aux données aux utilisateurs spécifiés. La sécurité SNL est configurée dans l’éditeur de datamart du service Power BI, et elle est automatiquement appliquée au modèle sémantique généré automatiquement et à la base de données Azure SQL (sous forme de règles de sécurité).

Quelle que soit la façon dont un utilisateur choisit de se connecter au datamart (au modèle sémantique ou à la base de données), des autorisations SNL identiques sont appliquées.

Check-list : voici les décisions et actions clés pour planifier les autorisations du créateur de datamarts :

Choisir la stratégie pour les autorisations du créateur de datamarts : déterminez les préférences et les exigences de gestion de la sécurité pour les créateurs de datamarts. Déterminez qui est autorisé ou encouragé à prendre en charge la gestion des données dans les divisions centralisées et décentralisées.
Choisir qui peut créer des datamarts : déterminez si vous devez limiter les créateurs de données Power BI qui peuvent créer des datamarts. Définissez le paramètre de locataire Créer et utiliser des datamarts conformément à cette décision. Si vous décidez de limiter les personnes autorisées à créer des datamarts, utilisez un groupe de type Créateurs de datamarts approuvés Power BI.
Vérifier comment les rôles d’espace de travail sont gérés pour les créateurs de datamarts : déterminez l’impact sur le processus de conception de votre espace de travail. Créez des espaces de travail de données distincts par domaine afin de simplifier les rôles d’espace de travail et la sécurité du modèle sémantique pour le domaine.
Fournir des conseils aux créateurs de datamarts sur la gestion des autorisations : ajoutez de la documentation pour les créateurs de datamarts indiquant comment gérer les autorisations de datamart. Publiez ces informations sur votre portail centralisé et vos supports de formation.
Choisir la stratégie d’utilisation de RLS dans les datamarts : déterminez les cas d’usage et les raisons pour lesquels vous voulez utiliser RLS dans un datamart.

Autorisations du créateur de cartes de performance

Les métriques dans Power BI vous permettent d’organiser des métriques spécifiques et de les suivre par rapport aux objectifs métier clés. Les métriques sont ajoutées aux cartes de performance, qui peuvent être partagées avec d’autres utilisateurs et consultées dans un seul volet.

Les cartes de performance peuvent être sécurisées avec trois niveaux d’autorisations :

Espace de travail.
Autorisations de carte de performance (par élément).
Métriques (dans la carte de performance).

Un utilisateur qui crée ou gère entièrement une carte de performance doit être Administrateur, Membre ou Contributeur de l’espace de travail.

Comme les métriques couvrent souvent plusieurs domaines, nous vous recommandons de créer un espace de travail distinct afin de pouvoir gérer indépendamment les autorisations des créateurs et des consommateurs.

Le paramètre de locataire Créer et utiliser des métriques permet aux administrateurs Power BI de configurer les groupes d’utilisateurs qui peuvent créer des métriques de carte de performance.

Autorisations de carte de performance

Vous pouvez attribuer les autorisations de carte de performance suivantes.

Lire : cette autorisation permet à un utilisateur de voir la carte de performance.
Repartager : destinée à toute personne ayant une autorisation existante sur la carte de performance, cette autorisation permet aux utilisateurs de partager la carte de performance avec un autre utilisateur.

Conformément aux autres types de contenu dans le service Power BI, les autorisations par élément sont utiles quand l’intention est de partager un élément avec un autre utilisateur. Nous vous recommandons d’utiliser des rôles d’espace de travail et des autorisations d’application dans la mesure du possible.

Autorisations au niveau des métriques

Chaque carte de performance a un ensemble d’autorisations au niveau des métriques que vous pouvez configurer dans les paramètres de la carte de performance. Les autorisations au niveau des métriques (au sein d’une carte de performance) peuvent être accordées différemment de celles de l’espace de travail ou de la carte de performance (par élément).

Les rôles au niveau des métriques vous permettent de définir :

Qui peut voir des métriques individuelles sur une carte de performance.
Qui peut mettre à jour des métriques individuelles en :
- Mettant à jour l’état pendant un archivage.
- Ajoutant des notes pendant un archivage.
- Mettant à jour la valeur actuelle pendant un archivage.

Pour réduire le niveau de la maintenance future, vous pouvez définir des autorisations par défaut dont héritent les sous-paramètres que vous créez par la suite.

Check-list : voici les décisions et actions clés pour planifier les autorisations du créateur de métriques :

Choisir la stratégie pour les autorisations du créateur de cartes de performance : déterminez les préférences et les exigences de gestion de la sécurité pour les créateurs de cartes de performance. Déterminez qui est autorisé ou encouragé à prendre en charge la gestion des données dans les divisions centralisées et décentralisées.
Choisir qui peut créer des cartes de performance : déterminez si vous devez limiter les créateurs de données Power BI qui peuvent créer des cartes de performance. Définissez le paramètre de locataire Créer et utiliser des métriques conformément à cette décision. Si vous décidez de limiter les personnes autorisées à créer des cartes de performance, utilisez un groupe de type Créateurs de cartes de performance approuvés Power BI.
Vérifier comment les rôles d’espace de travail sont gérés pour les créateurs de cartes de performance : déterminez l’impact sur le processus de conception de votre espace de travail. Créez des espaces de travail distincts pour les cartes de performance quand le contenu couvre plusieurs domaines.
Fournir des conseils aux créateurs de cartes de performance sur la gestion des autorisations : ajoutez de la documentation pour les créateurs de cartes de performance indiquant comment gérer les autorisations au niveau des métriques. Publiez ces informations sur votre portail centralisé et vos supports de formation.

Publication de contenu

Cette section comprend des rubriques de publication de contenu destinées aux créateurs de contenu.

Espaces de travail

Les créateurs de contenu ont besoin d’un accès au rôle Administrateur, Membre ou Contributeur pour publier du contenu sur un espace de travail. Pour plus d’informations, consultez les rôles d’espace de travail décrits plus haut dans cet article.

À l’exception de BI personnel, les créateurs de contenu doivent être encouragés à publier du contenu sur des espaces de travail standard, au lieu de leur espace de travail personnel.

Le paramètre de locataire Bloquer la republication et désactiver l’actualisation du package change le comportement de publication des modèles sémantiques. Quand il est activé, les administrateurs, membres ou contributeurs de l’espace de travail ne peuvent pas publier les changements d’un modèle sémantique. Seul le propriétaire du modèle sémantique est autorisé à publier une mise à jour (en forçant la prise de contrôle du modèle sémantique avant de publier le modèle sémantique mis à jour). Comme ce paramètre de locataire s’applique à l’ensemble de l’organisation, activez-le avec précaution dans la mesure où il affecte tous les modèles sémantiques de l’ensemble du locataire. Veillez à communiquer à vos créateurs de modèles sémantiques les effets de ce paramètre, car il change le comportement normal des rôles d’espace de travail.

Synchronisation Power Apps

Vous pouvez créer une solution Power Apps qui comprend des rapports Power BI incorporés. Le processus Power Apps crée automatiquement un espace de travail Power BI dédié pour stocker et sécuriser les rapports et modèles sémantiques Power BI. Pour gérer les éléments qui existent à la fois dans Power Apps et Power BI, il existe un processus de synchronisation.

Le processus synchronise les rôles de sécurité pour que Power BI puisse hériter des rôles initialement configurés dans Power Apps. Il permet également au créateur de contenu de gérer les autorisations de lecture des rapports Power BI (et des modèles sémantiques associés) incorporés dans une application Power Apps.

Pour plus d’informations sur la synchronisation des rôles Power Apps avec les rôles d’espace de travail Power BI, consultez Synchronisation des autorisations entre l’environnement Power Apps et l’espace de travail Power BI.

Accès du pipeline de déploiement

Les créateurs et les propriétaires de contenu peuvent utiliser des pipelines de déploiement Power BI pour la publication de contenu libre-service. Les pipelines de déploiement simplifient le processus de publication et améliorent le niveau de contrôle en cas de publication de nouveau contenu.

Vous gérez les autorisations de pipeline (pour les utilisateurs qui peuvent déployer du contenu avec un pipeline de déploiement) séparément des rôles d’espace de travail. L’accès à l’espace de travail et au pipeline de déploiement est nécessaire pour les utilisateurs effectuant un déploiement.

Les créateurs de contenu peuvent également avoir besoin des autorisations suivantes :

Autorisations de création d’espace de travail (quand les espaces de travail doivent être créés par le pipeline).
Autorisations de capacité Premium ou Fabric (quand les espaces de travail sont attribués par le pipeline).

Pour plus d’informations, consultez Accès du pipeline de déploiement.

Point de terminaison XMLA

Le point de terminaison XMLA utilise le protocole XMLA pour exposer toutes les fonctionnalités d’un modèle de données tabulaire, y compris certaines opérations de modélisation des données qui ne sont pas prises en charge par Power BI Desktop. Vous pouvez utiliser l’API TOM (Tabular Object Model) pour faire des changements programmatiques sur un modèle de données.

Le point de terminaison XMLA fournit également une connectivité. Vous pouvez vous connecter à un modèle sémantique uniquement quand l’espace de travail a un mode de licence Premium par utilisateur, Premium par capacité ou Embedded. Une fois qu’une connexion est établie, un outil XMLA peut opérer sur le modèle de données pour lire ou écrire des données. Pour plus d’informations sur l’utilisation du point de terminaison XMLA pour gérer un modèle sémantique, consultez le scénario d’utilisation de la gestion avancée des modèles de données.

L’accès par le point de terminaison XMLA respecte les autorisations existantes. Les administrateurs, membres et contributeurs de l’espace de travail ont implicitement l’autorisation de modèle sémantique Écrire, ce qui signifie qu’ils peuvent déployer de nouveaux modèles sémantiques à partir de Visual Studio et exécuter des scripts TMSL (Tabular Modeling Scripting Language) dans SQL Server Management Studio (SSMS).

Les utilisateurs avec l’autorisation de modèle sémantique Générer peuvent utiliser le point de terminaison XMLA pour se connecter aux modèles sémantiques et les parcourir à des fins de consommation et de visualisation des données. Les règles SNL sont respectées et les utilisateurs ne peuvent pas voir les métadonnées de modèle sémantique internes.

Le paramètre de locataire Autoriser les points de terminaison XMLA et l’analyse dans Excel avec les modèles sémantiques locaux fait référence à deux fonctionnalités : il contrôle les groupes d’utilisateurs qui peuvent utiliser le point de terminaison XMLA pour interroger et/ou gérer des modèles sémantiques dans le service Power BI. Il détermine également si Analyser dans Excel peut être utilisé avec des modèles locaux SQL Server Analysis Services (SSAS).

Notes

L’aspect Analyser dans Excel de ce paramètre de locataire s’applique uniquement aux modèles locaux SQL Server Analysis Services (SSAS). La fonctionnalité Analyser dans Excel standard, qui se connecte à un modèle sémantique Power BI dans le service Power BI, est contrôlée par le paramètre de locataire Autoriser les connexions actives.

Publier sur le web

Publier sur le web est une fonctionnalité qui fournit l’accès aux rapports Power BI à toute personne sur Internet. Elle ne nécessite pas d’authentification et d’accès n’est pas journalisée à des fins d’audit. Étant donné que les consommateurs de rapports n’ont pas besoin d’appartenir à l’organisation ou d’avoir une licence Power BI, cette technique est bien adaptée au journalisme de données, un processus où les rapports sont incorporés dans des billets de blog, des sites web, des e-mails ou des médias sociaux.

Attention

Publier sur le web peut exposer des données sensibles ou confidentielles, que ce soit accidentellement ou intentionnellement. C’est la raison pour laquelle elle est désactivée par défaut. Publier sur le web doit être utilisé seulement pour les rapports qui contiennent des données consultables par le public.

Le paramètre de locataire Publier sur le web permet aux administrateurs Power BI de contrôler les groupes d’utilisateurs qui peuvent publier des rapports sur le web. Pour maintenir un niveau de contrôle plus élevé, nous vous recommandons de ne pas ajouter d’autres groupes à ce paramètre de locataire (comme les administrateurs Power BI ou d’autres types de créateurs de contenu). À la place, appliquez un accès utilisateur spécifique en utilisant un groupe de sécurité de type Publication publique Power BI. Vérifiez que le groupe de sécurité est bien géré.

Incorporation dans des applications personnalisées

Le paramètre de locataire Incorporer du contenu dans des applications permet aux administrateurs Power BI de contrôler les utilisateurs qui peuvent incorporer du contenu Power BI en dehors du service Power BI. Quand vous envisagez d’incorporer du contenu Power BI dans des applications personnalisées, activez ce paramètre pour des groupes spécifiques, comme les développeurs d’applications.

Incorporation dans PowerPoint

Le paramètre de locataire Activer le complément Power BI pour PowerPoint permet aux administrateurs Power BI de contrôler les utilisateurs qui peuvent incorporer des pages de rapport Power BI dans des présentations PowerPoint. Si nécessaire, activez ce paramètre pour des groupes spécifiques, comme les créateurs de rapports.

Notes

Pour cette fonctionnalité, les utilisateurs doivent installer le complément Power BI pour PowerPoint. Pour utiliser le complément, les utilisateurs doivent avoir accès au magasin de compléments Office, ou le complément doit être disponible comme complément géré par l’administrateur. Pour plus d’informations, consultez Complément Power BI pour PowerPoint.

Indiquez aux créateurs de rapports de faire attention à l’emplacement où ils enregistrent leurs présentations PowerPoint et avec qui ils les partagent. En effet, une image des visuels de rapport Power BI est montrée aux utilisateurs quand ils ouvrent la présentation. Cette image est capturée à partir de la dernière connexion au fichier PowerPoint. Toutefois, l’image pourrait révéler par inadvertance des données que l’utilisateur destinataire n’est pas autorisé à voir.

Remarque

L’image peut être utile quand l’utilisateur destinataire n’a pas encore le complément ou quand que le complément n’est pas connecté au service Power BI pour récupérer des données. Dès que l’utilisateur est connecté, seules les données que l’utilisateur peut voir (en appliquant une règle RLS) sont récupérées sur Power BI.

Applications modèles

Les applications modèles permettent aux partenaires Power BI et aux fournisseurs de logiciels de créer des applications Power BI avec peu ou pas de code, et de les déployer pour n’importe quel client Power BI.

Le paramètre de locataire Publier des applications modèles permet aux administrateurs Power BI de contrôler les utilisateurs qui peuvent publier des applications modèles en dehors de l’organisation, par exemple sur Microsoft AppSource. Pour la plupart des organisations, ce paramètre de locataire doit être désactivé ou étroitement contrôlé. Utilisez un groupe de sécurité de type Créateurs d’applications modèles externes Power BI.

Abonnements par courrier

Vous pouvez vous abonner et abonner d’autres utilisateurs aux rapports paginés, tableaux de bord et rapports Power BI. Power BI envoie ensuite un e-mail selon une planification que vous définissez. L’e-mail contient un instantané et un lien vers le rapport ou le tableau de bord.

Vous pouvez créer un abonnement comprenant d’autres utilisateurs si vous êtes Administrateur, Membre ou Contributeur de l’espace de travail. Si le rapport se trouve dans un espace de travail Premium, vous pouvez abonner des groupes (qu’ils soient ou non dans votre domaine) et des utilisateurs externes. Quand vous configurez l’abonnement, vous avez la possibilité d’accorder des autorisations sur l’élément. Les autorisations d’accès direct par élément sont utilisées dans ce but et sont décrites dans l’article Planification de la sécurité des consommateurs de rapports.

Attention

La fonctionnalité d’abonnement aux e-mails peut partager du contenu avec des audiences internes et externes. Par ailleurs, quand la sécurité SNL est appliquée sur le modèle sémantique sous-jacent, les pièces jointes et les images sont générées en utilisant le contexte de sécurité de l’utilisateur abonné.

Le paramètre de locataire Abonnements aux e-mails permet aux administrateurs Power BI de contrôler si cette fonctionnalité est activée ou désactivée pour l’ensemble de l’organisation.

Il existe certaines limitations concernant les pièces jointes qui dépendent des restrictions de licences et des paramètres de locataire. Pour plus d’informations, consultez Abonnements aux e-mails de rapports et de tableaux de bord dans le service Power BI.

Check-list : voici les décisions et actions clés pour planifier la publication de contenu :

Choisir la stratégie qui définit où publier le contenu, comment et par qui : déterminez les préférences et les exigences qui existent pour l’emplacement de publication du contenu.
Vérifier l’accès à l’espace de travail : vérifiez l’approche de conception de l’espace de travail. Vérifiez comment utiliser les rôles d’accès à l’espace de travail pour prendre en charge votre stratégie qui définit où publier le contenu.
Choisir comment gérer les autorisations de pipeline de déploiement : déterminez les utilisateurs autorisés à publier du contenu en utilisant un pipeline de déploiement. Définissez les autorisations de pipeline de déploiement en conséquence. Vérifiez que l’accès à l’espace de travail est également fourni.
Choisir qui peut se connecter aux modèles sémantiques en utilisant le point de terminaison XMLA : déterminez les utilisateurs autorisés à interroger ou à gérer les modèles sémantiques en utilisant le point de terminaison XMLA. Définissez le paramètre de locataire Autoriser les points de terminaison XMLA et l’analyse dans Excel avec les modèles sémantiques locaux conformément à cette décision. Si vous décidez de limiter cette fonctionnalité, utilisez un groupe de type Créateurs de contenu approuvés Power BI.
Choisir qui peut publier des rapports publiquement : déterminez les utilisateurs qui sont autorisés à publier des rapports Power BI publiquement, le cas échéant. Définissez le paramètre de locataire Publier sur le web conformément à cette décision. Utilisez un groupe de type Publication publique Power BI.
Choisir qui peut incorporer du contenu dans des applications personnalisées : déterminez qui doit être autorisé à incorporer du contenu en dehors du service Power BI. Définissez le paramètre de locataire Incorporer du contenu dans des applications conformément à cette décision.
Choisir qui peut incorporer du contenu dans PowerPoint : déterminez qui doit être autorisé à incorporer du contenu dans PowerPoint. Définissez le paramètre de locataire Activer le complément Power BI pour PowerPoint conformément à cette décision.
Choisir qui peut publier des applications modèles : déterminez votre stratégie d’utilisation des applications modèles en dehors de l’organisation. Définissez le paramètre de locataire Publier des applications modèles conformément à cette décision.
Choisir s’il faut activer les abonnements : vérifiez quelle est votre stratégie d’utilisation des abonnements. Définissez le paramètre de locataire Abonnements aux e-mails conformément à cette décision.

Actualiser les données

Après la publication, les créateurs de données doivent vérifier que leurs modèles sémantiques et flux de données (contenant des données importées) sont régulièrement actualisés. Vous devez également choisir les stratégies appropriées pour les propriétaires de modèles sémantiques et de flux de données.

Propriétaire de modèle sémantique

Chaque modèle sémantique a un propriétaire, représenté par un compte d’utilisateur. Le propriétaire du modèle sémantique est requis pour configurer l’actualisation planifiée et définir les paramètres du modèle sémantique.

Par défaut, le propriétaire du modèle sémantique reçoit également des demandes d’accès de la part des créateurs de rapports qui souhaitent obtenir l’autorisation Générer (sauf si les Paramètres de demande d’accès du modèle sémantique sont définis pour fournir des instructions personnalisées). Pour plus d’informations, consultez la section Workflow de demande d’accès pour les créateurs dans cet article.

Power BI peut obtenir les informations d’identification de deux façons pour actualiser un modèle sémantique.

Le propriétaire du modèle sémantique stocke les informations d’identification dans les paramètres du modèle sémantique.
Le propriétaire du modèle sémantique référence une passerelle dans les paramètres du modèle sémantique (qui contient une source de données avec des informations d’identification stockées).

Si un autre utilisateur doit configurer l’actualisation ou définir des paramètres de modèle sémantique, il doit s’approprier le modèle sémantique. Un administrateur, un membre ou un contributeur de l’espace de travail peut se réapproprier le modèle sémantique.

Attention

La réappropriation du jeu de données supprime définitivement toutes les informations d’identification stockées pour le modèle sémantique. Les informations d’identification doivent être entrées de nouveau pour que les opérations d’actualisation des données reprennent.

Dans l’idéal, le propriétaire du modèle sémantique est l’utilisateur responsable du modèle sémantique. Vous devez mettre à jour le propriétaire du modèle sémantique s’il quitte l’organisation ou change de rôle. Par ailleurs, n’oubliez pas que quand le compte d’utilisateur du propriétaire du modèle sémantique est désactivé dans Microsoft Entra ID (auparavant appelé Azure Active Directory), l’actualisation des données est automatiquement désactivée. Dans ce cas, un autre utilisateur doit récupérer la propriété du modèle sémantique pour que les opérations d’actualisation des données reprennent.

Propriétaire du flux de données

Comme les modèles sémantiques, les flux de données ont également un propriétaire, représenté par un compte d’utilisateur. Les informations et les conseils fournis dans la rubrique précédente sur les propriétaires de modèles sémantiques s’appliquent également aux propriétaires de flux de données.

Check-list : voici les décisions et actions clés pour planifier la sécurité des processus d’actualisation des données :

Choisir la stratégie pour les propriétaires de modèles sémantiques : déterminez les préférences et les exigences qui existent pour gérer les propriétaires de modèles sémantiques.
Choisir la stratégie pour les propriétaires de flux de données : déterminez les préférences et les exigences qui existent pour gérer les propriétaires de flux de données.
Ajouter de la documentation et une formation pour les créateurs de modèles sémantiques : ajoutez des conseils pour indiquer à vos créateurs de données comment gérer les propriétaires pour chaque type d’élément.

Pour plus de considérations, d’actions, de critères décisionnels et de recommandations afin de vous aider à prendre des décisions concernant l’implémentation de Power BI, consultez les domaines correspondants.

Planification de l’implémentation de Power BI : planification de la sécurité du créateur de contenu

Stratégie pour les créateurs de contenu

Créateurs de données

Créateurs de rapports

Autorisations pour les créateurs

Création de contenu

Autorisations de publication du contenu

Actualisation des données

Découvrir du contenu pour les créateurs

Workflow de demande d’accès pour les créateurs

Créer et publier du contenu

Rôles d’espace de travail

Administrateur d’espace de travail

Membre de l’espace de travail

Contributeur d’espace de travail

Visionneuse d’espace de travail

Considérations relatives à la propriété de l’espace de travail

Variantes des rôles d’espace de travail

Autorisations du créateur d’applications

Autorisations des sources de données

Accès à une source de données

Niveaux de confidentialité

Requêtes de base de données natives

Connecteurs personnalisés

Autorisations de créateur de modèle sémantique

Autorisations de modèle sémantique

Autorisation de modèle sémantique Lire

Autorisation de modèle sémantique Générer

Autorisation de modèle sémantique Écrire

Autorisation de modèle sémantique Repartager

Sécurité des données de modèle sémantique

Modèles sémantiques chaînés

Requêtes d’API de modèle sémantique

Autorisations du créateur de rapports

Autorisations Lire et Générer pour le modèle sémantique sous-jacent

Sécurité des données pour le modèle sémantique sous-jacent

Connexion à des modèles sémantiques externes

Tables recommandées

Autorisations des visuels personnalisés

Autorisations du créateur de flux de données

Autorisations du créateur de datamarts

Partage de datamart

Sécurité au niveau des lignes du datamart

Autorisations du créateur de cartes de performance

Autorisations de carte de performance

Autorisations au niveau des métriques

Publication de contenu

Espaces de travail

Synchronisation Power Apps

Accès du pipeline de déploiement

Point de terminaison XMLA

Publier sur le web

Incorporation dans des applications personnalisées

Incorporation dans PowerPoint

Applications modèles

Abonnements par courrier

Actualiser les données

Propriétaire de modèle sémantique

Propriétaire du flux de données

Contenu connexe

Commentaires

Commentaires

Ressources supplémentaires