Azure SQL Database: Private Endpoints Configureren Voor VNet-toegang

Standaard zijn Azure SQL Databases toegankelijk via publieke eindpunten met een *.database.windows.net URL die wereldwijd oplosbaar is via publieke DNS en vanaf elke locatie op internet bereikbaar is met de juiste inloggegevens. Deze architectuur creëert inherente beveiligingsrisico's: brute-force authenticatie-aanvallen worden continu uitgevoerd vanaf locaties over de hele wereld waarbij geautomatiseerde tools systematisch inlogpogingen doen, echte netwerksegmentatie is onmogelijk omdat de database fundamenteel internetgericht blijft waarbij firewall-regels de enige bescherming bieden, verkeer wordt gerouteerd via het publieke internet wat zowel hogere latency oplevert als beveiligingsrisico's introduceert door potentiële verkeersinterceptie, en compliance-hiaten ontstaan omdat NIS2 Artikel 21 netwerkisolatie vereist voor kritieke informatiesystemen wat niet kan worden bereikt met publiek toegankelijke eindpunten. Beveiligingstelemetrie toont dat publiek blootgestelde databases gemiddeld duizenden aanvalspogingen per dag ondervinden. Private Endpoints transformeren deze architectuur fundamenteel door internetblootstelling volledig te elimineren waarbij de database niet meer via publieke DNS oplosbaar is en geen publiek IP-adres heeft, VNet-only toegang af te dwingen waarbij uitsluitend verkeer vanuit het VNet of verbonden netwerken (ExpressRoute/VPN) de database kan bereiken, Network Security Group (NSG) controles mogelijk te maken voor granulaire verkeersfiltering op subnetniveau, verkeer te routeren via Azure's private backbone-netwerk wat zowel sneller (lagere latency) als veiliger is zonder blootstelling aan publiek internet, en echte netwerkisolatie te realiseren wat compliance waarborgt met ISO 27001 netwerkcontroles en NIS2 netwerksegmentatie-eisen. Deze architectuur is de gouden standaard voor productie-databases met gevoelige of bedrijfskritieke data.

Implementatie

Deze maatregel implementeert Private Endpoints voor Azure SQL Databases waarbij database-toegang volledig binnen VNet-grenzen wordt gebracht. De implementatie omvat het aanmaken van een Private Endpoint-resource die specifiek wordt gekoppeld aan de SQL-server, waarbij deze resource een netwerkinterface creëert in een gespecificeerd VNet-subnet. Deze netwerkinterface krijgt een private IP-adres toegewezen uit het subnetbereik dat als enig toegangspunt voor de database fungeert. De doelsubresource moet worden gespecificeerd als 'sqlServer' voor Azure SQL Database of 'managedInstance' voor SQL Managed Instance. Private DNS-integratie is kritiek en moet worden geconfigureerd door een Private DNS Zone (privatelink.database.windows.net) aan te maken of te selecteren die automatisch wordt gekoppeld aan het VNet, waardoor DNS-queries voor de database FQDN vanuit het VNet automatisch worden omgezet naar het private IP-adres in plaats van het publieke IP-adres. Applicaties die binnen het VNet draaien of via VPN of ExpressRoute verbonden zijn, gebruiken de normale database-verbindingsreeks zonder wijzigingen - de DNS-resolutie gebeurt automatisch via de Private DNS Zone. Na succesvolle implementatie moet connectiviteit worden getest door vanaf een VM binnen het VNet verbinding te maken met de SQL Database en te verifiëren dat dit via het private IP-adres verloopt (verifieerbaar via nslookup). Daarna kan publieke netwerktoegang worden uitgeschakeld (zie sql-no-public-endpoints.json) voor volledige isolatie. De kosten bedragen €6 per Private Endpoint per maand, waarbij meerdere eindpunten kunnen worden geconfigureerd voor scenario's met hoge beschikbaarheid waarbij verschillende VNets toegang nodig hebben. Deze implementatie vereist 3 tot 4 uur technisch werk per database, ondersteunt zowel Azure SQL Database als SQL Managed Instance, en is de sterk aanbevolen architectuur voor alle productie-databases met gevoelige gegevens, compliance-vereisten of Zero Trust-principes.

Vereisten

Voordat u begint met de implementatie van Private Endpoints voor Azure SQL Database, is het essentieel om te verifiëren dat alle benodigde infrastructuurcomponenten en voorbereidingen op hun plaats zijn. Deze maatregel vereist een grondige planning en een goed begrip van de netwerkarchitectuur binnen uw Azure-omgeving. De implementatie van Private Endpoints is niet alleen een technische configuratie, maar vormt een fundamentele wijziging in de netwerktoegang tot uw databases, wat gevolgen heeft voor alle applicaties en services die met de database communiceren.

De primaire vereiste is de aanwezigheid van een Azure SQL Database of SQL Managed Instance die reeds is geconfigureerd en operationeel is. Het maakt niet uit of dit een nieuwe implementatie betreft of een bestaande database die wordt gemigreerd naar een Private Endpoint-architectuur. Voor bestaande databases is het cruciaal om een volledige inventarisatie te maken van alle applicaties, services en gebruikers die momenteel toegang hebben tot de database via het publieke endpoint. Deze inventarisatie vormt de basis voor het testen en valideren van de Private Endpoint-connectiviteit voordat publieke toegang wordt uitgeschakeld.

Een Azure Virtual Network (VNet) met een dedicated subnet voor Private Endpoints is een absolute vereiste. Dit subnet moet specifiek worden gereserveerd voor Private Endpoint-resources en mag niet worden gedeeld met andere workloads zoals virtuele machines of applicatie-services. Deze scheiding is essentieel voor netwerksegmentatie en maakt het mogelijk om Network Security Groups (NSG) toe te passen die specifiek zijn afgestemd op database-verkeer. Het subnet moet minimaal een /24 CIDR-blok bevatten (256 IP-adressen), wat voldoende ruimte biedt voor meerdere Private Endpoints en toekomstige uitbreidingen. Voor organisaties met meerdere SQL-servers of databases is het raadzaam om een subnet van /23 of groter te overwegen om schaalbaarheid te waarborgen.

Private DNS-integratie is een kritieke component die niet mag worden overgeslagen. Een Private DNS Zone met de naam 'privatelink.database.windows.net' moet worden aangemaakt of geselecteerd binnen dezelfde resource group als uw netwerkinfrastructuur. Deze DNS-zone zorgt ervoor dat DNS-queries voor de SQL Server FQDN (bijvoorbeeld 'mijnserver.database.windows.net') automatisch worden omgezet naar het private IP-adres in plaats van het publieke IP-adres wanneer deze queries worden uitgevoerd vanuit resources binnen het gekoppelde VNet. Zonder deze DNS-integratie zouden applicaties nog steeds proberen te verbinden via het publieke endpoint, wat de beveiligingsvoordelen van Private Endpoints volledig teniet zou doen.

Alle applicaties en services die toegang nodig hebben tot de SQL Database moeten zich binnen hetzelfde VNet bevinden, of toegang hebben via een VPN-verbinding of Azure ExpressRoute. Dit betekent dat externe applicaties die uitsluitend via het publieke internet opereren, niet langer toegang zullen hebben tot de database na de implementatie van Private Endpoints en het uitschakelen van publieke toegang. Voor hybride scenario's waarbij on-premises applicaties toegang nodig hebben, moet een Site-to-Site VPN of ExpressRoute-verbinding worden geconfigureerd voordat de Private Endpoint-implementatie wordt voltooid. Cloud-native applicaties moeten worden geïmplementeerd binnen het VNet, bijvoorbeeld als Azure App Services met VNet-integratie of als virtuele machines binnen het VNet.

Budgettaire overwegingen zijn belangrijk bij de planning. Elke Private Endpoint kost €6 per maand, ongeacht het aantal databases op de SQL Server. Dit betekent dat één Private Endpoint alle databases op een specifieke SQL Server kan bedienen, wat de kosten per database aanzienlijk kan verlagen bij servers met meerdere databases. De Private DNS Zone kost €0,50 per maand en kan worden gedeeld over meerdere Private Endpoints binnen dezelfde zone, wat de totale kosten per SQL Server op ongeveer €6,50 per maand brengt. Voor organisaties met tientallen SQL-servers kunnen deze kosten oplopen, maar dit moet worden afgewogen tegen de aanzienlijke beveiligings- en compliance-voordelen.

Een break-glass procedure voor noodgevallen waarbij tijdelijk publieke toegang nodig is, moet worden gedocumenteerd en getest voordat de implementatie wordt voltooid. Hoewel het uitschakelen van publieke toegang een beveiligingsbest practice is, kunnen zich scenario's voordoen waarbij snelle toegang nodig is voor troubleshooting, data recovery of andere kritieke operaties. Deze procedure moet duidelijk beschrijven hoe publieke toegang tijdelijk kan worden ingeschakeld, welke autorisaties hiervoor nodig zijn, en hoe deze toegang weer wordt uitgeschakeld zodra de noodsituatie is opgelost. Het is essentieel dat deze procedure wordt gecontroleerd en gelogd voor audit-doeleinden.

Implementatie

**FASE 1: Virtual Network Voorbereiding**

De eerste fase van de implementatie richt zich op de voorbereiding van het Azure Virtual Network. Deze fase duurt ongeveer 30 minuten wanneer een nieuw VNet moet worden aangemaakt, of 10 minuten wanneer u gebruik maakt van een bestaand VNet. Het is van cruciaal belang dat de regio van het VNet exact overeenkomt met de regio waarin uw SQL Server is geïmplementeerd, omdat Private Endpoints alleen kunnen worden gekoppeld aan resources binnen dezelfde regio.

Als u een nieuw VNet aanmaakt, navigeert u in de Azure Portal naar Virtual Networks en selecteert u Create. Geef het VNet een duidelijke naam die de doelstelling weerspiegelt, zoals 'vnet-databases-prod'. Het adresbereik moet zorgvuldig worden gekozen om conflicten te voorkomen met bestaande netwerken. Een veelgebruikt adresbereik is 10.3.0.0/16, wat ruimte biedt voor meerdere subnets en toekomstige uitbreidingen. Let erop dat dit adresbereik niet mag overlappen met on-premises netwerken of andere Azure VNets waarmee u mogelijk peering wilt configureren.

Binnen het VNet moet een dedicated subnet worden aangemaakt dat specifiek is gereserveerd voor database Private Endpoints. Navigeer naar het VNet, selecteer Subnets en klik op Add subnet. Geef dit subnet een beschrijvende naam zoals 'snet-private-endpoints-sql' om duidelijk te maken dat dit subnet uitsluitend bedoeld is voor Private Endpoint-resources. Het adresbereik voor dit subnet moet voldoende ruimte bieden voor meerdere Private Endpoints. Een /24 CIDR-blok (10.3.1.0/24) biedt 256 IP-adressen, wat ruim voldoende is voor honderden Private Endpoints. Voor grotere organisaties met tientallen SQL-servers kan een /23 of groter subnet worden overwogen.

De subnetconfiguratie vereist specifieke instellingen voor Private Endpoints. De Private endpoint network policy moet worden ingesteld op DISABLED, wat een vereiste is voor het gebruik van Private Endpoints. Service endpoints zijn niet nodig omdat Private Endpoints deze functionaliteit volledig vervangen en een betere beveiligingsisolatie bieden. Subnet delegation moet worden ingesteld op NONE, omdat Private Endpoints geen specifieke service-delegatie vereisen.

Een belangrijke best practice is om dit subnet volledig te scheiden van andere workloads zoals virtuele machines of applicatie-services. Door een dedicated subnet te gebruiken voor database Private Endpoints, creëert u een duidelijke netwerksegmentatie die het mogelijk maakt om Network Security Groups toe te passen die specifiek zijn afgestemd op database-verkeer. Deze scheiding vergemakkelijkt ook het beheer en de monitoring van database-connectiviteit, omdat al het verkeer naar en van databases geïsoleerd is binnen dit subnet.

**FASE 2: Private Endpoint Aanmaken voor SQL Server**

De tweede fase omvat het daadwerkelijk aanmaken van de Private Endpoint-resource voor uw SQL Server. Deze fase duurt ongeveer 15 tot 20 minuten, waarbij de meeste tijd wordt besteed aan het zorgvuldig configureren van alle instellingen. Het is belangrijk om te begrijpen dat Private Endpoints worden geconfigureerd op het niveau van de SQL Server, niet op het niveau van individuele databases. Dit betekent dat één Private Endpoint alle databases op een specifieke SQL Server kan bedienen, wat de configuratie vereenvoudigt en de kosten beperkt.

Begin door in de Azure Portal te navigeren naar uw SQL Server-resource. Let op dat u de SQL Server selecteert, niet een individuele database, omdat Private Endpoints op server-niveau worden geconfigureerd. Ga naar het Networking-gedeelte van de SQL Server en selecteer Private endpoint connections. Klik op Add private endpoint om de wizard te starten die u door het configuratieproces leidt.

Op het Basics-tabblad moet u een naam opgeven voor de Private Endpoint. Gebruik een consistente naamgevingsconventie zoals 'pe-sqlserver-[servername]-prod' om duidelijk te maken dat dit een Private Endpoint is voor een specifieke SQL Server in de productieomgeving. Selecteer de resource group waarin de Private Endpoint moet worden aangemaakt. U kunt kiezen voor dezelfde resource group als de SQL Server, of een dedicated networking resource group gebruiken voor betere organisatie. De regio moet exact overeenkomen met zowel de regio van de SQL Server als de regio van het VNet uit Fase 1.

Op het Resource-tabblad wordt het resource type automatisch ingesteld op Microsoft.Sql/servers. Selecteer de specifieke SQL Server waarvoor u de Private Endpoint wilt aanmaken. Bij Target sub-resource moet u 'sqlServer' selecteren voor Azure SQL Database, of 'managedInstance' voor SQL Managed Instance. Deze keuze bepaalt welk type database-connectiviteit wordt geconfigureerd en is belangrijk voor de correcte werking van de Private Endpoint.

Het Virtual Network-tabblad is waar u de netwerkconfiguratie voltooit. Selecteer het VNet dat u in Fase 1 heeft voorbereid, en kies het dedicated subnet voor SQL Private Endpoints. Voor de Private IP-configuratie heeft u twee opties: Dynamic of Static. Dynamic is aanbevolen omdat Azure automatisch een beschikbaar IP-adres toewijst uit het subnetbereik, wat het beheer vereenvoudigt. Static configuratie geeft u volledige controle over het IP-adres, wat handig kan zijn voor specifieke netwerkvereisten of firewall-regels die op IP-adressen zijn gebaseerd.

Het DNS-tabblad bevat de meest kritieke configuratie-instellingen. U moet 'Integrate with private DNS zone' instellen op YES, omdat dit essentieel is voor de correcte naamresolutie. Zonder deze integratie zouden applicaties nog steeds proberen te verbinden via het publieke IP-adres. Selecteer de juiste subscription en resource group voor de Private DNS Zone. Azure suggereert automatisch de zone 'privatelink.database.windows.net', wat de standaardzone is voor SQL Database Private Endpoints. Accepteer deze suggestie, want Azure maakt de zone automatisch aan als deze nog niet bestaat, wat het configuratieproces vereenvoudigt.

Na het voltooien van alle tabbladen, controleert u de configuratie op het Review + Create-tabblad en start u de deployment. Het aanmaken van de Private Endpoint duurt ongeveer 5 tot 10 minuten. Tijdens dit proces creëert Azure verschillende resources: een Private Endpoint network interface met een private IP-adres binnen het opgegeven subnet, een DNS A-record in de Private DNS Zone die de SQL Server FQDN (bijvoorbeeld 'mijnserver.database.windows.net') mapt naar het private IP-adres, en een VNet-link voor de DNS Zone die ervoor zorgt dat resources binnen het VNet automatisch de Private DNS Zone gebruiken voor naamresolutie.

**FASE 3: DNS en Connectivity Testing**

De derde fase is gewijd aan uitgebreide testing van de DNS-resolutie en database-connectiviteit. Deze fase duurt ongeveer 30 minuten en is cruciaal om te verifiëren dat de Private Endpoint correct functioneert voordat publieke toegang wordt uitgeschakeld. Het overslaan van deze testfase kan leiden tot connectiviteitsproblemen die moeilijk op te lossen zijn nadat publieke toegang is uitgeschakeld.

Voor het testen heeft u een virtuele machine nodig binnen hetzelfde VNet als de Private Endpoint, of binnen een peered VNet. Als u al een bestaande VM heeft in het VNet, kunt u deze gebruiken. Anders moet u een test-VM deployen die specifiek is bedoeld voor deze validatie. De VM moet zich in hetzelfde VNet bevinden of toegang hebben via VNet-peering, omdat Private Endpoints alleen toegankelijk zijn vanuit resources binnen het gekoppelde VNet of peered VNets. Externe toegang vanaf het publieke internet is niet mogelijk, wat precies het beveiligingsdoel is van deze implementatie.

De eerste test richt zich op DNS-resolutie. Open PowerShell of Command Prompt op de test-VM en voer de opdracht 'nslookup [servername].database.windows.net' uit, waarbij u de daadwerkelijke naam van uw SQL Server gebruikt. Het verwachte resultaat is dat de DNS-query het private IP-adres retourneert (bijvoorbeeld 10.3.1.x), niet het publieke IP-adres. Als de query het publieke IP-adres retourneert, betekent dit dat de DNS-integratie niet correct werkt. In dat geval moet u controleren of de Private DNS Zone correct is gekoppeld aan het VNet via de VNet-link. Controleer ook of de DNS-zone de juiste A-record bevat die de SQL Server FQDN mapt naar het private IP-adres.

Na het verifiëren van de DNS-resolutie, moet u de daadwerkelijke SQL-connectiviteit testen. Installeer SQL Server Management Studio (SSMS) of Azure Data Studio op de test-VM. Maak verbinding met de SQL Server met behulp van een standaard connection string zoals 'Server=[servername].database.windows.net;Database=testdb;User Id=admin;Password=xxx;'. Het is belangrijk om de normale FQDN te gebruiken zonder wijzigingen aan de connection string, omdat de DNS-resolutie automatisch moet gebeuren via de Private DNS Zone. De verbinding moet succesvol zijn en het verkeer moet via het private IP-adres verlopen, niet via het publieke internet.

Om te verifiëren dat de verbinding daadwerkelijk via het private netwerk verloopt, kunt u in SSMS een query uitvoeren: 'SELECT CONNECTIONPROPERTY('client_net_address');'. Deze query toont het IP-adres van de client-VM, niet het Private Endpoint IP-adres zelf, maar bevestigt wel dat de communicatie plaatsvindt binnen het VNet. Als alles correct is geconfigureerd, ziet u het private IP-adres van de VM, wat bevestigt dat de communicatie volledig binnen het private netwerk plaatsvindt zonder blootstelling aan het publieke internet.

Voer als laatste stap een performance-test uit door enkele testqueries uit te voeren op de database. Private Endpoint-verbindingen hebben typisch een lagere latency dan publieke endpoints, omdat het verkeer wordt gerouteerd via Azure's private backbone-netwerk in plaats van via het publieke internet. Deze lagere latency is een extra voordeel naast de beveiligingsvoordelen. Meet de response times en vergelijk deze indien mogelijk met eerdere metingen van publieke endpoint-verbindingen om het prestatievoordeel te kwantificeren.

**FASE 4: Public Network Access Uitschakelen**

De vierde en meest kritieke fase is het uitschakelen van publieke netwerktoegang. Deze fase duurt ongeveer 10 minuten, maar vereist zorgvuldige voorbereiding en validatie. Het is van het grootste belang dat u deze stap pas uitvoert nadat de Private Endpoint volledig is geverifieerd en alle applicaties succesvol verbinding kunnen maken via de Private Endpoint. Het uitschakelen van publieke toegang voordat alle connectiviteit is gevalideerd, kan leiden tot productie-uitval waarbij applicaties niet langer toegang hebben tot de database.

Voordat u publieke toegang uitschakelt, moet u een volledige inventarisatie hebben gemaakt van alle applicaties, services en gebruikers die toegang hebben tot de database. Test elke applicatie individueel om te verifiëren dat deze succesvol kan verbinden via de Private Endpoint. Dit omvat niet alleen productie-applicaties, maar ook monitoring-tools, backup-services, development-omgevingen, en alle andere systemen die database-toegang vereisen. Documenteer alle testresultaten en zorg ervoor dat minimaal 95 procent van alle kritieke connectiviteit succesvol is voordat u doorgaat met het uitschakelen van publieke toegang.

Om publieke netwerktoegang uit te schakelen, navigeert u in de Azure Portal naar uw SQL Server, selecteert u Networking, en klikt u op Connectivity. Onder Public network access selecteert u 'Disabled'. Deze actie voorkomt dat nieuwe verbindingen kunnen worden gemaakt via het publieke endpoint, maar bestaande verbindingen kunnen nog enige tijd actief blijven. Het is daarom raadzaam om deze wijziging door te voeren tijdens een onderhoudsvenster of een periode met lage activiteit.

Als alternatief kunt u publieke toegang uitschakelen via PowerShell met de opdracht 'Update-AzSqlServer -ResourceGroupName 'rg-name' -ServerName 'server-name' -PublicNetworkAccess 'Disabled''. Deze methode is handig voor geautomatiseerde deployments of wanneer u meerdere SQL-servers tegelijkertijd wilt configureren. Zorg ervoor dat u de juiste resource group naam en server naam gebruikt, en dat u de juiste Azure-credentials hebt om deze wijziging door te voeren.

Na het uitschakelen van publieke toegang moet u de dual-mode isolatie valideren door twee kritieke tests uit te voeren. Ten eerste moet u testen vanaf een VM binnen het VNet: SQL-connectiviteit moet nog steeds perfect werken via de Private Endpoint. Ten tweede moet u testen vanaf een locatie op het publieke internet zonder VPN-verbinding: SQL-connectiviteit moet falen met een connection timeout error, wat bevestigt dat publieke toegang daadwerkelijk is uitgeschakeld. Deze validatie is essentieel om te verifiëren dat de beveiligingsisolatie correct functioneert.

Als laatste stap in deze fase moet u alle verouderde firewall-regels verwijderen. Navigeer naar Networking → Firewall rules en verwijder alle IP-gebaseerde firewall-regels. Deze regels hebben geen functie meer na het uitschakelen van publieke toegang, omdat er geen verkeer meer kan komen vanaf het publieke internet. Het behouden van deze regels kan verwarring veroorzaken tijdens audits en suggereert mogelijk dat publieke toegang nog steeds wordt gebruikt. Documenteer welke regels zijn verwijderd en wanneer, voor audit-doeleinden.

De totale implementatietijd voor deze maatregel bedraagt 3 tot 4 uur voor een ervaren Azure-beheerder. Deze tijd is verdeeld over de verschillende fasen: VNet-setup duurt ongeveer 30 minuten wanneer een nieuw VNet moet worden aangemaakt, of 10 minuten wanneer gebruik wordt gemaakt van een bestaand VNet. Het aanmaken van de Private Endpoint neemt ongeveer 20 minuten in beslag, waarbij de meeste tijd wordt besteed aan het zorgvuldig configureren van alle instellingen. DNS- en connectiviteitstests vereisen ongeveer 30 minuten, waarbij elke applicatie individueel moet worden getest. Het uitschakelen van publieke toegang en de bijbehorende validatie duurt ongeveer 10 minuten. De resterende tijd, ongeveer 1 tot 2 uur, wordt besteed aan uitgebreide validatie, het testen van alle applicaties, en het documenteren van de implementatie voor audit-doeleinden.

De kosten voor deze implementatie zijn relatief laag gezien de aanzienlijke beveiligings- en compliance-voordelen. Elke Private Endpoint kost €6 per maand per SQL Server, ongeacht het aantal databases op die server. Dit betekent dat één Private Endpoint alle databases op een specifieke SQL Server kan bedienen, wat de kosten per database aanzienlijk kan verlagen bij servers met meerdere databases. De Private DNS Zone kost €0,50 per maand en kan worden gedeeld over meerdere SQL Private Endpoints binnen dezelfde zone. De totale kosten per SQL Server bedragen dus ongeveer €6,50 per maand. Voor organisaties met tientallen SQL-servers kunnen deze kosten oplopen, maar dit moet worden afgewogen tegen de aanzienlijke beveiligingsvoordelen, compliance-naleving, en de vermindering van het aanvalsoppervlak met meer dan 99 procent.

Monitoring

Gebruik PowerShell-script sql-private-endpoints-configured.ps1 (functie Invoke-Monitoring) – Controleren.

Effectieve monitoring van Private Endpoints is essentieel om te verzekeren dat de beveiligingsisolatie blijft functioneren en om snel te kunnen reageren op eventuele problemen of beveiligingsregressies. Monitoring moet zowel de technische status van de Private Endpoint-resources omvatten als de daadwerkelijke connectiviteit en netwerkverkeer. Een uitgebreide monitoringstrategie helpt niet alleen bij het detecteren van problemen, maar biedt ook waardevolle informatie voor compliance-audits en beveiligingsbeoordelingen.

De primaire monitoring-indicator is de verbindingsstatus van de Private Endpoint, die moet worden ingesteld op 'Goedgekeurd'. Deze status geeft aan dat de Private Endpoint correct is gekoppeld aan de SQL Server en dat de netwerkverbinding actief is. Een status van 'In behandeling' of 'Afgewezen' wijst op een configuratieprobleem dat onmiddellijke aandacht vereist. Configureer Azure Monitor-waarschuwingen die een melding genereren wanneer de verbindingsstatus afwijkt van 'Goedgekeurd', zodat u direct wordt geïnformeerd over mogelijke problemen met de Private Endpoint-configuratie.

DNS-resolutie moet regelmatig worden getest om te verifiëren dat de Private DNS Zone correct functioneert en dat DNS-query's nog steeds worden omgezet naar het privé IP-adres in plaats van het publieke IP-adres. Voer maandelijks een DNS-resolutietest uit vanaf een VM binnen het VNet met behulp van de nslookup-opdracht. Het verwachte resultaat is dat de SQL Server FQDN wordt omgezet naar een privé IP-adres binnen het subnetbereik. Als de query het publieke IP-adres retourneert, wijst dit op een probleem met de Private DNS Zone-configuratie of de VNet-link, wat onmiddellijk moet worden onderzocht.

Network Security Group (NSG) flow logs bieden waardevolle inzichten in het netwerkverkeer naar en van de Private Endpoint. Configureer NSG flow logs voor het subnet dat de Private Endpoints bevat, zodat u kunt monitoren welke bronnen verbinding maken met de SQL Database via de Private Endpoint. Deze logs helpen bij het detecteren van ongebruikelijk verkeer, potentiële beveiligingsincidenten, en het valideren dat al het database-verkeer daadwerkelijk via de Private Endpoint verloopt en niet via een publiek endpoint. Analyseer deze logs regelmatig om patronen te identificeren en afwijkingen te detecteren.

Een kritieke monitoringwaarschuwing moet worden geconfigureerd voor het verwijderen van Private Endpoints. Het verwijderen van een Private Endpoint zonder eerst een nieuwe te configureren, of zonder publieke toegang opnieuw in te schakelen, kan leiden tot volledig verlies van databaseconnectiviteit voor alle applicaties. Configureer Azure Monitor-waarschuwingen die een melding genereren wanneer een Private Endpoint wordt verwijderd, zodat u onmiddellijk kunt reageren en de impact kunt beperken. Deze waarschuwing moet worden geclassificeerd als een kritieke beveiligingswaarschuwing, omdat het verwijderen van een Private Endpoint een beveiligingsregressie kan vertegenwoordigen waarbij de database mogelijk weer toegankelijk wordt via het publieke eindpunt als publieke toegang niet expliciet is uitgeschakeld.

Kwartaallijkse connectiviteitsvalidatie vormt een essentiële best practice die helpt bij het verifiëren dat de Private Endpoint-implementatie nog steeds correct functioneert en dat alle applicaties succesvol verbinding kunnen maken. Deze validatie moet uitgebreid worden uitgevoerd volgens een gestructureerde aanpak die alle kritieke componenten van de Private Endpoint-architectuur omvat. Het proces begint met het testen van DNS-resolutie vanaf meerdere virtuele machines binnen het VNet om te verifiëren dat de Private DNS Zone nog steeds correct functioneert en dat alle DNS-query's worden omgezet naar privé IP-adressen in plaats van publieke IP-adressen. Deze test moet worden uitgevoerd vanaf verschillende subnetten binnen het VNet om te waarborgen dat de DNS-integratie correct werkt voor alle netwerksegmenten.

Na het verifiëren van de DNS-resolutie moet SQL-connectiviteit worden geverifieerd vanaf verschillende applicaties en services om te waarborgen dat alle systemen nog steeds succesvol kunnen verbinden via de Private Endpoint. Deze test moet worden uitgevoerd voor alle kritieke productie-applicaties, monitoring-tools, backup-services, en development-omgevingen die toegang hebben tot de database. Elke applicatie moet individueel worden getest om te verifiëren dat de verbinding succesvol is en dat het verkeer daadwerkelijk via het private IP-adres verloopt. Het is belangrijk om zowel de verbindingssnelheid als de stabiliteit van de verbindingen te meten om eventuele prestatieproblemen te identificeren die kunnen wijzen op netwerkconfiguratieproblemen.

Het controleren van de Private Endpoint-status en configuratie is essentieel om te verifiëren dat er geen ongeautoriseerde wijzigingen zijn aangebracht die de beveiligingsisolatie kunnen compromitteren. Deze controle moet omvatten: het verifiëren dat de verbindingsstatus nog steeds is ingesteld op 'Goedgekeurd', het controleren dat het private IP-adres niet is gewijzigd zonder autorisatie, het valideren dat de Private Endpoint nog steeds is gekoppeld aan de juiste SQL Server en VNet, en het verifiëren dat de Private DNS Zone-configuratie ongewijzigd is. Elke afwijking van de verwachte configuratie moet onmiddellijk worden onderzocht en gecorrigeerd om te voorkomen dat de beveiligingsisolatie wordt gecompromitteerd.

Het valideren dat publieke toegang nog steeds is uitgeschakeld vormt een kritieke beveiligingscontrole die moet worden uitgevoerd tijdens elke validatie. Deze validatie moet worden uitgevoerd door te proberen verbinding te maken met de SQL Database vanaf een locatie op het publieke internet zonder VPN-verbinding. Deze verbindingspoging moet falen met een connection timeout error, wat bevestigt dat publieke toegang daadwerkelijk is uitgeschakeld en dat de database alleen toegankelijk is via de Private Endpoint. Als de verbinding succesvol is vanaf het publieke internet, wijst dit op een kritieke beveiligingsregressie die onmiddellijke aandacht vereist.

Het beoordelen van NSG flow logs voor afwijkingen helpt bij het detecteren van ongebruikelijk netwerkverkeer of potentiële beveiligingsincidenten. Deze analyse moet worden uitgevoerd door de flow logs te onderzoeken op ongebruikelijke verbindingspatronen, onverwachte bron-IP-adressen, of abnormale verkeersvolumes. Eventuele afwijkingen moeten worden onderzocht om te bepalen of deze wijzen op beveiligingsincidenten, configuratiefouten, of legitieme veranderingen in het gebruikspatroon. Deze analyse helpt niet alleen bij het detecteren van beveiligingsproblemen, maar biedt ook waardevolle inzichten voor het optimaliseren van de netwerkconfiguratie en het verbeteren van de beveiligingspostuur.

Documenteer de resultaten van deze validatie uitgebreid voor compliance-doeleinden en gebruik deze informatie om de monitoringstrategie continu te verbeteren en aan te passen aan veranderende beveiligingsvereisten. De documentatie moet omvatten: een overzicht van alle uitgevoerde tests, de resultaten van elke test, eventuele geïdentificeerde problemen en de genomen corrigerende maatregelen, en aanbevelingen voor verbeteringen aan de monitoringstrategie. Deze documentatie vormt een waardevolle bron voor compliance-audits en helpt bij het aantonen dat de Private Endpoint-implementatie regelmatig wordt geverifieerd en onderhouden. Gebruik de verzamelde informatie om trends te identificeren en proactief te reageren op veranderende beveiligingsvereisten en bedreigingen.

Compliance en Auditing

De implementatie van Private Endpoints voor Azure SQL Database draagt significant bij aan de naleving van verschillende beveiligings- en compliance-standaarden die relevant zijn voor Nederlandse overheidsorganisaties en bedrijven in gereguleerde sectoren. Deze maatregel adresseert specifieke vereisten voor netwerkisolatie, segmentatie en beveiliging die zijn opgenomen in internationale normen en Europese regelgeving. Een grondig begrip van de compliance-implicaties helpt bij het rechtvaardigen van de investering en het voorbereiden van audit-documentatie.

De CIS Azure Benchmark bevat specifieke aanbevelingen voor SQL-netwerkcontroles die de implementatie van Private Endpoints vereisen voor productie-databases. Deze benchmark wordt wereldwijd erkend als een best practice voor cloud-beveiliging en wordt vaak gebruikt als basis voor beveiligingsbeoordelingen. De implementatie van Private Endpoints voldoet aan de CIS-aanbevelingen voor het beperken van database-toegang tot private netwerken en het elimineren van onnodige blootstelling aan het publieke internet. Tijdens audits kan worden aangetoond dat de database-toegang is beperkt tot geautoriseerde netwerken via Private Endpoints, wat voldoet aan de CIS-vereisten voor netwerksegmentatie.

Zero Trust Architecture-principes vereisen netwerkisolatie als een fundamenteel onderdeel van de beveiligingsstrategie. Private Endpoints implementeren het Zero Trust-principe van 'never trust, always verify' door database-toegang volledig te isoleren binnen private netwerken, waarbij standaard alle publieke toegang wordt geweigerd. Deze architectuur maakt het mogelijk om micro-segmentation te implementeren waarbij database-verkeer kan worden gecontroleerd en gemonitord op subnet-niveau. Zero Trust-architecturen vereisen dat alle resources worden behandeld als onbetrouwbaar totdat hun identiteit en autorisatie zijn geverifieerd, en Private Endpoints zorgen ervoor dat deze verificatie alleen kan plaatsvinden vanuit geautoriseerde netwerklocaties.

ISO 27001:2022 bevat specifieke controles voor netwerkbeveiliging, waaronder controle A.13.1.1 die betrekking heeft op netwerkcontroles en -beveiliging. Deze controle vereist dat organisaties netwerkbeveiligingsmaatregelen implementeren om netwerkdiensten te beschermen tegen onbevoegde toegang en om netwerkverkeer te controleren. Private Endpoints voldoen aan deze vereisten door database-toegang te beperken tot private netwerken en door het mogelijk te maken om Network Security Groups toe te passen voor granulaire verkeersfiltering. Tijdens ISO 27001-audits kan worden aangetoond dat database-toegang is geïsoleerd binnen private netwerken en dat netwerkverkeer wordt gemonitord en gecontroleerd via NSG flow logs.

De NIS2-richtlijn (Network and Information Systems Directive 2) bevat specifieke vereisten voor netwerksegmentatie in Artikel 21. Deze richtlijn is van toepassing op essentiële en belangrijke entiteiten in verschillende sectoren, waaronder de financiële sector, energie, transport, en digitale infrastructuur. Artikel 21 vereist dat organisaties netwerksegmentatie implementeren om kritieke systemen te isoleren en te beschermen tegen netwerkbedreigingen. Private Endpoints voor Azure SQL Database voldoen aan deze vereisten door database-toegang volledig te isoleren binnen private netwerken, waardoor kritieke databases worden beschermd tegen netwerkbedreigingen vanaf het publieke internet. Voor Nederlandse organisaties die onder de NIS2-richtlijn vallen, is de implementatie van Private Endpoints voor productie-databases met gevoelige data een verplichte maatregel.

De Baseline Informatiebeveiliging Overheid (BIO) bevat specifieke thema's voor netwerkbeveiliging, waaronder thema 13.01.01 dat betrekking heeft op netwerkbeveiliging en segmentatie. Dit thema vereist dat overheidsorganisaties netwerksegmentatie implementeren om verschillende netwerkzones te creëren en om gevoelige systemen te isoleren. Private Endpoints implementeren deze segmentatie door database-toegang te beperken tot specifieke netwerkzones (VNets) en door het mogelijk te maken om verschillende beveiligingsniveaus toe te passen op verschillende netwerksegmenten. Voor Nederlandse overheidsorganisaties is de implementatie van Private Endpoints voor databases met persoonsgegevens of andere gevoelige informatie een best practice die voldoet aan de BIO-vereisten voor netwerksegmentatie en -isolatie.

Remediatie

Gebruik PowerShell-script sql-private-endpoints-configured.ps1 (functie Invoke-Remediation) – Herstellen.

Wanneer een Azure SQL Database nog geen Private Endpoint heeft geconfigureerd, vormt dit een kritieke beveiligingsrisico dat onmiddellijke remediatie vereist. De remediatieprocedure omvat het volledige implementatieproces van Private Endpoints, waarbij alle stappen uit de implementatiesectie moeten worden doorlopen. Het is van cruciaal belang dat deze remediatie wordt uitgevoerd volgens een gestructureerde aanpak om te voorkomen dat bestaande applicaties en services worden verstoord tijdens de migratie van publieke naar private netwerktoegang.

De eerste stap in het remediatieproces is het uitvoeren van een volledige impactanalyse. Deze analyse moet alle applicaties, services en gebruikers identificeren die momenteel toegang hebben tot de SQL Database via het publieke endpoint. Documenteer voor elke applicatie de verbindingsmethode, de gebruikte connection strings, en de kritiekheid van de applicatie voor de bedrijfsvoering. Deze informatie is essentieel voor het plannen van de migratie en het bepalen van de volgorde waarin applicaties worden getest na de implementatie van de Private Endpoint. Voor kritieke productie-applicaties is het raadzaam om een uitgebreide testperiode in te plannen voordat publieke toegang wordt uitgeschakeld.

Voordat de Private Endpoint wordt geconfigureerd, moet de netwerkinfrastructuur worden voorbereid. Als er nog geen Azure Virtual Network beschikbaar is met een dedicated subnet voor Private Endpoints, moet deze eerst worden aangemaakt. Het subnet moet voldoende IP-adresruimte bevatten voor de Private Endpoint en eventuele toekomstige uitbreidingen. Voor organisaties met meerdere SQL-servers die nog moeten worden gemigreerd, is het verstandig om een subnet te kiezen dat groot genoeg is om alle benodigde Private Endpoints te accommoderen. Een /24 subnet biedt ruimte voor 256 IP-adressen, wat voldoende is voor de meeste organisaties, maar grotere implementaties kunnen een /23 of groter subnet vereisen.

De Private DNS Zone moet worden geconfigureerd voordat de Private Endpoint wordt aangemaakt. Als deze zone nog niet bestaat, moet deze worden aangemaakt met de naam 'privatelink.database.windows.net'. Deze zone moet worden gekoppeld aan het VNet via een VNet-link, zodat resources binnen het VNet automatisch de Private DNS Zone gebruiken voor naamresolutie. Zonder deze DNS-configuratie zouden applicaties nog steeds proberen te verbinden via het publieke IP-adres, wat de beveiligingsvoordelen van de Private Endpoint volledig teniet zou doen. Het is daarom essentieel dat de DNS-configuratie correct is voordat de Private Endpoint wordt geactiveerd.

Tijdens het aanmaken van de Private Endpoint moet zorgvuldig worden gelet op de configuratie-instellingen. De Private Endpoint moet worden gekoppeld aan de juiste SQL Server, waarbij de target sub-resource correct wordt ingesteld op 'sqlServer' voor Azure SQL Database of 'managedInstance' voor SQL Managed Instance. Het subnet dat wordt geselecteerd moet het dedicated subnet zijn dat specifiek is gereserveerd voor database Private Endpoints. De Private IP-configuratie kan worden ingesteld op Dynamic voor automatische toewijzing, of Static voor volledige controle over het IP-adres. Voor de meeste scenario's is Dynamic aanbevolen omdat dit het beheer vereenvoudigt en de kans op configuratiefouten verkleint.

Na het aanmaken van de Private Endpoint moet uitgebreide connectiviteitstesting worden uitgevoerd voordat publieke toegang wordt uitgeschakeld. Deze testing moet worden uitgevoerd vanaf een virtuele machine binnen het VNet om te verifiëren dat DNS-resolutie correct werkt en dat SQL-connectiviteit succesvol is via het private IP-adres. Test alle kritieke applicaties individueel om te verzekeren dat ze kunnen verbinden via de Private Endpoint. Documenteer alle testresultaten en los eventuele problemen op voordat u doorgaat met het uitschakelen van publieke toegang. Het is raadzaam om minimaal 24 uur te wachten na de implementatie van de Private Endpoint voordat publieke toegang wordt uitgeschakeld, zodat alle applicaties de kans krijgen om via de Private Endpoint te verbinden en eventuele DNS-caching kan worden vernieuwd.

Het uitschakelen van publieke netwerktoegang is de laatste en meest kritieke stap in het remediatieproces. Deze stap moet alleen worden uitgevoerd nadat alle connectiviteitstests succesvol zijn voltooid en alle kritieke applicaties hebben bewezen dat ze kunnen werken via de Private Endpoint. Het uitschakelen van publieke toegang kan worden gedaan via de Azure Portal door naar de SQL Server te navigeren, Networking te selecteren, en Public network access in te stellen op Disabled. Als alternatief kan dit worden gedaan via PowerShell met de Update-AzSqlServer cmdlet. Na het uitschakelen van publieke toegang moeten alle IP-gebaseerde firewall-regels worden verwijderd, omdat deze niet langer nodig zijn en verwarring kunnen veroorzaken tijdens audits.

Na voltooiing van de remediatie moet een post-implementatie validatie worden uitgevoerd om te verifiëren dat de beveiligingsisolatie correct functioneert. Deze validatie moet omvatten: het testen van connectiviteit vanaf een VM binnen het VNet (moet succesvol zijn), het testen van connectiviteit vanaf het publieke internet zonder VPN (moet falen met een timeout), het verifiëren dat DNS-resolutie het private IP-adres retourneert, en het controleren dat alle applicaties nog steeds correct functioneren. Documenteer alle validatieresultaten voor audit-doeleinden en gebruik deze informatie om de monitoringstrategie te verbeteren. De totale remediatietijd bedraagt 3 tot 4 uur voor een ervaren Azure-beheerder, waarbij de meeste tijd wordt besteed aan testing en validatie om te verzekeren dat geen applicaties worden verstoord tijdens de migratie.

Compliance & Frameworks

• CIS M365: Control SQL Network (L2) - Private connectivity voor Azure SQL Databases
• BIO: 13.01.01 - Netwerkbeveiliging - Private connectivity
• ISO 27001:2022: A.13.1.1 - netwerkcontroles - Segregatie
• 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

Private Endpoints voor Azure SQL Database elimineren publieke internetblootstelling door databases binnen Azure Virtual Networks te plaatsen met private IP-adressen, wat uitsluitend VNet-toegang mogelijk maakt zonder internet-bereikbaarheid. Implementatie creëert Private Endpoint-resources die SQL Server koppelen aan VNet-subnets waarbij DNS-integratie via Private DNS Zone (privatelink.database.windows.net) ervoor zorgt dat clients binnen VNet de SQL Server omzetten naar private IP (10.x.x.x) in plaats van publiek eindpunt. Network Security Groups op Private Endpoint-subnets bieden granulaire verkeersfiltering. Kritieke architectuurwijziging: schakel publieke netwerktoegang uit na Private Endpoint-implementatie (publicNetworkAccess=Disabled) om dual-mode toegang te voorkomen waarbij database zowel via private als public eindpunt bereikbaar zou blijven - publieke uitschakeling is verplicht voor echte isolatie. Na implementatie elimineer alle IP-gebaseerde firewall-regels (verouderd na VNet-only architectuur). Toepassingsscenario's: productie-databases met persoonsgegevens, financiële data of vertrouwelijke bedrijfsinformatie, multi-tier applicaties waar alleen backend-services database-toegang vereisen, compliance-workloads onder NIS2/BIO waar netwerkisolatie verplicht is, Zero Trust-architecturen met standaard weigeren netwerkbeleid en microsegmentatie. Deze maatregel is verplicht voor ALLE productie Azure SQL Databases met gevoelige data, verplicht voor NIS2 Artikel 21 en ISO 27001 A.13.1.1 compliance, essentieel voor Zero Trust netwerkarchitecturen, en wordt beschouwd als kritieke beveiligingscontrole voor databases in gereguleerde sectoren (financiën, gezondheidszorg, overheid). Belangrijke vereiste: applicaties MOETEN in VNet zijn geïmplementeerd of toegang hebben via ExpressRoute/VPN - externe internetgebaseerde applicaties kunnen NIET meer verbinden (dit is bewust ontworpen). Implementatie-inspanning: 3-4 uur per SQL Server (VNet-setup indien nieuw, Private Endpoint-aanmaak, Private DNS-configuratie, connectiviteitstesten, publieke toegang uitschakelen, firewall-opruiming). Kosten: €6 per maand per Private Endpoint, Private DNS Zone €0,50 per maand (gedeeld over databases). Rendement op investering komt van: 99 procent aanvalsoppervlak-reductie, geëlimineerde brute force-risico's (meer dan 3000 dagelijkse pogingen geblokkeerd), compliance-succes NIS2/ISO 27001, Zero Trust-bereiking, voorkomen van data-exfiltratie via netwerkisolatie.

• Implementatietijd: 4 uur
• FTE required: 0.05 FTE