Azure SQL Database: Publieke Endpoints Uitschakelen Voor Netwerkisolatie

Publieke SQL endpoints (*.database.windows.net) zijn standaard via internet bereikbaar, wat een aanzienlijk beveiligingsrisico vormt. Deze publieke exposure creëert continu aanvalsoppervlak: brute-force-aanvallen vinden 24/7 plaats met duizenden login-pogingen per dag die automatisch worden uitgevoerd door botnet sinds de database een publicly resolvable DNS-naam heeft, SQL injection-aanvallen kunnen vanaf elke locatie ter wereld worden geprobeerd zonder netwerk-based filtering, echte netwerk-segmentatie is onmogelijk omdat de database fundamenteel internet-facing blijft ongeacht firewall-regels, en firewall-regels zijn complex om te beheren, error-prone bij configuratie, en bieden slechts beperkte bescherming omdat IP-adressen kunnen worden gespoofed of aanvallers kunnen opereren vanuit gewhiteliste ranges. Security monitoring toont dat publiek toegankelijke databases gemiddeld honderden tot duizenden aanvalspogingen per dag ondergaan. Private Endpoints-only configuratie elimineert al deze risico's door volledige afwezigheid van internet exposure waarbij de database niet meer via publieke internet bereikbaar is en geen publicly resolvable DNS heeft, VNet network controls zoals Network Security Groups (NSGs) kunnen worden toegepast voor granulaire verkeerscontrole, private IP addressing binnen het VNet-adresbereik wordt gebruikt wat externe aanvallers geen target geeft, verkeer wordt gerouteerd via Azure Backbone-netwerk wat zowel sneller als veiliger is dan publieke internet-routing, en perfecte alignment met Zero Trust-principes waarbij netwerk-locatie een verification factor is. Deze architectuur voldoet aan NIS2 Artikel 21 dat netwerk-segmentatie vereist voor kritieke informatiesystemen.

Implementatie

Deze maatregel schakelt publieke endpoint-toegang voor Azure SQL Database volledig uit door de publicNetworkAccess-property op 'Disabled' te zetten. Kritiek is dat deze stap ALLEEN mag worden uitgevoerd NADAT Private Endpoints succesvol zijn geïmplementeerd en getest, anders verliest u alle toegang tot de database. De implementatie-workflow is: eerst moet een Private Endpoint voor de SQL server worden gecreëerd en gekoppeld aan een VNet subnet (zie sql-private-endpoints-configured.json), connectivity moet grondig worden getest door vanaf VMs binnen het VNet verbinding te maken met de database via het private IP-adres, Private DNS Zone moet correct zijn geconfigureerd zodat DNS-queries voor de SQL FQDN resolven naar het private IP in plaats van publiek IP, en pas daarna mag publicNetworkAccess worden ingesteld op 'Disabled' via Azure Portal onder Networking settings of via PowerShell. Na deze configuratie moet worden geverifieerd dat publieke toegang daadwerkelijk is geblokkeerd door vanaf buiten het VNet (bijvoorbeeld vanaf uw development machine zonder VPN) te proberen verbinding te maken - dit moet falen met een connection refused-error. Een formele break-glass procedure moet worden gedocumenteerd die beschrijft hoe publieke toegang tijdelijk kan worden heringeschakeld in noodsituaties (bijvoorbeeld bij VNet-issues of tijdens disaster recovery), inclusief approval workflow en tijdslimiet. Het resultaat is dat SQL Database uitsluitend toegankelijk is via het VNet en connected networks zoals on-premises via ExpressRoute/VPN, zonder enige internet-routing, wat het aanvalsoppervlak met circa 99% reduceert en voldoet aan de strengste compliance-eisen voor database-beveiliging.

Vereisten

Het uitschakelen van publieke endpoints voor Azure SQL Database is een kritieke beveiligingsmaatregel die zorgvuldige voorbereiding vereist. Voordat deze configuratie kan worden geïmplementeerd, moeten verschillende technische en organisatorische vereisten worden vervuld om te voorkomen dat de database ontoegankelijk wordt of dat kritieke bedrijfsprocessen worden verstoord. Deze vereisten vormen de fundering voor een veilige en succesvolle migratie naar een volledig geïsoleerde netwerkarchitectuur.

De primaire en meest kritieke vereiste is de volledige implementatie en validatie van privé endpoints voor de SQL server. Privé endpoints vormen de enige toegangsroute naar de database zodra publieke endpoints zijn uitgeschakeld, waardoor hun correcte configuratie absoluut essentieel is. Dit betekent dat het privé endpoint niet alleen moet zijn aangemaakt, maar ook daadwerkelijk operationeel moet zijn en getest moet zijn vanuit verschillende bronnen binnen het virtuele netwerk. De implementatie omvat het koppelen van het privé endpoint aan een geschikt subnet binnen het Azure Virtual Network, waarbij rekening moet worden gehouden met netwerksegmentatie-vereisten en beveiligingsbeleid. Het subnet moet voldoende IP-adresruimte hebben en moet zijn geconfigureerd met de juiste Network Security Group-regels om verkeer naar de database toe te staan.

Naast de fysieke implementatie van het privé endpoint is de configuratie van een Private DNS Zone een onmisbare vereiste. Zonder correcte DNS-configuratie zullen applicaties en services niet in staat zijn om de database te vinden, zelfs als het privé endpoint technisch correct is geconfigureerd. De Private DNS Zone zorgt ervoor dat DNS-queries voor de SQL Database Fully Qualified Domain Name (FQDN) worden omgezet naar het privé IP-adres binnen het Virtual Network in plaats van naar het publieke IP-adres. Deze configuratie moet worden gekoppeld aan het Virtual Network waar de database-verbindingen vandaan komen, en moet worden gevalideerd door middel van DNS-resoluties vanuit verschillende bronnen binnen het netwerk.

Uitgebreide netwerkconnectiviteitstests vormen een kritieke vereiste voordat publieke endpoints kunnen worden uitgeschakeld. Deze tests moeten worden uitgevoerd vanuit alle relevante bronnen die toegang tot de database nodig hebben, inclusief virtuele machines binnen het Virtual Network, on-premises systemen die verbinding maken via ExpressRoute of VPN, en development-workstations die via corporate VPN verbinding maken. De tests moeten niet alleen verifiëren dat verbindingen technisch mogelijk zijn, maar ook dat de prestaties acceptabel zijn en dat alle benodigde database-operaties kunnen worden uitgevoerd. Het is aanbevolen om deze tests gedurende een periode van minimaal 24 tot 48 uur uit te voeren in een productie-achtige omgeving om eventuele edge cases of timing-gerelateerde problemen te identificeren.

Een essentiële organisatorische vereiste is dat alle applicaties en services die toegang tot de database nodig hebben, moeten worden geïdentificeerd en gevalideerd. Dit omvat niet alleen productie-applicaties, maar ook development-omgevingen, CI/CD-pipelines, monitoring-tools, backup-systemen en administratieve tools. Elke applicatie moet worden beoordeeld op haar vermogen om via het Virtual Network of via VPN/ExpressRoute verbinding te maken met de database. Applicaties die momenteel afhankelijk zijn van publieke endpoint-toegang moeten worden gemigreerd of aangepast voordat publieke endpoints kunnen worden uitgeschakeld. Dit vereist coördinatie met verschillende teams, waaronder applicatie-eigenaren, development-teams en operations-teams.

Ten slotte moet een uitgebreide break-glass procedure worden gedocumenteerd voordat publieke endpoints worden uitgeschakeld. Deze procedure beschrijft hoe publieke toegang in noodsituaties tijdelijk kan worden heringeschakeld, bijvoorbeeld bij kritieke netwerkproblemen, disaster recovery-scenario's of onvoorziene configuratiefouten. De procedure moet duidelijke goedkeuringsworkflows bevatten, tijdslimieten voor het herinschakelen van publieke toegang, en verplichte root cause analysis-processen. Deze documentatie is niet alleen belangrijk voor operationele doeleinden, maar ook voor compliance en auditing, omdat auditors willen zien dat er adequate noodprocedures bestaan voor kritieke beveiligingsconfiguraties.

Implementatie

De implementatie van het uitschakelen van publieke endpoints voor Azure SQL Database vereist een uiterst zorgvuldige en gestructureerde aanpak. De meest kritieke overweging is de volgorde van operaties: privé endpoints moeten volledig operationeel zijn voordat publieke endpoints kunnen worden uitgeschakeld. Het omkeren van deze volgorde resulteert in een complete database-outage waarbij geen enkele applicatie, gebruiker of beheerder nog toegang heeft tot de database. Deze situatie kan alleen worden opgelost door het privé endpoint alsnog te implementeren, wat in een productieomgeving kan leiden tot aanzienlijke bedrijfsimpact en mogelijke dataverlies of service-onderbrekingen.

De eerste en meest cruciale fase van de implementatie betreft de volledige voorbereiding en validatie van het privé endpoint. Deze voorbereiding begint met het voltooien van de volledige privé endpoint-implementatie, waarbij een Azure Virtual Network en een geschikt subnet moeten worden aangemaakt of geïdentificeerd. Het privé endpoint zelf moet worden gecreëerd en gekoppeld aan de SQL Server, waarbij zorgvuldig moet worden gelet op de juiste resource group, locatie en netwerkconfiguratie. De Private DNS Zone moet worden geconfigureerd met de juiste zone-naam (privatelink.database.windows.net) en gekoppeld aan het Virtual Network, zodat DNS-resolutie correct werkt voor alle resources die toegang tot de database nodig hebben.

Na de technische configuratie volgt een uitgebreide validatiefase waarin alle netwerkconnectiviteit grondig moet worden getest. Deze tests moeten worden uitgevoerd vanuit verschillende bronnen binnen het Virtual Network, inclusief virtuele machines, container-instances en andere Azure-services. De tests moeten niet alleen verifiëren dat verbindingen technisch mogelijk zijn, maar ook dat de prestaties acceptabel zijn en dat alle benodigde database-operaties kunnen worden uitgevoerd. Het is essentieel dat alle applicaties die afhankelijk zijn van de database succesvol kunnen verbinden via het privé endpoint voordat publieke toegang wordt uitgeschakeld. Deze validatie moet gedurende een periode van minimaal 24 tot 48 uur worden uitgevoerd in een productie-achtige omgeving om eventuele edge cases, timing-gerelateerde problemen of configuratiefouten te identificeren voordat ze kritieke impact kunnen hebben.

Een kritieke stap in de voorbereidingsfase is het verkrijgen van bevestiging van alle stakeholders dat hun applicaties en services correct functioneren via het privé endpoint. Dit vereist coördinatie met applicatie-eigenaren, development-teams, operations-teams en andere belanghebbenden die afhankelijk zijn van database-toegang. Alleen wanneer alle stakeholders hebben bevestigd dat hun systemen correct werken en wanneer het privé endpoint honderd procent operationeel is, mag worden overgegaan tot het uitschakelen van publieke toegang. Het is absoluut verboden om verder te gaan met het uitschakelen van publieke toegang totdat deze bevestigingen zijn ontvangen, omdat dit kan leiden tot onverwachte service-onderbrekingen en bedrijfsimpact.

Fase 1 van de implementatie betreft de communicatie met alle stakeholders voordat de wijziging wordt doorgevoerd. Deze fase is cruciaal omdat het uitschakelen van publieke endpoints impact heeft op verschillende groepen binnen de organisatie. Alle database-stakeholders moeten worden geïnformeerd over de geplande wijziging en de gevolgen daarvan voor hun dagelijkse werkzaamheden. Applicatie-eigenaren moeten worden gewaarschuwd dat externe toegang tot de database stopt, wat betekent dat applicaties die momenteel vanaf het internet verbinding maken niet meer zullen functioneren zonder aanpassingen. Development-teams moeten worden geïnformeerd dat lokale development vanaf thuisnetwerken niet meer mogelijk is zonder VPN-verbinding, wat kan betekenen dat ontwikkelaars moeten overschakelen naar development-omgevingen binnen het Virtual Network of een corporate VPN moeten gebruiken. Database-beheerders (DBA-teams) moeten worden gewaarschuwd dat Azure Portal SQL-tools niet meer werken zonder VPN-verbinding, wat kan betekenen dat zij hun werkwijze moeten aanpassen of toegang moeten hebben tot een VPN-verbinding. CI/CD-pipeline-eigenaren moeten worden geïnformeerd dat build-agents binnen het Virtual Network moeten zijn of VPN moeten gebruiken om verbinding te kunnen maken met de database.

Hoewel de disable-operatie zelf instant is en geen database-restart vereist, is het verstandig om een onderhoudsvenster van ongeveer twee uur te plannen voor troubleshooting in het geval dat er onverwachte connectiviteitsproblemen ontstaan. Dit venster geeft het team de tijd om eventuele problemen te identificeren en op te lossen voordat ze kritieke impact hebben op bedrijfsprocessen. Tijdens dit venster moeten alle relevante teams beschikbaar zijn voor snelle respons en troubleshooting.

Een essentiële voorbereidingsstap is het voorbereiden van een break-glass procedure die beschrijft hoe publieke toegang in noodsituaties tijdelijk kan worden heringeschakeld. Deze procedure moet gedetailleerd documenteren hoe publieke toegang kan worden heringeschakeld via PowerShell met het commando Update-AzSqlServer -ResourceGroupName 'rg' -ServerName 'server' -PublicNetworkAccess Enabled. De procedure moet duidelijke goedkeuringsworkflows bevatten, waarbij executive approval vereist is voordat publieke toegang kan worden heringeschakeld. Er moet een maximum tijdslimiet worden vastgesteld voor het publieke toegangvenster, bijvoorbeeld 24 uur, waarna publieke toegang automatisch weer moet worden uitgeschakeld. Bovendien moet er een verplichte root cause analysis worden uitgevoerd om te begrijpen waarom het herinschakelen van publieke toegang nodig was, zodat toekomstige incidenten kunnen worden voorkomen.

Voorafgaand aan de implementatie moet worden geverifieerd dat recente database-backups bestaan, bij voorkeur minder dan 24 uur oud, voor het worst-case recovery-scenario. Hoewel het uitschakelen van publieke endpoints normaal gesproken geen dataverlies veroorzaakt, is het belangrijk om voorbereid te zijn op eventuele onvoorziene problemen die kunnen optreden tijdens of na de implementatie. Deze backups moeten worden getest om te verifiëren dat ze correct zijn en kunnen worden gebruikt voor herstel indien nodig.

Fase 2 van de implementatie betreft het daadwerkelijk uitschakelen van publieke netwerktoegang. Deze fase duurt ongeveer vijf minuten voor de uitvoering zelf, gevolgd door dertig minuten validatie. De uitvoering kan worden gedaan via de Azure Portal door te navigeren naar de SQL Server, vervolgens naar de Networking-sectie, en daar de optie Public network access te selecteren en 'Disabled' te kiezen. Na het klikken op 'Save' is de wijziging onmiddellijk actief en worden alle bestaande publieke endpoint-verbindingen direct beëindigd. Het is belangrijk om te begrijpen dat deze wijziging geen database-restart vereist en direct effect heeft, wat betekent dat alle actieve verbindingen via het publieke endpoint onmiddellijk worden verbroken.

Een alternatieve methode voor het uitschakelen van publieke toegang is via PowerShell, wat wordt aanbevolen voor audit trail-doeleinden. Het PowerShell-commando Update-AzSqlServer -ResourceGroupName 'rg-name' -ServerName 'server-name' -PublicNetworkAccess 'Disabled' kan worden gebruikt om de wijziging programmatisch door te voeren. Deze methode heeft het voordeel dat de actie wordt gelogd in de PowerShell-sessie, wat nuttig is voor compliance-documentatie en auditing. De log-output moet worden bewaard voor toekomstige referentie en compliance-doeleinden.

Onmiddellijk na het uitschakelen van publieke toegang moet uitgebreide validatie worden uitgevoerd om te verifiëren dat de configuratie correct werkt. Deze validatie omvat twee kritieke tests: ten eerste moet worden getest dat VNet-gebaseerde applicaties nog steeds werken via het privé endpoint. Deze test moet slagen, omdat deze applicaties de enige zijn die nog toegang moeten hebben tot de database. Ten tweede moet worden getest dat publieke internettoegang daadwerkelijk faalt door te proberen verbinding te maken vanaf een extern netwerk zonder VPN. Deze test moet falen met een connection timeout, wat bevestigt dat publieke toegang correct is uitgeschakeld.

Gedurende de eerste dertig minuten na het uitschakelen van publieke toegang moeten application health dashboards continu worden gemonitord op connectiviteitsfouten. Als er kritieke problemen worden gedetecteerd, moet onmiddellijk worden teruggedraaid door publieke toegang weer in te schakelen. Deze snelle respons is essentieel om te voorkomen dat bedrijfsprocessen worden verstoord en om de impact van eventuele onvoorziene problemen te minimaliseren.

Fase 3 van de implementatie betreft het opruimen van firewall-regels die niet meer nodig zijn na het uitschakelen van publieke endpoints. Deze fase duurt ongeveer vijftien minuten en is belangrijk voor het onderhouden van een schone en begrijpelijke configuratie. Alle IP-gebaseerde firewall-regels zijn nu verouderd omdat het publieke endpoint is uitgeschakeld, wat betekent dat deze regels geen effect meer hebben. Firewall-regels werken alleen voor publieke endpoints, en omdat deze nu zijn uitgeschakeld, hebben alle IP-range regels geen functie meer en kunnen ze veilig worden verwijderd.

De cleanup kan worden uitgevoerd via de Azure Portal door te navigeren naar de SQL Server, vervolgens naar de Networking-sectie, en daar naar Firewall rules. Alle IP-range regels moeten worden verwijderd omdat ze nu betekenisloos zijn. Het is belangrijk om de firewall rule-documentatie te bewaren in een archief voor historische referentie, maar deze moet worden gemarkeerd als 'Verouderd - Private Endpoint Only Architecture' om duidelijk te maken dat deze regels niet meer actief zijn. Een uitzondering op deze cleanup is de 'Allow Azure services' instelling, die moet worden gedocumenteerd voor het emergency re-enable-scenario, maar die in normale operaties uitgeschakeld moet blijven.

Fase 4 van de implementatie betreft uitgebreide connectiviteitsvalidatie en monitoring, wat ongeveer een uur duurt. Deze fase is cruciaal om te verifiëren dat alle systemen correct functioneren na het uitschakelen van publieke endpoints. De validatie omvat uitgebreide connectiviteitstests voor verschillende scenario's: productie-applicaties binnen het Virtual Network moeten worden gemonitord door middel van application logs gedurende 24 uur om te verifiëren dat er geen connectiviteitsfouten optreden. On-premises systemen die verbinding maken via ExpressRoute of VPN moeten worden getest door database-queries uit te voeren om te verifiëren dat de verbinding correct werkt. Development-workstations die verbinding maken via corporate VPN moeten worden getest om te verifiëren dat tools zoals SQL Server Management Studio (SSMS) en Azure Data Studio correct kunnen verbinden met de database.

Naast positieve tests moeten ook negatieve tests worden uitgevoerd om te verifiëren dat publieke toegang daadwerkelijk is geblokkeerd. Deze tests omvatten het proberen verbinding te maken vanaf een persoonlijke laptop zonder VPN, wat moet falen met een timeout. Bovendien moeten publieke internet-scanners zoals Shodan en Censys worden gemonitord om te verifiëren dat de SQL Server niet meer vindbaar is op deze scans. Het is belangrijk om te begrijpen dat de-indexing op deze scanners 7 tot 14 dagen kan duren, dus dit is een langetermijnmonitoring-activiteit.

Een belangrijke monitoring-configuratie is het instellen van alerting voor het herinschakelen van publieke toegang. Dit kan worden gedaan via Azure Policy of Azure Monitor alerts die worden geactiveerd wanneer de publicNetworkAccess-eigenschap wordt gewijzigd naar Enabled. Deze alerts helpen bij het detecteren van ongeautoriseerde wijzigingen of break-glass-scenario's, wat belangrijk is voor beveiliging en compliance. Wanneer een dergelijke alert wordt geactiveerd, moet onmiddellijk worden onderzocht waarom publieke toegang is heringeschakeld en of dit geautoriseerd was.

Ten slotte moeten alle runbooks en documentatie worden bijgewerkt om de nieuwe architectuur te reflecteren. Alle troubleshooting-guides moeten worden aangepast om de VPN-vereiste te vermelden, developer onboarding-documentatie moet worden bijgewerkt met VPN-setup-instructies, en de break-glass procedure voor het herinschakelen van publieke toegang moet worden gedocumenteerd. Deze documentatie-updates zijn essentieel om te zorgen dat alle teams en nieuwe medewerkers begrijpen hoe ze moeten werken met de nieuwe netwerkarchitectuur.

⏱️ **Totale Implementatietijd**: 2-3 uur (na Private Endpoint deployment compleet - dat is separate 3-4 uur). Breakdown: stakeholder communication 30 min, public disable execution 5 min, validation 30 min, firewall cleanup 15 min, extensive testing 1 uur.

💰 **Kosten**: Public endpoint disable is gratis - geen extra Azure-kosten. Vereist wel Private Endpoints (€6/maand per database - separate cost).

Compliance en Auditing

Het uitschakelen van publieke endpoints voor Azure SQL Database is een kritieke beveiligingsmaatregel die direct bijdraagt aan compliance met verschillende belangrijke beveiligingsstandaarden en regelgeving. Deze maatregel is niet alleen een best practice, maar in veel gevallen een verplichte vereiste voor organisaties die werken met gevoelige gegevens of die onder bepaalde regelgeving vallen. De compliance-aspecten van deze maatregel omvatten zowel technische beveiligingsstandaarden als regelgevingsvereisten die specifiek zijn voor de Nederlandse context.

De CIS Azure Benchmark bevat specifieke controles voor SQL-netwerkbeveiliging die het gebruik van privé endpoints en het uitschakelen van publieke endpoints vereisen. Deze controles zijn ontworpen om het aanvalsoppervlak van databases te minimaliseren en netwerkisolatie te waarborgen. Door publieke endpoints uit te schakelen, voldoet een organisatie aan deze CIS-controles en demonstreert zij een sterke beveiligingspostuur. De CIS Azure Benchmark wordt algemeen erkend als een belangrijke referentie voor cloudbeveiliging, en naleving van deze standaard is vaak een vereiste voor organisaties die werken met gevoelige gegevens of die contractuele verplichtingen hebben met betrekking tot beveiliging.

Zero Trust-architectuurprincipes vereisen netwerkisolatie als een fundamenteel onderdeel van de beveiligingsstrategie. In een Zero Trust-architectuur wordt ervan uitgegaan dat geen enkel netwerksegment inherent vertrouwd is, en alle toegang moet worden geverifieerd en geautoriseerd. Het uitschakelen van publieke endpoints is een directe implementatie van dit principe, omdat het ervoor zorgt dat databases niet meer toegankelijk zijn vanaf het publieke internet en alleen toegankelijk zijn via gecontroleerde netwerksegmenten. Deze netwerkisolatie is een essentieel onderdeel van een Zero Trust-architectuur en draagt bij aan het verminderen van het aanvalsoppervlak en het verbeteren van de algehele beveiligingspostuur.

ISO 27001, de internationale standaard voor informatiebeveiligingsmanagement, bevat specifieke controles voor netwerkbeveiliging. Controle A.13.1.1 vereist dat netwerkcontroles worden geïmplementeerd om netwerkdiensten te beveiligen. Het uitschakelen van publieke endpoints is een directe implementatie van deze controle, omdat het zorgt voor netwerksegmentatie en het beperken van netwerktoegang tot geautoriseerde bronnen. Door deze maatregel te implementeren, demonstreert een organisatie naleving van ISO 27001-vereisten en toont zij aan dat zij passende netwerkcontroles heeft geïmplementeerd om haar informatiebeveiliging te waarborgen.

De NIS2-richtlijn, die van toepassing is op essentiële en belangrijke entiteiten in de Europese Unie, bevat specifieke vereisten voor netwerksegmentatie. Artikel 21 van de NIS2-richtlijn vereist dat organisaties netwerksegmentatie implementeren voor kritieke informatiesystemen. Dit betekent dat databases met gevoelige gegevens niet publiek toegankelijk mogen zijn en moeten worden geïsoleerd binnen gecontroleerde netwerksegmenten. Het uitschakelen van publieke endpoints is een directe implementatie van deze vereiste en is verplicht voor organisaties die onder de NIS2-richtlijn vallen. Naleving van deze vereiste is niet alleen belangrijk voor beveiliging, maar ook voor het vermijden van potentiële boetes en andere sancties die kunnen worden opgelegd bij niet-naleving.

De Baseline Informatiebeveiliging Overheid (BIO) bevat specifieke thema's voor netwerkbeveiliging. Thema 13.01 vereist dat organisaties passende netwerkbeveiligingsmaatregelen implementeren, inclusief netwerkisolatie en het beperken van netwerktoegang. Het uitschakelen van publieke endpoints is een directe implementatie van deze BIO-vereiste en is verplicht voor Nederlandse overheidsorganisaties en organisaties die werken met overheidsgegevens. Naleving van BIO-vereisten is essentieel voor Nederlandse overheidsorganisaties en organisaties in de publieke sector, omdat deze standaard specifiek is ontworpen voor de Nederlandse context en rekening houdt met Nederlandse regelgeving en best practices.

Voor auditing-doeleinden is het belangrijk om te documenteren dat publieke endpoints zijn uitgeschakeld en dat alle database-toegang plaatsvindt via privé endpoints. Deze documentatie moet worden bewaard voor compliance- en auditing-doeleinden en moet regelmatig worden gecontroleerd om te verifiëren dat de configuratie ongewijzigd blijft. Auditors zullen willen zien dat er adequate netwerkisolatie is geïmplementeerd en dat er passende monitoring en alerting is geconfigureerd om te detecteren wanneer publieke toegang wordt heringeschakeld. Deze documentatie en monitoring zijn essentieel voor het aantonen van continue naleving van de verschillende beveiligingsstandaarden en regelgevingsvereisten.

Monitoring

Gebruik PowerShell-script sql-no-public-endpoints.ps1 (functie Invoke-Monitoring) – Controleren.

Remediatie

Gebruik PowerShell-script sql-no-public-endpoints.ps1 (functie Invoke-Remediation) – Herstellen.

Compliance & Frameworks

• CIS M365: Control SQL Network (L2) - No publieke endpoints voor Azure SQL Databases
• BIO: 13.01.01 - Netwerkbeveiliging - netwerk isolatie
• ISO 27001:2022: A.13.1.1, A.13.1.3 - netwerkcontroles en segregation
• NIS2: Artikel - netwerk segmentatie - Database isolation

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

Publieke Endpoint Disablement elimineert internet exposure van Azure SQL Databases door public network access volledig uit te schakelen zodat ALLEEN Private Endpoint VNet-connectivity mogelijk blijft. Deze maatregel VEREIST dat Private Endpoints EERST worden gedeployed (zie sql-private-endpoints-configured.json) omdat disablen van public access zonder Private Endpoint alternatief resulteert in zero connectivity - database wordt volledig onbereikbaar. Implementatie-volgorde: (1) Deploy Private Endpoints naar VNet-subnets, configure Private DNS voor name resolution, test connectivity vanaf VNet resources. (2) Disable public network access: Azure Portal → SQL Server → Networking → Public network access → Disabled, of via PowerShell Update-AzSqlServer -PublicNetworkAccess Disabled. (3) Verify dual isolation: Test dat publieke endpoint niet meer bereikbaar is (connection moet falen vanaf internet), Test dat Private Endpoint werkt (VNet resources kunnen connecten). Post-deployment: verwijder alle IP-based firewall rules (obsolete na public disable), update break-glass procedures voor emergency scenarios, document VNet-only architecture. Security impact: 99 procent reductie in attack surface door eliminatie van internet exposure, brute force attacks niet meer mogelijk (geen publiek endpoint om aan te vallen), SQL injection attempts vereisen eerst VNet access compromise (defensie in depth), DDoS protection (niet meer publiek benaderbaar). Deze maatregel is verplicht voor ALLE productie Azure SQL Databases met gevoelige data, mandatory voor NIS2 Artikel 21 network isolation compliance, vereist voor ISO 27001 A.13.1.1, essential voor Zero Trust architectures, en considered critical security control door NIST CSF. Belangrijke vereiste: Private Endpoints MOETEN operationeel zijn VOORDAT public access disabled - anders ontstaat complete database outage. Implementatie-effort: 2-3 uur (na Private Endpoint deployment - dat is 3-4 uur apart), geen extra kosten bovenop Private Endpoint costs (€6/maand). Return on investment komt van: 99 procent attack surface reduction, eliminated brute force risks (Microsoft: 3000+ daily attempts voorkomen), compliance success NIS2/ISO 27001, en Zero Trust architecture achievement.

• Implementatietijd: 3 uur
• FTE required: 0.03 FTE