von Bhavin Kukadia, Abhinav Garg und Michal Marusan
Azure Databricks ist eine Unified Data Analytics Platform, die Teil der Microsoft Azure Cloud ist. Azure Databricks basiert auf Delta Lake, MLFlow, Koalas und Apache Spark. Es ist ein First-Party-Service in der Microsoft Azure Cloud, der eine Ein-Klick-Einrichtung, native Integrationen mit anderen Azure-Diensten, eine interaktive Arbeitsumgebung und unternehmensweite Sicherheit bietet, um Data & AI-Anwendungsfälle für kleine bis große globale Kunden zu unterstützen. Die Plattform ermöglicht die echte Zusammenarbeit zwischen verschiedenen Datenexperten in jedem Unternehmen, wie z. B. Data Engineers, Data Scientists, Data Analysts und SecOps / Cloud Engineering.
In diesem Blogbeitrag, dem ersten einer zweiteiligen Serie, geben wir einen Überblick über die Azure Databricks-Architektur und wie Kunden sich sicher mit ihren selbst verwalteten Instanzen von Azure-Datendiensten verbinden können.
Azure Databricks ist eine verwaltete Anwendung in der Azure Cloud. Auf hoher Ebene besteht die Architektur aus einer Steuerungs-/Verwaltungsebene und einer Datenebene. Die Steuerungsebene befindet sich in einem von Microsoft verwalteten Abonnement und beherbergt Dienste wie die Webanwendung, den Cluster-Manager, den Job-Service usw. In der Standardbereitstellung ist die Datenebene eine vollständig verwaltete Komponente im Abonnement des Kunden, die ein VNET, eine NSG und ein Stamm-Speicherkonto, bekannt als DBFS, umfasst.
Die Datenebene kann auch in einem vom Kunden verwalteten VNET bereitgestellt werden, damit SecOps- und Cloud-Engineering-Teams die Sicherheits- und Netzwerkarchitektur für den Dienst gemäß ihren Unternehmensrichtlinien erstellen können. Diese Funktion wird als Bring Your Own VNET oder VNET Injection bezeichnet. Die Abbildung zeigt eine repräsentative Ansicht einer solchen Kundenarchitektur.
Unternehmenssicherheit ist ein Kernprinzip beim Erstellen von Software sowohl bei Databricks als auch bei Microsoft und wird daher in Azure Databricks als erstklassiger Bürger betrachtet. Im Kontext dieses Blogbeitrags bezieht sich sichere Konnektivität darauf, sicherzustellen, dass der Datenverkehr von Azure Databricks zu Azure-Datendiensten auf dem Azure-Netzwerk-Backbone verbleibt, mit der inhärenten Fähigkeit, Azure Databricks als erlaubte Quelle zu whitelisten. Als Sicherheitsempfehlung empfehlen wir einige Optionen, mit denen Kunden einen solchen Datenzugriffsmechanismus zu Azure-Datendiensten wie Azure Blob Storage, Azure Data Lake Store Gen2, Azure Synapse Data Warehouse, Azure CosmosDB usw. einrichten können. Lesen Sie weiter für eine Diskussion über Azure Private Link und Service Endpoints.
Der sicherste Weg, auf Azure-Datendienste von Azure Databricks aus zuzugreifen, ist die Konfiguration von Private Link. Laut Azure-Dokumentation ermöglicht Private Link den Zugriff auf Azure PaaS-Dienste (z. B. Azure Storage, Azure Cosmos DB und SQL Database) und auf Azure gehostete Kunden-/Partnerdienste über einen Private Endpoint in Ihrem virtuellen Netzwerk. Der Datenverkehr zwischen Ihrem virtuellen Netzwerk und dem Dienst wird über den Microsoft-Netzwerk-Backbone geleitet, wodurch die Exposition gegenüber dem öffentlichen Internet entfällt. Sie können auch Ihren eigenen Private Link Service in Ihrem virtuellen Netzwerk (VNet) erstellen und ihn privat an Ihre Kunden liefern. Das Einrichtungs- und Verbrauchserlebnis mit Azure Private Link ist für Azure PaaS-, kunden- und partnergehostete Dienste konsistent. Weitere Details finden Sie hier.
Sehen Sie unten, wie Azure Databricks und Private Link zusammen verwendet werden könnten.
Azure Databricks und Azure Data Service Private Endpoints in separaten VNETs
Azure Databricks und Azure Data Service Private Endpoints im selben VNET
Bitte beachten Sie Folgendes, bevor Sie den Private Endpoint implementieren:
Ein Beispiel, wo Private Link verwendet werden könnte, ist, wenn ein Kunde neben Azure Databricks einige Azure-Datendienste in der Produktion verwendet, wie Blob Storage, ADLS Gen2, SQL DB usw. Das Unternehmen möchte, dass die Benutzer die maskierten aggregierten Daten aus ADLS Gen2 abfragen, ihnen aber den Zugriff auf die unmaskierten vertraulichen Daten in anderen Datenquellen verweigern. In diesem Fall könnte ein Private Endpoint nur für den ADLS Gen2-Dienst unter Verwendung einer der oben genannten Unteroptionen eingerichtet werden.
So könnte eine solche Umgebung konfiguriert werden:
1 - Private Link für ADLS Gen2 einrichten
2 - Azure Databricks in Ihrem VNET bereitstellen
Bitte beachten Sie, dass es möglich ist, mehr als einen Private Link pro Azure-Datendienst zu konfigurieren, was Ihnen ermöglicht, eine Architektur zu erstellen, die Ihren Unternehmensrichtlinien entspricht.
Laut Azure-Dokumentation erweitern Virtual Network (VNET) Service Endpoints den privaten Adressraum Ihres virtuellen Netzwerks. Die Endpunkte erweitern auch die Identität Ihres VNet zu den Azure-Diensten über eine direkte Verbindung. Endpunkte ermöglichen es Ihnen, Ihre kritischen Azure-Dienstressourcen nur auf Ihre virtuellen Netzwerke zu beschränken. Der Datenverkehr von Ihrem VNet zu den Azure-Diensten verbleibt immer auf dem Microsoft Azure-Netzwerk-Backbone.
Verbesserte Sicherheit für Ihre Azure-Dienst-Ressourcen
Private Adressräume für verschiedene virtuelle Netzwerke können sich überschneiden. Sie können keinen überlappenden Netzwerbraum verwenden, um Datenverkehr, der aus einem bestimmten VNET stammt, eindeutig zu identifizieren. Sobald Service-Endpunkte für die Subnetze in Ihrem VNET aktiviert sind, können Sie eine virtuelle Netzwerks-Firewallregel hinzufügen, um die Azure-Datendienste zu sichern, indem Sie Ihre VNET-Identität auf diese Ressourcen erweitern. Eine solche Konfiguration hilft, den öffentlichen Zugriff auf diese Ressourcen zu entfernen und den Datenverkehr nur aus Ihrem VNET zuzulassen.
Optimale Weiterleitung für Azure-Datendienstdatenverkehr aus Ihrem virtuellen Netzwerk
Derzeit werden alle Routen in Ihrem VNET, die verwendet werden, um öffentlichen Netzwerkverkehr über Ihre Cloud/On-Premises-basierten virtuellen Appliances zu leiten, auch für den Azure-Datendienstdatenverkehr verwendet. Service-Endpunkte bieten eine optimale Weiterleitung für Azure-Datenverkehr.
Datenverkehr im Azure-Netzwerk-Backbone halten
Service-Endpunkte leiten Azure-Datendienstdatenverkehr immer direkt von Ihrem VNET zur Ressource im Microsoft Azure-Netzwerk-Backbone. Wenn der Datenverkehr im Azure-Netzwerk-Backbone verbleibt, können Sie ausgehenden Internetverkehr von Ihren virtuellen Netzwerken über Forced Tunneling weiterhin überwachen und auditieren, ohne den Datendienstdatenverkehr zu beeinträchtigen. Weitere Informationen zu benutzerdefinierten Routen und Forced Tunneling finden Sie unter Azure Virtual Network Traffic Routing.
Einfach einzurichten ohne Verwaltungsaufwand
Sie benötigen keine reservierten, öffentlichen IP-Adressen mehr in Ihren virtuellen Netzwerken, um Azure-Datendienstressourcen über eine IP-Firewall zu sichern. Es sind keine Network Address Translation (NAT) oder Gateway-Geräte erforderlich, um die Service-Endpunkte einzurichten. Sie können Service-Endpunkte über eine einfache Einrichtung für ein Subnetz konfigurieren. Es gibt keinen zusätzlichen Aufwand für die Wartung der Endpunkte.
Azure Service Endpoint mit Azure Databricks
Bitte beachten Sie Folgendes, bevor Sie die Service-Endpunkte implementieren:
Nehmen wir dasselbe Beispiel wie oben für Private Link und wie es mit Service Endpoints aussehen könnte. In diesem Fall könnte der Azure Storage Service Endpoint für Azure Databricks-Subnetze konfiguriert werden und dieselben Subnetze könnten dann in den ADLS Gen2-Firewallregeln auf die Whitelist gesetzt werden.
So könnte eine solche Umgebung konfiguriert werden:
1 - Service Endpoint für ADLS Gen2 einrichten
2 - Azure Databricks in Ihrem VNET bereitstellen
3 - IP-Firewallregeln für ADLS Gen2 konfigurieren
Wir haben einige Optionen besprochen, um sicher auf Azure-Datendienste von Ihrer Azure Databricks-Umgebung aus zuzugreifen. Basierend auf Ihren geschäftsspezifischen Anforderungen können Sie entweder Azure Private Link oder Virtual Network Service Endpoints verwenden. Sobald der Netzwerkverbindungsansatz finalisiert ist, können Sie sichere Authentifizierungsansätze nutzen, um sich mit diesen Ressourcen zu verbinden:
Im nächsten Blog dieser Reihe werden wir uns eingehend damit befassen, wie man eine gut abgesicherte Umgebung einrichtet, um Datenexfiltration zu verhindern (mit anderen Worten, eine Data Loss Prevention-Architektur implementieren). Sie würde eine Mischung aus den oben diskutierten Optionen und Azure Firewall verwenden. Bitte wenden Sie sich bei Fragen an Ihre Microsoft- oder Databricks-Account-Teams.
(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag
Abonnieren Sie unseren Blog und erhalten Sie die neuesten Beiträge direkt in Ihren Posteingang.