De vorm van identity in een bedrijf
Identity is de control plane voor wie en wat iets mag doen. De truc om het beheersbaar te houden: nest accounts in groups en roles, en pin nooit een permission op een user.
Het verschil tussen “zet die persoon in de group” en “elke permission die hij ooit aangeraakt heeft ne keer uitvlooien” is meestal een vrijdagnamiddag. Krijg de structuur nu juist. Identity management is dat weinig glamoureuze infrastructuurwerk dat pas rendeert wanneer je een simpele vraag moet beantwoorden: wie of wat mag iets doen, waar, en onder welke voorwaarden. Elke entity die IT aanraakt is een identity: personeel, contractors, guests, service accounts, bots, AI agents, devices, workloads. Krijg de nesting juist, en joiner/mover/leaver, access reviews en least privilege vallen er vanzelf uit. Krijg ze verkeerd, en je zit de volgende drie jaar permissions met de hand te patchen, één ACL per keer.
(Moest je het frame nog niet gezien hebben: identities zijn één van de vijf pillars die moderne IT-infrastructuur structureren. Dit stuk graaft in hoe je de identity-pillar zelf vormgeeft.)
Alles is een identity
Begin bij de basis: een identity is alles dat authenticeert en geautoriseerd geraakt. Dat zijn mensen, maar evengoed service accounts, bots, AI agents, devices, en workloads die in containers draaien. Elke identity heeft een owner, een doel, en een lifecycle. Ze beginnen als een request, geraken geprovisioned, gaan live, krijgen misschien elevation voor een taak, en worden gesuspend en gedeprovisioned wanneer ze klaar zijn.
De structurele regel die telt: elke automation hoort zijn eigen service identity te hebben in plaats van de account van een mens te lenen. Dat is al jaren geen optie meer, in de meeste estates zijn de non-human identities intussen talrijker dan de mensen.
Pin permissions niet op mensen, nest ze
Hier is de structurele regel die access beheersbaar houdt op elke schaal: je geeft User A nooit rechtstreeks een permission. Je nest. Het is de klassieke AGDLP-keten, Account → Global group → Domain local group → Permission, en ze mapt nog altijd proper op een moderne IdP.
User A is een account. Het is lid van een global group (Team A1), die nest in een department, die nest in een business unit. De permission zit op geen enkele daarvan. Ze zit op een domain local group die access tot exact één resource voorstelt. Membership stroomt naar beneden door de nest, rights hangen aan het verre uiteinde, en de twee ontmoeten elkaar alleen in het midden.
Roles zijn de eenheid waarmee je echt ontwerpt
Groups modelleren wie je bent, roles modelleren wat je mag doen. Een role is één of meer access rights gebundeld in iets met een naam die een mens herkent: “PLC integrator”, “Backup operator”, “Read-only auditor”. Roles nesten op dezelfde manier als groups: een parent role kan child roles bevatten, een identity kan er meerdere tegelijk houden, en een role respecteert dezelfde tiering als de accounts erin (een role bevat altijd alleen identities uit één tier). Ontwerp access als roles → rights, en je stopt met individuele users één voor één aan individuele permissions te draden, checkbox per checkbox.
De tiering is geen decoratie. Base identities doen het dagelijkse werk, tier 0 is domain-admin-terrein, en de twee mengen nooit, zodat een gecompromitteerde mailbox niet aan de control plane geraakt. Roles erven die discipline in plaats van er stilletjes een brug over te slaan.
Golden rule: nest membership, hang permissions één keer. De dag dat je een user zit te editen om access te geven, ben je de draad al kwijt.
Waarom de moeite
De payoff is saai, en dat is net het punt. Joiner/mover/leaver valt terug op “verander group membership,” niet op “elke resource uitvlooien die deze persoon zou kunnen aanraken.” Access reviews lees je af van roles in plaats van rauwe ACLs, zodat je echt kunt beantwoorden “wie had wat, wanneer, en wie heeft het goedgekeurd.” Least privilege en tiering vallen uit de structuur in plaats van met de hand bewaakt te worden. En de tooling eronder mag veranderen, AD vandaag, Entra of Authentik morgen, want de vorm verandert niet: accounts in groups, groups in roles, permissions precies één keer gehangen, aan het verre uiteinde van de nest.