WMA RBAC ABAC en PBAC

Category:Werken met APIs
__NOTOC__
Er zijn verschillende manieren voor het inrichten van toegangs- en informatiebeveiliging. Role-, Attribute- en Policy Based Access (ABAC, RBAC, PBAC) zijn drie manieren voor inrichten van de informatievoorziening om toegangscontrole en verantwoording mogelijk te maken. Bij RBAC worden beslissing over verlenen van toegang gebaseerd op vooraf gedefinieerde rollen. Bij ABAC wordt rekening gehouden met meerdere attributen terwijl bij PBAC beleidsregels worden geformuleerd op basis waarvan beslissingen over toegang worden genomen. Op basis van de specifieke vereisten en complexiteit van de omgeving waarin toegangscontrole plaats moet vinden kan gekozen worden voor implementatie op basis van 1 van de 3 modellen of voor een hybride model waarbij elementen uit meerdere modellen worden gecombineerd. Bij migratie van een landschap met siloapplicaties naar meer gedistribueerde applicaties die via API's met elkaar communiceren groeit de noodzaak om naast RBAC vaker gebruik te gaan maken van ABAC en PBAC. 
==Role Based Access==
Role Based Access (RBAC) is een veelgebruikt model voor toegangscontrole dat machtigingen verleent aan gebruikers op basis van hun rol binnen een organisatie. Het definieert rollen op basis van functies of verantwoordelijkheden en gebruikers krijgen specifieke rollen toegewezen die hun toegangsrechten bepalen. RBAC vereenvoudigt toegangsbeheer door machtigingen te koppelen aan rollen in plaats van aan individuele gebruikers. Een gebruiker die een rol krijgt toebedeeld krijgt automatisch alle aan de rol gekoppelde autorisaties. Krijgt hij meerdere rollen toebedeeld dan beschikt hij over het totaal aan autorisaties van de betreffende rollen. Bij gebruik van RBAC moet zijn te verantwoorden waarom bij een rol bepaalde autorisaties horen en waarom een gebruiker bepaalde rollen heeft gekregen.
Rollen kunnen zowel op bedrijfsmatig niveau worden gedefinieerd ('bedrijfsrollen') als op applicatieniveau ('applicatierollen'). Koppelen van de bedrijfsmatige rol 'manager' aan de applicatierol 'beslisser' betekent dat alle personen met de rol 'manager' geautoriseerd zijn om beslissingen te nemen. RBAC is veel toegepast model maar kent een aantal nadelen en beperkingen. Bij organisatorische veranderingen moeten veel wijzigingen plaatsvinden, overzicht en inzicht in wie nu precies wat mag ontbreekt vaak en bij aanwezigheid van dezelfde autorisatie via meerdere rollen is niet vast te stellen op basis van welke rol een persoon een handeling heeft uitgevoerd. Bij gebruik van RBAC zijn daarom vaak aanvullende beheers- en beveiligingsmaatregelen nodig wat tot aanvullende kosten leidt. Een steeds belangrijkere beperking is dat het met name is gericht op machtigen van personen terwijl toegang tot bronnen steeds vaker verloopt via, al dan niet door personen gebruikte, applicaties. Binnen een gedistribueerd API-landschap voldoet gebruik van het RBAC-model steeds minder.
==Attribute Based Access Control==
Attribute Based Access Control (ABAC) is een model voor toegangscontrole dat bij het nemen van toegangsbeslissingen rekening houdt met verschillende kenmerken van: 
* gebruikers (bijvoorbeeld rol, afdeling, machtigingsniveau)
* bronnen (bijvoorbeeld gevoeligheid, classificatie)
* context (bijvoorbeeld tijd, locatie) en
* andere relevante contextuele kenmerken.
ABAC maakt een meer geavanceerde toegangscontrole mogelijk dan PBAC waarmee betere beveiliging. naleving en verantwoording mogelijk is. 
Rolbeschrijvingen zijn vaak organisatie- en applicatiespecifiek. Attributen zijn neutraler van aard en kunnen worden gebruikt door meerdere services. Dit gebeutt bijvoorbeeld bij de OAuth autorisatiestandaard. Daarbij worden relevante attributen via tokens doorgegeven zodat gebruikers op een veilige manier applicaties kunnen autoriseren om hun gegevens op een andere website op te halen. Afspraken over het gebruik van deze standaard bij de Nederlandse overheid liggen vast in het NL GOV Assurance profile for OAuth 2.0. 
== Policy Based Access (PBAC) ==
Policy-Based Autorizatie (PBA) is een (organisatie)brede benadering waarbij beslissingen over toegang worden gebaseerd op een verzameling vooraf gedefinieerde beleidsregels. Beleidsregels zijn regels of verklaringen die voorschrijven welke acties onder welke voorwaarden al dan niet zijn toegestaan. 
Voor het opstellen van beleidsregels kan gebruik worden gemaakt van een Policy Language. Daarmee kan allerlei soorten contextuele informatie worden gebruikt om regels te formuleren op basis waarvan toegangsbeslissingen zijn te nemen. Regeldefinities kunnen variëren van eenvoudige "als-dan" voorwaarden tot complexe sets van regel met meerdere voorwaarden en acties. 
Idealiter kunnen beleidsregels worden gemaakt zonder dat uitgebreide IT-kennis nodig is, bijvoorbeeld via een grafische gebruikersinterface. De verantwoordelijkheid voor toegangsbeheer kan daarmee verschuiven van IT-gerelateerde functies naar lijnmanagers die het beste kunnen beslissen wat onder welke voorwaarden is toegestaan. Gaan werken met PBAC betekent daarmee een fundamentele verschuiving van taken en verantwoordelijkheden rondom toegangsbeheer. 
Het ontvlechten van applicatielogica en toegangslogica levert veel voordelen op. Door toegangslogica uit applicaties te halen wordt onderhoud daarvan eenvoudiger. Door beleidsregels te beheren via een gespecialiseerde 'Policy Editor' applicatie kan de verantwoordelijkheid bij de juiste personen worden belegd en zijn veranderingen in wetgeving en beleid sneller en beter te verwerken. Direct na de benodigde aanpassing van beleidsregels is er realtime gebruik van te maken door applicaties die toegangsverzoeken beoordelen en al dan niet inwilligen (in functionele termen 'Policy Decision Points' en 'Policy Enforcement Points'). Bijkomende voordelen als beleidsregels centraal worden beheerd zijn dat toegangscontrole bij verschillende systemen binnen de organisatie uniform en consistent plaatsvindt en een hoge mate van naleving wordt gegarandeerd. 
== Keuzes en groei ==
De keuze voor RBAC , ABAC of PBAC hangt af van de specifieke vereisten en context waarbinnen toegang moet worden beheerd. Factoren die een rol spelen zijn bijvoorbeeld de complexiteit van eisen voor toegangscontrole en de behoefte aan flexibiliteit.
RBAC is met name geschikt als toegangsbeslissingen afhangen van vooraf bekende rollen of functies van gebruikers. Het werkt goed in situaties met relatief statische en goed gedefinieerde gebruikersrollen waar toegangsrechten aan toe te wijzen zijn. ABAC is geschikt als bij toegang rekening moet worden gehouden met meerdere attributen, zoals gebruikers-, bron- en omgevingskenmerken. Via PBAC kan toegangscontrole meer gecentraliseerd, consistent en adaptief worden ingericht. In de praktijk kan een hybride aanpak, met een combinatie van modellen, geschikt zijn om aan de unieke behoeften voor toegangscontrole te voldoen.
Door toenemende digitalisering en interactie tussen systemen via API's groeit de behoefte aan geavanceerde ondersteuning voor toegangscontrole. Het RBAC-model voldoet in steeds mindere mate. Het ABAC-model biedt meer mogelijkheden maar om als organisatie goed grip te kunnen houden op gedistribueerd uitgevoerde toegangscontrole is toewerken naar inrichting volgens het PBAC-model wenselijk. 
De GEMMA, in de rol van referentiearchitectuur, beschrijft hoe het PBAC-model past binnen de gemeentelijke informatiearchitectuur. Werken met API's informatiearchitectuur beschrijft welke GEMMA-referentiecomponenten daarbij een rol spelen en hoe zij samenwerken om PBAC te implementeren. Hoe toegroeien van RBAC naar meer op PBAC-gebaseerd toegangsbeheer het beste kan plaatsvinden is per organisatie verschillend. Contextuele factoren zoals gevoelde noodzaak, ambitie en mogelijkheden spelen daarbij een belangrijke rol.