Sécurité au niveau des lignes : trois façons de la croire en place alors qu'elle ne l'est pas

Un directeur régional ouvre son rapport, voit sa région, et tout paraît en ordre. Trois mois plus tard, quelqu'un exporte une table de détail et découvre les chiffres d'une autre région.

La sécurité par ligne était en place. Elle ne couvrait pas ce chemin-là.

Le principe, en une phrase

Un rôle porte un filtre DAX sur une table. Quand un utilisateur affecté à ce rôle ouvre le rapport, le filtre s'applique avant tout calcul, et il se propage aux autres tables par les relations du modèle.

Ce dernier point est la source des trois erreurs qui suivent : la sécurité ne protège que ce que les relations lui permettent d'atteindre.

Erreur 1 : le filtre ne se propage pas jusqu'aux faits

Vous posez le rôle sur la table Région, qui est du côté « un » d'une relation vers Ventes. Le filtre descend correctement : chaque directeur voit ses ventes.

Puis quelqu'un ajoute une table Objectifs, reliée à Région elle aussi, mais la relation est créée dans l'autre sens, ou bien elle reste inactive parce qu'un doublon empêchait de la valider.

Le rapport affiche alors les ventes filtrées et les objectifs de tout le monde. Rien ne le signale : les deux visuels sont côte à côte et l'un des deux ment.

Ce qu'on fait : après avoir posé un rôle, on liste toutes les tables de faits du modèle et on vérifie une par une qu'elles sont bien atteintes. Une table de faits qu'aucun chemin de relation ne relie à la table sécurisée n'est pas protégée, et ne le sera jamais par ce rôle.

Erreur 2 : le filtrage bidirectionnel ouvre une porte

Le filtrage croisé bidirectionnel sert à résoudre certains modèles à plusieurs tables de faits. Il crée aussi des chemins que la sécurité n'avait pas prévus.

Le cas typique : Ventes est reliée à Produit en bidirectionnel pour qu'un filtre sur les ventes réduise la liste des produits. Un utilisateur restreint à une région voit alors, dans un segment, la liste des produits vendus dans sa région, ce qui est voulu. Mais si une autre table remonte par Produit vers un axe non sécurisé, le filtre peut ressortir par ce chemin.

Ce qu'on fait : aucune relation bidirectionnelle dans un modèle qui porte de la sécurité par ligne. Là où le besoin est réel, on le traite avec CROSSFILTER dans la seule mesure concernée, ce qui rend l'effet local et explicite.

Erreur 3 : le rôle est juste, la table de correspondance ne l'est pas

Beaucoup de modèles sécurisent par une table qui associe un utilisateur à un périmètre :

[Email] = USERPRINCIPALNAME ()

Le filtre est correct. Ce qui casse, c'est la table.

Un collaborateur change de région : deux lignes coexistent, et il voit les deux périmètres. Une adresse est saisie avec une majuscule différente : sans conséquence, DAX compare sans tenir compte de la casse. Mais un espace en fin de chaîne, lui, casse la correspondance et l'utilisateur ne voit rien. Ce cas-là se remonte vite, parce qu'il gêne. Le premier ne se remonte jamais.

Ce qu'on fait : la table de correspondance est alimentée depuis l'annuaire d'entreprise plutôt que saisie à la main, les adresses sont nettoyées à l'import, et un contrôle vérifie qu'aucun utilisateur n'apparaît deux fois.

Le test qui attrape les trois

Le bouton Afficher en tant que de Power BI Desktop teste un rôle sur les visuels d'une page. C'est utile et insuffisant : il ne teste que ce que la page affiche.

Notre protocole tient en quatre points.

1. Un jeu de comptes de test, un par périmètre, y compris un compte sans aucun périmètre : celui-ci doit voir zéro ligne, pas tout.
2. Une page de contrôle temporaire qui affiche, pour chaque table de faits du modèle, le nombre de lignes visibles. C'est là qu'apparaît la table qu'aucun filtre n'atteint.
3. Un test d'export. Le chemin le plus souvent oublié : Exporter les données depuis un visuel, et l'accès au modèle depuis Excel. Ces deux-là contournent la mise en page, pas la sécurité, à condition que la sécurité soit complète.
4. Un test après chaque ajout de table. Une table ajoutée six mois plus tard n'hérite de rien : elle est ouverte tant que personne ne l'a reliée au périmètre sécurisé.

Le point 3 mérite d'être fait devant le client, une fois. Il transforme une promesse en démonstration.

Ce qu'il faut retenir

La sécurité par ligne ne protège que ce que les relations du modèle lui permettent d'atteindre. Trois choses la mettent en défaut : une table de faits que le filtre n'atteint pas, une relation bidirectionnelle qui ouvre un chemin de traverse, et une table de correspondance qui contient un doublon.

Le test qui les attrape est une page de contrôle listant le nombre de lignes visibles par table, jouée sous un compte de test, dont un compte sans périmètre, qui doit voir zéro.