Isolierte Umgebung

Die Architektur der isolierten Umgebung erbt den Basisplan für die gehärtete Konnektivität und fügt zwei Anforderungen hinzu: zugriff auf private Arbeitsbereiche und eine erforderliche externe Firewall. Der Zugriff auf den Arbeitsbereich erfolgt ausschließlich über VPN oder einen eingehenden Private Link, niemals über das öffentliche Internet. Der gesamte klassische ausgehende Compute-Datenverkehr wird zur Inspektion und Durchsetzung von Richtlinien über die Firewall geleitet.

Diese Architektur hat:

• Vollständige Netzwerkisolation: Alle Datenverkehrsflüsse über private Verbindungen.
• Zugriff auf private Arbeitsbereiche: nur über VPN oder eingehenden Zugriff über Private Link. Der Arbeitsbereich ist aus dem öffentlichen Internet nicht erreichbar.
• Erforderliche Überprüfung des ausgehenden Datenverkehrs: Firewall-Inspektion des gesamten ausgehenden Datenverkehrs von Classic Compute.
• Verhinderung von Datenexfiltration: Steuerelemente auf Netzwerkebene blockieren nicht autorisierte Datenübertragungen.

Verwenden Sie diese Architektur in folgenden Fällen:

• Der Zugriff auf den Arbeitsbereich muss privat sein, etwa über VPN oder einen eingehenden Private Link.
• Umgang mit Daten in stark regulierten Branchen, z. B. Finanzdienstleistungen, Gesundheitswesen, Regierung.
• Compliance-Frameworks erfordern Kontrollen für ausgehenden Datenverkehr (z. B. SOC 2, HIPAA, PCI DSS und FedRAMP).
• Implementieren von Zero-Trust-Sicherheitsframeworks für Unternehmen.
• Die Verhinderung von Datenexfiltration ist eine Anforderung.

Voraussetzungen

• Azure Azure Databricks Premium-Stufe mit einem in VNet eingefügten Arbeitsbereich.

• Vorhandene VPN-Infrastruktur oder eingehende Private Link Konnektivität.
• Firewall oder virtuelle Netzwerkappliance (NVA).

Architekturübersicht

Die Architektur der isolierten Umgebung leitet den gesamten Datenverkehr über private Verbindungen mit Firewallüberprüfung weiter:

Datenverkehrstyp	Pfad
Benutzerzugriff	Benutzer → VPN oder eingehender privater Link → Workspace
Klassische Rechenleistung → Steuerung	Compute → Classic Private Link → Azure Databricks Steuerungsebene
Klassische Berechnung → Cloud	Berechnen → Dienstendpunkte oder UDRs → Azure-Dienste
Serverless → Ihre Ressourcen	Serverlose Berechnung → privaten NCC-Endpunkte → Ihre Azure-Ressourcen
Klassisches Compute → ausgehender Datenverkehr	Compute → Externe Firewall (erforderlich) → Überwachtes Internet

Erforderliche Komponenten

Inbound

Der Arbeitsbereich ist nur über private Verbindungen erreichbar: VPN, eingehender Private Link oder beides, abhängig von Ihrer bestehenden Infrastruktur. Kunden wählen in der Regel eins aus, anstatt sie zu stapeln.

Einstellungen für den privaten Zugriff (öffentlichen Zugriff deaktivieren)

Dies ist das Steuerelement, das den öffentlichen Zugriff tatsächlich blockiert. Ohne diese Konfiguration akzeptiert der Arbeitsbereich weiterhin Internetverkehr, selbst wenn Private Link konfiguriert ist. Private Link wird zu einem zusätzlichen Pfad, nicht zum einzigen Pfad.

Legen Sie die Public Network Access des Arbeitsbereichs auf Disabled im Azure-Portal fest. Dadurch wird der öffentliche Zugriff auf die Arbeitsbereichs-UI und APIs blockiert.

Arbeitsbereichseingangssteuerelemente

Konfigurieren Sie den Ingress für den Arbeitsbereich über kontextbasiertes Ingress (Context-Based Ingress, CBI), das empfohlene Framework für Ingress-Richtlinien. CBI-Regeln kombinieren Netzwerkquelle (IP-Bereiche), Identitäts-, Authentifizierungsmechanismus und Zugriffsbereich in einem einzigen Zulassungs-/Ablehnungsmodell, sodass das Netzwerkquell-Attribut den gleichen Auftrag wie das eigenständige IP-Zugriffslistenfeature und vieles mehr ausführt.

IP-Zugriffslisten werden weiterhin unterstützt und können zusammen mit CBI konfiguriert werden. Wenn beide konfiguriert sind, muss eine Anforderung von beiden Steuerelementen zugelassen werden.

Konfigurationsstufen:

• CBI-Richtlinien auf Kontoebene: Gilt für alle Arbeitsbereiche im Konto. Siehe Verwalten kontextbasierter Eingangsrichtlinien.
• IP-Zugriffslisten auf Arbeitsbereichsebene: Auf einen einzelnen Arbeitsbereich anwenden. Siehe Konfigurieren von IP-Zugriffslisten für Arbeitsbereiche.
• IP-Zugriffslisten auf Kontoebene: Auf die Kontokonsole anwenden. Siehe Konfigurieren von IP-Zugriffslisten für die Kontokonsole.

Bewährte Methoden:

• Beginnen Sie breit, verfeinern Sie basierend auf der tatsächlichen Nutzung.
• Dokumentieren Sie IP-Bereiche mit Zweck- und Ablaufdatum.
• Behalten Sie den Administratorzugriff über einen als sicher bekannten IP-Bereich bei.
• Überprüfen Sie die Bereiche vierteljährlich und entfernen Sie veraltete Bereiche.

Warning

Ingress-Richtlinien und IP-Zugriffslisten können Ihnen den Zugriff auf Ihren Arbeitsbereich verwehren, wenn sie falsch konfiguriert sind. Stellen Sie den Administratorzugang immer über einen als sicher bekannten IP-Bereich sicher.

Empfänger-Zugriffssteuerung für Delta Sharing

Delta Sharing verwendet eigene IP-Zugriffslisten, die auf Objekten der Empfänger konfiguriert sind. Dies ist getrennt von den IP-Zugriffslisten des Arbeitsbereichs und fällt nicht unter den kontextbasierten Ingress. Gilt nur für die offene Freigabe (Empfänger, die nicht Azure Databricks verwenden).

Weitere Informationen finden Sie unter Einschränken des Zugriffs von Delta Sharing-Empfangenden mithilfe von IP-Zugriffslisten (offene Freigabe).

Eingehende Verbindungen

Stellt eine private Konnektivität für den Benutzerzugriff auf die Arbeitsbereich-UI und die API her. Benutzer erreichen den Arbeitsbereich über VPN oder über eingehende Private Links, niemals über das öffentliche Internet.

Siehe Konfigurieren eingehender privater Verknüpfungen.

Benutzerdefiniertes DNS

Konfigurieren Sie privates DNS, um Azure Databricks Endpunkte in private IP-Adressen aufzulösen.

Azure erstellt beim Erstellen privater Endpunkte automatisch private DNS-Zonen.

Ausgehend

Serverlose Ausgangskontrollen (Netzwerkrichtlinien und private NCC-Endpunkte) werden von der Basislinie für die gehärtete Konnektivität geerbt. Diese Architektur macht die externe Firewall, die in Hardened optional ist, erforderlich für eine vollständige klassische Compute-Egress-Inspektion.

Externe Firewall (erforderlich)

Leiten Sie den gesamten ausgehenden Datenverkehr zur Überprüfung, Protokollierung und Durchsetzung von Richtlinien über eine Firewall weiter. Zu den Optionen gehören:

• Azure Firewall oder virtuelle Netzwerkappliances von Drittanbietern (NVAs).

Tip

Verwenden Sie Dienstendpunktrichtlinien für Azure Databricks Artefaktspeicher, um die Firewall zu umgehen, wodurch die Kosten für die Datenübertragung reduziert werden. Der Artefaktspeicher allein kann bis zu 11 GB pro Clusterknoten heruntergeladen werden.

Siehe IP-Adressen und Domänen für Azure Databricks Dienste und Ressourcen für die erforderlichen Azure Databricks Endpunkte, die Firewallregeln zulassen müssen.

Tip

Für maximale Sperrung sollten Sie ein privates Paket-Repository (z. B. JFrog Artifactory oder Sonatype Nexus) für Python-, R- und Maven-Pakete hosten. Dadurch wird die Notwendigkeit von Firewallregeln beseitigt, die den Zugriff auf öffentliche Paketindizes wie PyPI ermöglichen.

Warning

Azure Databricks Steuerebene und SCC-Relayverbindungen verwenden TLS mit Zertifikat-Pinning. Aktivieren Sie die TLS-Inspektion (entschlüsseln und erneut verschlüsseln) nicht für den Datenverkehr zwischen Ihren Clustern und der Azure Databricks Kontrollebene. Dies führt zu Clusterfehlern. Konfigurieren Sie Firewallregeln, um diese Verbindungen nach Ziel-FQDN oder IP ohne TLS-Abfangen zuzulassen. Siehe IP-Adressen und Domänen für Azure Databricks Dienste und Ressourcen für erforderliche Endpunkte.

Important

Falsch konfigurierte Firewallregeln können Azure Databricks Funktionen unterbrechen. Testen Sie gründlich in einer Nicht-Produktionsumgebung.

Schutz vor Datenexfiltration

Konfigurieren Sie Netzwerkrichtlinien und Firewallsteuerelemente, um nicht autorisierte Datenexfiltration zu verhindern:

• Serverlose Kontrolle des ausgehenden Datenverkehrs durch Netzwerkrichtlinien.
• Klassischer Computeausgang durch Firewall/NVA.
• Private Endpunktregeln für genehmigte Datenziele.

Informationen zum Implementierungsleitfaden finden Sie unter Datenexfiltrationsschutz .

Klassische Compute-Basis

Die klassische Compute-Basislinie wird von Verwaltete Sicherheit übernommen, und Cloud-Dienstendpunkte werden von Gehärtete Konnektivität übernommen. Für diese Architektur sind keine zusätzlichen klassischen Computekomponenten erforderlich.

Die Grundkonfiguration umfasst VNet-Integration, Secure Cluster Connectivity (SCC) und klassisches Private Link. Clouddienstendpunkte umfassen benutzerdefinierte Routen (UDRs), Dienstendpunkte und private Endpunkte für vom Kunden verwaltete Speicherkonten.

Methoden für den ausgehenden Datenzugriff

Es gibt zwei Ansätze für den Umgang mit ausgehendem Datenzugriff aus Computeressourcen:

• NAT-Gateway mit Firewall: Bereitstellen eines NAT-Gateways für ausgehende Konnektivität und Weiterleiten von Datenverkehr über eine Firewall zur Überprüfung. Dieser Ansatz ermöglicht den kontrollierten Zugriff auf externe Paketrepositorys und APIs und behält die Sichtbarkeit von Datenverkehrsmustern bei. Verwenden Sie diesen Ansatz, wenn Sie auf externe Ressourcen zugreifen müssen, aber Inspektionen und Protokollierungen erfordern.

• Kein NAT-Gateway (vollständig privat): Entfernen Sie das NAT-Gateway vollständig, um alle öffentlichen Kommunikationen aus Computeressourcen zu beseitigen. Der Datenzugriff erfolgt ausschließlich über private Endpunkte und VPC-Endpunkte. Dieser Ansatz hat die höchste Sicherheitsstufe, indem die Möglichkeit der Datenexfiltration durch öffentliche Ausgangspunkte entfernt wird. Verwenden Sie diesen Ansatz, wenn Ihre Organisation eine öffentliche Internetkommunikation von Computeressourcen verbietet.

Implementation

Gehen Sie von einer bereitgestellten gehärteten Konnektivität als Ausgangsbasis aus. In den folgenden Phasen wird der Zugriff auf den privaten Arbeitsbereich und die erforderliche externe Firewall hinzugefügt, die diese Architektur definiert.

Phase 1: Eingangskontrollen

1. Konfigurieren Sie Private Link für eingehenden Datenverkehr so, dass der Benutzerzugriff auf die Azure Azure Databricks-Benutzeroberfläche und APIs über private statt über öffentliche IP-Adressen geleitet wird. Siehe Konfigurieren eingehender privater Verknüpfungen.
2. Legen Sie die Public Network Access des Arbeitsbereichs auf Disabled im Azure-Portal fest. Das ist es, was den öffentlichen Zugriff tatsächlich blockiert. Ohne diese Einstellung akzeptiert der Arbeitsbereich weiterhin Internetverkehr, selbst wenn eingehender Private Link konfiguriert ist.
3. Testen Sie den Benutzerzugriff über VPN oder Private Link, um zu bestätigen, dass authentifizierte Benutzer den Arbeitsbereich nur über den privaten Netzwerkpfad erreichen können und dass der öffentliche Zugriff blockiert wird.

Phase 2: Externe Firewall (erforderlich)

1. Stellen Sie Azure Firewall oder eine virtuelle Netzwerk-Appliance (NVA) eines Drittanbieters in einem Hub-VNet bereit, und verbinden Sie das Arbeitsbereich-VNet mit VNet-Peering oder einem virtuellen Hub.
2. Konfigurieren Sie benutzerdefinierte Routen (UDRs) in den Subnetzen des Arbeitsbereichs mit einer Standardroute zur Firewall, sodass ausgehender Datenverkehr von Azure Databricks-Compute über die Hub-Firewall geleitet wird. Siehe Benutzerdefinierte Routeneinstellungen für Azure Databricks.
3. Konfigurieren Sie Azure Firewall Anwendungs- und Netzwerkregeln so, dass nur erforderliche Azure Databricks Endpunkte zulässig sind (siehe IP-Adressen und Domänen für Azure Databricks Dienste und Ressourcen) ohne TLS-Abfangen auf Kontrollebene und SCC-Relaydatenverkehr.

Phase 3: Validierung

1. Überprüfen Sie die Egress-Steuerung, indem Sie die Azure Firewall-Protokolle und Diagnosedaten auswerten, um sicherzustellen, dass der Azure Databricks-Datenverkehr gemäß der Richtlinie überprüft und eingeschränkt wird.
2. Vergewissern Sie sich, dass den Clusterknoten oder anderen von Azure Databricks verwalteten Computeressourcen im VNet des Arbeitsbereichs keine öffentlichen IP-Adressen zugewiesen sind.
3. Überprüfen Sie, ob der gesamte Steuerungs-, Daten- und eingehende Datenverkehr wie vorgesehen über die konfigurierten Private-Link-Endpunkte und die Hub-Firewall geleitet wird.

Die Azure Databricks Terraform SRA bietet Vorlagen für Infrastructure as Code als Ausgangspunkt für dieses Bereitstellungsmuster.

Validation

Führen Sie nach der Bereitstellung der Architektur die folgenden Überprüfungen aus, um zu bestätigen, dass vollständige Netzwerkisolation, private Konnektivität und Ausgangssteuerelemente wie konfiguriert funktionieren.

Prüfen	Erwartetes Ergebnis
Über VPN zugänglicher Arbeitsbereich	Yes
Arbeitsbereich ohne VPN zugänglich	No
Cluster starten mit SCC	Ja, keine öffentlichen IPs
Datenzugriff über private Verbindungen	Yes
Ausstieg ohne Firewallgenehmigung blockiert	Yes
DNS wird zu privaten IPs aufgelöst	Yes

Troubleshooting

Wenn eine Validierungsprüfung fehlschlägt oder eine Workload keine Verbindung zu einem erforderlichen Endpunkt herstellen kann, verwenden Sie die nachstehende cloudspezifische Tabelle, um häufige Probleme zu diagnostizieren.

Issue	Ursache	Resolution
Cluster lässt sich nicht starten	Firewallblockierung erforderlicher Endpunkte oder falsch konfigurierter privater Endpunkte für SCC, Azure Databricks Steuerungsebene oder Speicherkonten (NSG-Regeln, Routing)	Überprüfen Sie Firewallprotokolle, und fügen Sie Azure Databricks Infrastrukturregeln hinzu; überprüfen Sie, ob private Endpunkt-NSG-Regeln Datenverkehr von Clustersubnetzen zulassen; überprüfen Sie UDRs.
DNS-Auflösung schlägt fehl	Privates DNS falsch konfiguriert	Überprüfen privater DNS-Zonen und VNet-Links
Speicherzugriff schlägt fehl	Problem mit privatem Endpunkt oder Routing	Überprüfen der Konfiguration privater Endpunkte und Routentabellen
Paketinstallation schlägt fehl	PyPI blockiert durch Firewall	Hinzufügen von PyPI zur Firewall-Zulassungsliste

Fortlaufende Wartung

• Firewall-Regeln: Überprüfen und aktualisieren Sie die Zulassungslisten für ausgehenden Datenverkehr regelmäßig.
• DNS-Verwaltung: Aktualisieren von Einträgen beim Hinzufügen von Arbeitsbereichen.
• Endpunktüberwachung: Status und Datenübertragungskosten privater Endpunkte überwachen.
• Netzwerkrichtlinien: Fügen Sie private Endpunkte für neue genehmigte Datenquellen hinzu.
• Firewall entfernen: Wenn der Betriebsaufwand der Firewall zu hoch ist oder die Compliance-Anforderungen gelockert werden, können Sie die Firewall-Komponente entfernen und die private Konnektivität sowie den VPN-Zugriff beibehalten.
• Downgrade auf gehärtete Konnektivität: Wenn der Zugriff auf private Arbeitsbereiche zu einer Produktivitätsbarriere wird.

Nächste Schritte

Ressource	Description
Schutz vor Datenexfiltration	Detaillierte Referenzarchitektur für die Kombination von Netzwerk- und Unity-Katalog-Steuerelementen zur Verhinderung von Datenexfiltration.
Vernetzung	Netzwerkoptionen und -konzepte für Azure Databricks.