Accesso alle risorse

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:

• 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:

• 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.