Migration tenant à tenant Microsoft 365 : stratégies et bonnes pratiques
Avec la croissance des fusions, acquisitions et réorganisations internes, la migration de tenant à tenant dans Microsoft 365 est un...
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
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 :
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 !
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 … 😀
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
Avec la croissance des fusions, acquisitions et réorganisations internes, la migration de tenant à tenant dans Microsoft 365 est un...
Pourquoi migrer vers Microsoft 365 ? Face à l’évolution constante des technologies numériques, les entreprises sont confrontées à un choix...
Entra ID, anciennement connu sous le nom d’Azure Active Directory (Azure AD), est le service d’identité cloud de Microsoft, dédié...