Spark-ondersteuning voor OneLake-beveiliging (RLS en CLS)

Fabric Spark kan worden geïntegreerd met OneLake-beveiliging zodat beveiligingsbeleid op rijniveau (RLS) en CLS-beleid (Column Level Security) dat eenmaal in OneLake is gedefinieerd, consistent worden afgedwongen wanneer gebruikers Lakehouse Delta-tabellen lezen uit Spark-notebooks en Spark-taakdefinities. Gebruikers blijven standaard Spark SQL- of DataFrame-query's schrijven; Spark filtert het resultaat transparant, zodat elke gebruiker alleen de rijen en kolommen ziet die ze mogen openen.

In dit artikel wordt uitgelegd hoe Spark werkt met OneLake-beveiliging, waaronder de afdwingingsarchitectuur, de gegevensvoorbereidingsstroom, de gebruikerservaring en de ondersteunde scenario's en limieten.

Note

Voor het ontwerpen van beleid en het cross-engine-model, zie Beveiliging op rijniveau in OneLake en Beveiliging op kolomniveau in OneLake.

Concepten in één oogopslag

  • Eén bron van waarheid. RLS-regels en CLS-kolomlijsten worden eenmaal op het Lakehouse gedefinieerd met behulp van beveiligingsrollen van OneLake. Het beleid wordt niet opgeslagen of gedupliceerd in Spark.
  • Effectieve toegang onafhankelijk van de engine. OneLake retourneert de vooraf samengestelde effectieve toegang voor de aanvragende gebruiker, inclusief toegestane kolommen en RLS-metagegevens voor rijfilters. Spark verbruikt die effectieve toegang tijdens het uitvoeren van query's.
  • Alleen-deltafilters. De OneLake en Fabric-platformlaag past alleen RLS en CLS toe op Delta-parquet-tabellen. Niet-Delta-objecten waarop regels zijn toegepast, worden geblokkeerd door het platform in plaats van te filteren op Spark.
  • Bevoorrechte rollen omzeilen. Aangezien het gedrag van het OneLake en Fabric platform, zijn de rollen Admin, Lid en Bijdrager in de werkruimte niet beperkt door RLS of CLS. Filteren is van toepassing op Viewer en op gebruikers die toegang hebben verleend via OneLake-beveiligingsrollen.

Hoe Spark OneLake-beveiliging afdwingt

Wanneer een gebruiker een query indient die een beveiligde Lakehouse-tabel aanraakt, bereidt Spark een uitvoeringsplan voor dat de query van de gebruiker combineert met de effectieve toegang tot OneLake-beveiliging voor die gebruiker. Afdwingen vindt plaats tijdens de uitvoering, niet als een nafilterstap in gebruikerscode, zodat deze niet kan worden overgeslagen door alternatieve API's of op pad gebaseerde leesbewerkingen.

Uitvoeringsmodel met twee contexten

Fabric Spark twee uitvoeringscontexten gebruikt om beleidsevaluatie geïsoleerd te houden van gebruikerscode:

  • Gebruikerscontext. Hiermee wordt het notebook of de Spark-taakdefinitie van de gebruiker uitgevoerd met de identiteit van de gebruiker. Deze context plant de query en verbruikt de gefilterde uitvoer, maar heeft nooit directe, niet-gefilterde toegang tot beveiligde tabellen.
  • Systeemcontext (beveiliging). Een geprivilegieerde, door Microsoft beheerde context die de effectieve toegang van de gebruiker tot OneLake verifieert, de onderliggende Delta-bestanden leest, RLS-rijfiltering en CLS-projecties toepast, en alleen de rijen en kolommen retourneert die de gebruiker mag zien.

De systeemcontext wordt weergegeven in de Bewakingshub als SparkSecurityControl taken die naast de notebooksessie van de gebruiker worden uitgevoerd. De taaknaam en monitoringservaring is het gedrag van het Fabric-platform. Deze taken worden verwacht en geven aan dat de OneLake-beveiligingshandhaving actief is.

Queryverloop voor een beveiligde tabel

  1. De gebruiker voert bijvoorbeeld SELECT * FROM lakehouse.saleseen query uit in een Spark-notebook.
  2. Spark lost de tabel op via de lakehouse-catalogus en detecteert dat OneLake-beveiliging is ingeschakeld.
  3. Spark vraagt om de effectieve toegang voor de huidige gebruiker vanuit OneLake. Het antwoord bevat de metagegevens van de lijst met toegestane kolommen (CLS) en RLS-rijfilters.
  4. De beveiligingscontext van het systeem leest de Delta-bestanden, projecteert alleen de toegestane kolommen en past RLS toe tijdens de uitvoering met behulp van bitmap-stijl- of filteren met verwijderingsvectors.
  5. Het gefilterde resultaat wordt teruggegeven aan de gebruikerscontext, die de rest van de query van de gebruiker afhandelt (joins, aggregaties, schrijfbewerkingen naar niet-gesecureerde doelen, enzovoort) over de al gefilterde gegevens.

Wat gebeurt er voor elk beleidstype?

Policy Wat Spark teruggeeft Notes
Alleen RLS Alle kolommen, maar alleen de rijen die zijn toegestaan door de RLS-regel. Rijfiltering wordt afgedwongen in de beveiligingscontext met behulp van bitmapstijl of verwijderingsvectorfiltering; gebruikers kunnen de filterlogica niet observeren.
Alleen CLS Alleen de toegestane kolommen; alle rijen. SELECT * slaagt en retourneert de toegestane kolommen wanneer ten minste één kolom is toegestaan. Als er geen kolommen zijn toegestaan, mislukt Spark de query.
RLS + CLS in dezelfde rol Toegestane rijen geprojecteerd op toegestane kolommen. Ondersteund zolang beide regels tot dezelfde rol behoren.
RLS in rol A, CLS in rol B (dezelfde gebruiker) Query mislukt. De Platformlaag OneLake en Fabric biedt geen ondersteuning voor een gebruiker die lid is van twee rollen waarbij de ene RLS definieert en de andere CLS definieert. Zie Beveiliging op rijniveau en beveiliging op kolomniveau.
Niet-Delta-object Toegang geblokkeerd. De OneLake- en Fabric-platformlaag past RLS en CLS alleen toe op Delta Parquet-tabellen; andere objecten in een beveiligde rol worden geblokkeerd.

Zie de artikelen over beveiliging op rijniveau en beveiliging op kolomniveau voor de canonieke ontwerpregels en de syntaxis van RLS-expressies.

Hoe Spark gegevens voorbereidt voor gebruikers

OneLake-beveiliging is ontworpen om transparant te zijn voor de gegevensgebruiker. Gebruikers blijven de API's gebruiken die ze al kennen en Spark verwerkt beleidsomzetting en filtering namens hen.

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 beide voorbeelden worden de transactions tabelgegevens die in het DataFrame zijn geladen, al gefilterd door OneLake-beveiliging. Volgende transformaties worden alleen uitgevoerd op de gefilterde gegevens.

Directe bestandstoegang wordt geblokkeerd

Directe padtoegang omzeilt de beleidsresolutie van Lakehouse-catalogus. Wanneer OneLake-beveiliging is ingeschakeld voor een tabel, blokkeert de OneLake- en Fabric-platformlaag de volgende patronen voor niet-bevoegde gebruikers:

  • spark.read.format("delta").load("abfss://...")
  • DeltaTable.forPath(spark, "abfss://...")
  • OneLake REST/SDK leest de Tables/<table> map van een beveiligde tabel.

Gebruikers moeten toegang krijgen tot beveiligde tabellen via de naam van de lakehouse-tabel (bijvoorbeeld spark.read.table("lakehouse.table") Spark SQL), zodat Spark de effectieve toegang kan oplossen en toepassen.

Gebruikerservaring

  • Transparant filteren. Er is geen herschrijven van query's of speciale syntaxis vereist. Hetzelfde notebook werkt voor gebruikers met verschillende rollen en retourneert rolspecifieke gegevens.
  • Consistente resultaten in verschillende engines. Dezelfde RLS-regel en CLS-projectie die in Spark worden toegepast, worden ook toegepast in het SQL-analyse-eindpunt, semantische modellen die zijn gebouwd op Direct Lake en geautoriseerde engines van derden. Bekijk het overzicht van OneLake-beveiligingsintegraties.
  • Bevoorrechte rollen zien alles. Als onderdeel van het gedrag van het OneLake en Fabric platform blijven gebruikers van de werkruimte, zoals Admin, Member en Contributor, ongefilterde gegevens zien. Dit is nuttig voor de pijplijnontwikkeling, het tabelonderhoud (OPTIMIZE, VACUUM) en de probleemoplossing.
  • Toezicht. De SparkSecurityControl taken die worden weergegeven in de Monitoring Hub komen overeen met de systeemcontext die beleidsafdwinging uitvoert. De taaknaam en de vermelding van de monitoring hub maken deel uit van het Fabric-platformbeheer.

Tijdelijke aanduiding voor schermopname: Bewakingshub met een SparkSecurityControl-taak naast de notebooksessie van de gebruiker.

Prestatie-overwegingen

  • RLS-rijfiltering. RLS wordt dicht bij de Delta-scan toegepast met behulp van bitmap- of verwijderingsvectorfiltering en, waar ondersteund, de systeemeigen uitvoeringsengine. Dit ontwerp minimaliseert de rijen die in de gebruikerscontext zichtbaar worden.
  • Kolomverkleining. CLS-kolomlijsten worden gecombineerd met de projectie van de gebruiker. Alleen de doorsnede wordt uit Delta-opslag gelezen.
  • Effectieve toegang opslaan in cache. Spark slaat beleid en effectieve toegangsmetagegevens per query op en schoont het op wanneer de uitvoering van query's stopt.
  • Gebruik van partities en statistieken. Standaard Delta-partitionering snoeien en data-overslaan blijven van toepassing bij RLS-rijfiltering, zodat query's op gepartitioneerde tabellen efficiënt uitgevoerd blijven worden.

Ondersteunde scenario’s

  • Lakehouse Delta-tabellen lezen in Spark-notebooks en Spark-taakdefinities via de Lakehouse-catalogus (<lakehouse>.<table>).
  • Spark SQL en PySpark/Scala DataFrame-API's voor beveiligde tabellen.
  • Joins, aggregaties en downstream-transformaties op beveiligde tabellen.
  • Schrijft van beveiligde bronnen naar niet-beveiligde uitvoer. Uitvoertabellen die buiten het beveiligde lakehouse zijn geschreven, bevatten alleen de al gefilterde gegevens die de schrijfgebruiker mag lezen.
  • Lakehouse-toegang tussen werkruimten via snelkoppelingen, waarbij OneLake-beveiliging is ingeschakeld voor het bronlakehouse.

Limitations

OneLake-beveiligings-RLS en CLS in Spark nemen de algehele beveiligingsbeperkingen van OneLake over. Opmerkelijk gedrag en limieten zijn onder andere:

  • Spark RLS/CLS-implementatie biedt geen ondersteuning voor service-principals; alleen gebruikersidentiteiten worden geëvalueerd voor beveiligingsbeleid op rij- en kolomniveau. Het uitvoeren van notebooks met werkruimte-identiteit zal RLS/CLS niet afdwingen voor de werkruimte-identiteit zelf, alleen voor de individuele gebruikers die de queries uitvoeren binnen de notebookcontext.
  • De platformlaag OneLake en Fabric past RLS en CLS alleen toe op Delta parquet tabellen. Niet-Delta-objecten in een beveiligde rol worden geblokkeerd.
  • De OneLake- en Fabric-platformlaag blokkeert directe padlezingen (abfss://, DeltaTable.forPath) van beveiligde tabellen door niet-bevoegde gebruikers.
  • De platformlaag OneLake en Fabric biedt geen ondersteuning voor een gebruiker die lid is van twee rollen waarbij de ene RLS definieert en de andere CLS definieert voor de betrokken tabellen.
  • In het gedrag van het OneLake- en Fabric-platform omzeilen de rollen Admin, Lid en Bijdrager de RLS en CLS.
  • Schrijfbewerkingen naar niet-beveiligde uitvoer van beveiligde bronnen worden ondersteund en worden uitgevoerd op al gefilterde gegevens. Schrijfbewerkingen (INSERT/UPDATE/DELETE/MERGE) naar een beveiligd doel worden mogelijk niet ondersteund voor gebruikers die onderhevig zijn aan RLS of CLS; gebruik een bevoorrechte identiteit voor ETL-schrijfbewerkingen in beveiligde tabellen.

Verwante inhoud

  • Last updated on