Comment sécuriser les données pour les architectures de données courantes ?
Cet article fournit une vue d’ensemble de la configuration de la sécurité des données OneLake pour les architectures de maillage de données et de réseau en étoile.
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érents types de sécurité abordés dans ce guide pratique, voir Modèle de contrôle d’accès aux données dans OneLake.
Sécurisé pour le maillage de données
Le maillage de données est un paradigme architectural qui traite les données comme un produit, plutôt qu’un service ou une ressource. Le maillage de données vise à décentraliser la propriété et la gouvernance des données entre différents domaines et différentes équipes, tout en permettant l’interopérabilité et la détectabilité via une plateforme commune. Dans une architecture de maillage de données, chaque équipe décentralisée gère la propriété des données qui font partie de leur produit de données. Les conseils de sécurité fournis dans cette section se concentrent sur une seule équipe de produit de données qui configure l’accès pour son espace de travail. Les étapes sont destinées à être répétées par chaque équipe de produit de données sur son propre espace de travail, car elle permet l’accès aux utilisateurs en aval.
Pour commencer à créer un maillage de données, utilisez la fonctionnalité de domaine de Microsoft Fabric pour baliser les espaces de travail en fonction de leur produit de données et de leur propriété associés.
Dans les domaines, chaque équipe a son ou ses espaces de travail propres. L’espace de travail stocke les données nécessaires pour générer les produits de données finaux à des fins de consommation. Accordez aux utilisateurs l’accès à l’espace de travail à l’aide de rôles d’espace de travail.
Identifiez les consommateurs en aval de vos produits de données et accordez l’accès en fonction des autorisations minimales nécessaires pour atteindre leurs objectifs. Pour que les utilisateurs soient alignés sur leurs expériences cible, chaque type d’utilisateur en aval peut recevoir un accès à un seul élément de données Fabric. Le tableau ci-dessous présente certains cas d’usage courants pour les consommateurs de maillage de données et les éléments Fabric appropriés.
| Utilisateur | Éléments Fabric |
|---|---|
| Scientifiques des données | Notebooks Apache Spark ou lakehouse |
| Ingénieurs de données | Notebooks Apache Spark, flux de données ou pipelines |
| Analystes métier | Point de terminaison d’analytique SQL |
| Créateurs de rapports | Modèles sémantiques |
| Consommateurs de rapports | Rapports Power BI |
Sécurisé pour réseau en étoile
Une architecture de réseau en étoile diffère d’un maillage de données en ayant tous les produits de données certifiés gérés dans un emplacement unique et centralisé. Les consommateurs en aval se concentrent moins sur la création de produits de données supplémentaires et effectuent plutôt une analyse sur les données produites par l’équipe centrale.
Identifiez les consommateurs en aval et accordez l’accès en fonction des autorisations minimales nécessaires pour atteindre leurs objectifs. Pour que les utilisateurs soient alignés sur leurs expériences cible, chaque type d’utilisateur en aval peut recevoir un accès à un seul élément de données Fabric. La table de personnage utilisateur présente certains cas d’utilisation courants pour le réseau en étoile, ainsi que les éléments Fabric appropriés.
| Utilisateur | Éléments Fabric |
|---|---|
| Scientifiques des données | Notebooks Apache Spark ou lakehouse |
| Analystes métier | Point de terminaison d’analytique SQL |
| Créateurs de rapports | Modèles sémantiques |
| Consommateurs de rapports | Rapports Power BI |
Rôles d’espace de travail
Les attributions de rôles d’espace de travail suivent les mêmes recommandations pour les architectures de réseau en étoile et de maillage de données. Le tableau responsabilités du travail décrit le rôle d’espace de travail à attribuer aux utilisateurs selon les fonctions qu’ils exécutent dans l’espace de travail.
| Responsabilités du travail | Rôle d’espace de travail |
|---|---|
| Posséder l’espace de travail et gérer les attributions de rôles | Administrateur |
| Gérer les affectations de rôles pour les utilisateurs non administrateurs | Membre |
| Créer des éléments Fabric et écrire des données | Contributeur |
| Créer des tables et des vues avec SQL | Autorisations Visionneuse + SQL |
Scientifiques des données
Les scientifiques des données ont besoin d’accéder aux données d’un lakehouse pour les consommer via Apache Spark. Pour le maillage de données et le réseau en étoile, les utilisateurs Spark consomment des données à partir d’un espace de travail distinct de celui dans lequel résident les données. Cela permet aux scientifiques des données d’avoir accès à la création de modèles et d’expériences sans ajouter d’encombrement à l’espace de travail qui contient les données. Les scientifiques des données peuvent également utiliser d’autres services non-Spark qui se connectent directement aux chemins d’accès aux données OneLake, comme Azure Databricks ou Dremio.
Pour approvisionner l’accès aux scientifiques des données, utilisez le bouton Partager pour partager le lakehouse. Sélectionnez la case Lire tout Apache Spark dans la boîte de dialogue. Pour les lakehouses avec Rôles d’accès aux données OneLake activé, accordez l’accès aux mêmes utilisateurs en les ajoutant à un rôle d’accès aux données OneLake. L’utilisation de rôles d’accès aux données OneLake offre un accès plus précis aux données. Les ingénieurs Données peuvent ensuite créer des raccourcis pour sélectionner des tables ou des dossiers dans un lakehouse.
Ingénieurs de données
Les ingénieurs Données ont besoin d’accéder aux données d’un lakehouse pour générer des produits de données en aval. Les ingénieurs Données ont besoin d’accéder aux données dans OneLake afin que des pipelines ou des notebooks puissent être créés pour lire les données. Dans un véritable modèle de réseau en étoile, le rôle d’ingénieur Données existe uniquement dans les couches de l’équipe hub centrale. Toutefois, pour le maillage de données, les ingénieurs Données combinent des produits de données entre les domaines pour créer d’autres jeux de données.
Utilisez le bouton Partager pour partager le lakehouse avec des ingénieurs de données. Cochez la case Lire tout Apache Spark dans la boîte de dialogue. Pour les lakehouses avec Rôles d’accès aux données OneLake activé, accordez l’accès aux mêmes utilisateurs en les ajoutant à un rôle d’accès aux données OneLake. L’utilisation de rôles d’accès aux données OneLake offre un accès plus précis aux données. Les ingénieurs Données peuvent ensuite créer des raccourcis pour sélectionner des tables ou des dossiers dans un lakehouse.
Analystes métier
Les analystes métier (parfois appelés analystes Données) interrogent les données via SQL pour répondre aux questions métier.
Utilisez le bouton Partager pour partager le lakehouse avec les analystes métier. Cochez la case Lire toutes les données de point de terminaison SQL dans la boîte de dialogue. Ce paramètre donne aux analystes métier l’accès aux données dans le point de terminaison d'analytique SQL d’un Lakehouse, mais pas pour afficher les fichiers OneLake sous-jacents.
L’accès aux données peut être plus restreint pour ces utilisateurs en définissant la sécurité au niveau des lignes ou des colonnes directement dans SQL.
Créateurs de rapports
Les créateurs de rapports créent des rapports Power BI que d’autres utilisateurs peuvent consommer.
Utilisez le bouton Partager pour partager le lakehouse avec les créateurs de rapports. Cochez la case Créer des rapports sur le modèle sémantique par défaut dans la boîte de dialogue. Cette autorisation permet aux créateurs de rapports de générer des rapports à l’aide du modèle sémantique associé au lakehouse. Ces utilisateurs ne peuvent pas accéder aux données dans OneLake ni disposer d’un contrôle total du point de terminaison d'analytique SQL.
Consommateurs de rapports
Les consommateurs de rapports sont les chefs d’entreprise ou les directeurs qui consultent des données dans un rapport Power BI pour prendre des décisions.
Partagez un rapport avec les consommateurs à l’aide du bouton Partager. Ne cochez aucune des cases pour accorder l’accès à la lecture du rapport, mais sans voir les données sous-jacentes. Pour empêcher les utilisateurs d’accéder au point de terminaison d'analytique SQL et d’afficher les tables, assurez-vous qu’aucune autorisation SQL n’est définie pour accorder l’accès à ces utilisateurs.
Vous pouvez également partager des données avec des consommateurs de rapports à l’aide d’une application. Les applications permettent aux utilisateurs d’accéder à un rapport prédéfini ou à un ensemble de rapports sans avoir besoin d’accéder à l’espace de travail sous-jacent. Notez que pour les rapports en mode Direct Lake, il faudra que le lakehouse sous-jacent soit partagé avec les utilisateurs pour qu’ils puissent consulter les données.