L1/L2 BIO 09.01 ISO A.5.15 CIS CIS Microsoft Azure Foundations Benchmark

Azure Applications: API Authenticatie En Autorisatie

📅 2025-01-15
•
⏱️ 30 minuten lezen
•
🔴 Must-Have

💼 Management Samenvatting

Veilige authenticatie en autorisatie vormen de hoeksteen van elke Azure Application die API's aanbiedt. Voor Nederlandse overheidsorganisaties is het essentieel dat API's die toegang geven tot gevoelige gegevens en kritieke processen zijn beveiligd met moderne identiteits- en toegangsbeheeroplossingen die voldoen aan de Nederlandse Baseline voor Veilige Cloud, BIO en NIS2-vereisten.

Aanbeveling
IMPLEMENTEER VERPLICHT - STANDAARDISEER AUTHENTICATIE EN AUTORISATIE VOOR ALLE AZURE APPLICATIONS
Risico zonder
High
Risk Score
9/10
Implementatie
200u (tech: 120u)
Van toepassing op:
✓ Azure App Service
✓ Azure Functions
✓ Azure Logic Apps
✓ Azure API Management
✓ Azure Applications

Onbeveiligde of zwak beveiligde API's vormen een kritiek risico voor Nederlandse overheidsorganisaties. Zonder adequate authenticatie en autorisatie kunnen ongeautoriseerde gebruikers of systemen toegang krijgen tot basisregistraties, zaaksystemen, persoonsgegevens en andere gevoelige informatie. Traditionele authenticatiemethoden zoals hardcoded wachtwoorden, gedeelde API-keys zonder rotatie of basic authentication bieden onvoldoende bescherming tegen moderne bedreigingen. Daarnaast maakt het ontbreken van gedetailleerde autorisatiecontroles het onmogelijk om fine-grained toegangsbeheer te implementeren, waardoor gebruikers vaak meer rechten krijgen dan strikt noodzakelijk is. Dit schendt het principe van least privilege en vergroot het risico op privilege escalation en datalekken. Voor Nederlandse overheidsorganisaties is dit onacceptabel omdat zij verantwoordelijk zijn voor het beschermen van persoonsgegevens volgens de AVG, het waarborgen van continuïteit van kritieke diensten volgens NIS2, en het voldoen aan beveiligingsnormen volgens de BIO. Moderne authenticatie- en autorisatieoplossingen op basis van OAuth2, OpenID Connect en Microsoft Entra ID bieden een robuuste basis voor veilige API-toegang waarbij identiteiten centraal worden beheerd, tokens worden gevalideerd en autorisatiebeslissingen worden genomen op basis van rollen, claims en policies.

PowerShell Modules Vereist
Primary API: Azure Resource Manager (ARM), Microsoft Graph
Connection: Connect-AzAccount, Connect-MgGraph
Required Modules: Az.Accounts, Az.Resources, Az.Websites, Microsoft.Graph.Authentication, Microsoft.Graph.Applications

Implementatie

Dit artikel beschrijft een volledig raamwerk voor het implementeren van veilige authenticatie en autorisatie voor Azure Applications die API's aanbieden. De aanpak omvat het gebruik van Microsoft Entra ID als centrale identity provider, het implementeren van OAuth2 en OpenID Connect voor moderne token-gebaseerde authenticatie, het configureren van gedetailleerde autorisatiecontroles op basis van RBAC, app-rollen en claims, en het integreren van conditional access policies voor context-afhankelijke toegangsbeslissingen. Daarnaast worden best practices beschreven voor het beveiligen van service-to-service communicatie met managed identities en client credentials flows, het implementeren van tokenvalidatie en -cache, en het configureren van uitgebreide logging en monitoring voor audit doeleinden. Het artikel bevat praktische implementatiegidsen voor verschillende scenario's, inclusief gebruikersgebaseerde authenticatie voor burger- en medewerkerportalen, service-to-service authenticatie voor backend-integraties, en hybride scenario's waarin beide patronen worden gecombineerd. Het bijbehorende PowerShell-script helpt organisaties om hun huidige authenticatie- en autorisatieconfiguratie te inventariseren en te identificeren waar verbeteringen nodig zijn.

Fundamenten van Authenticatie en Autorisatie voor Azure Applications

Authenticatie en autorisatie zijn fundamenteel verschillende maar complementaire concepten in API-beveiliging. Authenticatie beantwoordt de vraag 'wie of wat is de identiteit die toegang vraagt?', terwijl autorisatie bepaalt 'welke acties is deze identiteit toegestaan uit te voeren?'. Voor Azure Applications die API's aanbieden, begint het beveiligingsmodel met een duidelijk begrip van beide concepten en hoe zij samenwerken om veilige toegang te garanderen. Authenticatie in Azure Applications gebeurt doorgaans via Microsoft Entra ID (voorheen Azure Active Directory), dat fungeert als centrale identity provider. Wanneer een gebruiker of applicatie toegang wil tot een API, wordt eerst de identiteit geverifieerd via Entra ID door middel van gebruikersnamen en wachtwoorden, multi-factor authenticatie, of certificaat-gebaseerde authenticatie. Na succesvolle authenticatie ontvangt de client een token dat cryptografisch is ondertekend door Entra ID en dat claims bevat over de identiteit, zoals gebruikers-ID, e-mailadres, rollen en groepen. Dit token wordt vervolgens meegestuurd met elke API-aanroep als bearer token in de Authorization header, waardoor de API kan verifiëren dat het verzoek afkomstig is van een geverifieerde identiteit zonder dat bij elke request opnieuw inloggegevens hoeven te worden opgegeven.

Autorisatie volgt na authenticatie en bepaalt welke specifieke acties de geverifieerde identiteit mag uitvoeren. Azure Applications ondersteunen verschillende autorisatiemodellen die kunnen worden gecombineerd voor optimale flexibiliteit en beveiliging. Role-Based Access Control (RBAC) definieert rollen zoals 'Reader', 'Contributor' of 'Owner' die bepaalde sets van machtigingen bevatten. App-rollen zijn specifieke rollen die worden gedefinieerd in de app-registratie in Entra ID en die kunnen worden toegewezen aan gebruikers of service principals. Claims-based authorization gebruikt claims in het token, zoals groepen, afdeling of geografische locatie, om toegangsbeslissingen te nemen. Resource-based authorization controleert eigendom of lidmaatschap van specifieke resources om toegang te verlenen. De combinatie van deze modellen maakt het mogelijk om zeer fijnmazige toegangscontrole te implementeren waarbij bijvoorbeeld alleen gebruikers in de groep 'Juridische Zaken' toegang hebben tot specifieke API-endpoints, of waarbij service principals alleen toegang hebben tot resources binnen hun eigen resource group. Voor Nederlandse overheidsorganisaties is deze fijnmazigheid essentieel om te voldoen aan het principe van least privilege dat wordt vereist door BIO en om te kunnen aantonen dat toegang tot persoonsgegevens is beperkt tot die personen die dit daadwerkelijk nodig hebben voor hun functie.

Een belangrijk aspect van moderne authenticatie- en autorisatiearchitecturen is het Zero Trust-principe, waarbij elke toegangsaanvraag wordt geverifieerd en geautoriseerd op basis van de huidige context, ongeacht of de identiteit eerder toegang heeft gekregen. Dit betekent dat zelfs nadat authenticatie is geslaagd en een token is uitgegeven, aanvullende controles kunnen worden uitgevoerd op basis van factoren zoals de locatie van de client, het apparaat dat wordt gebruikt, de tijd van de dag, of verdachte activiteitspatronen. Azure Conditional Access policies maken het mogelijk om dergelijke context-afhankelijke controles te implementeren, bijvoorbeeld door extra verificatie te eisen wanneer een gebruiker inlogt vanaf een niet-vertrouwde locatie, of door toegang te blokkeren voor apparaten die niet voldoen aan compliance-eisen. Deze extra laag van beveiliging is bijzonder waardevol voor Azure Applications die gevoelige gegevens verwerken, omdat het bescherming biedt tegen gestolen credentials, session hijacking en andere geavanceerde aanvallen. Door authenticatie en autorisatie te baseren op moderne standaarden zoals OAuth2 en OpenID Connect, en deze aan te vullen met conditional access en fijnmazige RBAC, kunnen Nederlandse overheidsorganisaties een robuust beveiligingsmodel implementeren dat voldoet aan de hoge eisen van de Nederlandse Baseline voor Veilige Cloud.

Integratie met Microsoft Entra ID voor Centraal Identiteitsbeheer

Gebruik PowerShell-script api-authentication-authorization.ps1 (functie Invoke-Monitoring) – Inventariseert Azure Applications en controleert of Microsoft Entra ID authenticatie en autorisatie correct zijn geconfigureerd.

Microsoft Entra ID fungeert als het centrale identity- en access management platform voor Azure Applications, waardoor organisaties alle identiteiten, applicaties en toegangsbeleid op één plek kunnen beheren. De integratie begint met het registreren van de Azure Application als een app-registratie in Entra ID, waarbij een unieke client-ID wordt toegewezen en configuratie wordt vastgelegd voor authenticatie- en autorisatieflows. Tijdens deze registratie worden belangrijke instellingen geconfigureerd, zoals de redirect URI's waar tokens naartoe kunnen worden gestuurd na authenticatie, de geaccepteerde token-issuers (meestal alleen de eigen tenant, maar mogelijk ook multi-tenant scenario's), en de vereiste API-permissions die de applicatie nodig heeft om te functioneren. Voor API's die zelf worden aangeboden, wordt een aparte app-registratie gemaakt die fungeert als de resource of API die wordt beschermd. Deze resource app-registratie definieert scopes (gedelegeerde machtigingen) en app-rollen (application permissions) die andere applicaties of gebruikers kunnen aanvragen om toegang te krijgen tot de API. Deze scopes en rollen vormen de basis voor autorisatiebeslissingen, waardoor API's kunnen bepalen welke acties een bepaalde identiteit mag uitvoeren op basis van de claims in het ontvangen token.

De authenticatieflow zelf wordt georkestreerd door OAuth2 en OpenID Connect protocollen, waarbij Entra ID fungeert als de authorization server. Voor interactieve gebruikersscenario's wordt doorgaans de authorization code flow met PKCE gebruikt, waarbij de gebruiker eerst wordt doorgestuurd naar een Entra ID login-pagina, authenticatie uitvoert (inclusief multi-factor authenticatie indien geconfigureerd), en vervolgens een autorisatiecode ontvangt die wordt uitgewisseld voor een access token en optioneel een refresh token. Deze flow is veiliger dan implicit flows omdat tokens nooit direct worden blootgesteld in URL's of browser geschiedenis, en PKCE voorkomt dat autorisatiecodes worden onderschept. Voor service-to-service scenario's zonder gebruikersinteractie wordt de client credentials flow gebruikt, waarbij een service principal zich authenticeert met een client secret of certificaat en direct een access token ontvangt. In beide gevallen worden de tokens uitgegeven door Entra ID en bevatten ze claims zoals de issuer (Entra ID tenant-ID), de audience (de app-registratie van de API), de gebruiker of service principal die het token heeft aangevraagd, en de scopes of rollen die zijn toegekend. De API valideert deze claims om te verifiëren dat het token legitiem is en dat de identiteit de juiste autorisatie heeft voor de aangevraagde actie.

Een cruciaal aspect van Entra ID-integratie is het beheren van secrets en credentials voor service principals en applicaties. Hardcoded secrets in broncode of configuratiebestanden vormen een kritiek beveiligingsrisico, vooral wanneer deze worden opgeslagen in version control systemen. In plaats daarvan moeten secrets worden opgeslagen in Azure Key Vault, waarbij applicaties gebruikmaken van managed identities om toegang te krijgen tot Key Vault zonder dat secrets expliciet hoeven te worden opgeslagen. Managed identities zijn identiteiten die door Azure automatisch worden beheerd en die geen credentials vereisen in code. Wanneer een Azure Application zoals App Service of Function App wordt geconfigureerd met een system-assigned of user-assigned managed identity, kan deze identity worden gebruikt om te authentiseren bij andere Azure-services, Key Vault, of API's die Entra ID ondersteunen, zonder dat er geheime sleutels hoeven te worden beheerd. Voor scenario's waarbij managed identities niet mogelijk zijn, moeten client secrets of certificaten worden opgeslagen in Key Vault en worden geroteerd volgens een vast schema, bijvoorbeeld elk kwartaal of direct na vermoeden van compromittering. Door deze best practices te volgen, kunnen organisaties een veilige en beheerbare integratie met Entra ID implementeren die voldoet aan de Nederlandse Baseline voor Veilige Cloud en de eisen voor geheimenbeheer in BIO en ISO 27001.

Tokenvalidatie en Autorisatie Policies in Azure Applications

Gebruik PowerShell-script api-authentication-authorization.ps1 (functie Invoke-Monitoring) – Controleert of tokenvalidatie en autorisatie policies correct zijn geconfigureerd voor Azure Applications.

Zodra een Azure Application tokens ontvangt van clients, moet het deze tokens valideren voordat toegang wordt verleend. Tokenvalidatie omvat verschillende controles die verifiëren dat het token legitiem is, niet is vervalst, en afkomstig is van een vertrouwde identity provider. De eerste validatiestap is het controleren van de digitale handtekening van het token met behulp van de publieke sleutels van de identity provider. Deze publieke sleutels worden opgehaald via het OpenID Connect discovery endpoint van Entra ID, waarbij de issuer URL wordt gebruikt om de juiste signing keys te identificeren. De handtekeningvalidatie verzekert dat het token daadwerkelijk is uitgegeven door Entra ID en niet is aangepast tijdens transport. Vervolgens worden de claims in het token gevalideerd: de issuer moet overeenkomen met de verwachte Entra ID tenant-ID, de audience moet overeenkomen met de app-registratie van de API, de expiration time moet in de toekomst liggen (het token mag niet zijn verlopen), en de not-before time moet in het verleden liggen (het token moet geldig zijn). Daarnaast kunnen aanvullende claims worden gecontroleerd, zoals de app-ID van de client die het token heeft aangevraagd, om te verifiëren dat alleen geautoriseerde applicaties toegang krijgen.

Na succesvolle tokenvalidatie volgt de autorisatiecontrole, waarbij wordt bepaald of de geverifieerde identiteit de gevraagde actie mag uitvoeren. Azure Applications kunnen verschillende mechanismen gebruiken voor autorisatie, afhankelijk van de complexiteit van de vereisten en de architectuur van de applicatie. In ASP.NET Core applicaties kan bijvoorbeeld gebruik worden gemaakt van het authorization middleware dat policies, requirements en handlers ondersteunt. Policies definiëren welke voorwaarden moeten worden voldaan voor toegang, bijvoorbeeld dat de gebruiker een specifieke rol moet hebben, tot een bepaalde groep moet behoren, of aan een custom requirement moet voldoen. Requirements zijn de specifieke regels binnen een policy, zoals 'moet de rol Administrator hebben' of 'moet tot de groep Juridische Zaken behoren'. Handlers evalueren of een gebruiker aan een requirement voldoet door claims in het token te analyseren, aanvullende gegevens op te halen uit Entra ID of andere bronnen, of complexe bedrijfslogica uit te voeren. Deze aanpak maakt het mogelijk om zeer flexibele en fijnmazige autorisatie te implementeren waarbij bijvoorbeeld alleen gebruikers met de rol 'Zaakbehandelaar' en die tot de afdeling 'Burgerservicing' behoren, toegang krijgen tot specifieke API-endpoints voor het behandelen van zaakdossiers.

Voor Azure API Management fungeren policies als het primaire mechanisme voor tokenvalidatie en autorisatie. De validate-jwt policy controleert tokens op signature, issuer, audience, expiration en andere claims, en kan aanvullende custom claims valideren zoals rollen of scopes. Deze policy kan worden toegepast op API-niveau, operation-niveau of product-niveau, waardoor verschillende niveaus van beveiliging kunnen worden geconfigureerd voor verschillende endpoints. Na tokenvalidatie kunnen additional policies worden gebruikt om autorisatiebeslissingen te nemen, bijvoorbeeld door te controleren op specifieke claims in het token en op basis daarvan toegang te verlenen of te weigeren, of door gegevens uit het token te extraheren en door te geven aan de backend-API. Voor Azure Functions kunnen HTTP-triggers worden beveiligd met function keys of met Entra ID authenticatie, waarbij de runtime automatisch tokens valideert en claims beschikbaar maakt aan de functiecode voor autorisatiecontroles. In alle gevallen is het essentieel dat autorisatie niet alleen wordt gecontroleerd op API-gateway niveau, maar ook op application niveau, zodat zelfs als een aanvaller de gateway omzeilt, de applicatie zelf nog steeds toegangscontroles uitvoert. Deze defense-in-depth aanpak verhoogt de beveiliging en zorgt ervoor dat toegangsbeslissingen op meerdere lagen worden gecontroleerd.

Service-to-Service Authenticatie met Managed Identities en Client Credentials

Naast gebruikersgebaseerde authenticatie moeten Azure Applications ook service-to-service communicatie beveiligen, waarbij applicaties onderling API's aanroepen zonder directe gebruikersinteractie. Dit scenario komt veel voor in microservices-architecturen, backend-integraties en geautomatiseerde workflows. De aanbevolen aanpak voor service-to-service authenticatie in Azure is het gebruik van managed identities in combinatie met OAuth2 client credentials flow. Managed identities zijn identiteiten die door Azure automatisch worden beheerd en waarvoor geen credentials hoeven te worden opgeslagen of geroteerd. Wanneer een Azure resource zoals App Service, Function App of Logic App wordt geconfigureerd met een system-assigned managed identity, krijgt deze resource automatisch een service principal in Entra ID die kan worden gebruikt voor authenticatie bij andere Azure-services en API's. User-assigned managed identities zijn handmatig gemaakte identiteiten die kunnen worden toegewezen aan meerdere resources, wat nuttig is wanneer meerdere applicaties dezelfde identiteit moeten delen. Het voordeel van managed identities is dat er geen secrets in code, configuratie of environment variables hoeven te worden opgeslagen, waardoor het risico op credential leakage wordt geëlimineerd. Daarnaast worden managed identities automatisch beheerd door Azure, inclusief rotatie van de onderliggende certificates, wat de operationele overhead reduceert en de beveiliging verhoogt.

Wanneer een Azure Application met een managed identity toegang wil tot een andere API, gebruikt het de Azure Instance Metadata Service (IMDS) om een access token aan te vragen namens de managed identity. IMDS is een REST endpoint die alleen toegankelijk is vanuit de Azure resource zelf en die automatisch tokens kan uitgeven voor de geconfigureerde managed identity. Het aanvragen van een token via IMDS vereist geen credentials, omdat de authenticatie gebeurt op basis van de identiteit van de Azure resource zelf. Het token dat wordt ontvangen bevat claims over de managed identity, zoals de object-ID en de app-ID, die kunnen worden gebruikt voor autorisatiebeslissingen in de target API. Voor scenario's waarbij managed identities niet mogelijk zijn, bijvoorbeeld bij on-premises applicaties of applicaties die buiten Azure draaien, kan de client credentials flow worden gebruikt waarbij een service principal zich authenticeert met een client secret of certificaat. Deze secrets moeten worden opgeslagen in Azure Key Vault en periodiek worden geroteerd. De client credentials flow is minder veilig dan managed identities omdat secrets expliciet moeten worden beheerd, maar biedt flexibiliteit voor hybride en multi-cloud scenario's. In alle gevallen moet de target API de ontvangen tokens valideren en autorisatiebeslissingen nemen op basis van de claims in het token, bijvoorbeeld door te controleren of de client app-ID is toegestaan of of de service principal de juiste app-rol heeft gekregen.

Een belangrijk aspect van service-to-service authenticatie is het voorkomen van privilege escalation waarbij een service meer rechten krijgt dan nodig is. Het principe van least privilege vereist dat elke service alleen de minimale machtigingen krijgt die nodig zijn om zijn functie uit te voeren. In de context van service-to-service communicatie betekent dit dat service principals en managed identities specifieke app-rollen moeten krijgen die precies de benodigde acties toestaan, in plaats van brede 'Owner' of 'Contributor' rollen. Bijvoorbeeld, een service die alleen gegevens moet lezen uit een database, moet alleen een 'Reader' rol krijgen en geen 'Contributor' of 'Data Contributor' rol die schrijfacties toestaat. Daarnaast moeten app-rollen worden gedefinieerd op het niveau van de resource API in Entra ID, zodat expliciet wordt vastgelegd welke acties mogelijk zijn, zoals 'Zaak.Lezen', 'Zaak.Schrijven', of 'Zaak.Verwijderen'. Deze rollen worden vervolgens toegewezen aan service principals via app role assignments, waarbij alleen de specifieke rollen worden toegekend die nodig zijn voor de functie van de service. Door deze fijnmazige aanpak te volgen, kunnen organisaties het risico op privilege escalation beperken en voldoen aan de eisen voor least privilege in BIO en ISO 27001. Het bijbehorende PowerShell-script kan helpen om te identificeren waar service principals of managed identities mogelijk overgeprivileged zijn door de toegewezen rollen te analyseren en te vergelijken met de daadwerkelijke gebruikte API-endpoints.

Monitoring, Audit Logging en Incident Response voor API Authenticatie

Gebruik PowerShell-script api-authentication-authorization.ps1 (functie Invoke-Remediation) – Genereert rapporten over authenticatie- en autorisatieconfiguraties en aanbevelingen voor verbetering.

Uitgebreide monitoring en audit logging van authenticatie- en autorisatieactiviteiten is essentieel voor security operations, compliance-verificatie en incident response. Nederlandse overheidsorganisaties moeten kunnen aantonen wie wanneer toegang heeft gekregen tot welke API's en resources, welke authenticatiepogingen zijn geslaagd of mislukt, en welke autorisatiebeslissingen zijn genomen. Azure biedt verschillende logging-mechanismen die moeten worden geconfigureerd en gecentraliseerd voor effectieve monitoring. Microsoft Entra ID Sign-In Logs en Audit Logs bevatten gedetailleerde informatie over alle authenticatiepogingen, inclusief de gebruiker of service principal die heeft geprobeerd in te loggen, de applicatie die toegang heeft aangevraagd, de IP-adres en locatie van waaruit de poging is gedaan, de gebruikte authenticatiemethode (bijvoorbeeld wachtwoord, multi-factor authenticatie, of certificaat), en of de poging succesvol was of is geweigerd en waarom. Deze logs moeten worden geëxporteerd naar een centrale logging-oplossing zoals Azure Log Analytics of een SIEM-platform zoals Microsoft Sentinel, waar queries en alerts kunnen worden geconfigureerd om verdachte activiteiten te detecteren, zoals mislukte inlogpogingen vanuit onbekende locaties, ongebruikelijke toegangspatronen, of pogingen tot privilege escalation.

Op application niveau moeten Azure Applications zelf ook uitgebreide logging implementeren voor alle authenticatie- en autorisatieactiviteiten. Dit omvat het loggen van elke API-aanroep, inclusief de identiteit die het verzoek heeft gedaan (geëxtraheerd uit het token), de tijdstempel, de aangevraagde resource en actie, en of toegang is verleend of geweigerd. Voor geweigerde toegangspogingen is het belangrijk om de reden voor de weigering vast te leggen, bijvoorbeeld 'token verlopen', 'ontbrekende rol', of 'niet geautoriseerd voor deze resource'. Deze application logs moeten worden gestructureerd (bijvoorbeeld in JSON-formaat) zodat ze eenvoudig kunnen worden doorzocht en geanalyseerd, en moeten worden doorgestuurd naar een centrale logging-oplossing. Application Insights kan worden gebruikt voor Azure Applications om automatisch telemetrie te verzamelen over requests, dependencies, exceptions en custom events, waarbij authenticatie- en autorisatie-informatie kan worden opgenomen als custom properties of dimensions. Deze telemetrie kan vervolgens worden geaggregeerd in dashboards die inzicht geven in authenticatie-success rates, autorisatie-failure rates, meest gebruikte endpoints, en identiteiten met de hoogste activiteit. Door deze metrics continu te monitoren, kunnen security teams snel afwijkingen detecteren die mogelijk wijzen op aanvallen, misbruik of configuratiefouten.

Incident response voor authenticatie- en autorisatieproblemen vereist snelle detectie, analyse en remediatie. Wanneer een verdachte activiteit wordt gedetecteerd, bijvoorbeeld via een alert in Microsoft Sentinel of een anomaly detection in Application Insights, moeten security teams snel kunnen bepalen of het een echte bedreiging is of een vals positief, en passende actie ondernemen. Voor authentieke bedreigingen kunnen verschillende mitigatiemaatregelen worden genomen, zoals het intrekken van tokens door de gebruiker of service principal te dwingen opnieuw te authenticeren, het tijdelijk blokkeren van een identiteit via conditional access policies, het intrekken van app role assignments om toegang tot specifieke API's te blokkeren, of in extreme gevallen het volledig uitschakelen van een account of service principal. Azure Key Vault biedt functionaliteit voor het intrekken van certificaten en secrets, wat essentieel is wanneer wordt vermoed dat credentials zijn gecompromitteerd. Daarnaast moeten incident response procedures worden gedocumenteerd en regelmatig worden geoefend, zodat teams weten hoe te reageren op verschillende scenario's zoals gestolen tokens, misbruik van service principals, of ongeautoriseerde toegang tot gevoelige API's. Voor Nederlandse overheidsorganisaties is het ook belangrijk om incidenten te melden aan relevante toezichthouders zoals de Autoriteit Persoonsgegevens (AVG) of de relevante sectorale toezichthouder (NIS2), waarbij de uitgebreide audit logs kunnen worden gebruikt om de scope en impact van het incident te bepalen en te documenteren. Door monitoring, logging en incident response op deze manier te structureren, kunnen organisaties proactief bedreigingen detecteren en snel reageren op beveiligingsincidenten, wat bijdraagt aan het waarborgen van de beveiliging en compliance van Azure Applications.

Compliance & Frameworks

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).

PowerShell
<# ================================================================================ AZURE POWERSHELL SCRIPT - Nederlandse Baseline voor Veilige Cloud ================================================================================ .SYNOPSIS Azure Applications: API Authenticatie en Autorisatie .DESCRIPTION Controleert of Azure Applications (App Service, Functions, Logic Apps) voldoen aan best practices voor API authenticatie en autorisatie, inclusief Microsoft Entra ID integratie, tokenvalidatie, en managed identities. Waarom is deze control belangrijk? - Voorkomen van ongeautoriseerde toegang tot API's - Compliance met BIO, AVG en NIS2 vereisten - Zekerstellen van correcte tokenvalidatie en autorisatie - Audit trail voor toegangsgebeurtenissen .NOTES Filename: api-authentication-authorization.ps1 Author: Nederlandse Baseline voor Veilige Cloud Created: 2025-01-15 Last Modified: 2025-01-15 Version: 1.0 Related JSON: content/azure/application/api-authentication-authorization.json .PARAMETER WhatIf Toont wat het script zou doen zonder daadwerkelijk wijzigingen door te voeren .PARAMETER Monitoring Voert uitgebreide compliance check uit en toont gedetailleerd rapport .PARAMETER Remediation Genereert rapporten en aanbevelingen voor verbetering .EXAMPLE .\api-authentication-authorization.ps1 Voert basis compliance check uit .EXAMPLE .\api-authentication-authorization.ps1 -Monitoring Toont gedetailleerd compliance rapport .EXAMPLE .\api-authentication-authorization.ps1 -Remediation Genereert aanbevelingen voor authenticatie- en autorisatieconfiguraties #> # ============================================================================ # REQUIREMENTS # ============================================================================ #Requires -Version 5.1 #Requires -Modules Az.Accounts #Requires -Modules Az.Websites #Requires -Modules Az.Resources #Requires -Modules Microsoft.Graph.Authentication #Requires -Modules Microsoft.Graph.Applications # ============================================================================ # PARAMETERS # ============================================================================ [CmdletBinding()] param( [Parameter()][switch]$WhatIf, [Parameter()][switch]$Monitoring, [Parameter()][switch]$Remediation ) # ============================================================================ # GLOBAL VARIABLES # ============================================================================ $ErrorActionPreference = 'Stop' $VerbosePreference = 'Continue' $PolicyName = "Azure Applications: API Authenticatie en Autorisatie" # ============================================================================ # FUNCTION: Connect-RequiredServices # ============================================================================ function Connect-RequiredServices { <# .SYNOPSIS Verbindt met benodigde Azure services #> [CmdletBinding()] param() Write-Verbose "Controleren van Azure verbinding..." try { $context = Get-AzContext -ErrorAction SilentlyContinue if (-not $context) { Write-Host "Verbinding maken met Azure..." -ForegroundColor Yellow Connect-AzAccount -ErrorAction Stop | Out-Null Write-Host "Verbonden met Azure" -ForegroundColor Green } else { Write-Verbose "Reeds verbonden met Azure als $($context.Account.Id)" } Write-Verbose "Controleren van Microsoft Graph verbinding..." $mgContext = Get-MgContext -ErrorAction SilentlyContinue if (-not $mgContext) { Write-Host "Verbinding maken met Microsoft Graph..." -ForegroundColor Yellow Connect-MgGraph -Scopes "Application.Read.All", "Directory.Read.All" -ErrorAction Stop | Out-Null Write-Host "Verbonden met Microsoft Graph" -ForegroundColor Green } else { Write-Verbose "Reeds verbonden met Microsoft Graph" } } catch { Write-Error "Kon niet verbinden met Azure of Microsoft Graph: $_" throw } } # ============================================================================ # FUNCTION: Test-AppServiceEntraAuth # ============================================================================ function Test-AppServiceEntraAuth { <# .SYNOPSIS Test of App Service Microsoft Entra ID authenticatie heeft geconfigureerd #> [CmdletBinding()] param( [Parameter(Mandatory = $true)] [Microsoft.Azure.Commands.WebApps.Models.PSSite]$WebApp ) try { $authSettings = Get-AzWebAppAuthSetting -ResourceGroupName $WebApp.ResourceGroup -Name $WebApp.Name -ErrorAction SilentlyContinue if (-not $authSettings) { return @{ HasAuth = $false Provider = "None" ClientId = $null } } $entraProvider = $authSettings.Providers | Where-Object { $_.Name -eq "AzureActiveDirectory" } return @{ HasAuth = ($entraProvider -ne $null) Provider = if ($entraProvider) { "AzureActiveDirectory" } else { "Other" } ClientId = if ($entraProvider) { $entraProvider.ClientId } else { $null } } } catch { Write-Verbose "Kon authenticatie-instellingen niet ophalen voor $($WebApp.Name): $_" return @{ HasAuth = $false Provider = "Unknown" ClientId = $null } } } # ============================================================================ # FUNCTION: Test-ManagedIdentity # ============================================================================ function Test-ManagedIdentity { <# .SYNOPSIS Test of App Service of Function App een managed identity heeft #> [CmdletBinding()] param( [Parameter(Mandatory = $true)] [Microsoft.Azure.Commands.WebApps.Models.PSSite]$WebApp ) try { $identity = Get-AzWebAppIdentity -ResourceGroupName $WebApp.ResourceGroup -Name $WebApp.Name -ErrorAction SilentlyContinue return @{ HasSystemAssigned = ($identity.Type -eq "SystemAssigned" -or $identity.Type -eq "SystemAssigned, UserAssigned") PrincipalId = $identity.PrincipalId } } catch { Write-Verbose "Kon managed identity niet ophalen voor $($WebApp.Name): $_" return @{ HasSystemAssigned = $false PrincipalId = $null } } } # ============================================================================ # FUNCTION: Test-Compliance # ============================================================================ function Test-Compliance { <# .SYNOPSIS Test compliance met authenticatie- en autorisatie best practices .OUTPUTS PSCustomObject met compliance resultaten #> [CmdletBinding()] param() Write-Verbose "Controleren van authenticatie- en autorisatie configuraties..." $result = [PSCustomObject]@{ ScriptName = "api-authentication-authorization" PolicyName = $PolicyName IsCompliant = $false TotalResources = 0 CompliantCount = 0 NonCompliantCount = 0 Details = @() Recommendations = @() AppServiceIssues = @() FunctionAppIssues = @() ManagedIdentityIssues = @() } try { Write-Verbose "Ophalen van alle App Services..." $webApps = Get-AzWebApp -ErrorAction SilentlyContinue Write-Verbose "Ophalen van alle Function Apps..." $functionApps = Get-AzFunctionApp -ErrorAction SilentlyContinue $totalApps = @($webApps).Count + @($functionApps).Count $result.TotalResources = $totalApps if ($totalApps -eq 0) { $result.Details += "Geen App Services of Function Apps gevonden in dit subscription" $result.IsCompliant = $true return $result } # Check App Services foreach ($app in $webApps) { Write-Verbose "Controleren van App Service: $($app.Name)" $appCompliant = $true $appIssues = @() # Check 1: Entra ID Authenticatie $authInfo = Test-AppServiceEntraAuth -WebApp $app if (-not $authInfo.HasAuth -or $authInfo.Provider -ne "AzureActiveDirectory") { $appCompliant = $false $appIssues += "Geen Microsoft Entra ID authenticatie geconfigureerd" $result.AppServiceIssues += @{ AppName = $app.Name ResourceGroup = $app.ResourceGroup Issue = "Geen Entra ID authenticatie" } } # Check 2: Managed Identity $identityInfo = Test-ManagedIdentity -WebApp $app if (-not $identityInfo.HasSystemAssigned) { $appIssues += "Geen managed identity geconfigureerd (aanbevolen voor service-to-service authenticatie)" $result.ManagedIdentityIssues += @{ AppName = $app.Name ResourceGroup = $app.ResourceGroup Issue = "Geen managed identity" } } # Determine compliance status if ($appIssues.Count -eq 0) { $result.CompliantCount++ $result.Details += "✓ App Service '$($app.Name)' voldoet aan authenticatie- en autorisatie best practices" } else { $result.NonCompliantCount++ $appCompliant = $false $issuesText = $appIssues -join "; " $result.Details += "✗ App Service '$($app.Name)': $issuesText (ResourceGroup: $($app.ResourceGroup))" if (-not $authInfo.HasAuth) { $result.Recommendations += "Configureer Microsoft Entra ID authenticatie voor App Service '$($app.Name)'" } if (-not $identityInfo.HasSystemAssigned) { $result.Recommendations += "Overweeg managed identity te configureren voor App Service '$($app.Name)' voor service-to-service authenticatie" } } } # Check Function Apps foreach ($func in $functionApps) { Write-Verbose "Controleren van Function App: $($func.Name)" $funcCompliant = $true $funcIssues = @() # Check Managed Identity for Function Apps try { $funcIdentity = Get-AzWebAppIdentity -ResourceGroupName $func.ResourceGroupName -Name $func.Name -ErrorAction SilentlyContinue if (-not $funcIdentity -or ($funcIdentity.Type -ne "SystemAssigned" -and $funcIdentity.Type -ne "SystemAssigned, UserAssigned")) { $funcIssues += "Geen managed identity geconfigureerd" $result.ManagedIdentityIssues += @{ AppName = $func.Name ResourceGroup = $func.ResourceGroupName Issue = "Geen managed identity" } } } catch { Write-Verbose "Kon managed identity niet controleren voor Function App $($func.Name): $_" } if ($funcIssues.Count -eq 0) { $result.CompliantCount++ $result.Details += "✓ Function App '$($func.Name)' voldoet aan authenticatie- en autorisatie best practices" } else { $result.NonCompliantCount++ $funcCompliant = $false $issuesText = $funcIssues -join "; " $result.Details += "✗ Function App '$($func.Name)': $issuesText (ResourceGroup: $($func.ResourceGroupName))" $result.FunctionAppIssues += @{ AppName = $func.Name ResourceGroup = $func.ResourceGroupName Issue = "Authenticatie- of autorisatie configuratie ontbreekt" } $result.Recommendations += "Overweeg managed identity te configureren voor Function App '$($func.Name)' voor service-to-service authenticatie" } } # Overall compliance check $result.IsCompliant = ($result.NonCompliantCount -eq 0) # Add general recommendations if ($result.AppServiceIssues.Count -gt 0) { $result.Recommendations += "Configureer Microsoft Entra ID authenticatie voor alle App Services die API's aanbieden" } if ($result.ManagedIdentityIssues.Count -gt 0) { $result.Recommendations += "Configureer managed identities voor alle Azure Applications voor veilige service-to-service authenticatie" } if ($result.NonCompliantCount -gt 0) { $result.Recommendations += "Implementeer tokenvalidatie en autorisatie policies voor alle API endpoints" $result.Recommendations += "Configureer uitgebreide logging en monitoring voor authenticatie- en autorisatieactiviteiten" } } catch { $result.Details += "ERROR: $($_.Exception.Message)" Write-Error "Fout bij compliance check: $_" } return $result } # ============================================================================ # FUNCTION: Invoke-Monitoring # ============================================================================ function Invoke-Monitoring { <# .SYNOPSIS Monitort de compliance status van authenticatie- en autorisatie configuraties #> [CmdletBinding()] param() Write-Host "`nMonitoring: $PolicyName" -ForegroundColor Yellow Write-Host "===========================================" -ForegroundColor Yellow $result = Test-Compliance Write-Host "`nResultaten:" -ForegroundColor Cyan Write-Host " Totaal Azure Applications: $($result.TotalResources)" -ForegroundColor Cyan Write-Host " Compliant: $($result.CompliantCount)" -ForegroundColor Green $color = if ($result.NonCompliantCount -gt 0) { "Red" } else { "Green" } Write-Host " Non-compliant: $($result.NonCompliantCount)" -ForegroundColor $color if ($result.AppServiceIssues.Count -gt 0) { Write-Host "`n App Services zonder Entra ID authenticatie: $($result.AppServiceIssues.Count)" -ForegroundColor Yellow foreach ($issue in $result.AppServiceIssues) { Write-Host " - $($issue.AppName) ($($issue.ResourceGroup))" -ForegroundColor Gray } } if ($result.ManagedIdentityIssues.Count -gt 0) { Write-Host "`n Applications zonder managed identity: $($result.ManagedIdentityIssues.Count)" -ForegroundColor Yellow foreach ($issue in $result.ManagedIdentityIssues) { Write-Host " - $($issue.AppName) ($($issue.ResourceGroup))" -ForegroundColor Gray } } if ($result.Details) { Write-Host "`nDetails:" -ForegroundColor Yellow foreach ($detail in $result.Details) { $detailColor = if ($detail -like "✓*") { "Green" } elseif ($detail -like "✗*") { "Red" } else { "Gray" } Write-Host " $detail" -ForegroundColor $detailColor } } if ($result.Recommendations) { Write-Host "`nAanbevelingen:" -ForegroundColor Yellow foreach ($recommendation in $result.Recommendations) { Write-Host " → $recommendation" -ForegroundColor Cyan } } if ($result.IsCompliant) { Write-Host "`n✅ COMPLIANT - Alle Azure Applications voldoen aan authenticatie- en autorisatie best practices" -ForegroundColor Green exit 0 } else { Write-Host "`n⚠️ NON-COMPLIANT - Verbetering van authenticatie- en autorisatie configuraties aanbevolen" -ForegroundColor Yellow exit 1 } } # ============================================================================ # FUNCTION: Invoke-Remediation # ============================================================================ function Invoke-Remediation { <# .SYNOPSIS Genereert rapporten en aanbevelingen voor verbetering #> [CmdletBinding()] param() Write-Host "`nRemediatie: Authenticatie- en Autorisatie Verbetering" -ForegroundColor Yellow Write-Host "===================================================" -ForegroundColor Yellow $result = Test-Compliance if ($result.IsCompliant) { Write-Host " Alle Azure Applications voldoen aan best practices" -ForegroundColor Green exit 0 } Write-Host "`nGenereren van verbeteraanbevelingen..." -ForegroundColor Cyan # Generate detailed report $reportPath = "api-auth-authorization-improvement-report-$(Get-Date -Format 'yyyyMMdd-HHmmss').txt" $reportContent = @" AUTHENTICATIE- EN AUTORISATIE VERBETERINGSREPORT Nederlandse Baseline voor Veilige Cloud Gegenereerd: $(Get-Date -Format 'yyyy-MM-dd HH:mm:ss') OVERZICHT ======== Totaal Azure Applications: $($result.TotalResources) Compliant: $($result.CompliantCount) Non-Compliant: $($result.NonCompliantCount) BEVINDINGEN =========== "@ if ($result.AppServiceIssues.Count -gt 0) { $reportContent += @" APP SERVICES ZONDER ENTRA ID AUTHENTICATIE ------------------------------------------ Aantal App Services: $($result.AppServiceIssues.Count) "@ foreach ($issue in $result.AppServiceIssues) { $reportContent += "- $($issue.AppName) (ResourceGroup: $($issue.ResourceGroup))`n" } $reportContent += @" AANBEVELING: Configureer Microsoft Entra ID authenticatie voor alle App Services die API's aanbieden. Dit zorgt voor token-gebaseerde authenticatie en autorisatie via OAuth2/OpenID Connect. "@ } if ($result.ManagedIdentityIssues.Count -gt 0) { $reportContent += @" APPLICATIONS ZONDER MANAGED IDENTITY ------------------------------------ Aantal Applications: $($result.ManagedIdentityIssues.Count) "@ foreach ($issue in $result.ManagedIdentityIssues) { $reportContent += "- $($issue.AppName) (ResourceGroup: $($issue.ResourceGroup))`n" } $reportContent += @" AANBEVELING: Configureer managed identities voor alle Azure Applications voor veilige service-to-service authenticatie zonder hardcoded credentials. "@ } $reportContent += @" ALGEMENE AANBEVELINGEN ====================== 1. Configureer Microsoft Entra ID authenticatie voor alle App Services die API's aanbieden 2. Implementeer managed identities voor service-to-service authenticatie 3. Configureer tokenvalidatie en autorisatie policies voor alle API endpoints 4. Implementeer fijnmazige autorisatie op basis van RBAC en app-rollen 5. Configureer uitgebreide logging en monitoring voor authenticatie- en autorisatieactiviteiten 6. Gebruik conditional access policies voor context-afhankelijke toegangsbeslissingen 7. Documenteer authenticatie- en autorisatiearchitectuur en patronen NEXT STEPS ========== 1. Review dit rapport met het Security en Development team 2. Prioriteer implementatie van Entra ID authenticatie voor kritieke applicaties 3. Plan implementatie van managed identities voor alle Azure Applications 4. Configureer logging en monitoring voor authenticatie- en autorisatieactiviteiten 5. Documenteer gekozen authenticatie- en autorisatiepatronen in architectuurdocumentatie "@ try { $reportContent | Out-File -FilePath $reportPath -Encoding UTF8 Write-Host " ✅ Rapport gegenereerd: $reportPath" -ForegroundColor Green Write-Host "`nOpen het rapport voor gedetailleerde aanbevelingen" -ForegroundColor Cyan } catch { Write-Host " ✗ Kon rapport niet genereren: $_" -ForegroundColor Red } Write-Host "`n✅ Remediatie-rapport gegenereerd" -ForegroundColor Green exit 0 } # ============================================================================ # MAIN EXECUTION # ============================================================================ try { Write-Host "`n========================================" -ForegroundColor Cyan Write-Host "API Authenticatie en Autorisatie Monitoring" -ForegroundColor Cyan Write-Host "Nederlandse Baseline voor Veilige Cloud" -ForegroundColor Cyan Write-Host "========================================`n" -ForegroundColor Cyan Connect-RequiredServices if ($Monitoring) { Invoke-Monitoring } elseif ($Remediation) { if ($WhatIf) { Write-Host "`n=== WHATIF MODE ===" -ForegroundColor Yellow Write-Host "Zou verbeteringsrapport genereren voor: $PolicyName" -ForegroundColor Yellow Write-Host "===================`n" -ForegroundColor Yellow } else { Invoke-Remediation } } else { $result = Test-Compliance Write-Host "`n========================================" -ForegroundColor Cyan Write-Host "Compliance Check: $PolicyName" -ForegroundColor Cyan Write-Host "========================================" -ForegroundColor Cyan if ($result.IsCompliant) { Write-Host "Status: [OK] COMPLIANT" -ForegroundColor Green Write-Host "Alle Azure Applications voldoen aan authenticatie- en autorisatie best practices" -ForegroundColor Green } else { Write-Host "Status: [WARNING] VERBETERING AANBEVOLEN" -ForegroundColor Yellow Write-Host "Aantal Applications met verbeterpunten: $($result.NonCompliantCount)" -ForegroundColor Yellow Write-Host "`nRun met -Monitoring voor gedetailleerd rapport" -ForegroundColor Cyan Write-Host "Run met -Remediation om verbeteringsrapport te genereren" -ForegroundColor Cyan } return $result } } catch { Write-Error "Error: $_" Write-Error $_.ScriptStackTrace exit 1 } finally { Write-Host "`n========================================`n" -ForegroundColor Cyan }

Risico zonder implementatie

Risico zonder implementatie
High: Zonder gestandaardiseerde authenticatie en autorisatie blijven Azure Applications kwetsbaar voor ongeautoriseerde toegang. Hardcoded credentials, gedeelde API-keys, ontbrekende tokenvalidatie en gebrek aan fijnmazige autorisatiecontroles maken het mogelijk voor aanvallers om toegang te krijgen tot gevoelige gegevens en kritieke systemen. Dit leidt tot verhoogd risico op datalekken, verstoringen van dienstverlening en non-compliance met BIO, AVG en NIS2-vereisten. Daarnaast maakt gebrek aan audit logging het onmogelijk om te verifiëren wie wanneer toegang heeft gehad, wat auditors ertoe brengt compliance-failures te rapporteren en kan leiden tot toezichtsancties.

Management Samenvatting

Veilige authenticatie en autorisatie voor Azure Applications vormen de basis van API-beveiliging en vereisen integratie met Microsoft Entra ID, implementatie van OAuth2 en OpenID Connect voor token-gebaseerde authenticatie, fijnmazige autorisatiecontroles op basis van RBAC en app-rollen, gebruik van managed identities voor service-to-service communicatie, uitgebreide tokenvalidatie en -cache, en comprehensive logging en monitoring voor audit doeleinden. Deze aanpak waarborgt dat alleen geautoriseerde identiteiten toegang krijgen tot API's en resources, voldoet aan BIO, ISO 27001 en NIS2-vereisten, en minimaliseert risico's op beveiligingsincidenten en datalekken. Implementatie: 200 uur. Kritiek voor alle productie Azure Applications die API's aanbieden.