Redirection SSH, VPN ou RD Gateway : quel chemin pour un bureau RDP ?

Les trois options transportent RDP, le protocole n’est donc pas le facteur décisif. La vraie question est de savoir quelle accessibilité un utilisateur doit obtenir et qui exploite ce qui la lui accorde. Un port TCP redirigé, un réseau privé routé et une passerelle de bureau répondent à cette question en trois tailles différentes. Choisissez d’abord la taille et le produit suivra.

La question est la portée, pas le protocole

Notez ce que l’utilisateur doit réellement toucher. Si la réponse est un seul bureau, une conception qui accorde un sous-réseau est trop large. Si la réponse est un bureau plus des partages de fichiers plus une console d’administration, une conception qui redirige un port reviendra le mois prochain pour deux redirections de plus. La liste des destinations est l’exigence ; tout le reste est de la mise en œuvre.

Gardez l’identité d’entrée séparée du compte Windows qui ouvre la session sur le bureau. Chaque conception ci-dessous a les deux, et les confondre est la façon dont un compte d’hôte de rebond finit avec plus d’autorité que quiconque ne l’avait prévu.

Un service TCP redirigé

Un hôte de rebond SSH approuvé peut rediriger un écouteur local vers le service RDP qu’il peut atteindre. Liez cet écouteur à loopback lorsqu’il n’existe que pour la machine de l’utilisateur, ce qui est l’intention normale d’une redirection locale. La redirection est une commodité pour une personne, pas un service pour une équipe.

La connexion SSH authentifie l’accès au chemin de redirection, et rien de plus. L’authentification Windows et l’autorisation RDP ont toujours lieu à la destination, donc un compte de rebond valide n’est pas une session de bureau valide. Ce sont deux portes indépendantes et les deux doivent s’ouvrir.

Restreignez les destinations de redirection du compte de rebond au lieu d’accorder un shell sans restriction. Cette conception convient à un petit ensemble de machines explicitement listé, et elle ajoute un hôte, une identité et un cycle de vie à exploiter. Cet hôte supplémentaire est la partie que les gens oublient lorsqu’ils la comparent à une passerelle : quelqu’un doit le corriger, le surveiller et posséder ses clés.

Un espace de travail privé routé

Un VPN fournit un DNS privé et l’accès à plusieurs services utilisés ensemble, et c’est sa valeur réelle. Masquer un port de bureau est un effet secondaire, pas la raison de le construire. Cette distinction compte quand quelqu’un demande pourquoi le VPN existe.

Restreignez les routes et les autorisations de ressources aux destinations prévues. Un utilisateur connecté ne mérite pas automatiquement tout le LAN, et le pare-feu de destination plus les droits de connexion Windows restent des frontières distinctes que le VPN ne remplace pas.

Cette disposition est pratique pour un espace de travail géré déjà établi. Le coût est que l’intégration, les exigences d’appareil, le comportement du résolveur et la politique de connexion font partie de l’environnement de travail de l’utilisateur, et que quelqu’un doit en être responsable. Comparez ce coût à la licence de la passerelle avant de supposer que le VPN est l’option la moins chère.

Une passerelle spécifique à RDP

Remote Desktop Gateway fournit une frontière spécifique à RDP plutôt qu’une frontière réseau. Sa politique d’autorisation des connexions décide qui peut se connecter, et sa politique d’autorisation des ressources décide des ressources internes qu’ils peuvent atteindre par son intermédiaire. Les deux politiques font partie du produit, pas des options.

Planifiez ensemble les certificats, l’intégration d’identité et les transports requis. La passerelle n’est pas un relais TCP anonyme, et la déployer comme tel contourne les politiques qui la justifient. Elle porte aussi des exigences de licence et d’exploitation qu’un seul port redirigé n’a pas. Budgétez-les avant la revue de conception, pas après.

Là où une équipe exploite déjà un accès centralisé aux bureaux, ce coût est déjà payé. Là où une personne a besoin d’une machine, c’est une grosse machine achetée pour un petit travail.

Ce dont les trois ont encore besoin

Conservez les contrôles d’identité d’hôte dans chaque conception. Un alias local ou un tunnel ne rend pas inoffensif un certificat inattendu, et accepter un certificat non concordant pour passer par un proxy anéantit l’intérêt du tunnel. Le nom dans le client et le nom sur le certificat doivent être conciliés délibérément.

Appliquez MFA au point d’entrée là où la politique l’exige, et conservez les contrôles de compte de la destination. Les deux sont complémentaires : le premier décide qui peut atteindre la porte, le second qui peut l’ouvrir. Omettre l’un ou l’autre laisse une conception qui semble complète et ne l’est pas.

Choisissez la frontière qui correspond au travail et au modèle d’exploitation que vous avez réellement. Vue d’ensemble des rôles RDS décrit la place de la passerelle parmi l’hôte de session et les autres composants, et c’est ce contexte qui rend son coût lisible.