In mijn vorige blog heb ik de eisen die de Baseline Informatiebeveiliging Overheid (BIO) stelt als het gaat om toegangsbeveiliging (hoofdstuk 9) toegelicht. Eén van de punten die ik daar heb benoemd is het goed inrichten van autorisaties. Een handig hulpmiddel hierbij is een autorisatiematrix. Maar hoe stel je zo’n autorisatiematrix op? IB&P heeft een tien stappenplan gemaakt om je hierbij te helpen. In deze blog zal ik ingaan op hoe je zo’n autorisatiematrix opstelt én borgt binnen je organisatie.

Waarom belangrijk?

Het is belangrijk dat er controle is op iemands toegangsrechten vanaf het moment van indiensttreding tot en met de beëindiging van het contract. Dit geldt voor zowel toegang tot bepaalde applicaties als toegang tot bepaalde ruimtes en/of gebouwen. Ook moeten bij functiewijzigingen van medewerkers en uitdiensttreding autorisaties zo spoedig mogelijk worden aangepast.

Echter, autorisatiebeheer binnen je organisatie inrichten én op orde houden, is vaak een lastige en tijdrovende klus. Om dit proces rondom autorisaties goed in te richten, kun je een autorisatiematrix gebruiken. Met een autorisatiematrix kun je inzien wie binnen de organisatie toegang heeft tot welke informatie en waarom. Elk (kritisch) systeem zou een autorisatiematrix moeten hebben waarin is vastgelegd welke medewerker (of rollen) rechten tot het systeem zou moeten hebben. Het is daarbij ook belangrijk om te controleren of de autorisaties die zijn vastgelegd in de matrix juist zijn.

Tien stappenplan

Vanuit IB&P hebben wij een tien stappenplan opgesteld, waarmee je een autorisatiematrix kunt opstellen. Normaal gesproken gaan wij met de klant in gesprek en nemen we deze stappen gezamenlijk door om te bepalen wat nodig is binnen de huidige organisatie en wat er mogelijk al gerealiseerd/aanwezig is. In deze blog neem ik jullie graag mee door deze tien stappen, zodat je hier als gemeente ook zelf mee aan de slag kunt.

Stap 1: Inventarisatie vooraf

Allereerst moet er een inventarisatie worden gemaakt van de applicaties die een autorisatiematrix nodig hebben. Het gaat in de meeste gevallen om kritieke applicaties binnen de organisatie. Deze stap is in dit geval reeds concreet, want mogelijk heeft de gemeente al een applicatielijst waarmee je kunt bepalen welke applicaties in scope zijn. Val niet in de valkuil om in één keer voor alle applicaties een autorisatiematrix op te willen stellen, maar stel de scope (net zoals de BIO aangeeft) vooral in op de risicovolle applicaties. 

Stap 2: Inventarisatie van gebruikersgroepen

Als je hebt bepaald welke applicaties in scope zijn, kun je vervolgens per applicatie in kaart brengen welke gebruikersgroepen er zijn. In eerste instantie kunnen deze vaak verdeeld worden naar afdelingen of bepaalde functies. Neem bijvoorbeeld de applicatie Basisregistratie Personen (BRP), de afdeling Burgerzaken heeft toegangsrechten nodig tot dit systeem, maar ook bepaalde medewerkers vanuit het Sociaal Domein. Voor deze applicatie kun je dan aangeven dat de afdeling Burgerzaken toegangsrechten nodig heeft, maar ook bepaalde functies vanuit andere afdelingen. Zo krijg je heel inzichtelijk wie er toegang nodig heeft tot welk systeem.

Stap 3: Huidige rechten beoordelen

Ofwel, welke rechten zijn nodig voor de diverse medewerkers of rollen. Simpelweg hebben medewerkers alleen toegang nodig tot de informatie en systemen die zij nodig hebben voor het uitvoeren van hun werk, ook wel het ‘need-to-know principe’ genoemd. Zo heeft bijvoorbeeld een receptioniste niet dezelfde rechten nodig als een administratief medewerker. De administratief medewerker moet voor zijn rol bijvoorbeeld informatie kunnen muteren, iets wat een receptioniste niet hoeft te doen bij het uitvoeren van zijn of haar taak. Ook zijn de toegangsrechten weer onder te verdelen in verschillende categorieën. Zo kun je iemand bijvoorbeeld de rechten ‘inzien’, ‘bewerken’ of ‘verwijderen’ geven. Het is van belang om de huidige inrichting van een applicatie te beoordelen om te zien of de juiste medewerkers de juiste rechten hebben. Je gaat hierbij uit van de zogenoemde IST-situatie.

Stap 4: Rechten waar mogelijk groeperen in huidige inrichting

Nu je per gebruikersgroep in kaart hebt gebracht welke rechten zij nodig hebben, kun je kijken naar of bepaalde rechten ook overeenkomsten hebben waarvan een type autorisatie (rol) gemaakt kan worden. Aan deze rol koppel je dan de bijhorende rechten. Dit geldt alleen wanneer je de applicatie op RBAC-niveau (Role Based Access Control) kunt implementeren. Dit betekent dat autorisaties niet op individuele basis worden toegekend, maar op basis van RBAC-rollen. Een voorbeeld: Iemand vervult de rol van baliemedewerker bij het klantcontactcentrum van de gemeente. Het CRM-systeem waar de medewerker in moet werken kent de rol klantcontactbeheer. De organisatierol ‘baliemedewerker’ wordt gekoppeld aan de informatiesysteemrol ‘klantcontactbeheer’. Daarmee verkrijgt deze medewerker automatisch de rechten die nodig zijn om de CRM-functie van klantcontact te kunnen uitvoeren. Indien er nu ook een andere collega wordt benoemd als baliemedewerker, dan verkrijgt ook deze collega automatisch de rechten die nodig zijn om de CRM-functie van klantcontact te kunnen uitvoeren. Wisselt de collega vervolgens van functie? Dan raakt hij ook automatisch de klantcontactbeheer rechten weer kwijt.

Stap 5: Inventarisatie speciale permissies

Bekijk per applicatie of er nog medewerkers zijn die speciale rechten nodig hebben, zoals bijvoorbeeld een applicatiebeheerder of administrator. Zij hebben vaak andere of extra rechten in een bepaalde applicatie of proces, zoals het uitvoeren van bepaalde updates of handelingen zoals het aanmaken van nieuwe gebruikers. Zorg dat je deze speciale rechten slechts toekent aan een kleine groep medewerkers. Hoe meer mensen speciale rechten hebben, hoe kwetsbaarder je bent voor kwaadwillenden. Het geeft ransomware of een hacker namelijk meer mogelijkheden als die erin slaagt je systeem binnen te dringen.

Stap 6: Stel de autorisatiematrix op

Op basis van de bovenstaande stappen die je hebt uitgevoerd en de informatie die hieruit is opgehaald, kun je dit nu per applicatie of proces allemaal samenbrengen in een autorisatiematrix. Hierin geef je per rol/gebruiker aan welke rechten en groepen daaraan gekoppeld moeten worden. Een autorisatiematrix bestaat uit de volgende onderdelen:

• Naam applicatie
• Naam eigenaar
• Naam beheerder (technisch applicatiebeheer)
• Rollen/gebruikers
• Rechten per rol/gebruiker (gebaseerd op de autorisatie inrichting van de applicatie)

Zie voor een voorbeeld ook bijlage 5 van de ‘Handreiking Beleid logische toegangsbeveiliging BIO‘ van de Informatiebeveiligingsdienst voor gemeenten (IBD).

Stap 7: Controle en vaststelling autorisatiematrix

Nu je de autorisatiematrix hebt opgesteld is het belangrijk om deze te laten controleren en goedkeuren door de verantwoordelijke van de betreffende applicatie. Zij hebben uiteindelijk het beste zicht op het systeem en de bijhorende rechten. Indien het om een afdelingsoverstijgende applicatie gaat, dan zal de systeemeigenaar ook per afdeling bij de afdelingsmanager moeten toetsen of de gebruikers kloppen.

Stap 8: Toepassen van de autorisaties

Als een autorisatiematrix eenmaal is opgesteld, zal de (technisch) applicatiebeheerder deze rechten moeten doorvoeren binnen de applicatie(s). Wanneer er wijzigingen zijn (bijvoorbeeld nieuwe gebruikers, het afvoeren van gebruikers of het aanpassen van rechten van gebruikers) moet dit niet alleen worden bijgehouden in de applicatie maar ook in de autorisatiematrix, zodat deze altijd up-to-date is en de werkelijke situatie weergeeft.

Stap 9: Periodieke controles

Het is belangrijk dat er periodiek controles worden uitgevoerd om te kijken of de autorisatiematrixen nog up to date zijn of dat er aanpassingen nodig zijn. Zeker in grote organisaties vinden veel veranderingen plaats en is er veel wisseling/doorstroom van personeel. Als een collega een team/afdeling verlaat, moet er gecheckt worden of er iets aangepast moet worden als het gaat om zijn of haar rechten binnen een systeem. Daarnaast moet je bij een aanvraag voor toegang tot een systeem ook kritisch bekijken of iemand die toegang wel echt nodig heeft. De verantwoordelijkheid hiervoor ligt bij de leidinggevende. Laat hen bijvoorbeeld vaste momenten in hun agenda reserveren waarop zij controleren of iedereen de juiste rechten heeft. Dan is het goed bij te houden en kost het uiteindelijk minder tijd. Ook is de kans op het maken van fouten kleiner. Om dit goed te borgen is het belangrijk om dit vast te leggen in bijvoorbeeld procedures of beleid.

Stap 10: Reviews

Tot slot, is het belangrijk dat er periodiek onafhankelijke reviews plaatsvinden (minimaal één keer per jaar) waarbij gekeken wordt naar of de autorisatiematrix nog voldoet of dat zaken moeten worden aangepast (bijvoorbeeld in geval van wijzigingen). In geval van het laatste, dien je de autorisatiematrix ook weer opnieuw te laten vaststellen door de systeemeigenaar. Deze review kan gedaan worden door de CISO, of de CISO kan hiertoe de in- of externe accountantsdienst opdracht geven.

Meer informatie?

Ik hoop je met deze blog meer inzicht te hebben gegeven in de stappen die nodig zijn voor het opstellen van een autorisatiematrix, waardoor je hier zelf mee aan de slag kunt. Heb je naar aanleiding van deze blog vragen of hulp nodig om binnen jouw gemeente verder te komen op dit vlak, neem dan gerust contact met ons op. We helpen je graag!