Azure App Service: Authenticatie Inschakelen Via Microsoft Entra ID

Het ontwikkelen en onderhouden van aangepaste authenticatiecode vormt een aanzienlijk beveiligingsrisico voor organisaties. Veelvoorkomende problemen bij zelfgebouwde authenticatiesystemen omvatten fouten in het beheer van inloggegevens waardoor referenties kunnen lekken, kwetsbaarheden in sessiebeheer die sessiekaping mogelijk maken, onveilige wachtwoordopslag zonder correcte hashing en salting, het ontbreken van ondersteuning voor meervoudige authenticatie waardoor accounts kwetsbaar blijven voor diefstal van inloggegevens, en geen mogelijkheid om beleidsregels voor voorwaardelijke toegang af te dwingen zoals locatie- of apparaat-gebaseerde toegangscontroles. Deze zelfgebouwde systemen vereisen ook continue aandacht voor beveiligingsupdates en patches, wat kostbaar en foutgevoelig is. App Service Authentication elimineert deze risico's door een volledig door Microsoft beheerde authenticatielaag te bieden. EasyAuth biedt naadloze integratie met Microsoft Entra ID voor gecentraliseerd identiteitsbeheer, automatische tokenvernieuwing zonder dat ontwikkelaars hiervoor code hoeven te schrijven, volledige ondersteuning voor meervoudige authenticatie die direct wordt afgedwongen, afdwinging van beleidsregels voor voorwaardelijke toegang zoals risicogebaseerde toegangscontroles, en vooral: geen authenticatiecode meer in de applicatie zelf, wat het aanvalsoppervlak drastisch verkleint en de onderhoudslast elimineert. Voor organisaties met compliance-vereisten zoals ISO 27001, NIS2 of de AVG is deze beheerde authenticatie vaak een voorwaarde om aan te tonen dat authenticatieprocessen op een gecontroleerde en geauditeerde manier plaatsvinden.

Implementatie

Deze maatregel implementeert App Service Authentication voor Azure App Services en Function Apps. De implementatie kan eenvoudig worden uitgevoerd via de Azure Portal of geautomatiseerd via PowerShell voor bulk-implementatie. Voor elke App Service wordt de authenticatiefunctie ingeschakeld en geconfigureerd met Microsoft Entra ID als identiteitsprovider. De configuratie omvat het aanmaken of selecteren van een app-registratie in Entra ID die fungeert als de OAuth2/OpenID Connect-applicatie, het instellen van authenticatievereisten zoals het verplicht stellen van authenticatie voor alle verzoeken, de keuze hoe om te gaan met niet-geauthenticeerde verzoeken (HTTP 401 Onbevoegd voor API's of HTTP 302 Doorverwijzing naar de aanmeldpagina voor web-apps), en optioneel het inschakelen van tokenopslag voor web-applicaties. De grote voordelen van deze aanpak zijn dat er geen codewijzigingen nodig zijn in de applicatie zelf - authenticatie wordt afgehandeld door het Azure-platform voordat verzoeken de applicatie bereiken, authenticatie wordt volledig beheerd door Azure zonder dat u beveiligingsupdates hoeft te implementeren, volledige Microsoft Entra ID-functionaliteit direct beschikbaar is inclusief meervoudige authenticatie en voorwaardelijke toegang, automatisch tokenbeheer en sessiebeheer plaatsvindt zonder eigen code, en gebruikers een vertrouwde Microsoft-aanmeldervaring krijgen. Na implementatie kunnen gebruikers alleen toegang krijgen tot de applicatie na succesvolle authenticatie via hun organisatie-account, waarbij alle beveiligingsmaatregelen die in Entra ID zijn geconfigureerd (zoals meervoudige authenticatie-vereisten of locatiebeperkingen) automatisch worden afgedwongen.

Vereisten

Voor het succesvol implementeren van App Service Authentication moeten organisaties beschikken over een aantal technische en organisatorische vereisten. Deze vereisten vormen de basis voor een veilige en effectieve implementatie van authenticatie binnen de Azure App Service omgeving. Het begrijpen en voorbereiden van deze vereisten voorkomt implementatieproblemen en zorgt voor een soepele overgang naar een beveiligde authenticatie-infrastructuur. De primaire technische vereiste betreft de beschikbaarheid van een Azure App Service instantie. Voor productie workloads is het essentieel dat de Basic tier of hoger wordt gebruikt, omdat de Free en Shared tiers beperkingen hebben die niet geschikt zijn voor productie-omgevingen. De Basic tier biedt voldoende resources en betrouwbaarheid voor bedrijfskritieke applicaties, terwijl Standard en Premium tiers aanvullende voordelen bieden zoals betere prestaties, schaalbaarheid en geavanceerde beveiligingsfuncties. Een tweede kritieke vereiste is de aanwezigheid van een Azure AD of Microsoft Entra ID tenant met actieve gebruikersaccounts. Deze tenant vormt de basis voor identiteitsbeheer en authenticatie. Zonder een functionerende Entra ID tenant kan App Service Authentication niet worden geconfigureerd, omdat alle authenticatieverzoeken worden afgehandeld via deze centrale identiteitsprovider. Organisaties moeten ervoor zorgen dat hun Entra ID tenant correct is geconfigureerd en dat gebruikersaccounts beschikbaar zijn voor de applicaties die authenticatie vereisen. De App Registration in Azure AD is een essentieel onderdeel van de authenticatieconfiguratie. Het goede nieuws is dat deze registratie automatisch kan worden aangemaakt tijdens het configuratieproces via de Azure Portal, wat de implementatie aanzienlijk vereenvoudigt. De automatische aanmaak zorgt ervoor dat alle benodigde OAuth2 en OpenID Connect instellingen correct worden geconfigureerd, inclusief de juiste redirect URIs en toepassingsmachtigingen. Voor organisaties die meer controle willen over de App Registration kan deze ook handmatig worden aangemaakt, wat meer flexibiliteit biedt voor complexe scenario's. Vanuit een beveiligingsperspectief zijn specifieke Azure RBAC-machtigingen vereist voor het configureren van App Service Authentication. De persoon of service principal die de configuratie uitvoert moet minimaal Contributor rechten hebben op de App Service resource zelf. Dit stelt hen in staat om de authenticatie-instellingen te wijzigen en de benodigde configuraties toe te passen. Voor het configureren van de Azure AD-componenten, zoals het aanmaken of wijzigen van App Registrations, zijn aanvullende rechten nodig: minimaal de rol van Global Reader voor het bekijken van configuraties, of de rol van Application Administrator voor het volledig beheren van App Registrations. Voor organisaties die gebruik maken van aangepaste domeinnamen in plaats van de standaard Azure-domeinen, is correcte DNS-configuratie een belangrijke vereiste. De DNS-records moeten correct zijn geconfigureerd om te verwijzen naar de App Service, en de domeinnaam moet worden gevalideerd binnen Azure. Deze configuratie is vooral belangrijk voor productie-omgevingen waar professionele domeinnamen worden gebruikt die aansluiten bij de organisatie-identiteit. Ten slotte is een geldig SSL/TLS certificaat vereist voor productie-omgevingen om HTTPS-verbindingen te garanderen. Dit certificaat kan worden verkregen via Azure App Service Managed Certificates, Let's Encrypt, of externe certificaatautoriteiten. HTTPS is niet alleen een best practice voor beveiliging, maar ook een vereiste voor OAuth2 en OpenID Connect authenticatieflows, die beide afhankelijk zijn van beveiligde verbindingen om tokens veilig uit te wisselen.

Implementatie

Gebruik PowerShell-script app-service-authentication-enabled.ps1 (functie Invoke-Monitoring) – Controleert of App Service Authentication is ingeschakeld voor alle App Services in het abonnement.

**FASE 1: Applicatie-inventaris en Authenticatievereisten Bepalen (Duur: 1-2 uur)** De eerste fase van de implementatie begint met een grondige inventarisatie van alle Azure App Services binnen het abonnement. Deze inventarisatie kan worden uitgevoerd via de Azure Portal door te navigeren naar de App Services sectie, of geautomatiseerd via PowerShell met behulp van de opdracht Get-AzWebApp gevolgd door Select-Object om de relevante eigenschappen zoals naam, resourcegroep, locatie en status te extraheren. Deze inventarisatie vormt de basis voor alle verdere beslissingen en zorgt ervoor dat geen enkele applicatie over het hoofd wordt gezien. Na de inventarisatie volgt een cruciale categorisatie van alle applicaties op basis van hun authenticatievereisten en beveiligingsniveau. Interne bedrijfsapplicaties zoals HR-portals en beheerdersdashboards vereisen verplicht authenticatie, omdat deze systemen vaak toegang bieden tot gevoelige personeelsgegevens en bedrijfskritieke functionaliteiten. Klantapplicaties met gebruikersaccounts hebben eveneens verplicht authenticatie nodig om te voorkomen dat onbevoegden toegang krijgen tot klantgegevens. Publieke API's die gebruik maken van API-sleutels kunnen authenticatie als optioneel beschouwen wanneer deze worden beveiligd via Azure API Management, dat een extra beveiligingslaag biedt. Marketing websites zonder gevoelige functionaliteit kunnen authenticatie als optioneel beschouwen, hoewel dit per organisatie kan verschillen op basis van compliance-vereisten. Voor elke applicatie die authenticatie vereist, moet gedetailleerde documentatie worden opgesteld. Deze documentatie moet de primaire gebruikersgroep beschrijven die toegang nodig heeft, het data-gevoeligheidsniveau classificeren volgens de organisatorische data-classificatiestandaarden, alle relevante compliance-vereisten vastleggen zoals AVG, NIS2 of ISO 27001, en bestaande authenticatiemechanismen documenteren die mogelijk moeten worden gemigreerd of vervangen. Deze documentatie is essentieel voor het plannen van de implementatie en het verkrijgen van goedkeuring van belanghebbenden. De prioritering van de implementatie moet gebaseerd zijn op risico-analyse. Applicaties met het hoogste risico, zoals beheerdersportals en systemen die gevoelige gegevens verwerken, moeten als eerste worden geïmplementeerd. Deze prioritering minimaliseert de blootstellingstijd van kwetsbare systemen en zorgt ervoor dat de meest kritieke beveiligingsgaten als eerste worden gedicht. Na de hoog-risico applicaties volgen productie-applicaties met normale gevoeligheid, en uiteindelijk ontwikkel- en testomgevingen, die doorgaans minder kritiek zijn maar nog steeds beveiliging vereisen. Communicatie met applicatie-eigenaren en ontwikkelteams is cruciaal voor een succesvolle implementatie. Deze belanghebbenden moeten op de hoogte worden gebracht van de aankomende wijzigingen, de verwachte impact op gebruikers, en eventuele downtime-vensters die nodig zijn voor de implementatie. Vroege communicatie voorkomt verrassingen en zorgt voor een soepele overgang waarbij alle partijen voorbereid zijn op de nieuwe authenticatievereisten.

**FASE 2: App Service Authentication Inschakelen via Azure Portal (Duur: 30 minuten per applicatie)** De tweede fase omvat het daadwerkelijk inschakelen en configureren van App Service Authentication voor elke applicatie. Het proces begint met navigatie naar de Azure Portal, waar de specifieke App Service wordt geselecteerd uit de lijst van beschikbare services. Eenmaal in de App Service-overzichtspagina, bevindt de authenticatieconfiguratie zich in het linker menu onder de sectie Settings, waar de optie 'Authentication' beschikbaar is. Wanneer authenticatie nog niet is ingeschakeld, toont de interface de melding 'No identity providers configured', wat aangeeft dat er nog geen authenticatie is geconfigureerd. Het toevoegen van een identity provider begint met het klikken op de knop 'Add identity provider', waarna een lijst met beschikbare providers wordt getoond. Voor de meeste organisaties is 'Microsoft' (Azure AD) de juiste keuze, omdat dit naadloos integreert met de bestaande Microsoft Entra ID-infrastructuur. De configuratie van de identity provider vereist verschillende belangrijke keuzes. Het tenant type moet worden ingesteld op 'Workforce' (current tenant) voor interne bedrijfsapplicaties, wat ervoor zorgt dat alleen gebruikers binnen de eigen organisatie toegang krijgen. Voor de App Registration wordt aanbevolen om te kiezen voor 'Create new app registration', omdat dit automatisch de Azure AD-registratie aanmaakt met alle correcte redirect URIs en toepassingsmachtigingen, wat implementatiefouten voorkomt. De ondersteunde accounttypen moeten worden ingesteld op 'Single tenant' voor bedrijfsapplicaties die alleen toegankelijk moeten zijn voor de eigen organisatie, of 'Multitenant' wanneer partnerorganisaties ook toegang moeten krijgen. De authenticatie-instellingen bepalen hoe het systeem omgaat met niet-geauthenticeerde verzoeken. De optie 'Restrict access' moet worden ingesteld op 'Require authentication' om alle niet-geauthenticeerde verzoeken te blokkeren, wat de hoogste beveiliging biedt. Voor niet-geauthenticeerde verzoeken zijn er twee opties: 'HTTP 302 Found redirect' voor webapplicaties, wat gebruikers automatisch doorstuurt naar de Azure AD-loginpagina, of 'HTTP 401 Unauthorized' voor REST API's, wat een standaard HTTP-authenticatiefout retourneert die API-clients kunnen afhandelen. De token store moet worden ingeschakeld voor webapplicaties om server-side token caching mogelijk te maken, wat de prestaties verbetert, maar moet worden uitgeschakeld voor stateless API's die geen server-side sessies gebruiken. Na het klikken op 'Add' slaat Azure de configuratie op en voert automatisch verschillende achtergrondtaken uit. Deze taken omvatten het aanmaken van de App Registration in Azure AD met alle benodigde OAuth2-configuraties, het genereren en veilig opslaan van een OAuth client secret, en het installeren en configureren van de EasyAuth middleware in de App Service, die alle inkomende verzoeken onderschept en authenticatie afdwingt voordat verzoeken de applicatie bereiken. Validatie van de implementatie is essentieel om te verifiëren dat alles correct werkt. Door te navigeren naar de applicatie-URL moet de gebruiker automatisch worden doorgestuurd naar de Azure AD-loginpagina wanneer niet is ingelogd. Na succesvolle authenticatie moet de applicatie volledig toegankelijk zijn, en de gebruiker moet de verwachte functionaliteit kunnen gebruiken. Deze validatie moet worden uitgevoerd met verschillende gebruikersaccounts en verschillende browsers om te zorgen dat alle scenario's correct werken.

**FASE 3: Multi-Factor Authentication en Voorwaardelijke Toegang (Duur: 1 uur)** De derde fase richt zich op het configureren van geavanceerde beveiligingsmaatregelen die verder gaan dan basisauthenticatie. Het is belangrijk om te begrijpen dat Multi-Factor Authentication en Conditional Access worden geconfigureerd in Azure AD zelf, niet binnen de App Service-configuratie. App Service Authentication respecteert automatisch alle Azure AD-beleidsregels, wat betekent dat zodra deze zijn geconfigureerd in Entra ID, ze automatisch worden toegepast op alle App Services die EasyAuth gebruiken. Deze architectuur zorgt voor centrale beveiligingscontrole en consistentie voor alle applicaties. Het aanmaken van een Conditional Access-beleid begint in de Azure Portal door te navigeren naar Azure Active Directory, gevolgd door de sectie Security en vervolgens Conditional Access, waar de optie 'New policy' beschikbaar is. Binnen de policy-assignments moet eerst worden bepaald welke gebruikersgroepen toegang moeten hebben tot de applicatie. Deze groepen kunnen worden geselecteerd op basis van afdeling, functie, of andere organisatorische criteria. Vervolgens moet de cloud-app worden geselecteerd, waarbij de App Registration die door EasyAuth is aangemaakt moet worden gekozen. In de access controls sectie moet onder Grant de optie 'Require multi-factor authentication' worden geselecteerd, wat ervoor zorgt dat gebruikers naast hun wachtwoord ook een tweede authenticatiefactor moeten verifiëren. Ten slotte moet de policy state worden ingeschakeld door deze op 'On' te zetten, waarna het beleid actief wordt. Voor organisaties die extra beveiliging willen, kan device compliance worden vereist door in de Grant-sectie de optie 'Require device to be marked as compliant' te selecteren. Deze instelling zorgt ervoor dat alleen apparaten die worden beheerd door Microsoft Intune en als compliant zijn gemarkeerd toegang krijgen tot de applicatie. Dit voorkomt dat onbeheerde of niet-geconfigureerde apparaten toegang krijgen, zelfs wanneer de gebruiker correct is geauthenticeerd. Deze maatregel is vooral waardevol voor organisaties die werken met gevoelige gegevens en strenge beveiligingsvereisten hebben. Locatiegebaseerde restricties bieden aanvullende beveiliging door toegang te blokkeren vanaf niet-vertrouwde locaties. Deze configuratie wordt ingesteld in de Conditions-sectie onder Locations, waar specifieke landen, regio's of IP-adresbereiken kunnen worden gedefinieerd als vertrouwd of geblokkeerd. Organisaties kunnen bijvoorbeeld toegang blokkeren vanaf alle locaties behalve het bedrijfsnetwerk en geautoriseerde VPN-verbindingen, wat de kans op ongeautoriseerde toegang vanaf externe of verdachte locaties aanzienlijk vermindert. Risicogebaseerd blokkeren vereist Azure AD Premium P2 en maakt gebruik van Identity Protection om verdachte aanmeldingsactiviteiten te detecteren. In de Conditions-sectie kan onder Sign-in risk worden gekozen voor High of Medium risiconiveaus, waarbij het systeem automatisch aanmeldingspogingen blokkeert die kenmerken vertonen van gecompromitteerde referenties, anonieme IP-adressen, of andere verdachte patronen. In de Grant-sectie kan worden ingesteld dat gebruikers bij verdachte aanmeldingen hun wachtwoord moeten wijzigen voordat toegang wordt verleend, wat de impact van mogelijke credential theft minimaliseert. De totale implementatietijd bedraagt ongeveer 2 tot 3 uur per applicatie voor een volledige EasyAuth-configuratie inclusief grondig testen. Voor bulk-deployment over meerdere applicaties, bijvoorbeeld 10 applicaties, kan met geautomatiseerde scripts de totale tijd worden teruggebracht tot 5 tot 10 uur, afhankelijk van de complexiteit en het aantal configuratievariabelen. Wat betreft kosten is EasyAuth volledig gratis en inbegrepen in alle App Service-tiers. Voor Conditional Access is Azure AD Premium P1 vereist tegen een kosten van ongeveer 5 euro per gebruiker per maand, terwijl Azure AD Premium P2, dat nodig is voor Identity Protection en risicogebaseerd blokkeren, ongeveer 8 euro per gebruiker per maand kost.

Monitoring en Controle

Gebruik PowerShell-script app-service-authentication-enabled.ps1 (functie Invoke-Monitoring) – Monitoring script controleert periodiek de authenticatiestatus van alle App Services.

Continue monitoring van App Service Authentication is essentieel om te zorgen dat de beveiligingsmaatregelen effectief blijven en dat nieuwe risico's tijdig worden gedetecteerd. Een uitgebreide monitoringstrategie omvat meerdere lagen van controle die samen een compleet beeld geven van de authenticatiestatus en beveiligingspostuur van alle App Services binnen de organisatie. De basis van de monitoringstrategie wordt gevormd door dagelijkse geautomatiseerde scans van alle App Services om de authenticatiestatus te verifiëren. Deze scans kunnen worden uitgevoerd via PowerShell-scripts die periodiek worden gedraaid, bijvoorbeeld via Azure Automation of een geplande taak. De scripts controleren of authenticatie is ingeschakeld voor elke App Service, of de configuratie correct is, en of er wijzigingen zijn aangebracht die mogelijk de beveiliging hebben aangetast. Deze dagelijkse controles zorgen ervoor dat eventuele configuratiefouten of onbedoelde wijzigingen snel worden gedetecteerd voordat ze kunnen worden uitgebuit. Azure Policy biedt een krachtige manier om automatisch te handhaven dat alle nieuwe App Services authenticatie vereisen. Door een policy-assignment te maken die controleert of authenticatie is ingeschakeld, kunnen organisaties ervoor zorgen dat ontwikkelaars en beheerders niet per ongeluk App Services kunnen aanmaken zonder authenticatie. Deze policy kan worden geconfigureerd om automatisch remediatie uit te voeren, waarbij nieuwe App Services zonder authenticatie automatisch worden geconfigureerd met de juiste authenticatie-instellingen, of om waarschuwingen te genereren wanneer niet-compliant resources worden gedetecteerd. Azure Security Center, nu bekend als Microsoft Defender for Cloud, biedt ingebouwde aanbevelingen voor App Service Authentication. Deze aanbevelingen worden automatisch gegenereerd wanneer App Services worden gedetecteerd zonder authenticatie, en worden weergegeven in het Security Center-dashboard. Organisaties moeten deze aanbevelingen regelmatig monitoren en actie ondernemen wanneer nieuwe aanbevelingen verschijnen. Het Security Center biedt ook een secure score die de algehele beveiligingspostuur weergeeft, waarbij App Services zonder authenticatie een negatieve impact hebben op deze score. Proactieve alerting is cruciaal voor het tijdig detecteren van nieuwe App Services die zonder authenticatie worden aangemaakt. Deze alerts kunnen worden geconfigureerd via Azure Monitor en moeten worden ingesteld om onmiddellijk te waarschuwen wanneer een nieuwe App Service wordt gedetecteerd zonder authenticatieconfiguratie. De alerts kunnen worden doorgestuurd naar beveiligingsteams via e-mail, SMS, of integratie met incident management systemen zoals ServiceNow of Jira, zodat snelle actie kan worden ondernomen. Periodieke access reviews van app registrations vormen een belangrijk onderdeel van de continue monitoring. Minstens maandelijks moeten organisaties alle App Registrations die worden gebruikt voor App Service Authentication controleren om te verifiëren dat ze nog steeds nodig zijn, dat de machtigingen correct zijn geconfigureerd, en dat er geen onbevoegde wijzigingen zijn aangebracht. Deze reviews helpen bij het identificeren van zombie-applicaties die niet meer worden gebruikt maar nog steeds actief zijn, wat onnodige blootstelling creëert. Het monitoren van authenticatielogs in Azure AD sign-in logs is essentieel voor het detecteren van anomalieën en mogelijke aanvallen. Deze logs bevatten gedetailleerde informatie over elke authenticatiepoging, inclusief de gebruiker, het apparaat, de locatie, en het resultaat van de authenticatie. Door deze logs regelmatig te analyseren kunnen organisaties verdachte patronen identificeren, zoals meerdere mislukte authenticatiepogingen van dezelfde gebruiker, authenticatiepogingen vanaf onbekende locaties, of ongebruikelijke toegangstijden. Azure Sentinel of andere SIEM-oplossingen kunnen worden gebruikt om deze logs te analyseren en automatisch waarschuwingen te genereren bij verdachte activiteiten. Het bijhouden van mislukte authenticatiepogingen is bijzonder belangrijk voor het detecteren van brute force-aanvallen en credential stuffing-pogingen. Wanneer een ongebruikelijk hoog aantal mislukte pogingen wordt gedetecteerd, kan dit wijzen op een gerichte aanval tegen een specifieke gebruiker of applicatie. Deze informatie moet worden gebruikt om aanvullende beveiligingsmaatregelen te implementeren, zoals het tijdelijk blokkeren van verdachte IP-adressen of het vereisen van extra authenticatiefactoren voor getroffen accounts. Een centraal dashboard met realtime compliance-status voor alle App Services biedt beveiligingsteams en management een overzichtelijk beeld van de algehele beveiligingspostuur. Dit dashboard moet de authenticatiestatus van elke App Service weergeven, compliance-scores, recent gedetecteerde problemen, en trends over tijd. Dergelijke dashboards kunnen worden gebouwd met behulp van Azure Dashboards, Power BI, of aangepaste oplossingen, en moeten regelmatig worden geraadpleegd tijdens beveiligingsreviews en managementrapportages.

Remediatie

Wanneer App Services zonder authenticatie worden gedetecteerd tijdens monitoring, moet een gestructureerd remediatieproces worden gevolgd om de beveiligingsrisico's te adresseren en compliance te herstellen. Dit proces vereist zorgvuldige analyse, planning en uitvoering om te voorkomen dat de beschikbaarheid van applicaties wordt aangetast terwijl de beveiliging wordt verbeterd.

Gebruik PowerShell-script app-service-authentication-enabled.ps1 (functie Invoke-Remediation) – Remediatie script schakelt automatisch authenticatie in voor niet-compliant App Services.

Het remediatieproces begint met de identificatie van App Services zonder authenticatie via het monitoring dashboard of geautomatiseerde scans. Deze identificatie moet worden gedocumenteerd met relevante details zoals de applicatienaam, resourcegroep, eigenaar, en de datum waarop het probleem is gedetecteerd. Deze informatie vormt de basis voor alle verdere stappen in het remediatieproces en is essentieel voor compliance-rapportage en audit trails. Een cruciale volgende stap is het bepalen of de applicatie daadwerkelijk authenticatie vereist. Niet alle App Services hebben authenticatie nodig, en het is belangrijk om onderscheid te maken tussen verschillende typen applicaties. Publieke marketing websites zonder backend-functionaliteit of gevoelige gegevens kunnen mogelijk zonder authenticatie functioneren, hoewel dit per organisatie kan verschillen op basis van compliance-vereisten. Deze beoordeling moet worden uitgevoerd in samenwerking met de applicatie-eigenaar en het beveiligingsteam om te zorgen dat de juiste beslissing wordt genomen. Voor publieke API's die momenteel geen authenticatie gebruiken, moet worden overwogen om Azure API Management te implementeren met API-sleutels als alternatieve beveiligingsmethode. API Management biedt een extra beveiligingslaag door API-sleutels te vereisen voor toegang, rate limiting te implementeren, en gedetailleerde logging en monitoring te bieden. Deze aanpak kan geschikt zijn voor API's die worden gebruikt door externe partners of publieke services, waar traditionele gebruikersauthenticatie mogelijk niet geschikt is. Voor interne bedrijfsapplicaties is de implementatie van EasyAuth met Azure AD de aanbevolen oplossing. Deze applicaties hebben doorgaans toegang tot gevoelige bedrijfsgegevens en vereisen daarom sterke authenticatie. De implementatie moet worden uitgevoerd volgens de stappen die zijn beschreven in de implementatiesectie, waarbij speciale aandacht wordt besteed aan het minimaliseren van downtime en het zorgen dat gebruikers naadloos kunnen blijven werken. Ontwikkel- en testomgevingen vormen een bijzondere uitdaging. Hoewel deze omgevingen mogelijk minder kritiek lijken dan productie-omgevingen, kunnen ze nog steeds gevoelige testdata bevatten of worden gebruikt om productieconfiguraties te testen. Organisaties moeten overwegen om authenticatie te implementeren voor deze omgevingen, of alternatief deze omgevingen te isoleren in een apart Azure-abonnement met beperkte toegang en aanvullende netwerkbeveiliging. Deze isolatie voorkomt dat ontwikkelomgevingen een toegangspunt vormen voor aanvallers. Wanneer besloten wordt om authenticatie te implementeren, moet eerst worden gecontroleerd of er al een App Registration bestaat in Azure AD voor de applicatie. Als deze niet bestaat, moet deze worden aangemaakt, hetzij automatisch via de EasyAuth-wizard in de Azure Portal, hetzij handmatig voor meer controle over de configuratie. De App Registration moet worden geconfigureerd met de juiste redirect URIs die overeenkomen met de applicatie-URL's, en de benodigde toepassingsmachtigingen moeten worden toegekend. De authenticatie-instellingen moeten zorgvuldig worden geconfigureerd met de juiste redirect URLs. Deze URLs moeten exact overeenkomen met de applicatie-URL's, inclusief het juiste protocol (HTTPS), poortnummer indien van toepassing, en pad. Onjuiste redirect URLs resulteren in authenticatiefouten en voorkomen dat gebruikers kunnen inloggen. Voor webapplicaties moet HTTP 302 redirect worden gebruikt, terwijl voor REST API's HTTP 401 Unauthorized de juiste keuze is. Na configuratie moet de authenticatieflow grondig worden getest, inclusief token refresh. Gebruikers moeten kunnen inloggen, toegang krijgen tot de applicatie, en na verloop van tijd moeten tokens automatisch worden vernieuwd zonder dat gebruikers opnieuw moeten inloggen. Deze tests moeten worden uitgevoerd met verschillende gebruikersaccounts, verschillende browsers, en verschillende apparaten om te zorgen dat alle scenario's correct werken. Sommige applicaties kunnen code-aanpassingen vereisen voor het correct afhandelen van redirects en authenticatie. Deze aanpassingen kunnen nodig zijn wanneer applicaties custom authenticatie-logica bevatten die moet worden aangepast om te werken met EasyAuth, of wanneer applicaties specifieke authenticatie-headers verwachten die door EasyAuth worden geleverd. Deze code-aanpassingen moeten worden getest in een ontwikkelomgeving voordat ze worden geïmplementeerd in productie. Voor applicaties die om legitieme bedrijfsredenen geen authenticatie kunnen gebruiken, moeten uitzonderingen worden gedocumenteerd in het compliance-register met een duidelijke business justification. Deze documentatie moet uitleggen waarom authenticatie niet mogelijk is, welke alternatieve beveiligingsmaatregelen zijn geïmplementeerd, en wanneer de situatie opnieuw zal worden beoordeeld. Deze uitzonderingen moeten regelmatig worden herzien om te zorgen dat ze nog steeds geldig zijn. Ten slotte moet de implementatie worden gepland tijdens een onderhoudsvenster om downtime te minimaliseren. Hoewel EasyAuth-implementatie doorgaans geen downtime veroorzaakt, kunnen sommige applicaties korte onderbrekingen ervaren tijdens de configuratie. Door dit te plannen tijdens een onderhoudsvenster kunnen gebruikers worden geïnformeerd en kunnen eventuele problemen worden opgelost zonder impact op de bedrijfsvoering.

Compliance en Auditing

De implementatie van App Service Authentication vormt een fundamentele beveiligingsmaatregel die direct bijdraagt aan compliance met meerdere internationaal erkende beveiligingsstandaarden en Nederlandse wet- en regelgeving. Deze maatregel adresseert specifieke controles binnen verschillende frameworks die organisaties in de publieke sector moeten naleven om te voldoen aan hun wettelijke verplichtingen en best practices voor informatiebeveiliging. Binnen het CIS Azure Foundations Benchmark framework adresseert deze maatregel specifiek Control 9.4, die vereist dat App Service authenticatie is ingesteld voor alle applicaties. Het CIS Benchmark wordt wereldwijd erkend als een van de meest uitgebreide beveiligingsrichtlijnen voor cloud-omgevingen en wordt regelmatig gebruikt door auditors en compliance-officers om de beveiligingspostuur van organisaties te beoordelen. Het niet naleven van deze controle resulteert in een negatieve beoordeling tijdens security audits en kan leiden tot vragen van toezichthouders en stakeholders over de effectiviteit van de beveiligingsmaatregelen. Voor organisaties die werken met ISO 27001:2022 certificering adresseert App Service Authentication meerdere kritieke controles binnen het informatiebeveiligingsmanagementsysteem. Control A.9.4.2 vereist de implementatie van veilige inlogprocedures die gebruikers authenticatie en autorisatie afdwingen voordat toegang wordt verleend tot informatiesystemen. Deze controle is essentieel voor het voorkomen van ongeautoriseerde toegang en vormt een basisvereiste voor elke ISO 27001-gecertificeerde organisatie. Daarnaast adresseert Control A.9.2.1 de vereisten voor gebruikersregistratie en deregistratie, waarbij App Service Authentication naadloos integreert met Microsoft Entra ID voor gecentraliseerd gebruikersbeheer en automatische provisioning en deprovisioning van toegang wanneer gebruikers de organisatie verlaten of van rol veranderen. De Europese NIS2-richtlijn, die sinds 2024 van kracht is voor essentiële en belangrijke entiteiten, vereist in Artikel 21 specifiek dat organisaties passende toegangscontrole- en authenticatiemechanismen implementeren voor hun netwerk- en informatiesystemen. App Service Authentication voldoet aan deze vereisten door sterke authenticatie af te dwingen op platformniveau, waardoor organisaties kunnen aantonen dat zij voldoen aan de technische beveiligingsmaatregelen die door NIS2 worden vereist. Voor Nederlandse organisaties die onder de reikwijdte van NIS2 vallen, zoals overheidsinstanties, zorginstellingen en kritieke infrastructuur, is deze maatregel niet alleen een best practice maar een wettelijke verplichting. Binnen het BIO-framework, dat specifiek is ontwikkeld voor de Nederlandse overheid, adresseert deze maatregel Thema 11.02 over toegangsbeheer tot systemen en toepassingen. Het BIO-framework biedt concrete richtlijnen voor overheidsorganisaties om informatiebeveiliging te implementeren volgens de Baseline Informatiebeveiliging Overheid, en App Service Authentication vormt een praktische implementatie van deze richtlijnen voor cloud-gebaseerde applicaties. De maatregel zorgt ervoor dat alleen geautoriseerde gebruikers toegang krijgen tot applicaties en dat alle toegangspogingen worden gelogd en gemonitord, wat essentieel is voor compliance met BIO-vereisten. Vanuit een applicatiebeveiligingsperspectief adresseert deze maatregel OWASP Top 10 2021 categorie A07, die zich richt op identificatie- en authenticatiefouten. OWASP identificeert zwakke authenticatie als een van de meest kritieke beveiligingsrisico's voor webapplicaties, en App Service Authentication elimineert dit risico door een platform-level authenticatielaag te bieden die is ontwikkeld en onderhouden door Microsoft, met alle bijbehorende security best practices en regelmatige security updates. Door gebruik te maken van deze beheerde oplossing voorkomen organisaties veelvoorkomende authenticatiekwetsbaarheden zoals zwakke wachtwoordbeleidsregels, onveilige sessiebeheer, en het ontbreken van multi-factor authenticatie. Voor organisaties die persoonsgegevens verwerken is de Algemene Verordening Gegevensbescherming (AVG) van cruciaal belang, en Artikel 32 vereist dat organisaties passende technische en organisatorische maatregelen implementeren om persoonsgegevens te beveiligen. App Service Authentication vormt een essentiële technische maatregel die voorkomt dat onbevoegden toegang krijgen tot systemen die persoonsgegevens bevatten. Wanneer een datalek plaatsvindt als gevolg van het ontbreken van authenticatie, kunnen organisaties worden geconfronteerd met boetes tot 20 miljoen euro of 4% van de wereldwijde jaaromzet, afhankelijk van welke waarde hoger is. Het implementeren van App Service Authentication helpt organisaties te voldoen aan de AVG-vereisten en vermindert het risico op dergelijke boetes aanzienlijk. Voor het succesvol doorstaan van compliance-audits en het aantonen van naleving van deze frameworks moeten organisaties uitgebreide auditbewijs documenteren en bewaren. Deze documentatie vormt het bewijs dat de beveiligingsmaatregelen daadwerkelijk zijn geïmplementeerd en effectief functioneren. Een eerste essentieel onderdeel van deze auditbewijzen bestaat uit schermafbeeldingen van de authenticatieconfiguratie voor elke App Service binnen de organisatie. Deze schermafbeeldingen moeten duidelijk tonen dat authenticatie is ingeschakeld, welke identity provider is geconfigureerd, en welke authenticatie-instellingen zijn toegepast. Deze visuele documentatie is bijzonder waardevol tijdens externe audits waar auditors fysiek bewijs willen zien van de implementatie. Geautomatiseerde compliance-rapporten die worden gegenereerd door monitoring scripts vormen een tweede kritiek onderdeel van de auditbewijzen. Deze rapporten moeten periodiek worden gegenereerd, idealiter wekelijks of maandelijks, en moeten een overzicht bevatten van alle App Services met hun authenticatiestatus, eventuele configuratiewijzigingen, en compliance-scores. Deze geautomatiseerde rapportage zorgt voor consistentie en volledigheid en elimineert menselijke fouten die kunnen optreden bij handmatige documentatie. De rapporten moeten worden opgeslagen in een centraal archief met versiebeheer, zodat auditors de historische ontwikkeling van de compliance-postuur kunnen volgen. Een gedetailleerde lijst van alle App Services met hun authenticatiestatus vormt een derde essentieel auditbewijs. Deze lijst moet worden bijgewerkt telkens wanneer nieuwe App Services worden aangemaakt of wanneer de authenticatieconfiguratie wordt gewijzigd. De lijst moet informatie bevatten zoals de applicatienaam, resourcegroep, eigenaar, authenticatiestatus (ingeschakeld of uitgeschakeld), datum van laatste configuratiewijziging, en eventuele uitzonderingen met bijbehorende business justification. Deze lijst dient als basis voor alle compliance-rapportage en moet regelmatig worden geverifieerd tegen de werkelijke configuratie in Azure om te zorgen dat deze accuraat blijft. App Registration configuratiedetails in Azure AD vormen een vierde kritiek onderdeel van de auditbewijzen. Deze details omvatten informatie over de OAuth2- en OpenID Connect-configuratie, redirect URIs, toepassingsmachtigingen, en gedelegeerde machtigingen. Deze informatie is essentieel voor auditors om te begrijpen hoe de authenticatie is geconfigureerd en om te verifiëren dat de configuratie voldoet aan security best practices. De configuratiedetails moeten worden gedocumenteerd op het moment van implementatie en moeten worden bijgewerkt wanneer wijzigingen worden aangebracht. Authenticatie- en autorisatielogboeken uit Azure AD vormen een vijfde essentieel auditbewijs. Deze logboeken bevatten gedetailleerde informatie over elke authenticatiepoging, inclusief de gebruiker, het apparaat, de locatie, het tijdstip, en het resultaat van de authenticatie. Deze logboeken zijn cruciaal voor het detecteren van verdachte activiteiten, het onderzoeken van beveiligingsincidenten, en het aantonen aan auditors dat de authenticatiesystemen daadwerkelijk worden gebruikt en gemonitord. De logboeken moeten worden bewaard voor minimaal de vereiste bewaartermijn zoals gespecificeerd in de compliance-frameworks, typisch minimaal één jaar maar vaak langer voor organisaties met specifieke compliance-vereisten. Aanmeldlogboeken met succesvolle en mislukte authenticatiepogingen vormen een zesde kritiek onderdeel van de auditbewijzen. Deze logboeken bieden inzicht in de effectiviteit van de authenticatie-implementatie en helpen bij het identificeren van potentiële beveiligingsproblemen zoals brute force-aanvallen of credential stuffing-pogingen. Auditors gebruiken deze logboeken om te verifiëren dat de authenticatiesystemen correct functioneren en dat er adequate monitoring plaatsvindt. De logboeken moeten regelmatig worden geanalyseerd en eventuele anomalieën moeten worden gedocumenteerd en onderzocht. Een uitzonderingsregister voor applicaties zonder authenticatie met business justification vormt een zevende essentieel auditbewijs. Niet alle App Services hebben authenticatie nodig, en het is belangrijk om deze uitzonderingen te documenteren met een duidelijke business justification die uitlegt waarom authenticatie niet mogelijk of niet nodig is. Dit register helpt auditors te begrijpen dat de organisatie bewust heeft nagedacht over welke applicaties authenticatie vereisen en welke niet, en dat uitzonderingen niet het gevolg zijn van nalatigheid maar van weloverwogen beslissingen. Het register moet regelmatig worden herzien om te zorgen dat uitzonderingen nog steeds geldig zijn en dat nieuwe alternatieve beveiligingsmaatregelen kunnen worden geïmplementeerd. Periodieke toegangsbeoordelingen van app-registraties en machtigingen vormen een achtste kritiek onderdeel van de auditbewijzen. Deze beoordelingen moeten minstens jaarlijks plaatsvinden, maar voor organisaties met hoge beveiligingsvereisten wordt maandelijks of driemaandelijks aanbevolen. De beoordelingen moeten verifiëren dat alle app-registraties nog steeds nodig zijn, dat de machtigingen correct zijn geconfigureerd en niet te breed zijn, en dat er geen onbevoegde wijzigingen zijn aangebracht. De resultaten van deze beoordelingen moeten worden gedocumenteerd en eventuele geïdentificeerde problemen moeten worden gecorrigeerd en gedocumenteerd. Change management tickets voor authenticatie-implementaties vormen een negende essentieel auditbewijs. Deze tickets documenteren het volledige proces van planning tot implementatie van App Service Authentication, inclusief de reden voor de implementatie, de betrokken partijen, de geteste scenario's, en de goedkeuringen die zijn verkregen. Deze documentatie is waardevol voor auditors om te begrijpen hoe de organisatie change management hanteert en om te verifiëren dat wijzigingen worden uitgevoerd volgens gecontroleerde processen. De tickets moeten worden bewaard voor de volledige bewaartermijn zoals gespecificeerd in het change management beleid van de organisatie. Al deze auditbewijzen moeten worden bewaard voor minimaal de vereiste bewaartermijn zoals gespecificeerd in de relevante compliance-frameworks. Voor de meeste frameworks is dit minimaal één jaar, maar voor organisaties met specifieke compliance-vereisten zoals financiële dienstverlening of gezondheidszorg kan dit aanzienlijk langer zijn, vaak tot zeven jaar of langer. De documentatie moet worden opgeslagen in een centraal archief met versiebeheer en toegangscontrole om te zorgen dat deze veilig en toegankelijk blijft voor auditors wanneer nodig.

Compliance & Frameworks

• CIS M365: Control 9.4 (L1) - Zorg ervoor dat App Service authentication is ingesteld voor apps
• BIO: 11.02.01, 11.02.02 - Toegangsbeheer tot systemen en toepassingen - gebruikersregistratie en authenticatie
• ISO 27001:2022: A.9.4.2, A.9.2.1 - Veilige inlogprocedures en gebruikersregistratie
• NIS2: Artikel - Toegangscontrole en authenticatiemechanismen voor netwerk- en informatiesystemen

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

App Service Authentication (EasyAuth) is een authenticatielaag op platformniveau die Azure AD-identiteitsbeheer integreert in App Service zonder applicatiecodewijzigingen. EasyAuth onderschept alle inkomende HTTP-verzoeken voordat ze de applicatie bereiken en dwingt Azure AD-authenticatie af, wat betekent dat gebruikers automatisch worden doorgestuurd naar Azure AD-aanmelding indien niet geauthenticeerd, eenmalige aanmelding wordt geboden voor gebruikers die al zijn ingelogd op Azure AD in hun browser, en meervoudige authenticatie automatisch wordt afgedwongen als geconfigureerd in Azure AD (inclusief Authenticator-app, SMS, hardwaretokens). Beleidsregels voor voorwaardelijke toegang worden volledig ondersteund waarbij riskante aanmeldingen van verdachte locaties, niet-conforme apparaten of anonieme VPN's automatisch worden geblokkeerd, apparaatcompliance kan worden vereist zodat alleen door Intune beheerde bedrijfsapparaten toegang krijgen, en Identity Protection-risicosignalen zoals gecompromitteerde referenties direct blokkeren. Tokenbeheer wordt geautomatiseerd afgehandeld door het platform waarbij OAuth-tokens worden beheerd, geroteerd en gevalideerd zonder betrokkenheid van ontwikkelaars. Deze maatregel is verplicht voor alle productie App Services met gevoelige data, bedrijfslogica of interne functionaliteit (geen uitzonderingen), vereist voor compliance met CIS Azure Benchmark 9.1, ISO 27001, NIS2, AVG, en optioneel alleen voor volledig publieke alleen-lezen marketing websites zonder backend-functionaliteit. Vereisten: Azure AD-tenant (standaard aanwezig), app-registratie wordt automatisch aangemaakt door EasyAuth-wizard (geen handmatige configuratie nodig), en bewustzijn dat EasyAuth primair bedoeld is voor interne bedrijfsapplicaties - voor publieke consumentgerichte apps met externe gebruikers kan Azure AD B2C of aangepaste authenticatie nodig zijn. Implementatie-inspanning: 2-3 uur per applicatie voor basis EasyAuth-configuratie (identiteitsprovider setup, authenticatie-instellingen, testen), geen extra kosten (EasyAuth is gratis, inbegrepen in App Service). Doorlopende inspanning: minimaal, 1 uur per jaar voor configuratiereviews. Return on investment komt van: geëlimineerde risico's op ongeautoriseerde toegang, automatische afdwinging van meervoudige authenticatie die accountcompromittering met 99,9 procent reduceert, compliance-auditsucces, en operationele eenvoud omdat authenticatie volledig platform-beheerd is zonder ontwikkeling van aangepaste code.

• Implementatietijd: 3 uur
• FTE required: 0.03 FTE