Nessun risultato. Prova con un altro termine.
Guide
Notizie
Software
Tutorial

Protezione e sicurezza in SQL Server 2005

Le novità di SQL Server 2005 in fatto di protezione
Le novità di SQL Server 2005 in fatto di protezione
Link copiato negli appunti

L'ultima versione di SQL Server introduce parecchie novità. Una delle più importanti è sicuramente la rivisitazione del concetto di protezione. Lo scopo di questo articolo è fare una panoramica delle nuove funzionalità di sicurezza e protezione utili agli sviluppatori.

I legami tra utenti e oggetti del database

Nelle precedenti versioni di SQL Server esisteva un'intima relazione che collegava gli utenti e gli oggetti del database da loro posseduti. Questo implicava che tutti gli oggetti del database di proprietà di un utente dovevano essere eliminati o riassegnati prima di poter rimuovere l'utente dal database.

Con SQL Server 2005, questa relazione non sussiste più perchè gli utenti non sono più proprietari di oggetti. Ciò è reso possibile dall'introduzione di una nuova funzionalità lo: schema. Questa innovazione influenza il modo di richiamare gli oggetti e il modo con cui la protezione viene applicata agli stessi.

Cos'è uno Schema?

Lo schema è uno strumento per raggruppare gli oggetti del database, non gli utenti, così facendo è possibile trattare un set di oggetti come un singolo oggetto. Concedere o negare autorizzazioni a uno schema significa esercitare questa azione indistintamente su tutti gli oggetti in esso contenuti.

Un esempio: se concediamo l'autorizzazione di esecuzione agli oggetti dello schema WebFrontEnd, con una sola istruzione, avremo l'effetto di abilitare tutti gli utenti legati allo schema ad eseguire le procedure memorizzate in esso contenute. Usare gli schemi è vantaggio per diversi motivi:

  1. Semplificano la rimozione degli utenti dal database. Un utente non è più proprietario di oggetti.
  2. Semplificano la gestione della sicurezza. Più utenti possono gestire uno schema e quindi tutti gli oggetti in esso contenuti. Questo implica che possiamo assegnare ad uno o più utenti la possibilità di controllare sottoinsiemi di oggetti del database senza dover polverizzare l'assegnazione delle autorizzazioni.
  3. Facilitano il raggruppamento di oggetti. Per definizione sono contenitori di oggetti.

In SQL Server 2000 si parlava di schema nella misura in cui questo coincideva con l'owner. In SQL Server 2005 lo schema non coincide più con l'owner. Possiamo pensare allo schema come ad un namespace di oggetti del database (identico a quelli delle classi in C# o VB).

Creare uno schema

La creazione di uno schema è un'operazione semplicissima e coinvolge una nuova istruzione DDL, CREATE SCHEMA:

Listato 1. Sintassi T-SQL per creare uno schema

CREATE SCHEMA Vendite

Lo schema Vendite è di proprietà dell'utente che esegue l'istruzione e può essere utilizzato in due modi per la creazione di oggetti: esplicita o implicita. Supponiamo di creare una tabella dal nome Ordine nello schema Vendite:

Listato 2. Sintassi T-SQL per creare una tabella usando il nome schema

CREATE TABLE Vendite.Ordine (Id int, dettaglio varchar(100) )

La stessa tabella può essere creata senza esplicitare lo schema:

Listato 3. Sintassi T-SQL per creare una tabella senza usare il nome schema

CREATE TABLE Ordine (Id int, dettaglio varchar(100) )

In questo caso la tabella Vendite utilizza lo schema predefinito dell'utente che esegue l'istruzione. Un consiglio, per evitare confusione è sempre bene specificare il nome dello schema durante la creazione di un oggetto.

Lo schema sys

Tra le tante novità apportate SQL Server 2005 rivoluziona il repository degli oggetti di sistema, che ora vengono fisicamente archiviati in un database di risorse, anche se a livello logico compaiono nello schema sys presente in tutti i database (sia di tipo utente che di sistema) presenti nell'istanza di SQL Server.

Quindi per scorrere la tabella sysobjects ora dobbiamo fare riferimento a sys.objects (per compatibilità è supportato anche select * from sysobjects) o anche a sys.columns, sys.indexes, ecc... La regola è: un . (punto) dopo il prefisso sys.

Nuove istruzioni DDL per LOGIN e USER

La rivoluzione della sicurezza in SQL Server 2005 coinvolge anche utenti e account di accesso a SQL Server.

CREATE LOGIN

L'accesso a SQL Server viene regolato attraverso le logins. Tramite l'istruzione CREATE LOGIN è possibile creare nuovi accessi che possono essere o integrati con Windows oppure creati su direttamente SQL Server. Nella versione 2005 questa istruzione ha incorporato nuove funzionalità come la gestione dei criteri di policy della password (come scadenza e lunghezza) integrata con Windows Server 2003.

Listato 4. Creare una login su SQL Server con verifica policy password

CREATE LOGIN luca
  WITH password='segreto!2',
  DEFAULT_DATABASE=HTML,
  CHECK_POLICY=ON,
  CHECK_EXPIRATION=ON

CREATE USER

Dopo aver creato una login è possibile avviare la creazione di utenti per i vari database di SQL Server. A questi utenti viene assegnato uno schema predefinito di accesso, nel caso fosse assegnato alcuno schema, quello predefinito diventa dbo (anche per compatibilità con la precedente versione di SQL Server).

Listato 5. Creare un utente per un database di SQL Server

Use Html
GO
CREATE USER sviluppatore
  FOR LOGIN luca
  WITH DEFAULT_SCHEMA = Vendite

Accesso agli oggetti

L'avvento degli schemi in SQL Server ha cambiato la modalità di accesso agli oggetti del database. Un utente può avere accesso a più oggetti presenti anche in più schemi. Nel richiamare un oggetto l'utente non è obbligato a indicare il nome dello schema, ma in questo caso SQL Server segue il ragionamento:

  1. l'oggetto esiste nello schema sys? se sì ok, altrimenti:
  2. l'oggetto esiste nello schema predefinito per l'utente? se sì ok, altrimenti:
  3. l'oggetto esiste nello schema dbo? se sì ok, altrimenti:

Se non si specifica alcuno schema le regole sono queste. La cosa migliore rimane sempre una sintassi esplicita nel riferimento all'oggetto.

Gestire le autorizzazioni

Il nuovo modo di concepire oggetti, schemi e utenti facilita enormemente la gestione delle autorizzazioni. Rispetto a SQL Server 2000 la differenza è abissale. Prima per usare un oggetto un utente doveva possederlo ed avere i giusti diritti su di esso. Adesso invece è possibile assegnare l'autorizzazione direttamente allo schema (che è poi il contenitore degli oggetti).

Listato 6. Assegnare l'autorizzazione SELECT ed EXECUTE su tutti gli oggetti dello schema Vendite

GRANT SELECT,EXECUTE ON Schema::Vendite TO sviluppatore

La concessione delle autorizzazioni a livello di schema è estesa anche ai ruoli del database ma non solo, in modo granulare SQL Server permette di controllare parecchi eventi a livello server: ALTER ANY LOGIN, ALTER ANY http ENDPOINT, CREATE DDL EVENT, ecc...

Cambiare il contesto di sicurezza

Altra innovazione è la possibilità di cambiare il contesto di sicurezza all'interno del quale una routine viene eseguita (valido per UDF e Stored Procedures). Questa possibilità è molto interessante per lo sviluppatore, perchè in SQL Server 2005 il concetto di catena di proprietà è cambiato e non viene più applicato al possessore degli oggetti come in SQL Server 2000 ma bensì allo schema a cui gli oggetti appartengono. L'introduzione della clausola in forma EXECUTE AS 'utente' permette di evitare l'interruzione della catena di proprietà all'interno delle routines.

La clausola EXECUTE può essere utilizzata in diversi modi:

  1. EXECUTE AS CALLER.

    La routine viene eseguita nel contesto dell'utente che l'ha chiamata. Questo comportamento è identico a quello di SQL Server 2000 e quindi la dicitura AS CALLER può essere tranquillamente omessa.
  2. EXECUTE AS 'Utente'.

    La routine viene eseguita nel contesto dell'utente specificato dopo la parole chiave AS. Tutto il codice all'interno della UDF o della stored procedure verrà eseguito nel contesto di protezione dell'utente specificato.
  3. EXECUTE AS SELF.

    Simile alla precedente. L'utente impersonato è quello che esegue l'istruzione.

Crittografia dei dati

Ultimo, ma non per questo meno importante, è l'introduzione di meccanismi di crittografia in SQL Server 2005 quali:

  1. Certificati
  2. Chiavi asimmetriche
  3. Chiavi simmetriche

Ora la sicurezza dei dati memorizzati su SQL Server può essere garantita da strumenti per la crittografia gestiti dal server stesso, è possibile utilizzare questi meccanismi per crittografare quel che si vuole (non un intero database però!), in particolare dati sensibili: password, numeri di telefono, carte di credito. Tutto il necessario alla generazione delle chiavi, dei certificati digitali e quant'altro è incorporato in SQL Server, che offre inoltre una vasta gamma di funzioni per far scadere le password e costringere gli utenti a mettere password più sicure. Crittografia e certificati possono anche abilitare l'esecuzione di stored procedure o altri oggetti solo ad utenti in grado di fornire un certificato o una password specifica.

Conclusione

In questo articolo abbiamo fatto una panoramica sulle nuove funzionalità di protezione di SQL Server 2005, con un occhio di riguardo al concetto di schema. Abbiamo inoltre passato in rassegna le istruzioni DDL per la sicurezza, la gestione delle autorizzazioni concludendo con un breve cenno ai meccanismi di crittografia.


Ti consigliamo anche