Het opstellen van toegangsregels vraagt om samenwerking tussen verschillende rollen. Bestuurders, juristen, IT-architecten en developers kijken vanuit hun eigen perspectief naar wat nodig is. Door de stappen te volgen, ontstaat een set regels die juridisch, functioneel én technisch klopt.

Dit stappenplan beschrijft zeven stappen om van een use case tot een goed werkende en uitvoerbare toegangsregel te komen. Het helpt om het proces gestructureerd aan te pakken en in elke fase de juiste keuzes te maken en de juiste rollen te betrekken.

Stap 1. Formuleer de use case

Formuleer eerst de use case. Doe dit samen met alle stakeholders, zoals de applicatie- of register-eigenaar, beveiligingsverantwoordelijke, beheerder en ontwikkelaar. Zo ontstaat een duidelijk afgebakend doel: wie moet welke taak kunnen uitvoeren en wanneer?

Voorbeeld: Bij het beoordelen van een aanvraag voor huurtoeslag haalt een medewerker persoonsgegevens op uit verschillende bronnen. Niet elke medewerker mag dat: alleen degene die de aanvraag behandelt én bevoegd is voor het bedrag, mag de gegevens bekijken.

Stap 2. Beschrijf de requirements

Omschrijf welke eisen (requirements) gelden voor toegang tot gegevens. Deze eisen worden straks in de toegangsregels verwerkt. Gebruik bij de omschrijving de termen:

1. subject (wie vraagt toegang)
2. action (wat wil die persoon doen)
3. resource (waar gaat het om)
4. context (onder welke omstandigheden)

Door de regels nu al in deze termen uit te drukken, wordt het schrijven later eenduidig en overzichtelijk.

Voorbeeld: een zaakbehandelaar (subject) mag een huurtoeslagzaak (resource) afsluiten (action) als de zaakbehandelaar afdelingshoofd is en de zaakstatus ‘klaar om af te sluiten’ is (context).

Stap 3. Bepaal de attributen

In stap 2 zijn de eisen voor toegang beschreven. In stap 3 volgt de inventarisatie van de attributen die nodig zijn om die eisen uit te voeren.

Voorbeeld:

1. ‘Afdelingshoofd’ is een attribuut van het subject ‘medewerker’
2. ‘Zaakstatus’ is een attribuut van de resource ‘zaak’

Bepaal per attribuut of de informatie beschikbaar is voor de beslismodule. Soms zijn extra koppelingen nodig om de gegevens op te halen.

Stap 4. Schrijf de policies

Als de use case, requirements en attributen beschreven zijn, is duidelijk wat er in de policies moet komen. Voor deze technische vertaling van de eerdere stappen naar taken die de software moet uitvoeren, is specialistische kennis nodig. Bijvoorbeeld van de regeltaal en van de gegevensmodellen van subject, actie, resource en context. Zijn de specificaties goed uitgewerkt? Dan is vooraf al duidelijk of de policies technisch haalbaar zijn.

Stap 5. Test de toegangsregels

Goede tests beginnen met slimme testdata. De testset moet zoveel mogelijk situaties afdekken: gevallen waarin toegang wél toegestaan is en situaties waarin dat niet zo is. Het samenstellen van die testdata is een taak voor een businessanalist. Een ontwikkelaar zet de testdata en verwachte uitkomsten in een systeem. Daarna is het mogelijk om de tests automatisch uit te voeren, zo vaak als nodig. Bijvoorbeeld na het opstellen of wijzigen van de regel, na aanpassingen in andere regels die invloed hebben of bij een verandering in de APIs.

Stap 6. Richt de infrastructuur in

In deze stap wordt de gekozen beslismodule (Policy Decision Point, PDP) neergezet en aangesloten op de juiste toegangshekken (Policy Enforcement Points, PEPs). Check vooraf of de gekozen componenten goed op elkaar aansluiten. Zie ook de checklist bij Softwarekeuze.

De PEP kan deel uitmaken van een applicatie, een API (Application Programming Interface), of een API-gateway. Als de component is gebouwd volgens de AuthZEN NL Gov-standaard, is er weinig extra programmeerwerk nodig voor de aansluiting. Het neerzetten (deployen) van de PDP vergt kennis van de infrastructuur (cloud infra, Helm, Kubernetes).

Stap 7. Zorg voor distributie van regels

Regels worden centraal beheerd, maar moeten terechtkomen bij alle systemen die ze gebruiken. De infrastructuur bepaalt op basis van doelbinding welke regels waar nodig zijn. De beslissystemen krijgen zo alleen relevante regels en altijd de nieuwste versie. Dit is belangrijk voor goede prestaties: regels worden vaak uitgevoerd en veel minder vaak aangepast.