Perché il tuo RLS di Power BI funziona in Desktop ma perde dati in Fabric

By Mirko Peters · 2026-08-11

Bentornato sul blog di data engineering e analytics! Se hai mai costruito una dashboard spettacolare, verificato la Row-Level Security in locale in Power BI Desktop, pubblicato tutto nel cloud e poi ti sei preso un colpo quando un utente standard ha visto dati che non avrebbe dovuto vedere, non sei affatto solo. L'architettura di sicurezza negli ambienti analytics moderni è notoriamente complicata

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

Titelbild: Why Your Power BI RLS Works in Desktop But Leaks in Fabric

In questo post vediamo nel dettaglio perché il tuo RLS di Power BI potrebbe perdere dati dopo il deployment, in che modo la mappatura delle identità cambia tra un ambiente e l'altro e come implementare pattern di sicurezza solidi e nativi del cloud. Analizziamo insieme l'architettura alla base della sicurezza dei dati aziendali.

In questo post approfondiremo perché la tua RLS di Power BI potrebbe perdere dati dopo il deployment, come il mapping delle identità cambia tra un ambiente e l'altro e come puoi implementare pattern di sicurezza robusti e cloud-native. Vediamo insieme l'architettura alla base della sicurezza dei dati in azienda.

Prima di scrivere una sola riga di Data Analysis Expressions, o DAX, devi stabilire il modello mentale corretto per la sicurezza. Troppi sviluppatori trattano la Row-Level Security come una semplice casella da spuntare o un'impostazione amministrativa rapida alla fine di un progetto. In realtà la sicurezza è un sistema interconnesso.

Prima di scrivere una sola riga di Data Analysis Expressions, o DAX, devi stabilire il modello mentale corretto per la sicurezza. Troppi sviluppatori trattano la Row-Level Security come una semplice casella da spuntare o un'impostazione amministrativa rapida da configurare alla fine del progetto. In realtà, la sicurezza è un sistema interconnesso.

Progettazione dei ruoli: pochi ruoli mirati battono una moltitudine di ruoli sovrapposti. Creare cento ruoli statici, uno per utente, diventerà rapidamente un incubo amministrativo.
Progettazione dei ruoli: pochi ruoli mirati sono meglio di tanti ruoli sovrapposti e disordinati. Creare cento ruoli statici, uno per utente, diventerà rapidamente un incubo amministrativo.
Contesto dinamico: la sicurezza deve reagire a chi sta visualizzando il report e a cosa lo riguarda nella struttura più ampia dell'organizzazione.
Realtà del cloud: la risoluzione delle identità e le impostazioni del tenant in Fabric possono cambiare radicalmente il comportamento rispetto alla tua macchina locale. Capire come il cloud associa la tua identità utente è indispensabile.

Scrivere espressioni DAX sicure per i tuoi ruoli è la pietra angolare di un isolamento dei dati efficace. In base alla struttura organizzativa e alla scala, probabilmente sceglierai tra pattern di filtro statici e dinamici.

Scrivere espressioni DAX sicure per i tuoi ruoli è la pietra angolare di un isolamento efficace dei dati. A seconda della struttura organizzativa e della scala della tua azienda, probabilmente sceglierai tra pattern di filtro statici e dinamici.

RLS statica (semplice, pubblico fisso)

Esempio su DimRegion:
DimRegion[Region] = "US"

RLS dinamica tramite tabella ponte (consigliata)

Tabelle: Users (UPN, UserKey), UserRegion (UserKey, RegionKey), DimRegion (RegionKey, Region)
Filtro del ruolo su Users:
Users[UPN] = USERPRINCIPALNAME()
Facoltativamente, limita DimRegion usando una relazione da Users > UserRegion > DimRegion.

Da evitare

La sicurezza basata su colonne calcolate, che viene valutata al momento dell'aggiornamento dei dati e non dinamicamente in base al contesto dell'utente.
USERNAME() in Fabric (usa sempre USERPRINCIPALNAME(); testa con cura i formati delle email e i suffissi UPN).
Inserire direttamente nelle espressioni di filtro email singole o domini.

Pattern dinamici utili

Modelli multi-tenant: mappa il TenantId dalla tabella centrale Users direttamente verso le tabelle dei fatti e delle dimensioni.
Gerarchie: memorizza i collegamenti tra manager e subordinati, materializza una tabella di accesso e filtra per tutti i discendenti strutturali dell'utente che visualizza il report.

La forma del modello dati definisce i confini della sicurezza. Usa filtri a direzione singola dove possibile, per evitare percorsi molti-a-molti ambigui che aggirano involontariamente i vincoli di sicurezza. Crea dimensioni di sicurezza dedicate, come tabelle ponte utente-accesso, invece di incorporare logica di business complessa direttamente nelle tabelle dei fatti. Preferisci sempre pochi ruoli riutilizzabili combinati con filtri dinamici a decine di ruoli statici.

La forma del tuo modello dati definisce i confini della sicurezza. Usa filtri a direzione singola dove possibile, per evitare percorsi molti-a-molti ambigui che possono aggirare involontariamente i vincoli di sicurezza. Crea dimensioni di sicurezza dedicate, come tabelle ponte utente-accesso, invece di incorporare logica di business complessa direttamente nelle tabelle dei fatti. Preferisci sempre pochi ruoli riutilizzabili combinati con filtri dinamici rispetto a decine di ruoli statici.

Assegnazioni senza sorprese (utenti e gruppi)

Gestire le assegnazioni in modo efficiente è fondamentale per la salute operativa a lungo termine. Associa sempre i ruoli a gruppi di Azure AD anziché a singoli account utente, così il sistema scala senza problemi quando i dipendenti cambiano team. Per evitare appartenenze obsolete, pianifica revisioni trimestrali degli accessi con i proprietari dei gruppi. Attenzione alle sovrapposizioni tra gruppi: un utente che appartiene a più gruppi di sicurezza può ampliare involontariamente l'accesso ai dati.

Desktop vs Fabric: cosa cambia dopo la pubblicazione

È qui che avviene la maggior parte delle fughe di dati. In Power BI Desktop lavori in un sandbox locale controllato. Una volta pubblicato in Microsoft Fabric, il cloud prende il controllo della gestione delle identità. USERPRINCIPALNAME() restituisce l'indirizzo email cloud in Fabric, mentre le anteprime in Desktop possono comportarsi diversamente a seconda delle credenziali locali. Inoltre, il proprietario del set di dati, le credenziali di aggiornamento, le impostazioni dell'area di lavoro e la latenza di sincronizzazione dei gruppi in Azure AD possono modificare ciò che un utente può effettivamente vedere.

Test che individuano davvero le fughe di dati

Non affidarti mai esclusivamente alla funzione "Visualizza come" di Power BI Desktop per approvare la sicurezza in produzione. Anche se è utile per verifiche rapide, devi eseguire i test in Fabric. Convalida con gruppi di sicurezza e account utente reali in un'area di lavoro non di produzione. Verifica ogni singolo ruolo nelle pagine principali dei report e nei visual sensibili. Valuta la possibilità di automatizzare controlli a campione tramite endpoint XMLA o strumenti di automazione, per esportare piccoli set di risultati per account di test noti.

Governance e operatività

Mantenere la sicurezza nel tempo richiede una governance rigorosa. Cataloga i ruoli, documenta i relativi filtri DAX, elenca le tabelle interessate e annota i destinatari previsti. Applica il controllo delle modifiche tramite pull request, richiedendo le evidenze dei test RLS prima di unire gli aggiornamenti del modello. Definisci contratti di dati chiari che specifichino quali dimensioni e tabelle dei fatti devono partecipare alla RLS. Esegui ricertificazioni trimestrali delle appartenenze ai gruppi e monitora i report ad alto rischio per individuare anomalie.

Schemi di errore comuni (e relative soluzioni)

In caso di problemi, verifica questi schemi di errore comuni:

Funziona in Desktop, perde dati in Fabric: causato dall'uso di USERNAME() o da formati di identità non coerenti. Soluzione: standardizza l'uso di USERPRINCIPALNAME() e allinea i valori di Users[UPN].
L'utente vede troppo: causato da un percorso molti-a-molti che aggira la sicurezza. Soluzione: introduci una dimensione di sicurezza e rafforza le relazioni.
L'accesso di un ex team persiste: causato da appartenenze obsolete ai gruppi di Azure AD. Soluzione: automatizza i flussi di ricertificazione e i processi di rimozione.
Colonna calcolata usata per l'identità: non produce alcun effetto per singolo utente. Soluzione: sposta la logica nel DAX dei filtri di ruolo sulle tabelle del modello.

Checklist di avvio rapido (questa settimana)

Aggiungi una tabella Users con chiave USERPRINCIPALNAME() e mettila in relazione con le tabelle degli accessi.
Converti i filtri fissi in filtri dinamici basati su tabelle, dove opportuno.
Sostituisci qualsiasi logica USERNAME() con USERPRINCIPALNAME() e ripeti i test in Fabric.
Associa i ruoli ai gruppi di AAD e pianifica una revisione degli accessi con i proprietari dei gruppi.
Pubblica in un'area di lavoro di test, convalida con utenti reali e correggi eventuali lacune nell'identità.
Documenta ruoli, DAX e tabelle nel README del modello.

Asset SEO suggeriti

Slug URL: power-bi-row-level-security-architecture
Meta title: Power BI Row-Level Security: Architettura, pattern DAX e governance pronta per il cloud
Meta description: Vai oltre la casella di controllo RLS. Scopri i pattern DAX dinamici, la progettazione dei ruoli, il mapping con Azure AD e i test specifici per Fabric per proteggere davvero i dati sensibili.
Parole chiave: Power BI, Row-Level Security, RLS, USERPRINCIPALNAME, gruppi di Azure AD, Fabric, RLS dinamica, data governance

Conclusione

La row-level security non è una funzionalità che si configura una volta e poi si dimentica. È un sistema vivo e in continua evoluzione, composto da modelli di dati, relazioni, formule DAX, mapping delle identità e impostazioni di governance nel cloud. Abbandonando i ruoli statici e fragili, adottando tabelle ponte dinamiche e solide e testando con rigore all'interno di Microsoft Fabric, puoi garantire che i tuoi dati restino protetti indipendentemente da come cresce e cambia la tua organizzazione.

Per approfondire questo argomento e ascoltare strategie di implementazione pratiche, non perdere il nostro episodio podcast correlato: Implement Power BI Row-Level Security in Microsoft Fabric. Non limitarti a bloccare i dati: progetta un'architettura di sicurezza resiliente che si adatti all'evoluzione della tua organizzazione!