Modèle de contrôle d’accès à la sécurité OneLake (préversion)

Ce document fournit un guide détaillé sur le fonctionnement du modèle de contrôle d’accès de sécurité OneLake. Il contient des détails sur la structure des rôles, leur application aux données et leur intégration à d’autres structures au sein de Microsoft Fabric.

Rôles de sécurité OneLake

La sécurité OneLake utilise un modèle de contrôle d’accès en fonction du rôle (RBAC) pour gérer l’accès aux données dans OneLake. Chaque rôle est constitué de plusieurs composants clés.

Type: Indique si le rôle donne accès (GRANT) ou supprime l’accès (DENY). Seuls les rôles de type GRANT sont pris en charge.
Autorisation: Action ou actions spécifiques qui sont accordées ou refusées.
Portée: Objets OneLake qui ont l’autorisation. Les objets sont des tables, des dossiers ou des schémas.
Membres: Toute identité Microsoft Entra affectée au rôle, comme les utilisateurs, les groupes ou les identités non-utilisateur. Le rôle est accordé à tous les membres d’un groupe Microsoft Entra.

En affectant un membre à un rôle, cet utilisateur est ensuite soumis aux autorisations associées sur l’étendue de ce rôle. Étant donné que la sécurité OneLake utilise un modèle de refus par défaut, tous les utilisateurs commencent sans accès aux données, sauf s’ils sont explicitement accordés par un rôle de sécurité OneLake.

Autorisations et éléments pris en charge

Les rôles de sécurité OneLake prennent en charge l’autorisation suivante :

Lire: Accorde à l’utilisateur la possibilité de lire des données à partir d’une table et d’afficher les métadonnées de table et de colonne associées. En termes SQL, cette autorisation équivaut à VIEW_DEFINITION et SELECT. Pour plus d’informations, consultez la sécurité des métadonnées.
ReadWrite : Accorde à l’utilisateur la possibilité de lire et d’écrire des données à partir d’une table ou d’un dossier et d’afficher les métadonnées de table et de colonne associées. En termes SQL, cette autorisation équivaut à ALTER, DROP, UPDATE et INSERT. Pour plus d’informations, consultez l’autorisation ReadWrite.

La sécurité OneLake permet aux utilisateurs de définir des rôles d’accès aux données pour les éléments Fabric suivants uniquement.

Élément Fabric	Statut	Autorisations prises en charge
Lakehouse	Public Preview	Lecture, Lecture/Écriture
Catalogue en miroir Azure Databricks	Public Preview	Lire

Autorisations de sécurité et d’espace de travail OneLake

Les autorisations d’espace de travail sont la principale limite de sécurité pour les données dans OneLake. Chaque espace de travail représente un domaine ou une zone de projet unique dans lequel les équipes peuvent collaborer sur des données. Vous gérez la sécurité dans l’espace de travail au moyen de rôles de l’espace de travail Fabric. En savoir plus sur le contrôle d’accès en fonction du rôle (RBAC) Fabric : rôles d’espace de travail

Les rôles d’espace de travail Fabric accordent des autorisations qui s’appliquent à tous les éléments de l’espace de travail. Le tableau suivant décrit les autorisations de base autorisées par les rôles d’espace de travail.

Autorisation	Administrateur	Membre	Contributeur	Observateur
Afficher les fichiers dans OneLake	Toujours* Oui	Toujours* Oui	Toujours* Oui	Non par défaut. Utilisez la sécurité OneLake pour accorder l’accès.
Écrire des fichiers dans OneLake	Toujours* Oui	Toujours* Oui	Toujours* Oui	Non
Peut modifier des rôles de sécurité OneLake	Toujours* Oui	Toujours* Oui	Non	Non

*Comme les rôles Administrateur, Membre et Contributeur d’espace de travail accordent automatiquement des autorisations d’écriture sur OneLake, ils remplacent les autorisations de lecture de sécurité OneLake.

Les rôles d’espace de travail gèrent l’accès aux données du plan de contrôle, ce qui signifie les interactions avec la création et la gestion des artefacts et des autorisations Fabric. En outre, les rôles d’espace de travail fournissent également des niveaux d’accès par défaut aux éléments de données à l’aide des rôles par défaut de sécurité OneLake. (Notez que les rôles par défaut s’appliquent uniquement aux visionneuses, car l’administrateur, le membre et le contributeur disposent d’un accès élevé via l’autorisation d’écriture) Un rôle par défaut est un rôle de sécurité OneLake normal qui est créé automatiquement avec chaque nouvel élément. Il donne aux utilisateurs avec certaines autorisations d’espace de travail ou d’élément un niveau d’accès par défaut aux données de cet élément. Par exemple, les éléments Lakehouse ont un rôle DefaultReader qui permet aux utilisateurs disposant de l’autorisation ReadAll de voir les données dans Lakehouse. Cela garantit que les utilisateurs accédant à un élément nouvellement créé ont un niveau d’accès de base. Tous les rôles par défaut utilisent une fonctionnalité de virtualisation de membre, afin que les membres du rôle soient tous les utilisateurs de cet espace de travail avec l’autorisation requise. Par exemple, tous les utilisateurs disposant de l’autorisation ReadAll sur lakehouse. Le tableau suivant indique les rôles par défaut standard. Les éléments peuvent avoir des rôles par défaut spécialisés qui s’appliquent uniquement à ce type d’élément.

Élément Fabric	Nom du rôle	Autorisation	Dossiers inclus	Membres assignés
Lakehouse	`DefaultReader`	Lire	Tous les dossiers sous `Tables/` et `Files/`	Tous les utilisateurs disposant de l’autorisation ReadAll
Lakehouse	`DefaultReadWriter`	Lire	Tous les dossiers	Tous les utilisateurs avec une autorisation d'écriture

Remarque

Pour restreindre l’accès à des utilisateurs spécifiques ou à des dossiers spécifiques, modifiez le rôle par défaut, ou supprimez-le et créez un rôle personnalisé.

Autorisations de sécurité et d’élément OneLake

Au sein d’un espace de travail, les éléments Fabric peuvent avoir des autorisations configurées séparément des rôles d’espace de travail. Vous pouvez configurer les autorisations en partageant un élément ou en gérant les autorisations d’un élément. Les autorisations suivantes déterminent la capacité d’un utilisateur à effectuer des actions sur les données dans OneLake. Pour plus d’informations sur le partage d’éléments, consultez Comment fonctionne le partage Lakehouse

Autorisation	Peut afficher des fichiers dans OneLake ?	Peut écrire des fichiers dans OneLake ?	Peut-on lire les données via le terminal d'analyse SQL ?
Lire	Non par défaut. Utilisez la sécurité OneLake pour accorder l’accès.	Non	Non
LireTout	Oui via le rôle DefaultReader. Utilisez la sécurité OneLake pour restreindre l’accès.	Non	Non*
Écrire	Oui	Oui	Oui
Exécuter, Partager à nouveau, Voir la sortie, Voir les journaux	N/A : ne peut pas être accordé par lui-même	N/A : ne peut pas être accordé par lui-même	N/A : ne peut pas être accordé par lui-même

*Dépend du mode de point de terminaison d’analyse SQL.

Créer les rôles

Vous pouvez définir et gérer des rôles de sécurité OneLake dans vos paramètres d’accès aux données de lakehouse.

En savoir plus dans Bien démarrer avec les rôles d’accès aux données.

Moteur et accès utilisateur aux données

L’accès aux données à OneLake se produit de deux façons :

Via un moteur de requête Fabric ou
Par le biais de l’accès utilisateur (les requêtes provenant de moteurs non-Fabric sont considérées comme un accès utilisateur)

La sécurité OneLake garantit que les données sont toujours sécurisées. Étant donné que certaines fonctionnalités de sécurité OneLake telles que la sécurité au niveau des lignes et des colonnes ne sont pas prises en charge par les opérations de niveau de stockage, tous les types d’accès aux données sécurisées au niveau des lignes ou des colonnes ne peuvent pas être autorisés. Cela garantit que les utilisateurs ne peuvent pas voir de lignes ou de colonnes auxquelles ils ne sont pas autorisés. Les moteurs Microsoft Fabric sont activés pour appliquer le filtrage de sécurité au niveau des lignes et des colonnes aux requêtes de données. Cela signifie qu’un utilisateur interroge des données dans un lakehouse ou un autre élément avec oneLake security RLS ou CLS sur celui-ci, les résultats que l’utilisateur voit ont les lignes et colonnes masquées supprimées. Pour l’accès utilisateur aux données dans OneLake avec RLS ou CLS sur celui-ci, la requête est bloquée si l’utilisateur demandant l’accès n’est pas autorisé à afficher toutes les lignes ou colonnes de cette table.

Le tableau ci-dessous décrit les moteurs Microsoft Fabric qui prennent en charge le filtrage RLS et CLS.

Moteur	Filtrage RLS/CLS	État
Lakehouse	Oui	Aperçu public
Notebooks Spark	Oui	Aperçu public
Point de terminaison SQL Analytics en « mode d’identité de l’utilisateur »	Oui	Aperçu public
Modèles sémantiques utilisant DirectLake sur le mode OneLake	Oui	Aperçu public
Eventhouse	Non	Planifié
Tables externes de l’entrepôt de données	Non	Planifié

Détails du modèle de contrôle d’accès de sécurité OneLake

Cette section fournit des détails sur la façon dont les rôles de sécurité OneLake accordent l’accès à des étendues spécifiques, comment cet accès fonctionne et comment l’accès est résolu entre plusieurs rôles et types d’accès.

Sécurité au niveau de la table

Toutes les tables OneLake sont représentées par des dossiers dans le lac, mais pas tous les dossiers dans le lac sont des tables selon les moteurs de requête et de sécurité OneLake dans Fabric. Pour être considéré comme un tableau valide, les conditions suivantes doivent être remplies :

Le dossier existe dans le répertoire Tables/ d’un élément.
Le dossier contient un dossier _delta_log avec les fichiers JSON correspondants pour les métadonnées de la table.
Le dossier ne contient aucun raccourci enfant.

Toutes les tables qui ne répondent pas à ces critères auront l'accès refusé si la sécurité au niveau de la table est configurée sur ces tables.

Sécurité des métadonnées

L’accès en lecture à la sécurité OneLake aux données accorde un accès total aux données et aux métadonnées d’une table. Pour les utilisateurs sans accès à une table, les données ne sont jamais exposées et les métadonnées ne sont généralement pas visibles. Cela s’applique également à la sécurité au niveau des colonnes et à la capacité d’un utilisateur à voir ou à ne pas voir une colonne dans cette table. Toutefois, la sécurité OneLake ne garantit pas que les métadonnées d’une table ne seront pas accessibles, en particulier dans les cas suivants :

Requêtes de point de terminaison SQL : le point de terminaison SQL Analytics utilise le même comportement de sécurité des métadonnées que SQL Server. Cela signifie que si un utilisateur n’a pas accès à une table ou à une colonne, le message d’erreur de cette requête indique explicitement le nom de table ou de colonne auquel l’utilisateur n’a pas accès.
Modèles sémantiques : l’octroi d’une autorisation build utilisateur sur un modèle sémantique leur permet d’accéder aux noms de tables inclus dans le modèle, que l’utilisateur y ait accès ou non. En outre, les visuels de rapport qui contiennent des colonnes masquées affichent le nom de colonne dans le message d’erreur.

Héritage d'autorisations

Pour un dossier donné, les autorisations de sécurité OneLake héritent toujours de l’intégralité de la hiérarchie des fichiers et sous-dossiers du dossier.

Par exemple, considérez la hiérarchie suivante d’un lakehouse dans OneLake :

Tables/
──── (empty folder)
Files/
────folder1
│   │   file11.txt
│   │
│   └───subfolder11
│       │   file1111.txt
|       │
│       └───subfolder111
|            │   file1111.txt
│   
└───folder2
    │   file21.txt

Vous créez deux rôles pour ce lakehouse. Role1 accorde l’autorisation de lecture sur folder1 et Role2 accorde l’autorisation de lecture sur folder2.

Pour la hiérarchie donnée, les autorisations de sécurité OneLake pour Role1 et Role2 héritent de la manière suivante :

Role1 : lire folder1

│   │   file11.txt
│   │
│   └───subfolder11
│       │   file1111.txt
|       │
│       └───subfolder111
|            │   file1111.txt

Role2 : lire folder2
```
    │   file21.txt
```

Parcours et établissement de liste dans la sécurité OneLake

La sécurité OneLake fournit un parcours automatique des éléments parents pour faciliter la découverte des données. L’octroi d’autorisations de lecture à l’utilisateur sur subfolder11 lui permet de lister et de parcourir le répertoire parent folder1. Cette fonctionnalité est similaire aux autorisations de dossier Windows où l’accès à un sous-dossier fournit la découverte et le parcours pour les répertoires parents. L’établissement de liste et le parcours accordés au parent ne s’étendent pas aux autres éléments en dehors des parents directs, ce qui garantit la sécurité des autres dossiers.

Par exemple, considérez la hiérarchie suivante d'un "lakehouse" dans OneLake.

Tables/
──── (empty folder)
Files/
────folder1
│   │   file11.txt
│   │
│   └───subfolder11
│       │   file111.txt
|       │
│       └───subfolder111
|            │   file1111.txt
│   
└───folder2
    │   file21.txt

Pour la hiérarchie donnée, les autorisations de sécurité OneLake pour « Role1 » fournissent l’accès suivant. L’accès à file11.txt n’est pas visible, car ce n’est pas un parent de subfolder11. De même pour Role2, file111.txt n’est pas visible non plus.

Role1 : lire subfolder11

Files/
────folder1
│   │
│   └───subfolder11
│       │   file111.txt
|       │
│       └───subfolder111
|            │   file1111.txt

Role2 : lire subfolder111

Files/
────folder1
│   │
│   └───subfolder11
|       │
│       └───subfolder111
|            │   file1111.txt

Pour les raccourcis, le comportement de l'affichage est légèrement différent. Les raccourcis vers des sources de données externes se comportent de la même façon que les dossiers, mais les raccourcis vers d’autres emplacements OneLake ont un comportement spécialisé. Les autorisations cibles du raccourci déterminent l’accès à un raccourci OneLake. Lors de l'établissement de la liste des raccourcis, il n'est pas nécessaire de vérifier l'accès à la cible. Par conséquent, quand vous listez un répertoire, tous les raccourcis internes sont renvoyés, quel que soit l’accès de l’utilisateur à la cible. Quand un utilisateur tente d’ouvrir le raccourci, la vérification évalue l’accès et l’utilisateur voit uniquement les données pour lesquelles il a les autorisations de lecture nécessaires. Pour plus d’informations sur les raccourcis, consultez la section relative à la sécurité des raccourcis.

Considérez la hiérarchie de dossiers suivante qui contient des raccourcis.

Files/
────folder1
│   
└───shortcut2
|
└───shortcut3

Role1 : lire folder1

Files/
────folder1
│   
└───shortcut2
|
└───shortcut3

Role2 : aucune autorisation définie

Files/
│   
└───shortcut2
|
└───shortcut3

Sécurité au niveau des lignes

La sécurité OneLake permet aux utilisateurs de spécifier la sécurité au niveau des lignes en écrivant des prédicats SQL pour limiter les données affichées à un utilisateur. RLS fonctionne en montrant les lignes où le prédicat est évalué à true. Pour plus d’informations, consultez la sécurité au niveau des lignes.

La sécurité au niveau des lignes évalue les données de chaîne comme non sensibles à la casse, en utilisant le classement suivant pour le tri et les comparaisons : Latin1_General_100_CI_AS_KS_WS_SC_UTF8

Lorsque vous utilisez la sécurité au niveau des lignes, assurez-vous que les instructions RLS sont propres et faciles à comprendre. Utilisez des colonnes entières pour le tri et supérieur ou inférieur aux opérations. Évitez les équivalences de chaîne si vous ne connaissez pas le format des données d’entrée, en particulier par rapport aux caractères Unicode ou à la sensibilité des accents.

Sécurité au niveau des colonnes

La sécurité OneLake prend en charge la limitation de l’accès aux colonnes en supprimant (masquant) l’accès d’un utilisateur à une colonne. Une colonne masquée est traitée comme n’ayant aucune autorisation affectée à celle-ci, ce qui entraîne la stratégie par défaut d’aucun accès. Les colonnes masquées ne seront pas visibles par les utilisateurs et les requêtes sur les données contenant des colonnes masquées ne retournent aucune donnée pour cette colonne. Comme indiqué dans la sécurité des métadonnées , il existe certains cas où les métadonnées d’une colonne peuvent toujours être visibles dans certains messages d’erreur.

La sécurité au niveau des colonnes suit également un comportement plus strict dans le point de terminaison SQL en fonctionnant par le biais d’une sémantique de refus. Refuser sur une colonne dans le point de terminaison SQL garantit que tous les accès à la colonne sont bloqués, même si plusieurs rôles se combinent pour lui donner accès. Par conséquent, CLS dans le point de terminaison SQL fonctionne à l’aide d’une intersection entre tous les rôles qu’un utilisateur fait partie du comportement d’union en place pour tous les autres types d’autorisations. Consultez la section Évaluation de plusieurs rôles de sécurité OneLake pour plus d’informations sur la façon dont les rôles se combinent.

Autorisation de lecture-écriture

L’autorisation ReadWrite permet aux utilisateurs en lecture seule d’effectuer des opérations d’écriture sur des éléments spécifiques. L’autorisation ReadWrite s’applique uniquement aux spectateurs ou aux utilisateurs disposant de l’autorisation de lecture sur un élément. L’attribution d’un accès ReadWrite à un administrateur, à un membre ou à un contributeur n’a aucun effet, car ces rôles disposent déjà de cette autorisation implicitement.

L’accès ReadWrite permet aux utilisateurs d’effectuer des opérations d’écriture via des notebooks Spark, l’Explorateur de fichiers OneLake ou les API OneLake. Les opérations d'écriture via l'interface utilisateur de Lakehouse pour les utilisateurs ne sont pas prises en charge.

L’autorisation ReadWrite fonctionne de la manière suivante :

L'autorisation ReadWrite inclut tous les privilèges accordés par l'autorisation Lecture.
Les utilisateurs disposant d’autorisations ReadWrite sur un objet peuvent effectuer des opérations d’écriture sur cet objet, inclus. Autrement dit, toutes les opérations peuvent également être effectuées sur l’objet lui-même.
ReadWrite permet les actions suivantes :
- Créer un dossier ou une table
- Supprimer un dossier ou une table
- Renommer un dossier ou une table
- Charger ou modifier un fichier
- Créer un raccourci
- Supprimer un raccourci
- Renommer un raccourci
Les rôles de sécurité OneLake avec accès ReadWrite ne peuvent pas contenir de contraintes RLS ou CLS.
Étant donné que Fabric prend uniquement en charge les écritures par un seul moteur dans les données, les utilisateurs disposant d’une autorisation ReadWrite sur un objet peuvent écrire ces données uniquement via OneLake. Toutefois, les opérations de lecture sont appliquées de manière cohérente via tous les moteurs d’interrogation.

Raccourcis

Vue d’ensemble des raccourcis

La sécurité OneLake s’intègre aux raccourcis dans OneLake pour garantir que les données à l’intérieur et à l’extérieur de OneLake peuvent être facilement sécurisées. Il existe deux modes d’authentification principaux pour les raccourcis :

Raccourcis pas à pas (SSO) : les informations d’identification de l’utilisateur interrogeant sont évaluées par rapport à la cible de raccourci pour déterminer les données autorisées à être affichées.
Raccourcis délégués : le raccourci utilise des informations d’identification fixes pour accéder à la cible et l’utilisateur d’interrogation est évalué par rapport à la sécurité OneLake avant de vérifier l’accès des informations d’identification déléguées à la source.

En outre, les autorisations de sécurité OneLake sont évaluées lors de la création de raccourcis dans OneLake. Découvrez les autorisations de raccourci dans le document de sécurité de raccourci.

Sécurité OneLake dans les raccourcis passthrough

La sécurité définie sur un dossier OneLake circule toujours sur tous les raccourcis internes pour restreindre l’accès au chemin source du raccourci. Quand un utilisateur accède à des données en utilisant un raccourci vers un autre emplacement OneLake, l’identité de l’utilisateur appelant est utilisée pour autoriser l’accès aux données dans le chemin cible du raccourci. Cet utilisateur doit donc avoir des autorisations de sécurité OneLake sur l’emplacement cible pour lire les données.

Important

Lors de l’accès aux raccourcis via des modèles sémantiques Power BI à l’aide de DirectLake sur desmoteurs SQL ou T-SQL en mode d’identité déléguée, l’identité de l’utilisateur appelant n’est pas transmise à la cible de raccourci. L’identité du propriétaire de l’élément appelant est transmise à la place, en déléguant l’accès à l’utilisateur appelant. Pour résoudre ce problème, utilisez des modèles sémantiques Power BI en mode DirectLake sur OneLake ou T-SQL en mode d’identité de l’utilisateur.

La définition des autorisations de sécurité OneLake pour le raccourci interne n’est pas autorisée et doit être définie sur le dossier cible situé dans l’élément cible. L’élément cible doit être un type d’élément qui prend en charge les rôles de sécurité OneLake. Si l’élément cible ne prend pas en charge la sécurité OneLake, l’accès de l’utilisateur est évalué en fonction de l’autorisation Fabric ReadAll sur l’élément cible. Les utilisateurs n’ont pas besoin de Fabric l’autorisation Lecture sur un élément pour y accéder via un raccourci.

Sécurité OneLake dans les raccourcis délégués

OneLake prend en charge la définition des autorisations pour les raccourcis comme les raccourcis ADLS, S3 et Dataverse. Dans ce cas, les autorisations sont appliquées au-dessus du modèle d’autorisation délégué activé pour ce type de raccourci.

Supposons que user1 crée un raccourci S3 dans un lakehouse pointant vers un dossier dans un compartiment AWS S3. Ensuite, user2 tente d’accéder aux données dans ce raccourci.

La connexion S3 autorise-t-elle l’accès pour le user1 délégué ?	La sécurité OneLake autorise-t-elle l’accès pour le user2 demandeur ?	Résultat : user2 peut-il accéder aux données dans le raccourci S3 ?
Oui	Oui	Oui
Non	Non	Non
Non	Oui	Non
Oui	Non	Non

Les autorisations de sécurité OneLake peuvent être définies pour l’ensemble de l’étendue du raccourci ou pour des sous-dossiers sélectionnés. Les autorisations définies sur un dossier s’héritent de manière récursive sur tous les sous-dossiers, même si le sous-dossier se trouve dans le raccourci. La sécurité définie sur un raccourci externe peut être délimitée pour accorder l’accès à l’intégralité du raccourci ou tout sous-chemin à l’intérieur du raccourci. Un autre raccourci interne pointant vers un raccourci externe nécessite toujours que l’utilisateur ait accès au raccourci externe d’origine.

Contrairement à d’autres types d’accès dans la sécurité OneLake, un utilisateur accédant à un raccourci externe nécessite l’l’autorisation Lecture Fabric sur l’élément de données où réside le raccourci externe. Cela est nécessaire pour résoudre en toute sécurité la connexion au système externe.

En savoir plus sur les raccourcis S3, ADLS et Dataverse dans Raccourcis OneLake.

Évaluation de plusieurs rôles de sécurité OneLake

Les utilisateurs peuvent être membres de plusieurs rôles de sécurité OneLake différents, chacun fournissant son propre accès aux données. La combinaison de ces rôles est appelée « rôle effectif » et c’est ce qu’un utilisateur verra lors de l’accès aux données dans OneLake. Les rôles combinent dans la sécurité OneLake à l’aide d’un modèle UNION ou moins restrictif. Cela signifie que si Role1 donne accès à TableA et que Role2 donne accès à TableB, l’utilisateur pourra voir TableA et TableB.

Les rôles de sécurité OneLake contiennent également la sécurité au niveau des lignes et des colonnes, ce qui limite l’accès aux lignes et aux colonnes d’une table. Chaque stratégie RLS et CLS existe dans un rôle et limite l’accès aux données pour tous les utilisateurs au sein de ce rôle unique. Par exemple, si Role1 donne accès à Table1, mais a RLS sur Table1 et affiche uniquement certaines colonnes de Table1, le rôle effectif pour Role1 sera les sous-ensembles RLS et CLS de Table1. Cela peut être exprimé en tant que (R1ols n R1cls n R1rls) où n est l’INTERSECTION de chaque composant dans le rôle.

Lorsque vous traitez de plusieurs rôles, RLS et CLS s’associent à une sémantique UNION sur les tables respectives. CLS est un ensemble direct union des tables visibles dans chaque rôle. RLS est combiné entre les prédicats à l’aide d’un opérateur OR. Par exemple, WHERE city = 'Redmond' OR city = 'New York'.

Pour évaluer plusieurs rôles avec RLS ou CLS, chaque rôle est d’abord résolu en fonction de l’accès donné par le rôle lui-même. Cela signifie l’évaluation de l’INTERSECTION de tous les objets, lignes et sécurité au niveau des colonnes. Chaque rôle évalué est ensuite combiné avec tous les autres rôles dont un utilisateur est membre via l’opération UNION. La sortie est le rôle effectif pour cet utilisateur. Cela peut être exprimé comme suit :

( (R1ols n R1cls n R1rls) u (R2ols n R2cls n R2rls) )

Enfin, chaque raccourci d’une lakehouse génère un ensemble de rôles déduits utilisés pour propager les autorisations de la cible de raccourci à l’élément interrogé. Les rôles déduits fonctionnent de la même façon que les rôles non déduits, sauf qu’ils sont résolus en premier lieu sur la cible de raccourci avant d’être combinés avec des rôles dans le lac de raccourci. Cela garantit que l’héritage des autorisations sur le lac d’accès contextuel est rompu et que les rôles déduits sont évalués correctement. La logique de combinaison complète peut ensuite être exprimée comme suit :

( (R1ols n R1cls n R1rls) u (R2ols n R2cls n R2rls) ) n ( (R1'ols n R1'cls n R1'rls) u (R2'ols n R2'cls n R2'rls)) )

Où R1' et R2' sont les rôles déduits et R1 et R2 sont les rôles lakehouse de raccourci.