BYOD et accès des prestataires : sécurisation des appareils non gérés via le navigateur

Un cabinet de conseil a besoin que 200 collaborateurs externes puissent accéder à ses environnements SharePoint et Salesforce internes dans le cadre d’une mission de six mois. Leurs ordinateurs portables personnels ne prennent pas en charge les agents de sécurité, l’inscription à une solution MDM est hors de question pour des appareils que ces collaborateurs utilisent également pour leurs opérations bancaires personnelles et pour stocker des photos de famille, et la mise en place d’une infrastructure VDI pour un effectif temporaire ferait exploser le budget du projet. Le navigateur — l’application déjà ouverte sur chacun de ces ordinateurs portables — constitue le point de contrôle le plus pratique dont vous disposez. Ce guide propose aux responsables de la sécurité une approche par étapes pour sécuriser l’accès BYOD et celui des collaborateurs externes grâce à des contrôles basés sur le navigateur, depuis les conditions préalables jusqu’aux critères de réussite mesurables.

Conditions préalables : ce dont vous avez besoin avant de commencer

Avant de configurer les contrôles d'accès via navigateur pour les utilisateurs BYOD et les prestataires, assurez-vous que ces bases sont bien en place. Le fait de les négliger est la cause la plus fréquente de blocage des déploiements.

L’infrastructure d’identité doit prendre en charge les utilisateurs externes. Votre fournisseur d’identité (IdP) doit gérer les identités fédérées des prestataires, et pas seulement celles des employés. Imaginez le cas d’un cabinet de conseil : le chef de projet envoie des instructions d’intégration à 200 prestataires un lundi. Si votre IdP n’est pas en mesure de délivrer des identités à portée limitée et à durée déterminée, liées à un domaine externe, vous passerez cette semaine à créer manuellement des comptes — et vous oublierez de les supprimer à la fin de la mission. La norme NIST SP 800-46 Rev. 2 traite explicitement des exigences de sécurité relatives au BYOD (Bring Your Own Device) ainsi qu’aux appareils clients contrôlés par les prestataires, les partenaires commerciaux et les fournisseurs, en soulignant l’importance de sécuriser les informations sensibles stockées sur ces appareils et transmises par leur intermédiaire.

Inventaire des applications par méthode d'accès. Répertoriez les applications dont les prestataires ont besoin, qu'il s'agisse d'applications SaaS (accessibles via un proxy direct ou inverse), d'applications web internes (accessibles via ZTNA) ou d'anciennes applications « thick client » (qui peuvent encore nécessiter une infrastructure VDI). La plupart des charges de travail des prestataires s'articulent autour des applications SaaS — SharePoint, Salesforce, ServiceNow —, ce qui rend l'application des règles via un navigateur envisageable pour la majorité des sessions.

Classification des données pour la mise en correspondance des politiques DLP. Si vous n’avez pas défini ce qui constitue des données sensibles dans les applications auxquelles les sous-traitants auront accès, les politiques DLP bloqueront soit trop d’éléments, soit rien du tout. Vous devez au minimum définir des critères de déclenchement pour les données à caractère personnel, les documents financiers et la propriété intellectuelle.

Décision relative à l'architecture réseau. La norme NIST SP 800-46 recommande aux organisations d'envisager l'utilisation de solutions de contrôle d'accès au réseau qui vérifient le niveau de sécurité d'un appareil client avant de lui permettre d'accéder au réseau interne, et d'envisager l'utilisation d'un réseau distinct pour tous les appareils clients externes, y compris les appareils BYOD et ceux contrôlés par des tiers. Pour les accès via un navigateur, cela implique d'acheminer tout le trafic provenant d'appareils non gérés via votre plateforme SSE plutôt que de leur accorder un accès direct au réseau.

Phase 1 : Mise en place d'une visibilité et d'une politique de référence avec le CASB et le SWG

Commencez par répondre à la question fondamentale : quel rôle jouent réellement, aujourd'hui, les appareils non gérés dans vos applications SaaS ?

Déployez le CASB en mode proxy inverse afin d’intercepter les sessions provenant d’appareils non gérés qui accèdent à des applications SaaS autorisées. Un proxy inverse ne nécessite aucun agent : le prestataire se contente de s’authentifier via votre fournisseur d’identité (IdP) et est acheminé de manière transparente via le point d’application du CASB. Dans le cas du cabinet de conseil, lorsqu’un prestataire se connecte à Salesforce depuis un MacBook personnel, le CASB détecte la session, classe l’appareil comme non géré en raison de l’absence de certificat client, puis applique votre politique relative aux appareils non gérés : accès en lecture seule aux fiches d’opportunité, interdiction d’exportation en masse et ajout d’un filigrane sur les affichages à l’écran.

Parallèlement, acheminez le trafic Web de ces utilisateurs via votre SWG afin d'appliquer les politiques d'utilisation acceptable, de bloquer l'accès aux catégories à haut risque et d'analyser les téléchargements à la recherche de logiciels malveillants. Le SWG constitue votre première ligne de défense contre un prestataire qui cliquerait sur un lien de hameçonnage dans un onglet de messagerie personnelle alors qu'il est également connecté à votre instance SharePoint d'entreprise.

Éléments à évaluer à ce stade :

Nombre de sessions sur des appareils non gérés détectées chaque jour

Applications SaaS auxquelles accèdent des appareils non gérés (détection des applications SaaS « fantômes »)

Violations des règles bloquées (téléchargements en masse, accès non autorisé aux applications)

Délai moyen entre la demande d'intégration d'un prestataire et l'obtention d'un accès opérationnel

Cette phase vous fournit les données de télémétrie nécessaires pour justifier les investissements dans les phases suivantes. Si votre CASB révèle que des prestataires téléchargent chaque semaine des listes de clients sur leurs appareils personnels, l'analyse de rentabilité de la phase 2 s'impose d'elle-même.

Phase 2 : Mise en place de Remote Browser Isolation les sessions hautement sensibles

Une fois la visibilité assurée, l'étape suivante consiste à éliminer complètement le terminal en tant que vecteur de menace pour vos applications les plus sensibles. C'est là qu'intervient remote browser isolation devient la mesure de contrôle la plus efficace disponible pour les appareils non gérés.

Prenons un cas concret : un prestataire externe travaillant pour un cabinet de conseil doit consulter dans Salesforce des dossiers clients contenant des données à caractère personnel (DCP) — noms, adresses, montants des contrats. Grâce à RBI, la session Salesforce s'exécute dans un conteneur basé sur le cloud. Le prestataire consulte l’application et interagit avec elle normalement depuis son navigateur Chrome ou Safari, mais aucune donnée d’application, aucun jeton de session ni aucun contenu de page n’atteint jamais l’appareil local. Si l’ordinateur portable personnel du prestataire est compromis par un enregistreur de frappe ou un logiciel de vol d’informations, le logiciel malveillant n’a rien d’utile à capturer, car la session ne s’exécute jamais localement.

RBI permet également d'appliquer des contrôles granulaires sur les données au sein de la session isolée. Vous pouvez désactiver le copier-coller, bloquer l'impression, empêcher le téléchargement de fichiers et appliquer des filigranes dynamiques qui intègrent l'identité de l'utilisateur dans les captures d'écran. À la fin de la session, le conteneur est détruit, ne laissant aucune trace de données sur l'appareil non géré.

Cette approche s'inscrit directement dans la lignée des principes du « zero trust ». La norme NIST SP 800-207 reconnaît explicitement que les appareils connectés au réseau peuvent ne pas appartenir à l'entreprise ni être configurables par celle-ci, et que les services sous-traités peuvent inclure des ressources n'appartenant pas à l'entreprise qui ont besoin d'un accès au réseau pour remplir leur rôle. Le RBI constitue la mise en œuvre concrète de ce principe : vous accordez l'accès à une application sans faire confiance à l'appareil.

Quand utiliser RBI plutôt qu'un proxy CASB standard :

Quand utiliser le proxy RBI plutôt que le proxy CASB standard ?

Phase 3 : Étendre le ZTNA aux applications privées

Les applications SaaS ne constituent qu'une partie du tableau. De nombreuses missions confiées à des prestataires nécessitent l'accès à des applications web internes — portails personnalisés, wikis internes, environnements de développement — qui ne sont pas accessibles depuis Internet.

Un VPN traditionnel offre aux prestataires un tunnel au niveau du réseau vers votre environnement, ce qui va à l'encontre de tous les principes du modèle « zero trust ». Si l'un de ces 200 prestataires dispose d'un logiciel malveillant sur son ordinateur portable personnel et que vous lui avez accordé un accès VPN, ce logiciel malveillant peut analyser votre réseau interne, tenter une propagation latérale et atteindre des systèmes bien au-delà du périmètre d'intervention prévu pour ce prestataire.

ZTNA / Private Access le VPN par un accès au niveau des applications. Le prestataire s'authentifie ; le moteur de règles évalue son identité, le contexte de son appareil et les signaux de risque, puis lui accorde uniquement l'accès aux applications internes spécifiques autorisées pour son rôle — et rien d'autre. Le prestataire ne voit ni n'accède jamais au réseau sous-jacent.

Les niveaux de maturité du modèle « Zero Trust » de la CISA permettent aux organisations d’évaluer, de planifier et de maintenir les investissements nécessaires pour évoluer vers un modèle « Zero Trust » à travers cinq piliers : l’identité, les appareils, les réseaux, les applications et les charges de travail, ainsi que les données. Le passage du VPN au ZTNA pour l’accès des prestataires constitue une avancée mesurable, marquant le passage du niveau de maturité « Traditionnel » au niveau « Initial » tant pour le pilier « Appareils » que pour le pilier « Réseaux ».

Dans le cas d’un cabinet de conseil, le ZTNA permet à Jane, la prestataire, d’accéder au portail interne de suivi des projets depuis son ordinateur portable personnel à domicile, mais elle ne peut pas analyser le réseau, atteindre le contrôleur de domaine ni accéder à l’application financière. Si sa mission prend fin vendredi, son accès est révoqué au niveau de la couche applicative : pas besoin de rechercher des certificats VPN ni de supprimer des règles de pare-feu.

Pourquoi les solutions VDI et MDM ne sont pas à la hauteur pour le BYOD et l'accès des prestataires

Les responsables de la sécurité évaluent souvent les solutions VDI et MDM avant d'envisager des contrôles basés sur un navigateur. Ces deux solutions ont des cas d'utilisation légitimes, mais aucune n'est particulièrement adaptée à des parcs d'appareils non gérés, temporaires et de grand volume.

VDI (Virtual Desktop Infrastructure) : la VDI crée un environnement de bureau centralisé sur un serveur, en diffusant une session visuelle vers l’appareil de l’utilisateur. Elle est idéale pour les environnements fortement réglementés nécessitant des applications « client lourd ». Mais pour 200 prestataires accédant à des applications SaaS pendant six mois, la VDI est une solution disproportionnée. Les solutions VDI hébergées dans le cloud coûtent généralement plusieurs dizaines de dollars par utilisateur et par mois, tandis que la VDI sur site nécessite un investissement important en serveurs, en infrastructure réseau et en logiciels de virtualisation. Pour une mission impliquant 200 prestataires, le coût total des abonnements VDI peut à lui seul atteindre plusieurs dizaines de milliers de dollars sur six mois, sans compter les frais liés à l’infrastructure, aux licences et à l’assistance. La VDI entraîne également une latence, des interruptions de session et de longs délais de mise en service, ce qui frustre les utilisateurs et réduit la productivité.

MDM (gestion des appareils mobiles) : le MDM nécessite l’installation d’un profil de gestion sur l’appareil personnel du prestataire, ce qui confère à l’organisation le contrôle des paramètres de l’appareil, la possibilité d’effacer les données à distance et une visibilité sur les applications installées. La plupart des prestataires s’y opposeront. Leur appareil est leur bien personnel ; ils l’utilisent pour leurs opérations bancaires, leurs e-mails privés et leurs photos de famille. Demander à un prestataire de s’inscrire au MDM engendre des conflits juridiques, des objections liées à la vie privée et retarde l’intégration de plusieurs jours, voire plusieurs semaines.

Contrôles basés sur un navigateur (CASB + RBI + SWG + ZTNA) : aucun agent, aucun enregistrement d’appareil, aucune infrastructure à faire évoluer. Le prestataire ouvre son navigateur, s’authentifie via votre fournisseur d’identité (IdP), et les politiques de sécurité sont appliquées au niveau de la couche de session. Le temps d’intégration passe de plusieurs jours à quelques minutes. Le marché de la sécurité BYOD reflète cette évolution : évalué à 60,64 milliards de dollars en 2025, il devrait atteindre 120,36 milliards de dollars d’ici 2032, avec un TCAC de 10,28 % (GII Research, 2026).

Tableau 2 : Comparaison entre les solutions VDI, MDM et les contrôles basés sur un navigateur

Points d'intégration : comment faire fonctionner la sécurité du navigateur avec votre infrastructure existante

Les contrôles BYOD basés sur un navigateur ne fonctionnent pas de manière isolée. Leur efficacité est décuplée lorsqu'ils sont intégrés à votre infrastructure de sécurité existante.

Fournisseur d’identité (IdP) et accès conditionnel : votre IdP (Azure AD, Okta, Ping) joue le rôle de gardien. Configurez des politiques d’accès conditionnel qui détectent les appareils non gérés — généralement en raison de l’absence d’un certificat client ou d’un signal de conformité — et acheminent automatiquement ces sessions via le proxy inverse CASB ou le RBI. Lorsqu’un prestataire se connecte à SharePoint à partir d’un appareil non enregistré, l’IdP doit automatiquement appliquer le chemin d’accès le plus strict sans intervention manuelle.

Unification des politiques DLP : les mêmes politiques DLP qui protègent les données sur les terminaux gérés doivent s’étendre aux sessions de navigation à partir d’appareils non gérés. Si votre politique DLP bloque l’exportation en masse des dossiers clients par les employés, elle doit également la bloquer pour les prestataires accédant via RBI. Le rapport IBM sur le coût des fuites de données (2024) quantifie ce risque : le coût moyen mondial d’une fuite de données a atteint 4,88 millions de dollars en 2024, soit une augmentation de 10 % par rapport à l’année précédente, ce qui représente la plus forte hausse depuis le début de la pandémie. Une application cohérente des politiques DLP, tant pour les accès gérés que non gérés, réduit le risque de faire partie de cette statistique.

Intégration SIEM et UEBA : acheminez les journaux de session provenant du CASB, du RBI et du ZTNA vers votre SIEM afin d’établir des références comportementales pour l’activité des prestataires. Si un prestataire qui accède habituellement à 20 enregistrements Salesforce par jour en exporte soudainement 2 000, cette anomalie devrait déclencher une alerte. La visibilité et l’analyse constituent l’une des trois capacités transversales du modèle de maturité « Zero Trust » de la CISA, et la télémétrie au niveau des sessions issue des contrôles de navigateur en est une mise en œuvre concrète.

Automatisation de la désaffiliation : lorsqu’un contrat avec un prestataire prend fin, désactivez son identité au niveau de l’IdP. L’accès étant basé sur une session et appliqué au niveau du proxy ou de la couche RBI, il n’y a aucun certificat VPN à révoquer, aucun agent de terminal à désinstaller et aucun profil d’appareil à supprimer. L’accès cesse tout simplement d’exister.

Indicateurs et critères de réussite

Mesurez ce qui compte. Ces indicateurs permettent de déterminer si vos contrôles d'accès liés au BYOD et aux prestataires, mis en œuvre via un navigateur, sont efficaces et justifient la poursuite de vos investissements.

Indicateurs opérationnels :

Délai moyen d'accès des prestataires : de la création du compte à la première session productive. Objectif : moins de 30 minutes. Si vous mesurez ce délai en jours, le processus doit être amélioré.

Volume de sessions sur les appareils non gérés : nombre total de sessions par semaine provenant d'appareils classés comme non gérés. Une tendance à la hausse est attendue à mesure que l'adoption se développe ; une tendance à la baisse alors que les effectifs des sous-traitants restent stables suggère un contournement du système.

Taux de violation des règles : nombre d'actions bloquées (téléchargements, copier-coller, accès non autorisé à des applications) pour 1 000 sessions. Un taux constamment élevé peut indiquer que les règles sont trop restrictives ou que la communication avec les utilisateurs est insuffisante.

Indicateurs de sécurité :

Incidents liés à l'absence de résidus de données : nombre d'événements de fuite de données imputables à un appareil non géré. L'objectif est de zéro pour les sessions protégées par RBI.

Taux de détection des applications SaaS non autorisées : nombre d'applications SaaS non autorisées auxquelles accèdent des appareils non gérés, tel que détecté par le CASB. Cet indicateur devrait diminuer au fil du temps à mesure que vous renforcez vos politiques SWG.

Incidents de vol d'identifiants à partir d'appareils non gérés : les attaques par usurpation d'identifiants ont représenté 16 % de l'ensemble des violations de données et ont été celles qui ont pris le plus de temps à être identifiées et maîtrisées, soit près de 292 jours (IBM, 2024). L'isolation des sessions proposée par RBI devrait réduire à presque zéro le vol d'identifiants résultant d'attaques par navigateur.

Indicateurs de coûts :

Coût par accès de prestataire : comparez le coût total des licences SSE pour les sessions sur des appareils non gérés au coût équivalent d'une solution VDI. La différence obtenue justifie le renouvellement.

Volume de tickets d'assistance liés à l'accès des sous-traitants : les contrôles basés sur un navigateur devraient générer moins de tickets d'assistance que les solutions VDI ou MDM, car il n'y a pas de logiciel client à dépanner.

Erreurs courantes

Traiter tous les appareils non gérés de la même manière. Un sous-traitant qui accède à des documents de projet non sensibles n'a pas besoin des mêmes contrôles qu'un autre qui traite des données à caractère personnel (DCP) de clients. L'application excessive de la politique RBI à chaque session augmente les coûts et la latence. Optez pour une hiérarchisation basée sur les risques : un proxy CASB pour les applications à faible sensibilité, et la politique RBI pour les applications à haute sensibilité.

On oublie souvent les données en transit entre les applications. Vous avez verrouillé l’accès à Salesforce à l’aide de RBI, mais le prestataire peut toujours copier le nom d’un client depuis Salesforce, le coller dans un outil d’IA générative ouvert dans un onglet adjacent et obtenir une réponse contenant des données enrichies. Associez RBI à des politiques SWG qui restreignent l’accès aux outils d’IA générative depuis des sessions sur des appareils non gérés — ou acheminez également l’accès à ces outils via un environnement isolé. Skyhigh présente des contrôles supplémentaires pour ce scénario dans ses recommandations sur la protection des applications cloud contre les appareils non gérés.

On néglige souvent le processus de désaffiliation. On accorde toute l’attention à la mise en place des droits d’accès, tandis que la suppression de ces droits ne fait l’objet que d’un simple post-it. Automatisez les déclencheurs de désaffiliation liés aux dates de fin de mission dans votre système RH ou de gestion des achats. Un prestataire qui conserve ses droits d’accès trois mois après la fin de son projet représente une menace interne, qu’il en ait l’intention ou non.

Négliger la communication avec les utilisateurs. Les prestataires qui découvrent le système RBI pour la première fois peuvent signaler que « l’application semble différente » ou que la fonction copier-coller ne fonctionne pas. Sans communication proactive expliquant pourquoi ces contrôles existent et quels comportements ils restreignent, vous verrez apparaître des solutions de contournement clandestines : des prestataires envoyant des données par e-mail vers leurs comptes personnels pour contourner les restrictions de téléchargement.

Déploiement de contrôles de navigateur sans DLP. L’isolation du navigateur sans data loss prevention fermer la porte tout en laissant une fenêtre ouverte. Le RBI empêche les données d’atteindre l’appareil, mais le DLP garantit que les données présentes au sein de la session ne peuvent pas être exfiltrées par des canaux autorisés — téléchargement vers un compte de stockage cloud personnel, envoi par e-mail à une adresse non professionnelle ou impression au format PDF local. IBM a constaté que 35 % des violations de données concernaient des « données fantômes » — c’est-à-dire des informations stockées dans des sources de données non gérées (IBM, 2024) —, ce qui souligne à quel point les mouvements de données non contrôlés engendrent des coûts et des risques.

Partir du principe qu’un seul modèle de déploiement convient à tous. Certaines catégories d’utilisateurs peuvent tirer profit d’une extension de navigateur légère sur des appareils gérés, tandis que les prestataires externes utilisent le RBI sans agent. Adaptez le contrôle à l’état de l’appareil et au type d’utilisateur plutôt que d’imposer une approche unique à l’ensemble de votre personnel.