L2 BIO 13.01.01 ISO A.13.1.1 CIS Network

Azure Databricks: Network Security Groups Correct Configureren

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

💼 Management Samenvatting

Correct geconfigureerde Network Security Groups (NSGs) voor Azure Databricks VNet Injection subnets vormen een cruciale balans tussen beveiliging door minimale blootstelling en het waarborgen van de vereiste Databricks-functionaliteit voor beheerlaag-communicatie en clusteronderling verkeer. Deze configuratie is essentieel voor een veilige en functionele Databricks-omgeving.

Aanbeveling
IMPLEMENTEER VERPLICHT VOOR VNET INJECTION
Risico zonder
High
Risk Score
8/10
Implementatie
4u (tech: 3u)
Van toepassing op:
✓ Azure Databricks met VNet Injection

Azure Databricks vereist specifieke Network Security Group-regels voor correcte werking. Deze regels moeten beheerlaag-communicatie via poort 443 naar de AzureDatabricks service tag toestaan, clusteronderling communicatie binnen subnets mogelijk maken, en toegang tot Azure Storage voor DBFS faciliteren. Het vinden van de juiste balans is kritiek: te restrictieve NSG-regels resulteren in clusters die niet kunnen starten, jobs die timeout oplopen, en notebooks die loskoppelen, wat operationele problemen en productiviteitsverlies veroorzaakt. Aan de andere kant leiden te permissieve regels tot beveiligingslekken waarbij ongeautoriseerd verkeer mogelijk wordt, laterale beweging binnen het netwerk kan plaatsvinden, en aanvallers een groter aanvalsoppervlak krijgen. Een correcte NSG-configuratie staat uitsluitend het vereiste Databricks-verkeer toe op basis van het principe van minimale bevoegdheden, blokkeert alle onnodige netwerkblootstelling om het aanvalsoppervlak te minimaliseren, en maakt monitoring mogelijk via NSG flow logs voor zichtbaarheid in verkeerspatronen en detectie van afwijkingen. Voor organisaties met compliance-vereisten zoals NIS2 en ISO 27001 is correcte netwerksegmentatie en toegangscontrole een absolute vereiste, wat deze NSG-configuratie tot een must-have maakt voor productie-Databricks-omgevingen.

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

Implementatie

Deze maatregel implementeert de vereiste Network Security Group-regels voor Azure Databricks VNet Injection, waarbij NSGs worden toegepast op zowel de publieke als privé subnets die door Databricks worden gebruikt. De configuratie omvat specifieke inkomende en uitgaande regels die zorgvuldig zijn afgestemd op Databricks-vereisten. Voor inkomend verkeer moet poort 443 vanaf de AzureDatabricks service tag worden toegestaan om beheerlaag-communicatie mogelijk te maken, waardoor de Databricks-beheerlaag clusters kan aansturen. Daarnaast moet al het interne subnet-verkeer worden toegestaan voor clusteronderling communicatie, wat essentieel is voor gedistribueerde rekenoperaties. Al het overige inkomend verkeer moet expliciet worden geweigerd om ongeautoriseerde toegang te voorkomen. Voor uitgaand verkeer moet poort 443 naar de AzureDatabricks service tag worden toegestaan voor beheerlaag-responses, poort 443 naar Azure Storage voor DBFS (Databricks File System) toegang, en poort 3306 naar Azure SQL Database voor toegang tot de Hive metastore. Intern subnet-verkeer moet worden toegestaan voor cluster-communicatie. Voor al het overige uitgaand verkeer kan worden gekozen om dit volledig te weigeren, of om het te routeren via een Azure Firewall of Network Virtual Appliance voor verkeersinspectie en filtering. Deze NSG moet worden gekoppeld aan zowel de publieke als de privé subnets die door Databricks worden gebruikt. Daarnaast wordt aanbevolen om NSG flow logs in te schakelen voor continue monitoring van verkeerspatronen en het detecteren van potentiële beveiligingsproblemen.

Vereisten

Voordat u begint met de implementatie van Network Security Groups voor Azure Databricks VNet Injection, moet u ervoor zorgen dat aan alle technische en organisatorische vereisten wordt voldaan. Deze vereisten vormen de fundering voor een succesvolle en veilige implementatie die zowel de operationele functionaliteit als de beveiligingsdoelstellingen waarborgt.

De primaire technische vereiste is dat Azure Databricks moet zijn geïmplementeerd met VNet Injection functionaliteit. Dit betekent dat de Databricks workspace is geconfigureerd om gebruik te maken van een aangepast virtueel netwerk binnen uw Azure-omgeving, in plaats van de standaard gedeelde infrastructuur. VNet Injection is essentieel omdat het de mogelijkheid biedt om Network Security Groups toe te passen op de specifieke subnets die door Databricks worden gebruikt. Zonder VNet Injection heeft u geen controle over de netwerkbeveiliging op subnet-niveau, wat deze maatregel onmogelijk maakt. Controleer of uw Databricks workspace is geconfigureerd met de optie voor VNet Injection en of de benodigde subnets zijn aangemaakt binnen uw virtuele netwerk.

Een tweede kritieke vereiste betreft de Network Security Group zelf. U moet een dedicated Network Security Group aanmaken die specifiek is bedoeld voor de Databricks subnets. Deze NSG moet worden gekoppeld aan zowel de publieke als de privé subnets die door Databricks worden gebruikt. Het is belangrijk om te begrijpen dat de NSG moet worden aangemaakt voordat de Databricks workspace wordt geïmplementeerd, of tijdens een gepland onderhoudsvenster wanneer er geen actieve clusters draaien. Het achteraf koppelen van een NSG aan een reeds actieve workspace kan tijdelijke connectiviteitsproblemen veroorzaken tijdens de overgangsperiode, wat kan resulteren in verstoring van de dienstverlening.

Een diepgaand begrip van de netwerkvereisten van Databricks is onmisbaar voor een succesvolle implementatie. Azure Databricks heeft specifieke poortvereisten voor verschillende functionaliteiten. De beheerlaag-communicatie vereist TCP-poort 443 voor zowel inkomend als uitgaand verkeer naar de AzureDatabricks service tag. Clusteronderling communicatie binnen de subnets moet volledig worden toegestaan, wat betekent dat al het verkeer tussen de publieke en privé subnets moet kunnen plaatsvinden. Voor de toegang tot Azure Storage voor het Databricks File System (DBFS) is uitgaand verkeer naar poort 443 naar de Storage service tag vereist. De Hive metastore functionaliteit vereist toegang tot Azure SQL Database via poort 3306. Zonder volledig inzicht in deze netwerkvereisten loopt u het risico om te restrictieve regels te configureren die de functionaliteit van Databricks volledig blokkeren, of te permissieve regels die onnodige beveiligingsrisico's introduceren.

Voor effectieve monitoring en probleemoplossing is het inschakelen van NSG Flow Logs een absolute vereiste. NSG Flow Logs bieden gedetailleerde inzicht in al het netwerkverkeer dat door de Network Security Group wordt verwerkt, inclusief informatie over toegestaan en geweigerd verkeer. Deze logs zijn essentieel voor het identificeren van configuratiefouten, het detecteren van verdachte verkeerspatronen, en het uitvoeren van forensisch onderzoek na beveiligingsincidenten. Zonder NSG Flow Logs bent u in feite blind voor wat er gebeurt op netwerkniveau, wat het onmogelijk maakt om beveiligingsproblemen te identificeren of compliance-vereisten te verifiëren. Configureer NSG Flow Logs om te worden verzonden naar een Log Analytics workspace, zodat u de gegevens kunt analyseren met KQL-queries en kunt integreren met Azure Monitor voor geavanceerde waarschuwingsregels.

Voor organisaties die extra beveiligingslagen willen implementeren, is een Azure Firewall of Network Virtual Appliance (NVA) optioneel maar sterk aanbevolen voor uitgaande filtering. Deze oplossingen bieden geavanceerde mogelijkheden voor verkeersinspectie, threat intelligence-gebaseerde filtering, en fijnmazige controle over welke bestemmingen kunnen worden bereikt. Wanneer u kiest voor deze aanpak, moet u User-Defined Routes (UDRs) configureren die al het uitgaande verkeer routeren via de firewall of NVA voor inspectie. Dit is met name belangrijk voor organisaties die werken met gevoelige gegevens en die extra bescherming willen tegen data exfiltratie en andere geavanceerde bedreigingen.

Naast deze technische vereisten zijn er ook organisatorische overwegingen. Zorg ervoor dat het team dat verantwoordelijk is voor de implementatie beschikt over de benodigde expertise in zowel Azure-netwerkbeveiliging als Databricks-architectuur. Dit is geen standaard netwerkconfiguratie en vereist specifieke kennis van hoe Databricks functioneert op netwerkniveau. Overweeg om Azure-consultants of Databricks-ondersteuning te betrekken voor validatie van het NSG-ontwerp voordat u overgaat tot productie-implementatie, vooral als uw organisatie beperkte ervaring heeft met Databricks VNet Injection configuraties.

Implementatie

Gebruik PowerShell-script databricks-nsg-configured.ps1 (functie Invoke-Remediation) – Automatiseert NSG-configuratie voor Databricks subnets met vereiste en aanbevolen beveiligingsregels.

Het is van cruciaal belang om te begrijpen dat een onjuiste NSG-configuratie de belangrijkste oorzaak is van mislukkingen bij Databricks VNet Injection-implementaties. Te restrictieve regels breken de functionaliteit van Databricks volledig, waardoor clusters niet kunnen starten en de hele workspace onbruikbaar wordt. Aan de andere kant creëren te permissieve regels onnodige beveiligingsrisico's door ongeautoriseerd verkeer toe te staan. Deze implementatie vereist daarom een nauwkeurige balans tussen functionaliteit en beveiliging, waarbij elke regel zorgvuldig moet worden afgestemd op de specifieke netwerkvereisten van Databricks.

**FASE 1: NSG Aanmaak en Basisconfiguratie (Duur: 30 minuten)**

De eerste fase van de implementatie omvat het aanmaken en configureren van de Network Security Group zelf. Begin met het aanmaken van een toegewijde Network Security Group die specifiek is bedoeld voor de Databricks subnets. Dit kunt u doen via de Azure Portal door te navigeren naar Network Security Groups en vervolgens Maken te selecteren. Gebruik een duidelijke naamgevingsconventie zoals 'nsg-databricks-prod-westeu' die aangeeft dat dit een NSG is voor Databricks in de productieomgeving in de regio West-Europa. Een consistente naamgevingsconventie is essentieel voor governance en maakt het eenvoudiger om resources te identificeren en te beheren.

Het is belangrijk om de NSG te configureren in dezelfde Azure-regio en resource group als het virtuele netwerk dat door Databricks wordt gebruikt. Deze configuratie is vereist voor de koppeling tussen de NSG en de subnets. Door de NSG in dezelfde regio te plaatsen, minimaliseert u latentie en zorgt u voor optimale prestaties. Het plaatsen in dezelfde resource group vereenvoudigt het beheer en maakt het eenvoudiger om gerelateerde resources samen te beheren.

Voor effectieve governance en resourcebeheer moet u de NSG taggen met relevante metadata. Gebruik tags zoals Workload=Databricks om aan te geven dat deze NSG specifiek is voor Databricks-workloads, Environment=Production om de omgeving te identificeren, en ManagedBy=CloudTeam om aan te geven welk team verantwoordelijk is voor het beheer. Deze tags zijn niet alleen nuttig voor organisatorische doeleinden, maar ook voor kostenbeheer, compliance-rapportage en geautomatiseerde beleidsregels.

Documenteer het doel van de NSG in het Description-veld van de resource. Een duidelijke beschrijving zoals 'Beveiligingsregels voor Azure Databricks VNet Injection - balanceert beheerlaag-connectiviteit met beveiligingsisolatie' helpt toekomstige beheerders en auditors om snel te begrijpen waarom deze NSG bestaat en wat de beoogde functionaliteit is. Deze documentatie is met name waardevol tijdens compliance-audits en wanneer nieuwe teamleden betrokken raken bij het beheer van de infrastructuur.

Een kritiek aandachtspunt is de timing van de NSG-aanmaak. U moet de NSG aanmaken voordat de Databricks workspace wordt geïmplementeerd. Het achteraf koppelen van een NSG aan een reeds actieve workspace kan tijdelijke connectiviteitsproblemen veroorzaken tijdens de overgangsperiode. Deze problemen kunnen resulteren in verstoring van de dienstverlening, waarbij actieve clusters mogelijk tijdelijk niet bereikbaar zijn of nieuwe clusters niet kunnen worden gestart. Door de NSG vooraf aan te maken en te configureren, voorkomt u deze operationele risico's en zorgt u voor een soepele implementatie.

**FASE 2: Verplichte Inkomende Regels voor Beheerlaag-connectiviteit (Duur: 30 minuten)**

De tweede fase omvat het configureren van de verplichte inkomende regels die nodig zijn voor de beheerlaag-connectiviteit van Databricks. Deze regels zijn absoluut noodzakelijk voor de werking van de Databricks workspace en mogen niet worden overgeslagen. De eerste regel die u moet configureren is de Beheerlaag-beheerregel met prioriteit 100. Geef deze regel de naam 'AllowAzureDatabricksControlPlane' en configureer deze met de service tag 'AzureDatabricks' als bron, alle bronpoorten, VirtualNetwork als bestemming, bestemmingspoort 443, protocol TCP en actie Allow. Deze regel is absoluut vereist voor het beheer van de Databricks workspace. Zonder deze regel kunnen clusters niet worden gestart of gestopt, omdat de beheerlaag niet in staat is om te communiceren met de clusters in uw virtuele netwerk.

De tweede verplichte regel betreft de clusteronderling communicatie. Configureer een regel met prioriteit 110 met de naam 'AllowVNetInternalCommunication'. Deze regel moet al het verkeer toestaan binnen het virtuele netwerk, waarbij VirtualNetwork zowel als bron als bestemming wordt gebruikt, alle poorten worden toegestaan, en het protocol Any wordt gebruikt met actie Allow. Databricks clusters moeten onderling kunnen communiceren tussen de publieke en privé subnets om gedistribueerde rekenoperaties uit te voeren. Het blokkeren van deze communicatie breekt de functionaliteit van gedistribueerd rekenen volledig, waardoor clusters niet kunnen samenwerken en taken niet kunnen worden uitgevoerd.

Voor extra beveiligingsversterking moet u een expliciete deny-regel configureren voor al het overige inkomend verkeer. Deze regel heeft prioriteit 4096, de naam 'DenyAllOtherInbound', en blokkeert al het verkeer van elke bron naar elke bestemming op alle poorten met elk protocol. Hoewel Azure standaard al een deny-all beleid heeft, maakt een expliciete deny-regel de beveiligingsintentie duidelijk in audits en compliance-controles. Deze regel documenteert expliciet dat alleen het toegestane verkeer is bedoeld en dat al het andere verkeer wordt geweigerd, wat waardevol is voor beveiligingsaudits en compliance-rapportage.

Een kritiek aandachtspunt bij het configureren van de beheerlaag-regel is dat u exact de service tag naam 'AzureDatabricks' moet gebruiken. Typefouten zoals 'AzureDataBricks' met een hoofdletter B, of simpelweg 'Databricks' werken niet. Service tags zijn hoofdlettergevoelig en Azure valideert deze namen strikt. Een verkeerde service tag naam resulteert in een regel die niet functioneert, waardoor de beheerlaag-communicatie wordt geblokkeerd en clusters niet kunnen starten. Controleer daarom zorgvuldig de exacte spelling en hoofdlettergebruik bij het configureren van deze regel.

**FASE 3: Verplichte Uitgaande Regels voor Databricks-afhankelijkheden (Duur: 45 minuten)**

De derde fase omvat het configureren van de verplichte uitgaande regels die nodig zijn voor de verschillende afhankelijkheden van Databricks. Deze regels zijn essentieel omdat Databricks afhankelijk is van verschillende Azure-services om te functioneren. De eerste uitgaande regel betreft de beheerlaag-responses. Configureer een regel met prioriteit 100 met de naam 'AllowOutboundDatabricksControlPlane' waarbij VirtualNetwork de bron is, de service tag 'AzureDatabricks' de bestemming, bestemmingspoort 443, protocol TCP en actie Allow. Bidirectionele beheerlaag-communicatie is vereist, wat betekent dat clusters niet alleen inkomend verkeer moeten kunnen ontvangen, maar ook uitgaand verkeer moeten kunnen verzenden naar de beheerlaag voor het rapporteren van status, het ontvangen van instructies en het uitvoeren van beheeroperaties.

De tweede verplichte uitgaande regel betreft de toegang tot Azure Storage voor het Databricks File System (DBFS). Configureer een regel met prioriteit 110 met de naam 'AllowOutboundAzureStorage' waarbij VirtualNetwork de bron is, de service tag 'Storage.WestEurope' de bestemming (let op: gebruik de regiospecifieke service tag, niet de generieke), bestemmingspoort 443, protocol TCP en actie Allow. Het Databricks File System wordt ondersteund door Azure Storage, wat betekent dat alle bestandsoperaties die worden uitgevoerd in Databricks notebooks en jobs uiteindelijk worden opgeslagen in Azure Storage. Zonder toegang tot Azure Storage kunnen clusters geen gegevens lezen of schrijven, waardoor de hele functionaliteit van Databricks wordt geblokkeerd.

De derde verplichte regel betreft de toegang tot Azure SQL Database voor de Hive metastore-functionaliteit. Configureer een regel met prioriteit 120 met de naam 'AllowOutboundSqlMetastore' waarbij VirtualNetwork de bron is, de service tag 'Sql.WestEurope' de bestemming (opnieuw: gebruik de regiospecifieke service tag), bestemmingspoort 3306, protocol TCP en actie Allow. De Databricks Hive metastore gebruikt Azure SQL Database om metadata over tabellen, databases en andere objecten op te slaan. Zonder toegang tot deze database is tabelmetadata ontoegankelijk, waardoor queries niet kunnen worden uitgevoerd en data-analyse onmogelijk wordt.

De vierde verplichte regel betreft de interne VNet-communicatie voor uitgaand verkeer. Configureer een regel met prioriteit 130 met de naam 'AllowOutboundVNetInternal' waarbij VirtualNetwork zowel de bron als de bestemming is, alle bestemmingspoorten worden toegestaan, protocol Any en actie Allow. Deze regel is nodig voor clusteronderling subnet node-communicatie, waarbij verschillende nodes binnen een cluster met elkaar moeten kunnen communiceren om gedistribueerde reken taken uit te voeren. Zonder deze regel kunnen cluster nodes niet met elkaar communiceren, waardoor taken falen en de cluster-functionaliteit wordt aangetast.

Als uw organisatie Azure Active Directory gebruikt voor authenticatie, moet u een vijfde verplichte regel configureren. Deze regel heeft prioriteit 140, de naam 'AllowOutboundAzureAD', de service tag 'AzureActiveDirectory' als bestemming, bestemmingspoort 443, protocol TCP en actie Allow. Deze regel is vereist wanneer Azure AD-synchronisatie is ingeschakeld, omdat clusters dan moeten kunnen communiceren met Azure Active Directory voor authenticatie en autorisatie. Zonder deze regel kunnen gebruikers niet inloggen op de Databricks workspace en kunnen geauthenticeerde operaties niet worden uitgevoerd.

Een belangrijk aandachtspunt bij het configureren van de Storage- en SQL-regels is dat u regiospecifieke service tags moet gebruiken in plaats van generieke tags. Gebruik bijvoorbeeld 'Storage.WestEurope' en 'Sql.WestEurope' in plaats van simpelweg 'Storage' en 'Sql'. Deze regiospecifieke tags bieden betere beveiligingsgranulariteit door verkeer te beperken tot alleen dezelfde regio, wat het risico op cross-region data exfiltratie vermindert. Als een aanvaller toegang krijgt tot een cluster, kan deze alleen gegevens exfiltreren naar storage-accounts in dezelfde regio, niet naar accounts in andere regio's, wat de potentiële schade beperkt.

**FASE 4: Optionele maar Aanbevolen Uitgaande Regels voor Uitgebreide Functionaliteit (Duur: 30 minuten)**

De vierde fase omvat het configureren van optionele maar sterk aanbevolen uitgaande regels die nodig zijn voor uitgebreide functionaliteit. Hoewel deze regels niet strikt vereist zijn voor de basiswerking van Databricks, zijn ze wel nodig voor veel praktische gebruiksscenario's. De eerste optionele regel betreft de toegang tot PyPI en Maven package repositories. Configureer een regel met prioriteit 200 die uitgaand verkeer naar poort 443 naar het internet toestaat voor package-installaties van pypi.org en repo.maven.apache.org. Deze regel is nodig wanneer gebruikers Python-packages of Maven-dependencies willen installeren in hun Databricks-notebooks. Als alternatief kunt u internettoegang blokkeren en private package repositories configureren binnen het virtuele netwerk via Azure Artifact feeds, wat een veiligere aanpak is maar meer configuratie vereist.

Als uw organisatie Customer-Managed Keys (CMK) gebruikt voor versleuteling, moet u een regel configureren voor toegang tot Azure Key Vault. Configureer een regel met prioriteit 210 die uitgaand verkeer naar poort 443 naar de service tag 'AzureKeyVault.WestEurope' toestaat voor toegang tot versleutelingssleutels. Deze regel is essentieel wanneer u CMK gebruikt, omdat Databricks dan toegang nodig heeft tot de sleutels in Key Vault om gegevens te versleutelen en te ontsleutelen. Zonder deze regel kunnen versleutelingsoperaties falen, waardoor gegevens niet kunnen worden gelezen of geschreven.

Voor effectieve monitoring en logging moet u een regel configureren voor toegang tot Azure Monitor. Configureer een regel met prioriteit 220 die uitgaand verkeer naar poort 443 naar de service tag 'AzureMonitor' toestaat voor het verzenden van diagnostische logs en metrische gegevens. Deze regel is belangrijk voor het monitoren van de gezondheid en prestaties van uw Databricks-clusters, het verzamelen van diagnostische informatie voor probleemoplossing, en het integreren met Azure Monitor-waarschuwingen voor proactieve beheer. Zonder deze regel worden logs en metrische gegevens niet verzonden naar Azure Monitor, waardoor u beperkt zicht heeft op de status van uw clusters.

Als uw organisatie aangepaste container images gebruikt voor Databricks Runtime, moet u een regel configureren voor toegang tot Azure Container Registry. Configureer een regel met prioriteit 230 die uitgaand verkeer naar poort 443 naar de service tag 'AzureContainerRegistry' toestaat. Deze regel is nodig wanneer u aangepaste Docker-container images hebt gebouwd die specifieke dependencies of configuraties bevatten die niet beschikbaar zijn in de standaard Databricks Runtime-images. Zonder deze regel kunnen clusters die zijn geconfigureerd om aangepaste images te gebruiken, deze niet ophalen, waardoor de clusters niet kunnen starten.

Voor extra beveiligingsversterking moet u overwegen om expliciet al het overige uitgaand verkeer naar het internet te weigeren met een regel met prioriteit 4000. Deze regel is alleen nodig wanneer alle vereiste bestemmingen zijn gedekt via service tags. Door deze regel te configureren, dwingt u al het verkeer via Azure Firewall of een Network Virtual Appliance voor inspectie, indien er een route bestaat die 0.0.0.0/0 naar de firewall of NVA routeert. Deze aanpak biedt extra beveiligingslagen door al het uitgaande verkeer te inspecteren op bedreigingen en ongeautoriseerde toegang te voorkomen.

**FASE 5: NSG-koppeling en Validatietests (Duur: 1 uur)**

De vijfde fase omvat het koppelen van de NSG aan de Databricks subnets en het uitvoeren van uitgebreide validatietests om te verifiëren dat de configuratie correct werkt. Begin met het koppelen van de NSG aan beide Databricks subnets, zowel de publieke als de privé subnet. Dit kunt u doen via de Azure Portal door te navigeren naar Virtual Network, vervolgens Subnets te selecteren, het gewenste subnet te kiezen, en dan Network Security Group te selecteren om de aangemaakte NSG te koppelen. Herhaal dit proces voor beide subnets om ervoor te zorgen dat alle Databricks-verkeer door de NSG wordt gefilterd.

De timing van de NSG-koppeling is kritiek voor het voorkomen van connectiviteitsverstoringen. U moet de NSG koppelen voordat de Databricks workspace wordt geïmplementeerd, of tijdens een gepland onderhoudsvenster wanneer er geen actieve clusters draaien. Het koppelen van een NSG aan een actieve workspace kan tijdelijke connectiviteitsproblemen veroorzaken, waarbij actieve clusters mogelijk tijdelijk niet bereikbaar zijn of nieuwe clusters niet kunnen worden gestart. Door de timing zorgvuldig te plannen, voorkomt u operationele verstoringen en zorgt u voor een soepele overgang.

Na het koppelen van de NSG moet u een test Databricks cluster starten om te valideren dat de NSG-regels correct zijn geconfigureerd. Als het cluster succesvol start en de Running-status bereikt, betekent dit dat de NSG-regels correct zijn geconfigureerd en dat alle vereiste verkeer wordt toegestaan. Als het cluster echter faalt tijdens het opstarten en blijft hangen in een Pending-status, of als u foutmeldingen krijgt zoals 'unable to reach control plane', betekent dit dat de NSG vereist verkeer blokkeert. In dit geval moet u de NSG Flow Logs raadplegen om te identificeren welk verkeer wordt geblokkeerd en de regels dienovereenkomstig aanpassen.

Het is essentieel om NSG Flow Logs onmiddellijk in te schakelen na het koppelen van de NSG. Ga naar de NSG in de Azure Portal, selecteer Flow logs, en maak een nieuwe flow log aan die wordt verzonden naar een Log Analytics workspace. Flow logs zijn essentieel voor het oplossen van connectiviteitsproblemen die gerelateerd zijn aan NSG-configuraties en voor beveiligingsmonitoring. Zonder flow logs heeft u geen inzicht in welk verkeer wordt toegestaan of geweigerd, wat het onmogelijk maakt om problemen te diagnosticeren of beveiligingsincidenten te onderzoeken.

Voer specifieke connectiviteitstests uit door een notebook te draaien met netwerktests. Gebruik nslookup voor DNS-resolutie om te verifiëren dat DNS-query's correct worden opgelost. Test HTTPS-connectiviteit naar storage en metastore met behulp van wget of curl om te verifiëren dat de uitgaande regels correct werken. Voer ping-tests uit voor interne VNet-routing om te verifiëren dat inter-subnet communicatie functioneert. Deze tests helpen u om specifieke problemen te identificeren voordat u overgaat tot productie-implementatie.

Verifieer via NSG Flow Logs dat de verwachte verkeersstromen correct werken. Query de logs om te controleren of toegestaan verkeer naar de AzureDatabricks, Storage en Sql service tags daadwerkelijk plaatsvindt. Controleer ook of geweigerd verkeer alleen betrekking heeft op niet-geautoriseerde bestemmingen en niet op vereiste services. Deze verificatie helpt u om te bevestigen dat de NSG-regels werken zoals bedoeld en dat er geen onbedoelde blokkades zijn die de functionaliteit van Databricks kunnen beïnvloeden.

**FASE 6: Beveiligingsversterking en restrictieve uitgaande regels (Optioneel, Duur: 2-3 uur)**

De zesde fase omvat geavanceerde beveiligingsversterking die optioneel is maar sterk wordt aanbevolen voor organisaties die werken met gevoelige gegevens of die extra beveiligingslagen willen implementeren. Deze fase richt zich op het implementeren van aanvullende netwerkbeveiligingscontroles die verder gaan dan de basis NSG-configuratie en die geavanceerde bedreigingsdetectie en preventie mogelijk maken.

Voor verbeterde beveiliging moet u User-Defined Routes (UDRs) implementeren die al het uitgaande verkeer (0.0.0.0/0) doorsturen naar Azure Firewall of een Network Virtual Appliance. Deze aanpak zorgt ervoor dat al het uitgaande verkeer wordt geïnspecteerd voordat het het virtuele netwerk verlaat, wat essentieel is voor het voorkomen van data exfiltratie en het detecteren van kwaadaardige activiteiten. User-Defined Routes worden geconfigureerd op subnet-niveau en overschrijven de standaard Azure-routing, waardoor u volledige controle krijgt over waar verkeer naartoe wordt gerouteerd. Wanneer u deze routes configureert, moet u ervoor zorgen dat de route naar 0.0.0.0/0 verwijst naar het interne IP-adres van uw Azure Firewall of Network Virtual Appliance, zodat al het uitgaande verkeer via deze beveiligingsapparaten wordt gerouteerd voor inspectie en filtering.

Configureer Azure Firewall application rules die gedetailleerde controle bieden over welke FQDN's (Fully Qualified Domain Names) Databricks mag bereiken. Deze regels maken het mogelijk om specifieke domeinen toe te staan terwijl alle andere domeinen worden geblokkeerd, wat een veel fijnmazigere beveiligingscontrole biedt dan NSG-regels alleen. Configureer regels die toegang toestaan tot *.azuredatabricks.net voor beheerlaag-communicatie, *.blob.core.windows.net voor Azure Storage-toegang, *.database.windows.net voor Azure SQL Database-toegang, pypi.org voor Python-package-installaties, en repo.maven.apache.org voor Maven-dependency-downloads. Deze application rules werken op applicatielaag en kunnen HTTP/HTTPS-verkeer inspecteren om te verifiëren dat verkeer daadwerkelijk naar de toegestane domeinen gaat, wat bescherming biedt tegen DNS-spoofing en andere netwerkaanvallen.

Implementeer threat intelligence-gebaseerde filtering in Azure Firewall die automatisch blokkeert op bekende kwaadaardige IP-adressen en domeinen. Deze functionaliteit maakt gebruik van Microsoft Threat Intelligence-feeds die continu worden bijgewerkt met informatie over bekende command & control-servers, malware-distributiepunten, en andere kwaadaardige bestemmingen. Door deze filtering in te schakelen, voorkomt u dat gecompromitteerde Databricks-clusters of kwaadaardige code in notebooks gegevens kunnen exfiltreren naar externe command & control-servers, zelfs als de code probeert verbinding te maken met deze bestemmingen. Deze bescherming is met name waardevol voor organisaties die werken met gevoelige gegevens en die extra bescherming willen tegen geavanceerde persistente bedreigingen (APT's) en andere geavanceerde aanvallen.

Bekijk NSG Flow Logs wekelijks voor onverwachte verkeerspatronen die kunnen wijzen op beveiligingsincidenten of configuratiefouten. Analyseer grote gegevensoverdrachten naar onbekende IP-adressen die kunnen wijzen op data exfiltratie, waarbij aanvallers proberen gevoelige gegevens te stelen uit uw Databricks-omgeving. Identificeer verbindingen naar verdachte poorten die kunnen wijzen op malware-communicatie, waarbij kwaadaardige software probeert te communiceren met externe servers op ongebruikelijke poorten. Monitor op spikes in geweigerd verkeer die kunnen wijzen op scanning-pogingen, waarbij aanvallers proberen kwetsbaarheden te identificeren in uw netwerkconfiguratie. Door deze patronen regelmatig te analyseren, kunt u beveiligingsincidenten vroegtijdig detecteren en passende maatregelen nemen voordat er significante schade ontstaat.

Voer kwartaal NSG-regel audits uit om te verifiëren dat alle regels nog steeds vereist zijn, verwijder verweesde regels van eerdere configuraties, en documenteer de zakelijke rechtvaardiging voor elke allow-regel. Tijdens deze audits moet u elke NSG-regel evalueren om te bevestigen dat deze nog steeds nodig is voor de operationele functionaliteit van Databricks. Verwijder regels die zijn achtergebleven van eerdere configuraties maar die niet langer nodig zijn, omdat deze onnodige regels het aanvalsoppervlak vergroten en de complexiteit van de beveiligingsconfiguratie verhogen. Documenteer voor elke allow-regel de specifieke zakelijke of technische reden waarom deze regel nodig is, inclusief welke Databricks-functionaliteit afhankelijk is van deze regel. Deze documentatie is essentieel voor compliance-audits en helpt toekomstige beheerders om te begrijpen waarom bepaalde regels bestaan en of ze veilig kunnen worden verwijderd of aangepast.

⏱️ **Totale Implementatie-tijd**: 3-4 uur voor basis NSG-configuratie (NSG-aanmaak, verplichte inkomende en uitgaande regels, subnet-koppeling, cluster start-testen). Additioneel 3-5 uur voor geavanceerde beveiligingsversterking (UDRs, Azure Firewall-integratie, uitgebreide flow log-analyse, beveiligingsbeleidsregels). Totaal: 6-9 uur voor productieklare NSG-installatie.

💰 **Kosten**: NSG zelf is gratis. NSG Flow Logs: €0,10 per GB verwerkt (typisch 2-5 GB per maand voor matig Databricks-gebruik = €0,20-0,50/maand - verwaarloosbaar). Azure Firewall indien gebruikt voor verbeterde inspectie: €900-5.500/maand afhankelijk van tier (Standard versus Premium). Traffic Analytics (optioneel): inbegrepen in NSG Flow Logs, geen extra kosten.

Monitoring

Gebruik PowerShell-script databricks-nsg-configured.ps1 (functie Invoke-Monitoring) – Controleren.

Effectieve monitoring van Network Security Groups voor Azure Databricks vormt de basis voor operationele stabiliteit, beveiligingsdetectie en compliance-verificatie. Zonder uitgebreide monitoring bent u in feite blind voor wat er gebeurt op netwerkniveau, wat het onmogelijk maakt om beveiligingsincidenten te detecteren, configuratiefouten te identificeren, of compliance-vereisten te verifiëren. Deze monitoringstrategie moet meerdere lagen omvatten: netwerkverkeersanalyse via NSG Flow Logs, operationele validatie van Databricks-functionaliteit, en continue beveiligingsbewaking voor afwijkingen en bedreigingen.

De eerste en meest kritieke monitoringcomponent betreft het inschakelen en configureren van NSG Flow Logs. NSG Flow Logs bieden gedetailleerde inzicht in al het netwerkverkeer dat door de Network Security Group wordt verwerkt, inclusief informatie over toegestaan en geweigerd verkeer, bron- en bestemmings-IP-adressen, poorten, protocollen en tijdstempels. Deze logs zijn essentieel voor het identificeren van configuratiefouten, het detecteren van verdachte verkeerspatronen, en het uitvoeren van forensisch onderzoek na beveiligingsincidenten. Zonder NSG Flow Logs bent u niet in staat om te verifiëren of de geconfigureerde regels correct functioneren, of om te identificeren wanneer ongeautoriseerd verkeer wordt geblokkeerd of toegestaan.

Configureer NSG Flow Logs om te worden verzonden naar een Log Analytics workspace, zodat u de gegevens kunt analyseren met KQL-queries en kunt integreren met Azure Monitor voor geavanceerde waarschuwingsregels. Het is belangrijk om de Log Analytics workspace te configureren in dezelfde regio als de NSG om latentie te minimaliseren en kosten te optimaliseren. Stel een retentieperiode in van minimaal 90 dagen voor operationele doeleinden, en overweeg langere retentieperioden voor compliance-vereisten zoals NIS2 en BIO, die vaak langere bewaartermijnen vereisen voor auditdoeleinden.

Een kritieke monitoringactiviteit betreft het instellen van waarschuwingen op geweigerde verkeersstromen. Geweigerde verkeersstromen kunnen wijzen op configuratiefouten waarbij legitiem Databricks-verkeer wordt geblokkeerd, wat resulteert in operationele problemen zoals clusters die niet kunnen starten of jobs die falen. Configureer Azure Monitor waarschuwingsregels die een melding genereren wanneer het aantal geweigerde verkeersstromen een bepaalde drempelwaarde overschrijdt, of wanneer specifieke poorten of protocollen consistent worden geweigerd. Deze waarschuwingen helpen u om snel configuratiefouten te identificeren voordat ze leiden tot significante operationele impact.

Daarnaast moet u waarschuwingen configureren voor verdachte verkeerspatronen die kunnen wijzen op beveiligingsincidenten. Monitor op ongebruikelijke data transfers naar externe IP-adressen die kunnen wijzen op data exfiltratie, verbindingen naar bekende kwaadaardige IP-adressen of domeinen, of verkeer naar ongebruikelijke poorten die kunnen wijzen op malware-communicatie. Integreer NSG Flow Logs met Azure Sentinel of andere Security Information and Event Management (SIEM) systemen voor geavanceerde threat detection en correlatie met andere beveiligingssignalen.

Operationele validatie vormt een tweede kritieke monitoringcomponent. U moet regelmatig verifiëren dat Databricks-clusters succesvol kunnen starten en de Running-status kunnen bereiken. Een cluster dat niet kan starten of oneindig in de Pending-status blijft, kan wijzen op NSG-regels die vereist Databricks-verkeer blokkeren. Implementeer geautomatiseerde tests die periodiek een testcluster starten en verifiëren dat deze succesvol opstart. Deze tests moeten worden uitgevoerd na elke wijziging aan NSG-regels, en minimaal wekelijks voor continue validatie.

Monitor ook de connectiviteit van Databricks notebooks, omdat dit een directe indicator is van de operationele status van de netwerkconfiguratie. Notebooks die niet kunnen verbinden met Azure Storage voor DBFS-toegang, of die niet kunnen communiceren met de Hive metastore, wijzen op problemen met outbound NSG-regels. Implementeer monitoring die de succesvolle uitvoering van notebook-operaties volgt, en waarschuw wanneer fouten optreden die kunnen worden gerelateerd aan netwerkconnectiviteit.

Een derde belangrijke monitoringactiviteit betreft het volgen van job execution success rates. Databricks jobs die consistent falen of timeouts ervaren, kunnen wijzen op netwerkproblemen waarbij vereiste verbindingen worden geblokkeerd. Analyseer job execution logs om patronen te identificeren die kunnen wijzen op NSG-gerelateerde problemen, zoals jobs die falen bij specifieke operaties zoals data lezen van Azure Storage of schrijven naar de Hive metastore. Correlateer deze job failures met NSG Flow Logs om te bevestigen of geweigerde verkeersstromen de oorzaak zijn.

Voor geavanceerde monitoring en troubleshooting moet u regelmatig NSG Flow Logs analyseren met KQL-queries om verkeerspatronen te identificeren. Query op toegestaan verkeer naar de AzureDatabricks service tag om te verifiëren dat control plane-communicatie correct functioneert. Analyseer verkeer naar Azure Storage en Azure SQL Database service tags om te bevestigen dat DBFS en Hive metastore-toegang werken. Identificeer geweigerd verkeer dat mogelijk legitiem is maar wordt geblokkeerd door te restrictieve regels, en gebruik deze informatie om NSG-regels te verfijnen.

Implementeer ook monitoring voor netwerkprestaties en latentie, omdat NSG-regels en flow logging een minimale impact kunnen hebben op netwerkprestaties. Monitor de tijd die nodig is voor NSG Flow Logs om beschikbaar te komen in Log Analytics, omdat vertragingen in log delivery het moeilijk maken om real-time beveiligingsincidenten te detecteren. Overweeg het gebruik van Azure Network Watcher voor geavanceerde netwerkdiagnostiek en troubleshooting wanneer complexe connectiviteitsproblemen optreden.

Ten slotte moet u regelmatige audits uitvoeren van NSG-regels en monitoringconfiguraties om te verifiëren dat alle vereiste monitoring in plaats is en correct functioneert. Verifieer dat NSG Flow Logs actief zijn en gegevens verzamelen, dat waarschuwingsregels correct zijn geconfigureerd en meldingen genereren wanneer verwacht, en dat operationele validatietests regelmatig worden uitgevoerd. Documenteer alle monitoringactiviteiten en resultaten voor compliance-doeleinden en voor toekomstige troubleshooting.

Compliance en Auditing

Correct geconfigureerde Network Security Groups voor Azure Databricks zijn essentieel voor naleving van verschillende cybersecurity- en compliance-frameworks die van toepassing zijn op Nederlandse overheidsorganisaties en kritieke infrastructuur. Deze compliance-vereisten stellen specifieke eisen aan netwerksegmentatie, toegangscontrole, monitoring en auditlogging, die allemaal worden ondersteund door een goed geconfigureerde NSG-implementatie. Organisaties die deze vereisten niet naleven, lopen het risico op boetes, reputatieschade en operationele beperkingen.

De CIS Azure Foundations Benchmark bevat specifieke controles voor netwerkbeveiliging die rechtstreeks van toepassing zijn op NSG-configuraties voor Databricks. Deze benchmark vereist dat organisaties Network Security Groups implementeren om netwerkverkeer te controleren en te beperken op basis van het principe van least privilege. Voor Databricks betekent dit dat NSG-regels moeten worden geconfigureerd om alleen het vereiste verkeer toe te staan dat nodig is voor de werking van de Databricks workspace, en dat alle overige verkeer expliciet moet worden geweigerd. De CIS-controles vereisen ook dat NSG Flow Logs zijn ingeschakeld voor monitoring en auditdoeleinden, wat essentieel is voor het verifiëren van netwerktoegangscontroles en het detecteren van beveiligingsincidenten.

ISO 27001, de internationale standaard voor informatiebeveiligingsmanagement, bevat specifieke controles die relevant zijn voor NSG-configuraties. Controle A.13.1.1 vereist dat organisaties netwerkcontroles implementeren om netwerkverkeer te beheren en te beveiligen. Voor Azure Databricks betekent dit dat NSG-regels moeten worden gebruikt om netwerksegmentatie te implementeren, waarbij Databricks-subnets worden geïsoleerd van andere netwerksegmenten en alleen specifiek geautoriseerd verkeer wordt toegestaan. Controle A.13.1.3 vereist netwerksegregatie, wat wordt ondersteund door het gebruik van dedicated NSGs voor Databricks-subnets die zijn gescheiden van andere workloads. ISO 27001 vereist ook dat organisaties regelmatig audits uitvoeren van netwerkcontroles om te verifiëren dat ze effectief zijn en blijven voldoen aan de beveiligingsvereisten.

De NIS2-richtlijn, die van toepassing is op essentiële entiteiten en belangrijke entiteiten in de Europese Unie, bevat specifieke vereisten voor netwerkbeveiliging in Artikel 21. Dit artikel vereist dat organisaties passende maatregelen implementeren voor netwerksegmentatie en toegangscontrole om de beveiliging van netwerk- en informatiesystemen te waarborgen. Voor Azure Databricks betekent dit dat NSG-regels moeten worden gebruikt om netwerksegmentatie te implementeren waarbij Databricks-workloads worden geïsoleerd van andere systemen, en dat toegangscontroles moeten worden geïmplementeerd op basis van het principe van least privilege. NIS2 vereist ook dat organisaties monitoring en logging implementeren voor netwerkactiviteiten, wat wordt ondersteund door NSG Flow Logs die alle netwerkverkeer vastleggen voor audit- en forensische doeleinden.

Het BIO-kader (Baseline Informatiebeveiliging Overheid) bevat specifieke thema's voor netwerkbeveiliging die relevant zijn voor Nederlandse overheidsorganisaties. Thema 13.01 vereist dat organisaties netwerkbeveiliging implementeren door middel van firewallregels en netwerksegmentatie. Voor Azure Databricks betekent dit dat NSG-regels moeten worden geconfigureerd als firewallregels die netwerkverkeer controleren en beperken. Het BIO-kader vereist ook dat organisaties netwerkverkeer monitoren en loggen voor beveiligingsdoeleinden, wat wordt ondersteund door NSG Flow Logs. Daarnaast vereist het BIO-kader dat organisaties regelmatig audits uitvoeren van netwerkbeveiligingsmaatregelen om te verifiëren dat ze effectief zijn en blijven voldoen aan de beveiligingsvereisten.

Voor compliance-audits moet u uitgebreide documentatie bijhouden van uw NSG-configuratie, inclusief de zakelijke rechtvaardiging voor elke allow-regel, de beveiligingsredenering achter deny-regels, en de procedures voor het beheer en onderhoud van NSG-regels. Deze documentatie moet duidelijk maken waarom specifieke regels zijn geconfigureerd, welke beveiligingsdoelen ze dienen, en hoe ze bijdragen aan de naleving van compliance-vereisten. Auditoren zullen deze documentatie gebruiken om te verifiëren dat de NSG-configuratie correct is geïmplementeerd en dat deze voldoet aan de vereisten van de verschillende compliance-frameworks.

NSG Flow Logs vormen een kritieke component voor compliance-auditing, omdat ze bewijs leveren van netwerktoegangscontroles en monitoring. Deze logs moeten worden bewaard voor de vereiste retentieperioden zoals gespecificeerd in de verschillende compliance-frameworks. Voor NIS2 en BIO zijn vaak langere bewaartermijnen vereist, wat betekent dat u NSG Flow Logs moet configureren met geschikte retentie-instellingen in Log Analytics. Auditoren zullen deze logs gebruiken om te verifiëren dat netwerkverkeer correct wordt gecontroleerd en dat ongeautoriseerd verkeer wordt geblokkeerd zoals bedoeld.

Regelmatige compliance-audits moeten worden uitgevoerd om te verifiëren dat de NSG-configuratie blijft voldoen aan de vereisten van de verschillende frameworks. Deze audits moeten controleren of alle vereiste NSG-regels correct zijn geconfigureerd, of NSG Flow Logs actief zijn en gegevens verzamelen, of waarschuwingsregels correct zijn geconfigureerd voor beveiligingsmonitoring, en of documentatie up-to-date is en alle configuratiewijzigingen correct weerspiegelt. Identificeer eventuele compliance-gaten en implementeer corrigerende maatregelen om ervoor te zorgen dat de NSG-configuratie volledig voldoet aan alle toepasselijke vereisten.

Voor organisaties die werken met gevoelige of geclassificeerde gegevens kunnen aanvullende compliance-vereisten van toepassing zijn, zoals de Baseline Informatiebeveiliging Rijksdienst (BIR) of specifieke sectorale vereisten. Deze vereisten kunnen aanvullende netwerksegmentatie of toegangscontroles vereisen die worden ondersteund door geavanceerde NSG-configuraties, zoals het gebruik van Azure Firewall voor extra verkeersinspectie en filtering. Overweeg om compliance-experts te betrekken bij het ontwerp en de implementatie van NSG-configuraties om ervoor te zorgen dat alle toepasselijke vereisten worden nageleefd.

Remediatie

Gebruik PowerShell-script databricks-nsg-configured.ps1 (functie Invoke-Remediation) – Herstellen.

Wanneer een Azure Databricks-omgeving niet correct is geconfigureerd met Network Security Groups, of wanneer bestaande NSG-configuraties problemen veroorzaken, is het essentieel om een gestructureerde remediatieaanpak te volgen. Remediatie omvat het identificeren van configuratiefouten, het corrigeren van NSG-regels, en het valideren dat de gecorrigeerde configuratie correct functioneert zonder operationele verstoringen te veroorzaken. Een onjuiste remediatieaanpak kan leiden tot verdere operationele problemen of beveiligingslekken, daarom is het belangrijk om zorgvuldig te werk te gaan en elke stap te valideren.

De eerste stap in het remediatieproces is het identificeren van het specifieke probleem. Als clusters niet kunnen starten of blijven hangen in een Pending-status, wijst dit meestal op ontbrekende of onjuiste inbound regels die control plane-communicatie blokkeren. Als jobs falen met connectiviteitsfouten of timeouts, kan dit wijzen op ontbrekende outbound regels die vereiste Azure-services blokkeren. Gebruik NSG Flow Logs om te identificeren welk specifiek verkeer wordt geblokkeerd, en correleer dit met de foutmeldingen die u ziet in Databricks om de root cause te bepalen.

Voor het corrigeren van ontbrekende inbound regels moet u eerst verifiëren of de control plane-regel correct is geconfigureerd. Controleer of er een regel bestaat met prioriteit 100 die verkeer toestaat van de service tag 'AzureDatabricks' naar VirtualNetwork op poort 443. Als deze regel ontbreekt of onjuist is geconfigureerd, voeg deze dan toe of corrigeer de configuratie. Verifieer ook of de inter-cluster communicatieregel correct is geconfigureerd, omdat deze essentieel is voor distributed computing-operaties. Gebruik het bijgeleverde PowerShell-script om deze regels automatisch te configureren volgens de best practices.

Voor het corrigeren van ontbrekende outbound regels moet u verifiëren of alle vereiste outbound regels aanwezig zijn. Controleer of er regels bestaan voor outbound verkeer naar de AzureDatabricks service tag voor control plane-responses, naar Azure Storage voor DBFS-toegang, naar Azure SQL Database voor Hive metastore-toegang, en voor interne VNet-communicatie. Als een van deze regels ontbreekt, voeg deze dan toe met de juiste prioriteiten en configuraties. Gebruik regiospecifieke service tags waar mogelijk om de beveiligingsgranulariteit te verbeteren en cross-region data exfiltratie te voorkomen.

Wanneer u NSG-regels corrigeert, is het belangrijk om dit te doen tijdens een gepland onderhoudsvenster wanneer er geen actieve clusters draaien, of om eerst een testomgeving te gebruiken om de wijzigingen te valideren voordat u ze toepast op productie. Wijzigingen aan NSG-regels kunnen tijdelijke connectiviteitsproblemen veroorzaken, vooral wanneer regels worden toegevoegd of gewijzigd terwijl clusters actief zijn. Door de timing zorgvuldig te plannen, minimaliseert u de impact op gebruikers en voorkomt u operationele verstoringen.

Na het corrigeren van NSG-regels moet u uitgebreide validatietests uitvoeren om te verifiëren dat de remediatie succesvol is. Start een testcluster en verifieer dat deze succesvol opstart en de Running-status bereikt. Test notebook-connectiviteit om te verifiëren dat gebruikers toegang hebben tot alle benodigde resources. Voer testjobs uit om te verifiëren dat data-operaties correct functioneren. Controleer NSG Flow Logs om te bevestigen dat vereist verkeer wordt toegestaan en dat ongeautoriseerd verkeer wordt geblokkeerd zoals bedoeld.

Voor complexe remediatiescenario's waarbij meerdere configuratiefouten moeten worden gecorrigeerd, overweeg om de NSG-configuratie volledig opnieuw op te bouwen volgens de best practices zoals beschreven in de implementatiesectie. Dit kan een veiligere aanpak zijn dan het proberen te corrigeren van individuele regels, vooral wanneer de huidige configuratie sterk afwijkt van de aanbevolen configuratie. Maak eerst een backup van de huidige NSG-configuratie voordat u wijzigingen aanbrengt, zodat u indien nodig kunt terugkeren naar de vorige configuratie.

Documenteer alle remediatie-activiteiten, inclusief de geïdentificeerde problemen, de toegepaste oplossingen, en de validatieresultaten. Deze documentatie is waardevol voor toekomstige troubleshooting, compliance-audits, en voor het voorkomen van vergelijkbare problemen in de toekomst. Gebruik het bijgeleverde PowerShell-script voor geautomatiseerde remediatie, maar verifieer altijd handmatig dat de configuratie correct is en dat alle functionaliteit werkt zoals verwacht voordat u de remediatie als voltooid beschouwt.

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: Network Security Groups Configured for Subnets .DESCRIPTION CIS Azure Foundations Benchmark - Control 3.1.2 Controleert of Network Security Groups (NSGs) zijn geconfigureerd voor de Databricks subnets (private en public). NSGs zorgen voor netwerk segmentatie en toegangscontrole op netwerklaag. Waarom is deze control belangrijk? - Controle over inbound/outbound verkeer - Network segmentation en micro-segmentation - Defense in depth security strategie - Compliance met netwerk security vereisten .NOTES Filename: databricks-nsg-configured.ps1 Author: Nederlandse Baseline voor Veilige Cloud Version: 1.0 Related JSON: content/azure/analytics/databricks-nsg-configured.json CIS Control: 3.1.2 .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 Toont handmatige instructies voor NSG configuratie .PARAMETER Revert Draait wijzigingen terug (niet van toepassing) .EXAMPLE .\databricks-nsg-configured.ps1 Voert basis compliance check uit .EXAMPLE .\databricks-nsg-configured.ps1 -Monitoring Toont gedetailleerd compliance rapport #> # ============================================================================ # REQUIREMENTS # ============================================================================ #Requires -Version 5.1 #Requires -Modules Az.Accounts #Requires -Modules Az.Databricks #Requires -Modules Az.Network #Requires -Modules Az.Resources # ============================================================================ # PARAMETERS # ============================================================================ [CmdletBinding()] param( [Parameter()][switch]$WhatIf, [Parameter()][switch]$Monitoring, [Parameter()][switch]$Remediation, [Parameter()][switch]$Revert ) # ============================================================================ # GLOBAL VARIABLES # ============================================================================ $ErrorActionPreference = 'Stop' $VerbosePreference = 'Continue' $PolicyName = "Azure Databricks: NSG Configuration" # ============================================================================ # 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 aanbevolen voor NSG configuratie" -ForegroundColor Yellow Write-Host " NSGs verwijderen vermindert security posture" -ForegroundColor Yellow Write-Host " NSGs handmatig verwijderen via: Remove-AzNetworkSecurityGroup`n" -ForegroundColor Gray } 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 NSG configuratie hebben .DESCRIPTION Controleert alle Databricks workspaces met custom VNet en valideert of beide subnets (private en public) NSGs hebben geconfigureerd. .OUTPUTS PSCustomObject met compliance status en details #> Write-Verbose "Testing compliance for: $PolicyName..." $result = [PSCustomObject]@{ ScriptName = "databricks-nsg-configured" PolicyName = $PolicyName IsCompliant = $false TotalResources = 0 CompliantCount = 0 NonCompliantCount = 0 Details = @() Recommendations = @() } function Invoke-Revert { Write-Host "`n⚠️ Revert wordt niet aanbevolen voor NSG configuratie" -ForegroundColor Yellow Write-Host " NSGs verwijderen vermindert security posture" -ForegroundColor Yellow Write-Host " NSGs handmatig verwijderen via: Remove-AzNetworkSecurityGroup`n" -ForegroundColor Gray } 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 $hasNSG = $false $nsgInfo = "" # Check voor custom VNet (NSGs zijn alleen relevant bij custom VNet) if ($resourceDetails.Properties.parameters.customVirtualNetworkId) { $customVNetId = $resourceDetails.Properties.parameters.customVirtualNetworkId.value $privateSubnetName = $resourceDetails.Properties.parameters.customPrivateSubnetName.value $publicSubnetName = $resourceDetails.Properties.parameters.customPublicSubnetName.value if ($customVNetId -and $privateSubnetName -and $publicSubnetName) { # Parse VNet ID om resourcegroup en vnet naam te krijgen $vnetParts = $customVNetId -split '/' $vnetRgName = $vnetParts[4] $vnetName = $vnetParts[8] # Haal VNet en subnets op function Invoke-Revert { Write-Host "`n⚠️ Revert wordt niet aanbevolen voor NSG configuratie" -ForegroundColor Yellow Write-Host " NSGs verwijderen vermindert security posture" -ForegroundColor Yellow Write-Host " NSGs handmatig verwijderen via: Remove-AzNetworkSecurityGroup`n" -ForegroundColor Gray } try { $vnet = Get-AzVirtualNetwork -Name $vnetName -ResourceGroupName $vnetRgName -ErrorAction Stop $privateSubnet = $vnet.Subnets | Where-Object { $_.Name -eq $privateSubnetName } $publicSubnet = $vnet.Subnets | Where-Object { $_.Name -eq $publicSubnetName } $privateHasNSG = $privateSubnet.NetworkSecurityGroup -ne $null $publicHasNSG = $publicSubnet.NetworkSecurityGroup -ne $null if ($privateHasNSG -and $publicHasNSG) { $hasNSG = $true $privateNsgName = ($privateSubnet.NetworkSecurityGroup.Id -split '/')[-1] $publicNsgName = ($publicSubnet.NetworkSecurityGroup.Id -split '/')[-1] $nsgInfo = "Private NSG: $privateNsgName, Public NSG: $publicNsgName" } elseif ($privateHasNSG -or $publicHasNSG) { $nsgInfo = "Incomplete: " + $(if ($privateHasNSG) { "Private has NSG" } else { "Private missing NSG" }) + ", " + $(if ($publicHasNSG) { "Public has NSG" } else { "Public missing NSG" }) } } catch { $nsgInfo = "Could not verify NSG (VNet not accessible)" } } else { $nsgInfo = "No custom VNet (default managed VNet gebruikt)" } } else { $nsgInfo = "No custom VNet (default managed VNet gebruikt)" } if ($hasNSG) { # Workspace heeft NSGs op beide subnets $result.CompliantCount++ $result.Details += "✓ Workspace '$($workspace.Name)' heeft NSGs geconfigureerd ($nsgInfo)" } else { # Workspace mist NSGs $result.NonCompliantCount++ $result.Details += "✗ Workspace '$($workspace.Name)': $nsgInfo (ResourceGroup: $($workspace.ResourceGroupName))" if ($nsgInfo -like "*No custom VNet*") { $result.Recommendations += "Deploy workspace '$($workspace.Name)' in custom VNet met NSGs" } else { $result.Recommendations += "Configureer NSGs voor workspace '$($workspace.Name)' subnets" } } } # Bepaal overall compliance $result.IsCompliant = ($result.NonCompliantCount -eq 0) if ($result.NonCompliantCount -gt 0) { $result.Recommendations += "NSGs moeten minimaal Databricks service tag rules bevatten" $result.Recommendations += "Run met -Remediation voor gedetailleerde NSG configuratie instructies" } } catch { $result.Details += "ERROR: $($_.Exception.Message)" $result.Recommendations += "Controleer of Az.Network module is geïnstalleerd" $result.Recommendations += "Controleer of je voldoende rechten hebt op subscription en VNets" } return $result } # ============================================================================ # FUNCTION: Invoke-Remediation # ============================================================================ function Invoke-Remediation { <# .SYNOPSIS Toont handmatige instructies voor NSG configuratie .DESCRIPTION NSGs voor Databricks subnets vereisen specifieke rules en kunnen niet volledig automatisch worden geconfigureerd zonder risico. Dit script toont gedetailleerde configuratie instructies. #> Write-Host "`nStarting remediation for: $PolicyName..." -ForegroundColor Cyan Write-Host "=" * 80 -ForegroundColor Cyan Write-Host "`n⚠️ BELANGRIJKE OPMERKING:" -ForegroundColor Yellow Write-Host " NSG configuratie voor Databricks is complex en workspace-specifiek" -ForegroundColor Yellow Write-Host " Verkeerde regels kunnen workspace functionaliteit breken`n" -ForegroundColor Yellow Write-Host "`n📋 NSG CONFIGURATIE INSTRUCTIES:" -ForegroundColor Cyan Write-Host "=" * 80 -ForegroundColor Cyan Write-Host "`n1️⃣ MINIMALE VEREISTE NSG RULES:" -ForegroundColor White Write-Host "`n INBOUND RULES (voor beide subnets):" -ForegroundColor Cyan Write-Host " • Allow VirtualNetwork → VirtualNetwork (any port)" -ForegroundColor Gray Write-Host " • Allow AzureDatabricks service tag → VirtualNetwork (any port)" -ForegroundColor Gray Write-Host " • Deny All other inbound traffic" -ForegroundColor Gray Write-Host "`n OUTBOUND RULES (voor beide subnets):" -ForegroundColor Cyan Write-Host " • Allow VirtualNetwork → VirtualNetwork (any port)" -ForegroundColor Gray Write-Host " • Allow VirtualNetwork → AzureDatabricks (any port)" -ForegroundColor Gray Write-Host " • Allow VirtualNetwork → Sql service tag (port 3306)" -ForegroundColor Gray Write-Host " • Allow VirtualNetwork → Storage service tag (port 443)" -ForegroundColor Gray Write-Host " • Allow VirtualNetwork → AzureActiveDirectory (port 443)" -ForegroundColor Gray Write-Host " • Allow VirtualNetwork → Internet (any port) [voor workspace connectivity]" -ForegroundColor Gray Write-Host "`n2️⃣ POWERSHELL VOORBEELD VOOR NSG CREATIE:" -ForegroundColor White $nsgScript = @' # Maak nieuwe NSG aan $nsgName = "nsg-databricks-private" $rgName = "your-resource-group" $location = "westeurope" $nsg = New-AzNetworkSecurityGroup -Name $nsgName -ResourceGroupName $rgName -Location $location # Inbound rules $nsg | Add-AzNetworkSecurityRuleConfig -Name "Allow-VNet-Inbound" ` -Priority 100 -Direction Inbound -Access Allow ` -SourceAddressPrefix VirtualNetwork -SourcePortRange * ` -DestinationAddressPrefix VirtualNetwork -DestinationPortRange * ` -Protocol * $nsg | Add-AzNetworkSecurityRuleConfig -Name "Allow-Databricks-Control-Plane" ` -Priority 110 -Direction Inbound -Access Allow ` -SourceAddressPrefix AzureDatabricks -SourcePortRange * ` -DestinationAddressPrefix * -DestinationPortRange * ` -Protocol * # Outbound rules $nsg | Add-AzNetworkSecurityRuleConfig -Name "Allow-VNet-Outbound" ` -Priority 100 -Direction Outbound -Access Allow ` -SourceAddressPrefix VirtualNetwork -SourcePortRange * ` -DestinationAddressPrefix VirtualNetwork -DestinationPortRange * ` -Protocol * $nsg | Add-AzNetworkSecurityRuleConfig -Name "Allow-Databricks-Infrastructure" ` -Priority 110 -Direction Outbound -Access Allow ` -SourceAddressPrefix * -SourcePortRange * ` -DestinationAddressPrefix AzureDatabricks -DestinationPortRange * ` -Protocol * $nsg | Add-AzNetworkSecurityRuleConfig -Name "Allow-SQL" ` -Priority 120 -Direction Outbound -Access Allow ` -SourceAddressPrefix * -SourcePortRange * ` -DestinationAddressPrefix Sql -DestinationPortRange 3306 ` -Protocol Tcp $nsg | Add-AzNetworkSecurityRuleConfig -Name "Allow-Storage" ` -Priority 130 -Direction Outbound -Access Allow ` -SourceAddressPrefix * -SourcePortRange * ` -DestinationAddressPrefix Storage -DestinationPortRange 443 ` -Protocol Tcp $nsg | Add-AzNetworkSecurityRuleConfig -Name "Allow-AAD" ` -Priority 140 -Direction Outbound -Access Allow ` -SourceAddressPrefix * -SourcePortRange * ` -DestinationAddressPrefix AzureActiveDirectory -DestinationPortRange 443 ` -Protocol Tcp # Apply configuration $nsg | Set-AzNetworkSecurityGroup # Attach NSG to subnet $vnet = Get-AzVirtualNetwork -Name "your-vnet" -ResourceGroupName $rgName $subnet = Get-AzVirtualNetworkSubnetConfig -Name "databricks-private" -VirtualNetwork $vnet $subnet.NetworkSecurityGroup = $nsg $vnet | Set-AzVirtualNetwork '@ Write-Host $nsgScript -ForegroundColor DarkGray Write-Host "`n3️⃣ VALIDATIE:" -ForegroundColor White Write-Host " • Test workspace connectivity na NSG configuratie" -ForegroundColor Gray Write-Host " • Verifieer dat clusters kunnen starten" -ForegroundColor Gray Write-Host " • Check NSG flow logs voor denied traffic" -ForegroundColor Gray Write-Host " • Run dit script opnieuw met -Monitoring om compliance te controleren" -ForegroundColor Gray Write-Host "`n📚 DOCUMENTATIE:" -ForegroundColor Cyan Write-Host " Microsoft Docs: https://learn.microsoft.com/azure/databricks/security/network/classic/vnet-inject#network-security-groups" -ForegroundColor Blue Write-Host "`n⚠️ TEST ALTIJD IN NON-PROD VOORDAT JE PROD NSGs AANPAST!" -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 aanbevolen voor NSG configuratie" -ForegroundColor Yellow Write-Host " NSGs verwijderen vermindert security posture" -ForegroundColor Yellow Write-Host " NSGs handmatig verwijderen via: Remove-AzNetworkSecurityGroup`n" -ForegroundColor Gray } 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: NSG configuratie vereist handmatige setup" -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 hebben NSGs geconfigureerd" -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 configuratie instructies" -ForegroundColor Yellow } } } catch { Write-Error "An error occurred: $_" Write-Error $_.ScriptStackTrace exit 1 }

Risico zonder implementatie

Risico zonder implementatie
High: Onjuiste Network Security Group (NSG) configuratie voor Azure Databricks VNet Injection-subnets creëert een binaire faalmodus waarbij de workspace ofwel volledig niet-functioneel wordt (te restrictief) ofwel significante beveiligingsblootstelling heeft (te permissief) - beide scenario's zijn onacceptabel voor productieomgevingen. Te restrictieve NSG-regels die vereist Databricks-verkeer blokkeren resulteren in clusters die onbepaald in Pending-status blijven en nooit Running-status bereiken, jobs die falen met cryptische 'cluster unavailable' foutmeldingen zonder duidelijke oorzaak, workspace-beheeroperaties zoals cluster aanmaken/verwijderen die time-outs krijgen, en volledige bedrijfsimpact waarbij data engineers geen werk kunnen doen en analytics-pipelines stil liggen - probleemoplossing is complex omdat foutmeldingen vaak niet expliciet NSG-blokkades vermelden. Te permissieve NSG-regels creëren ernstige beveiligingsblootstellingen: onbeperkte uitgaande internetconnectiviteit maakt data exfiltratie mogelijk waarbij gecompromitteerde notebooks of kwaadaardige code gegevens kunnen exfiltreren naar externe command & control-servers, laterale beweging naar andere Azure-resources wordt mogelijk wanneer VNet-intern verkeer niet wordt beperkt, cryptomining-malware kan worden gedownload en uitgevoerd op Databricks-clusters waardoor enorme rekenkosten ontstaan, en compliance-overtredingen ontstaan omdat NIS2 Artikel 21 en BIO 13.01 netwerksegmentatie en minimale bevoegdheden netwerktoegang vereisen. Zonder NSG Flow Logs ontbreekt netwerkzichtbaarheid voor beveiligingsmonitoring waarbij verdachte verkeerspatronen zoals abnormale gegevensoverdrachten, verbindingen naar kwaadaardige IP-adressen, of ongebruikelijk poortgebruik ongedetecteerd blijven, forensisch onderzoek na beveiligingsincidenten onmogelijk is door ontbrekende netwerkverkeerslogs, en compliance-audits falen omdat netwerktoegangslogs niet kunnen worden geproduceerd. Het risico van onjuiste NSG-configuratie is KRITIEK omdat het directe operationele impact heeft (niet-werkende Databricks) of beveiligingsblootstelling creëert - er is geen middenweg. Deze maatregel vereist expertise in zowel Databricks-netwerkvereisten als Azure NSG beste praktijken - organisaties zonder deze expertise moeten Azure-consultants of Databricks-support betrekken voor NSG-ontwerpvalidatie vóór implementatie.

Management Samenvatting

Correcte Network Security Group (NSG) configuratie voor Azure Databricks VNet Injection-subnets is een precisie-engineering opgave die exact de juiste balans moet vinden tussen het mogelijk maken van vereiste Databricks-functionaliteit en het handhaven van strikte beveiligingsisolatie. NSG's moeten verplichte inkomende regels implementeren: TCP 443 VAN 'AzureDatabricks' service tag (beheerlaag-beheer), ALLES VAN VirtualNetwork (clusteronderling communicatie binnen subnets), en verplichte uitgaande regels: TCP 443 NAAR 'AzureDatabricks' (beheerlaag-responses), TCP 443 NAAR regiospecifieke 'Storage' service tag (DBFS backend), TCP 3306 NAAR regiospecifieke 'Sql' (Hive metastore), ALLES NAAR VirtualNetwork (tussen subnet verkeer), TCP 443 NAAR 'AzureActiveDirectory' (indien Azure AD-synchronisatie ingeschakeld). Optioneel maar aanbevolen uitgaand: Internettoegang voor PyPI/Maven package-installaties (kan worden geblokkeerd als private repositories worden gebruikt), 'AzureKeyVault' voor CMK-scenario's, 'AzureMonitor' voor diagnostische logging. Beveiligingsversterking implementeert: expliciete weigering van al het overige uitgaand naar Internet (waardoor verkeersinspectie via Azure Firewall wordt afgedwongen indien nodig), NSG Flow Logs naar Log Analytics voor netwerkverkeerszichtbaarheid en beveiligingsmonitoring, regiospecifieke service tags (Storage.WestEurope NIET generieke Storage) voor cross-region exfiltratiepreventie, kwartaal NSG-regel audits waarbij verweesde regels worden verwijderd. Deze maatregel is ABSOLUUT VERPLICHT voor ALLE Databricks VNet Injection-implementaties - zonder correcte NSG-configuratie werkt Databricks simpelweg niet OF heeft enorme beveiligingslekken. KRITIEK: Test NSG-regels grondig in ontwikkelomgeving vóór productie-implementatie - NSG-fouten in productie kunnen uren downtime veroorzaken tijdens probleemoplossing. Implementatie-inspanning: 3-4 uur voor basis NSG (regel aanmaak, testen, subnet-koppeling), additionele 3-5 uur voor geavanceerde versterking (Azure Firewall-integratie, flow log-analyse, beveiligingsmonitoring). Kosten: NSG gratis, Flow Logs €0,20-0,50/maand (verwaarloosbaar), optionele Azure Firewall €900-5.500/maand. Return on investment komt van: operationele Databricks-functionaliteit (kan niet werken zonder correcte NSG), beveiligingsisolatie die datalekken voorkomt, netwerkzichtbaarheid die bedreigingsdetectie mogelijk maakt, en compliance met NIS2/BIO netwerksegmentatievereisten. Veelvoorkomende fouten om te vermijden: Vergeten van AzureDatabricks service tag (clusters starten niet), Gebruik van generieke Storage/Sql tags in plaats van regiospecifieke (beveiligingslek), Blokkeren van VirtualNetwork naar VirtualNetwork verkeer (breekt clusters), Niet inschakelen van Flow Logs (blind voor netwerkaanvallen).