Power BI: Contrôler qui voit quoi (2 de 2)

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

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

À 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?

1. Si votre entreprise détient une licence Premium, vos usagers externes n’auront pas besoin de licence Power BI
2. Si votre entreprise n’est pas détentrice d’une licence Premium:
   1. Soit vous assignez une licence PRO à vos usagers externes
   2. 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:

• https://docs.microsoft.com/en-us/azure/active-directory/active-directory-b2b-what-is-azure-ad-b2b

Le CFO masqué vous offre un vaste choix de formations Excel et Power BI, réparties dans 8 catégories: Excel – Tableaux de bord, Excel – Modélisation financière, Excel – VBA, Excel – Power Tools, Excel – Ninja, Power BI, Finance corporative et Compléments avancés. Ces formations sont offertes en classe, en entreprise et en ligne. Nos formateurs sont des experts dans leur domaine et ils sont accrédités par Emploi-Québec et vous remettent un certificat, à la fin de chaque formation, que vous pouvez notamment utiliser pour faire reconnaître des heures de formation continue auprès de votre ordre professionnel.

Découvrez quelles formations vous conviennent

Pour info: 514-605-7112 ou info@lecfomasque.com