De 2FA van een gedeeld Stripe-account beheren

De meeste gedeelde Stripe-inlogs hebben geen bestaansreden. Stripe heeft teamleden met rollen, en beperkte API-sleutels voor alles wat geautomatiseerd is: het antwoord, voor bijna iedereen die vandaag een gedeeld wachtwoord gebruikt, is een uitnodiging met een rol en een eigen tweede factor.

Wat daarna overblijft is meestal één inlog: de accounteigenaar. Die is werkelijk uniek, hij beheert de bankgegevens, en zijn 2FA verdient een doordachte bewaring in plaats van een telefoon in iemands zak.

Waarom teams toch een Stripe-inlog delen

Niet uit nalatigheid. Vier vertrouwde situaties:

• Finance heeft hem en support heeft hem nodig. Iemand moet om 23 uur een betaling terugvinden en de persoon met de inlog slaapt.
• De boekhouder heeft hem één keer per maand nodig. Toegang opzetten lijkt buitensporig voor twaalf bezoeken per jaar.
• Een bureau heeft de inloggegevens van de klant. Ze zijn bij de start gemaild en niemand wil het gesprek heropenen.
• Niemand wil aan het eigenaarsaccount komen. Het werkt, het hangt aan het adres van een oprichter, en het wijzigen lijkt riskant.

De eerste drie hebben duidelijke antwoorden binnen Stripe zelf. De vierde is het echte onderwerp.

Eerst: gebruik teamleden en rollen

Mensen uitnodigen is de stap die het probleem wegneemt in plaats van het te beheren. Elk teamlid logt in met een eigen e-mailadres, stelt een eigen tweede factor in, en verschijnt onder de eigen naam in de accountactiviteit. De rollen van Stripe maken het mogelijk de toegang op het werk af te stemmen: volledige administratie voor wie die nodig heeft, smallere rollen voor support en analyse.

Drie gevallen komen steeds terug:

Support en operations. Een rol waarmee je betalingen kunt zoeken en terugbetalingen kunt doen als dat hun vak is, en niets wat in de buurt van de bankgegevens komt. Dat is wat het bericht om 23 uur aan wie de telefoon heeft overbodig maakt.

De boekhouder. Een leesgerichte rol is beter dan de inlog afgeven, en maakt van het einde van de opdracht een simpele verwijdering in plaats van een wachtwoordwissel.

Bureaus die in het account van een klant werken. Vraag de klant je als teamlid uit te nodigen in plaats van je inloggegevens te sturen. Het is beter voor hem, want hij ziet wat je hebt gedaan en kan je netjes verwijderen, wat het gesprek makkelijk maakt, en het bevrijdt jou volledig van zijn 2FA-probleem.

Is single sign-on beschikbaar op je account, dan lost dat dit allemaal in één keer op en is het de moeite waard om ernaar te vragen.

Voor alles wat geautomatiseerd is: beperkte API-sleutels

Scripts, afstemmingsprocessen en interne tools zouden helemaal niet op het dashboard moeten inloggen. Beperkte API-sleutels bestaan daarvoor, en ze zijn alles wat een TOTP-geheim niet is: begrensd tot precieze rechten, afzonderlijk intrekbaar, en vernieuwbaar zonder iemands toegang aan te raken.

De regel: typt een mens een zescijferige code zodat een machine haar werk doet, dan is de integratie verkeerd gebouwd.

Wat er echt overblijft: het eigenaarsaccount

Sommige dingen hangen aan de accounteigenaar en laten zich niet delegeren: de bankrekening wijzigen, het eigendom overdragen, de inlog zelf herstellen. Die inlog is echt, hij is uniek, en meestal moeten meerdere mensen hem kunnen bereiken, want een bedrijf waar precies één mens de bestemming van de uitbetalingen kan wijzigen heeft een ander probleem.

Daar is gedeelde 2FA dus legitiem, en daar moet ze strak worden gehouden:

• Eén bewaarplaats voor het geheim, één keer ingevoerd, bekend bij minstens twee beheerders.
• Toegang tot de codes per persoon, voor het kleine aantal mensen dat ze echt nodig heeft.
• Een logboek van wie een code las, want op een betaalaccount moet „wie logde er dinsdag in” een antwoord hebben.
• Herstelcodes buiten het account dat ze herstellen, met de plek van het geheim ergens genoteerd.

De algemene redenering achter die vier punten staat in hoe je 2FA-codes veilig met je team deelt, en de vergelijking van mechanismen in de beste manieren om de 2FA van een gedeeld account te beheren.

Wat je op een betaalaccount niet moet doen

• De QR-code voor inschrijving fotograferen zodat iedereen hem toevoegt. Dat is het geheim, definitief, op onbekende toestellen. Op een Stripe-account is dat de slechtste plek om het te doen.
• Het TOTP-geheim in dezelfde kluisvermelding zetten als het wachtwoord. Eén inbreuk levert dan beide factoren op.
• Sms als tweede factor laten staan. Een betaalaccount is de moeite van een simswap waard; een code uit een app niet.
• Van de telefoon van één persoon de enige toegangsweg maken. Dat is een beschikbaarheidsprobleem op het account dat je leveranciers betaalt.

Wanneer iemand een Stripe-account verlaat

Wanneer iemand vertrekt, in deze volgorde:

1. Verwijder haar toegang als teamlid. Eén handeling, verder wordt niets aangeraakt.
2. Roteer de API-sleutels die zij aanmaakte, en elke beperkte sleutel die haar tools gebruikten.
3. Had zij ooit het TOTP-geheim van het eigenaarsaccount, reset dan de 2FA van dat account, verbreek alle sessies en wijzig het wachtwoord. Het geheim verlaat haar telefoon niet uit zichzelf.
4. Controleer de uitbetalings- en bankrekeninginstellingen, en de recente activiteit, om te zien wat er rond haar vertrek gewijzigd zou zijn.

Stap 3 is de bestaansreden van de bewaring hierboven: hebben maar twee beheerders het geheim gehad, dan slaan de meeste vertrekken die stap over, en de vertrekken die hem niet overslaan komen overeen met bekend en afgebakend werk.

Waar Share Auth staat

Voor het eigenaarsaccount en elk ander Stripe-account dat echt maar één set aanmeldgegevens heeft: het geheim wordt één keer ingevoerd en versleuteld opgeslagen, de mensen die de codes nodig hebben zien de actuele code en het aftellen in plaats van het geheim, de rechten worden per lid ingesteld, en elke raadpleging wordt in een toegangslogboek geschreven. Iemand verwijderen trekt zijn toegang overal in één keer in.

Voor al het overige in dit artikel zijn de teamleden en de beperkte sleutels van Stripe het betere antwoord, en hoeft geen enkele kluis zich ermee te bemoeien.