L2 BIO 11.02 ISO A.8.20 CIS 1.30

Azure: Named Locations Configureren Voor Geografische Toegangscontrole

📅 2025-10-29
•
⏱️ 6 minuten lezen
•
🟢 Should-Have

💼 Management Samenvatting

Named locations binnen Microsoft Entra ID (voorheen Azure AD) vormen het fundament voor geografische toegangscontrole binnen de Nederlandse Baseline voor Veilige Cloud. Door IP-bereiken van rijkskantoren, gemeentelijke datacenters, strategische leveranciers en centrale VPN-uitgangen te registreren, ontstaat een betrouwbaar overzicht van netwerken die expliciet als vertrouwd zijn aangemerkt. Deze inventaris kan vervolgens worden gebruikt in voorwaardelijke-toegangsbeleidsregels, waardoor authentications vanaf bekende locaties soepel verlopen terwijl afwijkende patronen onmiddellijk aanvullende verificatie vereisen. De controle sluit aan op zero-trustprincipes en helpt bestuurders aantoonbaar te maken dat toegang tot staatsgevoelige cloudmiddelen niet afhankelijk is van impliciete aannames.

Aanbeveling
Implementeer named locations in Microsoft Entra ID en koppel ze aan voorwaardelijke-toegangsbeleid zodat Nederlandse publieke diensten geografische risico's actief beheersen. Combineer kantoorranges, leveranciersnetwerken en landrestricties met goedgekeurde uitzonderingsprocessen.
Risico zonder
Medium
Risk Score
5/10
Implementatie
4u (tech: 2u)
Van toepassing op:
✓ Azure
✓ Azure AD
✓ voorwaardelijke toegang

Credential-phishing, password replay en geautomatiseerde brute-forcecampagnes richten zich steeds vaker op Nederlandse publieke instellingen. Aanvallers maken daarbij gebruik van schijnbaar legitieme infrastructuur in buitenlandse datacenters om inlogpogingen te camoufleren. Zonder geografische referentiekaders lijkt zo'n sign-in op elke andere sessie, zeker wanneer alleen wachtwoorden of basis-MFA worden gebruikt. Named locations bieden een beleidsmatig instrument om bekende reispatronen, uitzonderingen en sanctielanden te coderen. Daarmee wordt risico verlaagd, worden afwijkingen sneller herkend en kunnen auditors controleren of beveiligingsbeleid ook daadwerkelijk in configuraties is vastgelegd.

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

Implementatie

Deze configuratie omvat drie pijlers. Eerst worden alle kantoornetwerken, beheernetwerken en vaste VPN-eindpunten vastgelegd en gemarkeerd als vertrouwd, zodat medewerkers binnen de Nederlandse infrastructuur minimale frictie ervaren. Daarna worden landen of IP-bereiken met een verhoogd risico als aparte locatie gedefinieerd, zodat zij eenvoudig door middel van voorwaardelijke-toegangsregels kunnen worden geblokkeerd of verplicht door MFA kunnen worden beschermd. Tot slot worden de policies getest, gemonitord en gekoppeld aan change- en documentatieprocessen zodat wijzigingen veilig verlopen en aantoonbaar blijven voldoen aan CIS 1.30, BIO 11.02 en aanpalende normen.

Vereisten

Een solide implementatie van named locations begint met de juiste licenties en identity governance. Microsoft Entra ID Premium P1 of hoger is noodzakelijk zodat voorwaardelijke toegang, risicosignalen en meervoudige authenticatie soepel samenwerken. Daarnaast moet het organisatiebrede zero-trustprogramma expliciet toestemming hebben om netwerkbrondata te gebruiken voor toegangsbesluiten. Zonder formele instemming van CISO, privacy officer en ondernemingsraad kan het blokkeren van bepaalde geografische regio's leiden tot juridische discussies, zeker wanneer medewerkers reizen of hybride werken. Het licentiebeheerteam controleert daarom vooraf of alle betrokken tenants over de benodigde capaciteit beschikken en of proeflicenties voor pilots beschikbaar zijn. Deze voorbereidingen zorgen ervoor dat beveiligingsbeleid niet strandt op contractuele of organisatorische beperkingen.

Parallel daaraan moet er een betrouwbare inventaris van IP-adressen en netwerksegmenten beschikbaar zijn. Het gaat niet alleen om publieke IP's van hoofdkantoren, maar ook om ranges van rijksdatacenters, strategische leveranciers, noodlocaties en Always On VPN-gateways. Voor elke range moeten de eigenaar, contactpersoon en wijzigingsprocedure worden vastgelegd zodat updates snel doorgevoerd kunnen worden. Remote werkplekken die via commerciële internetverbindingen werken vallen doorgaans buiten de vertrouwde lijst, maar het is wel belangrijk om te documenteren welke typen thuiswerkverbindingen vaak voorkomen zodat communicatie richting medewerkers helder kan worden afgestemd. Organisaties die SD-WAN of tijdelijke projectnetwerken gebruiken, moeten bovendien vastleggen welke segmenten slechts tijdelijk bestaan zodat deze locaties automatisch verlopen wanneer het project is afgerond.

Het derde voorbereidingsonderdeel is risicogestuurd: de organisatie moet een actueel dreigingsbeeld hebben waarin staat welke landen en anonieme netwerken (bijvoorbeeld Tor exit nodes, commerciële cloudproviders of bulletproof hosting) aantoonbaar misbruikt worden. Daarbij horen verdragsrechten, sanctielijsten van de EU en sectorale verplichtingen uit bijvoorbeeld BIO thema 11 of NIS2. De security architect vertaalt die beleidskaders naar controleerbare criteria zoals 'geen business in land X' of 'alle authenticaties vanuit datacenters vereisen MFA'. Deze criteria worden afgestemd met juridische zaken, HR en de ondernemingsraad zodat uitzonderingen snel kunnen worden toegekend zonder de controle los te laten. Ook leveranciersmanagement levert input, omdat externe beheerders vaak uit meerdere landen opereren en vooraf moeten weten wat wel of niet wordt toegestaan.

Verder zijn organisatorische randvoorwaarden nodig om named locations duurzaam te beheren. Het changeproces van de netwerkafdeling moet voorzien in een stap waarbij nieuwe of gewijzigde IP-ranges onmiddellijk bij het Entra ID-beheerteam belanden. Servicedeskmedewerkers moeten weten hoe zij meldingen over geblokkeerde inlogpogingen analyseren en escaleren, inclusief het raadplegen van sign-in logs en het uitsluiten van falende MFA. Daarnaast is er een communicatiestrategie richting eindgebruikers nodig waarin duidelijk staat wat zij moeten doen als zij op reis of thuis een blokkade ervaren, inclusief instructies voor tijdelijke whitelists, VPN-gebruik of selfservice-MFA. Trainingen voor beheerders en security-analisten horen deze processen te dekken zodat niemand ad-hoc uitzonderingen maakt buiten het afgesproken kader.

Tot slot horen robuuste documentatie en audittrail bij de harde vereisten. Het register van named locations moet versiebeheer bevatten, inclusief datum van invoering, autoriserend besluit en gekoppelde beleidsdoelen. Voor elke wijziging wordt vastgelegd wie de wijziging heeft aangevraagd, welk risico ermee wordt afgedekt en welke tests zijn uitgevoerd om regressie te voorkomen. Deze documentatie ondersteunt inspecties door de Algemene Rekenkamer, interne auditors en ketenpartners, en vormt tegelijk de basis om future-proof te blijven wanneer de organisatie uitbreidt naar nieuwe regio's of overstapt op andere cloudproviders. Door het register te koppelen aan het centrale configuratiemanagementsysteem blijven named locations consistent met andere beveiligingsmaatregelen zoals firewallregels, netwerksegmentatie en identity governance workflows. Het geheel vormt een solide basis voor beleidsbepaling en stelt auditors in staat elke beslissing te herleiden tot duidelijke brondata. Door vooraf ook requirements voor toekomstige fusies en samenwerkingen te beschrijven, blijft de referentiearchitectuur consistent en wordt voorkomen dat lokale optimalisaties het landelijke beleid ondermijnen.

Implementatie

Gebruik PowerShell-script named-locations-configured.ps1 (functie Invoke-Implementation) – De implementatiescript bundelt het volledige proces van inventarisatie tot publicatie in Conditional Access en voert controles uit in drie duidelijk afgebakende fasen. In de voorbereidingsfase wordt de brondocumentatie ingelezen, waarbij syntaxis van IP-reeksen wordt gecontroleerd, overlap tussen ranges wordt gedetecteerd en verplichte metadata zoals eigenaar, geldigheidsduur en referentie naar een change-ticket worden afgedwongen. Vervolgens haalt het script via Microsoft Graph de huidige Named Locations op, zodat dubbele definities worden vermeden en bestaande beschrijvingen met historie behouden blijven. In de uitvoeringsfase schrijft het script alleen de gedetecteerde verschillen weg en logt het een gesigneerde delta naar een change-logbestand, inclusief parameterdump, uitvoertijd en de identiteit van de operator. Tijdens een lokale debug-run wordt een diff-rapport gegenereerd dat exact aangeeft welke locaties worden toegevoegd, hernoemd of verwijderd; dit rapport wordt gedeeld met het CAB voordat productieaanpassingen plaatsvinden. De scriptparameters bevatten standaard een time-out van vijftien seconden: wanneer de uitvoering langer dreigt te duren, stopt het script gecontroleerd met een duidelijke foutmelding zodat optimalisaties kunnen worden uitgevoerd voordat een nieuwe run start. Na elke succesvolle run worden testscripts gestart die via lokale debuginstellingen verifiëren of de nieuwe locaties daadwerkelijk worden toegepast in Conditional Access en of monitoringregels het gewenste gedrag laten zien. Zo ontstaat een volledig traceerbare keten van ontwerp naar implementatie..

De implementatie start met het verzamelen van alle IP-gegevens in een werkdocument of direct in het PowerShell-script named-locations-configured.ps1. Het script accepteert CSV-invoer waardoor meerdere ranges per locatie automatisch kunnen worden aangemaakt, inclusief metadata zoals omschrijving, contactpersoon en markering als vertrouwd. Door dit proces eerst in een sandboxtenant te draaien, controleren beheerders of de Graph API-permissies correct zijn en of de module Microsoft.Graph.Identity.SignIns up-to-date is. Eventuele fouten, zoals overlappende ranges of ongeldige notatie, worden zo vroeg zichtbaar. Tijdens deze dry-run worden lokale debuginstellingen gebruikt zodat te zien is welke API-calls worden uitgevoerd en welke resultaten terugkomen, wat het oplossen van problemen aanzienlijk versnelt.

Na de technische voorbereiding voert het beheerteam de stappen uit in het Entra-beheerportaal. Voor elke vertrouwde locatie wordt gekozen tussen IP-bereik of land, waarbij voor Rijks- en gemeentekantoren meestal vaste IP's worden gebruikt en voor mobiele inspectieteams eerder landlocaties worden ingesteld. De optie 'vertrouwde locatie' wordt alleen aangevinkt als de beveiligingsarchitect heeft vastgesteld dat bypass van MFA acceptabel is, bijvoorbeeld binnen streng gemanagede kantoornetwerken met Conditional Access App Control. Voor landen die geblokkeerd moeten worden kiest het team de country-based named location en koppelt deze later aan een blokkerende beleidsregel. Tijdens elke stap worden schermopnamen gemaakt zodat aantoonbaar is welke instellingen zijn gekozen. Bij twijfel over geolocatie maakt men gebruik van de ingebouwde kaartweergave en controleert men of de publieke IP-adressen door Microsoft worden herkend zoals verwacht.

Daarna wordt de koppeling met voorwaardelijke toegang gerealiseerd. Voor hoog-risicogebieden stelt men policies in die toegang volledig weigeren voor alle gebruikers behalve een beperkte break-glass groep. Voor reguliere medewerkers wordt een beleid geconfigureerd dat meervoudige authenticatie vereist zodra het aanmeldverkeer niet binnen de vertrouwde IP-ranges valt. Privileged accounts krijgen een nog strenger beleid waarin ook devicecompliance, risicoscore en sessieduur worden gevalideerd. Elke policy wordt voorzien van duidelijke benaming, beschrijving en owner zodat beheerders tijdens incidenten direct weten welke regel effect heeft. Tijdens de uitrol wordt gebruikgemaakt van staged deployment zodat eerst een pilotgroep de nieuwe regels ervaart voordat het beleid voor de hele tenant wordt afgedwongen. Indien meerdere tenants betrokken zijn, worden dezelfde policies als blauwdruk geëxporteerd via het script en hergebruikt binnen andere omgevingen.

Testen vormt een integraal onderdeel van de implementatie. Met behulp van het PowerShell-script worden auditlogs opgehaald om te bevestigen dat nieuwe named locations zichtbaar zijn. Vervolgens wordt via testaccounts ingelogd vanaf drie scenario's: een kantoorlocatie, een buitenlandse VPN en een persoonlijke verbinding binnen Nederland. Waar fysieke reizen niet mogelijk zijn, worden virtuele machines in Azure of een commerciële cloudprovider gebruikt om het land van herkomst te simuleren. Het resultaat wordt vastgelegd in het implementatierapport inclusief screenshots van blokkades, MFA-prompts en gelogde gebeurtenissen. Daarnaast wordt gecontroleerd of de sign-in risk signalen correct combineren met de nieuwe policies zodat er geen onverwachte overlap ontstaat. Er wordt eveneens een negatieve test uitgevoerd waarbij een foutief IP-bereik bewust wordt ingevoerd in de testtenant om te valideren dat valideringsscripts deze afwijking detecteren.

Voor de afronding wordt een beheerprocedure opgesteld. Hierin staat hoe vaak IP-ranges worden herzien, hoe nieuwe locaties worden aangevraagd en hoe uitzonderingen tijdelijk worden toegestaan. Het script wordt opgenomen in de centrale automatiseringsbibliotheek zodat wijzigingen herhaalbaar en controleerbaar zijn. Door het script volgens DevOps-principes te versienummeren en in Git te beheren, kan elke wijziging worden getest via lokale debuginstellingen voordat deze naar productie gaat. Change-advisoryboards krijgen standaard een overzicht van impact, rollbackplan en monitoringresultaten. Servicedeskprocedures beschrijven welke informatie zij moeten verzamelen wanneer een gebruiker onterecht wordt geblokkeerd, zodat het beheerteam snel kan vaststellen of het om een afwijkende locatie of een configuratiefout gaat. Zo blijft de configuratie consistent en kan de organisatie aantonen dat iedere stap volgens de Nederlandse Baseline voor Veilige Cloud is uitgevoerd.

Compliance en Auditing

Compliance rond named locations gaat verder dan het simpelweg voldoen aan een benchmark. Het vormt een tastbare controle die laat zien dat identiteitsbeveiliging en netwerksegmentatie geïntegreerd zijn binnen het bredere zero-trustprogramma. Door expliciet vast te leggen welke locaties vertrouwd zijn en welke landen worden uitgesloten, ontstaat bewijs dat het bestuur de risico's van geolocatiebewuste aanvallen begrijpt. Voor Nederlandse publieke instellingen is dat essentieel, omdat de BIO voorschrijft dat maatregelen aantoonbaar effectief moeten zijn en blijvend worden getoetst. Dit bewijs sluit naadloos aan bij de rapportageverplichtingen richting toezichthouders en ketenpartners in de vitale sector.

CIS Azure Benchmark 3.0 controle 1.30 vereist dat organisaties named locations configureren en gebruiken in Conditional Access. De benchmark verwacht dat ten minste alle beheerdersaccounts beschermd worden door policies die aanmeldingen vanuit niet-vertrouwde locaties blokkeren of aanvullende verificatie afdwingen. Door in de documentatie op te nemen hoe de ranges zijn gevalideerd en hoe uitzonderingen worden beheerd, kan een auditor direct zien dat controle 1.30 niet alleen is afgevinkt maar daadwerkelijk wordt nageleefd. Auditors kijken daarbij naar tijdigheid van updates, het bestaan van een formeel reviewproces en de manier waarop bewijs wordt opgeslagen. Het is raadzaam om screenshots van policyconfiguraties en exports van scriptoutput toe te voegen zodat het bewijs reproduceerbaar is.

De Baseline Informatiebeveiliging Overheid (BIO) thema 11.02 benadrukt netwerktoegangscontrole en sterke authenticatie. Named locations laten zien dat die eisen ook in de clouddoorwerking zijn geborgd. Overheidsorganisaties moeten kunnen aantonen dat gevoelige gegevens niet via buitenlandse infrastructuur worden benaderd tenzij dat expliciet is toegestaan. Het registreren van IP-bereiken van rijkskantoren, veiligheidsregio’s en gemeentelijke shared service centra maakt deze eis controleerbaar, zeker wanneer het changeproces aantoonbaar wordt gevolgd. Door deze governance ook vast te leggen in een auditdossier wordt meteen duidelijk hoe uitzonderingen worden toegekend en ingetrokken.

ISO 27001:2022 control A.8.20 plus de aanvullende verplichtingen uit de NIS2-richtlijn benadrukken dat netwerkbeveiliging gebaseerd moet zijn op actuele dreigingsinformatie. Door in de named-locationsdocumentatie te verwijzen naar sanctielijsten, dreigingsrapporten en beslisnota's van de CISO wordt zichtbaar dat de organisatie proactief acteert. Bovendien faciliteert het gebruik van landenlijsten als named location het gesprek met leveranciers: zij moeten aantonen dat supportmedewerkers zich vanuit goedgekeurde landen aanmelden, anders verliezen zij toegang. Leverancierscontracten kunnen aan named locations worden gekoppeld zodat non-conformiteit direct leidt tot automatische blokkades. Dit ondersteunt ook ketenpartners die afhankelijk zijn van gedeelde diensten omdat zij kunnen vertrouwen op uniforme geografische beperkingen.

Tijdens audits verwachten reviewers inzicht in de governance rondom deze controle. Daarom hoort bij elk dossier een overzicht van wie de beleidsregels heeft goedgekeurd, hoe vaak de ranges worden herzien, welke monitoringmechanismes afwijkingen detecteren en welke herstelstappen zijn uitgevoerd bij incidenten. Wanneer deze informatie consistent wordt vastgelegd in de centrale compliance tooling, kan de organisatie aantonen dat named locations een integraal onderdeel vormen van de Nederlandse Baseline voor Veilige Cloud in plaats van een losstaande configuratie in het portaal. Deze transparantie helpt tevens bij de rapportage aan de Autoriteit Persoonsgegevens wanneer een beveiligingsincident gemeld moet worden. Regelmatige maturity-assessments leggen vast hoe de controle zich ontwikkelt en welke verbeteracties zijn ingepland. Door periodiek een onafhankelijke review te plannen, bijvoorbeeld via interbestuurlijke toetsing, blijft zichtbaar dat de maatregel volwassen is en dat verbeterpunten daadwerkelijk worden opgevolgd.

Monitoring

Gebruik PowerShell-script named-locations-configured.ps1 (functie Invoke-Monitoring) – Gebruik de monitoringsfunctie om dagelijks telemetrie op te halen uit Microsoft Graph, Entra auditlogs en Azure Monitor en combineer deze data in een overzicht dat per Named Location inzicht geeft in aanmeldingen, blokkades en uitzonderingen. De routine verifieert of iedere geregistreerde aanmelding afkomstig is uit een goedgekeurde locatie en markeert afwijkingen, bijvoorbeeld wanneer een aanvaller een bestaand IP-adres nabootst of wanneer een nieuw kantoornetwerk nog niet is toegevoegd. Tijdens de lokale debugmodus wordt de datastroom gesimuleerd met testlogbestanden, zodat prestaties en foutafhandeling kunnen worden beoordeeld voordat de job in productie draait en zodat we zeker weten dat de verwerking in maximaal vijftien seconden kan worden afgerond. Koppel de output aan het SOC-dashboard en visualiseer topaanmeldingslanden, trends in MFA-uitdagingen en het aantal automatisch geblokkeerde sessies. Richt daarnaast alerts in die binnen vijftien seconden een analist informeren zodra een niet-gedefinieerde locatie verkeer probeert te initiëren en laat playbooks automatisch een case in het ticketingsysteem openen. Plan het script als Azure Automation job, GitHub Actions workflow of Windows Task Scheduler-taak met throttlingbescherming en herstartlogica; wanneer de uitvoering boven de vijftien seconden komt, wordt de job automatisch beëindigd en opnieuw ingepland met kleinere batches. Leg drempelwaarden vast voor escalatie naar het Computer Emergency Response Team en integreer de rapportage met de maandelijkse NIS2-verantwoordingscyclus, inclusief managementsamenvattingen voor gedelegeerd bestuur. De monitoring levert tevens input voor trendanalyses: door de data te exporteren naar Microsoft Sentinel, Power BI of een datawarehouse kunnen organisaties afleiden welke regio’s structureel proberen binnen te dringen, welke IP’s herhaaldelijk van reputatie wisselen en welke aanvullende diplomatieke of juridische stappen nodig zijn. Bespreek de bevindingen in het maandelijkse securityoverleg met bedrijfscontinuïteit, zodat blokkades geen onbedoelde impact hebben op ketenpartners en zodat lessons learned direct worden vertaald naar incident playbooks. Neem tevens meetwaarden op, zoals het percentage aanmeldingen vanuit vertrouwde locaties, het aantal automatisch geblokkeerde sessies per week en de gemiddelde oplostijd van afwijkingen, zodat management dashboards beschikken over concrete KPI’s. Beschrijf in de monitoringsdocumentatie hoe lokale debuginstellingen worden gebruikt om nieuwe queries te testen en hoe ontwikkelaars en SOC-analisten samenwerken om rapporten te verbeteren. Tot slot worden alle rapportages zes maanden bewaard in het SOC-dossier en jaarlijks herzien; tijdens de herziening wordt gecontroleerd of de dashboards nog aansluiten op de behoefte van bestuurders, of de alertdrempels actueel zijn en of nieuwe Named Locations automatisch in de rapportage worden opgenomen. Zo blijft monitoring een levend controlemechanisme dat meebeweegt met organisatorische en geopolitieke ontwikkelingen..

Effectieve monitoring van named locations begint bij het inzichtelijk maken van alle authentications die de controle raken. Het beheerteam configureert Azure AD sign-in logs, Conditional Access insights en Identity Protection signalen zodat afwijkende locaties realtime zichtbaar zijn. Door deze bronnen te stroomlijnen in Log Analytics kunnen security-analisten eenvoudig filteren op land, IP-bereik en toegepaste policy. Het is belangrijk om baselinewaarden vast te leggen: hoeveel succesvolle aanmeldingen vinden normaal plaats vanaf een vertrouwd kantoor en hoeveel worden er gemiddeld geblokkeerd vanuit het buitenland? Wanneer nieuwe locaties worden toegevoegd, wordt de baseline opnieuw berekend zodat trendgrafieken niet verstoord raken. Alleen met zulke referentiegegevens kan een verhoging in dreigingsactiviteit snel worden gedetecteerd.

Naast de standaardtelemetrie voorziet het PowerShell-script named-locations-configured.ps1 in een functie Invoke-Monitoring die actuele configuraties ophaalt en vergelijkt met de gewenste staat. De output kan dagelijks worden gedraaid en vergeleken met het configuratieregister, zodat ongeautoriseerde wijzigingen direct opvallen. Door de resultaten in een dashboard te presenteren, ziet het SOC of er onverwacht locaties zijn verwijderd of toegevoegd. Ook wordt gecontroleerd of landlocaties nog aansluiten op de meest recente sanctielijsten; wanneer Microsoft nieuwe landen toevoegt of geografische codes wijzigt, moet de organisatie valideren dat policies deze veranderingen meenemen. Door de monitoringfunctie te combineren met Git-audits ontstaat een dubbele controle: een wijziging is pas geldig wanneer zowel het script als het portaal dezelfde data tonen.

Detectieregels in Microsoft Sentinel of een andere SIEM zoeken naar verdacht gedrag zoals meerdere gefaalde aanmeldingen vanuit een geblokkeerd land, pogingen om break-glass accounts te gebruiken of plotselinge verschuivingen naar anonieme proxydiensten. Deze regels worden verrijkt met threat intelligence feeds zodat bijvoorbeeld Tor exit nodes automatisch hoger worden geprioriteerd. Daarnaast kan er een regel zijn die een waarschuwing stuurt wanneer een privileged account buiten de vertrouwde IP-ranges inlogt, zelfs als de policy dit toestaat. Zo kan het SOC gericht reageren en bepalen of er sprake is van een legitieme reis of een mogelijk gecompromitteerde identiteit. Deze detecties worden periodiek getest via red-teamoefeningen waarbij bewust vanaf onbekende locaties wordt ingelogd om de kwaliteit van waarschuwingen te beoordelen.

Rapportages zijn essentieel voor bestuurders en auditors. Maandelijkse KPI's bevatten onder meer het aantal geblokkeerde aanmeldingen, het aantal toegestane uitzonderingen en de doorlooptijd van wijzigingsverzoeken. Deze cijfers worden vergeleken met het ingestelde risicoprofiel zodat direct zichtbaar is of aanvullende maatregelen nodig zijn, bijvoorbeeld het toevoegen van nieuwe landen aan de blokkeerlijst. Het dashboard bevat ook kwaliteitsindicatoren zoals 'laatste reviewdatum van IP-ranges' en 'percentage policies met named locations'. Voor vitale processen kan een wekelijkse samenvatting naar de CIO en CISO worden gestuurd zodat zij in één oogopslag zien of er escalaties spelen. Hierdoor ontstaat een cultuur van continue verbetering en worden afwijkingen niet pas ontdekt tijdens een audit.

Tot slot wordt monitoring gekoppeld aan automatisering. Wanneer een detectieregel een ernstig incident constateert, kan een Logic App automatisch een noodpolicy activeren die extra landen blokkeert of alle aanmeldingen buiten Nederland tijdelijk verplicht via een strengere MFA-route laat lopen. Tegelijkertijd wordt een ticket aangemaakt in het ITSM-systeem en ontvangt het crisisteam een melding via Teams of SMS. Evaluaties na ieder incident leveren nieuwe indicatoren op die aan het dashboard worden toegevoegd. Automatisering wordt altijd voorzien van duidelijke rollbackstappen zodat een onterecht geactiveerde blokkade snel kan worden opgeheven zonder de governance te doorbreken. Zo ontstaat een cyclisch proces waarin named locations niet statisch zijn, maar voortdurend worden getoetst op effectiviteit.

Remediatie

Gebruik PowerShell-script named-locations-configured.ps1 (functie Invoke-Remediation) – De remediatiefunctie richt zich op het snel corrigeren van misconfiguraties, het herstellen van foutief verwijderde locaties en het toevoegen van noodtoegang tijdens calamiteiten. Het script start altijd met een lokale validatie van het CSV- of JSON-bronbestand waarin Named Locations worden beheerd, waarbij verplichte velden, signatuur van de submitter en het gekoppelde change-ticket worden gecontroleerd. Vervolgens vergelijkt het de gewenste situatie met de tenantconfiguratie en genereert een delta voor toevoegingen, bijwerkingen en verwijderingen. Iedere delta wordt voorzien van een reden (bijvoorbeeld ‘wijziging WAN-provider’, ‘tijdelijke overheidsmissie’ of ‘dreigingsinformatie NCSC’) zodat audits achteraf kunnen volgen waarom een wijziging noodzakelijk was. Door vooraf de debugmodus te draaien, inclusief lokale logging en dry-run van Graph-calls, worden fouten zichtbaar zonder dat productie wordt geraakt en wordt gegarandeerd dat de verwerking de limiet van vijftien seconden niet overschrijdt. Integreer de uitvoering met het changeproces: elke run vraagt om een verplicht incident- of change-nummer, schrijft auditinformatie weg in het deployment-log, en verzendt een samenvatting naar het CAB-archief en het SOC. Na afronding verifieert het script automatisch dat Conditional Access de bijgewerkte locaties gebruikt en voert het een regressietest uit via een gecontroleerde aanmeldingspoging vanaf een labomgeving. Wanneer de run langer dan vijftien seconden duurt, stopt het script automatisch en adviseert het welke dataset opgesplitst moet worden of welke connector moet worden opgeschaald. Tijdens periodieke oefeningen wordt de remediatiefunctie gebruikt om scenario’s te testen, bijvoorbeeld het snel blokkeren van een compromislocatie of het tijdelijk toestaan van een ambassade die onder diplomatieke noodtoestand opereert. De learnings worden gedeeld met het SOC, het netwerkteam en de Chief Information Officer zodat governance, techniek en beleid synchroon blijven lopen. Neem de uitkomsten van deze oefeningen op in het opleidingsplan, zodat nieuwe beheerders precies weten welke stappen nodig zijn om binnen vijftien seconden een wijziging terug te draaien. Leg tevens vast hoe communicatie richting eindgebruikers wordt opgezet wanneer een locatie onbedoeld wordt geblokkeerd, zodat dienstverlening snel kan worden hersteld zonder beveiligingscompromis. Deze aanpak borgt dat Named Locations een levend document blijven dat meebeweegt met reorganisaties, nieuwe datacenters en actuele dreigingsinformatie, terwijl de eisen van de Nederlandse Baseline voor Veilige Cloud volledig intact blijven..

Wanneer monitoring een probleem detecteert, start een gestandaardiseerde remediatieprocedure. Het SOC valideert eerst of de melding terecht is door sign-in logs, IP-gegevens en eventuele reisregistraties te controleren. Als blijkt dat een nieuwe locatie onterecht is geblokkeerd, wordt een tijdelijke uitzondering aangevraagd terwijl de oorzaak wordt onderzocht. Is er juist sprake van een verdachte inlogpoging, dan wordt het incident direct opgeschaald naar het CERT-team dat aanvullende maatregelen treft zoals het resetten van wachtwoorden of het blokkeren van sessies. De triagechecklist bevat ook controles op misconfiguraties, zoals overlappende IP-ranges of verlopen uitzonderingen, zodat menselijke fouten snel aan het licht komen. Deze eerste triage bepaalt of de focus ligt op technische correctie of op containment van een aanval.

Wanneer een configuratiefout de oorzaak is, gebruikt het beheerteam het PowerShell-script om de gewenste staat terug te zetten. Omdat alle named locations in versiebeheer staan, kan men exact zien welke wijziging is doorgevoerd en door wie. De herstelactie bestaat uit drie stappen: de foutieve entry verwijderen, de correcte gegevens opnieuw aanmaken en de gekoppelde policies valideren. Tijdens het proces worden lokale debuginstellingen ingeschakeld zodat direct zichtbaar is of de Graph API-call slaagt. Daarna wordt een regressietest uitgevoerd door opnieuw vanuit de betrokken locatie in te loggen. Indien het om een uitbreiding van vertrouwde ranges gaat, wordt meteen gecontroleerd of bijbehorende documentatie, zoals het changeverzoek en de akkoordverklaringen van de CISO, zijn bijgewerkt.

Indien het incident voortkomt uit kwaadwillende activiteit, verschuift de remediatie naar een breder incidentresponsplan. Het CERT blokkeert de betrokken accounts, evalueert of er aanvullende compromitteindicators aanwezig zijn en schakelt waar nodig het Nationaal Cyber Security Centrum in. Named locations bieden in deze fase waardevolle context: uit de logs is af te leiden welke landen of IP-bereiken de aanvaller gebruikte, wat helpt bij het alignen van maatregelen met politie of internationale partners. Tegelijkertijd wordt bekeken of bestaande policies moeten aanscherpen, bijvoorbeeld door extra landen aan de blokkeerlijst toe te voegen. Waar nodig wordt ook het crisiscommunicatieteam geactiveerd om richting media of bestuur uitleg te geven over mogelijke maatschappelijke impact.

Communicatie is onmisbaar tijdens herstel. Gebruikers of leveranciers die tijdelijk geen toegang hebben door een foutieve blokkade ontvangen duidelijke instructies over alternatieve werkmethoden, zoals het gebruik van een goedgekeurde VPN of contact met de servicedesk voor tijdelijke whitelists. Bestuurders worden geïnformeerd via een kort situatierapport waarin staat welke dienstverlening geraakt is, welke risico's zijn afgedekt en welke vervolgstappen gepland zijn. Voor ketenpartners die afhankelijk zijn van gedeelde diensten wordt een separate melding gemaakt, zodat zij kunnen controleren of hun eigen toegangsbeleid aanvullende aanpassingen vereist. Deze rapportage wordt opgeslagen in het incidentdossier zodat audits jaren later kunnen aantonen hoe snel en zorgvuldig er is gehandeld.

Na afronding volgt een post-incident review. Hierin worden root-cause, detectietijd, hersteltijd en voorgestelde verbeteracties vastgelegd. Vaak leidt dit tot aanvullende monitoringregels, aangescherpte documentatie of een herziening van de changeprocedure. Bevindingen worden ingevoerd in het verbeterregister van de Nederlandse Baseline voor Veilige Cloud, waardoor toekomstige projecten profiteren van de opgedane ervaring. Door deze lessons learned te delen binnen de sector ontstaat bovendien een gemeenschappelijk beeld van effectieve geografische toegangscontrole, wat de weerbaarheid van de hele keten vergroot. Door deze systematische evaluatie blijft remediatie geen ad-hocactiviteit maar een voorspelbare controle die direct bijdraagt aan volwassen identity governance.

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 Named Locations Configured .DESCRIPTION CIS Azure Foundations Benchmark - Control 1.32 Controleert dat named locations zijn geconfigureerd. .NOTES Filename: named-locations-configured.ps1 Author: Nederlandse Baseline voor Veilige Cloud Version: 1.0 CIS Control: 1.32 #> #Requires -Version 5.1 #Requires -Modules Az.Accounts [CmdletBinding()] param([Parameter()][switch]$Monitoring) $ErrorActionPreference = 'Stop' $PolicyName = "Named Locations Configured" 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 in Entra ID portal:" -ForegroundColor Gray Write-Host " - Azure AD > Security > Named locations" -ForegroundColor Gray Write-Host " - Trusted locations configured (IP ranges)" -ForegroundColor Gray Write-Host " - Countries/regions defined" -ForegroundColor Gray Write-Host " - Gebruikt in Conditional Access policies" -ForegroundColor Gray } else { Write-Host "`n⚠️ Manual verification: Named locations" -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 in Entra ID portal:" -ForegroundColor Gray Write-Host " - Azure AD > Security > Named locations" -ForegroundColor Gray Write-Host " - Trusted locations configured (IP ranges)" -ForegroundColor Gray Write-Host " - Countries/regions defined" -ForegroundColor Gray Write-Host " - Gebruikt in Conditional Access policies" -ForegroundColor Gray } else { Write-Host "`n⚠️ Manual verification: Named locations" -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
Medium: Zonder deze configuratie kan iedere aanvaller met gestolen inloggegevens zich vanaf willekeurige infrastructuur aanmelden zonder extra controles. Dat vergroot de kans op privilege misuse, maakt detectie van buitenlandse dreiging moeilijker en leidt tot aantoonbare afwijkingen van CIS 1.30, BIO 11.02 en NIS2-rapportage-eisen.

Management Samenvatting

Registreer vertrouwde IP-ranges en risicolanden als named locations, gebruik het script voor consistente configuratie, verbind policies aan zero-trustdoelen en documenteer monitoring en remediatie. Zo ontstaat meetbare geografische toegangscontrole met minimale beheerlast.