Identiteit en toegangsbeheer
Om te kunnen beslissen welke "identiteiten" (denk aan personen en apparaten) om de juiste redenen gebruik kunnen maken van API's is goed beheer van identiteiten en toegangsregels nodig. De manier waarop toegang nu vaak wordt geregeld voldoet niet meer wanneer intensief gebruik wordt gemaakt van API's. Aanvullend op bestaande mechanismen zijn daarom nieuwe manieren nodig van van identiteit- en toegangsbeheer ('Identity and Access Management (IAM)").
Referentiemodel NORA[bewerken]
Onderstaande afbeelding toont het model dat de NORA gebruikt voor de uitwerking van identiteit- en toegangbeheer.
Identiteitenbeheer omvat het beheer van identiteiten en de middelen waarmee identiteiten zijn aan te tonen (de blauwe en groen omlijnde functies).
Toegangsbeheer omvat het beheer van bevoegdheden- en machtigingen (de oranje en geel omlijnde functies).
Beide zijn nodig om bij een verzoek tot toegang tot een dienst te kunnen beslissen of toegang wordt verleend (de paars omlijnde functie).
Er wordt pas toegang tot een dienst verleend als iemand beschikt over een betrouwbare identiteit én over een toegangsbevoegdheid op basis van vastgelegde toegangsregels.
Identiteitenbeheer en toegangsbeheer zijn verschillende vakgebieden die een onderlinge relatie kennen maar afzonderlijk behandeld kunnen worden. Het maken van onderscheid tussen beheer van identiteiten en van toegang is relevant bij het gebruik van API’s.
Identiteitenbeheer[bewerken]
Onderstaande afbeelding geeft te onderscheiden soorten identiteiten weer:
Het benodigde beheer van identiteiten kan er per groep anders uitzien. Bij medewerkers kunnen bijvoorbeeld HR-processen zoals instroom, uitstroom en doorstroom tot aanpassing van regels leiden. Voor burgers geldt dat ze steeds vaker zelf identiteitsgegevens beheren. De afbeelding toont dat, naast identiteitenbeheer voor personen, beheer van identiteiten ook nodig is voor slimme apparaten ('IoT devices'). Bijvoorbeeld als via sensoren verkregen meetgegevens via een API als meetdata moeten worden vastgelegd.
Toegangsbeheer[bewerken]
Nadat met voldoende zekerheid is vastgesteld wie om toegang tot een dienst vraagt moet via toegangsbeheer worden bepaald of er toegang wordt verleend. Daarbij kunnen verschillende soorten aspecten van belang zijn. Wat is de functie van de betreffende actor? Waarvoor is toegang nodig? Op welke locatie en welk tijdstip wordt toegang gezocht? Binnen de huidige praktijk situatie worden verschillende soorten bedrijfsregels vaak versnipperd en onvoldoende gedetailleerd vastgelegd. Bijvoorbeeld door medewerkers op basis van toegekende rollen te autoriseren ('Role Based Access Control'). Onderstaande afbeelding geeft weer hoe verschillende soorten medewerkers en systemen een rol kunnen spelen bij het inrichten van toegangsbeheer.
Binnen de afbeelding worden een vijftal soorten 'eigenaren' binnen een organisatie onderscheiden. Ieder type eigenaar mag vanuit de eigen verantwoordelijkheid bepalen wie om welke reden toegang moet krijgen tot een proces, dienst, systeem of resource.
- Een lijnmanager mag bepalen welke medewerker welke taken mag uitvoeren. Bijvoorbeeld op basis van de competenties of beschikbare tijd van een een medewerker.
- De proceseigenaar gaat over de uitvoering en kwaliteit van processen. Hij weegt risico’s binnen een proces af en kan bijvoorbeeld besluiten processen op te delen in processtappen die afzonderlijk zijn te autoriseren om misbruik en fouten te voorkomen. De proceseigenaar bepaalt wie een taak mag uitvoeren en wil dat uitvoering wordt vastgelegd.
- De systeemeigenaar is verantwoordelijk voor een informatiesysteem, systeemautorisaties en de mapping daarvan op taken, verantwoordelijkheden en bevoegdheden van medewerkers.
- De gegevenseigenaar is verantwoordelijk voor de data governance. Hieronder vallen verantwoordelijkheden ten aanzien van duurzame toegankelijkheid, compliance aan wet- en regelgeving en doelbinding voor gebruik van data door processen in het kader van de AVG;
- Het hoofd IT tenslotte gaat over toegang tot de infrastructuur. Hij bepaalt aan welke voorwaarden moet zijn voldaan om gebruik te mogen maken van aanwezige technologie. Denk aan verplichte configuraties van software op laptops, firewalls, VPN’s, patch levels en dergelijke.
Bij het toenemend werken met API's schiet zo'n inrichting tekort qua controle en governance. Om betrouwbaar vast te kunnen stellen of een identiteit toegang tot een bepaalde dienst moet krijgen kunnen veel verschillende soorten gegevens nodig zijn. Role Based Access Control is daarvoor steeds minder geschikt. Attribute Based Access Control biedt meer mogelijkheden omdat kenmerken als attributen fijnmaziger zijn vast te leggen, maar op termijn is Policy Based Access Control nodig.
Toegangsbeheer transitie[bewerken]
Zeker in het verleden handelden veel informatiesystemen het beheer van identiteiten en toegang voor gebruikers helemaal zelf af. Tegenwoordig zijn steeds meer systemen in staat om gebruik te maken van externe identityproviders zoals Microsoft's Active Directory. Daardoor wordt bijvoorbeeld 'single sign-on' mogelijk voor gebruikers zodat zij zich slechts eenmalig hoeven aan te melden en daarna meerdere applicaties kunnen gebruiken. Applicaties ontvangen dan bij het opstarten de benodigde data voor autorisatie binnen de applicatie.
Vergelijkbaar als bij informatiesystemen handelen veel services die via API's worden aangeroepen identiteiten- en toegangsbeheer nog vaak zelf af. Soms wordt een deel van de autorisatie al extern afgehandeld. Bijvoorbeeld als een API-gateway voorziening controleert of een bepaalde API überhaupt mag worden aangeroepen. Net zoals bij informatiesystemen is gebeurd zal toegang tot API's stapsgewijs meer worden gebaseerd op extern gedefinieerde en afdwingbare regels. Onderstaande afbeelding toont de fasen die informatiesystemen daarvoor doorlopen.
Het model dat nu het meest wordt toegepast is het 3e model van links. In het meest rechtse model zijn identiteiten federatief en worden toegangsregels centraal bijgehouden en voor toegang gebruikt. Op netwerkniveau geldt een 'zero trust architectuur' en via API's benaderde services kennen zelf geen identiteiten en autorisatieregels meer.
In de gemeentelijke praktijk zal voorlopig een mix van gebruikte modellen en mechanismen voor toegangsbeheer blijven bestaan. Het toenemend gebruik van API's maakt het echter nodig om stapsgewijs toe te groeien naar meer gebruik van Policy Based Access Control. De mate waarin en het tempo waarmee dit gebeurt kan uiteraard per gemeente verschillen.