23 juin 2026MDM & Endpoints

Navigateurs gérés en MDM : Chrome, Edge et Safari sous contrôle

Un navigateur non configuré est une surface d'attaque ouverte : extensions non vérifiées, proxy contourné, données sensibles synchronisées vers des comptes personnels. Voici comment verrouiller Chrome, Edge et Safari via des profils MDM sans brider la productivité.

Par ZRS-Holding Sàrl·10 min de lecture·231 lectures
Partager

Un vecteur d'attaque sous-estimé dans les PME romandes

Le navigateur est aujourd'hui le principal environnement de travail : messagerie web, ERP SaaS, outils collaboratifs, accès VPN SSL. Pourtant, dans la majorité des PME de 20 à 150 postes auditées, la configuration du navigateur est laissée à l'utilisateur. Résultat concret : extensions installées sans vérification, synchronisation des mots de passe vers un compte Google ou Microsoft personnel, politique de proxy court-circuitée, et certificats d'entreprise ignorés par un profil de navigation privée.

Les CIS Benchmarks publient des profils de durcissement spécifiques pour Chrome, Edge et Safari. Ces recommandations couvrent plus de 200 paramètres par navigateur. Sans MDM pour les déployer et les maintenir, ces profils restent lettre morte.

Architecture : comment le MDM injecte des politiques navigateur

Chrome et Chrome for Business (macOS / Windows / ChromeOS)

Google expose ses politiques via un ensemble de clés de configuration documentées dans le schéma ADM/ADMX (Windows) et via des profils de configuration MDM (macOS, iOS/iPadOS). Sur Windows, Intune distribue le fichier ADMX officiel de Chrome, puis applique les valeurs via un profil OMA-URI. Sur macOS, Apple Business Manager combiné à un MDM (Jamf Pro, Mosyle, Kandji, ou une solution comme FleetDM pour les parcs mixtes) injecte un profil .mobileconfig ciblant le bundle com.google.Chrome.

Points de contrôle critiques à configurer en priorité :

  • SyncDisabled : interdit la synchronisation des données vers un compte Google personnel. Valeur : true.
  • ExtensionInstallBlocklist / Allowlist : liste blanche stricte des extensions autorisées par leur ID Chrome Web Store.
  • SafeBrowsingProtectionLevel : niveau 2 (protection renforcée) minimum pour les parcs régulés.
  • ManagedBookmarks : impose les favoris d'entreprise, non modifiables par l'utilisateur.
  • ProxySettings : force le proxy d'entreprise même en navigation privée.
  • SSLErrorOverrideAllowed : valeur false — interdit à l'utilisateur de passer outre une erreur de certificat.
  • IncognitoModeAvailability : valeur 1 pour désactiver complètement le mode navigation privée.

Microsoft Edge (Chromium)

Edge partage le moteur Chromium avec Chrome mais expose ses propres clés de politique, préfixées microsoft.edge.* dans le schéma ADMX. Sur Windows 11 avec Intune, le déploiement se fait via le catalogue de paramètres (Settings Catalog) directement — pas besoin d'importer l'ADMX manuellement depuis Edge 93+.

Paramètres spécifiques à Edge en environnement Microsoft 365 :

  • EnterpriseModeSiteListManager : mode compatibilité IE pour les applications legacy (encore fréquent dans les ERP suisses).
  • SyncDisabled : même logique que Chrome — bloque la synchro vers un compte Microsoft personnel.
  • BrowserSignin : valeur 0 (désactiver la connexion au navigateur) ou 2 (forcer la connexion avec le compte Azure AD/Entra ID d'entreprise uniquement).
  • EdgeCollectionsEnabled : valeur false — désactive la fonctionnalité Collections qui peut exfiltrer du contenu web.
  • SmartScreenEnabled : true obligatoire — filtre phishing Microsoft Defender.
  • PreventSmartScreenPromptOverride : true — empêche l'utilisateur de contourner l'alerte SmartScreen.

Safari (macOS / iPadOS via Apple Business Manager)

Safari est différent des deux autres : il n'existe pas de politique enterprise aussi granulaire que Chrome ou Edge. Apple contrôle les restrictions via les profils de configuration MDM ciblant les payloads com.apple.Safari et les restrictions generales du payload com.apple.applicationaccess.

Ce qui est configurable via MDM pour Safari :

  • Blocage de l'accès à des catégories de sites web (Content Filter payload, intégré nativement sur iOS/iPadOS 16+ et macOS 13+).
  • Forçage de la navigation HTTPS uniquement (HSTS imposé, redirection HTTP bloquée).
  • Restriction d'installation d'extensions Safari via allowedExtensions (macOS 13 Ventura+).
  • Désactivation du remplissage automatique de formulaires web (payload AutoFillEnabled à false).
  • Blocage du Handoff entre appareils (évite la fuite de sessions vers un iPhone personnel non géré).

Limite importante : Safari sur macOS ne supporte pas de liste blanche d'extensions au niveau MDM aussi fine que Chrome. Pour les parcs macOS nécessitant un contrôle strict des extensions, certaines organisations basculent vers Chrome ou Edge comme navigateur d'entreprise, même sur Mac, précisément pour bénéficier de la granularité des politiques.

Cadre légal suisse : ce que la nLPD impose côté navigateur

La nouvelle Loi sur la protection des données (nLPD), en vigueur depuis le 01.09.2023, renforce les obligations de sécurité technique des responsables de traitement. L'article 8 nLPD impose des mesures organisationnelles et techniques appropriées pour protéger les données personnelles. Un navigateur non géré, synchronisant des données métier vers un compte personnel, constitue un traitement non documenté — donc une violation potentielle du principe de transparence et de minimisation.

Concrètement, si un collaborateur stocke des données clients dans les favoris Chrome synchronisés vers son compte Gmail personnel, l'entreprise ne maîtrise plus le traitement : perte de contrôle sur la localisation des données (serveurs Google hors Suisse), absence de base légale pour cette synchronisation, et impossibilité d'exercer un droit à l'effacement côté PFPDT.

En cas de violation de données impliquant un navigateur non géré, le Préposé fédéral à la protection des données (PFPDT) pourra considérer l'absence de mesures techniques comme une faute organisationnelle. La nLPD prévoit des sanctions pénales jusqu'à CHF 250 000 pour les personnes physiques responsables (art. 60 nLPD).

Déploiement pas à pas : exemple sur un parc mixte Windows/macOS

Prérequis

  • Windows : Intune (Microsoft Endpoint Manager), licences Microsoft 365 Business Premium ou E3 minimum.
  • macOS : Apple Business Manager (ABM) + MDM compatible (Jamf, Mosyle, ou équivalent). Les endpoints doivent être supervisés (Supervised Mode via ABM ou Apple Configurator 2).
  • Android : Android Enterprise (Work Profile ou Fully Managed) avec Chrome for Work configuré via Managed Google Play.

Étapes de déploiement Windows / Edge et Chrome via Intune

  1. Importer les ADMX (si Edge < 93 ou Chrome) : télécharger les templates depuis les sources officielles Google/Microsoft, uploader dans Intune > Device Configuration > Administrative Templates.
  2. Créer un profil de configuration : Intune > Devices > Configuration profiles > Create > Windows 10/11 > Settings Catalog. Rechercher les paramètres par nom (ex. : «SyncDisabled», «ExtensionInstallBlocklist»).
  3. Définir le scope : cibler un groupe Azure AD/Entra ID dédié aux endpoints gérés. Ne jamais déployer directement sur «All Devices» sans test préalable.
  4. Tester sur un groupe pilote de 3 à 5 machines. Vérifier que le proxy d'entreprise est bien appliqué, que les extensions non listées sont refusées, et que le compte personnel ne peut pas être ajouté.
  5. Monitorer la conformité : créer une politique de conformité Intune vérifiant que les paramètres clés sont actifs. Non-conformité = accès conditionnel bloqué (Conditional Access).
  6. Documenter dans le registre des traitements (exigé par la nLPD) : ajouter une entrée décrivant les politiques navigateur appliquées, les données concernées, et les mesures techniques en place.

Étapes de déploiement macOS / Safari et Chrome via ABM

  1. Vérifier la supervision : dans le MDM, confirmer que les Macs sont en mode «Supervised». Non supervisé = restrictions limitées.
  2. Créer un profil .mobileconfig pour com.google.Chrome (si Chrome est le navigateur d'entreprise) avec les clés listées ci-dessus.
  3. Payload Restrictions : configurer le filtrage de contenu web natif (macOS 13+ : payload Network Content Filter) pour bloquer les catégories inadéquates sans proxy externe.
  4. Tester l'injection : sur un Mac pilote, ouvrir Chrome > chrome://policy — toutes les politiques actives doivent apparaître avec la source «Platform».
  5. Scope par groupe ABM : utiliser les Smart Groups du MDM pour cibler par département ou niveau de sensibilité des données.

Cas pratique : fiduciaire vaudoise, 45 postes

Une fiduciaire basée à Lausanne, 45 collaborateurs, parc composé de 30 MacBook Pro (macOS 14 Sonoma) et 15 PC Windows 11 23H2. Navigateurs en usage : Safari (Macs), Edge (Windows), Chrome installé manuellement par plusieurs collaborateurs sur les deux plateformes. Aucune politique navigateur en place avant l'audit.

Problèmes identifiés lors de l'audit initial :

  • 8 collaborateurs utilisaient Chrome avec un compte Google personnel synchronisé — données fiscales clients potentiellement présentes dans l'historique synchronisé.
  • Extension «Grammarly» installée sur 12 postes Windows, avec accès au contenu de tous les champs de formulaire web, y compris les données de clients.
  • Aucun filtrage de contenu web actif. Accès libre à des sites de partage de fichiers (WeTransfer, Dropbox non géré).
  • Mode navigation privée disponible, contournant le proxy Squid d'entreprise sur les Windows.

Déploiement réalisé en 3 semaines :

  1. Semaine 1 — Inventaire et décision de gouvernance : choix de Chrome comme navigateur unique (compatibilité ERP Abacus testé), Edge conservé sur Windows pour les applications legacy en mode IE. Safari désactivé comme navigateur par défaut sur les Macs via MDM.
  2. Semaine 2 — Déploiement des profils MDM :
    • macOS : profil com.google.Chrome déployé via Mosyle. SyncDisabled = true. ExtensionInstallAllowlist : 4 extensions validées par le DSI (uBlock Origin, LastPass Enterprise, DocuSign, Adobe Acrobat). IncognitoModeAvailability = 1.
    • Windows : profil Intune Settings Catalog. Mêmes paramètres Chrome. Edge : BrowserSignin = 2 (compte Entra ID uniquement), SmartScreen activé obligatoire.
  3. Semaine 3 — Validation et formation : vérification via chrome://policy sur 5 postes représentatifs. Formation de 45 minutes pour les collaborateurs : explication du pourquoi (nLPD, responsabilité professionnelle), pas seulement du comment. Mise à jour du registre des traitements.

Résultat chiffré : 0 extension non autorisée active à J+30. Réduction de la surface d'attaque navigateur estimée à -60 % selon le score CIS CAT Pro (passage de 42 % à 78 % de conformité CIS Chrome Benchmark niveau 1). Coût de mise en œuvre DSI interne : environ 18 heures. Aucun licencié supplémentaire requis (Mosyle et Intune déjà en place).

Récapitulatif opérationnel

  • Inventorier tous les navigateurs installés sur le parc — y compris les installations «shadow» hors politique. Outil : Intune Discovered Apps ou fleetdm.com pour parcs mixtes.
  • Choisir un navigateur d'entreprise par plateforme et le déclarer dans la politique de sécurité. Tolér les autres ou les bloquer via AppLocker/MDM Restrictions.
  • Déployer SyncDisabled = true en priorité absolue sur Chrome et Edge — c'est le paramètre à impact de fuite de données le plus immédiat.
  • Établir une liste blanche d'extensions : toute extension hors liste est bloquée. Processus de validation : test en sandbox, revue du manifeste de permissions, approbation DSI/RSSI.
  • Activer le filtrage de contenu web intégré au MDM (Apple Content Filter, Intune Web Content Filtering) ou via proxy d'entreprise — mais s'assurer que le proxy ne peut pas être contourné en mode privé.
  • Forcer HTTPS uniquement et bloquer les overrides de certificat (SSLErrorOverrideAllowed = false).
  • Vérifier la conformité en continu : créer des règles de compliance Intune/MDM qui alertent si les politiques navigateur ne sont plus actives (ex. : après une réinstallation OS).
  • Documenter dans le registre nLPD : les mesures techniques navigateur font partie des garanties à mentionner pour les traitements de données personnelles. Exigé par l'art. 12 nLPD (sécurité des données).
  • Réviser annuellement les profils MDM navigateur : les navigateurs publient des nouvelles politiques à chaque version majeure (Chrome 120+, Edge 121+). Consulter les CIS Benchmarks mis à jour pour chaque release.
  • Tester le phishing simulé avec les politiques actives : vérifier que SmartScreen/SafeBrowsing bloquent effectivement les domaines de test (ex. : NCSC publie des recommandations de sensibilisation utilisables comme base).

SynGuard propose des audits de configuration MDM navigateur et le déploiement de profils CIS adaptés aux parcs suisses de 20 à 150 endpoints — sans engagement long terme.

Sources

Noter cet article

4.0 / 5 · 1 vote