Hoe Managed Identities hardcoded wachtwoorden in Azure overbodig maken

By Mirko Peters · 2026-08-13

Welkom terug bij de begeleidende blog van onze podcast! Als je al langer applicaties bouwt, ben je waarschijnlijk het eeuwenoude probleem tegengekomen van hoe je je code koppelt aan een database, een API of een cloudopslagaccount…

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

Welkom terug bij de begeleidende blog van onze podcast! Als je al langer applicaties bouwt, ben je waarschijnlijk het eeuwenoude probleem tegengekomen van hoe je je code koppelt aan een database, een API of een cloudopslagaccount. Vroeger loste je dit op door een connectionstring, een databasewachtwoord of een clientgeheim rechtstreeks in een configuratiebestand, een omgevingsvariabele te zetten, of, nog erger, het hard in de broncode van je repository te coderen. Zolang de applicatie dat geheim kon lezen, kon ze zich authenticeren en haar werk doen. Maar wat gebeurt er als die code per ongeluk naar een openbare GitHub-repository wordt gepusht? Wat gebeurt er als een ontevreden medewerker vertrekt, of als een aanvaller leestoegang krijgt tot de instellingen van je applicatie? Dan is je hele infrastructuur meteen gecompromitteerd. In moderne cloudarchitectuur is dit een onaanvaardbaar risico. Vandaag duiken we diep in hoe Managed Identities in Microsoft Azure het gebruik van hardcoded wachtwoorden volledig overbodig maken, en statische geheimen vervangen door dynamische, kortlevende toegangstokens.

Inleiding tot cloudbeveiliging en hardcoded geheimen

Het traditionele, op perimeters gebaseerde beveiligingsmodel vertrouwde er sterk op dat je, zodra je binnen het bedrijfsnetwerk zat, betrouwbaar was. Binnen die perimeter communiceerden applicaties met statische serviceaccounts, hardcoded wachtwoorden en langlevende tokens die zelden of nooit verliepen. Als een kwaadwillende de perimeter doorbrak, had hij toegang tot een schat aan statische inloggegevens die onbeperkt opnieuw gebruikt konden worden.

Cloudcomputing heeft deze perimeter volledig doen verdwijnen. Onze workloads zijn nu verspreid over multi-cloudomgevingen, on-premises datacenters, SaaS-platforms en gedistribueerde serverless functies. In deze nieuwe wereld moet beveiliging de identiteit van de workload zelf volgen. Hardcoded geheimen zijn tikkende tijdbommen. Ze worden niet automatisch geroteerd, ze zijn notoir moeilijk te auditen en laten geen enkele ruimte voor fouten zodra ze gelekt zijn. Om echte Zero Trust-beveiliging te bereiken, moeten we inloggegevens volledig loskoppelen van onze broncode. We hebben een authenticatiemechanisme nodig waarbij applicaties kunnen bewijzen wie ze zijn, zonder ooit een wachtwoord te hoeven kennen of op te slaan.

Gebruikersidentiteiten versus workloadidentiteiten in Entra ID

Om te begrijpen hoe cloudbeveiliging is geëvolueerd, moeten we eerst kijken hoe Microsoft Entra ID de entiteiten beheert die toegang krijgen tot onze systemen. In grote lijnen verdeelt Microsoft Entra ID identiteiten in twee hoofdcategorieën: gebruikersidentiteiten en workloadidentiteiten.

Gebruikersidentiteiten vertegenwoordigen mensen: medewerkers, partners, contractors en klanten. Mensen werken dynamisch met systemen en authenticeren zich met methoden die op mensen zijn afgestemd, zoals wachtwoorden, Windows Hello for Business, FIDO2-beveiligingssleutels en multifactorauthenticatie. Mensen vergeten wachtwoorden, trappen in phishingaanvallen en hebben beheerderswachtwoorden nodig die opnieuw worden ingesteld.

Workloadidentiteiten daarentegen vertegenwoordigen software. Dat omvat applicaties, achtergrondservices, automatiseringsscripts, Azure Functions, Logic Apps, DevOps-deploymentpipelines en AI-agents. Workloads drinken geen koffie, ze klikken niet op phishingmails en ze kunnen geen interactieve multifactorauthenticatieprompt op een smartphone afronden. Ze moeten niet-interactief, programmatisch en continu kunnen authenticeren. Een workloadidentiteit behandelen als een gebruikersidentiteit door er een statisch wachtwoord aan toe te kennen, is een van de meest voorkomende valkuilen in cloudarchitectuur. Workloadidentiteiten vragen om hun eigen gespecialiseerde governancemodellen, levenscyclusbeheer en geautomatiseerde authenticatiestromen.

App-registraties, service principals en Managed Identities ontrafeld

Als je enige tijd applicaties in Microsoft Entra ID hebt geconfigureerd, ben je ongetwijfeld drie termen tegengekomen die vaak voor verwarring zorgen: app-registraties, service principals en Managed Identities. Laten we ze eenvoudig uitleggen.

Een app-registratie is de wereldwijde definitie of blauwdruk van je applicatie. Wanneer je een applicatie registreert in Microsoft Entra ID, maak je de wereldwijde identiteit ervan aan binnen het volledige multi-tenant-ecosysteem. Hier definieer je welke machtigingen de applicatie mogelijk nodig heeft, welke authenticatie-endpoints ze gebruikt en welke URI's ermee verbonden zijn. Zie de app-registratie als het sjabloon van een paspoort.

Een service-principal is de lokale instantie van die applicatie binnen een specifieke tenant. Als een applicatie multi-tenant is, heeft ze één app-registratie in de tenant van de uitgever, maar een aparte service-principal in elke afzonderlijke klanttenant waarin ze wordt uitgerold en waarvoor toestemming is verleend. De service-principal is de plek waar beheerders daadwerkelijk machtigingen toewijzen, voorwaardelijke toegangsbeleidsregels toepassen en lokaal bepalen wie toegang heeft tot de applicatie. Zie de service-principal als het daadwerkelijke, gestempelde paspoort waarmee je een specifiek land binnenkomt.

Een beheerde identiteit (managed identity) brengt dit concept een stap verder, specifiek voor resources die draaien binnen Microsoft Azure. In plaats van dat een ontwikkelaar handmatig een app-registratie moet aanmaken, een clientgeheim moet genereren, dat geheim moet opslaan in een omgevingsvariabele en code moet schrijven om de levenscyclus van de authenticatie af te handelen, neemt Azure het hele proces achter de schermen over. Azure maakt de onderliggende referenties aan, beheert ze en roteert ze automatisch voor je. De ontwikkelaar vertelt de Azure-resource simpelweg dat hij zijn beheerde identiteit moet gebruiken, en Azure regelt de rest.

Hoe beheerde identiteiten wachtwoorden en hardgecodeerde referenties overbodig maken

De kracht van beheerde identiteiten zit in hoe ze de authenticatietransactie fundamenteel veranderen. Wanneer je een beheerde identiteit gebruikt voor een Azure-resource, zoals een Azure App Service, een virtuele machine of een Azure Function, staat er letterlijk geen wachtwoord, geheim of certificaat opgeslagen in je code of configuratie-instellingen.

Wanneer je applicatie toegang nodig heeft tot een beveiligde resource, zoals een database of een API, zoekt ze geen opgeslagen wachtwoord op. In plaats daarvan doet de applicatie een lokale aanroep naar het eindpunt van de Azure Instance Metadata Service (IMDS), dat alleen binnen die specifieke Azure-resource beschikbaar is. Het onderliggende platform van de Azure-resource vraagt vervolgens namens de applicatie rechtstreeks bij Microsoft Entra ID een kortlevend JSON Web Token (JWT) aan.

Microsoft Entra ID verifieert de identiteit van de Azure-resource, geeft een cryptografisch ondertekend toegangstoken met een zeer korte levensduur (meestal ongeveer een uur) uit en geeft dat terug aan de applicatie. De applicatie gebruikt dit token vervolgens om zich bij de doeldienst te authenticeren. Omdat het token snel verloopt, is het kwetsbare tijdvenster extreem klein, zelfs als een aanvaller het token onderschept. Bovendien staat er geen statisch wachtwoord in de code geschreven, dus er is niets dat een ontwikkelaar per ongeluk kan lekken naar een openbare repository.

Azure Key Vault en kortlevende toegangstokens combineren

Beheerde identiteiten maken applicatiewachtwoorden overbodig, maar je vraagt je misschien af hoe applicaties omgaan met geheimen die echt extern zijn, zoals API-sleutels voor diensten van derden die geen Microsoft Entra-authenticatie ondersteunen. Hier komt Azure Key Vault in beeld, dat nauw samenwerkt met beheerde identiteiten.

In plaats van een API-sleutel van een derde partij hard te coderen in je broncode, sla je dat geheim veilig op in Azure Key Vault. Vervolgens geef je de beheerde identiteit van je Azure-resource de machtiging om geheimen uit die Key Vault te lezen, via Azure Role-Based Access Control (RBAC) of Key Vault-toegangsbeleidsregels.

Wanneer je applicatie opstart, gebruikt ze haar beheerde identiteit om zich bij Azure Key Vault te authenticeren, haalt ze de benodigde API-sleutel van de derde partij dynamisch op in het geheugen en gebruikt ze die. Op geen enkel moment worden referenties blootgesteld in de broncode. De applicatie gebruikt een veilig, identiteitsgebaseerd mechanisme om een geheim op te halen, in plaats van te vertrouwen op een statische tekenreeks die in een configuratiebestand is ingebed.

Workload-identiteiten beveiligen met least privilege en governance

Het elimineren van hardgecodeerde wachtwoorden is een enorme winst voor de beveiliging, maar het uitrollen van beheerde identiteiten is geen model van "instellen en vergeten". Workload-identiteiten vereisen degelijke governance, net zoals menselijke gebruikersaccounts dat doen.

Allereerst moet je strikt het principe van de minste privileges volgen. Ken geen brede bijdragerollen of overmatige Microsoft Graph-machtigingen toe aan een workload-identiteit om dingen snel aan de praat te krijgen. Als een achtergrondautomatiescript alleen items hoeft te lezen uit één specifieke Azure Storage-container, geef het dan Storage Blob Data Reader-toegang tot precies die container, en niets meer. Als die workload-identiteit ooit wordt gecompromitteerd, blijft de impact dan minimaal.

Ten tweede moet je je workload-identiteiten continu monitoren en controleren. Organisaties maken vaak service principals en beheerde identiteiten aan voor proof-of-concept-projecten, automatiseringsscripts en tijdelijke integraties, om ze vervolgens onbeperkt te laten draaien met hoge machtigingen. Voer regelmatig beveiligingsreviews uit om verweesde service principals, ongebruikte automatiseringsaccounts en verouderde referenties op te sporen. Door gebruik te maken van functies zoals Microsoft Entra ID Protection en een degelijke logging via Azure Monitor, heb je volledig zicht op wanneer en hoe je workload-identiteiten toegang krijgen tot je omgeving.

De juiste identiteitsstrategie kiezen voor elke cloudworkload

Met zoveel opties binnen het Microsoft-identiteitsecosysteem: hoe kies je de juiste authenticatiestrategie voor jouw specifieke workload? De keuze hangt meestal af van waar je applicatie draait en hoe die is opgebouwd.

Als je code binnen Microsoft Azure draait, of het nu gaat om Azure App Services, Azure Functions, Virtual Machines, Container Instances of Azure Kubernetes Service, dan is je eerste keuze altijd een Managed Identity. Je kunt kiezen tussen een System-Assigned Managed Identity (die een 1:1-levenscyclus heeft, direct gekoppeld aan de Azure-resource) of een User-Assigned Managed Identity (die los kan worden aangemaakt en over meerdere Azure-resources kan worden toegewezen, wat het beheer eenvoudiger maakt).

Draait je applicatie buiten Azure, bijvoorbeeld op on-premises servers, in AWS of als onderdeel van een CI/CD-pipeline in GitHub Actions, dan komen Managed Identities die door de Azure-infrastructuur worden gehost niet in aanmerking. In die scenario's moet je gebruikmaken van Workload Identity Federation. Hiermee kunnen externe platformen tokens rechtstreeks uitwisselen met Microsoft Entra ID via een OpenID Connect (OIDC)-vertrouwensrelatie. Je hoeft dan geen langlevende clientgeheimen meer te beheren, te roteren of op te slaan.

Ten slotte geldt voor traditionele maatwerk-enterpriseapplicaties die clientauthenticatie vereisen, waarbij noch Managed Identities noch federatie haalbaar zijn: zorgvuldig beheerde certificaten hebben altijd de voorkeur boven langlevende clientgeheimen. Door Microsoft Entra Workload Identities, Azure Key Vault, Zero Trust-principes en toegang op basis van de minste privileges te combineren, kan je organisatie hardgecodeerde wachtwoorden volledig uitbannen en een opmerkelijk veerkrachtige cloudarchitectuur opbouwen.

Conclusie en volgende stappen voor moderne cloudbeveiliging

Hardgecodeerde wachtwoorden en statische verbindingsreeksen zijn relicten uit een verouderd tijdperk van IT-beveiliging. Door Microsoft Entra Workload Identities en Azure Managed Identities te omarmen, kunnen we de risico's van ingebedde referenties volledig elimineren, onze broncoderepositories beschermen tegen onbedoelde lekken en strikte toegang op basis van de minste privileges afdwingen voor al onze cloud-native applicaties. Kortlevende toegangstokens zorgen ervoor dat zelfs als een token wordt onderschept, de levensduur ervan te kort is om blijvende schade aan te richten. Zo verschuift onze beveiligingshouding fundamenteel van reactieve verdediging naar proactieve bescherming.

Wil je dit onderwerp nog dieper verkennen en praktische implementatietips uit de praktijk horen? Bekijk dan zeker de bijbehorende podcastaflevering: Entra Workload Identities - Simply Explained. Luister mee terwijl we deze concepten nog verder uiteenzetten, zodat je je Azure- en Microsoft 365-omgevingen als een pro kunt beveiligen!