Integrare la sicurezza Direct Lake

La sicurezza Direct Lake garantisce che solo gli utenti autorizzati possano eseguire query sulle tabelle Delta in OneLake. È possibile gestire le autorizzazioni di accesso ai dati tramite i ruoli dell'area di lavoro. I collaboratori, i membri e gli amministratori dell'area di lavoro possono leggere i dati in OneLake. È anche possibile concedere l'accesso ai dati in OneLake tramite autorizzazioni di calcolo e a livello di elemento. La terza opzione consiste nel sfruttare la sicurezza di OneLake per applicare una sicurezza granulare basata sui ruoli in tutti i motori di calcolo di Fabric. Questo articolo illustra come allineare i modelli di autorizzazione, scegliere Single Sign-On (SSO) o identità fisse e sfruttare la sicurezza a livello di oggetto e la sicurezza a livello di riga. Per altre informazioni, vedere Panoramica della sicurezza di OneLake.

Concetti chiave e terminologia

Questo articolo presuppone che si abbia familiarità con questi concetti:

• Direct Lake usa espressioni M condivise nei metadati del modello semantico per fare riferimento alle origini dati tramite le funzioni di accesso ai dati di Power Query: AzureStorage.DataLake per Direct Lake in OneLake e Sql.Database per Direct Lake negli endpoint SQL. Tuttavia, Direct Lake non usa queste funzioni per leggere le tabelle Delta di origine. Legge le tabelle Delta direttamente tramite le API OneLake.
• Per garantire che solo gli utenti autorizzati eseseguono query sui dati, Direct Lake controlla le autorizzazioni di accesso ai dati dell'identità effettiva. L'identità effettiva dipende dalla configurazione della connessione dati. Per impostazione predefinita, Direct Lake usa SSO (Microsoft Entra ID) e usa l'identità dell'utente corrente che esegue una query sul modello semantico. È anche possibile associare un modello Direct Lake a una connessione cloud esplicita per fornire un'identità fissa.
• Se si concedono autorizzazioni di accesso ai dati tramite ruoli dell'area di lavoro, solo i membri del ruolo Collaboratori (o versione successiva) possono leggere i dati in OneLake. I visualizzatori dell'area di lavoro, tuttavia, non dispongono dell'autorizzazione di lettura in OneLake. I visualizzatori e gli utenti che non sono membri di un ruolo dell'area di lavoro possono ottenere l'accesso in lettura tramite una combinazione di autorizzazioni per gli elementi, autorizzazioni per il calcolo o ruoli di sicurezza di OneLake.
• La sicurezza di OneLake consente ai membri dei ruoli amministratore dell'area di lavoro e membro dell'area di lavoro di definire una sicurezza granulare basata sui ruoli per gli utenti nel ruolo Visualizzatore. Specificare le tabelle a cui un visualizzatore o un utente con autorizzazione di lettura esplicita può accedere ed escludere righe o colonne specifiche. Per altre informazioni sui ruoli di sicurezza di OneLake, vedere Sicurezza delle tabelle in OneLake, Sicurezza a livello di colonna in OneLake e Sicurezza a livello di riga in OneLake.

Configurazione della connessione

Configurare le connessioni dati per un modello Direct Lake allo stesso modo di altri tipi di modello semantico. Per informazioni dettagliate, vedere Connettersi alle origini dati cloud nel servizio Power BI .

Poiché Direct Lake si connette solo alle origini dati di Fabric, la configurazione SSO predefinita (Microsoft Entra ID) funziona in genere, quindi non è necessario associare modelli semantici a connessioni dati esplicite. Questo approccio riduce la complessità della configurazione e riduce il sovraccarico di gestione.

Con SSO (Microsoft Entra ID), Direct Lake verifica che l'utente corrente che interroga il modello semantico abbia accesso in lettura ai dati. Solo gli utenti con accesso in lettura possono interrogare i dati. Lo screenshot seguente mostra un modello Direct Lake usando la configurazione SSO predefinita.

Quando si usa una connessione dati esplicita con un'identità fissa anziché SSO, Direct Lake non richiede che ogni utente disponga dell'autorizzazione di lettura per i dati sottostanti. Se l'accesso SSO di Microsoft Entra rimane disabilitato nella connessione dati, le autorizzazioni dell'identità fissa determinano a quali dati Può accedere Direct Lake.

Requisiti di autenticazione

I modelli Direct Lake usano l'autenticazione microsoft Entra ID. Nella configurazione della connessione dati scegliere OAuth 2.0, Entità servizio o Identità dell'area di lavoro come metodo di autenticazione. Altri metodi, ad esempio l'autenticazione con chiave o firma di accesso condiviso, potrebbero essere visualizzati nell'interfaccia utente di configurazione, ma non sono supportati per i modelli Direct Lake.

Requisiti relativi alle autorizzazioni

I requisiti di autorizzazione variano tra Direct Lake negli endpoint SQL e Direct Lake in OneLake. Questa differenza esiste perché Direct Lake sugli endpoint SQL si basa sull'endpoint SQL Analytics della sorgente dati di destinazione, mentre Direct Lake su OneLake utilizza le API OneLake per i controlli dei permessi.

Implementazione di Direct Lake sugli endpoint SQL

Direct Lake sugli endpoint SQL controlla i permessi tramite l'endpoint SQL Analytics per verificare se l'identità effettiva che cerca di accedere ai dati abbia i permessi giusti. L'identità effettiva non richiede il permesso per leggere direttamente le tabelle Delta in OneLake. Richiede solo l'accesso di lettura all'elemento di Fabric, ad esempio un lakehouse, e l'autorizzazione SELECT su una tabella tramite il relativo endpoint di analisi SQL. Fabric concede al modello semantico i permessi necessari per leggere le tabelle Delta e i file Parquet correlati per caricare i dati delle colonne in memoria. Il modello semantico può leggere regolarmente l'endpoint di analisi SQL per verificare quali dati l'utente che interroga (o l'identità fissa) può accedere.

Direct Lake su OneLake

Direct Lake su OneLake non utilizza un endpoint di analisi SQL per controllare i permessi. Utilizza la sicurezza OneLake. Quando la sicurezza OneLake è attiva, Direct Lake su OneLake utilizza l'utente corrente (o identità fissa) per capire i ruoli di sicurezza di OneLake e applicare OLS e RLS sull'oggetto Fabric target. Se la sicurezza di OneLake non è abilitata, Direct Lake su OneLake richiede che l'identità effettiva disponga delle autorizzazioni Read e ReadAll per l'elemento Fabric di destinazione, per poter accedere alle relative tabelle Delta in OneLake. Per maggiori informazioni sui permessi Read e ReadAll, vedi Condividi elementi e imposta permessi a livello di elemento.

Utenti di Direct Lake

Gli scenari seguenti elencano i requisiti minimi di autorizzazione.

Per altre informazioni, vedere Autorizzazioni del modello semantico.

Proprietari di Direct Lake

Oltre all'identità effettiva (utente attuale o identità fissa), Direct Lake richiede che il proprietario del modello semantico abbia accesso in lettura alle tabelle sorgente, così che Direct Lake possa inquadrare il modello semantico come parte del refresh dei dati. Indipendentemente dall'utente che aggiorna un modello Direct Lake, Direct Lake controlla l'autorizzazione del proprietario per assicurarsi che il modello sia autorizzato ad accedere ai dati. I requisiti di autorizzazione di accesso ai dati del proprietario sono uguali a per gli utenti che eseguono query sul modello.

Se il proprietario del modello semantico non dispone delle autorizzazioni di accesso ai dati necessarie, Direct Lake genera l'errore seguente durante il frame: We cannot refresh this semantic model because one or multiple source tables either do not exist or access was denied. Please contact a data source admin to verify that the tables exist and ensure that the owner of this semantic model does have read access to these tables. Some restricted tables including fully restricted and partially restricted (indicating column constraints): '\<list of tables\>'.

Scorciatoie alle tabelle di origine

Le scorciatoie sono oggetti OneLake che si aggiungono a un lakehouse di Fabric o a un altro elemento di Fabric per puntare a percorsi di archiviazione interni o esterni. In un modello Direct Lake, le tabelle Delta aggiunte tramite scorciatoie appaiono come native nell'elemento Fabric connesso perché le scorciatoie sono trasparenti quando accedi ai dati tramite l'API OneLake.

Quando si accede ai collegamenti tramite endpoint Direct Lake su SQL, Direct Lake verifica innanzitutto che l'identità effettiva (utente corrente o identità fissa) possa accedere alla tabella nell'origine dati del modello semantico. Per le scorciatoie interne, dopo che il controllo è passato, Direct Lake utilizza l'identità del proprietario della sorgente dati per leggere la tabella Delta tramite la scorciatoia nell'elemento Fabric della tabella. Il proprietario dell'origine dati deve disporre dell'autorizzazione di accesso ai dati nel percorso OneLake di destinazione. Per i collegamenti esterni, il proprietario dell'origine dati necessita anche del permesso d'uso per la connessione cloud al sistema esterno che ospita la tabella Delta. Per ulteriori informazioni, vedere le scorciatoie di OneLake .

Direct Lake su OneLake ha requisiti di autorizzazione diversi perché l'endpoint di Analisi SQL non è coinvolto. Quando un utente accede ai dati tramite un collegamento interno a un'altra posizione di OneLake, l'identità effettiva (utente corrente o identità fissa) deve disporre dell'autorizzazione nella posizione di destinazione. L'identità effettiva deve essere un Collaboratore (o superiore), disporre delle autorizzazioni Lettura e Lettura completa, oppure essere in un ruolo di sicurezza OneLake che concede l'accesso in lettura.

Sicurezza a livello di oggetto (OLS) e sicurezza a livello di riga

Sia i modelli di sicurezza OneLake che quelli Direct Lake supportano OLS e RLS. OLS consente ai proprietari degli oggetti e agli amministratori di proteggere tabelle o colonne specifiche. RLS può essere utilizzata per limitare l'accesso ai dati a livello di riga in base ai filtri. Puoi definire OLS e RLS nella sicurezza OneLake, in un modello Direct Lake, o in entrambe le località.

Direct Lake su OneLake OLS/RLS con OneLake Security OLS/RLS

Direct Lake su OneLake valuta l'accesso agli oggetti protetti OLS/RLS risolvendo i ruoli di sicurezza OneLake dell'identità effettiva e applicando le regole OLS/RLS definite. I ruoli di sicurezza OneLake sono gestiti allo stesso modo dei ruoli di Direct Lake. Se l'identità effettiva appartiene a più ruoli di sicurezza in OneLake e in Direct Lake, Direct Lake esegue prima l'unione dei ruoli di sicurezza di OneLake, quindi interseca il risultato con i ruoli di Direct Lake.

Questa tabella elenca situazioni comuni di risoluzione dei problemi causate da regole di sicurezza OneLake e Direct Lake in conflitto.

Differenze di ambito OLS/RLS

L'applicazione di OLS e RLS nella sicurezza di OneLake applica le regole su tutti i motori di calcolo e garantisce un controllo unificato degli accessi per gli utenti. Ciò significa che, indipendentemente dal motore di calcolo — lakehouse, magazzino, modello semantico o altro elemento — le regole di sicurezza OneLake controllano l'accesso ai dati dell'utente. Al contrario, OLS/RLS definito all'interno di un modello semantico Direct Lake si applica solo all'interno dell'ambito di tale modello. Gli altri motori di calcolo non applicano queste regole di sicurezza Direct Lake, che possono produrre risultati diversi quando gli utenti accedono ai dati tramite altri percorsi.

OneLake OLS e metadati del modello semantico

I metadati del modello semantico includono definizioni di tabelle, colonne, relazioni e altri elementi dello schema. Gli utenti con autorizzazioni di compilazione o superiori possono visualizzare i metadati del modello tramite XML for Analysis (XMLA) e le API REST. Per altre informazioni, vedere Autorizzazioni del modello semantico.

Per proteggere i nomi sensibili di tabelle e colonne in OneLake con OneLake OLS, ricorda che la sicurezza di OneLake si applica solo ai membri del ruolo Visualizzatore dello spazio di lavoro. OneLake OLS non impedisce ai membri del ruolo Contributore (o superiore) dello spazio di lavoro di scoprire tabelle o colonne protette perché hanno già il permesso di scrittura su tutti gli elementi dello spazio di lavoro. I membri del ruolo Visualizzatore con autorizzazioni di compilazione o superiori per un modello Direct Lake possono individuare informazioni riservate sullo schema tramite i metadati del modello semantico. Questi visualizzatori con privilegi più elevati non hanno ancora accesso ai dati, ma possono vedere che le tabelle e le colonne protette esistono.

Un modello Direct Lake potrebbe esistere nello stesso spazio di lavoro dell'elemento sorgente oppure in uno spazio di lavoro separato. Concedere a un visualizzatore nella stessa area di lavoro build (o superiore) l'accesso a un modello Direct Lake tramite autorizzazioni sugli elementi. In un'area di lavoro separata, un utente potrebbe essere un collaboratore (o superiore) o avere autorizzazioni di compilazione (o superiore) per accedere ai metadati del modello.

Integrazione di OneLake OLS e Git

L'integrazione Git consente agli sviluppatori di integrare i processi di gestione del ciclo di vita delle applicazioni nella piattaforma Fabric. Il repository Git preserva la struttura dello spazio di lavoro, inclusi tutti gli elementi supportati. Gli sviluppatori hanno visibilità completa sui metadati di tutti gli elementi nel repository Git. I metadati del modello Direct Lake consentono loro di vedere che esistono tabelle o colonne protette anche se non hanno accesso all'origine dati di destinazione in un'altra area di lavoro. Per altre informazioni, vedere Che cos'è l'integrazione git di Microsoft Fabric?

Modalità di valutazione delle query in Direct Lake in SQL

Il motivo per cui sviluppare modelli semantici Direct Lake è ottenere query con prestazioni elevate su grandi volumi di dati in OneLake. Pertanto, è necessario cercare di progettare una soluzione che ottimizza le probabilità di query in memoria.

I passaggi seguenti approssimano il modo in cui vengono valutate le query Direct Lake in SQL e se hanno esito negativo. I vantaggi della modalità Direct Lake Storage sono possibili solo quando si ottiene il quinto passaggio.

1. Se la query contiene una tabella o una colonna limitata da OLS del modello semantico, viene restituito un risultato di errore (non è possibile eseguire il rendering degli oggetti visivi del report).
2. Se la query contiene una colonna limitata da CLS dell'endpoint di analisi SQL (o la tabella viene negata), viene restituito un risultato di errore (non è possibile eseguire il rendering degli oggetti visivi del report).
   1. Se la connessione cloud usa SSO (impostazione predefinita), CLS viene determinato dal livello di accesso del consumer del report.
   2. Se la connessione cloud usa un'identità fissa, CLS viene determinato dal livello di accesso dell'identità fissa.
3. Se il modello semantico utilizza Direct Lake negli endpoint SQL e la query contiene una qualsiasi tabella nell'endpoint di analisi SQL che applica la sicurezza a livello di riga o viene utilizzata una vista, la query passa alla modalità DirectQuery.
   1. Se la connessione cloud usa l'SSO (impostazione predefinita), la sicurezza a livello di riga (RLS) è determinata dal livello di accesso dell'utente del report.
   2. Se la connessione cloud utilizza un'identità fissa, la sicurezza a livello di riga viene determinata dal livello di accesso dell'identità fissa.
4. Se la query supera i limiti della capacità, torna alla modalità DirectQuery.
5. In caso contrario, la query viene soddisfatta dalla cache in memoria. Quando necessario, i dati della colonna vengono caricati in memoria .

Opzioni delle regole di accesso ai dati

È possibile configurare le regole di accesso ai dati in:

• Modello semantico.
• Endpoint di analisi SQL (Direct Lake solo sugli endpoint SQL).
• Sicurezza di OneLake.

Regole nel modello semantico

Se devi far rispettare le regole di accesso ai dati, fallo con la sicurezza di OneLake affinché le regole si applichino a tutti i motori di calcolo e garantiscano un controllo unificato degli accessi per gli utenti. Usare la RLS (sicurezza a livello di riga) o OLS del modello semantico quando agli utenti del report non viene concessa l'autorizzazione per eseguire query sul lakehouse o warehouse e la connessione cloud usa un'identità fissa anziché l'accesso SSO (Single Sign-On). SSO implica che gli utenti finali possono accedere direttamente all'origine dati e potrebbero quindi ignorare le regole di sicurezza nel modello semantico.

Regole a più livelli

Puoi imporre regole di accesso ai dati su tutti i livelli. Tuttavia, questo approccio comporta un sovraccarico di gestione e complessità aggiuntivo. In questo caso, usa un'identità fissa per la connessione cloud invece di SSO.

Confrontare le opzioni delle regole di accesso ai dati

Nella tabella seguente vengono confrontate le opzioni di configurazione dell'accesso ai dati per Direct Lake negli endpoint SQL e Direct Lake in OneLake.

Considerazioni e limitazioni

Prendere in considerazione queste limitazioni di sicurezza di Direct Lake.

• Assegna ai visualizzatori dell'area di lavoro ruoli di sicurezza OneLake che concedono l'accesso in lettura agli elementi Fabric di origine. Se un elemento di origine include collegamenti a un altro elemento Fabric, l'utente deve inoltre disporre dell'accesso in lettura a ciascun elemento Fabric di destinazione del collegamento.
• Usa un'identità fissa per isolare gli utenti da un elemento Fabric di origine. Associare il modello Direct Lake a una connessione cloud. Mantenere disabilitato l'accesso Single Sign-On sulla connessione cloud per usare l'identità fissa per gli aggiornamenti e le query.
• I modelli semantici Direct Lake che si basano sulla sicurezza Fabric OneLake sull'oggetto sorgente non supportano operazioni di backup.
• Le relazioni bidirezionali non sono supportate in un modello Direct Lake se l'oggetto Fabric di origine si affida a OneLake Security RLS.
• La sicurezza di OneLake non supporta definizioni dinamiche o configurazioni complesse di ruoli, come la combinazione di più ruoli OLS e RLS tra tabelle correlate.
• Consolidare le autorizzazioni di sicurezza di OneLake, RLS e OLS in un ruolo per utente anziché assegnare più ruoli.
• Se la configurazione di sicurezza di OneLake cambia, ad esempio a causa di modifiche di scorciatoie nell'oggetto target, aggiorna Direct Lake sui modelli OneLake che accedono a quell'elemento. È necessario aggiornare i modelli manualmente o usando le API di aggiornamento.
• Se una lakehouse ha una sicurezza OneLake:
  • L'endpoint di analisi SQL è, per impostazione predefinita, un'identità fissa al proprietario di Lakehouse, quindi la sicurezza OneLake dell'endpoint di analisi SQL è identica al proprietario (senza limitazioni). Direct Lake in SQL rimane in uso con Direct Lake, a meno che non vengano aggiunti ruoli di accesso granulari SQL aggiuntivi.
  • L'endpoint di analisi SQL può essere modificato in SSO. In questo caso, i ruoli di sicurezza di OneLake vengono aggiunti come regole di controllo di accesso granulare SQL e l'utente non può modificarli direttamente nell'endpoint di analisi SQL. A questo punto, Direct Lake su SQL esegue il fallback a DirectQuery il 100% delle volte.