Als je te maken hebt met computersystemen, dan heb je automatisch te maken met wat 'logische toegangscontrole' wordt genoemd. Logische toegang gaat over de vraag hoe de toegang tot de informatie en functies binnen systemen voor personen of identiteiten is geregeld. Makkie zul je denken, maar het omvat echter veel meer dan dat.

In dit artikel leggen we uit wat het begrip 'logische toegangscontrole' in de wereld van compliance inhoudt.

Digitale rechten, een zakelijk mandaat

Toegang tot computersystemen stelt medewerkers in staat hun werk te doen. In de regel is dit precies hoe tegen rechten wordt aangekeken: als iets is geblokkeerd, dan is dat vooral lastig. Wat onvoldoende wordt gerealiseerd, is dat logische toegang veel meer betekent dan een technische hindernis.

Het werk dat gedaan moet worden bestaat bijvoorbeeld uit het betalen van facturen. Toegang verlenen tot de 'betaalfunctie' betekent ook direct dat een mandaat wordt toegekend om een betaling te mogen doen. En natuurlijk is het niet de bedoeling dat onbevoegde personen in jouw organisatie zomaar toegang zou kunnen krijgen tot dat mandaat.

Uit de organisatiekunde weten we: wie mandaat toekent die delegeert, wie delegeert die controleert, aan wie is gedelegeerd legt daarover verantwoording af.

De kloof tussen beleid en praktijk

In theorie is de keten helder. De directie delegeert een mandaat aan bijvoorbeeld een manager, de manager wijst bevoegdheden toe aan medewerkers, en de IT-afdeling of leverancier richt dit technisch in.

In de dagelijkse praktijk zien we echter nooit een nauwkeurige 'reflectie' van wat het formele mandaat is en wat de informatiesystemen op basis van de toegekende rechten suggereren dat het mandaat zou zijn. Het is precies die kloof die, als het eenmaal misgaat, allerlei ingewikkelde vragen oproept.

Want stel dat een onbevoegde medewerker vertrouwelijke salarisgegevens inziet of een ongeoorloofde betaling verricht: wie treft dan welke blaam? De medewerker zou kunnen stellen: ik heb toch de rechten gekregen, de manager wijst misschien naar IT en IT wijst terug naar de manager die nooit een verzoek heeft ingediend om oude rechten in te trekken.

Je bespeurt het waarschijnlijk al: logische toegang gaat niet over de technische knopjes in een systeem, maar over het gehele proces rondom die toewijzing — waarvan de techniek slechts de laatste, concretiserende stap is.

Van ontwerp naar techniek

Zoals je hebt kunnen lezen zou de 'logische toegang' een weerspiegeling moeten zijn van de wijze waarop processen zijn vormgegeven en afgeleide taken, bevoegdheden en verantwoordelijkheden zijn opgeknipt naar functies en rollen.

Toegang ontstaat nooit in een vacuüm. Om ervoor te zorgen dat systemen het beleid ondersteunen in plaats van ondermijnen, moet een organisatie een vaste, drieledige hiërarchie respecteren.

1. Het organisatorische procesontwerp (de blauwdruk)

Dit klinkt omvangrijk, maar hiermee bedoelen we soms niet meer dan een schetsje van de belangrijkste processen en de positie van rollen en functies binnen deze processen. Binnen de ISO wordt vaak gebruikgemaakt van een RACI-matrix in combinatie met een  procesplaat of organogram. Zolang de uitwerking maar duidelijk maakt wat de taken en bevoegdheden zouden moeten zijn van deze personen.

2. HR-Cyclus (operationele koppeling)

In de praktijk zien we vaak dat de voorgaande ontwerpen de basis vormen voor vacatureteksten en functieomschrijvingen. Het zijn deze werkdocumenten waarmee HRM via werving (instroom), personeelsontwikkeling (doorstroom) en verloop (uitstroom) personele invulling geeft aan het ontwerp. Wat oneerbiedig, De HR-Cyclus koppelt een levend persoon aan de vooraf gedefinieerde rol.

Een veelgebruikte methode is om 'HR checklijstjes' te koppelen aan elk van de fasen van de HR-cyclus. Bijvoorbeeld het toekennen van logische toegang bij indiensttreding, het wijzigigen van rechten bij doorstroom en het ontnemen van rechten bij uitstroom.

3. De technische inrichting (het sluitstuk)

Pas hier komt de IT-afdeling of leverancier om de hoek kijken. Het meest risicovolle in deze stap is dat terplekke bedacht moet worden wat een 'juiste' vertaling van het beoogde mandaat in de techniek is of zou moeten zijn.

Zodra je IT-beheerders of leveranciers hierna vraagt, word je al snel overspoeld met afkortingen en vaktermen: RBAC, Least privilege, security groups, IAM, recertificering, CRUD authorisatie matrixen,AGDLP enzovoorts. Het voelt alsof je raketwetenschapper moet zijn en al dit jargon moet begrijpen. In de basis dient al deze jargon slechts één doel: voorkomen dat iemand achter de knoppen moet gissen naar wat jij mag.

Wat toezichthouders écht willen zien

Wanneer een toezichthouder, externe accountant of ISO-auditor over de vloer komt, ontstaat er bij veel organisaties lichte nervositeit. Men verwacht een diepgaande technische inspectie van firewalls of cryptografische instellingen. Maar wie een willekeurig auditrapport openslaat, ziet dat - hoewel die technische basis zeker telt - de formele waarschuwingen en afwijkingen zelden over bits en bytes gaan. Ze gaan over ontbrekende handtekeningen, slapende accounts van oud-collega's en het ontbreken van structureel overzicht.

Een toezichthouder zoekt geen technologische hoogstandjes. Een toezichthouder zoekt aantoonbare beheersing. De mate waarin de technische rechten en permissies een zuivere 'weerspiegeling' zijn van het beleid, is daarvoor de belangrijkste graadmeter.

Het kernbegrip voor elke auditor is accountability: kun je bewijzen dat toegang geen ad-hoc toevalligheid is, maar een doordacht ontwerp en een bewust besluit van het management? Precies daarom toetsen toezichthouders de inrichting van de logische toegang vrijwel altijd langs dezelfde beproefde cyclus: Design – Build – Run – Validate.

1. Design (ontwerpen)

De auditor vraagt simpelweg: “Laat mij zien wat de bedoeling is.”

Met deze vraag toetst de auditor wat in vaktermen de 'opzet' heet. Is er vooraf bewust nagedacht over wie wat mag en waar de risico’s zitten? Denk hierbij aan autorisatiematrices, RACI’s en functieomschrijvingen, met als belangrijke pijlers zoals functiescheiding en beperking van toegang (datareductie) en rechten (least-privilege).

Het ontwerp moet onder andere aantonen dat fouten, diefstal en fraude systematisch worden bemoeilijkt of voorkomen. In de klassieke leer van Starreveld spreken we over de strikte scheiding tussen beschikkende, bewarende en registrerende bevoegdheden.

2. Build (het bestaan)

    

De auditor vraagt: “Laat mij zien dat het ook daadwerkelijk zo gebouwd is.”

In auditland heet dit de toets op het bestaan. De auditor wil bewijs zien dat het papieren ontwerp niet in een bureaula is blijven liggen, maar ook echt is vertaald naar de 'logische toegang' in het systeem.

Hier wordt in de regel gebruikgemaakt van gestandaardiseerde rolprofielen (Role-Based Access Control of RBAC). Het toekennen van rechten op persoonsniveau is veel te foutgevoelig. Daarom richt IT afgebakende 'mandjes' of groepen in volgens het least privilege-principe: zo'n groep krijgt uitsluitend de rechten die strikt noodzakelijk zijn voor die specifieke rol, waarna medewerkers met die functie aan de groep worden gekoppeld.

De auditor controleert hier of de techniek de afgesproken functiescheiding ook echt afdwingt: kan de inkoper in het ERP-pakket technisch überhaupt op die fiatteringsknop drukken, of weigert het systeem de handeling simpelweg?

3. Run (de uitvoering/werking)

De auditor vraagt: “Laat mij zien hoe dit het afgelopen jaar in de praktijk heeft gefunctioneerd.”

In auditland heet dit de toets op de werking. Een auditor neemt geen genoegen met een fraai beleidsdocument of een systeem dat toevallig op de dag van de audit goed staat ingeregeld. De kernvraag is: heeft het proces gedurende het gehele controlejaar continu, consistent en aantoonbaar gewerkt?

Om dat vast te stellen, trekt de auditor meestal een aselecte steekproef uit de personeelsmutaties van HR en volgt het digitale spoor (de audittrail): vanaf de formele indiensttreding of functiewijziging, via de opdracht aan IT, tot aan de daadwerkelijke toewijzing in de systemen.

In deze fase moet de organisatie aantonen dat IT nooit op eigen houtje bevoegdheden wijzigt, maar dat elke technische mutatie een direct en herleidbaar gevolg is van een formele HR-gebeurtenis. Daarnaast toetst de auditor vaak het omgekeerde: kan de organisatie aantonen dat eventuele rechtstreekse ingrepen door beheerders direct worden gesignaleerd en verantwoord? Dit voorkomt dat beheerders buiten het zicht om uitzonderingen of 'outliers' creëren die nergens zijn vastgelegd.

4. Validatie (periodieke controle en verantwoording)

De auditor vraagt: “Hoe weet je zeker dat het vandaag de dag nog steeds klopt?”

Zelfs met een waterdicht ontwerp, nette rolprofielen en een strakke HR-koppeling sluipt er in de loop van de tijd altijd vervuiling in. Een medewerker krijgt tijdelijk extra rechten voor een spoedklus, een projectgroepje wordt na afronding vergeten, of iemands takenpakket verschuift geleidelijk zonder dat de officiële functietitel verandert.

De breed geaccepteerde maatregel hiervoor is het inrichten van periodieke controles of recertificering. De auditor wil zien dat er van tijd tot tijd gecontroleerd wordt en onjuistheden aantoonbaar worden getoetst en geschoond.

De cruciale fout die hier vaak gemaakt wordt, is dat IT gevraagd wordt om deze lijstjes op te schonen. Maar een IT-beheerder kan vanaf de zijlijn onmogelijk beoordelen of medewerker X die toegang tot de crediteurenadministratie nog wel nodig heeft. IT beheert immers slechts de knoppen, niet het mandaat.

De auditor zoekt daarom naar bewijs van de échte sturingscyclus:

• Krijgt de verantwoordelijk manager minimaal één of twee keer per jaar een helder overzicht van alle actieve accounts en toegekende rechten binnen zijn of haar team?
• Wordt dat overzicht daadwerkelijk kritisch beoordeeld, of is het een blinde paraaf?
• En als de manager constateert dat een recht niet langer nodig is: wordt de opdracht tot intrekking dan direct doorgevoerd en vastgelegd?

Pas na deze stap is de cirkel definitief rond.

Het brengt ons exact terug bij het organisatiekundige uitgangspunt waar we mee begonnen: wie delegeert, die controleert. Door die controle aantoonbaar bij de verantwoordelijke manager te beleggen, is logische toegang geen technisch hoofdpijndossier meer, maar een beheerst en volwassen bedrijfsproces.