• Article

Vigilance sécuritéAccès à distance sécurisé

John Morello

L'une des tendances indéniables du paysage technologique actuel est que le personnel des entreprises est de plus en plus mobile et connecté. Dans de nombreuses organisations, un grand nombre de membres du personnel travaillent depuis des bureaux dispersés, pratiquent le télétravail ou se déplacent fréquemment chez les clients. Le fait de fournir à ces utilisateurs un accès facile aux applications et aux données, quel que soit leur emplacement, ne peut qu'augmenter leur

productivité. Cependant, jusqu'à il y a peu, l'accès à distance sécurisé impliquait souvent d'installer un logiciel client, de taper des commandes complexes, ainsi que des temps de connexion longs.

Au cours des dernières années, plusieurs approches ont contribué à rendre l'accès à distance plus simple et plus accessible. Par exemple, Outlook® Web Access (OWA) fournit aux utilisateurs un outil simple basé sur un navigateur pour accéder à leur messagerie électronique, leur calendrier et leurs contacts sans les complexités d'un réseau privé virtuel (VPN) de couche 3 complet. Bien que les technologies telles qu'OWA puissent offrir un élément important d'une solution d'accès à distance, la plupart des organisations disposent de nombreuses applications clés qui ne permettent pas le même genre d'expérience intégrée basée sur un navigateur. Dans ce type de cas, les solutions telles que les services Terminal Server offrent une méthode efficace pour donner aux utilisateurs un accès à leurs applications quel que soit l'endroit où ils se trouvent.

Avec Windows Server® 2008, Microsoft a considérablement amélioré l'ensemble des fonctionnalités intégrées des services Terminal Server. Les services Terminal Server incluent désormais une fenêtre transparente, une fonctionnalité de publication pour chaque application, une fonctionnalité de pilote d'impression universel dans EasyPrint et un portail basé sur navigateur appelé TS Web Access. De plus (et c'est là la clé du scénario d'accès à distance), Windows Server 2008 inclut également le composant Passerelle TS qui fournit l'encapsulation SSL pour le protocole RDP (Remote Desktop Protocol), lui permettant ainsi de traverser de façon simple et sécurisée les pare-feu et les périphériques de traduction d'adresses réseau (NAT). La fonctionnalité de passerelle TS s'intègre également avec une autre nouvelle technologie de Windows Server 2008, la protection de l’accès réseau (NAP), pour assurer une vérification de l'intégrité du client de point de terminaison. Lorsque tous ces composants sont associés, les organisations ont la possibilité de générer des solutions qui permettent aux utilisateurs d'accéder facilement et de façon sécurisée à leurs applications et données depuis n'importe quel site.

Cet article se concentre sur les aspects relatifs à la sécurité et au réseau de la conception d'une solution d'accès à distance plutôt que sur la gestion des composants Terminal Server. Je décrirai les méthodes et les meilleures pratiques pour la création d'une telle solution basée sur les technologies incluses dans Windows Server 2008.

Pourquoi les réseaux privés virtuels de couche 3 posent-ils un problème ?

Lorsque vous envisagez d'utiliser une nouvelle technologie, il est important de comprendre ses avantages par rapport aux approches actuelles de sorte à pouvoir évaluer de façon précise la valeur du nouveau modèle. Dans le cas d'un VPN de couche 3 classique, deux problèmes majeurs se posent généralement : sécurité et simplicité d'utilisation.

Il peut sembler paradoxal d'énumérer la sécurité comme l'un des problèmes de nombreux VPN de couche 3 existants. Le but d'un VPN n'est-il pas de fournir un tunnel sécurisé sur Internet ? Pour mieux comprendre, examinons à un plus haut niveau ce qui est généralement considéré comme des menaces pour le réseau VPN. Je ne dis pas que les données transitant par ces VPN courent un risque d'interception ou de falsification ; la plupart des VPN modernes de couche 3 fournissent un excellent chiffrement du flux de données. Pensez plutôt aux menaces posées par les ordinateurs distants qui bénéficient d'un accès complet « tous ports, tous protocoles » au réseau de votre organisation. Le problème ne réside pas dans le flux de données chiffré et transporté sur le réseau par les VPN de couche 3, mais plutôt dans les clients distants se connectant via ces tunnels, qui représentent un risque plus grand pour votre réseau interne. Rappelons que la plupart des organisations ayant subi les conséquences de logiciels malveillants tels que Slammer ou Blaster n'ont pas été infectées par des ordinateurs sur leur réseau interne ou par des pirates informatiques traversant leurs pare-feu. L'infection provenait d'employés distants se connectant à leurs réseaux via des VPN depuis des ordinateurs infectés. Lorsque ces VPN créent des connexions de couche 3 entièrement routées, l'ordinateur distant a souvent autant accès (ce qui est à la fois une bonne et mauvaise chose) aux ressources internes qu'un ordinateur situé au centre de données.

De plus, les VPN de couche 3 sont souvent coûteux parce qu'ils nécessitent l'installation et la configuration de logiciels sur des ordinateurs qui ne sont pas gérés par l'équipe informatique de l'organisation. Par exemple, l'installation d'un client VPN sur l'ordinateur personnel d'un utilisateur peut impliquer la création de packages d'installation personnalisés, la rédaction d'instructions d'installation détaillées pour l'utilisateur et des conflits de dépannage avec des applications existantes sur l'ordinateur de l'utilisateur. En outre, les coûts de gestion peuvent être élevés si de nouvelles versions du client doivent être déployées ou si les données de configuration sont modifiées (par exemple lors de l'ajout d'un nouveau point de terminaison VPN). Pour l'utilisateur, l'utilisation de ce type de VPN se traduit souvent par une expérience non intuitive. Puisque le VPN fournit uniquement la connexion de couche 3, les applications et les données d'entreprise de l'utilisateur ne sont pas facilement accessibles et visibles.

Résolution des problèmes liés aux services Terminal Server

Les services Terminal Server, ainsi que d'autres technologies VPN de couche 7 ou de couche d'application, résolvent ces deux problèmes en fournissant un contrôle beaucoup plus approfondi sur les ressources et protocoles auxquels les utilisateurs peuvent accéder, et en rendant l'expérience utilisateur beaucoup plus simple et intuitive qu'auparavant.

Du point de vue de la sécurité, la différence la plus importante entre l'approche de VPN de couche 3 et celle qui utilise les services Terminal Server et la passerelle TS réside dans le fait que la connexion au réseau interne n'est pas totalement ouverte. En particulier, alors qu'une approche de couche 3 crée une interface virtuelle sur l'ordinateur local avec une fonctionnalité de routage complète vers le réseau interne, l'approche de passerelle TS autorise seulement aux paquets RDP à atteindre le réseau interne. Ainsi, la surface d'attaque générale est fortement réduite et des contrôles plus granulaires peuvent être appliqués dans RDP. Par exemple, alors que RDP fournit une prise en charge native pour le réacheminement de lecteur, les organisations peuvent configurer leurs passerelles TS de sorte qu'elles s'intègrent à NAP et qu'elles n'autorisent pas cette fonctionnalité à moins que l'ordinateur distant puisse prouver que son logiciel antivirus est à jour.

Pour les utilisateurs finaux, la différence la plus évidente entre une approche VPN de couche 3 et une approche Terminal Server réside dans la simplicité d'installation (souvent, il n'y a pas d'installation du tout) et un accès beaucoup plus facile et intuitif aux applications et données. Dans la mesure où le client Connexion Bureau à distance est intégré à Windows (et maintenu à jour à l'aide de technologies de maintenance standard telles que Windows® Update), il n'y a généralement pas de logiciel client à installer. De plus, en utilisant TS Web Access, les utilisateurs peuvent utiliser une URL unique pour rechercher toutes leurs applications et données. Il suffit de cliquer sur l'application appropriée pour lancer la passerelle TS qui tunnelise la connexion sur Internet de façon sécurisée, et l'application est envoyée de façon transparente au bureau de l'utilisateur. En d'autres termes, l'application se comporte comme si elle était installée localement, offrant notamment la possibilité de copier et coller et de la réduire dans la barre de tâches. En rendant facilitant la détection et l'installation des applications et des données, l'approche Terminal Server d'accès à distance améliore la satisfaction des utilisateurs et réduit les coûts de support.

Choix d'architecture réseau

Il existe deux approches fondamentales de conception de réseau pouvant être utilisées pour rendre un serveur de passerelle TS accessible sur Internet. La première place la passerelle TS dans le réseau de périmètre, entre deux pare-feu de couches 3 et 4. La seconde laisse la passerelle TS sur le réseau interne et utilise un pare-feu de couche d'application (tel que Microsoft® ISA Server, Microsoft Intelligent Application Gateway ou toute une série de solutions de tiers) pour résider sur le réseau de périmètre et inspecter les trames HTTPS entrantes. Une fois ces sessions entrantes analysées, les paquets sont transférés au serveur de passerelle TS interne.

Si une organisation dispose uniquement de pare-feu de couches 3 et 4 avec une vérification de paquets avec état de base, le périphérique de passerelle TS peut être directement placé dans le réseau de périmètre, comme illustré à la figure 1. Dans cette conception, le pare-feu ouvert sur Internet limite la connectivité à la passerelle TS pour autoriser uniquement le trafic HTTPS Internet à l'atteindre. Cependant, le pare-feu n'effectue pas de vérification sur la couche d'application de ce trafic ; il transfère simplement le trafic à la passerelle TS. Le serveur de passerelle TS extrait ensuite les trames RDP des paquets HTTPS et les transfère au serveur principal approprié. Ces serveurs principaux sont souvent séparés du réseau de périmètre par un deuxième pare-feu configuré pour autoriser les trames RDP de la passerelle TS à atteindre les serveurs internes appropriés.

Figure 1 Avec un pare-feu de couches 3 et 4, la passerelle TS est placée dans le réseau de périmètre

Figure 1** Avec un pare-feu de couches 3 et 4, la passerelle TS est placée dans le réseau de périmètre **(Cliquer sur l'image pour l'agrandir)

Bien qu'il s'agisse d'un scénario entièrement pris en charge et qui peut être utile à de nombreuses organisations, il présente deux inconvénients essentiels. Tout d'abord, dans la mesure où la passerelle TS reçoit le trafic directement d'Internet, elle est exposée à un niveau de risques provenant de tiers malveillants externes relativement plus élevé. Ces tiers malveillants pourraient tenter d'attaquer la passerelle via la session SSL et, comme le pare-feu frontal vérifie uniquement les en-têtes et pas les charges utiles, ces sessions atteindraient la passerelle. Cela ne veut pas dire que la passerelle TS est un composant vulnérable ; elle a été soumise aux mêmes conception et tests de sécurité rigoureux que le reste du produit Windows Server 2008. Cependant, son risque relatif est plus élevé dans ce scénario, simplement parce qu'elle contrôle un trafic non filtré provenant directement d'Internet. Le deuxième inconvénient majeur réside dans la quantité accrue de trafic devant être autorisé entre la passerelle et le pare-feu principal. Pour authentifier les utilisateurs, la passerelle TS doit communiquer avec Active Directory®. Pour autoriser cette communication, le pare-feu principal doit avoir des exceptions pour un nombre de ports et de protocoles beaucoup plus important que HTTPS. Ce niveau accru de communications autorisées représente également une augmentation du risque relatif de cette conception.

Une meilleure approche d'exposition d'une passerelle TS à Internet consiste à utiliser un pare-feu de couche d'application (couche 7) pour traiter les sessions HTTPS entrantes avant qu'elles n'atteignent la passerelle (voir figure 2). Dans cette conception, des pare-feu de couches 3/4 traditionnels peuvent toujours former un réseau de périmètre. Cependant, au lieu de la passerelle TS, c'est le pare-feu de couche 7 qui se situe dans le réseau de périmètre. Lorsque le trafic atteint le pare-feu externe, ce pare-feu filtre tout sauf les trames HTTPS, puis transfère ces trames vers le pare-feu de couche 7. Le pare-feu de couche 7 met fin à la session SSL, vérifie les contenus du flux non chiffrés, bloque le trafic malveillant, puis envoie les trames RDP vers la passerelle TS via le pare-feu principal. Notez que, si nécessaire, le pare-feu de couche 7 peut également rechiffrer les trames avant de les envoyer à la passerelle TS. Cette approche peut ne pas être nécessaire sur le réseau privé d'une organisation, mais elle peut être très utile dans des centres de données hébergés ou des réseaux partagés.

Figure 2 Utilisation d'un pare-feu de couche d'application avec un périphérique de passerelle TS

Figure 2** Utilisation d'un pare-feu de couche d'application avec un périphérique de passerelle TS **(Cliquer sur l'image pour l'agrandir)

Cette conception évite les deux inconvénients de la solution précédente. Dans la mesure où le serveur de passerelle TS reçoit uniquement le trafic qui a été inspecté par le pare-feu de couche 7, le risque de transmission d'attaques véhiculées par Internet est moins élevé. Le pare-feu de couche 7 devrait filtrer ces attaques et ne renvoyer que le trafic propre et inspecté à la passerelle.

Le deuxième avantage majeur de cette solution réside dans la position de la passerelle par rapport au réseau interne. Comme le trafic provenant d'Internet est inspecté par le pare-feu de couche 7 avant d'atteindre la passerelle, il peut rester sur le réseau interne et avoir directement accès aux contrôleurs de domaine pour les hôtes d'authentification et RDP pour les sessions utilisateur. De plus, le pare-feu principal peut avoir une stratégie beaucoup plus restrictive. Au lieu d'autoriser le trafic RDP et le trafic d'authentification d'annuaire, il doit simplement autoriser les sessions RDP entre du pare-feu de couche 7 et la passerelle TS. L'utilisation d'un pare-feu de couche 7 frontal dans votre déploiement de passerelle TS offre une solution plus sécurisée, qui est plus facile à gérer sans qu'il soit nécessaire de revoir la conception de votre réseau de périmètre existant.

Intégration NAP

Ressources pour les services Terminal Server

Bien qu'une bonne conception de périmètre soit un élément clé de votre solution d'accès à distance, il est également important de garantir la conformité et la sécurité de vos périphériques de point de terminaison. RDP étant un protocole riche qui autorise un grand nombre de types de réacheminement de périphérique, tels que les sessions RDP et les imprimantes, il est essentiel que les clients se connectant à votre solution se conforment aux stratégies de sécurité de votre organisation. Par exemple, même avec une topologie de réseau sécurisée basée sur les meilleures pratiques comme celles décrites précédemment, un utilisateur final se connectant à un serveur Terminal Server à partir d'un ordinateur non sécurisé peut finir par perdre des données confidentielles ou placer des fichiers malveillants sur le serveur Terminal Server. Bien que la quantité de connectivité et les dommages potentiels soient considérablement moindres que si cet utilisateur se connecte via un VPN de couche 3, il reste important de gérer le risque de perte de données et de garantir la conformité à vos stratégies informatiques.

La protection d'accès réseau (NAP) est une nouvelle technologie de Windows Server 2008 qui vous permet de contrôler non seulement qui peut se connecter à votre réseau, mais aussi à partir de quels genres de systèmes les utilisateurs autorisés peuvent se connecter. Par exemple, vous pouvez utiliser NAP pour garantir que seuls les ordinateurs ayant un pare-feu en cours d'exécution et un logiciel antivirus à jour puissent se connecter au réseau. NAP est une solution extensible qui ne couvre pas seulement le réseau interne de l'organisation, mais également les utilisateurs à distance, y compris ceux qui se connectent via des VPN de couche 3 et ceux qui se connectent via la passerelle TS. En intégrant NAP à votre conception de passerelle TS, vous pouvez vous assurer que seuls les systèmes conformes à vos stratégies de sécurité peuvent se connecter. Pour plus de détails sur NAP, consultez mon article Vigilance sécurité du numéro de mai 2007 de TechNet Magazine, disponible en ligne à l'adresse technetmagazine.com/issues/2007/05/SecurityWatch.

L'intégration de NAP à un déploiement de passerelle TS est un processus simple qui implique l'ajout d'un seul service supplémentaire à la conception. Ce service, appelé Network Policy Server (NPS), peut être installé soit sur le serveur de passerelle TS lui-même, soit sur une instance distincte du système d'exploitation. La console MMC de la passerelle TS est ensuite utilisée pour créer les stratégies d'autorisation des connexions (CAP) qui définissent quelles fonctionnalités RDP sont autorisées pour un état d'intégrité donné. Le serveur de passerelle TS est configuré pour vérifier auprès du service NPS chaque fois qu'une nouvelle connexion est tentée et pour transférer la déclaration d'intégrité (SoH) de cette connexion à NPS. Le service NPS compare ensuite la SoH à ses stratégies et indique à la passerelle TS si la connexion doit être autorisée en fonction de l'intégrité du client.

Comme l'illustre la figure 3, si un système non conforme n'est pas configuré pour utiliser Windows Update, mais que la stratégie de sécurité de l'organisation requiert que les mises à jour automatiques soient activées, lorsqu'un utilisateur tente de se connecter à la passerelle TS, son ordinateur génère et transfère une SoH. Cette SoH comprend des informations du type, « Mon pare-feu est activé et mon antivirus est à jour, mais les mises à jour automatiques sont désactivées ». La passerelle TS transfère alors cette SoH au service NPS (la passerelle TS n'a pas de logique lui permettant de décoder seule la SoH), et le service NPS compare la déclaration SoH aux stratégies définies par son administrateur. Dans la mesure où les mises à jour automatiques ont été désactivées, le service NPS détermine que la connexion est conforme à la stratégie de « non conformité » et indique à la passerelle TS de ne pas autoriser la connexion. La passerelle TS arrête la connexion et notifie l'utilisateur que l'ordinateur n'est pas conforme aux stratégies de sécurité de l'organisation. L'utilisateur peut alors prendre les mesures de correction nécessaires (dans ce cas, en activant les mises à jour automatiques) avant de faire une nouvelle tentative de connexion. Une nouvelle SoH est alors générée, le serveur NPS détermine la conformité et la passerelle TS autorise la connexion.

Figure 3 Seuls les systèmes conformes peuvent se connecter

Figure 3** Seuls les systèmes conformes peuvent se connecter **(Cliquer sur l'image pour l'agrandir)

Conclusion

Windows Server 2008 inclut les composants clés d'une solution d'accès à distance sécurisée. La passerelle TS fournit une méthode sécurisée pour la tunnelisation des sessions de bureau à distance sur Internet et offre aux organisations une grande liberté de choix dans la façon dont ces sessions sont intégrées à leurs réseaux existants. Les options consistent soit à placer la passerelle TS directement sur le réseau de périmètre, soit à utiliser devant elle un pare-feu de couche 7, comme ISA Server ou Intelligent Application Gateway. NAP peut être associé à la passerelle TS pour ajouter des fonctionnalités d'inspection de l'intégrité des points de terminaison à la solution. Les vérifications de point de terminaison permettent aux organisations de s'assurer non seulement que les connexions à distance proviennent d'utilisateurs valides, mais également qu'elles proviennent d'ordinateurs qui sont conformes à leurs stratégies de sécurité informatique. Lorsqu'elles sont utilisées ensemble, ces technologies fournissent aux organisations des fonctionnalités d'accès à distance plus sécurisées et plus efficaces qui offrent une meilleure expérience aux utilisateurs finaux. Vous trouverez de nombreuses informations complémentaires sur les sites indiqués dans l'encadré « Ressources pour les services Terminal Server ».

John Morello est chez Microsoft depuis 2000. En tant que consultant senior, il a conçu des solutions de sécurité pour des entreprises figurant dans le classement Fortune 100 ainsi que des clients civils et militaires de l'administration fédérale. Il est actuellement responsable de programme senior au sein du groupe Windows Server qui se consacre aux technologies de sécurité et d’accès à distance. Vous pouvez lire le blog de son équipe à l'adresse blogs.technet.com/WinCAT.

© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.