Sicurezza a livello di riga (RLS) in Power BI: una guida completa

La Row-Level Security (RLS) in Power BI ti permette di controllare quali righe di dati possono vedere gli utenti in base ai filtri. Questa funzionalità è particolarmente utile quando più utenti devono accedere a un report condiviso, ma con viste personalizzate in base ai loro ruoli o reparti.

In questo tutorial, ti guiderò verso una comprensione pratica e approfondita della RLS, incluse le sue configurazioni statiche e dinamiche, i passaggi operativi d’implementazione, tecniche avanzate a livello enterprise ed errori comuni che ho imparato a evitare. Condividerò anche le best practice e confronterò la RLS con altri modelli di sicurezza.

Se stai iniziando ora con Power BI, ti consiglio di dare un’occhiata al nostro percorso di competenze Power BI Fundamentals, che ti aiuterà a padroneggiare tutte le abilità essenziali di cui avrai bisogno.

Che cos’è la Row-Level Security?

La Row-Level Security (RLS) è una funzionalità di sicurezza in Power BI che limita l’accesso alle righe di una tabella in base all’identità dell’utente che visualizza il report. Invece di duplicare i report per diversi gruppi di utenti, la RLS ti consente di applicare filtri a livello di dato in modo che ciascun utente veda solo i dati a cui è autorizzato ad accedere.

Questo è fondamentale per preservare la riservatezza e l’integrità dei dati, specialmente in scenari che coinvolgono informazioni sensibili o proprietarie. La RLS opera all’interno del modello dati di Power BI e garantisce che gli utenti non autorizzati non possano accedere ai dati riservati, nemmeno tramite metodi indiretti come slicer o drill-down.

Ruoli e filtri

L’implementazione della RLS si basa su tre elementi fondamentali:

• Ruoli: raggruppamenti logici con regole di accesso definite.
• DAX filtri: espressioni che determinano a quali dati può accedere ciascun ruolo.
• Assegnazioni utente: configurazione di quali utenti o gruppi appartengono a quali ruoli.

Questi elementi lavorano insieme per valutare ogni query rispetto alle condizioni di accesso prima di restituire i risultati.

Casi d’uso

La RLS è altamente applicabile in molti settori e scenari, tra cui:

• Territori di vendita: i sales manager vedono solo i dati di performance della loro regione.
• Sanità: i medici accedono solo alle cartelle dei pazienti a loro assegnati.
• SaaS multi-tenant: i clienti vedono solo i dati della propria organizzazione in dashboard condivise.

Questo modello di sicurezza consente di mantenere sicuri i dataset condivisi riducendo al minimo duplicazioni e oneri amministrativi.

Architetture RLS statiche vs dinamiche

La sicurezza a livello di riga può essere suddivisa in due tipi: statica e dinamica.

Ne ho riassunto le differenze nella tabella seguente:

Consiglio: usa la RLS statica per gruppi utenti piccoli e stabili. Usa la RLS dinamica per ambienti in crescita o su larga scala.

Di seguito vedremo alcune implementazioni di esempi sia statici che dinamici.

Implementazione RLS statica

La RLS statica prevede la creazione di ruoli con filtri DAX hardcoded. Ogni ruolo corrisponde a un gruppo o segmento specifico, come una regione geografica o un reparto.

Ecco i passaggi generali per implementare una RLS statica:

1. Crea un ruolo chiamato, ad esempio, "Region_East".
2. Applica a quel ruolo un filtro come [Region] = "East".
3. Assegna utenti specifici al ruolo nel Power BI Service.

Implementazione RLS dinamica

La RLS dinamica utilizza funzioni come USERNAME() o USERPRINCIPALNAME() combinate con tabelle di mapping per filtrare dinamicamente i dati in base all’identità dell’utente.

Ecco i passaggi generali per implementare una RLS dinamica:

1. Crea una tabella di mapping che colleghi gli utenti ai livelli di accesso. Questa sarà la tua tabella di sicurezza. Dovrebbe includere colonne come email degli utenti, le loro regioni di accesso e i loro nomi.
2. Scrivi un filtro DAX come: [Region] = RELATED(UserRegion[Region])
3. Filtra quella tabella con: UserRegion[Email] = USERPRINCIPALNAME()

Configurare la Row-Level Security in Power BI Desktop

Ora vedremo una guida rapida su come impostare la RLS statica utilizzando un semplice dataset di vendite.

1. Creare un dataset di esempio con Python

Per testare la RLS, crea un dataset di esempio con Python:

import pandas as pd

data = {
    'Salesperson': ['Alice', 'Bob', 'Charlie', 'Alice', 'Bob', 'Charlie'],
    'Region': ['East', 'West', 'South', 'East', 'West', 'South'],
    'SalesAmount': [15000, 20000, 18000, 17000, 21000, 16000],
    'Email': ['alice@company.com', 'bob@company.com', 'charlie@company.com'] * 2,
    'Date': pd.date_range(start='2025-01-01', periods=6, freq='M')
}

sales_df = pd.DataFrame(data)
sales_df.to_csv('sample_sales_data.csv', index=False)

2. Importare in Power BI e creare una visualizzazione di riferimento

1. Apri Power BI Desktop.
2. Vai a Home > Get Data > Text/CSV.
3. Seleziona il file sample_sales_data.csv.

4. Carica i dati nel modello.

Assicurati che i tipi di dato siano corretti e verifica che la colonna Email corrisponda ai formati di identità di accesso (di solito l’email).

5. Crea un grafico a colonne in pila di base in Power BI. Trascina il campo Date sull’asse X e SalesAmount sull’asse Y.

Ecco come dovrebbe apparire il tuo grafico:

Trovi ulteriori informazioni su come usare Power BI nel nostro cheat sheet, come mostrato sotto.

3. Creare i ruoli

Ora creiamo alcuni ruoli per definire quali ruoli possono avere quali permessi.

1. Vai a Modeling > Manage Roles.

2. Clicca su Create e assegna un nome al ruolo, ad esempio SalesRegionStatic.
3. Seleziona la tabella pertinente.
4. Inserisci un’espressione DAX di filtro:

[Email] = “charlie@company.com”

Ecco come dovrebbe apparire l’interfaccia:

5. Salva e chiudi la finestra di dialogo.

Se le modifiche vengono salvate correttamente, comparirà una notifica con barra verde come mostrato sotto.

4. Testare i ruoli

1. Vai a Modeling > View as Roles.

2. Scegli il ruolo SalesRegionStatic che abbiamo creato in precedenza.

3. Visualizza i grafici del report filtrati da quella identità.

Come vedi nell’immagine sotto, il grafico è stato filtrato per mostrare solo i dati in cui l’email è “charlie@company.com”.

Questo consente una validazione locale prima della distribuzione.

Assegnare utenti e gestire i ruoli nel Power BI Service

Una volta configurati e testati i ruoli RLS in Power BI Desktop, il passaggio successivo è pubblicare il report su Power BI Service. Questo ti permette di assegnare utenti specifici o gruppi di sicurezza a ciascun ruolo, assicurando che il controllo degli accessi sia applicato quando il report viene condiviso.

1. Pubblicare il report su Power BI Service

1. In Power BI Desktop, clicca su Home > Publish > To Power BI.
2. Scegli lo spazio di lavoro di destinazione nel tuo Power BI Service.

3. Dopo la pubblicazione, accedi a Power BI Service su https://app.powerbi.com.

Ecco come appare il mio nel servizio Power BI sul web.

La pubblicazione è un prerequisito per configurare le assegnazioni dei ruoli RLS, poiché i ruoli definiti in Power BI Desktop vengono trasferiti insieme al dataset.

2. Accedere alle impostazioni di sicurezza

1. Seleziona il menu Altre opzioni per il tuo semantic model pertinente.Clicca sui puntini di sospensione (...) accanto al dataset e seleziona Security.
2. Vedrai un elenco dei ruoli definiti in Power BI Desktop.

Qui è dove assegni utenti o gruppi di Azure Active Directory (AAD) a ciascun ruolo.

3. Assegnare utenti singoli e gruppi di sicurezza

Per assegnare gli utenti, inserisci i loro indirizzi email completi nella casella di testo sotto il ruolo desiderato, premi Invio e clicca su Add.

Per assegnare gruppi AAD, usa il nome del gruppo (ad es., Sales_Region_East o Finance_Team). Assicurati che il gruppo sia già definito e gestito in Azure Active Directory.

4. Verificare l’accesso assegnato

Dopo aver assegnato utenti o gruppi, prenditi del tempo per verificare che i dati corretti siano presentati al gruppo giusto.

Ogni persona vedrà solo i dati filtrati dall’espressione DAX collegata al proprio ruolo. Non riceveranno una notifica diretta dell’assegnazione del ruolo, quindi potresti voler comunicare eventuali istruzioni di accesso dopo aver completato la verifica.

5. Testare le assegnazioni dei ruoli in Power BI Service

1. Nella stessa pagina, clicca sul nome della tua RLS definito in precedenza, poi sui puntini di sospensione (...), quindi su Test as role.

2. Power BI aprirà una versione di sola lettura del report mostrando solo i dati consentiti dal ruolo selezionato.

Per la RLS dinamica, puoi anche simulare cosa vedrà un utente specifico:

• Clicca su Test as role.
• Inserisci l’email di un utente per simulare la sua esperienza.

Questo è utile per assicurarti che i tuoi filtri dinamici (ad es., basati su USERPRINCIPALNAME()) funzionino correttamente.

Tecniche di implementazione avanzate

La RLS può essere ulteriormente integrata nel tuo flusso di lavoro Power BI tramite alcune tecniche avanzate. Ecco quelle da tenere presenti:

1. Integrazione con gruppi di sicurezza

L’uso dei gruppi di sicurezza di Azure Active Directory (AAD) ti permette di assegnare permessi di accesso a interi gruppi invece che a singoli utenti. 

Questa pratica è particolarmente utile nelle aziende in cui i dipendenti entrano o escono frequentemente dai team, poiché elimina la necessità di aggiornare manualmente i permessi di accesso in Power BI.

2. Considerazioni per modelli dati complessi

Quando costruisci modelli dati su larga scala, assicurati che la RLS non interferisca con le relazioni e la propagazione dei filtri. 

Ecco alcuni suggerimenti:

• Usa un design a schema a stella per evitare join complessi.
• Limita l’uso di relazioni bidirezionali se non necessarie.
• Evita relazioni ambigue che potrebbero portare a filtraggi errati.
• Ottimizza le performance riducendo al minimo le colonne calcolate nelle tabelle fortemente filtrate.

3. Approcci ibridi

Un approccio ibrido alla RLS combina tecniche statiche e dinamiche. 

Ad esempio, puoi definire un ruolo statico per concedere l’accesso a una specifica business unit e applicare un filtro dinamico all’interno di quel ruolo in base agli indirizzi email o ai nomi utente. Questo metodo consente una logica di sicurezza a livelli e flessibile.

4. Sicurezza a livello di oggetto (OLS)

La Object-Level Security ti permette di nascondere intere tabelle o colonne a determinati ruoli. Completa la RLS aggiungendo un ulteriore livello di protezione dei dati. L’OLS può essere usata per campi sensibili come stipendi o informazioni mediche.

Strategie di test e validazione

1. Test in Desktop

Power BI Desktop offre un modo utile per simulare viste di utenti diversi tramite la funzione “View as” dei ruoli. Questa funzione aiuta gli sviluppatori di report a validare che la logica di Row-Level Security funzioni correttamente prima di pubblicare il report.

Come testare la RLS in Power BI Desktop:

1. Clicca sulla scheda Modeling.
2. Seleziona View as dalla ribbon.
3. Scegli i ruoli che hai configurato (ad es., SalesRegionStatic).
4. Facoltativamente inserisci un nome utente/email di test se usi la RLS dinamica.
5. Clicca su OK ed esamina come vengono filtrate le visualizzazioni.

Questo simula il report come se lo stesse visualizzando un utente assegnato a quel ruolo. È particolarmente utile quando si testano filtri RLS dinamici che dipendono da funzioni DAX come USERPRINCIPALNAME().

2. Test nel Service

Una volta pubblicata su Power BI Service, la RLS dovrebbe essere testata di nuovo nell’ambiente cloud per garantirne l’accuratezza.

Come testare la RLS in Power BI Service:

1. Vai al dataset nel tuo spazio di lavoro.
2. Clicca sui ... accanto al dataset > Security.
3. Seleziona un ruolo > clicca su Test as role.
4. Usa l’opzione “Test as specific user” per simulare i filtri RLS dinamici.

Questo assicura che i filtri si comportino come previsto per gli utenti reali.

3. Suggerimenti chiave per la validazione

Per la validazione, puoi valutare l’uso di account di test o identità di servizio per imitare l’uso reale. Tutti i filtri sui grafici chiave, come tabelle e chart, dovrebbero essere rivisti periodicamente.

Controlla inoltre con attenzione slicer, drillthrough e segnalibri per assicurarti che non stiano facendo trapelare dati non autorizzati.

Errori comuni e soluzioni

L’implementazione della RLS può presentare alcuni problemi: ecco i più comuni e come risolverli.

1. Problemi post-pubblicazione

Dopo la pubblicazione su Power BI Service, alcuni utenti riscontrano che la RLS non si comporta come previsto, anche se funzionava in Power BI Desktop.

Soluzioni:

• Assicurati di ripubblicare il report dopo aver apportato modifiche a ruoli o filtri.
• Verifica che l’email usata in USERPRINCIPALNAME() corrisponda al formato di dominio di accesso presente nel dataset.

2. Conflitti di ruolo nello spazio di lavoro

Gli utenti con determinati ruoli nello spazio di lavoro (Admin, Member) potrebbero bypassare involontariamente la RLS.

Soluzioni:

• Assegna gli utenti come Viewer nello spazio di lavoro per applicare le regole RLS.
• Evita di assegnare diritti di Contributor/Admin se non necessari per lo sviluppo dei contenuti.

3. Limitazioni delle funzioni DAX

Errori comuni derivano dall’uso improprio di funzioni DAX come USERNAME() e USERPRINCIPALNAME():

• USERNAME() può restituire un nome account locale invece di un’email quando testato in Desktop.
• Usa USERPRINCIPALNAME() per avere coerenza con il comportamento delle identità in cloud.

Suggerimenti:

• Aggiungi una tabella di riferimento con email di esempio per facilitare i test locali.
• Usa logica condizionale o valori predefiniti in DAX per prevenire errori di filtro.

4. Sfide con DirectQuery e SSO

La RLS dinamica con origini DirectQuery richiede particolare attenzione, soprattutto se utilizzata con Single Sign-On (SSO).

Problemi comuni:

• Una configurazione errata del gateway può bloccare l’impersonificazione degli utenti.
• La configurazione SSO con Kerberos può fallire se gli SPN sono configurati in modo errato.

Soluzioni:

• Consulta la documentazione Microsoft sull’SSO con i gateway di Power BI.
• Collabora da vicino con i team IT e infrastruttura per abilitare la delega Kerberos.

Rimuovere o disabilitare la RLS per l’accesso pubblico

Potrebbero esserci scenari in cui la RLS deve essere rimossa temporaneamente (ad es., per demo o dashboard aperte) o definitivamente (ad es., quando si condividono dati con stakeholder esterni). In tali casi, occorre prestare attenzione alle impostazioni di visibilità per evitare fuoriuscite indesiderate.

Disabilitare la RLS in Power BI Desktop

Per disabilitare la RLS:

1. Apri il tuo report in Power BI Desktop.
2. Vai a Modeling > Manage Roles.
3. Seleziona ed elimina tutti i ruoli o disattiva i loro filtri.
4. Salva e ripubblica il dataset su Power BI Service.

Una volta rimossa, tutti gli utenti potranno accedere all’intero dataset a meno che non siano presenti altre misure di sicurezza.

Condivisione sicura senza RLS

Se la RLS non è fattibile o necessaria, considera le seguenti pratiche per mantenere la sicurezza dei dati:

• Usa permessi a livello di dataset: condividi il dataset o il report solo con utenti fidati e usa in modo appropriato i permessi dello spazio di lavoro (Viewer, Contributor).
• Evita la pubblicazione sul web: “Publish to Web” rimuove tutti i controlli di sicurezza. Usa invece “Embed for organization” o Power BI Embedded per una condivisione pubblica in modalità sicura.

Rimuovere la RLS non significa eliminare ogni sicurezza. Usa altri livelli di controllo degli accessi e funzioni di condivisione in Power BI Service per garantire una diffusione dei dati responsabile.

Best practice per la distribuzione enterprise

Una distribuzione della Row-Level Security su scala enterprise richiede pianificazione attenta, architettura scalabile e governance adeguata. Questa sezione illustra best practice comprovate in diverse dimensioni dell’implementazione RLS.

1. Modellazione dei dati

Un modello dati ben progettato supporta configurazioni RLS efficienti e manutenibili.

Raccomandazioni:

• Segui uno schema a stella con relazioni chiare tra tabelle di fatto e dimensioni.
• Evita relazioni bidirezionali non necessarie che potrebbero introdurre ambiguità nel filtraggio.

2. Gestione dei ruoli

Gestire i ruoli RLS in modo centralizzato e coerente aiuta a ridurre gli errori e migliorare la collaborazione.

Raccomandazioni:

• Mantieni un documento di definizione dei ruoli per tracciare la logica RLS e le espressioni DAX.
• Usa nomi di ruolo descrittivi (ad es., “Region_East_Sales”) per evitare confusione.

3. Ottimizzazione delle performance

La RLS può impattare le prestazioni del report, specialmente con filtri complessi o dataset di grandi dimensioni.

Raccomandazioni:

• Pre-aggrega i dati, dove possibile, utilizzando tabelle di riepilogo.
• Riduci al minimo l’uso di colonne calcolate nella logica RLS.
• Usa indicizzazione e query ottimizzate nei sistemi sorgente per supportare scenari DirectQuery.

RLS vs modelli di sicurezza alternativi

Confrontiamo ora le differenze tra Row-Level Security (RLS) e altre funzionalità di sicurezza, in particolare la Object-Level Security (OLS).

1. Granularità e caso d’uso

La RLS consente il controllo degli accessi a singole righe di dati, ideale per filtrare per identità utente, area geografica, reparto o business unit. L’OLS, invece, controlla l’accesso a intere tabelle o colonne, utile per nascondere informazioni sensibili finanziarie o HR (ad es., la colonna degli stipendi). 

2. Implementazione e adattamento dinamico

La RLS può essere implementata facilmente in Power BI Desktop tramite filtri DAX sui ruoli. Queste regole possono essere statiche (filtri hard-coded) o dinamiche (logica guidata dall’utente). L’OLS si configura tramite Tabular Editor o endpoint XMLA. Richiede inoltre uno spazio di lavoro premium o un dataset Power BI ospitato in Analysis Services.

Ho messo insieme un riepilogo comparativo nella tabella seguente:

Conclusione

In sintesi, la Row-Level Security (RLS) in Power BI è un metodo chiave per garantire la data governance all’interno della piattaforma. Consente alle organizzazioni di offrire esperienze analitiche personalizzate e sicure all’interno di un unico report o dashboard, senza compromettere la riservatezza o l’integrità dei dati sottostanti.

La sicurezza è un fattore sempre più importante nella gestione e nella governance dei dati, un aspetto centrale nel lavoro con Power BI. Per approfondire Power BI, scopri il nostro corso Deploying and Maintaining Assets in Power BI o il nostro corso Reports in Power BI. Per ulteriori letture, potrebbero esserti utili le nostre guide su Power BI Hierarchies e Power BI Dashboards.