RBAC vs ABAC voor interne tools: toegangsrechten die meeschalen

Waarom permissies in interne tools rommelig worden

Interne tools zitten dicht bij de gevoeligste onderdelen van een bedrijf: klantendossiers, refunds, facturen, salarisnotities, deal‑waardes en privé‑interne opmerkingen. Niet iedereen zou alles moeten kunnen zien en nog minder mensen zouden alles moeten kunnen bewerken.

Permissies beginnen meestal eenvoudig: “Support kan tickets bekijken”, “Finance kan refunds goedkeuren”, “Managers kunnen teamresultaten zien.” Daarna groeit de organisatie, veranderen processen en wordt het systeem een lappendeken van uitzonderingen.

Dat patroon van “loopt later uit de hand” komt vaak voor:

• Roluitbreiding: je voegt Support toe, daarna Support - Senior, dan Support - EU, dan Support - EU - Night Shift, totdat niemand meer weet wat elke rol precies omvat.
• Uitzonderings‑groei: een paar mensen hebben “net één extra permissie” nodig, dus stapels eenmalige toggles ontstaan.
• Per ongeluk blootstelling: iemand kan salarisnotities, klant‑PII of omzetrapporten zien omdat een scherm hergebruikt werd zonder toegang te checken.
• Gebroken workflows: een gebruiker kan een record zien maar kan niet de volgende stap nemen (of erger, kan de stap wél nemen zonder de context te zien).
• Pijnlijke audits: het is lastig om “Wie kan refunds boven $1.000 goedkeuren?” te beantwoorden zonder handmatig te graven.

Het doel van vroeg kiezen tussen RBAC of ABAC is niet alleen om schermen dicht te timmeren. Het is om regels begrijpelijk te houden wanneer nieuwe teams, regio’s en beleidsregels verschijnen.

Een permissiemodel dat standhoudt heeft vier eigenschappen: het is makkelijk uit te leggen, eenvoudig te reviewen, moeilijk te misbruiken en snel aan te passen.

RBAC in gewone taal (rollen en wat ze vrijgeven)

RBAC (role‑based access control) is de “functietitelbenadering”. Een gebruiker krijgt één of meer rollen (Support Agent, Admin). Elke rol heeft een vaste set dingen die die rol mag zien en doen. Als twee mensen dezelfde rol delen, krijgen ze dezelfde toegang.

RBAC werkt goed wanneer teams grotendeels hetzelfde werken en de belangrijkste vragen op feature‑niveau zijn: “Kunnen ze dit scherm gebruiken?” of “Kunnen ze deze actie uitvoeren?”

Voorbeelden van rollen in een supportconsole:

• Support Agent: tickets bekijken, op klanten reageren, interne notities toevoegen
• Support Lead: alles wat een agent kan, plus tickets herverdelen en teammetrics bekijken
• Admin: gebruikers beheren, systeeminstellingen wijzigen, permissieregels bewerken

Het kernidee is dat rollen aan verantwoordelijkheden worden gekoppeld, niet aan specifieke personen. Wanneer verantwoordelijkheden stabiel zijn, blijven rollen stabiel en blijft het model makkelijk uit te leggen.

RBAC past goed wanneer:

• De organisatiestructuur duidelijk is (teams, leads, admins)
• De meeste toegangsbeslissingen zijn: “mag deze feature gebruikt worden?”
• Onboarding voorspelbaar moet zijn (rol X toewijzen en je bent klaar)
• Audits belangrijk zijn (het is makkelijk op te sommen wat een rol kan)

Waar RBAC begint te wringen is wanneer de realiteit rommelig wordt. Interne tools verzamelen uitzonderingen: een supportagent die refunds kan doen, een finance‑gebruiker die alleen één regio mag zien, een contractor die tickets kan zien maar geen klant‑PII. Als je elke uitzondering oplost door een nieuwe rol te maken, krijg je rolexplosie.

Een praktisch signaal dat RBAC alleen faalt: je begint elke week “speciale rollen” toe te voegen.

ABAC in gewone taal (regels gebaseerd op attributen)

ABAC (attribute‑based access control) beslist toegang met behulp van regels, niet alleen functietitels. In plaats van “Wat mag de Finance‑rol?” vraagt ABAC: “Gegeven wie deze persoon is, wat dit record is en wat er op dit moment gebeurt, mogen we het toestaan?”

Attributen zijn feiten die je al bijhoudt. Een regel kan bijvoorbeeld zeggen:

• “Supportagents mogen tickets in hun regio bekijken.”
• “Managers mogen uitgaven goedkeuren onder €5.000 tijdens kantooruren.”

De meeste ABAC‑systemen gebruiken een paar attributencategorieën:

• Gebruikersattributen: afdeling, regio, managerstatus
• Data‑attributen: record‑eigenaar, ticketprioriteit, factuurstatus
• Contextattributen: tijd van de dag, apparaattype, netwerklocatie
• Actieattributen: view versus edit versus export

Concreet voorbeeld: een supportagent mag een ticket alleen bewerken als (a) de ticketprioriteit niet kritisch is, (b) het ticket aan hen is toegewezen en (c) de klantregio overeenkomt met hun regio. Je voorkomt dat je rollen als Support - EU - Noncritical en Support - US - Noncritical moet maken.

Het keerpunt is dat ABAC moeilijk te begrijpen kan worden als uitzonderingen blijven opstapelen. Na een paar maanden stopt men met het eenvoudig beantwoorden van vragen als “Wie kan facturen exporteren?” zonder een lange keten van voorwaarden door te lezen.

Een goede ABAC‑gewoonte is regels klein, consistent en met duidelijke namen te houden.

Record‑niveau toegang: waar de meeste fouten gebeuren

Veel teams behandelen permissies als “mag je dit scherm openen?” Dat is slechts de eerste laag. Record‑niveau toegang beantwoordt een andere vraag: zelfs als je het scherm kunt openen, welke rijen mag je dan zien of wijzigen?

Een supportagent en een finance‑analist kunnen allebei de Klanten‑pagina openen. Als je bij schermniveau stopt, loop je het risico iedereen alles te tonen. Record‑niveau regels beperken welke data binnen die pagina wordt geladen.

Veelvoorkomende record‑niveau regels zijn:

• Alleen jouw klanten (assigned_owner_id = current_user.id)
• Alleen jouw regio (customer.region IN current_user.allowed_regions)
• Alleen jouw cost center (invoice.cost_center_id IN current_user.cost_centers)
• Alleen tickets van je team (ticket.team_id = current_user.team_id)
• Alleen records die je zelf hebt aangemaakt (created_by = current_user.id)

Record‑niveau toegang moet worden afgedwongen waar data wordt opgehaald en gewijzigd, niet alleen in de UI. In de praktijk betekent dat op query‑laag, API‑endpoints en in de businesslogica.

Een typisch faalpatroon is “vergrendelde pagina, open API.” Een knop wordt voor niet‑admins verborgen, maar het endpoint retourneert nog steeds alle records. Iedereen met toegang tot de app kan soms die call hergebruiken door een request opnieuw te versturen of een filter aan te passen.

Controleer je model met een paar vragen:

• Als een gebruiker het endpoint direct aanroept, krijgt hij dan nog steeds alleen toegestane records?
• Passen list-, detail-, export‑ en count‑endpoints dezelfde regels toe?
• Worden create, update en delete apart gecontroleerd (niet alleen read)?
• Omzeilen admins regels opzettelijk, of per ongeluk?

Schermpermissies bepalen wie een ruimte mag betreden. Record‑niveau toegang bepaalt welke laatjes ze binnenin mogen openen.

Echte voorbeelden: support, finance en managers

Het doel is niet “perfecte beveiliging.” Het is permissies die mensen vandaag kunnen begrijpen en die je later kunt aanpassen zonder workflows te breken.

Support team

Support heeft meestal record‑niveau regels nodig, want “alle tickets” is zelden waar.

Een simpel model: agents mogen tickets openen en updaten die aan hen toegewezen zijn, plus alles in hun queue. Teamleads mogen tickets herverdelen en bij escalaties ingrijpen. Managers hebben vaak dashboards nodig zonder de mogelijkheid elk ticket te bewerken.

Bulkacties en exports zijn de gebruikelijke twist. Veel teams staan bulk‑sluiten toe, beperken bulk‑herverdeling en beperken exports tot leads en managers met logging.

Finance team

Finance‑toegang draait vooral om goedkeuringsstappen en een schoon auditspoor.

Een veelgebruikte opzet: een AP‑clerk kan facturen aanmaken en concepten opslaan, maar niet goedkeuren of betalen. Een controller kan goedkeuren en betalingen vrijgeven. Auditors horen read‑only te zijn, inclusief bijlagen, zonder mogelijkheid vendorgegevens te wijzigen.

Een realistische regel is: “AP‑clerks mogen concepten bewerken die zij hebben aangemaakt; zodra ingediend, mogen alleen controllers ze wijzigen.” Dat is record‑niveau toegang (status + eigenaar) en past vaak beter bij ABAC dan bij het aanmaken van meer rollen.

Managers

De meeste managers hebben brede zichtbaarheid maar beperkte bewerkingsmacht.

Een praktisch patroon: managers kunnen de meeste operationele data bekijken, maar alleen records bewerken die van hun team of directe rapporten zijn (verlofaanvragen, doelen, prestatie‑notities). Attributen zoals team_id, manager_id en employment_status zijn vaak duidelijker dan het maken van een aparte rol voor elke afdeling.

Over deze groepen heb je meestal nodig:

• Support: zichtbaarheid op basis van toewijzing/queue, strikte exports, gecontroleerde herverdeling
• Finance: regels op basis van status (concept vs ingediend vs goedgekeurd), strikte goedkeuringen, audit‑veilige read‑only toegang
• Managers: breed bekijken, beperkt bewerken (team‑ of directe‑report records)

Beslismatrix: rollen vs attributen vs record‑niveau regels

In plaats van te debatteren “wat is beter”, vraag welke onderdelen van je toegangsprobleem bij elk model passen. De meeste teams eindigen met een hybride: rollen voor brede toegang, attributen voor uitzonderingen en record‑niveau filters voor "alleen mijn items".

Behandel permissielogica als een maandelijkse rekening. Elke extra rol, regel en uitzondering kost tijd om te testen, uit te leggen en debuggen. Besteed de minste inspanning die de echte scenario’s van vandaag dekt.

Een praktisch standaardpatroon:

• Begin met RBAC voor brede banen (Support, Finance, Manager).
• Voeg ABAC toe voor terugkerende condities (regio, senioriteit, klanttier).
• Voeg record‑niveau regels toe wanneer gebruikers “hun” items moeten zien, niet de hele tabel.

Stap voor stap: ontwerp permissies voordat je schermen bouwt

Als je permissies beslist nadat de UI klaar is, eindig je meestal met te veel rollen of een stapel uitzonderingen. Een eenvoudig plan voorkomt constante herbouw.

1) Begin met acties, niet met schermen

Schrijf op wat mensen echt doen in elke workflow:

• View (lezen)
• Create (aanmaken)
• Edit (bewerken)
• Approve (goedkeuren)
• Export
• Delete (verwijderen)

In een refundsflow is Approve niet hetzelfde als Edit. Die ene onderscheiding bepaalt vaak of je een strikte regel of slechts een rol nodig hebt.

2) Definieer rollen die bij functietitels passen

Kies rollen die mensen herkennen zonder vergadering: Support Agent, Support Lead, Finance Analyst, Finance Manager, Auditor, Admin. Vermijd rollen als “Support Agent - Can edit VIP notes.” Die exploderen snel.

3) Maak een lijst van attributen die echte uitzonderingen veroorzaken

Voeg ABAC alleen toe als het echt iets oplevert. Typische attributen zijn regio, team, klanttier, ownership en bedrag.

Als een uitzondering minder dan eens per maand voorkomt, overweeg dan een handmatige goedkeuring in plaats van een permanente permissieregel.

4) Schrijf record‑niveau regels als eén‑zin beleid

Record‑niveau toegang is waar de meeste interne tools breken. Schrijf regels die je aan een niet‑technische manager kunt laten zien:

“Support Agents mogen tickets in hun regio bekijken.”

“Finance Analysts mogen facturen bewerken die zij hebben aangemaakt totdat ze goedgekeurd zijn.”

“Managers mogen refunds boven €500 alleen voor hun team goedkeuren.”

Als je een regel niet in één zin kunt uitdrukken, heeft het proces waarschijnlijk verduidelijking nodig.

5) Test met vijf echte mensen vóór je bouwt

Loop echte scenario’s door:

• Een supportagent die een VIP‑klant behandelt
• Een finance‑analist die een factuur corrigeert
• Een manager die een grote refund goedkeurt
• Een admin die onderhoud uitvoert
• Een auditor die geschiedenis moet zien maar niets mag veranderen

Los verwarring hier op, voordat het uitgroeit tot een permissiemoeras.

Veelvoorkomende valkuilen (en hoe ze te vermijden)

De meeste permissiefouten komen niet doordat je RBAC of ABAC kiest. Ze ontstaan wanneer kleine uitzonderingen zich opstapelen totdat niemand nog kan uitleggen wie wat mag en waarom.

Rolexplosie begint meestal met “Support Lead heeft één extra knop nodig” en groeit dan naar 25 rollen die in één permissie verschillen. Houd rollen breed (taak‑gericht) en gebruik een klein aantal regelgebaseerde uitzonderingen voor terugkerende randgevallen.

Onleesbare attributelogica is de ABAC‑variant van hetzelfde probleem. Als je voorwaarden hebt als “department == X AND region != Y” verspreid over alles, veranderen audits in giswerk. Gebruik benoemde policies (zelfs als dat alleen consistente labels in een gedeeld document zijn) zodat je kunt zeggen “RefundApproval‑policy” in plaats van een formule te ontcijferen.

Exports, rapporten en bulkacties zijn plekken waar lekkages ontstaan. Teams vergrendelen een recordview, en vergeten dan dat Export CSV of bulk‑update dezelfde controles kan omzeilen. Behandel elk niet‑schermpad als een volwaardige actie met eigen permissiechecks.

Valkuilen om in de gaten te houden:

• Een nieuwe rol voor elke uitzondering
• Attribuutregels die moeilijk te lezen of onbenoemd zijn
• Exports, geplande rapporten en bulkacties die checks overslaan
• Verschillende tools die dezelfde toegangsvraag verschillend beantwoorden
• Record‑niveau regels die op de ene plek worden toegepast maar niet op een andere

De veiligste oplossing is één bron van waarheid voor rollen, attributen en record‑niveau regels, consequent afgedwongen in je backendlogica.

Snelle checklist vóór je live gaat

Als je model moeilijk uit te leggen is, wordt het ook moeilijker te debuggen als iemand zegt: “Ik zou die klant moeten kunnen zien” of “Waarom kan die persoon dit exporteren?”

Vijf checks die de meeste verrassingen vangen:

• Kan een echte gebruiker hun toegang in één zin beschrijven (bijvoorbeeld: “Ik ben Support, regio = EU, ik kan tickets voor mijn regio bekijken maar ik kan niet exporteren”)? Zo niet, dan zijn regels waarschijnlijk te verspreid.
• Heb je een expliciet antwoord op “wie mag exporteren?” en “wie mag goedkeuren?” Behandel export en goedkeuring als hoogrisico acties.
• Worden record‑niveau regels overal afgedwongen waar data wordt opgehaald (API‑endpoints, rapporten, background jobs), niet alleen door knoppen te verbergen?
• Is de standaard veilig voor gevoelige acties (deny by default)? Nieuwe rollen, attributen en schermen mogen niet per ongeluk krachtige permissies erven.
• Kun je in minder dan een minuut antwoorden op “Wie kan dit specifieke record zien en waarom?” met één bron van waarheid (rol, attributen en het ownership/status van het record)?

Voorbeeld: Finance mag alle facturen bekijken, maar alleen Approvers kunnen goedkeuren en alleen Managers kunnen een volledige vendorlijst exporteren. Support mag tickets bekijken, maar alleen het team van de ticket‑eigenaar mag interne notities zien.

Permissies veranderen zonder alles te breken

Permissies veranderen om saaie redenen: een nieuwe manager begint, finance splitst in AP en AR, of het bedrijf neemt een team over. Plan voor verandering zodat updates klein, omkeerbaar en makkelijk te reviewen zijn.

Vermijd het koppelen van toegang aan één grote “superrol.” Voeg nieuwe toegang toe als een nieuwe rol, een nieuw attribuut of een smalle recordregel en test het tegen echte taken.

Toegang toevoegen zonder alles te herontwerpen

Wanneer er een nieuwe afdeling ontstaat (of bij een fusie), houd kernrollen stabiel en voeg lagen daaromheen toe.

• Houd basisrollen beperkt (Support, Finance, Manager) en voeg kleine add‑ons toe (Refunds, Export, Approvals).
• Geef de voorkeur aan attributen voor organisatieveranderingen (team, regio, cost center) zodat nieuwe groepen geen nieuwe rollen nodig hebben.
• Gebruik record‑niveau regels voor ownership en toewijzing (ticket.assignee_id, invoice.cost_center).
• Voeg een goedkeuringsstap toe voor gevoelige acties (uitbetalingen, afschrijvingen).
• Behandel export vrijwel overal als een eigen permissie.

Tijdelijke toegang mag geen permanente rolwijziging vereisen. Voor vervanging of incidenten gebruik je tijdsgebonden toestemmingen: “Finance Approver voor 48 uur”, met een einddatum en verplichte reden.

Auditritme en logkwaliteit

Gebruik een eenvoudige reviewcadans: maandelijks voor hoogrisico permissies (geld, exports), per kwartaal voor de rest en na elke reorg of fusie.

Log genoeg om te kunnen beantwoorden wie wat deed, welk record en waarom het toegestaan was:

• Wie heeft bekeken, bewerkt, goedgekeurd of geëxporteerd
• Wanneer het gebeurde (en vanwaar als je dat opvangt)
• Welk record is aangeraakt (IDs, type, voor/na bij bewerkingen)
• Waarom het was toegestaan (rol, attributen, recordregel, tijdelijke grant)
• Wie toegang heeft verleend (en wanneer het verloopt)

Volgende stappen: implementeer een model dat je kunt onderhouden

Begin met een klein, saai permissiemodel. Dat overleeft zes maanden verandering.

Een goed startpunt is simpele RBAC: een handvol rollen die echte functietaken weerspiegelen (Support Agent, Support Lead, Finance, Manager, Admin). Gebruik die rollen om grote deuren te regelen zoals welke schermen bestaan, welke acties beschikbaar zijn en welke workflows gestart mogen worden.

Voeg ABAC alleen toe wanneer je steeds dezelfde echte uitzonderingen ziet. Als de enige reden voor ABAC is “het kan later handig zijn”, wacht dan. ABAC blinkt uit wanneer condities ertoe doen (bedragen, regiobeperkingen, ownership, status), maar het vereist zorgvuldige tests en duidelijke eigenaren.

Schrijf regels eerst als plain‑sentences. Als je een regel niet in één zin kunt zeggen, wordt die moeilijk te onderhouden.

Als je snel wilt piloten in een echte interne tool, kan een no-code platform zoals AppMaster (appmaster.io) je helpen rollen, data‑velden zoals owner/team/status en backend‑afgedwongen workflows vroeg te modelleren, voordat UI‑beslissingen risicovolle aannames inbakken.