Medewerkers toegang tot 2FA geven zonder hun het geheim te geven

Geef je personeel toegang tot de codes en houd het geheim bij de persoon die het account beheert. Concreet: één persoon voert elk geheim één keer in, verleent toegang per persoon en per account, en trekt die toegang in wanneer iemand van functie wisselt of vertrekt. Niemand schrijft een eigen authenticator-app in, dus niemand neemt toegang mee die je niet kunt terugnemen.

Dit artikel gaat over de werkgeverskant van die opzet: wie krijgt wat, en hoe laat je het draaien. De redenering achter de scheiding staat in hoe je 2FA-codes veilig met je team deelt, en de werking waardoor je een code kunt uitdelen terwijl het geheim blijft staan, in TOTP-codes delen zonder het geheim te delen.

Begin met bepalen wat de eenheid van toegang is

De meeste teams verlenen 2FA-toegang zoals ze kantoorsleutels uitdelen: iemand vraagt, iemand anders zegt ja, en er wordt niets opgeschreven. Dat houdt stand tot de vierde aanwerving. Kies liever een eenheid en houd je eraan; drie zijn te verdedigen.

Per account. De standaardkeuze. Elke gedeelde inlog is iets waarvoor je geautoriseerd bent of niet: de betalingen, de cloud, de domeinregistrar, het belangrijkste sociale profiel, elk klantdashboard.

Per rol. In plaats van aan Amira te verlenen, verleen je aan wie het werk van Amira doet. „Financiën” krijgt de betaaldienstverlener en het boekhoudpakket. „Social” krijgt de twee profielen en het planningstool. Wisselt Amira van team, dan ligt de lijst die haar opvolger erft al vast.

Per opdracht. Bureaus hebben een derde as nodig: de klant. Toegang tot de accounts van een klant stopt wanneer de opdracht stopt, wie er ook nog in dienst is.

Rol en account kruisen vraagt geen enkele ceremonie. Een kleine tabel, één rij per rol en één kolom per gedeeld account, is het document dat je gebruikt bij de komst van een persoon en bij de controles.

Het minste privilege, toegepast op codes

Twee vragen beslissen over elke toekenning. Logt deze persoon in het kader van haar werk in op dit account? En als haar laptop vanavond gestolen werd, zou je dit account dan op de blootstellingslijst willen zien?

De eerste schrapt speculatieve toegang. „Het is makkelijker om iedereen alles te geven” klopt op de dag van de installatie en op geen enkele dag daarna, want de kosten komen later, bij een incident of een vertrek. De tweede is een gezondverstandtoets op anciënniteit: oprichters en technisch leidinggevenden verzamelen standaard alle accounts en worden het interessantste doelwit van het bedrijf.

Minste privilege betekent niet dat mensen elke keer moeten vragen. Heeft iemand wekelijks een account nodig, verleen het dan. Toegang die lastig te gebruiken is, wordt omzeild, meestal door iemand die de codes in een gesprek voorleest.

Hoe de eerste tien minuten van een nieuwkomer eruitzien

Het aanzetten moet een taak zijn, geen project. Kost het een middag, dan gebeurt het slecht.

Voor haar eerste dag

Zoek haar rol in de tabel op en noteer de bijbehorende accounts. Is de rol nieuw, beslis de lijst dan nu, niet tijdens haar inwerkperiode.

Op de dag zelf

De beheerder verleent die accounts. De nieuwkomer logt in, ziet de accounts waarvoor ze geautoriseerd is, en kan voor elk een code maken. Er is geen QR-code te scannen en geen geheim op te slaan: ze heeft dus niets te verliezen en niets te kopiëren.

Wat hardop gezegd moet worden

Zeg haar twee dingen. Ten eerste dat ze het geheim achter een code nooit zal zien, en dat dat bewust is. Ten tweede dat als ze een account nodig heeft dat niet op haar lijst staat, het antwoord een verzoek is en geen omweg. Teams die de tweede zin overslaan erven parallelle toegang: iemand maakt een schermafbeelding van een installatie-QR-code voor een collega, en het aantal kopieën wordt onkenbaar. Waarom die kopie nooit teruggehaald kan worden, staat in hoe TOTP-geheimen werken en waarom je ze niet moet delen.

Instroom, functiewissels, vertrek

Het woord dat de meeste teams vergeten is functiewissel. Instroom en vertrek worden bewaakt; de rolwissel zelden, en zo stapelt toegang zich op.

Instroom. Verleen de lijst van de rol. Niets meer, ook als de persoon ervaren is.

Functiewissel. Verleen de accounts van de nieuwe rol en trek die van de oude in. Het intrekken is de stap die wordt overgeslagen, en zo heeft een supportmedewerker die twee jaar geleden naar marketing ging nog steeds de betaaldienstverlener. Verleen per rol en een wissel wordt het vergelijken van twee lijsten.

Vertrek. Haal de persoon van alle accounts, op de dag van vertrek, in één handeling die voor de anderen niets verandert. Dwingt het vertrek juist tot een 2FA-reset op negen accounts en tot acht overblijvende collega’s die zich opnieuw moeten inschrijven, dan is dat het teken: je personeel heeft geheimen, geen toegang.

Leveranciers gaan door hetzelfde circuit, met een einddatum die wordt genoteerd op het moment dat de toegang wordt verleend. Niemand denkt eraan de toegang van een opdracht van drie weken in te trekken die geruisloos afliep.

Wat een medewerker ziet, en wat een beheerder ziet

Uitgesproken zijn over die asymmetrie voorkomt veel argwaan.

Een medewerker ziet de accounts waarvoor hij geautoriseerd is, en voor elk de actuele code en de resterende tijd. Hij kan het geheim niet zien, de accounts die hem niet zijn verleend niet, en geen manier om wie dan ook toegang te geven.

Een beheerder ziet alle accounts, wie tot elk toegang heeft, en het overzicht van geraadpleegde codes met hun tijdstempel. Beheerders zijn ook de mensen die de geheimen invoeren en de herstelcodes van de aanbieder bewaren.

Het gevoelige materiaal ligt zo in handen van een klein aantal met naam genoemde mensen, en „wie kan inloggen op het advertentieaccount?” heeft een echt antwoord in plaats van een schatting.

Hoe je dit brengt zonder dat het naar toezicht klinkt

Het toegangslogboek is het deel dat reactie oproept, en die reactie is terecht: niemand hoort graag achteraf dat zijn raadplegingen worden vastgelegd.

Zeg het meteen, bij het aanzetten, en leg in operationele termen uit waar het voor dient. Wanneer een gedeelde inlog iets doet dat niemand kan verklaren, is de eerste vraag wie was ingelogd, en het logboek van het platform zegt alleen dat het account is gebruikt. Het codelogboek is de enige plek die vijf collega’s onderscheidt. Het beschermt ook wie het gebruikt: een logboek dat toont wie een code opvroeg, toont evengoed wie dat niet deed.

Wat niet helpt, is het brengen als een vertrouwensmaatregel. Beschrijf het als leidingwerk, want dat is het.

„Wij vertrouwen onze mensen”

Het bezwaar verdient een eerlijk antwoord, want de premisse klopt meestal: de meeste teams hebben inderdaad betrouwbare medewerkers. Maar vertrouwen is niet de eigenschap die hier wordt beheerd. Twee andere wel.

De telling. Je zou moeten kunnen zeggen hoeveel toestellen op dit moment een code voor een account kunnen maken. Hebben mensen hun eigen apps ingeschreven, dan is dat getal onbekend en blijft het dat; niets op de beveiligingspagina van het account meldt het.

De intrekbaarheid. Je zou iemands toegang moeten kunnen beëindigen zonder het account aan te raken. Vereist beëindigen een 2FA-reset en het opnieuw inschrijven van alle anderen, dan zul je het vermijden, en de toegang blijft bestaan.

Geen van beide veronderstelt dat iemand zich misdraagt. Een volstrekt eerlijk team heeft toch telefoons die in taxi’s blijven liggen, mensen die in goede verstandhouding vertrekken, en leveranciers wier opdracht in maart afliep. Voor die gebeurtenissen bestaat deze opzet.

Eén versie van het bezwaar verdient wel instemming. Delen twee mensen één inlog, dan maakt geen enkel rechtenmodel daar twee identiteiten van. Waar het account echte individuele toegang kent, is dat beter dan welke deelregeling ook, en het is het eerste wat je nakijkt bij het sorteren van je accounts. Zie de 2FA van een gedeeld account: hoe pakt een team dat aan?.

Kijk de toegangen op een vaste datum na

Lees eens per kwartaal de lijst van elk gedeeld account en haal de namen weg die er niet horen. Voeg een controle toe bij elke functiewissel en bij elk einde van een opdracht.

Het kost een paar minuten als de toegang per account is verleend. Is je enige spoor een gedeelde kluismap die een dozijn mensen kan openen, dan valt er niets na te kijken: het antwoord is altijd „iedereen”. Accounts die niemand in maanden heeft geraadpleegd hoeven meestal helemaal niet gedeeld te worden.

De fouten die terugkeren

Alles voor iedereen als standaard. Meestal verantwoord met de angst voor flessenhalzen. Het maakt van elke verloren laptop een blootstelling van het hele bedrijf.

Aan de persoon verlenen in plaats van aan de functie. Toegang volgt een naam, de naam wisselt van baan, en niemand weet welke toekenningen aan de oude rol vasthingen. Verleen aan de rol en de wissel wordt mechanisch.

Geen benoemde beheerder. Is niemand verantwoordelijk voor het geheim van een account, dan bewaart niemand de herstelcodes ervan en ziet niemand de toegang afdrijven.

Vertrek behandelen als een beveiligingsproject in plaats van als een regel op een lijst. Het hoort naast de laptop en de badge, met dezelfde termijn.

Het mechanisme kiezen voordat de accounts gesorteerd zijn. Vergelijk mechanismen alleen voor de inloggegevens die echt maar één set aanmeldgegevens hebben, zoals in de beste manieren om de 2FA van een gedeeld account te beheren.

Waar Share Auth staat

Share Auth is rond deze vorm gebouwd. Je voert het geheim van elk account één keer in, en het wordt versleuteld opgeslagen. De mensen die je uitnodigt zien de actuele code en het aftellen, niet de tekenreeks waar hij uit komt: er is dus niets dat ze elders kunnen inschrijven.

Rechten worden per lid en per account verleend, waardoor de roltabel hierboven uitdrukbaar wordt in plaats van theoretisch. Elke raadpleging wordt in een toegangslogboek geschreven. Een lid verwijderen trekt zijn toegang op alle accounts in één keer in: een vertrek is een handeling, geen migratie. Er is een API als je onboarding al geautomatiseerd is.

Het gratis pakket dekt drie geheimen en drie leden zonder bankkaart, genoeg om de echte accounts van een team te draaien en te zien of het rechtenmodel standhoudt.

Wat dit niet oplost

Een gedeelde inlog blijft een gedeelde identiteit. Per persoon verleende codes vertellen je wie er een ophaalde; ze laten het auditspoor van het platform je collega’s niet onderscheiden, en ze geven je geen rechten per persoon binnen het account. Waar een aanbieder echte gebruikersaccounts of SSO biedt, blijft dat het beste antwoord, en deze opzet geldt voor accounts die geen van beide bieden.

Het doet ook niets aan het wachtwoord. Slingert dat ergens rond waar iedereen het kan lezen, dan heeft het apart houden van het geheim je de onafhankelijkheid van de tweede factor opgeleverd en verder niets. Dat is iets waard, maar het is niet de hele toegangscontrole.