Mise en œuvre de la sécurité au niveau des lignes dynamique dans Power BI et Microsoft Fabric : architecture, modèles DAX et gouvernance de niveau entreprise

By Mirko Peters · 2025-11-21 · Updated 2025-11-26

Mettez en œuvre la sécurité au niveau des lignes dynamique dans Power BI et Microsoft Fabric pour contrôler l’accès des utilisateurs aux données, garantir la conformité et s’adapter aux évolutions de l’organisation.

Automatically translated with AI from the original post. Read the English original

Il convient de considérer la sécurité au niveau des lignes dynamique comme un système évolutif. Elle grandit et évolue avec votre organisation. La conception du modèle de données, les expressions DAX, l’identité des utilisateurs et la gouvernance contribuent tous à déterminer le fonctionnement de la sécurité dans Power BI et Microsoft Fabric. Correctement configurée, elle vous permet de décider qui peut accéder à certaines données.

Points clés

• La sécurité au niveau des lignes dynamique s’adapte aux besoins de votre entreprise. Elle vous permet de choisir qui peut accéder à certaines données, en vérifiant l’identité de chaque utilisateur.

• Utilisez USERPRINCIPALNAME() pour la sécurité dans le cloud. Cette fonction permet aux utilisateurs de ne voir que leurs propres données et contribue à protéger vos informations.

• Vérifiez régulièrement votre configuration de sécurité et vos groupes d’utilisateurs. Cela empêche les personnes d’accéder à des données qui ne leur sont pas destinées et contribue à protéger vos données.

• Créez des tables de sécurité claires pour gérer les autorisations des utilisateurs. Cela vous aide à contrôler qui peut voir quoi à mesure que votre entreprise se développe.

• Testez vos règles de sécurité dans le cloud avec de vrais utilisateurs. Vous vous assurez ainsi que vos données sont protégées et que les utilisateurs ne voient que ce à quoi ils ont droit.

Repenser les systèmes de sécurité au niveau des lignes

La sécurité comme système piloté par le modèle

La sécurité au niveau des lignes est un système qui relie les différents éléments de votre plateforme analytique. Dès la conception de votre modèle de données, vous commencez à bâtir la sécurité des données. La manière dont vous structurez les tables, les reliez et définissez les rôles influe directement sur ce que chaque utilisateur voit. Lorsque votre entreprise se développe ou que de nouvelles équipes arrivent, vous devez mettre à jour vos règles de sécurité. La sécurité au niveau des lignes ne se configure pas une fois pour toutes et s’oublie. Elle évolue avec votre activité et répond à de nouveaux besoins.

Conseil : vérifiez régulièrement votre modèle de données. Un bon modèle simplifie la sécurité et vous aide à éviter les erreurs.

Votre modèle doit comporter des relations claires et des tables de sécurité dédiées. Vous pouvez ainsi contrôler qui voit certaines données et protéger les informations confidentielles. La sécurité dynamique au niveau des lignes peut faire correspondre ce que voient les utilisateurs à leur groupe ou à leur fonction dans Fabric. Vous pouvez alors modifier rapidement les autorisations lorsque votre organisation évolue.

Sécurité au niveau des lignes statique et dynamique

Il existe deux grandes approches pour configurer la sécurité des données : la sécurité au niveau des lignes statique et dynamique. La sécurité statique repose sur des règles figées : vous créez des rôles et des filtres pour chaque groupe. Elle convient aux petites équipes ou lorsque les accès évoluent peu. La sécurité dynamique s’appuie sur l’utilisateur connecté et sur des tables de correspondance. Elle identifie l’utilisateur et adapte immédiatement les données affichées. Elle est préférable pour les grandes entreprises comptant de nombreux utilisateurs et des règles évolutives.

Voici un tableau présentant les différences :

La sécurité dynamique au niveau des lignes offre davantage de moyens de contrôler les accès. Elle s’appuie sur USERPRINCIPALNAME() et des tables de correspondance pour associer chaque utilisateur aux bonnes données. La sécurité statique est simple à mettre en place, mais elle s’adapte mal aux organisations en croissance ou en forte évolution.

• La sécurité statique au niveau des lignes limite les données à l’aide de règles figées.

• La sécurité dynamique au niveau des lignes adapte les données affichées à l’identité de chaque utilisateur.

• La sécurité dynamique convient le mieux aux grandes entreprises disposant de nombreuses règles.

Pour protéger vos données, choisissez l’approche la mieux adaptée à vos besoins. Une bonne planification et un modèle solide vous aident à protéger les informations confidentielles et à sécuriser vos analyses.

Modèles de sécurité dynamique au niveau des lignes dans Fabric

Fonctions DAX : USERPRINCIPALNAME() ou USERNAME()

Il est essentiel de comprendre le fonctionnement de l’identité dans Fabric. Deux fonctions principales servent à configurer la sécurité au niveau des lignes : USERPRINCIPALNAME() et USERNAME(). Toutes deux identifient la personne qui consulte le rapport. USERPRINCIPALNAME() renvoie l’adresse e-mail de l’utilisateur dans le cloud, tandis que USERNAME() renvoie souvent un nom de compte local, principalement dans Power BI Desktop. Si vous utilisez USERNAME() dans le cloud, le filtrage peut ne pas fonctionner correctement, ce qui peut fragiliser la protection de vos données.

Astuce : utilisez toujours USERPRINCIPALNAME() pour la sécurité au niveau des lignes dynamique dans Fabric. Cette fonction correspond à l’adresse e-mail cloud de l’utilisateur et protège vos données.

Si vous utilisez la mauvaise fonction, des utilisateurs pourraient voir des données qu’ils ne devraient pas voir. Vous devez tester votre sécurité dans le cloud, et pas seulement dans Desktop.

Modèles DAX sécurisés et anti-modèles

Vous voulez que vos données restent protégées. Il vous faut des modèles DAX robustes pour la sécurité au niveau des lignes dynamique. La meilleure approche consiste à utiliser des tables de mappage et des règles dynamiques. Vous contrôlez ainsi qui peut voir quoi.

• Les filtres de lignes permettent de limiter ce que les utilisateurs peuvent voir. Vous pouvez bloquer des données par région, par service ou par compte.

• Les masques de colonnes vous permettent de masquer ou de modifier des données selon l’utilisateur concerné.

Un bon modèle DAX utilise une recherche pour associer chaque utilisateur à son groupe. Cette approche fonctionne bien pour les entreprises comptant de nombreux groupes. Voici un bon exemple :

Organizations[Id] = LOOKUPVALUE(
    AspNetUsers[OrganizationId],
    AspNetUsers[Email],
    USERPRINCIPALNAME()
)

Ce modèle vérifie l’adresse e-mail de l’utilisateur et retrouve son groupe. Vous pouvez l’utiliser pour n’afficher que les données appropriées. Cette méthode est préférable à une simple correspondance des adresses e-mail. Elle reste efficace à mesure que l’entreprise se développe et protège vos données.

Remarque : ne codez pas en dur les adresses e-mail et n’utilisez pas de colonnes calculées pour gérer les accès. Ces approches peuvent cesser de fonctionner si les utilisateurs changent ou si l’entreprise grandit.

Certains mauvais modèles peuvent provoquer des fuites de données :

• Utiliser USERNAME() dans le cloud.

• Coder en dur les adresses e-mail ou les domaines des utilisateurs.

• Placer la logique de sécurité dans des colonnes calculées.

Utilisez toujours des règles dynamiques et des tables de mappage. Votre modèle de données reste ainsi simple et vos données protégées.

Hiérarchies et fonction PATH()

Il arrive que vous deviez sécuriser l’accès pour des managers, des équipes ou des services. Les hiérarchies vous y aident. La fonction PATH() de DAX permet de créer des liens parent-enfant. Vous pouvez l’utiliser pour contrôler qui voit quoi à chaque niveau.

Par exemple, vous pouvez créer une table avec les identifiants des employés et de leurs managers. PATH() construit une chaîne reliant chaque collaborateur à son responsable. Vous pouvez ensuite utiliser DAX pour filtrer les données à chaque niveau.

PATH(Employee[EmployeeID], Employee[ManagerID])

Cette fonction vous aide à mettre en place une sécurité au niveau des lignes dynamique pour les grandes entreprises. Vous pouvez permettre aux managers de voir les données de leur équipe, tout en empêchant les collaborateurs ordinaires d’accéder à des informations excessives.

Astuce : utilisez PATH() pour sécuriser les hiérarchies. Votre modèle de données gagne en souplesse et vos données restent protégées.

Vous pouvez combiner filtres de lignes, masques de colonnes et fonctions de hiérarchie. Cela vous permet de protéger les données confidentielles et de contrôler les accès à mesure que l’entreprise grandit.

Architecture des rôles et des relations

Conception de la table de sécurité

Vous devez créer des tables de sécurité pour la sécurité au niveau des lignes dynamique. Ces tables indiquent quels utilisateurs peuvent voir quelles données. Utilisez des colonnes pour l’adresse e-mail, le groupe et le niveau d’accès. Cette structure vous aide à protéger vos données à mesure que l’entreprise grandit.
Lorsque vous créez des rôles, séparez les rôles stricts des rôles ouverts. Si un rôle permet à quelqu’un de tout voir, les autres rôles assortis d’une sécurité au niveau des lignes risquent de ne pas fonctionner correctement. Il faut empêcher les rôles de entrer en conflit pour protéger vos données.

• Créez des tables de sécurité aux colonnes claires pour l’utilisateur et les autorisations.

• Séparez les rôles afin qu’ils ne se chevauchent pas et ne provoquent pas de problèmes.

• Vérifiez régulièrement vos tables de sécurité pour suivre les changements.

Relations du modèle de données

La manière dont vous construisez votre modèle de données influence votre contrôle des accès. Utilisez des liaisons à sens unique entre les tables. Votre modèle reste ainsi simple et vous évitez les erreurs.
Il est préférable d’utiliser des tables de sécurité dédiées plutôt que d’y placer les autorisations dans les tables de faits. Vous pouvez relier votre table de sécurité à d’autres tables, comme celles des services ou des régions. Vous pouvez ainsi filtrer les données pour chaque utilisateur ou groupe.

Astuce : utilisez des tables de pont pour relier les utilisateurs aux données. Cela permet à la sécurité au niveau des lignes dynamique de fonctionner et protège vos données.

Granularité des rôles : petits rôles ou grands rôles

Vous devez choisir le niveau de détail de vos rôles. Des rôles restreints vous donnent davantage de contrôle. Vous pouvez attribuer l’accès par fonction ou par groupe. Des rôles étendus couvrent davantage de personnes, mais peuvent présenter des risques si les besoins évoluent.
Vérifiez régulièrement qui détient chaque rôle. Cela protège vos données et vous permet d’apporter des modifications si nécessaire.
Privilégiez des rôles restreints pour un contrôle accru et des mises à jour simples. Des rôles étendus peuvent convenir à des groupes simples, mais ils peuvent poser problème dans les grandes entreprises.

Attributions d’utilisateurs et de groupes dans Fabric

Groupes Azure AD ou utilisateurs individuels

Vous accordez l’accès dans Fabric en ajoutant des utilisateurs à des groupes Azure AD. Vous pouvez ainsi contrôler les données de nombreuses personnes à la fois. Il est plus sûr d’utiliser des groupes que d’ajouter chaque personne individuellement. Les groupes simplifient la gestion de votre système. Lorsque votre équipe évolue, vous pouvez mettre à jour les groupes rapidement. Associer des groupes à des rôles facilite la modélisation des données. Vos règles de sécurité au niveau des lignes restent claires et simples.

Astuce : utilisez des groupes Azure AD pour contrôler l’accès. Vous réduisez ainsi le risque d’erreurs et gagnez du temps.

Chevauchement de groupes et accès fantômes

Méfiez-vous des chevauchements de groupes. Il arrive qu’un utilisateur appartienne à plusieurs groupes. Cela peut lui permettre de voir des données auxquelles il ne devrait pas avoir accès. L’accès fantôme se produit lorsque cette erreur permet aux utilisateurs de voir des données supplémentaires. Vérifiez fréquemment la liste des groupes pour éviter ce problème. Utilisez des tableaux pour suivre les utilisateurs présents dans chaque groupe. Une bonne modélisation des données vous aide à détecter les problèmes au plus tôt. Retirez les utilisateurs des groupes dont ils n’ont plus besoin afin de protéger vos données.

Remarque : l’accès fantôme peut exposer des données privées. Corrigez les chevauchements de groupes pour préserver la sécurité de votre système.

Revues d’accès planifiées

Planifiez des revues d’accès régulières. Vérifiez périodiquement qui appartient à chaque groupe. Demandez aux propriétaires de groupes de confirmer qui doit avoir accès. Cela garantit le bon fonctionnement de votre sécurité dynamique au niveau des lignes à mesure que votre entreprise se développe. Utilisez les outils de Fabric pour faciliter ces contrôles. Supprimez les anciens utilisateurs afin de renforcer la sécurité de vos données. Cela maintient votre système d’analyse propre et sécurisé. Faites des revues d’accès une pratique courante de votre travail en informatique décisionnelle.

• Fixez des dates pour revoir l’ensemble des groupes.

• Utilisez les outils de Fabric pour vérifier les groupes.

• Demandez aux propriétaires de confirmer les membres de chaque groupe.

Alerte : les revues régulières vous permettent de détecter les erreurs avant qu’elles ne causent des problèmes.

Résolution d’identité : Desktop et Fabric

Fonctions d’identité et différences dans le cloud

Il est important de comprendre le fonctionnement de l’identité dans Power BI Desktop et Microsoft Fabric. Dans Power BI Desktop, USERNAME() affiche généralement le nom de votre ordinateur. Dans Microsoft Fabric, USERPRINCIPALNAME() renvoie votre adresse e-mail cloud. Cette différence est essentielle pour protéger vos données. Si vous utilisez USERNAME() dans le cloud, des personnes non autorisées pourraient accéder aux données. Utilisez toujours USERPRINCIPALNAME() pour les rapports cloud. Cela contribue à protéger vos données et à respecter le système d’identité de votre entreprise.

Astuce : testez vos règles de sécurité au niveau des lignes dans le cloud. Les tests sur Desktop ne reflètent pas les accès réels des utilisateurs.

Propriétaire du jeu de données et paramètres du locataire

Vous devez savoir qui est propriétaire de votre jeu de données. Le propriétaire peut modifier les paramètres d’actualisation et influer sur les personnes qui voient les données. Si vous changez de propriétaire, vous pouvez modifier qui peut accéder aux données privées. Les paramètres du locataire sont également importants. Ils déterminent le fonctionnement des identités dans votre entreprise. Vérifiez les paramètres du locataire avant de publier vos rapports. Assurez-vous que votre modèle de données respecte les règles de sécurité de votre entreprise.

Causes courantes de fuites RLS

Vous pouvez perdre le contrôle de la sécurité au niveau des lignes si vous ne testez pas dans le cloud. Il arrive que des utilisateurs voient plus de données qu’ils ne le devraient. Cela peut se produire si vous utilisez la mauvaise fonction d’identité ou si vous oubliez de mettre à jour l’appartenance aux groupes. Des fuites peuvent aussi survenir si vous modifiez votre modèle de données sans vérifier les tables de sécurité. Examinez toujours la configuration de sécurité de vos données après chaque modification. Utilisez des tests dans le cloud et des audits réguliers pour détecter les problèmes au plus tôt.

Alerte : les fuites de données peuvent exposer des informations privées. Examinez votre configuration régulièrement pour protéger votre organisation.

Tests, audit et gouvernance

Test de la sécurité au niveau des lignes dans le cloud

Vous devez tester la sécurité au niveau des lignes dans le cloud. Cela garantit que vos données sont protégées pour les utilisateurs réels. L’outil « Afficher en tant que » de Desktop ne fournit qu’un aperçu. Il ne montre pas le fonctionnement réel des règles dans Microsoft Fabric. Une fois votre rapport publié, testez-le avec de vrais utilisateurs et groupes. Vous pourrez ainsi voir ce que chaque personne est en mesure de consulter. Utilisez des comptes de test pour vérifier que les utilisateurs ne voient que leurs propres données. Testez de nouveau systématiquement après toute modification des rôles ou de votre modèle. Les tests dans le cloud vous aident à détecter les problèmes avant qu’ils ne nuisent à votre activité.

Conseil : testez toujours avec de vrais utilisateurs dans le cloud, et pas seulement dans Desktop. Vous renforcez ainsi la sécurité de vos données.

Automatisation pour les audits et les revues

Vous pouvez recourir à l’automatisation pour faciliter les audits et les revues dans Fabric. L’automatisation vérifie périodiquement les autorisations des espaces de travail, les flux de données et les étiquettes de confidentialité. Microsoft Purview vous fournit des tableaux de bord pour suivre les règles appliquées à l’ensemble de votre plateforme. Vous pouvez utiliser les journaux d’activité et les API d’administration pour détecter les problèmes de conformité. L’automatisation permet de repérer les problèmes tôt et fait gagner du temps. Les auditeurs peuvent suivre le parcours complet des colonnes sensibles, depuis la source jusqu’au rapport. Les revues sont ainsi plus rapides et plus fiables. L’automatisation permet aussi de respecter plus facilement et à moindre coût des réglementations comme le RGPD et HIPAA.

• Mettez en place des contrôles automatiques des autorisations et des flux de données.

• Utilisez des tableaux de bord pour surveiller les modifications des règles de sécurité.

• Consultez les journaux d’activité pour identifier rapidement les problèmes.

Documentation et gestion des changements

Des enregistrements rigoureux sont indispensables pour garder votre dispositif de sécurité des données lisible. Consignez vos règles de sécurité, vos listes de groupes et les modifications apportées aux rôles. Mettez à jour votre documentation lorsque vous modifiez le modèle ou ajoutez de nouveaux utilisateurs. Des enregistrements clairs vous permettent de savoir qui a accès à quelles données. Ils facilitent également la prise en main du système par les nouveaux membres de l’équipe. La gestion des changements consiste à vérifier et à approuver les mises à jour avant leur mise en production. Cette démarche garantit la sécurité de la sécurité au niveau des lignes à mesure que votre entreprise se développe.

Attention : tenez vos enregistrements à jour. Vous protégez ainsi vos données et corrigez les problèmes plus rapidement.

Considérez la sécurité au niveau des lignes comme un dispositif appelé à évoluer avec vos données et votre entreprise. Une configuration solide contribue à protéger les informations confidentielles. Des modèles DAX bien conçus et une gestion rigoureuse des identités des utilisateurs renforcent cette protection. Vérifier régulièrement votre sécurité et consigner les modifications vous aide à repérer les problèmes au plus tôt. En anticipant, vous gardez le contrôle sur qui accède aux données et préservez la sécurité de vos analyses.

• Vérifiez régulièrement votre configuration de sécurité.

• Adaptez les règles en fonction de l’évolution pour mieux protéger les données.

• Placez toujours la confidentialité au premier plan.

Questions fréquentes

Qu’est-ce que la sécurité dynamique au niveau des lignes dans Power BI et Fabric ?

La sécurité dynamique au niveau des lignes vous permet de contrôler l’accès aux données en fonction de l’utilisateur qui consulte le rapport. Vous utilisez des fonctions DAX et des tables de mappage pour associer les utilisateurs aux données qui leur correspondent.

Pourquoi utiliser USERPRINCIPALNAME() plutôt que USERNAME() ?

USERPRINCIPALNAME() renvoie l’adresse e-mail cloud de l’utilisateur. Cette fonction fonctionne au mieux dans Power BI et Fabric. USERNAME() peut afficher un nom local, ce qui peut provoquer des problèmes de sécurité dans le cloud.

En quoi les groupes Azure AD contribuent-ils à la sécurité ?

Les groupes Azure AD vous permettent de gérer l’accès de nombreux utilisateurs à la fois. Vous ajoutez les utilisateurs à des groupes et leur attribuez des rôles. Votre dispositif de sécurité gagne ainsi en simplicité et en fiabilité.

Qu’est-ce qu’une table de sécurité, et pourquoi en avez-vous besoin ?

Une table de sécurité répertorie les utilisateurs, les groupes et leurs autorisations. Vous l’utilisez pour contrôler qui peut voir certaines données. Elle vous aide à protéger vos données à mesure que votre entreprise se développe.

À quelle fréquence faut-il tester la sécurité au niveau des lignes dans le cloud ?

Vous devez tester la sécurité au niveau des lignes à chaque modification des rôles, des groupes ou de votre modèle de données. Les tests dans le cloud montrent ce que voient réellement les utilisateurs et permettent de détecter les problèmes au plus tôt.