Ruoli
si applica a:
SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium
I ruoli nei modelli tabulari definiscono le autorizzazioni dei membri 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 anche offrire maggiore sicurezza a livello di riga usando filtri a livello di riga.
Per i modelli semantici di Azure Analysis Services e Power BI, gli utenti devono trovarsi nell'ID Microsoft Entra. I nomi utente e i gruppi vengono specificati dall'indirizzo di posta elettronica dell'organizzazione o dal nome dell'entità utente (UPN). Per SQL Server Analysis Services, i ruoli contengono membri utente specificati dal nome utente di Windows o dal gruppo di Windows e dalle autorizzazioni (lettura, processo, amministratore).
Importante
Se si usa Visual Studio per creare ruoli e aggiungere utenti a un progetto di modello tabulare che verrà distribuito in Azure Analysis Services o Power BI, usare 'area di lavoro integrata.
Importante
Per consentire agli utenti di connettersi a un modello distribuito usando un'applicazione client per la creazione di report, è necessario creare almeno un ruolo con almeno l'autorizzazione lettura. Aggiungere utenti dell'app client per la creazione di report al ruolo come 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 si applicano 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. Esistono due tipi di ruoli:
Il ruolo del server è un ruolo predefinito 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.
I ruoli del database vengono definiti dagli autori e dagli amministratori del modello per controllare l'accesso a un database modello e ai dati per gli utenti.
I ruoli definiti per un modello tabulare sono ruoli del database. Questi ruoli contengono utenti o gruppi con autorizzazioni specifiche che definiscono l'azione che tali membri possono eseguire nel database modello. Un ruolo viene creato come oggetto separato nel database e si applica solo al database in cui viene creato il ruolo. L'autore del modello aggiunge utenti e gruppi al ruolo. Per impostazione predefinita, l'autore del modello dispone delle autorizzazioni di amministratore per il server di database dell'area di lavoro; per un modello distribuito, i membri del ruolo vengono aggiunti da un amministratore.
I ruoli nei modelli tabulari possono essere ulteriormente definiti con filtri di riga, noti anche come sicurezza a livello di riga. I filtri di riga usano espressioni DAX per definire le righe di una tabella e le righe correlate in molte direzioni, che un utente può eseguire query. I filtri di riga che usano espressioni DAX possono essere definiti solo per le autorizzazioni di lettura e lettura ed elaborazione. In Power BI i ruoli del modello sono 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 di modello tabulare, il progetto non ha ruoli definiti. I ruoli vengono definiti usando la finestra di dialogo Gestione ruoli in SSDT. Quando i ruoli vengono definiti durante la creazione di modelli, vengono applicati al database dell'area di lavoro modello. Quando il modello viene distribuito, 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 di database possono gestire i ruoli associati al modello e i membri associati a ogni ruolo usando SSMS.
Autorizzazioni
Le autorizzazioni dei ruoli descritte in questa sezione si applicano solo ad 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 ai modelli semantici.
Ogni ruolo dispone di una singola autorizzazione di database definita ,ad eccezione dell'autorizzazione di lettura e elaborazione combinata. Per impostazione predefinita, un nuovo ruolo dispone dell'autorizzazione Nessuna. Quando i membri vengono aggiunti a un ruolo che dispone dell'autorizzazione Nessuno, non possono modificare il database, eseguire un'operazione di processo, eseguire query sui dati o visualizzare il database a meno che non venga concessa un'autorizzazione diversa.
Un gruppo o un utente può essere membro di un numero qualsiasi di ruoli, ognuno dei quali dispone di un'autorizzazione diversa. Quando 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 Lettura e anche un membro di un ruolo con autorizzazione Nessuno, tale utente dispone delle autorizzazioni di lettura.
Ogni ruolo può avere una delle autorizzazioni seguenti definite:
| Autorizzazioni | Descrizione | Filtri di riga con DAX |
|---|---|---|
| Nessuno | I membri non possono apportare modifiche allo schema del database modello e non possono eseguire query sui dati. | I filtri di riga non si applicano. Nessun dato è visibile agli utenti in questo ruolo |
| Leggere | I membri possono eseguire query sui dati (in base ai filtri di riga) ma non possono visualizzare il database del modello in SSMS, non possono apportare modifiche allo schema del database modello e l'utente non può elaborare il modello. | È possibile applicare i filtri di riga. Solo i dati specificati nella formula DAX del filtro di riga sono visibili agli utenti. |
| Lettura ed elaborazione | I membri possono eseguire query sui dati (in base ai filtri a livello di riga) ed eseguire operazioni di processo eseguendo uno script o un pacchetto che contiene un comando di processo, ma non possono apportare modifiche al database. Gli utenti con autorizzazione non possono visualizzare il database modello in SSMS. | È possibile applicare i filtri di riga. È possibile eseguire query solo sui dati specificati nella formula DAX del filtro di riga. |
| Processo | I membri possono eseguire operazioni di elaborazione eseguendo uno script o un pacchetto che contiene un comando di processo. I membri non possono modificare lo schema del database modello, non possono eseguire query sui dati e non possono eseguire query sul database modello in SSMS. | I filtri di riga non si applicano. Nessun dato può essere sottoposto a query 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 creazione di report e in SSMS. | I filtri di riga non si applicano. Tutti i dati possono essere sottoposti a query in questo ruolo. |
Nota
I membri con autorizzazioni lettura e lettura ed elaborazione possono eseguire query sui dati in base ai filtri di riga, ma non possono visualizzare il database modello in SSMS. I membri non possono apportare modifiche allo schema del database 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 delle misure. 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. I filtri di riga vengono definiti per ogni tabella in un modello usando formule DAX.
I filtri di riga possono essere definiti solo per i ruoli con autorizzazioni di lettura e lettura ed elaborazione. Per impostazione predefinita, se un filtro di riga non è definito per una tabella specifica, i membri di un ruolo con autorizzazione Lettura o Lettura ed Elaborazione possono eseguire query su tutte le righe della tabella, a meno che il filtro incrociato non venga applicato da un'altra tabella.
Dopo aver definito un filtro di riga per una determinata tabella, una formula DAX che restituisce un valore TRUE/FALSE definisce le righe su cui è possibile eseguire query da parte dei membri di quel particolare ruolo. Non è possibile eseguire query sulle righe non incluse nella formula DAX. Ad esempio, per i membri del ruolo Sales, se nella tabella Customers è presente l'espressione di filtri di riga seguente, =Customers [Country] = "USA", i membri del ruolo Sales vedranno solo i clienti negli Stati Uniti.
I filtri di riga si applicano alle righe specificate e alle righe correlate. Quando una tabella ha più relazioni, i filtri applicano la sicurezza per la relazione attiva. I filtri di riga verranno intersecati con altri filer di riga definiti per le tabelle correlate, ad esempio:
| Tavolo | Espressione DAX |
|---|---|
| Regione | =Region[Country]="USA" |
| ProductCategory | =ProductCategory[Name]="Biciclette" |
| Transazioni | =Transactions[Year]=2020 |
L'effetto netto di queste autorizzazioni nella tabella Transactions è che i membri possono 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 possono eseguire query su transazioni esterne agli Stati Uniti o transazioni che non sono biciclette o transazioni non incluse 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 per 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 una stringa di connessione. Per implementare la sicurezza dinamica, è necessario includere una tabella con valori di account di accesso (nome utente di Windows) per gli utenti e un campo che può essere usato per definire una determinata autorizzazione nel modello. Ad esempio, includere una tabella dimEmployees con un ID di accesso (dominio\nomeutente) e un valore di reparto per ogni dipendente nel modello.
Per implementare la sicurezza dinamica, è possibile usare le funzioni seguenti come parte di una formula DAX per restituire il nome utente dell'utente attualmente connesso o la proprietà CustomData in una stringa di connessione:
| Funzione | Descrizione |
|---|---|
| funzione USERNAME (DAX) |
Restituisce il dominio\nome utente dell'utente attualmente connesso. |
| funzione CUSTOMDATA (DAX) |
Restituisce 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 da una stringa restituita dalla funzione CustomData. Le query possono essere limitate in cui i valori restituiti da LOOKUPVALUE corrispondono ai valori nella stessa tabella o correlata.
Ad esempio, usando questa formula:
='dimDepartment'[DepartmentId]=LOOKUPVALUE('dimEmployees'[DepartmentId], 'dimEmployees'[LoginId], USERNAME(), 'dimEmployees'[LoginId], 'dimDepartment'[DepartmentId])
La funzione LOOKUPVALUE restituisce i valori per la colonna dimEmployees[DepartmentId] in cui dimEmployees[LoginId] è uguale a LoginID dell'utente attualmente connesso, restituito da USERNAME e i valori per dimEmployees[DepartmentId] sono uguali ai valori dimDepartment[DepartmentId]. I valori in DepartmentId restituiti da LOOKUPVALUE vengono quindi usati per limitare le righe sottoposte a query nella tabella dimDepartment ed eventuali tabelle correlate da DepartmentId. Vengono restituite solo le righe in cui DepartmentId sono presenti anche nei valori per departmentId restituiti dalla funzione LOOKUPVALUE.
dimEmployees
| LastName | FirstName | LoginId | DepartmentName | DepartmentId |
|---|---|---|---|---|
| Marrone | Kevin | Adventure-works\kevin0 | Marketing | 7 |
| Bradley | Davide | Adventure-works\david0 | Marketing | 7 |
| Dobney | JoLynn | Adventure-works\JoLynn0 | Produzione | 4 |
| Baretto DeMattos | Paula | Adventure-works\Paula0 | Risorse umane | 2 |
dimDepartment
| DepartmentId | DepartmentName |
|---|---|
| 1 | Corporativo |
| 2 | Generale esecutivo e amministrazione |
| 3 | Gestione inventario |
| 4 | Manifatturiero |
| 5 | Controllo qualità |
| 6 | Ricerca e sviluppo |
| 7 | Vendite e marketing |
Ruoli di test
Quando si crea un progetto di modello in Visual Studio, è possibile usare la funzionalità Analizza in Excel per testare l'efficacia dei ruoli definiti. Dal menu
Ruoli di scripting
I ruoli per i modelli distribuiti e i modelli semantici possono essere inseriti in script usando TMSL (Tabular Model Scripting Language) per creare o modificare l'oggetto Roles . Gli script TMSL possono essere eseguiti in SSMS o con Invoke-ASCmd cmdlet di PowerShell.
Vedere anche
Creare e gestire i ruoli
prospettive
Analizza in Excel
funzione USERNAME (DAX)