Azure Purview : comment fonctionne Preview Managed VNet ?

Temps de lecture : 4 mins
Description de l'image
Jean-Philippe Lucas
22 mars 2022

Dans le précédent billet de blog sur Purview, j’avais balayé quelques options de configuration pour accéder à différents types de ressources, sur Azure ou on-premise.

Entre temps, une preview a fait son apparition courant janvier, et concerne la fonctionnalité Managed VNet.

Elle va apporter quelques options supplémentaires pour se connecter à vos ressources Azure, notamment celles qui sont privatisées, en facilitant leur mise en œuvre.

Cette preview reste limitée à date aux régions suivantes :

https://docs.microsoft.com/en-us/azure/purview/catalog-managed-vnet#supported-regions

Managed VNet : quelle utilité ?

Déjà utilisé par plusieurs services, notamment Data Factory ou Synapse, c’est un réseau managé et intégré au service qui le porte. Pas d’adresses IP à gérer, d’interconnexion ou de peering… de toute façon vous n’avez pas la main dessus !

Une « integration runtime » cloud est instanciée sur ce réseau, et grâce à l’utilisation de private endpoints que vous provisionnerez dessus, celle-ci va pouvoir utiliser de manière totalement privée les ressources qui y seront connectées.

Quel avantage ? Ne plus déployer de self hosted integration runtime pour utiliser des ressources Azure privatisées !

Reste que les services sont pour le moment limités, mais devraient couvrir bien des cas d’usages courants :

Dans le portail Purview

La configuration de l’integration runtime cloud en mode « Managed Virtual Network » se fait dans la section « Data Map », comme pour le mode « Self Hosted ».

Quelques minutes après sa création, trois private endpoints sont automatiquement crées (image ci-dessous). Ce sont eux qui vont permettre l’ingestion de données dans Purview.

Ce même écran va également vous permettre d’ajouter vos private endpoints vers vos ressources Azure à scanner.

A noter que l’event hub managé de Purview est également utilisé, certainement en direct sur le backbone Azure. Il n’est pas spécifiquement protégé au niveau réseau, son niveau d’accès restant toujours en « All networks ». Rassurez-vous, les données scannées ne passent pas par ce biais !

Architecture

En reprenant une architecture classique avec accès restreint et en y intégrant le Managed VNet, cela donne le schéma suivant. Oui, cela commence à faire pas mal de tuyauterie « Private Link »!

Et encore je n’ai pas fait le cas d’usage avec Synapse et son propre Managed VNet … 😀

Conclusion

Le fonctionnement n’est pas très éloigné de l’integration runtime en mode « Self Hosted ».

Le bonus, c’est que le système est totalement managé ! Plus besoin d’utiliser une machine virtuelle, cela simplifie grandement le déploiement.

La fonctionnalité restant en preview, elle peut bien sûr évoluer, et est déconseillée en production tant qu’elle ne passe pas le stade de la « General Availability » !

Vous trouverez plus d’information sur la documentation : https://docs.microsoft.com/en-us/azure/purview/catalog-managed-vnet

Bons tests !

Articles Similaires

Qu’est-ce que VMware Aria Operations ? 

Annoncé officiellement depuis le 22 janvier 2024 VMware Aria Operations (ex- vRealize Operations Manager) n’est plus vendu seul et est...

Cloud Security : la stratégie du Zero Trust 

Cloud : la sécurité par défaut Il y a peu, Vincent Strubel, Directeur Général de l’ANSSI, a affirmé que la...

Cloud Privé : pourquoi et comment le mettre en place ? 

Quels sont les avantages et les étapes de mises en place d'un cloud privé ? Et en quoi diffère-t-il d'un...