L'accesso alle risorse
Il completamento della fase di autenticazione da parte di un utente non
comporta automaticamente l'accesso a tutti i database di SQL Server 2000 e,
soprattutto, non implica che egli possa avere accesso a tutti gli oggetti anche
all'interno di uno stesso database.
Infatti, come già anticipato, l'uso degli
oggetti dal database da parte dei vari utenti è regolamentato attraverso le cd.
autorizzazioni che, generalmente, vengono espresse e concesse sotto forma di
ruoli e permessi.
I ruoli
Il concetto di ruolo è molto simile, per non dire identico, a quello di
gruppo di utenti del sistema operativo. In tale contesto un ruolo non è altro
che un astrazione concettuale utilizzata per raggruppare un insieme di utenti
all'interno di una stessa unità logica alla quale possono essere poi conferiti o
negati determinati privilegi. I ruoli rappresentano dunque una facilitazione
volta a snellire il tedioso processo di 'amministrazione dei permessi a livello
di database. SQL Server 2000 prevede una serie di ruoli differenti:
- public role: questo ruolo possiede i permessi di default
per gli utenti di un database, esiste in ogni database di SQL Server compresi
quelli di sistema (master, msdb, tempdb e model) e non può essere eliminato; - fixed server roles: sono ruoli predefiniti che hanno una
valenza globale e pertanto esistono al di fuori del contesto dei singoli
database. Di regola essi vengono associati ai login in modo da garantire a
questi ultimi i permessi amministrativi che essi implicano. Questi ruoli non
possono essere concessi singolarmente agli account utente, non sono modificabili
e non è possibile crearne altri dello stesso tipo. La tabella seguente riporta
una lista di questi ruoli insieme con l'indicazione delle loro caratteristiche:
|
Ruolo
|
Descrizione
|
| sysadmin | E' in grado di compiere qualsiasi attività. |
| serveradmin | Amministra le opzioni di configurazione del server e può eseguire lo shutdown dello stesso. |
| setupadmin | Gestisce ed amministra i server collegati e le procedure di startup. |
| securityadmin | Gestisce le impostazioni di sicurezza a livello di server, inclusi quelli collegati, e possiede il permesso CREATE DATABASE. Inoltre è in grado di eseguire il reset delle password per i login di autenticazione. |
| processadmin | E' in grado di terminare i processi di SQL Server. |
| dbcreator | Può creare, modificare e ripristinare qualsiasi database di SQL Server. |
| diskadmin | Gestisce i file sul disco. |
| bulkadmin | Permette agli utenti diversi dagli amministratori di sistema di eseguire le istruzioni bulkadmin. |
- fixed database roles: anche questi sono ruoli predefiniti
esistenti tuttavia nel contesto dei singoli database. Generalmente essi vengono
concessi agli account utente ma i relativi permessi non possono essere
modificati in alcun modo. La tabella seguente riporta una lista di questi ruoli
insieme con l'indicazione delle loro caratteristiche:
|
Ruolo
|
Descrizione
|
| db_owner | Esegue tutte le attività di manutenzione e configurazione del database. |
| db_accessadmin | Aggiunge o rimuove le autorizzazioni di accesso per gli utenti ed i gruppi del sistema operativo e per i login di SQL Server. |
| db_datareader | E' in grado di leggere i dati da tutte le tabelle degli utenti. |
| db_datawriter | E' in grado di aggiungere, cancellare e modificare i dati in tutte le tabelle degli utenti. |
| db_ddladmin | Può eseguire qualsiasi comando DDL (Data Definition Language) in un database. |
| db_securityadmin | Modifica l'appartenenza ai ruoli e gestisce i permessi. |
| db_backupoperator | Esegue il backup del database. |
| db_denydatareader | E' un ruolo di tipo restrittivo nel senso che esso non può leggere i dati di qualsiasi tabella degli utenti del database. |
| db_denydatawriter | Anche questo è un ruolo di tipo restrittivo nel senso che non può aggiungere, modificare o cancellare dati in nessuna delle tabelle degli utenti del database. |
- user defined database roles: si tratta di ruoli che possono
essere creati ex-novo a livello di singolo database per raggruppare una serie di
permessi che caratterizzano l'attività di un gruppo di utenti; - application roles: consentono di restringere l'accesso ai
dati sulla base dell'applicazione che ogni singolo utente sta usando in un
determinato momento. In sostanza tali ruoli permettono di delegare
all'applicazione la responsabilità dell'autenticazione dell'utente. Infatti
tutto ciò che l'amministratore deve fare è creare il ruolo applicativo ed
assegnare allo stesso i singoli permessi che lo caratterizzano mentre sarà
l'applicazione utilizzata sul lato client a dover attivare a run-time il ruolo
attraverso l'invocazione di una procedura registrata
(sp_setapprole) così da ottenere tutti i permessi
precedentemente associati al ruolo in fase di creazione. I ruoli applicativi
possiedono le seguenti caratteristiche:
- a causa del meccanismo dinamico con il quale vengono attivati questi ruoli non possono essere attribuiti ai singoli utenti;
- essi prevalgono sui permessi standard nel senso che, per effetto della loro attivazione, l'applicazione perde tutti gli altri permessi normalmente associati con il login/utente adoperato durante la connessione al server;
- essi esistono soltanto nel contesto di un singolo database per cui se l'applicazione deve iniziare una transazione che interessa un altro database occorre che in quest'ultimo sia attivato un account utente di tipo guest e che esso abbia le necessarie autorizzazioni per la lettura/scrittura di dati;
- gli utenti che utilizzano i ruolo applicativi sono soggetti ad attività di auditing all'interno del database;
I permessi
I permessi possono essere concessi ad utenti e ruoli del database oppure ad
utenti/gruppi del sistema operativo ma mai direttamente a login di SQL Server.
Attraverso i permessi vengono specificate le istruzioni ed i comandi sql che un
utente può eseguire nonchè le modalità con le quali egli può avere accesso agli
oggetti del database.
A seconda del contesto i permessi possono essere di
tipo grant, revoke e deny: un
permesso di tipo grant assume il valore di concessione positiva
mentre revoke e deny hanno valore di
restrizioni.
È comunque importante sottolineare la differenza fondamentale
che intercorre tra revoke e deny: l'effetto di
quest'ultimo è quello di negare (nel senso di annullare) l'esecuzione di
istruzioni o l'accesso ad oggetti anche quando esiste una grant
dal momento che esso viene considerato sempre per primo. Al contrario
l'istruzione revoke produce come effetto l'inefficacia di una
precedente grant o deny.
