L2 BIO 13.01.01 ISO A.13.1.1 CIS 3.1.1

Azure Databricks: Aangepaste Virtual Network Injection Implementeren

📅 2025-10-30
•
⏱️ 12 minuten lezen
•
🔴 Must-Have

💼 Management Samenvatting

Virtual Network (VNet) Injection implementeert Azure Databricks clusters binnen een door de klant beheerd virtueel netwerk, waardoor organisaties volledige netwerkcontrole verkrijgen via Network Security Groups (NSGs), firewalls, private endpoints en on-premises connectiviteit. Deze architectuur is essentieel voor organisaties met strenge netwerksegmentatie-eisen.

Aanbeveling
IMPLEMENTEER VOOR PRODUCTIE-WORKLOADS
Risico zonder
High
Risk Score
8/10
Implementatie
12u (tech: 8u)
Van toepassing op:
✓ Azure Databricks

In een standaard Azure Databricks deployment worden clusters geïmplementeerd in een door Microsoft beheerd virtueel netwerk, waarbij organisaties geen directe netwerkcontrole hebben. Dit betekent dat u geen Network Security Groups kunt toepassen op het cluster-verkeer, geen private endpoints kunt configureren voor beveiligde toegang tot Azure-services, geen connectiviteit heeft met uw on-premises omgeving via ExpressRoute of VPN, beperkte zichtbaarheid heeft in netwerkverkeerspatronen, en potentiële compliance-hiaten ontstaan ten aanzien van netwerk-isolatie-eisen. Met VNet Injection verkrijgt uw organisatie volledige controle over het netwerkverkeer van Databricks. Dit omvat de mogelijkheid om NSG-regels toe te passen op al het cluster-verkeer, User Defined Routes (UDR) te gebruiken voor het routeren van verkeer via bijvoorbeeld een Azure Firewall, Private Link en private endpoints in te zetten voor veilige toegang tot Azure Storage en Key Vault, Azure Firewall-integratie te realiseren voor uitgaand verkeer-filtering, ExpressRoute of site-to-site VPN-connectiviteit te configureren naar on-premises datacenters en applicaties, en te voldoen aan netwerk-isolatie-vereisten zoals gesteld in NIS2 en ISO 27001. Voor organisaties in gereguleerde sectoren of met Zero Trust-architectuurprincipes is VNet Injection daarom vaak een must-have vereiste.

PowerShell Modules Vereist
Primary API: Azure API
Connection: Connect-AzAccount
Required Modules: Az.Databricks, Az.Network

Implementatie

Deze maatregel implementeert VNet Injection voor Azure Databricks workspaces, waarbij Databricks clusters worden geïmplementeerd in een door de organisatie beheerd virtueel netwerk. De implementatie omvat verschillende essentiële stappen. Allereerst moet een toegewijd Virtual Network worden aangemaakt met voldoende adresruimte (minimaal een /16 CIDR-range wordt aanbevolen). Binnen dit VNet moeten twee afzonderlijke subnets worden gecreëerd: een publiek subnet (minimaal /24) en een privé subnet (minimaal /24) die beide specifiek gereserveerd zijn voor Databricks-gebruik. Deze subnets moeten gedelegeerd worden aan de Microsoft.Databricks/workspaces service, wat toestemming geeft aan Databricks om resources in deze subnets te beheren. Vervolgens moeten Network Security Group-regels worden geconfigureerd die het vereiste Databricks-verkeer toestaan, inclusief inbound verkeer op poort 443 vanaf de AzureDatabricks service tag voor control plane-communicatie. Bij het aanmaken van de Databricks workspace moet de VNet Injection-configuratie worden gespecificeerd, waarbij het aangemaakte VNet en de subnets worden geselecteerd. Optioneel kunnen User Defined Routes worden geconfigureerd voor het routeren van uitgaand verkeer via een Azure Firewall, en kunnen private endpoints worden ingesteld voor beveiligde toegang tot Azure Storage en Key Vault. Na de implementatie worden alle Databricks clusters automatisch binnen het klant-VNet aangemaakt, wat volledige netwerk-zichtbaarheid en controle mogelijk maakt.

Vereisten

  1. Toegewijd VNet met minimaal /16 CIDR (of groter)
  2. Twee subnets voor Databricks: publiek (/24) en privé (/24)
  3. NSG gekoppeld aan beide subnets
  4. Subnet delegatie geconfigureerd naar Microsoft.Databricks/workspaces
  5. Geen UDR conflicten met Databricks regelen plane communicatie
  6. firewall regels voor vereiste Databricks endpoints
  7. Planning voor IP adres ruimte (clusters gebruiken IP adressen)

Implementatie

Gebruik PowerShell-script databricks-custom-vnet.ps1 (functie Invoke-Remediation) – Automatiseert VNet Injection-configuratie voor Databricks workspaces inclusief VNet setup, subnet delegation en NSG-configuratie.

⚠️ **KRITIEKE VEREISTE**: Custom VNet Injection kan UITSLUITEND worden geconfigureerd tijdens het initiële aanmaken van een Azure Databricks workspace. Retrofitting VNet Injection op bestaande workspaces is technisch onmogelijk - dit vereist complete workspace re-creation met volledige data-migratie. Plan dit zorgvuldig VOORDAT u productie-workspaces deployt.

**FASE 1: Virtual Network Design en IP Address Planning (Duur: 2-3 uur)**

  1. Design de VNet address space met voldoende capaciteit voor toekomstige groei. MINIMUM is /16 (65.536 IP-adressen) maar /14 is recommended voor large-scale deployments met 100+ concurrent clusters. Databricks clusters consumeren significant IP-adressen: een 10-node cluster gebruikt 20+ IPs (2x aantal nodes voor redundancy).
  2. Kies een private IP-range volgens RFC 1918 standaarden die NIET overlapt met bestaande corporate networks (on-premises of andere Azure VNets): 10.0.0.0/8, 172.16.0.0/12, of 192.168.0.0/16. Overlap veroorzaakt routing conflicts die ExpressRoute/VPN connectivity blokkeren.
  3. Plan subnet sizing: Databricks vereist TWEE dedicated subnets: (1) 'Public' subnet (misleading naam - het is NIET internet-facing, maar voor control plane communicatie) met minimum /26 (64 IPs) maar /24 (256 IPs) recommended, (2) 'Private' subnet voor cluster worker nodes met minimum /26 maar /23 of groter recommended voor production (elke cluster node consumed 2 IPs). Formule: (#max_concurrent_cluster_nodes × 2) + 25% overhead.
  4. Documenteer het IP address plan in een network diagram met CIDR blocks, subnet purposes, reserved ranges voor future expansion, en integration points met corporate network (VPN gateway subnets, ExpressRoute gateways, Azure Firewall subnet).
  5. Obtain approval van enterprise networking team voor de VNet design, IP allocation en routing plan om conflicts met existing network infrastructure te voorkomen. Networking-gerelateerde issues na deployment zijn zeer moeilijk te remediëren.

**FASE 2: Azure Virtual Network Creatie en Basis-configuratie (Duur: 1 uur)**

  1. Creëer Azure VNet via Azure Portal, ARM template of Terraform in dezelfde Azure region als de geplande Databricks workspace (cross-region VNet Injection is niet supported). Naming convention: 'vnet-databricks-prod-westeurope'.
  2. Configureer de VNet address space met de in Fase 1 geplande CIDR block, bijvoorbeeld 10.140.0.0/16 voor een dedicated Databricks VNet of integreer in bestaande enterprise VNet als subnet.
  3. Schakel DDoS Protection Standard optioneel IN voor productie-workloads (€2.500/maand maar biedt protection tegen volumetric attacks). Basic DDoS is gratis maar limited protection.
  4. Configureer Azure DNS settings: gebruik Azure-provided DNS (168.63.129.16) of custom DNS servers indien corporate policy dit vereist. Let op: custom DNS kan Databricks control plane connectivity blokkeren indien niet correct configured.
  5. Tag de VNet met relevante metadata: Environment=Production, Workload=Databricks, CostCenter=Analytics, Owner=DataEngineering voor resource management en cost allocation.

**FASE 3: Databricks Subnets Creatie met Delegation (Duur: 1 uur)**

  1. Creëer het 'public' subnet (ondanks de naam: niet publiek toegankelijk, maar voor Databricks control plane communicatie): gebruik CIDR zoals 10.140.1.0/24, naam zoals 'snet-databricks-public', en delegeer het subnet aan 'Microsoft.Databricks/workspaces' service delegation (MANDATORY voor VNet Injection).
  2. Creëer het 'private' subnet voor Databricks worker nodes: gebruik CIDR zoals 10.140.2.0/23 (512 IPs voor grotere clusters), naam zoals 'snet-databricks-private', en delegeer ook dit subnet aan 'Microsoft.Databricks/workspaces'.
  3. Subnet delegation is KRITIEK: zonder delegation zal Databricks workspace deployment falen. Delegation geeft Databricks-service permissions om network interfaces aan te maken in deze subnets tijdens cluster launches.
  4. Reserveer GEEN IP-adressen in deze subnets voor andere resources - Databricks-delegated subnets mogen ALLEEN door Databricks worden gebruikt. Andere VMs of resources in deze subnets zullen deployment problemen veroorzaken.
  5. Voor multi-workspace scenarios: creëer separate subnet pairs per workspace voor volledige isolatie, of gebruik shared subnets (mogelijk maar meer complex permission management).

**FASE 4: Network Security Groups (NSGs) Configuratie met Required Rules (Duur: 2-3 uur)**

  1. Creëer een dedicated NSG voor Databricks subnets: naam zoals 'nsg-databricks-prod'. Gebruik NIET shared NSGs met andere workloads om blast radius te limiteren.
  2. Configureer MANDATORY inbound rules vereist voor Databricks control plane connectivity: (1) Allow inbound TCP 443 FROM 'AzureDatabricks' service tag TO subnet (workspace management), (2) Allow inbound ANY FROM VirtualNetwork TO VirtualNetwork (inter-cluster communicatie tussen public en private subnets). Zonder deze rules kunnen clusters niet starten.
  3. Configureer MANDATORY outbound rules: (1) Allow outbound TCP 443 TO 'AzureDatabricks' service tag (control plane), (2) Allow outbound TCP 3306 TO 'Sql' service tag (metastore), (3) Allow outbound TCP 443 TO 'Storage' service tag (DBFS, cluster logs), (4) Allow outbound ANY TO VirtualNetwork (inter-cluster).
  4. Implementeer RESTRICTIVE outbound rules voor security hardening: Block outbound TO Internet BEHALVE via Azure Firewall (implementeer UDRs in Fase 6), Allow only specific Azure service tags (Storage, Sql, KeyVault, AzureActiveDirectory) en block 'Internet' service tag direct om data exfiltration te voorkomen, Log ALL denied traffic via NSG Flow Logs voor security monitoring.
  5. Koppel de NSG aan BEIDE Databricks subnets (public en private). NSG moet zijn attached voordat workspace wordt deployed.
  6. Test NSG rules door een test Databricks workspace te deployen in een development VNet met identieke NSG configuration om te verifiëren dat clusters kunnen starten. NSG misconfigurations zijn de #1 oorzaak van VNet Injection deployment failures.

**FASE 5: Databricks Workspace Deployment met VNet Injection (Duur: 2 uur)**

  1. Start Databricks workspace creation via Azure Portal → Create Databricks Workspace → tijdens 'Networking' tab selecteer 'Deploy Azure Databricks workspace in your Virtual Network (VNet Injection)'.
  2. Selecteer de in Fase 2 gecreëerde VNet en de public/private subnets. Azure valideert automatisch of subnets correct zijn gedelegeerd en voldoende IP space hebben.
  3. Configureer 'Secure Cluster Connectivity' (No Public IP) optie: wanneer enabled, krijgen cluster nodes GEEN public IP-adressen wat attack surface reduceert. Recommended voor high-security deployments, maar vereist NAT Gateway of Azure Firewall voor outbound internet connectivity.
  4. Voor private connectivity: schakel 'Private Link' optioneel IN wat een Private Endpoint creëert voor de Databricks workspace URL (webapp endpoint) zodat users Databricks UI kunnen bereiken via private IP in plaats van publiek.
  5. Valideer tijdens deployment: Azure controleert subnet delegation, NSG attachment, IP space sufficiency. Deployment fails met detailed error als iets niet klopt - lees error messages carefully.
  6. Wacht op deployment completion (10-15 minuten). Monitor deployment via Azure Portal notifications of Azure CLI: 'az databricks workspace show --resource-group --name --query provisioningState'.
  7. Immediate na deployment: verifieer dat VNet Injection correct is door te checken: Azure Portal → Databricks workspace → Networking waarbij VNet name en subnet names moeten verschijnen. Start een test cluster en verify dat network interfaces verschijnen in de designated subnets.

**FASE 6: User-Defined Routes (UDRs) en Azure Firewall Integration (Optioneel maar Recommended, Duur: 3-4 uur)**

  1. Voor centralized traffic inspection: creëer een Route Table en associeer met beide Databricks subnets. Configureer UDRs die ALLE outbound internet traffic (0.0.0.0/0) forwarden naar Azure Firewall of Network Virtual Appliance (NVA) voor inspection.
  2. Deploy Azure Firewall in een dedicated subnet in de VNet of in hub VNet (hub-spoke topology). Configureer Firewall rules die Databricks required outbound traffic toestaan: *.azuredatabricks.net op TCP 443, Azure Storage endpoints, Azure SQL metastore, package repositories zoals PyPI/Maven voor library installations.
  3. KRITIEKE AANDACHT: UDRs kunnen Databricks control plane connectivity breken indien incorrectly configured. Gebruik de Azure Databricks-provided UDR template als starting point: routes naar AzureDatabricks service tag moeten NIET via Firewall maar direct naar internet om asymmetric routing te voorkomen.
  4. Implementeer Azure Firewall threat intelligence-based filtering die automatic blocks traffic naar known malicious IP addresses and domains, wat data exfiltration naar command & control servers voorkomt.
  5. Test thoroughly: start een cluster en monitor Azure Firewall logs om te verifiëren dat all required traffic wordt toegestaan. Cluster start failures door UDR/Firewall blocks zijn common - iterative testing is essential.

**FASE 7: Private Endpoints voor Dependent Azure Services (Duur: 2-3 uur)**

  1. Voor Azure Storage Accounts gebruikt door Databricks (DBFS storage, cluster logs): creëer Private Endpoints in de Databricks VNet zodat storage traffic private blijft. Configure Private DNS zones voor automatic DNS resolution van storage.blob.core.windows.net naar private IPs.
  2. Voor Azure Key Vault (indien CMK gebruikt): implementeer Private Endpoint zodat encryption key access via private network gebeurt. Kritiek voor compliance met data sovereignty vereisten.
  3. Voor Azure SQL Databases of Azure Synapse gebruikt als data sources: Private Endpoints elimineren public internet exposure van database connections. Databricks clusters kunnen dan secure via private IPs connecteren.
  4. Voor elke Private Endpoint: verify DNS resolution werkt correct vanaf Databricks clusters door een notebook te draaien met 'nslookup storage-account.blob.core.windows.net' - dit moet private IP teruggeven (10.x.x.x), NIET public IP (20.x.x.x of 52.x.x.x).
  5. Configureer NSG rules om traffic naar Private Endpoint IPs toe te staan indien restrictive outbound rules in plaats zijn. Private Endpoints gebruiken service tag 'Storage', 'KeyVault', 'Sql' die al in NSG allowed should zijn.

**FASE 8: NSG Flow Logs en Network Monitoring Setup (Duur: 1-2 uur)**

  1. Schakel NSG Flow Logs IN voor de Databricks NSG: send flow logs naar Storage Account voor retention en optioneel naar Log Analytics for real-time analysis. Flow logs capture ALL traffic (allowed en denied) voor security forensics.
  2. Configureer Traffic Analytics (built-in Azure feature) die NSG Flow Logs analyseert en visualizations biedt van: top talkers (welke IPs genereren meeste traffic), geographic traffic patterns (detect traffic naar unexpected countries), denied traffic patterns (blocked data exfiltration attempts), protocol distribution.
  3. Implementeer Azure Network Watcher packet captures (on-demand) voor deep troubleshooting van connectivity issues. Packet captures kunnen worden triggered wanneer clusters failover te starten.
  4. Creëer Azure Monitor alerts voor anomalous network behavior: Sudden spike in outbound traffic volume (>1000% increase kan indicate data exfiltration), Traffic naar new external IPs not seen before (could be command & control), High volume of denied traffic (indicates scanning or attack attempts), Connectivity failures naar critical endpoints zoals storage or metastore.
  5. Setup a monitoring dashboard in Azure Monitor workbooks met: Network traffic volume trends, Top destination IPs en ports, NSG rule hit counts (welke rules worden vaak triggered), Denied traffic analysis.

**FASE 9: On-Premises Connectivity via ExpressRoute of VPN (Optioneel, Duur: 4-8 uur)**

De negende fase omvat de optionele implementatie van on-premises connectiviteit via ExpressRoute of VPN Gateway voor hybrid cloud-scenario's waarbij Databricks-clusters moeten verbinden met on-premises databronnen zoals legacy-databases, bestandsservers of private API's. Voor deze scenario's moeten organisaties kiezen tussen ExpressRoute, dat een toegewijde private verbinding biedt met voorspelbare latency en hogere bandbreedte (1-100 Gbps), of VPN Gateway, dat een virtuele private netwerkverbinding biedt via het publieke internet met lagere kosten maar variabele performance. ExpressRoute is bijzonder geschikt voor organisaties met hoge beschikbaarheidsvereisten of die grote hoeveelheden data moeten verplaatsen tussen on-premises systemen en Azure Databricks, maar kost tussen €400 en €4.000 per maand afhankelijk van de bandbreedte en connectiviteitsprovider. VPN Gateway is een goedkopere optie (circa €100 per maand) maar biedt variabele performance en hogere latency, wat acceptabel kan zijn voor organisaties met minder strenge vereisten of lagere data-volumes.

Wanneer het Databricks-VNet en het on-premises gateway-VNet gescheiden zijn, moeten organisaties VNet-peering configureren tussen het Databricks-VNet en het hub-VNet met gatewaytransit ingeschakeld, zodat Databricks-verkeer kan worden gerouteerd via de gecentraliseerde ExpressRoute- of VPN-gateway. Deze configuratie maakt het mogelijk om meerdere spoke-VNets, inclusief het Databricks-VNet, te laten delen van een enkele ExpressRoute- of VPN-verbinding, wat kostenefficiënt is en consistente routing biedt across de hele organisatie. Gatewaytransit moet expliciet worden ingeschakeld tijdens de VNet-peering-configuratie, omdat deze functie standaard is uitgeschakeld om beveiligingsredenen. Wanneer gatewaytransit is ingeschakeld, kunnen resources in het Databricks-VNet automatisch gebruik maken van de gateway in het hub-VNet zonder dat er een aparte gateway hoeft te worden geïmplementeerd in het Databricks-VNet, wat kosten bespaart en de netwerktopologie vereenvoudigt.

On-premises firewallregels moeten worden bijgewerkt om inkomend verkeer van Databricks-subnetbereiken toe te staan naar specifieke databaseservers, API's of bestandsservers. Deze firewallregels moeten worden geconfigureerd volgens least-privilege-principes, waarbij alleen vereiste poorten en protocollen worden toegestaan om de aanvalsoppervlakte te minimaliseren. Organisaties moeten specifiek verifiëren dat alleen verkeer van Databricks-subnetten wordt toegestaan en niet van andere Azure-subnetten, wat de beveiliging verbetert door de bron van toegang te beperken. Firewallregels moeten worden gedocumenteerd met uitleg waarom specifieke poorten en protocollen zijn toegestaan, wat essentieel is voor compliance-audits en security-reviews. Regelmatige reviews van firewallregels moeten worden uitgevoerd om te verifiëren dat alleen actief gebruikte verbindingen zijn toegestaan en dat ongebruikte regels worden verwijderd om de beveiliging te verbeteren.

Connectiviteit moet worden getest vanaf Databricks-notebooks door verbinding te maken met on-premises systemen zoals SQL Server, bestandsservers of REST API's. Deze tests moeten worden uitgevoerd met private IP-adressen in plaats van publieke IP-adressen of FQDN's, omdat private IP-adressen ervoor zorgen dat verkeer via de ExpressRoute- of VPN-verbinding loopt in plaats van via het publieke internet. Tijdens het testen moeten organisaties de latency meten om te verifiëren dat deze acceptabel is (minder dan 50 milliseconden voor databases in dezelfde regio), omdat hoge latency de performance van Databricks-workloads kan beïnvloeden. Tests moeten worden uitgevoerd met verschillende workloads en datavolumes om te verifiëren dat de verbinding stabiel is onder verschillende omstandigheden. Eventuele connectivity-problemen moeten worden geanalyseerd met Azure Network Watcher om te identificeren waar verbindingen falen en welke aanpassingen nodig zijn aan firewallregels of routeconfiguraties.

Monitoring van on-premises connectiviteit moet worden geïmplementeerd om proactief te detecteren wanneer verbindingen falen of latency boven acceptabele drempels stijgt. Azure Monitor Connection Monitor kan periodieke connectiviteitstests uitvoeren tussen Databricks-subnets en on-premises endpoints, waarbij automatisch wordt gealert wanneer connectiviteit faalt of wanneer latency boven geconfigureerde drempels komt. Deze tests moeten worden geconfigureerd om regelmatig (bijvoorbeeld elke vijf minuten) verbinding te testen met kritieke on-premises systemen, zodat problemen snel worden gedetecteerd voordat ze impact hebben op productie-workloads. Connection Monitor-logs moeten worden geïntegreerd met Azure Monitor-alerts zodat operations teams automatisch worden gewaarschuwd wanneer connectiviteitsproblemen optreden. Daarnaast moeten trends in latency en beschikbaarheid worden gemonitord om te identificeren wanneer verbindingen langzaam verslechteren, wat kan wijzen op netwerkproblemen die moeten worden aangepakt voordat ze kritiek worden.

**FASE 10: Security hardening en validatietests (Duur: 2-3 uur)**

De tiende en laatste fase omvat security hardening en validatietests om te verifiëren dat alle security-configuraties correct zijn geïmplementeerd en dat de VNet Injection-architectuur voldoet aan compliance-vereisten. Network Watcher NSG-diagnostiek moet worden geïmplementeerd voor continue validatie dat NSG-regels correct zijn geconfigureerd en geen conflicten hebben. NSG-diagnostiek kan simuleren of specifieke verkeersstromen zouden worden toegestaan of geblokkeerd door NSG-regels, wat essentieel is voor het valideren van security-configuraties voordat problemen optreden. Deze diagnostiek moet regelmatig worden uitgevoerd om te verifiëren dat NSG-regels nog steeds correct zijn geconfigureerd en dat wijzigingen in de netwerkarchitectuur geen security-hiaten hebben geïntroduceerd. Organisaties moeten procedures ontwikkelen voor regelmatige NSG-diagnostiek en moeten waarschuwingen configureren wanneer diagnostiek wijst op mogelijke configuratiefouten of security-hiaten.

Penetration testing moet worden uitgevoerd met Microsoft-goedkeuring via het Azure penetration testing notification formulier om te verifiëren dat security-configuraties effectief werken tegen aanvalpogingen. Deze tests moeten verifiëren dat vanaf Databricks-clusters ongeautoriseerde uitgaande verbindingen naar kwaadaardige IP-adressen worden geblokkeerd, dat data exfiltratie via DNS-tunneling of ICMP wordt voorkomen, en dat laterale beweging naar andere Azure-resources wordt geblokkeerd door NSG-regels. Penetration testing moet worden uitgevoerd door gekwalificeerde security-professionals die bekend zijn met Azure-netwerkbeveiliging en die kunnen identificeren wanneer security-configuraties niet effectief zijn. De resultaten van penetration testing moeten worden gedocumenteerd in een security-rapport dat alle gevonden kwetsbaarheden en aanbevelingen voor verbetering bevat. Organisaties moeten actie ondernemen op basis van deze aanbevelingen om de security-posture te verbeteren en moeten follow-up tests uitvoeren om te verifiëren dat kwetsbaarheden zijn verholpen.

Validatie dat de Databricks-workspace control plane-communicatie werkt moet worden uitgevoerd door meerdere clusters gelijktijdig te starten en te verifiëren dat alle clusters succesvol starten. Deze validatie is essentieel om te verifiëren dat NSG-regels, subnet-delegatie en andere configuraties correct werken onder normale omstandigheden. Veelvoorkomende problemen die tijdens validatie kunnen optreden zijn NSG-regels die de AzureDatabricks-servicetag blokkeren, subnets die onvoldoende IP-adressen hebben, of ontbrekende subnet-delegatie. Deze problemen moeten worden geïdentificeerd en opgelost voordat productie-workloads worden gestart. Organisaties moeten verschillende scenario's testen, inclusief het starten van kleine en grote clusters, het starten van meerdere clusters gelijktijdig, en het starten van clusters met verschillende configuraties, om te verifiëren dat alle scenario's correct werken.

Failure-scenario's moeten worden getest om te verifiëren dat het systeem graceful faalt wanneer componenten niet beschikbaar zijn of wanneer configuratiefouten optreden. Organisaties moeten testen wat er gebeurt wanneer de Azure Firewall wordt gestopt (indien gebruikt) en verifiëren dat Databricks-clusters graceful falen zonder dataverlies of corrumpering. Organisaties moeten ook testen wat er gebeurt wanneer een Private Endpoint wordt verwijderd en verifiëren dat foutmeldingen betekenisvol zijn en dat operators kunnen begrijpen wat er mis is. Daarnaast moeten organisaties testen wat er gebeurt wanneer NSG-regels worden gewijzigd om vereist verkeer te blokkeren en verifiëren dat cluster-startfouten correct worden gelogd en dat operators worden gewaarschuwd. Deze tests helpen bij het identificeren van zwakke punten in de architectuur en bij het ontwikkelen van procedures voor het omgaan met failure-scenario's in productieomgevingen.

Alle netwerkafhankelijkheden moeten worden gedocumenteerd in een architectuurdiagram dat de VNet-topologie, subnet-indeling, NSG-regels, UDR next hops, Private Endpoints, ExpressRoute- of VPN-connectiviteit en DNS-configuratie weergeeft. Deze documentatie is essentieel voor troubleshooting wanneer problemen optreden en voor knowledge transfer wanneer teamleden wijzigen of wanneer nieuwe teamleden worden toegevoegd. Het architectuurdiagram moet worden bijgewerkt wanneer wijzigingen worden doorgevoerd in de netwerkarchitectuur om te garanderen dat de documentatie actueel blijft. Organisaties moeten procedures ontwikkelen voor het onderhouden van deze documentatie en moeten ervoor zorgen dat alle relevante stakeholders toegang hebben tot de documentatie. Deze documentatie is ook essentieel voor compliance-audits, omdat auditors deze gebruiken om te verifiëren dat netwerkisolatie correct is geïmplementeerd en dat alle vereiste security-controles aanwezig zijn.

⏱️ **Totale Implementatie-tijd**: 8-12 uur voor nieuwe workspace met basis VNet Injection (VNet design, subnet creation, NSG config, workspace deployment, testing). Additional 8-16 uur voor advanced networking (Azure Firewall integration, on-premises connectivity via ExpressRoute/VPN, extensive Private Endpoints setup). Voor migratie van bestaande workspaces: add 20-40 uur voor planning, data migration, parallel testing en cutover.

💰 **Kosten**: VNet Injection zelf is gratis (geen extra Databricks-kosten). Azure networking costs: VNet gratis, NSGs gratis, NSG Flow Logs circa €0,10/GB processed, Private Endpoints €6-8 per endpoint per maand, Azure Firewall vanaf €900/maand (Standard) tot €5.500/maand (Premium) indien gebruikt, ExpressRoute vanaf €400/maand (50 Mbps) tot €4.000+/maand (10 Gbps). Total cost of ownership voor production VNet Injection met Firewall en Private Endpoints: €1.000-2.000/maand networking costs bovenop Databricks DBU costs.

Monitoring

Gebruik PowerShell-script databricks-custom-vnet.ps1 (functie Invoke-Monitoring) – Controleren.

Monitor VNet traffic en compliance:

  1. NSG flow logt voor monitoring van cluster verkeerspatronen
  2. Azure firewall logt voor uitgaand verkeer
  3. Azure Network Watcher voor connectiviteit troubleshooting
  4. Alerts bij NSG regel schendingen
  5. Monitor IP adresruimte gebruik

Compliance en Auditing

  1. CIS Azure - regelen 3.1.1 (Netwerk isolatie)
  2. ISO 27001 - A.13.1.1 (Netwerk controls)
  3. NIS2 - Artikel 21 (Netwerk segmentatie)
  4. BIO - Thema 13.01 (Netwerkbeveiliging)
  5. Zero Trust Architectuur compliance

Remediatie

Gebruik PowerShell-script databricks-custom-vnet.ps1 (functie Invoke-Remediation) – Herstellen.

Compliance & Frameworks

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).

PowerShell
<# ================================================================================ AZURE POWERSHELL SCRIPT - Nederlandse Baseline voor Veilige Cloud ================================================================================ .SYNOPSIS Azure Databricks: Deployment in Customer-Managed Virtual Network .DESCRIPTION CIS Azure Foundations Benchmark - Control 3.1.1 Controleert of Azure Databricks workspaces zijn gedeployd in een customer-managed virtual network (VNet injection) in plaats van het standaard Microsoft-managed netwerk. Waarom is deze control belangrijk? - Betere netwerk isolatie en segmentatie - Controle over netwerkverkeer via NSG's en firewalls - Integratie met on-premises netwerken via VPN/ExpressRoute - Voldoet aan compliance vereisten voor netwerk controle .NOTES Filename: databricks-custom-vnet.ps1 Author: Nederlandse Baseline voor Veilige Cloud Version: 1.0 Related JSON: content/azure/analytics/databricks-custom-vnet.json CIS Control: 3.1.1 .PARAMETER WhatIf Toont wat het script zou doen zonder daadwerkelijk wijzigingen door te voeren .PARAMETER Monitoring Voert compliance check uit en toont gedetailleerd rapport .PARAMETER Remediation Voert automatische remediatie uit (toont handmatige instructies) .PARAMETER Revert Draait wijzigingen terug (niet van toepassing voor dit script) .EXAMPLE .\databricks-custom-vnet.ps1 Voert basis compliance check uit .EXAMPLE .\databricks-custom-vnet.ps1 -Monitoring Toont gedetailleerd compliance rapport .EXAMPLE .\databricks-custom-vnet.ps1 -Remediation Toont handmatige remediatie instructies #> # ============================================================================ # REQUIREMENTS # ============================================================================ #Requires -Version 5.1 #Requires -Modules Az.Accounts #Requires -Modules Az.Databricks #Requires -Modules Az.Resources #Requires -Modules Az.Network # ============================================================================ # PARAMETERS # ============================================================================ [CmdletBinding()] param( [Parameter()][switch]$WhatIf, [Parameter()][switch]$Monitoring, [Parameter()][switch]$Remediation, [Parameter()][switch]$Revert ) # ============================================================================ # GLOBAL VARIABLES # ============================================================================ $ErrorActionPreference = 'Stop' $VerbosePreference = 'Continue' $PolicyName = "Azure Databricks: Custom VNet Deployment" # ============================================================================ # FUNCTION: Connect-RequiredServices # ============================================================================ function Connect-RequiredServices { <# .SYNOPSIS Verbind met Azure met de benodigde permissions .DESCRIPTION Controleert of er al een actieve Azure connectie is. Indien niet, maakt het een nieuwe connectie aan. #> function Invoke-Revert { Write-Host "`n⚠️ Revert wordt niet ondersteund voor dit script" -ForegroundColor Yellow Write-Host " Custom VNet naar managed VNet conversie vereist hercreatie" -ForegroundColor Yellow Write-Host " Dit wordt niet aanbevolen vanwege security implications`n" -ForegroundColor Yellow } try { $context = Get-AzContext if (-not $context) { Write-Verbose "Connecting to Azure..." Connect-AzAccount | Out-Null } else { Write-Verbose "Already connected to Azure as $($context.Account.Id)" } } catch { Write-Error "Failed to connect to Azure: $_" throw } } # ============================================================================ # FUNCTION: Test-Compliance # ============================================================================ function Test-Compliance { <# .SYNOPSIS Test of Databricks workspaces in custom VNet zijn gedeployd .DESCRIPTION Controleert alle Databricks workspaces en valideert of ze VNet injection hebben geconfigureerd met custom virtual network. .OUTPUTS PSCustomObject met compliance status en details #> Write-Verbose "Testing compliance for: $PolicyName..." $result = [PSCustomObject]@{ ScriptName = "databricks-custom-vnet" PolicyName = $PolicyName IsCompliant = $false TotalResources = 0 CompliantCount = 0 NonCompliantCount = 0 Details = @() Recommendations = @() } function Invoke-Revert { Write-Host "`n⚠️ Revert wordt niet ondersteund voor dit script" -ForegroundColor Yellow Write-Host " Custom VNet naar managed VNet conversie vereist hercreatie" -ForegroundColor Yellow Write-Host " Dit wordt niet aanbevolen vanwege security implications`n" -ForegroundColor Yellow } try { # Haal alle Databricks workspaces op Write-Verbose "Retrieving all Databricks workspaces..." $workspaces = Get-AzDatabricksWorkspace -ErrorAction SilentlyContinue if (-not $workspaces) { $result.Details += "Geen Databricks workspaces gevonden in dit subscription" $result.IsCompliant = $true return $result } $result.TotalResources = @($workspaces).Count foreach ($workspace in $workspaces) { Write-Verbose "Checking workspace: $($workspace.Name)" # Haal gedetailleerde resource properties op $resourceDetails = Get-AzResource -ResourceId $workspace.Id -ExpandProperties -ErrorAction SilentlyContinue $hasCustomVNet = $false $vnetInfo = "" # Check voor custom VNet configuratie if ($resourceDetails.Properties.parameters.customVirtualNetworkId) { $customVNetId = $resourceDetails.Properties.parameters.customVirtualNetworkId.value $privateSubnet = $resourceDetails.Properties.parameters.customPrivateSubnetName.value $publicSubnet = $resourceDetails.Properties.parameters.customPublicSubnetName.value if ($customVNetId -and $privateSubnet -and $publicSubnet) { $hasCustomVNet = $true $vnetInfo = "VNet: $customVNetId, Private: $privateSubnet, Public: $publicSubnet" } } if ($hasCustomVNet) { # Workspace gebruikt custom VNet $result.CompliantCount++ $result.Details += "✓ Workspace '$($workspace.Name)' gebruikt custom VNet ($vnetInfo)" } else { # Workspace gebruikt Microsoft-managed VNet $result.NonCompliantCount++ $result.Details += "✗ Workspace '$($workspace.Name)' gebruikt GEEN custom VNet (ResourceGroup: $($workspace.ResourceGroupName))" $result.Recommendations += "Deploy workspace '$($workspace.Name)' in custom VNet - vereist hercreatie" } } # Bepaal overall compliance $result.IsCompliant = ($result.NonCompliantCount -eq 0) if ($result.NonCompliantCount -gt 0) { $result.Recommendations += "BELANGRIJK: Custom VNet vereist hercreatie van workspace" $result.Recommendations += "Backup eerst alle notebooks, clusters en libraries" $result.Recommendations += "Zorg voor VNet met minimaal 2x /26 subnets voor private/public" } } catch { $result.Details += "ERROR: $($_.Exception.Message)" $result.Recommendations += "Controleer of Az.Databricks module is geïnstalleerd" $result.Recommendations += "Controleer of je voldoende rechten hebt op subscription" } return $result } # ============================================================================ # FUNCTION: Invoke-Remediation # ============================================================================ function Invoke-Remediation { <# .SYNOPSIS Voert remediatie uit voor Databricks custom VNet deployment .DESCRIPTION LET OP: Databricks workspaces kunnen niet automatisch worden bijgewerkt naar custom VNet. Dit vereist hercreatie van de workspace. Dit script toont gedetailleerde instructies voor handmatige remediatie. #> Write-Host "`nStarting remediation for: $PolicyName..." -ForegroundColor Cyan Write-Host "=" * 80 -ForegroundColor Cyan Write-Host "`n⚠️ BELANGRIJKE WAARSCHUWING:" -ForegroundColor Yellow Write-Host " Custom VNet kan NIET worden toegevoegd aan bestaande workspace" -ForegroundColor Yellow Write-Host " Dit vereist hercreatie van de complete workspace`n" -ForegroundColor Yellow # Haal non-compliant workspaces op $result = Test-Compliance if ($result.NonCompliantCount -eq 0) { Write-Host "[OK] Alle Databricks workspaces zijn compliant" -ForegroundColor Green return } Write-Host "`n📋 HANDMATIGE REMEDIATIE STAPPEN:" -ForegroundColor Cyan Write-Host "=" * 80 -ForegroundColor Cyan Write-Host "`n1️⃣ VOORBEREIDING VAN VIRTUAL NETWORK:" -ForegroundColor White Write-Host " • Maak een Azure Virtual Network aan (of gebruik bestaande)" -ForegroundColor Gray Write-Host " • Minimale address space: /16 (bijv. 10.139.0.0/16)" -ForegroundColor Gray Write-Host " • Maak twee subnets:" -ForegroundColor Gray Write-Host " - Private subnet: minimaal /26 (bijv. 10.139.1.0/26)" -ForegroundColor DarkGray Write-Host " - Public subnet: minimaal /26 (bijv. 10.139.2.0/26)" -ForegroundColor DarkGray Write-Host " • Zorg dat beide subnets GEEN route table of service endpoints hebben" -ForegroundColor Gray Write-Host "`n2️⃣ NETWORK SECURITY GROUP CONFIGURATIE:" -ForegroundColor White Write-Host " • Maak NSG aan voor beide subnets" -ForegroundColor Gray Write-Host " • Configureer minimaal deze inbound rules:" -ForegroundColor Gray Write-Host " - Microsoft.Databricks/workspaces (service tag)" -ForegroundColor DarkGray Write-Host " - AllowVnetInBound voor inter-subnet communicatie" -ForegroundColor DarkGray Write-Host " • Configureer minimaal deze outbound rules:" -ForegroundColor Gray Write-Host " - AllowInternetOutBound (control plane connectie)" -ForegroundColor DarkGray Write-Host " - AllowAzureCloudOutBound" -ForegroundColor DarkGray Write-Host "`n3️⃣ SUBNET DELEGATIE:" -ForegroundColor White Write-Host " • Delegeer beide subnets aan Microsoft.Databricks/workspaces" -ForegroundColor Gray $delegateCommand = @' # PowerShell voorbeeld voor subnet delegatie $vnet = Get-AzVirtualNetwork -Name "databricks-vnet" -ResourceGroupName "network-rg" $privateSubnet = Get-AzVirtualNetworkSubnetConfig -Name "databricks-private" -VirtualNetwork $vnet $privateSubnet.Delegations.Add((New-AzDelegation -Name "databricks-del-private" -ServiceName "Microsoft.Databricks/workspaces")) $publicSubnet = Get-AzVirtualNetworkSubnetConfig -Name "databricks-public" -VirtualNetwork $vnet $publicSubnet.Delegations.Add((New-AzDelegation -Name "databricks-del-public" -ServiceName "Microsoft.Databricks/workspaces")) Set-AzVirtualNetwork -VirtualNetwork $vnet '@ Write-Host " PowerShell voorbeeld:" -ForegroundColor Gray Write-Host $delegateCommand -ForegroundColor DarkGray Write-Host "`n4️⃣ WORKSPACE BACKUP:" -ForegroundColor White Write-Host " • Export alle notebooks naar local directory" -ForegroundColor Gray Write-Host " • Documenteer alle cluster configuraties" -ForegroundColor Gray Write-Host " • Lijst alle geïnstalleerde libraries" -ForegroundColor Gray Write-Host " • Backup init scripts en secrets" -ForegroundColor Gray Write-Host " • Documenteer alle access permissions en groups" -ForegroundColor Gray Write-Host "`n5️⃣ NIEUWE WORKSPACE CREATIE:" -ForegroundColor White Write-Host " • Maak nieuwe workspace aan met custom VNet:" -ForegroundColor Gray $createCommand = @' New-AzDatabricksWorkspace ` -Name "databricks-workspace-vnet" ` -ResourceGroupName "databricks-rg" ` -Location "westeurope" ` -Sku "premium" ` -ManagedResourceGroupName "databricks-managed-rg" ` -VirtualNetworkId "/subscriptions/{sub-id}/resourceGroups/network-rg/providers/Microsoft.Network/virtualNetworks/databricks-vnet" ` -PrivateSubnetName "databricks-private" ` -PublicSubnetName "databricks-public" '@ Write-Host $createCommand -ForegroundColor DarkGray Write-Host "`n6️⃣ RESTORE EN VALIDATIE:" -ForegroundColor White Write-Host " • Import notebooks naar nieuwe workspace" -ForegroundColor Gray Write-Host " • Recreëer clusters met dezelfde configuratie" -ForegroundColor Gray Write-Host " • Installeer libraries" -ForegroundColor Gray Write-Host " • Configureer access permissions" -ForegroundColor Gray Write-Host " • Test alle kritieke workloads" -ForegroundColor Gray Write-Host " • Valideer met: .\databricks-custom-vnet.ps1 -Monitoring" -ForegroundColor Gray Write-Host "`n7️⃣ CLEANUP:" -ForegroundColor White Write-Host " • Verwijder oude workspace ALLEEN na volledige validatie" -ForegroundColor Gray Write-Host " • Update alle connection strings en pipelines" -ForegroundColor Gray Write-Host "`n📚 DOCUMENTATIE:" -ForegroundColor Cyan Write-Host " Microsoft Docs: https://learn.microsoft.com/azure/databricks/security/network/classic/vnet-inject" -ForegroundColor Blue Write-Host " Network Requirements: https://learn.microsoft.com/azure/databricks/security/network/classic/vnet-inject#network-requirements" -ForegroundColor Blue Write-Host "`n⚠️ Test deze operatie EERST in een non-productie omgeving!" -ForegroundColor Yellow } # ============================================================================ # FUNCTION: Invoke-Monitoring # ============================================================================ function Invoke-Monitoring { <# .SYNOPSIS Voert compliance check uit en toont gedetailleerd rapport .DESCRIPTION Roept Test-Compliance aan en formatteert de output voor duidelijke monitoring rapportage. #> $result = Test-Compliance Write-Host "`n========================================" -ForegroundColor Cyan Write-Host "$PolicyName" -ForegroundColor Cyan Write-Host "========================================" -ForegroundColor Cyan Write-Host "Workspaces gecontroleerd: $($result.TotalResources)" -ForegroundColor White Write-Host "Compliant: $($result.CompliantCount)" -ForegroundColor Green $color = if ($result.NonCompliantCount -gt 0) { "Red" } else { "Green" } Write-Host "Non-compliant: $($result.NonCompliantCount)" -ForegroundColor $color if ($result.Details) { Write-Host "`nDetails:" -ForegroundColor Yellow foreach ($detail in $result.Details) { Write-Host " $detail" -ForegroundColor Gray } } if ($result.Recommendations) { Write-Host "`nAanbevelingen:" -ForegroundColor Yellow foreach ($recommendation in $result.Recommendations) { Write-Host " → $recommendation" -ForegroundColor Cyan } } return $result } # ============================================================================ # MAIN EXECUTION BLOCK # ============================================================================ function Invoke-Revert { Write-Host "`n⚠️ Revert wordt niet ondersteund voor dit script" -ForegroundColor Yellow Write-Host " Custom VNet naar managed VNet conversie vereist hercreatie" -ForegroundColor Yellow Write-Host " Dit wordt niet aanbevolen vanwege security implications`n" -ForegroundColor Yellow } try { # Stap 1: Verbind met Azure Connect-RequiredServices # Stap 2: Bepaal actie op basis van parameters if ($Monitoring) { Invoke-Monitoring } elseif ($Remediation) { if ($WhatIf) { Write-Host "`n=== WHATIF MODE ===" -ForegroundColor Yellow Write-Host "Zou remediatie instructies tonen voor: $PolicyName" -ForegroundColor Yellow Write-Host "LET OP: Dit script voert GEEN automatische remediatie uit" -ForegroundColor Yellow Write-Host "Custom VNet vereist handmatige hercreatie van workspaces" -ForegroundColor Yellow Write-Host "===================`n" -ForegroundColor Yellow } else { Invoke-Remediation } } elseif ($Revert) { Invoke-Revert } else { # Standaard: simpele compliance check $result = Test-Compliance Write-Host "`n========================================" -ForegroundColor Cyan Write-Host "Compliance Check: $PolicyName" -ForegroundColor Cyan Write-Host "========================================" -ForegroundColor Cyan if ($result.IsCompliant) { Write-Host "Status: [OK] COMPLIANT" -ForegroundColor Green Write-Host "Alle Databricks workspaces zijn in custom VNet gedeployd" -ForegroundColor Green } else { Write-Host "Status: [FAIL] NON-COMPLIANT" -ForegroundColor Red Write-Host "Aantal non-compliant workspaces: $($result.NonCompliantCount)" -ForegroundColor Red Write-Host "`nRun met -Monitoring voor gedetailleerd rapport" -ForegroundColor Yellow Write-Host "Run met -Remediation voor remediatie instructies" -ForegroundColor Yellow } } } catch { Write-Error "An error occurred: $_" Write-Error $_.ScriptStackTrace exit 1 }

Risico zonder implementatie

Risico zonder implementatie
High: Wanneer Azure Databricks wordt gedeployed zonder Custom Virtual Network Injection (VNet Injection) en dus gebruik maakt van het standaard Microsoft-beheerde VNet, ontstaan aanzienlijke netwerkbeveiligings- en compliance-risico's die productie-deployment voor gereguleerde organisaties onacceptabel maken. Zonder VNet Injection heeft de organisatie GEEN controle over netwerkverkeer van Databricks-clusters, wat betekent dat Network Security Groups (NSGs) niet kunnen worden toegepast om ongeautoriseerde uitgaand verkeer naar malicious IP-adressen of data exfiltration-pogingen te blokkeren, Azure Firewall inspectie en filtering van Databricks-verkeer onmogelijk is, en threat intelligence-gebaseerde blocking niet kan worden geïmplementeerd. On-premises connectiviteit via ExpressRoute of VPN is niet mogelijk in Microsoft-managed VNet-scenario's, wat betekent dat Databricks geen secure toegang heeft tot on-premises databases, legacy systemen of private data sources, wat hybrid cloud-scenario's blokkeert en data duplication naar cloud forceert met verhoogde kosten en complexity. Private Endpoints voor Azure Storage, Key Vault, Azure SQL en andere Azure services kunnen NIET worden gebruikt zonder VNet Injection, wat betekent dat alle communicatie tussen Databricks en deze services via publieke internet endpoints moet gaan in plaats van private Azure backbone network, wat security risks en compliance-schendingen creëert onder NIS2 Artikel 21 (netwerkisolatie) en BIO 13.01 (netwerk segmentatie). Network visibility en security monitoring is drastisch beperkt omdat NSG Flow Logs, traffic analytics en network packet captures niet beschikbaar zijn voor Microsoft-managed VNets, wat forensisch onderzoek na security incidents critically beperkt. Compliance-audits voor ISO 27001 Controle A.13.1.1 (netwerk controles), NIS2 netwerkisolatie-vereisten en sectorspecifieke regelgeving zoals BIO voor overheidsinstellingen zullen falen zonder aantonable netwerkcontrole. Het risico is HIGH voor productie-workspaces met sensitive data, MANDATORY voor gereguleerde sectoren zoals finance onder AFM/DNB-toezicht, healthcare met patiëntgegevens, of overheid met staatsgeheime informatie, en STRONGLY RECOMMENDED voor alle business-critical Databricks deployments ongeacht sector.

Management Samenvatting

Custom Virtual Network (VNet) Injection voor Azure Databricks implementeert Databricks-clusters binnen het door de klant beheerde Azure Virtual Network in plaats van een Microsoft-managed VNet, wat volledige netwerkcontrole en security visibility mogelijk maakt. VNet Injection is ESSENTIEEL voor productie-workloads omdat het de volgende kritieke capabilities enableert: (1) Network Security Groups (NSGs) kunnen worden toegepast op Databricks-subnets voor granulaire inbound/outbound traffic filtering, blocking van unauthorized destinations en data exfiltration-preventie, (2) Azure Firewall of Network Virtual Appliances kunnen alle Databricks-verkeer inspecteren via User-Defined Routes (UDRs) voor advanced threat detection en URL filtering, (3) Private Endpoints voor Azure Storage Accounts, Azure Key Vault, Azure SQL Databases kunnen worden geïmplementeerd zodat ALL Databricks-communicatie via private Azure backbone gebeurt zonder public internet exposure, (4) ExpressRoute of VPN connectivity naar on-premises datacenters enabled hybrid scenarios waarbij Databricks secure kan connecteren met legacy databases, file servers of private APIs, (5) NSG Flow Logs en Azure Network Watcher bieden comprehensive network traffic visibility voor security monitoring en forensics, (6) Hub-spoke network topologies kunnen Databricks integreren in enterprise network architectures met centralized security controls. Deze maatregel is MANDATORY voor productie Databricks-workspaces in gereguleerde sectoren, REQUIRED voor compliance met NIS2 Artikel 21 en BIO 13.01 netwerkisolatie-vereisten, en STRONGLY RECOMMENDED voor alle business-critical workloads ongeacht data sensitivity. Belangrijke vereisten zijn: dedicated Azure VNet met minimaal /16 CIDR address space, twee subnets (public en private) van elk minimaal /24 voor Databricks cluster nodes, subnet delegation naar Microsoft.Databricks/workspaces service, en awareness dat VNet Injection ALLEEN tijdens workspace creation kan worden geconfigureerd - bestaande workspaces moeten volledig opnieuw worden aangemaakt. Implementatie-effort is 8-12 uur inclusief VNet design, subnet configuration, NSG rule development, Databricks workspace deployment met VNet Injection, Private Endpoint setup voor dependent services, connectivity testing en network monitoring configuration. Er zijn geen extra Databricks-kosten voor VNet Injection (het is een gratis feature), maar wel reguliere Azure networking costs voor VNet, NSGs, Private Endpoints (€6-8 per endpoint per maand), en optionele Azure Firewall (€900+ per maand). Return on investment komt van compliance-achievement, enhanced security posture, network visibility voor threat detection, en flexibility voor hybrid cloud architectures met on-premises connectivity.