SQL Server 2008:

sicurezza

Rick Byham

 

Panoramica:

  • Miglioramenti alla crittografia
  • Miglioramenti all'autenticazione
  • Controllo della sicurezza
  • Gestione basata su criteri

SQL Server 2008 fornisce numerosi miglioramenti e nuove funzionalità progettati per migliorare la sicurezza globale dell'ambiente di database. Introduce inoltre funzionalità di crittografia e autenticazione chiave e un nuovo sistema di controllo che

consente di creare report sul comportamento degli utenti e garantire la conformità ai requisiti normativi.

In questo articolo viene presentata una panoramica delle modifiche più importanti introdotte in SQL Server® 2008 a livello di sicurezza. Uno dei primi aspetti che si noterà è che lo strumento Configurazione superficie di attacco di SQL Server 2005 non è più supportato. Le opzioni di protocollo esposte dallo strumento Configurazione superficie di attacco ora sono disponibili nello strumento Gestione configurazione. Tuttavia, l'attivazione e la disattivazione delle funzionalità ora vengono eseguite mediante il nuovo framework per la gestione basata su criteri di SQL Server 2008.

Miglioramenti alla crittografia

Nell'area della crittografia sono stati introdotti due importanti miglioramenti. Primo, SQL Server ora supporta l'utilizzo delle chiavi di crittografia archiviate in un modulo di sicurezza hardware di terze parti esterno. Secondo, i dati archiviati in SQL Server possono essere crittografati in un metodo trasparente per le applicazioni che si connettono al database. Ne consegue che gli amministratori di database possono crittografare facilmente tutti i dati archiviati in un intero database senza dover modificare il codice dell'applicazione esistente.

Il primo miglioramento è reso possibile dalla nuova funzionalità Extensible Key Management (EKM), disponibile nelle edizioni Enterprise, Developer ed Evaluation di SQL Server 2008. EKM consente ai fornitori di soluzioni di gestione di chiavi a livello aziendale e di moduli di sicurezza hardware (HSM) di terze parti di registrare i relativi dispositivi in SQL Server. Una volta registrati i dispositivi, gli utenti possono utilizzare le chiavi di crittografia archiviate in questi moduli.

Questi fornitori possono esporre nei moduli persino funzionalità di crittografia avanzate, come la scadenza e la rotazione delle chiavi. In alcune configurazioni, questo consente di proteggere i dati da amministratori di database che non sono membri del gruppo sysadmin. Le istruzioni di crittografia T-SQL consentono quindi di crittografare e decrittografare i dati utilizzando le chiavi archiviate nel dispositivo EKM esterno.

Un'altra nuova funzionalità, la crittografia trasparente dei dati, consente di crittografare i file di database senza dover apportare modifiche ad alcuna applicazione. Questa funzionalità consente di eseguire la crittografia e la decrittografia I/O in tempo reale dei file di registro e di dati. La crittografia utilizza la chiave di crittografia del database (DEK, Database Encryption Key), che è archiviata nel record di avvio del database per la disponibilità durante il ripristino. La chiave di crittografia del database viene protetta con un certificato archiviato nel database master del server. Nel diagramma nella Figura 1 viene illustrata l'architettura che abilita la crittografia trasparente dei dati.

Figura 1 Architettura della crittografia trasparente dei dati

Figura 1** Architettura della crittografia trasparente dei dati **(Fare clic sull'immagine per ingrandirla)

Questa architettura risulta particolarmente utile per la protezione dei dati inattivi. Sebbene sia possibile adottare diverse precauzioni per garantire la sicurezza del proprio database, come la crittografia di cespiti riservati e il posizionamento di un firewall intorno ai server di database, il supporto fisico su cui il database viene archiviato (anche i nastri di backup) presenta una vulnerabilità differente. Un utente malintenzionato potrebbe rubare questo supporto e accedere ai dati in esso archiviati.

La crittografia trasparente dei dati, tuttavia, consente di crittografare i dati riservati nel database e di proteggere le chiavi utilizzate per crittografare i dati con un certificato. Questo può consentire alle organizzazioni di garantire la conformità a gran parte delle leggi, delle normative e delle linee guida del settore correlate all'adeguata protezione dei dati.

La crittografia trasparente dei dati consente agli sviluppatori software di crittografare i dati utilizzando gli algoritmi di crittografia AES (Advanced Encryption Standard) e 3DES (Triple Data Encryption Standard). La crittografia del file di database viene eseguita a livello di pagina, ovvero le pagine vengono crittografate prima di essere scritte su disco e successivamente decrittografate quando vengono lette in memoria. I file di backup dei database per i quali la crittografia trasparente ei dati è attivata vengono crittografati anche utilizzando la chiave di crittografia del database.

Per ripristinare un database crittografato, è necessario accedere al certificato o alla chiave asimmetrica utilizzata per crittografare il database. Senza il certificato o la chiave asimmetrica, non è possibile ripristinare il database. Pertanto, accertarsi di conservare tutte le chiavi per le situazioni in cui potrebbe essere necessario accedere ai backup correlati.

Miglioramenti all'autenticazione

Come probabilmente si saprà, Kerberos è un protocollo di autenticazione di rete utilizzato per fornire un sistema a elevata sicurezza per l'autenticazione reciproca delle entità client e server (o entità di sicurezza) su una rete. Kerberos consente agli utenti di ridurre i rischi causati da vulnerabilità della sicurezza, come gli attacchi di elevazione di privilegi e di tipo man-in-the-middle. Rispetto all'autenticazione NTLM di Windows®, Kerberos è più sicuro e affidabile e offre prestazioni più elevate.

Per eseguire l'autenticazione reciproca di una connessione utilizzando Kerberos, è necessario che i nomi principali di servizio (SPN, Service Principal Name) di un'istanza di SQL Server vengano registrati in Active Directory® e che un driver client fornisca un SPN registrato durante la connessione. In SQL Server 2008, l'autenticazione Kerberos è stata estesa a tutti i protocolli di rete, compresi TCP, Named Pipe, Shared Memory e Virtual Interface Adapter (VIA). Per impostazione predefinita, il driver client deduce automaticamente un SPN corretto per un'istanza di SQL Server a cui si connette. È inoltre possibile specificare in modo esplicito un SPN nel parametro della stringa di connessione per garantire livelli di sicurezza e controllo più elevati oltre che una più efficace risoluzione dei problemi.

Internet Information Services (IIS) non fornisce più l'accesso ad ASP.NET, a Gestione report o al servizio Web ReportServer. In SQL Server 2008, Reporting Services gestisce tutta le richieste di autenticazione tramite un nuovo sottosistema di autenticazione che supporta l'autenticazione personalizzata e basata su Windows.

Reporting Services ora esegue l'hosting delle tecnologie di Microsoft® .NET Framework e ASP.NET incorporate nel CLR (Common Language Runtime) di SQL Server e utilizza le funzionalità HTTP.SYS del sistema operativo. Il server di report include un listener HTTP che accetta le richieste indirizzate a un URL e a una porta definiti durante la configurazione del server. La registrazione e le prenotazioni URL ora vengono gestite dal server di report tramite HTTP.SYS.

Controllo della sicurezza

SQL Server Audit è una nuova funzionalità che consente di creare controlli personalizzati degli eventi del motore di database. Questa funzionalità utilizza eventi estesi per registrare le informazioni per i controlli e fornisce gli strumenti e i processi necessari per attivare, archiviare e visualizzare i controlli su diversi oggetti di server e database.

SQL Server Audit, inoltre, offre prestazioni più elevate rispetto a SQL Server Trace, mentre SQL Server Management Studio consente di semplificare la creazione e il monitoraggio dei registri di controllo. È possibile eseguire il controllo a un livello di granularità maggiore, acquisendo le istruzioni SELECT, INSERT, UPDATE, DELETE, REFERENCES ed EXECUTE per i singoli utenti. Inoltre, SQL Server Audit è completamente configurabile tramite script con le istruzioni T-SQL CREATE SERVER AUDIT e CREATE SERVER AUDIT SPECIFICATION e le istruzioni correlate ALTER e DROP.

Per configurare il controllo, creare un controllo e specificare il percorso in cui gli eventi controllati verranno registrati. I controlli possono essere salvati nel registro eventi di sicurezza di Windows, nel registro applicazione di Windows o in un file nel percorso specificato. Assegnare un nome al controllo e configurarne le caratteristiche, come il percorso del file di controllo e la relativa dimensione massima. È inoltre possibile impostare SQL Server in modo che venga arrestato in caso di errore del controllo. Se è necessario registrare gli eventi controllati in più posizioni, creare semplicemente più controlli.

Il passaggio successivo consiste nel creare una o più specifiche del controllo. Una specifica di controllo del server raccoglie informazioni sull'istanza di SQL Server e contiene gli oggetti con ambito server, come account di accesso e appartenenze al ruolo del server. Include inoltre le informazioni di database gestite nel database master, come il diritto di accesso a un database. Quando si definisce una specifica di controllo, viene indicato il controllo che riceverà gli eventi monitorati. È possibile definire più controlli del server e più specifiche di controllo del server, ma ciascun controllo del server può includere una sola specifica di controllo del server attivata per volta.

È inoltre possibile creare specifiche di controllo del database che consentono di monitorare gli eventi in un singolo database. È possibile aggiungere a un controllo più specifiche di controllo del database, ma un controllo del server può attivare una sola specifica di controllo per ciascun database per volta.

Gli eventi delle azioni di controllo di SQL Server utilizzati per le specifiche di controllo del server vengono raggruppati in insiemi di eventi di azioni di controllo correlati. Questi insiemi vengono esposti come gruppi di azioni di controllo. Quando si aggiunge un gruppo alla specifica di controllo, vengono monitorati tutti gli eventi inclusi in tale gruppo. Esiste, ad esempio, un gruppo di azioni di controllo denominato DBCC_GROUP che espone i comandi DBCC. I comandi DBCC, tuttavia, non sono in grado di gestire il controllo singolarmente.

Sono disponibili 35 gruppi di azioni di controllo per il server, alcuni dei quali sono strettamente correlati tra loro. Sono disponibili, ad esempio, i gruppi SUCCESSFUL_LOGIN_GROUP, FAILED_LOGIN_GROUP e LOGOUT_GROUP. È inoltre disponibile il tipo di azione di controllo AUDIT_ CHANGE_GROUP, che è possibile utilizzare per controllare il processo di controllo.

Le specifiche di controllo del database consentono inoltre di specificare i gruppi di eventi di azioni di controllo raccolti nei gruppi di azioni di controllo a livello di database. Oltre ai gruppi di azioni di controllo, la specifica di controllo del database può contenere singoli eventi di azioni di controllo per controllare le istruzioni Data Manipulation Language (DML). È possibile configurare questi eventi per il monitoraggio dell'intero database o solo di specifici oggetti di database. L'azione di controllo SELECT, ad esempio, può essere utilizzata per controllare le query SELECT per una singola tabella o un intero schema. Questi eventi possono inoltre essere configurati per il monitoraggio delle azioni da parte di specifici utenti o ruoli, ad esempio tutti i ruoli db_writer.

È possibile utilizzare l'azione di controllo SELECT, ad esempio, per controllare le query SELECT per una singola tabella in base all'utente Mary o al ruolo di database FINANCE_DEPT o al ruolo di database pubblico. Ovviamente, questo offre un ampio margine di controllo e flessibilità per la creazione dei controlli necessari.

Creazione di report di dipendenze

La creazione dei report delle dipendenze è stata migliorata con una nuova vista del catalogo e nuove funzioni di sistema. Se si utilizza sys.sql_expression_dependencies, sys.dm_sql_referencing_entities e sys.dm_sql_referenced_entities, è possibile creare report su dipendenze tra server, dipendenze tra database e dipendenze SQL a livello di database per gli oggetti associati a schema e non associati a schema.

Nuovi ruoli di database

Sono state apportate modifiche ai ruoli di database inclusi nel database msdb. I ruoli db_dtsadmin, db_dtsltduser e db_dtsoperator sono stati rinominati rispettivamente in db_ssisadmin, db_ssisltduser e db_ssisoperator. Per supportare la compatibilità con le versioni precedenti, i ruoli precedenti vengono aggiunti come membri dei nuovi ruoli durante l'aggiornamento dei server.

Oltre a queste modifiche, sono stati aggiunti nuovi ruoli di database per fornire il supporto per le nuove funzionalità di SQL Server 2008. In particolare, il database msdb include nuovi ruoli per i gruppi di server (ServerGroupAdministratorRole e ServerGroupReaderRole), la gestione basata su criteri (PolicyAdministratorRole) e l'agente di raccolta dati (dc_admin, dc_operator e dc_proxy). Anche il database del data warehouse di gestione include nuovi ruoli per l'agente di raccolta dati (mdw_admin, mdw_writer e mdw_reader).

Sicurezza FILESTREAM

SQL Server ora fornisce il supporto per l'archiviazione FILESTREAM, che consente alle applicazioni SQL Server di archiviare dati non strutturati, come documenti e immagini, nel file system. Questo, a sua volta, implica che le applicazioni client possono sfruttare le API di flusso e le prestazioni del file system, garantendo nel contempo la coerenza delle transazioni tra i dati non strutturati e i dati strutturati corrispondenti.

I dati FILESTREAM devono essere archiviati in filegroup FILESTREAM, uno speciale filegroup che contiene le directory del file system anziché i file effettivi. Queste directory, denominate contenitori di dati, forniscono l'interfaccia tra l'archiviazione del motore di database e l'archiviazione del file system.

In termini di sicurezza, i dati FILESTREAM vengono protetti allo stesso modo degli altri dati; le autorizzazioni vengono concesse a livello di tabella o colonna. L'unico account a cui vengono concesse autorizzazioni NTFS per il contenitore FILESTREAM è l'account con cui viene eseguito l'account di servizio di SQL Server. Quando un database viene aperto, SQL Server limita l'accesso ai contenitori di dati FILESTREAM, eccetto quando l'accesso viene eseguito utilizzando le transazioni T-SQL e le API OpenSqlFilestream.

Gestione basata su criteri

La gestione basata su criteri di SQL Server 2008 fornisce un nuovo sistema per gestire SQL Server. È possibile creare criteri per testare e generare report su molti aspetti di SQL Server; i criteri possono essere applicati a un singolo database, a una singola istanza di SQL Server o a tutti i server SQL Server gestiti.

Con la gestione basata su criteri, è possibile testare le opzioni di configurazione di SQL Server e molte impostazioni di sicurezza. Per alcune impostazioni di sicurezza, è possibile creare criteri che consentono di rilevare i server di database non conformi e, successivamente, è possibile intraprendere le opportune azioni per renderli conformi.

In SQL Server 2008, numerose funzionalità che non sono considerate essenziali sono disattivate per impostazione predefinita, in modo da ridurre al minimo l'esposizione a possibili attacchi. È possibile utilizzare la gestione basata su criteri per attivare selettivamente eventuali funzionalità aggiuntive necessarie. È possibile quindi valutare la configurazione in base a una pianificazione, ricevendo avvisi nel caso in cui vengano rilevate impostazioni di configurazione non conformi ai criteri.

La gestione basata su criteri consente di raggruppare le proprietà correlate e di esporle in componenti denominati facet. Ad esempio, il facet Configurazione superficie di attacco contiene le proprietà per Query remote ad hoc, Integrazione con CLR, Posta elettronica database, Automazione OLE, Attiva DAC remote, SQL Mail, Pubblicazione guidata sul Web e xp_cmdshell. È possibile creare un criterio che consenta di attivare l'opzione Integrazione con CLR ma disattiva tutte le altre funzionalità. I criteri possono includere istruzioni di condizioni complesse, come la disattivazione di Posta elettronica database su tutte le istanze di SQL Server, a meno che non siano denominate Customer_Response.

Una volta creato il criterio, è possibile valutarlo su tutti i server per produrre un report in cui indicare i server non conformi. Fare clic sul pulsante Configura in modo che tutte le istanze non conformi vengano configurate con le impostazioni dei criteri. È opportuno inoltre pianificare l'esecuzione del criterio a intervalli periodici in modo da monitorare lo stato dei server. I facet Configurazione superficie di attacco vengono forniti per il Motore di database, Analysis Services e Reporting Services.

Notare, tuttavia, che la gestione basata su criteri non è un meccanismo di tutela della sicurezza. Nella maggior parte dei casi, un utente con privilegi sufficienti può eseguire istruzioni che violano un criterio o ignorare il criterio ed eseguire azioni di riconfigurazione che potrebbero violare i criteri di sicurezza. La gestione basata su criteri di SQL Server 2008 deve essere considerata semplicemente come un meccanismo di supporto per il monitoraggio delle impostazioni di sicurezza di SQL Server.

I facet si differenziano per la capacità di applicare le impostazioni, a seconda che le relative istruzioni DDL correlate possano essere eseguite o meno in modalità che non prevedono il commit automatico. A volte un facet può forzare un'impostazione di configurazione su un'istanza del Motore di database; tuttavia, un amministratore è comunque in grado di riconfigurare le impostazioni. Alcuni facet possono essere applicati da un trigger a livello di server; questo può impedire a utenti con privilegi ridotti di modificare l'impostazione e ridurre la possibilità che un amministratore modifichi accidentalmente l'impostazione. In questo caso, l'amministratore dovrebbe disattivare temporaneamente i criteri prima di modificare l'impostazione. Altri facet possono solo produrre report sullo stato di una proprietà ma non possono modificarlo. Questo è quanto avviene con un criterio che controlla la lunghezza di una chiave simmetrica o asimmetrica, come illustrato nella Figura 2.

Figura 2 Facet per chiavi asimmetriche

Figura 2** Facet per chiavi asimmetriche **(Fare clic sull'immagine per ingrandirla)

Sono disponibili altri facet per la maggior parte dei tipi di oggetti di database, molti dei quali vengono utilizzati nell'ambito della sicurezza. Ad esempio, il facet di accesso può determinare se i criteri password vengono applicati per ciascun accesso, mentre il facet delle stored procedure è in grado di rilevare se vengono crittografate tutte le stored procedure. Altri facet sono in grado di testare proprietà di utenti, schemi, provider di servizi di crittografia, conformità ai criteri comuni e controllo C2.

Windows Server 2008

SQL Server 2008 è stato completamente testato con Windows Server® 2008, che viene fornito con il firewall attivato. Questo è il momento opportuno per esaminare la modalità di configurazione delle impostazioni del firewall. Windows Server 2008 fornisce inoltre la funzionalità di controllo di accesso utente già disponibile in Windows Vista®. Questa funzionalità limita i privilegi ricevuti automaticamente come utente con diritti di amministratore. Queste funzionalità avranno effetto su tutte le versioni di SQL Server.

Conclusioni

La sicurezza continua a essere un'area di miglioramento importante per SQL Server. I miglioramenti apportati alla crittografia e all'autenticazione forniscono nuove funzionalità, mentre il nuovo sistema di controllo e la gestione basata su criteri di SQL Server 2008 offrono nuovi strumenti per monitorare lo stato della conformità ai criteri di sicurezza.

Rick Byham è entrato in Microsoft nel 1995, dove ha lavorato come SQL Server Support Engineer presso il Servizio Supporto Tecnico Clienti e, successivamente, si è unito al team di SQL Server in Microsoft Learning. Nel 2003 è entrato a far parte del team per la documentazione in linea di SQL Server in qualità di technical writer, dove attualmente è responsabile della documentazione sulla sicurezza. È possibile contattare Rick all'indirizzo rick.byham@microsoft.com.

© 2008 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.