Abgesicherte Konnektivität

Die abgesicherte Konnektivität baut auf verwalteten Sicherheitsfunktionen auf und ergänzt diese um mehrschichtige Ingress- und Egress-Kontrollen: kontextbasiertes Ingress (CBI), VPC-Endpunkte, serverlose Egress-Kontrollen und eine optionale externe Firewall. Der Zugriff auf den Arbeitsbereich erfolgt weiterhin über das öffentliche Internet und ist durch CBI abgesichert.

Diese Architektur hat:

  • Kontextbasierter Zugriff auf den Arbeitsbereich: Benutzer melden sich über das Internet an, und CBI-Richtlinien beschränken den Arbeitsbereichszugriff nach Netzwerkquelle, Identität, Authentifizierungsmechanismus und Zugriffsbereich. Dies ist ein Kompromiss zugunsten der Einfachheit im Vergleich zu VPN-gestützten Architekturen.
  • Zugriff auf private Cloud-Dienste: VPC-Endpunkte (AWS) oder Serviceendpunkte (Azure) halten den Datenverkehr zu Cloud-Diensten vom öffentlichen Internet fern.
  • Serverlose Ausgangssteuerung: Netzwerkrichtlinien und private NCC-Endpunkte steuern ausgehenden Datenverkehr von serverloser Berechnung.
  • Optionale Eingangsüberprüfung: Stellen Sie eine externe Firewall bereit, um den klassischen Computeausgang zu prüfen und zu protokollieren.
  • Kein VPN erforderlich: Vereinfachter Benutzerzugriff ohne Unternehmensnetzwerkabhängigkeit.

Verwenden Sie diese Architektur in folgenden Fällen:

  • Die Datensicherheit ist das Hauptanliegen, nicht die Arbeitsbereichszugriffskontrolle.
  • DIE VPN-Komplexität ist eine Barriere für die Produktivität der Benutzer.
  • IP-basierte Zugriffssteuerungen sind für die Compliance ausreichend.
  • Ihre Organisation bevorzugt Cloud-first-Zugriffsmuster.

Voraussetzungen

  • Azure Azure Databricks Premium-Stufe mit einem in VNet eingefügten Arbeitsbereich.
  • Liste der IP-Bereiche für die Arbeitsbereichszugriffskontrolle.

Architekturübersicht

Die gehärtete Konnektivitätsarchitektur sichert den Netzwerkdatenverkehr und vereinfacht den Benutzerzugriff:

Datenverkehrstyp Pfad
Benutzerzugriff Benutzer → Internet → CBI-Richtlinie → Arbeitsbereich
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 Recheninstanz → Externe Firewall (optional) → Geprüftes Internet

Note

Der Arbeitsbereichszugriff ist in dieser Architektur nicht privat. Benutzer stellen eine Verbindung über das öffentliche Internet her, eingeschränkt durch CBI-Richtlinien. Wenn Ihre Organisation zugriff auf private Arbeitsbereiche benötigt, verwenden Sie stattdessen die Architektur der isolierten Umgebung .

Erforderliche Komponenten

Inbound

Kein eingehender Private Link. Der zugriff auf öffentliches Internet ist durch kontextbasierte Eingangsrichtlinien und optional durch IP-Zugriffslisten eingeschränkt. Befolgen Sie die Standard-IAM für die Authentifizierung. Siehe Authentifizierung und Zugriffssteuerung.

Symbol Arbeitsbereichseingangssteuerelemente

Konfigurieren Sie den Dateneingang für den Arbeitsbereich mithilfe der kontextbasierten Zugangskontrolle (CBI), dem empfohlenen Framework für Richtlinien für den Dateneingang. 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:

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.

Symbol OpenSharing-Empfängerzugriffssteuerung

OpenSharing verwendet eigene IP-Zugriffslisten, die für Empfängerobjekte konfiguriert sind. Dies unterscheidet sich von kontextbasierten Eingangs- und Arbeitsbereichs-IP-Zugriffslisten. Gilt nur für Databricks-zu-Open Sharing (Azure Databricks-fremde Empfänger).

Siehe Einschränken des OpenSharing-Empfängerzugriffs mithilfe von IP-Zugriffslisten (Databricks-to-Open Sharing)

Ausgehend

Der serverlose Ausgang unterliegt Netzwerkrichtlinien und privaten NCC-Endpunkten. Verwenden Sie Unity Catalog für die Datengovernance des ausgehenden Datenzugriffs. Siehe Was ist Unity Catalog?.

Filtersymbol. Serverlose Kontrolle des ausgehenden Datenverkehrs

Konfigurieren Sie Netzwerkrichtlinien, um serverlosen ausgehenden Datenverkehr zu steuern. Definieren zulässiger Ziele mithilfe von IP-Bereichen oder FQDNs.

Siehe Was ist serverlose Ausgangskontrolle?

Symbol Serverlose Private Link (private NCC-Endpunkte)

Stellt über Private Link private Konnektivität von serverlosem Compute zu Ihren Ressourcen bereit. Serverloser Datenverkehr bleibt außerhalb des öffentlichen Internets.

Weitere Informationen finden Sie unter Private Konnektivität zu Azure-Ressourcen konfigurieren.

Klassische Compute-Basis

Die klassische Compute-Basislinie wird von Managed security übernommen. Es sind keine zusätzlichen Basiskomponenten erforderlich, aber Sie können optional eine externe Firewall hinzufügen, um den ausgehenden Datenverkehr von Classic Compute zu überprüfen.

Die Grundkonfiguration umfasst VNet-Integration, Secure Cluster Connectivity (SCC) und klassisches Private Link.

Note

Diese Architektur verwendet keine eingehenden Private Link. Benutzer greifen über das öffentliche Internet auf den Arbeitsbereich zu, gesteuert durch CBI-Richtlinien. Wenn Ihre Organisation Zugriff auf private Arbeitsbereiche benötigt, siehe die Architektur der isolierten Umgebung, die eingehenden Zugriff über Private Link oder durch VPN geschützten Zugriff hinzufügt.

Symbol Klassische Berechnungsebene Private Link

Stellt eine private Konnektivität zwischen Ihrem VNet und der Azure Databricks Steuerebene bereit. REST-API und SCC-Relaydatenverkehr zwischen Clustern und der Kontrollebene bleiben privat, anstatt das öffentliche Internet zu verwenden.

Siehe Konfigurieren der privaten Konnektivität der klassischen Compute-Ebene für Azure Databricks.

Symbol Benutzerdefinierte Routen

Konfigurieren Sie das Routing für den Zugriff auf Clouddienste, um den Datenverkehr privat zu halten und Kosten zu senken.

Konfigurieren Sie UDRs mit Diensttags für Azure Dienste. Siehe Benutzerdefinierte Routeneinstellungen für Azure Databricks.

Schild-Symbol. Externe Firewall für klassische Recheninstanzen (optional)

Leiten Sie den ausgehenden Datenverkehr (klassisches Compute) über eine externe Firewall, um ihn zu überprüfen, zu protokollieren und Richtlinien durchzusetzen. Erforderlich in isolierter Umgebung; optional hier.

Zu den Optionen gehören Azure Firewall oder eine virtuelle Drittanbieter-Appliance (Network Virtual Appliance, NVA).

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. Siehe IP-Adressen und Domänen für Azure Databricks Dienste und Ressourcen für erforderliche Endpunkte.

Implementation

Beginnen Sie mit einer bereitgestellten Baseline für verwaltete Sicherheit. In den folgenden Phasen werden die Eingangs- und Ausgangssteuerelemente hinzugefügt, die diese Architektur definieren.

Phase 1: Zugriffskontrolle für eingehenden Zugriff

Konfigurieren von kontextbasierten Eingangsrichtlinien

Konfigurieren Sie kontextbasierte Eingangsrichtlinien auf Kontoebene (CBI), um den Arbeitsbereichszugriff nach Netzwerkquelle, Identität, Authentifizierungsmechanismus und Zugriffsbereich einzuschränken. Siehe kontextbasiertes Eingangssteuerelement und Verwalten kontextbasierter Eingangsrichtlinien.

Konfigurieren von IP-Zugriffslisten auf Arbeitsbereichsebene (optional)

Konfigurieren Sie optional IP-Zugriffslisten auf Arbeitsbereichsebene zusammen mit CBI für Abwärtskompatibilität oder Außerkraftsetzungen pro Arbeitsbereich. Wenn beide konfiguriert sind, muss eine Anfrage von beiden zugelassen werden. Siehe Konfigurieren von IP-Zugriffslisten für Arbeitsbereiche.

Konfigurieren von IP-Zugriffslisten auf Kontoebene

Konfigurieren Sie IP-Zugriffslisten auf Kontoebene, um den Zugriff auf die Kontokonsole zu steuern. Siehe Konfigurieren von IP-Zugriffslisten für die Kontokonsole.

Konfigurieren von IP-Zugriffslisten auf Empfängerebene

Wenn Sie OpenSharing Databricks-zu-Open Sharing verwenden, konfigurieren Sie IP-Zugriffslisten auf Empfängerebene für jeden Freigabeempfänger. Siehe Einschränken des OpenSharing-Empfängerzugriffs mithilfe von IP-Zugriffslisten (Databricks-to-Open Sharing)

Konfigurierte IP-Bereiche des Dokuments

Verwalten Sie die Dokumentation für alle konfigurierten IP-Bereiche, einschließlich Begründung, verknüpfter Tickets und geplanter Überprüfungsdaten.

Überprüfen des Zugriffsverhaltens

Überprüfen Sie das Zugriffsverhalten, indem Sie die Anmeldung aus genehmigten IP-Bereichen testen und bestätigen, dass Verbindungen von nicht genehmigten IP-Bereichen blockiert werden.

Phase 2: Clouddienstendpunkte

Konfigurieren von benutzerdefinierten Routen

Konfigurieren Sie benutzerdefinierte Routen (USER-Defined Routes, UDRs) mithilfe Azure Diensttags, sodass Datenverkehr zu Azure Diensten Ihren gewünschten privaten oder kontrollierten Ausgangspunkten folgt. Siehe Benutzerdefinierte Routeneinstellungen für Azure Databricks.

Konfigurieren von Dienstendpunkten oder privaten Endpunkten für den Speicher

Konfigurieren Sie Dienstendpunkte oder private Endpunkte für vom Kunden verwaltete Azure Speicherkonten nach Bedarf.

Phase 3: Serverlose Ausgangssteuerelemente

Konfigurieren von Serverlosen Netzwerkrichtlinien

Konfigurieren Sie serverlose Netzwerkrichtlinien, um serverlosen ausgehenden Datenverkehr auf genehmigte Ziele mithilfe von IP-Bereichen oder FQDNs einzuschränken. Siehe Was ist serverlose Ausgangskontrolle?

Konfigurieren privater NCC-Endpunkte

Konfigurieren Sie private NCC-Endpunkte für private Konnektivität von serverlosem Compute zu Ihren Azure Ressourcen. Weitere Informationen finden Sie unter Private Konnektivität zu Azure-Ressourcen konfigurieren.

Serverlosen ausgehenden Datenverkehr testen

Testen Sie, ob Serverless-Workloads genehmigte Ziele erreichen können und daran gehindert werden, nicht genehmigte Ziele zu erreichen.

Phase 4 (optional): Externe Firewall für klassische Rechenressourcen

Bereitstellen einer externen Firewall

Stellen Sie Azure Firewall oder eine virtuelle Netzwerk-Appliance (NVA) eines Drittanbieters in einem Hub-VNet bereit, und peeren Sie sie mit dem Arbeitsbereich-VNet.

Ausgangsdatenverkehr mit UDRs durch die Firewall weiterleiten

Konfigurieren Sie UDRs in den Arbeitsbereichssubnetzen mit einer Standardroute zur Firewall.

Konfigurieren von Firewallregeln ohne TLS-Abfangen

Konfigurieren Sie Firewallregeln, um erforderliche Azure Databricks-Endpunkte ohne TLS-Abfang auf der Steuerungsebene und im SCC-Relay-Datenverkehr zuzulassen.

Der Azure Databricks Terraform SRA stellt Infrastruktur-as-Code-Vorlagen bereit, die diese Bereitstellung automatisieren.

Validierung

Führen Sie nach der Bereitstellung der Architektur die folgenden Überprüfungen aus, um zu bestätigen, dass der datenverkehr der klassische Computeebene privat bleibt und dass Ihre IP-Zugriffsliste den Arbeitsbereichszugriff wie konfiguriert einschränkt.

Prüfen Erwartetes Ergebnis
Arbeitsbereich, auf den über zulässige IPs zugegriffen werden kann Yes
Arbeitsbereich, der von nicht autorisierten IPs blockiert wurde Yes
Cluster starten mit SCC Ja, keine öffentlichen IPs
Datenzugriff über private Verbindungen Yes
Paketinstallation mittels privatem Artefakt-Repository Yes

Troubleshooting

Wenn eine Überprüfung fehlschlägt oder sich eine Workload unerwartet verhält, verwenden Sie die folgende Tabelle, um häufige Probleme zu diagnostizieren.

Issue Ursache Lösung
Zugriff auf den Arbeitsbereich nicht möglich IP nicht in der Zugriffsliste IP-Adresse zur Arbeitsbereichsliste hinzufügen
Cluster lässt sich nicht starten Fehlkonfiguration von Routing oder Endpunkt Überprüfen von Routentabellen und privater Endpunktkonnektivität
S3/ADLS-Zugriff schlägt fehl Problem mit dem VPC-Endpunkt oder dem Routing Überprüfen Sie die Endpunktkonfiguration und die Sicherheitsgruppen.
Paketinstallation schlägt fehl Privates Artefaktrepository nicht erreichbar Überprüfen Sie die VNet-Endpunktkonfiguration und die DNS-Auflösung für Ihr Artefakt-Repository.
Zeitweilige Zugriffsprobleme Dynamische IP-Adressen Verwenden von VPN mit statischem Ausgangs-IP oder Verbreiterung von IP-Bereichen

Fortlaufende Wartung

  • Verwaltung von IP-Zugriffslisten: Monatlich überprüfen, neue Speicherorte hinzufügen, veraltete Bereiche entfernen.
  • Endpunktüberwachung: Status und Datenübertragungskosten privater Endpunkte überwachen.
  • Verwaltung von Artefakt-Repositories: Private Paketspiegel verwalten und die Verfügbarkeit überwachen.
  • Benutzerunterstützung: Verwalten des Prozesses für IP-Zugriffsprobleme.

Vorherige und nächste Schritte

Architecture Wann wählen
Verwaltete Sicherheit Vorheriger Schritt. Wenn IP-basierte Zugriffssteuerungen, VPC-Endpunkte und serverlose Egress-Kontrollen mehr sind, als Ihre Workloads benötigen. Die Basiskonfiguration umfasst ein kundenseitig verwaltetes VNet und SCC sowie optional klassischen Private Link.
Isolierte Umgebung Nächster Schritt. Wenn die IP-basierte Zugriffssteuerung nicht ausreichend ist, erfordern Vorschriften den Zugriff auf private Arbeitsbereiche oder die Einhaltung der Datenexfiltrationsverhinderung.
  • Last updated on