De 2FA van gedeelde socialemedia-accounts beheren

Op de meeste sociale platforms kun je posten zonder het wachtwoord te hebben. Welke delegatie er bestaat, en het herstelplan dat erbij hoort.

Op de meeste sociale platforms hoort niemand in je team het wachtwoord van het account te hebben. Meta, LinkedIn, YouTube en TikTok hebben allemaal een model waarin mensen op eigen naam worden toegevoegd, met een eigen inlog en een eigen tweede factor, en toegang krijgen tot een pagina, een kanaal of een advertentieaccount.

Waar dat model bestaat, gebruik het, en de kwestie van de 2FA verdwijnt. Wat overblijft is een korte lijst inloggegevens zonder echte delegatie, plus iets wat sociale accounts meer nodig hebben dan welke categorie ook: een herstelplan.

Waarom social het slechtste geval is voor een gedeelde inlog

Hier stapelen zich vier dingen op die dat bij een betaaldienstverlener of een cloudconsole niet doen.

Het verloop van mensen. Zzp’ers, stagiairs, bureaus en leveranciers trekken sneller langs sociale accounts dan waar ook, en elk van hen is een persoon die misschien een QR-code heeft gescand.

Platforms in telefoonvorm. Er wordt vanaf telefoons gepost, dus de inloggegevens belanden op persoonlijke toestellen, en de tweede factor is vaak een sms naar iemands nummer.

Overname is een beroep. Deze accounts worden doelbewust en op grote schaal aangevallen, want een account met volgers heeft doorverkoopwaarde en bereik.

Herstel is een wachtrij, geen procedure. Bij een betaaldienstverlener kun je meestal eigendom aantonen. Op sommige sociale platforms komt een geblokkeerd account neer op een supportformulier en wachten, zonder gegarandeerd resultaat. Die asymmetrie zou moeten veranderen hoe zorgvuldig je met de inloggegevens omgaat.

Welke delegatie er bestaat, per platform

Grofweg, en te controleren met de huidige interface, want deze dingen veranderen vaker van naam dan van vorm:

  • Facebook en Instagram. Een bedrijfsportfolio bezit de resources (pagina’s, advertentieaccounts, Instagram-profielen) en mensen worden er afzonderlijk aan toegewezen. Bureaus krijgen partnertoegang vanuit hun eigen portfolio, in plaats van inloggegevens.
  • LinkedIn. Bedrijfspagina’s hebben beheerders, die elk handelen vanuit hun persoonlijke account. Een persoonlijke LinkedIn-inlog delen is zowel riskant als in strijd met de regels.
  • YouTube. Een merkaccount kan meerdere eigenaars en managers hebben, elk met een eigen Google-inlog en een eigen tweede factor.
  • TikTok. Een bedrijfscentrum laat toe leden toe te voegen en hun accounts toe te wijzen.
  • X. Gedelegeerde toegang is er in de loop der jaren bij gekomen en weer uit gehaald: de meeste teams behandelen het dus als een gewone gedeelde inlog. Het is het archetype van het geval uit de voorlaatste paragraaf.

Het patroon is overal hetzelfde waar het bestaat: de resource wordt gedeeld, de identiteit niet.

Planningstools zijn een delegatielaag

Het andere antwoord, vaak over het hoofd gezien omdat je deze tools om andere redenen koopt: een publicatietool verbindt zich één keer met het account, via de autorisatiestroom van het platform, en je team post via de tool.

Wie post heeft nooit de inloggegevens, iemand verwijderen komt neer op hem uit de tool halen, en het platform bewaart een intrekbare autorisatie die je in zijn instellingen voor verbonden apps ziet. Twee dingen om te onthouden: de verbinding zelf is een sleutel, dus het telt wie opnieuw kan verbinden of accounts kan toevoegen, en de inloggegevens van de tool vragen dezelfde discipline als de rest.

Tussen het model van ‘mensen en resources’ van het platform en een planningstool kunnen de meeste teams zover komen dat ze het wachtwoord van het account alleen nog voor beheer gebruiken, en dan nog zelden.

De inloggegevens zonder delegatie

Sommige accounts hebben er geen: X voor de meeste teams, een Instagram-profiel dat nooit aan een bedrijfsportfolio is gekoppeld, een geërfd account dat aan een persoonlijk adres hangt, een klant die niets gaat herbouwen.

Daarvoor gelden de eisen van elk werkelijk gedeeld account: één bewaarplaats voor het geheim, toegang tot de codes per persoon verleend, een spoor van wie een code las, en herstelcodes buiten het account. De redenering staat in hoe je 2FA-codes veilig met je team deelt, en dezelfde behandeling toegepast op een betaaldienstverlener en een cloudconsole in de 2FA van een gedeeld Stripe-account beheren en de 2FA van een gedeeld AWS-account beheren.

Het herstelplan dat sociale accounts nodig hebben

Dit is de paragraaf die je echt moet uitvoeren: hij staat tussen een vertrek en een verloren account.

  • Een tweede beheerder of eigenaar, niet dezelfde persoon als de eerste, en niet de zzp’er.
  • Herstelcodes in jouw bezit, gegenereerd bij de inschrijving, bewaard buiten het account dat ze herstellen.
  • Een geverifieerd e-mailadres dat van het bedrijf is. Een gedeelde mailbox of een distributielijst, niet de mailbox van één persoon, want het wachtwoordherstel komt daar aan.
  • Een telefoonnummer dat niemand meeneemt. Eist een platform er een, dan zou het geen privémobiel moeten zijn.
  • Een geschreven notitie die zegt waar het geheim woont, zodat een reset een beslissing is en geen expeditie.

Test wat te testen valt. Controleer dat de tweede beheerder echt alleen kan handelen, en dat iemand anders dan de oorspronkelijke eigenaar de geverifieerde mailbox kan lezen.

Wanneer een zzp’er of een bureau vertrekt

  1. Haal ze uit het bedrijfsportfolio, de pagina, het kanaal of het bedrijfscentrum. Eén handeling per platform, verder wordt niets aangeraakt.
  2. Haal ze uit de planningstool, en kijk welke verbindingen ze hebben gemaakt.
  3. Loop de verbonden apps van het platform na en trek alles in wat ze hebben opgezet.
  4. Hebben ze ooit het TOTP-geheim van het account gehad, reset dan de 2FA van het account, wijzig het wachtwoord en verbreek alle sessies. Het geheim verlaat hun telefoon niet uit zichzelf.
  5. Bekijk de beheerderswissels en de recente publicaties, op zoek naar het onverwachte rond hun vertrek.

Stap 3 en 5 zijn eigen aan deze categorie. Een autorisatie die aan een externe tool is gegeven overleeft de persoon die haar gaf, en ze authenticeert zich zonder enige tweede factor.

Wat je niet moet doen

  • Het wachtwoord in een gedeeld document of een groepsgesprek bewaren. Het is de eerste plek waar iedereen kijkt, en het ligt er meestal naast het herstelmailadres.
  • De QR-code voor inschrijving fotograferen zodat iedereen het account toevoegt. Dat verspreidt het geheim definitief, naar toestellen die je niet beheerst.
  • Rekenen op sms naar een privénummer.
  • Van de telefoon van één persoon de enige toegangsweg maken, op een account waarvan het verlies in de praktijk definitief is.

Waar Share Auth staat

Voor de accounts uit de vierde paragraaf, dus X, een niet-gekoppeld Instagram-profiel of een klantinlog die je niet kunt herbouwen: het geheim wordt één keer ingevoerd en versleuteld opgeslagen, de mensen die posten zien de actuele code en het aftellen in plaats van het geheim, de rechten gelden per lid en per account, en elke raadpleging wordt gelogd.

Voor alles wat een bedrijfsportfolio, een merkaccount of een planningstool kan regelen, zijn die het betere antwoord. Een gedeelde codekluis is gemaakt voor de accounts die geen manier hebben om de identiteit persoonlijk te maken, niet voor de accounts die je nog niet de tijd hebt genomen om in te richten.

Veelgestelde vragen

Via het model van „mensen en resources” van het platform: partnertoegang tot een Meta-bedrijfsportfolio, beheerder van een LinkedIn-pagina, manager van een YouTube-merkaccount, een lidplaats in het Business Center van TikTok. De medewerkers van het bureau gebruiken hun eigen inloggegevens met hun eigen 2FA, en de klant kan de toegang op één plek intrekken.

Lees ook · Tool voor tool

6 min leestijd

De 2FA van een gedeeld AWS-account beheren

Niemand hoort een AWS-inlog te delen, en de root accepteert meerdere MFA-toestellen in plaats van een gekopieerd geheim. Wat daarna overblijft.