Sécurité OneLake pour les points de terminaison d’analytique SQL (préversion)

Avec la sécurité OneLake, Microsoft Fabric développe la façon dont les organisations peuvent gérer et appliquer l’accès aux données entre les charges de travail. Cette nouvelle infrastructure de sécurité offre aux administrateurs une plus grande flexibilité pour configurer les autorisations. Les administrateurs peuvent choisir entre une gouvernance centralisée via OneLake ou un contrôle SQL granulaire au sein du point de terminaison d’analyse SQL.

Modes d’accès dans le point de terminaison d’analytique SQL

Lorsque vous utilisez le point de terminaison d’analytique SQL, le mode d’accès sélectionné détermine la façon dont la sécurité des données est appliquée. Fabric prend en charge deux modèles d’accès distincts, chacun offrant des avantages différents en fonction de vos besoins opérationnels et de conformité :

• Mode d’identité utilisateur : applique la sécurité à l’aide de rôles et de stratégies OneLake. Dans ce mode, le point de terminaison d’analytique SQL transmet l’identité de l’utilisateur connecté à OneLake et l’accès en lecture est entièrement régi par les règles de sécurité définies dans OneLake. Les autorisations au niveau SQL sur les tables sont prises en charge, ce qui garantit une gouvernance cohérente entre les outils tels que Power BI, les notebooks et lakehouse.

• Mode d’identité déléguée : fournit un contrôle total via SQL. Dans ce mode, le point de terminaison d’analytique SQL se connecte à OneLake à l’aide de l’identité du propriétaire de l’espace de travail ou de l’élément , et la sécurité est régie exclusivement par les autorisations SQL définies dans la base de données. Ce modèle prend en charge les approches de sécurité traditionnelles, notamment GRANT, REVOKE, rôles personnalisés, sécurité Row-Level et masquage dynamique des données.

Chaque mode prend en charge différents modèles de gouvernance. La compréhension de leurs implications est essentielle pour choisir la bonne approche dans votre environnement Fabric.

Comparaison entre les modes d’accès

Voici un tableau de comparaison clair et concis axé sur la façon dont et l’emplacement où vous définissez la sécurité en mode identité utilisateur par rapport au mode d’identité déléguée, divisé par type d’objet et stratégies d’accès aux données :

Mode d’identité utilisateur dans la sécurité OneLake

En mode identité utilisateur, le point de terminaison d’analytique SQL utilise un mécanisme d’authentification directe pour appliquer l’accès aux données. Lorsqu’un utilisateur se connecte au point de terminaison d’analyse SQL, son identité Entra ID est transmise à OneLake, qui effectue la vérification des autorisations. Toutes les opérations de lecture sur les tables sont évaluées à l’aide des règles de sécurité définies dans OneLake Lakehouse, et non par des instructions GRANT ou REVOKE au niveau SQL.

Ce mode vous permet de gérer la sécurité de manière centralisée, en garantissant une mise en œuvre cohérente de toutes les expériences Fabric, notamment Power BI, notebooks, lakehouse et point de terminaison d’analytique SQL. Il est conçu pour les modèles de gouvernance où l’accès doit être défini une fois dans OneLake et respecté automatiquement partout.

En mode d’identité utilisateur :

• L’accès aux tables est entièrement régi par la sécurité OneLake. Les instructions SQL GRANT/REVOKE sur les tables sont ignorées.

• RLS (Row-Level Security), CLS (Column-Level Security) et Object-Level Security sont tous définis dans l’expérience OneLake.

• Les autorisations SQL sont autorisées pour les objets non-data tels que les vues, les procédures stockées et les fonctions, ce qui permet de définir des points d’entrée personnalisés ou orientés utilisateur vers des données.

• Les opérations d’écriture ne sont pas prises en charge sur le point de terminaison d’analytique SQL. Toutes les écritures doivent se produire via l’interface utilisateur Lakehouse et sont régies par les rôles d’espace de travail (Administrateur, Membre, Contributeur).

Comportement du rôle d’espace de travail

Les utilisateurs disposant du rôle Administrateur, Membre ou Contributeur au niveau de l’espace de travail ne sont pas soumis à l’application de la sécurité OneLake. Ces rôles ont des privilèges élevés et contournent entièrement les stratégies RLS, CLS et OLS. Suivez ces exigences pour vous assurer que la sécurité de OneLake est respectée :

• Affecter aux utilisateurs le rôle Visionneuse dans l’espace de travail ou

• Partagez le point de terminaison Lakehouse ou SQL Analytics avec les utilisateurs à l’aide d’autorisations en lecture seule . Seuls les utilisateurs disposant d’un accès en lecture seule ont leurs requêtes filtrées en fonction des rôles de sécurité OneLake.

Priorité des rôles : la plupart des accès permissifs gagnent

Si un utilisateur appartient à plusieurs rôles OneLake, le rôle le plus permissif définit son accès effectif. Par exemple:

• Si un rôle accorde un accès complet à une table et qu’un autre applique RLS pour restreindre les lignes, le SRL ne sera pas appliqué.

• Le rôle d’accès plus large est prioritaire. Ce comportement garantit que les utilisateurs ne sont pas bloqués involontairement, mais qu’il nécessite une conception de rôle minutieuse pour éviter les conflits. Il est recommandé de conserver des rôles restrictifs et permissifs mutuellement exclusifs lors de l’application des contrôles d’accès au niveau des lignes ou des colonnes.

Pour plus d’informations, consultez le modèle de contrôle d’accès aux données pour la sécurité OneLake.

Synchronisation de sécurité entre oneLake et point de terminaison d’analytique SQL

Un composant critique du mode d’identité utilisateur est le service de synchronisation de sécurité. Ce service en arrière-plan surveille les modifications apportées aux rôles de sécurité dans OneLake et garantit que ces modifications sont reflétées dans le point de terminaison d’analyse SQL.

Le service de synchronisation de sécurité est responsable des éléments suivants :

• Détection des modifications apportées aux rôles OneLake, notamment les nouveaux rôles, les mises à jour, les attributions d’utilisateurs et les modifications apportées aux tables.

• Traduction de stratégies définies par OneLake (RLS, CLS, OLS) en structures de rôle de base de données compatibles SQL équivalentes.

• La vérification des objets de raccourci (tables provenant d’autres lakehouses) est correctement validée afin que les paramètres de sécurité OneLake d’origine soient respectés, même lorsqu’ils sont accessibles à distance.

Cette synchronisation garantit que les définitions de sécurité OneLake font autorité, ce qui élimine la nécessité d’une intervention manuelle au niveau SQL pour répliquer le comportement de sécurité. Étant donné que la sécurité est appliquée de manière centralisée :

• Vous ne pouvez pas définir la valeur RLS, CLS ou OLS directement à l’aide de T-SQL dans ce mode.

• Vous pouvez toujours appliquer des autorisations SQL aux vues, fonctions et procédures stockées à l’aide d’instructions GRANT ou EXECUTE.

Erreurs de synchronisation de sécurité et résolution

Comportement des raccourcis avec synchronisation de sécurité

La sécurité OneLake est appliquée à la source de la vérité, de sorte que la synchronisation de sécurité désactive le chaînage des propriétés pour les tables et les vues impliquant des raccourcis. Cela garantit que les autorisations système sources sont toujours évaluées et respectées, même pour les requêtes d’une autre base de données.

Par conséquent :

• Les utilisateurs doivent disposer d’un accès valide à la fois sur la source de raccourci (point de terminaison Current Lakehouse ou SQL Analytics) et sur la destination où résident physiquement les données.

• Si l’utilisateur n’a pas d’autorisation de part et d’autre, les requêtes échouent avec une erreur d’accès.

• Lorsque vous concevez vos applications ou vues qui référencent des raccourcis, vérifiez que les attributions de rôles sont correctement configurées aux deux extrémités de la relation de raccourci.

Cette conception préserve l’intégrité de la sécurité au-delà des limites de Lakehouse, mais elle introduit des scénarios où les échecs d’accès peuvent se produire si les rôles inter-Lakehouse ne sont pas alignés.

Mode délégué dans la sécurité OneLake

En mode d’identité déléguée, le point de terminaison d’analytique SQL utilise le même modèle de sécurité qu’aujourd’hui dans Microsoft Fabric. La sécurité et les autorisations sont entièrement gérées au niveau de la couche SQL, et les rôles OneLake ou les stratégies d’accès ne sont pas appliqués pour l’accès au niveau de la table. Lorsqu’un utilisateur se connecte au point de terminaison d’analytique SQL et émet une requête :

• SQL valide l’accès en fonction des autorisations SQL (GRANT, REVOKE, RLS, CLS, DDM, rôles, etc.).

• Si la requête est autorisée, le système continue d’accéder aux données stockées dans OneLake.

• Cet accès aux données est effectué à l’aide de l’identité du propriétaire du point de terminaison Lakehouse ou SQL Analytics, également appelé compte d’élément.

Dans ce modèle :

• L’utilisateur connecté n’est pas passé à OneLake.

• Toutes les applications d’accès sont supposées être gérées au niveau de la couche SQL.

• Le propriétaire de l’élément est chargé d’avoir suffisamment d’autorisations dans OneLake pour lire les fichiers sous-jacents au nom de la charge de travail.

Étant donné qu’il s’agit d’un modèle délégué, toute erreur d’alignement entre les autorisations SQL et l’accès OneLake pour le propriétaire entraîne des échecs de requête. Ce mode offre une compatibilité complète avec :

• SQL GRANT/REVOKE à tous les niveaux d’objet

• SécuritéRow-Level, sécuritéColumn-Level et masquage des données dynamiques définis par SQL

• Outils et pratiques T-SQL existants utilisés par les administrateurs de base de données ou les applications

Comment modifier le mode d’accès OneLake

Le mode d’accès détermine comment l’accès aux données est authentifié et appliqué lors de l’interrogation de OneLake via le point de terminaison d’analyse SQL. Vous pouvez basculer entre le mode d’identité de l’utilisateur et le mode d’identité délégué en procédant comme suit :

1. Accédez à votre espace de travail Fabric et ouvrez votre lakehouse. En haut à droite, passez du point de terminaison Lakehouse au point de terminaison d’analytique SQL.

2. Dans le volet de navigation supérieur, accédez à l’onglet Sécurité et sélectionnez l’un des modes d’accès OneLake suivants :

   • Identité de l’utilisateur : utilise l’identité de l’utilisateur connecté. Il applique des rôles OneLake.

   • Identité déléguée : utilise l’identité du propriétaire de l’élément ; applique uniquement les autorisations SQL.

3. Une fenêtre contextuelle s’ouvre pour confirmer votre sélection. Sélectionnez Oui pour confirmer la modification.

Considérations relatives au basculement entre les modes

Passage au mode d’identité de l’utilisateur

• Les autorisations sql RLS, CLS et table sont ignorées.

• Les rôles OneLake doivent être configurés pour permettre aux utilisateurs de maintenir l’accès.

• Seuls les utilisateurs disposant d’autorisations de visionneuse ou d’un accès en lecture seule partagé sont régis par la sécurité OneLake.

• Les rôles SQL existants sont supprimés et ne peuvent pas être récupérés.

Passage en mode d’identité déléguée

• Les rôles OneLake et les stratégies de sécurité ne sont plus appliqués.

• Les rôles SQL et les stratégies de sécurité deviennent actifs.

• Le propriétaire de l’élément doit disposer d’un accès OneLake valide, ou toutes les requêtes peuvent échouer.

Limites

• S’applique uniquement aux lecteurs : OneLake Security régit les utilisateurs qui accèdent aux données en tant que visionneuses. Les utilisateurs d’autres rôles d’espace de travail (membre administrateur ou contributeur) contournent OneLake Security et conservent un accès complet.

• Les objets SQL n’héritent pas de propriété : les raccourcis sont exposés dans le point de terminaison d’analyse SQL en tant que tables. Lors de l’accès à ces tables, directement ou via des vues, des procédures stockées et d’autres objets SQL dérivés ne portent pas de propriété au niveau de l’objet ; toutes les autorisations sont vérifiées au moment de l’exécution pour empêcher le contournement de la sécurité.

• Les modifications de raccourci déclenchent un temps d’arrêt de validation : lorsqu’une cible de raccourci change (par exemple, renommer, mettre à jour l’URL), la base de données entre brièvement en mode mono-utilisateur pendant que le système valide la nouvelle cible. Pendant cette période, les requêtes sont bloquées, ces opérations sont assez rapides, mais parfois selon différents processus internes peuvent prendre jusqu’à 5 minutes pour se synchroniser.

  • La création de raccourcis de schéma peut entraîner une erreur connue qui affecte la validation et retarde la synchronisation des métadonnées.

• Propagation différée des autorisations : les modifications d’autorisation ne sont pas instantanées. Le basculement entre les modes de sécurité (identité utilisateur et délégué) peut nécessiter du temps pour se propager avant de prendre effet, mais doit prendre moins de 1 minute.

• Dépendance du plan de contrôle : les autorisations ne peuvent pas être appliquées aux utilisateurs ou groupes qui n’existent pas déjà dans le plan de contrôle de l’espace de travail. Vous devez partager l’élément source ou l’utilisateur doit être membre du rôle d’espace de travail Visionneuse. Notez que le même ID d’objet doit se trouver dans les deux emplacements. Un groupe et un membre de ce groupe ne comptent pas comme correspondance.

• L’accès le plus permissif prévaut : lorsque les utilisateurs appartiennent à plusieurs groupes ou rôles, l’autorisation effective la plus permissive est respectée : si un utilisateur a à la fois REFUSÉ via un rôle et GRANT à l’aide d’un autre, grant est prioritaire.

• Limitations du mode délégué : en mode délégué, la synchronisation des métadonnées sur les tables de raccourcis peut échouer si l’élément source a des stratégies De sécurité OneLake qui n’accordent pas l’accès complet à la table au propriétaire de l’élément.

• Comportement DENY : lorsque plusieurs rôles s’appliquent à une seule table de raccourcis, l’intersection des autorisations suit la sémantique SQL Server : DENY remplace GRANT. Cela peut produire des résultats d’accès inattendus.

• Conditions d’erreur attendues : les utilisateurs peuvent rencontrer des erreurs dans des scénarios tels que :

  • Cible de raccourci renommée ou non valide

    • Exemple : si la source de la table a été supprimée.

  • Configuration incorrecte de RLS (sécuritéRow-Level)

    • Certaines expressions pour le filtrage RLS ne sont pas prises en charge dans OneLake et peuvent autoriser l’accès non autorisé aux données.

    • La suppression de la colonne utilisée sur l’expression de filtre invalide la synchronisation des lignes et des métadonnées sera obsolète jusqu’à ce que le SRLS soit résolu sur le panneau de sécurité OneLake.

    • Pour la préversion publique, nous prenons uniquement en charge les tables d’expression unique. Les RLS dynamiques et les RLS multi-tables ne sont pas pris en charge pour le moment.

  • limitations de Column-Level Security (CLS)

    • CLS fonctionne en conservant une liste verte de colonnes. Si une colonne autorisée est supprimée ou renommée, la stratégie CLS devient non valide.

    • Quand CLS n’est pas valide, la synchronisation des métadonnées est bloquée jusqu’à ce que la règle CLS soit corrigée dans le panneau Sécurité OneLake.

  • Échec de synchronisation des métadonnées ou des autorisations

    • S’il existe des modifications apportées à la table, comme le changement de nom d’une colonne, la sécurité n’est pas répliquée sur le nouvel objet et vous recevez des erreurs d’interface utilisateur montrant que la colonne n’existe pas.

• Les renommages de table ne conservent pas les stratégies de sécurité : si les rôles OneLake Security (OLS) sont définis au niveau du schéma, ces rôles restent en vigueur uniquement tant que le nom de la table n’est pas modifié. Le changement de nom de la table interrompt l’association et les stratégies de sécurité ne seront pas migrées automatiquement. Cela peut entraîner une exposition involontaire des données jusqu’à ce que les stratégies soient réappliquées.

• Les rôles de sécurité OneLake ne peuvent pas avoir de noms de plus de 124 caractères ; sinon, la synchronisation de sécurité ne peut pas synchroniser les rôles.

• Les rôles de sécurité OneLake sont propagés sur le point de terminaison d’analyse SQL avec le préfixe OLS_.

• Les modifications de l’utilisateur sur les rôles OLS_ ne sont pas prises en charge et peuvent entraîner des comportements inattendus.

• Les groupes de sécurité et les listes de distribution activés par courrier ne sont pas pris en charge.

• Le propriétaire du lakehouse doit être membre des rôles d’espace de travail administrateur, membre ou contributeur ; sinon, la sécurité n’est pas appliquée au point de terminaison d’analyse SQL.

• Le propriétaire du lakehouse ne peut pas être un principal de service pour que la synchronisation de sécurité fonctionne.

Contenu connexe

• Meilleures pratiques pour sécuriser les données dans OneLake
• Modèle de contrôle d’accès à la sécurité OneLake