Le bureau à distance est-il sécurisé ? Un modèle de menace honnête

« Le bureau à distance est-il sécurisé » n’a pas une réponse unique, cela dépend de quel bureau à distance on parle. Un RDP natif Windows exposé sur Internet est l’une des surfaces d’attaque les plus abusées en IT d’entreprise, il apparaît chaque année dans la section ransomware du DBIR de Verizon. Un client moderne basé sur des relais comme Tenvo, AnyDesk ou TeamViewer, qui n’expose jamais de port à l’écoute sur Internet, présente une posture de sécurité fondamentalement différente. Cet article décrit honnêtement le modèle de menace : ce qui est réellement protégé, ce qui ne l’est pas, et ce que vous devez vérifier avant d’installer un outil de bureau à distance.

TL;DR : Le chiffrement du transport (AES-256-GCM) et l’échange de clés (X25519 + ED25519 pour les signatures) sont aujourd’hui le minimum requis, la plupart des outils réputés les ont. La variation intéressante porte sur ce que le relais peut voir, la gestion de l’accès sans surveillance, l’application de la 2FA, et la possibilité d’auditer le code source. Allez à la check-list en 5 points à la fin si vous voulez juste les actions à mener.

Le modèle de menace : contre quoi vous défendez-vous réellement ?

Trois classes d’adversaires sont pertinentes pour le bureau à distance :

• Attaquant réseau (passif ou MITM actif). Quelqu’un sur le même Wi‑Fi, un nœud de sortie VPN malveillant, un acteur étatique faisant de l’interception TLS à grande échelle. Il cherche à lire ou modifier le trafic entre le client et l’hôte.
• Attaquant d’identifiants. Quelqu’un qui tente de se connecter à distance au mot de passe d’accès sans surveillance. Attaque par force brute, credential stuffing, recherche dans des bases de données compromises.
• Attaquant fournisseur / relais. L’entreprise de bureau à distance elle‑même, ou quelqu’un qui l’a compromise. Ils se trouvent au milieu par définition : que peuvent‑ils réellement voir ?

Une quatrième classe, la compromission d’un endpoint (malware sur une des machines), bat tous les outils de bureau à distance existants. Si votre PC local est compromis, aucun protocole de chiffrement ne vous sauve. Nous n’aborderons pas cela ici car c’est hors du champ du protocole lui‑même.

Chiffrement du transport : AES-256-GCM

Tenvo chiffre la connexion avec TLS et un certificat par appareil. L’algorithme le plus discuté dans ce contexte est AES-256-GCM, un mode de chiffrement authentifié qui protège à la fois la confidentialité (pas d’écoute) et l’intégrité (pas de falsification). GCM est le même mode que TLS 1.3 utilise, celui que votre banque utilise, et que le protocole Signal utilise pour la couche symétrique. À ce jour (2026), il n’existe pas d’attaque pratique connue contre AES-256-GCM.

La clé de session fait 256 bits, est dérivée par session et n’est jamais réutilisée. Même si une clé était récupérée a posteriori, seule cette session serait compromise ; les sessions passées et futures sont indépendantes.

Échange de clés : X25519 + ED25519

Comment les deux clients conviennent‑ils d’une clé de session sans que le relais l’apprenne ? X25519, un Diffie‑Hellman à courbe elliptique sur Curve25519. Chaque côté génère une paire de clés éphémères, échange les clés publiques via le relais, et calcule indépendamment le même secret partagé en utilisant sa clé privée et la clé publique de l’autre côté. Le relais ne voit que les valeurs publiques, inutiles sans l’une des clés privées.

Pour empêcher un MITM actif (un relais malveillant ou compromis qui remplacerait les clés publiques en vol), l’identité publique de l’hôte est signée avec ED25519. La première fois que vous vous connectez à un hôte, Tenvo affiche l’empreinte de la clé de l’hôte : c’est le modèle de confiance au premier usage (trust‑on‑first‑use, TOFU), comme SSH. Lors des connexions suivantes, le client vérifie que l’empreinte correspond ; si un relais tentait de vous intercepter, l’empreinte changerait et le client refuserait la connexion.

X25519 + ED25519 est le même ensemble de primitives utilisé par WireGuard, Signal, age et SSH moderne. C’est largement audité et considéré comme la pratique recommandée actuelle.

Ce que le relais voit réellement

C’est la question qui distingue vraiment les outils de bureau à distance. Certains produits terminent TLS au relais puis ré‑encryptent vers le client : cela signifie que le fournisseur peut techniquement déchiffrer votre session. Demandez quel modèle s’applique à l’outil que vous évaluez, y compris à celui-ci : Tenvo est de bout en bout sur une connexion pair‑à‑pair directe, et termine TLS au relais quand une connexion directe ne peut pas être établie.

Deux remarques sur le tableau. Premièrement, « vendor claims relay sees ciphertext only » est une affirmation qu’il faut prendre pour parole d’auteur pour les produits propriétaires : sans accès au code source, vous ne pouvez pas la vérifier. Deuxièmement, le VNC classique sur Internet est l’option la plus mauvaise de cette liste : de nombreuses variantes de VNC sont livrées sans chiffrement de transport par défaut, et les identifiants sont envoyés dans un challenge‑response qui est cassé depuis des années. Ne lancez pas du VNC non chiffré sur Internet.

Authentification : mots de passe vs 2FA

Pour l’accès sans surveillance (où vous définissez un mot de passe sur l’hôte afin de pouvoir vous connecter ultérieurement sans que quelqu’un accepte la demande), le mot de passe constitue toute la défense. Deux modes d’échec :

1. Mot de passe faible : Un code PIN à 4 chiffres est brute‑forcé en quelques secondes. Un mot de passe alphanumérique de 6 caractères peut être brute‑forcé en quelques heures si l’attaquant a accès au réseau. Utilisez 12+ caractères générés par un gestionnaire de mots de passe. Tenvo impose un minimum de 6 caractères et alerte sur les mots de passe courants ; nous recommandons 16+ pour tout hôte accessible depuis Internet.
2. Absence de second facteur : Si le mot de passe fuit, c’est toute l’authentification qui tombe. Activez la 2FA si votre outil le supporte ; Tenvo prend en charge le TOTP pour les niveaux payants. AnyDesk et TeamViewer proposent des offres similaires.

Pour les sessions d’assistance interactives (où quelqu’un vous lit un code à usage unique), la menace est beaucoup plus faible car la session est bornée dans le temps et le code expire. L’attaque classique ici est l’ingénierie sociale qui pousse la victime à lire le code à des arnaqueurs : les escroqueries « support technique » utilisent exactement ce vecteur, et aucune cryptographie ne le corrige.

Risque de l’accès sans surveillance

L’accès sans surveillance est la fonctionnalité la plus utile et la plus risquée. Par définition, vous laissez un identifiant sur l’hôte qui, s’il fuit, permet à quiconque de se connecter à distance sans invitation. Bonnes pratiques recommandées :

• Utilisez un mot de passe unique par hôte. Ne réutilisez pas le mot de passe entre machines.
• Activez la 2FA lorsque c’est supporté.
• Définissez un délai d’inactivité pour que les sessions sans surveillance inactives se déconnectent. Tenvo par défaut coupe au bout de 4 heures.
• Utilisez la liste blanche d’accès, limitez les connexions entrantes à des identifiants d’appareils précis que vous contrôlez. Tenvo le prend en charge dans les paramètres de sécurité.
• Consultez périodiquement le journal de connexions. Des connexions inattendues sont un signal d’alerte.

Pourquoi RDP natif exposé sur Internet est particulièrement mauvais

RDP en soi n’est pas intrinsèquement insecure : Microsoft a considérablement durci le protocole, et les versions récentes utilisent CredSSP protégé par TLS. Le problème est opérationnel. RDP écoute sur un port bien connu (3389), est généralement authentifié seulement par un mot de passe Windows, et fait l’objet d’un balayage constant pour force brute. Une fois l’attaquant dedans, il dispose d’une session Windows interactive connectée, le point d’appui le plus utile pour déployer un ransomware. C’est pourquoi CISA et le FBI désignent spécifiquement le RDP exposé comme un des trois principaux vecteurs d’accès initial au ransomware. Des outils comme Tenvo, AnyDesk et TeamViewer évitent totalement ce problème en n’exposant jamais un service à l’écoute sur Internet.

La check-list en 5 points pour tout outil de bureau à distance

Quel que soit l’outil que vous choisissez, vérifiez ces cinq points avant de lui confier quoi que ce soit d’important :

1. Chiffrement de bout en bout du transport avec AES-256 ou ChaCha20-Poly1305. Tout autre chose (pas de chiffrement, RC4, VNC non protégé) disqualifie l’outil. Lisez la documentation technique, pas seulement la page marketing.
2. Échange de clés à secret avancé (Diffie‑Hellman d’une forme ou d’une autre). X25519 est le défaut moderne. ECDH P‑256 est acceptable. Un échange statique par RSA est un signal d’alerte.
3. Modèle de relais documenté : le fournisseur voit‑il le ciphertext ou le plaintext ? Lisez leur whitepaper de sécurité. S’ils ne peuvent pas répondre, partez.
4. Authentification à deux facteurs pour l’accès sans surveillance. Si votre outil n’offre pas la 2FA, n’activez pas l’accès sans surveillance sur des hôtes accessibles depuis Internet.
5. Code source ou audit tiers lisible. L’open source (comme Tenvo/RustDesk sous AGPL-3.0) est la preuve la plus forte. À défaut, un rapport SOC 2 Type II ou un pentest publié est acceptable.

Conclusion

« Le bureau à distance est-il sécurisé » est la mauvaise question. La bonne est : lequel des bureaux à distance, déployé comment. Un outil moderne basé sur des relais avec transport AES-256-GCM, échange de clés X25519, chiffrement de bout en bout au‑delà du relais et 2FA pour l’accès sans surveillance est à peu près aussi sûr que tout autre protocole Internet auquel vous faites confiance au quotidien. Un RDP exposé via un port redirigé avec un mot de passe faible ne l’est pas. Lisez l’architecture complète de sécurité de Tenvo pour les détails au niveau protocole, ou téléchargez le client et auditez‑le vous‑même, le code source est sur GitHub.

FAQ

L’équipe Tenvo peut‑elle lire mes sessions de bureau à distance ?
Cela dépend du chemin de routage. Une connexion pair‑à‑pair directe est chiffrée de bout en bout et nous ne pouvons pas la lire. Quand une connexion directe ne peut pas être établie, la session est relayée et TLS est terminé sur notre relais : nous ne enregistrons ni ne stockons le contenu des sessions, mais nous n’affirmerons pas qu’il est techniquement impossible pour nous de le voir. Le client est open source, vous pouvez donc vérifier cela plutôt que de nous croire sur parole.

L’open source est‑il réellement plus sûr que le code fermé ?
La disponibilité du code source est nécessaire mais pas suffisante. AGPL-3.0 permet à un auditeur indépendant de vérifier que le protocole correspond à la documentation ; les outils propriétaires exigent de faire confiance au fournisseur. Les deux peuvent être sécurisés si l’implémentation est bonne ; seul l’un est vérifiable.

Dois‑je m’inquiéter du modèle de fingerprint trust‑on‑first‑use ?
Seulement si vous établissez la connexion sur un réseau que vous ne maîtrisez pas. Pour les configurations paranoïaques, vérifiez l’empreinte de l’hôte hors bande (lisez‑la lors d’un appel téléphonique, pas via un chat) lors de la première connexion. Après cela, le client épingle l’empreinte localement.

Y a‑t‑il des CVE connus dans RustDesk / Tenvo ?
Le projet RustDesk a eu une poignée de problèmes divulgués au fil des ans, principalement dans les composants optionnels du serveur auto‑hébergé, corrigés rapidement dans chaque cas. Le client desktop lui‑même n’a eu aucun CVE d’exécution de code à distance de haute gravité à la date de mai 2026. Consultez la page des security advisories sur GitHub pour la liste à jour.

Quels modes de 2FA Tenvo supporte‑t‑il ?
TOTP via n’importe quelle application d’authentification standard (Authy, 1Password, Google Authenticator) aux niveaux Lite et Pro. Le support des clés matérielles (WebAuthn) est sur la feuille de route.