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. Hierbij valt op te merken dat de omvang van de ellipsen in het figuur ook aangeven wat de omvang van de populatie is die toegang verleend wordt.
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'). Om toegangsbeheer te duiden en aan te geven wat de knelpunten zijn bij de inrichting die nu veelal binnen organisaties wordt gebruikt wordt een voorbeeld uitgewerkt. Dit voorbeeld is gebaseerd op het gebruik van een Identity Governance and Administration (IGA) oplossing. Een IGA-oplossing beheert digitale identiteiten en toegangsrechten over meerdere systemen binnen een organisatie.
In het IGA model stromen medewerkers in via HR-processen vanuit het HR-systeem. De IGA-oplossing krijgt mutaties vanuit het HR-systeem door en administreert onder andere bij welke afdeling medewerkers behoren, welke taken zij gaan uitvoeren, wie de verantwoordelijk manager is en wat de rol van een medewerker binnen de organisatie is. Op grond van hiervan wordt vervolgens een account aangemaakt in een informatiesysteem, Active Directory of Cloudvoorziening. In dit geschetste basis IGA-model wordt het Role Based Access Control (RBAC) model gehanteerd. Binnen het RBAC-model wordt iemand binnen de organisatie bekend als identiteit en krijgt hij of zijn niet afzonderlijke persoonlijke autorisaties maar autorisaties die op basis van een rol, of rollen, toegekend worden. Het RBAC-model kent zijn mogelijkheden maar ook zijn beperkingen. Het grote voordeel van dit model is dat het autorisatiebeheer door slim gebruik te maken van rollen grotendeels geautomatiseerd worden. Stel iemand komt in dienst en wordt krijgt als rol ‘medewerker financiën’. Op basis van deze rol kunnen aan de persoon autorisaties worden toegekend voor bijvoorbeeld folders op een server van de afdeling financiën, toegang tot het financieel systeem en misschien ook wel autorisaties voor functies in de Cloud. De medewerker kan dus op basis van een roltoekenning direct met de juiste autorisaties aan de slag. Op het moment dat de medewerker de organisatie verlaat kunnen de autorisaties ook automatisch worden ingetrokken op basis van een uitstroom bericht vanuit het HR-systeem. Het RBAC-model is het meest basale en bekende model van identity en access management. Kern van het model is dat het gaat over automatiseren van uitgifte van autorisaties. Onderstaand figuur geeft de basis van het model weer.
Een persoon krijgt een bepaalde business rol, bijvoorbeeld ‘debiteurenbeheerder’. Op basis van die rol krijgt iemand toegang tot een applicatierol. Deze applicatierol is een verzameling autorisaties in een informatiesysteem. In het geval dat de applicatierol ‘debiteurenmedewerker’ binnen het financieel systeem wordt gekoppeld aan de business rol ‘debiteurenbeheerder’ dan krijgt de persoon links in het figuur automatisch alle autorisaties rechts in het figuur. Van een persoon kan ook bepaald worden welke autorisaties deze toegekend heeft gekregen door te kijken welke business rol(len) de persoon heeft en deze te combineren met de autorisaties in de applicatierol(len). Ook kan in dit model vanuit een specifieke autorisatie bepaald worden welke accounts toegang hebben tot een bepaalde autorisatie door te bepalen in welke applicatierol de autorisatie is opgenomen, welke bedrijfsrol(len) gekoppeld zijn aan de applicatierol en welke accounts aan de bedrijfsrol gekoppeld zijn. Qua beheer en efficiency is RBAC een handig model wat mede door gemeenten op grote schaal wordt toegepast.
Aan het RBAC-model kleven naast voordelen ook een aantal knelpunten. Het eerste knelpunt is geneste rollen en groepen. Denk hierbij bijvoorbeeld aan groepen die lid zijn van een andere groep. Het zicht op de autorisaties raakt door deze nesting snel verloren. De vraag wie mag wat, en waarom iemand iets mag is bij het nesten van rollen al snel onduidelijk. Het is bijvoorbeeld goed mogelijk dat iemand vanuit verschillende toegekende rollen dezelfde autorisatie heeft. Bij het gebruik van de autorisatie is dan niet te herleiden vanuit welke specifieke rol iemand handelt. Het is wel bekend dat de persoon een autorisatie heeft, maar waarom diegene de autorisatie gebruikt is onduidelijk. Een ander nadeel van RBAC is dat in de loop van de tijd veel rollen ontstaan, rollen qua inhoud statisch zijn en de nesting van deze rollen vaak in het verloop van de tijd onduidelijk is. Hierdoor is het overzicht van autorisaties niet helder is het dus ook lastig om iemand een bepaalde autorisatie te ontnemen. Een account kan immers vanuit verschillende rollen een autorisatie verkrijgen. Zonder helder overzicht van rollen en onderlinge groepering van rollen is het grip krijgen op autorisaties en daarmee in control zijn van toegang tot functies en resources lastig. Dit is dus een governance probleem. Een ander governance issue bij het RBAC-model is het toepassen van functiescheiding. Functiescheiding is een manier om taken, bevoegdheden en verantwoordelijkheden van elkaar te scheiden zodat ze niet in één hand liggen. Functiescheiding is feitelijk een risicomanagement methodiek om fraude, misbruik en fouten bij het uitvoeren van processen te voorkomen. Op het moment dat iemand een rol krijgt, en rollen ook genest worden is het lastig om vast te stellen of iemand de juiste autorisaties heeft en niet ook taken kan uitvoeren die vanuit functiescheiding ongewenst zijn. Onderdeel van functiescheiding is daarnaast ook het voorkomen van belangenverstrengeling. Op het moment dat bij het uitvoeren van een taak niet eenduidig vast te stellen is voor welk doel een autorisatie gebruikt wordt is het voorkomen van belangenverstrengeling lastig. Een laatste belangrijke beperking van RBAC is het ontbreken van context bij autorisaties. Stel dat een medewerker bij de belastingdienst de rol heeft van medewerker voor het afhandelen van aanvragen voor toeslagen. Stel dat alle medewerkers binnen deze rol hebben dezelfde autorisaties, ervaring en competenties hebben en iedere medewerker binnen de rol alle soorten toeslagaanvragen mag afhandelen. Daarnaast is het zo dat een medewerker niet zijn eigen aanvraag voor een toeslag mag afhandelen. In dat geval is de context (een eigen aanvraag) dus bepalend voor de toegang. Het RBAC-model voorziet niet in deze contextbeperking. Dus als bijvoorbeeld iemand alleen onder kantooruren mag werken, of alleen vanaf een bepaalde locatie voorziet het RBAC-model niet in deze context beperking.
Het RBAC-model is vanuit beheeroogpunt ideaal maar het levert vanuit governance oogpunt dus helaas niet de controle en governance die gewenst is. Als het RBAC-model gehanteerd wordt moet er dus iets worden toegevoegd om die controle rondom de context wel te verkrijgen. Om dit vraagstuk op te lossen is onderstaand Access Governance model ontwikkeld.
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.
Federatie van identiteiten[bewerken]
Een gemeente is verantwoordelijk voor het beheer van de identiteiten van de medewerkers van de eigen organisatie. Dit beheer betreft de inhuur, instroom, doorstroom en uitstroom processen en daaraan voortvloeiende IT-voorzieningen zoals een Active Directory en Windows. De gemeente heeft in de HR-processen geborgd dat de medewerker is wie hij zegt dat hij is en de organisatie heeft een inschatting gemaakt van de risico’s die de organisatie loopt door bijvoorbeeld een Verklaring Onbesproken Gedrag (VOG) te eisen. Voor identiteiten van buiten de eigen organisatie ligt het beheer idealiter gezien ook buiten de organisatie. Een voorbeeld is hierbij de identificatie van burgers via DigiDn of eIDAS. De uitvoering van de processen rondom het herkennen en erkennen van de identiteit van burgers ligt hierbij bij de overheid. Gemeenten kunnen voor het identificeren van burgers gebruik maken van deze gefedereerde DigiD identiteit. Gemeenten vertrouwen er daarbij op dat de overheid de processen rondom de identiteiten op orde heeft en betrouwbare identiteiten levert. Op basis van dit vertrouwen geeft de gemeente vervolgens op basis van eigen toegangsregels deze gefedereerde identiteiten toegang. De gemeente kent de personen achter de identiteiten niet maar geeft ze op basis van het vertrouwen van de identity provider (in dit geval de overheid) toegang. Het identiteitenbeheer (identiteiten en authenticatiemiddelen) ligt dus bij de overheid terwijl het toegangsbeheer de verantwoordelijkheid van de gemeente is.
Welke identity providers worden vertrouwd als betrouwbare providers is bij het gebruik van gefedereerde identiteiten de verantwoordelijkheid van de organisatie die diensten aanbied. In de commerciële sector worden bijvoorbeeld partijen als Google, Facebook en Apple veel gebruikt als identity providers. Binnen de overheid zijn de providers die gebruikt mogen worden gelimiteerd vanuit wetgeving. De Wet digitale overheid (Wdo) beschrijft de eisen die gesteld worden aan identity providers die in het publieke domein gebruikt mogen worden.
Zero Trust concept[bewerken]
Het zero trust concept is beschreven in de NIST 800-207. In dit model wordt een verzoek tot toegang tot een resource gevalideerd door een Policy Enforcement Point (PEP). Dit component borgt dat van ieder verzoek wat wordt gedaan op basis van toegangsregels wordt bepaald of de identiteit die het verzoek doet toegang mag krijgen tot de resource. Het maakt hierbij niet uit of de identiteit een lokale- of een gefedereerde identiteit is. De bepaling of aan de toegangsregels voldaan wordt is de verantwoordelijkheid van een Policy Decision Point (PDP). Het PEP biedt een aantal attributen, waaronder de identiteit en het type identity provider, aan het PDP aan. Het PDP zal op basis van deze attributen de toegangsregels uitvoeren en het resultaat terugkoppelen aan het PEP. Het PEP geeft op basis van die uitkomst wel of geen toegang tot de resource.
De toegangsregels worden via een Policy Administration Point (PAP) beschreven en vastgelegd. Het PDP heeft de mogelijkheid om naast de attributen die van het PEP ontvangen worden op basis van toegangsregels nog andere attributen op te vragen bij informatiesystemen. Het kan dit zelf doen of het kan hiervoor een Policy Information Point (PIP) gebruiken.
Projectie van Zero Trust concept op NORA referentiemodel[bewerken]
.png)
Als de concepten van het zero trust model worden geprojecteerd op de NORA referentiearchitectuur op het gebied van identity en access management dan ontstaat onderstaand beeld. Het onderdeel ‘Toegang verlenen’ van het model wordt ingevuld door een policy enforcement en een policy decision point. Het beheer van de bevoegdheden kan in dit model worden uitgevoerd met behulp van een policy administration point. In de evealuatie van de toegangsrechten kan gebruik worden gemaakt van de attributen die van de identity provider ontvangen worden. Deze attributen zullen bij gebruik van de voor de overheid toegestane middelen onder andere de identiteit, het type authenticatiemiddel en het betrouwbaarheidsniveau van het middel zijn.
Door toepassing van het bovenstaande model ontstaat een dynamiek die bij toegangsverlening op het gebied van toegekende rollen (RBAC) ontbreekt. Door gebruik te maken van attributen en policies is toegangsverlening op basis van context mogelijk gemaakt. Het is mogelijk om in de afweging van toegangsverlening attributen mee te nemen als de tijd van de dag of de locatie van waar de identiteit is aangemeld. Ook is het mogelijk om bijvoorbeeld het BSN, OIN of intern HR-id van de aangemelde identiteit in een toegangsregel mee te nemen. Hierdoor wordt het bijvoorbeeld mogelijk om te borgen dat een medewerker een bepaalde transactie enkel mag afhandelen als de medewerker zelf niet betrokken is als belanghebbende binnen de transactie. Een medewerker mag bijvoorbeeld geen vergunningsaanvraag afhandelen waarvoor hij of zij zelf de aanvrager is.
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.