Donner à ses employés accès à la 2FA sans leur donner le secret

Donnez au personnel l’accès aux codes et gardez le secret avec la personne qui administre le compte. Concrètement, une personne saisit chaque secret une fois, accorde l’accès par personne et par compte, et retire cet accès quand quelqu’un change de poste ou s’en va. Personne n’enrôle sa propre application d’authentification, donc personne n’emporte un accès que vous ne pouvez pas reprendre.

Cet article traite du côté employeur de cet arrangement : qui obtient quoi, et comment le faire tourner. Le raisonnement derrière la séparation est dans comment partager des codes 2FA en équipe en toute sécurité, et la mécanique qui permet de distribuer un code pendant que le secret reste en place est dans partager des codes TOTP sans partager le secret.

Commencez par décider quelle est l’unité d’accès

La plupart des équipes accordent les accès 2FA comme elles distribuent les clés du bureau : quelqu’un demande, quelqu’un d’autre dit oui, et rien n’est écrit. Ça tient jusqu’à la quatrième embauche. Choisissez plutôt une unité, et tenez-vous-y ; trois se défendent.

Par compte. Le choix par défaut. Chaque identifiant partagé est quelque chose pour lequel on est autorisé ou non : les paiements, le cloud, le bureau d’enregistrement, le principal profil social, chaque tableau de bord client.

Par rôle. Au lieu d’accorder à Amira, vous accordez à quiconque fait le travail d’Amira. « Finance » obtient le prestataire de paiement et l’outil de comptabilité. « Social » obtient les deux profils et l’outil de programmation. Quand Amira change d’équipe, la liste dont hérite son remplaçant est déjà définie.

Par mission. Les agences ont besoin d’un troisième axe : le client. L’accès aux comptes d’un client s’arrête quand la mission s’arrête, quelles que soient les personnes encore en poste.

Croiser rôle et compte ne demande aucune cérémonie. Un petit tableau, une ligne par rôle et une colonne par compte partagé, c’est le document que vous utiliserez à l’arrivée d’une personne et lors des revues.

Le moindre privilège, appliqué aux codes

Deux questions décident de chaque attribution. Cette personne se connecte-t-elle à ce compte dans le cadre de son travail ? Et si son portable était volé ce soir, voudriez-vous voir ce compte dans la liste des expositions ?

La première écarte les accès spéculatifs. « C’est plus simple de tout donner à tout le monde » est vrai le jour de la mise en place et faux tous les jours suivants, parce que le coût arrive plus tard, lors d’un incident ou d’un départ. La seconde est un test de bon sens sur l’ancienneté : fondateurs et responsables techniques accumulent tous les comptes par défaut et deviennent la cible la plus intéressante de l’entreprise.

Le moindre privilège ne veut pas dire obliger les gens à demander à chaque fois. Si quelqu’un a besoin d’un compte chaque semaine, accordez-le. Un accès pénible à utiliser se contourne, en général par quelqu’un qui lit les codes dans une conversation.

À quoi ressemblent les dix premières minutes d’un nouvel arrivant

L’enrôlement doit être une tâche, pas un projet. S’il prend un après-midi, il sera mal fait.

Avant son premier jour

Cherchez son rôle dans le tableau et notez les comptes qui vont avec. Si le rôle est nouveau, décidez la liste maintenant, pas pendant son intégration.

Le jour même

L’administrateur accorde ces comptes. Le nouvel arrivant se connecte, voit les comptes pour lesquels il est autorisé, et peut produire un code pour chacun. Il n’y a aucun QR code à scanner et aucun secret à stocker : il n’a donc rien à perdre ni à copier.

Ce qui mérite d’être dit à voix haute

Dites-lui deux choses. D’abord qu’il ne verra jamais le secret derrière un code, et que c’est délibéré. Ensuite que s’il a besoin d’un compte absent de sa liste, la réponse est une demande et non un contournement. Les équipes qui sautent la seconde phrase héritent d’accès parallèles : quelqu’un capture un QR code de configuration pour un collègue, et le nombre de copies devient impossible à connaître. Pourquoi cette copie ne peut jamais être rappelée est traité dans comment fonctionnent les secrets TOTP et pourquoi il ne faut pas les partager.

Arrivées, changements de poste, départs

Le mot que la plupart des équipes oublient, c’est changements de poste. Les arrivées et les départs sont surveillés ; le changement de rôle rarement, et c’est comme ça que les accès s’accumulent.

Arrivée. Accordez la liste du rôle. Rien de plus, même si la personne est expérimentée.

Changement de poste. Accordez les comptes du nouveau rôle et retirez ceux de l’ancien. Le retrait est l’étape qu’on saute, et c’est ainsi qu’un agent de support passé au marketing il y a deux ans a toujours le prestataire de paiement. Accordez par rôle et un changement devient la comparaison de deux listes.

Départ. Retirez la personne de tous les comptes, le jour de son départ, en une action qui ne change rien pour les autres. Si le départ impose au contraire de réinitialiser la 2FA sur neuf comptes et de demander à huit collègues restants de se réenrôler, c’est le signe : votre personnel détient des secrets, pas des accès.

Les prestataires entrent dans le même circuit, avec une date de fin notée au moment où l’accès est accordé. Personne ne pense à révoquer l’accès d’une mission de trois semaines qui s’est terminée sans bruit.

Ce que voit un employé, et ce que voit un administrateur

Être explicite sur cette asymétrie évite beaucoup de soupçons.

Un employé voit les comptes pour lesquels il est autorisé et, pour chacun, le code courant et le temps qu’il lui reste. Il ne peut voir ni le secret, ni les comptes qui ne lui ont pas été accordés, ni le moyen d’accorder l’accès à qui que ce soit.

Un administrateur voit tous les comptes, qui a accès à chacun, et le relevé des codes consultés et de leur horodatage. Les administrateurs sont aussi les personnes qui saisissent les secrets et conservent les codes de récupération du fournisseur.

Le matériel sensible est donc entre les mains d’un petit nombre de personnes nommées, et « qui peut se connecter au compte publicitaire ? » a une vraie réponse plutôt qu’une estimation.

Comment présenter ça sans que ça sonne comme de la surveillance

Le journal d’accès est la partie qui fait réagir, et la réaction est légitime : personne n’aime apprendre après coup que ses lectures sont enregistrées.

Dites-le d’emblée, à l’enrôlement, et expliquez à quoi ça sert en termes opérationnels. Quand un identifiant partagé fait quelque chose que personne ne s’explique, la première question est de savoir qui était connecté, et le journal de la plateforme dit seulement que le compte a servi. Le journal des codes est le seul endroit qui distingue cinq collègues. Il protège aussi ceux qui l’utilisent : un journal qui montre qui a consulté un code montre tout autant qui ne l’a pas fait.

Ce qui n’aide pas, c’est de le présenter comme une mesure de confiance. Décrivez-le comme de la plomberie, parce que c’en est.

« On fait confiance à nos gens »

L’objection mérite une réponse franche, parce que sa prémisse est en général juste : la plupart des équipes ont bien des salariés dignes de confiance. Mais la confiance n’est pas la propriété qu’on gère ici. Deux autres le sont.

Le décompte. Vous devriez pouvoir dire combien d’appareils peuvent actuellement produire un code pour un compte. Si les gens ont enrôlé leurs propres applications, ce nombre est inconnu et le reste ; rien dans la page de sécurité du compte ne le rapporte.

La révocabilité. Vous devriez pouvoir mettre fin à l’accès de quelqu’un sans toucher au compte. Si y mettre fin impose de réinitialiser la 2FA et de réenrôler tous les autres, vous éviterez de le faire, et l’accès persistera.

Ni l’un ni l’autre ne suppose que quiconque se comporte mal. Une équipe parfaitement honnête a quand même des téléphones oubliés dans des taxis, des gens qui partent en bons termes, et des prestataires dont la mission s’est terminée en mars. C’est pour ces événements-là que cette organisation existe.

Une version de l’objection mérite pourtant d’être concédée. Si deux personnes partagent un identifiant, aucun modèle de permissions n’en fait deux identités. Là où le compte gère de vrais accès individuels, ça vaut mieux que n’importe quel arrangement de partage, et c’est la première chose à vérifier en triant vos comptes. Voir la 2FA d’un compte partagé : comment une équipe devrait-elle s’y prendre ?.

Revoyez les accès à date fixe

Une fois par trimestre, lisez la liste de chaque compte partagé et retirez les noms qui ne devraient pas y être. Ajoutez une revue à chaque changement de poste et à chaque fin de mission.

Ça prend quelques minutes si l’accès a été accordé compte par compte. Si votre seule trace est un dossier de coffre partagé qu’une douzaine de personnes peuvent ouvrir, il n’y a rien à revoir : la réponse est toujours « tout le monde ». Les comptes que personne n’a consultés depuis des mois n’ont en général pas besoin d’être partagés du tout.

Les erreurs qui reviennent

Tout à tout le monde par défaut. En général justifié par la crainte des goulots d’étranglement. Ça transforme chaque portable perdu en exposition de toute l’entreprise.

Accorder à la personne plutôt qu’au poste. L’accès suit un nom, le nom change de travail, et personne ne sait quelles attributions étaient liées à l’ancien rôle. Accordez au rôle et le changement devient mécanique.

Aucun administrateur nommé. Si personne n’est responsable du secret d’un compte, personne ne conserve ses codes de récupération et personne ne voit les accès dériver.

Traiter le départ comme un projet de sécurité plutôt que comme une ligne de liste. Ça se range à côté du portable et du badge, avec la même échéance.

Choisir le mécanisme avant d’avoir trié les comptes. Ne comparez les mécanismes que pour les identifiants qui n’ont vraiment qu’un seul jeu d’informations de connexion, comme dans les meilleures façons de gérer la 2FA d’un compte partagé.

Où Share Auth se place

Share Auth est construit autour de cette forme. Vous saisissez le secret de chaque compte une fois, et il est chiffré au repos. Les personnes que vous invitez voient le code courant et son décompte, pas la chaîne dont il vient : il n’y a donc rien qu’elles puissent enrôler ailleurs.

Les permissions sont accordées par membre et par compte, ce qui rend le tableau par rôle ci-dessus exprimable plutôt que théorique. Chaque consultation est écrite dans un journal d’accès. Retirer un membre retire son accès sur tous les comptes d’un coup : un départ est une action, pas une migration. Il y a une API si votre intégration des nouveaux arrivants est déjà scriptée.

Le forfait gratuit couvre trois secrets et trois membres sans carte bancaire, de quoi faire tourner les vrais comptes d’une équipe et voir si le modèle de permissions tient.

Ce que ça ne règle pas

Un identifiant partagé reste une identité partagée. Des codes accordés par personne vous disent qui en a récupéré un ; ils ne font pas distinguer vos collègues par la piste d’audit de la plateforme, et ils ne vous donnent aucune permission par personne à l’intérieur du compte. Là où un fournisseur propose de vrais comptes utilisateurs ou du SSO, ça reste la meilleure réponse, et cette organisation vaut pour les comptes qui n’offrent ni l’un ni l’autre.

Ça ne fait rien non plus au sujet du mot de passe. S’il traîne quelque part où tout le monde peut le lire, garder le secret à part vous a acheté l’indépendance du second facteur et rien d’autre. C’est bon à prendre, mais ce n’est pas tout le contrôle d’accès.