Spark-Unterstützung für OneLake-Sicherheit (RLS und CLS)

Fabric Spark ist in OneLake Security integriert, sodass richtlinien für Sicherheit auf Zeilenebene (RLS) und clS-Richtlinien auf Spaltenebene, die einmal in OneLake definiert sind, konsistent erzwungen werden, wenn Benutzer Lakehouse Delta-Tabellen aus Spark-Notizbüchern und Spark-Auftragsdefinitionen lesen. Benutzer schreiben weiterhin standardmäßige Spark SQL- oder DataFrame-Abfragen; Spark filtert das Ergebnis transparent, sodass jeder Benutzer nur die Zeilen und Spalten sieht, auf die er autorisiert ist.

In diesem Artikel wird erläutert , wie Spark mit OneLake-Sicherheit arbeitet, einschließlich der Erzwingungsarchitektur, des Datenvorbereitungsflusses, der Benutzeroberfläche und der unterstützten Szenarien und Grenzwerte.

Konzepte auf einen Blick

• Einzelne Quelle der Wahrheit. RLS-Regeln und CLS-Spaltenlisten werden einmal im Lakehouse mithilfe von OneLake-Sicherheitsrollen definiert. Spark speichert oder dupliziert die Richtlinie nicht.
• Plattformunabhängiger effektiver Zugriff. OneLake gibt den vorkompilierten effektiven Zugriff für den anfordernden Benutzer zurück, einschließlich zulässiger Spalten und RLS-Zeilenfiltermetadaten. Spark verbraucht diesen effektiven Zugriff zur Abfragezeit.
• Nur Delta-Filterung. Die OneLake- und Fabric-Plattform-Schicht wendet RLS und CLS nur auf Delta-Parquet-Tabellen an. Nicht-Delta-Objekte mit angewendeten Regeln werden von der Plattform blockiert, anstatt von Spark gefiltert.
• Umgehung privilegierter Rollen. Im OneLake- und Fabric-Plattform-Verhalten sind die Rollen Admin, Member und Contributor nicht durch RLS oder CLS eingeschränkt. Die Filterung gilt für den Viewer und für Benutzer, denen Zugriff über OneLake-Sicherheitsrollen gewährt wurde.

So erzwingt Spark OneLake-Sicherheit

Wenn ein Benutzer eine Abfrage sendet, die eine gesicherte Lakehouse-Tabelle berührt, bereitet Spark einen Ausführungsplan vor, der die Abfrage des Benutzers mit dem effektiven OneLake-Zugriff für diesen Benutzer kombiniert. Die Erzwingung erfolgt während der Ausführung, nicht als Postfilterschritt im Benutzercode, sodass sie nicht von alternativen APIs oder pfadbasierten Lesevorgängen umgangen werden kann.

Ausführungsmodell mit zwei Kontexten

Fabric Spark verwendet zwei Ausführungskontexte, um die Richtlinienauswertung vom Benutzercode isoliert zu halten:

• Benutzerkontext. Führt die Notizbuch- oder Spark-Auftragsdefinition des Benutzers mit der Identität des Benutzers aus. In diesem Kontext wird die Abfrage geplant und die gefilterte Ausgabe verwendet, hat aber nie direkten, ungefilterten Zugriff auf gesicherte Tabellen.
• Systemkontext (Sicherheit). Ein privilegierter, von Microsoft verwalteter Kontext, der den effektiven Zugriff des Benutzers in OneLake ermittelt, die zugrunde liegenden Delta-Dateien liest, RLS-Zeilenfilterung und CLS-Projektionen anwendet und nur die Zeilen und Spalten zurückgibt, die der Benutzer sehen darf.

Der Systemkontext wird im Monitoring Hub als SparkSecurityControl Aufträge angezeigt, die zusammen mit der Notizbuchsitzung des Benutzers ausgeführt werden. Der Jobname und der Überwachungsvorgang sind das Fabric-Plattformverhalten. Diese Aufträge werden erwartet und zeigen an, dass die OneLake-Sicherheitsdurchsetzung aktiv ist.

Abfragefluss für eine gesicherte Tabelle

1. Der Benutzer führt eine Abfrage in einem Spark-Notizbuch aus, z. B SELECT * FROM lakehouse.sales. .
2. Spark löst die Tabelle über den Lakehouse-Katalog auf und erkennt, dass die OneLake-Sicherheit aktiviert ist.
3. Spark fordert den effektiven Zugriff für den aktuellen Benutzer von OneLake an. Die Antwort enthält die Metadaten der zulässigen Spaltenliste (CLS) und des RLS-Zeilenfilters.
4. Der Sicherheitskontext des Systems liest die Delta-Dateien, projiziert nur die erlaubten Spalten und wendet RLS mithilfe von Bitmap- oder Löschvektorzeilenfilterung während der Ausführung an.
5. Das gefilterte Ergebnis wird an den Benutzerkontext zurückgegeben, der die restliche Abfrage des Benutzers (Verknüpfungen, Aggregationen, Schreibvorgänge in nicht gesicherte Ziele usw.) über die bereits gefilterten Daten abschließt.

Was geschieht für jeden Richtlinientyp?

Informationen zu den kanonischen Erstellungsregeln und der RLS-Ausdruckssyntax finden Sie in den Sicherheitsartikeln auf Zeilenebene und Sicherheitsartikel auf Spaltenebene .

Vorbereiten von Daten für Benutzer durch Spark

Die OneLake-Sicherheit ist so konzipiert, dass sie für den Datenverbraucher transparent ist. Benutzer verwenden weiterhin die apIs, die sie bereits kennen, und Spark verarbeitet die Richtlinienauflösung und Filterung in ihrem Auftrag.

Spark SQL

-- Returns only rows and columns the current user is authorized to see.
SELECT product_category, SUM(amount) AS total
FROM sales.transactions
GROUP BY product_category;

PySpark DataFrame

df = spark.read.table("sales.transactions")
df.filter("region = 'EMEA'").groupBy("product_category").sum("amount").show()

In beiden Beispielen sind die transactions Tabellendaten, die in den DataFrame geladen werden, bereits durch die OneLake-Sicherheit gefiltert. Nachfolgende Transformationen werden nur für die gefilterten Daten ausgeführt.

Der direkte Dateizugriff ist blockiert.

Der direkte Pfadzugriff umgeht die Richtlinienauflösung des Lakehouse-Katalogs. Wenn oneLake-Sicherheit in einer Tabelle aktiviert ist, blockiert die OneLake- und Fabric-Plattformebene die folgenden Muster für nicht privilegierte Benutzer:

• spark.read.format("delta").load("abfss://...")
• DeltaTable.forPath(spark, "abfss://...")
• OneLake REST/SDK liest aus dem Tables/<table> Ordner einer gesicherten Tabelle.

Benutzer müssen über den Lakehouse-Tabellennamen (z. B. spark.read.table("lakehouse.table") oder Spark SQL) auf gesicherte Tabellen zugreifen, damit Spark den effektiven Zugriff auflösen und anwenden kann.

Benutzerfreundlichkeit

• Transparente Filterung. Eine Abfrageumschreibung oder eine spezielle Syntax ist nicht erforderlich. Dasselbe Notizbuch funktioniert für Benutzer mit unterschiedlichen Rollen und gibt rollenspezifische Daten zurück.
• Konsistente Ergebnisse für alle Motoren. Die gleiche RLS-Regel und CLS-Projektion, die in Spark angewendet wird, wird auch im SQL-Analyseendpunkt angewendet, semantische Modelle, die auf Direct Lake basieren, und autorisierte Drittanbietermodule. Siehe Übersicht über OneLake-Sicherheitsintegrationen.
• Privilegierte Rollen sehen alles. Als Teil des Plattformverhaltens von OneLake und Fabric sehen Admin, Member und Contributor Benutzer weiterhin ungefilterte Daten, die nützlich für die Pipelineentwicklung, die Tabellenwartung (OPTIMIZE, VACUUM) und die Problembehandlung sind.
• Überwachung. Die SparkSecurityControl Aufträge, die im Überwachungshub angezeigt werden, entsprechen dem System, das die Durchsetzung von Richtlinien übernimmt. Der Auftragsname und der Monitoring Hub-Eintrag sind Teil des Betriebs der Fabric-Plattform.

Leistungsüberlegungen

• RLS-Zeilenfilterung. RLS wird nahe beim Delta-Scan mithilfe der Filterung im Bitmap- oder Löschvektorstil und, sofern unterstützt, der nativen Ausführungs-Engine angewendet. Dieser Entwurf minimiert die Zeilen, die im Benutzerkontext materialisiert werden.
• Spaltenschnitt. CLS-Spaltenlisten werden mit der Projektion des Benutzers kombiniert. Nur die Schnittmenge wird aus Delta-Speicher gelesen.
• Effektives Zwischenspeichern des Zugriffs. Spark speichert Richtlinienrichtlinien und Metadaten für effektiven Zugriff pro Abfrage und bereinigt sie, wenn die Abfrageausführung beendet wird.
• Partitions- und Statistikverwendung. Die Standardmäßige Delta-Partitionsbereinigung und das Überspringen von Daten werden weiterhin mit der Filterung von RLS-Zeilen angewendet, sodass Abfragen für partitionierte Tabellen effizient bleiben.

Unterstützte Szenarien

• Lesen von Lakehouse Delta-Tabellen in Spark-Notizbüchern und Spark-Auftragsdefinitionen durch den Lakehouse-Katalog (<lakehouse>.<table>).
• Spark SQL und PySpark/Scala DataFrame-APIs für gesicherte Tabellen.
• Verknüpfungen, Aggregationen und Downstream-Transformationen für gesicherte Tabellen.
• Schreibvorgänge aus gesicherten Quellen in nicht gesicherte Ausgaben. Ausgabetabellen, die außerhalb des gesicherten Seehauses geschrieben sind, enthalten nur die bereits gefilterten Daten, die der Schreibbenutzer lesen darf.
• Arbeitsbereichsübergreifender Seehauszugang durch Tastenkombinationen, bei denen das Quellseehaus OneLake-Sicherheit aktiviert hat.

Einschränkungen

OneLake-Sicherheits-RLS und CLS in Spark erben die allgemeinen OneLake-Sicherheitsbeschränkungen. Zu den wichtigen Verhaltensweisen und Grenzwerten gehören:

• Die Spark RLS/CLS-Implementierung unterstützt keine Dienstprinzipale; nur Benutzeridentitäten werden für Sicherheitsrichtlinien auf Zeilen- und Spaltenebene ausgewertet. Das Ausführen von Notizbüchern mit Arbeitsbereichsidentität erzwingt RLS/CLS nicht für die Arbeitsbereichsidentität selbst, nur für die einzelnen Benutzer, die die Abfragen im Notizbuchkontext ausführen.
• Die OneLake- und Fabric-Plattformebene wendet RLS und CLS nur auf Delta-Parquet Tabellen an. Nicht-Delta-Objekte in einer gesicherten Rolle werden blockiert.
• Die OneLake- und Fabric-Plattformebene blockiert direkte Pfadlesevorgänge (abfss://, DeltaTable.forPath) auf gesicherten Tabellen für nicht-privilegierte Benutzer.
• Die OneLake- und Fabric-Plattformebene unterstützt keinen Benutzer, der Mitglied von zwei Rollen ist, wobei ein Benutzer RLS definiert und der andere CLS für die betroffenen Tabellen definiert.
• In Bezug auf das Verhalten der OneLake- und Fabric-Plattform, die Admin-, Member- und Contributor-Rollen umgehen RLS und CLS.
• Schreibvorgänge aus gesicherten Quellen in nicht gesicherte Ausgaben werden unterstützt und basieren auf bereits gefilterten Daten. Schreibvorgänge (INSERT/UPDATE/DELETE/MERGE) in ein gesichertes Ziel werden für Benutzer, die RLS oder CLS unterliegen, möglicherweise nicht unterstützt; verwenden Sie eine privilegierte Identität für ETL-Schreibvorgänge in gesicherte Tabellen.

Verwandte Inhalte

• Erste Schritte mit OneLake-Sicherheit
• Sicherheit auf Zeilenebene in OneLake
• Sicherheit auf Spaltenebene in OneLake
• Übersicht über OneLake-Sicherheitsintegrationen
• Workspace-Rollen für Lakehouse
• Freigabe- und Berechtigungsverwaltung für Lakehouse
• Fabric Spark Security