Condividi tramite

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

  • Articolo

Questo articolo è destinato agli autori di modelli di dati che usano Power BI Desktop. Vengono descritte le procedure di progettazione valide per l'applicazione della sicurezza a livello di riga nei modelli di dati.

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

Nota

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

Inoltre, non viene descritta l'applicazione della sicurezza a livello di riga nelle connessioni dinamiche a 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 impone la sicurezza a livello di riga, a meno che l'account non abbia i privilegi di amministratore.

Creazione di ruoli

È possibile creare più ruoli. Quando si prendono in considerazione le autorizzazioni necessarie per un utente del report, creare un singolo ruolo che conceda tutte le autorizzazioni necessarie anziché una progettazione in cui l'utente del report è membro di più ruoli. Un utente di report può infatti eseguire il mapping a più ruoli, direttamente usando il proprio account utente o indirettamente tramite l'appartenenza al gruppo di sicurezza. Il mapping a più ruoli può causare risultati imprevisti.

Quando un utente del report viene assegnato a più ruoli, i filtri di sicurezza a livello di riga diventano additivi. Questo significa che gli utenti del report possono visualizzare le righe della tabella che rappresentano l'unione dei filtri. In alcuni scenari non è possibile garantire che un utente del report non visualizzi le righe in una tabella. Per questa ragione, a differenza delle autorizzazioni applicate agli oggetti di database SQL Server e ad altri modelli di autorizzazione, il principio "negato una volta, negato per sempre" non è applicabile.

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

FALSE()

Nota

Una regola non restituirà alcuna riga di tabella se la relativa espressione restituisce FALSE.

Tuttavia, un secondo ruolo, denominato Managers, 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 per entrambi i ruoli, visualizzeranno tutte le righe della tabella Libro paga.

Ottimizzare la sicurezza a livello di riga

La sicurezza a livello di riga applica automaticamente i filtri a ogni query DAX. I filtri possono avere un impatto negativo sulle prestazioni delle query. Per questa ragione, una sicurezza a livello di riga efficiente è un buon modello di progettazione. È importante seguire le linee guida per la progettazione dei modelli, illustrate negli articoli seguenti:

In generale, è spesso più efficace applicare i filtri per la sicurezza a livello di riga nelle tabelle di tipo dimensione e non nelle tabelle di tipo fact. Inoltre, basarsi su relazioni ben progettate per assicurarsi 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 pertanto di usare la funzione DAX LOOKUPVALUE quando le relazioni tra modelli potrebbero ottenere lo stesso risultato.

Ogni volta che vengono applicati filtri di sicurezza a livello di riga nelle tabelle DirectQuery e sono presenti relazioni con altre tabelle DirectQuery, assicurarsi di ottimizzare il database di origine. È possibile progettare gli indici appropriati o usare colonne calcolate persistenti. Per altre informazioni, vedere Linee guida per il modello DirectQuery in Power BI Desktop.

Misurare l'impatto della sicurezza a livello di riga

È possibile misurare l'impatto sulle prestazioni dei filtri della sicurezza a livello di riga in Power BI Desktop usando l'analizzatore prestazioni. Per prima cosa, determinare le durate delle query visive del report quando non è applicata la sicurezza a livello di riga. Usare quindi il comando Visualizza come nella scheda della barra multifunzione Modellazione 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 per i ruoli del modello semantico (noto in precedenza come set di dati). Solo i proprietari del modello semantico 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. Dove possibile, è consigliabile eseguire il mapping dei gruppi di sicurezza per i ruoli del modello semantico. Comporta la gestione delle appartenenze ai gruppi di sicurezza in Microsoft Entra ID (noto in precedenza come Azure Active Directory). Se possibile, delegare l'attività agli amministratori di rete.

Convalidare i ruoli

Testare ogni ruolo per assicurarsi che il modello venga filtrato correttamente. Per eseguire questa operazione, è possibile usare il comando Visualizza come nella scheda della barra multifunzione Modellazione.

Quando il modello include regole dinamiche con la funzione DAX USERNAME, assicurarsi di verificare i valori previsti e non previsti. Quando si incorpora il contenuto di Power BI, in particolare usando lo scenario incorpora per i clienti, la logica dell'app può passare qualsiasi valore come nome utente di identità efficace. Quando possibile, assicurarsi che i valori accidentali o dannosi producano filtri che non restituiscono alcuna riga.

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: è "Responsabile" o "Lavoratore". 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 di questa espressione di regola è che tutti i valori, ad eccezione di "Worker", restituiscono tutte le righe della tabella. Di conseguenza, un valore accidentale come "Lavratre" restituisce involontariamente tutte le righe della tabella. Per questa ragione, è consigliabile scrivere un'espressione che verifica ogni valore previsto. Nella seguente espressione di regola migliorata, un valore non previsto fa in modo che la tabella non restituisca alcuna riga.

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

Progettare la sicurezza a livello di riga parziale

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

Sebbene non sia possibile che un'espressione DAX esegua l'override della sicurezza a livello di riga (non è in grado di individuare l'applicazione della sicurezza a livello di riga), è possibile usare una tabella del modello di riepilogo. Viene eseguita una query nella tabella del modello di riepilogo per recuperare i ricavi di "tutte le aree" e la tabella non è vincolata da alcun filtro di sicurezza a livello di riga.

Di seguito viene descritto come implementare questo requisito di progettazione. In primo luogo, si consideri la progettazione del modello seguente:

Viene visualizzata un'immagine del diagramma di un modello. Il diagramma è descritto nei paragrafi seguenti.

Il modello include quattro tabelle:

  • La tabella Salesperson archivia una riga per ogni venditore. Include la colonna EmailAddress che archivia l'indirizzo di posta elettronica di ogni venditore. Questa tabella è nascosta.
  • La tabella Sales archivia una riga per ogni ordine. Include la misura Revenue % All Region, progettata per restituire un rapporto tra i ricavi ottenuti dall'area dell'utente del report e i ricavi ottenuti da tutte le aree.
  • 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 ordine. Questa tabella è nascosta.

L'espressione seguente definisce la tabella calcolata SalesRevenueSummary:

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

Nota

Una tabella delle aggregazioni può soddisfare 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
Terminatore diagramma di flusso 1. 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 nascosta Salesperson usando la funzione DAX USERNAME. Il valore della colonna Region (per l'utente del report) viene propagato alla tabella Sales.
Terminatore diagramma di flusso 2. Tra le tabelle Date e Sales esiste una relazione uno-a-molti.
Terminatore diagramma di flusso 3. Tra le tabelle Date e SalesRevenueSummary esiste una relazione uno-a-molti.

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 fact 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 Sicurezza a livello di riga

A volte è opportuno evitare Sicurezza a livello di riga. Se sono presenti solo alcune regole di Sicurezza a livello di riga semplicistiche che applicano filtri statici, è consigliabile pubblicare più modelli semantici. Nessuno dei modelli semantici definisce i ruoli poiché ciascuno di essi contiene i dati per uno specifico gruppo di destinatari del report, che ha le stesse autorizzazioni per i dati. Quindi, creare un'area di lavoro per ogni gruppo di destinatari e assegnare le autorizzazioni di accesso all'area di lavoro o all'app.

Ad esempio, una società che ha solo due aree vendite decide di pubblicare un modello semantico per ogni area vendite in aree di lavoro diverse. I modelli semantici non applicano Sicurezza a livello di riga. Usano tuttavia parametri di query per filtrare i dati di origine. In questo modo viene pubblicato lo stesso modello in ogni area di lavoro, e avrà solo diversi valori di parametri del modello semantico. Ai venditori viene assegnato l'accesso solo a una delle aree di lavoro o delle app pubblicate.

La mancata applicazione della sicurezza a livello di riga presenta diversi vantaggi:

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

La mancata applicazione della sicurezza a livello di riga presenta tuttavia anche svantaggi:

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

Risolvere i problemi della sicurezza a livello di riga

Se la sicurezza a livello di riga produce risultati imprevisti, controllare se si verificano i problemi seguenti:

  • Esistono relazioni non corrette tra le tabelle del modello, in termini di mapping di colonne e direzioni dei filtri. Tenere presente che i filtri di Sicurezza a livello di riga vengono propagati solo tramite relazioni attive.
  • La proprietà di relazione Applica filtro di sicurezza in entrambe le direzioni non è impostata correttamente. Per altre informazioni, vedere Linee guida per la relazione bidirezionale.
  • Le tabelle non contengono dati.
  • I valori non corretti vengono caricati nelle tabelle.
  • Viene eseguito il mapping dell'utente a più ruoli.
  • Il modello include tabelle di aggregazioni e le regole di sicurezza a livello di riga non filtrano in modo coerente le aggregazioni e i dettagli. Per altre informazioni, vedere Usare le aggregazioni in Power BI Desktop (sicurezza a livello di riga per le aggregazioni).

Quando un utente specifico non visualizza i dati, è possibile che il relativo UPN non sia archiviato o non sia stato immesso correttamente. Questo problema può verificarsi improvvisamente perché l'account utente è stato modificato in seguito alla modifica del nome.

Suggerimento

A scopo di test, aggiungere una misura che restituisce la funzione DAX USERNAME. È possibile assegnare un nome simile a "Who Am I". Aggiungere quindi la misura a un oggetto visivo scheda in un report e pubblicarlo 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 di Sicurezza a livello di riga).

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

Contenuto correlato

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