Cet article fait suite Ă notre article Power BI: ContrĂ´ler qui voit quoi (1 de 2), qui prĂ©sentait la technique de base pour intĂ©grer des règles de sĂ©curitĂ© dans un rapport Power BI. Dans cet article, nous avions créé des rĂ´les de sĂ©curitĂ© dans Power BI Desktop et nous avions associĂ© ces rĂ´les de sĂ©curitĂ© Ă des usagers, dans Power BI Service. Dans le prĂ©sent article, nous allons explorer d’autres options concernant la sĂ©curitĂ© des donnĂ©es dans Power BI, soit la reprise de la sĂ©curitĂ© Ă la source d’un cube SSAS tabulaire, la sĂ©curitĂ© dynamique par ligne et la sĂ©curitĂ© dans les rapports partagĂ©s avec des usagers externes.
1. Reprise de la sécurité à la source
De façon gĂ©nĂ©rale, lorsque vous publiez un rapport Power BI dans le service, la publication et la mise Ă jour s’effectue Ă partir des informations d’identification que vous avez utilisĂ©es au moment de la publication. Ce faisant, si le rapport ne possède pas de règles de sĂ©curitĂ© dĂ©finies dans Power BI (mĂ©thode expliquĂ©e dans l’article Power BI: ContrĂ´ler qui voit quoi (1 de 2)), tous les usagers ayant accès Ă ce rapport verront les mĂŞmes donnĂ©es.
Si toutefois les donnĂ©es sources proviennent d’un cube SSAS (SQL Server Analysis Services) tabulaire et que vous y ĂŞtes connectĂ© en connexion active, le service peut reprendre tout simplement la sĂ©curitĂ© Ă la source. En effet, si votre cube SSAS comprend dĂ©jĂ toutes les règles de sĂ©curitĂ©, il serait inutile de les rĂ©pliquer dans Power BI Desktop. Pour en savoir davantage sur la connexion active, je vous invite Ă lire l’article Power BI: Importation de donnĂ©es vs connexion directe.
Pour reprendre la sĂ©curitĂ© Ă la source, vous devez d’abord installer une passerelle de donnĂ©es dans Power BI Service (data gateway) et y ajouter votre cube SSAS tabulaire comme source de donnĂ©es. Pour ce faire, vous devez utiliser un compte administrateur. La passerelle utilisera le Effective User Name de Power BI pour se connecter Ă SSAS et la requĂŞte retournĂ©e sera basĂ©e sur ce nom d’usager.
Par dĂ©faut, le Effective User Name devrait ĂŞtre le compte Power BI de l’usager. Si le domaine du serveur SSAS et de Power BI n’est pas le mĂŞme, il faudra effectuer un “mapping” de comptes.
Références:
- https://docs.microsoft.com/fr-fr/power-bi/service-gateway-onprem-indepth
- https://docs.microsoft.com/fr-fr/power-bi/desktop-ssas-multidimensional
Vous devez analyser de grandes quantités de données et les présenter dans des rapports et tableaux de bord, avec des indicateurs de performance pertinents ? Développez vos compétences avec nos formations en Power BI.
2. Sécurité par ligne (RLS) dynamique
La sĂ©curitĂ© RLS dynamique permet de dĂ©placer la gestion des usagers au niveau des donnĂ©es elles-mĂŞmes. Ceci permet d’ajouter et de supprimer plus aisĂ©ment des usagers sans avoir Ă mettre Ă jour le cube Ă chaque fois. Ceci peut s’avĂ©rer très utile dans les cas oĂą il y a Ă©normĂ©ment d’usagers avec Ă©normĂ©ment de rĂ´les diffĂ©rents. Dans ces cas particuliers, la dĂ©finition de la sĂ©curitĂ© est donc Ă cĂ´tĂ© de l’information du compte d’usager, dans les donnĂ©es sources.
Pour implanter de la sĂ©curitĂ© par ligne dynamique, vous devez avoir une table d’usagers avec les noms d’usagers (courriels) et cette table doit ĂŞtre liĂ©e Ă la table de faits en relation bidirectionnelle.
Vous devez aussi appliquer le filtre de sécurité dans les deux directions.
Vous devez finalement crĂ©er un rĂ´le de sĂ©curitĂ© qui utilisera la fonction Username(). Pour comprendre comment fonctionne cette fonction, nous avons créé une mesure NomUsager Ă l’aide de la fonction Username().
Dans Power BI service, cette mesure affiche l’information suivante (elle reprend mon courriel):
Dans Power BI Desktop, dans la gestion des rôles, au lieu de créer une panoplie de rôles différents, nous allons plutôt créer un seul rôle et nous allons ensuite appliquer un filtre sur la colonne Nom Usager de la table Usagers et ce filtre utilisera la fonction Username().
Sans rĂ´le de sĂ©curitĂ©, les deux tables et la mesure Username s’affichent comme suit dans Power BI Desktop:
Si on test le rôle de sécurité sur mon courriel, on obtient ceci:
Il faut nĂ©anmoins assigner le rĂ´le Ă tous les usagers concernĂ©s dans PBI Service. Cela ne veut pas dire que tous les usagers ajoutĂ©s au rĂ´le verront quelque chose… tout dĂ©pendra de leur nom d’usager (username).
Références:
- http://radacad.com/dynamic-row-level-security-with-power-bi-made-simple
- http://radacad.com/dynamic-row-level-security-with-organizational-hierarchy-power-bi
- http://radacad.com/dynamic-row-level-security-with-power-bi-made-simple
- http://radacad.com/dynamic-row-level-security-with-manager-level-access-in-power-bi
- https://www.kasperonbi.com/power-bi-desktop-dynamic-security-cheat-sheet/
3. Azure Active Directory B2B
Si vous souhaitez partager des donnĂ©es sĂ©curisĂ©es avec des usagers Ă l’extĂ©rieur de votre organisation, vous pouvez le faire Ă partir d’Azure Active Directory.
Étape 1:
- CrĂ©er un espace d’application Power BI dans Power BI Service
- Ajouter d’autres usagers comme administrateurs Ă l’espace de travail collaboratif
- CrĂ©er le contenu Ă partager Ă l’intĂ©rieur de l’application
Étape 2:
- Inviter les usagers externes
- Invitations planifiées (planned invites): à partir du portail AAD
- Ajouter un nouvel usager invité (new guest user) et insérer le courriel externe
- Ajouter un message d’invitation
- L’usager invitĂ© devra cliquer sur le lien qu’il recevra pour accĂ©der au rapport
- Invitation ad-hoc (ad-hoc invites)
- Ajouter les accès aux courriels externes lors de la publication de l’application
- Invitations planifiées (planned invites): à partir du portail AAD
Ă€ noter que les invitations sont requises seulement la première fois qu’un usager externe est invitĂ© Ă rejoindre l’organisation.
Quelles sont les licences nécessaires pour réussir un tel partage?
- Si votre entreprise dĂ©tient une licence Premium, vos usagers externes n’auront pas besoin de licence Power BI
- Si votre entreprise n’est pas dĂ©tentrice d’une licence Premium:
- Soit vous assignez une licence PRO Ă vos usagers externes
- Soit vos usagers utilisent leurs propres licences PRO
Et qu’en est-il de la sĂ©curitĂ© par ligne dans le cas oĂą les rapports sont partagĂ©s avec des usagers externes?
La sĂ©curitĂ© RLS peut ĂŞtre utilisĂ©e. Des rĂ´les peuvent ĂŞtre créés et ensuite associĂ©s Ă des usagers externes, de la mĂŞme manière qu’ils sont associĂ©s Ă des usagers internes. Le tout fonctionne aussi avec la sĂ©curitĂ© par ligne dynamique. Dans ce cas, il est mieux d’utiliser les invitations planifiĂ©es et prĂ©voir les règles de sĂ©curitĂ© avant de partager le contenu avec les usagers externes. Si votre rapport a une connexion Ă une source locale comme SSAS ou SQL, il faudra faire le “mapping” des usagers externes Ă des usagers internes.
Référence:
Formation complémentaire
Vous devez manipuler et analyser beaucoup de données et êtes à la recherche d’un outil BI (Business Intelligence) performant, en mode libre-service ? Suivez la formation Power BI – Niveau 1.
Bonjour Sophie,
Merci d’abord pour les nombreux articles très intĂ©ressants que tu crĂ©es et partages.
Je suis dans un cas oĂą j’aimerais gĂ©rer le rĂ´le des utilisateurs de mon dashboard, avec de multiples niveaux hiĂ©rarchiques, mais sans indication de ceux-ci.
Je m’explique : M. A supervise M. B et M. C, il voit donc les informations les concernant. M. A est quant Ă lui supervisĂ© par M. D. J’aimerais que M. D puisse alors voir les informations de M.A, mais aussi celles de M. B et M. C. Avez-vous une idĂ©e de comment faire ?
Existe-t-il une fonction permettant par exemple de mettre une condition “Si M. D est le supĂ©rieur de M. A, et que M. A est le supĂ©rieur de M. B et M. C, alors M. D est le supĂ©rieur de M. B et M. C” ?
Merci beaucoup,
Thomas.
Bonjour,
Vous trouverez un article Ă ce sujet ici http://angryanalyticsblog.azurewebsites.net/index.php/2016/12/27/dynamic-rls-via-hierarchy-in-power-bi/.
Au plaisir,
Sophie