De methodiek: PBAC in een federatief stelsel #

De voorgestelde oplossing is:

Maak gebruik van PBAC, waar mogelijk in een federatief stelsel.

Dit is ook beschreven in een FDS position paper .

Hieronder beschrijven we hoe dit in architectuur eruit ziet, beginnend vanaf een generiek koppelvlak.

Generieke architectuur van een koppelvlak #

In generieke zin is de architectuur van elke API-koppeling te beschrijven in onderstaand diagram:

Links zien we de afnemer, het systeem dat om gegevensverwerking vraagt, en rechts de aanbieder, die de dienst levert. ‘Verwerking’ bedoelen we hier in de brede AVG zin: dat kan opvragen van gegevens zijn, maar ook aanpassen of verwijderen daarvan.

Beide kanten hebben in principe dezelfde componenten. Beide kanten hebben een API-gateway waarmee de andere kant gevonden en de verbinding beveiligd kan worden. Bij de beveiliging hoort in de overheidssituatie altijd een OIN PKI-certificaat. Daarnaast is er een vorm van identificatie en authenticatie: het vaststellen en verifiëren van de identiteit van de vrager. Dit kan ingebouwd zijn in de applicatie/API, in de gateway, of elders.

Verschillend is dat links het functionele blok als applicatie benoemd wordt, en rechts als een API. Dit om duidelijk te maken dat er een verschil zit in functie: de afnemer vraagt om verwerking, de aanbieder verwerkt. Beide zijn echter volwaardige softwarecomponenten waar allerlei functionaliteit ingebouwd kunnen zijn. De API zal soms op een eenvoudig doorgeefluik lijken, en soms gegevens uit verschillende bronnen halen en toegevoegde waarde bieden door te combineren, berekenen, minimaliseren, etc.

Generieke architectuur van een federatief koppelvlak #

In het FDS is de architectuur uitgebreider:

De volgende componenten zijn erbij gekomen:

• Toegangsverlening: het onderwerp van deze methodiek, een vorm van bepalen wat inhoudelijk mag qua diensten en gegevens. Bij open API’s zal dit niet bestaan of slechts heel rudimentair, in andere API’s uitgebreid.
• Transactielogging: een log van de transacties op het transportniveau. Dit zijn gegevens zoals tijdstip, certificaat, ip adres van het aanvragend systeem, etc. De inhoud van het bericht zelf wordt hier niet in meegenomen.
• Logboek dataverwerkingen: een log op applicatieniveau waarin juist wel de inhoud van het bericht centraal staat, en daarbij gegevens zoals de grondslag van de verwerking bewaard blijven.
• FSC (Federatieve Service Connectiviteit) is de naam voor de transactielaag in het FDS.

Transactielogging is hier bij de gateway getekend omdat het voor de hand ligt dat die verantwoordelijkheid daar ligt, hoewel dat niet hoeft. Toegangsverlening en logboek dataverwerkingen zijn tussen de applicatie/API en de gateway getekend, omdat het in de architectuur vrijgelaten wordt waar de verantwoordelijkheid komt te liggen om logging aan te roepen.

We richten ons in de rest van dit onderzoek alleen op toegangsverlening. We houden daarbij wel in het achterhoofd dat er een belangrijke relatie met logboek dataverwerkingen zal zijn, omdat het logboek dataverwerkingen (naast andere gegevens) de beslissing van toegangsverlening moet vastleggen.

Generieke architectuur van PBAC-toegangsverlening #

Een PBAC-oplossing heeft de volgende generieke architectuur:

Boven de PBAC-architectuur aan één zijde van de koppeling. Als toelichting:

• Toegangsverlening start als de Policy Enforcement Point (PEP) wordt aangesproken, door de applicatie, API of gateway. Beiden hebben de mogelijkheid om een transactie door te laten gaan of te blokkeren, en daarmee af te dwingen dat de toegangsbeslissing gehonoreerd wordt. In de FDS-architectuur is gekozen om FSC de aanroep te laten doen, door de gateway dus.
• Het Policy Decision Point (PDP) wordt gevraagd om de beslissing te nemen. Daarvoor gebruikt het policies uit de PAP en attributen uit de PIP.
• Het Policy Access Point (PAP) haalt de policies op die geëvalueerd moeten worden. De policies moeten ‘buiten’ de software zijn opgeslagen, op een plek die bereikbaar is voor mensen en systemen van buiten zodat audits gedaan kunnen worden.
• Het Policy Information Point (PIP) haalt op verzoek van de PDP waarden van attributen op. Deze kunnen komen uit:
  1. De vrager, of subject. Dit is de identiteit in brede zin, waaronder ook rollen en verklaringen vallen;
  2. De vraag, of actie. Dit zijn de gekozen dienst of API en de parameters die zijn meegegeven;
  3. Het antwoord, of object. Het kan zijn dat er een eigenschap van de gevraagde data van invloed is op de toegang. Als er bijvoorbeeld gegevens van personen gevraagd worden waar in principe recht op is, maar dat er in de populatie bijzondere personen zitten die afgeschermd zijn.
  4. De context. Dit zijn aller veranderlijke aspecten, zoals tijd, geolocatie, gebruikt apparaat, authenticatiesterkte, eerdere verzoeken, etc.

Dit plaatje toont een federatieve PBAC-oplossing, met als extra elementen:

• Beide kanten implementeren PBAC. Het is niet noodzakelijk dat ze dezelfde implementatie daarvoor kiezen.
• Beide kanten delen dezelfde toegangsregels. In een federatief stelsel ligt het voor de hand daar een gedistribueerde oplossing voor te kiezen. Dit in tegenstelling tot losse systemen die handmatig synchroon gehouden moeten worden, en ook in tegenstelling tot één enkele database waarbij een enkel kritisch systeem zou ontstaan.

Autorisatieregels apart #

Belangrijk aan een PBAC-oplossing is de autorisatieregels ook daadwerkelijk zoveel mogelijk in de opslag bij de PAP staan. Waar nu regels verwerkt zijn in de code van de API, bijvoorbeeld in de database query, moeten deze in mens- en machineleesbare vorm in de autorisatieregels komen.

Een aspect dat extra aandacht verdient hier is zorgvuldig beheer. Als regels makkelijker bijgewerkt kunnen worden, is een vergissing ook sneller gemaakt. Aanpassingen moeten nog steeds in een goed ontwikkel-, test- en releaseproces plaatsvinden. Waar dat nu vaak deel uitmaakt van het softwareontwikkelproces, dat onder beheer is van ontwikkelaars met specialistische tooling en kennis, komt dat straks dichter bij functioneel beheer te liggen. Een goede afstemming waarbij de beide teams bijdragen aan een zorgvuldig proces is essentieel. Het inrichten van een testomgeving met eventu