Spark-støtte for OneLake-sikkerhet (RLS og CLS)

Fabric Spark integreres med OneLake sikkerhet slik at radnivå-sikkerhetspolicyer (RLS) og kolonnenivå-sikkerhetspolicyer (CLS) definert én gang i OneLake konsekvent håndheves når brukere leser lakehouse Delta-tabeller fra Spark-notatbøker og Spark-jobbdefinisjoner. Brukere fortsetter å skrive standard Spark SQL- eller DataFrame-spørringer; Spark filtrerer resultatet transparent slik at hver bruker kun ser radene og kolonnene de har tillatelse til å få tilgang til.

Denne artikkelen forklarer hvordan Spark fungerer med OneLake-sikkerhet, inkludert håndhevingsarkitekturen, dataforberedelsesflyten, brukeropplevelsen og de støttede scenarioene og begrensningene.

Notat

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

Konsepter i et overblikk

  • Én kilde til sannhet. RLS-regler og CLS-kolonnelister defineres én gang på lakehouse via OneLake sikkerhetsroller. Spark lagrer eller dupliserer ikke policyen.
  • Motor-agnostisk effektiv tilgang. OneLake returnerer den forhåndsberegnede effektive tilgangen for den forespørrende brukeren, inkludert tillatte kolonner og RLS-radfiltermetadata. Spark bruker den effektive tilgangen ved spørringstidspunktet.
  • Kun delta-filtrering. OneLake- og Fabric-plattformlaget påfører RLS og CLS kun på Delta-parkettbord. Ikke-Delta-objekter med anvendte regler blokkeres av plattformen i stedet for å filtreres av Spark.
  • Privilegerte roller omgås. Siden OneLake og Fabric plattformadferd, er arbeidsområder Admin, Member og Contributor ikke begrenset av RLS eller CLS. Filtrering gjelder både Viewer og brukere som får tilgang gjennom OneLake-sikkerhetsroller.

Hvordan Spark håndhever sikkerheten i OneLake

Når en bruker sender inn en forespørsel som berører en sikret lakehouse-tabell, utarbeider Spark en kjøringsplan som kombinerer brukerens spørring med OneLake-sikkerhetseffektiv tilgang for den brukeren. Håndheving skjer under utførelsen, ikke som et post-filter-steg i brukerkoden, så det kan ikke omgås av alternative API-er eller stibaserte lesinger.

To-kontekst utførelsesmodell

Fabric Spark bruker to utførelseskontekster for å holde policyevaluering isolert fra brukerkoden:

  • Brukerkontekst. Kjører brukerens notatbok eller Spark-jobbdefinisjon med brukerens identitet. Denne konteksten planlegger spørringen og konsumerer det filtrerte utdataet, men har aldri direkte, ufiltrert tilgang til sikrede tabeller.
  • System- (sikkerhets-) kontekst. En privilegert, Microsoft-administrert kontekst som løser brukerens effektive tilgang mot OneLake, leser de underliggende Delta-filene, anvender RLS-radfiltrering og CLS-projeksjoner, og returnerer kun radene og kolonnene brukeren har lov til å se.

Systemkonteksten vises i overvåkingshuben som SparkSecurityControl jobber som kjører parallelt med brukerens notatboksesjon. Stillingsnavnet og overvåkingserfaringen er Fabric-plattformens oppførsel. Disse jobbene forventes og indikerer at sikkerhetshåndhevelsen i OneLake er aktiv.

Spørringsflyt for en sikret tabell

  1. Brukeren kjører en spørring i en Spark-notatbok, for eksempel SELECT * FROM lakehouse.sales.
  2. Spark løser tabellen gjennom lakehouse-katalogen og oppdager at OneLake-sikkerheten er aktivert.
  3. Spark ber om effektiv tilgang for den nåværende brukeren fra OneLake. Svaret inkluderer listen over tillatte kolonner (CLS) og RLS radfiltermetadata.
  4. Systemsikkerhetskonteksten leser Delta-filene, projiserer kun de tillatte kolonnene, og anvender RLS ved å bruke bitmap- eller delete-vector-stil radfiltrering under kjøring.
  5. Det filtrerte resultatet sendes tilbake til brukerkonteksten, som fullfører resten av brukerens spørring (joininger, aggregeringer, skriver til ikke-sikrede mål osv.) over de allerede filtrerte dataene.

Hva skjer for hver type polise

Policy Hva Spark returnerer Merknader
Kun RLS Alle kolonner, men bare de radene som RLS-regelen tillater. Radfiltrering håndheves i sikkerhetskontekst ved bruk av bitmap- eller delesjonsvektor-filtrering; Brukere kan ikke observere filterlogikken.
Kun CLS Kun de tillatte kolonnene; Alle rader. SELECT * lykkes og returnerer de tillatte kolonnene når minst én kolonne er tillatt. Hvis ingen kolonner er tillatt, feiler Spark spørringen.
RLS + CLS i samme rolle Tillatte rader projisert til tillatte kolonner. Støttes så lenge begge reglene tilhører samme rolle.
RLS i rolle A, CLS i rolle B (samme bruker) Spørringen mislykkes. OneLake- og Fabric-plattformlaget støtter ikke at en bruker er medlem av to roller hvor den ene definerer RLS og den andre definerer CLS. Se sikkerhet på radnivå og sikkerhet på kolonnenivå.
Ikke-delta-objekt Tilgang blokkert. OneLake- og Fabric-plattformlaget anvender RLS og CLS kun på Delta-parkettbord; andre objekter i en sikret rolle er blokkert.

For de kanoniske forfatterreglene og RLS-uttrykkssyntaksen, se artiklene om rad-nivå sikkerhet og kolonne-nivå sikkerhet .

Hvordan Spark forbereder data for brukere

OneLake-sikkerhet er designet for å være transparent for dataforbrukeren. Brukere fortsetter å bruke API-ene de allerede kjenner, 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 eksemplene transactions er tabelldataene som lastes inn i DataFrame allerede filtrert av OneLake-sikkerheten. Påfølgende transformasjoner opererer kun over de filtrerte dataene.

Direkte filtilgang er blokkert

Direkte sti-tilgang omgår policy-løsning i Lakehouse-katalogen. Når OneLake-sikkerhet er aktivert på en tabell, blokkerer OneLake- og Fabric-plattformlaget følgende mønstre for ikke-privilegerte brukere:

  • spark.read.format("delta").load("abfss://...")
  • DeltaTable.forPath(spark, "abfss://...")
  • OneLake REST/SDK leser mot Tables/<table> mappen til en sikret tabell.

Brukere må få tilgang til sikrede tabeller via lakehouse-tabellnavnet (for eksempel spark.read.table("lakehouse.table") Spark SQL) slik at Spark kan løse og anvende effektiv tilgang.

Brukeropplevelse

  • Gjennomsiktig filtrering. Ingen spørringsomskriving eller spesiell syntaks er nødvendig. Den samme notatboken fungerer for brukere med ulike roller og returnerer rollespesifikke data.
  • Konsistente resultater på tvers av motorer. Den samme RLS-regelen og CLS-projeksjonen som brukes i Spark, brukes også i SQL-analyseendepunktet, semantiske modeller bygget på Direct Lake, og autoriserte tredjepartsmotorer. Se oversikt over OneLake sikkerhetsintegrasjoner.
  • Privilegerte roller ser alt. Etter hvert som OneLake og Fabric plattformadferd, arbeidsområder Admin, Member og Contributor fortsetter brukere å se ufiltrerte data, noe som er nyttig for pipelineutvikling, tabellvedlikehold (OPTIMIZE, VACUUM) og feilsøking.
  • Overvåking. Jobbene SparkSecurityControl som vises i overvåkingshuben tilsvarer systemkonteksten som utfører policyhåndheving. Jobbnavnet og oppføringen i overvåkingshuben er en del av driften av Fabric-plattformen.

Skjermbilde-plassholder: Overvåkingshub som viser en SparkSecurityControl-jobb sammen med brukerens notatbokøkt.

Ytelseshensyn

  • RLS-radfiltrering. RLS brukes nær Delta-skanningen ved å bruke bitmap- eller deletion-vector-filtrering og, der det støttes, Native Execution Engine. Dette designet minimerer radene som materialiserer seg i brukerkonteksten.
  • Beskjæring av søyler. CLS-kolonnelister kombineres med brukerens projeksjon. Kun krysset leses fra Delta-lagringen.
  • Effektiv tilgangs-caching. Spark cacher policy- og effektive tilgangsmetadata per spørring og rydder opp når spørringskjøringen stopper.
  • Bruk av partisjon og statistikk. Standard Delta-partisjonsbeskjæring og datahopping fortsetter å brukes med RLS-radfiltrering, slik at spørringer mot partisjonerte tabeller forblir effektive.

Scenarier som støttes

  • Lesing av Lakehouse Delta-tabeller i Spark-notatbøker og Spark-jobbdefinisjoner gjennom lakehouse-katalogen (<lakehouse>.<table>).
  • Spark SQL og PySpark/Scala DataFrame API-er mot sikrede tabeller.
  • Joins, aggregeringer og nedstrømstransformasjoner på sikrede tabeller.
  • Skriver fra sikrede kilder til usikrede utdata. Utdatatabeller som skrives utenfor det sikrede lakehouse inneholder kun de allerede filtrerte dataene som den skrivende brukeren fikk lov til å lese.
  • Kryss-arbeidsområde tilgang til lakehouse via snarveier, der kilde-lakehouse har OneLake-sikkerhet aktivert.

Begrensninger

OneLake sikkerhets RLS og CLS i Spark overtar de overordnede sikkerhetsbegrensningene i OneLake. Merkbare atferder og begrensninger inkluderer:

  • Spark RLS/CLS-implementeringen støtter ikke tjenesteprinsipper; Kun brukeridentiteter vurderes for sikkerhetspolicyer på rad- og kolonnenivå. Kjøring av notatbøker med arbeidsområdeidentitet vil ikke håndheve RLS/CLS for selve arbeidsområdets identitet, kun for de individuelle brukerne som utfører spørringene i notatbokkonteksten.
  • OneLake- og Fabric-plattformlaget anvender RLS og CLS kun på Delta parquet tabeller. Ikke-Delta-objekter i en sikret rolle blokkeres.
  • OneLake- og Fabric-plattformlaget blokkerer direkte stilesninger (abfss://, DeltaTable.forPath) mot sikrede tabeller for ikke-privilegerte brukere.
  • OneLake- og Fabric-plattformlaget støtter ikke at en bruker er medlem av to roller hvor den ene definerer RLS og den andre definerer CLS for de berørte tabellene.
  • Etter hvert som OneLake og Fabric plattformadferd, omgår workspace Admin, Member og Contributor RLS og CLS.
  • Skriving til usikrede utganger fra sikrede kilder støttes og opererer på allerede filtrerte data. Skriving (INSERT/UPDATE/DELETE/MERGE) til et sikret mål kan være ustøttet for brukere underlagt RLS eller CLS; bruk en privilegert identitet for ETL-skrivinger i sikrede tabeller.

Relatert innhold

  • Last updated on