Birthright access goed inrichten in Entra ID en AD

Birthright access is de toegang die elke medewerker automatisch krijgt op het moment van indiensttreding, nog voordat iemand iets heeft aangevraagd. Mail, het bedrijfsbrede Teams-kanaal, het intranet, basale bestandslocaties, de VPN-client. Het is de basis die elke nieuwe medewerker nodig heeft om op dag één te kunnen functioneren, en de reikwijdte ervan goed bepalen is belangrijker dan de meeste IT-teams beseffen. Te smal, en dag één verandert in een stroom supporttickets. Te breed, en je hebt ongemerkt staande toegang opgebouwd die niemand zich meer herinnert te hebben toegekend.

Het idee zelf is simpel. De uitvoering meestal niet, want "wat moet iedereen automatisch krijgen" is een lastigere vraag dan het lijkt, en het antwoord verschuift in de loop van de tijd doordat afdelingen uitzonderingen toevoegen, nieuwe rollen ontstaan, en niemand teruggaat om de oorspronkelijke lijst op te schonen. Dit artikel bekijkt wat wél in een birthright access-pakket hoort, wat niet, en hoe je de definitie accuraat houdt terwijl mensen door je organisatie bewegen, in plaats van het te laten verworden tot iets dat niemand meer vertrouwt.

Wat birthright access precies inhoudt

Birthright access is de kleine, vaste set aan middelen die elke medewerker, of elke medewerker binnen een bepaalde categorie, krijgt zonder daar een aanvraag voor in te dienen. Het wordt toegekend op basis van het feit dat iemand medewerker is, niet op basis van diens specifieke functie. Een financieel controller en een magazijncoördinator krijgen allebei mail en een Teams-licentie op dag één, omdat die toegang niet aan hun rol vastzit, maar aan het feit dat ze op de loonlijst staan.

Dit verschilt van rolgebaseerde toegang, die gekoppeld is aan de functie (een controller heeft het financiële systeem nodig, de coördinator niet), en van aangevraagde toegang, waar iemand expliciet om vraagt omdat hij het nodig heeft voor een specifieke taak. Birthright access zit onder beide. Het is de vloer waarop iedereen staat, niet de toegang die iemand moest verantwoorden.

Waarom het onderscheid ertoe doet

Birthright access verwarren met rolgebaseerde toegang is de meest voorkomende manier waarop birthright-pakketten opgeblazen raken. Als "iedereen bij Sales krijgt het CRM" sluipenderwijs onderdeel wordt van de birthright-definitie in plaats van een rolgebaseerde regel die is afgebakend tot Sales, dan erft elke nieuwe medewerker in elke afdeling dit automatisch, of erger nog, iemand kopieert de verkeerde template en een magazijncoördinator krijgt CRM-toegang die niemand ooit bedoeld heeft te geven.

Wat wel in een birthright access-pakket hoort

Een goed birthright-pakket is kort en verdedigbaar. Elk item erop moet iets zijn dat je aan letterlijk elke medewerker zou geven, ongeacht afdeling, senioriteit of locatie.

Typische inhoud:

• Mail en agenda (Exchange Online-mailbox)
• Basis-samenwerkingstools (Teams, SharePoint-intranet, bedrijfsbrede kanalen)
• Identiteitsbasis (Entra ID-account, MFA-registratie, self-service wachtwoordherstel)
• Netwerktoegang (VPN-client, gastwifi-inloggegevens waar relevant)
• Algemene licentielaag (de basis Microsoft 365 SKU, geen add-ons)
• HR self-service (loonstroken, verlofaanvragen, als dit op dezelfde identiteit draait)

Dat is meestal het geheel. Merk je dat je afdelingsspecifieke tools, adminrechten, of iets met blootstelling aan financiële, HR- of klantgegevens aan deze lijst toevoegt, dan is het geen birthright access meer, maar een rolgebaseerde regel die apart gedefinieerd en afgebakend moet worden.

Wat niet in birthright access hoort

Hier gaat het in de meeste omgevingen sluipenderwijs mis. Toegang belandt in de "iedereen krijgt dit"-bak omdat het op dat moment gewoon makkelijk was, niet omdat het daar hoort.

Veelvoorkomende overreach-patronen

• Admin- of verhoogde rechten, breed toegekend omdat een paar mensen ze echt nodig hebben en het makkelijker leek om ze aan een hele groep te geven dan individueel te beheren.
• Financiële systemen, toegevoegd aan een afdelingsbrede birthright-regel omdat het merendeel van de afdeling met facturen werkt, ook al zou niet elke rol erin dit moeten hebben.
• Klant- of HR-gegevens, overgeërfd van een template die voor één rol is gebouwd en hergebruikt voor een heel team zonder de scope opnieuw te checken.
• Verouderde applicaties, achtergebleven in een birthright-regel uit een eerdere reorganisatie omdat niemand degene wilde zijn die iemands toegang brak door het te verwijderen.

Geen van deze zaken is birthright access. Het is rol- of taakgebaseerde toegang die in de automatisch-op-dag-één-bak is beland, meestal omdat dat sneller was dan een fatsoenlijke regel definiëren. De oplossing is niet om automatisering terug te draaien, maar om die correct af te bakenen: houd birthright access beperkt tot de echt universele basis, en stuur al het andere aan op basis van de attributen die daadwerkelijk bepalen of iemand het nodig heeft, afdeling, functietitel, locatie, dienstverband.

Waarom birthright access uit de pas gaat lopen

Birthright access gaat zelden mis op het moment dat het gedefinieerd wordt. Het gaat maanden of jaren later mis, terwijl de organisatie verandert rondom een definitie die stil bleef staan.

Een paar patronen komen steeds terug:

1. Reorganisaties vervagen de grens. Een team dat ooit een eigen afdeling was, wordt samengevoegd met een grotere, en de oude birthright-regel wordt niet ingetrokken, maar bovenop de regel van de nieuwe afdeling gestapeld.
2. Movers houden oude basistoegang vast. Iemand wisselt intern van rol, en de oorspronkelijke birthright access, plus alles wat diegene onderweg heeft opgepikt, gaat mee, omdat geen enkel proces bij een verplaatsing actief iets intrekt, alleen toevoegt.
3. "Tijdelijke" uitzonderingen worden permanent. Een eenmalige toevoeging aan de birthright-regel voor een project of migratie wordt na afloop van het project nooit teruggedraaid.
4. Nieuwe medewerkers krijgen wat de vorige persoon had. Zonder een heldere, attribuutgestuurde definitie betekent onboarding vaak het kopiëren van de toegang van een collega in plaats van het toepassen van een vastgelegde basis, waarmee je precies de drift importeert die die collega al had opgebouwd.

Het patroon achter alle vier is hetzelfde: birthright access wordt behandeld als een eenmalige inrichtingsbeslissing in plaats van een regel die actief onderhouden moet worden terwijl de organisatie en haar mensen veranderen.

Birthright access accuraat houden terwijl mensen bewegen

De oplossing is stoppen met birthright access als statische lijst te behandelen, en het gaan behandelen als een regel die doorlopend tegen actuele attributen wordt geëvalueerd, in plaats van eenmalig toegekend en daarna met rust gelaten.

Definieer op attribuut, niet op uitzondering

In plaats van een handmatige groep te onderhouden waar iedereen met de hand aan wordt toegevoegd, definieer je birthright access als een regel: "elk account met een actieve dienstverbandstatus krijgt deze groepslidmaatschappen." Als de regel attribuutgestuurd is, hoeft niemand te onthouden om iemand toe te voegen of te verwijderen. Wie in dienst komt, kwalificeert automatisch. Wie vertrekt, kwalificeert automatisch niet meer, omdat het onderliggende attribuut (dienstverbandstatus) veranderde, niet omdat iemand eraan dacht een groep bij te werken.

Herbereken bij elke mover-gebeurtenis

Wat de meeste omgevingen missen, is dat een rolwissel toegang opnieuw zou moeten evalueren, niet er alleen aan toevoegen. Is birthright access écht universeel, dan verliezen movers er zelden iets van. Maar rolgebaseerde toegang die verkeerd als birthright werd bestempeld, komt precies op dit moment naar boven: als iemand van afdeling wisselt en de "birthright"-regel blijkt alleen te gelden zolang je op een bepaalde manier meetelt, is dat meestal het signaal dat het eigenlijk rolgebaseerde toegang was die zich voordeed als birthright.

Toets de definitie zelf, periodiek

Zelfs een goed afgebakend birthright-pakket heeft een periodieke sanity check nodig, niet van wie het heeft (dat zou iedereen moeten zijn), maar van wat erin zit. Een access review die zich specifiek richt op de inhoud van de birthright-regel, één of twee keer per jaar, vangt scope creep op voordat het de nieuwe norm wordt.

Type toegang	Basis voor toekenning	Verandert wanneer
Birthright	Dienstverbandstatus	Persoon treedt in of uit dienst
Rolgebaseerd	Afdeling, functietitel, locatie	Persoon wisselt van rol, afdeling of locatie
Aangevraagd	Specifieke taak- of projectbehoefte	Aanvraag wordt goedgekeurd of behoefte vervalt

Dit is precies het soort regel waar attribute-based access control (ABAC) voor bedoeld is. In plaats van een statische groep met handmatig beheerd lidmaatschap, evalueren de birthright-regel en elke rolgebaseerde regel daarboven doorlopend tegen Entra ID- en on-prem AD-attributen, zodat de scope correct blijft door reorganisaties, rolwissels en vertrek heen, zonder dat iemand het handmatig hoeft op te merken en te herstellen. Als je birthright- en rolgebaseerde toegang in de loop der tijd uit elkaar zijn gegroeid, is group mining, het bekijken van bestaande lidmaatschapspatronen om te suggereren wat de regels eigenlijk zouden moeten zeggen, een praktische manier om een accurate basis te herbouwen zonder bij nul te beginnen. Voor het bredere plaatje van hoe attribuutgestuurde regels toegang beheren over de hele levenscyclus van een medewerker, zie ons overzicht Identity & Access Management.

FAQ

Wat is het verschil tussen birthright access en least privilege? Het zijn geen tegenpolen. Birthright access is de kleine, universele basis die elke medewerker nodig heeft; least privilege is het principe dat niemand meer zou moeten hebben dan die basis plus wat zijn specifieke rol vereist. Een goed afgebakend birthright-pakket is eigenlijk een least-privilege-praktijk, omdat het bewust de automatisch-op-dag-één-set zo smal mogelijk houdt.

Moet birthright access ooit goedkeuring vereisen? Nee. Als iets goedkeuring vereist, is het per definitie geen birthright access, maar aangevraagde of rolgebaseerde toegang. Die grens scherp houden is wat dag één snel houdt zonder van elk account een automatisch afvinkje te maken.

Hoe vaak moet een birthright access-definitie herzien worden? Eén tot twee keer per jaar is meestal genoeg voor een stabiele organisatie, vaker als je door reorganisaties gaat of snel groeit, want dat zijn de momenten waarop scope creep het makkelijkst de regel binnensluipt.

Wijst ServiceChanger birthright access automatisch toe? Ja, via de ABAC-engine: regels beoordelen Entra ID- en on-prem AD-attributen zoals dienstverbandstatus, afdeling en locatie, en kennen groeps- en rollidmaatschap dienovereenkomstig toe of trekken dit in, ook bij mover- en leaver-gebeurtenissen, zodat birthright- en rolgebaseerde toegang accuraat blijven zonder handmatig groepsbeheer.

Birthright access goed regelen gaat niet om meer automatiseren, maar om het juiste, smalle ding automatiseren en al het andere attribuutgestuurd houden zodat het niet ongemerkt onderdeel van de basis wordt. Voor meer over toegang structureren op basis van attributen in plaats van handmatig groepsbeheer, bekijk onze artikelen over onboarding en access control op de blog.

Volgende stap

Benieuwd wat jouw huidige birthright access daadwerkelijk bevat versus wat het zou moeten bevatten? Plan een demo of lees de documentatie over toegangsautomatisering.