Een wachtwoordmanager invoeren bij een klein team

Begin met drie vragen op papier, niet in software. Wie is eigenaar van de inloggegevens van het bedrijf (de zaakvoerder, niet een individuele medewerker)? Wie beheert de wachtwoordmanager zelf? Wie neemt over als die beheerder afwezig of vertrokken is?

• Eigenaar: beslist welke gegevens in de kluis horen en wie toegang krijgt.
• Beheerder: voegt gebruikers toe en verwijdert ze, en beheert gedeelde mappen of groepen.
• Back-upbeheerder: een tweede persoon die kan ingrijpen als de beheerder wegvalt.
• Gebruiker: bewaart en gebruikt gegevens volgens de afspraken.

In een team van drie of vier kan één persoon meerdere rollen hebben, maar eigenaar en back-upbeheerder zijn bij voorkeur niet dezelfde persoon. Noteer de namen en bewaar dit document op een plek die niet afhangt van de wachtwoordmanager zelf. Welke rollen en rechten een bepaald product echt kent, controleert de beheerder in de documentatie van die aanbieder; de rollen hierboven zijn je eigen afspraken, niet noodzakelijk de productnamen.

Een wachtwoordmanager is zelf een waardevol doelwit. Zet dus eerst de beveiliging van de hoofdaccounts op orde. Google legt voor Google-accounts uit dat tweestapsverificatie een extra beveiligingslaag toevoegt voor het geval je wachtwoord wordt gestolen, en dat je kunt inloggen met je wachtwoord plus een tweede stap of met een toegangssleutel. Die bron gaat niet over wachtwoordmanagers; het advies om dit ook daar te gebruiken is een redactionele aanbeveling, en je controleert in de documentatie van je product wat het ondersteunt. Zie de uitleg van Google over tweestapsverificatie. Werk je met een account via je werk, school of een groep, dan kan de beheerder instellingen beperkt hebben en moet je daarvoor bij je beheerder zijn.

Praktisch: zet tweestapsverificatie aan voor de beheerders- en e-mailaccounts, want via e-mail kunnen resetmeldingen verlopen. Kies voor de wachtwoordmanager zelf een lang, uniek hoofdwachtwoord en activeer de extra verificatie die het product aanbiedt. Maak ook een afspraak over wat er gebeurt als iemand zijn telefoon verliest. Welke methoden je precies kunt instellen, kijk je na in de accountinstellingen of bij je beheerder; die kunnen wijzigen.

Herstel is het deel dat teams vergeten tot het misgaat. Leg vóór de uitrol vast wat de procedure is bij vier gebeurtenissen: iemand vergeet zijn hoofdwachtwoord, iemand verliest zijn apparaat, de beheerder wordt onbereikbaar, en iemand verlaat het bedrijf.

Een belangrijk punt: wie toegang had tot een gedeeld wachtwoord, kent dat wachtwoord. Bij vertrek verwijder je dus niet alleen de gebruiker en trek je de toegang meteen in, ook als de volledige inventaris van gedeelde gegevens nog niet klaar is. Daarna beoordeel je welke gedeelde wachtwoorden je vervangt, te beginnen met de gevoeligste. Of een bepaald herstelmechanisme bestaat, verschilt per product en kan wijzigen; lees de actuele documentatie.

De gevaarlijkste stap is vaak de import: een exportbestand met alle wachtwoorden in leesbare tekst dat achterblijft op een bureaublad, in een downloadmap of in een mailbox. Beperk dat risico met een vaste volgorde.

1. Bepaal eerst welke gegevens echt moeten mee. Een oude, ongebruikte login hoef je niet over te zetten.
2. Gebruik, waar het product dat biedt, een rechtstreekse importfunctie of browser-koppeling in plaats van een tussenbestand. Controleer in de documentatie of dat bestaat.
3. Is een tussenbestand onvermijdelijk, maak het dan op een versleutelde of tijdelijk afgeschermde plek, nooit in een gedeelde map of mail.
4. Verwijder het bestand direct na de import, ook uit de prullenbak en de downloadmap, en controleer of er geen synchronisatiekopie bestaat.
5. Verifieer de import met een steekproef: open een paar items en controleer gebruikersnaam, link en notities.
6. Gebruik daarna het oude systeem (spreadsheet, notitie) niet meer en verwijder het op een vastgelegd moment.

Vermijd ook delen via chat of mail tijdens de overgang. Gebruik daarvoor de deelfunctie van het product zelf. Over de bredere aanpak van webbeveiliging zegt MDN dat je bij authenticatie niet alleen op wachtwoorden moet vertrouwen, dat passkeys de veiligste methode zijn en dat TOTP veiliger is dan traditionele wachtwoorden; zie de MDN-pagina over webbeveiliging. Dit geldt voor websites die je zelf bouwt, maar het principe geldt ook voor hoe je team inlogt.

Test het delen voor je echte gegevens toevoegt. Maak een proefitem met een nep-wachtwoord en doorloop deze controles met twee teamleden.

• Deelt de eigenaar het item met een gebruiker, en ziet die gebruiker het alleen als dat zo bedoeld is?
• Kan een gebruiker zonder rechten het item niet zien of bewerken?
• Als je het item wijzigt, ziet de andere gebruiker de nieuwe versie?
• Als je de toegang intrekt, verdwijnt het item bij die gebruiker? Controleer dit expliciet, ga er niet van uit.
• Staat er in de gedeelde map niets wat niet gedeeld mocht worden?

Noteer de uitkomst per punt. Een punt dat niet werkt zoals verwacht, los je op voor je echte wachtwoorden overzet. Gedrag bij het intrekken van toegang kan per product verschillen, dus lees ook de documentatie van de aanbieder. Dit is een controle op werking en niet een garantie dat het systeem volledig veilig is.

Een fictief voorbeeld zonder naam, uitsluitend ter illustratie. Invoer: een team van vier met een gedeeld spreadsheet voor twintig logins, één persoon die alles beheert en geen vastgelegd herstel. De eigenaar legt de vier rollen vast, kiest een back-upbeheerder, zet tweestapsverificatie aan op beheerders- en e-mailaccounts en bouwt de procedure voor vertrek. Dan importeert het team de gegevens rechtstreeks, controleert een steekproef en verwijdert het spreadsheet op een afgesproken datum. Verwachte controles: (1) bestaat er nergens nog een leesbare kopie? (2) werkt het delen en intrekken bij het proefitem? (3) kent iedereen het herstelpad?

Plan na enkele weken een korte nacontrole: wie heeft nog een logins buiten de kluis, is er een vertrek geweest en volgde je de checklist, en werkt de herstelprocedure in een droge oefening? Houd de afspraken kort en actueel.

Wil je weten welke publieke signalen je website uitstraalt rond vertrouwen en veiligheid, bekijk ze dan via Marketing Scan. Een publieke scan ziet alleen wat buiten zichtbaar is en zegt niets over hoe je team intern met wachtwoorden omgaat.