Een permissiematrix helpt rollen, scopes en uitzonderingen in kaart te brengen voordat je schermen en API's bouwt, waardoor herwerk en toegangsproblemen later verminderen.
Een intern hulpmiddel is de software die je team dagelijks gebruikt om het bedrijf te runnen. Denk aan adminpanelen, operations-dashboards, supportconsoles, financiële beoordelingsschermen en de kleine apps die mensen helpen werk goed te keuren, data te herstellen of op klanten te reageren.
Deze tools raken gevoelige data en bieden krachtige acties. Een supportmedewerker moet misschien een klantprofiel kunnen bekijken maar nooit volledige betaalgegevens zien. Een finance-medewerker kan facturen exporteren maar zou accountinstellingen niet mogen aanpassen. Een ops-lead kan beide doen, maar alleen voor zijn of haar regio.
Permissies worden snel ingewikkeld omdat interne tools in lagen groeien. Nieuwe rollen verschijnen, oude rollen splitsen, en losse uitzonderingen stapelen zich op: “Sta Maria toe om terug te betalen”, “Blokkeer externe krachten voor notities”, “Laat teamleads alleen goedkeuren tot €500”. Als die regels alleen in hoofden leven (of verspreid in tickets), drijven schermen en API-eindpunten uit elkaar en ontstaan er beveiligingslekken.
Een permissiematrixontwerp lost dit op door een enkele, gedeelde kaart te maken van wie wat mag doen, op welke data en met welke beperkingen. Het wordt de bron van waarheid voor zowel UI-beslissingen (welke schermen, knoppen en velden zichtbaar zijn) als backend-beslissingen (wat de server echt toestaat, ook als iemand de UI probeert te omzeilen).
Het is niet alleen voor ontwikkelaars. Een goede matrix is een werkend document waar product, operations en bouwers samen overeenstemming over hebben. Als je bouwt met een no-code platform zoals AppMaster is de matrix nog steeds essentieel: hij stuurt hoe je rollen instelt, resources definieert en visuele schermen en gegenereerde endpoints consistent houdt.
Een eenvoudige matrix helpt je om:
Goed permissiematrixontwerp begint met gedeelde terminologie. Als je team deze termen hetzelfde gebruikt, voorkom je rommelige regels later.
Een rol is een op werk gebaseerde groep mensen die meestal dezelfde toegang nodig hebben. Denk aan Support, Finance, Ops of Manager. Rollen moeten beschrijven wat iemand de meeste dagen doet, niet hun senioriteit. Eén persoon kan meerdere rollen hebben, maar houd dat zeldzaam.
Een resource is het ding dat je beschermt. In interne tools zijn veelvoorkomende resources klanten, tickets, facturen, rapporten, integraties en instellingen. Geef resources naam als zelfstandige naamwoorden. Dit helpt later wanneer je regels omzet naar schermen en API-eindpunten.
Een actie is wat iemand met een resource kan doen. Houd de werkwoorden consistent zodat de matrix leesbaar blijft. Typische acties zijn:
Een scope beantwoordt de vraag “welke records?” zonder meer rollen te maken. Scopes bepalen vaak het verschil tussen veilige en onveilige toegang. Veelvoorkomende scopes zijn:
Een uitzondering is een override die de normale rol- en scoperegels doorbreekt. Uitzonderingen kunnen tijdelijk zijn (bij een dienst), gebruiker-specifiek (een specialist heeft één extra actie nodig) of record-specifiek (een VIP-klantrecord is afgeschermd). Behandel uitzonderingen als gecontroleerde schuld: registreer wie ze goedkeurde, waarom ze bestaan en wanneer ze verlopen.
Voorbeeld: een supportmedewerker mag “tickets bekijken” met scope “team”, maar krijgt een kortlopende uitzondering om “tickets te exporteren” voor één incidentreview. In een tool gebouwd met AppMaster is dit soort regel veel makkelijker te onderhouden als je rollen, resources, acties en scopes vanaf het begin consequent benoemt.
Begin met overeenstemming over wat je eigenlijk beschermt. Noteer de gebieden van het interne hulpmiddel als resources, niet als schermen. Een scherm kan tegelijk “Orders”, “Terugbetalingen” en “Klanten” tonen, maar dat zijn verschillende resources met verschillende risico’s.
Standaardiseer je actie-werkwoorden voordat je een enkele permissie schrijft. Kleine woordverschillen creëren later dubbele regels (edit vs update, remove vs delete, view vs read). Kies een korte, gedeelde set en houd die vast voor elk resource. Voor de meeste interne tools is een eenvoudige set als view, create, update, delete, approve, export voldoende.
Scopes zijn de volgende beslissing en ze moeten passen bij hoe je organisatie al denkt. Te veel scopes maken de matrix onleesbaar; te weinig veroorzaken constante uitzonderingen. Streef naar een kleine set die bij je organisatie past, zoals:
Je hebt ook een duidelijke regel voor “nee” nodig. Beslis wat expliciet verboden is versus impliciet geweigerd. Impliciet weigeren (alles wat niet is vermeld is geweigerd) is veiliger en eenvoudiger. Expliciet verbieden is nuttig als je brede toegang hebt maar een specifieke actie wilt blokkeren, zoals “Finance kan alle facturen openen behalve delete”.
Markeer ten slotte compliance-gevoelige acties vroeg, voordat ze begraven raken in het raster. Exports, deletions, payouts, rolwijzigingen en toegang tot persoonlijke data verdienen extra aandacht, logging en vaak een goedkeuringsstap. Bijvoorbeeld: je laat een supportlead mogelijk een klantprofiel bijwerken, maar vereist finance-goedkeuring voordat een uitbetaling wordt aangemaakt of geëxporteerd.
Als je in AppMaster bouwt, mappen deze beslissingen later netjes naar backend-eindpunten en Business Process-logica, maar de matrix moet eerst duidelijk zijn.
Begin met het werk dat mensen doen, niet met de schermen die je wilt bouwen. Als je bij schermen begint, kopieer je de huidige UI en mis je de echte regels (zoals wie terugbetalingen kan goedkeuren, of wie een klantrecord mag bewerken nadat het is vergrendeld).
Een eenvoudige manier om permissiematrixontwerp te doen is het behandelen als een kaart van taken naar toegang, en die later naar je app te converteren.
Maak een lijst van zakelijke taken in gewone taal. Voorbeeld: “Een terugbetaling uitvoeren”, “Het e-mailadres van een klant wijzigen”, “Facturen van vorige maand exporteren”. Houd het kort en reëel.
Zet taken om in resources en acties. Resources zijn zelfstandige naamwoorden (Invoice, Ticket, Customer), acties zijn werkwoorden (view, create, edit, approve, export). Wijs een eigenaar toe voor elke resource: één persoon die randgevallen kan uitleggen en zegt “ja, dat is correct”.
Definieer rollen op basis van stabiele teams. Gebruik groepen als Support, Finance, Operations, Team Lead. Vermijd titels die vaak veranderen (Senior, Junior) tenzij die echt toegang veranderen.
Vul de matrix met de minimale toegang die elke rol nodig heeft om taken uit te voeren. Als Support alleen facturen hoeft te bekijken om vragen te beantwoorden, geef niet standaard “export” toe. Je kunt later altijd toegang toevoegen, maar het later weer verwijderen doorbreekt gewoonten.
Voeg scopes alleen toe waar het echt belangrijk is. In plaats van één enkele “edit” permissie, noteer scopes zoals “edit own”, “edit assigned” of “edit all”. Dit houdt regels duidelijk zonder 50 rollen te maken.
Leg uitzonderingen vast in een aparte tabel, niet als rommelige notities in de matrix. Elke uitzondering heeft een duidelijk redenveld (compliance, fraude, scheiding van taken) en één eigenaar die het goedkeurt.
Als dit klaar is, maken tools zoals AppMaster het eenvoudiger om de matrix om te zetten in beschermde endpoints en admin-schermen zonder tijdens het bouwen te moeten raden wat de regels zijn.
Een permissiematrix is alleen nuttig als mensen hem snel kunnen lezen. Als het een enorme muur van cellen wordt, stopt het team met gebruiken en drijven permissies af van wat je bedoeld hebt.
Begin met het splitsen van de matrix per domein. In plaats van één sheet voor alles, gebruik één tab per bedrijfsgebied, zoals Customers, Billing en Content. De meeste rollen raken maar een paar domeinen, dus dit houdt reviews snel en vermindert per ongeluk wijzigen.
Gebruik een naamgevingspatroon dat consistent blijft over tabs. Een simpel format als Resource.Action.Scope maakt direct duidelijk wat elke permissie betekent en voorkomt duplicaten die er anders uitzien maar hetzelfde betekenen. Bijvoorbeeld, Invoice.Approve.Department leest hetzelfde als Customer.Edit.Own.
Als je op een randgeval stuit, weersta de verleiding om een nieuwe rol te maken. Voeg een korte nota naast de cel toe die de uitzondering en de toepassingsduur beschrijft. Voorbeeld: Support kan facturen bekijken, maar alleen nadat de klant identiteit heeft geverifieerd. De nota kan ook wijzen op de extra UI-stap die nodig is, zonder het rolmodel te veranderen.
Markeer hoog-risico permissies zodat ze opvallen tijdens reviews. Dit zijn acties zoals refunds, approvals, exports en verwijderen van data. Markeer de cellen en beschrijf welke extra controle vereist is, zoals tweepersonen-goedkeuring of managerbevestiging.
Om permissiematrixontwerp onderhoudbaar te houden, versieer het als een echt artefact:
Als de matrix stabiel is, is het veel eenvoudiger om schermen en endpoints in een tool als AppMaster te bouwen, omdat elke knop en API-actie naar een duidelijke permissienaam verwijst.
Een permissiematrixontwerp is alleen nuttig als het echte regels wordt op twee plaatsen: je API en je UI. Behandel elk resource in de matrix (zoals Tickets, Invoices, Users) als een endpointgroep. Houd de acties in lijn met je matrix-werkwoorden: view, create, edit, approve, export, delete.
Aan de API-kant, handhaaf permissies bij elk verzoek. UI-controles zijn nuttig voor duidelijkheid, maar geen beveiliging. Een verborgen knop stopt geen directe API-aanroep.
Een eenvoudige manier om de matrix naar API-permissies te vertalen is permissies consequent te benoemen en ze vast te zetten op de grens waar de actie plaatsvindt:
Gebruik vervolgens dezelfde permissienamen om UI-gates aan te sturen: menu-items, paginatoegang, knoppen en zelfs velden. Bijvoorbeeld, een Support-agent ziet de Ticketlijst en kan een ticket openen, maar het veld “Refund” is alleen bewerkbaar als die persoon ook invoices:approve heeft.
Wees voorzichtig met lijst- versus detailtoegang. Teams hebben vaak “willen zien dat iets bestaat” zonder het record zelf te mogen bekijken. Dat betekent dat je mogelijk lijstresultaten toelaat met beperkte kolommen, maar het openen van de detailweergave blokkeert tenzij de gebruiker detailpermissie heeft (of een scope-check zoals “toegevoegd aan mij” doorstaat). Beslis dit vroeg zodat je geen lijstscherm bouwt dat gevoelige data lekt.
Koppel audit-logging aan acties die ertoe doen. Export, delete, approve, rolwijzigingen en data-downloads moeten audit-events aanmaken met wie, wat, wanneer en het doelrecord. Als je in AppMaster bouwt, kun je dit terug laten komen in endpointlogica en business process flow zodat dezelfde regel zowel de actie als de audit-trigger uitvoert.
De snelste manier om permissiematrixontwerp te breken is het UI-model te volgen in plaats van het bedrijfsmodel. Een scherm kan meerdere dingen tonen, en hetzelfde ding kan op meerdere schermen verschijnen. Als je elk scherm als aparte resource behandelt, dupliceer je regels, mis je randgevallen en discussieer je over naamgeving in plaats van toegang.
Een andere valkuil is rol-sprawl. Teams blijven rollen toevoegen (Support Level 1, Support Level 2, Support Manager, enz.) terwijl een kleinere set rollen plus duidelijke scopes vaak voldoende is. Scopes zoals “own team”, “assigned region” of “accounts die je beheert” leggen verschillen meestal beter uit dan een nieuwe rol.
Enkele fouten die vaak voorkomen in echte interne tools:
Uitzonderingen verdienen speciale voorzichtigheid. Ze zijn nuttig voor tijdelijke situaties, maar moeten verlopen of worden herzien. Als uitzonderingen blijven groeien, is dat een teken dat je rollen of scopes niet goed gemapt zijn.
Een snel voorbeeld: in een support- en finance-tool kan Support klantprofielen bekijken en tickets aanmaken, maar Finance kan facturen exporteren en terugbetalingen uitvoeren. Als je alleen pagina's beveiligt, kan een Support-agent nog steeds direct een export-endpoint aanroepen. Of je nu met custom code bouwt of met een platform zoals AppMaster dat backend-eindpunten genereert, de regel moet server-side leven, niet alleen in de UI.
Een permissiematrix is alleen nuttig als hij in duidelijke, afdwingbare regels verandert. Loop deze checklist door voordat je je eerste scherm of endpoint maakt. Het helpt je “bijna veilig” situaties te vermijden die breken zodra er een nieuwe rol of randgeval verschijnt.
Begin met een default-deny mindset: alles wat niet expliciet is toegestaan, is geblokkeerd. Dit is de veiligste basis en voorkomt verrassende toegang wanneer je later functies toevoegt.
Zorg dat je één bron van waarheid voor permissies hebt. Of het nu in een document, een tabel in je database of je no-code configuratie staat, iedereen in het team moet weten waar de huidige regels zijn. Als de spreadsheet iets anders zegt dan de app, ontstaan er bugs.
Hier is een compacte pre-build checklist voor permissiematrixontwerp:
Controleer daarna de regels met één realistisch scenario. Bijvoorbeeld: “Een supportagent kan een bestelling bekijken en een notitie toevoegen voor zijn regio, maar mag geen prijzen bewerken of terugbetalingen uitvoeren. Finance kan terugbetalingen uitvoeren, maar alleen na managergoedkeuring en elke terugbetaling wordt gelogd.” Als je het niet in één of twee zinnen kunt zeggen, zijn je scopes en uitzonderingen nog niet duidelijk.
Als je in AppMaster bouwt, behandel deze items als eisen voor zowel je schermen als je businesslogica, niet alleen de UI. Knoppen kunnen acties verbergen, maar alleen backend-regels handhaven ze echt.
Stel je een middelgroot bedrijf voor met één intern hulpmiddel dat door Support en Finance wordt gebruikt. Dezelfde database bevat Customers, Tickets, Refunds, Payouts en een kleine Settings-ruimte (zoals templates en integraties). Dit is het soort app waar een eenvoudige logincheck niet voldoende is.
Hier zijn de rollen waarmee ze beginnen:
Een praktisch permissiematrixontwerp begint met acties per resource op te schrijven en die vervolgens aan te scherpen met scopes.
Voor Tickets mogen Support Agents tickets bekijken en de status bijwerken, maar alleen voor tickets in hun toegewezen queue. Ze kunnen notities toevoegen, maar mogen de ticket-eigenaar niet wijzigen. Support Leads kunnen alles wat een Support Agent kan, plus tickets binnen hun regio herverdelen.
Voor Refunds kan Finance terugbetalingen aanmaken en goedkeuren, maar alleen tot een vastgesteld bedrag. Support kan een terugbetalingsverzoek aanmaken, maar niet goedkeuren. Refund-goedkeuring is een aparte actie van het aanmaken van een refund, zodat het zichtbaar blijft in de matrix en niet per ongeluk wordt verleend.
Voor Payouts en Settings blijft het strikt: alleen Finance kan payouts zien en alleen Ops Admin kan Settings wijzigen. Support ziet deze schermen niet, wat verleiding vermindert en fouten beperkt.
Voeg nu een uitzonderingsregel toe: een Support Lead dekt een andere regio gedurende twee weken. In plaats van ze een brede rol als Ops Admin te geven, kan de matrix een tijdelijke scope-uitbreiding opnemen (Support Lead + Regio B, vervalt op een datum). Die enkele uitzondering is veiliger dan permissies kopiëren tussen rollen.
Als je dit in AppMaster bouwt, leidt dezelfde matrix tot wat pagina's in de UI zichtbaar zijn en wat endpoints op de backend toestaan, zodat iemand niet bij Payouts of Settings kan komen door een API-aanroep te raden.
Permissies falen meestal op kleine, saaie manieren: één scherm vergeet een knop te verbergen, één endpoint slaat een check over, één scoperegel matched te breed. Een goede permissiematrix wordt veel nuttiger zodra je hem in herhaalbare tests en een eenvoudig onderhoudsroutine omzet.
Begin met een klein setje testgebruikers. Je hebt geen tientallen accounts nodig. Maak één gebruiker per rol, plus één “randgebruiker” voor elke veelvoorkomende uitzondering (zoals “Support agent met refund-goedkeuring”). Houd deze accounts stabiel zodat je team ze sprint na sprint kan hergebruiken.
Zet vervolgens de matrix om in testcases. Voor elke regel schrijf je één “toegestaan” pad en één “geweigerd” pad. Maak het geweigerde pad specifiek (wat hoort te gebeuren) zodat mensen het niet afdoen.
Test dezelfde regel twee keer: in de UI en in de API. Als de UI een actie blokkeert maar de API het nog steeds toestaat, kan iemand het scherm omzeilen. Als je in AppMaster bouwt, controleer dat zowel UI-logica als backend-eindpunten de regel afdwingen.
Scopes hebben echte data nodig om te testen. Maak testrecords die verschillen in eigendom, team en regio. Verifieer dat je geen ID uit een andere scope kunt raden en ermee kunt openen.
Beslis tenslotte wat je logt voor gevoelige acties (refunds, exports, rolwijzigingen). Log wie het deed, wat er veranderde, wanneer en vanwaar. Review logs periodiek en voeg alerts toe voor zeldzame acties zoals permissiewijzigingen of bulk-exports.
Behandel je permissiematrix als een bouwplan, niet als een document dat je weglegt. De snelste manier om waarde te halen is de basis te bevestigen met de mensen die eigenaar zijn van de data en het proces.
Begin met een korte workshop (30 minuten is genoeg) met één vertegenwoordiger per rol plus de resource-eigenaren (mensen verantwoordelijk voor customers, invoices, payouts, tickets, enz.). Loop rollen, resources, acties en scopes door en noteer eventuele speciale gevallen die als uitzondering aanvoelen. Als een uitzondering vaak voorkomt, is het waarschijnlijk een ontbrekende scope.
Maak daarna een v1-matrix en doe een gerichte review met resource-eigenaren. Houd het praktisch: “Mag Support facturen bekijken?” “Mag Finance klantgegevens bewerken?” Als iemand aarzelt, leg de regel eerst in platte taal vast. Je kunt het later formaliseren.
Als v1 is goedgekeurd, bouw één domein end-to-end voordat je uitbreidt. Kies een dunne slice die data, logica en UI raakt (bijvoorbeeld: Ticketing of Invoice approvals). Je moet kunnen beantwoorden: wie kan het zien, wie kan het wijzigen en wat gebeurt er als ze het proberen.
Als je AppMaster gebruikt, map de matrix naar productonderdelen voordat je iets genereert:
Een eenvoudig voorbeeld: bouw een “Refund request” flow met twee rollen (Support maakt aan, Finance keurt goed). Als dat soepel werkt, kun je randgevallen toevoegen zoals “Support kan annuleren alleen binnen 30 minuten.”
Probeer een klein intern hulpmiddel in AppMaster om rollen en stromen vroeg te valideren en iterateer daarna vanuit de matrix. Het doel is misverstanden te vangen voordat je 20 schermen en een stapel permissie-correcties hebt.
21 jan 2026
8 min
20 jan 20268 min
20 jan 20267 minExperimenteer met AppMaster met gratis abonnement.
Als je er klaar voor bent, kun je het juiste abonnement kiezen.
