Sécurité OneLake pour les endpoints d’analytique SQL

Avec la sécurité OneLake, Microsoft Fabric étend la façon dont les organisations peuvent gérer et appliquer les accès de données à travers les charges de travail. Cette 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 analytique SQL

Lorsque vous utilisez le point de terminaison d’analytique SQL, le mode access sélectionné détermine la façon dont la sécurité des données est appliquée. Fabric prend en charge deux modèles access 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 objets nondata (vues, procédures stockées, fonctions) 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

Le tableau suivant compare comment et 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é d'utilisateur, le point de terminaison d’analytique SQL utilise un mécanisme d’authentification passthrough pour appliquer un 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 des tables sont évaluées à l’aide des règles de sécurité définies dans OneLake Lakehouse, et non par des instructions au niveau SQL GRANT ou REVOKE.

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 seule fois dans OneLake et respecté automatiquement partout.

En mode d’identité utilisateur :

• L'accès à la table est entièrement régi par la sécurité de 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 analytique SQL. Toutes les écritures doivent se produire via la page Lakehouse dans le portail Fabric et sont régies par les rôles d’espace de travail (Administrateur, Membre, Contributeur).

Pour plus d’informations sur le modèle d’autorisations avec le mode d’identité de l’utilisateur, consultez le modèle de contrôle d’accès aux données pour la sécurité OneLake.

Synchronisation de la sécurité entre OneLake et le point de terminaison 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 validation des objets de raccourci (tables provenant d’autres lakehouses) est effectuée correctement 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, aux fonctions et aux procédures stockées à l’aide des instructions GRANT ou EXECUTE.

Délai de reprise de la synchronisation de sécurité

La synchronisation de la sécurité inclut un mécanisme de nouvelle tentative d’interruption pour protéger la stabilité du système et éviter une consommation inutile de calcul :

• Si des erreurs répétées se produisent lors de l’application de rôles de sécurité OneLake au point de terminaison d’analyse SQL, le système peut suspendre temporairement les tentatives de synchronisation automatique.

• La synchronisation reprend automatiquement lorsqu’un rôle de sécurité OneLake existant est modifié ou qu’un nouveau rôle est créé.

Erreurs de synchronisation des paramètres de sécurité et leur 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 avoir des accès valides sur à la fois le raccourci source (Lakehouse actuel ou point de terminaison d'analytique SQL) et la destination où résident physiquement les données.

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

• Lors de la conception d’applications ou de vues qui référencent des raccourcis, assurez-vous 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é à travers les frontières du Lakehouse, mais elle introduit des scénarios où des défaillances d'accès peuvent se produire si les rôles inter-Lakehouse ne sont pas correctement 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 conserve la compatibilité descendante avec le modèle de sécurité SQL traditionnel. La sécurité est définie et appliquée au niveau de la couche moteur SQL, et les rôles de sécurité OneLake et les stratégies d’accès ne sont pas transférés vers l’accès au niveau de la table. Tous les contrôles de filtrage et d’accès( y compris l’accès aux schémas et aux tables, Row-Level Sécurité (RLS), CLS (Column-Level Security) et Dynamic Data Masking (DDM) doivent être définis à l’aide de constructions SQL (GRANT/REVOKEstratégies de sécurité, etc.).

Étant donné que les rôles de sécurité OneLake pour l’utilisateur final ne sont pas appliqués directement, les règles de sécurité définies dans OneLake (par exemple, les règles appliquées par Spark ou d’autres moteurs qui lisent via OneLake) ne s’appliquent pas lorsque les mêmes données sont interrogées via le point de terminaison d’analyse SQL. Choisissez ce mode lorsque la charge de travail dépend de la sémantique de sécurité native SQL ou lorsque les outils T-SQL existants nécessitent une compatibilité totale.

Lorsqu’un utilisateur se connecte au point de terminaison d’analytique SQL et émet une requête :

• SQL valide la requête par rapport aux autorisations définies au niveau de la couche SQL.

• Si la requête est autorisée, le système passe à access 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, et non de l’utilisateur connecté.

Le propriétaire de l’élément est donc responsable de disposer d’autorisations suffisantes dans OneLake pour lire les fichiers sous-jacents au nom de la charge de travail. Toute incompatibilité entre les autorisations SQL accordées aux utilisateurs finaux et l’accès OneLake du propriétaire de l’élément entraîne des échecs de requête.

Ce mode prend en charge les outils et pratiques T-SQL existants utilisés par les administrateurs de bases de données ou les applications, avec une compatibilité totale pour SQL GRANT/REVOKE sur tous les niveaux d’objets et RLS, CLS et DDM définis par SQL.

Comportement des raccourcis en mode délégué

Étant donné que le mode délégué se connecte à OneLake à l’aide de l’identité du propriétaire de l’élément, les raccourcis fonctionnent uniquement lorsque le propriétaire a un accès illimité à l’ensemble de la table source. Si la table source a une règle de sécurité de niveau OneLake appliquée, telle que Row-Level Sécurité (RLS), Column-Level Sécurité (CLS), le point de terminaison d’analyse SQL bloque l’accès à ce raccourci.

Par conséquent :

• Les raccourcis pointant vers des tables sources sans règles de sécurité au niveau des données fonctionnent normalement en mode délégué.

• Les raccourcis pointant vers des tables sources avec RLS ou CLS dans la sécurité OneLake sur le producteur ne sont pas accessibles via le point de terminaison d’analyse SQL en mode délégué, même si l’utilisateur final dispose d’autorisations SQL sur l’objet de raccourci.

• Pour utiliser des raccourcis dont la source possède des stratégies de sécurité OneLake, utilisez le mode d’identité utilisateur sur le point de terminaison du consommateur afin que l’identité de l’utilisateur final soit évaluée par rapport aux règles de sécurité OneLake de la source.

Comment modifier le mode access 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. Dans le coin supérieur droit, passez du Lakehouse au point de terminaison d'analyse SQL.

2. Dans la navigation supérieure, 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é. 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 les permissions au niveau des tables 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’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 avoir un access OneLake valide, ou toutes les requêtes peuvent échouer.

Remarques

• Les objets SQL n’héritent pas de propriété : les raccourcis fonctionnent en tant que tables dans le point de terminaison d’analyse SQL, mais s’écartent intentionnellement du chaînage de propriétés SQL standard pour maintenir une posture de sécurité unifiée.

  • Règle de non-héritage Les objets SQL dérivés (vues, procédures stockées ou fonctions) n'héritent pas des autorisations par le propriétaire de l'objet.

  • Validation du runtime : les autorisations sont vérifiées par rapport à l’identité de l’appelant au moment de l’exécution, ce qui garantit que les abstractions SQL ne peuvent pas contourner les stratégies de niveau OneLake.

  • Security par conception : les stratégies de sécurité restent cohérentes si les données sont accessibles via SQL, Spark ou Power BI.

• Dépendance du plan de contrôle (correspondance d’identité stricte) : La sécurité OneLake exige que l’identité accordée au producteur soit la même identité reconnue lors de l’évaluation de l’accès au plan de données consommateur. Le système valide le principal spécifique auquel l'accès a été accordé à la source et n'étend pas l'appartenance aux groupes imbriqués ni ne déduit l'accès effectif par une appartenance indirecte.

  • Correspondance du principal littéral : Access est évalué par rapport à l’ID d’objet exact accordé au producteur.

  • Aucune résolution imbriquée/efficace : l’appartenance à un groupe imbriqué ou l’héritage indirect n’est pas traité comme suffisant pour l’application. Consultez la légende en mode Identité utilisateur dans la sécurité OneLake pour obtenir un exemple concret.

• Comportement d’évaluation des autorisations : l’évaluation des autorisations varie selon le type de table en fonction du modèle d’application actuel.

  • Tables de raccourcis : l’accès peut être refusé lorsque les conditions d’autorisation requises ne sont pas satisfaites. Il s’agit d’un résultat d’application restrictif, et non d’une fonctionnalité DENY basée sur les rôles dans la sécurité OneLake.

  • Règle générale : lorsque le contrôle ne peut pas valider clairement l’accès, le système applique la mesure la plus restrictive.

• Conception de la sécurité au niveau des colonnes (CLS) : CLS conserve une liste d'autorisation stricte de colonnes.

  • Le changement de nom ou la suppression d’une colonne autorisée invalide la règle de sécurité. Bien que la règle persiste dans le système, elle reste inactive, refusant tout accès à la ressource, jusqu’à ce que le nommage de colonne d’origine soit restitué.

  • Protection de la synchronisation : lorsqu’une stratégie n’est pas valide, la synchronisation des métadonnées est bloquée par conception jusqu’à ce que la règle soit corrigée dans le panneau de sécurité OneLake.

  • Validation du schéma : le changement de nom des colonnes sans mise à jour des stratégies de sécurité déclenche des erreurs d’interface utilisateur indiquant que la colonne « n’existe pas » tant que la configuration n’est pas synchronisée.

• Propagation et synchronisation des rôles (SLA) :

  • Synchronisation de sécurité OneLake : lorsqu’un rôle de sécurité OneLake change en mode d’identité utilisateur, la mise à jour n’est pas immédiate. Bien qu’il soit généralement rapide, il peut prendre jusqu’à 5 minutes pour se synchroniser avec le point de terminaison d’analyse SQL.

  • Préfixe automatique : les rôles de sécurité OneLake sont propagés au point de terminaison d’analyse SQL avec le préfixe OLS_.

  • Priorité de synchronisation : le processus de synchronisation de sécurité actualise régulièrement l’état des OLS_ rôles. Les modifications manuelles apportées à ces rôles ne sont pas prises en charge et sont remplacées pendant le prochain cycle de synchronisation. Si aucune modification n’est apportée à la synchronisation, la synchronisation de sécurité ne remplace pas les modifications manuelles.

• Sécurité et raccourcis SQL de l’entrepôt : les stratégies de sécurité définies à l’aide de constructions SQL dans un entrepôt, telles que Row-Level Security (RLS), Column-Level Security (CLS) ou Object-Level Security (OLS) sont appliquées uniquement dans le contexte d’exécution SQL de l’entrepôt (point de terminaison TDS).

Limites

• S’applique uniquement aux lecteurs : la sécurité OneLake est principalement appliquée aux utilisateurs qui accèdent aux données via l’espace de travail au niveau de la visionneuse ou l’accès aux éléments. Les utilisateurs disposant de rôles d’espace de travail plus larges tels que l’administrateur, le membre ou le contributeur conservent un accès élevé et ne sont pas la cible principale de l’application de la sécurité OneLake.

  • Exceptions :

    • Comportement de refus des raccourcis : pour les tables basées sur un raccourci, le contrôle peut toujours refuser l’accès aux administrateurs, aux membres ou aux contributeurs dans des cas spécifiques.

    • Cas d’échec de la synchronisation de la sécurité : si la synchronisation de sécurité ne parvient pas à appliquer la sécurité correctement pour certaines tables ou rôles, les utilisateurs des rôles Administrateur, Membre ou Contributeur qui sont membres de ces rôles concernés peuvent également rencontrer un accès restreint.

    • RLS en mode identité utilisateur : lorsque Row-Level Sécurité (RLS) est configuré en mode identité utilisateur, les règles de sécurité définies sont appliquées pour tous les utilisateurs, y compris ceux dans les rôles Administrateur, Membre et Contributeur.

• Dépendance de synchronisation de la sécurité : en mode identité utilisateur, les rôles de sécurité OneLake sont synchronisés avec le point de terminaison d’analyse SQL via le processus de synchronisation de la sécurité. Tant que la synchronisation n’est pas terminée, SQL peut évaluer temporairement l’accès à l’aide de l’état d’autorisation SQL existant. Une fois la synchronisation terminée, le point de terminaison SQL reflète la configuration de sécurité OneLake.

• Sensibilité aux limites des raccourcis : le point de terminaison d'analyse SQL peut initialement évaluer les tables soutenues par des raccourcis à l'aide de la sémantique d'objet SQL standard. Une fois la synchronisation de sécurité effectuée, les stratégies de sécurité OneLake sont appliquées pour s’assurer que l'application des règles d'accès soit conforme aux limites d’artéfact et d’espace de travail.

• Chronométrage de l'application de l'accès entre artefacts : l'accès aux tables soutenues par les raccourcis OneLake qui font référence aux données d'autres artefacts est assuré via des rôles de sécurité OneLake synchronisés. Tant que la synchronisation ne se produit pas, l’autorisation SQL peut refléter temporairement l’état d’autorisation précédent.

• Modifications de propriété sur les tables avec raccourcis : les tables sauvegardées par raccourci sont représentées en tant qu’objets SQL dans le point de terminaison d’analyse SQL et prennent donc en charge les opérations de propriété SQL standard. Les commandes d’administration telles que ALTER AUTHORIZATION peuvent modifier le propriétaire d’une table avec raccourci. Dans certains scénarios, cela peut autoriser le comportement de chaînage de propriétés qui contourne les stratégies de sécurité OneLake et accorde un accès inattendu aux données sous-jacentes. Tant que des moyens d'application supplémentaires ne sont pas introduits, les administrateurs doivent éviter de modifier la propriété sur les tables basées sur des raccourcis.

• Temps d’arrêt de validation cible : lorsqu’une cible de raccourci change (par exemple, renommer ou 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 généralement rapides, mais, selon les 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.

• Mise en cache des jetons en mode délégué : en mode délégué, le point de terminaison d’analyse SQL met en cache le jeton d’accès de stockage utilisé pour récupérer des données à partir de OneLake pour le compte de l’identité du propriétaire. Si les autorisations du propriétaire changent, un jeton précédemment émis peut rester valide jusqu’à son expiration. Par conséquent, les modifications d’accès liées à l’identité du propriétaire peuvent ne pas prendre effet immédiatement et peuvent persister jusqu’à l’expiration du jeton, généralement jusqu’à 30 à 60 minutes.

• Les modifications apportées aux stratégies GRANT/DENY de sécurité OneLake sont appliquées immédiatement et ne sont pas retardées par la mise en cache des jetons de stockage.

• Annulation de requête active : pour maintenir l’intégrité et la sécurité des données, les requêtes actives peuvent être automatiquement annulées si une configuration de raccourci change pendant l’exécution.

• Contraintes de sécurité au niveau des lignes (RLS) :

  • Pour l'Aperçu Public, seules les tables à expression unique sont prises en charge. Les RLS dynamiques et les RLS multi-tables ne sont pas disponibles.

  • La suppression d’une colonne utilisée dans une expression de filtre bloque la synchronisation des métadonnées jusqu’à ce que le RLS soit rétabli dans le panneau de sécurité OneLake.

• Synchronisation des rôles et des métadonnées : une complexité élevée dans les rôles de sécurité, en particulier celles impliquant de nombreuses intersections et sémantiques d’union à l’aide de la SNL, peut entraîner l’échec de la synchronisation de la sécurité. Une synchronisation de sécurité ayant échoué empêche l’application des stratégies de sécurité et bloque la possibilité de synchroniser les métadonnées.

• Contraintes de schéma et de rôle :

  • Renommer: les rôles de sécurité OneLake sont liés au nom de la table. Le changement de nom d’une table interrompt l’association et les stratégies ne migrent pas automatiquement. Cela peut entraîner une exposition involontaire des données jusqu’à ce que les stratégies soient réappliquées.

  • Limites de caractères : les noms de rôles de sécurité OneLake ne peuvent pas dépasser 124 caractères ; sinon, la création ou la synchronisation de rôles échoue sur le point de terminaison d’analyse SQL.

  • OLS_ modifications de rôle : les modifications des utilisateurs sur OLS_ les rôles ne sont pas prises en charge et peuvent entraîner des comportements inattendus.

• Identités non prises en charge : les groupes de sécurité et les listes de distribution prenant en charge les messages ne sont actuellement pas pris en charge.

• Exigences pour le propriétaire de lakehouse :

  • 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 de sécurité OneLake