Le point de départ
Dans Microsoft Fabric, la sécurité OneLake permet de contrôler finement ce qu’un utilisateur voit dans un lakehouse. On s’attend donc à ce qu’un simple Viewer, qui n’appartient à aucun rôle d’accès aux données, ne voie rien. C’est vrai dans l’explorateur du lakehouse. Ce n’est pas vrai partout : le point de terminaison d’analyse SQL a son propre mode d’accès, et celui par défaut ignore les rôles OneLake.
Cet article couvre ce point de terminaison. La façon dont les rôles OneLake se combinent entre eux, et le rôle DefaultReader, font l’objet d’un article séparé.
Règle suivie ici : chaque affirmation est vérifiée en lab avant d’être écrite. Les captures proviennent d’un workspace de test (ws_dp700_sandbox) avec deux comptes : fab.admin (Admin) et Alpha (Viewer). Le point de terminaison SQL est celui du lakehouse lh_dp700_sandbox, chargé avec le jeu de données d’exemple de Fabric.
1. Le modèle en trois lignes
- Les rôles de workspace ouvrent la porte : un Viewer a la permission Read sur les items du workspace, il voit donc le lakehouse.
- Les rôles OneLake (data access roles) décident des données visibles à l’intérieur. OneLake est en deny by default : sans rôle qui l’accorde, aucun accès.
- Chaque chemin d’accès applique ces règles à sa façon : l’explorateur, Spark, Power BI et le point de terminaison d’analyse SQL ne se comportent pas tous pareil.
2. Alpha sans rôle : bloqué dans l’explorateur, autorisé en SQL
Le workspace contient fab.admin (Admin) et Alpha (Viewer). Alpha n’appartient à aucun rôle OneLake.
Le point de terminaison SQL du lakehouse est dans son mode par défaut : ses paramètres (Data access mode) affichent Delegated identity access mode, avec fab.admin comme identité déléguée.
Dans l’explorateur du lakehouse, Alpha voit l’item, mais Tables et Files portent une croix rouge : il n’a pas l’autorisation d’afficher les tables ni les fichiers. Le refus par défaut fonctionne.
Le message propose toutefois de passer au point de terminaison d’analyse SQL. Alpha s’y connecte et lance une requête :
SELECT TOP 10 *
FROM [dbo].[sales]Elle réussit.
Même utilisateur, mêmes données, aucun rôle OneLake : bloqué dans l’explorateur, autorisé en SQL.
3. Pourquoi : le mode delegated identity
D’après la documentation Microsoft, un point de terminaison SQL nouvellement créé démarre en mode delegated identity. Dans ce mode :
- l’endpoint lit OneLake avec l’identité du propriétaire de l’item, pas celle de l’utilisateur ;
- la sécurité ne dépend que des permissions SQL définies dans la base ;
- les rôles OneLake ne sont pas appliqués.
Ce n’est pas un contournement : c’est le mode par défaut, et c’est exactement celui de notre lab.
4. Passer en User’s identity : ce que Fabric supprime
Un Admin ou un Member peut basculer le point de terminaison en User’s identity access mode (Use OneLake security for tables). Fabric prévient de deux conséquences avant d’appliquer :
- toutes les permissions de sécurité SQL actuelles sont supprimées du point de terminaison ;
- l’accès aux données se fait avec l’identité de l’utilisateur.
Une seconde fenêtre confirme que le changement désactive temporairement le point de terminaison SQL pour tout le workspace et annule les requêtes en cours.
Nous appliquons le changement à 14h31. À 14h34, la même requête lancée par Alpha, toujours sans aucun rôle OneLake, est refusée :
Le message d’erreur : The SELECT permission or external policy action … was denied on the object ‘sales’. Le point de terminaison applique désormais les rôles OneLake, et Alpha n’en a aucun.
5. Un rôle sur la table rétablit l’accès
À 14h48, nous créons un rôle ReadersSalesTable, en Read, qui ne donne accès qu’à la table sales du schéma dbo, et nous y ajoutons Alpha.
Après rechargement de la page, la requête réussit de nouveau, et l’explorateur du lakehouse affiche maintenant Tables → dbo → sales. Files reste bloqué : le rôle ne couvre pas les fichiers.
Le rôle OneLake pilote donc le même accès dans l’explorateur et en SQL, à condition que le point de terminaison soit en mode user’s identity.
Récapitulatif anti-pièges
| Piège | Ce qu’il faut retenir |
|---|---|
| Viewer et lakehouse | Un Viewer voit toujours l’item (Read) ; les données dépendent des rôles OneLake |
| Refus dans l’explorateur | Ne prouve pas que les données sont protégées : le SQL a son propre mode |
| Mode par défaut de l’endpoint | Delegated identity : permissions SQL, rôles OneLake ignorés |
| Passage en User’s identity | Supprime les permissions SQL, désactive l’endpoint du workspace un moment |
| Après le passage | Sans rôle OneLake sur la table, la requête est refusée |
| Rétablir l’accès | Un rôle OneLake dont les données incluent la table |
| Test | Toujours avec un compte Viewer, jamais avec un Admin |
Pourquoi ça compte au-delà de l’examen
Pour l’examen DP-700 (domaine “Implement and manage an analytics solution”, sécurité et gouvernance), savoir qu’un rôle OneLake ne s’applique pas à tous les chemins d’accès évite de croire une donnée protégée alors qu’elle ne l’est pas.
En production, l’enjeu est de vérifier le mode d’accès de chaque point de terminaison SQL avant de compter sur les rôles OneLake : un compte Viewer sans aucun rôle lisait la table dans notre lab. Mieux vaut le découvrir dans un workspace de test que pendant un audit.
En résumé
- Un Viewer voit toujours le lakehouse : c’est normal, il a Read sur l’item.
- En mode delegated (le mode par défaut), le point de terminaison SQL ignore vos rôles OneLake : dans notre lab, Alpha, sans aucun rôle, lisait la table.
- En mode user’s identity, les rôles OneLake s’appliquent au SQL : le même utilisateur est refusé, puis autorisé dès qu’un rôle couvre la table. L’effet est apparu en quelques minutes dans notre test.
- Avant de basculer : indisponibilité temporaire des points de terminaison SQL du workspace, et suppression des permissions SQL existantes (à recréer en rôles OneLake).
Pour la façon dont les rôles OneLake se combinent entre eux, voir OneLake security : les rôles s’additionnent.
Sources officielles
- OneLake security for SQL analytics endpoints : deux modes d’accès (user’s identity et delegated identity) ; un endpoint neuf démarre en mode delegated ; en delegated, l’endpoint lit OneLake avec l’identité du propriétaire de l’item et la sécurité ne dépend que des permissions SQL ; le changement de mode rend les endpoints du workspace temporairement indisponibles et supprime les permissions SQL ; la permission Read sur l’item est requise pour se connecter.
- Troubleshoot OneLake security for SQL analytics endpoints : le mode delegated ne respecte pas les rôles OneLake, d’où des résultats différents entre Spark et le point de terminaison SQL.
- How OneLake security controls data access : modèle deny by default ; les rôles de workspace sont la première frontière ; rôles de type Grant uniquement.
- Data security in OneLake : les rôles OneLake accordent l’accès aux données aux utilisateurs Viewer ou ayant la permission Read sur l’item.