Con l’articolo di oggi vogliamo dare una panoramica sui nuovi ruoli a livello server (server-level roles) introdotti a partire dal SQL Server 2022.
Ruoli server antecedenti SQL Server 2022
In SQL Server, i fixed server roles sono ruoli predefiniti a livello di server che consentono di gestire autorizzazioni specifiche senza doverle configurare manualmente per ogni utente o login. Si possono immaginare come macro-contenitori di permessi per autorizzare gli utenti ad operare su istanza e database in base al proprio ruolo.
Questi ruoli forniscono un controllo granulare su attività amministrative e di gestione e sono assegnabili ai login che accedono al server SQL.
I ruoli esistenti fino alla versione 2022 sono:
Fixed server roles | Descrizione |
sysadmin | Accesso totale al server, con capacità di eseguire qualsiasi attività. |
serveradmin | Permette di configurare e gestire il server, come impostazioni e configurazioni e procedere con la shutdown. |
securityadmin | Gestisce login, autorizzazioni e ruoli a livello di server. |
processadmin | Permette di gestire i processi in esecuzione. |
setupadmin | Consente la gestione dei linked server e la configurazione delle procedure di avvio. |
bulkadmin | Autorizza l'esecuzione di operazioni di bulk insert (inserimenti massivi). |
diskadmin | Gestisce i dischi utilizzati da SQL Server. |
dbcreator | Consente la creazione, modifica e cancellazione di database. |
Ruoli server introdotti da SQL Server 2022
I nuovi ruoli introdotti dalla versione 16, ovvero SQL Server 2022, sono 10 e sono facilmente riconoscibili dai loro predecessori perché definiti con il prefisso “##MS_” e il suffisso “##”.
I nuovi ruoli attualmente sono complementari a quelli esistenti e non li sostituiscono.
Il nuovo design nasce specificamente per rispettare i dettami di sicurezza denominato “Il Principio del Minimo Privilegio” (POLP - Principle of least privilege in inglese) e quindi concedere il minimo set di permessi necessari allo scopo per cui quell’account è stato creato.
I nuovi ruoli sono:
Fixed server roles | Descrizione |
##MS_DatabaseConnector## | I membri possono connettersi a qualsiasi database senza la necessità di avere un user-account nel database. |
##MS_LoginManager## | I membri possono creare, modificare ed eliminare i login. A differenza di securityadmin però non ha potere di garantire nessun tipo di grant. |
##MS_DatabaseManager## | I membri possono creare ed eliminare database e possono diventare owner degli stessi connettendosi come dbo. Il ruolo è paritetico a dbcreator. |
##MS_ServerStateReader## | I membri possono leggere tutti le viste dinamiche di management (DMV’s) e funzioni coperte da VIEW SERVER STATE e di conseguenza di VIEW DATABASE STATE nel momento in cui il membro di questo ruolo ne possiede un user account. |
##MS_ServerStateManager## | I membri hanno gli stessi permessi di ##MS_ServerStateReader## con l’aggiunta di ALTER SERVER STATE che permette diverse manutenzioni come DBCC FREEPROCCACHE, DBCC FREESYSTEMCACHE ('ALL'), DBCC SQLPERF(). |
##MS_ServerPerformanceStateReader## | I membri possono leggere tutti le viste dinamiche di management (DMV’s) e funzioni coperte da VIEW SERVER PERFORMANCE STATE e di conseguenza di VIEW DATABASE PERFORMANCE STATE nel momento in cui il membro di questo ruolo ne possiede un user account. Di fatto è un sotto insieme di ##MS_ServerStateReader##. |
##MS_ServerSecurityStateReader## | I membri possono leggere tutti le viste dinamiche di management (DMV’s) e funzioni coperte da VIEW SERVER SECURITY STATE e di conseguenza di VIEW DATABASE SECURITY STATE nel momento in cui il membro di questo ruolo ne possiede un user account. Di fatto è un sotto insieme di ##MS_ServerStateReader##. |
##MS_DefinitionReader## | I membri possono leggere tutti le viste di catalogo comprese da VIEW ANY DEFINITION e di conseguenza di VIEW SECURITY DEFINITION nel momento in cui il membro di questo ruolo ne possiede un user account. |
##MS_PerformanceDefinitionReader## | I membri possono leggere tutti le viste dinamiche di management (DMV’s) e funzioni coperte da VIEW ANY SERVER PERFORMANCE DEFINITION e di conseguenza di VIEW DEFINITION nel momento in cui il membro di questo ruolo ne possiede un user account. Di fatto è un sotto insieme di ##MS_ DefinitionReader ##. |
##MS_SecurityDefinitionReader## | I membri possono leggere tutti le viste di catalogo coperte da VIEW ANY SECURITY DEFINITION e di conseguenza di VIEW SECURITY DEFINITION nel momento in cui il membro di questo ruolo ne possiede un user account. |
Le autorizzazioni dei nuovi ruoli “reader” possono propagarsi come descritto a livello database.
Affinché ciò accada però è necessario:
- Abbinare login e utenza database presente sull’istanza
- Concedere al login anche il ruolo ##MS_DatabaseConnector## che, come detto, permette la connessione a qualsiasi DB anche senza averne l’utenza abbinata.
I nuovi ruoli hanno in dettaglio i seguenti permessi:
Fixed server-level role | Server-level permissions | Database-level permissions |
##MS_DatabaseConnector## | CONNECT ANY DATABASE | CONNECT |
##MS_LoginManager## | CREATE LOGIN ALTER ANY LOGIN | N/A |
##MS_DatabaseManager## | CREATE ANY DATABASE ALTER ANY DATABASE | ALTER |
##MS_ServerStateManager## | ALTER SERVER STATE VIEW SERVER STATE VIEW SERVER PERFORMANCE STATE VIEW SERVER SECURITY STATE | VIEW DATABASE STATE VIEW DATABASE PERFORMANCE STATE VIEW DATABASE SECURITY STATE |
##MS_ServerStateReader## | VIEW SERVER STATE VIEW SERVER PERFORMANCE STATE VIEW SERVER SECURITY STATE | VIEW DATABASE STATE VIEW DATABASE PERFORMANCE STATE VIEW DATABASE SECURITY STATE |
##MS_ServerPerformanceStateReader## | VIEW SERVER PERFORMANCE STATE | VIEW DATABASE PERFORMANCE STATE |
##MS_ServerSecurityStateReader## | VIEW SERVER SECURITY STATE | VIEW DATABASE SECURITY STATE |
##MS_DefinitionReader## | VIEW ANY DATABASE VIEW ANY DEFINITION VIEW ANY PERFORMANCE DEFINITION VIEW ANY SECURITY DEFINITION | VIEW DEFINITION VIEW PERFORMANCE DEFINITION VIEW SECURITY DEFINITION |
##MS_PerformanceDefinitionReader## | VIEW ANY PERFORMANCE DEFINITION | VIEW PERFORMANCE DEFINITION |
##MS_SecurityDefinitionReader## | VIEW ANY SECURITY DEFINITION | VIEW SECURITY DEFINITION |
FOCUS 1: la scalabilità dei permessi
Come abbiamo visto i ruoli “reader” hanno l’interessante caratteristica di dividere l’accesso tra oggetti a livello server e quelli a livello database.
È necessario mappare il login (server) ad un utente del database appunto per garantire a sua volta l’accesso agli oggetti del DB specifico!
Per comprendere meglio il concetto facciamo un esempio.
Immaginiamo di creare la SQL login “foo” e di assegnare ad essa il ruolo “##MS_ServerStateReader##”
Eseguendo la query sulla vista sys.databases otteniamo correttamente la lista dei database presenti sull’istanza. Questo è possibile perché nel ruolo ##MS_ServerStateReader## è compreso l’accesso alla vista.
La stessa operazione fallisce però se proviamo a leggere la vista “sys_dabase_files” del database “test“, questo perché la login non ha nessun utente mappato a DB in accordo con quanto detto prima.
Andiamo quindi a mappare il login “foo” al database “test” creandone lo user.
Post modifica la query funziona come da manuale.
Ricordo che se vogliamo garantire automaticamente l’accesso a tutti gli oggetti di tutti i database è possibile evitare di aggiungere un user database per database assegnando al login anche il ruolo di ##MS_DatabaseConnector##.
FOCUS 2: il caso particolare di ##MS_LoginManager## Role vs. securityadmin
Un altro caso degno di nota e che mostra come Microsoft ha ristrutturato i ruoli con in mente POLP è nel confronto tra securityadmin e ##MS_LoginManager##.
Come riportato da Microsoft in questo articolo, è rimarcato che un login con ruolo securityadmin ha il permesso di garantire la gran parte dei permessi e quindi si suggerisce si considerare il ruolo al pari di sysadmin (es. può resettare la password di un login sysadmin per esempio).
Come specificato invece ##MS_LoginManager## ha la sola possibilità di creare, modificare o eliminare un login senza però scendere poter assegnare specifici permessi o ruoli.
È possibile immaginare questo ruolo come uno strato intermedio tra la figura che crea i login e quella che definisce i poteri che prima mancava.
Scendendo nello specifico ##MS_LoginManager## a differenza di securityadmin non può dare:
- grant “Create database” ad altri login
- grant “Backup database” ad altri login
- grant “View Definitions” ad altri login
- grant o deny windows login
- leggere il log degli errori
creando una forte separazione dei ruoli rispetto al passato.
Conclusioni
I nuovi ruoli introdotti da Microsoft sono sicuramente interessanti, ma è anche vero che in organizzazioni non particolarmente strutturate possono risultare poco utili (specialmente dove fondamentalmente esistono due figure, utenti base ed admin).
Di sicuro interesse come abbiamo visto il ruolo ##MS_LoginManager## che è qualcosa di nuovo rispetto al passato. Non ci resta che scoprire se Microsoft proseguirà questo percorso con la nuova release (SQL Server 2025).
Fonti:
https://www.mssqltips.com/sqlservertip/7356/sql-server-msloginmanager-vs-securityadmin-role/
di Riccardo Trattenero, pubblicato il 16 luglio 2025