Supporto di Spark per la sicurezza di OneLake (RLS e CLS)

Fabric Spark si integra con OneLake security in modo che i criteri di sicurezza a livello di riga e di sicurezza a livello di colonna definiti una volta in OneLake vengano applicati in modo coerente quando gli utenti leggono tabelle Delta lakehouse dai notebook Spark e dalle definizioni dei processi Spark. Gli utenti continuano a scrivere query Spark SQL o DataFrame standard; Spark filtra in modo trasparente il risultato in modo che ogni utente veda solo le righe e le colonne a cui sono autorizzati ad accedere.

Questo articolo illustra il funzionamento di Spark con la sicurezza di OneLake, tra cui l'architettura di imposizione, il flusso di preparazione dei dati, l'esperienza utente e gli scenari e i limiti supportati.

Annotazioni

Per la creazione di criteri e il modello tra motori, vedere Sicurezza a livello di riga in OneLake e Sicurezza a livello di colonna in OneLake.

Concetti a colpo d'occhio

  • Unica fonte di verità. Le regole RLS e gli elenchi di colonne CLS vengono definiti in modo univoco nel lakehouse tramite i ruoli di sicurezza di OneLake. Spark non archivia o duplica i criteri.
  • Accesso efficace indipendente dal motore. OneLake restituisce l'accesso effettivo precomputato per l'utente che effettua la richiesta, incluse le colonne consentite e i metadati del filtro RLS. Spark usa tale accesso effettivo in fase di query.
  • Filtro solo delta. Il layer della piattaforma OneLake e Fabric applica RLS e CLS solo alle tabelle Parquet Delta. Gli oggetti non Delta con regole applicate sono bloccati dalla piattaforma anziché filtrati da Spark.
  • Bypass dei ruoli con privilegi. Nella piattaforma OneLake e Fabric, i ruoli Admin, Member e Contributor dell'area di lavoro non sono soggetti a RLS o CLS. Il filtro si applica al Visualizzatore e agli utenti a cui è concesso l'accesso tramite i ruoli di sicurezza di OneLake.

Come Spark applica la sicurezza di OneLake

Quando un utente invia una query che tocca una tabella lakehouse protetta, Spark prepara un piano di esecuzione che combina la query dell'utente con l'accesso effettivo alla sicurezza OneLake per tale utente. L'imposizione avviene durante l'esecuzione, non come passaggio post-filtro nel codice utente, quindi non può essere ignorata da API alternative o letture basate sul percorso.

Il modello di esecuzione a due contesti

Fabric Spark usa due contesti di esecuzione per mantenere la valutazione dei criteri isolata dal codice utente:

  • Contesto utente. Esegue il notebook dell'utente o la definizione del job Spark con l'identità dell'utente. Questo contesto pianifica la query e utilizza l'output filtrato, ma non ha mai accesso diretto e non filtrato alle tabelle protette.
  • Contesto di sicurezza del sistema. Un contesto privilegiato gestito da Microsoft che risolve l'accesso effettivo dell'utente a OneLake, legge i file Delta sottostanti, applica il filtraggio a livello di riga RLS e le proiezioni di sicurezza delle colonne CLS, e restituisce solo le righe e le colonne che l'utente può visualizzare.

Il contesto di sistema viene visualizzato nell'hub di monitoraggio come SparkSecurityControl processi eseguiti insieme alla sessione del notebook dell'utente. Il nome dell'attività e l'attività di monitoraggio sono il comportamento della piattaforma Fabric. Questi job sono previsti e indicano che l'applicazione della sicurezza di OneLake è attiva.

Flusso di query per una tabella protetta

  1. L'utente esegue una query in un notebook Spark, ad esempio SELECT * FROM lakehouse.sales.
  2. Spark risolve la tabella tramite il catalogo lakehouse e rileva che la sicurezza di OneLake è abilitata.
  3. Spark richiede l'accesso effettivo per l'utente corrente da OneLake. La risposta include l'elenco delle colonne consentite (CLS) e i metadati del filtro di riga (RLS).
  4. Il contesto di sicurezza del sistema legge i file Delta, seleziona solo le colonne consentite e applica la RLS utilizzando il filtraggio delle righe in stile bitmap o con vettori di eliminazione durante l'esecuzione.
  5. Il risultato filtrato viene restituito al contesto utente, che completa il resto della query dell'utente (join, aggregazioni, scritture in destinazioni non protette e così via) sui dati già filtrati.

Cosa accade per ogni tipo di politica

Policy Cosa restituisce Spark Notes
Solo RLS Tutte le colonne, ma solo le righe consentite dalla regola RLS (sistema di sicurezza a livello di riga). Il filtro delle righe viene applicato nel contesto di sicurezza usando filtri di tipo bitmap o di eliminazione vettoriale; gli utenti non possono osservare la logica del filtro.
Solo CLS Solo le colonne consentite; tutte le righe. SELECT * ha esito positivo e restituisce le colonne consentite quando è consentita almeno una colonna. Se non sono consentite colonne, Spark non riesce a eseguire la query.
RLS + CLS nello stesso ruolo Righe consentite proiettate in colonne consentite. Supportato purché entrambe le regole appartengano allo stesso ruolo.
RLS nel ruolo A, CLS nel ruolo B (stesso utente) La query non riesce. Il livello della piattaforma OneLake e Fabric non supporta un utente come membro di due ruoli in cui uno definisce la sicurezza a livello di riga e l'altro definisce la sicurezza a livello di colonna (CLS). Vedi Sicurezza a livello di riga e Sicurezza a livello di colonna.
Oggetto non Delta Accesso bloccato. Il livello della piattaforma OneLake e Fabric applica la sicurezza a livello di riga (RLS) e la sicurezza a livello di colonna (CLS) solo alle tabelle Parquet Delta; gli altri oggetti in un ruolo protetto vengono bloccati.

Per le regole di scrittura canoniche e la sintassi delle espressioni di sicurezza a livello di riga, vedere gli articoli sulla sicurezza a livello di riga e sulla sicurezza a livello di colonna.

Come Spark prepara i dati per gli utenti

La sicurezza di OneLake è progettata per essere trasparente per il consumer di dati. Gli utenti continuano a usare le API che già conoscono e Spark gestisce la risoluzione e il filtro dei criteri per loro conto.

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 entrambi gli esempi, i transactions dati della tabella caricati nel dataframe sono già filtrati in base alla sicurezza di OneLake. Le trasformazioni successive operano solo sui dati filtrati.

L'accesso diretto ai file è bloccato

L'accesso diretto al percorso ignora la risoluzione dei criteri del catalogo lakehouse. Quando la sicurezza di OneLake è abilitata in una tabella, il livello della piattaforma OneLake e Fabric blocca i modelli seguenti per gli utenti senza privilegi:

  • spark.read.format("delta").load("abfss://...")
  • DeltaTable.forPath(spark, "abfss://...")
  • OneLake REST/SDK legge nella Tables/<table> cartella di una tabella protetta.

Gli utenti devono accedere alle tabelle protette tramite il nome della tabella lakehouse (ad esempio spark.read.table("lakehouse.table") o Spark SQL) in modo che Spark possa risolvere e applicare l'accesso effettivo.

Esperienza utente

  • Filtro trasparente. Non è necessaria alcuna riscrittura delle query o una sintassi speciale. Lo stesso notebook funziona per gli utenti con ruoli diversi e restituisce dati specifici del ruolo.
  • Risultati coerenti tra i motori di ricerca. La stessa regola RLS e proiezione CLS applicate in Spark vengono applicate anche all'endpoint di analisi SQL, ai modelli semantici costruiti su Direct Lake e ai motori di terze parti autorizzati. Vedere Panoramica delle integrazioni della sicurezza di OneLake.
  • I ruoli privilegiati vedono tutto. Come comportamento della piattaforma OneLake e Fabric, area di lavoro AdminMember e Contributor gli utenti continuano a visualizzare i dati non filtrati, utili per lo sviluppo della pipeline, la manutenzione delle tabelle (OPTIMIZE, VACUUM) e la risoluzione dei problemi.
  • Monitoraggio. I SparkSecurityControl processi di lavoro visualizzati nell'hub di monitoraggio corrispondono al contesto di sistema che esegue l'applicazione delle policy. Il nome del job e l'elemento dell'hub di monitoraggio fanno parte dell'operazione della piattaforma Fabric.

Segnaposto screenshot: hub di monitoraggio che mostra un processo SparkSecurityControl insieme alla sessione del notebook dell'utente.

Considerazioni sulle prestazioni

  • Filtro RLS delle righe. RLS viene applicato vicino alla scansione Delta usando filtri in stile bitmap o in stile vettore di eliminazione e, se supportato, il motore di esecuzione nativo. Questa progettazione riduce al minimo le righe che si materializzano nel contesto utente.
  • Potatura delle colonne. Gli elenchi di colonne CLS vengono combinati con la proiezione dell'utente. Solo l'intersezione viene letta dallo storage Delta.
  • Caching efficace degli accessi. Spark memorizza nella cache i criteri e i metadati di accesso effettivi per ogni query e lo pulisce quando l'esecuzione della query si arresta.
  • Uso di partizioni e statistiche. La potatura delle partizioni Delta standard e il salto dei dati continuano ad applicarsi con il filtraggio delle righe con RLS, in modo che le query sulle tabelle partizionate rimangano efficaci.

Scenari supportati

  • Lettura delle tabelle Delta lakehouse nei notebook Spark e definizioni di processi Spark tramite il catalogo lakehouse (<lakehouse>.<table>).
  • API Spark SQL e PySpark/Scala dataframe su tabelle protette.
  • Le join, le aggregazioni e le trasformazioni a valle nelle tabelle protette.
  • Scrive da fonti sicure verso output non sicuri. Le tabelle di output scritte all'esterno del lakehouse protetto contengono solo i dati già filtrati che l'utente di scrittura è autorizzato a leggere.
  • Accesso ai lakehouse tra aree di lavoro tramite collegamenti, dove la sicurezza OneLake è abilitata per il lakehouse sorgente.

Limitazioni

OneLake security RLS e CLS in Spark ereditano le limitazioni di sicurezza complessive di OneLake. I comportamenti e i limiti rilevanti includono:

  • L'implementazione di Spark RLS/CLS non supporta le entità servizio; vengono valutate solo le identità utente per i criteri di sicurezza a livello di riga e colonna. L'esecuzione di notebook con l'identità dell'area di lavoro non applica RLS/CLS all'identità dell'area di lavoro stessa, ma solo agli utenti individuali che eseguono le query all'interno del contesto del notebook.
  • Il livello della piattaforma OneLake e Fabric applica la sicurezza a livello di riga (RLS) e la sicurezza a livello di colonna (CLS) solo alle tabelle Delta parquet. Gli oggetti non Delta in un ruolo protetto vengono bloccati.
  • Il livello della piattaforma OneLake e Fabric blocca le letture dei percorsi diretti (abfss://, DeltaTable.forPath) su tabelle protette per gli utenti non privilegiati.
  • Il livello della piattaforma OneLake e Fabric non supporta un utente come membro di due ruoli in cui uno definisce la sicurezza a livello di riga (RLS) e l'altro definisce la sicurezza a livello di colonna (CLS) per le tabelle interessate.
  • Per la piattaforma OneLake e Fabric, i ruoli Admin, Member e Contributor non applicano la sicurezza a livello di riga (RLS) e CLS.
  • Le scritture su output non protetti da fonti protette sono supportate e operano su dati già filtrati. Le scritture (INSERT/UPDATE/DELETE/MERGE) in una destinazione protetta potrebbero non essere supportate per gli utenti soggetti a RLS o CLS; usare un'identità con privilegi per le scritture ETL in tabelle protette.