De nieuwe medewerker krijgt toegang tot vrijwel alles. Niet omdat iemand heeft vastgesteld dat dit nodig is, maar omdat het sneller is dan uitzoeken wat de functie werkelijk vereist. De bestaande rol heet bijvoorbeeld “medewerker”, “beheerder” of “projectteam”, en voor de zekerheid krijgt iedereen dezelfde variant. Het toegangsoverzicht ziet er daarna keurig gestandaardiseerd uit. De organisatie heeft immers RBAC.
Alleen: een rol die aan iedereen wordt uitgedeeld, is geen toegangsbeheersing meer. Het is een administratieve snelweg om uitzonderingen te vermijden. RBAC, Role-Based Access Control, wordt dan niet gebruikt om toegang te beperken tot wat iemand nodig heeft, maar om discussies over verantwoordelijkheid uit de weg te gaan.
De centrale fout zit daarom niet in het aantal rollen. De fout is dat een rol wordt behandeld als een handige verzamelbak voor gemak, politieke rust en tijdelijke noodoplossingen. Zodra iedereen dezelfde rol krijgt, verdwijnt het onderscheid tussen mogen kijken, mogen wijzigen, mogen goedkeuren en mogen ingrijpen. Wat overblijft is geen model van verantwoordelijkheid, maar een vermomde vorm van brede toegang.
Een rol is geen functietitel
Organisaties beginnen vaak met functienamen. Medewerker financiën krijgt een financiële rol, een applicatiebeheerder krijgt een beheerdersrol en een manager krijgt iets met goedkeuren. Dat klinkt logisch, totdat blijkt dat functietitels weinig zeggen over de handelingen die iemand in een systeem moet uitvoeren.
Twee medewerkers op dezelfde afdeling kunnen verschillende bevoegdheden nodig hebben. De een verwerkt facturen, de ander controleert ze. Een projectleider mag projectdocumenten wijzigen, maar niet noodzakelijk personeelsgegevens. Een applicatiebeheerder moet een systeem kunnen configureren, maar hoeft niet automatisch alle bedrijfsdata te kunnen lezen. De functienaam is hooguit een aanwijzing. De werkelijke vraag is welke handelingen iemand uitvoert, op welke gegevens, in welke context en met welke verantwoordelijkheid.
Wie een rol gelijkstelt aan een afdeling of functie, maakt het model snel begrijpelijk, maar inhoudelijk arm. Dat is prettig bij de invoering en pijnlijk bij een incident. Dan blijkt dat “financiën” geen autorisatie is, maar een etiket waaronder tientallen verschillende risico’s zijn opgeborgen.
De universele rol is een bestuurlijke keuze
Het argument voor één brede rol is meestal praktisch. Mensen moeten kunnen werken, de aanvraagprocedure is traag en niemand wil verantwoordelijk zijn voor een blokkade. Dus krijgt de gebruiker alvast toegang. Als later blijkt dat iets niet werkt, wordt er wel gekeken. Dat “later” is in veel organisaties een permanente beheerstrategie geworden.
Daarmee wordt brede toegang geen technische noodzaak, maar een bestuurlijke keuze. De organisatie kiest ervoor om productiviteit op korte termijn zwaarder te wegen dan controleerbaarheid op langere termijn. Dat mag, maar dan moet het ook zo worden besproken. Niet als een neutrale inrichting van RBAC, maar als geaccepteerd risico met een eigenaar.
Het probleem is dat die eigenaar vaak nergens zichtbaar is. IT beheert de rol, de manager vraagt om toegang, security beoordeelt de configuratie en de proceseigenaar veronderstelt dat het wel goed zal zitten. Iedereen heeft een stukje van de verantwoordelijkheid, waardoor niemand het geheel bezit. Bij een incident blijkt dan dat de gebruiker formeel bevoegd was, maar dat niemand ooit serieus heeft vastgesteld of die bevoegdheid nog passend was.
Dat sluit aan bij een breder probleem rond digitale identiteiten: een identiteit is niet alleen een account met een wachtwoord, maar een verzameling aannames over wie iemand is en wat die persoon mag doen. Zodra die aannames niet worden onderhouden, ontstaat een identiteitslek, ook zonder dat er technisch een wachtwoord wordt gestolen. Hoe identiteitslekken ontstaan, en waarom techniek niet genoeg is begint daarom niet bij een productinstelling, maar bij de vraag wie welke verantwoordelijkheid werkelijk draagt.
Role explosion is niet de belangrijkste angst
Bij gesprekken over RBAC verschijnt snel het bekende tegenargument: maak niet te veel rollen, want dan ontstaat role explosion. Dat risico bestaat. Een rol voor iedere denkbare combinatie van afdeling, locatie, project, senioriteit en tijdelijke uitzondering wordt al snel onbeheerbaar. Dan krijgt de organisatie honderden rollen met namen die niemand meer begrijpt.
Maar die waarschuwing wordt ook gebruikt als excuus om te weinig onderscheid te maken. Omdat twintig rollen lastig zijn, maakt men er drie van. Omdat drie rollen nog discussie opleveren, wordt het één brede rol. De complexiteit is daarmee niet verdwenen. Ze is verplaatst naar losse groepslidmaatschappen, handmatige uitzonderingen, gedeelde accounts, lokale applicatieregels en urgente verzoeken via e-mail.
Een beperkt aantal rollen is niet automatisch eenvoud. Een brede rol met veel uitzonderingen kan ingewikkelder zijn dan een zorgvuldig gekozen set met duidelijke verantwoordelijkheden. De vraag is dus niet hoeveel rollen er zijn, maar of iemand kan uitleggen waarom een rol bestaat, welke acties erbij horen, wie eigenaar is en wanneer de toegang vervalt.
Goede RBAC maakt bovendien onderscheid tussen verschillende soorten toegang. Lezen is iets anders dan wijzigen. Wijzigen is iets anders dan publiceren. Een transactie uitvoeren is iets anders dan die transactie goedkeuren. Wie al die handelingen in één rol stopt, maakt functies technisch handig maar bestuurlijk oncontroleerbaar.
Automatisering maakt verkeerd beleid sneller
Provisioning en deprovisioning worden vaak gepresenteerd als bewijs dat toegangsbeheer volwassen is. Een medewerker komt in dienst, wordt automatisch aan een groep toegevoegd en ontvangt de bijbehorende rechten. Bij uitdiensttreding wordt het account weer verwijderd. Dat is nuttig, maar het automatiseert alleen de beslissing die eraan voorafgaat.
Als de brongegevens grof zijn, wordt ook de fout grootschalig uitgevoerd. Een HR-waarde als “Finance” kan een rol activeren die veel meer toegang geeft dan de functie vereist. Een wijziging van afdeling kan oude rechten laten staan als het proces alleen nieuwe groepen toevoegt. Een tijdelijke projectrol kan permanent worden wanneer niemand verantwoordelijk is voor het einde ervan. De machine doet dan precies wat is ingericht. Dat is geen geruststelling, maar soms de kern van het probleem.
Ook SCIM of andere koppelingen lossen dit niet vanzelf op. Zij kunnen identiteiten en groepslidmaatschappen synchroniseren, maar bepalen niet of een groep inhoudelijk verstandig is. In de praktijk wordt een fout toegangsmodel zo niet minder fout, maar sneller en consistenter fout. Automatisering is geen vervanging voor autorisatieontwerp. Het is een vermenigvuldiger van de kwaliteit daarvan.
Daarom hoort bij elke geautomatiseerde toekenning een duidelijke bron van waarheid. Niet alleen voor de identiteit, maar ook voor functie, organisatorische verantwoordelijkheid, tijdelijke opdracht en einddatum. Wie die gegevens niet betrouwbaar kan leveren, moet terughoudend zijn met automatische rechten. Snel verkeerde toegang uitdelen is geen volwassenheid, hoe modern de koppeling ook klinkt.
Een bruikbaar model begint bij handelingen
Een werkbaar RBAC-model begint niet met de vraag welke groepen de leverancier aanbiedt. Het begint met de vraag welke handelingen in een proces bestaan. Wie mag een klantrecord inzien? Wie mag het wijzigen? Wie mag een kredietlimiet aanpassen? Wie controleert die wijziging? Wie mag een export maken? Door die handelingen zichtbaar te maken, komen verantwoordelijkheden en conflicten vanzelf naar boven.
Daarna kan een organisatie rollen samenstellen die logisch bij elkaar horen. Niet iedere afzonderlijke handeling hoeft een rol te worden, maar risicovolle combinaties verdienen wel aandacht. Een gebruiker die een betaling kan voorbereiden én goedkeuren, heeft meer nodig dan een brede functierol. Daar hoort een expliciete keuze bij, inclusief controle, logging en periodieke beoordeling.
Toegang moet daarnaast een levenscyclus hebben. Een rol is geen permanente sticker op een account. Er moet een reden zijn voor toekenning, een eigenaar voor beoordeling en een moment waarop de noodzaak opnieuw wordt vastgesteld. Dat geldt vooral voor beheerdersrechten, projecttoegang en uitzonderingen. Een uitzondering zonder einddatum is meestal gewoon een nieuwe standaard die niemand durft te benoemen.
Dit is ook waar Zero Trust meer betekent dan een technisch patroon. Niet vertrouwen betekent niet dat iedere gebruiker voortdurend verdacht moet worden behandeld. Het betekent dat toegang niet uitsluitend wordt gebaseerd op lidmaatschap van een groep of op het feit dat iemand ooit toestemming heeft gekregen. Context, doel, apparaat, gevoeligheid van de gegevens en de gevraagde handeling doen ertoe. Zero Trust is geen product. Stop met doen alsof.
Wat is dan de echte IT-realiteit?
RBAC wordt complex zodra organisaties verantwoordelijkheid proberen te modelleren met gemak als uitgangspunt. De brede rol lijkt de eenvoudige oplossing, maar verbergt juist de ingewikkeldheid. De vraag wie toegang heeft, wordt vervangen door de vraag bij welke groep iemand hoort. Daarmee wordt het systeem overzichtelijker op papier en onduidelijker in werkelijkheid.
De oplossing is niet om onbeperkt nieuwe rollen te bouwen en evenmin om iedere gebruiker als een potentieel gevaar te behandelen. De oplossing is om autorisaties te koppelen aan concrete handelingen, gegevens en verantwoordelijke eigenaren. Dat vraagt keuzes van de business, discipline van IT en voldoende bestuurlijke moed om soms “nee” te zeggen tegen een verzoek dat alleen snel is omdat niemand de consequenties wil uitzoeken.
Een rol moet dus kleiner worden naarmate de gevolgen groter zijn. Wie dat niet wil organiseren, heeft geen RBAC-probleem maar een verantwoordelijkheidsprobleem. En geen enkele groep kan dat voor je oplossen.
Ontdek meer van IT realiteit
Abonneer je om de nieuwste berichten naar je e-mail te laten verzenden.
