Autorisatiematrix
In dit artikel
Wat is een Autorisatiematrix?
Een autorisatiematrix is een document, tool of systeem dat gedetailleerd beschrijft welke gebruikers of groepen toegang hebben tot specifieke applicaties, data of andere faciliteiten binnen je organisatie. Daarmee is het een belangrijk hulpmiddel bij je account- en toegangsbeheer en je ondersteunt ermee je informatiebeveiliging en compliance.
Zo’n autorisatiematrix heeft twee doelen:
- De matrix vormt de bron voor alle gebruikersrechten zoals die binnen je Identity en Access Management (IAM) platform worden verstrekt en beheerd. Het IAM zorgt dat alle gebruikers toegang krijgen tot alle benodigde applicaties, gegevens en andere middelen.
- Het is daarmee tegelijkertijd ook de ‘single truth’ waarop bij audits of na een beveiligingslek kan worden teruggegrepen om alle toegangsrechten te inventariseren en bijvoorbeeld een audit trail te maken.
Een autorisatiematrix is noodzakelijk om te voldoen aan het ‘Principle of Least Privilege’ (PoLP), een leidend principe binnen beveiligingsnormen zoals ISO 27001 en de Algemene verordening gegevensbescherming (AVG). Dit principe houdt in dat iedere medewerker altijd alleen rechten krijgt voor die applicaties, data en faciliteiten die een medewerker echt nodig heeft om zijn of haar werk te kunnen doen. Ieder gebruiker krijgt als het ware toegang op basis van het ‘Need to know’ principe. Dit in tegenstelling tot bijvoorbeeld kleine start-ups waar vaak alle gebruikers toegang hebben tot alle faciliteiten; tenzij het echt zeer specifieke, vertrouwelijke informatie betreft. Dit wordt wel het ‘open, tenzij’ principe genoemd.
IAM systemen worden veelal ingericht op een need to know basis en om dat beheersbaar te doen is een autorisatiematrix noodzakelijk.
Is een autorisatiematrix verplicht?
Met betrekking tot beveiligingsrichtlijnen zoals ISO 27001 of BIO wordt vaak verwezen naar een autorisatiematrix maar tegelijkertijd is zo’n matrix niet officieel verplicht. Er is ook niet een vaste richtlijn over hoe zo’n matrix eruit moet zien en hoe deze moet worden geïmplementeerd. Het is meer een algemene term voor één centrale, gestructureerde en beheerde registratie van alle autorisatieregels. En zo’n registratie is simpelweg noodzakelijk om te kunnen voldoen aan actuele beveiligings- en privacy richtlijnen. Zo wordt binnen ons eigen HelloID platform niet letterlijk een matrix gebruikt, maar borgen we het autorisatiebeheer via een set gestructureerde business rules.
Overigens heb je ook nogal eens autorisatiematrices op twee of meer niveaus binnen organisaties:
- Op organisatorisch/bestuurlijk niveau gaat het dan veelal om de rechten en verantwoordelijkheden rondom complete (deel)processen en groepen data. Wie is bijvoorbeeld de business eigenaar van alle klantgegevens en klantsystemen?
- Op meer operationeel niveau (zoals in het IAM systeem) is een autorisatiematrix veel gedetailleerder en gaat het om de toegang tot specifieke systemen en data shares.
Autorisatiematrix opstellen
Hoe moet je zo’n autorisatiematrix opstellen en is er een standaard autorisatiematrix template? Er zijn natuurlijk templates te vinden maar we gaven al aan dat de daadwerkelijke inrichting afhankelijk is van de organisatie en de gebruikte beheertoepassingen. Maar in essentie komt het opstellen van een autorisatiematrix altijd neer op volgende zaken:
- Identificeer de resources, ofwel alle informatiesystemen, applicaties, databases, en fysieke locaties waarvoor toegangsbeheer nodig is.
- Definieer gebruikers, gebruikersgroepen of rollen waarvoor je rechten moet verstrekken en beheren.
- Bepaal voor de verschillende gebruikers(groepen) en rollen tot welke systemen, applicaties en andere faciliteiten ze op een ‘need to know basis’ toegang moeten krijgen.
- Toegangsrechten kunnen vervolgens ook nog een extra verdiepingsniveau krijgen. Bijvoorbeeld in de vorm van de toegestane acties (inzien, bewerken, verwijderen etc.). En bijvoorbeeld in de zorg wordt bij de toegang tot zorgsystemen vaak een extra ‘scope’ aangebracht: iemand krijgt dan alleen toegang tot de data van een bepaalde locatie of groep cliënten.
Deze informatie moet je vervolgens in je IAM systeem verwerken. Je zag al in stap 4 hierboven dat bij het verdiepen van toegangsrechten zo’n autorisatiematrix feitelijk multi-dimensionaal wordt. Dan is een gewone tabelstructuur eigenlijk te beperkt en mede daarom maken we in ons HelloID platform gebruik van zogeheten business rules. Die zijn flexibeler en veelzijdiger, en je kun ze via een gebruiksvriendelijke interface rechtstreeks online in het HelloID platform invoeren, inzien, beoordelen en aanpassen.
Het in kaart brengen van alle gebruikers(groepen), rollen en hun rechten kan in een grotere organisatie behoorlijk ingewikkeld zijn. Je moet een complete analyse maken van de bestaande organisatiestructuur en alle bedrijfsprocessen. Een nuttig hulpmiddel om toch snel en eenvoudig een eerste autorisatiematrix te maken, is zogenaamde role mining. Daarbij maak je een slimme analyse van de al bestaande gebruikers en hun toegangsrechten om van daaruit een eerste versie van de autoriteitsmatrix te kunnen maken.
Wat zijn alternatieven voor een autorisatiematrix?
Er is niet zozeer een alternatief voor de autorisatiematrix zelf. We gaven al aan dat het meer een algemene term is voor een document of tool om gestructureerd toegangsrechten te registreren en beheren. Maar op wélke wijze je die toegangsrechten organiseert, kan verschillen. We schetsen hieronder wat mogelijke vormen voor dat toegangsbeheer:
| Vormen autorisatiebeheer | Toelichting |
|---|---|
| Access Control List (ACL) | Hierbij wordt de toegang tot systemen en gegevens per individuele gebruiker beheerd. Hiermee zit je het dichtst bij het basisconcept van een autorisatiematrix. Voor kleine systemen en organisaties werkt dit goed, voor grotere omgevingen wordt dit al snel lastig te beheren. |
| Role Based Access Control (RBAC) | Bij RBAC organiseer je je toegangsrechten niet per persoon maar op basis van de rollen of functies die mensen kunnen vervullen binnen een organisatie. Dus een verkoper krijgt andere toegangsrechten dan een administrateur. |
| Attribute Based Access Control (ABAC) | ABAC lijkt op RBAC maar is flexibeler – maar ook ingewikkelder - omdat meer eigenschappen (attributen) van de gebruikers, applicaties en data kunnen worden gebruikt. Om toegang tot bepaalde gegevens te krijgen moet iemand bijvoorbeeld én een bepaalde rol hebben, maar ook geautoriseerd zijn voor gegevens met een bepaald classificatieniveau. |
| Policy Based Access Control (PBAC) | Bij PBAC maak je gebruik van beleidsregels om te bepalen wie toegang heeft tot welke gegevens en applicaties. Zo kun de toegang tot applicaties afhankelijk maken van de tijd van de dag (bijvoorbeeld alleen werktijd), het gebruikte toegangsnetwerk of de gevoeligheid van de data. |
Dit zijn wat verschillende manieren om toegangsrechten te organiseren en structureren. Elk van de beschreven ‘control mogelijkheden’ heeft eigen voor- en nadelen, afhankelijk van de het type organisatie, de grootte en de gevoeligheid van de gegevens die worden beheerd. Ook zul je in de praktijk vaak zien dat geavanceerde IAM oplossingen een combinatie van dit soort methodes gebruiken voor hun autorisatiebeheer.
IAM en autorisatiematrix
Hoe gebruik je een autorisatiematrix om je Identity en Access Management in te richten. In veel IAM oplossingen – en dat geldt ook voor HelloID – wordt Role Based Access Control genoemd als uitgangspunt voor je toegangsbeheer. Logisch, want RBAC sluit goed aan op het Least Privilege principe; per rol bepaal je welke toegangsrechten nodig zijn.
Maar feitelijk biedt HelloID een uitgebreider mechanisme om je autorisatieregels te beheren, namelijk ABAC. Attributen zijn allerlei mogelijke kenmerken van gebruikers. Dat kan iemands rol of functie zijn inderdaad, maar bijvoorbeeld ook de afdeling waar iemand werkt, of diens werklocatie. We kunnen toegangsrechten toekennen aan de hand van combinaties van zulke attributen en die flexibiliteit maakt het systeem erg krachtig. We geven hieronder wat voorbeelden van zulke business rules:
- We kunnen door middel van een business rule eenvoudig configureren dat iemand met de functie ‘zorgmedewerker’ naast standaard M365 software ook toegang krijgt tot het Elektronisch Cliënt Dossier (ECD). Dit is dus een rol-gebaseerd toegangsrecht.
- Je kunt zo’n toegangsrecht nog verdiepen door ook andere attributen te gebruiken. Zodat een zorgmedewerker alleen nog toegang krijgt tot de ECD gegevens van cliënten die worden behandeld in de locatie en afdeling waar de betreffende medewerker zelf werkt.
- Business rules ondersteunen ook de tijdsfactor. Je kunt dan bijvoorbeeld al een aantal dagen voorafgaand aan iemands onboarding de benodigde autorisaties verstrekken. En je kunt een account bij beëindiging van het contract blokkeren maar nog wel de bijbehorende autorisaties gedurende een grace-periode in het systeem laten staan
Je kunt met HelloID overigens ook nog individuele optionele toegangsrechten verstrekken. Bijvoorbeeld een specifieke applicatie voor een tijdelijk project. Zo’n recht volgt dus niet uit attributen of beleidsregels en daarom beheren we deze rechten ook niet via algemene business rules. In plaats daarvan gebruiken we hiervoor de HelloID Service Automation module. Die automatiseert en registreert de online aanvraag van zulke optionele aanvragen; inclusief de controle en goedkeuring, de uitgifte en desgewenst ook weer het tijdig intrekken ervan.
Je ziet dat HelloID je de flexibiliteit geeft om binnen je IAM omgeving verschillende beheermaatregelen te combineren en zo je IAM autorisatiematrix precies te tunen op jouw organisatie.
Meer weten over het inrichten van je autorisatieregels en autorisatiematrix met behulp van HelloID business rules? Bekijk onze webinar.
Autorisatie is het proces waarbij wordt bepaald of een gebruiker – of een systeem of applicatie – toegang krijgt tot specifieke applicaties, gegevens of andere IT-middelen. Eerste stap is veelal het verifiëren van de identiteit van de aanvrager. Bij gebruikers gaat dat nog vaak met een gebruikersnaam en wachtwoord. Na deze authenticatie bepaalt de autorisatie welke toegangsrechten iemand heeft en welke handelingen zijn toegestaan. Die handelingen kunnen variëren van alleen inzien van gegevens tot het wijzigen en verwijderen ervan.
Een ACL, of Access Control List, is een beveiligingsmethode in digitale netwerken waarbij per gebruiker is vastgelegd tot welke applicaties, gegevens en andere IT resources iemand toegang krijgt. Omdat dit per individuele gebruiker wordt beheerd, is dit bij uitstek geschikt voor een kleinere organisatie of één systeem. In grotere omgevingen wordt meestal gewerkt met bijvoorbeeld Role Based Access Control (RBAC) waarbij de toegangsrechten afhankelijk zijn van iemands rol in de organisatie.
Binnen Identity en Access Management verwijst de term ‘need to know’ naar een beleidsregel voor toegang tot systemen. Bij ‘need to know’ krijgen gebruikers alleen toegang tot systemen en data die iemand nodig heeft om zijn of haar werk te kunnen doen. een zorgmedewerker krijgt bijvoorbeeld alleen toegang tot het medische dossier van de cliënten waar hij of zij voor zorgt. ‘Need to know’ wordt vaak verward met ‘least privilege’. Beide concepten lijken op elkaar maar officieel zegt ‘need to know’ alleen iets over de toegangsrechten, terwijl ‘least privilege’ ook iets zegt over iemands machtigingen; wat mag hij of zij doen met de gegevens.