Profils de navigateur locaux ou synchronisés dans le cloud

Définir le système avant de comparer les étiquettes

Un profil de navigateur ne se résume pas à une ligne dans un sélecteur. La documentation de Chromium sur le répertoire de données utilisateur décrit des données de profil telles que l’historique, les favoris et les cookies, en plus d’un état local propre à l’installation. Un produit d’équipe peut y ajouter des extensions, une configuration de proxy, la propriété, des enregistrements d’audit, des métadonnées de chiffrement, des versions de sauvegarde et un état de synchronisation.

Évaluez trois couches indépendantes :

1. Exécution : où le code du navigateur s’exécute-t-il et où le contenu web est-il rendu ?
2. Contenu : où les cookies, le stockage des sites, l’historique, les extensions et les autres états du profil existent-ils sous une forme lisible ?
3. Contrôle : où l’identité, les adhésions, les rôles, les verrous, les événements d’audit, la facturation et les enregistrements d’appareils existent-ils ?

Un produit peut exécuter le navigateur localement, téléverser des ensembles de profils chiffrés et conserver des métadonnées opérationnelles limitées dans un plan de contrôle cloud. Qualifier toute cette conception de « locale » ou de « cloud » masque les décisions importantes.

Trois modèles de profils courants

Modèle	Principal avantage	Principal coût ou risque à examiner
Profil uniquement local	La perte du service cloud ne supprime pas la copie locale active ; le contenu lisible peut rester sur un appareil	La perte de l’appareil, sa compromission, les sauvegardes et le transfert en équipe deviennent la responsabilité de l’équipe
Synchronisation lisible par le serveur	Accès simple depuis plusieurs appareils, traitement centralisé et récupération assistée par le fournisseur potentiellement possibles	Le fournisseur ou un chemin de service compromis peut éventuellement lire le contenu synchronisé, selon la conception documentée
Synchronisation chiffrée côté client	Le service peut stocker et transférer du texte chiffré sans détenir la clé de déchiffrement du contenu	Distribution des clés, récupération, accès des appareils révoqués, résolution des conflits et assistance plus difficiles ; certaines métadonnées peuvent rester visibles

Ces modèles ne constituent pas un classement de qualité. Un service lisible par le serveur et exploité avec soin peut mieux convenir qu’un service chiffré mal conçu. Un profil uniquement local sans sauvegarde testée peut protéger d’une menace cloud tout en restant fragile face à une panne matérielle ordinaire.

Les termes de chiffrement exigent une carte des flux de données

« Chiffré » peut désigner plusieurs contrôles :

• Le chiffrement en transit protège une connexion entre des extrémités.
• Le chiffrement au repos protège le support stocké, mais le service peut toujours détenir les clés de déchiffrement.
• Le chiffrement côté client ou de bout en bout vise à conserver les clés de contenu sur les extrémités autorisées afin que le service de stockage ne puisse pas lire le contenu protégé.
• Le chiffrement de l’appareil ou du volume protège le stockage local dans certains états verrouillés ou hors ligne. Il ne protège pas les données contre un logiciel malveillant ou un processus autorisé après déverrouillage.

La présentation de la sécurité d’iCloud d’Apple montre pourquoi cette distinction compte. Apple documente TLS en transit et le chiffrement au repos pour iCloud, tout en distinguant les catégories dont Apple détient les clés et peut faciliter la récupération de celles protégées de bout en bout. Il s’agit d’un exemple de terminologie, non d’une preuve concernant un autre fournisseur.

Pour tout système de profils, demandez un schéma indiquant chaque emplacement où les données en clair et les clés peuvent exister : appareil source, mémoire, disque local, archive d’export, sauvegarde, service de synchronisation, appareil d’un autre membre, outils d’assistance, journaux et télémétrie.

Comparer les défaillances importantes pour l’équipe

Événement	Questions pour une conception locale par défaut	Questions pour une conception synchronisée
Appareil perdu ou défaillant	Existe-t-il une sauvegarde indépendante récente et un matériel de récupération séparé ?	Un appareil de remplacement reçoit-il une copie complète et autorisée ? Qu’est-ce qui exige une nouvelle authentification ?
Terminal compromis	Un logiciel malveillant peut-il lire les profils déverrouillés ou voler du matériel de session ?	L’appareil compromis peut-il téléverser un état empoisonné ou obtenir d’autres profils ?
Violation du service cloud	Quelles métadonnées de compte, d’appareil et de diagnostic existent à distance ?	Le service peut-il déchiffrer le contenu ? Un attaquant peut-il remplacer le texte chiffré, les versions ou les enregistrements d’adhésion ?
Suppression ou corruption accidentelle	Quels points de restauration antérieurs subsistent sur un stockage séparé ?	La suppression ou la corruption se propage-t-elle ? Un administrateur peut-il sélectionner une version connue comme valide ?
Départ d’un membre de l’équipe	Quelles copies locales et quels exports restent hors du contrôle central ?	L’appareil et ses clés peuvent-ils être révoqués ? Quel contenu a déjà été déchiffré localement ?
Indisponibilité du réseau ou du fournisseur	Le travail autorisé peut-il continuer et les modifications être mises en attente sans danger ?	Quelles opérations échouent en mode fermé et comment les conflits sont-ils traités après reconnexion ?
Perte de la clé de chiffrement	Qui peut récupérer, renouveler ou mettre la clé sous séquestre selon la politique approuvée ?	Une récupération assistée par le fournisseur affaiblit-elle la limite de confiance annoncée ?

La compromission du terminal reste importante dans tous les modèles. Le chiffrement côté client réduit certaines expositions côté serveur, mais un appareil autorisé doit déchiffrer le contenu pour l’utiliser. Le chiffrement ne peut pas rendre fiable un terminal déverrouillé et compromis.

Comparer séparément les catégories de données

Les différents types de données d’un profil méritent des règles différentes de placement et de partage.

État d’exécution sensible

Les cookies, jetons de session, données de stockage local, identifiants enregistrés et certaines données d’extensions peuvent donner accès à des comptes ou révéler une activité. Traitez-les comme des secrets ou du contenu sensible du profil. Ne les exposez pas dans les journaux courants, la recherche, les flux d’audit ou les sorties d’automatisation. Le partage d’une session active peut aussi enfreindre la politique d’un client ou les conditions d’un tiers, même lorsque l’opérateur est par ailleurs autorisé.

Configuration reconstructible

Les favoris, les identifiants d’extensions approuvées, les paramètres de locale et les références de politiques peuvent être plus faciles à reconstruire et moins risqués à synchroniser qu’un état de session actif. Cela ne rend pas tous les champs inoffensifs. Un mot de passe de proxy reste un secret même s’il figure à côté d’une configuration de proxy ordinaire.

Métadonnées opérationnelles

Les libellés de profils, identifiants d’organisation, attributions de propriétaire, numéros de version, identifiants d’appareils, verrous et événements d’audit peuvent être nécessaires à la coordination de l’équipe. Réduisez ces champs au minimum, définissez leur conservation et déterminez si un libellé révèle à lui seul une relation client.

La description des données Chrome Sync de Google est un exemple propre à un fournisseur qui montre l’importance de cet inventaire : elle distingue le contenu créé par l’utilisateur, les informations sur l’utilisateur et l’appareil, les informations sur les sites, les informations sur les extensions et celles sur le navigateur. N’utilisez la liste d’un fournisseur que pour comprendre son comportement publié.

Matériel de récupération

Les clés de chiffrement, codes de récupération, mots de passe de sauvegarde et authentificateurs de secours ne doivent pas résider uniquement dans le profil qu’ils permettent de récupérer. La recommandation du NIST sur la gestion des clés considère la protection, la disponibilité, la sauvegarde, la compromission et la récupération comme des parties d’un même cycle de vie des clés.

Les clés d’accès synchronisées ajoutent une décision distincte. Les recommandations actuelles du NIST sur les authentificateurs synchronisables imposent des contrôles sur le stockage chiffré des clés, l’accès à l’infrastructure de synchronisation et les authentificateurs compromis. L’étiquette de synchronisation d’un profil ne permet pas de savoir si une clé d’accès donnée est liée à l’appareil, synchronisée par le fournisseur du système ou récupérable.

Questions à poser avant de choisir une conception

1. Où le contenu lisible peut-il apparaître ?

Demandez un inventaire par champ, pas une déclaration générale de confidentialité. Incluez les fichiers temporaires, la mémoire, les diagnostics, les dossiers d’assistance, les fichiers d’export, les sauvegardes et les index de recherche.

2. Qui contrôle chaque clé ?

Identifiez la création des clés, l’inscription des appareils, le partage entre membres, le renouvellement, la révocation, la sauvegarde et la destruction. Si le fournisseur peut réinitialiser un compte et rétablir silencieusement l’accès au contenu chiffré, déterminez quelle clé ou quel mécanisme de récupération le permet.

3. Que se passe-t-il après la perte d’un identifiant ou d’un appareil ?

Parcourez la récupération d’un appareil, de tous les appareils, du dernier propriétaire de l’organisation et d’un second facteur perdu. Décidez si elle privilégie la confidentialité, la disponibilité ou l’approbation partagée. Toute conception de récupération implique des compromis entre ces propriétés.

4. Comment fonctionnent les autorisations de l’équipe ?

Recherchez des comptes individuels, des rôles suivant le moindre privilège, une propriété explicite, un inventaire des appareils, la révocation, une approbation des exports sensibles et des enregistrements d’audit. Un stockage cloud partagé sans autorisation par utilisateur ne constitue pas une collaboration contrôlée.

5. Quelle est la sémantique hors ligne et en cas de conflit ?

Demandez ce qui se passe lorsque deux appareils autorisés modifient le même profil, qu’un appareil détient une ancienne clé ou qu’un téléversement est interrompu. Un profil contenant des bases de données et un état de session ne peut pas appliquer « le dernier téléversement l’emporte » comme règle par défaut inexpliquée.

6. Qu’est-ce qui est conservé après une suppression ?

Distinguez la réplique active, l’historique des versions, la conservation des sauvegardes, la mise sous gel juridique et les journaux du fournisseur. Confirmez la durée, l’autorité de suppression et la possibilité qu’un appareil révoqué téléverse une ancienne copie.

7. L’équipe peut-elle partir en toute sécurité ?

Testez un export documenté vers un environnement propre et pris en charge. Consignez les types de données transférés, les secrets délibérément exclus et la manière dont le fournisseur supprime les copies restantes. Les affirmations de portabilité doivent nommer un format et ses limites.

Synchronisation et sauvegarde résolvent des problèmes différents

La synchronisation maintient certains états alignés entre plusieurs appareils. Une sauvegarde utile préserve un état antérieur récupérable lorsque l’état actif est supprimé, corrompu, chiffré par un rançongiciel ou modifié à tort.

Dans les opérations, traitez la synchronisation comme une réplication, sauf si le produit documente des versions indépendantes et protégées ainsi qu’un chemin de restauration testé. Une mauvaise modification peut se propager rapidement. Les recommandations de la CISA sur les rançongiciels préconisent des sauvegardes hors ligne chiffrées et des tests réguliers de disponibilité et d’intégrité. L’implémentation adaptée dépend du modèle de menace, mais l’exigence d’indépendance est essentielle.

Un modèle pratique de sélection

Un profil uniquement local peut convenir lorsque

• un opérateur autorisé utilise un appareil géré ;
• l’exposition au cloud importe davantage qu’un transfert rapide ;
• l’équipe sait gérer des sauvegardes chiffrées et indépendantes ainsi que la récupération des clés ; et
• la perte de l’appareil dans la fenêtre de récupération définie est acceptable.

Des profils synchronisés peuvent convenir lorsque

• des personnes autorisées ont besoin de transferts contrôlés ou de plusieurs appareils gérés ;
• la révocation, l’audit et le choix des versions sont clairement définis ;
• l’emplacement des données et l’accès du fournisseur respectent les obligations envers les clients ; et
• l’équipe a testé le travail hors ligne, le traitement des conflits et la récupération complète.

Un modèle hybride exprime souvent le besoin réel

Conservez par défaut l’exécution du navigateur et le contenu sensible en local. Ne synchronisez que les catégories de données approuvées, chiffrez les ensembles sensibles sur le client lorsque le modèle de menace l’exige et ne gardez que les métadonnées opérationnelles minimales nécessaires aux autorisations et à l’audit. Maintenez une sauvegarde indépendante au lieu de considérer la copie synchronisée comme l’unique chemin de récupération.

Ce modèle exige toujours des preuves propres au produit. Le mot « hybride » n’indique pas quelles données restent locales, quelles métadonnées sont distantes, qui détient les clés ni si la récupération fonctionne.