Modello di controllo di accesso alla sicurezza OneLake (anteprima)

Questo documento fornisce una guida dettagliata sul funzionamento del modello di controllo di accesso alla sicurezza OneLake. Contiene informazioni dettagliate sulla struttura dei ruoli, sul modo in cui si applicano ai dati e sull'integrazione con altre strutture all'interno di Microsoft Fabric.

Ruoli di sicurezza di OneLake

La sicurezza di OneLake usa un modello di controllo degli accessi in base al ruolo per la gestione dell'accesso ai dati in OneLake. Ogni ruolo è costituito da diversi componenti chiave.

Digitare: Se il ruolo concede l'accesso (GRANT) o rimuove l'accesso (DENY). Sono supportati solo i ruoli del tipo GRANT.
Permesso: Azione o azioni specifiche concesse o negate.
Portata: Oggetti OneLake che dispongono dell'autorizzazione. Gli oggetti sono tabelle, cartelle o schemi.
Membri: Qualsiasi identità Di Microsoft Entra assegnata al ruolo, ad esempio utenti, gruppi o identità non utente. Il ruolo viene concesso a tutti i membri di un gruppo Microsoft Entra.

Assegnando un membro a un ruolo, tale utente viene quindi soggetto alle autorizzazioni associate per l'ambito di tale ruolo. Poiché la sicurezza di OneLake usa un modello di negazione per impostazione predefinita, tutti gli utenti iniziano senza accesso ai dati a meno che non venga concesso esplicitamente da un ruolo di sicurezza OneLake.

Autorizzazioni ed elementi supportati

I ruoli di sicurezza di OneLake supportano l'autorizzazione seguente:

Leggere: Concede all'utente la possibilità di leggere i dati da una tabella e visualizzare i metadati della tabella e della colonna associati. In termini SQL, questa autorizzazione equivale sia a VIEW_DEFINITION che a SELECT. Per altre informazioni, vedere Sicurezza dei metadati.
ReadWrite: Concede all'utente la possibilità di leggere e scrivere dati da una tabella o da una cartella e visualizzare i metadati della tabella e della colonna associati. In termini SQL, questa autorizzazione equivale a ALTER, DROP, UPDATE e INSERT. Per altre informazioni, vedere Autorizzazione ReadWrite.

La sicurezza di OneLake consente agli utenti di definire i ruoli di accesso ai dati solo per gli elementi di Fabric seguenti.

Articolo di tessuto	stato	Autorizzazioni supportate
Lakehouse	Public Preview	Lettura, LetturaScrittura
Catalogo duplicato di Azure Databricks	Public Preview	Leggi

Autorizzazioni per la sicurezza e l'area di lavoro di OneLake

Le autorizzazioni dell'area di lavoro sono il primo limite di sicurezza per i dati all'interno di OneLake. Ogni area di lavoro rappresenta un singolo dominio o area di progetto in cui i team possono collaborare ai dati. La sicurezza nell'area di lavoro viene gestita tramite i ruoli dell'area di lavoro di Fabric. Altre informazioni sul controllo degli accessi in base al ruolo di Fabric: ruoli dell'area di lavoro

I ruoli dell'area di lavoro infrastruttura forniscono autorizzazioni applicabili a tutti gli elementi nell'area di lavoro. Nella tabella seguente vengono illustrate le autorizzazioni di base consentite dai ruoli dell'area di lavoro.

Autorizzazione	Amministratore	Membro	Collaboratore	Visualizzatore
Visualizza i file in OneLake	Sì, sempre*	Sì, sempre*	Sì, sempre*	No, per impostazione predefinita. Usare la sicurezza di OneLake per concedere l'accesso.
Scrivere file in OneLake	Sì, sempre*	Sì, sempre*	Sì, sempre*	NO
Può modificare i ruoli di sicurezza di OneLake	Sì, sempre*	Sì, sempre*	NO	NO

*Poiché i ruoli di amministratore, membro e collaboratore dell'area di lavoro concedono automaticamente autorizzazioni di scrittura a OneLake, queste ultime sostituiscono le autorizzazioni di lettura della sicurezza di OneLake.

I ruoli dell'area di lavoro gestiscono l'accesso ai dati del piano di controllo, ovvero le interazioni con la creazione e la gestione degli artefatti e delle autorizzazioni dell'infrastruttura. Inoltre, i ruoli dell'area di lavoro forniscono livelli di accesso predefiniti agli elementi di dati usando i ruoli predefiniti per la sicurezza di OneLake. Si noti che i ruoli predefiniti si applicano solo ai visualizzatori, perché l'accesso è stato elevato da amministratore, membro e collaboratore tramite l'autorizzazione di scrittura. Un ruolo predefinito è un normale ruolo di sicurezza OneLake creato automaticamente con ogni nuovo elemento. Offre agli utenti autorizzazioni per determinate aree di lavoro o elemento un livello predefinito di accesso ai dati in tale elemento. Ad esempio, gli elementi Lakehouse hanno un ruolo DefaultReader che consente agli utenti con l'autorizzazione ReadAll di visualizzare i dati in Lakehouse. In questo modo, gli utenti che accedono a un elemento appena creato hanno un livello di accesso di base. Tutti i ruoli predefiniti usano una funzionalità di virtualizzazione dei membri, in modo che i membri del ruolo siano tutti gli utenti dell'area di lavoro con l'autorizzazione necessaria. Ad esempio, tutti gli utenti con autorizzazione ReadAll per Lakehouse. Nella tabella seguente vengono illustrati i ruoli predefiniti standard. Gli elementi possono avere ruoli predefiniti specializzati che si applicano solo a quel tipo di elemento.

Articolo di tessuto	Nome ruolo	Autorizzazione	Cartelle incluse	Membri assegnati
Lakehouse	`DefaultReader`	Leggi	Tutte le cartelle in `Tables/` e `Files/`	Tutti gli utenti con autorizzazione ReadAll
Lakehouse	`DefaultReadWriter`	Leggi	Tutte le cartelle	Tutti gli utenti con autorizzazione di scrittura

Nota

Per limitare l'accesso a utenti specifici o cartelle specifiche, modificare il ruolo predefinito o rimuoverlo e creare un nuovo ruolo personalizzato.

Autorizzazioni per la sicurezza e gli elementi di OneLake

All'interno di un'area di lavoro, gli elementi di Fabric possono avere autorizzazioni configurate separatamente dai ruoli dell'area di lavoro. È possibile configurare le autorizzazioni tramite la condivisione di un elemento o la gestione delle autorizzazioni di un elemento. Le autorizzazioni seguenti determinano la capacità di un utente di eseguire azioni sui dati in OneLake. Per altre informazioni sulla condivisione degli elementi, vedere Funzionamento della condivisione di Lakehouse

Autorizzazione	È possibile visualizzare i file in OneLake?	È possibile scrivere file in OneLake?	È possibile leggere i dati tramite l'endpoint di analisi SQL?
Leggi	No, per impostazione predefinita. Usare la sicurezza di OneLake per concedere l'accesso.	NO	NO
LeggiTutto	Sì tramite il ruolo DefaultReader. Usare la sicurezza di OneLake per limitare l'accesso.	NO	No*
Scrittura	Sì	Sì	Sì
Eseguire, Ricondividire, Visualizzare output, Visualizzare log	N/D: non può essere concesso autonomamente	N/D: non può essere concesso autonomamente	N/D: non può essere concesso autonomamente

*Dipende dalla modalità endpoint di analisi SQL.

Creazione di ruoli

È possibile definire e gestire la sicurezza di OneLake tramite le impostazioni di accesso ai dati del lakehouse.

Per ulteriori informazioni, vedere Introduzione ai ruoli di accesso ai dati.

Accesso utente e motore ai dati

L'accesso ai dati a OneLake si verifica in uno dei due modi seguenti:

Tramite un motore di query di Fabric o
Tramite l'accesso utente (le query provenienti da motori non di infrastruttura sono considerate accesso utente)

La sicurezza di OneLake garantisce che i dati siano sempre protetti. Poiché alcune funzionalità di sicurezza di OneLake come la sicurezza a livello di riga e colonna non sono supportate dalle operazioni a livello di archiviazione, non tutti i tipi di accesso ai dati protetti a livello di riga o colonna possono essere consentiti. Ciò garantisce che gli utenti non possano visualizzare righe o colonne a cui non sono autorizzati. I motori di Microsoft Fabric sono abilitati per applicare il filtro di sicurezza a livello di riga e colonna alle query di dati. Ciò significa che quando un utente esegue query sui dati in un lakehouse o in un altro elemento con la sicurezza di OneLake o CLS, i risultati visualizzati dall'utente hanno le righe e le colonne nascoste rimosse. Per l'accesso utente ai dati in OneLake con sicurezza a livello di riga o CLS, la query viene bloccata se l'utente che richiede l'accesso non è autorizzato a visualizzare tutte le righe o le colonne in tale tabella.

La tabella seguente illustra i motori di Microsoft Fabric che supportano la sicurezza a livello di riga e il filtro CLS.

Motore	Filtro RLS/CLS	Stato
Lakehouse	Sì	Anteprima pubblica
Notebook Spark	Sì	Anteprima pubblica
Endpoint di Analisi SQL in "modalità di identità dell'utente"	Sì	Anteprima pubblica
Modelli semantici che usano DirectLake in modalità OneLake	Sì	Anteprima pubblica
Eventhouse	NO	Pianificato
Tabelle esterne del data warehouse	NO	Pianificato

Dettagli del modello di controllo di accesso alla sicurezza di OneLake

Questa sezione fornisce informazioni dettagliate sul modo in cui i ruoli di sicurezza di OneLake concedono l'accesso a ambiti specifici, sul funzionamento dell'accesso e sul modo in cui l'accesso viene risolto tra più ruoli e tipi di accesso.

Sicurezza a livello di tabella

Tutte le tabelle OneLake sono rappresentate da cartelle nel lake, ma non tutte le cartelle nel lake sono tabelle dal punto di vista dei motori di query e sicurezza di OneLake in Fabric. Per essere considerata una tabella valida, è necessario soddisfare le condizioni seguenti:

La cartella esiste nella directory Tables/ di un elemento.
La cartella contiene una cartella _delta_log con i file JSON corrispondenti per i metadati della tabella.
La cartella non contiene alcun sottocollegamento.

Le tabelle che non soddisfano tali criteri avranno accesso negato se è configurata la sicurezza a livello di tabella.

Sicurezza dei metadati

L'accesso in lettura alla sicurezza di OneLake ai dati concede l'accesso completo ai dati e ai metadati in una tabella. Per gli utenti senza accesso a una tabella, i dati non vengono mai esposti e in genere i metadati non sono visibili. Questo vale anche per la sicurezza a livello di colonna e la capacità di un utente di visualizzare o non visualizzare una colonna in tale tabella. Tuttavia, la sicurezza di OneLake non garantisce che i metadati per una tabella non siano accessibili, in particolare nei casi seguenti:

Query sugli endpoint SQL: l'endpoint di Analisi SQL usa lo stesso comportamento di sicurezza dei metadati di SQL Server. Ciò significa che se un utente non ha accesso a una tabella o a una colonna, il messaggio di errore per tale query indcherà in modo esplicito i nomi di tabella o colonna a cui l'utente non ha accesso.
Modelli semantici: concedere a un utente l'autorizzazione di compilazione per un modello semantico consente loro di visualizzare i nomi di tabella inclusi nel modello, indipendentemente dal fatto che l'utente abbia accesso o meno a tali modelli. Inoltre, gli oggetti visivi del report che contengono colonne nascoste mostrano il nome della colonna nel messaggio di errore.

Ereditarietà delle autorizzazioni

Per una determinata cartella, le autorizzazioni di sicurezza di OneLake vengono ereditate sempre nell'intera gerarchia dei file e delle sottocartelle della cartella.

Ad esempio, considerate la seguente gerarchia di un lakehouse in OneLake:

Tables/
──── (empty folder)
Files/
────folder1
│   │   file11.txt
│   │
│   └───subfolder11
│       │   file1111.txt
|       │
│       └───subfolder111
|            │   file1111.txt
│   
└───folder2
    │   file21.txt

Crei due ruoli per questo lakehouse. Role1 concede l'autorizzazione di lettura a folder1 e Role2 concede l'autorizzazione di lettura a folder2.

Per la gerarchia specificata, le autorizzazioni di sicurezza di OneLake per Role1 e Role2 ereditano nel modo seguente:

Ruolo1: Leggi cartella1

│   │   file11.txt
│   │
│   └───subfolder11
│       │   file1111.txt
|       │
│       └───subfolder111
|            │   file1111.txt

Role2: lettura cartella2
```
    │   file21.txt
```

Attraversamento ed elenco nella sicurezza di OneLake

La sicurezza di OneLake garantisce la navigazione automatica tra gli elementi principali per assicurare che i dati siano facilmente individuabili. La concessione a un utente delle autorizzazioni di lettura alla subfolder11 concede all'utente la possibilità di visualizzare e navigare nella directory genitore folder1. Questa funzionalità è simile alle autorizzazioni delle cartelle di Windows in cui concedere l'accesso a una sottocartella fornisce visibilità e navigazione per le directory padre. L'elenco e l'attraversamento concessi al genitore diretto non si estendono ad altri elementi al di fuori di esso, assicurando che le altre cartelle rimangano mantenute al sicuro.

Ad esempio, considera la gerarchia seguente di un lakehouse in OneLake.

Tables/
──── (empty folder)
Files/
────folder1
│   │   file11.txt
│   │
│   └───subfolder11
│       │   file111.txt
|       │
│       └───subfolder111
|            │   file1111.txt
│   
└───folder2
    │   file21.txt

Per la gerarchia specificata, le autorizzazioni di sicurezza di OneLake per Role1 forniscono il seguente accesso. L'accesso a file11.txt non è visibile perché non è un elemento padre di subfolder11. Analogamente a Role2, neanche file111.txt è visibile.

Role1: Leggere subfolder11

Files/
────folder1
│   │
│   └───subfolder11
│       │   file111.txt
|       │
│       └───subfolder111
|            │   file1111.txt

Role2: Lettura di subfolder111

Files/
────folder1
│   │
│   └───subfolder11
|       │
│       └───subfolder111
|            │   file1111.txt

Per le scorciatoie da tastiera, il comportamento dell'elenco è leggermente diverso. I collegamenti alle origini dati esterne si comportano come le cartelle, ma i collegamenti ad altre posizioni di OneLake hanno un comportamento specializzato. Le autorizzazioni di destinazione del collegamento permettono l'accesso a un shortcut OneLake. Quando si elencano i collegamenti, non viene effettuata alcuna chiamata per controllare l'accesso di destinazione. Pertanto, quando si elenca una directory vengono restituiti tutti i collegamenti interni indipendentemente dall'accesso di un utente alla destinazione. Quando un utente tenta di aprire il collegamento, viene effettuato un controllo sull'accesso e l'utente visualizza solo i dati che dispongono delle autorizzazioni necessarie per la visualizzazione. Per ulteriori informazioni sulle scorciatoie, consultare la sezione sicurezza delle scorciatoie.

Si consideri la seguente gerarchia di cartelle che contiene scorciatoie.

Files/
────folder1
│   
└───shortcut2
|
└───shortcut3

Ruolo1: Leggi cartella1

Files/
────folder1
│   
└───shortcut2
|
└───shortcut3

Role2: nessuna autorizzazione definita

Files/
│   
└───shortcut2
|
└───shortcut3

Protezione a livello di riga

La sicurezza di OneLake consente agli utenti di specificare la sicurezza a livello di riga scrivendo predicati SQL per limitare i dati visualizzati a un utente. La sicurezza a livello di riga opera mostrando le righe in cui il predicato restituisce true. Per altre informazioni, vedere sicurezza a livello di riga.

La sicurezza a livello di riga valuta i dati stringa come senza distinzione tra maiuscole e minuscole, usando le regole di confronto seguenti per l'ordinamento e i confronti: Latin1_General_100_CI_AS_KS_WS_SC_UTF8

Quando si usa la sicurezza a livello di riga, assicurarsi che le istruzioni di sicurezza a livello di riga siano pulite e facili da comprendere. Usare colonne integer per l'ordinamento e maggiore o minore di operazioni. Evitare le equivalenze di stringa se non si conosce il formato dei dati di input, in particolare in relazione ai caratteri Unicode o alla sensibilità accentato.

Sicurezza a livello di colonna

La sicurezza di OneLake supporta la limitazione dell'accesso alle colonne rimuovendo (nascondendo) l'accesso di un utente a una colonna. Una colonna nascosta viene considerata priva di autorizzazioni assegnate, con conseguente assenza di criteri predefiniti di nessun accesso. Le colonne nascoste non saranno visibili agli utenti e le query sui dati contenenti colonne nascoste non restituiscono dati per tale colonna. Come indicato nella sicurezza dei metadati , esistono alcuni casi in cui i metadati di una colonna potrebbero essere ancora visibili in alcuni messaggi di errore.

La sicurezza a livello di colonna segue anche un comportamento più rigoroso nell'endpoint SQL tramite una semantica di negazione. Nega in una colonna nell'endpoint SQL garantisce che tutto l'accesso alla colonna sia bloccato, anche se più ruoli si combinano per concedere l'accesso. Di conseguenza, CLS nell'endpoint SQL opera usando un'intersezione tra tutti i ruoli che un utente fa parte del comportamento di unione invece che per tutti gli altri tipi di autorizzazione. Vedere la sezione Valutazione di più ruoli di sicurezza di OneLake per altre informazioni sulla combinazione dei ruoli.

Autorizzazione ReadWrite

L'autorizzazione ReadWrite consente agli utenti di sola lettura di eseguire operazioni di scrittura in elementi specifici. L'autorizzazione ReadWrite è applicabile solo ai visualizzatori o agli utenti con l'autorizzazione Lettura per un elemento. L'assegnazione dell'accesso ReadWrite a un amministratore, un membro o un collaboratore non ha alcun effetto perché tali ruoli dispongono già di tale autorizzazione in modo implicito.

L'accesso readWrite consente agli utenti di eseguire operazioni di scrittura tramite notebook Spark, OneLake File Explorer o Le API OneLake. Le operazioni di scrittura tramite l'esperienza utente lakehouse per i visualizzatori non sono supportate.

L'autorizzazione ReadWrite opera nei modi seguenti:

L'autorizzazione ReadWrite include tutti i privilegi concessi dall'autorizzazione Read.
Gli utenti con autorizzazioni ReadWrite per un oggetto possono eseguire operazioni di scrittura su tale oggetto, inclusi. Ovvero, qualsiasi operazione può essere eseguita anche sull'oggetto stesso.
ReadWrite consente le azioni seguenti:
- Creare una nuova cartella o una nuova tabella
- Eliminare una cartella o una tabella
- Rinominare una cartella o una tabella
- Caricare o modificare un file
- Crea un collegamento
- Eliminare un collegamento
- Rinominare un collegamento
I ruoli di sicurezza di OneLake con accesso ReadWrite non possono contenere vincoli RLS o CLS.
Poiché Fabric supporta solo scritture a motore singolo nei dati, gli utenti con autorizzazione ReadWrite per un oggetto possono scrivere solo in tali dati tramite OneLake. Tuttavia, le operazioni di lettura verranno applicate in modo coerente tramite tutti i motori di query.

Scorciatoie

Panoramica dei collegamenti

La sicurezza di OneLake si integra con i collegamenti in OneLake per garantire che i dati all'interno e all'esterno di OneLake possano essere protetti facilmente. Esistono due modalità di autenticazione principali per i collegamenti:

Collegamenti pass-through (SSO): le credenziali dell'utente che esegue query vengono valutate rispetto alla destinazione di collegamento per determinare quali dati possono essere visualizzati.
Collegamenti delegati: il collegamento usa credenziali fisse per accedere alla destinazione e l'utente che esegue query viene valutato in base alla sicurezza di OneLake prima di controllare l'accesso delle credenziali delegate all'origine.

Inoltre, le autorizzazioni di sicurezza di OneLake vengono valutate durante la creazione di collegamenti in OneLake. Leggere le informazioni sulle autorizzazioni di scelta rapida nel documento di sicurezza dei collegamenti.

Sicurezza di OneLake nei collegamenti pass-through

Le impostazioni di sicurezza su una cartella OneLake si applicano sempre a tutti i collegamenti interni per limitare l'accesso alle destinazioni originali del collegamento. Quando si accede ai dati tramite un collegamento a un'altra sede OneLake, l'identità dell'utente chiamante verrà utilizzata per autorizzare l'accesso ai dati nel percorso di destinazione del collegamento. L'utente deve pertanto disporre delle autorizzazioni di sicurezza di OneLake nella posizione di destinazione per leggere i dati.

Importante

Quando si accede alle scorciatoie tramite modelli semantici di Power BI utilizzando DirectLake su SQL o motori T-SQL in modalità identità delegata, l'identità dell'utente chiamante non viene passata alla destinazione della scorciatoia. L'identità del proprietario dell'elemento chiamato viene trasmessa invece, delegando l'accesso all'utente che chiama. Per risolvere questo problema, usare i modelli semantici di Power BI in modalità DirectLake su OneLake o T-SQL in modalità di identità dell'utente.

La definizione delle autorizzazioni di sicurezza di OneLake per il collegamento interno non è consentita e deve essere definita nella cartella di destinazione che si trova nell'elemento di destinazione. L'elemento di destinazione deve essere un tipo di oggetto che supporta i ruoli di sicurezza di OneLake. Se l'elemento di destinazione non supporta la sicurezza di OneLake, l'accesso dell'utente viene valutato in base al fatto che disponga dell'autorizzazione Fabric ReadAll per l'elemento di destinazione. Gli utenti non hanno bisogno dell'autorizzazione di lettura infrastruttura per un elemento per accedervi tramite un collegamento.

Sicurezza di OneLake nei collegamenti delegati

OneLake supporta la definizione delle autorizzazioni per i collegamenti, ad esempio ADLS, S3 e Dataverse. In questo caso, le autorizzazioni vengono applicate in aggiunta al modello di autorizzazione delegato abilitato per questo tipo di scorciatoia.

Supponiamo che user1 crei un collegamento S3 in un lakehouse che indirizza a una cartella in un bucket AWS S3. Quindi user2 sta tentando di accedere ai dati in questa scorciatoia.

Il collegamento S3 autorizza l'accesso per l'user1 delegato?	La sicurezza di OneLake autorizza l'accesso per l'user2 richiedente?	Risultato: user2 può accedere ai dati in S3 Shortcut?
Sì	Sì	Sì
NO	NO	NO
NO	Sì	NO
Sì	NO	NO

Le autorizzazioni di sicurezza di OneLake possono essere definite per l'intero ambito della scorciatoia o per le sottocartelle selezionate. Le autorizzazioni impostate in una cartella si applicano in modo ricorsivo alle sottocartelle, anche se la sottocartella si trova all'interno della scorciatoia. È possibile impostare la sicurezza su un collegamento esterno per concedere l'accesso all'intero collegamento o a qualsiasi sottopercorso all'interno del collegamento. Un altro collegamento interno che punta a un collegamento esterno richiede comunque all'utente di avere accesso al collegamento esterno originale.

A differenza di altri tipi di accesso nella sicurezza di OneLake, un utente che accede a un collegamento esterno richiede l'autorizzazione Di lettura infrastruttura per l'elemento di dati in cui risiede il collegamento esterno. Questa operazione è necessaria per risolvere in modo sicuro la connessione al sistema esterno.

Ottieni maggiori informazioni sui collegamenti S3, ADLS e Dataverse in Collegamenti OneLake.

Valutazione di più ruoli di sicurezza di OneLake

Gli utenti possono essere membri di più ruoli di sicurezza onelake diversi, ognuno dei quali fornisce il proprio accesso ai dati. La combinazione di questi ruoli viene chiamata "ruolo effettivo" ed è ciò che un utente vedrà quando accede ai dati in OneLake. I ruoli si combinano nella sicurezza di OneLake usando un modello UNION o meno restrittivo. Ciò significa che se Role1 concede l'accesso a TableA e Role2 concede l'accesso a TableB, l'utente sarà in grado di visualizzare sia TableA che TableB.

I ruoli di sicurezza di OneLake contengono anche la sicurezza a livello di riga e colonna, che limita l'accesso alle righe e alle colonne di una tabella. Ogni criterio cls e di sicurezza a livello di riga esiste all'interno di un ruolo e limita l'accesso ai dati per tutti gli utenti all'interno di tale singolo ruolo. Ad esempio, se Role1 concede l'accesso a Table1, ma ha la sicurezza a livello di riga in Table1 e mostra solo alcune colonne di Table1, il ruolo effettivo per Role1 sarà il sottoinsieme di sicurezza a livello di riga e CLS di Table1. Può essere espresso come (R1ols n R1cls n R1rls) dove n è l'INTERSEZIONE di ogni componente nel ruolo.

Quando si gestiscono più ruoli, la sicurezza a livello di riga e CLS viene combinata con una semantica UNION nelle rispettive tabelle. CLS è un'UNIONE diretta di set delle tabelle visibili in ogni ruolo. La sicurezza a livello di riga viene combinata tra predicati usando un operatore OR. Ad esempio, WHERE city = 'Redmond' OR city = 'New York'.

Per valutare più ruoli ognuno con sicurezza a livello di riga o CLS, ogni ruolo viene prima risolto in base all'accesso assegnato dal ruolo stesso. Ciò significa valutare l'intersezione della sicurezza a livello di oggetto, riga e colonna. Ogni ruolo valutato viene quindi combinato con tutti gli altri ruoli di cui un utente è membro tramite l'operazione UNION. L'output è il ruolo effettivo per l'utente. Questo valore può essere espresso come:

( (R1ols n R1cls n R1rls) u (R2ols n R2cls n R2rls) )

Infine, ogni collegamento in una lakehouse genera un set di ruoli dedotti usati per propagare le autorizzazioni della destinazione di collegamento all'elemento sottoposto a query. I ruoli dedotti operano in modo simile ai ruoli non dedotti, tranne che vengono risolti per primi nella destinazione di collegamento prima di essere combinati con i ruoli nel lakehouse di collegamento. In questo modo si garantisce che qualsiasi ereditarietà delle autorizzazioni nel lakehouse di collegamento venga interrotta e che i ruoli dedotti vengano valutati correttamente. La logica di combinazione completa può quindi essere espressa come segue:

( (R1ols n R1cls n R1rls) u (R2ols n R2cls n R2rls) ) n ( (R1'ols n R1'cls n R1'rls) u (R2'ols n R2'cls n R2'rls)) )

Dove R1' e R2' sono i ruoli dedotti e R1 e R2 sono i ruoli del lakehouse di scelta rapida.