Sicurezza a livello di riga con Power BI

La sicurezza a livello di riga limita l'accesso ai dati per utenti specifici di un modello semantico di Power BI. I filtri limitano i dati a livello di riga e si definiscono i filtri all'interno dei ruoli. Nel servizio Power BI, gli utenti con accesso a un'area di lavoro hanno accesso a modelli semantici in tale area di lavoro. RLS limita l'accesso ai dati solo per gli utenti con autorizzazioni Visualizzatore. Non si applica ai ruoli amministratore, membro o collaboratore dell'area di lavoro.

Per implementare la RLS (sicurezza a livello di riga), seguire questo flusso di lavoro generale:

1. Definire ruoli e regole in Power BI Desktop usando espressioni di filtro DAX.
2. Publish il modello semantico e il report nel servizio Power BI.
3. Aggiungi membri ai ruoli nel servizio Power BI.
4. Convalidare usando la funzionalità Test come ruolo per verificare che il filtro dei dati funzioni come previsto.

È possibile configurare la sicurezza a livello di riga (RLS) per i modelli semantici importati in Power BI Desktop o nel servizio Power BI. È anche possibile configurare la sicurezza a livello di riga (RLS) nei modelli semantici che usano la modalità DirectQuery, ad esempio in SQL Server. Per le connessioni dinamiche di Analysis Services o Azure Analysis Services, configurare la sicurezza a livello di riga nel modello, non in Power BI. L'opzione di sicurezza non viene visualizzata per i modelli semantici di connessione dinamica.

Definire i ruoli e le regole in Power BI Desktop

È possibile definire i ruoli e le regole in Power BI Desktop. Con questo editor è possibile passare dall'interfaccia a discesa predefinita a un'interfaccia DAX e viceversa. Quando si esegue la pubblicazione in Power BI, verranno pubblicate anche le definizioni dei ruoli.

Per definire i ruoli di sicurezza:

1. Importare dati nel report di Power BI Desktop o configurare una connessione DirectQuery.

   Nota

   Non è possibile definire i ruoli in Power BI Desktop per connessioni dinamiche di Analysis Services. È necessario eseguire questa operazione nel modello di Analysis Services.

2. Nella scheda Modellazione selezionare Gestisci ruoli.

3. Nella finestra Gestisci ruoli selezionare Nuovo per creare un nuovo ruolo.

4. In Ruoli specificare un nome per il ruolo e premere INVIO.

   Nota

   Non è possibile definire un ruolo con una virgola, ad esempio London,ParisRole.

5. In Seleziona tabelle selezionare la tabella a cui si vuole applicare un filtro di sicurezza a livello di riga.

6. In Filtra dati usare l'editor predefinito per definire i ruoli. Le espressioni create restituiscono un valore vero o falso. Un filtro DAX valuta TRUE/FALSE per ogni riga. Solo le righe che restituiscono TRUE sono visibili Tutto il resto viene rimosso completamente.

   Nota

   Non tutti i filtri di sicurezza a livello di riga supportati in Power BI possono essere definiti usando l'editor predefinito. Le limitazioni includono espressioni che oggi possono essere definite solo usando DAX, incluse regole dinamiche come username() o userprincipalname(). Per definire i ruoli usando questi filtri passare all'editor DAX.

7. Facoltativamente, selezionare Passa all'editor DAX per passare all'uso dell'editor DAX per definire il ruolo. Le espressioni DAX restituiscono un valore true o false. Ad esempio: [Entity ID] = “Value”. L'editor DAX è completo di completamento automatico per le formule (IntelliSense). È possibile selezionare il segno di spunta sopra la casella dell'espressione per convalidare l'espressione e il pulsante X sopra la casella dell'espressione per ripristinare le modifiche.

   Nota

   È possibile usare username() all'interno di questa espressione. Tenere presente che username() ha il formato DOMAIN\username in Power BI Desktop. Nel servizio Power BI e nel server di report di Power BI, ha il formato del User Principal Name (UPN) dell'utente. Inoltre, in questa casella dell'espressione si usano le virgole per separare gli argomenti della funzione DAX anche se si usano impostazioni locali che in genere prevedono il separatore punto e virgola (ad esempio italiano o tedesco).

8. È possibile tornare all'editor predefinito selezionando Passa all'editor predefinito. Tutte le modifiche apportate in entrambe le interfacce dell'editor vengono salvate in modo permanente passando da un'interfaccia all'altra, ove possibile. Quando si definisce un ruolo usando l'editor DAX che non può essere definito nell'editor predefinito, se si tenta di passare all'editor predefinito verrà visualizzato un avviso che indica che il cambio di editor potrebbe causare la perdita di alcune informazioni. Per mantenere queste informazioni, selezionare Annulla e continuare a modificare questo ruolo solo nell'editor DAX.

   Nota

   In questa casella dell'espressione, usare le virgole per separare gli argomenti della funzione DAX anche se si usano impostazioni locali che in genere prevedono il separatore punto e virgola (ad esempio italiano o tedesco).

9. Seleziona Salva.

Non è possibile assegnare gli utenti a un ruolo in Power BI Desktop. Li assegni nel servizio Power BI. È possibile abilitare la sicurezza dinamica all'interno di Power BI Desktop usando le funzioni DAX username() o userprincipalname() e configurando le relazioni appropriate.

Modelli di filtro DAX comuni per i ruoli RLS

Gli esempi seguenti mostrano espressioni di filtro DAX comuni che è possibile usare per definire i ruoli di sicurezza a livello di riga in Power BI Desktop:

• Sicurezza statica a livello di riga: restringe i dati a un valore fisso:

  [Region] = "West"
  

• Sicurezza a livello di riga dinamica con UPN: limita l'accesso ai dati in base all'indirizzo email dell'utente collegato.

  [UserEmail] = USERPRINCIPALNAME()
  

• RLS dinamica con USERNAME — Limita i dati basato sul dominio e sul nome utente:

  [UserDomain] = USERNAME()
  

• RLS dinamica con CUSTOMDATA: limita i dati in base a una stringa personalizzata passata dall'applicazione di embedding.

  [AppRole] = CUSTOMDATA()
  

  Nota

  CUSTOMDATA() viene usato principalmente in scenari incorporati in cui l'applicazione passa una stringa di identità effettiva personalizzata tramite l'API REST Power BI.

La sicurezza a livello di riga dinamica è l'approccio più comune perché consente a una singola definizione di ruolo di filtrare i dati in modo diverso per ogni utente, in base a una tabella di mapping utente nel modello di dati.

Esempio: Filtrare Power BI dati di vendita in base all'area

Si supponga di avere una Sales tabella con colonne Region, Producte Amount. Si vuole limitare gli utenti assegnati al ruolo "West" in modo che visualizzino solo le righe in cui l'area è "West".

Nel campo filtro DAX per il ruolo "West" immettere l'espressione seguente:

[Region] = "West"

Prima di filtrare (tutti i dati):

Dopo il filtro (visualizzazione per gli utenti del ruolo "West):After filtering (view for "West" role users):

L'espressione DAX funge da filtro di riga che valuta ogni riga della tabella. Solo le righe in cui la Region colonna è uguale a "West" sono visibili agli utenti assegnati a tale ruolo.

Filtro incrociato bidirezionale con RLS

Per impostazione predefinita, i filtri per la sicurezza a livello di riga usano i filtri unidirezionali, indipendentemente dal fatto che le relazioni siano unidirezionali o bidirezionali.

È possibile abilitare manualmente il filtro incrociato bidirezionale con sicurezza a livello di riga selezionando la relazione e quindi la casella di controllo Applica filtro di sicurezza in entrambe le direzioni. Selezionare questa opzione se è stata implementata anche la sicurezza a livello di riga dinamica a livello di server, in cui la sicurezza a livello di riga si basa sul nome utente o sull'ID di accesso. Se una tabella fa parte di più relazioni bidirezionali, è possibile selezionare questa opzione solo per una di queste relazioni.

Per altre informazioni, vedere Filtro incrociato bidirezionale con DirectQuery in Power BI e l'articolo tecnico Protezione del modello semantico tabulare di BI.

Gestire la sicurezza nel modello semantico

Per gestire la sicurezza nel modello semantico, aprire l'area di lavoro in cui è stato salvato il modello semantico in Microsoft Fabric e seguire questa procedura:

1. In Microsoft Fabric selezionare il menu Altre opzioni per un modello semantico. Questo menu viene visualizzato quando si passa il puntatore su un nome di modello semantico.

   

2. Seleziona Sicurezza.

   

Security porta alla pagina Sicurezza a livello di riga, dove aggiungi membri a un ruolo che hai creato. Gli utenti con il ruolo Collaboratore dell'area di lavoro o superiore vedono l'opzione Sicurezza e possono assegnare un ruolo agli utenti. La proprietà del modello semantico o l'autorizzazione Build potrebbero essere necessari anche a seconda dello scenario.

Gestire l'appartenenza al ruolo RLS nel servizio Power BI

Aggiungere membri a un ruolo RLS

Nel servizio Power BI, è possibile aggiungere un membro a un ruolo RLS digitando l'indirizzo e-mail o il nome dell'utente o del gruppo di sicurezza. Non è possibile aggiungere gruppi creati in Power BI. È possibile aggiungere membri esterni all'organizzazione. Per indicazioni su come RLS funziona con utenti esterni B2B guest, vedere Considerazioni per gli utenti esterni guest B2B.

Per configurare la sicurezza a livello di riga, è possibile usare i gruppi Microsoft Entra ID e abilitati alla posta elettronica seguenti:

• Gruppo di distribuzione
• Gruppo abilitato alla posta elettronica
• Microsoft Entra gruppo di sicurezza: se il gruppo di sicurezza contiene utenti guest B2B esterni, vedere Considerazioni per gli utenti esterni (guest B2B) per limitazioni note.

È possibile visualizzare il numero di membri che fanno parte del ruolo in base al numero tra parentesi accanto al nome del ruolo o accanto a Membri.

Rimuovere membri da un ruolo RLS

È possibile rimuovere i membri selezionando la X accanto al nome.

Convalidare il ruolo all'interno del servizio Power BI

È possibile verificare che il ruolo RLS definito funzioni correttamente nel servizio Power BI eseguendo un test del ruolo.

1. Selezionare Altre opzioni (...) accanto al ruolo.
2. Seleziona Test come ruolo.

Quando il report viene caricato, verificare quanto segue:

• Il report visualizza solo le righe di dati che corrispondono all'espressione di filtro definita nel ruolo.
• Gli oggetti visivi, le tabelle e i grafici riflettono i dati filtrati, non il set di dati completo.
• Se si usa la sicurezza a livello di riga dinamica, i dati corrispondono all'identità visualizzata nell'intestazione Now viewing as .

Nell'intestazione di pagina viene visualizzato il ruolo applicato. Provare altri ruoli, una combinazione di ruoli o una persona specifica selezionando Visualizza come. Qui vengono visualizzati dettagli importanti sulle autorizzazioni relative alla persona o al ruolo sottoposto a test. Per ulteriori informazioni su come le autorizzazioni interagiscono con RLS, vedere Esperienza utente RLS.

Testare altri report connessi al modello semantico selezionando Visualizzazione nell'intestazione della pagina. È possibile testare solo i report che si trovano nella stessa area di lavoro del modello semantico.

Per tornare alla visualizzazione normale, selezionare Torna alla sicurezza a livello di riga.

Uso delle funzioni DAX username() o userprincipalname()

È possibile sfruttare la funzione DAX username() o userprincipalname() all'interno del set di dati. Queste funzioni possono essere usate all'interno di espressioni in Power BI Desktop. Quando si pubblica il modello, verrà usata all'interno del servizio Power BI.

All'interno di Power BI Desktop, username() restituirà un utente nel formato DOMINIO\utente, mentre userprincipalname() restituirà un utente nel formato user@contoso.com.

All'interno del servizio Power BI, username() e userprincipalname() restituiranno il Nome Principale Utente (UPN, User Principal Name). simile a un indirizzo di posta elettronica.

Usare la sicurezza a livello di riga (RLS) con le aree di lavoro in Power BI

Se pubblichi il report di Power BI Desktop in un'area di lavoro nel servizio Power BI, i ruoli RLS vengono applicati ai membri a cui è assegnato il ruolo Visualizzatore nell'area di lavoro. Anche se a Viewers viene concessa l'autorizzazione Build per il modello semantico, la sicurezza a livello di riga continua ad applicarsi. Ad esempio, se gli utenti con autorizzazioni Build usano Analizza in Excel, il loro accesso ai dati è limitato dalla sicurezza a livello di riga. I membri dell'area di lavoro assegnati a Admin, Member o Contributor dispongono dell'autorizzazione di modifica per il modello semantico e, pertanto, la sicurezza a livello di riga (RLS) non è applicabile a loro. Se si desidera che RLS (sicurezza a livello di riga) venga applicata alle persone in un'area di lavoro, è possibile assegnarle solo il ruolo Visualizzatore. Per altre informazioni, vedere Ruoli nelle aree di lavoro.

Considerazioni per gli utenti esterni (guest B2B)

Se si condividono contenuti di Power BI con utenti esterni tramite Microsoft Entra B2B, tenere presenti le considerazioni seguenti per RLS.

Gruppi di sicurezza di Microsoft Entra con membri esterni

I gruppi di sicurezza di Microsoft Entra che contengono utenti ospiti B2B esterni potrebbero non funzionare come previsto se usati per l'appartenenza ai ruoli di sicurezza a livello di riga. In alcune configurazioni — in particolare quando l'utente esterno ha un account di tipo guest (anziché un account di tipo member) — l'appartenenza del guest ai gruppi non viene valutata correttamente dal servizio Power BI quando applica i filtri RLS.

Soluzione alternativa consigliata: Anziché aggiungere gli utenti esterni ai ruoli RLS tramite i gruppi di sicurezza di Microsoft Entra, aggiungerli direttamente al ruolo tramite indirizzo email. L'indirizzo e-mail viene associato all'account B2B dell'utente. Questo garantisce che la loro identità sia associata correttamente quando vengono applicati i filtri RLS. Per altre informazioni, vedi Gestire l'appartenenza al ruolo di sicurezza a livello di riga nel servizio Power BI.

Per le organizzazioni con molti utenti esterni, è consigliabile usare la sicurezza a livello di riga dinamica con USERPRINCIPALNAME() anziché l'appartenenza a ruoli basata su gruppo. Questo approccio valuta singolarmente l'identità di ogni utente ed evita completamente il problema di risoluzione dell'appartenenza al gruppo.

Se il problema persiste dopo l'applicazione della soluzione alternativa, vedere Risoluzione dei problemi: il guest B2B esterno non visualizza dati in un report Power BI per ulteriori passaggi di diagnostica.

Risoluzione UPN per gli utenti guest B2B nella RLS di Power BI

Quando un utente guest B2B esterno accede a un report di Power BI, la funzione DAX USERPRINCIPALNAME() restituisce in genere un identificatore simile a un messaggio di posta elettronica, ad esempio user@partner.com. In alcune configurazioni potrebbe restituire un UPN guest nel #EXT# formato , ad esempio user_partner.com#EXT#@yourtenant.onmicrosoft.com.

Questa distinzione è importante per la RLS dinamica. Se la tabella di mapping utente archivia un formato di identificatore diverso da quello USERPRINCIPALNAME() restituito, l'espressione di filtro non corrisponde e l'utente guest potrebbe non visualizzare dati o dati non corretti.

Comportamento di USERNAME() per i guest B2B nella sicurezza a livello di riga (RLS) in Power BI

La USERNAME() funzione DAX restituisce l'identificatore dell'utente domain\username . Per gli utenti guest B2B, USERNAME() spesso restituisce un identificatore simile a un UPN come USERPRINCIPALNAME(), a seconda della configurazione (ad esempio, user@partner.com), anziché nel formato domain\username. Poiché USERNAME() e USERPRINCIPALNAME() spesso restituiscono lo stesso valore per i guest B2B, la maggior parte delle implementazioni viene usata USERPRINCIPALNAME() per coerenza.

Approccio consigliato: Archiviare e usare in modo coerente lo stesso formato di identificatore nella tabella di mapping utente del valore restituito da USERPRINCIPALNAME(). Nella maggior parte dei casi, l'uso degli indirizzi di posta elettronica semplifica la gestione:

[UserEmail] = USERPRINCIPALNAME()

Dove la UserEmail colonna contiene indirizzi di posta elettronica come user@partner.com per gli utenti interni ed esterni.

Risoluzione dei problemi: il guest B2B esterno non vede dati in un report di Power BI

Se un utente guest B2B visualizza un report vuoto o riceve un messaggio "nessun dato", seguire questa procedura:

1. Verifica il formato UPN restituito — Crea una misura di test usando USERPRINCIPALNAME() e visualizzala in un visual scheda. Chiedere all'utente guest di visualizzare il report per visualizzare il valore effettivo restituito.
2. Controlla la tabella di mapping degli utenti — Verifica che la tabella di mapping contenga una riga con un valore che corrisponda esattamente al valore restituito da USERPRINCIPALNAME() per quell'ospite.
3. Verificare la distinzione tra maiuscole e minuscole — per impostazione predefinita, i confronti tra stringhe DAX non distinguono tra maiuscole e minuscole, ma verifica che l'origine dati non abbia introdotto valori sensibili alle maiuscole/minuscole.
4. Esaminare le impostazioni di accesso tra tenant: se l'organizzazione usa criteri di accesso tra tenant, questi possono influire sul formato UPN visualizzato Power BI.
5. Esegui il test con l'utente guest effettivo — La funzionalità Test as role usa la tua identità. Convalidare sempre con l'account guest esterno reale.
6. Verifica l'assegnazione del ruolo — Se un utente ospite visualizza più dati del previsto, verifica che gli sia stato assegnato un ruolo RLS. Gli utenti a cui non è assegnato alcun ruolo RLS in genere non vedono alcun dato (risultati vuoti), perché RLS viene applicato, ma non è assegnato alcun ruolo corrispondente. Un filtro DAX valuta TRUE/FALSE per ogni riga. Sono visibili solo le righe che restituiscono TRUE. Tutto il resto è completamente rimosso.

Per altre informazioni sulla condivisione di contenuto Power BI con utenti esterni, vedere Distribute Power BI contenuto a utenti guest esterni con Microsoft Entra B2B.

Considerazioni e limitazioni

È possibile visualizzare le limitazioni correnti per la sicurezza a livello di riga nei modelli cloud qui:

• Se in precedenza sono stati definiti ruoli e regole nel servizio Power BI, sarà necessario crearli di nuovo in Power BI Desktop.
• È possibile definire il RLS solo nei modelli semantici creati con Power BI Desktop. Se si desidera abilitare RLS per i modelli semantici creati con Excel, è necessario prima convertire i file in file di Power BI Desktop (PBIX). Altre informazioni.
• Le entità servizio non possono essere aggiunte a un ruolo di sicurezza a livello di riga (Row-Level Security, RLS). Di conseguenza, la sicurezza a livello di riga (RLS) non viene applicata alle app che utilizzano un'entità di servizio come l'identità effettiva finale.
• Sono supportate solo le connessioni di importazione e DirectQuery. Le connessioni dinamiche ad Analysis Services vengono gestite nel modello locale.
• Con RLS abilitato, l'uso della funzione DAX USERELATIONSHIP() nelle query e misure DAX può causare errori imprevisti. Per risolvere questo problema, riprogettare le espressioni DAX per evitare USERELATIONSHIP() e usare invece relazioni a livello di modello o altri modelli DAX.
• La funzionalità Test as role/View as role non funziona per i modelli DirectQuery con l'accesso Single Sign-On (SSO) abilitato.
• La funzionalità "Esegui test come ruolo/Visualizza come ruolo" mostra solo i report dell'area di lavoro dei modelli semantici.
• La funzione "Test come ruolo/Visualizza come ruolo" non funziona per i report impaginati.
• L'identità basata su token funziona solo per i modelli DirectQuery su una capacità connessa a un database SQL di Azure configurato per consentire l'autenticazione di Microsoft Entra. Per altre informazioni, vedere Incorporare un report con identità basata su token
• Il parametro 'IdentityBlob' è un token di accesso OAuth 2.0 per Azure SQL ed è supportato solo per i set di dati con una connessione DirectQuery a Azure SQL. Il meccanismo stesso è specifico di Azure SQL: il blob is un token di accesso Microsoft Entra con ambito limitato a https://database.windows.net/.default. Non esiste alcun meccanismo equivalente di trasferimento del token per altre origini dati nell'embedding App-owns-data. Per altre informazioni, vedere Informazioni di riferimento sulle API REST per GenerateToken.

Considerazioni e limitazioni per RLS dinamica

Quando si usa la sicurezza dinamica a livello di riga con funzioni DAX come USERPRINCIPALNAME(), USERNAME()o CUSTOMDATA(), tenere presenti le considerazioni seguenti.

Scenari tra tenant B2B

Negli scenari B2B, USERPRINCIPALNAME() restituisce l'identità risolta dal servizio Power BI, che può variare a seconda della configurazione del tenant. Può essere visualizzato in una delle seguenti forme:

• Indirizzo di posta elettronica dell'utente esterno (user@partner.com) o
• Valore risolto dal tenant, ad esempio user_partner.com#EXT#@tenant.onmicrosoft.com

Il formato esatto non è garantito e deve essere convalidato nell'ambiente in uso.

Se la tabella di mapping degli utenti archivia gli identificatori in un formato diverso da quello restituito da USERPRINCIPALNAME() per gli utenti ospiti, l'espressione di filtro RLS non corrisponderà e l'utente ospite non vedrà alcun dato oppure vedrà dati non corretti. Verificare sempre il valore esatto restituito da USERPRINCIPALNAME() per gli utenti esterni nell'ambiente.

Testare con le limitazioni del ruolo usando la sicurezza dinamica a livello di riga

La funzionalità Test come ruolo nel servizio Power BI usa la tua identità per valutare espressioni RLS dinamiche. Questo significa che USERPRINCIPALNAME() restituisce l'UPN dell'utente corrente, non quello dell'utente che si sta cercando di simulare. Non è possibile usare Testa come ruolo per vedere cosa vedrebbe uno specifico utente guest B2B o un'entità servizio.

Test as role simula l'appartenenza a un ruolo, ma non replica completamente il contesto di autenticazione di un altro utente, in particolare per gli utenti guest B2B o negli scenari incorporati.

Per verificare l'RLS dinamico per gli utenti esterni, accedere come l'effettivo utente guest e visualizzare direttamente il report. Questo è l'unico modo per confermare che USERPRINCIPALNAME() restituisca il valore previsto e che i filtri RLS siano applicati correttamente per tale utente.

Scenari incorporati con entità servizio

Quando si accede a un report tramite un'applicazione incorporata che esegue l'autenticazione con un service principal, USERPRINCIPALNAME() e USERNAME() restituiscono l'ID dell'applicazione del service principal o una stringa vuota, non l'identità di un utente finale.

Queste funzioni non restituiscono l'identità dell'utente finale e pertanto non possono essere utilizzate per il filtraggio per utente negli scenari di incorporazione con service principal. Ciò significa che i filtri RLS dinamici basati su queste funzioni non filtreranno i dati in base all'utente negli scenari di incorporamento.

Per applicare l'RLS per utente negli scenari di incorporamento, utilizzare la funzionalità effective identity dell'API REST di Power BI. Passare l'oggetto EffectiveIdentity con il nome utente e i ruoli appropriati durante la generazione di un token di incorporamento. Se le regole RLS usano CUSTOMDATA(), passa la stringa di dati personalizzata attraverso EffectiveIdentity.CustomData.

Per altre informazioni, vedere RLS per scenari incorporati per ISV.

Tenere presente che se un report di Power BI fa riferimento a una riga con RLS configurata, verrà visualizzato lo stesso messaggio come per un campo eliminato o inesistente. Per questi utenti, sembra che il report non funzioni correttamente.

Domande frequenti

Domanda: Cosa accade se sono stati precedentemente creati ruoli e regole per un set di dati nel servizio Power BI? Continueranno a funzionare anche se non si esegue alcuna operazione?
Risposta: No, gli oggetti visivi non verranno visualizzati correttamente. È necessario ricreare i ruoli e le regole in Power BI Desktop e quindi pubblicarli nel servizio Power BI.

Domanda: È possibile creare questi ruoli per le origini dati di Analysis Services?
Risposta: Sì, è possibile solo se i dati sono stati importati in Power BI Desktop. Se si usa una connessione dinamica, non è possibile configurare la sicurezza a livello di riga all'interno del servizio Power BI. Definisci la sicurezza a livello di riga nel modello di Analysis Services in locale.

Domanda: È possibile usare RLS per la restrizione delle colonne o delle misure accessibili agli utenti?
Risposta: No, se un utente può accedere a una riga specifica di dati, può visualizzare tutte le colonne di dati per tale riga. Per limitare l'accesso alle colonne e ai metadati delle colonne, è consigliabile usare la sicurezza a livello di oggetto.

Domanda: La sicurezza a livello di riga consente di nascondere i dati dettagliati, ma di concedere l'accesso ai dati riepilogati nelle visualizzazioni?
Risposta: No. È possibile proteggere singole righe di dati, ma gli utenti possono visualizzare sempre i dettagli o i dati riepilogati.

Domanda: Per l'origine dati sono già stati definiti ruoli di sicurezza, ad esempio ruoli di SQL Server o ruoli di SAP BW. Qual è la relazione tra questi ruoli e la sicurezza a livello di riga?
Risposta: La risposta varia a seconda che i dati vengano importati o che si usi DirectQuery. Quando si importano dati nel set di dati di Power BI, i ruoli di sicurezza nell'origine dati non vengono utilizzati. In questo caso, è necessario definire RLS per applicare regole di sicurezza per gli utenti che si connettono su Power BI. Quando si utilizza DirectQuery, i ruoli di sicurezza nell'origine dati vengono utilizzati. Quando un utente apre un report di Power BI invia una query all'origine dati sottostante, che applica le regole di sicurezza ai dati in base alle credenziali dell'utente.

Domanda: un utente può appartenere a più ruoli?
Risposta: un utente può appartenere a più ruoli e i ruoli possono essere sommati. Ad esempio, se un utente appartiene ai ruoli "Vendite" e "Marketing", può visualizzare i dati per entrambi questi ruoli.

Contenuto correlato

• Limitare l'accesso ai dati con sicurezza a livello di riga per Power BI Desktop
• Pianificazione dell'implementazione di Power BI: Pianificazione della sicurezza per gli utenti dei report
• Sicurezza a livello di riga per scenari integrati per ISV
• Distribute Power BI contenuto a utenti guest esterni con Microsoft Entra B2B

Domande? Provare a rivolgersi alla community di Power BI per suggerimenti. Contribuire con idee per migliorare Power BI