L1 BIO 09.04.02 ISO A.5.15 CIS Multiple (1.x series)

Quick Start: Voorwaardelijke Toegang Basis Policies - Week 1-2

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

💼 Management Samenvatting

Een robuuste baseline voor voorwaardelijke toegang vormt binnen twee weken de ruggengraat van een Zero Trust-aanpak: elke aanmelding wordt aan meervoudige verificatie onderworpen, verouderde protocollen verdwijnen, uitsluitend beheerde apparaten mogen sessies openen en aanmeldingen vanuit onbekende regio's worden automatisch geweerd. Deze handleiding gidst beveiligingsteams stap voor stap zodat de Microsoft 365-tenant dezelfde beschermingslaag krijgt als toonaangevende Nederlandse overheidsorganisaties, zonder de continuïteit van kritieke werkprocessen te verstoren.

Aanbeveling
IMPLEMENT
Risico zonder
Critical
Risk Score
10/10
Implementatie
32u (tech: 16u)
Van toepassing op:
✓ M365
✓ Azure AD
✓ voorwaardelijke toegang

Voorwaardelijke toegang is de beslislaag van Microsoft Entra ID die bij elke aanmelding toetst of de gebruiker, het apparaat, de locatie en de applicatie aan het gewenste risicoprofiel voldoen. Wanneer deze laag niet volledig wordt ingevuld, blijven structurele gaten bestaan: sommige SaaS-diensten eisen geen MFA, verouderde protocollen kunnen buiten het zicht authenticeren en apparaten buiten beheer krijgen toegang tot gevoelige gegevens. Overheidsorganisaties moeten bovendien aantonen dat toegang uitsluitend wordt verleend op basis van actuele signalen uit logging, dreigingsinformatie en compliancebeleid. Een consistente set basisbeleidsregels levert dat bewijs. Zij verplichten meervoudige verificatie voor elk scenario, blokkeren pogingen via protocollen zonder moderne beveiliging, dwingen apparaatcompliance af volgens de Intune-standaard en houden onbekende of verdachte locaties tegen. Tegelijkertijd verschaffen risk-gebaseerde beleidsregels inzicht in afwijkende patronen zodat securityteams direct kunnen ingrijpen. Zonder deze maatregelen ontstaan onverklaarbare toegangen in audit-trails, blijft de grootste bron van accountmisbruik intact en wordt het vrijwel onmogelijk om de naleving van BIO, AVG en NIS2 overtuigend te onderbouwen.

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

Implementatie

Deze gids beschrijft drie opeenvolgende werkstromen die samen de volledige basis leveren. In de eerste week worden de wereldwijde policies (CA000-CA014) uitgerold waarmee elke gebruiker, applicatie en beheertool dezelfde MFA- en sessie-eisen krijgt en waarmee legacy-authenticatie definitief wordt uitgezet. De tweede week richt zich op administrators (CA100-CA105) en zorgt voor strengere eisen rond apparaatstatus, sessieduur, locaties en risicosignalen zodat kritieke beheerpaden hermetisch worden afgesloten. De derde golf (CA200-CA210) biedt verfijning voor interne gebruikers door apparaatcompliance, app-bescherming en downloadbeperkingen te koppelen aan concrete bedrijfsprocessen. Alle policies worden eerst in report-only uitgevoerd, ondersteund door automatiseringsscripts voor uitrol en beheergroepen, zodat organisaties gecontroleerd kunnen testen en vervolgens gefaseerd kunnen handhaven.

Vereisten

Deze implementatie richt zich op organisaties die de eerdere quick-starts hebben voltooid en binnen twee weken aantoonbaar resultaat willen boeken. De onderstaande vereisten borgen dat beleid zonder verstoring kan worden ingevoerd, dat beheerrollen en tooling klaarstaan en dat audit- en escalatieprocedures meteen actief zijn voor CISO, privacy officer en ICT-beheer.

  1. Azure AD Premium P1-licenties zijn minimaal vereist zodat voorwaardelijke toegang, templates en rapportages beschikbaar zijn; wie direct risk-gebaseerde policies wil activeren reserveert tegelijkertijd Entra ID P2-capaciteit en legt vast welke gebruikers of dienstaccounts onder de licentie vallen, zodat auditors later kunnen zien dat licentievoorwaarden zijn geborgd.
  2. Quick Start 01 (meervoudige authenticatie) moet volledig zijn afgerond, inclusief enforced registratie, noodprocedures en een helpdesk-draaiurenplanning, omdat voorwaardelijke toegang de reeds ingestelde MFA-methode hergebruikt en er anders inconsistent gedrag ontstaat.
  3. Quick Start 02 zorgt voor break-glass-accounts en een exclusiegroep; deze accounts moeten aantoonbaar getest zijn, MFA mogen overslaan en in een apart kluisdossier zijn opgenomen zodat ze bij een lock-out direct beschikbaar zijn.
  4. Een global administrator of Conditional Access Administrator moet de configuraties uitvoeren en vooraf met de security officer de scope, auditverantwoordelijkheden en wijzigingsprocedure vastleggen, zodat wijzigingen traceerbaar blijven en het change-advisory-board inzicht houdt.
  5. Een beheerd werkstation met PowerShell 7, Microsoft.Graph.Identity.SignIns en Microsoft.Graph.Groups moet beschikbaar zijn; het station moet compliant zijn volgens Intune, beschikt over just-in-time lokale adminrechten en is verbonden via een vertrouwd netwerksegment.
  6. Plan een testperiode van minimaal twee weken in report-only, inclusief communicatie naar business- en applicatie-eigenaren, dagelijkse reviewmomenten en een formeel go/no-go-besluit voor handhaving; documenteer deze planning in het securityjaarplan.
  7. Leg een rollbackprocedure vast waarin staat hoe policies bij verstoringen veilig worden teruggedraaid, hoe break-glass-accounts worden gebruikt, welke diensten prioriteit krijgen en hoe communicatie richting directie, meldkamer en servicedesk verloopt.
  8. Intune-devicecompliancebeleid en encryptiestandaarden moeten al uitgerold zijn of minimaal in pilotstatus zitten, zodat policies die afhankelijk zijn van compliant apparaten ook daadwerkelijk onderscheid kunnen maken tussen beheerde en onbeheerde endpoints.
  9. Het monitoringteam moet directe toegang hebben tot sign-in-logs, de rapportages van voorwaardelijke toegang en SIEM-waarschuwingen; stel een dagelijkse reviewtaak in waarin afwijkingen, foutcodes en uitzonderingen worden besproken en vastgelegd in het operations-runbook.

Implementatie (Week 1-2)

Gebruik PowerShell-script 03-conditional-access-basis.ps1 (functie Invoke-Implementation) – Voert de geautomatiseerde baseline-implementatie uit, koppelt de templates aan de juiste groepen, logt elke wijziging met versienummer en schrijft de resultaten weg naar het operationslogboek zodat wijzigingen volledig auditeerbaar blijven..

Week 1 draait om het uitrollen van de wereldwijde baselines. We starten met een inventarisatie van gebruikersgroepen, kritieke applicaties en bestaande uitzonderingen en plaatsen vervolgens de templates in een gecontroleerde staging. Elke policy krijgt een naamconventie (CA000-CA014) en een beschrijving met doel, verantwoordelijke en geplande enforcementsdatum. Dagelijkse stand-ups tussen identitybeheer, SOC en servicedesk zorgen ervoor dat signaalstromen, communicatie en change-registratie naadloos op elkaar aansluiten.

Gebruik PowerShell-script 03-conditional-access-basis.ps1 (functie Invoke-Remediation) – Zet de policies gecontroleerd in report-only, controleert per policy op conflicterende assignments en publiceert een CSV-overzicht met toegepaste voorwaarden, uitzonderingsgroepen en geplande evaluatiedata zodat beheer en security dezelfde broninformatie gebruiken..

  1. Dag 1-2: we richten de globale policies in door eerst de referentiegroepen (All Users, All Cloud Apps, Break-Glass) te synchroniseren, vervolgens de templates CA000-CA014 in report-only te plaatsen en direct na elke publicatie de "What If"-analyse te draaien zodat we exact weten welk percentage aanmeldingen geraakt wordt en welke uitzonderingen nodig zijn.
  2. CA000: deze policy zorgt ervoor dat elke moderne aanmelding, ongeacht applicatie of locatie, meervoudige verificatie eist; we maken vooraf uitzonderingsgroepen voor break-glass-accounts en serviceprincipals en controleren via sign-in-logs of er processen bestaan die nog wachtwoorden cachen.
  3. CA002: met deze regel blokkeren we alle protocollen zonder moderne authenticatie zoals IMAP, POP en SMTP AUTH; het script zet het beleid in rapportage en koppelt Entra-signalen zodat we een lijst krijgen van systemen die nog migratiebegeleiding nodig hebben.
  4. CA003: voor apparaatregistratie en join-acties verplichten we MFA zodat kwaadwillenden geen schaduwapparaten kunnen toevoegen; we testen scenario's zoals Autopilot, handmatige join en Azure VM-registraties en leggen afwijkingen vast voor de Intune-beheerders.
  5. CA013: toegang tot Azure-beheerportalen, PowerShell en CLI wordt achter MFA geplaatst; we controleren of alle beheergroepen gebruikmaken van PIM en documenteren hoe just-in-time rechten samenwerken met deze policy zodat beheerders precies weten welke stappen nodig zijn bij spoedincidenten.
  6. CA014: alle afzonderlijke beheerportalen, zoals Microsoft Intune, Defender en Purview, vallen onder een eigen regel waarmee MFA en eventueel vertrouwde locaties verplicht worden; de policybeschrijving bevat per portal een contactpersoon zodat wijzigingen afgestemd kunnen worden.
  7. Dag 3-4: we verschuiven de focus naar administratorpolicies en bepalen per rol (Global Admin, Security Admin, Application Admin) welke extra eisen gelden rond apparaatcompliance, sessieduur en locatie; de resultaten worden gedeeld met het change-advisory-board voor expliciete goedkeuring.
  8. CA100: administrators moeten vanaf nu zowel MFA gebruiken als werken vanaf een compliant of hybrid joined apparaat; we controleren via Intune-rapportages welke beheerders aan de eisen voldoen en plannen indien nodig uitlevering van een beheerwerkstation.
  9. CA101: aanmeldingen van administrators vanuit onbekende of risicovolle locaties worden geblokkeerd; we vullen de named locations-lijst met Nederlandse datacenters, kantoorlocaties en VPN-uitgangen en leggen het proces vast voor het toevoegen van tijdelijke locaties tijdens crisissituaties.
  10. CA102: de sessieduur voor beheerders wordt verkort naar vier uur zodat herauthenticatie verplicht blijft; we communiceren dit naar beheerteams en verifiëren via rapportages of aanmeldingen daadwerkelijk opnieuw worden uitgedaagd, waarna we de instelling eventueel aanscherpen naar twee uur voor hoog-risicorollen.
  11. CA103: persoonlijke of onbeheerde apparaten worden uitgesloten voor beheerders door het gebruik van de filter op devicestatus; we documenteren welke sandboxomgevingen een uitzondering krijgen en zorgen dat deze uitzonderingen gekoppeld zijn aan tijdelijke access-packages.
  12. CA104: voor global administrators eisen we verbinding vanuit een vertrouwde locatie; alleen door het operations-team goedgekeurde VPN-uitgangen komen op de whitelist en elke wijziging wordt via een vierogenprincipe doorgevoerd om misbruik te voorkomen.
  13. Dag 5: we pakken de policies voor interne gebruikers op en stemmen met HR en communicatie af hoe de wijzigingen worden aangekondigd, welke trainingen nodig zijn en hoe servicepunten vragen rond downloadbeperkingen beantwoorden.
  14. CA200: toegang tot gevoelige applicaties vereist een compliant of hybrid joined apparaat; we koppelen het beleid aan de Intune-evaluatie, beschrijven de uitzonderingsprocedure voor buitenlandse reizen en controleren of gedeelde werkstations in gemeenten correct worden herkend.
  15. CA201: alleen goedgekeurde client-apps zoals Outlook, Teams en de officiële mobiele apps krijgen toegang; we testen scenario's zoals oude native mailclients en geven adoptieteams instructies om gebruikers naar de juiste appstores te begeleiden.
  16. CA202: downloads vanaf onbeheerde apparaten worden geblokkeerd of beperkt tot een web-only ervaring; het beleid verwijst naar Defender for Cloud Apps zodat sessiecontroles kunnen afdwingen dat gevoelige documenten niet lokaal worden opgeslagen.
  17. Alle policies blijven gedurende de eerste twee weken in report-only; dagelijks vergelijken we de policyresultaten met daadwerkelijke verstoringen en beschrijven we per policy de criteria waaronder enforcement wordt ingeschakeld, inclusief akkoord van proceseigenaren.
  18. Verify: na elke uitrol valideren we via sign-in-logs, "What If"-scenario's en handmatige tests dat assignments, uitsluitingen en gebruikerservaring correct zijn; alle bevindingen worden in het changeticket en het securityjournaal opgenomen inclusief een herstelplan voor afwijkingen.

Week 2 staat volledig in het teken van testen en validatie. We analyseren per policy de rapportagemeldingen, koppelen ze aan helpdesktickets en spreken applicatie-eigenaren om de bedrijfsimpact te toetsen. Elk incident krijgt een classificatie met voorgestelde maatregel en einddatum. Het doel is aan te tonen dat de policies voorspelbaar gedrag laten zien en dat uitzonderingen aantoonbaar tijdelijk zijn. De SOC-analisten leveren dagelijks een rapport, terwijl de change manager twee beslismomenten organiseert om te bepalen welke policies klaar zijn voor handhaving.

  1. Dagelijkse monitoring: het SOC controleert elke ochtend en avond de sign-in-logs, het tabblad Voorwaardelijke Toegang en eventuele Defender-waarschuwingen, zodat trends tijdig zichtbaar zijn en afwijkingen direct worden teruggekoppeld aan de productteams.
  2. Analyseer de uitkomsten van de "What If"-tool en de exports uit het script om te bepalen hoeveel aanmeldingen geblokkeerd zouden worden, welk type gebruiker geraakt wordt en of de Business Impact Analyse overeenkomt met de werkelijkheid.
  3. Identificeer structurele issues door technische signalen te combineren met gebruikersfeedback; beschrijf per bevinding het risico, de impact op primaire processen en de voorgestelde maatregel zodat het change-advisory-board onderbouwd kan beslissen.
  4. Serviceaccounts zonder meervoudige verificatie worden geïnventariseerd, beoordeeld op noodzaak en waar mogelijk omgezet naar beheerde of workload-identiteiten; resterende accounts krijgen een tijdelijke uitzondering met een expliciete einddatum.
  5. Legacy-apps die nog op IMAP, POP of SMTP AUTH vertrouwen krijgen een migratieplan met eigenaar, planning en tijdelijke beveiligingsmaatregelen zoals app-wachtwoorden blokkeren en transportversleuteling afdwingen.
  6. Niet-conforme apparaten worden opgespoord via Intune-rapportages en Endpoint Analytics; gebruikers ontvangen instructies voor inschrijving en encryptie en het device-team monitort of zij binnen de afgesproken termijn compliant worden.
  7. VPN- of externe gebruikers die door locatiebeleid geraakt worden krijgen een analyse van hun verbindingspad, waarna we ofwel de vertrouwde locatie aanpassen of een alternatief aanbieden zoals een managed VDI-werkplek.
  8. Policies worden verfijnd door voorwaarden toe te voegen, sessiecontroles aan te scherpen of uitzonderingen te verwijderen; leg steeds vast wat het doel is en welke risico-indicator bevestigt dat het probleem is opgelost.
  9. Serviceaccounts die toch een uitzondering nodig hebben worden uitsluitend via de groep 'CA-Exclusion-ServiceAccounts' beheerd; elke toevoeging krijgt een ticketnummer, verantwoordelijke en evaluatiedatum zodat de groep klein blijft.
  10. De grace-periode voor apparaatcompliance wordt aangepast op basis van echte enrollments; als gebruikers gemiddeld drie dagen nodig hebben, verhogen we tijdelijk de drempel maar plannen we extra ondersteuning om terug te gaan naar één dag.
  11. Named locations voor kantoren en VPN worden opnieuw geverifieerd met netwerkbeheer; IP-bereiken worden voorzien van beschrijving, eigenaar en vervaldatum zodat oude ranges automatisch worden verwijderd.
  12. Executive approval: de CISO en proceseigenaren ontvangen een impactanalyse met grafieken, een overzicht van resterende uitzonderingen en een voorstel voor het enforcementschema, zodat zij formeel akkoord kunnen geven en de uitrol bestuurlijk is geborgd.

Week 3 draait om gefaseerde handhaving. We starten met een pilotgroep die het volledige pakket activeert, analyseren binnen 24 uur de resultaten en zetten daarna stap voor stap de organisatie over. Elke stap wordt ondersteund door gerichte communicatie, aanvullende servicedeskcapaciteit en realtime dashboards zodat bestuurders live kunnen volgen welke gebruikers zijn omgeschakeld en of er verstoringen optreden.

  1. Dag 1: activeer de kritieke policies (MFA, blokkeren van legacy-authenticatie en beheerderscontroles) voor de pilotgroep bestaande uit het IT-team, zodat eventuele technische problemen snel kunnen worden opgelost door dezelfde specialisten die de policies beheren.
  2. Dag 2-3: monitor de pilot continu, verzamel feedback via een speciaal serviceloket, los incidenten dezelfde dag op en documenteer lessons learned inclusief eventuele aanpassingen die nodig zijn voor bredere uitrol.
  3. Dag 4: schakel de kritieke policies in voor ongeveer de helft van de gebruikerspopulatie, bij voorkeur gespreid over meerdere organisatieonderdelen, en houd nauwlettend bij of specifieke processen of applicaties extra begeleiding nodig hebben.
  4. Dag 5: activeer de policies voor de resterende gebruikers en zorg dat communicatiekanalen zoals intranet, pushberichten en leidinggevende updates hetzelfde verhaal vertellen over waarom de wijziging noodzakelijk is en hoe ondersteuning beschikbaar is.
  5. Week 4: voer de resterende policies (apparaatcompliance, app-controles, downloadbeperkingen) in volgens het afgesproken volgplan; combineer dit met aanvullende adoptietrainingen zodat medewerkers begrijpen hoe ze veilig blijven werken.
  6. Finale validatie: bevestig via dashboards en steekproeven dat alle policies daadwerkelijk zijn ingeschakeld, dat uitzonderingen traceerbare einddata hebben en dat gebruikers voldoen aan de nieuwe eisen; rapporteer dit aan CISO, CIO en auditteam.

monitoring

Gebruik PowerShell-script 03-conditional-access-basis.ps1 (functie Invoke-Monitoring) – Start het monitoringdashboard, haalt via Microsoft Graph de statistieken over aanmeldingssucces, policybeslissingen en uitzonderingen op en archiveert iedere run in een beveiligde storage-account zodat zowel SOC als auditors inzicht krijgen in trends en incidenten. Het script controleert daarnaast of alle logging-agents actief zijn, vergelijkt de huidige waarden met vooraf ingestelde drempels en verstuurt automatisch een melding zodra een indicator afwijkt, zodat niemand afhankelijk is van handmatige controles..

De eerste maand na implementatie vraagt om dagelijkse aandacht. Monitoring combineert technische telemetrie met gebruikerssignalen: SOC-analisten controleren de dashboards, de servicedesk levert samenvattingen van meldingen en change managers toetsen of uitzonderingen binnen de afgesproken grenzen blijven. Elk rapport bevat een overzicht van de belangrijkste KPI's, de status van openstaande uitzonderingen en een lijst met aanbevelingen. De resultaten worden gedeeld met CISO, privacy officer en proceseigenaren zodat zij weten welke maatregelen effect hebben en waar moet worden bijgestuurd.

  1. De sign-in-succesratio moet structureel boven 95% liggen; dalingen wijzen op verkeerde toewijzingen, ontbrekende apparaten of gebrekkige gebruikerscommunicatie en worden onderzocht door het SOC, waarna het resultaat inclusief oorzaakanalyse aan de CISO wordt gemeld. Zakt de ratio drie dagen op rij onder de norm, dan pauzeert het team de verdere handhaving totdat corrigerende maatregelen aantoonbaar zijn uitgevoerd.
  2. Analyseer dagelijks de CA-failures per policy en per applicatie; excessieve blokkades vormen input om voorwaarden te verfijnen, extra adoptietraining te plannen of uitzonderingen gecontroleerd toe te voegen met een heldere einddatum. De bevindingen worden gedeeld met applicatie-eigenaren zodat zij hun gebruikers tijdig kunnen informeren over aanstaande wijzigingen.
  3. Helpdesktickets rond voorwaardelijke toegang worden geclassificeerd naar thema (MFA, apparaat, locatie) en vergeleken met de telemetrie; trends leiden tot aanvullende instructies, zelfservice-artikelen of versnelde Intune-onboarding. De servicedesk rapporteert wekelijks welke top drie vragen spelen en welke acties zijn ondernomen om de druk te verlagen.
  4. Beheer van uitsluitingsgroepen gebeurt via het vierogenprincipe: bij elke wijziging wordt gecontroleerd of de aanvrager geautoriseerd is, of er een ticketnummer aanwezig is en of de uitzondering een automatische herbeoordelingsdatum heeft. Het monitoringrapport bevat een overzicht van toegevoegde en verwijderde leden zodat auditors zien dat het principe 'least privilege' wordt gevolgd.
  5. Elke policywijziging wordt realtime bewaakt via activity alerts in Microsoft Entra; bij ongeautoriseerde aanpassingen wordt direct een incident geopend, worden de oorspronkelijke instellingen vanuit het script teruggezet en wordt bepaald of er aanvullende maatregelen zoals PIM-vereisten of conditional access change-approvals nodig zijn.

Compliance en Auditing

Voorwaardelijke toegang vormt in de Nederlandse Baseline voor Veilige Cloud de tastbare uitwerking van Zero Trust en sluit direct aan op de verplichting uit de BIO en NIS2 om identiteiten continu te verifiëren. De baseline die in dit document wordt beschreven zorgt ervoor dat elke gebruiker, applicatie en beheersessie aan dezelfde controlepunten wordt onderworpen, waardoor “least privilege” daadwerkelijk afdwingbaar wordt. Door de policies centraal te documenteren en te koppelen aan changeprocedures kan elke auditor exact zien welke maatregelen actief zijn en welke risico’s zij mitigeren. De aanpak volgt bovendien de aanbevelingen van het NCSC-NL om privileges minimaal te houden en om verdachte activiteiten onmiddellijk te isoleren. Binnen de Baseline Informatiebeveiliging Overheid (BIO) adresseert dit pakket vooral thema 09 Toegangsbeveiliging: identiteiten worden sterk geauthenticeerd, sessies worden ingekort en apparaten moeten aantoonbaar voldoen aan beheer- en encryptie-eisen. Tegelijkertijd ondersteunt het pakket AVG-artikel 32 omdat organisaties kunnen aantonen dat toegang tot persoonsgegevens alleen plaatsvindt na risicogestuurde controles en dat gegevensstromen worden gelogd voor reconstructie. De rapportages uit de monitoringfase vormen bewijs dat de maatregelen niet alleen zijn geconfigureerd, maar ook daadwerkelijk functioneren en op effectiviteit worden beoordeeld. Dit sluit aan op de accountability-eis: bestuurders kunnen aantonen dat passende technische en organisatorische maatregelen zijn genomen en periodiek worden herzien. Ook internationale kaders zijn direct afgedekt. De CIS Microsoft 365 Foundations beveelt meerdere conditional-access-regels aan; de hier opgenomen CA000-CA202 policies corresponderen met de relevante controls en geven bovendien extra context voor publieke instellingen. ISO 27001:2022 controle A.5.15 verlangt dat organisaties procedures hebben voor toegang tot informatie; de combinatie van groepsbeheer, uitzonderingsbeheer en rapportage demonstreert dat. NIS2 artikel 21 benoemt identiteit en toegangsbeheer als kernonderdeel van de zorgplicht en eist dat daarbij actuele dreigingsinformatie wordt gebruikt. Door risk-based policies en Identity Protection-signalen op te nemen, laat de organisatie zien dat realtime risico-indicatoren meewegen in de besluitvorming. Tot slot sluit de aanpak aan op NIST SP 800-207 (Zero Trust Architecture) waarin identity, device en context centraal staan. Om naleving overtuigend te kunnen bewijzen, wordt elke policy gekoppeld aan audit-evidence: een export van actieve policies, een gedateerde goedkeuringsmail, monitoringrapporten en het register van uitzonderingen. Tijdens audits kan men daardoor snel aantonen wie verantwoordelijk is, wanneer de laatste review heeft plaatsgevonden en welke correctieve acties zijn ingezet. Alle bewijsstukken worden zeven jaar bewaard zodat zij voldoen aan de archief- en BIO-eisen. Zo ontstaat een sluitend verhaal richting CIO, toezichthouders en interne accountants dat de Nederlandse Baseline voor Veilige Cloud niet alleen beleidsmatig is vastgelegd, maar ook aantoonbaar werkt in de praktijk.

Remediatie

Gebruik PowerShell-script 03-conditional-access-basis.ps1 (functie Invoke-Remediation) – Het herstelproces start met het detecteren van een afwijking: een legitieme gebruiker raakt geblokkeerd, een applicatie verliest toegang of er verschijnt een ongeautoriseerde policywijziging. De functie Invoke-Remediation voert dan een gecontroleerde rollback uit. Het script haalt de laatst bekende goede configuratie uit het versieregister, vergelijkt die met de huidige situatie en toont een overzicht van verschillen inclusief toewijzingen, uitzonderingen en sessie-instellingen. De operator ziet daarbij welke change-ID, welk account en welke tijdstempel bij elke wijziging horen. Alleen wanneer de operator het vier-ogen-akkoord bevraagt en bevestigt, worden de wijzigingen toegepast zodat noodgrepen altijd traceerbaar zijn. Het rapport bevat bovendien een referentie naar het bijbehorende service- of incidentticket zodat auditsporen logisch aan elkaar verbonden blijven. Vervolgens worden de meest kritieke acties uitgevoerd. De betrokken policy wordt tijdelijk naar report-only of disabled gezet, terwijl de break-glass-accounts beschikbaar worden gemaakt voor de getroffen beheerders. Het script zorgt ervoor dat noodtoegang automatisch een einddatum krijgt, dat de kredieten worden vastgelegd in een kluis en dat alle stappen in het incidentlogboek terechtkomen. Parallel hieraan wordt een communicatiebericht opgesteld voor servicedesk, security operations, proceseigenaren en – indien nodig – de meldkamer, zodat iedereen weet welke maatregelen gelden en welke gebruikersgroep is geraakt. Daarnaast noteert de communicatieafdeling welke kanalen zijn gebruikt en welke vragen binnenkomen, zodat het herstelplan ook de gebruikerservaring adresseert. Daarna volgt de technische correctie. Invoke-Remediation herstelt de gewenste instellingen, verwijdert ongeautoriseerde uitzonderingen en voert een integriteitscheck uit op de gekoppelde groepen. Indien nodig wordt een aanvullend script gestart om Intune-compliance te herbevestigen of om Defender for Cloud Apps policies opnieuw te synchroniseren. Zodra de configuratie klopt, draait het team een volledige set "What If"-scenario's, voert het script proefaanmeldingen uit met testaccounts en controleert het monitoringdashboard of de fout is verdwenen. Pas als alle controles groen zijn en het CAB akkoord geeft, wordt de policy opnieuw geactiveerd. Het team valideert daarna opnieuw de gebruikerservaring door samen met proceseigenaren realistische scenario's door te lopen. Tot slot documenteert het team het incident volgens de eisen uit de Nederlandse Baseline voor Veilige Cloud. Het script genereert een rapport met tijdstempels, betrokken accounts, genomen stappen en aanbevelingen voor structurele verbeteringen. Dit rapport wordt toegevoegd aan het CAB-dossier, gedeeld met de CISO en opgenomen in de auditmap. Lessons learned worden verwerkt in trainingsmateriaal voor beheerders en in nieuwe controles in het monitoringdashboard, terwijl alle herstelacties minimaal zeven jaar worden bewaard in lijn met de BIO-retentie-eisen. Zo ontstaat een herhaalbaar herstelproces dat de beschikbaarheid van diensten beschermt, kennis borgt en laat zien dat voorwaardelijke toegang niet alleen kan worden uitgerold, maar ook verantwoord kan worden beheerd..

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
<# .SYNOPSIS Quick Start: Conditional Access Basis .DESCRIPTION Deployt VOLLEDIGE set van basis Conditional Access policies via templates. Gebruikt kant-en-klare templates uit _FrameWorkBackgrounds/Conditional-Access/Policies. INCLUDES: - CA000: MFA voor alle gebruikers - CA001: Block ongewenste landen - CA002: Block legacy authentication - CA003: MFA voor device registration - CA013: MFA voor Azure Management - CA014: MFA voor Admin Portals - CA100-105: Admin protectie - CA200-210: Internal users protectie .NOTES Filename: 03-conditional-access-basis.ps1 Author: Nederlandse Baseline voor Veilige Cloud Created: 2025-10-16 Related JSON: content/quick-start/03-conditional-access-basis.json Priority: Week 1-2 #> #Requires -Version 5.1 #Requires -Modules Microsoft.Graph.Identity.SignIns, Microsoft.Graph.Groups [CmdletBinding()] param( [Parameter(HelpMessage = "Monitor CA policies")] [switch]$Monitoring, [Parameter(HelpMessage = "Create baseline CA policies")] [switch]$Remediation, [Parameter(HelpMessage = "Full implementation with all policies")] [switch]$Implementation, [Parameter(HelpMessage = "Week 4: Enable policies (report-only → enabled)")] [switch]$Enforcement, [Parameter(HelpMessage = "Revert (disable all policies)")] [switch]$Revert, [Parameter(HelpMessage = "Preview changes")] [switch]$WhatIf ) $ErrorActionPreference = 'Stop' Write-Host "`n========================================" -ForegroundColor Cyan Write-Host "Quick Start: Conditional Access Basis" -ForegroundColor Cyan Write-Host "WEEK 1-2" -ForegroundColor Cyan Write-Host "Nederlandse Baseline voor Veilige Cloud" -ForegroundColor Cyan Write-Host "========================================`n" -ForegroundColor Cyan # Import CA Template module $modulePath = Join-Path $PSScriptRoot "..\modules\ConditionalAccess-Templates.psm1" Import-Module $modulePath -Force function Test-Compliance { [CmdletBinding()] param() return Invoke-Monitoring } function Invoke-Monitoring { <# .SYNOPSIS Monitors CA policies status #> [CmdletBinding()] param() try { Write-Host "`nMonitoring:" -ForegroundColor Yellow Connect-MgGraph -Scopes 'Policy.Read.All' -NoWelcome $result = @{ isCompliant = $false timestamp = Get-Date totalPolicies = 0 enabledPolicies = 0 reportOnlyPolicies = 0 disabledPolicies = 0 policies = @() } Write-Host "Checking Conditional Access policies..." -ForegroundColor Gray $allPolicies = Get-MgIdentityConditionalAccessPolicy $result.totalPolicies = $allPolicies.Count foreach ($policy in $allPolicies) { $policyInfo = @{ name = $policy.DisplayName state = $policy.State id = $policy.Id } $result.policies += $policyInfo switch ($policy.State) { 'enabled' { $result.enabledPolicies++ Write-Host " [OK] $($policy.DisplayName)" -ForegroundColor Green } 'enabledForReportingButNotEnforced' { $result.reportOnlyPolicies++ Write-Host " ⚠️ $($policy.DisplayName) [REPORT-ONLY]" -ForegroundColor Yellow } 'disabled' { $result.disabledPolicies++ Write-Host " [FAIL] $($policy.DisplayName) [DISABLED]" -ForegroundColor Red } } } # Determine compliance if ($result.totalPolicies -ge 5 -and ($result.enabledPolicies + $result.reportOnlyPolicies) -ge 5) { $result.isCompliant = $true } # Summary Write-Host "`n========================================" -ForegroundColor Cyan Write-Host "SUMMARY:" -ForegroundColor Cyan Write-Host " Total policies: $($result.totalPolicies)" -ForegroundColor White Write-Host " Enabled: $($result.enabledPolicies)" -ForegroundColor Green Write-Host " Report-only: $($result.reportOnlyPolicies)" -ForegroundColor Yellow Write-Host " Disabled: $($result.disabledPolicies)" -ForegroundColor Red if ($result.isCompliant) { Write-Host "`n[OK] COMPLIANT: CA policies configured" -ForegroundColor Green } else { Write-Host "`n[FAIL] NON-COMPLIANT: Insufficient CA policies" -ForegroundColor Red } return $result } catch { Write-Host "`n[FAIL] ERROR: $_" -ForegroundColor Red throw } } function Invoke-Remediation { <# .SYNOPSIS Deployt basis CA policies (Global set: CA000-CA014) #> [CmdletBinding(SupportsShouldProcess)] param() try { Write-Host "`nRemediation: Deploying baseline CA policies..." -ForegroundColor Yellow Connect-MgGraph -Scopes 'Policy.ReadWrite.ConditionalAccess', 'Group.ReadWrite.All' -NoWelcome # STAP 1: Maak break-glass group aan Write-Host "`nSTEP 1: Create exclusion groups..." -ForegroundColor Cyan $breakGlassGroupName = "CA-Exclusion-BreakGlass" $breakGlassGroup = Get-MgGroup -Filter "displayName eq '$breakGlassGroupName'" -ErrorAction SilentlyContinue if (-not $breakGlassGroup) { Write-Host " Creating: $breakGlassGroupName" -ForegroundColor Gray if ($PSCmdlet.ShouldProcess($breakGlassGroupName, "Create group")) { $breakGlassGroup = New-MgGroup -DisplayName $breakGlassGroupName ` -MailEnabled:$false ` -SecurityEnabled:$true ` -MailNickname ($breakGlassGroupName -replace '[^a-zA-Z0-9]', '') ` -Description "Break-glass accounts excluded from CA policies" Write-Host " [OK] Created: $($breakGlassGroup.Id)" -ForegroundColor Green } } else { Write-Host " [OK] Group exists: $breakGlassGroupName" -ForegroundColor Green } # STAP 2: Deploy Global policies (CA000-CA014) Write-Host "`nSTEP 2: Deploy Global CA policies (CA000-CA014)..." -ForegroundColor Cyan $globalPolicies = @( 'CA000-Global-IdentityProtection-AnyApp-AnyPlatform-MFA', 'CA002-Global-IdentityProtection-AnyApp-AnyPlatform-Block-LegacyAuthentication', 'CA003-Global-BaseProtection-RegisterOrJoin-AnyPlatform-MFA', 'CA013-Global-IdentityProtection-AzureManagement-AnyPlatform-MFA', 'CA014-Global-IdentityProtection-AdminPortals-AnyPlatform-MFA' ) foreach ($policyName in $globalPolicies) { try { Write-Host "`n Deploying: $policyName" -ForegroundColor Yellow $template = Import-CATemplate -TemplateName $policyName # Deploy in report-only mode Deploy-CAPolicy -Template $template ` -State 'enabledForReportingButNotEnforced' ` -ExcludedGroups @($breakGlassGroupName) ` -WhatIf:$WhatIf } catch { Write-Host " ⚠️ Error deploying $policyName : $_" -ForegroundColor Yellow } } Write-Host "`n[OK] Remediation completed" -ForegroundColor Green Write-Host "`n⚠️ Policies deployed in REPORT-ONLY mode" -ForegroundColor Yellow Write-Host " Use -Enforcement to enable after testing" -ForegroundColor Gray } catch { Write-Host "`n[FAIL] ERROR: $_" -ForegroundColor Red throw } } function Invoke-Implementation { <# .SYNOPSIS COMPLETE implementation: Global + Admin + Internal policies #> [CmdletBinding(SupportsShouldProcess)] param() try { Write-Host "`nImplementation: COMPLETE CA baseline..." -ForegroundColor Yellow Connect-MgGraph -Scopes 'Policy.ReadWrite.ConditionalAccess', 'Group.ReadWrite.All' -NoWelcome # STAP 1: Maak exclusion groups Write-Host "`nSTEP 1: Create ALL exclusion groups..." -ForegroundColor Cyan $groups = @( 'CA-Exclusion-BreakGlass', 'CA-Exclusion-ServiceAccounts', 'CA-Exclusion-Admins-Temporary', 'CA-Exclusion-Testing' ) foreach ($groupName in $groups) { $group = Get-MgGroup -Filter "displayName eq '$groupName'" -ErrorAction SilentlyContinue if (-not $group) { Write-Host " Creating: $groupName" -ForegroundColor Gray if ($PSCmdlet.ShouldProcess($groupName, "Create group")) { $group = New-MgGroup -DisplayName $groupName ` -MailEnabled:$false ` -SecurityEnabled:$true ` -MailNickname ($groupName -replace '[^a-zA-Z0-9]', '') ` -Description "CA exclusion group: $groupName" Write-Host " [OK] Created" -ForegroundColor Green } } else { Write-Host " [OK] Exists: $groupName" -ForegroundColor Green } } # STAP 2: Deploy ALL baseline policies Write-Host "`nSTEP 2: Deploy ALL baseline CA policies..." -ForegroundColor Cyan $categories = Get-CATemplatesByCategory # Global policies (CA000-CA014) Write-Host "`n [GLOBAL POLICIES]" -ForegroundColor Magenta foreach ($template in $categories.Global | Select-Object -First 15) { try { $templateObj = Import-CATemplate -TemplateName ($template.Name -replace '\.json$', '') Deploy-CAPolicy -Template $templateObj ` -State 'enabledForReportingButNotEnforced' ` -ExcludedGroups @('CA-Exclusion-BreakGlass') ` -WhatIf:$WhatIf } catch { Write-Host " ⚠️ Error: $_" -ForegroundColor Yellow } } # Admin policies (CA100-CA105) Write-Host "`n [ADMIN POLICIES]" -ForegroundColor Magenta foreach ($template in $categories.Admins) { try { $templateObj = Import-CATemplate -TemplateName ($template.Name -replace '\.json$', '') Deploy-CAPolicy -Template $templateObj ` -State 'enabledForReportingButNotEnforced' ` -ExcludedGroups @('CA-Exclusion-BreakGlass') ` -WhatIf:$WhatIf } catch { Write-Host " ⚠️ Error: $_" -ForegroundColor Yellow } } # Internal user policies (CA200-CA210) Write-Host "`n [INTERNAL USER POLICIES]" -ForegroundColor Magenta foreach ($template in $categories.Internals) { try { $templateObj = Import-CATemplate -TemplateName ($template.Name -replace '\.json$', '') Deploy-CAPolicy -Template $templateObj ` -State 'enabledForReportingButNotEnforced' ` -ExcludedGroups @('CA-Exclusion-BreakGlass', 'CA-Exclusion-Testing') ` -WhatIf:$WhatIf } catch { Write-Host " ⚠️ Error: $_" -ForegroundColor Yellow } } Write-Host "`n[OK] Implementation completed" -ForegroundColor Green Write-Host "`n⚠️ All policies in REPORT-ONLY mode" -ForegroundColor Yellow Write-Host " Review sign-in logs for 1-2 weeks before enforcement" -ForegroundColor Gray } catch { Write-Host "`n[FAIL] ERROR: $_" -ForegroundColor Red throw } } function Invoke-Enforcement { <# .SYNOPSIS Week 4: Enable all CA policies (report-only → enabled) #> [CmdletBinding(SupportsShouldProcess)] param() try { Write-Host "`nWeek 4: CA Enforcement..." -ForegroundColor Yellow Connect-MgGraph -Scopes 'Policy.ReadWrite.ConditionalAccess' -NoWelcome $policies = Get-MgIdentityConditionalAccessPolicy | Where-Object { $_.State -eq 'enabledForReportingButNotEnforced' } if ($policies.Count -eq 0) { Write-Host " ℹ️ No policies in report-only mode" -ForegroundColor Yellow return } Write-Host " Found $($policies.Count) policies in report-only mode" -ForegroundColor Gray Write-Host "`n Enabling policies..." -ForegroundColor Cyan foreach ($policy in $policies) { try { Write-Host " • $($policy.DisplayName)" -ForegroundColor Gray if ($PSCmdlet.ShouldProcess($policy.DisplayName, "Enable CA policy")) { Update-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId $policy.Id -State 'enabled' Write-Host " [OK] ENABLED" -ForegroundColor Green } } catch { Write-Host " [FAIL] Error: $_" -ForegroundColor Red } } Write-Host "`n[OK] Enforcement completed - all policies ACTIVE!" -ForegroundColor Green } catch { Write-Host "`n[FAIL] ERROR: $_" -ForegroundColor Red throw } } function Invoke-Revert { <# .SYNOPSIS Disables all CA policies #> [CmdletBinding(SupportsShouldProcess)] param() try { Write-Host "`nRevert: Disabling CA policies..." -ForegroundColor Yellow Connect-MgGraph -Scopes 'Policy.ReadWrite.ConditionalAccess' -NoWelcome $policies = Get-MgIdentityConditionalAccessPolicy | Where-Object { $_.State -ne 'disabled' } Write-Host " Found $($policies.Count) active policies" -ForegroundColor Gray foreach ($policy in $policies) { Write-Host " Disabling: $($policy.DisplayName)" -ForegroundColor Gray if ($PSCmdlet.ShouldProcess($policy.DisplayName, "Disable CA policy")) { Update-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId $policy.Id -State 'disabled' Write-Host " [OK] Disabled" -ForegroundColor Green } } Write-Host "`n[OK] Revert completed" -ForegroundColor Green } catch { Write-Host "`n[FAIL] ERROR: $_" -ForegroundColor Red throw } } # MAIN EXECUTION try { if ($Implementation) { if ($WhatIf) { Write-Host "WhatIf: Would deploy COMPLETE CA baseline" -ForegroundColor Yellow } else { Invoke-Implementation } } elseif ($Remediation) { if ($WhatIf) { Write-Host "WhatIf: Would deploy basic CA policies" -ForegroundColor Yellow } else { Invoke-Remediation } } elseif ($Enforcement) { if ($WhatIf) { Write-Host "WhatIf: Would enable all report-only policies" -ForegroundColor Yellow } else { Invoke-Enforcement } } elseif ($Revert) { if ($WhatIf) { Write-Host "WhatIf: Would disable all policies" -ForegroundColor Yellow } else { Invoke-Revert } } elseif ($Monitoring) { $result = Invoke-Monitoring exit $(if ($result.isCompliant) { 0 } else { 1 }) } else { Write-Host "Available parameters:" -ForegroundColor Yellow Write-Host " -Monitoring : Check CA policies status" -ForegroundColor Gray Write-Host " -Remediation : Deploy basic CA policies (report-only)" -ForegroundColor Gray Write-Host " -Implementation : Deploy COMPLETE baseline (all templates)" -ForegroundColor Gray Write-Host " -Enforcement : Enable all policies (Week 4)" -ForegroundColor Gray Write-Host " -Revert : Disable all policies" -ForegroundColor Gray Write-Host " -WhatIf : Preview changes" -ForegroundColor Gray } } catch { Write-Error "Script execution failed: $_" exit 2 } finally { Write-Host "`n========================================`n" -ForegroundColor Cyan }

Risico zonder implementatie

Risico zonder implementatie
Critical: KRITIEK: CA policies zijn de enforcement layer voor nul Trust. Zonder baseline CA: MFA gaps, legacy auth mogelijk, non-compliant devices access, risky sign-ins succeed. complete baseline binnen 3-4 weken is achievable en transforms beveiligingspositie.

Management Samenvatting

WEEK 1-4: implementeren 10-15 baseline CA policies via templates. Report-only (week 1-2) → Gradual enforcement (week 3-4). Covers: MFA alle scenarios, Blokkeer legacy auth, Device compliance, Admin bescherming. Implementatie: 16 uur over 4 weken. KRITIEKE nul TRUST FOUNDATION.