💼 Management Samenvatting
Private Endpoints voor Azure App Service brengen web-applicaties binnen een Virtual Network (VNet) met private IP-adressen, waardoor publieke internet exposure wordt geëlimineerd voor interne applicaties. Deze netwerkisolatie is essentieel voor applicaties die alleen toegankelijk mogen zijn binnen het bedrijfsnetwerk of voor specifieke geautoriseerde netwerken.
Standaard zijn Azure App Services toegankelijk via publieke internet endpoints met een {appname}.azurewebsites.net URL die wereldwijd bereikbaar is. Voor interne bedrijfsapplicaties, employee portals, backend APIs en andere non-public-facing applicaties creëert deze publieke exposure onnodig aanvalsoppervlak en potentiële security risico's. Zelfs met authenticatie ingeschakeld blijft de applicatie technisch beschikbaar op internet, wat DDoS-aanvallen, poort-scanning en brute-force-aanvallen mogelijk maakt. Private Endpoints lossen dit op door de App Service binnen een klant-VNet te plaatsen met een private IP-adres uit het VNet-adresbereik, waardoor toegang alleen mogelijk is vanuit het VNet of verbonden netwerken zoals on-premises datacenters via ExpressRoute of VPN, Network Security Group (NSG) regels kunnen worden toegepast voor granulaire toegangscontrole, publieke DNS-resolution wordt vervangen door Private DNS waardoor de applicatie niet meer publiek vindbaar is, en het ideaal wordt voor interne APIs, employee portals, admin interfaces en backend services die geen publieke toegang vereisen. Dit past perfect binnen Zero Trust-architecturen waarbij network segmentation een kernprincipe is. Belangrijke consideraties zijn dat Private Endpoints alleen beschikbaar zijn voor App Services op Premium v2/v3 tier of Isolated tier (App Service Environment), en dat deze feature niet bedoeld is voor public-facing applicaties die internet-toegankelijkheid vereisen - daarvoor is Azure Application Gateway met Web Application Firewall (WAF) de juiste oplossing.
Connection:
Connect-AzAccountRequired Modules: Az.Websites, Az.Network
Implementatie
Deze maatregel implementeert Private Endpoints voor Azure App Services die uitsluitend interne toegang vereisen. De implementatie begint met een upgrade naar Premium v2 of v3 tier (vereist voor Private Endpoint-ondersteuning, met kosten vanaf €150 per maand afhankelijk van de tier en instance size). Vervolgens wordt een Private Endpoint aangemaakt die de App Service koppelt aan een subnet binnen een bestaand Virtual Network. Deze Private Endpoint krijgt een private IP-adres uit het subnet-bereik dat als enig toegangspunt fungeert voor de applicatie. Een Private DNS Zone moet worden geconfigureerd (bijvoorbeeld privatelink.azurewebsites.net) die DNS-queries van binnen het VNet resolved naar het private IP-adres in plaats van het publieke endpoint. Cruciaal is dat publicNetworkAccess wordt ingesteld op 'Disabled', wat het publieke internet endpoint volledig uitschakelt en ervoor zorgt dat de applicatie uitsluitend via het Private Endpoint bereikbaar is. Na implementatie moet de VNet-only connectivity worden getest door toegang te proberen vanaf een VM binnen het VNet (moet werken) en vanaf public internet (moet falen). Network Security Groups kunnen worden geconfigureerd op het subnet voor aanvullende toegangscontrole, bijvoorbeeld om alleen specifieke source IP-ranges toe te staan. De kosten zijn ongeveer €6 per Private Endpoint per maand bovenop de Premium tier-kosten. Veelvoorkomende use cases zijn interne business APIs die alleen door andere Azure-resources of on-premises systemen mogen worden aangeroepen, employee portals die alleen toegankelijk moeten zijn via het bedrijfsnetwerk, admin interfaces en configuration portals die extra netwerkisolatie vereisen, en backend services die deel uitmaken van multi-tier applicaties waarbij alleen de frontend publiek toegankelijk is. Deze maatregel is vooral relevant voor organisaties in gereguleerde sectoren of met strikte compliance-eisen rond netwerk-segmentatie.
Implementatie
De implementatie van Private Endpoints voor Azure App Service vereist een systematische aanpak die bestaat uit vijf kritieke fases. Voordat de implementatie begint, is het essentieel om te begrijpen dat Private Endpoints uitsluitend beschikbaar zijn op App Service Premium v2, Premium v3 of Isolated tier. Basic en Standard tiers ondersteunen Private Endpoints niet, wat betekent dat een tier upgrade vereist is indien de applicatie momenteel op een lagere service tier draait. Deze upgrade heeft significante kostenimplicaties: een tier upgrade van Standard naar Premium v2 verhoogt de maandelijkse kosten van €60 naar minimaal €150 per maand, afhankelijk van de gekozen instance size en regio. Budgetgoedkeuring is daarom absoluut noodzakelijk voordat met de implementatie wordt begonnen, omdat tier downgrades niet mogelijk zijn zonder volledige App Service re-creatie na de upgrade.
De eerste fase van de implementatie betreft het upgraden van de App Service tier indien nodig, een proces dat typisch dertig minuten in beslag neemt inclusief downtime-planning en validatie. Het proces begint met het controleren van de huidige tier-configuratie via Azure Portal door naar de App Service te navigeren, het Overview-paneel te openen en de Pricing tier te inspecteren. Als de applicatie momenteel op Basic of Standard tier draait, is een upgrade vereist voordat Private Endpoints kunnen worden geconfigureerd. Het plannen van het juiste upgrade-tijdstip is cruciaal omdat tier-wijzigingen een korte applicatie-restart veroorzaken die typisch tussen de dertig en zestig seconden downtime veroorzaakt. Deze upgrade moet worden gepland tijdens een onderhoudsvenster om impact op gebruikers te minimaliseren. De daadwerkelijke upgrade wordt uitgevoerd via de Scale up functionaliteit binnen het App Service plan, waarbij de Production tier wordt geselecteerd. De minimum configuratie voor Private Endpoint-ondersteuning is Premium v2 P1v2, die beschikbaar is vanaf €150 per maand met één processor core en 3.5GB RAM. Alternatief kan worden gekozen voor Premium v3 P1v3 tegen €180 per maand, wat twee processor cores, 4GB RAM en nieuwere hardware biedt. Na de upgrade vindt automatisch een applicatie-restart plaats en moet worden gevalideerd dat de applicatie correct opstart na de tier-wijziging. Een kritieke overweging is dat tier downgrades niet mogelijk zijn na de upgrade zonder volledige App Service re-creatie, daarom wordt sterk aanbevolen om de Private Endpoint-functionaliteit eerst te testen in een development omgeving voordat de productieomgeving wordt geüpgraded.
De tweede fase omvat het voorbereiden van het Virtual Network en subnet, een proces dat dertig minuten in beslag neemt voor een nieuw VNet en ongeveer tien minuten voor een bestaand VNet. Indien er nog geen Virtual Network beschikbaar is, moet dit eerst worden aangemaakt via Azure Portal door naar Virtual Networks te navigeren en Create te selecteren. Een aanbevolen naamgeving is 'vnet-internal-apps' met een address space van 10.1.0.0/16, wat ongeveer 65.000 IP-adressen biedt voor toekomstige uitbreidingen. Het is van kritiek belang dat de regio exact matcht met de regio waarin de App Service zich bevindt, omdat Private Endpoints regionale resources zijn en geen cross-regional connectivity ondersteunen. Binnen het Virtual Network moet een dedicated subnet worden gecreëerd specifiek voor Private Endpoints door naar Subnets te navigeren en Add subnet te selecteren. Een aanbevolen naam is 'snet-private-endpoints' met een address range van 10.1.1.0/24, wat 256 IP-adressen biedt en meer dan voldoende is voor honderden Private Endpoints. De subnet configuratie vereist specifieke instellingen: Private endpoint network policy moet zijn ingesteld op DISABLED (dit is de standaardwaarde en vereist voor Private Endpoints), Service endpoints moeten zijn ingesteld op NONE omdat deze niet nodig zijn voor Private Endpoints, en Subnet delegation moet NONE zijn. Een best practice is om een dedicated subnet uitsluitend te gebruiken voor Private Endpoints zonder deze te mixen met virtuele machines of andere resources, omdat dit het Network Security Group management vereenvoudigt en troubleshooting aanzienlijk vergemakkelijkt. Ten slotte moet de subnet Resource ID worden genoteerd voor gebruik tijdens de Private Endpoint-creatie, waarbij het formaat volgt: /subscriptions/{sub-id}/resourceGroups/{rg}/providers/Microsoft.Network/virtualNetworks/{vnet}/subnets/{subnet}.
De derde fase betreft het daadwerkelijk aanmaken en koppelen van de Private Endpoint aan de App Service, een proces dat ongeveer vijftien minuten in beslag neemt. Het proces wordt gestart via Azure Portal door naar de App Service te navigeren, het Networking-paneel te openen, Private endpoints te selecteren en Add private endpoint te kiezen. Op het Basics-tabblad wordt een beschrijvende naam opgegeven zoals 'pe-[appname]-internal' om de Private Endpoint duidelijk te identificeren. De resource group kan worden gekozen als dezelfde resource group waarin de App Service zich bevindt, of een dedicated networking resource group voor betere organisatie. Opnieuw is het essentieel dat de regio exact matcht met zowel de App Service als het Virtual Network regio. Op het Resource-tabblad wordt de resource type automatisch ingesteld op Microsoft.Web/sites, waarna de betreffende App Service wordt geselecteerd uit de dropdown. De target sub-resource wordt ingesteld op 'sites' voor een standaard App Service web app, of 'sites-[slot]' indien deployment slots worden gebruikt voor staging omgevingen. Op het Virtual Network-tabblad wordt het VNet geselecteerd dat in fase twee is voorbereid, gevolgd door het Private Endpoint subnet. Voor de Private IP-configuratie wordt Dynamic aanbevolen omdat Azure dan automatisch een beschikbaar IP-adres toewijst uit het subnet-bereik, hoewel Static kan worden gekozen indien een specifiek IP-adres vereist is binnen het subnet-bereik. Het DNS-tabblad biedt de optie om te integreren met een private DNS zone, wat sterk wordt aanbevolen voor automatische DNS-integratie. Azure suggereert automatisch de Private DNS zone 'privatelink.azurewebsites.net', wat moet worden geaccepteerd. Na het selecteren van de subscription en resource group wordt op Review + Create geklikt, waarbij de configuratie wordt gevalideerd voordat Create wordt geselecteerd. De deployment duurt typisch tussen de twee en vijf minuten, waarbij Azure automatisch de volgende resources creëert: een Private Endpoint netwerkinterface met een private IP-adres, een DNS A-record in de Private DNS Zone die de App Service hostname mapt naar het private IP-adres, en een VNet link voor de DNS Zone die ervoor zorgt dat DNS-queries vanuit het VNet automatisch worden doorgestuurd naar de Private DNS Zone.
De vierde fase is kritiek en betreft het uitschakelen van publieke netwerktoegang, een stap die vaak wordt overgeslagen maar essentieel is voor volledige netwerkisolatie. Zonder deze stap blijft de applicatie zowel via het Private Endpoint als via het publieke endpoint bereikbaar, wat betekent dat de Private Endpoint configuratie alleen onvoldoende is voor volledige isolatie. Het publieke internet endpoint blijft actief tenzij expliciet wordt uitgeschakeld, waardoor de beoogde security voordelen niet worden bereikt. Het uitschakelen van publieke toegang wordt uitgevoerd via Azure Portal door naar de App Service te navigeren, het Networking-paneel te openen, Public network access te selecteren en Disabled te kiezen. Alternatief kan deze instelling worden geconfigureerd via PowerShell met de cmdlet Set-AzWebApp, waarbij de parameter PublicNetworkAccess wordt ingesteld op Disabled. Deze PowerShell-methode wordt aanbevolen voor consistency in geautomatiseerde deployments en infrastructure-as-code scenario's. Na het uitschakelen van publieke toegang moet worden gevalideerd dat de applicatie niet meer bereikbaar is via het publieke internet door een poging te doen om toegang te verkrijgen tot de applicatie via de publieke URL (https://[appname].azurewebsites.net) vanaf een internetverbinding buiten het VNet. Deze poging moet falen met een connection timeout of Access Denied error. Een belangrijke waarschuwing is dat na het uitschakelen van publieke toegang bepaalde Azure Portal features mogelijk niet meer werken, waaronder Log Stream, Console en de Kudu debug console, omdat deze features ook via het publieke endpoint functioneren. Toegang tot deze features vereist nu een VPN-verbinding naar het VNet of het gebruik van Azure Bastion voor veilige remote access tot Azure-resources.
De vijfde en laatste fase omvat uitgebreide connectiviteitstests en troubleshooting om ervoor te zorgen dat de Private Endpoint configuratie correct functioneert en dat de applicatie uitsluitend bereikbaar is via het private netwerk. De testfase duurt typisch dertig minuten en omvat zowel positieve als negatieve testscenario's. De eerste test wordt uitgevoerd vanuit het VNet zelf door een test virtuele machine te deployen in hetzelfde VNet of een peered VNet. Vanaf deze test-VM wordt een browser geopend en wordt genavigeerd naar https://[appname].azurewebsites.net, wat moet werken en moet resolven naar het private IP-adres uit het subnet-bereik (bijvoorbeeld 10.1.1.x). Een tweede kritieke test betreft de verificatie van DNS-resolution door vanaf de test-VM de opdracht nslookup [appname].azurewebsites.net uit te voeren. Het resultaat moet het private IP-adres tonen en niet het publieke IP-adres. Indien het publieke IP-adres wordt getoond, is de DNS-configuratie niet correct en moet worden gecontroleerd of de Private DNS Zone VNet link bestaat en correct is geconfigureerd. Voor organisaties met on-premises datacenters die zijn verbonden via ExpressRoute of VPN moet worden getest of toegang vanaf corporate workstations via VPN correct werkt. Deze test verifieert dat de on-premises connectiviteit naar het VNet correct is geconfigureerd en dat routing, Network Security Group rules en Private DNS forwarding allemaal correct functioneren. Een negatieve test is even belangrijk: toegang tot de applicatie vanaf een persoonlijk device zonder VPN-verbinding moet falen, wat bevestigt dat publieke internet-toegang correct is geblokkeerd. Indien de applicatie nog steeds bereikbaar is vanaf publiek internet, is de public network access instelling niet correct uitgeschakeld en moet deze opnieuw worden gecontroleerd. Voor connectiviteitsproblemen dient een troubleshooting checklist te worden doorlopen die controleert of de Private DNS Zone VNet link bestaat en actief is, of Network Security Groups op het Private Endpoint subnet geen blokkerende regels bevatten, of de App Service publicNetworkAccess instelling correct is ingesteld op Disabled, en of client DNS correct is geconfigureerd om de Private DNS Zone te gebruiken, wat automatisch gebeurt voor Azure virtuele machines maar handmatig moet worden geconfigureerd voor on-premises systemen via DNS forwarders of conditional forwarding.
De totale implementatietijd voor het volledige proces bedraagt drie tot vier uur wanneer inclusief tier upgrade (indien nodig), VNet setup (indien nieuw), Private Endpoint creation, DNS-configuratie, testing en troubleshooting. Voor organisaties met een bestaand VNet en App Services die al op Premium tier draaien, kan de implementatietijd worden teruggebracht naar één tot twee uur. De kostenstructuur omvat de Premium v2 P1v2 tier vanaf €150 per maand als minimum vereiste voor Private Endpoints, een Private Endpoint kost €6 per maand per endpoint, en een Private DNS Zone kost €0,50 per maand per zone waarbij de kosten worden gedeeld over alle Private Endpoints binnen die zone. Het Virtual Network zelf is gratis, wat resulteert in een totaalbedrag van €156 tot €180 per maand voor een basis Private Endpoint setup, afhankelijk van de gekozen Premium tier en instance size. Deze investering wordt gerechtvaardigd door de significante beveiligingsverbeteringen, compliance-voordelen en verminderde aanvalsoppervlakte voor interne applicaties die geen publieke internettoegang vereisen.
Notitie
Private Endpoints vereisen App Service Premium v2 of v3 tier, of Isolated tier. Voor publieke applicaties die internettoegankelijk moeten zijn, gebruik Azure Application Gateway met Web Application Firewall (WAF) in plaats van Private Endpoints. Private Endpoints zijn uitsluitend bedoeld voor interne applicaties die geen publieke toegang vereisen.
Compliance en Auditing
De implementatie van Private Endpoints voor Azure App Service draagt substantieel bij aan compliance met verschillende nationale en internationale beveiligingsstandaarden die van toepassing zijn op Nederlandse overheidsorganisaties en bedrijven in gereguleerde sectoren. Deze maatregel is met name relevant voor de Baseline Informatiebeveiliging Overheid (BIO), de ISO 27001 informatiebeveiligingsstandaard, het Center for Internet Security (CIS) Azure Foundations Benchmark, en moderne Zero Trust-architecturen die network segmentation als fundamenteel principe hanteren. Het begrijpen van de compliance-implicaties en audit-vereisten is essentieel voor organisaties die moeten voldoen aan strikte beveiligings- en privacy-eisen, vooral in sectoren zoals financiën, gezondheidszorg, energie en publieke sector waar netwerkisolatie vaak een verplicht onderdeel is van compliance-frameworks.
De Baseline Informatiebeveiliging Overheid (BIO) controle 13.01.01 vereist specifiek dat organisaties adequate netwerkbeveiliging implementeren waarbij interne systemen zijn gescheiden van publieke netwerken. Private Endpoints zijn een directe implementatie van deze vereiste omdat ze ervoor zorgen dat interne applicaties niet langer toegankelijk zijn via publieke internet endpoints, wat netwerk-segmentatie realiseert op een manier die perfect past binnen de BIO-richtlijnen. Voor Nederlandse overheidsorganisaties die moeten voldoen aan BIO is de implementatie van Private Endpoints voor interne applicaties niet alleen best practice, maar vaak een compliance-vereiste voor applicaties die gevoelige of vertrouwelijke informatie verwerken. Tijdens audits wordt verwacht dat organisaties kunnen aantonen dat interne systemen adequaat zijn beschermd tegen publieke internet exposure, en Private Endpoint-configuraties dienen als concrete audit evidence dat deze netwerkisolatie is geïmplementeerd. De BIO-controle vereist ook dat organisaties regelmatig monitoren en controleren of netwerkconfiguraties correct blijven geconfigureerd, wat betekent dat Private Endpoint-configuraties regelmatig moeten worden gecontroleerd om ervoor te zorgen dat public network access daadwerkelijk is uitgeschakeld en dat Private Endpoints correct zijn geconfigureerd.
De ISO 27001 informatiebeveiligingsstandaard, met name controle A.13.1.1 (Network segregation), mandateert dat organisaties netwerk-segmentatie implementeren waarbij verschillende netwerkgebieden worden gescheiden op basis van beveiligingsvereisten. Private Endpoints voor Azure App Service zijn een concrete implementatie van deze vereiste omdat ze een duidelijke scheiding creëren tussen publieke en private netwerken, waarbij interne applicaties uitsluitend toegankelijk zijn binnen gecontroleerde private netwerken. Voor organisaties die ISO 27001-certificering nastreven of onderhouden, is de implementatie van Private Endpoints voor interne applicaties een belangrijk onderdeel van de informatiebeveiligingsmanagementsystemen (ISMS) omdat het aantoont dat de organisatie actief werkt aan het verminderen van netwerkrisico's door middel van technische controles. Tijdens ISO 27001-audits wordt verwacht dat organisaties documentatie kunnen overleggen die aantoont hoe netwerk-segmentatie is geïmplementeerd, en Private Endpoint-configuraties vormen concrete technische bewijslast dat deze controles operationeel zijn. De standaard vereist ook dat organisaties risico-assessments uitvoeren voor netwerkconfiguraties en dat mitigatiemaatregelen worden geïmplementeerd voor geïdentificeerde risico's, waarbij Private Endpoints een directe mitigatie vormen voor het risico van onnodige publieke internet exposure van interne applicaties.
Het Center for Internet Security (CIS) Azure Foundations Benchmark bevat specifieke netwerkcontroles die relevant zijn voor de implementatie van Private Endpoints. Hoewel de CIS Benchmark primair gericht is op algemene Azure-netwerkbeveiliging, ondersteunt de implementatie van Private Endpoints de onderliggende principes van network segmentation en defense-in-depth die centraal staan in de CIS-controles. De CIS Benchmark benadrukt het belang van het minimaliseren van publieke internet exposure voor resources die geen publieke toegang vereisen, en Private Endpoints zijn een directe implementatie van dit principe voor Azure App Services. Voor organisaties die de CIS Azure Foundations Benchmark volgen, draagt de implementatie van Private Endpoints bij aan de algehele security posture en helpt het bij het bereiken van compliance met de network security-aanbevelingen die in de benchmark zijn opgenomen. Het is belangrijk op te merken dat de CIS Benchmark een raamwerk biedt voor best practices en dat organisaties hun implementatie moeten afstemmen op hun specifieke security-vereisten en compliance-obligaties, waarbij Private Endpoints een waardevolle toevoeging zijn aan een algehele beveiligingsstrategie.
Zero Trust-architecturen zijn gebaseerd op het principe dat organisaties nooit impliciet moeten vertrouwen op netwerklocatie of netwerksegmentatie als primaire beveiligingscontrole, maar tegelijkertijd erkennen moderne Zero Trust-implementaties het belang van network segmentation als een laag in een defense-in-depth strategie. Private Endpoints passen perfect binnen Zero Trust-architecturen omdat ze netwerk-segmentatie bieden zonder te vertrouwen op perimeter-gebaseerde beveiliging als enige controle. In een Zero Trust-model worden applicaties geïsoleerd op netwerkniveau via Private Endpoints terwijl aanvullende controles zoals authenticatie, autorisatie en continue monitoring worden geïmplementeerd om ervoor te zorgen dat toegang wordt verleend op basis van identiteit en context in plaats van alleen netwerklocatie. Microsoft's eigen Zero Trust-implementatie benadrukt het belang van Private Endpoints voor het isoleren van workloads en het verminderen van het aanvalsoppervlak, waardoor Private Endpoints een fundamenteel onderdeel zijn van moderne Zero Trust-strategieën in Azure-omgevingen. Voor organisaties die een Zero Trust-transformatie ondergaan, is de implementatie van Private Endpoints voor interne applicaties een belangrijke stap in het moderniseren van hun netwerkbeveiliging en het uitlijnen van hun infrastructuur met Zero Trust-principes.
Naast deze primaire compliance-frameworks zijn Private Endpoints ook relevant voor andere beveiligingsstandaarden en best practices die van toepassing zijn op Nederlandse organisaties. De NIS2-richtlijn (Network and Information Systems Directive 2) vereist dat operators van essentiële diensten en belangrijke entiteiten adequate beveiligingsmaatregelen implementeren, waaronder netwerkbeveiliging en het minimaliseren van aanvalsoppervlakken. De Algemene Verordening Gegevensbescherming (AVG) vereist technische en organisatorische maatregelen om persoonsgegevens te beschermen, waarbij Private Endpoints bijdragen aan het verminderen van het risico op ongeautoriseerde toegang tot systemen die persoonsgegevens verwerken. Voor organisaties in de gezondheidszorg zijn Private Endpoints relevant voor compliance met de Wet op de Geneeskundige Behandelingsovereenkomst (WGBO) en andere sectorale privacy-eisen die vereisen dat medische gegevens adequaat worden beschermd tegen onbevoegde toegang. Tijdens compliance-audits moeten organisaties kunnen aantonen dat Private Endpoint-configuraties regelmatig worden gecontroleerd en dat public network access daadwerkelijk is uitgeschakeld, wat vereist dat monitoring en audit-logging correct zijn geconfigureerd om compliance-evidence te verzamelen voor auditors en toezichthouders.
Monitoring
Gebruik PowerShell-script app-service-private-endpoints-configured.ps1 (functie Invoke-Monitoring) – Controleren.
Remediatie
Gebruik PowerShell-script app-service-private-endpoints-configured.ps1 (functie Invoke-Remediation) – Herstellen.
Compliance & Frameworks
- CIS M365: Control Network (L2) - Private connectivity
- BIO: 13.01.01 - Netwerkbeveiliging
- ISO 27001:2022: A.13.1.1 - Network segregation
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 App Service elimineren publieke internet exposure door applicaties te plaatsen binnen een Azure Virtual Network (VNet) met private IP-adressen in plaats van publieke endpoints. Implementatie creëert een Private Endpoint-resource die de App Service koppelt aan een VNet-subnet, waardoor toegang alleen mogelijk is vanuit het VNet, on-premises netwerken verbonden via ExpressRoute of VPN, of andere peered VNets - publieke internet-toegang wordt volledig geblokkeerd. DNS-integratie via Private DNS Zones zorgt dat interne clients de applicatie resolven naar het private IP-adres in plaats van het publieke endpoint. Network Security Groups kunnen granulaire toegangscontrole bieden op subnet-niveau. Use cases: interne business APIs die alleen door andere Azure-resources worden aangeroepen, employee portals toegankelijk alleen via bedrijfs-VPN, admin interfaces voor system configuration die extra isolatie vereisen, backend services in multi-tier architecturen waar alleen frontend publiek is. Belangrijke vereisten en beperkingen: App Service Premium v2/v3 tier of Isolated tier vereist (Private Endpoints niet beschikbaar op Basic/Standard, upgrade kost vanaf €150/maand), Public network access moet expliciet worden uitgeschakeld (publicNetworkAccess=Disabled) om publiek endpoint te blokkeren, Private DNS Zone-integratie vereist voor correcte name resolution binnen VNet, clients buiten VNet (zoals lokale development machines) kunnen applicatie niet meer bereiken zonder VPN-verbinding naar VNet. Deze maatregel is sterk aanbevolen voor interne applicaties in enterprise-omgevingen, mandatory voor compliance met BIO 13.01.01 en ISO 27001 A.13.1.1 network segmentation-vereisten, en essential voor Zero Trust network architectures. Implementatie-effort: 3-4 uur (tier upgrade indien nodig, Private Endpoint creation, Private DNS configuration, testing), kosten: Premium tier vanaf €150/maand plus €6 per Private Endpoint per maand. Return on investment komt van: reduced attack surface door eliminatie van publieke internet exposure, compliance met network segmentation-vereisten, DDoS protection (niet meer publiek benaderbaar), en enhanced security posture voor interne applicaties via network-level isolation.
- Implementatietijd: 4 uur
- FTE required: 0.05 FTE