Segregation of Duties: SoD-basis voor de mid-market

Segregation of duties access is een van die controls waar elke auditor naar vraagt en die bijna geen enkel mid-market IT-team echt geautomatiseerd heeft. Het principe ken je: één persoon zou nooit én een leverancier kunnen aanmaken én die leverancier kunnen uitbetalen, of én een inkooporder kunnen goedkeuren én de betaling kunnen vrijgeven. Het idee is oud en breed geaccepteerd. Het probleem is dat de meeste organisaties tussen de 200 en 2.000 medewerkers dit nog steeds met een spreadsheet controleren, één keer per jaar, vlak voor de audit.

Die kloof bestaat niet omdat segregation of duties (SoD, functiescheiding) moeilijk te begrijpen is. Het komt doordat de tooling om het af te dwingen historisch gebonden was aan zware identity-governance-suites, gebouwd voor banken en verzekeraars, met SoD-matrices van duizenden regels over SAP, Oracle en tien andere systemen. Als jouw realiteit Microsoft 365, Entra ID en een handvol bedrijfsapplicaties is, is die machinerie overdreven. Wat je nodig hebt is een korte lijst van toxic combinations, automatisch gecontroleerd tegen je Entra ID- en Active Directory-groepen.

Dit artikel behandelt wat SoD access betekent, hoe je de toxic combinations identificeert die ertoe doen in een Microsoft-centrische omgeving, en hoe je ze afdwingt zonder een enterprise IGA-platform aan te schaffen.

Waar segregation of duties tegen beschermt

Segregation of duties is een control tegen een single point of failure in je processen, niet een control tegen het wantrouwen van één individu. Het punt is dat een fout, een oversight, of een bewuste actie niet onopgemerkt kan blijven omdat twee verschillende rollen dezelfde transactie moeten aanraken.

Klassieke voorbeelden:

• Wie een nieuwe leverancier aanmaakt in het financiële systeem, zou niet ook betalingen aan die leverancier moeten kunnen goedkeuren.
• Wie toegang aanvraagt, zou niet degene moeten zijn die de eigen aanvraag goedkeurt.
• Wie code naar productie deployt, zou niet dezelfde persoon moeten zijn die de wijziging heeft goedgekeurd.
• Een HR-beheerder die zowel medewerkersdossiers kan aanmaken als salarisruns kan verwerken, kan een spookmedewerker aanmaken en uitbetalen.

Geen van deze voorbeelden vereist kwade opzet om relevant te zijn. Auditors hechten waarde aan SoD omdat het de schade beperkt van zowel fraude als menselijke fouten, en omdat ISO 27001, SOC 2 en NIS2-achtige kaders verwachten dat je het als control aantoont, niet alleen als beleid claimt.

Waarom dit een access-managementprobleem wordt

SoD klinkt als een bedrijfsprocesvraag, maar in de praktijk wordt het afgedwongen via toegang: wie lid is van welke groep, wie welke rol heeft, wie wat mag goedkeuren. Zodra iemand na jaren interne doorgroei groepslidmaatschappen opstapelt (een joiner/mover/leaver-probleem in vermomming), sluipt een toxic combination er stilletjes in. Niemand heeft het bewust toegekend. Het is gewoon opgebouwd.

Daarom zijn SoD en access governance in wezen dezelfde discipline, vanuit een andere hoek bekeken. Als je al schone groepsdefinities hebt, een access review-proces, en een lifecycle die toegang intrekt zodra iemand van rol verandert, ben je al een heel eind op weg naar een werkende SoD-control.

De toxic-combination-aanpak voor mid-market teams

Enterprise IGA-suites modelleren SoD vaak als een uitputtende matrix: elke rol tegen elke andere rol, gescoord op risico, beoordeeld door een compliance-team. Voor een bedrijf dat vooral op Microsoft 365 en een paar line-of-business apps draait, is dat niveau van formaliteit zelden proportioneel. Een eenvoudigere aanpak werkt beter en wordt ook daadwerkelijk onderhouden.

Stap 1: Maak een lijst van je echte toxic combinations, geen generiek template

Begin met een korte lijst, tien tot twintig rolparen die in jouw organisatie écht nooit zouden mogen overlappen. Haal deze uit echte proceskennis, niet uit een gedownload sjabloon. Praat met finance, HR en IT-operations en vraag: "als één persoon beide dingen zou kunnen doen, wat kan er dan misgaan?"

Typische mid-market paren:

1. Leverancier aanmaken + betaling goedkeuren
2. Inkooporder goedkeuren + betaling vrijgeven
3. Toegang aanvragen + eigen aanvraag goedkeuren
4. Entra ID-adminrollen toekennen + diezelfde rollen auditen
5. Salaris verwerken + medewerkersgegevens wijzigen
6. AD-groepslidmaatschap beheren + access reviews voor die groep goedkeuren

Stap 2: Koppel elke combinatie aan echte groepen en controleer overlap automatisch

Elk item op die lijst moet vertaald worden naar iets controleerbaars: een Entra ID-groep, een on-prem AD-securitygroep, een applicatierol. Deze stap wordt vaak overgeslagen, en dat is precies waarom SoD-beleid theoretisch blijft. Zodra de combinaties gekoppeld zijn aan groepen, is de check zelf simpele verzamelingenlogica: bevat de doorsnede van groep A en groep B gebruikers? Die query kan continu draaien in plaats van één keer per jaar in een spreadsheet. De waarde zit niet in geavanceerdheid, maar in frequentie: een toxic combination die elf maanden bestaat voordat de jaarlijkse audit hem opvangt, is nog steeds elf maanden blootstelling.

Waar SoD misgaat in Microsoft-omgevingen

Een paar patronen komen steeds terug in Microsoft-omgevingen en verdienen specifieke aandacht.

Geneste groepen en opgestapelde rollen

Een gebruiker is misschien geen direct lid van twee conflicterende groepen, maar geneste groepslidmaatschap kan hem er indirect wel in plaatsen, dus een check die alleen naar direct lidmaatschap kijkt mist dit. Een verwant patroon: iemand stroomt door van crediteurenadministratie naar een financemanagerrol en houdt het oude AP-groepslidmaatschap, omdat niemand eraan dacht dit te verwijderen. Zes maanden later heeft die persoon beide kanten van een toxic combination, zonder dat iemand dat bewust zo besloten heeft. Dit is precies het joiner/mover/leaver-gat: toegang die de geschiedenis van iemand volgt in plaats van de huidige attributen.

Tijdelijke toegang en niet-gescheiden adminrollen

Iemand valt in voor een collega met verlof en wordt toegevoegd aan een goedkeuringsgroep "voor twee weken." Die twee weken worden twee jaar, omdat tijdelijke verhoogde toegang meestal buiten de normale reviewcyclus wordt toegekend en zelden een vervaldatum krijgt. Een vergelijkbaar risico zit in Entra ID-adminrollen: een veelvoorkomend toxic paar is het bezitten van zowel een geprivilegieerde rol (Global Administrator, User Administrator) als de mogelijkheid om toegang tot diezelfde rol goed te keuren of te beoordelen. Wie privileges kan toekennen, zou niet de enige reviewer ervan moeten zijn.

SoD afdwingen zonder enterprise IGA-suite

Voor de meeste mid-market organisaties dekken drie praktische mechanismen het grootste deel van SoD-handhaving:

Mechanisme	Wat het opvangt	Waar het draait
Attribuutgebaseerde groepsregels (ABAC)	Voorkomt dat iemand in twee conflicterende groepen terechtkomt, omdat lidmaatschap afdeling, functietitel en locatie volgt	Entra ID dynamic groups, on-prem AD
Periodieke access reviews op toxic pairs	Vangt opgestapelde conflicten op uit historische toekenningen en geneste lidmaatschappen	Reviews gericht op de specifieke groepsparen op je lijst
Self-service goedkeuringsrouting	Zorgt dat de goedkeurder nooit de aanvrager is, en gevoelige aanvragen buiten die groep worden gerouteerd	Self-service access-portaal, regelgebaseerde goedkeuring

De rode draad is dat SoD-handhaving het beste werkt wanneer het is ingebouwd in hoe toegang wordt toegekend en beoordeeld, in plaats van er als losse audit-exercitie bovenop geplakt te worden. Als je toegangsmodel al attribuutgebaseerd is, is een klein aantal regels van "deze groepen mogen nooit overlappen" een bescheiden uitbreiding, geen nieuw platform.

Dit is precies waar ServiceChanger past voor Microsoft-only omgevingen. De ABAC-engine kent Entra ID- en on-prem AD-groepslidmaatschap automatisch toe op basis van attributen zoals afdeling en functietitel, wat beperkt hoe toxic combinations kunnen ontstaan. De access review-functionaliteit laat je een terugkerende review precies richten op de groepsparen die voor SoD relevant zijn, in plaats van alles opnieuw te reviewen. En omdat toegang attributen volgt in plaats van handmatige toekenningen, kan het self-service portaal goedkeuringen op basis van regels routeren naar iemand buiten de aanvragende groep, waardoor aanvraag en goedkeuring by design gescheiden blijven.

Een lichtgewicht SoD-programma bouwen: checklist

• Leg je echte toxic combinations vast (tien tot twintig is genoeg om mee te beginnen).
• Koppel elke combinatie aan specifieke Entra ID-groepen, AD-groepen of app-rollen.
• Los effectief (genest) lidmaatschap op bij het controleren van overlap, niet alleen direct lidmaatschap.
• Voer de overlapcheck volgens een schema uit, niet één keer per jaar.
• Route toegangsaanvragen zo dat de goedkeurder nooit de aanvrager is, en voor gevoelige groepen buiten die groep zit.
• Zet vervaldatums op tijdelijke of vervangende toegang zodat die niet stilletjes permanent wordt.
• Beoordeel de lijst met toxic combinations zelf jaarlijks opnieuw. Rollen veranderen, je lijst zou dat ook moeten doen.

FAQ

Wat is segregation of duties (SoD) in access management? SoD is een control die ervoor zorgt dat niemand twee rollen of rechten combineert waarmee hij of zij een gevoelig proces zonder toezicht volledig kan afronden, zoals een leverancier aanmaken én de betaling aan die leverancier goedkeuren.

Hebben mid-market bedrijven een volledige IGA-suite nodig voor SoD? Nee. De meeste organisaties die vooral op Microsoft 365 en Entra ID draaien, kunnen SoD afdwingen met een korte lijst van toxic combinations die automatisch tegen groeps- en rollidmaatschap wordt gecontroleerd, zonder de matrixmachinerie die voor grote ERP-landschappen is gebouwd.

Hoe ontstaan toxic combinations als niemand ze bewust toekent? Ze stapelen zich meestal op door interne rolwijzigingen waarbij oude lidmaatschappen nooit worden verwijderd, door geneste lidmaatschap die niet zichtbaar is in een directe check, of door tijdelijke toegang die nooit wordt ingetrokken.

Kunnen Entra ID dynamic groups helpen SoD-overtredingen te voorkomen? Ja. Wanneer lidmaatschap wordt bepaald door attributen zoals afdeling en functietitel in plaats van handmatige toewijzing, is het moeilijker om onbedoeld conflicterende lidmaatschappen op te bouwen, omdat lidmaatschap de huidige rol weerspiegelt, niet de geschiedenis.

Segregation of duties hoeft geen jaarlijkse audit-scramble te zijn. Begin met een korte lijst van de combinaties die er echt toe doen, koppel ze aan echte Entra ID- en AD-groepen, en controleer de overlap automatisch. Wil je zien hoe de ABAC-engine en access reviews van ServiceChanger dit ondersteunen voor Microsoft-only omgevingen, bekijk dan onze pagina over access governance en compliance, of lees meer over access control en governance op de blog.