Linee guida sulla sicurezza a livello di riga in Power BI Desktop

Questo articolo è destinato a un modello di dati che usa Power BI Desktop. Descrive le procedure di progettazione consigliate per applicare la sicurezza a livelli di riga nei modelli di dati.

È importante comprendere le righe della tabella dei filtri a livello di riga. Non possono essere configurati per limitare l'accesso agli oggetti modello, incluse tabelle, colonne o misure.

Nota

Questo articolo non descrive la sicurezza a livello di riga o come configurarla. Per altre informazioni, vedere Limitare l'accesso ai dati con la sicurezza a livello di riga per Power BI Desktop.

Inoltre, non copre l'applicazione della sicurezza a livello di riga nelle connessioni dinamiche ai modelli ospitati esternamente con Azure Analysis Services o SQL Server Analysis Services. In questi casi, la sicurezza a livello di riga viene applicata da Analysis Services. Quando Power BI si connette tramite Single Sign-On (SSO), Analysis Services applichererà la sicurezza a livello di riga (a meno che l'account non abbia privilegi di amministratore).

Creazione di ruoli

È possibile creare più ruoli. Quando si considerano le esigenze di autorizzazione per un singolo utente del report, cercare di creare un singolo ruolo che conceda tutte le autorizzazioni, invece di una progettazione in cui un utente del report sarà membro di più ruoli. È perché un utente del report può eseguire il mapping a più ruoli, direttamente usando il proprio account utente o indirettamente dall'appartenenza al gruppo di sicurezza. Più mapping dei ruoli possono comportare risultati imprevisti.

Quando un utente del report viene assegnato a più ruoli, i filtri di sicurezza a livello di riga diventano additivi. Significa che gli utenti del report possono visualizzare righe di tabella che rappresentano l'unione di tali filtri. Inoltre, in alcuni scenari non è possibile garantire che un utente del report non visualizzi righe in una tabella. A differenza delle autorizzazioni applicate agli oggetti di database di SQL Server (e ad altri modelli di autorizzazione), il principio "una volta negato sempre negato" non si applica.

Si consideri un modello con due ruoli: il primo ruolo, denominato Ruoli di lavoro, limita l'accesso a tutte le righe della tabella Payroll usando l'espressione di regola seguente:

FALSE()

Nota

Una regola non restituirà righe di tabella quando l'espressione restituisce FALSE.

Tuttavia, un secondo ruolo, denominato Manager, consente l'accesso a tutte le righe della tabella Payroll usando l'espressione di regola seguente:

TRUE()

Prestare attenzione: se un utente del report esegue il mapping a entrambi i ruoli, visualizzerà tutte le righe della tabella Payroll .

Ottimizzare la sicurezza a livello di riga

La sicurezza a livello di riga funziona applicando automaticamente filtri a ogni query DAX e questi filtri possono avere un impatto negativo sulle prestazioni delle query. Quindi, una sicurezza a livello di riga efficiente scende a una buona progettazione del modello. È importante seguire le linee guida per la progettazione dei modelli, come illustrato negli articoli seguenti:

• Comprendere lo schema star e l'importanza per Power BI
• Tutti gli articoli relativi alle linee guida sulle relazioni sono disponibili nella documentazione delle linee guida di Power BI

In generale, è spesso più efficiente applicare filtri di sicurezza a livello di riga nelle tabelle di tipo dimensione e non tabelle di tipo fatto. Inoltre, si basano su relazioni ben progettate per garantire che i filtri di sicurezza a livello di riga vengano propagati ad altre tabelle del modello. I filtri di sicurezza a livello di riga vengono propagati solo tramite relazioni attive. Evitare quindi di usare la funzione DAX LOOKUPVALUE quando le relazioni del modello potrebbero ottenere lo stesso risultato.

Ogni volta che i filtri di sicurezza a livello di riga vengono applicati alle tabelle DirectQuery e sono presenti relazioni con altre tabelle DirectQuery, assicurarsi di ottimizzare il database di origine. Può comportare la progettazione di indici appropriati o l'uso di colonne calcolate persistenti. Per altre informazioni, vedere Linee guida sul modello DirectQuery in Power BI Desktop.

Misurare l'impatto della sicurezza a livello di riga

È possibile misurare l'impatto sulle prestazioni dei filtri di sicurezza a livello di riga in Power BI Desktop usando analizzatore prestazioni. Determinare prima di tutto la durata delle query visive del report quando non viene applicata la sicurezza a livello di riga. Usare quindi il comando Visualizza come nella scheda Modellazione della barra multifunzione per applicare la sicurezza a livello di riga e determinare e confrontare le durate delle query.

Configurare i mapping dei ruoli

Dopo la pubblicazione in Power BI, è necessario eseguire il mapping dei membri ai ruoli del modello semantico (noto in precedenza come set di dati). Solo i proprietari di modelli semantici o gli amministratori dell'area di lavoro possono aggiungere membri ai ruoli. Per altre informazioni, vedere Sicurezza a livello di riga con Power BI (Gestire la sicurezza nel modello).

I membri possono essere account utente, gruppi di sicurezza, gruppi di distribuzione o gruppi abilitati alla posta elettronica. Quando possibile, è consigliabile eseguire il mapping dei gruppi di sicurezza ai ruoli del modello semantico. Comporta la gestione delle appartenenze ai gruppi di sicurezza in Microsoft Entra ID (noto in precedenza come Azure Active Directory). Possibilmente delega l'attività agli amministratori di rete.

Convalidare i ruoli

Testare ogni ruolo per assicurarsi che filtri correttamente il modello. Questa operazione viene eseguita facilmente usando il comando Visualizza come nella scheda Della barra multifunzione Modellazione .

Quando il modello dispone di regole dinamiche che usano la funzione DAX U edizione Standard RNAME, assicurarsi di verificare la disponibilità di valori previsti e imprevisti. Quando si incorpora il contenuto di Power BI, in particolare usando l'incorporamento per lo scenario dei clienti, la logica dell'app può passare qualsiasi valore come nome utente di identità effettivo. Quando possibile, assicurarsi che i valori accidentali o dannosi comportino filtri che non restituiscono righe.

Si consideri un esempio di uso di Power BI embedded, in cui l'app passa il ruolo di lavoro dell'utente come nome utente effettivo: è "Manager" o "Worker". I manager possono visualizzare tutte le righe, ma i ruoli di lavoro possono visualizzare solo le righe in cui il valore della colonna Type è "Internal".

Viene definita l'espressione di regola seguente:

IF(
    USERNAME() = "Worker",
    [Type] = "Internal",
    TRUE()
)

Il problema con questa espressione di regola è che tutti i valori, ad eccezione di "Worker", restituiscono tutte le righe della tabella. Pertanto, un valore accidentale, come "Wrker", restituisce involontariamente tutte le righe della tabella. Pertanto, è più sicuro scrivere un'espressione che testa ogni valore previsto. Nell'espressione di regola migliorata seguente, un valore imprevisto comporta la restituzione di nessuna riga nella tabella.

IF(
    USERNAME() = "Worker",
    [Type] = "Internal",
    IF(
        USERNAME() = "Manager",
        TRUE(),
        FALSE()
    )
)

Progettare una sicurezza a livello di riga parziale

In alcuni casi, i calcoli richiedono valori che non sono vincolati dai filtri di sicurezza a livello di riga. Ad esempio, un report potrebbe dover visualizzare un rapporto dei ricavi ottenuti per l'area di vendita dell'utente del report su tutti i ricavi ottenuti.

Anche se non è possibile eseguire l'override della sicurezza a livello di riga da un'espressione DAX, in realtà non può nemmeno determinare che viene applicata la sicurezza a livello di riga, è possibile usare una tabella del modello di riepilogo. Viene eseguita una query sulla tabella del modello di riepilogo per recuperare i ricavi per "tutte le aree" e non è vincolato da alcun filtro di sicurezza a livello di riga.

Vediamo come implementare questo requisito di progettazione. Prima di tutto, prendere in considerazione la progettazione del modello seguente:

Il modello comprende quattro tabelle:

• La tabella Salesperson archivia una riga per ogni venditore. Include la colonna EmailAddress , che archivia l'indirizzo di posta elettronica per ogni venditore. Questa tabella è nascosta.
• La tabella Sales archivia una riga per ordine. Include la misura Revenue % All Region , progettata per restituire un rapporto dei ricavi ottenuti dall'area dell'utente del report rispetto ai ricavi ottenuti da tutte le aree geografiche.
• La tabella Date archivia una riga per data e consente di filtrare e raggruppare anno e mese.
• SalesRevenueSummary è una tabella calcolata. Archivia i ricavi totali per ogni data dell'ordine. Questa tabella è nascosta.

L'espressione seguente definisce la tabella calcolata SalesRevenueSummary :

SalesRevenueSummary =
SUMMARIZECOLUMNS(
    Sales[OrderDate],
    "RevenueAllRegion", SUM(Sales[Revenue])
)

Nota

Una tabella di aggregazione può raggiungere lo stesso requisito di progettazione.

La regola di sicurezza a livello di riga seguente viene applicata alla tabella Salesperson :

[EmailAddress] = USERNAME()

Ognuna delle tre relazioni del modello è descritta nella tabella seguente:

Relazione	Descrizione
	Esiste una relazione molti-a-molti tra le tabelle Salesperson e Sales . La regola di sicurezza a livello di riga filtra la colonna EmailAddress della tabella Salesperson nascosta usando la funzione DAX U edizione Standard RNAME. Il valore della colonna Region (per l'utente del report) viene propagato alla tabella Sales .
	Esiste una relazione uno-a-molti tra le tabelle Date e Sales .
	Esiste una relazione uno-a-molti tra le tabelle Date e SalesRevenueSummary .

L'espressione seguente definisce la misura Revenue % All Region :

Revenue % All Region =
DIVIDE(
    SUM(Sales[Revenue]),
    SUM(SalesRevenueSummary[RevenueAllRegion])
)

Nota

Prestare attenzione a evitare di divulgare fatti sensibili. Se in questo esempio sono presenti solo due aree, è possibile che un utente del report calcoli i ricavi per l'altra area.

Quando evitare di usare la sicurezza a livello di riga

A volte è opportuno evitare di usare la sicurezza a livello di riga. Se sono presenti solo alcune regole semplicistiche per la sicurezza a livello di riga che applicano filtri statici, è consigliabile pubblicare più modelli semantici. Nessuno dei modelli semantici definisce i ruoli perché ogni modello semantico contiene dati per un gruppo di destinatari di utenti del report specifico, che dispone delle stesse autorizzazioni per i dati. Creare quindi un'area di lavoro per gruppo di destinatari e assegnare le autorizzazioni di accesso all'area di lavoro o all'app.

Ad esempio, un'azienda che ha solo due aree di vendita decide di pubblicare un modello semantico per ogni area di vendita in aree di lavoro diverse. I modelli semantici non applicano la sicurezza a livello di riga. Tuttavia, usano parametri di query per filtrare i dati di origine. In questo modo, lo stesso modello viene pubblicato in ogni area di lavoro, ma hanno solo valori dei parametri del modello semantico diversi. Ai venditori viene assegnato l'accesso solo a una delle aree di lavoro (o alle app pubblicate).

Esistono diversi vantaggi associati all'evitare la sicurezza a livello di riga:

• Miglioramento delle prestazioni delle query: può comportare prestazioni migliorate a causa di un minor numero di filtri.
• Modelli più piccoli: anche se si ottengono più modelli, sono più piccoli. I modelli più piccoli possono migliorare la velocità di risposta alle query e all'aggiornamento dei dati, soprattutto se la capacità di hosting subisce una pressione sulle risorse. Inoltre, è più facile mantenere le dimensioni del modello al di sotto dei limiti di dimensione imposti dalla capacità. Infine, è più facile bilanciare i carichi di lavoro tra capacità diverse, perché è possibile creare aree di lavoro in o spostare le aree di lavoro in capacità diverse.
• Funzionalità aggiuntive: è possibile usare funzionalità di Power BI che non funzionano con la sicurezza a livello di riga, ad esempio Pubblica sul Web.

Tuttavia, esistono svantaggi associati all'evitare la sicurezza a livello di riga:

• Più aree di lavoro: è necessaria un'area di lavoro per ogni gruppo di destinatari dell'utente del report. Se le app vengono pubblicate, significa anche che è presente un'app per ogni gruppo di destinatari dell'utente del report.
• Duplicazione del contenuto: i report e i dashboard devono essere creati in ogni area di lavoro. Richiede più impegno e tempo per configurare e gestire.
• Utenti con privilegi elevati: gli utenti con privilegi elevati, che appartengono a più gruppi di destinatari degli utenti del report, non possono visualizzare una visualizzazione consolidata dei dati. Dovranno aprire più report (da aree di lavoro o app diverse).

Risolvere i problemi relativi alla sicurezza a livello di riga

Se la sicurezza a livello di riga produce risultati imprevisti, verificare la presenza dei problemi seguenti:

• Esistono relazioni errate tra le tabelle del modello, in termini di mapping di colonne e direzioni di filtro. Tenere presente che i filtri della sicurezza a livello di riga vengono propagati solo tramite relazioni attive.
• La proprietà Applica filtro di sicurezza in entrambe le direzioni della relazione non è impostata correttamente. Per altre informazioni, vedere Indicazioni sulle relazioni bidirezionali.
• Le tabelle non contengono dati.
• I valori non corretti vengono caricati nelle tabelle.
• L'utente viene mappato a più ruoli.
• Il modello include tabelle di aggregazione e regole di sicurezza a livello di riga non filtrano in modo coerente aggregazioni e dettagli. Per altre informazioni, vedere Usare le aggregazioni in Power BI Desktop (RLS per le aggregazioni).

Quando un utente specifico non può visualizzare dati, potrebbe essere perché l'UPN non è archiviato o viene immesso in modo non corretto. Può verificarsi improvvisamente perché l'account utente è cambiato in seguito a una modifica del nome.

Suggerimento

Ai fini del test, aggiungere una misura che restituisce la funzione DAX U edizione Standard RNAME. Potresti assegnare un nome simile a "Chi sono io". Aggiungere quindi la misura a un oggetto visivo scheda in un report e pubblicarla in Power BI.

Gli autori e i consumer con autorizzazione di sola lettura per il modello semantico potranno visualizzare solo i dati che possono visualizzare (in base al mapping dei ruoli della sicurezza a livello di riga).

Quando un utente visualizza un report in un'area di lavoro o in un'app, la sicurezza a livello di riga potrebbe o meno essere applicata a seconda delle autorizzazioni del modello semantico. Per questo motivo, è fondamentale che i consumer di contenuti e gli autori dispongano solo dell'autorizzazione di lettura per il modello semantico sottostante quando è necessario applicare la sicurezza a livello di riga. Per informazioni dettagliate sulle regole di autorizzazioni che determinano se viene applicata la sicurezza a livello di riga, vedere l'articolo Report consumer security planning (Pianificazione della sicurezza degli utenti consumer).

Contenuto correlato

Per altre informazioni relative a questo articolo, vedere le risorse seguenti:

• Sicurezza a livello di riga con Power BI
• Limitare l'accesso ai dati con la sicurezza a livello di riga per Power BI Desktop
• Relazioni tra modelli in Power BI Desktop
• Pianificazione dell'implementazione di Power BI: Pianificare la sicurezza degli utenti dei report
• Domande? Contattare la community di Power BI
• inviare suggerimenti, Contribuire con idee per migliorare Power BI