Limitare l'accesso ai dati del modello Power BI
I data modeler configurano la Sicurezza a livello di riga creando uno o più ruoli. Un ruolo ha un nome univoco nel modello e include in genere una o più regole. Le regole applicano filtri alle tabelle del modello usando espressioni filtro di tipo DAX (Data Analysis Expressions).
Nota
Per impostazione predefinita, un modello di dati non ha alcun ruolo. Se un modello di dati non ha alcun ruolo, gli utenti autorizzati a eseguire query nel modello di dati potranno accedere a tutti i dati del modello.
Suggerimento
È possibile definire un ruolo che non include alcuna regola. In questo caso, il ruolo fornisce l'accesso a tutte le righe di tutte le tabelle del modello. Questa configurazione di ruolo sarebbe adatta per un utente amministratore che è autorizzato a visualizzare tutti i dati.
È possibile creare, convalidare e gestire ruoli in Power BI Desktop. Per i modelli di Azure Analysis Services o SQL Server Analysis Services è possibile creare, convalidare e gestire i ruoli usando SQL Server Data Tools (SSDT).
È inoltre possibile creare e gestire i ruoli usando SQL Server Management Studio (SSMS) oppure uno strumento di terze parti, ad esempio Tabular Editor.
Per comprendere meglio il modo in cui la Sicurezza a livello di riga limita l'accesso ai dati, guardare la seguente immagine animata.
Applicare i principi di progettazione dello schema star
È consigliabile applicare i principi di progettazione dello schema star per produrre un modello che include tabelle delle dimensioni e tabelle dei fatti. È comune configurare Power BI per applicare regole che filtrano le tabelle delle dimensioni, consentendo alle relazioni del modello di propagare in modo efficiente tali filtri alle tabelle dei fatti.
L'immagine seguente è il diagramma del modello di dati per l'analisi delle vendite di Adventure Works. Mostra una struttura dello schema star costituita da una singola tabella dei fatti denominata Sales (Vendite). Le altre tabelle sono tabelle delle dimensioni che supportano l'analisi delle misure di vendita per data, territorio di vendita, cliente, rivenditore, ordine, prodotto e venditore. Si notino le relazioni tra modelli che connettono tutte le tabelle. Queste relazioni propagano i filtri, direttamente o indirettamente, nella tabella Sales (Vendite).
Questa struttura del modello supporta gli esempi presentati nell'unità.
Definire le regole
Le espressioni delle regole vengono valutate entro il contesto di riga, ovvero l'espressione viene valutata per ogni riga usando i valori di colonna di tale riga. Quando l'espressione restituisce TRUE, l'utente può "visualizzare" la riga.
Suggerimento
Per altre informazioni sul contesto di riga, completare il modulo Aggiungere tabelle e colonne calcolate a modelli di Power BI Desktop. Benché questo modulo descriva l'aggiunta di calcoli ai modelli, include anche un'unità che presenta e descrive il contesto di riga.
È possibile definire regole statiche o dinamiche.
Regole statiche
Le regole statiche usano espressioni DAX che fanno riferimento a costanti.
Si consideri la regola seguente applicata alla tabella Area, che limita l'accesso ai dati solo alle vendite per il Midwest.
'Region'[Region] = "Midwest"
I passaggi seguenti spiegano il modo in cui Power BI applica la regola. IT:
Filtra la tabella Area, restituendo come risultato una riga visibile (per Midwest).
Usa la relazione tra modelli per propagare il filtro della tabella Area alla tabella Stato, restituendo come risultato sei righe visibili (l'area del Midwest include 14 stati).
Usa la relazione tra modelli per propagare il filtro della tabella Stato alla tabella Vendite, restituendo come risultato migliaia di righe visibili (i fatti relativi alle vendite per gli stati appartenenti all'area Midwest).
La regola statica più semplice che è possibile creare limita l'accesso a tutte le righe della tabella. Si consideri la regola seguente applicata alla tabella Sales Details (Dettagli vendite), non mostrata nel diagramma del modello.
FALSE()
Questa regola assicura che gli utenti non possano accedere ad alcun dato della tabella. Potrebbe risultare utile quando i venditori sono autorizzati a visualizzare i risultati di vendita aggregati, dalla tabella Sales (Vendite), ma non i dettagli a livello di ordine.
La definizione di regole statiche è un approccio semplice ed efficace. È consigliabile usarle quando è necessario creare solo poche regole, ad esempio nel caso di Adventure Works, in cui sono presenti solo sei aree degli Stati Uniti. Occorre tuttavia notare degli svantaggi: la configurazione di regole statiche può comportare un impegno significativo per la creazione e la configurazione. Richiederebbe inoltre l'aggiornamento e la nuova pubblicazione del set di dati quando viene eseguito l'onboarding di nuove aree.
Se esistono molte regole da configurare e si prevede che in futuro verranno aggiunte nuove regole, è consigliabile creare invece regole dinamiche.
Regole dinamiche
Le regole dinamiche usano funzioni DAX specifiche che restituiscono valori di ambiente, invece di costanti. I valori di ambiente vengono restituiti da tre funzioni DAX specifiche:
USERNAME o USERPRINCIPALNAME: restituisce l'utente autenticato di Power BI come valore di testo.
CUSTOMDATA: restituisce la proprietà CustomData passata nella stringa di connessione. Gli strumenti di creazione di report non Power BI che si connettono al set di dati usando una stringa di connessione possono impostare questa proprietà, ad esempio Microsoft Excel.
Nota
Si noti che la funzione USERNAME restituisce l'utente in formato DOMINIO\nomeutente se viene usata in Power BI Desktop. Se viene usata nel servizio Power BI, tuttavia, restituisce il formato del nome dell'entità utente (UPN), ad esempio username@adventureworks.com. In alternativa, è possibile usare la funzione USERPRINCIPALNAME, che restituisce sempre l'utente in formato UPN.
Si consideri una struttura di modello modificata che include ora la tabella nascosta AppUser (UtenteApp). Ogni riga della tabella AppUser (UtenteApp) descrive un nome utente e un'area. Una relazione tra modelli nella tabella Region (Area) propaga filtri dalla tabella AppUser (UtenteApp).
La regola seguente applicata alla tabella AppUser (UtenteApp) limita l'accesso ai dati a una o più aree dell'utente autenticato.
'AppUser'[UserName] = USERPRINCIPALNAME()
La definizione di regole dinamiche è un approccio semplice ed efficace quando una tabella del modello archivia valori del nome utente. Tali regole consentono di applicare una struttura basata sui dati per la Sicurezza a livello di riga. Quando ad esempio vengono aggiunti o rimossi venditori dalla tabella AppUser oppure i venditori vengono assegnati ad aree diverse, questo approccio di progettazione funziona in modo ottimale.
Convalidare i ruoli
Quando si creano ruoli, è importante testarli per assicurarsi che applichino i filtri corretti. Per i modelli di dati creati in Power BI Desktop è disponibile la funzione Visualizza come che consente di visualizzare il report con ruoli diversi applicati e valori diversi passati per nome utente.
Configurare i mapping di ruoli
I mapping di ruoli devono essere configurati prima che gli utenti accedano al contenuto di Power BI. Il mapping di ruoli comporta l'assegnazione di oggetti di sicurezza di Microsoft Entra ai ruoli. Gli oggetti di sicurezza possono essere account utente o gruppi di sicurezza.
Suggerimento
Quando possibile, è consigliabile eseguire il mapping dei ruoli ai gruppi di sicurezza. In questo modo sarà possibile ridurre il numero di mapping e delegare la gestione dell'appartenenza ai gruppi agli amministratori di rete.
Per i modelli sviluppati di Power BI Desktop, il mapping di ruoli viene in genere eseguito nel servizio Power BI. Per i modelli di Azure Analysis Services o SQL Server Analysis Services, il mapping di ruoli viene in genere eseguito in SSMS.
Per altre informazioni sulla configurazione della Sicurezza a livello di riga, vedere:
Usare l'accesso Single Sign-On (SSO) per le origini DirectQuery
Quando il modello di dati dispone di tabelle DirectQuery e l'origine dati supporta l'accesso SSO, l'origine dati può applicare le autorizzazioni per i dati. In questo modo, il database applica la sicurezza a livello di riga e i set di dati e report Power BI rispettano la sicurezza dell'origine dati.
Si consideri che Adventure Works ha un database SQL di Azure per le operazioni di vendita che risiede nello stesso tenant di Power BI. Il database applica la sicurezza a livello di riga per controllare l'accesso alle righe in varie tabelle di database. È possibile creare un modello DirectQuery che si connette a questo database senza ruoli e pubblicarlo nel servizio Power BI. Quando si impostano le credenziali dell'origine dati nel servizio Power BI, si abilita l'accesso SSO. Quando i consumer di report aprono i report Power BI, Power BI inoltra la loro identità all'origine dati. L'origine dati applica quindi la sicurezza a livello di riga in base all'identità del consumer del report.
Per informazioni sulla Sicurezza a livello di riga di database SQL di Azure, vedere Sicurezza a livello di riga.
Nota
Le tabelle calcolate e le colonne calcolate che fanno riferimento a una tabella DirectQuery da un'origine dati con autenticazione SSO non sono supportate nel servizio Power BI.
Per altre informazioni sulle origini dati che supportano l'accesso SSO, vedere Single Sign-On (SSO) per le origini DirectQuery.