Domeingebruikers Verplicht Verhogen Bij Het Wijzigen Van De Netwerk­locatie

De gekozen netwerk­locatie bepaalt welke firewallprofielen, beveiligingsregels en beheeropties automatisch worden toegepast. Aanvallers of onbewuste gebruikers kunnen proberen deze locatie te wijzigen om strengere beveiligingsmaatregelen te omzeilen. Door te eisen dat een verhoogde sessie nodig is voor het instellen of wijzigen van de netwerk­locatie, verkleint de organisatie het risico op misconfiguraties, privilege‑escalatie via zwakke netwerkprofielen en ongecontroleerde toegang tot interne resources. Deze instelling sluit aan bij de principes van least privilege en maakt het eenvoudiger om uniform beleid af te dwingen binnen de gehele tenant.

Implementatie

In deze richtlijn wordt beschreven hoe organisaties met behulp van Microsoft Intune de instelling "Require domain users to elevate when setting a network’s location" afdwingen op domein‑joined en hybride Azure AD‑joined Windows‑apparaten. We behandelen de functionele achtergrond van de instelling, de voorbereidingen binnen beheerprocessen, de concrete configuratie in Intune, het inrichten van monitoring en rapportage, en de manier waarop afwijkingen automatisch kunnen worden hersteld. De tekst is gericht op security officers, Intune‑beheerders en Windows‑specialisten binnen organisaties die de Nederlandse Baseline voor Veilige Cloud volgen.

Vereisten

Om deze maatregel effectief en beheersbaar te implementeren, moet de organisatie beschikken over een aantal randvoorwaarden op zowel technisch als organisatorisch vlak. Allereerst moeten de betrokken Windows‑apparaten beheerd worden via Microsoft Intune, bij voorkeur als onderdeel van een gestandaardiseerd endpoint‑beheerproces. De apparaten zijn minimaal hybride Azure AD‑joined of volledig Entra ID‑joined en worden periodiek gesynchroniseerd zodat beleidswijzigingen tijdig worden doorgevoerd. Daarnaast is het noodzakelijk dat er een duidelijke rolverdeling bestaat tussen Intune‑beheerders, security officers en lijn‑ of applicatiebeheerders: wie mag beleid ontwerpen, wie mag het publiceren naar productie en wie beoordeelt de impact van wijzigingen op de gebruikerservaring. Binnen de organisatie hoort een actueel overzicht aanwezig te zijn van alle netwerksegmenten en hun beoogde beveiligingsniveau (bijvoorbeeld kantoorlocaties, datacenters, thuiswerkplekken en gastnetwerken), zodat wijzigingen aan de netwerk­locatie altijd kunnen worden beoordeeld in de context van het totale beveiligingsontwerp. Verder is het van belang dat er een centraal change‑ en releaseproces bestaat waarin aanpassingen aan Intune‑configuraties worden geregistreerd, getest en goedgekeurd, inclusief terugvalscenario’s voor het geval er compatibiliteitsproblemen ontstaan met specifieke toepassingen of legacy‑apparatuur. Tot slot moeten helpdesk‑ en supportprocessen zijn ingericht om meldingen over verbindingsproblemen of gewijzigde netwerk­locaties snel te kunnen analyseren, waarbij medewerkers op basis van duidelijke instructies kunnen nagaan of de oorzaak ligt in een verkeerd toegepaste netwerkclassificatie, een foutieve groepslidmaatschapstoewijzing of in onderliggende infrastructuurcomponenten zoals firewallregels of VPN‑configuratie.

Implementeeratie

De implementatie van deze instelling in Microsoft Intune verloopt stapsgewijs en begint met het kiezen van de juiste configuratievorm. In de meeste omgevingen is een Endpoint Security‑ of Configuration Profiles‑beleid voor Windows 10/11 het meest geschikt, omdat hiermee op een uniforme manier registry‑ en beleidsinstellingen kunnen worden afgedwongen. De beheerder start in het Intune‑portaal met het aanmaken van een nieuw beleid dat is gericht op de relevante Windows‑platformen en kiest bij voorkeur voor een aparte policy die uitsluitend netwerk‑ en firewallgerelateerde instellingen bevat. Dit verhoogt de transparantie en maakt het eenvoudiger om later de impact van wijzigingen te analyseren. Binnen het beleid wordt de instelling die ervoor zorgt dat domeingebruikers hun rechten moeten verhogen bij het instellen van de netwerk­locatie expliciet op "Ingeschakeld" gezet. Waar nodig wordt aanvullende documentatie toegevoegd in de beschrijvingsvelden, zodat andere beheerders direct begrijpen waarom deze instelling is gekozen en hoe deze samenhangt met de bredere security‑architectuur. Vervolgens wordt het beleid toegewezen aan één of meerdere testgroepen, bijvoorbeeld een kleine groep werkplekken binnen de IT‑afdeling of een pilot‑afdeling met voldoende technische ondersteuning. Gedurende de testfase wordt gecontroleerd of gebruikers nog steeds kunnen verbinden met de voor hen bedoelde netwerken, maar geen mogelijkheid meer hebben om zelf de classificatie van een netwerk aan te passen zonder tussenkomst van een administrator. Na succesvolle validatie wordt het beleid gefaseerd uitgerold naar productie, bij voorkeur in batches per organisatieonderdeel, zodat eventuele onverwachte compatibiliteitsproblemen snel kunnen worden opgespoord. Alle stappen en bevindingen worden vastgelegd in het change‑dossier, inclusief de planning voor herbeoordeling van de instelling wanneer Microsoft nieuwe functionaliteit of aanvullende beleidsopties beschikbaar stelt.

Gebruik PowerShell-script require-domain-users-to-elevate-when-setting-a-networks-location-is-set-to-enabled.ps1 (functie Invoke-Monitoring) – Monitoren.

monitoring

Na implementatie is structurele monitoring essentieel om te borgen dat de instelling daadwerkelijk op alle relevante Windows‑apparaten wordt afgedwongen en blijft gelden bij toekomstige wijzigingen. Binnen Microsoft Intune kan de organisatie gebruikmaken van compliance‑rapportages, configuratiostatus‑overzichten en device‑inventaris om snel te zien welke endpoints het beleid succesvol hebben ontvangen en toegepast. Het gekoppelde PowerShell‑script kan aanvullend worden ingezet om vanaf een centrale beheerlocatie de werkelijke registrysleutels en effectieve local policy‑instellingen uit te lezen. Hiermee kan worden vastgesteld of er geen lokale afwijkingen of manuele aanpassingen plaatsvinden die het Intune‑beleid neutraliseren. De resultaten van deze metingen worden idealiter periodiek opgeslagen in een centrale logging‑ en rapportageoplossing, zoals Microsoft Sentinel of een ander SIEM‑platform, zodat trends zichtbaar worden en afwijkingen automatisch een waarschuwing genereren. In de operationele praktijk is het belangrijk dat de servicedesk duidelijke dashboards of rapporten tot haar beschikking heeft, bijvoorbeeld een lijst met apparaten waarop de instelling ontbreekt, recent is gewijzigd of frequent heen en weer geschakeld wordt. Dit soort patronen kan wijzen op misconfiguraties, ongeautoriseerde beheeracties of gebruikers die proberen beperkingen te omzeilen. Door monitoring te combineren met change‑registratie en asset‑management ontstaat een compleet beeld: als een apparaat bewust is uitgezonderd vanwege een specifieke business‑eis, moet dat worden teruggevonden in de documentatie; ontbreekt deze onderbouwing, dan is aanvullende analyse en mogelijk correctieve actie nodig.

Gebruik PowerShell-script require-domain-users-to-elevate-when-setting-a-networks-location-is-set-to-enabled.ps1 (functie Invoke-Monitoring) – Controleren.

Remediatie

Ondanks een zorgvuldig ontwerp en goede monitoring kunnen er situaties ontstaan waarin de instelling niet of niet meer correct is toegepast. Denk aan apparaten die tijdelijk buiten beheer zijn geweest, handmatig zijn hersteld na een incident of waarop lokale beheerders wijzigingen hebben aangebracht. Voor deze gevallen is een helder remediatieproces nodig. Het gekoppelde PowerShell‑script kan worden ingezet om non‑compliant apparaten automatisch terug te brengen naar de gewenste configuratie door de relevante beleidsinstellingen en registrysleutels opnieuw te zetten en dit resultaat terug te melden aan de beheerorganisatie. In veel omgevingen is het zinvol om deze remediatie periodiek, bijvoorbeeld dagelijks of wekelijks, geautomatiseerd uit te voeren via Intune remediations of scheduled tasks, zodat afwijkingen nooit lang onopgemerkt blijven. Naast technische correctie is ook aandacht nodig voor root‑cause‑analyse: bij ieder hersteld apparaat wordt onderzocht waarom de instelling is weggevallen of gewijzigd. Was er sprake van een fout in de toewijzing van het Intune‑beleid, een verouderde image, een migratiescript of ongeautoriseerde lokale beheerdersrechten? Door deze oorzaken structureel te adresseren, neemt de frequentie van afwijkingen af en wordt het nalevingsniveau duurzaam verhoogd. Tot slot is het verstandig om duidelijke communicatie op te stellen richting eindgebruikers en lokale beheerders waarin wordt uitgelegd waarom de netwerk­locatie niet zelfstandig mag worden aangepast en hoe zij een wijziging kunnen aanvragen via de reguliere change‑ of servicedeskprocessen.

Gebruik PowerShell-script require-domain-users-to-elevate-when-setting-a-networks-location-is-set-to-enabled.ps1 (functie Invoke-Remediation) – Herstellen.

Compliance en Auditing

Deze maatregel levert een aantoonbare bijdrage aan de naleving van verschillende normen en kaders die binnen de Nederlandse publieke sector relevant zijn, waaronder de Baseline Informatiebeveiliging Overheid (BIO), ISO 27001 en sector‑specifieke richtlijnen voor logging, toegangsbeveiliging en netwerksegmentatie. Door domeingebruikers te verplichten hun rechten te verhogen bij het instellen van de netwerk­locatie wordt de kans kleiner dat kritieke systemen of gevoelige gegevens onbedoeld bereikbaar worden via een te permissief netwerkprofiel. Voor auditors is het belangrijk dat het beleid rond netwerkclassificatie, firewallprofielen en Intune‑configuratie duidelijk is vastgelegd in beleid‑ en procesdocumenten. Daarin wordt beschreven welke netwerktypen de organisatie onderscheidt, welke beveiligingsniveaus daarbij horen en hoe de instelling in dit JSON‑document bijdraagt aan het afdwingen van die niveaus. Audit‑evidence kan onder meer bestaan uit exports van Intune‑beleid, rapportages van compliance‑status, logboeken van het gekoppelde PowerShell‑script en change‑dossiers waarin uitzonderingen en tijdelijke afwijkingen zijn geautoriseerd. Daarnaast verdient het aanbeveling om periodiek een interne controle uit te voeren waarbij steekproefsgewijs wordt nagegaan of de feitelijke netwerk­locaties op clients overeenkomen met de beoogde classificaties in architectuurdocumenten en netwerk‑ontwerpen. Afwijkingen worden geanalyseerd, geclassificeerd naar risico en, waar nodig, opgevolgd met aanvullende maatregelen of aanscherping van het beleid. Door deze cyclus van plannen, uitvoeren, controleren en bijsturen structureel te borgen in het Information Security Management System (ISMS) kan de organisatie tijdens externe audits overtuigend aantonen dat de maatregel niet alleen technisch is ingericht, maar ook procesmatig is verankerd en actief wordt bewaakt.

Compliance & Frameworks

• CIS M365: Control 18.9.19.2 (L1) - CIS Security Benchmark-aanbevelingen voor Windows-netwerk- en configuratiebeveiliging
• BIO: 16.01 - BIO Baseline Informatiebeveiliging Overheid - 16.01 - Gebeurtenissen logging en audittrails
• ISO 27001:2022: A.12.4.1 - ISO 27001:2022 - Gebeurtenissen logging en audittrails

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

Zorg dat alleen beheerders met verhoogde rechten de netwerk­locatie van Windows‑apparaten kunnen wijzigen, zodat de gekozen beveiligingsprofielen betrouwbaar aansluiten bij het beoogde risiconiveau van elk netwerksegment.

• Implementatietijd: 2 uur
• FTE required: 0.01 FTE