La gestione della row-level security è un aspetto molto importante per molte aziende, non solo per quelle di livello corporate.
Per chi si stesse approcciando per la prima volta all’argomento, l’idea della sicurezza a livello di riga (RLS) con Power BI è quella di limitare l’accesso ai dati per determinati utenti.
I filtri posti sulle colonne delle tabelle appartenenti al data model limitano l’accesso ai dati a livello di riga ed è possibile definire filtri all’interno dei ruoli in modo tale da definire “chi vede cosa”.
Occorre fare attenzione al fatto che, nel servizio Cloud di Power BI, i membri di un’area di lavoro (workspace) hanno accesso ai set di dati in esse contenuti e che la RLS non limita questo accesso ai dati.
Questa è una delle ragioni per le quali è sempre consigliabile separare dataset e report in aree di lavoro distinte.
In questo articolo verrà presentato il nuovo editor disponibile in preview in Power Bi desktop e, in particolare, verrà esaminata un’applicazione “statica” della RLS.
Come si imposta la row-level security
L’editor per la gestione di questa importante funzionalità è implementato all’interno di Power BI desktop.
Prima di poterlo utilizzare, tuttavia, occorre abilitarlo dalle Opzioni > Global > Preview features (vedi la figura 1).
Eseguito questo passaggio si è in grado di utilizzare la nuova funzionalità.
Per questo esempio è stato utilizzato il set di dati di esempio compreso in Power BI desktop.
Una volta caricati i dati, occorre accedere alla gestione dei ruoli (vedi figura 2)
Il nuovo editor si presenta rinnovato anche nella veste grafica e, in particolare, dopo aver operato la scelta di creare un nuovo ruolo (1) si potrà scegliere se (2) lavorare con l’impostazione di default (editor facilitato e guidato) o (3) tornare all’editor classico in cui sarà possibile inserire manualmente di codice DAX.
Scegliendo la prima possibilità (utilizzare la modalità facilitata per la definizione dei ruoli e della porzione dei dati che dovrà essere mantenuta disponibile) si dovrà cliccare su “Add” e si potrà cominciare a definire quali filtri dovranno valere e quale rapporto, in termini di logica, dovrà sussistere tra le condizioni elencate (vedi punto 3: scelta tra All e Any).
A questo proposito, molto interessante è la possibilità di “ispezionare” il codice DAX che viene prodotto automaticamente.
Questo modo di lavorare ricorda molto da vicino ciò che accade in Power Query in termini di traduzione, in termini di codice M, dei passaggi eseguiti dall’utente (vedi la figura 5).
Come si può osservare, il filtro su financials[Country] che è stato impostato con la clausola “All” è stato tradotto con il seguente codice DAX:
[Country] == “Mexico” && [Country] == “Canada”
Ciò conduce a un’assenza di valori visibili in quanto nessuna riga della tabella “financials” conterrà, allo stesso tempo, un valore pari sia a “Mexico” che a “Canada”.
Correggendo la clausola settata sul valore “All” e selezionando il valore “Any“, si giunge ad un codice DAX sottostante coerente e sensato.
Tale tipo di modifica vale a passare da un AND logico “&&” a un OR “||” il che, detto in altre parole, equivale ad “abilitare” le righe della tabella “financials” che conterranno il valore “Mexico” o il valore “Canada” nella colonna “Country” (vedi la figura 7).
Stavolta, infatti, il codice DAX sottostante l’operazione effettuata è il seguente:
[Country] == “Mexico” || [Country] == “Canada”
Per osservare l’effetto dell’applicazione del ruolo “Test” occorre salvare e chiudere l’editor e, successivamente, operare sul menu abilitato dal comando “View as” (1), selezionare il ruolo “Test” (2) e confermare con “OK” (3).
La visualizzazione dei dati appare limitata come previsto dal ruolo (4) (vedi figura 8).
Filtri complessi tramite i gruppi
Prima di concludere può essere utile dare un’occhiata alla possibilità di esprimere condizioni più complesse procedendo a raggruppare “blocchi” di condizioni che dovranno essere coordinati internamente (1) ed esternamente (2), vale a dire rispetto agli altri blocchi (vedi figura 9).
Questo tipo di impostazione si ottiene selezionando le singole condizioni (1) e cliccando poi sul pulsante “Group” (2) (vedi figura 10).
Nell’esempio finale di questo articolo, la selezione e la formazione dei gruppi è stata impostata come si può osservare nella figura 11.
Il codice DAX che è stato generato automaticamente per soddisfare la richiesta espressa tramite l’editor “facilitato” è il seguente:
([Country] == “Mexico” || [Country] == “Canada”) && [Month Name] == “April”
Stavolta sono state aggiunte le parentesi per consentire una valutazione corretta dell’espressione che vale ad abilitare tutte le righe in cui sia simultaneamente verificato che la colonna “Country” valga “Mexico” o “Canada” e la colonna “Month Name” valga “April”.
Il risultato può essere osservato nella figura 12.
Conclusioni
A parere del sottoscritto, questa piccola evoluzione appare un chiaro segnale della volontà di Microsoft di facilitare in misura sempre maggiore l’accesso degli utenti business alle funzionalità di Power BI.
In effetti, stabilire “chi vede che cosa” ha molto a che fare con logiche che spesso vengono discusse dalle figure direzionali, ancorché implementate dal mondo IT.
Questo tipo di facilitazioni sembra incoraggiare l’analista “business” ad implementare autonomamente certi tipi di policy aziendali.
Nondimeno, anche i professionisti “puramente” IT avranno una vita più facile nell’impostare logiche di RLS statica.
Grazie per la lettura e alla prossima!
Autore del Post
