Je hebt de theorie over Separation of Duties inmiddels wel gehoord. SoD staat in het auditrapport, het principe is uitgelegd, en de noodzaak staat niet ter discussie. De vraag die daarna volgt is een stuk concreter: hoe dwingt de software die dit moet borgen (Identity Governance & Administration, ofwel IGA) SoD eigenlijk af?
Want een principe is één ding. Een product dat er handen en voeten aan geeft is iets heel anders. En tussen IGA-leveranciers bestaan veel grotere verschillen dan de meeste organisaties beseffen.
De ene leverancier ziet SoD als een centrale rolmatrix die door een compliance-team wordt onderhouden. De andere ziet het als een operationele waarborg die in elke aanvraag verweven hoort te zitten. Die keuze bepaalt sterk wat een product kan, en wat het van je organisatie verwacht.
IGA-software beheert wie toegang heeft tot welke systemen, zorgt dat die toegang aansluit op beleid en regelgeving, en maakt aantoonbaar dat de juiste mensen de juiste rechten hebben. Denk aan het toewijzen en intrekken van rechten, het periodiek herzien van toegang en het vastleggen van wie wanneer wat kon doen.
Functiescheiding is daarbinnen geen losstaande functie, maar een governancevereiste. Het antwoord op de vraag: zijn de rechten die we hebben toegekend ook veilig verdeeld? Een organisatie die alleen bijhoudt wie toegang heeft, maar niet controleert of die combinatie van rechten gevaarlijk is, heeft een blinde vlek in haar governance.
IGA-producten vullen SoD op fundamenteel verschillende manieren in. Die keuze heeft grote gevolgen voor hoe je functiescheiding beheert, wie daarvoor verantwoordelijk is, en hoe aantoonbaar het resultaat is.
Separation of Duties is geen IT-uitvinding. Het principe komt uit de accountancy, waar al eeuwen geldt dat dezelfde persoon niet zowel geld mag ontvangen, registreren als controleren. In de twintigste eeuw werd dat geformaliseerd in het COSO-raamwerk. Na de boekhoudschandalen rond Enron en WorldCom dwong de Sarbanes-Oxley Act van 2002 beursgenoteerde bedrijven om SoD aantoonbaar in te richten, ook in IT. Sindsdien is het onderdeel van ISO 27001, NIST en talloze sectorspecifieke normen.
De kerngedachte is altijd hetzelfde: geen enkele individuele actor (mens of systeem) mag een kritiek proces volledig alleen kunnen uitvoeren. Voor de uitgebreide context, en voor de discussie over preventieve versus detectieve controles, verwijzen we graag terug naar het artikel: Wat betekent Separation of Duties en waarom mislukt het?
Veel IGA-producten combineren meerdere benaderingen, maar bijna elk product heeft een duidelijk zwaartepunt. Die keuze is zelden toevallig: ze weerspiegelt een visie op wie verantwoordelijk is voor governance en hoe strikt dat wordt afgedwongen.
Dit is de klassieke benadering en de meest zichtbare. Een compliance-team definieert vooraf welke rollen of bevoegdheden onverenigbaar zijn met elkaar. Een gebruiker die rol A bezit, kan rol B niet eenvoudigweg toegewezen krijgen. Het systeem bewaakt dit centraal en behandelt een aanvraag die een conflict zou opleveren ofwel als blokkade ofwel als policy violation die om remediation vraagt.
Belangrijk detail: in matrix-producten is het beleid vaak configureerbaar. Een organisatie kan een SoD-policy preventief instellen (blokkeren bij aanvraag) of detectief (toestaan, maar zichtbaar als overtreding op een dashboard, met remediation als vervolgstap). In de praktijk zien we beide modi door elkaar gebruikt worden, soms zelfs binnen één installatie.
Wat de matrix oplevert: een centraal overzicht van het beleid, dat in audits goed valt uit te leggen. Wat het kost: aanzienlijke modelleerinspanning, een compliance-functie die de matrix actueel houdt, en een hoge mate van centralisatie. In organisaties met sterk decentraal eigenaarschap voelt deze aanpak vaak vervreemdend, omdat de mensen die de processen kennen niet altijd degenen zijn die de matrix beheren.
Een tweede groep producten kiest een wezenlijk andere route: niet preventief blokkeren, maar periodiek hercertificeren. Toegang mag eerst toegekend worden, maar wordt vervolgens met vaste regelmaat door een manager of eigenaar opnieuw onder de loep genomen. Conflicten worden detectief opgespoord, niet preventief voorkomen.
Wat dit oplevert: minder rigide modellering vooraf, ruimte voor legitieme uitzonderingen, en goede zichtbaarheid achteraf. Wat het kost: reactiviteit. Tussen het ontstaan van een conflict en de eerstvolgende certificering kan een gebruiker maanden lang in een toxische combinatie van rechten zitten. Voor sterk gereguleerde omgevingen is dat zelden voldoende.
De derde variant verlegt het zwaartepunt naar het moment van de aanvraag. Een aanvrager kan niet zijn eigen aanvraag goedkeuren, en de goedkeurder kan niet zelf de toegang activeren. SoD wordt zo niet gemodelleerd als rol-conflict, maar afgedwongen in de keten van handelingen. Dit is de variant die het dichtst tegen het oorspronkelijke 4-ogen principe uit de accountancy aanleunt.
De meeste IGA-producten ondersteunen deze laag out-of-the-box, vaak als aanvulling op variant 1 of 2. In sommige producten is workflow-segregatie zelfs de primaire SoD-laag, en wordt er geen aparte conflictmatrix gevoerd.
Wat dit oplevert: een operationele waarborg op precies het moment dat het ertoe doet, en een implementatie die ook werkt zonder zware compliance-functie. Wat het kost: zonder aanvullende mechanismen kan een gebruiker nog steeds twee onverenigbare rechten in zijn portefeuille verzamelen.
JIT is geen alternatief voor de drie varianten hierboven, maar een zinvolle aanvullende laag. In plaats van permanente rechten worden bevoegdheden pas actief op het moment dat iemand ze nodig heeft, voor precies de duur van de taak. Daarna vervallen ze automatisch.
Dat verkleint het aanvalsoppervlak: conflicterende bevoegdheden worden nooit permanent gecombineerd. Maar het lost het SoD-probleem niet volledig op. Een goedkeurder in een JIT-workflow ziet niet automatisch welke andere rechten een gebruiker op dat moment heeft. Zonder aanvullende controle kan iemand via afzonderlijke verzoeken toch een gevaarlijke rechtencombinatie opbouwen, tijdelijk maar reëel.
JIT verrijkt de audittrail (er wordt een reden en vervaltijd vastgelegd) en past goed bij privileged access, noodsituaties en projectgebonden toegang. Als aanvulling op een van de drie varianten, niet als vervanging.
KeyHub volgt het principe van centrale authenticatie en decentrale autorisatie. Wie toegang verleent tot wat, is een verantwoordelijkheid van de mensen die het werk kennen, niet van een centraal compliance-team. Die keuze klinkt operationeel, maar werkt door tot in de manier waarop SoD wordt ingevuld.
Waar een matrix-product zegt "deze twee rollen mogen nooit in één persoon samenkomen, ongeacht waar in de organisatie", zegt KeyHub: het is aan de eigenaren van groepen om te bepalen waar functiescheiding nodig is. Als zij die scheiding eenmaal hebben ingesteld, dan handhaaft KeyHub die strikt.
Dat principe wordt concreet via vijf bouwstenen.
Toegang in KeyHub loopt via groepen. Elke groep geeft toegang tot een specifieke combinatie van accounts, systemen of wachtwoorden, en heeft een groepseigenaar die het lidmaatschap beheert. Groepseigenaren staan dicht bij het werk en kennen de risico's van hun eigen domein.
Tussen twee groepen kan een wederzijdse uitsluiting worden ingesteld. Een gebruiker die lid is van groep A kan dan eenvoudigweg geen lid worden van groep B, en omgekeerd. Er ontstaat geen conflict dat later opgelost moet worden: de handhaving is strikt. Een aanvraag die het conflict zou veroorzaken wordt geweigerd, of er nu via de UI gewerkt wordt of via de API, en ongeacht of de toewijzing handmatig is of via een accessprofile loopt. Bij het instellen van een uitsluiting wordt expliciet aangegeven uit welke groep conflicterende leden moeten worden verwijderd. De functie is recent toegevoegd en draait inmiddels in productie bij een grote publieke-sector klant.
KeyHub kent negen distincte goedkeuringsmomenten waar het 4-ogen principe wordt afgedwongen, van groepstoelating en kluis-toegang tot activatieverzoeken, lidmaatschapswijzigingen en audit-reviews. Voor elk van die momenten kan een aparte autoriserende groep worden ingesteld. Dat maakt drie partijen mogelijk in één keten: aanvrager, goedkeurder en, als er een autoriserende groep is geconfigureerd, een aanvullende controle daarboven. Per actie binnen één en dezelfde groep kan de autoriserende groep verschillen. Een groepsmanager mag bijvoorbeeld de dagelijkse lidmaatschapswijzigingen goedkeuren, terwijl de audit van diezelfde groep door een ander team wordt afgetekend.
Voor groepen waar permanente toegang ongewenst is (zoals privileged access), kan KeyHub het lidmaatschap tijdsgebonden activeren. De gebruiker activeert de toegang voor de duur die hij nodig heeft, met een reden en een vervaltijd. Na afloop wordt de toegang automatisch ingetrokken. Voor low en medium privileged toegang is dit doorgaans niet wenselijk: niemand zit te wachten op een activatie-rondje om bij een gedeelde teammap te komen. JIT is in KeyHub dus geen verplicht patroon, maar een gericht instrument voor groepen waar het risico het rechtvaardigt.
Groepen kunnen worden geclassificeerd, en per classificatie kan een organisatie centraal minimumeisen opleggen: maximaal audit-interval, verplichte audit-maand, audittrail-vastlegging, en welke goedkeuringen op welk moment verplicht zijn. Op de roadmap staat dat ook SoD-eisen via classificaties opgelegd kunnen worden, op dezelfde manier waarop dat nu al kan met de autoriserende flows. Daarmee kan een organisatie centraal afdwingen dat bepaalde groepstypes uitsluitingen krijgen, zonder de decentrale invulling daarvan op te geven.
KeyHub heeft geen centrale rol-conflictmatrix. Dat is een bewuste keuze: de mensen die de processen kennen, zijn beter in staat om te bepalen waar functiescheiding nodig is dan een centraal compliance-team. Uitsluitingen worden decentraal ingesteld, en KeyHub handhaaft ze vervolgens strikt. Voor organisaties die SOX-audits krijgen op een specifiek matrix-format is dat iets om rekening mee te houden bij de inrichting.
Uitzonderingen op uitsluitingen zijn geen configuratieoptie, maar een expliciet ontwerp. Wie een uitzondering wil inrichten, doet dat via een aparte groep met JIT-activatie en een autoriserende groep erboven. Zichtbaar, traceerbaar en goedgekeurd. Niet stilzwijgend toegestaan.
Separation of Duties heeft veel gezichten in de IGA-markt. Een matrix-aanpak werkt voor organisaties die centraal compliance hoog in het vaandel hebben en bereid zijn om die modelleringsdiscipline te dragen. Een certificeringsaanpak werkt voor wie liever flexibel start en achteraf opruimt. Een workflow-aanpak werkt voor wie het 4-ogen principe als hoofdwaarborg ziet. Een JIT-aanpak werkt voor wie de permanente attack surface wil verkleinen waar het risico hoog is.
KeyHub combineert workflow-seperation en gerichte JIT met een expliciete SoD-laag in de vorm van groepsuitsluitingen, en plaatst dat alles binnen een classificatie-gebaseerde governance-laag. Dat past bij de filosofie waarop het hele product is gebouwd: centrale authenticatie, decentrale autorisatie. De mensen die de processen kennen, kunnen functiescheiding daar afdwingen waar het nodig is. En als dat eenmaal is ingesteld, dan is het strikt.
Geen matrix, geen vinkje. Wel werkende mechanismen.