Transport Layer Security e certificati digitali
Questo articolo descrive i dettagli del protocollo Transport Layer Security (TLS) e dei certificati digitali.
Transport Layer Security (TLS)
I protocolliTLS e SSL si trovano tra il livello del protocollo dell'applicazione e il livello TCP/IP, dove possono proteggere e inviare i dati dell'applicazione al livello trasporto. I protocolli TLS/SSL usano gli algoritmi di un pacchetto di crittografia per creare chiavi e crittografare informazioni. Il client e il server negoziano la versione del protocollo e il pacchetto di crittografia da usare durante la fase iniziale di connessione (pre-accesso). La versione TLS più elevata supportata è sempre preferibile nell'handshake TLS. Per controllare le versioni dei protocolli TLS supportate da versioni diverse dei sistemi operativi Windows, vedere Protocolli in TLS/SSL (SSP Schannel). Sono state segnalate diverse vulnerabilità note relative a SSL e versioni del protocollo TLS precedenti. Si consiglia di eseguire l'aggiornamento a TLS 1.2 per una comunicazione sicura.
SQL Server può usare TLS per crittografare i dati trasmessi attraverso una rete tra un'istanza di SQL Server e un'applicazione client. TLS usa un certificato per implementare la crittografia.
Abilitando la crittografia TLS è possibile aumentare la sicurezza dei dati trasmessi nelle reti tra le istanze di SQL Server e le applicazioni. Tuttavia, quando tutto il traffico tra SQL Server e un'applicazione client è crittografato con TLS, sono necessarie le operazioni di elaborazione aggiuntive seguenti:
- Al momento della connessione è necessario un ulteriore round trip in rete.
- I pacchetti inviati dall'applicazione all'istanza di SQL Server devono essere crittografati dallo stack TLS del client e decrittografati dallo stack TLS del server.
- I pacchetti inviati dall'istanza di SQL Server all'applicazione devono essere crittografati dallo stack TLS del server e decrittografati dallo stack TLS del client.
Importante
A partire da SQL Server 2016 (13.x), Secure Sockets Layer (SSL) non è più disponibile. Usare invece TLS (si consiglia TLS 1.2). Per altre informazioni, vedere l'articolo KB3135244 - Supporto di TLS 1.2 per Microsoft SQL Server. SQL Server 2022 introduce il supporto per TLS 1.3. Per altre informazioni, vedere Supporto di TLS 1.3. Se non esistono protocolli corrispondenti tra il computer client e server, è possibile che si verifichi l'errore descritto in Una connessione esistente è stata chiusa forzatamente dall'host remoto.
Panoramica del certificato digitale
I certificati digitali sono file elettronici che funzionano come una password online per verificare l'identità di un utente o di un computer. Vengono usati per creare il canale crittografato usato per le comunicazioni client. Un certificato è un'istruzione digitale rilasciata da un'autorità di certificazione (CA) che garantisce l'identità del titolare del certificato e consente alle parti di comunicare in modo sicuro usando la crittografia.
I certificati digitali forniscono i servizi seguenti:
- Crittografia: consentono di proteggere i dati scambiati da furti o manomissioni.
- Autenticazione: verificano che i loro titolari (persone, siti Web e persino dispositivi di rete come i router) siano realmente chi o cosa sostengono di essere. In genere, l'autenticazione è unidirezionale, ovvero l'origine verifica l'identità della destinazione, ma è possibile anche l'autenticazione TLS reciproca.
Un certificato contiene una chiave pubblica e collega tale chiave pubblica all'identità di una persona, di un computer o di un servizio che contiene la chiave privata corrispondente. Le chiavi pubbliche e private vengono usate dal client e dal server per crittografare i dati prima che vengano trasmessi. Per gli utenti, i computer e i servizi di Windows, l'attendibilità nella CA viene stabilita quando il certificato radice viene definito nell'archivio certificati radice attendibili e il certificato contiene un percorso di certificazione valido. Un certificato viene considerato valido se non è stato revocato (non si trova nell'elenco di revoche di certificati della CA o nel CRL) o non è scaduto.
I tre tipi principali di certificati digitali sono descritti nella tabella seguente:
| Tipo | Descrizione | Vantaggi | Svantaggi |
|---|---|---|---|
| Certificato autofirmato | Il certificato viene firmato dall'applicazione che l'ha creato o viene creato usando New-SelfSignedCertificate. | Costo (gratuito) | - Il certificato non viene considerato automaticamente attendibile dai computer client e dai dispositivi mobili. Il certificato deve essere aggiunto manualmente all'archivio certificati radice attendibili in tutti i computer client e dispositivi, ma non tutti i dispositivi mobili consentono modifiche all'archivio certificati radice attendibili. - Non tutti i servizi utilizzano certificati autofirmati. - Difficile stabilire un'infrastruttura per la gestione del ciclo di vita dei certificati. Ad esempio, i certificati autofirmati non possono essere revocati. |
| Certificato emesso da una CA interna | Il certificato viene rilasciato da un'infrastruttura a chiave pubblica (PKI) nell'organizzazione. Ne sono un esempio i Servizi certificati Active Directory (AD CS). Per maggiori informazioni, vedere Panoramica di Active Directory Certificate Services. | - Consente alle organizzazioni di rilasciare i propri certificati. - Meno costoso rispetto ai certificati di una CA commerciale. |
- Maggiore complessità per distribuire e gestire l'infrastruttura a chiave pubblica. - Il certificato non viene considerato automaticamente attendibile dai computer client e dai dispositivi mobili. Il certificato deve essere aggiunto manualmente all'archivio certificati radice attendibili in tutti i computer client e dispositivi, ma non tutti i dispositivi mobili consentono modifiche all'archivio certificati radice attendibili. |
| Certificato rilasciato da una CA commerciale | Il certificato viene acquistato da una CA commerciale attendibile. | La distribuzione dei certificati è semplificata perché tutti i client, i dispositivi e i server considerano automaticamente attendibili i certificati. | Costo. È necessario pianificare in anticipo per ridurre al minimo il numero di certificati necessari. |
Per dimostrare che un titolare del certificato è chi dichiara di essere, il certificato deve identificare accuratamente il titolare ad altri client, dispositivi o server. I tre metodi di base per eseguire questa operazione sono descritti nella tabella seguente:
| metodo | Descrizione | Vantaggi | Svantaggi |
|---|---|---|---|
| Corrispondenza dell'oggetto del certificato | Il campo Oggetto del certificato contiene il nome comune (CN) dell'host. Ad esempio, il certificato rilasciato per www.contoso.com può essere usato per il sito Web https://www.contoso.com. |
- Compatibile con tutti i client, i dispositivi e i servizi. - Compartimentazione. La revoca del certificato per un host non influisce sugli altri host. |
- Numero di certificati necessari. È possibile usare il certificato solo per l'host specificato. Ad esempio, non è possibile usare il certificato www.contoso.com per ftp.contoso.com, anche se i servizi vengono installati nello stesso server.- Complessità. In un server Web ogni certificato richiede il proprio binding di indirizzi IP. |
| Corrispondenza dei nomi alternativi dei soggetti (SAN) dei certificati | Oltre al campo Oggetto, il campo Nome alternativo soggetto del certificato contiene un elenco di più nomi host. Ad esempio:www.contoso.comftp.contoso.comftp.eu.fabirkam.net |
- Praticità. È possibile usare lo stesso certificato per più host in più domini separati. - La maggior parte dei client, dei dispositivi e dei servizi supporta i certificati SAN. - Controllo e sicurezza. Saprai esattamente quali host sono in grado di usare il certificato SAN. |
- È necessaria una pianificazione più approfondita. È necessario specificare l'elenco degli host quando si crea il certificato. - Mancanza di compartimentazione. Non è possibile revocare in modo selettivo i certificati per alcuni degli host specificati senza influire su tutti gli host nel certificato. |
| Corrispondenza del certificato con carattere jolly | Il campo Oggetto del certificato contiene il nome comune come carattere jolly (*) più un singolo dominio o sottodominio. Ad esempio, *.contoso.com o *.eu.contoso.com. Il certificato con caratteri jolly *.contoso.com può essere usato per:www.contoso.comftp.contoso.commail.contoso.com |
Flessibilità. Non è necessario fornire un elenco di host quando si richiede il certificato ed è possibile usare il certificato in un numero qualsiasi di host che potrebbero essere necessari in futuro. | - Non è possibile usare certificati con caratteri jolly con altri domini di primo livello (TLD). Ad esempio, non è possibile usare il certificato con caratteri jolly *.contoso.com per gli host *.contoso.net.- È possibile usare solo i certificati con caratteri jolly per i nomi host a livello di carattere jolly. Ad esempio, non è possibile usare il certificato *.contoso.com per www.eu.contoso.com. Oppure, non è possibile usare il certificato *.eu.contoso.com per www.uk.eu.contoso.com.- I client, i dispositivi, le applicazioni o i servizi meno recenti potrebbero non supportare i certificati con caratteri jolly. - I caratteri jolly non sono disponibili con certificati di convalida estesa (EV). - Sono necessari revisioni e controlli accurati. Se il certificato con caratteri jolly viene compromesso, ciò influisce su ogni host nel dominio specificato. |