Systeemtoegewezen versus door de gebruiker toegewezen Azure-beheerde identiteiten: welke kies je?

By Mirko Peters · 2026-10-26

Vergelijk systeemtoegewezen en door de gebruiker toegewezen Azure-beheerde identiteiten. Ontdek welk identiteitstype je moet kiezen om de administratieve lasten te verlagen en veilig te schalen.

Automatically translated with AI from the original post. Read the English original

Kiezen tussen systeemtoegewezen en door de gebruiker toegewezen beheerde identiteiten in Azure is een van de belangrijkste architectuurbeslissingen voor cloudbeveiliging en administratieve lasten. Systeemtoegewezen identiteiten zijn rechtstreeks gekoppeld aan de levenscyclus van één Azure-resource, terwijl door de gebruiker toegewezen identiteiten zelfstandige entiteiten zijn die over meerdere resources gedeeld kunnen worden. Dat scheelt flink in overbodige roltoewijzingen en voorkomt knelpunten met tokenlimieten in geautomatiseerde omgevingen.

Belangrijkste punten

• Systeemtoegewezen identiteiten worden automatisch aangemaakt, beheerd en verwijderd samen met de bijbehorende Azure-resource.
• Door de gebruiker toegewezen identiteiten bestaan los als zelfstandige Azure-resources, waardoor ze gedeeld kunnen worden tussen meerdere VM's, apps en functies.
• Microsoft raadt door de gebruiker toegewezen identiteiten aan voor de meeste scenario's met meerdere resources, om het beheerwerk en de complexe roltoewijzingen te beperken.
• Systeemtoegewezen identiteiten gebruiken in snel schalende of kortstondige testomgevingen kan ertoe leiden dat identiteiten zich opstapelen en Azure-limieten voor aanvragen overschrijden.
• Eén Azure-resource kan zowel een systeemtoegewezen identiteit voor geïsoleerde logging als een of meer door de gebruiker toegewezen identiteiten voor gedeelde workloads hebben.

De kernverschillen begrijpen

Wanneer je cloudapplicaties ontwerpt die veilig werken zonder hardcoded geheimen of verbindingsreeksen, moet je bepalen hoe je workloads zich bij Microsoft Entra ID authenticeren. Azure biedt twee soorten beheerde identiteiten: systeemtoegewezen en door de gebruiker toegewezen. Als je begrijpt hoe ze onder de motorkap werken, bespaar je je engineeringteam ontelbare uren aan probleemoplossing en administratief onderhoud.

Hoe systeemtoegewezen identiteiten werken

Een systeemtoegewezen beheerde identiteit wordt rechtstreeks in een specifieke Azure-resource ingeschakeld, zoals een Azure Virtual Machine, App Service of Function App. Je kunt het zien als een identiteit die samen met de resource wordt geboren en ook samen met de resource sterft. Wanneer je een systeemtoegewezen identiteit op een virtuele machine inschakelt, maakt Azure in Microsoft Entra ID een identiteit aan met exact de naam van die resource.

Het grootste voordeel van deze aanpak is eenvoud en een nauwe koppeling aan de levenscyclus. Omdat de identiteit aan de resource is gekoppeld, hoef je je nooit zorgen te maken over verweesde identiteiten die in je directory blijven hangen nadat een virtuele machine buiten gebruik is gesteld. Als je de resource verwijdert, verwijdert Azure de identiteit automatisch voor je. Deze strakke koppeling brengt echter architectonische beperkingen met zich mee als meerdere resources dezelfde toegangsrechten nodig hebben.

Hoe door de gebruiker toegewezen identiteiten werken

Een door de gebruiker toegewezen beheerde identiteit wordt daarentegen eerst als zelfstandige Azure-resource aangemaakt. Je geeft die een eigen naam, beheert hem los binnen je resourcegroepen en koppelt hem expliciet aan een of meer Azure-services die toegang nodig hebben. Omdat hij niet gebonden is aan de levenscyclus van één virtuele machine of app service, blijft hij bestaan, ook als alle resources die eraan gekoppeld zijn, worden verwijderd.

Dit zelfstandige karakter verandert de manier waarop cloudarchitecten toegangsbeheer op schaal aanpakken. In plaats van authenticatie te zien als een een-op-eenrelatie tussen één server en een database, maken door de gebruiker toegewezen identiteiten many-to-one-authenticatiemodellen mogelijk, waarin clusters van microservices één goed beheerde beveiligingscontext delen.

Administratieve overhead en roltoewijzingen

De praktische verschillen tussen deze twee identiteitstypen worden pijnlijk duidelijk wanneer je kijkt naar het beheer van op rollen gebaseerd toegangsbeheer (RBAC) in grote omgevingen. Elke keer dat je een identiteit toegang geeft tot een opslagaccount, key vault of database, moet je een Azure-roltoewijzing aanmaken.

Stel je een veelvoorkomend scenario in een grote organisatie voor: je hebt vier virtuele machines die allemaal gegevens moeten lezen uit twee afzonderlijke Azure Storage-accounts. Als je uitsluitend vertrouwt op systeemtoegewezen identiteiten, heeft elke virtuele machine een eigen identiteit nodig. Om toegang te verlenen, moet je acht afzonderlijke roltoewijzingen configureren, één per machine per storage-account. Als je opschaalt naar twintig virtuele machines, groeit het aantal roltoewijzingen exponentieel en ontstaat er een administratieve nachtmerrie.

Als diezelfde vier virtuele machines daarentegen één gedeelde door de gebruiker toegewezen beheerde identiteit gebruiken, heb je in totaal maar twee roltoewijzingen nodig. Je krijgt exact dezelfde fijnmazige toegangscontrole tegen een fractie van de beheerinspanning. Wanneer teamleden vertrekken of de infrastructuur opnieuw wordt opgebouwd, wordt het onderhouden van een schone directory een stuk eenvoudiger.

Architecturale valkuilen en uitzonderingsgevallen

Door de gebruiker toegewezen identiteiten zijn over het algemeen efficiënter, maar de verkeerde keuze voor het type kan verborgen operationele wrijving veroorzaken. Een grote valkuil doet zich voor bij kortstondige rekenresources of omgevingen met automatisch schalen.

Als je met systeemtoegewezen identiteiten gedurende de dag snel ontwikkel-, test- of containeromgevingen aanmaakt en weer verwijdert, stapelen die identiteiten zich op in Microsoft Entra ID voordat de opschoonroutines worden uitgevoerd. Uiteindelijk kunnen organisaties de Azure-limieten voor directory-aanvragen bereiken, waardoor het platform het aanmaken van nieuwe resources volledig weigert. Een door de gebruiker toegewezen identiteit delen over deze kortlevende workloads heen, voorkomt deze valkuil volledig.

Omgekeerd schitteren systeemtoegewezen identiteiten in twee specifieke scenario's:

• Auditing en non-repudiation: Als je beveiligingslogboeken onomstotelijk moeten aantonen welke exacte virtuele machine een specifieke actie heeft uitgevoerd, bieden systeemtoegewezen identiteiten die attributie op microniveau, omdat elke resource zijn eigen unieke directory-object behoudt.
• Strikte opschoning van de levenscyclus: Als compliancevereisten voorschrijven dat alle toegangsmachtigingen op het exacte moment verdwijnen waarop een resource wordt beëindigd, regelen systeemtoegewezen identiteiten dit automatisch, zonder menselijke tussenkomst.

Houd er rekening mee dat je niet gedwongen wordt tot een absolute keuze. Eén Azure-resource kan zowel een systeemtoegewezen identiteit voor privé, gevoelige bewerkingen als een of meer door de gebruiker toegewezen identiteiten voor gedeelde zakelijke workflows bevatten.

Conclusie

Identiteitsbeheer in de Microsoft-cloud vereist een balans tussen operationele efficiëntie en strikte beveiligingsgrenzen. Door de verschillen in operationeel gedrag tussen systeemtoegewezen en door de gebruiker toegewezen identiteiten te begrijpen, kun je robuuste, schaalbare architecturen ontwerpen die hardcoded geheimen elimineren zonder administratieve bloat.

Wil je dieper ingaan op hoe tokens worden uitgegeven, hoe Azure Key Vault zonder wachtwoorden integreert en welke veelvoorkomende beveiligingsvalkuilen je moet vermijden? Zorg dat je de volledige aflevering beluistert van de podcast voor expertinzichten en praktische strategieën.

Veelgestelde vragen

Kan een enkele Azure-resource zowel systeemtoegewezen als door de gebruiker toegewezen beheerde identiteiten gebruiken?

Ja. Een Azure-resource zoals een virtuele machine of App Service kan tegelijkertijd één systeemtoegewezen identiteit en één of meer door de gebruiker toegewezen identiteiten hebben ingeschakeld, zodat je gedeelde en dedicated authenticatiestrategieën kunt combineren.

Wat gebeurt er met een door de gebruiker toegewezen identiteit wanneer de Azure-resource waaraan hij is gekoppeld, wordt verwijderd?

In tegenstelling tot systeemtoegewezen identiteiten, die automatisch worden verwijderd wanneer hun bovenliggende resource wordt verwijderd, blijven door de gebruiker toegewezen identiteiten bestaan als zelfstandige objecten in Azure totdat een beheerder ze expliciet verwijdert.

Waarom raadt Microsoft door de gebruiker toegewezen identiteiten aan voor de meeste scenario's met meerdere resources?

Microsoft raadt door de gebruiker toegewezen identiteiten vooral aan om administratieve overhead en een wildgroei aan roltoewijzingen te beperken. Door één identiteit over meerdere rekenresources te delen, verklein je het aantal RBAC-toewijzingen dat je moet aanmaken en onderhouden aanzienlijk.

Kosten managed identities iets om in Azure te gebruiken?

Nee, zowel door het systeem toegewezen als door de gebruiker toegewezen beheerde identiteiten zijn gratis functies die zijn inbegrepen bij Microsoft Entra ID for Azure resources, al kunnen er wel standaardkosten gelden voor de onderliggende rekenkracht- of opslagservices die je gebruikt.