UGISS User Group Italiano SQL Server
Configurare l’utilizzo di SSL per criptare i dati scambiati tra SQL Server ed i Client è un’operazione semplice ma che può nascondere qualche insidia. Dato che la sicurezza non è mai troppa, in questo breve articolo vedremo tutti i passaggi necessari per configurare questa funzionalità, importantissima soprattutto se dovete garantire l’accesso a SQL Server tramite Internet, cosi da mettere al sicuro tutti i dati scambiati tra i vostri client e SQL Server, oltre che avere un’autenticazione ancora più efficace: potrete infatti decidere di autorizzare alla connessione a SQL Server solo i client in grado di criptare la connessione e quindi in possesso del certificato digitale corretto.
Per criptare con SSL la connessione tra un client e SQL Server è necessario essere in possesso di un certificato adatto allo scopo, ossia che abbia nella proprietà "Enhanced Key Usage" al valore 1.3.6.1.5.5.7.3.1 ossia "Server Authentication".
Per generare un certificato con tale proprietà, se non lo si vuole acquistare da un’ente preposta (ad es. Verisign), oppure non si vuole mettere in piedi una Certification Authority perché si vuole solamente fare un test, lo si può generare in proprio utilizzado l’utility makecert:
L’utility makecert è disponibile nell’SDK del .NET Framework.
È importante che l’impostazione dell’opzione "-n" ossia il Subject del certificato sia il Fully-Qualified-Domain-Name (FQDN) del server alla quale il certificato andrà associato.
Eseguendo il comando suddetto sul server dov’è presente SQL Server si genererà un certificato che verrà automaticamente inserito tra i certificati disponibili all’interno del physical store "localmachine" e che sarà utilizzabile da SQL Server.
Avremo inoltre a disposizione in c:\dbserver.ugiss.cer il certificato pronto per essere dato ai client in modo che possano fornirlo al server ed cosi autenticarsi mutualmente criptando poi i dati scambiati.
Per associare il certificato a SQL Server è sufficiente aprire il SQL Server Configuration Manager, aprire la voce "SQL Server 2005 Network Configuration" ed aprire le proprietà della voce "Protocols for MSSQLSERVER". Fatto ciò, cliccando sulla voce "Certificate" sarà disponibile la selezione del certificato appena creato.
Beh, non sempre :-). Il certificato sarà presente nella drop-down list solamente se il soggetto dello stesso è il nome del server. Per poter essere usato dai client, però, il certificato creato DEVE avere il FQDN del server, ma se non siete in un dominio il FQDM potrebbe non essere quello che dovete specificare poiché i client che si tenteranno di collegarsi a SQL Server non riconosceranno il FQDN e vi risponderanno con l’errore
Questo perché il nome del server (non nel dominio) è "dbserver", ma il FQDN per i client sarà "dbserver.ugiss.org", e siamo quindi costretti a specificare quest’ultimo per far si che i client possano riconoscere correttamente il certificato del server, ma ciò impedisce al server di elencare tra i certificati validi il certificato suddetto in quanto il valore definito nel parametro CN è diverso dal nome del server, ossia "dbserver" (e non "dbserver.ugiss.org").
Come uscire da questo circolo vizioso se pur ci serve la cifratura della connessione ma non siamo in un dominio? La risposta (nascosta) sta nel contenuto di questo post del team di sviluppo dei protocolli di comunicazione di SQL Server: http://blogs.msdn.com/sql_protocols/archive/2005/12/30/508311.aspx. In particolare la nota che dice:
We will match against the computer name part (i.e., the first part) of the FQDN, rather than the whole FQDN. In addition, if a user configures the server to load the certificate by hash value, item 5) will not be a requirement anymore. In SQL Server 2005, a user can use SQL Server Configuration Manager to configure the server to load the certificate by hash value. The Thumbprint value of the certificate will be saved as the value of the following registry:
In pratica dobbiamo quindi prendere il Thumbprint del nostro certificato e metterlo a mano nella chiave di registry suddetta.
Il Thumbprint lo si preleva direttamente dal certificato esportato (doppio click sul file .cer), rimuovendo gli spazi presenti nello stesso.
Fatto ciò si può riavviare il servizio di SQL Server e se tutto è stato fatto correttamente nel log di avvio di SQL Server si potrà leggere:
A questo punto possiamo passare a configurare i client.
È necessario copiare il file .cer generato con il comando makecert sul client e fare un doppio-click sullo stesso in modo che Windows ci chieda se lo vogliamo installare nella nostra macchina. La risposta è si e siccome è un certificato di prova non garantito da nessuna certification authority lo dobbiamo installare nel key store "Trusted Root Certification Authorities" nello store fisico "local machine".
Fatto questo è possibile seguire le indicazioni dell’help per poter criptare tutte le connessioni, oppure lasciare al client la possibilità di decidere se criptare o meno la trasmissione:
Encrypting Connections to SQL Server
http://msdn2.microsoft.com/en-us/library/ms189067.aspx
How to: Enable Encrypted Connections to the Database Engine
http://msdn2.microsoft.com/en-us/library/ms191192.aspx
Per verificare che la vostra connessione sia criptata basta fare una query sulla DMV relativa alle connessioni:
Alla voce "encrypt_option" leggerete "true".
Altri riferimenti utilii per utilizzare SSL con SQL Server:
Install a self-signed test certificate that can be loaded by SQL Server automatically
http://blogs.msdn.com/sql_protocols/archive/2007/06/27/install-a-self-signed-test-certificate-that-can-be-loaded-by-sql-server-automatically.aspx
Certificate for SQL Server 2005
http://blogs.msdn.com/sql_protocols/archive/2005/12/30/508311.aspx
Enabling Certificate for SSL on a SQL Server 2005 Clustered Installation
http://blogs.msdn.com/jorgepc/archive/2008/02/19/enabling-certificates-for-ssl-connection-on-sql-server-2005-clustered-installation.aspx
Se siete curiosi di capire perchè è bene installare SSL, potete scaricare questo bel tool free di Microsoft che vi analizza i pacchetti di rete….in breve tempo potrete verificare da soli come una login ed una password memorizzate in una tabella di SQL Server (cosa tipica nelle applicazioni custom) possano essere intercettate con facilità:
Microsoft Network Monitor 3.1
http://www.microsoft.com/downloads/details.aspx?FamilyID=18b1d59d-f4d8-4213-8d17-2f6dde7d7aac&displaylang=en
