Sicurezza di OneLake per gli endpoint di analisi SQL (anteprima)

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 nuovo 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 read access è regolato interamente dalle regole di sicurezza definite all'interno di OneLake. Sono supportate autorizzazioni a livello SQL per le tabelle, 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

Ecco una tabella di confronto chiara e concisa incentrata su come e dove impostare la sicurezza in modalità identità utente rispetto alla modalità identità delegata, suddivisa per tipo di oggetto e criteri di access 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 da istruzioni GRANT o REVOKE a livello 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).

Comportamento dei ruoli nell'area di lavoro

Gli utenti con il ruolo Amministratore, Membro o Collaboratore a livello di area di lavoro non sono soggetti all'imposizione della sicurezza di OneLake. Questi ruoli hanno privilegi elevati e ignorano completamente i criteri di sicurezza a livello di riga, CLS e OLS. Seguire questi requisiti per garantire che la sicurezza di OneLake venga rispettata:

• Assegnare agli utenti il ruolo Visualizzatore nell'area di lavoro o

• Condividere l'endpoint di analisi Lakehouse o SQL con gli utenti usando autorizzazioni di sola lettura . Solo gli utenti con accesso di sola lettura hanno le loro query filtrate in base ai ruoli di sicurezza di OneLake.

Precedenza dei ruoli: la regola più permissiva vince

Se un utente appartiene a ruoli OneLake multipli, il ruolo più permissivo ne definisce l'effettivo accesso. Per esempio:

• Se un ruolo concede accesso completo a una tabella e un altro applica la RLS per limitare le righe, la RLS non verrà applicata.

• Il ruolo di accesso più ampio ha la precedenza. Questo comportamento garantisce che gli utenti non vengano bloccati involontariamente, ma richiede un'attenta progettazione dei ruoli per evitare conflitti. È consigliabile mantenere ruoli restrittivi e permissivi mutuamente esclusivi quando si applicano controlli di accesso a livello di riga o di colonna.

Per ulteriori informazioni, vedere il modello di controllo dell'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 istruzioni GRANT o EXECUTE.

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, query avrà esito negativo con un errore di access.

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

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 usa lo stesso modello di sicurezza attualmente esistente in Microsoft Fabric. La sicurezza e le autorizzazioni vengono gestite interamente a livello SQL, e i ruoli OneLake o i criteri di accesso non vengono applicati a livello di tabella. Quando un utente si connette all'endpoint di analisi SQL ed esegue una query:

• SQL convalida l'accesso in base alle autorizzazioni di SQL (GRANT, REVOKE, RLS, CLS, DDM, ruoli e così via).

• 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 item account.

In questo modello:

• L'utente connesso non viene passato a OneLake.

• Si presuppone che tutti gli accessi vengano applicati a livello SQL.

• Il proprietario dell'elemento è responsabile della disponibilità di autorizzazioni sufficienti in OneLake per leggere i file sottostanti per conto del carico di lavoro.

Poiché si tratta di un modello delegato, qualsiasi errore di allineamento tra le autorizzazioni SQL e OneLake access per il proprietario genera errori di query. Questa modalità offre la compatibilità completa con:

• SQL GRANT/REVOKE a tutti i livelli degli oggetti

• Sicurezza a livello di riga definita da SQL, sicurezza a livello di colonna e Mascheramento dinamico dei dati

• Strumenti e procedure T-SQL esistenti usati dalle applicazioni o dagli amministratori di database

Come modificare la modalità di accesso OneLake

La modalità di accesso determina in che modo l'accesso ai dati viene autenticato e applicato quando si eseguono 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 superiore destro, passa da "lakehouse" all'endpoint di analisi SQL.

2. Dal riquadro di spostamento superiore passare alla scheda Security e selezionare la seguente modalità di access OneLake:

   • 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 di visualizzazione oppure accesso condiviso di sola lettura saranno soggetti alle misure di sicurezza di OneLake.

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

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.

Limitazioni

• Si applica solo ai lettori: la sicurezza di OneLake regola gli utenti che accedono ai dati come visualizzatori. Gli utenti in altri ruoli dell'area di lavoro (amministratore, membro o collaboratore) ignorano la sicurezza di OneLake e mantengono il access completo.

• Gli oggetti SQL non ereditano la proprietà: i collegamenti vengono visualizzati nell'endpoint di analisi SQL come tabelle. Quando si accede a queste tabelle, direttamente o tramite viste, stored procedure e altri oggetti SQL derivati, non comportano la proprietà a livello di oggetto; tutte le autorizzazioni vengono controllate in fase di esecuzione per impedire il bypass di sicurezza.

• Le modifiche ai collegamenti attivano brevemente un periodo di inattività per la convalida: quando una destinazione di collegamento cambia (come rinominare, aggiornare un URL), il database entra brevemente in modalità utente singolo mentre il sistema convalida la nuova destinazione. Durante questo periodo le query vengono bloccate, queste operazioni sono abbastanza rapide, ma a volte a seconda di un processo interno diverso può 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.

• Propagazione ritardata delle autorizzazioni: le modifiche alle autorizzazioni non sono istantanee. Il passaggio tra le modalità di sicurezza (Identità utente e Delegato) può richiedere tempo per propagarsi prima di rendere effettivo, ma richiede meno di 1 minuto.

• Dipendenza del piano di controllo: le autorizzazioni non possono essere applicate a utenti o gruppi che non esistono già nel piano di controllo dell'area di lavoro. È necessario condividere l'elemento di origine oppure l'utente deve essere membro del ruolo di Visualizzatore nell'area di lavoro. Si noti che lo stesso ID oggetto deve trovarsi in entrambe le posizioni. Un gruppo e un membro del gruppo non vengono conteggiati come risultati.

• L'accesso più permissivo prevale: quando gli utenti appartengono a più gruppi o ruoli, viene rispettata l'autorizzazione più permissiva Esempio: se un utente ha sia DENY in un ruolo sia GRANT in un altro, il GRANT ha la precedenza.

• Limitazioni della modalitàdelegata: in modalità delega, la sincronizzazione dei metadati nelle tabelle di collegamento può non riuscire se l'elemento di origine ha criteri di sicurezza OneLake che non concedono access tabella completa al proprietario dell'elemento.

• comportamento DENY: quando più ruoli si applicano a una singola tabella di collegamento, l'intersezione delle autorizzazioni segue la semantica di SQL Server: DENY annulla GRANT. Ciò può produrre risultati di accesso imprevisti.

• Condizioni di errore previste: gli utenti possono riscontrare errori in scenari come:

  • Destinazione collegamento rinominata o non valida

    • Esempio: se l'origine della tabella è stata eliminata.

  • Configurazione errata della sicurezza a livello di riga (Row-Level Security)

    • Alcune espressioni per il filtro RLS non sono supportate in OneLake e potrebbero consentire l'accesso non autorizzato ai dati.

    • L'eliminazione della colonna usata nell'espressione di filtro invalida la sicurezza a livello di riga e la sincronizzazione dei metadati non sarà aggiornata finché la sicurezza a livello di riga non viene corretta nel pannello di sicurezza di OneLake.

    • Per l'anteprima pubblica, sono supportate solo tabelle con singole espressioni. La RLS dinamica e la RLS con più tabelle non sono attualmente supportate.

  • Limitazioni di Column-Level Security (CLS)

    • CLS funziona mantenendo un elenco di colonne consentite. Se una colonna consentita viene rimossa o rinominata, il criterio CLS diventa non valido.

    • Quando CLS non è valido, la sincronizzazione dei metadati viene bloccata fino a quando la regola CLS non viene corretta nel pannello di sicurezza di OneLake.

  • Errore di sincronizzazione dei metadati o delle autorizzazioni

    • Se sono state apportate modifiche alla tabella, ad esempio la ridenominazione di una colonna, la sicurezza non viene replicata nel nuovo oggetto e si ricevono errori dell'interfaccia utente che indicano che la colonna non esiste.

• Le ridenominazione delle tabelle non mantengono i criteri di sicurezza: se i ruoli di sicurezza (OLS) di OneLake sono definiti a livello di schema, tali ruoli rimangono attivi solo se il nome della tabella rimane invariato. La ridenominazione della tabella interrompe l'associazione e la migrazione dei criteri di sicurezza non verrà eseguita automaticamente. Ciò può comportare un'esposizione imprevista dei dati fino a quando i criteri non vengono riapplicati.

• I ruoli di sicurezza di OneLake non possono avere nomi più lunghi di 124 caratteri; in caso contrario, la sincronizzazione della sicurezza non può sincronizzare i ruoli.

• I ruoli di sicurezza di OneLake vengono propagati nell'endpoint di analisi SQL con il prefisso OLS_.

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

• I gruppi di sicurezza abilitati alla posta elettronica e le liste di distribuzione non sono supportati.

• Il proprietario del lakehouse deve appartenere ai ruoli di amministratore, membro o collaboratore dell'area di lavoro; 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