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

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

À 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

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.

Voici quelques commentaires d’apprenants ayant suivi cette formation :

La mission du CFO masqué est de développer les compétences techniques des analystes et des contrôleurs de gestion en informatique décisionnelle avec Excel et Power BI et favoriser l’atteinte de leur plein potentiel, en stimulant leur autonomie, leur curiosité, leur raisonnement logique, leur esprit critique et leur créativité.