Recommandations en matière de sécurité pour Azure Virtual Desktop

  • 7 minutes

Azure Virtual Desktop est un service de bureau virtuel géré qui comprend de nombreuses fonctionnalités de sécurité pour garantir la sécurité de votre organisation. L'architecture Azure Virtual Desktop comprend de nombreux composants qui constituent le service reliant les utilisateurs à leurs bureaux et applications.

Azure Virtual Desktop dispose de nombreuses fonctionnalités de sécurité avancées intégrées, telles que la connexion inversée où aucun port réseau entrant n'a besoin d'être ouvert. Ces fonctionnalités réduisent le risque lié au fait que les bureaux à distance sont accessibles depuis n’importe où. Le service hérite également de nombreuses autres fonctionnalités de sécurité d’Azure, telles que l’authentification multifacteur et l’accès conditionnel. Cet article décrit les étapes à suivre en tant qu’administrateur pour sécuriser vos déploiements Azure Virtual Desktop, que vous fournissiez des ordinateurs de bureau et des applications aux utilisateurs de votre organisation ou à des utilisateurs externes.

Responsabilités de sécurité partagées

Avant Azure Virtual Desktop, les solutions de virtualisation locales telles que les services Bureau à distance exigeaient d’accorder aux utilisateurs l'accès à des rôles tels que Passerelle, Répartiteur, Accès web, etc. Ces rôles devaient être entièrement redondants et capables de gérer les pics de capacité. Les administrateurs devaient installer ces rôles dans le système d’exploitation Windows Server, et ils devaient être joints à un domaine avec des ports spécifiques accessibles aux connexions publiques. Pour assurer la sécurité des déploiements, les administrateurs devaient constamment s’assurer que tous les éléments de l’infrastructure étaient mis à jour.

Toutefois, dans la plupart des services cloud, il existe un ensemble partagé de responsabilités de sécurité entre Microsoft et le client ou le partenaire. Pour Azure Virtual Desktop, la plupart des composants sont gérés par Microsoft, mais les hôtes de session et certains services et composants de support sont gérés par les clients ou par des partenaires. Pour en savoir plus sur les composants d’Azure Virtual Desktop gérés par Microsoft, veuillez consulter la rubrique Architecture et résilience du service Azure Virtual Desktop.

Même si certains composants sont déjà sécurisés pour votre environnement, vous devez configurer d’autres zones pour répondre aux besoins de sécurité de votre organisation ou de votre client. Voici les composants dont vous êtes responsable de la sécurité dans votre déploiement Azure Virtual Desktop :

Composant Responsabilité
Identité Client ou partenaire
Appareils utilisateur (mobiles et PC) Client ou partenaire
Sécurité de l’application Client ou partenaire
Systèmes d’exploitation de l’hôte de session Client ou partenaire
Configuration du déploiement Client ou partenaire
Contrôles de réseau Client ou partenaire
Plan de contrôle de virtualisation Microsoft
Hôtes physiques Microsoft
Réseau physique Microsoft
Centre de données physique Microsoft

Limites de sécurité

Les limites de sécurité séparent le code et les données des domaines de sécurité avec différents niveaux de confiance. Par exemple, il existe généralement une limite de sécurité entre le mode noyau et le mode utilisateur. La plupart des logiciels et services Microsoft dépendent de plusieurs limites de sécurité pour isoler les appareils sur les réseaux, les machines virtuelles et les applications sur les appareils. Le tableau suivant répertorie chaque limite de sécurité pour Windows et sa contribution à la sécurité globale.

Limite de sécurité Description
Limite de réseau Un point de terminaison réseau non autorisé ne peut pas accéder au code ni aux données sur l’appareil d’un client, ni les falsifier.
Limite de noyau Un processus en mode utilisateur non administratif ne peut pas accéder au code ni aux données du noyau, ni les falsifier. Administrateur-vers-noyau n’est pas une limite de sécurité.
Limite de processus Un processus en mode utilisateur non autorisé ne peut pas accéder au code ni aux données d’un autre processus, ni les falsifier.
Limite de bac à sable AppContainer Un processus de bac à sable basé sur AppContainer ne peut pas accéder au code ni aux données, ni les falsifier, en dehors du bac à sable en fonction des capacités du conteneur.
Limite d’utilisateur Un utilisateur ne peut pas accéder au code ni aux données d’un autre utilisateur, ni les falsifier, sans y être autorisé.
Limite de session Une session utilisateur ne peut pas accéder au code ni aux données d’une autre session utilisateur, ni les falsifier, sans y être autorisé.
Limite de navigateur web Un site web non autorisé ne peut pas violer la stratégie d’origine identique, ni accéder au code natif ni aux données du bac à sable du navigateur web Microsoft Edge, ni les falsifier.
Limite de machine virtuelle Une machine virtuelle invitée Hyper-V non autorisée ne peut pas accéder au code ni aux données d’une autre machine virtuelle invitée, ni les falsifier. Les conteneurs isolés Hyper-V sont également concernés.
Limite du mode sécurisé virtuel (VSM) Le code qui s’exécute en dehors de l’enclave ou du processus de confiance VSM ne peut pas accéder au code ni aux données du processus de confiance, ni les falsifier.

Vous devrez également faire certains choix concernant les limites de sécurité au cas par cas. Par exemple, si un utilisateur de votre organisation a besoin de privilèges d’administrateur local pour installer des applications, vous devrez lui attribuer un bureau personnel plutôt qu’un hôte de session partagé. Nous déconseillons de fournir aux utilisateurs des privilèges d’administrateur local dans les scénarios de pool multisession, car ces utilisateurs peuvent franchir les limites de sécurité pour les sessions ou les autorisations de données NTFS, arrêter des machines virtuelles multisession ou effectuer d’autres opérations susceptibles d’interrompre le service ou d’entraîner des pertes de données.

Les utilisateurs d’une même organisation, comme les travailleurs du savoir qui utilisent des applications ne nécessitant pas de privilèges d’administrateur, sont d’excellents candidats pour les hôtes de session multisession, comme Windows 11 Entreprise multisession. Ces hôtes de session réduisent les coûts pour votre organisation, car plusieurs utilisateurs peuvent partager une seule machine virtuelle, avec uniquement les frais de traitement d’une machine virtuelle par utilisateur. Avec des solutions de gestion de profil utilisateur comme FSLogix, les utilisateurs peuvent se voir attribuer n’importe quelle machine virtuelle dans un pool d’hôtes sans remarquer les éventuelles interruptions de service. Cette fonctionnalité vous permet également d’optimiser les coûts en arrêtant, par exemple, les machines virtuelles pendant les heures creuses.

Si, dans votre cas, des utilisateurs de différentes organisations doivent se connecter à votre déploiement, nous vous recommandons d’avoir un locataire distinct pour les services d’identité comme Active Directory et Microsoft Entra ID. Nous vous conseillons également d’avoir un abonnement distinct pour ces utilisateurs à des fins d’hébergement des ressources Azure, comme Azure Virtual Desktop et les machines virtuelles.

Dans de nombreux cas, l’utilisation de plusieurs sessions est un moyen acceptable de réduire les coûts, mais le fait de la recommander ou non dépend du niveau de confiance entre les utilisateurs possédant un accès simultané à une instance multisession partagée. En règle générale, les utilisateurs qui appartiennent à la même organisation ont une relation de confiance suffisante et approuvée. Par exemple, un service ou un groupe de travail où les utilisateurs collaborent et peuvent accéder aux informations personnelles de chacun est une organisation où le niveau de confiance est élevé.

Windows utilise des limites et des contrôles de sécurité pour s’assurer que les processus et les données des utilisateurs sont isolés entre les sessions. Cependant, Windows donne toujours accès à l’instance sur laquelle l’utilisateur travaille.

Les déploiements multisession pourraient tirer parti d’une stratégie de sécurité en profondeur qui ajoute des limites de sécurité supplémentaires empêchant les utilisateurs internes et externes à l’organisation d’obtenir un accès non autorisé aux informations personnelles d’autres utilisateurs. L’accès non autorisé aux données est lié à une erreur dans le processus de configuration par l’administrateur système, telle qu’une faille de sécurité non divulguée ou une vulnérabilité connue qui n’a pas encore été corrigée.

Nous déconseillons d’accorder aux utilisateurs qui travaillent pour des entreprises différentes ou concurrentes l’accès au même environnement multisession. Ces scénarios comportent plusieurs limites de sécurité qui peuvent être attaquées ou utilisées abusivement, telles que le réseau, le noyau, le processus, l’utilisateur ou les sessions. Une seule vulnérabilité de sécurité peut entraîner le vol d’informations d’identification et de données non autorisées, la fuite d’informations personnelles, l’usurpation d’identité et d’autres problèmes. Les fournisseurs d’environnements virtualisés sont tenus de proposer des systèmes bien conçus, dotés de plusieurs limites de sécurité fortes et de fonctionnalités de sécurité supplémentaires si possible activées.

Le tableau récapitule nos recommandations pour chaque scénario.

Scénario de niveau de confiance Solution recommandée
Utilisateurs d’une même organisation avec des privilèges standard Utilisez un système d’exploitation Windows Entreprise multisession.
Les utilisateurs nécessitent des privilèges d’administrateur Utilisez un pool d’hôtes personnel et attribuez à chaque utilisateur son propre hôte de session.
Utilisateurs de différentes organisations qui se connectent Séparez le locataire Azure et l’abonnement Azure.