Azure App Service: Managed Identity Inschakelen Voor Authenticatie

Hardcoded credentials in applicatiecode en configuratiebestanden zijn de nummer één oorzaak van beveiligingslekken en data breaches in cloud-omgevingen. Deze aanpak brengt aanzienlijke risico's met zich mee: secrets worden opgeslagen in code of configuratiebestanden die vaak in version control systems zoals Git terechtkomen, credentials worden gecommit naar GitHub of andere repositories waar ze publiek of voor insiders toegankelijk worden, credential rotation wordt een nachtmerrie omdat secrets op meerdere plekken moeten worden bijgewerkt, gelekte credentials in logbestanden of error messages geven aanvallers direct toegang, en er is geen centraal audittrail van hoe en wanneer credentials worden gebruikt. Onderzoek toont aan dat meer dan 60% van alle data breaches het gevolg is van gestolen of gelekte credentials. Managed Identity elimineert 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, automatische token refresh plaatsvindt zonder developer intervention waardoor applicaties altijd valide credentials hebben, naadloze integratie met Azure RBAC mogelijk is voor fine-grained authorization, een complete audittrail beschikbaar is via Azure AD sign-in logs die precies registreert wanneer de Managed Identity wordt gebruikt, en credential rotation volledig geautomatiseerd is zonder downtime of code-wijzigingen. Voor organisaties die voldoen aan compliance-frameworks zoals ISO 27001, NIS2 of de AVG is Managed Identity vaak een vereiste om aan te tonen dat credentials veilig worden beheerd zonder risico op lekkage.

Implementatie

Deze maatregel implementeert Managed Identity voor Azure App Services en Function Apps, waarbij voor elke App Service een System-Assigned of User-Assigned Managed Identity wordt ingeschakeld. Een System-Assigned identity is gekoppeld aan de levenscyclus van de App Service en wordt automatisch verwijderd wanneer de App Service wordt verwijderd, terwijl een User-Assigned identity onafhankelijk bestaat en aan meerdere resources kan worden toegekend. Na het inschakelen krijgt de App Service automatisch een identity in Microsoft Entra ID die kan worden gebruikt voor authenticatie bij andere Azure-services. De implementatie omvat het inschakelen van de Managed Identity via de Azure Portal onder Identity settings of via PowerShell voor geautomatiseerde deployment, het toekennen van de benodigde RBAC-machtigingen aan de identity (bijvoorbeeld Key Vault Secrets User voor toegang tot Key Vault, Storage Blob Data Reader voor Storage Account-toegang, of specifieke SQL Database-permissions), het updaten van applicatiecode om DefaultAzureCredential() te gebruiken in plaats van hardcoded connection strings (deze credential provider detecteert automatisch de Managed Identity), het verwijderen van alle hardcoded credentials, connection strings en secrets uit code, configuratiebestanden en environment variables, en het testen van de authenticatieflow om te bevestigen dat de applicatie succesvol kan verbinden met Azure-services via de Managed Identity. Veelvoorkomende gebruik scenarios zijn toegang tot Azure Key Vault om applicatiesecrets op te halen, toegang tot Azure Storage Accounts voor blob- of file-operaties, SQL Database-authenticatie zonder connection strings met wachtwoorden, en het aanroepen van andere Azure-services zoals Service Bus, Event Hubs of Cognitive Services. Deze implementatie vereist geen extra kosten, is binnen 3-4 uur implementeerbaar inclusief code-wijzigingen, en is een non-negotiable beveiligingscontrole voor alle productie-applicaties.

Implementatie

De implementatie van Managed Identity voor Azure App Service bestaat uit vier hoofdfasen die systematisch doorlopen moeten worden om een volledig beveiligde, zero-secrets architectuur te realiseren. Elke fase bouwt voort op de vorige en vereist zorgvuldige aandacht voor detail om ervoor te zorgen dat de authenticatie naadloos werkt zonder hardcoded credentials.

**FASE 1: System-Assigned Managed Identity Inschakelen** De eerste fase van de implementatie richt zich op het activeren van een System-Assigned Managed Identity voor de App Service. Deze fase duurt gemiddeld tien minuten per App Service en vormt de basis voor alle verdere configuratie. Het proces begint in de Azure Portal waar u navigeert naar de sectie App Services en de specifieke App Service selecteert waarvoor u Managed Identity wilt inschakelen. In het linker navigatiemenu onder de categorie Settings vindt u de optie 'Identity', die u moet selecteren om toegang te krijgen tot de identity-configuratie-instellingen. Onder het tabblad 'System assigned' ziet u een status-schakelaar die standaard op 'Off' staat. Door deze schakelaar op 'On' te zetten, wordt het proces gestart om een Azure AD-identiteit aan te maken. Azure toont een waarschuwing die u informeert dat er een Azure AD-identiteit wordt aangemaakt en vraagt om bevestiging. Deze bevestiging is belangrijk omdat de identiteit permanent wordt gekoppeld aan de App Service en niet eenvoudig ongedaan kan worden gemaakt zonder de App Service te verwijderen. Na het klikken op 'Save' start Azure het proces om automatisch een Service Principal aan te maken in Microsoft Entra ID (voorheen Azure Active Directory). Deze Service Principal krijgt dezelfde naam als de App Service en wordt direct gekoppeld aan de levenscyclus van de App Service. Het aanmaken van de Service Principal duurt doorgaans tussen de tien en dertig seconden, afhankelijk van de belasting van het Azure-platform. Zodra het proces is voltooid, verschijnt er een Object (principal) ID in de interface. Deze unieke identifier is cruciaal voor alle verdere configuratiestappen, met name voor het toewijzen van RBAC-machtigingen op andere Azure-resources. Noteer deze ID zorgvuldig, want u heeft deze nodig bij het configureren van toegangsrechten. Een belangrijk aandachtspunt bij System-Assigned Managed Identity is dat deze automatisch wordt verwijderd wanneer de App Service wordt verwijderd. Dit gedrag is ideaal voor applicaties die een unieke identiteit nodig hebben die volledig gekoppeld is aan de levenscyclus van de App Service. Voor scenario's waarbij meerdere App Services dezelfde identiteit moeten delen, of wanneer u een identiteit nodig heeft die onafhankelijk van de App Service bestaat, moet u overwegen om een User-Assigned Managed Identity te gebruiken. Deze optie biedt meer flexibiliteit maar vereist een extra configuratiestap waarbij u eerst de User-Assigned Managed Identity als standalone resource aanmaakt voordat u deze toewijst aan de App Service.

**FASE 2: RBAC-machtigingen Toewijzen op Doel-Azure-resources** De tweede fase van de implementatie omvat het toewijzen van de juiste RBAC-machtigingen aan de Managed Identity op alle Azure-resources die de App Service moet kunnen benaderen. Deze fase is kritiek voor de functionaliteit van de applicatie en duurt gemiddeld vijftien tot dertig minuten, afhankelijk van het aantal resources dat geconfigureerd moet worden. Het principe van least privilege moet hierbij strikt worden toegepast, wat betekent dat u alleen de minimale machtigingen toekent die de applicatie daadwerkelijk nodig heeft om te functioneren. Voor toegang tot Azure Key Vault zijn er twee verschillende toegangsmodellen beschikbaar. Het moderne RBAC-model (aanbevolen) gebruikt rolgebaseerde toegangscontrole via de Access Control (IAM) sectie van de Key Vault. Navigeer naar de Key Vault-resource, selecteer Access Control (IAM) in het linker menu, en klik op 'Add role assignment'. Selecteer de rol 'Key Vault Secrets User' voor alleen-lezen toegang tot secrets, of 'Key Vault Secrets Officer' voor schrijftoegang. In het veld Members zoekt u naar de naam van de App Service en selecteert u deze. Het legacy Access Policy-model werkt anders: navigeer naar Access policies onder Settings, klik op 'Add Access Policy', configureer de Secret permissions (bijvoorbeeld Get en List), en wijs de App Service toe in het veld Assign. Hoewel beide modellen werken, is het RBAC-model de aanbevolen aanpak omdat het beter integreert met Azure's centrale toegangsbeheer. Voor Azure Storage Account-toegang volgt u een vergelijkbaar patroon via Access Control (IAM). Navigeer naar het Storage Account, selecteer Access Control (IAM), en klik op 'Add role assignment'. De keuze van de rol hangt af van de benodigde functionaliteit: 'Storage Blob Data Reader' voor alleen-lezen toegang tot blobs, 'Storage Blob Data Contributor' voor lezen en schrijven van blobs, of 'Storage Queue Data Contributor' voor toegang tot queues. Zoek in het veld Members naar de naam van de App Service en wijs de rol toe. Het is belangrijk om te realiseren dat Storage Account-toegang via Managed Identity veel veiliger is dan het gebruik van Storage Account Keys, omdat deze keys volledige toegang geven tot het hele Storage Account, terwijl RBAC-rollen specifieke, beperkte machtigingen kunnen verlenen. Azure SQL Database-toegang via Managed Identity vereist een extra configuratiestap omdat SQL Database een specifiek authenticatiemodel gebruikt. Eerst moet de Azure Active Directory-beheerder worden geconfigureerd op het SQL Server-niveau. Dit is een eenmalige configuratie die vereist dat u een Azure AD-gebruiker of -groep aanwijst als beheerder. Zodra dit is gebeurd, kunt u verbinding maken met de SQL Database via SQL Server Management Studio (SSMS) of Azure Data Studio, waarbij u zich aanmeldt als de Azure AD-beheerder. Voer vervolgens SQL-commando's uit om de Managed Identity toe te voegen als databasegebruiker. Het commando CREATE USER [app-service-name] FROM EXTERNAL PROVIDER; maakt de gebruiker aan, waarna u met ALTER ROLE db_datareader ADD MEMBER [app-service-name]; alleen-lezen toegang verleent, of met ALTER ROLE db_datawriter ADD MEMBER [app-service-name]; schrijftoegang verleent. Deze aanpak elimineert de noodzaak voor SQL-aanmeldgegevens en connection strings met ingebedde wachtwoorden. Voor andere Azure-services zoals Service Bus, Event Hubs, Cognitive Services, of API Management volgt u hetzelfde RBAC-patroon. Navigeer naar de doelresource, open Access Control (IAM), voeg een roltoewijzing toe, selecteer de juiste rol gebaseerd op het principe van least privilege, en wijs de App Service Managed Identity toe. Het is cruciaal om bij elke roltoewijzing te evalueren welke specifieke acties de applicatie moet kunnen uitvoeren. Geef bijvoorbeeld alleen-lezen toegang als de applicatie alleen data hoeft te lezen, verleen toegang tot specifieke Key Vault-secrets in plaats van alle secrets, en scope machtigingen op resource group-niveau in plaats van subscription-breed waar mogelijk. Deze aanpak minimaliseert het aanvalsoppervlak en volgt security best practices zoals beschreven in frameworks zoals NIST en CIS.

**FASE 3: Applicatiecode Bijwerken voor Managed Identity** De derde fase omvat het bijwerken van de applicatiecode om gebruik te maken van Managed Identity in plaats van hardcoded credentials. Deze fase is de meest tijdrovende en duurt gemiddeld één tot twee uur, afhankelijk van de complexiteit van de applicatie en het aantal plaatsen waar credentials worden gebruikt. De exacte implementatie verschilt per programmeertaal, maar alle moderne Azure SDK's ondersteunen de DefaultAzureCredential-klasse die automatisch Managed Identity detecteert en gebruikt wanneer deze beschikbaar is. Voor .NET-applicaties installeert u eerst het NuGet-pakket 'Azure.Identity' via de package manager of via de command line met dotnet add package Azure.Identity. Vervolgens werkt u de code bij om DefaultAzureCredential te gebruiken in plaats van connection strings of wachtwoorden. Voor Key Vault-toegang maakt u een nieuwe instantie van DefaultAzureCredential aan en gebruikt u deze om een SecretClient te initialiseren. De code ziet er als volgt uit: var credential = new DefaultAzureCredential(); var client = new SecretClient(new Uri(keyVaultUrl), credential); KeyVaultSecret secret = await client.GetSecretAsync(secretName);. Voor SQL Database-toegang gebruikt u dezelfde credential om een toegangstoken op te halen dat u kunt gebruiken voor SQL-authenticatie. Maak een SqlConnection aan met een connection string die alleen de server en database bevat (zonder wachtwoord), en stel vervolgens de AccessToken-eigenschap in met een token dat u ophaalt via credential.GetTokenAsync met het juiste scope voor SQL Database: var connection = new SqlConnection(connectionString); connection.AccessToken = await credential.GetTokenAsync(new TokenRequestContext(new[] { "https://database.windows.net/.default" }));. Node.js-applicaties gebruiken het npm-pakket '@azure/identity' dat u installeert via npm install @azure/identity. De implementatie volgt een vergelijkbaar patroon waarbij u DefaultAzureCredential importeert en gebruikt om Azure-serviceclients te authenticeren. Voor Key Vault-toegang ziet de code er als volgt uit: const { DefaultAzureCredential } = require('@azure/identity'); const { SecretClient } = require('@azure/keyvault-secrets'); const credential = new DefaultAzureCredential(); const client = new SecretClient(vaultUrl, credential); const secret = await client.getSecret(secretName);. De DefaultAzureCredential-klasse werkt identiek aan de .NET-versie en detecteert automatisch de beschikbare authenticatiemethoden. Python-applicaties gebruiken het pip-pakket 'azure-identity' dat u installeert via pip install azure-identity. De code-structuur is vergelijkbaar met de andere talen: from azure.identity import DefaultAzureCredential; from azure.keyvault.secrets import SecretClient; credential = DefaultAzureCredential(); client = SecretClient(vault_url=vault_url, credential=credential); secret = client.get_secret(secret_name);. Python-ontwikkelaars moeten ervoor zorgen dat ze de nieuwste versie van de Azure SDK gebruiken om volledige ondersteuning voor Managed Identity te garanderen. Java-applicaties gebruiken de Azure SDK for Java die u toevoegt aan uw project via Maven of Gradle. De implementatie gebruikt de DefaultAzureCredentialBuilder om een credential-object te maken: DefaultAzureCredential credential = new DefaultAzureCredentialBuilder().build(); SecretClient client = new SecretClientBuilder().vaultUrl(vaultUrl).credential(credential).buildClient(); KeyVaultSecret secret = client.getSecret(secretName);. Java-ontwikkelaars moeten ervoor zorgen dat alle benodigde Azure SDK-afhankelijkheden correct zijn geconfigureerd in het build-bestand. Een cruciaal voordeel van DefaultAzureCredential is dat deze automatisch meerdere authenticatiemethoden probeert in een vaste volgorde. In productieomgevingen waar Managed Identity beschikbaar is, wordt deze automatisch gebruikt. Voor lokale ontwikkeling probeert de credential provider eerst Azure CLI-credentials als u bent ingelogd via az login, daarna Visual Studio-credentials als u Visual Studio gebruikt, en ten slotte environment variables als fallback. Deze flexibiliteit maakt het mogelijk om dezelfde code te gebruiken in zowel ontwikkel- als productieomgevingen zonder wijzigingen, wat de ontwikkelervaring aanzienlijk verbetert en het risico op configuratiefouten vermindert.

**FASE 4: Hardcoded Credentials Verwijderen en Valideren** De vierde en laatste fase van de implementatie richt zich op het volledig verwijderen van alle hardcoded credentials uit de codebase en het valideren dat er geen secrets meer aanwezig zijn. Deze fase is essentieel voor het bereiken van een echte zero-secrets architectuur en duurt gemiddeld één uur. Het proces begint met een grondige scan van de codebase om alle plaatsen te identificeren waar credentials mogelijk zijn opgeslagen. Voer een uitgebreide zoekactie uit in alle code- en configuratiebestanden naar patronen die wijzen op hardcoded credentials. Zoek naar termen zoals 'ConnectionString', 'Password=', 'AccountKey=', 'SharedAccessSignature', en 'DefaultEndpointsProtocol'. Deze termen komen vaak voor in connection strings en configuratiebestanden waar credentials zijn ingebed. Controleer niet alleen de broncode, maar ook configuratiebestanden zoals appsettings.json, web.config, environment variables, en deployment-scripts. Het is belangrijk om te realiseren dat credentials op veel verschillende plaatsen kunnen voorkomen, waaronder comments in code, testbestanden, en zelfs in documentatie. Verwijder alle connection strings uit de App Service Configuration in de Azure Portal. Navigeer naar de App Service, selecteer Configuration onder Settings, en verwijder alle connection strings die embedded passwords bevatten. Als secrets nog steeds nodig zijn voor de applicatie (bijvoorbeeld voor externe services die geen Managed Identity ondersteunen), vervang deze dan door Key Vault-references. Deze references gebruiken de syntaxis @Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/mysecret/) en zorgen ervoor dat secrets veilig worden opgehaald uit Key Vault zonder dat ze in plaintext in de configuratie staan. De App Service heeft automatisch toegang tot Key Vault wanneer Managed Identity is ingeschakeld en de juiste RBAC-machtigingen zijn toegewezen. Update de applicatieconfiguratie om alleen endpoints te bevatten zonder credentials. In plaats van volledige connection strings met wachtwoorden, bevat de configuratie nu alleen de benodigde URLs en servernamen. Voor Key Vault is dit de URL zoals https://myvault.vault.azure.net/, voor Storage Accounts is dit de blob endpoint zoals https://mystorage.blob.core.windows.net/, en voor SQL Database is dit alleen de servernaam zoals myserver.database.windows.net. Geen enkele configuratie bevat nog passwords, keys, of andere geheime informatie. Deze aanpak maakt het mogelijk om configuratiebestanden veilig te committen naar version control zonder risico op credential exposure. Voer een uitgebreide code-scan uit met gespecialiseerde tools om te verifiëren dat er geen credentials meer in de code staan. Tools zoals GitHub Secret Scanning, GitGuardian, of Trufflehog zijn specifiek ontworpen om secrets te detecteren in codebases. Deze tools gebruiken pattern matching, machine learning, en heuristieken om verschillende soorten credentials te identificeren, waaronder API keys, wachtwoorden, tokens, en connection strings. Configureer deze tools om regelmatig te scannen, bij voorkeur als onderdeel van de CI/CD-pipeline, zodat nieuwe credentials direct worden gedetecteerd voordat ze in de repository worden gecommit. Een belangrijk aandachtspunt is dat zelfs na het verwijderen van credentials uit de huidige code, deze nog steeds aanwezig kunnen zijn in de git-geschiedenis. Git bewaart een complete geschiedenis van alle commits, wat betekent dat oude commits nog steeds credentials kunnen bevatten. Voor kritieke secrets die mogelijk zijn gecommit, overweeg een git history rewrite met behulp van git filter-branch of de BFG Repo-Cleaner tool. Deze tools kunnen credentials uit de volledige git-geschiedenis verwijderen, hoewel dit proces complex is en vereist dat alle teamleden hun lokale repositories opnieuw clonen. Als alternatief, als een git history rewrite niet haalbaar is, roteer dan alle exposed credentials onmiddellijk en markeer de oude credentials als compromised in uw credential management systeem. Dit is een kritieke security-maatregel omdat aanvallers vaak git-geschiedenis scannen op gecommit credentials. De totale implementatietijd voor deze maatregel bedraagt drie tot vier uur per applicatie. Het inschakelen van Managed Identity neemt ongeveer tien minuten in beslag, de RBAC-configuratie duurt gemiddeld dertig minuten, code-updates vereisen één tot twee uur afhankelijk van de complexiteit, en testing en validatie nemen ongeveer één uur in beslag. Voor organisaties met meerdere applicaties is het belangrijk om te realiseren dat de eerste implementatie de langste duurt, omdat u tijdens dit proces de patronen en best practices leert. Volgende applicaties kunnen doorgaans in twee tot drie uur worden geïmplementeerd omdat u de geleerde patronen kunt hergebruiken. Wat betreft kosten is Managed Identity volledig gratis. Er zijn geen extra Azure-kosten voor identity management, token acquisition, of authentication. Het Azure-platform beheert alle aspecten van de Managed Identity zonder extra kosten, wat deze oplossing zeer kosteneffectief maakt. De totale kosten voor deze beveiligingsmaatregel bedragen nul euro, terwijl de beveiligingsvoordelen aanzienlijk zijn.

Compliance en Auditing

Managed Identity voor Azure App Service speelt een cruciale rol in het voldoen aan verschillende compliance-frameworks en beveiligingsstandaarden die relevant zijn voor Nederlandse overheidsorganisaties en bedrijven die werken met gevoelige gegevens. Deze maatregel adresseert specifieke controles uit meerdere frameworks en biedt de audit-evidence die nodig is om aan te tonen dat credentials veilig worden beheerd zonder risico op lekkage of misbruik.

**CIS Azure Benchmark - Identity Controls** De CIS Azure Benchmark bevat specifieke controles gericht op identity management en authenticatie. Managed Identity voor App Services adresseert direct meerdere identity-gerelateerde controles door te zorgen voor een zero-secrets architectuur waarbij geen credentials in code of configuratiebestanden worden opgeslagen. De CIS Azure Benchmark benadrukt het belang van het gebruik van managed identities in plaats van service principals met client secrets, omdat managed identities automatisch worden beheerd door het Azure-platform zonder dat er secrets hoeven te worden opgeslagen. Voor organisaties die voldoen aan de CIS Azure Benchmark is Managed Identity niet alleen een best practice, maar vaak een vereiste controle die moet worden geïmplementeerd om volledige compliance te bereiken. De audit-evidence voor CIS-compliance omvat het documenteren dat Managed Identity is ingeschakeld voor alle productie App Services, dat RBAC-machtigingen correct zijn geconfigureerd volgens het principe van least privilege, en dat er geen hardcoded credentials aanwezig zijn in de codebase.

**ISO 27001 - A.9.4.2 Secure Log-on Procedures** ISO 27001 controle A.9.4.2 vereist dat organisaties secure log-on procedures implementeren voor alle systemen en applicaties. Managed Identity voor Azure App Service voldoet aan deze vereiste door te zorgen voor cryptografisch veilige authenticatie zonder dat er wachtwoorden of secrets in plaintext worden opgeslagen. De controle A.9.4.2 specificeert dat authenticatie-informatie cryptografisch moet worden beveiligd en dat er mechanismen moeten zijn voor het beheren en roteren van credentials. Managed Identity adresseert beide aspecten: authenticatie gebeurt via Azure AD-tokens die cryptografisch worden beveiligd door het Azure-platform, en token-rotatie gebeurt automatisch elke 24 uur zonder enige interventie van de organisatie. Voor ISO 27001-audits moet u kunnen aantonen dat alle App Services gebruik maken van Managed Identity, dat er geen hardcoded credentials aanwezig zijn, en dat er een proces is voor het monitoren en auditen van identity-gebruik. Azure AD sign-in logs bieden de benodigde audit-trail die ISO 27001-auditors verwachten, inclusief informatie over wanneer identities worden gebruikt, welke resources worden benaderd, en of authenticatiepogingen succesvol waren.

**NIS2 - Artikel 21 Secure Authentication Mechanisms** De NIS2-richtlijn (Network and Information Systems Directive 2) is van toepassing op essentiële en belangrijke entiteiten in de Europese Unie, inclusief Nederlandse overheidsorganisaties en kritieke infrastructuren. Artikel 21 van NIS2 vereist dat organisaties secure authentication mechanisms implementeren voor alle systemen die toegang hebben tot gevoelige informatie of kritieke functies. Managed Identity voor Azure App Service voldoet aan deze vereiste door te zorgen voor sterke, cryptografisch beveiligde authenticatie zonder afhankelijkheid van wachtwoorden of secrets die kunnen worden gestolen of gelekt. NIS2 benadrukt het belang van defense in depth en het minimaliseren van het aanvalsoppervlak, wat perfect aansluit bij de zero-secrets architectuur die Managed Identity biedt. Voor NIS2-compliance moet u kunnen aantonen dat alle kritieke applicaties gebruik maken van secure authentication mechanisms zoals Managed Identity, dat er geen zwakke authenticatiemethoden worden gebruikt, en dat er monitoring en logging plaatsvindt van alle authenticatie-activiteiten. Azure AD sign-in logs en Azure Monitor bieden de benodigde logging-capaciteiten om te voldoen aan de NIS2-vereisten voor security monitoring en incident response.

**OWASP Top 10 - A07:2021 Identification and Authentication Failures** OWASP Top 10 voor 2021 classificeert Identification and Authentication Failures als een van de meest kritieke beveiligingsrisico's voor webapplicaties. Deze categorie omvat problemen zoals zwakke wachtwoorden, hardcoded credentials, onveilige credential storage, en het ontbreken van multi-factor authentication. Managed Identity voor Azure App Service adresseert direct meerdere aspecten van A07:2021 door te elimineren dat credentials in code of configuratiebestanden worden opgeslagen, door te zorgen voor sterke cryptografische authenticatie via Azure AD-tokens, en door automatische token-rotatie te implementeren zonder dat developers of operations teams hierbij betrokken hoeven te zijn. OWASP benadrukt dat hardcoded credentials een van de meest voorkomende en gevaarlijke beveiligingsfouten zijn, omdat deze credentials vaak in version control systems terechtkomen en publiekelijk toegankelijk worden. Managed Identity elimineert dit risico volledig door te zorgen dat er geen credentials zijn om te lekken. Voor OWASP-compliance en security assessments moet u kunnen aantonen dat alle applicaties gebruik maken van secure authentication mechanisms, dat er geen hardcoded credentials aanwezig zijn in de codebase, en dat er processen zijn voor het regelmatig scannen en valideren van de codebase op aanwezigheid van secrets. Tools zoals GitHub Secret Scanning, GitGuardian, en Trufflehog kunnen worden gebruikt om te verifiëren dat er geen credentials meer in de code staan, wat de audit-evidence levert die nodig is voor OWASP-compliance.

**Audit-Evidence en Documentatie** Voor alle compliance-frameworks is het belangrijk om voldoende audit-evidence te verzamelen en te documenteren. De benodigde evidence voor Managed Identity-implementatie omvat ten minste de volgende elementen: documentatie dat Managed Identity is ingeschakeld voor alle productie App Services (bijvoorbeeld via Azure Portal screenshots of PowerShell-script output), een overzicht van alle RBAC-roltoewijzingen die zijn gemaakt voor de Managed Identities (beschikbaar via Azure Portal IAM-sectie of via Azure CLI/PowerShell queries), resultaten van code-scans die aantonen dat er geen hardcoded credentials aanwezig zijn in de codebase (bijvoorbeeld output van GitHub Secret Scanning of GitGuardian), Azure AD sign-in logs die authenticatie-activiteiten documenteren (beschikbaar via Azure Portal of Azure Monitor), en een procesdocumentatie die beschrijft hoe Managed Identity wordt gebruikt en beheerd binnen de organisatie. Deze documentatie moet worden bewaard voor de vereiste retentieperiode, die voor veel compliance-frameworks minimaal zeven jaar bedraagt. Azure biedt verschillende tools voor het exporteren en archiveren van logs, waaronder Azure Monitor Log Analytics, Azure Storage Accounts voor langetermijnopslag, en Azure Archive Storage voor kosten-effectieve opslag van historische data. Het is belangrijk om deze logs regelmatig te exporteren en te archiveren om te voldoen aan compliance-vereisten voor data retention.

Monitoring

Gebruik PowerShell-script app-service-managed-identity-enabled.ps1 (functie Invoke-Monitoring) – Automatiseert monitoring van Managed Identity-configuratie en authenticatie-activiteiten.

Effectieve monitoring van Managed Identity voor Azure App Service is essentieel om te waarborgen dat authenticatie correct functioneert, dat beveiligingsincidenten tijdig worden gedetecteerd, en dat compliance-vereisten worden nageleefd. Monitoring omvat het continu volgen van authenticatie-activiteiten, het detecteren van mislukte authenticatiepogingen die kunnen wijzen op beveiligingsbedreigingen, het verifiëren dat Managed Identity correct is geconfigureerd voor alle productie App Services, en het waarborgen dat alle authenticatie-activiteiten worden gelogd voor auditdoeleinden. Zonder uitgebreide monitoring kunnen organisaties niet garanderen dat hun zero-secrets architectuur daadwerkelijk werkt en dat ze voldoen aan compliance-vereisten zoals ISO 27001, NIS2 en OWASP Top 10.

De basis van Managed Identity-monitoring wordt gevormd door Azure AD sign-in logs. Deze logboeken registreren alle authenticatie-activiteiten waarbij Managed Identities worden gebruikt om toegang te krijgen tot Azure-resources. Organisaties moeten deze diagnostische instellingen inschakelen en de logboeken streamen naar een Log Analytics-workspace voor langetermijnretentie en real-time analyse. Voor compliance-doeleinden wordt aanbevolen om logboeken minimaal zeven jaar te bewaren, wat overeenkomt met veel compliance-frameworks zoals AVG en ISO 27001. De sign-in logs bevatten gedetailleerde informatie over wanneer een Managed Identity wordt gebruikt, welke resource wordt benaderd, of de authenticatie succesvol was, en welke foutmeldingen zijn gegenereerd bij mislukte pogingen. Deze informatie is essentieel voor forensisch onderzoek en compliance-audits.

Azure Monitor waarschuwingsregels moeten worden geconfigureerd om kritieke authenticatiegebeurtenissen automatisch te detecteren en te rapporteren. Een van de belangrijkste waarschuwingen is voor mislukte authenticatiepogingen waarbij een Managed Identity geen toegang krijgt tot een Azure-resource. Wanneer er meer dan tien mislukte authenticatiepogingen binnen één uur plaatsvinden, kan dit wijzen op permission-problemen, geautomatiseerde aanvallen, of pogingen tot ongeautoriseerde toegang. Deze waarschuwingen moeten onmiddellijk worden verzonden naar het security operations center en naar identity administrators. Een tweede kritieke waarschuwing betreft het gebruik van legacy authenticatiemethoden zoals connection strings met embedded passwords. Wanneer een App Service nog steeds gebruikmaakt van connection strings in plaats van Managed Identity, moet dit worden gemeld als een beveiligingsrisico dat onmiddellijk moet worden aangepakt.

Abnormale authenticatiepatronen kunnen wijzen op beveiligingsincidenten zoals credential theft of unauthorized access. Wanneer het volume van authenticatie-activiteiten met meer dan 500 procent toeneemt ten opzichte van het normale baseline-niveau, moet dit worden onderzocht als een potentiële beveiligingsbedreiging. Dergelijke pieken kunnen erop wijzen dat een aanvaller probeert toegang te krijgen tot resources via een gecompromitteerde Managed Identity, of dat er een geautomatiseerd proces actief is dat ongeautoriseerd gebruik maakt van de identity. Waarschuwingsregels moeten worden geconfigureerd om dergelijke afwijkingen te detecteren op basis van statistische analyse van historische data, waarbij rekening wordt gehouden met normale variaties zoals geplande maintenance-activiteiten of nieuwe applicatie-deployments.

Token expiration errors zijn bijzonder kritiek omdat ze betekenen dat de App Service geen toegang meer heeft tot Azure-resources. Dit kan gebeuren wanneer de Managed Identity is uitgeschakeld, wanneer RBAC-machtigingen zijn ingetrokken, of wanneer er problemen zijn met de Azure AD-service. Deze fouten moeten worden behandeld als kritieke incidenten die onmiddellijke respons vereisen, omdat ze kunnen resulteren in volledige applicatie-uitval. Waarschuwingsregels moeten worden geconfigureerd om onmiddellijk te escaleren naar het on-call team wanneer dergelijke fouten worden gedetecteerd, met een doelstelling voor respons binnen vijftien minuten.

Organisaties moeten een specifiek Azure Monitor workbook-dashboard creëren voor Managed Identity-monitoring. Dit dashboard moet visualisaties bevatten van authenticatie-activiteiten per uur, waarbij onderscheid wordt gemaakt tussen succesvolle en mislukte authenticatiepogingen. Het dashboard moet ook de verhouding tussen succesvolle en mislukte authenticaties tonen, wat helpt bij het identificeren van permission-problemen of configuratiefouten. Een belangrijk onderdeel van het dashboard is de Managed Identity compliance-status, die toont hoeveel App Services Managed Identity hebben ingeschakeld versus hoeveel nog steeds gebruikmaken van legacy authenticatiemethoden. Het dashboard moet ook authenticatiepatronen per App Service visualiseren, wat helpt bij het detecteren van afwijkend gedrag of ongeautoriseerd gebruik.

Azure Security Center-aanbevelingen moeten worden gemonitord om automatisch te waarschuwen bij Managed Identity-misconfiguraties. Security Center detecteert wanneer App Services geen Managed Identity hebben ingeschakeld, wanneer RBAC-machtigingen niet correct zijn geconfigureerd, of wanneer er nog steeds hardcoded credentials aanwezig zijn in App Service-configuraties. Deze aanbevelingen moeten worden behandeld als hoge prioriteit omdat ze de beveiliging van applicaties direct beïnvloeden. Organisaties moeten een proces implementeren waarbij Security Center-aanbevelingen wekelijks worden gereviewd en waarbij alle kritieke bevindingen binnen 48 uur worden opgelost.

Kwartaalreviews van Managed Identity-configuraties zijn essentieel om te waarborgen dat alle productie App Services correct zijn geconfigureerd. Tijdens deze reviews moeten organisaties verifiëren dat alle App Services Managed Identity hebben ingeschakeld, dat RBAC-machtigingen correct zijn geconfigureerd volgens het principe van least privilege, en dat er geen hardcoded credentials meer aanwezig zijn in App Service-configuraties. Deze reviews moeten worden gedocumenteerd en alle wijzigingen moeten worden goedgekeurd door senior management. De reviews moeten ook worden gebruikt om te verifiëren dat er geen orphaned permissions zijn (machtigingen voor App Services die niet meer bestaan) en dat alle authenticatie-activiteiten correct worden gelogd.

De Managed Identity-status van App Services moet regelmatig worden geverifieerd via de Azure Portal of via geautomatiseerde scripts. Organisaties moeten maandelijks controleren dat alle productie App Services Managed Identity hebben ingeschakeld en dat de RBAC-machtigingen correct zijn geconfigureerd. Eventuele wijzigingen in de Managed Identity-configuratie moeten onmiddellijk worden onderzocht, omdat dit kan wijzen op een beveiligingsincident of een onbedoelde configuratiewijziging. Deze verificaties moeten worden gedocumenteerd en moeten deel uitmaken van de reguliere security compliance-checks.

Remediatie

Gebruik PowerShell-script app-service-managed-identity-enabled.ps1 (functie Invoke-Remediation) – Automatiseert de implementatie van Managed Identity voor App Services die nog gebruikmaken van hardcoded credentials.

Remediatie van Managed Identity voor Azure App Service omvat het implementeren van Managed Identity voor App Services die momenteel gebruikmaken van hardcoded credentials, connection strings met embedded passwords, of andere onveilige authenticatiemethoden. Het proces vereist zorgvuldige planning en uitvoering om te voorkomen dat applicaties tijdens de migratie uitvallen, en om te waarborgen dat alle hardcoded credentials volledig worden verwijderd uit de codebase en configuratiebestanden. Voor productie-applicaties is het belangrijk om een gestructureerde aanpak te volgen die minimale downtime veroorzaakt en die alle beveiligingsrisico's elimineert die gepaard gaan met hardcoded credentials.

Het remediatieproces begint met een uitgebreide assessment van de huidige App Service-configuratie. Identificeer alle plaatsen waar credentials worden gebruikt, inclusief App Service Application Settings, Connection Strings, environment variables, configuratiebestanden zoals appsettings.json of web.config, en broncode. Gebruik geautomatiseerde tools zoals GitHub Secret Scanning, GitGuardian, of Azure Security Center om alle hardcoded credentials te detecteren. Documenteer welke Azure-resources de App Service moet kunnen benaderen, welke RBAC-machtigingen nodig zijn, en welke applicatiecode moet worden bijgewerkt om DefaultAzureCredential te gebruiken. Deze assessment is essentieel om een compleet beeld te krijgen van de scope van de remediatie en om te voorkomen dat er credentials over het hoofd worden gezien.

Voor productie-applicaties moet een maintenance window worden gepland om de migratie uit te voeren zonder impact op gebruikers. Plan minimaal twee tot vier uur downtime, afhankelijk van de complexiteit van de applicatie en het aantal resources dat moet worden geconfigureerd. Communiceer proactief met alle stakeholders, inclusief developers, operations teams, en business gebruikers, over de geplande migratie en de verwachte impact. Zorg ervoor dat er een rollback-plan is voor het geval de migratie problemen veroorzaakt, hoewel dit zelden nodig is omdat Managed Identity een non-breaking change is die geen wijzigingen vereist aan de applicatielogica zelf.

De eerste stap in het remediatieproces is het inschakelen van System-Assigned Managed Identity voor de App Service. Navigeer naar de Azure Portal, selecteer de App Service, ga naar Identity onder Settings, en schakel System assigned in. Noteer de Object (principal) ID die wordt gegenereerd, want deze is nodig voor de volgende stappen. Het inschakelen van Managed Identity heeft geen impact op de huidige functionaliteit van de applicatie, omdat de applicatie nog steeds gebruikmaakt van de bestaande connection strings en credentials totdat de code wordt bijgewerkt. Dit betekent dat u Managed Identity veilig kunt inschakelen zonder dat de applicatie uitvalt.

De tweede stap omvat het toewijzen van RBAC-machtigingen aan de Managed Identity op alle Azure-resources die de App Service moet kunnen benaderen. Voor elke resource die momenteel wordt benaderd via connection strings of credentials, moet u de juiste RBAC-rol toewijzen aan de Managed Identity. Voor Azure Key Vault wijst u de rol Key Vault Secrets User toe via Access Control (IAM). Voor Azure Storage Accounts wijst u de rol Storage Blob Data Contributor of Storage Blob Data Reader toe, afhankelijk van de benodigde functionaliteit. Voor Azure SQL Database moet u eerst de Azure AD-beheerder configureren op het SQL Server-niveau, en vervolgens de Managed Identity toevoegen als databasegebruiker via SQL-commando's. Het is belangrijk om het principe van least privilege toe te passen en alleen de minimale machtigingen toe te kennen die de applicatie nodig heeft.

De derde stap is het bijwerken van de applicatiecode om DefaultAzureCredential te gebruiken in plaats van hardcoded credentials. Voor .NET-applicaties installeert u het Azure.Identity NuGet-pakket en werkt u de code bij om DefaultAzureCredential te gebruiken. Voor Node.js-applicaties installeert u het @azure/identity npm-pakket, en voor Python-applicaties installeert u het azure-identity pip-pakket. Update alle code die momenteel connection strings of credentials gebruikt om in plaats daarvan DefaultAzureCredential te gebruiken. Test de code lokaal met Azure CLI-credentials (az login) om te verifiëren dat de code correct werkt voordat u deze naar productie deployt. Deze code-updates zijn backward compatible omdat DefaultAzureCredential automatisch de beschikbare authenticatiemethode detecteert, wat betekent dat de applicatie nog steeds werkt met connection strings totdat deze volledig zijn verwijderd.

De vierde stap is het verwijderen van alle hardcoded credentials uit App Service-configuraties. Navigeer naar de App Service Configuration in de Azure Portal en verwijder alle connection strings die embedded passwords bevatten. Als secrets nog steeds nodig zijn voor externe services die geen Managed Identity ondersteunen, vervang deze dan door Key Vault-references die gebruikmaken van de syntaxis @Microsoft.KeyVault(SecretUri=...). Update Application Settings om alleen endpoints en URLs te bevatten zonder credentials. Verwijder alle environment variables die credentials bevatten. Het is belangrijk om te realiseren dat deze wijzigingen pas effect hebben nadat de applicatiecode is bijgewerkt om Managed Identity te gebruiken, dus u kunt deze stap parallel uitvoeren met de code-updates.

De vijfde stap is het testen van de volledige authenticatieflow om te verifiëren dat de applicatie succesvol kan verbinden met alle Azure-resources via Managed Identity. Deploy de bijgewerkte code naar een staging-omgeving en test alle functionaliteit die afhankelijk is van Azure-resources. Verifieer dat Key Vault-secrets correct worden opgehaald, dat Storage Account-operaties werken, dat SQL Database-verbindingen succesvol zijn, en dat alle andere Azure-service-integraties functioneren. Controleer Azure AD sign-in logs om te bevestigen dat de Managed Identity wordt gebruikt voor authenticatie. Als alle tests succesvol zijn, kunt u de code naar productie deployen. Als er problemen zijn, identificeer dan de oorzaak en los deze op voordat u doorgaat naar productie.

Na succesvolle deployment naar productie moet u een uitgebreide code-scan uitvoeren om te verifiëren dat er geen credentials meer in de codebase aanwezig zijn. Gebruik tools zoals GitHub Secret Scanning, GitGuardian, of Trufflehog om alle code- en configuratiebestanden te scannen. Als er nog steeds credentials worden gedetecteerd, verwijder deze dan onmiddellijk en roteer alle exposed credentials omdat ze mogelijk zijn gecommit naar version control. Het is belangrijk om te realiseren dat credentials die in het verleden zijn gecommit nog steeds aanwezig kunnen zijn in de git-geschiedenis, zelfs als ze uit de huidige code zijn verwijderd. Overweeg een git history rewrite voor kritieke secrets, of roteer alle exposed credentials onmiddellijk.

Voor bestaande applicaties die gebruikmaken van User-Assigned Managed Identity in plaats van System-Assigned, is het proces vergelijkbaar maar vereist een extra stap waarbij de User-Assigned Managed Identity eerst wordt aangemaakt als standalone resource. Navigeer naar Managed Identities in de Azure Portal, klik op Create, en volg de wizard om een User-Assigned Managed Identity aan te maken. Noteer de Resource ID van de identity, want deze is nodig om de identity toe te wijzen aan de App Service. Ga vervolgens naar de App Service Identity-settings, selecteer het tabblad User assigned, en voeg de User-Assigned Managed Identity toe. Het voordeel van User-Assigned Managed Identity is dat deze onafhankelijk bestaat van de App Service en kan worden gedeeld tussen meerdere App Services, wat nuttig is voor scenario's waarbij meerdere applicaties dezelfde identiteit moeten gebruiken.

De totale remediatietijd voor een typische App Service bedraagt drie tot vier uur, inclusief assessment, planning, implementatie, testing en validatie. Voor organisaties met meerdere App Services is het belangrijk om te realiseren dat de eerste remediatie de langste duurt, omdat u tijdens dit proces de patronen en best practices leert. Volgende App Services kunnen doorgaans in twee tot drie uur worden geremediateerd omdat u de geleerde patronen kunt hergebruiken. Het is aanbevolen om een remediatie-script te maken dat de meeste stappen automatiseert, wat de tijd per App Service aanzienlijk kan verkorten en het risico op menselijke fouten kan verminderen.

Compliance & Frameworks

• CIS M365: Control Identity (L1) - beheerde identiteit voor apps
• BIO: 11.02.01 - Identity en Toegangsbeheer
• ISO 27001:2022: A.9.4.2 - Use of secret authentication information

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

Managed Identity voor Azure App Service elimineert de noodzaak voor hardcoded credentials door Azure AD-managed identities te gebruiken voor authenticatie naar andere Azure-resources. System-Assigned Managed Identity creëert automatisch een Azure AD service principal specifiek voor de App Service die alleen bestaat zolang de App Service bestaat, zonder wachtwoorden of secrets - authentication gebeurt via Azure AD tokens die automatisch worden verkregen en geroteerd door het Azure-platform. User-Assigned Managed Identity is een standalone Azure resource die aan meerdere App Services kan worden gekoppeld (useful voor shared identities over apps). Implementatie: schakel Managed Identity in via Azure Portal → App Service → Identity → System assigned → On, of via PowerShell Set-AzWebApp -AssignIdentity. Ken RBAC-machtigingen toe op target resources: bijvoorbeeld Key Vault Secrets User op Key Vault, Storage Blob Data Contributor op Storage Accounts, SQL DB Contributor op Azure SQL. Update application code om DefaultAzureCredential() te gebruiken in plaats van connection strings - deze SDK-library detecteert automatisch Managed Identity en verkrijgt tokens zonder developer intervention. Voordelen: Zero secrets in code, configuration of environment variables (volledige eliminatie van credential exposure-risico), Automatic token rotation elke 24 uur door Azure-platform zonder operational overhead, Centralized access management via Azure RBAC in plaats van distributed secrets, Audit trails in Azure AD sign-in logs voor forensics. Deze maatregel is absoluut verplicht voor alle productie App Services die andere Azure resources benaderen (geen uitzonderingen), vereist voor compliance met OWASP A07, ISO 27001 A.9.4.2, CIS Azure Benchmark, NIS2, en considered security best practice door NIST, SANS, en alle cloud security frameworks. Implementatie-effort: 3-4 uur per applicatie (Managed Identity inschakelen, RBAC-machtigingen configureren, code updaten om DefaultAzureCredential te gebruiken, testen), geen extra Azure-kosten (Managed Identity is gratis). Doorlopende inspanning: nul - eenmaal geïmplementeerd zijn tokens volledig platform-managed zonder operational overhead. Return on investment komt van: eliminated credential leak risks (zero GitHub exposure), zero credential rotation operational burden, compliance audit success, reduced security incident costs (IBM: gemiddeld €1-5M per credential breach voorkomen), en operational simplicity door centralized Azure RBAC access management.

• Implementatietijd: 4 uur
• FTE required: 0.05 FTE