Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Microsoft Fabric prend en charge des scénarios multi-espaces de travail tels que le hub de données, les favoris, la traçabilité, la recherche, le catalogue OneLake et d’autres fonctionnalités de gouvernance et de découverte via des API multi-espaces de travail. Ces API permettent aux utilisateurs d’accéder aux métadonnées légères à partir de plusieurs espaces de travail auxquels ils peuvent accéder en dehors des configurations réseau des espaces de travail. Les API prennent en charge la recherche unifiée, l’organisation et la navigation sur la plateforme sans exposer le contenu des données sous-jacentes.
Les API multi-espaces de travail ne sont pas toujours exposées en tant que points de terminaison REST autonomes. Dans de nombreux cas, ces API sont appelées indirectement. Par exemple, ils peuvent être appelés dans le cadre d’un appel REST plus large, d’un processus en arrière-plan ou d’une opération de portail (par exemple, le chargement d’une page dans l’interface utilisateur Fabric). Quelle que soit la façon dont ils sont déclenchés, ils sont soigneusement délimités pour s’assurer qu’ils retournent uniquement les métadonnées auxquelles un utilisateur est autorisé à accéder.
Catégories d’API multi-espaces de travail
Les API multi-espaces de travail se trouvent dans les deux catégories suivantes. Chacun sert des scénarios spécifiques et applique le contrôle d’accès de différentes manières.
API à multiples espaces de travail en lecture seule et non filtrées
- Conçu pour retourner des métadonnées dans tous les espaces de travail accessibles pour l’utilisateur.
- N’appliquez pas de restrictions d’accès basées sur le réseau.
- En lecture seule par conception et pas supporté sur les connexions de points de terminaison privés de l’espace de travail.
- Généralement utilisé dans des scénarios d’agrégation globaux tels que l’indexation à l’échelle de la plateforme ou le catalogage.
API multi-espaces de travail filtrées
- Appliquez le contrôle d’accès en fonction de l’origine réseau de la demande d’API.
- Prise en charge de l’utilisation sécurisée à partir d’un lien privé d’espace de travail, d’un lien privé du locataire et de configurations de réseau public.
- Retournez les métadonnées uniquement pour les espaces de travail accessibles en fonction du contexte réseau de la requête.
Ces API prennent en charge l’agrégation de métadonnées à grande échelle et sont classées en fonction de la façon dont elles gèrent le contrôle d’accès et la sécurité réseau. Le tableau suivant résume la façon dont différents types d’API dans un environnement multi-espace de travail retournent des métadonnées en fonction du type de connexion réseau.
| Type d’API multi-espaces de travail | Connexion réseau entrante | Métadonnées retournées |
|---|---|---|
| Lecture seule, non filtrée | Internet public, point de terminaison privé du locataire | Tous les espaces de travail auxquels l’utilisateur peut accéder |
| Filtré | Internet public, point de terminaison privé du locataire | Espaces de travail non sécurisés via un point de terminaison privé de l'espace de travail |
| Filtré | Point de terminaison privé de l’espace de travail | Seul l’espace de travail associé à ce point de terminaison privé de l’espace de travail |
Exemple de scénario
Supposons qu’un utilisateur a accès à cinq espaces de travail Fabric :
- L’espace de travail 1 et l’espace de travail 2 sont sécurisés avec les points de terminaison privés de l’espace de travail WSPE 1 et WSPE 2, respectivement.
- Les espaces de travail 3, 4 et 5 sont accessibles via un réseau public ou une liaison privée de locataire.
Dans cet exemple de scénario, l’utilisateur souhaite appeler l’API Get Workspace sur différentes configurations réseau. L’API Get Workspace est une API d’agrégation non filtrée en lecture seule qui permet aux utilisateurs de récupérer des métadonnées sur tous les espaces de travail auxquels ils peuvent accéder. Le comportement de cette API peut changer (ou rester cohérent) entre les configurations réseau dans Microsoft Fabric.
Lorsque l’utilisateur appelle l’API Get Workspace (non filtrée) :
- À partir d’un réseau public : l’API retourne les cinq espaces de travail. Aucune restriction réseau n’est appliquée et l’accès est basé uniquement sur les autorisations utilisateur.
- Dans le cas d'une liaison privée de locataire : le comportement est identique à celui d’un réseau public. Les cinq espaces de travail sont retournés. Une liaison privée de locataire n’impose pas de restrictions au niveau de l’espace de travail sur les API non filtrées.
- À partir d’un point de terminaison privé d’espace de travail : l’appel d’API échoue. Les API non filtrées ne sont pas prises en charge via une liaison privée d’espace de travail, car ces réseaux isolés sont conçus pour empêcher l’exposition des données entre espaces de travail.
Ce scénario montre comment les API d’agrégation non filtrées se comportent de manière cohérente sur les réseaux ouverts, mais sont intentionnellement bloquées dans des environnements privés délimités à l’espace de travail pour la sécurité.
Données en envergure et usage
-
Autorisations, propriété et informations de créateur : métadonnées qui incluent des champs qui identifient qui possède ou gère l’élément, qui l’a créé ou le dernier modifié, ainsi que le niveau d’accès dont disposent différents principaux. Exemples :
Artifact.CurrentPrincipalPermissions,Artifact.OwnerOrContact,Workspace.PrincipalPermissionsetWorkspace.OwnerOrContact. -
Informations d’accès et de modification : métadonnées qui capturent quand et par qui un élément ou un espace de travail a été créé, dernier accès ou modifié. Les exemples incluent
Artifact.CreateAccessModifyTime, ,Artifact.CreateAccessModifyUserWorkspace.CreateAccessModifyTimeet les champs connexes sousJobScheduleetInformationProtection. -
Identificateurs, types et attributs descriptifs : métadonnées qui couvrent des identificateurs uniques, des noms d’affichage, des types d’artefacts, des informations de connexion et des URL pour localiser ou classifier des éléments. Les champs peuvent inclure
Artifact.Id, ,Artifact.TypeOrSubtypeArtifact.NameOrDisplayName,Artifact.UrlOrConnectionString,Workspace.TypeOrSubtypeetWorkspace.NameOrDisplayName. -
Classification des données, étiquetage et balises : métadonnées qui incluent des champs utilisés à des fins de gouvernance et de conformité, tels que des étiquettes de protection des informations, des états de classification, des étiquettes de contenu et des restrictions de sécurité. Exemples :
Artifact.ContentTag,Artifact.InformationProtection.StateOrStatus,Artifact.InformationProtection.RestrictionsetTenant.MipLabel. -
Attributs au niveau de l’organisation et de la plateforme : métadonnées qui reflètent l’emplacement où réside l’élément dans l’ensemble de la plateforme ou de la structure de locataire, notamment les métadonnées de domaine, de capacité, de région et de plateforme. Les champs peuvent inclure
Tenant.Domain, ,Tenant.CapacityWorkspace.StorageInfoetWorkspace.SecuritySettings. -
Relations et hiérarchies : métadonnées qui indiquent la relation entre un élément ou un espace de travail et d’autres objets (relations parent/enfant, sous-objets, traçabilité des travaux et entités groupées). Il peut inclure des champs tels que
Artifact.RelationToArtifactParentChild, ,Artifact.SubArtifactWorkspace.RelationToWorkspaceParentChild,Workspace.Subfolder, etTenant.Group.
Cet accès aux métadonnées est en lecture seule et est limité dans l’étendue. Il n’implique pas l’accès au contenu de données sous-jacent ou aux charges utiles générées par l’utilisateur dans les artefacts. Il est destiné à prendre en charge les fonctionnalités de découverte et de gouvernance centralisées dans les expériences Fabric.