Qu'est-ce que Remote Browser Isolation comment fonctionne la RBI ?

Remote browser isolation RBI) exécute le contenu Web dans un conteneur cloud jetable plutôt que sur le terminal de l'utilisateur, garantissant ainsi qu'aucun code malveillant provenant de pages de phishing, d'exploits « zero-day » ou de téléchargements automatiques n'atteigne jamais l'appareil ou le réseau de l'entreprise. Pour les architectes de sécurité qui évaluent la technologie d'isolation du navigateur dans le cadre d'une stratégie « zero trust », le RBI offre un modèle de sécurité fondamentalement différent : plutôt que d'essayer de détecter chaque menace dans le trafic Web, il part du principe que tout contenu Web est non fiable et sépare physiquement l'exécution du terminal. Cette approche devient de plus en plus urgente à mesure que le navigateur devient l'espace de travail principal — et la principale surface d'attaque — dans toutes les entreprises.

Qu'est-ce que Remote Browser Isolation?

Remote browser isolation une technologie de cybersécurité qui sépare physiquement l'activité de navigation Web d'un utilisateur de son appareil local et du réseau de l'entreprise. Lorsqu'un utilisateur se rend sur un site Web, la page se charge et s'exécute à l'intérieur d'un conteneur cloud sécurisé et éphémère, plutôt que dans le navigateur de son ordinateur portable ou de son poste de travail. L'utilisateur voit et interagit avec une représentation visuelle sécurisée de la page ; tout le code sous-jacent (HTML, CSS, JavaScript, objets intégrés) reste confiné à l'environnement distant. À la fin de la session, le conteneur est détruit, ainsi que toute charge malveillante qu'il aurait pu rencontrer. Lorsqu'elle est fournie sous forme de service hébergé dans le cloud, cette technologie est connue sous le nom remote browser isolation.

Voici comment cela se passe concrètement : une directrice marketing reçoit un e-mail contenant un lien vers un soi-disant rapport sectoriel. Elle clique dessus. Au lieu que le lien s'ouvre directement dans Chrome sur son ordinateur portable, le trafic est acheminé via la secure web gateway, qui redirige l’URL non classée vers une session RBI. Un conteneur cloud jetable est lancé, charge la page et l’affiche. La directrice marketing voit une version entièrement interactive de la page — elle peut faire défiler, cliquer et lire — mais aucun contenu HTML, JavaScript ou exécutable n’atteint jamais son ordinateur. Si le lien mène à une page de phishing contenant une faille de type « zero day », le code malveillant s’exécute à l’intérieur du conteneur, qui est détruit à la fin de la session. Son terminal reste sain. Aucune exfiltration de données ne se produit. Le SOC n'aura peut-être jamais besoin de trier un incident, car l'attaque a été contenue avant même qu'elle ne commence.

Ce modèle s'écarte fondamentalement des systèmes de sécurité traditionnels basés sur la détection. Contrairement aux moteurs antivirus ou aux filtres de réputation d'URL qui s'appuient sur des modèles et des signatures de menaces connus, l'isolation du navigateur adopte une approche « zero trust » : elle considère tout contenu Web comme potentiellement hostile, quelle que soit sa réputation. Cette distinction est importante, car les outils traditionnels sont structurellement incapables de détecter les attaques « zero hour », c'est-à-dire les menaces qui ne disposent pas encore de signature.

Pourquoi Remote Browser Isolation aujourd'hui ?

Le navigateur n'est plus seulement une fenêtre sur Internet. C'est l'espace de travail de l'entreprise où convergent la messagerie électronique, les applications SaaS, les systèmes CRM, les plateformes financières et les outils d'IA. Cette concentration d'activités sensibles fait du navigateur une cible extrêmement attractive.

Près de la moitié des incidents de sécurité examinés en 2024 (44 %) impliquaient des activités malveillantes lancées ou facilitées par le biais des navigateurs des employés, notamment le phishing, l'utilisation abusive des redirections d'URL et le téléchargement de logiciels malveillants (Rapport 2025 d'Unit 42 sur la réponse aux incidents mondiaux). Par ailleurs, le rapport 2025 sur l'état de la sécurité des navigateurs publié par Menlo Security révèle une hausse de 140 % des attaques de phishing ciblant les navigateurs au cours de l'année écoulée, les incidents de phishing de type « zero hour » (des attaques trop récentes pour être répertoriées dans une base de signatures) ayant augmenté de 130 %.

Les répercussions financières sont considérables. Selon le rapport « Cost of a Data Breach » d'IBM, le coût moyen d'une violation de données à l'échelle mondiale s'élevait à 4,88 millions de dollars en 2024. Il a fallu en moyenne 292 jours pour détecter et contenir les attaques par usurpation d'identifiants. Bon nombre de ces chaînes de vol d'identifiants commencent dans le navigateur : un utilisateur accède à une page de phishing convaincante, saisit ses identifiants, et le pirate reste dans l'environnement pendant près de dix mois avant d'être neutralisé.

Prenons un scénario concret : un analyste financier travaillant dans une banque de taille moyenne reçoit une notification dans son navigateur qui semble provenir du système de gestion documentaire de la banque. Le lien redirige vers une copie conforme de la page de connexion, hébergée sur une plateforme cloud légitime afin de contourner les filtres de réputation des URL. En l'absence d'isolation du navigateur, l'analyste saisit ses identifiants et le pirate informatique accède aux systèmes internes. Avec le RBI en place, la page de phishing se charge à l'intérieur d'un conteneur cloud ; même si l'analyste tente de saisir ses identifiants, la session peut être configurée pour bloquer la saisie d'identifiants sur des domaines non classés ou supprimer entièrement les soumissions de formulaires. La chaîne d'attaque est interrompue dès le premier lien.

La norme NIST SP 800-46, révision 2, met en évidence le modèle de menace qui rend le RBI indispensable : ce document part du principe que les terminaux des télétravailleurs seront infectés par des logiciels malveillants et recommande la mise en place de contrôles à plusieurs niveaux, notamment des solutions d'accès au réseau qui vérifient l'état de sécurité du terminal avant d'accorder l'accès. Le RBI concrétise cette hypothèse en ne faisant jamais confiance au terminal pour traiter le contenu Web en toute sécurité.

Comment Remote Browser Isolation : trois approches de rendu

Toutes les solutions RBI partagent la même architecture de base : le contenu Web est récupéré et exécuté dans un environnement distant et isolé (généralement un conteneur cloud éphémère), et seule une représentation sécurisée de la page est transmise au navigateur local de l'utilisateur. La différence essentielle réside dans la manière dont cette représentation sécurisée est générée et transmise. Il existe trois approches principales.

Traitement des pixels (diffusion de pixels)

Cette approche permet de générer le contenu web sur un serveur distant et d'envoyer une représentation visuelle de la page web vers l'appareil de l'utilisateur sous la forme d'une image interactive ou d'un flux vidéo. On peut comparer cela à un flux vidéo en direct d'une session de navigation s'exécutant sur l'ordinateur d'une autre personne : l'appareil de l'utilisateur fait office de simple terminal d'affichage.

Avantage en matière de sécurité : isolation maximale. Aucun code Web ni script d'origine n'atteint jamais le terminal. Tous les vecteurs d'attaque potentiels intégrés au code du site restent isolés sur le serveur distant.

Inconvénient : l'encodage et la transmission en continu de flux vidéo nécessitent une bande passante importante et s'avèrent coûteux à grande échelle. Même avec une optimisation poussée, la latence inévitable entraîne une expérience utilisateur sensiblement différente. Sur les écrans à haute résolution, le texte peut apparaître flou ; les utilisateurs mobiles disposant de connexions instables subissent une dégradation de la qualité.

Idéal pour : les environnements hautement sécurisés où la confidentialité prime sur l'expérience utilisateur — recherche OSINT, accès administrateur privilégié à des systèmes critiques ou navigation dans des environnements classifiés.

Mise en miroir du DOM (reconstruction du DOM)

Grâce à la reconstruction du DOM, les pages Web sont chargées dans un environnement isolé, analysées au niveau du Document Object Model, puis réécrites afin d'éliminer les menaces potentielles. Une fois le contenu nettoyé, une version sécurisée est envoyée à l'appareil de l'utilisateur, où le navigateur de ce dernier l'affiche à l'aide de son propre moteur.

Avantage en matière de sécurité : légèreté et rapidité. Le terminal bénéficie d'une expérience de navigation quasi native qui préserve l'accélération par GPU et le comportement de défilement standard.

Compromis : les technologies sous-jacentes — HTML, CSS, polices Web — constituent elles-mêmes des vecteurs d'attaque. Tenter de supprimer les contenus malveillants par le biais d'un filtrage est intrinsèquement imparfait ; de nouvelles techniques d'exploitation pourraient passer entre les mailles du filet. Les pages dynamiques complexes risquent de ne plus fonctionner ou de s'afficher de manière incorrecte.

Idéal pour : la navigation d'entreprise à usage général, où les performances et l'expérience utilisateur sont primordiales, et où l'organisation accepte un niveau d'isolation légèrement inférieur au profit de la productivité.

Rendu vectoriel en réseau (NVR)

NVR intercepte les commandes de dessin provenant du moteur graphique utilisé dans Chromium et Firefox, les crypte, puis les transmet au navigateur local. Comme NVR transmet des commandes de dessin vectorielles plutôt que le code réel du site web, il consomme moins de bande passante que le traitement pixel par pixel, tout en conservant une isolation stricte.

Avantage en matière de sécurité : aucun code du site web n'atteint le terminal, à l'instar du « pixel pushing », mais la consommation de bande passante est nettement inférieure, car les commandes de dessin vectoriel sont bien plus compactes que les images vidéo composées de pixels.

Compromis : l'adoption de la technologie NVR est plus limitée et peut dépendre de la prise en charge par certains moteurs de navigateur. Elle se situe à mi-chemin entre le rendu pixel par pixel et la réplication du DOM, tant en termes de sécurité que de performances.

Idéal pour : les entreprises qui ont besoin d'une sécurité quasi parfaite sans surcoût en bande passante — notamment celles dont les équipes travaillent à distance et utilisent des connexions réseau variables.

Isolement total ou isolement sélectif : choisir le bon modèle de politique

La plupart des entreprises n'ont ni besoin ni envie d'isoler chaque session de navigation. La perte de performances et les coûts informatiques liés à une isolation totale sont difficiles à justifier lorsque la majeure partie du trafic est dirigée vers des applications SaaS bien connues et classées par catégorie. C'est là que l'isolation sélective s'impose comme une stratégie pratique.

L'isolation totale achemine l'intégralité du trafic Web via le RBI. Chaque page, chaque session, chaque utilisateur. Cette approche s'avère pertinente pour les segments nécessitant un niveau de sécurité élevé : une agence gouvernementale traitant des informations classifiées, une salle des marchés financiers ou un laboratoire de recherche médicale accédant à des sources de données externes. La garantie de sécurité est absolue, mais il en va de même pour le coût et l'impact sur la latence.

L'isolation sélective applique le RBI uniquement au trafic qui dépasse un seuil de risque défini. Parmi les déclencheurs courants, on peut citer :

Domaines non classés ou nouvellement enregistrés. Un prestataire clique sur un lien menant à un domaine enregistré il y a 48 heures. Le SWG le signale comme non classé ; le RBI isole automatiquement la session.

Catégories d'URL à risque. Les sites classés dans les catégories « partage de fichiers », « messagerie personnelle » ou « réseaux publicitaires » sont isolés, tandis que le trafic SaaS de l'entreprise circule sans entrave.

Liens intégrés dans les e-mails. Chaque URL contenue dans un e-mail entrant, quelle que soit sa réputation, est ouverte via RBI, ce qui neutralise le principal vecteur de hameçonnage.

Segments d'utilisateurs sensibles. Les cadres, les utilisateurs des services financiers et des ressources humaines qui traitent des données réglementées naviguent par défaut en mode isolé ; le personnel général n'utilise ce mode que pour les destinations à risque.

Le point d'intégration clé est la secure web gateway, qui classe et achemine le trafic en temps réel. La politique de la passerelle Web sécurisée détermine quelles sessions accèdent à RBI et lesquelles sont soumises à une inspection standard. Lorsque la passerelle Web sécurisée s'inscrit dans une plateforme SSE plus large, les décisions d'isolation peuvent tenir compte des scores de risque CASB, de la classification DLP, de l'identité de l'utilisateur, de l'état de sécurité des appareils et des informations sur les menaces en temps réel, créant ainsi une politique contextuelle qui concilie sécurité et productivité.

Le rôle de la RBI dans l'architecture Zero Trust et SSE

L'isolation du navigateur ne fonctionne pas en vase clos. Déployée de manière autonome, elle permet de lutter contre les logiciels malveillants et le phishing sur le Web, mais présente des lacunes en matière d'exfiltration de données, d'informatique fantôme dans les solutions SaaS et d'attaques ciblant les identités. C'est lorsqu'elle est intégrée à une architecture « zero trust » aux côtés de contrôles complémentaires que l'isolation du navigateur révèle toute sa valeur.

Le modèle de maturité « Zero Trust » v2.0 (2023) de la CISA permet de s'éloigner des approches traditionnelles axées sur le périmètre, en donnant aux organisations les moyens d'isoler les hôtes, d'imposer le chiffrement, de segmenter l'activité et de mettre en œuvre des contrôles de sécurité plus proches des applications et des données. RBI s'inscrit directement dans ces principes : il isole l'environnement de navigation, impose le chiffrement entre le conteneur et le terminal, et sépare l'activité Web à risque du réseau d'entreprise.

Le plan technique 2026 de la Cloud Security Alliance sur la sécurité des navigateurs va plus loin, en repositionnant le navigateur comme un point d'application des politiques (PEP) de premier plan au sein d'une architecture Zero Trust complète qui unifie les contrôles d'accès basés sur le principe du moindre privilège, l'authentification multifactorielle résistante au phishing, la validation de l'état des appareils, la gouvernance adaptative des sessions et remote browser isolation. La CSA recommande spécifiquement de déployer remote browser isolation les sessions privilégiées ou à risque élevé afin de neutraliser à la fois la compromission des terminaux et les menaces Web malveillantes.

Dans les architectures SSE concrètes, le RBI fonctionne en tandem avec :

SWG pour le filtrage d'URL, les informations sur les menaces et les décisions relatives au routage du trafic.

Un CASB permettant de surveiller l'utilisation des services SaaS autorisés et non autorisés, avec la possibilité d'isoler les sessions vers des services informatiques parallèles tout en bloquant les opérations de téléchargement et de chargement.

Le DLP permet de contrôler le contenu transitant par des sessions isolées et d'empêcher que des données sensibles ne soient copiées, téléchargées ou imprimées lors d'une navigation à risque.

ZTNA / Private Access isoler les sessions provenant d'appareils non gérés qui accèdent aux applications internes : un prestataire externe utilisant son ordinateur portable personnel accède à l'intranet de l'entreprise via une session isolée dans laquelle les fonctions copier-coller et de téléchargement sont désactivées.

Selon le Magic Quadrant 2024 de Gartner Magic Quadrant la sécurité des applications (SSE), d'ici 2026, 85 % des entreprises cherchant à sécuriser leurs applications Web, SaaS et privées s'appuieront sur les fonctionnalités de sécurité d'une solution SSE. La technologie RBI figure parmi les fonctionnalités attendues d'une plateforme SSE mature, ce qui confirme que l'isolation n'est plus une option pour les entreprises qui prennent au sérieux la sécurité des navigateurs d'entreprise.

Évaluation des solutions RBI : les priorités des architectes en sécurité

Toutes les implémentations de RBI ne se valent pas. Lorsque vous évaluez des solutions, concentrez-vous sur les critères qui ont une incidence directe sur le niveau de sécurité, la complexité opérationnelle et l'acceptation par les utilisateurs.

1. Méthode de rendu et plafond d'isolation. Vérifiez si la solution utilise le « pixel pushing », la mise en miroir du DOM, la technologie NVR ou une approche hybride. Demandez au fournisseur quel contenu, le cas échéant, s'exécute sur le navigateur du terminal. Une solution de mise en miroir du DOM qui envoie du code JavaScript nettoyé au terminal présente une surface d'attaque différente de celle d'une solution de « pixel pushing » qui n'envoie que des images.

2. Expérience utilisateur et latence. Demandez une démonstration de faisabilité dans votre environnement réseau réel. Demandez aux utilisateurs de charger leurs dix applications SaaS les plus utilisées via la session isolée et mesurez le temps de chargement des pages, la fluidité du défilement, le fonctionnement du copier-coller ainsi que les processus de téléchargement et de chargement de fichiers. Si l'expérience se détériore de manière notable, l'adoption par les utilisateurs échouera — et ceux-ci trouveront des solutions de contournement pour contourner complètement l'isolation.

3. Niveau d'intégration de la plateforme SSE. Le moteur d'isolation doit partager les politiques, le contexte d'identité, les règles DLP et les informations sur les menaces avec les composants SWG, CASB et ZTNA. Si vous devez gérer les politiques RBI dans une console distincte utilisant un langage de règles différent, vous achetez un produit ponctuel, et non une fonctionnalité de plateforme. La plateforme SSE Skyhigh Security intègre le RBI aux composants SWG, CASB, DLP et ZTNA sous un moteur de politiques unique — un exemple de l'approche unifiée que les architectes de sécurité devraient exiger.

4. Prise en charge des appareils non gérés. L'un des principaux avantages de la technologie RBI réside dans la possibilité d'offrir un accès sécurisé à partir d'appareils que l'entreprise ne contrôle pas : ordinateurs portables de sous-traitants, appareils de partenaires, tablettes personnelles. La solution doit prendre en charge un déploiement sans client (sans agent), dans lequel les utilisateurs se connectent via un navigateur standard sans avoir à installer d'agents ni de logiciels propriétaires.

5. Niveau de contrôle des données. La solution permet-elle de désactiver le copier-coller, l'impression, la capture d'écran et le téléchargement de fichiers au cas par cas, en fonction des règles définies ? Pour une session isolée au cours de laquelle un prestataire accède à Salesforce, vous souhaitez un accès en lecture seule, avec le copier-coller bloqué et aucune mise en cache de fichiers en local.

6. Évolutivité et empreinte cloud. Chaque session isolée consomme des ressources informatiques. Renseignez-vous sur l'infrastructure cloud du fournisseur, sa présence géographique, les limites de simultanéité des sessions, ainsi que sur l'évolution des coûts à mesure que vous ajoutez des utilisateurs ou augmentez la part de trafic isolé.

7. Compatibilité avec les navigateurs existants. La stratégie d'adoption la plus efficace consiste à conserver les navigateurs actuels des utilisateurs — Chrome, Edge, Firefox, Safari — plutôt que d'imposer le remplacement de ceux-ci par un navigateur propriétaire. Comme le montre la comparaison entre les navigateurs d'entreprise et les solutions RBI, les solutions SSE intégrées à RBI vous permettent de sécuriser les navigateurs que vos collaborateurs utilisent déjà sans imposer de migration perturbante.

Erreurs courantes lors du déploiement de systèmes RBI

Tout isoler dès le premier jour. L'isolation totale de l'ensemble du trafic peut sembler sûre sur le papier, mais elle suscite des plaintes liées aux performances qui érodent la confiance des utilisateurs. Une meilleure approche consiste à commencer par les catégories à haut risque : les domaines non classés, les URL intégrées dans les e-mails et les sessions sur des appareils non gérés. Étendez la portée de l'isolation à mesure que vous évaluez l'impact sur les utilisateurs et renforcez leur confiance.

Déploiement de RBI en tant que produit autonome. Sans intégration à SWG, RBI ne peut pas prendre de décisions de routage intelligentes. Sans DLP, RBI ne peut pas empêcher un utilisateur de saisir des données sensibles dans un formulaire Web au cours d'une session isolée. Sans CASB, RBI ne peut pas déterminer si la destination est un service de stockage cloud autorisé ou un compte de partage de fichiers personnel. L'isolation résout un problème — empêcher les contenus malveillants d'atteindre le terminal — mais la sécurité des données nécessite la pile SSE complète.

On néglige le cas des appareils non gérés. De nombreuses organisations acquièrent une solution RBI pour leurs terminaux gérés, mais négligent les sous-traitants et les utilisateurs tiers utilisant des appareils BYOD. Ces utilisateurs représentent certaines des sessions présentant les risques les plus élevés. La norme NIST SP 800-46 Rev. 2 souligne explicitement que tous les composants des technologies de télétravail, y compris les appareils clients BYOD, doivent être sécurisés contre les menaces anticipées identifiées par le biais de modèles de menaces. La solution RBI constitue l’un des moyens les plus pratiques d’y parvenir sans nécessiter l’inscription à un système de gestion des appareils.

Ne pas associer l'isolation à l'identité. Une politique d'isolation uniforme qui traite tous les utilisateurs de la même manière entraîne un gaspillage de ressources et génère de la frustration chez les utilisateurs à faible risque. Il convient de lier les politiques d'isolation aux groupes d'identité, aux contrôles d'accès basés sur les rôles et à la notation adaptative des risques. Un cadre dirigeant naviguant sur le réseau de l'entreprise à partir d'un appareil géré n'a peut-être pas besoin d'être isolé ; ce même cadre naviguant depuis le réseau Wi-Fi d'un hôtel sur une tablette personnelle devrait quant à lui être isolé automatiquement. Le rapport 2025 Global Incident Response Report de l'Unit 42 a révélé que 70 % des incidents impliquaient au moins trois vecteurs d'attaque : des politiques tenant compte du contexte, qui prennent en considération l'identité, l'appareil et la destination, sont essentielles pour briser les chaînes d'attaques multivectorielles.