01.Le piège que personne ne documente
Vous configurez le row-level security sur votre Lakehouse gold. Vous le testez en tant qu'utilisateur non-admin — les lignes sont bien filtrées. Vous déployez.
Deux semaines plus tard, une autre équipe crée un shortcut depuis son workspace pointant vers vos tables pour construire ses propres rapports. Leurs rapports fonctionnent. Mais quand vous vérifiez ce que leurs utilisateurs voient réellement, vous découvrez quelque chose de gênant : le RLS que vous avez soigneusement configuré ne s'applique pas. Ils voient toutes les lignes.
Ce n'est pas un bug Fabric. C'est la conséquence de confondre trois couches de sécurité distinctes — Power BI RLS, SQL endpoint row-level security et OneLake Security — et de supposer qu'elles se propagent de la même façon à travers les shortcuts.
Une fuite RLS sur un Lakehouse avec shortcuts peut rester invisible pendant des mois. Les requêtes passent, les rapports affichent des données — mais des lignes non autorisées sont exposées. Un audit trimestriel découvrant la faille coûte bien plus qu'une heure de configuration correcte dès le départ.
02.Les 3 couches de sécurité en 90 secondes
Fabric dispose de trois endroits distincts où vous pouvez appliquer du contrôle d'accès au niveau des lignes, et ils ne font pas la même chose :
| Couche | Point d'enforcement | Contourné par |
|---|---|---|
| Power BI RLS | Semantic model (filtres DAX USERNAME()) |
Tout accès hors semantic model — SQL endpoint, Spark, XMLA |
| SQL endpoint RLS | T-SQL CREATE SECURITY POLICY sur le SQL analytics endpoint |
Tout accès au niveau fichier — notebooks Spark, shortcuts via un autre moteur |
| OneLake Security | Couche de stockage OneLake elle-même | Rien dans Fabric — se propage via SQL endpoint, Spark, Direct Lake et shortcuts |
Les shortcuts sont des pointeurs virtuels : quand un consommateur lit un shortcut, la requête s'exécute contre les fichiers de l'item cible sous l'identité du consommateur. Si votre RLS s'applique dépend entièrement de quelle couche vous l'avez configuré.
03.Les 3 patterns que je vois chaque semaine
Power BI RLS uniquement
Le RLS du semantic model ne s'exécute que quand quelqu'un passe par ce modèle. Un utilisateur avec permission ReadData sur le SQL endpoint du Lakehouse — ou sur le shortcut — peut lancer un SELECT * simple et contourner le filtre DAX entièrement. Donner à un workspace consommateur un shortcut vers votre Lakehouse accorde implicitement des chemins d'accès qui ne passent pas par votre semantic model.
SQL endpoint security policy uniquement
Les security policies T-SQL s'exécutent dans le moteur SQL. Un notebook Spark qui lit les fichiers Delta sous-jacents — directement dans le workspace source ou via un shortcut — contourne complètement le moteur SQL et voit toutes les lignes. Les shortcuts ne copient pas la SQL security policy ; ils pointent vers les fichiers.
OneLake Security
OneLake Security s'enforce au niveau de la couche de stockage — en dessous de tous les moteurs de calcul de Fabric. La policy voyage avec la table quel que soit le moteur qui l'interroge ou si l'accès est direct ou via un shortcut, car la vérification se fait avant que tout moteur voit les lignes. C'est le seul pattern que je recommande en production quand des shortcuts sont en jeu.
04.Le pattern qui tient — étape par étape
1. Activer OneLake Security sur le workspace
OneLake Security doit être activé au niveau admin tenant/workspace avant de pouvoir définir des policies. Vérifiez dans les paramètres du workspace → volet OneLake security que la fonctionnalité est activée.
2. Définir la row-filter policy sur la table sensible
Policy name: rls_customer_region
Type: Row filter
Expression: region = GET_USER_ATTRIBUTE('department')
Applies to: role:"Regional Analysts"La fonction GET_USER_ATTRIBUTE() lit les attributs Entra ID de l'utilisateur — vous ne codez pas les utilisateurs en dur, vous pilotez le filtre depuis l'annuaire.
3. Accorder l'accès ReadData (pas ReadAll)
Role: "Regional Analysts"
Members: Entra group "fabric-regional-analysts"
Permission: ReadData ← CRUCIAL (pas ReadAll)ReadAll contourne les row filters OneLake Security — c'est une permission niveau admin. La grande majorité des consommateurs ne devrait avoir que ReadData. C'est l'erreur de configuration la plus fréquente.
4. Laisser les consommateurs créer des shortcuts
Quand un workspace consommateur crée un shortcut vers cette table, la OneLake Security policy voyage avec lui. Aucune configuration supplémentaire n'est nécessaire côté consommateur, à condition que ses utilisateurs soient dans le rôle Regional Analysts sur le Lakehouse source.
05.Comment vérifier que votre RLS ne fuit pas
Voici la checklist que j'exécute à chaque configuration RLS. Hypothèse : utilisateur test alice@contoso.com, attribut department = EMEA, table customer avec des lignes où region IN ('EMEA', 'APAC', 'AMER').
Test 1 — SQL endpoint sur le Lakehouse source
SELECT DISTINCT region FROM customer;
-- Attendu : uniquement 'EMEA'. Autre résultat = enforcement SQL raté.Test 2 — Notebook Spark sur le Lakehouse source
spark.read.table("customer").select("region").distinct().show()
# Attendu : uniquement 'EMEA'. Autre résultat = enforcement Spark raté.Test 3 — Shortcut dans un workspace consommateur, lu via Spark
spark.read.table("customer_shortcut").select("region").distinct().show()
# Attendu : uniquement 'EMEA'. Autre résultat = propagation shortcut ratée.Test 4 — Shortcut via SQL analytics endpoint
SELECT DISTINCT region FROM customer_shortcut;
-- Attendu : uniquement 'EMEA'.Test 5 — Rapport Power BI Direct Lake via le shortcut
Publiez un visuel table simple avec region comme colonne. Connectez-vous en tant qu'Alice. Le visuel doit afficher uniquement EMEA.
Si les 5 tests passent sous l'identité d'Alice ET retournent toutes les régions sous une identité admin, votre policy est correctement enforced au niveau OneLake et se propage à travers les shortcuts. Vous êtes sécurisé.
06.Les zones grises non documentées par Microsoft
1. Shortcuts cross-tenant
Si un consommateur dans le tenant B crée un shortcut vers une table dans le tenant A, la OneLake Security policy du tenant A référence des attributs Entra du tenant A. Les utilisateurs du tenant B n'ont pas ces attributs. Dans mes tests, le comportement par défaut est deny — mais confirmez pour votre propre setup avant de vous y fier.
2. Shortcuts vers du stockage non-OneLake (ADLS Gen2, S3)
Les OneLake Security policies sont définies sur des tables OneLake. Un shortcut depuis OneLake vers ADLS externe n'hérite pas de OneLake Security — le stockage externe est gouverné par ses propres ACL. Planifiez en conséquence.
3. Interaction avec les workspace roles
Un Contributor sur le workspace source a des permissions implicites équivalentes à ReadAll sur les tables Lakehouse, ce qui contourne les row filters. Si vous voulez que RLS s'applique à un utilisateur, il ne doit pas être Contributor ou supérieur — il doit être Viewer avec ReadData explicite accordé via un rôle.
07.Checklist de migration pour un Lakehouse existant
Si vous rétrofitez du RLS sur un Lakehouse gold qui a déjà des consommateurs et des shortcuts, travaillez dans cet ordre pour éviter de casser quelqu'un :
- Inventorier tous les shortcuts existants pointant vers les tables que vous prévoyez de sécuriser (via l'Admin API ou l'UI workspace)
- Inventorier les role assignments de chaque workspace consommateur sur le Lakehouse source
- Mapper chaque groupe consommateur à l'attribut Entra qui pilotera le row filter (department, region, business unit, etc.)
- Activer OneLake Security sur le workspace
- Définir la row-filter policy sur chaque table sensible, scopée à un rôle de test non-production d'abord
- Ajouter un seul utilisateur test au rôle de test et exécuter les 5 requêtes de vérification ci-dessus
- Quand les 5 passent, élargir le rôle aux vrais groupes Entra consommateurs
- Rétrograder les permissions
ReadAllexistantes versReadDatapour les groupes consommateurs — c'est ce changement qui risque de casser quelque chose, communiquez-le - Relancer les 5 requêtes de vérification avec une vraie identité consommateur
- Documenter la policy dans votre data catalog
