Installer un client distinct pour chaque type d'accès n'est pas durable. Un logiciel pour le VPN, un autre client pour le VDI, un outil dédié pour le RDP, un terminal pour le SSH, un kubeconfig pour Kubernetes, des tableaux de mots de passe partagés pour les anciens systèmes… Ce modèle porte les habitudes du passé, non les besoins de sécurité modernes.
Avec le temps, chaque ordinateur portable devient un petit chaos d'accès. Les agents s'accumulent, les mises à jour prennent du retard, les équipes de support se débattent avec des problèmes d'installation, les mots de passe privilégiés se rapprochent des appareils des utilisateurs. L'organisation croit accorder l'accès ; en réalité elle disperse le contrôle.
De plus, tous les appareils ne peuvent pas porter cette charge. Un Chromebook, un kiosque, un appareil mobile ou l'ordinateur d'un prestataire ne peut souvent pas exécuter les clients nécessaires. Pour que le travail ne s'arrête pas, des exceptions sont ouvertes, et les contournements temporaires deviennent permanents.
Le point le plus faible de cette architecture, c'est l'audit. L'enregistrement de session, le watermark à l'écran, le DLP du presse-papiers, le contrôle des transferts de fichiers et l'évaluation in-session du risque ne font pas partie intégrante de l'accès. Ils sont rapiécés par des produits ajoutés après coup.
L'accès distant ne doit pas être la somme d'outils séparés. Il doit y avoir une seule identité, un seul portail, une seule couche d'audit et un seul chemin d'accès sécurisé.
Cinq protocoles sont rendus dans le navigateur via un seul endpoint HTTPS ; la couche d'audit et de politique d'entreprise est placée directement à l'intérieur de la gateway.
RDP, VNC, SSH, Kubernetes exec et Telnet sont rendus dans le navigateur existant de l'utilisateur sur un canvas HTML5 et un terminal. Chromebook, poste de travail restreint, appareil mobile, ordinateur de prestataire — tout appareil doté d'un navigateur moderne devient un poste de travail pleinement habilité.
La gateway termine les cinq protocoles derrière un seul endpoint WebSocket protégé par TLS. Les règles de pare-feu se réduisent à une seule ligne, l'exposition au niveau réseau se réduit à un seul port, et les équipes distantes ne courent plus après l'UDP, le port 3389 ou les exceptions de split-tunnel.
Les identifiants du système cible sont conservés dans un coffre-fort et injectés au moment où la session démarre. L'utilisateur entre dans le portail avec sa propre identité et le MFA ; la gateway récupère l'identifiant privilégié au moment du lancement et le remet directement au moteur de protocole. La rotation, la mise au rebut et la gestion des mots de passe par session deviennent automatiques.
Chaque session peut être enregistrée en MP4 standard, chaque image est watermarkée avec l'identité de l'opérateur et évaluée en continu par rapport à la politique. Les frappes clavier et les événements de presse-papiers sont journalisés avec un masquage basé sur regex pour les motifs de mots de passe et de PII. La gateway qui rend la session est aussi la propriétaire de la piste d'audit.
Cinq protocoles, plus la couche d'entreprise que nous avons construite par-dessus.
Network Level Authentication, session protégée par TLS, redirection de lecteurs, prise en charge du son et du presse-papiers, résolution dynamique et redirection d'imprimante sont entièrement intégrés. La fonctionnalité RemoteApp publie une seule application Windows (un client ERP, AutoCAD, un ancien logiciel de comptabilité) sous forme de fenêtre dans le navigateur de l'utilisateur — pas de bureau complet, pas d'exposition de la barre des tâches, applications annexes invisibles. Modernisation du legacy sans la charge du VDI.
Fonctionne avec TightVNC, RealVNC, UltraVNC, x11vnc et tous les serveurs compatibles RFB. Plusieurs schémas d'authentification (mot de passe, ARD, VeNCrypt avec TLS), presse-papiers bidirectionnel, modes de rendu du curseur et réglage de la profondeur de couleur pour les faibles bandes passantes. Les bureaux Mac et Linux dotés d'un partage d'écran intégré deviennent des cibles de portail de première classe.
Terminal entièrement compatible xterm ; établi avec authentification par clé, agent, mot de passe et certificat. Le SFTP fonctionne via la même connexion SSH — un panneau de fichiers intégré permet à l'utilisateur de téléverser des fichiers par glisser-déposer, ou d'en sélectionner et télécharger, sans quitter le navigateur. Les paramètres locaux et dispositions clavier sont traités naturellement, le texte de session peut être recherché et copié comme n'importe quelle page web.
Les opérateurs obtiennent un shell interactif dans n'importe quel pod, à portée d'un namespace et d'un conteneur, via l'endpoint exec de l'API Kubernetes. Aucun kubectl à installer, aucun fichier kubeconfig à distribuer, aucun service-account à laisser fuir sur un ordinateur portable. Le RBAC est configuré une fois dans le portail, l'audit a lieu dans la gateway, et les SRE accèdent au cluster depuis n'importe quel navigateur.
Certains actifs attendent encore Telnet — Cisco IOS antérieur à SSH, HMI OT/SCADA, gateways mainframe. Le portail les traite avec la même couche de rendu, d'audit et de watermark que les autres protocoles. Telnet s'active de façon optionnelle selon la politique ; l'opérateur voit un avertissement clair lorsqu'il démarre un protocole en clair.
Les identifiants privilégiés du système cible restent dans le coffre-fort de la plateforme, jamais sur l'appareil de l'utilisateur. Lorsqu'une session démarre, la gateway récupère l'identifiant depuis le coffre-fort, le remet au moteur de protocole ; l'utilisateur ouvre la session sans voir ni saisir le mot de passe. La rotation suit le calendrier défini par l'opérateur — elle peut même avoir lieu après chaque session si l'actif l'exige.
L'enregistrement se configure par actif, par groupe d'utilisateurs ou par session — les administrateurs décident où il est obligatoire (systèmes soumis à conformité, prestataires tiers) et où il est optionnel. La sortie est écrite en MP4 H.264 standard dans le stockage local de la gateway, avec des contrôles de rétention. Les enregistrements sont recherchables par utilisateur, actif et horodatage ; les auditeurs peuvent rejouer chaque session directement dans le navigateur.
Chaque image rendue porte un watermark dont les composantes proviennent du contexte vivant de la session (identité de l'opérateur, IP source, nom de l'actif, horodatage). Le modèle est défini par l'administrateur. Le watermark est traité côté serveur dans le flux ; aucun bloqueur de publicité ou manipulation du DOM côté client ne peut le retirer. Il dissuade la prise de photo de l'écran, rend les captures d'écran fuitées traçables et rappelle que chaque action est observée.
La couche d'audit et de politique qui transforme l'accès sans client en un contrôle d'accès privilégié de niveau entreprise.
Chaque session active est réévaluée en continu par rapport à la politique d'accès conditionnel appliquée au lancement. Si l'IP de l'opérateur change de pays, si le score de confiance du terminal baisse, si l'appareil sort de la posture gérée ou si le comportement devient anormal, la gateway peut interrompre la session, demander un MFA supplémentaire, rétrograder la session en lecture seule ou alerter l'équipe sécurité — sans attendre la prochaine connexion.
Chaque frappe clavier, chaque événement de presse-papiers et chaque transfert de fichier est journalisé avec le contexte de session, d'actif et d'horodatage. Les motifs sensibles — heuristiques de complexité de mot de passe, numéros de carte de crédit, identifiants nationaux et regex personnalisés — sont masqués automatiquement avant d'atteindre le journal. La piste d'audit reste complète sans devenir une source secondaire de fuite.
Le contenu du presse-papiers qui transite entre le navigateur de l'utilisateur et l'actif distant est contrôlé par rapport à la politique. Les administrateurs n'autorisent que la copie entrante sur les actifs réglementés, ferment complètement le presse-papiers ou masquent en ligne les motifs correspondants — par exemple en caviardant les numéros de carte de crédit dans le texte collé vers l'extérieur sans altérer le reste du texte.
Le téléversement et le téléchargement sont des autorisations distinctes, configurées par actif et par rôle. Limites de taille, liste de types MIME autorisés, analyse antivirus via le moteur d'inspection WAAP de la plateforme et journal d'audit par transfert — cela transforme un canal d'exfiltration normalement invisible en un canal contrôlé et observable.
Les actifs à haute sensibilité peuvent exiger un score de confiance minimal du composant endpoint trust manager (ETM) de la plateforme pour que le bouton de lancement puisse être actif. L'ordinateur d'un prestataire sans chiffrement de disque, un appareil personnel aux correctifs manquants ou un poste de travail signalé pour logiciel malveillant n'atteint même pas la page de lancement de ces actifs — sans que l'opérateur n'ait à se souvenir de règles distinctes.
Les opérateurs autorisés peuvent rejoindre une session en cours en tant que second observateur — pour une observation silencieuse ou un accompagnement interactif. Les administrateurs juniors reçoivent une formation en situation, les équipes sécurité examinent une activité suspecte en temps réel, et les équipes de réponse aux incidents accèdent à l'écran en direct plutôt qu'à partir d'un enregistrement après coup.
Les systèmes relevant de PCI-DSS, HIPAA, GDPR, ISO 27001 exigent que chaque session privilégiée soit enregistrée, watermarkée et traçable à un opérateur nommé. Le portail en fait le comportement par défaut pour les actifs qui importent à l'auditeur ; pour les autres actifs, il s'efface.
Les prestataires obtiennent un accès restreint et limité dans le temps à des actifs précis — jamais au réseau, jamais à un mot de passe administrateur partagé, jamais à un compte VPN à longue durée de vie. Chaque session est enregistrée, watermarkée avec l'identité du prestataire et visible dans la file de support pour un audit en direct.
Les SRE atteignent n'importe quel pod de n'importe quel cluster depuis n'importe quel navigateur — sans installation de kubectl, sans distribution de kubeconfig ni jetons de service-account de cluster circulant sur les ordinateurs portables. Le RBAC, l'audit et la politique vivent dans le portail ; ils ne se dispersent pas dans les outils en ligne de commande.
Un ancien client ERP Windows est publié via RDP RemoteApp ; un appareil Cisco antérieur à SSH est ouvert via Telnet avec enregistrement obligatoire ; un HMI sur un réseau OT segmenté ne devient accessible que via le portail audité. Les anciens actifs continuent de fonctionner tandis que l'accès se modernise autour d'eux.
Accès via le navigateur à RDP, VNC, SSH, Kubernetes et aux systèmes legacy — enregistrement, watermark, coffre-fort et politique intégrés. Nous vous guidons dans une installation en direct sur vos propres actifs.