Comment Remote Browser Isolation l'architecture « Zero Trust »

Remote browser isolation RBI) est l'une des manifestations techniques les plus directes du principe fondamental du « zero trust » : ne jamais accorder de confiance implicite à aucun contenu, aucune session ni aucun appareil. Pour les architectes de sécurité qui alignent leurs contrôles sur les principes de la norme NIST SP 800-207 et sur le modèle de maturité « zero trust » de la CISA, la RBI comble une lacune que le filtrage d'URL par SWG et la détection au niveau des terminaux ne peuvent à eux seuls combler : les menaces véhiculées par le navigateur qui s'exécutent avant qu'un verdict ne soit rendu. Cet article explique précisément comment le RBI s’inscrit dans les principes du « Zero Trust » que sont la vérification explicite, le principe du privilège minimal et l’hypothèse de violation, et quelle est sa place aux côtés du ZTNA, du SWG, du CASB et du DLP au sein d’une pile SSE moderne.

Qu'est-ce que Remote Browser Isolation?

Remote browser isolation une technologie de sécurité qui exécute les sessions de navigation Web dans un conteneur hébergé dans le cloud, séparant ainsi physiquement l'ensemble du code Web du terminal de l'utilisateur. L'appareil local ne traite jamais directement le code Web actif ; il ne reçoit en effet qu'un flux de pixels ou un DOM nettoyé et reconstruit.

Imaginez une analyste des achats travaillant pour un fabricant de taille moyenne qui reçoit un lien d’un nouveau fournisseur. Le domaine a été enregistré la semaine dernière, n’a aucune réputation en matière d’URL et se trouve dans la zone grise « non classée », où un SWG traditionnel le bloquerait (au grand dam de l’analyste) ou l’autoriserait (en faisant confiance à l’inconnu). Avec RBI, la page se charge à l’intérieur d’un conteneur cloud jetable. L’analyste voit une page entièrement interactive — elle remplit un formulaire, télécharge un PDF — mais aucun JavaScript, aucun ActiveX, aucun exploit intégré n’atteint jamais son ordinateur portable. Si la page abritait un exploit « zero-day », celui-ci se déclencherait sans danger à l’intérieur d’un conteneur qui serait effacé dès qu’elle fermerait l’onglet.

Ce modèle revêt plus d'importance que jamais. Le Google Threat Intelligence Group (GTIG) a recensé 75 vulnérabilités « zero-day » exploitées en milieu réel en 2024, et 44 % de ces exploits visaient des technologies d'entreprise (GTIG, avril 2025). Les chaînes d'attaques basées sur les navigateurs restent un vecteur persistant, et le RBI assure une défense en profondeur, que la menace soit connue ou non.

Pourquoi le RBI est essentiel pour le modèle « Zero Trust »

Le « zero trust » n’est pas un produit que l’on achète : il s’agit d’un ensemble de principes de conception. La norme NIST SP 800 207 (2020) précise que le « zero trust » part du principe qu’aucune confiance implicite n’est accordée aux ressources ou aux comptes d’utilisateurs sur la seule base de leur emplacement physique ou réseau, ni en fonction de la propriété de ces ressources. Or, le navigateur a traditionnellement fonctionné selon un principe de confiance implicite : si une URL figure sur la liste blanche du SWG ou si un domaine dispose d’un certificat valide, le terminal charge et exécute tout le code fourni par le serveur. Il s’agit là d’un modèle de confiance périmétrique appliqué à une interaction au niveau de la session.

L'écart de maturité reste manifeste. Dans l'enquête de Gartner de 2024 sur l'adoption du modèle « zero trust », 63 % des organisations ont déclaré avoir mis en œuvre, totalement ou partiellement, une stratégie « zero trust » ; toutefois, Gartner a souligné que, pour la plupart d'entre elles, ce modèle ne couvre encore que la moitié, voire moins, de leur environnement et ne permet d'atténuer qu'un quart, voire moins, du risque global de l'entreprise. L’une des principales lacunes qui subsistent concerne la session de navigation : selon Gartner, les navigateurs constituent le principal moyen d’accès à la plupart des applications d’entreprise modernes ; pourtant, moins de 10 % des entreprises ont adopté à ce jour un navigateur d’entreprise sécurisé, même si Gartner prévoit que ce taux d’adoption atteindra 25 % d’ici 2028. C’est par le navigateur que les collaborateurs interagissent quotidiennement avec les applications SaaS, les outils d’IA et les sites externes, mais de nombreuses organisations continuent de le traiter selon un simple modèle « autoriser/bloquer » au lieu d’appliquer une visibilité granulaire, des politiques et des contrôles de protection des données.

Prenons l'exemple d'un responsable de la conformité dans le secteur des services financiers qui accède à un portail réglementaire hébergé par un fournisseur tiers. Le SWG classe le domaine dans la catégorie « gouvernement » et autorise l’accès. Or, le portail du prestataire utilise un plugin vulnérable, et un pirate a injecté un iframe malveillant. Sans RBI, le terminal de la responsable constitue désormais une surface d’attaque. Avec RBI, l’iframe se charge à l’intérieur d’un conteneur isolé, la charge utile malveillante n’atteint jamais le terminal, et la responsable termine sa tâche sans se rendre compte de l’existence de la menace.

Comment le modèle RBI s'inscrit dans les trois principes du « Zero Trust »

Vérifier explicitement

La norme NIST SP 800 207 stipule qu’aucun actif ne doit être considéré comme intrinsèquement fiable : l’entreprise doit évaluer le niveau de sécurité de l’actif lors de l’examen de chaque demande de ressource. RBI met ce principe en œuvre au niveau de la couche des sessions Web. Au lieu de prendre une décision binaire en matière de confiance sur la base de la réputation de l’URL, RBI exécute chaque session éligible de manière isolée et évalue le contenu en fonction de son comportement au sein du conteneur. Cela fait passer la vérification d’un contrôle ponctuel (vérification de l’URL) à un modèle de confinement continu dans lequel même les domaines « de confiance » ne se voient pas accorder de privilèges d’exécution de code brut sur les terminaux.

Lorsqu’un chargé du traitement des demandes de remboursement de soins de santé ouvre un portail partenaire et accède à une page déclenchant un téléchargement furtif, les contrôles de vérification traditionnels explicites — authentification multifactorielle (MFA), conformité de l’appareil, réputation de l’URL — ont déjà été validés. L’utilisateur est authentifié, l’appareil est géré et l’URL est classée comme sûre. RBI ajoute une couche de vérification supplémentaire : même après la validation de tous les contrôles préalables, le contenu Web lui-même n’est pas considéré comme fiable pour s’exécuter sur le terminal.

Principe du privilège minimal

La norme NIST SP 800 207 précise que les principes du « privilège minimal » doivent être appliqués afin de limiter à la fois la visibilité et l’accessibilité. RBI applique ce principe à la diffusion de contenu Web. Les utilisateurs ne reçoivent que ce dont ils ont besoin pour effectuer leur travail : une représentation visuelle finalisée de la page. Ils ne reçoivent pas de code JavaScript brut, de CSS ni d’objets exécutables. Les contrôles DLP intégrés à RBI permettent de restreindre davantage les opérations sur le presse-papiers, l’impression, les téléchargements et les envois de fichiers en fonction du niveau de sensibilité de la session.

Un exemple concret : un fournisseur de services gérés accorde à des prestataires externes l'accès au système de gestion des tickets de l'entreprise via ZTNA. Les prestataires s'authentifient, passent les contrôles de conformité de leurs appareils et accèdent à l'application. Mais l’architecte sécurité applique également une politique RBI : les sessions des prestataires s’exécutent en mode isolé, avec la fonction copier-coller désactivée et les téléchargements limités aux fichiers PDF aplatis. Les prestataires peuvent consulter et mettre à jour les tickets, mais ils ne peuvent pas extraire de données brutes. Il s’agit là d’une application du principe du « privilège minimal » non seulement à l’accès au réseau, mais également aux actions que les utilisateurs peuvent effectuer au sein de la session.

Partir du principe qu'il y a eu une violation

La norme NIST SP 800 207 part du principe que le réseau est toujours hostile et que des menaces externes et internes existent en permanence. La technologie RBI incarne ce principe dès sa conception : elle part du principe que toute page Web pourrait être compromise et établit une barrière physique entre le contenu Web et le terminal. Comme le souligne la Cloud Security Alliance, RBI exécute les sessions Web à haut risque dans des conteneurs cloud isolés et éphémères, où le terminal local de l’utilisateur n’interagit jamais directement avec le code Web actif (CSA, janvier 2026).

Si un commercial consulte la page marketing d’un fournisseur de SaaS compromis qui diffuse une charge malveillante sans fichier via une bibliothèque JavaScript exploitée, cette charge s’exécute à l’intérieur du conteneur et est détruite à la fin de la session. Il n’y a aucun mécanisme de persistance, aucune possibilité de mouvement latéral et aucune trace laissée sur le terminal. L’approche « « assume breach » » est maintenue même si la menace a contourné tous les autres contrôles de la pile.

Comment le modèle RBI s'intègre au modèle de maturité « Zero Trust » de la CISA

Le modèle de maturité « Zero Trust » de la CISA, version 2.0 (2023), articule le modèle « Zero Trust » autour de cinq piliers — Identité, Appareils, Réseaux, Applications et charges de travail, et Données — ainsi que de trois capacités transversales : Visibilité et analyse, Automatisation et orchestration, et Gouvernance. La RBI contribue simultanément à plusieurs de ces piliers :

Pilier ZTMM de la CISA : contribution de la RBI et évolution de l'échéance

La norme NIST SP 800 207 définit la triade architecturale composée du moteur de politiques (PE), de l’administrateur de politiques (PA) et du point d’application des politiques (PEP). Dans ce modèle, RBI fait office de PEP au niveau de la couche de session du navigateur. Le PE évalue le contexte de la requête — identité de l’utilisateur, état de sécurité du terminal, risque lié à l’URL, sensibilité des données — et le PA ordonne au service RBI d’isoler la session et d’appliquer les contrôles de données appropriés. Cela s’inscrit dans le cadre des exigences de la CISA en matière de vérification au cas par cas, telles que décrites par la Cloud Security Alliance (CSA, janvier 2026).

RBI au sein de la pile SSE : intégration avec ZTNA, SWG, CASB et DLP

Utilisé isolément, le RBI est utile mais présente des limites. Il ne déploie pleinement son potentiel en matière de « zero trust » que lorsqu’il fonctionne en tant que composant intégré au sein d’une plateforme Security Service Edge SSE) comprenant des modules SWG, CASB, ZTNA et DLP.

Considérons le déroulement des opérations lorsqu'un collaborateur utilisant un appareil géré accède à un outil d'IA générative via un navigateur. Le SWG examine la requête, classe la destination et évalue le risque lié à l'URL. Le CASB identifie l’application d’IA et vérifie si elle est autorisée. Le moteur DLP analyse le texte de la requête à la recherche de données sensibles. Et la session RBI — déclenchée par la politique du SWG, l’outil d’IA étant classé dans la catégorie « surveiller » — garantit que l’employé peut utiliser l’outil, mais ne peut pas y coller des informations personnelles identifiables (PII) de clients, télécharger des réponses contenant du contenu sensible, ni mettre en ligne des fichiers comportant des données réglementées. Tout cela s’effectue au sein d’un seul moteur de politiques, et non à travers quatre produits distincts dotés de consoles séparées.

C'est ce modèle d'intégration qui explique pourquoi Gartner estime que le marché du SASE connaîtra une croissance à un TCAC de 26 %, pour atteindre 28,5 milliards de dollars d'ici 2028 (Gartner, février 2025). Les entreprises regroupent l'accès, la protection contre les menaces et la sécurité des données au sein de plateformes unifiées, car l'alternative — à savoir assembler des produits RBI, SWG, CASB et DLP autonomes — engendre des lacunes dans les politiques, une application incohérente et une charge opérationnelle qui sapent le modèle « zero trust ».

Skyhigh Private Access la technologie ZTNA à l'analyse DLP et à la fonctionnalité RBI transparente, de sorte que les sessions d'applications privées soient isolées lorsque la politique l'exige, sans qu'il soit nécessaire d'acheminer le trafic via un produit distinct.

Quand le navigateur devient un espace de travail

Le navigateur constitue l’espace de travail principal pour l’accès aux services SaaS, l’utilisation d’outils d’IA, le téléchargement de fichiers, la saisie d’identifiants et la collaboration avec des tiers. Un architecte en sécurité qui déploie le ZTNA pour protéger des applications privées, mais qui néglige la session de navigation au cours de laquelle les employés interagissent avec ces applications, présente une faille dans la mise en œuvre de la sécurité. RBI comble cette faille, non pas en remplaçant le navigateur que les utilisateurs connaissent déjà (Chrome, Edge, Firefox, Safari), mais en encapsulant la session dans une couche d’isolation basée sur le cloud, contrôlée par une politique SSE.

Un prestataire non géré accède à l'application CRM d'une entreprise via un CASB de type proxy inverse. Le CASB authentifie le prestataire, applique des contrôles de session et déclenche une politique RBI, car l'appareil n'est pas géré. Le prestataire consulte et utilise le CRM normalement, mais en arrière-plan, la session s'exécute de manière isolée, avec des restrictions sur le presse-papiers et le blocage des téléchargements. L'entreprise sécurise les données sans obliger le prestataire à installer un agent, à enregistrer son appareil ou à utiliser un navigateur propriétaire.

Critères d'évaluation : les éléments à prendre en compte pour une RBI « Zero Trust »

Toutes les implémentations de la technologie RBI n'offrent pas la même valeur en matière de « zero trust ». Les architectes en sécurité qui évaluent l'isolation des navigateurs doivent tenir compte des critères suivants :

1. Intégration native à SSE. Le RBI doit faire partie du même moteur de politiques que le SWG, le CASB, le ZTNA et le DLP. Si le RBI nécessite une console distincte, des politiques distinctes ou un acheminement du trafic distinct, cela entraîne des lacunes opérationnelles et des incohérences au niveau des politiques.

2. Contrôles granulaires des données au sein des sessions d'isolation. Le modèle « Zero Trust » exige l'application du principe du « privilège minimal » au niveau de la session. Le RBI doit permettre de désactiver le presse-papiers, l'impression, le téléchargement de fichiers et les captures d'écran de manière indépendante, par politique, par groupe d'utilisateurs et par catégorie d'application.

3. Prise en charge des appareils non gérés. Une solution qui nécessite un agent côté terminal pour activer l'isolation va à l'encontre de l'un des principaux cas d'utilisation de RBI : la protection de l'accès contre les appareils que l'entreprise ne contrôle pas.

4. Performances et expérience utilisateur. Si le RBI entraîne une latence perceptible, les utilisateurs trouveront le moyen de le contourner : en ouvrant les liens sur leurs appareils personnels, en utilisant des points d'accès mobiles ou simplement en se plaignant jusqu'à ce que le service informatique accorde des dérogations. La couche d'isolation doit afficher les pages à une vitesse proche de celle d'une application native.

5. Fidélité de rendu. Les applications SaaS modernes sont des applications monopages complexes, fortement basées sur JavaScript. RBI doit les prendre en charge sans altérer leurs fonctionnalités, sans omettre d'éléments interactifs et sans nuire à l'expérience utilisateur.

6. Activation évolutive basée sur des règles. Le modèle « zero trust » n’implique pas nécessairement d’isoler chaque session. Les meilleures implémentations permettent aux équipes de sécurité de définir des déclencheurs basés sur le risque : isoler les URL non classées, isoler toutes les sessions des utilisateurs à haut risque, isoler certaines catégories de SaaS ou isoler l’ensemble du trafic provenant d’appareils non gérés.

7. Visibilité et analyse. Le RBI devrait intégrer les données de télémétrie des sessions dans la couche d’analyse plus large du SSE, contribuant ainsi à la capacité transversale « Visibilité et analyse » du ZTMM de la CISA. Cela implique de savoir qui a accédé à quoi, quand, depuis où et à l’aide de quel appareil — et si ce comportement s’écarte de la ligne de base.

Le coût de l'angle mort de la navigation

Le fait de ne pas soumettre les sessions de navigateur aux contrôles « zero trust » a un coût mesurable. Selon le rapport IBM « Cost of a Data Breach Report 2024 » (juillet 2024), le coût moyen mondial d'une fuite de données a atteint 4,88 millions de dollars en 2024. Les identifiants compromis constituaient le vecteur d'attaque le plus courant, représentant 16 % de l'ensemble des fuites.

Le phishing par navigateur est l'un des principaux moyens utilisés pour voler des identifiants. Un gestionnaire de paie reçoit un lien vers ce qui semble être la page de connexion d’un portail dédié aux avantages sociaux. Le domaine vient d’être enregistré, passe les contrôles DMARC et semble légitime. En l’absence de RBI, le gestionnaire saisit ses identifiants sur la page de l’attaquant, et le vol d’identifiants est consommé. Grâce à RBI, qui applique une politique d’isolation aux domaines non classés, la page de hameçonnage se charge dans un conteneur, le système DLP détecte le schéma de soumission des identifiants, et la session est interrompue avant que les identifiants ne quittent l’environnement isolé.

La justification financière du RBI n'est pas purement théorique. Les organisations qui comblent les failles de sécurité au niveau du navigateur réduisent leur exposition aux vecteurs de violation les plus coûteux : le vol d'identifiants, la diffusion de logiciels malveillants via le Web et l'exfiltration de données par le biais d'actions non surveillées effectuées dans le navigateur.

Erreurs courantes lors du déploiement de la technologie RBI dans un modèle « Zero Trust »

Déploiement de RBI en tant que produit autonome. Sans intégration à SSE, RBI devient une solution ponctuelle supplémentaire, dotée de son propre silo de politiques. Un système de santé qui déploie RBI séparément de son SWG se retrouve avec deux moteurs de catégorisation d’URL distincts, deux consoles de gestion des politiques, et une dérive inévitable. Les politiques entrent en conflit, les exceptions se multiplient et le modèle « zero trust » s’affaiblit.

Tout isoler, systématiquement. L'isolation généralisée gaspille des ressources informatiques et nuit aux performances des sessions à faible risque. Une approche fondée sur les risques — consistant à isoler les domaines non classés, les groupes d'utilisateurs à haut risque et les catégories d'applications sensibles — permet d'obtenir de meilleurs résultats en matière de sécurité tout en réduisant les contraintes.

Ignorer les appareils non gérés. Certaines implémentations exigent que des agents redirigent le trafic vers le service d’isolation, ce qui exclut précisément les cas d’utilisation (sous-traitants, BYOD, transitions liées aux fusions-acquisitions) dans lesquels RBI apporte le plus de valeur ajoutée. Un détaillant qui intègre des responsables d’entrepôt saisonniers utilisant leurs tablettes personnelles a besoin d’une isolation sans agent, et non d’une redirection dépendant d’un agent.

Négliger la protection DLP dans les sessions isolées. La technologie RBI, sans contrôles des données, bloque les logiciels malveillants mais pas l'exfiltration de données. Un collaborateur qui ne peut pas coller des dossiers clients dans un e-mail personnel via un navigateur classique peut tout de même le faire via une session isolée, à moins que des contrôles du presse-papiers ne soient mis en place.

Considérer RBI comme une alternative à la VDI. RBI isole les sessions de navigateur, et non les postes de travail complets. Il complète la VDI dans certains cas d'utilisation spécifiques (accès Web pour des tiers), mais ne la remplace pas pour les utilisateurs qui ont besoin d'applications de bureau natives.