Padroneggiare la sicurezza a livello di riga in Power BI senza compromettere i report

By Mirko Peters · 2026-08-11

Automatically translated with AI from the original post. Read the English original

Titelbild: Mastering Row-Level Security in Power BI Without Breaking Your Reports

Bentornati nel blog del podcast! Se vi è mai capitato di fissare un report di audit sulla sicurezza chiedendovi come abbia fatto un utente a vedere dati di un'altra regione, non siete soli. Gestire la business intelligence aziendale significa camminare su un filo sottile: rendere i dati accessibili alle persone giuste e, al tempo stesso, proteggerli abbastanza da superare i controlli di conformità più rigorosi. Troppo spesso le organizzazioni si affidano ad autorizzazioni disordinate negli spazi di lavoro oppure creano decine di report duplicati per i diversi reparti. C'è un modo migliore.

In questo post vediamo come applicare una sicurezza dei dati solida direttamente nei modelli semantici di Power BI, combinando Microsoft Entra ID (in precedenza Azure Active Directory), il contesto di Power Apps e pattern DAX robusti. Questo approfondimento riprende tutto ciò che abbiamo trattato nel nostro recente episodio. Se volete ascoltare la sintesi audio e sentire storie di implementazioni reali, non perdete Create Role-Based Dashboards in Power Platform.

Il framework di mappatura dei ruoli (la parte che tutti saltano)

Prima di scrivere una sola riga di DAX o configurare un gruppo di sicurezza, serve un progetto di riferimento. L'errore più grave che commettono i team è passare subito alla configurazione tecnica senza definire chi deve vedere cosa. Un framework di mappatura dei ruoli solido chiude le falle di sicurezza prima che si aprano.

Persone: definite profili utente chiari, come Dirigente, Responsabile regionale, Manager, Analista e Revisore.
Ambito dei dati: stabilite i limiti per ciascun profilo, che siano l'intera azienda, una regione specifica, il livello di team, solo i propri dati o l'accesso in sola lettura per la conformità.
Gruppi di Entra ID: create un gruppo di sicurezza per ogni combinazione di profilo e ambito. Quando possibile, preferite regole dinamiche basate su attributi come reparto, regione e qualifica.
Ruoli del modello dati: assegnate ai ruoli del modello semantico nomi logici, come Exec_All, Region_Lead, Mgr_Team, Analyst_Region e Auditor_Read.
Filtri RLS: basate la logica di sicurezza su tabelle di ricerca (Utenti, Team, Regioni) collegate direttamente alle tabelle dei fatti, invece di inserire in modo fisso gli indirizzi e-mail degli utenti.
Distribuzione: pubblicate una sola app di Power BI che utilizza visualizzazioni per pubblico, tutte mappate sullo stesso modello sottostante.

Entra ID ↔ Power BI: una sicurezza che funziona davvero

Affidarsi alle autorizzazioni dell'area di lavoro per proteggere i dati è una ricetta per il disastro. Le autorizzazioni dell'area di lavoro stabiliscono chi può modificare o gestire i contenuti, ma non controllano l'accesso ai dati a livello di riga. La vera sicurezza dei dati risiede all'interno del modello semantico.

Create gruppi di sicurezza dinamici in Microsoft Entra ID basati sugli attributi degli utenti, per ciascun profilo.
All'interno del set di dati di Power BI, create i ruoli di sicurezza corrispondenti e assegnate a questi ruoli i gruppi di Entra ID, anziché i singoli account utente.
Implementate nel modello una tabella Utenti dedicata che includa UserPrincipalName, Department, Region e ManagerObjectId.
Applicate i pattern RLS utilizzando una logica DAX pulita:
- Dirigente: TRUE() (con esportazione dei dati limitata dai criteri dell'organizzazione).
- Responsabile regionale: 'Facts'[Region] IN VALUES('UserRegions'[Region])
- Responsabile: 'Facts'[ManagerId] = LOOKUPVALUE('Users'[ObjectId], 'Users'[UPN], USERPRINCIPALNAME())
- Analista: limitate l'accesso ai dati per regione o famiglia di prodotti tramite una tabella ponte.
Testate sempre la configurazione RLS con la funzione «Visualizza come» per i profili reali, prima di andare in produzione.

Power Apps → Power BI: personalizzazione basata sul contesto

Quando incorporate report di Power BI in app personalizzate di Power Apps, si aprono opportunità notevoli di personalizzazione basata sul contesto. Tuttavia, dovete gestire il contesto con attenzione per mantenere l'integrità della sicurezza.

Power Apps può acquisire il contesto dell'utente direttamente da Microsoft Graph, recuperando reparto, appartenenze ai gruppi, relazioni gerarchiche e dettagli sulla regione.
Passate questo contesto utente ai report di Power BI incorporati tramite filtri iniziali e segmentazioni al caricamento, puntando a parametri come regione o teamId.
La regola d'oro delle applicazioni ibride: i filtri a livello di app devono sempre allinearsi con la RLS del tuo dataset, come livello aggiuntivo di difesa in profondità. L'interfaccia della tua applicazione non è mai un confine di sicurezza.
Usa le funzionalità di visibilità condizionale di Power Apps per mostrare o nascondere dinamicamente pagine di report, pulsanti di azione e schede sensibili in base alla persona dell'utente attivo.

Piano di implementazione (passo dopo passo)

Conta soprattutto l'esecuzione. Segui questo piano strutturato per distribuire la tua architettura di reporting sicura senza sovraccaricare la coda di supporto IT.

Modello dati: crea un modello semantico centrale condiviso. Aggiungi le tabelle di ricerca Users, Teams e Regions e collegale correttamente alle tabelle dei fatti.
RLS: definisci i ruoli di sicurezza e scrivi filtri DAX puliti che usino le tabelle di ricerca invece degli indirizzi email scritti direttamente nel codice.
AAD: crea gruppi di sicurezza dinamici e popola gli attributi utente sincronizzando il tuo sistema HRIS con il provisioning di Entra ID.
Pubblico delle app: pubblica i contenuti come app di Power BI con viste distinte per pubblico, mantenendo un unico modello condiviso con molte viste personalizzate.
Shell Power Apps (facoltativa): leggi Microsoft Graph, imposta le variabili dell'applicazione, pre-filtra le viste incorporate di Power BI e aggiungi azioni interattive come approvazioni, assegnazioni e commenti.
Governance: applica etichette di riservatezza, criteri di prevenzione della perdita di dati (DLP) e restrizioni sull'esportazione, monitorando attivamente i log di attività di Power BI.
Runbook: documenta le procedure di onboarding e offboarding, pianifica la ricertificazione trimestrale degli accessi e stabilisci test unitari di routine per la RLS.

Pattern RLS da riutilizzare

Non serve inventare nuove formule di sicurezza per ogni progetto. Pochi pattern standard coprono quasi tutti i requisiti aziendali che incontrerai.

Albero dei manager: usa una tabella organizzativa appiattita che contenga l'intera gerarchia dei manager per creare facilmente viste "il mio team" per i supervisori.
Analisti multi-regione: usa una tabella ponte UserRegions con una relazione molti-a-molti con le regioni per gestire gli analisti che necessitano di un ambito cumulativo su più territori.
Privacy a livello di cella: combina la sicurezza a livello di riga con la Object-Level Security (OLS) per nascondere completamente agli utenti non autorizzati le colonne sensibili, come le retribuzioni dei dirigenti o le note HR.
Visibilità ibrida: implementa una navigazione specifica per pubblico su un unico modello, così i dirigenti accedono alle pagine KPI di alto livello e gli analisti alle pagine di drill-through di dettaglio.

Automazione su larga scala (senza code di ticket)

La gestione manuale degli utenti porta inevitabilmente a colli di bottiglia e a derive della sicurezza. Automatizza la pipeline di provisioning per proteggere i dati senza dover rispondere continuamente ai ticket dell'help desk.

Usa gruppi di sicurezza dinamici con regole esplicite, ad esempio includere gli utenti il cui reparto è Vendite e il cui paese è Germania o Francia.
Definisci criteri del ciclo di vita per far scadere automaticamente gli accessi privilegiati, rimuovere gli account utente inattivi e fornire l'elevazione Just-In-Time (JIT) per i ruoli temporanei.
Fai in modo che il percorso di provisioning fluisca senza interruzioni dagli attributi HRIS agli attributi di Entra ID, poi nei gruppi dinamici e direttamente negli effetti immediati della RLS, senza intervento manuale.
Esegui script di health check pianificati che confrontino le autorizzazioni dei workspace con le assegnazioni dei ruoli del dataset, inviando avvisi automatici ogni volta che viene rilevata una deriva.

Prestazioni e UX

La sicurezza non deve mai andare a scapito delle prestazioni dei report o dell'esperienza utente. Mantieni il sistema veloce e reattivo.

Mantieni centralizzato il modello semantico. Distribuisci app specifiche per pubblico o navigazione tra pagine invece di mantenere copie duplicate dei report.
Limita il numero di visualizzazioni per pagina a otto o meno, e usa aggregazioni o tabelle ibride per i dataset di fatti molto grandi.
Metti in cache le schede critiche della dashboard e preferisci misure parametrizzate a una proliferazione infinita di pagine di report.
Per gli utenti mobili, pubblica una vista dedicata e leggera con schede pulite, KPI di alto livello e segmentatori semplici, ottimizzata per i manager in movimento.

Problemi comuni → soluzioni

Fai attenzione a questi errori comuni durante la fase di implementazione e applica subito le soluzioni consigliate.

Accesso solo al workspace (senza RLS): gli utenti vedono molti più dati del necessario. → Sposta i confini di sicurezza direttamente nei ruoli del dataset e limita le esportazioni dei dati.
Gruppi obsoleti: gli aggiornamenti manuali dei membri restano molto indietro rispetto alle ristrutturazioni aziendali. → Passa completamente a gruppi AAD dinamici alimentati da una sincronizzazione automatica con le risorse umane.
I filtri delle app non equivalgono a RLS: gli utenti trovano il modo di aggirare i filtri dell'interfaccia utente. → Replica tutta la logica di filtro in RLS del set di dati e testala a fondo con "Visualizza come".
Proliferazione di persona: i team creano decine di copie duplicate dei report. → Consolida tutto in un unico modello che utilizzi viste per pubblico, navigazione mirata e segnalibri parametrizzati.
Accumulo di privilegi: l'accesso derivante da vecchi progetti resta attivo a tempo indeterminato. → Implementa certificazioni trimestrali degli accessi e revoca automaticamente le autorizzazioni subito dopo ogni cambio di ruolo.

KPI per capire se "funziona"

Come dimostri che la nuova architettura di sicurezza sta funzionando? Monitora nel tempo questi indicatori chiave di prestazione:

Gli incidenti di sicurezza sugli accessi mensili sono in calo.
Il tempo necessario per integrare ed eliminare gli utenti, per assegnare correttamente i ruoli, è in calo.
I report duplicati per area tematica sono in calo.
Il tasso di adozione da parte di dirigenti e manager, misurato con i visualizzatori attivi settimanali, è in crescita.
I tentativi di esportazione dei dati non giustificati vengono bloccati, tracciati e rivisti regolarmente.

Checklist di avvio rapido (da copiare e incollare)

Pronto a iniziare? Copia questa checklist nel tuo strumento di gestione dei progetti e inizia a spuntare le voci:

Inventaria i tuoi persona, gli ambiti dei dati e i campi sensibili.
Crea gruppi di sicurezza AAD dinamici e popola tutti gli attributi utente necessari.
Crea le tabelle di ricerca Users, Teams e Regions e collega le regole RLS di DAX.
Pubblica un unico modello semantico condiviso e configura i pubblici della tua app di Power BI.
Allinea perfettamente i filtri di contesto di Power Apps con l'RLS del set di dati e testali.
Attiva le etichette di riservatezza e i criteri DLP, limitando esportazioni e condivisione secondo necessità.
Pianifica test mensili di convalida "Visualizza come" per l'RLS e audit automatici delle differenze di accesso.

Implementare una sicurezza a prova di proiettile in Power BI richiede una pianificazione attenta, ma il risultato è un ambiente analitico pulito, scalabile e pienamente conforme. Per approfondire le considerazioni architetturali, le discussioni su Microsoft Power Platform e i suggerimenti pratici per l'implementazione, ascolta l'episodio completo su Create Role-Based Dashboards in Power Platform!