RDP ou VPN : ce dont vos serveurs ont vraiment besoin

La comparaison qu'on croit faire

« RDP ou VPN » sonne comme un choix entre deux technologies d'accès distant. Ce n'en est pas un : un VPN ne remplace pas RDP, il décide qui a le droit de l'atteindre. Au bout, vous utilisez toujours le Bureau à distance. La vraie question est de savoir si le service RDP écoute internet tout entier ou un réseau privé dont vous contrôlez la porte.

Ainsi posée, la comparaison sécuritaire n'est pas serrée. Un VPN supprime l'exposition ; RDP direct la gère. Tout guide de durcissement sérieux dit d'utiliser le VPN, et tout guide de durcissement sérieux a raison.

Et pourtant un nombre considérable de serveurs de production sont exposés directement, tenus par des gens qui ont lu ces guides. Cela mérite d'être pris au sérieux plutôt qu'écarté, car les raisons sont généralement réelles.

Ce qu'un VPN change réellement

Placez un VPN devant, et le service RDP n'est plus joignable depuis internet. Ce seul fait supprime toute une catégorie de problèmes :

• Les scanners cessent de vous trouver. Le volume de connexions échouées tombe pratiquement à zéro, et votre journal de sécurité redevient lisible.
• Les vulnérabilités de RDP exploitables avant authentification cessent d'être urgentes. Si aucun non-authentifié ne peut atteindre le service, la prochaine CVE RDP est un correctif que vous planifiez, pas un incident que vous gérez.
• Les attaques par identifiants doivent d'abord franchir l'authentification du VPN : un endroit de plus où imposer le multifacteur, et un journal de plus à relire.
• Vous obtenez un point d'entrée unique et auditable au lieu d'un service exposé indépendamment sur chaque serveur.

Ce que coûte l'exploitation

Si les VPN sont recommandés sans être adoptés, c'est que le coût est opérationnel plutôt que financier, et qu'il retombe sur des personnes plutôt que sur des budgets.

Chaque personne ayant besoin d'un accès a besoin d'un client, d'identifiants et d'une configuration fonctionnelle — y compris le prestataire venu pour deux semaines, la collègue sur son téléphone, et celui qui est d'astreinte à trois heures du matin depuis un réseau d'hôtel qui bloque le port du VPN.

Le VPN lui-même devient une infrastructure critique. Quand il tombe, plus personne n'atteint rien, y compris ceux qui doivent le réparer. Il faut le superviser, le corriger, lui prévoir sa propre voie d'accès de secours ; et des équipements VPN ont eux-mêmes servi de porte d'entrée dans plusieurs brèches majeures.

Enfin, il existe un mode de défaillance propre aux organisations qui l'adoptent à moitié : le VPN est installé, un serveur reste exposé directement « temporairement » pour qu'un client puisse se connecter, et cette exception survit à tous ceux qui se souviennent de l'avoir acceptée. Une exposition directe documentée et défendue est plus sûre qu'une exposition non documentée derrière un VPN que personne n'audite.

Quand RDP direct est le choix défendable

Ce n'est pas une concession : il existe des situations où c'est réellement la meilleure décision d'ingénierie.

Quand les personnes ayant besoin d'accès échappent à votre contrôle. Serveurs appartenant au client, prestataires externes, agences qui se passent des machines : vous ne pouvez pas délivrer d'identifiants VPN à une organisation que vous n'administrez pas.

Quand vous exploitez un ou quelques serveurs. Monter et maintenir une infrastructure VPN pour protéger deux machines est un mauvais compromis, et le VPN devient l'élément le plus susceptible de tomber.

Quand l'accès doit fonctionner de partout, immédiatement. Les réseaux d'hôtels et d'entreprises bloquent les protocoles VPN assez souvent pour que « je n'arrive pas à me connecter » pendant un incident soit un vrai risque opérationnel.

Dans ces cas, la position honnête est : le service est exposé, et il lui faut des mesures compensatoires réellement en place — MFA sur chaque compte, NLA, correctifs à jour, et bannissement automatique des sources qui échouent de façon répétée. Cette combinaison est nettement plus solide qu'un VPN que la moitié de l'équipe contourne.

Les options intermédiaires

Le choix n'est pas binaire, et c'est au milieu que finissent la plupart des parcs bien tenus.

• Passerelle Bureau à distance (RD Gateway) — tunnelise RDP sur HTTPS en 443, fonctionne donc depuis des réseaux qui bloquent tout le reste, et donne un point d'entrée unique, authentifié et journalisé. Proche du VPN par le bénéfice, proche de RDP par le coût d'exploitation.
• Un bastion ou jump host — une seule machine durcie et étroitement surveillée est exposée ; tout le reste n'est joignable que depuis elle. Concentre le risque là où vous pouvez vous permettre de regarder de près.
• Gestionnaires de session des fournisseurs cloud — accès par navigateur ou agent, sans aucun port entrant. Excellent là où vos serveurs vivent chez un fournisseur qui le propose, indisponible ailleurs.
• Zero-trust network access — accès par application, conscient de l'identité, sans tunnel de niveau réseau. La direction que prend le secteur, avec l'abonnement et le coût d'intégration correspondants.
• RDP restreint par source — pas de tunnel, juste un pare-feu qui n'autorise qu'une courte liste d'adresses connues. La mesure réelle la moins chère qui soit, et elle tient jusqu'au jour où quelqu'un se déplace.

Choisir

Deux questions tranchent dans la plupart des cas. Chaque personne ayant besoin d'un accès peut-elle joindre un VPN de façon fiable, depuis chaque réseau d'où elle travaille ? Et avez-vous quelqu'un qui maintiendra ce VPN corrigé et supervisé ?

Deux oui : prenez le VPN, et arrêtez-vous là. C'est la conception la plus solide et le coût est portable.

Un seul non : reconnaissez que le service est exposé, et construisez correctement les mesures compensatoires plutôt que d'adopter un VPN qui sera contourné. Cela signifie MFA partout, NLA activé, correctifs à jour, compte Administrator intégré désactivé, et bannissement automatique au pare-feu des sources qui échouent de façon répétée.

RDP Protector couvre ce dernier point pour les serveurs qui restent joignables — bannissements par sous-réseau, permanents et résistants au redémarrage, votre propre adresse en liste blanche avant tout blocage, et ports détectés depuis le registre plutôt que supposés. Il vaut aussi la peine derrière un VPN, car les connexions échouées restantes viennent alors de l'intérieur de votre périmètre, et c'est exactement le trafic dont vous voulez être informé.