L2 BIO 09.04 ISO A.5.17 CIS 1.38

Azure: Phishing-Resistente MFA Verplicht Stellen Voor Beheerders-accounts

📅 2025-10-29
•
⏱️ 13 minuten lezen
•
🔴 Must-Have

💼 Management Samenvatting

Phishing-resistente meervoudige authenticatie gebruikt cryptografische verificatie die niet kan worden ge-phisht, in tegenstelling tot traditionele MFA-methoden zoals SMS-codes of pushmeldingen die gevoelig zijn voor AiTM-aanvallen (Adversary-in-the-Middle). Voor geprivilegieerde accounts is phishing-resistente MFA essentieel vanwege de extreme impact van een gecompromitteerd beheerdersaccount.

Aanbeveling
IMPLEMENTEER VOOR GEPRIVILEGIEERDE ACCOUNTS
Risico zonder
Critical
Risk Score
10/10
Implementatie
20u (tech: 12u)
Van toepassing op:
✓ Azure
✓ Azure AD
✓ Entra ID

Traditionele MFA-methoden zoals SMS, spraakoproepen en pushmeldingen kunnen worden omzeild via geavanceerde phishingaanvallen. AiTM-phishingproxies kunnen MFA-codes onderscheppen en in realtime doorsturen naar aanvallers. MFA-vermoeidheidsaanvallen bombarderen gebruikers met pushmeldingen totdat ze per ongeluk goedkeuren. SIM-swapping-aanvallen stelen SMS-codes door de mobiele telefoonnummeroverdracht te manipuleren. Geprivilegieerde accounts zijn primaire doelen voor aanvallers, die extra inspanning leveren om beheerdersreferenties te phishen omdat één gecompromitteerd beheerdersaccount een volledige tenantovername mogelijk maakt. Phishing-resistente MFA zoals FIDO2, Windows Hello voor Business en certificaatgebaseerde authenticatie gebruikt publieke-sleutelcryptografie waarbij de privésleutel nooit het apparaat verlaat. Dit maakt phishing onmogelijk omdat er geen code is om te stelen die kan worden onderschept.

PowerShell Modules Vereist
Primary API: Microsoft Graph API
Connection: Connect-MgGraph
Required Modules: Microsoft.Graph.Identity.SignIns, Microsoft.Graph.Identity.DirectoryManagement

Implementatie

Deze controle vereist phishing-resistente MFA voor alle geprivilegieerde Azure AD-rollen, waaronder Globale beheerder, Beheerder van geprivilegieerde rollen, Beveiligingsbeheerder, Beheerder van voorwaardelijke toegang en andere hoog-impactrollen. Phishing-resistente methoden omvatten FIDO2-beveiligingssleutels zoals YubiKey en Microsoft Titan, die USB- of NFC-hardwaretokens zijn met cryptografische authenticatie. Windows Hello voor Business biedt biometrische of PIN-verificatie met TPM-ondersteunde privésleutels. Certificaatgebaseerde authenticatie gebruikt clientcertificaten die zijn uitgegeven door een vertrouwde certificeringsinstantie. De implementatie vereist een Conditional Access-beleid dat phishing-resistente authenticatiestrekte vereist voor leden van geprivilegieerde rollen. Gebruikers moeten FIDO2-sleutels registreren voordat het beleid wordt afgedwongen.

Vereisten

Voor een succesvolle implementatie van phishing-resistente meervoudige authenticatie voor beheerdersaccounts zijn verschillende technische en organisatorische vereisten noodzakelijk. Deze vereisten vormen de basis voor een veilige en effectieve implementatie die voldoet aan de hoogste beveiligingsstandaarden voor geprivilegieerde toegang in Azure-omgevingen.

De primaire licentievereiste betreft Azure AD Premium P1 of hoger, omdat Conditional Access-beleidsregels die authenticatiestrekte vereisen alleen beschikbaar zijn in deze licentie-edities. Zonder Premium P1 kunnen organisaties geen beleid afdwingen dat specifiek phishing-resistente authenticatiemethoden vereist. Voor grotere organisaties met uitgebreide beveiligingsbehoeften kan Azure AD Premium P2 worden overwogen, wat aanvullende functies biedt zoals Identity Protection en Privileged Identity Management die de beveiligingspostuur verder versterken.

FIDO2-beveiligingssleutels vormen de kern van phishing-resistente authenticatie voor de meeste implementaties. Organisaties moeten minimaal twee FIDO2-sleutels per beheerder aanschaffen om redundantie te garanderen. De primaire sleutel dient voor dagelijks gebruik, terwijl de back-upsleutel beschikbaar blijft voor noodsituaties zoals verlies, diefstal of defect van de primaire sleutel. Aanbevolen FIDO2-sleutels zijn de YubiKey 5-serie, Microsoft Titan-sleutels en andere FIDO2-certificeringssleutels. De kosten variëren doorgaans tussen vijftig en honderd euro per sleutel, wat betekent dat de investering voor een volledige beheerdersgroep aanzienlijk kan zijn maar essentieel is voor kritieke beveiliging.

Windows Hello voor Business biedt een alternatieve phishing-resistente authenticatiemethode die geen extra hardware vereist, maar wel specifieke apparaatvereisten heeft. Apparaten moeten Windows 10 versie 1903 of hoger draaien en beschikken over een TPM 2.0-chip. De TPM-chip slaat de privésleutel cryptografisch op en zorgt ervoor dat deze nooit het apparaat verlaat, wat de beveiliging garandeert. Organisaties moeten een Windows Hello voor Business-implementatie uitvoeren via Intune of Group Policy, waarbij biometrische verificatie of een PIN wordt geconfigureerd die is gekoppeld aan de TPM-sleutelopslag.

Apparaatcompliancebeleidsregels in Microsoft Intune zijn essentieel om ervoor te zorgen dat alleen vertrouwde apparaten toegang krijgen tot beheerdersfuncties. Deze beleidsregels moeten vereisen dat apparaten voldoen aan beveiligingsstandaarden zoals versleuteling, beveiligingsupdates en beveiligingssoftware. Voor Windows Hello voor Business-implementaties moeten compliancebeleidsregels specifiek TPM 2.0 en Windows-versievereisten afdwingen. Apparaten die niet voldoen aan deze standaarden moeten worden uitgesloten van toegang tot geprivilegieerde rollen, zelfs als de gebruiker over een geldige FIDO2-sleutel beschikt.

Een volledige inventarisatie van alle geprivilegieerde beheerdersaccounts is cruciaal voordat de implementatie begint. Organisaties moeten alle gebruikers identificeren die zijn toegewezen aan rollen zoals Globale beheerder, Beheerder van geprivilegieerde rollen, Beveiligingsbeheerder, Beheerder van voorwaardelijke toegang en andere hoog-impactrollen. Deze inventarisatie moet regelmatig worden bijgewerkt om nieuwe toewijzingen te detecteren en te zorgen dat alle geprivilegieerde accounts onder het phishing-resistente MFA-beleid vallen. Automatisering via PowerShell-scripts of Microsoft Graph API kan helpen bij het onderhouden van deze inventarisatie.

Break-glass accounts vormen een kritieke uitzondering op het phishing-resistente MFA-beleid en vereisen speciale aandacht. Deze accounts zijn bedoeld voor noodsituaties waarbij normale authenticatiemethoden niet beschikbaar zijn, zoals bij een volledige uitval van de authenticatie-infrastructuur. Break-glass accounts moeten worden beveiligd met alternatieve sterke authenticatiemethoden, zoals lange wachtwoordzinnen opgeslagen in een fysieke kluis, of tijdelijk gebruik van certificaatgebaseerde authenticatie. Deze accounts moeten strikt worden beheerd, regelmatig worden gecontroleerd en alleen worden gebruikt in gedocumenteerde noodsituaties.

Een testomgeving is essentieel voor een succesvolle pilotimplementatie voordat de volledige productieomgeving wordt uitgerold. Deze testomgeving moet een replica zijn van de productieconfiguratie, inclusief Conditional Access-beleidsregels, gebruikersaccounts en apparaatconfiguraties. De pilot moet worden uitgevoerd met een kleine groep beheerders die representatief zijn voor de volledige beheerderspopulatie, inclusief verschillende rollen, apparaten en gebruikspatronen. Tijdens de pilot moeten alle aspecten worden getest, inclusief registratie van FIDO2-sleutels, authenticatie met verschillende methoden, foutafhandeling en herstelprocedures.

Monitoring en verificatie

Gebruik PowerShell-script phishing-resistant-mfa-azure.ps1 (functie Invoke-Monitoring) – PowerShell-script voor verificatie dat phishing-resistente MFA is geconfigureerd. Vereist handmatige verificatie via Azure AD-rapportage over authenticatiemethoden..

Effectieve monitoring van phishing-resistente meervoudige authenticatie is essentieel om te garanderen dat alle geprivilegieerde beheerdersaccounts daadwerkelijk gebruikmaken van de vereiste authenticatiemethoden. Monitoring moet worden uitgevoerd via meerdere kanalen om een volledig beeld te krijgen van de implementatiestatus en om snel afwijkingen te kunnen detecteren die kunnen wijzen op beveiligingsproblemen of configuratiefouten.

De primaire monitoringlocatie bevindt zich in de Azure AD-portal onder Beveiliging, Authenticatiemethoden en Activiteit. Hier kunnen organisaties filteren op geprivilegieerde gebruikers en verifiëren welke authenticatiemethoden zijn geregistreerd. Voor elke geprivilegieerde beheerder moet worden gecontroleerd of FIDO2-beveiligingssleutels of Windows Hello voor Business correct zijn geregistreerd. Het dashboard toont registratiestatus, laatste gebruik en eventuele fouten tijdens authenticatiepogingen. Organisaties moeten wekelijks een rapport genereren dat alle geprivilegieerde accounts toont en hun authenticatiemethode-status, waarbij aandacht wordt besteed aan accounts die nog geen phishing-resistente MFA hebben geconfigureerd.

Aanmeldingslogboeken in Azure AD bieden gedetailleerde inzichten in de daadwerkelijke authenticatiemethoden die worden gebruikt tijdens aanmeldingen. Organisaties moeten regelmatig de aanmeldingslogboeken controleren voor alle geprivilegieerde gebruikers en verifiëren dat de authenticatiemethode wordt weergegeven als FIDO2 of Windows Hello voor alle aanmeldingen. Aanmeldingen die gebruikmaken van andere methoden zoals SMS, telefoonoproep of Microsoft Authenticator-app moeten worden onderzocht, omdat deze kunnen wijzen op een configuratiefout of een poging tot omzeiling van het beveiligingsbeleid. De logboeken moeten worden gefilterd op gebruikers met geprivilegieerde rollen en gesorteerd op datum om recente activiteit te identificeren.

Het streefdoel voor monitoring is dat honderd procent van de geprivilegieerde beheerders gebruikmaakt van phishing-resistente MFA voor alle aanmeldingen. Dit betekent dat elke aanmelding door een geprivilegieerde beheerder moet worden geverifieerd met FIDO2, Windows Hello voor Business of certificaatgebaseerde authenticatie. Organisaties moeten wekelijkse rapporten genereren die de nalevingspercentage tonen en trends over tijd volgen. Een daling in het nalevingspercentage kan wijzen op nieuwe beheerdersaccounts die nog niet zijn geconfigureerd, verloren of defecte FIDO2-sleutels, of configuratiefouten in Conditional Access-beleidsregels.

Automatisering van monitoring via PowerShell-scripts kan de efficiëntie aanzienlijk verbeteren en zorgen voor consistente rapportage. Scripts kunnen worden geconfigureerd om dagelijks te draaien en automatisch rapporten te genereren die worden verzonden naar beveiligingsteams en compliance-officers. Deze scripts moeten controleren op nieuwe toewijzingen van geprivilegieerde rollen, verifiëren dat nieuwe beheerders phishing-resistente MFA hebben geconfigureerd voordat ze toegang krijgen, en waarschuwingen genereren voor accounts die niet voldoen aan de vereisten. Geavanceerde scripts kunnen ook trendanalyses uitvoeren en voorspellen wanneer onderhoud of vervanging van FIDO2-sleutels nodig kan zijn.

Naast technische monitoring moeten organisaties ook organisatorische controles uitvoeren. Regelmatige audits moeten worden uitgevoerd om te verifiëren dat alle FIDO2-sleutels correct worden beheerd, dat verloren sleutels onmiddellijk worden gedeactiveerd, en dat nieuwe beheerders de juiste training hebben ontvangen over het gebruik van phishing-resistente authenticatie. Deze audits moeten worden gedocumenteerd en beschikbaar zijn voor externe auditors die compliance met normen zoals CIS, BIO en ISO 27001 verifiëren.

Implementatie

Gebruik PowerShell-script phishing-resistant-mfa-azure.ps1 (functie Invoke-Implementation) – Implementeren van phishing-resistente MFA voor geprivilegieerde accounts.

De implementatie van phishing-resistente meervoudige authenticatie voor geprivilegieerde beheerdersaccounts vereist een gefaseerde aanpak om risico's te minimaliseren en een soepele overgang te garanderen. Een gefaseerde uitrol stelt organisaties in staat om problemen vroegtijdig te identificeren en op te lossen voordat de volledige beheerderspopulatie wordt beïnvloed, terwijl het ook voldoende tijd biedt voor training en aanpassing aan nieuwe authenticatiemethoden.

De eerste fase van de implementatie betreft het inschakelen van FIDO2-beveiligingssleutels in Azure AD. Beheerders moeten navigeren naar de Azure AD-portal, Beveiliging, Authenticatiemethoden en de optie voor FIDO2-beveiligingssleutels activeren. Tijdens deze initiële configuratie moet de doelgroep worden ingesteld op een selecte groep gebruikers die de pilotgroep vormt, in plaats van alle gebruikers. Dit maakt het mogelijk om de functionaliteit te testen met een beperkte groep voordat de volledige uitrol plaatsvindt. De registratie-instelling moet worden geconfigureerd om sleutelattestatie af te dwingen, wat garandeert dat alleen gecertificeerde FIDO2-sleutels kunnen worden geregistreerd en gebruikt. Deze beveiligingsmaatregel voorkomt dat niet-gecertificeerde of mogelijk gecompromitteerde hardwaretokens worden gebruikt.

De tweede fase omvat de aanschaf en distributie van FIDO2-beveiligingssleutels. Organisaties moeten FIDO2-sleutels bestellen voor alle geprivilegieerde beheerders, waarbij minimaal twee sleutels per beheerder worden aangeschaft om redundantie te garanderen. De primaire sleutel wordt gebruikt voor dagelijkse authenticatie, terwijl de back-upsleutel beschikbaar blijft voor noodsituaties. Aanbevolen FIDO2-sleutels zijn de YubiKey 5 NFC-serie of Microsoft Titan-sleutels, die doorgaans rond de vijftig euro per stuk kosten. Voordat de volledige bestelling wordt geplaatst, moeten organisaties de compatibiliteit van de gekozen sleutels testen met de verschillende apparaten en besturingssystemen die door beheerders worden gebruikt. Sommige oudere apparaten of besturingssystemen kunnen beperkte ondersteuning hebben voor bepaalde FIDO2-sleutels, wat problemen kan veroorzaken tijdens de registratie of authenticatie.

De derde fase betreft de registratie van FIDO2-sleutels door geprivilegieerde beheerders. Sleutels moeten worden gedistribueerd aan alle beheerders in de pilotgroep, vergezeld van duidelijke instructies voor registratie. Beheerders moeten worden begeleid naar myaccount.microsoft.com, waar ze onder Beveiligingsinfo de optie kunnen selecteren om een nieuwe methode toe te voegen en vervolgens Beveiligingssleutel kiezen. Tijdens het registratieproces moeten beheerders hun FIDO2-sleutel aansluiten of via NFC verbinden en een PIN instellen die wordt gebruikt om de sleutel te activeren bij elke authenticatie. Na registratie moeten beheerders testen of authenticatie met de geregistreerde sleutel correct werkt voordat het Conditional Access-beleid wordt afgedwongen. Deze testfase voorkomt dat beheerders worden uitgesloten van toegang wanneer het beleid wordt geactiveerd.

De vierde fase omvat de configuratie van Conditional Access-beleidsregels die phishing-resistente MFA vereisen. Organisaties moeten een nieuw Conditional Access-beleid maken met de naam 'Vereis phishing-resistente MFA voor beheerders'. De gebruikersomvang moet worden ingesteld op Directory-rollen, waarbij specifiek de rol Globale beheerder en andere geprivilegieerde rollen worden geselecteerd, zoals Beheerder van geprivilegieerde rollen, Beveiligingsbeheerder en Beheerder van voorwaardelijke toegang. De cloud-apps moeten worden ingesteld op alle cloud-apps om ervoor te zorgen dat het beleid van toepassing is op alle Microsoft 365-services. Onder voorwaarden moet de authenticatiestrekte worden ingesteld op Phishing-resistente MFA, en onder Toegangscontroles moet Vereis authenticatiestrekte worden geselecteerd. Tijdens deze testfase moet de status van het beleid worden ingesteld op Alleen rapporteren, wat betekent dat het beleid wordt geëvalueerd en gerapporteerd maar nog niet wordt afgedwongen. Dit stelt organisaties in staat om te zien welke gebruikers zouden worden geblokkeerd zonder daadwerkelijk toegang te weigeren.

De vijfde fase betreft de overgang naar volledige afdwinging van het beleid. Organisaties moeten de resultaten van de rapportagefase gedurende minimaal twee weken monitoren om te identificeren welke beheerders nog geen phishing-resistente MFA hebben geconfigureerd en om eventuele configuratiefouten te detecteren. Tijdens deze monitoringperiode moeten alle problemen worden opgelost, zoals beheerders die hun FIDO2-sleutels nog niet hebben geregistreerd of die problemen ondervinden met de authenticatie. Zodra alle beheerders correct zijn geconfigureerd en eventuele problemen zijn opgelost, kan de status van het Conditional Access-beleid worden gewijzigd van Alleen rapporteren naar Aan, wat de afdwingingsmodus activeert. Na activering moeten organisaties de eerste tweeënzeventig uur intensief monitoren op accountvergrendelingen of andere toegangsproblemen die kunnen optreden wanneer beheerders proberen in te loggen zonder de vereiste authenticatiemethode.

De zesde en laatste fase omvat de uitbreiding van het beleid naar aanvullende geprivilegieerde rollen en de vastlegging van beheerprocedures. Organisaties moeten het Conditional Access-beleid geleidelijk uitbreiden naar andere geprivilegieerde rollen die aanvankelijk niet in de pilot waren opgenomen, waarbij elke uitbreiding wordt voorafgegaan door een korte testperiode. Tegelijkertijd moeten organisaties uitgebreide documentatie opstellen voor FIDO2-sleutelbeheer, inclusief procedures voor verloren sleutels, onboarding van nieuwe beheerders, vervanging van defecte sleutels en deactivering van sleutels wanneer beheerders de organisatie verlaten. Helpdeskmedewerkers moeten worden getraind in het oplossen van problemen met FIDO2-authenticatie, inclusief veelvoorkomende problemen zoals niet-herkende sleutels, PIN-vergrendelingen en compatibiliteitsproblemen met verschillende browsers of besturingssystemen. Deze training zorgt ervoor dat helpdeskmedewerkers beheerders effectief kunnen ondersteunen wanneer ze problemen ondervinden met phishing-resistente authenticatie.

Compliance en Auditing

De implementatie van phishing-resistente meervoudige authenticatie voor geprivilegieerde beheerdersaccounts draagt significant bij aan het voldoen aan verschillende nationale en internationale beveiligingsstandaarden en compliance-vereisten. Deze controle vormt een fundamenteel onderdeel van moderne zero-trust-architecturen en wordt expliciet vereist door toonaangevende beveiligingsframeworks die worden gebruikt door Nederlandse overheidsorganisaties en bedrijven in kritieke sectoren.

De CIS Azure Foundations Benchmark versie 3.0.0 specificeert in controle 1.38 dat organisaties moeten zorgen dat phishing-resistente multifactor-authenticatie wordt gebruikt voor geprivilegieerde Azure AD-rollen. Deze controle is geclassificeerd als Level 2, wat betekent dat deze wordt aanbevolen voor organisaties met verhoogde beveiligingsbehoeften. De CIS Benchmark wordt wereldwijd erkend als een toonaangevende standaard voor cloudbeveiliging en wordt vaak gebruikt als basis voor security-audits en compliance-verificaties. Organisaties die voldoen aan deze controle demonstreren dat ze de hoogste standaarden voor identiteitsbeveiliging implementeren.

De BIO Baseline Informatiebeveiliging Overheid, die de beveiligingsstandaard vormt voor Nederlandse overheidsorganisaties, vereist in Thema 09.04 het gebruik van cryptografische technieken voor authenticatie. Phishing-resistente MFA-methoden zoals FIDO2 en Windows Hello voor Business gebruiken publieke-sleutelcryptografie, wat volledig voldoet aan deze vereiste. Thema 10.01 behandelt sleutelbeheer, wat relevant is voor de beveiliging en het beheer van FIDO2-beveiligingssleutels. Nederlandse overheidsorganisaties moeten kunnen aantonen dat ze voldoen aan deze BIO-vereisten tijdens audits door de Autoriteit Persoonsgegevens of andere toezichthouders.

ISO 27001:2022, de internationale standaard voor informatiebeveiligingsmanagement, bevat verschillende controles die relevant zijn voor phishing-resistente authenticatie. Controle A.5.17 behandelt het beheer van authenticatie-informatie en vereist dat organisaties sterke authenticatiemethoden implementeren. Controle A.9.4.3 specificeert dat organisaties sterke authenticatie moeten gebruiken voor geprivilegieerde toegang tot systemen. Phishing-resistente MFA voldoet aan beide controles door cryptografische authenticatie te gebruiken die niet kan worden ge-phisht. Organisaties die ISO 27001-certificering nastreven of behouden moeten kunnen aantonen dat geprivilegieerde accounts gebruikmaken van deze geavanceerde authenticatiemethoden.

De NIS2-richtlijn, die van toepassing is op organisaties in kritieke sectoren in de Europese Unie, vereist in Artikel 21 dat organisaties passende cybersecurity-maatregelen implementeren, inclusief sterke authenticatie voor geprivilegieerde accounts. Nederlandse organisaties die onder de NIS2-richtlijn vallen, zoals energiebedrijven, financiële instellingen en gezondheidszorgorganisaties, moeten kunnen aantonen dat ze phishing-resistente authenticatie gebruiken voor beheerdersaccounts. De richtlijn verplicht organisaties om regelmatig te rapporteren over hun beveiligingsmaatregelen, waarbij phishing-resistente MFA een belangrijk onderdeel vormt van deze rapportage.

NIST Special Publication 800-63B, de Digital Identity Guidelines van het Amerikaanse National Institute of Standards and Technology, definieert Authenticator Assurance Level 3 (AAL3) als het hoogste niveau van authenticatie-assurance. AAL3 vereist cryptografische authenticators die bestand zijn tegen phishing-aanvallen, wat exact overeenkomt met phishing-resistente MFA-methoden zoals FIDO2. Hoewel NIST een Amerikaanse standaard is, wordt deze wereldwijd erkend als toonaangevend voor identiteitsbeveiliging en wordt deze vaak gebruikt als referentie door organisaties die de hoogste beveiligingsstandaarden willen implementeren.

Executive Order 14028 van de Amerikaanse federale overheid, uitgegeven in 2021, vereist dat federale agentschappen zero-trust-architecturen implementeren, inclusief phishing-resistente meervoudige authenticatie. Hoewel deze order specifiek van toepassing is op Amerikaanse federale organisaties, heeft deze een brede invloed gehad op beveiligingspraktijken wereldwijd, inclusief in Nederland. Veel Nederlandse organisaties die samenwerken met Amerikaanse partners of die willen voldoen aan internationale best practices gebruiken deze vereisten als leidraad voor hun eigen beveiligingsimplementaties.

Voor Nederlandse organisaties is het belangrijk om te erkennen dat phishing-resistente MFA niet alleen een technische beveiligingsmaatregel is, maar ook een compliance-vereiste die moet worden gedocumenteerd en geverifieerd tijdens audits. Organisaties moeten regelmatig rapporten genereren die aantonen dat alle geprivilegieerde beheerdersaccounts gebruikmaken van phishing-resistente authenticatie, en deze rapporten moeten beschikbaar zijn voor interne en externe auditors. De documentatie moet ook procedures bevatten voor het beheer van FIDO2-sleutels, het onboarden van nieuwe beheerders en het afhandelen van verloren of defecte sleutels, zodat auditors kunnen verifiëren dat de implementatie volledig en correct is.

Remediatie

Gebruik PowerShell-script phishing-resistant-mfa-azure.ps1 (functie Invoke-Remediation) – Automatische remediatie van niet-conforme configuraties voor phishing-resistente MFA.

Remediatie van niet-conforme configuraties voor phishing-resistente meervoudige authenticatie is essentieel om te garanderen dat alle geprivilegieerde beheerdersaccounts daadwerkelijk gebruikmaken van de vereiste authenticatiemethoden. Wanneer monitoring detecteert dat beheerdersaccounts niet voldoen aan het phishing-resistente MFA-beleid, moeten organisaties onmiddellijk actie ondernemen om deze afwijkingen te corrigeren en de beveiligingspostuur te herstellen.

De meest voorkomende remediatiescenario's betreffen beheerders die nog geen FIDO2-sleutels hebben geregistreerd of die problemen ondervinden met hun bestaande registraties. Wanneer een beheerder wordt geïdentificeerd zonder phishing-resistente MFA, moet de organisatie onmiddellijk contact opnemen met de beheerder om de registratie te voltooien. Beheerders moeten worden voorzien van duidelijke instructies voor het registreren van een FIDO2-sleutel of het configureren van Windows Hello voor Business, afhankelijk van de gekozen authenticatiemethode. Tijdens het remediatieproces moet de beheerder mogelijk tijdelijk worden uitgesloten van bepaalde geprivilegieerde functies totdat de authenticatie correct is geconfigureerd, hoewel dit moet worden afgewogen tegen operationele behoeften.

Voor beheerders die problemen ondervinden met bestaande FIDO2-sleutelregistraties, zoals niet-herkende sleutels of authenticatiefouten, moet de helpdesk een gestructureerd troubleshooting-proces volgen. Dit proces moet beginnen met het verifiëren dat de sleutel correct is aangesloten of via NFC is verbonden, gevolgd door het controleren of de PIN correct is ingevoerd. Als deze basisstappen het probleem niet oplossen, moet de helpdesk controleren of de sleutel nog steeds actief is in Azure AD en of deze niet is gedeactiveerd of verwijderd. In sommige gevallen kan het nodig zijn om de sleutel opnieuw te registreren of een back-upsleutel te gebruiken als de primaire sleutel defect blijkt te zijn.

Wanneer Conditional Access-beleidsregels niet correct worden afgedwongen, wat kan resulteren in beheerders die nog steeds kunnen inloggen zonder phishing-resistente MFA, moet de configuratie van het beleid worden gecontroleerd. Organisaties moeten verifiëren dat het beleid correct is toegepast op de juiste gebruikersgroepen, dat de authenticatiestrekte correct is geconfigureerd, en dat de status van het beleid is ingesteld op Aan in plaats van Alleen rapporteren. Eventuele uitzonderingen in het beleid moeten worden gecontroleerd om te verifiëren dat deze niet onbedoeld beheerders uitsluiten van de vereisten.

Automatische remediatie via PowerShell-scripts kan het proces aanzienlijk versnellen en zorgen voor consistente afhandeling van niet-conforme configuraties. Scripts kunnen worden geconfigureerd om dagelijks te controleren op beheerdersaccounts zonder phishing-resistente MFA en automatisch waarschuwingen te genereren of zelfs bepaalde acties uit te voeren, zoals het tijdelijk uitschakelen van toegang tot geprivilegieerde functies. Deze scripts moeten echter zorgvuldig worden ontworpen om te voorkomen dat legitieme beheerders onterecht worden uitgesloten, en moeten altijd menselijke beoordeling omvatten voordat drastische maatregelen worden genomen.

Voor verloren of gestolen FIDO2-sleutels moet onmiddellijk een remediatieproces worden gevolgd om te voorkomen dat de sleutel wordt misbruikt. De beheerder moet onmiddellijk de helpdesk informeren over het verlies, waarna de sleutel onmiddellijk moet worden gedeactiveerd in Azure AD. De beheerder moet vervolgens een back-upsleutel gebruiken voor authenticatie totdat een nieuwe primaire sleutel kan worden geregistreerd. Als er geen back-upsleutel beschikbaar is, moet de organisatie een noodsleutel verstrekken of tijdelijk gebruikmaken van alternatieve authenticatiemethoden, waarbij de beveiligingsimplicaties zorgvuldig worden afgewogen. Alle verloren sleutels moeten worden gedocumenteerd in een incidentlogboek voor auditdoeleinden.

Remediatie moet ook worden uitgevoerd wanneer nieuwe beheerders worden toegevoegd aan geprivilegieerde rollen. Het onboardingproces moet ervoor zorgen dat nieuwe beheerders onmiddellijk FIDO2-sleutels ontvangen en registreren voordat ze toegang krijgen tot geprivilegieerde functies. Automatisering kan helpen bij het detecteren van nieuwe roltoewijzingen en het automatisch genereren van taken voor het distribueren en registreren van FIDO2-sleutels. Dit voorkomt dat nieuwe beheerders per ongeluk toegang krijgen zonder de vereiste authenticatie, wat een significant beveiligingsrisico zou vormen.

Alle remediatie-acties moeten worden gedocumenteerd voor audit- en compliance-doeleinden. Organisaties moeten een logboek bijhouden van alle niet-conforme configuraties, de genomen remediatie-acties, en de tijd die nodig was om de problemen op te lossen. Deze documentatie is essentieel voor het demonstreren van proactief beveiligingsbeheer tijdens externe audits en helpt organisaties om trends te identificeren die kunnen wijzen op systematische problemen met de implementatie of het beheer van phishing-resistente authenticatie.

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 Phishing-Resistant MFA Azure .DESCRIPTION CIS Azure Foundations Benchmark - Control 1.38 Controleert phishing-resistant MFA voor admin accounts. .NOTES Filename: phishing-resistant-mfa-azure.ps1 Author: Nederlandse Baseline voor Veilige Cloud Version: 1.0 CIS Control: 1.38 #> #Requires -Version 5.1 #Requires -Modules Az.Accounts [CmdletBinding()] param([Parameter()][switch]$Monitoring) $ErrorActionPreference = 'Stop' $PolicyName = "Phishing-Resistant MFA Azure" function Connect-RequiredServices { if (-not (Get-AzContext)) { Connect-AzAccount | Out-Null } } try { Connect-RequiredServices if ($Monitoring) { Write-Host "`n========================================" -ForegroundColor Cyan Write-Host "$PolicyName" -ForegroundColor Cyan Write-Host "========================================" -ForegroundColor Cyan Write-Host "⚠️ Manual verification required" -ForegroundColor Yellow Write-Host "Controleer phishing-resistant MFA:" -ForegroundColor Gray Write-Host " - FIDO2 security keys enabled" -ForegroundColor Gray Write-Host " - Windows Hello for Business" -ForegroundColor Gray Write-Host " - Certificate-based authentication" -ForegroundColor Gray Write-Host " - Vereist voor admin accounts" -ForegroundColor Gray } else { Write-Host "`n⚠️ Manual verification: Phishing-resistant MFA" -ForegroundColor Yellow } } catch { Write-Error $_; exit 1 } # ================================================================================ # Standaard Invoke-* Functions (Auto-generated) # ================================================================================ function Invoke-Implementation { <# .SYNOPSIS Implementeert de configuratie #> [CmdletBinding()] param() Invoke-Remediation } function Invoke-Monitoring { <# .SYNOPSIS Controleert de huidige configuratie status #> [CmdletBinding()] param() $Monitoring = $true try { Connect-RequiredServices if ($Monitoring) { Write-Host "`n========================================" -ForegroundColor Cyan Write-Host "$PolicyName" -ForegroundColor Cyan Write-Host "========================================" -ForegroundColor Cyan Write-Host "⚠️ Manual verification required" -ForegroundColor Yellow Write-Host "Controleer phishing-resistant MFA:" -ForegroundColor Gray Write-Host " - FIDO2 security keys enabled" -ForegroundColor Gray Write-Host " - Windows Hello for Business" -ForegroundColor Gray Write-Host " - Certificate-based authentication" -ForegroundColor Gray Write-Host " - Vereist voor admin accounts" -ForegroundColor Gray } else { Write-Host "`n⚠️ Manual verification: Phishing-resistant MFA" -ForegroundColor Yellow } } catch { Write-Error $_; exit 1 } } function Invoke-Remediation { <# .SYNOPSIS Herstelt de configuratie naar de gewenste staat .DESCRIPTION Dit is een monitoring-only control, remediation delegeert naar monitoring #> [CmdletBinding()] param() Write-Host "[INFO] Dit is een monitoring-only control" -ForegroundColor Yellow Write-Host "[INFO] Running monitoring check..." -ForegroundColor Cyan Invoke-Monitoring }

Risico zonder implementatie

Risico zonder implementatie
Critical: Traditionele MFA kan worden omzeild via AiTM-phishingaanvallen met standaard tools. Aanvallers richten zich specifiek op beheerdersaccounts omdat één gecompromitteerd Global Admin-account een volledige tenantovername mogelijk maakt. Recente inbreuken zoals Uber in 2022 en Twilio in 2022 gebruikten AiTM-aanvallen tegen MFA-beschermde beheerders. Phishing-resistente MFA is de enige effectieve preventie tegen deze aanvallen. Gemiddelde herstelkosten bedragen meer dan vijfhonderdduizend euro. Compliance-vereisten: CIS 1.38, BIO 9.04, ISO 27001 A.9.4.3, NIS2, NIST AAL3. Het risico is KRITIEK voor beheerdersaccounts.

Management Samenvatting

Phishing-resistente MFA voor geprivilegieerde rollen: FIDO2-hardwaretokens zoals YubiKey, Windows Hello voor Business met biometrie en TPM. Blokkeert AiTM-phishingaanvallen. Vereist: Hardwaretokens tussen vijftig en honderd euro per beheerder voor twee tokens als back-up. Activatie: Registreer FIDO2-tokens en configureer Conditional Access om deze te vereisen voor beheerders. Verplicht volgens CIS 1.38, BIO 9.04, NIS2. Implementatie: acht tot twaalf uur technisch werk plus acht uur organisatorisch werk. KRITIEKE beveiliging voor beheerdersaccounts.