Pourquoi réaliser un mask dynamique de données dans Power BI est une mauvaise idée

Une des questions techniques que l'on m'a posé la semaine passée était : "Comment faire pour afficher une valeur en clair ou avec un mask, en fonction des permissions de l'utilisateur ?"

L'idée est alors d'afficher pour un numéro de téléphone, "+336123456789" pour le userA, et "+33XXXXXXX789" pour le userB. Pour y répondre, il y a alors plusieurs solutions :

1. Le réaliser directement dans le modèle sémantique (tabular ou Power BI) :

• Le réaliser via une mesure nécessairement, qui évaluera selon le contexte de l'utilisateur la valeur à afficher : une des options serait d'utiliser le code ci-dessous : (FIRSTNONBLANK permet d'éviter un Callback présent avec MIN ou MAX).

• On remarque via l'utilisation de DAX Studio et de l'analyseur de performance que la requête est perturbée par l'évaluation de la mesure, le temps de calcul pour ce simple tableau est démultiplié (par ~5 pour le DAX) :

• Il n'est pas possible d'utiliser une colonne calculée, car elle est évaluée au moment du process du modèle (ou rafraîchissement du dataset), et donc elle n'est plus dynamique. De ce fait, ce n'est pas supporté.

2. Une autre solution serait de le réaliser au sein de la source de données en se basant sur le Dynamic Data Masking de SQL Server : Masquage dynamique des données - SQL Server | Microsoft Docs. Cette solution implique deux choses :

• Que le Dynamic Data Masking soit implémenté directement sur la source de données, et donc, pour qu'elle dépende de l'identité d'un utilisateur, il faut que l'utilisateur requête en direct les données sur la base : synonyme donc de DirectQuery et donc contraire à un modèle performant. (Se référer à Using and optimizing DirectQuery in #powerbi and #ssas #tabular - SQLBI).
• Que l'authentification au jeu de données se fasse via Single Sign On, et donc via une Gateway On-Premise, pour donner accès directement à la base de données. Vue d’ensemble de l’authentification unique (SSO) pour les passerelles de données locales - Power BI | Microsoft Docs

"Quand vous configurez l’authentification unique pour la source de données, les requêtes s’exécutent sous l’identité de l’utilisateur qui interagit avec Power BI via l’expérience web ou des applications mobiles Power BI. Par conséquent, chaque utilisateur voit précisément dans la source de données sous-jacente les données pour lesquelles il dispose d’autorisations."

Ces deux possibilités sont alors une mauvaise idée d'un point de vue performance, et représentent une grande compléxité.

La meilleure solution à ce problème réside dans l'utilisation de l'Object Level Security dans Power BI ou au sein du modèle tabulaire : De fait, si l'utilisateur ne doit pas voir le contenu des numéros de téléphone, alors le fait de lui afficher une information avec un mask n'a aucune valeur ajoutée : il n'est pas nécessaire de l'afficher dans le rapport. Pour y arriver, Visual Studio ou Tabular Editor nous aideront, comme pour la Row Level Security, qui vise à réduire les lignes affichées au périmètre de l'utilisateur.

Via Tabular Editor :

Via Visual Studio :

NB : Cette solution implique que les modèles tabulaires ou Power BI soient développés avec une version supérieure à 1400. Analysis Services modèle tabulaire-sécurité au niveau de l’objet | Microsoft Docs