Architecture réseau Microsoft Purview et meilleures pratiques

Les solutions de gouvernance des données Microsoft Purview sont des solutions PaaS (Platform as a Service) pour la gouvernance des données. Les comptes Microsoft Purview ont des points de terminaison publics accessibles via Internet pour se connecter au service. Toutefois, tous les points de terminaison sont sécurisés par le biais de connexions Azure Active Directory (Azure AD) et du contrôle d’accès en fonction du rôle (RBAC).

Remarque

Ces meilleures pratiques couvrent l’architecture réseau des solutions de gouvernance des données unifiées Microsoft Purview. Pour plus d’informations sur les solutions de conformité et de risque Microsoft Purview, accédez ici. Pour plus d’informations sur Microsoft Purview en général, accédez ici.

Pour une couche de sécurité supplémentaire, vous pouvez créer des points de terminaison privés pour votre compte Microsoft Purview. Vous obtiendrez une adresse IP privée de votre réseau virtuel dans Azure vers le compte Microsoft Purview et ses ressources managées. Cette adresse limite tout le trafic entre votre réseau virtuel et le compte Microsoft Purview vers une liaison privée pour l’interaction de l’utilisateur avec les API et le portail de gouvernance Microsoft Purview, ou pour l’analyse et l’ingestion.

Actuellement, le pare-feu Microsoft Purview fournit un contrôle d’accès pour le point de terminaison public de votre compte Purview. Vous pouvez utiliser le pare-feu pour autoriser tous les accès ou pour bloquer tous les accès via le point de terminaison public lors de l’utilisation de points de terminaison privés. Pour plus d’informations, consultez Options de pare-feu Microsoft Purview

En fonction de vos exigences en matière de réseau, de connectivité et de sécurité, vous pouvez configurer et gérer des comptes Microsoft Purview pour accéder aux services sous-jacents ou à l’ingestion. Utilisez ce guide de bonnes pratiques pour définir et préparer votre environnement réseau afin de pouvoir accéder à Microsoft Purview et analyser les sources de données à partir de votre réseau ou cloud.

Ce guide couvre les options réseau suivantes :

• Utilisez des points de terminaison publics Azure.
• Utilisez des points de terminaison privés.
• Utilisez des points de terminaison privés et autorisez l’accès public sur le même compte Microsoft Purview.
• Utilisez des points de terminaison publics Azure pour accéder au portail de gouvernance Microsoft Purview et aux points de terminaison privés pour l’ingestion.

Ce guide décrit quelques-uns des scénarios d’architecture réseau les plus courants pour Microsoft Purview. Bien que vous ne soyez pas limité à ces scénarios, gardez à l’esprit les limitations du service lorsque vous planifiez la mise en réseau pour vos comptes Microsoft Purview.

Configuration requise

Pour comprendre quelle option réseau convient le mieux à votre environnement, nous vous suggérons d’effectuer d’abord les actions suivantes :

• Passez en revue les exigences en matière de topologie et de sécurité de votre réseau avant d’inscrire et d’analyser les sources de données dans Microsoft Purview. Pour plus d’informations, consultez Définir une topologie de réseau Azure.

• Définissez votre modèle de connectivité réseau pour les services PaaS.

Option 1 : Utiliser des points de terminaison publics

Par défaut, vous pouvez utiliser des comptes Microsoft Purview via les points de terminaison publics accessibles sur Internet. Autorisez les réseaux publics dans votre compte Microsoft Purview si vous avez les exigences suivantes :

• Aucune connectivité privée n’est requise lors de l’analyse ou de la connexion aux points de terminaison Microsoft Purview.
• Toutes les sources de données sont des applications SaaS (Software-as-a-Service) uniquement.
• Toutes les sources de données ont un point de terminaison public accessible via Internet.
• Les utilisateurs professionnels ont besoin d’accéder à un compte Microsoft Purview et au portail de gouvernance Microsoft Purview via Internet.

Options du runtime d’intégration

Pour analyser les sources de données alors que le pare-feu de compte Microsoft Purview est configuré pour autoriser l’accès public, vous pouvez utiliser à la fois le runtime d’intégration Azure et un runtime d’intégration auto-hébergé. La façon dont vous les utilisez dépend de la prise en charge de vos sources de données.

Voici quelques bonnes pratiques :

• Vous pouvez utiliser le runtime d’intégration Azure ou un runtime d’intégration auto-hébergé pour analyser les sources de données Azure telles que Azure SQL Database ou Stockage Blob Azure, mais nous vous recommandons d’utiliser le runtime d’intégration Azure pour analyser les sources de données Azure dans la mesure du possible, afin de réduire les coûts et la surcharge administrative.

• Pour analyser plusieurs sources de données Azure, utilisez un réseau public et le runtime d’intégration Azure. Les étapes suivantes montrent le flux de communication à un niveau élevé lorsque vous utilisez le runtime d’intégration Azure pour analyser une source de données dans Azure :

  

  1. Une analyse manuelle ou automatique est lancée à partir du Mappage de données Microsoft Purview via le runtime d’intégration Azure.

  2. Le runtime d’intégration Azure se connecte à la source de données pour extraire les métadonnées.

  3. Les métadonnées sont mises en file d’attente dans le stockage managé Microsoft Purview et stockées dans Stockage Blob Azure.

  4. Les métadonnées sont envoyées au Mappage de données Microsoft Purview.

• L’analyse des sources de données locales et basées sur des machines virtuelles nécessite toujours l’utilisation d’un runtime d’intégration auto-hébergé. Le runtime d’intégration Azure n’est pas pris en charge pour ces sources de données. Les étapes suivantes montrent le flux de communication à un niveau élevé lorsque vous utilisez un runtime d’intégration auto-hébergé pour analyser une source de données. Le premier diagramme montre un scénario où les ressources se trouvent dans Azure ou sur une machine virtuelle dans Azure. Le deuxième diagramme montre un scénario avec des ressources locales. Les étapes entre les deux sont les mêmes du point de vue de Microsoft Purview :

  

  

  1. Une analyse manuelle ou automatique est déclenchée. Microsoft Purview se connecte à Azure Key Vault pour récupérer les informations d’identification pour accéder à une source de données.

  2. L’analyse est lancée à partir du Mappage de données Microsoft Purview par le biais d’un runtime d’intégration auto-hébergé.

  3. Le service runtime d’intégration auto-hébergé à partir de la machine virtuelle ou de l’ordinateur local se connecte à la source de données pour extraire les métadonnées.

  4. Les métadonnées sont traitées dans la mémoire de la machine pour le runtime d’intégration auto-hébergé. Les métadonnées sont mises en file d’attente dans le stockage managé Microsoft Purview, puis stockées dans Stockage Blob Azure. Les données réelles ne quittent jamais la limite de votre réseau.

  5. Les métadonnées sont envoyées au Mappage de données Microsoft Purview.

Options d’authentification

Lorsque vous analysez une source de données dans Microsoft Purview, vous devez fournir des informations d’identification. Microsoft Purview peut ensuite lire les métadonnées des ressources à l’aide du runtime d’intégration Azure dans la source de données de destination. Lorsque vous utilisez un réseau public, les options d’authentification et les exigences varient en fonction des facteurs suivants :

• Type de source de données. Par exemple, si la source de données est Azure SQL Database, vous devez utiliser une connexion avec db_datareader accès à chaque base de données. Il peut s’agir d’une identité gérée par l’utilisateur ou d’une identité managée Microsoft Purview. Il peut également s’agir d’un principal de service dans Azure Active Directory ajouté à SQL Database en tant que db_datareader.

  Si la source de données est Stockage Blob Azure, vous pouvez utiliser une identité managée Microsoft Purview ou un principal de service dans Azure Active Directory ajouté en tant que rôle Lecteur de données stockage Blob sur le compte de stockage Azure. Ou utilisez la clé du compte de stockage.

• Type d’authentification. Nous vous recommandons d’utiliser une identité managée Microsoft Purview pour analyser les sources de données Azure si possible, afin de réduire la surcharge administrative. Pour tous les autres types d’authentification, vous devez configurer des informations d’identification pour l’authentification source dans Microsoft Purview :

  1. Générez un secret à l’intérieur d’un coffre de clés Azure.
  2. Inscrivez le coffre de clés dans Microsoft Purview.
  3. Dans Microsoft Purview, créez des informations d’identification à l’aide du secret enregistré dans le coffre de clés.

• Type d’exécution utilisé dans l’analyse. Actuellement, vous ne pouvez pas utiliser une identité managée Microsoft Purview avec un runtime d’intégration auto-hébergé.

Autres considérations

• Si vous choisissez d’analyser des sources de données à l’aide de points de terminaison publics, vos machines virtuelles du runtime d’intégration auto-hébergé doivent disposer d’un accès sortant aux sources de données et aux points de terminaison Azure.

• Vos machines virtuelles du runtime d’intégration auto-hébergé doivent disposer d’une connectivité sortante aux points de terminaison Azure.

• Vos sources de données Azure doivent autoriser l’accès public. Si un point de terminaison de service est activé sur la source de données, veillez à autoriser les services Azure figurant dans la liste des services approuvés à accéder à vos sources de données Azure. Le point de terminaison de service achemine le trafic à partir du réseau virtuel via un chemin optimal vers Azure.

Option 2 : Utiliser des points de terminaison privés

Comme pour d’autres solutions PaaS, Microsoft Purview ne prend pas en charge le déploiement directement dans un réseau virtuel. Par conséquent, vous ne pouvez pas utiliser certaines fonctionnalités réseau avec les ressources de l’offre, telles que les groupes de sécurité réseau, les tables de routage ou d’autres appliances dépendantes du réseau, telles que Pare-feu Azure. Au lieu de cela, vous pouvez utiliser des points de terminaison privés qui peuvent être activés sur votre réseau virtuel. Vous pouvez ensuite désactiver l’accès Internet public pour vous connecter en toute sécurité à Microsoft Purview.

Vous devez utiliser des points de terminaison privés pour votre compte Microsoft Purview si vous avez l’une des exigences suivantes :

• Vous devez disposer d’une isolation réseau de bout en bout pour les comptes microsoft Purview et les sources de données.

• Vous devez bloquer l’accès public à vos comptes Microsoft Purview.

• Vos sources de données PaaS (platform-as-a-service) sont déployées avec des points de terminaison privés, et vous avez bloqué tout accès via le point de terminaison public.

• Vos sources de données IaaS (Infrastructure as a Service) locales ou locales ne peuvent pas atteindre les points de terminaison publics.

Considérations relatives à la conception

• Pour vous connecter à votre compte Microsoft Purview de manière privée et sécurisée, vous devez déployer un compte et un point de terminaison privé du portail. Par exemple, ce déploiement est nécessaire si vous envisagez de vous connecter à Microsoft Purview via l’API ou d’utiliser le portail de gouvernance Microsoft Purview.

• Si vous devez vous connecter au portail de gouvernance Microsoft Purview à l’aide de points de terminaison privés, vous devez déployer des points de terminaison privés de compte et de portail.

• Pour analyser des sources de données via une connectivité privée, vous devez configurer au moins un compte et un point de terminaison privé d’ingestion pour Microsoft Purview. Vous devez configurer les analyses à l’aide d’un runtime d’intégration auto-hébergé via une méthode d’authentification autre qu’une identité managée Microsoft Purview.

• Avant de configurer des analyses, passez en revue la matrice de prise en charge pour l’analyse des sources de données via un point de terminaison privé d’ingestion .

• Passez en revue les exigences DNS. Si vous utilisez un serveur DNS personnalisé sur votre réseau, les clients doivent être en mesure de résoudre le nom de domaine complet (FQDN) pour les points de terminaison de compte Microsoft Purview en adresse IP du point de terminaison privé.

• Pour analyser des sources de données Azure via une connectivité privée, utilisez Managed VNet Runtime. Afficher les régions prises en charge. Cette option peut réduire la surcharge administrative liée au déploiement et à la gestion des machines runtime d’intégration auto-hébergées.

Options du runtime d’intégration

• Si vos sources de données se trouvent dans Azure, vous pouvez choisir l’une des options d’exécution suivantes :

  • Runtime de réseau virtuel managé. Utilisez cette option si votre compte Microsoft Purview est déployé dans l’une des régions prises en charge et que vous envisagez d’analyser l’une des sources de données prises en charge.

  • Runtime d’intégration auto-hébergé.

    • Si vous utilisez le runtime d’intégration auto-hébergé, vous devez configurer et utiliser un runtime d’intégration auto-hébergé sur une machine virtuelle Windows déployée à l’intérieur du même réseau virtuel ou d’un réseau virtuel appairé où les points de terminaison privés d’ingestion Microsoft Purview sont déployés. Le runtime d’intégration Azure ne fonctionne pas avec les points de terminaison privés d’ingestion.

    • Pour analyser les sources de données locales, vous pouvez également installer un runtime d’intégration auto-hébergé sur une machine Windows locale ou sur une machine virtuelle à l’intérieur d’un réseau virtuel Azure.

    • Lorsque vous utilisez des points de terminaison privés avec Microsoft Purview, vous devez autoriser la connectivité réseau entre les sources de données et la machine virtuelle d’intégration auto-hébergée sur le réseau virtuel Azure où les points de terminaison privés Microsoft Purview sont déployés.

    • Nous vous recommandons d’autoriser la mise à niveau automatique du runtime d’intégration auto-hébergé. Veillez à ouvrir les règles de trafic sortant requises dans votre réseau virtuel Azure ou sur votre pare-feu d’entreprise pour autoriser la mise à niveau automatique. Pour plus d’informations, consultez Configuration de mise en réseau du runtime d’intégration auto-hébergé.

Options d’authentification

• Vous ne pouvez pas utiliser une identité managée Microsoft Purview pour analyser des sources de données via des points de terminaison privés d’ingestion. Utilisez un principal de service, une clé de compte ou une authentification SQL, en fonction du type de source de données.

• Assurez-vous que vos informations d’identification sont stockées dans un coffre de clés Azure et inscrites dans Microsoft Purview.

• Vous devez créer des informations d’identification dans Microsoft Purview en fonction de chaque secret que vous créez dans le coffre de clés Azure. Vous devez au minimum attribuer l’accès obtenir et lister les secrets pour Microsoft Purview sur la ressource Key Vault dans Azure. Sinon, les informations d’identification ne fonctionneront pas dans le compte Microsoft Purview.

Restrictions en cours

• L’analyse de plusieurs sources Azure à l’aide de l’abonnement ou du groupe de ressources entier via des points de terminaison privés d’ingestion et un runtime d’intégration auto-hébergé n’est pas prise en charge lorsque vous utilisez des points de terminaison privés pour l’ingestion. Au lieu de cela, vous pouvez inscrire et analyser des sources de données individuellement.

• Pour connaître les limitations liées aux points de terminaison privés Microsoft Purview, consultez Limitations connues.

• Pour connaître les limitations liées au service Private Link, consultez limites Azure Private Link.

Scénarios de point de terminaison privé

Réseau virtuel unique, région unique

Dans ce scénario, toutes les sources de données Azure, les machines virtuelles du runtime d’intégration auto-hébergé et les points de terminaison privés Microsoft Purview sont déployés dans le même réseau virtuel dans un abonnement Azure.

S’il existe des sources de données locales, la connectivité est fournie par le biais d’un VPN de site à site ou d’une connectivité Azure ExpressRoute à un réseau virtuel Azure sur lequel des points de terminaison privés Microsoft Purview sont déployés.

Cette architecture convient principalement aux petites organisations ou aux scénarios de développement, de test et de preuve de concept.

Une seule région, plusieurs réseaux virtuels

Pour connecter plusieurs réseaux virtuels dans Azure, vous pouvez utiliser le peering de réseaux virtuels. Le trafic réseau entre les réseaux virtuels appairés est privé et est conservé sur le réseau principal Azure.

De nombreux clients créent leur infrastructure réseau dans Azure à l’aide de l’architecture réseau hub-and-spoke, où :

• Les services partagés de mise en réseau (tels que les appliances virtuelles réseau, les passerelles ExpressRoute/VPN ou les serveurs DNS) sont déployés dans le réseau virtuel hub.
• Les réseaux virtuels spoke consomment ces services partagés via le peering de réseaux virtuels.

Dans les architectures réseau hub-and-spoke, l’équipe de gouvernance des données de votre organization peut être dotée d’un abonnement Azure qui inclut un réseau virtuel (hub). Tous les services de données peuvent se trouver dans quelques autres abonnements connectés au réseau virtuel hub par le biais d’un peering de réseaux virtuels ou d’une connexion VPN de site à site.

Dans une architecture hub-and-spoke, vous pouvez déployer Microsoft Purview et une ou plusieurs machines virtuelles du runtime d’intégration auto-hébergé dans l’abonnement hub et le réseau virtuel. Vous pouvez inscrire et analyser des sources de données à partir d’autres réseaux virtuels à partir de plusieurs abonnements dans la même région.

Les machines virtuelles du runtime d’intégration auto-hébergé peuvent être déployées dans le même réseau virtuel Azure ou un réseau virtuel appairé où les points de terminaison privés de compte et d’ingestion sont déployés.

Vous pouvez éventuellement déployer un autre runtime d’intégration auto-hébergé dans les réseaux virtuels spoke.

Plusieurs régions, plusieurs réseaux virtuels

Si vos sources de données sont distribuées dans plusieurs régions Azure dans un ou plusieurs abonnements Azure, vous pouvez utiliser ce scénario.

Pour optimiser les performances et les coûts, nous vous recommandons vivement de déployer une ou plusieurs machines virtuelles du runtime d’intégration auto-hébergé dans chaque région où se trouvent des sources de données.

Analyser à l’aide du runtime de réseau virtuel managé

Vous pouvez utiliser managed VNet Runtime pour analyser des sources de données dans un réseau privé si votre compte Microsoft Purview est déployé dans l’une des régions prises en charge et que vous envisagez d’analyser l’une des sources de données Azure prises en charge.

L’utilisation du runtime de réseau virtuel managé permet de réduire la surcharge administrative liée à la gestion du runtime et de réduire la durée d’analyse globale.

Pour analyser des sources de données Azure à l’aide du runtime de réseau virtuel managé, un point de terminaison privé managé doit être déployé dans Microsoft Purview Managed Réseau virtuel, même si la source de données dispose déjà d’un réseau privé dans votre abonnement Azure.

Si vous avez besoin d’analyser des sources de données locales ou des sources de données supplémentaires dans Azure qui ne sont pas prises en charge par Managed VNet Runtime, vous pouvez déployer le runtime de réseau virtuel managé et le runtime d’intégration auto-hébergé.

Si Microsoft Purview n’est pas disponible dans votre région primaire

Microsoft Purview est une solution de plateforme en tant que service Azure. Vous pouvez déployer un compte Microsoft Purview dans votre abonnement Azure dans n’importe quelle région Azure prise en charge.

Si Microsoft Purview n’est pas disponible dans votre région Azure principale, tenez compte des facteurs suivants lors du choix d’une région secondaire pour déployer votre compte Microsoft Purview :

• Passez en revue la latence entre votre région Azure principale où les sources de données sont déployées et votre région Azure secondaire, où le compte Microsoft Purview sera déployé. Pour plus d’informations, consultez Statistiques de latence aller-retour du réseau Azure.
• Passez en revue vos exigences en matière de résidence des données. Lorsque vous analysez des sources de données dans le Mappage de données Microsoft Purview, les informations relatives à vos métadonnées sont ingérées et stockées dans votre mappage de données dans la région Azure où votre compte Microsoft Purview est déployé. Pour plus d’informations, consultez Où sont stockées les métadonnées.
• Passez en revue vos exigences en matière de réseau et de sécurité si une connectivité réseau privée pour l’accès utilisateur ou l’ingestion des métadonnées est requise. Pour plus d’informations, consultez Si Microsoft Purview n’est pas disponible dans votre région primaire.

Option 1 : Déployez votre compte Microsoft Purview dans une région secondaire et déployez tous les points de terminaison privés dans la région primaire, où se trouvent vos sources de données Azure. Pour ce scénario :

• Il s’agit de l’option recommandée si l’Australie Sud-Est est la région primaire pour toutes vos sources de données et que toutes les ressources réseau sont déployées dans votre région primaire.
• Déployez un compte Microsoft Purview dans votre région secondaire (par exemple, Australie Est).
• Déployez tous les points de terminaison privés Microsoft Purview, y compris le compte, le portail et l’ingestion dans votre région primaire (par exemple, Australie Sud-Est).
• Déployez toutes les machines virtuelles du runtime d’intégration auto-hébergé Microsoft Purview dans votre région primaire (par exemple, Australie Sud-Est). Cela permet de réduire le trafic entre les régions, car les analyses data map se produisent dans la région locale où se trouvent les sources de données et seules les métadonnées sont ingérées dans votre région secondaire où votre compte Microsoft Purview est déployé.
• Si vous utilisez des réseaux virtuels managés Microsoft Purview pour l’ingestion des métadonnées, le runtime de réseau virtuel managé et tous les points de terminaison privés managés sont automatiquement déployés dans la région où votre Microsoft Purview est déployé (par exemple, Australie Est).

Option 2 : Déployez votre compte Microsoft Purview dans une région secondaire et déployez des points de terminaison privés dans les régions primaire et secondaire. Pour ce scénario :

• Cette option est recommandée si vous avez des sources de données dans les régions primaires et secondaires et si les utilisateurs sont connectés via la région primaire.
• Déployez un compte Microsoft Purview dans votre région secondaire (par exemple, Australie Est).
• Déployez le point de terminaison privé du portail de gouvernance Microsoft Purview dans la région primaire (par exemple, Australie Sud-Est) pour l’accès utilisateur au portail de gouvernance Microsoft Purview.
• Déployez des points de terminaison privés d’ingestion et de compte Microsoft Purview dans votre région primaire (par exemple, Australie Sud-Est) pour analyser les sources de données localement dans la région primaire.
• Déployez des points de terminaison privés d’ingestion et de compte Microsoft Purview dans votre région secondaire (par exemple, Australie Est) pour analyser les sources de données localement dans la région secondaire.
• Déployez des machines virtuelles du runtime d’intégration auto-hébergé Microsoft Purview dans les régions primaire et secondaire. Cela permet de conserver le trafic d’analyse de la carte de données dans la région locale et d’envoyer uniquement des métadonnées à Mappage de données Microsoft Purview où est configuré dans votre région secondaire (par exemple, Australie Est).
• Si vous utilisez des réseaux virtuels managés Microsoft Purview pour l’ingestion des métadonnées, le runtime de réseau virtuel managé et tous les points de terminaison privés managés sont automatiquement déployés dans la région où votre Microsoft Purview est déployé (par exemple, Australie Est).

Configuration DNS avec des points de terminaison privés

Résolution de noms pour plusieurs comptes Microsoft Purview

Il est recommandé de suivre ces recommandations si votre organization doit déployer et gérer plusieurs comptes Microsoft Purview à l’aide de points de terminaison privés :

1. Déployez au moins un point de terminaison privé de compte pour chaque compte Microsoft Purview.
2. Déployez au moins un ensemble de points de terminaison privés d’ingestion pour chaque compte Microsoft Purview.
3. Déployez un point de terminaison privé de portail pour l’un des comptes Microsoft Purview dans vos environnements Azure. Créez un enregistrement DNS A pour le point de terminaison privé du portail afin de résoudre web.purview.azure.com. Le point de terminaison privé du portail peut être utilisé par tous les comptes Purview du même réseau virtuel Azure ou des réseaux virtuels connectés via le peering de réseaux virtuels.

Ce scénario s’applique également si plusieurs comptes Microsoft Purview sont déployés sur plusieurs abonnements et plusieurs réseaux virtuels connectés via le peering de réseaux virtuels. Le point de terminaison privé du portail restitue principalement les ressources statiques liées au portail de gouvernance Microsoft Purview. Par conséquent, il est indépendant du compte Microsoft Purview. Par conséquent, un seul point de terminaison privé du portail est nécessaire pour accéder à tous les comptes Microsoft Purview dans l’environnement Azure si les réseaux virtuels sont connectés.

Remarque

Vous devrez peut-être déployer des points de terminaison privés de portail distincts pour chaque compte Microsoft Purview dans les scénarios où les comptes Microsoft Purview sont déployés dans des segmentations réseau isolées. Le portail Microsoft Purview est un contenu statique pour tous les clients sans aucune information client. Si vous le souhaitez, vous pouvez utiliser le réseau public (sans point de terminaison privé du portail) pour lancer web.purview.azure.com si vos utilisateurs finaux sont autorisés à lancer Internet.

Option 3 : Utiliser des points de terminaison privés et publics

Vous pouvez choisir une option dans laquelle un sous-ensemble de vos sources de données utilise des points de terminaison privés et, en même temps, vous devez analyser l’une des opérations suivantes :

• Autres sources de données configurées avec un point de terminaison de service
• Sources de données qui ont un point de terminaison public accessible via Internet

Si vous devez analyser certaines sources de données à l’aide d’un point de terminaison privé d’ingestion et de certaines sources de données à l’aide de points de terminaison publics ou d’un point de terminaison de service, vous pouvez :

1. Utilisez des points de terminaison privés pour votre compte Microsoft Purview.
2. Définissez Accès réseau public sur Activé à partir de tous les réseaux de votre compte Microsoft Purview.

Options du runtime d’intégration

• Pour analyser une source de données Azure configurée avec un point de terminaison privé, vous devez configurer et utiliser un runtime d’intégration auto-hébergé sur une machine virtuelle Windows déployée à l’intérieur du même réseau virtuel ou d’un réseau virtuel appairé où des points de terminaison privés d’ingestion et de compte Microsoft Purview sont déployés.

  Lorsque vous utilisez un point de terminaison privé avec Microsoft Purview, vous devez autoriser la connectivité réseau à partir de sources de données vers une machine virtuelle d’intégration auto-hébergée sur le réseau virtuel Azure où les points de terminaison privés Microsoft Purview sont déployés.

• Pour analyser une source de données Azure configurée pour autoriser un point de terminaison public, vous pouvez utiliser le runtime d’intégration Azure.

• Pour analyser des sources de données locales, vous pouvez également installer un runtime d’intégration auto-hébergé sur une machine Windows locale ou une machine virtuelle à l’intérieur d’un réseau virtuel Azure.

• Nous vous recommandons d’autoriser la mise à niveau automatique pour un runtime d’intégration auto-hébergé. Veillez à ouvrir les règles de trafic sortant requises dans votre réseau virtuel Azure ou sur votre pare-feu d’entreprise pour autoriser la mise à niveau automatique. Pour plus d’informations, consultez Configuration de mise en réseau du runtime d’intégration auto-hébergé.

Options d’authentification

• Pour analyser une source de données Azure configurée pour autoriser un point de terminaison public, vous pouvez utiliser n’importe quelle option d’authentification, en fonction du type de source de données.

• Si vous utilisez un point de terminaison privé d’ingestion pour analyser une source de données Azure configurée avec un point de terminaison privé :

  • Vous ne pouvez pas utiliser une identité managée Microsoft Purview. Utilisez plutôt un principal de service, une clé de compte ou une authentification SQL, en fonction du type de source de données.

  • Assurez-vous que vos informations d’identification sont stockées dans un coffre de clés Azure et inscrites dans Microsoft Purview.

  • Vous devez créer des informations d’identification dans Microsoft Purview en fonction de chaque secret que vous créez dans Azure Key Vault. Au minimum, attribuez l’accès get et list pour les secrets pour Microsoft Purview sur la ressource Key Vault dans Azure. Sinon, les informations d’identification ne fonctionneront pas dans le compte Microsoft Purview.

Option 4 : Utiliser des points de terminaison privés pour l’ingestion uniquement

Vous pouvez choisir cette option si vous devez :

• Analysez toutes les sources de données à l’aide d’un point de terminaison privé d’ingestion.
• Les ressources managées doivent être configurées pour désactiver le réseau public.
• Activer l’accès au portail de gouvernance Microsoft Purview via un réseau public.

Pour activer cette option :

1. Configurez le point de terminaison privé d’ingestion pour votre compte Microsoft Purview.
2. Définissez Accès réseau publicsur Désactivé pour l’ingestion uniquement (préversion) sur votre compte Microsoft Purview.

Options du runtime d’intégration

Suivez la recommandation pour l’option 2.

Options d’authentification

Suivez la recommandation pour l’option 2.

Recommandations relatives au réseau et au proxy du runtime d’intégration auto-hébergé

Pour analyser des sources de données sur vos réseaux locaux et Azure, vous devrez peut-être déployer et utiliser une ou plusieurs machines virtuelles du runtime d’intégration auto-hébergé au sein d’un réseau virtuel Azure ou d’un réseau local, pour tous les scénarios mentionnés plus haut dans ce document.

• Pour simplifier la gestion, dans la mesure du possible, utilisez le runtime Azure et le runtime managé Microsoft Purview pour analyser les sources de données Azure.

• Le service runtime d’intégration auto-hébergé peut communiquer avec Microsoft Purview via un réseau public ou privé sur le port 443. Pour plus d’informations, consultez Exigences de mise en réseau du runtime d’intégration auto-hébergé.

• Une machine virtuelle du runtime d’intégration auto-hébergé peut être utilisée pour analyser une ou plusieurs sources de données dans Microsoft Purview. Toutefois, le runtime d’intégration auto-hébergé doit être inscrit uniquement pour Microsoft Purview et ne peut pas être utilisé pour Azure Data Factory ou Azure Synapse en même temps.

• Vous pouvez inscrire et utiliser un ou plusieurs runtimes d’intégration auto-hébergés dans un compte Microsoft Purview. Il est recommandé de placer au moins une machine virtuelle runtime d’intégration auto-hébergée dans chaque région ou réseau local où résident vos sources de données.

• Il est recommandé de définir une base de référence pour la capacité requise pour chaque machine virtuelle du runtime d’intégration auto-hébergé et de mettre à l’échelle la capacité de machine virtuelle en fonction de la demande.

• Il est recommandé de configurer une connexion réseau entre les machines virtuelles du runtime d’intégration auto-hébergé et Microsoft Purview et ses ressources managées via un réseau privé, lorsque cela est possible.

• Autorisez la connectivité sortante vers download.microsoft.com, si la mise à jour automatique est activée.

• Le service runtime d’intégration auto-hébergé ne nécessite pas de connectivité Internet sortante si les machines virtuelles du runtime d’intégration auto-hébergé sont déployées dans un réseau virtuel Azure ou dans le réseau local connecté à Azure via une connexion EXPRESSRoute ou VPN de site à site. Dans ce cas, le processus d’analyse et d’ingestion des métadonnées peut être effectué via un réseau privé.

• Le runtime d’intégration auto-hébergé peut communiquer Microsoft Purview et ses ressources managées directement ou via un serveur proxy. Évitez d’utiliser les paramètres de proxy si la machine virtuelle du runtime d’intégration auto-hébergé se trouve à l’intérieur d’un réseau virtuel Azure ou si elle est connectée via expressRoute ou une connexion VPN de site à site.

• Passez en revue les scénarios pris en charge, si vous devez utiliser le runtime d’intégration auto-hébergé avec le paramètre proxy.

Prochaines étapes

• Utiliser des points de terminaison privés pour sécuriser l’accès à Microsoft Purview