Definities #

Voordat we verder gaan is het goed vast te stellen wat precies het onderwerp is; wat hetgene is waar we een standaard voor zoeken.

Toegangsverlening #

Toegangsverlening, of autorisatie, is in beginsel de vraag of iemand iets mag. De gangbare IT-terminologie hierbij is ‘subject’ voor ‘iemand’, en ‘resource’ voor ‘iets’. (zie lock/unlock documentatie voor een uitgebreidere uitleg).

Het subject vaststellen is de taak van identificatie en authenticatie, en resulteert in de aanduiding van een persoon, met daarbij eventueel attributen zoals rollen, afdelingen, verifieerbare verklaringen, etc.

Het verwerkingsverzoek is de handeling de gevraagd wordt. ‘Verwerken ’ is hier zo breed als in de AVG: bekijken, vastleggen, wijzigen, doorsturen, verwijderen en nog veel meer.

De resource is een breed begrip dat kan verwijzen naar bepaalde gegevens (bv ‘geboortedatum’), maar ook diensten met afgeleide informatie (‘meerderjarig’).

De regels beschrijven wat er mag. Deze regels zijn afgesproken tussen partijen in de vorm van een overeenkomst of wet. In onze context hebben we het over regels die dusdanig concreet vastgesteld zijn dat ze geautomatiseerd kunnen worden toegepast.

De context is term voor de dynamische omgeving waarbinnen het verzoek plaats vindt. Daaronder valt de datum en tijd, de geografische locatie, gegevens over het apparaat, etc.

Toegang is vervolgens het proces dat op basis van deze gegevens beslist of en hoeveel toegang verleend wordt, en of er voorwaarden aan verbonden zijn.

Filtering #

Niet alle regels kunnen vooraf doorgerekend worden, omdat soms het antwoord nodig is om te bepalen of de vraag terecht was. Als bijvoorbeeld een medewerker in principe gerechtigd is om persoonsgegevens op te vragen, dan komt zijn zoekactie op BSN door de regels. Maar als vervolgens blijkt dat de gevraagde persoon een beschermede identiteit is, dan wordt het verzoek alsnog niet gehonoreerd.

We onderkenning hierbij de volgende afschermingspatronen :

1. Verticale subsets: het beperken van de attributen van een object. In termen van tabellen zijn dat de kolommen, de velden in een database. Een medewerker burgerzaken mag wel de adresgegevens zien, maar niet het inkomen.
2. Horizontale subsets: beperking op de objecten zelf, oftewel de rijen van een tabel of de records in een database. Een gemeente mag alleen wijzigingen doorvoeren van burgers die in de eigen gemeente staan geregistreerd.
3. Richting: het beperken van de wijze van zoeken. Een baliemedewerker mag wel opzoeken wie de eigenaar is van een pand, maar niet welke panden die persoon nog meer bezit.

2. Methodieken #

Voor toegang zijn een aantal methodieken benoemd. Dan zijn werkwijzen, oftewel categorieën van oplossingen, niet concrete implementaties. Een gangbare indeling is:

1. Lijsten van gebruikers (ACL )
2. Rolgebaseerd (RBAC )
3. Attribuutgebaseerd (ABAC )
4. Policy-gebaseerd (PBAC)
5. Relatiegebaseerd ReBAC

Er zijn al goede beschrijvingen en vergelijkingen beschikbaar:

• Door het project FDS is een position paper gemaakt
• Onder GEMMA is een vergelijking gemaakt.

Het onderscheid tussen ACL, RBAC en de laatste groep is duidelijk, maar tussen de laatste drie is minder evident. Essentiële kenmerken zijn dat:

• Regels worden opgeschreven in aparte bestanden, in een daarvoor bestemde taal
• Regels gebruik kunnen maken van eigenschappen van de vrager (‘subject’), de vraag (‘actie’), de context en het antwoord (‘object’)
• Regels worden real-time toegepast
• De taal biedt mogelijkheden voor complexe expressies

De term PBAC legt de nadruk op policies, hoewel in eerder beschrijvingen van ABAC al dezelfde structuur en functionaliteiten genoemd zijn. Volgens Wikipedia zijn ze hetzelfde. ReBAC op zijn beurt schuift relaties naar de voorgrond, maar in essentie zijn relaties eigenschappen van subjecten.

Verantwoordelijkheden #

Wie wat doet, is een kwestie van afspraken; de theorie of methodieken schrijven hier in principe niets over voor. Hieronder bekijken we van een aantal verantwoordelijkheden waar ze moeten liggen in onze context.

Controle toegangsrecht #

In een klassieke API-uitwisseling is het vaak alleen de aanbieder die controleert of een afnemer wel mag wat hij vraagt. Denk aan een commerciële dienst waarbij de aanbieder controleert of er wel betaald is en de afnemer vrijuit mag vragen.

Bij de gegevensuitwisseling bij de overheid ligt dat anders: de afnemer moet vooraf controleren of de persoon of het systeem een vraag terecht stelt. Alleen de afnemer weet namelijk waarom de vraag gesteld wordt (de doelbinding) en de grond waarop de persoon het recht om de vraag te stellen ontleent (de grondslag). De aanbieder mag erop vertrouwen dat deze controles zijn uitgevoerd.

De aanbieder moet daarna nog wel de verklaringen verifiëren, en eventuele aanvullende filtering doen als dat zo is afgesproken, maar hoeft juridisch geen verantwoording af te leggen over het gebruik.

Dataminimalisatie #

Een ander principe is dat van dataminimalisatie , een van de basisprincipes van de AVG en doelstelling in de GDI. Dat stelt dat alleen de gegevens die strikt noodzakelijk zijn worden uitgewisseld. Dit is een verantwoordelijkheid van beide partijen.

• De aanbieder moet de mogelijkheid bieden om gericht te vragen. Als er alleen een dienst is om alle persoonsgegevens op te halen, dan zal de afnemer die alleen adressen wil zien te veel gegevens krijgen.
• De afnemer moet de dienst gebruiken die het minimale biedt om het doel te bereiken.

Logging #

Een andere verantwoordelijkheid in de overheidsregels is dat de afnemer een logboek moet bijhouden van alle verwerkingen. Daarin staan, naast tijdstip, persoon, systeem e.d., ook de eerder genoemde doelbinding en grondslag vermeld. Daarmee kunnen achteraf controles/audits uitgevoerd worden, geautomatiseerd of handmatig, incidenteel of structureel.

Dit staat nog los van de transactielogging. Dat is een verantwoordelijkheid op transportniveau, los van toegangsverlening, waarin de technische details van de berichtverzending, de envelop, staan.