Spark-understøttelse af OneLake-sikkerhed (RLS og CLS)

Fabric Spark integreres med OneLake security så row-level security (RLS) og column-level security (CLS) politikker, der er defineret én gang i OneLake, konsekvent håndhæves, når brugere læser lakehouse Delta-tabeller fra Spark-notebooks og Spark-jobdefinitioner. Brugere fortsætter med at skrive standard Spark SQL- eller DataFrame-forespørgsler; Spark filtrerer resultatet gennemsigtigt, så hver bruger kun ser de rækker og kolonner, de har tilladelse til at få adgang til.

Denne artikel forklarer , hvordan Spark arbejder med OneLake-sikkerhed, herunder håndhævelsesarkitekturen, dataforberedelsesflowet, brugeroplevelsen samt de understøttede scenarier og begrænsninger.

Bemærkning

For politikudarbejdelse og cross-engine-modellen, se Row-level security i OneLake og Column-level security in OneLake.

Koncepter i et overblik

  • Én kilde til sandhed. RLS-regler og CLS-kolonnelister defineres én gang på lakehouse via OneLake-sikkerhedsroller. Spark gemmer eller duplikerer ikke politikken.
  • Motor-agnostisk effektiv adgang. OneLake returnerer den forudberegnede effektive adgang til den anmoderende bruger, inklusive tilladte kolonner og RLS rækkefiltermetadata. Spark bruger den effektive adgang ved forespørgselstidspunktet.
  • Kun delta-filtrering. OneLake og Fabric platformlaget anvender kun RLS og CLS på Delta parketborde. Ikke-Delta-objekter med anvendte regler blokeres af platformen i stedet for filtreret af Spark.
  • Privilegerede roller omgås. Da OneLake og Fabric platformadfærd er workspace Admin, Member og Contributor ikke begrænset af RLS eller CLS. Filtrering gælder for Viewer og for brugere, der får adgang gennem OneLake sikkerhedsroller.

Hvordan Spark håndhæver OneLake-sikkerheden

Når en bruger indsender en forespørgsel, der berører en sikret lakehouse-tabel, udarbejder Spark en eksekveringsplan, der kombinerer brugerens forespørgsel med OneLake-sikkerhedsadgangen for den pågældende bruger. Håndhævelsen sker under eksekveringen, ikke som et post-filter-trin i brugerkoden, så det kan ikke omgås af alternative API'er eller sti-baserede læsninger.

To-kontekst eksekveringsmodel

Fabric Spark bruger to eksekveringskontekster for at holde policyevaluering isoleret fra brugerkoden:

  • Brugerkontekst. Kører brugerens notebook eller Spark-jobdefinition med brugerens identitet. Denne kontekst planlægger forespørgslen og forbruger det filtrerede output, men den har aldrig direkte, ufiltreret adgang til sikrede tabeller.
  • Systemkontekst (sikkerheds). En privilegeret, Microsoft-administreret kontekst, der løser brugerens effektive adgang mod OneLake, læser de underliggende Delta-filer, anvender RLS-rækkefiltrering og CLS-projektioner og returnerer kun de rækker og kolonner, som brugeren må se.

Systemkonteksten vises i overvågningshubben som SparkSecurityControl jobs, der kører side om side med brugerens notesbogssession. Jobnavnet og overvågningserfaringen er Fabric-platformens adfærd. Disse opgaver forventes og indikerer, at sikkerhedshåndhævelsen i OneLake er aktiv.

Forespørgselsflow for en sikret tabel

  1. Brugeren kører en forespørgsel i en Spark-notesbog, for eksempel SELECT * FROM lakehouse.sales.
  2. Spark løser tabellen gennem lakehouse-kataloget og opdager, at OneLake-sikkerhed er aktiveret.
  3. Spark anmoder om effektiv adgang for den nuværende bruger fra OneLake. Svaret indeholder den tilladte kolonneliste (CLS) og RLS rækkefiltermetadata.
  4. Systemsikkerhedskonteksten læser Delta-filerne, projicerer kun de tilladte kolonner og anvender RLS ved at bruge bitmap- eller deletetion-vector-stil rækkefiltrering under eksekveringen.
  5. Det filtrerede resultat gives tilbage til brugerkonteksten, som fuldender resten af brugerens forespørgsel (joins, aggregations, skriver til ikke-sikrede mål osv.) over de allerede filtrerede data.

Hvad sker der for hver type police.

Policy Hvad Spark vender tilbage Bemærkninger
Kun RLS Alle kolonner, men kun de rækker, der er tilladt ifølge RLS-reglen. Rækkefiltrering håndhæves i sikkerhedskonteksten ved brug af bitmap- eller deletion-vektor-filtrering; Brugere kan ikke observere filterlogikken.
Kun CLS Kun de tilladte kolonner; Alle rækker. SELECT * lykkes og returnerer de tilladte kolonner, når mindst én kolonne er tilladt. Hvis ingen kolonner er tilladt, fejler Spark forespørgslen.
RLS + CLS i samme rolle Tilladte rækker projiceret til tilladte kolonner. Støttes, så længe begge regler hører til samme rolle.
RLS i rolle A, CLS i rolle B (samme bruger) Forespørgslen mislykkes. OneLake- og Fabric-platformlaget understøtter ikke, at en bruger er medlem af to roller, hvor den ene definerer RLS og den anden definerer CLS. Se Række-niveau sikkerhed og Kolonne-niveau sikkerhed.
Ikke-Delta-objekt Adgang blokeret. OneLake- og Fabric-platformlaget anvender kun RLS og CLS på Delta-parquetborde; andre objekter i en sikret rolle er blokerede.

For de kanoniske forfatterregler og RLS-udtrykssyntaks, se artiklerne om sikkerhed på række- og kolonneniveau .

Hvordan Spark forbereder data til brugerne

OneLake-sikkerhed er designet til at være gennemsigtig for dataforbrugeren. Brugere fortsætter med at bruge de API'er, de allerede kender, og Spark håndterer policyløsning og filtrering på deres vegne.

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()

I begge eksempler er de transactions tabeldata, der indlæses i DataFrame, allerede filtreret af OneLake-sikkerheden. Efterfølgende transformationer opererer kun over de filtrerede data.

Direkte filadgang er blokeret

Direkte stiadgang omgår Lakehouse Catalog Policy Resolution. Når OneLake-sikkerhed er aktiveret på en tabel, blokerer OneLake- og Fabric-platformlaget følgende mønstre for ikke-privilegerede brugere:

  • spark.read.format("delta").load("abfss://...")
  • DeltaTable.forPath(spark, "abfss://...")
  • OneLake REST/SDK læser mod Tables/<table> mappen i en sikret tabel.

Brugere skal få adgang til sikrede tabeller via lakehouse-tabelnavnet (for eksempel spark.read.table("lakehouse.table") eller Spark SQL), så Spark kan løse og anvende den effektive adgang.

Brugeroplevelse

  • Gennemsigtig filtrering. Ingen forespørgselsomskrivning eller særlig syntaks er nødvendig. Den samme notesbog fungerer for brugere med forskellige roller og returnerer rollespecifikke data.
  • Konsistente resultater på tværs af motorer. Den samme RLS-regel og CLS-projektion, som anvendes i Spark, anvendes også i SQL-analyse-endpointet, semantiske modeller bygget på Direct Lake og autoriserede tredjepartsmotorer. Se Oversigt over OneLake sikkerhedsintegrationer.
  • Privilegerede roller ser alt. Efterhånden som OneLake og Fabric platformadfærd, workspace Admin, Member og Contributor brugere fortsat ser ufiltrerede data, hvilket er nyttigt til pipeline-udvikling, tabelvedligeholdelse (OPTIMIZE, VACUUM) og fejlfinding.
  • Overvågning. De SparkSecurityControl jobs, der vises i overvågningshubben, svarer til den systemkontekst, der udfører politikhåndhævelse. Jobnavnet og indgangen til overvågningshubben er en del af driften af Fabric-platformen.

Skærmbillede-pladsholder: Overvågningshub, der viser et SparkSecurityControl-job sammen med brugerens notesbogssession.

Ydelsesovervejelser

  • RLS rækkefiltrering. RLS anvendes tæt på Delta-scanningen ved brug af bitmap- eller deletion-vektor-filtrering og, hvor det understøttes, Native Execution Engine. Dette design minimerer de rækker, der opstår i brugerkonteksten.
  • Beskæring af søjler. CLS-kolonnelister kombineres med brugerens projektion. Kun krydset læses fra Delta-lageret.
  • Effektiv adgangscache. Spark cacher policy- og effective-access-metadata pr. forespørgsel og rydder op, når forespørgselsudførelsen stopper.
  • Partition og statistik brug. Standard Delta-partitionsbeskæring og dataspringning fortsætter med at anvendes med RLS-rækkefiltrering, så forespørgsler mod opdelte tabeller forbliver effektive.

Understøttede scenarier

  • Læsning af Lakehouse Delta-tabeller i Spark-notesbøger og Spark-jobdefinitioner gennem lakehouse-kataloget (<lakehouse>.<table>).
  • Spark SQL og PySpark/Scala DataFrame API'er mod sikrede tabeller.
  • Joins, aggregationer og downstream-transformationer på sikrede tabeller.
  • Skriver fra sikrede kilder til ikke-sikrede output. Outputtabeller, der skrives uden for det sikrede lakehouse, indeholder kun de allerede filtrerede data, som den skrivende bruger fik lov til at læse.
  • Adgang til lakehouse på tværs af arbejdsområder via genveje, hvor kilde lakehouse har OneLake-sikkerhed aktiveret.

Begrænsninger

OneLake sikkerheds-RLS og CLS i Spark overtager de overordnede sikkerhedsbegrænsninger i OneLake. Bemærkelsesværdige adfærd og begrænsninger inkluderer:

  • Spark RLS/CLS-implementeringen understøtter ikke serviceprincipaler; Kun brugeridentiteter vurderes for sikkerhedspolitikker på række- og kolonneniveau. Kørsel af notebooks med workspace-identitet vil ikke håndhæve RLS/CLS for selve workspace-identiteten, kun for de enkelte brugere, der udfører forespørgslerne inden for notebook-konteksten.
  • OneLake- og Fabric platformlaget anvender RLS og CLS kun på Delta parquet tabeller. Ikke-Delta-objekter i en sikret rolle blokeres.
  • OneLake- og Fabric platformlaget blokerer direkte stilæsninger (abfss://, DeltaTable.forPath) mod sikrede tabeller for ikke-privilegerede brugere.
  • OneLake- og Fabric-platformlaget understøtter ikke, at en bruger er medlem af to roller, hvor den ene definerer RLS og den anden definerer CLS for de berørte tabeller.
  • Som OneLake og Fabric platformadfærd, omgår workspace-rollerne Admin, Member og Contributor rollerne RLS og CLS.
  • Skrivninger til usikrede output fra sikrede kilder understøttes og opererer på allerede filtrerede data. Skrivninger (INDSÆT/OPDATERING/SLET/SAMMENFLETTING) til et sikret mål kan være uunderstøttet for brugere, der er underlagt RLS eller CLS; brug en privilegeret identitet til ETL-skrivninger i sikrede tabeller.

Relateret indhold

  • Last updated on