
De 2FA van klantaccounts beheren als bureau
Accounts die van de klant zijn en teams die wisselen. Netjes om toegang vragen, klanten scheiden, en aan het eind alles teruggeven.
Vraag elke klant je op eigen naam toe te voegen, in plaats van je zijn inlog te sturen. Bijna alle platforms waarop een bureau werkt hebben een manier om een externe organisatie toegang te geven: partnertoegang, een uitnodiging als lid, een rol over accounts heen, een eigen gebruiker in hun CMS. Waar dat bestaat is er geen gedeeld wachtwoord en geen gedeelde tweede factor te beheren.
Wat daarna overblijft is een korte lijst per klant: de accounts zonder delegatie, die waarvan het pakket ze voor bedrijven reserveert, die welke zijn ingesteld door iemand die weg is. Die vragen om een bewaring die je tijdens de opdracht kunt nakijken en aan het eind netjes kunt ontbinden.
De beperking die bureau-2FA anders maakt
Een intern team bezit zijn accounts. Zit de tweede factor op de verkeerde plek, dan kan het die verplaatsen: de 2FA resetten, een tweede beheerder toevoegen, het account aan een gedeelde mailbox hangen. Vervelend, maar mogelijk.
Een bureau heeft geen van die hefbomen. De accounts zijn van de klant, ze zijn twee jaar geleden ingesteld door iemand van zijn financiële afdeling, en jouw invloed op die inrichting beperkt zich tot een beleefd verzoek bij de start. Je kunt het account niet corrigeren. Je kunt alleen jouw kant corrigeren.
Het tweede verschil is rekenkundig. Een intern team heeft misschien vijftien gedeelde accounts in totaal. Een bureau heeft er een aantal per klant. Bij drie klanten houd je alles in je hoofd. Bij veertig is informele praktijk geen stijlkeuze meer, maar wat zal bezwijken, en het zal bezwijken op andermans eigendom.
De algemene redenering over het bewaren van gedeelde accounts staat in de 2FA van een gedeeld account: hoe pakt een team dat aan?. Het bedrijfsmodel van een bureau komt daarbovenop.
Wat je in plaats van een wachtwoord moet vragen
De vormen van nette toegang
De namen verschillen per platform, de vorm niet. Iemand van buiten de organisatie van de klant krijgt een omschreven toegangsniveau op een omschreven bron, met een eigen inlog en een eigen tweede factor.
| Wat men je meestal aanbiedt | Wat je in plaats daarvan moet vragen |
|---|---|
| De inlog van hun advertentieaccount | Partnertoegang, verleend vanuit je eigen zakelijke portfolio |
| Het wachtwoord van een betaal- of facturatiedashboard | Een uitnodiging als teamlid met een rol op maat van het werk |
| De root- of consolegegevens van hun cloudaccount | Een rol die jouw organisatie aanneemt, aan hun kant intrekbaar |
| Het adminwachtwoord van het CMS of de webshop | Een eigen benoemde gebruiker, met een redacteurs- of medewerkersrol |
| De inlog van het analysetool | Een eigen gebruiker op hun property, op het benodigde toegangsniveau |
De klant wint er meer bij dan jij, en dat maakt het gesprek makkelijk. Hij ziet welke wijzigingen de jouwe zijn, hij kan je verwijderen zonder iets te resetten voor zijn eigen medewerkers, en geen van zijn wachtwoorden belandt in een mailwisseling. Zeg dat erbij wanneer je het vraagt.
De versies per tool staan elders: een gedeeld Stripe-account, een gedeeld AWS-account, en gedeelde socialemedia-accounts, waar het partnertoegangsmodel het verst is doorgevoerd.
Hoe je het gesprek voert
Vraag het bij de start, schriftelijk, account voor account. Een opdracht die begint met een gemaild wachtwoord komt nooit meer op de vraag terug.
Twee dingen laten het verzoek slagen. Richt je tot de persoon die het account echt beheert, niet tot de marketingmanager die je verzoek doorstuurt naar iemand met vakantie. En stuur de stappen in plaats van het verzoek: een korte genummerde lijst van waar te klikken, per platform, haalt de moeite weg die het echte bezwaar is. „Om veiligheidsredenen” leest als jouw probleem; „zodat jullie zien wat wij hebben gewijzigd en ons met één klik kunnen afsluiten” leest als het zijne.
Reken op een dag of veertien en twee herinneringen bij sommige accounts. Laat het werk daar niet achter stilvallen.
Wanneer de klant het wachtwoord toch stuurt
Sommigen doen het. Een eenmanszaak waar de directeur de enige beheerder is, een klant wiens IT-leverancier niet reageert, een platform dat echt geen delegatie kent. De inlog weigeren is geen echte optie: beperk liever de blootstelling.
- Haal hem meteen na ontvangst uit de mailbox. De kopie in jouw inbox en die in zijn verzonden berichten staan er nog, en je beheerst er maar één.
- Vraag hem het wachtwoord te wijzigen zodra je het hebt, of wijzig het zelf als je daartoe bevoegd bent. Dat doodt de gemailde kopie, het enige wat je er echt aan kunt doen.
- Aanvaard nooit de 2FA-inschrijfcode. Niet de schermafbeelding van de QR-code, niet de tekenreeks eronder, via geen enkel kanaal. Biedt hij hem aan, weiger dan en leg uit waarom: het is de blijvende sleutel en geen wachtwoord, zijn kopieën kunnen niet geteld en niet teruggenomen worden, en er één ongedaan maken vereist een reset van de 2FA van het account. De werking staat in hoe TOTP-geheimen werken.
- Zegt hij hem ooit naar een vorige leverancier te hebben gemaild, zeg dan dat hij hem als gecompromitteerd moet beschouwen en moet resetten. Ongemakkelijke boodschap, juist advies.
- Noteer wat je hebt ontvangen, van wie, en wanneer. Die gewoonte maakt het einde van de opdracht mogelijk.
Niets hiervan maakt een gemaild wachtwoord achteraf veilig. Het verkort het venster en laat je een spoor na.
Eén klant, één grens
Bij veertig klanten is scheiding de eigenschap die een klein incident klein houdt.
Eén vermelding per klantaccount. Genoemd naar klant en account, nooit één gezamenlijke hoop „klantinloggegevens”. Die hoop maakt alle volgende regels onuitvoerbaar.
Toegang per persoon, voor de klanten waaraan die persoon werkt. De projectleider van het ene pakket heeft geen enkele reden om bij de domeinregistrar van een andere klant te komen. Dat is geen wantrouwen jegens je medewerkers; het betekent dat een gestolen laptop het probleem van één klant is en een vertrek één gesprek.
Een register dat je echt bijhoudt. Geen document dat je één keer bij de start schrijft:
| Veld | Waarom het er staat |
|---|---|
| Klant en account | Zodat de overdrachtslijst zichzelf schrijft |
| Soort toegang | Gedelegeerde gebruiker, partnerkoppeling, of gedeelde inlog |
| Wie in het bureau hem heeft | De vertreklijst, persoon voor persoon |
| Verleend op | Om permanente toegang ter discussie te kunnen stellen |
| Wie hem aan klantzijde beheert | Om te weten wie je vraagt als iets breekt |
Een controle op een vast moment, gekoppeld aan de pakketreview of de facturatie. Toegang die nooit wordt herzien stapelt zich alleen maar op.
De eerlijke prijs: de scheiding blokkeert iemand, meestal degene die op het laatste moment een collega vervangt bij een klant. Het antwoord is een toekenning die dertig seconden kost, niet permanente toegang voor iedereen. Is verlenen traag, dan gaan mensen eromheen, en ze gaan eromheen met een wachtwoord in een bericht.
De komst van een klant
Behandel het verzamelen van toegangen als een op te leveren product, met een verantwoordelijke en een datum, net als de kick-off.
- Maak een lijst van de accounts die het werk echt nodig heeft, niet van alles wat de klant bezit. Uitdijende toegangsomvang is hoe een bureau de inlog van een registrar bewaart die het nooit gebruikt.
- Zoek uit wie elk ervan beheert en welke delegatie het toelaat. De tweede vraag beantwoordt zichzelf meestal op hun eigen instellingenpagina.
- Vraag om gedelegeerde toegang, met de stappen erbij.
- Spreek voor wat overblijft de bewaring uitdrukkelijk af: wie in het bureau de inlog houdt, waar hij woont, en wie de codes ervan mag lezen.
- Leg alles vast, ook de accounts waarom je hebt gevraagd zonder ze te krijgen.
- Spreek nu al de eindsituatie af, zolang de goede wil hoog is: wat je teruggeeft, wat je verwijdert, wat je hem zult vragen te vernieuwen.
Stap 6 kost bij de start vijf minuten en scheelt later een onderhandeling, wanneer een pakket afloopt en niemand zich gul voelt.
Het einde van een opdracht
Over het vertrek van een medewerker wordt gepraat. Het einde van een klantopdracht is wat klanten echt merken, en het verloopt meestal slechter.
- Verwijder wat je zelf beheert. Verlaat de partnerrelatie, geef de aangenomen rol op, verwijder je eigen gebruikers waar je dat mag.
- Stuur de klant de lijst van wat alleen hij kan verwijderen. Benoemde gebruikers, partnerkoppelingen, API-sleutels, app-wachtwoorden, integraties. Hij zal zich niet herinneren wat jullie is gegeven; jouw register wel.
- Verwijder de inloggegevens die je bewaart, en zeg dat.
- Noem elk account waarvoor je een TOTP-geheim hebt bewaard, en vraag om de 2FA te resetten en alle sessies op elk ervan te verbreken. Dit is de stap die iedereen overslaat.
- Zet dat alles in een schriftelijke overdracht, gedateerd, met wat je had, wat je hebt verwijderd, en wat je vraagt te vernieuwen.
Over het bewijs dat je niets meer hebt: je kunt de afwezigheid van een kopie niet bewijzen, en een bureau dat beweert dat wel te kunnen overdrijft. Wat je wel kunt, is de klant in een positie brengen waarin alles wat je nog zou kunnen hebben niets waard is. Een gewijzigd wachtwoord en een gereset tweede factor zijn het enige echte bewijs, en hij moet het leveren: bouw de overdracht dus rond dat verzoek in plaats van rond geruststellende woorden.
Daar wordt informele praktijk zichtbaar. Hebben de inloggegevens op één plek gewoond, met een spoor van wie ze kon lezen, dan is stap 4 een alinea die je eerlijk kunt schrijven. Hebben elf mensen in drie jaar inschrijfcodes gescand, dan kun je hem helemaal niet schrijven, en dat je er een vagere versie van schrijft zou je moeten storen.
Leveranciers en zzp’ers
Rouleren is de normale toestand, niet de uitzondering, en het gaat slecht samen met alles wat permanent is.
Verleen per klant, en noteer de intrekking op de dag van toekenning. Een zzp’er die zes weken bij één klant werkt, hoort zes weken toegang tot één klant te hebben. Die datum is makkelijk te zetten wanneer je toch al op de instellingenpagina bent, en onmogelijk te reconstrueren vier maanden later.
Geef ze codes, nooit geheimen. Een onderaannemer werkt op zijn eigen toestel, met zijn eigen wachtwoordmanager en zijn eigen back-ups. Alles wat hij kan kopiëren houdt hij zodra de factuur betaald is, en geen enkele clausule verandert daar iets aan. Het onderscheid is het onderwerp van TOTP-codes delen zonder het geheim te delen.
Waar het platform van de klant het toelaat, regel je voor de zzp’er een eigen gebruiker aan klantzijde. De klant ziet van wie het werk komt, en intrekken is een handeling aan zijn kant waarbij jij niet betrokken bent.
Laat een zzp’er nooit het inschrijfpunt van de 2FA van een klant zijn. Het gebeurt per ongeluk: hij richt het account in tijdens een lancering, de authenticator-app belandt op zijn telefoon, en twee jaar later kan niemand inloggen en is hij van beroep veranderd. Op sommige platforms heeft dat geen betrouwbare uitweg, alleen een wachtrij bij de helpdesk.
Sluit de toegangen bij het einde van het contract even zeker af als je de factuur verstuurt. Een van beide gebeurt altijd. Hang het andere eraan vast.
Wat in de opdrachtbevestiging hoort
Operationeel, niet juridisch: de contracttekst is een vraag voor een advocaat, en niets hier is juridisch advies. Maar één alinea in het plan van aanpak of de startmail beslecht de ruzies van de negende maand, en die zou moeten dekken:
- voor welke accounts het bureau inloggegevens bewaart, en welke het via gedelegeerde toegang bereikt;
- dat de klant het eigendom houdt en elke toegang op elk moment kan intrekken, zonder aankondiging en zonder uitleg;
- wie in het bureau geautoriseerd is, en dat de toegang per persoon geldt en niet aan het bureau als entiteit;
- dat 2FA-inschrijfcodes en geheimen niet per mail of chat circuleren, in geen enkele richting;
- wat er aan het eind gebeurt: de overdrachtslijst, de intrekkingen die het bureau uitvoert, en de vernieuwingen die het de klant zal vragen;
- wie te contacteren wanneer een inlog het niet meer doet, zodat niemand dat om 19 uur oplost door een wachtwoord in een kanaal te zetten.
Het punt is niet de afdwingbaarheid. Het punt is dat het gesprek één keer plaatsvindt, aan het begin, in een rustige week.
Wat er breekt wanneer dit alles informeel blijft
De storingen zijn herkenbaar, en ze komen allemaal uit dezelfde ontbrekende structuur.
Het doorgeven. De codes komen van de telefoon van een projectleider. Werkbaar bij vier klanten, tot die persoon een week vakantie neemt.
De vertrekker die je niet kunt offboarden. Iemand gaat weg nadat hij zijn authenticator-app op een dozijn klantaccounts heeft ingeschreven. Het goed doen betekent twaalf klanten benaderen met de vraag hun 2FA te resetten, en uitleggen waarom. De meeste bureaus laten dat stilzwijgend, wat betekent dat de volgende overdrachtsnotitie een onjuiste bewering bevat.
Het account dat niemand kan herstellen. Geregistreerd op een privéadres of -nummer, door iemand die niet meer bereikbaar is.
De onbeantwoordbare vraag. Een klant vraagt wie op de 14e zijn advertentieaccount opende. „Een van vier of vijf mensen, denken we” is een slecht antwoord aan een klant over zijn eigen eigendom, en het is meestal het moment waarop een bureau zijn werkwijze verandert.
De straal. Eén gezamenlijke hoop maakt van een gekraakte laptop een incident voor alle klanten tegelijk, en het meldingsgesprek wordt veertig gesprekken.
Waar Share Auth staat
Voor de klantaccounts die na de delegatie overblijven: die met maar één inlog, zonder partnermodel, bij een klant die niets gaat herbouwen.
Het geheim wordt één keer ingevoerd en versleuteld opgeslagen. De mensen die je uitnodigt zien de actuele zescijferige code en het aftellen in plaats van de tekenreeks erachter, waardoor de toegang van een onderaannemer echt intrekbaar wordt. Rechten worden per lid en per account ingesteld, dus de scheiding van klanten wordt uitdrukbaar in plaats van een wens. Elke raadpleging wordt in een toegangslogboek geschreven, dus „wie las op de 14e de code” heeft een antwoord met een naam en een tijdstempel. Een lid verwijderen trekt zijn toegang op alle klantaccounts in één keer in. Eén handeling, zonder resets bij twaalf klanten. Er is een API voor de gevallen waarin een machine, en niet een persoon, de code nodig heeft. Het gratis pakket dekt drie geheimen en drie leden zonder bankkaart, genoeg om één klant door de hele cyclus te halen voor je iets besluit.
Wat het niet doet: het bezorgt je geen gedelegeerde toegang, wat overal waar die bestaat het beste antwoord blijft, het houdt je register en je overdrachtsnotities niet bij, en het kan een al gemailde inschrijfcode niet ongedaan maken. Het is ook geen wachtwoordmanager, en het wachtwoord hoort te blijven in de manager die je al hebt, om de reden die staat in hoe je 2FA-codes veilig met je team deelt. Weeg je de opties nog af, dan worden de mechanismen vergeleken in de beste manieren om de 2FA van een gedeeld account te beheren, en het onderliggende protocol wordt behandeld in de volledige gids over TOTP in teams.
Waar te beginnen
Niet bij veertig klanten tegelijk.
- Neem de klant met de meest verwarde toegangen en bouw zijn registervermelding netjes op. Eén middag, en het vertelt je hoe de andere negenendertig eruitzien.
- Schrijf twee sjablonen: de genummerde stappen van het verzoek bij de start, en de overdrachtsnotitie met haar verzoek om vernieuwing. Dat ze geschreven zijn, is wat ze de deur uit doet gaan.
- Vraag al je huidige klanten om gedelegeerde toegang waar die bestaat, in een tempo van één klant per week.
- Voor de accounts die gedeeld blijven, zet het geheim op één plek met toegang tot de codes per persoon, en reset de 2FA van elk account waarvan de inschrijfcode ooit is verstuurd of gepost.
De eindsituatie heeft niets glansrijks: een klant vraagt wat je bewaart en wie het heeft gebruikt, en je antwoordt dezelfde dag.
Veelgestelde vragen
Vraag om op eigen naam te worden toegevoegd in plaats van een inlog te krijgen. De meeste platforms waarop een bureau werkt staan dat toe: partnertoegang vanuit je eigen zakelijke portfolio, een uitnodiging als lid met een rol, een rol over accounts heen, een eigen gebruiker in hun CMS. De klant houdt het eigendom, je medewerkers gebruiken hun eigen tweede factor, en het activiteitenlogboek van de klant noteert namen in plaats van „het bureau”.
Neem het werk aan en beperk daarna de blootstelling. Haal de inlog uit de mailbox en zet hem in je kluis, vraag de klant het wachtwoord te wijzigen zodra jij het hebt, en aanvaard nooit de 2FA-inschrijfcode of een schermafbeelding van de QR-code, via welk kanaal dan ook. Vraag daarna opnieuw om gedelegeerde toegang bij de eerstvolgende natuurlijke gelegenheid: een platformmigratie, of een nieuwe persoon op het account.
Eén vermelding per klantaccount, nooit één gezamenlijke hoop, en toegang per persoon voor de klanten waaraan die persoon echt werkt. De scheiding kost wat gemak wanneer iemand een collega vervangt, en ze voorkomt dat een gekraakte laptop of een vertrek een gebeurtenis met veertig klanten wordt.
Je kunt de afwezigheid van een kopie niet bewijzen, en je zou het ook niet moeten beweren. Wat je wel kunt: precies opsommen wat je had, bevestigen wat je aan jouw kant hebt verwijderd, en de klant vragen het wachtwoord te wijzigen en de 2FA te resetten op alles wat je had. Die rotatie is het enige echte bewijs, en ze is van hem: bouw je overdracht rond dat verzoek.
Verleen toegang per klant en noteer de intrekdatum op dezelfde dag dat je hem verleent. Geef onderaannemers de codes en niet het geheim, want alles wat ze kunnen kopiëren blijft na afloop van het contract bij hen. Waar het platform van de klant het toelaat, regel je voor de zzp'er een eigen gebruiker aan klantzijde, zodat intrekken één handeling van de klant is.