Wie erzwingt Databricks die Benutzerisolation?

Auf dieser Seite wird erläutert, wie Azure Databricks Lakeguard verwendet, um die Benutzerisolation in gemeinsam genutzten Computeumgebungen zu erzwingen und eine differenzierte Zugriffssteuerung im dedizierten Compute zu steuern.

Was ist Lakeguard?

Lakeguard ist eine Reihe von Technologien für Databricks, die Codeisolation und Datenfilterung erzwingen, sodass mehrere Benutzer dieselbe Recheneinheit sicher und kosteneffizient nutzen können und auf Daten mit feingranulierten Zugriffssteuerungen zugreifen können, die auf der Recheneinheit bereitgestellt werden, welche privilegierten Maschinenzugriff bietet.

Wie funktioniert Lakeguard?

In gemeinsam genutzten Computeumgebungen wie klassischen Compute-, serverlosen Compute- und SQL-Warehouses isoliert Lakeguard den Benutzercode vom Spark-Modul und von anderen Benutzern. Dieses Design ermöglicht es vielen Benutzern, dieselben Computeressourcen gemeinsam zu nutzen und gleichzeitig strenge Grenzen zwischen Benutzern, dem Spark-Treiber und Executoren beizubehalten. Da diese Isolation vorhanden ist, kann die Standardberechnung systemeigene differenzierte Zugriffssteuerungen erzwingen, z. B. Zeilenfilter und Spaltenmasken.

Dedizierte Compute-Ressourcen verwenden die klassische Spark-Architektur, bei der der Benutzercode nicht von der Engine isoliert ist, sodass granulare Zugriffssteuerungen nicht direkt durchgesetzt werden können, ohne zu riskieren, mehr Daten als nötig abzurufen. Stattdessen delegiert die dedizierte Rechenleistung die Datenfilterung an die serverlose Rechenleistung Ihres Arbeitsbereichs, die Lakeguard-isoliert ist und die Filterung für diese durchführt. Deshalb setzt die feingranulare Zugriffssteuerung für dedizierte Rechenressourcen voraus, dass Ihr Arbeitsbereich für serverloses Computing aktiviert ist. Siehe Feingranulare Zugriffssteuerung auf dedizierten Rechenressourcen.

Klassische Spark-Architektur

Die folgende Abbildung zeigt, wie in der herkömmlichen Spark-Architektur Benutzeranwendungen einen JVM mit privilegiertem Zugriff auf den zugrunde liegenden Computer teilen.

Lakeguard-Architektur

Lakeguard isoliert den gesamten Benutzercode mit sicheren Containern. Auf diese Weise können mehrere Workloads auf derselben Computeressource ausgeführt werden und gleichzeitig die strikte Isolation zwischen Benutzern beibehalten werden.

Isolation des Spark-Clients

Lakeguard isoliert Clientanwendungen vom Spark-Treiber und voneinander mit zwei Schlüsselkomponenten:

• Spark Connect: Lakeguard verwendet Spark Connect (eingeführt mit Apache Spark 3.4), um Clientanwendungen vom Treiber zu entkoppeln. Clientanwendungen und Treiber teilen nicht mehr denselben JVM oder Klassenpfad. Diese Trennung verhindert nicht autorisierten Datenzugriff. Dieses Design verhindert auch, dass Benutzer auf Daten zugreifen, die sich aus dem Überholen ergeben, wenn Abfragen Filter auf Zeilen- oder Spaltenebene enthalten.

  Hinweis

  Spark Connect verschiebt die Analyse und Namensauflösung auf die Ausführungszeit, wodurch sich das Verhalten Ihres Codes ändern kann. Siehe "Vergleichen von Spark Connect" mit Spark Classic.

• Container-Sandkasten: Jede Clientanwendung wird in einer eigenen isolierten Containerumgebung ausgeführt. Dadurch wird verhindert, dass Benutzercode auf die Daten anderer Benutzer oder den zugrunde liegenden Computer zugreift. Das Sandboxing verwendet containerbasierte Isolationsverfahren, um eine sichere Trennung zwischen Benutzern zu schaffen.

Isolation von UDFs

Standardmäßig isolieren Spark-Executoren UDFs nicht. Dieser Mangel an Isolation kann UDFs das Schreiben von Dateien oder den Zugriff auf den zugrunde liegenden Computer ermöglichen.

Lakeguard isoliert benutzerdefinierten Code, einschließlich UDFs, auf Spark-Executoren durch:

• Isolation der Ausführungsumgebung auf Spark-Executors.
• Isolierung des von UDFs ausgehenden Netzwerkdatenverkehrs, um unbefugten externen Zugriff zu verhindern.
• Replizieren der Clientumgebung in die UDF-Sandbox, damit Benutzer auf erforderliche Bibliotheken zugreifen können.

Diese Isolation gilt für UDFs auf Standard-Compute sowie für Python-UDFs auf serverlosem Compute und in SQL-Warehouses.