Sécurisation des applications SaaS grâce à des contrôles au niveau du navigateur

Votre CASB empêche un prestataire de télécharger une liste de clients depuis Salesforce vers un ordinateur portable non géré. Cinq secondes plus tard, ce même prestataire sélectionne l’intégralité du tableau, le copie dans le presse-papiers, le colle dans la fenêtre de rédaction de son compte Gmail personnel, puis clique sur « Envoyer ». Le CASB ne s’en rend pas compte. Le navigateur, lui, l’a détecté — et, avec les contrôles appropriés, aurait pu empêcher cette action. Ce guide propose aux administrateurs de sécurité SaaS et aux opérateurs CASB une approche par étapes visant à combler cette lacune en mettant en place des contrôles au niveau du navigateur — remote browser isolation (RBI), les politiques secure web gateway SWG), la prévention des fuites de données ( DLP) et les actions de session — en complément des déploiements CASB existants.

Conditions préalables : ce qu'il faut avoir mis en place avant de commencer

Avant d'activer les contrôles au niveau du navigateur, veuillez vous assurer que votre environnement remplit les quatre conditions fondamentales. Le non-respect de ces conditions entraîne des conflits de politiques, la frustration des utilisateurs et une couverture incomplète.

1. Un CASB avec les modes proxy direct et inverse déjà déployés. Vous avez besoin d’une inspection du trafic en ligne pour les applications SaaS autorisées (proxy inverse) et d’une visibilité sur l’informatique parallèle (proxy direct) comme base de référence pour l’application de vos règles. Si votre déploiement CASB repose uniquement sur une API, il vous manque la voie en ligne que permettent les contrôles au niveau du navigateur.

2. Moteur de politiques DLP unifié. Les contrôles au niveau du navigateur doivent se référer aux mêmes classifications de données — informations personnelles identifiables (PII), informations médicales protégées (PHI), documents financiers, code source, propriété intellectuelle — que celles utilisées par votre CASB et vos politiques DLP de messagerie. Si vos définitions DLP sont cloisonnées, commencez par les regrouper. Une classification incohérente conduit à ce qu’un canal bloque ce qu’un autre autorise. Une plateforme DLP centralisée évite cette fragmentation.

3. Intégration d’un fournisseur d’identité (IdP) et évaluation de l’état de sécurité des appareils. Les contrôles au niveau du navigateur gagnent considérablement en utilité lorsqu’ils s’adaptent en fonction de l’identité de l’utilisateur et de l’appareil qu’il utilise. Un prestataire en marketing travaillant sur son MacBook personnel devrait être soumis à des contrôles plus stricts qu’un analyste financier à temps plein utilisant un terminal Windows géré. Cela nécessite une fédération SAML/OIDC avec votre IdP ainsi que des vérifications de l’état de sécurité des appareils (géré ou non géré, niveau de mise à jour du système d’exploitation, état du chiffrement du disque).

4. Inventaire des applications SaaS avec classification par niveau de sensibilité. Vous ne pouvez pas définir la portée des politiques relatives aux navigateurs sans savoir quelles applications SaaS contiennent des données sensibles. Classez vos 20 à 50 principales applications SaaS par niveau de sensibilité des données (critique, élevé, moyen, faible). Les « Meilleures pratiques de gouvernance SaaS » de la CSA recommandent d’évaluer les risques à toutes les étapes du cycle de vie des applications SaaS : évaluation, adoption, utilisation et résiliation. Cet inventaire servira de base à la définition de la portée de vos politiques.

Phase 1 : Combler les lacunes en matière de presse-papiers et de téléchargement dans les scénarios à haut risque

Commencez par les cas où le risque est le plus élevé et où la population d'utilisateurs est la plus restreinte : les appareils non gérés qui accèdent à des applications SaaS sensibles.

Le scénario justifiant la phase 1 : un auditeur tiers se connecte à votre instance Workday depuis un ordinateur portable personnel à l'aide de l'authentification unique (SSO). Votre proxy inverse CASB authentifie la session et bloque les téléchargements de fichiers conformément à la politique en vigueur. Mais l’auditeur ouvre un rapport sur la rémunération des employés, sélectionne trente lignes de données salariales, les copie, ouvre un nouvel onglet vers une feuille Google Sheet personnelle, puis les colle. Le CASB a détecté une session Workday authentifiée et une session Google Sheets — deux événements distincts, autorisés individuellement. Il n’a jamais détecté le transfert de données entre ces deux sessions, car l’opération de copier-coller s’est entièrement déroulée dans le contexte de rendu du navigateur.

Ce qu'il faut mettre en œuvre : activez remote browser isolation toutes les sessions des appareils non gérés accédant aux applications SaaS de niveau 1 (critique) et de niveau 2 (élevé). La technologie RBI affiche l'application SaaS dans un conteneur hébergé dans le cloud et ne transmet que les pixels au navigateur de l'utilisateur. Cette architecture vous offre un contrôle précis sur les actions effectuées au cours de la session :

Restriction de copier-coller : bloquez les opérations d'écriture et de lecture dans le presse-papiers depuis la session isolée, ou autorisez le collage mais bloquez la copie vers l'extérieur afin d'empêcher les données de quitter le contexte de l'application SaaS.

Suppression des téléchargements : empêchez totalement le téléchargement de fichiers à partir de la session affichée, ou limitez les téléchargements à certains types de fichiers.

Blocage de l'impression : désactivez les commandes d'impression et d'impression au format PDF.

Marquage d'eau des captures d'écran : insérez un filigrane visible ou numérique contenant l'adresse e-mail de l'utilisateur et un horodatage dans le flux affiché, afin de dissuader la réalisation de captures d'écran.

La norme NIST SP 800-53 SC 7 impose d'isoler les composants du système à l'aide de mécanismes de protection des frontières afin de contrôler les flux d'informations et de limiter les dommages potentiels résultant d'attaques malveillantes et d'erreurs. RBI crée précisément cette frontière entre les données de l'application SaaS et l'appareil local de l'utilisateur, en appliquant des contrôles des flux d'informations qu'un proxy réseau n'est pas en mesure d'assurer.

Limitation du champ d'application : appliquez ces mesures de contrôle uniquement aux appareils non gérés et aux sous-traitants au cours de la phase 1. Les terminaux gérés sur lesquels un agent a été déployé et dont l'état de sécurité a été vérifié peuvent faire l'objet de mesures de contrôle moins strictes (telles que l'apposition d'un filigrane sans blocage du presse-papiers) afin de préserver la productivité.

Phase 2 : Étendre la protection DLP du navigateur aux terminaux gérés et élargir la couverture des solutions SaaS

Une fois que la phase 1 s'est stabilisée — généralement après 4 à 6 semaines de collecte de données télémétriques et d'ajustement des règles —, étendez la couverture aux appareils gérés et à un ensemble plus large d'applications SaaS.

Le scénario qui justifie la phase 2 : un commercial à temps plein, disposant d’un ordinateur portable géré, accède à Salesforce via Chrome. Il ouvre la fiche d’un client, copie le nom, le nom de l’entreprise et le numéro de téléphone du contact, puis les colle dans ChatGPT afin de générer un e-mail de prise de contact personnalisé. Aucun fichier n’a été téléchargé. Aucune règle de partage de Salesforce n’a été enfreinte. Mais les données à caractère personnel du client viennent de quitter votre environnement SaaS contrôlé pour être transférées vers un outil d’IA tiers via le presse-papiers du navigateur.

Selon le rapport de la CSA intitulé « State of SaaS Security Report » (2025), 63 % des organisations signalent un partage excessif de données vers l'extérieur, et 56 % indiquent que leurs collaborateurs téléchargent des données sensibles vers des applications SaaS non autorisées — souvent via ces mêmes chemins d'accès au presse-papiers et de téléchargement que les contrôles traditionnels ne détectent pas. La prévention des fuites de données (DLP) au niveau du navigateur est le mécanisme de contrôle qui intercepte ces actions avant que les données n'atteignent leur destination non autorisée.

Éléments à déployer :

SWG a mis en place une inspection DLP sur les terminaux gérés. Votre secure web gateway intercepte le trafic du navigateur et applique la classification DLP aux données en transit — notamment les soumissions de champs de formulaire, les opérations de collage depuis le presse-papiers vers des applications web et les téléchargements de fichiers via le navigateur. Cela permet de détecter le scénario « de Salesforce vers ChatGPT » évoqué ci-dessus.

RBI sélectif pour les catégories sensibles. Plutôt que d’isoler l’ensemble de la navigation, acheminez les sessions vers les applications SaaS de niveau 1 et 2 via le RBI lorsque le comportement de l’utilisateur déclenche un signal de risque (par exemple, accès à un objet de données client, ouverture d’une vue d’exportation, accès à un outil d’IA à l’aide des identifiants de l’entreprise).

Utilisation de filigranes pour dissuader l'enregistrement des sessions. Appliquez des filigranes visibles aux sessions affichant des données sensibles, de sorte que si un utilisateur photographie son écran, le filigrane permette de remonter jusqu'à un utilisateur, une session et un horodatage spécifiques.

Principe de conception des politiques tiré de la norme NIST SP 800-53 AC 4 : des mécanismes d'application des politiques d'accès peuvent être mis en œuvre au niveau des applications et des services afin de renforcer la sécurité de l'information et de contrôler les flux d'informations au-delà de ce que permettent les contrôles au niveau du réseau. Les solutions DLP et RBI au niveau du navigateur opèrent précisément à ce niveau des applications et des services, ajoutant ainsi des mesures d'application que les proxys CASB au niveau du réseau ne peuvent pas mettre en œuvre.

Phase 3 : Intégrer les contrôles du navigateur dans votre infrastructure de politiques SSE

Le déploiement de contrôles au niveau du navigateur en tant que couche autonome engendre une charge opérationnelle supplémentaire : des politiques distinctes, des consoles distinctes, des files d’attente d’incidents distinctes. La phase 3 unifie l’application des règles au niveau du navigateur avec votre Security Service Edge (SSE), de sorte qu’un seul moteur de politique régisse les décisions relatives au CASB, au SWG, au DLP, au RBI et au ZTNA.

Le scénario justifiant la phase 3 : votre SOC reçoit trois alertes : une alerte CASB indiquant qu’un utilisateur a accédé à une application SaaS « shadow », une alerte SWG signalant que la session de navigation de ce même utilisateur a déclenché une correspondance avec un modèle DLP, et une alerte RBI indiquant qu’une copie dans le presse-papiers a été bloquée. Trois consoles, trois analystes, trois tickets — pour un seul utilisateur effectuant une seule séquence d’actions. La politique SSE unifiée regroupe tout cela en un seul événement corrélé, avec un seul workflow de réponse.

Éléments à déployer :

Des règles de politique unifiées qui prennent en compte l'identité de l'utilisateur, l'état de sécurité du terminal, le niveau de sensibilité de l'application SaaS, la classification des données et le type d'action effectuée dans le navigateur (téléchargement, presse-papiers, impression, envoi) au sein d'une seule instruction conditionnelle.

Isolation adaptative qui fait automatiquement passer une session en mode RBI complet lorsque la plateforme SSE détecte une combinaison de signaux — par exemple, un appareil non géré accédant à une application de niveau 1 tandis que le système DLP détecte du contenu sensible dans la page.

Transmettez les données de télémétrie de session au SIEM/SOAR afin que les événements au niveau du navigateur (blocage du presse-papiers, insertion de filigranes, blocage des téléchargements) soient visibles aux côtés des événements CASB, SWG et ZTNA, à des fins de corrélation et d'analyse.

Le modèle de maturité « Zero Trust » de la CISA invite les organisations à gérer et à sécuriser les applications déployées à l'aide de contrôles d'accès granulaires et de protections intégrées contre les menaces, dans le but d'atteindre une maturité optimale dans les piliers « Applications et charges de travail » et « Données ». L'intégration de contrôles au niveau du navigateur dans la politique SSE vous permet de mettre en œuvre ces recommandations pour les applications SaaS accessibles via le navigateur.

Points d'intégration : où les contrôles du navigateur s'intègrent à votre infrastructure existante

Les contrôles au niveau du navigateur ne remplacent pas les outils de sécurité existants : ils comblent les lacunes en matière d'application qui existent entre eux. Définissez clairement les points d'intégration afin d'éviter les doublons et de garantir une couverture complète.

Prenons l’exemple d’une séquence d’intégration concrète : un établissement de santé utilise le mode API CASB pour analyser les données de santé protégées (PHI) au repos dans Box et appliquer des politiques de partage. Cependant, lorsqu’une infirmière praticienne ouvre un document patient via le navigateur sur sa tablette personnelle, l’analyse par l’API a déjà eu lieu ; celle-ci n’empêchera donc pas la copie du diagnostic du patient dans le presse-papiers vers une application de messagerie. Une session RBI dotée de restrictions sur le presse-papiers et d’un système de filigrane comble cette lacune sans nécessiter d’agent de terminal sur la tablette personnelle. L’approche Skyhigh Security visant à protéger les applications cloud contre les appareils non gérés répond précisément à ce cas d’utilisation en combinant un proxy inverse, la technologie RBI et la prévention des fuites de données (DLP) au sein d’une politique intégrée.

Indicateurs et critères de réussite

Les contrôles au niveau du navigateur génèrent des données télémétriques que les déploiements antérieurs de CASB seules ne pouvaient pas produire. Définissez des indicateurs avant le déploiement afin de pouvoir démontrer la valeur ajoutée et affiner les politiques.

Indicateurs opérationnels (à suivre chaque semaine) :

Événements de blocage du presse-papiers par utilisateur, par application ou par type d'appareil. Une forte augmentation des blocages du presse-papiers pour un utilisateur donné peut indiquer une tentative d'exfiltration ou signaler une politique trop restrictive pour un flux de travail légitime. Examinez les valeurs aberrantes.

Téléchargements bloqués. Suivi par application SaaS et par rôle d'utilisateur. Un nombre élevé de téléchargements bloqués provenant d'une application particulière peut indiquer que les utilisateurs ont besoin d'une alternative sécurisée (par exemple, une visionneuse en lecture seule ou un processus d'exportation contrôlé).

Les filigranes ont donné lieu à des enquêtes. Comptez le nombre de fois où une capture d'écran ou un document imprimé comportant un filigrane a permis de remonter jusqu'à un utilisateur dans le cadre d'une enquête. Même un nombre faible suffit à démontrer l'effet dissuasif de cette mesure.

Demandes de dérogation aux règles. Suivez le nombre d'utilisateurs qui demandent des dérogations aux contrôles du navigateur, ainsi que les motifs invoqués. Un volume élevé de dérogations pour une application spécifique suggère que la règle doit être affinée.

Indicateurs de réduction des risques (suivi trimestriel) :

Réduction du nombre d'incidents liés aux données sensibles impliquant le presse-papiers ou les chemins de téléchargement des applications SaaS. Comparez le volume d'incidents avant et après la mise en place de contrôles au niveau du navigateur pour les mêmes applications SaaS et les mêmes groupes d'utilisateurs.

Couverture du contrôle des sessions sur les appareils non gérés. Mesurez le pourcentage de sessions SaaS sur des appareils non gérés qui transitent par RBI par rapport à celles qui le contournent. Visez une couverture d'au moins 95 % pour les applications de niveau 1.

Délai moyen de détection des tentatives d'exfiltration via le navigateur. La télémétrie du navigateur devrait permettre de réduire ce délai de plusieurs jours (lorsqu'on s'appuie sur des alertes de scan DLP a posteriori) à quelques secondes (blocage en temps réel du presse-papiers).

Le rapport DBIR 2025 de Verizon a révélé que 60 % des violations de données impliquaient un facteur humain : l'utilisateur cliquant, copiant, téléchargeant et collant des données. Les contrôles au niveau du navigateur génèrent des données télémétriques de mise en application portant précisément sur ces actions humaines, offrant ainsi à votre SOC une visibilité sur un vecteur que les contrôles réseau et API ne détectent absolument pas. Parallèlement, Forrester indique qu’environ une violation de données sur cinq résulte d’incidents impliquant des initiés (2026), et les contrôles des sessions de navigateur permettent une mise en application directe et en temps réel contre le presse-papiers et les chemins de téléchargement que les initiés exploitent le plus fréquemment.

Erreurs courantes

Erreur n° 1 : mettre en place une isolation RBI complète pour tous les utilisateurs dès le premier jour. L’isolation complète du streaming de pixels modifie l’expérience de navigation. La latence augmente légèrement, certaines extensions de navigateur cessent de fonctionner et les applications web complexes peuvent s’afficher différemment. Si vous appliquez cette mesure à 5 000 employés simultanément, le service d’assistance se rebellera et la direction mettra fin au projet. Commencez par les appareils non gérés et les applications à haut risque. Étendez progressivement la mise en œuvre.

Erreur n° 2 : appliquer des politiques de navigateur identiques aux appareils gérés et non gérés. Un ordinateur portable non géré appartenant à un sous-traitant justifie un blocage total du presse-papiers et une interdiction des téléchargements. Un terminal d’entreprise géré, équipé d’un agent, d’un chiffrement de disque vérifié et de correctifs à jour, peut se contenter d’un marquage au filigrane et de restrictions sélectives de collage. Différenciez les politiques en fonction de l’état de sécurité de l’appareil. Le profil de risque lié à des identifiants compromis sur un appareil géré équipé d’un EDR est fondamentalement différent de celui sur un appareil non géré pour lequel vous n’avez aucune visibilité — vos politiques de navigateur doivent refléter cette asymétrie.

Erreur n° 3 : négliger les destinations des outils d’IA dans la politique DLP. De nombreuses organisations ont configuré leur solution DLP au niveau du navigateur pour bloquer les téléchargements vers les catégories traditionnelles de « shadow IT » (stockage cloud personnel, messagerie web), mais ont oublié d’inclure les assistants d’IA. Les outils d’IA figurent désormais parmi les destinations non autorisées les plus courantes pour les données copiées-collées et téléchargées. Mettez à jour les catégories d’URL de votre SWG et de votre DLP afin d’y inclure les services d’IA générative, et appliquez les mêmes restrictions relatives au presse-papiers et aux téléchargements que celles que vous imposez aux autres applications non autorisées.

Erreur n° 4 : Considérer les contrôles de navigateur comme un projet autonome plutôt que comme une extension de la politique SSE. Si les contrôles de navigateur sont hébergés dans une console distincte avec des politiques distinctes, ils deviennent un outil de plus que le SOC ignore. Intégrez-les à votre plateforme SSE dès la phase 3 afin que les événements liés au navigateur puissent être mis en corrélation avec les événements CASB, SWG et ZTNA au sein d’un workflow d’incident unique.

Erreur n° 5 : Négliger de classer les applications SaaS en fonction de leur niveau de sensibilité avant de rédiger les politiques. Sans inventaire des applications SaaS classées par niveau de sensibilité, vous risquez soit de bloquer trop d’applications (en isolant celles à faible risque et en frustrant les utilisateurs), soit de ne pas en bloquer suffisamment (en laissant des applications critiques sans contrôle). Les grandes entreprises utilisent couramment des dizaines, voire des centaines d’offres SaaS, et la classification n’est pas facultative : elle constitue le fondement d’une politique ciblée qui permet d’éviter à la fois les failles de sécurité et la révolte des utilisateurs.