Ga naar inhoud
FTV Beeldmerk

Federatieve Toegangsverlening

Advies over gebruik van ReBAC

17 september 2025

Federatieve Toegangsverlening (FTV) volgt het architectuurpatroon van Externalized Authorization Management (EAM). Regelmatig komt de vraag op of Relationship Based Access Control (ReBAC) daarbinnen toegepast kan worden. In dit artikel geven Michiel Trimpe en Gerard Juijn (architect en developer bij team FTV) uitleg en advies over de inzet van ReBAC in de context van de overheid. Daarbij ligt de uitdaging in het benutten van de voordelen van ReBAC zonder concessies te doen aan de veiligheid van gevoelige informatie.

Wat is ReBAC

ReBAC is een moderne variant van ABAC (Attribute Based Access Control) en PBAC. Ook in die varianten kunnen relaties onderdeel zijn van een toegangsbeslissing. Die relaties moeten dan wel eerst expliciet worden opgehaald of beschikbaar gemaakt. Elk verzoek kost tijd en bij gebruik in interactieve applicaties kan dit ongewenst veel vertraging veroorzaken.

Hoe werkt ReBAC?

ReBAC werkt anders. Relaties worden vooraf vastgelegd en zijn automatisch beschikbaar bij de service die de toegangsbeslissing neemt. Zodra een relatie verandert, wordt de informatie bijgewerkt. Zo staat altijd de actuele informatie klaar en kunnen toegangsbeslissingen, ook bij complexe relaties, snel worden genomen.

Voordelen ReBAC?

ReBAC biedt meerdere voordelen.

Het versnelt toegangsbeslissingen, omdat informatie niet steeds opnieuw hoeft te worden opgehaald.

Relaties zijn bovendien vaak een natuurlijkere manier om regels uit te drukken dan attributen (eigenschappen). In systemen zoals Google Zanzibar, een bekend voorbeeld van ReBAC, draait toegangsverlening grotendeels op relaties en spelen attributen een kleinere rol.

Wat ReBAC verder interessant maakt, is dat de zoekfunctionaliteit standaard beschikbaar is in open source oplossingen. De AuthZEN Search APIs kunnen eenvoudig zichtbaar maken welke gebruikers, welke handelingen op welke gegevens uit mogen voeren. Bij PBAC- en ABAC-oplossingen is vergelijkbare functionaliteit vaak alleen in commerciële producten te vinden. Daarnaast kennen sommige ReBAC-oplossingen ook het gebruik van zogenaamde Zookies waarmee historische beslissingen laagdrempelig herleidbaar gemaakt kunnen worden; en hoge niveaus van herleidbaarheid in het Authorization Decision Log relatief laagdrempelig behaald kunnen worden.

ReBAC binnen de overheid

Bij de uitvoering van overheidstaken is het onnodig delen van informatie een belangrijk uitgangspunt. Het gebruik van ReBAC staat op gespannen voet met dit principe, als er gevoelige informatie benodigd is voor de toegangsbeslissingen. De informatie wordt namelijk gekopieerd naar de Policy Decision Points (PDP, beslispunt), die dicht bij de Policy Enforcement Points (PEP, afdwingpunt) aan zitten, welke vaak verspreid zijn over het IT-landschap. Daardoor zouden gegevens ook beschikbaar kunnen komen op plekken waar dat niet nodig is.

Beveiliging is aandachtspunt

Een verantwoorde toepassing van ReBAC vraagt daarom om een goede beveiliging van de gekopieerde gegevens als daar gevoelige informatie in terecht komt. In de praktijk brengt dit een hoge last met zich mee, omdat elk PEP en PDP afzonderlijk moet worden beveiligd. Daarbij komt dat de meeste bestaande ReBAC-oplossingen slechts beperkt beveiliging bieden voor de communicatie tussen PEPs en de PDPs. Het gevolg is dat vanuit elke PEP mogelijk alle relaties in de PDP kunnen worden bevraagd. Dat is zeker bij gevoelige informatie een risico.

Advies

Voor niet-gevoelige informatie, zoals open data, of licht gevoelige informatie, zoals configuratiegegevens, kan ReBAC voordelen bieden. In die gevallen maakt de techniek het mogelijk om complexe toegangsbeslissingen snel en efficiënt te nemen. Het kopiëren van relaties met gevoelige informatie naar de PDPs moet bij het gebruik van ReBAC echter zoveel mogelijk voorkomen worden. Dit kan soms door gevoelige informatie door de PEP op te laten halen en deze, tijdens het autorisatie-verzoek, als ‘losse’ relaties aan de PDP aan te bieden. Dan hoeven de gevoelige gegevens niet gekopieerd te worden naar PDPs. Een andere oplossing kan zijn om gevoelige gegevens via Privacy Enhancing Technologies PET onherkenbaar te versleutelen. Hierbij zijn ze niet meer herkenbaar, maar kunnen ze nog steeds gebruikt worden om koppelingen te controleren. Alleen gaat dit niet op als gevoelige gegevens als attribuut in vergelijkingen nodig zijn. Wanneer implementaties toch vragen om het kopiëren van relaties met gevoelige gegevens, moet de beveiliging van de PDP en de verbinding met PEPs voldoen aan de hoge eisen die gelden voor de verwerking en opslag van gevoelige data.

Meer weten?

[OpenFTV]/(https://vng-realisatie.github.io/ftv/toepassen/openftv/), de referentie-implementatie van FTV, bevat mogelijkheden om met OpenFGA (een ReBAC implementatie) aan de slag te gaan.

Conclusie

Vanuit FTV geldt ReBAC voor toegangsbeslissingen die vooral op relaties gebaseerd worden als een prima alternatief, met de kanttekening dat voor het gebruik van gevoelige informatie in de ReBAC-data hoge eisen aan de beveiliging gesteld moeten worden.