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:

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.