De 2FA van een gedeeld account: hoe pakt een team dat aan?

Neem het in deze volgorde. Schaf de gedeelde inlog af overal waar de tool dat toelaat. Waar hij dat niet toelaat, delegeer de toegang per persoon als de tool een begrip van leden heeft. Voor de accounts die echt maar één inlog en één tweede factor hebben: houd het geheim op één plek en geef het team toegang tot de codes die het maakt, met een spoor van wie heeft gekeken.

De meeste teams springen meteen naar het derde geval, en delen dan het geheim zelf, meestal als schermafbeelding van de installatie-QR-code. Dat is de enige handeling in dit hele onderwerp die niet ongedaan te maken is.

Waarom teams accounts gaan delen

Een gedeeld account is geen teken van een nalatig team. Het komt meestal uit vier gewone situaties.

De prijs per zetel. Een tool kost 19 euro per gebruiker per maand, en één persoon gebruikt hem twee keer per week. Het team koopt één zetel en deelt hem. Dat is een budgetbeslissing, geen beveiligingsbeslissing, en het team zeggen vijf zetels te kopen verandert het budget niet.

Eén enkele facturatie- of juridische identiteit. Betaaldienstverleners, domeinregistrars en belastingportalen hangen aan één houder. Vaak is er geen tweede zetel te koop.

Accounts die het team niet bezit. Bureaus werken in de accounts van hun klanten, met inloggegevens die bij de start van de opdracht zijn gemaild. De klant vragen zijn toegangsmodel te herzien is zelden haalbaar.

Accounts die ouder zijn dan het team. Iemand maakte het in 2019 aan met een privéadres, het werd dragend, en niemand heeft de inlog sindsdien aangeraakt.

Geen van deze gevallen wordt opgelost door een regel die zegt dat je geen accounts mag delen. Wat wel oplosbaar is, is wat er met de tweede factor gebeurt zodra het delen vaststaat.

Wat 2FA verandert aan een gedeeld account

Een gedeeld wachtwoord is een abstractie: het woont in een kluis, en iedereen die de kluis heeft, heeft het. Tweefactorauthenticatie aanzetten geeft het account een fysieke plek: een bepaalde telefoon, in een bepaalde zak. Dat levert twee verschillende storingen op, en ze trekken in tegengestelde richtingen.

De flessenhals

Eén persoon wordt de voordeur. Er wordt haar om codes geschreven tijdens haar vakantie, haar ziekte, haar vergaderingen, en op het slechtst denkbare moment tijdens een incident. Teams gaan eromheen door deployments te plannen wanneer die persoon wakker is, wat het teken is dat het account een afhankelijkheid van een mens is geworden.

Dan raakt de telefoon kwijt, of wordt vervangen, of de persoon vertrekt zonder overdracht, en de toegang is weg. Niet geblokkeerd. Weg. Wat volgt is een herstelprocedure bij de aanbieder, in diens tempo, met de eigendomsbewijzen die hij vraagt.

De stille kopie

Tegenover de flessenhals is de natuurlijke beweging iedereen zijn eigen app te laten inschrijven vanaf dezelfde installatie-QR-code. Dat lost de beschikbaarheid meteen op en maakt een probleem zonder houdbaarheidsdatum.

De QR-code bevat het geheim. Eenmaal in een kanaal of op een gedeelde schijf gepubliceerd, is het aantal kopieën onbekend en onmogelijk te achterhalen: het zit in de berichtgeschiedenis, in zoekindexen, in back-ups, en op de telefoon van iedereen die hem ooit scande, ook van wie allang weg is. De beveiligingspagina van het account zal er nooit over spreken. Niets brengt het ooit naar boven, tot de dag dat iemand die de toegang niet zou moeten hebben hem gebruikt.

De tweede storing is erger dan de eerste, omdat de eerste zich aankondigt en de tweede niet.

Sorteer de accounts voor je een mechanisme kiest

De fout is één mechanisme voor alles te kiezen. Sorteer eerst de lijst. Voor de meeste teams kost dat twintig minuten en krimpt het echte probleem tot een handvol accounts.

De accounts die helemaal niet gedeeld hoeven te worden

Kijk of de tool SSO aankan in het pakket dat je hebt, of individuele gebruikers met rollen. Zo ja, dan zou de gedeelde inlog moeten ophouden te bestaan. Iedereen logt op eigen naam in, met een eigen tweede factor, en er blijft niets te delen. Het is de enige optie in dit artikel die het probleem wegneemt in plaats van het te beheren.

De accounts die delegatie toelaten

Een grote groep zit in het midden: één account bezit de bron, maar het platform laat toe mensen afzonderlijk toe te voegen. Cloudconsoles laten toe een gebruiker per persoon aan te maken met een eigen MFA. Advertentieplatforms en business managers geven individuele toegang op een bron. Betaaldienstverleners laten meestal toe teamleden uit te nodigen die elk hun eigen 2FA instellen.

Hier blijft de gedeelde inlog bestaan (de eigenaar, het rootaccount, het ding dat je twee keer per jaar gebruikt) en gebeurt het dagelijkse werk onder persoonlijke identiteiten. Vertrekt iemand, dan verwijder je één persoon en raak je verder niets aan. Het is de minst glansrijke en meest nuttige stap van de hele oefening, en de vaakst overgeslagen omdat het opzetten ervan een middag kost.

De accounts die echt maar één inlog hebben

Wat overblijft is het echte onderwerp: de domeinregistrar, de kleine SaaS zonder teampakket, het klantaccount waarvan de eigenaar niets gaat herzien, het geërfde account dat niemand wil migreren. Eén inlog, één tweede factor, en meerdere mensen die hem terecht nodig hebben.

Vijf manieren om die laatste groep te draaien

Twee van die regels verdienen meer dan een tabelregel, want dat zijn de regels die teams echt in praktijk brengen.

Het aparte toestel is beter dan zijn reputatie. Het houdt het geheim buiten persoonlijke toestellen en laat zich makkelijk uitleggen. Het faalt op beschikbaarheid, want een team op afstand kan geen lade gebruiken, en op achteraf iets weten. Als noodtoestel, samen met de herstelcodes bewaard, verdient het zijn plek.

De gedeelde wachtwoordmanager is het gangbaarste antwoord, en voor een team van drie volstaat het vaak. De zwakte is structureel en geen gevolg van slordigheid: het wachtwoord en het TOTP-geheim belanden in dezelfde vermelding, dus één gekraakt kluisaccount levert beide factoren. De meeste kluizen loggen ook het openen van een vermelding, wat niet hetzelfde is als weten voor welke aanmelding een code diende. Waar de kluis de twee kan scheiden en de toegang per vermelding kan beperken, gebruik dat.

Hoe de juiste opzet eruitziet, wat je ook kiest

Vier eigenschappen scheiden een gedeeld account dat je beheerst van een account waarvan je alleen hoopt dat niemand het misbruikt.

• Niemand hoeft het geheim te hebben om een code te krijgen. Een verloren laptop of een vertrekkende leverancier houdt dan op een incident te zijn.
• De toegang geldt per persoon en per account. Wie op het sociale profiel post heeft geen enkele reden codes te maken voor de betaaldienstverlener.
• De raadplegingen worden vastgelegd wanneer ze gebeuren. Na een incident is de eerste vraag wie op dat moment toegang had. Dat uit een gespreksgeschiedenis reconstrueren is geen antwoord.
• Iemand verwijderen past in één handeling. Vereist een vertrek een 2FA-reset op elf accounts, dan gebeurt het niet, zonder dat iemand het zegt.

De werking van de eerste eigenschap, codes zonder het geheim, staat in TOTP-codes delen zonder het geheim te delen, en de praktische opzet in hoe je 2FA-codes veilig met je team deelt.

Een regel die je deze week kunt toepassen

1. Maak een lijst van de gedeelde inlogs die mensen blokkeren. Niet al je accounts, alleen die waar iemand op iemand anders wacht. Meestal vier of vijf.
2. Zoek voor elk SSO of individuele zetels in je huidige pakket. Alles wat die heeft, verlaat de lijst.
3. Zoek voor de rest de delegatie. Leden, subgebruikers, toegang op bronniveau. Verplaats het dagelijkse werk daarheen en houd de gedeelde inlog voor het eigendom van het account.
4. Wat beide controles overleeft is je echte 2FA-probleem. Beslis waar het geheim woont, geef alle anderen toegang tot de codes in plaats van tot het geheim, en houd een logboek bij.
5. Reset de 2FA op elk account waarvan de QR-code ergens is gepubliceerd. Een geheim laat zich niet ont-delen. Beschouw het als verbrand en begin dat account één keer opnieuw.
6. Noteer waar elk geheim woont, met de herstelcodes, ergens waar de beheerders kunnen komen zonder via het account te gaan dat het beschermt.

Stap 6 is degene waarvan je spijt hebt hem te hebben overgeslagen. De enige kopie van een herstelcode opbergen in het account dat hij herstelt is een lus die zich op het slechtste moment sluit.

Waar Share Auth staat

Share Auth dekt stap 4 en verder niets. Een account wordt één keer toegevoegd, door wie het beheert, en de uitgenodigde mensen zien de actuele zescijferige code met het aftellen in plaats van de tekenreeks erachter. De geheimen zijn versleuteld opgeslagen, de rechten worden per lid verleend, en elke raadpleging wordt in een toegangslogboek geschreven. Een lid verwijderen trekt zijn toegang op alle accounts in één keer in, zonder dat er iets opnieuw ingesteld hoeft te worden voor wie blijft.

Het vervangt bewust je wachtwoordmanager niet, en het vervangt SSO niet waar SSO bestaat. Heeft stap 2 of stap 3 een account opgelost, dan hoort dat account hier niet thuis.

Wat dit alles niet oplost

Een gedeelde inlog is een gedeelde identiteit, en geen enkel gereedschap rond de tweede factor verandert dat. Het auditlogboek van de aanbieder toont het account, niet de persoon. Een spoor van wie een code raadpleegde is de beste beschikbare vervanging, en die is goed: het brengt een onderzoek van „iedereen” naar een naam en een tijdstempel. Maar het is een gevolgtrekking, geen bewijs.

Dat is het argument om de middag aan stap 3 te besteden in plaats van stap 4 te perfectioneren. Gedeelde 2FA goed regelen loont voor de accounts die gedeeld moeten blijven. Voor al het andere is het doel er volgend kwartaal minder te hebben dan dit kwartaal.