Azure Virtual Desktop continue encore d’évoluer et s’associe maintenant avec un autre service réseau du cloud Microsoft : Azure Private Link. En ce début du mois de novembre, Microsoft vient de l’ouvrir en préversion publique pour tester cette fonctionnalité. L’idée est donc de sécuriser d’avantage, par une restriction encore plus poussée, l’accès au service Azure Virtual Desktop.
Pourquoi restreindre un service Cloud ?
Pour répondre à une demande provenant de certaines entreprises. Beaucoup d’entre-elles ont même des exigences légales et ne souhaitent donc pas faire passer un flux réseau à travers internet, quand bien même il s’agirait de communications en HTTPS.
Il paraissait donc important que Microsoft propose ce type de fonctionnalité pour permettre à au service à Azure Virtual Desktop d’être 100% en dehors du web.
Pour parvenir à la mise en place de cette fonctionnalité, Microsoft met déjà à disposition plusieurs documentations, disponibles uniquement en anglais pour l’instant :
Qu’est-ce qu’Azure Private Link ?
En deux mot, Azure Private Link vous permet d’accéder aux services Azure PaaS (par exemple du stockage Azure, compte le compte de stockage ou encore une base de données SQL) depuis votre réseau virtuel :
Voici une vidéo qui aborde le sujet dans son entièreté :
Comment va fonctionner Azure Virtual Desktop avec Private Link ?
Comme pour les autres services proposant cette association, le trafic entre le réseau virtuel et Azure Virtual Desktop transitera par le réseau « dorsal » de Microsoft, ce qui signifie que vous n’aurez plus besoin d’exposer votre AVD à l’Internet.
En termes de sécurité, transiter son trafic dans le réseau « connu » et sécurisé de Microsoft renforcera toujours un peu plus la protection de vos données.
A quel moment intervient le Private Link dans le chemin de connexion entre l’utilisateur et AVD ?
Il peut intervenir à plusieurs niveaux. En effet, la connexion est décomposée en différentes étapes et avec plusieurs composants. Il est alors possible de choisir quelles connexions ont le droit ou non de transiter par internet.
C’est d’ailleurs pour cela que plusieurs options sont présentes dans la configuration réseau d’AVD :
- La première option se charge d’autoriser ou non l’accès au service AVD des utilisateurs depuis internet. Autrement la partie frontale de la connexion AVD.
- La seconde option se charge d’autoriser ou non l’accès au service AVD des machines virtuelles AVD depuis internet. Autrement la partie arrière-plan de la connexion AVD.
Peut-on utiliser à la fois les fonctionnalités Private Link et RDP Shortpath ?
Durant cette phase de préversion, cela n’est pas possible. Pour rappel RDP Shortpath est une méthode habile d’Azure Virtual Desktop qui établit un transport direct basé sur le protocole UDP entre le client Remote Desktop et l’hôte de session. Tout y est expliqué ici.
Etape 0 – Rappel des prérequis
Pour arriver à la démonstration de l’association entre Azure Virtual Desktop et Private Link, je dispose d’un environnement comprenant des composants déjà en place :
- Poste Windows 10 avec Azure VPN
- Environnement AVD avec jointure Azure AD
On retrouve ainsi mon premier réseau virtuel comprenant :
- La machine virtuelle faisant office de poste utilisateur distant sous Windows 10
- Le service Azure Bastion pour m’y connecter plus facilement
J’ai également déployé un second réseau virtuel. Celui-ci comprend
- Mon environnement Azure Virtual Desktop
- Une passerelle VPN pour assurer la connection entre le poste Windows 10 et AVD
La connexion VPN Point à Site est bien fonctionnelle :
Comme vous pouvez le voir sur la configuration d’Azure Virtual Desktop, une nouvelle section dédiée au réseau a fait son apparition :
Avant d’aller plus loin, il est donc nécessaire d’activer la fonctionnalité, encore en préversion à l’heure où ces lignes sont écrites.
Etape I – Activation de la fonction de préversion d’Azure Private Link
Comme beaucoup de fonctionnalités encore en préversion, il est nécessaire de l’activer depuis le portail Azure. Pour cela, effectuer l’opération suivante via ce lien :
Une fois enregistrée, attendez environ 15 minutes.
Retournez sur la section réseau de votre Azure Virtual Desktop pour constater le déblocage des fonctionnalités réseaux :
Dans cette configuration par défaut, avec les 2 cases de cochées, la connexion réseau transite via internet dans sa totalité :
- Entre le client et le service Azure Virtual Desktop
- Entre le service Azure Virtual Desktop et les machines virtuelles AVD
Un test, avec le VPN désactivé, montre que la connexion se fait toujours via internet :
Etape II – Restreindre la communication entre le service AVD et le pool d’hôtes au réseau virtuel Azure
La première étape consiste donc à restreindre la communication entre le service Azure Virtual Desktop et les machines virtuelles AVD au réseau virtuel. Pour cela décochez la case suivante et sauvegardez :
Un nouvel essai de connexion utilisateur vous montre le blocage immédiat de cette méthode en passant par internet :
Pour arriver rétablir l’accès au service AVD, nous avons besoin de créer un premier private endpoint en cliquant sur le second onglet de la section réseau :
Donnez-lui un nom, puis passez à l’onglet suivant :
Laissez cet onglet comme ceci avec le type connexion et passez sur le suivant.
Pour information, il existe différents types de sous-resource cible, ils auront une importance et seront utilisés par la suite :
| Type de resource | Type de sous-resource | Quantité |
|---|---|---|
| Microsoft.DesktopVirtualization/workspaces | global | Un pour tous les déploiements Azure Virtual Desktop |
| Microsoft.DesktopVirtualization/workspaces | feed | Un par workspace |
| Microsoft.DesktopVirtualization/hostpools | connection | Un par pool d’hôtes |
Renseignez le réseau / sous réseau de votre environnement Azure Virtual Desktop :
Pour votre information, plusieurs adresses IP privées seront alors allouées pour les services suivants :
Sur l’onglet suivant, une zone DNS privée va être créé pour le private endpoint :
Lancez la création puis attendez :
Une fois créé, la carte réseau du private endpoint nouvellement créé vous montre que chaque service dispose bien d’une adresse IP dédiée :
Important : Pour les gros environnement AVD, prévoir un second sous-réseau pour éviter un souci d’adressage.
Un redémarrage de machines virtuelles AVD plus tard : la connexion AVD depuis le poste client refonctionne sans souci :
Veuillez noter que la copie d’écran ci-dessus montre bien que le VPN d’Azure est toujours déconnecté. Cela montre bien que nous n’avons pas encore influencé la partie frontale du service AVD.
Pour bien comprendre ce qui s’est passé, un test intéressant est de
- Créer un groupe de sécurité réseau (NSG)
- Y ajouter une restriction d’accès au service publique d’Azure Virtual Desktop
- L’associer au sous-réseau contenant les machines virtuelles AVD
Ce test créé une contrainte qui n’empêche pas notre test de fonctionner, car la connexion entre le service Azure Virtual Desktop et les machines AVD transite par le private endpoint nouvellement créé.
J’ai également fait un autre test de retirer le private endpoint. Les machines virtuelles AVD apparaissent alors bien comme étant injoignables pour le service Azure Virtual Desktop :
Maintenant, la seconde étape est de restreindre également l’accès au service Azure Virtual pour les postes connectés uniquement à internet.
Etape IIIa – Restreindre la communication entre le service AVD et les utilisateurs au réseau virtuel
La première étape consiste donc à restreindre la communication entre le service AVD et les utilisateurs via internet. Pour cela, décochez la case suivante et sauvegardez :
Un nouvel essai de connexion à AVD nous montre le blocage immédiat de cette méthode en passant par internet :
Un rafraichissement de l’espace de travail AVD montre maintenant un refus d’affichage de celui-ci :
Pour terminer la configuration, nous avons besoin de créer deux autres private endpoints.
Pour cela, allez sur l’espace de travail AVD, allez dans la section réseau, décochez la case et sauvegardez :
Comme précédemment, commencez par créer un private endpoint comme ceci :
Nommez-le différemment du premier private endpoint créé durant l’étape précédente :
Choisissez cette fois-ci la sous-resource cible de type Feed :
Renseignez le réseau / sous réseau où votre environnement Azure Virtual Desktop :
Là encore, des adresses IP privées seront allouées pour les services suivants :
Sur l’onglet suivant, la première zone DNS privée va être réutilisée pour le second private endpoint, rattaché à votre espace de travail :
Lancez la création puis attendez :
Une fois créé, retournez sur la page d’Azure Virtual Desktop pour créer le troisième private endpoint de type Global.
Etape IIIb – Restreindre la communication entre le service AVD et les utilisateurs au réseau virtuel
Microsoft conseille d’isoler ce private endpoint sur un espace de travail dédié au réseau. En effet, ce private endpoint unique de type Global pourrait service servir à tous les réseaux virtuels appairés.
Pour cela, créez un nouvel espace de travail AVD :
Nommez-le et lancez sa création :
Une fois créé, retournez-y, décochez là encore l’option réseau, puis sauvegardez.
Créez ici le troisième private endpoint et remplissez le premier onglet comme les 2 précédentes fois :
Choisissez le type de sous-resource cible Global :
Choisissez un réseau en relation directe avec votre environnement AVD :
Pour information, une adresse IP privée sera là-encore allouée pour le service suivant :
Sur l’onglet suivant, la première zone DNS privée va être réutilisée pour le troisième private endpoint, rattaché à ce nouvel espace de travail :
Lancez la création puis attendez :
Etape IV : Configuration du réseau on-premise
Pour que la connexion restreinte à Azure Virtual Desktop fonctionne bien, il est nécessaire d’apporter les enregistrements DNS créés précédemment sur le réseau on-premise.
Comme mon réseau on-premise est virtuellement créé sur Azure, j’ai choisi de créer une seconde zone DNS privée avec le même nom et de la rattacher à mon réseau on-premise :
Etape V : Test de la connexion via Azure VPN Point à Site
Sur le poste on-premise de test, effectuez un premier test de connexion à l’URL d’Azure Virtual Desktop tout en ayant la connexion VPN de stoppée :
aka.ms/wvdarmwebConstatez avant tout que la page n’est dorénavant plus joignable :
Démarrez votre connexion VPN grâce au client Azure VPN :
Recharger la page web du service Azure Virtual Desktop et renseignez vos identifiants de l’utilisateur de test :
Cliquez sur l’icône de bureau à distance :
Renseignez une seconde fois son mot de passe :
Et vus voilà dans votre session AVD !
Un test de déconnexion de la connexion VPN affectera immédiatement la session utilisateur d’AVD :
Réactiver la connexion VPN pour retrouver la session AVD.
Etape VI : Résumé des ressources Azure créées
Afin d’apporter plus de clarté à toutes ces opérations de déploiement, voici un récapitulatif du travail effectué dans cet article sur mon environnement Azure :
- 3 private endpoints :
- 3 cartes réseaux :
- 2 zones DNS privées :
- 1 second espace de travail AVD :
Etape VI : Aide à la résolution
Si l’installation s’est déroulée sans accro, mais que vous n’arrivez toujours pas à vous reconnecter à votre environnement Azure Virtual Desktop, voici quelques pistes qui peuvent vous aider :
Conclusion
Par cette nouvelle fonctionnalité, Microsoft apporte encore plus de liberté dans la manière d’utiliser son environnement AVD, avec toujours plus d’exigences de sécurité. La possibilité de restreindre le service AVD à différents types de connexions sécurisées, comme les VPNs ou encore Azure ExpressRoute était attendue depuis longtemps.
Comme toujours, Dean de l’Azure Academy a préparé une vidéo très explicative de la mise en route ????
