Gérer la 2FA d’un compte Stripe partagé

La plupart des connexions Stripe partagées n’ont pas lieu d’exister. Stripe a des membres d’équipe avec des rôles, et des clés d’API restreintes pour tout ce qui est automatisé : la réponse, pour presque toutes les personnes qui utilisent aujourd’hui un mot de passe partagé, est une invitation avec un rôle et leur propre second facteur.

Ce qui reste ensuite est en général un seul identifiant : le propriétaire du compte. Celui-là est vraiment unique, il contrôle les coordonnées bancaires, et c’est celui dont la 2FA mérite une garde réfléchie plutôt qu’un téléphone dans la poche de quelqu’un.

Pourquoi les équipes partagent quand même un identifiant Stripe

Pas par négligence. Quatre situations familières :

• La finance le détient et le support en a besoin. Quelqu’un doit retrouver un paiement à 23 h et la personne qui a l’identifiant dort.
• Le comptable en a besoin une fois par mois. Mettre en place un accès semble disproportionné pour douze visites par an.
• Une agence détient les identifiants du client. Ils ont été envoyés par e-mail au démarrage et personne ne veut rouvrir la conversation.
• Personne ne veut toucher au compte propriétaire. Il marche, il est lié à l’adresse d’un fondateur, et le modifier semble risqué.

Les trois premiers ont des réponses nettes dans Stripe lui-même. Le quatrième est le vrai sujet.

D’abord : servez-vous des membres d’équipe et des rôles

Inviter des gens est l’étape qui supprime le problème au lieu de le gérer. Chaque membre d’équipe se connecte avec sa propre adresse e-mail, configure son propre second facteur, et apparaît sous son propre nom dans l’activité du compte. Les rôles de Stripe permettent d’ajuster l’accès au travail : administration complète pour ceux qui en ont besoin, rôles plus étroits pour le support et l’analyse.

Trois cas reviennent tout le temps :

Support et opérations. Un rôle qui permet de rechercher des paiements et d’émettre des remboursements si c’est leur métier, et rien qui approche des coordonnées bancaires. C’est ce qui supprime le message de 23 h à celui qui tient le téléphone.

Le comptable. Un rôle orienté lecture vaut mieux que de remettre l’identifiant, et ça fait de la fin de la mission un simple retrait plutôt qu’un changement de mot de passe.

Les agences qui travaillent dans le compte d’un client. Demandez au client de vous inviter comme membre d’équipe plutôt que de vous envoyer des identifiants. C’est meilleur pour lui, puisqu’il voit ce que vous avez fait et peut vous retirer proprement, ce qui rend la conversation facile, et ça vous débarrasse complètement de son problème de 2FA.

Si l’authentification unique est disponible sur votre compte, elle règle tout ça d’un coup et mérite qu’on se renseigne.

Pour tout ce qui est automatisé : des clés d’API restreintes

Les scripts, les traitements de rapprochement et les outils internes ne devraient pas se connecter au tableau de bord du tout. Les clés d’API restreintes existent pour ça, et elles sont tout ce qu’un secret TOTP n’est pas : limitées à des permissions précises, révocables individuellement, et renouvelables sans toucher à l’accès de quiconque.

La règle : si un humain tape un code à six chiffres pour qu’une machine fasse son travail, l’intégration est mal construite.

Ce qui reste vraiment : le compte propriétaire

Certaines choses tiennent au propriétaire du compte et ne se délèguent pas : changer le compte bancaire, transférer la propriété, récupérer l’identifiant lui-même. Cet identifiant est réel, il est unique, et plusieurs personnes ont en général besoin de pouvoir l’atteindre, parce qu’une entreprise où exactement un être humain peut changer la destination des versements a un autre problème.

C’est donc là que la 2FA partagée est légitime, et là qu’elle doit être tenue serrée :

• Une garde unique du secret, saisi une fois, connue d’au moins deux administrateurs.
• Un accès aux codes par personne, pour le petit nombre de gens qui en ont vraiment besoin.
• Un journal de qui a lu un code, parce que sur un compte de paiement, « qui s’est connecté mardi » doit avoir une réponse.
• Des codes de récupération rangés hors du compte qu’ils récupèrent, avec l’emplacement du secret noté quelque part.

Le raisonnement général derrière ces quatre points est dans comment partager des codes 2FA en équipe en toute sécurité, et la comparaison des mécanismes dans les meilleures façons de gérer la 2FA d’un compte partagé.

Ce qu’il ne faut pas faire sur un compte de paiement

• Capturer le QR code d’enrôlement pour que chacun l’ajoute. C’est le secret, définitivement, sur des appareils inconnus. Sur un compte Stripe, c’est le pire endroit pour le faire.
• Ranger le secret TOTP dans la même entrée de coffre que le mot de passe. Une seule compromission livre alors les deux facteurs.
• Laisser le SMS comme second facteur. Un compte de paiement vaut bien l’effort d’un échange de carte SIM ; un code produit par une application, non.
• Faire du téléphone d’une seule personne l’unique voie d’accès. C’est un problème de disponibilité sur le compte qui paie vos fournisseurs.

Le départ de quelqu’un sur un compte Stripe

Quand quelqu’un s’en va, dans cet ordre :

1. Retirez son accès de membre d’équipe. Une action, rien d’autre n’est touché.
2. Faites tourner les clés d’API qu’elle a créées, ainsi que toute clé restreinte utilisée par ses outils.
3. Si elle a détenu un jour le secret TOTP du compte propriétaire, réinitialisez la 2FA de ce compte, déconnectez toutes les sessions et changez le mot de passe. Le secret ne quitte pas son téléphone tout seul.
4. Vérifiez les réglages de versement et de compte bancaire, ainsi que l’activité récente, pour repérer ce qui aurait changé autour de son départ.

L’étape 3 est la raison d’être de la garde décrite plus haut : si seuls deux administrateurs ont détenu le secret, la plupart des départs sautent cette étape, et ceux qui ne la sautent pas correspondent à un travail connu et circonscrit.

Où Share Auth se place

Pour le compte propriétaire et tout autre compte Stripe qui n’a vraiment qu’un jeu d’informations de connexion : le secret est saisi une fois et chiffré au repos, les personnes qui ont besoin des codes voient le code courant et son décompte plutôt que le secret, les permissions se règlent par membre, et chaque consultation est écrite dans un journal d’accès. Retirer quelqu’un retire son accès partout d’un coup.

Pour tout le reste de cet article, les membres d’équipe et les clés restreintes de Stripe sont la meilleure réponse, et aucun coffre n’a à s’en mêler.