Come la sicurezza OneLake controlla l'accesso ai dati

La sicurezza di OneLake è un sistema basato sui ruoli che determina chi può accedere ai dati in OneLake e quali azioni può intraprendere su quei dati. Comprendere il modello di controllo dell'accesso ai dati ti aiuta a concedere agli utenti solo l'accesso di cui hanno bisogno, così da proteggere i dati sensibili lasciando comunque che le persone giuste lavorino con essi.

Questo articolo spiega come sono strutturati i ruoli di sicurezza di OneLake, come si integrano con i permessi di workspace e degli elementi, come OneLake applica e risolve l'accesso ai tuoi dati e quali sono i limiti da tenere a mente.

Ruoli di sicurezza di OneLake

La sicurezza OneLake utilizza un modello di controllo degli accessi basato sul ruolo (RBAC) per gestire l'accesso ai dati in OneLake. Nell'esperienza di sicurezza OneLake, ogni ruolo ha i seguenti componenti:

• Permessi: I permessi che il ruolo concede sui dati, come Read o ReadWrite.
• Tipo: Il tipo di ruolo. La sicurezza di OneLake supporta solo i ruoli Grant, che consentono ai membri di accedere ai dati inclusi nel ruolo. Non sono supportati i ruoli di negazione che revocano l'accesso.
• Dati nel ruolo: Le tabelle, cartelle o schemi a cui il ruolo concede accesso. Puoi anche definire l'accesso ai dati con la sicurezza a livello di riga e colonna su tabelle.
• Membri nel ruolo: Le identità Microsoft Entra assegnate al ruolo, come utenti, gruppi o identità non utenti. Se assegni un gruppo Microsoft Entra, OneLake Security assegna il ruolo a tutti i membri del gruppo.

La sicurezza OneLake utilizza un modello di negazione predefinita, quindi gli utenti iniziano senza accesso ai dati a meno che un ruolo di sicurezza OneLake non conceda esplicitamente l'accesso. Alcuni elementi Fabric iniziano con ruoli predefiniti che danno agli utenti accesso di base in base ai permessi del loro workspace.

Autorizzazioni ed elementi supportati

I ruoli di sicurezza OneLake supportano i seguenti permessi:

• 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 sia a SELECT. Per ulteriori informazioni, vedi Sicurezza dei Metadati.
• ReadWrite: Concede all'utente la possibilità di leggere e scrivere dati in una tabella o cartella e visualizzare i metadati associati a tabelle e colonne. In termini SQL, questo permesso è equivalente a ALTER, DROP, UPDATE, e INSERT. Per ulteriori informazioni, vedi permesso ReadWrite.

Puoi creare ruoli di sicurezza OneLake per i seguenti oggetti Fabric:

Autorizzazione ReadWrite

Usa l'autorizzazione ReadWrite per concedere agli utenti con accesso in sola lettura l'autorizzazione in scrittura a dati specifici di un elemento.

L’autorizzazione ReadWrite si applica solo agli utenti con l’autorizzazione di lettura per un elemento, ad esempio agli utenti con il ruolo Visualizzatore nell’area di lavoro. L'assegnazione di ReadWrite a un Admin, Member o Contributor dell'area di lavoro non ha alcun effetto, perché questi ruoli dell'area di lavoro dispongono già delle autorizzazioni di scrittura.

ReadWrite include tutti i privilegi concessi dal permesso di lettura, oltre a concedere l'accesso di scrittura all'oggetto selezionato e al suo contenuto. Ad esempio, il permesso di scrittura in lettura su una cartella concede accesso di scrittura sia alla cartella che ai dati al suo interno.

Gli utenti con il permesso di ReadWrite possono eseguire le seguenti azioni:

• Crea, elimina o rinomina una cartella o una tabella.
• Carica o modifica un file.
• Crea, elimina o rinomina un collegamento.

Gli utenti possono eseguire operazioni di scrittura tramite notebook Spark, l'esploratore file OneLake o le API OneLake. Poiché Fabric supporta solo scritture su dati su un singolo motore, gli utenti con il permesso di scrittura ReadWrite possono scrivere su quei dati solo tramite OneLake. Tutti i motori di query continuano a imporre operazioni di lettura in modo coerente.

I ruoli di sicurezza OneLake che concedono permessi di ReadWrite non possono contenere vincoli di sicurezza a livello di riga (RLS) o di sicurezza a livello di colonna (CLS).

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

I ruoli di spazio di lavoro rappresentano il primo confine di sicurezza per i dati in OneLake. Gestiscono il piano di controllo - creando e gestendo gli elementi Fabric e i permessi - e applicano tutti gli elementi nello spazio di lavoro. Per informazioni sulle autorizzazioni specifiche di OneLake concesse da ogni ruolo dell'area di lavoro, vedere Concedere l'accesso tramite i ruoli dell'area di lavoro. Per saperne di più sui ruoli negli spazi di lavoro, consulta Ruoli negli spazi di lavoro in Fabric.

Oltre all'accesso tramite piano di controllo, i ruoli di workspace possono anche fornire accesso a elementi dati tramite i ruoli predefiniti di sicurezza di OneLake. (I ruoli predefiniti si applicano solo agli Viewer, perché i ruoli Admin, Member e Contributor hanno accesso elevato tramite il permesso di scrittura.) Un ruolo predefinito è un normale ruolo di sicurezza OneLake che Fabric crea automaticamente ad ogni nuovo elemento. Offre agli utenti con determinate autorizzazioni su aree di lavoro o elementi un livello di accesso predefinito ai dati in tali elementi. Ad esempio, gli elementi lakehouse hanno un ruolo DefaultReader che consente agli utenti con l'autorizzazione ReadAll di visualizzare i dati nella lakehouse. Questo accesso predefinito garantisce che gli utenti che lavorano con un elemento appena creato abbiano un livello base di accesso. Tutti i ruoli predefiniti utilizzano una funzione di virtualizzazione dei membri, in modo che i membri del ruolo siano utenti presenti in quell'area di lavoro con il permesso richiesto. Ad esempio, tutti gli utenti con autorizzazione ReadAll nel lakehouse.

La tabella seguente mostra i ruoli standard predefiniti. Gli oggetti potrebbero avere ruoli predefiniti specializzati che si applicano solo a quel tipo di oggetto.

Puoi modificare o rimuovere il ruolo predefinito da un elemento Fabric per cambiare l'accesso agli utenti di quel gruppo di membri.

Accesso del motore di ricerca e dell'utente ai dati

La sicurezza OneLake si basa di default sull'accesso con privilegi minimi. Alcune operazioni a livello di storage non possono applicare RLS o CLS, quindi quando una query non può essere filtrata in sicurezza, OneLake la blocca completamente invece di rischiare di esporre dati che l'utente non può vedere. Se una query sia filtrata o bloccata dipende dal percorso di accesso - un motore di query supportato o l'accesso diretto dell'utente.

Per informazioni sui motori che supportano il filtro RLS e CLS e sui requisiti per ciascuno, vedere Leggere i dati protetti con la sicurezza di OneLake.

Ambiti e applicazione

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

OneLake rappresenta tutte le tabelle come cartelle, ma dal punto di vista dei motori di sicurezza e query di OneLake in Fabric, non tutte le cartelle sono tabelle. Per essere una tabella valida, una cartella deve soddisfare le seguenti condizioni:

• La cartella esiste nella Tables/ cartella di un elemento. Per gli elementi abilitati per lo schema, la cartella deve trovarsi anche in una cartella dello schema valida.
• La cartella contiene una _delta_log cartella con i corrispondenti file JSON per i metadati della tabella.
• La cartella non contiene scorciatoie figlie.

Se configuri RLS o CLS su una tabella, OneLake nega l'accesso quando la cartella della tabella non soddisfa questi criteri. Senza RLS o CLS, OneLake tratta una cartella che non soddisfa questi criteri come una cartella e applica la sicurezza a livello di cartella.

Sicurezza a livello di riga e a livello di colonna

All'interno di un ruolo, puoi limitare l'accesso a righe e colonne specifiche di una tabella utilizzando la sicurezza a livello riga e a livello di colonna. Per maggiori informazioni su cosa fa ciascun controllo e come OneLake lo applica, consulta Sicurezza a livello di tabelle, colonne e righe in OneLake. Per informazioni su come RLS e CLS si risolvono quando un utente appartiene a più ruoli, vedi Valuta più ruoli di sicurezza OneLake.

Sicurezza dei metadati

L'autorizzazione di lettura di OneLake 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. Questa regola si applica anche alla sicurezza a livello di colonna e alla capacità dell'utente di vedere o meno una colonna in quella tabella. Tuttavia, la sicurezza di OneLake non garantisce che i metadati di una tabella non siano accessibili. Alcuni messaggi di errore e esperienze potrebbero mostrare i nomi delle colonne.

Eredità dei permessi delle cartelle ed esplorazione delle cartelle

I permessi delle cartelle influenzano una gerarchia in due direzioni:

• Eredità: I permessi concessi a una cartella si applicano verso il basso ai suoi file e sottocartelle.
• Attraversamento ed elencazione: Quando gli utenti dispongono delle autorizzazioni per un elemento figlio, la sicurezza di OneLake consente loro di elencare e attraversare le relative cartelle padre, così da poter individuare e raggiungere i dati a cui possono accedere. Traversal non concede l'accesso a file o cartelle fratelle.

Considera la seguente gerarchia di una casa sul lago in OneLake:

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

Crei un ruolo, Role1, che concede il permesso di Leggere su subfolder11. Per ereditarietà, i membri di quel ruolo possono leggere file111.txt e tutto in subfolder111. I membri possono vedere e attraversare folder1 per raggiungere subfolder11, ma non possono vedere file11.txt perché è un fratello di subfolder11 e non possono vedere Tables perché è un fratello di Files.

Files/
│
└───folder1
│   │
│   └───subfolder11 <-- READ
│       │   file111.txt
│       │
│       └───subfolder111
│            │   file1111.txt

Crei un altro ruolo, Role2, che concede il permesso di Lettura su folder2. Tramite l'ereditarietà, i membri possono leggere file21.txt. I membri possono attraversare folder2 e Files per raggiungerlo, ma non possono vedere folder1 né alcuno dei suoi elementi figli.

Files/
│
└───folder2 <-- READ
    │   file21.txt

Per le scorciatoie, il comportamento è leggermente diverso. Le scorciatoie verso fonti di dati esterne si comportano allo stesso modo delle cartelle. Tuttavia, le scorciatoie verso altre località OneLake hanno comportamenti specifici. Le autorizzazioni di destinazione del collegamento permettono l'accesso a un shortcut OneLake. Quando elenca scorciatoie, OneLake non effettua alcuna chiamata per controllare l'accesso target. Di conseguenza, quando visualizzi il contenuto di una directory, OneLake restituisce tutti i collegamenti interni indipendentemente dal tuo accesso alla destinazione. Il controllo di accesso viene valutato una volta provata ad aprire la scorciatoia, e poi vedi solo i dati per cui hai i permessi necessari.

Scorciatoie

La sicurezza di OneLake si integra con scorciatoie per proteggere i dati all'interno e all'esterno di OneLake. Le scorciatoie utilizzano una delle due modalità di autenticazione:

• Passthrough: La scorciatoia utilizza l'identità dell'utente che fa la query per accedere al target. La modalità pass-through è l'impostazione predefinita per i collegamenti OneLake-to-OneLake.
• Delegato: La scorciatoia utilizza un'identità di connessione o una credenziale configurata per accedere al target. Le scorciatoie OneLake-to-OneLake possono utilizzare l'autenticazione delegata, e le scorciatoie verso sistemi esterni utilizzano sempre l'autenticazione delegata.

Creare una scorciatoia richiede permessi sia sul percorso in cui viene creato il collegamento sia sul percorso di destinazione. Per i requisiti per creare e accedere a ogni tipo di scorciatoia, vedi OneLake Shortcut Security.

Sicurezza di OneLake nei collegamenti pass-through

Quando un utente accede ai dati tramite una scorciatoia passthrough OneLake-to-OneLake, OneLake utilizza l'identità dell'utente chiamante per autorizzare l'accesso al percorso target. L'accesso effettivo dell'utente è limitato dai permessi sia sul percorso scorciatoia che su quello di destinazione.

Non puoi definire direttamente i permessi di sicurezza di OneLake su una scorciatoia OneLake-to-OneLake. I permessi sulla cartella che contiene la scorciatoia si combinano con i permessi sul percorso di destinazione. Se l'oggetto target supporta la sicurezza OneLake, l'utente deve accedere tramite un ruolo di sicurezza OneLake. Se l'oggetto target non supporta la sicurezza OneLake, l'utente ha bisogno del permesso Fabric ReadAll sull'oggetto target. L'utente non ha bisogno del permesso di Fabric Read sull'oggetto di destinazione solo per accedere ai suoi dati tramite la scorciatoia.

Sicurezza di OneLake nei collegamenti delegati

Le scorciatoie delegate utilizzano un'identità di connessione configurata o una credenziale invece dell'identità dell'utente chiamante per accedere al target. La sicurezza OneLake limita ciò a cui l'utente chiamante può accedere tramite quella connessione.

Collegamenti a OneLake delegati

Per un collegamento OneLake-to-OneLake delegato, l'utente che effettua la chiamata vede l'intersezione tra i propri diritti di accesso nel percorso del collegamento e i diritti di accesso dell'identità di connessione configurata nel percorso di destinazione. La sicurezza a livello di colonna (CLS) è supportata su entrambi i percorsi. La sicurezza a livello di riga (RLS) è supportata sul percorso target, ma non puoi definire RLS sul percorso scorciatoia.

Scorciatoie esterne delegate

Le scorciatoie verso sistemi esterni, come ADLS, Amazon S3 e Dataverse, utilizzano una credenziale di connessione configurata per accedere alla sorgente esterna. La sicurezza OneLake viene applicata oltre all'accesso concesso da quella credenziale.

Ad esempio, supponiamo che user1 crei una scorciatoia del lakehouse verso una cartella in un bucket Amazon S3 e che user2 acceda alla scorciatoia dal lakehouse. L'utente2 può accedere ai dati S3 solo se la credenziale di connessione S3 configurata può accedere alla sorgente e la sicurezza OneLake autorizza l'utente2 ad accedere al percorso scorciatoia.

Puoi concedere a OneLake accesso di sicurezza all'intero collegamento esterno o a sottopercorsi selezionati. I permessi di una cartella vengono ereditati ricorsivamente da tutte le sue sottocartelle, incluse le cartelle contenute nel collegamento. Un utente che raggiunge una scorciatoia esterna tramite un'altra scorciatoia OneLake deve comunque essere autorizzato dalla sicurezza OneLake applicata alla scorciatoia esterna originale.

Accedere a una scorciatoia esterna tramite Spark o a una chiamata API OneLake diretta richiede anche il permesso di Fabric Read sull'elemento che contiene la scorciatoia esterna. Questo permesso è necessario per risolvere in modo sicuro la connessione al sistema esterno.

Valuta più ruoli di sicurezza di OneLake

Un utente può appartenere a più ruoli di sicurezza OneLake. OneLake combina l'accesso concesso da quei ruoli in un ruolo efficace, che determina i dati a cui l'utente può accedere. OneLake valuta il ruolo effettivo per fasi.

Gestisci l'accesso per ciascun ruolo

OneLake risolve innanzitutto ogni ruolo in modo indipendente. All'interno di un ruolo, un utente può accedere solo ai dati consentiti da tutti e tre i componenti di sicurezza:

• La sicurezza a livello di oggetto (OLS) determina quali tabelle o cartelle il ruolo può accedere.
• La sicurezza a livello di riga (RLS) limita quali righe di una data tabella il ruolo può accedere.
• La sicurezza a livello di colonna (CLS) limita quali colonne di una data tabella il ruolo può accedere.

Poiché tutti e tre i componenti si applicano, OneLake considera la loro intersezione. Ad esempio, se Role1 concede accesso a Table1 e ne limita righe e colonne, l'accesso risolto per Role1 è:

Role1 = R1_OLS ∩ R1_RLS ∩ R1_CLS

Il simbolo di intersezione (∩) significa che l'utente riceve solo l'accesso consentito da OLS, RLS e CLS in quel ruolo.

Unisci l'accesso tra i ruoli

Dopo aver risolto ogni ruolo, OneLake combina i ruoli utilizzando un modello sindacale, o meno restrittivo. Il simbolo sindacale (∪) significa che l'accesso concesso da qualsiasi ruolo diventa parte del ruolo effettivo. Se il Ruolo1 concede l'accesso alla Tabella A e il Ruolo2 concede l'accesso alla TabellaB, un utente che appartiene a entrambi i ruoli può accedere a entrambe le tabelle.

Per due ruoli, il ruolo effettivo è:

Effective role = Role1 ∪ Role2

Quando più ruoli concedono l'accesso alla stessa tabella, le regole di sicurezza a livello di riga si combinano tramite un operatore OR. Ad esempio, i predicati che consentono city = 'Redmond' e city = 'New York' si combinano come city = 'Redmond' OR city = 'New York'.

Le regole di sicurezza a livello di colonna si combinano anch'esse come unione, tranne che nell'endpoint di analisi SQL. Nell'endpoint di analisi SQL, CLS utilizza una semantica di negazione più rigida. Se un ruolo nasconde una colonna, l'endpoint blocca l'accesso a quella colonna. Di conseguenza, l'endpoint interseca le allow list CLS di tutti i ruoli dell'utente invece di combinarle in un unico insieme.

Unisci scorciatoia e accesso alla destinazione

Per un collegamento, OneLake valuta separatamente i ruoli nella posizione del collegamento e nella destinazione del collegamento. I ruoli target diventano ruoli inferi nella posizione scorciatoia. OneLake quindi interseca l'accesso combinato dai ruoli scorciatoie con l'accesso combinato dai ruoli target deduzionati. Questo passaggio impedisce che l'accesso ereditato dal percorso del collegamento prevalga sulle restrizioni della destinazione.

Per due ruoli di collegamento e due ruoli di destinazione dedotti, l'accesso effettivo è:

Effective shortcut access = (ShortcutRole1 ∪ ShortcutRole2) ∩ (InferredRole1 ∪ InferredRole2)

In questa espressione, ShortcutRole1 e ShortcutRole2 sono ruoli nella posizione scorciatoia. InferredRole1 e InferredRole2 sono i corrispondenti ruoli inferiti dalla destinazione del collegamento. Ogni ruolo viene risolto a partire dai suoi componenti OLS, RLS e CLS prima che OneLake combini i ruoli.

Limitazioni di sicurezza di OneLake

• Se assegni un ruolo di sicurezza OneLake a un utente guest B2B, devi configurare le impostazioni di collaborazione esterna per B2B in Microsoft Entra ID Esterno. Imposta l'impostazione di accesso utente ospite su modo che gli utenti ospiti abbiano lo stesso accesso dei membri (il più inclusivo).

• Se si aggiunge una lista di distribuzione a un ruolo nella sicurezza di OneLake, l'endpoint di analisi SQL non può risolvere i membri dell'elenco per imporre l'accesso. Di conseguenza, gli utenti sembrano non essere membri del ruolo quando accedono all'endpoint di analisi SQL. Anche Direct Lake su modelli semantici SQL è soggetto a questa limitazione.

• I notebook Spark richiedono che l'ambiente sia 3.5 o superiore e che utilizzino il runtime di Fabric 1.3.

• I lakehouse senza schema non supportano l'anteprima dei dati per le tabelle protette con RLS e CLS. Usa lakehouse con supporto per gli schemi e la sicurezza di OneLake.

• La sicurezza OneLake non funziona con Condivisione dati di Azure o Purview Condivisione dati. Per altre informazioni, vedere Condivisione dati di Azure.

• La tabella seguente elenca i limiti dei ruoli di sicurezza di OneLake.

  Sceneggiatura	Limite
  Numero massimo di ruoli di sicurezza di OneLake per ogni elemento di Fabric	250 ruoli per elemento (vedi nota)
  Numero massimo di membri per ogni ruolo di sicurezza di OneLake	500 utenti o gruppi di utenti per ruolo
  Numero massimo di autorizzazioni per ogni ruolo di sicurezza di OneLake	500 autorizzazioni per ruolo

  Nota

  Puoi richiedere un aumento dei ruoli per oggetto fino a 1.000. Per richiedere un aumento, contattare il supporto di Azure.

Latenze

L'applicazione delle modifiche apportate alle definizioni dei ruoli richiede circa 5 minuti.

Per le modifiche apportate a un gruppo di utenti in un ruolo di sicurezza di OneLake, OneLake impiega circa un'ora per applicare le autorizzazioni del ruolo al gruppo di utenti aggiornato. Alcuni motori Fabric hanno un proprio livello di caching, quindi potrebbe richiedere un'ora aggiuntiva per aggiornare l'accesso in tutti i sistemi.

Contenuti correlati

• Introduzione alla sicurezza di OneLake
• Ruoli nelle aree di lavoro in Microsoft Fabric
• Dati sicuri con sicurezza a livello di riga e colonna
• Panoramica delle integrazioni di sicurezza di OneLake
• Endpoint di analisi SQL e sicurezza OneLake
• Scorciatoie per la sicurezza di OneLake