Sicurezza di OneLake per gli endpoint di analisi SQL

Con la sicurezza di OneLake, Microsoft Fabric sta espandendo il modo in cui le organizzazioni possono gestire e applicare l'accesso ai dati tra carichi di lavoro. Questo framework di sicurezza offre agli amministratori una maggiore flessibilità per configurare le autorizzazioni. Gli amministratori possono scegliere tra la governance centralizzata tramite OneLake o il controllo granulare basato su SQL all'interno dell'endpoint di analisi SQL.

Modalità di accesso nell'endpoint di analisi SQL

Quando si usa l'endpoint di analisi SQL, la modalità di access selezionata determina il modo in cui viene applicata la sicurezza dei dati. Fabric supporta due modelli di access distinti, ognuno dei quali offre vantaggi diversi a seconda delle esigenze operative e di conformità:

• Modalità di identità utente: applica la sicurezza usando i ruoli e i criteri di OneLake. In questa modalità, l'endpoint di analisi SQL passa l'identità dell'utente connesso a OneLake e l'accesso in lettura è regolato interamente dalle regole di sicurezza definite in OneLake. Le autorizzazioni a livello SQL per oggetti non dati (viste, stored procedure, funzioni) sono supportate, garantendo una governance coerente tra strumenti come Power BI, notebook e lakehouse.

• Modalità identità delegata: fornisce il controllo completo tramite SQL. In questa modalità, l'endpoint di analisi SQL si connette a OneLake usando l'identità dell'area di lavoro o del proprietario dell'elemento e la sicurezza è governata esclusivamente dalle autorizzazioni SQL definite all'interno del database. Questo modello supporta approcci di sicurezza tradizionali, tra cui GRANT, REVOKE, ruoli personalizzati, sicurezza Row-Level e maschera dati dinamica.

Ogni modalità supporta modelli di governance diversi. Comprendere le implicazioni è essenziale per scegliere il corretto approccio nell'ambiente Fabric.

Confronto tra le modalità di accesso

La tabella seguente confronta come e dove si imposta la sicurezza in modalità identità utente rispetto alla modalità identità delegata, suddivisa in base al tipo di oggetto e ai criteri di accesso ai dati:

Modalità identità utente nella sicurezza di OneLake

In modalità identità utente, l'endpoint di analisi SQL usa un meccanismo di autenticazione passthrough per applicare l'accesso ai dati. Quando un utente si connette all'endpoint di analisi SQL, l'identità dell'ID Entra viene passata a OneLake, che esegue il controllo delle autorizzazioni. Tutte le operazioni di lettura sulle tabelle vengono valutate usando le regole di sicurezza definite all'interno di OneLake Lakehouse, non a livello di istruzioni GRANT o REVOKE SQL.

Questa modalità consente di gestire la sicurezza centralmente, garantendo un'imposizione coerente in tutte le esperienze dell'infrastruttura, tra cui Power BI, notebook, lakehouse e endpoint di analisi SQL. È progettato per i modelli di governance in cui access deve essere definito una volta in OneLake e rispettato automaticamente ovunque.

In modalità identità utente:

• L'accesso alla tabella è interamente gestito dalla sicurezza di OneLake. Le istruzioni SQL GRANT/REVOKE nelle tabelle vengono ignorate.

• La sicurezza a livello di riga (Row-Level security), CLS (Column-Level Security) e Object-Level Security sono tutte definite nell'esperienza OneLake.

• Le autorizzazioni SQL sono consentite per oggetti non dati come viste, stored procedure e funzioni, consentendo flessibilità per la definizione di logica personalizzata o punti di ingresso rivolti all'utente ai dati.

• Le operazioni di scrittura non sono supportate nell'endpoint di analisi SQL. Tutte le scritture devono essere eseguite tramite la pagina Lakehouse nel portale Fabric e sono controllate dai ruoli dello spazio di lavoro (amministratore, membro, collaboratore).

Per altre informazioni sul modello di autorizzazioni con la modalità di identità dell'utente, vedere il modello di controllo di accesso ai dati per la sicurezza di OneLake.

Sincronizzazione della sicurezza tra OneLake ed endpoint di analisi SQL

Un componente critico della modalità identità utente è il servizio di sincronizzazione della sicurezza. Questo servizio in background monitora le modifiche apportate ai ruoli di sicurezza in OneLake e garantisce che tali modifiche vengano riflesse nell'endpoint di analisi SQL.

Il servizio di sincronizzazione della sicurezza è responsabile dei seguenti elementi:

• Rilevamento delle modifiche apportate ai ruoli di OneLake, inclusi nuovi ruoli, aggiornamenti, assegnazioni utente e modifiche alle tabelle.

• Conversione di criteri definiti da OneLake (RLS, CLS, OLS) in strutture di ruoli del database compatibili con SQL equivalenti.

• Verificare che gli oggetti di scelta rapida (tabelle provenienti da altri lakehouse) siano convalidati correttamente in modo che le impostazioni di sicurezza di OneLake originali vengano rispettate, anche quando si accede in remoto.

Questa sincronizzazione garantisce che le definizioni di sicurezza di OneLake rimangano autorevoli, eliminando la necessità di un intervento manuale a livello SQL per replicare il comportamento di sicurezza. Poiché la sicurezza viene applicata centralmente:

• Non è possibile definire direttamente RLS, CLS o OLS usando T-SQL in questa modalità.

• È comunque possibile applicare autorizzazioni SQL a viste, funzioni e stored procedure usando le istruzioni GRANT o EXECUTE.

Ritardo nei tentativi di sincronizzazione della sicurezza

La sincronizzazione della sicurezza include un meccanismo di backoff di ripetizione dei tentativi per proteggere la stabilità del sistema ed evitare un consumo di calcolo non necessario:

• Se si verificano errori ripetuti durante l'applicazione dei ruoli di sicurezza OneLake all'endpoint di analisi SQL, il sistema potrebbe sospendere temporaneamente i tentativi di sincronizzazione automatica.

• La sincronizzazione riprende automaticamente quando viene modificato un ruolo di sicurezza OneLake esistente o ne viene creato uno nuovo.

Errori di sincronizzazione della sicurezza e risoluzione

Comportamento delle scorciatoie con la sincronizzazione della sicurezza

La sicurezza di OneLake viene applicata alla fonte della verità, quindi la sincronizzazione della sicurezza disabilita il concatenamento della proprietà per tabelle e visualizzazioni che coinvolgono scorciatoie. Ciò garantisce che le autorizzazioni del sistema di origine vengano sempre valutate e rispettate, anche per le query provenienti da un altro database.

Di conseguenza:

• Gli utenti devono avere accesso valido su sia il collegamento sorgente (attuale Lakehouse o endpoint di analisi SQL) che il destinazione in cui risiedono fisicamente i dati.

• Se l'utente non dispone dell'autorizzazione su entrambi i lati, le query hanno esito negativo con un errore di accesso.

• Quando si progettano applicazioni o viste che fanno riferimento a scelte rapide, assicurarsi che le assegnazioni di ruolo siano configurate correttamente in entrambe le estremità della relazione di scelta rapida.

Questa progettazione mantiene l'integrità della sicurezza attraverso i confini dei Lakehouse, ma introduce scenari in cui possono verificarsi errori di accesso se i ruoli tra i diversi Lakehouse non sono allineati.

Modalità delegata nella sicurezza di OneLake

In modalità identità delegata, l'endpoint di analisi SQL mantiene la compatibilità con le versioni precedenti con il modello di sicurezza SQL tradizionale. La sicurezza viene definita e applicata a livello di motore SQL e i ruoli di sicurezza e i criteri di accesso di OneLake non vengono trasportati all'accesso a livello di tabella. Tutti i filtri e il controllo di accesso, inclusi l'accesso a schemi e tabelle, Row-Level Security (RLS), Column-Level Security (CLS) e Dynamic Data Masking (DDM) devono essere definiti usando costrutti SQL (GRANT/REVOKE, criteri di sicurezza e così via).

Poiché i ruoli di sicurezza di OneLake per l'utente finale non vengono applicati direttamente, le regole di sicurezza definite in OneLake (ad esempio, le regole applicate da Spark o altri motori che leggono tramite OneLake) non verranno applicate quando gli stessi dati vengono sottoposti a query tramite l'endpoint di analisi SQL. Scegliere questa modalità quando il carico di lavoro dipende dalla semantica di sicurezza nativa di SQL o quando gli strumenti T-SQL esistenti richiedono la compatibilità completa.

Quando un utente si connette all'endpoint di analisi SQL ed esegue una query:

• SQL convalida la query sulle autorizzazioni definite a livello SQL.

• Se la query è autorizzata, il sistema passa ad accedere ai dati archiviati in OneLake.

• Questo accesso ai dati viene eseguito usando l'identità del proprietario dell'endpoint di Analisi SQL o Lakehouse, noto anche come account dell'elemento, non dell'utente connesso.

Il proprietario dell'elemento è quindi responsabile della disponibilità di autorizzazioni sufficienti in OneLake per leggere i file sottostanti per conto del carico di lavoro. Qualsiasi disallineamento tra le autorizzazioni SQL concesse agli utenti finali e l'accesso OneLake del proprietario dell'elemento genera errori di query.

Questa modalità supporta gli strumenti e le procedure T-SQL esistenti utilizzati dagli amministratori di database o dalle applicazioni, garantendo piena compatibilità per SQL GRANT/REVOKE a tutti i livelli di oggetto e con RLS, CLS e DDM definiti da SQL.

Comportamento delle scorciatoie in modalità delegata

Poiché la modalità delegata si connette a OneLake usando l'identità del proprietario dell'elemento, i collegamenti funzionano solo quando il proprietario ha accesso illimitato all'intera tabella di origine. Se nella tabella di origine è applicata una regola di sicurezza a livello di OneLake, ad esempio Row-Level Security (RLS), Column-Level Security (CLS), l'endpoint di analisi SQL blocca l'accesso a tale collegamento.

Di conseguenza:

• Le scorciatoie che puntano alle tabelle di origine che non hanno regole di sicurezza a livello di dati funzionano normalmente in modalità delegata.

• I collegamenti che puntano alle tabelle di origine con sicurezza RLS o CLS in OneLake nel produttore non sono accessibili tramite l'endpoint di analisi SQL in modalità delegata, anche se l'utente finale dispone delle autorizzazioni SQL per l'oggetto di collegamento.

• Per utilizzare i collegamenti di cui l'origine dispone di criteri di sicurezza OneLake, usare la modalità di identità utente nell'endpoint consumer in modo che l'identità dell'utente finale venga valutata rispetto alle regole di sicurezza OneLake dell'origine.

Come modificare la modalità di accesso OneLake

La modalità di accesso determina il modo in cui l'accesso ai dati viene autenticato e applicato durante l'esecuzione di query su OneLake tramite l'endpoint di analisi SQL. È possibile passare dalla modalità identità utente alla modalità identità delegata attenendosi alla procedura seguente:

1. Accedi alla tua area di lavoro Fabric e apri il tuo lakehouse. Dall'angolo in alto a destra, passa da "lakehouse" a endpoint di analisi SQL.

2. Nella barra di spostamento superiore passare alla scheda Sicurezza e selezionare una delle modalità di accesso di OneLake seguenti:

   • Identità utente : usa l'identità dell'utente connesso. Applica i ruoli di OneLake.

   • Identità delegata : usa l'identità del proprietario dell'elemento. Applica solo le autorizzazioni SQL.

3. Viene avviato un popup per confermare la selezione. Selezionare Sì per confermare la modifica.

Considerazioni relative al passaggio da una modalità all'altra

Passaggio alla modalità identità utente

• Le autorizzazioni di sicurezza a livello di riga (RLS), CLS e le autorizzazioni a livello di tabella in SQL vengono ignorate.

• I ruoli di OneLake devono essere configurati per consentire agli utenti di mantenere l'accesso.

• Solo gli utenti con autorizzazioni visualizzatore o accesso condiviso in sola lettura sono regolati dalla sicurezza di OneLake.

• I ruoli SQL esistenti vengono eliminati e non possono essere ripristinati.

Passaggio alla modalità identità delegata

• I ruoli e i criteri di sicurezza di OneLake non vengono più applicati.

• I ruoli SQL e i criteri di sicurezza diventano attivi.

• Il proprietario dell'elemento deve avere un access OneLake valido oppure tutte le query potrebbero non riuscire.

Osservazioni:

• Gli oggetti SQL non ereditano la proprietà: le scorciatoie funzionano come tabelle nell'endpoint di analisi SQL, ma deviano intenzionalmente dal concatenamento della proprietà SQL standard per mantenere una strategia di sicurezza unificata.

  • Regola di assenza di ereditarietà: gli oggetti SQL derivati (viste, stored procedure o funzioni) non ereditano le autorizzazioni dal proprietario dell'oggetto.

  • Convalida del runtime: le autorizzazioni vengono verificate sull'identità del chiamante in fase di esecuzione, assicurando che le astrazioni SQL non possano aggirare i criteri a livello di OneLake.

  • Security by design: i criteri di sicurezza rimangono coerenti se si accede ai dati tramite SQL, Spark o Power BI.

• Dipendenza del piano di controllo (corrispondenza rigorosa delle identità): la sicurezza di OneLake richiede che l'identità a cui è stato concesso l'accesso dal produttore sia la stessa identità riconosciuta durante la valutazione dell'accesso a livello dati nel consumatore. Il sistema convalida l'entità specifica a cui è stato concesso l'accesso all'origine e non espande l'appartenenza al gruppo annidata o deduce l'accesso effettivo tramite l'appartenenza indiretta.

  • Corrispondenza principale letterale: L'accesso viene valutato rispetto all'ID oggetto esatto concesso al produttore.

  • Nessuna risoluzione annidata/efficace: l'appartenenza al gruppo annidato o l'ereditarietà indiretta non viene considerata sufficiente per l'applicazione. Per un esempio funzionato, vedere il callout in modalità Identità utente in Sicurezza OneLake .

• Comportamento di valutazione delle autorizzazioni: la valutazione delle autorizzazioni varia in base al tipo di tabella in base al modello di imposizione corrente.

  • Tabelle di scelta rapida: l'accesso può essere negato quando le condizioni di autorizzazione richieste non sono soddisfatte. Si tratta di un risultato di imposizione restrittivo, non di una funzionalità DENY basata su ruoli nella sicurezza OneLake.

  • Regola generale: quando l'applicazione non può convalidare chiaramente l'accesso, il sistema applica l'esito più restrittivo.

• Sicurezza a Livello di Colonna (CLS): la progettazione di CLS mantiene un elenco rigoroso di colonne consentite.

  • La ridenominazione o la rimozione di una colonna consentita invalida la regola di sicurezza. Anche se la regola persiste nel sistema, rimane inattiva, negando l'accesso alla risorsa, fino a quando non viene ripristinata la denominazione della colonna originale.

  • Protezione della sincronizzazione: quando un criterio non è valido, la sincronizzazione dei metadati viene bloccata dalla progettazione fino a quando la regola non viene corretta nel pannello di sicurezza di OneLake.

  • Convalida dello schema: la ridenominazione delle colonne senza l'aggiornamento dei criteri di sicurezza attiva errori dell'interfaccia utente che indicano che la colonna "non esiste" fino a quando la configurazione non viene sincronizzata.

• Propagazione e sincronizzazione dei ruoli (SLA):

  • Sincronizzazione della sicurezza di OneLake: quando un ruolo di sicurezza di OneLake cambia in modalità identità utente, l'aggiornamento non è immediato. In genere, la sincronizzazione con l'endpoint di analisi SQL può richiedere fino a 5 minuti .

  • Prefisso automatico: i ruoli di sicurezza di OneLake vengono propagati all'endpoint di analisi SQL con il OLS_ prefisso .

  • Priorità di sincronizzazione: il processo di sincronizzazione della sicurezza aggiorna periodicamente lo stato dei OLS_ ruoli. Le modifiche manuali a questi ruoli non sono supportate e vengono sovrascritte durante il ciclo di sincronizzazione successivo. Se non sono state apportate modifiche alla sincronizzazione, la sincronizzazione della sicurezza non esegue l'override delle modifiche manuali.

• Sicurezza SQL del magazzino e scorciatoie: i criteri di sicurezza definiti usando costrutti SQL in un magazzino, ad esempio Row-Level Security (RLS), Column-Level Security (CLS) o Object-Level Security (OLS), vengono applicati solo all'interno del contesto di esecuzione SQL del magazzino (endpoint TDS).

Limitazioni

• Si applica solo ai lettori: la sicurezza di OneLake viene applicata principalmente agli utenti che accedono ai dati tramite l'area di lavoro a livello di visualizzatore o l'accesso agli elementi. Gli utenti con ruoli dell'area di lavoro più ampi, ad esempio Amministratore, Membro o Collaboratore , mantengono l'accesso con privilegi elevati e non sono la destinazione principale dell'imposizione della sicurezza di OneLake.

  • Eccezioni:

    • Comportamento di negazione della scorciatoia: per le tabelle basate su scorciatoie, l'applicazione può comunque negare l'accesso ad amministratori, membri o collaboratori in casi specifici.

    • Casi di errore di sincronizzazione della sicurezza: se la sincronizzazione della sicurezza non riesce ad applicare correttamente la sicurezza per determinate tabelle o ruoli, gli utenti nei ruoli di amministratore, membro o collaboratore che sono membri di tali ruoli interessati possono anche riscontrare un accesso limitato.

    • Sicurezza a livello di riga in modalità identità utente: quando Row-Level Security (RLS) è configurato in modalità di identità utente, le regole di sicurezza definite vengono applicate per tutti gli utenti, inclusi quelli nei ruoli Amministratore, Membro e Collaboratore.

• Dipendenza di sincronizzazione della sicurezza: in modalità identità utente, i ruoli di sicurezza di OneLake vengono sincronizzati con l'endpoint di analisi SQL tramite il processo di sincronizzazione della sicurezza. Fino al completamento della sincronizzazione, SQL può valutare temporaneamente l'accesso usando lo stato di autorizzazione SQL esistente. Al termine della sincronizzazione, l'endpoint SQL riflette la configurazione di sicurezza di OneLake.

• Riconoscimento dei limiti di collegamento: l'endpoint di analisi SQL può inizialmente valutare le tabelle basate su collegamenti usando la semantica degli oggetti SQL standard. Dopo l'esecuzione della sincronizzazione della sicurezza, i criteri di sicurezza di OneLake vengono applicati per garantire che l'applicazione dell'accesso sia allineata ai limiti dell'artefatto e dell'area di lavoro.

• Tempistica di applicazione dell'accesso tra artefatti: L'accesso alle tabelle basate sui collegamenti OneLake che fanno riferimento ai dati di altri artefatti viene applicato tramite ruoli di sicurezza OneLake sincronizzati. Fino a quando non si verifica la sincronizzazione, l'autorizzazione SQL può riflettere temporaneamente lo stato precedente dell'autorizzazione.

• Modifiche di proprietà nelle tabelle basate su collegamenti: le tabelle supportate da collegamenti sono rappresentate come oggetti SQL nell'endpoint di analisi SQL e pertanto supportano operazioni di proprietà SQL standard. Comandi amministrativi, quali ALTER AUTHORIZATION, possono cambiare il proprietario di una tabella basata su collegamenti. In alcuni scenari, ciò può consentire il comportamento di concatenamento della proprietà che ignora i criteri di sicurezza di OneLake e concede l'accesso non previsto ai dati sottostanti. Fino a quando non vengono introdotti meccanismi di applicazione aggiuntivi, gli amministratori devono evitare di modificare la proprietà nelle tabelle basate su scorciatoie.

• Tempo di inattività di convalida di destinazione: quando una destinazione di collegamento cambia (ad esempio, cambio nome o aggiornamento dell'URL), il database passa brevemente in modalità mono-utente mentre il sistema convalida la nuova destinazione. Durante questo periodo, le query vengono bloccate. Queste operazioni sono in genere veloci, ma, a seconda dei processi interni, possono richiedere fino a 5 minuti per la sincronizzazione.

  • La creazione di collegamenti allo schema potrebbe causare un errore noto che influisce sulla convalida e ritarda la sincronizzazione dei metadati.

• Memorizzazione nella cache dei token in modalità delegata: in modalità delegata, l'endpoint di analisi SQL memorizza nella cache il token di accesso alle risorse di archiviazione usato per recuperare i dati da OneLake per conto dell'identità del proprietario. Se le autorizzazioni del proprietario cambiano, un token rilasciato in precedenza può rimanere valido fino alla scadenza. Di conseguenza, le modifiche di accesso associate all'identità del proprietario potrebbero non essere effettive immediatamente e possono essere mantenute fino alla scadenza del token, in genere fino a 30-60 minuti.

• Le modifiche apportate ai criteri GRANT/DENY per la sicurezza di OneLake vengono applicate immediatamente e non vengono ritardate dalla memorizzazione nella cache dei token di archiviazione.

• Annullamento delle query attive: per mantenere l'integrità e la sicurezza dei dati, le query attive possono essere annullate automaticamente se una configurazione di collegamento cambia durante l'esecuzione.

• Vincoli di sicurezza a livello di riga (RLS):

  • Per l'anteprima pubblica sono supportate solo le tabelle a espressione singola. La sicurezza a livello di riga dinamica e la sicurezza a livello di riga a più tabelle non sono disponibili.

  • L'eliminazione di una colonna usata in un'espressione di filtro blocca la sincronizzazione dei metadati fino a quando la RLS non viene corretta nel pannello di sicurezza di OneLake.

• Complessità dei ruoli e sincronizzazione dei metadati: complessità elevata nei ruoli di sicurezza, in particolare quelli che coinvolgono numerose intersezioni e semantiche di unione tramite RLS, possono causare il fallimento della sincronizzazione della sicurezza. Una sincronizzazione della sicurezza non riuscita impedisce l'applicazione dei criteri di sicurezza e blocca la possibilità di sincronizzare i metadati.

• Vincoli di schema e ruolo:

  • Rinominazioni: i ruoli di sicurezza di OneLake sono associati al nome della tabella. La ridenominazione di una tabella interrompe l'associazione e i criteri non vengono migrati automaticamente. Ciò può comportare un'esposizione imprevista dei dati fino a quando i criteri non vengono riapplicati.

  • Limiti dei caratteri: i nomi dei ruoli di sicurezza di OneLake non possono superare i 124 caratteri; in caso contrario, la creazione o la sincronizzazione dei ruoli non riesce nell'endpoint di analisi SQL.

  • OLS_ modifiche ai ruoli: le modifiche degli utenti nei OLS_ ruoli non sono supportate e possono causare comportamenti imprevisti.

• Identità non supportate: i gruppi di sicurezza abilitati alla posta elettronica e le liste di distribuzione non sono attualmente supportati.

• Requisiti del proprietario di Lakehouse:

  • Il proprietario del lakehouse deve essere membro dei ruoli dell'area di lavoro Amministratore, Membro o Collaboratore; in caso contrario, la sicurezza non viene applicata all'endpoint di analisi SQL.

  • Il proprietario del lakehouse non può essere una service principal affinché la sincronizzazione della sicurezza funzioni correttamente.

Contenuti correlati

• Procedure consigliate per proteggere i dati in OneLake
• Modello di controllo accessi di sicurezza OneLake