Sicherheits-Best-Practices für Delta Sharing

 

Das Data Lakehouse hat es uns ermöglicht, unsere Datenmanagement-Architekturen zu konsolidieren, Silos zu eliminieren und eine gemeinsame Plattform für alle Anwendungsfälle zu nutzen. Die Vereinigung von Data Warehousing und KI-Anwendungsfällen auf einer einzigen Plattform ist ein großer Fortschritt für Organisationen, aber sobald dieser Schritt getan ist, stellt sich die nächste Frage: „Wie teilen wir diese Daten einfach und sicher, unabhängig davon, welchen Client, welches Tool oder welche Plattform der Empfänger verwendet, um darauf zuzugreifen?“ Glücklicherweise hat das Lakehouse auch auf diese Frage eine Antwort: Datenteilung mit Delta Sharing.

Delta Sharing

Delta Sharing ist das weltweit erste offene Protokoll für die sichere gemeinsame Nutzung von Daten intern und organisationsübergreifend in Echtzeit, unabhängig von der Plattform, auf der die Daten liegen. Es ist eine Schlüsselkomponente der Offenheit der Lakehouse-Architektur und ein wichtiger Wegbereiter für die Organisation unserer Datenteams und Zugriffsmuster auf eine Weise, die bisher nicht möglich war, wie z. B. Data Mesh.

Sicher von Grund auf

Es ist wichtig zu beachten, dass Delta Sharing von Grund auf mit Blick auf Sicherheit entwickelt wurde. Sie können die folgenden Funktionen sofort nutzen, unabhängig davon, ob Sie die Open-Source-Version oder die verwaltete Entsprechung verwenden:

• Ende-zu-Ende-TLS-Verschlüsselung vom Client zum Server bis zum Speicherkonto
• Kurzlebige Anmeldeinformationen wie Pre-Signed URLs werden für den Datenzugriff verwendet
• Einfache Verwaltung, Nachverfolgung und Überprüfung des Zugriffs auf Ihre freigegebenen Datensätze über Unity Catalog

Die Best Practices, die wir im Rahmen dieses Blogs teilen werden, sind ergänzend und ermöglichen es Kunden, die geeigneten Sicherheitskontrollen an ihr Risikoprofil und die Sensibilität ihrer Daten anzupassen.

Sicherheits-Best-Practices

Unsere Empfehlungen für Best Practices zur gemeinsamen Nutzung sensibler Daten mit Delta Sharing lauten wie folgt:

1. Bewerten Sie die Open-Source-Version im Vergleich zur verwalteten Version basierend auf Ihren Anforderungen
2. Legen Sie die geeignete Token-Lebensdauer für Empfänger für jeden Metastore fest
3. Etablieren Sie einen Prozess für die Rotation von Anmeldeinformationen
4. Berücksichtigen Sie die richtige Granularität für Shares, Empfänger und Partitionen
5. Konfigurieren Sie IP-Zugriffslisten
6. Konfigurieren Sie Databricks Audit Logging
7. Konfigurieren Sie Netzwerkeinschränkungen für das/die Speicherkonto(en)
8. Konfigurieren Sie Logging für das/die Speicherkonto(en)

1. Bewerten Sie die Open-Source-Version im Vergleich zur verwalteten Version basierend auf Ihren Anforderungen

Wie oben dargelegt, wurde Delta Sharing von Grund auf mit Blick auf Sicherheit entwickelt. Es gibt jedoch Vorteile bei der Verwendung der verwalteten Version:

• Delta Sharing auf Databricks wird von Unity Catalog bereitgestellt, was es Ihnen ermöglicht, feingranularen Zugriff auf beliebige Datensätze zwischen verschiedenen Benutzergruppen zentral von einem Ort aus zu gewähren. Mit der Open-Source-Version müssten Sie Datensätze mit unterschiedlichen Datenzugriffsrechten auf mehrere Sharing-Server verteilen und außerdem Zugriffsbeschränkungen für diese Server und die zugrunde liegenden Speicherkonten durchsetzen. Zur einfacheren Bereitstellung wird mit der Open-Source-Version ein Docker-Image bereitgestellt, aber es ist wichtig zu beachten, dass die Skalierung von Bereitstellungen in großen Unternehmen einen nicht unerheblichen Aufwand für die Teams bedeutet, die für deren Verwaltung zuständig sind.
• Wie die übrige Databricks Lakehouse Platform wird auch Unity Catalog als verwalteter Dienst angeboten. Sie müssen sich keine Gedanken über Dinge wie Verfügbarkeit, Uptime und Wartung des Dienstes machen, denn wir kümmern uns darum für Sie.
• Unity Catalog ermöglicht Ihnen die Konfiguration umfassender Audit-Logging-Funktionen out-of-the-box.
• Datenbesitzer können Shares mit SQL-Syntax verwalten. Zusätzlich stehen REST-APIs zur Verwaltung von Shares zur Verfügung. Die Verwendung vertrauter SQL-Syntax vereinfacht die Art und Weise, wie wir Daten teilen, und reduziert den administrativen Aufwand.
• Bei Verwendung der Open-Source-Version sind Sie für die Konfiguration, Infrastruktur und Verwaltung der Datenteilung verantwortlich, aber mit der verwalteten Version ist all diese Funktionalität sofort verfügbar.

Aus diesen Gründen empfehlen wir, beide Versionen zu bewerten und eine Entscheidung basierend auf Ihren Anforderungen zu treffen. Wenn eine einfache Einrichtung und Nutzung, integrierte Governance und Überwachung sowie ein ausgelagerter Service-Management wichtig für Sie sind, wird die verwaltete Version wahrscheinlich die richtige Wahl sein.

2. Legen Sie die geeignete Token-Lebensdauer für Empfänger für jeden Metastore fest

Wenn Sie Delta Sharing aktivieren, konfigurieren Sie die Token-Lebensdauer für Empfänger-Anmeldeinformationen. Wenn Sie die Token-Lebensdauer auf 0 setzen, laufen Empfänger-Tokens niemals ab.

Die Festlegung der geeigneten Token-Lebensdauer ist aus regulatorischer, Compliance- und Reputationssicht von entscheidender Bedeutung. Ein Token, das niemals abläuft, birgt ein enormes Risiko. Daher wird empfohlen, kurzlebige Tokens als Best Practice zu verwenden. Es ist weitaus einfacher, einem Empfänger, dessen Token abgelaufen ist, ein neues Token zu gewähren, als die Verwendung eines Tokens zu untersuchen, dessen Lebensdauer falsch eingestellt wurde.

Siehe die Dokumentation (AWS, Azure) zur Konfiguration von Tokens, die nach der entsprechenden Anzahl von Sekunden, Minuten, Stunden oder Tagen ablaufen.

3. Etablieren Sie einen Prozess für die Rotation von Anmeldeinformationen

Es gibt eine Reihe von Gründen, warum Sie Anmeldeinformationen rotieren möchten, z. B. das Ablaufen eines vorhandenen Tokens, Bedenken, dass eine Anmeldeinformation kompromittiert wurde, oder einfach nur, weil Sie die Token-Lebensdauer geändert haben und neue Anmeldeinformationen ausstellen möchten, die diese Ablaufzeit berücksichtigen.

Um sicherzustellen, dass solche Anfragen vorhersehbar und zeitnah erfüllt werden, ist es wichtig, einen Prozess zu etablieren, vorzugsweise mit einem festgelegten SLA. Dies könnte gut in Ihren IT-Service-Management-Prozess integriert werden, wobei die entsprechende Aktion vom zuständigen Dateneigentümer, Data Steward oder DBA für diesen Metastore durchgeführt wird.

Siehe die Dokumentation (AWS, Azure) zur Rotation von Anmeldeinformationen. Insbesondere:

• Wenn Sie eine Anmeldeinformation sofort rotieren müssen, setzen Sie --existing-token-expire-in-seconds auf 0, und das vorhandene Token läuft sofort ab.
• Databricks empfiehlt die folgenden Maßnahmen, wenn Bedenken bestehen, dass Anmeldeinformationen kompromittiert wurden:
  1. Entziehen Sie dem Empfänger den Zugriff auf den Share.
  2. Rotieren Sie den Empfänger und setzen Sie --existing-token-expire-in-seconds auf 0, damit das vorhandene Token sofort abläuft.
  3. Teilen Sie den neuen Aktivierungslink über einen sicheren Kanal mit dem vorgesehenen Empfänger.
  4. Nachdem auf die Aktivierungs-URL zugegriffen wurde, gewähren Sie dem Empfänger erneut Zugriff auf die Freigabe.

4. Berücksichtigen Sie die richtige Granularität für Freigaben, Empfänger und Partitionen

In der verwalteten Version kann jede Freigabe eine oder mehrere Tabellen enthalten und mit einem oder mehreren Empfängern verknüpft werden. Dabei kommen feingranulare Steuerelemente zum Einsatz, um zu verwalten, wer oder wie auf die mehreren Datensätze zugegriffen wird. Dies ermöglicht uns, feingranularen Zugriff auf mehrere Datensätze zu bieten, was mit Open Source allein viel schwieriger zu erreichen wäre. Und wir können sogar noch einen Schritt weiter gehen, indem wir nur einen Teil einer Tabelle zum Teilen hinzufügen, indem wir eine Partitionspezifikation bereitstellen (siehe die Dokumentation zu AWS, Azure).

Es lohnt sich, diese Funktionen zu nutzen, indem Sie Ihre Freigaben und Empfänger nach dem Prinzip der geringsten Rechte implementieren, sodass im Falle einer Kompromittierung der Anmeldeinformationen eines Empfängers diese mit der geringstmöglichen Anzahl von Datensätzen oder der kleinstmöglichen Teilmenge der Daten verknüpft ist.

5. Konfigurieren Sie IP-Zugriffslisten

Standardmäßig ist alles, was zum Zugriff auf Ihre Freigaben erforderlich ist, eine gültige Delta Sharing-Anmeldeinformationsdatei. Daher ist es entscheidend, die Möglichkeit einer Kompromittierung von Anmeldeinformationen zu minimieren, indem Netzwerkbeschränkungen für deren Verwendung implementiert werden.

Konfigurieren Sie Delta Sharing IP-Zugriffslisten (siehe die Dokumentation für AWS, Azure), um den Empfängerzugriff auf vertrauenswürdige IP-Adressen zu beschränken, z. B. die öffentliche IP Ihres Unternehmens-VPN.

Die Kombination von IP-Zugriffslisten mit dem Zugriffstoken reduziert die Risiken unbefugten Zugriffs erheblich. Damit jemand unbefugt auf die Daten zugreifen kann, muss er sowohl eine Kopie Ihres Tokens erworben haben als auch im selben autorisierten Netzwerk sein, was viel schwieriger ist, als nur das Token selbst zu erwerben.

6. Konfigurieren Sie Databricks Audit Logging

Audit-Protokolle sind Ihre maßgebliche Aufzeichnung dessen, was auf Ihrer Databricks Lakehouse Platform geschieht, einschließlich aller Aktivitäten im Zusammenhang mit Delta Sharing. Daher empfehlen wir dringend, Databricks Audit-Protokolle für jede Cloud zu konfigurieren (siehe die Dokumentation für AWS, Azure) und automatisierte Pipelines einzurichten, um diese Protokolle zu verarbeiten und wichtige Ereignisse zu überwachen/darauf zu alarmieren.

Schauen Sie sich unseren begleitenden Blog an, Monitoring Your Databricks Lakehouse Platform with Audit Logs, für eine tiefere Betrachtung dieses Themas, einschließlich aller Codes, die Sie zum Einrichten von Delta Live Tables-Pipelines, zum Konfigurieren von Databricks SQL-Warnungen und zum Ausführen von SQL-Abfragen benötigen, um wichtige Fragen zu beantworten wie:

• Welche meiner Delta-Freigaben sind am beliebtesten?
• Aus welchen Ländern werden meine Delta-Freigaben abgerufen?
• Werden Delta Sharing-Empfänger ohne IP-Zugriffslistenbeschränkungen erstellt?
• Werden Delta Sharing-Empfänger mit IP-Zugriffslistenbeschränkungen erstellt, die außerhalb meines vertrauenswürdigen IP-Adressbereichs liegen?
• Schlagen Zugriffsversuche auf meine Delta-Freigaben aufgrund von IP-Zugriffslistenbeschränkungen fehl?
• Schlagen Zugriffsversuche auf meine Delta-Freigaben wiederholt fehl, weil die Authentifizierung fehlschlägt?

7. Konfigurieren Sie Netzwerkeinschränkungen für das/die Speicherkonto(en)

Sobald eine Delta Sharing-Anfrage vom Sharing-Server erfolgreich authentifiziert wurde, werden eine Reihe von kurzlebigen Anmeldeinformationen generiert und an den Client zurückgegeben. Der Client verwendet diese URLs dann, um die relevanten Dateien direkt vom Cloud-Anbieter anzufordern. Dieses Design bedeutet, dass die Übertragung parallel mit massiver Bandbreite erfolgen kann, ohne die Ergebnisse durch den Server zu streamen. Es bedeutet auch, dass Sie aus Sicherheitsperspektive wahrscheinlich ähnliche Netzwerkeinschränkungen für das Speicherkonto implementieren möchten wie für den Delta Sharing-Empfänger selbst – es hat keinen Sinn, die Freigabe auf Empfängerebene zu schützen, wenn die Daten selbst in einem Speicherkonto gehostet werden, auf das jeder von überall zugreifen kann.

Azure

Unter Azure empfiehlt Databricks die Verwendung von Managed Identities (derzeit in Public Preview), um auf das zugrunde liegende Speicherkonto im Namen von Unity Catalog zuzugreifen. Kunden können dann Speicher-Firewalls konfigurieren, um allen anderen Zugriff auf die vertrauenswürdigen privaten Endpunkte, virtuellen Netzwerke oder öffentlichen IP-Bereiche zu beschränken, die Delta Sharing-Clients für den Datenzugriff verwenden können. Bitte wenden Sie sich für weitere Informationen an Ihren Databricks-Ansprechpartner.

Wichtiger Hinweis: Auch hier ist es wichtig, alle potenziellen Anwendungsfälle zu berücksichtigen, wenn Sie Netzwerkeinschränkungen festlegen. Beispielsweise ist es wahrscheinlich, dass neben dem Zugriff auf Daten über Delta Sharing auch ein oder mehrere Databricks-Workspaces Zugriff auf die Daten benötigen. Daher sollten Sie den Zugriff von den entsprechenden vertrauenswürdigen privaten Endpunkten, virtuellen Netzwerken oder öffentlichen IP-Bereichen zulassen, die von diesen Workspaces verwendet werden.

AWS

Unter AWS empfiehlt Databricks die Verwendung von S3-Bucket-Richtlinien, um den Zugriff auf Ihre S3-Buckets zu beschränken. Beispielsweise könnte die folgende Deny-Anweisung verwendet werden, um den Zugriff auf vertrauenswürdige IP-Adressen und VPCs zu beschränken.

Wichtiger Hinweis: Es ist wichtig, alle potenziellen Anwendungsfälle zu berücksichtigen, wenn Sie Netzwerkeinschränkungen festlegen. Zum Beispiel:

• Bei Verwendung der verwalteten Version werden die Pre-Signed URLs von Unity Catalog generiert. Daher müssen Sie den Zugriff von der Databricks Control Plane NAT IP für Ihre Region zulassen.
• Es ist wahrscheinlich, dass ein oder mehrere Databricks-Workspaces auch Zugriff auf die Daten benötigen. Daher sollten Sie den Zugriff von den entsprechenden VPC-IDs zulassen, wenn sich der zugrunde liegende S3-Bucket in derselben Region befindet und Sie VPC-Endpunkte für die Verbindung mit S3 verwenden, oder von der öffentlichen IP-Adresse, zu der der Datenverkehr der Datenebene aufgelöst wird (z. B. über ein NAT-Gateway).
• Um den Verlust der Konnektivität aus Ihrem Unternehmensnetzwerk zu vermeiden, empfiehlt Databricks, den Zugriff immer von mindestens einer bekannten und vertrauenswürdigen IP-Adresse zuzulassen, z. B. der öffentlichen IP Ihres Unternehmens-VPN. Dies liegt daran, dass Deny-Bedingungen auch innerhalb der AWS-Konsole gelten.

Zusätzlich zu netzwerkseitigen Beschränkungen wird empfohlen, den Zugriff auf die zugrunde liegenden S3-Buckets auf die IAM-Rolle zu beschränken, die von Unity Catalog verwendet wird. Der Grund dafür ist, dass Unity Catalog, wie wir gesehen haben, eine granulare Datenzugriffskontrolle ermöglicht, die mit den grobkörnigen Berechtigungen von AWS IAM/S3 nicht möglich ist. Wenn also jemand direkt auf den S3-Bucket zugreifen könnte, könnte er diese feingranularen Berechtigungen umgehen und auf mehr Daten zugreifen, als beabsichtigt war.

Wichtiger Hinweis: Wie oben erwähnt, gelten Deny-Bedingungen auch innerhalb der AWS-Konsole. Daher wird empfohlen, auch einer Administratorrolle Zugriff zu gewähren, die eine kleine Anzahl privilegierter Benutzer für den Zugriff auf die AWS-Benutzeroberfläche/APIs verwenden kann.

8. Protokollierung für Speicherkonten konfigurieren

Zusätzlich zur Durchsetzung von Netzwerkbeschränkungen für die zugrunde liegenden Speicherkonten möchten Sie wahrscheinlich überwachen, ob jemand versucht, diese zu umgehen. Daher empfiehlt Databricks:

• Einrichten von S3 Server Access Logging in AWS sowie die entsprechende Überwachung und Alarmierung dafür
• Einrichten von Diagnoseprotokollierung in Azure sowie die entsprechende Überwachung und Alarmierung dafür

Fazit

Das Lakehouse hat die meisten Datenmanagementprobleme gelöst, die zu fragmentierten Datenarchitekturen und Zugriffsmustern geführt haben, und die Zeit bis zur Wertschöpfung aus Daten stark eingeschränkt. Da Daten-Teams nun von diesen Problemen befreit sind, ist offenes, aber sicheres Data Sharing die nächste Grenze.

Delta Sharing ist das weltweit erste offene Protokoll für den sicheren Austausch von Daten intern und organisationsübergreifend in Echtzeit, unabhängig von der Plattform, auf der die Daten liegen. Durch die Verwendung von Delta Sharing in Kombination mit den oben beschriebenen Best Practices können Organisationen einfach, aber sicher Daten mit ihren Benutzern, Partnern und Kunden im Enterprise-Maßstab austauschen.

Bestehende Datenmarktplätze haben den Geschäftswert für Datenanbieter und -verbraucher nicht maximiert. Mit dem Databricks Marketplace können Sie die Databricks Lakehouse Platform nutzen, um mehr Kunden zu erreichen, Kosten zu senken und mehr Wert aus all Ihren Datenprodukten zu ziehen.

Wenn Sie daran interessiert sind, ein Data Provider Partner zu werden, würden wir uns freuen, von Ihnen zu hören!

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag