Rollen en rechten in een klantportaal bepalen welke gebruiker welke informatie mag zien en welke handelingen mag uitvoeren. Een goed model begint bij verantwoordelijkheden, niet bij individuele namen. Je definieert eerst rollen zoals organisatiebeheerder, projectmedewerker en klant, koppelt daar beperkte bevoegdheden aan en wijst gebruikers vervolgens toe aan de juiste projecten of dossiers.
Zo blijft toegang beheersbaar wanneer teams, klanten en projecten veranderen. Zonder rollenmodel ontstaan al snel brede beheeraccounts, handmatige uitzonderingen en onduidelijkheid over wie iets mocht publiceren of wijzigen.
Begin bij informatie en handelingen
Maak eerst een inventarisatie van wat het portaal bevat. Denk aan projectupdates, persoonsgegevens, documenten, keuzes, berichten, beoordelingen en gebruikersbeheer. Beschrijf per onderdeel welke handelingen mogelijk zijn:
- bekijken;
- toevoegen of uploaden;
- bewerken;
- publiceren naar klanten;
- beoordelen of goedkeuren;
- verwijderen of archiveren;
- toegang toekennen of intrekken.
“Toegang tot documenten” is dus te grof. Een medewerker die een bestand mag uploaden, hoeft niet automatisch te bepalen voor welke klanten het wordt gepubliceerd. Door handelingen te scheiden, wordt duidelijk waar extra controle nodig is.
Maak onderscheid tussen rol en bereik
De rol beschrijft wat iemand kan doen; het bereik beschrijft waar dat mag. Een projectmedewerker kan bijvoorbeeld updates publiceren, maar alleen binnen toegewezen projecten. Een klant kan documenten bekijken, maar alleen binnen het eigen dossier.
Deze combinatie voorkomt dat je voor iedere medewerker een unieke rol maakt. Dezelfde rol kan voor meerdere projecten worden gebruikt, terwijl de project- of dossierkoppeling het bereik beperkt.
Een praktische autorisatiematrix
Onderstaande vereenvoudigde matrix is een startpunt. Pas haar aan op je processen en risico’s.
| Handeling | Organisatiebeheerder | Projectbeheerder | Projectmedewerker | Klant |
|---|---|---|---|---|
| Organisatie-inrichting beheren | Ja | Nee | Nee | Nee |
| Project en dossiers inrichten | Volgens beleid | Binnen toegewezen project | Meestal niet | Nee |
| Update publiceren | Volgens beleid | Binnen toegewezen project | Alleen indien nodig voor de taak | Nee |
| Klantdocument bekijken | Alleen met werkreden | Binnen toegewezen project | Binnen toegewezen project of dossier | Alleen eigen dossier |
| Keuze indienen | Nee | Niet namens klant zonder afgesproken proces | Niet namens klant zonder afgesproken proces | Eigen dossier |
| Gebruikers uitnodigen | Ja | Eventueel binnen project | Nee | Nee |
Vervang “volgens beleid” door een concrete afspraak. Een matrix is alleen bruikbaar als iemand kan bepalen wat in de praktijk is toegestaan.
Beperk beheerrechten bewust
Beheeraccounts hebben invloed op veel projecten en gebruikers. Ken zulke rechten daarom alleen toe wanneer de functie ze nodig heeft. Gebruik geen gedeelde accounts en behandel tijdelijke vervanging als een expliciete, weer in te trekken toewijzing.
Het NCSC adviseert organisaties om identiteiten en toegang vanuit vastgesteld beleid te beheren en besteedt daarbij aandacht aan aanvragen, goedkeuren, wijzigen en verwijderen van autorisaties. Zie de praktische uitleg over identiteits- en toegangsbeheer. Welke technische en organisatorische maatregelen passend zijn, bepaal je op basis van je eigen risicoanalyse.
Ontwerp het in-, door- en uitstroomproces
Rechten verouderen. Een medewerker wisselt van functie, een externe partner rondt werk af of een klanttraject eindigt. Leg daarom per gebeurtenis vast wat er met toegang gebeurt.
- Instroom: de leidinggevende of proceseigenaar vraagt een rol en bereik aan.
- Controle: een bevoegde beheerder verifieert project, dossier en einddatum.
- Doorstroom: bij een rolwijziging worden oude rechten herzien, niet alleen nieuwe toegevoegd.
- Uitstroom: accounts en projecttoegang worden tijdig ingetrokken.
- Periodieke review: eigenaren controleren of actieve rechten nog nodig zijn.
Neem ook klanttoegang mee. Denk aan een tweede koper, een bewindvoerder of vertegenwoordiger, en aan de situatie na overdracht van een woning. Beoordeel deze scenario’s juridisch en organisatorisch voordat je ze technisch automatiseert.
Scheid voorbereiden en publiceren waar nodig
Voor informatie met grote impact kan een tweede controle nuttig zijn. Een medewerker bereidt een update of documentpublicatie voor; een bevoegde collega controleert inhoud, versie en doelgroep voordat klanten het zien.
Pas zo’n vierogenstap gericht toe. Als iedere kleine tekstwijziging door twee mensen moet worden behandeld, zoeken teams mogelijk een omweg. Reserveer extra controle voor processen waar een fout daadwerkelijk grote gevolgen kan hebben.
Maak rechten uitlegbaar aan klanten en medewerkers
Een gebruiker hoeft geen technische autorisatiematrix te lezen, maar moet wel begrijpen waarom bepaalde informatie zichtbaar is. Gebruik herkenbare project- en dossiernamen. Laat medewerkers vóór publicatie zien welke doelgroep is geselecteerd en bied een klantweergave om de inrichting te controleren.
De Autoriteit Persoonsgegevens wijst organisaties erop dat systemen en processen zo moeten zijn ingericht dat privacyrechten kunnen worden uitgevoerd. De pagina over privacyrechten in de praktijk is een bruikbare primaire bron bij het opstellen van je beheerproces.
Test ook misbruik en vergissingen
Een acceptatietest moet verder gaan dan “kan de beheerder inloggen?”. Controleer minimaal:
- of een klant geen ander dossier kan openen via navigatie of een bewaarde link;
- of een medewerker buiten het toegewezen project geen klantinformatie ziet;
- of een gebruiker zonder publicatierecht een concept niet kan vrijgeven;
- of ingetrokken toegang daadwerkelijk niet meer werkt;
- of een beheerder ziet voor welke doelgroep een document wordt gepubliceerd;
- of uitzonderingen en foutmeldingen geen informatie over andere dossiers prijsgeven.
Documenteer de testgevallen en herhaal ze na wezenlijke wijzigingen in rollen, projectstructuur of koppelingen.
Probeer het model eerst in één project
Een pilot maakt zichtbaar waar een rol op papier logisch lijkt maar in het dagelijkse werk te breed of juist te beperkt is. Kies één project, wijs echte verantwoordelijkheden toe en laat medewerkers enkele complete taken uitvoeren: een dossier aanmaken, een document voorbereiden, de klantweergave controleren en een gebruiker weer verwijderen. Noteer iedere tijdelijke uitzondering. Als dezelfde uitzondering terugkomt, onderzoek dan of de rol of het proces moet veranderen in plaats van steeds extra toegang toe te voegen.
Van matrix naar dagelijks beheer
Het beste rollenmodel is niet het model met de meeste niveaus, maar het model dat beheerders consequent kunnen toepassen. Begin klein, benoem een eigenaar en leg uitzonderingen apart vast. Het artikel over digitale woningdossiers en toegangsrechten laat zien hoe rollen met de dossierstructuur samenwerken.
Yindle Portal ordent klanttrajecten rond projecten, dossiers en gebruikers. Bespreek je rollen- en rechtenmodel voordat je een nieuwe klantomgeving in gebruik neemt.