Sécuriser les accès et auditer l'activité

En bref

Objectifs : mettre en place une sécurité au niveau des lignes (RLS) statique puis dynamique ; tester et déployer les rôles dans le service ; combiner rôles d'espace de travail et RLS ; suivre l'activité avec le journal d'audit et protéger les données avec Microsoft Purview.
Prérequis : page Organiser le service : capacités, espaces de travail et diffusion ; notions de modélisation et de DAX.
Niveau : intermédiaire.
Licence requise : Power BI Pro pour publier ; rôle d'administrateur Fabric pour l'espace de travail de surveillance ; accès au portail Microsoft Purview pour l'audit.

Pourquoi ?

Un directeur régional ne doit voir que les chiffres de sa région, un commercial que ses clients. Créer un rapport par population est ingérable : la sécurité au niveau des lignes filtre un seul modèle sémantique selon l'utilisateur connecté. L'administrateur doit aussi pouvoir répondre, en cas de contrôle ou de fuite, à la question « qui a consulté, exporté ou partagé quoi ? ».

Notions clés

RLS et OLS

La sécurité au niveau des lignes (RLS) filtre les lignes d'une table selon le rôle de l'utilisateur.
La sécurité au niveau des objets (OLS) masque des tables ou des colonnes entières.
Les rôles et leurs filtres DAX sont définis dans Power BI Desktop ; les membres de chaque rôle sont attribués dans le service.
Le filtre se pose sur une table de dimension et se propage aux tables de faits par les relations.

Le détail de la modélisation (RLS avec table de correspondance, plusieurs-à-plusieurs, OLS) se trouve dans la page Sécurité RLS et OLS (partie 3).

RLS statique et RLS dynamique

	RLS statique	RLS dynamique
Principe	Un rôle par périmètre, filtre en dur : `[Région] = "Nord"`	Un seul rôle, filtre sur l'identité : `[Email] = USERPRINCIPALNAME()`
Maintenance	Un rôle à créer pour chaque nouveau périmètre	Une ligne à ajouter dans la table de sécurité
Prérequis	Aucun	Table de correspondance utilisateur et périmètre

USERPRINCIPALNAME() renvoie l'UPN de l'utilisateur (au format prenom.nom@domaine.fr), dans Desktop comme dans le service. USERNAME() renvoie le format DOMAINEutilisateur dans Desktop et l'UPN dans le service : préférez USERPRINCIPALNAME(). La colonne de la table de sécurité doit contenir exactement la valeur renvoyée par la fonction, qui n'est pas toujours l'adresse e-mail.

Rôles d'espace de travail et RLS

La RLS ne s'applique qu'aux utilisateurs qui ont le rôle Lecteur dans l'espace de travail, ou un accès par partage ou par application. Les rôles Administrateur, Membre et Contributeur voient toutes les données. Les droits effectifs combinent donc deux couches :

Population	Rôle d'espace de travail	Rôle RLS
Équipe BI	Membre ou Contributeur	Sans effet
Managers régionaux	Lecteur, ou audience de l'application	Rôle « Région »
Direction	Lecteur	Rôle sans filtre

Appliquez le principe du moindre privilège, attribuez les rôles à des groupes de sécurité Microsoft Entra ID et séparez les environnements de développement, de test et de production.

Auditer l'activité

Journal d'audit Microsoft Purview : toutes les activités Fabric et Power BI (consultation, export, partage, modification, suppression) y sont enregistrées. La recherche se fait dans le portail Microsoft Purview, par date, activité et utilisateur ; elle demande le rôle Journaux d'audit d'Exchange Online.
Espace de travail de surveillance de l'administrateur (préversion) : installé automatiquement à la première ouverture par un administrateur Fabric, il contient le rapport Gouvernance du Catalogue OneLake (inventaire, capacités, domaines, utilisation des fonctionnalités, activités, partage, approbation, couverture des étiquettes de sensibilité). Il est en lecture seule et actualisé une fois par jour.
Métriques d'utilisation d'un rapport : nombre de vues et d'utilisateurs, accessibles à partir du rapport dans le service.

Protéger les données avec Microsoft Purview

Étiquettes de sensibilité (Protection des informations) : elles classent les éléments (Public, Interne, Confidentiel...) et restent appliquées lors des exports pris en charge (Excel, PDF, PowerPoint).
Prévention de la perte de données (DLP) : des stratégies détectent les données sensibles dans les modèles sémantiques et les éléments Fabric et déclenchent des conseils ou des alertes.
Gestion des risques internes : des indicateurs détectent les fuites potentielles à partir des activités Power BI.

Pas à pas

Créer et tester un rôle dans Power BI Desktop

1. Onglet Modélisation > Gérer les rôles > Nouveau, nommez le rôle, choisissez la table et saisissez le filtre DAX.

[Capture : fenêtre Gérer les rôles de Power BI Desktop avec un rôle « Nord » et le filtre [Région] = "Nord" sur la table Région]

2. Modélisation > Afficher en tant que, cochez le rôle (et, pour la RLS dynamique, Autre utilisateur avec une adresse de test), puis vérifiez que les visuels sont filtrés.

[Capture : boîte de dialogue Afficher en tant que rôles, rôle coché et case Autre utilisateur renseignée]

Attribuer les membres et tester dans le service

3. Dans l'espace de travail, menu ... du modèle sémantique > Sécurité, sélectionnez le rôle et ajoutez des utilisateurs ou des groupes.

[Capture : page Sécurité au niveau des lignes d'un modèle sémantique, rôle sélectionné et zone d'ajout des membres]

4. Menu ... du rôle > Tester en tant que rôle, puis Afficher actuellement en tant que pour essayer une autre personne.

[Capture : rapport en mode Tester en tant que rôle, bandeau « Afficher actuellement en tant que » en haut]

Exemple

Rôle dynamique sur une table Sécurité (colonnes Email et Région) reliée à la dimension Région :

[Email] = USERPRINCIPALNAME()

Le filtre réduit la table Sécurité aux lignes de l'utilisateur connecté, puis se propage à Région et aux ventes. Pour que la propagation traverse la relation entre Sécurité et Région, vérifiez son sens de filtrage croisé (page Sécurité RLS et OLS).

Pièges et bonnes pratiques

Dans le service, Tester en tant que rôle utilise votre propre identité : pour une RLS dynamique, choisissez une personne précise avec Afficher actuellement en tant que.
Le test dans le service ne fonctionne pas pour les modèles DirectQuery avec authentification unique ; testez alors avec un vrai compte membre du rôle.
Un utilisateur ajouté comme Contributeur « pour qu'il puisse tout voir » échappe à la RLS : vérifiez la matrice des droits.
Planifiez une revue régulière du journal d'audit pour répondre aux obligations du RGPD.

À retenir

Rôles définis dans Desktop, membres attribués dans le service.
La RLS dynamique repose sur USERPRINCIPALNAME() et une table de sécurité.
La RLS ne filtre que les lecteurs, pas les administrateurs, membres et contributeurs.
L'activité se suit dans le journal d'audit Purview et l'espace de travail de surveillance de l'administrateur.

Pour aller plus loin

Sécurité au niveau des lignes avec Power BI. Source
Aide sur la sécurité au niveau des lignes dans Power BI Desktop. Source
Suivre les activités des utilisateurs dans Microsoft Fabric. Source
Qu'est-ce que l'espace de travail de surveillance de l'administrateur ? Source
Utiliser Microsoft Purview pour protéger Microsoft Fabric. Source
Protection des informations dans Microsoft Fabric. Source

Exercice

Durée : 1 h environ. Fichiers : PBIX d'exercice avec un modèle Ventes et une table Région, fourni par le formateur.

Créez trois rôles statiques « Nord », « Sud » et « Est » avec un filtre sur la colonne [Région], puis testez chacun avec Afficher en tant que.
Ajoutez une table Sécurité (colonnes Email et Région), reliez-la à la table Région et créez un rôle unique « RLS dynamique » avec le filtre [Email] = USERPRINCIPALNAME().
Testez le rôle avec Autre utilisateur en saisissant plusieurs adresses de la table.
Publiez, attribuez les membres dans le service et testez avec Tester en tant que rôle.
Par groupes, remplissez la matrice des droits pour trois profils (administrateur, contributeur, lecteur) : qui peut publier, modifier, partager, exporter.

Résultat attendu : chaque adresse de test ne voit que les ventes de sa région.