Ga naar hoofdinhoud
Patroon: Human-Centric ACL

Rechtenbeheer in mensentaal Begrijpelijke rollen, minder over-toekenning

Secure-by-design rechtenbeheer vertaalt technische permissies naar duidelijke rollen, zodat gebruikers veilig kunnen kiezen zonder te gokken.

Toegang aanpassen
Huidige toegang
MK
M. Klaassen (Eigenaar)
J
j.visser@overheid.nl
Wijzigen...
Alleen-lezen

Kan documenten inzien, maar niets wijzigen of delen.

Bewerken

Kan inhoud aanpassen en versies beheren.

Beheren

Rechten van anderen wijzigen en verwijderen.

Wijziging wordt vastgelegd in activiteitenlog

Wanneer gebruikers rollen zien als RBAC Group 4A of ACL-Editor-Level-2, maken ze keuzes zonder echt te begrijpen wat die betekenen.

Secure-by-design rechtenbeheer vertaalt technische permissies naar begrijpelijke rollen en maakt gevolgen zichtbaar in mensentaal.

Zo voorkom je over-toekenning van toegang zonder de operatie te blokkeren.

Waarom rechtenbeheer een UX-vraagstuk is

Technisch correcte permissies zijn niet automatisch begrijpelijk. Gebruikers kiezen vaak de meest uitgebreide rol om zeker te zijn dat iets werkt, zonder precies te weten wat ze mogelijk maken.

Gevolg: te brede toegang, onbedoelde wijzigingen en audit-logs die niemand kan uitleggen. Als rechten niet begrijpelijk zijn, wordt least privilege in de praktijk nauwelijks toegepast.

Het risico van technische rolbenamingen

Wanneer rolbenamingen intern technisch zijn opgebouwd, ontstaan twee bekende problemen:

Over-toekenning

"Voor de zekerheid geef ik maar volledige rechten, anders werkt het misschien niet."

Onzekerheid

"Ik weet niet wat Group 4 betekent, dus ik laat de oude rechten maar staan."

Beide scenario's zijn risicovol in publieke omgevingen waar dataminimalisatie en uitlegbaarheid essentieel zijn.

Secure-by-design principe

Begrijpelijkheid is zelf een beveiligingsmaatregel. Rechtenbeheer moet:

  • Beschrijven wat iemand kan doen, niet hoe het technisch heet.
  • Verschillen tussen niveaus duidelijk maken.
  • De veiligste optie als standaard tonen.
  • Extra rechten expliciet laten voelen als risicovoller.
  • Altijd zichtbaar maken wie wat mag.

Functiegebaseerde toegang (RBAC)

In overheden worden rechten gekoppeld aan rollen, niet aan individuen. Zo blijft toegang herhaalbaar, uitlegbaar en beheersbaar bij functiewisselingen.

Voorbeelden van rollen:

  • dossierhouder
  • behandelaar
  • beheerder

Dit voorkomt structurele over-toekenning en beperkt afhankelijkheid van persoonsgebonden uitzonderingen.

Praktische UI-patronen

1. Rollen beschrijven in actie-taal

Gebruik werkwoorden, geen systeemtermen.

Niet doen
Editor-Level-3
Admin-ACL-Restricted
User_Group_Write
Wel doen
Alleen-lezen
Bewerken
Beheren

2. Toon wat een rol concreet betekent

Onder elke rol staat in gewone taal wat de consequenties zijn.

Bewerken
  • Inhoud van documenten aanpassen
  • Nieuwe versies uploaden
  • Rechten van anderen wijzigen

3. Highlight risicovolle rollen

Wanneer iemand Beheren kiest, toon directe context zonder dreigende toon.

Let op: Met de rol Beheren kan deze gebruiker ook andere personen toegang geven of documenten permanent verwijderen.

Toekenning of wijziging van Beheren wordt vastgelegd in het auditlogboek.

4. Houd rechten zichtbaar in de interface

Rechten zijn geen verborgen systeemlaag. Toon bij elk dossier of map:

  • Wie toegang heeft
  • Met welk niveau
  • Intern of extern bereik

5. Tijdelijke toegang voor ketensamenwerking

Externe partners krijgen tijdelijke toegang die automatisch verloopt. Dit voorkomt langdurige blootstelling van overheidsinformatie en houdt samenwerking werkbaar.

Least privilege zonder frustratie

Veel organisaties vrezen dat least privilege (minimale rechten) het werk vertraagt. Dat gebeurt vooral als rollen te granular of moeilijk aanpasbaar zijn.

De oplossing:

Maak rollen taakgericht: groepeer permissies die logisch bij een taak horen.

Bied tijdelijke uitbreiding: bijvoorbeeld bewerkrechten voor 24 uur of ketentoegang voor externe partners die automatisch verloopt.

Maak opschalen bewust maar eenvoudig: verhoogde rechten krijgen een expliciete stap met duidelijke impact.

Risico dat je hiermee voorkomt

  • Over-toekenning van Beheren of Bewerken zonder noodzaak.
  • Onduidelijkheid bij audits over wie wat mocht.

Wanneer niet gebruiken (anti-pattern)

  • Gebruik geen technische rolcodes in de UI, zoals RBAC-ADMIN-LEVEL-3.
  • Gebruik consequent: Alleen-lezen, Bewerken, Beheren.
  • Technische termen blijven backend, niet in de gebruikersinterface.

Implementatie & Design System

Rechtenbeheer in mensentaal vereist een vertaalslag. In de backend blijft bijvoorbeeld ROLE_ID_99 bestaan, terwijl de interface "Beheren" toont.

Component suggesties

<RoleSelector />
<PermissionSummary />
<AccessOverviewTable />
<RecommendedBadge />

Relevantie voor overheidsorganisaties

Overheden werken met dossiers, persoonsgegevens en ketensamenwerkingen. Te brede rechten vergroten het risico op datalekken, ongeautoriseerde verspreiding en reputatieschade.

Begrijpelijk rechtenbeheer verlaagt dit risico zonder dienstverlening te vertragen. Beveiliging begint niet pas bij encryptie, maar bij begrijpelijkheid in de UI.

Koppel rechten aan functies in plaats van personen, laat externe ketentoegang automatisch verlopen en log toekenning of wijziging van Beheren als audit-event.

Gerelateerde Secure-by-design patronen

Verdiep dit onderwerp verder via gerelateerde patronen binnen de secure-by-design portal.

Rechtenbeheer verbeteren in jullie portalen?

Ik help teams met heldere rolmodellen en secure-by-design interactiepatronen die echt worden gebruikt.