Sécurisation de l ‘accès réseau de l’environnement Azure Virtual Desktop

Dans ce nouveau article , nous allons voir les bonnes pratiques pour sécuriser notre environnement Azure Virtual Desktop.

Flux de connexion

Azure Virtual Desktop utilise le protocole RDP (Remote Desktop Protocol) pour fournir des capacités d’affichage et de saisie à distance via des connexions réseau. Le flux de données de connexion pour Azure Virtual Desktop commence par une recherche DNS du datacenter Azure le plus proche. La passerelle gère toutes les connexions de la session, le client ne recevant que des pixels. La connexion d’un utilisateur se fait en cinq étapes :

Après l’authentification dans Azure AD, un jeton est renvoyé au client Remote Desktop Services
La passerelle vérifie la validité du jeton avec le Service Broker pour les connexions
Le Service Broker interroge la base de données Azure SQL pour trouver les ressources attribuées à l’utilisateur
La passerelle et le Service Broker sélectionnent l’hôte de session pour le client connecté
L’hôte de la session crée une connexion inverse avec le client en utilisant la passerelle Azure Virtual Desktop

Reverse Connect

Si vous connaissez les services de Bureau à distance (RDS), et la passerelle Bureau à distance (RD Gateway) en particulier, vous savez que pour permettre à l’utilisateur de se connecter à un hôte de session Bureau à distance (RD Session Host), le port TCP 3389 doit être ouvert depuis la passerelle Gateway vers l’hôte de session Bureau à distance

Contrairement à RDS, Azure Virtual Desktop ajoute par défaut une couche de sécurité supplémentaire et n’a donc pas besoin d’un écouteur TCP pour recevoir les connexions RDP entrantes. Azure Virtual Desktop utilise le transport de connexion inverse ( reverse connect) pour établir la session à distance ainsi que pour transporter le trafic RDP. L’agent Azure Virtual Desktop qui est automatiquement installé sur l’hôte de la session est configuré pour utiliser la connectivité sortante vers l’infrastructure Azure Virtual Desktop via la connexion HTTPS. Aucun port entrant n’est nécessaire à l’intérieur du pare-feu devant les hôtes de session. Aucune action supplémentaire n’est nécessaire pour activer Reverse Connect,

En cas de besoin d’un accès RDP direct à des fins d’administration ou de dépannage, il faut se connecter à partir d’un réseau interne ou activez un accès juste-à-temps pour limiter la surface d’attaque potentielle sur un hôte de session.

Balises de service du groupe de sécurité de réseau

Une autre mesure de sécurité que nous pouvons prendre consiste à limiter le trafic d’Azure Virtual Desktop à l’aide de balises de service NSG (Network Security Group).

Un NSG est un ensemble de règles de sécurité qui autorisent ou interdisent le flux de trafic réseau entrant ou sortant des ressources Azure. Chaque règle peut définir les propriétés suivantes : nom, priorité, source ou destination, protocole, direction, plage de ports et action. Les NSG sont un service de sécurité réseau de niveau 3 et 4.

Les balises de service simplifient la sécurité des VM Azure. Étant donné que les réseaux virtuels Azure sont utilisés dans le cadre d’un déploiement d’Azure Virtual Desktop, les balises de service permettent de limiter facilement l’accès au réseau aux seuls services Azure. Nous pouvons utiliser des balises de service dans les règles NSG pour autoriser ou refuser le trafic vers un service Azure spécifique, globalement ou par région Azure .

Les VM Azure que nous avons crée pour notre environnement Azure Virtual Desktop doivent avoir accès à plusieurs noms de domaine complets (FQDN) pour fonctionner correctement. Le tableau suivant montre les FQDN et ports concernés :

Azure Firewall

Azure Firewall fournit une balise FQDN Azure Virtual Desktop pour simplifier la configuration

Pour autoriser le trafic sortant de la plateforme Azure Virtual Desktop à l’aide du pare-feu Azure, il faut :
• Déployer Azure Firewall et configurez la route définie par l’utilisateur (UDR) de votre pool d’hôtes Azure Virtual Desktop pour acheminer la totalité du trafic par Azure Firewall.
• Créer une collection de règles d’application et ajouter une règle pour activer la balise FQDN AzureVirtualDesktop.
• L’ensemble des comptes de stockage et de bus de service requis pour un pool d’hôtes Azure Virtual Desktop est spécifique à chaque déploiement. Il fat autoriser l’accès HTTPS depuis le sous-réseau de votre lot d’hôtes à *xt.blob.core.windows.net, *eh.servicebus.windows.net et *xt.table.core.windows.net. Ces FQDN génériques permettent l’accès requis mais sont moins restrictifs. L’autre option consiste à utiliser une requête d’analyse des journaux pour répertorier les FQDN exacts requis, puis à les autoriser explicitement dans votre règle d’application du pare-feu.
• Créez une collection de règles réseau et autorisez le trafic émanant de votre adresse IP privée AD DS vers * pour les ports TCP et UDP 53, et autorisez le trafic émanant des VM Azure Virtual Desktop vers le port TCP 1688 du service d’activation Windows.

Accès sortant du pool d’hôtes à Internet

Pour notre environnement VDI , il faut un accès Internet sortant sécurisé pour les utilisateurs.

Lorsque la liste des destinations autorisées est bien définie (par exemple, l’accès à Microsoft 365), nous pouvons utiliser les règles d’application et de réseau du pare-feu Azure pour configurer l’accès requis. Dans le cas d’applications moins bien définies, l’ajout de ces destinations sur une liste blanche peut représenter un travail plus important. On peut également configurer les navigateurs web ou d’autres applications fonctionnant sur le pool d’hôtes d’Azure Virtual Desktop avec une configuration spécifique, si on souhaite filtrer le trafic Internet sortant des utilisateurs en utilisant une passerelle web sécurisée existante sur site.