Comment sécuriser un lakehouse pour les équipes Entrepôt de données
Introduction
Dans cet article, nous présentons une vue d’ensemble de la configuration de la sécurité d’un lakehouse dans Fabric pour une utilisation par des utilisateurs SQL avec des requêtes T-SQL. Ces utilisateurs peuvent être des analystes métier qui consomment des données via SQL, des générateurs de rapports ou des ingénieurs données créant de nouvelles tables et vues.
Fonctionnalités de sécurité
Microsoft Fabric utilise un modèle de sécurité multicouche avec différents contrôles disponibles à différents niveaux afin de fournir uniquement les autorisations minimales nécessaires. Pour plus d’informations sur les différentes fonctions de sécurité disponibles dans Fabric, consultez Modèle de contrôle d’accès aux données dans OneLake.
Dans la charge de travail Synapse Data Warehouse, les éléments entrepôt et point de terminaison d’analytique SQL permettent également de définir la sécurité SQL native. La sécurité SQL utilise la bibliothèque complète de constructions de sécurité T-SQL pour permettre un contrôle d’accès granulaire des tables, vues, lignes et colonnes au sein d’un élément. Pour plus d’informations sur la sécurité SQL, consultez Autorisations granulaires SQL.
Les autorisations SQL configurées dans l’entrepôt ou le point de terminaison d’analytique SQL s’appliquent uniquement aux requêtes exécutées sur l’entrepôt ou le point de terminaison d’analytique SQL. Les données sous-jacentes se trouvent dans OneLake, mais l’accès aux données OneLake est contrôlé séparément par les rôles d’accès aux données OneLake. Pour vous assurer que les utilisateurs disposant d’autorisations SQL spécifiques ne voient pas les données auxquelles ils n’ont pas un accès SQL, n’incluez pas ces utilisateurs dans un rôle d’accès aux données OneLake.
Sécuriser par cas d’utilisation
La sécurité dans Microsoft Fabric est optimisée autour de la sécurisation des données pour des cas d’utilisation spécifiques. Un cas d'utilisation est un ensemble d’utilisateurs qui ont besoin d’un accès spécifique et d’accès aux données via un moteur donné. Pour les scénarios SQL, les cas d'utilisation les plus courants sont les suivants :
- Enregistreurs SQL : utilisateurs qui doivent créer de nouvelles tables, afficher ou écrire des données dans des tables existantes.
- Lecteurs SQL : utilisateurs qui doivent lire des données à l’aide de requêtes SQL. Ils peuvent accéder directement à la connexion SQL ou via un autre service comme Power BI.
Nous pouvons ensuite aligner chaque cas d’utilisation avec les autorisations nécessaires dans Fabric.
Accès en écriture SQL
Il existe deux façons d’accorder à un utilisateur un accès en écriture à un entrepôt ou à un point de terminaison d’analytique SQL :
- Grâce aux rôles d’espace de travail Fabric, vous pouvez accorder un abonnement à trois rôles d’espace de travail accordant des autorisations d’accès en écriture. Chaque rôle se traduit automatiquement par un rôle correspondant dans SQL qui accorde un accès en écriture équivalent.
- Accordez un accès en lecture au moteur SQL et accordez des autorisations SQL personnalisées pour écrire sur une partie ou toutes les données.
Si un utilisateur a besoin d’un accès en écriture à tous les entrepôts ou à tous les points de terminaison d’analytique SQL d’un espace de travail, attribuez-lui un rôle d’espace de travail. Sauf si un utilisateur doit attribuer d’autres utilisateurs aux rôles d’espace de travail, le rôle Contributeur doit être utilisé.
Si un utilisateur doit uniquement écrire dans des entrepôts ou des analytiques SQL spécifiques, accordez-lui un accès direct via les autorisations SQL.
Accès en lecture SQL
Il existe deux façons d’accorder à un utilisateur un accès en lecture à un entrepôt ou à un point de terminaison d’analytique SQL :
- Accordez l’accès en lecture via l’autorisation ReadData, accordée dans le cadre des rôles d’espace de travail Fabric. Les quatre rôles d’espace de travail accordent l’autorisation ReadData.
- Accordez un accès en lecture au moteur SQL et accordez des autorisations SQL personnalisées pour lire une partie ou toutes les données.
Si un utilisateur est membre d’un rôle d’espace de travail Fabric, il reçoit l’autorisation ReadData. L'autorisation ReadData associe l'utilisateur à un rôle SQL qui lui donne des autorisations SELECT sur toutes les tables de l'entrepôt ou du lakehouse. Cette autorisation est utile si un utilisateur doit voir toutes ou la plupart des données dans le lakehouse ou l’entrepôt. Toutes les autorisations DENY SQL définies pour un lakehouse ou un entrepôt particulier s’appliquent toujours et limitent l’accès aux tables. En outre, la sécurité au niveau des lignes et des colonnes peut être définie sur les tables pour restreindre l’accès à un niveau granulaire.
Si un utilisateur a uniquement besoin d’accéder à un lac ou un entrepôt spécifique, la fonctionnalité de partage fournit l’accès uniquement à l’élément partagé. Pendant le partage, les utilisateurs peuvent choisir d’accorder uniquement l’autorisation d'accès en lecture ou Lecture + ReadData. L’autorisation d’accès en lecture permet à l’utilisateur de se connecter à l’entrepôt ou au point de terminaison d’analytique SQL, mais ne lui permet pas d’accéder à la table. En accordant aux utilisateurs les autorisations ReadData, ils bénéficient d’un accès complet en lecture à toutes les tables de l’entrepôt ou du point de terminaison d’analytique SQL. Dans les deux cas, une sécurité SQL supplémentaire peut être configurée pour accorder ou refuser l’accès à des tables spécifiques. Cette sécurité SQL peut inclure un contrôle d’accès granulaire tel que la sécurité au niveau des lignes ou des colonnes.
Utiliser avec des raccourcis
Les raccourcis sont une fonctionnalité OneLake qui permet aux données d’être référencées à partir d’un emplacement sans les copier physiquement. Les raccourcis sont un outil puissant qui permet aux données d’un lakehouse d’être facilement réutilisés dans d’autres emplacements sans effectuer de copies en double des données.
Les entrepôts dans Fabric ne prennent pas en charge les raccourcis. Toutefois, il existe un comportement spécial concernant la manière dont le point de terminaison d’analytique SQL d’un lakehouse interagit avec les raccourcis.
Tous les raccourcis d’un lakehouse sont accédés en mode délégué lors d’une interrogation via le point de terminaison d’analytique SQL. L’identité déléguée est l’utilisateur Fabric propriétaire du lakehouse. Par défaut, le propriétaire est l’utilisateur qui a créé le point de terminaison lakehouse et d’analytique SQL. Le propriétaire peut être modifié dans les cas de sélection et le propriétaire actuel s’affiche dans la colonne Propriétaire dans Fabric lors de l’affichage de l’élément dans la liste d’éléments de l’espace de travail. Le comportement délégué signifie qu’un utilisateur interrogeant peut lire à partir de tables de raccourcis si le propriétaire a accès aux données sous-jacentes, et non à l’utilisateur qui exécute la requête. L’utilisateur qui interroge n’a besoin d’accéder qu’à partir de la table de raccourcis.
Remarque
Par exemple, UserA est le propriétaire d’un lakehouse et UserB exécute une requête sur une table qui est un raccourci. UserB doit d’abord disposer d’un accès en lecture sur la table, qu’il s’agisse d’autorisations ReadData ou SQL. Pour consulter les données, la requête vérifie ensuite si l'utilisateur A a accès au raccourci. Si UserA a accès, UserB voit les résultats de la requête. Si UserA n’a pas accès, la requête échoue.
Pour les lakehouses utilisant la fonctionnalité de rôles d’accès aux données OneLake, l’accès à un raccourci est déterminé par le fait que le propriétaire du point de terminaison d’analytique SQL dispose d’un accès lui permettant d’afficher le lakehouse cible et de lire la table via un rôle d’accès aux données OneLake.
Pour les lakehouses n’utilisant pas encore la fonctionnalité de rôles d’accès aux données OneLake, l’accès aux raccourcis est déterminé par le fait que le propriétaire du point de terminaison d’analytique SQL dispose des autorisations Read et ReadAll sur le chemin d’accès à la cible.