Wachtwoorden beheren binnen teams is eenvoudig met drie mensen. Bij vijftien mensen begint het vast te lopen.

Een klein bedrijf heeft misschien een handjevol tools, enkele gedeelde accounts en doorgaans één informele plek waar wachtwoorden staan: een spreadsheet, een vastgepind bericht in een chat of een gedeeld document.

Naarmate er meer mensen bij een bedrijf komen, maakt informeel delen het moeilijk om het verschil te zien tussen nuttige toegang en riskante toegang. Wachtwoorden voor alledaagse tools komen terecht tussen inloggegevens voor financiën, beheer, klanten of infrastructuur. De lijst oogt van buitenaf misschien nog overzichtelijk, maar geeft niet meer weer wie er eigenlijk bij welke gegevens moet.

Naarmate een bedrijf groeit, hebben gedeelde inloggegevens structuur en controle nodig: wie kan bij welk wachtwoord, welke afdeling is eigenaar van de inloggegevens en hoe verandert de toegang naarmate mensen komen, gaan en van functie wisselen.

We leggen uit hoe u wachtwoordkluizen per team of afdeling organiseert, hoe groepsgewijze toegang least privilege ondersteunt en hoe u onboarding en offboarding veiliger maakt – voordat de verspreiding van inloggegevens een beveiligings- en operationeel probleem wordt.

Waarom gedeelde wachtwoordtoegang niet schaalt

Informeel delen is meestal het eerste model waar groeiende bedrijven op vertrouwen. Informeel delen is gericht op gemak: wachtwoorden staan in een spreadsheet, een discussiedraad of de browser van iemand, en niemand hoeft elke keer om toegang te vragen als er moet worden ingelogd.

Dat gemak wordt al snel overtroffen door chaos en risico. Zodra er meer teams, freelancers, klanten en tools bij het bedrijf betrokken zijn, wordt die gedeelde lijst te breed voor het werk dat mensen echt doen. Het financiële team heeft bijvoorbeeld inloggegevens nodig voor bankieren, salarisadministratie en facturatie, maar niet voor advertentieaccounts of ontwikkelaarstools. Marketing heeft mogelijk toegang tot analytics, content en social media nodig, maar niet tot juridische portals of inloggegevens voor infrastructuur.

De gebreken worden zichtbaar in het dagelijkse werk, maar offboarding is waar dit model gevaarlijk wordt. Als iemand vertrekt, heeft het bedrijf geen betrouwbare manier om te weten bij welke inloggegevens die persoon toegang had, welke zijn gekopieerd of welke die persoon zich nog herinnert. Een wachtwoord vervangen betekent dat het nieuwe opnieuw via dezelfde onbeveiligde kanalen moet worden verspreid, zonder registratie van wie het heeft ontvangen. Vanwege die inspanning slaan veel bedrijven het vervangen van wachtwoorden over.

Een wachtwoordbeheerder voor bedrijven met gestructureerde kluizen en groepsgewijze toegang vervangt onnauwkeurigheid door controle: toegang kan doelbewust worden verleend, gecontroleerd en ingetrokken.

Hoe groter de kluis wordt, hoe minder bruikbaar deze is als toegangscontrole. Wachtwoorden worden er misschien nog steeds veilig bewaard, maar de kluis geeft niet meer weer hoe het bedrijf echt werkt, wie eigenaar is van welke inloggegevens en wie deze zou moeten kunnen gebruiken.

Toegang per team ondersteunt least privilege

Het principe achter toegang tot inloggegevens per afdeling is eenvoudig: mensen mogen alleen toegang hebben tot de inloggegevens die ze nodig hebben voor hun werk.

Het principe van least privilege is nuttig omdat het een heldere toets geeft voor toegang tot inloggegevens: heeft deze persoon dit wachtwoord nodig om het werk te kunnen doen, of heeft die het omdat de toegang ooit is verleend en daarna nooit meer is bevraagd? Bij het beheren van teamwachtwoorden zou die vraag bepalend moeten zijn voor hoe kluizen worden aangemaakt, wie erbij hoort en wanneer toegang wordt verwijderd.

Dit is vooral belangrijk voor gedeelde inloggegevens. Een gedeelde login is al moeilijker te beheren dan een individueel account, omdat meer dan één persoon deze kan gebruiken.

Als die inloggegevens ook toegankelijk zijn voor mensen die er geen toegang toe nodig hebben, loopt het bedrijf risico zonder enig voordeel: elke extra persoon die ze kan bekijken, is een extra apparaat waar ze automatisch kunnen worden ingevuld, gekopieerd of kunnen worden misbruikt via phishing. Het bedrijf weet misschien dat het wachtwoord veilig wordt opgeslagen, maar niet of iedereen met toegang tot de kluis er nog een geldige reden voor heeft.

Groepen in Proton Pass for Business lossen dit op: beheerders kunnen mensen indelen in groepen die teams, afdelingen of projecten weerspiegelen en die groepen vervolgens toewijzen aan specifieke kluizen en items, zodat de toegang volgt op basis van de functie in plaats van een lijst met individuele toekenningen.

De structuur van kluizen moet aansluiten bij het risico. Operationele logins met weinig risico kunnen eenvoudig worden gedeeld, terwijl beheerdersinloggegevens, financiële tools, HR-systemen, klantexport en back-uptoegang strengere controles nodig hebben.

Hoe een goede kluisstructuur eruitziet

Een bruikbare kluisstructuur moet mensen helpen vinden wat ze nodig hebben, zonder ze alles te geven.

Een praktisch uitgangspunt voor de meeste groeiende kmo’s zijn zes wachtwoordkluizen per team:

  • Financiën: Boekhouding, salarisadministratie, bankieren, facturatie, belastingportals, betalingsplatforms.
  • Marketing: Social media, analytics, advertenties, contentbeheer, designtools.
  • Sales en klantrelaties: CRM, offertetools, klantportals, ondersteuningsplatforms.
  • Operationeel: Leveranciersportals, tools voor projectbeheer, logistiek, inkoop.
  • IT en beveiliging: Beheerdersconsoles, back-upaccounts, apparaatbeheer, DNS, hosting, infrastructuur.
  • Directie: Documenten voor de raad van bestuur, beleggersportals, services op directieniveau, gevoelige leveranciersaccounts.

Als de kluisstructuur en groepstoegang samenwerken, kunnen beheerders machtigingen op grote schaal beheren: wijs een financiële groep toe aan de financiële kluis, een IT-groep aan infrastructuurkluizen en een projectgroep aan tijdelijk klantenwerk. De toegang schaalt dan mee met het organisatieschema in plaats van met het geheugen van een beheerder.

Zodra de basisstructuur op zijn plaats is, kunt u beperkte kluizen aanmaken waar het risico dat rechtvaardigt. Een IT-team kan een algemene IT-kluis hebben en een aparte beheerderskluis met verhoogde rechten, beide toegewezen aan de juiste groepen.

Dit wordt essentieel tijdens onboarding en offboarding. Als u iemand aan een groep toevoegt, krijgt die persoon in één keer alle benodigde kluizen; bij verwijdering wordt alles in één keer ingetrokken.

Het doel is niet om kluizen ingewikkeld te maken. Het doel is om te voorkomen dat inloggegevens met heel verschillende risiconiveaus door elkaar raken. Een socialmediaplanner zou geen toegang mogen delen met salarisadministratie.

Wachtwoordkluisstructuren voor teams van verschillende groottes

Een heel klein bedrijf heeft geen kluisarchitectuur op bedrijfsniveau nodig. Te veel structuur te vroeg kan verwarring veroorzaken en de invoering vertragen.

Zelfs met een tot twee mensen legt u een fundament voor groei door zakelijke inloggegevens in aparte kluizen te scheiden van persoonlijke.

Voor een team van drie tot tien mensen zijn een paar brede kluizen misschien genoeg: bedrijfsvoering, financiën, marketing en IT. De belangrijkste prioriteit is één kluis voor alles vermijden en de meest gevoelige inloggegevens apart houden.

Voor een team van tien tot vijftig mensen moet de kluisstructuur volgen hoe het bedrijf daadwerkelijk is georganiseerd. In deze fase wordt toegang tot inloggegevens onderdeel van de dagelijkse bedrijfsvoering: mensen komen bij teams, freelancers worden aangetrokken voor specifieke projecten, managers worden verantwoordelijk voor de tools die hun teams gebruiken en beheerders hebben een manier nodig om toegang te controleren zonder elke inloggegeven afzonderlijk te openen. Freelancers en externe samenwerkers kunnen toegang krijgen tot projectspecifieke kluizen met een afgebakende reikwijdte, zodat ze alleen zien wat hun opdracht vereist – en automatisch de toegang verliezen als het project eindigt.

Voor teams van vijftig of meer – grotere kmo’s en middenmarktteams – moeten kluizen mogelijk zowel per afdeling als per functie worden ingedeeld. Een afdelingslabel is niet altijd specifiek genoeg; iemand kan in de financiële afdeling werken zonder toegang tot bankieren nodig te hebben, of de IT-bedrijfsvoering ondersteunen zonder beheerdersinloggegevens met verhoogde rechten nodig te hebben.

De structuur moet passen bij het bedrijf, niet andersom. In de volgende secties leest u hoe u die structuur operationeel maakt via onboarding, offboarding en doorlopende toegangscontroles.

Inbouwen van structuur in onboarding

Onboarding legt vaak zwak wachtwoordbeheer bloot. Een nieuwe medewerker komt in dienst en iemand moet onthouden welke inloggegevens die persoon nodig heeft, waar die wachtwoorden staan, wie ze kan delen en welke toegang moet wachten tot na training of goedkeuring.

Een model op basis van teams neemt die afhankelijkheid van het geheugen weg. Als een nieuwe collega in de financiële afdeling begint, hoeft die niet een collega te vragen elke inloggegeven handmatig te identificeren en te delen. Die persoon kan gewoon worden toegevoegd aan de financiële groep voor de benodigde toegang. Niemand zou koppelingen hoeven door te sturen, wachtwoorden in een chat hoeven te plakken of hoeven onthouden welke tools het financiële team meestal gebruikt.

Die persoon wordt gewoon toegevoegd aan de financiële groep en erft automatisch de kluizen en items die aan die groep zijn toegewezen – alleen de inloggegevens die bij die functie horen. Zo verloopt onboarding sneller en blijven gevoelige accounts binnen het team dat ze nodig heeft. Mensen kunnen aan het werk gaan zonder achter wachtwoorden aan te hoeven gaan, terwijl het bedrijf omwille van het gemak geen brede toegang hoeft te geven.

Ook helpt hier een duidelijk wachtwoordbeleid. De gids van Proton over het maken van een wachtwoordbeleid legt uit hoe bedrijven regels kunnen definiëren voor het maken van wachtwoorden, veilig delen, toegangsbeheer en verificatie. Die regels zijn makkelijker toe te passen als inloggegevens al per team zijn georganiseerd.

Veiliger maken van offboarding

Met één gedeelde bedrijfskluis is intrekken alles of niets: de vertrekkende medewerker heeft mogelijk tientallen of honderden inloggegevens gebruikt, wat betekent dat alle wachtwoorden vervangen moeten worden of – erger nog – dat voormalige werknemers toegang houden die blijft bestaan.

Een zorgvuldige offboarding ziet er zo uit:

  1. Verwijder de persoon uit de team- en projectgroepen.
  2. Controleer inloggegevens die deze persoon in eigendom had of beheerde.
  3. Vervang wachtwoorden met een hoger risico waar nodig.

Het bedrijf kan de inspanning voor rotatie en evaluatie richten op de inloggegevens die daadwerkelijk risico met zich meebrengen, in plaats van elk wachtwoord te behandelen als een noodgeval.

Dit is waar het aanmaken van groepen zijn vruchten afwerpt. Als toegang alleen via gedeelde kluizen wordt beheerd, moet een beheerder de persoon uit elke kluis afzonderlijk verwijderen. Met groepen trekt het verwijderen uit de groep automatisch de toegang tot elke kluis en elk item die aan die groep zijn toegewezen in – één actie in plaats van een audit.

Dezelfde logica geldt wanneer iemand van functie verandert. Wie van sales naar operations gaat, behoudt standaard geen oude CRM-beheerdersinloggegevens. Functiewijzigingen moeten net zozeer aanleiding geven tot een evaluatie van de kluistoegang als het uitdiensttreden van medewerkers. Met toegang op basis van groepen verloopt die evaluatie snel: verplaats de persoon tussen groepen en de toegang wordt automatisch bijgewerkt – oude CRM-inloggegevens ingetrokken, nieuwe operations-kluizen toegekend, allemaal in één eenvoudige stap.

Meer inzicht voor beheerders

Goed wachtwoordbeheer voor teams geeft beheerders een duidelijk beeld van de toegang. Ze moeten basisvragen snel kunnen beantwoorden.

Belangrijke toegangsvragen die beheerders moeten kunnen beantwoorden

  • Wie heeft toegang tot de financiële inloggegevens?
  • Welke kluizen omvatten externe opdrachtnemers?
  • Welke gebruikers hebben toegang tot beheerderswachtwoorden?
  • Welke inloggegevens worden gedeeld tussen afdelingen?
  • Wat is er veranderd nadat een medewerker is vertrokken?
  • Welke kluizen bevatten accounts met een hoog risico of met verhoogde rechten?

De NCSC-richtlijnen voor identiteits- en toegangsbeheer(nieuw venster) benadrukken dat moet worden gecontroleerd wie en wat toegang heeft tot systemen en gegevens. Ook wijzen ze op het belang van het beperken van toegang tot wat nodig is en het regelmatig evalueren van toegang.

Dit is lastig als toegang wordt georganiseerd rond gemak in plaats van verantwoordelijkheid. Een overzichtelijke kluisstructuur geeft beheerders een steviger startpunt voor beveiligingsaudits, toegangsevaluaties en vragenlijsten van klanten.

Voor IT-teams biedt Proton Pass for Business ondersteuning voor gecentraliseerd beheer, beleid, veilig delen, rapportage en logboeken, SCIM-provisioning en SSO-integraties. Teams krijgen gecentraliseerd inzicht dat wachtwoorden die in de browser worden opgeslagen en gedeelde spreadsheets niet bieden.

Veelvoorkomende fouten bij het beheer van gedeelde kluizen

Problemen met gedeelde kluizen beginnen meestal als oplossingen voor het gemak. Ze maken toegang op dat moment eenvoudiger, maar maken het later juist moeilijker om te weten wie welke inloggegevens kan gebruiken.

Vijf fouten liggen aan de basis van de meeste problemen met gedeelde kluizen in groeiende bedrijven:

Het te lang aanhouden van één bedrijfskluis

Eén kluis kan in het begin goed werken, maar uiteindelijk krijgen te veel mensen toegang tot inloggegevens die buiten hun functie vallen.

Afhankelijkheid van de kennis van één beheerder

Als slechts één persoon weet waar kritieke inloggegevens zich bevinden, is het bedrijf afhankelijk van geheugen in plaats van processen – en die kennis loopt de deur uit wanneer die persoon vertrekt.

Behandeling van kluistoegang als permanent gegeven

Mensen veranderen van functie, opdrachtnemers ronden projecten af en leveranciers vertrekken. Toegang tot kluizen zou mee moeten veranderen.

Het vergeten van de rotatie van inloggegevens

Sommige wachtwoorden moeten worden gewijzigd na uitdiensttreding, functiewijzigingen of perioden van al te ruim delen, vooral voor beheerdersaccounts, financiële tools, klantensystemen en leveranciersportals.

Het mengen van alledaags inloggen met toegang met verhoogde rechten

Een teamkluis kan het dagelijkse werk eenvoudiger maken, maar inloggegevens met een hoog risico vereisen nog steeds strengere controle en beperktere toegang.

Elk van deze fouten heeft dezelfde oorzaak – toegang georganiseerd rond gemak – en dezelfde remedie: een structuur die het team, de functies en het risico weerspiegelt.

Hoe Proton Pass for Business wachtwoordbeheer voor teams ondersteunt

Proton Pass for Business helpt bedrijven om van informeel delen van wachtwoorden over te stappen naar gestructureerd beheer van inloggegevens. Teams kunnen sterke wachtwoorden genereren, inloggegevens opslaan in versleutelde kluizen, toegang veilig delen en zakelijke wachtwoorden vanaf één plek beheren.

Een zakelijke wachtwoordbeheerder geeft teams een veiligere plek om inloggegevens op te slaan en te delen, maar de structuur rond die inloggegevens blijft belangrijk. Voor groeiende teams is de volgende stap om ervoor te zorgen dat gedeelde toegang weerspiegelt hoe mensen daadwerkelijk werken: per afdeling, functie, project en risiconiveau.

Met groepen in Proton Pass wordt toegang tot inloggegevens beheerd op het niveau waarop teams daadwerkelijk werken: beheerders wijzen kluizen en items toe aan groepen die hun afdelingen of projecten weerspiegelen, en wijzigingen in het lidmaatschap werken de toegang automatisch bij – het toevoegen van een nieuwe medewerker verleent alles die persoon nodig heeft; het verwijderen trekt alles in.

Een duidelijkere structuur maakt veilig delen makkelijker te beheren binnen de werkstroom. Inloggegevens worden georganiseerd rond de teams en functies die ze daadwerkelijk gebruiken, beheerders hebben een beter overzicht van de toegang en werknemers vinden de wachtwoorden die ze nodig hebben zonder geheimen te verplaatsen naar chat, e-mail of persoonlijke notities.

Organiseer de toegang tot de inloggegevens van uw team met een zakelijke wachtwoordbeheerder.