Autorizzazioni per gli shortcut di Microsoft Fabric: regole di sicurezza interne ed esterne

By Mirko Peters · 2026-10-30

Scopri come funzionano le autorizzazioni per gli shortcut di Microsoft Fabric, confrontando il passaggio dell'identità utente interna con le regole di sicurezza delle connessioni esterne archiviate.

Automatically translated with AI from the original post. Read the English original

Le autorizzazioni per gli shortcut di Microsoft Fabric determinano come gli utenti accedono ai dati tra aree di lavoro diverse e multi-cloud senza copiare i file. Gli shortcut interni si basano sul passaggio dell'identità a livello utente, mentre le origini cloud esterne usano identità di connessioni archiviate. Comprendere questi confini di sicurezza previene l'esposizione non autorizzata dei dati e risolve gli errori di query a valle, che sono fonte di frustrazione.

Punti chiave

• Gli shortcut interni trasmettono l'identità dell'utente che esegue la query, che deve disporre di diritti di accesso diretti nel percorso di destinazione.
• Gli shortcut cloud esterni utilizzano le credenziali di connessioni archiviate, concedendo l'accesso a chiunque possa leggere il lakehouse.
• Quando i livelli di autorizzazione sono in conflitto tra il percorso dello shortcut e quello di destinazione, vince sempre la regola di sicurezza più restrittiva.
• Gli shortcut scrivibili comportano un rischio grave di eliminazioni a cascata dei dati se le autorizzazioni sulla destinazione sono configurate in modo errato.
• Pianificare i confini di sicurezza previene errori di accesso imprevisti quando si scalano architetture multi-cloud.

Come funzionano le autorizzazioni per gli shortcut di Microsoft Fabric

Quando implementi puntatori tra origini dati diverse in OneLake, la sicurezza raramente è una configurazione da impostare e dimenticare. A differenza dei modelli tradizionali di data warehouse, in cui le autorizzazioni sono centralizzate e applicate in modo uniforme alle tabelle clonate, gli shortcut di Fabric introducono un problema di identità a doppio binario. Esiste un percorso dello shortcut, da cui l'utente avvia una query, e un percorso di destinazione, dove risiedono fisicamente i dati. Fabric valuta entrambi gli endpoint prima di restituire una singola riga di dati, rendendo l'architettura di sicurezza un prerequisito di progettazione fondamentale per gli amministratori cloud.

La filosofia di base della sicurezza di Fabric si fonda sul principio del privilegio minimo, ma gli shortcut piegano le regole dell'accesso ai dati tradizionale. Poiché i dati non vengono spostati quando si crea uno shortcut, le autorizzazioni associate all'account di archiviazione sottostante, al bucket Amazon S3 esterno o al lakehouse collegato devono essere mappate con attenzione. Se un utente ha accesso in lettura all'area di lavoro che contiene lo shortcut ma non al contenitore di origine, la query non riuscirà. Al contrario, concedere autorizzazioni eccessivamente ampie a un'identità di connessione archiviata può esporre involontariamente file esterni sensibili a utenti power non autorizzati.

Shortcut interni e propagazione dell'identità utente

Gli shortcut interni, ovvero quelli che puntano da un elemento Fabric a un altro, come un lakehouse in un'area di lavoro commerciale che punta a una tabella clienti condivisa, funzionano usando la tua identità esatta di Entra ID. Quando esegui una query su uno shortcut interno, Fabric verifica se il tuo account dispone di autorizzazioni di lettura esplicite sull'area di lavoro e sull'elemento di destinazione. Se non hai l'autorizzazione per visualizzare le tabelle di origine, lo shortcut restituisce un errore.

Questo comportamento è pensato per rispecchiare la governance degli accessi tradizionale. Impedisce agli utenti avanzati di aggirare i confini dell'area di lavoro creando semplicemente collegamenti a dataset con restrizioni. Tuttavia, significa anche che chi crea i report deve ricevere autorizzazioni adeguate su più aree di lavoro, aumentando il carico amministrativo nella gestione dei team di analisi collaborativa.

Scorciatoie esterne e identità di connessione memorizzate

Le scorciatoie esterne cambiano completamente la dinamica della sicurezza. Quando punti un lakehouse di Fabric a un account di Azure Data Lake Storage Gen2, Amazon S3, Google Cloud Storage o a una posizione di rete on-premises tramite un data gateway, la propagazione dell'identità utente si interrompe al confine di Fabric. Le scorciatoie esterne, invece, si autenticano usando un'identità di connessione memorizzata.

Questa differenza operativa ha implicazioni di sicurezza enormi. Chiunque abbia accesso in lettura al lakehouse di Fabric che contiene la scorciatoia esterna può interrogare attraverso di essa l'origine dati sottostante, indipendentemente dal fatto che disponga di credenziali dirette per il bucket cloud esterno. Gli amministratori devono trattare i lakehouse con scorciatoie esterne come zone ad alta riservatezza, limitando con rigore i ruoli nell'area di lavoro per prevenire l'esfiltrazione non autorizzata di dati.

La regola del più restrittivo

Quando risolvono i problemi di accesso in Microsoft Fabric, gli amministratori si trovano spesso di fronte alla regola che governa le autorizzazioni delle scorciatoie: vince l'autorizzazione più restrittiva tra le due.

Per valutare questa regola occorre considerare entrambe le estremità del puntatore:

• Autorizzazioni del percorso della scorciatoia: le assegnazioni di ruolo (Amministratore, Membro, Collaboratore, Visualizzatore) sull'area di lavoro e sul lakehouse in cui si trova la scorciatoia.
• Autorizzazioni del percorso di destinazione: gli elenchi di controllo accessi (ACL), i criteri IAM o le autorizzazioni del database applicate direttamente ai file o alle tabelle di origine.

Se un utente è Collaboratore nell'area di lavoro che ospita la scorciatoia, ma ha solo autorizzazioni di Visualizzatore sull'account di archiviazione di destinazione, potrà soltanto leggere i dati. In alternativa, se un utente ha pieni diritti di amministratore sul dataset di origine, ma il suo ruolo nell'area di lavoro è limitato a Visualizzatore, non può modificare o gestire la configurazione della scorciatoia. Questa applicazione a doppio livello garantisce che nessuna singola configurazione errata possa compromettere completamente il perimetro di sicurezza dell'organizzazione, ma richiede una documentazione accurata quando si coordinano reparti IT separati.

Rischi delle scorciatoie scrivibili e delle eliminazioni a cascata

Le autorizzazioni di sicurezza non regolano solo chi può leggere i dati; determinano anche cosa gli utenti possono distruggere. Una delle trappole più pericolose per gli amministratori junior riguarda le scorciatoie scrivibili combinate con configurazioni di identità eccessivamente permissive.

Le scorciatoie di Fabric non eseguono eliminazioni a cascata sui dati sottostanti se elimini l'oggetto scorciatoia stesso: i dati di destinazione restano completamente al sicuro. Tuttavia, se una scorciatoia è scrivibile e un utente dispone dell'autorizzazione di eliminazione sul percorso di destinazione, eliminare file o cartelle tramite il percorso della scorciatoia cancellerà in modo permanente i dati presso l'origine. La scorciatoia funge da accesso diretto al sistema di archiviazione di destinazione, e uno script di pulizia sbagliato o un'azione accidentale di un utente possono abbattere le strutture portanti molto più rapidamente di quanto potrebbero fare le tradizionali pipeline di dati.

Conclusione

Padroneggiare le autorizzazioni delle scorciatoie di Microsoft Fabric richiede un cambiamento radicale nel modo in cui si pensa all'accesso ai dati e alla governance. Bilanciando il pass-through dell'identità utente per i carichi di lavoro interni con credenziali memorizzate e strettamente controllate per le origini multi-cloud, puoi costruire un ambiente analitico reattivo e zero-copy senza compromettere la sicurezza. Per esplorare strategie architetturali più ampie, formati dei dati e compromessi, non perdere l'occasione di ascoltare l'episodio completo per un'analisi dettagliata della moderna gestione dei dati in cloud.

Domande frequenti

Le scorciatoie di Microsoft Fabric ereditano automaticamente le autorizzazioni dell'utente?

Le scorciatoie interne usano la tua identità personale di Entra ID, il che significa che devi avere accesso in lettura esplicito sia all'area di lavoro della scorciatoia sia all'area di lavoro di destinazione. Le scorciatoie esterne, invece, usano un'identità di connessione memorizzata, consentendo a chiunque abbia accesso al lakehouse di leggere i dati esterni.

Cosa succede ai dati se elimino una scorciatoia di Microsoft Fabric?

Eliminare l'oggetto shortcut in sé non elimina i dati sottostanti nel percorso di destinazione. I file fisici o le tabelle restano del tutto al sicuro, a meno che lo shortcut non sia stato configurato come scrivibile e l'utente non abbia eliminato esplicitamente dei file tramite il percorso dello shortcut disponendo di autorizzazioni sufficienti sulla destinazione.

Come gestiscono l'autenticazione gli shortcut cloud esterni per AWS S3 o Google Cloud Storage?

Gli shortcut cloud esterni si autenticano tramite una connessione archiviata, configurata durante l'impostazione, invece di trasmettere le credenziali dei singoli utenti. Per questo motivo, gli elenchi di controllo di accesso dell'area di lavoro rappresentano la principale barriera di sicurezza per gli utenti che interrogano dati multi-cloud esterni.

Che cosa significa la regola di sicurezza "stricter-wins" in Fabric?

La regola "stricter-wins" stabilisce che, nella valutazione dell'accesso, Fabric applica il set di autorizzazioni più restrittivo riscontrato sia nel percorso dello shortcut sia in quello della destinazione. Se una delle due posizioni nega l'accesso o limita le funzionalità, tali limitazioni si applicano all'utente finale.