💼 Management Samenvatting
Beheerde identiteiten in Azure elimineren de noodzaak voor hardcoded credentials, wachtwoorden en connection strings in applicatiecode door Azure-resources automatisch te authenticeren met Microsoft Entra ID. Deze zero-secrets architectuur vormt een fundamenteel onderdeel van de Nederlandse Baseline voor Veilige Cloud omdat het het risico op credential leakage drastisch vermindert, automatische credential rotation mogelijk maakt en naadloze integratie biedt met Azure RBAC voor fine-grained toegangscontrole. Wanneer applicaties, virtuele machines, container instances of andere Azure-resources gebruik maken van beheerde identiteiten, hoeven ontwikkelaars en beheerders geen secrets meer op te slaan in code, configuratiebestanden of environment variables. In plaats daarvan verleent Azure automatisch een identiteit aan de resource die kan worden gebruikt voor authenticatie bij andere Azure-services zoals Key Vault, Storage Accounts, SQL Database, Service Bus en honderden andere services. Deze identiteit wordt volledig beheerd door Azure, inclusief automatische token refresh en credential rotation, zonder dat er developer intervention nodig is. Het belang van beheerde identiteiten wordt nog duidelijker wanneer we kijken naar de realiteit van moderne cloud-omgevingen. Onderzoek toont aan dat meer dan 60% van alle data breaches het gevolg is van gestolen of gelekte credentials. Hardcoded wachtwoorden in applicatiecode die per ongeluk worden gecommit naar GitHub, connection strings in configuratiebestanden die in logbestanden terechtkomen, of service principal secrets die worden gedeeld via onveilige kanalen vormen dagelijks een bedreiging voor organisaties. Beheerde identiteiten elimineren deze risico's volledig door een zero-secrets architectuur te implementeren waarbij geen enkele credential in code, configuratie of environment variables hoeft te worden opgeslagen. Dit is met name kritiek voor Nederlandse overheidsorganisaties die moeten voldoen aan strikte compliance-eisen vanuit de AVG, BIO en NIS2, waarbij het veilig beheren van credentials een expliciete vereiste is. Bovendien biedt de implementatie van beheerde identiteiten operationele voordelen die verder gaan dan alleen beveiliging. Wanneer applicaties gebruik maken van beheerde identiteiten, wordt credential management volledig geautomatiseerd. Azure zorgt automatisch voor token refresh, zodat applicaties altijd valide credentials hebben zonder dat ontwikkelaars of beheerders hier handmatig actie voor hoeven te ondernemen. Dit vermindert de operationele overhead aanzienlijk en voorkomt downtime die kan optreden wanneer credentials verlopen. Daarnaast biedt beheerde identiteit naadloze integratie met Azure RBAC, waardoor organisaties fine-grained toegangscontrole kunnen implementeren op basis van de least privilege principle. Elke beheerde identiteit kan exact de rechten krijgen die nodig zijn voor de specifieke taak, zonder dat er overbodige permissions worden verleend. De audit- en compliance-voordelen zijn eveneens aanzienlijk. Wanneer beheerde identiteiten worden gebruikt, wordt elke authenticatiepoging automatisch gelogd in Azure AD sign-in logs, waardoor organisaties een complete audittrail hebben van wanneer en hoe resources toegang krijgen tot services. Dit is essentieel voor compliance-frameworks zoals ISO 27001, waarbij organisaties moeten aantonen dat toegang tot systemen wordt gecontroleerd en gemonitord. Bovendien maakt de zero-secrets architectuur het onmogelijk dat credentials per ongeluk worden gecommit naar version control systems, gedeeld via onveilige kanalen of opgeslagen in onbeveiligde locaties. Dit vermindert het risico op credential leakage aanzienlijk en maakt het voor auditors eenvoudiger om te verifiëren dat credentials veilig worden beheerd. Tot slot biedt beheerde identiteit flexibiliteit door twee verschillende typen te ondersteunen: system-assigned en user-assigned. Een system-assigned identity is uniek gekoppeld aan een specifieke Azure-resource en wordt automatisch verwijderd wanneer de resource wordt verwijderd. Dit is ideaal voor resources die een dedicated identiteit nodig hebben. Een user-assigned identity bestaat onafhankelijk van resources en kan worden toegewezen aan meerdere resources tegelijkertijd. Dit is handig wanneer meerdere resources dezelfde identiteit moeten delen, bijvoorbeeld voor toegang tot een gedeelde Key Vault of Storage Account. Door de juiste keuze te maken tussen deze twee typen kunnen organisaties een optimale balans vinden tussen beveiliging, flexibiliteit en beheerbaarheid.
Het niet configureren van beheerde identiteiten voor Azure-resources creëert een reeks kritieke beveiligingsrisico's die organisaties blootstellen aan credential leakage, data breaches en compliance-schendingen. Wanneer applicaties en resources gebruik maken van hardcoded credentials, connection strings of service principal secrets, ontstaat er een situatie waarin deze credentials op meerdere plekken worden opgeslagen: in applicatiecode, configuratiebestanden, environment variables, deployment scripts en mogelijk zelfs in logbestanden of error messages. Elke locatie waar credentials worden opgeslagen vormt een potentieel lekpunt. Onderzoek toont aan dat meer dan 60% van alle data breaches het gevolg is van gestolen of gelekte credentials, en dat hardcoded credentials in code de nummer één oorzaak zijn van beveiligingslekken in cloud-omgevingen. Het risico op credential leakage is bijzonder hoog wanneer developers credentials in code plaatsen die vervolgens per ongeluk worden gecommit naar version control systems zoals GitHub, GitLab of Azure DevOps. Zelfs wanneer credentials later worden verwijderd uit de code, blijven ze zichtbaar in de Git-geschiedenis, waar ze kunnen worden ontdekt door kwaadwillende actoren of automatische scanners. Dit probleem wordt verergerd door het feit dat veel organisaties publieke repositories gebruiken of repositories met onvoldoende toegangscontrole, waardoor gelekte credentials snel kunnen worden misbruikt. Bovendien maken hardcoded credentials credential rotation tot een nachtmerrie, omdat secrets op meerdere plekken moeten worden bijgewerkt, wat vaak leidt tot inconsistenties, downtime of het vergeten van bepaalde locaties. Daarnaast vormt het ontbreken van beheerde identiteiten een significant compliance-risico. Frameworks zoals ISO 27001, NIS2 en de BIO vereisen dat organisaties aantonen dat credentials veilig worden beheerd en dat toegang tot systemen wordt gecontroleerd en gemonitord. Wanneer hardcoded credentials worden gebruikt, is het onmogelijk om een complete audittrail te hebben van wanneer en hoe credentials worden gebruikt, omdat authenticatie niet wordt gelogd in Azure AD sign-in logs. Dit maakt het voor auditors moeilijk om te verifiëren dat credentials veilig worden beheerd en dat toegang wordt gecontroleerd volgens het least privilege principle. Bovendien kan het gebruik van hardcoded credentials worden gezien als een schending van security best practices, wat kan leiden tot negatieve auditbevindingen, mogelijke boetes en reputatieschade. Het operationele risico mag evenmin worden onderschat. Wanneer credentials verlopen of worden geroteerd, moeten ontwikkelaars en beheerders handmatig actie ondernemen om nieuwe credentials te configureren in alle applicaties en resources die deze gebruiken. Dit proces is foutgevoelig, tijdrovend en kan leiden tot downtime wanneer credentials onverwacht verlopen of wanneer rotatie niet correct wordt uitgevoerd. Bovendien maakt het gebruik van hardcoded credentials het moeilijk om fine-grained toegangscontrole te implementeren, omdat service principals vaak overbodige permissions krijgen om te voorkomen dat toegang wordt geblokkeerd wanneer applicaties worden gewijzigd. Dit schendt het least privilege principle en vergroot het aanvalsoppervlak aanzienlijk. Het financiële en reputatietechnische risico is eveneens aanzienlijk. Een enkel credential leak kan leiden tot ongeautoriseerde toegang tot gevoelige data, wat kan resulteren in data breaches, compliance-schendingen en mogelijke boetes onder de AVG. Voor Nederlandse overheidsorganisaties kan dit bovendien leiden tot vragen in de Tweede Kamer, onderzoeken door de Algemene Rekenkamer en verlies van vertrouwen bij burgers. De kosten van incident response, forensisch onderzoek, credential rotation, communicatie en eventuele juridische procedures kunnen snel oplopen tot honderdduizenden euro's, terwijl de reputatieschade op de langere termijn nog veel groter kan zijn. Daarom is het configureren van beheerde identiteiten geen optionele luxe maar een essentiële beveiligingsmaatregel voor alle Azure-resources die toegang nodig hebben tot andere Azure-services. Door beheerde identiteiten te implementeren, elimineren organisaties het risico op credential leakage volledig, automatiseren zij credential management, verbeteren zij compliance en auditmogelijkheden, en verminderen zij operationele overhead. Deze maatregel vormt een fundamenteel onderdeel van een volwassen cloud security-strategie binnen de Nederlandse Baseline voor Veilige Cloud.
Connection:
Connect-AzAccountRequired Modules: Az.Accounts, Az.ManagedServiceIdentity, Az.Resources
Implementatie
Deze maatregel omvat het configureren van beheerde identiteiten voor alle Azure-resources die toegang nodig hebben tot andere Azure-services, waarbij hardcoded credentials, connection strings en service principal secrets worden vervangen door automatische authenticatie via beheerde identiteiten. Het proces begint met een grondige inventarisatie van alle Azure-resources die momenteel gebruik maken van hardcoded credentials: welke App Services, Function Apps, Virtual Machines, Container Instances of andere resources hebben toegang nodig tot Azure-services zoals Key Vault, Storage Accounts, SQL Database of Service Bus? Documenteer per resource welke services worden gebruikt en welke credentials momenteel worden toegepast. Vervolgens bepaal je per resource of een system-assigned of user-assigned identity het meest geschikt is. Een system-assigned identity is ideaal wanneer een resource een dedicated identiteit nodig heeft die automatisch wordt verwijderd wanneer de resource wordt verwijderd. Een user-assigned identity is geschikt wanneer meerdere resources dezelfde identiteit moeten delen of wanneer de identiteit onafhankelijk van de resource moet bestaan. Na het bepalen van het type identiteit, schakel je de beheerde identiteit in via de Azure Portal, Azure CLI of PowerShell. Voor een system-assigned identity navigeer je naar de resource in de Azure Portal, ga je naar de Identity-sectie en schakel je System assigned in. Voor een user-assigned identity maak je eerst de identity aan in de Azure Portal onder Managed Identities en wijs je deze vervolgens toe aan de gewenste resources. Na het inschakelen krijgt de resource automatisch een identity in Microsoft Entra ID die kan worden gebruikt voor authenticatie. Vervolgens ken je de benodigde RBAC-machtigingen toe aan de beheerde identiteit. Dit is cruciaal voor het implementeren van het least privilege principle: geef de identity alleen de minimale rechten die nodig zijn voor de specifieke taak. Voor toegang tot Key Vault gebruik je bijvoorbeeld de rol Key Vault Secrets User, voor Storage Account-toegang gebruik je Storage Blob Data Reader of Storage Blob Data Contributor, en voor SQL Database gebruik je de juiste database-level permissions. Na het configureren van de beheerde identiteit en RBAC-machtigingen, update je de applicatiecode om DefaultAzureCredential() te gebruiken in plaats van hardcoded connection strings of service principal secrets. DefaultAzureCredential is een credential provider die automatisch verschillende authenticatiemethoden probeert, waaronder beheerde identiteit, environment variables en Azure CLI credentials. Wanneer een beheerde identiteit beschikbaar is, wordt deze automatisch gebruikt zonder dat er code-wijzigingen nodig zijn. Verwijder vervolgens alle hardcoded credentials, connection strings en secrets uit code, configuratiebestanden en environment variables. Test de authenticatieflow grondig om te bevestigen dat de applicatie succesvol kan verbinden met Azure-services via de beheerde identiteit. Borg de configuratie door regelmatige monitoring en periodieke controles. Automatiseer een wekelijkse check met het script in dit artikel om te bevestigen dat beheerde identiteiten correct zijn geconfigureerd voor alle resources die deze nodig hebben, dat RBAC-machtigingen correct zijn toegekend volgens het least privilege principle, en dat er geen hardcoded credentials meer worden gebruikt. Koppel de monitoring aan het SOC-dashboard en definieer een escalatiepad voor wanneer beheerde identiteiten worden uitgeschakeld of wanneer RBAC-machtigingen worden gewijzigd. In incident response-plannen benoem je expliciet dat resources gebruik maken van beheerde identiteiten, zodat onderzoeksteams weten dat authenticatie wordt gelogd in Azure AD sign-in logs. Door deze operationele borging sluit het technische ontwerp volledig aan op governance-, risico- en complianceprocessen en blijft de organisatie aantoonbaar in controle over credential management.
- Begin met een grondige inventarisatie van alle Azure-resources die momenteel gebruik maken van hardcoded credentials. Gebruik het script 'managed-identities-configured.ps1' om automatisch alle App Services, Function Apps, Virtual Machines, Container Instances en andere resources te identificeren die ondersteuning bieden voor beheerde identiteiten. Documenteer per resource welke Azure-services worden gebruikt en welke credentials momenteel worden toegepast. Neem vooraf het change-nummer, het doel van de wijziging en het expliciete akkoord van de verantwoordelijke informatie-eigenaar op zodat iedere actie herleidbaar blijft in auditrapportages. Controleer welke baselinedocumenten van toepassing zijn, waaronder dit artikel, de BIO-maatregelen en de interne beleidsnotitie over credential management. Leg in het changeformulier vast dat deze configuratie onderdeel is van de Nederlandse Baseline voor Veilige Cloud en dat afwijkingen alleen via het CAB mogen worden goedgekeurd. Bepaal per resource of een system-assigned of user-assigned identity het meest geschikt is. Een system-assigned identity is ideaal wanneer een resource een dedicated identiteit nodig heeft die automatisch wordt verwijderd wanneer de resource wordt verwijderd. Een user-assigned identity is geschikt wanneer meerdere resources dezelfde identiteit moeten delen of wanneer de identiteit onafhankelijk van de resource moet bestaan. Schakel vervolgens de beheerde identiteit in via de Azure Portal, Azure CLI of PowerShell. Voor een system-assigned identity navigeer je naar de resource in de Azure Portal, ga je naar de Identity-sectie en schakel je System assigned in. Voor een user-assigned identity maak je eerst de identity aan in de Azure Portal onder Managed Identities en wijs je deze vervolgens toe aan de gewenste resources. Documenteer de keuze voor system-assigned versus user-assigned in het changeformulier, inclusief de rationale achter deze keuze. Na het inschakelen van de beheerde identiteit, ken je de benodigde RBAC-machtigingen toe volgens het least privilege principle. Dit is cruciaal: geef de identity alleen de minimale rechten die nodig zijn voor de specifieke taak. Voor toegang tot Key Vault gebruik je bijvoorbeeld de rol Key Vault Secrets User, voor Storage Account-toegang gebruik je Storage Blob Data Reader of Storage Blob Data Contributor afhankelijk van de benodigde operaties, en voor SQL Database gebruik je de juiste database-level permissions. Documenteer alle toegekende RBAC-machtigingen in het changeformulier en leg uit waarom elke machtiging nodig is. Update vervolgens de applicatiecode om DefaultAzureCredential() te gebruiken in plaats van hardcoded connection strings of service principal secrets. DefaultAzureCredential detecteert automatisch de beheerde identiteit wanneer deze beschikbaar is. Verwijder alle hardcoded credentials, connection strings en secrets uit code, configuratiebestanden en environment variables. Test de authenticatieflow grondig in een testomgeving voordat je wijzigingen doorvoert naar productie. Bevestig dat de applicatie succesvol kan verbinden met Azure-services via de beheerde identiteit en dat alle functionaliteit nog werkt zoals verwacht. Bevestig ten slotte dat de wijziging is opgeslagen door de configuratie te controleren in de Azure Portal, de succesvolle auditlog te controleren en een periodieke export van deze log te plannen naar het centrale SIEM zodat afwijkingen automatisch alerting veroorzaken. Noteer in het configuratieregister wie de actie heeft uitgevoerd, welk tijdstip gold, welke scripts of portalen zijn gebruikt en welke bewijslast is verzameld, inclusief ticketnummers en verwijzingen naar de repository waarin de scripts zijn beheerd. Koppel de wijziging aan het incident- en probleembeheerproces zodat afwijkingen snel kunnen worden onderzocht, stel meldingen in die het SOC waarschuwen zodra beheerde identiteiten worden uitgeschakeld of wanneer RBAC-machtigingen worden gewijzigd, en definieer een rollback-procedure voor het geval de wijziging ongewenste impact heeft. Informeer de servicedesk, het security operations center en de betrokken productteams dat beheerde identiteiten zijn geactiveerd, licht toe welke signalen op afwijking moeten worden gemeld en geef aan hoe ontwikkelaars hulp kunnen krijgen bij het migreren naar beheerde identiteiten. Rond af door de change te evalueren tijdens de eerstvolgende retrospective van het identity-team zodat verbeterpunten direct kunnen worden opgenomen en de documentatie in de deployment-map kan worden bijgewerkt. Leg afsluitend vast welke lessen zijn geleerd en koppel deze terug aan het bestuur.
Vereisten
Een succesvolle implementatie van beheerde identiteiten vereist een solide basis van beleid, processen en technische randvoorwaarden. Begin met een formeel vastgesteld credential management-beleid waarin staat dat alle Azure-resources die toegang nodig hebben tot andere Azure-services gebruik moeten maken van beheerde identiteiten in plaats van hardcoded credentials. Dit beleid moet expliciet beschrijven wanneer system-assigned identities worden gebruikt versus user-assigned identities, welke RBAC-machtigingen worden toegekend volgens het least privilege principle, en wie verantwoordelijk is voor het beheren van beheerde identiteiten. Minimaal twee beheerders hebben de rol Owner, Contributor of User Access Administrator op het subscription- of resource group-niveau zodat altijd een vervanger beschikbaar is tijdens vakantie, ziekte of crisisrespons. Op hun beheerwerkplekken staan de modules Az.Accounts, Az.ManagedServiceIdentity en Az.Resources klaar, inclusief moderne authenticatie en Just-In-Time-toegang via Privileged Identity Management.
Daarnaast moet het changeproces duidelijk beschrijven wie een nieuwe beheerde identiteit initieert, welke bewijsstukken nodig zijn (zoals een risicoanalyse, een overzicht van benodigde RBAC-machtigingen en goedkeuring van de informatie-eigenaar) en hoe de CISO-organisatie de configuratie bekrachtigt. Elke wijziging aan beheerde identiteiten bevat een Business Impact Assessment, een overzicht van getroffen resources en services, en een testplan. Servicedeskmedewerkers zijn getraind om te herkennen wanneer een probleem gerelateerd is aan beheerde identiteiten en weten hoe zij ontwikkelaars kunnen helpen bij authenticatieproblemen. Er is een actueel overzicht beschikbaar van alle beheerde identiteiten, inclusief hun type (system-assigned of user-assigned), de toegewezen resources, de RBAC-machtigingen en de eigenaar die verantwoordelijk is voor het onderhouden van de identiteit.
Vervolgens zijn technische randvoorwaarden nodig om de configuratie betrouwbaar uit te voeren. De Azure subscription moet toegang hebben tot Microsoft Entra ID en beheerde identiteiten moeten zijn ingeschakeld (dit is standaard het geval). Logging naar Microsoft Sentinel of een ander SIEM-platform is ingericht, inclusief diagnostische instellingen voor Azure AD sign-in logs zodat authenticatiepogingen van beheerde identiteiten worden gelogd. Er bestaat een netwerkpad naar management-endpoints zodat scripts vanuit het segment 'beheerwerkplek' verbinding kunnen maken zonder dat er openstaande VPN's of persoonlijke apparaten nodig zijn. Back-up en version control voor scripts in de map deployment en code/azure zijn geregeld via GitHub of Azure DevOps, zodat wijzigingen aantoonbaar kunnen worden gevolgd. Beheerders beschikken over een dedicated testtenant of sandbox waarin beheerde identiteiten eerst worden gevalideerd voordat productie wordt aangepast.
Tot slot is cultuur een randvoorwaarde: leidinggevenden en ontwikkelaars ondersteunen het principe dat hardcoded credentials niet acceptabel zijn en accepteren dat de migratie naar beheerde identiteiten tijd en inspanning kost. Zonder die steun kan een technisch team deze maatregel niet handhaven. Daarom hoort een besluit van het CIO-beraad of het informatiebeveiligingsberaad bij de documentatie, inclusief verwijzing naar de risicoanalyse. Neem de maatregel op in onboardingprogramma's voor nieuwe ontwikkelaars en beheerders zodat zij begrijpen waarom beheerde identiteiten worden gebruikt en hoe zij deze moeten implementeren. Alleen wanneer beleid, techniek, processen en cultuur op elkaar aansluiten, levert de implementatie van beheerde identiteiten de beoogde beveiligingsvoordelen op.
Als aanvullende borging is een jaarplanning nodig voor interne audits en security scans die specifiek kijken naar het gebruik van hardcoded credentials in code en configuratiebestanden. Plan ten minste eenmaal per jaar een control waarbij een security scanner of code review tool zoekt naar hardcoded credentials, connection strings en secrets in repositories. Documenteer bevindingen en verbeteracties, en koppel deze aan de roadmap van het identity-team. Deze terugkerende toetsing zorgt ervoor dat randvoorwaarden actueel blijven, zelfs wanneer nieuwe applicaties of services worden ingevoerd.
Monitoring
Gebruik PowerShell-script managed-identities-configured.ps1 (functie Invoke-Monitoring) – Voer het script uit vanaf een beheerde werkplek of Azure Automation-account zodat beheerde identiteiten regelmatig worden gecontroleerd en afwijkingen automatisch worden gelogd in het SOC-platform..
Monitoring van beheerde identiteiten is essentieel om te waarborgen dat alle resources die toegang nodig hebben tot Azure-services gebruik maken van beheerde identiteiten en dat er geen hardcoded credentials meer worden gebruikt. Start met het script 'managed-identities-configured.ps1' uit de map code/azure/identity-access en koppel dit via een geautomatiseerde taak aan een beveiligde beheerwerkplek of Azure Automation-account. Het script inventariseert alle Azure-resources die ondersteuning bieden voor beheerde identiteiten, controleert of deze zijn ingeschakeld, verifieert dat RBAC-machtigingen correct zijn toegekend volgens het least privilege principle, en zoekt naar indicatoren van hardcoded credentials in configuratiebestanden en environment variables. Registreer de status in een logbestand en stuur een melding naar het SOC-dashboard zodra een resource zonder beheerde identiteit wordt gedetecteerd of wanneer RBAC-machtigingen worden gewijzigd. Breid de monitoring uit met Azure Monitor-workbooks waarin je het gebruik van beheerde identiteiten visualiseert: hoeveel resources gebruiken system-assigned identities, hoeveel gebruiken user-assigned identities, welke services worden het meest gebruikt voor authenticatie, en zijn er trends in het gebruik van beheerde identiteiten over tijd? Gebruik Azure AD sign-in logs om te analyseren wanneer en hoe beheerde identiteiten worden gebruikt voor authenticatie. Stel alerts in die waarschuwen wanneer een beheerde identiteit wordt uitgeschakeld, wanneer RBAC-machtigingen worden gewijzigd, of wanneer er authenticatiefouten optreden. Koppel deze alerts aan het ITSM-systeem zodat tickets automatisch worden aangemaakt voor onderzoek en remediatie. Combineer de technische metingen met security scans: gebruik tools zoals GitHub Advanced Security, Azure DevOps Security Scanners of externe tools zoals GitGuardian om te scannen naar hardcoded credentials in code repositories. Configureer deze scans om automatisch te draaien bij elke commit en stel alerts in die waarschuwen wanneer credentials worden gedetecteerd. Rapporteer de resultaten aan het informatiebeveiligingsberaad zodat zij kunnen beoordelen of er trendmatig afwijkingen optreden. Documenteer tenslotte ieder incident, zelfs als het vals alarm blijkt te zijn, zodat auditors kunnen zien dat de controlemiddelen actief worden beheerd. Monitoring gaat ook over compliance: documenteer in het auditdossier welke meetpunten worden bewaakt, hoe lang logbestanden worden bewaard (minimaal zeven jaar voor rijksorganisaties) en hoe de betrouwbaarheid van de scripts wordt gecontroleerd. Laat minimaal eenmaal per jaar een onafhankelijk team het monitoringsscript reviewen en uitvoeren in een kale beheerimage, zodat duidelijk is dat er geen verborgen afhankelijkheden zijn. Op die manier blijft monitoring een aantoonbaar effectief onderdeel van de Nederlandse Baseline voor Veilige Cloud.
Implementatie
Gebruik PowerShell-script managed-identities-configured.ps1 (functie Invoke-Implementation) – Automatiseren via script.
Begin met een grondige inventarisatie van alle Azure-resources die momenteel gebruik maken van hardcoded credentials. Gebruik het script 'managed-identities-configured.ps1' om automatisch alle App Services, Function Apps, Virtual Machines, Container Instances en andere resources te identificeren die ondersteuning bieden voor beheerde identiteiten. Documenteer per resource welke Azure-services worden gebruikt en welke credentials momenteel worden toegepast. Neem vooraf het change-nummer, het doel van de wijziging en het expliciete akkoord van de verantwoordelijke informatie-eigenaar op zodat iedere actie herleidbaar blijft in auditrapportages. Controleer welke baselinedocumenten van toepassing zijn, waaronder dit artikel, de BIO-maatregelen en de interne beleidsnotitie over credential management. Leg in het changeformulier vast dat deze configuratie onderdeel is van de Nederlandse Baseline voor Veilige Cloud en dat afwijkingen alleen via het CAB mogen worden goedgekeurd.
Bepaal per resource of een system-assigned of user-assigned identity het meest geschikt is. Een system-assigned identity is ideaal wanneer een resource een dedicated identiteit nodig heeft die automatisch wordt verwijderd wanneer de resource wordt verwijderd. Een user-assigned identity is geschikt wanneer meerdere resources dezelfde identiteit moeten delen of wanneer de identiteit onafhankelijk van de resource moet bestaan. Schakel vervolgens de beheerde identiteit in via de Azure Portal, Azure CLI of PowerShell. Voor een system-assigned identity navigeer je naar de resource in de Azure Portal, ga je naar de Identity-sectie en schakel je System assigned in. Voor een user-assigned identity maak je eerst de identity aan in de Azure Portal onder Managed Identities en wijs je deze vervolgens toe aan de gewenste resources. Documenteer de keuze voor system-assigned versus user-assigned in het changeformulier, inclusief de rationale achter deze keuze.
Na het inschakelen van de beheerde identiteit, ken je de benodigde RBAC-machtigingen toe volgens het least privilege principle. Dit is cruciaal: geef de identity alleen de minimale rechten die nodig zijn voor de specifieke taak. Voor toegang tot Key Vault gebruik je bijvoorbeeld de rol Key Vault Secrets User, voor Storage Account-toegang gebruik je Storage Blob Data Reader of Storage Blob Data Contributor afhankelijk van de benodigde operaties, en voor SQL Database gebruik je de juiste database-level permissions. Documenteer alle toegekende RBAC-machtigingen in het changeformulier en leg uit waarom elke machtiging nodig is. Update vervolgens de applicatiecode om DefaultAzureCredential() te gebruiken in plaats van hardcoded connection strings of service principal secrets. DefaultAzureCredential detecteert automatisch de beheerde identiteit wanneer deze beschikbaar is.
Verwijder alle hardcoded credentials, connection strings en secrets uit code, configuratiebestanden en environment variables. Test de authenticatieflow grondig in een testomgeving voordat je wijzigingen doorvoert naar productie. Bevestig dat de applicatie succesvol kan verbinden met Azure-services via de beheerde identiteit en dat alle functionaliteit nog werkt zoals verwacht. Bevestig ten slotte dat de wijziging is opgeslagen door de configuratie te controleren in de Azure Portal, de succesvolle auditlog te controleren en een periodieke export van deze log te plannen naar het centrale SIEM zodat afwijkingen automatisch alerting veroorzaken. Noteer in het configuratieregister wie de actie heeft uitgevoerd, welk tijdstip gold, welke scripts of portalen zijn gebruikt en welke bewijslast is verzameld, inclusief ticketnummers en verwijzingen naar de repository waarin de scripts zijn beheerd. Koppel de wijziging aan het incident- en probleembeheerproces zodat afwijkingen snel kunnen worden onderzocht, stel meldingen in die het SOC waarschuwen zodra beheerde identiteiten worden uitgeschakeld of wanneer RBAC-machtigingen worden gewijzigd, en definieer een rollback-procedure voor het geval de wijziging ongewenste impact heeft. Informeer de servicedesk, het security operations center en de betrokken productteams dat beheerde identiteiten zijn geactiveerd, licht toe welke signalen op afwijking moeten worden gemeld en geef aan hoe ontwikkelaars hulp kunnen krijgen bij het migreren naar beheerde identiteiten. Rond af door de change te evalueren tijdens de eerstvolgende retrospective van het identity-team zodat verbeterpunten direct kunnen worden opgenomen en de documentatie in de deployment-map kan worden bijgewerkt. Leg afsluitend vast welke lessen zijn geleerd en koppel deze terug aan het bestuur.
Compliance en Auditing
CIS Azure Foundations Benchmark Control 7.7 verplicht organisaties om beheerde identiteiten te gebruiken voor alle Azure-resources die toegang nodig hebben tot andere Azure-services. In het compliance-dossier beschrijf je hoe beheerde identiteiten zijn geconfigureerd voor alle relevante resources, hoe het monitoringsscript elke nacht de configuratie controleert en hoe afwijkingen binnen 24 uur worden geanalyseerd en teruggedraaid. Voeg een stappenplan toe waarin staat dat de control owner na iedere wijziging een ticket aanmaakt, een forensische notitie schrijft en de status deelt met het informatiebeveiligingsberaad. Leg de koppeling met de actuele CIS Azure Benchmark vast, inclusief versienummer, publicatiedatum en verwijzing naar het acceptatiebesluit binnen de Nederlandse Baseline voor Veilige Cloud. Documenteer ook welke metriek elke maand wordt gemeten (aantal resources met beheerde identiteiten, aantal hardcoded credentials gedetecteerd, gemiddelde tijd tot remediatie) en hoe die cijfers worden opgenomen in het risicoregister. Licht ten slotte toe hoe lessons learned worden opgevolgd, hoe de control wordt getest tijdens interne audits en welke evidence beschikbaar is voor een externe assessor zodat helder is dat het proces structureel volwassen is. Beschrijf hoe de control samenhangt met andere CIS-eisen, zoals privileged access management en logging, zodat een auditor de volledige keten kan volgen. Sluit af met een verwijzing naar de plek in het SIEM-dashboard waar realtime resultaten zichtbaar zijn.
BIO-maatregel 12.02 verlangt dat organisaties passende technische en organisatorische maatregelen nemen om informatie te beschermen, inclusief het veilig beheren van credentials. Licht in de documentatie toe dat beheerde identiteiten het gebruik van hardcoded credentials volledig elimineren, dat alle authenticatiepogingen worden gelogd in Azure AD sign-in logs, en dat RBAC-machtigingen worden toegekend volgens het least privilege principle. Leg uit hoe het securityteam elk kwartaal steekproeven uitvoert waarbij zij controleren of resources inderdaad gebruik maken van beheerde identiteiten en of er geen hardcoded credentials worden gebruikt. Beschrijf de KPI's die worden gevolgd, zoals 'percentage resources met beheerde identiteiten' en 'aantal hardcoded credentials gedetecteerd', en hoe deze KPI's richting bestuur worden gerapporteerd. Benoem bovendien dat de control onderdeel is van de BIO-volwassenheidsmeting, dat de Functionaris Gegevensbescherming meekijkt bij uitzonderingen en dat verbeteracties worden vastgelegd in het roadmapdocument voor de Nederlandse Baseline voor Veilige Cloud. Geef inzicht in de escalatieprocedure wanneer KPI's rood kleuren, hoe lessons learned worden vertaald naar aanvullende maatregelen zoals training of tooling en op welke manier resultaten worden gedeeld met ketenpartners.
ISO 27001 controle A.9.2.1 verlangt dat gebruikers alleen toegang krijgen tot systemen en services waarvoor zij zijn geautoriseerd. Beschrijf hoe beheerde identiteiten in combinatie met Azure RBAC ervoor zorgen dat resources alleen toegang krijgen tot services waarvoor zij expliciet zijn geautoriseerd, en hoe dit wordt onderbouwd met logbestanden, testresultaten en managementrapportages. Koppel de maatregel aan het Statement of Applicability, leg uit welke bewijsstukken beschikbaar zijn voor externe auditors, beschrijf welke retentie-eisen gelden, hoe de control is gekoppeld aan het privacy impact assessment en hoe afwijkingen worden gevolgd via corrigerende maatregelen. Benoem welke teams verantwoordelijk zijn voor het onderhouden van de documentatie, hoe vaak de effectiviteitstoets wordt uitgevoerd en welke escalaties gelden wanneer de control niet werkt. Werk uit hoe de control aansluit op verbetercyclus Plan-Do-Check-Act, hoe uitkomsten worden gedeeld met leveranciers die namens de organisatie beheer uitvoeren en hoe herstelacties worden vastgelegd in het register van corrigerende maatregelen.
Remediatie
Gebruik PowerShell-script managed-identities-configured.ps1 (functie Invoke-Remediation) – Het PowerShell-script managed-identities-configured.ps1 wordt ingezet zodra monitoring aangeeft dat een resource geen beheerde identiteit heeft geconfigureerd of wanneer hardcoded credentials worden gedetecteerd. Start met het uitvoeren van het script vanaf een beheerde werkplek waarop de Az.Accounts, Az.ManagedServiceIdentity en Az.Resources modules up-to-date aanwezig zijn en waarop multi-factor-authenticatie verplicht is. Het script maakt een verbouwing van de configuratie inzichtelijk door eerst alle resources te inventariseren die ondersteuning bieden voor beheerde identiteiten, deze te loggen in een forensisch bestand en vervolgens beheerde identiteiten in te schakelen voor resources die deze nog niet hebben. De operator kiest het change-nummer waarmee de actie wordt verbonden en geeft aan welke tenant, welk scenario en welke verantwoordelijke informatie-eigenaar betrokken zijn. Hierdoor is elke remediering herleidbaar en voldoet de organisatie aan de eisen van de Nederlandse Baseline voor Veilige Cloud.
Vooraf voert de operator een dry-run uit, zodat duidelijk wordt welke resources beheerde identiteiten zullen krijgen en welke RBAC-machtigingen zullen worden toegekend. Pas wanneer de preview geen fouten oplevert, wordt de daadwerkelijke write-actie uitgevoerd. Het script controleert na afloop automatisch of de wijziging correct is verwerkt door de configuratie nogmaals uit te lezen en te vergelijken met het gewenste profiel. Wanneer de status nog niet overeenkomt, wordt er een foutmelding gelogd en wordt de operator gevraagd om contact op te nemen met het SOC zodat zij kunnen beoordelen of er sprake is van een gelijktijdige wijziging door een andere beheerder.
Na een succesvolle remediering genereert het script een kort rapport waarin de oude configuratie, de nieuwe configuratie, het tijdstip en de accountnaam zijn opgenomen. Dit rapport wordt opgeslagen in de map deployment/evidence zodat auditors het later kunnen terugvinden. Het script kan optioneel een notificatie sturen naar Microsoft Teams of e-mail zodat het change- en incidentteam direct wordt geïnformeerd. Wanneer de wijziging onderdeel is van een breder incident, kan het rapport worden toegevoegd aan het post-incidentreviewdocument zodat duidelijk is welke technische maatregelen zijn genomen.
Omdat beheerde identiteiten direct impact hebben op applicatiefunctionaliteit, bevat het script ook een communicatiestap. Na bevestiging dat beheerde identiteiten zijn geactiveerd, toont het script een overzicht met aanbevolen berichten voor ontwikkelaars en beheerders zodat zij weten dat applicaties moeten worden bijgewerkt om DefaultAzureCredential() te gebruiken. Hierdoor voorkom je dat applicaties onverwacht falen wanneer hardcoded credentials worden verwijderd. Tot slot logt het script hoeveel tijd er zat tussen detectie en herstel, zodat je de mean time to remediate kunt rapporteren als KPI richting bestuurders en toezichthouders.
Om herhaling te voorkomen bevat het script een evaluatiemodule: de operator geeft de oorzaak van de afwijking op (bijvoorbeeld nieuwe resource zonder beheerde identiteit, foutieve configuratie of kwaadwillende actie) en koppelt die oorzaak automatisch aan het risicoregister. Wanneer dezelfde oorzaak vaker terugkomt, genereert het script een advies om aanvullende maatregelen te nemen, zoals strengere change approval of extra training. Bij iedere run worden de gebruikte PowerShell-versies en moduleversies vastgelegd zodat later kan worden aangetoond dat de tooling up-to-date was.
Het script biedt ook een rollback-functie. Als blijkt dat de wijziging onbedoelde impact heeft, kan de operator met een enkele parameter de beheerde identiteit uitschakelen terwijl tegelijkertijd een ticket wordt aangemaakt voor nadere analyse. Hierdoor blijft de beschikbaarheid van cruciale applicaties gewaarborgd. Tenslotte wordt een checksum van de scriptversie vergeleken met de broncode in de repository, zodat zeker is dat er niet met een onbeheerde kopie wordt gewerkt. Op deze manier is remediatie niet alleen een technische handeling, maar een volledig gecontroleerd proces dat governance, communicatie en bewijsvoering combineert..
Compliance & Frameworks
- CIS M365: Control 7.7 (L1) - Ensure that Virtual Machines use managed identities
- BIO: 12.02 - Beveiligingsmaatregelen voor informatiebeveiliging
- ISO 27001:2022: A.9.2.1 - Toegangscontrole en authenticatie
Automation
Gebruik het onderstaande PowerShell script om deze security control te monitoren en te implementeren. Het script bevat functies voor zowel monitoring (-Monitoring) als remediation (-Remediation).
Risico zonder implementatie
Management Samenvatting
Beheerde identiteiten: schakel in voor alle Azure-resources die toegang nodig hebben tot Azure-services, ken RBAC-machtigingen toe volgens least privilege, update code om DefaultAzureCredential() te gebruiken, verwijder hardcoded credentials, en valideer wekelijks met het script managed-identities-configured.ps1 zodat credential management structureel wordt beheerd.
- Implementatietijd: 12 uur
- FTE required: 0.1 FTE