Comment la sécurité OneLake contrôle l’accès aux données

La sécurité OneLake est un système basé sur des rôles qui détermine qui peut accéder aux données dans OneLake et quelles actions il peut entreprendre sur ces données. Comprendre le modèle de contrôle d’accès aux données vous permet d’accorder aux utilisateurs uniquement l’accès dont ils ont besoin, afin de protéger les données sensibles tout en laissant les bonnes personnes y travailler.

Cet article explique comment les rôles de sécurité OneLake sont structurés, comment ils s’intègrent avec les permissions d’espace de travail et d’objets, comment OneLake applique et résout l’accès à vos données, ainsi que les limites à garder à l’esprit.

Rôles de sécurité OneLake

La sécurité de OneLake utilise un modèle de contrôle d’accès basé sur les rôles (RBAC) pour gérer l’accès aux données dans OneLake. Dans l’expérience sécurité OneLake, chaque poste comporte les composantes suivantes :

  • Autorisations : Les autorisations que le rôle accorde sur les données, telles que Lecture ou Lecture/écriture.
  • Type : Le type de rôle. La sécurité OneLake ne prend en charge que les rôles Grant, qui donnent aux membres accès aux données du poste. Il ne prend pas en charge les rôles de refus qui suppriment l’accès.
  • Données dans le rôle : Les tableaux, dossiers ou schémas auxquels le rôle accorde accès. Vous pouvez également définir l’accès aux données avec une sécurité au niveau ligne et au niveau des colonnes sur les tables.
  • Membres en poste : Les identités Microsoft Entra attribuées au rôle, telles que les utilisateurs, les groupes ou les identités non utilisateur. Si vous attribuez un groupe Microsoft Entra, OneLake Security attribue ce rôle à tous les membres du groupe.

La sécurité OneLake utilise un modèle de refus par défaut ; les utilisateurs n’ont donc initialement aucun accès aux données, à moins qu’un rôle de sécurité OneLake ne leur accorde explicitement cet accès. Certains éléments Fabric commencent par des rôles par défaut qui donnent aux utilisateurs un accès de base basé sur les permissions de leur espace de travail.

Autorisations et éléments pris en charge

Les rôles de sécurité OneLake prennent en compte les autorisations suivantes :

  • 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 de SQL, cette autorisation équivaut à la fois à VIEW_DEFINITION et à SELECT. Pour plus d’informations, voir Sécurité des métadonnées.
  • ReadWrite : Permet à l’utilisateur de lire et d’écrire des données dans un tableau ou un dossier et de consulter les métadonnées associées à la table et à la colonne. En termes SQL, cette permission est équivalente à ALTER, DROP, UPDATE, et INSERT. Pour plus d’informations, voir Autorisation ReadWrite.

Vous pouvez créer des rôles de sécurité OneLake pour les articles Fabric suivants :

Élément Fabric Permissions supportées
Lakehouse Lecture, Lecture/Écriture
Catalogue mis en miroir Azure Databricks Lire
Bases de données mises en miroir Lire
Catalogues en miroir Lire

Autorisation de lecture-écriture

Utilisez la permission ReadWrite pour donner aux utilisateurs en lecture seule un accès à l’écriture à des données spécifiques d’un élément.

ReadWrite ne s’applique qu’aux utilisateurs ayant la permission de lire sur un élément, comme ceux ayant le rôle d’espace de travail Visualiseur. L’attribution de l’autorisation Lecture/écriture à un administrateur, un membre ou un contributeur de l’espace de travail n’a aucun effet, car ces rôles d’espace de travail disposent déjà d’un accès en écriture.

ReadWrite inclut tous les privilèges accordés par la permission de lecture, ainsi qu’il accorde un accès d’écriture à l’objet sélectionné et à son contenu. Par exemple, la permission ReadWrite sur un dossier accorde l’accès d’écriture à la fois au dossier et aux données qu’il contient.

Les utilisateurs disposant de la permission ReadWrite peuvent effectuer les actions suivantes :

  • Créez, supprimez ou renommez un dossier ou une table.
  • Téléchargez ou modifiez un fichier.
  • Créez, supprimez ou renommez un raccourci.

Les utilisateurs peuvent effectuer des opérations d’écriture via des carnets Spark, l’explorateur de fichiers OneLake ou les API OneLake. Étant donné que Fabric ne prend en charge que l’écriture des données via un seul moteur, les utilisateurs disposant de l’autorisation ReadWrite peuvent écrire dans ces données uniquement par l’intermédiaire de OneLake. Tous les moteurs de requête continuent d’appliquer des opérations de lecture de manière cohérente.

Les rôles de sécurité OneLake qui accordent la permission ReadWrite ne peuvent pas contenir de contraintes de sécurité au niveau ligne (RLS) ou de sécurité au niveau colonne (CLS).

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

Les rôles d’espace de travail constituent la première frontière de sécurité pour les données dans OneLake. Ils gèrent le plan de contrôle – créant et gérant les éléments Fabric et les permissions – et s’appliquent à tous les éléments de l’espace de travail. Pour connaître les autorisations OneLake spécifiques accordées par chaque rôle d’espace de travail, consultez Accorder l’accès avec les rôles d’espace de travail. Pour en savoir plus sur les rôles dans les espaces de travail, voir Rôles dans les espaces de travail dans Fabric.

Au-delà de l’accès par plan de contrôle, les rôles d’espace de travail peuvent également fournir un accès aux éléments de données via les rôles de sécurité par défaut OneLake. (Les rôles par défaut s’appliquent uniquement aux Viewers, car les rôles Admin, Member et Contributor ont un accès élevé via l’autorisation d’écriture.) Un rôle par défaut est un rôle de sécurité OneLake normal que Fabric crée automatiquement à 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 ayant l’autorisation ReadAll de consulter les données dans le lakehouse. Cet accès par défaut garantit que les utilisateurs travaillant avec un nouvel élément ont un niveau d’accès basique. Tous les rôles par défaut utilisent une fonction de virtualisation des membres, de sorte que les membres du rôle sont des utilisateurs présents dans cet espace de travail avec la permission requise. Par exemple, tous les utilisateurs disposant de l’autorisation ReadAll sur le lakehouse.

Le tableau suivant présente les rôles par défaut standards. Les objets peuvent avoir des rôles par défaut spécialisés qui ne s’appliquent qu’à ce type d’objet.

Élément Fabric Nom du rôle Permission accordée Membres assignés
Lakehouse DefaultReader Lire Tous les utilisateurs disposant de l’autorisation ReadAll
Catalogue mis en miroir Azure Databricks DefaultReader Lire Tous les utilisateurs disposant d’une autorisation lecture
Catalogue en miroir DefaultReader Lire Tous les utilisateurs disposant d’une autorisation lecture
Base de données en miroir DefaultReader Lire Tous les utilisateurs disposant de l’autorisation ReadAll

Vous pouvez modifier ou supprimer le rôle par défaut d’un élément Fabric pour changer l’accès des utilisateurs de ce groupe de membres.

Moteur et accès utilisateur aux données

Par défaut, la sécurité OneLake applique le principe du moindre privilège. Certaines opérations au niveau du stockage ne peuvent pas appliquer RLS ou CLS, donc lorsqu’une requête ne peut pas être filtrée en toute sécurité, OneLake la bloque complètement plutôt que de risquer d’exposer des données que l’utilisateur n’est pas autorisé à voir. Le fait qu’une requête soit filtrée ou bloquée dépend du chemin d’accès – un moteur de requête supporté ou un accès direct utilisateur.

Pour les moteurs qui prennent en charge le filtrage RLS et CLS ainsi que les exigences associées, voir Lire des données sécurisées avec la sécurité OneLake.

Portée et mise en application

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

OneLake représente toutes les tables comme des dossiers, mais du point de vue de la sécurité et des moteurs de requête de OneLake dans Fabric, tous les dossiers ne sont pas des tableaux. Pour qu’un tableau soit valide, un dossier doit remplir les conditions suivantes :

  • Le dossier existe dans le Tables/ répertoire d’un article. Pour les éléments prenant en charge le schéma, le dossier doit également se trouver dans un dossier de schéma valide.
  • Le dossier contient un _delta_log dossier contenant des fichiers JSON correspondants pour les métadonnées de tableau.
  • Le dossier ne contient aucun raccourci enfant.

Si vous configurez RLS ou CLS sur une table, OneLake refuse l’accès lorsque le dossier de la table ne remplit pas ces critères. Sans RLS ou CLS, OneLake traite un dossier qui ne remplit pas ces critères comme un dossier et applique une sécurité au niveau des dossiers.

Sécurité au niveau des lignes et des colonnes

Dans un poste, vous pouvez restreindre l’accès à certaines lignes et colonnes d’un tableau en utilisant la sécurité au niveau ligne et au niveau colonne. Pour plus d’informations sur ce que fait chaque contrôle et comment OneLake l’applique, voir Sécurité au niveau des tables, colonnes et lignes dans OneLake. Pour des informations sur la résolution de RLS et CLS lorsqu’un utilisateur appartient à plusieurs rôles, voir Évaluer plusieurs rôles de sécurité OneLake.

Sécurité des métadonnées

L'autorisation de lecture de la sécurité OneLake 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. Cette règle s’applique également à la sécurité au niveau de la colonne et à la capacité de l’utilisateur à voir ou non une colonne dans ce tableau. Cependant, la sécurité OneLake ne garantit pas que les métadonnées d’une table ne sont pas accessibles. Certains messages d’erreur et expériences peuvent afficher les noms des colonnes.

Héritage des permissions et déplacement des dossiers

Les permissions de dossier affectent une hiérarchie dans deux directions :

  • Héritage : Les autorisations accordées sur un dossier s’appliquent à ses fichiers et sous-dossiers.
  • Parcours et listage : Lorsque les utilisateurs disposent d’une autorisation sur un élément enfant, la sécurité OneLake leur permet de lister et de parcourir les dossiers parents afin qu’ils puissent découvrir les données auxquelles ils peuvent accéder et y accéder. La traversée de répertoires ne permet pas d’accéder aux fichiers ou dossiers du même niveau.

Considérez la hiérarchie suivante d’une maison lacustre dans OneLake :

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

Vous créez un rôle, Role1, qui accorde la permission de lire sur subfolder11. Grâce à l’héritage, les membres de ce rôle peuvent lire file111.txt et tout ce qui se trouve dans subfolder111. Les membres peuvent voir et traverser folder1 pour atteindre subfolder11, mais ils ne peuvent pas voir file11.txt car c’est un frère ou une sœur de subfolder11 et ils ne peuvent pas voir Tables car c’est un frère ou une sœur de Files.

Files/
│
└───folder1
│   │
│   └───subfolder11 <-- READ
│       │   file111.txt
│       │
│       └───subfolder111
│            │   file1111.txt

Vous créez un autre rôle, Role2, qui accorde la permission de lire sur folder2. Grâce à l’héritage, les membres peuvent lire file21.txt. Les membres peuvent passer par folder2 et Files pour l’atteindre, mais ils ne peuvent pas voir folder1 ni aucun de ses éléments enfants.

Files/
│
└───folder2 <-- READ
    │   file21.txt

Pour les raccourcis, le comportement est légèrement différent. Les raccourcis vers des sources de données externes se comportent de la même manière que les dossiers. Cependant, les raccourcis vers d’autres emplacements OneLake présentent un comportement spécifique. Les autorisations cibles du raccourci déterminent l’accès à un raccourci OneLake. Lorsqu’il liste des raccourcis, OneLake ne fait aucun appel pour vérifier l’accès cible. En conséquence, lorsque vous listez un annuaire, OneLake renvoie tous les raccourcis internes, quel que soit votre accès à la cible. La vérification d’accès s’évalue une fois que vous essayez d’ouvrir le raccourci, et vous ne voyez alors que les données pour lesquelles vous avez les autorisations requises.

Raccourcis

La sécurité OneLake s’intègre avec des raccourcis pour sécuriser les données à l’intérieur et à l’extérieur de OneLake. Les raccourcis utilisent l’un des deux modes d’authentification :

  • Passage : Le raccourci utilise l’identité de l’utilisateur interrogateur pour accéder à la cible. Le mode passthrough est l’option par défaut pour les raccourcis d’OneLake à OneLake.
  • Délégué : Le raccourci utilise une identité de connexion configurée ou des informations d’identification pour accéder à la cible. Les raccourcis OneLake-to-OneLake peuvent utiliser une authentification déléguée, et les raccourcis vers les systèmes externes utilisent toujours l’authentification déléguée.

Créer un raccourci nécessite des permissions à la fois sur le chemin où le raccourci est créé et sur le chemin cible. Pour les exigences de création et d’accès à chaque type de raccourci, voir OneLake Shortcut Security.

Sécurité de OneLake dans les raccourcis de passage direct

Lorsqu’un utilisateur accède aux données via un raccourci passthrough OneLake-to-OneLake, OneLake utilise l’identité de l’utilisateur appelant pour autoriser l’accès au chemin cible. L’accès effectif de l’utilisateur est limité par ses permissions à la fois sur le chemin de raccourci et sur le chemin cible.

Remarque

L’identité du moteur de requête et l’authentification par raccourci sont des réglages distincts. Un raccourci passthrough utilise normalement l’identité de l’utilisateur appelant pour accéder à la cible. Cependant, les modèles sémantiques Power BI qui utilisent Direct Lake sur SQL et des points de terminaison d’analytique SQL en mode d’identité déléguée utilisent l’identité du propriétaire de l’élément consommateur ou de la source de données. Ce comportement ne modifie pas le mode d’authentification configuré par le raccourci. Pour un passage d’identité utilisateur de bout en bout, utilisez Direct Lake sur OneLake ou configurez le point de terminaison d’analyse SQL pour utiliser le mode d’accès à l’identité de l’utilisateur.

Vous ne pouvez pas définir directement les permissions de sécurité OneLake sur un raccourci OneLake-à-OneLake. Les permissions sur le dossier contenant le raccourci se combinent avec les autorisations sur le chemin cible. Si l’élément cible prend en charge la sécurité OneLake, l’utilisateur doit accéder via un rôle de sécurité OneLake. Si l'élément cible ne prend pas en charge la sécurité OneLake, l'utilisateur a besoin de la permission Fabric ReadAll sur l'élément cible. L'utilisateur n'a pas besoin d'une autorisation de lecture Fabric sur l'élément cible uniquement pour accéder à ses données via le raccourci.

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

Les raccourcis délégués utilisent un identifiant de connexion configuré ou un identifiant d’identification au lieu de l’identité de l’utilisateur appelant pour accéder à la cible. La sécurité OneLake limite ce à quoi l’utilisateur appelant peut accéder via cette connexion.

Raccourcis OneLake délégués

Pour un raccourci délégué d’un OneLake vers un autre OneLake, l’utilisateur appelant dispose de l’intersection entre ses droits d’accès sur le chemin du raccourci et les droits d’accès de l’identité de connexion configurée sur le chemin cible. La sécurité au niveau des colonnes (CLS) est prise en charge sur les deux voies. La sécurité au niveau des lignes (RLS) est prise en charge sur le chemin cible, mais vous ne pouvez pas définir RLS sur le chemin de raccourci.

Raccourcis externes délégués

Les raccourcis vers des systèmes externes, tels que ADLS, Amazon S3 et Dataverse, utilisent un identifiant de connexion configuré pour accéder à la source externe. La sécurité OneLake s’applique en plus de l’accès accordé par cette certification.

Par exemple, supposons que l’utilisateur1 crée un raccourci de la maison du lac vers un dossier dans un bucket Amazon S3, et que l’utilisateur2 accéde au raccourci depuis la maison du lac. L’utilisateur2 ne peut accéder aux données S3 que si l’identifiant de connexion S3 configuré peut accéder à la source et que la sécurité OneLake autorise l’utilisateur 2 à accéder au chemin de raccourci.

Vous pouvez accorder à OneLake un accès de sécurité à l’ensemble du raccourci externe ou à certains sous-chemins sélectionnés. Les autorisations d’un dossier sont héritées récursivement par tous ses sous-dossiers, y compris les dossiers contenus dans le raccourci. Un utilisateur qui atteint un raccourci externe via un autre raccourci OneLake doit toujours être autorisé par la sécurité OneLake appliquée au raccourci externe d’origine.

L’accès à un raccourci externe via Spark ou un appel API OneLake direct nécessite également une autorisation de lecture Fabric sur l’élément contenant le raccourci externe. Cette autorisation est nécessaire pour résoudre en toute sécurité la connexion au système externe.

Évaluer plusieurs rôles de sécurité chez OneLake

Un utilisateur peut appartenir à plusieurs rôles de sécurité OneLake. OneLake combine l’accès accordé par ces rôles en un rôle efficace, qui détermine les données auxquelles l’utilisateur peut accéder. OneLake évalue le rôle effectif par étapes.

Définir les accès pour chaque rôle

OneLake résout d’abord chaque rôle de manière indépendante. Dans un rôle, un utilisateur ne peut accéder qu’aux données autorisées par les trois composants de sécurité :

  • La sécurité au niveau objet (OLS) détermine quelles tables ou dossiers le rôle peut accéder.
  • La sécurité au niveau des lignes (RLS) limite les lignes d’une table donnée auxquelles le rôle peut accéder.
  • La sécurité au niveau des colonnes (CLS) limite les colonnes d’une table donnée auxquelles le rôle peut accéder.

Comme les trois composants s’appliquent, OneLake retient leur intersection. Par exemple, si Role1 accorde l’accès à Table1 et restreint ses lignes et colonnes, l’accès résolu pour Role1 est :

Role1 = R1_OLS ∩ R1_RLS ∩ R1_CLS

Le symbole d’intersection (∩) signifie que l’utilisateur ne reçoit que l’accès autorisé par OLS, RLS et CLS dans ce rôle.

Combiner l’accès entre rôles

Après avoir résolu chaque rôle, OneLake combine les rôles en utilisant un modèle syndiqué, ou le moins restrictif. Le symbole syndical (∪) signifie que l’accès accordé par n’importe quel rôle devient partie intégrante du rôle effectif. Si le Rôle1 accorde l’accès à la TableA et que le Rôle2 donne accès à la TableB, un utilisateur appartenant aux deux rôles peut accéder aux deux tableaux.

Pour deux rôles, le rôle effectif est :

Effective role = Role1 ∪ Role2

Lorsque plusieurs rôles donnent accès à la même table, les règles de sécurité au niveau des lignes se combinent à l’aide de l’opérateur OR. Par exemple, les prédicats qui permettent city = 'Redmond' et city = 'New York' combinent comme city = 'Redmond' OR city = 'New York'.

Les règles de sécurité au niveau des colonnes se combinent également par union, sauf dans le point de terminaison d’analytique SQL. Dans le point de terminaison analytique SQL, CLS utilise une sémantique de déni plus stricte. Si un rôle cache une colonne, le point d’extrémité bloque l’accès à cette colonne. En conséquence, le point d’extrémité croise les listes CLS allow à travers tous les rôles de l’utilisateur au lieu de les combiner en une union.

Important

Gardez les règles RLS et CLS qui doivent s’appliquer ensemble dans le même rôle. OneLake ne supporte pas une combinaison de rôles où deux rôles permettent un ensemble différent de colonnes pour une table et où l’un ou l’autre rôle applique également RLS à cette table. Par exemple, un utilisateur ne peut pas appartenir à Role1, qui permet les colonnes c1 et c2 et un sous-ensemble de lignes, et à Role2, qui permet les colonnes c2 et c3.

Combiner raccourci et accès à la cible

Pour un raccourci, OneLake évalue séparément les rôles à l’emplacement du raccourci et au niveau de la cible du raccourci. Les rôles ciblés deviennent des rôles inférés au point de raccourci. OneLake croise ensuite l’accès combiné des rôles de raccourci avec l’accès combiné des rôles cibles déduits. Cette étape empêche que l’accès hérité à l’emplacement du raccourci ne remplace les restrictions appliquées à la cible.

Pour deux rôles raccourcis et deux rôles cibles déduites, l’accès effectif est :

Effective shortcut access = (ShortcutRole1 ∪ ShortcutRole2) ∩ (InferredRole1 ∪ InferredRole2)

Dans cette expression, ShortcutRole1 et ShortcutRole2 sont des rôles à l’emplacement du raccourci. InferredRole1 et InferredRole2 sont les rôles déduits correspondants à partir de la cible de raccourci. Chaque rôle est défini à partir de ses composantes OLS, RLS et CLS avant qu’OneLake ne combine les rôles.

Limitations de sécurité OneLake

  • Si vous attribuez un rôle de sécurité OneLake à un utilisateur invité B2B, vous devez configurer vos paramètres de collaboration externe pour B2B dans ID externe Microsoft Entra. Définissez le paramètre d’accès des utilisateurs invités à que les utilisateurs invités aient le même accès que les membres (le plus inclusif).

  • Si vous ajoutez une liste de distribution à un rôle dans la sécurité de OneLake, le point de terminaison d’analytique SQL ne peut pas identifier les membres de la liste pour appliquer les autorisations d’accès. En conséquence, les utilisateurs semblent ne pas être membres du poste lorsqu’ils accèdent au point de terminaison SQL analytics. Direct Lake sur des modèles sémantiques SQL est également soumis à cette limitation.

  • Les notebooks Spark nécessitent un environnement en version 3.5 ou ultérieure et l’utilisation du runtime Fabric 1.3.

  • Les lakehouses sans schéma ne prennent pas en charge l’aperçu des données pour les tables sécurisées par RLS et CLS. Utilisez des maisons lacustres compatibles avec schéma et la sécurité OneLake.

  • La sécurité OneLake ne fonctionne pas avec Azure Data Share ou Purview Data Share. Pour plus d’informations, consultez Azure Data Share.

  • Le tableau suivant liste les limitations des rôles de sécurité chez OneLake.

    Scénario Limite
    Nombre maximal de rôles de sécurité OneLake par élément Fabric 250 rôles par élément (voir note)
    Nombre maximal de membres par rôle de sécurité OneLake 500 utilisateurs ou groupes d’utilisateurs par rôle
    Nombre maximal d’autorisations par rôle de sécurité OneLake 500 autorisations par rôle

    Remarque

    Vous pouvez demander une augmentation du nombre de rôles par objet à 1 000. Pour demander une augmentation, contactez Azure support.

Latences

L’application des changements de définitions de rôle prend environ 5 minutes.

En cas de changements dans un groupe d’utilisateurs dans un rôle de sécurité OneLake, il faut compter environ une heure pour que OneLake applique les autorisations du rôle sur le groupe d’utilisateurs mis à jour. Certains moteurs Fabric ont leur propre couche de mise en cache. Par conséquent, une heure supplémentaire peut être nécessaire pour mettre à jour l’accès dans tous les systèmes.

Contenu connexe

  • Last updated on