Azure: Directory-rollen Beschermen Via Conditional Access Policies

Directoryrollen beschikken over extreme bevoegdheden. Eén gecompromitteerde beheerder kan leiden tot een volledige overname van de tenant. Standaard Conditional Access-beleidsregels voor reguliere gebruikers zijn onvoldoende voor beheerders. Beheerders hebben gelaagde beveiliging nodig: phishing-resistente meervoudige authenticatie (niet alleen reguliere MFA), uitsluitend compliante apparaten (geen BYOD voor beheerderstoegang), alleen vertrouwde locaties of landen, geblokkeerde hoog-risico aanmeldingen en kortere sessieduur. Directoryrolbescherming via Conditional Access biedt deze extra beveiligingslagen specifiek voor accounts met hoge bevoegdheden.

Implementatie

Deze controle implementeert een specifiek Conditional Access-beleid dat uitsluitend is gericht op leden van directoryrollen binnen de Azure Active Directory-omgeving. Het beleid creëert een gelaagde beveiligingsstructuur die fundamenteel verschilt van standaard Conditional Access-beleidsregels voor reguliere gebruikers, omdat het specifiek is ontworpen om de unieke risico's te adresseren die gepaard gaan met accounts die beschikken over verhoogde bevoegdheden. De beleidsconfiguratie begint met de selectie van gebruikers, waarbij expliciet wordt gekozen voor directoryrollen in plaats van individuele gebruikers of groepen. Deze aanpak omvat automatisch alle gebruikers die momenteel een beheerdersrol hebben toegewezen, waaronder de Globale beheerder met de hoogste bevoegdheden, de Bevoorrechte rolbeheerder die andere rollen kan beheren, de Beveiligingsbeheerder die beveiligingsinstellingen configureert, de Gebruikersbeheerder die gebruikersaccounts beheert, en alle andere rollen met verhoogde bevoegdheden die binnen de organisatie worden gebruikt. Voor cloud-applicaties wordt gekozen voor alle cloud-apps, waardoor het beleid van toepassing is op alle Microsoft 365-services en Azure-services waartoe beheerders toegang hebben, inclusief de Microsoft 365-portal, Azure-portal, Exchange Online, SharePoint Online, Teams en alle andere cloud-applicaties. De voorwaarden van het beleid omvatten kritieke beveiligingsvereisten die gezamenlijk een gelaagde beveiligingsbenadering vormen. Het beleid vereist dat alle apparaten die worden gebruikt voor beheerderstoegang compliant zijn volgens het Intune-beleid van de organisatie, wat betekent dat apparaten moeten voldoen aan strikte beveiligingsvereisten zoals schijfversleuteling, bijgewerkte besturingssystemen, en geïnstalleerde beveiligingssoftware. Daarnaast vereist het beleid phishing-resistente meervoudige authenticatie waarbij alleen cryptografische authenticatiemethoden zoals FIDO2-security keys of Windows Hello for Business zijn toegestaan, en worden traditionele MFA-methoden zoals SMS-codes of authenticator-apps expliciet uitgesloten omdat deze kwetsbaar zijn voor geavanceerde phishing-aanvallen. Het beleid blokkeert bovendien automatisch riskante aanmeldingen met een hoog risico zoals gedetecteerd door Identity Protection, waardoor aanmeldingen die overeenkomen met bekende aanvalspatronen of die afwijkende activiteiten vertonen worden geblokkeerd voordat toegang wordt verleend. De toekenningsvoorwaarden combineren het vereisen van phishing-resistente meervoudige authenticatie met het vereisen van een compliant apparaat, waardoor een gelaagde beveiligingsbenadering ontstaat waarbij meerdere onafhankelijke beveiligingscontroles moeten worden doorstaan voordat toegang wordt verleend. Voor de sessieconfiguratie wordt de aanmelfrequentie ingesteld op 4 uur, wat aanzienlijk korter is dan de standaard 24 uur voor reguliere gebruikers, waardoor het risico van gecompromitteerde sessies wordt verminderd door beheerders vaker te verplichten opnieuw te authenticeren met hun phishing-resistente MFA-methode. Door een apart beleid te configureren dat specifiek is gericht op beheerdersaccounts, kunnen organisaties maximale bescherming bieden aan accounts met verhoogde bevoegdheden zonder de gebruikerservaring voor reguliere gebruikers te beïnvloeden.

Vereisten

De implementatie van directoryrolbescherming via Conditional Access vereist een grondige voorbereiding waarbij zowel technische als organisatorische aspecten moeten worden afgedekt. Deze vereisten vormen de fundamentele basis voor een robuuste beveiligingsstrategie die beheerdersaccounts effectief beschermt tegen geavanceerde cyberbedreigingen die specifiek gericht zijn op accounts met verhoogde bevoegdheden. Zonder adequate voorbereiding en het voldoen aan alle vereisten loopt de implementatie het risico om onvolledig te zijn of zelfs te falen, wat ernstige beveiligingsrisico's met zich meebrengt. De primaire technische vereiste betreft de licentieconfiguratie van de Azure Active Directory-omgeving. Voor de basisimplementatie van Conditional Access-beleidsregels is minimaal een Azure AD Premium P1-licentie vereist. Deze licentie biedt toegang tot de volledige Conditional Access-functionaliteit, waardoor organisaties beleidsregels kunnen configureren die toegang controleren op basis van verschillende factoren zoals gebruikersidentiteiten, apparaatstatus, geografische locaties en specifieke cloud-applicaties. De Conditional Access-functionaliteit vormt de kern van moderne identiteitsbeveiliging en stelt organisaties in staat om dynamische toegangsbeslissingen te nemen op basis van contextuele informatie. Zonder deze licentie kunnen organisaties geen Conditional Access-beleidsregels implementeren, wat betekent dat ze afhankelijk blijven van statische toegangscontroles die onvoldoende bescherming bieden tegen moderne bedreigingen. Voor organisaties die geavanceerde risicogebaseerde beveiligingsmaatregelen willen implementeren, is een Azure AD Premium P2-licentie noodzakelijk. Deze licentie voegt Identity Protection-functionaliteit toe aan de Conditional Access-capaciteiten, waardoor organisaties Conditional Access-beleidsregels kunnen configureren die reageren op gedetecteerde aanmeldingsrisico's en gebruikersrisico's. Identity Protection analyseert continu aanmeldingspatronen en gebruikersgedrag om afwijkende activiteiten te detecteren die kunnen wijzen op gecompromitteerde accounts of kwaadaardige activiteiten. Deze geavanceerde detectiecapaciteiten stellen organisaties in staat om automatisch hoog-risico aanmeldingen te blokkeren voordat ze toegang krijgen tot kritieke systemen. Voor beheerdersaccounts is deze functionaliteit bijzonder waardevol omdat een gecompromitteerde beheerder toegang heeft tot de meest gevoelige systemen en gegevens binnen de organisatie. De risicogebaseerde blokkering vormt een cruciale verdedigingslaag tegen geavanceerde phishing-aanvallen, credential stuffing-aanvallen en andere moderne bedreigingstechnieken die specifiek gericht zijn op het compromitteren van beheerdersaccounts. Een van de meest kritieke vereisten betreft de authenticatiemethode voor beheerdersaccounts. Alle beheerders moeten geregistreerd zijn voor phishing-resistente meervoudige authenticatie voordat directoryrolbescherming kan worden geïmplementeerd. Phishing-resistente MFA verschilt fundamenteel van traditionele MFA-methoden zoals SMS-codes of authenticator-apps omdat het cryptografische bewijs gebruikt in plaats van gedeelde geheimen die kunnen worden onderschept. Beheerders moeten beschikken over FIDO2-security keys of Windows Hello for Business als hun primaire authenticatiemethode. FIDO2-security keys zijn fysieke hardware-apparaten die cryptografische sleutels bevatten en die direct communiceren met de browser of het besturingssysteem zonder dat gevoelige informatie wordt doorgegeven via netwerkverbindingen. Windows Hello for Business gebruikt de Trusted Platform Module (TPM) van het apparaat om cryptografische sleutels veilig op te slaan en te gebruiken voor authenticatie. Deze methoden zijn resistent tegen phishing-aanvallen omdat ze gebruikmaken van public key cryptografie waarbij de private key nooit het apparaat verlaat. Traditionele MFA-methoden zijn kwetsbaar voor geavanceerde phishing-aanvallen zoals adversary-in-the-middle (AiTM) aanvallen, waarbij aanvallers een proxy-server opzetten tussen de gebruiker en de legitieme service, waardoor ze authenticatiecodes kunnen onderscheppen en hergebruiken. Voor beheerdersaccounts is deze kwetsbaarheid onacceptabel omdat een gecompromitteerde beheerder toegang heeft tot alle systemen en gegevens binnen de tenant. Apparaatcompliance vormt een andere essentiële vereiste voor directoryrolbescherming. Alle apparaten die worden gebruikt voor beheerderstoegang moeten compliant zijn volgens het Intune-beleid van de organisatie. Dit betekent dat apparaten moeten voldoen aan een reeks beveiligingsvereisten die zijn gedefinieerd in het Mobile Device Management-beleid. Deze vereisten omvatten typisch schijfversleuteling via BitLocker of een vergelijkbare technologie, complexe wachtwoordvereisten of biometrische authenticatie, bijgewerkte besturingssystemen zonder bekende kwetsbaarheden, geïnstalleerde en bijgewerkte beveiligingssoftware zoals antivirus en antimalware, en configuratie van beveiligingsinstellingen zoals firewallregels en applicatiecontrole. Compliante apparaten vormen een cruciale verdedigingslaag omdat ze beveiligd zijn tegen malware-infecties, ongeautoriseerde toegang en andere bedreigingen die kunnen worden gebruikt om beheerdersaccounts te compromitteren. Apparaten die niet voldoen aan de compliancevereisten kunnen kwetsbaarheden bevatten die aanvallers kunnen exploiteren om toegang te krijgen tot beheerdersaccounts, zelfs wanneer andere beveiligingsmaatregelen correct zijn geïmplementeerd. Voor beheerdersaccounts is het gebruik van persoonlijke apparaten of apparaten die niet voldoende beveiligd zijn een onacceptabel risico dat moet worden voorkomen door strikte apparaatcompliancevereisten. Een belangrijke organisatorische vereiste betreft de configuratie van break-glass accounts. Deze noodaccounts moeten expliciet worden uitgesloten van het Conditional Access-beleid voor directoryrollen om te voorkomen dat organisaties worden uitgesloten van hun eigen tenant in noodsituaties. Break-glass accounts zijn speciaal geconfigureerde accounts die worden gebruikt wanneer reguliere beheerdersaccounts niet toegankelijk zijn, bijvoorbeeld tijdens een grootschalige cyberaanval waarbij meerdere beheerdersaccounts zijn gecompromitteerd, of wanneer er technische problemen zijn met de Conditional Access-configuratie die normale beheerdersaanmeldingen blokkeren. Deze accounts moeten buiten het Conditional Access-beleid blijven om te garanderen dat organisaties altijd toegang hebben tot hun tenant voor hersteldoeleinden. Break-glass accounts moeten echter wel andere strenge beveiligingsmaatregelen hebben om te voorkomen dat ze een zwakke schakel worden in de beveiligingsstrategie. Deze maatregelen omvatten zeer sterke wachtwoorden die regelmatig worden gewijzigd, beperkte toegang tot specifieke functies die strikt noodzakelijk zijn voor hersteloperaties, uitgebreide logging en monitoring van alle activiteiten die worden uitgevoerd met break-glass accounts, en regelmatige audits om te controleren of deze accounts alleen worden gebruikt wanneer dat absoluut noodzakelijk is. De configuratie en het beheer van break-glass accounts vereist zorgvuldige planning en documentatie om te garanderen dat ze hun beoogde doel vervullen zonder onnodige beveiligingsrisico's te introduceren.

Implementatie

Gebruik PowerShell-script directory-role-protection-ca.ps1 (functie Invoke-Implementation) – Implementeren.

De implementatie van directoryrolbescherming via Conditional Access vereist een zorgvuldige en gestructureerde aanpak waarbij gelaagde beveiligingsmaatregelen worden geconfigureerd die specifiek zijn afgestemd op de unieke risicoprofielen van beheerdersaccounts. Het implementatieproces begint met het navigeren naar de Azure Active Directory-portal binnen de Microsoft 365-beheercentrum of de Azure-portal, gevolgd door het selecteren van de sectie voor voorwaardelijke toegang. Deze sectie biedt toegang tot alle Conditional Access-beleidsregels en stelt beheerders in staat om nieuwe beleidsregels te maken of bestaande beleidsregels te bewerken. Het is belangrijk om te begrijpen dat Conditional Access-beleidsregels worden geëvalueerd in real-time tijdens elke aanmeldingspoging, waardoor ze een krachtig mechanisme vormen voor dynamische toegangscontrole. Het eerste kritieke aspect van de implementatie betreft de naamgeving en documentatie van het nieuwe beleid. Het beleid moet een duidelijke en beschrijvende naam krijgen zoals "Directory rol bescherming - Beheerders" om de doelstelling en het bereik onmiddellijk duidelijk te maken voor andere beheerders die het beleid later moeten onderhouden of aanpassen. Een goede naamgeving is essentieel voor het beheer van meerdere Conditional Access-beleidsregels, vooral in grote organisaties waar tientallen of zelfs honderden beleidsregels kunnen bestaan. Naast de naam moet het beleid worden gedocumenteerd met een duidelijke beschrijving die uitlegt waarom het beleid is gemaakt, welke beveiligingsdoelstellingen het dient, en welke specifieke risico's het adresseert. Deze documentatie is waardevol voor audits, compliance-verificaties en toekomstige wijzigingen aan het beleid. Bij de configuratie van de gebruikersselectie moet expliciet worden gekozen voor directoryrollen in plaats van individuele gebruikers of groepen. Deze aanpak is superieur omdat het automatisch alle gebruikers omvat die momenteel een beheerdersrol hebben toegewezen, evenals toekomstige gebruikers die later een beheerdersrol krijgen. De selectie moet alle relevante beheerdersrollen omvatten, waaronder de Globale beheerder die de hoogste bevoegdheden heeft binnen de tenant, de Bevoorrechte rolbeheerder die andere rollen kan beheren, de Beveiligingsbeheerder die beveiligingsinstellingen kan configureren, de Gebruikersbeheerder die gebruikersaccounts kan beheren, de Exchange-beheerder die e-mailconfiguraties kan wijzigen, de SharePoint-beheerder die SharePoint-omgevingen kan beheren, en alle andere rollen met verhoogde bevoegdheden die binnen de organisatie worden gebruikt. Het is essentieel om een break-glass accounts groep expliciet uit te sluiten van dit beleid om te voorkomen dat organisaties worden uitgesloten van hun eigen tenant in noodsituaties wanneer reguliere beheerdersaccounts niet toegankelijk zijn. Deze uitsluiting moet zorgvuldig worden geconfigureerd en gedocumenteerd, en break-glass accounts moeten andere strenge beveiligingsmaatregelen hebben om te compenseren voor het ontbreken van Conditional Access-beveiliging. Voor de configuratie van cloud-applicaties moet worden gekozen voor alle cloud-apps om ervoor te zorgen dat het beleid van toepassing is op alle Microsoft 365-services en Azure-services waartoe beheerders toegang hebben. Deze brede toepassing is noodzakelijk omdat beheerders vaak toegang hebben tot meerdere services en omdat een gecompromitteerde beheerder toegang kan krijgen tot kritieke systemen via elke beschikbare service. Het beleid moet van toepassing zijn op de Microsoft 365-portal waar beheerders algemene configuraties kunnen wijzigen, de Azure-portal waar Azure-resources kunnen worden beheerd, Exchange Online waar e-mailconfiguraties kunnen worden gewijzigd, SharePoint Online waar documentbeheer kan worden geconfigureerd, Teams waar samenwerkingsinstellingen kunnen worden aangepast, en alle andere cloud-applicaties die binnen de organisatie worden gebruikt. Door het beleid toe te passen op alle cloud-apps wordt een consistente beveiligingspostuur gehandhaafd ongeacht welke service een beheerder probeert te gebruiken. Bij de configuratie van voorwaarden moet het aanmeldingsrisico worden ingesteld op het blokkeren van hoog risico. Deze configuratie vereist Azure AD Premium P2 en Identity Protection-functionaliteit, die continu aanmeldingspatronen analyseert om afwijkende activiteiten te detecteren. Wanneer Identity Protection een hoog risico detecteert, zoals een aanmelding vanaf een onbekende locatie met verdachte gedragspatronen, of een aanmelding die overeenkomt met bekende aanvalspatronen, wordt de aanmelding automatisch geblokkeerd voordat toegang wordt verleend. Deze risicogebaseerde blokkering vormt een cruciale verdedigingslaag tegen geavanceerde bedreigingen die traditionele authenticatiemethoden kunnen omzeilen. Daarnaast kan optioneel worden geconfigureerd dat alleen vertrouwde locaties zijn toegestaan, wat extra beveiliging biedt door aanmeldingen van onbekende geografische locaties te blokkeren. Vertrouwde locaties moeten zorgvuldig worden gedefinieerd op basis van de werkelijke geografische spreiding van beheerders binnen de organisatie, en moeten regelmatig worden herzien om te voorkomen dat legitieme beheerders worden geblokkeerd wanneer ze reizen of werken vanaf nieuwe locaties. De toekenningsvoorwaarden vormen het hart van het Conditional Access-beleid en moeten worden ingesteld op het vereisen van phishing-resistente meervoudige authenticatie in combinatie met het vereisen van een compliant apparaat. Phishing-resistente MFA betekent dat alleen FIDO2-security keys of Windows Hello for Business zijn toegestaan als authenticatiemethode, en dat traditionele MFA-methoden zoals SMS-codes of authenticator-apps expliciet worden uitgesloten. Deze restrictie is noodzakelijk omdat traditionele MFA-methoden kwetsbaar zijn voor geavanceerde phishing-aanvallen waarbij aanvallers authenticatiecodes kunnen onderscheppen en hergebruiken. Compliant apparaten zijn apparaten die voldoen aan het Intune-beleid van de organisatie voor beveiliging, inclusief versleuteling, wachtwoordvereisten, bijgewerkte besturingssystemen en geïnstalleerde beveiligingssoftware. De combinatie van phishing-resistente MFA en apparaatcompliance creëert een gelaagde beveiligingsbenadering waarbij meerdere onafhankelijke beveiligingscontroles moeten worden doorstaan voordat toegang wordt verleend. Voor de sessieconfiguratie moet de aanmelfrequentie worden ingesteld op 4 uur, wat aanzienlijk korter is dan de standaard 24 uur die typisch wordt gebruikt voor reguliere gebruikers. Deze kortere sessieduur vermindert het risico van gecompromitteerde sessies door beheerders vaker te verplichten opnieuw te authenticeren met hun phishing-resistente MFA-methode. Als een beheerderssessie wordt gecompromitteerd, bijvoorbeeld door session hijacking of een andere aanvalstechniek, wordt de schade beperkt omdat de sessie na maximaal 4 uur automatisch verloopt en opnieuw authenticatie vereist. Deze aanpak is bijzonder belangrijk voor beheerdersaccounts omdat een gecompromitteerde beheerderssessie toegang kan geven tot alle systemen en gegevens binnen de tenant. Het implementatieproces moet beginnen met het inschakelen van het beleid in de report-only modus, waarbij het beleid wordt geëvalueerd en gelogd maar nog geen toegang blokkeert. Deze modus stelt organisaties in staat om het beleid te testen met een pilotgroep van beheerders zonder het risico te lopen dat legitieme beheerders worden geblokkeerd. Gedurende minimaal één week moet het beleid worden gemonitord door regelmatig de Conditional Access-insights en aanmeldingslogboeken te controleren om te verifiëren dat het beleid correct wordt geëvalueerd, dat er geen onverwachte blokkades optreden, en dat alle beheerders in de pilotgroep correct kunnen aanmelden met hun phishing-resistente MFA-methoden en compliante apparaten. Tijdens deze testperiode moeten eventuele problemen worden geïdentificeerd en opgelost, en moeten aanpassingen worden gemaakt aan de configuratie indien nodig. Na een succesvolle testperiode zonder problemen kan het beleid worden ingeschakeld in de enforcement-modus voor alle beheerders, waarbij het beleid daadwerkelijk toegang blokkeert wanneer de voorwaarden niet worden voldaan.

Compliance en Auditing

Directoryrolbescherming via Conditional Access draagt substantieel bij aan naleving van verschillende belangrijke beveiligingsstandaarden en compliance-frameworks die relevant zijn voor Nederlandse overheidsorganisaties en andere organisaties die werken met gevoelige gegevens. Deze compliance-aspecten zijn van cruciaal belang omdat ze niet alleen technische beveiligingsvereisten adresseren, maar ook juridische en regelgevende verplichtingen die organisaties moeten nakomen om te voldoen aan nationale en internationale normen voor informatiebeveiliging. Het implementeren van directoryrolbescherming helpt organisaties om te demonstreren dat ze passende maatregelen hebben genomen om beheerdersaccounts te beschermen tegen geavanceerde bedreigingen, wat essentieel is voor compliance-verificaties en audits. De CIS Azure Benchmark v3.0.0 bevat specifieke controles die direct worden afgedekt door directoryrolbescherming via Conditional Access. Control 1.26 vereist expliciet dat alle beheerdersaccounts meervoudige authenticatie gebruiken voor alle cloud-services en Azure-services. Deze controle is gebaseerd op het principe dat beheerdersaccounts een verhoogd risico vormen en daarom extra authenticatievereisten nodig hebben bovenop wachtwoorden alleen. Directoryrolbescherming voldoet aan deze controle door het vereisen van phishing-resistente meervoudige authenticatie voor alle beheerdersaccounts. Control 1.38 gaat nog verder en vereist specifiek dat beheerdersaccounts phishing-resistente meervoudige authenticatie gebruiken, wat betekent dat traditionele MFA-methoden zoals SMS-codes of authenticator-apps niet voldoende zijn. Deze controle is gebaseerd op het groeiende aantal geavanceerde phishing-aanvallen die traditionele MFA kunnen omzeilen, zoals adversary-in-the-middle aanvallen waarbij aanvallers authenticatiecodes kunnen onderscheppen. Door directoryrolbescherming te implementeren met phishing-resistente MFA en compliant apparaten, voldoen organisaties aan beide controles en demonstreren ze dat ze de hoogste beveiligingsstandaarden toepassen voor hun meest kritieke accounts. Het BIO-framework (Baseline Informatiebeveiliging Overheid) bevat in norm 09.04 specifieke vereisten voor de bescherming van bevoorrechte toegang die direct relevant zijn voor directoryrolbescherming. Deze norm vereist dat organisaties gelaagde beveiligingsmaatregelen implementeren voor accounts met verhoogde bevoegdheden, waarbij meerdere onafhankelijke beveiligingscontroles moeten worden doorstaan voordat toegang wordt verleend. Het concept van gelaagde beveiliging is gebaseerd op het defense-in-depth-principe, waarbij meerdere beveiligingslagen worden geïmplementeerd zodat als één laag faalt, andere lagen nog steeds bescherming bieden. Directoryrolbescherming via Conditional Access biedt deze gelaagde beveiliging door het combineren van phishing-resistente MFA die beschermt tegen geavanceerde phishing-aanvallen, compliant apparaten die beschermen tegen malware en andere apparaatgerelateerde bedreigingen, risicogebaseerde blokkering die automatisch hoog-risico aanmeldingen blokkeert, en kortere sessieduur die het risico van gecompromitteerde sessies vermindert. Deze combinatie van beveiligingsmaatregelen voldoet aan de BIO-vereisten voor bevoorrechte toegangsbescherming en helpt organisaties om te demonstreren dat ze passende maatregelen hebben genomen om hun kritieke accounts te beschermen. ISO 27001:2022 bevat in controle A.9.4.3 specifieke vereisten voor bevoorrechte toegangssystemen die relevant zijn voor directoryrolbescherming. Deze controle vereist dat organisaties beveiligingsmaatregelen implementeren voor accounts met verhoogde bevoegdheden, inclusief sterke authenticatie en toegangscontrole die zijn afgestemd op het risiconiveau van de accounts. De controle benadrukt dat bevoorrechte accounts een verhoogd risico vormen omdat ze toegang hebben tot kritieke systemen en gegevens, en daarom extra beveiligingsmaatregelen nodig hebben bovenop de standaard beveiligingscontroles. Directoryrolbescherming via Conditional Access voldoet aan deze vereisten door het implementeren van phishing-resistente MFA die sterke authenticatie biedt die resistent is tegen geavanceerde phishing-aanvallen, apparaatcompliance die ervoor zorgt dat alleen beveiligde apparaten toegang krijgen, en risicogebaseerde toegangscontrole die automatisch reageert op gedetecteerde bedreigingen. Deze combinatie van beveiligingsmaatregelen specifiek voor beheerdersaccounts voldoet aan de ISO 27001-vereisten en helpt organisaties om te demonstreren dat ze een risicogebaseerde benadering hanteren voor beveiligingsbeheer. De NIS2-richtlijn (Network and Information Systems Directive 2) bevat in artikel 21 specifieke vereisten voor de beveiliging van bevoorrechte accounts die relevant zijn voor Nederlandse organisaties die onder de richtlijn vallen. Dit artikel vereist dat essentiële entiteiten en belangrijke entiteiten passende beveiligingsmaatregelen implementeren voor accounts met verhoogde bevoegdheden, waarbij de maatregelen moeten zijn afgestemd op het risiconiveau van de accounts en de kritiekheid van de systemen waartoe ze toegang hebben. De richtlijn benadrukt dat bevoorrechte accounts een bijzonder hoog risico vormen omdat ze toegang hebben tot kritieke infrastructuren en daarom extra beveiligingsmaatregelen nodig hebben. Directoryrolbescherming via Conditional Access biedt deze beveiligingsmaatregelen door het implementeren van gelaagde beveiliging specifiek voor beheerdersaccounts, waarbij meerdere onafhankelijke beveiligingscontroles moeten worden doorstaan voordat toegang wordt verleend. Deze aanpak voldoet aan de NIS2-vereisten en helpt organisaties om te demonstreren dat ze passende maatregelen hebben genomen om hun kritieke accounts te beschermen tegen geavanceerde bedreigingen. Het Zero Trust-beveiligingsmodel vereist expliciete verificatie voor alle gebruikers en apparaten, ongeacht hun locatie of netwerkverbinding. Dit model is gebaseerd op het principe dat organisaties nooit automatisch moeten vertrouwen op gebruikers, apparaten of netwerken, maar altijd expliciete verificatie moeten vereisen voordat toegang wordt verleend. Voor beheerdersaccounts is dit principe nog belangrijker omdat ze toegang hebben tot de meest kritieke systemen en gegevens binnen de organisatie, en omdat een gecompromitteerde beheerder catastrofale gevolgen kan hebben voor de organisatie. Directoryrolbescherming via Conditional Access implementeert Zero Trust-principes door het vereisen van expliciete verificatie via phishing-resistente MFA en compliant apparaten voor alle beheerdersaanmeldingen, ongeacht de locatie waar de aanmelding plaatsvindt. Dit betekent dat een beheerder die probeert aan te melden vanaf een vertrouwd netwerk of een bekende locatie nog steeds moet voldoen aan dezelfde strenge authenticatievereisten als een beheerder die probeert aan te melden vanaf een onbekende locatie. Deze aanpak voldoet aan het Zero Trust-principe van "verifieer expliciet" voor beheerdersaccounts en helpt organisaties om een Zero Trust-beveiligingsarchitectuur te implementeren die bescherming biedt tegen zowel externe als interne bedreigingen.

Monitoring

Gebruik PowerShell-script directory-role-protection-ca.ps1 (functie Invoke-Monitoring) – Controleren.

Effectieve monitoring van directoryrolbescherming via Conditional Access is essentieel om te verifiëren dat het beleid correct functioneert, dat beheerdersaccounts adequaat worden beschermd, en dat er geen onverwachte problemen optreden die de beschikbaarheid of beveiliging kunnen beïnvloeden. Monitoring moet een continu proces zijn waarbij regelmatig wordt gecontroleerd of het Conditional Access-beleid wordt toegepast zoals bedoeld, of er ongewenste blokkades optreden, en of de beveiligingsmaatregelen effectief zijn tegen geavanceerde bedreigingen. Zonder adequate monitoring kunnen organisaties niet verifiëren dat hun beveiligingsmaatregelen werken zoals bedoeld, en kunnen ze problemen missen die kunnen leiden tot beveiligingsincidenten of operationele verstoringen. De primaire monitoringactiviteit betreft het regelmatig controleren van de Conditional Access-insights en aanmeldingslogboeken om te verifiëren dat het beleid correct wordt geëvalueerd en toegepast. De Conditional Access-insights bieden een overzicht van alle Conditional Access-beleidsregels en hun impact, inclusief het aantal gebruikers dat wordt beïnvloed, het aantal geslaagde en geblokkeerde aanmeldingen, en trends over tijd. Deze insights helpen organisaties om te begrijpen hoe het beleid presteert en of er aanpassingen nodig zijn. De aanmeldingslogboeken bevatten gedetailleerde informatie over elke aanmeldingspoging, inclusief welke Conditional Access-beleidsregels werden geëvalueerd, welke voorwaarden werden gecontroleerd, en wat de uiteindelijke beslissing was. Door regelmatig deze logboeken te analyseren kunnen organisaties patronen identificeren, zoals beheerders die regelmatig worden geblokkeerd vanwege niet-compliante apparaten of ontbrekende phishing-resistente MFA-registratie, en kunnen ze proactief actie ondernemen om deze problemen op te lossen. Een kritieke monitoringactiviteit betreft het controleren van de compliance-status van beheerdersapparaten. Alle apparaten die worden gebruikt voor beheerderstoegang moeten compliant zijn volgens het Intune-beleid, en organisaties moeten regelmatig controleren of alle beheerdersapparaten daadwerkelijk compliant zijn. Niet-compliante apparaten vormen een significant beveiligingsrisico omdat ze kwetsbaarheden kunnen bevatten die aanvallers kunnen exploiteren om toegang te krijgen tot beheerdersaccounts. Monitoring moet identificeren welke beheerdersapparaten niet compliant zijn, waarom ze niet compliant zijn, en wat er moet worden gedaan om ze compliant te maken. Deze informatie moet worden gebruikt om beheerders te helpen hun apparaten te configureren volgens de vereisten, en om te verifiëren dat alle apparaten uiteindelijk compliant worden. Regelmatige compliance-rapportages helpen organisaties om een overzicht te houden van de beveiligingspostuur van hun beheerdersapparaten en om trends te identificeren die kunnen wijzen op bredere problemen met apparaatbeheer. Monitoring van phishing-resistente MFA-registratie is essentieel om te verifiëren dat alle beheerders daadwerkelijk zijn geregistreerd voor phishing-resistente authenticatiemethoden. Organisaties moeten regelmatig controleren welke beheerders FIDO2-security keys of Windows Hello for Business hebben geregistreerd, en welke beheerders nog steeds afhankelijk zijn van traditionele MFA-methoden die niet voldoen aan de vereisten. Beheerders die niet zijn geregistreerd voor phishing-resistente MFA vormen een beveiligingsrisico omdat ze kwetsbaar zijn voor geavanceerde phishing-aanvallen die traditionele MFA kunnen omzeilen. Monitoring moet identificeren welke beheerders nog moeten worden geregistreerd, en moet worden gebruikt om gerichte acties te ondernemen om deze beheerders te helpen bij de registratie. Regelmatige rapportages over MFA-registratiestatus helpen organisaties om bij te houden hoeveel beheerders voldoen aan de vereisten en hoeveel nog actie moeten ondernemen. Monitoring van Identity Protection-signalen en risicodetecties is cruciaal voor organisaties die Azure AD Premium P2 gebruiken en risicogebaseerde blokkering hebben geconfigureerd. Identity Protection detecteert continu afwijkende activiteiten en risicovolle aanmeldingspatronen die kunnen wijzen op gecompromitteerde accounts of kwaadaardige activiteiten. Organisaties moeten regelmatig controleren welke risicodetecties zijn gegenereerd voor beheerdersaccounts, welke risiconiveaus zijn toegekend, en welke acties zijn ondernomen als reactie op deze detecties. Hoge risicodetecties voor beheerdersaccounts vereisen onmiddellijke aandacht omdat ze kunnen wijzen op een gecompromitteerd account of een lopende aanval. Monitoring moet organisaties helpen om deze detecties snel te identificeren en te reageren, en om patronen te identificeren die kunnen wijzen op bredere beveiligingsproblemen. Regelmatige analyse van risicodetecties helpt organisaties om hun beveiligingspostuur te verbeteren en om proactief te reageren op nieuwe bedreigingen. Monitoring van Conditional Access-beleidsimpact en gebruikerservaring is belangrijk om te verifiëren dat het beleid niet onbedoeld legitieme beheerders blokkeert of hun productiviteit negatief beïnvloedt. Organisaties moeten regelmatig controleren hoeveel beheerdersaanmeldingen worden geblokkeerd door het beleid, wat de redenen zijn voor deze blokkades, en of deze blokkades legitiem zijn of het gevolg van configuratiefouten. Onverwachte blokkades kunnen wijzen op problemen met de beleidsconfiguratie, zoals te strenge voorwaarden of onjuiste uitsluitingen, die moeten worden opgelost om te voorkomen dat legitieme beheerders worden geblokkeerd. Monitoring moet ook de gebruikerservaring evalueren, zoals hoe vaak beheerders moeten opnieuw authenticeren vanwege de kortere sessieduur, en of dit acceptabel is of aanpassingen vereist. Regelmatige feedback van beheerders over hun ervaring met het beleid helpt organisaties om de balans te vinden tussen beveiliging en bruikbaarheid, en om aanpassingen te maken die de beveiliging behouden terwijl de gebruikerservaring wordt verbeterd.

Remediatie

Gebruik PowerShell-script directory-role-protection-ca.ps1 (functie Invoke-Remediation) – Herstellen.

Wanneer directoryrolbescherming via Conditional Access niet correct is geconfigureerd of wanneer beheerders problemen ondervinden bij het aanmelden, moeten passende remediatiemaatregelen worden genomen om de beveiliging te herstellen en de functionaliteit te waarborgen. Remediatie moet worden uitgevoerd op basis van de specifieke problemen die worden geïdentificeerd tijdens monitoring of wanneer beheerders problemen melden, waarbij elke situatie zorgvuldig moet worden geanalyseerd om de juiste oplossing te identificeren. Effectieve remediatie vereist een gestructureerde aanpak waarbij problemen worden geïdentificeerd, geanalyseerd, opgelost en geverifieerd om te zorgen dat de beveiligingsmaatregelen correct functioneren en dat beheerders toegang hebben wanneer dat nodig is. Wanneer beheerders niet kunnen aanmelden omdat hun apparaat niet compliant is volgens het Intune-beleid, moeten systematische remediatiemaatregelen worden genomen om het apparaat compliant te maken. Het eerste stap in het remediatieproces betreft het identificeren van de specifieke redenen waarom het apparaat niet compliant is via de Intune-portal, waar gedetailleerde informatie beschikbaar is over de compliance-status en de specifieke vereisten die niet worden voldaan. Veelvoorkomende oorzaken voor niet-compliantie omvatten verouderde besturingssystemen die niet langer worden ondersteund of die bekende kwetsbaarheden bevatten, ontbrekende beveiligingsupdates die kritieke patches bevatten voor bekende beveiligingslekken, niet-geïnstalleerde of niet-bijgewerkte antivirussoftware die bescherming biedt tegen malware en andere bedreigingen, en niet-versleutelde schijven die gevoelige gegevens blootstellen aan ongeautoriseerde toegang wanneer apparaten worden gestolen of verloren. Zodra de specifieke oorzaken zijn geïdentificeerd, moeten gerichte acties worden ondernomen om deze problemen op te lossen, zoals het bijwerken van het besturingssysteem naar een ondersteunde versie, het installeren van alle beschikbare beveiligingsupdates, het installeren en configureren van antivirussoftware volgens organisatiebeleid, of het inschakelen van schijfversleuteling via BitLocker of een vergelijkbare technologie. Na het oplossen van de compliance-problemen moet het apparaat opnieuw worden gecontroleerd via de Intune-portal om te verifiëren dat het nu volledig compliant is en dat beheerders weer toegang kunnen krijgen tot de benodigde systemen. Wanneer beheerders niet kunnen aanmelden omdat ze geen phishing-resistente meervoudige authenticatie hebben geconfigureerd, moeten gerichte remediatiemaatregelen worden genomen om deze beheerders te helpen bij de registratie van geschikte authenticatiemethoden. Het eerste stap betreft het controleren van welke MFA-methoden de beheerder momenteel heeft geregistreerd via de Azure AD-portal, waar een overzicht beschikbaar is van alle geconfigureerde authenticatiemethoden. Als de beheerder alleen traditionele MFA-methoden heeft geregistreerd zoals SMS-codes of authenticator-apps, moet deze worden geïnstrueerd en geholpen bij het registreren van phishing-resistente authenticatiemethoden zoals FIDO2-security keys of Windows Hello for Business. De registratie kan worden uitgevoerd via de beveiligingsinstellingen in Azure AD, waar gebruikers kunnen kiezen om nieuwe authenticatiemethoden te registreren. Voor FIDO2-security keys moet de beheerder een compatibele hardware security key aanschaffen en configureren volgens de instructies van de fabrikant, terwijl voor Windows Hello for Business het apparaat moet beschikken over een Trusted Platform Module en moet worden geconfigureerd via de Windows-instellingen. Na registratie moet worden gecontroleerd of de beheerder nu correct kan aanmelden met de nieuwe phishing-resistente MFA-methode, en moet worden geverifieerd dat het Conditional Access-beleid de nieuwe methode accepteert en toegang verleent. Wanneer beheerders worden geblokkeerd vanwege hoog-risico aanmeldingen die worden gedetecteerd door Identity Protection, moeten zorgvuldige remediatiemaatregelen worden genomen om te bepalen of de blokkade legitiem is of het gevolg van een valse positieve detectie. Het eerste stap betreft het controleren van de specifieke redenen waarom de aanmelding als hoog risico wordt beschouwd via Identity Protection in Azure AD, waar gedetailleerde informatie beschikbaar is over de risicodetecties en de factoren die hebben bijgedragen aan het risiconiveau. Veelvoorkomende oorzaken voor hoog-risico detecties omvatten aanmeldingen vanaf onbekende geografische locaties die afwijken van het normale aanmeldingspatroon van de beheerder, aanmeldingen vanaf apparaten die zijn geïdentificeerd als gecompromitteerd of geïnfecteerd met malware, en aanmeldingen die overeenkomen met bekende aanvalspatronen zoals adversary-in-the-middle phishing-aanvallen. Als de aanmelding legitiem is en het risico een valse positieve detectie betreft, bijvoorbeeld wanneer een beheerder reist naar een nieuwe locatie of een nieuw apparaat gebruikt, kan de beheerder worden vrijgegeven via Identity Protection waarbij het risico handmatig wordt genegeerd na verificatie van de identiteit van de beheerder. Als de aanmelding daadwerkelijk verdacht is en mogelijk wijst op een gecompromitteerd account of een lopende aanval, moeten onmiddellijk aanvullende beveiligingsmaatregelen worden genomen zoals het resetten van wachtwoorden, het blokkeren van het account totdat verdere verificatie kan plaatsvinden, en het onderzoeken van de omstandigheden rondom de verdachte aanmelding om te bepalen of er sprake is van een beveiligingsincident. Wanneer het Conditional Access-beleid per ongeluk is uitgeschakeld of gewijzigd, moeten onmiddellijke remediatiemaatregelen worden genomen om de oorspronkelijke configuratie te herstellen en de beveiliging te waarborgen. Het eerste stap betreft het controleren van wat er precies is gewijzigd via de auditlogboeken in Azure AD, waar een gedetailleerd overzicht beschikbaar is van alle wijzigingen die zijn aangebracht aan Conditional Access-beleidsregels, inclusief wie de wijzigingen heeft gemaakt, wanneer ze zijn gemaakt, en wat de specifieke wijzigingen waren. Deze informatie is essentieel om te begrijpen wat er is gebeurd en om te bepalen of de wijzigingen opzettelijk waren of het gevolg van een fout of onbevoegde toegang. Vervolgens moet het beleid worden hersteld naar de oorspronkelijke configuratie die is gedocumenteerd in de beleidsdocumentatie, waarbij alle instellingen moeten worden gecontroleerd om te verifiëren dat ze overeenkomen met de bedoelde configuratie. Na het herstellen van de configuratie moet het beleid opnieuw worden ingeschakeld om ervoor te zorgen dat de beveiligingsmaatregelen weer actief zijn. Het is belangrijk om te controleren of alle beheerders nog steeds correct kunnen aanmelden na het herstellen van het beleid, en om te verifiëren dat er geen onbedoelde gevolgen zijn van de wijzigingen die zijn aangebracht. Wanneer break-glass accounts onterecht worden gebruikt voor reguliere beheerderstaken in plaats van alleen in noodsituaties, moeten corrigerende maatregelen worden genomen om te voorkomen dat deze accounts een zwakke schakel worden in de beveiligingsstrategie. Het eerste stap betreft het controleren van wie de break-glass accounts heeft gebruikt en waarom via de auditlogboeken in Azure AD, waar gedetailleerde informatie beschikbaar is over alle activiteiten die zijn uitgevoerd met break-glass accounts, inclusief welke beheerders de accounts hebben gebruikt, wanneer ze zijn gebruikt, en welke acties zijn uitgevoerd. Deze informatie helpt om te begrijpen waarom break-glass accounts worden gebruikt en of er legitieme redenen zijn voor het gebruik of dat het gebruik onterecht is. Vervolgens moeten de gebruikers worden geïnstrueerd dat break-glass accounts alleen mogen worden gebruikt in noodsituaties wanneer reguliere beheerdersaccounts niet toegankelijk zijn, en dat het gebruik van break-glass accounts voor reguliere taken een beveiligingsrisico vormt omdat deze accounts buiten het Conditional Access-beleid vallen. Als break-glass accounts regelmatig worden gebruikt voor reguliere taken, moet worden overwogen om de beveiligingsmaatregelen voor reguliere beheerdersaccounts te verbeteren om te voorkomen dat beheerders zich genoodzaakt voelen om break-glass accounts te gebruiken, bijvoorbeeld door het verbeteren van de gebruikerservaring van het Conditional Access-beleid of door het oplossen van technische problemen die normale aanmeldingen blokkeren.

Compliance & Frameworks

• CIS M365: Control 1.26 (L1) - Gelaagde beveiliging voor directoryrollen
• BIO: 09.04 - BIO: Bevoorrechte toegangsbescherming
• ISO 27001:2022: A.9.4.3 - Bevoorrechte toegangssysteem
• NIS2: Artikel - Bevoorrechte accountbeveiliging

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

Directory Rolbescherming via Conditional Access: Specifiek Conditional Access-beleid voor directoryrollen (Globale beheerder, Beveiligingsbeheerder, etc.): Phishing-resistente MFA (FIDO2, niet SMS), Compliante apparaten vereist, Blokkeer riskante aanmeldingen, Kortere sessieduur. Gelaagde beheerderbescherming. Vereist Azure AD P1. Implementatie: 4 uur technisch (FIDO2) + 4 uur organisatorisch. Verplicht CIS 1.26/1.38, BIO 9.04, NIS2, Zero Trust.

• Implementatietijd: 8 uur
• FTE required: 0.05 FTE