Publieke Netwerktoegang Uitschakelen Voor PaaS-diensten

Het implementeren van privé-eindpunten alleen is onvoldoende voor volledige netwerkbeveiliging. Zonder het expliciet uitschakelen van publieke toegang blijven beide toegangspaden actief, waardoor aanvallers nog steeds gebruik kunnen maken van het publieke eindpunt. Dit vormt een ernstig beveiligingsrisico en kan leiden tot compliance-schendingen. Door publieke toegang uit te schakelen wordt connectiviteit alleen via het virtuele netwerk afgedwongen, wat een fundamenteel principe is van Zero Trust-architectuur en verplicht is onder NIS2-richtlijnen.

Implementatie

Deze beveiligingsmaatregel omvat het instellen van PublicNetworkAccess op Uitgeschakeld voor Azure-opslagaccounts, Azure SQL-databases, Key Vault en Cosmos DB. Het is essentieel dat privé-eindpunten eerst worden geïmplementeerd en getest voordat publieke toegang wordt uitgeschakeld, om te voorkomen dat legitieme toegang wordt geblokkeerd. Organisaties moeten een gestructureerde aanpak volgen waarbij eerst de privé-connectiviteit wordt gevalideerd, vervolgens publieke toegang wordt uitgeschakeld, en ten slotte wordt geverifieerd dat alleen toegang via het virtuele netwerk mogelijk is.

Implementatie

De implementatie van het uitschakelen van publieke netwerktoegang vereist een zorgvuldige, gefaseerde aanpak om te voorkomen dat legitieme toegang wordt geblokkeerd. Deze maatregel moet worden uitgevoerd nadat privé-eindpunten volledig zijn geïmplementeerd en getest, omdat het uitschakelen van publieke toegang zonder werkende privé-connectiviteit kan leiden tot volledig toegangsverlies tot kritieke diensten. Organisaties die deze stap overslaan of onvoldoende voorbereiden, riskeren dat essentiële bedrijfsprocessen worden verstoord en dat medewerkers geen toegang meer hebben tot systemen die nodig zijn voor hun dagelijkse werkzaamheden. De eerste fase van de implementatie omvat het implementeren van privé-eindpunten voor alle relevante Platform-as-a-Service diensten. Dit betekent dat voor elke dienst die publieke toegang zal verliezen, een privé-eindpunt moet worden geconfigureerd binnen het virtuele netwerk waar de toegang vandaan moet komen. Privé-eindpunten maken gebruik van Azure Private Link, wat een beveiligde en privé verbinding biedt tussen het virtuele netwerk en de PaaS-dienst zonder dat verkeer over het publieke internet gaat. Deze technologie zorgt ervoor dat alle communicatie tussen de organisatie en de clouddiensten plaatsvindt via een beveiligd, geïsoleerd kanaal dat niet zichtbaar is voor externe partijen. Het configureren van privé-eindpunten vereist een grondige inventarisatie van alle PaaS-diensten die binnen de organisatie worden gebruikt. Dit omvat niet alleen de meest voor de hand liggende diensten zoals opslagaccounts en databases, maar ook minder zichtbare diensten zoals Key Vault, Cosmos DB, App Service en andere services die mogelijk publieke toegang hebben. Voor elke dienst moet worden bepaald welke virtuele netwerken toegang nodig hebben en welke subnetten binnen die netwerken de privé-eindpunten zullen hosten. Deze planning is essentieel omdat privé-eindpunten specifieke IP-adressen gebruiken binnen het virtuele netwerk en deze moeten worden toegewezen aan subnetten die voldoende adresruimte hebben. Na de implementatie van privé-eindpunten is het cruciaal om de privé-connectiviteit grondig te testen voordat publieke toegang wordt uitgeschakeld. Dit omvat het verifiëren dat applicaties en services die afhankelijk zijn van de PaaS-diensten nog steeds correct functioneren via de privé-eindpunten. Testscenario's moeten verschillende toegangspatronen omvatten, waaronder applicatie-toegang, database-verbindingen en Key Vault-operaties. Het is belangrijk om niet alleen de basisfunctionaliteit te testen, maar ook edge cases en scenario's waarbij meerdere applicaties gelijktijdig toegang nodig hebben tot dezelfde diensten. Performance-tests zijn eveneens essentieel, omdat privé-eindpunten een andere netwerkroute gebruiken dan publieke eindpunten en dit kan invloed hebben op de latentie en doorvoer. Alleen wanneer de privé-connectiviteit volledig is gevalideerd en alle testscenario's succesvol zijn afgerond, kan de volgende fase worden gestart. Het is verstandig om een periode van monitoring in te bouwen na de implementatie van privé-eindpunten maar voordat publieke toegang wordt uitgeschakeld. Tijdens deze periode kunnen eventuele problemen worden geïdentificeerd en opgelost zonder dat de organisatie het risico loopt op toegangsverlies. Deze voorzorgsmaatregel is vooral belangrijk voor productieomgevingen waar downtime of toegangsproblemen directe gevolgen kunnen hebben voor de bedrijfsvoering. De tweede fase bestaat uit het instellen van de instelling PublicNetworkAccess op Uitgeschakeld voor elke dienst. Dit kan worden gedaan via de Azure Portal, Azure PowerShell of Azure CLI, afhankelijk van de voorkeur en de automatisering die de organisatie gebruikt. Voor Azure Storage-accounts wordt dit geconfigureerd in de Netwerkbeveiliging-instellingen, waarbij de optie 'Publieke toegang toestaan' wordt uitgeschakeld. Deze instelling voorkomt dat opslagaccounts toegankelijk zijn via het publieke internet, zelfs als er firewallregels zijn geconfigureerd die bepaalde IP-adressen toestaan. Voor Azure SQL-databases wordt de instelling 'Publieke netwerktoegang' ingesteld op Uitgeschakeld in de firewall- en virtuele netwerken-configuratie. Deze instelling zorgt ervoor dat SQL-databases alleen toegankelijk zijn via privé-eindpunten of via beheerde identiteiten, wat de beveiliging aanzienlijk verbetert. Key Vault en Cosmos DB hebben vergelijkbare instellingen die moeten worden aangepast. Voor Key Vault wordt de netwerktoegang beperkt tot alleen privé-eindpunten en virtuele netwerken die expliciet zijn toegestaan. Voor Cosmos DB wordt de instelling voor publieke netwerktoegang uitgeschakeld, wat betekent dat alleen verbindingen via privé-eindpunten mogelijk zijn. Het is belangrijk om te begrijpen dat deze instellingen per dienst verschillen en dat de exacte configuratiestappen kunnen variëren afhankelijk van de versie van de Azure-services en de gebruikte interface. Na het uitschakelen van publieke toegang moet worden geverifieerd dat publieke toegang daadwerkelijk is geblokkeerd. Dit kan worden getest door te proberen verbinding te maken met de diensten vanaf een locatie buiten het virtuele netwerk, bijvoorbeeld vanaf een thuiswerkplek of een ander extern netwerk. Alle dergelijke pogingen moeten falen, wat bevestigt dat alleen toegang via het virtuele netwerk mogelijk is. Tegelijkertijd moeten interne tests bevestigen dat toegang via privé-eindpunten nog steeds functioneel is en dat alle applicaties en services normaal blijven werken. Het is raadzaam om deze verificatie uit te voeren met verschillende gebruikers en applicaties om er zeker van te zijn dat alle toegangspatronen correct functioneren. Een kritiek onderdeel van de implementatie is het documenteren van een noodprocedure, ook wel bekend als een break-glass procedure. In noodsituaties, zoals tijdens een incidentrespons of wanneer privé-eindpunten tijdelijk niet beschikbaar zijn vanwege onderhoud of technische problemen, kan het nodig zijn om publieke toegang tijdelijk weer in te schakelen. Deze procedure moet duidelijk beschrijven wanneer en hoe dit kan worden gedaan, welke autorisaties hiervoor nodig zijn, en hoe publieke toegang weer wordt uitgeschakeld zodra de noodsituatie is opgelost. De noodprocedure moet worden geïntegreerd in het incidentresponsplan van de organisatie en alle betrokken partijen moeten bekend zijn met de stappen die moeten worden genomen. Het is essentieel dat deze procedure alleen wordt gebruikt in echte noodsituaties en dat alle activiteiten worden gelogd en geaudit om te voorkomen dat publieke toegang onnodig lang actief blijft.

Compliance en Audit

Het uitschakelen van publieke netwerktoegang is niet alleen een best practice voor beveiliging, maar ook een verplichting onder verschillende compliance-frameworks en regelgeving die van toepassing zijn op Nederlandse overheidsorganisaties. Deze maatregel draagt bij aan het voldoen aan meerdere beveiligingsstandaarden en helpt organisaties te voldoen aan hun wettelijke verplichtingen op het gebied van cybersecurity en gegevensbescherming. Voor organisaties in de publieke sector is het niet alleen een technische keuze, maar vaak een wettelijke verplichting die voortvloeit uit verschillende Europese en Nederlandse richtlijnen en wetten. De CIS Azure Benchmark bevat meerdere controls die betrekking hebben op het beperken van publieke toegang tot clouddiensten. Deze controls zijn gebaseerd op het principe van least privilege en verdediging in lagen, waarbij organisaties moeten zorgen dat alleen geautoriseerde toegang mogelijk is via beveiligde kanalen. Het principe van least privilege betekent dat gebruikers en systemen alleen de minimale toegang krijgen die nodig is voor hun functie, terwijl verdediging in lagen ervoor zorgt dat meerdere beveiligingsmaatregelen worden geïmplementeerd om te voorkomen dat een enkele zwakke schakel de hele beveiliging compromitteert. Door publieke toegang uit te schakelen en alleen privé-eindpunten te gebruiken, voldoen organisaties aan deze controls en versterken ze hun algehele beveiligingspostuur aanzienlijk. Zero Trust-principes vormen de basis voor moderne cloudbeveiliging en vereisen dat organisaties nooit vertrouwen en altijd verifiëren. Dit betekent dat elke toegangspoging, ongeacht de bron of locatie, moet worden geverifieerd en geautoriseerd voordat toegang wordt verleend. Het uitschakelen van publieke netwerktoegang is een fundamenteel onderdeel van een Zero Trust-architectuur, omdat het ervoor zorgt dat alle toegang wordt geverifieerd en gecontroleerd via beveiligde, privé verbindingen. Dit sluit aan bij het principe dat netwerktoegang niet automatisch moet worden vertrouwd, ongeacht de locatie of het netwerk waar de toegang vandaan komt. In een Zero Trust-model worden alle netwerkverbindingen behandeld als potentieel vijandig totdat het tegendeel is bewezen, en het uitschakelen van publieke toegang is een concrete manier om dit principe te implementeren. De NIS2-richtlijn, die van toepassing is op essentiële en belangrijke entiteiten in Nederland, bevat specifieke vereisten voor netwerkbeveiliging. Artikel 21 van de NIS2-richtlijn verplicht organisaties om passende technische en organisatorische maatregelen te treffen om de beveiliging van netwerk- en informatiesystemen te waarborgen. Deze maatregelen moeten effectief zijn in het voorkomen, detecteren en reageren op beveiligingsincidenten, en moeten regelmatig worden geëvalueerd en bijgewerkt om rekening te houden met nieuwe bedreigingen en kwetsbaarheden. Het uitschakelen van publieke toegang en het gebruik van privé-eindpunten is een concrete implementatie van deze vereisten, omdat het de aanvalsoppervlakte aanzienlijk verkleint en de beveiliging van netwerkverbindingen versterkt. Door deze maatregel te implementeren, tonen organisaties aan dat zij serieus omgaan met hun verantwoordelijkheden onder de NIS2-richtlijn en dat zij proactief werken aan het verbeteren van hun cybersecurity-postuur. ISO 27001, de internationale standaard voor informatiebeveiligingsmanagement, bevat in controle A.13.1.1 specifieke vereisten voor netwerkbeveiliging. Deze controle vereist dat organisaties netwerkdiensten beveiligen en toegang tot netwerkdiensten beheren op een manier die consistent is met het beveiligingsbeleid van de organisatie. Dit omvat het implementeren van netwerksegmentatie, het gebruik van firewalls en andere netwerkbeveiligingsapparatuur, en het beperken van toegang tot netwerkdiensten tot alleen geautoriseerde gebruikers en systemen. Het uitschakelen van publieke toegang en het gebruik van privé-eindpunten is een effectieve manier om te voldoen aan deze controle, omdat het zorgt voor gecontroleerde en beveiligde toegang tot netwerkdiensten. Organisaties die gecertificeerd zijn volgens ISO 27001 of die werken aan certificering, moeten kunnen aantonen dat zij passende maatregelen hebben getroffen om netwerkbeveiliging te waarborgen, en het uitschakelen van publieke toegang is een concrete, verifieerbare maatregel die kan worden gedocumenteerd en geaudit. Voor Nederlandse overheidsorganisaties is compliance met deze frameworks niet alleen een best practice, maar vaak ook een wettelijke verplichting. Het BIO (Baseline Informatiebeveiliging Overheid) bevat vergelijkbare vereisten voor netwerkbeveiliging, en organisaties die werken met gevoelige overheidsgegevens moeten kunnen aantonen dat zij passende maatregelen hebben getroffen om deze gegevens te beschermen. Het BIO is gebaseerd op internationale standaarden zoals ISO 27001 en NIST, maar is specifiek aangepast aan de Nederlandse context en de behoeften van overheidsorganisaties. Het uitschakelen van publieke toegang en het gebruik van privé-eindpunten is een concrete, verifieerbare maatregel die kan worden gedocumenteerd en geaudit, en die direct bijdraagt aan het voldoen aan de BIO-vereisten voor netwerkbeveiliging. Bij auditing moeten organisaties kunnen aantonen dat publieke toegang daadwerkelijk is uitgeschakeld voor alle relevante diensten. Dit vereist uitgebreide documentatie van de configuratie-instellingen, logs van toegangspogingen, en bewijs dat alleen toegang via privé-eindpunten mogelijk is. Auditors zullen niet alleen kijken naar de configuratie-instellingen zelf, maar ook naar de processen en procedures die ervoor zorgen dat deze instellingen correct worden geïmplementeerd en onderhouden. Regelmatige compliance-controles moeten verifiëren dat deze instellingen niet zijn gewijzigd en dat nieuwe diensten ook correct zijn geconfigureerd met uitgeschakelde publieke toegang. Het is belangrijk dat organisaties een proces hebben voor het controleren van nieuwe diensten en het verifiëren dat zij voldoen aan de beveiligingsvereisten voordat zij in productie worden genomen. Dit proces moet worden gedocumenteerd en regelmatig worden geëvalueerd om ervoor te zorgen dat het effectief blijft in het voorkomen van configuratiefouten die de beveiliging kunnen compromitteren.

Monitoring

Het monitoren van de publieke netwerktoegang-instellingen voor Platform-as-a-Service diensten is een kritiek onderdeel van een effectieve beveiligingsstrategie. Continue monitoring zorgt ervoor dat de beveiligingsconfiguratie niet wordt gewijzigd door onbedoelde acties, automatische updates of mogelijk kwaadwillende activiteiten. Organisaties moeten een gestructureerde aanpak implementeren die regelmatige controles, geautomatiseerde waarschuwingen en compliance-verificatie omvat. De basis van effectieve monitoring begint bij het regelmatig controleren van de PublicNetworkAccess-instelling voor alle relevante PaaS-diensten binnen de organisatie. Dit omvat niet alleen de diensten die reeds zijn geconfigureerd met uitgeschakelde publieke toegang, maar ook nieuwe diensten die worden aangemaakt. Azure biedt verschillende methoden om deze instellingen te controleren, waaronder de Azure Portal, Azure PowerShell, Azure CLI en Azure Resource Graph queries. De keuze voor een specifieke methode hangt af van de automatisering die de organisatie heeft geïmplementeerd en de frequentie waarmee controles worden uitgevoerd. Geautomatiseerde monitoring is essentieel om te garanderen dat wijzigingen in de publieke netwerktoegang-instellingen onmiddellijk worden gedetecteerd. Dit kan worden bereikt door het implementeren van Azure Policy regels die automatisch controleren of PublicNetworkAccess op Uitgeschakeld staat voor alle relevante diensten. Wanneer een dienst wordt aangemaakt of gewijzigd waarbij publieke toegang is ingeschakeld, genereert Azure Policy automatisch een waarschuwing en kan deze zelfs automatisch worden gecorrigeerd via automatische herstelacties. Deze geautomatiseerde benadering vermindert niet alleen de werklast van IT-beheerders, maar zorgt er ook voor dat afwijkingen van de gewenste configuratie onmiddellijk worden geïdentificeerd en aangepakt. Naast het monitoren van de configuratie-instellingen zelf, is het belangrijk om ook de daadwerkelijke toegangspogingen te monitoren. Azure-logboeken bevatten informatie over pogingen om toegang te krijgen tot PaaS-diensten via publieke eindpunten, zelfs wanneer deze zijn uitgeschakeld. Het analyseren van deze logboeken kan inzicht geven in potentiële beveiligingsbedreigingen, zoals herhaalde toegangspogingen vanaf verdachte IP-adressen of geografische locaties. Deze informatie is waardevol voor het identificeren van mogelijke aanvalspogingen en het nemen van aanvullende beveiligingsmaatregelen indien nodig. Logboekanalyse moet worden uitgevoerd met regelmatige tussenpozen, waarbij de frequentie afhankelijk is van het risiconiveau van de organisatie en de kritikaliteit van de gegevens die worden verwerkt. Voor organisaties met gevoelige overheidsgegevens is dagelijkse logboekanalyse aan te bevelen, terwijl voor minder kritieke omgevingen wekelijkse controles voldoende kunnen zijn. De resultaten van deze analyses moeten worden gedocumenteerd en bewaard voor audit-doeleinden, wat bijdraagt aan compliance met verschillende beveiligingsframeworks en regelgeving. Azure Monitor en Azure Security Center bieden geïntegreerde mogelijkheden voor het monitoren van netwerkbeveiligingsinstellingen en het genereren van waarschuwingen wanneer afwijkingen worden gedetecteerd. Deze services kunnen worden geconfigureerd om automatisch meldingen te verzenden wanneer een dienst wordt gewijzigd met ingeschakelde publieke toegang, of wanneer toegangspogingen worden gedetecteerd vanaf locaties buiten het toegestane virtuele netwerk. De waarschuwingen kunnen worden geconfigureerd om te worden verzonden via e-mail, SMS, of geïntegreerd met incidentmanagement systemen zoals ServiceNow of Azure DevOps. Compliance-monitoring is een belangrijk aspect dat organisaties moeten implementeren om te kunnen aantonen dat zij voldoen aan verschillende beveiligingsstandaarden en regelgeving. Dit omvat het regelmatig genereren van rapporten die aantonen dat alle relevante diensten zijn geconfigureerd met uitgeschakelde publieke toegang. Deze rapporten moeten worden bewaard voor audit-doeleinden en moeten voldoende detail bevatten om externe auditors in staat te stellen de configuratie te verifiëren. Het is raadzaam om deze rapporten minimaal maandelijks te genereren, hoewel voor organisaties met hoge compliance-vereisten wekelijkse of zelfs dagelijkse rapporten kunnen worden vereist. Het monitoren van publieke netwerktoegang-instellingen moet worden geïntegreerd in het bredere beveiligingsmonitoringprogramma van de organisatie. Dit betekent dat de monitoring-activiteiten moeten worden gecoördineerd met andere beveiligingsmaatregelen, zoals het monitoren van netwerkverkeer, het analyseren van beveiligingslogboeken, en het implementeren van bedreigingsdetectie-systemen. Door deze verschillende monitoring-activiteiten te integreren, kunnen organisaties een compleet beeld krijgen van hun beveiligingspostuur en kunnen zij sneller reageren op potentiële beveiligingsbedreigingen. Effectieve monitoring vereist ook dat er duidelijke procedures zijn voor het reageren op gedetecteerde afwijkingen. Wanneer een dienst wordt gedetecteerd met ingeschakelde publieke toegang terwijl dit niet is toegestaan volgens het beveiligingsbeleid, moeten er duidelijke stappen zijn voor het onderzoeken van de oorzaak, het corrigeren van de configuratie, en het voorkomen van vergelijkbare incidenten in de toekomst. Deze procedures moeten worden gedocumenteerd en alle betrokken partijen moeten bekend zijn met hun verantwoordelijkheden bij het reageren op dergelijke incidenten.

Gebruik PowerShell-script public-network-access-disabled.ps1 (functie Invoke-Monitoring) – Controleren.

Remediatie

Remediatie van onjuiste publieke netwerktoegang-instellingen voor Platform-as-a-Service diensten is een kritiek proces dat snel en accuraat moet worden uitgevoerd wanneer afwijkingen van het beveiligingsbeleid worden gedetecteerd. Het doel van remediatie is om ervoor te zorgen dat alle relevante diensten correct zijn geconfigureerd met uitgeschakelde publieke toegang, terwijl wordt gegarandeerd dat legitieme toegang via privé-eindpunten niet wordt verstoord. Organisaties moeten een gestructureerde remediatieprocedure hebben die rekening houdt met verschillende scenario's en die zorgt voor minimale impact op bedrijfsprocessen. Het remediatieproces begint bij het identificeren van diensten die niet voldoen aan het beveiligingsbeleid. Dit kan gebeuren via geautomatiseerde monitoring-tools, handmatige controles, of externe audits. Zodra een dienst is geïdentificeerd met onjuiste configuratie, moet eerst worden onderzocht waarom de afwijking is ontstaan. Dit onderzoek is belangrijk omdat het helpt om te voorkomen dat vergelijkbare incidenten in de toekomst optreden en omdat het inzicht geeft in mogelijke zwakheden in het configuratiebeheerproces. Voordat remediatie wordt uitgevoerd, moet worden geverifieerd dat er werkende privé-eindpunten aanwezig zijn voor de diensten die zullen worden bijgewerkt. Het uitschakelen van publieke toegang zonder werkende privé-connectiviteit kan leiden tot toegangsverlies, wat ernstige gevolgen kan hebben voor bedrijfsprocessen. Deze verificatie moet worden uitgevoerd door te testen of de diensten toegankelijk zijn via de privé-eindpunten en of alle afhankelijke applicaties en services correct functioneren. Indien privé-eindpunten ontbreken of niet correct functioneren, moeten deze eerst worden geïmplementeerd en getest voordat publieke toegang wordt uitgeschakeld. Het uitvoeren van de remediatie zelf kan worden gedaan via verschillende methoden, afhankelijk van de voorkeur en automatisering van de organisatie. Via de Azure Portal kan de PublicNetworkAccess-instelling worden gewijzigd door naar de netwerkconfiguratie van de betreffende dienst te navigeren en de instelling handmatig aan te passen. Voor grootschalige remediatie of geautomatiseerde herstelacties zijn Azure PowerShell of Azure CLI meer geschikt, omdat deze kunnen worden geïntegreerd in scripts en workflow-automatisering. Azure Policy kan ook worden geconfigureerd om automatische herstelacties uit te voeren wanneer afwijkingen worden gedetecteerd, wat de snelste en meest consistente methode is voor remediatie. Bij het uitvoeren van remediatie voor meerdere diensten tegelijk is het belangrijk om een gefaseerde aanpak te volgen. Het corrigeren van alle diensten tegelijkertijd kan leiden tot verstoring van bedrijfsprocessen als er onverwachte problemen optreden. Een betere aanpak is om eerst diensten in de laagste risicocategorie te corrigeren, bijvoorbeeld test- en ontwikkelomgevingen, en vervolgens door te gaan naar productieomgevingen. Tussen elke fase moet worden geverifieerd dat de correcties succesvol zijn en dat er geen onbedoelde gevolgen zijn voor toegankelijkheid of functionaliteit. Na het uitvoeren van remediatie is verificatie essentieel om te bevestigen dat de wijzigingen correct zijn toegepast. Dit omvat het controleren dat de PublicNetworkAccess-instelling daadwerkelijk op Uitgeschakeld staat voor alle gecorrigeerde diensten, en het testen dat toegang via privé-eindpunten nog steeds functioneel is. Daarnaast moeten toegangspogingen vanaf externe locaties worden getest om te bevestigen dat publieke toegang inderdaad is geblokkeerd. Deze verificatiestappen moeten worden gedocumenteerd voor audit-doeleinden en compliance-verificatie. Documentatie van het remediatieproces is cruciaal voor compliance en audit-doeleinden. Alle stappen die zijn genomen tijdens het remediatieproces moeten worden vastgelegd, inclusief de reden voor de remediatie, de diensten die zijn bijgewerkt, de methoden die zijn gebruikt, en de verificatiestappen die zijn uitgevoerd. Deze documentatie moet worden bewaard volgens de documentretentievereisten van de organisatie en moet beschikbaar zijn voor interne en externe auditors. Naast compliance-doeleinden helpt goede documentatie ook bij het verbeteren van het remediatieproces door lessen te leren van eerdere incidenten. Het voorkomen van toekomstige afwijkingen is een belangrijk onderdeel van het remediatieproces. Na het corrigeren van een afwijking moet worden geanalyseerd waarom de afwijking is ontstaan en welke maatregelen kunnen worden genomen om te voorkomen dat vergelijkbare incidenten optreden. Dit kan bijvoorbeeld betekenen dat het configuratiebeheerproces moet worden verbeterd, dat aanvullende controles moeten worden geïmplementeerd, of dat medewerkers moeten worden getraind in het correct configureren van diensten. Door deze preventieve maatregelen te nemen, kan de organisatie het aantal toekomstige remediatie-incidenten verminderen en de algehele beveiligingspostuur verbeteren. In noodsituaties kan het nodig zijn om publieke toegang tijdelijk weer in te schakelen, bijvoorbeeld wanneer privé-eindpunten niet beschikbaar zijn vanwege technische problemen of onderhoud. Deze break-glass procedure moet duidelijk gedocumenteerd zijn en moet beschrijven wanneer en hoe publieke toegang tijdelijk kan worden ingeschakeld. Het is essentieel dat deze procedure alleen wordt gebruikt in echte noodsituaties en dat alle activiteiten worden gelogd en geaudit. Zodra de noodsituatie is opgelost, moet publieke toegang onmiddellijk weer worden uitgeschakeld en moeten de normale remediatieprocedures worden gevolgd om te verifiëren dat de configuratie weer correct is.

Gebruik PowerShell-script public-network-access-disabled.ps1 (functie Invoke-Remediation) – Herstellen.

Compliance & Frameworks

• CIS M365: Control Multiple (L2) - Publieke toegang uitschakelen
• BIO: 13.01.01 - Netwerkbeveiliging
• ISO 27001:2022: A.13.1.1 -

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

Public Network Access Disabled: Disable public endpoints NA Private Endpoint deployment (VNet-only access). SQL/Storage/Key Vault: PublicNetworkAccess=Disabled. Activatie: PaaS resource → Networking → Public access: Disabled. Gratis. Verplicht NIS2, Zero Trust. Implementatie: 3-4 uur (test Private Endpoint first). Enforces VNet-only isolation.

• Implementatietijd: 4 uur
• FTE required: 0.05 FTE