In veel Dynamics 365-omgevingen die ik onder de motorkap bekijk, kom ik dezelfde situatie tegen: een fors aantal gebruikers met de System Administrator-rol, terwijl die rol bedoeld is voor een handvol mensen die de omgeving daadwerkelijk technisch beheren. Het is een van de meest stille, maar reële risico’s in een Dynamics 365-omgeving.

Security roles zijn, net als connection references en service principals in Power Platform, het type onderwerp dat technisch en intern aanvoelt — tot het moment dat het misgaat. Een gebruiker die per ongeluk records van een afdeling bewerkt waar hij niet bij zou mogen, een rapport dat gevoelige data toont aan iemand die het niet zou moeten zien, of een audit die blootlegt dat niemand meer weet wie waarom welke rechten heeft.

Waarom de “System Administrator voor iedereen”-aanpak ontstaat

De reden is bijna altijd pragmatisch, niet kwaadwillend. Tijdens een implementatie is het makkelijker om iedereen ruime rechten te geven, zodat niemand wordt geblokkeerd terwijl de inrichting nog wordt afgerond. Na livegang wordt het opschonen van die rechten vaak uitgesteld — er is geen acute aanleiding, het systeem werkt, en niemand heeft tijd om uit te zoeken wie precies welke rol nodig heeft.

Het probleem stapelt op: Hoe langer een te ruime rechtenstructuur bestaat, hoe moeilijker het wordt om die later terug te brengen — gebruikers zijn gewend geraakt aan toegang die ze formeel niet nodig hebben, en het intrekken daarvan voelt als het wegnemen van iets, in plaats van het herstellen van een tijdelijke situatie.

Wat security roles, business units en teams precies doen

Dynamics 365 kent drie samenhangende mechanismen om toegang te beheren. Security roles bepalen welke acties een gebruiker mag uitvoeren op welk type record — lezen, schrijven, verwijderen, toewijzen — en op welk niveau: alleen eigen records, records binnen de business unit, of alle records in de organisatie.

Business units: de scope waarbinnen een rol werkt

Business units verdelen de organisatie in afdelingen of eenheden, en bepalen daarmee de scope waarbinnen een security role werkt. Een verkoper met een role die toegang geeft op business unit-niveau, ziet alleen records binnen zijn eigen business unit — niet die van een andere afdeling, ook niet als hij toevallig wel toegang tot het systeem heeft.

Teams: een derde, flexibele laag

Teams bieden een derde laag: een manier om rechten te groeperen rond een project of tijdelijke samenwerking, zonder dat dit de standaard business unit-structuur van een gebruiker beïnvloedt. Teams zijn met name nuttig wanneer mensen uit verschillende business units tijdelijk moeten samenwerken op een specifieke set records.

De praktische risico’s van te ruime rechten

Het meest directe risico is dataverlies of -corruptie: een gebruiker met meer rechten dan nodig kan, per ongeluk of uit onwetendheid, records aanpassen of verwijderen die buiten zijn verantwoordelijkheid liggen.

Compliance-risico: Voor organisaties die onder AVG, ISO 27001 of sectorspecifieke regelgeving vallen, is een ondoorzichtige rechtenstructuur een aantoonbaar pijnpunt bij elke audit. “We weten niet meer precies wie waarom toegang heeft” is geen antwoord waar een auditor tevreden mee is.

Een derde, vaak onderschat risico is dat te ruime rechten een vals beeld geven van wie waarvoor verantwoordelijk is. Als iedereen alles kan, is bij een fout niet meer te herleiden wie de wijziging heeft gemaakt op basis van zijn rol — alleen wie er technisch toe in staat was, wat in een omgeving zonder rolscheiding bijna iedereen is.

“Als iedereen System Administrator is, is niemand verantwoordelijk. Rolscheiding is niet alleen een beveiligingsmaatregel — het is ook de basis van herleidbaarheid.”

Hoe je een security-model wel goed inricht

Het uitgangspunt is least privilege: elke gebruiker krijgt precies de rechten die nodig zijn voor zijn functie, niet meer. In de praktijk betekent dit het opstellen van een rollenmatrix: welke functies bestaan er in de organisatie, welke acties horen daar logisch bij, en welke scope — eigen, business unit, organisatie-breed — is voor elke functie passend.

Het principe: System Administrator-rechten worden beperkt tot een klein aantal mensen die de omgeving daadwerkelijk technisch beheren — doorgaans niet meer dan een handvol, ook in grotere organisaties. Voor functioneel beheer bestaat een tussenliggende rol die specifiek voor dat doel is samengesteld, niet de standaard System Administrator-rol als gemakkelijke oplossing.

Een bestaande, te ruime structuur herstellen

Voor organisaties die nu al in de situatie zitten waarin te veel gebruikers te veel rechten hebben, is een geleidelijke aanpak verstandiger dan een abrupte ingreep. Eerst een inventarisatie van wie welke rol heeft en waarom. Daarna een nieuwe rollenmatrix opstellen op basis van daadwerkelijke functievereisten. Vervolgens een periode waarin de nieuwe rollen naast de oude bestaan, zodat eventuele gaten in de matrix zichtbaar worden voordat de oude, te ruime rollen worden ingetrokken.

Deze aanpak kost meer tijd dan in een keer alle rechten aanpassen, maar voorkomt dat gebruikers plotseling worden geblokkeerd in werk dat ze daadwerkelijk nodig hebben — wat het draagvlak voor een opschoning in de praktijk vaak meer schade toebrengt dan de oorspronkelijke te ruime rechten.

Een herziene structuur heeft doorgaans deze kenmerken:

  • Een rollenmatrix bestaat en wordt onderhouden — Functies en bijbehorende rechten staan vastgelegd, niet alleen in iemands hoofd.
  • System Administrator is uitzondering, geen standaard — Alleen wie de omgeving technisch beheert, heeft deze rol.
  • Scope sluit aan op de functie — Eigen records, business unit of organisatie-breed, bewust gekozen per rol.
  • Teams worden gebruikt voor tijdelijke samenwerking — Niet als permanente omweg rond de business unit-structuur.
  • Wijzigingen zijn herleidbaar — Bij een fout is te achterhalen wie de wijziging op basis van welke rol heeft gemaakt.

Wanneer schakel je hier hulp bij in?

Het herinrichten van een security-model in een levende productieomgeving vraagt precisie: een verkeerde wijziging kan gebruikers blokkeren in werk dat ze die dag nog moeten doen. Dit soort wijzigingen voer je niet door zonder een duidelijk beeld van de impact vooraf.

Ik help organisaties bij het opstellen van een rollenmatrix, het herstructureren van bestaande, te ruime rechten, en het inrichten van een model dat meegroeit met de organisatie in plaats van na elke uitbreiding opnieuw te moeten worden uitgevonden.

Weet jij wie er System Administrator is in jouw omgeving — en waarom?

Ik voer graag een vrijblijvende security-quickscan uit en geef je direct concreet, bruikbaar advies over je rechtenstructuur.

Vraag een vrijblijvende quickscan aan →