Partager un travail dans le navigateur sans partager d’identifiants bruts

Les équipes disent souvent devoir « partager une connexion », alors que le besoin réel est plus restreint : relire un brouillon, mettre à jour une boutique autorisée, reproduire un défaut régional ou poursuivre un flux d’assistance. Partir de la tâche offre davantage d’options que partir du mot de passe.

Ce qui constitue un identifiant brut

Les exemples évidents sont les mots de passe, les codes de récupération, les graines de mots de passe à usage unique, les clés privées et les mots de passe de proxy. Le travail dans le navigateur introduit également des identifiants moins visibles :

• les cookies d’authentification et identifiants de session ;
• les jetons d’accès et de renouvellement OAuth ;
• les enregistrements des gestionnaires de mots de passe et les données de remplissage automatique ;
• le matériel de clé privée d’une clé d’accès ou l’accès à l’authentificateur qui le détient ;
• l’état d’un appareil de confiance et de récupération ; et
• une archive de profil contenant l’un des éléments précédents.

Les recommandations du NIST sur les sessions décrivent une session de navigateur comme une continuité fondée sur la possession d’un secret de session. L’OWASP Session Management Cheat Sheet explicite la conséquence opérationnelle : tant qu’il est valide, un jeton de session peut être équivalent à l’authentification la plus forte qui l’a créé.

Un ensemble de profil chiffré n’expose pas ces valeurs à un fournisseur de stockage ou à un observateur occasionnel. Une fois que l’appareil d’un destinataire autorisé a déchiffré et lancé le profil, le navigateur peut néanmoins exercer l’autorité de la session. Le transfert a transmis une autorité même si le destinataire ne lit jamais un cookie.

Séparer la tâche de l’autorité

Avant de choisir un mécanisme de partage, rédigez une courte déclaration d’accès :

L’opérateur nominatif A peut effectuer les actions B sur la ressource C, depuis l’appareil approuvé D, jusqu’à l’heure E, selon la règle d’approbation et d’audit F.

Cette phrase révèle les autorisations inutiles. Si la tâche consiste à « approuver ce brouillon », une session d’administration complète est excessive. Si le service cible propose déjà un rôle de relecteur, le partage de l’état du navigateur ajoute du risque sans ajouter de capacité.

La Zero Trust Architecture du NIST recommande d’accorder l’accès à chaque ressource par session avec les privilèges minimaux nécessaires à la tâche. Ce principe s’applique sans adopter un produit étiqueté « zero trust ». Il constitue un bon test de conception pour tout transfert dans le navigateur.

Préférer ces modèles dans l’ordre

1. Accès nominatif au service cible

Utilisez les fonctions d’équipe, d’organisation, de rôle, de délégation ou d’approbation du propriétaire du site ou de l’application lorsqu’elles existent. Chaque personne s’authentifie avec son compte individuel et son authentificateur. Le service cible peut ainsi appliquer ses propres autorisations, attribuer les actions à l’opérateur, utiliser ses contrôles de risque et révoquer une personne sans modifier l’identifiant de tous.

Il s’agit généralement du modèle le plus solide, car l’autorisation réside là où l’action est comprise. Un gestionnaire de navigateur ne peut pas transformer de manière fiable la session d’administration partagée d’un site en rôle de relecteur au niveau de ce site.

Les comptes partagés et de groupe réduisent la responsabilité. La NIST SP 800-53 Rev. 5 conseille aux organisations d’en limiter l’usage et de définir des conditions explicites avant de les autoriser.

2. Délégation délimitée par le service cible

Lorsqu’un service propose OAuth ou un autre protocole de délégation, n’accordez au client ou à l’acteur que les ressources, actions et durées nécessaires. La RFC 9700 recommande de réduire les privilèges des jetons d’accès au minimum requis et de limiter leur audience au serveur de ressources prévu.

Préférez des autorisations de courte durée, révocables et limitées à une audience. Les jetons liés à l’émetteur peuvent réduire le rejeu en cas de fuite, mais ne servent plus si un attaquant obtient à la fois le jeton et le matériel de clé auquel il est lié. L’appareil et le logiciel clients restent dans la limite de menace.

La délégation est particulièrement utile pour l’automatisation : un script peut recevoir l’autorisation d’effectuer une opération définie sans obtenir le mot de passe d’une personne ni une session générale du navigateur. L’événement d’audit doit identifier l’initiateur humain, l’acteur délégué, la ressource, le périmètre et le résultat.

3. Usage d’un secret stocké par l’intermédiaire d’un courtier

Certains services anciens ne proposent qu’un identifiant partagé. Un courtier d’identifiants contrôlé ou un gestionnaire de mots de passe peut limiter les copies en permettant à un flux approuvé du navigateur d’utiliser un secret sans l’afficher dans une messagerie, un ticket, un document ou une sortie normale de l’application.

Cela améliore la conservation, le renouvellement et la révision des accès, mais ne répare pas le modèle de compte du service cible. Après la connexion, chaque opérateur peut encore agir sous la même identité du site. La session obtenue reste sensible et exige ses propres contrôles de délai d’expiration, de révocation et d’appareil.

L’OWASP Secrets Management Cheat Sheet recommande des accès fins, une interaction humaine minimale avec la valeur des secrets, des contrôles du cycle de vie et un audit des personnes qui demandent et utilisent un secret. Dans la mesure du possible, un produit de navigation doit s’intégrer au moyen d’une référence opaque plutôt que devenir un autre coffre généraliste de secrets.

4. Transfert protégé d’une session de navigateur

N’utilisez un profil authentifié partagé que si le service cible ne permet pas une délégation adéquate et si le flux autorisé exige réellement la continuité de la session. Il s’agit du transfert normal le plus risqué, car le destinataire reçoit la capacité d’agir au moyen du compte actif.

Les contrôles minimaux incluent :

• un propriétaire et un destinataire approuvé explicites ;
• une tâche, une ressource et une date d’expiration déclarées ;
• un seul processus d’écriture actif ou un modèle de conflits testé ;
• le chiffrement côté client avant tout téléversement dans le cloud ;
• l’autorisation de l’appareil destinataire et sa protection locale ;
• un verrou empêchant un travail simultané ambigu ;
• des événements d’audit pour l’octroi, le téléchargement, l’ouverture, l’action sensible, la fermeture, la révocation et la récupération ;
• des interfaces normales renvoyant un état expurgé plutôt que des cookies ou jetons ; et
• un plan de révocation de la session auprès du service cible.

Ce modèle peut protéger la valeur de l’identifiant contre la copie occasionnelle et le stockage cloud. Il ne peut pas permettre au service cible de distinguer deux personnes utilisant le même compte authentifié. Il ne peut pas non plus protéger la session d’un logiciel malveillant, d’une extension malveillante ou d’un destinataire autorisé qui abuse de l’autorité reçue.

5. Transfert d’un identifiant brut

Copier un mot de passe, un cookie, un code de récupération, une clé d’accès ou une archive de profil dans un message, une feuille de calcul, un ticket, un script ou un export non protégé crée un secret durable, aux copies mal connues et à la révocation difficile. Évitez cette méthode.

Si un processus ancien exceptionnel exige un transfert, appliquez la procédure d’identifiants approuvée par l’organisation, réduisez les destinataires et la durée au minimum, puis renouvelez ou révoquez l’identifiant. Ne considérez pas le chiffrement du message comme un substitut à la responsabilité individuelle ou au recensement de chaque copie.

Comparer l’autorité, pas seulement la commodité

Modèle	Le service cible identifie l’opérateur	Le périmètre peut correspondre à la tâche	Limite de révocation	Principal risque restant
Membre nominatif du service cible	Généralement oui	Généralement le plus précis	Retirer un membre ou un rôle	Autorisations excessives dans le service cible
Jeton délégué et délimité	L’acteur et le client peuvent être représentés	Précis lorsque les périmètres et l’audience sont étroits	Révoquer l’autorisation ou le jeton	Compromission du jeton, du client ou de la clé
Connexion partagée par courtier	Souvent non après la connexion	Limitée par le compte partagé	Renouveler le secret et fermer les sessions	Identité partagée sur le site et sessions actives
Session de navigateur chiffrée	Généralement non dans le service cible	Au niveau du profil, souvent large	Révoquer le partage et la session cible	L’appareil destinataire peut exercer toute l’autorité de la session
Copie d’un identifiant brut	Aucune identité individuelle fiable	Généralement large	Trouver les copies, renouveler et fermer les sessions	Copies inconnues et faible responsabilité

Ce tableau explique pourquoi « personne ne peut voir le mot de passe » est un critère de réussite incomplet. Le résultat important est l’étendue de l’autorité que le destinataire peut exercer, sa durée et le système capable de la révoquer.

Les clés d’accès améliorent l’authentification, avec une réserve sur le partage

WebAuthn crée un identifiant à clé publique limité à un tiers de confiance. La spécification WebAuthn Level 3 indique que l’authentificateur détient la clé privée et que le script du site reçoit des résultats signés, non l’identifiant privé lui-même. Lorsque le déploiement est correct, cela permet une authentification résistante à l’hameçonnage.

Les clés d’accès ne créent pas automatiquement des rôles d’équipe. Un service cible peut enregistrer un identifiant distinct pour chaque membre nominatif, ce qui préserve l’accès individuel. Un fournisseur de clés d’accès peut également permettre la synchronisation ou le partage des clés d’authentification. La NIST SP 800-63B-4 reconnaît ce modèle tout en identifiant des risques : usage non autorisé des clés, prolifération entre appareils, compromission de l’infrastructure de synchronisation et révocation difficile.

Pour une équipe autorisée, préférez un compte de service nominatif et un authentificateur par personne. Si une clé d’accès partagée est le seul modèle pris en charge, traitez-la comme un authentificateur partagé, documentez qui peut la recevoir et sur quels appareils gérés, et vérifiez comment le fournisseur affiche, révoque et récupère les clés partagées. Le service cible peut toujours enregistrer toutes les actions sous un seul compte.

Définir le transfert dans le navigateur comme un contrat

Un transfert contrôlé doit répondre aux questions suivantes avant le déplacement de l’état du profil :

1. Qui agit ? Utilisez une identité nominative de l’organisation, jamais un libellé d’opérateur générique.
2. Qui a autorisé l’action ? Consignez le propriétaire ou la décision de politique sans stocker de secrets d’approbation.
3. Qu’est-ce qui est partagé ? Nommez le profil et la tâche. Évitez l’inventaire brut de ses cookies ou identifiants.
4. Que peut faire le destinataire ? Séparez les autorisations de lancement, de modification, d’export, d’automatisation, de partage et d’administration.
5. Où l’exécution est-elle permise ? Limitez l’accès aux appareils inscrits et de confiance adaptés aux données.
6. Combien de temps dure-t-il ? Fixez une expiration et fermez les sessions inactives.
7. Deux processus d’écriture peuvent-ils agir ? N’en autorisez qu’un, sauf si le comportement des conflits a été délibérément conçu et testé.
8. Qu’est-ce qui est consigné ? Enregistrez l’acteur, l’appareil, la référence du profil, l’action, le résultat et l’heure. Excluez par défaut les secrets et le contenu des pages.
9. Comment le révoquer ? Couvrez à la fois l’autorisation de partage du navigateur et la session du service cible.
10. Comment le récupérer ? Préservez une dernière version connue comme valide sans restaurer accidentellement des autorisations révoquées.

Le chiffrement s’inscrit dans ce contrat. Il protège les données pendant leur stockage ou leur transfert. L’autorisation décide qui peut accéder au chemin de déchiffrement. La confiance accordée à l’appareil et l’isolation locale protègent l’utilisation. L’audit contribue à la responsabilité et à l’enquête. Aucun de ces contrôles ne remplace les autres.

Maintenir l’automatisation hors de la limite des secrets

Les API, SDK, outils en ligne de commande et agents doivent souvent lancer un profil ou effectuer une action approuvée du cycle de vie. Ils ont rarement besoin des valeurs des cookies, mots de passe, clés d’accès, identifiants de proxy ou d’une archive brute de profil.

Une interface étroite peut accepter une référence opaque de profil ou de secret et renvoyer :

• si l’action a été autorisée ;
• un état expurgé tel que prêt, verrouillé, expiré ou révoqué ;
• une référence de processus ou de session à durée limitée ;
• une erreur structurée et une étape de récupération ; et
• une référence d’événement d’audit.

Elle ne doit pas renvoyer un identifiant simplement parce que l’appelant peut lancer le profil. Un export, un partage groupé ou une autre opération porteuse de secrets exige une politique distincte et, le cas échéant, une approbation explicite.

Le contenu des sites web et les entrées d’automatisation restent également non fiables. L’instruction d’une page ne doit pas pouvoir convaincre un agent de révéler du matériel de session par des journaux, des sorties d’outils, des captures d’écran ou un canal d’assistance.

La révocation comporte deux couches

Retirer un collaborateur d’un espace de travail du navigateur bloque son futur accès autorisé par cet espace. Cela ne prouve pas que la session du service cible est invalide. Un appareil peut déjà détenir un état déchiffré, et une session copiée ou toujours active peut continuer.

Lorsque l’accès prend fin normalement :

1. révoquez l’autorisation d’équipe et fermez le bail du profil ;
2. supprimez le matériel local chiffré conformément à la politique de conservation ;
3. fermez la session concernée auprès du service cible lorsque cela est possible ;
4. retirez l’adhésion de la personne au service cible ou son autorisation déléguée ; et
5. conservez les preuves d’audit expurgées pendant la période approuvée.

En cas de suspicion de compromission, placez aussi les versions du profil affectées en quarantaine, révoquez les sessions et jetons actifs, retirez les authentificateurs non autorisés, renouvelez les secrets partagés exposés et examinez les événements d’audit. Restaurer un ancien instantané peut restaurer un ancien secret de session : la récupération doit donc respecter l’état de révocation.

Limites subsistant après un transfert prudent

• Le chiffrement côté client protège les données stockées et transmises, mais une extrémité autorisée doit déchiffrer ce dont le navigateur a besoin.
• Un verrou de navigateur contrôle l’accès simultané au niveau du produit, pas toutes les actions du service cible.
• Une session partagée présente généralement une seule identité de compte au service cible, même si le produit de navigation dispose d’un audit plus riche.
• Un appareil ou une extension compromis peut agir par une session valide sans extraire un mot de passe lisible.
• Révoquer une autorisation d’espace de travail et révoquer une session de site sont deux opérations distinctes.
• Les conditions du service cible, le contrat du client et le droit applicable déterminent toujours si un flux peut être délégué.
• Certains services n’offrent aucune solution sûre à la place d’un accès individuel. Dans ce cas, réduire le périmètre ou refuser le transfert peut être la décision responsable.

La RFC 6265 décrit les cookies comme une autorité ambiante : un navigateur peut les joindre à une requête même lorsque la partie à l’origine de cette requête ne connaît jamais leur valeur. C’est la limite centrale du partage de session. Dissimuler les identifiants réduit leur divulgation ; cela ne réduit pas l’autorité que le navigateur peut exercer.