Toutes les données ne doivent pas être visibles par tous les utilisateurs et c’est souvent une exigence lors de la création de rapports. Au lieu de créer différents rapports en fonction de ce que les utilisateurs peuvent et ne peuvent pas voir, comment la sécurité au niveau des lignes peut-elle être utilisée dans Power BI ?
La sécurité est dans l’esprit de tous, car les données provenant de nombreuses sources continuent de croître. Avec autant de données sensibles, je conseille de créer des lignes directrices sur les données qui peuvent et ne peuvent pas être vues par les utilisateurs. La sécurité dans Power BI se présente sous plusieurs formes. Tout d’abord, la licence (pro vs premium) est requise pour accéder au service Power BI dans le cloud (ou pour les ressources sur site associées dans Power BI Report Server). Ensuite, l’accès doit être accordé aux ensembles de données, aux rapports et, de manière plus appropriée, à l’application hébergeant le tableau de bord, les rapports et les ensembles de données.
La couche d’accès au niveau de l’ensemble de données est centrée sur la sécurité au niveau des lignes, appelée Row Level Security (RLS). Les fonctionnalités de sécurité au niveau de la ligne fonctionnent ligne par ligne en fournissant un moyen de restreindre l’accès aux données basé sur des valeurs spécifiques dans un ensemble de données. C’est un outil puissant qui peut être utilisé en conjonction avec des groupes AD, des adresses e-mail et des ID utilisateur de manière à créer un accès limité via un filtre basé sur les rôles.
Dans cet article, je vais décrire les différentes manières de configurer le niveau de sécurité en ligne :
- En définissant des rôles fixes
- En se basant sur une table d’une base de données pour définir des rôles dynamiques
Pour illustrer mes propos, j’ai utilisé la base de données WideWorldImportersDW (version 2016) dans le modèle de données Power BI.
Partie 1 : Configuration du Row Level Security
Pour mettre en place la configuration du RLS, j’ai commencé, tout d’abord, par créer un rapport Power BI contenant un graphique et un tableau.
Le processus de configuration de la sécurité RLS doit se faire en deux étapes pour que cela fonctionne correctement :
- Dans PowerBI Desktop
- Dans PowerBI Service
Configuration des rôles dans Power BI Desktop
La 1ère étape nécessite d’utiliser des rôles. Et de définir les données spécifiques auxquelles chaque rôle aura accès. La configuration se fait à partir de l’option « Manage roles » dans l’onglet « Modeling ».
Dans mon exemple, je crée le rôle « California ». Je sélectionne ensuite la table Dimension City qui sera utilisée pour limiter le niveau d’accès aux données ([State Province] = « California »).
Avant de publier le rapport, il est possible de tester le rôle pour s’assurer qu’il fonctionne correctement. Pour cela, je clique sur le bouton « View as Roles » puis je sélectionne « California ». Si tout se passe bien, je verrai apparaître que les données de California uniquement.
Configurer la sécurité sur Power BI Service
Maintenant que l’ensemble des données et le rapport sont publiés, je peux accéder à mon espace de travail « MyReport ». Je clique droit puis je sélectionne « Security ».
Désormais, les utilisateurs, les listes de distribution ou des groupes Active Directory peuvent être ajoutés en tant que membres de rôles. C’est dans ce processus que je peux attribuer des utilisateurs ou des groupes aux rôles. Il est plus avantageux que les membres ajoutés soient des groupes directs actifs. Car ajouter des individus peut définir un fardeau administratif si le nombre d’utilisateurs devient de plus en plus important.
Pour ajouter un groupe ou utilisateur, l’étape consiste à cliquer sur le bouton « Add » puis d’enregistrer.
Enfin, la dernière étape du processus consiste à vérifier que le rôle fonctionne. Pour cela, je clique sur le bouton à droite du rôle et je sélectionne « Test as role ».
Voici le résultat :
Remarques :
- Si un utilisateur qui a accès au rapport, mais n’est pas affecté en tant que membre d’un rôle, ne verra aucune donnée
- Si un utilisateur dispose d’une autorisation de modification pour le rapport et l’ensemble des données (ex un administrateur), il verra toutes les données et pourra modifier sa propre appartenance à un rôle
Partie 2 : Configuration du RLS basé sur un tableau
Dans la partie 1, j’ai décrit la configuration de la sécurité au niveau des lignes en fonction des rôles qui ont été créés pour une catégorie de données dont j’ai limité l’accès.
Dans cette deuxième partie, je bascule la sécurité au niveau de la ligne pour utiliser dynamiquement l’utilisateur qui est connecté au service Power BI et le comparer à une valeur dans une table. L’utilisateur est référencé dans une table de la base de données pour déterminer à quelles données, il aura accès. En outre, la méthode fixe nécessite que chaque rôle soit prédéfini dans le fichier Power BI (ou que les modifications doivent être apportées après coup). Tandis que les méthodes basées sur une table ne nécessitent que des mises à jour ou des insertions dans une table pour effectuer une modification.
Cette nouvelle méthode consiste à identifier l’utilisateur qui interagit avec le rapport. Dans Power BI, deux fonctions DAX fournissent des informations utilisateur :
- USERNAME()
- USERPRINCIPALNAME ()
USERNAME () fournit le nom de domaine et le nom d’utilisateur de l’utilisateur qui s’est connecté à Power BI dans Power BI Desktop. Ces informations sont renvoyées au format Domaine/Nom d’utilisateur.
USERPRINCIPALNAME () fournit également l’information de l’utilisateur dans Power BI Desktop au format Domaine/Nom d’utilisateur. Cependant, les deux fonctions fournissent l’adresse e-mail de connexion de l’utilisateur qui se connecte aux services Power BI.
Pour voir les valeurs réelles renvoyées par ces deux fonctions, je créé 2 nouvelles colonnes dans la table de fait :
Le premier champ « UserName » utilise la fonction USERNAME ().
Le deuxième champ « UserPrincipalName » utilise la fonction DAX USERPRINCIPALNAME ().
Voici un aperçu du résultat des 2 nouvelles colonnes dans Power BI Desktop. Les 2 fonctions renvoient le domaine et le nom d’utilisateur.
Sur Power BI Service, c’est l’adresse email qui s’affiche.
Je crée ensuite le back-end de la base de données qui assurera la sécurité au niveau des lignes. Le tableau doit au minimum contenir deux éléments :
- Le nom d’utilisateur
- La valeur de la catégorie associée qui différenciera l’accès.
Le nom d’utilisateur doit correspondre au nom d’utilisateur qui est résolu sur le service Power BI. Il doit refléter le format de courrier électronique. Le champ de catégorie est l’élément qui différencie l’accès d’un utilisateur. Cela peut être des choses comme des succursales ou une région de vente ou peut-être un département. La valeur peut être du texte ou un entier d’identité. Cela dépendra des données de la table de faits utilisée.
Dans l’exemple ci-dessous, je crée une table contenant la liste des utilisateurs autorisés. Cette table comprend les champs suivants :
- User_Key correspondant à l’identité de l’utilisateur
- User_Name_ID correspondant au nom d’utilisateur de messagerie appelé
- State_Province contenant le nom de l’état qui pourra être affiché pour l’utilisateur concerné
Une fois la table créée, elle doit maintenant être remplie avec les utilisateurs appropriés qui ont besoin d’un accès.
Notez qu’une ligne est requise pour chaque point de données d’accès. Ainsi, si un utilisateur a besoin d’accéder à 3 états, une ligne pour chaque combinaison de {State_Province / User} doit être insérée.
À ce stade, je dois revenir sur Power BI Desktop. La table d’autorisations « User_StateProvince » nouvellement créée doit être ajoutée au modèle.
Enfin, la relation entre la table de faits ou la dimension City et la table d’autorisations « User_StateProvince » doit être définie. Comme illustrée ci-dessous, la jointure est créée entre le champ State_Province dans la table City de dimension et le champ Province dans la table User_StateProvince.
Création des relations entre les tables
Je crée également un rôle nommé « UserRole » qui vérifie le User_Name_ID dans la table Dimension User_StateProvince et le compare avec un appel à la fonction DAX UserName().
Power BI Desktop se résout en domaine/nom d’utilisateur tandis que Power BI service renvoie l’adresse email connecté au portail. Par conséquent, pour terminer le processus d’installation, le fichier Power BI doit être publié sur le service Power BI.
Après la publication, il reste une étape supplémentaire pour terminer le processus de sécurité au niveau des lignes. Pour cela, je sélectionne « Security » à partir de mon espace de travail (comme montré dans la partie 1). Puis je teste en tant que rôle « UserRole ».
Dans la base de données, mon ID utilisateur était associé à l’état « California ». Comme le montre la copie d’écran ci-dessous, le rapport du tableau de bord ne montre que les données de cet état.
Le deuxième onglet du tableau de bord affiche également uniquement les ventes de l’état California.
L’utilisation de la sécurité au niveau des lignes basée sur une table ajoute une flexibilité supplémentaire à l’infrastructure de sécurité d’un tableau de bord Power BI. Je conseille cette méthode, car elle permet une méthode plus évolutive de limitation de la vue des utilisateurs sur les données sensibles et peut être intégrée à d’autres processus de sécurité.