MSDN Authoring Template

Funzionalità di protezione di Microsoft
SQL Server 2000
Autori: Richard Waymire e Ben Thomas
Abstract: questo documento presenta ad amministratori e sviluppatori di Microsoft ®
SQL Server™ le nuove funzionalità di protezione di SQL Server 2000. Oltre a
introdurre le nuove caratteristiche, vengono illustrate in dettaglio le migliori modalità
di implementazione della sicurezza in domini Microsoft Windows®, con il supporto di
esempi di codice sorgente.
Le informazioni contenute in questo documento rappresentano l’attuale posizione
di Microsoft Corporation nei confronti dei problemi discussi al momento della
pubblicazione del documento. Per la necessità da parte di Microsoft di rispondere
alle mutevoli condizioni del mercato, le informazioni fornite non impegnano in alcun
modo Microsoft, che non garantisce l’accuratezza delle informazioni presentate dopo
la data di pubblicazione.
Questo documento è esclusivamente per scopi informativi. MICROSOFT ESCLUDE
OGNI GARANZIA ESPRESSA O IMPLICITA IN QUESTO DOCUMENTO.
Il rispetto di tutte le leggi in vigore in materia di copyright è responsabilità esclusiva
dell’utente. Senza alcun limite per i diritti coperti da copyright, nessuna parte di
questo documento può essere riprodotta in qualsiasi forma o mezzo elettronico o
meccanico, per alcun uso, senza il permesso scritto di Microsoft Corporation.
Microsoft può essere titolare di brevetti, domande di brevetto, marchi, copyright o
altri diritti di proprietà intellettuale relativi all’oggetto del presente documento. Salvo
quanto espressamente previsto in un contratto scritto di licenza Microsoft, la
consegna del presente documento non implica la concessione di alcuna licenza su tali
brevetti, marchi, copyright o altra proprietà intellettuale.
©
2000 Microsoft Corporation. Tutti i diritti riservati.
Active Directory, Microsoft, Microsoft Press, MDSN, Visual Basic, Visual C++, Win32,
Windows, Windows 2000, Windows Me e Windows NT sono marchi o marchi registrati
di Microsoft Corporation negli Stati Uniti e/o negli altri paesi.
Altri nomi di prodotti e società citati nel presente documento possono essere marchi
dei rispettivi proprietari.
Microsoft è un marchio registrato di Microsoft Corporation negli Stati Uniti e/o negli
altri paesi.
Gli altri marchi e nomi commerciali menzionali del presente documento appartengono
ai rispettivi proprietari.
Sommario
Funzionalità di protezione di Microsoft SQL Server 2000
Introduzione
Presupposti
Nuove funzionalità di protezione di SQL Server 2000
Installazione protetta
Completamento della valutazione per la certificazione di sicurezza C2
Autenticazione Kerberos e delega in ambiente Windows 2000
Controllo della sicurezza
Controlli previsti dallo standard C2
Eliminazione dell’account delegato SQLAgentCmdExec
Miglioramento dei ruoli del server
Crittografia
Crittografia di rete con SSL/TLS
Supporto per la crittografia del file system in Windows 2000
Crittografia avanzata basata sul server
Crittografia dei pacchetti DTS
Protezione tramite password
Backup e gruppi di supporti di backup
SQL Server Enterprise Manager
Modifica dell’account del servizio con SQL Server Enterprise Manager
Eliminazione della colonna SUID in tutte le tabelle di sistema
Modello di protezione di SQL Server 2000
Modalità di autenticazione
Utilizzo interno degli identificativi di protezione (SID)
Ruoli
Ruolo public
Ruoli predefiniti
Ruoli definiti dall’utente
Ruoli applicazione
Protezione dell’accesso al server
Protezione dell’accesso ai database
Ruoli del database definiti dall’utente
Sistema di autorizzazioni
Concessione e negazione delle autorizzazioni a utenti e ruoli
Catene di proprietà
Implementazione della protezione a livello di server
Utilizzo di identificatori di protezione (SID)
Eliminazione dei SUID (Server User ID)
Generazione di GUID per utenti non trusted
Ridenominazione di account di Windows relativi a utenti o gruppi
Tabella di sistema sysxlogins
1
3
4
5
5
6
6
7
8
8
9
9
9
10
10
11
11
11
11
11
12
13
15
16
16
16
17
19
19
22
26
27
29
30
32
34
34
34
35
35
36
i
Implementazione della protezione a livello di oggetto
Controllo delle autorizzazioni
Costo della modifica delle autorizzazioni
Ridenominazione di account di Windows relativi a utenti o gruppi
Rimozione della tabella di sistema sysprocedures
Opzione WITH GRANT
Tabella di sistema sysusers
Tabella di sistema sysmembers
Tabella di sistema syspermissions
Tabella di sistema sysprotects
Autorizzazioni Named Pipes e Multiprotocol
Aggiornamento da SQL Server 7.0
Aggiornamento da SQL Server 6.5
Processo di aggiornamento
Analisi dell’output del processo di aggiornamento
Preparazione dell’ambiente di protezione di SQL Server 6.5
Protezione dell’installazione di SQL Server 2000
Account di servizio
File system
Registro di sistema
Controllo
Profiling per il controllo
Backup e ripristino
Protezione di file e supporti di backup
Ripristino in un altro server
Autenticazione di Windows (ripristino all’interno dello stesso dominio)
Autenticazione di Windows (ripristino all’interno di un altro dominio)
Connessione e disconnessione di file di database
Configurazione generali della protezione di Windows
Conclusioni
Appendice A: Ulteriori informazioni
39
39
40
40
41
41
42
42
43
43
44
45
45
45
46
47
49
50
52
52
53
53
54
54
54
55
55
56
56
57
58
ii
Introduzione
Questo documento presenta ad amministratori e sviluppatori di Microsoft ® SQL Server™
le nuove funzionalità di protezione di SQL Server 2000. Oltre a introdurre le nuove
caratteristiche, sono discusse in dettaglio le migliori modalità di implementazione della
sicurezza in domini Microsoft Windows®, con il supporto di esempi di codice sorgente.
Poiché non è tuttavia prevista una descrizione dettagliata dell’interfaccia utente,
l’implementazione della sicurezza da questo punto di vista non rientra nello scopo
del presente documento.
Per gli utenti che desiderano eseguire l’aggiornamento di server da SQL Server
versione 7.0 o precedente, vengono fornite informazioni relative all’aggiornamento
della protezione, oltre a note relative alle modalità di gestione della protezione in
SQL Server 6.5 e versioni precedenti.
Anche se molti sviluppatori e amministratori hanno implementato un’architettura di
protezione già in SQL Server 7.0 e versioni precedenti, i più esperti in questo campo
erano consapevoli del fatto che i miglioramenti a livello di sicurezza avrebbero potuto
essere applicati solo come patch finché non fosse stata possibile un’integrazione più
completa. SQL Server 2000 parte dalle funzionalità di protezione di SQL Server 7.0
per fornire una soluzione di sicurezza più efficace di quella offerta con SQL Server 6.5
e versioni precedenti.
3
Presupposti
Il sistema di sicurezza di Microsoft SQL Server 2000 si basa sul modello di protezione
di Microsoft Windows NT® 4.0 e Windows 2000; il presente documento presuppone
quindi una buona conoscenza dell’architettura di protezione di questi due sistemi
operativi, oltre a una discreta familiarità con i concetti di dominio, gruppo globale
e account utente nel contesto di protezione di Windows NT 4.0, nonché nell’ambito
di Microsoft Active Directory™ in Windows 2000.
La conoscenza del sistema di sicurezza di SQL Server 6.x, anche se utile, non è
necessaria per la comprensione della maggior parte delle informazioni contenute
in questo documento, a eccezione della sezione “Aggiornamento da SQL Server 6.5”,
che illustra come in SQL Server 2000 siano stati eliminati i problemi di protezione
di SQL Server 6.5.
Per una comprensione approfondita dei concetti espressi nella sezione “Utilizzo interno
degli identificativi di protezione (SID)”, è necessario possedere una discreta conoscenza
delle tabelle di sistema di SQL Server 7.0 e versioni precedenti.
Per gli utenti interessati, vengono forniti alcuni esempi di codice Microsoft Visual Basic
e SQL (Structured Query Language) che favoriscono la comprensione dell’argomento.
Anche l’eventuale esperienza maturata nell’utilizzo del modello di oggetti SQL-DMO
(Distributed Management Objects) costituisce un vantaggio significativo, sebbene
anche gli utenti con una conoscenza limitata di Windows NT 4.0, Windows 2000 o SQL
Server potranno ottenere informazioni utili sui meccanismi di sicurezza di questi
prodotti. Tali informazioni sono concentrate soprattutto nelle sezioni “Nuove funzionalità
di protezione di SQL Server 2000” e “Modello di protezione di SQL Server 2000”.
4
Nuove funzionalità di protezione
di SQL Server 2000
Nella prima parte di questo documento vengono esaminate le funzionalità di protezione
di SQL Server 2000 e viene fornita una panoramica dei miglioramenti in termini di
sicurezza apportati a questa versione.
Installazione protetta
In SQL Server 2000 la sicurezza è integrata fin dal momento dell’installazione.
Quando si esegue il programma di installazione di qualsiasi versione di SQL Server
(ad eccezione di Microsoft SQL Server Desktop Engine), viene visualizzata la finestra
di dialogo illustrata nella figura 1.
Figura 1: durante l’installazione di SQL Server 2000, nella finestra per la scelta della modalità
di autenticazione è selezionata per impostazione predefinita l’autenticazione di Windows.
Questa finestra consente di selezionare la modalità di autenticazione per SQL Server
2000.1 Per impostazione predefinita è impostata l’autenticazione di Windows, che
è più sicura della modalità mista. Se si sceglie la modalità mista, è necessario
impostare la password di accesso a SQL Server per l’amministratore di sistema (sa).
È anche possibile impostare l’autenticazione senza password, ma non è consigliabile
perché rende il sistema vulnerabile a eventuali attacchi.
Nota: in SQL Server versione 7.0 e versioni precedenti, per impostazione predefinita
veniva utilizzata la modalità di autenticazione mista e senza password sa.
Per informazioni sulle modalità di protezione disponibili, vedere la sezione
del presente documento dedicata alle modalità di autenticazione.
1
5
Quando si installa SQL Server in un computer Windows NT 4.0 o Windows 2000
che utilizza il file system NTFS, le directory di destinazione dell’installazione vengono
protette in modo da limitare l’accesso ai soli account impostati per i servizi di SQL
Server e al gruppo di amministratori predefinito. Per impostazione predefinita,
l’applicazione viene installata nella directory C:\Programmi\Microsoft SQL
Server\MSSql. Durante installazione di SQL Server vengono protette in questo modo
anche le chiavi di registro di SQL Server, HKLM\Software\Microsoft\MSSQLServer
o HKLM\Software\Microsoft\Microsoft SQL Server\MSSQL$NomeIstanza, per le istanze
denominate, e le relative sottochiavi.
Installazione di Microsoft SQL Server 2000 Desktop Engine
Per impostazione predefinita nei sistemi operativi Windows NT 4.0 e Windows 2000
il programma di installazione di Microsoft SQL Server 2000 Desktop Engine utilizza
la modalità di autenticazione di Windows, mentre nei sistemi operativi Windows 98
e Windows Millennium (Windows ME), dove questo tipo di autenticazione non è
disponibile, viene utilizzata la modalità mista. Per specificare la modalità mista come
opzione di installazione predefinita, è necessario utilizzare l’opzione
SECURITYMODE=SQL quando si esegue l’installazione dalla riga di comando o nel file
INI, secondo quanto documentato nella sezione della documentazione in linea di SQL
Server 2000 dedicata all’installazione di SQL Server 2000 Desktop Engine.
Secondo quanto riportato nel file readme.txt di SQL Server 2000, nelle sezioni della
documentazione in linea dedicate all’installazione di SQL Server 2000 Desktop Engine
e all’integrazione di quest’ultimo in Windows Installer sono documentati due parametri
che vengono ignorati dalla versione finale del programma di installazione di Desktop
Engine: USEDEFAULTSAPWD e SAPASSWORD.
Pertanto, in un’installazione di Desktop Engine configurata per l’autenticazione
in modalità mista la password sa è sempre assente e deve essere impostata
immediatamente al termine dell’installazione.
Completamento della valutazione
per la certificazione di sicurezza C2
La valutazione di SQL Server 2000 è stata completata e, con la configurazione
esaminata dal Governo degli Stati Uniti, l’applicazione è risultata conforme ai requisiti
per la certificazione di sicurezza C2. Per informazioni sulla configurazione da adottare
per ottenere un sistema conforme allo standard C2, visitare il sito
www.microsoft.com/technet/treeview/default.asp?url=/technet/security/news/c2eval.asp.
All’indirizzo www.radium.ncsc.mil/tpep/epl/entries/TTAP-CSC-EPL-00-001.html
è invece disponibile un annuncio sulla certificazione C2.
Autenticazione Kerberos e delega
in ambiente Windows 2000
Kerberos è il principale meccanismo di autenticazione utilizzato nelle reti Windows
2000. La delega consente invece di trasmettere attraverso più computer e applicazioni
le credenziali di protezione dell’utente, che vengono mantenute a ogni “hop” da un
computer all’altro. SQL Server 2000 include il supporto completo per Kerberos,
compresa la capacità di accettare ticket Kerberos delegati, nonché di delegare tali
ticket (in ambiente Microsoft Windows 2000) attraverso i domain controller Windows
2000 e Active Directory. Tutto questo influisce sul funzionamento delle stored
procedure remote e delle query distribuite.
6
Per ulteriori informazioni su Kerberos e sulla protezione di Windows 2000, visitare
il sito www.microsoft.com/italy/windows2000/technologies/security/default.asp
e leggere i documenti tecnici dedicati a tali argomenti.
Per configurare la delega, è necessario che tutti i server con i quali viene stabilita
la connessione eseguano Microsoft Windows 2000 con il supporto Kerberos attivato
e utilizzino Active Directory.
Per utilizzare la delega, è necessario impostare le seguenti opzioni in Active Directory:

L’account è sensibile e non può essere delegato. Non selezionare questa
opzione per l’utente che richiede la delega.

L’account è trusted per delega. Selezionare questa opzione per l’account
di servizio di SQL Server.

Il computer è trusted per delega. Selezionare questa opzione per il server
che esegue l’istanza di Microsoft SQL Server.
Affinché sia possibile eseguire la delega degli account di protezione, l’amministratore
del dominio dell’account di Windows 2000 deve assegnare a SQL Server un nome
principale di servizio (SPN). Il nome SPN deve essere assegnato all’account del servizio
di SQL Server nel computer utilizzato. La delega esegue l’autenticazione reciproca e il
nome SPN garantisce che SQL Server è stato verificato nel server specifico, all’indirizzo
socket specifico, da parte dell’amministratore del dominio dell’account di Windows
2000. Il nome SPN per SQL Server può essere definito dall’amministratore del dominio.
Per ulteriori informazioni sull’utilità setspn, vedere
il Resource Kit di Windows 2000.
Per creare un nome SPN per SQL Server 2000
Immettere il seguente comando:
setspn -A MSSQLSvc/Host:porta accountservizio
Ad esempio:
setspn -A MSSQLSvc/server1.redmond.microsoft.com accountsql
Per il corretto funzionamento della delega, è necessario utilizzare la libreria di rete
TCP/IP Sockets. Non è possibile utilizzare la libreria Named Pipes, poiché il nome SPN
fa riferimento a un particolare socket TCP/IP. Se vengono utilizzate più porte, è
necessario impostare un nome SPN per ogni porta.
È possibile attivare la delega anche nell’ambito dell’account LocalSystem. SQL Server
2000 si registra automaticamente all’avvio del servizio, registrando automaticamente
anche il nome SPN. Questo metodo è più semplice rispetto all’attivazione della delega
tramite un account utente di dominio. Se tuttavia SQL Server 2000 viene arrestato,
la registrazione dei nomi SPN per l’account LocalSystem viene annullata.
Controllo della sicurezza
La disponibilità di una funzione di controllo della sicurezza è uno dei requisiti imposti
dal Governo degli Stati Uniti per la certificazione C2. In SQL Server 2000 è integrato un
meccanismo di controllo dotato di funzionalità complete, costituito da più componenti
che verranno descritti di seguito. Insieme, questi componenti consentono di tenere
traccia di qualsiasi utilizzo delle autorizzazioni effettuato nell’ambito di SQL Server 2000.
7
SQL Trace
SQL Trace è il nome attribuito ai componenti lato server del meccanismo di controllo.
Le funzioni di controllo sono state aggiunte allo stesso meccanismo utilizzato in SQL
Server 7.0 per ottenere informazioni sulle prestazioni di SQL Server. Le informazioni
sulle prestazioni vengono fornite anche nella nuova versione, oltre alle informazioni di
controllo, anche se in SQL Server 2000 l’interfaccia è stata completamente ridisegnata
e tutte le stored procedure estese di SQL Server 7.0 sono state sostituite.
Per informazioni sulle nuove stored procedure utilizzate per il controllo della sicurezza,
fare riferimento alla documentazione in linea di SQL Server 2000.
Ogni volta che nel motore relazionale o di archiviazione di SQL Server si verifica
un evento di sicurezza da controllare, viene inviata una notifica al motore di gestione
degli eventi (SQL Trace) e, se la traccia per l’acquisizione dell’evento generato
è attivata e in esecuzione, tale evento viene scritto nel file di traccia appropriato.
Per informazioni sull’attivazione della funzione di traccia per i normali controlli di
sicurezza e per i controlli richiesti dalla specifica C2, fare riferimento alla documentazione
in linea di SQL Server 2000.
SQL Profiler
SQL Profiler è un’utilità con interfaccia grafica che consente di visualizzare i file della
traccia di controllo e di eseguire azioni specifiche come ricerche all’interno dei file,
salvataggio dei file in una tabella e creazione e configurazione delle definizioni della
traccia tramite l’interfaccia utente. Poiché SQL Profiler è un componente client di SQL
Trace, è possibile eseguire controlli di sicurezza anche quando tale componente non
è in esecuzione.
Controlli previsti dallo standard C2
SQL Server 2000 ha ottenuto la certificazione di compatibilità con lo standard C2.
La configurazione collaudata per C2 prevede l’attivazione di un meccanismo di controllo
di livello C2, che definisce i tipi di eventi da controllare (tutti gli eventi legati alla
sicurezza), le colonne di dati da acquisire (tutte quelle che possono contenere
informazioni relative a tali eventi) e altre impostazioni prestabilite.
Ciascuna impostazione è documentata nella documentazione in linea di SQL Server
2000 e in Trusted Facilities Manual for SQL Server 2000, disponibili all’indirizzo
www.microsoft.com/Downloads/release.asp?ReleaseID=25503.
Eliminazione dell’account delegato
SQLAgentCmdExec
In SQL Server 2000 non viene più creato l’account SQLAgentCmdExec. In SQL Server
versione 7.0 e precedenti, i processi dell’Agente SQL Server di proprietà degli account
di accesso senza privilegi di amministratore di sistema potevano accedere alle risorse
di Windows solo utilizzando l’account delegato SQLAgentCmdExec, un account utente di
Windows NT 4.0 e Windows 2000 creato localmente durante l’installazione di SQL Server.
Nella nuova versione, gli utenti senza privilegi di amministratore di sistema non
possono accedere alle risorse esterne a SQL Server per impostazione predefinita.
Tuttavia, quando si attiva un account proxy per SQL Server 2000 è possibile specificare
un account utente di dominio che consente agli utenti senza privilegi di amministratore
di sistema di accedere alle risorse della rete, anziché solo alle risorse locali del
computer in cui è installato SQL Server.
8
Miglioramento dei ruoli del server
Sono stati apportati alcuni piccoli miglioramenti anche ai ruoli predefiniti del server
inclusi in SQL Server 2000. Per informazioni su tali ruoli, vedere la sezione “Ruoli
predefiniti” del presente documento.
BulkAdmin
BulkAdmin è un nuovo ruolo di SQL Server 2000, che consente agli account membri
di eseguire il comando BULK INSERT. Gli utenti di questo gruppo possono caricare dati
da qualsiasi file disponibile in rete e da qualsiasi computer che esegue il server ed è
accessibile mediante l’account del servizio di SQL Server. L’appartenenza deve essere
impostata con estrema attenzione. I membri di questo ruolo devono infatti disporre
dell’autorizzazione INSERT per tutte le tabelle utilizzate come destinazione del comando
BULK INSERT. L’appartenenza a questo ruolo predefinito del server autorizza
unicamente a eseguire l’istruzione BULK INSERT e ad accedere ai file necessari per
l’esecuzione di tale comando.
SecurityAdmin
Il ruolo SecurityAdmin è autorizzato a modificare le password degli account di accesso
per la modalità di autenticazione di SQL Server, che non possono essere reimpostate
dai membri del ruolo predefinito sysadmin. Questo ruolo può essere ad esempio
utilizzato per il personale dell’help-desk, che non necessita dell’accesso amministrativo
completo a SQL Server.
ServerAdmin
L’area dei messaggi a livello di server del ruolo ServerAdmin è stata modificata.
L’appartenenza a questo ruolo consente ora di eseguire sp_addmessage,
sp_dropmessage e sp_altermessage.
Crittografia
Crittografia di rete con SSL/TLS
SQL Server 2000 supporta automaticamente la crittografia dei dati e del traffico di rete
tra i sistemi client e server di una rete. Il livello di crittografia dipende dalle capacità
specificate nel certificato installato per SQL Server e dalle funzionalità di crittografia
del client e del server.
Il certificato selezionato per SQL Server deve essere associato al nome del server,
che deve essere costituito da un nome di server DNS completo, come
SQLServer.Redmond.corp.Microsoft.com. Il certificato deve consentire l’autenticazione
del server. È necessario effettuare l’accesso a SQL Server con l’account del servizio di
SQL Server, richiedere il certificato (a un’autorità di certificazione interna o a
un’autorità attendibile indipendente come Verisign), quindi installare il certificato nel
percorso del server suggerito al momento dell’importazione del certificato.
9
Crittografia dei pacchetti di accesso
Durante tutti i tentativi di accesso, se nel server è presente un certificato utilizzabile,
valido per l’autenticazione del server e con nome oggetto uguale al nome DNS del
computer, tutti i pacchetti scambiati durante l’accesso vengono crittografati.
Questa operazione viene eseguita automaticamente e non richiede particolari
operazioni di configurazione del server, oltre all’installazione del certificato.
Crittografia richiesta dal client
Il client può richiedere la crittografia di tutto il traffico di dati diretto a SQL Server.
Questa opzione, che può essere impostata mediante l’utilità Configurazione di rete
client (Imponi crittografia protocolli), viene applicata a tutte le connessioni in uscita
dal computer client. La richiesta di crittografia da parte del client impedisce inoltre
l’accesso a SQL Server 7.0 e versioni precedenti e a qualsiasi computer SQL Server
2000 che non disponga di un certificato valido.
Questa impostazione può essere configurata anche a livello di programmazione,
inserendo l’opzione “Encrypt=yes” nella stringa di connessione OLE DB o ODBC per
il server di database.
Crittografia richiesta dal server
La crittografia dei dati può essere applicata anche sul server, se l’amministratore del
database lo richiede. Questa opzione, che può essere impostata mediante l’utilità
Configurazione di rete di SQL Server (Imponi crittografia protocolli), assicura la
crittografia di tutto il traffico di rete diretto a SQL Server. Se un client non è in grado
di negoziare la crittografia con SQL Server, la connessione viene chiusa.
Supporto per la crittografia del file system
in Windows 2000
SQL Server 2000 protegge i file di dati utilizzando in modo appropriato il supporto
per la crittografia del file system integrata in Windows 2000. Per crittografare i file
è necessario utilizzare l’account del servizio di SQL Server.
Per cambiare l’account del servizio, occorre decrittografare i file, cambiare l’account
per i servizi di SQL Server, quindi crittografare nuovamente i file utilizzando il nuovo
account del servizio. Se non si procede in questo modo, potrebbe risultare impossibile
avviare SQL Server, perché l’applicazione non è in grado di decrittografare i file
crittografati con le credenziali dell’account del servizio utilizzato in precedenza.
Crittografia avanzata basata sul server
Nell’ambito di una revisione completa dell’uso della crittografia nei prodotti Microsoft,
per tutti i dati crittografati basati sul server (password, stored procedure crittografate
e così via) verrà utilizzata l’API di crittografia di Windows, CryptoAPI, che assicura una
maggiore affidabilità e sicurezza nell’archiviazione degli elementi protetti in SQL Server.
10
Crittografia dei pacchetti DTS
Nella nuova versione i pacchetti DTS (Data Transformation Services) vengono
crittografati mediante CryptoAPI.
Se in SQL Server 7.0 si specifica una password per un pacchetto DTS, quest’ultimo
viene crittografato utilizzando la password come chiave. Se non si specifica alcuna
password, il pacchetto non viene protetto. In SQL Server 2000 tutti i pacchetti vengono
crittografati anche se non viene fornita alcuna password.
Protezione tramite password
Backup e gruppi di supporti di backup
SQL Server 2000 consente di specificare una password per un singolo backup o per
un gruppo di supporti di backup. Poiché senza tale password non è possibile ripristinare
i dati di backup, in questo modo è possibile proteggersi dal ripristino non autorizzato
delle copie di backup.
Tuttavia, dal momento che i dati non vengono crittografati, un programma che non
supporti il formato MTF (Microsoft Tape Format) può ignorare la password e consentire
l’accesso ai dati contenuti nel supporto di backup. Tutti i meccanismi di ripristino di
SQL Server prevedono invece l’utilizzo della password.
SQL Server Enterprise Manager
Mentre in SQL Server 7.0 le password per l’accesso autenticato venivano memorizzate
in un formato non protetto nel Registro di sistema del computer client, in SQL Server
2000 tali password vengono crittografate con CryptoAPI.
Modifica dell’account del servizio con
SQL Server Enterprise Manager
Quando si utilizza SQL Server Enterprise Manager per modificare gli account dei
servizi di SQL Server (SQL Server o Agente SQL Server), vengono reimpostate sia
le autorizzazioni relative a file e directory, se i dati sono archiviati nel file system NTFS,
sia le autorizzazioni relative alle chiavi di registro. Le nuove autorizzazioni vengono
aggiunte, mentre l’account del servizio precedente e il gruppo Administrators predefinito
vengono mantenuti. La password viene reimpostata nel database dei servizi, come
avviene quando si reimpostano le informazioni di un account mediante l’utilità Servizi
del Pannello di controllo, e all’account del servizio selezionato vengono concesse le
autorizzazioni di protezione appropriate di Windows NT o Windows 2000. Infine, il
nuovo account di servizio viene aggiunto al ruolo predefinito sysadmin di SQL Server.
11
Eliminazione della colonna SUID in tutte
le tabelle di sistema
Nelle versioni precedenti di SQL Server, la colonna SUID era presente nelle seguenti
tabelle di sistema:

Sysdatabases

Syslogins

Sysremotelogins

Sysusers

Sysprocesses

Sysalternates
In SQL Server 7.0 questa colonna non veniva tuttavia utilizzata, poiché è stata
sostituita dalla colonna SID, ma è stata mantenuta per assicurare la compatibilità con
le versioni precedenti. Per evitare confusione, nella nuova versione questa colonna è
stata rimossa ed è stata eliminata anche la tabella sysalternates, poiché conteneva
solo le relazioni tra i SUID.
12
Modello di protezione di SQL Server 2000
Per implementare la sicurezza in SQL Server 2000 con la massima efficienza, è
importante comprendere come è stato implementato il modello di protezione dal team
di progettazione. Gli utenti che hanno familiarità con la protezione di Windows
avranno senz’altro compreso come l’utilizzo degli utenti e dei gruppi di Windows
possa accrescere le potenzialità di SQL Server 2000.
In SQL Server 2000 la protezione dovrebbe essere implementata come illustrato
nella figura 2.
Dominio trusted
Utente
Utente
Dominio trusted
Utente
Utente
Utente

Dominio trusted
Utente
Utente
Utente

Utente
Utente
Utente

Gruppo glob ale
Gruppo glob ale
Dominio trusted
Utente

Gruppo glob ale
Gruppo glob ale
Dominio
SQL Server
Database
$ $
$
DB
Utente
Utente

Oggetto
Utente
Ruolo

Database



DB
Oggetto
Gruppo locale
Gruppo glob ale
Figura 2: il modello basato sugli utenti e sui gruppi di Windows offre agli amministratori
di SQL Server uno strumento di protezione potente e flessibile.
Nel diagramma sono illustrati i seguenti passaggi:
1. Nei singoli domini gli utenti vengono assegnati ai gruppi globali di Windows.
2. I gruppi globali di Windows dei diversi domini vengono inseriti nel gruppo locale
di Windows.
3. Al gruppo locale di Windows vengono assegnati i diritti di accesso a SQL Server 2000.
13
4. Al gruppo locale di Windows vengono assegnati i diritti di accesso ai database
appropriati. Tale gruppo locale di Windows deve essere diverso da quello utilizzato
per concedere i diritti di accesso nel passaggio 3. I passaggi 1 e 2 vengono pertanto
ripetuti di frequente per raggruppare gli utenti in base alle autorizzazioni di accesso
necessarie.
5. Al gruppo locale di Windows vengono assegnate le autorizzazioni relative a oggetti
specifici del database.
È anche possibile adottare un approccio alternativo alla protezione, basato sull’uso dei
ruoli e in genere implementato come illustrato nella figura 3.
Dominio trusted
Utente
Utente
Dominio trusted
Utente
Utente
Utente

Dominio trusted
Utente
Utente

Gruppo glob ale
Utente
Dominio trusted
Utente
Utente
Utente

Gruppo glob ale
Utente

Gruppo glob ale
Gruppo glob ale
Dominio
SQL Server
Database
$ $
$

DB
Utente
Utente

Oggetto
Utente


 Ruolo

Database
DB
Oggetto
Gruppo locale
Gruppo glob ale
Figura 3: in alternativa, in SQL Server 2000 è possibile utilizzare la protezione basata sui ruoli.
Se si sceglie di utilizzare i ruoli per assegnare le autorizzazioni relative agli oggetti,
le autorizzazioni relative al server e al database devono essere comunque assegnate
agli utenti utilizzando l’approccio consigliato.
Nei due diagrammi i passaggi da 1 a 4 sono identici, anche se nel secondo non
verranno probabilmente creati più gruppi locali e globali di Windows. Sono
completamente supportati anche i gruppi universali di Windows 2000.
Fase 5: assegnazione di singoli account e gruppi di Windows a un ruolo.
Fase 6: assegnazione delle autorizzazioni relative agli oggetti ai ruoli.
Poiché quando si utilizzano i ruoli gli utenti vengono raggruppati in SQL Server 2000,
l’esigenza di creare gruppi di utenti in Windows è più limitata.
14
Modalità di autenticazione
In Microsoft SQL Server 2000 sono disponibili due modalità di autenticazione per
proteggere l’accesso al server: l’autenticazione di Windows e la modalità mista.
Nota: la modalità di autenticazione standard, presente in SQL Server 6.5, è stata
eliminata in SQL Server 7.0.
Autenticazione di Windows
L’autenticazione di Windows è la modalità di autenticazione predefinita di SQL Server 2000.
Se si sceglie questa modalità, SQL Server 2000 si basa esclusivamente sull’autenticazione
di Windows e consente l’accesso a tutti gli utenti e i gruppi di Windows.
L’autenticazione di Windows consente a SQL Server 2000 di autenticare gli utenti
basandosi sul sistema Windows, come fanno anche altre applicazioni. Le connessioni
stabilite con il server utilizzando questa modalità di autenticazione sono dette
connessioni trusted.
Quando viene utilizzata l’autenticazione di Windows, l’amministratore del database
concede il diritto di accesso a SQL Server 2000 agli utenti che accedono al computer
che esegue SQL Server. Per tenere traccia degli accessi autenticati da Windows
vengono utilizzati gli identificativi di protezione (SID, Security Identifier). Servendosi
dei SID di Windows, l’amministratore del database può concedere l’accesso
direttamente agli utenti e ai gruppi di Windows.
Modalità mista
Se è impostata la modalità mista, gli utenti possono essere autenticati mediante
l’autenticazione di Windows o l’autenticazione di SQL Server. Le coppie nome
utente/password degli utenti autenticati da SQL Server vengono gestite all’interno
di SQL Server.2
In SQL Server 2000, la modalità mista prevede l’uso dell’autenticazione di Windows
quando il client e il server supportano l’utilizzo di NTLM 3 o i protocolli Kerberos per
l’autenticazione di accesso. Se il client non è in grado di utilizzare un metodo di accesso
standard di Windows, SQL Server richiede l’immissione di una coppia nome
utente/password e la confronta con quella memorizzata nelle tabelle di sistema.
Le connessioni basate sulle coppie nome utente/password sono dette non trusted.
La modalità mista viene fornita per garantire la compatibilità con le versioni precedenti
e per l’utilizzo di SQL Server 2000 con i sistemi operativi Windows 98 e Windows ME.
Infatti, i computer Windows 98 e Windows ME configurati come server non supportano
le connessioni trusted.
Le coppie nome utente/password vengono memorizzate nella tabella di sistema
sysxlogins del database master.
2
3
Accesso standard di Windows NT tramite il metodo Challenge-Response.
15
Utilizzo interno degli identificativi
di protezione (SID)
SQL Server 2000 utilizza internamente gli identificativi di protezione (SID) degli utenti.
È possibile consentire agli utenti e ai gruppi di Windows l’accesso a un database o a
oggetti specifici all’interno di un database. Si supponga ad esempio che l’utente Jane
faccia parte dei gruppi SALES e MARKETING di Windows e che al gruppo SALES sia
stata concessa l’autorizzazione di accesso a SQL Server e al database pubs. Se
l’amministratore concede a Jane anche l’accesso alla tabella authors utilizzandone il
nome utente di Windows, REDMOND\Ferraro (per fare riferimento all’account di
Windows occorre specificare sia il dominio che il nome utente) il SID di Jane viene
memorizzato nelle tabelle di sistema del database pubs.
SQL Server 2000 non supporta l’uso dei nomi principali degli utenti (UPN, User Principal
Name). Se ad esempio il dominio di accesso è SALES e il nome utente è SOMEONE,
l’accesso a SQL Server è impostato come SALES\SOMEONE e non è possibile utilizzare
il nome [email protected], supportato da Windows 2000 Active Directory.
Ruoli
I ruoli, che svolgono una funzione analoga a quella dei gruppi di Windows, consentono
di raggruppare più utenti in una singola unità alla quale è possibile applicare le
autorizzazioni desiderate. La concessione, la negazione e la revoca delle autorizzazioni
hanno effetto su tutti i membri del ruolo. È ad esempio possibile definire un ruolo che
rappresenta un’attività svolta da una particolare categoria di dipendenti all’interno di
un’organizzazione e concedere le autorizzazioni a tale ruolo. Se l’attività corrispondente
al ruolo viene svolta a turno dai dipendenti, ognuno di essi viene aggiunto al ruolo
all’inizio del proprio turno e viene rimosso alla fine di quest’ultimo. In questo modo si
evita di concedere, negare e revocare continuamente le autorizzazioni ai singoli utenti
ogni volta che iniziano e finiscono il proprio turno.
I ruoli costituiscono uno strumento molto potente, poiché si basano su numerosi
concetti chiave. Innanzitutto poiché, ad eccezione di quelli predefiniti del server, i ruoli
vengono implementati all’interno di un database, l’amministratore del database può
creare gruppi di utenti indipendentemente dalle scelte effettuate dall’amministratore di
Windows. In secondo luogo, i ruoli possono essere nidificati, senza alcuna limitazione
legata ai livelli anche se, per ovvie ragioni, non è consentita la nidificazione circolare. In
terzo luogo, diversamente da quanto avveniva per i gruppi di SQL Server 6.5 e versioni
precedenti, ogni utente di un database può appartenere anche a più ruoli
contemporaneamente.
Ruolo public
Il ruolo public è presente in tutti database, inclusi i database master, msdb, tempdb
e model di sistema, e, poiché fornisce le autorizzazioni predefinite per gli utenti del
database, non può essere eliminato. Dal punto di vista funzionale, può essere paragonato
al gruppo Everyone di Windows NT 4.0. Poiché tutti gli utenti di un database vengono
automaticamente aggiunti a questo ruolo, non è possibile aggiungere né rimuovere
manualmente gli utenti.
16
Ruoli predefiniti
SQL Server 2000 include diversi ruoli predefiniti, dotati di autorizzazioni implicite
predefinite che non possono essere concesse ad altri account utente. Esistono due tipi
di ruoli predefiniti: ruoli predefiniti del server e ruoli predefiniti dei database.
Ruoli predefiniti del server
I ruoli predefiniti del server hanno ambito esteso all’intero server e non risiedono nei
database. Tutti i membri di un ruolo predefinito del server hanno facoltà di aggiungere
a tale ruolo altri account di accesso.
Nota: tutti i membri del gruppo BUILTIN\Administrators di Windows (il gruppo
dell’amministratore locale) sono membri del ruolo sysadmin per impostazione
predefinita.
I ruoli predefiniti del server disponibili in SQL Server 2000 sono elencati nella tabella
che segue (figura 4).
Ruolo
predefinito
del server
Descrizione
Sysadmin
Consente di eseguire qualsiasi attività in SQL Server.
Serveradmin
Consente di arrestare il server e di impostare le opzioni di configurazione
a livello di server.
Setupadmin
Consente di gestire i server collegati e le procedure di avvio.
securityadmin
Consente di gestire le impostazioni di protezione a livello di server, inclusi
i server collegati e le autorizzazioni CREATE DATABASE. Consente inoltre
di reimpostare le password degli account di accesso utilizzati per
l’autenticazione di SQL Server.
processadmin
Consente di terminare i processi in esecuzione in SQL Server.
dbcreator
Consente di creare, modificare, eliminare e ripristinare qualsiasi database.
diskadmin
Consente di gestire i file su disco.
Bulkadmin
Consente l’esecuzione dell’istruzione bulkadmin da parte degli utenti che
non appartengono al ruolo sysadmin.
Figura 4: ruoli predefiniti del server disponibili in SQL Server 2000.
Per aggiungere utenti ai ruoli predefiniti del server, è necessario utilizzare la seguente
istruzione Transact-SQL:
/* Add Bob to the sysadmin server role */
exec sp_addsrvrolemember “REDMOND\Bob”, “sysadmin”
È possibile aggiungere ai ruoli del server qualsiasi utente o gruppo di Windows.
17
Il codice che segue consente di aggiungere un utente a un ruolo del server mediante
SQL-DMO:
‘ Declare variables
Dim oServer As SQLDMO.SQLServer
‘ Create a server object and connect
Set oServer = CreateObject(“SQLDMO.SQLServer”)
oServer.Connect (“SERVERNAME”)
‘ Add Bob to the sysadmin server role
oServer.ServerRoles(“sysadmin”).AddMember (“REDMOND\Bob”)
Per ulteriori informazioni sull’utilizzo dei ruoli predefiniti del server, fare riferimento alla
documentazione in linea di SQL Server 2000.
Ruoli predefiniti dei database
I ruoli predefiniti dei database vengono definiti a livello di database e risiedono nei
singoli database. L’appartenenza al ruolo predefinito di un database può essere gestita
dai membri dei ruoli amministrativi db_owner e db_security, ma solo i membri di
db_owner possono aggiungere utenti a tale ruolo predefinito.
I ruoli predefiniti dei database disponibili in SQL Server 2000 sono elencati nella tabella
che segue (figura 5).
Ruoli predefiniti
dei database
Descrizione
db_owner
Consente di eseguire qualsiasi attività di manutenzione e configurazione
del database.
db_accessadmin
Consente di concedere o negare l’accesso a utenti e gruppi di Windows
e agli account di accesso di SQL Server.
db_datareader
Consente di leggere tutti i dati da tutte le tabelle utente.
db_datawriter
Consente di aggiungere, eliminare o modificare dati in tutte le tabelle
utente.
db_ddladmin
Consente di eseguire qualsiasi comando DDL (Data Definition Language)
in un database.
db_securityadmin
Consente di modificare l’appartenenza ai ruoli e di gestire le autorizzazioni.
db_backupoperator Consente di eseguire il backup del database.
db_denydatareader Impedisce di leggere i dati nelle tabelle utente di un database.
db_denydatawriter
Impedisce di aggiungere, modificare o eliminare dati in qualsiasi vista
o tabella utente.
Figura 5: ruoli predefiniti dei database disponibili in SQL Server 2000.
Per ulteriori informazioni sull’utilizzo dei ruoli predefiniti dei database, fare riferimento
alla documentazione in linea di SQL Server 2000.
18
Ruoli definiti dall’utente
I ruoli definiti dall’utente semplificano la gestione delle autorizzazioni relative a un
database quando è presente un gruppo di utenti che svolgono uno specifico insieme
di attività in SQL Server 2000 e in Windows non è disponibile alcun gruppo applicabile
oppure l’amministratore del database non dispone delle autorizzazioni necessarie per
gestire gli account utente di Windows. In questi casi, infatti, i ruoli definiti dall’utente
offrono all’amministratore del database la stessa flessibilità dei gruppi di Windows.
Tali ruoli, che sono ruoli locali del database in cui vengono creati, sono applicabili solo
a livello di database.
Ruoli applicazione
I ruoli applicazione consentono all’amministratore del database di limitare l’accesso ai
dati in base all’applicazione utilizzata. Quando si utilizzano questi ruoli, l’autenticazione
dell’utente viene eseguita dalle singole applicazioni.
Quando un’applicazione stabilisce una connessione a SQL Server 2000, esegue la
stored procedure sp_setapprole, che accetta due parametri: nome utente e password
(questi parametri possono essere crittografati 4).5 Le autorizzazioni eventualmente
esistenti per l’utente vengono eliminate e viene applicato il contesto di protezione
dell’applicazione.
Una volta attivati, i ruoli applicazione non possono essere disattivati e per tornare al
contesto di protezione originale dell’utente è necessario disconnettersi e riconnettersi
a SQL Server.
I ruoli applicazione supportano entrambe le modalità di autenticazione e non possono
avere membri. Non è infatti possibile associare utenti ai ruoli applicazione, poiché ogni
programma richiede il contesto di protezione del ruolo applicazione tramite la stored
procedure sp_setapprole.
Come i ruoli definiti dall’utente, i ruoli applicazione esistono solo nel contesto del
database. Se si accede a un altro database mentre un’applicazione si trova nel contesto
di protezione di un ruolo applicazione, l’accesso a tale database viene concesso
all’account guest di tale database, secondo le autorizzazioni impostate. Se l’account
guest non esiste o non è espressamente autorizzato ad accedere ai dati, non sarà
possibile accedere agli oggetti.
Quando si utilizzano i ruoli applicazione è importante sapere che in SQL Server 2000
viene effettuato il controllo dell’utente che esegue l’applicazione. In altre parole, i ruoli
applicazione forniscono il contesto di protezione per il controllo delle autorizzazioni di
accesso agli oggetti del database, ma l’identità effettiva dell’utente viene mantenuta.
Di seguito è riportato un esempio di implementazione basato sui ruoli applicazione. Se
Jane appartiene al gruppo ACCOUNTING e i membri di questo gruppo sono autorizzati
ad accedere ai dati disponibili in SQL Server solo tramite il pacchetto
di contabilità, è possibile creare un ruolo applicazione per tale prodotto software.
La password può essere sempre crittografata prima dell’invio a SQL Server.
Utilizzando la libreria di rete Multiprotocol, è possibile crittografare anche il pacchetto
che contiene la password.
4
Il modo migliore per memorizzare il nome utente e la password consiste nel salvare le
informazioni in una chiave di registro, la quale deve essere crittografata con una chiave
nota solo all’applicazione.
5
19
Pertanto, sarà autorizzato ad accedere ai dati il ruolo applicazione ACCOUNTING, ma
non il gruppo ACCOUNTING di Windows. In questa situazione, Jane può accedere ai
dati utilizzando il software di contabilità, ma non utilizzando SQL Query Analyzer.
La procedura che segue illustra l’utilizzo dei ruoli applicazione da parte di
un’applicazione client.
1. Creare un ruolo applicazione.
2. Assegnare a tale ruolo le autorizzazioni desiderate.
3. Assicurarsi che l’applicazione client sia in grado di connettersi a SQL Server 2000.
4. Assicurarsi che l’applicazione client attivi il ruolo applicazione.
I primi due passaggi di questa procedura sono in genere distinti dagli ultimi due.
Di seguito vengono pertanto riportati due diversi frammenti di codice, rispettivamente
per Transact-SQL e Visual Basic.
Script Transact-SQL:
/* Create the application role. */
EXEC sp_addapprole “AccAppRole”, “ABC”
/* Grant permissions to SELECT. */
GRANT SELECT
ON authors
TO AccAppRole
GO
Per attivare il ruolo è necessario utilizzare il codice seguente:
/* Activate the role. */
EXEC sp_setapprole “AccAppRole”, {ENCRYPT N “ABC”}
La crittografia della password è facoltativa, ma assicura un maggior livello
di protezione quando la password viene trasmessa su una rete WAN.
Codice Visual Basic:
‘ Declare variables.
Dim oServer As SQLDMO.SQLServer
Dim oDbRole As SQLDMO.DatabaseRole
‘ Create a server object and connect.
Set oServer = CreateObject(“SQLDMO.SQLServer”)
oServer.Connect (“SERVERNAME”)
‘ Create the Role object.
Set oDbRole = CreateObject(“SQLDMO.DatabaseRole”)
20
‘ Set the appropriate properties.
oDbRole.Name = “AccAppRole”
oDbRole.AppRole = True
oDbRole.Password = “ABC”
‘ Add the Role object to the servers Role collection.
oServer.Databases(“pubs”).DatabaseRoles.Add oDbRole
Per utilizzare il ruolo:
‘ Declare variables.
Dim oConnection As ADODB.Connection
‘ Create the connection object and connect.
Set oConnection = CreateObject(“ADODB.Connection”)
oConnection.Provider = “sqloledb”
oConnection.Open “Server=SERVERNAME;Database=pubs;Trusted_Connection=yes”
‘ Activate the application role. There is no error handling for this
sample.
oConnection.Execute “EXEC sp_setapprole ‘AccAppRole’, {ENCRYPT N ‘ABC’},
‘ODBC’”
Per le origini dati OLE DB e ODBC è necessario impostare lo stile di crittografia (l’ultimo
parametro), mentre le altre origini dati non sono in grado di crittografare la password
in modo esplicito. Se si utilizzano origini dati di questo tipo, è necessario utilizzare un
protocollo di comunicazione crittografato per la connessione al server.
Poiché i ruoli applicazione vengono implementati a livello di sessione, se l’applicazione
in uso crea più sessioni che richiedono lo stesso ruolo, prima di eseguire qualsiasi
operazione ogni sessione dovrà attivare il ruolo.
L’implementazione dei ruoli applicazione consente di ottenere un livello di sicurezza molto
più dettagliato che in passato. Ad esempio, un’applicazione client può utilizzare il contesto
di protezione dell’utente per alcune connessioni e un ruolo applicazione per altre.
Quando si utilizzano i ruoli applicazione, per verificare il nome del ruolo applicazione
in uso è possibile eseguire il comando SELECT USER, mentre per conoscere l’identità
dell’utente attualmente connesso è possibile utilizzare la seguente istruzione SQL:
SELECT SYSTEM_USER.
21
Protezione dell’accesso al server
La modalità di controllo dell’accesso al server dipende dalla modalità di autenticazione
di SQL Server 2000. Dopo l’accesso, le modalità di autenticazione sono invece
identiche. Al momento dell’installazione di SQL Server 2000 viene attivata per
impostazione predefinita l’autenticazione di Windows.
Accesso a livello di Windows
Se l’accesso al sistema viene impostato a livello di Windows, l’amministratore deve
creare un account di accesso per ciascun utente che intenda connettersi a SQL Server
e che non disponga già di un account.
In ogni dominio di account utente, è necessario creare gruppi globali per raggruppare
gli utenti in base ai requisiti di processo. Gli utenti devono essere quindi inseriti nei
gruppi globali appropriati dei rispettivi domini.
Nel computer che esegue SQL Server 2000 i gruppi locali dovranno essere creati in
base ai diversi requisiti di processo per i quali è necessario assegnare un’autorizzazione
di accesso a SQL Server. È quindi necessario inserire i gruppi globali appropriati dei
diversi domini trusted nei rispettivi gruppi locali del computer che esegue SQL Server.
Anche se la creazione dei gruppi globali e locali descritti in precedenza può sembrare
eccessivamente impegnativa per una rete di piccole dimensioni e con un solo dominio,
l’esperienza ha dimostrato che questa configurazione consente di ottenere ottimi
risultati.
È infatti essenziale raggruppare tutti gli utenti con le stesse esigenze di protezione in
una singola unità, che può essere utilizzata dall’amministratore del database per
concedere le autorizzazioni di accesso a SQL Server 2000. L’accesso per gruppo non
impedisce tuttavia di identificare i singoli utenti dall’interno del database. 6
Nonostante le raccomandazioni, l’amministratore del database ha la possibilità di
assegnare le autorizzazioni relative agli oggetti a gruppi universali, gruppi globali,
gruppi locali e singoli account utente di Windows.
Nota: la creazione di account utente e gruppi di Windows a livello di programmazione
non rientra nell’ambito del presente documento.
Tale operazione può essere effettuata utilizzando il modello di oggetti ADSI di Microsoft
Visual Basic oppure accedendo direttamente all’API Win32 ® da Microsoft Visual C++®.
In sostanza, si tratta di una configurazione analoga a quella utilizzata per la protezione
di un file nel file system NTFS, in cui l’accesso è consentito solo ai membri del gruppo
SALES. In tale configurazione Bob, che appartiene al gruppo SALES, tenta di accedere
al file, nel registro di controllo viene inserita una voce per l’utente Bob, non per il
gruppo SALES.
6
22
Accesso a livello di SQL Server
Per consentire l’accesso a SQL Server da parte dei gruppi locali di Windows creati, è
necessario concedere autorizzazioni a livello di SQL Server 2000. Tali autorizzazioni
possono essere concesse direttamente agli utenti, ma questo può risultare poco pratico
per l’amministrazione, se non negli ambienti più limitati.
Le autorizzazioni di accesso al server possono essere concesse tramite l’interfaccia
utente o implementate a livello di programmazione utilizzando Microsoft Visual Basic
o Transact-SQL.7
Per la concessione dell’accesso agli utenti e ai gruppi di Windows sono state create
le nuove stored procedure elencate di seguito (figura 6).
sp_addalias
sp_droprole
sp_addapprole
sp_droprolemember
sp_addgroup
sp_dropserver
sp_addlinkedsrvlogin
sp_dropsrvrolemember
sp_addlogin
sp_dropuser
sp_addremotelogin
sp_grantdbaccess
sp_addrole
sp_grantlogin
sp_addrolemember
sp_helpdbfixedrole
sp_addserver
sp_helpgroup
sp_addsrvrolemember
sp_helplinkedsrvlogin
sp_adduser
sp_helplogins
sp_approlepassword
sp_helpntgroup
sp_change_users_login
sp_helpremotelogin
sp_changedbowner
sp_helprole
sp_changegroup
sp_helprolemember
sp_changeobjectowner
sp_helprotect
sp_dbfixedrolepermission
sp_helpsrvrole
sp_defaultdb
sp_helpsrvrolemember
sp_defaultlanguage
sp_helpuser
sp_denylogin
sp_password
sp_dropalias
sp_remoteoption
sp_dropapprole
sp_revokedbaccess
sp_dropgroup
sp_revokelogin
sp_droplinkedsrvlogin
sp_setapprole
sp_droplogin
sp_srvrolepermission
sp_dropremotelogin
sp_validatelogins
Figura 6: stored procedure legate alla protezione disponibili in SQL Server 2000.
Le definizioni che seguono rientrano nel contesto del presente documento. Il codice
Visual Basic si riferisce alla creazione di un’applicazione in ambiente Visual Basic o
Visual Basic, Applications Edition dotato della libreria SQL-DMO. Il codice Transact-SQL
(Transact Structured Query Language) si riferisce all’implementazione di SQL
disponibile in SQL Server 7.0 e SQL Server 2000.
7
23
La seguente istruzione Transact-SQL concede i diritti di accesso al gruppo locale
SALESLG:
/* Grant login. */
exec sp_grantlogin ‘REDMOND\SALESLG’
In alternativa, per concedere i diritti di accesso è possibile utilizzare il seguente codice
Visual Basic:
‘ Declare variables.
Dim oServer As SQLDMO.SQLServer
Dim oLogin As SQLDMO.Login
‘ Create a server object and connect.
Set oServer = CreateObject(“SQLDMO.SQLServer”)
oServer.Connect (“SERVERNAME”)
‘ Create the Login object.
Set oLogin = CreateObject(“SQLDMO.Login”)
‘ Set the appropriate properties.
oLogin.Name = “REDMOND\SALESLG”
oLogin.Type = SQLDMOLogin_NTGroup
‘ Add the Login object to the server’s Logins collection.
oServer.Logins.Add oLogin
Per consentire agli utenti di accedere a SQL Server 2000 utilizzando connessioni non
trusted, è necessario creare i relativi account utente in SQL Server.
Nota: se si installa SQL Server 2000 in Windows selezionando la modalità mista,
i client che supportano l’autenticazione di Windows possono comunque stabilire
connessioni trusted.
Il seguente script Transact-SQL consente invece di creare un account di accesso per
una connessione non trusted:
/* Add a login. */
exec sp_addlogin ‘Bob’, ‘password’, ‘pubs’
Questa istruzione aggiunge un utente di nome Bob, con password uguale a password
e pubs come database predefinito. Il database predefinito è quello a cui viene
connesso l’utente al momento dell’accesso. Tuttavia, affinché ciò sia possibile l’utente
deve creare un account utente nel database predefinito, perché la stored procedure
sp_addlogin non aggiunge alcun account utente al database a cui viene fatto
riferimento nello script.
24
In alternativa, per ottenere lo stesso risultato è possibile utilizzare il seguente codice
Visual Basic:
‘ Declare variables.
Dim oServer As SQLDMO.SQLServer
Dim oLogin As SQLDMO.Login
‘ Create a server object and connect.
Set oServer = CreateObject(“SQLDMO.SQLServer”)
oServer.Connect (“SERVERNAME”)
‘ Create the Login object.
Set oLogin = CreateObject(“SQLDMO.Login”)
‘ Set the appropriate properties.
oLogin.Name = “Bob”
oLogin.Type = SQLDMOLogin_Standard
oLogin.SetPassword ““,”password”
‘ Add the Login object to the server’s Logins collection.
oServer.Logins.Add oLogin
25
Protezione dell’accesso ai database
L’esecuzione dell’accesso non implica automaticamente la possibilità di accedere a tutti
i database di SQL Server 2000. Per consentire agli utenti di accedere a un determinato
database, è infatti necessario concedere le autorizzazioni appropriate.
In questa sezione non viene fatta distinzione fra utenti non trusted, utenti di Windows
e gruppi di Windows. Se viene fatto riferimento a utenti o gruppi di Windows, può
trattarsi di utenti o gruppi globali appartenenti a domini trusted o a domini situati
nello stesso insieme di strutture.
In ogni database viene creato un utente che viene collegato a un account di accesso
di SQL Server oppure a un utente o a un gruppo di Windows.
Lo snap-in di Microsoft Management Console (MMC) SQL Server Enterprise Manager,
utilizzato per l’amministrazione di SQL Server 2000, non consente la creazione di utenti
senza autorizzazioni di accesso specifiche. È pertanto necessario selezionare una voce
dall’elenco degli account autorizzati ad accedere al server visualizzato in MMC. Lo
stesso vale per il modello di oggetti SQL-DMO.
Con Transact-SQL è possibile concedere i diritti di accesso a un database a qualsiasi
account di accesso di SQL Server oppure a qualsiasi utente o gruppo di Windows valido,
anche se nella tabella sysxlogins del database master non è presente un account di
accesso specifico.
Nota: anche se non è necessario dal punto di vista tecnico, se si utilizzano connessioni
trusted nei singoli database è preferibile creare utenti con nome uguale al nome di
accesso.
Di seguito sono riportati alcuni esempi di istruzioni Transact-SQL per la concessione
delle autorizzazioni per l’utilizzo di un database:
/* Grant access to Bob. */
exec sp_grantdbaccess ‘REDMOND\Bob’
/* Grant access to Wendy, referring to her by first name within this
database. */
exec sp_grantdbaccess ‘REDMOND\WendyH’, ‘Wendy’
Per consentire il funzionamento di questo esempio di codice con client non trusted,
è sufficiente sostituire il nome utente di dominio con il nome utente utilizzato da
SQL Server 2000 per l’autenticazione dell’utente.
Se si utilizza SQL-DMO, per ottenere lo stesso risultato è necessario utilizzare il codice
seguente:
‘ Declare variables.
Dim oServer As SQLDMO.SQLServer
Dim oUser As SQLDMO.User
26
‘ Create a server object and connect.
Set oServer = CreateObject(“SQLDMO.SQLServer”)
oServer.Connect (“SERVERNAME”)
‘ Create the User object.
Set oUser = CreateObject(“SQLDMO.User”)
‘ Set the appropriate properties.
oUser.Name = “Bob”
oUser.Login = “REDMOND\Bob”
‘ Add the User object to the servers Users collection.
oServer.Databases(“pubs”).Users.Add oUser
Protezione dell’accesso agli oggetti di un database
Le autorizzazioni concesse a ruoli e utenti possono essere assegnate in modo da
consentire l’esecuzione di determinate istruzioni e l’accesso a particolari oggetti
del database. Le autorizzazioni per l’esecuzione di istruzioni consentono di
specificare gli utenti autorizzati a eseguire istruzioni come CREATE DATABASE,
CREATE TABLE o CREATE FUNCTION. Le autorizzazioni relative gli oggetti limitano
l’accesso a oggetti come tabelle, viste, funzioni definite dall’utente e stored
procedure. Le autorizzazioni disponibili dipendono dagli oggetti a cui si riferiscono.
Ad esempio, le autorizzazioni relative alle tabelle includono SELECT, INSERT,
UPDATE, DELETE e REFERENCES, mentre quelle relative alle stored procedure
includono EXECUTE.
Ruoli del database definiti dall’utente
In un ambiente ideale i ruoli non sarebbero necessari, perché tutti utilizzerebbero
SQL Server 2000 in Windows NT 4.0 o Windows 2000 e verrebbe utilizzata solo
l’autenticazione di Windows. L’amministratore del database potrebbe pertanto
chiedere all’amministratore di Windows di inserire in un particolare gruppo di
Windows tutti gli utenti con uno specifico requisito (o ruolo) di accesso ai dati, per
poi concedere le autorizzazioni necessarie solo a tale gruppo di Windows.
Poiché, tuttavia, nella maggior parte degli ambienti questa situazione non si verifica,
non sempre è possibile creare gruppi di Windows appropriati. Se ad esempio si installa
SQL Server 2000 in Windows 98, non è tecnicamente possibile creare gruppi di
Windows. In questo caso è tuttavia possibile utilizzare i ruoli per raggruppare gli utenti
in base alle autorizzazioni necessarie.
È infatti possibile creare un ruolo, che può comprendere qualsiasi utente o gruppo di
Windows, e assegnare a tale ruolo le autorizzazioni relative gli oggetti del database
esattamente come si assegnano le autorizzazioni agli utenti del database.
Nota: gli utenti possono definire ruoli solo all’interno di un database. I ruoli predefiniti
del server e i ruoli predefiniti del database non possono essere modificati.
27
Per creare un ruolo è possibile utilizzare il seguente codice Transact-SQL:
/* Add role for Telephone Operators. */
exec sp_addrole “TelephoneOperators”
Oppure il seguente codice Visual Basic:
‘ Declare variables.
Dim oServer As SQLDMO.SQLServer
Dim oDbRole As SQLDMO.DatabaseRole
‘ Create a server object and connect.
Set oServer = CreateObject(“SQLDMO.SQLServer”)
oServer.Connect (“SERVERNAME”)
‘ Create the Database Role object.
Set oDbRole = CreateObject(“SQLDMO.DatabaseRole”)
‘ Set the appropriate properties.
oDbRole.Name = “TelephoneOperators”
‘ Add the Role object to the servers Role collection.
oServer.Databases(“pubs”).DatabaseRoles.Add oDbRole
Dopo la creazione di un ruolo di database definito dall’utente, è possibile aggiungere
a quest’ultimo utenti, gruppi o altri ruoli. I ruoli possono essere nidificati, anche se non
in modo circolare perché non si otterrebbe una configurazione efficace.
Nell’esempio di codice Transact-SQL che segue viene creato un ruolo a cui vengono
aggiunti un utente di Windows, un gruppo di Windows e un ruolo di database.
/* Add a Windows user to the TelephoneOperators role. */
exec sp_addrolemember “TelephoneOperators”, “REDMOND\Bob”
/* Add a Windows group to the TelephoneOperators role. */
exec sp_addrolemember “TelephoneOperators”, “REDMOND\Sales”
/* Add HelpDeskOperators role to TelephoneOperators role. */
exec sp_addrolemember “TelephoneOperators”, “HelpDeskOperators”
28
Utilizzando SQL-DMO si otterrebbe invece il codice seguente:
‘ Declare variables.
Dim oServer As SQLDMO.SQLServer
‘ Create a server object and connect.
Set oServer = CreateObject(“SQLDMO.SQLServer”)
oServer.Connect (“MSNZBENTHOM”)
‘ Use with statement for code legibility.
With oServer.Databases(“pubs”).DatabaseRoles(“TelephoneOperators”)
‘ Add the Windows user to the TelehoneOperators role collection.
.AddMember (“REDMOND\Bob”)
‘ Add the
Windows group to the TelehoneOperator’s role collection
.AddMember (“REDMOND \Sales”)
‘ Add the HelpDeskOperators role to TelehoneOperators role collection.
.AddMember (“HelpDeskOperators”)
End With
Sistema di autorizzazioni
Il sistema di autorizzazioni di SQL Server 2000 si basa sullo stesso modello additivo
alla base delle autorizzazioni di Windows. Un utente che sia membro dei ruoli sales,
marketing e research (ora uno stesso utente può appartenere anche a più
gruppi), dispone della somma delle autorizzazioni fornite da ciascun ruolo. Se ad
esempio il ruolo sales fornisce autorizzazioni SELECT per una tabella, il ruolo
marketing dispone di autorizzazioni INSERT e il ruolo research di autorizzazioni
UPDATE, l’utente disporrà delle autorizzazioni SELECT, INSERT e UPDATE. Tuttavia,
come avviene anche in Windows, se l’utente è membro di un ruolo a cui è stata
negata una particolare autorizzazione per gli oggetti, ad esempio SELECT, l’utente
non potrà beneficiare di tale autorizzazione. Ha infatti la precedenza l’autorizzazione
più restrittiva (DENY).
29
Concessione e negazione delle autorizzazioni
a utenti e ruoli
A livello di database è possibile concedere autorizzazioni solo agli utenti e ai ruoli
del database e agli utenti e ai gruppi di Windows, ma non agli account di accesso
di SQL Server 2000. Per gestire le autorizzazioni appropriate per gli utenti e i ruoli
di un database è necessario utilizzare metodi di concessione, negazione e revoca
delle autorizzazioni.
L’autorizzazione DENY consente all’amministratore di negare a un utente o a un ruolo
l’autorizzazione a utilizzare un determinato oggetto o istruzione. Come avviene anche
per le autorizzazioni di Windows, l’autorizzazione DENY ha la precedenza su tutte le
altre.
Se si nota ad esempio che alcuni utenti di un database modificano i dati in modo
inappropriato, anziché rimuovere le autorizzazioni per tutti gli utenti, la maggior parte
dei quali utilizza i dati in modo responsabile, è possibile creare un nuovo ruolo, ad
esempio trouble_makers, e applicare l’autorizzazione DENY per le operazioni INSERT,
UPDATE e DELETE a tutte le tabelle associate a tale ruolo. Gli utenti che si comportano
in modo inappropriato vengono inseriti nel ruolo trouble_makers indipendentemente
dalle autorizzazioni personali, di gruppo o di ruolo di cui dispongono.
La revoca di un’autorizzazione è diversa dalla negazione. L’autorizzazione REVOKE
elimina un’autorizzazione GRANT o DENY concessa in precedenza, mentre l’autorizzazione
DENY impedisce l’accesso anche nel caso in cui siano state concesse autorizzazioni
specifiche.
In questa sezione viene mostrato un esempio di utilizzo di ciascun metodo sia in Visual
Basic, sia in Transact-SQL. Il seguente codice Transact-SQL concede agli utenti Bob e
Jane l’autorizzazione SELECT per la tabella authors e all’utente Jane viene concessa
anche l’autorizzazione INSERT per la tabella titles.
/* Grant permissions to SELECT. */
GRANT SELECT
ON authors
TO Bob, [REDMOND\Jane]
GO
/* Grant permissions to INSERT. */
GRANT INSERT
ON titles
TO [REDMOND\Jane]
GO
Nell’esempio precedente l’istruzione GRANT viene utilizzata per concedere autorizzazioni
sia a un utente definito esplicitamente a livello di database (Bob), sia a un utente di
Windows (Jane).
30
Di seguito è riportato lo stesso esempio in Visual Basic.
‘ Declare variables.
Dim oServer As SQLDMO.SQLServer
‘ Create a server object and connect.
Set oServer = CreateObject(“SQLDMO.SQLServer”)
oServer.Connect (“SERVERNAME”)
‘ Grant Jane and Bob permissions to select from the authors table.
oServer.Databases(“pubs”).Tables(“authors”).Grant SQLDMOPriv_Select, “Bob”
oServer.Databases(“pubs”).Tables(“authors”).Grant SQLDMOPriv_Select, _
“[REDMOND\Jane]
‘ Grant Jane permissions to select from the authors table.
oServer.Databases(“pubs”).Tables(“authors”).Grant SQLDMOPriv_Select, _
“[REDMOND\Jane]”
Negli esempi precedenti la differenza tra la concessione dell’accesso mediante l’utilizzo
del nome di dominio completo dell’utente e la concessione dell’accesso a un utente già
autorizzato ad accedere direttamente al database è minima. Proprio per questo, negli
esempi che seguono viene mostrato solo il codice relativo agli utenti già impostati per
il database.
La seguente istruzione Transact-SQL permette di negare l’autorizzazione SELECT a un
utente.
/* Deny permissions to SELECT. */
DENY SELECT
ON authors
TO Bob
GO
And again using Visual Basic:
‘ Declare variables.
Dim oServer As SQLDMO.SQLServer
‘ Create a server object and connect.
Set oServer = CreateObject(“SQLDMO.SQLServer”)
oServer.Connect (“SERVERNAME”)
‘ Deny Bob permissions to select from authors table.
oServer.Databases(“pubs”).Tables(“authors”).Deny SQLDMOPriv_Select, “Bob”
31
L’esempio di codice Transact-SQL che segue mostra invece come revocare le
autorizzazioni concesse a un utente.
/* Revoke permissions to SELECT. */
REVOKE SELECT
ON authors
FROM Bob
GO
Here is the Visual Basic code:
‘ Declare variables.
Dim oServer As SQLDMO.SQLServer
‘ Create a server object and connect.
Set oServer = CreateObject(“SQLDMO.SQLServer”)
oServer.Connect (“SERVERNAME”)
‘ Revoke Bob permissions to select from the authors table.
oServer.Databases(“pubs”).Tables(“authors”).Revoke SQLDMOPriv_Select,
“Bob”
Catene di proprietà
Per sviluppare un ambiente SQL Server 2000 sicuro è essenziale comprendere
a fondo cosa sono le catene di proprietà. Le catene di proprietà vengono definite
durante la verifica delle autorizzazioni relative agli oggetti. Ad esempio, quando
un utente accede a una vista, vengono controllale le autorizzazioni per la vista,
ma occorre anche stabilire come devono essere controllate le autorizzazioni relative
alla tabella sottostante.
SQL Server 2000 controlla sempre le autorizzazioni per gli oggetti quando rileva
una catena di proprietà interrotta, ossia quando il proprietario dell’oggetto è diverso
da quello degli oggetti sottostanti. Se ad esempio l’utente Mary crea una vista
basata su una tabella creata dall’utente Bob, la catena di proprietà si interrompe.
I punti di interruzione delle catene di proprietà indicano pertanto i punti in cui
è necessario eseguire un ulteriore controllo delle autorizzazioni, oltre a quello già
eseguito per l’oggetto al quale è stato originariamente effettuato l’accesso. Questo
consente di ottenere un modello estremamente pratico.
Per meglio illustrare il concetto di catena di proprietà, conviene ricorrere a un
esempio. Si supponga che Bob sia proprietario di una tabella e che per proteggere
l’accesso a tale tabella conceda l’autorizzazione SELECT solo all’utente Mary. Per
svolgere il suo lavoro, Mary crea una vista della tabella e l’utente Sue, osservando
Mary, chiede di utilizzare la stessa vista. Mary decide di concedere a Sue l’accesso
alla vista, ma ciò è in contrasto con le intenzioni di Bob, che non desidera
consentire a Sue di visualizzare i dati della tabella. In questo caso la catena di
proprietà è interrotta, poiché la tabella appartiene a Bob e la vista appartiene
32
a Mary. Poiché la proprietà di una vista non implica la proprietà degli oggetti
sottostanti, quando Sue tenta di utilizzare la vista e SQL Server verifica le
autorizzazioni per stabilire se Sue sia autorizzata ad accedervi, poiché la catena
di proprietà è interrotta vengono controllate anche le autorizzazioni relative alla
tabella.
Se Sue non è autorizzata ad accedere alla tabella, non può utilizzare la vista, perché
la catena di proprietà è interrotta. In pratica, una catena di proprietà interrotta
impedisce agli utenti di accedere ai dati senza averne l’autorizzazione.
Se invece la vista appartenesse a Bob e quest’ultimo decidesse di negare a Sue
l’accesso alla tabella, ma di concederle l’accesso alla vista, Sue potrebbe acce dere
alla vista. Infatti, poiché le autorizzazioni vengono controllate solo quando Sue
accede alla vista e in questo caso non è presente alcuna interruzione della catena
di proprietà, le autorizzazioni per la tabella sottostante non vengono controllate.
Pertanto, poiché Bob ha creato entrambi gli oggetti, concedendo l’accesso alla vista
autorizza implicitamente Sue ad accedere agli oggetti sottostanti.
SQL Server 2000 sfrutta le potenzialità offerte dalle catene di proprietà ad esempio
nell’implementazione delle password. Gli utenti non possono aggiornare
direttamente le tabelle di sistema, soprattutto quelle contenute nel database
master. Quando si utilizza SQL Server 2000 in modalità mista, le coppie nome
utente/password vengono memorizzate nella tabella di sistema sysxlogins.
Poiché gli utenti devono avere la possibilità di modificare le password a intervalli
regolari, in SQL Server 2000 è stata implementata una stored procedure per
modificare la password, che può essere eseguita da qualsiasi utente. In questo
modo, gli utenti non possono accedere alla tabella sysxlogins, ma sono autorizzati
a eseguire la stored procedure sp_password. Poiché il proprietario della stored
procedure sp_password coincide con quello della tabella di sistema sysxlogins,
la catena di proprietà non viene interrotta e le autorizzazioni vengono controllate
solo per la stored procedure.
Grazie alle catene di proprietà, è pertanto possibile implementare in SQL Server
2000 un sistema di protezione che attribuisce al proprietario dei dati originali il
controllo completo sulla concessione delle autorizzazioni di accesso ai propri dati.
Inoltre, poiché se la catena di proprietà non viene interrotta non è necessario
verificare le autorizzazioni, si ottiene anche un miglioramento delle pres tazioni.
33
Implementazione della protezione a livello
di server
Utilizzo di identificatori di protezione (SID)
SQL Server 2000 verifica se all’identificatore di protezione (SID, Security Identifier)
dell’utente, o ai SID di appartenenza a un gruppo, è stato espressamente negato
l’accesso al server, poiché in questo caso l’utente non può accedere al server. Se
invece l’accesso non è stato espressamente negato, il server verifica se l’accesso
è stato concesso direttamente all’utente o se deriva dalla sua appartenenza a un
gruppo. Se l’accesso è stato concesso, la connessione a SQL Server 2000 viene
mantenuta e l’utente può utilizzare il database predefinito appropriato, per il quale
deve disporre di un’apposita autorizzazione di accesso. Vengono quindi controllati i
diritti di accesso relativi a tutti gli oggetti a cui l’utente tenta di accedere. Se invece
per un determinato insieme di credenziali l’accesso non è consentito, la connessione
al server viene interrotta.
Quando a un utente o a un gruppo di Windows NT 4.0 viene concesso o negato
l’accesso a SQL Server 2000, le relative informazioni vengono archiviate nella tabella
di sistema sysxlogins. L’accesso al server non viene più controllato attraverso le
autorizzazioni per una determinata chiave del Registro di sistema, ma gli utenti che si
connettono tramite una connessione trusted vengono identificati da SQL Server 2000
tramite i relativi SID e i SID di appartenenza ai gruppi.
Eliminazione dei SUID (Server User ID)
In SQL Server 2000 la tabella di sistema sysxlogins del database master non
contiene più la colonna SUID (Server User ID), che in SQL Server 6.5 e versioni
precedenti veniva utilizzata per tenere traccia della protezione. In SQL Server 7.0,
questa colonna era presente anche in molte altre tabelle di sistema.
La colonna <name> è stata invece rimossa dalle seguenti tabelle di sistema:

Sysdatabases

Syslogins

Sysremotelogins

Sysusers

Sysprocesses
È stata completamente rimossa anche la vista sysalternates, mentre le funzioni
SUSER_ID() e SUSER_NAME() sono state dichiarate obsolete e, se chiamate,
restituiscono sempre NULL.
34
Generazione di GUID per utenti non trusted
Per le connessioni non trusted, come quelle create quando SQL Server 2000 è installato
in Windows 98, i SID di Windows non sono disponibili. In questo caso, SQL Server 2000
genera un identificatore univoco globale (GUID, Globally Unique Identifier) di 16 byte,
che viene utilizzato internamente come avviene per i SID di Windows associati agli
utenti e ai gruppi di Windows. Il funzionamento del sistema di protezione negli ambienti
trusted e non trusted è pertanto identico.
Ridenominazione di account di Windows
relativi a utenti o gruppi
Se un utente o un gruppo di Windows viene rinominato mediante lo strumento User
Manager for Domains di Windows NT 4.0 o con l’utilità Utenti e computer di Active
Directory, tale modifica non viene rilevata da SQL Server 2000. Per ottimizzare le
prestazioni, in SQL Server 2000 il nome completo dell’utente o del gruppo viene
memorizzato nella tabella sysxlogins, poiché l’esecuzione di query sul domain
controller per ottenere queste informazioni può richiedere molto tempo, in particolare
se le ricerche sono molte o il domain controller utilizza una connessione WAN lenta.
Eventuali differenze nei nomi di utenti e gruppi tra SQL Server 2000 e Windows non
determinano problemi di protezione. Infatti, poiché SQL Server utilizza internamente
solo i SID, il set di autorizzazioni per l’utente o il gruppo modificato continua a
funzionare correttamente.
Quando si utilizzano le funzioni SUSER_SNAME() e SUSER_SID(), che restituiscono
rispettivamente il nome e il SID dell’utente, per effettuare la risoluzione dei nomi viene
eseguita una query sulla tabella sysxlogins e tale query viene inoltrata all’autorità di
protezione locale (LSA, Local Security Authority) di Windows8 solo se la tabella
sysxlogins non contiene il nome utente o il SID.
Per questa ragione, i nomi utente visualizzati nei messaggi di sistema potrebbero non
essere aggiornati.
8
Per ulteriori informazioni, vedere Windows NT Resource Kit.
35
Tabella di sistema sysxlogins
Nella tabella di sysxlogins sono riportate le autorizzazioni di accesso degli utenti
o l’eventuale assenza di autorizzazione9. Questa tabella è presente solo nel database
master.
In SQL Server 2000 sono disponibili tre viste basate sulla tabella sysxlogins:

La vista syslogins, che fornisce la compatibilità con le versioni precedenti
e interpreta al tempo stesso la colonna status, in modo da semplificarne
la comprensione.

La vista sysremotelogins, che fornisce la compatibilità con le versioni precedenti
e semplifica l’accesso alle informazioni relative agli account di accesso remoto.

La vista sysoledbusers, che contiene informazioni sugli account di accesso remoto.
Colonna xstatus
La colonna xstatus contiene varie impostazioni relative allo stato, come l’appartenenza
ai ruoli del server. I valori di stato disponibili sono riportati nella tabella che segue
(figura 7).
Valore
Bit10
Note
Denylogin
1
--
Hasaccess
2
--
Isntname
3
Se ha valore 1, significa che si tratta di un
account
di Windows
Isntgroup
3
Solo se il bit di stato 4 non è impostato
Isntuser
4
Deve essere impostato anche il bit di stato 3
Sysadmin
5
Ruolo del server
Securityadmin
6
Ruolo del server
Serveradmin
7
Ruolo del server
Setupadmin
8
Ruolo del server
Processadmin
9
Ruolo del server
Diskadmin
10
Ruolo del server
Dbcreator
11
Ruolo del server
Bulkadmin
12
Ruolo del server
Figura 7: valori di stato per la protezione di SQL Server 2000.
In SQL Server 6.5 e versioni precedenti, queste informazioni erano archiviate nella
tabella di sistema syslogins. Per garantire la compatibilità con le versioni precedenti è
ancora possibile eseguire query su syslogins, che nella nuova versione costituisce una
vista della tabella sysxlogins. Questa vista non è in genere necessaria, poiché è
preferibile evitare di accedere direttamente alle tabelle di sistema. Le tabelle di sistema
possono essere modificate in qualsiasi momento.
9
10
36
Bit: posizione del bit di stato procedendo da destra a sinistra.
Colonne dbid e language
Il meccanismo utilizzato per recuperare le impostazioni relative alla lingua e al
database predefiniti dell’utente è poco conosciuto. Quando un utente si connette a
SQL Server 2000 il server cerca nella tabella sysxlogins la riga contenente il SID
oppure il GUID, se la connessione non è trusted, specifico dell’utente. Le impostazioni
relative alla lingua e al database predefiniti vengono ricavate dalla riga individuata.
Se tale riga non viene trovata, il server cerca i SID dei gruppi a cui l’utente
appartiene e utilizza la lingua e il database predefiniti impostati per il primo gruppo
trovato. Questa implementazione è specifica di ciascuna impostazione predefinita.
Se per il primo gruppo individuato è impostata la lingua predefinita ma il database
predefinito è NULL, SQL Server passa al gruppo successivo e tenta di ottenere il
database predefinito da tale gruppo.
Se ad esempio per l’utente Bob, appartenente ai gruppi SALES e MARKETING, la
lingua e il database predefiniti non sono stati espressamente configurati, il sistema
cerca le impostazioni predefinite dei gruppi SALES e MARKETING e utilizza le prime
impostazioni restituite.
Pertanto, se per un utente che appartiene a più gruppi la lingua e il database
predefiniti non sono stati impostati, non è possibile garantire la scelta univoca di
tali impostazioni.
È tuttavia possibile assegnare la lingua e il database predefiniti a un utente senza
concedergli espressamente i diritti di accesso. L’utente è infatti autorizzato ad
accedere a SQL Server in virtù dell’appartenenza a determinati gruppi, ma le relative
impostazioni predefinite vengono prelevate dalla voce della tabella di sistema
sysxlogins associata all’utente. In questo caso, per la voce della tabella sysxlogins
specifica dell’utente il flag hasaccess della tabella sysxlogins viene impostato
su zero.
Stato hasaccess
Lo stato hasaccess della tabella di sistema sysxlogins consente di configurare le
impostazioni predefinite per un utente specifico senza concedere implicitamente
l’accesso a tale utente. La tabella sysxlogins viene in genere utilizzata per concedere
diritti di accesso a determinati utenti o gruppi. Se il bit di stato hasaccess ha valore
zero, all’utente non viene concesso esplicitamente l’accesso, ma se si connette come
membro di un gruppo disporrà delle impostazioni predefinite appropriate.
Lo stato hasaccess è importante anche per un altro motivo, che può essere chiarito
con un esempio. Se Bob, che appartiene al gruppo REDMOND\SALES, non è
espressamente autorizzato ad accedere a SQL Server 2000, nella tabella sysxlogins
non sono presenti voci corrispondenti a tale utente, ma quest’ultimo può comunque
effettuare l’accesso, perché il gruppo REDMOND\SALES dispone delle autorizzazioni
necessarie. Se Bob viene aggiunto a un ruolo predefinito del server, non ottiene
automaticamente l’autorizzazione ad accedere direttamente a SQL Server, ma
continua a effettuare l’accesso tramite il gruppo SALES. In questo caso, nella tabella
sysxlogins viene aggiunta una nuova riga per Bob, ma il flag hasaccess viene
impostato su zero in modo da concedere l’appartenenza al ruolo appropriato del
server, senza tuttavia concedere implicitamente l’accesso al server.
La tabella sysxlogins può contenere voci che non implicano la concessione esplicita
dell’accesso a un utente o a un gruppo anche quando è impostato il flag denylogin.
37
Stato denylogin
Lo stato denylogin consente di contrassegnare un utente o un gruppo in modo che
gli venga esplicitamente negato l’accesso a SQL Server 2000. Per impedire a un utente
o a un gruppo specifico di accedere a SQL Server, è ad esempio possibile utilizzare la
seguente istruzione Transact-SQL:
Exec sp_denylogin ‘REDMOND\Bob’
che non corrisponde a:
Exec sp_revokelogin ‘REDMOND\Bob’
Infatti, mentre la prima istruzione nega l’accesso a SQL Server, la seconda revoca
l’accesso all’account specificato. Se l’utente è membro del gruppo MARKETING,
che dispone dell’accesso, la seconda istruzione non impedisce a Bob di continuare
ad accedere al server tramite il gruppo MARKETING, mentre la prima nega l’accesso
a tale utente anche se quest’ultimo appartiene a gruppi a cui è stato concesso.
Nota: nei sistemi operativi Windows, per impedire a un determinato utente di
accedere a una risorsa è sufficiente un’istruzione DENY.
Vista sysremotelogins
La vista sysremotelogins viene fornita per compatibilità con le versioni precedenti.
In SQL Server 6.5 e versioni precedenti, infatti, il mapping degli account di accesso
remoto era impostato in una tabella di nome sysremotelogins.
Vista sysoledbuser
Quando un utente tenta di eseguire una query su un server remoto, il server locale
deve accedere al server collegato per conto dell’utente.
Per aggiungere ai server remoti nuovi account collegati viene utilizzata la stored
procedure sp_addlinkedsrvlogin e le informazioni corrispondenti vengono archiviate
nella tabella sysxlogins. Per eseguire la stored procedure è necessario specificare
come parametri il nome del server remoto, il nome utente locale, il nome utente
remoto e la password remota.
38
Implementazione della protezione a livello
di oggetto
Controllo delle autorizzazioni
Per identificare gli utenti e i gruppi di Windows, SQL Server 2000 utilizza i SID.
Tuttavia, data la lunghezza dei SID, fino a 85 byte, all’interno dei singoli database SQL
Server 2000 esegue il mapping dei SID sugli ID nella tabella sysusers. Gli ID utente
mappati vengono quindi utilizzati nella tabella sysobjects per identificare i proprietari
delle varie tabelle, nella tabella syspermissions per impostare le autorizzazioni per gli
oggetti e nella tabella systypes per identificare i proprietari dei tipi definiti dall’utente.
Quando un utente si connette a SQL Server 2000, il server crea in memoria una
struttura di stato del processo (PSS, Process Status Structure) 11, che contiene il SID
dell’utente, i SID di gruppo e altre informazioni relative allo stato e alla protezione.
Questa struttura è uno snapshot creato al momento della connessione dell’utente, mai
aggiornato e specifico della sessione di connessione al server. A un singolo utente che
stabilisca più sessioni con SQL Server 2000 corrispondono pertanto più strutture PSS.
Se l’utente accede a un database, SQL Server controllata la tabella sysusers per
stabilire se all’utente sia stato negato l’accesso, direttamente oppure perché appartiene
a un gruppo a cui è stato negato. Se all’utente è stato negato l’accesso, tale restrizione
verrà subito applicata, in caso contrario verrà eseguito un ulteriore controllo nella
tabella sysusers, questa volta utilizzando tutti gli ID utente associati all’utente. Una
volta stabilito che l’utente è autorizzato ad accedere al database, viene analizzata la
tabella sysmembers per consentire l’impostazione di tutte le appartenenze ai ruoli per
l’utente. L’utente può ad esempio essere membro di un ruolo, membro di un gruppo di
Windows o utilizzare l’alias di un altro utente. Vengono individuati gli ID utente di tutte
le appartenenze applicabili, in modo da utilizzare le autorizzazioni appropriate per
l’utente. Diversamente dalle strutture PSS, queste informazioni non sono persistenti.
Quando l’utente inizia ad accedere agli oggetti del database, le autorizzazioni applicabili
vengono determinate cercando nella tabella syspermissions le voci con ID utente
corrispondenti, in base a quanto stabilito in precedenza. Vengono controllate per prime
le autorizzazioni DENY, poiché se sono presenti l’utente non può accedere all’oggetto
richiesto. Se non vengono individuate autorizzazioni DENY e sono presenti voci che
autorizzano l’utente ad accedere all’oggetto richiesto, l’accesso viene invece consentito.
Le autorizzazioni di accesso effettive vengono quindi memorizzate nella cache, per
evitare di ripetere l’intero processo di controllo in caso di accesso ripetuto.
A questa struttura viene fatto riferimento in numerosi messaggi di errore generati da
SQL Server 7.0.
11
39
Costo della modifica delle autorizzazioni
Come spiegato in precedenza, in SQL Server 2000 le autorizzazioni relative agli oggetti
vengono memorizzate nella cache della sessione, per evitare di ripetere l’intero
processo di controllo in caso di accesso ripetuto agli stessi oggetti. Diversamente dalla
struttura PSS, in cui le informazioni di protezione non vengono più modificate dopo la
creazione, la cache delle autorizzazioni viene continuamente aggiornata utilizzando il
metodo del controllo delle versioni.
Durante il controllo iniziale delle autorizzazioni viene definito un numero di versione.
Quando le autorizzazioni per un oggetto vengono modificate, SQL Server 2000
incrementa un contatore di versione, che viene controllato a ogni accesso all’oggetto.
Se tale contatore è diverso da quello memorizzato nella cache, il contenuto della cache
viene eliminato e le autorizzazioni effettive vengono ridefinite.
Le impostazioni di protezione memorizzate nella cache vengono utilizzate ogni volta che
l’utente accede a un determinato oggetto, purché il contatore della versione sia rimasto
invariato. Se il contatore risulta modificato, l’operazione da eseguire richiede un
overhead limitato.
Ridenominazione di account di Windows
relativi a utenti o gruppi
In SQL Server 2000 è possibile concedere ai gruppi e agli utenti di Windows le
autorizzazioni necessarie per accedere direttamente agli oggetti di un database. In
questo caso, il SID e i nomi degli utenti e dei gruppi di Windows vengono memorizzati
nella tabella sysusers.12
Quando l’amministratore di Windows rinomina un gruppo o un utente di Windows, la
modifica del nome non viene propagata a SQL Server 2000.
Sebbene questo possa sembrare un problema, consente in realtà di evitare una
notevole confusione.
Infatti, come nelle versioni precedenti, anche in SQL Server 2000 amministratori e
sviluppatori creano numerosi script Transact-SQL, trigger, stored procedure e così via.
Si supponga ad esempio che l’utente Susie Jones crei una tabella in un database. Il
nome di accesso di Susie è SUSIEJ e la tabella viene denominata
SUSIEJ.SALESDEMO. Susie concede ad altri utenti le autorizzazioni di accesso alla
propria tabella e molti colleghi creano viste e stored procedure basate su tale tabella. Si
supponga ora che, in seguito al matrimonio di Susie con Bob Taylor, il nome utente
venga modificato in SUSIET. Se la modifica venisse rilevata da SQL Server 2000, la
tabella di Susie verrebbe automaticamente rinominata in SUSIET.SALESDEMO e
costituirebbe quindi un oggetto completamente diverso.
Di conseguenza, le viste, le stored procedure e tutto il codice normalmente utilizzato
per accedere alla tabella smetterebbero di funzionare.
La ridenominazione degli account reali in Windows non viene automaticamente
propagata in SQL Server 2000 proprio per garantire una maggiore stabilità.
Per informazioni sul problema della ridenominazione in relazione ai nomi di accesso,
vedere la precedente sezione “Ridenominazione di account di Windows relativi a utenti
o gruppi” del presente documento.
12
40
Rimozione della tabella di sistema
sysprocedures
In SQL Server 6.5 e versioni precedenti, quando veniva creata una stored procedure il
testo della query veniva memorizzato nella tabella di sistema syscomments e nella
tabella di sistema sysprocedures veniva salvata una struttura di query normalizzata.
Durante il processo di normalizzazione, le istruzioni SQL venivano analizzate in modo
da ottenere formati più efficienti e gli oggetti a cui veniva fatto riferimento venivano
risolti nelle relative rappresentazioni interne. Alla successiva esecuzione della stored
procedure, la struttura veniva recuperata dalla tabella sysprocedures e utilizzata
come base per un piano di esecuzione ottimizzato, che veniva a sua volta memorizzato
nella cache delle procedure.13
Anche se apparentemente non esiste alcun legame tra questo processo e la protezione,
alcuni sviluppatori di software14 rimuovevano il testo SQL originale da syscomments
allo scopo di proteggere il codice sorgente. In effetti, il testo SQL originale non veniva
in genere riutilizzato fino al successivo aggiornamento del server a una nuova versione
di SQL Server o all’applicazione di un service pack. Per nascondere in modo più
efficiente il testo SQL originale agli utenti a cui non si desidera consentire l’accesso,
nella versione 6.0 di SQL Server Microsoft ha introdotto l’opzione WITH ENCRYPTION,
che consente di crittografare il testo SQL originale al momento della creazione della
stored procedure.
In SQL Server 7.0 e SQL Server 2000, invece, se un amministratore elimina le voci
appropriate dalla tabella syscomments, la stored procedure non può essere eseguita,
poiché in SQL Server 2000 la tabella sysprocedures è stata rimossa e il testo SQL
viene recuperato direttamente dalla tabella syscomments prima dell’esecuzione.
Opzione WITH GRANT
WITH GRANT è un’opzione facoltativa che può essere utilizzata con l’istruzione GRANT.
Tale opzione, che può essere applicata solo alle autorizzazioni per gli oggetti, consente
al destinatario dell’istruzione GRANT di trasferire ad altri tale autorizzazione.
Se ad esempio Bob ha utilizzato l’opzione WITH GRANT per concedere autorizzazioni
SELECT a Jane, quest’ultima potrà concedere autorizzazioni SELECT ad altri utenti.
Se Bob decide di revocare le autorizzazioni SELECT a Jane, può utilizzare l’opzione
CASCADE per revocare anche le autorizzazioni SELECT concesse da Jane ad altri utenti.
Questo approccio veniva utilizzato anche per le viste, le impostazioni predefinite,
le regole, i trigger e i vincoli CHECK e DEFAULT.
13
14
41
In particolare nelle versioni precedenti a SQL Server 6.0.
Tabella di sistema sysusers
Per alcuni aspetti, la tabella sysusers svolge per il database la stessa funzione svolta
dalla tabella sysxlogins per il server. La tabella sysusers, presente in ogni database,
contiene infatti le informazioni relative agli utenti a cui è concesso o negato l’accesso al
database.
Colonna hasdbaccess
La colonna hasdbaccess funziona in modo analogo alla colonna hasaccess della
tabella sysxlogins. In questo caso, il flag viene impostato su zero quando un utente
crea oggetti senza disporre di diritti di accesso al database concessi in modo esplicito,
viene autorizzato in modo esplicito oppure viene aggiunto a un ruolo in modo esplicito.
Gli oggetti creati da un determinato utente appartengono sempre a quest’ultimo, e non
al gruppo attraverso il quale l’utente ha effettuato l’accesso al database,15 a meno che
un utente appartenente a un ruolo o a un gruppo di Windows non indichi esplicitamente
il ruolo o il gruppo come proprietario dell’oggetto al momento della creazione di
quest’ultimo.16 In tal caso, affinché per l’oggetto venga impostato il proprietario
corretto, è necessario creare una voce per l’utente nella tabella sysusers. La voce
viene creata automaticamente, ma poiché il flag hasaccess è impostato su zero,
l’utente non ottiene l’accesso esplicito al database.
La colonna hasdbaccess è impostata su zero anche per i ruoli, ugualmente elencati
nella tabella sysusers.
Tabella di sistema sysmembers
La tabella di sistema sysmembers, una delle più piccole, contiene solo due colonne
e viene utilizzata per registrare l’appartenenza degli utenti ai ruoli del database.
Questa tabella contiene una riga per ogni membro di un ruolo del database.
Per migliorare le prestazioni legate ai ruoli, in SQL Server 2000 la prima
appartenenza di un determinato utente a un ruolo viene inserita nella colonna gid
della tabella sysusers. In questo modo, quando SQL Server 2000 tenta di identificare
tutti i ruoli a cui appartiene un determinato utente, se la colonna gid della tabella
sysusers ha valore zero non è necessario eseguire una query sulla tabella
sysmembers. Se invece il valore della colonna è diverso da zero, significa che la
voce specifica un ruolo ed è necessario eseguire una query sulla tabella sysmembers
per ottenere l’elenco completo dei ruoli a cui l’utente appartiene.
Questo è importante, perché un utente può essere membro di più gruppi. In questo
caso non è infatti possibile determinare automaticamente il gruppo da impostare come
proprietario dell’oggetto.
15
16
Di seguito è riportato un esempio di sintassi valida:
CREATE TABLE [builtin\administrators].test_table(acolumn VARCHAR(2))
42
Tabella di sistema syspermissions
La tabella di sistema syspermissions, presente in tutti i database, è stata introdotta
in SQL Server 7.0. Nelle versioni precedenti tutte le autorizzazioni venivano gestite
utilizzando la tabella di sistema sysprotects. La tabella syspermissions viene
attualmente utilizzata per tenere traccia delle autorizzazioni concesse o negate agli
utenti. Per ulteriori informazioni sulla compatibilità con la tabella sysprotects delle
versioni precedenti, vedere la sezione “Tabella di sistema sysprotects”.
La tabella di sistema syspermissions contiene un numero di colonne piuttosto
limitato. La colonna id fa riferimento agli ID di oggetto per cui sono state concesse
o negate le autorizzazioni. Per le autorizzazioni relative alle istruzioni, questa colonna
è impostata su zero.
Le colonne grantor e grantee indicano l’utente che concede le autorizzazioni e
il beneficiario, identificati specificando l’ID del ruolo, dell’utente di Windows o del
gruppo di Windows, secondo quanto riportato nella tabella sysusers.
La colonna actadd fa riferimento alle autorizzazioni concesse per tutte le colonne
dell’oggetto, se si tratta di una tabella, mentre la colonna actmod fa riferimento
alle autorizzazioni negate per tutte le colonne dell’oggetto, sempre nel caso di una
tabella.
Le restanti colonne vengono utilizzate solo se vengono implementate autorizzazioni
a livello di colonna. La colonna seladd viene utilizzata per le autorizzazioni SELECT
concesse e contiene una mappa di bit delle colonne per le quali è stato concesso
questo tipo di autorizzazione. Poiché gli ID delle colonne non vengono mai riutilizzati,
l’approccio basato sulla mappa di bit risulta estremamente efficiente. La colonna
selmod contiene invece le autorizzazioni SELECT negate.
Le due colonne successive vengono utilizzate in modo analogo alle precedenti, ma
riguardano le autorizzazioni UPDATE.
Le ultime due colonne si riferiscono alle autorizzazioni REFERENCES e vengono
implementate come le quattro precedenti.
Tabella di sistema sysprotects
L’implementazione della tabella di sistema sysprotects è stata modificata rispetto alle
versioni precedenti. In SQL Server 6.5 e versioni precedenti, nella tabella sysprotects
venivano memorizzate le autorizzazioni per gli oggetti, mentre in SQL Server 7.0 e SQL
Server 2000 queste informazioni vengono memorizzate nella tabella syspermissions.
In genere, nei casi in cui è stata modificata l’implementazione di una tabella di sistema
Microsoft ha fornito una vista per garantire la compatibilità con le versioni precedenti.
Ad esempio, nel caso della tabella master..sysxlogins per garantire la compatibilità
con le versioni precedenti viene ora fornita la vista syslogins.
Nel caso della tabella di sistema sysprotects, tuttavia, poiché la tabella di sistema
sottostante è stata modificata in modo più radicale, non è stato possibile creare una
vista in grado di fornire la compatibilità con le versioni precedenti in modo efficiente.
Per questo motivo, anziché implementare la vista sysprotects Microsoft ha preferito
creare una speciale tabella di nome sysprotects, che viene rilevata dal sistema come
una tabella qualsiasi, ma che in realtà viene creata dinamicamente secondo le
esigenze.
43
Poiché non dispone di pagine di dati persistenti, la tabella sysprotects ha pertanto un
funzionamento analogo a quello delle viste, che viene implementato dal motore di
database, e l’oggetto sysprotects appare come una tabella contenuta nella tabella
sysobjects.
Autorizzazioni Named Pipes
e Multiprotocol
Per comprendere il funzionamento della protezione interna di SQL Server 2000,
è importante comprendere un concetto chiave spesso trascurato. Sebbene non
costituisca una novità di SQL Server 2000, tale concetto viene illustrato in questo
contesto per fornire una trattazione più completa.
La libreria di rete Named Pipes rappresenta un meccanismo di comunicazione tra
processi (IPC, Inter Process Communications) che viene implementato mediante
la condivisione IPC$ in Windows. Quando un client si connette a SQL Server tramite
la libreria di rete Named Pipes, viene stabilita una connessione alla condivisione IPC$
e, in questa fase, viene eseguita anche l’autenticazione. Questo aspetto non era stato
approfondito durante la descrizione delle nuove funzionalità di protezione. Dopo
l’autenticazione del client da parte di Windows, che viene eseguita come per l’accesso
a qualsiasi altra risorsa, viene creata una sessione Named Pipes basata sulla
condivisione IPC$. Tale operazione viene completata prima di tentare il passaggio
della connessione a SQL Server.
Tutti gli utenti che effettuano la connessione a SQL Server 2000 mediante la libreria
di rete Named Pipes devono pertanto disporre di un account di Windows e delle
autorizzazioni di Windows necessarie per l’accesso alla condivisione IPC$.
Se non si desidera eseguire questo tipo di autenticazione, è necessario utilizzare
un’altra libreria di rete, come TCP/IP Sockets o Multiprotocol, poiché tali connessioni
non vengono convalidate nella condivisione IPC$ di Windows NT. TCP/IP Sockets è
la libreria di rete predefinita di SQL Server 2000.
Se si utilizza la libreria di rete Multiprotocol, l’autenticazione di Windows viene
comunque eseguita prima del passaggio della connessione a SQL Server 2000, poiché
i servizi RPC (Remote Procedure Call) di runtime effettuano l’autenticazione del client
quando viene richiesta la connessione. Pertanto, come per la libreria di rete Named
Pipes, per Multiprotocol è necessario un account di Windows valido.
Si noti tuttavia che la libreria di rete Multiprotocol non consente di eseguire la
connessione alle istanze denominate di SQL Server 2000 e non è più necessaria,
poiché tutte le librerie di rete supportano la crittografia.
Per gestire gli utenti che non dispongono di un account di Windows e desiderano
connettersi mediante le librerie di rete Named Pipes o Multiprotocol, è possibile
attivare l’account guest di Windows. Quando richiedono una sessione, questi utenti
possono connettersi a Windows utilizzando l’account utente guest e tentare l’accesso
a SQL Server. Tuttavia, poiché l’attivazione dell’account guest comporta una
riduzione del livello di protezione dell’intero ambiente Windows, questa soluzione è
in genere sconsigliata. È stata illustrata in questo contesto solo come soluzione da
adottare in caso di estrema necessità.
44
Aggiornamento da SQL Server 7.0
L’architettura di protezione non è stata modificata nel passaggio da SQL Server 7.0
a SQL Server 2000. Per informazioni sulle nuove funzionalità di protezione di SQL
Server 2000, vedere la sezione “Nuove funzionalità di protezione di SQL Server 2000”
del presente documento.
Aggiornamento da SQL Server 6.5
Il modello di protezione di SQL Server 6.5, diverso da quello di SQL Server 6.0, è stato
ulteriormente modificato in SQL Server 2000 allo scopo di rendere più pratico
l’ambiente di lavoro di SQL Server. A causa di questa modifica, quando si esegue
l’aggiornamento è necessario controllare accuratamente le autorizzazioni.
Considerazioni sull’aggiornamento
Le informazioni fornite in questa sezione sono applicabili solo all’aggiornamento dalla
modalità integrata o mista di SQL Server 6.5. L’aggiornamento da un computer che
esegue SQL Server 6.5 in modalità standard non comporta problemi di sicurezza.
Microsoft consiglia tuttavia di utilizzare nell’ambiente aggiornato le nuove funzionalità
di protezione offerte dalla modalità di autenticazione di Windows. Per garantire il
corretto aggiornamento delle impostazioni di protezione di SQL Server 6.x è necessario
pianificare accuratamente l’aggiornamento e preparare l’ambiente di sicurezza.
Processo di aggiornamento
Il processo di aggiornamento può essere eseguito direttamente in un computer oppure
in modalità remota da un altro computer. Da un punto di vista logico, l’aggiornamento
di un singolo computer equivale a un aggiornamento con due computer in cui i
computer di origine e di destinazione coincidono. Questi due computer sono detti server
di origine e server di destinazione. Nel server di origine deve essere installato SQL
Server 6.0 o SQL Server 6.5, mentre nel server di destinazione deve essere installato
SQL Server 2000.
Durante l’aggiornamento della versione viene eseguito un programma che apre la
chiave del Registro di sistema integrata in SQL Server 6.5, nel computer di origine, e
vengono letti i SID di tutti gli account a cui è stato concesso l’accesso integrato. Gli
account per cui è configurata la protezione integrata nel server di origine possono
essere costituiti da gruppi globali o locali di Windows o da utenti di Windows. Gli utenti
e i gruppi globali possono appartenere a un dominio locale, se SQL Server 2000 viene
eseguito in un member server, oppure possono essere costituiti da account di un
dominio trusted. Se SQL Server 2000 è installato in un domain controller, i gruppi locali
possono essere costituiti da gruppi locali del dominio a cui appartiene il domain
controller oppure da gruppi locali del member server.
Durante i processi di drill-down e di mapping degli account, gli account a cui sono state
concesse autorizzazioni amministrative nel server di origine vengono ignorati.
Nota: nel computer che esegue SQL Server 2000, per ciascun account di Windows
configurato per l’utilizzo della protezione integrata in SQL Server 6.5 viene eseguita
l’istruzione sp_grantlogin. Poiché lo strumento SQL Security Manager incluso in SQL
Server 6.5 eseguiva l’istruzione xp_grantlogin, il processo di aggiornamento
riproduce le operazioni effettuate nella versione precedente.
45
Analisi dell’output del processo
di aggiornamento
I problemi di protezione che emergono in seguito all’aggiornamento derivano in genere
dal fatto che, poiché in SQL Server 6.5 la protezione integrata veniva implementata
attraverso la protezione di una chiave del Registro di sistema, potevano accedere al
server solo gli utenti che avevano accesso a tale chiave. Per ulteriori informazioni,
vedere la sezione “Utilizzo di identificatori di protezione (SID)” del presente documento.
Le autorizzazioni relative alla chiave del Registro di sistema erano collegate agli
account di accesso utente memorizzati nella tabella syslogins.
In SQL Server 2000 questo metodo di protezione non viene più utilizzato, poiché
l’accesso al server viene concesso in base ai SID degli utenti o dei gruppi di Windows.
Di conseguenza, il processo di aggiornamento non è sempre in grado di identificare i
requisiti di protezione originali. Questo avviene in genere quando l’ambiente di
protezione di SQL Server non è aggiornato o l’aggiornamento è destinato a un
ambiente diverso.
La tabella che segue (figura 8) mostra come appaiono gli account di accesso in SQL
Server Enterprise Manager dopo un aggiornamento.
Nome
Tipo
Accesso
al server
Database
predefinito
utente1
Standard
Autorizzato
Master
1
a#utente2
Standard
Autorizzato
Master
2
BUILTIN\Administrators
Gruppo
Windows
Autorizzato
Master
DOM3\SQLUsers
Gruppo
Windows
Autorizzato
Master
4
DOM3_utente#3
Standard
Autorizzato
Master
5
DOM3_Administrator
Standard
Autorizzato
Master
6
REDMOND\a utente4
Utente
Windows
Tramite
gruppo
Master
7
REDMOND\utente5
Utente
Windows
Tramite
gruppo
Master
8
Utente
dbo
Riga
3
Figura 8: account di accesso visualizzati in SQL Server Enterprise Manager dopo l’aggiornamento
a SQL Server 2000.
Il contenuto della tabella è illustrato nelle sezioni successive.
Eliminazione degli utenti
Le righe 1 e 2 della tabella precedente vengono create quando gli utenti in questione
non vengono trovati nella directory degli utenti di Windows. In particolare, se la stored
procedure di sistema xp_logininfo non restituisce il nome utente, l’account viene
convertito in un account di accesso standard, come quelli riportati nelle prime due righe
della tabella. Il carattere “#” presente nella riga 2 rappresenta uno spazio, poiché in
SQL Server 6.5 e versioni precedenti i caratteri speciali non erano supportati.
46
Account dell’amministratore
Il gruppo locale BUILTIN\Administrators riportato nella riga 3 della tabella è stato
associato all’alias dell’utente dbo del database master.
Utenti dei domini trusted
La riga 4 della tabella fa riferimento al gruppo DOM3\SQLUsers, un gruppo globale di
un dominio trusted. I membri di questo gruppo dispongono di diritti di accesso di
gruppo, oltre ai diritti di accesso concessi a livello di utente nell’ambito della protezione
standard, come avviene in SQL Server 6.5 e versioni precedenti.
In questo modo è stata garantita la compatibilità con la protezione standard delle
versioni precedenti.
Si consideri ora l’account Administrator indicato nella riga 6. All’account
dell’amministratore di Windows del dominio DOM3 erano stati concessi diritti di
accesso utente prima dell’aggiornamento. Tali diritti sono stati mantenuti. Tutti gli
accessi a livello di utente verranno elaborati allo stesso modo.
Utenti del dominio predefinito corrente
Gli utenti del dominio predefinito corrente, in base alla configurazione di SQL Server 6.x
in vigore prima dell’aggiornamento, vengono aggiornati come indicato nelle righe 7 e 8.
Si notino il tipo di account e la presenza dello spazio nella riga 7. SQL Server 2000
supporta infatti l’uso di caratteri speciali nei nomi di account.
Preparazione dell’ambiente di protezione
di SQL Server 6.5
Microsoft consiglia di eliminare completamente le impostazioni di protezione prima
di eseguire l’aggiornamento. Per garantire la sincronizzazione fra tutti gli account di
Windows e SQL Server, è necessario eseguire SQL Security Manager. Se si prepara
adeguatamente dell’ambiente, le probabilità di completare correttamente
l’aggiornamento aumentano.
Monitoraggio delle singole fasi dell’aggiornamento
Monitorare il processo di aggiornamento e prevedere l’esito dell’aggiornamento dei
gruppi e degli account utente è facile, poiché la procedura di aggiornamento guidato
di SQL Server consente di sospendere il processo dopo ogni passaggio. Selezionando
l’opzione di interruzione dopo ciascun passaggio è possibile analizzare l’output delle
prime fasi dell’aggiornamento della protezione, contenuto nei file loginmap.sid e
loginmap.txt. Se il contenuto di questi file di testo non risulta corretto, è possibile
modificarlo prima di proseguire.
Nota: la modifica dei file loginmap.sid e loginmap.txt durante l’aggiornamento non
è supportata da Microsoft.
47
Problemi connessi all’aggiornamento a un nuovo dominio
Se si esegue l’aggiornamento da SQL Server 6.x mediante il metodo basato su nastro,
è necessario evitare di eseguire il backup del database in un dominio per poi effettuare
l’aggiornamento in un altro dominio, poiché la stored procedure xp_logininfo potrebbe
non trovare più gli account definiti nel dominio originale e, nel caso li trovasse, non si
tratterebbe comunque degli stessi account, ma solo di account con lo stesso nome.
I diritti di accesso verrebbero infatti gestiti come se gli account fossero stati eliminati.
Per ulteriori informazioni, vedere “Eliminazione degli utenti”.
Eliminazione della necessità di eseguire il mapping
dei caratteri
Non è necessario eseguire il mapping dei caratteri, perché SQL Server 2000 supporta
l’uso di spazi e barre rovesciate nei nomi degli account.
In SQL Server 6.5 e versioni precedenti, per gestire i nomi degli account di Windows NT
contenenti caratteri speciali, come la barra rovesciata (\), era invece necessario
configurare il mapping dei caratteri. Per questo scopo, in SQL Server 6.5 e versioni
precedenti erano disponibili i seguenti caratteri di mapping: “#”, “_” e “$”.
Evitare di utilizzare l’account sa
In SQL Server 6.5 e versioni precedenti, per eseguire la maggior parte delle attività
amministrative era necessario accedere a SQL Server utilizzando l’account
dell’amministratore di sistema (sa). Per questo motivo, l’accesso amministrativo veniva
spesso fornito a un numero di utenti elevato.
In SQL Server 2000 si consiglia di assegnare al ruolo predefinito del server sysadmin
tutti gli utenti di Windows NT a cui vengono concessi diritti di tipo sa.
Per ulteriori informazioni, vedere la sezione “Problemi connessi all’utilizzo dell’account
sa” del presente documento.
Problemi connessi all’utilizzo degli alias
Per garantire la compatibilità con le versioni precedenti SQL Server 2000 supporta l’uso
degli alias degli account utente all’interno dei database, ma nella nuova versione è
preferibile utilizzare i ruoli, che offrono funzionalità analoghe ma sono più potenti. Per
ulteriori informazioni, vedere la sezione “Ruoli definiti dall’utente” del presente
documento.
48
Protezione dell’installazione
di SQL Server 2000
Le informazioni presentate in questa sezione sono applicabili esclusivamente alle
installazioni di SQL Server 2000 in Windows NT o Windows 2000, poiché gli ambienti
Windows 98 e Windows Me non dispongono delle funzionalità di protezione illustrate.
In questa sezione si presuppone che SQL Server 2000 sia stato configurato con la
modalità di autenticazione di Windows, come previsto dall’installazione predefinita, che
offre il livello di protezione massimo.
Problemi connessi all’utilizzo dell’account sa
Per concedere l’accesso a SQL Server a tutti gli amministratori di SQL Server è
consigliabile utilizzare l’appartenenza ai gruppi di Windows, definendo questi ultimi
come membri del ruolo sysadmin del server. Questo approccio presenta un piccolo
svantaggio perché, avendo la possibilità di aggiungere utenti ai gruppi di Windows, gli
amministratori di Windows possono attribuire le autorizzazioni sysadmin di SQL Server
2000 a qualsiasi utente.
Se in un determinato sito si desidera evitare che gli amministratori di Windows possano
ottenere o fornire ad altri l’accesso sysadmin a SQL Server, è necessario assegnare al
ruolo sysadmin solo singoli account di Windows.
In ogni caso, è preferibile evitare di utilizzare l’account sa per l’amministrazione
quotidiana e assegnare a tale account una password difficilmente violabile, da
conservare in cassaforte e utilizzare solo in caso di emergenza.
Se si esegue SQL Server 2000 in modalità di autenticazione di Windows, come
suggerito nel presente documento, non è possibile accedere mediante l’account sa,
poiché sono consentite solo connessioni trusted.
Nota: sebbene l’account sa non possa essere utilizzato per accedere a SQL Server
2000 quando si utilizza la modalità di autenticazione mista, è comunque importante per
assegnare una password a tale account, poiché basta una piccola modifica al Registro
di sistema per passare dalla modalità di autenticazione alla modalità mista. 17 Se
l’account sa non dispone di password, come previsto dall’installazione predefinita, può
essere utilizzato da un utente non autorizzato o dall’amministratore di Windows per
accedere al server. Per informazioni su come ridurre la probabilità di un attacco di
questo tipo, vedere la sezione “Registro di sistema”.
17
La modalità di accesso è configurata nella seguente chiave del Registro di sistema:
HKLM/Software/microsoft/MSSQLServer/MSSQLServer/LoginMode
Il valore è 0 corrisponde alla modalità mista, mentre il valore 1
corrisponde alla modalità di autenticazione di Windows.
49
Account di servizio
SQL Server 2000 è costituito da tre servizi di Windows:

MSSQLServer oppure MSSQL$InstanceName (per le istanze denominate).
È il motore che fornisce le funzionalità principali di SQL Server.

SQLServerAgent oppure SQLAgent$InstanceName (per un’istanza denominata).
Fornisce le funzionalità per la pianificazione dei comandi e delle repliche regolari,
un metodo per la gestione degli errori, la possibilità di contattare gli operatori di
SQL Server in caso di errore e altre funzioni di supporto.

Servizio Microsoft Search. Fornisce la funzionalità di ricerca full-text. Questo
servizio deve essere sempre configurato in modo da utilizzare l’account di sistema
locale.
I servizi SQL Server e Agente SQL Server possono essere invece configurati in modo
da utilizzare uno dei seguenti tipi di account di Windows:

Account di servizio locale

Account utente locale

Account utente di dominio
Il tipo di account da utilizzare dipende dalle funzionalità di SQL Server 2000 richieste.
È possibile configurare entrambi i servizi in modo da utilizzare lo stesso account utente
di Windows.
Per modificare un account di servizio dopo l’installazione del server, è necessario
utilizzare SQL Server Enterprise Manager. Infatti, sebbene gli account dei servizi SQL
Server e Agente SQL Server possano essere modificati anche dal Pannello di controllo,
questo metodo è sconsigliato poiché non consente di mantenere la sincronizzazione dei
dettagli della configurazione per il servizio Microsoft Search.
Le modifiche eventualmente apportate alle informazioni dell’account vengono applicate
al successivo avvio del servizio. È possibile configurare i servizi SQL Server e Agente
SQL Server in modo da utilizzare account di Windows diversi, ma questa procedura è in
genere sconsigliata. In caso di modifica dell’account di servizio, le modifiche devono
essere apportate a entrambi i servizi, poiché vengono configurati separatamente.
Per ridurre gli interventi amministrativi negli ambienti multiserver, è possibile utilizzare
un unico account utente di dominio per tutti i server SQL Server 2000 dell’azienda.
50
Account di sistema locale
Se SQL Server non è configurato per la replica e non richiede l’accesso a risorse di rete,
è possibile eseguire SQL Server 2000 utilizzando l’account di sistema locale.
Per la corretta esecuzione delle attività del servizio, l’account di sistema locale utilizzato
da SQL Server 2000 deve disporre delle autorizzazioni elencate di seguito, che vengono
assegnate automaticamente dal programma di installazione.

Controllo completo sulla directory di SQL Server, che per impostazione predefinita è
\Programmi\Microsoft SQL Server\MSSQL.

Controllo completo su tutti i file di database con estensione mdf, ndf e ldf.

Controllo completo sulle seguenti chiavi del Registro di sistema e sulle relative
sottochiavi:

HKEY_LOCAL_MACHINE\Software\
Microsoft\MSSQLServer

HKEY_LOCAL_MACHINE\System\
CurrentControlset\Services\MSSQLServer

Per le istanze denominate le chiavi sono:

HKEY_LOCAL_MACHINE\Software\
Microsoft\Microsoft SQL Server\NomeIstanza

HKEY_LOCAL_MACHINE\System\
CurrentControlset\Services\MSSQL$NomeIstanza
Account utente locale
Se SQL Server 2000 è configurato per l’utilizzo di un account utente locale, vengono
applicate le stesse restrizioni impostate per il sistema locale, con il seguente requisito
aggiuntivo, concesso per impostazione predefinita dal programma di installazione:

L’account utente deve disporre dell’autorizzazione Accesso come servizio.
Account utente di dominio
La configurazione di SQL Server 2000 con un account utente di dominio garantisce il
massimo livello di flessibilità, poiché consente di usufruire, fra le altre, delle seguenti
funzionalità:

Replica

Backup e ripristino da unità di rete

Join eterogenei che coinvolgono origini dati remote

Funzioni di posta elettronica dell’Agente SQL Server e di SQL Mail
Per la corretta esecuzione delle attività di SQL Server 2000 è necessario che l’account
utente di dominio venga configurato come l’account utente locale precedentemente
illustrato. Alcune funzionalità estese, tuttavia, sono disponibili solo se si aggiungono
ulteriori autorizzazioni, come indicato nella tabella che segue (figura 9).
51
Servizio
Autorizzazione
Funzionalità
SQL Server
Autorizzazioni di scrittura in rete.
Possibilità di eseguire operazioni
di lettura e scrittura per il
caricamento dei dati, il backup
remoto e così via.
SQL Server
Agire come parte del sistema
operativo e sostituire un token a
livello di processo.
Esecuzione di xp_cmdshell
da parte di un utente diverso
dall’amministratore di SQL Server.
Agente SQL
Server
Membro del gruppo locale
Administrators.
Creazione di processi CmdExec
e ActiveScript di proprietà di utenti
diversi dall’amministratore
di SQL Server.
Agente SQL
Server
Membro del gruppo locale
Administrators.
Utilizzo della funzione di riavvio
automatico.
Agente SQL
Server
Membro del gruppo locale
Administrators.
Utilizzo dei processi eseguiti quando
il computer è inattivo.
Figura 9: autorizzazioni richieste per l’uso delle funzionalità estese di SQL Server 2000.
Per fornire a SQL Server 2000 il massimo livello di funzionalità, si consiglia di utilizzare
un account utente di dominio membro del gruppo Administrators locale.
File system
Windows offre un’eccellente infrastruttura per la protezione degli oggetti del sistema
operativo, come i file. Microsoft consiglia di applicare l’autorizzazione NTFS per i file ai
file di dati e di log di tutti i database. L’account utente che deve essere utilizzato da
SQL Server 2000 deve invece disporre di autorizzazioni di controllo completo per i file
di database, mentre tutti i file di SQL Server 2000, inclusi i file eseguibili e le librerie a
collegamento dinamico (DLL, Dynamic Link Library), devono essere configurati in modo
da impedirne la manipolazione da parte degli utenti. Le autorizzazioni per questi file
devono essere impostate in modo da attribuire autorizzazioni di controllo completo
all’account utente utilizzato da SQL Server, al gruppo Administrators e all’account di
sistema locale. È preferibile non impostare altre autorizzazioni.
Il programma di installazione di SQL Server 2000 concede automaticamente le
autorizzazioni di controllo completo per i file associati a SQL Server sia agli account
di servizio, sia al gruppo locale degli amministratori.
Registro di sistema
Per proteggere l’installazione di SQL Server 2000 da eventuali attacchi al sistema
di protezione da parte degli utenti autorizzati ad accedere fisicamente al server, è
opportuno impostare le autorizzazioni di Windows appropriate per le chiavi del
Registro di sistema utilizzate per la configurazione di SQL Server 2000, in particolare,
per la chiave HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\MSSQLSERVER e le
relative sottochiavi, per un’istanza predefinita, oppure per la chiave
HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\MICROSOFT SQL
SERVER\NOMEISTANZA e le relative sottochiavi, per le istanze denominate. Si
consiglia pertanto di rimuovere dal gruppo everyone le autorizzazioni relative a tale
chiave e di aggiungere autorizzazioni di controllo completo al gruppo
Administrators, all’account di sistema locale e all’account di servizio di SQL Server.
Per gli account di servizio selezionati durante il processo di installazione, queste
operazioni vengono eseguite automaticamente dal programma di installazione.
52
L’impostazione delle autorizzazioni relative alle chiavi del Registro di sistema è
particolarmente importante quando gli amministratori di SQL Server desiderano
impedire agli amministratori di Windows di accedere a SQL Server. In questo caso,
poiché gli amministratori di SQL Server devono assumere la proprietà della chiave
appropriata del Registro di sistema e rimuovere le autorizzazioni dal gruppo
Administrators, è essenziale che l’account di servizio di SQL Server disponga
di autorizzazioni di controllo completo. Sebbene non impedisca l’accesso da parte
degli amministratori, questo metodo consente agli amministratori di SQL Server
di scoprire se la sicurezza è stata compromessa dagli amministratori di Windows.
Gli amministratori possono sempre assumere la proprietà, ma non assegnarla.
Per ulteriori informazioni sull’accesso a SQL Server da parte degli amministratori
di Windows, vedere la sezione “Problemi connessi all’utilizzo dell’account sa” del
presente documento.
Controllo
SQL Server 2000 consente di utilizzare il log eventi di Windows per controllare l’accesso
al server. Per configurare il livello di controllo è possibile utilizzare SQL Server
Enterprise Manager o la stored procedure estesa xp_loginconfig.
Le impostazioni di controllo disponibili sono elencate di seguito.

Nessuno. Non vengono registrate informazioni di controllo.

Esito positivo. Vengono registrati solo gli accessi con esito positivo.

Esito negativo. Vengono registrati solo gli accessi con esito negativo.

Tutti. Vengono registrati tutti gli accessi, indipendentemente dall’esito.
Le informazioni di controllo vengono scritte nel log degli errori di SQL Server 2000.
Profiling per il controllo
In SQL Server 2000 è disponibile uno strumento di profiling estremamente potente,
SQL Profiler, che consente di analizzare numerosi eventi interni di SQL Server e
fornisce funzionalità complete per il controllo della protezione.
SQL Profiler acquisisce e analizza tutte le azioni eseguite in SQL Server. Le informazioni
acquisite possono essere visualizzate in tempo reale sullo schermo, salvate in un file di
testo oppure inserite in una tabella di SQL Server.
SQL Profiler consente di acquisire praticamente tutti gli eventi di SQL Server, inclusi i
seguenti:

Attività dell’utente finale: comandi SQL, connessioni e disconnessioni, attivazione
dei ruoli applicazione.

Attività DBA: DDL (ad eccezione di GRANT, REVOKE e DENY ed eventi di
protezione) e configurazione del server o di un database.

Eventi di protezione: GRANT, REVOKE e DENY, accesso utente o ruolo, aggiunta,
rimozione o configurazione.

Eventi delle utilità: comandi backup, restore, bulk insert, bcp e DBCC.

Eventi del server: chiusura, sospensione e avvio.

Eventi di controllo: aggiunta, modifica e interruzione del controllo.
53
Queste informazioni sono di grande aiuto per stabilire quali operazioni sono state
eseguite, quando e da chi. Per ulteriori informazioni sull’attivazione del controllo, ad
esempio sulla creazione di una stored procedure da eseguire all’avvio del sistema,
vedere la documentazione in linea di SQL Server 2000.
In alternativa, è possibile utilizzare la modalità di controllo C2, che prevede
l’acquisizione di tutti gli eventi associati al controllo e di tutte le colonne di dati relative
a tali eventi. Poiché può generare in breve tempo volumi di dati estremamente elevati,
si consiglia di utilizzare questa modalità solo se si installa SQL Server 2000 in una
configurazione C2. Per ulteriori informazioni, vedere la documentazione in linea di SQL
Server 2000.
Backup e ripristino
Protezione di file e supporti di backup
Per un backup sicuro, si consiglia di creare i file di backup con SQL Server 2000, per
poi utilizzare il programma di backup di Windows NT per eseguire il backup di tali file
sui supporti applicandovi una password, di modo che possano essere ripristinati solo da
utenti che conoscono tale password. SQL Server 2000 supporta l’impostazione di una
password direttamente su un set di backup.
Si consiglia di collocare i file di dati di backup in una partizione NTFS in cui le
autorizzazioni per le directory siano impostate in modo da impedire l’accesso ai file da
parte degli utenti comuni.
Se è possibile proteggere fisicamente i supporti di backup, la creazione di copie di
backup standard con SQL Server 2000 non comporta rischi di sicurezza. Infatti, poiché i
dati veri e propri non sono crittografati, possono essere letti anche se i supporti sono
protetti da password, a meno che non siano protetti anche fisicamente.
Ripristino in un altro server
Per quanto riguarda il ripristino del database in un altro server, verranno illustrati tre
scenari specifici. Il primo è applicabile quando il server di origine e il server di
destinazione del database utilizzano la modalità di autenticazione mista.
Il secondo e il terzo scenario sono applicabili quando viene utilizzata l’autenticazione di
Windows ma, mentre nel secondo scenario il database viene ripristinato nello stesso
dominio, nel terzo viene ripristinato in un server di un altro dominio.
Modalità mista
Quando si ripristina un database in un server protetto con la modalità mista, non è
possibile applicare la protezione a livello di database, perché gli accessi memorizzati
nella tabella sysxlogins del database master e i diritti utente per l’accesso a un
determinato database vengono memorizzati nella tabella sysusers di tale database.
Tra le voci delle tabelle sysxlogins e sysusers relative a un determinato utente esiste
pertanto una connessione logica, costituita da un GUID di 16 byte. Per ulteriori
informazioni, vedere la sezione “Generazione di GUID per utenti non trusted” del
presente documento.
54
A causa di questa implementazione basata sui GUID, se si utilizza la modalità mista e si
ripristina un database in un computer SQL Server 2000 diverso da quello in cui è stato
concesso l’accesso al database, il collegamento tra la tabella sysxlogins e la tabella
sysusers viene interrotto e nessuno potrà più accedere al database, a parte i membri
del gruppo sysadmin. Sarà quindi necessario ricreare tutte le appartenenze ai ruoli e
le autorizzazioni degli utenti.
Autenticazione di Windows (ripristino all’interno
dello stesso dominio)
Se il database viene ripristinato in un altro computer SQL Server 2000 dello stesso
dominio, le autorizzazioni impostare nel database non subiscono alcuna modifica.
L’unico problema può essere costituito dalla necessità di concedere agli utenti le
autorizzazioni di accesso al server. L’autorizzazione di accesso al server viene
implementata in tutte le istanze di SQL Server.
Si supponga ad esempio che Bob sia membro del gruppo SALES e che tale gruppo sia
autorizzato ad accedere a SQLSERVER1. Se a Bob viene concesso il diritto di accesso al
database delle vendite, quando tale database viene ripristinato in SQLSERVER2 le
autorizzazioni di Bob sono ancora presenti, ma Bob non può utilizzare il database
perché il gruppo SALES non è autorizzato ad accedere al nuovo server. Se tuttavia
l’amministratore concede al gruppo EVERYONE i diritti di accesso al server, Bob può
ancora utilizzare il database, perché l’accesso al server costituiva l’unico ostacolo
all’utilizzo del database sales.
Pertanto, quando si ripristina un database in un altro server dello stesso dominio, le
autorizzazioni a livello di database rimangono invariate, ma può essere necessario
concedere le autorizzazioni di accesso al nuovo server.
Autenticazione di Windows (ripristino all’interno
di un altro dominio)
Se il database viene ripristinato in un altro dominio, possono presentarsi vari scenari, a
seconda degli utenti che desiderano accedere al database.
Utenti dei domini trusted
Se tra il dominio di origine e il nuovo dominio sussiste una relazione di trust, grazie alla
quale il dominio di origine viene riconosciuto come trusted da quello nuovo, gli utenti
del dominio di origine autorizzati ad accedere a SQL Server manterranno
completamente le autorizzazioni relative ai database, mentre gli utenti degli altri
domini trusted e gli utenti del nuovo dominio non disporranno di diritti di accesso ai
database.
Utenti del nuovo dominio
Gli utenti del nuovo dominio non sono autorizzati ad accedere ai database, perché i
relativi SID non sono presenti nelle tabelle sysusers dei database.
L’unica eccezione è costituita dagli account BUILTIN di Windows, che utilizzano gli
stessi SID in tutti i server. Le autorizzazioni concesse agli account BUILTIN, come
il gruppo locale Administrators, rimangono pertanto invariate. In questo caso si
presuppone che gli account BUILTIN dispongano di diritti di accesso e che SQL Server
sia installato in un domain controller.
55
Utenti di qualsiasi dominio con nome utente e password
invariati
Nella maggior parte delle implementazioni della protezione Windows, quando
è richiesto l’accesso a una risorsa non inclusa nel dominio specifico dell’utente
quest’ultimo può accedere a tale risorsa solo se esiste un account utente con
la stessa combinazione di nome utente e password. In questo caso, il funzionamento
è trasparente.
Se per la connessione al server vengono utilizzate named pipe, è innanzitutto
necessario stabilire una connessione a una condivisione di file. Questo metodo
funziona anche se l’utente desidera utilizzare un account con un altro nome, purché
utilizzi un computer dotato di Windows. Se a un utente che tenta di connettersi
a una risorsa di file da un computer Windows NT 4.0 o Windows 2000 viene negata
la connessione, e tale utente non utilizza attualmente altre credenziali sul computer
di destinazione, è possibile fornire un nuovo nome utente e una nuova password di
accesso.
Connessione e disconnessione di file
di database
I problemi associati alla connessione e alla disconnessione di file di database sono
analoghi a quelli illustrati nella sezione “Ripristino in un altro server” del presente
documento, ma in questo caso è necessario creare il database prima di ripristinare i dati.
Configurazione generali della protezione
di Windows
Poiché SQL Server 2000 si basa sull’architettura di protezione di Windows, tutti i
principi di sicurezza di Windows possono essere applicati anche ai server Windows che
eseguono SQL Server 2000.
Disattivazione dell’account Guest di Windows
Quando SQL Server 2000 viene eseguito in modalità di autenticazione di Windows,
utilizza Windows per tutte le operazioni di autenticazione dei client. Viene quindi
implementata la stessa infrastruttura di protezione di Windows, con i relativi vantaggi
e svantaggi. Sebbene gli svantaggi non siano molti, l’utilizzo dell’account Guest di
Windows costituisce un problema accuratamente documentato in molti articoli sulla
sicurezza pubblicati da Microsoft e da altri fornitori. Si consiglia pertanto di disattivare
l’account Guest, se necessario. Per ulteriori informazioni, vedere la risorsa TechNet
indicata nella sezione “Siti Web” dell’appendice A.
Limitazione dell’accesso fisico
Come per ogni altro server basato su Windows, se possibile è consigliabile limitare
l’accesso fisico. Infatti, se un utente non autorizzato riuscisse ad accedere fisicamente
al server, potrebbe avviarlo da un disco floppy e ottenere l’accesso al file system di
Windows NT. È pertanto necessario proteggere fisicamente i server di database di
produzione mission-critical.
56
Conclusioni
Con SQL Server 2000, gli amministratori di database dispongono di tutte le funzionalità
necessarie per configurare e gestire server di database sicuri e perfettamente integrati
con il sistema di protezione di Windows.
Sono inoltre disponibili strumenti per i programmatori che consentono di sviluppare
applicazioni sicure senza aumentare i tempi e le difficoltà di sviluppo.
57
Appendice A: Ulteriori informazioni
Manuali
Inside Microsoft® SQL Server™ 2000, di Kalen Delaney. Copyright 2000, Microsoft
Press. ISBN: 88-8331-178-7
Sams Teach Yourself Microsoft SQL Server 2000 in 21 Days, di Richard Waymire e Rick
Sawtell. Copyright 2000, Sams Publishing. ISBN 0-672-31969-1.
Siti Web
www.microsoft.com/italy/sql: home page di SQL Server
http://support.microsoft.com/support/sql: home page del servizio di supporto di SQL
Server
www.microsoft.com/italy/technet/: sito di risorse TechNet
www.microsoft.com/italy/msdn/: sito di risorse MSDN®
www.microsoft.com/italy/security/: principale sito Microsoft per le informazioni sulla
protezione
White Paper
http://msdn.microsoft.com/sqlserver: centro dedicato agli sviluppatori SQL Server,
contenente download e white paper tecnici aggiornati.
www.microsoft.com/italy/sql/techinfo/: elenco completo dei white paper disponibili nel
sito Web di SQL Server.
58