Ruoli

Si applica a: SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium

I ruoli nei modelli tabulari definiscono le autorizzazioni membro per un modello. I membri del ruolo possono eseguire azioni sul modello, come definito dall'autorizzazione del ruolo. I ruoli definiti con autorizzazioni di lettura possono garantire inoltre sicurezza aggiuntiva a livello di riga tramite i relativi filtri.

Per Azure Analysis Services e set di dati di Power BI, gli utenti devono trovarsi nell'ID di Microsoft Entra e i gruppi specificati in base all'indirizzo di posta elettronica dell'organizzazione o all'UPN. Per SQL Server Analysis Services, i ruoli contengono membri utente in base al nome utente di Windows o al gruppo di Windows e alle autorizzazioni (lettura, processo, amministratore). Per Azure Analysis Services e modelli semantici di Power BI, gli utenti devono trovarsi in Azure Active Directory e i nomi utente e i gruppi specificati in base all'indirizzo di posta elettronica dell'organizzazione o all'UPN. Per SQL Server Analysis Services, i ruoli contengono membri utente in base al nome utente di Windows o al gruppo di Windows e alle autorizzazioni (lettura, processo, amministratore).

Importante

Quando si usa Visual Studio per creare ruoli e aggiungere utenti dell'organizzazione a un progetto di modello tabulare che verrà distribuito in Azure Analysis Services o Power BI, usare l'area di lavoro integrata.

Importante

Per consentire agli utenti di connettersi a un modello distribuito usando un'applicazione client di report, è necessario creare almeno un ruolo con almeno l'autorizzazione di lettura per cui tali utenti sono membri.

Le informazioni contenute in questo articolo sono destinate agli autori di modelli tabulari che definiscono i ruoli usando la finestra di dialogo Gestione ruoli in SSDT. I ruoli definiti durante la creazione di modelli vengono applicati al database dell'area di lavoro modello. Dopo la distribuzione di un database modello, gli amministratori del database modello possono gestire (aggiungere, modificare, eliminare) membri del ruolo usando SSMS.

Informazioni sui ruoli

I ruoli vengono usati in Analysis Services per gestire l'accesso ai dati del modello. Sono disponibili due tipi di ruoli:

  • Ruolo server, un ruolo fisso che fornisce l'accesso amministratore a un'istanza del server Analysis Services. I ruoli del server non si applicano a Power BI. Power BI usa invece ruoli dell'area di lavoro.

  • Ruoli del database, ovvero ruoli definiti dagli autori e amministratori di modelli per controllare l'accesso al database modello e ai dati per utenti non amministratori.

I ruoli definiti per un modello tabulare sono ruoli del database. Ovvero, i ruoli contengono membri costituiti da utenti o gruppi che dispongono di autorizzazioni specifiche che definiscono l'azione che tali membri possono eseguire nel database del modello. Un ruolo viene creato come oggetto separato nel database e si applica solo al database in cui viene creato tale ruolo. Gli utenti e i gruppi sono inclusi nel ruolo dell'autore del modello, che per impostazione predefinita dispone delle autorizzazioni amministratore nel server di database dell'area di lavoro; per un modello distribuito da un amministratore.

I ruoli nei modelli tabulari possono essere ulteriormente definiti con filtri di riga, noti anche come sicurezza a livello di riga. Per questi ultimi vengono utilizzate le espressioni DAX per definire le righe in una tabella e tutte le righe correlate nelle numerose direzioni in cui un utente può effettuare query. I filtri di riga tramite espressioni DAX possono essere definiti solo per le autorizzazioni di lettura e di lettura ed elaborazione. In Power BI i ruoli del modello vengono definiti in Power BI Desktop e si applicano solo alla sicurezza a livello di riga. Per altre informazioni, vedere Filtri di riga più avanti in questo articolo.

Per impostazione predefinita, quando si crea un nuovo progetto modello tabulare, il progetto non ha ruoli. È possibile definire i ruoli nella finestra di dialogo Gestione ruoli di SSDT. Quando i ruoli vengono definiti durante la creazione di modelli, essi vengono applicati al database dell'area di lavoro modello. Quando viene distribuito il modello, gli stessi ruoli vengono applicati al modello distribuito. Dopo la distribuzione di un modello, i membri del ruolo server ([Amministratore di Analysis Services) e gli amministratori del database possono gestire i ruoli associati al modello e i membri associati a ogni ruolo usando SSMS.

Autorizzazioni

Le autorizzazioni per il ruolo descritte in questa sezione si applicano solo a Azure Analysis Services e SQL Server Analysis Services. In Power BI le autorizzazioni vengono definite per il modello semantico. Per altre informazioni, vedere Gestire l'accesso al modello semantico.

Ogni ruolo dispone di una singola autorizzazione definita per il database, eccetto l'autorizzazione combinata di lettura ed elaborazione. Per impostazione predefinita, un nuovo ruolo disporrà dell'autorizzazione Nessuno. Ovvero, una volta che i membri sono stati aggiunti al ruolo con l'autorizzazione Nessuno, non possono modificare il database, eseguire operazioni di elaborazione, eseguire query sui dati né esaminare il database, a meno che non venga concessa un'autorizzazione diversa.

Un gruppo o un utente può essere un membro di qualsiasi numero di ruoli, ogni ruolo con un'autorizzazione diversa. Se un utente è membro di più ruoli, le autorizzazioni definite per ogni ruolo sono cumulative. Ad esempio, se un utente è membro di un ruolo con l'autorizzazione di lettura, e anche membro di un ruolo con l'autorizzazione Nessuno, tale utente disporrà delle autorizzazioni di lettura.

Ciascun ruolo può disporre di una delle seguenti autorizzazioni definite:

Autorizzazioni Descrizione Filtri di riga tramite DAX
Nessuno I membri non possono apportare alcuna modifica allo schema del database modello, né eseguire query sui dati. Filtri di riga non applicabili. Agli utenti con questo ruolo non è visibile alcun dato.
Lettura I membri possono eseguire query sui dati, in base ai filtri di riga, ma non possono visualizzare il database modello in SSMS, né possono apportare modifiche allo schema del database modello e l'utente non può elaborare il modello. Filtri di riga applicabili. Agli utenti sono visibili solo i dati specificati nella formula DAX del filtro di riga.
Lettura ed elaborazione I membri possono eseguire query sui dati in base ai filtri a livello di riga ed effettuare operazioni di elaborazione eseguendo uno script o un pacchetto contenente un comando di elaborazione, ma non possono apportare alcuna modifica al database, Impossibile visualizzare il database del modello in SSMS. Filtri di riga applicabili. È possibile eseguire query solo sui dati specificati nella formula DAX del filtro di riga.
Processo I membri possono effettuare operazioni di elaborazione eseguendo uno script o un pacchetto contenente un comando di elaborazione. Non è possibile modificare lo schema del database modello, Non è eseguire query sui dati. Impossibile eseguire query sul database del modello in SSMS. Filtri di riga non applicabili. Non è possibile eseguire query sui dati in questo ruolo
Amministratore I membri possono apportare modifiche allo schema del modello e possono eseguire query su tutti i dati nella finestra di progettazione modelli, nel client di report e in SSMS. Filtri di riga non applicabili. È possibile eseguire query su tutti i dati in questo ruolo.

Nota

I membri con autorizzazioni lettura e lettura e processo possono eseguire query sui dati in base ai filtri di riga, ma non possono visualizzare il database del modello in SSMS. I membri non possono apportare modifiche allo schema del database del modello e non possono elaborare il modello. Tuttavia, in SQL Server Analysis Services 2019 e versioni precedenti, i membri possono usare DMV per determinare le definizioni di misura. SQL Server Analysis Services 2022 e versioni successive bloccano l'accesso alle DMV per migliorare la sicurezza.

Filtri di riga

I filtri di riga, comunemente noti come sicurezza a livello di riga in Power BI, definiscono quali righe in una tabella possono essere sottoposte a query dai membri di un ruolo specifico. e vengono definiti per ogni tabella in un modello tramite formule DAX.

I filtri di riga possono essere definiti solo per i ruoli con le autorizzazioni Lettura e Lettura ed elaborazione. Per impostazione predefinita, se per una particolare tabella non è stato definito alcun filtro di riga, i membri di un ruolo con l'autorizzazione di lettura o di lettura ed elaborazione saranno in grado di eseguire query su tutte le righe della tabella, a meno che non venga applicato il filtro incrociato da un'altra tabella.

Una volta definito un filtro di riga per una determinata tabella, una formula DAX da cui deve essere restituito un valore TRUE o FALSE, tale filtro consente di definire le righe in cui i membri di tale particolare ruolo possono eseguire query. Non sarà possibile eseguire query sulle righe non incluse nella formula DAX. Ad esempio, per i membri del ruolo Sales, la tabella Customers con l'espressione filtri di riga seguente, =Customers [Country] = "USA", i membri del ruolo Sales saranno in grado di visualizzare solo i clienti negli Stati Uniti.

I filtri di riga vengono applicati alle righe specificate e a quelle correlate. Quando una tabella ha più relazioni, i filtri applicano la sicurezza per la relazione attiva. I filtri di riga saranno intersecati con altri relativi filtri definiti per le tabelle correlate, ad esempio:

Tabella Espressione DAX
Region =Region[Country]="USA"
ProductCategory =ProductCategory[Name]="Bicycles"
Transazioni =Transactions[Year]=2020

L'effetto netto di queste autorizzazioni sulla tabella Transazioni è che i membri potranno eseguire query su righe di dati in cui il cliente si trova negli Stati Uniti e la categoria di prodotti è biciclette e l'anno è 2020. Gli utenti non sarebbero in grado di eseguire query su transazioni esterne agli Stati Uniti o su transazioni che non sono biciclette o transazioni non nel 2020, a meno che non siano membri di un altro ruolo che concede queste autorizzazioni.

È possibile usare il filtro, =FALSE(), per negare l'accesso a tutte le righe di un'intera tabella.

Per altre informazioni sui ruoli del modello in Power BI, vedere Sicurezza a livello di riga in Power BI.

Sicurezza dinamica

La sicurezza dinamica consente di definire la sicurezza a livello di riga in base al nome utente dell'utente attualmente connesso o alla proprietà CustomData restituita da un stringa di connessione. Per implementare la sicurezza dinamica, è necessario includere nel modello una tabella con i valori di accesso (nome utente di Windows) per gli utenti e un campo che è possibile utilizzare per definire una particolare autorizzazione; ad esempio, una tabella dimEmployees con un ID di accesso (dominio\nomeutente) e un valore di reparto per ogni dipendente.

Per implementare la sicurezza dinamica, è possibile utilizzare le funzioni seguenti come parte di una formula DAX per restituire il nome dell'utente attualmente connesso o la proprietà CustomData in una stringa di connessione:

Funzione Descrizione
Funzione USERNAME (DAX) Viene restituito il valore dominio\nomeutente dell'utente attualmente connesso.
Funzione CUSTOMDATA (DAX) Viene restituita la proprietà CustomData in una stringa di connessione.

È possibile utilizzare la funzione LOOKUPVALUE per restituire valori per una colonna in cui il nome utente di Windows corrisponde al nome utente restituito dalla funzione USERNAME o una stringa restituita dalla funzione CustomData. Le query possono quindi essere limitate nel caso in cui i valori restituiti da LOOKUPVALUE corrispondono ai valori nella stessa tabella o in una tabella correlata.

Ad esempio, utilizzando la formula:

='dimDepartment'[DepartmentId]=LOOKUPVALUE('dimEmployees'[DepartmentId], 'dimEmployees'[LoginId], USERNAME(), 'dimEmployees'[LoginId], 'dimDepartment'[DepartmentId])

La funzione LOOKUPVALUE restituisce valori per la colonna dimEmployees[DepartmentId] in cui la funzione dimEmployees[LoginId] è uguale all'ACCOUNT di accesso dell'utente attualmente connesso, restituito da USERNAME e i valori per dimEmployees[DepartmentId] sono uguali ai valori per dimDepartment[DepartmentId]. I valori in DepartmentId restituiti da LOOKUPVALUE vengono quindi utilizzati per limitare le righe in cui vengono eseguite query nella tabella dimDepartment e qualsiasi tabella correlata da DepartmentId. Vengono restituite solo le righe in cui DepartmentId è presente anche nei valori per DepartmentId restituiti da LOOKUPVALUE.

dimEmployees

LastName FirstName Loginid DepartmentName DepartmentId
Brown Kevin Adventure-works\kevin0 Marketing 7
Bradley David Adventure-works\david0 Marketing 7
Dobney JoLynn Adventure-works\JoLynn0 Produzione 4
Baretto DeMattos Paula Adventure-works\Paula0 Human Resources 2

dimDepartment

DepartmentId DepartmentName
1 Aziendale
2 Executive General and Administration
3 Inventory Management
4 Produzione
5 Controllo di qualità
6 Ricerca e sviluppo
7 Vendite e marketing

Ruoli di test

Quando si crea un progetto modello in Visual Studio, è possibile usare la funzionalità Analizza in Excel per testare l'efficacia dei ruoli definiti. Se si fa clic su Analizza in Excel nel menu Modelloin Progettazione modelli prima che venga aperto Excel, verrà visualizzata la finestra di dialogo Scegli credenziali e prospettiva . In questa finestra di dialogo è possibile specificare il nome utente corrente, un nome utente diverso, un ruolo e una prospettiva che verranno utilizzati per la connessione al modello dell'area di lavoro come origine dati. Per i dettagli, vedere Analizza in Excel.

Ruoli di scripting

I ruoli per i modelli distribuiti e i modelli semantici possono essere scriptati usando Tabular Model Scripting Language (TMSL) per creare o modificare l'oggetto Roles. Gli script TMSL possono essere eseguiti in SSMS o con il cmdlet di PowerShell Invoke-ASCmd.

Vedi anche

Creare e gestire ruoli
Prospettive
Analizza in Excel
Funzione USERNAME (DAX)
LOOKUPVALUE (DAX) - funzione
Funzione CUSTOMDATA (DAX)